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.
Les fonctionnalités d’Opérations Azure IoT disposent d’un Agent 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, permet la communication bidirectionnelle/cloud et alimente les applications basées sur les événements en périphérie.
Conformité MQTT
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.
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 :
- La couche front-end sans état.
- La couche back-end avec état et shardé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, comme l’ID client pour les sessions client 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.
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 des défaillances 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 : les messages sont remis si au moins un pod front-end et un pod back-end d’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 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é
Configuration
Pour la configuration, l’Agent MQTT intègre plusieurs ressources personnalisées Kubernetes qui définissent différents aspects du comportement et des fonctionnalités de l’agent.
- 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.
- Un Broker peut comporter jusqu’à trois BrokerListeners. Chacun d’entre eux écoute les connexions MQTT entrantes sur le type de service spécifié (NodePort, LoadBalancer ou ClusterIP). Chaque BrokerListener peut avoir plusieurs ports.
- Chaque port d’un BrokerListener peut être associé à une ressource BrokerAuthentication et à une ressource BrokerAuthorization. Ces ressources définissent les stratégies d’authentification et d’autorisation qui déterminent qui peut se connecter au port et quelles actions ces utilisateurs peuvent effectuer sur l’agent.
Par conséquent, la relation entre Broker et BrokerListener est un-à-plusieurs, et la relation entre BrokerListener et BrokerAuthentication/BrokerAuthorization est plusieurs-à-plusieurs. Pour ces ressources, le diagramme entité-association (ERD) est le suivant :
Par défaut, Opérations Azure IoT 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 assurent la configuration de l’Agent MQTT de base nécessaire au fonctionnement d’Opérations Azure IoT. La configuration par défaut est la suivante :
Important
Pour éviter toute interruption involontaire de la communication entre les composants internes d’Opérations Azure IoT, nous recommandons de ne pas modifier la configuration par défaut.
Pour personnaliser le déploiement de l’Agent MQTT, ajoutez de nouvelles ressources (comme BrokerListeners, BrokerAuthentication et BrokerAuthorization) à l’agent 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 BrokerListener LoadBalancer nommé example-lb-listener avec deux ports 1883 et 8883
- Un BrokerListener NodePort nommé example-nodeport-listener avec un seul port 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 avez configuré tous les nouveaux ports pour qu’ils utilisent les mêmes ressources BrokerAuthentication et BrokerAuthorization, la configuration est la suivante :
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 Azure IoT ne peut comporter qu’un seul Broker qui doit être nommé par défaut. La ressource Broker par défaut est nécessaire au fonctionnement d’Opérations Azure IoT. 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 d’Opérations Azure 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 devez personnaliser l’agent par défaut pendant le temps de déploiement initial à l’aide de l’interface Azure CLI ou du portail Azure. Pour modifier les paramètres de configuration du Broker, un nouveau déploiement est nécessaire.
Pour personnaliser la ressource Broker par défaut pendant le déploiement :
Lorsque vous suivez le guide pour déployer Opérations Azure IoT, dans la section Configuration, consultez Configuration de l’Agent MQTT. Dans ce cas, vous pouvez personnaliser les paramètres de cardinalité et de profil de mémoire. Pour configurer d’autres paramètres, y compris la mémoire tampon de message sur disque et les options de client MQTT avancées, utilisez l’interface Azure CLI.
Afficher les paramètres du Broker par défaut
Pour afficher les paramètres du Broker par défaut :
- Dans le Portail Azure, accédez à votre instance Opérations Azure IoT.
- Sous Composants, sélectionnez Agent MQTT.
- Sous Informations sur le Broker, sélectionnez vue JSON.
Étapes suivantes
Déployer Opérations Azure IoT sur un cluster Kubernetes avec Arc