Un load balancer qui tombe, c'est tout le trafic web de l'entreprise qui s'arrête d'un coup. La haute disponibilité HAProxy sert exactement à éviter ce scénario et c'est pourtant souvent la brique la moins redondée de toute l'infrastructure, celle qu'on installe vite pour répartir la charge et qu'on oublie de doubler.
Le problème ou le contexte
Prenons un environnement multi-services assez classique : un frontal HAProxy qui route le trafic HTTPS vers plusieurs applications métier, site de paiement, un intranet, une application RH, quelques services web internes. Tout ce trafic passe par une seule machine.
Le jour où cette machine tombe, c'est l'accès à tous les services qui disparaît en même temps, pendant que les équipes tentent de comprendre ce qui se passe. Sur ce genre d'infrastructure, doubler les serveurs applicatifs n'est pas utile si le load balancer placé devant eux reste, lui, un point de défaillance unique (SPOF) c'est exactement le genre d'angle mort qu'on traite en amont d'un projet infrastructure bien pensé.
Ce que nous conseillons
Pour palier à ce risque, la mise en place d'un cluster de deux load balancers : un actif, un passif, avec bascule automatique si le premier noeud tombe est essentiel. Techniquement, plusieurs possibilité, du heartbeat, du keepalived ou encore du VRRP.
Dans notre cas c'est heartbeat, cela permet d'avoir une adresse IP flottante (la VIP) partagée entre les deux nœuds. Le nœud actif la porte ; s'il ne répond plus, le nœud passif la reprend, et avec elle le service HAProxy.
Le détail qui change tout, c'est le réseau utilisé pour ce dialogue entre les deux nœuds. De nombreuse setups font transiter les paquets Heartbeat sur le réseau de production classique. Le risque de tout ca ?
Au début peu de risque car peu de service transite par le LB, mais au fur et à mesure le réseau se charge car les services qui passent par les loadbalancer croient.
La surchage peut faire croire à un nœud que son voisin est mort alors qu'il répond juste plus lentement et provoquer une bascule pour rien. Une fois, deux fois puis tellement régulièrement que les pages prennent du temps à charger.
La bonne pratique, c'est d'isoler ce dialogue sur un lien dédié, point à point entre les deux machines. Un vrai câble croisé virtuel, sans autre trafic dessus.
Deuxième détail qu'on néglige souvent : la façon de vérifier qu'un serveur backend est vivant. Un simple check TCP vérifie que le port répond. C'est un peu comme vérifier qu'une porte est fermée à clé sans savoir si quelqu'un se trouve derrière.
Un health check applicatif HTTP, qui interroge une route dédiée et vérifie le code retour, détecte un serveur qui répond au réseau mais qui plante en interne. C'est la différence entre « le service tourne » et « le service tourne vraiment ».
Concrètement, ça donne : 𝚘𝚙𝚝𝚒𝚘𝚗 𝚑𝚝𝚝𝚙𝚌𝚑𝚔 𝙶𝙴𝚃 /𝚑𝚎𝚊𝚕𝚝𝚑.𝚙𝚑𝚙 puis 𝚑𝚝𝚝𝚙-𝚌𝚑𝚎𝚌𝚔 𝚎𝚡𝚙𝚎𝚌𝚝 𝚜𝚝𝚊𝚝𝚞𝚜 𝟸𝟶𝟶 deux lignes qui changent la nature healthcheck.
Le chiffrement mérite le même soin : profil TLS durci selon le guide Mozilla SSL Configuration, des en-tête HSTS forcés sur toutes les réponses. Un load balancer mal configuré côté TLS reste une porte d'entrée aussi sensible que n'importe quel serveur applicatif.
Pourquoi la haute disponibilité HAProxy doit vous intéresser
Pour une PME ou un service IT qui gère plusieurs applications métier critiques en internes devraient envisager la mise en place d'une infrastructure LB redondée. Un load balancer non redondé transforme n'importe quel redémarrage, mise à jour ou incident matériel en coupure de service généralisée, c'est la même logique de continuité qui vaut pour une sauvegarde mal testée : ça ne se voit pas, jusqu'au jour où on en a besoin.
Il y a un deuxième enjeu, moins visible : le jour où on passe en cluster, le debug se complique. Si une bascule a eu lieu entre-temps, il faut aller chercher les logs sur les deux nœuds pour reconstituer ce qui s'est passé. Beaucoup d'infrastructures découvrent ce problème après coup, une fois le cluster déjà en place.
La centralisation des logs, et plus largement le suivi en continu de ce genre d'infrastructure, devrait faire partie du projet dès le départ plutôt que d'être traité en maintien en condition opérationnelle dans l'urgence.
Exemple concret ou retour terrain
Sur une architecture retail multi-sites qu'on a accompagnée, le loadbalancer HAProxy encaissait le trafic HTTPS de plusieurs applications métier distinctes (paiement, intranet, services web internes), routées par nom d'hôte sur un seul frontal. Deux nœuds en production avec heartbeat, deux autres en préproduction pour valider les changements avant bascule.
Concrètement, ça commence par 𝚊𝚙𝚝-𝚐𝚎𝚝 𝚒𝚗𝚜𝚝𝚊𝚕𝚕 𝚑𝚎𝚊𝚛𝚝𝚋𝚎𝚊𝚝 puis 𝚌𝚑𝚖𝚘𝚍 𝟼𝟶𝟶 /𝚎𝚝𝚌/𝚑𝚊.𝚍/𝚊𝚞𝚝𝚑𝚔𝚎𝚢𝚜 pour verrouiller la clé partagée entre les deux nœuds. La ressource déclarée dans /etc/ha.d/haresources ressemble à ceci : 𝚕𝚋𝟶𝟸 𝙸𝙿𝚊𝚍𝚍𝚛::𝟷𝟿𝟸.𝟶.𝟸.𝟷𝟶/𝟸𝟺/𝚎𝚝𝚑𝟷 𝚑𝚊𝚙𝚛𝚘𝚡𝚢 — le nœud primaire, la VIP, l'interface dédiée et le service supervisé
Avant même de monter la deuxième machine, on a créé un réseau virtuel dédié uniquement au trafic Heartbeat, avec une interface point à point sur chaque nœud. Le TLS a été durci selon le profil « intermediate » de Mozilla, HSTS forcé sur toutes les réponses. Les health checks sont passés en HTTP applicatif plutôt qu'en simple TCP sur tous les backends critiques.
Le vrai gain, cela dit, est venu du côté logs. Les logs HAProxy, générés au format JSON structuré, sont désormais centralisés via rsyslog en flux chiffré vers une plateforme de log management managée type Graylog, avec un parsing par patterns Grok pour retrouver n'importe quelle requête, sur n'importe quel nœud, en quelques secondes. Fini les allers-retours entre les deux machines pour reconstituer un incident.
Ce qu'on recommande chez Logexia
Sur le terrain, quelques principes reviennent systématiquement quand on conçoit ce genre d'architecture. Isoler le réseau de Heartbeat dès la conception, jamais après coup ce qui évite les bascules fantômes. Préférer un health check applicatif à un simple check TCP sur tous les backends qui portent une logique métier derrière. Centraliser les logs avant que le cluster ne grossisse, pas au moment du premier incident difficile à reconstituer.
Et un point qu'on voit encore trop souvent : un mot de passe d'administration qui traîne en clair dans un fichier de configuration permettant d’accéder à la page de statistiques de HAProxy, parfois en place depuis des années. Un gestionnaire de mots de passe couplé à une restriction d'accès par IP source vaut mieux qu'un simple auth basic oublié dans une conf qu'on ne relit jamais.
Deux réflexes qui évitent bien des sueurs froides : valider la syntaxe avant tout reload avec 𝚑𝚊𝚙𝚛𝚘𝚡𝚢 -𝚌 -𝚏 /𝚎𝚝𝚌/𝚑𝚊𝚙𝚛𝚘𝚡𝚢/𝚑𝚊𝚙𝚛𝚘𝚡𝚢.𝚌𝚏𝚐, et pour sortir un serveur du pool sans repasser par l'interface web, 𝚎𝚌𝚑𝚘 "𝚜𝚎𝚝 𝚜𝚎𝚛𝚟𝚎𝚛 𝚋𝚊𝚌𝚔_𝚊𝚙𝚙/𝚊𝚙𝚙𝟷 𝚜𝚝𝚊𝚝𝚎 𝚖𝚊𝚒𝚗𝚝" | 𝚜𝚘𝚌𝚊𝚝 𝚜𝚝𝚍𝚒𝚘 /𝚟𝚊𝚛/𝚛𝚞𝚗/𝚑𝚊𝚙𝚛𝚘𝚡𝚢/𝚊𝚍𝚖𝚒𝚗.𝚜𝚘𝚌𝚔 fait exactement le même travail que le bouton « Set state to MAINT » dans la page stats de HAproxy.
Conclusion
Un load balancer haute disponibilité, ce n'est pas juste « deux serveurs au lieu d'un ». C'est un réseau de bascule isolé, et des logs qu'on peut réellement exploiter le jour où ça tourne mal. La vraie question à se poser n'est pas si votre frontal peut tomber, mais ce qui se passe concrètement le jour où il tombe.