Servizio AWS ELB Apache2 503 non disponibile: il server back-end è al massimo

Abbiamo gestito un paio di siti Web dall'infrastruttura AWS di Amazzoni ormai da circa due anni e da circa due giorni fa il server web ha iniziato a fallire una o due volte al giorno con l'unico errore che riesco a trovare:

HTTP/1.1 503 Service Unavailable: Back-end server is at capacity

CloudWatch non attiva alcun allarme (CPU / Disk IO / DB Conn). Ho provato ad andare sul sito tramite l'IP elastico per saltare l'ELB e ho ottenuto questo:

HTTP request sent, awaiting response... Read error (Connection reset by peer) in headers. Retrying.

Non vedo nulla di straordinario nei registri di Apache e ho verificato che venivano ruotati correttamente. Non ho problemi ad accedere alla macchina quando è "inattivo" tramite SSH e guardando l'elenco dei processi vedo 151 processi apache2 che mi sembrano normali. Il riavvio di apache risolve temporaneamente il problema. Questa macchina funziona solo come un server web dietro un ELB. Ogni suggerimento sarà molto apprezzato.

Media utilizzo CPU: 7,45%, Minimo: 0,00%, Massimo: 25,82%

Media utilizzo memoria: 11,04%, minimo: 8,76%, massimo: 13,84%

Media utilizzo swap: N / A, Minimo: N / A, Massimo: N / A

Utilizzo spazio su disco per / dev / xvda1 montato su / Media: 62,18%, Minimo: 53,39%, Massimo: 65,49%

Consentitemi di chiarire che penso che il problema riguardi la singola istanza EC2 e non l'ELB. Non volevo escluderlo anche se non ero in grado di raggiungere l'IP elastico. Sospetto che ELB stia solo restituendo i risultati del colpire l'istanza EC2 effettiva.

Aggiornamento: 2014-08-26 Avrei dovuto aggiornarlo prima, ma la "correzione" consisteva nel fare un'istantanea dell'istanza "errata" e avviare l'AMI risultante. Non è andato giù da allora. Ho esaminato il controllo dello stato quando stavo ancora riscontrando problemi e potevo accedere alla pagina del controllo dello stato ( curl http://localhost/page.html) anche quando stavo riscontrando problemi di capacità dal bilanciamento del carico. Non sono convinto che si sia trattato di un problema di controllo dello stato, ma poiché nessuno, incluso Amazon, può fornire una risposta migliore, lo sto contrassegnando come risposta. Grazie.

Aggiornamento: 2015-05-06 Ho pensato di tornare qui e dire che parte del problema ora credo fermamente nelle impostazioni del controllo dello stato. Non voglio escludere che si tratti di un problema con l'AMI perché sicuramente è migliorato dopo il lancio dell'AMI sostitutivo, ma ho scoperto che i nostri controlli di integrità erano diversi per ciascun bilanciamento del carico e che quello che stava avendo più problemi aveva una soglia malsana molto aggressiva e un timeout di risposta. Il nostro traffico tende a impennare in modo imprevedibile e penso che tra le impostazioni di controllo sanitario aggressivo e i picchi di traffico sia stata una tempesta perfetta.

