La alta disponibilidad busca reducir el tiempo durante el que un servicio deja de estar accesible. No significa que una plataforma nunca falle: obliga a identificar qué componentes pueden fallar, cuánto tiempo de interrupción es aceptable y cómo se recupera el servicio.
La arquitectura debe responder a esas preguntas con medidas concretas, no solo con más servidores.
Definir qué debe seguir funcionando
Empieza por el servicio que el usuario necesita y por sus dependencias. Una web puede tener dos nodos de aplicación y seguir caída si ambos dependen de una única base de datos, un almacenamiento compartido o un DNS sin alternativa. Define el objetivo de disponibilidad y el RTO, es decir, el tiempo máximo admisible para recuperar el servicio.
El RPO añade otra dimensión: cuántos datos se podrían perder después de un fallo. Una copia nocturna y una réplica continua no ofrecen el mismo resultado.
Redundancia de componentes
La redundancia puede aplicarse a nodos web, discos, fuentes de alimentación, red y datos. Un balanceador distribuye solicitudes, pero necesita saber cuándo un nodo está realmente sano. Una comprobación que solo recibe código HTTP 200 puede pasar por alto que la aplicación no puede consultar la base de datos.
La redundancia introduce estados que deben coordinarse. Las sesiones, colas y archivos subidos no pueden quedar ligados a un único nodo si las peticiones cambian de servidor.
Datos, replicación y consistencia
Replicar una base de datos no equivale a tener una copia de seguridad. Un borrado accidental puede propagarse a todas las réplicas. Las copias independientes y las pruebas de restauración siguen siendo necesarias.
Si dos nodos escriben a la vez, hay que definir cómo se resuelven conflictos y cuánto retraso de replicación es aceptable. Para algunos proyectos es preferible un nodo principal con recuperación probada antes que una topología distribuida difícil de operar.
Qué ocurre durante el cambio
Documenta cómo se detecta el fallo, quién decide desviar tráfico y cómo se devuelve un nodo al servicio. Una conmutación automática puede reducir tiempo, pero también puede mover tráfico hacia una configuración incorrecta si las comprobaciones son débiles.
Prueba los procedimientos con una carga controlada. Un plan que solo existe en un documento no demuestra que el equipo pueda ejecutarlo bajo presión.
El límite de la alta disponibilidad
La redundancia no corrige código vulnerable, errores de despliegue ni una dependencia externa que se ha caído. Tampoco elimina el mantenimiento. Cada componente adicional necesita actualizaciones, monitorización, permisos y documentación.
Qué revisar antes de ampliar
Mide los fallos que realmente han ocurrido, su duración y la dependencia que los causó. Si el objetivo es reducir caídas por saturación, puede bastar con ajustar recursos o caché; si el problema es una zona única de fallo, necesitarás otra estrategia. La opción de Cloud Hosting puede valorarse solo después de definir esos requisitos.
Dependencias y dominios de fallo
Un dominio de fallo es un componente o zona cuya caída afecta a varias piezas a la vez. Dos servidores en el mismo host físico no ofrecen la misma independencia que dos hosts separados. Del mismo modo, dos nodos web no eliminan el riesgo de un único proveedor DNS, una única red o unas credenciales compartidas.
Haz un inventario de dependencias y marca cuáles pueden sustituirse. Esta revisión suele revelar que la base de datos, el almacenamiento o el servicio de correo tienen una disponibilidad distinta a la página web.
Salud real y conmutación
Las comprobaciones deben probar una función representativa. Un endpoint de salud puede verificar conexión a base de datos, espacio disponible y estado de una dependencia sin exponer información sensible. Si la comprobación es demasiado simple, el tráfico se dirigirá a un nodo que responde pero no puede trabajar.
La vuelta al nodo reparado también necesita control. Devuélvelo gradualmente y observa errores antes de considerarlo estable.
Pruebas que merecen la pena
Simula la pérdida de un nodo, la saturación de un disco y la restauración de una copia. Registra el tiempo de detección, decisión, recuperación y validación. Una prueba revela tanto los fallos técnicos como los de coordinación.
Disponibilidad y mantenimiento planificado
Una plataforma redundante también necesita ventanas de mantenimiento. Si no se puede retirar un nodo sin interrumpir el servicio, la arquitectura no ha resuelto todas sus dependencias. Coordina actualizaciones, drenaje de conexiones y comprobaciones posteriores.
Los objetivos deben ser realistas. Reducir un fallo de varias horas a unos minutos puede justificar una inversión concreta; perseguir una continuidad absoluta puede añadir complejidad que el proyecto no puede probar ni mantener.
Registrar lo que sucede
Conserva eventos de conmutación, errores de salud, retrasos de replicación y resultados de restauración. Una tendencia de latencia creciente puede anticipar el fallo antes de que el balanceador retire un nodo.
La monitorización permite aprender del incidente, pero no sustituye a un plan de recuperación. El equipo debe saber qué señal requiere una actuación y cuál es solo una anomalía transitoria.
Revisar el objetivo con datos
Compara el tiempo de caída, el impacto y el coste de cada medida. La alta disponibilidad debe mejorar un objetivo concreto y poder demostrarse con pruebas. Si no se conoce el resultado esperado, la redundancia puede convertirse en una capa difícil de justificar.