Lastausgleich mit NGINX und NGINX Plus, Teil 2

Im Abschnitt „Lastenausgleich mit NGINX und NGINX Plus, Teil 1 “ richten wir einen einfachen HTTP-Proxy ein, um den Datenverkehr auf mehrere Webserver zu verteilen. In diesem Artikel sehen wir uns zusätzliche Funktionen an, von denen einige in NGINX Plus verfügbar sind: Leistungsoptimierung mit Keepalives , Integritätschecks , Sitzungspersistenz , Weiterleitungen und Inhaltsneuschreibung .

Einzelheiten zu den Lastausgleichsfunktionen in NGINX und NGINX Plus finden Sie im NGINX Plus-Administratorhandbuch .

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 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/UDP -Upstream-Module.

Eine kurze Übersicht

Zur Wiederholung: Dies ist die Konfiguration , die wir im vorherigen Artikel erstellt haben:

server { listen 80;

location / {
proxy_pass http://backend;

# Schreiben Sie den Header „Host“ auf den Wert in der Client-Anforderung um,
    # oder den primären Servernamen
    proxy_set_header Host $host;

# Geben Sie den Wert alternativ in die Konfiguration ein:
# proxy_set_header Host www.example.com;
} 
}

upstream backend {
zone backend 64k; # Verwenden Sie den gemeinsam genutzten Speicher von NGINX Plus
least_conn;

server webserver1 weight=1;
server webserver2 weight=4;
}

In diesem Artikel sehen wir uns einige einfache Möglichkeiten zum Konfigurieren von NGINX und NGINX Plus an, die die Effektivität des Lastenausgleichs verbessern.

HTTP-Keepalives

Durch das Aktivieren von HTTP-Keepalives zwischen NGINX oder NGINX Plus und den Upstream-Servern wird die Leistung verbessert (durch Reduzierung der Latenz) und die Wahrscheinlichkeit verringert, dass NGINX keine temporären Ports mehr zur Verfügung stehen.

Das HTTP-Protokoll verwendet zugrunde liegende TCP-Verbindungen, um HTTP-Anfragen zu übertragen und HTTP-Antworten zu empfangen. HTTP-Keepalive-Verbindungen ermöglichen die Wiederverwendung dieser TCP-Verbindungen und vermeiden so den Aufwand, für jede Anforderung eine Verbindung herzustellen und zu zerstören:

NGINX ist ein vollwertiger Proxy und verwaltet Verbindungen von Clients (Frontend-Keepalive-Verbindungen) und Verbindungen zu Servern (Upstream-Keepalive-Verbindungen) unabhängig voneinander:

NGINX verwaltet einen „Cache“ mit Keepalive-Verbindungen – eine Reihe inaktiver Keepalive-Verbindungen zu den Upstream-Servern – und wenn es eine Anfrage an einen Upstream weiterleiten muss, verwendet es eine bereits hergestellte Keepalive-Verbindung aus dem Cache, anstatt eine neue TCP-Verbindung zu erstellen. Dadurch wird die Latenz für Transaktionen zwischen NGINX und den Upstream-Servern verringert und die Rate, mit der temporäre Ports verwendet werden, verringert, sodass NGINX große Datenmengen aufnehmen und deren Last ausgleichen kann. Bei einer großen Verkehrsspitze kann der Cache geleert werden und in diesem Fall stellt NGINX neue HTTP-Verbindungen zu den Upstream-Servern her.

Bei anderen Tools zum Lastenausgleich wird diese Technik manchmal als Multiplexing , Verbindungspooling , Verbindungswiederverwendung oder OneConnect bezeichnet.

Sie konfigurieren den Keepalive-Verbindungscache, indem Sie die Anweisungen proxy_http_version , proxy_set_header und keepalive in die Konfiguration aufnehmen:

