Haute disponibilité et récupération d’urgence IoT Hub :

La première étape de l’implémentation d’une solution IoT résiliente consiste, pour les architectes, développeurs et chefs d’entreprise, à définir les objectifs de temps de fonctionnement pour les solutions qu’ils développent. Ces objectifs peuvent être principalement définis en fonction des objectifs stratégiques applicables à chaque scénario. Dans ce contexte, l’article Conception d’applications résilientes pour Azure décrit un cadre général qui vous aide à réfléchir aux questions de continuité d'activité et de reprise d'activité. Le document Récupération d’urgence et haute disponibilité pour les applications Azure contient des recommandations d’architecture concernant les stratégies permettant de mettre en place la haute disponibilité et la récupération d’urgence dans les applications Azure.

Cet article décrit les fonctionnalités de haute disponibilité et de récupération d’urgence offertes par le service IoT Hub. Il aborde essentiellement les aspects suivants :

• Haute disponibilité intra-région
• Récupération d’urgence inter-région
• Haute disponibilité inter-région

Selon les objectifs de temps d’activité que vous définissez pour vos solutions IoT, vous devez identifier parmi les options décrites dans cet article celle qui correspond le mieux à vos objectifs stratégiques. L’intégration de ces alternatives de haute disponibilité/récupération d’urgence dans votre solution IoT suppose d’évaluer minutieusement les compromis entre :

• le niveau de résilience dont vous avez besoin ;
• la complexité d’implémentation et de maintenance ;
• l’impact du coût des marchandises vendues.

Haute disponibilité intra-région

Le service IoT Hub fournit une haute disponibilité intra-région en implémentant les redondances à presque tous les niveaux du service. Le SLA publié par le service IoT Hub est atteint grâce à l’utilisation de ces redondances. Les développeurs d’une solution IoT peuvent tirer parti de ces fonctionnalités de haute disponibilité sans le moindre effort supplémentaire. Bien qu’IoT Hub offre une garantie de disponibilité raisonnablement élevée, des défaillances temporaires peuvent toujours se produire comme avec n’importe quelle plateforme informatique distribuée. Si vous démarrez seulement avec la migration de vos solutions locales vers le cloud, vous devez vous concentrer davantage sur l’optimisation du « temps moyen de récupération » que sur le « délai moyen entre défaillances ». En d’autres termes, les défaillances temporaires sont considérées comme normales lorsque le cloud est dans la balance. Des stratégies de nouvelle tentative appropriées doivent être intégrées dans les composants qui interagissent avec une application cloud de manière à gérer les défaillances temporaires.

Zones de disponibilité

IoT Hub prend en charge les zones de disponibilité Azure. Une zone de disponibilité est une offre à haute disponibilité qui protège vos applications et vos données contre les défaillances des centres de données. Une région avec prise en charge des zones de disponibilité est composée au minimum de trois zones prenant en charge cette région. Chaque zone fournit un ou plusieurs centres de données, chacun dans un emplacement physique unique avec une alimentation, un refroidissement et un réseau indépendants. Cette configuration assure la réplication et la redondance au sein de la région.

Les zones de disponibilité offrent deux avantages : la résilience des données et des déploiements plus fluides.

La résilience des données provient du remplacement des services de stockage sous-jacents par le stockage pris en charge par les zones de disponibilité. La résilience des données est importante pour les solutions IoT, car ces solutions fonctionnent souvent dans des environnements complexes, dynamiques et incertains où les défaillances ou les interruptions peuvent avoir des conséquences importantes. Qu’une solution IoT prenne en charge un atelier de fabrication, des environnements de vente au détail ou de restauration, des systèmes de santé ou une infrastructure, la disponibilité et la qualité des données sont nécessaires pour récupérer après des défaillances et fournir des services fiables et cohérents.

Les déploiements plus fluides proviennent du remplacement du matériel du centre de données sous-jacent par du matériel plus récent qui prend en charge les zones de disponibilité. Ces améliorations matérielles réduisent l’impact sur les clients des déconnexions et des reconnexions des appareils, et des temps d’arrêt liés au déploiement. L’équipe d’ingénierie IoT Hub déploie plusieurs mises à jour sur chaque hub IoT chaque mois, pour des raisons de sécurité et pour apporter des améliorations aux fonctionnalités. Le matériel pris en charge par les zones de disponibilité est divisé en 15 domaines de mise à jour afin que chaque mise à jour soit plus fluide, avec un impact minimal sur vos flux de travail. Pour plus d’informations sur les domaines de mise à jour, consultez Groupes à haute disponibilité.

