Alta disponibilidad con Hyper-V

A la hora de considerar las opciones de alta disponibilidad asociadas a los escenarios de infraestructuras virtualizadas usando la tecnología Microsoft Hyper-V 2008 R2, debemos tener en cuenta dos enfoques:

i) Alta disponibilidad del servicio de virtualización: como ocurre con cualquier otro servicio, del que puedan depender sistemas en producción para empresas, la alta disponibilidad de los servidores de Hyper-V y de los servicios de virtualización, entendida como la obtención del mayor nivel posible de continuidad en el servicio, puede llegar a ser una necesidad.

Aspectos determinantes de la alta disponibilidad en general, tales como tiempos de recuperación ante fallos, duplicidad de componentes, hardware tolerante a fallos, sustitución de elementos en caliente o clústeres, son totalmente aplicables a los servicios de Hyper-V.

ii) Alta disponibilidad usando virtualización: en este segundo enfoque lo que se trata es de aprovechar la tecnología de virtualización para aumentar el grado de disponibilidad de otros servicios, es decir, se usa la virtualización como una estrategia para conseguir alta disponibilidad de sistemas.

Al instalar sistemas de producción en máquinas virtuales se consiguen unos mejores tiempos de respuesta ante fallos, ya que restaurar una máquina virtual es mucho más sencillo que restaurar un sistema físico, al no existir dependencias del hardware, y al estar toda la información incluida en un único fichero de disco duro virtual (vhd).

Además clusterizar máquinas virtuales es mucho más sencillo, versátil y sobre todo económico, que clusterizar sistemas físicos, aunque sigue existiendo la necesidad de utilizar almacenamiento profesionales dedicados.

 Clúster de servidores de virtualización (Hyper-V)

Cluster failover es una característica de Windows Server 2008 R2 que permite configurar un grupo de equipos independientes para que trabajen juntos aumentando el nivel de disponibilidad de aplicaciones y servicios. Los sistemas que forman parte del cluster failover se denominan nodos, y están interconectados tanto físicamente (por cables) como lógicamente (por software).

Si uno de los nodos del clúster deja de responder otro se encargará de ejecutar los servicios del nodo caído, de tal manera que los usuarios experimenten el menor tiempo posible de parada en el servicio.

En el caso de los servicios de virtualización de infraestructuras de Hyper-V hablamos de Hyper-V host clustering, que en esencia es un failover cluster de Microsoft en el cual los nodos ejecutan el rol de Hyper-V.

El Hyper-V host cluster se consigue mediante la configuración en clúster de varios servidores físicos con Hyper-V instalado.

Los servidores usarán un almacenamiento en red de tipo SAN (Storage Attached Network), sobre el cuál se definirán los servicios que se quieren clusterizar, en este caso máquinas virtuales.

Figura 1.- Hyper-V host failover cluster antes del fallo

En la figura 1 podemos ver como el servidor HyperV-1 utiliza una LUN (LUN 2) de un almacenamiento de tipo SAN para albergar el disco duro (D1.vhd) de una máquina virtual (partición hija).

Si el servidor Hyper-V1 deja de estar operativo la máquina virtual D1 también dejaría de estar accesible, pero puesto que Hyper-V1 e Hyper-V2 se han configurado en failover cluster para el servicio de Hyper-V, el servidor Hyper-V2 automáticamente procederá a retomar el servicio de la máquina virtual D1.

Figura 2.- Hyper-V host failover cluster después del fallo

Para ello en la figura 2 se observa como el servidor Hyper-V2 tiene una configuración idéntica de acceso al almacenamiento compartido, con lo cual el servicio de la máquina virtual continúa, aunque ahora desde otro servidor físico, lo cual en principio es transparente para los usuarios de los servicios alojados en la máquina virtual.

Ambos servidores estaban configurados de forma idéntica, y tenían acceso a la misma información (almacenada en la SAN), pero sólo uno de ellos usaba la configuración y los datos para ejecutar el servicio (máquina virtual). Tras el fallo es el otro servidor el que pasa a ejecutar el servicio.

 Clúster de servidores virtuales

Aunque entre las ventajas del uso de máquinas virtuales se encuentra una mayor estabilidad derivada de la independencia del hardware, y mejores tiempos de respuesta ante los fallos que se puedan producir, derivados en parte de la fácil portabilidad de las máquinas virtuales, cualquier servidor virtualizado en producción está expuesto, como cualquier otro tipo de servidor, a caídas de servicio por problemas internos: corrupción del sistema operativo, fallos de aplicaciones, virus...

El hecho de que el servidor de virtualización que ejecuta estas máquinas virtuales este clusterizado no va a resolver el problema, ya que cuando en el segundo servidor se levante la misma máquina virtual esta va a seguir sin poder dar servicio, ya que el problema era interno a la propia máquina virtual.

Para conseguir alta disponibilidad en este escenario se requiere de lo que se denomina clúster de invitado, o guest clustering.

En esencia el guest clustering no es más que la aplicación de las tecnologías failover cluster de Microsoft para diversos servicios de red (ficheros, impresoras, web, bases de datos...) cuando dichos servicios en vez de estar ejecutándose en servidores físicos, que es lo habitual en Microsoft failover clustering, se están ejecutando en servidores virtualizados con Hyper-V.

Figura 3.- Hyper-V guest failover cluster antes del fallo

En este caso son los servidores virtuales, definidos en las particiones hijas de ambos servidores de Hyper-V los que tienen configurados los accesos al almacenamiento compartido.

Cada partición hija tiene su propio sistema Windows Server 2008 R2, y ambos se han configurado en failover cluster. El almacenamiento asociado a los datos y configuración de las aplicaciones clusterizadas está en las LUN definidas en ambos servidores virtuales, aunque sólo está en uso por uno de los servidores virtuales a la vez, exactamente igual que ocurriría si el failover cluster se hubiera definido sobre servidores físicos.

Figura 4.- Hyper-V guest failover cluster antes del fallo

Este escenario de failover cluster de servidores virtuales también puede implementarse sobre un único servidor físico, aunque evidentemente en este caso si se produce un fallo del servidor de Hyper-V el clúster de servidores virtuales no serviría de nada.

Figura 5.- Hyper-V guest failover cluster con un sólo servidor físico después del fallo

Nota: existe una diferencia fundamental entre el failover cluster aplicado a servidores físicos y el failover cluster aplicado a servidores virtuales, y es que en el segundo caso la característica failover clustering sólo es compatible con almacenamientos SAN basados en protocolo iSCSI. En el caso de servidores físicos también se admiten los protocolos de conexión a redes SAN FC (Fibre channel) y SAS.