Nota Técnica: Microsoft Cluster Server en máquinas virtuales.

Nuestro amigo Jorge J. me remite la siguiente consulta:

"Soy un fiel seguidor de tu blog. Aquí en mi empresa, la virtualizión es algo que está en boca de todos y como no algún proyecto hay para medidados de Julio, que seguramente me tocará lidiar.
Tengo una pregunta para usted.

Es cierto que en el ESX 3.5 no se permite la clusterización de Microsoft¿? MSCS¿?. Entonces que sistema ESX me recomienda para ofrecer servicios en alta disponibilidad¿?.
Gracias y un saludo. "



He demorado la respuesta en espera del Update 1 de VI 3.5 ya que la limitación existente en VI 3.5 desaparece y VMware vuelve a ofrecer soporte para el Microsoft Cluster Service. Y ya puestos, aprovecho para escribir un poco sobre la clusterización Microsoft en entornos virtuales.



¿Cómo funciona un cluster MSCS?



Sin ánimo de describir en profundidad la tecnología MSCS, baste para los propósitos de este post el decir que provee los mecanismos necesarios para compartir un único almacenamiento entre varios servidores que ejecutan este servicio, pero no de modo simultáneo, sino que permite que los servidores se "pasen" o "cojan" el disco compartido bajo las demandas de disponibilidad de los servicios que albergan.



La gestión de la propiedad del disco se hace mediante el uso de tres características del protocolo SCSI2:

• reserve: Este comando es enviado por la controladora SCSI (ya sea FC, SCSI o iSCSI) para obtener o mantener la propiedad de un dispositivo SCSI, en este caso una LUN. Un dispositivo reservado denegará todos los comandos que envíe un iniciador distinto del que lo tiene reservado.
  


• release: Este comando será enviado por el host propietario de un recurso cuando ese recurso queda offline dentro del mismo, liberando la propiedad del dispositivo SCSI para cualquier otro nodo.
  


• reset: Este comando "rompe" la reserva de un dispositivo SCSI. El comando puede ocasionar un reset completo del bus (en el caso de que varios dispositivos estén situados sobre el mismo bus) o, mediante el uso del driver "storport.sys", el reseteo de un dispositivo individual.

Problemas de los entornos de cluster basados en Reservation SCSI2.

Windows Server 2008 substituye el uso del los comandos SCSI reservation de SCSI II por los nuevos Persistent Reservation del protocolo SCSI3. Como diferencia principal cabe destacar que ya no es necesario enviar un comando SCSI reservation reset cuando un nodo reclama un dispositivo SCSI porque su anterior propietario ha quedado fuera de línea.

Es precisamente el uso de SCSI Reservation Reset lo que ocasiona ciertos problemas con los cluster MSCS, ya que problemas de conexión con la LUN compartida (ya sea la SAN, el switch fiberchannel/iSCSI), etc, pueden ocasionar que un nodo del cluster (Nodo A) genere un timeout en el acceso a disco, lo comunique por el HeartBeat al otro (Nodo B), ocasionando un "balanceo" del cluster sin necesidad aparente. Si nuestra aplicación (un SQL server, por ejemplo), tiene afinidad por el Nodo A, tan pronto este nodo verifique que el problema ha desaparecido, indicará al nodo 2 que le devuelva la instancia SQL, forzando de nuevo un balanceo innecesario. Digo innecesario porque MSCS ha respondido tal y como se espera: IF Nodo A pierde el disco, THEN nodo 2 lo coge. Esto tan simple supone un bombardeo de peticiones SCSI reset (Nodo 2 cogiendo el disco de nodo 1), SCSI reservation (Nodo 2 toma el control de la LUN), SCSI release (Nodo 1 y pide a Nodo 2 que libere la LUN) y SCSI reservation (Nodo 1 toma de nuevo el control de la LUN). También puede darse (y de hecho hay escenarios donde se dá) en que la situación se repite varias veces... y observaremos un par de balanceos inesperados y en el visor de eventos un montón de errores de I/O... SQL, por su parte, hace lo que debe hacer: IF base de datos se pone en SUSPECT, THEN chequeo.

