Nous essayons d'exécuter une configuration assez simple sur Amazon EC2 - plusieurs serveurs HTTP assis derrière un Amazon Elastic Load Balancer (ELB).

Notre domaine est géré dans Route53, et nous avons un enregistrement CNAME configuré pour pointer vers l'ELB.

Nous avons rencontré des problèmes où certains emplacements, mais pas tous, ne peuvent pas se connecter par intermittence à l'équilibreur de charge; il semble que ce soit la résolution du nom de domaine de l'ELB.

Le support d'Amazon nous a informés que l'IP Elastic sous-jacent de l'équilibreur de charge a changé et que le problème est que certains serveurs DNS des FAI n'honorent pas le TTL. Nous ne sommes pas satisfaits de cette explication, car nous avons reproduit le problème en utilisant les propres serveurs DNS d'Amazon à partir d'une instance EC2, ainsi que sur les FAI locaux en Australie et via le serveur DNS de Google ( 8.8.8.8).

Amazon a également confirmé que pendant la période où nous avons remarqué des temps d'arrêt de certains endroits, le trafic passant par l'ELB était en baisse significative - donc le problème n'est pas avec nos points de terminaison.

Fait intéressant, le domaine semble se résoudre à l'IP correcte sur les serveurs qui ne peuvent pas se connecter - mais la tentative d'établissement d'une connexion TCP échoue.

Toutes les instances attachées à l'ELB ont toujours été saines. Ils sont tous

Quelqu'un sait-il comment procéder pour diagnostiquer ce problème plus en profondeur? Quelqu'un d'autre a-t-il rencontré ce problème avec Elastic Load Balancer?

Merci,

J'ai trouvé cette question lors de la recherche sur Google pour diagnostiquer les équilibreurs de charge élastique Amazon (ELB) et je veux y répondre pour toute autre personne comme moi qui a eu ce problème sans beaucoup de conseils.

Propriétés ELB

Les ELB ont des propriétés intéressantes. Par exemple:

• Les ELB sont constitués de 1 ou plusieurs nœuds
• Ces nœuds sont publiés en tant qu'enregistrements A pour le nom ELB
• Ces nœuds peuvent échouer ou être fermés et les connexions ne seront pas fermées correctement
• Cela nécessite souvent une bonne relation avec le support Amazon ($$$) pour amener quelqu'un à creuser dans les problèmes ELB

REMARQUE: Une autre propriété intéressante mais légèrement moins pertinente est que les ELB n'ont pas été conçus pour gérer les pointes de trafic soudaines. Ils nécessitent généralement 15 minutes de trafic intense avant de se développer ou ils peuvent être préchauffés sur demande via un ticket d'assistance

Dépannage des ELB (manuellement)

Mise à jour: AWS a depuis migré tous les ELB pour utiliser Route 53 pour DNS. De plus, tous les ELB ont désormais un all.$elb_nameenregistrement qui renverra la liste complète des nœuds pour l'ELB. Par exemple, si votre nom ELB est elb-123456789.us-east-1.elb.amazonaws.com, vous obtiendrez la liste complète des nœuds en faisant quelque chose comme dig all.elb-123456789.us-east-1.elb.amazonaws.com. Pour les nœuds IPv6, all.ipv6.$elb_namefonctionne également. De plus, Route 53 est capable de renvoyer jusqu'à 4 Ko de données en utilisant toujours UDP, donc l'utilisation de l' +tcpindicateur peut ne pas être nécessaire.

Sachant cela, vous pouvez faire vous-même un peu de dépannage. Tout d'abord, résolvez le nom ELB en une liste de nœuds (en tant qu'enregistrements A):

$ dig @ns-942.amazon.com +tcp elb-123456789.us-east-1.elb.amazonaws.com ANY

L' tcpindicateur est suggéré car votre ELB pourrait avoir trop d'enregistrements pour tenir dans un seul paquet UDP. On m'a également dit, mais je n'ai pas personnellement confirmé, qu'Amazon n'affichera que jusqu'à 6 nœuds, sauf si vous effectuez une ANYrequête. L'exécution de cette commande vous donnera une sortie qui ressemble à ceci (rognée pour plus de concision):

;; ANSWER SECTION:
elb-123456789.us-east-1.elb.amazonaws.com. 60 IN SOA ns-942.amazon.com. root.amazon.com. 1376719867 3600 900 7776000 60
elb-123456789.us-east-1.elb.amazonaws.com. 600 IN NS ns-942.amazon.com.
elb-123456789.us-east-1.elb.amazonaws.com. 60 IN A 54.243.63.96
elb-123456789.us-east-1.elb.amazonaws.com. 60 IN A 23.21.73.53

