Lastverteilung mit NGINX und NGINX Plus, Teil 1

Owen GarrettSenior Director, Produktmanagement

NGINX ist ein leistungsfähiger Beschleunigungs-Proxy für eine Vielzahl HTTP-basierter Anwendungen. Seine Caching-Funktionen, die Verarbeitung von HTTP-Verbindungen und die Auslagerung von Aufgaben steigern die Anwendungsleistung erheblich, insbesondere bei hoher Auslastung.

Anmerkung der Redaktion – NGINX Plus Version 5 und höher kann auch die Last für TCP-basierte Anwendungen verteilen. Der TCP-Lastenausgleich wurde in Version 6 durch Zustandsprüfungen, dynamische Neukonfiguration, SSL-Terminierung und weitere Funktionen erheblich erweitert. In NGINX Plus Version 7<.htmla> und höher bietet der TCP-Lastenausgleich denselben Funktionsumfang wie der HTTP-Lastenausgleich. Die Unterstützung für UDP-Lastenausgleich wurde mit Version 9 eingeführt.

Sie konfigurieren den TCP- und UDP-Lastenausgleich im stream-Kontext anstelle des http-Kontexts. Die verfügbaren Direktiven und Parameter unterscheiden sich aufgrund der grundlegenden Unterschiede zwischen HTTP und TCP/UDP geringfügig. Weitere Informationen finden Sie in der Dokumentation zu den Upstream-Modulen für HTTP und TCP.

NGINX Plus erweitert die Funktionen von NGINX um zusätzliche Lastverteilungsfunktionen: Systemzustandsprüfungen, Sitzungspersistenz, Live-Aktivitätsüberwachung und dynamische Konfiguration von Servergruppen mit Lastverteilung.

Dieser Blogbeitrag führt Sie durch die Konfiguration von NGINX für die Lastverteilung des Datenverkehrs auf mehrere Webserver. Außerdem werden einige der zusätzlichen Funktionen von NGINX Plus vorgestellt.

Weitere Informationen finden Sie auch im NGINX Plus-Administratorhandbuch sowie im Folgeartikel Lastverteilung mit NGINX und NGINX Plus, Teil 2.

Traffic mit NGINX weiterleiten

Zunächst leiten wir den Datenverkehr per Proxy an zwei Upstream-Webserver weiter. Die folgende NGINX-Konfiguration genügt, um alle HTTP-Anfragen an Port 80 zu terminieren und sie nach dem Round-Robin-Verfahren auf die Webserver in der Upstream-Gruppe zu verteilen:

http {    server {
        listen 80;

        location / {
            proxy_pass http://backend;
        }
    }

    upstream backend {
        server web-server1:80;
        server web-server2:80;
    }
}

Mit dieser einfachen Konfiguration leitet NGINX jede an Port 80 eingehende Anfrage abwechselnd an web-server1 und web-server2 weiter und stellt dabei jeweils eine neue HTTP-Verbindung her.

Festlegen der Lastverteilungsmethode

Standardmäßig verwendet NGINX das Round-Robin-Verfahren, um den Datenverkehr gleichmäßig auf die Server zu verteilen. Dabei kann jedem Server optional eine „Gewichtung“ zugewiesen werden, die seine relative Kapazität angibt.

Die IP-Hash-Methode verteilt den Datenverkehr anhand eines Hashwerts 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 jedes Mal neu berechnet wird, wenn ein Server ausfällt oder wieder verfügbar ist oder wenn die Upstream-Gruppe geändert wird. NGINX Plus bietet bessere Lösungen, wenn Sitzungspersistenz erforderlich ist.

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

Alle Lastverteilungsverfahren können mithilfe eines optionalen Parameters weight in der Direktive server angepasst werden. Dies ist sinnvoll, wenn die Server unterschiedliche Verarbeitungskapazitäten haben. Im folgenden Beispiel leitet NGINX viermal so viele Anfragen an web-server2 wie an web-server1 weiter:

upstream backend {    zone backend 64k;
    least_conn;

    server web-server1 weight=1;
    server web-server2 weight=4;
}

In NGINX werden Gewichtungen von jedem Worker-Prozess unabhängig verwaltet. NGINX Plus verwendet ein gemeinsam genutztes Speichersegment für Upstream-Daten (konfiguriert mit der zone-Direktive), sodass die Gewichtungen von den Workern gemeinsam genutzt werden und der Datenverkehr präziser verteilt wird.

Fehlererkennung

Wenn beim Versuch von NGINX, eine Verbindung zu einem Server herzustellen, eine Anfrage an ihn weiterzuleiten oder den Antwort-Header zu lesen, ein Fehler oder eine Zeitüberschreitung auftritt, wiederholt NGINX den Verbindungsversuch mit einem anderen Server. (Sie können die Direktive proxy_next_upstream in die Konfiguration aufnehmen, um weitere Bedingungen für die Wiederholung der Anfrage festzulegen.) Darüber hinaus kann NGINX den ausgefallenen Server aus der Gruppe der potenziellen Server entfernen und gelegentlich Anfragen an ihn senden, um festzustellen, wann er wieder verfügbar ist. Die Parameter max_fails und fail_timeout der Direktive server steuern dieses Verhalten.

NGINX Plus bietet eine Reihe von Out-of-Band-Integritätsprüfungen für umfassende HTTP-Tests der einzelnen Upstream-Server, um festzustellen, ob sie aktiv sind, sowie einen Langsamanlaufmechanismus, mit dem wiederhergestellte Server schrittweise wieder in die Load-Balancing-Gruppe aufgenommen werden:

server web-server1 slow_start=30s;

Ein häufiger Stolperstein – Korrektur des Host-Headers

Sehr häufig verwendet ein Upstream-Server den Host-Header in der Anfrage, um zu bestimmen, welche Inhalte ausgeliefert werden sollen. Wenn unerwartete 404-Fehler vom Server auftreten oder etwas anderes darauf hindeutet, dass er die falschen Inhalte ausliefert, sollten Sie dies als Erstes überprüfen. Fügen Sie anschließend die Direktive proxy_set_header in die Konfiguration ein, um den passenden Wert für den Header festzulegen:

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;
}

Erweiterter Lastenausgleich mit NGINX Plus

Dank einer Reihe fortschrittlicher Funktionen eignet sich NGINX Plus ideal als Load Balancer vor Gruppen von Upstream-Servern:

• Lastverteilung und Sitzungspersistenz – Verbesserte Lastverteilung über Worker-Prozesse hinweg sowie Methoden zur Sitzungspersistenz, um Anwendungssitzungen zu erkennen und beizubehalten
• HTTP-Zustandsprüfung und langsamer Serverstart – Asynchrone „synthetische Transaktionen“ zur Überprüfung des ordnungsgemäßen Betriebs jedes Upstream-Servers sowie zur kontrollierten Wiedereinbindung wiederhergestellter Server mittels „Slow Start“
• Live-Aktivitätsüberwachung – Sofortige Anzeige von Aktivität und Leistung
• Dynamisch konfigurierte Upstream-Servergruppen – Tool zur Vereinfachung gängiger Aufgaben bei der Upstream-Verwaltung, beispielsweise zum sicheren und vorübergehenden Entfernen eines Servers

Weitere Informationen zu erweitertem Load Balancing und Proxying finden Sie im Folgebeitrag Load Balancing mit NGINX und NGINX Plus, Teil 2.

Wenn Sie NGINX Plus ausprobieren möchten, starten Sie noch heute Ihre kostenlose 30-Tage-Testversion oder kontaktieren Sie uns, um Ihre Anwendungsfälle für den Lastenausgleich zu besprechen.

Über den Autor

Owen GarrettSenior Director, Produktmanagement

Weitere Blogbeiträge von Owen Garrett