Modèle de configuration de la charge de travail Edge
La grande variété des systèmes et des appareils en place dans un atelier peut compliquer la configuration de la charge de travail. Cet article fournit plusieurs approches pour vous faciliter la tâche.
Contexte et problème
Dans le cadre de leur parcours de transformation numérique, les entreprises industrielles se focalisent de plus en plus sur la création de solutions logicielles qui peuvent être réutilisées sous forme de fonctionnalités partagées. En raison de la diversité des appareils et des systèmes dans un atelier, les charges de travail modulaires sont configurées pour prendre en charge différents protocoles, pilotes et formats de données. Parfois, il arrive même que plusieurs instances d’une charge de travail soient exécutées avec des configurations différentes dans le même emplacement en périphérie. Pour certaines charges de travail, les configurations sont mises à jour plusieurs fois par jour. La gestion de la configuration occupe donc une place de plus en plus importante dans le scale-out des solutions de périphérie.
Solution
Voici quelques caractéristiques courantes de la gestion de la configuration pour les charges de travail de périphérie :
- Plusieurs points de configuration peuvent être regroupés en couches distinctes, comme la source logicielle, le pipeline CI/CD, le locataire cloud et l’emplacement de périphérie :
- Les différentes couches peuvent être mises à jour par différentes personnes.
- Quelle que soit la façon dont les configurations sont mises à jour, elles doivent être suivies et auditées avec attention.
- Pour assurer la continuité de l’activité, il est nécessaire que les configurations soient accessibles hors connexion à la périphérie.
- Il est également nécessaire d’avoir une vue globale des configurations disponibles dans le cloud.
Problèmes et considérations
Prenez en compte les points suivants lorsque vous choisissez comment implémenter ce modèle :
- Le fait d’autoriser les modifications lorsque la périphérie n’est pas connectée au cloud augmente considérablement la complexité de la gestion de la configuration. Il est possible de répliquer les modifications dans le cloud, mais cela peut créer des difficultés dans les domaines suivants :
- Authentification des utilisateurs, car elle s’appuie sur un service cloud comme Microsoft Entra ID.
- Résolution des conflits après une reconnexion, si les charges de travail reçoivent des configurations inattendues qui nécessitent une intervention manuelle.
- L’environnement de périphérie peut avoir des contraintes liées au réseau si la topologie est conforme aux exigences de la norme ISA-95. Vous pouvez surmonter ces restrictions en sélectionnant une technologie qui offre une connectivité entre les couches, comme les hiérarchies d’appareils dans Azure IoT Edge.
- Si la configuration à l’exécution est dissociée des publications de logiciels, les modifications de configuration doivent être gérées séparément. Pour offrir des fonctionnalités d’historique et de restauration, vous devez stocker les configurations passées dans un magasin de données dans le cloud.
- Une erreur dans une configuration, comme un composant de connectivité configuré vers un point de terminaison inexistant, peut arrêter la charge de travail. Il est donc important de traiter les modifications de configuration au fur et à mesure que vous traitez les autres événements du cycle de vie de déploiement dans la solution d’observabilité, afin que les tableaux de bord d’observabilité puissent mettre en corrélation les erreurs système avec les modifications de configuration. Pour plus d’informations sur l’observabilité, consultez le Guide de monitoring du cloud : observabilité.
- Prenez connaissance des rôles que jouent les magasins de données dans le cloud et en périphérie dans la continuité de l’activité. Si le magasin de données cloud est la seule source de vérité, les charges de travail de périphérie doivent être en mesure de restaurer les états prévus en utilisant des processus automatisés.
- À des fins de résilience, le magasin de données de périphérie doit agir comme un cache hors connexion. Cela a priorité sur les considérations relatives à la latence.
Quand utiliser ce modèle
Utilisez ce modèle dans les situations suivantes :
- Il est nécessaire de configurer des charges de travail en dehors du cycle de publication des logiciels.
- Différentes personnes doivent être en mesure de lire et de mettre à jour les configurations.
- Les configurations doivent être disponibles même en l’absence de connexion au cloud.
Exemples de charges de travail :
- Solutions qui se connectent aux ressources de l’atelier pour l’ingestion des données (OPC Publisher, par exemple) ainsi que la commande et le contrôle
- Charges de travail de Machine Learning pour la maintenance prédictive
- Charges de travail de Machine Learning qui inspectent en temps réel la qualité sur la chaîne de fabrication
Exemples
La solution pour configurer des charges de travail de périphérie à l’exécution peut être basée sur un contrôleur de configuration externe ou un fournisseur de configuration interne.
Variation du contrôleur de configuration externe
Cette variation présente un contrôleur de configuration externe à la charge de travail. Le rôle du composant contrôleur de configuration cloud est d’envoyer (push) les modifications du magasin de données cloud à la charge de travail par le biais du contrôleur de configuration de périphérie. La périphérie contient également un magasin de données afin que le système fonctionne même quand il est déconnecté du cloud.
Avec IoT Edge, le contrôleur de configuration de périphérie peut être implémenté en tant que module, et les configurations peuvent être appliquées avec des jumeaux de module. La taille du jumeau de module est limitée. Si la configuration dépasse la limite, la solution peut être étendue en utilisant le Stockage Blob Azure ou en segmentant les charges utiles plus importantes sur des méthodes directes.
Les avantages de cette variation sont les suivants :
- La charge de travail n’a pas besoin de connaître le système de configuration. Cette capacité est obligatoire si le code source de la charge de travail n’est pas modifiable, par exemple en cas d’utilisation d’un module de la Place de marché Azure IoT Edge.
- Il est possible de modifier la configuration de plusieurs charges de travail simultanément en coordonnant les modifications par le biais du contrôleur de configuration cloud.
- Une validation supplémentaire peut être implémentée dans le cadre du pipeline d’envoi, par exemple pour valider l’existence de points de terminaison en périphérie avant d’envoyer la configuration à la charge de travail.
Variation du fournisseur de configuration interne
Dans la variation du fournisseur de configuration interne, la charge de travail tire (pull) les configurations d’un fournisseur de configuration. Pour obtenir un exemple d’implémentation, consultez Implémenter un fournisseur de configuration personnalisé dans .NET. Cet exemple est écrit en C#, mais vous pouvez utiliser d’autres langages.
Dans cette variation, les charges de travail ont des identificateurs uniques, ce qui permet au même code source s’exécutant dans différents environnements d’avoir des configurations différentes. Une façon de construire un identificateur consiste à concaténer la relation hiérarchique de la charge de travail et un regroupement de niveau supérieur, comme un locataire. Pour IoT Edge, vous pouvez combiner un groupe de ressources Azure, un nom de hub IoT, un nom d’appareil IoT Edge et un identificateur de module. Ces valeurs forment un identificateur unique qui fonctionne comme une clé dans les magasins de données.
Bien que la version du module puisse être ajoutée à l’identificateur unique, il est souvent nécessaire de conserver les configurations d’une mise à jour de logiciel à l’autre. Si la version fait partie de l’identificateur, l’ancienne version de la configuration doit alors être migrée avec une implémentation supplémentaire.
Les avantages de cette variation sont les suivants :
- Outre les magasins de données, la solution ne nécessite pas de composants, réduisant ainsi la complexité.
- La logique de migration à partir d’anciennes versions incompatibles peut être gérée dans l’implémentation de la charge de travail.
Solutions basées sur IoT Edge
Le composant cloud de l’implémentation de référence IoT Edge se compose d’un hub IoT qui agit comme contrôleur de configuration cloud. La fonctionnalité de jumeau de module Azure IoT Hub propage les modifications de configuration et les informations sur la configuration actuellement appliquée en utilisant les propriétés souhaitées et signalées du jumeau de module. Le service de gestion de la configuration fait office de source des configurations. Il peut également s’agir d’une interface utilisateur pour la gestion des configurations, d’un système de build ou d’autres outils utilisés pour créer des configurations de charge de travail.
Une base de données Azure Cosmos DB stocke toutes les configurations. Elle peut interagir avec plusieurs hubs IoT et fournit l’historique de la configuration.
Une fois qu’un appareil de périphérie indique par le biais de propriétés signalées qu’une configuration a été appliquée, le service d’état de configuration note l’événement dans l’instance de base de données.
Quand une configuration est créée dans le service de gestion de la configuration, elle est stockée dans Azure Cosmos DB et les propriétés souhaitées du module de périphérie sont modifiées dans le hub IoT où réside l’appareil. La configuration est ensuite transmise par IoT Hub à l’appareil de périphérie. Le module de périphérie est censé appliquer la configuration et signaler l’état de la configuration par le biais du jumeau de module. Le service d’état de configuration écoute ensuite les événements de modification du jumeau. S’il détecte qu’un module signale une modification de l’état de configuration, il enregistre la modification correspondante dans la base de données Azure Cosmos DB.
Le composant de périphérie peut utiliser le contrôleur de configuration externe ou le fournisseur de configuration interne. Dans les deux implémentations, la configuration est transmise dans les propriétés souhaitées du jumeau de module. Si des configurations volumineuses doivent être transmises, les propriétés souhaitées du jumeau de module contiennent une URL vers le Stockage Blob Azure ou un autre service qui peut être utilisé pour récupérer la configuration. Le module indique ensuite dans les propriétés signalées du jumeau de module si la nouvelle configuration a été appliquée et la configuration actuellement appliquée.
Contributeurs
Cet article est géré par Microsoft. Il a été écrit à l’origine par les contributeurs suivants.
Auteur principal :
- Heather Camm | Responsable de programme confirmé
Pour afficher les profils LinkedIn non publics, connectez-vous à LinkedIn.
Étapes suivantes
- Azure IoT Edge
- Qu’est-ce qu’Azure IoT Edge ?
- Azure IoT Hub
- Concepts IoT et Azure IoT Hub
- Azure Cosmos DB
- Bienvenue dans Azure Cosmos DB
- Stockage Blob Azure
- Introduction à Stockage Blob Azure