NetApp Tech OnTap
     

Utilización del Site Recovery Manager de VMware para simplificar la recuperación ante desastres

No hay nada más espantoso que la perspectiva de tener que recuperar todo un centro de datos tras un desastre y la inclusión de una infraestructura virtual en el entorno puede complicar aún más la situación. El Site Recovery Manager (SRM) de VMware® se ha diseñado con el fin de simplificar y acelerar la recuperación ante desastres para infraestructuras de VMware, e incluye pruebas que no afectan al funcionamiento del sistema con las que podrá asegurarse de que su plan de recuperación del centro de datos funcionará antes de que necesite usarlo.

SRM permite la conmutación por error automatizada de la infraestructura virtual de máquinas virtuales (VM) y servidores; se basa en las posibilidades de replicación existentes proporcionadas por proveedores de almacenamiento (como la tecnología SnapMirror® de NetApp®) en vez de suministrar sus propios mecanismos de replicación de datos para transmitir la información de las VM al site de recuperación ante desastres (DR). NetApp ha trabajado en estrecha colaboración con VMware para que SRM saque el máximo partido de las funciones avanzadas de SnapMirror y otras tecnologías de NetApp.

En este artículo analizaré cuáles son las dificultades de la planificación de la DR y explicaré cómo VMware SRM (junto con las funciones de almacenamiento de NetApp) puede simplificar mucho la DR para la infraestructura virtual.

Planificación de la recuperación ante desastres

La planificación y la ejecución son los aspectos más importantes de la recuperación ante desastres. Hay muchas catástrofes naturales, desastres causados por el hombre y fallos de los ordenadores que pueden afectar a la disponibilidad de los datos. A continuación se enumeran algunos de los problemas más habituales que ocurren hoy en día con la planificación de la DR.

No hay plan. Para algunas personas, el coste y la complejidad de la DR son simplemente demasiado grandes dadas las actuales limitaciones de recursos y de presupuesto. No hay tiempo para hacer una parada programada y el proceso de crear (y, lo que es más importante, comprobar) un auténtico plan de DR se aplaza continuamente.

Incapacidad de cumplir el objetivo de punto de recuperación (RPO) y el objetivo de tiempo de recuperación (RTO).
Para mucha gente, los objetivos RPO y RTO exigidos por los procesos empresariales no se cumplen porque el plan depende de una infraestructura cara, operaciones de restauración lentas o instalaciones del sistema partiendo de cero. Los recursos necesarios para implantar y ejecutar un plan de prueba son demasiado exigentes, especialmente si nunca se ha producido un verdadero desastre en la empresa.

Administración en lugar de RPO/RTO.
Cuando se conmutan los procesos empresariales para recuperarse de un desastre, hay muchos pasos que son lentos y han de realizarse de forma manual. A menudo, aunque se escriben scripts personalizados que se utilizan para simplificar algunos de estos procesos, son los procesos que deben seguirse los que afectan al verdadero RTO que cualquier solución de DR puede proporcionar. Veamos cuál es el flujo de un proceso de recuperación ante desastres normal:

  1. Se produce una situación que obliga a conmutar por error a un site de DR. (Esta puede ser debida a una interrupción del suministro eléctrico demasiado larga para que la empresa resista sin llevar a cabo la conmutación o un desastre que provoque la pérdida de datos o equipos en el site de producción).
  2. El equipo de DR da los pasos necesarios para confirmar el desastre y toma la decisión de conmutar por error.
  3. Suponiendo que se hayan hecho las pruebas necesarias para confirmar que la replicación de datos es correcta y que el site de DR puede utilizarse:
    • El almacenamiento replicado se le debe ofrecer a los sistemas ESX del site de DR.
    • Los sistemas deben estar conectados con el almacenamiento.
    • Las máquinas virtuales correctas deben agregarse al inventario de los sistemas ESX.
    • Si el site de DR está en un segmento distinto de red que la de producción, habrá que reconfigurar cada VM para la nueva red.
    • El personal del departamento de informática debe asegurarse de que el entorno se carga como es debido, activándose los sistemas y servicios en el orden correcto para evitar conflictos de nombres o direcciones IP.
  4. En cuanto el entorno de DR esté listo, los procesos empresariales estarán respaldados por el equipo del site de DR. Tarde o temprano, el site de producción volverá a estar disponible o los equipos que se hayan perdido se sustituirán.
  5. Los cambios aplicados a los datos durante el periodo en que el site de DR haya dado respaldo a los procesos empresariales en ocasiones se tendrán que volver a replicar en el site primario. (Para ello, debe invertirse la replicación).
  6. Los procesos que tuvieron lugar en el paso 3 se deben volver a ejecutar.
  7. Una vez que se haya recuperado el entorno de producción, debe restablecerse el programa de replicación y las relaciones originales (desde el site de producción al site de DR ).

