F5 NGINX PLUS

F5 NGINX Plus : équilibrage de charge

L’équilibrage de votre trafic réseau entre les serveurs, les clients et les proxies est essentiel pour satisfaire vos clients et optimiser votre infrastructure. Avec l’équilibrage de charge haute performance NGINX Plus, vous pouvez évoluer et fournir de la redondance, reconfigurer dynamiquement votre infrastructure sans avoir à la redémarrer, et activer le GSLB (Global Server Load Balancing), la persistance des sessions et les contrôles de santé actifs. NGINX Plus équilibre la charge non seulement le trafic HTTP, mais aussi TCP, UDP et gRPC.

Faites évoluer vos applications avec l’équilibrage de charge NGINX et NGINX Plus
Faites évoluer vos applications avec l’équilibrage de charge NGINX et NGINX Plus

Équilibrage de charge HTTP

Lors de l’équilibrage du trafic HTTP, NGINX Plus termine chaque connexion HTTP et traite chaque requête individuellement. Vous pouvez supprimer le cryptage SSL/TLS, inspecter et manipuler la requête, mettre la requête en file d’attente en utilisant des limites de taux, puis sélectionner la politique d’équilibrage de la charge.

Pour améliorer les performances, NGINX Plus peut automatiquement appliquer une large gamme d’optimisations à une transaction HTTP, y compris les mises à niveau du protocole HTTP, l’optimisation du keepalive et les transformations telles que la compression du contenu et la mise en cache de la réponse.

L’équilibrage de charge du trafic HTTP est facile avec NGINX Plus :

http {
    upstream my_upstream {
        server server1.example.com;
        server server2.example.com;
    }

    server {
        listen 80;
        location / {
            proxy_set_header Host $host;
            proxy_pass http://my_upstream;
        }
    }
}

Spécifiez d’abord un serveur virtuel à l’aide de l’option server puis spécifiez le port listen sur lequel écouter le trafic. Faites correspondre les URL des requêtes des clients à l’aide d’un bloc location, définissez l’en-tête Host à l’aide de la directive proxy_set_header, et incluez la directive proxy_pass pour transmettre la demande à un groupe en amont (la directive upstream définit les serveurs sur lesquels NGINX Plus équilibre le trafic)

Pour plus d’informations, consultez cette introduction à l’équilibrage de charge avec NGINX et NGINX Plus.

Équilibrage de la charge TCP et UDP

NGINX Plus peut également équilibrer la charge des applications TCP telles que MySQL, et des applications UDP telles que DNS et RADIUS. Pour les applications TCP, NGINX Plus termine les connexions TCP et crée de nouvelles connexions vers le backend.

stream {
    upstream my_upstream {
        server server1.example.com:1234;
        server server2.example.com:2345;
    }

    server {
        listen 1123 [udp];
        proxy_pass my_upstream;
    }
}

La configuration est similaire à celle du protocole HTTP : utilisez la directive server pour spécifier un serveur virtuel, listen pour écouter le trafic sur un port, et proxy_pass pour envoyer la requête à un groupe upstream (en amont).

Pour plus d’informations sur l’équilibrage de charge TCP et UDP, voir le Guide d’administration de NGINX Plus.

Méthodes d’équilibrage de charge

NGINX Plus prend en charge un certain nombre de méthodes d’équilibrage de la charge des applications pour équilibrer la charge HTTP, TCP et UDP. Toutes les méthodes prennent en compte le poids (weight) que vous pouvez optionnellement assigner à chaque serveur en amont.

  • Round Robin (par défaut) : distribue les demandes sur les serveurs en amont dans l’ordre.
  • Least Connections : transfère les demandes au serveur ayant le plus petit nombre de connexions actives.
  • Least Time : transfère les requêtes au serveur le moins chargé, sur la base d’un calcul combinant le temps de réponse et le nombre de connexions actives. Exclusif à NGINX Plus.
  • Hash : distribue les requêtes sur la base d’une clé spécifiée, par exemple l’adresse IP du client ou l’URL de la requête. NGINX Plus peut aussi appliquer un hash cohérent pour minimiser la redistribution des charges si l’ensemble des serveurs en amont change.
  • IP Hash (HTTP uniquement) : distribue les requêtes en fonction des trois premiers octets de l’adresse IP du client.
  • Random with Two Choices : choisit deux serveurs au hasard et transmet la requête à celui qui a le plus petit nombre de connexions actives (méthode Least Connections). Avec NGINX Plus, la méthode Least Time peut également être utilisée.

