Corosync et Pacemaker : Concepts et Architecture

Corosync et Pacemaker sont des outils essentiels pour assurer une haute disponibilité (HA) et la continuité des services dans les infrastructures Linux. Ce guide explore leurs concepts fondamentaux, leur architecture et les mécanismes de gestion des échecs pour comprendre comment ces outils garantissent la résilience des clusters de serveurs.

Historique

La genèse et le développement de Corosync et Pacemaker sont intrinsèquement liés à l’évolution des besoins en haute disponibilité et en gestion de clusters.

Corosync est issu du projet OpenAIS, qui avait pour objectif de développer une implémentation open source des standards de l’API de service d’interface d’application (API). Le but était de créer une infrastructure de communication pour les services de haute disponibilité. À mesure que le projet évoluait, le besoin de simplifier et de focaliser les fonctionnalités sur la communication en cluster est devenu évident. Corosync a ainsi été créé pour se concentrer exclusivement sur la couche de communication, laissant la gestion des ressources à d’autres outils, tels que Pacemaker.

Pacemaker a été développé initialement par la société Linux-HA (High-Availability Linux) pour étendre les capacités de l’outil Heartbeat, qui était alors limité à la gestion de deux nœuds seulement. Avec l’augmentation de la complexité des infrastructures IT et la nécessité de gérer des clusters plus grands et plus dynamiques, Pacemaker est devenu un gestionnaire de ressources complet capable de supporter des configurations de clusters étendues et complexes.

Au fil du temps, Corosync et Pacemaker ont été intégrés pour travailler conjointement, fournissant une solution complète pour la gestion de clusters haute disponibilité. Cette intégration a permis aux utilisateurs de bénéficier d’une communication efficace entre les nœuds avec Corosync, tout en utilisant Pacemaker pour la gestion fine et stratégique des ressources du cluster. Cette synergie a renforcé leur position comme la solution de référence pour les systèmes nécessitant une haute disponibilité.

Fonctionnalités principales

Fonctionnalités principales de Corosync

Corosync est responsable de la communication et de la synchronisation entre les nœuds d’un cluster. Voici ses points forts :

• Gestion du quorum : Il vérifie qu’un certain nombre de nœuds du cluster sont actifs pour garantir la cohérence des données et éviter des situations où plusieurs nœuds prennent des décisions contradictoires.
• Communication inter-nœuds : Corosync offre un mécanisme fiable et performant pour échanger des messages entre les nœuds d’un cluster. Il repose sur des protocoles comme Totem pour assurer la diffusion en anneau (ring).
• Détection des pannes : Si un nœud devient inactif ou ne répond plus, Corosync le détecte rapidement et notifie le cluster pour prendre des mesures correctives.
• Extension via plugins : Corosync peut être enrichi avec des modules supplémentaires pour répondre à des besoins spécifiques, comme la gestion d’événements ou le suivi des ressources.

Fonctionnalités principales de Pacemaker

Pacemaker gère les ressources du cluster et s’assure que les services critiques restent disponibles en tout temps. Ses atouts incluent :

• Gestion des ressources : Pacemaker permet de configurer, surveiller et relancer des ressources comme des services (ex : Apache, Nginx) ou des disques montés.
• Failover automatisé : En cas de défaillance d’un nœud, Pacemaker déplace automatiquement les ressources vers un autre nœud actif du cluster.
• Gestion des dépendances : Il prend en compte les relations entre ressources (par exemple, un service web doit attendre que le service de base de données soit actif).
• STONITH (Shoot The Other Node In The Head) : Pacemaker utilise des mécanismes de fencing pour couper complètement un nœud en panne ou isolé, afin de protéger les données.
• Flexibilité de configuration : Pacemaker prend en charge des profils complexes de règles (par exemple, redémarrer un service après 3 échecs ou ajuster les comportements selon l’heure ou la charge).
• Monitoring et alerte : Il surveille l’état des ressources et envoie des alertes si quelque chose ne va pas, tout en enregistrant des logs détaillés pour les diagnostics.

