NGINX Plus und Microsoft Azure Load Balancer

Michael Pleshakov

[Redaktion – Dieser Beitrag wurde aktualisiert, um die Funktionen widerzuspiegeln, die NGINX Plus und die Azure-Lastenausgleichsdienste seit Juni 2021 unterstützen. Außerdem wird auf die NGINX Plus API verwiesen, die das in der ursprünglichen Version des Beitrags erwähnte separate Modul für die dynamische Konfiguration ersetzt und als veraltet kennzeichnet.]

Kunden, die Microsoft Azure nutzen, haben drei Optionen für den Lastenausgleich: NGINX Plus, die Lastenausgleichsdienste von Azure oder NGINX Plus in Verbindung mit den Lastenausgleichsdiensten von Azure. Dieser Beitrag soll Ihnen genügend Informationen für eine fundierte Entscheidung liefern und zeigt außerdem, wie Sie durch den Einsatz von NGINX Plus mit Azure Load Balancer einen hochverfügbaren HTTP-Load-Balancer mit umfangreicher Layer-7-Funktionalität erhalten.

Überblick

Microsoft Azure bietet seinen Benutzern zwei Optionen für einen Load Balancer: Azure Load Balancer für grundlegendes TCP/UDP-Load-Balancing (auf Layer 4, der Netzwerkschicht) und Azure Application Gateway für HTTP/HTTPS-Load-Balancing (auf Layer 7, der Anwendungsschicht). Diese Lösungen eignen sich zwar für einfache Anwendungsfälle, bieten jedoch viele Funktionen nicht, die bei NGINX Plus standardmäßig enthalten sind.

Hier finden Sie einen allgemeinen Vergleich zwischen NGINX Plus und den Load-Balancing-Angeboten von Azure:

Sehen wir uns nun einige der Unterschiede zwischen NGINX Plus und den Load-Balancing-Diensten von Azure sowie ihre jeweiligen besonderen Funktionen an und betrachten wir, wie NGINX Plus und Azure-Load-Balancer zusammenarbeiten können.

Vergleich von NGINX Plus und Azure-Lastenausgleichsdiensten

Lastverteilungsmethoden

NGINX Plus bietet neben der standardmäßigen Round-Robin-Methode mehrere Lastverteilungsverfahren zur Auswahl:

• Least Connections – Jede Anfrage wird an den Server mit der geringsten Anzahl aktiver Verbindungen gesendet.
• Kürzeste Antwortzeit – Jede Anfrage wird an den Server mit dem niedrigsten Wert gesendet. Dieser wird anhand einer gewichteten Kombination aus durchschnittlicher Latenz und der geringsten Anzahl aktiver Verbindungen berechnet.
• IP-Hash – Jede Anfrage wird an den Server gesendet, der anhand der Quell-IP-Adresse der Anfrage bestimmt wird.
• Generischer Hash – Jede Anfrage wird an den Server gesendet, der anhand eines benutzerdefinierten Schlüssels bestimmt wird. Dieser kann eine beliebige Kombination aus Text und NGINX-Variablen enthalten, beispielsweise die Variablen, die den Headerfeldern Quell-IP-Adresse und Quell-Port entsprechen, oder den URI.
• Zufällig – Jede Anfrage wird an einen zufällig ausgewählten Server gesendet. Wenn der Parameter two angegeben ist, wählt NGINX Plus nach dem Zufallsprinzip zwei Server aus und entscheidet sich dann je nach Konfiguration anhand des Algorithmus „Least Connections“ (Standardeinstellung) oder „Least Time“ für einen der beiden.

Alle Methoden können erweitert werden, indem jedem Backend-Server unterschiedliche Gewichtungswerte zugewiesen werden. Weitere Informationen zu den Methoden finden Sie im NGINX Plus-Administratorhandbuch.

Azure Load Balancer bietet eine Lastenausgleichsmethode: Hash, die standardmäßig einen Schlüssel verwendet, der auf den Headerfeldern Source IP Address, Source Port, Destination IP Address, Destination Port und Protocol basiert, um einen Backend-Server auszuwählen.

Azure Application Gateway bietet nur ein Round-Robin-Verfahren.

Sitzungspersistenz

Sitzungspersistenz, auch bekannt als Sticky Sessions oder Sitzungsaffinität, ist erforderlich, wenn eine Anwendung voraussetzt, dass alle Anfragen eines bestimmten Clients weiterhin an denselben Backend-Server gesendet werden, da der Clientstatus nicht von den Backend-Servern gemeinsam genutzt wird.

NGINX Plus unterstützt drei fortschrittliche Methoden zur Sitzungspersistenz:

