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;

        # Rewrite the 'Host' header to the value in the client request,
        # or primary server name
        proxy_set_header Host $host;

        # Alternatively, put the value in the config:
        # proxy_set_header Host www.example.com;
    } 
}

upstream backend {
    zone backend 64k;  # Use NGINX Plus' shared memory
    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;
    location / {
        proxy_pass http://backend;
        proxy_http_version 1.1;
        proxy_set_header Connection "";
     }
}

upstream backend {
    server webserver1;
    server webserver2;

    # maintain up to 20 idle connections to the group of upstream servers
    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;

    location / {
        proxy_pass http://backend;

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

        # The health checks inherit other proxy settings
        proxy_set_header Host www.foo.com;
    }
}

match statusok {
    # Used for /test.php health check
    status 200;
    header Content-Type = text/html;
    body ~ "Server[0-9]+ is alive";
}

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;

    # This health check might not work...
    health_check interval=2s fails=1 passes=5 uri=/test.php match=statusok;

    # Extract the 'Host' header from the request
    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; # Prevent external requests from matching this location block

    proxy_pass http://backend;

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

    # Explicitly set request parameters; don't use run-time variables
    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 expires=1h domain=.example.com path=/;

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;

    # select first non-empty variable; it should contain either 'a' or 'b'
    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_redirect 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:

sub_filter /blog/ /blog-staging/;
sub_filter_once off;

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-Encoding "";

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;

    location / {
        proxy_pass http://backend;

        proxy_http_version 1.1;
        proxy_set_header Connection "";
        proxy_set_header Accept-Encoding "";
        proxy_redirect http://staging.example.com/ http://$host/;

        # Rewrite the Host header to the value in the client request
        proxy_set_header Host $host;

        # Replace any references inline to staging.example.com
        sub_filter http://staging.example.com/ /;
        sub_filter_once off;
    }

    location /internal-health-check1 {
        internal; # Prevent external requests from matching this location block
        proxy_pass http://backend;
        health_check interval=2s fails=1 passes=5 uri=/test.php match=statusok;
        # Explicitly set request parameters; don't use runtime variables
        proxy_set_header Host www.example.com;
    }
 
upstream backend {
    zone backend 64k; # Use NGINX Plus' shared memory
    least_conn;
    keepalive 20;

    # Apply session persistence for this upstream group
    sticky cookie srv_id expires=1h domain=.example.com path=/servlet;

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

match statusok {
    # Used for /test.php health check
    status 200;
    header Content-Type = text/html;
    body ~ "Server[0-9]+ is alive";
}

server {
    listen 8080;
    root /usr/share/nginx/html;

    location = /api {
        api write=on; # Live activity monitoring and
                      # dynamic configuration of upstream groups

        allow 127.0.0.1; # permit access from localhost
        deny all;        # deny access from everywhere else
    }
}

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 .