Alta disponibilidad y clustering: servicios que no caen

Cuando un servicio crítico cae en una empresa, el tiempo cuenta en dinero, reputación y confianza. Una tienda de comercio electrónico que no está disponible durante el Black Friday, un sistema ERP que impide a los empleados trabajar durante horas, una plataforma SaaS con usuarios en múltiples zonas horarias que experimenta una interrupción de madrugada en Europa pero en plena jornada laboral en América: todos estos escenarios tienen un denominador común, la falta de una arquitectura diseñada para la continuidad del servicio. La alta disponibilidad no es un lujo para grandes empresas; es una inversión que se justifica por el coste de la alternativa.

La alta disponibilidad (HA, High Availability) es la capacidad de un sistema para seguir funcionando correctamente durante un porcentaje elevado del tiempo, incluyendo ante fallos de componentes individuales. Se expresa habitualmente como número de nueves: 99,9% de disponibilidad equivale a algo menos de 9 horas de caída al año; 99,99% (cuatro nueves) baja eso a menos de una hora al año; 99,999% (cinco nueves) significa menos de 5 minutos de caída al año. Cada nueve adicional es exponencialmente más caro y complejo de conseguir.

En este artículo vamos a explorar las tecnologías y patrones de diseño que hacen posible la alta disponibilidad en entornos empresariales reales: clustering de failover, balanceo de carga, redundancia de red y almacenamiento, y las consideraciones operativas que determinan si una arquitectura HA funciona en la práctica o solo sobre el papel.

Conceptos fundamentales: RPO y RTO

Antes de diseñar cualquier arquitectura de alta disponibilidad, es imprescindible establecer dos métricas clave con el negocio: RPO (Recovery Point Objective) y RTO (Recovery Time Objective). El RPO define la máxima pérdida de datos tolerable: si el sistema cae ahora y el RPO es de 1 hora, se puede tolerar perder hasta 1 hora de transacciones o datos. El RTO define el tiempo máximo tolerable de interrupción: cuánto tiempo puede estar el servicio caído antes de que el impacto al negocio sea inaceptable.

Estos dos números tienen implicaciones tecnológicas y económicas directas. Un RPO de 0 (cero pérdida de datos) requiere replicación síncrona entre nodos, lo que implica latencia adicional en todas las operaciones de escritura. Un RTO de 30 segundos requiere failover automático sin intervención humana, que es más complejo y costoso que el failover manual con 30 minutos de RTO. El diseño de la arquitectura HA debe ser proporcional a los requisitos de negocio: no tiene sentido diseñar para cinco nueves si el negocio puede tolerar 4 horas de interrupción al año.

Clustering de failover en Windows Server

Windows Server Failover Clustering (WSFC) es la tecnología de clustering de Microsoft integrada en Windows Server. Permite agrupar dos o más servidores (nodos) de forma que, si uno falla, los servicios que ejecutaba (roles del clúster) se trasladan automáticamente a otro nodo que continúa ofreciendo el servicio. Es la base tecnológica de la alta disponibilidad para SQL Server Always On, Hyper-V con migración en vivo, servidores de ficheros y muchos otros roles de Windows Server.

La configuración de un clúster de failover requiere varios componentes: todos los nodos deben pertenecer al mismo dominio Active Directory, deben tener conectividad de red redundante (al menos dos adaptadores de red por nodo, en redes separadas para el tráfico de clúster y el de cliente), y deben compartir almacenamiento (típicamente iSCSI o Fibre Channel) para los datos de los roles. El quorum es el mecanismo que el clúster usa para decidir qué nodos forman el clúster activo y evitar el problema del split-brain (dos grupos de nodos que creen ser el clúster activo simultáneamente).

Configuraciones de quorum recomendadas

• Nodo y disco testigo: para clústeres con número par de nodos, añade un disco testigo para tener mayoría impar
• Nodo y recurso compartido de archivo testigo: alternativa cuando no hay almacenamiento compartido disponible para testigo de disco
• Testigo en la nube (Azure): para clústeres distribuidos entre ubicaciones, un blob de Azure Storage actúa como testigo de quorum
• Solo mayoría de nodos: para clústeres con número impar de nodos (no recomendable para clústeres de dos nodos)

