Pacemaker et Corosync — cluster haute disponibilité Linux

La haute disponibilité (HA) est une exigence incontournable pour les infrastructures qui ne peuvent se permettre aucune interruption de service. Qu’il s’agisse d’un serveur web, d’une base de données ou d’un service NFS, une panne matérielle ou logicielle sans mécanisme de reprise automatique se traduit directement par une interruption visible pour les utilisateurs. Sur Linux, la combinaison Pacemaker et Corosync constitue la référence pour bâtir des clusters HA robustes et flexibles.

Corosync assure la couche de communication entre les nœuds du cluster : il maintient un bus de messages fiable, gère le quorum et détecte les défaillances. Pacemaker s’appuie sur cette infrastructure pour orchestrer les ressources — démarrage, arrêt, déplacement d’un service d’un nœud à l’autre en cas de panne. Ensemble, ils forment une stack éprouvée, présente dans des environnements RHEL/Rocky, Debian et Ubuntu depuis plus d’une décennie.

Cet article couvre l’installation et la configuration d’un cluster à deux nœuds sous Debian/Ubuntu : mise en place de Corosync, initialisation du cluster via pcs, création d’une IP virtuelle et d’un service managé, configuration du fencing STONITH, et tests de bascule. À l’issue, vous disposerez d’une base opérationnelle prête à être adaptée à votre cas d’usage.

Architecture et concepts fondamentaux

Corosync : le bus de communication

Corosync (Cluster Engine) implémente le protocole Totem, un protocole de diffusion en anneau à ordre total. Il garantit que tous les nœuds reçoivent les mêmes messages dans le même ordre — condition nécessaire pour maintenir un état cohérent du cluster. Il gère également le quorum : le cluster n’est actif que si suffisamment de nœuds sont joignables, ce qui prévient les situations de split-brain où deux nœuds s’imaginent tous deux être le maître.

Pacemaker : le gestionnaire de ressources

Pacemaker (Cluster Resource Manager, CRM) consomme les événements produits par Corosync pour décider où et comment faire tourner les ressources. Une ressource est n’importe quel service géré par le cluster : une IP virtuelle, un processus systemd, un volume, un conteneur. Pacemaker supporte des contraintes (ordre de démarrage, colocalisation) et des politiques de défaillance configurables finement.

STONITH : fencing et isolation

STONITH (Shoot The Other Node In The Head) est le mécanisme de fencing : lorsqu’un nœud ne répond plus, le cluster doit pouvoir le couper physiquement avant de reconfigurer les ressources sur un nœud sain — sans quoi deux nœuds pourraient écrire simultanément sur le même volume, avec corruption à la clé. Le fencing peut s’appuyer sur IPMI, l’API d’un hyperviseur, ou des agents logiciels.

Prérequis et installation

Environnement de référence

• Deux serveurs : node1 (192.168.1.10) et node2 (192.168.1.20)
• IP virtuelle cible : 192.168.1.50
• OS : Debian 12 / Ubuntu 24.04 LTS
• Résolution DNS ou /etc/hosts configurée sur les deux nœuds

Ajoutez les entrées dans /etc/hosts sur les deux nœuds :

192.168.1.10  node1
192.168.1.20  node2

Installation des paquets

Exécutez sur les deux nœuds :

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

# Activer le démon PCS (interface de gestion)
systemctl enable --now pcsd

Définissez un mot de passe identique pour l’utilisateur hacluster sur les deux nœuds — PCS utilise ce compte pour l’authentification inter-nœuds :

# Sur node1 ET node2 (même mot de passe)
echo "VotreMotDePasseHA" | passwd --stdin hacluster 2>/dev/null || 
  echo "VotreMotDePasseHA" | passwd hacluster

Configuration de Corosync

Génération de la clé d’authentification

Sur node1 uniquement, générez la clé partagée puis copiez-la sur node2 :

# Génération de la clé (prend quelques secondes)
corosync-keygen

# Copie vers node2 (ajustez l'utilisateur si besoin)
scp /etc/corosync/authkey root@node2:/etc/corosync/authkey

# Permissions correctes sur node2
ssh root@node2 "chmod 400 /etc/corosync/authkey"

Fichier corosync.conf

Éditez /etc/corosync/corosync.conf sur les deux nœuds (contenu identique) :

totem {
    version:        2
    cluster_name:   prod-cluster
    transport:      udpu          # unicast — plus fiable que multicast
    secauth:        on            # authentification par clé partagée
    token:          3000          # délai d'expiration token en ms
    token_retransmits_before_loss_const: 10
}

nodelist {
    node {
        ring0_addr: 192.168.1.10
        name:       node1
        nodeid:     1
    }
    node {
        ring0_addr: 192.168.1.20
        name:       node2
        nodeid:     2
    }
}

quorum {
    provider:   corosync_votequorum
    two_node:   1    # quorum spécial pour cluster à 2 nœuds
}

logging {
    to_syslog:      yes
    debug:          off
}

Note : En cluster à deux nœuds, l’option two_node: 1 est indispensable. Sans elle, la perte d’un nœud fait chuter le quorum en dessous de 50 % et le cluster s’arrête — le résultat inverse de ce qu’on cherche.

Initialisation du cluster avec PCS

Toutes les commandes pcs suivantes sont exécutées depuis node1 uniquement.

# Authentification des nœuds
pcs host auth node1 node2 -u hacluster -p VotreMotDePasseHA

# Création et démarrage du cluster
pcs cluster setup prod-cluster node1 node2
pcs cluster start --all
pcs cluster enable --all

# Vérification de l'état
pcs status

La sortie de pcs status doit afficher les deux nœuds Online et aucune ressource en erreur :

