> ## Content Index
> Fetch the complete content index at: https://0ctet.fr/llms.txt
> Use this file to discover other available public pages before exploring further.

# Déployer la haute disponibilité sans cloud public : HAProxy et Keepalived sur Bare Metal
- URL: https://0ctet.fr/deployer-la-haute-disponibilite-sans-cloud-public-haproxy-et-keepalived-sur-bare-metal/
- Published: 2026-10-29T15:00:34.000Z
- Updated: 2026-10-29T15:00:34.000Z
- Description: Éliminer le Single Point of Failure sans cloud public : configuration pas à pas de HAProxy et Keepalived avec IP flottante VRRP sur Bare Metal.
- Author: Mathis Nounni
- Tags: Hardware, #tribune

### **1\. Le problème : le point de défaillance unique du répartiteur de charge**

Dans une architecture applicative moderne, la répartition de charge (*load balancing*) est la pierre angulaire des performances et de la tolérance aux pannes. Qu'il s'agisse d'acheminer du trafic web HTTP/HTTPS ou de distribuer des requêtes vers un groupe de bases de données, l'utilisation d'un répartiteur de charge comme HAProxy permet d'absorber les pics de charge et de masquer les opérations de maintenance sur les serveurs applicatifs.

Cependant, l'introduction d'un répartiteur de charge unique crée un problème architectural classique : un point de défaillance unique (*Single Point of Failure* ou SPOF). Si le serveur physique ou la machine virtuelle hébergeant HAProxy subit une panne matérielle, un défaut de carte réseau ou un plantage du système d'exploitation, l'intégralité des services applicatifs devient inaccessible, quelle que soit la redondance des serveurs situés en aval.

Sur les infrastructures de cloud public (AWS, Google Cloud, Azure), ce problème est généralement masqué par des services managés comme les *Elastic Load Balancers*, qui s'appuient sur des IP virtuelles réassignables via des API internes. Mais sur une infrastructure auto-hébergée (*Bare Metal*) chez des hébergeurs comme OVH, Hetzner, Scaleway Dedibox ou au sein d'un centre de données privé, ces mécanismes d'API propriétaires n'existent pas ou imposent des coûts récurrents élevés.

Pour garantir une disponibilité de 99,99 % sur du matériel dédié sans dépendre d'un fournisseur cloud, il est nécessaire de mettre en œuvre une solution de basculement au niveau de la couche réseau. L'association de HAProxy et de Keepalived sur une paire de serveurs Bare Metal constitue la réponse standard, éprouvée et extrêmement performante à ce défi.

---

### **2\. La solution étape par étape : configurer une architecture actif/passif avec IP flottante**

L'architecture repose sur deux serveurs répartiteurs de charge (nommés par exemple lb01 et lb02) partageant une adresse IP virtuelle (VIP) flottante. Un seul serveur à la fois détient l'adresse IP virtuelle et traite le trafic entrant (mode MASTER), tandis que le second reste en attente passive (mode BACKUP).

#### **Étape 1 : Activer le liage d'IP non locale dans le noyau Linux**

Par défaut, le système d'exploitation Linux interdit à un service applicatif de s'associer (*bind*) à une adresse IP qui n'est pas physiquement configurée sur l'une de ses interfaces réseau locales. Sur le serveur secondaire (BACKUP), l'adresse IP virtuelle n'étant pas encore active, HAProxy refuserait de démarrer.

Pour résoudre ce blocage, activez le paramètre noyau net.ipv4.ip\_nonlocal\_bind sur les deux nœuds en modifiant le fichier /etc/sysctl.conf :

| \# Autoriser le liage sur une IP virtuelle non localeecho "net.ipv4.ip\_nonlocal\_bind = 1" >> /etc/sysctl.confsysctl -p |
| ------------------------------------------------------------------------------------------------------------------------ |

Ce réglage permet au service HAProxy de démarrer et d'écouter sur l'IP virtuelle sur les deux serveurs simultanément, garantissant un basculement instantané sans attente de démarrage de service.

