Internet der Dinge: Hochverfügbare Anwendungen mit MQTT

Inhaltsverzeichnis

Wie schnell IoT im Alltag angekommen ist, zeigen die Mobilitätsangebote von Tier, Bolt und anderen Anbietern. Etwa 500.000 E-Scooter und Fahrräder sollen in europäischen Städten auf den Straßen verfügbar sein, die Interessierte per App finden und ausleihen können.

Der Anbieter Bolt konnte nach eigenen Angaben die Anzahl der Fahrten im Jahr 2021 gegenüber dem Vorjahr um 400 Prozent steigern (Bolt Safety Report 2022). Solche Roller oder Fahrräder sind informationstechnisch vernetzt und melden unter anderem ihren Batterieladezustand und Standort an zentrale Stellen. Diese Funktionen nutzen das IoT-Standardprotokoll MQTT.

Weitere Einsatzbereiche für MQTT sind Smart Buildings, intelligente Straßenbeleuchtung oder Parkplatz-Statusinformationen. Die Zahl der IoT-Anwendungen für die Grundversorgung wächst stetig. Das erfordert eine nahezu hundertprozentige Verfügbarkeit, analog zu digitalen Diensten wie Online-Banking, Messenger-Anwendungen oder kontaktlosem Zahlungsverkehr.

Anforderung Hochverfügbarkeit

Der Ausdruck Hochverfügbarkeit (High Availability, HA) hat sich zur Standardanforderung für den Betrieb kritischer Systeme entwickelt. Die oft verwendete Bezeichnung Four-Nines-Verfügbarkeit steht für eine Verfügbarkeit von 99,99 Prozent. Für Cloud-Infrastruktur-Anbieter wie Amazon Web Services oder Microsoft Azure sind derart spezifizierte Verfügbarkeiten Teil der Vertragsunterlagen.

Die Heise-Konferenz zum IoT

Am 26. und 27. April findet die achte Auflage der building IoT 2023 in München statt. Die Fachkonferenz richtet sich an diejenigen, die Anwendungen und Produkte für das Internet der Dinge erstellen.

In diesem Jahr steht das Thema IIoT noch stärker im Fokus als in den vergangenen Jahren. Das Programm bietet unter anderem Vorträge zur Datenanalyse für das IIoT, Zeitreihendatenbanken, sicheres Edge-Computing mit Kubernetes und EU-Normen für Cybersecurity.

Um eine Four-Nines-Verfügbarkeit zu verdeutlichen, kann man grob eine zu akzeptierende Unterbrechung von etwa fünfzig Minuten pro Betriebsjahr annehmen. Der HA-Ansatz ermöglicht somit aus Nutzersicht einen unterbrechungsfreien und konsistenten Betrieb von Diensten. Das bedeutet im IoT-Fall vor allem den Informationsaustausch über das MQTT-Protokoll.

Herausforderungen für MQTT-Broker

Das Bereitstellen von Daten oder Webseiten ist im Sinne der Verfügbarkeit durch Zonenreplikation, Lastausgleich und automatische Skalierung Stand der Technik. Will man MQTT-Brokern jedoch hochverfügbar machen, sind protokollspezifische Eigenschaften zu berücksichtigen. Es ist eine wesentliche Grundlage des Protokolls, dass die Verbindung zwischen Broker und Client anders als bei Webseitenanfragen dauerhaft aufrechterhalten bleibt. Weiterhin speichern die Broker die Informationen, die beim Verbindungsaufbau und während der Verbindung entstehen, als Session-Informationen oder kurz Sessions. Diese enthalten unter anderem die Informationen zu den Topics, die Clients abonniert haben (Subscriptions), Nachrichten, die sich in der Warteschlange befinden (Queued Messages) und die Information zum letzten Willen (Last Will) für den Fall, dass ein System nicht mehr erreichbar ist.

