Frage Nach welchen Kriterien stimmen Sie Timeouts in der HA-Proxy-Konfiguration ab?


Wie entscheiden Sie bei der Konfiguration des HA-Proxy, welche Werte den Timeouts zugewiesen werden sollen? Ich habe ein halbes Dutzend Samples in verschiedenen Blogs gelesen, und jeder benutzt unterschiedliche Timeouts und niemand diskutiert warum.

HAProxy scheint sich besonders Sorgen um Client, Connect und Server zu machen, was HAPRoxy eine Warnung gibt, wenn Sie völlig unausgewogen bleiben:

While not properly invalid, you will certainly encounter various problems
with such a configuration. To fix this, please ensure that all following
timeouts are set to a non-zero value: 'client', 'connect', 'server'.

Das Dokumentation ist in dieser Hinsicht nicht hilfreich: es schlägt "leicht über ein Vielfaches von 3 Sekunden" vor, aber nicht, warum Sie ein Vielfaches von 1 gegen 100 oder 42 wählen würden.

Der RPM, den ich verwende (Amazon Linux-Repository), legt diese Standardwerte fest:

timeout connect         10s
timeout client          1m
timeout server          1m

Zwei davon sind genau ein Vielfaches von 3 Sekunden und verletzt den einzigen offiziellen Rat, den ich gesehen habe.

Wenn Sie keinen spezifischen Optimierungsratschlag haben, ist vielleicht eine einfachere Frage: Was sollte ich bei wirklich kurzen oder sehr langen Timeouts erwarten?


26
2018-05-02 02:03


Ursprung




Antworten:


Das TCP-RTO (Empfangs-Timeout) beginnt bei drei Sekunden. (RFC 1122) Wenn bei einem übertragenen Paket zu dieser Zeit keine Bestätigung zurückgegeben wurde, wird angenommen, dass es verloren gegangen ist und erneut übertragen wurde. Das ist fast sicher, worauf sich der Autor bezieht. (Beachten Sie, dass das RTO dynamisch nach oben oder unten abgestimmt wird verschiedene Algorithmen, außerhalb des Rahmens dieser Frage.)

Beachten Sie, dass dies nur für Verbindungen zwischen Ihrem Frontend-Server und den Clients (d. H. Web-Benutzern) gilt. In normalen Szenarios sollten die Verbindungen zwischen HAProxy und Ihren Back-End-Servern in einem LAN sein und Sie sollten viel kürzere Timeouts verwenden, damit fehlerhafte Back-Ends früher außer Betrieb genommen werden.

Was Ihre Web-Benutzer anbelangt, können sich einige von ihnen auf Verbindungen mit sehr hoher Latenz befinden, wie z. B. Satelliten, und können dadurch höhere als normale Neuübertragungen erfahren. Die RTT einer Verbindung, bei der ein Satellit verwendet wird, kann selbst dann mehr als 2000 ms betragen, wenn alles in Ordnung ist.

In Anbetracht dessen werden Sie in der Regel sehr kurze Timeouts für timeout connect und sehr lange für timeout client.

Zum timeout serverDies hängt von Ihrer Webanwendung ab. Berücksichtigen Sie beim Festlegen des Zeitlimits die Komplexität der Webanwendung, die bereitgestellt wird, und wie lange es im schlimmsten Fall dauert, eine komplexe Anforderung zu verarbeiten. Im Zweifelsfall den Wert erhöhen.


33
2018-05-02 02:32



Wirklich die gelehrteste und höflichste Antwort, die ich irgendwo auf StackExchange erhalten habe. Vielen Dank. - Jeremy Wadhams
Was kann ich sagen, Serverfehler ist nur ein Haufen mürrischer Curmudgeons. - Michael Hampton♦


Vorwort

Ich habe HAProxy eine Weile gestimmt und eine Menge Leistungstests durchgeführt. Von 100 HTTP-Anfragen / s bis zu 50 000 HTTP-Anfragen / s.

Der erste Ratschlag ist zu Aktivieren Sie die Statistikseite auf HAProxy. Sie brauchen Überwachung, keine Ausnahme. Sie müssen auch Feineinstellungen vornehmen, wenn Sie 10.000 Anfragen / s überschreiten möchten.

Timeouts sind ein verwirrendes Biest, weil sie eine große Bandbreite möglicher Werte haben, von denen die meisten keinen beobachtbaren Unterschied haben. Ich muss noch etwas sehen, das wegen einer Zahl 5% niedriger oder 5% höher scheitert. 10000 vs 11000 Millisekunden, wen interessiert das? Wahrscheinlich nicht dein System.

Aufbau

Ich kann nicht mit gutem Gewissen ein paar Nummern als "beste Timeouts für alle" angeben.

Was ich stattdessen sagen kann, sind die meisten aggressiven Timeouts, die immer für den Lastausgleich von HTTP (S) akzeptabel sind. Wenn Sie auf niedrigere Werte stoßen, ist es an der Zeit, den Load Balancer neu zu konfigurieren.

timeout connect 5000
timeout check 5000
timeout client 30000
timeout server 30000

Timeout-Client:

Das Inaktivitätszeitlimit gilt, wenn der Client erwartet oder bestätigen soll   schicke Daten. Im HTTP-Modus ist diese Zeitüberschreitung besonders wichtig   während der ersten Phase, wenn der Client die Anfrage sendet und während der   Antwort, während es Daten vom Server gesendet liest.

