F5 NGINX Plus: Load Balancing

HTTP-Load Balancing

Beim Lastausgleich des HTTP-Datenverkehrs beendet NGINX Plus jede HTTP-Verbindung und verarbeitet jede Anfrage einzeln. Sie können die SSL/TLS-Verschlüsselung entfernen, die Abfrage untersuchen und manipulieren, die Abfrage mit Hilfe von Ratenbegrenzungen in eine Warteschlange stellen und dann die Lastenausgleichsrichtlinie auswählen.

Zur Leistungsverbesserung kann NGINX Plus automatisch eine breite Palette an Optimierungen auf eine HTTP-Transaktion anwenden, einschließlich HTTP-Protokoll-Upgrades, keepalive-Optimierung und Transformationen wie Inhaltskomprimierung und Reaktions-Caching.

Der Lastenausgleich des HTTP-Datenverkehrs ist mit NGINX Plus ganz einfach:

http {
    upstream my_upstream {
        server server1.example.com;
        server server2.example.com;
    }

    server {
        listen 80;
        location / {
            proxy_set_header Host $host;
            proxy_pass http://my_upstream;
        }
    }
}

Spezifizieren Sie zunächst einen virtuellen Server mit der Server-Anweisung. Anschließend geben Sie den Port für listen an, über den der Datenverkehr kontrolliert werden soll. Passen Sie die URLs von Client-Abfragen mit einem location-Block an, richten Sie den Host-Header mit der proxy_set_header-Anweisung ein und fügen Sie die proxy_pass-Anweisung ein, um die Anfrage an eine Upstream-Gruppe weiterzuleiten. (Der Upstream-Block definiert die Server, über die NGINX Plus den Datenverkehr ausgleicht)

Weitere Informationen finden Sie in dieser Einführung in Load Balancing mit NGINX und NGINX Plus.

TCP- und UDP-Load Balancing

NGINX Plus kann auch einen Lastenausgleich für TCP-Anwendungen wie MySQL und UDP-Anwendungen wie DNS und RADIUS vornehmen. Bei TCP-Anwendungen beendet NGINX Plus die TCP-Verbindungen und baut neue Verbindungen zum Backend auf.

stream {
    upstream my_upstream {
        server server1.example.com:1234;
        server server2.example.com:2345;
    }

    server {
        listen 1123 [udp];
        proxy_pass my_upstream;
    }
}

Die Konfiguration ist ähnlich wie bei HTTP: Spezifizieren Sie einen virtuellen Server mit der Server-Anweisung, nutzen Sie listen für die Datenverkehrsüberwachung auf einem Port und verwenden Sie die proxy_pass-Anweisung für eine Upstream-Gruppe.

Weitere Informationen zum TCP- und UDP-Lastenausgleich finden Sie im NGINX Plus Administratorleitfaden.

Methoden zum Load Balancing

NGINX Plus unterstützt eine Reihe von Methoden für den HTTP-, TCP- und UDP-Lastenausgleich. Alle Methoden berücksichtigen die Gewichtung, die Sie jedem Upstream-Server optional zuweisen können.

• Round Robin (Standard) – Verteilt die Anfragen der Reihe nach auf die Upstream-Server.
• Wenigsten Verbindungen – Leitet Anfragen an den Server mit der geringsten Anzahl aktiver Verbindungen weiter.
• Kürzeste Dauer – Leitet Anfragen an den am wenigsten ausgelasteten Server weiter, basierend auf einer Berechnung, die Reaktionszeit und Anzahl der aktiven Verbindungen kombiniert. Exklusiv für NGINX Plus.
• Hash – Verteilt Anfragen auf der Grundlage eines bestimmten Schlüssels, z. B. der Client-IP-Adresse oder der Anfrage-URL. NGINX Plus kann optional einen konsistenten Hash anwenden, um die Lastenverteilung zu minimieren, wenn sich die Menge der Upstream-Server ändert.
• IP Hash (nur HTTP) – Verteilt Anfragen basierend auf den ersten drei Oktetten der Client-IP-Adresse.
• Willkürlich mit zwei Auswahlmöglichkeiten  Wählt zwei Server nach dem Zufallsprinzip aus und leitet die Anfrage an den Server mit der geringeren Anzahl aktiver Verbindungen weiter (Methode der wenigsten Verbindungen). Bei NGINX Plus kann zudem auch die Methode „Kürzeste Dauer“ verwendet werden.

Verbindungsbegrenzung mit NGINX Plus

