Auswählen einer NGINX Plus-Lastausgleichstechnik

Wir haben viel darüber geschrieben, wie Sie mit NGINX Plus und NGINX Open Source die Last Ihrer Websites und Apps ausgleichen können, um optimale Verfügbarkeit und Zuverlässigkeit zu erzielen. Der Lastenausgleich ist ein grundlegendes Tool zur Steigerung der App-Leistung , zur Bereitstellung von Apps im großen Maßstab und zum Einsatz von Containern und Microservices .

Wir haben bereits erklärt, wie Sie NGINX Plus im Rechenzentrum (möglicherweise neben älteren Anwendungsbereitstellungscontrollern), in Containern und in Cloud-Umgebungen, einschließlich Amazon Web Services (AWS), der Google Cloud Platform und Microsoft Azure , bereitstellen können.

In diesem Beitrag konzentrieren wir uns auf die Lastausgleichstechniken (auch Lastausgleichsmethoden oder -algorithmen genannt) in NGINX Plus und NGINX und geben einige Ratschläge zur Auswahl der richtigen Methode für verschiedene Anwendungsfälle. NGINX bietet vier Lastausgleichstechniken ( Round Robin , Hash , IP Hash und Least Connections ) und NGINX Plus fügt eine weitere hinzu ( Least Time ). Alle Methoden für HTTP-Verkehr sind auch für TCP (und UDP in NGINX Plus Release 9 und höher) verfügbar, mit Ausnahme von IP Hash.

[ Herausgeber – NGINX Plus R16 und NGINX Open Source 1.15.1 führten Random with Two Choices als zusätzlichen Lastausgleichsalgorithmus ein. Eine Erläuterung hierzu finden Sie in unserem Blog unter „NGINX und der Lastausgleichsalgorithmus „Power of Two Choices“ .]

Überprüfung der Lastausgleichstechniken

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

• Artikel im NGINX Plus Admin Guide bieten einen vollständigen Überblick.
• Hochleistungs-Lastausgleich enthält Links zu detaillierten Diskussionen der erweiterten Funktionen in NGINX Plus, mit denen die Effizienz einer Lastausgleichsmethode noch weiter verbessert werden kann.
• Lastausgleich mit NGINX und NGINX Plus , Teil 1 und Teil 2 ist eine schrittweise Anleitung, die einen einfachen Reverse-Proxy in eine umfassende Lastausgleichslösung mit den erweiterten Funktionen von NGINX Plus einbaut.
• Die Seite „Load Balancing Solutions“ enthält Links zu anderen Ressourcen, darunter E-Books, Webinare und Whitepaper.

Der Einfachheit halber konzentrieren wir uns auf den HTTP-Lastausgleich, den Sie im HTTP- Kontext konfigurieren. Der TCP-Lastausgleich wird stattdessen im Streamkontext konfiguriert (wie auch der UDP-Lastausgleich in NGINX Plus Release 9 und höher). Obwohl die HTTP- und TCP/UDP-Load Balancer über Funktionsparität verfügen, unterscheiden sich die verfügbaren Anweisungen und Parameter aufgrund inhärenter Unterschiede zwischen den Protokollen etwas. Weitere Informationen finden Sie in der Dokumentation zu den Upstream-Modulen für HTTP und TCP/UDP .

Sie aktivieren das Lastenausgleichssystem mit zwei Konfigurationsblöcken, die wir in ihrer Grundform ohne optionale Parameter oder Zusatzfunktionen zeigen:

• Der Serverblock definiert einen virtuellen Server, der auf Datenverkehr mit den von Ihnen definierten Merkmalen wartet und ihn an eine benannte Gruppe von Upstream-Servern weiterleitet. In unseren Beispielen überwacht der virtuelle Server den an www.example.com gesendeten HTTP-Verkehr auf dem Standardport (80) und leitet ihn per Proxy an die Upstream-Servergruppe mit dem Namen „backend“ weiter . Dieser Block ist in allen unseren Beispielen derselbe.

  Server { Servername www.example.com;
  
  Standort / {
  Proxy-Passwort http://backend;
  }
  }

  (NGINX Plus und NGINX können auch die Last von FastCGI-, Memcached-, SCGI- und uwsgi-Backend-Servern ausgleichen. Ersetzen Sie proxy_pass durch die entsprechende Anweisung – fastcgi_pass , memcached_pass , scgi_pass oder uwsgi_pass .)

