Konfigurieren des Verhaltens des datenträgergestützten Nachrichtenpuffers

Artikel
11/21/2024

Wichtig

Diese Einstellung erfordert das Ändern der Brokerressource und kann nur zur ersten Bereitstellungszeit mithilfe der Azure CLI oder des Azure-Portals konfiguriert werden. Eine neue Bereitstellung ist erforderlich, wenn Änderungen an der Broker-Konfiguration erforderlich sind. Weitere Informationen finden Sie unter Anpassen des Standardbrokers.

Das Feature datenträgergestützer Nachrichtenpuffer wird für die effiziente Verwaltung von Nachrichtenwarteschlangen im verteilten MQTT-Broker verwendet. Zu diesen Vorteilen gehören:

Effiziente Warteschlangenverwaltung: In einem MQTT Vermittler ist jeder Abonnent einer Nachrichtenwarteschlange zugeordnet. Die Geschwindigkeit, mit der ein Abonnent Nachrichten verarbeitet, wirkt sich direkt auf die Größe der Warteschlange aus. Wenn ein Abonnent Nachrichten langsam verarbeitet oder die Verbindung trennt und trotzdem eine persistente MQTT-Sitzung anfordert, kann die Warteschlange größer als der verfügbare Arbeitsspeicher werden.
Datenbeibehaltung für persistente Sitzungen: Das Feature „datenträgergestützter Nachrichtenpuffer“ stellt eine nahtlose Pufferung auf dem Datenträger sicher, wenn eine Warteschlange den verfügbaren Arbeitsspeicher überschreitet. Dieses Feature verhindert Datenverlust und unterstützt persistente MQTT-Sitzungen, sodass Abonnenten ihre Sitzungen mit ihren Nachrichtenwarteschlangen bei erneuter Verbindung problemlos fortsetzen können. Der Datenträger wird als kurzlebiger Speicher verwendet und dient als Überlauf für den Arbeitsspeicher. Daten, die auf den Datenträger geschrieben werden, sind nicht dauerhaft und gehen verloren, wenn der Pod beendet wird. Solange aber mindestens ein Pod in jeder Back-End-Kette funktionsfähig bleibt, verliert der Broker als Ganzes keine Daten.
Behandlung von Konnektivitätsproblemen: Cloudconnectors werden als Abonnenten mit persistenten Sitzungen behandelt, die mit Konnektivitätsproblemen konfrontiert werden können, wenn sie aufgrund einer getrennten Netzwerkverbindung nicht mit externen Systemen wie dem Event Grid-MQTT Vermittler kommunizieren können. In solchen Szenarien sammeln sich Nachrichten (PUBLISHes) an. Der MQTT-Broker puffert diese Nachrichten intelligent im Arbeitsspeicher oder auf dem Datenträger, bis die Verbindung wiederhergestellt wird, und stellt so die Nachrichtenintegrität sicher.

Standardmäßig ist das Feature für datenträgergestützte Nachrichtenpuffer deaktiviert. In diesem Fall bleiben Nachrichten im Speicher und es wird ein Gegendruck auf die Kunden ausgeübt, wenn der Leserpool oder der Scratch-Pool die durch die Begrenzung der Abonnentenwarteschlange definierte Grenze erreicht.

Die Konfiguration des datenträgerbasierten Nachrichtenpuffers ist für die Aufrechterhaltung eines robusten und zuverlässigen Message-Queuing-Systems von entscheidender Bedeutung – insbesondere in Szenarien, in denen die Geschwindigkeit der Nachrichtenverarbeitung und die Konnektivität von entscheidender Bedeutung sind.

Hinweis

Der MQTT-Broker schreibt die Daten genau so auf den Datenträger, wie sie von den Clients empfangen wurden, ohne zusätzliche Verschlüsselung. Die Sicherung des Datenträgers ist unerlässlich, um die vom Broker gespeicherten Daten zu schützen.

Konfigurationsoptionen

