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.
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).
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 nœud tombe est essentiel. Techniquement, plusieurs possibilités : 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 nombreux setups font transiter les paquets Heartbeat sur le réseau de production classique. La surcharge 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. La bonne pratique, c'est d'isoler ce dialogue sur un lien dédié, point à point entre les deux machines.
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. 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 ».
Le chiffrement mérite le même soin : profil TLS durci selon le guide Mozilla SSL Configuration, des en-têtes 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.
Une PME ou un service IT qui gère plusieurs applications métier critiques en interne devrait 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.
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é. La centralisation des logs devrait faire partie du projet dès le départ.
Sur une architecture retail multi-sites qu'on a accompagnée, le load balancer 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.
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 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 type Graylog, avec un parsing par patterns Grok pour retrouver n'importe quelle requête, sur n'importe quel nœud, en quelques secondes.
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. 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. 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.
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 n'est pas si votre frontal peut tomber, mais ce qui se passe concrètement le jour où il tombe.
