Choisir une technique d’équilibrage de charge NGINX Plus

Tony Mauro

Nous avons beaucoup écrit sur la façon dont vous pouvez utiliser NGINX Plus et NGINX Open Source pour répartir la charge de vos sites web et applications afin de garantir une disponibilité et une fiabilité optimales. La répartition de charge est un outil essentiel pour améliorer les performances des applications, déployer des applications à grande échelle, et déployer des conteneurs et des microservices.

Nous avons déjà expliqué comment déployer NGINX Plus dans le centre de données (éventuellement aux côtés de contrôleurs de mise à disposition d’applications existants), dans des conteneurs, ainsi que dans des environnements cloud, notamment Amazon Web Services (AWS), Google Cloud Platform et Microsoft Azure.

Dans cet article, nous nous concentrerons sur les techniques d’équilibrage de charge (également appelées méthodes ou algorithmes d’équilibrage de charge) de NGINX Plus et NGINX, et vous donnerons quelques conseils pour choisir la méthode adaptée aux différents cas d’utilisation. NGINX propose quatre techniques d’équilibrage de charge (Round Robin, Hash, IP Hash et Least Connections), auxquelles NGINX Plus en ajoute une autre (Least Time). Toutes les méthodes destinées au trafic HTTP sont également disponibles pour TCP (ainsi que pour UDP à partir de NGINX Plus Release 9), à l’exception d’IP Hash.

[Éditeur – NGINX Plus R16 et NGINX Open Source 1.15.1 ont introduit l’algorithme « Random with Two Choices » comme algorithme supplémentaire de répartition de charge. Pour en savoir plus, consultez l’article NGINX et l’algorithme de répartition de charge « Power of Two Choices » sur notre blog.]

Examen des techniques de répartition de charge

Nous partons du principe que vous connaissez les bases de la configuration de l’équilibrage de charge, mais vous pouvez consulter ces ressources si vous souhaitez vous rafraîchir la mémoire :

• Les articles du Guide d’administration de NGINX Plus fournissent une vue d’ensemble complète.
• Équilibrage de charge haute performance renvoie vers des présentations détaillées des fonctionnalités avancées de NGINX Plus qui permettent d’améliorer encore davantage l’efficacité d’une méthode d’équilibrage de charge.
• Répartition de charge avec NGINX et NGINX Plus, Partie 1 et Partie 2 est un guide pas à pas qui transforme un simple proxy inverse en une solution complète de répartition de charge grâce aux fonctionnalités avancées de NGINX Plus.
• La page des solutions d’équilibrage de charge contient des liens vers d’autres ressources, notamment des livres numériques, des webinaires et des livres blancs.

Par souci de simplicité, nous nous concentrerons sur l’équilibrage de charge HTTP, que vous configurez dans le contexte http . L’équilibrage de charge TCP se configure quant à lui dans le contexte stream (tout comme l’équilibrage de charge UDP dans NGINX Plus version 9 et ultérieure). Bien que les équilibreurs de charge HTTP et TCP/UDP offrent les mêmes fonctionnalités, les directives et paramètres disponibles diffèrent quelque peu en raison des différences inhérentes entre les protocoles. Pour plus de détails, consultez la documentation relative aux modules Upstream pour HTTP et TCP/UDP.

Vous activez la répartition de charge à l’aide de deux blocs de configuration, présentés ici sous leur forme de base, sans paramètres facultatifs ni fonctionnalités auxiliaires :

• Le bloc « server » définit un serveur virtuel qui écoute le trafic présentant les caractéristiques que vous avez définies et le transmet à un groupe nommé de serveurs en amont. Dans nos exemples, le serveur virtuel écoute sur le port par défaut (80) le trafic HTTP envoyé à www.example.com et le transmet au groupe de serveurs en amont nommé « backend ». Ce bloc est identique dans tous nos exemples.

