Conceptos de Alta Disponibilidad
¿Qué es la Alta Disponibilidad?
La Alta Disponibilidad (HA) es la capacidad de un sistema para permanecer operativo y accesible incluso en caso de fallo de uno o varios de sus componentes.
┌─────────────────────────────────────────────────────────────┐
│ ALTA DISPONIBILIDAD │
├─────────────────────────────────────────────────────────────┤
│ │
│ Objetivo: El servicio permanece accesible a pesar de fallos│
│ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ │ │
│ │ ¿Fallo de servidor? → Otro servidor toma el relevo│ │
│ │ ¿Fallo de zona (AZ)? → Otra AZ toma el relevo │ │
│ │ ¿Fallo de región? → Otra región (DR) │ │
│ │ │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ Medida: Porcentaje de disponibilidad (uptime) │
│ │
│ 99% = 3.65 días de inactividad/año (no aceptable) │
│ 99.9% = 8.76 horas de inactividad/año (estándar) │
│ 99.99% = 52.6 minutos de inactividad/año (alta dispo) │
│ 99.999% = 5.26 minutos de inactividad/año (muy alta) │
│ │
└─────────────────────────────────────────────────────────────┘
SPOF - Single Point of Failure
Un SPOF es un componente cuya falla provoca la parada completa del sistema.
┌─────────────────────────────────────────────────────────────┐
│ IDENTIFICAR LOS SPOF │
├─────────────────────────────────────────────────────────────┤
│ │
│ ARQUITECTURA CON SPOF │
│ ────────────────────── │
│ │
│ Usuarios │
│ │ │
│ ▼ │
│ ┌─────────┐ │
│ │ Servidor│ ← ¡SPOF! Si este servidor falla, todo para │
│ │ Web │ │
│ └────┬────┘ │
│ │ │
│ ▼ │
│ ┌─────────┐ │
│ │ BDD │ ← ¡SPOF! Solo una base de datos │
│ │ │ │
│ └─────────┘ │
│ │
│ SPOF identificados: │
│ ❌ 1 solo servidor web │
│ ❌ 1 sola base de datos │
│ ❌ 1 sola zona de disponibilidad │
│ │
└─────────────────────────────────────────────────────────────┘
Eliminar los SPOF
┌─────────────────────────────────────────────────────────────┐
│ ARQUITECTURA SIN SPOF │
├─────────────────────────────────────────────────────────────┤
│ │
│ Usuarios │
│ │ │
│ ▼ │
│ ┌─────────────┐ │
│ │ Load Balancer│ ← Gestionado por AWS (alta dispo nativa) │
│ └──────┬──────┘ │
│ │ │
│ ┌─────┼─────┐ │
│ │ │ │ │
│ ▼ ▼ ▼ │
│ ┌──┐ ┌──┐ ┌──┐ │
│ │S1│ │S2│ │S3│ ← 3 servidores en 3 AZ diferentes │
│ └┬─┘ └┬─┘ └┬─┘ │
│ │ │ │ │
│ └─────┼─────┘ │
│ │ │
│ ▼ │
│ ┌─────────────┐ │
│ │ RDS Multi-AZ│ ← Base de datos con standby auto │
│ │ Primary │ │
│ │ ↓ │ │
│ │ Standby │ │
│ └─────────────┘ │
│ │
│ SPOF eliminados: │
│ ✅ Múltiples servidores web │
│ ✅ Base de datos Multi-AZ │
│ ✅ Distribución en varias AZ │
│ │
└─────────────────────────────────────────────────────────────┘
Arquitectura Multi-AZ
Zonas de Disponibilidad AWS
┌─────────────────────────────────────────────────────────────┐
│ ZONAS DE DISPONIBILIDAD (AZ) │
├─────────────────────────────────────────────────────────────┤
│ │
│ Región AWS (ej: us-east-1) │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ │ │
│ │ ┌───────────┐ ┌───────────┐ ┌───────────┐ │ │
│ │ │ AZ-a │ │ AZ-b │ │ AZ-c │ │ │
│ │ │ │ │ │ │ │ │ │
│ │ │ Datacenter│ │ Datacenter│ │ Datacenter│ │ │
│ │ │ aislado │ │ aislado │ │ aislado │ │ │
│ │ │ │ │ │ │ │ │ │
│ │ └─────┬─────┘ └─────┬─────┘ └─────┬─────┘ │ │
│ │ │ │ │ │ │
│ │ └──────────────┼──────────────┘ │ │
│ │ │ │ │
│ │ Red de alta velocidad │ │
│ │ (baja latencia entre AZ) │ │
│ │ │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ Características: │
│ • Cada AZ = 1+ datacenters físicamente separados │
│ • Alimentación, red, refrigeración independientes │
│ • Distancia suficiente para evitar catástrofe común │
│ • Latencia < 2ms entre AZ de la misma región │
│ │
└─────────────────────────────────────────────────────────────┘
Cálculo de Disponibilidad
┌─────────────────────────────────────────────────────────────┐
│ CÁLCULO DE DISPONIBILIDAD │
├─────────────────────────────────────────────────────────────┤
│ │
│ Fórmula: Dispo_total = 1 - (1 - Dispo_componente)^n │
│ │
│ Ejemplo: Un servidor tiene 99% de disponibilidad │
│ │
│ 1 servidor: │
│ Dispo = 99% = 0.99 │
│ Downtime = 3.65 días/año │
│ │
│ 2 servidores (en paralelo): │
│ Dispo = 1 - (1-0.99)² = 1 - 0.0001 = 99.99% │
│ Downtime = 52 minutos/año │
│ │
│ 3 servidores (en paralelo): │
│ Dispo = 1 - (1-0.99)³ = 1 - 0.000001 = 99.9999% │
│ Downtime = 32 segundos/año │
│ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ │ │
│ │ Número de servidores Disponibilidad Downtime │ │
│ │ ──────────────────── ────────────── ───────── │ │
│ │ 1 99% 3.65 días │ │
│ │ 2 99.99% 52 minutos │ │
│ │ 3 99.9999% 32 segundos │ │
│ │ │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ ⚠️ Atención: ¡Esto supone fallos independientes! │
│ Si los servidores están en la misma AZ, un fallo de AZ │
│ los afecta a todos → usar Multi-AZ │
│ │
└─────────────────────────────────────────────────────────────┘
Patrones de Alta Disponibilidad
Patrón 1: Active-Passive
┌─────────────────────────────────────────────────────────────┐
│ ACTIVE-PASSIVE (Standby) │
├─────────────────────────────────────────────────────────────┤
│ │
│ ┌───────────────────────────────────────────────────┐ │
│ │ │ │
│ │ ┌─────────────┐ ┌─────────────┐ │ │
│ │ │ ACTIVE │ │ PASSIVE │ │ │
│ │ │ (Primary) │───────►│ (Standby) │ │ │
│ │ │ │ sync │ │ │ │
│ │ │ Procesa el │ │ Espera │ │ │
│ │ │ tráfico │ │ su turno │ │ │
│ │ └─────────────┘ └─────────────┘ │ │
│ │ │ │ │
│ │ │ Si falla │ │
│ │ ▼ │ │
│ │ ┌─────────────┐ ┌─────────────┐ │ │
│ │ │ (down) │ │ ACTIVE │ │ │
│ │ │ │ │ (nuevo) │ │ │
│ │ └─────────────┘ └─────────────┘ │ │
│ │ │ │
│ └───────────────────────────────────────────────────┘ │
│ │
│ Ventajas: Desventajas: │
│ ✅ Sencillo ❌ Recursos infrautilizados │
│ ✅ Datos sincronizados ❌ Failover no instantáneo │
│ ✅ Costo moderado │
│ │
│ Casos de uso: RDS Multi-AZ, bases de datos │
│ │
└─────────────────────────────────────────────────────────────┘
Patrón 2: Active-Active
┌─────────────────────────────────────────────────────────────┐
│ ACTIVE-ACTIVE │
├─────────────────────────────────────────────────────────────┤
│ │
│ ┌───────────────────────────────────────────────────┐ │
│ │ │ │
│ │ ┌─────────────────┐ │ │
│ │ │ Load Balancer │ │ │
│ │ └────────┬────────┘ │ │
│ │ │ │ │
│ │ ┌───────────┼───────────┐ │ │
│ │ │ │ │ │ │
│ │ ▼ ▼ ▼ │ │
│ │ ┌────────┐ ┌────────┐ ┌────────┐ │ │
│ │ │ ACTIVE │ │ ACTIVE │ │ ACTIVE │ │ │
│ │ │ (1) │ │ (2) │ │ (3) │ │ │
│ │ │ │ │ │ │ │ │ │
│ │ │ Procesa│ │ Procesa│ │ Procesa│ │ │
│ │ │ tráfico│ │ tráfico│ │ tráfico│ │ │
│ │ └────────┘ └────────┘ └────────┘ │ │
│ │ AZ-a AZ-b AZ-c │ │
│ │ │ │
│ └───────────────────────────────────────────────────┘ │
│ │
│ Ventajas: Desventajas: │
│ ✅ Todos los recursos usados ❌ Más complejo │
│ ✅ Mejor rendimiento ❌ Sincronización de datos difícil│
│ ✅ Failover transparente │
│ │
│ Casos de uso: Servidores web stateless, APIs │
│ │
└─────────────────────────────────────────────────────────────┘
Servicios AWS Alta Disponibilidad
| Servicio | HA Nativa | Configuración Requerida |
|---|---|---|
| S3 | ✅ 99.999999999% | Ninguna |
| DynamoDB | ✅ Multi-AZ auto | Ninguna |
| ALB/NLB | ✅ Multi-AZ | Especificar 2+ subnets |
| RDS | ⚠️ Opción | Activar Multi-AZ |
| EC2 | ❌ No | Diseñar con ASG |
| Lambda | ✅ Multi-AZ auto | Ninguna |
| Aurora | ✅ Multi-AZ | Activar réplicas |
Ejercicio: Identificar los SPOF
Escenario
Analice esta arquitectura e identifique los SPOF:
┌─────────────────────────────────────────────────────────────┐
│ ARQUITECTURA A ANALIZAR │
├─────────────────────────────────────────────────────────────┤
│ │
│ Internet │
│ │ │
│ ▼ │
│ ┌──────────┐ │
│ │ ALB │ │
│ └────┬─────┘ │
│ │ │
│ ┌──────────┴──────────┐ │
│ │ │ │
│ ▼ ▼ │
│ ┌────────┐ ┌────────┐ │
│ │ EC2 │ │ EC2 │ │
│ │ AZ-a │ │ AZ-a │ │
│ └────┬───┘ └────┬───┘ │
│ │ │ │
│ └──────────┬──────────┘ │
│ │ │
│ ▼ │
│ ┌──────────┐ │
│ │ RDS │ │
│ │ Single │ │
│ │ AZ │ │
│ └──────────┘ │
│ │
└─────────────────────────────────────────────────────────────┘
💡 Solución
SPOF identificados:
-
❌ Todas las EC2 en la misma AZ (AZ-a)
- Si AZ-a falla, todos los servidores están caídos
- Solución: Distribuir en AZ-a y AZ-b como mínimo
-
❌ RDS Single-AZ
- Si la AZ de la base de datos falla, posible pérdida de datos
- Solución: Activar RDS Multi-AZ
-
✅ ALB está OK (Multi-AZ por defecto si 2+ subnets)
Arquitectura corregida:
- EC2 en AZ-a Y AZ-b
- RDS con Multi-AZ activado
- ALB con subnets en 2+ AZ
Resumen
| Concepto | Descripción |
|---|---|
| HA | Sistema permanece accesible a pesar de fallos |
| SPOF | Componente único cuya falla detiene todo |
| Multi-AZ | Distribución en varias zonas |
| 99.9% | ~8h downtime/año (estándar) |
| Active-Passive | Uno activo, otro en espera |
| Active-Active | Todos procesan el tráfico |
Próxima sección: Load Balancers