Partager via

Agent MQTT local intégré à Opérations Azure IoT

  • Article

Important

Cette page inclut des instructions pour la gestion des composants Azure IoT Operations à l’aide des manifestes de déploiement Kubernetes, qui sont en version préliminaire. Cette fonctionnalité est fournie avec plusieurs limitations et ne doit pas être utilisée pour les charges de travail de production.

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.

Azure IoT Operations dispose d’un courtier MQTT de niveau entreprise et conforme aux normes. Le courtier MQTT est évolutif, hautement disponible et natif de Kubernetes. Il fournit le plan de messagerie pour les opérations IoT, permet une communication bidirectionnelle edge/cloud et alimente les applications pilotées par événements en périphérie.

Conformité MQTT

MQTT est devenu le langage commun utilisé parmi les protocoles dans l'espace IoT. La conception simple de MQTT permet à un seul courtier de servir des dizaines de milliers de clients simultanément, avec une création et une gestion de sujets de publication-abonnement légères. De nombreux appareils IoT prennent en charge MQTT de manière native et prête à l'emploi. Les passerelles de traduction en aval rationalisent la longue traîne des protocoles IoT dans MQTT.

Le répartiteur MQTT sous-tend la couche de messagerie dans Les opérations IoT et prend en charge MQTT v3.1.1 et MQTT v5. Pour plus d’informations sur les fonctionnalités MQTT prises en charge, consultez Prise en charge des fonctionnalités MQTT dans MQTT broker.

Architecture

L’Agent MQTT présente trois couches principales :

  • Couche frontale sans état
  • Couche backend avec état et fragmentée

La couche front-end gère les connexions et les requêtes client, puis les achemine vers le back-end. La couche back-end partitionne les données selon différentes clés, telles qu'un ID client pour les sessions client et un nom de sujet pour les messages de sujet. Elle utilise la réplication de chaîne pour répliquer des données au sein de chaque partition.

Les objectifs de l’architecture sont les suivants :

  • Tolérance aux pannes et isolement : la publication des messages se poursuit en cas de défaillance des pods principaux et empêche la propagation des pannes au reste du système.
  • Récupération après échec : Récupération automatique des pannes sans intervention de l'opérateur.
  • Aucune perte de message : Livraison de messages si au moins un pod frontal et un pod backend dans une partition sont 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 Edge et Cloud.
  • Des performances constantes à grande échelle : Limiter la latence des messages en raison de la réplication en chaîne.
  • Simplicité opérationnelle : Dépendance minimale aux composants externes pour simplifier la maintenance et la complexité.

Configuration

Pour la configuration, le courtier MQTT est composé de plusieurs ressources personnalisées Kubernetes qui définissent différents aspects du comportement et des fonctionnalités du courtier :

  • La ressource principale est Broker, qui définit les paramètres globaux, comme la cardinalité, le profil d’utilisation de la mémoire et les paramètres de diagnostic.
  • Une ressource Broker peut avoir jusqu'à trois BrokerListeners, chacun d'eux écoutant les connexions MQTT entrantes sur le type de service spécifié (NodePort, LoadBalancer ou ClusterIP). Chaque ressource BrokerListener peut avoir plusieurs ports.
  • Chaque port d'une ressource BrokerListener peut être associé à une ressource BrokerAuthentication et à une ressource BrokerAuthorization. Ces politiques d’authentification et d’autorisation déterminent quels clients peuvent se connecter au port et quelles actions ils peuvent effectuer sur le courtier.

La relation entre Broker et BrokerListener est de type un-à-plusieurs. La relation entre BrokerListener et BrokerAuthentication/BrokerAuthorization est de type plusieurs-à-plusieurs. Le diagramme entité-relation pour ces ressources est :

Diagramme qui montre le modèle de ressources du courtier.

Par défaut, IoT Operations déploie un Broker par défaut, un BrokerListener par défaut et un BrokerAuthentication par défaut. Toutes ces ressources sont nommées par défaut. Ensemble, ces ressources fournissent une configuration de courtier MQTT de base requise pour le fonctionnement des opérations IoT. La configuration par défaut est :

Diagramme qui montre les ressources du courtier par défaut et les relations entre elles.

Important

Pour éviter toute interruption involontaire de la communication entre les composants internes d'IoT Operations, nous vous recommandons de ne modifier aucune configuration par défaut.

Pour personnaliser le déploiement du courtier MQTT, ajoutez de nouvelles ressources telles que BrokerListeners, BrokerAuthentication et BrokerAuthorization au courtier par défaut.

La ressource Broker est elle-même immuable et ne peut pas être modifiée après le déploiement. Toutefois, elle a seulement besoin d’être personnalisée avec les scénarios avancés. Pour en savoir plus sur la personnalisation de la ressource Broker, consultez Personnaliser la ressource Broker par défaut.

Un déploiement complet peut comporter plusieurs BrokerListeners. Chacun d’entre eux intègre plusieurs ports et chaque port peut avoir différentes ressources BrokerAuthentication et BrokerAuthorization associées.

Par exemple, à partir de la configuration par défaut, vous ajoutez :

  • Un LoadBalancer BrokerListener nommé example-lb-listener, avec les deux ports 1883 et 8883.
  • Un NodePort BrokerListener nommé exemple-listener-nodeport, avec le port unique 1884 (nodePort 31884).
  • Une ressource BrokerAuthentication nommée example-authn, avec une méthode d'authentification personnalisée.
  • Une ressource BrokerAuthorization nommée example-authz, avec vos paramètres d'autorisation personnalisés.

Ensuite, si vous configurez tous les nouveaux ports en utilisant les mêmes ressources BrokerAuthentication et BrokerAuthorization, la configuration ressemble à ceci :

Diagramme montrant un déploiement complet d'un courtier personnalisé et les relations entre chacun.

De cette façon, la configuration par défaut demeure intacte. Vous ajoutez de nouvelles ressources pour personnaliser le déploiement de l’Agent MQTT en fonction de vos besoins.

Ressource Broker par défaut

Chaque déploiement d'opérations IoT ne peut avoir qu'un seul courtier, et il doit être nommé default. La ressource Broker par défaut est requise pour que les opérations IoT fonctionnent. Elle est immuable et ne peut pas être modifiée après le déploiement.

Attention

Ne supprimez pas la ressource Broker par défaut. Cela perturbe la communication entre les composants internes des opérations IoT et le déploiement cesse de fonctionner.

Personnaliser le Broker par défaut

Dans la plupart des configurations, il n’est pas nécessaire de personnaliser le Broker par défaut. Les paramètres qui exigent une personnalisation sont les suivants :

  • Cardinalité : détermine la capacité de l’agent à traiter d’autres connexions et messages et améliore la haute disponibilité en cas de défaillance d’un nœud ou d’un pod.
  • Profil de mémoire : définit l’utilisation maximale de la mémoire de l’agent et comment gérer l’utilisation de la mémoire à mesure que l’agent se développe.
  • Mémoire tampon de message sauvegardée sur disque : configure la mise en mémoire tampon des messages sur le disque lorsque la mémoire RAM sature.
  • Paramètres de diagnostic : configure les paramètres de diagnostic, comme le niveau de consignation et le point de terminaison des métriques.
  • Options de client MQTT avancées : configure les options de client MQTT avancées, comme l’expiration de la session, l’expiration du message et les paramètres de conservation.
  • Chiffrement du trafic interne : configure le chiffrement du trafic interne entre les pods front-end et back-end de l’agent.

Vous pouvez personnaliser le courtier par défaut uniquement pendant la période de déploiement initiale, à l’aide d’Azure CLI ou du Portail Microsoft Azure. Un nouveau déploiement est requis si vous avez besoin de paramètres de configuration de Broker différents.

Pour personnaliser la ressource Broker par défaut pendant le déploiement :

Lorsque vous suivez le guide pour déployer les opérations IoT, dans la section Configuration, regardez sous Configuration du courtier MQTT. Dans ce cas, vous pouvez personnaliser les paramètres de cardinalité et de profil de mémoire. Pour configurer d’autres paramètres, notamment la mémoire tampon de messages sauvegardée sur disque et les options client MQTT avancées, utilisez Azure CLI.

Afficher les paramètres du Broker par défaut

Pour afficher les paramètres du Broker par défaut :

  1. Dans le Portail Azure, accédez à votre instance Opérations IoT.
  2. Sous Composants, sélectionnez Agent MQTT.
  3. Sous Informations sur le Broker, sélectionnez vue JSON.

Contenu connexe