Lastausgleich mit NGINX und NGINX Plus, Teil 1

NGINX ist ein leistungsfähiger Beschleunigungsproxy für eine breite Palette von HTTP-basierten Anwendungen. Durch Caching, HTTP-Verbindungsverarbeitung und Offload wird die Anwendungsleistung insbesondere in Zeiten hoher Auslastung deutlich gesteigert.

Editor – NGINX Plus Release 5 und höher können auch TCP-basierte Anwendungen ausgleichen. Der TCP-Lastausgleich wurde in Release 6 durch die Hinzufügung von Integritätsprüfungen, dynamischer Neukonfiguration, SSL-Terminierung und mehr erheblich erweitert. In NGINX Plus Release 7<.htmla> und höher verfügt der TCP-Load Balancer über volle Funktionsparität mit dem HTTP-Load Balancer. Die Unterstützung für UDP-Lastausgleich wurde in Release 9 eingeführt.

Sie konfigurieren den TCP- und UDP-Lastausgleich im Streamkontext statt im HTTP -Kontext. Die verfügbaren Anweisungen und Parameter unterscheiden sich etwas aufgrund inhärenter Unterschiede zwischen HTTP und TCP/UDP. Einzelheiten finden Sie in der Dokumentation der HTTP- und TCP- Upstream-Module.

NGINX Plus erweitert die Funktionen von NGINX um weitere Funktionen zum Lastenausgleich: Integritätsprüfungen , Sitzungspersistenz , Live-Aktivitätsüberwachung und dynamische Konfiguration von Servergruppen mit Lastenausgleich .

Dieser Blogbeitrag führt Sie durch die Konfiguration von NGINX, um den Datenverkehr auf eine Reihe von Webservern zu verteilen. Es hebt einige der zusätzlichen Funktionen in NGINX Plus hervor.

Als weiterführende Literatur können Sie auch einen Blick in den NGINX Plus Admin Guide und den Nachfolgeartikel zu diesem Artikel, Load Balancing mit NGINX und NGINX Plus, Teil 2 , werfen.

Proxying des Datenverkehrs mit NGINX

Wir beginnen mit der Weiterleitung des Datenverkehrs an ein Paar Upstream-Webserver. Die folgende NGINX-Konfiguration reicht aus, um alle HTTP-Anfragen an Port 80 zu beenden und sie im Round-Robin-Verfahren an die Webserver in der Upstream-Gruppe weiterzuleiten:

http { Server {
Listen 80;

Standort / {
Proxy-Passwort http://backend;
}
}

Upstream-Backend {
Server Web-Server1:80;
Server Web-Server2:80;
}
}

Mit dieser einfachen Konfiguration leitet NGINX jede auf Port 80 empfangene Anfrage nacheinander an Webserver1 und Webserver2 weiter und stellt dabei jeweils eine neue HTTP-Verbindung her.

Festlegen der Lastausgleichsmethode

Standardmäßig verwendet NGINX die Round-Robin-Methode, um den Datenverkehr gleichmäßig zwischen den Servern zu verteilen. Dabei wird jedem Server ein optionales „Gewicht“ zugewiesen, um seine relative Kapazität anzugeben.

Die IP-Hash -Methode verteilt den Datenverkehr basierend auf einem Hash der Quell-IP-Adresse. Anfragen von derselben Client-IP-Adresse werden immer an denselben Upstream-Server gesendet. Dies ist eine einfache Methode zur Sitzungspersistenz, die bei jedem Serverausfall oder -wiederherstellung oder bei jeder Änderung der Upstream-Gruppe neu berechnet wird. NGINX Plus bietet bessere Lösungen, wenn Sitzungspersistenz erforderlich ist.

Die Methode „Least Connections“ leitet jede Anforderung an den Upstream-Server mit den wenigsten aktiven Verbindungen weiter. Diese Methode eignet sich gut für die Verarbeitung einer Mischung aus schnellen und komplexen Anfragen.

Alle Lastausgleichsmethoden können mit einem optionalen Gewichtungsparameter in der Serverdirektive optimiert werden. Dies ist sinnvoll, wenn Server unterschiedliche Verarbeitungskapazitäten haben. Im folgenden Beispiel leitet NGINX viermal so viele Anfragen an web-server2 als an web-server1 weiter:

