Buscar
Cerrar este cuadro de búsqueda.

Encora Webinar Metro Storage Cluster con VMware vSAN

Encora Webinar Metro Cluster con VMware con vSAN

Querid@s amig@s del blog de Encora, en este Encora webinar, realizado en marzo de 2021 para nuestros clientes, explicamos de la mano de Miquel Mariano, Head of Infrastructure, cómo aplicar la tecnología Metro Storage Cluster con VMware vSAN para la protección ante desastres.

También comentaremos qué es el almacenamiento definido por software, sus beneficios y su arquitectura.

¿QUÉ ES VMware vSAN?

VMware vSAN fue presentada en el VMWorld de 2014, con lo que ya lleva varios años en el mercado. 

Es una tecnología de hiperconvergencia y una solución de almacenamiento definido por software que nos permite agrupar los discos locales que tienen cada uno de los servidores VMware ESXi para montar o formar un único datastore, es decir, un único almacenamiento definido por software que se comparte entre los diferentes ESXi miembros de ese cluster.

Es una solución que está embebida en el hipervisor, en el propio ESXi y por lo tanto se integra muy bien, y es completamente funcional con otras tecnologías de VMware como puedan ser HA, DRS, vMotion, etc. 

TIPOS DE CLUSTER

  • vSAN CLÁSICO
Cluster VMware vSAN clásico.

El primer tipo de clúster que podemos montar con VMware vSAN es el clúster típico con tres nodos. Este tipo de cluster es perfecto para entornos estándar con relativamente poca carga de trabajo para pequeñas medianas empresas y también perfecto para para VDIs.

  • STRETCHED CLUSTER
Stretched Cluster con VMware vSAN.

El segundo tipo de cluster, es el que no centraremos en. este webinar.

El Stretched cluster de VMware vSAN es una arquitectura geo-distribuida en la que podemos montar nuestros servidores ESXi en diferentes centros de datos para cubrirnos de una posible contingencia.

Este tipo de cluster está pensado para entornos Enterprise.

– Alta disponibilidad de los servicios.

– Tiempos de recuperación RPO relativamente bajos para no perder nivel de producción.

Este tipo de cluster de la tecnología VMware vSAN nos permite distribuir en diferentes centros de datos nuestros servidores ESXi. Además, cabe destacar que esta tecnología o este tipo de cluster utiliza replicación síncrona entre los diferentes sites para poder tener una copia idéntica de los datos dependiendo de las políticas que apliquemos. También nos permitirá tener una copia en un centro de datos secundario.

Partiendo de la base de que en el cluster estándar eran necesarios un mínimo de tres nodos, ahora en un Stretched cluster, el máximo de nodos soportados, en la versión más actual es de 31 nodos. 

Profundizando en la característica de nodos que puede llegar a soportar este tipo de cluster, hay que destacar que soporta un máximo de 15 nodos por sitio, es decir, tenemos un sitio principal y un sitio secundario en el que podremos albergar 15 servidores ESXi. 

A su vez, será necesaria la figura del Witness Host o del nodo testigo que es un servidor VMware ESXi que puede ser virtual. La función de este servidor es la de ser el árbitro en este cluster, es decir, sería el quórum para guardar la coherencia de los datos y de la información que tiene el propio cluster.

  • VMware vSAN DE 2 NODOS O VMware vSAN ROBO
VMware vSAN ROBO.

Este tipo de cluster podría definirse informalmente como el hermano pequeño de una Stretched cluster.

Es un entorno VMware vSAN de 2 nodos o vSAN Robo. Es un Stretched cluster de dos nodos pensado para entornos muy pequeños, es decir, para oficinas remotas que no tienen infraestructura propia en las que no es necesario tener una gran capacidad de cómputo ni de almacenamiento.

Es necesario un mínimo tres nodos. En este caso, tiene truco porque son dos nodos físicos más el nodo Witness.

