Migrationsleitfaden für HiveMQ Cloud Serverless: MQTT-Clients Schritt für Schritt umziehen

Eine Migration von HiveMQ Cloud Serverless ist vor allem ein Umkonfigurationsprojekt: Das MQTT-Protokoll bleibt gleich, aber jeder Client braucht einen neuen Hostnamen, neue Zugangsdaten und eventuell eine neue Client-ID, und jeder Zustand, der auf dem alten Cluster lag, muss neu aufgebaut werden. Dieser Leitfaden führt Sie in sechs Schritten durch das gesamte Vorgehen, mit einem privaten Broker von ConnectMQ als Ziel. Dieselben Schritte gelten für jeden standardkonformen MQTT-Broker.

Falls Sie die Hintergründe noch nicht kennen, beginnen Sie mit HiveMQ Cloud Serverless End of Life. Dort finden Sie die Termine und was HiveMQ nach dem 31. Dezember 2026 löscht.

Schritt 1: Alles erfassen, was sich verbindet

Was Sie nicht erfasst haben, können Sie nicht migrieren. Öffnen Sie die HiveMQ-Cloud-Konsole, notieren Sie den Hostnamen Ihres Clusters und alle Zugangsdaten und legen Sie dann eine Tabelle mit einer Zeile pro Client-Typ an:

Vergessen Sie die stillen Clients nicht: einen Node-RED-Flow auf einem vergessenen Raspberry Pi, einen Grafana- oder Telegraf-Input, eine mobile App mit fest eingetragenem Hostnamen oder einen Partner, der ein einzelnes Topic abonniert. In der Fertigung gehören auch Edge-Gateways an SPS und MES-Schnittstellen auf diese Liste. Die HiveMQ-Migrationscheckliste enthält eine druckbare Version dieser Bestandsaufnahme.

Schritt 2: Funktionen dem neuen Broker zuordnen

Vergleichen Sie Ihre Bestandsaufnahme mit dem Zieltarif, bevor Sie etwas ändern:

Zwei Zeilen erfordern eine Entscheidung.

Client-IDs. Bei HiveMQ Cloud wählt jeder Client seine Client-ID selbst. ConnectMQ bindet die Client-ID an die ausgegebenen Zugangsdaten: Ein Client darf genau die ausgegebene Client-ID oder eine Variante mit Suffix verwenden, etwa YOUR_CLIENT_ID_sensor140. Planen Sie für jedes Gerät ein Suffix ein, das aus Seriennummer oder MAC-Adresse abgeleitet ist. Muster dafür finden Sie unter Best Practices für MQTT-Client-IDs.

Berechtigungen. Wenn Sie Topic-Berechtigungen bei HiveMQ genutzt haben, um nicht vertrauenswürdige Parteien zu trennen (zum Beispiel Kunden, die die Daten anderer Kunden nicht sehen dürfen), versuchen Sie nicht, das auf einem einzelnen Broker nachzubilden. Nutzen Sie einen Broker pro Kunde oder Vertrauensgrenze oder schalten Sie ein Backend dazwischen.

Schritt 3: Den Ziel-Broker anlegen

1. Registrieren Sie sich unter app.connectmq.com. Der kostenlose Serverless-Tarif erfordert keine Kreditkarte und eignet sich ideal zum Testen.
2. Wählen Sie einen Tarif, der zu Ihrer Spitzenzahl an Verbindungen plus Reserve passt. Nutzen Sie Serverless (Paid) für Produktionsflotten bis 1.000 Verbindungen oder Dedicated für größere oder latenzkritische Workloads. Unsere Leitfäden zur Serverless-Alternative und zur verwalteten Cloud-Alternative helfen bei der Wahl.
3. Legen Sie den Broker an und kopieren Sie den generierten Benutzernamen, das Passwort und die Client-ID.
4. Machen Sie die Broker-Adresse diesmal konfigurierbar. Speichern Sie Hostname, Port, Zugangsdaten und Client-ID in einer Konfigurationsdatei, einem Provisionierungsdienst oder per OTA aktualisierbaren Einstellungen statt in kompilierter Firmware. Ein einfacher DNS-Alias unter Ihrer eigenen Domain reicht für TLS allein nicht aus, weil das Zertifikat des Brokers für den Hostnamen des Anbieters ausgestellt ist und Clients, die den Hostnamen prüfen, es ablehnen würden.

Schritt 4: Mit einem echten Client testen

Bevor Sie Produktions-Clients umziehen, prüfen Sie die Grundlagen mit denselben Bibliotheken, die Ihre Geräte verwenden. Mit den mosquitto-Clients über TLS:

# Terminal 1: abonnieren
mosquitto_sub -h broker.connectmq.com -p 8883 --capath /etc/ssl/certs \
  -u YOUR_USERNAME -P YOUR_PASSWORD -i YOUR_CLIENT_ID_test1 \
  -t 'site1/#' -v

# Terminal 2: veröffentlichen
mosquitto_pub -h broker.connectmq.com -p 8883 --capath /etc/ssl/certs \
  -u YOUR_USERNAME -P YOUR_PASSWORD -i YOUR_CLIENT_ID_test2 \
  -t 'site1/room1/temp' -m '{"temp":21.7}' -q 1

Testen Sie dann die Details, auf die es bei Ihrer Flotte ankommt: QoS-Stufen, Retained Messages, Last-Will-Nachrichten, persistente Sessions (falls Sie sie nutzen), Nachrichtengrößen nahe Ihrer größten Payload und die Latenz aus dem Netz, das Ihre Geräte tatsächlich nutzen. Der Live-Topic-Explorer im ConnectMQ-Portal zeigt jede Nachricht beim Eintreffen an und ist der schnellste Weg, Topic-Strukturen zu bestätigen – etwa eine ISA-95-Hierarchie in Ihrem Unified Namespace (UNS). Codebeispiele für ESP32, Python, Node.js und Node-RED finden Sie unter MQTT-Clients nach HiveMQ umstellen.

