Freigeben über

Konfigurieren der Grundlegenden MQTT-Brokereinstellungen

  • Artikel

Wichtig

Die von Azure Arc unterstützte Vorschauversion von „Azure IoT Einsatz“ befindet sich derzeit in der Vorschauphase. Sie sollten diese Vorschausoftware nicht in Produktionsumgebungen verwenden.

Sie müssen eine neue Installation von „Azure IoT Einsatz“ bereitstellen, wenn ein allgemein verfügbares Release verfügbar wird. Sie werden kein Upgrade für eine Preview-Installation durchführen können.

Die zusätzlichen Nutzungsbestimmungen für Microsoft Azure-Vorschauen enthalten rechtliche Bedingungen. Sie gelten für diejenigen Azure-Features, die sich in der Beta- oder Vorschauversion befinden oder aber anderweitig noch nicht zur allgemeinen Verfügbarkeit freigegeben sind.

Die Broker-Ressource ist die Hauptressource, die die allgemeinen Einstellungen für MQTT-Broker definiert. Sie bestimmt auch die Anzahl und den Typ der Pods, die die Broker-Konfiguration ausführen, z. B. die Front-Ends und die Back-Ends. Sie können auch die Brokerressource verwenden, um ihr Speicherprofil zu konfigurieren. In den Broker sind Selbstreparaturmechanismen integriert, und er kann häufig automatisch nach Komponentenausfällen wiederhergestellt werden. Beispiel: Ein Knoten fällt in einem für Hochverfügbarkeit konfigurierten Kubernetes-Cluster aus.

Sie können den MQTT Vermittler horizontal skalieren, indem Sie weitere Front-End-Replikate und Back-End-Ketten hinzufügen. Die Front-End-Replikate sind für die Annahme von MQTT-Verbindungen von Clients und deren Weiterleitung an die Back-End-Ketten zuständig. Die Back-End-Ketten sind für das Speichern und Übermitteln von Nachrichten an die Clients verantwortlich. Die Front-End-Pods verteilen den Datenverkehr auf die Back-End-Pods, und der Back-End-Redundanzfaktor bestimmt die Anzahl der Datenkopien, um die Resilienz gegen Knotenausfälle im Cluster zu gewährleisten.

Eine Liste der verfügbaren Einstellungen finden Sie in der API-Referenz zum Broker.

Konfigurieren von Skalierungseinstellungen

Wichtig

Derzeit kann die Broker-Ressource nur zum Zeitpunkt der erstmaligen Bereitstellung mithilfe der Azure CLI, des Portals oder mit GitHub Actions konfiguriert werden. Eine neue Bereitstellung ist erforderlich, wenn Änderungen an der Broker-Konfiguration erforderlich sind.

Um die Skalierungseinstellungen für den MQTT-Broker zu konfigurieren, müssen Sie die cardinality-Felder in der Spezifikation der benutzerdefinierten Broker-Ressource angeben. Weitere Informationen zum Festlegen der Modus- und Kardinalitätseinstellungen mithilfe der Azure CLI finden Sie unter az iot ops init.

Das Feld cardinality ist ein geschachteltes Feld, das die folgenden Unterfelder aufweist:

  • frontend: In diesem Unterfeld legen Sie die Einstellungen für die Front-End-Pods fest. Beispiel:
    • replicas: Die Anzahl der bereitzustellenden Front-End-Pods. Dieses Unterfeld ist erforderlich, wenn das Feld mode auf distributed festgelegt ist.
    • workers: Die Anzahl der bereitzustellenden Worker pro Front-End (muss derzeit auf 1 festgelegt werden). Dieses Unterfeld ist erforderlich, wenn das Feld mode auf distributed festgelegt ist.
  • backendChain: Dieses Unterfeld legt die Einstellungen für die Back-End-Ketten fest. Beispiel:
    • redundancyFactor: Die Anzahl der Datenkopien in jeder Back-End-Kette. Dieses Unterfeld ist erforderlich, wenn das Feld mode auf distributed festgelegt ist.
    • partitions: Die Anzahl der bereitzustellenden Partitionen. Dieses Unterfeld ist erforderlich, wenn das Feld mode auf distributed festgelegt ist.
    • workers: Die Anzahl der bereitzustellenden Worker pro Back-End (muss derzeit auf 1 festgelegt werden). Dieses Unterfeld ist erforderlich, wenn das Feld mode auf distributed festgelegt ist.