REQUISITOS NECESARIOS PARA MONTAR UN STRETCHED CLUSTER

  1. Necesitaremos mínimo tener un nodo por site. No tiene sentido montar un cluster de menos de dos nodos más el Witness. 
  2. Necesitaremos un nodo Witness Host. Es muy recomendable que este nodo testigo esté ubicado en un tercer site o en una tercera sede para protegernos en caso de caída o de desastre en uno de los CPDs principales de que no se caiga también este Witness Host.
  3. Debido a la replicación síncrona entre sitios, necesitaremos una conexión de 10G entre ambos sites. Esta característica en un cluster normal ya está soportado con conexión de 1 giga, pero en un Stretched cluster debido a que tenemos los dos sitios de datos, la conexión necesaria es de 10G. 
  4. Como consecuencia del anterior requisito, esta conexión deberá ser rápida y de latencia por debajo de 5 milisegundos. En estas últimas versiones de vSAN no está soportado capa 2 y capa 3, por lo tanto, podremos tener los sitios o CPDs en el mismo direccionamiento de red o incluso podemos meter un router por el medio por si tenemos diferentes redes.
  5.  Como último requisito a tener en cuenta, la única dificultad que tiene un Stretched cluster es que necesitamos licencia Enterprise para montar esta arquitectura.

FAULT DOMAINS

Teniendo en cuenta que anteriormente hemos mencionado la replicación, en este apartado explicaremos cómo funciona o cómo organiza internamente vSAN los datos.

VMware vSAN trabaja con los denominados Fault Domains o dominios de fallo. Un Fault Domain es una agrupación de servidores ESXi en los cuales la propia vSAN intentará separar los datos en diferentes Fault Domains.

En tecnología Stretched Cluster por defecto y obligatoriamente deberemos tener tres Fault Domains, uno por cada sitio de datos y uno que será el Witness Fault Domain o nodo testigo.

En un entorno tradicional, es decir, en un cluster estándar, podremos tener los dos Fault Domain que queramos agrupar por rack, o si tenemos servidores en un blade, poder agruparlos por blade, etc. 

Es muy importante recordar que en un Stretched cluster deberemos tener, obligatoriamente, 3 Fault Domains.

OBJETOS QUE TRABAJA VMs

Existe una falsa creencia de que el mínimo objeto o el objeto a la mínima expresión que trabaja vSAN son máquinas virtuales. Eso no es así. Lo que hace VMware vSAN con una máquina virtual es la segmentación de esta entre diferentes objetos o componentes. A cada uno de estos componentes le podremos aplicar una política de redundancia o de tolerancia a fallos diferente. Una máquina virtual, no por ser una única máquina, debe tener la misma redundancia en sus componentes.

Si tenemos un servidor de ficheros, por ejemplo, que tiene tres discos enormes para almacenar datos, esos tres discos obligatoriamente no tienen porqué tener la misma política o tolerancia a fallos. Este hecho es importante porque a la hora de calcular los espacios y lo que nos consumirá una replicación en un Stretched cluster, hay que calcular a nivel de objetos y no de máquina virtual

POLÍTICAS

Habiendo explicado anteriormente lo que son los objetos, pasaremos a hablar de las políticas. Para poder hacerlo, tendremos como referencia una captura de pantalla del Wizard que tiene VMware vSAN en la que podemos definir esta tolerancia a fallos en nuestros objetos.

Tolerancia de fallos Metro Storage Cluster VMware vSAN.

Recordemos que no estamos hablando de máquinas virtuales. 

Podemos tolerar múltiples fallos de un nodo, de dos nodos o de tres nodos, etc. dependiendo del tamaño que tenga nuestra VMware vSAN. Anteriormente hemos dicho que máximo 15 nodos por site e incluso podríamos configurar, en el peor de los casos, una tolerancia a fallos de 14 porque siempre que nos quede uno libre, podremos configurar esa tolerancia.

Pasamos a destacar el contenido de una tabla que resume cuántas copias del objeto son necesarias dependiendo de los fallos a tolerar que configuremos.

Tolerancia de fallos Metro Storage Cluster VMware vSAN.

Como podemos observar, cuantos más fallos a tolerar configuremos en nuestra política, más copias de ese objeto o de ese dato deberá tener la propia VMware vSAN y por lo tanto más espacio consumiremos en el Datastore.

Es interesante comentar que, en una cabina de discos, la tolerancia o el nivel de protección óptimo sería un RAID 1, es decir, no hay que calcular paridad, existe un espejo de todos los datos que conlleva que se consuma mucho espacio porque de cada uno de los componentes, vSAN deberá almacenar el doble para garantizar esa protección en RAID 1.

Existen diferentes tipos de protección como pueden ser RAID 5 y RAID 6 en los que se ahorra un poquito más de espacio.

