NGINX Plus et les équilibreurs de charge Microsoft Azure

Michael Pleshakov

[Note de la rédaction – Cet article a été mis à jour afin de refléter les fonctionnalités prises en charge par NGINX Plus et les services d’équilibrage de charge Azure en juin 2021. Il fait également référence à l’API NGINX Plus, qui remplace et rend obsolète le module distinct de configuration dynamique mentionné dans la version originale de l’article.]

Les clients qui utilisent Microsoft Azure disposent de trois options pour l’équilibrage de charge : NGINX Plus, les services d’équilibrage de charge Azure, ou NGINX Plus conjointement avec les services d’équilibrage de charge Azure. Cet article vise à vous fournir suffisamment d’informations pour prendre une décision et vous montre également comment l’utilisation de NGINX Plus avec Azure Load Balancer peut vous offrir un équilibreur de charge HTTP hautement disponible doté de riches fonctionnalités de couche 7.

Vue d’ensemble

Microsoft Azure propose à ses utilisateurs deux options d’équilibrage de charge : Azure Load Balancer pour l’équilibrage de charge TCP/UDP de base (au niveau de la couche 4, la couche réseau) et Azure Application Gateway pour l’équilibrage de charge HTTP/HTTPS (au niveau de la couche 7, la couche application). Bien que ces solutions conviennent aux cas d’utilisation simples, elles n’offrent pas de nombreuses fonctionnalités incluses de série dans NGINX Plus.

Voici une comparaison générale entre NGINX Plus et les offres d’équilibrage de charge d’Azure :

Examinons maintenant certaines des différences entre NGINX Plus et les services d’équilibrage de charge Azure, leurs fonctionnalités propres, ainsi que la manière dont NGINX Plus et les équilibreurs de charge Azure peuvent fonctionner ensemble.

Comparaison de NGINX Plus et des services d’équilibrage de charge Azure

Méthodes d’équilibrage de charge

NGINX Plus propose plusieurs méthodes d’équilibrage de charge en plus de la méthode Round Robin utilisée par défaut :

• Moins de connexions – Chaque requête est envoyée au serveur ayant le plus petit nombre de connexions actives.
• Temps minimal – Chaque requête est envoyée au serveur ayant le score le plus faible, calculé à partir d’une combinaison pondérée de la latence moyenne et du nombre le plus faible de connexions actives.
• Hachage IP – Chaque requête est envoyée au serveur déterminé par l’adresse IP source de la requête.
• Hachage générique – Chaque requête est envoyée au serveur déterminé à partir d’une clé définie par l’utilisateur, qui peut contenir n’importe quelle combinaison de texte et de variables NGINX, par exemple les variables correspondant aux champs d’en-tête Adresse IP source et Port source, ou à l’URI.
• Aléatoire – Chaque requête est envoyée à un serveur sélectionné de manière aléatoire. Lorsque le paramètre two est inclus, NGINX Plus sélectionne deux serveurs de manière aléatoire, puis choisit l’un d’eux à l’aide de l’algorithme du plus petit nombre de connexions (par défaut) ou du temps le plus court, selon la configuration.

Toutes ces méthodes peuvent être étendues en attribuant différentes valeurs de pondération à chaque serveur backend. Pour plus de détails sur ces méthodes, consultez le Guide d’administration de NGINX Plus.

Azure Load Balancer propose une seule méthode d’équilibrage de charge, Hachage, qui utilise par défaut une clé basée sur les champs d’en-tête Adresse IP source, Port source, Adresse IP de destination, Port de destination et Protocole pour choisir un serveur backend.

Azure Application Gateway fournit uniquement une méthode de répartition à tour de rôle.

Persistance de session

La persistance de session, également appelée « sessions persistantes » ou « affinité de session », est nécessaire lorsqu’une application exige que toutes les requêtes d’un client donné continuent d’être envoyées au même serveur backend, car l’état du client n’est pas partagé entre les serveurs backend.

NGINX Plus prend en charge trois méthodes avancées de persistance de session :

• Cookie persistant – NGINX Plus ajoute un cookie de session à la première réponse du groupe en amont pour un client donné. Ce cookie identifie le serveur backend utilisé pour traiter la requête. Le client inclut ce cookie dans les requêtes suivantes, et NGINX Plus l’utilise pour diriger la requête du client vers le même serveur backend.
• Apprentissage de l’affinité – NGINX Plus surveille les requêtes et les réponses afin de repérer les identifiants de session (généralement des cookies) et les utilise pour déterminer le serveur auquel adresser les requêtes suivantes d’une même session.
• Routage persistant – Il est possible de configurer une correspondance entre les valeurs de routage et les serveurs backend afin que NGINX Plus recherche une valeur de routage dans les requêtes et sélectionne le serveur backend correspondant.

