Konfigurieren der MQTT-Brokerpersistenz

Die Datenpersistenzfunktion ist als ergänzender Mechanismus für das Replikationssystem konzipiert. Während der Broker Daten knotenübergreifend repliziert, kann ein clusterweites Herunterfahren trotzdem zu Datenverlust führen.

Um dieses Risiko zu minimieren, unterstützt der MQTT-Broker persistenten Speicher, wodurch wichtige Daten auf Datenträger geschrieben und bei Neustarts beibehalten werden können. Diese Datenpersistenzfunktion unterscheidet sich vom datenträgergestützten Nachrichtenpuffer, der Datenträger als Erweiterung des Arbeitsspeichers verwendet, aber kurzlebig ist und keine Dauerhaftigkeitsgarantien bietet.

Das Speichern von Daten auf dem Datenträger führt zu Leistungseinbußen. Die Auswirkungen variieren je nach Typ und Geschwindigkeit des zugrunde liegenden Speichermediums.

Sie können die Datenpersistenz während der Erstbereitstellung mithilfe des Azure-Portals oder der Azure CLI konfigurieren. Sie können auch einige Persistenzoptionen nach der Bereitstellung ändern.

Konfigurationsmethoden

Konfigurieren Sie die Datenpersistenz für den MQTT-Broker mithilfe einer der folgenden Methoden:

• Azure-Portal: Konfigurieren Sie Persistenzeinstellungen über die grafische Benutzeroberfläche während der IoT Operations-Bereitstellung.
• Azure CLI: Verwenden Sie eine JSON-Konfigurationsdatei mit dem Flag --broker-config-file, wenn Sie IoT Operations mithilfe des Befehls az iot ops create bereitstellen.

Eine vollständige Liste der verfügbaren Einstellungen finden Sie in der Dokumentation zur Azure IoT Operations-API.

Konfigurationsoptionen zur Bereitstellungszeit

Sie müssen diese Optionen während der Bereitstellung festlegen und können sie später nicht mehr ändern.

Volume und Volumegröße

Der MQTT-Broker verwendet ein persistentes Volume (PV), um Daten auf dem Datenträger zu speichern. Mit zwei Einstellungen wird gesteuert, wie dieses Volume bereitgestellt wird:

• maxSize (erforderlich): Legt die maximale Größe des persistenten Volumes zum Speichern von Brokerdaten fest. Dieses Feld ist immer erforderlich, auch wenn Sie einen benutzerdefinierten Volumeanspruch angeben. Der Wert muss größer als 100 MB sein.

  Beispiel:10GiB

• persistentVolumeClaimSpec (optional): Hiermit können Sie eine benutzerdefinierte PersistentVolumeClaim-Vorlage (PVC) definieren, um zu steuern, wie das persistente Volume bereitgestellt wird. Wenn Sie diese Option nicht festlegen, erstellt der Broker einen Standard-PVC unter Verwendung des angegebenen maxSize-Werts und der Standardspeicherklasse. Dies kann zu einer suboptimalen Leistung führen, wenn die Standardklasse nicht von einer lokalen Pfadbereitstellung unterstützt wird.

Verschlüsselung

Um Daten zu schützen, verschlüsselt der MQTT-Broker standardmäßig alle Persistenzdaten auf dem Datenträger mit starker AES-256-GCM-Verschlüsselung. Dadurch wird sichergestellt, dass auch dann, wenn ein Angreifer Zugriff auf das zugrunde liegende Volume erhält, der vertrauliche Brokerstatus oder Sitzungsdaten geschützt bleiben.

Die Verschlüsselung ist optional und ist standardmäßig aktiviert. Sie können die Verschlüsselung deaktivieren, falls erforderlich. Verschlüsselung schützt ruhende Daten nur. Daten im Arbeitsspeicher werden nicht verschlüsselt. Die Verwendung der Verschlüsselung führt zu minimalen Leistungseinbußen, aber die Schlüsselrotation wird noch nicht unterstützt.

{
  "persistence": {
    "encryption": {
      "mode": "Disabled"
    }
  }
}

Laufzeitkonfigurationsoptionen

Diese Optionen können aktualisiert werden, nachdem Sie den Azure IoT Operations-MQTT-Broker bereitgestellt haben.