Server { listen 80; Standort / { Proxy-Pass http://backend; Proxy-http_Version 1.1 ; Proxy-Set-Header Verbindung "" ; } } Upstream-Backend { Server Webserver1; Server Webserver2; # Bis zu 20 inaktive Verbindungen zur Gruppe der Upstream-Server aufrechterhalten Keepalive 20 ; }

Gesundheitschecks

Durch das Aktivieren von Integritätsprüfungen wird die Zuverlässigkeit Ihres Lastenausgleichsdienstes erhöht, die Wahrscheinlichkeit verringert, dass Endbenutzer Fehlermeldungen sehen, und es kann auch allgemeine Wartungsvorgänge erleichtern.

Mit der Integritätsprüfungsfunktion in NGINX Plus können Ausfälle von Upstream-Servern erkannt werden. NGINX Plus prüft jeden Server mithilfe „synthetischer Transaktionen“ und vergleicht die Antwort mit den Parametern, die Sie in der Direktive health_check konfigurieren (und, wenn Sie den Parameter match einschließen, mit dem zugehörigen Match- Konfigurationsblock):

Server { Listen 80; Standort / { Proxy-Pass http://backend; Gesundheitscheck Intervall=2s Fehler=1 Erfolge=5 URI=/test.php Match=statusok ; # Die Gesundheitschecks übernehmen andere Proxy-Einstellungen Proxy-Set_Header Host www.foo.com; } } Match Statusok { # Wird für den Gesundheitscheck von /test.php verwendet Status 200 ; Header Content-Type = Text/HTML ; Body ~ "Server[0-9]+ ist aktiv" ; }

Die Integritätsprüfung erbt einige Parameter von ihrem übergeordneten Standortblock . Dies kann zu Problemen führen, wenn Sie in Ihrer Konfiguration Laufzeitvariablen verwenden. Beispielsweise funktioniert die folgende Konfiguration für echten HTTP-Verkehr, da sie den Wert des Host- Headers aus der Client-Anforderung extrahiert. Es funktioniert wahrscheinlich nicht für die synthetischen Transaktionen, die der Integritätscheck verwendet, da der Host -Header für sie nicht festgelegt ist. Dies bedeutet, dass in der synthetischen Transaktion kein Host -Header verwendet wird.

location / { proxy_pass http://backend;

# Dieser Healthcheck funktioniert möglicherweise nicht...
health_check Intervall=2s Fehler=1 Erfolge=5 uri=/test.php Übereinstimmung=statusok;

# Extrahieren Sie den Header „Host“ aus der Anfrage
proxy_set_header Host $host;
}

Eine gute Lösung besteht darin, einen Dummy- Standortblock zu erstellen, der alle von der Integritätsprüftransaktion verwendeten Parameter statisch definiert:

location /internal-health-check1 { internal; # Verhindern, dass externe Anfragen diesem Standortblock entsprechen

proxy_pass http://backend;

health_check interval=2s fails=1 passes=5 uri=/test.php match=statusok;

# Anfrageparameter explizit festlegen; keine Laufzeitvariablen verwenden
proxy_set_header Host www.example.com;
}

Weitere Informationen finden Sie im NGINX Plus-Administratorhandbuch .

Sitzungspersistenz

Mithilfe der Sitzungspersistenz können Anwendungen, die nicht in einem Cluster bereitgestellt werden können, zuverlässig lastausgeglichen und skaliert werden. Anwendungen, die Sitzungszustände speichern und replizieren, arbeiten effizienter und die Leistung für den Endbenutzer verbessert sich.

Bestimmte Anwendungen speichern manchmal Statusinformationen auf den vorgelagerten Servern, beispielsweise wenn ein Benutzer einen Artikel in einen virtuellen Einkaufswagen legt oder ein hochgeladenes Bild bearbeitet. In diesen Fällen möchten Sie möglicherweise alle nachfolgenden Anfragen dieses Benutzers an denselben Server weiterleiten.

Die Sitzungspersistenz gibt an, wohin eine Anforderung weitergeleitet werden muss, während die Lastverteilung NGINX die Freiheit gibt, den optimalen Upstream-Server auszuwählen. Die beiden Prozesse können mithilfe der Sitzungspersistenzfunktion von NGINX Plus koexistieren:

   Wenn die Anfrage einer Sitzungspersistenzregel entspricht
dann verwenden Sie den Ziel-Upstream-Server
Andernfalls wenden Sie den Lastausgleichsalgorithmus an, um den Upstreamserver auszuwählen

Wenn die Entscheidung zur Sitzungspersistenz fehlschlägt, weil der Zielserver nicht verfügbar ist, trifft NGINX Plus eine Entscheidung zum Lastenausgleich.

Die einfachste Methode zur Sitzungspersistenz ist der „ Sticky-Cookie “-Ansatz, bei dem NGINX Plus in die erste Antwort ein Cookie einfügt, das den Sticky-Upstream-Server identifiziert:

Sticky Cookie srv_id läuft ab=1h Domäne=.example.com Pfad=/;

Bei der alternativen Methode „ Sticky Route “ wählt NGINX den Upstream-Server anhand von Anforderungsparametern wie dem JSESSIONID-Cookie aus:

Upstream-Backend { Server backend1.example.com Route=a ; Server backend2.example.com Route=b ; # wähle die erste nicht leere Variable; sie sollte entweder „a“ oder „b“ enthalten. Sticky-Route $route_cookie $route_uri ; }

Weitere Informationen finden Sie im NGINX Plus-Administratorhandbuch .

HTTP-Weiterleitungen neu schreiben

Schreiben Sie HTTP-Weiterleitungen neu, wenn einige Weiterleitungen fehlerhaft sind, und insbesondere, wenn Sie feststellen, dass Sie vom Proxy zum echten Upstream-Server umgeleitet werden.

Wenn Sie einen Proxy zu einem Upstream-Server verwenden, veröffentlicht der Server die Anwendung unter einer lokalen Adresse, Sie greifen jedoch über eine andere Adresse auf die Anwendung zu – die Adresse des Proxys. Diese Adressen werden normalerweise in Domänennamen aufgelöst. Wenn der Server und der Proxy unterschiedliche Domänen haben, können Probleme auftreten.

In einer Testumgebung könnten Sie Ihren Proxy beispielsweise direkt (über die IP-Adresse) oder als localhost ansprechen. Der Upstream-Server lauscht jedoch möglicherweise auf einem echten Domänennamen (wie etwa www.nginx.com ). Wenn der Upstream-Server eine Umleitungsnachricht ausgibt (mithilfe eines 3xx- Status- und Standortheaders oder mithilfe eines Aktualisierungsheaders ), kann die Nachricht die tatsächliche Domäne des Servers enthalten.

NGINX versucht, die häufigsten Fälle dieses Problems abzufangen und zu beheben. Wenn Sie die volle Kontrolle benötigen, um bestimmte Umschreibungen zu erzwingen, verwenden Sie die Direktive proxy_redirect wie folgt:

Proxy-Umleitung http://staging.mysite.com/ http://$host/;

Umschreiben von HTTP-Antworten

Manchmal müssen Sie den Inhalt in einer HTTP-Antwort neu schreiben. Möglicherweise enthält die Antwort, wie im obigen Beispiel, absolute Links, die auf einen anderen Server als den Proxy verweisen.

Mit der Direktive „sub_filter“ können Sie die anzuwendende Umschreibung definieren:

Unterfilter /blog/ /blog-staging/;
Unterfilter_einmalig aus;

Ein sehr häufiges Problem ist die Verwendung der HTTP-Komprimierung. Wenn der Client signalisiert, dass er komprimierte Daten akzeptieren kann, und der Server dann die Antwort komprimiert, kann NGINX die Antwort nicht prüfen und ändern. Die einfachste Maßnahme besteht darin, den Accept-Encoding- Header aus der Client-Anfrage zu entfernen, indem Sie ihn auf den leeren String ( "" ) setzen:

proxy_set_header Accept-Kodierung "";

Ein vollständiges Beispiel

Hier ist eine Vorlage für eine Lastausgleichskonfiguration, die alle in diesem Artikel besprochenen Techniken verwendet. Die in NGINX Plus verfügbaren erweiterten Funktionen sind orange hervorgehoben.

[Editor – Die folgende Konfiguration wurde aktualisiert, um die NGINX Plus-API für die Live-Aktivitätsüberwachung und dynamische Konfiguration von Upstream-Gruppen zu verwenden und die ursprünglich verwendeten separaten Module zu ersetzen.]

Server { listen 80; Standort / { Proxy-Pass http://backend; Proxy-http_Version 1.1; Proxy-Set_Header Verbindung ""; Proxy-Set_Header Accept-Encoding ""; Proxy-Redirect http://staging.example.com/ http://$host/; # Host-Header auf den Wert in der Client-Anforderung umschreiben Proxy-Set_Header Host $host; # Alle Inline-Referenzen auf staging.example.com ersetzen Subfilter http://staging.example.com/ /; Subfilter_once aus; } Standort /internal-health-check1 { intern; # Verhindern, dass externe Anforderungen mit diesem Standortblock übereinstimmen Proxy-Pass http://backend; Health_Check Intervall=2 s Fehler=1 Durchläufe=5 URI=/test.php Übereinstimmung=statusok ; # Anforderungsparameter explizit festlegen; keine Laufzeitvariablen verwenden Proxy-Set_Header Host www.example.com; } Upstream-Backend { Zone Backend 64k ; # Verwenden Sie den gemeinsam genutzten Speicher von NGINX Plus least_conn; keepalive 20; # Wenden Sie die Sitzungspersistenz für diese Upstream-Gruppe an sticky cookie srv_id expires=1h domain=.example.com path=/servlet ; server webserver1 weight=1; server webserver2 weight=4; } match statusok { # Wird für die Integritätsprüfung von /test.php verwendet status 200 ; header Content-Type = text/html ; body ~ "Server[0-9]+ ist aktiv" ; } server { listen 8080; root /usr/share/nginx/html; location = /api { api write=on ; # Live-Aktivitätsüberwachung und # dynamische Konfiguration von Upstream-Gruppen allow 127.0.0.1; # Zugriff von localhost erlauben deny all; # Zugriff von überall sonst verweigern } }

Probieren Sie alle großartigen Lastausgleichsfunktionen in NGINX Plus selbst aus – starten Sie noch heute Ihre kostenlose 30-Tage-Testversion oder kontaktieren Sie uns, um Ihre Anwendungsfälle zu besprechen .