Limitation des connexions avec NGINX Plus

Vous pouvez limiter le nombre de connexions que NGINX Plus établit avec des serveurs HTTP ou TCP en amont, ou le nombre de sessions avec des serveurs UDP. Lorsque le nombre de connexions ou de sessions avec un serveur dépasse une limite définie, NGINX Plus arrête d’en établir de nouvelles.

Dans l’extrait de configuration ci-dessous, la limite de connexion pour le serveur web 1 est de 250 et celle du serveur web 2 est de 150. Le paramètre queue spécifie le nombre maximum de connexions excédentaires que NGINX Plus place dans la file d’attente d’écoute du système d’exploitation, pour une durée maximale de 30 secondes chacune ; les demandes excédentaires supplémentaires sont abandonnées.

upstream backend {
    zone backends 64k;
    queue 750 timeout=30s;

    server webserver1 max_conns=250;
    server webserver2 max_conns=150;
}

Lorsque le nombre de connexions actives sur un serveur tombe en dessous de sa limite, NGINX Plus lui envoie des connexions depuis la file d’attente. Limiter les connexions permet d’assurer un service homogène et prévisible des requêtes des clients, même en cas de pics de trafic.

Persistance de session

Vous pouvez configurer NGINX Plus pour qu’il identifie les sessions utilisateur et envoie toutes les requêtes d’une session au même serveur en amont. C’est vital lorsque les serveurs d’applications stockent l’état localement, car des erreurs fatales se produisent lorsqu’une requête pour une session utilisateur en cours est envoyée à un serveur différent. La persistance des sessions peut également améliorer les performances lorsque les applications partagent des informations au sein d’un cluster.

En plus de la persistance de session basée sur le hachage prise en charge par NGINX Open Source (les méthodes d’équilibrage de charge Hash et IP Hash), NGINX Plus prend en charge la persistance de session basée sur les cookies, y compris le cookie persistant (sticky cookie). NGINX Plus ajoute un cookie de session à la première réponse du groupe en amont à un client donné, identifiant en toute sécurité le serveur qui a généré la réponse. Les demandes ultérieures du client incluent le cookie, que NGINX Plus utilise pour acheminer la demande vers le même serveur en amont :

upstream backend {
    server webserver1;
    server webserver2;

    sticky cookie srv_id expires=1h domain=.example.com path=/;
}

Dans l’exemple ci-dessus, NGINX Plus insère un cookie appelé srv_id dans la réponse initiale du client pour identifier le serveur qui a traité la requête. Lorsqu’une requête ultérieure contient le cookie, NGINX Plus la transmet au même serveur.

NGINX Plus prend également en charge les méthodes « sticky learn » et « sticky route persistence ».

Note : La persistance de session basée sur les cookies est exclusive à NGINX Plus.

Contrôles de santé actifs

Par défaut, NGINX effectue des vérifications de base sur les réponses des serveurs en amont, en réessayant les requêtes échouées lorsque cela est possible. NGINX Plus ajoute des vérifications de santé des applications hors bande (également connues sous le nom de transactions synthétiques) et une fonction de démarrage lent pour ajouter gracieusement de nouveaux serveurs et des serveurs récupérés dans le groupe d’équilibrage de la charge.

Ces fonctionnalités permettent à NGINX Plus de détecter et de contourner une plus grande variété de problèmes, améliorant ainsi de manière significative la fiabilité de vos applications HTTP et TCP/UDP.

upstream my_upstream {
	zone my_upstream 64k;
	server server1.example.com slow_start=30s;
}

server {
    # ...
    location /health {
        internal;
        health_check interval=5s uri=/test.php match=statusok;
        proxy_set_header Host www.example.com;
        proxy_pass http://my_upstream
    }
}

match statusok {
    # Used for /test.php health check
    status 200;
    header Content-Type = text/html;
    body ~ "Server[0-9]+ is alive";
}

Dans l’exemple ci-dessus, NGINX Plus envoie une requête pour /test.php toutes les cinq secondes. La fonction match définit les conditions que doit remplir la réponse pour que le serveur en amont soit considéré comme sain : un code de statut de 200 OK et un corps de réponse contenant le texte ServerN is alive (le serveur N est vivant).

