VMware vSAN: vSAN Witness

¿Qué es esto? ¿Qué es vSAN?

Si estás leyendo este artículo sin tener ni idea de qué es vSAN, permíteme introducirte a una solución que posiblemente revolucione tu infraestructura TI: VMware vSAN. Créeme, te va a gustar. Y no me mal interpretes, no estoy hablando de la última moda pasajera; vSAN fue lanzado en 2014, ¡hace más de una década! Tampoco te voy a contar la teoría sin más, esto no es humo. VMware vSAN funciona y se usa en muchísimos centros de datos. Sin embargo, para muchos, sigue siendo un enigma.

Si por el contrario, no es tu primera vez y simplemente quieres echar un ojo a lo importante, puedes omitir esta introducción teórica.

¿Qué es vSAN? En pocas palabras, es como darle súper poderes a los discos duros de tus servidores. ¿Cómo? vSAN te permite usar tus discos locales como parte de un pool de almacenamiento compartido. En lugar de tener tu almacenamiento en una cabina de discos tradicional, puedes usar los propios discos locales de los servidores como «cabina de discos global y común» a todos los servidores. De esta forma, podemos usar funcionalidades como HA, vMotion, FT o DRS sin necesidad de almacenamiento externo.

Ref: https://docs.vmware.com/es/VMware-vSAN/index.html

¿Por qué vSAN? Hasta hace apenas seis meses, la respuesta habría sido: «¡Por el precio!» Sin embargo, desde que Broadcom adquirió VMware, los costes de licenciamiento han aumentado, lo que significa que el precio ya no es un factor tan diferenciador. No obstante, sigue siendo una referencia en el mercado. A medida que nuestra infraestructura crece, vSAN se vuelve cada vez más rentable. Además del coste, la facilidad de escalar la infraestructura con vSAN es fundamental. Todo lo que necesitas está en tus ESXi. Olvídate de las cabinas de discos y otros elementos externos requeridos en la arquitectura tradicional. ¿Necesitas más almacenamiento? Agrega otro ESXi a tu clúster y listo.

¿Y el rendimiento, qué? vSAN garantiza un rendimiento óptimo y una alta disponibilidad de tus datos (High Availability + Fault Tolerance), incluso si un servidor falla inesperadamente.

Si quieres saber más información, te recomiendo leer con calma este artículo de VMware. Está explicado mejor por ellos que por mí.

Disclaimer

1. Debo admitir que este artículo es un poco egoísta. Lo escribo porque cada cierto tiempo tengo que empezar desde cero con un entorno VMware. Tener un artículo que me refresque qué hice, cómo lo hice y qué problemas enfrenté es muy útil. Me ayuda a evitar problemas y a ahorrar tiempo. Y si puede ser útil para alguien más, ¡genial!
2. No trabajo en VMware ni he implementado vSAN miles de millones de veces. Si algo de lo que se menciona en este artículo no es preciso, te pido amablemente que me lo señales y estaré encantado de corregirlo. Aprecio mucho tu ayuda. ¡Gracias!
3. En un principio, como siempre, quería hacer una mini guía para implementar vSAN Witness pero finalmente me ha quedado un artículo que quizás tardes más en leerlo de lo que tardarás en beber 1 café. Por lo tanto, prepara 2 cafés.

Tipos de clústeres vSAN

Existen diferentes tipos de clústeres de vSAN. Antes de intentar resumir como funciona cada uno, quiero que pienses RAIDs. Si tienes 2 servidores, tienes un RAID0 (no hablamos de RAIDs1 aquí). Si quieres conseguir un RAID5, necesitas un tercer «elemento».

Además, igual que se asume que tienes servicios de networking ya funcionando (switching, routing, fw, DHCPs, DNS…), tienes que tener en cuenta que siempre hablamos de vSAN como una parte más de la infraestructura VMware ya desplegada. Por ejemplo, un clúster VMware vSAN clásico son 3 nodos, es decir, 3 servidores ESXi pero para desplegarlo necesitas vCenter. Por lo tanto, necesitaríamos un cuarto nodo que se asume que ya lo tienes (Y sí, posteriormente puedes mover ese vCenter dentro del clúster!).

vSAN clásico

3 nodos ESXi. Fácil y sencillo. Los 3 nodos comparten almacenamiento. Necesitarás conectar los 3 nodos a 10G mediante switches y también comunicarlo con vCenter. Si puedes comprar 3 nodos (y todo lo auxiliar que conlleva), es lo más recomendado.

vSAN clásico con 2 nodos (FTT = 0)