Ferner ermöglicht das Protokoll, zurückgehaltene Nachrichten (Retained Messages) im Broker zu hinterlegen. Solche Nachrichten müssen zusammen mit den client-spezifischen Sessions im Fall eines Verbindungsabbruchs, Broker-Fehlers oder Netzwerk-Routenwechsels persistent zur Verfügung stehen.

Folglich muss ein HA-MQTT-Dienst im Falle einer Störung die folgenden Funktionen durchgängig und mindestens mit einer Verfügbarkeit von beispielsweise 99,99 Prozent, sicherstellen:

• Wiederaufnehmen der unterbrochenen Client-Broker-Verbindung: Der MQTT-Broker kennt die Autorisierung (Access Control Lists) und Authentifizierung (Credentials und gegebenenfalls TLS Session) der Clients.
• Der Broker muss Themenabonnements (Subscriptions) und noch nicht zugestellte Nachrichten in der Warteschlange (Queued Messages mit QoS > 0) des Clients bereitstellen beziehungsweise senden.
• Er muss aufbewahrte Nachrichten (Retained Messages inklusive Last Will) bereithalten beziehungsweise senden.

Zusammengefasst handelt es sich um client- und verbindungsspezifische persistente Daten.

Skalierbarkeit ist nicht gleich Hochverfügbarkeit

Um HA-Dienste umzusetzen, replizieren Unternehmen typischerweise virtuelle Maschinen oder Container (Nodes) mit identischen Applikationen in Clustern, die sie in unterschiedlichen Verfügbarkeitszonen betreiben. Infrastrukturanbieter bieten in der Region Central Europe in der Regel drei Verfügbarkeitszonen an. Eine Zone ist ein physisch separiertes Rechenzentrum innerhalb einer Region. Ein zonenredundanter Load Balancer sorgt für die Erreichbarkeit und die gleichmäßige Auslastung der einzelnen Nodes über Zonengrenzen hinweg. Aus Sicht des Clients ist stets ein identischer öffentlicher Endpunkt erreichbar. Replikationsregeln und eine Skalierungsregel (Auto Scaling) passen die Anzahl der Nodes an. Meist legen die Betreiber eine Mindest- und eine Maximalanzahl fest.

Regelgrößen für die Skalierung sind im Wesentlichen die Zahl der Verbindungen oder die Last an einzelnen Nodes. Statusinformationen (Healthiness Probes) und zyklisch gesendete Lebenszeichen (Heartbeats) sorgen dafür, dass man die einzelnen Nodes überwachen und bei einem Ausfall oder Überlastung durch die Replikationen ersetzen kann. Alle Nodes sind zonenunabhängig Teil eines gemeinsamen virtuellen Netzwerks.

Diese Aufstellung kann eine gleichbleibende hohe Performance garantieren, die weitgehend unabhängig davon ist, ob es zehn, tausend oder eine Million Clientanfragen gibt. Solche Architekturen sorgen theoretisch für eine Verfügbarkeit von Five Nines. Allerdings gilt dabei die Annahme, dass die einzelnen Nodes als Einzelgänger agieren und sich im Fehlerfall durch neu gestartete Replikate im Cluster ersetzen lassen. Es müssen keine Daten zwischen Nodes ausgetauscht werden.

Im Gegensatz dazu genügt es für einen hochverfügbaren MQTT-Broker jedoch nicht, ein oder mehrere Replikate des Brokers bereitzustellen, da die protokollspezifischen Funktionen stets erfüllt sein müssen. Das bedeutet insbesondere, dass beim Ersetzen eines ausgefallenen Knotens die client- und verbindungsspezifischen persistenten Daten verfügbar sein müssen, um die Verbindung wiederaufzunehmen. Um das sicherzustellen, kann man erstens eine feste Zahl von Replikaten statt Auto Scaling verwenden. Zweitens lässt sich eine zusätzliche Kommunikation zwischen den Nodes einrichten, die stets die persistenten Daten synchronisiert, um alle Broker mit dem MQTT-Active-Active-Cluster-Konzept auf demselben Stand zu halten.