• Sticky Cookie – NGINX Plus fügt der ersten Antwort der Upstream-Gruppe für einen bestimmten Client ein Sitzungscookie hinzu. Dieses Cookie identifiziert den Backend-Server, der zur Verarbeitung der Anfrage verwendet wurde. Der Client sendet dieses Cookie bei nachfolgenden Anfragen mit, und NGINX Plus leitet die Clientanfrage damit an denselben Backend-Server weiter.
• Sticky Learn – NGINX Plus überwacht Anfragen und Antworten, um Sitzungskennungen (in der Regel Cookies) zu ermitteln, und bestimmt anhand dieser den Server für nachfolgende Anfragen innerhalb einer Sitzung.
• Sticky Route – Es kann eine Zuordnung zwischen Routenwerten und Backend-Servern konfiguriert werden, sodass NGINX Plus Anfragen auf einen Routenwert prüft und den passenden Backend-Server auswählt.

NGINX Plus bietet außerdem zwei grundlegende Methoden für die Sitzungspersistenz, die als zwei der oben beschriebenen Lastverteilungsverfahren implementiert sind:

• IP-Hash – Der Backend-Server wird anhand der IP-Adresse der Anfrage bestimmt.
• Hash – Der Backend-Server wird anhand eines benutzerdefinierten Schlüssels bestimmt, zum Beispiel Quell-IP-Adresse und Quell-Port, oder anhand des URI.

Azure Load Balancer unterstützt das Äquivalent zur Hash-Methode von NGINX Plus, wobei der Schlüssel jedoch auf bestimmte Kombinationen der Headerfelder Quell-IP-Adresse, Quell-Port, Ziel-IP-Adresse, Ziel-Port und Protokoll beschränkt ist.

Azure Application Gateway unterstützt das Äquivalent zur Sticky-Cookie-Methode von NGINX Plus mit folgenden Einschränkungen: Der Name des Cookies, sein Ablaufdatum, die Domain, der Pfad sowie die Cookie-Attribute HttpOnly und Secure können nicht konfiguriert werden.

Hinweis: Wenn Sie Azure Load Balancer, die IP-Hash-Methode von NGINX Plus oder die Hash-Methode von NGINX Plus verwenden und dabei die Quell-IP-Adresse in den Schlüssel einbeziehen, funktioniert die Sitzungspersistenz nur dann ordnungsgemäß, wenn die IP-Adresse des Clients während der gesamten Sitzung unverändert bleibt. Dies ist nicht immer der Fall, beispielsweise wenn ein Mobilgerät von einem WLAN zu einem Mobilfunknetz wechselt. Um sicherzustellen, dass Anfragen weiterhin denselben Backend-Server erreichen, empfiehlt es sich, eine der oben aufgeführten erweiterten Methoden zur Sitzungspersistenz zu verwenden.

Integritätsprüfungen

Azure Load Balancer und Azure Application Gateway unterstützen grundlegende Integritätsprüfungen für Anwendungen. Sie können die URL angeben, die der Lastenausgleich anfordert. Der Back-End-Server wird als fehlerfrei eingestuft, wenn der erwartete HTTP-Rückgabecode 200 empfangen wird. Sie können die Häufigkeit der Integritätsprüfung und den Zeitraum bis zur Einstufung des Servers als fehlerhaft festlegen. Bei Azure Application Gateway können Sie außerdem den erwarteten Antwortcode anpassen und mit dem Inhalt des Antworttexts abgleichen.

NGINX Plus erweitert diese Funktionalität um erweiterte Integritätsprüfungen. Neben der Angabe der zu verwendenden URL können Sie mit NGINX Plus Header in die Anfrage einfügen, nach verschiedenen Antwortcodes suchen und sowohl die Header als auch den Textkörper der Antwort untersuchen.

Eine nützliche verwandte Funktion in NGINX Plus ist der langsame Anlauf. NGINX Plus erhöht die Last für einen neuen oder kürzlich wiederhergestellten Server schrittweise, damit dieser nicht durch zu viele Verbindungen überlastet wird. Dies ist hilfreich, wenn Ihre Backend-Server eine gewisse Aufwärmzeit benötigen und ausfallen würden, wenn sie ihren vollen Anteil am Datenverkehr erhalten, sobald sie als fehlerfrei erkannt werden.

NGINX Plus unterstützt außerdem Zustandsprüfungen für TCP- und UDP-Server, bei denen Sie eine zu sendende Zeichenfolge und eine in der Antwort zu suchende Zeichenfolge angeben können.

Azure Load Balancer unterstützt TCP-Integritätsprüfungen, bietet jedoch nicht dieses Maß an Überwachung.

SSL/TLS-Terminierung

NGINX Plus unterstützt die SSL/TLS-Terminierung, ebenso wie Azure Application Gateway. Azure Load Balancer hingegen nicht.

Verbindungs- und Ratenbegrenzungen

Mit NGINX Plus können Sie mehrere Begrenzungen konfigurieren, um den ein- und ausgehenden Datenverkehr Ihrer NGINX Plus-Instanz zu steuern. Dazu gehören die Begrenzung von eingehenden Verbindungen, von Verbindungen zu Backend-Knoten, der Rate eingehender Anfragen sowie der Datenübertragungsrate von NGINX Plus zu Clients.

Azure Application Gateway und Azure Load Balancer unterstützen keine Raten- oder Verbindungslimits. Sie können jedoch andere Azure-Dienste verwenden, um eine Ratenbegrenzung zu konfigurieren und zu aktivieren.

