Keepalived ou Pacemaker : faire basculer un service en moins de 10 s

1. Le principe : une IP qui se déplace

Deux machines hébergent le même service. Une adresse IP supplémentaire, dite flottante, n'appartient à aucune des deux en propre : elle est portée par celle qui assure le service à un instant donné. Les deux nœuds s'envoient en permanence de brefs messages ; quand ils cessent d'arriver, le survivant s'attribue l'adresse et annonce au réseau qu'elle est désormais chez lui.

Du point de vue du client, rien ne change : il continue de s'adresser à la même IP, sans savoir qu'il y a deux machines derrière ni laquelle lui répond. C'est ce qui distingue cette approche d'un changement de DNS, qui demanderait à chaque client de se réinterroger et d'attendre l'expiration de son cache. Le mécanisme est normalisé sous le nom de VRRP (RFC 5798^[1]).

Côté BSD, l'équivalent s'appelle CARP (Common Address Redundancy Protocol). Le principe est le même — une adresse partagée, un maître élu, des annonces périodiques — mais l'implémentation est intégrée au système plutôt que fournie par un démon tiers. Si votre pare-feu ou votre passerelle tourne sous OpenBSD, FreeBSD ou pfSense, c'est CARP qu'on déploie, pas keepalived.

Pourquoi deux protocoles pour le même besoin

La raison est juridique, pas technique, et elle mérite d'être racontée correctement. VRRP est une norme de l'IETF (RFC 5798^[1]), pas un protocole Cisco. Ce qui appartient à Cisco, c'est HSRP, son prédécesseur propriétaire — et surtout le brevet américain 5 473 599, « Standby Router Protocol », délivré le 5 décembre 1995, dont la RFC 2281^[2] précise noir sur blanc qu'il « peut s'appliquer ».

C'est ce brevet qui a poussé le projet OpenBSD à concevoir CARP : une implémentation libre, sous licence BSD, pensée pour ne dépendre d'aucune de ces revendications.

Ce brevet a expiré depuis longtemps — il datait de 1995. Le choix entre les deux ne se fait donc plus sur la licence, mais sur le système : keepalived sous Linux, CARP sous BSD, parce que chacun est natif chez lui. L'histoire explique l'existence des deux ; elle ne décide plus rien aujourd'hui.

Sans hyperviseur, ça marche aussi

On associe souvent la haute disponibilité à la virtualisation, mais ce montage lui est antérieur et reste parfaitement valable sur du matériel nu : deux serveurs physiques, une adresse partagée, et la perte de l'un fait passer l'adresse sur l'autre en une à trois secondes. Ce niveau absorbe donc bien la panne matérielle — ce qui le distingue du niveau 1 n'est pas la nature de la panne, mais le fait qu'on surveille ici le service et non la machine.

2. Heartbeat : figé, mais toujours là

Si vous cherchez de la documentation sur la haute disponibilité sous Linux, vous tomberez inévitablement sur Heartbeat. C'était le premier gestionnaire du genre, au sein du projet Linux-HA, et il a équipé énormément d'infrastructures dans les années 2000. On en trouve encore en production.

Le projet est figé, pas effacé — et la nuance compte. La dernière version amont, 3.0.6, a une décennie, et le site historique du projet (linux-ha.org) ne répond plus. Debian, en revanche, l'empaquette toujours : 3.0.6-17 dans Trixie. Vous pouvez donc parfaitement l'installer aujourd'hui — mais vous installeriez un composant que plus personne ne fait évoluer. Le développement a migré vers ClusterLabs^[3], qui porte Pacemaker et Corosync, et c'est cette pile qui est documentée et maintenue. (Vérifié le 22 août 2026.)

Ce qu'on fait quand on en trouve un

La migration n'est pas mécanique, et c'est l'occasion de simplifier. On regarde ce que la configuration existante gérait réellement : dans la grande majorité des cas, il ne s'agissait que de déplacer une adresse et de vérifier qu'un démon répondait — keepalived fait cela avec dix fois moins de pièces. Quand il y avait vraiment un ordonnancement de ressources, on va vers Pacemaker. Reprendre à l'identique une configuration Heartbeat de quinze ans dans un outil moderne serait le pire des deux mondes.

3. keepalived : simple, rapide, limité

keepalived^[4] fait une chose et la fait bien : déplacer une adresse IP entre deux nœuds, en une à trois secondes. C'est ce qu'on déploie devant un répartiteur de charge, un serveur web, un pare-feu ou un résolveur interne — partout où il n'y a qu'une adresse à faire suivre.

Une configuration minimale qui fonctionne

Voici l'essentiel de ce que nous posons sur le nœud principal. Le second est identique, à deux valeurs près : state BACKUP et une priority plus basse.

vrrp_script chk_service {
    script   "/usr/bin/curl -sf http://localhost/health"
    interval 2        # on teste toutes les 2 s
    timeout  1        # au-delà d'1 s, le test est considéré en échec
    fall     2        # 2 échecs consécutifs = service KO
    rise     2        # 2 succès consécutifs avant de se déclarer OK
    weight  -20       # en cas d'échec, on baisse sa propre priorité
}

vrrp_instance VI_SERVICE {
    state           MASTER
    interface       eth0
    virtual_router_id 51      # identique sur les 2 nœuds, unique sur le réseau
    priority        150       # 100 sur le second nœud
    advert_int      1

    authentication {
        auth_type PASS
        auth_pass changez-moi
    }

    virtual_ipaddress {
        192.0.2.10/24 dev eth0
    }

    track_script {
        chk_service
    }
}

Avec ces valeurs, la bascule intervient en trois à cinq secondes : deux tests échoués, puis la perte de priorité qui fait passer la main. On peut descendre plus bas, au prix d'une sensibilité accrue aux micro-coupures — un arbitrage que nous réglons service par service.

Le bloc qui change tout : `vrrp_script`

Sans ce bloc, keepalived ne surveille que lui-même. Le nœud garde l'adresse tant que son démon keepalived tourne — même si le service qu'il est censé rendre est mort depuis une heure. C'est l'erreur de configuration la plus fréquente que nous trouvions, et elle est particulièrement traître : le cluster paraît fonctionner, la bascule marche quand on éteint la machine pour tester, et elle ne se déclenche jamais quand c'est le service qui tombe. « Le nœud est vivant » et « le service répond » sont deux questions différentes.

Ce qu'il ne fait pas

• Ordonner des ressources. Si un volume doit être monté avant qu'un service démarre, keepalived ne le sait pas et n'a aucun moyen de l'apprendre.
• Isoler un nœud douteux. Il déplace une adresse ; il ne garantit pas que l'ancien porteur a cessé de travailler.
• Migrer un état. Les sessions en cours sur le nœud perdu sont perdues, sauf si l'applicatif lui-même sait les partager.

4. Le cas du pare-feu d'entrée de réseau

C'est un usage de keepalived qu'on oublie souvent en pensant haute disponibilité applicative. Deux pare-feu, une adresse virtuelle par patte : celle du réseau interne est la passerelle des postes, celle côté public porte l'adresse joignable de l'extérieur. Le réseau ignore qu'il y a deux machines.

Le piège : la bascule tue les sessions

Un pare-feu garde en mémoire l'état de chaque connexion qui le traverse. Si cette table n'est pas répliquée sur le second nœud, celui-ci prend la main avec une mémoire vide : toutes les connexions établies, toutes les traductions d'adresses, tous les tunnels VPN sont considérés comme inconnus et rejetés. Le pare-feu bascule en deux secondes et les utilisateurs redémarrent quand même tout.

La réponse porte deux noms selon le système. Sous Linux, c'est conntrackd, qui réplique la table de connexions entre les deux nœuds. Sous BSD, c'est pfsync, et le couple CARP + pfsync est probablement le montage de pare-feu redondant le plus éprouvé qui soit : l'un porte l'adresse, l'autre synchronise l'état des connexions, les deux sont intégrés au système et pensés ensemble depuis le départ.

Le sujet mérite mieux que ces quelques lignes — synchronisation des règles, tunnels, tests de bascule qui vérifient la survie des sessions longues et pas seulement le ping. Nous lui consacrerons une page dédiée. Un point d'attention immédiat en attendant : chez un hébergeur, l'adresse publique ne se déplace pas comme sur un réseau qu'on possède, et la méthode dépend entièrement du fournisseur.

5. Pacemaker + Corosync : le gestionnaire de ressources

Quand il ne s'agit plus de déplacer une adresse mais d'orchestrer un ensemble, Pacemaker^[5] prend le relais. La répartition des rôles entre les deux composants est simple, et la retenir évite beaucoup de confusions :

Corosync répond à « qui est vivant »

Il maintient la liste des membres joignables et calcule qui détient la majorité. Il ne sait rien des services : c'est un bus d'appartenance, rien de plus.

Pacemaker répond à « qui fait quoi »

À partir de cette liste, il décide où chaque ressource doit tourner, dans quel ordre les démarrer, et ce qu'il faut faire quand l'une d'elles échoue.

Ce qu'il apporte réellement

• Des agents de ressource : chaque service est piloté par un script normalisé qui sait le démarrer, l'arrêter et surtout vérifier son état.
• Des contraintes d'ordre : monter le volume, puis démarrer la base, puis activer l'adresse — dans cet ordre, et en sens inverse à l'arrêt.
• Des contraintes de colocation : telle ressource doit tourner là où telle autre tourne, ou au contraire jamais au même endroit.

STONITH : un cluster sans isolation n'est pas un cluster

Avant de démarrer une ressource ailleurs, il faut la certitude qu'elle ne tourne plus là où elle était. Pas une forte présomption : une certitude. C'est le rôle de l'isolation — couper l'alimentation du nœud douteux, ou le retirer de force du réseau et du stockage. Sans elle, un nœud simplement injoignable continue d'écrire pendant que son remplaçant écrit aussi, et deux processus corrompent les mêmes données en croyant chacun être seul. Beaucoup de clusters sont livrés avec cette fonction désactivée parce qu'elle complique les tests. Un cluster sans isolation n'est pas un cluster, c'est un pari.

6. Le split-brain à deux nœuds, et les trois façons d'en sortir

Deux nœuds, un lien coupé, aucune machine morte. Chacun constate que l'autre ne répond plus et en tire la même conclusion : « je suis le survivant, je prends la main ». Les deux activent l'adresse partagée. Si des données sont en jeu, les deux écrivent. Le service peut sembler fonctionner pendant que les données divergent — et le dégât n'est constaté qu'après.

Le problème est structurel : à deux, aucune majorité n'existe. Mais avant de conclure qu'il faut toujours un arbitre, il faut poser la seule question qui décide vraiment.

Le split-brain n'a pas le même prix selon qu'il y a des données ou non

Sans état : deux nœuds suffisent très bien

Proxy sortant, résolveur DNS, NTP, relais syslog, pare-feu sans suivi de session. Le pire cas est que les deux nœuds portent l'adresse en même temps pendant quelques secondes : le réseau s'en accommode mal, des réponses peuvent se dupliquer, mais rien n'est détruit et la situation se résorbe d'elle-même dès que le lien revient. Un cluster à deux nœuds est ici parfaitement raisonnable, et c'est ce que nous déployons le plus souvent.

Avec des données : il faut un troisième point de vue

Deux instances écrivent en parallèle, chacune persuadée d'être seule, et les deux jeux divergent. Rien n'alerte, le service répond parfaitement, et la réparation ne consiste pas à redémarrer quoi que ce soit : elle consiste à choisir quelle version on jette. C'est là, et seulement là, qu'un arbitre indépendant devient indispensable.

Quand un arbitre est nécessaire, trois mécanismes le fournissent.

Un témoin

Une troisième voix, hébergée sur une petite machine qui ne porte aucune charge. Elle ne fait que voter, et ce vote suffit à créer une majorité. C'est la solution la moins chère et celle que nous privilégions.

L'isolation par la force

Le premier qui réussit à éteindre l'autre a gagné, et il le sait. Efficace et sans ambiguïté, mais suppose un chemin de contrôle indépendant du réseau en panne — sinon les deux échouent en même temps.

Un troisième nœud

La solution la plus robuste, et la plus chère : trois membres actifs, une majorité toujours calculable. C'est ce qu'on fait quand le service se prête à trois instances.

Ce que nous refusons de faire : livrer un cluster à deux nœuds portant des données sans aucun de ces trois mécanismes. Il fonctionnera parfaitement en démonstration, passera tous les tests d'extinction de machine, et échouera exactement le jour où le réseau se coupera au mauvais endroit — en silence, ce qui est le pire.

7. Tableau de choix

La question qui départage les deux outils tient en une phrase : combien de choses doivent bouger ensemble ? Une seule adresse et un service à tester : keepalived. Un ensemble ordonné : Pacemaker.

Votre service	Ce que nous déployons	Pourquoi
Répartiteur de charge, serveur web	keepalived	Sans état, une seule adresse à faire suivre
Pare-feu, passerelle	keepalived + conntrackd (Linux) CARP + pfsync (BSD)	Deux adresses, plus la table de connexions à répliquer
Résolveur DNS, NTP interne	keepalived, ou plusieurs instances	Le protocole sait souvent gérer plusieurs sources lui-même
Service avec volume partagé	Pacemaker + Corosync	Ordre de démarrage et isolation indispensables
Plusieurs services liés entre eux	Pacemaker + Corosync	Contraintes d'ordre et de colocation
Base de données	Réplication du moteur	Le problème est la fraîcheur des données, pas l'adresse — voir §9

8. Plusieurs VIP et RR DNS : la répartition de charge à l'ancienne

Sur un cluster de deux ou trois nœuds, il existe un montage que nous déployons souvent et dont on parle peu. Au lieu d'une seule adresse flottante, on en déclare deux ou trois — avec des priorités croisées, chaque nœud portant la sienne en fonctionnement nominal — et on publie l'ensemble dans un même enregistrement DNS. Le client tire au sort.

Ce qu'on obtient gratuitement

• Une répartition approximative de la charge
• Si un nœud tombe, sa VIP migre chez un survivant : pas de trou de service, juste un déséquilibre
• Aucun composant central — donc aucun nouveau point de panne. Un répartiteur dédié est lui-même à redonder, pas ce montage.

Ce qu'il faut savoir avant

• Le DNS ne fait aucun test applicatif — d'où l'importance du vrrp_script du §3
• Le cache client et la durée de vie des enregistrements retardent toute correction
• La répartition n'est pas pondérée : un gros serveur reçoit autant qu'un petit
• Certains résolveurs et clients ne font pas de rotation du tout

C'est suffisant pour deux ou trois nœuds, un trafic interne ou modéré, un service idempotent et sans session collante. Au-delà, il faut un vrai répartiteur — en couche 4 avec IPVS, que keepalived sait d'ailleurs piloter nativement, ou en couche 7 avec HAProxy pour router selon l'URL et tester réellement la santé applicative : voir les 5 niveaux de répartition de charge.

9. Le cas des bases de données

Ni keepalived ni Pacemaker ne résolvent le problème d'une base de données, parce que le problème n'est pas de déplacer une adresse. Il est de garantir que le nœud qui prend la main détient bien les données à jour. Faire pointer une adresse vers un réplica en retard ne rend pas le service disponible : cela publie des données périmées, ce qui est souvent pire qu'une interruption franche.

La disponibilité se joue donc au niveau du moteur : soit une réplication synchrone où une transaction n'est validée que lorsque plusieurs nœuds l'ont acceptée, soit un orchestrateur qui surveille l'état de la réplication et ne promeut un nœud que s'il est réellement à jour. La bascule réseau vient après, et seulement après.

C'est un domaine à part entière, avec ses propres compromis entre latence d'écriture et garantie de cohérence. Nous le traitons sur notre site dédié : cluster Galera pour la réplication synchrone multi-maître, et replication-manager pour l'orchestration de la bascule.

10. Ce que ça coûte à exploiter

Un cluster double la surface de maintenance : deux systèmes à mettre à jour, deux configurations à garder identiques, et un mécanisme de bascule qui doit rester fonctionnel entre les deux. La partie coûteuse n'est pas l'installation, elle est là.

• Les mises à jour se font nœud par nœud, avec une bascule volontaire entre les deux. C'est l'occasion idéale de vérifier que la bascule fonctionne — encore faut-il l'utiliser comme telle plutôt que de la subir.
• Les configurations divergent silencieusement. Un réglage appliqué en urgence sur un seul nœud transforme la bascule en surprise : le service redémarre ailleurs, mais pas avec les mêmes paramètres.
• Le test de bascule doit être provoqué. Un basculement qu'on n'a jamais déclenché volontairement est une hypothèse. Nous les planifions et nous mesurons le temps réel obtenu, qui est la seule valeur qui compte.

Tout cela relève de l'exploitation courante, incluse dans nos forfaits d'infogérance — à partir de 150 € HT par mois et par serveur, dégressif dès le deuxième nœud d'un même cluster — avec l'astreinte 24/7 pour ce que l'automatisme ne sait pas traiter.

Questions fréquentes

Keepalived ou Pacemaker : lequel choisir ?

La question à se poser n'est pas laquelle est la meilleure, mais combien de choses doivent bouger ensemble. S'il n'y a qu'une adresse IP à déplacer et un service à surveiller, keepalived suffit et c'est le bon choix : moins de pièces, moins de pannes possibles. Dès qu'il faut ordonner plusieurs ressources, garantir qu'un système de fichiers est monté avant qu'un service démarre, ou isoler un nœud défaillant par la force, Pacemaker devient nécessaire. Le coût de Pacemaker n'est pas dans son installation, il est dans son exploitation.

Peut-on faire un cluster à deux nœuds seulement ?

Oui, et la réponse dépend entièrement de ce que le cluster porte. Pour un service sans état — proxy, résolveur DNS, NTP, relais — deux nœuds suffisent très bien : si le lien se coupe et que les deux se croient légitimes, le pire cas est une adresse portée en double quelques secondes, gênant mais non destructeur. Dès qu'il y a des données, c'est autre chose : deux instances écriraient en parallèle et les jeux divergeraient en silence. Il faut alors un troisième point de vue — un témoin léger qui ne fait que voter, ou un mécanisme d'isolation^[6] qui tranche par la force.

Un cluster keepalived protège-t-il d'une panne matérielle ?

Oui, à condition que les deux nœuds soient sur du matériel distinct. C'est même le cas d'usage historique, antérieur à la virtualisation : deux serveurs physiques, une adresse partagée, et la perte de l'un fait passer l'adresse sur l'autre en une à trois secondes. Ce qui distingue ce niveau de la haute disponibilité d'hyperviseur n'est donc pas la nature de la panne mais la granularité de la surveillance : ici c'est le service qui est observé, pas la machine.

Qu'est-ce qu'un split-brain, concrètement ?

C'est la situation où deux membres d'un cluster se croient simultanément légitimes. Elle survient quand le réseau les sépare sans qu'aucun ne tombe : chacun constate que l'autre ne répond plus et en conclut qu'il doit prendre la main. Les deux activent alors l'adresse partagée, ou pire, montent le même volume de données et écrivent dessus en parallèle. Le service peut sembler fonctionner pendant que les données divergent silencieusement, et c'est ce qui rend le scénario si coûteux : le dégât n'est constaté qu'après.

Heartbeat est-il encore utilisé en 2026 ?

Oui, dans des systèmes historiques — mais ce n'est plus un choix que nous conseillons pour un nouveau déploiement. Heartbeat a été le premier gestionnaire de haute disponibilité sous Linux, au sein du projet Linux-HA. Sa dernière version amont, 3.0.6, a une décennie, et le site du projet ne répond plus ; Debian l'empaquette pourtant encore, ce qui explique qu'on en croise toujours. Le développement, lui, a migré vers ClusterLabs, qui porte Pacemaker et Corosync. Quand nous en trouvons un en production, nous remappons ce qu'il gérait vers keepalived ou vers Pacemaker selon la complexité réelle.

Et pour une base de données MariaDB ou PostgreSQL ?

Ni keepalived ni Pacemaker seuls ne suffisent, parce que le problème n'est plus de déplacer une adresse mais de garantir que les données sont à jour sur le nœud qui prend la main. Déplacer la VIP vers un réplica en retard revient à publier des données périmées. Il faut donc une réplication au niveau du moteur, synchrone ou orchestrée, et c'est elle qui décide qui peut devenir maître. La bascule réseau vient ensuite, et seulement ensuite.

Un cluster Pacemaker peut-il s'étendre sur deux sites ?

C'est possible mais rarement souhaitable. Un cluster suppose des échanges fréquents et une décision rapide ; entre deux sites, la latence rend la détection moins fiable et une coupure du lien inter-site provoque exactement le scénario de partition que le quorum a du mal à trancher. Pour couvrir la perte d'un site, on change généralement de logique : plutôt qu'étirer un cluster, on répartit des instances indépendantes et on laisse le routage ou le DNS diriger le trafic vers celles qui répondent.

Votre cluster bascule-t-il quand le service tombe, ou seulement quand la machine s'éteint ?

C'est la première chose que nous vérifions sur un cluster existant. La réponse est plus souvent « seulement quand la machine s'éteint » qu'on ne le voudrait.

Demander un audit

À ne pas confondre : deux Corosync différents

Sommaire