Microsoft, su tecnología y yo

El Blog de David Cervigón (Microsoft)

Clústeres Virtuales (guest clustering)

Clústeres Virtuales (guest clustering)

  • Comments 11
  • Likes

Hola

Como continuación del post en el que hablaba sobre clústeres de Hyper-V (host clustering) y clústeres virtuales (guest clustering), aquí van un par de diagramas de como quedaría una solución con “guest clustering” sobre un host clustering, que, salvo por aspectos puntuales, es válido para cualquier plataforma de virtualización. Si lo quieres reutilizar y te viene bien el Visio original, no dudes en contactar conmigo.

A modo de resumen de aquel post, las controladoras SCSI virtuales que introduce Hyper-V en la máquinas virtuales no nos sirven para montar un bus de almacenamiento compartido apropiado para clustering, ni para Windows Server 2003 ni para Windows server 2008, por lo que cualquier intento de usar VHDs o discos Pass-Through conectados simultáneamente a cualquier controladora virtual de una VM montada en Hyper-V será en vano. Decíamos también que tanto Virtual Server 2005 como diversos productos de vmware emulan en las máquinas virtuales unas controladoras SCSI que si son válidas para formar clústeres de Windows Server 2003, pero que en el caso de Windows Server 2008 solo se soporta Fiber Channel , iSCSI o SAS como bus compartido para un Failover Cluster, con lo que en este caso tampoco nos vale la clásica estrategia. En resumidas cuentas, que el futuro del “guest clustering” con sistemas operativos Microsoft pasa por el uso de iSCSI.

Esto plantea una ventaja y un inconveniente. La ventaja es que el almacenamiento se le presenta a las máquinas virtuales que conforman los nodos del cluster directamente sin pasar por los host de virtualización. La desventaja es que no todo el mundo dispone de almacenamiento que sea capaz de utilizar iSCSI, si bien esto parece que es una tendencia que va a más, a medida de que nos vamos dando cuenta de que habíamos descartado las capacidades del cobre antes de tiempo. Luego volveré sobre este punto.

Este es el esquema de una solución basada en tres hosts que conforman un cluster, sobre el que se albergan un cierto número de servidores virtuales, dos de los cuales forman un cluster virtual:

Clusteres Virtuales

Como se puede observar, los hosts están conectados a la SAN a través de diferentes fabrics de fibra y ethernet, a la que se conectan a través de sus HBAs y NICs (dedicadas). Desde las cabina se presentan un cierto numero de LUNs a los nodos. Las que serán específicas de cada nodo se presentan individualmente, y las que se usarán como almacenamiento compartido del cluster se las presentamos a todos. En estas últimas almacenaremos los VHDs de nuestras máquinas virtuales, aunque alguna puede incluso tener asociada su propia LUN por razones diversas, o porque se vaya a usar en pass-through.

Para formar el almacenamiento compartido del cluster virtual, presentamos desde la cabina los volúmenes que vayamos a necesitar a través de iSCSI. Una vez hecho esto, configuramos los “iSCSI Initiators” del sistema operativo de la máquina virtual para que se conecte al target de la cabina y monte los volúmenes que se les han asignado. Este es el detalle de cómo queda el cluster virtual:

Clusteres Virtuales-detail

Los nodos virtuales en este caso se comportan exactamente igual que lo haría un cluster físico que se montara con iSCSI, y por tanto, se deben seguir las mismas recomendaciones para su configuración. Necesitaremos una par de NICs virtuales para atender a los clientes y para el heartbeat (no represento su conectividad), y es conveniente dedicar una NIC virtual para iSCSI. También sería una buena idea dedicar switches virtuales en el host para conectar a los switches físicos que nos conectan con la cabina.

Como decía, hay muchas ocasiones en las que no tenemos una cabina que “hable” iSCSI, o simplemente en las que no tenemos almacenamiento compartido. Tanto para simular entornos de producción como por mero aprendizaje, es interesante montar tanto clústeres físicos como clústeres virtuales. En ese caso, ¿como nos las apañamos?.

Existe un buen número de Targets iSCSI por software e incluso emuladores de SAN (OpenFiler, OpenNAS, FreeNAS, etc.), que se pueden montar tanto en físico como en virtual. Encontrar uno no nos garantiza el poder formar un cluster de Windows Server 2008 (aunque si 2003), porque muchos de ellos implementan un target NetBSD/FreeBSD que a fecha de hoy no soporta SCSI-3. Tampoco he probado los targets que implementan algunos *nix (SUSE, OpenSolaris, etc.)

Entre los que sé que funcionan (ejemplo 1, ejemplo 2), se encuentran:

Después de releer este ladrillo, no sé si esto será aclaratorio o si simplemente aumenta vuestro nivel de confusión. Espero que no.

Saludos

David Cervigón