Lesen: Dies ist die maximale Zeit für den Empfang einer HTTP-Anfrage Kopfzeilen vom Kunden.

3G / 4G / 56k / Satellit kann manchmal langsam sein. Dennoch sollten sie HTTP-Header in ein paar Sekunden senden können, NICHT 30.

Wenn jemand eine Verbindung so schlecht hat, dass er mehr als 30s benötigt, um eine Seite anzufordern (dann mehr als 10 * 30s, um die 10 eingebetteten Bilder / CSS / JS anzufordern), glaube ich, dass es akzeptabel ist, ihn abzulehnen.

Zeitüberschreitung Server:

Das Inaktivitätszeitlimit gilt, wenn der Server erwartet wird, oder   schicke Daten. Im HTTP-Modus ist diese Zeitüberschreitung besonders wichtig   während der ersten Phase der Antwort des Servers, wenn es die senden muss   Header, da es direkt die Verarbeitungszeit des Servers für die   anfordern. Um herauszufinden, welchen Wert man dort setzen kann, ist es oft gut, mit dem Anfang zu beginnen   was als inakzeptable Antwortzeiten gelten würden, dann prüfe die Protokolle   Beobachten Sie die Antwortzeitverteilung und passen Sie den Wert entsprechend an.

Lesen: Dies ist die maximale Zeit für den Empfang der HTTP-Antwort Kopfzeilen vom Server (nachdem es die vollständige Client-Anfrage erhalten hat). Im Grunde genommen ist dies die Verarbeitungszeit von Ihren Servern, bevor sie mit dem Senden der Antwort beginnt.

Wenn Ihr Server so langsam ist, dass mehr als 30 Sekunden benötigt werden, um eine Antwort zu geben, dann ist es akzeptabel, sie für tot zu halten.

Besonderer Fall: Einige RARE-Dienste, die sehr stark verarbeitet werden, benötigen möglicherweise eine volle Minute oder mehr, um eine Antwort zu geben. Diese Zeitüberschreitung muss möglicherweise für diese spezielle Verwendung stark erhöht werden. (Hinweis: Dies ist wahrscheinlich ein Fall von schlechtem Design, verwenden Sie eine asynchrone Stilkommunikation oder verwenden Sie überhaupt kein HTTP.)

Zeitüberschreitung verbinden:

Legen Sie die maximale Wartezeit für einen Verbindungsversuch mit einem Server fest.

Lesen: Die maximale Zeit, die ein Server eine TCP-Verbindung akzeptieren muss.

Server sind im selben LAN wie HAProxy, also sollte es schnell gehen. Geben Sie es mindestens 5 Sekunden lang ein, denn so lange dauert es, bis etwas Unerwartetes passiert (ein verlorenes TCP-Paket, das erneut übertragen werden muss, ein Server, der einen neuen Prozess für die neuen Anfragen absetzt).

Besonderer Fall: Wenn sich Server in einem anderen LAN oder über eine unzuverlässige Verbindung befinden. Diese Zeitüberschreitung muss möglicherweise stark erhöht werden. (Anmerkung: Dies ist wahrscheinlich eine schlechte Architektur.)

Zeitüberschreitungsprüfung:

Legen Sie das zusätzliche Überprüfungstimeout fest, jedoch erst nach einer bereits bestehenden Verbindung   etabliert.

Legen Sie das zusätzliche Überprüfungstimeout fest, jedoch erst nach einer bereits bestehenden Verbindung   Wenn gesetzt, verwendet haproxy min ("timeout connect", "inter") als Verbindungstimeout   für Check und "Timeout Check" als zusätzliches Lese-Timeout. Das "Min" ist   benutzt, damit Leute mit rennen sehr lange "timeout connect" (z. B. die   Wer das wegen der Warteschlange oder des Targets benötigt), bremsen ihre Schecks nicht ab.   (Bitte beachten Sie auch, dass es keinen triftigen Grund gibt, solch eine lange Verbindung zu haben   Timeouts, weil "Timeout Queue" und "Timeout Tarpit" immer verwendet werden können   um das zu vermeiden).

Lesen: Wenn eine Healthcheck durchgeführt wird, hat der Server timeout connect um die Verbindung dann zu akzeptieren timeout check um die Antwort zu geben.

Alle Server MÜSSEN einen HTTP (S) -Health-Check konfiguriert haben. Nur so kann der Load Balancer feststellen, ob ein Server verfügbar ist. Der Gesundheitscheck ist einfach /isalive Seite antwortet immer OK.

Geben Sie dieses Zeitlimit mindestens 5 Sekunden an, denn so lange kann es dauern, wenn etwas Unerwartetes passiert (ein verlorenes TCP-Paket wird erneut übertragen, ein Server forkiert einen neuen Prozess, um die neuen Anfragen aufzunehmen, Spike im Datenverkehr).

Kriegsgeschichte: Viele Leute zu Unrecht glaube, dass der Server diese einfache Seite in 3 ms immer beantworten kann. Sie setzen ein aggressives Timeout (<2000ms) mit aggressivem Failover (2 fehlgeschlagene Checks = Server tot). Ich habe ganze Webseiten deswegen gesehen. Typischerweise gibt es einen leichten Anstieg im Datenverkehr, Backend-Server werden langsamer, die Healthchecks verzögern sich ... bis sie plötzlich alle gemeinsam auslaufen, HAProxy denkt, ALLE Server starben auf einmal und die gesamte Site geht aus.


23
2018-05-21 18:13