Clústeres Virtuales (guest clustering)
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:
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:
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:
- Starwind, de RocketDivision
- El simulador de Data ONTAP de NetApp (solo para pruebas)
- Microsoft iSCSI Target, integrado en los appliance OEM que usan Windows Storage Server o Windows Unified data Storage Server. Existe una versión de evaluación en https://microsoft.download-ss.com (enlace directo aquí)
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
Comments
Anonymous
January 01, 2003
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 SaludosAnonymous
January 01, 2003
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 SaludosAnonymous
January 01, 2003
The comment has been removedAnonymous
January 01, 2003
The comment has been removedAnonymous
January 01, 2003
The comment has been removedAnonymous
January 01, 2003
Gracias Josep SaludosAnonymous
April 18, 2009
The comment has been removedAnonymous
November 08, 2009
Estimado, muy bueno el post, en próximas versiones de hyper-v se soportara cluster virtuales con FC?Anonymous
October 14, 2010
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.Anonymous
October 21, 2010
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.Anonymous
March 04, 2012
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.