Como crear un Disco Duro para acceso compartido en el mismo Host ESX

En muchas ocasiones nos puede venir muy bien que dos VMs compartan el acceso a un disco duro simultaneamente. Esta es la forma tipica de crear un cluster MSCS o un cluster GFS u OCFS o Linux HA, etc, etc.

Lo que se busca es que dichas VMs puedan acceder al mismo tiempo al disco, poniendo una capa por encima que arbitre (generalmente mediante locks) el acceso en lectura/escritura. Lo normal, es que usemos Raw Device Mapping y que dichas VM estén en diferentes Hosts ESX pero hay muchas veces que por diversas razones (no tenemos una SAN, estamos haciendo una maqueta de pruebas, etc,etc) necesitamos poner las VMs que conforman dicho cluster en el mismo Host ESX.

En estos casos, para que sea posible compartir un disco duro (un "virtual disk"), es necesario especificar en el driver SCSI de las máquinas virtuales en las cuales el disco va a ser compartido que su Bus SCSI va a ser compartido:

Una vez hecho esto, tendremos que crear el disco que va a ser compartido como "thick".

El comando para hacerlo es:

vmkfstools -c 10g ruta_del_disco_duro_a_crear -d thick

Una vez creado el disco, lo añadimos a las máquinas virtuales que lo tengan que utilizar a través de "Add Hard Drive", "Use an existing virtual disk". Lo normal es crear con el comando anteriror el vmdk que va a ser compartido en el primer nodo del cluster (es decir en el mismo direcorio que el vmx del primer nodo) y en los nodos simplemente añadir el disco usando Use an existing virtual disk y seleccionando el directorio donde esta el vmdk a compartir.

¿Porqué debemos crear el Virtual Disk como thick?
Esto ocurre porque, al tratarse de un disco que va a ser compartido, los nodos pueden estar escribiendo simultáneamente en posiciones del disco muy diferentes, por ejemplo uno podria escribir al principio mientras que otro podria escribir al final, por ello es necesario reservar y ocupar todo el espacio que ocupa el disco ya desde su creación.

Cluster GFS de maquinas virtuales con VmWare: Ideas

Tengo desde hace tiempo en la cabeza el proyecto de realizar un cluster de maquinas virtuales bajo linux: Una solucion muy escalable y versatil que lleva implicta la alta disponibilidad.

Por el momento, todos los clusters que he visto nombrados en vmware son clusters de microsoft en maquinas vituales pero ninguno que corra sobre maquinas linux. Este estudio me servirá para determinar si es posible realizar esta solucion y si se puede llevar a produccion incluso para servidores tipo IMAP con millones de pequeños ficheros (situacion mas desafavorable para el filesystem).

De partida descarto Xen como tecnologia para virtualización en produccion. Yo esperaria un par de años antes de poner nada en produccion con paravirtualizacion. Tiene muy buena pinta pero si no quieres estar sufriendo una solucion recien nacida no os lo aconsejo.

La eleccion del sistema de ficheros GFS (o GFS2 si logro ponerlo) viene dado por los conocimientos que tengo (hemos echado a andar un cluster gfs para web(apache) y servidor de apps(tomcat) y funciona a las mil maravillas). Otras implementaciones como PolyServe están fuera de presupuesto.


Algunas ideas/pasos para ponerlo en marcha:

Instalacion de GFS en una maquina virtual.
En esto no creo que tengamos problemas, es identico a una maquina real. La instalación en un RedHat 4U4 la haré por rpms.

Clonacion.
Una vez tenemos una vm (nodo) del cluster bien configurado lo clonamos (con lo que tenga en eso momento, copiando discos vmdk y cambiando los vmx...). De esta forma tendrmos 3 nodos idénticos. Necesitariamos una vlan para señalización del gfs y otra vlan para los datos de aplicación.

Acceso Raw Device Mapping.
Las luns de datos estarán en una cabina DS4300, haremos un RDM de dichas luns.


Fencing.
Esta es una de las cosas que mas me preocupa. El fencing es la forma que tiene el gfs de impedir que un nodo corrompa el fs. Cuando un nodo ha perdido heartbeats (se envían por la red de señalización) los demas nodos que forman el cluster deciden que no tenga acceso a los datos. Esto se puede hacer de diversas formas: Por medio de un switch de corriente(apagando el nodo), Cortando el acceso a la lun de datos,etc.

Cuando los nodos son reales esto no supone ningun problema, pero ¿ Y con maquinas virtuales ? Buscando en google(herramienta de trabajo donde las haya) podemos ver que no hay mucho implementado a este respecto.

Podemos ver la solución que nos plantean aqui .
Se trata de un script de perl que manda un comanda com vmware-cmd al ESX remoto que alberga el nodo que ha perdido la comunicación.
Esta solución no es viable puesto que con ejecutar de forma local el comando vmware-cmd.pl ruta_a_la_vm.vmx off hard ya nos tardaría alrededor de 3,5", tiempo inaceptable para un cluster en producción puesto que hasta que el nodo no es 'fenceado' el nodo que 'fencea' no tiene acceso al FS.

La solución más inmediata y elegante es realizar el fenceo via RPC. Matando la vm, averiguando su pid a través de su numbre (nombre.vmx).

Las pruebas que llevo hasta ahora me dan tiempos de 40ms en local y desde remoto unos 80ms, claro que depende de la latencia de la red. Por ello nos viene muy bien el hecho de que la señalización vaya por una vlan diferente.

Pruebas de carga.
Bueno , esto está por ver. Es posible que se hagan pruebas con IMAP.

Espero escribir un poco mas sobre el tema pronto.