Équilibreurs de charge NGINX Plus et Microsoft Azure

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

Les clients utilisant Microsoft Azure ont trois options pour équilibrer la charge : NGINX Plus , les services d’équilibrage de charge Azure ou NGINX Plus en conjonction avec les services d’équilibrage de charge Azure. Cet article vise à vous donner 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 avec de riches fonctionnalités de couche 7 .

Aperçu

Microsoft Azure offre à ses utilisateurs deux choix d'équilibreur 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 fonctionnent pour des cas d’utilisation simples, elles ne fournissent pas de nombreuses fonctionnalités fournies en standard avec NGINX Plus.

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

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

Comparaison des services NGINX Plus et Azure Load Balancing

Méthodes d'équilibrage de charge

NGINX Plus propose un choix de plusieurs méthodes d'équilibrage de charge en plus de la méthode Round Robin par défaut :

• Moins de connexions – Chaque requête est envoyée au serveur avec le plus petit nombre de connexions actives.
• Temps minimum – Chaque requête est envoyée au serveur avec le score le plus bas, qui est calculé à partir d’une combinaison pondérée de la latence moyenne et du nombre le plus bas 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é au hasard. Lorsque les deux paramètres sont inclus, NGINX Plus sélectionne deux serveurs au hasard, puis choisit entre eux en utilisant soit l'algorithme Least Connections (par défaut), soit Least Time, selon la configuration.

Toutes les méthodes peuvent être étendues en attribuant des valeurs de poids différentes à chaque serveur backend. Pour plus de détails sur les méthodes, consultez le Guide d'administration NGINX Plus.

Azure Load Balancer propose une méthode d’équilibrage de charge, Hash , 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 back-end.

Azure Application Gateway fournit uniquement une méthode round-robin .

Persistance de la session

La persistance de session , également connue sous le nom de sessions persistantes ou d'affinité de session , est nécessaire lorsqu'une application exige que toutes les requêtes d'un client spécifique continuent d'être envoyées au même serveur principal, car l'état du client n'est pas partagé entre les serveurs principaux.

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

• Cookie collant – 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 qui a été utilisé pour traiter la demande. Le client inclut ce cookie dans les demandes ultérieures et NGINX Plus l'utilise pour diriger la demande du client vers le même serveur backend.
• Sticky Learn – NGINX Plus surveille les demandes et les réponses pour localiser les identifiants de session (généralement des cookies) et les utilise pour déterminer le serveur pour les demandes ultérieures dans une session.
• Sticky Route – Un mappage entre les valeurs de route et les serveurs back-end peut être configuré afin que NGINX Plus surveille les demandes pour une valeur de route et choisisse le serveur back-end correspondant.

NGINX Plus propose également deux méthodes de persistance de session de base, implémentées comme 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 l’adresse IP source et le port source , ou l’URI.

Azure Load Balancer prend en charge l’équivalent de la méthode de hachage 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 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 ou les attributs de cookie HttpOnly ou Secure .

Note: Lorsque vous utilisez Azure Load Balancer, la méthode de hachage IP NGINX Plus ou la méthode de hachage IP NGINX Plus avec l’ adresse IP source incluse dans la clé, la persistance de session fonctionne correctement uniquement si l’adresse IP du client reste la même tout au long de la session. Ce n’est pas toujours le cas, comme lorsqu’un client mobile passe d’un réseau WiFi à un réseau cellulaire, par exemple. Pour garantir que les requêtes continuent d’atteindre le même serveur principal, 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 de santé

Azure Load Balancer et Azure Application Gateway prennent en charge les contrôles d’intégrité des applications de base. Vous pouvez spécifier l'URL demandée par l'équilibreur de charge et il considère que le serveur principal est sain s'il reçoit le HTTP attendu200 code de retour. Vous pouvez spécifier la fréquence de vérification de l'état et le délai d'expiration avant que le serveur ne soit considéré comme défectueux. Avec Azure Application Gateway, vous pouvez également personnaliser le code de réponse attendu et le faire correspondre au contenu du corps de la réponse.

NGINX Plus étend cette fonctionnalité avec des contrôles de santé avancés . En plus de spécifier l'URL à utiliser, avec NGINX Plus, vous pouvez insérer des en-têtes dans la demande et rechercher différents codes de réponse, et examiner à la fois les en-têtes et le corps de la réponse.

Une fonctionnalité utile associée à NGINX Plus est le démarrage lent . NGINX Plus augmente progressivement la charge sur un serveur nouveau ou récemment récupéré afin qu'il ne soit pas submergé par les connexions. Cela est utile lorsque vos serveurs principaux nécessitent un certain temps de préchauffage et échoueront s'ils reçoivent leur pleine part de trafic dès qu'ils s'avèrent sains.

NGINX Plus prend également en charge les contrôles de santé sur les 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.

Résiliation SSL/TLS

NGINX Plus prend en charge la terminaison SSL/TLS , tout comme Azure Application Gateway . Azure Load Balancer ne le fait pas.

Limites de connexion et de débit

Avec NGINX Plus, vous pouvez configurer plusieurs limites pour contrôler le trafic vers et depuis votre instance NGINX Plus. Il s'agit notamment de limiter les connexions entrantes , les connexions aux nœuds back-end , le taux de requêtes entrantes et le taux de transmission de données de NGINX Plus aux clients.

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

Prise en charge du protocole et réécriture et redirection d'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 de requête – L'URL d'une requête peut être modifiée avant d'être transmise à un serveur backend, ce qui signifie que vous pouvez modifier les chemins de requête et les emplacements de fichiers en interne sans modifier les URL annoncées aux clients. Vous pouvez également rediriger les requêtes, par exemple en modifiant le schéma d'une requête HTTP en HTTPS.

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

Lorsqu'il est utilisé avec Azure Load Balancer et Azure Traffic Manager , NGINX Plus devient une solution d'équilibrage de charge hautement disponible avec de riches fonctionnalités de couche 7.

Haute disponibilité active-active

En utilisant Azure Load Balancer pour équilibrer la charge entre les instances NGINX Plus dans un groupe de disponibilité , vous créez un équilibreur de charge hautement disponible dans 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. Cela est possible en créant des ensembles de disponibilité dans le service cloud Azure qui héberge vos instances NGINX Plus. Vous devez prendre en charge la synchronisation des fichiers de configuration NGINX Plus.

Instances backend à mise à l'échelle automatique

Vous pouvez également configurer la mise à l'échelle automatique de vos instances backend en fonction de l'utilisation moyenne du processeur. Cela est possible en créant des ensembles de disponibilité dans le service cloud Azure qui héberge vos instances back-end. Vous devez prendre soin d'ajouter ou de supprimer des instances backend de la configuration NGINX Plus, ce qui est possible avec l' API NGINX Plus .

Pour automatiser les mises à jour de la configuration NGINX Plus (soit en combinaison avec des ensembles de disponibilité, soit lors de l'utilisation de NGINX Plus 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 populaires :

• 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 avec Azure Traffic Manager

Pour un environnement distribué à l’échelle mondiale, vous pouvez utiliser Azure Traffic Manager pour distribuer le trafic des clients dans de nombreuses régions.

Fonctionnalités supplémentaires dans Azure Load Balancing Services

Azure Load Balancer et Application Gateway sont gérés par Azure Cloud et fournissent tous deux une solution d’équilibrage de charge hautement disponible.

Une fonctionnalité d’Azure Load Balancer qui n’est pas disponible dans NGINX Plus est la NAT source , dans laquelle le trafic sortant des instances back-end a la même adresse IP source que l’équilibreur de charge.

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

Résumé

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

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