Cluster name: prod-cluster
Cluster Summary:
  * Stack: corosync (Pacemaker is running)
  * 2 nodes configured

Node List:
  * Online: [ node1 node2 ]

Full List of Resources:
  * No resources

Création des ressources cluster

IP virtuelle (VIP)

La VIP est l’élément central : elle se déplace automatiquement vers le nœud actif. C’est elle que les clients ciblent — l’adresse IP physique des nœuds ne les intéresse pas.

pcs resource create vip_cluster 
    ocf:heartbeat:IPaddr2 
    ip=192.168.1.50 
    cidr_netmask=24 
    nic=eth0 
    op monitor interval=10s

# Vérification
pcs resource status vip_cluster

Service applicatif (exemple : Nginx)

Pacemaker peut gérer n’importe quel service géré par systemd via l’agent systemd: :

pcs resource create svc_nginx 
    systemd:nginx 
    op monitor interval=30s 
    op start   timeout=60s 
    op stop    timeout=60s

Contraintes de colocalisation et d’ordre

On veut que la VIP et Nginx tournent toujours sur le même nœud, et que Nginx démarre avant la VIP :

# Nginx et VIP sur le même nœud (obligatoire)
pcs constraint colocation add vip_cluster with svc_nginx INFINITY

# Nginx démarre avant la VIP
pcs constraint order svc_nginx then vip_cluster

# Afficher toutes les contraintes
pcs constraint list

Fencing STONITH

Sans fencing, Pacemaker refuse de démarrer les ressources sur un nœud sain en cas de défaillance d’un autre nœud — il ne peut pas garantir que le nœud défaillant a bien libéré ses ressources. Activez STONITH dès la mise en production.

# Exemple avec IPMI (adaptez l'agent à votre environnement)
pcs stonith create fence_node1 fence_ipmilan 
    pcmk_host_list="node1" 
    ipaddr="10.0.0.11" 
    login="admin" 
    passwd="secret" 
    op monitor interval=60s

pcs stonith create fence_node2 fence_ipmilan 
    pcmk_host_list="node2" 
    ipaddr="10.0.0.12" 
    login="admin" 
    passwd="secret" 
    op monitor interval=60s

# Activer STONITH globalement
pcs property set stonith-enabled=true
pcs property set no-quorum-policy=stop

En environnement virtuel (VMware, KVM, Proxmox), remplacez fence_ipmilan par l’agent correspondant : fence_vmware_soap, fence_virsh, etc. En développement ou lab sans IPMI, vous pouvez désactiver provisoirement STONITH avec pcs property set stonith-enabled=false — jamais en production.

Tests de bascule

La validation d’un cluster HA ne se fait pas uniquement en lisant la documentation — il faut simuler des pannes et vérifier que le comportement correspond aux attentes.

# Voir sur quel nœud tourne chaque ressource
pcs status

# Test 1 : migration manuelle vers node2
pcs resource move vip_cluster node2
pcs status  # VIP et Nginx doivent être sur node2

# Annuler la contrainte de migration manuelle
pcs resource clear vip_cluster

# Test 2 : simuler une panne de node1 (depuis node2)
pcs cluster stop node1
pcs status  # node2 doit reprendre toutes les ressources

# Réintégrer node1
pcs cluster start node1
pcs status  # les deux nœuds online, cluster stable

# Suivi temps réel
crm_mon -1           # snapshot une fois
watch -n2 pcs status # rafraîchissement toutes les 2 secondes

Pour une supervision continue du cluster en production, intégrez les métriques Pacemaker à Prometheus et Grafana via l’exporteur ha_cluster_exporter — vous disposerez ainsi d’alertes sur les transitions de ressources et les nœuds hors ligne.

Diagnostics courants

# Logs Corosync
journalctl -u corosync -f

# Logs Pacemaker
journalctl -u pacemaker -f

# Historique des transitions du cluster
crm_report -f "$(date -d '1 hour ago' '+%Y-%m-%d %H:%M')" /tmp/crm_report

# Vérifier la configuration sans l'appliquer
crm_verify -L -V

# Exporter la configuration CIB (XML complet du cluster)
pcs cluster cib > /tmp/cluster_backup.xml

# Restaurer depuis une sauvegarde
pcs cluster cib-push /tmp/cluster_backup.xml

Automatisation du déploiement

Déployer un cluster sur plusieurs nœuds manuellement est source d’erreurs. L’utilisation d’Ansible permet de rendre le processus reproductible : installation des paquets, distribution de la clé Corosync, configuration du corosync.conf via template Jinja2, et enregistrement des ressources via le module command: pcs resource create. Le rôle linux-system-roles/ha_cluster (Red Hat) ou des rôles communautaires Ansible Galaxy offrent une base solide.

À lire également

• Gestion des services avec systemd sur Debian et Ubuntu — comprendre le cycle de vie des services que Pacemaker orchestre via l’agent systemd:
• Ansible : automatiser la gestion de serveurs Linux avec des playbooks — industrialiser le déploiement et la configuration de vos nœuds de cluster
• Prometheus et Grafana sur Debian — installation, configuration et dashboards pratiques — superviser l’état du cluster et mettre en place des alertes sur les bascules de ressources
• Sécurité Linux — Firewall iptables et nftables — configurer les règles pare-feu pour les ports Corosync (UDP 5404-5406) et PCS (TCP 2224)

Références

• Documentation officielle Pacemaker — ClusterLabs
• Documentation officielle Corosync
• Debian Wiki — HA Clusters from Scratch
• Ubuntu Community Hub — High Availability avec Corosync et Pacemaker
• LINBIT — NFS HA avec DRBD et Pacemaker