Sie können die Anzahl der Verbindungen, die NGINX Plus mit Upstream-HTTP- oder TCP-Servern herstellt, oder die Anzahl der Sitzungen mit UDP-Servern begrenzen. Wenn die Anzahl der Verbindungen oder Sitzungen über einen Server einen festgelegten Grenzwert überschreitet, stellt NGINX Plus den Aufbau neuer Verbindungen ein.

Im folgenden Konfigurationsausschnitt ist das Verbindungslimit für webserver1 auf 250 und für webserver2 auf 150 festgelegt. Die queue-Anweisung gibt die maximale Anzahl der überschüssigen Verbindungen an, die NGINX Plus in die Warteschlange des Betriebssystems stellt, und zwar für jeweils bis zu 30 Sekunden. Weitere überschüssige Anfragen werden verworfen.

upstream backend {
    zone backends 64k;
    queue 750 timeout=30s;

    server webserver1 max_conns=250;
    server webserver2 max_conns=150;
}

Wenn die Anzahl der aktiven Verbindungen auf einem Server unter den Grenzwert fällt, sendet NGINX Plus dem Server Verbindungen aus der Warteschlange zu. Die Begrenzung der Verbindungen trägt dazu bei, eine konsistente und vorhersehbare Bearbeitung von Client-Anfragen zu gewährleisten – auch bei hohem Datenverkehrsaufkommen.

Sitzungspersistenz

Sie können NGINX Plus so konfigurieren, dass es Benutzersitzungen identifiziert und alle Anfragen innerhalb einer Sitzung an denselben Upstream-Server sendet. Das ist von entscheidender Bedeutung, wenn Anwendungsserver den Status lokal speichern, da fatale Fehler auftreten, wenn eine Anfrage für eine laufende Benutzersitzung an einen anderen Server gesendet wird. Die Sitzungspersistenz kann auch zu Leistungsverbesserungen führen, wenn Anwendungen Informationen in einem Cluster gemeinsam nutzen.

Zusätzlich zur Hash-basierten Sitzungspersistenz, die von NGINX Open Source unterstützt wird (die Hash- und IP-Hash-Lastenausgleichsmethode), unterstützt NGINX Plus die Cookie-basierte Sitzungspersistenz, einschließlich Sticky-Cookie. NGINX Plus fügt der ersten Reaktion der Upstream-Gruppe auf einen bestimmten Client ein Sitzungs-Cookie hinzu, das sicher identifiziert, welcher Server die Antwort generiert hat. Nachfolgende Client-Anfragen enthalten das Cookie, das NGINX Plus verwendet, um die Anfrage an denselben Upstream-Server zu leiten:

upstream backend {
    server webserver1;
    server webserver2;

    sticky cookie srv_id expires=1h domain=.example.com path=/;
}

Im obigen Beispiel fügt NGINX Plus ein Cookie mit der Bezeichnung srv_id in die erste Client-Antwort ein, um den Server zu identifizieren, der die Anfrage bearbeitet hat. Wenn eine nachfolgende Anfrage das Cookie enthält, leitet NGINX Plus diese an denselben Server weiter.

NGINX Plus unterstützt auch die Methoden „Sticky Learn“ und „Sticky-Route Persistenz“.

Hinweis: Die Cookie-basierte Sitzungspersistenz ist exklusiv für NGINX Plus.

Aktive Zustandsprüfungen

Standardmäßig führt NGINX grundlegende Überprüfungen der Reaktionen von Upstream-Servern durch und wiederholt fehlgeschlagene Anfragen, wenn möglich. NGINX Plus fügt Out-of-Band-Zustandsprüfungen für Anwendungen (auch bekannt als synthetische Transaktionen) und eine Slow-Start-Funktion hinzu, um neue und wiederhergestellte Server ordnungsgemäß in die Lastenausgleichsgruppe aufzunehmen.

Dank dieser Funktionen kann NGINX Plus eine Vielzahl von Problemen erkennen und beheben, wodurch die Zuverlässigkeit Ihrer HTTP- und TCP/UDP-Anwendungen erheblich verbessert wird.

upstream my_upstream {
	zone my_upstream 64k;
	server server1.example.com slow_start=30s;
}

server {
    # ...
    location /health {
        internal;
        health_check interval=5s uri=/test.php match=statusok;
        proxy_set_header Host www.example.com;
        proxy_pass http://my_upstream
    }
}

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

Im obigen Beispiel sendet NGINX Plus alle fünf Sekunden eine Anfrage an /test.php. Der match-Block definiert die Bedingungen, die die Antwort erfüllen muss, damit der Upstream-Server als gesund gilt: ein Status-Code von 200 OK und ein Antwortkörper mit dem Text ServerN is alive.

Hinweis: Aktive Zustandsprüfungen sind nur bei NGINX Plus verfügbar.

