Haute disponibilité avec Pacemaker/Corosync : groupes de ressources, STONITH et prévention du split-brain

Qui souhaite exploiter des services productifs en haute disponibilité sous Linux opte souvent pour Haute disponibilité avec Pacemaker/Corosync. Pacemaker est le gestionnaire de ressources, Corosync fournit le messaging, les informations de membership et de quorum. Ce guide complète les bases par des aspects opérationnels approfondis : configurations STONITH concrètes, utilisation de SBD, tuning de Corosync, intégration au monitoring, étapes de vérification pour les tests de fencing ainsi que stratégies de rollback — le tout avec un focus sur l’exploitation, l’intégrité des données et les migrations sûres de solutions logicielles proches du processus.

Risques avancés : quand un split‑brain est particulièrement probable

Le split‑brain survient lorsque deux partitions du cluster activent indépendamment des ressources. Sont particulièrement vulnérables les configurations avec Single‑Writer‑Storage (par ex. LVM/LUN classiques sans système de fichiers cluster), un réseau de cluster instable ou l’absence/défaillance du fencing. Les coupures réseau simultanées à des timeouts du stockage constituent un scénario classique : une partition perd la communication Corosync, l’autre voit toujours le LUN comme accessible — les deux peuvent devenir Primary.

SBD (STONITH Block Device) : quand cela a du sens et comment démarrer

SBD est un mécanisme de fencing qui utilise un blockdevice dédié comme token. L’idée : seul le nœud qui peut détenir le token est autorisé à effectuer des écritures. SBD est particulièrement pratique lorsqu’un SAN externe est disponible ou qu’un petit blockdevice rapidement accessible (par ex. un LUN iSCSI) peut être fourni au cluster.

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"

Explication : SBD_DEVICE est le device partagé ; SBD_WATCHDOG utilise un watchdog matériel, SBD_PACEMAKER permet l’intégration avec Pacemaker ; SBD_TIMEOUT est le délai avant le fencing. Startmode=dual autorise deux nœuds à utiliser SBD. Testez les modifications en dehors des heures de production.

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"

Important : SBD requiert un device partagé fiable. Si le device disparaît de façon intermittente, SBD provoque des faux fenceings. Testez la persistance du chemin du device et le chemin de basculement avant la mise en production.

STONITH via BMC : IPMI / Redfish exemples et écueils

Le power‑fencing via BMC est courant car il permet un reset matériel réel. Cependant, les BMC sont souvent configurés séparément et présentent des risques de sécurité propres (mots de passe par défaut, réseaux de gestion non chiffrés).

Exemple : STONITH avec fence_ipmilan via 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

Remarque : utilisez des identifiants sûrs, des restrictions d’accès pour le réseau de gestion et des accès basés sur les rôles dans le BMC. Testez le power‑cycle toujours de manière contrôlée et documentée.

Redfish : API plus moderne

# 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 offre des API claires et de meilleures possibilités d’audit. Néanmoins, règle de base : accès BMC uniquement via un réseau de management dédié, changement des identifiants et définition de limites d’accès.

Corosync‑Tuning: Parameter, die Stabilität bringen

Corosync communique via un anneau ; les retards ou pertes de paquets entraînent des changements répétés de membership. Trois réglages pertinents :

• token : durée maximale pendant laquelle un nœud attend son tour. Un token plus élevé réduit la sensibilité au split‑brain en présence de latence, mais augmente la latence de basculement.
• consensus : nombre de messages requis pour les changements de membership ; augmente la résistance aux pertes de paquets transitoires.
• join‑timeout / rrp_mode (pour plusieurs anneaux) : délai attendu pour les nouvelles connexions.

Les modifications nécessitent des tests en environnement de test. De petites augmentations du token sont souvent préférables à des timeouts de ressources agressifs.

Pacemaker Resource‑Meta und Failure‑Handling

Pacemaker propose des attributs meta tels que migration‑threshold, failure‑timeout ou resource‑stickiness. Ceux‑ci déterminent à quelle fréquence et à quelle vitesse une ressource est migrée ou retentée après des erreurs.

# Beispiel: Metaparameter setzen
pcs resource meta grp_app migration-threshold=3 failure-timeout=10m 
  resource-stickiness=100

Recommandation : resource‑stickiness empêche des mouvements aller‑retour inutiles. migration‑threshold limite le nombre de tentatives de migration automatiques, failure‑timeout définit la fenêtre temporelle pour les comptages.

Monitoring und Alerting: End‑to‑End statt nur Clusterstatus

Les métriques du cluster seules ne suffisent pas. Complétez les Prometheus‑Exporter (p. ex. crm_exporter ou native pacemaker exporter) par des probes de bout en bout vérifiant la fonctionnalité des services (checks de santé HTTP, écriture/lecture DB). Les alertes doivent fournir des indications claires : erreurs de fencing, basculements répétés, récupérations de longue durée.

Fencing‑Tests: Sicher, reproduzierbar und auditorisch

