HiveMQ-Migrationscheckliste: Workload und Zugangsdaten

Der Abschied von HiveMQ Cloud Serverless verläuft reibungslos, wenn drei Dinge erledigt sind, bevor Sie ein Gerät anfassen: Sie kennen Ihren Workload, Sie haben Ihre neuen Zugangsdaten geplant, und Sie haben einen privaten Broker mit Ihrem echten Datenverkehr getestet. Diese Checkliste macht aus diesen drei Schritten konkrete Punkte zum Abhaken. Sie funktioniert mit jedem Ziel-Broker; wo es hilft, zeigen wir, wie jeder Punkt bei ConnectMQ aussieht.

HiveMQ stellt Serverless am 31. Dezember 2026 ein. Hintergründe finden Sie unter HiveMQ Cloud Serverless End of Life.

Teil 1: Workload prüfen

Ihr Workload bestimmt, welchen Tarif Sie brauchen und wie lange die Migration dauert.

Verbindungen

Spitzenzahl gleichzeitiger Verbindungen auf dem HiveMQ-Cluster (in der Konsole während Ihrer verkehrsreichsten Stunde prüfen).
Erwartetes Wachstum in den nächsten 12 bis 18 Monaten.
Anzahl der Verbindungen, die Anwendungen oder Dashboards statt Geräte sind.
Clients, die mehrere Verbindungen öffnen (zum Beispiel ein Gateway pro Standort oder ein Backend mit Workern).

Nachrichten

Durchschnittliche und maximale Nachrichtenrate.
Größte Payload, einschließlich Binärformaten wie Sparkplug B.
Verwendete QoS-Stufen; notieren Sie alle QoS-2-Flüsse.
Topics mit gesetztem Retain-Flag und ob der Retained-Zustand für den Start wichtig ist.
Clients, die persistente Sessions nutzen und während Offline-Phasen eingereihte Nachrichten erwarten.

Topologie

Vollständige Liste der Topic-Präfixe und wer jeweils veröffentlicht oder abonniert – in der Fertigung oft entlang einer ISA-95-Hierarchie im Unified Namespace (UNS).
Wildcard-Abonnements von Backends.
Shared Subscriptions für die Lastverteilung.
Partner oder Kunden, die sich mit Ihrem Cluster verbinden.

So dimensionieren Sie den neuen Tarif

Ihr Workload	Empfohlener ConnectMQ-Tarif
Bis zu 25 Verbindungen, QoS 0 oder 1, Payloads unter 256 KB	Serverless (Free)
Bis zu 1.000 Verbindungen, QoS 2, Payloads bis 1 MB, Shared Subscriptions	Serverless (Paid)
Mehr als 1.000 Verbindungen, latenzkritisch oder Isolation erforderlich	Dedizierter verwalteter Cloud-MQTT-Broker von ConnectMQ
Daten müssen in Ihrem Cloud-Konto bleiben	BYOC
Broker muss auf Ihrer eigenen Hardware laufen	Self Managed Enterprise

Dimensionieren Sie immer auf die Spitze plus Reserve. Ein Tarif, der zum Durchschnitt passt, weist Verbindungen beim Reconnect-Sturm nach einem Netzwerkausfall ab.

Teil 2: Neue Zugangsdaten planen

Ihre HiveMQ-Cluster-URL und Ihre Zugangsdaten lassen sich nicht übertragen, also bekommt jeder Client neue. Planen Sie das Schema einmal, statt pro Gerät zu improvisieren.

Alle HiveMQ-Zugangsdaten auflisten und was sie jeweils nutzt.
Zugangsdaten Brokern zuordnen. Bei ConnectMQ gibt jeder Broker einen Benutzernamen, ein Passwort und eine Client-ID aus. Fassen Sie Clients derselben Vertrauensgrenze unter einem Broker zusammen.
Client-IDs entwerfen. ConnectMQ bindet die Client-ID an die Zugangsdaten; Clients dürfen die ausgegebene ID verwenden oder ein Suffix anhängen, etwa YOUR_CLIENT_ID_line1-plc. Leiten Sie Suffixe aus einer eindeutigen Hardware-Kennung ab, damit nie zwei Geräte kollidieren. Siehe Best Practices für MQTT-Client-IDs.
Vertrauensgrenzen trennen. Wenn Sie Topic-Berechtigungen bei HiveMQ genutzt haben, um Kunden oder Partner voneinander zu isolieren, geben Sie jedem einen eigenen Broker statt gemeinsamer Zugangsdaten.
Secrets richtig speichern. Bewahren Sie Zugangsdaten in einem Secrets Manager und auf Geräten in geschütztem Speicher auf, niemals in der Versionskontrolle. Siehe MQTT-Zugangsdaten auf Geräten sicher speichern.
Rotation planen. Legen Sie fest, wie Sie Zugangsdaten später ohne erneute Migration rotieren. Siehe MQTT-Zugangsdaten rotieren.
Endpunkte konfigurierbar machen. Hostname, Port, Zugangsdaten und Client-ID sollten sich aus der Ferne ändern lassen, damit dies das letzte Mal ist, dass ein Broker-Wechsel Firmware-Änderungen erfordert.