server {    server_name www.example.com;

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

• (NGINX Plus et NGINX peuvent également répartir la charge entre des serveurs backend FastCGI, memcached, SCGI et uwsgi. Remplacez proxy_pass par la directive appropriée : fastcgi_pass, memcached_pass, scgi_pass ou uwsgi_pass.)
• Le bloc upstream nomme un groupe en amont et répertorie les serveurs qui en font partie, identifiés par leur nom d’hôte, leur adresse IP ou le chemin d’accès à leur socket de domaine UNIX. Dans nos exemples, le groupe en amont appelé backend comprend trois serveurs : web1, web2 et web3. Le bloc upstream permet de spécifier la technique d’équilibrage de charge ; nous la mettrons donc en évidence dans les sections suivantes. À titre d’exemple, voici le bloc correspondant à la méthode par défaut, Round Robin :

upstream backend {    server web1;
    server web2;
    server web3;
}

Tourniquet

Round Robin est la technique d’équilibrage de charge par défaut pour NGINX Plus et NGINX. L’équilibreur de charge parcourt séquentiellement la liste des serveurs en amont et attribue à chacun, à tour de rôle, la demande de connexion suivante.

Avec l’exemple de configuration suivant du groupe en amont « backend », l’équilibreur de charge envoie les trois premières demandes de connexion à web1, web2 et web3, dans cet ordre, la quatrième à web1, la cinquième à web2, et ainsi de suite.

upstream backend {    server web1;
    server web2;
    server web3;
}

server {
    server_name www.example.com;

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

Hachage

Avec la méthode de hachage, l'équilibreur de charge calcule pour chaque requête une valeur de hachage basée sur la combinaison de texte et de variables NGINX que vous spécifiez, puis associe cette valeur à l'un des serveurs. Il envoie toutes les requêtes présentant cette valeur de hachage à ce serveur. Cette méthode établit donc une forme élémentaire de persistance de session.

Dans l’exemple suivant, la directive « hash » utilise le protocole (http ou https) et l’URI complète de la requête comme base de calcul du hachage :

upstream backend {    hash $scheme$request_uri;

    server web1;
    server web2;
    server web3;
}

server {
    server_name www.example.com;

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

Hachage IP

IP Hash (disponible uniquement pour HTTP) est une variante prédéfinie de la méthode Hash, dans laquelle le hachage repose sur l’adresse IP du client. Vous l’activez à l’aide de la directive « ip_hash ».

upstream backend {    ip_hash;

    server web1;
    server web2;
    server web3;
}

server {
    server_name www.example.com;

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

Si le client possède une adresse IPv6, le hachage est calculé à partir de l’adresse complète. S’il possède une adresse IPv4, le hachage repose uniquement sur les trois premiers octets de l’adresse. Ce mécanisme est conçu pour optimiser le traitement des clients de fournisseurs d’accès à Internet auxquels des adresses IP sont attribuées dynamiquement à partir d’une plage de sous-réseau (/24). En cas de redémarrage ou de reconnexion, l’adresse du client est souvent remplacée par une autre adresse de la plage réseau /24, mais la connexion correspond toujours au même client ; il n’y a donc aucune raison de modifier son association avec le serveur.

Toutefois, si la majeure partie du trafic vers votre site provient de clients appartenant au même réseau /24, la méthode IP Hash n’est pas pertinente, car elle associe tous les clients au même serveur. Dans ce cas (ou si, pour une autre raison, vous souhaitez calculer le hachage à partir des quatre octets), utilisez plutôt la méthode Hash avec la variable « $remote_addr ».

hash $remote_addr;

Moins de connexions

Avec la méthode des connexions les moins nombreuses, l’équilibreur de charge compare le nombre actuel de connexions actives qu’il entretient avec chaque serveur et envoie la requête au serveur qui en compte le moins. Vous configurez cette méthode à l’aide de la directive « least_conn ».

upstream backend {
    least_conn;

    server web1;
    server web2;
    server web3;
}

server {
    server_name www.example.com;

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

Temps minimal

Avec la méthode Least Time (disponible uniquement dans NGINX Plus), l’équilibreur de charge combine mathématiquement deux métriques pour chaque serveur : le nombre actuel de connexions actives et la moyenne pondérée du temps de réponse aux requêtes précédentes. Il envoie ensuite la requête au serveur présentant la valeur la plus faible.

Le paramètre que vous choisissez pour la directive least_time détermine lequel des deux temps de réponse est mesuré : soit le temps nécessaire pour recevoir l’en-tête de la réponse (header), soit le temps nécessaire pour recevoir la réponse complète (last_byte).

upstream backend {    least_time (header | last_byte);

    server web1;
    server web2;
    server web3;
}

server {
    server_name www.example.com;

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

Remarques :

• Pour l’équilibrage de charge TCP et UDP (dans le contexte stream), vous pouvez choisir parmi trois types de temps de réponse à l’aide des paramètres suivants de la directive least_time :
  • connect – Temps nécessaire pour se connecter au serveur en amont
  • first_byte – Temps nécessaire pour recevoir le premier octet des données de réponse
  • last_byte – Temps nécessaire pour recevoir le dernier octet des données de réponse
• Pour le trafic HTTP comme pour le trafic TCP/UDP, dans NGINX Plus R12 et les versions ultérieures, ajoutez le paramètre « inflight » afin d’inclure les connexions incomplètes dans chaque métrique ; dans les versions antérieures, ces connexions sont incluses par défaut.

Choisir une technique de répartition de charge

Alors, comment savoir quelle technique de répartition de charge convient le mieux à votre site web ou à votre application ?

Les profils de trafic varient tellement d’un site à l’autre – et même au sein d’un même site selon l’heure de la journée – qu’il n’est pas pertinent de choisir une technique d’équilibrage de charge en fonction d’une seule caractéristique (par exemple, un trafic en rafales ou régulier, des connexions de courte ou de longue durée, etc.). Cela étant, nous examinerons les avantages et les inconvénients de chaque méthode afin de vous aider à réduire l’éventail des options à envisager.

Exécuter des tests pour comparer les méthodes

Quel que soit le sous-ensemble de méthodes de répartition de charge que vous envisagez, nous vous encourageons à les tester afin de déterminer celle qui convient le mieux à votre trafic. « La meilleure » désigne généralement celle qui permet de transmettre les réponses aux clients dans les délais les plus courts, mais vos critères peuvent être différents.

La gestion des performances des applications est très utile pour ce type de test : vous pouvez créer des tableaux de bord personnalisés comportant des graphiques pour chacun des serveurs du groupe en amont, afin de les comparer en temps réel à mesure que les valeurs évoluent pendant le test. Plusieurs solutions APM proposent des plug-ins personnalisés pour NGINX Plus et NGINX, notamment AppDynamics, Datadog, Dynatrace et New Relic.

Les tests sont plus simples lorsque tous les serveurs ont la même capacité. Dans le cas contraire, vous devez définir la pondération des serveurs afin que les machines disposant d’une plus grande capacité reçoivent davantage de requêtes. Consultez la section « Définition de la pondération lorsque les serveurs ne sont pas identiques » ci-dessous.

Voici quelques métriques à vérifier pendant les tests :

• Charge du processeur et de la mémoire – Examinez le pourcentage de la capacité totale utilisée, tant pour le processeur que pour la mémoire. Si la charge n’est pas répartie uniformément entre tous les serveurs, le trafic n’est pas distribué efficacement.
• Temps de réponse des serveurs – Si le temps de réponse de certains serveurs est systématiquement plus élevé que celui des autres, cela signifie que des requêtes plus « lourdes » (nécessitant davantage de calculs ou d’appels à une base de données ou à d’autres services) leur sont adressées de manière déséquilibrée. Essayez d’ajuster les pondérations, car ce déséquilibre peut être dû à des pondérations incorrectes plutôt qu’à un problème lié à la technique d’équilibrage de charge.
• Temps total de réponse au client – Là encore, des temps systématiquement plus élevés pour certains serveurs indiquent qu’ils reçoivent une part disproportionnée des requêtes nécessitant beaucoup de temps. Vous pouvez à nouveau essayer d’ajuster les pondérations pour voir si cela résout le problème.
• Erreurs et requêtes ayant échoué – Vous devez vous assurer que le nombre de requêtes ayant échoué et d’autres erreurs survenues pendant les tests n’est pas supérieur à la normale pour votre site. Sinon, vous fondez votre décision sur des conditions d’erreur plutôt que sur un trafic réaliste. Pour certaines erreurs, le serveur peut envoyer sa réponse plus rapidement que lorsque la requête aboutit. Par exemple, pour le code de réponse HTTP 404 (Fichier non trouvé), le serveur renvoie probablement l’erreur bien plus rapidement qu’il ne pourrait fournir le fichier réel s’il existait. Avec les algorithmes d’équilibrage de charge Least Connections et Least Time, cela peut conduire l’équilibreur de charge à privilégier un serveur qui, en réalité, ne fonctionne pas correctement.

Avantages, inconvénients et cas d’utilisation

Examinons maintenant les avantages et les inconvénients de chaque technique d’équilibrage de charge, ainsi que certains cas d’usage auxquels elles sont particulièrement adaptées. Nous les présenterons par ordre croissant de pertinence pour la majorité des cas d’usage. En bref, nous considérons que Least Connections (et, pour NGINX Plus, Least Time) constituent les meilleurs choix pour le plus large éventail de cas d’usage.

Hachage et hachage IP

Les techniques d’équilibrage de charge Hash et IP Hash créent une association fixe entre un type donné de requête client (représenté par la valeur de hachage) et un serveur spécifique. Il s’agit de la persistance de session : toutes les requêtes ayant une valeur de hachage donnée sont toujours dirigées vers le même serveur.

Le principal inconvénient de ces méthodes est qu’elles ne garantissent pas une répartition égale des requêtes entre les serveurs, et encore moins une répartition uniforme de la charge. L’algorithme de hachage divise uniformément l’ensemble des valeurs de hachage possibles en « compartiments », un pour chaque serveur du groupe en amont, mais il est impossible de prévoir si les requêtes réellement reçues auront des valeurs de hachage uniformément réparties. Supposons, par exemple, que dix clients accèdent à un site et que l’algorithme IP Hash associe par hasard les valeurs de hachage de sept des adresses IP à web1, celle d’une adresse à web2, et celles de deux adresses à web3. Le serveur web1 finit par recevoir plus de deux fois plus de requêtes que tous les autres serveurs réunis.

Il est donc judicieux d’utiliser Hash ou IP Hash lorsque les avantages liés au maintien des sessions l’emportent sur les éventuels effets négatifs d’une répartition de charge déséquilibrée. Ce sont les seules formes de persistance de session disponibles dans NGINX. NGINX Plus propose trois autres mécanismes de persistance de session plus sophistiqués, qui fonctionnent conjointement avec un véritable équilibrage de charge (vous les configurez à l’aide de la directive sticky). Toutefois, même avec NGINX Plus, vous pouvez opter pour Hash ou IP Hash, car ces trois mécanismes ne fonctionnent pas dans les cas suivants :

• Le navigateur ou l’application cliente n’accepte pas les cookies, et l’application ne permet pas d’utiliser les mécanismes de persistance de session sans cookies. Utilisez la méthode IP Hash pour associer chaque client (plus précisément, son adresse IP) à un serveur particulier.
• Vous souhaitez envoyer systématiquement les requêtes concernant une URL donnée au même serveur afin de tirer parti de la mise en cache sur le serveur lui-même. Utilisez la méthode Hash avec la variable $request_uri pour récupérer le fichier sur le même serveur à chaque fois. Par exemple, supposons que vous sachiez que la diffusion d’un certain fichier .php nécessite plusieurs appels chronophages à la base de données, mais que les données récupérées changent rarement et peuvent donc être mises en cache. Si vous dirigez toutes les requêtes concernant ce fichier vers le même serveur, seul le premier client subit un long délai dû aux appels à la base de données. Pour tous les clients suivants, les données sont rapidement récupérées depuis le cache. Autre avantage : un seul serveur doit mettre en cache cet ensemble de données particulier. Comme vous évitez de mettre en cache les mêmes données sur chaque serveur, vous pouvez utiliser des caches plus petits.

Il existe quelques cas dans lesquels IP Hash – ainsi que Hash lorsque l’adresse IP du client fait partie de la clé – ne fonctionnent pas :

• Lorsque l’adresse IP du client peut changer au cours de la session, par exemple lorsqu’un client mobile passe d’un réseau Wi-Fi à un réseau cellulaire.
• Lorsque les requêtes d’un grand nombre de clients transitent par un proxy direct, car l’adresse IP du proxy est utilisée pour tous ces clients.

Les hachages sont déterministes (l’algorithme de hachage produit les mêmes résultats à chaque fois). Cela présente deux avantages : toutes les instances NGINX Plus ou NGINX d’un déploiement répartissent les requêtes exactement de la même manière, et l’association entre les hachages et les serveurs est conservée après les redémarrages de l’équilibreur de charge. (Elle est en réalité recalculée après le redémarrage, mais comme le résultat est toujours le même, elle est de fait conservée.)

En revanche, la modification de l’ensemble des serveurs en amont impose généralement de recalculer au moins certaines des associations, ce qui compromet la persistance des sessions. Vous pouvez réduire quelque peu le nombre d’associations recalculées :

• Pour la méthode de hachage, ajoutez le paramètre « consistent » à la directive « hash » ; NGINX Plus utilise l’algorithme de hachage ketama, ce qui réduit le nombre de remappages.
• Pour la méthode IP Hash, avant de retirer temporairement un serveur du groupe en amont, ajoutez le paramètre « down » à sa directive « server », comme pour web2 dans l’exemple suivant. Les mappages ne sont pas recalculés, car le serveur est supposé être bientôt remis en service.

upstream backend {    ip_hash;

    server web1;
    server web2 down;
    server web3;
}

Tourniquet

Comme indiqué précédemment, Round Robin est la méthode d’équilibrage de charge par défaut dans NGINX Plus et NGINX. C’est donc certainement la méthode la plus simple à choisir : vous n’avez rien d’autre à configurer que le groupe upstream lui-même.

Il est généralement admis que la méthode Round Robin fonctionne mieux lorsque les caractéristiques des serveurs et des requêtes ne risquent pas d’entraîner une surcharge de certains serveurs par rapport à d’autres. Voici quelques-unes de ces conditions :

• Tous les serveurs ont à peu près la même capacité. Cette exigence est moins importante si les différences entre les serveurs sont fidèlement représentées par leur pondération.
• Tous les serveurs hébergent le même contenu.
• Les requêtes nécessitent des temps de traitement ou une puissance de calcul relativement similaires. Si leur charge varie fortement, un serveur peut se retrouver surchargé parce que l’équilibreur de charge lui envoie par hasard un grand nombre de requêtes lourdes coup sur coup.
• Le volume de trafic n’est pas suffisamment élevé pour amener fréquemment les serveurs à fonctionner presque à pleine capacité. Si les serveurs sont déjà fortement sollicités, la répartition mécanique des requêtes effectuée par l’algorithme Round Robin risque davantage de pousser certains serveurs « au-delà de leurs limites » et de provoquer leur surcharge, comme décrit dans le point précédent.

La méthode Round Robin est particulièrement adaptée aux scénarios de test, car elle garantit que les requêtes sont réparties entre tous les serveurs en nombre égal (ou selon la pondération appropriée). Certaines autres méthodes ne répartissent pas toujours le trafic de manière uniforme lorsque le volume est faible, ce qui peut fausser les résultats des tests.

La répartition uniforme permet également de déterminer si les caches fonctionnent correctement et à pleine capacité : comme Round Robin ne permet pas d’envoyer les requêtes concernant un fichier donné au même serveur, chaque serveur est susceptible de servir et de mettre en cache un large éventail de fichiers (et généralement bon nombre des mêmes fichiers que les autres serveurs), ce qui augmente la probabilité que le cache se remplisse.

Enfin, la répartition initiale uniforme permet de détecter les problèmes de persistance de session dans NGINX Plus (telle qu’elle est configurée avec la directive « sticky »).

Nombre minimal de connexions et temps minimal

Comme nous l’avons indiqué précédemment, la méthode des connexions les moins nombreuses est la technique d’équilibrage de charge la mieux adaptée au plus large éventail de cas d’utilisation, en particulier au trafic de production. Les retours d’expérience de nos clients le confirment. Ses performances sont stables et prévisibles.

L’algorithme Least Connections répartit également efficacement la charge de travail entre les serveurs en fonction de leur capacité. Un serveur plus puissant traite les requêtes plus rapidement ; à tout moment, il est donc susceptible d’avoir moins de connexions encore en cours de traitement (ou même en attente de traitement) qu’un serveur moins performant. Least Connections envoie chaque requête au serveur ayant le moins de connexions actives et est donc plus susceptible de diriger les requêtes vers les serveurs puissants. (La définition de pondérations permet toutefois de répartir les requêtes encore plus efficacement, comme décrit dans la section Définition de pondérations lorsque les serveurs ne sont pas identiques ci-dessous.)

Vous pouvez considérer Least Time (NGINX Plus uniquement) comme une version plus sensible de Least Connections. En intégrant le temps de réponse moyen, cet algorithme tient compte de l’historique récent des performances du serveur (il s’agit en réalité d’une moyenne mobile à pondération exponentielle, de sorte que les temps de réponse plus anciens influent moins sur la moyenne que les plus récents).

Least Time est particulièrement adapté lorsque les serveurs en amont présentent des temps de réponse moyens très différents. Si, par exemple, vous disposez de serveurs dans différents centres de données à des fins de reprise après sinistre, Least Time tend à envoyer davantage de requêtes aux serveurs locaux, car ils répondent plus rapidement. Les environnements cloud, où les performances des serveurs sont souvent très imprévisibles, constituent un autre cas d’utilisation.

Définir des pondérations lorsque les serveurs ne sont pas identiques

Nous avons mentionné à plusieurs reprises l’importance de définir des pondérations pour les serveurs lorsque ceux du groupe en amont n’ont pas les mêmes capacités. C’est particulièrement important pour l’équilibreur de charge Round Robin, qui, sans cela, envoie le même nombre de requêtes à chaque serveur. Un serveur moins puissant risque alors d’être surchargé, tandis qu’un serveur plus puissant reste en partie inactif.

Pour définir les pondérations, ajoutez le paramètre « weight » à une ou plusieurs directives « server » dans le bloc « upstream ». La valeur par défaut est 1.

Vous pouvez envisager comme suit l’effet de la définition de pondérations sur les différentes techniques de répartition de charge. Gardez à l’esprit que ces descriptions sont correctes sur le plan conceptuel, mais que l’implémentation dans le code de NGINX Plus n’utilise pas nécessairement les opérations mathématiques indiquées. Voici le groupe de serveurs en amont utilisé dans nos exemples :

upstream backend {    server web1 weight=6;
    server web2 weight=3;
    server web3;
}

• Round Robin – Chaque serveur reçoit un pourcentage des requêtes entrantes égal à son poids divisé par la somme des poids. Dans notre exemple, sur dix requêtes, web1 en reçoit six (60 %), web2 en reçoit trois (30 %) et web3 en reçoit une (10 %).
• Hachage et Hachage IP – Rappelons que, sans pondération, l’algorithme de hachage répartit uniformément l’ensemble des valeurs de hachage possibles dans des « compartiments », à raison d’un par serveur du groupe en amont. Avec la pondération, il additionne les poids, répartit l’ensemble des valeurs de hachage possibles entre ce nombre de compartiments et associe à chaque serveur un nombre de compartiments correspondant à son poids. Dans notre exemple, il y a dix compartiments, contenant chacun 10 % des valeurs de hachage possibles. Six compartiments (60 % des valeurs de hachage possibles) sont associés à web1, trois compartiments (30 %) à web2 et un compartiment (10 %) à web3.
• Moins de connexions et Temps le plus court – Nous avons indiqué précédemment que, même sans pondération, ces algorithmes répartissent assez efficacement la charge de travail entre les serveurs en fonction de leur capacité. La définition de pondérations améliore encore leurs performances à cet égard. Rappelons que les algorithmes Moins de connexions et Temps le plus court envoient chaque requête au serveur ayant le « score » le plus faible (respectivement le nombre de connexions ou une combinaison mathématique du nombre de connexions et du temps). Lorsque vous attribuez des pondérations, l’équilibreur de charge divise le score de chaque serveur par sa pondération, puis envoie à nouveau la requête au serveur ayant la valeur la plus faible. Voici un exemple pour l’algorithme Moins de connexions, avec nos exemples de pondérations et le nombre indiqué de connexions actives : le score de web1, qui est de 100, est le plus faible ; il reçoit donc la requête, même si son nombre de connexions, qui s’élève à 600, est 1,5 fois supérieur à celui de web2 et plus de 4 fois supérieur à celui de web3.
  • web1 – 600 connexions actives ÷ 6 = 100
  • web2 – 400 connexions actives ÷ 3 = 133
  • web3 – 125 connexions actives ÷ 1 = 125

Résumé

Après avoir examiné les avantages et les inconvénients des techniques d’équilibrage de charge disponibles dans NGINX Plus et NGINX, nous estimons que Least Connections (et, pour NGINX Plus, Least Time) convient au plus large éventail de cas d’utilisation. Il est toutefois important de tester plusieurs méthodes dans votre déploiement, car la combinaison particulière des caractéristiques de votre trafic et de vos serveurs pourrait rendre une autre méthode plus adaptée.

Pour essayer vous-même l’équilibrage de charge de NGINX Plus, commencez votre essai gratuit de 30 jours dès aujourd’hui ou contactez-nous pour discuter de vos cas d’utilisation.

Nous serions ravis de connaître votre expérience de l’équilibrage de charge dans différents cas d’utilisation. N’hésitez pas à la partager dans la section des commentaires ci-dessous.

À propos de l’auteur

Tony Mauro

Autres articles de Tony Mauro