Bereitstellungsplanung – Datenträgergestützter Nachrichtenpuffer

Der datenträgerbasierte Nachrichtenpuffer ist eine Funktion, mit der der MQTT-Broker die Nachrichtenwarteschlangen von Abonnenten auf den Datenträger auslagern kann, wenn sie den verfügbaren Arbeitsspeicher überschreiten. Entscheiden Sie vor der Bereitstellung, ob Sie für den MQTT-Broker datenträgergestützte Nachrichtenpufferung benötigen.

Die festplattengestützte Nachrichtenpufferungsfunktion wird zur effizienten Verwaltung von Nachrichtenwarteschlangen im verteilten MQTT-Broker verwendet. Zu den Vorteilen gehören:

• Effiziente Warteschlangenverwaltung: In einem MQTT-Broker ist jeder Abonnent einer Nachrichtenwarteschlange zugeordnet. Die Nachrichtenverarbeitungsgeschwindigkeit eines Abonnenten wirkt sich direkt auf die Größe der Warteschlange aus. Wenn ein Abonnent Nachrichten nur langsam verarbeitet oder die Verbindung trennt, aber eine persistente MQTT-Sitzung anfordert, kann die Warteschlange auf eine Größe anwachsen, die den verfügbaren Arbeitsspeicher übersteigt.
• Datenerhalt für persistente Sitzungen: Die Funktion zur datenträgergestützten Nachrichtenpufferung stellt sicher, dass eine Warteschlange, wenn sie den verfügbaren Arbeitsspeicher überschreitet, nahtlos auf dem Datenträger zwischengespeichert wird. Diese Funktion verhindert Datenverlust und unterstützt persistente MQTT-Sitzungen, sodass Abonnenten ihre Sitzungen fortsetzen können, wobei ihre Nachrichtenwarteschlangen erhalten bleiben, wenn sie sich erneut verbinden. Der Datenträger wird als kurzlebiger Speicher verwendet und dient als Überlauf für den Arbeitsspeicher. Auf die Festplatte geschriebene Daten sind nicht persistent und gehen beim Beenden des Pods verloren. Wenn mindestens ein Pod in jeder Back-End-Kette funktionsfähig bleibt, verliert der Broker insgesamt keine Daten.
• Umgang mit Konnektivitätsproblemen: Cloud-Connectors werden als Abonnenten mit persistenten Sitzungen behandelt, bei denen Verbindungsprobleme auftreten können, wenn sie aufgrund einer Netzwerkunterbrechung nicht mit externen Systemen wie einem Azure Event Grid MQTT-Broker kommunizieren können. In solchen Szenarien sammeln sich Nachrichten (PUBLISHes) an. Der MQTT-Broker puffert diese Nachrichten intelligent im Speicher oder auf dem Datenträger, bis die Verbindung wiederhergestellt ist, wodurch die Integrität der Nachrichten gewährleistet wird.

Standardmäßig ist die Funktion zur datenträgergestützten Nachrichtenpufferung deaktiviert. In diesem Fall verbleiben Nachrichten im Arbeitsspeicher, und der Rückdruck wird auf Clients angewendet, da die Speicherauslastung den Grenzwert erreicht, der durch den Grenzwert der Abonnentenwarteschlange definiert wurde.

Festplattenbasierten Nachrichtenpuffer konfigurieren

Um den Datenträger-gesicherten Nachrichtenpuffer zu konfigurieren, bearbeiten Sie den diskBackedMessageBuffer Abschnitt in der Brokerressource. Derzeit wird diese Konfiguration nur mithilfe des --broker-config-file Flags unterstützt, wenn Sie Azure IoT Einsatz mithilfe des az iot ops create Befehls bereitstellen. Weitere Informationen finden Sie unter Azure CLI-Unterstützung für die erweiterte MQTT-Brokerkonfiguration.

Diese Einstellung kann nach der Bereitstellung nicht mehr geändert werden. Um die Konfiguration des Vom Datenträger gesicherten Nachrichtenpuffers zu ändern, stellen Sie die IoT Operations-Instanz erneut bereit.

Bereiten Sie zunächst eine Brokerkonfigurationsdatei vor, indem Sie der DiskBackedMessageBuffer-API-Referenz folgen.

Stellen Sie dann IoT Operations mit dem --broker-config-file Flag bereit (andere Parameter wurden der Kürze halber weggelassen):

az iot ops create ... --broker-config-file <FILE>.json

Die einfachste Konfiguration umfasst z. B. nur die Angabe der maximalen Größe. In diesem Fall wird ein emptyDir-Volume eingebunden. Der maxSize Wert wird als Größenbeschränkung des emptyDir Volumes verwendet. Diese Option ist jedoch aufgrund der Einschränkungen des emptyDir Volumes die am wenigsten bevorzugte Option.

{
  "diskBackedMessageBuffer": {
    "maxSize": "1G"
  }
}

Um eine bessere Konfiguration des datenträgerbasierten Nachrichtenpuffers zu erhalten, geben Sie ein ephemeres Volume oder einen PersistentVolumeClaim an, um ein dediziertes Speichervolume für Ihren Nachrichtenpuffer einzuhängen. Beispiel:

