AZ-104
Deep Dive
Estrategias y servicios de replicación en Azure para garantizar disponibilidad y recuperación de desastres. El AZ-104 evalúa RPO/RTO, opciones de replicación por servicio y configuración de failover.
Contenido
RPO (Recovery Point Objective)
Cantidad máxima de datos que se puede perder medida en tiempo. Si el RPO es 1 hora, en el peor caso pierdes 1 hora de datos.
RPO = 0: replicación síncrona, sin pérdida. RPO = 5 min: replicación asíncrona con lag típico de 5 min.
RTO (Recovery Time Objective)
Tiempo máximo permitido para recuperar el servicio después de un fallo. Si RTO es 1 hora, en máximo 1h el servicio debe estar operativo.
RTO = 0: failover automático e inmediato (Business Critical SQL). RTO = 30 min: failover manual con tiempo de preparación.
Replicación síncrona vs asíncrona
Síncrona: la escritura se confirma solo después de que todas las réplicas la reciben. RPO = 0, pero mayor latencia. Asíncrona: la escritura se confirma en la primaria y se replica después. Menor latencia, RPO > 0.
SQL Business Critical: síncrona. SQL General Purpose: asíncrona. GRS de Storage: asíncrona.
La redundancia de Storage se configura al crear la cuenta y afecta a todos los servicios dentro de ella (Blob, File, Queue, Table). Ver detalle completo en el tema de Storage Accounts.
| Redundancia | RPO (aprox.) | RTO (failover) | Tipo replicación | Disponibilidad lectura durante outage regional |
|---|---|---|---|---|
| LRS | N/A (1 región) | N/A | Síncrona (3 copias mismo DC) | No — si DC falla, no hay lectura |
| ZRS | N/A (1 región, 3 AZs) | Automático (segundos) | Síncrona (3 AZs) | Sí — si 1 AZ falla, otras 2 sirven |
| GRS | <15 min (típico) | Horas (failover manual o automático) | Asíncrona a región secundaria | No — secundaria solo disponible post-failover |
| RA-GRS | <15 min | N/A para lectura (secundaria siempre disponible) | Asíncrona a región secundaria | Sí — .secondary endpoint siempre disponible |
| GZRS | <15 min | Horas (failover) | Síncrona (3 AZs primaria) + Asíncrona (secundaria) | No (sin RA-) |
| RA-GZRS | <15 min | N/A para lectura | Síncrona (3 AZs) + Asíncrona (secundaria) | Sí — máxima disponibilidad |
Failover de Storage Account
• Failover convierte la región secundaria en primaria (la cuenta empieza a servir desde la nueva primaria)
• Después del failover, la redundancia se convierte en LRS en la nueva primaria — debes reconfigurar GRS/ZRS manualmente
• El failover puede iniciarse desde: Portal → Storage Account → Geo-replication → Prepare for failover
• Microsoft puede iniciar un failover automático en desastres mayores (sin garantía de timing)
• Posible pérdida de datos: Azure indica el "Last sync time" — datos escritos después de esa hora pueden perderse
Object Replication copia automáticamente blobs de un container origen a un container destino (en la misma o distinta cuenta/región). Es diferente a la redundancia GRS — es a nivel de contenedor específico.
Cómo funciona
• Replicación asíncrona basada en el Change Feed de blobs
• Puedes definir filtros: solo blobs con ciertos prefijos, o desde una fecha de creación específica
• No replica metadatos de operaciones (solo el contenido del blob)
• El destino puede estar en una cuenta diferente, suscripción diferente o región diferente
• No hay garantía de tiempo (SLA) para cuándo llegará la replicación al destino
Requisitos
• Blob Versioning habilitado en origen Y destino
• Change Feed habilitado en la cuenta origen
• Solo Block Blobs (no Page Blobs ni Append Blobs)
Casos de uso
Distribución de contenido
Replicar imágenes/videos a múltiples regiones para servir localmente. Los usuarios de APAC leen desde una cuenta de Storage en APAC, reduciendo latencia.
Analítica distribuida
Replicar datos de operaciones (región East US) a una cuenta dedicada de analytics (West US) sin afectar la cuenta primaria de producción.
Retención diferenciada
La cuenta origen retiene 30 días con Hot tier. La replica en otra cuenta aplica Archive tier automáticamente. Optimización de costos sin lifecycle complejo en la cuenta origen.
Active Geo-Replication
Hasta 4 réplicas secundarias legibles en distintas regiones. Replicación asíncrona continua desde la BD primaria. Las secundarias son BDs read-only activas.
• RPO: ~5 segundos en condiciones normales (asíncrona)
• RTO: ~30 segundos para failover manual
• Failover: manual siempre — no hay failover automático nativo en geo-replication simple
• Read scale-out: redirigir queries de lectura a secundarias reduce carga en la primaria
• Disponible solo en Azure SQL Database (no SQL MI)
• Si hay failover, la app debe actualizar su connection string a la nueva primaria
Auto-Failover Groups
Extiende geo-replication con failover automático configurable y endpoints de connection string que no cambian durante el failover.
• Listener RW: nombre DNS estable — apunta a la primaria actual automáticamente
• Listener RO: apunta a la secundaria — para separar lectura/escritura
• Grace period: tiempo de espera antes del failover automático (mín. 1 hora, configurable)
• Failover policy: Automatic o Manual
• Disponible en SQL Database y SQL Managed Instance
• Un failover group puede incluir múltiples BDs — se conmutan juntas
HA interna vs Geo-Replication vs Failover Groups
| Mecanismo | Scope | Automático | RPO | Protege contra |
|---|---|---|---|---|
| HA interna (siempre activa) | Réplicas en misma región | Sí | ~0 seg (Business Critical) / ~25 seg (GP) | Fallo de nodo, hardware |
| Geo-Replication | Otra región | No (manual) | ~5 seg | Fallo de región completa |
| Auto-Failover Groups | Otra región | Opcional | ~5 seg | Fallo de región + app transparente (no cambia endpoint) |
Replicación multi-región
En Cosmos DB puedes añadir o quitar regiones en cualquier momento desde el Portal con zero downtime. La replicación es asíncrona entre regiones (excepto con consistencia Strong).
• Latencia lectura: <10ms al leer de la región local
• Latencia escritura: depende de la región de escritura y consistencia elegida
• Número de regiones: hasta ~25+ regiones simultáneas
• Costo: cada región réplica añade el costo de RU/s aprovisionadas
Single-write vs Multi-write (Multi-master)
Single-write region
Una región acepta escrituras. Las demás son read-only. Failover automático configurable en caso de caída de la región de escritura. Orden de failover: prioridad manual.
Multi-region writes
Todas las regiones aceptan escrituras. Mínima latencia de escritura global. Requiere gestionar conflictos de escritura (LWW o custom). RPO efectivamente 0 para escrituras locales.
Failover en Cosmos DB
• Automático: si la región de escritura no está disponible, Cosmos elige la siguiente en la lista de prioridades de failover
• Manual: puedes cambiar la región de escritura en el portal (sin downtime con multi-write, con breve ventana single-write)
• Con multi-write: no hay failover necesario — cualquier región acepta escrituras
Comparación de comportamiento de failover por servicio
Azure Storage (GRS/GZRS)
Failover automático
Solo en desastres graves declarados por Microsoft. Sin SLA de tiempo.
Failover manual
Portal → Geo-replication → Prepare failover. Puede tardar 1+ hora. Implica posible pérdida de datos (datos después de "last sync time").
Post-failover
La cuenta queda en LRS en la nueva región. Debes reconfigurar GRS manualmente.
Azure SQL Database (Auto-Failover Groups)
Failover automático
Sí — si se configura Grace Period y Failover Policy = Automatic. Inicia failover si la primaria no responde durante el grace period.
Failover manual
Portal → Failover Group → Failover. La app usa el listener DNS (no cambia). Con failover forzado puede haber pérdida de datos.
Post-failover
La secundaria se convierte en primaria. La antigua primaria se convierte en secundaria (sync reversa automática).
Azure Cosmos DB (single-write)
Failover automático
Sí — si "Enable automatic failover" está activado. Cosmos elige la siguiente región en la lista de prioridades.
Failover manual
Portal → Replicate data globally → Manual failover → elegir nueva región primaria.
Post-failover
La nueva región acepta escrituras. La antigua se convierte en réplica de lectura automáticamente.
| Servicio | Opción de replicación | Tipo | RPO | Lectura desde réplica | Failover |
|---|---|---|---|---|---|
| Storage | LRS/ZRS | Síncrona | 0 | No aplica | No |
| Storage | GRS/GZRS | Asíncrona | <15 min | No (solo post-failover) | Manual / Auto (MS) |
| Storage | RA-GRS / RA-GZRS | Asíncrona | <15 min | Sí (.secondary endpoint) | Manual / Auto (MS) |
| SQL Database | HA interna (GP) | Asíncrona (almacenamiento remoto) | ~0 seg | No | Automático ~25 seg |
| SQL Database | HA interna (BC) | Síncrona (Always On) | 0 | Sí (1 réplica de lectura gratis) | Automático <8 seg |
| SQL Database | Active Geo-Replication | Asíncrona | ~5 seg | Sí (todas las secundarias) | Manual |
| SQL DB / MI | Auto-Failover Groups | Asíncrona | ~5 seg | Sí (listener RO) | Automático o manual |
| Cosmos DB | Multi-región (single-write) | Asíncrona | Según consistencia | Sí (todas las réplicas) | Automático o manual |
| Cosmos DB | Multi-region writes | Asíncrona | ~0 (local) | Sí | No necesario |
Patrones de diseño para alta disponibilidad
Active-Passive
Una región activa, otra en standby. Failover manual o automático. Costos menores (la réplica no sirve tráfico). Mayor RTO.
Ej: SQL DB con Active Geo-Replication (sin redirect automático).
Active-Active
Ambas regiones sirven tráfico. Menor latencia global. Mayor costo. Requiere gestionar consistencia de datos.
Ej: Cosmos DB multi-write, SQL con Auto-Failover Groups + split de tráfico por geografía.
¿Entendiste este tema?
Pon a prueba lo que acabas de aprender
Una aplicación de e-commerce necesita que en caso de fallo de la región primaria, el failover de la base de datos SQL ocurra automáticamente y sin que la app necesite cambiar su connection string. ¿Qué configuración deberías implementar?