HAProxy comme répartiteur de charge TCP/HTTP sous Linux : test de configuration, rechargement sans coupure et health checks

Objectif

Placer HAProxy devant un ensemble de serveurs backend, vérifier une nouvelle configuration avant qu'elle ne reçoive du trafic, recharger sans interrompre les connexions, et faire en sorte que HAProxy cesse d'envoyer du trafic vers un backend défaillant.

Prérequis

HAProxy installé ; au moins deux serveurs ou ports backend sur lesquels répartir la charge ; le fichier de configuration existant sauvegardé avant toute modification.

Étapes

1. Définir un frontend qui écoute sur l'adresse et le port publics, et un backend qui liste les serveurs, chaque ligne de serveur se terminant par check pour activer les health checks. L'option check active les health checks sur un serveur ; sans autre paramétrage, HAProxy considère un serveur comme disponible lorsqu'il peut établir une connexion à la couche de transport la plus haute configurée, et le retire de la rotation en cas d'échec. Pour une vérification au niveau HTTP, ajouter option httpchk au backend (à partir de la version 2.2, http-check send meth GET uri /health et http-check expect status 200 permettent de l'affiner).
2. Avant de recharger, valider le fichier : haproxy -c -f /etc/haproxy/haproxy.cfg. L'option -c se contente de vérifier les fichiers de configuration et s'arrête avant toute tentative de liaison aux ports, avec un code de sortie non nul en cas d'erreur ; on peut donc l'exécuter sans risque sur une configuration qui n'est pas encore en production.
3. Recharger sans coupure de connexion : systemctl reload haproxy (en root). Les unités fournies par les paquets lancent HAProxy en mode master-worker (-Ws) ; le rechargement envoie un signal au master, qui tente de charger sans interruption la nouvelle configuration dans de nouveaux processus worker, tandis que les anciens workers terminent leurs connexions en cours avant de s'arrêter. La plupart des unités fournies par les paquets exécutent d'abord la vérification -c et conservent les anciens workers si elle échoue.
4. Uniquement si HAProxy est lancé manuellement, sans le mode master-worker : démarrer le nouveau processus avec -sf <pid>..., afin qu'il envoie le signal de fin (SIGUSR1) aux anciens processus une fois le démarrage terminé, leur demandant d'achever leur travail en cours puis de quitter.
5. Ajuster si nécessaire les délais des health checks pour chaque serveur (inter, fall, rise ; valeurs par défaut : 2 s, 3 et 2) selon la rapidité avec laquelle un backend défaillant doit être retiré, puis réintégré.
6. Observer l'état à l'exécution après chaque modification : la socket de statistiques ou la page de statistiques indique l'état de vérification de chaque serveur (UP/DOWN), ce qui rend l'effet d'un rechargement sur la santé des backends immédiatement visible.

Résultat attendu

haproxy -c -f <file> retourne le code 0 avant même que l'instance en cours ne soit rechargée ; un rechargement ne laisse apparaître aucune connexion client interrompue dans le journal d'accès ; l'arrêt d'un processus backend fait passer son état à DOWN dans la sortie des statistiques dans l'intervalle de vérification configuré, et le trafic n'est plus dirigé vers lui.

Limites et base de vérification

-c valide la syntaxe et la cohérence interne, mais pas l'accessibilité des adresses backend : une configuration peut passer -c et pourtant n'envoyer le trafic nulle part si l'adresse ou le port d'un backend est erroné. Le rechargement en douceur maintient les anciennes connexions ouvertes sur le processus sortant, mais ne les fait pas migrer vers la nouvelle configuration ; un client dont la requête est en cours pendant le rechargement la termine selon les anciennes règles. Il faut conserver le dernier fichier de configuration valide connu pour pouvoir revenir rapidement en arrière si un nouveau fichier passe -c mais se comporte mal une fois en production.