Persistenz aufbewahrter Nachrichten

Aufbewahrte Nachrichten sind MQTT-Nachrichten, die der Broker speichert und an neue Abonnenten übermittelt, wenn sie eine Verbindung mit einem Thema herstellen. Diese Nachrichten helfen sicherzustellen, dass Abonnenten die neuesten Daten erhalten, auch wenn sie nicht verbunden waren, als die Nachricht ursprünglich veröffentlicht wurde. Dies ist besonders nützlich für Statusaktualisierungen, Konfigurationsdaten oder zuletzt bekannte Werte, die neue Abonnenten sofort bei der Verbindungsherstellung benötigen.

Durch das Beibehalten aufbewahrter Nachrichten auf dem Datenträger wird sichergestellt, dass diese wichtigen Nachrichten den Neustart des Brokers überstehen und während der Wartung oder bei unerwartetem Herunterfahren nicht verloren gehen. Ohne Persistenz sind aufbewahrte Nachrichten nur im Arbeitsspeicher vorhanden und gehen verloren, wenn der Broker neu gestartet wird. Dadurch können neue Abonnenten wichtige Anfangsdaten nicht erhalten.

Diese Einstellung steuert, welche aufbewahrten Nachrichten auf dem Datenträger beibehalten werden.

• mode (erforderlich, wenn retain festgelegt wird): Optionen sind None, All oder Custom.

  • None: Es werden keine aufbewahrten Nachrichten beibehalten.
  • All: Alle aufbewahrten Nachrichten werden beibehalten.
  • Custom: Nur die in retainSettings.topics aufgelisteten Themen werden beibehalten.

• Wenn Sie Custom auswählen:

  • retainSettings.topics (optional): Liste der beizubehaltenden Themenmuster. Die Platzhalterzeichen # und + werden unterstützt.

  • retainSettings.dynamic.mode (optional, Standardeinstellung: Enabled): Ermöglicht MQTT-Clients das Anfordern der Datenträgerpersistenz für aufbewahrte Nachrichten mithilfe einer MQTT v5-Benutzereigenschaft.

az iot ops broker persist update --resource-group <ResourceGroupName> --instance <AioInstanceName> --name <BrokerName> --persist-mode retain=<PersistMode> --retain-topics "<TopicPattern1>" "<TopicPattern2>"

az iot ops broker persist update --resource-group myResourceGroup --instance myAioInstance --name myBroker --persist-mode retain=Custom --retain-topics "sensor1" "factory/#" "groundfloor/+/temperature"

Persistenz der Abonnentenwarteschlange

Abonnentenwarteschlangen enthalten Nachrichten, die auf die Zustellung an MQTT-Clients mit QoS 1-Abonnements (Quality of Service) warten. Wenn ein Client QoS 1 abonniert, garantiert der Broker die Nachrichtenzustellung, indem Nachrichten in die Warteschlange gesetzt werden, bis der Client den Empfang bestätigt. Diese Warteschlangen sind besonders wichtig für Clients, deren Verbindung vorübergehend getrennt wird oder die Nachrichten langsam verarbeiten.

Durch das Beibehalten von Abonnentenwarteschlangen auf dem Datenträger wird sichergestellt, dass Nachrichten, die auf die Zustellung warten, während Brokerneustarts nicht verloren gehen. Dieses Feature ist für IoT-Szenarien wichtig, in denen Geräte zeitweise Konnektivität, langsame Verarbeitung oder persistente Sitzungen aufweisen können, die die Nachrichtenzustellung über Brokerneustarts hinweg gewährleisten müssen. Ohne Persistenz gehen Nachrichten in der Warteschlange verloren. Dies kann zu Datenverlust für wichtige Gerätekommunikation führen.

Weitere Informationen zu Abonnentenwarteschlangen und Nachrichtenzustellung finden Sie unter Konfigurieren von Broker-MQTT-Clientoptionen.

Diese Einstellung steuert, welche Abonnentennachrichtenwarteschlangen auf dem Datenträger beibehalten werden. Metadaten zum Sitzungszustand werden unabhängig von diesen Einstellungen immer beibehalten.

• mode (erforderlich, wenn subscriberQueue festgelegt wird): Optionen sind None, All oder Custom.

