Seguro que habéis escuchado un montón de veces el término Metro-Clúster, sobre todo cuando hablamos de proyectos de continuidad de negocio o de recuperación ante desastres y fundamentalmente asociado a un fabricante de almacenamiento, NetApp, porque fue el primero en impulsar esta tecnología con dicho nombre.

Hoy en día, prácticamente la totalidad de los fabricantes de almacenamiento del mercado, tienen una solución de metro-clúster en su portfolio y el propósito de este articulo es acercaros a este tecnología y su aplicación en el mundo de la virtualización, desde un punto de vista de agnosticismo de fabricante.

vmware-seminar.jpg

¿Que es un «Metro-Clúster»?

Un Metro-Cluster es una configuración que permite crear un clúster entre varios (al menos dos) arrays de almacenamiento ubicados en distintas ubicaciones geográficas. Hasta ahí, parece sencillo, pero la principal característica es que podemos trabajar en ambos sites de forma simultánea, porque «en teoría» el disco se haya «distribuido y replicado» entre los dos sites geográficos.

Es decir, sobre el papel, un servidor conectado al Datacenter A, podrá acceder a sus discos en la cabina a través de «paths» en el site A y en el site B.

Como apreciaréis, pongo muchas comillas, porque todo esto depende de la arquitectura de acceso a disco, por la que opte el fabricante de almacenamiento en su concepto de Metro-Clúster. Básicamente tenemos dos tipos de solución:

Fuente: vmware.com

Fuente: vmware.com

Como supondréis, la opción de acceso a datos uniforme, es la más extendida a día de hoy, además ser la más lógica, ya que que al tener el acceso a disco distribuido se aprovecha al máximo las capacidades y funcionalidades del Metro-Clúster. Prácticamente, pasaremos a tener un «Datastore geo-distribuido».

Es por ello, que tomaremos esta arquitectura como la base para el concepto de Metro-Clúster.

¿Cómo lo integramos en un entorno virtualizado?


A estas alturas, seguro que habéis visto en algunos diagramas, escrito «Stretched Cluster». ¿Y esto qué es?

Fuente: vmware.com

Pues, simplemente se trata de un clúster de vSphere compuesto de nodos en ambas ubicaciones geográficas. Pongamos el ejemplo, de caída de la infraestructura del site A, las VMs a través de la HA del cluster vSphere, se reiniciarán en el site B. Tan sencillo como esto. 

También podremos hacer vMotion (o Metro vMotion dependiendo de las configuraciones) de VMs entre ambos sites. Y la clave de todo esto, no es más que el «Datastore distribuido» entre ambas ubicaciones.

Obviamente, para poder tener toda nuestra infraestructura lo más ajustada posible, tendremos que jugar con las reglas de afinidad en nuestro clúster 😉

Para más información de los Stretched Cluster os recomiendo la guia de VMware de vSphere Metro Storage Cluster o vSphere vMSC.

¿Y esto qué aporta a mi negocio?

Obviamente, estas soluciones tienen un coste económico elevado, pero si valoramos todo aquello que nos aporta, son relativamente económicas en términos de funcionalidad coste.

Lo primero que hay que valorar, es que es una solución pensada para empresas que necesiten realmente un RPO/RTO = de prácticamente 0, es decir, una pérdida de servicio y/o datos por muy leve que sea, impactarán de forma catastrófica en el negocio. Recalco mucho este aspecto, porque no siempre todos los negocios necesitan un RTO/RPO de esta dimensión y a veces, una pérdida de 5 minutos de datos y una parada de 1 hora es totalmente tolerable. Cada negocio, tiene sus necesidades.


Cabe señalar que el principal requerimiento para el funcionamiento de esta solución son las comunicaciones entre ambos sites, que por regla general serán con una latencia de menos de 5ms y fibra óptica dedicada, aunque dependerá de arquitecturas y diseños.

Como cualquier solución del mercado tiene una serie de ventajas:

  • RTO/RPO mínimo.
  • Fácil gestión y curva de aprendizaje muy rápida.
  • No hay necesidad de Site Recovery Manager (según configuraciones).
  • Ofrece protección frente a múltiples fallos y escenarios catastróficos.

Pero también una serie de desventajas entre otras:

  • Alta exigencia en comunicaciones, 5-10ms de latencia (según diseños).
  • Replicación síncrona para que vSphere vMSC funcione.
  • Ambos sistemas de almacenamiento (A y B) deben ser iguales y su crecimiento paralelo.
  • Diseño perfecto desde el inicio.
  • Complejidad en la configuración.
  • ISL en Fabric SAN.

Cada fabricante le pone su nombre a la solución, bien sea EMC con su VPLEXNetApp con su MetroCluster o HDS con su GAD, por mencionar algunos. Todos ellos tienen sus puntos fuertes y sus funcionalidades, que se ajustarán mejor a las necesidades y requerimientos de cada proyecto.

Con esto os hemos aproximado una visión global de esta tecnología que en Ncora os podemos ayudar a implementar con el fabricante que más os empatice. ¡Hasta el próximo post!

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Post Relacionados: