Mosquitto ohne Ausfallzeit zu einem Cloud-MQTT-Broker migrieren

Wenn Sie Mosquitto in die Cloud migrieren, ist nicht der neue Broker der riskante Teil, sondern der Moment, in dem die Geräte umschalten. Dieses Tutorial liefert Ihnen ein Runbook ohne Ausfallzeit: Erfassen Sie, was heute auf Ihrem Mosquitto läuft, ordnen Sie die Zugangsdaten dem Cloud-Broker zu, betreiben Sie beide Broker mit einer Mosquitto-Bridge parallel, ziehen Sie Clients in Wellen um und legen Sie den alten Broker mit einem bereitliegenden Rollback-Plan still. Die Beispiele nutzen ConnectMQ als Ziel, die Methode funktioniert aber mit jedem standardkonformen Broker.

Warum Teams von Mosquitto wegmigrieren

Mosquitto ist ein hervorragender, schlanker Broker und bleibt für viele Edge- und Laborinstallationen die richtige Wahl. Teams verlagern den zentralen Broker meist aus betrieblichen Gründen in die Cloud, nicht wegen technischer Schwächen: Zertifikatserneuerungen, Betriebssystem-Patches, Backups, Monitoring und Rufbereitschaft landen bei jemandem, der eigentlich andere Aufgaben hat. Entfernte Geräte brauchen zudem einen erreichbaren Endpunkt, was Firewall-Regeln und eine öffentliche Erreichbarkeit für einen Server bedeutet, den Sie selbst pflegen. Wenn Sie noch unentschlossen sind, vergleichen Sie zuerst die Abwägungen unter MQTT-Broker selbst betrieben vs. verwaltet und Mosquitto-Alternative in der Cloud.

Schritt 1: Clients, Topics und Funktionen erfassen

Was Sie nicht aufgelistet haben, können Sie nicht migrieren. Sammeln Sie vier Dinge vom aktuellen Broker.

Konfiguration. Lesen Sie mosquitto.conf und alle Dateien in conf.d. Notieren Sie Listener und Ports, allow_anonymous, password_file, acl_file, Persistenzeinstellungen, max_inflight_messages, Limits für die Nachrichtengröße und bestehende Bridges.

Clients. Mosquitto protokolliert jede Verbindung mit ihrer Client ID. Extrahieren Sie die eindeutigen IDs und Quelladressen aus dem Log:

grep "New client connected" /var/log/mosquitto/mosquitto.log \
  | sed -E 's/.*from ([0-9a-fA-F.:]+):[0-9]+ as ([^ ]+).*/\2 \1/' \
  | sort -u > clients.txt
wc -l clients.txt

Topics. Abonnieren Sie über einen repräsentativen Zeitraum alles und erfassen Sie die eindeutigen Topic-Namen, einschließlich der Retained Topics:

timeout 600 mosquitto_sub -h localhost -p 1883 -u admin -P 'ADMIN_PASSWORD' \
  -i inventory-$RANDOM -t '#' -F '%t %r' | sort -u > topics.txt

Das Feld %r gibt bei Retained Messages eine 1 aus; diese müssen Sie auf dem neuen Broker neu anlegen.

Die Topic-Liste ist zugleich eine gute Gelegenheit, die Struktur zu prüfen. In Industrie-4.0-Umgebungen hat sich ein Unified Namespace (UNS) bewährt, dessen Topic-Baum der ISA-95-Hierarchie Enterprise → Site → Area → Line → Cell folgt, etwa acme/werk-stuttgart/montage/linie-1/zelle-3/temperatur. Ob Sie die Topics während der Migration umbenennen oder erst danach, sollten Sie bewusst entscheiden: Ein Umzug ohne Umbenennung ist risikoärmer, eine spätere Umstellung kann über zusätzliche Bridge-Regeln mit Präfixen erfolgen. Hintergründe liefert der Beitrag zu Sparkplug B und Unified Namespace.

Genutzte Funktionen. Prüfen Sie, ob Clients MQTT 5, QoS 2, persistente Sitzungen, große Payloads, Wildcard-Subscriptions oder ACLs pro Topic verwenden. Jeder dieser Punkte wird zu einer Anforderung an das Ziel.

Schritt 2: Funktionen und Zugangsdaten zuordnen

Vergleichen Sie Ihre Bestandsaufnahme mit dem Ziel-Broker, bevor Sie irgendein Gerät anfassen:

Zwei Zeilen verdienen besondere Aufmerksamkeit. Erstens die Client IDs: Auf Mosquitto kann meist jeder Client eine beliebige ID wählen, während ConnectMQ jede Client ID an die ausgegebenen Zugangsdaten bindet. Planen Sie einen Satz Zugangsdaten pro Gerät oder Dienst und passen Sie Firmware oder Konfiguration so an, dass jedes Gerät seine ausgegebene Client ID verwendet. Zweitens die ACLs: Wenn Ihr Mosquitto-Setup auf feingranulare Topic-ACLs setzt, um nicht vertrauenswürdige Parteien zu trennen, gestalten Sie diese Grenze vor der Migration mit getrennten Brokern oder einem Backend neu, das den Zugriff vermittelt.