La prise en charge des zones de disponibilité pour IoT Hub est activée automatiquement pour les nouvelles ressources IoT Hub créées dans les régions Azure suivantes :

Région	Résilience des données	Déploiements plus fluides
Australie Est
Brésil Sud
Centre du Canada
Inde centrale
USA Centre
USA Est
France Centre
Allemagne Centre-Ouest
Japon Est
Centre de la Corée
Europe Nord
Norvège Est
Qatar Central
USA Centre Sud
Asie Sud-Est
Sud du Royaume-Uni
Europe Ouest
USA Ouest 2
USA Ouest 3

Récupération d’urgence inter-région

Il peut arriver à de rares occasions qu’un centre de données connaisse une interruption prolongée en raison de pannes d’alimentation ou d’autres défaillances impliquant des biens physiques. Ces événements se produisent rarement et la fonction de haute disponibilité intra-région décrite précédemment ne peut pas toujours s’appliquer dans ces situations. IoT Hub propose plusieurs solutions de récupération face à ce type d’interruption prolongée.

Les clients disposent de deux options de récupération dans une telle situation : le basculement initié par Microsoft et le basculement manuel. La différence fondamentale entre les deux est que, dans la première option, Microsoft intervient, tandis que l’utilisateur déclenche lui-même le basculement dans la deuxième option. Le basculement manuel garantit également un objectif de temps de récupération (RTO) inférieur à celui de l’option de basculement initié par Microsoft. Les RTO spécifiques offerts pour chaque option sont décrits dans les sections suivantes. Lorsqu’une de ces options de basculement d’un IoT hub à partir de sa région primaire est utilisée, le hub devient entièrement fonctionnel dans la région Azure qui lui est associée géographiquement.

Ces deux options de basculement offrent les objectifs de point de récupération (RPO) suivants :

¹Les messages cloud-à-appareil et les travaux parents ne sont pas récupérés dans le cadre d’un basculement manuel.

Une fois l’opération de basculement terminée pour l’IoT Hub, toutes les opérations exécutées à partir des applications principales et de l’appareil sont supposées continuer de fonctionner sans intervention manuelle. Cela signifie que vos messages appareil-à-cloud continuent de fonctionner et que l’intégralité du registre de l’appareil est intacte. Les événements émis via Event Grid peuvent être utilisés sur les mêmes abonnements configurés précédemment tant que ces abonnements Event Grid restent disponibles. Aucune manipulation supplémentaire n’est requise pour les points de terminaison personnalisés.

Basculement initié par Microsoft

Le basculement initié par Microsoft est déclenché par Microsoft dans de rares situations pour faire basculer tous les hubs IoT entre une région affectée et la région géographiquement associée. Ce processus représente l’option par défaut et ne nécessite aucune intervention de la part de l’utilisateur. Microsoft se réserve le droit de déterminer dans quelles circonstances exercer cette option. Ce mécanisme n’implique pas le consentement de l’utilisateur avant le basculement du hub de l’utilisateur. Le basculement initié par Microsoft est associé à un objectif de temps de récupération (RTO) de 2 à 26 heures.

Ce long RTO s’explique par le fait que Microsoft doit effectuer l’opération de basculement pour le compte de tous les clients affectés dans cette région. Si vous exécutez une solution IoT moins critique capable de supporter un temps d’arrêt d’environ une journée, vous pouvez très bien prendre une dépendance sur cette option pour satisfaire les objectifs généraux de récupération d’urgence pour votre solution IoT. Le temps total nécessaire pour que les opérations de runtime soient totalement opérationnelles après le déclenchement de ce processus est décrit dans la section « Temps de récupération ».

Seuls les utilisateurs qui déploient des hubs IoT dans les régions Brésil Sud et Asie Sud-Est (Singapour) peuvent refuser cette fonctionnalité. Pour plus d’informations, consultez Désactiver la récupération d’urgence.

Basculement manuel

Si vos objectifs de disponibilité ne sont pas satisfaits par le RTO associé à l’option de basculement initié par Microsoft, envisagez d’utiliser un basculement manuel pour déclencher vous-même le processus de basculement. Cette option peut vous assurer un RTO allant de 10 minutes à quelques heures. Le RTO dépend actuellement du nombre d’appareils inscrits sur l’instance IoT Hub en cours de basculement. Pour un hub hébergeant environ 100 000 appareils, vous pouvez vous attendre à un RTO de l’ordre de 15 minutes. Le temps total nécessaire pour que les opérations de runtime soient totalement opérationnelles après le déclenchement de ce processus est décrit dans la section « Temps de récupération ».

