Microsoft, su tecnología y yo

El Blog de David Cervigón (Microsoft)

Sobre Clusters de Hyper-V y clusteres virtuales

Sobre Clusters de Hyper-V y clusteres virtuales

  • Comments 19
  • Likes

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
  • Joermasho... qué pedazo de post. Yo de mayor quiero ser como tú...

    Enhorabuena por el curro, muy logrado el post.

  • 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.

  • Gracias Josep

    Miguel Angel, esto casi segudo de que con esa familia cabina puedes hacer tanto host como guest clustering

    Saludos

  • Muy oportuno.

    ¡Muchas Gracias!.

  • Buen post y muy interesante el tema.

    Te mereces un cordero en condiciones ;)

    Saludos,

    Dani

  • Una pregunta tonta ... Si tenemos un cluster HA de Hyper-V con dos máquinas físicas, ¿las máquinas virtuales pueden correr en los dos nodos a la vez aprovechando el hardware, o uno de ellos tiene que estar en standby a la espera que el otro caiga?

    Estoy buscando info, pero no lo veo especificado en ningún lugar.

    La idea seria si tenemos 10 máquinas virtuales, que 5 corran en cada nodo, y si uno cae, pues que el otro absorva la carga de las 10 VMs.

    Gracias por la ayuda

    Sergi

  • 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

  • Hay un problema con los clústeres de Windows Server 2008.

    Si el disco de sistema está "reflejado", "espejado", es decir, en RAID-1, la herramienta de validación del cluster falla miserablemente con el error 234.

    Hay un montón de información en la web sobre éste tema, te pego una conversación en technet:

    http://social.technet.microsoft.com/forums/en/winserverClustering/thread/e26d2004-8da2-4546-9142-b36795466b0d/

    ¿Alguna forma de resolverlo sin tener que romper el espejo?

    No encuentro nada en la KB....

    Gracias,

    Andrés.

  • 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

  • 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?

  • 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

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

  • 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

  • Hola

    Con P4 y 1 GB poco margen de maniobra tienes.

    PCs con NT SP2... ¿Eso realmente sigue funcionando? :-)

    Saludos

  • 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

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment