MQTT-Broker Hochverfügbarkeit: Konzepte und Fragen

Bei der Hochverfügbarkeit eines MQTT-Brokers geht es darum, dass Geräte und Anwendungen weiter kommunizieren, wenn ein Teil des Systems ausfällt, und sie hängt ebenso sehr von Ihren Clients ab wie vom Broker. Dieser Artikel erklärt die zentralen Konzepte, was während eines Failovers tatsächlich mit Sitzungen und Nachrichten passiert, wie Sie Clients entwerfen, die sich sauber erholen, und welche Fragen Sie jedem Anbieter stellen sollten, ConnectMQ eingeschlossen, bevor Sie sich auf ihn verlassen.

Was Hochverfügbarkeit für MQTT bedeutet

Allgemein bedeutet Hochverfügbarkeit in der Infrastruktur, ein System so zu gestalten, dass der Ausfall einer Komponente nicht den gesamten Dienst für längere Zeit lahmlegt. Bei einem MQTT-Broker zerfällt das in drei separate Fragen:

Können sich Clients schnell wieder verbinden? Wenn Broker-Prozess, Maschine oder Netzwerkpfad ausfallen, wie lange dauert es, bis sich Geräte wieder verbinden können?
Was passiert mit dem Sitzungszustand? Bleiben Subscriptions und gepufferte QoS-1- und QoS-2-Nachrichten für Offline-Clients über den Ausfall hinweg erhalten?
Was passiert mit Nachrichten in Zustellung? Gehen Nachrichten, die angenommen, aber noch nicht zugestellt wurden, verloren, werden sie einmal oder zweimal zugestellt?

Diese Fragen haben je nach Architektur unterschiedliche Antworten, und ein Anbieter, der bei der ersten hervorragend ist, macht zur dritten womöglich gar kein Versprechen. Seien Sie präzise darin, was Sie brauchen.

Gängige Hochverfügbarkeitsarchitekturen

Muster	Funktionsweise	Was einen Knotenausfall übersteht	Abwägungen
Einzelner Knoten mit schnellem Neustart	Ein Broker, der bei Ausfall automatisch neu gestartet oder ersetzt wird	Konnektivität nach dem Neustart; Zustand hängt von der Persistenz ab	Einfach; kurzer Ausfall während des Neustarts
Aktiv-passiv	Ein Standby übernimmt, wenn der Primärknoten ausfällt	Konnektivität; Zustand nur bei Replikation oder gemeinsamem Speicher	Standby-Kapazität liegt brach
Cluster, aktiv-aktiv	Mehrere Knoten bedienen Clients und leiten Nachrichten untereinander weiter	Konnektivität; Zustand, wenn der Cluster ihn repliziert	Komplexer; Koordinationsaufwand zwischen Knoten
Partitionierte Broker	Unabhängige Broker pro Standort, Mandant oder Region	Nur die ausgefallene Partition ist betroffen	Kein gemeinsamer globaler Topic-Raum
Clientseitiges Failover	Clients kennen einen primären und einen sekundären Endpunkt	Konnektivität, sofern der sekundäre gesund ist	Zustand wird zwischen den beiden Brokern nicht geteilt

Keines davon ist allgemein das beste. Viele zuverlässige IoT-Systeme setzen auf einen einzelnen, gut betriebenen Broker pro Partition plus robuste Clients, denn die einfachste Architektur hat die wenigsten Möglichkeiten zu versagen.

In der Fertigung folgt die Partitionierung oft der ISA-95-Hierarchie: Jedes Werk betreibt seinen eigenen Broker, der den Teilbaum acme/werk-stuttgart/... des Unified Namespace (UNS) trägt, und nur ausgewählte, verdichtete Daten werden an eine Ebene für das gesamte Unternehmen weitergereicht. Fällt ein Werks-Broker aus, laufen die anderen Standorte weiter, und die Topic-Struktur aus Enterprise, Site, Area, Line und Cell bleibt trotzdem einheitlich. Mehr zum UNS-Konzept lesen Sie im Beitrag Sparkplug B und Unified Namespace.

Wo ein verwalteter MQTT-Broker hineinpasst

Hier lohnt sich Offenheit. ConnectMQ bietet kein Clustering mit Nachrichtenreplikation, und Sitzungen sowie gepufferte Nachrichten werden über Broker-Neustarts hinweg nicht persistiert. Sie sollten Clients daher so entwerfen, dass sie einen Broker-Neustart verkraften, indem sie sich neu verbinden, neu abonnieren und alles Wichtige erneut publizieren, was ohnehin auf jedem Broker gute Praxis ist.

Für die Verfügbarkeitsplanung bietet ConnectMQ stattdessen die Wahl des Bereitstellungsmodells. Ein Dedicated-Plan gibt Ihnen einen isolierten Cluster, sodass der Traffic anderer Mandanten Ihren nicht beeinflussen kann. BYOC betreibt den Broker in Ihrem eigenen Cloud-Konto, verwaltet von ConnectMQ, sodass er innerhalb der Infrastruktur-, Netzwerk- und Regionsentscheidungen liegt, die Sie bereits kontrollieren. Wenn Sie ein bestimmtes Verfügbarkeitsziel brauchen, besprechen Sie es für eine Dedicated- oder BYOC-Bereitstellung mit dem Team, statt eine Zahl vorauszusetzen.

Was während eines Failovers passiert

Wenn ein Broker neu startet oder ein Client auf einen anderen Knoten verschoben wird, sieht der typische Ablauf so aus:

Die TCP-Verbindung bricht ab. Der Client bemerkt es sofort oder nach seinem Keepalive-Intervall.
Andere Subscriber erhalten die Last-Will-Nachricht, sofern der Broker sie vor dem Ausfall verarbeitet, oder später ein Status-Update.
Der Client verbindet sich mit Backoff neu.
Hat der Broker die Sitzung noch, meldet CONNACK „Session Present“, und die Subscriptions sind intakt. Wenn nicht, beginnt der Client mit einer sauberen Sitzung und muss neu abonnieren.
Nachrichten, die publiziert wurden, während der Client offline war, werden nur zugestellt, wenn der Broker sie aufbewahrt hat; andernfalls sind sie weg.

Die praktische Schlussfolgerung: Gehen Sie nie davon aus, dass Schritt 4 „Session Present“ meldet. Abonnieren Sie bei jeder Verbindung neu und halten Sie alles, was Sie nicht verlieren dürfen, auf dem Client, bis es bestätigt ist.

Clients für Hochverfügbarkeit entwerfen

Robuste Clients machen aus einem Broker-Failover statt eines Incidents nur ein kurzes Flackern. Die folgenden Muster funktionieren auf jedem Broker.

Bei jeder Verbindung neu abonnieren

Legen Sie Subscriptions in den Connect-Callback, nicht in den Startcode, damit sie nach jedem Reconnect unabhängig vom Sitzungszustand wiederhergestellt werden.

Lokal puffern bis zur Bestätigung

Halten Sie für wichtige Daten eine lokale Warteschlange vor und entfernen Sie einen Eintrag erst, wenn der Broker einen QoS-1-Publish bestätigt hat. Unser Leitfaden zu Store-and-Forward mit MQTT behandelt persistente Puffer auf Gateways.

Zwischen Endpunkten umschalten

Wenn Sie mehr als einen Broker betreiben, etwa zwei unabhängige Bereitstellungen an verschiedenen Standorten, kann der Client zwischen ihnen rotieren. Hier ist ein minimales Python-Beispiel mit paho-mqtt 2.x, das Endpunkte rotiert, bei jeder Verbindung neu abonniert und unbestätigte Nachrichten im Speicher hält.

import json
import random
import threading
import time

import paho.mqtt.client as mqtt

ENDPOINTS = [("broker.connectmq.com", 8883), ("YOUR_SECONDARY_HOST", 8883)]
BASE = "acme/site1/line1/gw-01"
pending = {}              # mid -> (topic, payload), wird bei Bestätigung entfernt
lock = threading.Lock()

def send(client, topic, payload):
    with lock:
        info = client.publish(topic, payload, qos=1)
        pending[info.mid] = (topic, payload)

def on_connect(client, userdata, flags, reason_code, properties):
    if reason_code.is_failure:
        print("refused:", reason_code)
        return
    print("connected; session present:", flags.session_present)
    client.subscribe(f"{BASE}/cmd/#", qos=1)           # immer neu abonnieren
    client.publish(f"{BASE}/status", "online", qos=1, retain=True)
    with lock:
        unacked = list(pending.values())
        pending.clear()
    for topic, payload in unacked:                       # unbestätigte Daten erneut senden
        send(client, topic, payload)

def on_publish(client, userdata, mid, reason_code, properties):
    with lock:
        pending.pop(mid, None)

def on_message(client, userdata, msg):
    print("command:", msg.topic, msg.payload.decode())

client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2,
                     client_id="YOUR_CLIENT_ID", protocol=mqtt.MQTTv5)
client.username_pw_set("YOUR_USERNAME", "YOUR_PASSWORD")
client.tls_set()
client.will_set(f"{BASE}/status", "offline", qos=1, retain=True)
client.on_connect = on_connect
client.on_publish = on_publish
client.on_message = on_message

index, delay = 0, 1
while True:
    host, port = ENDPOINTS[index % len(ENDPOINTS)]
    try:
        client.connect(host, port, keepalive=30)
    except OSError as exc:
        print(f"{host} unreachable: {exc}")
        index += 1
        time.sleep(delay + random.random())              # Backoff mit Jitter
        delay = min(delay * 2, 60)
        continue
    delay = 1
    client.loop_start()
    time.sleep(2)                                        # auf CONNACK warten
    while client.is_connected():
        reading = json.dumps({"ts": int(time.time()), "rpm": 1480})
        send(client, f"{BASE}/telemetry", reading)
        time.sleep(5)
    client.loop_stop()
    print(f"lost {host}, trying the next endpoint")
    index += 1

In der Produktion würden Sie pending auf die Festplatte schreiben und seine Größe begrenzen, die Struktur bleibt aber dieselbe. Da QoS 1 Duplikate zulässt, sollten Empfänger tolerieren, dass eine Nachricht nach einem Failover zweimal ankommt. Beachten Sie, dass jeder Endpunkt Zugangsdaten braucht, die für diesen Broker gültig sind.

Befehle idempotent machen

Nach einem Failover kann ein QoS-1-Befehl zweimal ankommen. Fügen Sie eine Befehls-ID hinzu und ignorieren Sie Duplikate auf dem Gerät.

Zustand erneut publizieren, statt sich auf den Broker zu verlassen

Retained-Status- und Konfigurationsnachrichten sind nützlich, doch wenn der Broker ohne Persistenz neu startet, müssen sie erneut publiziert werden. Lassen Sie Geräte ihren Retained-Zustand bei jeder Verbindung erneut publizieren, wie es das Beispiel tut.

Fragen, die Sie jedem MQTT-Anbieter stellen sollten

Nutzen Sie diese Liste in Evaluierungen und Ausschreibungen. Verlangen Sie schriftliche Antworten und werten Sie vage Antworten als „nein“.

Welche Bereitstellungstopologie hat mein Plan: einzelner Knoten, aktiv-passiv oder Cluster?
Werden Sitzungen und gepufferte Nachrichten über einen Broker-Neustart hinweg persistiert?
Werden Nachrichten zwischen Knoten repliziert, bevor sie bestätigt werden?
Wie werden Clients nach einem Ausfall umgeleitet: gleicher Hostname, DNS-Änderung oder neuer Endpunkt?
Wie lange dauert die Wiederherstellung nach einem Knotenausfall typischerweise, und ist sie vertraglich zugesichert?
Gibt es ein veröffentlichtes SLA, was deckt es ab und welche Gutschriften gibt es?
Wie werden Wartung und Upgrades durchgeführt, und werden Clients dabei getrennt?
Wo ist die Statusseite, und wie werden Incidents kommuniziert?
Kann ich eine Bereitstellung an einem zweiten Standort oder in meinem eigenen Cloud-Konto betreiben?
Was passiert mit meinem Workload, wenn sich ein anderer Mandant in einem geteilten Plan fehlerhaft verhält?

