Primeras impresiones: 8 horas dedicadas a Windows Server 2016 Technical Preview 3

En una semana tumultuosa marcada por millones de cónyuges sudando la fuga de Ashley Madison, y Dios se inclinó para hacerle cosquillas a Google con no menos de cuatro rayos, Microsoft lanzó silenciosamente Technical Preview 3 (TP3) de Windows Server 2016 (WS2016) y System Center. Configuration Manager (ConfigMan), junto con algunos otros artículos diversos, como una actualización de Microsoft Deployment Toolkit (MDT) 2013, que finalmente debería ser totalmente compatible con Windows 10.

Todavía estoy asimilando las especificaciones de ConfigMan y MDT, pero pasé por dos seminarios web en profundidad de 4 horas sobre Windows Server 2016 presentados a principios de esta semana por Matt McSpirit, gerente senior de marketing técnico de productos en Microsoft, y Corey Hynes, Microsoft. MVP y CEO de Learn on Demand Systems. Los seminarios web sobre WS2016, aunque ya es TP3, fueron mi primera exposición real al nuevo sistema operativo (¡Oye, tengo una vida!).

Lo primero es lo primero: estas sesiones fueron largas pero extremadamente valiosas, cubriendo todas las novedades históricas de Windows Server, pero con una profundidad útil. Microsoft grabó ambas sesiones y pronto estarán disponibles gratuitamente en el sitio web de Microsoft Virtual Academy junto con los mazos de sesiones, demostraciones y enlaces de recursos. Por lo tanto, si WS2016 está en su radar, le recomiendo verlos.

Contenedores de Windows Server
En cuanto a las características importantes: sin duda, la gran novedad para TP3 es la inclusión de Microsoft de la tecnología de contenedores compatible con Docker, tanto en el sistema operativo como en las capas Hyper-V. Como señalaron los Redmond, los contenedores son una vieja noticia para los desarrolladores y tal vez para los ninjas de DevOps, pero probablemente no hayan sido parte del pensamiento de la mayoría de los administradores de TI. Después de todo, tenemos virtualización, entonces, ¿quién necesita contenedores? Bueno, tal vez tú.

La mejor manera que se me ocurre de conceptualizar los contenedores es como una instantánea de un estado específico del sistema operativo subyacente que puede bifurcar y ejecutar por sí solo. Entonces, por ejemplo, podría hacer girar un contenedor basado en una instancia básica de WS2016, agregar una aplicación lista para contenedores, ajustar con ciertas configuraciones o permisos, luego guardar todo el shebang para recuperarlo cuando se necesite ese estado del sistema operativo en el futuro.

No es una máquina virtual (VM), solo una colección de configuraciones y punteros de aplicaciones que piensan que son un SO independiente y se comportarán de esa manera cuando se activen, siempre y cuando el SO subyacente en el que se ejecutan tenga todas las características necesidades del contenedor. Esto no le brinda todo el aislamiento o la portabilidad de una máquina virtual completa, pero escala mucho más rápidamente (piense en segundos) y puede proporcionar una densidad mucho mayor por host. No son útiles para muchos (quizás incluso la mayoría) de los servicios que se esperan de un departamento de TI, pero pueden tener un gran valor en el servicio dinámico de aplicaciones, así como en entornos de desarrollo / prueba a gran escala.

Donde se vuelve complicado para los contenedores WS2016 es en la capa Hyper-V. Sí, Microsoft está introduciendo “contenedores de Windows Server”, así como “contenedores Hyper-V” y, no, no son lo mismo. Microsoft implementó completamente los contenedores en la capa del sistema operativo, lo que significa que puede instalar un sistema operativo host físico y crear contenedores a partir de ese (contenedores de Windows Server), pero también implementó contenedores en la capa del hipervisor Hyper-V. De modo que ahora puede tener un sistema operativo a nivel de máquina que ejecute Hyper-V y luego crear contenedores en una máquina virtual alojada en esa caja, o dos o más.

De hecho, podría hacerlo dos veces, en efecto, anidando hipervisores: Servidor A que ejecuta Hyper-V que aloja una máquina virtual que aloja un grupo de contenedores junto con otra máquina virtual que también ejecuta Hyper-V que aloja otro grupo de contenedores. ¿Por qué? Los Microsoftees no fueron muy claros en eso, excepto para decir que un contenedor Hyper-V perderá un poco en el departamento de consolidación de recursos mientras gana en capacidades de aislamiento, así que piense en escenarios de hospedaje especializado y de múltiples inquilinos.