• Der Upstream- Block benennt eine Upstream-Gruppe und listet die zugehörigen Server auf, identifiziert durch Hostnamen, IP-Adresse oder UNIX-Domänen-Socket-Pfad. In unseren Beispielen umfasst die Upstream-Gruppe mit dem Namen „Backend“ drei Server: web1 , web2 und web3 .

  Im Upstreamblock geben Sie die Lastausgleichstechnik an. Deshalb werden wir diesen in den folgenden Abschnitten hervorheben. Als Beispiel ist hier der Block für die Standardmethode Round Robin:

  Upstream-Backend { Server Web1;
  Server Web2;
  Server Web3;
  }

Rundenturnier

Round Robin ist die Standardtechnik zum Lastenausgleich sowohl für NGINX Plus als auch für NGINX. Der Lastenausgleich durchläuft die Liste der Upstream-Server der Reihe nach und weist jedem Server nacheinander die nächste Verbindungsanforderung zu.

Bei der folgenden Beispielkonfiguration der Back-End- Upstream-Gruppe sendet der Load Balancer die ersten drei Verbindungsanforderungen der Reihe nach an web1 , web2 und web3 , die vierte an web1 , die fünfte an web2 und so weiter.

Upstream-Backend { Server Web1;
Server Web2;
Server Web3;
}

Server {
Servername www.example.com;

Standort / {
Proxy-Passwort http://backend;
}
}

Hash

Mit der Hash-Methode berechnet der Load Balancer für jede Anforderung einen Hash, der auf der von Ihnen angegebenen Kombination aus Text und NGINX-Variablen basiert, und ordnet den Hash einem der Server zu. Es sendet alle Anfragen mit diesem Hash an diesen Server, sodass diese Methode eine grundlegende Art der Sitzungspersistenz herstellt.

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