{
  "diskBackedMessageBuffer": {
    "maxSize": "1G",
    "ephemeralVolumeClaimSpec": {
      "storageClassName": "foo",
      "accessModes": [
        "ReadWriteOnce"
      ]
    }
  }
}

{
  "diskBackedMessageBuffer": {
    "maxSize": "1G",
    "persistentVolumeClaimSpec": {
      "storageClassName": "foo",
      "accessModes": [
        "ReadWriteOnce"
      ]
    }
  }
}

Passen Sie die Optionen für den Brokernachrichtenpuffer an, indem Sie die folgenden Einstellungen anpassen:

• Konfigurieren Sie das Volume: Geben Sie eine Volumeanspruchsvorlage an, um ein dediziertes Speichervolume für den Nachrichtenpuffer bereitzustellen.
• Wählen Sie eine Speicherklasse aus: Definieren Sie die gewünschte Speicherklasse mithilfe der storageClassName Eigenschaft.
• Definieren Sie Zugriffsmodi: Bestimmen Sie die Zugriffsmodi, die Sie für Ihr Volume benötigen. Weitere Informationen finden Sie unter Zugriffsmodi für persistente Volumes.

Kurzlebige Datenträger

Ephemeres Volume ist die bevorzugte Option für Ihren Nachrichtenpuffer.

Befolgen Sie für kurzlebige Volumes die Hinweise im Abschnitt "Überlegungen zu Speicheranbietern ".

Der Wert der Eigenschaft ephemeralVolumeClaimSpec wird als Eigenschaft ephemeral.volumeClaimTemplate.spec des Volumes in den StatefulSet-Spezifikationen der Backend-Ketten verwendet.

Wenn Sie z. B. ein ephemeres Volume mit einer Kapazität von 1 Gigabyte verwenden möchten, geben Sie die folgenden Parameter in Ihrer Brokerressource an:

{
  "diskBackedMessageBuffer": {
    "maxSize": "1G",
    "ephemeralVolumeClaimSpec": {
      "storageClassName": "foo",
      "accessModes": [
        "ReadWriteOnce"
      ]
    }
  }
}

Persistentes Volume

Persistentes Volume ist nach dem ephemeren Volume die nächstbevorzugte Option für Ihren Nachrichtenpuffer.

Befolgen Sie für beständiges Volume die Hinweise im Abschnitt "Überlegungen zu Speicheranbietern ".

Der Wert der persistentVolumeClaimSpec-Eigenschaft wird als volumeClaimTemplates.spec-Eigenschaft in den StatefulSet-Spezifikationen der Backend-Ketten verwendet.

Wenn Sie z. B. ein persistentes Volume mit einer Kapazität von 1 Gigabyte verwenden möchten, geben Sie die folgenden Parameter in Ihrer Brokerressource an:

{
  "diskBackedMessageBuffer": {
    "maxSize": "1G",
    "persistentVolumeClaimSpec": {
      "storageClassName": "foo",
      "accessModes": [
        "ReadWriteOnce"
      ]
    }
  }
}

emptyDir-Volume

Ein emptyDir-Volume ist nach einem persistenten Volume die am wenigsten bevorzugte Option.

Verwenden Sie ein emptyDir Volume nur, wenn Sie einen Cluster mit Dateisystemkontingenten verwenden. Weitere Informationen finden Sie auf der Registerkarte "Dateisystem-Projektkontingent". Wenn das Feature nicht aktiviert ist, führt der Cluster periodische Scans durch, die keine Beschränkungen erzwingen und es dem Hostknoten ermöglichen, Speicherplatz zu füllen und den gesamten Hostknoten als fehlerhaft zu kennzeichnen.

Wenn Sie z. B. ein emptyDir Volume mit einer Kapazität von 1 Gigabyte verwenden möchten, geben Sie die folgenden Parameter in Ihrer Brokerressource an:

{
  "diskBackedMessageBuffer": {
    "maxSize": "1G"
  }
}

Überlegungen zu Speicheranbietern

Berücksichtigen Sie das Verhalten Ihres ausgewählten Speicheranbieters, z. B. wenn Sie Anbieter wie rancher.io/local-path. Wenn der Anbieter keine Grenzwerte unterstützt, verbraucht das Auffüllen des Volumes den Speicherplatz des Knotens. Dieses Verhalten könnte dazu führen, dass Kubernetes den Knoten und alle zugehörigen Pods als nicht funktionsfähig markiert. Es ist wichtig zu verstehen, wie sich Ihr Speicheranbieter in solchen Szenarien verhält.

Disabled

Wenn Sie den Datenträger-gesicherten Nachrichtenpuffer nicht verwenden möchten, schließen Sie die diskBackedMessageBufferSettings Eigenschaft nicht in Ihre Brokerressource ein. Dieses Verhalten ist auch die Standardeinstellung.

Datenträgerpuffer im Vergleich zur Persistenz

Sowohl die datenträgergestützte Nachrichtenpufferung als auch die Brokerpersistenz schreiben Daten auf den Datenträger, dienen jedoch unterschiedlichen Zwecken:

Nächste Schritte

• Überprüfen der Persistenzeinstellungen
• Überprüfen der Diagnoseeinstellungen
• Überprüfen erweiterter MQTT-Optionen
• Vorbereiten des Clusters