SQL Server Always On Availability Groups

Always On Availability Groups es la solución de alta disponibilidad más avanzada de SQL Server y uno de los casos de uso más importantes del clustering empresarial. Permite tener hasta 9 réplicas de una base de datos (una primaria y hasta 8 secundarias) con failover automático o manual, con soporte para réplicas en modo síncrono (RPO=0, el commit solo se confirma cuando la réplica secundaria lo ha escrito) o asíncrono (para réplicas en ubicaciones distantes donde la latencia de red haría el modo síncrono inviable).

Las réplicas secundarias no son pasivas por defecto: pueden configurarse para atender consultas de solo lectura, lo que permite distribuir la carga de reporting e informes entre los nodos secundarios sin impactar el rendimiento del nodo primario. Un Availability Group Listener es una dirección IP virtual y nombre de host que las aplicaciones usan para conectarse: el listener siempre apunta al nodo primario actual, por lo que las aplicaciones no necesitan modificarse cuando hay un failover. La reconexión tras el failover es transparente para las aplicaciones que usan cadenas de conexión correctas con el parámetro MultiSubnetFailover=True.

Clustering con Pacemaker en Linux: HA para el ecosistema open source

En el ecosistema Linux, el stack de alta disponibilidad más extendido es la combinación de Corosync (comunicación entre nodos del clúster) y Pacemaker (gestor de recursos del clúster). Esta combinación, disponible en todas las distribuciones empresariales (RHEL/Rocky Linux, SUSE Linux Enterprise, Ubuntu Server), permite crear clústeres de alta disponibilidad para servicios Linux: servidores web Apache o Nginx, bases de datos MySQL o PostgreSQL, servidores de ficheros NFS y prácticamente cualquier servicio que pueda arrancarse y pararse.

Pacemaker gestiona los recursos del clúster a través de Resource Agents, scripts que saben cómo arrancar, parar, comprobar el estado y migrar cada tipo de recurso. Los agents están disponibles para los servicios más comunes (PostgreSQL, MySQL, Apache, Nginx, dirección IP virtual, sistema de ficheros) y es posible escribir agents personalizados para aplicaciones propias. La configuración del clúster se almacena en una base de datos CIB (Cluster Information Base) replicada entre todos los nodos, que define qué recursos existen, dónde deben ejecutarse preferentemente y qué restricciones de orden o colocación tienen.

Balanceo de carga: distribuyendo el trabajo

El balanceo de carga y el failover resuelven problemas distintos y complementarios. El failover garantiza que el servicio continúa cuando un nodo falla (disponibilidad). El balanceo de carga distribuye las peticiones entre varios nodos activos simultáneamente (escalabilidad horizontal y también disponibilidad, porque si un nodo falla el balanceador deja de enviarle tráfico). En arquitecturas modernas, ambas capacidades suelen estar presentes.

HAProxy es el balanceador de carga open source más utilizado en entornos de producción Linux. Es capaz de gestionar cientos de miles de conexiones concurrentes, soporta balanceo de carga L4 (TCP) y L7 (HTTP/HTTPS con terminación SSL), ofrece múltiples algoritmos de balanceo (round-robin, least connections, source IP hash para sesiones pegajosas) y tiene un sistema de health checks que detecta automáticamente nodos no disponibles y los excluye del pool de balanceo. La combinación de dos HAProxy en activo-pasivo con Keepalived (que gestiona la IP virtual que apunta al HAProxy activo) es una arquitectura estándar para alta disponibilidad del propio balanceador.

Algoritmos de balanceo y cuándo usarlos

• Round-robin: distribuye peticiones de forma rotatoria, ideal para peticiones de carga similar y servidores homogéneos
• Least connections: envía cada petición al nodo con menos conexiones activas, mejor para peticiones de duración variable
• Source IP hash: el mismo cliente siempre va al mismo servidor, necesario para aplicaciones sin sesiones distribuidas
• Random: selección aleatoria, útil para distribuir carga sin estado de conexión
• Resource based: envía tráfico según la carga actual de cada nodo, requiere monitorización de los nodos

