Pruebas y ejecución de la conmutación por error

Un plan de recuperación ante desastres que nunca se ha probado no es más que una hipótesis. La conmutación por error de prueba permite validar que las máquinas virtuales se inician correctamente, que las aplicaciones arrancan y que la conectividad de red funciona en la región de destino, todo ello sin interrumpir el entorno de origen ni detener la replicación en curso. Muchas organizaciones descubren que sus planes de recuperación ante desastres tienen deficiencias únicamente cuando ocurre un desastre real, precisamente cuando un plan defectuoso causa el máximo daño. Las pruebas periódicas de conmutación por error son un requisito de cumplimiento para la mayoría de los marcos normativos.

ASR admite tres tipos de acciones de conmutación por error. La conmutación por error de prueba crea copias de las máquinas virtuales conmutadas por error en una red aislada (usted especifica la VNet de destino) sin afectar a la replicación ni al entorno de origen. La conmutación por error planeada se utiliza para migraciones o tareas de mantenimiento programadas: primero sincroniza los cambios restantes y, después, apaga el origen antes de realizar la conmutación por error. La conmutación por error no planeada (utilizada durante un desastre real) realiza la conmutación por error inmediatamente desde el punto de recuperación más reciente, sin esperar a una sincronización final.

Para ejecutar una conmutación por error de prueba en el portal, seleccione el elemento protegido, haga clic en Test Failover, elija un punto de recuperación (el último coherente frente a bloqueos, el último coherente con la aplicación o un momento específico) y seleccione una red virtual de destino (normalmente, una VNet de prueba aislada y dedicada). ASR inicia la máquina virtual en la región de destino utilizando los discos de réplica. La máquina virtual de prueba aparece junto a la réplica, pero es completamente independiente: el entorno de producción no se ve afectado. Después de realizar la prueba, haga clic en Cleanup test failover para eliminar las máquinas virtuales de prueba.

Durante la conmutación por error, seleccione un punto de recuperación dentro de la ventana de retención de ASR. Las opciones son: Latest (lowest RPO): el punto de recuperación más actual y coherente frente a bloqueos, que minimiza la pérdida de datos. Latest processed: el punto procesado más recientemente, que puede tener un retraso de algunos minutos. Latest app-consistent: el punto de recuperación más reciente coherente con la aplicación, que puede ser más antiguo, pero garantiza una recuperación limpia de la aplicación. Custom: un punto de recuperación anterior específico para recuperar un estado correcto conocido previo a un incidente.

Un plan de recuperación agrupa varias máquinas virtuales protegidas y define la secuencia y el momento de su conmutación por error. Puede especificar qué máquinas virtuales se inician primero, como los servidores de bases de datos antes que los servidores de aplicaciones; agregar puertas de aprobación manual para pausar la conmutación por error y permitir la validación humana; e insertar runbooks de Azure Automation para ejecutar scripts previos y posteriores a la conmutación por error, como actualizar registros DNS, configurar equilibradores de carga o enviar notificaciones. Los planes de recuperación se pueden probar de forma independiente mediante una conmutación por error de prueba.

Una conmutación por error de prueba ofrece la oportunidad de medir su RTO (Recovery Time Objective) real. Inicie un cronómetro cuando comience la conmutación por error y deténgalo cuando la aplicación esté completamente operativa y accesible para los usuarios. Normalmente, una conmutación por error de Azure a Azure se completa en 15–30 minutos para una sola máquina virtual, pero las aplicaciones de varios niveles con dependencias pueden tardar más. Documente los pasos que añadan tiempo inesperado, como la propagación de DNS o el calentamiento de la aplicación, y corríjalos antes de la siguiente prueba.

Después de una conmutación por error planeada, por ejemplo, al migrar a una nueva región, ejecute Commit para finalizar la conmutación por error. La confirmación detiene la replicación desde el origen y marca las máquinas virtuales de destino como las nuevas máquinas virtuales principales. Una vez confirmada, puede habilitar la reprotección para invertir la dirección de la replicación y convertir la región de origen original en el nuevo destino de recuperación ante desastres. Esto le permite realizar una conmutación por recuperación a la región original una vez resuelto el incidente.

La conmutación por recuperación es el proceso de devolver las cargas de trabajo a la región original después de un desastre o una migración planeada. Los pasos son: volver a proteger las máquinas virtuales conmutadas por error (invirtiendo la replicación para replicar desde la nueva instancia principal hacia la región original), esperar a que se complete la sincronización inicial y, después, realizar una conmutación por error planeada de vuelta a la región original. La conmutación por recuperación requiere que la infraestructura de origen original siga intacta; si fue destruida, es posible que deba reconstruir la zona de aterrizaje antes de realizarla.

Después de una conmutación por error de prueba, debe ejecutar Cleanup test failover en el portal para eliminar las máquinas virtuales de prueba y sus discos asociados. Si no realiza la limpieza, las máquinas virtuales de prueba seguirán ejecutándose y acumulando costos de proceso. El paso de limpieza también restablece el estado de conmutación por error de prueba del elemento protegido, lo que le permite ejecutar otra prueba en el futuro. Automatizar la limpieza, por ejemplo, programándola para una hora después del inicio de la prueba mediante un runbook de Automation, evita que las máquinas virtuales de prueba olvidadas sigan ejecutándose durante días.

Cada prueba de recuperación ante desastres debe generar un informe del simulacro de recuperación ante desastres que registre: la fecha y el escenario probados, los puntos de recuperación utilizados, el RTO y el RPO alcanzados, los problemas detectados y las acciones correctivas realizadas. Esta documentación cumple los requisitos de los auditores para marcos como ISO 27001 y SOC 2, que exigen pruebas periódicas de recuperación ante desastres. Almacene los informes de los simulacros en una ubicación segura a la que tengan acceso tanto los equipos de TI como los de continuidad empresarial.

Los precios de Azure Site Recovery se aplican por instancia protegida y por mes; la tarifa cubre tanto el servicio de replicación como la orquestación. También se cobra el almacenamiento utilizado por los discos administrados de réplica en la región de destino y por la cuenta de almacenamiento de caché durante la replicación. La transferencia de datos salientes entre regiones de Azure para el tráfico de replicación se cobra según las tarifas normales de salida, a diferencia de Azure Backup, donde la salida entre regiones emparejadas es gratuita. Para la replicación de entornos locales a Azure, las licencias de Windows Server para las máquinas virtuales de Azure pueden utilizar Azure Hybrid Benefit para reducir los costos.

Compruebe sus conocimientos sobre los conceptos de Microsoft Azure Fundamentals (AZ-900) tratados en esta lección.

En esta lección ha aprendido que la conmutación por error de prueba valida su plan de recuperación ante desastres en una red aislada sin afectar a la producción; los planes de recuperación secuencian la conmutación por error de varias máquinas virtuales mediante puertas manuales y pasos de runbooks de automatización; y la conmutación por recuperación devuelve las cargas de trabajo a la región original invirtiendo la dirección de replicación después de un desastre. A continuación, exploraremos Azure CDN para acelerar la entrega global de contenido.