Planes de recuperación y conmutación por error automatizada

Un plan de recuperación de Azure Site Recovery es una secuencia estructurada y ordenada de pasos que coordina la conmutación por error conjunta de varias máquinas virtuales. En lugar de conmutar por error cada máquina virtual individualmente, un plan de recuperación las agrupa en grupos que realizan la conmutación por error en secuencia, lo que garantiza que la infraestructura (base de datos, middleware y web) se inicie en el orden correcto, tal como ocurriría durante la implementación inicial.

Para crear un plan de recuperación, seleccione el sitio de origen (región principal) y el sitio de destino (región secundaria) y, a continuación, agregue las máquinas virtuales que desea incluir. El asistente del plan crea automáticamente un grupo predeterminado, pero puede agregar más grupos para controlar la secuencia de conmutación por error. Las máquinas virtuales del mismo grupo realizan la conmutación por error simultáneamente; los grupos se ejecutan en el orden numérico indicado.

Para una aplicación típica de tres niveles, el plan de recuperación debe tener tres grupos:

• Grupo 1 — máquinas virtuales del nivel de base de datos (deben iniciarse primero)
• Grupo 2 — máquinas virtuales del nivel de aplicación o middleware
• Grupo 3 — máquinas virtuales del frontend web (se inician al final)

Cada grupo espera a que el grupo anterior complete correctamente la conmutación por error antes de iniciarse. Esto reproduce el orden correcto de inicio y evita que las máquinas virtuales del nivel web se inicien antes de que la base de datos esté lista para aceptar conexiones.

Los planes de recuperación admiten acciones previas y acciones posteriores en cada límite entre grupos. Estas pueden ser:

• Acciones manuales — pausar la conmutación por error y esperar a que una persona la confirme (por ejemplo, «Comprobar que la base de datos está lista»)
• runbooks de Azure Automation — ejecutar automáticamente un script (por ejemplo, actualizar los registros DNS o deshabilitar el modo de mantenimiento)

El uso de runbooks de Automation permite realizar una conmutación por error totalmente automatizada, sin intervención humana, para las cargas de trabajo de nivel 1.

Azure Site Recovery admite dos tipos de conmutación por error:

• Conmutación por error planeada — se inicia antes de un evento conocido (por ejemplo, el mantenimiento del centro de datos). La máquina virtual principal se apaga correctamente, los datos se sincronizan y, a continuación, se inicia la máquina virtual secundaria. No se pierden datos.
• Conmutación por error no planeada — se desencadena durante un desastre real. Es posible que la máquina virtual principal no esté disponible, por lo que ASR utiliza el punto de control de replicación más reciente. Puede producirse cierta pérdida de datos, según el RPO.

Después de una conmutación por error, las máquinas virtuales recuperadas en la región secundaria se encuentran en un estado de confirmación pendiente. Debe confirmar la conmutación por error para indicar que el sitio secundario es ahora el sitio activo y que no desea revertir la operación. Una vez confirmada, puede configurar la replicación inversa para proteger el sitio secundario y, finalmente, realizar la conmutación por recuperación a la región principal cuando esta se haya restaurado.

Después de confirmar una conmutación por error, los elementos replicados en la región principal original dejan de replicarse activamente. Para restaurar la protección, debe restablecer la protección de los elementos, lo que invierte la dirección de replicación para que la nueva región principal (antes secundaria) replique los datos en la región principal original. El restablecimiento de la protección lleva tiempo y debe iniciarse en cuanto la región principal original vuelva a estar disponible.

Cada paso de un plan de recuperación contribuye al RTO total. Entre los principales consumidores de tiempo se incluyen:

• Tiempo de inicio de las VM (2-5 minutos por VM)
• Tiempo de preparación de la aplicación (inicialización del grupo de conexiones de la base de datos y calentamiento de la caché)
• Propagación de DNS después de los cambios de IP
• Tiempo de espera de las puertas de aprobación manual

Mida cada paso durante las conmutaciones por error de prueba y súmelos para calcular su RTO real y compararlo con el objetivo.

Después de una conmutación por error, las VM de la región secundaria tienen direcciones IP diferentes. En el caso de las aplicaciones que exponen un nombre DNS público, debe actualizar el DNS para que apunte a las nuevas IP. Use un runbook de Azure Automation como acción posterior a la conmutación por error para actualizar Azure DNS o el estado de los puntos de conexión de Traffic Manager y redirigir el tráfico automáticamente, evitando un paso manual que podría retrasar el RTO.

Durante una conmutación por error, la vista de trabajos del portal de Azure en el almacén de Recovery Services muestra en tiempo real el progreso de cada paso del plan de recuperación. Puede ver qué grupo se está ejecutando, qué VM se han iniciado correctamente y si hay scripts o acciones manuales pendientes. Supervisar esta vista permite al equipo de recuperación intervenir rápidamente si falla algún paso.

Estos son algunos procedimientos recomendados clave para los planes de recuperación:

• Mantenga los grupos pequeños (5-10 VM) para limitar el radio de impacto si un grupo falla
• Use runbooks de Automation en lugar de acciones manuales siempre que sea posible para reducir el RTO
• Documente el tiempo de inicio previsto de cada grupo para poder calcular el RTO
• Ejecute una conmutación por error de prueba al menos trimestralmente para validar el plan
• Revise y actualice el plan cada vez que agregue nuevas VM o cambie la arquitectura de la aplicación

Ponga a prueba sus conocimientos sobre los conceptos de Microsoft Azure Fundamentals (AZ-900) de esta lección.

En esta lección ha aprendido que un plan de recuperación coordina la conmutación por error ordenada de varias VM, con acciones previas y posteriores en cada grupo; la conmutación por error no planeada usa el último punto de comprobación de replicación, mientras que la conmutación por error planeada no implica ninguna pérdida de datos; y, después de una conmutación por error, debe confirmar y volver a proteger los recursos para restaurar la protección de DR. A continuación, exploraremos cómo probar los planes de DR sin afectar al entorno de producción.