NGINX Plus propose également deux méthodes de base de persistance de session, mises en œuvre sous la forme de deux des méthodes d’équilibrage de charge décrites ci-dessus :

• Hachage IP – Le serveur backend est déterminé par l’adresse IP de la requête.
• Hachage – Le serveur backend est déterminé à partir d’une clé définie par l’utilisateur, par exemple Adresse IP source et Port source, ou à partir de l’URI.

Azure Load Balancer prend en charge l’équivalent de la méthode de hachage de NGINX Plus, bien que la clé soit limitée à certaines combinaisons des champs d’en-tête Adresse IP source, Port source, Adresse IP de destination, Port de destination et Protocole.

Azure Application Gateway prend en charge l’équivalent de la méthode Sticky Cookie de NGINX Plus, avec les limitations suivantes : vous ne pouvez pas configurer le nom du cookie, sa date d’expiration, le domaine, le chemin d’accès, ni les attributs de cookie HttpOnly ou Secure.

Remarque : Lorsque vous utilisez Azure Load Balancer, la méthode IP Hash de NGINX Plus ou la méthode Hash de NGINX Plus avec l’adresse IP source incluse dans la clé, la persistance de session ne fonctionne correctement que si l’adresse IP du client reste la même pendant toute la session. Ce n’est pas toujours le cas, par exemple lorsqu’un client mobile passe d’un réseau Wi-Fi à un réseau cellulaire. Pour que les requêtes continuent d’être dirigées vers le même serveur backend, il est préférable d’utiliser l’une des méthodes avancées de persistance de session répertoriées ci-dessus.

Contrôles d’intégrité

Azure Load Balancer et Azure Application Gateway prennent en charge des contrôles d’intégrité de base des applications. Vous pouvez spécifier l’URL interrogée par l’équilibreur de charge. Celui-ci considère le serveur principal comme opérationnel s’il reçoit le code de retour HTTP attendu 200. Vous pouvez spécifier la fréquence des contrôles d’intégrité et le délai d’expiration au-delà duquel le serveur est considéré comme défaillant. Avec Azure Application Gateway, vous pouvez également personnaliser le code de réponse attendu et vérifier qu’il correspond au contenu du corps de la réponse.

NGINX Plus étend cette fonctionnalité grâce à des contrôles d’intégrité avancés. En plus de spécifier l’URL à utiliser, NGINX Plus vous permet d’insérer des en-têtes dans la requête, de rechercher différents codes de réponse et d’examiner à la fois les en-têtes et le corps de la réponse.

Une fonctionnalité connexe utile de NGINX Plus est le démarrage progressif. NGINX Plus augmente progressivement la charge envoyée à un serveur nouveau ou récemment rétabli afin qu’il ne soit pas submergé par les connexions. Cette fonctionnalité est utile lorsque vos serveurs backend nécessitent un certain temps de préchauffage et risquent de tomber en panne s’ils reçoivent la totalité de leur part de trafic dès qu’ils sont considérés comme opérationnels.

NGINX Plus prend également en charge les contrôles d’intégrité des serveurs TCP et UDP, qui vous permettent de spécifier une chaîne à envoyer et une chaîne à rechercher dans la réponse.

Azure Load Balancer prend en charge les contrôles d’intégrité TCP, mais n’offre pas ce niveau de surveillance.

Terminaison SSL/TLS

NGINX Plus prend en charge la terminaison SSL/TLS, tout comme Azure Application Gateway. Ce n’est pas le cas d’Azure Load Balancer.

Limites de connexions et de débit

Avec NGINX Plus, vous pouvez configurer plusieurs limites afin de contrôler le trafic entrant et sortant de votre instance NGINX Plus. Vous pouvez notamment limiter les connexions entrantes, les connexions aux nœuds backend, le débit des requêtes entrantes et le débit de transmission des données de NGINX Plus vers les clients.

Azure Application Gateway et Azure Load Balancer ne prennent pas en charge les limites de débit ou de connexions. Toutefois, vous pouvez utiliser d’autres services Azure pour configurer et activer la limitation du débit.