Wenn das Feld cardinality weggelassen wird, wird die Kardinalität bestimmt, indem der Operator für den MQTT-Broker automatisch die entsprechende Anzahl von Pods basierend auf der Clusterhardware bereitstellt.

Um die Skalierungseinstellungen für den MQTT-Broker zu konfigurieren, müssen Sie die Felder mode und cardinality in der Spezifikation der benutzerdefinierten Broker-Ressource angeben. Weitere Informationen zum Festlegen der Modus- und Kardinalitätseinstellungen mithilfe der Azure CLI finden Sie unter az iot ops init.

Konfigurieren des Arbeitsspeicherprofils

Wichtig

Derzeit kann die Broker-Ressource nur zum Zeitpunkt der erstmaligen Bereitstellung mithilfe der Azure CLI, des Portals oder mit GitHub Actions konfiguriert werden. Eine neue Bereitstellung ist erforderlich, wenn Änderungen an der Broker-Konfiguration erforderlich sind.

Um die Arbeitsspeichersprofileinstellungen des MQTT-Brokers zu konfigurieren, geben Sie die memoryProfile-Felder in der Spezifikation der benutzerdefinierten Broker-Ressource an. Weitere Informationen zum Festlegen der Arbeitsspeicherprofileinstellung mithilfe der Azure CLI finden Sie unter az iot ops init.

memoryProfile: Dieses Unterfeld definiert die Einstellungen für das Arbeitsspeicherprofil. Es gibt einige Profile für die Speicherauslastung, die Sie auswählen können:

Sehr klein

Bei Verwendung dieses Profils:

  • Die maximale Speicherauslastung jedes Front-End-Replikats beträgt etwa 99 MiB, aber die tatsächliche maximale Speicherauslastung kann höher sein.
  • Die maximale Speicherauslastung jedes Back-End-Replikats beträgt etwa 102 MiB, aber die tatsächliche maximale Speicherauslastung kann höher sein.

Empfehlungen bei Verwendung dieses Profils:

  • Es sollte nur ein Front-End verwendet werden.
  • Clients sollten keine großen Pakete senden. Sie sollten nur Pakete senden, die kleiner als 4 MiB sind.

Niedrig

Bei Verwendung dieses Profils:

  • Die maximale Speicherauslastung jedes Front-End-Replikats beträgt etwa 387 MiB, aber die tatsächliche maximale Speicherauslastung kann höher sein.
  • Die maximale Speicherauslastung jedes Back-End-Replikats beträgt etwa 390 MiB multipliziert mit der Anzahl der Back-End-Worker, aber die tatsächliche maximale Speicherauslastung kann höher sein.

Empfehlungen bei Verwendung dieses Profils:

  • Es sollten nur ein oder zwei Front-Ends verwendet werden.
  • Clients sollten keine großen Pakete senden. Sie sollten nur Pakete senden, die kleiner als 10 MiB sind.

Medium

„Mittel“ ist das Standardprofil.

  • Die maximale Speicherauslastung jedes Front-End-Replikats beträgt etwa 1,9 GiB, aber die tatsächliche maximale Speicherauslastung kann höher sein.
  • Die maximale Speicherauslastung jedes Back-End-Replikats beträgt etwa 1,5 GiB multipliziert mit der Anzahl der Back-End-Worker, aber die tatsächliche maximale Speicherauslastung kann höher sein.

Hoch

  • Die maximale Speicherauslastung jedes Front-End-Replikats beträgt etwa 4,9 GiB, aber die tatsächliche maximale Speicherauslastung kann höher sein.
  • Die maximale Speicherauslastung jedes Back-End-Replikats beträgt etwa 5,8 GiB multipliziert mit der Anzahl der Back-End-Worker, aber die tatsächliche maximale Speicherauslastung kann höher sein.

Standardbroker

Standardmäßig stellt Azure IoT Einsatz Preview eine Standardbrokerressource mit dem Namen „default“ bereit. Sie wird im Namespace „azure-iot-operations“ mit Kardinalitäts- und Arbeitsspeicherprofileinstellungen bereitgestellt, die während der Erstbereitstellung über das Azure-Portal oder die Azure CLI konfiguriert wurden. Um die Einstellungen anzuzeigen, führen Sie den folgenden Befehl aus:

kubectl get broker default -n azure-iot-operations -o yaml

Ändern des Standardbrokers durch erneute Bereitstellung