Maintenant, pour chacun des Aenregistrements, utilisez par exemple curlpour tester une connexion à l'ELB. Bien sûr, vous souhaitez également isoler votre test uniquement sur l'ELB sans vous connecter à vos backends. Une dernière propriété et un fait peu connu sur les ELB:

• La taille maximale de la méthode de requête (verbe) qui peut être envoyée via un ELB est de 127 caractères . Tout plus grand et l'ELB répondra avec un HTTP 405 - Méthode non autorisée .

Cela signifie que nous pouvons profiter de ce comportement pour tester uniquement que l'ELB répond:

$ curl -X $(python -c 'print "A" * 128') -i http://ip.of.individual.node
HTTP/1.1 405 METHOD_NOT_ALLOWED
Content-Length: 0
Connection: Close

Si vous voyez, HTTP/1.1 405 METHOD_NOT_ALLOWEDl'ELB répond avec succès. Vous pouvez également ajuster les délais d'expiration de curl à des valeurs qui vous conviennent.

Dépannage des ELB avec elbping

Bien sûr, cela peut devenir assez fastidieux, j'ai donc construit un outil pour automatiser cela appelé elbping . Il est disponible sous forme de gemme rubis, donc si vous avez des rubygèmes, vous pouvez l'installer en faisant simplement:

$ gem install elbping

Vous pouvez maintenant exécuter:

$ elbping -c 4 http://elb-123456789.us-east-1.elb.amazonaws.com
Response from 54.243.63.96: code=405 time=210 ms
Response from 23.21.73.53: code=405 time=189 ms
Response from 54.243.63.96: code=405 time=191 ms
Response from 23.21.73.53: code=405 time=188 ms
Response from 54.243.63.96: code=405 time=190 ms
Response from 23.21.73.53: code=405 time=192 ms
Response from 54.243.63.96: code=405 time=187 ms
Response from 23.21.73.53: code=405 time=189 ms
--- 54.243.63.96 statistics ---
4 requests, 4 responses, 0% loss
min/avg/max = 187/163/210 ms
--- 23.21.73.53 statistics ---
4 requests, 4 responses, 0% loss
min/avg/max = 188/189/192 ms
--- total statistics ---
8 requests, 8 responses, 0% loss
min/avg/max = 188/189/192 ms

N'oubliez pas que si vous voyez code=405cela signifie que l'ELB répond.

Prochaines étapes

Quelle que soit la méthode que vous choisissez, vous saurez au moins si les nœuds de votre ELB répondent ou non. Armé de cette connaissance, vous pouvez soit vous concentrer sur le dépannage d'autres parties de votre pile, soit être en mesure de démontrer à AWS que quelque chose ne va pas.

J'espère que cela t'aides!

Le correctif est en fait simple: utilisez un Aenregistrement plutôt qu'un CNAMEdans Route53.

Dans la AWS Management Console, choisissez «Un enregistrement», puis déplacez le bouton radio intitulé «Alias» sur «Oui». Sélectionnez ensuite votre ELB dans le menu déroulant.

Il existe des solutions potentielles que vous pouvez essayer dans ce forum des développeurs AWS. https://forums.aws.amazon.com/message.jspa?messageID=387552 .

Par exemple:

correction potentielle n ° 1

Nous avons eu un problème similaire lorsque nous sommes passés à ELB, nous avons résolu ce problème en réduisant le nom de notre ELB à un seul caractère. Même un nom à 2 caractères pour ELB a causé des problèmes aléatoires avec les résolutions DNS des solutions réseau.

Le nom DNS de votre ELB devrait ressembler à -> X. <9chars> .us-east-1.elb.amazonaws.com

correction potentielle n ° 2

Je suis l'affiche originale. Merci pour toutes les réponses. Nous avons pu réduire la fréquence à laquelle nous avons rencontré des problèmes DNS en définissant le TTL très haut (afin qu'ils soient mis en cache par des serveurs non-Network Solutions). Cependant, nous obtenions toujours suffisamment de problèmes où nous ne pouvions tout simplement plus rester avec Network Solutions. Nous avons pensé passer à UltraDNS sur la base de bons rapports sur le service, mais il semblait que la Route 53 (qui utilise UltraDNS sous les couvertures, semble-t-il) serait moins chère pour nous. Depuis le passage à Route 53, nous n'avons plus de problèmes DNS et nos noms ELB peuvent aussi être beaux et longs.

Il y avait d'autres choses à essayer dans ce post, mais celles-ci semblent être les meilleures pistes.