Freigeben über

Integrierter lokaler MQTT-Broker für Azure IoT Operations

Wichtig

Diese Seite enthält Anweisungen zum Verwalten der Komponenten von Azure IoT Einsatz mithilfe von Kubernetes-Bereitstellungsmanifesten. Diese Option befindet sich in der Vorschau. Dieses Feature wird mit einigen Einschränkungen bereitgestellt und sollte nicht für Produktionsworkloads verwendet werden.

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.

Azure IoT Operations umfasst einen MQTT-Broker, der in Unternehmensqualität und standardskonform ist. Der MQTT-Broker ist skalierbar, hochverwendbar und Kubernetes native. Sie stellt die Messagingebene für IoT-Vorgänge bereit, ermöglicht die bidirektionale Edge-zu-Cloud-Kommunikation und unterstützt ereignisgesteuerte Anwendungen am Edge.

MQTT-Compliance

MQTT ist ein gemeinsames Protokoll im IoT-Raum. Sein einfaches Design ermöglicht es einem einzelnen Broker, Tausende von Clients gleichzeitig mit der Erstellung und Verwaltung von Themen zu veröffentlichen und zu verwalten. Viele IoT-Geräte unterstützen MQTT nativ. Nachgeschaltete Übersetzungsgateways konvertieren verschiedene IoT-Protokolle in MQTT.

Der MQTT-Broker unterstützt die Messaging-Ebene in IoT Operations und ist kompatibel mit MQTT v3.1.1 und MQTT v5. Weitere Informationen zu unterstützten MQTT-Features finden Sie unter MQTT-Featureunterstützung im MQTT-Broker.

Aufbau

Der MQTT-Broker hat zwei Hauptebenen:

  • Statusfreie Front-End-Ebene
  • Zustandsbehaftete Back-End-Ebene mit Sharding

Die Front-End-Ebene verarbeitet Clientverbindungen und Anforderungen und leitet sie an das Back-End weiter. Die Back-End-Ebene partitioniert Daten nach Schlüsseln, z. B. eine Client-ID für Clientsitzungen und einen Themennamen für Themennachrichten. Die Back-End-Ebene verwendet die Kettenreplikation, um Daten innerhalb jeder Partition zu kopieren.

Die Ziele der Architektur sind:

  • Fehlertoleranz und Isolierung: Die Veröffentlichung von Nachrichten wird fortgesetzt, wenn Back-End-Pods fehlschlagen, und Fehler werden nicht an den Rest des Systems weitergegeben.
  • Wiederherstellung nach Fehlern: Automatische Wiederherstellung nach Fehlern ohne Operatoreingriff
  • Kein Nachrichtenverlust: Nachrichten werden übermittelt, wenn mindestens ein Frontend-Pod und ein Back-End-Pod in einer Partition ausgeführt werden.
  • Flexible Skalierung: Die horizontale Skalierung des Veröffentlichungs- und Abonnementdurchsatzes unterstützt Edge- und Cloudbereitstellungen.
  • Konsistente Leistung in großem Maßstab: Verringert die Latenzzeitüberlastung bei Nachrichten aufgrund der Kettenreplikation.
  • Betriebliche Einfachheit: Reduziert die Abhängigkeit von externen Komponenten, um Die Wartung und Komplexität zu vereinfachen.

Konfiguration

Für die Konfiguration verwendet der MQTT-Broker mehrere benutzerdefinierte Kubernetes-Ressourcen, um verschiedene Aspekte des Verhaltens und der Funktionalität des Brokers zu definieren:

  • Die Hauptressource ist Broker, der die globalen Einstellungen wie Kardinalität, Speichernutzungsprofil und Diagnoseeinstellungen definiert.
  • Eine Brokerressource kann bis zu drei BrokerListeners-Ressourcen haben, von denen jeder auf eingehende MQTT-Verbindungen auf dem angegebenen Diensttyp (NodePort, LoadBalancer oder ClusterIP) lauscht. Jede BrokerListener-Ressource kann über mehrere Ports verfügen.
  • Jeder Port in einer BrokerListener-Ressource kann einer BrokerAuthentication-Ressource und einer BrokerAuthorization-Ressource zugeordnet werden. Diese Authentifizierungs- und Autorisierungsrichtlinien bestimmen, welche Clients eine Verbindung mit dem Port herstellen und welche Aktionen sie für den Broker ausführen können.

Die Beziehung zwischen Broker und BrokerListener ist eins-zu-viele, während die Beziehung zwischen BrokerListener und BrokerAuthentication/BrokerAuthorization viele-zu-viele ist. Das Entitätsbeziehungsdiagramm für diese Ressourcen lautet wie folgt:

Diagramm: Brokerressourcenmodell

Standardmäßig stellt IoT Einsatz einen Standardbroker, eine standardmäßige BrokerListener-Ressource und eine standardmäßige BrokerAuthentication-Ressource bereit. Alle diese Ressourcen werden als Standard bezeichnet. Zusammen stellen diese Ressourcen ein grundlegendes MQTT-Brokersetup bereit, das für die Funktion von IoT Einsatz erforderlich ist. Das Standardsetup lautet wie folgt:

Diagramm: Standardbrokerressourcen und -beziehungen

Wichtig

Um eine Unterbrechung der Kommunikation zwischen internen IoT Operations-Komponenten zu vermeiden, ändern Sie keine Standardkonfiguration.

Um die MQTT-Brokerbereitstellung anzupassen, fügen Sie dem Standardbroker neue Ressourcen wie BrokerListeners, BrokerAuthentication und BrokerAuthorization hinzu.

Die Brokerressource ist unveränderlich und kann nach der Bereitstellung nicht geändert werden, erfordert jedoch nur Anpassungen in erweiterten Szenarien. Weitere Informationen zum Anpassen der Brokerressource finden Sie unter Anpassen des standardmäßigen Brokers.

In einer vollständigen Bereitstellung könnten Sie mehrere BrokerListeners mit mehreren Ports haben, und jeder Port könnte unterschiedliche BrokerAuthentication- und BrokerAuthorization-Ressourcen zugeordnet haben.

Beispielsweise fügen Sie nach dem Standardsetup Folgendes hinzu:

  • Eine LoadBalancer BrokerListener-Ressource mit dem Namen example-lb-listener und den beiden Ports 1883 und 8883
  • Eine NodePort BrokerListener-Ressource mit dem Namen example-nodeport-listener und dem Port 1884 (nodePort 31884)
  • Eine BrokerAuthentication-Ressource mit dem Namen example-authn und einer benutzerdefinierten Authentifizierungsmethode
  • Eine BrokerAuthorization-Ressource mit dem Namen example-authz und Ihren benutzerdefinierten Autorisierungseinstellungen

Wenn Sie alle neuen Ports mit denselben BrokerAuthentication- und BrokerAuthorization-Ressourcen konfigurieren, sieht das Setup wie folgt aus:

Diagramm: Vollständig benutzerdefinierte Brokerbereitstellung und Beziehungen zwischen den einzelnen Komponenten

Dieser Ansatz behält das Standardsetup intakt und ermöglicht es Ihnen, neue Ressourcen hinzuzufügen, um die MQTT-Brokerbereitstellung anzupassen.

Standardbrokerressource

Jede IoT Operations-Bereitstellung kann nur über einen Broker verfügen und muss den Namen "Standard" haben. Die Standardbrokerressource ist erforderlich, damit IoT-Vorgänge funktionieren. Sie ist unveränderlich und kann nach der Bereitstellung nicht mehr geändert werden.

Achtung

Löschen Sie die Standardbrokerressource nicht. Dadurch wird die Kommunikation zwischen internen IoT Einsatz-Komponenten unterbrochen, und die Bereitstellung wird nicht mehr ausgeführt.

Anpassen des Standardbrokers

Das Anpassen der Standardbrokerressource ist für die meisten Setups nicht erforderlich. Zu den Einstellungen, die Anpassungen erfordern, gehören:

  • Kardinalität: Bestimmt die Kapazität des Brokers, mehr Verbindungen und Nachrichten zu verarbeiten, und es verbessert die hohe Verfügbarkeit, wenn Pod- oder Knotenfehler auftreten.
  • Speicherprofil: Legt die maximale Speicherauslastung des Brokers und die Behandlung der Speicherauslastung fest, während der Broker skaliert wird.
  • Nachrichtenpuffer der Datenträgersicherung: Konfiguration für das Puffern von Nachrichten auf dem Datenträger, wenn RAM sich auffüllt.
  • Diagnoseeinstellungen: Konfiguration für Diagnoseeinstellungen wie Protokollebene und Metrikenendpunkt.
  • Erweiterte MQTT-Clientoptionen: Konfiguration für erweiterte MQTT-Clientoptionen wie Sitzungsablauf, Nachrichtenablauf und Keep-Alive-Einstellungen.
  • Verschlüsselung des internen Datenverkehrs: Konfiguration zum Verschlüsseln des internen Datenverkehrs zwischen Broker-Front-End- und Back-End-Pods.

Sie können den Standardbroker nur während der erstbereitstellung mithilfe der Azure CLI oder des Azure-Portals anpassen. Eine neue Bereitstellung ist erforderlich, wenn Sie unterschiedliche Brokerkonfigurationseinstellungen benötigen.

So passen Sie den Standardbroker während der Bereitstellung an:

Wenn Sie den folgenden Leitfaden zum Bereitstellen von IoT Einsatz befolgen, sehen Sie im Abschnitt Konfiguration unter MQTT-Brokerkonfiguration nach. Hier können Sie Kardinalitäts- und Speicherprofileinstellungen anpassen. Verwenden Sie die Azure CLI, um andere Einstellungen zu konfigurieren, einschließlich datenträgergestützter Nachrichtenpuffer und erweiterter MQTT-Clientoptionen.

Wichtig

Sie können die Brokerressource nach der erstmaligen Bereitstellung nicht aktualisieren. Konfigurationsänderungen an Kardinalität, Arbeitsspeicherprofil oder Datenträgerpuffer sind nach der Bereitstellung nicht zulässig.

Als Problemumgehung können Sie beim Bereitstellen von Azure IoT Einsatz mit dem Befehl az iot ops init den Parameter --broker-config-file mit einer JSON-Konfigurationsdatei für den MQTT-Broker einschließen. Weitere Informationen finden Sie unter Erweiterte MQTT-Brokerkonfiguration und Konfigurieren der Grundeinstellungen für den MQTT-Broker.

Anzeigen der Standardbrokereinstellungen

So zeigen Sie die Einstellungen für den Standardbroker an:

  1. Navigieren Sie im Azure-Portal zu Ihrer IoT Einsatz-Instanz.
  2. Wählen Sie unter "Komponenten" den MQTT-Brokeraus.
  3. Wählen Sie unter BrokerdetailsJSON-Ansicht aus.

Zugehöriger Inhalt