Stiamo cercando di eseguire una configurazione abbastanza semplice su Amazon EC2 - diversi server HTTP seduti dietro un Amazon Elastic Load Balancer (ELB).

Il nostro dominio è gestito in Route53 e abbiamo un record CNAME impostato per puntare all'ELB.

Abbiamo riscontrato alcuni problemi in cui alcune posizioni, ma non tutte, non sono in grado di connettersi in modo intermittente al bilanciamento del carico; sembra che questa potrebbe essere la risoluzione del nome di dominio dell'ELB.

Il supporto Amazon ci ha informato che l'IP elastico sottostante del bilanciamento del carico è cambiato e che il problema è che i server DNS di alcuni ISP non rispettano il TTL. Non siamo soddisfatti di questa spiegazione, perché abbiamo replicato il problema utilizzando i server DNS di Amazon da un'istanza EC2, nonché su ISP locali in Australia e tramite il server DNS di Google ( 8.8.8.8).

Amazon ha anche confermato che durante il periodo in cui abbiamo notato tempi di inattività da alcune località, il traffico che attraversava l'ELB era notevolmente ridotto, quindi il problema non riguarda i nostri endpoint.

È interessante notare che il dominio sembra risolversi nell'IP corretto sui server che non possono connettersi, ma il tentativo di stabilire una connessione TCP fallisce.

Tutte le istanze associate all'ELB sono sempre state salutari. Lo sono tutti

Qualcuno sa come potremmo fare per diagnosticare questo problema in modo più approfondito? Qualcun altro ha riscontrato questo problema con l'Elastic Load Balancer?

Grazie,

Ho trovato questa domanda mentre cercavo su Google come diagnosticare Amazon Elastic Load Balancers (ELB) e voglio rispondere a chiunque come me abbia avuto questo problema senza troppe indicazioni.

Proprietà ELB

Gli ELB hanno alcune proprietà interessanti. Per esempio:

• Gli ELB sono costituiti da 1 o più nodi
• Questi nodi sono pubblicati come record A per il nome ELB
• Questi nodi possono fallire o essere chiusi e le connessioni non verranno chiuse con grazia
• Richiede spesso una buona relazione con il supporto Amazon ($$$) per indurre qualcuno a scavare nei problemi ELB

NOTA: un'altra proprietà interessante ma leggermente meno pertinente è che gli ELB non sono stati progettati per gestire improvvisi picchi di traffico. In genere richiedono 15 minuti di traffico intenso prima di aumentare o possono essere preriscaldati su richiesta tramite un ticket di supporto

Risoluzione dei problemi relativi agli ELB (manualmente)

Aggiornamento: da allora AWS ha migrato tutti gli ELB per utilizzare Route 53 per DNS. Inoltre, tutti gli ELB hanno ora un all.$elb_namerecord che restituirà l'elenco completo dei nodi per ELB. Ad esempio, se il tuo nome ELB è elb-123456789.us-east-1.elb.amazonaws.com, allora otterrai l'elenco completo dei nodi facendo qualcosa di simile dig all.elb-123456789.us-east-1.elb.amazonaws.com. Per i nodi IPv6, all.ipv6.$elb_namefunziona anche. Inoltre, Route 53 è in grado di restituire fino a 4KB di dati che utilizzano ancora UDP, quindi +tcppotrebbe non essere necessario utilizzare il flag.

Sapendo questo, puoi fare un po 'di risoluzione dei problemi da solo. Innanzitutto, risolvi il nome ELB in un elenco di nodi (come record A):

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

Il tcpflag è suggerito poiché l'ELB potrebbe contenere troppi record per adattarsi all'interno di un singolo pacchetto UDP. Mi è stato anche detto, ma non ho confermato personalmente, che Amazon mostrerà solo fino a 6 nodi a meno che tu non esegua una ANYquery. L'esecuzione di questo comando ti darà un output simile al seguente (tagliato per brevità):

;; 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

Ora, per ciascuno dei Arecord utilizzare ad esempio curlper testare una connessione all'ELB. Naturalmente, vuoi anche isolare il tuo test solo sull'ELB senza collegarti ai tuoi backend. Un'ultima proprietà e fatti poco noti sugli ELB:

• La dimensione massima del metodo di richiesta (verbo) che può essere inviato tramite un ELB è di 127 caratteri . Più grande e ELB risponderà con un HTTP 405 - Metodo non consentito .

Ciò significa che possiamo sfruttare questo comportamento per testare solo che ELB sta rispondendo:

$ 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

Se vedi, HTTP/1.1 405 METHOD_NOT_ALLOWEDELB sta rispondendo correttamente. Potresti anche voler regolare i timeout del ricciolo su valori che sono accettabili per te.

Risoluzione dei problemi relativi agli ELB mediante elbping

Naturalmente, farlo può diventare piuttosto noioso, quindi ho creato uno strumento per automatizzare questo chiamato elbping . È disponibile come gemma rubino, quindi se hai rubygem puoi installarlo semplicemente facendo:

$ gem install elbping

Ora puoi eseguire:

$ 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

Ricorda, se vedi, code=405ciò significa che l'ELB sta rispondendo.

Prossimi passi

Qualunque metodo tu scelga, almeno saprai se i nodi del tuo ELB stanno rispondendo o meno. Grazie a questa conoscenza, puoi focalizzare la tua attenzione sulla risoluzione dei problemi di altre parti del tuo stack o essere in grado di fornire ad AWS un caso abbastanza ragionevole che qualcosa non va.

Spero che sia di aiuto!

La correzione è in realtà semplice: usa un Arecord piuttosto che un CNAMEin Route53.

Nella Console di gestione AWS, seleziona "Un record", quindi sposta il pulsante di opzione "Alias" su "Sì". Quindi seleziona il tuo ELB dal menu a discesa.

Ci sono alcune potenziali soluzioni che potresti provare in questo forum per sviluppatori AWS. https://forums.aws.amazon.com/message.jspa?messageID=387552 .

Per esempio:

potenziale correzione n. 1

Abbiamo avuto un problema simile quando ci siamo trasferiti in ELB, lo abbiamo risolto riducendo il nome del nostro ELB a un singolo personaggio. Anche un nome di 2 caratteri per ELB ha causato problemi casuali con le soluzioni DNS di soluzioni di rete.

Il nome DNS di ELB dovrebbe essere simile a -> X. <9chars> .us-east-1.elb.amazonaws.com

potenziale correzione n. 2

Sono il poster originale. Grazie per tutte le risposte. Siamo stati in grado di ridurre la frequenza con cui abbiamo riscontrato problemi DNS impostando il TTL su un valore molto alto (quindi sarebbero memorizzati nella cache da server non Network Solutions). Tuttavia, continuavamo a riscontrare abbastanza problemi in cui non potevamo più rimanere con Network Solutions. Abbiamo pensato di passare a UltraDNS sulla base di buoni rapporti sul servizio, ma sembrava che la Route 53 (che utilizza UltraDNS sotto le coperte, a quanto pare) sarebbe stata più economica per noi. Da quando siamo passati alla Route 53, non abbiamo più problemi DNS e anche i nostri nomi ELB possono essere belli e lunghi.

C'erano altre cose da provare in quel post ma quelle sembrano essere le migliori.