Verbinden des Cloudconnectors der MQTT-Brücke von Azure IoT MQ (Vorschau) mit anderen MQTT Vermittlern.

Artikel
04/22/2024

Wichtig

Die von Azure Arc aktivierte Azure IoT Operations Preview befindet sich derzeit in der VORSCHAU. Sie sollten diese Vorschausoftware nicht in Produktionsumgebungen verwenden.

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.

Sie können die MQTT-Brücke von Azure IoT MQ (Vorschau) verwenden, um eine Verbindung mit Azure Event Grid oder anderen MQTT Vermittlern herzustellen. Das MQTT-Bridging ist der Prozess des Verbindens zweier MQTT Vermittler, damit sie Nachrichten austauschen können.

Wenn zwei Broker überbrückt werden, werden Nachrichten, die auf einem Broker veröffentlicht werden, automatisch an den anderen weitergeleitet und umgekehrt.
Das MQTT-Bridging hilft dabei, ein Netzwerk von MQTT Vermittlern zu schaffen, die miteinander kommunizieren, und die MQTT-Infrastruktur zu erweitern, indem zusätzliche Broker nach Bedarf hinzugefügt werden.
Das MQTT-Bridging ist nützlich für mehrere physische Standorte, das Teilen von MQTT-Nachrichten und Themen zwischen Edge und Cloud oder wenn Sie MQTT in andere Messaging-Systeme integrieren möchten.

Um eine Brücke zu einem anderen Broker zu erstellen, muss Azure IoT-MQ die Endpunkt-URL des Remote-Brokers, die MQTT-Version, die Authentifizierungsmethode und die zuzuordnenden Themen kennen. Um die Zusammensetzbarkeit und Flexibilität in Kubernetes-nativer Art zu maximieren, werden diese Werte als benutzerdefinierte Kubernetes-Ressourcen (CRDs) mit dem Namen MqttBridgeConnector und MqttBridgeTopicMapkonfiguriert. Dieser Leitfaden führt Sie durch die Erstellung des MQTT-Brückenconnectors mithilfe dieser Ressourcen.

Erstellen Sie eine YAML-Datei, welche die MqttBridgeConnector-Ressource definiert. Sie können das Beispiel-YAML verwenden, aber stellen Sie sicher, dass sie die namespace ändern, um mit derjenigen übereinzustimmen, die Azure IoT-MQ bereitgestellt hat, und die remoteBrokerConnection.endpoint, um mit der Endpunkt-URL Ihres Remote-Brokers übereinzustimmen.
Erstellen Sie eine YAML-Datei, welche die MqttBridgeTopicMap-Ressource definiert. Sie können das Beispiel-YAML verwenden, aber stellen Sie sicher, dass sie die namespace ändern, um mit derjenigen übereinzustimmen, die Azure IoT-MQ bereitgestellt hat, und die mqttBridgeConnectorRef, um mit dem Namen der MqttBridgeConnector-Ressource übereinzustimmen, die Sie im früheren Schritt erstellt haben.

Stellen Sie den MQTT-Brückenconnector und die Themenkarte mit kubectl apply -f <filename> bereit.

$ kubectl apply -f my-mqtt-bridge.yaml 
mqttbridgeconnectors.mq.iotoperations.azure.com my-mqtt-bridge created
$ kubectl apply -f my-topic-map.yaml
mqttbridgetopicmaps.mq.iotoperations.azure.com my-topic-map created

Verwenden Sie nach der Bereitstellung kubectl get pods, um zu überprüfen, dass Nachrichten beginnen, zu und von Ihrem Endpunkt zu fließen.

Konfigurieren des MqttBridgeConnector

Die MqttBridgeConnector-Ressource definiert den MQTT-Brückenconnector, der mit einem Remote-Broker kommunizieren kann. Sie enthält die folgenden Komponenten:

Eine oder mehrere Instanzen des MQTT-Brückenconnectors. Jede Instanz ist ein Container, der den MQTT-Brückenconnector ausführt.
Eine Remote-Brokerverbindung.
Eine optionale lokale Brokerverbindung.

