Clustering con Pacemaker y Corosync: Guía de Alta Disponibilidad Empresarial

Introducción

El clustering de alta disponibilidad es un componente crítico de la infraestructura empresarial, asegurando la entrega continua de servicios incluso cuando los nodos individuales fallan. Pacemaker y Corosync forman la columna vertebral de las soluciones de alta disponibilidad basadas en Linux, proporcionando capacidades robustas de gestión de recursos de cluster y comunicación entre nodos que impulsan aplicaciones de misión crítica en todo el mundo.

Pacemaker es un gestor de recursos de cluster sofisticado que determina qué nodos deben alojar qué servicios y maneja las operaciones de failover automáticamente. Corosync, por otro lado, proporciona la capa de comunicación del cluster utilizando el protocolo Totem, asegurando la entrega confiable de mensajes entre nodos del cluster y detectando fallos de nodos a través de mecanismos de heartbeat.

Juntas, estas tecnologías habilitan configuraciones de redundancia activo-pasivo, activo-activo y N+M que protegen contra fallos de hardware, caídas de software y ventanas de mantenimiento planificado. Las organizaciones que despliegan sistemas financieros, aplicaciones de salud, infraestructura de telecomunicaciones y plataformas de comercio electrónico dependen de clusters Pacemaker/Corosync para mantener acuerdos de nivel de servicio (SLAs) que demandan disponibilidad del 99.99% o superior.

Esta guía exhaustiva explora implementaciones de clusters de nivel empresarial, cubriendo diseño de arquitectura, patrones de configuración avanzados, optimización de rendimiento y estrategias de solución de problemas que los ingenieros de sistemas experimentados necesitan para construir soluciones de alta disponibilidad listas para producción.

Teoría y Conceptos Fundamentales

Fundamentos de Arquitectura de Cluster

Los clusters de alta disponibilidad construidos con Pacemaker y Corosync operan sobre varios principios fundamentales que los distinguen de mecanismos simples de balanceo de carga o redundancia.

Quorum y Prevención de Split-Brain: Los clusters utilizan mecanismos de votación para establecer quorum—el número mínimo de nodos requeridos para operar el cluster. Cuando ocurren particiones de red, solo la partición que contiene quorum puede continuar gestionando recursos, previniendo escenarios de split-brain donde múltiples particiones de cluster intentan gestionar los mismos recursos simultáneamente, llevando a la corrupción de datos.

Jerarquía de Gestión de Recursos: Pacemaker organiza los servicios en recursos con propiedades configurables:

• Recursos Primitivos: Servicios individuales como direcciones IP, sistemas de archivos o aplicaciones
• Grupos: Colecciones de recursos que deben ejecutarse juntos en el mismo nodo
• Clones: Recursos que se ejecutan en múltiples nodos simultáneamente (activo-activo)
• Recursos Master-Slave: Recursos donde una instancia es primaria y otras están en espera

Fencing y STONITH: Los mecanismos "Shoot The Other Node In The Head" apagan o aíslan forzosamente los nodos fallidos para garantizar que los sistemas defectuosos no puedan corromper recursos compartidos. El fencing es obligatorio para clusters de producción que gestionan recursos con estado como bases de datos o almacenamiento compartido.

Arquitectura de Comunicación de Corosync

Corosync implementa el protocolo Totem Single Ring Ordering and Membership, proporcionando:

Orden Total: Todos los mensajes se entregan a todos los nodos en el mismo orden, esencial para un estado de cluster consistente Sincronía Virtual: Grupos de nodos mantienen vistas sincronizadas de la membresía del cluster Protocolo de Anillo Redundante: Soporte para múltiples rutas de red para eliminar puntos únicos de fallo

La capa de comunicación opera usando UDP multicast o unicast, con intervalos de heartbeat configurables (típicamente 1-5 segundos) y tiempos de espera de detección de fallos que equilibran entre failover rápido y detección de falsos positivos.

Motor de Decisión de Pacemaker

