La répartition de charge est la distribution dirigée du trafic entrant entre plusieurs travailleurs en aval. Sur Stack Harbor PaaS, le travail est fait par un nœud répartiteur — ajouté à la topologie automatiquement chaque fois que vous mettez à l’échelle un palier applicatif, et que vous pouvez aussi ajouter et mettre à l’échelle manuellement.
La plateforme opère la répartition sur deux couches, et il est utile de les distinguer quand on raisonne sur le flux de trafic.
Les deux couches
| Couche | Rôle | Géré par |
|---|---|---|
| Couche infrastructure | Achemine les requêtes entrantes depuis l’internet public vers le bon environnement | Shared Load Balancer, opéré par la plateforme |
| Couche application | Distribue les requêtes à l’intérieur d’un environnement entre les répliques d’un palier | Un nœud répartiteur au niveau environnement |
Quand un nœud a une IP publique attachée, le trafic vers ce nœud contourne le Shared Load Balancer et arrive directement. Tout le reste passe d’abord par le Shared Load Balancer.
Les cinq piles infogérées
Le PaaS fournit la prise en charge prête à l’emploi de cinq piles de répartiteur sur la couche application :
- NGINX — proxy inverse TCP/UDP et HTTP. Répartition Couche 7 et mise en cache de contenu. Le défaut dans la plupart des environnements, modulaire et économe en ressources.
- HAProxy — proxy événementiel pour TCP et HTTP. Persistance intelligente, mémoire stable en forte concurrence, utile pour des façades tolérantes au DDoS.
- Varnish — proxy inverse HTTP avec cache, livré avec NGINX comme façade HTTPS pour composer avec le TLS personnalisé. Décharge la livraison du statique et du dynamique cacheable.
- Répartiteur Apache — répartiteur à modules avec large personnalisation. Choix naturel quand le reste du palier est déjà Apache.
- LiteSpeed Web ADC — ADC commercial avec HTTP/3 / QUIC, pare-feu applicatif web, filtrage anti-DDoS de couche 7, mise en cache, accélération et délestage.
Exploiter un palier derrière un répartiteur avec deux nœuds ou plus est le motif de production standard — redondance et suppression du serveur applicatif unique comme point de défaillance.
Vérifications de santé des backends
Chaque répartiteur au niveau environnement embarque une vérification de santé par défaut :
| Répartiteur | Vérification par défaut |
|---|---|
| NGINX | Vérification TCP sur le port amont avant chaque décision de routage ; en cas d’échec, le nœud suivant est essayé |
| HAProxy | Vérification TCP toutes les 2 secondes, résultats stockés dans une table d’état en mémoire |
| Varnish | Sonde URL une fois par minute, délai de 30 s, fenêtre de 5 échantillons, seuil de 2 échecs |
| LiteSpeed ADC | Vérification TCP sur l’IP interne chaque seconde avec un délai de 1 s, au niveau Worker Group |
| Répartiteur Apache | Aucune par défaut — configurez mod_proxy_hcheck si vous voulez un sondage actif |
Les valeurs par défaut sont des points de départ raisonnables. Ajustez l’intervalle, le délai et le seuil d’échec depuis les fichiers de configuration du répartiteur via le tableau de bord ou en SSH.
Quand ajouter un répartiteur manuellement
Le répartiteur est ajouté pour vous quand vous mettez à l’échelle un palier au-delà d’un nœud. Trois cas justifient d’en ajouter un plus tôt ou à la main :
- TLS sur le répartiteur. Terminer HTTPS une fois et transmettre HTTP en interne — gestion de certificat plus propre, serveurs d’application allégés.
- Contrôles en bordure. Authentification, autoriser/refuser par IP, limitation de débit, réécriture de requête — plus propre sur un répartiteur dédié que dispersé sur les nœuds applicatifs.
- Cache. Une couche Varnish ou cache NGINX devant des backends dynamiques garde les temps de réponse plats sous charge.
Vous pouvez ajouter un répartiteur à une topologie à un seul serveur applicatif depuis le bloc Balancing de l’assistant de topologie.