La alta disponibilidad (HA, high availability) es una propiedad de la infraestructura que se mide como porcentaje de tiempo en que el servicio está disponible para los usuarios. Entre un sistema con 99% de uptime y uno con 99,99% hay unos 3 días al año de caída frente a 52 minutos. Se consigue eliminando puntos únicos de fallo en cuatro capas (balanceo, cómputo, datos y detección) y probando periódicamente que el failover funciona. En uno de nuestros casos, una tienda online que se caía en cada campaña pasó del ~98% de disponibilidad al 99,99% tras migrar a una arquitectura redundante con escalado automático, y acabó pagando por uso real sin gastar más que antes. La HA se dimensiona según lo que cuesta cada hora de caída, no según lo que la técnica permite.
Esta guía explica cómo se construye HA en la práctica, qué componentes implica y cuándo el coste extra está justificado.
¿Qué significa «alta disponibilidad» de verdad?
Se expresa como un número de nueves:
| Nueves | Uptime anual | Downtime al año |
|---|---|---|
| 99% (2 nueves) | 99% | 3,65 días |
| 99,9% (3 nueves) | 99,9% | 8,76 horas |
| 99,95% | 99,95% | 4,38 horas |
| 99,99% (4 nueves) | 99,99% | 52,6 minutos |
| 99,999% (5 nueves) | 99,999% | 5,26 minutos |
Cada nueve adicional cuesta exponencialmente más. Llegar a 99,99% requiere arquitectura redundante en todos los puntos críticos; llegar a 99,999% requiere replicación geográfica y procedimientos operativos muy estrictos.
Antes de empezar, calcula cuánto cuesta una hora de caída. Si la respuesta son cientos de euros, 99,9% sobra. Si son miles, hay que ir a 99,99% mínimo.
Componentes clave
Balanceador de carga
Reparte tráfico entre múltiples instancias backend. Si una cae, el balanceador detecta el fallo (health checks) y deja de enviarle peticiones. Opciones: ALB/NLB en AWS, Application Gateway en Azure, GCP Load Balancing; HAProxy o Nginx self-hosted.
Sin balanceador o con uno solo, no hay HA: ese balanceador es el punto único de fallo. El balanceador también aísla problemas. En una infraestructura que operamos, una única sesión de usuario llegó a saturar la red entre los nodos de la base de datos; la monitorización de tráfico permitió identificarla y bloquearla en el balanceador en minutos, sin que el resto de usuarios notara nada.
Múltiples instancias en distintas zonas
Dos backends en la misma zona de disponibilidad no protegen contra fallo de zona. La regla mínima: dos instancias en dos zonas (AZ) distintas. Para HA fuerte, multi-región. Lo mismo aplica fuera del cómputo: un segundo servidor de backups en otra ubicación puede parecer redundancia de más, hasta que una sustitución de hardware en la ubicación principal obliga a tirar de él y el servicio ni se entera. Nos pasó exactamente eso semanas después de montarlo.
Replicación de base de datos
La base de datos suele ser el punto más complicado. Opciones:
- Réplica síncrona (HA real, latencia añadida en escritura).
- Réplica asíncrona (mejor rendimiento, pequeño riesgo de pérdida de datos en failover).
- Multi-master (compleja, conflictos de escritura).
Servicios gestionados (RDS Multi-AZ, Aurora, Azure SQL HA) cubren la mayoría de casos sin gestionar la replicación manualmente. Y un clúster bien montado permite además operar sin ventanas de corte: hemos migrado el motor de un clúster de base de datos en producción incorporando los nodos nuevos uno a uno al clúster viejo, sin parar el servicio en ningún momento. La HA también te permite mantener y evolucionar la plataforma sin madrugadas de parada programada.
Failover automático
Cuando el primario cae, el secundario asume su rol sin intervención humana. Tiempo de failover típico:
- RDS Multi-AZ: 30-120 segundos.
- Aurora: 30 segundos.
- Soluciones custom con Keepalived/Pacemaker: 5-30 segundos.
Sin failover automático, una caída a las 03:00 espera al técnico de guardia, y eso ya no es HA. Y la escalada vertical también puede ser parte del plan: en plena campaña de un cliente, con la CPU al 100%, doblamos la capacidad del servidor de 8 a 16 núcleos con menos de un minuto de corte, porque la operación estaba prevista y ensayada. Salió bien porque el procedimiento existía antes del incidente. Antes de escalar así, conviene saber si el problema es potencia o arquitectura, la pregunta central para escalar un servidor sin sobredimensionar.
Monitorización y alertas en tiempo real
Sin observabilidad activa no detectas un fallo parcial: por ejemplo, una instancia que responde 200 OK pero devuelve datos vacíos. Métricas clave: latencia p95, tasa de error, cola de peticiones, conexiones a base de datos.
RPO y RTO: las métricas que faltan en muchos proyectos
- RTO (Recovery Time Objective): cuánto puedes tardar en recuperarte de un incidente.
- RPO (Recovery Point Objective): cuántos datos puedes permitirte perder, medido en tiempo.
Ejemplos típicos:
| Caso | RTO | RPO |
|---|---|---|
| Ecommerce mediano | 1 hora | 15 minutos |
| ERP empresarial | 4 horas | 1 hora |
| Banca / pagos | Minutos | 0 (sin pérdida) |
| Web corporativa | 1 día | 1 día |
Definir RTO y RPO antes de diseñar la infraestructura es lo que evita sobre-ingeniería innecesaria y huecos críticos.
¿Cuándo conviene HA y cuándo no?
Conviene invertir en alta disponibilidad cuando el coste de la caída supera el coste de la redundancia, y no antes. La cuenta cabe en una servilleta. Multiplica las horas de caída esperables al año con la arquitectura actual por lo que cuesta cada hora (ventas perdidas, personal parado, penalizaciones de SLA con tus propios clientes, daño reputacional) y compáralo con el sobrecoste anual de la arquitectura redundante. En cuanto la primera cifra dobla a la segunda, la decisión está tomada. Con obligaciones contractuales o sector regulado (banca, sanidad, telco), la cuenta ni siquiera hace falta. En el otro extremo, montar HA para una web corporativa o una herramienta interna no crítica es pagar complejidad operativa permanente por un riesgo que se toleraría sin problema.
Conviene cuando se cumple alguno:
- El coste de una hora de caída supera los miles de euros.
- Hay obligación contractual con SLA hacia tus clientes.
- Estás en un sector regulado (banca, sanidad, telco).
- El tráfico está distribuido geográficamente y necesitas latencia baja en varios continentes.
No conviene (o no aún) cuando:
- Web corporativa interna, blog, herramientas no críticas.
- Producto en fase muy temprana donde aún se valida el problema.
- La operación interna no soporta complejidad operativa adicional.
El error más común es construir HA por costumbre técnica sin haber definido si el negocio lo necesita.
Buenas prácticas
- Probar el failover periódicamente. Una HA que nunca se ha activado no se sabe si funciona. Lo hemos comprobado en carne ajena con un backup de producción restaurado en un entorno de pruebas que no arrancaba, porque el cifrado usaba la llave de otro nodo. Se diagnosticó y resolvió en menos de una hora, pero si esa restauración se hubiera necesitado durante un incidente real, esa hora habría sido de caída. Las pruebas existen para que los fallos aparezcan en el ensayo.
- No solo redundar el cómputo: la base de datos, la cola de mensajes, el DNS y la red también deben ser redundantes.
- Documentar el runbook: qué hacer si el sistema automático no responde.
- Postmortems sin culpas tras cada incidente: aprender sin buscar responsables.
- No confundir HA con backup. Si los datos se corrompen, el sistema redundante replica la corrupción. Necesitas backup también.
¿Te ayudamos a evaluar tu caso?
En Elimática diseñamos infraestructuras de alta disponibilidad para entornos B2B: definimos RTO/RPO, dimensionamos la arquitectura, automatizamos failover y probamos los procedimientos.
Servidores gestionados | Diagnóstico gratuito.
¿Prefieres una introducción más sencilla antes de entrar en el detalle técnico? Lee Alta disponibilidad: balanceo de carga y failover explicados.