El Policy Engine (PE) de Pacemaker evalúa continuamente el estado del cluster contra restricciones y políticas configuradas:

Restricciones de Ubicación: Definen qué nodos pueden o deben alojar recursos específicos Restricciones de Colocación: Especifican recursos que deben ejecutarse juntos o separados Restricciones de Orden: Definen secuencias de inicio/apagado para recursos dependientes Adhesividad de Recursos: Preferencia por mantener recursos en su nodo actual versus migrar

El Cluster Resource Manager (CRM) interpreta estas políticas y orquesta transiciones de recursos, minimizando la interrupción del servicio mientras respeta todas las restricciones configuradas.

Prerrequisitos

Requisitos de Hardware

Las implementaciones de clusters empresariales requieren una planificación cuidadosa del hardware:

Configuración Mínima:

• Al menos 3 nodos (2 para servicios + 1 quorum/desempate)
• Interfaces de red duales por nodo para comunicación redundante
• Infraestructura de almacenamiento compartido (SAN, NAS o sistema de archivos distribuido)
• Interfaces IPMI/iLO/BMC dedicadas para fencing STONITH
• 4 núcleos de CPU mínimo por nodo
• 8GB RAM mínimo por nodo (16GB+ recomendado)

Infraestructura de Red:

• Red de interconexión de cluster dedicada (VLAN aislada)
• Rutas de red redundantes con latencia inferior a 5ms
• Soporte de tramas jumbo (MTU 9000) para redes de almacenamiento
• Switches de red con IGMP snooping para multicast

Consideraciones de Almacenamiento:

• Almacenamiento de bloques compartido para sistemas de archivos en cluster (GFS2, OCFS2)
• Configuración RAID para redundancia de almacenamiento local
• Caché con respaldo de batería para rendimiento de escritura
• Configuración multipath para redundancia de rutas de almacenamiento

Prerrequisitos de Software

Compatibilidad de Sistema Operativo:

• Red Hat Enterprise Linux 8/9 o compatible (Rocky Linux, AlmaLinux)
• Ubuntu 20.04/22.04 LTS
• SUSE Linux Enterprise Server 15
• Debian 11/12

Paquetes Requeridos (RHEL/Rocky):

pacemaker corosync pcs fence-agents-all resource-agents

Paquetes Requeridos (Ubuntu/Debian):

pacemaker corosync crmsh fence-agents resource-agents

Requisitos de Configuración de Red

Todos los nodos requieren:

• Tiempo sincronizado vía NTP/Chrony (crítico para operaciones de cluster)
• Resolución de nombres de host vía /etc/hosts o DNS
• Reglas de firewall que permitan comunicación de cluster
• Políticas SELinux/AppArmor que permitan operaciones de cluster

Configuración Avanzada

Configuración Inicial del Cluster

Paso 1: Sincronización de Tiempo

Configurar chrony en todos los nodos:

# Instalar chrony
dnf install -y chrony

# Configurar fuentes NTP confiables
cat >> /etc/chrony.conf << EOF
server 0.pool.ntp.org iburst
server 1.pool.ntp.org iburst
server 2.pool.ntp.org iburst
EOF

systemctl enable --now chronyd

Paso 2: Configuración de Red y Nombres de Host

Configurar /etc/hosts en todos los nodos:

cat >> /etc/hosts << EOF
192.168.100.11  cluster-node1
192.168.100.12  cluster-node2
192.168.100.13  cluster-node3
EOF

Paso 3: Configuración de Firewall

Abrir puertos requeridos en todos los nodos:

# Comunicación Corosync
firewall-cmd --permanent --add-service=high-availability
firewall-cmd --permanent --add-port=2224/tcp  # pcsd
firewall-cmd --permanent --add-port=3121/tcp  # pacemaker remote
firewall-cmd --permanent --add-port=5403/tcp  # corosync qnetd
firewall-cmd --permanent --add-port=5404-5412/udp  # corosync
firewall-cmd --reload

