HAProxy :
ce que « lire la requête » permet vraiment
Lire la requête débloque le routage par URL, la terminaison du chiffrement et un test de santé qui teste enfin quelque chose. En échange, on ajoute une pièce sur le chemin de chaque requête — et il faut la redonder.
Sommaire
1. Deux modes, et le choix se fait tôt
HAProxy sait fonctionner en mode TCP, où il relaie une connexion sans l'interpréter, et en mode HTTP, où il lit et comprend chaque requête. Ce n'est pas un détail de configuration : les deux modes n'offrent pas les mêmes fonctions, et changer d'avis après coup demande de reprendre la configuration.
Mode TCP
Utile pour tout ce qui n'est pas du web : une base de données, un annuaire, un service métier. On y gagne la pondération et un test de santé plus fin qu'un simple port ouvert — HAProxy sait par exemple ouvrir une session applicative pour vérifier qu'elle répond. C'est aussi le mode qui permet de répartir un flux de lecture de base de données quand l'application sépare déjà ses connexions.
Mode HTTP
Le mode qui justifie vraiment HAProxy. La requête est analysée, donc utilisable comme critère : URL, en-tête, méthode, cookie. C'est ce qui permet de router, de réécrire, de filtrer et de mesurer — au prix d'un traitement plus lourd et d'une configuration qui vit.
2. Ce que « lire la requête » débloque
- • Router selon l'URL. Un seul point d'entrée, plusieurs applications derrière :
/apivers un groupe de serveurs,/staticvers un autre. C'est la fonction la plus demandée, et elle est structurellement impossible en couche 4. - • Terminer le chiffrement à un endroit unique. Un seul jeu de certificats à renouveler au lieu d'un par machine — un gain d'exploitation qui se mesure sur la durée.
- • Réécrire et normaliser. Ajouter l'adresse réelle du client dans un en-tête, forcer une redirection, retirer un en-tête qui en dit trop sur la version du serveur.
- • Observer. HAProxy expose un état détaillé par cible : connexions, erreurs, temps de réponse. C'est souvent la première visibilité honnête qu'une équipe obtient sur son propre trafic.
3. Le test de santé qui teste vraiment
C'est la différence la plus importante avec la couche 4, et celle qui décide souvent du passage. Un test TCP vérifie qu'un port accepte les connexions. Un serveur qui renvoie une erreur sur chaque requête le passe sans difficulté, et le répartiteur continue consciencieusement de lui envoyer du trafic.
backend applicatif
balance roundrobin
option httpchk GET /health
http-check expect status 200
# le serveur est retiré après 3 échecs, réintégré après 2 succès
default-server inter 3s fall 3 rise 2
server app1 10.0.0.11:8080 check weight 100
server app2 10.0.0.12:8080 check weight 50Ce qu'il faut mettre derrière /health
Un point d'entrée qui renvoie 200 sans rien vérifier ne vaut pas mieux qu'un test de port. Un bon test de santé interroge les dépendances dont l'application a besoin pour travailler — sa base, son cache, son stockage — et échoue si l'une manque. C'est un travail applicatif de quelques lignes, et c'est lui qui donne toute sa valeur au reste. Sans lui, on a payé la couche 7 pour un test de couche 4.
4. Les sessions collantes, si vraiment
HAProxy sait poser un cookie pour qu'un client retombe toujours sur la même instance. C'est la fonction qu'on vient chercher quand une application garde l'état de la session en mémoire locale — et c'est aussi celle qu'il vaut mieux ne pas avoir à utiliser.
Ce qu'on accepte en l'activant
- • La répartition devient inégale : une instance peut concentrer les sessions longues
- • La panne d'une instance déconnecte tous ses utilisateurs alors que le service reste debout
- • Mettre à jour un nœud demande d'attendre l'expiration de ses sessions, ou de les sacrifier
Notre proposition est toujours la même en premier lieu : sortir l'état de l'application, en base ou dans un cache partagé, pour que n'importe quelle instance puisse servir n'importe quel utilisateur. C'est souvent un travail modeste, et il supprime le problème au lieu de le déplacer. Quand ce n'est pas envisageable, on met du collant — en sachant ce qu'on achète.
5. Redonder HAProxy, sinon rien n'a été gagné
C'est le point sur lequel nous ne transigeons pas. Un HAProxy unique devant six serveurs applicatifs n'améliore pas la disponibilité : il l'a même dégradée, puisque le service dépend maintenant d'une machine de plus, et que celle-là est sur le chemin de chaque requête.
Le montage standard est donc deux HAProxy et une adresse flottante, avec le test de santé qui déclenche la bascule si le processus meurt. On revient exactement au niveau 2 de nos architectures de haute disponibilité : la répartition s'appuie sur la disponibilité, elle ne la remplace pas.
Ce que nous surveillons ensuite
Un répartiteur en parfaite santé devant deux serveurs morts répond parfaitement des erreurs. Le contrôle qui compte n'est donc pas « HAProxy répond-il ? » mais « combien de cibles sont encore vivantes ? ». Nous suivons ce nombre, la répartition réelle entre les cibles, et l'écart entre ce que la configuration prévoit et ce qui se passe.
Questions fréquentes
HAProxy ou nginx pour répartir ?
Les deux savent le faire et le choix dépend surtout de ce que la machine fait par ailleurs. Si elle sert aussi des fichiers ou héberge une application, nginx évite d'ajouter un composant. Si son unique rôle est de répartir, HAProxy offre un contrôle plus fin sur les tests de santé, les files d'attente et l'observation du trafic — c'est ce pour quoi il a été conçu.
Faut-il terminer le TLS sur HAProxy ou sur les serveurs ?
Sur HAProxy dans la grande majorité des cas : un seul endroit où renouveler les certificats, et la possibilité de router selon l'URL, ce qui suppose de voir la requête en clair. On garde le chiffrement jusqu'aux serveurs quand une exigence de conformité l'impose — mais alors il faut accepter de perdre le routage par URL, ou de rechiffrer derrière.
Que se passe-t-il si toutes les cibles échouent au test de santé ?
HAProxy renvoie une erreur immédiate au lieu de faire patienter le client, ce qui est le bon comportement : mieux vaut un échec net qu'un délai d'attente. Mais cela signifie aussi qu'un test de santé trop strict peut retirer tout le monde et provoquer une panne totale à partir d'un incident partiel. Les seuils de retrait et de réintégration se règlent avec cette possibilité en tête.
Combien de trafic un HAProxy encaisse-t-il ?
Beaucoup plus que ce que la plupart des infrastructures lui envoient — le facteur limitant est presque toujours le chiffrement, pas la répartition. En pratique, la question à se poser n'est pas la capacité brute mais le comportement en cas de perte d'un des deux répartiteurs : le survivant doit encaisser la totalité, pas la moitié.
Votre répartiteur est-il seul sur le chemin ?
Un HAProxy unique devant six serveurs n'améliore pas la disponibilité, il la dégrade. Nous auditons l'existant et nous le disons franchement.
Demander un devis