Wir betreiben seit ungefähr zwei Jahren einige Websites außerhalb der Amazons AWS-Infrastruktur. Seit ungefähr zwei Tagen ist der Webserver ein- oder zweimal am Tag ausgefallen, mit dem einzigen Fehler, den ich feststellen kann:
HTTP/1.1 503 Service Unavailable: Back-end server is at capacity
Es werden keine Alarme (CPU / Disk IO / DB Conn) von CloudWatch ausgelöst. Ich habe versucht, die Website über die elastische IP zu besuchen, um die ELB zu überspringen.
HTTP request sent, awaiting response... Read error (Connection reset by peer) in headers. Retrying.
Ich sehe nichts Ungewöhnliches in den Apache-Protokollen und habe überprüft, dass sie ordnungsgemäß gedreht wurden. Ich habe keine Probleme, auf den Computer zuzugreifen, wenn er über SSH "down" ist und wenn ich die Prozessliste betrachte, sehe ich 151 Apache2-Prozesse, die mir normal erscheinen. Durch einen Neustart von Apache wird das Problem vorübergehend behoben. Diese Maschine arbeitet nur als Webserver hinter einer ELB. Anregungen wäre sehr dankbar.
CPU-Auslastung Durchschnitt: 7,45%, Minimum: 0,00%, Maximum: 25,82%
Speicherauslastung Durchschnitt: 11,04%, Minimum: 8,76%, Maximum: 13,84%
Swap-Nutzungsdurchschnitt: N / A, Minimum: N / A, Maximum: N / A
Speicherplatznutzung für / dev / xvda1 bereitgestellt auf / Durchschnitt: 62,18%, Minimum: 53,39%, Maximum: 65,49%
Lassen Sie mich klarstellen, dass ich denke, dass das Problem bei der einzelnen EC2-Instanz und nicht bei der ELB liegt. Ich wollte das nur nicht ausschließen, obwohl ich die elastische IP nicht erreichen konnte. Ich vermute, ELB gibt nur die Ergebnisse der tatsächlichen EC2-Instanz zurück.
Update: 2014-08-26
I should have updated this sooner but the "fix" was to take a snapshot of the "bad" instance and start the resulting AMI. It hasn't gone down since then. I did look at the health check when I was still experiencing issues and could get to the health check page (curl http://localhost/page.html) even when I was getting capacity issues from the load balancer. I'm not convinced it was a health check issue but since no one, including Amazon, can provide a better answer I'm marking it as the answer. Thank you.
Update: 2015-05-06 Ich dachte, ich kehre hierher zurück und sage, dass ein Teil des Problems, von dem ich jetzt fest überzeugt bin, die Einstellungen für die Gesundheitsprüfung waren. Ich möchte nicht ausschließen, dass sie ein Problem mit dem AMI darstellen, da es nach dem Start des Ersatz-AMI definitiv besser wurde, aber ich stellte fest, dass unsere Integritätsprüfungen für jeden Load Balancer unterschiedlich waren und derjenige, der die meisten Probleme hatte hatte eine sehr aggressive, ungesunde Schwelle und eine Reaktionszeitüberschreitung. Unser Verkehr nimmt unvorhersehbar zu, und ich denke, zwischen den Einstellungen für aggressive Gesundheitsprüfungen und den Verkehrsspitzen war es ein perfekter Sturm.
Antworten:
Ein "Back-End-Server ist voll" wird angezeigt, wenn der ELB-Lastenausgleich seine Integritätsprüfungen durchführt und eine "Seite nicht gefunden" (oder einen anderen einfachen Fehler) aufgrund einer Fehlkonfiguration (normalerweise mit dem NameVirtual-Host) erhält.
Versuchen Sie, den Ordner mit den Protokolldateien mit dem Benutzeragenten "ELB-HealthChecker" zu durchsuchen. z.B
Dies führt in der Regel zu einem 4-fachen oder 5-fachen Fehler, der leicht behoben werden kann. zB Flooding, MaxClients etc. machen dem Problem zu viel Ehre.
Zu Ihrer Information: Amazon: Warum nicht die Antwort von der Anfrage anzeigen? Sogar ein Statuscode würde helfen.
quelle
Ich bin gerade auf dieses Problem gestoßen. Die Amazon ELB gibt diesen Fehler zurück, wenn keine fehlerfreien Instanzen vorhanden sind. Unsere Sites wurden falsch konfiguriert, sodass der ELB-Integritätscheck fehlschlug, was dazu führte, dass der ELB die beiden Server außer Rotation setzte. Mit null fehlerfreien Standorten hat der ELB 503 zurückgegeben. Dienst nicht verfügbar: Der Back-End-Server ist voll.
quelle
[BEARBEITEN, nachdem die Frage besser verstanden wurde] Ich habe noch keine Erfahrung mit der ELB und denke, dass dies verdächtig nach dem 503-Fehler klingt, der möglicherweise ausgelöst wird, wenn Apache einen Tomcat in den Vordergrund stellt und die Verbindung überflutet.
Dies hat zur Folge, dass sich die Backend-Eingabewarteschlangen füllen, wenn Apache mehr Verbindungsanforderungen übermittelt, als vom Backend verarbeitet werden können, bis keine Verbindungen mehr akzeptiert werden können. In diesem Fall füllen sich die entsprechenden Ausgabewarteschlangen von Apache. Wenn die Warteschlangen voll sind, wirft Apache einen Wert von 503 ab. Dies kann auch passieren, wenn Apache das Backend ist und das Frontend so schnell liefert, dass sich die Warteschlangen füllen.
Die (hypothetische) Lösung besteht darin, die Eingangsanschlüsse des Backends und die Ausgangsanschlüsse des Frontends zu dimensionieren. Dies wird zu einem Spagat zwischen dem zu erwartenden Überflutungsgrad und dem verfügbaren Arbeitsspeicher der beteiligten Computer.
Überprüfen Sie in diesem Fall Ihre Einstellungen für maxclients und überwachen Sie Ihre beschäftigten Mitarbeiter in Apache (mod_status.). Machen Sie dasselbe, wenn möglich, mit allem, was ELB hat, das Tomcats-Connector-Rückstand, Maxthreads usw. entspricht. Kurz gesagt, schauen Sie sich alles an, was die Eingabewarteschlangen von Apache und die Ausgabewarteschlangen von ELB betrifft.
Obwohl ich voll und ganz verstehe, dass es nicht direkt anwendbar ist, enthält dieser Link eine Anleitung zur Größenbestimmung für den Apache-Connector. Sie müssten die entsprechenden ELB-Warteschlangentechniken untersuchen und dann rechnen: http://www.cubrid.org/blog/dev-platform/maxclients-in-apache-and-its-effect-on-tomcat-during- full-gc /
Wie im folgenden Kommentar zu sehen ist, ist eine Verkehrsspitze nicht die einzige Möglichkeit, um den Apache-Connector zu überwältigen. Wenn einige Anfragen langsamer bearbeitet werden als andere, kann ein höheres Verhältnis dazu führen, dass sich die Connectorwarteschlangen füllen. Das stimmte in meinem Fall.
Als mir das passierte, war ich verblüfft, dass ich den Apache-Dienst neu starten musste, um nicht wieder mit 503: s bedient zu werden. Es reichte nicht aus, nur auf die Überflutung des Steckers zu warten. Ich habe das nie herausgefunden, aber man kann vielleicht spekulieren, dass Apache aus seinem Cache dient?
Nachdem die Anzahl der Worker und die entsprechenden Einstellungen für Pre-Fork-Maxclients erhöht wurden (dies war Apache mit mehreren Threads unter Windows, das, wenn ich mich richtig erinnere, einige andere Anweisungen für die Warteschlangen enthält), verschwand das 503-Problem. Eigentlich habe ich nicht nachgerechnet, sondern nur die Werte angepasst, bis ich einen großen Spielraum für den Spitzenverbrauch der Warteschlangenressourcen feststellen konnte. Ich lasse es dabei gehen.
Hoffe das hat geholfen.
quelle
Sie können die Werte des Elb Health Checkers erhöhen, damit bei einer einzelnen langsamen Antwort kein Server aus dem Elb gezogen wird. Es ist besser, wenn ein paar Benutzer nicht erreichbar sind, als wenn die Website für alle nicht erreichbar ist.
BEARBEITEN: Wir sind in der Lage zu entkommen, ohne den Cache vorzuwärmen, indem wir das Zeitlimit für den Zustandscheck auf 25 Sekunden erhöhen. Nach 1-2 Minuten
BEARBEITEN :: starten Sie einfach eine Reihe von On-Demand-Tools, und wenn Ihre Überwachungstools das Management aufzeigen, wie schnell Sie sind, zahlen Sie RI amazon: P im Voraus aus
BEARBEITEN: Es ist möglich, dass eine einzelne Backend-Elb-registrierte Instanz nicht ausreicht. Starten Sie einfach ein paar weitere, und registrieren Sie sie bei Elb. Dadurch können Sie Ihr Problem eingrenzen
quelle
Es ist ein paar Jahre zu spät, aber hoffentlich hilft das jemandem.
Ich habe diesen Fehler gesehen, als der Instanz hinter der ELB keine ordnungsgemäße öffentliche IP zugewiesen wurde. Ich musste manuell eine elastische IP erstellen und sie mit der Instanz verknüpfen, nachdem die ELB sie fast sofort abgerufen hatte.
quelle