Das folgende Beispiel zeigt eine Beispielkonfiguration für das Bridging zu einem MQTT-Broker von Azure Event Grid. Es verwendet eine systemseitig zugewiesene verwaltete Identität für die Authentifizierung und TLS-Verschlüsselung.

apiVersion: mq.iotoperations.azure.com/v1beta1
kind: MqttBridgeConnector
metadata:
  name: my-mqtt-bridge
  namespace: azure-iot-operations
spec:
  image: 
    repository: mcr.microsoft.com/azureiotoperations/mqttbridge 
    tag: 0.4.0-preview
    pullPolicy: IfNotPresent
  protocol: v5
  bridgeInstances: 1
  clientIdPrefix: factory-gateway-
  logLevel: debug
  remoteBrokerConnection:
    endpoint: example.westeurope-1.ts.eventgrid.azure.net:8883
    tls:
      tlsEnabled: true
    authentication:
      systemAssignedManagedIdentity:
        audience: https://eventgrid.azure.net
  localBrokerConnection:
    endpoint: aio-mq-dmqtt-frontend:8883
    tls:
      tlsEnabled: true
      trustedCaCertificateConfigMap: aio-ca-trust-bundle-test-only
    authentication:
      kubernetes: {}

Die folgenden Tabelle beschreibt die Felder in der MqttBridgeConnector-Ressource:

Feld	Erforderlich	Beschreibung
image	Ja	Das Bild des Kafka-Connectors. Sie können `pullPolicy`, `repository` und `tag` für das Bild angeben. Die richtigen Werte werden im vorherigen Beispiel angezeigt.
Protokoll	Ja	MQTT-Protokollversion. Kann `v5` oder `v3` sein. Siehe MQTT v3.1.1-Support.
bridgeInstances	Nein	Anzahl der Instanzen für den Brückenconnector. Der Standardwert ist 1. Siehe Anzahl von Instanzen.
clientIdPrefix	Nein	Das Präfix für die dynamisch generierte Client-ID. Der Standard ist kein Präfix. Siehe Client-ID-Konfiguration.
logLevel	Nein	Protokollebene. Kann `debug` oder `info` sein. Der Standardwert ist `info`.
remoteBrokerConnection	Ja	Verbindungsdetails des Remote-Brokers, zu dem eine Brücke hergestellt werden soll. Siehe Remote-Brokerverbindung.
localBrokerConnection	Nein	Verbindungsdetails des lokalen Brokers, zu dem eine Brücke hergestellt werden soll. Standardmäßig wird der angezeigte Wert verwendet. Siehe lokale Brokerverbindung.

MQTT v3.1.1-Support

Der Brückenconnector kann für die Verwendung von MQTT v3.1.1 sowohl mit der lokalen Brokerverbindung für Azure IoT-MQ als auch für die Remote-Brokerverbindung konfiguriert werden. Dadurch werden jedoch gemeinsame Abonnements unterbrochen, wenn der Remote-Broker es nicht unterstützt. Wenn Sie beabsichtigen, gemeinsame Abonnements zu verwenden, belassen Sie es als Standardwert v5.

Anzahl von Instanzen

Konfigurieren Sie für Hochverfügbarkeit und Skalierung den MQTT-Brückenconnector für die Verwendung mehrerer Instanzen. Nachrichtenflow und Routen werden automatisch zwischen verschiedenen Instanzen ausgeglichen.

spec:
  bridgeInstances: 2

Client-ID-Konfiguration

Azure IoT-MQ generiert eine Client-ID für jeden MqttBridgeConnector-Client unter Verwendung eines von Ihnen angegebenen Präfixes im Format von {clientIdPrefix}-{routeName}. Diese Client-ID ist wichtig für Azure IoT-MQ, um Nachrichtenverluste zu minimieren und Konflikte oder Kollisionen mit vorhandenen Client-IDs zu vermeiden, da die MQTT-Spezifikation nur eine Verbindung pro Client-ID zulässt.