Upstream-Backend { Hash $scheme$request_uri; Server Web1; Server Web2; Server Web3; } Server { Servername www.example.com; Standort / { Proxy-Passwort 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 legen es mit der Direktive ip_hash fest.

Upstream-Backend { IP-Hash ; Server Web1; Server Web2; Server Web3; } Server { Servername www.example.com; Standort / { Proxy-Passwort http://backend; } }

Wenn der Client über eine IPv6-Adresse verfügt, basiert der Hash auf der gesamten Adresse. Wenn es sich um eine IPv4-Adresse handelt, basiert der Hash nur auf den ersten drei Oktetten der Adresse. Dies dient der Optimierung für ISP-Clients, denen IP-Adressen dynamisch aus einem Subnetzbereich (/24) zugewiesen werden. Bei einem Neustart oder einer erneuten Verbindung ändert sich die Adresse des Clients häufig zu einer anderen im /24-Netzwerkbereich, die Verbindung stellt jedoch immer noch denselben Client dar, sodass es keinen Grund gibt, die Zuordnung zum Server zu ändern.

Wenn jedoch der Großteil des Datenverkehrs zu Ihrer Site von Clients im selben /24-Netzwerk stammt, ist IP-Hash nicht sinnvoll, da es alle Clients demselben Server zuordnet. Verwenden Sie in diesem Fall (oder wenn Sie aus einem anderen Grund alle vier Oktette hashen möchten) stattdessen die Hash-Methode mit der Variablen $remote_addr .

Hashwert für $remote_addr;

Wenigste Verbindungen

Bei der Methode „Least Connections“ vergleicht der Load Balancer die aktuelle Anzahl seiner aktiven Verbindungen zu den einzelnen Servern und sendet die Anfrage an den Server mit den wenigsten Verbindungen. Sie konfigurieren es mit der least_conn -Direktive.

Upstream-Backend { least_conn ; Server web1; Server web2; Server web3; } Server { Servername www.example.com; Standort / { Proxy-Passwort http://backend; } }

Mindestzeit

Mit 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 eine gewichtete durchschnittliche Antwortzeit für vergangene Anfragen – und sendet die Anfrage an den Server mit dem niedrigsten Wert.

Ihre Parameterauswahl in der least_time -Direktive steuert, welche von zwei Antwortzeiten verfolgt wird: entweder die Zeit zum Empfangen des Antwortheaders ( header ) oder die Zeit zum Empfangen der vollständigen Antwort ( last_byte ).

Upstream-Backend { least_time (Header | letztes Byte) ; Server Web1; Server Web2; Server Web3; } Server { Servername www.example.com; Standort / { Proxy-Passwort http://backend; } }

Hinweise:

• Für den TCP- und UDP-Lastausgleich (im Stream -Kontext) können Sie mit diesen Parametern für die least_time -Direktive aus drei Antwortzeittypen wählen:

  • connect – Zeit zum Verbinden mit dem 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 in NGINX Plus R12 und höher für HTTP- und TCP/UDP-Datenverkehr den Inflight- Parameter hinzu, um unvollständige Verbindungen in jede Metrik einzubeziehen. In früheren Versionen sind solche Verbindungen standardmäßig enthalten.

Auswählen einer Lastenausgleichstechnik

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

Die Verkehrsmuster unterscheiden sich von Standort zu Standort – und sogar innerhalb eines Standorts zu verschiedenen Tageszeiten – so stark, dass es keinen Sinn ergibt, die Wahl der Lastausgleichstechnik auf ein einziges Merkmal zu stützen (wie etwa stoßweiser vs. gleichmäßiger Verkehr, kurzlebige vs. langlebige Verbindungen usw.). Dennoch werden wir die Vor- und Nachteile jeder Methode betrachten, um Ihnen dabei zu helfen, die Auswahl einzugrenzen.

Ausführen von Tests zum Vergleichen von Methoden

Egal, für welche Teilmenge der Lastausgleichsmethoden Sie sich entscheiden, wir empfehlen Ihnen, sie zu testen, um herauszufinden, welche für Ihren Datenverkehr am besten geeignet ist. „Am besten“ bedeutet normalerweise die kürzeste Zeit, in der den Kunden Antworten übermittelt werden, aber Sie können auch andere Kriterien haben.

Tools zur Anwendungsleistungsverwaltung sind für diese Art von Tests sehr praktisch. Sie können benutzerdefinierte Bildschirme mit Diagrammen für jeden der Server in der Upstream-Gruppe erstellen, sodass Sie diese in Echtzeit vergleichen können, wenn sich die Werte während des Tests ändern. Mehrere APMs bieten benutzerdefinierte Plug-Ins für NGINX Plus und NGINX, darunter AppDynamics , Datadog , Dynatrace und New Relic .

Das Testen ist am einfachsten, wenn alle Server über die gleiche Kapazität verfügen. Wenn nicht, müssen Sie Servergewichte festlegen, damit Maschinen mit mehr Kapazität mehr Anfragen erhalten. Weitere Informationen finden Sie weiter unten unter „Festlegen von Gewichten, wenn die Server nicht identisch sind“ .

Einige während des Tests zu überprüfende Kennzahlen sind:

• CPU- und Speicherauslastung – Sehen Sie sich den Prozentsatz der genutzten Gesamtkapazität sowohl für CPU als auch für Speicher an. Wenn nicht alle Server gleichmäßig ausgelastet sind, wird der Datenverkehr nicht effizient verteilt.
• Serverantwortzeit – Wenn die Zeit bei manchen Servern durchgängig höher ist als bei anderen, werden „schwerere“ Anfragen (die mehr Berechnungen oder Aufrufe einer Datenbank oder anderer Dienste erfordern) auf unausgewogene Weise an sie weitergeleitet. Versuchen Sie, die Gewichte anzupassen, da das Ungleichgewicht eher durch falsche Gewichte als durch ein Problem mit der Lastausgleichstechnik verursacht werden könnte.
• Gesamtzeit bis zur Antwort an den Client – Auch hier deuten durchweg höhere Zeiten bei manchen Servern darauf hin, dass sie einen überproportional hohen Anteil zeitaufwändiger Anfragen erhalten. Und nochmals: Sie können versuchen, die Gewichte anzupassen, um zu sehen, ob das Problem dadurch behoben wird.
• Fehler und fehlgeschlagene Anfragen – Sie müssen sicherstellen, dass die Anzahl fehlgeschlagener Anfragen und anderer Fehler während der Tests nicht größer ist als für Ihre Site üblich. Andernfalls stützen Sie Ihre Entscheidung auf Fehlerbedingungen statt auf realistischen Datenverkehr. Bei manchen Fehlern kann der Server seine Antwort schneller senden, als wenn die Anfrage erfolgreich war. Für den HTTP-Antwortcode 404( Datei nicht gefunden ) gibt der Server den Fehler beispielsweise wahrscheinlich viel schneller zurück, als er die eigentliche Datei ausliefern könnte, wenn sie vorhanden wäre. Bei den Lastausgleichsalgorithmen „Least Connections“ und „Least Time“ kann dies dazu führen, dass der Load Balancer einen Server bevorzugt, der tatsächlich nicht gut funktioniert.

Vor- und Nachteile sowie Anwendungsfälle

Sehen wir uns nun die Vor- und Nachteile der einzelnen Lastausgleichstechniken an und beschreiben einige Anwendungsfälle, für die sie besonders geeignet sind. Wir besprechen sie in der Reihenfolge zunehmender Eignung für die meisten Anwendungsfälle. Eine kurze Vorschau: Wir sind der Ansicht, dass Least Connections (und für NGINX Plus Least Time) für die größte Bandbreite an Anwendungsfällen die beste Wahl ist.

Hash und IP-Hash

Die Lastausgleichstechniken Hash und IP Hash erstellen eine feste Verbindung zwischen einem bestimmten Typ von Clientanforderung (erfasst im Hashwert) und einem bestimmten Server. Sie erkennen dies möglicherweise an der Sitzungspersistenz – alle Anfragen mit einem bestimmten Hash-Wert gehen immer an denselben Server.

Der größte Nachteil dieser Methoden besteht darin, dass keine gleichmäßige Verteilung der Anfragen auf die Server gewährleistet ist und schon gar keine gleichmäßige Lastverteilung gewährleistet ist. 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 gibt jedoch keine Möglichkeit vorherzusagen, ob die Hashes der tatsächlich auftretenden Anfragen gleichmäßig verteilt sein werden. Angenommen, zehn Clients greifen auf eine Site zu und der IP-Hash-Algorithmus verknüpft den Hash für sieben der IP-Adressen mit web1 , eine mit web2 und zwei mit web3 . Der Web1 -Server erhält letztendlich mehr als doppelt so viele Anfragen wie die anderen Server zusammen.

Daher ist die Verwendung von Hash oder IP-Hash sinnvoll, wenn der Nutzen der Aufrechterhaltung von Sitzungen die möglicherweise negativen Auswirkungen einer unausgeglichenen Last überwiegt. Sie sind die einzige Form der Sitzungspersistenz, die in NGINX verfügbar ist. NGINX Plus bietet drei weitere Sitzungspersistenzmechanismen , die ausgefeilter sind und in Kombination mit tatsächlichem Lastausgleich funktionieren (Sie konfigurieren sie mit der Sticky -Direktive). Sie können jedoch auch bei NGINX Plus Hash oder IP Hash wählen, da die drei Mechanismen in den folgenden Fällen nicht funktionieren:

• Der Browser oder die Client-App akzeptiert keine Cookies und die Anwendung hat keine Möglichkeit, ohne Cookies mit den Sitzungspersistenzmechanismen zu arbeiten. Verwenden Sie die IP-Hash-Methode, um jeden Client (insbesondere seine IP-Adresse) einem bestimmten Server zuzuordnen.

• Sie möchten Anfragen für eine bestimmte URL jedes Mal an denselben Server senden, um die Vorteile der 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, dass zum Bereitstellen einer bestimmten PHP- Datei mehrere zeitaufwändige Datenbankaufrufe erforderlich sind, die abgerufenen Daten sich jedoch nicht oft ändern und deshalb zwischengespeichert werden können. Wenn Sie alle Anfragen für die Datei an denselben Server richten, kommt es nur beim ersten Client aufgrund der Datenbankaufrufe zu einer längeren Verzögerung. Für alle nachfolgenden Clients werden die Daten schnell aus dem Cache abgerufen. Ein weiterer Vorteil besteht darin, dass nur ein Server diesen bestimmten Datensatz zwischenspeichern muss. Da Sie nicht auf allen Servern dieselben Daten doppelt zwischenspeichern, können Sie kleinere Caches verwenden.

In einigen Fällen funktionieren IP-Hashes – und Hashes, wenn die Client-IP-Adresse im Schlüssel enthalten ist – nicht:

• Wenn sich die IP-Adresse des Clients während der Sitzung ändern kann, beispielsweise wenn ein mobiler Client von einem WLAN-Netzwerk zu einem Mobilfunknetzwerk wechselt.
• Wenn die Anfragen einer großen Anzahl von Clients über einen Forward-Proxy laufen, weil für alle die IP-Adresse des Proxys verwendet wird.

Hashes sind deterministisch (der Hashing-Algorithmus liefert jedes Mal die gleichen Ergebnisse). Dies hat einige positive Nebeneffekte: Alle NGINX Plus- oder NGINX-Instanzen in einer Bereitstellung führen den Lastenausgleich für Anforderungen auf genau dieselbe Weise durch und die Hash-zu-Server-Zuordnung bleibt auch nach Neustarts des Lastenausgleichs bestehen. (Tatsächlich wird es nach dem Neustart neu berechnet, aber da das Ergebnis immer dasselbe ist, bleibt es effektiv bestehen.)

Andererseits führt eine Änderung der Upstream-Server-Gruppe normalerweise dazu, dass zumindest einige der Zuordnungen neu berechnet werden müssen, wodurch die Sitzungspersistenz unterbrochen wird. Sie können die Anzahl der neu berechneten Zuordnungen etwas reduzieren:

• Fügen Sie für die Hash-Methode den konsistenten Parameter in die Hash- Direktive ein. NGINX Plus verwendet den Ketama- Hashing-Algorithmus, wodurch weniger Neuzuordnungen erforderlich sind.

• Fügen Sie für die IP-Hash-Methode vor dem vorübergehenden Entfernen eines Servers aus der Upstream-Gruppe den Down- Parameter zu seiner Serverdirektive hinzu, wie für web2 im folgenden Beispiel. Die Zuordnungen werden nicht neu berechnet, da davon ausgegangen wird, dass der Server bald wieder betriebsbereit ist.

  Upstream-Backend { IP_Hash; Server Web1; Server Web2 ausgefallen ; Server Web3; }

Rundenturnier

Wie bereits erwähnt, ist Round Robin die Standardmethode zum Lastenausgleich in NGINX Plus und NGINX. Dies macht es sicherlich zur einfachsten Methode – Sie müssen außer der Upstream-Gruppe selbst nichts konfigurieren.

Es besteht allgemeine Übereinstimmung darüber, dass Round-Robin am besten funktioniert, wenn die Eigenschaften der Server und Anfragen wahrscheinlich nicht dazu führen, dass einige Server im Vergleich zu anderen überlastet werden. Einige der Bedingungen sind:

• Alle Server haben etwa die gleiche Kapazität. Diese Anforderung ist weniger wichtig, wenn Unterschiede zwischen Servern durch Servergewichte genau dargestellt werden.
• Alle Server hosten denselben Inhalt.
• Hinsichtlich der benötigten Zeit und Verarbeitungsleistung sind die Anfragen recht ähnlich. Bei großen Schwankungen im Anforderungsgewicht kann es zu einer Überlastung des Servers kommen, da der Load Balancer ihm zufällig viele schwergewichtige Anforderungen in schneller Folge sendet.
• Das Verkehrsaufkommen ist nicht hoch genug, um die Server häufig an ihre nahezu volle Kapazität zu bringen. Wenn die Server bereits stark ausgelastet sind, besteht eine größere Wahrscheinlichkeit, dass die automatische Verteilung der Anfragen durch Round-Robin einige Server „über die Kante“ treibt und sie überlastet, wie im vorherigen Punkt beschrieben.

Round Robin eignet sich besonders für Test-Szenarien, da hierdurch gewährleistet wird, dass die Anfragen in gleicher Anzahl (bzw. im entsprechend gewichteten Verhältnis) auf alle Server verteilt werden. Bei einigen anderen Methoden wird der Datenverkehr bei geringem Volumen nicht immer gleichmäßig verteilt, was die Testergebnisse verfälschen kann.

Die Gleichmäßigkeit der Verteilung kann auch Aufschluss darüber geben, ob die Caches gut funktionieren und ihre Kapazität voll ausschöpfen: Da es beim Round-Robin-Verfahren nicht möglich ist, Anforderungen für eine bestimmte Datei an denselben Server zu senden, muss jeder Server letztendlich wahrscheinlich eine große Bandbreite an Dateien bereitstellen und zwischenspeichern (und normalerweise viele derselben Dateien wie seine Peers). Dadurch ist es wahrscheinlicher, dass der Cache voll wird.

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

Wenigste Verbindungen und wenig Zeit

Wie oben erwähnt, ist Least Connections die am besten geeignete Lastausgleichstechnik für die meisten Anwendungsfälle und insbesondere für Produktionsverkehr. Dies wird durch Erfahrungsberichte unserer Kunden untermauert. Seine Leistung ist stabil und vorhersehbar.

Darüber hinaus verteilt Least Connections die Arbeitslast effektiv auf die Server entsprechend ihrer Kapazität. Ein leistungsstärkerer Server erfüllt Anfragen schneller, sodass zu einem beliebigen Zeitpunkt wahrscheinlich eine geringere Anzahl von Verbindungen noch verarbeitet werden (oder überhaupt auf den Beginn der Verarbeitung warten) als bei einem Server mit geringerer Kapazität. Bei der Option „Least Connections“ wird jede Anfrage an den Server mit der geringsten Anzahl aktueller Verbindungen gesendet. Daher ist es wahrscheinlicher, dass Anfragen an leistungsstarke Server gesendet werden. (Das Festlegen von Gewichtungen führt jedoch trotzdem zu einer noch effizienteren Verteilung der Anfragen, wie weiter unten unter „Festlegen von Gewichtungen, wenn die Server nicht identisch sind“ beschrieben.)

Sie können Least Time (nur NGINX Plus) als eine sensiblere Version von Least Connections betrachten. Durch die Einbeziehung der durchschnittlichen Antwortzeit wird die jüngste Leistungshistorie des Servers berücksichtigt (tatsächlich handelt es sich um einen exponentiell gewichteten gleitenden Durchschnitt, sodass ältere Antwortzeiten den Durchschnitt weniger beeinflussen als neuere Antwortzeiten).

Least Time eignet sich insbesondere dann, wenn die vorgelagerten Server sehr unterschiedliche durchschnittliche Antwortzeiten aufweisen. Wenn Sie beispielsweise zum Zwecke der Notfallwiederherstellung Server in verschiedenen Rechenzentren haben, werden bei Least Time tendenziell mehr Anfragen an die lokalen Server gesendet, da diese schneller reagieren. Ein weiterer Anwendungsfall sind Cloud-Umgebungen, in denen die Serverleistung oft sehr unvorhersehbar ist.

Festlegen von Gewichten, wenn die Server nicht identisch sind

Wir haben mehrfach erwähnt, wie wichtig es ist, Servergewichte festzulegen, wenn die Server in der Upstream-Gruppe unterschiedliche Kapazitäten haben. Dies ist insbesondere für den Round-Robin-Load-Balancer wichtig, der ansonsten an jeden Server die gleiche Anzahl an Anfragen sendet. Dies führt wahrscheinlich dazu, dass ein weniger leistungsstarker Server überlastet wird, während ein leistungsstärkerer Server teilweise ungenutzt herumsteht.

Um Gewichte festzulegen, schließen Sie den Gewichtsparameter in eine oder mehrere Serverdirektiven im Upstreamblock ein. Der Standardwert ist 1.

Sie können sich die Auswirkungen der Festlegung von Gewichten für die verschiedenen Lastausgleichstechniken folgendermaßen vorstellen. Beachten Sie, dass die Beschreibungen 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 Gewicht = 6;
Server Web2 Gewicht = 3;
Server Web3;
}

• Round Robin – Jeder Server erhält den Prozentsatz der eingehenden Anfragen, der seiner Gewichtung geteilt durch die Summe der Gewichtungen entspricht. In unserem Beispiel erhält Web1 von zehn Anfragen sechs (60 %), Web2 drei (30 %) und Web3 eine (10 %).

• Hash und IP-Hash – Denken Sie daran, dass der Hash-Algorithmus ohne Gewichte die Menge aller möglichen Hash-Werte gleichmäßig in „Buckets“ aufteilt, einen für jeden Server in der Upstream-Gruppe. Bei Gewichten werden stattdessen die Gewichte summiert, die Menge der möglichen Hashes auf diese Anzahl von Buckets aufgeteilt und jedem Server die Anzahl von Buckets zugeordnet, die seinem Gewicht entspricht.

  In unserem Beispiel gibt es zehn Buckets mit jeweils 10 % der möglichen Hashes. Sechs Buckets (60 % der möglichen Hashes) sind mit web1 verknüpft, drei Buckets (30 %) mit web2 und ein Bucket (10 %) mit web3 .

• Wenigste Verbindungen und geringste Zeit – Wir haben bereits erwähnt, dass diese Algorithmen auch ohne Gewichte die Arbeitslast entsprechend ihrer Kapazität recht effektiv auf die Server verteilen können. Durch das Setzen von Gewichten wird ihre Leistung in dieser Hinsicht noch weiter verbessert.

  Denken Sie daran, dass bei den Methoden Least Connections und Least Time jede Anfrage an den Server mit dem niedrigsten „Score“ (Anzahl der Verbindungen bzw. eine mathematische Kombination aus Verbindungen und Zeit) gesendet wird. Wenn Sie Gewichte zuweisen, teilt der Load Balancer die Punktzahl jedes Servers durch seine Gewichtung und sendet die Anforderung erneut an den Server mit dem niedrigsten Wert.

  Hier ist ein Beispiel für „Least Connections“ mit unseren Beispielgewichten und der angegebenen Anzahl aktiver Verbindungen: Der Score von web1 von 100 ist der niedrigste und es erhält die Anfrage, obwohl seine Verbindungsanzahl von 600 1,5-mal so hoch ist wie die von web2 und mehr als 4-mal so hoch wie die von web3 .

  • web1 – 600 aktive Verbindungen ÷ 6 = 100
  • web2 – 400 aktive Verbindungen ÷ 3 = 133
  • web3 – 125 aktive Verbindungen ÷ 1 = 125

Zusammenfassung

Nachdem wir die Vor- und Nachteile der in NGINX Plus und NGINX verfügbaren Lastausgleichstechniken geprüft haben, sind wir zu dem Schluss gekommen, dass Least Connections (und bei NGINX Plus Least Time) für die größte Bandbreite an Anwendungsfällen am besten geeignet ist. Es ist jedoch wichtig, dass Sie bei Ihrer Bereitstellung mehrere Methoden testen, da eine bestimmte Kombination aus Datenverkehr und Servereigenschaften für Sie möglicherweise die bessere Methode ist.

Um die Lastverteilung von NGINX Plus selbst auszuprobieren, 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 Lastenausgleich in verschiedenen Anwendungsfällen hören. Fügen Sie sie bitte unten im Kommentarbereich hinzu.