Ein dedizierter MQTT-Broker gibt einem einzelnen Kunden einen isolierten Broker-Cluster statt eines Anteils an einem gemeinsamen, sodass Performance und Kapazität allein für Ihre Flotte reserviert sind. Dieser Leitfaden erklärt, was Ihnen Isolation bringt, an welchen Signalen Sie erkennen, dass eine Serverless-Stufe nicht mehr reicht, wie Sie die Kapazität vor dem Wechsel planen, und liefert eine praktische Checkliste für den Umstieg von ConnectMQ Serverless auf Dedicated.
Was ein dedizierter MQTT-Broker ist
In einer Serverless-Stufe teilen sich viele Mandanten einen Cluster und sind logisch durch Zugangsdaten, Topic-Namensräume und Kontingente getrennt. Eine dedizierte Bereitstellung hebt diese gemeinsame Nutzung auf: Der Anbieter betreibt einen Broker-Cluster, der nur Ihre Organisation bedient. Sie verwalten weiterhin weder Server noch Betriebssysteme oder Zertifikate, denn es bleibt ein verwalteter MQTT-Broker, aber Rechenleistung, Arbeitsspeicher und Netzwerk hinter Ihrem Endpunkt teilen Sie mit niemandem.
Dieser Unterschied ist für kleine Flotten weniger wichtig, als viele erwarten, und für große oder latenzkritische Flotten deutlich wichtiger. Wenn Sie noch grundsätzlich zwischen Hosting-Modellen abwägen, erklärt der Leitfaden zum Cloud-MQTT-Broker die gesamte Landschaft.
Was Ihnen Isolation bringt
Vorhersehbare Performance
Auf einem gemeinsamen Cluster verhindern Kontingente, dass ein einzelner Mandant die Ressourcen monopolisiert, doch Ihr Datenverkehr läuft trotzdem neben dem aller anderen. Bei einem dedizierten MQTT-Broker kann eine Lastspitze eines anderen Unternehmens Sie schlicht nicht beeinflussen. Latenz und Durchsatz hängen von Ihrer eigenen Last ab, was das Verhalten leichter nachvollziehbar und testbar macht.
Planbare Kapazitätsreserven
Gemeinsame Stufen haben feste Kontingente pro Plan. Ein dedizierter Cluster wird für Ihre erwartete Last dimensioniert, sodass Sie Reserven bewusst planen, statt an eine Obergrenze zu stoßen, die für den durchschnittlichen Mandanten ausgelegt ist.
Einfachere Argumentation bei Sicherheit und Compliance
Manche Sicherheitsprüfungen stellen eine einfache Frage: Berührt der Datenverkehr anderer Kunden denselben Broker-Prozess? Beim dedizierten Hosting lautet die Antwort Nein. Das verkürzt Beschaffungsgespräche oft, selbst wenn die gemeinsame Stufe technisch gut isoliert war.
Weniger Einschränkungen im Design
Breites Fan-out, viele Backend-Konsumenten auf Shared Subscriptions, größere Payloads und QoS-2-Abläufe lassen sich leichter unterbringen, wenn der Cluster Ihnen gehört.
Anzeichen, dass Serverless nicht mehr reicht
Achten Sie auf diese Signale. Ein einzelnes ist nicht unbedingt ein Grund zu wechseln, mehrere zusammen meist schon.
| Signal | Was Sie sehen | Warum es wichtig ist |
|---|---|---|
| Verbindungsobergrenze | Abgelehnte Verbindungen, Reason Code 0x97 | Geräte können nicht online gehen |
| Gleichmäßig hohe Nachrichtenrate | Konstanter Durchsatz rund um die Uhr | Sie zahlen für gebündelte Kapazität, die Sie praktisch ständig nutzen |
| Latenzempfindlichkeit | Regelkreise, Alarme, Bedienoberflächen | Schwankungen schaden mehr als der Durchschnitt |
| Anforderungen der Beschaffung | Fragen zu gemeinsam genutzter Infrastruktur | Isolation vereinfacht die Antwort |
| Wachstumsplan der Flotte | Tausende Geräte auf der Roadmap | Besser vor dem Ansturm migrieren |
| Viele Backend-Konsumenten | Mehrere Services abonnieren dieselben Streams | Fan-out vervielfacht die Last |
Der Plan Serverless (Paid) von ConnectMQ unterstützt bis zu 1.000 Verbindungen, QoS 2, Nachrichten bis 1 MB und Shared Subscriptions, was für viele Produkte völlig ausreicht. Dedicated ist für den Fall gedacht, dass Sie einen eigenen isolierten Cluster statt höherer Kontingente auf einem gemeinsamen möchten.
In Industrie-4.0-Projekten tritt dieser Punkt oft früher ein als erwartet. Sobald der Broker als Unified Namespace (UNS) mehrere Werke bündelt und SPS-Gateways, MES, SCADA und Historians entlang der ISA-95-Hierarchie (etwa acme/werk-stuttgart/montage/linie-1/...) daran hängen, wird er zur zentralen Produktionsinfrastruktur. Planbare Latenz und eigene Reserven zählen dann mehr als die günstigste Stufe.
Kapazitätsplanung für eine dedizierte Bereitstellung
Gute Kapazitätsplanung beginnt bei Ihren Geräten, nicht bei Broker-Benchmarks. Arbeiten Sie diese Werte durch und halten Sie sie schriftlich fest; genau darüber werden Sie bei der Dimensionierung Ihres Clusters sprechen.
- Gleichzeitige Verbindungen in der Spitze. Geräte, Gateways, Backend-Services, Dashboards und Testwerkzeuge zählen alle. Berücksichtigen Sie den Reconnect-Sturm: Nach einem Netzwerkausfall verbindet sich jedes Gerät innerhalb kurzer Zeit neu.
- Eingehende Nachrichten pro Sekunde. Multiplizieren Sie Geräte mit Publish-Rate. 2.000 Geräte mit einer Nachricht alle 10 Sekunden ergeben im Mittel 200 Nachrichten pro Sekunde, doch Synchronität (Geräte melden zur vollen Minute) erzeugt Spitzen.
- Ausgehendes Fan-out. Jede publizierte Nachricht wird einmal pro passendem Abonnement zugestellt. Eine Nachricht, die ein Dashboard, ein Historian und ein Alarmdienst lesen, bedeutet drei Zustellungen.
- Payload-Größe. Durchschnitt und Maximum. Kompakte JSON- oder Binär-Payloads senken Bandbreite und Speicherbedarf des Brokers.
- QoS-Mix. QoS 1 und 2 erzeugen im Vergleich zu QoS 0 zusätzlichen Bestätigungsverkehr und In-flight-Zustand. Siehe MQTT-QoS-Stufen erklärt.
- Session-Zustand. Persistente Sessions mit gepufferten Nachrichten für Offline-Clients verbrauchen Speicher. Setzen Sie eine Session Expiry, damit sich verwaiste Sessions nicht ansammeln.
- Retained Messages. Eine retained Message pro Status-Topic ist günstig, Millionen veralteter retained Topics sind es nicht.
- Wachstum. Planen Sie für das Flottenwachstum der nächsten 12 bis 18 Monate statt für den heutigen Bestand.
Ein einfaches Dimensionierungsblatt im Klartext hilft, das Team auf einen Stand zu bringen:
Peak devices online ............ 3,000
Backend/dashboard clients ...... 40
Reconnect storm window ......... 120 s
Avg publish interval ........... 15 s -> ~200 msg/s inbound
Avg subscribers per message .... 2 -> ~400 msg/s outbound
Avg payload .................... 350 bytes
QoS ............................ 1 (telemetry), 2 (commands)
Retained topics ................ ~3,000 (one status topic per device)
Session expiry ................. 1 hour
Growth target (18 months) ...... 3x
Erst messen, dann migrieren
Sammeln Sie vor dem Wechsel echte Zahlen von Ihrem Serverless-Broker. Ein kleiner Python-Subscriber, der Nachrichten pro Topic der obersten Ebene zählt, liefert schnell eine Ausgangsbasis.
import collections
import ssl
import time
import paho.mqtt.client as mqtt
counts = collections.Counter()
start = time.time()
def on_connect(client, userdata, flags, reason_code, properties):
print("Connected:", reason_code)
client.subscribe("#", qos=0)
def on_message(client, userdata, msg):
counts[msg.topic.split("/")[0]] += 1
elapsed = time.time() - start
if elapsed >= 60:
for prefix, n in counts.most_common():
print(f"{prefix:20s} {n / elapsed:8.2f} msg/s")
counts.clear()
globals()["start"] = time.time()
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(cert_reqs=ssl.CERT_REQUIRED)
client.on_connect = on_connect
client.on_message = on_message
client.connect("broker.connectmq.com", 8883, keepalive=60)
client.loop_forever()
Kombinieren Sie das mit dem Portal-Dashboard und dem Topic $SYS/broker/connection/{clientId}/state, das anzeigt, ob ein bestimmter Client verbunden ist, um sowohl den Datenverkehr als auch das Verbindungsverhalten zu verstehen.
Migrations-Checkliste: von Serverless zu Dedicated
Da ein dedizierter MQTT-Broker dasselbe Protokoll MQTT 3.1.1 und 5.0 auf denselben Ports spricht (1883, 8883, 8083 und 8084 mit /mqtt), ist die Migration im Wesentlichen eine Konfigurationsaufgabe.
- Den Endpunkt konfigurierbar machen. Wenn Hostname, Port, Benutzername, Passwort und Client ID fest in die Firmware einkompiliert sind, beheben Sie das zuerst. Legen Sie sie in NVS, einer Konfigurationsdatei oder in Provisionierungsdaten ab.
- Den dedizierten Broker anfordern und bereitstellen. Beziehen Sie im Portal neue Zugangsdaten für die dedizierte Umgebung.
- Zuerst die Backend-Konsumenten umziehen. Richten Sie eine Kopie jedes Backend-Services auf den neuen Broker und prüfen Sie, ob Testdaten ankommen.
- Übergangsweise mit eigenem Werkzeug überbrücken. Wenn Geräte über Tage oder Wochen umziehen, betreiben Sie ein kleines Relay (Node-RED oder ein kurzes Python-Skript), das auf dem alten Broker abonniert und auf dem neuen erneut publiziert. ConnectMQ bietet keine integrierten Bridges, daher erfolgt dies mit einem externen MQTT-Client.
- Geräte in Wellen umstellen. Aktualisieren Sie einen kleinen Prozentsatz, beobachten Sie Verbindungsstatus und Fehlerprotokolle und fahren Sie dann fort.
- Retained-Zustand neu publizieren. Retained Messages ziehen nicht automatisch mit um; lassen Sie Geräte ihren aktuellen Status beim Verbinden publizieren.
- Den alten Broker stilllegen. Wenn der alte Broker keine Geräteverbindungen mehr zeigt, stoppen Sie das Relay und nehmen ihn außer Betrieb.
Typische Stolperfallen: Dashboards und Skripte, die noch auf den alten Hostnamen zeigen, fest codierte Client IDs, die zwischen Umgebungen kollidieren, und fehlender Retained-Zustand nach der Umstellung. Unser Leitfaden zu Best Practices für MQTT-Sicherheit lohnt sich in diesem Zusammenhang ebenfalls, denn eine Migration ist ein guter Moment, Zugangsdaten zu rotieren.
Dedicated, BYOC oder Enterprise?
Dedicated ist nicht die einzige isolierte Option. Wenn der Broker im eigenen Cloud-Konto Ihrer Organisation laufen muss, stellt BYOC ihn dort bereit, während ConnectMQ ihn verwaltet. Wenn Sie alles selbst betreiben müssen, deckt Self Managed Enterprise das ab. Der Leitfaden zum Enterprise-MQTT-Broker vergleicht diese Modelle mit typischen Unternehmensanforderungen.
Wechseln Sie mit ConnectMQ zu einem dedizierten Broker
Die meisten Teams starten mit dem kostenlosen Serverless-Plan unter app.connectmq.com (keine Kreditkarte nötig), messen den realen Datenverkehr und wechseln zu einem Dedicated-Cluster, sobald Isolation und Reserven Priorität bekommen. ConnectMQ behält Protokolle, Ports und Portal-Werkzeuge über alle Pläne hinweg bei, sodass Ihre Geräte, der Topic-Explorer, Dashboards und Alarmregeln nach dem Wechsel genauso weiterarbeiten.
Häufig gestellte Fragen
Ist ein dedizierter MQTT-Broker schneller als Serverless?
Im Durchschnitt nicht unbedingt, aber er ist vorhersehbarer, weil kein anderer Mandant den Cluster teilt. Der Vorteil zeigt sich vor allem unter Dauerlast und bei Lastspitzen.
Muss ich die Geräte-Firmware für den Wechsel zu Dedicated neu schreiben?
Nein, sofern die Verbindungseinstellungen konfigurierbar sind. Protokoll und Ports bleiben gleich, es ändern sich nur Hostname und Zugangsdaten.
Kann ich nach dem Wechsel zu Dedicated einen Serverless-Broker behalten?
Ja. Viele Teams behalten einen kostenlosen Serverless-Broker für Entwicklung und Tests und betreiben die Produktion auf dem dedizierten Cluster.
Beinhaltet ein dedizierter Broker eine Replikation über Regionen hinweg?
Gehen Sie nicht davon aus. Fragen Sie nach der konkreten Bereitstellung und gestalten Sie Geräte so, dass sie sich mit Backoff neu verbinden und ihren Zustand erneut publizieren, damit sie sich nach jedem Broker-Neustart sauber erholen.