En general, los procesos de DR pueden ser largos, lentos y son propensos a errores humanos. Básicamente hay que repetir los mismos procesos —con los mismos problemas— para devolver el site primario a la actividad. No obstante, una solución de DR es una buena póliza de seguros para cualquier empresa. La comprobación periódica del plan de DR es imprescindible para poder confiar en la solución.

Esta comprobación generalmente supone repetir los pasos 1 a 7 de forma programada. Esto puede ser costoso (en horas de trabajo y tiempo de inactividad) y puede afectar a las operaciones informáticas normales. Debido a limitaciones del entorno físico y a la dificultad de llevar a cabo pruebas de DR, la mayoría de los centros de datos sólo pueden hacerlo unas pocas veces al año, a lo sumo, y algunos no pueden hacer ningún tipo de comprobación realista. SRM puede automatizar el proceso de DR y reducir la posibilidad de que un error humano afecte a la recuperación ante desastres.

Características básicas de SRM

La parte más difícil y más lenta de la conmutación por error de la DR en un entorno VMware es la ejecución de los pasos necesarios para conectar, inventariar, reconfigurar y poner en marcha máquinas virtuales en un site de DR. VMware ha resuelto estos problemas con la introducción de Site Recovery Manager, que simplifica la gestión de todo el proceso de DR.
SRM tiene tres componentes principales:

  • Descubrimiento/configuración
  • Conmutación por error
  • Comprobación

La parte más importante de la DR es la planificación de la respuesta que se dará en caso de producirse un desastre. SRM permite programar de forma anticipada la respuesta ante el desastre; está es una de las ventajas más importantes de la solución. Encender o apagar cientos de servidores puede ser un enorme desafío, especialmente en mitad de una crisis. Activar los sistemas en un orden determinado es algo mucho más que un desafío.

El plan de recuperación creado durante la fase de configuración de SRM permite configurar con antelación todo el plan. SRM permite crear el plan en muy poco tiempo gracias a las funciones de descubrimiento que incorpora y a la estrecha integración con Virtual Center. Una vez existe un plan, éste puede ejecutarse perfectamente sin fallos y con una intervención mínima por parte del usuario. (Basta con iniciar el proceso de recuperación en caso de producirse un desastre). Crear un plan como este utilizando los métodos de DR tradicionales puede llevar meses —incluso años— e incluir un montón de pasos manuales propensos a errores.

La solución de comprobación automática de SRM permite hacer pruebas de DR que no afectan a la replicación en curso (para la DR) ni a los SLA, ni siquiera mientras se arrancan varias máquinas virtuales y se comprueban conjuntos de datos. Además, pueden clonarse conjuntos de datos replicados y usarse para pruebas, etcétera.

Utilizando la tecnología de clonación de NetApp en combinación con la herramienta SRM para ejecutar operaciones de la máquina virtual, podrá activar un site y ejecutar pruebas en él sin afectar a la producción... todo ello desde una sola ubicación sitio y prácticamente sin la intervención del usuario. Esta es una forma muy eficaz de ejecutar una serie de pruebas para validar una aplicación o un conjunto de datos concretos sin afectar al site de producción ni a los SLA acordados.

SRM y el almacenamiento de NetApp

SRM habilita dos entornos VMware independientes, el site primario y el de DR, que se comunican entre sí. Las VM del site primario se pueden reunir de forma fácil y rápida en grupos de protección que comparten recursos comunes y que pueden recuperarse juntos. Estos grupos de protección se configuran en planes de recuperación en el site de DR.