Paso 4: Instalar y Configurar Software de Cluster

En todos los nodos:

# Instalar paquetes de cluster
dnf install -y pacemaker corosync pcs fence-agents-all

# Habilitar e iniciar daemon pcsd
systemctl enable --now pcsd

# Establecer contraseña de hacluster (igual en todos los nodos)
echo "StrongClusterPassword123!" | passwd --stdin hacluster

Paso 5: Autenticar Nodos del Cluster

En node1:

# Autenticar todos los nodos
pcs host auth cluster-node1 cluster-node2 cluster-node3 \
  -u hacluster -p StrongClusterPassword123!

Paso 6: Crear el Cluster

# Crear cluster con todos los nodos
pcs cluster setup enterprise-cluster \
  cluster-node1 addr=192.168.100.11 \
  cluster-node2 addr=192.168.100.12 \
  cluster-node3 addr=192.168.100.13 \
  transport knet

# Habilitar servicios de cluster en el arranque
pcs cluster enable --all

# Iniciar el cluster
pcs cluster start --all

Configuración Avanzada de Corosync

Editar /etc/corosync/corosync.conf para optimización de producción:

totem {
    version: 2
    cluster_name: enterprise-cluster
    transport: knet

    # Detección agresiva de fallos
    token: 3000
    token_retransmits_before_loss_const: 10
    join: 60
    consensus: 3600

    # Habilitar cifrado
    crypto_cipher: aes256
    crypto_hash: sha256

    interface {
        ringnumber: 0
        bindnetaddr: 192.168.100.0
        broadcast: yes
        mcastport: 5405
    }

    # Anillo redundante para tolerancia a fallos
    interface {
        ringnumber: 1
        bindnetaddr: 192.168.101.0
        broadcast: yes
        mcastport: 5407
    }
}

quorum {
    provider: corosync_votequorum
    expected_votes: 3
    two_node: 0
    wait_for_all: 0
    last_man_standing: 1
    last_man_standing_window: 10000
}

logging {
    to_logfile: yes
    logfile: /var/log/cluster/corosync.log
    to_syslog: yes
    timestamp: on
    logger_subsys {
        subsys: QUORUM
        debug: off
    }
}

nodelist {
    node {
        ring0_addr: cluster-node1
        ring1_addr: cluster-node1-priv
        name: cluster-node1
        nodeid: 1
    }
    node {
        ring0_addr: cluster-node2
        ring1_addr: cluster-node2-priv
        name: cluster-node2
        nodeid: 2
    }
    node {
        ring0_addr: cluster-node3
        ring1_addr: cluster-node3-priv
        name: cluster-node3
        nodeid: 3
    }
}

Recargar configuración:

pcs cluster reload corosync --all

Configuración STONITH/Fencing

Configurar fencing basado en IPMI:

# Crear dispositivo fence para node1
pcs stonith create fence-node1 fence_ipmilan \
  pcmk_host_list="cluster-node1" \
  ipaddr="192.168.200.11" \
  username="admin" \
  password="ipmi_password" \
  lanplus=1 \
  cipher=1 \
  op monitor interval=60s

# Repetir para todos los nodos
pcs stonith create fence-node2 fence_ipmilan \
  pcmk_host_list="cluster-node2" \
  ipaddr="192.168.200.12" \
  username="admin" \
  password="ipmi_password" \
  lanplus=1 \
  cipher=1 \
  op monitor interval=60s

pcs stonith create fence-node3 fence_ipmilan \
  pcmk_host_list="cluster-node3" \
  ipaddr="192.168.200.13" \
  username="admin" \
  password="ipmi_password" \
  lanplus=1 \
  cipher=1 \
  op monitor interval=60s

# Habilitar STONITH globalmente
pcs property set stonith-enabled=true

# Probar fencing
pcs stonith fence cluster-node3

Ejemplos de Configuración de Recursos

Recurso de Dirección IP Virtual:

