Azure IoT Einsatz integrierten lokalen MQTT-Broker

Azure IoT Einsatz umfasst einen MQTT-Broker, der unternehmensweit und standardkonform ist. Der MQTT-Broker ist skalierbar, hochverwendbar und Kubernetes native. Es stellt die Messagingebene für Azure IoT Einsatz bereit, ermöglicht die bidirektionale Edge-zu-Cloud-Kommunikation und unterstützt eventgesteuerte Anwendungen am Rand.

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 Azure IoT Einsatz 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 der Broker, der globale 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:

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:

In einer vollständigen Bereitstellung können Sie über mehrere BrokerListener verfügen, die jeweils über mehrere Ports verfügen, und jeder Port kann über unterschiedliche BrokerAuthentication- und BrokerAuthorization-Ressourcen verfügen.

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:

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.

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 verbessert die Hochverfü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 des Azure CLI oder des Azure Portals anpassen. Eine neue Bereitstellung ist erforderlich, wenn Sie unterschiedliche Brokerkonfigurationseinstellungen benötigen.

Um den Standardbroker während der Bereitstellung anzupassen, befolgen Sie die Anweisungen für Ihre Bereitstellungsmethode:

Anzeigen der Standardbrokereinstellungen

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

az iot ops broker show --name default --instance <INSTANCE_NAME> --resource-group <RESOURCE_GROUP>

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

Verwandte Inhalte

• IoT-Operationen auf einem Azure Arc-fähigen Kubernetes-Cluster bereitstellen