La versión final de Windows Server 2016 será liberada a finales del mes de septiembre, no obstante, en la última preview pública (TP5) se dejan ver y probar la mayoría de novedades que vendrán con la versión final. Será una versión rara por cómo se libera ya que, a diferencia de las anteriores, no irá acompañada de la versión cliente del sistema operativo. Como profesional especialista en datacenter y virtualización os mostraré las características más importantes que traerá Hyper-V asi como otras novedades relacionadas con DevOps, open source y seguridad. Y como siempre me gusta que mis publicaciones sean didácticas os propongo un pequeño laboratorio sobre Nano Server donde probaremos varias de las novedades que os he comentado.
La característica de failover es la base de cualquier entorno de virtualización productivo. Nos permite alta disponibilidad de nuestras máquinas virtuales y flexibilidad en el datacenter. Veamos qué mejoras nos trae.
Esta característica viene a solucionar el problema de actualizar nuestros clústeres. En la última actualización Microsoft nos facilitó pasar de Windows Server 2012 a 2012 R2 gracias a Live Migration, ya que podíamos migrar workloads desde un cluster 2012 a unos 2012 R2 sin pérdida de servicio, aunque se hacía necesario disponer de hardware y almacenamiento adicional. En versiones anteriores era incluso necesario realizar una parada de las máquinas virtuales en el proceso de migración.
Mediante Cluster OS Rolling Upgrade podremos ir añadiendo nuevos hosts de Windows Server 2016 a nuestro clúster de Windows Server 2012 R2 siguiendo un proceso secuencial de drain, evict, upgrade, add y resume de cada nodo, actualizando nuestro clúster de Hyper-V o Scale-out File Server sin necesidad de paradas, clúster secundario, hardware ni almacenamiento adicional. Sin duda una gran ayuda en el proceso de adopción de una nueva versión del server.
El strech clustering es una característica de Windows Server 2016 que nos permite configurar máquinas y almacenamiento en un único clúster donde algunos de los nodos comparten un conjunto de almacenamiento y otros nodos comparten otro conjunto, los cuales están sincronizados mediante Storage Réplica. Dependiendo de la latencia, esta sincronización puede ser síncrona o asíncrona. Esto nos permite disponer de un sistema de alta disponibilidad geográfica que es muy sencilla de configurar ya que para ello utilizaremos el mismo administrador de clústeres de Windows Server.
La simplificación de SMB Multichannel. Es una característica que ya estaba presente en la versión anterior de Windows Server y que nos ayuda a alcanzar un ancho de banda gigante (10 GiB, 40 GiB o más) pero que ahora es capaz de reconocer y configurar automáticamente múltiples NICs que estén en la mismasubnet consiguiendo que el diseño y la configuración de SMB Multichannel sea muy sencillo. Como vemos en la siguiente imagen el uso de múltiples NICs nos permite alcanzar el mayor ancho de banda posible entre un clúster de Hyper-V y el clúster de almacenamiento.
Será automático y estará habilitado por defecto, eso significa que todas las NICs serán usadas para heartbeat, tráfico CSV y de clúster. Además, también se utilizará IPv6 de forma automática en redes privadas para solo clúster (tarjetas dedicadas). Sin duda una ayuda a la hora de diseñar clústeres de alto rendimiento que sean capaces de aprovechar las ventajas del equipamiento de red más moderno.
En la parte de computación virtual las novedades son importantes. Más allá de las mejoras esperadas en cuanto a rendimiento, disponibilidad, estabilidad, etc., tenemos otras que resuelven problemas o necesidades que los usuarios hemos ido solicitando los últimos años.
La virtualización nos hace la vida más fácil, no es ninguna novedad, la facilidad de crear y ejecutar múltiples máquinas virtuales en un mismo host, moverlas de forma rápida y sencilla y destruirlas con tan solo un clic de ratón o un comando. Por supuesto, esto también tiene una desventaja, cualquier usuario con acceso al host de virtualización tiene la capacidad de poder “robar” esas máquinas con tan solo copiarlas en un pendrive y ejecutarlas en su casa donde podrá campar a sus anchas para acceder a información sensible y nadie sabrá que ha sucedido esto porque la máquina original seguirá corriendo en el datacenter corporativo.
Este problema lo tienen todos y cada uno de los hipervisores existentes en el mercado: VMware, Hyper-V, Xen, KVM, etc. El cifrado es parte de la solución, basta con añadir un TPM virtual en cada máquina virtual para poder cifrarlas, pero seguimos teniendo el problema de que un administrador comprometido o malicioso tendría la capacidad de descifrar la máquina y realizar la operativa anteriormente explicada.
WS 2016 viene a cubrir este problema con máquinas virtuales blindadas permitiéndonos:
Estas ventajas se obtienen mediante dos mecanismos:
![]() |
![]() |
Hasta ahora el uso de checkpoints (lo que toda la vida hemos conocido como snapshots) en entornos productivos era algo prohibitivo o con un uso muy limitado a casos de intervención puntual. Esto es debido a la forma en que se ejecutaban estos checkpoints. Con WS 2016 tendremos dos tipos de checkpoints:
Los production checkpoints se habilitan por defecto para cualquier máquina virtual nueva, aunque se puede configurar el tipo de checkpoint por defecto para cada máquina individualmente.
La virtualización anidada es una característica muy interesante. Básicamente nos permite utilizar una máquina virtual como host de Hyper-V y poder crear máquinas virtuales dentro del host virtualizado. En principio es una funcionalidad que está pensada para entornos de desarrollo y test. El uso de Hyper-VContainers es otro caso de uso.
Lo hemos introducido como parte de los Streched clusters. Storage Replica ofrece una nueva forma de recuperación antes desastres para nuestros datos. Por primera vez, Windows Server ofrece la capacidad de sincronizar datos entre diferentes racks, plantas, edificios y ciudades. Tras un desastre todos los datos siguen intactos sin ninguna posibilidad de pérdida. Storage replica soporta tres escenarios (en TP5): stretch cluster, cluster-to-cluster, server-to-cluster.
![]() |
![]() |
![]() |
Además, estos tres escenarios soportan sincronización tanto síncrona como asíncrona por lo que podremos desplegar los mismos sobre escenarios con alta latencia de red. Por defecto, se utiliza sincronización síncrona.
Con respecto a la seguridad tenemos una novedad que han llamado JEA (Just Enough Administration), una tecnología de seguridad que permite la delegación de permisos para cualquier acción que pueda ser realizada con PowerShell. Esta tecnología nos permitirá obtener los siguientes beneficios:
Esta granularidad de permisos es muy importante sobre todo en entornos donde tenemos consolidados más de un servicio en la misma máquina y no queremos que un administrador de un servicio tenga permisos para modificar otros. Un ejemplo típico sería un servidor controlador de dominio que además tiene el servicio DNS, en este escenario podríamos tener un rol administrador de DNS que tenga acceso a todos los comandos relacionados con DNS pero que no pueda ejecutar comandos de Directorio Activo.
JEA no es una novedad exclusiva de Windows Server 2016 sino que viene integrada en el Windows Management Framework 5.0 por lo que está disponible tanto en Windows Client (7, 8, 8.1) y Windows Server (2008 R, 2012, 2012 R2) instalando la versión 5 del framework.
DevOps es un concepto que ya no nos es ajeno y está cada vez más extendido en pequeñas y grandes empresas. Si bien hace ya años que se habla y se trabaja con metodologías ágiles en el ámbito del desarrollo, tenemos que asumir que también debe existir una “operación ágil”. DevOps es el término que utilizamos para esta unificación de tendencias ágiles, y, si bien, DevOps está más orientado a procesos y colaboración entre grupos de personas, WS 2016 viene cargado con novedades que nos ayudarán a implementar una TI ágil. Y que puede ser más ágil que poder desplegar aplicaciones en contenedores o definir la infraestructura que necesito mediante código.
Quizá la novedad más llamativa y directamente heredada del mundo Linux. Los contenedores se basan en una serie de características del kernel de Linux que permiten generar capas de abstracción y virtualización a nivel de sistema operativo. Básicamente estos contenedores se ejecutan de forma independiente dentro de una misma instancia de Linux evitando la sobrecarga de iniciar y mantener máquinas virtuales completas. En este escenario es donde Docker aparece, que es la tecnología que permite explotar estos contenedores de una forma sencilla (existen otras como OpenVZ o LXC que han tenido un menor éxito). WS 2016 viene con la capacidad de contenerización y con soporte para Docker.
Como hemos adelantado los contenedores son entornos operativos (no llegan a ser sistema operativo completo porque comparten el kernel con el host), son portables, aislados y con recursos controlados. Vamos, prácticamente como máquinas virtuales, pero sin la carga de proceso del hipervisor. Básicamente es un lugar aislado donde se ejecuta una aplicación sin afectar al resto del sistema u otros contenedores. Podemos hablar de una evolución de la virtualización.
En WS Server 2016 podremos generar dos tipos de contenedores:
Llegados a este punto podemos pensar que existen muchas similitudes entre un contenedor y una máquina virtual pero la tecnología y los conceptos detrás de los contenedores son muy distintos a los de la virtualización clásica. Es importante señalar que los dos tipos de contenedores son totalmente compatibles con la tecnología Docker (Docker CLI, API REST, etc.). Los contenedores tienen material para una entrada dedicada, así que de momento dejémoslo aquí.
Otra de las “patas” que proporciona agilidad en metodologías DevOps es la capacidad de definir infraestructura como código. El concepto de Infrastructure as Code o IaC es similar a programar scripts, normalmente utilizados para automatizar tareas de TI, solo que no se trata de crear pasos estáticos que se deban repetir a lo largo de un determinado número de servidores. En IaC se suele utilizar un lenguaje de alto nivel o descriptivo para crear procesos de provisión y despliegue más versátiles y adaptativos. Existen numerosas soluciones que permiten hacer esto (Chef, Puppet, Ansible) aunque tratando sobre el sistema operativo de Microsoft hablaremos de PowerShell DSC.
Con PowerShell DSC podremos controlar las necesidades del core de una infraestructura (computación, almacenamiento y redes). PowerShell ha realizado un salto cuantitativo y cualitativo en su última versión. Las principales novedades son:
Todas estas herramientas y funcionalidades al final son facilidades a la hora de implementar metodologías DevOps donde PowerShell DSC cobra una relevancia obvia y donde otras tecnologías de virtualización provenientes del open source tienen ahora cabida sobre tecnología Microsoft.
Windows Server 2016 ofrece un nuevo tipo de instalación: Nano server. Nano en el Sistema internacional indica un factor 10-9. Con este prefijo ya podemos adivinar que trata de ofrecernos Microsoft con este “sabor” de Windows Server: una versión mínima del servidor.
Muchos pensarán que ya existía la versión Core donde se eliminaba la interfaz gráfica, pero nano va un poco más allá, entremos en detalle.
Estamos hablando de DevOps, y Nano Server tiene mucho que ver. DevOps implica rapidez, agilidad, flexibilidad. Mediante PowerShell tendremos la capacidad de desplegar y configurar una máquina virtual con Nano Server en apenas 40 segundos, cuando una versión completa puede llevarnos varias decenas de minutos e incluso algunas horas. Esto es posible porque a la versión Core le han eliminado lo siguiente: soporte 32 bit, GDI y todo el soporte gráfico, Remote Desktop y Winlogon.
Esto hace que una imagen Nano sea 25 veces más pequeña que una versión completa de Windows Server con escritorio. Todo esto se traduce en un aumento del rendimiento, de la velocidad de arranque, reducción de número de parches a instalar, además de que estamos reduciendo la superficie de ataque exponiendo solo lo mínimo y necesario. Es por ello que Nano será una gran baza a jugar en entornos de DevOps, sobre todo para las fases de desarrollo y test donde la volatilidad es mayor.
Personalmente creo que Nano Server tendrá su hueco en el datacenter corporativo. De hecho, veo dos escenarios donde Nano Server aplica de manera clara:
No obstante, las posibilidades son amplias, por ejemplo, servidores DNS, servidores web corriendo IIS o Apache o pequeños servidores de base de datos con MySQL.
Este tipo de escenarios hacen que no sea para nada necesario disponer de un escritorio o de establecer conexiones RDP que ensucien la máquina virtual (ya sabéis que cada administrador que se conecta a un server va dejando su “huella”). Para ello tenemos herramientas que podremos instalar en servidores o clientes Windows con escritorio completo desde donde podremos administrar nuestros workloads. Cada vez soy más de la idea de que cualquier servicio que tengamos desplegado debería estar automatizado y ser repetible evitando realizar tareas manuales en los servidores.
Con el fin de que esta entrada no sea un mero recopilatorio de novedades de tecnología vamos con un pequeño laboratorio sobre Nano Server donde desplegaremos un servicio sobre una máquina virtual con Nano Server montada sobre un Windows Server 2016 virtualizado en un Windows 10. Parece un trabalenguas así que mejor vayamos al grano.
Este laboratorio requiere que tengamos algunos conocimientos básicos de virtualización y necesitaremos los siguientes prerrequisitos:
El primer paso que vamos a realizar es habilitar la virtualización anidada (Nested Virtualization) con el fin de que podamos instalar el rol de Hyper-V en esta máquina virtual. Para ello la forma más fácil es correr un script PowerShell que configurará automáticamente los requisitos adecuados. Abrimos una consola de PowerShell con permisos de administrador y con el siguiente comando descargaremos automáticamente el script desde GitHub.
El siguiente paso es obtener un listado de las máquinas virtuales que están corriendo mediante el cmdlet Get-VM para conocer el nombre de nuestra máquina virtual.
Ejecutamos el script añadiendo correctamente el nombre de la máquina virtual donde queremos habilitar la virtualización anidada.
Como se observa, el script muestra el estado actual de la máquina virtual y pide habilitar aquellas funciones necesarias para la virtualización anidada. Hay algunas como la memoria que son opcionales y que en este caso no se ha cambiado.
Con todo esto ya podemos volver a iniciar la máquina virtual e instalar el rol de Hyper-V sin problemas, lo cual haremos como siempre, con PowerShell o desde el Server Manager.
Nos pedirá un reinicio y ya estaremos preparados para continuar con nuestro laboratorio.
El siguiente paso es crear una imagen personalizada de Nano Server. En este laboratorio crearemos una muy básica que contenga el rol IIS para que podamos publicar una web.
Para ello debemos utilizar la ISO de Windows Server que deberíamos tener descargada en la configuración inicial y la montamos en la máquina virtual. Accediendo a la unidad DVD virtual veremos que existe una carpeta llama NanoServer. Copiamos la carpeta NanoServerImageGenerator a una carpeta local de la máquina virtual y ejecutamos el siguiente comando desde la carpeta recién copiada:
Mediante un cmdlet vamos a crear un VHD donde configuraremos un nombre para la máquina y además incluiremos los drivers de Hyper-V:
Básicamente modificaremos 2 parámetros:
La ejecución del comando anterior da como resultado la siguiente salida:
Con ello obtendremos en la ruta .\NanoServerVM\NanoServerVM.vhd un VHD listo para ser lanzado por Hyper-V. Bastará con crear una nueva máquina virtual en nuestro Hyper-V anidado y agregar este disco VHD como primario o, por supuesto, podemos automatizarlo mediante un script.
Creamos una nueva máquina virtual siguiendo el asistente de Hyper-V. En este laboratorio utilizaremos los siguientes parámetros:
Con todo esto ya podemos iniciar la máquina virtual. Veremos que el arranque es muy rápido y que el disco VHD está en torno a los (ridículos) 500 MB. Para conocer la IP tendremos que conectarnos con la consola de Hyper-V y nos aparecerá una consola con fondo negro donde nos solicita un usuario y contraseña. El usuario por defecto es administrator y la contraseña ya nos la pidió durante el proceso de creación de la imagen Nano Server:
Nos aparece la siguiente pantalla:
Seleccionamos Networking, y la única ethernet existente. Si el DHCP es accesible veremos que nos ha dado una IP:
Si necesitamos configurar una IP manualmente podremos hacerlo pulsando F11.
Ahora si introducimos la IP en el navegador de nuestra máquina host veremos que nos muestra la web por defecto de IIS:
A continuación, y como paso final vamos a utilizar la característica de PowerShell Direct que nos permite acceder remotamente a la máquina virtual sin necesidad de configurar puertos, redes ni administración remota.
De nuevo desde una consola PowerShell con permisos elevados ejecutamos el siguiente comando:
Por supuesto nos pedirá las credenciales de administración de la máquina virtual. En nuestro ejemplo el resultado es el siguiente:
Con este sencillo cmdlet ya estamos dentro de la máquina virtual y no nos ha hecho falta decirle ninguna IP ni configurar el acceso remoto dentro de la máquina virtual. Y podremos modificar los artefactos de nuestra web o crear nuevos sites usando comandos PowerShell. Existe una guía online disponible Technet con todo lo relacionados con la administración de IIS en Nano Server.
Hemos llegado al final de este pequeño repaso de lo que considero algunas de las novedades más interesantes de Windows Server 2016. Por supuesto, existen muchas más que evitaré abordar ahora para no extenderme demasiado, pero al final de esta entrada os comparto algunos links interesantes.
Como resumen hacer foco de nuevo en la orientación DevOps y open source. Entiéndase este foco con los guiños de Microsoft hacia Linux, con el tema de contenedores, la reciente consola bash de Ubuntu para Windows, y los repositorios que utilizará Nano Server para añadir funcionalidad (find-packageprovider). Windows Server 2016 será de gran ayuda para construir un datacenter moderno, proporcionando agilidad, integridad, eficiencia, y en definitiva a implementar una TI ágil.
Con respecto al laboratorio, es un pequeño test de características nuevas como son Nano Server, PowerShell Direct, virtualización anidada, etc. Espero que os haya gustado y os haya picado el gusanillo de Nano Server y lo que puede ofrecer.
Como siempre, cualquier comentario podéis hacérnoslo llegar a info@kabel.es y seguidnos en Linkedin.
Todo sobre la TP5 de Windows Server 2016:
https://technet.microsoft.com/en-us/windows-server-docs/get-started/windows-server-2016-technical-preview-5
Introducción a los contenedores en Windows Server 2016:
https://msdn.microsoft.com/en-us/virtualization/windowscontainers/containers_welcome
Blog dedicado a Nano Server:
https://blogs.technet.microsoft.com/nanoserver/
//