• Wenn Sie Custom auswählen:

  • subscriberQueueSettings.subscriberClientIds (optional): Liste der Abonnentenclient-IDs, die beibehalten werden sollen. Platzhalter (*) werden unterstützt.

  • subscriberQueueSettings.dynamic.mode (optional, Standardeinstellung: Enabled): Ermöglicht MQTT-Clients, Persistenz dynamisch anzufordern.

az iot ops broker persist update --resource-group <ResourceGroupName> --instance <AioInstanceName> --name <BrokerName> --persist-mode subscriberQueue=<PersistMode>

az iot ops broker persist update --resource-group myResourceGroup --instance myAioInstance --name myBroker --persist-mode subscriberQueue=All

Persistenz für Sitzungsablauf und Abonnentenwarteschlange

Zum Beibehalten von Abonnentennachrichtenwarteschlangen auf dem Datenträger müssen sowohl das Sitzungsablaufintervall als auch die Persistenzkonfiguration des Brokers aufeinander abgestimmt werden. Dies gilt insbesondere in folgenden Fällen:

• MQTTv5-Clients: Kann das Sitzungsablaufintervall mithilfe der Eigenschaft für das Sitzungsablaufintervall von CONNECT- oder DISCONNECT-Paketen angeben. Sie können das Persistenzverhalten der Datenträger auch mit einer angegebenen Benutzereigenschaft anfordern.

• MQTTv3-Clients: Wenn das Flag „Clean Session“ auf „true“ festgelegt ist, wird das Ablaufintervall der Sitzung auf 0 festgelegt. Andernfalls wird der Wert der maxSessionExpirySeconds-Konfiguration im Broker verwendet.

Der Broker behandelt die Persistenz der Abonnentenwarteschlange je nach Konfigurationsmodus und Sitzungsablaufintervall unterschiedlich:

Wenn der Modus auf None festgelegt ist:

• Alle Abonnentenwarteschlangen bleiben nur im Arbeitsspeicher, unabhängig vom Ablaufintervall der Sitzung

Wenn der Modus auf All festgelegt ist:

• Wenn das Sitzungsablaufintervall gleich 0 ist: Warteschlangen bleiben im Arbeitsspeicher.
• Wenn das Sitzungsablaufintervall > 0 ist: Warteschlangen werden für die Dauer des Intervalls auf dem Datenträger beibehalten.

Wenn der Modus auf Custom festgelegt ist:

• Wenn das Sitzungsablaufintervall gleich 0 ist: Warteschlangen bleiben im Arbeitsspeicher.
• Wenn das Sitzungsablaufintervall > 0 ist: Warteschlangen werden nur in folgenden Fällen für die Dauer des Intervalls auf dem Datenträger beibehalten:
  • Die Client-ID entspricht der konfigurierten Liste in subscriberQueueSettings.subscriberClientIds, ODER
  • Der dynamische Modus ist aktiviert, und ein MQTTv5-Client stellt die entsprechende Benutzereigenschaft im CONNECT-Paket bereit.

Um sicherzustellen, dass Abonnentenwarteschlangen auf dem Datenträger beibehalten werden, beachten Sie die folgenden wichtigen Punkte:

• Abonnentenwarteschlangen werden nur beibehalten, wenn das Ablaufintervall der Sitzung größer als 0 ist.
• Für den benutzerdefinierten Modus (Custom) muss entweder die Client-ID explizit aufgeführt sein, oder die dynamische Persistenz muss mit der richtigen Benutzereigenschaft aktiviert werden.
• MQTTv5-Clients können dynamische Persistenz verwenden, indem die konfigurierte Benutzereigenschaft (Standardeinstellung: aio-persistence=true) in das CONNECT-Paket eingeschlossen wird.

Persistenz des Zustandsspeichers

Der Zustandsspeicher ist eine interne Komponente des MQTT-Brokers, die verschiedene Arten von Betriebsdaten und Metadaten über MQTT-Standardnachrichten hinweg verwaltet. Dazu gehören Brokerkonfigurationsstatus, Sitzungsinformationen, Abonnementdetails und andere interne Datenstrukturen, die der Broker zum effizienten Verwalten von Clientverbindungen und für das Nachrichtenrouting verwendet.