Un test de fencing doit satisfaire aux critères suivants : contrôlable, reproductible et documenté. Procédure :

1. Activer le mode maintenance (dans les environnements de test, éventuellement sans, mais uniquement avec autorisation explicite)
2. Sauvegarde : pcs config export et sauvegarde des logs
3. Simulation de panne de nœud (p. ex. déconnexion réseau) et observation pour vérifier si le fencing s’enclenche
4. Vérification : le LUN/FS est‑il vraiment hors ligne ? Des commandes Power‑Off/Reset ont‑elles été exécutées sur le BMC ?
5. Documentation de toutes les étapes et des horodatages

# Beispiel: Logs prüfen (Pacemaker, Corosync, SBD)
journalctl -u pacemaker -u corosync -u sbd --since "-30m" --no-pager
# Corosync Quorum Status
corosync-quorumtool -s

Évitez les tests pendant les heures de production. Si le fencing échoue, un Power‑Off peut arrêter brutalement une VM productive ou rendre un chemin de stockage inaccessible.

Upgrade- und Migrationsstrategie für bestehende Cluster

Les mises à niveau de cluster sont risquées, car des modifications du messaging‑stack ou des resource agents peuvent altérer le comportement. Étapes recommandées :

• Plan de rollback et sauvegarde de configuration avant chaque étape
• Rolling upgrade, si supporté par le distributeur : mettre à niveau les nœuds un par un, vérifier le fonctionnement du cluster
• Reproduire un environnement de test : même configuration de stockage et conditions réseau comparables
• Après la mise à niveau : période d’observation prolongée, sensibilité du monitoring accrue

Betriebscheckliste: Vor einem produktiven Go‑Live

• Documentation : diagramme d’architecture avec domaines de défaillance, méthodes de fencing et fenêtres de maintenance
• Contrôles de bout en bout : VIPs, NS/ARPs, Service‑Bind, DB‑Writes
• Test de fencing : reproduit et documenté avec succès au moins une fois
• Monitoring : alertes pour fencing, échecs répétés, nombre élevé d’échecs
• Sauvegardes : snapshot de configuration et runbook de récupération disponibles

Exemples pratiques : pièges typiques et mesures correctives

Piège : les BMCs se trouvent dans le même VLAN de gestion que les clients en production

Problème : si le réseau de production tombe, le BMC n’est plus joignable et le fencing échoue. Mesure corrective : déplacer les BMCs sur un réseau de gestion séparé ou prévoir des accès Out‑of‑Band redondants.

Piège : intervalles de surveillance incorrects

Problème : des moniteurs trop agressifs en période de latence IO élevée provoquent du flapping. Mesure corrective : adapter les intervalles de surveillance aux conditions réelles d’E/S et augmenter la resource‑stickiness.

Conclusion : infrastructure disciplinée plutôt que magie de configuration

La haute disponibilité avec Pacemaker/Corosync fonctionne de manière fiable lorsque l’architecture, le fencing et le quorum sont conçus comme un système intégré. STONITH n’est pas un « nice to have », mais indispensable pour les Single‑Writer‑Setups et DRBD. SBD offre une alternative robuste si un périphérique de bloc partagé est disponible, tandis que le BMC‑Fencing fournit une véritable isolation d’alimentation. L’essentiel : tester, documenter, intégrer le monitoring et prévoir des plans de rollback. Ainsi, le split‑brain devient évitable et l’exploitation prévisible.

Ressources avancées : commandes de vérification utiles

# Quick‑Checks im Betrieb
pcs status --full
pcs stonith show
corosync-cfgtool -s
corosync-quorumtool -s
# Logs zusammenführen
journalctl -u pacemaker -u corosync -u sbd --since "-2h" --no-pager

FAQ

• Le STONITH est‑il toujours nécessaire ? Pour les configurations avec stockage partagé sans système de fichiers de cluster multi‑writer et pour DRBD, le STONITH est impératif. Dans des stockages totalement distribués avec cohérence intégrée, il peut être dispensable dans certaines architectures, mais la décision exige une compréhension précise de la sémantique du stockage.
• Comment tester SBD sans mettre en risque les données de production ? Utilisez une LUN de test avec une structure de chemin identique, simulez des pannes de nœuds et vérifiez si le transfert de jeton et le fencing fonctionnent comme attendu. Documentez les différences par rapport à l’environnement de production.
• Que faire si le fencing échoue ? Passer immédiatement en mode maintenance, analyser l’accessibilité des BMC/du stockage et exécuter le plan de recovery. Dans les situations critiques, l’exploitation contrôlée sur un nœud unique est souvent plus sûre que des actions automatiques incertaines.

Haute disponibilité avec Pacemaker/Corosync : qdevice, contraintes de ressources et runbook de récupération