#### **Étape 2 : Configurer HAProxy sur les deux nœuds**

Installez HAProxy sur les deux serveurs. Les fichiers de configuration /etc/haproxy/haproxy.cfg doivent être rigoureusement identiques sur lb01 et lb02, à l'exception éventuelle des identifiants de nœud.

| global log /dev/log local0 user haproxy group haproxy daemondefaults log global mode http option httplog timeout connect 5s timeout client 50s timeout server 50sfrontend web\_frontend bind 192.168.1.100:80 default\_backend web\_serversbackend web\_servers balance roundrobin server app01 192.168.1.11:80 check server app02 192.168.1.12:80 check |
| -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |

Dans cet exemple, 192.168.1.100 représente l'adresse IP virtuelle (VIP) partagée.

#### **Étape 3 : Installer et configurer Keepalived pour le protocole VRRP**

Keepalived implémente le protocole VRRP (Virtual Router Redundancy Protocol). Il émet des paquets multicast réguliers pour vérifier la présence du nœud principal.

Installez Keepalived sur les deux serveurs (apt install keepalived).

Sur le premier nœud (lb01, serveur principal), éditez /etc/keepalived/keepalived.conf :

| vrrp\_script chk\_haproxy { script "killall -0 haproxy" interval 2 weight 2}vrrp\_instance VI\_1 { state MASTER interface eth0 virtual\_router\_id 51 priority 101 advert\_int 1 authentication { auth\_type PASS auth\_pass Securite123! } virtual\_ipaddress { 192.168.1.100/24 } track\_script { chk\_haproxy }} |
| ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |

Sur le second nœud (lb02, serveur de secours), configurez le fichier /etc/keepalived/keepalived.conf avec une priorité inférieure :

| vrrp\_script chk\_haproxy { script "killall -0 haproxy" interval 2 weight 2}vrrp\_instance VI\_1 { state BACKUP interface eth0 virtual\_router\_id 51 priority 100 advert\_int 1 authentication { auth\_type PASS auth\_pass Securite123! } virtual\_ipaddress { 192.168.1.100/24 } track\_script { chk\_haproxy }} |
| ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |

#### **Étape 4 : Démarrer les services et valider le basculement**

Lancez les services HAProxy et Keepalived sur les deux nœuds. Le serveur lb01 attribue l'IP 192.168.1.100 à son interface réseau. Pour tester la haute disponibilité, simulez une panne sur lb01 en arrêtant le service HAProxy ou en coupant l'interface réseau :

| systemctl stop haproxy |
| ---------------------- |

En moins de deux secondes, Keepalived sur lb02 détecte la baisse de priorité du maître, prend la main et émet un paquet Gratuitous ARP pour réassigner l'IP virtuelle. Le trafic bascule de manière transparente pour les utilisateurs.

---

### **3\. Les pièges à éviter : du Split-Brain au blocage des paquets VRRP**

Bien que l'architecture Keepalived soit éprouvée, plusieurs erreurs de configuration courantes peuvent compromettre la stabilité de la haute disponibilité.

#### **Le phénomène de Split-Brain (double maître)**

Le risque majeur d'une configuration VRRP est le *Split-Brain*. Ce phénomène se produit lorsque les deux serveurs ne parviennent plus à communiquer entre eux via le réseau local. Ne recevant plus d'annonces du nœud MASTER, le nœud BACKUP estime que le maître est hors ligne et attribue lui aussi l'IP virtuelle à son interface. Les deux serveurs revendiquent alors simultanément la même adresse IP, provoquant des conflits d'adresses MAC et une perte massive de paquets.

Pour éviter le Split-Brain, assurez-vous que le trafic multicast (adresse 224.0.0.18 et protocole IP 112) est explicitement autorisé sur votre pare-feu local (UFW ou nftables).

#### **Ne pas surveiller l'état réel de HAProxy**

