Publier et souscrire à des messages MQTT à l’aide de MQTT broker

Important

Opérations Azure IoT Préversion avec Azure Arc est actuellement en préversion. Vous ne devez pas utiliser ce logiciel en préversion dans des environnements de production.

Lorsqu’une version en disponibilité générale sera publiée, vous devrez déployer une nouvelle installation d’Opérations Azure IoT. Vous ne pourrez pas mettre à niveau une installation en préversion.

Pour connaître les conditions juridiques qui s’appliquent aux fonctionnalités Azure en version bêta, en préversion ou plus généralement non encore en disponibilité générale, consultez l’Avenant aux conditions d’utilisation des préversions de Microsoft Azure.

MQTT broker dispose d’un répartiteur MQTT conforme aux normes d’entreprise qui est évolutif, hautement disponible et natif Kubernetes. Il fournit le plan de messagerie pour les Opérations Azure IoT (préversion), permet la communication bidirectionnelle/cloud et alimente les applications basées sur les événements en périphérie.

Conforme à MQTT

MQTT broker dispose d’un répartiteur MQTT conforme aux normes qui prend en charge MQTT v3.1.1 et MQTT v5.

Le transport de télémétrie de la file d’attente de messages (MQTT) a émergé en tant que lingue franca parmi les protocoles dans l’espace IoT. La conception simple de MQTT permet à un répartiteur unique de servir des dizaines de milliers de clients simultanément, avec une création et une gestion légères de rubriques de publication-abonnement. De nombreux appareils IoT prennent en charge MQTT en mode natif, avec la longue fin des protocoles IoT rationalisés en MQTT par des passerelles de traduction en aval.

MQTT broker utilise le protocole MQTT comme sous-jacent pour la couche de messagerie. Pour plus d’informations sur les fonctionnalités MQTT prises en charge, consultez Prise en charge des fonctionnalités MQTT dans MQTT broker.

Scalabilité et haute disponibilité

Kubernetes peut mettre à l’échelle horizontalement des charges de travail pour s’exécuter dans plusieurs instances. Cette redondance signifie une capacité supplémentaire pour traiter les demandes et la fiabilité en cas de panne d’une instance. Kubernetes dispose d’une auto-réparation intégrée, et les instances sont récupérées automatiquement.

En plus d'être une technologie de mise à l'échelle élastique, Kubernetes est également une norme pour DevOps. Si MQTT est la lingua franca parmi les protocoles IoT, Kubernetes est la lingua franca pour la couche d'infrastructure informatique. En adoptant Kubernetes, vous pouvez utiliser partout le même pipeline CI/CD, les mêmes outils, la même surveillance, le même packaging d'applications, la même qualification des employés. Le résultat est un système de bout en bout unique à partir du cloud computing, des serveurs locaux et des passerelles IoT plus petites au niveau de l’usine. Vous pouvez passer moins de temps à gérer l’infrastructure ou DevOps et vous concentrer sur votre entreprise.

MQTT broker se concentre sur la valeur unique du plan de données natif de périphérie qu’il peut fournir à l’écosystème Kubernetes tout en s’y intégrant en toute transparence. Il offre un plan de plateforme de messagerie hautes performances et évolutif conçu autour de MQTT et une intégration transparente à d’autres charges de travail Kubernetes évolutives et Azure.

Sécurisé par défaut

MQTT broker s’appuie sur des concepts de sécurité et d’identité natifs d’Azure et de Kubernetes qui ont fait leurs preuves, ce qui le rend à la fois hautement sécurisé et utilisable. Il prend en charge plusieurs mécanismes d’authentification pour la flexibilité, ainsi que les mécanismes de contrôle d’accès granulaires jusqu’au niveau de rubrique MQTT individuel.

Conseil

Vous pouvez accéder au déploiement du MQTT broker par défaut seulement en utilisant l’adresse IP du cluster, le protocole TLS et un jeton de compte de service. Les clients se connectant depuis l’extérieur du cluster ont besoin d’une configuration supplémentaire pour pouvoir se connecter.

Intégration d’Azure Arc

La plateforme hybride de Microsoft est ancrée autour de Kubernetes avec Azure Arc en tant que plan de contrôle unique. Il fournit un plan de gestion qui projette des ressources autres qu’Azure, locales ou autres dans Azure Resource Manager. Il en résulte un volet de contrôle unique pour gérer les machines virtuelles, les clusters Kubernetes et les bases de données qui ne s'exécutent pas dans les centres de données Azure.

MQTT broker est déployé en tant qu’extension Azure Arc pour Kubernetes et peut être géré via un fournisseur de ressources Azure complet ( RP) – microsoft/IoTOperationsMQ. Cela signifie que vous pouvez le gérer comme les ressources cloud Azure natives telles que les machines virtuelles, le stockage, etc.

La technologie Azure Arc permet aux modifications de prendre effet sur les services MQTT broker s’exécutant sur le cluster Kubernetes local. Si vous préférez une approche native entièrement Kubernetes, vous pouvez gérer MQTT broker avec des définitions de ressources personnalisées Kubernetes (CRD) localement ou à l’aide de technologies GitOps comme Flux.

Connecteurs cloud

Vous pouvez avoir des exigences de messagerie différentes pour votre scénario cloud. Par exemple, un chemin rapide bidirectionnel cloud/edge pour les données à priorité élevée ou pour alimenter des tableaux de bord cloud en quasi temps réel et un chemin lent à moindre coût pour des données moins critiques en temps réel qui peuvent être mises à jour par lots.

Pour plus de flexibilité, MQTT broker fournit des connecteurs Azure intégrés à Event Hubs (avec point de terminaison Kafka), la capacité MQTT broker d’Event Grid, Microsoft Fabric et Stockage Blob. MQTT broker est extensible afin que vous puissiez choisir votre solution de messagerie cloud préférée qui fonctionne avec votre solution.

En plus d’Azure Arc, les connecteurs peuvent être configurés pour utiliser l’identité managée Azure pour accéder aux services cloud avec un puissant contrôle d’accès en fonction du rôle (RBAC). Aucune gestion manuelle, non sécurisée et fastidieuse des informations d’identification n’est requise.

Modèle de programmation Dapr

Dapr simplifie la liaison entre les applications distribuées en exposant les capacités communes des applications distribuées, telles que la gestion de l'état, l'invocation de service à service et la messagerie de publication et d'abonnement. Les composants Dapr se trouvent sous les modules et fournissent l’implémentation concrète pour chaque fonctionnalité. Vous pouvez vous concentrer sur la logique métier et laisser Dapr gérer les détails de l’application distribuée.

MQTT broker fournit des blocs de construction enfichables Dapr publish-subscribe et state store, ce qui facilite le développement et le déploiement d’applications événementielles à la périphérie et permet de s’affranchir de la technologie.

Architecture

Le répartiteur MQTT a trois couches :

• Couche frontale sans état qui gère les demandes du client
• Équilibreur de charge qui achemine les requêtes et connecte le répartiteur à d’autres personnes
• Couche back-end avec état et partitionnée qui stocke et traite les données

La couche back-end partitionne les données par différentes clés, telles que l’ID client pour les sessions clientes et le nom de rubrique pour les messages de rubrique. Elle utilise la réplication de chaîne pour répliquer des données au sein de chaque partition. Pour les données partagées par toutes les partitions, elle utilise une seule chaîne qui s’étend sur toutes les partitions.

Les objectifs de l’architecture sont les suivants :

• Tolérance et isolation des pannes : la publication de messages continue si les nœuds back-end échouent et empêchent la propagation d’échecs vers le reste du système
• Récupération de défaillance : récupération automatique des défaillances sans intervention de l’opérateur
• Aucune perte de message : remise de messages si au moins un nœud frontal et un nœud principal est en cours d’exécution
• Mise à l’échelle élastique : mise à l’échelle horizontale du débit de publication et d’abonnement pour prendre en charge les déploiements de périphérie et de cloud
• Performances cohérentes à grande échelle: limitez la surcharge de latence des messages en raison de la réplication en chaîne
• Simplicité opérationnelle : dépendance minimale des composants externes pour simplifier la maintenance et la complexité

Étapes suivantes

Déployer Opérations Azure IoT sur un cluster Kubernetes avec Arc