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 MQTT-Broker, der für Unternehmen geeignet und standardkonform ist. Der MQTT-Broker ist skalierbar, hochverfügbar und Kubernetes-nativ. Er stellt die Messagingebene für IoT Einsatz bereit, ermöglicht bidirektionale Edge-/Cloudkommunikation und unterstützt ereignisgesteuerte Anwendungen am Edge.

MQTT-Compliance

MQTT wird als gemeinsame Sprache zwischen Protokollen im IoT-Bereich verwendet. Das einfache Design von MQTT ermöglicht es einem einzigen Broker, mehrere zehntausend Clients gleichzeitig zu bedienen, mit einer einfachen Erstellung und Verwaltung von Themen zum Veröffentlichen und Abonnieren. Viele IoT-Geräte unterstützen vorkonfigurierte MQTT-Protokolle nativ. Nachgeschaltete Übersetzungsgateways rationalisieren die zahlreichen IoT-Protokolle in MQTT.

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:

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

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-IDs für Clientsitzungen und Themennamen 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
  • Flexible 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.
  • 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.

Zwischen Broker und BrokerListener besteht eine 1:n-Beziehung. Zwischen BrokerListener und BrokerAuthentication/BrokerAuthorization besteht eine m:n-Beziehung. 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 unbeabsichtigte Unterbrechungen in der Kommunikation zwischen internen IoT Einsatz-Komponenten zu verhindern, empfehlen wir, keine Standardkonfiguration zu ändern.

Um die MQTT-Brokerbereitstellung anzupassen, fügen Sie dem Standardbroker neue Ressourcen wie BrokerListener-, BrokerAuthentication- und BrokerAuthorization-Ressourcen 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:

  • 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 dann alle neuen Ports konfigurieren und dabei die gleichen BrokerAuthentication- und BrokerAuthorization-Ressourcen verwenden, sieht das Setup wie folgt aus:

Diagramm: Vollständig benutzerdefinierte 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 IoT Einsatz-Bereitstellung kann nur über einen Broker verfügen und muss den Namen default haben. Die Standardbrokerressource ist erforderlich, damit Azure IoT Einsatz 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 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.

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.