Configurez nginx en load balancer : le bloc upstream, round robin, least_conn, ip_hash et hash, les poids, max_fails et fail_timeout, les serveurs de secours, plus un générateur de configuration.
Pour répartir la charge avec nginx, listez vos serveurs d'application dans un bloc upstream et faites pointer proxy_pass vers son nom. Les requêtes tournent en round robin, sauf si vous ajoutez least_conn, ip_hash, hash ou random. Chaque ligne server peut porter un weight, un max_fails et un fail_timeout pour les contrôles de santé passifs, ainsi que les options backup ou down.
Méthodes de répartition de charge nginx
Directive
Comment elle choisit un serveur
Idéale pour
(aucune)
Round robin pondéré, le comportement par défaut
Serveurs similaires et requêtes courtes
Le moins de connexions actives, en tenant compte des poids
Requêtes de durées très différentes
Hash de l'adresse du client (trois premiers octets en IPv4, adresse complète en IPv6)
Garder un visiteur sur un même serveur
hash key
Hash de n'importe quelle valeur, comme $request_uri
Affinité de cache ; ajoutez consistent pour limiter les redistributions
Serveur aléatoire, ou le meilleur de deux avec random two
Plusieurs load balancers partageant un même pool
Répartir le trafic sur plusieurs copies d'une application est l'une des plus anciennes tâches de nginx, et toute la configuration tient en une douzaine de lignes. Le générateur ci-dessous écrit le bloc upstream à partir d'une liste de serveurs, signale les combinaisons que nginx refuse et affiche la part de requêtes de chaque serveur quand des poids s'appliquent. La référence qui suit couvre chaque paramètre de server avec sa valeur par défaut.
Ajoutez l'adresse et le port de chaque serveur d'application dans le générateur, avec un poids si certaines machines sont plus puissantes que d'autres.
Choisissez une méthode. Gardez le round robin, sauf si la durée des requêtes varie beaucoup ou si les visiteurs doivent rester sur un même serveur.
Copiez le résultat dans le contexte http, par exemple dans un fichier de conf.d, puis lancez nginx -t.
Rechargez avec nginx -s reload, puis arrêtez un serveur d'application et observez les requêtes basculer vers les autres.
Un upstream avec un seul serveur ignore max_fails et fail_timeout : les contrôles passifs ne comptent qu'à partir de deux serveurs.
Avec ip_hash, marquez un serveur down au lieu de supprimer sa ligne. Le hash de l'adresse de chaque autre client continue ainsi de pointer au même endroit qu'avant.
Les serveurs backup ne reçoivent du trafic que lorsque tous les serveurs principaux sont indisponibles, et ne peuvent pas être combinés avec hash, ip_hash ou random.
C'est proxy_next_upstream qui décide quels échecs comptent pour max_fails. Par défaut, les erreurs et les timeouts comptent ; une erreur HTTP 500 ne compte pas, sauf si vous l'ajoutez.
Ajoutez keepalive avec proxy_http_version 1.1 et un en-tête Connection vide pour réutiliser les connexions vers les backends au lieu d'en ouvrir une par requête.
Questions fréquentes
nginx open source propose-t-il des health checks actifs ?
Non. La directive health_check fait partie de l'offre commerciale NGINX Plus. nginx open source s'appuie sur des contrôles passifs : si une requête vers un serveur échoue max_fails fois pendant fail_timeout, le serveur est écarté pendant fail_timeout, puis retesté avec du trafic réel.
Quelles sont les valeurs par défaut de max_fails et fail_timeout ?
max_fails vaut 1 par défaut et fail_timeout 10 secondes. Une seule tentative échouée écarte donc un serveur pendant dix secondes. Avec max_fails=0, le décompte est désactivé pour ce serveur.
Comment rendre les sessions persistantes (sticky) avec nginx ?
Utilisez ip_hash pour garder chaque adresse client sur un même serveur, ou hash avec une variable de cookie comme $cookie_session pour un contrôle plus fin. Les directives sticky basées sur les cookies n'existent que dans l'édition commerciale.
À quoi sert le paramètre weight ?
Il modifie le nombre de requêtes qu'un serveur reçoit par rapport aux autres. Avec des poids de 3, 1 et 1, le premier serveur reçoit environ trois requêtes sur cinq en round robin. Le poids par défaut est 1.
nginx peut-il répartir des connexions WebSocket ?
Oui. Faites pointer proxy_pass vers l'upstream et transmettez les en-têtes Upgrade et Connection. least_conn convient mieux que le round robin aux sockets de longue durée, car il compte les connexions que chaque serveur détient déjà.
Où placer chaque élément
Le bloc upstream se place dans le contexte http, à côté de vos blocs server. Il ne fait que nommer un pool : rien ne se passe tant qu'une location n'indique pas proxy_pass http://name. Le même pool peut servir à plusieurs locations et plusieurs blocs server.
Les contrôles de santé passifs, étape par étape
Quand une requête vers un serveur échoue d'une manière que proxy_next_upstream prend en compte, nginx la relance sur le serveur suivant et enregistre l'échec. Dès qu'un serveur atteint max_fails échecs dans la fenêtre fail_timeout, nginx cesse de le choisir. Une fois fail_timeout écoulé, il lui renvoie prudemment de vraies requêtes clientes, et un succès le remet dans la rotation.
Comme ces contrôles s'appuient sur le trafic réel, un visiteur peut tomber sur la première tentative échouée. Des timeouts courts sur proxy_connect_timeout limitent ce délai.
Paramètres de server et leurs valeurs par défaut
Paramètres d'une ligne server dans upstream
Paramètre
Défaut
Effet
weight=n
Part relative des requêtes
max_fails=n
Tentatives échouées pendant fail_timeout avant que le serveur soit écarté ; 0 désactive
fail_timeout=time
Fenêtre de décompte des échecs et durée pendant laquelle le serveur est écarté
max_conns=n
0 (aucune limite)
Plafond de connexions actives simultanées vers ce serveur
Utilisé uniquement quand tous les serveurs principaux sont indisponibles
Marque le serveur comme indisponible en permanence
Exemples complets
Round robin avec un serveur de secours
Deux serveurs principaux se partagent la charge ; le troisième ne répond que si les deux sont hors service.
least_conn avec connexions réutilisées
keepalive garde en cache les connexions inactives vers les backends ; les deux lignes proxy rendent cela possible.
Affinité de cache par URL
Chaque URL retombe toujours sur le même serveur de cache ; consistent préserve la plupart des correspondances quand un serveur est ajouté ou retiré.
Nom de l'upstream
Méthode
Round robin (par défaut)
Clé de hash
Connexions keepalive inactives (0 pour aucune)
Serveurs
Adresse et port
Poids
fail_timeout (s)
Part
Retirer le serveur {n}
Ajouter un serveur
nginx refuse les serveurs backup avec hash, ip_hash et random. Retirez l'option backup ou changez de méthode.
Tous les serveurs principaux sont marqués down : aucun ne peut recevoir de trafic.