Wenn es beispielsweise für clientIdPrefix: "client-" zwei routes in der Themenzuordnung gibt, sind die Client-IDs wir folgt: client-route1 und client-route2.

Remote-Brokerverbindung

Das remoteBrokerConnection-Feld definiert die Verbindungsdetails, um eine Brücke zum Remote-Broker herzustellen. Diese Felder sind enthalten:

Feld	Erforderlich	BESCHREIBUNG
endpoint	Ja	Endpunkt-URL des Remote-brokers mit Port. Beispiel: `example.westeurope-1.ts.eventgrid.azure.net:8883`.
tls	Ja	Gibt an, ob die Verbindung mit TLS und vertrauenswürdigem ZS-Zertifikat verschlüsselt ist. Siehe TLS-Support
authentication	Ja	Authentifizierungsdetails für Azure IoT-MQ für die Verwendung mit dem Broker. Muss einer der folgenden Werte sein: systemseitig zugewiesene verwaltete Identität oder X.509. Siehe Authentifizierung.
Protokoll	Nein	Zeichenfolgenwert, der die Verwendung von MQTT oder MQTT über WebSockets definiert. Kann `mqtt` oder `webSocket` sein. Der Standardwert ist `mqtt`.

Authentifizierung

Das Authentifizierungsfeld definiert die Authentifizierungsmethode für Azure IoT-MQ, die mit dem Remote-Broker verwendet werden soll. Diese Felder sind enthalten:

Feld	Erforderlich	Beschreibung
systemAssignedManagedIdentity	Nein	Authentifizieren mit der systemseitig zugewiesenen verwalteten Identität. Siehe Verwaltete Identität.
x509	Nein	Authentifizierungsdetails mittels X.509-Zertifikaten. Siehe X.509.

Verwaltete Identität

Das Feld systemAssignedManagedIdentity enthält die folgenden Felder:

Feld	Erforderlich	Beschreibung
Zielgruppe	Ja	Die Zielgruppe für das Token. Erforderlich bei der Verwendung der verwalteten Identität. Für Event Grid ist dies `https://eventgrid.azure.net`.

Wenn Azure IoT-MQ als Azure Arc-Erweiterung bereitgestellt wird, erhält es standardmäßig eine systemseitig zugewiesene verwaltete Identität. Sie sollten eine verwaltete Identität für Azure IoT-MQ verwenden, um mit Azure-Ressourcen zu interagieren, einschließlich des Event Grid-MQTT Vermittlers, da Sie die Verwaltung von Anmeldeinformationen vermeiden und Hochverfügbarkeit beibehalten können.

Um eine verwaltete Identität für die Authentifizierung mit Azure-Ressourcen zu verwenden, weisen Sie zunächst eine entsprechende Azure RBAC-Rolle wie EventGrid TopicSpaces Publisher zur verwalteter Identität von Azure IoT-MQ zu, die von Arc bereitgestellt wird.

Geben Sie dann MQTTBridgeConnector mit der verwalteten Identität als Authentifizierungsmethode an:

spec:
  remoteBrokerConnection:
    authentication:
      systemAssignedManagedIdentity:
        audience: https://eventgrid.azure.net

Wenn Sie die verwaltete Identität verwenden, ist die Client-ID nicht konfigurierbar und entspricht der Azure Resource Manager-Ressourcen-ID für die Azure IoT-MQ Azure Arc-Erweiterung in Azure.

Die systemseitig zugewiesene verwaltete Identität wird von Azure Arc bereitgestellt. Das der verwalteten Identität zugeordnete Zertifikat muss mindestens alle 90 Tage verlängert werden, um einen manuellen Wiederherstellungsvorgang zu vermeiden. Weitere Informationen finden Sie unter Wie gehe ich mit abgelaufenen Azure Arc-fähigen Kubernetes-Ressourcen um?