Um den Datenträger-gesicherten Nachrichtenpuffer zu konfigurieren, bearbeiten Sie den Abschnitt diskBackedMessageBuffer in der Brokerressource. Derzeit wird dies nur durch die Verwendung des --broker-config-file-Flags unterstützt, wenn Sie die Azure IoT Einsatz mit dem Befehl az iot ops create bereitstellen.

Bereiten Sie zunächst eine Broker-Konfigurationsdatei gemäß der DiskBackedMessageBuffer-API-Referenz vor.

Zum Beispiel umfasst die einfachste Konfiguration nur die Angabe der maximalen Größe. In diesem Fall wird ein emptyDir-Volume bereitgestellt. Der maxSize -Wert wird als Größenbeschränkung des Volumes emptyDir verwendet. Dies ist jedoch die am wenigsten bevorzugte Option, die die Einschränkungen emptyDir Volumes gibt.

{
  "diskBackedMessageBuffer": {
    "maxSize": "<SIZE>"
  }
}

Um eine bessere Konfiguration des datenträgergestützten Nachrichtenpuffers zu erhalten, geben Sie einen Anspruch auf ein kurzlebiges oder persistentes Volume an, um ein dediziertes Speichervolume für Ihren Nachrichtenpuffer bereitzustellen. Zum Beispiel:

{
  "diskBackedMessageBuffer": {
    "maxSize": "<SIZE>",
    "ephemeralVolumeClaimSpec": {
      "storageClassName": "<NAME>",
      "accessModes": [
        "<MODE>"
      ]
    }
  }
}

{
  "persistentVolumeClaimSpec": {
    "maxSize": "<SIZE>",
    "ephemeralVolumeClaimSpec": {
      "storageClassName": "<NAME>",
      "accessModes": [
        "<MODE>"
      ]
    }
  }
}

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

Konfigurieren des Volumes: Geben Sie eine Vorlage für die Datenträgerzuweisung an, um einen dedizierten Datenträger für Ihren Nachrichtenpuffer bereitzustellen.
Auswählen einer Speicherklasse: Definieren Sie die gewünschte StorageClass mithilfe der storageClassName-Eigenschaft.
Zugriffsmodi definieren: Bestimmen Sie die Zugriffsmodi, die Sie für Ihr Volume benötigen. Weitere Informationen finden Sie im Artikel zu Zugriffsmodi für persistente Volumes.

Sehen Sie sich die folgenden Abschnitte an, um die verschiedenen Volumemodi zu verstehen:

Ein kurzlebiges Volume ist die bevorzugte Option.
Als Nächstes werden persistente Volumesbevorzugt.
emptyDir Volume wird am wenigsten bevorzugt.

Sowohl persistente als auch kurzlebige Volumes werden in der Regel von den gleichen Speicherklassen bereitgestellt. Wenn beide Optionen verfügbar sind, wählen Sie kurzlebige aus. Beachten Sie, dass kurzlebige Volumes Kubernetes 1.23 oder höher erfordern.

Tipp

Durch die Angabe einer EVC- (Ephemeral Volume Claim) oder PVC-Vorlage (Persistent Volume Claim) können Sie eine Speicherklasse Ihrer Wahl verwenden, was die Flexibilität für einige Bereitstellungsszenarien erhöht. Beispielsweise werden persistente Volumes (PVs), die mithilfe einer PVC-Vorlage bereitgestellt wurden, in Befehlen wie kubectl get pv angezeigt, was für die Überprüfung des Clusterzustands nützlich sein kann.

Wenn Ihre Kubernetes-Knoten nicht über ausreichend lokalen Speicherplatz für den Nachrichtenpuffer verfügen, verwenden Sie eine Speicherklasse, die Netzwerkspeicher wie Azure Blobs bereitstellt. Im Allgemeinen ist es jedoch besser, eine lokale Festplatte mit einem kleineren maxSize-Wert zu verwenden, da der Nachrichtenpuffer von einem schnellen Zugriff profitiert und keine Langlebigkeit erfordert.

