Sobre Clusters de Hyper-V y clusteres virtuales

Hola

Hoy toca hablar de cluster. Lo cierto es que el término es a veces un poco confuso, porque se refiere a un grupo de diferentes máquinas trabajando juntas por alguna razón determinada. En éste artículo de la Wikipedia creo que se explica muy bien, y distingue entre clústeres de Alta Disponibilidad (HA clusters), clústeres de balanceo de carga (Load Balancing clusters) y clústeres de computación (Grids)

En particular, en el mundo Microsoft existen tres tecnologías diferentes para cada uno de estos tipos de clustering. Dos de ellas están incluidas en Windows Server, y la otra en una edición especial. Ésta es una presentación al respecto, un poco arcaica ya, pero es mía :-)

  • Failover Cluster: Conocido también como MSCS o de almacenamiento compartido. Se utiliza para dotar de alta disponibilidad por tolerancia a fallos de servicios que por lo general tienen una dependencia del almacenamiento. Ejemplos de esto serían bases de datos, buzones de correo, máquinas virtuales, etc.
  • Clústeres de NLB (Network Load Balancing): Pensados para dotar de alta disponibilidad por tolerancia a fallos y escalabilidad a servicios de red. El ejemplo más frecuente son granjas Web o de Terminal Services. Se asume que todos los frontales tienen la información que sirven a los clientes correctamente replicada o en un repositorio central o back-end (generalmente este en Failover Cluster).
  • Clústeres HPC o de High Performance Computing: A "grosso modo" un nodo cabecera recibe un trabajo que paraleliza entre los diferentes nodos de computación, y estos le devuelven los resultados de vuelta para componer el resultado total. Esto se usa generalmente para hacer sumas y restas de esas que con una calculadora resultaría extremadamente tedioso realizar.

Todos y cada uno de estos tipos de cluster tienen algo que ver con el mundo de la virtualización. Todos pueden montarse en un entorno puramente virtual allí donde tenga sentido hacerlo (Clústeres virtuales, NLB entre VMs, o nodos de HPC virtuales), y los hosts físicos de Hyper-V pueden funcionar tanto con Failover Clustering como con NLB, si bien esto último es raro y me costaría imaginar algún entorno en el que fuera aplicable.

En adelante nos vamos a centrar únicamente en Failover Clustering y su relación tanto con los hosts de hyper-V como con las VMs que montemos encima. Distinguimos entonces:

  • Host Clustering: de 2 a 16 nodos con Hyper-V funcionando conjuntamente de modo que las Máquinas Virtuales puedan pivotar entre ellos, según sea necesario:
    • Bien por una caída no planificada del Host que la alberga. En este caso la VM reiniciará en alguno de los hosts del cluster automáticamente
    • Bien de manera manual o automática, por un mantenimiento planificado del host, o porque queramos redistribuir de forma diferente las cargas de trabajo entre los nodos del cluster. Esto es lo que hoy en día conocemos por Quick Migration, y en Windows Server 2008 R2 podremos hacer también con Live Migration.
  • Guest Clustering: Esto se refiere a un Failover Cluster en el que los diferentes nodos del mismo son máquinas virtuales corriendo en Hyper-V. Rizando el rizo puedes tener guest clustering en HA, es decir que las VMs que componen el cluster virtual, estén albergadas a su vez en un host cluster de Hyper-V

Vamos a tratar de aclarar las dudas más frecuentes que suelen surgir sobre todo esto:

Host Clustering

Creo que esto se entiende fácilmente simplemente diciendo que es la combinación de la característica (role) de Hyper-V y la funcionalidad (feature) de Failover  Cluster incluidos en Windows Server 2008 x64 Enterprise y Datacenter. La configuración hardware más típica para montar esto consiste en:

  • Almacenamiento compartido (típicamente SAN, con Fiber Channel, iSCSI o SAS, aunque este tipo de tecnologías proliferan). Muy importante en este punto y en lo que sigue: Windows Server 2008 NO SOPORTA Failover Clustering usando el tradicional bus SCSI
  • De 2 a 16 servidores que tienen la capacidad de acceder a un cierto numero de LUNs expuestas a todos ellos por el almacenamiento compartido
  • Dos o tres subredes diferentes para gestión, acceso publico y heartbeat.

Por suerte, puedo ahorrarme el hacer un paso a paso de la creación de un cluster de Hyper-V porque abundan. Si que creo que es importante referenciar la documentación que considero "autoritativa" para ello:

Para los interesados en probar esto y que no cuenten con este tipo de sistemas de almacenamiento compartido, queda la friki-opción de usar uno o varios File Shares (y si ya nos queremos complicar aún más la vida, que sean por NFS). Todo esto, y mucho más, está detallado en este post de mi compañero José Barreto. De hecho él tiene publicado un post mucho mas curado que éste que estas leyendo, y que se titula Windows Server 2008 Hyper-V Failover Clustering Options.