Protokollunterstützung sowie URL-Umschreibung und -Weiterleitung

NGINX Plus, Azure Application Gateway und Azure Load Balancer unterstützen alle Folgendes:

• HTTP/2 – NGINX Plus akzeptiert seit 2016 HTTP/2-Anfragen von Clients. Azure hat die WebSocket-Unterstützung erst später hinzugefügt.
• WebSocket – NGINX Plus akzeptiert seit 2014 WebSocket-Verbindungen von Clients. Azure hat die WebSocket-Unterstützung erst später hinzugefügt.
• URL-Umschreibung und Anfragenumleitung – Die URL einer Anfrage kann geändert werden, bevor sie an einen Backend-Server weitergeleitet wird. So können Sie intern Anfragepfade und Dateispeicherorte ändern, ohne die gegenüber Clients angegebenen URLs anzupassen. Sie können Anfragen auch umleiten, beispielsweise indem Sie das Schema einer HTTP-Anfrage in HTTPS ändern.

NGINX Plus mit Azure-Lastenausgleichsdiensten

In Kombination mit Azure Load Balancer und Azure Traffic Manager wird NGINX Plus zu einer hochverfügbaren Load-Balancer-Lösung mit umfangreichen Layer-7-Funktionen.

Aktiv-Aktiv-Hochverfügbarkeit

Durch die Verwendung von Azure Load Balancer zur Lastverteilung auf NGINX Plus-Instanzen in einer Verfügbarkeitsgruppe erstellen Sie einen hochverfügbaren Load Balancer innerhalb einer Region.

Automatische Skalierung von NGINX Plus

Sie können die automatische Skalierung von NGINX Plus-Instanzen auf Grundlage der durchschnittlichen CPU-Auslastung einrichten. Dazu erstellen Sie Verfügbarkeitsgruppen im Azure Cloud Service, der Ihre NGINX Plus-Instanzen hostet. Die Synchronisierung der NGINX Plus-Konfigurationsdateien müssen Sie selbst sicherstellen.

Automatische Skalierung von Backend-Instanzen

Sie können außerdem die automatische Skalierung Ihrer Backend-Instanzen auf Grundlage der durchschnittlichen CPU-Auslastung einrichten. Dazu erstellen Sie Verfügbarkeitsgruppen in dem Azure Cloud Service, der Ihre Backend-Instanzen hostet. Sie müssen Backend-Instanzen selbst zur NGINX Plus-Konfiguration hinzufügen bzw. daraus entfernen. Dies ist über die NGINX Plus API möglich.

Um Aktualisierungen der NGINX Plus-Konfiguration zu automatisieren (entweder in Kombination mit Verfügbarkeitsgruppen oder bei eigenständiger Verwendung von NGINX Plus), können Sie ein Service-Discovery-System in NGINX Plus integrieren – entweder über die NGINX Plus API oder über DNS, sofern das System über eine DNS-Schnittstelle verfügt. Lesen Sie unsere Blogbeiträge über die Verwendung von NGINX Plus mit gängigen Service-Discovery-Systemen:

• Diensterkennung für NGINX Plus mithilfe von DNS-SRV-Einträgen aus Consul
• Serviceerkennung für NGINX Plus mithilfe von Consul-APIs
• Diensterkennung für NGINX Plus mit etcd
• Serviceerkennung für NGINX Plus mit ZooKeeper

Integration mit Azure Traffic Manager

Für eine global verteilte Umgebung können Sie Azure Traffic Manager verwenden, um den Datenverkehr von Clients auf mehrere Regionen zu verteilen.

Zusätzliche Funktionen in Azure-Lastenausgleichsdiensten

Azure Load Balancer und Application Gateway werden von Azure Cloud verwaltet und bieten beide eine hochverfügbare Lösung für den Lastenausgleich.

Eine Funktion von Azure Load Balancer, die in NGINX Plus nicht verfügbar ist, ist Source-NAT. Dabei hat der ausgehende Datenverkehr von Backend-Instanzen dieselbe Quell-IP-Adresse wie der Load Balancer.

Azure Load Balancer ermöglicht eine automatische Neukonfiguration bei Verwendung der Autoskalierungsfunktion von Azure Cloud.

Zusammenfassung

Wenn Ihre Anforderungen an den Lastenausgleich einfach sind, können die Lastenausgleichsangebote von Azure eine gute Lösung darstellen. Bei komplexeren Anforderungen ist NGINX Plus eine gute Wahl. Sie können NGINX Plus entweder allein oder in Verbindung mit Azure Load Balancer verwenden, um eine hohe Verfügbarkeit der NGINX Plus-Instanzen zu gewährleisten.

Wenn Sie NGINX Plus auf Microsoft Azure testen möchten, starten Sie noch heute Ihre kostenlose 30-Tage-Testversion oder kontaktieren Sie uns, um Ihre Anwendungsfälle zu besprechen.

Über den Autor

Michael Pleshakov

Weitere Blogbeiträge von Michael Pleshakov