Puedes desplegar el clúster vSAN clásico con 2 nodos pero perderás la paridad y, por tanto, tendrás un RAID0. Compartes almacenamiento, puedes activar HA, DRS, FT… pero es un raid 0. Si te cae un nodo con 1 vm corriendo, la vm no volverá a levantar hasta que no recuperes el nodo.

Clúster ampliado o stretched cluster

1 sitio vSAN primario y 1 sitio vSAN secundario separados físicamente pero con conexión directa entre ellos (inter-site-link, 5ms). Ambos sitios son redundantes entre sí mediante un testigo en una tercera ubicación (200 ms).

Siguiendola imagen anterior: En la organización tengo 3 ubicaciones físicas y quiero que pase lo que pase tenga conexión a mis servicios. Despliego el mismo número de servidores (1..n) en dos ubicaciones diferentes. Despliego networking entre ellos (10G) y configuro un único clúster con dos sitios diferentes. El principal y el secundario. De tal forma que si cae el principal la VM continúa ejecutándose en el sitio secundario. Downtime cercano a 0.

vSAN dos nodos (ROBO)

Es el hermano pequeño del clúster ampliado. 2 nodos + testigo (appliance o 3er nodo). Es el que menor coste conlleva.

Básicamente tienes dos servidores que se replican todo entre ellos y usan un tercer elemento para hacer quorum. La resiliencia que ofrece es bastante alta. Por ejemplo, podría fallar 1 disco y continuar funcionando sin downtime. Fallar un segundo disco y lo mismo. Fallar 1 servidor completamente y continuar sin downtime (inapreciable). Volver a fallar otro disco del servidor 2 y no pasaría nada…

La imagen anterior representa el escenario tipo para el que ha sido pensado. Tienes varias oficinas o varios emplazamientos pequeños, levantas 2 servidores y gestionas todo desde oficinas centrales o datacenter principal. A medida que tu organización crece, simplemente añades más clústeres remotos.

Si deseas comprender más a fondo vSAN, te recomiendo encarecidamente que consultes este artículo de VMware: Enlace. Allí encontrarás una explicación detallada proporcionada por el propio fabricante.

vSAN ESA vs vSAN OSA

No es el propósito de este artículo pero veamos un poco de información ya que sino siento que falta contexto.

Hasta la versión 7 de VMware vSphere, cuando hablabamos de vSAN hablabamos de vSAN y punto, sin medias tintas. A partir de la versión 8, VMware introduce el concepto de vSAN OSA (Original Storage Architecture o Arquitectura de almacenamiento original) y vSAN ESA (Express Storage Architecture o Arquitectura de almacenamiento exprés).

vSAN OSA es la arquitectura original, es el vSAN de versiones anteriores. vSAN ESA es la novedad en la versión 8. Existen muchas diferencias entre ambos y eso daría para otro artículo. Os dejo un enlace a VMware donde se entiende mejor.

Al grano (por fin)

He tardado más en buscar toda la info teórica que en montar el clúster…

En este artículo voy a mostrar (o al menos es la intención) cómo desplegar un clúster de VMware VSAN con 2 nodos y un componente que hará de testigo.

¿Qué es un testigo? El testigo o witness es el componente que permite desempatar cuando se produce un partición de red. Sistema de Quorum.

Este testigo puede ser un tercer ESXi o puede ser una máquina virtual (ESXi virtualizado) que este ejecutándose en otro host. El testigo NO puede formar parte del clúster vSAN. Por lo tanto, el clúster de «2 nodos» es mentira. Necesitas 2 nodos + un tercero que pueda ejecutar el testigo. El testigo se instala en modo appliance, con lo cual, puede correr en múltiples plataformas (HyperV..)

Requisitos hardware

Los requisitos hardware en VMware vSAN son un dolor de cabeza. Y sí, vas a dedicar más tiempo a saber el hardware que necesitas que en levantar el propio clúster. Este tiempo es importante porque de lo contrario, te encontrarás con mil problemas posteriormente. Atento a unidades y tipo de almacenamiento. Tarjetas de red: fabricante, modelo, drivers, compatibilidades. Tarjetas HBA almacenamiento: fabricante, modelo, drivers, almacenamiento.

Además, y como práctica general, te recomiendo que actualices todos los firmware en tus servidores porque de lo contrario, sí, problemas.

Si no queremos gastar tiempo en saber que necesito y si tienes los recursos apropiados, puedes ir directamente a tu fabricante de hardware favorito (HPE, Huawei, Supermicro…) y solicitar oferta para un clúster VMware vSAN con las características que necesites. El coste de la consultaría irá incluído en el precio hardware.

No obstante, voy a intentar hacer un resumen del hardware necesario para VMware vSAN clúster de 2 nodos.

