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 Einsatz verfügt über einen standardkonformen MQTT-Broker der Enterprise-Klasse, der skalierbar, hochverfügbar und Kubernetes-nativ ist. Es stellt die Messagingebene für Azure IoT Einsatz bereit, ermöglicht bidirektionale Edge-/Cloudkommunikation und unterstützt ereignisgesteuerte Anwendungen am Edge.

MQTT-Compliance

Message Queue Telemetry Transport (MQTT) hat sich als Verkehrssprache zwischen Protokollen im IoT-Raum etabliert. Das einfache Design von MQTT ermöglicht es einem einzigen Broker, mehrere zehntausend Kund*innen gleichzeitig zu bedienen, mit einer einfachen Erstellung und Verwaltung von Veröffentlichen/Abonnieren-Themen. Viele IoT-Geräte unterstützen MQTT standardmäßig, wobei die meisten IoT-Protokolle durch nachgeschaltete Übersetzungsgateways in MQTT umgewandelt werden.

Der MQTT-Broker befindet sich unterhalb der Messagingschicht in IoT Einsatz und unterstützt sowohl MQTT v3.1.1 als auch 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:

  • Zustandslose Front-End-Ebene.
  • Zustandsbehaftete und shardierte Back-End-Ebene.

Die Frontend-Ebene verarbeitet Clientverbindungen und Anforderungen und leitet sie an das Back-End weiter. Die Back-End-Ebene partitioniert Daten nach verschiedenen Schlüsseln, z. B. Client-ID für Clientsitzungen, und Themenname für Themennachrichten. Sie verwendet die Kettenreplikation, um Daten innerhalb jeder Partition zu replizieren.

Die Ziele der Architektur sind:

  • Fehlertoleranz und Isolation: Die Veröffentlichung von Nachrichten wird fortgesetzt, wenn Back-End-Pods ausfallen und verhindert, dass Fehler an den Rest des Systems weitergegeben werden
  • Wiederherstellung nach Fehlern: Automatische Wiederherstellung nach Fehlern ohne Operatoreingriff
  • Kein Nachrichtenverlust: Übermittlung von Nachrichten, wenn mindestens ein Front-End-Pod und ein Back-End-Pod in einer Partition ausgeführt werden
  • Elastische Skalierung: Horizontale Skalierung der Veröffentlichung und Abonnieren des Durchsatzes zur Unterstützung von Edge- und Cloudbereitstellungen
  • Konsistente Leistung im großen Stil: Beschränkung des Latenzaufwands für Nachrichten aufgrund der Kettenreplikation
  • Betriebliche Einfachheit: Minimale Abhängigkeit von externen Komponenten zur Vereinfachung der Wartung und Komplexität

Konfiguration

Für die Konfiguration besteht der MQTT-Broker aus mehreren benutzerdefinierten Kubernetes-Ressourcen, die verschiedene Aspekte des Verhaltens und der Funktionalität des Brokers definieren.

  • Die Hauptressource ist Broker, der die globalen Einstellungen wie Kardinalität, Speichernutzungsprofil und Diagnoseeinstellungen definiert.
  • Ein Broker kann bis zu drei BrokerListeners 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 einem BrokerListener kann einer BrokerAuthentication-Ressource und einer BrokerAuthorization-Ressource zugeordnet werden. Dies sind die Authentifizierungs- und Autorisierungsrichtlinien, die bestimmen, welche Clients eine Verbindung mit dem Port herstellen können und welche Aktionen sie für den Broker ausführen können.

Die Beziehung zwischen Broker und BrokerListener ist also 1:n und die Beziehung zwischen BrokerListener und BrokerAuthentication/BrokerAuthorization ist n:n. Das Entitätsbeziehungsdiagramm (ERD) für diese Ressourcen lautet wie folgt:

Diagramm mit dem Brokerressourcenmodell.

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

Diagramm, das die Standardbrokerressourcen und -Beziehungen zwischen ihnen zeigt.

Wichtig

Um unbeabsichtigte Unterbrechungen in der Kommunikation zwischen internen Azure IoT Operations-Komponenten zu verhindern, empfehlen wir, keine Standardkonfiguration zu ändern.

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

Die Brokerressource selbst ist unveränderlich und kann nach der Bereitstellung nicht geändert werden, benötigt 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:

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

Wenn Sie dann alle neuen Ports konfigurieren und die gleichen BrokerAuthentication- und BrokerAuthorization-Ressourcen verwenden, würde das Setup wie folgt aussehen:

Diagramm mit einer vollständigen benutzerdefinierten Brokerbereitstellung und Beziehungen zwischen den einzelnen Komponenten.

Auf diese Weise behalten Sie das Standardsetup intakt und fügen neue Ressourcen hinzu, um die MQTT-Brokerbereitstellung an Ihre Anforderungen anzupassen.

Standardbrokerressource

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

Achtung

Löschen Sie nicht die Standardbrokerressource. Dadurch wird die Kommunikation zwischen internen Azure IoT Operations-Komponenten unterbrochen, und die Bereitstellung funktioniert nicht mehr.

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.

Das Anpassen des Standardbrokers muss während der ersten Bereitstellungszeit mithilfe der Azure CLI oder des Azure-Portals erfolgen. Eine neue Bereitstellung ist erforderlich, wenn unterschiedliche Brokerkonfigurationseinstellungen erforderlich sind.

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

Im folgenden Leitfaden zum Bereitstellen von Azure IoT Operations schauen Sie im Abschnitt Konfiguration unter MQTT-Brokerkonfiguration. 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.

Anzeigen der Standardbrokereinstellungen

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

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

Nächste Schritte

Bereitstellen von Azure IoT-Vorgängen in einem arcfähigen Kubernetes-Cluster