Für unseren eigenen Dienst lauten die Antworten auf die Fragen 2 und 3, dass Persistenz über Neustarts und Nachrichtenreplikation nicht angeboten werden; zu SLA-Bedingungen fragen Sie bitte direkt das Team. Unser Artikel zum MQTT-Broker-SLA erklärt, wie man SLA-Formulierungen liest, und die RFP-Checkliste für MQTT-Broker enthält eine längere Evaluierungsliste.

Praktische Hochverfügbarkeitsmuster auf einem verwalteten MQTT-Broker

Kombiniert man die obigen Konzepte, sieht ein realistischer Ansatz für die meisten Teams so aus:

Wählen Sie einen verwalteten MQTT-Broker, damit Patches, TLS und Maschinenausfälle die Aufgabe eines anderen sind.
Nutzen Sie eine Dedicated-Bereitstellung, wenn Sie Isolation von anderen Mandanten brauchen.
Nutzen Sie BYOC, wenn der Broker in Ihrem eigenen Cloud-Konto neben Ihren anderen Systemen laufen soll.
Partitionieren Sie nach Standort (etwa pro Werk im UNS) oder Kunde, wo ein Ausfall nicht alle treffen darf.
Bauen Sie jeden Client mit Neu-Abonnieren bei Verbindung, lokaler Pufferung, idempotenten Befehlen und Backoff mit Jitter.
Überwachen Sie den Verbindungsstatus, etwa über $SYS/broker/connection/{clientId}/state, und alarmieren Sie, wenn Geräte offline gehen.

Zur Kapazität neben der Verfügbarkeit lesen Sie MQTT-Broker skalieren, und für die weitere Hosting-Landschaft den Leitfaden zum Cloud-MQTT-Broker.

Planen Sie Ihre MQTT-Verfügbarkeit mit ConnectMQ

ConnectMQ ist ein verwalteter MQTT-Broker mit den Optionen Serverless, Dedicated und BYOC, sodass Sie das Bereitstellungsmodell wählen können, das zu Ihren Verfügbarkeitsanforderungen passt. Starten Sie kostenlos unter app.connectmq.com ohne Kreditkarte, bauen Sie robuste Clients dagegen und sprechen Sie mit dem Team, wenn Sie eine Dedicated- oder BYOC-Bereitstellung brauchen.

Häufig gestellte Fragen

Hat MQTT eine eingebaute Hochverfügbarkeit?

Nein. Das MQTT-Protokoll definiert Sitzungen, QoS und Last Will, doch Hochverfügbarkeit hängt davon ab, wie der Broker bereitgestellt wird und wie Clients mit Reconnects umgehen.

Übersteht meine MQTT-Sitzung einen Broker-Neustart?

Nur wenn der Broker Sitzungen persistiert. Viele Bereitstellungen, auch unsere, persistieren Sitzungen nicht über Neustarts hinweg, daher sollten Clients bei jeder Verbindung neu abonnieren und wichtigen Zustand erneut publizieren.

Ist Clustering für ein zuverlässiges MQTT-System erforderlich?

Nicht immer. Gut entworfene Clients, partitionierte Broker und isolierte Bereitstellungen verschaffen vielen Systemen eine hohe Zuverlässigkeit ohne replizierten Cluster.

Was sollte ich einen Anbieter zur Hochverfügbarkeit von MQTT-Brokern fragen?

Fragen Sie nach Topologie, Sitzungspersistenz, Nachrichtenreplikation, Failover-Verhalten, Wartungsfenstern und schriftlichen SLA-Bedingungen. Lassen Sie sich die Antworten schriftlich geben, bevor Sie sich festlegen.

Hochverfügbarkeit von MQTT-Brokern: Konzepte, Client-Design und die richtigen Fragen