Arquitectura de Clústeres de Alta Disponibilidad (HA) con Corosync y Pacemaker en Linux

En entornos empresariales críticos, el tiempo de inactividad no es una opción aceptable. La arquitectura de clústeres de Alta Disponibilidad (HA) en sistemas Linux se ha estandarizado en torno a una combinación robusta y probada en producción: Corosync y Pacemaker. Este stack proporciona las primitivas necesarias para gestionar el estado, el quórum y los recursos, asegurando que los servicios sigan operando de forma ininterrumpida frente a fallos de hardware o de red.

En este artículo, desgranaremos la arquitectura interna de estas herramientas y orquestaremos el despliegue avanzado para un clúster de alta disponibilidad.

Anatomía de un Clúster HA Moderno#

La separación de responsabilidades es el pilar del éxito en el ecosistema HA de Linux. Históricamente, proyectos monolíticos intentaban abarcar demasiado. Hoy, el estándar arquitectónico se divide en dos capas modulares bien definidas:

Corosync: La Capa de Mensajería y Quórum

Corosync actúa como el sistema nervioso del clúster. Implementa un modelo de comunicación basado en anillos (ring) mediante redes multicast o unicast (UDPU), garantizando que todos los nodos compartan una visión unificada del estado global del sistema. Además, proporciona el motor de quórum (votequorum), vital para prevenir el escenario catastrófico de cerebro dividido (split-brain).

Nota Importante: Para topologías de dos nodos, es imperativo configurar two_node: 1 en la sección de quórum de Corosync o, de forma preferente, implementar un mecanismo de tie-breaker mediante qdevice para evitar la pérdida total de quórum si un nodo cae.

Pacemaker: El Cluster Resource Manager (CRM)

Pacemaker es el cerebro de la operación. Se suscribe a los eventos topológicos de Corosync y toma decisiones deterministas de enrutamiento y estado para los recursos (IPs virtuales, bases de datos, montajes compartidos). Sus principales demonios incluyen:

• crmd (Cluster Resource Management Daemon): Orquesta las acciones. Un nodo del clúster es elegido como el Designated Controller (DC) encargado de centralizar las decisiones.
• lrmd (Local Resource Management Daemon): Ejecuta scripts locales (operaciones start, stop, monitor) a través de agentes OCF (Open Cluster Framework).
• stonithd (Shoot The Other Node In The Head): Controla el fencing, aislando a nivel de hardware o de hipervisor los nodos problemáticos para proteger la integridad de los datos.

Implementación Práctica: Configuración de la Topología Base#

Asumiremos un entorno corporativo con dos nodos (node-01 y node-02) ejecutando RHEL/AlmaLinux 9.

1. Inicialización de Corosync

En lugar de editar manualmente /etc/corosync/corosync.conf, la práctica moderna dictamina el uso de la CLI pcs (Pacemaker Configuration System) para orquestar la configuración distribuida.

# Autenticación segura entre nodos
pcs host auth node-01 node-02 -u hacluster -p 'SuperSecretPassword'

# Configuración del anillo del clúster (protocolo Unicast UDPU por defecto en RHEL 8+)
pcs cluster setup mi_cluster_ha node-01 node-02

# Arranque síncrono y habilitación de los servicios a nivel de systemd
pcs cluster start --all
pcs cluster enable --all

2. El Imperativo del Fencing (STONITH)

El mecanismo de fencing no es opcional en arquitecturas serias. Si un nodo pierde comunicación, Pacemaker debe tener la certeza absoluta de que está físicamente apagado o aislado antes de transicionar una IP flotante o montar una LUN en el nodo sobreviviente. Usaremos una interfaz Out-of-Band (OOB) como IPMI/iLO de ejemplo:

# Configuración de un dispositivo STONITH vía IPMI LAN
pcs stonith create fence_node_01 fence_ipmilan \
    pcmk_host_list="node-01" \
    ipaddr="10.0.0.101" \
    login="admin" \
    passwd="ipmi_password" \
    lanplus=1 \
    op monitor interval="60s"

Nota Importante: En entornos de infraestructura Cloud (AWS, Azure) donde no existe hardware físico dedicado, se deben usar agentes de fencing nativos específicos como fence_aws o fence_azure_arm. Nunca deshabilites STONITH (stonith-enabled=false) en un clúster de producción.

Gestión Avanzada de Recursos (Primitives y Constraints)#

Pacemaker define la topología de carga de los servicios a través de Primitives (recursos atómicos), agrupaciones lógicas y Constraints (restricciones de orden y colocación).

Despliegue Acoplado de IP Virtual (VIP) y Apache

Aprovisionaremos un recurso de IP virtual y un servidor web, acoplándolos lógicamente para asegurar que coexistan en el mismo nodo físico y arranquen de forma determinista.

# 1. Definir el recurso primitivo IP Virtual (VIP)
pcs resource create Cluster_VIP ocf:heartbeat:IPaddr2 \
    ip="192.168.1.100" cidr_netmask="24" \
    op monitor interval="30s"

# 2. Definir el recurso del Servidor Web (Apache)
pcs resource create Web_Server ocf:heartbeat:apache \
    configfile="/etc/httpd/conf/httpd.conf" \
    statusurl="http://localhost/server-status" \
    op monitor interval="1min"

# 3. Aplicar Restricciones: Colocation y Order
# Forzar la convivencia: Apache debe correr en el nodo donde resida la VIP
pcs constraint colocation add Web_Server with Cluster_VIP INFINITY

# Forzar el orden topológico: la VIP debe estar levantada antes de lanzar Apache
pcs constraint order Cluster_VIP then Web_Server

Para monitorizar en tiempo real el estado, los quórums y las decisiones del CRM, utilizaremos crm_mon:

# Vista completa de nodos, recursos, fencing operations y errores
crm_mon -Afr -1

Conclusión#

Diseñar un clúster funcional con Corosync y Pacemaker requiere un dominio analítico profundo sobre el comportamiento asíncrono y los límites de los sistemas distribuidos. Al controlar exhaustivamente el quórum, implementar arquitecturas estrictas de fencing y definir las dependencias vía Constraints, los arquitectos de sistemas lograrán garantizar SLAs de 99.99% para cargas monolíticas legacy o servicios stateful críticos.