Primeras impresiones: 8 horas con Windows Server 2016 vista previa técnica 3 | Oliver Rist

En una semana tumultuosa marcada por millones de cónyuges sudando la fuga de Ashley Madison, y Dios extendiéndose para hacerle cosquillas a Google con no menos de cuatro rayos, Microsoft lanzó silenciosamente la Vista previa técnica 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 analicé dos seminarios web exhaustivos de 4 horas en Windows Server 2016 presentados a principios de esta semana por Matt McSpirit, Gerente Técnico Superior de Mercadeo 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 (¡Hola, tengo una vida!).

Primero lo primero: estas sesiones fueron largas pero extremadamente valiosas, cubriendo toda la novedad histórica 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 sesión, demostraciones y enlaces de recursos. Entonces, si WS2016 está en su radar, recomiendo verlos.

Contenedores de Windows Server

En cuanto a las características importantes: Sin duda, la gran noticia 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 Redmondites, los contenedores son viejas noticias para los desarrolladores y quizás 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, ¿quién necesita contenedores? Bueno, tal vez tu.

La mejor manera en que puedo pensar para conceptualizar contenedores es como una instantánea de un estado específico del sistema operativo subyacente que puede bifurcar y ejecutar por sí mismo. Entonces, por ejemplo, podría girar un contenedor basado en una instancia básica de WS2016, agregar una aplicación lista para contenedores, ajustar con ciertas configuraciones o permisos, y luego guardar todo el shebang para recuperarlo siempre que 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 sistema operativo independiente y se comportarán de esa manera cuando se activen, siempre que el sistema operativo subyacente en el que se ejecutan tenga todas las características que Necesidades de contenedores. Esto no le brinda todo el aislamiento o la portabilidad de una máquina virtual completa, pero se escala mucho más rápidamente (piense 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á presentando "contenedores de Windows Server", así como "contenedores de Hyper-V" y, no, no son lo mismo. Microsoft implementó contenedores completamente en la capa del sistema operativo, lo que significa que puede instalar un sistema operativo host físico y construir contenedores a partir de eso (contenedores de Windows Server), pero también implementó contenedores en la capa de hipervisor Hyper-V. Entonces, ahora puede tener un sistema operativo de nivel de máquina que ejecute Hyper-V y luego construir contenedores en una VM alojada en esa caja, o dos o más.

De hecho, podría hacerlo dos veces, en efecto, anidando hipervisores: el Servidor A que ejecuta Hyper-V que aloja una VM que aloja un montón de contenedores junto con otra VM que también ejecuta Hyper-V que aloja otro montón de contenedores. ¿Por qué? Los Microsoftees no fueron muy claros en eso, excepto para decir que un contenedor de Hyper-V perderá un poco en el departamento de consolidación de recursos al obtener capacidades de aislamiento, así que piense en escenarios especializados de alojamiento y multiinquilino.

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

Nano Servers: aún más virtualización mini-me. Piense en una máquina virtual de estilo Windows Core que contiene solo los bits necesarios para realizar su función específica. Se compilan rápidamente y, dado que solo llevan consigo el código que necesitarán, pueden ejecutarse en menos de 200 MB en lugar de en el espacio de 3 a 4 GB + de una máquina virtual 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 básicos de la estructura (ver más abajo). La desventaja es que no pueden actualizarse o modificarse una vez configurados y ni Microsoftee sabía cuál sería el plan de licencias para estas instancias, aunque ambos sospechaban que no habría una nueva licencia mini-me, solo una etiqueta de precio de servidor estándar. Solo otro empujón para que salgas a la edición de 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 Hyper-V utilizando BitLocker, almacena las claves en un bosque de AD confiable y crea una relación de confianza entre el bosque de VM y el bosque clave (y me refiero a bosque, no a dominio). Esto protege las máquinas virtuales blindadas contra el robo, la inspección o cualquier tipo de manipulación, aunque aparentemente requerirá hardware verificado por logotipo en el lado del servidor que necesita tener silicio Trusted Platform Module (TPM) y usar la Interfaz de firmware extensible unificada (UEFI).

Actualizaciones sin tiempo de inactividad: Bueno para aquellos que 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 se pueden actualizar a WS2016 sin necesidad de desactivar un servicio. La demostración se realizó de forma manual y en gran medida 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 solo un montón 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 clúster de nada compartido".

Sistema de archivos resilientes (ReFS): no es nuevo, pero definitivamente ha madurado en WS2016, con aumentos significativos de rendimiento disponibles para operaciones de administración como fusiones.

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

PowerShell inevitable

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

Y, basándose en la naturaleza de casi todas las demostraciones mostradas durante esas ocho horas de sesión, no está bromeando. Es cierto que estamos en TP3, por lo que habrá mucha más compatibilidad con la interfaz gráfica de usuario (GUI) por disponibilidad general (GA), pero pruebe algunas de estas características usted mismo y verá eso, incluso si obtienen una superposición de GUI en el futuro, fueron diseñados en gran medida con PowerShell en mente. Microsoft va todo con los conceptos de DevOps y todo lo definido por software, y PowerShell es el eje de esa estrategia. Si la descripción de su trabajo involucra la administración de un número significativo de máquinas con plataforma Windows (servidores o dispositivos cliente) y realmente desea conservar ese trabajo, bueno, siga el ejemplo de Hynes: abróchese el cinturón y aprenda PowerShell, ahora.

Afortunadamente, realmente es una tecnología poderosa. Al usar PowerShell, McSpirit y Hynes administraron la automatización sobre la marcha, configuraron y pusieron en funcionamiento 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 VM que sufrían interrupciones de red al iniciar sesión y ejecutando comandos de PowerShell a través del bus VM. Lo que me lleva al próximo cambio de juego para mí después de mis ocho horas de observación de 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 el rol del servidor Virtual Network Gateway. En WS2016, todo esto 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 por eso". 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 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 gestionar 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 ha conectado en sus bastidores de conmutadores hoy: firewalls, enrutadores, inteligentes interruptores y equilibradores de carga, por nombrar algunos. McSpirit señaló que la mayoría de estas capacidades "adaptadas al dispositivo" son tecnologías probadas en batalla que se llevan a Windows Server desde Azure (donde han estado funcionando durante algún tiempo), por lo que no tiene que preocuparse tanto por la conversión su infraestructura para software novedoso. 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 de 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 firewalls, equilibradores de carga y su Puerta de enlace de Windows Server), sino también sus capas de estructura Hyper-V, y incluso el rendimiento del servicio a través de la redirección de tráfico inteligente.

En general, si usted es un administrador de TI de la empresa, todo esto suena emocionante. Pero el cínico en mí se preocupa cada vez que alguien me dice: "No te preocupes por tu linda cabeza, déjame encargarme de eso por ti". Hay una gran cantidad de 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 pintaron como una nueva tendencia que reducirá la necesidad de solucionar problemas. No estoy muy seguro. Según mi experiencia, parece que simplemente cambiará la resolución de problemas de cables y luces intermitentes a una línea de comando, y el PowerShell mencionado anteriormente y cada vez más inevitable.

Además, aunque 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 tomar partes de ella, incluso partes grandes. 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éeme 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 varios 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.