En un entorno de almacenamiento de NetApp, SnapMirror pueden configurarse para replicar máquinas virtuales desde el almacenamiento local de NetApp hasta un sistema remoto, lo que da lugar a grupos de replicación sólo de lectura en ubicaciones remotas. Una ventaja de SnapMirror es que ofrece una gran flexibilidad a la hora de configurar el almacenamiento del site de DR, reduciendo considerablemente el coste del almacenamiento de la DR. Muchas soluciones de replicación exigen que se disponga de una configuración de almacenamiento idéntica en ambas ubicaciones. Con SnapMirror —siempre que tenga almacenamiento de NetApp en ambos sitios— pueden replicarse plataformas de gama alta en otras de gama baja, discos FC en discos SATA y SAN Fibre Channel en iSCSI.

Tra'fico que pasa por conmutadores de red

Figura 1) SnapMirror solo o con SRM.
Se pueden replicar de forma flexible configuraciones de almacenamiento
de gama alta (plataformas de alto rendimiento, discos FCP,
configuraciones SAN FC) en soluciones menos caras (plataformas
de almacenamiento más baratas, discos SATA, iSCSI).

VMware SRM descubre estas relaciones y permite programar con anticipación una respuesta, incluyendo promocionar los grupos de replicación para hacerlos de escritura, montar sistemas de archivos o arrancar sistemas.

Sobre la ejecución de un plan de DR en un entorno de almacenamiento de NetApp, SRM:

  • Desactivará e interrumpirá las relaciones de SnapMirror.
  • Asociará los LUN con los igrupos existentes (los igrupos son tablas de nombres de puertos de todo el mundo —WWPN— de hosts que tienen acceso a los LUN).
  • Activará hosts ESX de la DR para que vuelvan a explorar y detectar el almacenamiento.
  • Reconfigurará las VM tal y como están definidas para la red en el site de DR.
  • Pondrá en marcha las VM en el orden definido en el plan de recuperación.

Por lo que hace a la ejecución de una prueba de DR en un entorno de NetApp, SRM:

  • Creará volúmenes FlexClone® de los volúmenes FlexVol® en el sistema de almacenamiento de la DR.
  • Asociará los LUN contenidos en estos volúmenes FlexVol con igrupos existentes.
  • Activará hosts ESX de la DR para que vuelvan a explorar y detectar el almacenamiento.
  • Conectará adaptadores de red de VM a una red privada de tipo "Burbuja de prueba".
  • Reconfigurará las VM tal y como están definidas para la red en el site de DR.
  • Pondrá en marcha las VM en el orden definido en el plan de recuperación.

Conclusión

En resumen, al automatizar las partes manuales de la planificación de la DR y que consumen muchos recursos, la conmutación por error y las pruebas, como por ejemplo asociar las VM con el almacenamiento, arrancar en el orden correcto y solucionar el problema de las direcciones IP y los esquemas de denominación, SRM simplifica muchísimo la DR en entornos virtuales. El aumento de los costes de proteger una VM es casi cero desde el punto de vista operativo. Los únicos gastos reales son el espacio en disco ocupado en el site de destino y el ancho de banda necesario para gestionar el intercambio de datos de esta VM. Los servidores y el almacenamiento virtuales se conectan con la mínima dificultad posible para los administradores. El plan de DR y los procedimientos de recuperación pueden crearse en muy poco tiempo utilizando una cantidad de recursos ínfima.

¿Qué opina sobre las DR para entornos VMware o Site Recovery Manager?

Haga preguntas, intercambie ideas y comparta sus opiniones en la comunidad online de NetApp.

Darrin Chapman

Darrin Chapman
Experto en protección de datos y responsable de marketing técnico
NetApp

Darrin Chapman es una persona a la que puede preguntarle cualquier cosa sobre recuperación ante desastres o backups y recuperaciones en NetApp. Ha estado involucrado en casi todas las guías de buenas prácticas sobre protección de datos de NetApp desde 2002 y en su tiempo libre diseña cursos de formación para el personal técnico y los clientes de NetApp. Licenciado en ingeniería eléctrica, Darrin trabajó durante varios años en el campo de la arquitectura de sistemas en AT&T, Nortel y EMC.

Investigue ma's