AZ-305

Deep Dive

D3 · Continuidad de Negocio

Diseño de Alta Disponibilidad

Alta disponibilidad = sobrevivir fallos dentro de una región (HA) o de toda una región (DR). El AZ-305 te pedirá calcular qué arquitectura cumple un SLA objetivo ("99.99%") y elegir entre availability sets, zones y multi-región según costo y requisito.

Icon-compute-21

Bloques: fault domains, availability sets y zones

ConstrucciónProtege contraSLA VMs (2+)
VM única (premium SSD)Nada — solo SLA de hardware99.9%
Availability Set (fault/update domains)Fallo de rack (FD) y mantenimiento planificado (UD) — mismo datacenter99.95%
Availability ZonesCaída de un datacenter completo (zona) — energía, red, refrigeración independientes99.99%
Multi-región (+ Front Door/Traffic Manager)Desastre regionalCompuesto >99.99%

Reglas para el examen

  • • "99.99% para las VMs" → Availability Zones (sets solo llegan a 99.95%)
  • • Availability set y zones son excluyentes para una misma VM
  • • Zone-redundant services (Standard LB, App Gateway v2, ZRS, SQL BC zonal) reparten la redundancia entre zonas automáticamente
  • • VMSS con "zone balancing" reparte instancias entre zonas — el patrón moderno por defecto

Trade-offs de zonas

  • • Latencia inter-zona ~1-2 ms — relevante para clusters chatty
  • • Tráfico inter-zona puede tener costo
  • • No todas las regiones tienen zonas (cada vez menos excepciones)
  • • Proximity placement groups (latencia mínima) chocan con repartir entre zonas — elegir prioridad

SLAs y SLA compuesto

El SLA compuesto de servicios en serie se multiplica: App Service (99.95%) × SQL Database (99.99%) = 99.94% — siempre MENOR que el componente más débil. Para subirlo: redundancia en paralelo (multi-instancia, multi-zona, multi-región) o eliminar dependencias síncronas (colas).

Downtime permitido por nivel

99.9%~8.7 horas/año
99.95%~4.4 horas/año
99.99%~52 minutos/año
99.999%~5 minutos/año

Cómo razonar en el examen

  • • Cadena en serie: multiplica los SLAs — si no llega al objetivo, añade redundancia
  • • Componentes en paralelo: 1−(1−A)×(1−B) — dos rutas de 99.9% ≈ 99.9999%
  • • Desacoplar con colas convierte dependencias duras en blandas (la app sobrevive si el backend cae un rato)
  • • El SLA real de negocio incluye TU código y operaciones — el SLA de Azure es solo la plataforma

Patrones de HA por capa

CapaDiseño HA intra-región
Web/API (PaaS)App Service plan con ≥2-3 instancias + zone redundancy; autoscale
Compute (IaaS)VMSS Flexible (modo moderno por defecto) repartido en zonas detrás de Standard Load Balancer zone-redundant; VMSS Uniform solo para workloads legacy
ContenedoresAKS con node pools en múltiples zonas; pod topology spread
SQL DatabaseBusiness Critical/GP con zone redundancy (réplicas en zonas distintas)
StorageZRS (o GZRS si además DR regional)
MensajeríaService Bus Premium (zone redundant por defecto)
CacheRedis Standard/Premium con réplica; Premium con zonas
Balanceo regionalStandard LB / App Gateway v2 (ambos zone-redundant)
Icon-networking-73

HA multi-región

Active-Active

  • Ambas regiones sirven tráfico (Front Door/Traffic Manager reparten)
  • RTO ≈ 0: el fallo de una región solo reduce capacidad
  • Más caro; exige datos multi-región (Cosmos multi-write, replicación)

Active-Passive (hot standby)

  • Secundaria desplegada y corriendo, recibe failover
  • RTO minutos; costo intermedio
  • Patrón típico con SQL failover groups + Front Door priority routing

Active-Passive (cold / redeploy)

  • Secundaria se crea al fallar (IaC + backups/ASR)
  • RTO horas; el más barato
  • Para workloads tolerantes con presupuesto ajustado

Entrada global

Azure Front Door (L7: HTTP/S, failover casi instantáneo, WAF, CDN) vs Traffic Manager (DNS: cualquier protocolo, failover depende del TTL). Para apps web multi-región la respuesta moderna es Front Door.

Tabla de decisión

RequisitoDiseño
SLA 99.99% para una capa de VMs en una regiónVMs/VMSS en Availability Zones + Standard LB
SLA 99.95% suficiente, región sin zonasAvailability Set
El SLA compuesto en serie no llega al objetivoRedundancia en paralelo o desacoplar con colas
Web global que sobrevive a caída regional con RTO≈0Active-active multi-región + Front Door
DR regional barato, RTO de horas aceptableCold standby: IaC + backups geo-redundantes
Storage que sobreviva caída de zonaZRS
Latencia mínima entre VMs del clusterProximity placement group (sacrificando resiliencia zonal)

¿Entendiste este tema?

Pon a prueba lo que acabas de aprender

Una app corre en 4 VMs detrás de un load balancer en West Europe. El negocio exige SLA de 99.99% para la capa de cómputo y que la app sobreviva al fallo completo de un datacenter, manteniéndose en una sola región. ¿Qué diseño cumple?

Inicia sesión para llevar tu progreso.