En complément de STONITH et SBD, il vaut la peine de regarder trois domaines opérationnels souvent négligés mais qui influent fortement sur la stabilité : l’utilisation d’un quorum‑witness externe (qdevice/qnetd), des contraintes de ressources propres (Order/Colocation) et un runbook de récupération pragmatique pour de vrais cas de split‑brain. Ces aspects concernent l’architecture, l’automatisation et le retour sécurisé en production – pertinents pour l’exploitation de solutions logicielles proches des processus avec stockage partagé ou VIP‑Failover.

qdevice (Quorum Witness) vs. SBD : quand utiliser quel pattern ?

qdevice (également appelé qnetd) propose un petit service de témoin externe qui fournit des voix lors de situations de quorum serré. Avantage : aucun périphérique de bloc partagé requis, faible overhead, plus simple dans des environnements Cloud/VM. Inconvénient : le témoin doit être joignable et performant ; en cas de partition réseau il n’apporte un avantage que s’il reste clairement accessible.

SBD est basé sur le hardware ou le stockage et protège au niveau des périphériques de bloc. Choisissez qdevice si vous ne pouvez pas fournir de LUNs partagées ou dans des environnements virtualisés avec une petite VM témoin externe. Choisissez SBD pour des environnements physiques avec un chemin SAN fiable et si vous avez besoin d’une garantie de fencing basée sur des jetons.

Conseils pratiques pour l’exploitation de qdevice

• Emplacement du témoin : de préférence dans un troisième site ou un segment réseau séparé, afin qu’il ne fausse pas la décision lors d’un split à deux nœuds.
• Résilience : exploitez qdevice en HA (deux instances témoin prêtes avec Floating‑IP sont possibles) ou utilisez un témoin hébergé dans le cloud si les connexions réseau sont stables.
• Supervision : mesurez la liveness et le RTT vers le témoin ; des latences fluctuantes peuvent causer du membership‑flapping.

Contraintes de ressources: modéliser correctement l’ordre et la colocation

Beaucoup de problèmes de basculement surviennent parce que les services sont démarrés dans le mauvais ordre ou placés sur des nœuds différents. Utilisez délibérément des contraintes d’ordre et de colocation (Order‑ et Colocation‑Constraints) pour imposer les dépendances :

# 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

Explication : la contrainte d’ordre empêche les problèmes de synchronisation (p. ex. l’application démarre avant que le FS ne soit prêt). La contrainte de colocation empêche que l’application s’exécute sur un nœud qui n’a pas accès au stockage.

Multipath et persistance des périphériques

Les dépendances à des périphériques de bloc partagés nécessitent des noms de périphériques stables. Utilisez des WWID persistants, configurez multipathd de manière appropriée et protégez les règles udev. Si des changements de chemin ou des événements de timeout rendent la LUN temporairement invisible, le cluster interprète rapidement cela comme une défaillance de nœud — avec un possible fencing erroné.

Runbook de récupération: étapes sûres en cas de suspicion de split‑brain

Un runbook clair et testé évite les actions hâtives. Exemple de procédure avant d’agir :

1. Informez les parties prenantes et ouvrez une fenêtre de maintenance. Activez le cas échéant un niveau d’alerte global, afin que les scripts automatiques n’interviennent pas en outre.
2. Sauvegardez la configuration et les logs: pcs config export > /root/pcs-config-$(date +%F).xml et collectez les sorties journalctl.
3. Isolez des nœuds : arrêtez Pacemaker sur au moins un nœud si vous souhaitez vérifier l’intégrité d’un support de stockage (systemctl stop pacemaker).
4. Identifiez l’instance de données ayant la plus haute autorité (p. ex. quel replica a eu les droits d’écriture en dernier, pour DRBD: Primary). Documentez les horodatages et les métriques IO.
5. Si un nœud autoritaire est identifié : répliquez les données (selon la technologie de stockage), remettez l’autre nœud dans un état propre et faites-le rejoindre de façon contrôlée.
6. Après restauration : phase de surveillance prolongée, alarmes renforcées et validation manuelle des contrôles end‑to‑end (VIP, écritures DB, journaux applicatifs).

Important : évitez le « force‑join » automatique sans vérification de la cohérence des données. Documentez chaque étape afin de rendre possibles d’éventuelles analyses forensiques.

Automatisation, contrôle de configuration et stratégie de test

Conservez les configurations de cluster versionnées (Git) et automatisées via des playbooks vérifiés. Testez les scénarios de fencing et de quorum de manière automatisée dans des laboratoires de type CI/CD (p. ex. staging basé sur Vagrant/VM). Seuls des playbooks vérifiés et reproductibles peuvent appliquer des modifications à Pacemaker/Corosync en production.

Ces compléments aident à réduire les risques d’architecture et d’exploitation : un witness adapté, des contraintes claires et un runbook de récupération testé font la différence entre des basculements occasionnels et une exploitation planifiable et auditée.

Pour ce sujet, les clusters Pacemaker et le fencing Stonith sont également importants. L’article remet ces aspects en contexte de manière claire et montre ce qui compte au quotidien.