Verrà visualizzato un "Server back-end a capacità" quando il bilanciamento del carico ELB esegue i controlli di integrità e riceve una "pagina non trovata" (o un altro errore semplice) a causa di una configurazione errata (in genere con l'host NameVirtual).

Prova a trascinare la cartella dei file di registro utilizzando l'agente utente "ELB-HealthChecker". per esempio

grep ELB-HealthChecker  /var/log/httpd/*

Questo in genere ti dà un errore 4x o 5x che è facilmente risolvibile. ad esempio Flood, MaxClients ecc. sta dando troppo credito al problema.

Cordiali saluti Amazon: perché non mostrare la risposta restituita dalla richiesta? Anche un codice di stato sarebbe di aiuto.

Mi sono appena imbattuto in questo problema da solo. Amazon ELB restituirà questo errore se non ci sono istanze integre. I nostri siti sono stati configurati in modo errato, quindi il controllo di integrità ELB non è riuscito, il che ha causato la disattivazione della rotazione dei due server. Con zero siti sani, ELB ha restituito 503 Servizio non disponibile: il server back-end è al massimo.

[MODIFICA dopo aver compreso meglio la domanda] Non avendo alcuna esperienza dell'ELB, penso ancora che suona sospettosamente come l'errore 503 che può essere lanciato quando Apache affronta un Tomcat e inonda la connessione.

L'effetto è che se Apache fornisce più richieste di connessione di quante possano essere elaborate dal back-end, le code di input del back-end si riempiono fino a quando non è possibile accettare più connessioni. Quando ciò accade, le code di output corrispondenti di Apache iniziano a riempirsi. Quando le code sono piene, Apache genera un 503. Ne consegue che lo stesso potrebbe accadere quando Apache è il backend e il frontend viene distribuito a una velocità tale da riempire le code.

La (ipotetica) soluzione consiste nel dimensionare i connettori di input del backend e quelli di output del frontend. Ciò si trasforma in un atto di bilanciamento tra il livello di allagamento previsto e la RAM disponibile dei computer coinvolti.

Quindi, in questo caso, controlla le impostazioni dei client maxi e monitora i tuoi dipendenti occupati in Apache (mod_status.). Fai lo stesso, se possibile, con qualsiasi ELB che corrisponda al backlog del connettore Tomcats, maxthreads ecc. In breve, guarda tutto ciò che riguarda le code di input di Apache e le code di output di ELB.

Anche se capisco perfettamente che non è direttamente applicabile, questo link contiene una guida alle taglie per il connettore Apache. Dovresti ricercare i corrispondenti tecnicismi della coda ELB, quindi fare i conti: http://www.cubrid.org/blog/dev-platform/maxclients-in-apache-and-its-effect-on-tomcat-during- full-gc /

Come osservato nel commento qui sotto, per sopraffare il connettore Apache un picco nel traffico non è l'unica possibilità. Se alcune richieste vengono servite più lentamente di altre, un rapporto più elevato di quelle può anche portare al riempimento delle code del connettore. Questo era vero nel mio caso.

Inoltre, quando mi è successo, ero sconcertato dal fatto che dovevo riavviare il servizio Apache per non ricevere nuovamente 503: s. Non bastava semplicemente aspettare l'allagamento del connettore. Non l'ho mai capito, ma forse si può speculare su Apache dalla sua cache?

Dopo aver aumentato il numero di lavoratori e le corrispondenti impostazioni dei client max pre-fork (questo era Apache multithread su Windows che ha un paio di altre direttive per le code se ricordo bene), il problema 503 è scomparso. In realtà non ho fatto i conti, ma ho semplicemente aumentato i valori fino a quando non ho potuto osservare un ampio margine sul consumo di picco delle risorse della coda. L'ho lasciato andare.

Spero che questo sia stato di qualche aiuto.

puoi aumentare i valori del controllo di integrità elb, così come una singola risposta lenta non estrarrà un server da elb. meglio che alcuni utenti non rendano disponibile il servizio, che il sito non è disponibile per tutti.

EDIT: Siamo in grado di scappare senza preriscaldamento della cache aumentando il timeout del controllo dello stato a 25 secondi ...... dopo 1-2 minuti ... il sito è reattivo come l'inferno

EDIT :: basta lanciare un sacco di su richiesta, e quando i tuoi strumenti di monitoraggio mostrano la gestione quanto sei veloce, allora prepaghi RI amazon: P

EDIT: è possibile, una singola istanza registrata elb back-end non è sufficiente. basta avviarne alcuni altri e registrarli con elb, e questo ti aiuterà a restringere il problema

È in ritardo di qualche anno, ma speriamo che questo aiuti qualcuno.

Stavo vedendo questo errore quando all'istanza dietro ELB non era assegnato un IP pubblico adeguato. Avevo bisogno di creare manualmente un IP elastico e associarlo all'istanza, dopodiché l'ELB lo raccolse quasi all'istante.