pcs resource create vip-public ocf:heartbeat:IPaddr2 \
  ip=192.168.100.100 \
  cidr_netmask=24 \
  nic=eth0 \
  op monitor interval=10s

Recurso de Servidor Web Apache:

pcs resource create webserver systemd:httpd \
  op monitor interval=30s \
  op start timeout=60s \
  op stop timeout=60s

# Asegurar que VIP inicie antes de webserver
pcs constraint order vip-public then webserver

# Asegurar que VIP y webserver se ejecuten en el mismo nodo
pcs constraint colocation add webserver with vip-public INFINITY

Recurso de Sistema de Archivos en Cluster:

# Crear recurso de grupo de volumen LVM
pcs resource create vg-cluster ocf:heartbeat:LVM-activate \
  vgname=cluster_vg \
  vg_access_mode=system_id \
  op monitor interval=30s \
  op start timeout=90s

# Crear recurso de sistema de archivos
pcs resource create fs-cluster Filesystem \
  device="/dev/cluster_vg/cluster_lv" \
  directory="/mnt/cluster" \
  fstype="xfs" \
  op monitor interval=20s \
  op start timeout=60s \
  op stop timeout=60s

# Crear grupo de recursos
pcs resource group add cluster-storage vg-cluster fs-cluster

Recurso de Base de Datos PostgreSQL:

pcs resource create postgres-db pgsql \
  pgctl="/usr/pgsql-14/bin/pg_ctl" \
  psql="/usr/pgsql-14/bin/psql" \
  pgdata="/var/lib/pgsql/14/data" \
  pgport="5432" \
  op start timeout=120s \
  op stop timeout=120s \
  op monitor interval=30s timeout=60s

# Agregar al grupo de recursos con almacenamiento y VIP
pcs constraint order cluster-storage then postgres-db
pcs constraint colocation add postgres-db with cluster-storage INFINITY

Optimización de Rendimiento

Ajuste de Corosync para Baja Latencia

Optimizar valores de token timeout basados en características de red:

# Detección rápida de fallos (redes de baja latencia)
pcs property set token=1000
pcs property set token_retransmits_before_loss_const=20

# Configuración de tiempo de ida y vuelta de red
pcs property set token_warning=75%

Adhesividad de Recursos y Umbral de Migración

Prevenir migraciones innecesarias de recursos:

# Adhesividad global de recursos
pcs resource defaults resource-stickiness=100

# Umbral de migración por recurso
pcs resource meta webserver migration-threshold=3
pcs resource meta webserver failure-timeout=300s

Operaciones de Fencing Concurrentes

Habilitar fencing paralelo para recuperación más rápida:

pcs property set concurrent-fencing=true
pcs property set stonith-max-attempts=5
pcs property set stonith-action=reboot

Optimización de Transición de Cluster

Reducir sobrecarga de recálculo del cluster:

pcs property set cluster-recheck-interval=2min
pcs property set dc-deadtime=20s
pcs property set election-timeout=2min

Ajuste de Operaciones de Recursos

Optimizar intervalos de verificación de recursos:

# Monitoreo menos frecuente para recursos estables
pcs resource op remove webserver monitor
pcs resource op add webserver monitor interval=60s timeout=30s

# Monitoreo agresivo para recursos críticos
pcs resource op remove postgres-db monitor
pcs resource op add postgres-db monitor interval=15s timeout=45s on-fail=restart

Patrones de Alta Disponibilidad

Configuración Activo-Pasivo

Cluster de failover estándar con servicios ejecutándose en un nodo:

# Deshabilitar clonación de recursos
pcs resource create app-service systemd:myapp \
  op monitor interval=30s

# Establecer nodo preferido
pcs constraint location app-service prefers cluster-node1=100
pcs constraint location app-service prefers cluster-node2=50

Activo-Activo con Recursos Clonados

Servicios ejecutándose simultáneamente en todos los nodos:

# Crear recurso clonado
pcs resource create app-clone systemd:myapp \
  clone notify=true globally-unique=false