Aparte de los contenedores, que fueron la gran noticia, McSpirit e Hynes mostraron varias otras características, la mayoría de las cuales se habían mencionado en la documentación de TP anterior:

Nano servidores: Aún más virtualización mini-yo. Piense en una máquina virtual de estilo Windows Core que contiene solo los bits necesarios para realizar su función específica. Son rápidos de construir y, debido a que solo llevan consigo el código que necesitarán, pueden ejecutarse en menos de 200 MB en lugar del espacio de 3 a 4 GB + de una VM típica. Además, no necesitan casi la cadencia de reinicio de una máquina virtual estándar porque solo se necesita parchear un pequeño porcentaje del código. Microsoft está lanzando Nano Servers como el servidor preferido para los servicios de estructura básica (ver más abajo). La desventaja es que no se pueden actualizar ni modificar una vez configurados y ninguno de los Microsoftee sabía cuál sería el plan de licencias para estas instancias, aunque ambos sospechaban que no habría ninguna nueva licencia mini-me, solo un precio de servidor estándar. Solo otro empujón para que salga con la edición Datacenter.
Máquinas virtuales encriptadas: Finalmente, algo más de seguridad alrededor de sus máquinas virtuales. En este esquema, Microsoft protege las máquinas virtuales de Hyper-V mediante BitLocker, almacena las claves en un bosque de AD de confianza y crea una relación de confianza entre el bosque de máquinas virtuales y el bosque de claves (y me refiero al bosque, no al dominio). Esto protege las máquinas virtuales blindadas contra el robo, la inspección o cualquier tipo de manipulación, aunque aparentemente requerirá hardware con logotipo verificado en el lado del servidor que debe tener un módulo de plataforma confiable (TPM) y usar la interfaz de firmware extensible unificada (UEFI).

Actualizaciones sin tiempo de inactividad: Bueno para quienes ofrecen servicios de misión crítica o trabajan bajo restricciones de acuerdo de nivel de servicio (SLA). Esto equivale a un esquema mediante el cual las máquinas host y las máquinas virtuales en un clúster pueden actualizarse a WS2016 sin necesidad de desactivar un servicio. La demostración se realizó manualmente y en gran parte en la línea de comandos a través de PowerShell, pero Microsoft promete más automatización para el lanzamiento final.

Almacenamiento definido por software: La novedad aquí se centra principalmente en Storage Spaces Direct, que permite a los administradores converger por separado Solo un grupo de discos (JBOD), así como servidores de archivos escalables en un solo grupo en lugar de múltiples niveles. En palabras de Hynes, “Piense en ello como RAID a nivel de servidor o llámelo agrupación de nada compartido”.

Réplica de almacenamiento: Nueva para WS2016, esta tecnología permite la replicación síncrona a nivel de almacenamiento en clústeres de datos, incluidas las distancias metropolitanas, y trae consigo una conmutación por error inmediata del nodo sin interrupción del servicio.

PowerShell inevitable
Todas estas características suenan muy bien, pero me llamó la atención un tema de características que las cruzó todas: PowerShell. Hynes tenía otra cita reveladora, aunque estoy parafraseando un poco: “Si quieres ser un [Windows] administrador del servidor, aprender PowerShell es inevitable, así que aprende a amarlo. “No es un mensaje completamente nuevo de Microsoft, pero la franqueza es reciente. La conclusión es que Microsoft te ha avisado: PowerShell ya no es solo una opción.

Y, según la naturaleza de casi todas las demostraciones que se muestran durante esas ocho horas de sesión, no está bromeando. Es cierto que estamos en TP3, por lo que habrá mucho más soporte de interfaz gráfica de usuario (GUI) por disponibilidad general (GA), pero pruebe algunas de estas funciones usted mismo y lo verá, incluso si obtienen una superposición de GUI. en el futuro, se diseñaron en gran medida teniendo en cuenta PowerShell. Microsoft apuesta por los conceptos de DevOps y todo definido por software, y PowerShell es el eje de esa estrategia. Si la descripción de su trabajo implica administrar una cantidad significativa de máquinas con plataforma Windows (servidores o dispositivos cliente) y realmente desea mantener ese trabajo, bueno, sigue el ejemplo de Hynes: abróchate el cinturón y aprende PowerShell, ahora.

Afortunadamente, realmente es una tecnología poderosa. Con PowerShell, McSpirit y Hynes administraron la automatización sobre la marcha, configuraron y activaron Nano Servers con una (larga) línea de código, aumentaron y disminuyeron la memoria de una VM en ejecución y también se conectaron a las VM que sufrían interrupciones en la red al iniciar sesión y ejecutar comandos de PowerShell a través del bus VM. Lo que me lleva al siguiente cambio de juego de mis ocho horas viendo Windows: redes definidas por software (SDN).