Como vemos, hemos disfrutado de un buen rato (y hasta de una pequeña pérdida de datos) debido a un movimiento entre nodos debido a una situación de NO indisponibilidad. No podemos culpar a MSCS de no predecir el futuro, y de iniciar un proceso de balanceo que durará (por ejemplo, 4 minutos) para prevenir una indisponibilidad de 85 segundos.

Este no es un problema exclusivo de MSCS o de Microsoft: ESX también presenta sus "cosillas" con las SCSI reservations, con consecuencias también poco agradables. Prometo hablar sobre ello.

Esta situación no es exclusiva tampoco de las máquinas físicas: Sólo un poco más difícil de sufrir que en entornos virtuales. Siempre es una buena práctica, recomendada incluso por Microsoft en algunos casos, el "subir" el tiempo de timeot mediante la alteración del valor HKEY_LOCAL_MACHINE\System\CurrentCOntrolSet\Services\Disk\TimeOutValue . Este valor controla el timeout que el sistema aplicará a los accesos a disco antes de reportar un error. Por contra... incrementa los tiempos de vuelta a disponibilidad de los recursos clusterizados ya que el cluster esperará más tiempo para verificar el error para iniciar el balanceo.

Estas situaciones se dan en SAN con mucho tráfico o con entornos de mucho I/O.

Quede claro que el uso de SCSI reservations siempre supone un factor de riesgo, y hay que tener en mente que su uso es un mal necesario.... sea cual sea el entorno.

Clusters bajo entornos virtuales.

Un entorno virtual "simula" un entorno físico... incluyendo las SCSI reservations. También sabemos que todo lo virtual es "algo" más lento que lo físico.... incluyendo las I/O de disco y comandos SCSI, así que es BASTANTE más posible que se den situaciones (cuello de botella, timeouts, etc) en las que una situación como la antes descrita se dé. De ahí la prudencia tanto de VMware como de los especialistas en virtualización en cualquier plataforma a la hora de recomendar e implementar soluciones de cluster basadas en reservas SCSI en máquinas virtuales.

VMware publica una guía de instalación de Microsoft Cluster Service en ESX. La podéis descargar de aquí y os recomiendo ENCARECIDAMENTE su lectura, junto con la guía de almacenamiento (que podéis descargar de aquí). Los problemas que pueden ocasionar una configuración inadecuada (ya sea por hardware, software VMware o software Microsoft) no son inmediatos, y pueden llevar pérdidas de datos asociadas.

VMware soporta tres tipos de configuraciones MSCS, que son las siguientes:

• Cluster in a Box: Clusterizado de máquinas virtuales dentro del mismo host.


• Cluster Across Boxes: Clusterizado de máquinas virtuales entre diferentes host.


• Standby Host: Clusterizado de máquinas virtuales con máquinas físicas.

Antes de decidir como montar un cluster en VMware, parémonos a pensar para qué queremos el cluster.



Un cluster se monta, normalmente, para prevenir un fallo (físico o de sistema operativo) de los servidores que lo integran, no (al menos no siempre) de las aplicaciones clusterizadas o del almacenamiento. Resumiendo: Un cluster del tipo MSCS no nos protegerá del fallo del almacenamiento, así que tengamos claro para qué nos vale.... y qué esperamos de él.

Por suerte o desgracia, no hay alternativa a su uso en entornos virtuales, salvo VMware HA, que nos garantiza que si un host o una VM cae por alguna razón, esta VM será "encendida" en otro host dentro del cluster HA de host que hayamos montado. Evidentemente, esto tampoco nos proteje de un fallo en el disco virtual de la máquina o de una LUN accedida por el host que ha caído. En el mejor de los casos, dispondremos de la VM en funcionamiento entre 16 y 120 segundos después... vamos, lo que tarde en hacer un power on y levantar las aplicaciones.

¿alternativas?... Bueno, hasta que VMware comercialice Countinuous Availability (Presentada por Mendel Rosenblum, Jefe Científico de VMware en el VMworld'2007), que permitirá que una máquina virtual se ejecute A LA VEZ en dos host ESX sincronizando estados (memoria, conexiones, etc) y almacenamiento, me temo que como alternativas al MSCS tradicional (almacenamiento compartido usando reservations SCSI2/3) puedo recomendar la replicación entre aplicaciones, además de las que nombré en este post. Eso sí, las soluciones de replicación no nos darán, ni de lejos, los tiempos de respuesta de MSCS (o soluciones similares).

Un saludo.