Durch das Beibehalten von Zustandsspeicherdaten auf dem Datenträger wird sichergestellt, dass der Broker die Betriebskontinuität über Neustarts hinweg aufrecht erhalten kann. Dies ist besonders wichtig für komplexe IoT-Bereitstellungen, bei denen der Verlust des internen Zustands zu Verbindungsproblemen, Abonnementverlusten oder Leistungsbeeinträchtigungen führen kann, da der Broker seine internen Datenstrukturen von Grund auf neu erstellt.

Die Persistenz des Zustandsspeichers ist besonders in Produktionsumgebungen nützlich, in denen die Minimierung der Wiederherstellungszeit und die Aufrechterhaltung der Dienstkonsistenz entscheidend sind. Ohne Persistenz muss der Broker beim Neustart alle internen Zustände neu erstellen, was zu temporären Dienstunterbrechungen und Leistungseinbußen führen kann.

Weitere Informationen zum Zustandsspeicher finden Sie unter Zustandsspeicherprotokoll.

Diese Einstellung steuert, welche Schlüssel im internen Zustandsspeicher beibehalten werden.

• mode (erforderlich, wenn „stateStore“ festgelegt wird): Optionen sind None, All oder Custom.

• Wenn Sie Custom auswählen:

  • stateStoreSettings.stateStoreResources (optional): Liste der Schlüsseltypen und Schlüssel, die beibehalten werden sollen.

    • keyType: Muster, Zeichenfolge oder Binärdatei

    • keys: Liste der Schlüssel/Muster, die beibehalten werden sollen.

  • stateStoreSettings.dynamic.mode (optional, Standardeinstellung: Enabled): Ermöglicht MQTT-Clients, Persistenz dynamisch anzufordern.

az iot ops broker persist update --resource-group <ResourceGroupName> --instance <AioInstanceName> --name <BrokerName> --persist-mode stateStore=<PersistMode> --state-store-str-keys "<StringKey1>" "<StringKey2>" --state-store-glob-keys "<PatternKey1>" "<PatternKey2>" --state-store-bin-keys "<BinaryKey1>" "<BinaryKey2>"

az iot ops broker persist update --resource-group myResourceGroup --instance myAioInstance --name myBroker --persist-mode stateStore=Custom --state-store-str-keys "device-001" "device-002" --state-store-glob-keys "sensors/*" --state-store-bin-keys "bXlrZXkx" "bXlrZXky"

Anfordern der Persistenz von einem Client mithilfe einer Einstellung für dynamische Persistenz

Clients können Persistenz für ihre Daten anfordern, indem sie eine MQTT v5-Benutzereigenschaft in ihren Nachrichten senden. Auf diese Weise können Clients die Persistenz für ihre Nachrichten, Abonnentenwarteschlangen oder Zustandsspeichereinträge dynamisch aktivieren, ohne die Brokerkonfiguration zu ändern.

Wenn ein Client Persistenz anfordert, überprüft der Broker seine aktuellen Persistenzeinstellungen und wendet sie an. Wenn der angeforderte Persistenzmodus aktiviert und so festgelegt ist, dass dynamische Anforderungen erlaubt sind, behält der Broker die Daten des Clients gemäß der Angabe in der Konfiguration bei.

Sie können die Einstellungen für dynamische Persistenz für jeden Datentyp (aufbewahrte Nachrichten, Abonnentenwarteschlangen und Zustandsspeichereinträge) aktivieren oder deaktivieren, indem Sie dynamic.mode in den entsprechenden Konfigurationsabschnitten auf Enabled festlegen. Der MQTT-Benutzereigenschaftsschlüssel und -wert, die für dynamische Persistenzanforderungen verwendet werden, werden separat auf Brokerebene konfiguriert.

az iot ops broker persist update --resource-group <ResourceGroupName> --instance <AioInstanceName> --name <BrokerName> --persist-mode <PersistMode>

az iot ops broker persist update --resource-group myResourceGroup --instance myAioInstance --name myBroker --persist-mode subscriberQueue=Custom --subscriber-client-ids "factory-client-*" "sensor-gateway-01"

Verwandte Inhalte

Weitere Informationen zur Azure CLI-Unterstützung für die erweiterte MQTT-Brokerkonfiguration finden Sie unter Azure CLI-Unterstützung für die erweiterte MQTT-Brokerkonfiguration.