Upstream-Backend { Zone-Backend 64k; least_conn; Server Web-Server1 Gewicht=1; Server Web-Server2 Gewicht=4 ; }

In NGINX werden Gewichte von jedem Arbeitsprozess unabhängig verwaltet. NGINX Plus verwendet ein gemeinsam genutztes Speichersegment für Upstream-Daten (konfiguriert mit der Zonendirektive ), sodass Gewichte zwischen den Workern geteilt und der Datenverkehr präziser verteilt werden.

Fehlererkennung

Wenn beim Versuch von NGINX, eine Verbindung zu einem Server herzustellen, eine Anforderung an ihn weiterzuleiten oder den Antwortheader zu lesen, ein Fehler oder eine Zeitüberschreitung auftritt, wiederholt NGINX die Verbindungsanforderung bei einem anderen Server. (Sie können die Direktive „proxy_next_upstream“ in die Konfiguration aufnehmen, um andere Bedingungen für die Wiederholung der Anfrage festzulegen.) Darüber hinaus kann NGINX den ausgefallenen Server aus der Gruppe der potenziellen Server herausnehmen und gelegentlich Anfragen an ihn senden, um festzustellen, wann er wiederhergestellt ist. Die Parameter max_fails und fail_timeout der Serverdirektive steuern dieses Verhalten.

NGINX Plus fügt eine Reihe von Out-of-Band -Integritätsprüfungen hinzu, die anspruchsvolle HTTP-Tests für jeden Upstream-Server durchführen, um festzustellen, ob er aktiv ist, und einen Slow-Start- Mechanismus, um wiederhergestellte Server schrittweise wieder in die Gruppe mit Lastenausgleich einzuführen:

Server Webserver1 langsamer_Start=30s;

Ein häufiges Problem – Korrigieren des Host -Headers

Häufig verwendet ein Upstream-Server den Host- Header in der Anforderung, um zu bestimmen, welcher Inhalt bereitgestellt werden soll. Wenn Sie unerwartete404 Wenn beim Server Fehler auftreten oder irgendetwas anderes darauf hindeutet, dass der falsche Inhalt bereitgestellt wird, sollten Sie dies als Erstes überprüfen. Nehmen Sie dann die Direktive proxy_set_header in die Konfiguration auf, um den entsprechenden Wert für den Header festzulegen:

location / { proxy_pass http://backend; # Schreiben Sie den Header „Host“ in den Wert in der Client-Anforderung um. # oder in den primären Servernamen proxy_set_header Host $host ; # Alternativ fügen Sie den Wert in die Konfiguration ein: #proxy_set_header Host www.example.com; }

Erweiterter Lastenausgleich mit NGINX Plus

Eine Reihe erweiterter Funktionen in NGINX Plus machen es zu einem idealen Load Balancer vor Farmen von Upstream-Servern:

• Lastausgleich und Sitzungspersistenz – Besserer Lastausgleich über Arbeitsprozesse und Sitzungspersistenzmethoden zur Identifizierung und Einhaltung von Anwendungssitzungen
• HTTP-Integritätsprüfung und langsamer Serverstart – Asynchrone „synthetische Transaktionen“ zur Prüfung der korrekten Funktion jedes Upstream-Servers und ordnungsgemäße Wiedereinführung der Server per „langsamem Start“, wenn sie sich erholt haben.
• Live-Aktivitätsüberwachung – Sofortiger Bericht über Aktivität und Leistung
• Dynamisch konfigurierte Upstream-Servergruppen – Tool zur Erleichterung einiger gängiger Upstream-Verwaltungsaufgaben, wie z. B. der sicheren und vorübergehenden Entfernung eines Servers

Einzelheiten zum erweiterten Lastenausgleich und Proxying finden Sie im Folgebeitrag zu diesem Beitrag, Lastenausgleich mit NGINX und NGINX Plus, Teil 2 .

Um NGINX Plus auszuprobieren, starten Sie noch heute Ihre kostenlose 30-Tage-Testversion oder kontaktieren Sie uns, um Ihre Anwendungsfälle zum Lastenausgleich zu besprechen .