# Establecer máximo de clones
pcs resource clone app-service clone-max=3 clone-node-max=1

Configuración Master-Slave (Clone Promocionable)

Replicación de base de datos con promoción automática:

# Replicación por streaming de PostgreSQL
pcs resource create postgres-ha pgsqlms \
  bindir="/usr/pgsql-14/bin" \
  pgdata="/var/lib/pgsql/14/data" \
  op start timeout=60s \
  op stop timeout=60s \
  op promote timeout=30s \
  op demote timeout=120s \
  op monitor interval=15s role="Master" \
  op monitor interval=30s role="Slave" \
  promotable notify=true

# La IP virtual sigue al master
pcs constraint colocation add vip-db with master postgres-ha-clone INFINITY
pcs constraint order promote postgres-ha-clone then start vip-db

Monitoreo y Observabilidad

Monitoreo de Estado del Cluster

Estado del cluster en tiempo real:

# Estado completo del cluster
pcs status --full

# Estado específico de recursos
pcs resource show --full

# Estado de nodos
pcs node attribute

Script de monitoreo para automatización:

#!/bin/bash
# /usr/local/bin/cluster-health-check.sh

OUTPUT_FILE="/var/log/cluster/health-$(date +%Y%m%d-%H%M%S).log"

{
    echo "=== Verificación de Salud del Cluster: $(date) ==="

    # Estado del cluster
    echo -e "\n--- Estado del Cluster ---"
    pcs status

    # Estado de quorum
    echo -e "\n--- Estado de Quorum ---"
    corosync-quorumtool

    # Restricciones de recursos
    echo -e "\n--- Restricciones de Recursos ---"
    pcs constraint --full

    # Acciones fallidas
    echo -e "\n--- Acciones Fallidas ---"
    pcs status --full | grep -A5 "Failed Actions" || echo "Ninguna"

    # Estado STONITH
    echo -e "\n--- Dispositivos STONITH ---"
    pcs stonith status

} > "$OUTPUT_FILE"

# Alertar sobre problemas
if pcs status 2>&1 | grep -q "Failed\|Error\|Unclean"; then
    mail -s "Alerta de Salud del Cluster" [email protected] < "$OUTPUT_FILE"
fi

Integración con Prometheus

Exportar métricas del cluster para monitoreo:

# Instalar ha_cluster_exporter
wget https://github.com/ClusterLabs/ha_cluster_exporter/releases/download/1.3.0/ha_cluster_exporter-amd64.tar.gz
tar -xvf ha_cluster_exporter-amd64.tar.gz -C /usr/local/bin/

# Crear servicio systemd
cat > /etc/systemd/system/ha_cluster_exporter.service << EOF
[Unit]
Description=HA Cluster Exporter
After=network.target

[Service]
Type=simple
User=hacluster
ExecStart=/usr/local/bin/ha_cluster_exporter
Restart=on-failure

[Install]
WantedBy=multi-user.target
EOF

systemctl enable --now ha_cluster_exporter

Análisis de Logs y Alertas

Centralizar logging del cluster:

# Configurar reenvío de rsyslog
cat >> /etc/rsyslog.d/cluster.conf << EOF
if \$programname == 'pacemaker' or \$programname == 'corosync' then @@log-server:514
EOF

systemctl restart rsyslog

Solución de Problemas

Escenarios de Pérdida de Quorum

Síntoma: El cluster deja de gestionar recursos debido a pérdida de quorum.

Diagnóstico:

# Verificar estado de quorum
corosync-quorumtool

# Ver configuración de votación
pcs quorum status

Resolución:

# Habilitar temporalmente anulación de quorum (¡peligroso!)
pcs quorum unblock

# Restaurar operaciones normales una vez que los nodos se reúnan
pcs cluster start cluster-node2

Detección y Recuperación de Split-Brain

Síntoma: Múltiples nodos creen que son coordinador del cluster.

Diagnóstico:

# Verificar elección de DC
crm_mon -1 | grep "Current DC"

