Alta disponibilidad y Disaster Recovery (AZ-305)
0. RPO, RTO y matriz de opciones
Casi todas las preguntas de HA/DR en AZ-305 giran alrededor de dos parámetros:
- RPO (Recovery Point Objective): cuánto dato puedes perder.
- RTO (Recovery Time Objective): cuánto tiempo puedes estar caído.
El truco es mapear el RPO/RTO a la combinación adecuada de:
- Zonas de disponibilidad y conjuntos de disponibilidad.
- Replicación de datos (LRS/ZRS/GRS/GZRS, geo-replicación de BD).
- Orquestación de DR (Azure Site Recovery, Traffic Manager/Front Door).
1. Alta disponibilidad en una sola región
Cuando el requisito habla de fallos de host o rack, pero no de región completa, nos centramos en mecanismos dentro de la misma región:
- Availability Sets para distribuir VMs en dominios de fallo y actualización.
- Availability Zones para aislar físicamente (data centers diferentes).
- VM Scale Sets con zonas para escalado automático + HA.
Si el fallo esperado es de data center completo dentro de la región, la respuesta suele incluir Availability Zones; si solo es de host/rack, basta con Availability Sets o réplicas de BD en la misma región.
2. Multi-región y pares regionales
Cuando el requisito menciona “caída completa de la región” o “desastre mayor”, tienes que pensar en multi-región:
- Uso de pares regionales para replicación y actualizaciones coordinadas.
- Servicios con soporte nativo multi-región: Front Door, Traffic Manager, Cosmos DB, etc.
- Refugio (DR) en región secundaria con capacidad suficiente para cargas críticas.
En muchos casos, el diseño correcto combina:
- Front Door / Traffic Manager para enrutar tráfico entre regiones.
- BD con geo-replicación (por ejemplo, Azure SQL active geo-replication).
- VMs replicadas por Azure Site Recovery o plantillas IaC para reconstrucción.
3. Azure Site Recovery para IaaS
Azure Site Recovery (ASR) es el servicio principal para orquestar DR de máquinas:
- Replica VMs entre regiones de Azure o desde on-prem a Azure.
- Permite definir planes de recuperación con orden, grupos de arranque y scripts.
- Consigue RPO de minutos en muchos escenarios.
Detalles que AZ-305 suele explotar
- Los Recovery Plans coordinan aplicaciones multi-tier.
- Puede integrarse con runbooks (Automation) para tareas extra durante el failover.
- Es diferente de Azure Backup: ASR es DR, Backup es retención y recuperación de datos.
4. Estrategias de DR para datos
La pieza de datos manda: de nada sirve el DR de VMs si tus datos no están replicados correctamente.
- Azure SQL: active geo-replication, failover groups.
- Cosmos DB: multi-región con multi-master opcional.
- Storage: GRS / GZRS (escrituras asincrónicas a región emparejada).
- BD en VMs: tecnologías propias (Always On, log shipping, etc.) + ASR.
El examen valora que alinees la estrategia de datos con la de computación: si haces failover de la app a otra región, los datos deben estar allí también.
5. Patrones y escenarios de examen
Patrones típicos
- RPO bajo (minutos) y RTO reducido, fallo de región completa → ASR + geo-replicación de datos + Front Door/Traffic Manager.
- Alta disponibilidad frente a fallos de host → Availability Sets o Scale Sets con múltiples instancias.
- Alta disponibilidad dentro de la región, riesgo de caída de data center → Availability Zones.
Laboratorio recomendado
- Crear una aplicación sencilla con front + BD en una región primaria.
- Habilitar ASR para las VMs hacia una región secundaria.
- Configurar geo-replicación para la BD.
- Orquestar un plan de recuperación y probar un failover de prueba.