AZ-104
Deep Dive
El failover es la activación del sistema de DR cuando el primario falla. El failback es la vuelta al sistema primario cuando se recupera. El AZ-104 evalúa los procesos de failover en ASR, Azure SQL y Traffic Manager, incluyendo las implicaciones del DNS.
Contenido
Failover
Activar el sistema de DR secundario cuando el primario falla o se degrada. El tráfico se redirige al sistema secundario.
Failover automático
Health checks detectan el fallo y redirigen tráfico sin intervención humana. Ej: Traffic Manager con endpoint monitoring, SQL Failover Groups.
Failover manual
Un operador decide iniciar el failover. Ej: ASR failover desde el portal, iniciar manualmente cuando se confirma el desastre.
Failback
Volver al sistema primario original una vez que se ha recuperado. El proceso inverso al failover.
¿Cuándo hacer failback?
Solo cuando el sistema primario está completamente recuperado, verificado y validado. No hay prisa — correr en el secundario es más seguro que un failback apresurado.
Datos creados durante el failover
Los datos generados en el sistema secundario durante el período de failover deben sincronizarse de vuelta al primario antes del failback.
Split-brain — el riesgo del failover
Split-brain ocurre cuando tanto el sistema primario como el secundario creen ser el activo simultáneamente y aceptan escrituras. Resulta en divergencia de datos — los dos sistemas tienen datos diferentes e incompatibles. Los sistemas de failover automático tienen mecanismos para evitarlo (fencing, quorum). En failover manual: siempre confirmar que el primario está completamente caído antes de activar el secundario.
Proceso de failover en ASR
Decisión
Confirmar que la región primaria está caída o inaccesible. Comunicar a stakeholders. Activar el plan de DR.
Iniciar failover
En RSV → Replicated Items → VM → Failover (o Recovery Plan → Failover). Seleccionar recovery point (latest processed, latest app-consistent, o específico).
Recovery point
Latest processed: menor RPO pero puede ser crash-consistent. Latest app-consistent: datos más limpios pero más antiguo. Custom: elegir un punto específico en el tiempo.
Verificación
VMs creadas en región secundaria. Verificar conectividad, datos, funcionamiento de la app antes de redirigir tráfico.
Commit
Confirmar el failover. Después del commit, los recovery points del origin se eliminan. No hay vuelta atrás sin re-protección.
Redirigir tráfico
Actualizar DNS o Traffic Manager para apuntar a los endpoints de la región secundaria.
Proceso de failback con ASR
Re-protect (paso 1 obligatorio)
Después del commit del failover, la región secundaria es la primaria. Ejecutar "Re-protect" para empezar a replicar de vuelta a la región original.
Esperar sincronización
ASR replica los datos actuales de la región secundaria a la región original. Tiempo según volumen de cambios.
Failover de vuelta
Cuando la sincronización completa, hacer Failover desde la región secundaria de vuelta a la original. Verificar funcionamiento.
Re-protect (paso 2)
Después del failback, volver a proteger: región original es primaria, secundaria es DR. Configuración inicial restaurada.
Active Geo-Replication
Hasta 4 réplicas secundarias legibles en regiones distintas. Failover manual: az sql db replica set-primary. La secundaria se promueve a primaria.
Auto-Failover Groups
Abstracción sobre Active Geo-Replication. Proporciona endpoint de listener único que apunta automáticamente al primario. Failover automático configurable.
SQL Managed Instance — Failover Groups
SQL Managed Instance también soporta Failover Groups pero con algunas diferencias: el failover puede tardar más (hasta 30 min para instancias grandes), no soporta múltiples secundarias (solo 1 por grupo), y el proceso de replicación inicial puede llevar días para instancias grandes.
Traffic Manager detecta automáticamente cuando un endpoint está caído (via health probes) y deja de resolver DNS hacia él. Con el método Priority routing, esto implementa failover automático de aplicación web entre regiones.
Configurar failover con Traffic Manager
Parámetros de health probe de TM
Probing interval: 30 segundos (normal) o 10 segundos (fast — más caro)
Con qué frecuencia sonda el endpoint
Tolerated failures: 3 (default)
Cuántas sondas fallidas antes de marcar endpoint como degradado
Probe timeout: 10 segundos
Cuánto espera la respuesta de la sonda
TTL del DNS: Configurable — default 60s
Cuánto tiempo cachean los clientes la respuesta DNS. Menor TTL = failover más rápido
RTO de Traffic Manager — tiempo total de failover
RTO efectivo = Probe interval × Tolerated failures + TTL DNS
Con defaults: 30s × 3 = 90s detección + 60s TTL = ~150 segundos (2.5 min) de failover
Con fast probe (10s) + TTL bajo (30s): 10s × 3 = 30s + 30s = ~60 segundos
El TTL bajo es crítico — si el TTL es 300s, los clientes seguirán usando el endpoint caído hasta que expire su caché DNS.
TTL — el factor oculto del RTO
El TTL (Time To Live) del registro DNS determina cuánto tiempo los clientes cachean la resolución. Aunque cambies el DNS, los clientes con caché activa siguen usando el endpoint antiguo.
• TTL 3600 (1 hora): hasta 1 hora de impacto tras failover DNS
• TTL 300 (5 min): hasta 5 min después del cambio DNS
• TTL 60 (1 min): hasta 1 min — agresivo pero efectivo
• TTL 30: óptimo para failover, pero aumenta la carga en DNS servers
Best practice pre-desastre
Reducir TTL a 60-120 segundos ANTES de que ocurra el desastre (durante operación normal). Esto no impacta rendimiento pero acelera el failover si ocurre.
Opciones de redirección en failover
Traffic Manager (Priority)
~1-3 min
Failover DNS automático. Requiere bajo TTL para ser efectivo.
Azure Front Door
<30 seg
Failover automático en el edge con anycast. El failover es más rápido que DNS.
Manual DNS update
TTL del registro
Cambiar el registro A/CNAME manualmente. Efectivo pero lento si TTL es alto.
SQL Failover Groups
<30 seg
Endpoint del listener se actualiza automáticamente. La app no cambia URL.
Pre-failover (preparación)
Durante el failover
¿Entendiste este tema?
Pon a prueba lo que acabas de aprender
Una empresa usa Traffic Manager con routing Priority para failover entre East US (primaria, prioridad 1) y West US (secundaria, prioridad 2). El TTL del Traffic Manager está configurado en 300 segundos. East US falla a las 10:00. ¿Cuándo empezarán TODOS los usuarios a usar West US?