Équilibrage de charge Nginx

L'équilibrage de charge entre plusieurs applications, backends et serveurs fait partie du processus d'optimisation des ressources, d'amélioration des performances et de la tolérance aux pannes du service.

Nginx comme équilibreur de charge

Ce serveur Web est considéré comme l'une des solutions les plus populaires et les plus productives car il offre les fonctionnalités et la flexibilité de configuration les plus étendues. Nginx est donc souvent utilisé pour l'équilibrage de charge.

Il existe plusieurs approches et implémentations, mais vérifiez d'abord la disponibilité du module ngx_http_upstream_module :

# nginx -v

S'il manque, alors vous devrez reconstruire Nginx en ajoutant ce module. Après cela, vous pouvez commencer à configurer le serveur Web. Pour activer l'équilibrage, ajoutez la directive amont (section http) au fichier de configuration Nginx :

upstream backend  {
  server backend1.somesite.com;
  server backend2.somesite.com;
  server backend3.somesite.com;
}

Vous devez maintenant spécifier la redirection du groupe nécessaire :

server {
  location / {
    proxy_pass  http://backend;
  }
}

De plus, Nginx prend en charge des paramètres supplémentaires et des méthodes d'équilibrage de charge.

Choisir une méthode d'équilibrage

Nginx propose plusieurs méthodes d'équilibrage de charge.

Tourniquet

Par défaut, le serveur Web distribue les requêtes uniformément entre les backends (mais en tenant compte des pondérations). Il s'agit d'une méthode standard dans Nginx, il n'y a donc pas de directive d'inclusion.

moins_conn

Les requêtes sont d'abord envoyées au backend avec le moins de connexions actives (mais en tenant compte des poids) :

upstream backend {
    least_conn;

    server backend1.somesite.com;
    server backend2.somesite.com;
}

Hachage et hachage IP

En utilisant cette méthode, vous pouvez créer une sorte de connexion persistante entre les clients et les backends. Pour chaque requête, Nginx calcule un hachage composé de texte, de variables de serveur Web ou d'une combinaison de celles-ci, puis le mappe aux backends :

upstream backend {
   hash $scheme$request_uri;

   server backend1.somesite.com;
   server backend2.somesite.com;
   server backend3.somesite.com;
}

Le hachage IP ne fonctionne qu'avec HTTP, il s'agit d'une option prédéfinie dans laquelle le hachage est calculé par l'adresse IP du client :

upstream backend {
   ip_hash;

   server backend1.somesite.com;
   server backend2.somesite.com;
   server backend3.somesite.com;
}

Poids du backend

Si certains backends de la pile sont plus puissants que d'autres, alors les pondérations sont utiles :

upstream backend {
    server backend1.somesite.com weight=10;
    server backend2.somesite.com weight=5;
    server backend3.somesite.com;
    server 192.0.0.1 backup;
}

Dans cet exemple, sur 16 requêtes, le premier backend en traitera 10, le second 5 et le troisième 1. Dans ce cas, le serveur de secours ne recevra des requêtes que si les trois principaux backends ne sont pas disponibles.

Surveillance

Si Nginx pense que le serveur principal est indisponible, il arrête temporairement de lui envoyer des requêtes. Deux directives en sont responsables :

max_fails — définit le nombre de tentatives de connexion infructueuses, après quoi le backend est considéré comme indisponible pendant un certain temps ;
fail_timeout — durée pendant laquelle le serveur est considéré comme indisponible.

Les paramètres ressemblent à ceci :

upstream backend {                
    server backend1.somesite.com;
    server backend2.somesite.com max_fails=3 fail_timeout=30s;
    server backend3.somesite.com max_fails=2;
}

Conclusion

Le choix de la méthode d'équilibrage appropriée permettra de mieux répartir la charge. N'oubliez pas les poids du backend, la surveillance et la tolérance aux pannes du serveur.