Bilanciamento del carico elastico AWS: tempo di connessione iniziale estremamente lungo

Question

Per un paio di giorni, spesso vediamo un tempo di connessione iniziale estremamente lungo (15s - 1.3 minuti) ai nostri ELB quando si effettua una richiesta tramite ssl. Stranamente, l'ho potuto osservare solo in Google Chrome (non in Safari, in Firefox o in arricciatura).

Non si verifica ogni singola richiesta, ma circa il 50% delle richieste. Si verifica con la prima richiesta (OPTIONS-call).

La nostra configurazione è la seguente: ELB a zone incrociate che si collega a un backend node.js (attualmente in 2 AZ in eu-west-1). Tutte le istanze sono in buone condizioni e una volta ricevuta la richiesta, viene elaborata normalmente. Attualmente, non c'è praticamente nessun carico sul sistema. Cloudwatch per ELB non segnala alcun errore di connessione di back-end, né SurgeQueue (valore 0) né un conteggio di spillover. Le metriche ELB mostrano una bassa latenza (< 100 ms). Abbiamo Route53 configurato per il routing verso l'ELB (non vediamo alcun problema dns, vedere screenshot allegato).

Abbiamo diverse API REST che hanno tutte questa configurazione. Si verifica a tutti gli ELB (ognuno di essi si connette a un backend node.js indipendente). Tutti questi ELB sono impostati allo stesso modo tramite il nostro modello di cloudformation.

Gli ELB fanno anche la nostra terminazione SSL.

Cosa potrebbe portare a un simile comportamento? È possibile che gli ELB non siano configurati correttamente? E perché potrebbe apparire solo su Google Chrome?

Answer 1

penso che sia una possibile configurazione errata ELB. Ho avuto lo stesso problema quando ho inserito sottoreti private in ELB. Risolto il problema cambiando le sottoreti private in pubblico. Vedi https://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/elb-manage-subnets.html

Answer 2

Questo può essere un problema con l'elb di Amazon. L'elb ridimensiona il numero di istanze con il numero di richieste. Dovresti vedere qualche picco di richieste in quei momenti. Amazon aggiunge alcune istanze per adattarsi al carico. le istanze sono raggiungibili durante il processo di avvio in modo che i client ottengano tali timeout. è totalmente casualità così si dovrebbe:

• ping l'ELB al fine di ottenere tutte le IP utilizzato

• uso mtr su tutti ip trovato

• Tenete d'occhio il CloudWatch

• Trova alcuni indizi

Answer 3

Solo per seguire l'eccellente risposta di @Nikita Ogurtsov; Ho avuto lo stesso problema tranne che era solo una delle mie sottoreti che era privata e il resto del pubblico.

Anche se pensi che i tuoi sottoreti sono pubblici, vi consiglio di controllare due volte le tabelle di routing per assicurare che essi tutti hanno un Gateway.

È possibile utilizzare una singola tabella percorso che ha un gateway per tutte le sottoreti LB se questo ha senso

VPC/Subnets/(select subnet)/Route Table/Edit

Answer 4

Soluzione Se sei DNS è configurato per colpire direttamente sul ELB - si> dovrebbe ridurre il TTL dell'associazione (IP, DNS). L'IP può cambiare in qualsiasi momento con l'ELB in modo da poter causare gravi danni al tuo traffico.

Il client mantiene alcuni IP dall'ELB nella cache in modo da poter avere quei problemi.

Scaling di bilanciamento del carico elastico Una volta creato un bilanciamento del carico elastico, è necessario configurarlo per accettare le richieste di traffico e rotte in arrivo verso le istanze EC2. Questi parametri di configurazione sono memorizzati dal controller e il controller assicura che tutti i bilanciatori del carico funzionino con la configurazione corretta. Il controller monitorerà anche i bilanciatori di carico e gestirà la capacità utilizzata per gestire le richieste dei client. Aumenta la capacità utilizzando risorse più grandi (risorse con caratteristiche di rendimento più elevate) o più risorse individuali. Il servizio di bilanciamento del carico elastico aggiornerà il record DNS (Domain Name System) del bilanciamento del carico quando viene ridimensionato in modo che le nuove risorse abbiano i rispettivi indirizzi IP registrati nel DNS. Il record DNS che viene creato include un'impostazione TTL (Time-to-Live) di 60 secondi, con l'aspettativa che i client eseguano nuovamente la ricerca del DNS almeno ogni 60 secondi. Per impostazione predefinita, il bilanciamento del carico elastico restituirà più indirizzi IP quando i client eseguono una risoluzione DNS, con i record ordinati casualmente su ciascuna richiesta di risoluzione DNS. Quando il profilo del traffico cambia, il servizio del controller ridimensiona i bilanciatori del carico per gestire più richieste, scalando allo stesso modo in tutte le zone di disponibilità.

Best Practices ELB on AWS