Nginx como balanceador y proxy inverso

Nginx tiene una posición peculiar en el ecosistema de alta disponibilidad: es a la vez un servidor web de alto rendimiento, un proxy inverso y un balanceador de carga. En muchas arquitecturas web modernas, Nginx desempeña el papel de terminador SSL (descifra el HTTPS y envía HTTP en claro a los backends, reduciendo la carga de los servidores de aplicación), proxy inverso (añade cabeceras, gestiona el enrutamiento por URL) y balanceador de carga (distribuye peticiones entre múltiples instancias del servidor de aplicación).

Para la capa de bases de datos, donde Nginx no es la herramienta adecuada, existen proxies específicos: ProxySQL para MySQL/MariaDB y pgBouncer o pgPool-II para PostgreSQL. Estos proxies gestionan el pool de conexiones (reduciendo el número de conexiones reales a la base de datos, que son costosas), pueden enrutar las consultas de solo lectura a las réplicas secundarias automáticamente, y manejan el failover de base de datos de forma transparente para la aplicación.

Redundancia de red: eliminando puntos únicos de fallo

Una arquitectura de alta disponibilidad perfecta en software puede fallar si la infraestructura de red tiene puntos únicos de fallo. La redundancia de red comienza con los propios servidores: cada nodo de un clúster debe tener al menos dos tarjetas de red físicas conectadas a switches distintos, configuradas en modo bonding/teaming para que el sistema operativo las presente como un único adaptador de red lógico que sigue funcionando si falla una de las tarjetas o uno de los switches.

En el nivel de la red física, los switches de acceso deben estar en pares con conexiones redundantes (LACP/802.3ad para agregar ancho de banda y redundancia) y los switches de distribución o núcleo deben tener también su propia redundancia. Los routers y firewalls perimetrales deben estar en configuración activo-pasivo con protocolos de gateway redundante como VRRP o HSRP. Cada enlace de acceso a internet debe tener al menos una línea de backup de un proveedor diferente, con BGP o rutas estáticas con failover automático.

Almacenamiento para alta disponibilidad: DRBD y GFS2

Los clústeres de alta disponibilidad necesitan que sus datos estén disponibles en múltiples nodos. Hay dos aproximaciones fundamentales: almacenamiento compartido (una SAN o NAS que todos los nodos acceden simultáneamente) o replicación entre nodos (cada nodo tiene su almacenamiento local y los datos se replican entre ellos). DRBD (Distributed Replicated Block Device) implementa la segunda aproximación para Linux: replica un dispositivo de bloque entre dos o más nodos en tiempo real, con soporte para modo síncrono (el más seguro) o asíncrono.

GFS2 (Global File System 2) es un sistema de ficheros de clúster que permite que múltiples nodos accedan simultáneamente al mismo almacenamiento compartido con coherencia de datos garantizada. Es necesario para casos de uso donde varios nodos necesitan leer y escribir en los mismos ficheros al mismo tiempo (a diferencia del clustering activo-pasivo donde solo el nodo activo accede al almacenamiento). Ceph es otra solución de almacenamiento distribuido que está ganando mucho terreno, especialmente como base de almacenamiento para clústeres de Kubernetes y plataformas de virtualización como Proxmox.

Health checks y deteccion automatica de fallos

La efectividad de cualquier sistema de alta disponibilidad depende de la calidad de su sistema de detección de fallos. Un fallo no detectado o detectado tarde convierte el RTO teórico en papel mojado. Los health checks deben ser específicos al servicio: no basta con comprobar que el proceso está en ejecución (un proceso puede estar en ejecución pero no respondiendo correctamente); hay que comprobar que el servicio responde correctamente a peticiones reales. Un health check de base de datos que hace una consulta simple contra la base de datos es radicalmente más útil que uno que solo comprueba si el puerto 5432 está escuchando.