Nur Kardinalität und Arbeitsspeicherprofil können während der Erstbereitstellung über das Azure-Portal oder die Azure CLI konfiguriert werden. Andere Einstellungen können nur konfiguriert werden, indem die YAML-Datei geändert und der Broker erneut bereitgestellt wird.

Führen Sie den folgenden Befehl aus, um den Standardbroker zu löschen:

kubectl delete broker default -n azure-iot-operations

Erstellen Sie dann eine YAML-Datei mit den gewünschten Einstellungen. Die folgende YAML-Datei konfiguriert beispielsweise den Broker mit dem Namen „default“ im Namespace „azure-iot-operations“ mit dem Arbeitsspeicherprofil „medium“ und dem distributed-Modus. Es gibt zwei Front-End-Replikate und zwei Back-End-Ketten mit jeweils zwei Partitionen und zwei Workern. Außerdem ist die Option für die Verschlüsselung des internen Datenverkehrs deaktiviert.

apiVersion: mqttbroker.iotoperations.azure.com/v1beta1
kind: Broker
metadata:
  name: default
  namespace: azure-iot-operations
spec:
  memoryProfile: medium
  cardinality:
    backendChain:
      partitions: 2
      redundancyFactor: 2
      workers: 2
    frontend:
      replicas: 2
      workers: 2
  encryptInternalTraffic: false

Führen Sie den folgenden Befehl aus, um den Broker bereitzustellen:

kubectl apply -f <path-to-yaml-file>

Konfigurieren der erweiterten Einstellungen des MQTT-Brokers

Zu den erweiterten Einstellungen des Brokers gehören Clientkonfigurationen, Verschlüsselung des internen Datenverkehrs und Zertifikatrotationen. Weitere Informationen zu den erweiterten Einstellungen finden Sie in der API-Referenz zum Broker.

Hier sehen Sie ein Beispiel für einen Broker mit erweiterten Einstellungen:

apiVersion: mqttbroker.iotoperations.azure.com/v1beta1
kind: Broker
metadata:
  name: default
  namespace: azure-iot-operations
spec:
  advanced:
    clients:
        maxSessionExpirySeconds: 282277
        maxMessageExpirySeconds: 1622
        subscriberQueueLimit:
          length: 1000
          strategy: DropOldest
        maxReceiveMaximum: 15000
        maxKeepAliveSeconds: 300
    encryptInternalTraffic: Enabled
    internalCerts:
      duration: 240h
      renewBefore: 45m
      privateKey:
        algorithm: Rsa2048
        rotationPolicy: Always

Konfigurieren von Diagnoseeinstellungen für den MQTT-Broker

Mithilfe von Diagnoseeinstellungen können Sie Metriken und Ablaufverfolgungen für den MQTT-Broker aktivieren.

  • Metriken liefern Informationen zur Ressourcenauslastung und zum Durchsatz des MQTT-Brokers.
  • Die Ablaufverfolgung enthält detaillierte Informationen zu den Anforderungen und Antworten, die vom MQTT-Broker verarbeitet werden.

Um die Standarddiagnoseeinstellungen für den MQTT-Broker außer Kraft zu setzen, aktualisieren Sie den Abschnitt spec.diagnostics in der Broker-Ressource. Passen Sie die Protokollebene an, um die Menge und Details der protokollierten Informationen zu steuern. Die Protokollebene kann für verschiedene Komponenten des MQTT-Brokers festgelegt werden. Die Standardprotokollebene ist info.

Sie können die Diagnose mithilfe der benutzerdefinierten Ressourcendefinition (Custom Resource Definition, CRD) des Brokers konfigurieren. Weitere Informationen zu den Diagnoseeinstellungen finden Sie in der API-Referenz zum Broker.

Hier sehen Sie ein Beispiel für eine benutzerdefinierte Broker-Ressource mit aktivierten Metriken und Ablaufverfolgungen und deaktivierter Selbstüberprüfung:

apiVersion: mqttbroker.iotoperations.azure.com/v1beta1
kind: Broker
metadata:
  name: broker
  namespace: azure-iot-operations
spec:
  diagnostics:
    logs:
      level: "debug"
      opentelemetryExportConfig:
        otlpGrpcEndpoint: "endpoint"
    metrics:
      opentelemetryExportConfig:
        otlpGrpcEndpoint: "endpoint"
        intervalSeconds: 60
    selfCheck:
      mode: Enabled
      intervalSeconds: 120
      timeoutSeconds: 60
    traces:
      cacheSizeMegabytes: 32
      mode: Enabled
      opentelemetryExportConfig:
        otlpGrpcEndpoint: "endpoint"
      selfTracing:
        mode: Enabled
        intervalSeconds: 120
      spanChannelCapacity: 1000

