Aller au contenu
English
Cloud high

Load Balancing : répartition de charge L4, L7 et terminaison TLS

10 min de lecture

Un répartiteur de charge distribue les requêtes entre plusieurs serveurs, et c'est sa deuxième fonction qui compte le plus : retirer automatiquement de la rotation un serveur qui ne répond plus. Sans lui, un serveur en panne continue de recevoir du trafic et vos visiteurs voient une erreur. Cette page explique la différence entre répartition de niveau 4 et de niveau 7, où terminer le chiffrement, et pourquoi la sonde de santé mérite plus d'attention que l'algorithme de répartition.

  • Choisir entre une répartition de niveau 4 et de niveau 7 selon ce que vous exposez.
  • Écrire une sonde de santé qui détecte les vraies pannes et pas seulement les serveurs éteints.
  • Décider où terminer le chiffrement TLS, et ce que ce choix implique.
  • Éviter les deux pièges qui font perdre des sessions ou surcharger un serveur.
  • Chiffrer ce que coûte un répartiteur avant de le multiplier par environnement.

Les leçons sur les tables de routage et sur la sécurité réseau.

Niveau 4 ou niveau 7 : ce que le répartiteur comprend

Section intitulée « Niveau 4 ou niveau 7 : ce que le répartiteur comprend »

La différence tient à ce que le répartiteur lit dans le trafic. Au niveau 4, il voit des adresses et des ports. Au niveau 7, il lit le contenu HTTP, donc l'adresse demandée, les chemins et les en-têtes.

Niveau 4Niveau 7
Ce qu'il lit pour répartiradresse IP, portadresse demandée, chemin, en-têtes, cookies
Peut router selon le cheminnonoui, /api vers un groupe, /static vers un autre
Peut terminer TLSoui, plusieurs produits le proposentoui
Latence ajoutéetrès faiblefaible, mais supérieure
Cas d'usagebase de données, protocole non HTTP, besoin de performance brutesite web, API, la majorité des cas

Pour une application web, prenez le niveau 7. Il permet de router selon le chemin, de terminer le chiffrement, d'ajouter des en-têtes, et le surcoût de latence est négligeable devant ce qu'il apporte. Le niveau 4 garde sa place pour ce qui n'est pas du HTTP, ou quand chaque microseconde compte.

Un répartiteur ne sait pas qu'un serveur est en panne : il le déduit d'une sonde que vous configurez. Une sonde mal écrite laisse du trafic partir vers un serveur cassé, ou retire de la rotation un serveur qui va très bien.

L'erreur la plus répandue est de sonder le port TCP plutôt que l'application. Un serveur web dont la base de données est tombée accepte encore les connexions sur le port 443 : le port répond, la sonde est satisfaite, et chaque visiteur reçoit une erreur 500.

Une bonne sonde interroge un point de terminaison qui teste ce dont l'application a besoin. Concrètement, une adresse /health que vous écrivez vous-même, qui vérifie la connexion à la base et aux dépendances critiques, et qui répond 200 seulement si tout va bien.

RéglageValeur de départ raisonnableCe qu'il décide
Chemin/health, pas /ce qui est réellement testé
Intervalle10 sà quelle vitesse une panne est vue
Seuil d'échec3combien d'échecs avant retrait
Délai d'attente5 s, inférieur à l'intervalleà partir de quand on considère l'absence de réponse

Terminer TLS, c'est déchiffrer le trafic. L'endroit où cela se produit décide de ce que le répartiteur peut faire, et de qui voit les données en clair.

Trois montages existent, et le choix se fait sur une seule question : le trafic entre le répartiteur et vos serveurs traverse-t-il un réseau que vous ne maîtrisez pas ?

MontageCe qui se passeQuand le choisir
TerminaisonLe répartiteur déchiffre, puis parle en clair aux serveursRéseau interne maîtrisé, le cas courant
Re-chiffrementIl déchiffre, inspecte, puis re-chiffre vers les serveursDonnées sensibles, exigence de conformité
PassthroughIl ne déchiffre pas, il transmet le fluxLe serveur doit voir le certificat client

La terminaison simple est le montage par défaut, et il est raisonnable : le trafic circule en clair uniquement dans votre réseau privé, entre des machines que vous contrôlez. Elle a un avantage pratique décisif, la gestion des certificats se fait à un seul endroit.

Le re-chiffrement coûte du processeur des deux côtés et se justifie quand une norme l'exige, ou quand le réseau interne est partagé. Ne l'activez pas « par principe » sans savoir ce qu'il vous apporte.

Si votre application garde l'état de la session en mémoire, un visiteur réparti sur un autre serveur perd sa session. Le réflexe est d'activer l'affinité, qui renvoie toujours le même visiteur au même serveur. C'est une solution, et elle en crée d'autres.

Un serveur avec affinité garde ses visiteurs jusqu'à leur départ. Quand vous en ajoutez un pour absorber une montée en charge, il ne reçoit que les nouveaux arrivants, et la charge ne se rééquilibre pas. Pire, retirer un serveur pour maintenance déconnecte tout le monde d'un coup.

La solution durable est de sortir la session de la mémoire du serveur, dans un cache partagé ou une base. L'application devient alors sans état, n'importe quel serveur peut répondre à n'importe quelle requête, et la répartition redevient libre. C'est un travail applicatif, pas une case à cocher, et il paie sur tout le reste du cycle de vie.

Le répartiteur managé est facturé à l'heure, plus au trafic ou aux connexions. Il tourne en permanence, y compris devant un environnement de recette utilisé deux heures par semaine.

Trois arbitrages tiennent la facture :

  • Un répartiteur par environnement se multiplie vite. Production, recette, développement, cela fait trois abonnements pour un seul service rendu. Un seul répartiteur avec des règles de routage par nom peut servir plusieurs environnements non critiques.
  • Le trafic entre zones est facturé : un répartiteur en zone A qui envoie vers un serveur en zone B paie ce trajet. La répartition multi-zone est nécessaire à la résilience, pas gratuite.
  • Le niveau 7 coûte parfois plus cher que le niveau 4 chez certains fournisseurs, à service comparable. Vérifiez avant de choisir par défaut.
  • Le niveau 7 lit le HTTP, le niveau 4 non. Pour une application web, le niveau 7 dans presque tous les cas.
  • La sonde de santé fait le vrai travail. Sondez une adresse applicative, jamais le simple port TCP.
  • Délai d'attente inférieur à l'intervalle, et seuil d'échec à 3 : intervalle multiplié par seuil donne la durée pendant laquelle vos visiteurs voient des erreurs.
  • La terminaison TLS au répartiteur est le montage par défaut et centralise la gestion des certificats.
  • Le certificat expiré est l'incident le plus fréquent : renouvellement automatique, plus une alerte à 30 jours.
  • L'affinité de session masque un problème applicatif. Sortir la session de la mémoire du serveur rend la répartition vraiment libre.
  • Un répartiteur par environnement se paie par environnement. Regroupez ce qui n'est pas critique.

Ce site vous est utile ?

Sachez que moins de 1% des lecteurs soutiennent ce site.

Je maintiens +700 guides gratuits, sans pub ni tracking. Un soutien, même symbolique, m'aide à couvrir l'hébergement et à garder ces ressources gratuites. Merci pour votre appui.

Le formulaire ne s'affiche pas ? Ouvrir Ko-fi dans un onglet.

Abonnez-vous et suivez mon actualité DevSecOps sur LinkedIn