Legen Sie dann das Ziel an: Registrieren Sie sich unter app.connectmq.com, wählen Sie einen Plan, der zu Ihrer maximalen Verbindungszahl passt, erstellen Sie einen Broker und geben Sie Zugangsdaten für die Bridge und die erste Welle von Clients aus.

Schritt 3: Parallelbetrieb mit einer Mosquitto-Bridge

Die Bridge macht eine Migration ohne Ausfallzeit überhaupt erst möglich. Mosquitto verbindet sich als normaler MQTT-Client mit dem Cloud-Broker und leitet ausgewählte Topics in jede Richtung weiter, sodass Geräte auf beiden Brokern während der Umstellung dieselben Daten sehen. Legen Sie eine Datei wie /etc/mosquitto/conf.d/bridge-connectmq.conf an:

connection connectmq
address broker.connectmq.com:8883
bridge_protocol_version mqttv311
remote_clientid YOUR_CLIENT_ID
remote_username YOUR_USERNAME
remote_password YOUR_PASSWORD
bridge_capath /etc/ssl/certs
bridge_insecure false
try_private false
notifications false
cleansession true
restart_timeout 5 60

# Telemetrie lokaler Geräte geht hinauf in die Cloud
topic factory1/+/+/telemetry out 1
topic factory1/+/+/status out 1
# Befehle von Cloud-Anwendungen kommen herunter zu den lokalen Geräten
topic factory1/+/+/cmd in 1

Starten Sie Mosquitto mit sudo systemctl restart mosquitto neu und prüfen Sie im Log, ob die Bridge-Verbindung erfolgreich aufgebaut wurde. Einige Einstellungen sind entscheidend:

• try_private false: Das Private-Bridge-Flag ist eine Mosquitto-spezifische Erweiterung; deaktivieren Sie es, wenn die Gegenseite ein anderer Broker ist.
• notifications false: verhindert, dass Mosquitto Bridge-Status-Topics an die Gegenseite publiziert, die Sie dort nicht benötigen.
• Gerichtete Topics: Verwenden Sie wo immer möglich out und in statt both. Bidirektionales Bridging derselben Topics zwischen zwei Brokern kann Nachrichtenschleifen erzeugen.
• restart_timeout: verlängert schrittweise die Abstände zwischen Reconnect-Versuchen, wenn die Cloud-Seite kurz nicht erreichbar ist.

Überprüfen Sie die Bridge, indem Sie mit eigenen Zugangsdaten auf der Cloud-Seite abonnieren oder den Live-Topic-Explorer im Portal beobachten, während ein lokales Gerät publiziert.

mosquitto_sub -h broker.connectmq.com -p 8883 --capath /etc/ssl/certs \
  -u YOUR_USERNAME -P YOUR_PASSWORD -i YOUR_CLIENT_ID \
  -t 'factory1/#' -v

Verwenden Sie hier einen anderen Satz Zugangsdaten als für die Bridge, denn jede Client ID kann nur eine Verbindung halten.

Schritt 4: Clients in Wellen umziehen

Solange die Bridge läuft, kann jeder Client unabhängig umziehen. Ziehen Sie zuerst die Consumer um, dann die Producer:

1. Backend-Consumer (Datenbanken, Node-RED, Dashboards): Richten Sie sie auf den Cloud-Broker aus. Dank der Bridge erhalten sie weiterhin die lokale Telemetrie.
2. Eine Pilotgruppe von Geräten: eine Handvoll Geräte von verschiedenen Standorten und mit verschiedenen Firmware-Versionen. Ändern Sie Host, Port 8883, TLS und Zugangsdaten und beobachten Sie sie einige Tage lang.
3. Übrige Geräte in Chargen: nach Standort oder Produktlinie, mit einem Kontrollpunkt nach jeder Charge. In der Fertigung bietet es sich an, die Chargen an geplante Stillstände oder Wartungsfenster einer Linie zu koppeln.
4. Befehls-Producer: Sobald die Geräte auf dem Cloud-Broker sind, ziehen Sie die Anwendungen um, die Befehle senden.

Bestätigen Sie für jede Charge den Verbindungsstatus unter $SYS/broker/connection/{clientId}/state, prüfen Sie, ob die erwarteten Topics im Explorer erscheinen, und legen Sie alle Retained Messages neu an, die Ihre Bestandsaufnahme markiert hat. Da ConnectMQ keinen Retained-Zustand über Neustarts hinweg garantiert, sollten Geräte ihren Retained-Status und ihre Konfiguration bei jeder Verbindung erneut publizieren, was auf jedem Broker eine gute Praxis ist.

