Partager via

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

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 inclut un répartiteur MQTT conforme aux normes et aux niveaux d’entreprise. Le répartiteur MQTT est évolutif, hautement disponible et kubernetes natif. Il fournit le plan de messagerie pour les opérations IoT, active la communication bidirectionnelle de périphérie à cloud et prend en charge les applications pilotées par les événements à la périphérie.

Conformité MQTT

MQTT est un protocole commun dans l’espace IoT. Sa conception simple permet à un répartiteur unique de servir des milliers de clients simultanément avec la création et la gestion de rubriques de publication-abonnement légères. De nombreux appareils IoT prennent en charge MQTT en mode natif. Les passerelles de traduction en aval convertissent différents protocoles IoT en MQTT.

Le répartiteur MQTT prend en charge la couche de messagerie dans Les opérations IoT et est compatible avec 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 des clients, et les route vers le serveur principal. La couche back-end partitionne les données par clés, comme un ID client pour les sessions clientes et un nom de rubrique pour les messages de rubrique. La couche back-end utilise la réplication de chaîne pour copier des données dans chaque partition.

Les objectifs de l’architecture sont les suivants :

  • Tolérance et isolation des pannes : la publication de messages continue si les pods principaux échouent et que les échecs ne se propagent pas 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 : les messages sont remis si au moins un pod frontal et un pod backend sont en cours d'exécution dans une partition.
  • Mise à l’échelle élastique : la mise à l’échelle horizontale du débit de publication et d’abonnement prend en charge les déploiements de périphérie et de cloud.
  • Performances cohérentes à grande échelle : limite la surcharge de latence des messages en raison de la réplication de chaîne.
  • Simplicité opérationnelle : réduit la dépendance vis-à-vis des composants externes pour simplifier la maintenance et la complexité.

Paramétrage

Pour la configuration, le répartiteur MQTT utilise plusieurs ressources personnalisées Kubernetes pour définir différents aspects du comportement et des fonctionnalités du répartiteur :

  • 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 un-à-plusieurs, tandis que la relation entre BrokerListener et BrokerAuthentication/BrokerAuthorization est 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 de perturber la communication entre les composants internes d’IoT Operations, ne modifiez aucune configuration par défaut.

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

La ressource Broker est immuable et ne peut pas être modifiée après le déploiement, mais elle nécessite une personnalisation uniquement dans 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.

Si vous configurez tous les nouveaux ports avec les mêmes ressources BrokerAuthentication et BrokerAuthorization, le programme d’installation ressemble à ceci :

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

Cette approche conserve la configuration par défaut intacte et vous permet d’ajouter de nouvelles ressources pour personnaliser le déploiement du répartiteur MQTT.

Ressource Broker par défaut

Chaque déploiement d’opérations IoT ne peut avoir qu’un seul répartiteur et doit être nommé par défaut. 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

La personnalisation de la ressource broker par défaut n’est pas nécessaire pour la plupart des configurations. 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 répartiteur par défaut uniquement pendant le déploiement initial, à l’aide d’Azure CLI ou du portail Azure. Un nouveau déploiement est nécessaire si vous avez besoin de différents paramètres de configuration du répartiteur.

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 message sauvegardée sur disque et les options avancées du client MQTT, utilisez Azure CLI.

Important

Vous ne pouvez pas mettre à jour la ressource broker après le déploiement initial. Les modifications de configuration apportées à la cardinalité, au profil mémoire ou à la mémoire tampon de disque ne sont pas autorisées après le déploiement.

Pour contourner ce problème, lors du déploiement d’Opérations Azure IoT avec la commande az iot ops init, vous pouvez inclure le paramètre --broker-config-file avec un fichier de configuration JSON pour l’Agent MQTT. Pour plus d’informations, consultez Configuration avancée de l’Agent MQTT et Configurer les paramètres principaux de l’Agent MQTT.

Afficher les paramètres du Broker par défaut

Pour afficher les paramètres du répartiteur 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