Bei den meistbesuchten Websites im Internet dominieren NGINX und NGINX Plus den Markt. Tatsächlich betreibt NGINX mehr der weltweit meistbesuchten 1 Million Websites als jeder andere Webserver. Seine Fähigkeit, mehr als 1 Million gleichzeitige Verbindungen auf einem einzigen Server zu verarbeiten, hat dazu geführt, dass NGINX von Hyperscale-Websites und -Apps wie Airbnb, Netflix und Uber eingesetzt wird.
NGINX Plus ist zwar vor allem als Webserver, HTTP-Reverse-Proxy und Load Balancer bekannt, aber zugleich auch ein voll ausgestatteter Application Delivery Controller (ADC) mit Unterstützung für TCP- und UDP-Anwendungen. Seine ereignisgesteuerte Architektur und all die anderen Eigenschaften, die zu seinem Erfolg bei HTTP-Anwendungsfällen beigetragen haben, eignen sich ebenso für das Internet der Dinge (IoT).
In diesem Artikel zeigen wir, wie NGINX Plus für den Lastenausgleich von MQTT-Datenverkehr eingesetzt werden kann. MQTT wurde ursprünglich 1999 für die Kommunikation mit abgelegenen Ölfeldern veröffentlicht. 2013 wurde es für IoT-Anwendungsfälle aktualisiert und hat sich seitdem zum bevorzugten Protokoll für viele IoT-Implementierungen entwickelt. Produktive IoT-Implementierungen mit Millionen von Geräten stellen hohe Anforderungen an die Leistung und die erweiterten Funktionen eines Load Balancers. In dieser zweiteiligen Blogartikelreihe behandeln wir die folgenden fortgeschrittenen Anwendungsfälle.
- Lastverteilung für MQTT-Datenverkehr (dieser Beitrag)
- MQTT-Datenverkehr verschlüsseln und authentifizieren
Die Testumgebung
Um die Funktionen von NGINX Plus zu erkunden, verwenden wir eine einfache Testumgebung, die die wichtigsten Komponenten einer IoT-Umgebung mit einem Cluster aus MQTT-Brokern abbildet. Bei den MQTT-Brokern in dieser Umgebung handelt es sich um HiveMQ-Instanzen, die in Docker-Containern ausgeführt werden.
Testumgebung für MQTT-Lastverteilung und Sitzungspersistenz
NGINX Plus fungiert als Reverse-Proxy und Load Balancer für den MQTT-Broker und lauscht am standardmäßigen MQTT-Port 1883. Dadurch erhält der Client eine einfache und einheitliche Schnittstelle, während die MQTT-Knoten im Backend skaliert (und sogar offline genommen) werden können, ohne dass dies Auswirkungen auf den Client hat. Wir verwenden das Mosquitto-Befehlszeilentool als Client, der die IoT-Geräte in der Testumgebung repräsentiert.
Alle Anwendungsfälle in diesem Beitrag und in Teil 2 verwenden diese Testumgebung, und alle Konfigurationen lassen sich direkt auf die in der Abbildung dargestellte Architektur anwenden. Eine vollständige Anleitung zum Aufbau der Testumgebung finden Sie in Anhang 1.
MQTT-Lastverteilung mit aktiven Integritätsprüfungen für hohe Verfügbarkeit
Eine Hauptfunktion eines Load Balancers besteht darin, eine hohe Verfügbarkeit der Anwendung zu gewährleisten, sodass Backend-Server hinzugefügt oder entfernt werden beziehungsweise offline gehen können, ohne den Client zu beeinträchtigen. Für einen zuverlässigen Betrieb sind dabei Systemdiagnosen unerlässlich, die proaktiv die Verfügbarkeit der einzelnen Backend-Server prüfen. Mithilfe aktiver Systemdiagnosen kann NGINX Plus ausgefallene Server aus der Load-Balancing-Gruppe entfernen, bevor tatsächliche Clientanfragen sie erreichen.
Der Nutzen einer Zustandsprüfung hängt davon ab, wie genau sie den realen Anwendungsdatenverkehr simuliert und die Antwort analysiert. Einfache Prüfungen der Serververfügbarkeit, etwa durch einen Ping, gewährleisten nicht, dass der Backend-Dienst ausgeführt wird. Prüfungen auf offene TCP-Ports gewährleisten nicht, dass die Anwendung selbst fehlerfrei funktioniert. Hier konfigurieren wir für die Testumgebung einen einfachen Lastenausgleich mit einer Zustandsprüfung, die sicherstellt, dass jeder Backend-Server neue MQTT-Verbindungen annehmen kann.
Wir nehmen Änderungen an zwei Konfigurationsdateien vor.
In der Hauptdatei nginx.conf fügen wir den folgenden stream-Block und die include-Direktive ein, damit NGINX Plus die Konfiguration für den TCP-Lastenausgleich aus einer oder mehreren Dateien im Unterverzeichnis stream_conf.d einliest, das sich im selben Verzeichnis wie nginx.conf befindet. Dies tun wir, anstatt die eigentliche Konfiguration in nginx.conf aufzunehmen.
Codebeispiel wird geladen…
Anschließend erstellen wir im selben Verzeichnis wie nginx.conf das Verzeichnis stream_conf.d, in dem unsere TCP- und UDP-Konfigurationsdateien abgelegt werden. Beachten Sie, dass wir das bereits vorhandene Verzeichnis conf.d nicht verwenden, da es standardmäßig für den http-Konfigurationskontext reserviert ist und das Hinzufügen einer stream-Konfiguration dort daher fehlschlägt.
Codebeispiel wird geladen…
In stream_mqtt_healthcheck.conf definieren wir zunächst das Zugriffsprotokollformat für den MQTT-Datenverkehr (Zeilen 1–2). Dieses ähnelt bewusst dem allgemeinen HTTP-Protokollformat, sodass die resultierenden Protokolle in Protokollanalysetools importiert werden können.
Als Nächstes definieren wir die upstream-Gruppe namens hive_mq (Zeilen 4–9), die drei MQTT-Server enthält. In unserer Testumgebung sind sie jeweils über localhost mit einer eindeutigen Portnummer erreichbar. Die zone-Direktive legt einen Speicherbereich fest, der von allen NGINX Plus-Worker-Prozessen gemeinsam genutzt wird, um Informationen zum Lastverteilungsstatus und Systemzustand zu verwalten.
Der match-Block (Zeilen 11–15) definiert die Integritätsprüfung, mit der die Verfügbarkeit der MQTT-Server getestet wird. Die send-Direktive ist die hexadezimale Darstellung eines vollständigen MQTT-CONNECT-Pakets mit der Client-Kennung (ClientId) nginx health check. Dieses wird bei jeder Ausführung der Integritätsprüfung an jeden der in der Upstream-Gruppe definierten Server gesendet. Die zugehörige expect-Direktive beschreibt die Antwort, die der Server zurückgeben muss, damit NGINX Plus ihn als funktionsfähig einstuft. Hier ist die 4 Byte lange Hexadezimalzeichenfolge 20 02 00 00 ein vollständiges MQTT-CONNACK-Paket. Der Empfang dieses Pakets zeigt, dass der MQTT-Server neue Clientverbindungen annehmen kann.
Der server-Block (Zeilen 17–25) konfiguriert, wie NGINX Plus mit Clients umgeht. NGINX Plus lauscht am standardmäßigen MQTT-Port 1883 und leitet den gesamten Datenverkehr an die Upstream-Gruppe hive_mq weiter (Zeile 19). Die Direktive health_check legt fest, dass für die Upstream-Gruppe Systemdiagnosen durchgeführt werden (standardmäßig alle fünf Sekunden) und dabei die im mqtt_conn-match-Block definierte Prüfung verwendet wird.
Überprüfen der Konfiguration
Um zu überprüfen, ob diese Basiskonfiguration funktioniert, können wir mit dem Mosquitto-Client einige Testdaten in unserer Testumgebung veröffentlichen.
$ mosquitto_pub -d -h mqtt.example.com -t "topic/test" -m "test123" -i "thing001"Client thing001 sending CONNECT
Client thing001 received CONNACK
Client thing001 sending PUBLISH (d0, q0, r0, m1, 'topic/test', ... (7 bytes))
Client thing001 sending DISCONNECT
$ tail --lines=1 /var/log/nginx/mqtt_access.log
192.168.91.1 [23/Mar/2017:11:41:56 +0000] TCP 200 23 4 127.0.0.1:18831Die Zeile aus dem Zugriffsprotokoll zeigt, dass NGINX Plus insgesamt 23 Byte empfangen und 4 Byte an den Client gesendet hat (das CONNACK-Paket). Außerdem ist zu erkennen, dass der MQTT-Knoten node1 ausgewählt wurde (Port 18831). Wie die folgenden Zeilen aus dem Zugriffsprotokoll zeigen, wählt der standardmäßige Round-Robin-Lastverteilungsalgorithmus bei einer Wiederholung des Tests nacheinander node1, node2 und node3 aus.
$ tail --lines=4 /var/log/nginx/mqtt_access.log192.168.91.1 [23/Mar/2017:11:41:56 +0000] TCP 200 23 4 127.0.0.1:18831
192.168.91.1 [23/Mar/2017:11:42:26 +0000] TCP 200 23 4 127.0.0.1:18832
192.168.91.1 [23/Mar/2017:11:42:27 +0000] TCP 200 23 4 127.0.0.1:18833
192.168.91.1 [23/Mar/2017:11:42:28 +0000] TCP 200 23 4 127.0.0.1:18831MQTT-Lastverteilung für Sitzungspersistenz mit dem NGINX-JavaScript-Modul
[Redaktion – Der folgende Anwendungsfall ist nur einer von vielen für das NGINX-JavaScript-Modul. Eine vollständige Liste finden Sie unter „Anwendungsfälle für das NGINX-JavaScript-Modul“.]
Der Code in diesem Abschnitt wurde wie folgt aktualisiert, um Änderungen an der Implementierung von NGINX JavaScript seit der ursprünglichen Veröffentlichung des Blogbeitrags zu berücksichtigen:
- Zur Verwendung des überarbeiteten Sitzungsobjekts (
s) für das Stream-Modul, das mit NGINX JavaScript 0.2.4 eingeführt wurde. - Zur Verwendung der
js_import-Direktive, welche diejs_include-Direktive ab NGINX Plus R23 ersetzt. Weitere Informationen finden Sie in der Referenzdokumentation zum NGINX JavaScript-Modul – im Abschnitt Beispielkonfiguration wird die korrekte Syntax für NGINX-Konfigurations- und JavaScript-Dateien gezeigt.
Round-Robin-Lastverteilung ist ein effektiver Mechanismus, um Clientverbindungen auf eine Gruppe von Servern zu verteilen. Es gibt jedoch mehrere Gründe, warum sie für MQTT-Verbindungen nicht ideal ist.
MQTT-Server erwarten häufig eine langlebige Verbindung zwischen Client und Server, wobei sich auf dem Server umfangreiche Sitzungszustände ansammeln können. Aufgrund der Beschaffenheit von IoT-Geräten und der von ihnen genutzten IP-Netzwerke werden Verbindungen jedoch immer wieder unterbrochen, sodass einige Clients häufig neue Verbindungen herstellen müssen. NGINX Plus kann seinen Hash-Lastausgleichsalgorithmus verwenden, um anhand der IP-Adresse des Clients einen MQTT-Server auszuwählen. Durch einfaches Hinzufügen von hash $remote_addr; zum Upstream-Block wird Sitzungspersistenz aktiviert, sodass bei jeder neuen Verbindung von einer bestimmten Client-IP-Adresse derselbe MQTT-Server ausgewählt wird.
Wir können uns jedoch nicht darauf verlassen, dass IoT-Geräte die Verbindung über dieselbe IP-Adresse wiederherstellen, insbesondere wenn sie Mobilfunknetze nutzen (zum Beispiel GSM oder LTE). Um sicherzustellen, dass derselbe Client die Verbindung zum selben MQTT-Server wiederherstellt, müssen wir die MQTT-Client-ID als Schlüssel für den Hash-Algorithmus verwenden.
Sitzungspersistenz basierend auf der MQTT-ClientId
Die MQTT-ClientId ist ein obligatorischer Bestandteil des initialen CONNECT-Pakets. Daher steht sie NGINX Plus zur Verfügung, bevor das Paket per Proxy an den Upstream-Server weitergeleitet wird. Mit NGINX JavaScript können wir das CONNECT-Paket parsen und die ClientId als Variable extrahieren, die anschließend von der hash-Direktive verwendet werden kann, um eine MQTT-spezifische Sitzungspersistenz zu implementieren.
NGINX JavaScript ist die „NGINX-native“ Programmiersprache für die Konfiguration. Es handelt sich um eine speziell für NGINX und NGINX Plus entwickelte JavaScript-Implementierung, die auf serverseitige Anwendungsfälle und die Verarbeitung einzelner Anfragen zugeschnitten ist. Sie weist drei wesentliche Merkmale auf, die sie für die Implementierung der Sitzungspersistenz für MQTT geeignet machen:
- NGINX JavaScript ist eng in die Verarbeitungsphasen von NGINX Plus integriert, sodass wir Clientpakete prüfen können, bevor sie per Lastverteilung an die Upstream-Gruppe weitergeleitet werden.
- NGINX JavaScript verwendet integrierte JavaScript-Methoden zur Verarbeitung von Zeichenfolgen und Zahlen, wodurch sich Layer-4-Protokolle effizient parsen lassen. Für das eigentliche Parsen des MQTT-
CONNECT-Pakets sind weniger als 20 Codezeilen erforderlich. - NGINX JavaScript kann Variablen erstellen, die in der NGINX Plus-Konfiguration verfügbar sind.
Eine Anleitung zum Aktivieren von NGINX JavaScript finden Sie in Anhang 2.
NGINX Plus-Konfiguration für Sitzungspersistenz
Die NGINX Plus-Konfiguration für diesen Anwendungsfall bleibt relativ einfach. Die folgende Konfiguration ist eine angepasste Version des Beispiels unter „Lastverteilung mit aktiven Integritätsprüfungen“, wobei die Integritätsprüfungen der Kürze halber weggelassen wurden.
Codebeispiel wird geladen…
Zunächst geben wir mit der js_import-Direktive den Speicherort des NGINX-JavaScript-Codes an. Die js_set-Direktive weist NGINX Plus an, die Funktion setClientId aufzurufen, wenn die Variable $mqtt_client_id ausgewertet werden muss. Wir ergänzen das Zugriffsprotokoll um weitere Details, indem wir diese Variable in Zeile 5 an das mqtt-Protokollformat anhängen.
In Zeile 12 aktivieren wir die Sitzungspersistenz mit der Direktive hash, wobei wir $mqtt_client_id als Schlüssel angeben. Beachten Sie, dass wir den Parameter consistent verwenden. Fällt ein Upstream-Server aus, wird sein Anteil am Datenverkehr dadurch gleichmäßig auf die verbleibenden Server verteilt, ohne dass bereits auf diesen Servern bestehende Sitzungen beeinträchtigt werden. Konsistentes Hashing wird in unserem Blogbeitrag über das Sharding eines Webcaches näher erläutert – die Prinzipien und Vorteile gelten hier gleichermaßen.
Die js_preread-Direktive (Zeile 18) gibt die NGINX-JavaScript-Funktion an, die in der Vorablesephase der Anfrageverarbeitung ausgeführt wird. Die Vorablesephase wird für jedes Paket (in beide Richtungen) ausgelöst und findet vor dem Proxying statt, sodass der Wert von $mqtt_client_id bei Bedarf im upstream-Block verfügbar ist.
NGINX-JavaScript-Code für Sitzungspersistenz
Wir definieren den JavaScript-Code zum Extrahieren der MQTT-ClientId in der Datei „mqtt.js“, die über die Direktive „js_import“ in der NGINX Plus-Konfigurationsdatei „stream_mqtt_session_persistence.conf“ geladen wird.
Codebeispiel wird geladen…
Die Hauptfunktion getClientId() wird in Zeile 4 deklariert. Ihr wird das Objekt namens s übergeben, das die aktuelle TCP-Sitzung darstellt. Das Sitzungsobjekt verfügt über zahlreiche Eigenschaften, von denen mehrere in dieser Funktion verwendet werden.
Die Zeilen 5–9 stellen sicher, dass das aktuelle Paket das erste vom Client empfangene Paket ist. Nachfolgende Clientnachrichten und Serverantworten werden ignoriert, sodass nach dem Aufbau einer Verbindung kein zusätzlicher Verarbeitungsaufwand für den Datenverkehr entsteht.
Codebeispiel wird geladen…
In den Zeilen 10–24 wird der MQTT-Header überprüft, um sicherzustellen, dass das Paket vom Typ CONNECT ist, und um zu ermitteln, wo die MQTT-Nutzdaten beginnen.
Codebeispiel wird geladen…
Die Zeilen 27–32 extrahieren die ClientId aus der Nutzlast und speichern den Wert in der globalen JavaScript-Variable client_id_str. Diese Variable wird anschließend mit der Funktion setClientId in die NGINX-Konfiguration exportiert (Zeilen 43–45).
Überprüfen der Sitzungspersistenz
Jetzt können wir den Mosquitto-Client erneut verwenden, um die Sitzungspersistenz zu testen. Dazu senden wir eine Reihe von MQTT-Veröffentlichungsanfragen mit drei verschiedenen ClientId-Werten (Option -i).
$ mosquitto_pub -h mqtt.example.com -t "topic/test" -m "test123" -i "foo"$ mosquitto_pub -h mqtt.example.com -t "topic/test" -m "test123" -i "bar"
$ mosquitto_pub -h mqtt.example.com -t "topic/test" -m "test123" -i "baz"
$ mosquitto_pub -h mqtt.example.com -t "topic/test" -m "test123" -i "foo"
$ mosquitto_pub -h mqtt.example.com -t "topic/test" -m "test123" -i "foo"
$ mosquitto_pub -h mqtt.example.com -t "topic/test" -m "test123" -i "foo"
$ mosquitto_pub -h mqtt.example.com -t "topic/test" -m "test123" -i "bar"
$ mosquitto_pub -h mqtt.example.com -t "topic/test" -m "test123" -i "bar"
$ mosquitto_pub -h mqtt.example.com -t "topic/test" -m "test123" -i "baz"
$ mosquitto_pub -h mqtt.example.com -t "topic/test" -m "test123" -i "baz"Eine Untersuchung des Zugriffsprotokolls zeigt, dass die ClientId foo immer eine Verbindung zu node1 (Port 18831) herstellt, die ClientId bar immer eine Verbindung zu node2 (Port 18832) herstellt und die ClientId baz immer eine Verbindung zu node3 (Port 18833) herstellt.
$ tail /var/log/nginx/mqtt_access.log192.168.91.1 [23/Mar/2017:12:24:24 +0000] TCP 200 23 4 127.0.0.1:18831 foo
192.168.91.1 [23/Mar/2017:12:24:28 +0000] TCP 200 23 4 127.0.0.1:18832 bar
192.168.91.1 [23/Mar/2017:12:24:32 +0000] TCP 200 23 4 127.0.0.1:18833 baz
192.168.91.1 [23/Mar/2017:12:24:35 +0000] TCP 200 23 4 127.0.0.1:18831 foo
192.168.91.1 [23/Mar/2017:12:24:37 +0000] TCP 200 23 4 127.0.0.1:18831 foo
192.168.91.1 [23/Mar/2017:12:24:38 +0000] TCP 200 23 4 127.0.0.1:18831 foo
192.168.91.1 [23/Mar/2017:12:24:42 +0000] TCP 200 23 4 127.0.0.1:18832 bar
192.168.91.1 [23/Mar/2017:12:24:44 +0000] TCP 200 23 4 127.0.0.1:18832 bar
192.168.91.1 [23/Mar/2017:12:24:47 +0000] TCP 200 23 4 127.0.0.1:18833 baz
192.168.91.1 [23/Mar/2017:12:24:48 +0000] TCP 200 23 4 127.0.0.1:18833 bazEin weiterer Vorteil besteht darin, dass die MQTT-ClientId unabhängig davon, ob wir Sitzungspersistenz oder einen anderen Lastverteilungsalgorithmus verwenden, in den Zugriffsprotokollzeilen erscheint.
Fazit
In diesem ersten Beitrag einer zweiteiligen Serie haben wir gezeigt, wie NGINX Plus mithilfe aktiver Zustandsprüfungen die Verfügbarkeit und Zuverlässigkeit von IoT-Anwendungen verbessert und wie NGINX JavaScript NGINX Plus um eine Layer-7-Lastverteilungsfunktion wie Sitzungspersistenz für TCP-Datenverkehr erweitern kann. Im zweiten Teil untersuchen wir, wie NGINX Plus Ihre IoT-Anwendungen sicherer machen kann, indem es die TLS-Terminierung übernimmt und Clients authentifiziert.
In Kombination mit NGINX JavaScript oder auch eigenständig ist NGINX Plus dank seiner hohen Leistung und Effizienz ideal als Software-Load-Balancer für Ihre IoT-Infrastruktur geeignet.
Wenn Sie NGINX JavaScript mit NGINX Plus ausprobieren möchten, starten Sie Ihre kostenlose 30-Tage-Testversion oder kontaktieren Sie uns, um Ihre Anwendungsfälle zu besprechen.
Anhänge
Erstellen der Testumgebung
Wir haben die Testumgebung auf einer virtuellen Maschine installiert, damit sie isoliert und reproduzierbar ist. Sie können sie jedoch ebenso auf einem physischen „Bare-Metal“-Server installieren.
NGINX Plus installieren
Lesen Sie die Anweisungen im NGINX Plus-Administratorhandbuch.
HiveMQ installieren
Es kann jeder beliebige MQTT-Server verwendet werden, diese Testumgebung basiert jedoch auf HiveMQ (hier herunterladen). In diesem Beispiel installieren wir HiveMQ auf einem einzelnen Host und verwenden für jeden Knoten einen eigenen Docker-Container. Die folgenden Anweisungen basieren auf Bereitstellen von HiveMQ mit Docker.
- Erstellen Sie im selben Verzeichnis wie hivemq.zip eine Dockerfile für HiveMQ.
Codebeispiel wird geladen…
- Erstellen Sie in dem Verzeichnis, das hivemq.zip und das Dockerfile enthält, das Docker-Image.
$ docker build -t hivemq:latest .- Erstellen Sie drei HiveMQ-Knoten, die jeweils über einen anderen Port erreichbar sind.
$ docker run -p 18831:1883 -d --name node1 hivemq:latest
ff2c012c595a
$ docker run -p 18832:1883 -d --name node2 hivemq:latest
47992b1f4910
$ docker run -p 18833:1883 -d --name node3 hivemq:latest
17303b900b64- Überprüfen Sie, ob alle drei HiveMQ-Knoten ausgeführt werden. (In der folgenden Beispielausgabe wurden die Spalten „
COMMAND“, „CREATED“ und „STATUS“ der besseren Lesbarkeit halber weggelassen.)
$ docker psCONTAINER ID IMAGE ... PORTS NAMES
17303b900b64 hivemq:latest ... 0.0.0.0:18833->1883/tcp node3
47992b1f4910 hivemq:latest ... 0.0.0.0:18832->1883/tcp node2
ff2c012c595a hivemq:latest ... 0.0.0.0:18831->1883/tcp node1Mosquitto installieren
Der Mosquitto-Kommandozeilenclient kann von der Projektwebsite heruntergeladen werden. Mac-Nutzer, die Homebrew installiert haben, können den folgenden Befehl ausführen.
$ brew install mosquittoTesten Sie den Mosquitto-Client und die HiveMQ-Installation, indem Sie eine einfache Publish-Nachricht an eines der Docker-Images senden.
$ mosquitto_pub -d -h mqtt.example.com -t "topic/test" -m "test123" -i "thing001" -p 18831
Client thing001 sending CONNECT
Client thing001 received CONNACK
Client thing001 sending PUBLISH (d0, q0, r0, m1, 'topic/test', ... (7 bytes))
Client thing001 sending DISCONNECT[ngx_snippet name=’njs-enable-instructions’]
Über den Autor
Ähnliche Blogbeiträge
Die Zukunft von NGINX: Zurück zu unseren Open-Source-Wurzeln
Beim NGINX Sprint 2022 besinnen wir uns auf unsere Open-Source-Wurzeln. Erfahren Sie mehr über die Initiativen, die wir im kommenden Jahr verfolgen, und teilen Sie uns mit, was Sie sich wünschen.
Ein Leitfaden zur Auswahl eines Ingress-Controllers, Teil 1: Ermitteln Sie Ihre Anforderungen
Ein Ingress-Controller kann eines der leistungsstärksten Tools in Ihrem Kubernetes-Stack sein. Erfahren Sie, wie Sie Ihre Ingress-Anforderungen ermitteln, um die beste Option auszuwählen.
Bereitstellung des NGINX Ingress Controllers auf Amazon EKS: So haben wir getestet
Wir haben kürzlich den Lösungsleitfaden zum NGINX Ingress Controller um Empfehlungen zur Dimensionierung für Amazon Elastic Kubernetes Service (EKS) ergänzt. In diesem Blogbeitrag erläutern wir, wie wir diese Empfehlungen erarbeitet haben, und stellen Ihnen alle Informationen zur Verfügung, die Sie benötigen, um selbst ähnliche Tests durchzuführen.
Protokollierung des Datenverkehrs zwischen NGINX und Upstream-Servern bei CDN77
Bei der Fehlersuche bei Datenverkehrsproblemen zwischen NGINX und Upstream-Servern konnte CDN77 die benötigten Daten nur aus dem Fehlerprotokoll mit aktivierter Debug-Ausgabe beziehen, was die Leistung beeinträchtigt und riesige Dateien erzeugt. Daher entwickelte das Team ein neues benutzerdefiniertes Modul, das ausschließlich die benötigten Daten protokolliert.
Ankündigung von NGINX Plus R16
NGINX Plus R16 ist eine einheitliche, elastische Ingress- und Egress-Schicht für Anwendungen, die die Funktionen eines Load Balancers, API-Gateways und einer WAF vereint und neue Features wie clusterfähige Ratenbegrenzung, Schlüssel-Wert-Speicher, „Random with Two Choices“, verbessertes UDP-Load-Balancing und vieles mehr bietet.
5 Gründe für den Umstieg auf softwarebasiertes Load Balancing
Entdecken Sie fünf Gründe für den Wechsel zu einem softwarebasierten Load Balancer wie NGINX Plus, darunter Kosteneinsparungen, die Einführung von DevOps und eine einheitliche Lösung für alle Umgebungen.