Installation einer hochverfügbaren, geclusterten MQTT bridge (Teil 1)

MQTT ist ein TCP-basiertes Client/Server Protokoll nach Publish/Subscriber Muster. Die clients können sich auf einen zentralen MQTT Server (Broker genannt) subscriben bzw. Daten auf diesen Broker publishen. Das subscriben sowie publishen funktioniert dabei auf der Ebene eines "Topics" - im Wesentlichen vorstellbar wie ein Adressfach eines Brokers. Jede Nachricht die auf ein bestimmtes Topic gepublished wird, wird automatisch an alle Clients weitergeleitet, die sich auf eben jenes Topic subscribed haben.

Das Protokoll zeichnet sich dabei durch seine Offenheit, leichtgewichtige Implementierung und Einfachheit aus - was es speziell auf ressourcenbeschränkten Systemen und in instabilen/high-latency Netzwerkumgebungen sehr beliebt macht. MQTT ist darüber hinaus ein sehr skalierfähiges Protokoll: ein MQTT Broker kann ohne weiteres mehrere Millionen Client-Verbindungen verwalten und bedienen.

Nicht zuletzt aus diesen Gründen hat sich MQTT als de-facto-standard für M2M Kommunikation und IoT/IIoT gemausert. In diesen beiden Anwendungsfeldern sind genau jene Anforderungen zu finden, die von MQTT ideal abgedeckt werden:

• Schlechte, instabile Netzwerkumgebungen
• Hohes Datenaufkommen
• Potentiell viele Clients
• Tendenziell ressourcenbeschränkte Systeme

Aufgrund der weiten Verbreitung von MQTT sind im Netz zahlreiche Tutorials zur Auswahl und Installation geeigneter MQTT-Infrastruktur vorhanden. Ein Teilaspekt der jedoch nach wie vor recht stiefmütterlich behandelt und beschrieben ist, ist jener der MQTT Bridge.

Was ist eine MQTT Bridge?

Eine MQTT Bridge erlaubt - vereinfacht ausgedrückt - die Verbindung zweier MQTT Broker. Einer der Broker (local broker) stellt dabei seinerseits einen MQTT Client dar, der sich auf ein Topic eines zweiten (remote broker) Brokers subscribed. Somit werden alle Nachrichten, die am remote Broker aufschlagen, an den local Broker weitergeleitet. Am local Broker können dann wiederum weitere MQTT Clients subscribed sein, die diese Nachrichten dann konsumieren.

Fig.: Schematische Darstellung einer MQTT Bridge

MQTT Bridges können dabei bidirektional konfiguriert werden - somit kann der og. local Bridge-Client Nachrichten auch direkt an den remote Broker weiterleiten - ohne dass dieser eine subscription auf den local Broker umsetzen muss.

Wozu eine MQTT Bridge konfigurieren?

MQTT Bridges sind immer dann sinnvoll, wenn zwei eigentlich getrennte Messaging-Systeme miteinander verbunden werden sollen. Ein sehr verbreitetes Szenario ist dabei die Weiterleitung von an der IoT-Edge generierten Nachrichten in ein oder mehrere Cloud-Systeme. Ein zentraler MQTT Broker wird dabei direkt an der Edge (z.B. in der Produktionshalle eines produzierenden Unternehmens) installiert - alle IIoT-Teilnehmer wie Maschinen und Sensoren publishen auf diesen Broker. Gleichzeitig subscriben sich lokale Datensysteme (wie SCADA-Systeme oder Edge-Analytics-Lösungen) auf Topics an diesem Broker - somit ist ein in sich geschlossenes Edge IIoT Messaging System skizziert. Gleichzeitig sollen diese Daten nun in das firmeneigene IIoT Cloud System sowie in einen unternehmensinternen Data Lake weitergeleitet werden.

Da alle drei Systeme (Edge System, Cloud System und Data Lake) unterschiedliche Einsatzzwecke haben, ist es architektonisch sinnvoll, diese bestmöglich voneinander zu trennen und definierte Interfaces zu implementieren. Dafür bietet es sich an, das Cloud System sowie das Data-Lake-System mit eigenen MQTT-Brokern auszustatten. Der Broker des Edge-Systems wird dann über den MQTT-Bridge-Mechanismus mit dem Data-Lake und dem Cloud-System verbunden.

Fig.: Verbindung mehrerer Daten-Systeme via MQTT Bridge

Die so umgesetzte Architektur bietet folgende Vorteile:

• Klare Trennung der einzelnen System - verbunden durch ein definiertes Interface
• Lediglich das Edge-System muss die Zielsysteme kennen, nicht jedoch umgekehrt
• Einfach zu implementieren
• Günstig und wartungsfreundlich
• Erweiterbar oder reduzierbar (Es können sehr einfach weitere Edge Systeme oder Ziel-Systeme angebunden werden)
• Hochverfügbar und skalierbar (bei entsprechend korrekter Implementierung)

Eine abgewandelte Form des hier beschriebenen Use-Cases ist die Verteilung von Daten an diverse Backend-Systeme. Über die gezielte Konfiguration einer zentralen MQTT-Bridge können die einkommenden Daten aller MQTT Clients an verschiedenste Backend/Ziel-Systeme feingranular auf Topic-Ebene weitergeleitet werden. Es können somit alle datenerzeugenden MQTT-Clients einen zentralen Broker als Ansprechpartner konfigurieren, dieser nimmt dann die Verteilung der Daten an die richtigen Zielsysteme vor. Da MQTT-Bridges optional bidirektional sind, können die Zielsysteme darüber hinaus über die MQTT-Bridge mit den Clients kommunizieren - um beispielsweise Updates oder Konfigurationsänderungen durchzuführen.

Die hier vorgestellte Architektur vereinfacht die Konfiguration der MQTT Clients sowie die Firewall-Einstellung der Clients drastisch - da alle Clients ein- und dieselben MQTT-Konfigurationen umsetzen können - unabhängig davon, wohin die Daten übermittelt werden sollen. Die Komplexität wird auf eine zentrale MQTT Bridge verlagert.

Fig.: Datenweiterleitung mittels MQTT Bridge

Nicht unerwähnt bleiben soll, dass diese Vorgehensweise einen gravierenden Nachteil aufweist: Wenn die zentrale MQTT Bridge ausfällt, erliegt der komplette Datenfluss. Es ist somit von äußerster Wichtigkeit, diese Komponente hochverfügbar und skalierbar umzusetzen.

Im nächsten Teil dieser Tutorial-Reihe werde ich Sie Schritt für Schritt durch den Auswahlprozess als auch die Erstinstallation einer MQTT-Bridge-Technologie führen. Ich werde den Guide dabei auf den letztgenannten Use-Case fokussieren, da dieser einerseits komplexer umzusetzen und mit nur wenigen Konfigurationsänderungen auf den erstgenannten Use-Case änderbar ist.