AWS/ELB-Verbindungsabfluss Probleme

Question

Diese Frage wurde in den AWS-Foren ohne jede Antwort gestellt. Unten ist die ursprüngliche Frage

---

Hallo!

Wir machen rollende Upgrades unserer API-Instanzen hinter einem ELB und sehen alarmierend lange Zeiten, in denen wir darauf warten, dass die Verbindung zum Ende kommt. Das Szenario ist wie folgt:

Wir betreiben zwei identische Systeme, 4x c3.large hinter einem ELB, ein System für Entwickler und ein System für die Produktion. Der einzige Unterschied zwischen den beiden Systemen besteht darin, dass das Produktionssystem ständig Anfragen bedient.

Ein laufendes Upgrade auf dem Dev-System dauert etwa 3 Minuten für alle 4 Instanzen, wenn kein Verkehr vorhanden ist. Auf dem Produktionssystem schwanken diese Zeiten zwischen 6 und 17+ Minuten. Aus Gründen müssen wir diese rollenden Upgrades im Durchschnitt etwa 2 mal pro Stunde machen und dann werden mehr als 17 Minuten für ein rollendes Upgrade zu einem Problem.

Alle unsere API-Aufrufe sind < 100ms, also gibt es keine lang laufenden Anfragen, die die Verbindung so lange zurückhalten sollten. Wir haben mit der Änderung der Werte für Leerlauf-Timout und Verbindungs-Drain-Timout auf dem ELB herumgespielt, ohne gute Ergebnisse zu erzielen.

Beim Verringern des Timeouts für die Verbindungsableitung sehen wir 502 Antworten von der API, da die Verbindungen zwangsweise unterbrochen werden und das Verringern des Leerlaufzeitlimits anscheinend keine Auswirkungen hat.

Alles in allem würden wir gerne wissen, was getan werden kann, um diese Zeiten zu reduzieren. Da unsere Anfragen alle < 100ms sind, sollte es theoretisch nicht mehr als ein oder zwei Sekunden dauern, um die Verbindungen von einer Instanz zu trennen. Gibt es etwas, was uns hier fehlt?

Eine letzte Anmerkung: Wir haben versucht, die Verbindung zu deaktivieren, die alles zusammen löschte, und dies schien besser zu funktionieren, als die Verbindungsabflusszeit zu verringern. Im Durchschnitt gab es nur 1 oder 2 Fehler pro Testlauf und einige Runs hatten keine Fehler. Liegt das daran, dass die Antwortzeiten so schnell sind? Unsere Antworten sind auch relativ klein, daher ist es möglich, dass die TCP-Antwort im OS-Ausgabepuffer gespeichert wird, damit sie auch dann reagieren kann, wenn die Verbindung getrennt ist. Was ist der Unterschied zwischen dem Timeout für die Verbindungsableitung auf 0 und dem Ausschalten?

Zusätzliche Informationen:

• Der gesamte Datenverkehr ist HTTPS
• SSL-Terminierung auf den Instanzen geschieht
• Keep-Alive auf nginx aktiviert ist (versucht, den Wert auch hier ohne Ergebnisse zu variieren)

Danke!

Answer 1

Dies ist eine komplexe Frage mit einer Reihe von Variablen und so kann ich ein paar Vorschläge machen.

1) Überprüfen Sie die Einstellungen für Health Check Interval, Response Timeout und Unhealthy Threshold. Wenn Sie im Rahmen Ihres fortlaufenden Upgrades Ihre Instances beenden, während der ELB noch Health-Checks durchführt, wartet der ELB die Dauer von "Response Timeout" unabhängig vom Verbindungsabbau. Wenn dieses Zeitlimit für 1 Minute mit 3 Wiederholungen ("Unhealthy Threshold") festgelegt wird, sind dies 3 Minuten pro Server, bevor der ELB die Instanz für tot erklärt.Selbst wenn die Verbindungsableitung auf Null gesetzt ist, werden keine neuen Anfragen an diese Instanz gesendet, sondern die ELB wartet 3 Minuten, bis sie entscheidet, dass die Instanz tatsächlich tot ist.

Worst Case - multiplizieren Sie mit 4 Instanzen und Sie sind 12 Minuten vor dem ELB versteht alle Instanzen sind tot. Mit anderen Worten - der ELB ist damit beschäftigt, darauf zu warten, dass Healthchecks tatsächlich fehlschlagen.

2) Heben Sie die Registrierung Ihrer Instanzen vom ELB auf, bevor Sie sie beenden? Dies vermeidet das Problem in Nr. 1 oben.

3) Deaktivieren des Verbindungsausgleich und Anschluss Aktivieren mit einem Timeout-Wert von Null Drainierende sollte die entsprechende Funktionalität