Schritt 5: Parallel betreiben und in Wellen umziehen

Die sicherste Migration lässt beide Broker laufen und leitet den Datenverkehr zwischen ihnen weiter, sodass ein Gerät am alten Broker und eine Anwendung am neuen Broker weiterhin die Nachrichten des jeweils anderen sehen. Ein kleiner Relay-Prozess abonniert auf dem einen Broker und veröffentlicht erneut auf dem anderen. Ein vollständiges Relay-Skript und die Reihenfolge der Wellen zeigen wir unter HiveMQ-Migration ohne Ausfallzeit.

Die empfohlene Reihenfolge:

1. Zuerst die Consumer. Ziehen Sie Datenbanken, Regel-Engines, Node-RED-Flows und Dashboards auf den neuen Broker um. Dank des Relays erhalten sie weiterhin Daten von Geräten am alten Cluster.
2. Eine Pilotgruppe von Geräten. Eine Handvoll aus verschiedenen Standorten und Firmware-Versionen. Beobachten Sie sie einige Tage lang.
3. Der Rest der Flotte in Gruppen, mit einem Kontrollpunkt nach jeder Gruppe.
4. Zuletzt die Befehlsgeber, sobald die Geräte, die sie steuern, umgezogen sind.

Behalten Sie in jeder Welle die Zahl der Verbindungen im Verhältnis zu Ihrem Tarif im Blick. Wird das Kontingent überschritten, erhalten MQTT-5-Clients den Reason Code 0x97 (Quota exceeded). Stufen Sie Ihren Tarif vor einer Welle hoch, nicht währenddessen.

Schritt 6: Umschalten und aufräumen

Sobald der HiveMQ-Cluster außer dem Relay keine Client-Verbindungen mehr zeigt:

1. Stoppen Sie das Relay.
2. Bestätigen Sie, dass jedes erwartete Topic auf dem neuen Broker aktiv ist und der Retained-Zustand erneut veröffentlicht wurde.
3. Exportieren Sie alles, was Sie vom alten Cluster behalten möchten, etwa eine Liste der Zugangsdaten für Ihre Unterlagen.
4. Löschen Sie den Serverless-Cluster und denken Sie daran, dass HiveMQ ihn nicht wiederherstellen kann.
5. Entfernen Sie den alten Hostnamen aus Firmware-Standardwerten, Dokumentation, Runbooks und Secret Stores.

Planen Sie, deutlich vor dem 31. Dezember 2026 fertig zu sein. Einige Wochen Puffer lassen Raum für Geräte, die nur selten online kommen, etwa saisonal genutzte Anlagen oder Sensoren, die einmal am Tag aufwachen.

Typische Stolperfallen

• Kollisionen bei Client-IDs. Zwei Geräte mit derselben Client-ID trennen sich auf jedem Broker gegenseitig immer wieder. Leiten Sie Suffixe aus eindeutigen Hardware-Kennungen ab.
• Fest eingetragene CA-Zertifikate. Geräte, die ein bestimmtes CA-Bundle pinnen, lehnen das Zertifikat eines neuen Brokers womöglich ab. ConnectMQ verwendet ein Zertifikat von Let's Encrypt; stellen Sie sicher, dass das Root-Zertifikat ISRG Root X1 im Trust Store des Geräts liegt. Siehe MQTT-TLS-Konfiguration.
• Die Annahme, dass Retained-Zustand mitwandert. Das tut er nicht. Lassen Sie Geräte ihren aktuellen Zustand direkt nach dem Verbinden mit gesetztem Retain-Flag veröffentlichen.
• Vergessene Reconnect-Logik. Ein Gerät ohne sauberes Backoff kann einen neuen Broker während einer Welle fluten. Prüfen Sie vorher MQTT Keep Alive und die Reconnect-Einstellungen Ihres Clients.

Häufig gestellte Fragen

Wie lange dauert eine Migration von HiveMQ Serverless?

Bei einer Handvoll Anwendungen einen Tag. Bei Flotten von Feldgeräten, die Firmware-Updates brauchen, sollten Sie Wochen einplanen: neue Firmware bauen und testen, gestaffelt ausrollen und auf selten verbundene Geräte warten. Beginnen Sie jetzt, damit die Frist nicht Ihr Testtermin wird.

Kann ich migrieren, ohne die Geräte-Firmware zu aktualisieren?

Nur wenn Hostname, Zugangsdaten und Client-ID ohne Firmware-Änderung konfigurierbar sind, zum Beispiel über eine Konfigurationsdatei oder einen Provisionierungsdienst. Sind sie fest einkompiliert, brauchen Sie ein Over-the-Air-Update.

Muss ich meine Topic-Struktur ändern?

Nein. Topics sind einfach Zeichenketten, und ConnectMQ unterstützt Standard-Wildcards und die Topic-Tiefen, die typische IoT-Designs verwenden. Behalten Sie Ihre bestehende Struktur bei, damit Dashboards und Regeln weiter funktionieren.

Mit welchem ConnectMQ-Tarif sollte ich beginnen?

Beginnen Sie zum Testen mit dem kostenlosen Serverless-Tarif. Für die Produktion wählen Sie Serverless (Paid) für bis zu 1.000 Verbindungen oder den dedizierten verwalteten Cloud-MQTT-Broker von ConnectMQ, wenn Sie einen isolierten Cluster benötigen.