Pacemaker + Corosync : mettre en place une haute disponibilité générique (VIP, watchdog, fencing)

Pacemaker (gestionnaire de ressources) et Corosync (messagerie de cluster) forment une stack de haute disponibilité (HA) très flexible pour protéger des services variés (base de données, NFS, services web, etc.).
L’objectif : détecter la panne d’un nœud, redémarrer la ressource ailleurs et publier une IP virtuelle (VIP) pour une continuité transparente.

• Prérequis & architecture
• Installation (Debian/Ubuntu & RHEL)
• Configuration de Corosync (anneau, quorum)
• Configuration de Pacemaker (ressources, contraintes)
• Fencing/STONITH & watchdog
• Tests de bascule et vérifications
• Bonnes pratiques & supervision
• Conclusion

• Pour une orchestration Kubernetes HA, consultez Kubernetes en haute disponibilité
• Sécurisez vos secrets en cluster avec HashiCorp Vault HA
• Supervisez le cluster avec une stack de monitoring complète
• Explorez HAProxy en cluster
• Synchronisez l'heure avec NTP local
• Découvrez Consul pour la service discovery

• 2 à 3 nœuds (au moins 2 pour la redondance, 3 recommandé pour un quorum robuste).
• Un réseau fiable entre nœuds (latence faible).
• Une IP virtuelle (VIP) qui sera déplacée entre nœuds.
• Des données partagées si nécessaire (DRBD, NFS, SAN) selon le service protégé.
• Accès root/admin et pare-feu ajusté pour les ports Corosync/Pacemaker.

Debian/Ubuntu

sudo apt update
sudo apt install pacemaker corosync pcs fence-agents

RHEL/CentOS/Rocky

sudo yum install pacemaker corosync pcs fence-agents-all
sudo systemctl enable --now pcsd
echo "motdepasse" | sudo passwd --stdin hacluster   # RHEL-like

Synchroniser l’heure (chrony/ntp) et configurer la résolution DNS/hosts pour tous les nœuds.

Fichier /etc/corosync/corosync.conf minimal (transport unicast UDP) :

totem {
  version: 2
  secauth: on
  cluster_name: ha-cluster
  transport: udpu
}
nodelist {
  node { ring0_addr: node1; name: node1; nodeid: 1; }
  node { ring0_addr: node2; name: node2; nodeid: 2; }
}
quorum { provider: corosync_votequorum; two_node: 1; }
logging { to_syslog: yes; }

Activer et démarrer :

sudo systemctl enable --now corosync pacemaker

Vérifier le cluster :

pcs status        # ou crm_mon -1

Créer une IP virtuelle (ex. 192.168.1.50/24 sur eth0) et une ressource service (ex. apache/httpd) :

pcs resource create vip ocf:heartbeat:IPaddr2 ip=192.168.1.50 cidr_netmask=24 nic=eth0 op monitor interval=20s
pcs resource create web systemd:httpd op monitor interval=30s timeout=20s

Définir l’ordre (la VIP doit suivre le service ou l’inverse selon le design) et l’emplacement :

pcs constraint order start web then vip
pcs constraint colocation add vip with web INFINITY

Le fencing (STONITH) évite les split-brain : le nœud défaillant est mis hors ligne de façon sûre.
Exemple générique (IPMI/iDRAC/ILO) :

pcs stonith create fence-node1 fence_ipmilan pcmk_host_list="node1" ipaddr="10.0.0.11" login="admin" passwd="secret" lanplus="1"
pcs stonith create fence-node2 fence_ipmilan pcmk_host_list="node2" ipaddr="10.0.0.12" login="admin" passwd="secret" lanplus="1"
pcs property set stonith-enabled=true
pcs property set no-quorum-policy=stop

Option watchdog (soft fencing) si disponible :

modprobe softdog
pcs property set stonith-watchdog-timeout=10s

• Arrêt du service sur le nœud actif : Pacemaker redémarre ailleurs.
• Coupure réseau (simulée) : vérifier le comportement du quorum.
• Arrêt du nœud : la VIP et la ressource migrent automatiquement.

Commandes utiles :

pcs status
pcs resource move web node2           # migration manuelle (test)
pcs resource clear web                # nettoyage des contraintes temporaires

• Toujours activer STONITH et tester les scénarios de panne.
• Versionner la configuration (pcs config backup), documenter les procédures de DR.
• Surveiller avec Prometheus (exporter pacemaker), crm_mon -1, journaux journalctl -u pacemaker.
• Éviter les dépendances cachées (montages, DNS, pare-feu).
• Ajuster les timeouts et op monitor selon le service protégé.

Avec Pacemaker + Corosync, vous mettez en place une HA générique et robuste : détection de panne, bascule automatique, fencing et VIP pour une continuité transparente.
Cette stack s’adapte à de nombreux services (bases, NFS, web) et reste une valeur sûre en production.