Prise en charge des protocoles, réécriture et redirection des URL

NGINX Plus, Azure Application Gateway et Azure Load Balancer prennent tous en charge les éléments suivants :

• HTTP/2 – NGINX Plus accepte les requêtes HTTP/2 des clients depuis 2016. Azure a ajouté la prise en charge de WebSocket plus récemment.
• WebSocket – NGINX Plus accepte les connexions WebSocket des clients depuis 2014. Azure a ajouté la prise en charge de WebSocket plus récemment.
• Réécriture d’URL et redirection des requêtes – L’URL d’une requête peut être modifiée avant sa transmission à un serveur backend. Vous pouvez ainsi modifier en interne les chemins des requêtes et l’emplacement des fichiers sans changer les URL communiquées aux clients. Vous pouvez également rediriger les requêtes, par exemple en remplaçant le protocole HTTP d’une requête par HTTPS.

NGINX Plus avec les services d’équilibrage de charge Azure

Lorsqu’il est utilisé conjointement avec Azure Load Balancer et Azure Traffic Manager, NGINX Plus constitue une solution d’équilibrage de charge hautement disponible, dotée de fonctionnalités avancées de couche 7.

Haute disponibilité actif-actif

En utilisant Azure Load Balancer pour répartir la charge entre les instances NGINX Plus d’un groupe à haute disponibilité, vous créez un équilibreur de charge hautement disponible au sein d’une région.

Mise à l’échelle automatique de NGINX Plus

Vous pouvez configurer la mise à l’échelle automatique des instances NGINX Plus en fonction de l’utilisation moyenne du processeur. Pour ce faire, créez des groupes à haute disponibilité dans le service cloud Azure qui héberge vos instances NGINX Plus. Vous devez veiller à la synchronisation des fichiers de configuration de NGINX Plus.

Mise à l’échelle automatique des instances backend

Vous pouvez également configurer la mise à l’échelle automatique de vos instances backend en fonction de l’utilisation moyenne du processeur en créant des groupes à haute disponibilité dans le service cloud Azure qui héberge vos instances backend. Vous devez veiller à ajouter ou supprimer les instances backend dans la configuration de NGINX Plus, ce que vous pouvez faire à l’aide de l’API NGINX Plus.

Pour automatiser les mises à jour de la configuration de NGINX Plus (que ce soit en association avec des groupes à haute disponibilité ou lorsque NGINX Plus est utilisé seul), vous pouvez intégrer un système de découverte de services à NGINX Plus, soit via l’API NGINX Plus, soit via DNS si le système dispose d’une interface DNS. Consultez nos articles de blog sur l’utilisation de NGINX Plus avec les systèmes de découverte de services les plus courants :

• Découverte de services pour NGINX Plus à l’aide des enregistrements DNS SRV de Consul
• Découverte de services pour NGINX Plus à l’aide des API Consul
• Découverte de services pour NGINX Plus avec etcd
• Découverte de services pour NGINX Plus avec ZooKeeper

Intégration à Azure Traffic Manager

Pour un environnement distribué à l’échelle mondiale, vous pouvez utiliser Azure Traffic Manager afin de répartir le trafic des clients entre plusieurs régions.

Fonctionnalités supplémentaires des services d’équilibrage de charge Azure

Azure Load Balancer et Application Gateway sont gérés par Azure Cloud et offrent tous deux une solution d’équilibrage de charge à haute disponibilité.

Une fonctionnalité d’Azure Load Balancer qui n’est pas disponible dans NGINX Plus est la NAT source, qui permet au trafic sortant des instances backend d’utiliser la même adresse IP source que l’équilibreur de charge.

Azure Load Balancer assure une reconfiguration automatique lors de l’utilisation de la fonctionnalité de mise à l’échelle automatique d’Azure Cloud.

Résumé

Si vos besoins en matière d’équilibrage de charge sont simples, les offres d’équilibrage de charge Azure peuvent constituer une bonne solution. Lorsque les besoins deviennent plus complexes, NGINX Plus est un choix judicieux. Vous pouvez utiliser NGINX Plus seul ou conjointement avec Azure Load Balancer afin d’assurer la haute disponibilité des instances NGINX Plus.

Pour essayer NGINX Plus sur Microsoft Azure, commencez votre essai gratuit de 30 jours dès aujourd’hui ou contactez-nous pour discuter de vos cas d’utilisation.

À propos de l’auteur

Michael Pleshakov

Autres articles de Michael Pleshakov