Hyper-V R2 - Alta disponibilidad con Host Cluster

En este pequeño articulo quisiera compartir mi experiencia en la implementación de Hyper-V R2 para sistemas en ambiente de producción.  En ningún caso se pretende conseguir un manual de instalación infalible, sino una guía que los oriente para conseguir implementar un ambiente de virtualización robusto y que ofrezca alta disponibilidad.  En su momento me fue difícil encontrar documentación adecuada para conseguir este objetivo y con este articulo espero poder aportar a quienes estén dando sus primeros pasos en esta tecnología.

En el marco de la implementación de una plataforma SharePoint 2007, y tomando en consideración la nueva política corporativa de consolidación y virtualización de servidores, comencé a evaluar las distintas alternativas con las que trabajamos.

Por un lado tenia VMWare ESX 3.5 y por otro Hyper-V.  Todos los puntos se los llevaba VMWare por lejos, pero estaba el tema costos, lo cual es un tema importante cuando se trabaja con VMWare.  Por otro lado Hyper-V hasta ese momento no contaba con buenas características de Alta Disponibilidad, comparable con un Cluster HA de VMWare y VMotion, que entregara protección ante fallas de Hardware en el Host.

En eso estaba cuando fue lanzado Windows Server 2008 R2, con un Hyper-V totalmente mejorado, incluyendo nuevas características como LiveMigration y Cluster Shared Volume (CSV), que lo acerca bastante a las funcionalidades que VMWare incluye desde hace unos años. 

Características de Hyper-V

Hyper-V soporta una arquitectura de alta disponibilidad en Failover Clustering y en NLB.  En este articulo nos centraremos solo en Failover Clustering.

Hyper-V soporta Failover Cluster tanto a nivel de Host (host cluster), como a nivel de Guest (guest cluster)

En el caso de Host Cluster, Microsoft soporta de 2 a 16 nodos con Hyper-v funcionando conjuntamente de modo de poder mover las maquinas virtuales de un nodo a otro según se requiera:

-       Caída no programada de un Host Hyper-V, ya sea por una falla de Hardware o Software.  En este caso la maquina virtual será movida automáticamente a otro nodo del cluster.

-       Migración manual o automática por mantenimiento programado de algún Host, o simplemente para distribuir carga entre los host (Aquí hecho de menos una funcionalidad como DRS de VMWare).

Respecto al Guest Cluster, se refiere a un Failover Cluster en el que los diferentes nodos que lo componen corresponden a maquinas virtuales sobre Hyper-V.  Para lograr esto se requiere conexión iSCSI, Fiber Channel no esta soportado para funcionalidades de Guest Failover Cluster.

Luego nos encontramos con Cluster Shared Volume, que nos permite compartir un único volumen o LUN, entre 2 o más host Hyper-V, pudiendo ser accedidos por todos los nodos del Host Cluster simultáneamente.

Finalmente, nos encontramos con Live Migration, funcionalidad comparable con VMotion de VMWare, que nos permite hacer migraciones “en caliente” de una maquina virtual, de un host a otro, sin provocar perdida de servicio o datos en la maquina virtual (Excepto cuando se produce una falla en el Host que provoque su apagado o reinicio, en cuyo caso la migración de la maquina virtual se realiza con la funcionalidad Quick Migration).

Mas detalles de las diferencias entre Live Migration y Quick Migration y sobre su funcionamiento lo pueden encontrar en el siguiente sitio:

Hyper-V Live Migration vs. Quick Migration

Requisitos

Una vez tomada la decisión de trabajar con Hyper-V comenzó la tarea de preparar la plataforma para cumplir con los requisitos para su implementación.  A continuación un resumen de los requisitos mínimos para implementar un Host Cluster con Hyper-V

-       2 o más servidores para Hyper-V (Hasta 16 nodos son soportados), con una arquitectura lo más similar posible (idealmente idéntica), para evitar conflictos en los servidores virtuales al momento de una migración de un Host a otro.  Hyper-V requiere procesadores con arquitectura 64Bits.  En mi caso son 2 servidores Dell idénticos, con 4 sockets Intel Xeon Quadcore y 64GB en RAM c/u.

-       2 o más interfaces de red en cada host.  Idealmente se debe contar con una interfaz dedicada para Live Migration, una para la comunicación de las maquinas virtuales, una para la administración del servidor y una para comunicación iSCSI (si aplica).  En mi caso omito la interfaz para iSCSI ya que utilizaré conexión por Fiber Channel.

