La alta disponibilidad (HA, High Availability) es la propiedad de un sistema diseñado para seguir operativo pese a fallos de sus componentes, alcanzando niveles de servicio acordados durante periodos prolongados. Su objetivo no es eliminar los fallos —algo imposible— sino evitar que el fallo de una pieza se convierta en la caída del servicio. Esto se logra mediante redundancia inteligente: duplicar los componentes críticos y, sobre todo, eliminar todo punto único de fallo (single point of failure, SPOF).
Medir la disponibilidad: los "nueves" y sus límites
La disponibilidad se expresa en porcentaje de tiempo operativo y se traduce en una ventana de indisponibilidad anual concreta. Conviene tenerla presente porque cada nueve adicional multiplica el coste:
| Disponibilidad | Nombre | Inactividad anual aprox. |
|---|---|---|
| 99% | Dos nueves | 3 días y 15 horas |
| 99,9% | Tres nueves | 8 horas y 46 minutos |
| 99,99% | Cuatro nueves | 52 minutos |
| 99,999% | Cinco nueves | 5 minutos y 15 segundos |
Dos métricas complementan el porcentaje: el MTBF (tiempo medio entre fallos), que mide la fiabilidad del componente, y el MTTR (tiempo medio de reparación), que mide la velocidad de recuperación. La disponibilidad mejora tanto aumentando el MTBF como reduciendo el MTTR; en la práctica, automatizar la recuperación para bajar el MTTR suele ser más rentable que perseguir hardware infalible.
Redundancia: activo-activo frente a activo-pasivo
Hay dos topologías fundamentales. En activo-pasivo, un nodo atiende el tráfico mientras otro espera en reserva (standby) listo para asumir el servicio cuando el primario cae; es más sencillo de operar pero desaprovecha capacidad. En activo-activo, todos los nodos atienden tráfico simultáneamente repartiéndose la carga, lo que aprovecha mejor los recursos y suma capacidad, a cambio de exigir sincronización de estado y resolución de conflictos. La elección depende de si la aplicación mantiene estado (stateful) o no (stateless): las aplicaciones sin estado escalan en activo-activo con naturalidad.
Balanceo de carga (load balancing)
El balanceador es el componente que distribuye las peticiones entre los nodos disponibles y retira de rotación a los que fallan. Trabaja en distintas capas del modelo OSI: un balanceador de capa 4 (transporte) reparte por IP y puerto sin inspeccionar el contenido, mientras que uno de capa 7 (aplicación) decide según la URL, las cookies o las cabeceras HTTP, permitiendo enrutado avanzado. Los algoritmos habituales son round-robin, menor número de conexiones (least connections) y hashing por IP para mantener afinidad de sesión. Un detalle crítico: el propio balanceador no debe ser un SPOF, por lo que se despliega en pareja redundante con una IP virtual flotante.
Clustering y protocolos de latido (heartbeat)
Un clúster agrupa varios nodos que se comportan como un único sistema lógico. La coordinación se apoya en un protocolo de latido (heartbeat): cada nodo emite señales periódicas y, cuando dejan de recibirse de un compañero, el clúster lo da por caído e inicia el failover. El gran enemigo de este mecanismo es el split-brain: si la red entre nodos se parte pero ambos siguen vivos, cada uno puede creerse el único superviviente y asumir el rol primario, provocando corrupción de datos. Se previene con quórum (mayoría de votos para actuar, lo que exige un número impar de nodos o un testigo) y con técnicas de fencing/STONITH que apagan al nodo dudoso antes de que cause daño. Herramientas como Pacemaker y Corosync en Linux, o Keepalived con VRRP, implementan estos patrones.
Más allá de la HA: redundancia geográfica y datos
La alta disponibilidad protege frente a fallos de componente dentro de un emplazamiento. Frente a un desastre que afecte a un centro de datos entero, se recurre a la replicación geográfica entre zonas y regiones, con dos objetivos definidos por el plan de continuidad: el RTO (tiempo máximo aceptable para restaurar el servicio) y el RPO (pérdida máxima de datos tolerable). La replicación de bases de datos puede ser síncrona (sin pérdida de datos pero con latencia y acoplamiento) o asíncrona (mejor rendimiento a costa de un RPO mayor). Importa no confundir HA con copia de seguridad: la redundancia replica también los errores lógicos y el borrado accidental, por lo que la HA nunca sustituye a un backup verificado.
Alta disponibilidad en la nube y en contenedores
Las plataformas cloud reformulan la HA con primitivas gestionadas. Los proveedores organizan su infraestructura en zonas de disponibilidad (centros de datos independientes dentro de una región) y regiones geográficamente separadas; distribuir las réplicas entre varias zonas protege frente al fallo de un centro completo. Los grupos de autoescalado reemplazan automáticamente las instancias que fallan una comprobación de salud, reduciendo el MTTR a minutos sin intervención humana. En el mundo de contenedores, un orquestador como Kubernetes implementa los mismos principios de forma declarativa: define un número deseado de réplicas de cada servicio, vigila su salud mediante liveness y readiness probes —la versión moderna del heartbeat— y reprograma automáticamente los contenedores caídos en nodos sanos. La lógica de quórum reaparece en el plano de control: el almacén de estado del clúster (etcd) exige mayoría para evitar inconsistencias, por lo que se despliega en un número impar de nodos.
Patrones de resiliencia en la aplicación
La redundancia de infraestructura no basta si la aplicación no está preparada para tolerar fallos. Los patrones de resiliencia más extendidos son el circuit breaker, que deja de invocar un servicio que está fallando para no agotar recursos esperando respuestas que no llegarán; los reintentos con retroceso exponencial, que vuelven a intentar una operación transitoria espaciando los intentos para no saturar el sistema; los tiempos de espera (timeouts) bien ajustados, que evitan que una petición colgada bloquee un hilo indefinidamente; y los mamparos (bulkheads), que aíslan recursos para que el fallo de una funcionalidad no arrastre a las demás. Diseñar la aplicación como stateless, externalizando el estado a almacenes compartidos, es lo que permite que el balanceador reparta el tráfico libremente y que cualquier nodo atienda cualquier petición.
Marco normativo y buenas prácticas
La continuidad del servicio es exigible por norma. La norma ISO 22301 define los requisitos de un sistema de gestión de la continuidad del negocio, incluyendo el análisis de impacto que fija los RTO y RPO. La ISO/IEC 27001 incorpora la disponibilidad como uno de los tres pilares de la seguridad de la información, junto con la confidencialidad y la integridad. En el plano operativo, las prácticas de ingeniería de fiabilidad (SRE) formalizan los SLO, los presupuestos de error y las pruebas de caos para validar que la redundancia funciona de verdad.
Probar la redundancia: ingeniería del caos
Una arquitectura redundante que nunca se ha probado en condiciones de fallo es una hipótesis, no una garantía. La ingeniería del caos formaliza la práctica de inyectar fallos controlados en producción —apagar un nodo, introducir latencia en la red, agotar recursos— para verificar que los mecanismos de conmutación responden como se espera. El principio es contraintuitivo pero sólido: es preferible provocar el fallo de forma planificada, en horario controlado y con el equipo preparado, que descubrir en plena madrugada que el failover no funciona. Estos experimentos parten siempre de una hipótesis ("si cae este nodo, el servicio seguirá disponible con una degradación inferior al X%") y se ejecutan con un radio de impacto limitado y un mecanismo de aborto inmediato. Los ejercicios periódicos de conmutación, conocidos como game days, mantienen entrenado al equipo y validan que la documentación de recuperación sigue siendo correcta tras cada cambio.
El coste de la disponibilidad: dimensionar sin exceso
Cada nivel adicional de disponibilidad multiplica el coste de infraestructura, operación y complejidad. Pasar de tres a cuatro nueves puede implicar duplicar nodos, contratar replicación entre zonas y reforzar la monitorización; alcanzar cinco nueves exige redundancia geográfica activa-activa y equipos de guardia permanente. La decisión correcta no es técnica sino económica: se compara el coste de la indisponibilidad para el negocio (pérdida de ingresos, penalizaciones contractuales, daño reputacional) con el coste de prevenirla. Un comercio electrónico en campaña de rebajas justifica los cinco nueves; un sistema interno de informes mensuales rara vez necesita más de tres. Dimensionar la disponibilidad por servicio, y no aplicar un nivel uniforme a toda la plataforma, es lo que permite invertir donde de verdad importa y ahorrar donde el negocio puede tolerar una breve interrupción.
Errores comunes que arruinan la alta disponibilidad
Los incidentes graves casi siempre delatan los mismos descuidos: dejar un SPOF oculto (un único conmutador de red, una sola fuente de alimentación, un balanceador no redundado); no probar nunca el failover real, descubriendo en plena crisis que la réplica no arranca; ignorar el riesgo de split-brain por falta de quórum; confundir HA con backup; y diseñar para "cinco nueves" sin medir si el negocio los necesita y los puede pagar. Otro fallo recurrente es no monitorizar el estado del nodo pasivo, que se degrada en silencio hasta que se necesita y no responde.
Preguntas frecuentes
¿Cuál es la diferencia entre alta disponibilidad y recuperación ante desastres? La HA mantiene el servicio frente a fallos de componente dentro de un emplazamiento, con conmutación automática en segundos. La recuperación ante desastres (DR) restaura el servicio tras la pérdida de un emplazamiento completo, con tiempos definidos por el RTO y el RPO.
¿Necesito siempre cinco nueves? No. Cada nueve adicional encarece notablemente la arquitectura. El nivel objetivo debe derivarse del impacto real de la indisponibilidad sobre el negocio, no de una aspiración genérica.
¿La redundancia me protege del borrado accidental de datos? No. La redundancia replica también los errores. Para eso se necesitan copias de seguridad versionadas y probadas, independientes del sistema en producción.
¿Qué es exactamente el split-brain y cómo se evita? Es la situación en que una partición de red hace que dos nodos se crean simultáneamente el primario. Se evita exigiendo quórum (mayoría) para actuar y aplicando fencing para aislar al nodo dudoso.
La alta disponibilidad no se compra, se diseña y se prueba: parte de identificar y eliminar cada punto único de fallo, elige la topología de redundancia que corresponde al perfil de estado de la aplicación, coordina los nodos con latidos y quórum que evitan el split-brain, y se valida con ejercicios reales de conmutación. El número de nueves debe responder al impacto sobre el negocio, no a una cifra de catálogo. En Summum Sistemas diseñamos arquitecturas resilientes, definimos los objetivos de RTO y RPO con el cliente y verificamos el failover de forma controlada, para que la redundancia se demuestre antes de que un incidente la ponga a prueba.