# Verificar historial STONITH
stonith_admin --history=*

Resolución:

# Fencing manual de nodos ambiguos
pcs stonith fence cluster-node2

# Verificar integridad del cluster
pcs status --full

Fallos y Reinicio de Recursos

Síntoma: Recursos fallando y reiniciando repetidamente.

Diagnóstico:

# Ver historial de fallos
pcs status --full | grep -A10 "Failed"

# Verificar configuración de recursos
pcs resource config webserver

Resolución:

# Limpiar fallos de recursos
pcs resource cleanup webserver

# Aumentar umbral de fallos
pcs resource meta webserver migration-threshold=5 failure-timeout=600s

# Operaciones manuales de recursos
pcs resource debug-start webserver

Problemas de Comunicación de Corosync

Síntoma: Nodos uniéndose/dejando el cluster de forma errática.

Diagnóstico:

# Verificar estado del anillo de corosync
corosync-cfgtool -s

# Monitorear cambios de membresía
corosync-cmapctl | grep members

Resolución:

# Verificar conectividad de red
ping -c 5 cluster-node2
mtr cluster-node2

# Verificar pérdida de paquetes
corosync-cfgtool -s | grep "failed"

# Ajustar token timeout para redes con pérdidas
pcs property set token=5000

Fallos de STONITH

Síntoma: Operaciones de fencing agotando tiempo de espera o fallando.

Diagnóstico:

# Probar dispositivo fence
stonith_admin --fence cluster-node3 --test

# Ver configuración de dispositivo fence
pcs stonith show fence-node3

Resolución:

# Verificar conectividad IPMI
ipmitool -I lanplus -H 192.168.200.13 -U admin -P password power status

# Actualizar timeout de dispositivo fence
pcs stonith update fence-node3 pcmk_reboot_timeout=90s

# Configurar retrasos de fence para prevenir fencing simultáneo
pcs stonith update fence-node1 pcmk_delay_max=30s

Degradación de Rendimiento

Síntoma: Transiciones lentas de recursos y alto uso de CPU.

Diagnóstico:

# Analizar rendimiento de Pacemaker
crm_verify -L -V

# Verificar bucles de restricciones
pcs constraint show --full

Resolución:

# Simplificar configuración de restricciones
pcs constraint remove complex-constraint-id

# Optimizar cálculo de transición
pcs property set stop-orphan-resources=false
pcs property set stop-orphan-actions=false

Conclusión

Pacemaker y Corosync proporcionan capacidades de clustering de alta disponibilidad de nivel empresarial esenciales para infraestructura moderna que demanda entrega continua de servicios. Esta guía ha explorado patrones de configuración avanzados, técnicas de optimización de rendimiento y metodologías de solución de problemas que los ingenieros de sistemas necesitan para construir y mantener entornos de cluster listos para producción.

Las implementaciones exitosas de clusters requieren planificación cuidadosa de la topología de hardware, arquitectura de red y dependencias de recursos. El fencing STONITH permanece como no negociable para recursos con estado, asegurando la integridad de datos durante escenarios de fallo. El ajuste de rendimiento debe equilibrar la detección rápida de fallos contra los riesgos de falsos positivos introducidos por latencia de red y congestión.

Las organizaciones deben implementar monitoreo exhaustivo utilizando herramientas como Prometheus y logging centralizado para mantener visibilidad en la salud del cluster. Las pruebas regulares de escenarios de failover, operaciones de fence y procedimientos de recuperación ante desastres aseguran preparación cuando ocurren fallos reales. A medida que las aplicaciones crecen cada vez más complejas, dominar el clustering Pacemaker/Corosync se vuelve esencial para entregar la confiabilidad que las empresas modernas demandan.

Los temas avanzados como clusters geo-redundantes, integración con redes definidas por software y clustering de plataformas de orquestación de contenedores representan extensiones naturales de estos conceptos fundamentales, posicionando a ingenieros capacitados para arquitecturar soluciones altamente disponibles a escala.