Concepts du reprovisionnement d’appareils IoT Hub
Durant le cycle de vie d’une solution IoT, il est fréquent d’avoir à déplacer des appareils d’un hub IoT à un autre. Voici quelques scénarios nécessitant le déplacement d’un appareil :
Géolocalisation et géolatence : quand un appareil change souvent d’emplacement, il doit être migré vers un hub IoT plus proche de son emplacement pour améliorer la latence du réseau.
Multilocation : un appareil est utilisé dans la même solution IoT et est réassigné à un nouveau client ou site client. Le service fourni à ce nouveau client peut utiliser un autre hub IoT.
Changement de solution : un appareil est déplacé dans une nouvelle solution IoT ou une solution IoT mise à jour. Cette réassignation peut nécessiter que l’appareil communique avec un nouveau hub IoT qui est connecté à d’autres composants back-end.
Mise en quarantaine : ce scénario est similaire à un changement de solution. Il est possible qu’un appareil défectueux, compromis ou obsolète soit réassigné à un hub IoT qui peut uniquement effectuer la mise à jour et la remise en conformité. Une fois que l’appareil fonctionne correctement, il est transféré à nouveau vers son hub principal.
La prise en charge du reprovisionnement dans le service Device Provisioning permet de gérer ces différents scénarios. Les appareils peuvent être automatiquement réassignés à de nouveaux hubs IoT selon la stratégie de reprovisionnement qui est configurée dans l’entrée d’inscription de l’appareil.
Données d’état de l’appareil
Les données d’état de l’appareil englobent les fonctionnalités de l’appareil et du jumeau d’appareil. Ces données sont stockées dans l’instance du service Device Provisioning et dans le hub IoT auquel l’appareil est assigné.
Quand un appareil est initialement provisionné avec une instance du service Device Provisioning, les étapes suivantes sont effectuées :
L’appareil envoie une demande de provisionnement à l’instance du service Device Provisioning. L’instance du service authentifie l’identité de l’appareil par rapport à une entrée d’inscription et crée la configuration initiale des données d’état de l’appareil. L’instance du service assigne l’appareil à un hub IoT en fonction de la configuration de l’inscription, puis retourne cette assignation de hub IoT à l’appareil.
L’instance du service Device Provisioning transmet une copie des données d’état initiales de l’appareil au hub IoT assigné. L’appareil se connecte au hub IoT assigné et commence ses opérations.
Les données d’état de l’appareil sur le hub IoT peuvent être mises à jour au fur et à mesure par des opérations sur l’appareil et des opérations sur le backend. Les données d’état initiales de l’appareil qui sont stockées dans l’instance du service Device Provisioning ne sont pas modifiées. Ces données correspondent à la configuration initiale.
Dans certains scénarios, quand un appareil est déplacé d’un hub IoT à un autre, il peut également être nécessaire de migrer l’état mis à jour de l’appareil de l’ancien hub IoT vers le nouveau hub IoT. Cette migration est gérée par les stratégies de reprovisionnement configurées dans le service Device Provisioning.
Stratégies de réapprovisionnement
Selon le scénario, un appareil could peut envoyer une demande à une instance du service Device Provisioning au redémarrage. Il prend aussi en charge une méthode pour déclencher manuellement le provisionnement à la demande. La stratégie de reprovisionnement sur une entrée d’inscription définit de quelle manière l’instance du service Device Provisioning gère ces demandes de provisionnement. La stratégie détermine également si les données d’état de l’appareil doivent être migrées au moment du reprovisionnement. Les mêmes stratégies sont disponibles pour les inscriptions individuelles et les groupes d’inscriptions :
Réapprovisionner et migrer les données : il s’agit de la stratégie par défaut pour les nouvelles entrées d’inscription. Cette stratégie est appliquée quand des appareils associés à l’entrée d’inscription envoient une nouvelle demande (1). Selon la configuration de l’entrée d’inscription, l’appareil peut être réassigné à un autre hub IoT. Si l’appareil est déplacé vers un autre hub IoT, il est désinscrit du hub IoT initial. Les données d’état de l’appareil qui ont été mises à jour dans ce hub IoT initial sont alors migrées vers le nouveau hub IoT (2). Durant la migration, l’état de l’appareil indique Affectation.
Réapprovisionner et rétablir la configuration initiale : cette stratégie est appliquée quand des appareils associés à l’entrée d’inscription envoient une demande de nouveau approvisionnement (1). Selon la configuration de l’entrée d’inscription, l’appareil peut être réassigné à un autre hub IoT. Si l’appareil est déplacé vers un autre hub IoT, il est désinscrit du hub IoT initial. Les données de configuration initiale que l’instance du service Device Provisioning a reçues au moment du provisionnement de l’appareil sont transmises au nouveau hub IoT (2). Durant la migration, l’état de l’appareil indique Affectation.
Cette stratégie est souvent utilisée dans le cadre d’une réinitialisation aux paramètres d’usine sans changer les hubs IoT.
Ne jamais réapprovisionner : L’appareil n’est jamais réaffecté à un autre hub. Cette stratégie est fournie pour gérer la compatibilité descendante.
Remarque
DPS appellera toujours le webhook d’allocation personnalisée, quelle que soit la stratégie de réapprovisionnement en cas de nouvelles ReturnData pour l’appareil. Si la stratégie de réapprovisionnement est définie sur Ne jamais réapprovisionner, le webhook est appelé, mais l’appareil ne change pas son hub attribué.
Lors de la conception de votre solution et de la définition d’une logique de reprovisionnement, plusieurs éléments sont à prendre en compte. Par exemple :
- La fréquence à laquelle vous prévoyez que vos appareils redémarreront
- Les quotas et limites DPS
- La durée de déploiement attendue pour votre flotte (déploiement échelonné ou tous en même temps)
- La fonctionnalité de nouvelle tentative implémentée sur votre code client, telle que décrite dans les recommandations générales concernant les nouvelles tentatives dans le Centre des architectures Azure
Conseil
Nous vous recommandons de ne pas provisionner à chaque redémarrage de l’appareil, car cela peut entraîner des problèmes lors du reprovisionnement de plusieurs milliers ou millions d’appareils à la fois. Vous devez plutôt tenter d’utiliser l’API de recherche de l’état d’inscription de l’appareil pour essayer de vous connecter avec ces informations à IoT Hub. En cas d’échec, essayez de procéder à un reprovisionnement, car les informations IoT Hub pourraient avoir changé. N’oubliez pas que l’interrogation de l’état d’inscription sera comptabilisée comme une nouvelle inscription d’appareil. Vous devez donc prendre en compte la limite d’inscriptions d’appareils. Envisagez également d’implémenter une logique de nouvelle tentative appropriée, telle qu’un backoff exponentiel avec randomisation, comme décrit dans les recommandations générales concernant les nouvelles tentatives. Dans certains cas, selon les fonctionnalités de l’appareil, il est possible d’enregistrer les informations IoT Hub directement sur l’appareil pour se connecter directement à IoT Hub après le provisionnement initial à l’aide de DPS. Si vous choisissez de procéder ainsi, veillez à implémenter un mécanisme de secours au cas où des erreurs spécifiques à partir du hub se produiraient. Considérez par exemple les scénarios suivants :
- Réessayez l’opération du hub si le code de résultat est 429 (trop de requêtes) ou si vous rencontrez une erreur dans la plage 5xx. N’effectuez pas de nouvelle tentative pour toute autre erreur.
- Pour les erreurs 429, ne réessayez qu’après l’heure indiquée dans l’en-tête Retry-after (nouvelle tentative après).
- Pour les erreurs 5xx, utilisez le backoff exponentiel, avec la première tentative d’au moins 5 secondes après la réponse.
- Lors d’erreurs autres que 429 et 5xx, réeffectuez l’inscription par le biais de DPS
- Dans l’idéal, vous devez également prendre en charge une méthode pour déclencher manuellement le provisionnement à la demande.
Nous vous recommandons également de tenir compte des limites du service lors de la planification d’activités telles que l’envoi (push) de mises à jour à votre flotte. Par exemple, la mise à jour de la flotte en une seule fois peut entraîner la réinscription de tous les appareils par le biais de DPS (ce qui pourrait facilement dépasser le quota d’inscriptions). Pour de tels scénarios, envisagez de planifier les mises à jour de l’appareil en plusieurs phases, au lieu de mettre à jour l’ensemble de votre flotte en même temps.
Gestion de la compatibilité descendante
Avant septembre 2018, les assignations d’appareils à des hubs IoT avaient un comportement fixe. Quand un appareil suivait un processus de provisionnement, il était seulement réassigné au même hub IoT.
Pour les solutions qui dépendent de ce comportement, le service Device Provisioning gère la compatibilité descendante. Ce comportement est actuellement maintenu pour les appareils selon les critères suivants :
Les appareils se connectent avec une version d’API antérieure à la mise à disposition de la prise en charge native du reprovisionnement dans le service Device Provisioning. Reportez-vous au tableau des versions d’API ci-dessous.
Il n’existe pas de stratégie de reprovisionnement configurée dans l’entrée d’inscription des appareils.
Cette compatibilité garantit que les appareils précédemment déployés conservent le même comportement que celui qu’ils avaient lors des tests initiaux. Pour conserver le comportement initial, ne configurez pas de stratégie de reprovisionnement pour ces inscriptions. Si une stratégie de reprovisionnement est configurée, elle est prioritaire sur le comportement. Les clients peuvent alors mettre à jour le comportement de l’appareil sans avoir à réinitialiser ce dernier.
L’organigramme suivant aide à illustrer le processus du comportement :
Le tableau suivant répertorie les versions d’API antérieures à la mise à disposition de la prise en charge native du reprovisionnement dans le service Device Provisioning :
| API REST | Kit SDK C | Kit de développement logiciel (SDK) Python | Node SDK | Kit SDK Java | Kit de développement logiciel (SDK) .NET |
|---|---|---|---|---|---|
| 2018-04-01 et versions antérieures | 1.2.8 et versions antérieures | 1.4.2 et versions antérieures | 1.7.3 ou version antérieure | 1.13.0 ou version antérieure | 1.1.0 ou version antérieure |
Remarque
Ces valeurs et ces liens sont susceptibles de changer. Il s’agit ici uniquement de tenter de déterminer là où les versions peuvent être définies par un client et les versions attendues.