X.509

Das x509-Feld enthält die folgenden Felder:

Feld	Erforderlich	Beschreibung
secretName	Ja	Das Kubernetes-Geheimnis, welches das Clientzertifikat und den privaten Schlüssel enthält. Sie können Azure Key Vault verwenden, um Geheimnisse für Azure IoT-MQ anstelle von Kubernetes-Geheimnissen zu verwalten. Weitere Informationen finden Sie unter Verwalten von Geheimnissen mithilfe von Azure Key Vault oder Kubernetes-Geheimnissen.

Viele MQTT Vermittler, z. B. Event Grid unterstützen die X.509-Authentifizierung. Die MQTT-Brücke von Azure IoT-MQ kann ein X.509-Clientzertifikat präsentieren und die TLS-Kommunikation aushandeln. Verwenden Sie ein Kubernetes-Geheimnis, um das X.509-Clientzertifikat, den privaten Schlüssel und die Zwischenzertifizierungsstelle zu speichern.

kubectl create secret generic bridge-client-secret \
--from-file=client_cert.pem=mqttbridge.pem \
--from-file=client_key.pem=mqttbridge.key \
--from-file=client_intermediate_certs.pem=intermediate.pem

Und verweisen Sie mit secretName darauf:

spec:
  remoteBrokerConnection:
    authentication:
      x509:
        secretName: bridge-client-cert

Lokale Brokerverbindung

Das localBrokerConnection-Feld definiert die Verbindungsdetails, um eine Brücke zum lokalen Broker zu erstellen.

Feld	Erforderlich	BESCHREIBUNG
endpoint	Ja	Endpunkt-URL des Remote-brokers mit Port.
tls	Ja	Gibt an, ob die Verbindung mit TLS und vertrauenswürdigem ZS-Zertifikat verschlüsselt ist. Siehe TLS-Support
authentication	Ja	Authentifizierungsdetails für Azure IoT-MQ für die Verwendung mit dem Broker. Die einzige unterstützte Methode ist das Kubernetes-Dienstkontotoken (Service Account Token, SAT). Geben Sie zum Verwenden von SAT `kubernetes: {}` an.

Standardmäßig wird IoT-MQ im Namespace azure-iot-operations mit aktivierter TLS und SAT-Authentifizierung bereitgestellt.

Anschließend muss die lokale Brokerverbindungseinstellung MqttBridgeConnector so konfiguriert werden, dass sie übereinstimmt. Die Bereitstellungs-YAML für MqttBridgeConnector muss localBrokerConnection auf der gleichen Ebene wie remoteBrokerConnection haben. Um beispielsweise TLS mit SAT-Authentifizierung zu verwenden, um der standardmäßigen IoT-MQ-Bereitstellung zu entsprechen:

spec:
  localBrokerConnection:
    endpoint: aio-mq-dmqtt-frontend:8883
    tls:
      tlsEnabled: true
      trustedCaCertificateConfigMap: aio-ca-trust-bundle-test-only
    authentication:
      kubernetes: {}

Hier ist trustedCaCertifcateName die ConfigMap für die Stammzertifizierungsstelle von Azure IoT-MQ, wie die ConfigMap für die Stammzertifizierungsstelle des Remote-Brokers. Die Standardstammzertifizierungsstelle wird in einer ConfigMap mit dem Namen aio-ca-trust-bundle-test-onlygespeichert.

Weitere Informationen zum Abrufen der Stammzertifizierungsstelle finden Sie unter Konfigurieren von TLS mit automatischer Zertifikatverwaltung, um die MQTT-Kommunikation zu sichern.

TLS-Unterstützung

Das tls-Feld definiert die TLS-Konfiguration für die Remote- oder lokale Brokerverbindung. Diese Felder sind enthalten:

Feld	Erforderlich	Beschreibung
tlsEnabled	Ja	Gibt an, ob TLS aktiviert ist oder nicht.
trustedCaCertificateConfigMap	Nein	Das Zertifizierungsstellenzertifikat, dem beim Herstellen einer Verbindung mit dem Broker vertraut werden soll. Erforderlich, wenn TLS aktiviert ist.

Der TLS-Verschlüsselungssupport ist sowohl für Remote- als auch für lokale Brokerverbindungen verfügbar.

Für die Remote-Brokerverbindung: Wenn TLS aktiviert ist, sollte ein vertrauenswürdiges Zertifizierungsstellenzertifikat als Kubernetes ConfigMap-Referenz angegeben werden. Wenn nicht, schlägt der TLS-Handshake wahrscheinlich fehl, es sei denn, der Remote-Endpunkt ist weitgehend vertrauenswürdig. Ein vertrauenswürdiges Zertifizierungsstellenzertifikat befindet sich bereits im Zertifikatspeicher des Betriebssystems. Beispielsweise verwendet Event Grid einen weitgehend vertrauenswürdigen Zertifizierungsstellenstamm, sodass die Angabe nicht erforderlich ist.
Für die lokale (Azure IoT-MQ)-Brokerverbindung: Wenn TLS für den Brokerlistener vom Azure IoT-MQ aktiviert ist, sollte das Zertifizierungsstellenzertifikat, welches das Listenerserverzertifikat ausgestellt hat, als Kubernetes ConfigMap-Referenz angegeben werden.

Wenn Sie eine vertrauenswürdige Zertifizierungsstelle angeben, erstellen Sie eine ConfigMap mit dem öffentlichen Teil der Zertifizierungsstelle, und geben Sie den ConfigMap-Namen in der trustedCaCertificateConfigMap-Eigenschaft an. Beispiel:

kubectl create configmap client-ca-configmap --from-file ~/.step/certs/root_ca.crt

Konfigurieren von MqttBridgeTopicMap

Die MqttBridgeTopicMap-Ressource definiert die Themenzuordnung zwischen den lokalen und Remote-Brokern. Sie muss zusammen mit einer MqttBridgeConnector-Ressource verwendet werden. Sie enthält die folgenden Komponenten:

Der Name der MqttBridgeConnector-Ressource, mit der eine Verknüpfung hergestellt werden soll.
Eine Liste der Routen für das Bridging.
Eine optionale Konfiguration für ein gemeinsames Abonnement.

Ein MqttBridgeConnector kann mehrere MqttBridgeTopicMaps verwenden, die mit ihr verknüpft sind. Wenn eine MqttBridgeConnector-Ressource bereitgestellt wird, beginnt der Azure IoT-MQ-Operator mit dem Scannen des Namespaces nach allen MqttBridgeTopicMaps, die damit verknüpft sind und verwaltet automatisch den Nachrichtenflow zwischen den MqttBridgeConnector-Instanzen. Nach der Bereitstellung ist die MqttBridgeTopicMap mit dem MqttBridgeConnector verknüpft. Jede MqttBridgeTopicMap kann nur mit einem MqttBridgeConnector verknüpft werden.

Das folgende Beispiel zeigt eine MqttBridgeTopicMap-Konfiguration für das Herstellen einer Brücke zwischen Nachrichten aus dem Remote-Thema remote-topic zum lokalen Thema local-topic:

apiVersion: mq.iotoperations.azure.com/v1beta1
kind: MqttBridgeTopicMap
metadata:
  name: my-topic-map
  namespace: azure-iot-operations 
spec:
  mqttBridgeConnectorRef: my-mqtt-bridge
  routes:
    - direction: remote-to-local
      name: first-route
      qos: 0
      source: remote-topic
      target: local-topic
      sharedSubscription:
        groupMinimumShareNumber: 3
        groupName: group1
    - direction: local-to-remote
      name: second-route
      qos: 1
      source: local-topic
      target: remote-topic

Die folgenden Tabelle beschreibt die Felder in der MqttBridgeTopicMap-Ressource:

Felder	Erforderlich	Beschreibung
mqttBridgeConnectorRef	Ja	Name der `MqttBridgeConnector`-Ressource, mit der eine Verknüpfung hergestellt werden soll.
Routen	Ja	Eine Liste der Routen für das Bridging. Weitere Informationen finden Sie unter Routen.

Routes

Ein MqttBridgeTopicMap kann mehrere Routen haben. Das routes-Feld definiert die Liste der Routen. Diese Felder sind enthalten:

Felder	Erforderlich	Beschreibung
Richtung	Ja	Richtung des Nachrichtenflows. Er kann `remote-to-local` oder `local-to-remote` sein. Weitere Informationen finden Sie unter Richtung.
name	Ja	Der Name der Route.
qos	Nein	MQTT-Servicequalität (Quality of Service, QoS). Der Standardwert lautet 1.
Quelle	Ja	MQTT-Quellthema. Kann Platzhalter wie `#` und `+` aufweisen. Siehe Platzhalter im Quellthema.
target	Nein	MQTT-Zielthema. Darf keine Platzhalter aufweisen. Wenn nicht angegeben, wäre es gleich wie die Quelle. Siehe Referenzquellthema im Ziel.
sharedSubscription	Nein	Gemeinsame Abonnementkonfiguration. Aktiviert eine konfigurierte Anzahl von Clients für zusätzliche Skalierung. Weitere Informationen finden Sie unter Gemeinsame Abonnements.

Direction

Wenn die Richtung beispielsweise lokal zu remote ist, veröffentlicht Azure IoT-MQ alle Nachrichten im angegebenen lokalen Thema im Remote-Thema:

routes:
  - direction: local-to-remote
    name: "send-alerts"
    source: "alerts"
    target: "factory/alerts"

Wenn die Richtung umgekehrt ist, empfängt Azure IoT-MQ Nachrichten von einem Remote-Broker. Hier wird das Ziel weggelassen, und alle Nachrichten aus dem commands/factory-Thema des Remote-Brokers werden lokal im selben Thema veröffentlicht.

routes:
  - direction: remote-to-local
    name: "receive-commands"
    source: "commands/factory"

Platzhalter im Quellthema

Verwenden Sie zum Herstellen einer Brücke zwischen nicht statischen Themen Platzhalter, um zu definieren, wie die Themenmuster abgeglichen werden sollen, und die Regel der Themennamenübersetzung. Um beispielsweise eine Brücke zwischen allen Nachrichten in allen Unterthemen unter telemetry zu erstellen, verwenden Sie den Mehrebenen-Platzhalter #:

routes:
  - direction: local-to-remote
    name: "wildcard-source"
    source: "telemetry/#"
    target: "factory/telemetry"

Wenn eine Nachricht in einem beliebigenThema unter telemetry veröffentlicht wird, z. B. telemetry/furnace/temperature, veröffentlicht Azure IoT-MQ sie unter dem statischen factory/telemetry-Thema im Remote-Broker mit Brücke.

Verwenden Sie für Einzelebenen-Themenplatzhalter stattdessen +, z. B. telemetry/+/temperature.

Der MQTT-Brückenconnector muss das genaue Thema im Zielbroker kennen, entweder remote oder über Azure IoT-MQ ohne Mehrdeutigkeit. Platzhalter sind nur als Teil des source-Themas verfügbar.

Referenzquellthema im Ziel

Um auf das gesamte Quellthema zu verweisen, lassen Sie die Zielthemakonfiguration in der Route vollständig weg. Platzhalter werden unterstützt.

Beispielsweise wird für alle unter dem Thema my-topic/# veröffentlichten Nachrichten, z. B. my-topic/foo oder my-topic/bar, eine Brücke mit dem Remote-Broker unter demselben Thema erstellt:

routes:
  - direction: local-to-remote
    name: "target-same-as-source"
    source: "my-topic/#"
    # No target

Andere Methoden der Quellthemenreferenz werden nicht unterstützt.

Gemeinsame Abonnements

Das sharedSubscription-Feld definiert die Konfiguration des gemeinsamen Abonnements für die Route. Diese Felder sind enthalten:

Felder	Erforderlich	Beschreibung
groupMinimumShareNumber	Ja	Anzahl der Clients, die für ein gemeinsames Abonnement verwendet werden sollen.
groupName	Ja	Name der gemeinsamen Abonnementgruppe.

Gemeinsame Abonnements helfen Azure IoT-MQ, mehr Clients für die MQTT-Brücke zu erstellen. Sie können für jede Route ein anderes gemeinsames Abonnement einrichten. Azure IoT-MQ abonniert Nachrichten aus dem Quellthema und sendet sie mit Roundrobin jeweils an einen Client. Anschließend veröffentlicht der Client die Nachrichten an den Broker mit Brücke.

Wenn Sie beispielsweise eine Route mit gemeinsamem Abonnement einrichten und groupMinimumShareNumber als 3 festlegen:

routes:
    - direction: local-to-remote
      qos: 1
      source: "shared-sub-topic"
      target: "remote/topic"
      sharedSubscription:
        groupMinimumShareNumber: 3
        groupName: "sub-group"

Die MQTT-Brücke von Azure IoT-MQ erstellt drei Abonnentenclients unabhängig davon, wie viele Instanzen es gibt. Nur ein Client erhält jede Nachricht von $share/sub-group/shared-sub-topic. Anschließend veröffentlicht derselbe Client die Nachricht im Thema remote/topic für den Remote-Broker mit der Brücke. Die nächste Nachricht wird einem nächsten Client übergeben.

Auf diese Weise können Sie den Nachrichtendatenverkehr für die Brücke zwischen mehreren Clients mit unterschiedlichen IDs ausgleichen. Dies ist nützlich, wenn Ihr Broker mit Brücke die Anzahl der Nachrichten begrenzt, die jeder Client senden kann.

Azure Event Grid MQTT-Brokerunterstützung

Um die Verwaltung von Anmeldeinformationen zu minimieren, wird die Verwendung der systemseitig zugewiesenen verwalteten Identität und Azure RBAC empfohlen, um mit dem MQTT Vermittler-Feature in Azure Event Grid eine Brücke zu Azure IoT MQ zu erstellen.

Ein End-to-End-Tutorial finden Sie unter Tutorial: Konfigurieren der MQTT-Bridge zwischen IoT MQ und Azure Event Grid.

Herstellen einer Verbindung mit dem Event Grid MQTT Vermittler mit verwalteter Identität

Suchen Sie zunächst mithilfe von az k8s-extension show die Prinzipal-ID für die Arc-Erweiterung von Azure IoT-MQ. Notieren Sie sich den Ausgabewert für identity.principalId, der wie abcd1234-5678-90ab-cdef-1234567890ab aussehen sollte.

az k8s-extension show --resource-group <RESOURCE_GROUP> --cluster-name <CLUSTER_NAME> --name mq --cluster-type connectedClusters --query identity.principalId -o tsv

Verwenden Sie dann Azure CLI, um die Rollen der verwalteten Identität der Arc-Erweiterung von Azure IoT-MQ zuzuweisen. Ersetzen Sie <MQ_ID> durch die Prinzipal-ID, die Sie im vorherigen Schritt gefunden haben. So weisen Sie beispielsweise die Rolle EventGrid TopicSpaces Publisher zu:

az role assignment create --assignee <MQ_ID> --role 'EventGrid TopicSpaces Publisher' --scope /subscriptions/<SUBSCRIPTION_ID>/resourceGroups/<RESOURCE_GROUP>/providers/Microsoft.EventGrid/namespaces/<EVENT_GRID_NAMESPACE>

Tipp

Um das Prinzip der geringsten Rechte zu optimieren, können Sie die Rolle einem Themenbereich statt dem gesamten Event Grid-Namespace zuweisen. Weitere Informationen finden Sie unter Event Grid-RBAC und Themenräume.

Erstellen Sie schließlich einen MQTTBridgeConnector, und wählen Sie verwaltete Identität als Authentifizierungsmethode aus. Erstellen Sie die MqttBridgeTopicMaps und stellen Sie die MQTT-Brücke mit kubectl bereit.

Maximale Clientsitzungen pro Authentifizierungsname

Wenn bridgeInstances höher als 1 festgelegt ist, konfigurieren Sie den Event Grid-MQTT Vermittler Konfiguration>Maximale Anzahl von Clientsitzungen pro Authentifizierungsname, um mit der Anzahl der Instanzen übereinzustimmen. Diese Konfiguration verhindert Probleme wie Fehler 151 „Kontingent überschritten“.

Grenzwert pro Verbindung

Wenn die Verwendung der verwalteten Identität nicht möglich ist, sollten Sie beim Entwerfen Ihres Setups die Grenzwerte pro Verbindung für den Event Grid MQTT Vermittler berücksichtigen. Zum Zeitpunkt der Veröffentlichung beträgt der Grenzwert 100 Nachrichten/Sekunde in jeder Richtung für eine Verbindung. Um den Durchsatz für die MQTT-Brücke zu erhöhen, verwenden Sie gemeinsame Abonnements, um die Anzahl der Clients zu erhöhen, die jede Route bedienen.

Brücke von einem anderen Broker zu Azure IoT MQ (Vorschau)

Azure IoT-MQ ist ein kompatibler MQTT Vermittler und andere Broker können mit den entsprechenden Authentifizierungs- und Autorisierungsanmeldeinformationen eine Brücke darauf herstellen. Weitere Informationen finden Sie in der MQTT-Brückendokumentation für HiveMQ, VerneMQ, EMQX und Mosquitto.

Veröffentlichen und Abonnieren von MQTT-Nachrichten mit Azure IoT MQ (Vorschau)

Teilen über

Verbinden des Cloudconnectors der MQTT-Brücke von Azure IoT MQ (Vorschau) mit anderen MQTT Vermittlern.

Konfigurieren des MqttBridgeConnector

MQTT v3.1.1-Support

Anzahl von Instanzen

Client-ID-Konfiguration

Remote-Brokerverbindung

Authentifizierung

Verwaltete Identität

X.509

Lokale Brokerverbindung

TLS-Unterstützung

Konfigurieren von MqttBridgeTopicMap

Routes

Direction

Platzhalter im Quellthema

Referenzquellthema im Ziel

Gemeinsame Abonnements

Azure Event Grid MQTT-Brokerunterstützung

Herstellen einer Verbindung mit dem Event Grid MQTT Vermittler mit verwalteter Identität

Maximale Clientsitzungen pro Authentifizierungsname

Grenzwert pro Verbindung

Brücke von einem anderen Broker zu Azure IoT MQ (Vorschau)

Feedback

Feedback

Zusätzliche Ressourcen

Teilen über

Verbinden des Cloudconnectors der MQTT-Brücke von Azure IoT MQ (Vorschau) mit anderen MQTT Vermittlern.

Konfigurieren des MqttBridgeConnector

MQTT v3.1.1-Support

Anzahl von Instanzen

Client-ID-Konfiguration

Remote-Brokerverbindung

Authentifizierung

Verwaltete Identität

X.509

Lokale Brokerverbindung

TLS-Unterstützung

Konfigurieren von MqttBridgeTopicMap

Routes

Direction

Platzhalter im Quellthema

Referenzquellthema im Ziel

Gemeinsame Abonnements

Azure Event Grid MQTT-Brokerunterstützung

Herstellen einer Verbindung mit dem Event Grid MQTT Vermittler mit verwalteter Identität

Maximale Clientsitzungen pro Authentifizierungsname

Grenzwert pro Verbindung

Brücke von einem anderen Broker zu Azure IoT MQ (Vorschau)

Zugehöriger Inhalt

Feedback

Feedback

Zusätzliche Ressourcen