Requisitos hardware VMware vSAN clúster 2 nodos: Almacenamiento

• Mínimo (no recomendable): 3 discos por cada nodo.
  • 2 HDD
  • 1 SSD / FLASH
  • Escenario: En esta configuración usaríamos 1 HDD para el hipervisor, 1 HDD para capacity tier y 1 SSD para caché tier. Esta opción no se recomienda porque no tenemos ninguna redundancia RAID a nivel de hipervisor y puede suponer un problema. Además, un disco de tipo HDD para el hipervisor tampoco es lo más recomendado.
  • Tipo de clúster: vSAN 8 OSA o vSAN 7.
• Mínimo recomendable: 4 discos por cada nodo:
  • 3 HDD
  • 1 SSD / FLASH
  • Escenario: En esta configuración usaríamos 2 HDD para el hipervisor en RAID1 (se necesita controladora RAID adicional), 1 HDD para capacity tier y 1 SSD para caché tier. Esta opción es la mínima recomendada para un entorno con poca necesidad de almacenamiento y un rendimiento de IO bajo.
  • Tipo de clúster: vSAN 8 OSA o vSAN 7.
• Recomendable: 4 discos flash por cada nodo
  • 4 SSD / FLASH
  • Escenario: En esta configuración usaríamos 2 SSD para el hipervisor en RAID1 (se necesita controladora RAID adicional).
    • Esta opción es recomendada para un entorno con poca necesidad de almacenamiento y un IO alto.
  • Tipo de clúster: vSAN 8 ESA o vSAN 7.
    • vSAN 7: 1 SSD para capacity tier y 1 SSD para caché tier.
    • vSAN 8 OSA: No tiene sentido usar OSA en esta configuración.
    • vSAN 8 ESA: 2 SSDs para propósito general.
• Ideal: 6 discos flash o más.
  • De inicio: cuantos más discos flash, mejor.
  • Escenario: En esta configuración usaríamos 2 SSD para el hipervisor en RAID1 (se necesita controladora RAID adicional) y el resto de SSDs para almacenamiento/caché (mínimo 4).
    • Esta opción es recomendada para un entorno con necesidad de almacenamiento alta y un IO alto.
  • Tipo de clúster: vSAN 8 ESA o vSAN 7.
    • vSAN 7: 2 SSD para caché tier y el resto para capacidad.
    • vSAN 8 OSA: No tiene sentido usar OSA en esta configuración.
    • vSAN 8 ESA: Todos SSDs para propósito general.

En mi escenario de pruebas, tenemos un total de 4 discos flash por cada nodo:

• 1 SSD NVME – Hypervisor (no recomendable pero esto es para pruebas!)
• 3 SSD SATA 2.5 – vSAN

Requisitos hardware VMware vSAN clúster 2 nodos: Networking

Dado que tenemos 2 nodos, no necesitaremos conectar ambos nodos a un switch 10G para enviar el tráfico de almacenamiento pero si necesitaremos conectar ambos entre sí a 10G. A pesar que según VMware en un escenario híbrido funciona a 1G, para mi es imprescindible que la conexión entre ellos sea a 10G como mínimo. Esta conexión es necesaria para la transferencia de datos entre ambos.

La conexión con el witness no es necesaria que sea a 10G, una conexión estándar de 1G es suficiente siempre que la latencia sea menos a 200ms.

En mi escenario de pruebas, tenemos un tarjeta con 2 puertos 10G cada uno.

Requisitos hardware VMware vSAN clúster 2 nodos: Resto

El resto de hardware es similar a servidores tradicionales teniendo en cuenta la memoria. A vSAN le encanta la memoria, cuanta más memoria le des mejor así que te recomiendo que dejes un 25% solo para vSAN.

Artículo que explica el uso de la memoria en vSAN 7

En mi escenario de pruebas, tenemos un tarjeta con 2 equipos con 48GB de RAM cada uno.

Escenario

Partimos de la base de que si estás leyendo hasta este punto es porque sabes de sobra que es un ESXi y como se instala. Has levantado previamente clústeres VMware (sin vSAN) y te manejas bien con el entorno vSphere. Por lo tanto, contamos con:

• 2 nodos ESXi recien instalados (VMware ESXi, 8.0.2, 22380479)
  • Conexión directa a 10G
  • Conexión indirecta (switching) a 1G.
• 1 nodo con:
  • 1 VCSA 8 (vSphere Center Server Appliance) corriendo.
    • Clúster con HA activado.
• Servidor DNS funcionando.

