Freigeben über


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

Comments

  • Anonymous
    January 01, 2003
    Hola Como continuación del post en el que hablaba sobre clústeres de Hyper-V (host clustering) y clústeres

  • Anonymous
    January 01, 2003
    Hola Con P4 y 1 GB poco margen de maniobra tienes. PCs con NT SP2... ¿Eso realmente sigue funcionando? :-) Saludos

  • Anonymous
    January 01, 2003
    Hola Lo que quiere eso decir es que el fix se hará (o se ha hecho) para 2008 si alguien lo solicita vía soporte. Le he preguntado a Elden por el estado del tema. Mándame un correo y seguimos moviendo esto ya en privado Saludos

  • Anonymous
    January 01, 2003
    Hola Si, claro, puedes tener una configuración de dos nodos en activo-activo. Solo has de tener en cuenta que cada uno de los hosts pueda albergar solo toda la carga de trabajo que supone la suma de todas las VMs del sistema. Con clusteres de más nodos, las cargas se reparten entre los nodos restantes. Saludos

  • Anonymous
    January 01, 2003
    The comment has been removed

  • Anonymous
    January 01, 2003
    Hola Como dice mi compañero Elden en esa conversación, parece un bug confirmado. Hi, Thank you for the information, we've been able to reproduce internally and have confirmed it's a bug.  We plan to address this in the next release.  If this is a blocking issue for you and you need a hotfix for Win2008, please open a case with Microsoft Product Support Services. Thanks! Elden Poco más puedo aportar yo. Supongo que puedes excluir ese test del conjunto de validaciones del cluster, formarlo, y que funcione sin problemas. Saludos

  • Anonymous
    January 01, 2003
    Gracias Josep Miguel Angel, esto casi segudo de que con esa familia cabina puedes hacer tanto host como guest clustering Saludos

  • Anonymous
    December 17, 2008
    The comment has been removed

  • Anonymous
    December 18, 2008
    Muy bueno los post's. Quisiera saber para este tipo de montaje si las cabinas de iscsi de Dell Equallogic funcionan perfectamente y dan los recursos necesarios para este tipo de montaje. Un saludo y si no hablamos más, felices fiestas y prospero año nuevo.

  • Anonymous
    December 18, 2008
    Muy oportuno. ¡Muchas Gracias!.

  • Anonymous
    December 19, 2008
    Buen post y muy interesante el tema. Te mereces un cordero en condiciones ;) Saludos, Dani

  • Anonymous
    December 29, 2008
    The comment has been removed

  • Anonymous
    April 03, 2009
    The comment has been removed

  • Anonymous
    April 04, 2009
    Hasta ahí había leído yo (por eso puse el enlace), pero al final del hilo, si te fijas, alguien indica la (posible) existencia de un hot fix, que el soporte no quier/puede darle si no hay un KB... Bueno, me temo que el error también se presenta al agregar los discos compartidos al cluster. El problema está en el objeto de instrumentación de enumeració de los discos, que devuelve errores cuando el disco del sistema está en un espejo por software. No sólo pasa con la verificación de lo srequerimientos del cluster. ¿Puedes confirmar si esto se resuelve en R2? ¿Y si existe dicho hot fix?

  • Anonymous
    May 27, 2009
    Hola, no se si estoy fuera de onda, pero me gustaria que me aclararas, lo siguiente: -Hardware   - Server P4 con 1Gb Ram y 300gb en RAID 5   - Server P4 con 1Gb Ram y 250Gb en Raid 5 IDE   - 4 PC's entre 386 y pentium II Basicos -Software   - Windows Server 2008 Datacenter para los dos servidores   - Windows NT 4 SP2 para los 4 PC's Montage de dos granjas, un server y dos pc's mas un server y dos PC's, el control del cluster lo tiene windows server 2008. La pregunta es: Seria posible montar maquinas virtuales en la granja, optimizando los recursos del cluster o lo que intento es una utopia? Gracias

  • Anonymous
    May 27, 2009
    SI, sigue funcionando, y bastante bien me he de pelear montando los clusters pero voy saliendo, lo que más me interesa es la respuesta a la pregunta anterior. Saludos

  • Anonymous
    May 29, 2009
    Gracias, por las respuestas, os mantendre informados sobre el montage, asi mismo me estoy anotando los pasos que sigo para poder remitiros un tutorial, por si alguien esta interesado en este tipo de curiosidades. ;) Saludos

  • Anonymous
    April 30, 2011
    un favor debo arreglar la coneccion wi-fi de un portatil creo que son problemas del sistema operativo, lo que pasa es que este portatil cuenta con una licencia original de windows vista pero a el equipo lo formatiaron y le instalaron un sistema operativo que no se si es legal, ahora cual es mi pregunta ¿por medio de internet puedo instalar una version de windows teniendo en cuenta que este equipo en si tiene una licencia original pero no cuenta con disco?

  • Anonymous
    November 28, 2013
    Muy bueno todo , interesantes comentario . Saludos.

  • Anonymous
    September 29, 2015
    Muy buen comentario, me aclaro varias dudas