Teil 3: Einen privaten verwalteten Broker testen

Lassen Sie nie das erste Produktionsgerät den ersten Test sein. Legen Sie einen privaten Broker an, zum Beispiel einen kostenlosen unter app.connectmq.com, und arbeiten Sie diese Tests ab.

Konnektivität

Verbindung über TLS auf Port 8883 aus jedem Netztyp, den Ihre Geräte nutzen.
Verbindung über Secure WebSocket auf Port 8084 (Pfad /mqtt) aus Ihrem Web-Dashboard.
Bestätigen, dass Geräte dem Broker-Zertifikat vertrauen. ConnectMQ verwendet Let's Encrypt; das Root-Zertifikat ISRG Root X1 muss im Trust Store liegen. Siehe MQTT-TLS-Konfiguration.

Verhalten

Mit Ihrer echten Topic-Struktur und Ihren echten Payloads veröffentlichen und abonnieren.
Jede genutzte QoS-Stufe testen.
Eine Retained Message veröffentlichen und bestätigen, dass ein neuer Abonnent sie erhält.
Eine Last-Will-Nachricht setzen und den Client hart beenden, um ihre Zustellung zu bestätigen.
Mit persistenter Session neu verbinden und bestätigen, dass eingereihte Nachrichten ankommen.
Ihre größte Payload senden.

Leistung und Limits

Round-Trip-Latenz von den Gerätestandorten aus messen, nicht nur aus dem Büro.
Eine Gruppe von Test-Clients gleichzeitig neu verbinden, um die Wiederherstellung nach einem Ausfall zu simulieren.
Prüfen, wie sich Ihre Clients verhalten, wenn ein Limit erreicht ist; MQTT-5-Clients erhalten den Reason Code 0x97 bei überschrittenem Kontingent.
Den Test im Live-Topic-Explorer und im Dashboard beobachten.

Ein schneller Latenztest mit MQTT.js:

// npm install mqtt
const mqtt = require("mqtt");
const topic = "migration-test/rtt";
const client = mqtt.connect("mqtts://broker.connectmq.com:8883", {
  username: process.env.MQTT_USERNAME,
  password: process.env.MQTT_PASSWORD,
  clientId: `${process.env.MQTT_CLIENT_ID}_rtt`,
  protocolVersion: 5,
});

let sentAt = 0, n = 0;
client.on("connect", () => client.subscribe(topic, { qos: 1 }, send));
function send() { sentAt = Date.now(); client.publish(topic, String(n), { qos: 1 }); }
client.on("message", () => {
  console.log(`round trip ${n}: ${Date.now() - sentAt} ms`);
  if (++n < 20) setTimeout(send, 250); else client.end();
});

Teil 4: Go/No-Go vor der ersten Welle

Bestandsaufnahme vollständig und Verantwortliche für jeden Client-Typ benannt.
Tarif gewählt und auf Spitze plus Reserve dimensioniert.
Schema für Zugangsdaten und Client-IDs dokumentiert.
Alle Tests aus Teil 3 bestanden.
Retained-Zustand exportiert oder von Clients beim Verbinden erneut veröffentlicht. Siehe Datenlöschung bei HiveMQ Serverless.
Relay für den Parallelbetrieb getestet. Siehe HiveMQ-Migration ohne Ausfallzeit.
Rollback-Plan: wie eine Welle bei einem Fehler zu HiveMQ zurückkehrt, solange der alte Cluster noch läuft.
Zieltermin für die letzte Welle, einige Wochen vor dem 31. Dezember 2026.

Sobald jeder Punkt abgehakt ist, folgen Sie für den eigentlichen Umzug dem Migrationsleitfaden für HiveMQ Serverless.

Häufig gestellte Fragen

Wie finde ich meine Spitzenzahl an Verbindungen auf HiveMQ Serverless?

Prüfen Sie die Verbindungsinformationen in der HiveMQ-Cloud-Konsole während Ihrer verkehrsreichsten Phase und gleichen Sie sie mit Ihrem eigenen Geräteinventar ab. Im Zweifel dimensionieren Sie den neuen Tarif großzügig.

Brauche ich einen Satz Zugangsdaten pro Gerät?

Nicht unbedingt. Bei ConnectMQ können viele Geräte einen Satz Zugangsdaten teilen, indem sie eindeutige Suffixe an die Client-ID anhängen. Nutzen Sie separate Broker oder Zugangsdaten, wo Geräte oder Nutzer zu unterschiedlichen Vertrauensgrenzen gehören.

Kann ich ConnectMQ testen, bevor ich bezahle?

Ja. Der Tarif Serverless (Free) erfordert keine Kreditkarte und unterstützt bis zu 25 Verbindungen, was für alle Tests dieser Checkliste ausreicht.

Was, wenn ein Test fehlschlägt?

Beheben Sie das Problem, bevor Sie Produktions-Clients umziehen. Die meisten Fehler betreffen TLS-Trust-Stores, Regeln für Client-IDs oder Tariflimits, und alle drei lassen sich leichter beheben, solange der alte Cluster noch läuft.

HiveMQ-Migrationscheckliste: Workload prüfen, Zugangsdaten planen und einen privaten Broker testen