Auswahl einer Lastverteilungstechnik für NGINX Plus

Tony Mauro

Wir haben bereits ausführlich darüber berichtet, wie Sie NGINX Plus und NGINX Open Source für den Lastenausgleich Ihrer Websites und Apps einsetzen können, um optimale Verfügbarkeit und Zuverlässigkeit zu gewährleisten. Lastenausgleich ist ein grundlegendes Instrument, um die App-Performance zu steigern, Apps in großem Maßstab bereitzustellen, und Container und Microservices bereitzustellen.

Wir haben bereits erläutert, wie Sie NGINX Plus im Rechenzentrum (möglicherweise zusammen mit älteren Application Delivery Controllern), in Containern, sowie in Cloud-Umgebungen bereitstellen können, darunter Amazon Web Services (AWS), die Google Cloud Platform, und Microsoft Azure.

In diesem Beitrag konzentrieren wir uns auf die Lastverteilungstechniken (auch als Lastverteilungsmethoden oder -algorithmen bezeichnet) in NGINX Plus und NGINX und geben einige Tipps zur Auswahl der richtigen Methode für verschiedene Anwendungsfälle. NGINX bietet vier Lastverteilungstechniken (Round Robin, Hash, IP Hash und Least Connections); NGINX Plus bietet darüber hinaus eine weitere Methode (Least Time). Mit Ausnahme von IP Hash sind alle Methoden für HTTP-Datenverkehr auch für TCP verfügbar (und ab NGINX Plus Release 9 auch für UDP).

[Redaktion – NGINX Plus R16 und NGINX Open Source 1.15.1 führten „Random with Two Choices“ als zusätzlichen Lastverteilungsalgorithmus ein. Weitere Informationen finden Sie unter NGINX und der Lastverteilungsalgorithmus „Power of Two Choices“ in unserem Blog.]

Überblick über die Lastverteilungstechniken

Wir gehen davon aus, dass Sie mit den Grundlagen der Konfiguration von Load Balancing vertraut sind. Falls Sie Ihr Wissen auffrischen möchten, können Sie sich jedoch diese Ressourcen ansehen:

• Die Artikel im NGINX Plus Admin Guide bieten einen vollständigen Überblick.
• Hochleistungs-Lastverteilung verweist auf ausführliche Erläuterungen zu erweiterten Funktionen in NGINX Plus, mit denen sich die Effizienz einer Lastverteilungsmethode noch weiter steigern lässt.
• Lastverteilung mit NGINX und NGINX Plus, Teil 1 und Teil 2 ist eine Schritt-für-Schritt-Anleitung, in der ein einfacher Reverse-Proxy mithilfe der erweiterten Funktionen von NGINX Plus zu einer umfassenden Lastverteilungslösung ausgebaut wird.
• Die Seite „Load Balancing“ enthält Links zu weiteren Ressourcen, darunter E-Books, Webinare und Whitepaper.

Der Einfachheit halber konzentrieren wir uns auf den HTTP-Lastenausgleich, den Sie im http-Kontext konfigurieren. Der TCP-Lastenausgleich wird stattdessen im stream-Kontext konfiguriert (ebenso wie der UDP-Lastenausgleich ab NGINX Plus Release 9). Obwohl die HTTP- und TCP/UDP-Load-Balancer denselben Funktionsumfang bieten, unterscheiden sich die verfügbaren Direktiven und Parameter aufgrund der inhärenten Unterschiede zwischen den Protokollen geringfügig. Weitere Informationen finden Sie in der Dokumentation zu den Upstream-Modulen für HTTP und TCP/UDP.

Sie aktivieren den Lastenausgleich mit zwei Konfigurationsblöcken, die wir im Folgenden in ihrer Grundform ohne optionale Parameter oder zusätzliche Funktionen zeigen:

• Der server-Block definiert einen virtuellen Server, der auf Datenverkehr mit den von Ihnen festgelegten Eigenschaften wartet und ihn an eine benannte Gruppe von Upstream-Servern weiterleitet. In unseren Beispielen wartet der virtuelle Server am Standardport (80) auf den an www.example.com gesendeten HTTP-Datenverkehr und leitet ihn an die Upstream-Servergruppe namens backend weiter. Dieser Block ist in allen unseren Beispielen identisch.