-       Acceso a un dispositivo de almacenamiento compartido, como una SAN, ya sea a través de iSCSI o Fiber Channel (Windows 2008 no soporta Failover Cluster usando el bus SCSI tradicional).  En mi caso una SAN EMC conectada por Fiber Channel.

Pasos de Instalación

Pre-Requisitos.

Se procede a instalar Windows Server 2008 R2 en todos los nodos del cluster.  Puede utilizarse la versión Enterprise o Datacenter, tanto en una instalación Full como en Server Core.  Todos los nodos deben tener la misma versión.

Se deben aplicar todos los parches de seguridad disponibles para el Sistema Operativo.

Se procede a configurar las interfaces de red para cada nodo.  En mi caso se configura las siguientes interfaces:

-       Interfaz de Administración

-       Interfaz para Maquinas Virtuales

-       Interfaz para Live Migration

Todos los servidores en el cluster deben estar en el mismo dominio Active Directory.

Se conectan los nodos al almacenamiento compartido (En mi caso una SAN EMC), y se crean las LUNs requeridas para el Cluster.  Cada LUN debe ser asignada a todos los nodos del Cluster, para que puedan acceder a su contenido.

Si en cada servidor se utiliza más de una conexión al almacenamiento compartido, para efectos de redundancia, se debe configurar el servidor para el manejo de múltiples Paths. La solución Multipath debe estar basado en Microsoft Multipath I/O (MPIO). En mi caso utilizo una herramienta del fabricante de la SAN, EMC PowerPath, para cumplir esta función.

A nivel de sistema operativo, las LUNs asociadas deben configurarse como Basic Disks, no Dynamics Disks.

Se recomienda formatear las particiones en formato NTFS.  Para el disco Witness esto es obligatorio.

Para las particiones se pueden utilizar Master Boot Record (MBR) o tabla de particiones GUID (GPT)

Se instala el rol de Hyper-V en todos los nodos del Cluster en la sección de roles de Server Manager:

Se instala la Feature Failover Cluster en todos los nodos del cluster, en la sección Features de Server Manager:

  

Configuración.

1.     1. Validación de la configuración.

Antes de que se pueda crear el cluster, se debe validar la configuración.  Se deben ingresar todos los servidores que formarán parte del cluster.

Se debe asegurar que se ejecuten todos los test disponibles, ya que la solución solo está soportada cuando se aprueban estos tests. 

Si la validación presenta Warnings, se puede continuar de igual forma con la instalación.  Si por el contrario la validación presenta errores, estos deben ser solucionados antes de proceder:

2.     2. Creación de Cluster.

Una vez que se haya pasado la validación, hacer click en la opción “Create a Cluster”.  Primero se deben seleccionar ambos nodos:

Luego se debe especificar el nombre virtual del cluster.  Este nombre debe haber sido registrado previamente en el servidor DNS.

Una vez confirmados los datos ingresados, se completa la creación del Cluster

Se puede ver la información del cluster abajo:

3.     3. Configuración de Red.

Una vez creado el cluster, se debe seleccionar una interfaz de red para ser usada como Live Migration:

También se debe configurar la interfaz a ser utilizada para las maquinas virtuales:

4.     4. Configuración de Almacenamiento.

Una vez creado el Cluster y configurada la red, se debe configurar los discos a ser utilizados en el cluster.  En mi caso se agregaron 2 LUNs para maquinas virtuales y una adicional a ser utilizada como disco Witness. 

Opcionalmente se puede cambiar la configuración del Quorum.  En mi caso dejé la configuración por defecto para la arquitectura que implementé, es decir “Node and Disk Majority”.

Para ver más detalles de las distintas configuraciones de Quorum, pueden ingresar en la siguiente pagina:

Windows Server 2008 Failover Clustering - The New Quorum Model

Para modificar la configuración del Quorum se elige la opción “Configure Cluster Quorum Settings” de las opciones del cluster:

A continuación se elige el tipo de configuración de Quorom a utilizar:

Luego se selecciona el disco a ser utilizado por el Quorum:

Se dejan las demás opciones por defecto y se finaliza la configuración, la cual queda de la siguiente forma:

La columna “Current Owner” muestra el nodo que esta utilizando actualmente el disco.  Para que todos los nodos puedan tener acceso simultaneo a los discos, se debe habilitar la función Cluster Shared Volumes.  Aun así, cada disco tendrá un Owner, pero podrá ser accedido por el resto de los nodos.

En la sección Cluster Shared Volumes se debe habilitar esta función:

Se deben agregar los discos que deberán ser accedidos por todos los nodos del Cluster.  La configuración quedaría de la siguiente forma:

Se pueden agregar mas discos a los Cluster Shared Volumes a medida que se van asignando más LUNs al cluster.

5.    5.  Validación de Cluster.

Finalmente, se recomienda ejecutar una validación del cluster para detectar posibles problemas de configuración.   Se deben ejecutar todos los tests disponibles.  Se debe tener especial cuidado de no ejecutar esta validación en un ambiente en producción, debido a que parte de los tests incluyen la desconexión y reconexión de los discos del Cluster, provocando así la caída de las maquinas virtuales que se ejecutan sobre el.

Pruebas del Cluster.

1.     1. Creación de maquina virtual de pruebas.

Para probar el cluster y sus funciones de Alta Disponibilidad, se debe crear una Maquina Virtual normal en uno de los nodos del Cluster.

La maquina virtual debe utilizar los discos del Cluster para almacenar los discos virtuales y su configuración.  La función Cluster Shared Volume crea un acceso directo en el disco C de cada nodo llamado “Cluster Storage”, el cual contiene cada uno de los volúmenes compartidos del Cluster.

En esta configuración los volúmenes no son visibles directamente a través de la interfaz de usuario del servidor.  Solo se puede acceder a ellos a través del acceso directo mencionado anteriormente.

2.     2. Configurando alta disponibilidad para la maquina virtual.

Una vez creada la maquina virtual, se debe configurar para las funciones de alta disponibilidad de Hyper-V.

Se debe entrar a la sección “Service and Applications” y seleccionar la opción “Configure a Service or Application”, donde aparecerá el siguiente asistente:

Aquí se debe seleccionar la opción “Virtual Machine”, luego de lo cual se debe seleccionar la maquina virtual a configurar:

Seleccionamos la maquina virtual creada y dejamos el resto de las opciones por defecto.

Una vez configurada la alta disponibilidad  para la maquina virtual, aparecerá de la siguiente forma.

En este punto podemos encender la maquina virtual desde esta ventana, o desde la consola de administración de Hyper-V.

Para evitar los pasos de habilitación de alta disponibilidad para cada maquina virtual que se crea, se puede utilizar Microsoft System Center Virtual Machine Manager para administrar las maquinas virtuales, el cual configura la alta disponibilidad en forma automática.

3.    3.  Moviendo una maquina virtual entre nodos.

Una vez configurada la alta disponibilidad, se pueden realizar pruebas de migración utilizando Live Migration.  En la consola Failover Cluster Manager, en la sección “Services and Applications”, se selecciona la maquina que se quiere migrar y se selecciona la opción “Live Migrate virtual machine to another node”, indicando el nodo al cual se quiere migrar:

Durante la migración la consola se verá de la siguiente forma:

Este proceso dura solo unos segundos, y depende de cuanta memoria tiene asignada la maquina virtual.

Para eventos de caídas de uno de los nodos, otro de los nodos del cluster tomará el control de las maquinas virtuales afectadas.  Se guardará el estado de estas maquinas y se moverán de nodo, donde se iniciarán nuevamente con un mínimo de downtime.

Conclusiones

En este punto ya tenemos habilitado un Cluster Hyper-V, con funcionalidades de alta disponibilidad utilizando Live Migration y Cluster Shared Volume.

La plataforma puede comenzar a ser utilizada creando nuevas maquinas virtuales para los servicios que se requieran, los cuales a la vez pueden formar un Guest Cluster o un NLB si así se requiere.

Para la administración de Hyper-V se pueden apoyar en System Center Virtual Machine Manager y en Data Proteccion Manager para efectos de respaldos. 

Al implementar una solución de virtualización se deben tomar todos los resguardos necesarios para asegurar la continuidad operacional, considerando que existirán múltiples servicios ejecutándose en un único servidor físico.

En próximos artículos hablaré de virtualización de SQL Server 2005 en alta disponibilidad y la implementación de SharePoint 2007 sobre Hyper-V utilizando Network Load Balancing (NLB).

Lecturas recomendadas

-       Design for a Failover Cluster in Which All Nodes Run Hyper-V 

-       Requirements and Recommendations for Failover Clusters in Which All Nodes Run Hyper-V

-       Checklist: Failover Cluster in Which the Servers Run Hyper-V

-       Step-by-Step Guide for Testing Hyper-V and Failover Clustering

-       Hyper-V Step-by-Step Guide: Hyper-V and Failover Clustering

Posted in: Alta Disponibilidad,Hyper-V,Windows 2008 R2