Implementieren von Azure IoT Einsatz mit datenträgergestütztem Nachrichtenpuffer

Um einen datenträgergestützten Nachrichtenpuffer zu verwenden, stellen Sie Azure IoT Einsatz mit dem Befehl az iot ops create und dem --broker-config-file-Flag bereit. Sehen Sie sich den folgenden Befehl an (andere Parameter wurden der Kürze halber weggelassen):

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

Diese Einstellung kann nach der Bereitstellung nicht mehr geändert werden. Um die Konfiguration des datenträgergestützten Nachrichtenpuffers zu ändern, stellen Sie die Azure IoT Einsatz-Instanz neu bereit.

Kurzlebige Datenträger

Ein kurzlebiges Volume ist die bevorzugte Option für den Nachrichtenpuffer.

Befolgen Sie für ein kurzlebiges Volume die Ratschläge im Abschnitt Überlegungen für Speicheranbieter.

Der Wert der Eigenschaft ephemeralVolumeClaimSpec wird als ephemeral.volumeClaimTemplate.spec-Eigenschaft des Volumens in den StatefulSet-Spezifikationen der Back-End-Ketten verwendet.

Wenn Sie z. B. ein kurzlebiges Volume mit einer Kapazität von 1 Gigabyte verwenden möchten, geben Sie die folgenden Parameter in der Broker-Ressource an:

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

Persistentes Volume

Ein persistentes Volume ist nach dem kurzlebigen Volume die nächste bevorzugte Option für den Nachrichtenpuffer.

Befolgen Sie für ein persistentes Volume die Ratschläge im Abschnitt Überlegungen für Speicheranbieter.

Der Wert der Eigenschaft persistentVolumeClaimSpec wird als volumeClaimTemplates.spec-Eigenschaft der StatefulSet-Spezifikationen der Back-End-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 der Broker-Ressource an:

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

`emptyDir`-Volume

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

Verwenden Sie emptyDir-Volumes nur bei Verwendung eines Clusters mit Dateisystemkontingenten. Weitere Informationen finden Sie in den Details auf der Registerkarte „Filesystem project quota“. Wenn das Feature nicht aktiviert ist, führt der Cluster regelmäßige Überprüfungen durch, die keinen Grenzwert erzwingen und es dem Hostknoten ermöglichen, Speicherplatz auszufüllen und den gesamten Hostknoten als fehlerhaft zu markieren.

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

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

Überlegungen für Speicheranbieter

Berücksichtigen Sie das Verhalten des ausgewählten Speicheranbieters. Betrachten Sie als Beispiel die Nutzung von Anbietern wie rancher.io/local-path. Wenn der Anbieter keine Grenzwerte unterstützt, verbraucht das Auffüllen des Volumes den Speicherplatz des Knotens. Dies könnte dazu führen, dass Kubernetes den Knoten und alle zugehörigen Pods als fehlerhaft markiert. Es ist wichtig zu verstehen, wie sich Ihr Speicheranbieter in solchen Szenarien verhält.

Disabled

Wenn Sie den datenträgergestützten Nachrichtenpuffer nicht verwenden möchten, schließen Sie die diskBackedMessageBufferSettings-Eigenschaft nicht in die Broker-Ressource ein. Dies ist auch das Standardverhalten.

Persistenz

Es ist wichtig zu verstehen, dass das Feature „datenträgergestützter Nachrichtenpuffer“ nicht gleichbedeutend mit Persistenz ist. In diesem Zusammenhang bezieht sich Persistenz auf Daten, die über Pod-Neustarts hinweg erhalten bleiben. Dieses Feature bietet jedoch temporären Speicherplatz, damit Daten auf dem Datenträger gespeichert werden können, was Speicherüberläufe und Datenverlust während des Neustarts von Pods verhindert.

Freigeben über