Remarque : les contrôles de santé actifs sont exclusifs à NGINX Plus.

Découverte de services à l’aide de DNS

Par défaut, les serveurs NGINX Plus résolvent les noms DNS au démarrage et mettent en cache les valeurs résolues de manière persistante. Lorsque vous utilisez un nom de domaine tel que exemple.com pour identifier un groupe de serveurs en amont avec la directive server et le paramètre resolve, NGINX Plus résout régulièrement le nom de domaine à nouveau. Si la liste d’adresses IP associée a changé, NGINX Plus commence immédiatement à équilibrer la charge sur le groupe de serveurs mis à jour.

Pour configurer NGINX Plus afin qu’il utilise les enregistrements DNS SRV, incluez la directive resolver avec le paramètre service=http dans la directive server, comme indiqué :

resolver 127.0.0.11 valid=10s;

upstream service1 {
    zone service1 64k;
    server service1 service=http resolve;
}

Dans l’exemple ci-dessus, NGINX Plus interroge 127.0.0.11 (le serveur DNS intégré de Docker) toutes les 10 secondes pour résoudre à nouveau le nom de domaine service1.

Remarque : la découverte de services à l’aide de DNS est exclusive à NGINX Plus.

API NGINX Plus

NGINX Plus inclut une API RESTful avec un seul point de terminaison API. Utilisez l’API NGINX Plus pour mettre à jour les configurations en amont et les magasins de valeurs clés à la volée avec zéro temps d’arrêt.

L’extrait de configuration suivant inclut la directive api pour permettre l’accès en lecture-écriture au point de terminaison /api.

upstream backend {
    zone backends 64k;
    server 10.10.10.2:220 max_conns=250;
    server 10.10.10.4:220 max_conns=150;
}

server {
    listen 80;
    server_name www.example.org;

    location /api {
        api write=on;
    }
}

Lorsque l’API est activée comme dans l’exemple ci-dessus, vous pouvez ajouter un nouveau serveur à un groupe en amont existant à l’aide de la commande curl suivante. Elle utilise la méthode POST et le codage JSON pour définir l’adresse IP du serveur à 192.168.78.66, son poids à 200 et le nombre maximum de connexions simultanées à 150 (pour la version, remplacez le numéro de version actuel de l’API comme spécifié dans la documentation de référence).

$ curl -iX POST -d ’{"server":"192.168.78.66:80","weight":"200","max_conns":"150"}’ http://localhost:80/api/version/http/upstreams/backend/servers/

Pour afficher la configuration complète de tous les serveurs backend en amont au format JSON, exécutez :

$ curl -s http://localhost:80/api/version/http/upstreams/backend/servers/ | python -m json.tool
	{
      "backup": false,
      "down": false,
      "fail_timeout": "10s",
      "id": 0,
      "max_conns": 250,
      "max_fails": 1,
      "route": "",
      "server": "10.10.10.2:220",
      "slow_start": "0s",
      "weight": 1
      },
      {
      "backup": false,
      "down": false,
      "fail_timeout": "10s",
      "id": 1,
      "max_conns": 150,
      "max_fails": 1,
      "route": "",
      "server": "10.10.10.4:220",
      "slow_start": "0s",
      "weight": 1
      },
      {
      "backup": false,
      "down": false,
      "fail_timeout": "10s",
      "id": 2,
      "max_conns": 200,
      "max_fails": 1,
      "route": "",
      "server": "192.168.78.66:80",
      "slow_start": "0s",
      "weight": 200
      }

Pour modifier la configuration d’un serveur en amont existant, identifiez-le par son ID interne, qui apparaît dans le champ id de la sortie ci-dessus. La commande suivante utilise la méthode PATCH pour reconfigurer le serveur ayant l’ID 2, en fixant son adresse IP et son port d’écoute à 192.168.78.55:80, son poids à 500 et la limite de connexion à 350.

$ curl -iX PATCH -d ’{"server":"192.168.78.55:80","weight":"500","max_conns":"350"}’ http://localhost:80/api/version/http/upstreams/backend/servers/2

Vous pouvez accéder à la documentation complète de Swagger (OpenAPI Specification) de l’API NGINX Plus à l’adresse suivante : https://demo.nginx.com/swagger-ui/.

Note : l’API NGINX Plus est exclusive à NGINX Plus.

Étapes suivantes