L’option de basculement manuel est toujours disponible, que la région primaire rencontre ou non des temps d’arrêt. Par conséquent, vous pouvez potentiellement utiliser cette option pour effectuer des basculements planifiés. Les basculements planifiés peuvent être par exemple utilisés dans le cadre d’exercices de basculement périodiques. Il faut cependant savoir qu’une opération de basculement planifié entraîne l’arrêt du hub pendant la période définie par le RTO pour cette option. Elle s’accompagne également d’une perte de données, telle que définie dans le tableau des RPO ci-dessus. Vous pouvez envisager de configurer une instance IoT Hub de test pour exercer l’option de basculement planifié de manière périodique, afin de gagner confiance en votre capacité à maintenir le bon fonctionnement de vos solutions de bout en bout en cas d’incident réel.

La fonctionnalité de basculement manuel est disponible sans coût supplémentaire pour les hubs IoT créés après le 18 mai 2017.

Pour obtenir des instructions pas à pas, consultez le Tutoriel : Effectuer un basculement manuel pour un hub IoT

Basculement manuel et Event Hubs

Le nom et le point de terminaison compatibles Event Hubs, de même que le point de terminaison Events intégré à IoT Hub, changent après le basculement manuel. Cela est dû au fait que le client Event Hubs n’a pas de visibilité sur les événements IoT Hub. Il en va de même pour d’autres clients basés sur le cloud, tels que Functions et Azure Stream Analytics. Pour récupérer le point de terminaison et le nom, vous pouvez utiliser le portail Azure ou le Kit de développement logiciel (SDK) .NET.

Utiliser le portail

Pour plus d’informations sur l’utilisation du portail pour récupérer le point de terminaison compatible avec Event Hub et le nom compatible avec Event Hub, consultez Se connecter au point de terminaison intégré.

Utiliser le kit de développement logiciel (SDK) .NET

Pour utiliser la chaîne de connexion IoT Hub afin de recapturer le point de terminaison compatible Avec Event Hubs, utilisez un exemple situé à l’adresse https://github.com/Azure/azure-sdk-for-net/tree/main/samples/iothub-connect-to-eventhubs. L’exemple de code utilise la chaîne de connexion pour obtenir le nouveau point de terminaison Event Hubs et rétablir la connexion. Visual Studio doit être installé sur votre machine.

Exécuter des exercices de test

Les exercices de test ne doivent pas être effectués sur des IoT Hubs utilisés dans vos environnements de production.

Ne pas utiliser le basculement manuel pour migrer un hub IoT vers une autre région

Il n’est pas conseillé d’utiliser le basculement manuel comme un mécanisme servant à migrer définitivement votre hub entre les régions Azure associées géographiquement. En supposant que les appareils étaient situés le plus près de la région primaire du hub, la latence des opérations effectuées sur le hub IoT augmente lorsque le hub bascule vers une région secondaire.

Restauration automatique

Vous pouvez effectuer une restauration automatique vers l’ancienne région primaire en déclenchant l’action de basculement une deuxième fois. Si l’opération de basculement d’origine a été effectuée dans le cadre d’une récupération après une panne prolongée dans la région primaire d’origine, il est recommandé de basculer le hub vers l’emplacement d’origine une fois la situation de panne corrigée.

Temps de récupération

Alors que le FQDN (et par conséquent, la chaîne de connexion) de l’instance IoT Hub reste le même après le basculement, l’adresse IP sous-jacente change. Le temps pour que les opérations de runtime exécutées sur votre instance IoT Hub deviennent totalement opérationnelles une fois que le processus de basculement peut être exprimé à l’aide de la fonction suivante :

Temps de récupération = RTO [10 min -2 heures pour un basculement manuel | 2 à 26 heures pour un basculement initié par Microsoft] + délai de propagation DNS + temps nécessaire à l’application cliente pour actualiser l’adresse IP du hub IoT mise en cache.

Désactiver la reprise d’activité

IoT Hub permet le basculement initié par Microsoft et le basculement manuel en répliquant les données dans la région appairée pour chaque hub IoT. Pour certaines régions, vous pouvez éviter la réplication des données en dehors de la région en désactivant la reprise d’activité quand vous créez un hub IoT. Les régions suivantes prennent en charge cette fonctionnalité :

• Brésil Sud ; région appairée, USA Centre Sud.
• Asie Sud-Est (Singapour) ; région appairée, Asie Est (Hong Kong SAR).

Pour désactiver la reprise d’activité dans les régions prises en charge, vérifiez que Reprise d’activité activée est désélectionné quand vous créez votre hub IoT :

Vous pouvez également désactiver la reprise d’activité quand vous créez un hub IoT à l’aide d’un modèle ARM.

