AZ-104
Deep Dive
Azure Site Recovery replica VMs y cargas de trabajo físicas a una región secundaria de Azure para habilitar recuperación ante desastres. El AZ-104 evalúa configuración de replicación, recovery plans, failover y failback.
Contenido
Azure Site Recovery (ASR) replica continuamente VMs de Azure entre regiones (o desde on-premises a Azure) para que en caso de desastre puedas hacer failover a la réplica en minutos. No es un backup — es replicación continua para DR.
Diferencia crítica: Backup guarda snapshots puntuales para restaurar datos. ASR replica el estado completo de la VM en tiempo casi real para recuperación ante caída de región.
Qué puede replicar
Beneficios clave
Lo que NO es ASR
Componentes de ASR (Azure → Azure)
Recovery Services Vault
Contenedor principal donde se configura ASR. Debe estar en la región de destino (secundaria). También se usa para Azure Backup.
Replication Policy
Define: frecuencia de snapshot de crash-consistent (cada 5 min), frecuencia de snapshot app-consistent (cada 1-12h) y retención de recovery points (hasta 72h).
Cache Storage Account
Cuenta de almacenamiento temporal en la región de origen donde se almacenan los datos de replicación antes de transferirse a la región de destino.
Target Resources
ASR crea automáticamente los recursos en la región de destino: VNet réplica, subnet réplica, NIC réplica. Estos recursos solo se usan en failover.
Tipos de recovery points
Crash-consistent
Snapshot del estado del disco en el momento — equivalente a sacar el cable de alimentación a la VM. Los datos en memoria se pierden. Capturado cada 5 minutos.
App-consistent
Snapshot con quiescence del OS — las aplicaciones completan sus writes pendientes antes del snapshot. Los datos son consistentes a nivel de aplicación. Capturado cada 1-12 horas (configurable). Usa VSS en Windows.
RPO mínimo
Con crash-consistent cada 5 min: RPO máximo = 5 minutos de datos perdidos en caso de desastre. Para DBs transaccionales, usar app-consistent para garantizar consistencia de transacciones.
Pasos para habilitar replicación
Mobility Service
Agente instalado automáticamente por ASR en cada VM replicada. Captura las escrituras de datos en el disco de la VM y las envía al cache storage account. Para VMs on-premises: instalación manual o via Configuration Server.
Requisitos de la VM
Un Recovery Plan orquesta el failover de múltiples VMs en un orden específico y con acciones personalizadas entre pasos. Permite hacer failover de toda una aplicación multi-tier con dependencias.
Estructura de un Recovery Plan
Groups (grupos de VMs)
Las VMs se organizan en grupos numerados. El failover ejecuta los grupos en orden: Group 1 completa antes de iniciar Group 2.
Pre/Post actions
Entre grupos se pueden añadir: Azure Automation Runbooks (scripts PowerShell/Python) o Manual actions (pause para intervención humana).
Ejemplo — app 3 capas
Group 1: DB Server → failover primero
Pre-action: script que verifica DB está up
Group 2: App Servers → arrancan tras DB
Group 3: Web/Frontend → arrancan al final
Test Failover
Test Failover permite probar el DR sin interrumpir la producción. Crea las VMs réplica en una VNet de test aislada — la producción sigue funcionando normalmente.
| Paso | Acción | Descripción |
|---|---|---|
| Failover 1 | Iniciar failover | En vault → Recovery Plan (o VM individual) → Failover. Seleccionar recovery point y confirmar. ASR crea las VMs en la región secundaria. |
| Failover 2 | Verificar VMs secundarias | Confirmar que las VMs en la región secundaria funcionan correctamente. Redirigir DNS/Traffic Manager a la región secundaria. |
| Failover 3 | Commit | Una vez verificado, hacer Commit del failover. Esto finaliza el failover — la VM primaria ya no se puede usar para failback sin re-protección. |
| Re-protect 1 | Re-protect | Después del commit, re-proteger: ahora la región secundaria es la primaria. ASR comienza a replicar de vuelta a la región original. |
| Failback 1 | Failback (optional) | Cuando la región original se recupera, hacer failover de vuelta (failback) a la región original. |
| Failback 2 | Re-protect (final) | Re-proteger de nuevo: la región original es primaria, la secundaria es el DR. Configuración restaurada al estado inicial. |
Tipos de failover
Planned Failover
La VM primaria se detiene primero, sincroniza datos finales, luego inicia en secundaria. RPO = 0 (sin pérdida de datos). Para migraciones planificadas.
Unplanned Failover
La región primaria no está disponible. Failover desde el último recovery point disponible. Algo de pérdida de datos posible (depende del RPO del último punto).
Test Failover
Prueba sin impacto en producción. VMs réplica creadas en VNet aislada. No interrumpe la replicación activa. Cleanup al terminar.
Cuándo usar ASR
Límites importantes
Costos de ASR
Licencia ASR
Por instancia protegida por mes. Las primeras 31 días son gratuitas por instancia.
Almacenamiento réplica
Discos gestionados en la región secundaria (se pagan aunque la VM no esté running).
Egress de replicación
Transferencia de datos entre regiones para la replicación continua (costo de egress estándar).
¿Entendiste este tema?
Pon a prueba lo que acabas de aprender
Un administrador realiza un Test Failover de un Recovery Plan en ASR. ¿Cuál es el impacto en las VMs de producción en la región primaria?