Behalten Sie während der Wellen die Limits Ihres Plans im Blick. Treibt eine Welle die Verbindungen über das Kontingent, erhalten MQTT-5-Clients den Reason Code 0x97; 3.1.1-Clients werden abgewiesen. Führen Sie das Plan-Upgrade vor der Welle durch, nicht währenddessen.

Schritt 5: Umstellen, dann stilllegen

Wenn der lokale Broker außer der Bridge keine direkten Clients mehr trägt, ist die Migration funktional abgeschlossen. Lassen Sie Bridge und alten Broker für einen vereinbarten Beobachtungszeitraum als Rollback-Pfad weiterlaufen. Ein Gerät zurückzuholen ist dann nur eine Konfigurationsänderung zurück auf den alten Host, und die Bridge hält beide Seiten in der Zwischenzeit synchron.

Legen Sie dann in dieser Reihenfolge still: Entfernen Sie die Bridge-Konfiguration, stoppen Sie Mosquitto, schließen Sie die Firewall-Ports, widerrufen Sie alte Zugangsdaten und archivieren Sie die Konfigurationsdateien. Wenn manche Standorte lokales MQTT für Edge-Logik benötigen, die offline funktionieren muss, behalten Sie dort dauerhaft eine Mosquitto-Instanz und verbinden Sie sie per Bridge nach oben; dieses hybride Design ist verbreitet und völlig legitim.

Checkliste für die Migration

1. Konfiguration, Client-Liste und Topic-Liste aus Mosquitto exportiert.
2. Funktionslücken (ACLs, QoS 2, Nachrichtengröße, Persistenz) geklärt.
3. Ziel-Broker in einem Plan mit ausreichend Verbindungen angelegt.
4. Ein Satz Zugangsdaten pro Gerät oder Dienst ausgegeben.
5. Bridge mit gerichteten Topics in Betrieb; Daten auf beiden Seiten verifiziert.
6. Consumer umgezogen und verifiziert.
7. Geräte in Wellen mit Kontrollpunkten umgezogen.
8. Retained-Zustand wird bei Verbindung erneut publiziert.
9. Rollback-Pfad für den Beobachtungszeitraum beibehalten.
10. Alter Broker stillgelegt und Zugangsdaten widerrufen.

Der Leitfaden MQTT vom Prototyp zur Produktion behandelt Härtungsschritte, die Sie in dasselbe Projekt einbinden können.

Zu ConnectMQ migrieren

Erstellen Sie unter app.connectmq.com einen kostenlosen Broker im Serverless-Plan, ohne Kreditkarte, und bauen Sie die Bridge dagegen auf, um das gesamte Runbook zu testen, bevor Sie sich festlegen. ConnectMQ bietet Ihnen einen verwalteten MQTT-Broker mit TLS, WebSockets, ausgegebenen Zugangsdaten und einem Portal mit Live-Topic-Explorer. Hintergründe zu Bereitstellungsmodellen finden Sie im Leitfaden zum Cloud-MQTT-Broker, und für schnelle, unkritische Experimente nutzen Sie den öffentlichen MQTT-Broker, der für Tests gedacht ist und keine Produktionsdaten transportieren sollte.

Häufig gestellte Fragen

Kann ich Mosquitto in die Cloud migrieren, ohne die Geräte-Firmware zu ändern?

Nur wenn Host, Port, TLS-Einstellungen, Zugangsdaten und Client ID ohne Firmware-Update konfigurierbar sind. Geräte mit fest einprogrammierten Broker-Adressen können an einem lokalen Mosquitto bleiben, der per Bridge mit der Cloud verbunden ist.

Sollte die Bridge QoS 1 oder QoS 0 verwenden?

QoS 1 ist die übliche Wahl für das Bridging von Telemetrie und Befehlen, weil es Nachrichten über die Bridge-Verbindung absichert. Verwenden Sie QoS 0 nur für Daten mit hoher Rate, bei denen gelegentliche Verluste akzeptabel sind.

Werden Retained Messages automatisch migriert?

Bereits auf Mosquitto vorhandene Retained Messages werden nicht en bloc kopiert. Die Bridge leitet neue Publishes weiter; lassen Sie die Geräte ihren Retained-Status bei der Verbindung erneut publizieren und überprüfen Sie die Retained Topics auf der Cloud-Seite.

Wie lange sollte ich den alten Mosquitto-Broker behalten?

Behalten Sie ihn mitsamt laufender Bridge, bis jeder Client über einen vereinbarten Zeitraum stabil auf dem neuen Broker läuft. So haben Sie zu sehr geringen Kosten einen sofortigen Rollback-Pfad.