Como puedes ver, necesitas un VCSA corriendo en algún sitio y posteriormente tendremos que instalar un Witness Appliance . Usaremos el mismo tercer nodo para esto. Como vimos al principio del artículo, este nodo puede ser usado para varios clústeres de 2 nodos de vSAN, es decir, puedo tener 1 nodo que tenga 1 VCSA que administre varios clústeres vSAN y también tenga el testigo de todos ellos. Así que sí, necesitas si o si 3 servidores.

En cada host tendremos, al menos, 2 vSwitch:

• 1 para gestión y tráfico witness (testigo).
  • vmnic0
• 1 para tráfico de tipo vSAN.
  • vmnic1 y vmnic2 (1 es suficiente, aunque de nuevo, se recomiendan 2).

La topología la podéis ver en la imagen posterior.

Configuración

Configuración: Requisitos

No soy muy pro-wizards o asistentes pero en este caso, VMware nos lo pone bastante fácil y vamos a usar el asistente para crear el clúster vSAN en lugar de hacerlo manualmente. Antes vamos a configurar lo único que el wizard no hace: la creación del testigo y la configuración de el tráfico del testigo.

Este punto es el más importante y el motivo principal por el cual escribo este artículo. Si tenemos los dos ESXi directamente conectados, sin switch en medio. ¿Cómo comunicamos con el testigo? Podemos usar cualquier interface para comunicar con el testigo, simplemente hay que aplicarle una configuración. Para hacer esto, tenemos que indicar mediante línea de comandos que ese adaptador se usará para tráfico de tipo testigo.

Para ello, activamos SSH en todos nuestros hosts y, en la vmk que vayamos a usar para este tráfico, apliquemos el siguiente comando:

esxcli vsan network ip add -i vmk0 -T=witness

Para verificar que está correctamente aplicado:

esxcli vsan network list

Si tenemos desplegado el testigo en modo appliance (vm), no tendremos que hacer nada en esta VM. En cambio, si tenemos desplegado el testigo en modo ESXi, tendremos que hacer exactamente lo mismo con la interface que quieras usar para el tráfico de vsan/testigo.

Configuración: Despliegue de testigo / witness

Es bastante sencillo pero aún así lo explico con unas cuantas imágenes.

1. Descargamos la OVA (VMware-vSAN-ESA-Witness-8.0U1-21495797) de vmware.com (enlace).
2. Desplegamos la OVA directamente.
   • Recomiendo usar disco de tipo thin si no vamos sobrados de espacio (mi caso).

Una vez desplegada, arrancamos la VM. Veremos que es un ESXi virtualizado con 2 interfaces: 1 para mgmt y 1 para tráfico VSAN.

A continuación, añadamos el host a nuestro vCenter como si cualquier otro ESXi se tratase. Una vez añadido, podemos ver que nuestro vCenter detecta que es de tipo testigo. Mirad el icono al lado de la IP.

Configuración: Creación del clúster (wizard)

Por fin hemos conseguido cumplir con todos los requisitos que nos pide VMware para poder crear un clúster de vSAN. A continuación, podemos arrancar el wizard. Clúster > Configurar > Inicio rápido > Configurar.

Os dejo unas imágenes de como lo he configurado yo. En pocas palabras:

• Uso la conexión directa a 10G para crear un switch virtual distribuido.
• Asigno dos direccionamientos IP diferentes para el tráfico vSAN entre nodos.
• Selecciono vSAN de dos nodos (al final mostraré el resultado, crea un clúster ampliado!)
• Selecciono todos los discos duros que tengo (3 por nodo, todos SSD).
  • Importante: VMware indica que los discos son incompatibles pero esto solo indica que el disco no ha sido aprobado por VMware. No está certificado y por tanto VMware no garantiza un rendimiento óptimo. El disco es compatible y se puede seleccionar.
• Selección de testigo.
• Comprobación final.

En mi escenario tengo bastantes warnings ya que se trata de un escenario de pruebas en mi homelab, no es algo preocupante.

Algunas imágenes para comprobar el estado del clúster:

Atención a la última imagen: Tipo de configuración > Clúster ampliado.

¿Qué demonios? Si he configurado este clúster como vSAN 2 nodos. ¿Por qué el wizard ha creado el clúster ampliado? Sinceramente, en este momento lo desconozco. Si sabes el por qué, agradezco tu ayuda. ¡Ponte en contacto conmigo! La idea del artículo era el uso del tráfico VSAN para el testigo mediante el comando indicado y no averiguar el por qué el wizard crea un clúster ampliado en lugar de uno de 2 nodos. No obstante, investigaré que ha pasado aquí. En el próximo artículo…

Gracias.

Si has llegado hasta aquí, simplemente gracias. Cualquier comentario constructivo es bienvenido.