Pourquoi Elastic Load Balancing achemine-t-il de façon inégale le trafic de mon équilibreur de charge ?

Lecture de 7 minute(s)
0

J'ai configuré mon équilibreur de charge pour acheminer le trafic de manière égale entre les instances ou les zones de disponibilité. Toutefois, Elastic Load Balancing (ELB) achemine davantage de trafic vers une instance ou une zone de disponibilité que vers les autres. Pourquoi cela se produit-il et comment puis-je résoudre le problème ?

Brève description

ELB peut acheminer le trafic de façon inégale vers vos cibles si :

  • les clients acheminent des requêtes vers une adresse IP incorrecte d'un nœud d'équilibreur de charge avec un enregistrement DNS dont la durée de vie a expiré ;
  • les sessions permanentes (affinité de session) sont activées pour l'équilibreur de charge ; les sessions permanentes utilisent des cookies pour aider le client à maintenir une connexion à la même instance pendant la durée de vie d'un cookie, ce qui peut entraîner des déséquilibres au fil du temps ;
  • les instances saines disponibles ne sont pas uniformément réparties entre les zones de disponibilité ;
  • les instances avec un type de capacité spécifique ne sont pas également réparties entre les zones de disponibilité ;
  • il existe des connexions TCP durables entre les clients et les instances ;
  • la connexion utilise un WebSocket.

Solution

Confirmer le déséquilibre du trafic

S'ils sont disponibles, analysez les journaux d'accès ELB pour confirmer le déséquilibre du trafic. Utilisez les outils de ligne de commande pour trouver le nombre de demandes acheminées par l'équilibreur de charge vers des applications spécifiques.

Pour les équilibreurs de charge d'application :

awk '{print $5}' *.log | awk -F ":" '{print $1}' | sort | uniq -c | sort -r

Pour les équilibreurs Classic Load Balancer :

awk '{print $4}' *.log | awk -F ":" '{print $1}' | sort | uniq -c | sort -r

ELB ajoute des fichiers individuels à votre compartiment pour chaque nœud ELB. Vous pouvez comparer le nombre de lignes de vos fichiers journaux d'accès sur une période donnée.

Vider le cache DNS

Le routage basé sur les entrées DNS obsolètes entraîne un modèle RequestCount déséquilibré dans différentes zones de disponibilité. Pour plus d'informations, consultez Métriques Application Load Balancer ou Métriques Classic Load Balancer. Videz le cache DNS de votre client pour vous assurer qu'il utilise les enregistrements DNS actuels pour les nœuds d'équilibreur de charge.

**Remarque :**lorsque l'équilibrage de charge entre zones est activé, l'équilibreur de charge peut toujours équilibrer uniformément les requêtes au niveau de l'instance.

Pour les clients Linux utilisant nscd pour la mise en cache DNS, exécutez l'une des commandes suivantes :

sudo /etc/init.d/nscd restart
# service nscd restart
# service nscd reload

Pour les clients Linux utilisant dnsmasq pour la mise en cache DNS, exécutez l'une des commandes suivantes :

$ sudo /etc/init.d/dnsmasq restart
# service dnsmasq restart

Pour les clients Linux utilisant BIND pour la mise en cache DNS, exécutez l'une des commandes suivantes :

# /etc/init.d/named restart
# rndc restart
# rndc exec

Pour les clients Windows, exécutez la commande suivante :

ipconfig /flushdns

Remarque : si vous avez effacé le cache DNS de votre client, mais que vous rencontrez toujours des problèmes de mise en cache, assurez-vous que votre application client ne met pas en cache les enregistrements DNS.

Vérifier la configuration des sessions permanentes

Si vous utilisez la permanence de session basée sur la durée, configurez un délai d'expiration de cookie approprié pour votre cas d'utilisation spécifique. Pour plus d'informations, consultez :

Si vous définissez la permanence de session à partir d'applications individuelles, utilisez autant que possible des cookies de session plutôt que des cookies permanents. Pour plus d'informations, consultez Permanence des sessions contrôlées par application (Classic Load Balancers).

