Quien quiera operar realmente servicios productivos con alta disponibilidad, en Linux suele optar por Alta disponibilidad con Pacemaker/Corosync. Pacemaker es el gestor de recursos; Corosync proporciona mensajería, membresía e información de quórum. Esta guía complementa los fundamentos con aspectos operativos más profundos: configuraciones concretas de STONITH, uso de SBD, ajuste de Corosync, integración con monitoring, pasos de comprobación para pruebas de fencing y estrategias de rollback — todo con foco en operación, integridad de datos y migraciones seguras de soluciones de software cercanas al proceso.
Riesgos avanzados: cuándo el Split‑Brain es especialmente probable
El Split‑Brain se produce cuando dos particiones del clúster activan recursos de forma independiente. Están especialmente en riesgo los entornos con Single‑Writer‑Storage (p. ej. LVM/LUNs clásicas sin sistema de archivos en clúster), redes de clúster inestables o fencing ausente/defectuoso. Las desconexiones de red concurrentes con un timeout del almacenamiento son un escenario clásico: una partición pierde la comunicación de Corosync, la otra sigue viendo el LUN accesible — ambas pueden pasar a ser primarias.
SBD (STONITH Block Device): cuándo tiene sentido y cómo empezar
SBD es un mecanismo de fencing que utiliza un dispositivo de bloque dedicado como token. La idea: solo el nodo que pueda sostener el token puede realizar escrituras. SBD resulta especialmente práctico cuando existe un SAN externo o se puede provisionar para el clúster un pequeño dispositivo de bloque de acceso rápido (p. ej. un LUN iSCSI).
SBD‑Konfiguration: Beispiel /etc/sbd.conf
# Minimalbeispiel /etc/sbd.conf
SBD_DEVICE=/dev/sdb
SBD_WATCHDOG=yes
SBD_PACEMAKER=yes
SBD_TIMEOUT=120
SBD_STARTMODE=dual
SBD_OPTS="-p 30"
Explicación: SBD_DEVICE es el dispositivo compartido; WATCHDOG usa un watchdog de hardware; PACEMAKER permite la integración con Pacemaker; TIMEOUT es el tiempo de espera hasta el fencing. Startmode=dual permite dos nodos que usen SBD. Siempre pruebe los cambios fuera del horario de producción.
SBD installieren und starten (Debian/Ubuntu, RHEL-Varianten ähnlich)
# Debian/Ubuntu
apt-get update && apt-get install -y sbd
# RHEL/CentOS
yum install -y sbd
# Starten und prüfen
systemctl enable --now sbd
journalctl -u sbd --no-pager --since "-5m"
Importante: SBD necesita un dispositivo compartido fiable. Si el dispositivo desaparece de forma intermitente, SBD provoca fencing erróneo. Verifique la persistencia de la ruta del dispositivo y la ruta de failover antes del inicio en producción.
STONITH vía BMC: ejemplos de IPMI / Redfish y riesgos habituales
El power‑fencing a través del BMC está muy extendido, porque permite un reinicio hardware real. No obstante, los BMC suelen requerir configuración independiente y plantean riesgos de seguridad propios (contraseñas por defecto, redes de gestión no cifradas).
Beispiel: STONITH mit fence_ipmilan über pcs
# Beispiel: Gerät für „node1“ anlegen (Platzhalter verwenden!)
pcs stonith create fence-node1 fence_ipmilan
ipaddr=192.0.2.120 login=ADMIN passwd='SECRET'
pcmk_host_list=node1 op monitor interval=60s
# Prüfen
pcs stonith show
Nota: use credenciales seguras, restrinja el acceso a la red de gestión y aplique controles de acceso en el BMC. Pruebe el ciclo de alimentación siempre de forma controlada y documentada.
Redfish: moderneres API
# Beispiel: fence_redfish mit Token (Platzhalter)
pcs stonith create fence-node1-redfish fence_redfish
ip=192.0.2.121 user=admin password='SECRET'
pcmk_host_list=node1 op monitor interval=60s
Redfish ofrece APIs claras y mejores posibilidades de auditoría. Aun así se mantiene la regla básica: acceso al BMC solo a través de una red de gestión dedicada, cambiar las credenciales y establecer límites de acceso.
Ajuste de Corosync: parámetros que aportan estabilidad
Corosync se comunica a través de un anillo; las demoras o pérdidas de paquetes provocan cambios de membresía repetidos. Tres parámetros útiles:
- token: tiempo que un nodo espera como máximo su turno. Un token mayor reduce la sensibilidad a split‑brain por latencia, pero aumenta la latencia de failover.
- consensus: número de mensajes necesarios para cambios de membresía; incrementa la seguridad frente a pérdidas de paquetes transitorias.
- join‑timeout / rrp_mode (en configuraciones con múltiples anillos): velocidad con la que se esperan las reconexiones.
Los cambios requieren pruebas en la red de pruebas. Aumentos leves del token suelen ser preferibles a timeouts agresivos de recursos.
Pacemaker Resource‑Meta y manejo de fallos
Pacemaker ofrece atributos meta como migration‑threshold, failure‑timeout o resource‑stickiness. Estos determinan con qué frecuencia y con qué rapidez se migra un recurso tras fallos o se reintenta.
# Beispiel: Metaparameter setzen
pcs resource meta grp_app migration-threshold=3 failure-timeout=10m
resource-stickiness=100
Recomendación: resource‑stickiness evita movimientos innecesarios de ida y vuelta. migration‑threshold limita el número de intentos automáticos de migración; failure‑timeout define la ventana temporal para las contabilizaciones.
Monitorización y alertas: End‑to‑End en lugar de solo el estado del clúster
Las métricas del clúster por sí solas no son suficientes. Complete los exporters de Prometheus (p. ej. crm_exporter o native pacemaker exporter) con probes End‑to‑End que verifiquen la funcionalidad del servicio (HTTP‑healthchecks, escritura/lectura en BD). Las alertas deben proporcionar indicaciones claras: errores de fencing, failovers repetidos, recuperaciones de larga duración.
Pruebas de fencing: seguras, reproducibles y auditables
Una prueba de fencing debe cumplir los siguientes criterios: ser controlable, reproducible y documentada. Procedimiento:
- Poner el modo de mantenimiento (en entornos de prueba también puede prescindirse de él, pero con autorización clara)
- Copia de seguridad: pcs config export y guardar los logs
- Fallo simulado de nodo (p. ej. desconexión de red) y observación de si se activa el fencing
- Verificación: ¿está realmente offline la LUN/FS? ¿Se ejecutaron comandos Power‑Off/Reset en el BMC?
- Documentación de todos los pasos y marcas temporales
# Beispiel: Logs prüfen (Pacemaker, Corosync, SBD)
journalctl -u pacemaker -u corosync -u sbd --since "-30m" --no-pager
# Corosync Quorum Status
corosync-quorumtool -s
Evite las pruebas durante las horas punta. Si el fencing falla, un apagado forzado (Power‑Off) puede terminar bruscamente una VM productiva o dejar inaccesible una ruta de almacenamiento.
Estrategia de actualización y migración para clústeres existentes
Las actualizaciones de clúster son arriesgadas, ya que cambios en el messaging‑stack o en los Resource‑Agents pueden alterar el comportamiento. Pasos recomendados:
- Plan de rollback y copia de seguridad de la configuración antes de cada paso
- Rolling upgrade, siempre que lo soporte el distribuidor: actualizar los nodos uno a uno, verificar la funcionalidad del clúster
- Replicar el entorno de pruebas: misma configuración de almacenamiento y condiciones de red comparables
- Tras la actualización: periodo de observación más largo y mayor sensibilidad de la monitorización
Lista de verificación operativa: antes de un Go‑Live en producción
- Documentación: diagrama de arquitectura con Failure Domains, métodos de fencing y ventanas de mantenimiento
- Comprobaciones de extremo a extremo: VIPs, NS/ARPs, Service‑Bind, DB‑Writes
- Prueba de fencing: reproducida y documentada con éxito al menos una vez
- Monitorización: alertas para fencing, fallos repetidos, altos recuentos de fallos
- Backups: snapshot de configuración y runbook de recuperación disponibles
Ejemplos prácticos: obstáculos típicos y contramedidas
Trampa común: BMCs están en el mismo VLAN de gestión que los clientes productivos
Problema: si la red de producción falla, el BMC tampoco es accesible y el fencing falla. Contramedida: mover los BMCs a una red de gestión separada o prever accesos Out‑of‑Band redundantes.
Trampa común: intervalos de monitorización incorrectos
Problema: monitores demasiado agresivos en períodos de alta latencia de E/S provocan flapping. Contramedida: adaptar los intervalos de monitorización a las condiciones reales de E/S, aumentar el resource‑stickiness.
Conclusión: infraestructura disciplinada en lugar de magia de configuración
High‑Availability con Pacemaker/Corosync funciona de forma fiable cuando la arquitectura, el fencing y el quorum se diseñan como un sistema integrado. STONITH no es un „nice to have“, sino imprescindible en Single‑Writer‑Setups y con DRBD. SBD ofrece una alternativa robusta cuando hay disponible un dispositivo de bloque compartido, mientras que el BMC‑fencing proporciona aislamiento real de la alimentación. Lo decisivo es: probar, documentar, integrar la monitorización y tener planes de rollback preparados. Así se evita el split‑brain y la operación se hace planificable.
Recursos avanzados: comandos útiles de verificación
# Verificaciones rápidas en operación
pcs status --full
pcs stonith show
corosync-cfgtool -s
corosync-quorumtool -s
# Consolidar logs
journalctl -u pacemaker -u corosync -u sbd --since "-2h" --no-pager
Preguntas frecuentes
- ¿STONITH es siempre necesario? En setups de almacenamiento compartido sin Multi‑Writer‑Cluster‑FS y con DRBD, STONITH es obligatorio. En almacenamientos completamente distribuidos con consistencia incorporada puede prescindirse en algunas arquitecturas, pero la decisión exige una comprensión precisa de la semántica del almacenamiento.
- ¿Cómo pruebo SBD sin arriesgar datos de producción? Utilice una LUN de prueba con la misma estructura de rutas, simule fallos de nodo y compruebe si la transferencia de tokens y el fencing funcionan como se espera. Documente las diferencias con respecto al entorno de producción.
- ¿Qué ocurre si el fencing falla? Modo de mantenimiento inmediato, analizar la accesibilidad de BMC/Storage y ejecutar el plan de recuperación. En situaciones críticas, la operación controlada de nodo único suele ser más segura que acciones automáticas inseguras.
Alta disponibilidad con Pacemaker/Corosync: qdevice, restricciones de recursos y runbook de recuperación
Como complemento a STONITH y SBD conviene revisar tres áreas operativas que a menudo se pasan por alto pero que influyen de forma decisiva en la estabilidad: el uso de un Quorum‑Witness externo (qdevice/qnetd), restricciones de recursos limpias (Order/Colocation) y un runbook de recuperación pragmático para casos reales de split‑brain. Estos aspectos afectan a la arquitectura, la automatización y la recuperación segura al estado normal – relevantes para el funcionamiento de soluciones de software orientadas a procesos con almacenamiento compartido o VIP‑Failover.
qdevice (Quorum Witness) vs. SBD: ¿Cuándo usar cada patrón?
qdevice (también llamado qnetd) proporciona un pequeño servicio de testigo externo que aporta votos en situaciones de quórum ajustado. Ventaja: no requiere dispositivos de bloque compartidos, bajo overhead y sencillo en entornos Cloud/VM. Desventaja: el testigo debe ser alcanzable y tener buen rendimiento; en particiones de red solo aporta ventaja si permanece claramente accesible.
SBD es basado en hardware o storage y protege a nivel de dispositivo de bloque. Elija qdevice si no puede proporcionar LUNs compartidas o si está en entornos virtualizados con una pequeña VM testigo externa. Elija SBD para entornos físicos con una ruta SAN fiable y cuando necesite garantía de fencing basada en tokens.
Notas prácticas para el funcionamiento de qdevice
- Ubicación del testigo: preferiblemente en una tercera ubicación o en un segmento de red separado, para que en una división de dos nodos no distorsione la decisión.
- Resiliencia: opere qdevice en HA (es posible usar dos instancias de testigo preparadas con IP flotante) o utilice un testigo alojado en la nube si las conexiones de red son estables.
- Monitorización: registre la liveness y el RTT hacia el testigo; latencias variables pueden causar membership‑flapping.
Restricciones de recursos: modelar correctamente orden y colocación
Muchos problemas de failover surgen porque los servicios se inician en el orden incorrecto o se colocan en nodos distintos. Use conscientemente las Order‑ y Colocation‑Constraints para forzar dependencias:
# Beispiel: sicherstellen, dass das Filesystem zuerst startet, dann die Applikation
pcs constraint order start fs_resource then app_resource
# Beispiel: Applikation muss auf dem selben Knoten wie das gemountete Filesystem laufen
pcs constraint colocation add app_resource with fs_resource INFINITY
Explicación: la Order‑Constraint evita problemas de temporización (p. ej. la App arranca antes de que el FS esté disponible). La Colocation‑Constraint evita que la aplicación se ejecute en un nodo que no tenga acceso al storage.
Multipath y persistencia de dispositivos
Las dependencias de dispositivos de bloque compartidos requieren nombres de dispositivo estables. Utilice WWIDs persistentes, configure multipathd de forma adecuada y asegure las reglas de udev. Si cambios de ruta o eventos de timeout hacen que el LUN sea momentáneamente invisible, el clúster puede interpretar rápidamente esto como un fallo de nodo, con posible fencing erróneo.
Runbook de recuperación: pasos seguros en caso de sospecha de split‑brain
Un runbook claro y probado evita acciones precipitadas. Secuencia de ejemplo antes de actuar:
- Informe a las partes interesadas y establezca una ventana de mantenimiento. Active, si procede, un nivel de alarma global para evitar que scripts automáticos actúen adicionalmente.
- Asegure la configuración y los logs:
pcs config export > /root/pcs-config-$(date +%F).xmly recopile las salidas de journalctl. - Aisle nodos: detenga Pacemaker en al menos un nodo si desea comprobar la integridad de un soporte de datos (
systemctl stop pacemaker). - Identifique el conjunto de datos con la mayor autoridad (p. ej. qué réplica tuvo los últimos permisos de escritura; en DRBD: Primary). Documente sellos temporales y métricas de E/S.
- Si hay un nodo autoritativo claro: replique los datos (según la técnica de almacenamiento), deje el otro nodo en un estado limpio y reincorpórelo de forma controlada.
- Tras la restauración: fase de monitorización prolongada, alarmas elevadas y verificación manual de las comprobaciones end‑to‑end (VIP, DB‑Writes, logs de la aplicación).
Importante: Evite el ‚force-join‘ automático sin una comprobación de la consistencia de los datos. Documente cada paso para permitir posibles análisis forenses.
Automatización, control de configuración y estrategia de pruebas
Mantenga las configuraciones de clúster versionadas (Git) y automatizadas mediante playbooks verificados. Pruebe los escenarios de fencing y quorum de forma automatizada en laboratorios tipo CI/CD (p. ej., staging basado en Vagrant/VM). Solo los playbooks verificados y reproducibles pueden ejecutar cambios en Pacemaker/Corosync en producción.
Estas medidas ayudan a reducir los riesgos de arquitectura y operación: un witness adecuado, restricciones claras y un runbook de recuperación probado marcan la diferencia entre failovers ocasionales y una operación planificable y apta para auditoría.
Para este tema también son importantes los clústeres Pacemaker y el Stonith Fencing. El artículo contextualiza estos aspectos de forma comprensible y muestra en qué hay que fijarse en el día a día.