Fonctionnalités combinées Corosync + Pacemaker

Ensemble, Corosync et Pacemaker offrent une solution complète pour la haute disponibilité :

• Fiabilité des clusters grâce à la communication robuste de Corosync et la gestion intelligente des ressources de Pacemaker.
• Tolérance aux pannes : les services critiques restent disponibles même si un ou plusieurs nœuds tombent.
• Scalabilité : ils peuvent être utilisés dans des petits clusters (2 nœuds) ou des clusters plus larges pour des environnements complexes.
• Simplicité d’utilisation : bien que puissants, ces outils disposent d’interfaces claires et d’une documentation bien fournie pour faciliter leur prise en main.

Concepts clés

Pour comprendre pleinement comment Corosync et Pacemaker fonctionnent ensemble dans la gestion des clusters, il est indispensable de maîtriser certains concepts fondamentaux du clustering. Ces concepts sont essentiels pour configurer et maintenir un cluster de haute disponibilité.

• Quorum : Le quorum est un concept clé dans la gestion des clusters, désignant la majorité nécessaire pour prendre des décisions opérationnelles. Dans un cluster, le quorum aide à éviter le problème de “split brain”, où le cluster pourrait être divisé en plusieurs sous-groupes qui fonctionnent de manière indépendante, ce qui peut entraîner des conflits de données. Corosync utilise des mécanismes de quorum pour s’assurer qu’un seul sous-ensemble de nœuds (ayant la majorité) peut opérer à un moment donné, améliorant ainsi l’intégrité et la cohérence des données.

• Fencing (Isolation) : Le fencing est une stratégie de sécurité critique pour la gestion des clusters. Il s’agit de l’isolation d’un nœud qui semble défaillant ou instable, pour empêcher qu’il cause des dommages au reste du cluster, comme des corruptions de données. Pacemaker utilise le fencing pour garantir que seulement les nœuds sains et fiables participent au cluster, en éteignant ou en redémarrant les nœuds problématiques si nécessaire.

Les différents types de ressources Pacemaker

Dans le contexte de Pacemaker, une ressource représente un service ou un élément du système que le cluster doit gérer pour garantir une haute disponibilité. Ces ressources peuvent inclure des services comme une base de données, un serveur web, ou même des adresses IP flottantes. Pacemaker utilise différents types d’agents pour gérer ces ressources. Ces agents définissent comment démarrer, arrêter et surveiller une ressource spécifique. Les principaux types d’agents de ressources utilisés dans Pacemaker incluent OCF, systemd et lsb.

OCF (Open Cluster Framework)

Les scripts OCF sont un standard développé par le projet Linux-HA pour uniformiser la manière dont les ressources sont gérées dans un cluster de haute disponibilité. Les scripts OCF sont des scripts shell qui suivent une convention spécifique et offrent des actions standardisées telles que start, stop, monitor, meta-data, entre autres. Chaque script OCF doit être capable de :

• Démarrer une ressource
• Arrêter une ressource
• Surveiller l’état actuel de la ressource
• Fournir des métadonnées décrivant la ressource et ses paramètres

Un exemple de configuration d’une ressource OCF dans Pacemaker pourrait ressembler à ceci :

pcs resource create myResource ocf:heartbeat:Dummy op monitor interval=30s

Ici, heartbeat:Dummy indique que le script OCF Dummy du fournisseur heartbeat est utilisé.

Les scripts OCF sont généralement stockés dans des répertoires spécifiques au fournisseur sous le dossier /usr/lib/ocf/resource.d/. Chaque fournisseur, tel que heartbeat ou pacemaker, a son propre sous-dossier dans ce répertoire.

Exemple de contenu du dossier /usr/lib/ocf/resource.d/heartbeat:

root@node1:/usr/lib/ocf/resource.d# ls heartbeat/
AoEtarget     LVM              SphinxSearchDaemon  apache           docker            iface-bridge  minio                    oralsnr           rsyslog
AudibleAlarm  LVM-activate     Squid               asterisk         docker-compose    iface-vlan    mpathpersist             ovsmonitor        scsi2reservation
CTDB          LinuxSCSI        Stateful            aws-vpc-move-ip  dovecot           ipsec         mysql                    pgagent           sfex
ClusterMon    MailTo           SysInfo             aws-vpc-route53  dummypy           iscsi         mysql-proxy              pgsql             sg_persist
Delay         ManageRAID       VIPArip             awseip           eDir88            jboss         nagios                   pingd             slapd
Dummy         ManageVE         VirtualDomain       awsvip           ethmonitor        jira          named                    podman            sybaseASE
EvmsSCC       NodeUtilization  WAS                 azure-events     exportfs          kamailio      nfsnotify                portblock         symlink
Evmsd         Pure-FTPd        WAS6                azure-lb         fio               ldirectord    nfsserver                postfix           syslog-ng
Filesystem    Raid1            WinPopup            clvm             galera            lvmlockd      nginx                    pound             tomcat
ICP           Route            Xen                 conntrackd       garbd             lxc           openstack-cinder-volume  proftpd           varnish
IPaddr        SAPDatabase      Xinetd              crypt            gcp-vpc-move-ip   lxd-info      openstack-floating-ip    rabbitmq-cluster  vdo-vol
IPaddr2       SAPInstance      ZFS                 db2              iSCSILogicalUnit  machine-info  openstack-info           redis             vmware
IPsrcaddr     SendArp          aliyun-vpc-move-ip  dhcpd            iSCSITarget       mariadb       oraasm                   rkt               vsftpd
IPv6addr      ServeRAID        anything            dnsupdate        ids               mdraid        oracle                   rsyncd            zabbixserver

systemd

Les unités systemd sont des scripts de service pour le système d’initialisation systemd, utilisé par de nombreuses distributions Linux modernes pour gérer les services système et les processus. Pacemaker peut directement gérer ces services en tant que ressources, en utilisant les commandes et fonctionnalités fournies par systemd. Cela permet une intégration étroite avec les composants système sous-jacents et simplifie la gestion des services qui sont déjà configurés pour être gérés par systemd.

Pour configurer une ressource systemd dans Pacemaker, vous pouvez utiliser une commande telle que :

pcs resource create myWebServer systemd:httpd.service op monitor interval=60s

Dans cet exemple, httpd.service est le nom du service systemd géré par Pacemaker.

LSB (Linux Standard Base)

Les scripts LSB sont basés sur les standards de la Linux Standard Base, qui définit les actions de service standard comme start, stop, status, et restart. Pacemaker peut utiliser ces scripts pour gérer des services qui ne sont pas encore intégrés à systemd. Bien que moins fréquemment utilisés aujourd’hui en raison de la prévalence de systemd, ils sont toujours pris en charge pour assurer la compatibilité avec les systèmes plus anciens.

Un exemple de commande pour configurer une ressource LSB pourrait être :

pcs resource create myOldService lsb:my-service op monitor interval=120s

Choix de l’agent de ressource

Le choix de l’agent de ressource dépend principalement du type de service à gérer et de l’environnement système. Les agents OCF sont préférables pour leur portabilité et leur extensibilité, tandis que les agents systemd sont mieux intégrés avec les systèmes qui utilisent systemd pour la gestion des services. Les agents LSB peuvent être utilisés pour les services plus anciens ou pour ceux qui ne sont pas encore pris en charge par systemd.

Stratégie de fencing de Pacemaker

Le fencing, également connu sous le terme de clôture, est une stratégie importante dans la gestion des clusters de haute disponibilité, comme ceux contrôlés par Pacemaker. Le but principal du fencing est de prévenir les scénarios de “cerveau divisé” (split-brain) où plusieurs nœuds du cluster croient être le coordinateur actif, conduisant potentiellement à des corruptions de données.

Le fencing est une méthode utilisée pour isoler un nœud défectueux ou non fiable d’un cluster, afin de garantir que ce nœud ne puisse pas causer de dommages aux données partagées ou aux services du cluster. Cela est souvent réalisé en coupant l’accès du nœud aux ressources partagées, telles que le stockage réseau ou l’adresse IP virtuelle. Il existe principalement deux types de fencing :

• Fencing actif : où le système prend des mesures actives pour isoler le nœud défectueux, comme redémarrer ou éteindre le nœud.
• Fencing passif : où le nœud défectueux est simplement ignoré par les autres nœuds du cluster sans prendre de mesures actives pour l’arrêter.

Les principaux agents de fencing de Pacemaker

Pacemaker supporte une variété d’agents de fencing (aussi appelés agents STONITH, pour “Shoot The Other Node In The Head”), qui sont essentiels pour assurer l’intégrité des données et la haute disponibilité dans un environnement de cluster. Ces agents permettent de garantir qu’un nœud défectueux est correctement isolé du cluster pour éviter les conflits et la corruption des données. Voici une liste de quelques agents de fencing communément utilisés avec Pacemaker :

1. fence_aws : Conçu pour interagir avec les services Amazon Web Services (AWS). Cet agent peut arrêter, redémarrer ou isoler des instances EC2 via l’API AWS.
2. fence_azure_arm : Utilisé pour les environnements Microsoft Azure. Cet agent fait appel à Azure Resource Manager pour gérer les instances virtuelles.
3. fence_gce : Dédié aux environnements Google Cloud Platform (GCP). Il utilise l’API Google Compute Engine pour contrôler les instances virtuelles.
4. fence_vmware_soap : Cet agent utilise l’API SOAP de VMware pour gérer les machines virtuelles sur des hôtes VMware ESXi ou vSphere.
5. fence_ipmilan : Utilise l’interface de gestion à distance IPMI (Intelligent Platform Management Interface) pour contrôler le matériel serveur, permettant des actions telles que l’arrêt ou le redémarrage de la machine.
6. fence_rhevm : Conçu pour les environnements Red Hat Enterprise Virtualization (RHEV), maintenant connu sous le nom de Red Hat Virtualization (RHV). Cet agent interagit avec l’API RHEV pour gérer les machines virtuelles.
7. fence_xvm : Utilisé pour le fencing de machines virtuelles Xen à l’aide de commandes xm ou xl sur un hôte Xen.
8. fence_scsi : Un agent de fencing qui utilise le SCSI persistent reservations pour contrôler l’accès aux périphériques de stockage partagé.
9. fence_brocade : Permet le contrôle des switches Fibre Channel Brocade via telnet, ssh ou SNMP.
10. fence_drac : Cible les serveurs Dell équipés de la carte de gestion à distance iDRAC, permettant diverses opérations de contrôle à distance.

Ces agents couvrent un large éventail de technologies et de plateformes, offrant ainsi des solutions de fencing flexibles et adaptées à divers environnements de datacenter et de cloud. Choisir l’agent approprié dépend des équipements et des services spécifiquement utilisés dans votre infrastructure.

Les principaux outils pour gérer des clusters

Il existe deux principaux outils en ligne de commande pour gérer les clusters : crm et pcs.

Utilisation et commandes principales de crm

crm est une interface en ligne de commande pour gérer les clusters qui utilisent le moteur de haute disponibilité Pacemaker. Cet outil est essentiel pour la configuration et la gestion du cluster, permettant aux administrateurs de surveiller, de modifier et de maintenir les paramètres et les ressources du cluster de manière interactive. crm offre une interface complète pour la gestion des clusters, ce qui en fait un choix privilégié pour les configurations complexes et les ajustements fins.

crm status

Cette commande fournit un aperçu de l’état actuel du cluster, y compris l’état des nœuds, des ressources et des contraintes de groupe.

crm configure show

Utilisez cette commande pour afficher la configuration actuelle des ressources du cluster.

crm configure edit <resource_name>

Cette commande permet de modifier la configuration d’une ressource spécifique.

crm node status

Montre le statut de chaque nœud du cluster.

crm configure colocation add <constraint_name> <resource1> with <resource2>

Définit une contrainte de colocation pour que deux ressources soient placées sur le même nœud.

crm configure stonith

Permet de configurer et de gérer les dispositifs STONITH dans le cluster.

Utilisation et commandes principales de pcs

pcs (Pacemaker/Corosync Configuration System) est un outil de gestion de cluster qui simplifie le processus de configuration de clusters utilisant Corosync et Pacemaker. Il fournit une interface de ligne de commande unifiée pour configurer, gérer et visualiser tous les aspects du cluster.

pcs status

Cluster name: my_cluster
Cluster Summary:
  * Stack: corosync
  * Current DC: node2.test.local (version 2.1.2-ada5c3b36e2) - partition with quorum
  * Last updated: Tue May 14 08:37:39 2024
  * Last change:  Tue May 14 06:10:26 2024 by hacluster via crmd on node1.test.local
  * 2 nodes configured
  * 1 resource instance configured

Node List:
  * Online: [ node1.test.local node2.test.local ]

Full List of Resources:
  * HAProxy   (systemd:haproxy):  Started node2.test.local

Daemon Status:
  corosync: active/enabled
  pacemaker: active/enabled
  pcsd: active/enabled

Cette commande donne une vue d’ensemble de l’état du cluster, incluant les nœuds, les ressources et les contraintes.

pcs resource create <resource_name> <agent> [options]

Crée une nouvelle ressource avec le type d’agent spécifié et des options configurables.

pcs cluster start --all
pcs cluster stop --all

Ces commandes permettent de démarrer ou d’arrêter tous les nœuds du cluster.

pcs property set stonith-enabled=true

Active ou modifie une propriété du cluster, comme l’activation de STONITH.

pcs constraint colocation add <resource1> with <resource2> [score]

Ajoute une contrainte de colocation entre deux ressources.

Quel outil choisir : crm ou pcs ?

Bien que crm et pcs accomplissent des fonctions similaires, pcs est souvent préféré pour sa simplicité et son approche plus directes.

pcs est conçu pour être plus accessible et plus facile à utiliser pour les nouveaux administrateurs de clusters, fournissant des commandes claires et des options de configuration simplifiées. Cela en fait un outil idéal pour les tâches courantes de gestion de clusters, rendant la configuration et la surveillance plus intuitives et moins sujettes aux erreurs.

Gestion des échecs : fail-count et migration-threshold

Pacemaker intègre un système sophistiqué de gestion des échecs qui permet de contrôler finement le comportement du cluster en cas de problème avec une ressource. Comprendre ces mécanismes est essentiel pour configurer un cluster robuste et éviter les basculements intempestifs.

Le fail-count : compteur d’échecs

Le fail-count est un compteur qui enregistre le nombre d’échecs d’une ressource sur un nœud spécifique. Chaque fois qu’une opération de monitoring échoue ou qu’une ressource ne démarre pas correctement, Pacemaker incrémente ce compteur.

Consulter les fail-counts :

# Voir tous les compteurs d'échecs
pcs resource failcount show

# Voir le fail-count d'une ressource spécifique
pcs resource failcount show HAProxy

# Sortie exemple :
# Failcounts for HAProxy
# node1.test.local: 2
# node2.test.local: 0

Le migration-threshold : seuil de basculement

Le migration-threshold définit le nombre d’échecs tolérés avant que Pacemaker ne bascule automatiquement la ressource vers un autre nœud. Par défaut, cette valeur est INFINITY, ce qui signifie qu’un seul échec déclenche un basculement.

Configuration du seuil :

# Configurer le seuil à 3 échecs avant basculement
pcs resource meta HAProxy migration-threshold=3

# Vérifier la configuration
pcs resource config HAProxy

Exemple de comportement :

• Échec 1 : fail-count = 1, ressource redémarrée sur place
• Échec 2 : fail-count = 2, ressource redémarrée sur place
• Échec 3 : fail-count = 3, basculement vers l’autre nœud

Le failure-timeout : réinitialisation automatique

Le failure-timeout définit le délai après lequel le fail-count est automatiquement remis à zéro si aucun nouvel échec ne se produit. Cela évite qu’un ancien problème temporaire ne bloque indéfiniment une ressource.

# Réinitialiser le compteur après 5 minutes sans échec
pcs resource meta HAProxy failure-timeout=300s

# Valeurs courantes :
# - 60s : pour des services très dynamiques
# - 300s (5 min) : valeur équilibrée (recommandé)
# - 600s (10 min) : pour des services stables

Le resource-stickiness : éviter les migrations inutiles

Le resource-stickiness est un score qui indique la “préférence” d’une ressource à rester sur son nœud actuel. Une valeur élevée évite les migrations inutiles lorsque le nœud d’origine redevient disponible.

# Configurer un stickiness de 100 (valeur modérée)
pcs resource meta HAProxy resource-stickiness=100

# Valeurs recommandées :
# - 0 : Pas de préférence (peut migrer facilement)
# - 100 : Préférence modérée (recommandé)
# - 1000 : Forte préférence (évite presque toute migration)
# - INFINITY : La ressource ne migre jamais automatiquement

Les options on-fail : réaction aux échecs

L’option on-fail définit l’action à entreprendre lorsqu’une opération échoue. Chaque opération (start, stop, monitor) peut avoir sa propre stratégie.

Actions disponibles :

• restart (défaut) : Redémarre la ressource sur place
• ignore : Ignore l’échec, continue comme si de rien n’était
• block : Bloque la ressource, ne fait aucune tentative de récupération
• stop : Arrête la ressource sans la redémarrer
• standby : Met le nœud en standby
• fence : Déclenche le fencing du nœud (STONITH)

Exemples de configuration :

# Redémarrer en cas d'échec de monitoring
pcs resource op add HAProxy monitor interval=30s on-fail=restart

# Bloquer en cas d'échec d'arrêt (éviter les corruptions)
pcs resource op add HAProxy stop timeout=60s on-fail=block

# Exemple complet avec toutes les opérations
pcs resource create HAProxy systemd:haproxy \
  op start timeout=60s interval=0s on-fail=restart \
  op monitor timeout=30s interval=10s on-fail=restart \
  op stop timeout=60s interval=0s on-fail=block

Scénario réel : chronologie d’une panne avec récupération

Prenons un exemple concret avec HAProxy configuré avec migration-threshold=3 et failure-timeout=300s :

T+0s : HAProxy fonctionne normalement sur node1

Status: HAProxy Started node1 (fail-count: 0)

T+10s : Premier échec de monitoring (timeout réseau temporaire)

10:00:10 - Monitor HAProxy failed on node1
Status: HAProxy Restarting on node1 (fail-count: 1)
Action: restart on node1

T+20s : Service redémarré, fonctionne à nouveau

Status: HAProxy Started node1 (fail-count: 1)

T+150s : Deuxième échec (pic de charge)

10:02:30 - Monitor HAProxy failed on node1
Status: HAProxy Restarting on node1 (fail-count: 2)
Action: restart on node1

T+160s : Service redémarré

Status: HAProxy Started node1 (fail-count: 2)

T+200s : Troisième échec (problème matériel détecté)

10:03:20 - Monitor HAProxy failed on node1
Status: HAProxy Migrating to node2 (fail-count: 3 = threshold)
Action: stop on node1, start on node2

T+210s : Migration complétée

Status: HAProxy Started node2 (node1 fail-count: 3)

T+510s : Timeout atteint (300s après dernier échec à T+210s)

10:08:30 - Failure-timeout expired for node1
Status: HAProxy Started node2 (node1 fail-count: 0)
Note: node1 redevient éligible pour héberger HAProxy

Commandes de diagnostic et résolution

Vérifier l’état détaillé d’une ressource :

# Voir les échecs récents et fail-counts
pcs resource failcount show HAProxy

# Afficher l'état complet du cluster
pcs status --full

# Voir l'historique des opérations d'une ressource
pcs resource op defaults

Limitation avec les ressources systemd

Les commandes pcs resource debug-start, debug-stop et debug-monitor ne fonctionnent pas avec les ressources de type systemd :

# ERREUR avec systemd:haproxy
pcs resource debug-monitor HAProxy
# Operation force-check for HAProxy (systemd:haproxy) could not be executed
# Error: Manual execution of the systemd standard is unsupported

Solution 1 : Test manuel avec systemctl :

# Arrêter temporairement la gestion par Pacemaker
pcs resource unmanage HAProxy

# Tester avec systemctl
sudo systemctl status haproxy
sudo systemctl restart haproxy
sudo systemctl is-active haproxy

# Remettre sous gestion Pacemaker
pcs resource manage HAProxy

Solution 2 : Utiliser les opérations Pacemaker :

# Redémarrer la ressource via Pacemaker
pcs resource restart HAProxy

# Forcer le monitoring (déclenche une vérification)
pcs resource refresh HAProxy

# Nettoyer et redémarrer
pcs resource cleanup HAProxy
pcs resource restart HAProxy --wait

Nettoyer les fail-counts :

# Réinitialiser le compteur d'une ressource sur tous les nœuds
pcs resource cleanup HAProxy

# Réinitialiser sur un nœud spécifique
pcs resource cleanup HAProxy node1.test.local

# Forcer le redémarrage et nettoyage
pcs resource restart HAProxy --force

Surveiller les échecs en temps réel :

# Logs Pacemaker en temps réel
sudo tail -f /var/log/pacemaker/pacemaker.log | grep -i "fail\|error"

# Journal systemd pour une ressource spécifique
sudo journalctl -u haproxy -f

Bonnes pratiques de configuration

Configuration recommandée pour un service web critique :

pcs resource create HAProxy systemd:haproxy \
  meta migration-threshold=3 \
       failure-timeout=300s \
       resource-stickiness=100 \
  op start timeout=60s interval=0s on-fail=restart \
  op monitor timeout=30s interval=10s on-fail=restart \
  op stop timeout=60s interval=0s on-fail=block

Explications des choix :

• migration-threshold=3 : Tolère 2 échecs temporaires avant de migrer
• failure-timeout=300s : Réinitialise après 5 minutes de stabilité
• resource-stickiness=100 : Préfère rester sur le nœud actuel
• start on-fail=restart : Retente le démarrage si échec
• monitor on-fail=restart : Redémarre si monitoring échoue
• stop on-fail=block : Bloque si arrêt échoue (évite corruption)

Ajustements selon le contexte :

• Service très stable : migration-threshold=5, failure-timeout=600s
• Service volatile : migration-threshold=2, failure-timeout=60s
• Service critique : resource-stickiness=INFINITY (ne jamais migrer automatiquement)

Surveillance proactive

Mettre en place des alertes sur les fail-counts :

#!/bin/bash
# check-failcounts.sh - À exécuter via cron toutes les 15 minutes

THRESHOLD=2
FAILCOUNTS=$(pcs resource failcount show | grep -v "^$" | grep -v "Failcounts" | awk '{print $2}')

for count in $FAILCOUNTS; do
    if [ "$count" -ge "$THRESHOLD" ]; then
        logger -t pacemaker-check "ALERT: Fail-count >= $THRESHOLD détecté"
        # Envoyer alerte email/Slack/etc.
    fi
done

Conclusion

Corosync et Pacemaker forment ensemble une solution robuste et éprouvée pour la haute disponibilité dans les infrastructures Linux. Leur architecture modulaire permet de séparer les responsabilités : Corosync assure la communication fiable entre nœuds et la gestion du quorum, tandis que Pacemaker orchestre intelligemment les ressources et gère les mécanismes de failover.

La maîtrise des concepts fondamentaux - quorum, fencing, agents de ressources, et gestion des échecs - est indispensable pour concevoir des clusters résilients. Les mécanismes sophistiqués de fail-count, migration-threshold et resource-stickiness permettent d’ajuster finement le comportement du cluster selon les besoins spécifiques de chaque service.

Plus d’infos

ClusterLabs ↗