Comments
  • Gran post David!!

    Muy aclaratorio. Creo que si es un poco ladrillo (largo) es porque la cuestión lo merece. No se puede hablar de algo tan complejo como un clúster virtual con fundamento y resumirlo en tres líneas.

    Enhorabuena por el curro del Visio!

    Un abrazo

    Josep Ros

  • Gracias Josep

    Saludos

  • hacer más para entender acerca de un esquema de imagen gracias por tu artículo

  • Estimado, muy bueno el post, en próximas versiones de hyper-v se soportara cluster virtuales con FC?

  • Para eso habría que crear una HBA emulada o sintética, y jugar con puertos de fibra físicos y virtuales para que la VM no dependiera de la HBA física del host.

    No sé exactamente qué se hará, pero todo esto, al margen de la discursión de si realmente merece la pena virtualizar un cluster en producción, hace pensar que iSCSI seguirá siendo un excelente manera de trabajar con clusteres virtuales.

    Lo que no se va a hacer es volver atrás en el soporte al viejo SCSI en los clusteres por parte del sistema operativo. Presentar la LUN de fibra al host y conectarla a una SCSI emulada ya no es viable para guests posteriores a 2003

    Saludos

  • thanks hacer más para entender acerca de un esquema de imagen gracias por tu artículo

  • Hola,

    una cuestión al respecto de la configuración de red para host/guest clustering en 2008R2.

    Al configurar un host clustering es recomendable tener nics dedicadas para redes específicas de

    iSCSI, Cluster/CSV y LiveMigration. En el caso de guest clustering se me plantea la duda de que

    tendríamos que crear un virtual switch externo contra esas nics para "replicar" esa misma

    configuración en los nodos invitados, o tener más nics dedicadas (que no compartan con el host).

    Creo que la segunda opción seria la óptima, pero claro estamos hablando que si las

    configuraciones ideales de número de nics para host clustering están entre 4 a 8 nics dedicadas;

    en el caso de implementar la configuración host/guest clustering estaríamos hablando del doble.

    La pregunta sería si es aceptable utilizar la primera opción donde cada nic se comparte entre el

    host y el guest o directamente buscaría una solución para llegar a la aproximación segunda donde

    las nics son dedicadas.

    Saludos.

  • Hola

    Pues tienes varias opciones, y como bien dices, depende del numero de nics que puedas dedicar. Ten en cuenta que en el esquema de arriba no estamos teniendo en cuenta otra variable, que es el multipath, donde a nivel de host usaríamos al menos dos NICs físicas.

    Si luego además queremos usar dos NICs adicionales como switches virtuales para que cada VM tenga dos vNICs dedicadas para iSCSI también con multipath, pues ya tendríamos 4 NICs dedicadas a estos menesteres.

    Al final no hay mejor ni peor si no se analizan recursos disponibles vs. requerimientos de la solución. Hay que ver anchos de banda que se van a consumir, ver si al final todo va a terminar pasando por el mismo switch físico o no, si tanta tolerancia es realmente necesaria....

    En nuestro laboratorio todo va con dos NICs, y todo el almacenamiento es iSCSI. Una NIC es vSwitch y la otra es red interna (HB+LM+CSV) y ademas soporta el tráfico iSCSI. Cuando una VM necesita almacenamiento iSCSI va con una IP/VLAN de la red iSCSI, pero sale por la NIC que es vSwitch. Otra opcion sería convertir ambas NICs en vSwitches, con dos vNICs para la particion padre, y segmentar totalmente el tráfico "LAN" y el iSCSI. Pero como todo sale por el mismo chasis de blades y el ancho de banda no parece superar por ahora ninguna de las NICs Gb, pues nos hemos decantado por lo anterior

    Cuando no hay de donde sacar...

    Saludos

  • Cada host tiene 1 tarjeta de red con dos puertos, pero se le presentan al host 8 nics independientes (utilizando la tecnología Flex10 de HP). Según esto creo que debería tener montado 3 teams para conectar las redes de Producción, Hearbeat+Cluster y CSV/LM; y las otras dos tarjetas para iSCSI con multipath. De esta forma cada red tiene redundancia en cada puerto de la tarjeta física. Luego cada puerto del Flex10 irá a switches independientes.

    Por cierto tengo 3 VLANs disponibles: Producción, Cluster e iSCSI.

    La cuestión es que si queremos que las VMs puedan montar guest clustering entonces esas 3 teams + 2 nics iSCSI deberían configurarse como vswitches compartidos con el host. El host si puede utilizar MPIO, pero las VMs deben utilizar MCS ya que no tienen un driver nativo para MPIO.

    También tengo la opción de montar un team en iSCSI para atacar el almacenamiento, lo he probado y funciona. Además el almacenamiento (HP Lefthand) tiene dos ips independientes, y una virtual de un cluster que monta. De esta forma te ahorras MPIO y ya el team y la lefthand se encarga de balancear el tráfico.

    Qué te parece la aproximación?

    Gracias y saludos.

  • Es bastante aclaratorio, pero hay que conocer bien este tipo de instalaciones para enterarse del todo.

    Lo único que no me queda claro si por ejemplo un OpenFile funcionaria, pero tampoco es el motivo del artículo.

    Gracias y saludos.

  • Hola

    Necesitamos que este soportado SCSI-3 por el tema de las reservas persistentes. Por lo que parece en Openfiler estan trabajando para que se soporte

    forums.openfiler.com/viewtopic.php

    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