Configurer Keepalived sans le bloc vrrp\_script est une erreur fréquente. Si seul l'état du serveur physique est surveillé, un plantage isolé du processus HAProxy n'entraînera aucun basculement d'IP. Le serveur restera MASTER et continuera de recevoir le trafic réseau, mais renverra des erreurs de connexion à tous les clients. Le script de vérification (chk\_haproxy) est donc indispensable.

#### **Utiliser le même virtual\_router\_id sur un réseau partagé**

Si plusieurs paires de serveurs Keepalived coexistent sur le même réseau local (VLAN), elles doivent obligatoirement utiliser des valeurs de virtual\_router\_id distinctes (de 1 à 255). Deux clusters partageant le même identifiant interfèreront dans leurs élections VRRP.

---

### **4\. Pour aller plus loin : unicast VRRP, synchronisation d'état et double VIP actif/actif**

Pour pousser l'architecture encore plus loin et adapter la solution à des contraintes réseau complexes, plusieurs améliorations peuvent être apportées.

#### **Passer en VRRP Unicast pour les réseaux restreints**

Certains environnements réseau ou commutateurs virtuels d'hébergeurs interdisent le trafic multicast. Dans ce cas, Keepalived peut être configuré en mode Unicast point-à-point en ajoutant les directives unicast\_src\_ip et unicast\_peer dans le bloc d'instance VRRP.

#### **Implémenter une configuration actif/actif avec double IP virtuelle**

Au lieu de laisser le serveur BACKUP inactif en consommant des ressources pour rien, il est possible de configurer deux instances VRRP croisées (VI\_1 et VI\_2) associées à deux adresses IP virtuelles distinctes. Le serveur lb01 est MASTER sur la première IP, tandis que lb02 est MASTER sur la seconde. En répartissant vos enregistrements DNS (Round-Robin DNS) sur les deux IP, vous utilisez 100 % de la capacité de vos deux serveurs en temps normal, tout en conservant le basculement automatique en cas de panne.

#### **Synchroniser les tables de sessions avec stick-tables**

Par défaut, lors d'un basculement d'IP, les connexions TCP actives et les sessions utilisateurs stockées en mémoire sur le premier HAProxy sont perdues. L'utilisation des *stick-tables* répliquées de HAProxy permet de synchroniser les états de session en temps réel entre les deux nœuds via un canal d'échange dédié, garantissant une persistance parfaite pour les utilisateurs finaux.

En combinant ces bonnes pratiques, vous disposez d'une infrastructure de répartition de charge de classe industrielle, hautement disponible et entièrement affranchie des contraintes des clouds propriétaires.

---

### **Sources :**

1. **HAProxy Documentation** — [*Configure two HAProxy Enterprise servers for active/standby clustering*](https://www.haproxy.com/documentation/haproxy-enterprise/administration/high-availability/active-standby/?ref=0ctet.fr)
2. **OSTechNix** — [*Build a 99.99% Uptime Stack with Keepalived, HAProxy, and NGINX*](https://ostechnix.com/keepalived-haproxy-nginx-high-availability-ubuntu/?ref=0ctet.fr)
3. **System Developer** — [*Setting Up VRRP and Keepalived for Load Balancer Redundancy with HAProxy*](https://www.systemdeveloper.nl/tech/setting-up-vrrp-and-keepalived-for-load-balancer-redundancy-with-haproxy/?ref=0ctet.fr)
4. **Broadcom TechDocs** — [*Advanced Configuration: HAProxy with Keepalived*](https://techdocs.broadcom.com/us/en/vmware-cis/aria/aria-operations/8-18/vmware-aria-operations-load-balancing-guide-8-18-/haproxy-installation-and-configuration/advanced-configuration-haproxy-with-keepalived.html?ref=0ctet.fr)
5. **MangoHost** — [*Setting Up Highly Available HAProxy Servers with Keepalived on Ubuntu 24*](https://mangohost.net/blog/setting-up-highly-available-haproxy-servers-with-keepalived-and-reserved-ips-on-ubuntu-24/?ref=0ctet.fr)