Queridos amigos del blog de Encora, el pasado 10 de marzo nos despertábamos con la noticia del gran incendio en el centro de datos de OVH. Esta noticia, ha puesto de manifiesto la importancia no sólo de tener un buen plan de recuperación de desastres distribuido geográficamente, sino también un buen plan de continuidad de negocio. En este post de hoy explicamos cómo podemos mejorar ese plan de continuidad de negocio basándonos en las tecnologías que actualmente tenemos en el mercado y concretamente con VMware vSAN.
VMware vSAN
VMware vSAN es un producto que salió al mercado en el primer Q de 2014. Es una solución robusta de almacenamiento definido por software o SDDC (de sus siglas en inglés). Viene embebida en el hipervisor ESXi y utiliza los discos locales de los servidores para proveer almacenamiento compartido entre todos los miembros de un clúster.
El almacenamiento que aporte cada uno de los servidores ESXi estará distribuido en dos capas.
- Caché
Esta capa deberá ser obligatoriamente de discos SSD o flash y su función es la de “absorber” los IOPS de entrada en la vSAN y dar una respuesta rápida.
- Capacidad
Es la capa formada por discos SSH, flash o discos mecánicos tradicionales y que nos aporta capacidad en el cluster. Es la capa donde se almacena la información de manera persistente.
Tipos de cluster vSAN:
Actualmente tenemos diferentes formas o arquitecturas de implementar un cluster de vSAN:
- vSAN Clásico
Requiere de un mínimo de 3 nodos y es ideal para ejecutar y almacenar nuestras cargas de trabajo en entornos estándar.
- Stretched Cluster
Pensado para entornos Enterprise y de alto rendimiento puede estar formado por hasta 30 nodos en vSAN7, 15 en cada sitio. Se diseña una arquitectura multi-site para tener el almacenamiento distribuido geográficamente.
- vSAN de 2 nodos o vSAN ROBO
Pensado para pequeños entornos u oficinas remotas. Aunque sólo disponga de 2 nodos ESXi, en verdad son 3, ya que es necesario disponer de un witness host, que podrá ser en versión appliance. En términos generales, es el hermano pequeño de un stretched cluster, ya que el funcionamiento es el mismo, pero con sólo 2 nodos.
Stretched cluster
Cómo adelantaba anteriormente, un vSAN stretched cluster no es más que un diseño geo-distribuido de nuestros nodos para construir una arquitectura robusta ante desastres. Nos permite tener los datos redundados en dos ubicaciones físicas independientes y maximizar el acceso en caso de caída total de alguno de los centros de datos.
De esta forma, se incrementa la disponibilidad y la protección del dato en entornos Enterprise. Es una arquitectura activo-activo en el que se habilita una replicación síncrona entre ambos sites.
Con esta arquitectura, podremos disponer de un entorno mucho más ágil a la hora de reaccionar ante desastres. Todo esto, gracias a esta replicación, que nos permite tener los datos duplicados, o por lo menos “reconstruibles” (en caso de Raid5) en 2 sitios.
La escalabilidad máxima en vSAN es de 15 nodos por sitio + el witness host, por lo que nos da un total de 30 nodos por cluster.
A nivel de networking es importante interconectar correctamente los 3 sites en una red a 10Gbps o superior y disponer de una latencia < 5ms.
Ya en estas últimas versiones de vSAN se puede utilizar Layer 3 y tener el witness en diferentes redes.
Otra cosa a tener en cuenta es que para utilizar la arquitectura de stretched cluster es necesario tener una licencia de vSAN Enterprise.
Fault domains
La arquitectura de stretched cluster está basada en los denominados “fault domain”. Un dominio de fallo es una agrupación de nodos de la vSAN en los cuales se almacenarán los objetos dentro de la vSAN.
En una arquitectura de stretched cluster siempre tendremos 3 fault domain. El centro A, el centro B y el centro witness. El witness fault domain está pensado para que sea “testigo” y dé consistencia y coherencia a los datos de la vSAN que por tanto, no se podrán ejecutar VMs.
En un stretched cluster, los objetos obligatoriamente estarán en los 2 centros y el witness será el encargado de mantener la coherencia de esos datos.
Para que sea fácil de entender, basándonos en las políticas de vSAN, podremos configurar que los componentes dentro de la vSAN estén redundados en 2 fault domain distintos. A esa configuración se le llamará “Dual site mirroring”.
Witness host
Este componente es un ESXi que se distribuye en formato OVA y que nos servirá para dar coherencia a la vSAN. Básicamente es el nodo de quorum que nos protege en caso de un escenario de Split-brain en el que los 2 centros de datos se desconecten y dejen de tener visibilidad entre ellos.
El witness host deberá estar preferiblemente en un 3er centro de datos para evitar que se caiga con alguno de los sites de producción.
Este ESXi está soportado exclusivamente en entornos Stretched Cluster o ROBO, por lo cual sólo puede almacenar meta-datos, en ningún caso almacenará datos de VMs o será capaz de ejecutar máquinas virtuales.
La parte buena que tiene este ESXi virtual es que no consume licencia.
Casos de uso
El uso de vSAN Stretched cluster puede estar recomendado en diferentes escenarios, por ejemplo:
- Mantenimientos programados de nuestro CPD
Con stretched cluster podremos mover cargas de trabajo entre nuestros CPDs y poder ejecutar con seguridad nuestros mantenimientos sin necesidad de tener downtime en nuestros servicios.
- Prevención ante desastres
Teniendo nuestra vSAN distribuida entre diferentes CPDs, el impacto de la pérdida de nuestro centro de datos será mucho menor, al poder arrancar rápidamente nuestros servicios en otro CPD.
- Recuperación automática
Al ser vSAN un producto nativo de vSphere, se integra perfectamente con otras funcinalidades como HA (High Availability). Al tener nuestro almacenamiento geo-distribuido, esta tecnología nos permite que las VMs puedan arrancar de forma automática en otro centro en caso de desastre en uno de nuestros site.
Y hasta aquí por hoy. Espero que este post sea de vuestro interés.
¡Hasta la próxima! Gracias por leernos.
Miquel.