Un tipo particular de Failover Clusters son los clústeres geográficamente dispersos, multi-site clusters o GeoClusters. Y están de moda. Espero poder dedicar algún tiempo a dar más detalles sobre ellos (aprovechando que Dani Matey, con nocturnidad y en compañía de otros, hace poco que ha estado montando un par de ellos en sendos clientes de esos cuyo nombre conocemos sin excepción todos los españolitos). Mientras tanto, vayan por delante algunas consideraciones:

  • Estrictamente hablando, el almacenamiento debe estar replicado en las diferentes localizaciones. La idea es que el sitio físico donde reside el almacenamiento no sea un punto único de fallo.
  • El Failover Cluster de Windows Server 2008 ha sido rediseñado a nivel de almacenamiento y red para soportar este tipo de entornos. En particular sus modelos de quorum permiten una arquitectura del almacenamiento "shared nothing", en la que la replicación de la información se realiza por algún medio más o menos ajeno al cluster. En un extremo tendríamos las soluciones tipo Database Mirroring, Log-shipping etc. (como la de los clústeres CCR de Exchange 2007) y en el otro la pura replicación hardware. En este último caso hay que tener en cuenta una máxima de cajón. La velocidad de la replicación debe ser mayor o igual que la velocidad a la que el nodo escribe datos en el almacenamiento.
  • Debe existir un componente software que medie entre el cluster y el almacenamiento para decidir en que sentido debe realizarse la réplica, y tomar la acciones necesarias en caso de fallo o movimiento manual de los recursos.
  • La arquitectura de Hyper-V le hace agnóstico de toda esta película. Mientras que en el otro nodo el almacenamiento sea a todos los niveles idéntico, todo lo que espera Hyper-V es que alguien le presente los ficheros necesarios para continuar moviendo la máquina virtual.
  • Esta solución es cara. Y hay quien pregunta por algo similar, pero sin el coste asociado. Existen diferentes soluciones de replicación de datos a nivel software (podríamos imaginar, solo imaginar, una replicación de datos a base de robocopys :-) ), pero dudo muchas de ellas lleguen a cumplir todas y cada una de las condiciones anteriores. Por tanto, se parecerán mucho más a una solución de backup que a un geocluster. Y en estos casos conviene preguntarse quién y como garantiza la consistencia de los datos copiados. Prometo investigar.

Para hacernos una idea de soluciones de este tipo, he aquí una lista, que francamente no he repasado y no sé cuantas de ellas pueden aplicar a Hyper-V y Windows Server 2008.

Guest Clustering

Llegados a este punto, cabe preguntarse acerca de la necesidad o no de montar un cluster virtual. Por un lado, si el failover cluster se inventó principalmente para proteger a las cargas de trabajo ante un eventual fallo del hardware físico, y no solamente ya no tenemos hardware físico que se rompa sino que además ese "hardware virtual" se puede beneficiar de las tolerancia a fallos del host de virtualización que lo sustenta, ¿que ganamos?. Si la VM ya tiene alta disponibilidad, ¿para que rizar el rizo?. Pero por otro, ¿quien nos defiende ante un fallo que suceda a nivel de sistema operativo o aplicación dentro de la máquina virtual?. Y además, si tengo clusteres físicos en producción, ¿por qué no beneficiarme de las ventajas de la virtualización en los entornos de pre-producción y pruebas y desarrollo equivalentes?. Resumiendo, el "host clustering" de VMs reduce pero no elimina la necesidad de usar "guest clustering".

Antes de meternos a ver cómo se montan en Hyper-V, es conveniente repasar la manera en que hace en Virtual Server y en otras soluciones de virtualización. En esos entornos se emular una controladora SCSI que soporte bus sharing (la Adaptec 7870 para mas señas en el caso de Virtual Server, y en otros casos LSI, BusLogic, etc.), y que, en resumidas cuentas, pueda realizar las operaciones descritas en este artículo de la Knowledge Base. Pues bien, el diseño del Failover Cluster de Windows Server 2008 se lleva a cabo teniendo en cuenta las necesidades de los modernos entornos de almacenamiento compartido, y no soporta más el tradicional bus SCSI. Me sorprendería mucho que alguien montara un cluster virtual de Windows Server 2008 (que efectivamente funcione, no que termine el el proceso de configuración) usando las controladoras emuladas arriba citadas.

La controladora SCSI que se usa en Hyper-V no es una emulada sino sintética, es decir, no es una implementación software de una ninguna controladora SCSI que exista o existió en el mercado. Y no soporta bus sharing, lo que la hace incapaz de soportar un cluster de Windows 2000 Server o Windows Server 2003. Mis sospechas (personales) es que si el clustering a través de SCSI no se soporta en Windows Server 2008, simplemente no se ha invertido en este sentido en la controladora SCSI sintética de Hyper-V.

¿Cómo se hace pues un cluster virtual en Hyper-V?. Pues a través de una tecnología bien soportada en Windows 2000, 2003 y 2008. Usando iSCSI. Para ello necesitamos dos piezas:

  • El iSCSI Initiator en el sistema operativo de la máquina virtual. Windows Server 2008 lo lleva de serie, y para Windows 2000 SP4 y Windows 2003 se puede descargar de aquí.
  • Almacenamiento que sea capaz de exponer sus LUNs mediante iSCSI o un "iSCSI Target" por software. Muchas de las cabinas modernas soportan tanto Fiber Channel con iSCSI, y hay también servidores de especializados de almacenamiento que exponen su almacenamiento a través de iSCSI. Tal es el caso de Windows Unified Data Storage Server 2003 (Windows Server Storage Server 2003 R2), que incluye una evolución de Wintarget que comercializaba String Bean Software.

Esto tiene bajo mi punto de vista una ventaja y un inconveniente. La ventaja es que el almacenamiento se le presenta directamente a la VM, y solo nos tendremos que preocupar de optimizar las tarjetas de red virtuales y las del host físico, ya que obviamente estamos encapsulando comandos SCSI sobre Ethernet lo que debe ser tenido en cuenta a la hora de dimensionar la solución. El inconveniente es que a fecha de hoy el almacenamiento iSCSI no es tan frecuente como el Fiber Channel, y los buenos iSCSI targets gratuitos escasean. En este sentido creo que vamos a asistir en los próximos años a la competencia entre la fibra y el cobre también en el campo del almacenamiento.

Bueno, menudo ladrillo. Y lo peor es que tengo la sensación de dejarme un montón de cosas en el tintero. Espero que al menos a alguien le resulte aclaratorio.

Saludos

David Cervigón