Utilisation de nginx comme équilibreur de charge HTTP
L'équilibrage de charge sur plusieurs instances d'application est une technique couramment utilisée pour optimiser l'utilisation des ressources, maximiser le débit, réduire la latence et garantir des configurations tolérantes aux pannes.
Il est possible d'utiliser nginx comme un équilibreur de charge HTTP très efficace pour distribuer le trafic sur plusieurs serveurs d'applications et pour améliorer les performances, l'évolutivité et la fiabilité des applications Web avec nginx.
Méthodes d'équilibrage de charge
Les mécanismes (ou méthodes) d'équilibrage de charge suivants sont pris en charge dans nginx :
| Méthode | Description |
|---|---|
| round-robin | Les requêtes adressées aux serveurs d'applications sont distribuées de manière circulaire. |
| least-connected | La requête suivante est attribuée au serveur ayant le moins de connexions actives. |
| ip-hash | Une fonction de hachage est utilisée pour déterminer quel serveur doit être sélectionné pour la requête suivante (en fonction de l'adresse IP du client). |
Configuration d'équilibrage de charge par défaut
La configuration la plus simple pour l'équilibrage de charge avec nginx peut ressembler à ce qui suit :
|
http { upstream myapp1 { server srv1.example.com; server srv2.example.com; server srv3.example.com; } server { listen 80; location / { proxy_pass http://myapp1; } } } |
Dans l'exemple ci-dessus, 3 instances de la même application s'exécutent sur srv1-srv3. Lorsque la méthode d'équilibrage de charge n'est pas spécifiquement configurée, elle est par défaut de type round-robin. Toutes les requêtes sont transmises par proxy au groupe de serveurs myapp1 et nginx applique l'équilibrage de charge HTTP pour distribuer les requêtes.
L'implémentation du proxy inverse dans nginx inclut l'équilibrage de charge pour HTTP, HTTPS, FastCGI, uwsgi, SCGI, memcached et gRPC.
Pour configurer l'équilibrage de charge pour HTTPS au lieu de HTTP, utilisez simplement «https» comme protocole.
Lors de la configuration de l'équilibrage de charge pour FastCGI, uwsgi, SCGI, memcached ou gRPC, utilisez respectivement les directives fastcgi_pass, uwsgi_pass, scgi_pass, memcached_pass et grpc_pass.
Équilibrage de charge le moins connecté
Une autre discipline d'équilibrage de charge est l'équilibrage le moins connecté. Le mode le moins connecté permet de contrôler la charge sur les instances d'application de manière plus équitable dans une situation où certaines requêtes prennent plus de temps à se terminer.
Avec l'équilibrage de charge le moins connecté, nginx essaiera de ne pas surcharger un serveur d'application occupé avec des requêtes excessives, en distribuant les nouvelles requêtes à un serveur moins occupé à la place.
L'équilibrage de charge le moins connecté dans nginx est activé lorsque la directive least_conn est utilisée dans le cadre de la configuration du groupe de serveurs :
|
upstream myapp1 { least_conn; server srv1.example.com; server srv2.example.com; server srv3.example.com; } |
Persistance de session
Veuillez noter qu'avec l'équilibrage de charge à tour de rôle ou l'équilibrage de charge le moins connecté, la demande de chaque client suivant peut être potentiellement distribuée à un serveur différent. Il n'y a aucune garantie que le même client sera toujours dirigé vers le même serveur.
S'il est nécessaire de lier un client à un serveur d'application particulier (en d'autres termes, de rendre la session du client «collante» ou «persistante» en essayant toujours de sélectionner un serveur particulier), le mécanisme d'équilibrage de charge ip-hash peut être utilisé.
Avec ip-hash, l'adresse IP du client est utilisée comme clé de hachage pour déterminer quel serveur d'un groupe de serveurs doit être sélectionné pour les demandes du client. Cette méthode garantit que les demandes du même client seront toujours dirigées vers le même serveur, sauf lorsque ce serveur n'est pas disponible.
Pour configurer l'équilibrage de charge ip-hash, ajoutez simplement la directive ip_hash à la configuration du groupe de serveurs (en amont) :
|
upstream myapp1 { ip_hash; server srv1.example.com; server srv2.example.com; server srv3.example.com; } |
Équilibrage de charge pondéré
Il est également possible d'influencer encore davantage les algorithmes d'équilibrage de charge nginx en utilisant les pondérations des serveurs.
Dans les exemples ci-dessus, les pondérations des serveurs ne sont pas configurées, ce qui signifie que tous les serveurs spécifiés sont traités comme étant également qualifiés pour une méthode d'équilibrage de charge particulière.
Avec le round-robin en particulier, cela signifie également une répartition plus ou moins égale des requêtes sur les serveurs, à condition qu'il y ait suffisamment de requêtes et que les requêtes soient traitées de manière uniforme et terminées suffisamment rapidement.
Lorsque le paramètre de pondération est spécifié pour un serveur, le poids est pris en compte dans le cadre de la décision d'équilibrage de charge.
|
upstream myapp1 { server srv1.example.com weight=3; server srv2.example.com; server srv3.example.com; } |
Avec cette configuration, toutes les 5 nouvelles requêtes seront distribuées sur les instances d'application comme suit : 3 requêtes seront dirigées vers srv1, une requête ira vers srv2 et une autre vers srv3.
Il est également possible d'utiliser des pondérations avec l'équilibrage de charge le moins connecté et le hachage IP dans les versions récentes de nginx.
Vérifications de l'état
L'implémentation du proxy inverse dans nginx inclut des vérifications de l'état du serveur en bande (ou passives). Si la réponse d'un serveur particulier échoue avec une erreur, nginx marquera ce serveur comme ayant échoué et essaiera d'éviter de sélectionner ce serveur pour les requêtes entrantes suivantes pendant un certain temps.
La directive max_fails définit le nombre de tentatives infructueuses consécutives de communication avec le serveur devant se produire pendant fail_timeout. Par défaut, max_fails est défini sur 1. Lorsqu'il est défini sur 0, les vérifications de l'état sont désactivées pour ce serveur. Le paramètre fail_timeout définit également la durée pendant laquelle le serveur sera marqué comme ayant échoué. Après l'intervalle fail_timeout suivant la panne du serveur, nginx commencera à sonder le serveur avec les requêtes du client actif. Si les sondages ont réussi, le serveur est marqué comme étant actif.
Pour en savoir plus
En outre, il existe d'autres directives et paramètres contrôlant l'équilibrage de la charge du serveur dans nginx, par exemple proxy_next_upstream, backup, down et keepalive.