En este post, intentaré explicar de manera sencilla como funciona HA en un Cluster vSAN. Para los que no conocen el producto, VMware vSAN es una solución de hiperconvergencia que te permite conformar un storage compartido, utilizando los discos internos de los servidores. No quiero ahondar mucho en la teoría de cómo funciona y cuáles son las diferencias con las soluciones tradicionales de Storage (FC o iSCSI). En cambio lo que pretendo hacer con esta publicación, es simplemente mostrarte en detalle como efectuar una prueba de HA.
En primer lugar HA dentro del mundo de VMware, es una característica a nivel de Cluster, que permite el reinicio automático de las VMs en caso de que un host (en donde están ejecutando) falle, se apague, quede aislados de la red, etc. Tal como lo indican sus siglas HA (High Availability), esta feature permite la alta disponibilidad de las máquinas virtuales, de manera automática y sin la intervención manual del administrador. En un entorno vSAN, dicho servicio trabaja en conjunto con SPBM (Storage Policy–Based Management), que me permite definir la tolerancia a fallos que quiero que soporten mis máquinas virtuales. De acuerdo a la tolerancia a fallos que yo establezca como administrador, voy a necesitar un mínimo de host ESXI dentro de mi Cluster. Por ejemplo, si yo defino que mis VMs tengan una tolerancia a fallo de 1 (un host ESXI) con RAID1 (mirroring), necesito como mínimo 3 host ESXI (recomendado 4). Esto se debe a que en un ESXI estará almacenada mi VM original, en el segundo una VM réplica (una copia completa de mi VM original) y en un tercero habrá una copia que cumplirá la función de witness (solo contiene metadatos). El ESXI que contiene la VM witness es el encargado de dar quorum ante la caída o desconexión del ESXI que contenga la VM original o la réplica. Se podría comparar con Microsoft Clustering (MSCS) en donde cada miembro tiene un voto y ante la caída o falla de uno de sus miembros, mantendrá el servicio el host que más votos tenga (el propio y el del witness).
Para esta demo voy a utilizar los laboratorios de VMware: https://labs.hol.vmware.com/HOL/catalogs/catalog/all . Sitio que recomiendo a todo el mundo porque además de ser gratuito, te permite probar todos los productos que VMware tiene en su catálogo.
Antes de comenzar, les paso un detalle de cómo está conformada la infraestructura:
1 Cluster vSAN conformado por 4 host ESXI 6.7
1 Datastore vSAN con un total de casi 80 GB.
Los discos internos de cada servidor se van a dividir en 2 niveles: caché y capacity. Lo que se muestra en la imagen anterior, es la sumatoria de los discos internos de cada servidor, los cuales se encuentran dentro del segundo grupo (capacity).
1 máquina virtual con un disco de 100 MB y la política SPBM que viene por default (FTT 1/RAID 1)
Cada servidor cuenta con 2 placas de red de 10 Gbe, las cuales están asociadas a un mismo Switch Distribuido (RegionA01-vDS-COMP).
El Switch Distribuido tiene conectado los diferentes puertos virtuales configurados (VM Port Groups y VMkernel).
El primer paso que realizaremos, será verificar en que host ESXI se encuentran los diferentes objetos que conforman la VM. En un entorno vSAN cada VM se divide en 3 componentes principales: el disco virtual, la swap y la carpeta «VM Home».
El disco virtual, es en donde las VM tiene instalado el SO Guest y en donde va a alojar todo su contenido.
El objeto swap se crea cada vez que la VM se enciende y si no tiene asignada una reserva de memoria. En caso de que el ESXI se quede sin memoria física para asignarle a las VMs, las mismas podrán volcar su memoria virtual al disco físico.
La carpeta «VM home» contiene toda la configuración de la VM tal como el archivo .vmx, archivos logs, archivos de descripción de snapshots, etc.
Desde nuestro vCenter, podremos saber la ubicación de cada uno de los componentes. En este ejemplo, los mismos se encuentran distribuidos entre el ESXI-01, ESXI-02 y ESXI-03. Esto se debe a que la VM tiene aplicada una política SPBM FTT=1/RAID1, por lo tanto cada objeto (disco virtual, swap y VM home) estará replicado en 3 hosts diferentes dentro del Cluster. Si tomamos como ejemplo el componente «swap» podremos observar lo siguiente:
Cada objeto cumple un rol determinante: component o witness. Los objetos «component» pertenecen a la VM original o a la réplica. Los objetos «witness» cumplirán la función de dar quorum ante la perdida de acceso a la VM original o a la réplica. En la imagen a continuación, podrán observar que el objeto «swap» tiene una copia en el ESXI-03, el cual cumple el rol de «witness» y 2 copias en los ESXI-01 y ESXI-02, los cuales figuran como «component».
Esto me va a asegurar que la VM soporte la caída de uno de sus miembros (host ESXI), y dependiendo en donde se encuentre la máquina virtual original, la funcionalidad HA me permitirá el reinicio automático sin mi intervención.
La VM actualmente se encuentra ejecutando sobre el host ESXI-01, así que procederemos a forzar un failover. Recuerden que la «original» se encuentra almacenada en los discos locales del servidor, por lo tanto en una infraestructura vSAN (siempre y cuando cumpla con la cantidad de host mínimos necesarios) se mantendrá una «réplica».
Detalle: En un entorno no vSAN, si una VM se encuentra almacenada en los discos locales del host y el mismo falla, la VM quedaría inaccesible.
Haciendo click derecho sobre el host ESXI, seleccionamos la opción Power–>Shut down.
Ingreso el motivo por el cual quiero apagar el host, en mi caso «Prueba HA» y presten atención al mensaje que indica más abajo.
Básicamente nos advierte que si apagamos o reiniciamos el host sin antes ponerlo en modo mantenimiento, las VMs no serán evacuadas (migradas a otros host dentro del Cluster) o apagadas de manera correcta. Además nos dice que en caso de estar trabajando sobre un «Cluster vSAN», podría resultar en la perdida de acceso a ciertos datos. El modo mantenimiento dentro de VMware, sería el paso previo que debo ejecutar antes de apagar el host de manera correcta. Pero en esta demo mi objetivo es forzar una falla del entorno, por lo tanto al seleccionar directamente (sin antes ponerlo en modo mantenimiento) la opción «Shut down», sería algo similar a «presionar el botón de apagado en mi servidor» (el famoso botonazo jejeje).
El host iniciará el proceso de apagado a las 06:07 P.M.
Una vez apagado, se van a disparar varias alarmas dentro del entorno. A nivel de Cluster, nos va a dar aviso sobre la perdida de conexión de uno de sus miembros y además, la puesta en acción de la feature HA.
Si nos apoyamos sobre el servidor ESXI que apagamos, las alarmas disparadas indicarán que se perdió conexión con el host, la falta de sincronización y además que vSphere HA detectó un fallo en el mismo.
Si seleccionamos otro de los miembros del Cluster, en este caso el ESXI-02, nos advertirá que ya no puede comunicarse con uno de sus miembros (ESXI-01).
Si vemos el estado de la VM, podremos observar que la misma se encuentra ejecutando sobre el servidor ESXI-04. Cómo sucedió esto?, simplemente HA la reinició de manera automática en otro host dentro del Cluster.
No me creen lo que les digo?, miremos el registro de los eventos.
El mensaje es más que claro: vSphere HA ha reiniciado esta maquina virtual. Esto sucedió a las 06:08 P.M., o sea unos segundos después de haber apagado el ESXI-01.
Este ejemplo me viene como anillo al dedo para sintetizar como funciona vSAN. Por si no lo recuerdan, vimos que la VM original se encontraba en los discos locales del host ESXI-01, la réplica en el host ESXI-03 y la witness en el host ESXI-02. Ahora bien, la VM se reinició en el host ESXI-04… pero la réplica de la misma, se encontraba almacenada en el host ESXI-03. En pocas palabras, la parte de computo (vCPU y memoria) está utilizando los recursos del ESXI-04, pero los I/O a nivel de almacenamiento se están generando en los discos locales del host ESXI-03. Qué quiere decir esto?, que vSAN me permite conformar una configuración similar a la empleada en una infraestructura con storage externo (SAN o iSCSI), pero utilizando los recursos de computo, almacenamiento y networking de mis ESXI. Por lo tanto me estaría ahorrando miles de dolares en infraestructura (storage externo, switches, fibra óptica, refrigeración, etc.), y además me permitiría simplificar y centralizar la administración del entorno, desde una misma plataforma.
Por último, se acuerdan que aclaré que para FTT=1/RAID1 se necesitaba un mínimo de 3 host, pero que lo recomendado era contar con 4??. Bueno, he aquí la explicación. vSAN cuenta con una inteligencia que le permite recuperar los componentes que no están cumpliendo con la política de tolerancia a fallos. En la demo que ejecuté, cuando el host ESXI-01 quedó fuera de servicio, solo me quedaron disponibles los objetos de la réplica y de la witness. Si observan las imágenes a continuación, verán el status de los objetos, una vez apagado el ESXI-01:
Noten que los componentes que se encontraban en el ESXI-01 figuran con status «Absent» (ausente). Esto es correcto, ya que al apagar el host, me quedé sin acceso a sus discos locales. Esto ocasionó que mi VM ya no cumpliera con la política establecida, debido a que los objetos de la VM original quedaron inaccesibles.
Para cumplir a rajatabla con FTT=1/RAID1, si o si necesito contar con los todos los componentes. Y para qué es necesario el cuarto host?, simple, vSAN por default tiene una configuración en la cual va a esperar 60 minutos y en caso de que no se vuelva a establecer la conexión con el host caído, intentará recuperar los objetos perdidos. En pocas palabras, lo que hará es generar una réplica de la VM disponible, en alguno de los ESXI restantes. Para esta demo, por cuestiones de tiempo, modifiqué el marcador que viene por default y lo bajé a 20 minutos.
Luego de esperar 20 minutos…voilà!!! vSAN generó una réplica de los objetos (disco virtual, swap y VM folder) en el host ESXI-02 (originalmente acá se encontraba la witness, la cual solo contiene metadatos) y una witness en el host ESXI-04. No me crees?, mirá las imágenes a continuación.
De esta manera la VM quedó nuevamente protegida, lo que me permitirá tolerar la caída de alguno de los 3 host restantes. Lo mejor de todo esto es que no tuve que intervenir en ningún momento.
Espero que hayas entendido como funciona HA dentro de un entorno vSAN, en próximas publicaciones seguiré profundizando sobre este tema que tanto me apasiona. Hasta el próximo post!!!
Se autoriza la reproducción de los materiales de este blog citando la fuente e incluyendo un enlace al mismo.
Blog de Cloud Computing y Virtualización 