Dienstsuche über DNS

Standardmäßig lösen NGINX Plus Server DNS-Namen beim Start auf und speichern die aufgelösten Werte dauerhaft. Wenn Sie einen Domänennamen wie example.com verwenden, um eine Gruppe von Upstream-Servern mit der server-Anweisung und dem resolve-Parameter zu identifizieren, löst NGINX Plus den Domänennamen regelmäßig erneut auf. Wenn sich die zugehörige Liste der IP-Adressen geändert hat, beginnt NGINX Plus sofort mit dem Lastenausgleich über die aktualisierte Servergruppe.

Um NGINX Plus für die Verwendung von DNS SRV-Einträgen zu konfigurieren, fügen Sie die resolver-Anweisung zusammen mit dem service=http-Parameter in die Server-Anweisung ein:

resolver 127.0.0.11 valid=10s;

upstream service1 {
    zone service1 64k;
    server service1 service=http resolve;
}

Im obigen Beispiel fragt NGINX Plus alle 10 Sekunden 127.0.0.11 (den integrierten Docker-DNS-Server) ab, um den Domänennamen service1 neu aufzulösen.

Hinweis: Die Dienstsuche über DNS ist exklusiv für NGINX Plus.

NGINX Plus API

NGINX Plus umfasst eine RESTful API mit einem einzigen API-Endpunkt. Setzen Sie NGINX Plus API zur Aktualisierung der Upstream-Konfigurationen und Schlüsselwertspeicherungen ohne Ausfallzeiten ein.

Der folgende Konfigurationsausschnitt enthält die api-Anweisung, um den Lese- und Schreibzugriff auf den /api-Endpunkt zu ermöglichen.

upstream backend {
    zone backends 64k;
    server 10.10.10.2:220 max_conns=250;
    server 10.10.10.4:220 max_conns=150;
}

server {
    listen 80;
    server_name www.example.org;

    location /api {
        api write=on;
    }
}

Wenn die API wie im obigen Beispiel aktiviert ist, können Sie mit dem folgenden curl-Befehl einen neuen Server zu einer bestehenden Upstream-Gruppe hinzufügen. Er nutzt die POST-Methode und JSON-Kodierung, um die IP-Adresse des Servers auf 192.168.78.66, sein Gewicht auf 200 und die maximale Anzahl gleichzeitiger Verbindungen auf 150 zu setzen. (Für version ersetzen Sie die aktuelle Versionsnummer der API, wie sie in der Referenzdokumentation angegeben ist.)

$ curl -iX POST -d '{"server":"192.168.78.66:80","weight":"200","max_conns":"150"}' http://localhost:80/api/version/http/upstreams/backend/servers/

Um die vollständige Konfiguration aller Backend-Upstream-Server im JSON-Format anzuzeigen, Folgendes ausführen:

$ curl -s http://localhost:80/api/version/http/upstreams/backend/servers/ | python -m json.tool
	{
      "backup": false,
      "down": false,
      "fail_timeout": "10s",
      "id": 0,
      "max_conns": 250,
      "max_fails": 1,
      "route": "",
      "server": "10.10.10.2:220",
      "slow_start": "0s",
      "weight": 1
      },
      {
      "backup": false,
      "down": false,
      "fail_timeout": "10s",
      "id": 1,
      "max_conns": 150,
      "max_fails": 1,
      "route": "",
      "server": "10.10.10.4:220",
      "slow_start": "0s",
      "weight": 1
      },
      {
      "backup": false,
      "down": false,
      "fail_timeout": "10s",
      "id": 2,
      "max_conns": 200,
      "max_fails": 1,
      "route": "",
      "server": "192.168.78.66:80",
      "slow_start": "0s",
      "weight": 200
      }

Um die Konfiguration eines vorhandenen Upstream-Servers zu ändern, führen Sie Identifizierungen anhand seiner internen ID durch, die in der obigen Ausgabe im Feld id erscheint. Der folgende Befehl verwendet die PATCH-Methode, um den Server mit ID 2 neu zu konfigurieren, indem er seine IP-Adresse und den Listening-Port auf 192.168.78.55:80, sein Gewicht auf 500 und das Verbindungslimit auf 350 setzt.

$ curl -iX PATCH -d '{"server":"192.168.78.55:80","weight":"500","max_conns":"350"}' http://localhost:80/api/version/http/upstreams/backend/servers/2

Die vollständige Swagger-Dokumentation (OpenAPI-Spezifikation) der NGINX Plus API finden Sie unter https://demo.nginx.com/swagger-ui/.

Hinweis: Die NGINX Plus API ist exklusiv für NGINX Plus.