Load Balancing – MQTT-Broker-Clustering Teil 1

Dieser Beitrag gibt eine kurze Einführung in MQTT Message Broking, die Herausforderungen des Clustering und dann den Lastausgleich.

MQTT das Protokoll

Vielleicht sind Sie mit dem MQTT-Protokoll nicht so vertraut, Sie kennen das HTTP-Protokoll wahrscheinlich sehr gut. Wie HTTP arbeitet MQTT auf derselben Netzwerk-(Transport-)Schicht TCP/TLS (nun, es kann tatsächlich auf HTTP funktionieren, aber das ist ein Thema für einen anderen Tag).

Hier ist das Zitat von

MQTT ist ein OASIS-Standard-Messaging-Protokoll für das Internet der Dinge (IoT). Es ist als extrem leichter Publish/Subscribe-Messaging-Transport konzipiert, der sich ideal für die Verbindung von Remote-Geräten mit geringem Code-Footprint und minimaler Netzwerkbandbreite eignet. MQTT wird heute in einer Vielzahl von Branchen eingesetzt, wie z. B. Automobil, Fertigung, Telekommunikation, Öl und Gas usw.

MQTT-Clients ähneln auch HTTP-Clients: Sie bauen TCP-Verbindungen zu einem Server auf und senden und empfangen Daten. Der Unterschied besteht darin, dass HTTP ein Request/Response-Modell verwendet, während MQTT ein Publish/Subscribe-Modell verwendet.

Ein Beispiel aus der Praxis: Ein Temperatursensor im Wohnzimmer sendet seine Messwerte periodisch an eine MQTT-Broker, kann eine Smart-Home-Anwendung die Temperaturmesswerte abonnieren und Smart-Home-Entscheidungen für Sie treffen. Zum Beispiel: Schalten Sie die Klimaanlage ein, wenn es über 32 Grad Celsius ist.

Die Skalierbarkeitsherausforderungen

Ein Temperatursensor zu Hause ist nur ein Beispiel, das jedem nahe genug ist. Um Smart-Home-Geräte zu bedienen, sollte ein einzelner MQTT-Broker, z. B. EMQX Edge Edition, der auf einem Raspberry PI läuft, mehr als ausreichen, ganz zu schweigen davon, dass ein einzelner EMQX-Knoten bis zu 2 Millionen Verbindungen verarbeiten kann.

Stellen Sie sich nun diese Beispiele vor: Millionen von Autos auf der ganzen Welt; Millionen von Straßenlaternen im ganzen Land; und so weiter und so weiter, die Anzahl der Geräte (MQTT-Clients) und das Datenvolumen können sehr groß sein, groß genug, um jeden einzelnen MQTT-Broker zu überwältigen.

Dies ist einer der Gründe, warum wir einen Cluster von MQTT-Brokern erstellen müssen. Aber es schafft auch mehr Herausforderungen wie:

  • MQTT-Broker-Erkennung: Wie sollen Clients wissen, mit welchem ​​Broker-Endpunkt sie sich verbinden müssen;
  • MQTT-Abonnentensitzungsübernahme, falls ein Client die Verbindung zu einem Knoten trennt und sich wieder mit einem anderen verbindet;
  • Die globale Routing-Tabelle muss konsistent von allen Knoten im Cluster gemeinsam genutzt werden

Die ersten beiden Herausforderungen können gut angegangen werden, indem ein Load Balancer vor dem Cluster platziert wird.

MQTT-Load-Balancing

MQTT-Lastenausgleich

MQTT-Lastenausgleich

Um die oben genannten Herausforderungen zu meistern, sollte ein Load Balancer in der Lage sein, Kunden bei der Entscheidung zu helfen, welchen Broker sie basierend auf konfigurierten Ausgleichsstrategien verbinden möchten. Die Hauptfunktionen eines Load Balancers für MQTT-Broker-Cluster sind:

  • Erkennung von Broker-Endpunkten. Die Clients müssen sich nur um die Adresse des Load Balancers kümmern, nicht aber um die einzelnen Broker. Dies schafft auch die Flexibilität für Broker, umzuziehen, zu vergrößern oder zu verkleinern.
  • TLS-Beendigung. Viele Benutzer von MQTT-Brokern entscheiden sich dafür, TLS im LB zu terminieren, sodass die Ressourcen in Brokern gut für die Nachrichtenverarbeitung reserviert werden können.
  • Verteilen Sie die Last gleichmäßig auf die Broker. Load Balancer sind in der Regel für Ausgleichsstrategien konfigurierbar, wie z. B. Random, Round-Robin (mit verschiedenen gewichteten Versionen) und am interessantesten: Sticky Dispatch.

Da MQTT ein Protokoll auf TCP/IP ist, kann der Lastausgleich auf der Transportschicht erfolgen. Tatsächlich arbeiten die meisten Load-Balancing-Produkte heute (August 2021) im Gegensatz zu vielen verschiedenen Möglichkeiten, die wir bei HTTP haben, immer noch auf der Transportschicht. Zum Beispiel AWS NLB, Nginx und HAProxy.

Zusätzlich zum Load-Balancing der Transportschicht bieten HAProxy 2.4 und NGINX plus auch MQTT-Load-Balancing auf Anwendungsebene.

NGINX Plus ist eine Anwendungsbereitstellungsplattform, die auf NGINX, einem Open-Source-Webserver und Reverse-Proxy für stark frequentierte Websites, aufbaut. Dieser Artikelvon Nginx Plus gibt eine schöne Einführung in seine MQTT-Load-Balancing-Lösung.

Ebenso hervorragend wie NGINX ist HAProxy eine kostenlose Open-Source-Software, die einen hochverfügbaren Load Balancer und Proxy-Server für TCP- und HTTP-basierte Anwendungen (und jetzt auch MQTT) bietet. Ab August 2021 ist HAProxy der einzige kostenlose Load-Balancer, der das MQTT-Protokoll kennt. Es gibt eine kurze Einführung in die Funktion in ihrem Veröffentlichungshinweis.

Im nächsten Beitrag der Serie „MQTT-Broker-Clustering“ werden wir HAProxy 2.4 + EMQX 4.3 verwenden, um eine vollständige Bereitstellung detaillierter zu demonstrieren.

Ursprünglich erschienen bei

Similar Posts

Leave a Reply

Your email address will not be published. Required fields are marked *