SDN en Windows Server 2012 R2 ya era una imagen bastante compleja, centrada en el conmutador extensible de Hyper-V y la función del servidor de puerta de enlace de red virtual. En WS2016, todo esto se mejora, pero gran parte de esa mejora proviene de lo que equivale a que Windows Server inicie una segunda red, la red Hyper-V, un nivel por debajo de su red actual. Otra frase común utilizada por McSpirit y Hynes fue: “Deje que el software se preocupe”. El software del que están hablando es esta capa de lógica de virtualización manejable que se encuentra debajo de sus redes IP, las conecta y administra el tráfico y las políticas entre ellas.

La administración de direcciones IP (IPAM), por ejemplo, podrá mostrar una vista de una sola consola de todas sus redes IP, dominios de Active Directory (AD) y redes físicas o virtuales (incluidas las redes basadas en Azure), incluso si tienen esquemas de direccionamiento redundantes y administrar el tráfico y la asignación de recursos entre ellos.

Otra mejora clave es la introducción de funciones de red virtualizadas. Puede pensar en estos como dispositivos (y puede apostar que se verá obligado a usar Nano Server para implementarlos) que realizan la funcionalidad de todas esas cajas que tiene conectadas en sus bastidores de conmutadores hoy: firewalls, enrutadores, dispositivos inteligentes conmutadores y balanceadores de carga, por nombrar algunos. McSpirit señaló que la mayoría de estas capacidades “adaptadas a dispositivos” son tecnologías probadas en batalla que se incorporan a Windows Server desde Azure (donde se han estado ejecutando durante algún tiempo), por lo que no tiene que preocuparse tanto por la conversión su infraestructura a software de última generación. Voy a esperar y ver eso, pero lo nuevo es cómo se configurarán y administrarán. Eso sucederá a través del nuevo controlador de red WS2016, que suena como una consola que toca la bocina, un nuevo rol de servidor o probablemente ambos.

Con el controlador de red, tendrá control total sobre su implementación de SDN, con la capacidad de controlar no solo las características de su red IP (incluidos los firewalls, balanceadores de carga y su puerta de enlace de Windows Server), sino también las capas de la estructura Hyper-V, y incluso el rendimiento del servicio a través de la redirección inteligente del tráfico.

En general, si es un administrador de TI empresarial, esto suena interesante. Pero el cínico que hay en mí se preocupa cada vez que alguien me dice: “No te preocupes, tu linda cabeza, déjame ocuparme de eso”. Hay mucha complejidad que está siendo enmascarada por una capa de lógica virtualizada, de línea de comandos y de código pesado. McSpirit y Hynes lo describieron como una nueva tendencia que reducirá la necesidad de solucionar problemas. No estoy muy seguro. Según mi experiencia, parece que simplemente cambiará la solución de problemas de los cables y las luces parpadeantes a una línea de comandos, y al PowerShell antes mencionado y cada vez más inevitable.

Además, si bien proteger las máquinas virtuales con BitLocker es un gran paso, me gustaría escuchar mucho, ¡mucho !, más sobre las mejores prácticas de seguridad cuando se trata de proteger el controlador de red. En este momento, alguien podría comprometer mi red y apoderarse de partes de ella, incluso partes importantes. Pero con este esquema de controlador de red, parece que podrían tomarlo todo, incluso varias redes si estoy usando el controlador de red para controlar más de una estructura. Son muchos huevos para una canasta de Microsoft. Coloréame impresionado por la visión, pero aún no convencido por la realidad.

Obviamente, hay mucho más en WS2016 que he tenido que pasar por alto, como soporte virtual para acceso directo a memoria remota (RDMA), automatización mejorada, dulzura adicional para Linux, acceso web PowerShell y más. Afortunadamente, McSpirit y Hynes publicaron un montón de enlaces útiles (ver más abajo), incluida la descarga de TP3 que le permitirá explorar WS2016 más a fondo. Voy a descargar algunos tutoriales de PowerShell ahora.

Para obtener más información sobre WS2016 TP3, consulte los siguientes enlaces de recursos: Descarga de evaluación de Windows Server 2016 TP3, Guías de experiencia del cliente para TP3, Tutorial de MSDN sobre contenedores de Windows, Resumen de TechNet TP3, Introducción a PowerShell Direct y Videos de Channel 9 Storage Spaces Direct.