server {    server_name www.example.com;

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

• (NGINX Plus und NGINX können auch die Lastverteilung für FastCGI-, memcached-, SCGI- und uwsgi-Backend-Server übernehmen. Ersetzen Sie proxy_pass durch die entsprechende Direktive – fastcgi_pass, memcached_pass, scgi_pass oder uwsgi_pass.)
• Der upstream-Block benennt eine Upstream-Gruppe und führt die zugehörigen Server auf, die anhand ihres Hostnamens, ihrer IP-Adresse oder des Pfads zu ihrem UNIX-Domain-Socket identifiziert werden. In unseren Beispielen umfasst die Upstream-Gruppe namens backend drei Server: web1, web2 und web3. Im upstream-Block legen Sie das Lastverteilungsverfahren fest. Daher werden wir diesen Block in den folgenden Abschnitten besonders hervorheben. Als Beispiel sehen Sie hier den Block für das Standardverfahren Round Robin:

upstream backend {    server web1;
    server web2;
    server web3;
}

Round-Robin

Round Robin ist die standardmäßige Lastverteilungsmethode für NGINX Plus und NGINX. Der Load Balancer durchläuft die Liste der Upstream-Server der Reihe nach und weist jedem Server abwechselnd die nächste Verbindungsanfrage zu.

Bei der folgenden Beispielkonfiguration der Upstream-Gruppe backend leitet der Load Balancer die ersten drei Verbindungsanfragen der Reihe nach an web1, web2 und web3 weiter, die vierte an web1, die fünfte an web2 und so weiter.

upstream backend {    server web1;
    server web2;
    server web3;
}

server {
    server_name www.example.com;

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

Hash

Bei der Hash-Methode berechnet der Load Balancer für jede Anfrage einen Hash, der auf der Kombination aus dem angegebenen Text und den angegebenen NGINX-Variablen basiert, und ordnet den Hash einem der Server zu. Er sendet alle Anfragen mit diesem Hash an diesen Server. Diese Methode stellt somit eine grundlegende Form der Sitzungspersistenz her.

Im folgenden Beispiel verwendet die hash-Direktive das Schema (http oder https) und den vollständigen URI der Anfrage als Grundlage für den Hash:

upstream backend {    hash $scheme$request_uri;

    server web1;
    server web2;
    server web3;
}

server {
    server_name www.example.com;

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

IP-Hash

IP-Hash (nur für HTTP verfügbar) ist eine vordefinierte Variante der Hash-Methode, bei der der Hash auf der IP-Adresse des Clients basiert. Sie konfigurieren ihn mit der Direktive „ip_hash“.

upstream backend {    ip_hash;

    server web1;
    server web2;
    server web3;
}

server {
    server_name www.example.com;

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

Wenn der Client eine IPv6-Adresse hat, basiert der Hash auf der gesamten Adresse. Bei einer IPv4-Adresse basiert der Hash hingegen nur auf den ersten drei Oktetten der Adresse. Dies ist für Clients von Internetanbietern optimiert, denen IP-Adressen dynamisch aus einem Subnetzbereich (/24) zugewiesen werden. Nach einem Neustart oder einer erneuten Verbindung ändert sich die Adresse des Clients häufig in eine andere Adresse innerhalb des /24-Netzbereichs. Da die Verbindung jedoch weiterhin demselben Client zuzuordnen ist, besteht kein Grund, die Zuordnung zum Server zu ändern.

Wenn jedoch der Großteil des Datenverkehrs zu Ihrer Website von Clients im selben /24-Netzwerk stammt, ist IP Hash nicht sinnvoll, da dadurch alle Clients demselben Server zugeordnet werden. Verwenden Sie in diesem Fall (oder wenn Sie aus einem anderen Grund alle vier Oktette für den Hash heranziehen möchten) stattdessen die Hash-Methode mit der Variable $remote_addr.

hash $remote_addr;

Wenigste Verbindungen

Bei der Least-Connections-Methode vergleicht der Load Balancer die aktuelle Anzahl seiner aktiven Verbindungen zu den einzelnen Servern und leitet die Anfrage an den Server mit den wenigsten Verbindungen weiter. Die Konfiguration erfolgt mit der Direktive „least_conn“.

upstream backend {
    least_conn;

    server web1;
    server web2;
    server web3;
}

server {
    server_name www.example.com;

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

Kürzeste Antwortzeit

Bei der Least-Time-Methode (nur in NGINX Plus verfügbar) kombiniert der Load Balancer für jeden Server mathematisch zwei Messwerte – die aktuelle Anzahl aktiver Verbindungen und die gewichtete durchschnittliche Antwortzeit für frühere Anfragen – und leitet die Anfrage an den Server mit dem niedrigsten Wert weiter.

Mit der Wahl des Parameters für die Direktive „least_time“ legen Sie fest, welche von zwei Antwortzeiten erfasst wird: entweder die Zeit bis zum Empfang des Antwort-Headers (header) oder die Zeit bis zum Empfang der vollständigen Antwort (last_byte).

upstream backend {    least_time (header | last_byte);

    server web1;
    server web2;
    server web3;
}

server {
    server_name www.example.com;

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

Hinweise:

• Für den TCP- und UDP-Lastenausgleich (im stream-Kontext) können Sie mit diesen Parametern für die least_time-Direktive zwischen drei Arten von Antwortzeiten wählen:
  • connect – Zeit für den Verbindungsaufbau zum Upstream-Server
  • first_byte – Zeit bis zum Empfang des ersten Bytes der Antwortdaten
  • last_byte – Zeit bis zum Empfang des letzten Bytes der Antwortdaten
• Fügen Sie sowohl für HTTP- als auch für TCP/UDP-Datenverkehr in NGINX Plus R12 und höher den Parameter „inflight“ hinzu, um unvollständige Verbindungen in jede Metrik einzubeziehen; in früheren Versionen werden solche Verbindungen standardmäßig berücksichtigt.

Auswählen einer Lastverteilungsmethode

Woher wissen Sie also, welche der Lastverteilungstechniken für Ihre Website oder App am besten geeignet ist?

Die Datenverkehrsmuster unterscheiden sich von Website zu Website – und selbst innerhalb einer einzelnen Website je nach Tageszeit – so stark, dass es nicht sinnvoll ist, die Wahl der Lastverteilungstechnik von einem einzigen Merkmal abhängig zu machen (etwa stoßartiger gegenüber gleichmäßigem Datenverkehr, kurzlebigen gegenüber langlebigen Verbindungen usw.). Dennoch betrachten wir die Vor- und Nachteile der einzelnen Methoden, um Ihnen dabei zu helfen, die infrage kommenden Optionen einzugrenzen.

Tests zum Vergleich der Methoden durchführen

Unabhängig davon, welche Auswahl an Lastverteilungsverfahren Sie in Betracht ziehen, empfehlen wir Ihnen, diese zu testen, um herauszufinden, welches sich für Ihren Datenverkehr am besten eignet. „Am besten“ bedeutet in der Regel, dass Antworten möglichst schnell an Clients übermittelt werden. Möglicherweise gelten für Sie jedoch andere Kriterien.

Application Performance Management-Tools sind für diese Art von Tests sehr praktisch. Sie können benutzerdefinierte Ansichten mit Diagrammen für jeden Server in der Upstream-Gruppe erstellen und diese so in Echtzeit vergleichen, während sich die Werte im Laufe des Tests ändern. Mehrere APM-Lösungen bieten benutzerdefinierte Plug-ins für NGINX Plus und NGINX an, darunter AppDynamics, Datadog, Dynatrace und New Relic.

Das Testen ist am einfachsten, wenn alle Server über die gleiche Kapazität verfügen. Andernfalls müssen Sie Servergewichtungen festlegen, damit leistungsfähigere Rechner mehr Anfragen erhalten. Weitere Informationen finden Sie weiter unten unter „Festlegen von Gewichtungen bei unterschiedlichen Servern“.

Einige Kennzahlen, die während des Tests überprüft werden sollten, sind:

• CPU- und Arbeitsspeicherauslastung – Prüfen Sie sowohl für die CPU als auch für den Arbeitsspeicher, wie viel Prozent der Gesamtkapazität genutzt werden. Wenn nicht alle Server gleichmäßig ausgelastet sind, wird der Datenverkehr nicht effizient verteilt.
• Serverantwortzeit – Wenn die Antwortzeit bei einigen Servern durchgehend höher ist als bei anderen, werden ihnen offenbar „aufwendigere“ Anfragen (die mehr Rechenleistung oder Zugriffe auf eine Datenbank oder andere Dienste erfordern) auf unausgewogene Weise zugewiesen. Versuchen Sie, die Gewichtungen anzupassen, da das Ungleichgewicht möglicherweise durch falsche Gewichtungen und nicht durch ein Problem mit dem Lastverteilungsverfahren verursacht wird.
• Gesamtzeit für die Antwort an den Client – Auch hier deuten dauerhaft längere Antwortzeiten bei einigen Servern darauf hin, dass sie einen unverhältnismäßig hohen Anteil zeitaufwendiger Anfragen erhalten. Auch in diesem Fall können Sie versuchen, die Gewichtungen anzupassen, um zu prüfen, ob sich das Problem dadurch beheben lässt.
• Fehler und fehlgeschlagene Anfragen – Sie müssen sicherstellen, dass die Anzahl der fehlgeschlagenen Anfragen und sonstigen Fehler während der Tests nicht höher ist als für Ihre Website üblich. Andernfalls stützen Sie Ihre Entscheidung auf Fehlerbedingungen statt auf realistischen Datenverkehr. Bei manchen Fehlern kann der Server seine Antwort schneller senden als bei einer erfolgreichen Anfrage. Beim HTTP-Antwortcode 404 (Datei nicht gefunden) beispielsweise gibt der Server die Fehlermeldung wahrscheinlich wesentlich schneller zurück, als er die eigentliche Datei bereitstellen könnte, wenn sie vorhanden wäre. Bei den Load-Balancing-Algorithmen „Least Connections“ und „Least Time“ kann dies dazu führen, dass der Load Balancer einen Server bevorzugt, der tatsächlich nicht ordnungsgemäß funktioniert.

Vor- und Nachteile sowie Anwendungsfälle

Sehen wir uns nun die Vor- und Nachteile der einzelnen Lastverteilungsverfahren an und beschreiben einige Anwendungsfälle, für die sie sich besonders gut eignen. Wir behandeln sie in der Reihenfolge ihrer zunehmenden Eignung für die meisten Anwendungsfälle. Vorab ein kurzer Ausblick: Least Connections (und bei NGINX Plus Least Time) sind unserer Ansicht nach für das breiteste Spektrum an Anwendungsfällen die beste Wahl.

Hash und IP-Hash

Die Lastverteilungsmethoden Hash und IP-Hash stellen eine feste Zuordnung zwischen einer bestimmten Art von Clientanfrage (die im Hashwert erfasst wird) und einem bestimmten Server her. Dies wird auch als Sitzungspersistenz bezeichnet: Alle Anfragen mit einem bestimmten Hashwert werden stets an denselben Server weitergeleitet.

Der größte Nachteil dieser Methoden besteht darin, dass sie weder eine gleichmäßige Verteilung der Anfragen auf die Server noch eine gleichmäßige Lastverteilung gewährleisten. Der Hashing-Algorithmus teilt die Menge aller möglichen Hashwerte gleichmäßig in „Buckets“ auf, einen für jeden Server in der Upstream-Gruppe. Es lässt sich jedoch nicht vorhersagen, ob die Hashwerte der tatsächlich eingehenden Anfragen gleichmäßig verteilt sein werden. Angenommen, zehn Clients greifen auf eine Website zu und der IP-Hash-Algorithmus ordnet die Hashwerte von sieben IP-Adressen zufällig web1, den Hashwert einer IP-Adresse web2 und die Hashwerte von zwei IP-Adressen web3 zu. Der Server web1 erhält dadurch mehr als doppelt so viele Anfragen wie die anderen Server zusammen.

Daher ist es sinnvoll, Hash oder IP Hash zu verwenden, wenn der Vorteil der Aufrechterhaltung von Sitzungen die möglichen negativen Auswirkungen einer ungleichmäßigen Lastverteilung überwiegt. Dies sind die einzigen in NGINX verfügbaren Formen der Sitzungspersistenz. NGINX Plus bietet drei weitere Sitzungspersistenzmechanismen, die ausgefeilter sind und mit einer tatsächlichen Lastverteilung kombiniert werden können (sie werden mit der Direktive sticky konfiguriert). Aber auch bei NGINX Plus können Sie sich für Hash oder IP Hash entscheiden, da die drei Mechanismen in den folgenden Fällen nicht funktionieren:

• Der Browser oder die Client-App akzeptiert keine Cookies, und die Anwendung bietet keine Möglichkeit, die Mechanismen zur Sitzungspersistenz ohne Cookies zu verwenden. Verwenden Sie die IP-Hash-Methode, um jeden Client (genauer gesagt seine IP-Adresse) einem bestimmten Server zuzuordnen.
• Sie möchten Anfragen für eine bestimmte URL immer an denselben Server senden, um die Zwischenspeicherung auf dem Server selbst zu nutzen. Verwenden Sie die Hash-Methode mit der Variable $request_uri, um die Datei jedes Mal vom selben Server abzurufen. Angenommen, Sie wissen beispielsweise, dass die Bereitstellung einer bestimmten .php-Datei mehrere zeitaufwendige Datenbankaufrufe erfordert, die abgerufenen Daten sich jedoch nur selten ändern und daher zwischengespeichert werden können. Wenn Sie alle Anfragen für die Datei an denselben Server weiterleiten, kommt es nur beim ersten Client aufgrund der Datenbankaufrufe zu einer langen Verzögerung. Für alle nachfolgenden Clients werden die Daten schnell aus dem Cache abgerufen. Ein weiterer Vorteil besteht darin, dass nur dieser eine Server den betreffenden Datensatz zwischenspeichern muss. Da dieselben Daten nicht auf jedem Server redundant zwischengespeichert werden, können Sie kleinere Caches verwenden.

Es gibt einige Fälle, in denen IP Hash – und Hash, wenn die Client-IP-Adresse Teil des Schlüssels ist – nicht funktionieren:

• Wenn sich die IP-Adresse des Clients während der Sitzung ändern kann, beispielsweise wenn ein Mobilgerät von einem WLAN zu einem Mobilfunknetz wechselt.
• Wenn die Anfragen einer großen Anzahl von Clients über einen Forward-Proxy geleitet werden, da für alle dieselbe IP-Adresse des Proxys verwendet wird.

Hashes sind deterministisch (der Hash-Algorithmus liefert jedes Mal dieselben Ergebnisse). Dies hat einige positive Nebeneffekte: Alle NGINX Plus- oder NGINX-Instanzen in einer Bereitstellung verteilen Anfragen auf genau dieselbe Weise, und die Zuordnung von Hashes zu Servern bleibt auch nach Neustarts des Load Balancers bestehen. (Sie wird nach dem Neustart zwar neu berechnet, da das Ergebnis jedoch immer dasselbe ist, bleibt sie faktisch bestehen.)

Andererseits erzwingt eine Änderung der Gruppe von Upstream-Servern in der Regel die Neuberechnung zumindest einiger Zuordnungen, wodurch die Sitzungspersistenz unterbrochen wird. Sie können die Anzahl der neu berechneten Zuordnungen etwas reduzieren:

• Fügen Sie bei der Hash-Methode den Parameter „consistent“ zur Direktive „hash“ hinzu. NGINX Plus verwendet den Hash-Algorithmus „ketama“, wodurch weniger Neuzuordnungen erforderlich sind.
• Fügen Sie bei der IP-Hash-Methode vor dem vorübergehenden Entfernen eines Servers aus der Upstream-Gruppe den Parameter „down“ zu dessen „server“-Direktive hinzu, wie bei „web2“ im folgenden Beispiel. Die Zuordnungen werden nicht neu berechnet, da davon ausgegangen wird, dass der Server bald wieder verfügbar sein wird.

upstream backend {    ip_hash;

    server web1;
    server web2 down;
    server web3;
}

Round-Robin

Wie bereits erwähnt, ist Round Robin die standardmäßige Methode zur Lastverteilung in NGINX Plus und NGINX. Damit ist sie zweifellos am einfachsten auszuwählen – Sie müssen außer der Upstream-Gruppe selbst nichts weiter konfigurieren.

Allgemein herrscht Einigkeit darüber, dass Round Robin am besten funktioniert, wenn die Eigenschaften der Server und Anfragen voraussichtlich nicht dazu führen, dass einige Server im Vergleich zu anderen überlastet werden. Zu den Voraussetzungen gehören:

• Alle Server verfügen über ungefähr die gleiche Kapazität. Diese Anforderung ist weniger wichtig, wenn Unterschiede zwischen den Servern durch Servergewichtungen präzise abgebildet werden.
• Alle Server hosten dieselben Inhalte.
• Die Anfragen sind hinsichtlich der benötigten Zeit oder Rechenleistung weitgehend vergleichbar. Wenn sich der Ressourcenbedarf der Anfragen stark unterscheidet, kann ein Server überlastet werden, weil der Load Balancer ihm zufällig viele ressourcenintensive Anfragen kurz hintereinander zuweist.
• Das Datenverkehrsaufkommen ist nicht hoch genug, um die Server häufig an ihre Kapazitätsgrenze zu bringen. Wenn die Server bereits stark ausgelastet sind, ist es wahrscheinlicher, dass die schematische Verteilung der Anfragen durch Round Robin einige Server über ihre Belastungsgrenze hinaus in eine Überlastung treibt, wie im vorherigen Aufzählungspunkt beschrieben.

Round Robin eignet sich besonders für Testszenarien, da dieses Verfahren sicherstellt, dass die Anfragen auf alle Server und in gleicher Anzahl (bzw. entsprechend der jeweiligen Gewichtung) verteilt werden. Einige andere Methoden verteilen den Datenverkehr bei geringem Volumen nicht immer gleichmäßig, was die Testergebnisse verfälschen kann.

Die gleichmäßige Verteilung kann auch Aufschluss darüber geben, ob die Caches ordnungsgemäß und mit voller Kapazität arbeiten: Da es bei Round Robin nicht möglich ist, Anfragen für eine bestimmte Datei immer an denselben Server zu senden, wird wahrscheinlich jeder Server eine Vielzahl von Dateien ausliefern und zwischenspeichern (und in der Regel viele der gleichen Dateien wie die anderen Server), wodurch sich der Cache eher füllt.

Schließlich hilft die gleichmäßige anfängliche Verteilung dabei, Probleme mit der Sitzungspersistenz in NGINX Plus aufzudecken (wie mit der sticky-Direktive konfiguriert).

Wenigste Verbindungen und kürzeste Zeit

Wie bereits erwähnt, ist „Least Connections“ für das breiteste Spektrum an Anwendungsfällen und insbesondere für den Produktivdatenverkehr das am besten geeignete Lastverteilungsverfahren. Dies wird durch Erfahrungsberichte unserer Kunden bestätigt. Die Leistung ist stabil und vorhersehbar.

Least Connections verteilt die Arbeitslast außerdem effektiv entsprechend der Kapazität auf die Server. Ein leistungsfähigerer Server bearbeitet Anfragen schneller. Daher hat er zu einem beliebigen Zeitpunkt wahrscheinlich weniger Verbindungen, die noch verarbeitet werden (oder sogar noch auf den Beginn der Verarbeitung warten), als ein Server mit geringerer Kapazität. Least Connections leitet jede Anfrage an den Server mit den wenigsten aktuellen Verbindungen weiter und sendet Anfragen daher mit höherer Wahrscheinlichkeit an leistungsfähige Server. (Durch das Festlegen von Gewichtungen lässt sich die Verteilung der Anfragen jedoch noch effizienter gestalten, wie weiter unten unter „Festlegen von Gewichtungen bei unterschiedlichen Servern“ beschrieben.)

Least Time (nur NGINX Plus) kann als empfindlichere Variante von Least Connections betrachtet werden. Durch die Einbeziehung der durchschnittlichen Antwortzeit berücksichtigt das Verfahren den jüngsten Leistungsverlauf des Servers (genau genommen handelt es sich um einen exponentiell gewichteten gleitenden Durchschnitt, sodass ältere Antwortzeiten den Durchschnitt weniger stark beeinflussen als neuere).

Least Time eignet sich besonders, wenn die Upstream-Server sehr unterschiedliche durchschnittliche Antwortzeiten aufweisen. Wenn Sie beispielsweise zur Notfallwiederherstellung Server in verschiedenen Rechenzentren betreiben, sendet Least Time tendenziell mehr Anfragen an die lokalen Server, da diese schneller antworten. Ein weiterer Anwendungsfall sind Cloud-Umgebungen, in denen die Serverleistung häufig nur schwer vorhersehbar ist.

Gewichtungen festlegen, wenn Server nicht identisch sind

Wir haben bereits mehrfach darauf hingewiesen, wie wichtig es ist, Servergewichtungen festzulegen, wenn die Server in der Upstream-Gruppe unterschiedliche Kapazitäten haben. Dies ist besonders beim Round-Robin-Load-Balancer wichtig, da dieser andernfalls dieselbe Anzahl von Anfragen an jeden Server sendet. Dadurch wird wahrscheinlich ein weniger leistungsfähiger Server überlastet, während ein leistungsfähigerer Server teilweise ungenutzt bleibt.

Um Gewichtungen festzulegen, fügen Sie den Parameter „weight“ zu einer oder mehreren „server“-Direktiven im „upstream“-Block hinzu. Der Standardwert ist 1.

Die Auswirkungen der Gewichtung auf die verschiedenen Load-Balancing-Verfahren lassen sich folgendermaßen veranschaulichen. Beachten Sie, dass die Beschreibungen zwar konzeptionell korrekt sind, die Implementierung im NGINX Plus-Code jedoch nicht unbedingt die angegebenen mathematischen Operationen verwendet. Hier ist die Upstream-Gruppe für unsere Beispiele:

upstream backend {    server web1 weight=6;
    server web2 weight=3;
    server web3;
}

• Round Robin – Jeder Server erhält einen Anteil der eingehenden Anfragen, der seinem Gewicht geteilt durch die Summe aller Gewichte entspricht. In unserem Beispiel erhält web1 von jeweils zehn Anfragen sechs (60 %), web2 drei (30 %) und web3 eine (10 %).
• Hash und IP-Hash – Ohne Gewichtungen teilt der Hashing-Algorithmus die Menge aller möglichen Hashwerte gleichmäßig in „Buckets“ auf, einen für jeden Server in der Upstream-Gruppe. Bei Verwendung von Gewichtungen summiert er stattdessen die Gewichtungen, teilt die Menge der möglichen Hashwerte auf diese Anzahl von Buckets auf und ordnet jedem Server so viele Buckets zu, wie es seiner Gewichtung entspricht. In unserem Beispiel gibt es zehn Buckets, die jeweils 10 % der möglichen Hashwerte enthalten. Sechs Buckets (60 % der möglichen Hashwerte) sind web1, drei Buckets (30 %) web2 und ein Bucket (10 %) web3 zugeordnet.
• Wenigste Verbindungen und Kürzeste Zeit – Wir haben bereits erwähnt, dass diese Algorithmen auch ohne Gewichtungen die Arbeitslast recht effektiv entsprechend der Kapazität auf die Server verteilen. Durch das Festlegen von Gewichtungen lässt sich ihre Leistung in dieser Hinsicht noch weiter verbessern. Zur Erinnerung: „Wenigste Verbindungen“ und „Kürzeste Zeit“ leiten jede Anfrage an den Server mit dem niedrigsten „Wert“ weiter (jeweils die Anzahl der Verbindungen beziehungsweise eine mathematische Kombination aus Verbindungen und Zeit). Wenn Sie Gewichtungen zuweisen, teilt der Load Balancer den Wert jedes Servers durch dessen Gewichtung und leitet die Anfrage wiederum an den Server mit dem niedrigsten Wert weiter. Hier ein Beispiel für „Wenigste Verbindungen“ mit unseren Beispielgewichtungen und der angegebenen Anzahl aktiver Verbindungen: Der Wert von web1 ist mit 100 am niedrigsten, sodass dieser Server die Anfrage erhält, obwohl seine Verbindungsanzahl von 600 dem 1,5-Fachen der von web2 und mehr als dem Vierfachen der von web3 entspricht.
  • web1 – 600 aktive Verbindungen ÷ 6 = 100
  • web2 – 400 aktive Verbindungen ÷ 3 = 133
  • web3 – 125 aktive Verbindungen ÷ 1 = 125

Zusammenfassung

Nach Abwägung der Vor- und Nachteile der in NGINX Plus und NGINX verfügbaren Lastverteilungstechniken halten wir Least Connections (und bei NGINX Plus Least Time) für die größte Bandbreite an Anwendungsfällen für am besten geeignet. Es ist jedoch wichtig, dass Sie in Ihrer Bereitstellung mehrere Methoden testen, da aufgrund der spezifischen Kombination aus Datenverkehr und Servereigenschaften möglicherweise eine andere Methode besser geeignet ist.

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

Wir würden gerne von Ihren Erfahrungen mit Load Balancing in verschiedenen Anwendungsfällen hören. Teilen Sie sie uns bitte unten im Kommentarbereich mit.

Über den Autor

Tony Mauro

Weitere Blogbeiträge von Tony Mauro