MetroCluster 8.3 ¡Clustered!

Como sabéis, en las últimas semanas, desde NetApp, hemos lanzado un montón de novedades que poco a poco os estamos contando por aquí. Dentro de las novedades de clustered Data ONTAP 8.3, MetroCluster era una de las más esperadas.

MetroCluster 8.3 es uno de los productos que más éxito ha tenido en Insight 2014 Berlin, nuestro evento técnico más importante del año, con un lleno prácticamente absoluto en todas las sesiones.

 

MetroCluster: la solución perfecta para la disponibilidad total

La mayoría de las causas de interrupciones no planificadas de los servicios del almacenamiento son por fallos de hardware, fallos de software, error humano o fallos eléctricos o de suministro. Frente a este tipo de fallos internos al centro de datos, Clustered Data ONTAP hace un trabajo excepcional garantizando la disponibilidad de los datos. Pero hay otro tipo de problemas que pueden causar indisponibilidad de servicio y que son externos al centro de datos, como pueden ser los desastres a una escala mayor (tormentas, terremotos, incendios, inundaciones, apocalipsis zombie, etc.). MetroCluster en Clustered Data ONTAP es la única solución que protege también contra este otro tipo de fallos.

 

MetroCluster 8.3: Características

Estás son las características principales de MetroCluster en Clustered Data ONTAP (o MCC como se le conoce internamente):

  • Protección contra las principales causas de interrupción del servicio en el centro de datos.
  • Extensión de las operaciones no-disruptivas a otro centro de datos, poniendo un clúster de dos nodos en cada sede y pudiendo separar estas hasta 200km. 
  • Recuperación transparente frente a fallos.
  • Conmutación entre centros de datos con un solo comando
  • Soporte para entornos NAS y SAN
  • Integración con las características de clustered Data ONTAP (SnapMirror, NDO, Almacenamiento Virtualizado, Multi-Tenancy, QoS, FlexArray etc.)
  • No necesita licencia adicional 

¡MetroCluster 8.3 con HA local!

La principal diferencia con versiones anteriores de MetroCluster es que ahora disponemos de dos clúster (uno en cada sede) que replican de forma síncrona entre ellos. Cada uno de los clúster cuenta con una pareja de controladoras en HA que funcionan en activo-activo disponiendo por tanto de 4 controladoras dando servicio simultáneamente. Estas 4 controladoras tienen que ser exactamente iguales.

La capacidad de failover en local en cada sede era una de las funcionalidades más demandadas por nuestros clientes. Gracias al failover en local se elimina la necesidad de conmutar a la otra sede en los casos de fallo de componentes, fallo de un nodo, fallos de red, etc. y además aporta la posibilidad de realizar actualizaciones y otras operaciones de mantenimiento sin necesidad de conmutación remota. De esta manera la conmutación a la sede remota queda únicamente para los casos de desastres reales o sucesos que afecten completamente a uno de los centros de datos.

 

Arquitectura.png

 

Incluso en estos casos en los que es necesario conmutar a la sede remota, se trata de un proceso sencillo que solo requiere un comando para el “switchover” y tres comandos para “switchback”. Esta conmutación, gracias a MetroCluster-TieBreaker, se puede automatizar.

En esta versión además se introduce la posibilidad de comprobar mediante un comando si la configuración del MetroCluster es la correcta. También existe otro comando que permite simular una conmutación sin llegar realmente a realizarla.

 

Por lo demás la arquitectura es muy similar a la arquitectura anterior de MetroCluster con los siguientes elementos:

  • Clúster de dos nodos en cada sede
  • 4 switches para crear la SAN de backend (dos por sede)
  • Hasta 4 ISL por fabric para interconectar las dos sedes
  • Bandejas de discos o array de terceros en ambas sedes

 

¿Cómo funciona?

El funcionamiento es bastante intuitivo. Cada una de las controladoras de los dos clúster tiene discos asignados tanto de la sede local como de la sede remota. Los datos se van copiando de forma síncrona mediante SyncMirror entre los discos de ambas sedes. Cada controladora además replica el contenido de su NVRAM tanto a su pareja dentro del clúster local como a una de las controladoras del clúster remoto. Así mismo existe otra replicación de la configuración de los SVM de cada clúster.

Durante el funcionamiento normal, los dos clúster estarán dando servicio independientemente, cada uno con sus SVM. Al mismo tiempo en el clúster remoto se almacena toda la información correspondiente a la configuración de estos SVM. En caso de fallo local, cada clúster se encargará de responder al mismo según las necesidades (LIF Failover, Takeover, etc.).

 

disaster.png

 

En caso de un fallo generalizado en alguna de las sedes se puede proceder a levantar (“switchover”) todo el servicio de la sede afectada en el clúster correspondiente a la sede superviviente. Esta operación se puede hacer de forma manual o puede ser automatizada mediante MC-TieBreaker. En este caso la operación completa nunca supera los 120 segundos. Una vez recuperada la sede afectada por el fallo, podremos resincronizar los datos mediante SyncMirror y proceder a devolver el servicio a su sede original (“switchback”).

 

Más información:

MetroCluster 8.3 RC1 Clustered Documentation

 

¡Espero que os haya resultado interesante!

¡Hasta la próxima!

 

Jaime

 

Me llamo Jaime Balañá, trabajo para NetApp desde 2010 y actualmente soy Technical Account Manager. 

Twitter: @jbalana