Vérifier une distribution d'instance saine entre les zones de disponibilité

Si le nombre d'instances saines disponibles dans vos différentes zones de disponibilité est inégal et que l'équilibrage de charge entre zones est désactivé, ELB doit équilibrer les requêtes sur moins d'instances dans les zones de disponibilité concernées. Les instances saines restantes traitent un plus grand nombre de requêtes afin de compenser, ce qui peut avoir un impact négatif sur les performances.

Remarque : un déséquilibre de charge du trafic entre les instances ou les zones de disponibilité ne signifie pas nécessairement que l'utilisation des ressources est également déséquilibrée. Par exemple, un déséquilibre peut se produire lorsqu'une ou plusieurs instances derrière un équilibreur de charge traitent les requêtes plus rapidement que les autres.

Maintenez un nombre égal d'instances dans chaque zone de disponibilité activée. Pour ajouter d'autres instances en tant que cibles d'équilibreur de charge, consultez :

Pour les équilibreurs Classic Load Balancer et Network Load Balancer, envisagez d'activer l'équilibrage de charge entre zones afin de répartir les requêtes au niveau des instances plutôt qu'au niveau des zones de disponibilité. Pour plus d'informations, consultez Équilibrage de charge entre zones (Network Load Balancers) ou Configuration de l'équilibrage de charge entre zones pour votre Classic Load Balancer. L'équilibrage de charge entre zones est toujours activé pour les équilibreurs de charge d'application.

Vérifier la distribution du type d'instance

Un Classic Load Balancer avec des écouteurs HTTP ou HTTPS peut acheminer davantage de trafic vers des types d'instance à plus grande capacité. Cette distribution vise à empêcher les types d'instance à faible capacité d'avoir un trop grand nombre de requêtes en attente. Pour plus d'informations, consultez Types d'instances. Il est recommandé d'utiliser des types d'instance et des configurations similaires pour réduire les risques d'écarts de capacité et de déséquilibre de trafic.

Un déséquilibre du trafic peut également se produire si vous avez des instances de capacités similaires s'exécutant sur différentes Amazon Machine Images (AMI). Dans ce scénario, le déséquilibre du trafic en faveur des types d'instance à plus grande capacité est souhaitable.

Vérifier les connexions TCP durables

Elastic Load Balancing achemine le trafic TCP à l'aide d'un algorithme round-robin. Les connexions TCP durables entre les clients et les instances entraînent une distribution inégale de la charge du trafic. Par conséquent, les nouvelles instances prennent plus de temps pour atteindre un équilibre de connexion. Assurez-vous de vérifier vos métriques pour les connexions TCP durables susceptibles de provoquer des problèmes. Notez également qu'avec les écouteurs TCP, l'équilibreur de charge répartit le trafic uniquement au niveau de la connexion. Cela signifie, par exemple, que les clients qui réutilisent fréquemment des connexions pour envoyer et recevoir plusieurs requêtes HTTP peuvent produire un trafic déséquilibré au niveau de l'instance. Envisagez de passer à un équilibreur de charge Layer 7 si votre application prend en charge des protocoles réseau de couche supérieure tels que HTTP, HTTPS, WebSocket ou HTTP2.

Vérifiez les modèles RequestCount de votre équilibreur de charge et les autres métriques pertinentes. Pour plus d'informations, consultez :

Vérifier les connexions WebSocket

Les clients utilisant des équilibreurs de charge avec des connexions WebSocket utilisent une connexion 1:1 entre le client et la cible. Cette connexion reste bloquée à la cible pendant la durée de la connexion WebSocket, ce qui entraîne une répartition inégale du trafic. Les Application Load Balancers fournissent un support natif pour WebSockets Seules les nouvelles requêtes HTTP mises à niveau vers WebSockets sont dirigées vers les nouvelles cibles. Les WebSockets fonctionnent également avec les Classic Load Balancers et les Network Load Balancers disposant d'un écouteur de couche 4.

Pour plus d'informations, consultez Configuration de l'écouteur.


AWS OFFICIEL
AWS OFFICIELA mis à jour il y a 2 ans