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.
Failover clustering
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.
Cluster OS Rolling Upgrade
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.
Stretched clusters
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.
SMB Multichannel
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.
Hyper-V
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.
Shielded Virtual Machines
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:
- Salvaguardar nuestras VMs, forzando que solo se ejecuten en la infraestructura que designemos y
- Proteger esas VMs de administradores que hayan visto comprometida su seguridad.
Estas ventajas se obtienen mediante dos mecanismos:
- Uno de cifrado del disco y del estado de las máquinas virtuales, con lo cual solo un administrador de la máquina o del tenant puede accederla.
- Y otro a nivel del fabric (host Hyper-V) mediante una nueva característica de Windows Server llamada Host Guardian Service. HGS comprueba si el host tiene permitido ejecutar la máquina blindada a través de unas mediciones de certificación de arranque y de hardware junto con una nueva característica de integridad del código que permite determinar si un host cumple con los criterios necesarios para poder ejecutar la máquina blindada.
 |
 |
Production checkpoints
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:
- Standard checkpoints. Los de siempre, capturan el estado de la máquina y la configuración del hardware y están pensados para usarse en entornos de desarrollo y test. Son de utilidad si necesitamos recrear un estado o condición específica de una máquina virtual. Ya sabemos que estos checkpoints generan un disco diferencial que va creciendo con cada cambio además de que necesitan pausar la máquina durante un determinado tiempo para capturar la memoria lo que puede provocar microcortes. Es por ello que no está recomendado para entornos productivos.
- Production checkpoints. Son imágenes completas de un momento determinado de una máquina virtual, que pueden ser restauradas en cualquier momento y que están completamente soportadas para cualquier workload productivo. Esto se consigue mediante tecnología de backup creando el checkpoint desde dentro de la propia máquina, en lugar de utilizar la tecnología saved state de los Standard checkpoints. No existe ninguna pausa de ejecución y se pueden utilizar a discreción sin impactar en el rendimiento. Este tipo de checkpoint no guarda el estado de la memoria.
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.
Nested virtualization
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.
Storage réplica
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.
Just Enough Administration
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:
- Reducir el número de administradores en las máquinas, mediante cuentas virtuales que pueden realizar acciones privilegiadas en lugar de utilizar usuarios normales.
- Limitar que puede hacer un usuario, especificando que cmdlets, funciones y comandos externos puede ejecutar.
- Conocer mejor que están haciendo nuestros usuarios, mostrándonos exactamente que comandos ha ejecutado un usuario durante una sesión.
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
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.
Containers
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:
- Windows Server Containers. Nos proporcionan aislamiento de aplicación mediante una tecnología de aislamiento de procesos y espacios de nombres, compartiendo el kernel con todos los contenedores que se ejecuten en el host.
- Hyper-V Containers. Incrementan el aislamiento proporcionado por Windows Server Containers ejecutando cada contenedor en una máquina virtual (muy optimizada, eso sí). En este tipo de contenedor el kernel del host no se comparte con el resto de Hyper-V Containers.
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í.
Infraestructura como código
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:
- PowerShell Direct. Nos permite ejecutar PowerShell dentro de una máquina virtual desde el host de Hyper-V sin necesidad de configuración de red, firewall, o gestión remota. Si alguna vez has necesitado ejecutar un script dentro de una máquina virtual, además de las credenciales necesarias, debías de tener configurada la gestión remota además de tener visibilidad por red a la misma. PowerShell Direct es una alternativa a las herramientas existentes para conectarse a una máquina virtual (Remote Desktop, VMConnect) y que agiliza la capacidad de scripting y automatización. Quizá la única pega es que para que funcione la máquina tiene que estar corriendo en el mismo host desde donde se ejecuta el comando y que por supuesto esté iniciada.
- Pester. Es el framework para PowerShell. Proporciona un lenguaje para definir casos de test y el comando Invoke-Pester para ejecutar esos test y obtener un informe de los resultados. (https://blogs.technet.microsoft.com/heyscriptingguy/2015/12/15/getting-started-with-pester/)
- PSScriptAnalyzer. Nos proporciona un análisis del código de nuestros scripts PowerShell para detectar defectos de código en base a unas reglas. (http://www.powershellgallery.com/packages/PSScriptAnalyzer)
- PowerShell Gallery. Otra de las grandes novedades, un gran repositorio con scripts que han pasado los test anteriores y que podremos utilizar simplemente instalando el módulo con un comando. La galería contiene tanto scripts como recursos DSC. Además, todos ellos están publicados en GitHub desde donde se revisan y actualizan proporcionando un método ágil y basado en OpenSource para solventar problemas en los mismos y desde donde bebe directamente PowerShell Gallery.
- PowerShell ISE también ha sido mejorado con capacidades de debugging.
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.
Nano Server
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:
- Private Cloud Infrastructure, incluyendo tanto clústeres de Hyper-V como de almacenamiento (Scale-out File Servers).
- Cloud Application Platform, para la construcción de aplicaciones modernas, ligeras, rápidas, basadas en microservicios y contenedores.
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.
Laboratorio
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.
Configuración inicial
Este laboratorio requiere que tengamos algunos conocimientos básicos de virtualización y necesitaremos los siguientes prerrequisitos:
- Un equipo físico (sobremesa o portátil) con al menos 8 GB RAM (y al menos 4 GB libres de RAM)
- Windows 10 actualizado
- Rol Hyper-V instalado y funcionando
- Una máquina virtual corriendo en el Hyper-V con una instalación básica de Windows Server 2016 TP5 (se puede descargar una imagen aquí)
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.
[su_box title=»PowerShell»]Invoke-WebRequest https://raw.githubusercontent.com/Microsoft/Virtualization-Documentation/master/hyperv-tools/Nested/Enable-NestedVm.ps1 -OutFile Enable-NestedVm.ps1 [/su_box]
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.
[su_box title=»PowerShell»]Get-VM[/su_box]
Ejecutamos el script añadiendo correctamente el nombre de la máquina virtual donde queremos habilitar la virtualización anidada.
[su_box title=»PowerShell»]Enable-NestedVm.ps1 -vmName «WS2016 TP5″[/su_box]
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.
Imagen personalizada de Nano Server
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:
[su_box title=»PowerShell»]Import-Module .\NanoServerImageGenerator -Verbose[/su_box]
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:
[su_box title=»PowerShell»]New-NanoServerImage -Edition Standard -DeploymentType Guest -MediaPath <path to root of media> -BasePath .\Base -TargetPath .\NanoServerVM\NanoServerVM.vhd -ComputerName <computer name> -Package <name of package>[/su_box]
Básicamente modificaremos 2 parámetros:
- MediaPath. Es la ruta al DVD montado en la máquina virtual con la ISO de Windows Server 2016
- ComputerName. El nombre que queremos dar a la máquina.
- Package. Nombre de los paquetes que queremos agregar a la imagen base. Ver la lista incluida en el DVD de WS2016 dentro de la carpeta packages.
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:
- Name: NanoWeb1
- Generation: 1
- Startup memory: 1024
- Desmarcar uso de memoria dinámica
- Connection: utilizar un Virtual Switch conectado a una red accesible con DHCP y acceso a internet (se puede configurar después)
- Utilizar un disco VHD existente, buscando el que hemos creado en el paso anterior.
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:
[su_box title=»PowerShell»]Enter-PSSession -VMName <virtual machine name>[/su_box]
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.
Resumen
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.
Enlaces de interés
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/
//