En estos tipos de protección es necesario trabajar y calcular paridades dentro de la vSAN, pero no consumes tanto espacio. En la tabla podemos observar que el ahorro de espacio de en RAID 5 es de un tercio más o menos y si metemos RAID 6 conseguimos ahorrar un poquito más.

POSIBLES ESCENARIOS DE FALLO

Escenarios de fallo Metro Storage Cluster VMware vSAN

En la siguiente imagen, podemos observar los posibles escenarios de fallo que podría soportar esta tecnología. 

  • ESCENARIO DE FALLO: SPLIT-BRAIN O SEGMENTACIÓN DE RED

El primer escenario de fallo con el que puede soportar, parte de lo que hemos comentado anteriormente de que el Stretched cluster funciona con dos sitios de datos geográfica o preferiblemente separados.

En este escenario, puede ocurrir que la línea de comunicaciones entre ambos CPDs se corte. En este caso, entraría en acción el Witness o nodo testigo en un tercer centro. Lo que este último nodo haría sería determinar cuál es el sitio predefinido y provocar un HA Restart en nuestras máquinas virtuales para que, si el sitio secundario se ha quedado aislado porque se ha caído el router o porque se a caído la línea de comunicación, las máquinas virtuales automáticamente arrancarán en ese sitio Preferred.

  • ESCENARIO DE FALLO: CAIDA DEL CPD POR COMPLETO

En este caso, hay que resaltar que, si se nos cae el CPD de manera total, no existe la posibilidad de actuación del nodo Witness.

Lo que debemos hacer es ejecutar el HA y como consecuencia de ello, las máquinas arrancarán automáticamente en el sitio secundario.

  • ESCENARIO DE FALLO: CAIDA DEL NODO WITNESS HOST

En este último caso, no pasaría absolutamente nada porque el Witness Host es un elemento de testigo en caso de que los dos sites no estén operativos. Si los dos sites están operativos, en la comunicación que mantienen para intercambiar o replicar información, está incluida la información relacionada con los metadatos para saber que ambos sites están activos. 

Por tanto, mientras los dos sites estén activos, si tenemos que realizar alguna operativa en el Witness, lo tenemos que reiniciar, etc. no pasa absolutamente nada.

CASOS DE USO

En este apartado se comentarán algunos casos de uso que podríamos tener con esta tecnología.

Encora Webinar. Casos de uso con Metrocluster con VMware vSAN
Casos de uso de VMware vSAN
  • PLANNED MAINTENANCE

Este caso de uso hace referencia a poder realizar mantenimientos planificados. 

En repetidas ocasiones, en nuestro centro de datos tenemos que realizar intervenciones eléctricas, mantenimientos que requiere apagar equipos, etc. Con un Stretched cluster podríamos apagar un CPD y tener los datos o tener los servicios activos en la otra parte de forma totalmente transparente para el consumidor final.

  • DISASTER AVOIDANCE

Todo ello, nos podía ayudar a protegernos ante posibles desastres (huracanes, terremotos, incendios, etc). Con una tecnología de Stretched cluster geo distribuida, si tenemos una contingencia en uno de nuestros centros, por un evento no deseado, podemos recuperar rápidamente en el otro centro. 

  • AUTOMATED RECOVERY

Teniendo en cuenta que anteriormente hemos comentado que se integra perfectamente con HA, con vMotion, con otras tecnologías de VMWare, etc., tener un Stretched cluster nos ayudará a automatizar ese Recovery. Con HA arrancarían las máquinas automáticamente, tendríamos tiempos de recuperación RTO muy bajos (el tiempo que tarda que tarda una máquina virtual en arrancar). 

En resumen, nos sería muy útil para este tipo de casos de contingencia.

Esperamos que os haya gustado este webinar.  

Recordad que podéis consultar todos los webinars y que os podéis suscribir a la Encora Newsletter para estar al día de todas nuestras novedades. 

Gracias por compartirlo en redes sociales. Esperamos vuestros comentarios.

¡Hasta pronto!

Si estás interesado en contactar con el Encora Team para hablar de un proyecto para tu empresa, pulsa en el botón y te llamamos.

Compártelo en redes sociales

SUSCRÍBETE A LA ENCORA NEWSLETTER

SÉ EL RPIMERO EN ESTAR INFORMADO DE LA ACTUALIDAD TIC CON ENCORA

estamos a tu lado en este momento crítico

Nuestro equipo de expertos te ayuda inmediatamente