La fonctionnalité de basculement n’est pas disponible si vous désactivez la reprise d’activité pour un hub IoT.

Vous pouvez désactiver la reprise d’activité pour éviter la réplication de données en dehors de la région appairée dans les régions Brésil Sud et Asie Sud-Est uniquement quand vous créez un hub IoT. Si vous souhaitez configurer votre hub IoT existant pour désactiver la reprise d’activité, vous devez créer un hub IoT avec la reprise d’activité désactivée et migrer manuellement votre hub IoT existant. Pour obtenir des conseils, consultez Comment effectuer une migration du hub IoT.

Haute disponibilité inter-région

Si vos objectifs de temps d’activité ne sont pas satisfaits par le RTO associé à un basculement initié par Microsoft ou par un basculement manuel, vous devez envisager d’implémenter un mécanisme de basculement automatique inter-région pour chaque appareil. Un traitement complet des topologies de déploiement dans des solutions IoT dépasserait la portée de cet article. L’article traite du modèle de déploiement avec basculement régional pour la récupération haute disponibilité et d’urgence.

Dans un modèle de basculement régional, le backend de solution s’exécute principalement dans un emplacement de centre de données. Un IoT Hub et un backend secondaire sont déployés dans un autre emplacement de centre de données. Si l’IoT Hub de la région primaire subit une panne ou si la connectivité réseau de l’appareil à la région primaire est interrompue, les appareils utilisent un point de terminaison de service secondaire. Vous pouvez améliorer la disponibilité de la solution en implémentant un modèle de basculement inter-régions au lieu de rester au sein d’une seule région.

À un niveau supérieur, pour implémenter un modèle de basculement régional avec IoT Hub, vous devez procéder de la manière suivante :

• Un hub IoT secondaire et une logique de routage des appareils : En cas d’interruption de service dans votre région principale, les appareils doivent commencer à se connecter à votre région secondaire. Étant donné l’état de la plupart des services impliqués, il est courant pour les administrateurs de solution de déclencher le processus de basculement inter-régions. La meilleure façon de communiquer le nouveau point de terminaison aux appareils tout en conservant le contrôle du processus consiste à consulter régulièrement un service de conciergerie pour connaître le point de terminaison actif en cours. Le service de concierge peut être une application web répliquée accessible à l’aide de techniques de redirection DNS (par exemple, l’utilisation d’Azure Traffic Manager).

  Notes

  Le service IoT Hub n’est pas un type de point de terminaison pris en charge dans Azure Traffic Manager. Il est recommandé d’intégrer le service de concierge proposé avec Azure Traffic Manager pour faire en sorte qu’il implémente l’API de sonde d’intégrité du point de terminaison.

• Réplication du registre des identités : Pour être utilisable, le hub IoT secondaire doit contenir toutes les identités des appareils pouvant se connecter à la solution. La solution doit conserver des sauvegardes géo-répliquées d’identités d’appareils et les télécharger dans le hub IoT secondaire avant de basculer le point de terminaison actif des appareils. La fonctionnalité d’exportation des identités d’appareil d’IoT Hub est utile dans ce contexte. Pour plus d’informations, consultezGuide du développeur IoT Hub - Registre des identités.

• Logique de fusion : Quand la région principale redevient disponible, l’ensemble des états et des données qui ont été créés dans le site secondaire doivent être migrés en sens inverse vers la région principale. Ces états et ces données ont essentiellement trait aux identités des appareils et aux métadonnées d’application qui doivent être fusionnées avec l’IoT Hub principal et d’autres magasins propres à l’application dans la région principale.

Pour simplifier cette étape, vous devez utiliser des opérations idempotentes. Des opérations idempotentes minimisent les effets indésirables de la distribution cohérente éventuelle d’événements, et des doublons ou des livraisons d’événements hors d’usage. Par ailleurs, la logique d’application doit être conçue pour tolérer les éventuelles incohérences ou de légers retards. Cette situation peut se produire en raison du temps additionnel que le système prend pour se réparer en fonction des objectifs de points de récupération (RPO).

Choisir la bonne option de haute disponibilité/récupération d’urgence

Voici un résumé des options de haute disponibilité/récupération d’urgence présentées dans cet article et que vous pouvez utiliser comme cadre de référence pour choisir l’option qui convient le mieux à votre solution.

Étapes suivantes

• Qu’est-ce qu’Azure IoT Hub ?
• Démarrage rapide : Envoyer des données de télémétrie à partir d’un appareil IoT Plug-and-Play vers Azure IoT Hub
• Tutoriel : Effectuer un basculement manuel pour un hub IoT