nginx Load Balancing: upstream, Methoden und Health Checks
nginx Load Balancing
nginx Load Balancer: upstream, Methoden, Gewichte, Health | We.Inc
Richte nginx als Load Balancer ein: der upstream-Block, Round Robin, least_conn, ip_hash und hash, Gewichte, max_fails und fail_timeout, Backups, plus ein Config-Generator.
Für Load Balancing mit nginx listest du deine App-Server in einem upstream-Block auf und richtest proxy_pass auf dessen Namen. Anfragen rotieren per Round Robin, solange du nicht least_conn, ip_hash, hash oder random hinzufügst. Jede server-Zeile kann weight, max_fails und fail_timeout für passive Health Checks sowie die Flags backup oder down tragen.
Load-Balancing-Methoden in nginx
Direktive
Wie ein Server gewählt wird
Gut für
(keine)
Gewichtetes Round Robin, der Standard
Ähnliche Server und kurze Anfragen
Wenigste aktive Verbindungen, unter Berücksichtigung der Gewichte
Anfragen mit sehr unterschiedlicher Dauer
Hash der Client-Adresse (erste drei Oktette bei IPv4, ganze IPv6)
Einen Besucher auf einem Server halten
hash key
Hash eines beliebigen Werts, etwa $request_uri
Cache-Affinität; consistent hinzufügen, um Umverteilung zu begrenzen
Zufälliger Server, oder der bessere von zweien mit random two
Mehrere Load Balancer, die sich einen Pool teilen
Traffic auf mehrere Kopien einer App zu verteilen ist eine der ältesten Aufgaben von nginx, und das ganze Setup passt in ein Dutzend Zeilen. Der Generator unten schreibt den upstream-Block aus einer Serverliste, warnt vor Kombinationen, die nginx ablehnt, und zeigt bei Gewichten den Anteil jedes Servers an den Anfragen. Die Referenz danach behandelt jeden Server-Parameter mit seinem Standardwert.
Füge im Generator Adresse und Port jedes App-Servers hinzu, mit einem Gewicht, wenn manche Maschinen größer sind als andere.
Wähle eine Methode. Bleib bei Round Robin, außer die Anfragen unterscheiden sich stark in der Dauer oder Besucher müssen auf einem Server bleiben.
Kopiere das Ergebnis in den http-Kontext, zum Beispiel in eine Datei in conf.d, und führe nginx -t aus.
Lade mit nginx -s reload neu, stoppe dann einen App-Server und beobachte, wie die Anfragen zu den anderen wandern.
Ein einzelner Server in einem upstream ignoriert max_fails und fail_timeout, passive Checks spielen also erst ab zwei Servern eine Rolle.
Markiere bei ip_hash einen Server als down, statt die Zeile zu löschen. So zeigt der Hash der Adresse jedes anderen Clients weiterhin dorthin, wo er vorher hinzeigte.
backup-Server erhalten nur Traffic, wenn alle primären Server nicht verfügbar sind, und lassen sich nicht mit hash, ip_hash oder random kombinieren.
Welche Fehler für max_fails zählen, bestimmt proxy_next_upstream. Standardmäßig zählen Fehler und Timeouts; ein HTTP 500 zählt nur, wenn du ihn aufführst.
Füge keepalive zusammen mit proxy_http_version 1.1 und einem leeren Connection-Header hinzu, um Verbindungen zu den Backends wiederzuverwenden, statt pro Anfrage eine neue zu öffnen.
Häufige Fragen
Hat Open-Source-nginx aktive Health Checks?
Nein. Die Direktive health_check gehört zum kommerziellen NGINX Plus. Open-Source-nginx setzt auf passive Checks: Schlägt eine Anfrage an einen Server innerhalb von fail_timeout max_fails-mal fehl, wird der Server für fail_timeout übersprungen und danach erneut mit echtem Traffic versucht.
Was sind die Standardwerte für max_fails und fail_timeout?
max_fails ist standardmäßig 1 und fail_timeout 10 Sekunden. Ein einziger fehlgeschlagener Versuch nimmt einen Server also für zehn Sekunden aus dem Spiel. Mit max_fails=0 schaltest du die Zählung für diesen Server ab.
Wie mache ich Sessions in nginx sticky?
Nutze ip_hash, um jede Client-Adresse auf einem Server zu halten, oder hash mit einer Cookie-Variable wie $cookie_session für feinere Kontrolle. Cookie-basierte sticky-Direktiven gibt es nur in der kommerziellen Edition.
Was bewirkt der Parameter weight?
Er ändert, wie viele Anfragen ein Server im Verhältnis zu den anderen bekommt. Mit den Gewichten 3, 1 und 1 erhält der erste Server bei Round Robin etwa drei von fünf Anfragen. Das Standardgewicht ist 1.
Kann nginx WebSocket-Verbindungen verteilen?
Ja. Richte proxy_pass auf den upstream und leite die Header Upgrade und Connection weiter. least_conn passt bei langlebigen Sockets besser als Round Robin, weil es zählt, wie viele Verbindungen jeder Server bereits hält.
Wohin die Teile gehören
Der upstream-Block liegt im http-Kontext, neben deinen server-Blöcken. Er benennt nur einen Pool; passieren tut nichts, bis eine location proxy_pass http://name angibt. Derselbe Pool kann von vielen locations und vielen server-Blöcken genutzt werden.
Passive Health Checks Schritt für Schritt
Schlägt eine Anfrage an einen Server auf eine Weise fehl, die proxy_next_upstream zählt, versucht nginx sie beim nächsten Server erneut und merkt sich den Fehler. Sobald ein Server innerhalb des fail_timeout-Fensters max_fails Fehler erreicht, wählt nginx ihn nicht mehr. Ist fail_timeout abgelaufen, schickt es vorsichtig wieder echte Client-Anfragen, und ein Erfolg bringt ihn zurück in die Rotation.
Weil die Checks auf echtem Traffic laufen, kann ein Besucher den ersten fehlgeschlagenen Versuch abbekommen. Kurze Timeouts bei proxy_connect_timeout halten diese Verzögerung klein.
server-Parameter und ihre Standardwerte
Parameter einer server-Zeile innerhalb von upstream
Parameter
Standard
Wirkung
weight=n
Relativer Anteil an den Anfragen
max_fails=n
Fehlversuche innerhalb von fail_timeout, bevor der Server übersprungen wird; 0 deaktiviert
fail_timeout=time
Zeitfenster für das Zählen der Fehler und Dauer, für die der Server übersprungen wird
max_conns=n
0 (kein Limit)
Obergrenze gleichzeitig aktiver Verbindungen zu diesem Server
Wird nur genutzt, wenn alle primären Server nicht verfügbar sind
Markiert den Server dauerhaft als nicht verfügbar
Vollständige Beispiele
Round Robin mit Reserve
Zwei primäre Server teilen sich die Last; der dritte antwortet nur, wenn beide ausfallen.
least_conn mit wiederverwendeten Verbindungen
keepalive hält inaktive Verbindungen zu den Backends vor; die zwei proxy-Zeilen sorgen dafür, dass das funktioniert.
Cache-Affinität nach URL
Jede URL landet immer wieder auf demselben Cache-Server; consistent hält die meisten Zuordnungen stabil, wenn ein Server hinzukommt oder wegfällt.
upstream-Name
Methode
Round Robin (Standard)
Hash-Schlüssel
Inaktive keepalive-Verbindungen (0 für keine)
Server
Adresse und Port
Gewicht
fail_timeout (s)
Anteil
Server {n} entfernen
Server hinzufügen
nginx lehnt backup-Server bei hash, ip_hash und random ab. Entferne das backup-Flag oder ändere die Methode.
Jeder primäre Server ist als down markiert, daher kann nichts Traffic empfangen.