Los intervalos y umbrales de los health checks deben calibrarse cuidadosamente. Un intervalo muy largo aumenta el tiempo de detección del fallo (aumentando el RTO efectivo). Un intervalo muy corto puede generar failovers innecesarios ante fallos transitorios de red o picos de carga. Lo habitual es configurar varios checks consecutivos fallidos como condición para declarar el fallo (por ejemplo, 3 checks fallidos en 15 segundos con intervalos de 5 segundos), lo que filtra los falsos positivos sin añadir demasiado tiempo al RTO.

Pruebas de failover: el elemento mas ignorado

Un sistema de alta disponibilidad que nunca se prueba no es un sistema de alta disponibilidad: es una arquitectura de alta disponibilidad potencial. La única forma de saber que el failover funciona correctamente y dentro del RTO establecido es ejecutarlo de forma controlada. Las pruebas de failover deben ser eventos planificados y regulares (al menos trimestralmente para sistemas críticos), documentados con tiempos de inicio y fin de cada fase del proceso, y con impacto medido en los servicios dependientes.

• Simulación de fallo de nodo primario: apagar el nodo activo y verificar el tiempo hasta la recuperación completa del servicio
• Fallo de disco o controladora de almacenamiento: retirar un disco del RAID y verificar que el sistema continúa operando
• Fallo de tarjeta de red: desconectar un cable de red y verificar que el bonding/teaming conmuta correctamente
• Fallo del balanceador de carga: apagar el HAProxy activo y verificar que Keepalived promueve el pasivo
• Prueba de restauración desde backup: restaurar datos de un período concreto para verificar integridad y tiempo de restauración

Alta disponibilidad en la nube: zonas y regiones

Las plataformas cloud (AWS, Azure, Google Cloud) ofrecen primitivas de alta disponibilidad que abstraen gran parte de la complejidad del clustering tradicional. Las Availability Zones (zonas de disponibilidad) son centros de datos físicamente separados dentro de una misma región, conectados por redes de muy baja latencia. Distribuir las instancias de una aplicación entre múltiples zonas garantiza que el fallo de un centro de datos completo no afecte al servicio. Los balanceadores de carga gestionados (AWS ALB/NLB, Azure Load Balancer, Google Cloud Load Balancing) distribuyen el tráfico entre las instancias y retiran automáticamente del pool las instancias no saludables.

Para aplicaciones que requieren disponibilidad incluso ante el fallo de una región completa (un desastre natural, un incidente masivo de infraestructura), la distribución multi-región añade otra capa de complejidad: replicación de datos entre regiones, gestión del DNS con failover automático (AWS Route 53 con health checks, Azure Traffic Manager, Cloudflare Load Balancing), y consistencia eventual frente a consistencia fuerte en los datos. Estos requisitos multi-región están justificados para una minoría de aplicaciones críticas; la mayoría de las empresas obtiene una disponibilidad más que suficiente con arquitecturas activo-activo dentro de una única región.

La alta disponibilidad no se diseña; se prueba. Una arquitectura HA que no se ha failoverizado en producción bajo condiciones controladas es una hipótesis, no una garantía.

Conclusión: disponibilidad como disciplina de ingeniería

Diseñar sistemas de alta disponibilidad es una disciplina de ingeniería que combina conocimiento técnico profundo con entendimiento del negocio. El técnico más brillante puede construir una arquitectura HA perfecta que no sirve al negocio si los requisitos de RPO y RTO no estaban bien definidos desde el principio. Por eso, el primer paso en cualquier proyecto de alta disponibilidad no es elegir la tecnología: es sentarse con los responsables del negocio y entender qué significa para ellos que un servicio 'no esté disponible' y cuánto tiempo pueden tolerarlo.

La tecnología de alta disponibilidad es madura y accesible: tanto en el ecosistema Windows con WSFC y Always On como en Linux con Pacemaker y HAProxy, las soluciones están documentadas, son estables y cuentan con amplia experiencia de uso en producción. El reto no es técnico sino organizativo: mantener la arquitectura documentada y actualizada, ejecutar las pruebas de failover regularmente, y gestionar los cambios de infraestructura con el rigor que merecen los sistemas críticos.