Konfigurieren der Verschlüsselung des internen Datenverkehrs

Wichtig

Dieses Feature kann derzeit nicht mithilfe der Azure CLI oder des Azure-Portals während der Erstbereitstellung konfiguriert werden. Um diese Einstellung zu ändern, müssen Sie die YAML-Datei ändern und den Broker erneut bereitstellen.

Das Feature encryptInternalTraffic wird verwendet, um den internen Datenverkehr zwischen den Front-End- und Back-End-Pods zu verschlüsseln. Um dieses Feature zu verwenden, muss der Zertifikat-Manager im Cluster installiert sein. Dieser ist bei Verwendung von Azure IoT Einsatz standardmäßig installiert.

Zu diesen Vorteilen gehören:

  • Sicherer interner Datenverkehr: Der gesamte interne Datenverkehr zwischen Front-End- und Back-End-Pods wird verschlüsselt.

  • Sichere ruhende Daten: Alle ruhenden Daten werden verschlüsselt.

  • Sichere Daten während der Übertragung: Alle übertragenen Daten werden verschlüsselt.

  • Sichere Daten im Arbeitsspeicher: Alle Daten im Arbeitsspeicher werden verschlüsselt.

  • Sichere Daten im Nachrichtenpuffer: Alle Daten im Nachrichtenpuffer werden verschlüsselt.

  • Sichere Daten im Nachrichtenpuffer auf dem Datenträger: Alle Daten im Nachrichtenpuffer auf dem Datenträger werden verschlüsselt.

Standardmäßig ist das encryptInternalTraffic-Feature aktiviert. Um das Feature zu deaktivieren, legen Sie das Feld encryptInternalTraffic in der Spezifikation der benutzerdefinierten Broker-Ressource beim erneuten Bereitstellen des Brokers auf false fest.

Konfigurieren des Verhaltens des datenträgergestützten Nachrichtenpuffers

Wichtig

Dieses Feature kann derzeit nicht mithilfe der Azure CLI oder des Azure-Portals während der Erstbereitstellung konfiguriert werden. Um diese Einstellung zu ändern, müssen Sie die YAML-Datei ändern und den Broker erneut bereitstellen.

Das Feature diskBackedMessageBufferSettings 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 diskBackedMessageBufferSettings 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.

Das Verstehen und Konfigurieren des diskBackedMessageBufferSettings-Features sorgt für ein robustes und zuverlässiges Nachrichtenwarteschlangensystem. Die richtige Konfiguration ist in Szenarien wichtig, in denen die Nachrichtenverarbeitungsgeschwindigkeit und Konnektivität kritische Faktoren sind.

Konfigurationsoptionen

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

  • Konfigurieren des Volumes: Geben Sie eine Anspruchsvorlage für beständige Volumes an, um ein dediziertes Speichervolume 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 Volumes und dann emptyDir-Volumes bevorzugt. Sowohl persistente Volumes als auch kurzlebige Volumes werden in der Regel von den gleichen Speicherklassen bereitgestellt. Wenn Sie über beide Optionen verfügen, wählen Sie kurzlebige Volumes aus. Für kurzlebige Volumes ist allerdings Kubernetes 1.23 oder höher erforderlich.

Deaktiviert

Wenn Sie den datenträgergestützten Nachrichtenpuffer nicht verwenden möchten, schließen Sie die diskBackedMessageBufferSettings-Eigenschaft nicht in die Broker-CRD ein.

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 ephemeralVolumeClaimSpec-Eigenschaft wird als ephemeral.volumeClaimTemplate.spec-Eigenschaft des Volumes 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-CRD 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 persistentVolumeClaimSpec-Eigenschaft wird als volumeClaimTemplate.spec-Eigenschaft des Volumes in den 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-CRD an:

diskBackedMessageBuffer:
  maxSize: "1G"
  persistentVolumeClaimSpec:
    storageClassName: "foo"
    accessModes:
    - "ReadWriteOnce"

emptyDir-Volume

Verwenden Sie ein emptyDir-Volume. Ein emptyDir-Volume ist die nächste 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-CRD 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.

Persistenz

Es ist wichtig zu verstehen, dass das Feature diskBackedMessageBufferSettings 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.