Fiabilité dans Azure IoT Hub

Cet article décrit la prise en charge de la fiabilité dans Azure IoT Hub. Il couvre la résilience intrarégion via les zones de disponibilité et les déploiements multirégions.

La fiabilité est une responsabilité partagée entre vous et Microsoft. Vous pouvez utiliser ce guide pour déterminer quelles options de fiabilité répondent à vos objectifs métier et objectifs de temps d’activité spécifiques.

Lorsque vous évaluez les options de fiabilité, vous devez également évaluer les compromis entre les éléments suivants :

• Niveau de résilience dont vous avez besoin
• la complexité d’implémentation et de maintenance ;
• Coût de l’implémentation de différentes options

Pour plus d’informations, consultez compromis de fiabilité.

Erreurs temporaires

Les erreurs temporaires sont des défaillances courtes et intermittentes dans les composants. Elles se produisent fréquemment dans un environnement distribué comme le cloud, et font partie intégrante des opérations ordinaires. Les erreurs temporaires se corrigent après une courte période de temps. Il est important que vos applications gèrent les erreurs temporaires, généralement en réessayant les requêtes affectées.

Toutes les applications hébergées dans le cloud doivent suivre les instructions de gestion des erreurs temporaires Azure lorsqu’elles communiquent avec toutes les API, bases de données et autres composants hébergés dans le cloud. Pour plus d’informations, voir Recommandations concernant le traitement des pannes transitoires.

IoT Hub offre une garantie de temps d’activité raisonnablement élevée, mais des défaillances temporaires peuvent se produire dans n’importe quelle plateforme informatique distribuée. Pour gérer les défaillances temporaires, générez les modèles de nouvelle tentative appropriés dans les composants qui interagissent avec les applications cloud.

Prise en charge des zones de disponibilité

Les zones de disponibilité sont des groupes physiquement distincts de centres de données au sein de chaque région Azure. Lorsqu'une zone tombe en panne, les services peuvent basculer vers l'une des zones restantes.

IoT Hub prend en charge deux types distincts de prise en charge des zones de disponibilité :

• Redondance de zone pour les données, qui réplique automatiquement les données entre plusieurs zones de disponibilité pour les composants de stockage sous-jacents qui stockent le registre des identités d’appareil et les messages appareil-à-cloud.

• Redondance de zone pour le calcul, qui fournit une résilience dans les composants responsables de la gestion des appareils et des messages de routage.

Soutien régional

Le type de prise en charge des zones de disponibilité pour votre hub IoT dépend de la région dans laquelle il est déployé.

Région	Redondance de zone pour les données	Redondance de zone pour le calcul
Australie Est
Brésil Sud
Centre du Canada
Inde centrale
Centre des États-Unis
USA Est
France Centrale
Allemagne Centre-Ouest
Japon Est
Corée Centrale
Europe Nord
Norvège Est
Banque Centrale du Qatar
États-Unis - partie centrale méridionale
Asie du Sud-Est
Sud du Royaume-Uni
Europe Ouest
Ouest des États-Unis 2
Ouest des États-Unis 3

Les hubs IoT que vous créez dans des régions qui ne figurent pas dans cette liste ne sont pas résilients aux pannes de zone.

Coûts

Il n’existe aucun coût supplémentaire pour la redondance de zone avec IoT Hub.

Configurez la prise en charge des zones de disponibilité

Les ressources IoT Hub prennent automatiquement en charge la redondance de zone lorsqu’elles sont déployées dans des régions prises en charge. Aucune configuration supplémentaire n'est nécessaire.

Opérations normales

Cette section décrit ce qui doit être attendu lorsque les ressources IoT Hub sont configurées pour la redondance de zone et que toutes les zones de disponibilité sont opérationnelles.

• Réplication des données entre les zones : Lorsque votre ioT Hub est déployé dans une région qui prend en charge la redondance des zones pour les données, les modifications apportées aux données sont répliquées automatiquement entre les zones de disponibilité. La réplication se produit de façon synchrone.

• Routage du trafic entre les zones : Lorsque votre ioT Hub est déployé dans une région qui prend en charge la redondance de zone pour les composants de calcul, les requêtes sont acheminées vers une instance principale du service dans l’une des zones de disponibilité. Azure sélectionne automatiquement l’instance active et la zone.

Expérience en cas de défaillance de zone

Cette section décrit ce qui doit être attendu lorsque les ressources IoT Hub sont configurées pour la redondance de zone et qu’il existe une panne de zone de disponibilité.

• Détection et réponse : Le service IoT Hub est responsable de la détection d’une défaillance dans une zone de disponibilité. Vous n’avez rien à faire pour initier un failover de zone.

• Demandes actives : Lors d’un échec de zone, les requêtes actives peuvent être supprimées. Vos clients et appareils doivent avoir une logique de nouvelle tentative suffisante implémentée pour gérer les erreurs temporaires.

• Perte de données attendue : Lorsque votre ioT Hub est déployé dans une région qui prend en charge la redondance de zone pour les données, une défaillance de zone ne doit pas entraîner de perte de données.

• Temps d’arrêt attendu : Lorsque votre hub IoT est déployé dans une région qui prend en charge la redondance de zone pour les composants de calcul et de données, une défaillance de zone ne doit pas entraîner de temps d’arrêt sur vos ressources IoT Hub.

• Réacheminement du trafic : Lorsque votre ioT Hub est déployé dans une région qui prend en charge la redondance de zone pour les composants de calcul, IoT Hub détecte la perte de la zone. Ensuite, toutes les nouvelles requêtes sont automatiquement redirigées vers une nouvelle instance principale du service dans l’une des zones de disponibilité saines.

Restauration automatique

Lorsque la zone de disponibilité récupère, IoT Hub restaure automatiquement les instances dans la zone de disponibilité et redirige le trafic entre vos instances normalement.

Test des défaillances de zone

Étant donné que IoT Hub gère entièrement le routage du trafic, le basculement et le retour pour les défaillances de zone, vous n’avez pas besoin de valider les processus de gestion des défaillances de zones de disponibilité ni de fournir des informations supplémentaires.

Prise en charge de plusieurs régions

IoT Hub est un service à région unique. Si la région devient indisponible, vos ressources IoT Hub sont également indisponibles.

Toutefois, si vos ressources se trouvent dans une région jumelée, les données de votre hub IoT sont répliquées vers la région jumelée.

Votre hub IoT peut basculer vers la région jumelée dans les scénarios suivants :

• Basculement initié par le client : vous pouvez déclencher un basculement manuel vers la région jumelée, que la région fasse ou non l’expérience d’un temps d’arrêt. Vous pouvez utiliser cette approche pour effectuer des basculements et des exercices planifiés.

• Basculement initié par Microsoft : si une région est perdue, Microsoft peut initier un basculement des hubs IoT vers la région jumelée. Toutefois, il est peu probable que Microsoft initie un basculement, excepté après un délai significatif et dans la mesure du possible. Le basculement des ressources IoT Hub peut s’effectuer à un autre moment que le basculement d’autres services Azure. Ce processus est une option par défaut et ne nécessite aucune intervention de vous.

Si les ressources se trouvent dans une région non jumelée, Microsoft ne réplique pas la configuration et les données entre les régions, et aucun basculement inter-régions n’est intégré. Toutefois, vous pouvez déployer des ressources distinctes dans plusieurs régions. Dans ce cas de figure, il vous incombe de gérer la réplication, la distribution du trafic et le basculement.

Si votre IoT Hub se trouve dans une région non associée ou si le comportement par défaut de réplication et de basculement ne répond pas à vos besoins, vous pouvez utiliser d'autres approches multi-régions pour planifier et lancer des basculements.

Soutien régional

La réplication et le basculement par défaut sont uniquement pris en charge dans les régions jumelées.

Spécifications

La réplication d’une région jumelée et les options de basculement sont disponibles pour tous les niveaux IoT Hub.

Considérations

N’utilisez pas le basculement initié par l'utilisateur pour transférer définitivement votre hub entre les régions associées d'Azure. En règle générale, les appareils se trouvent à proximité de la région principale du hub. Si vous déplacez votre hub vers la région secondaire, la latence augmente pour les opérations entre les appareils et le hub IoT à l’emplacement secondaire.

Coûts

Pour les hubs dans les régions associées, il n'y a pas de coût supplémentaire pour la réplication ou le basculement des données entre régions.

Si votre ioT Hub se trouve dans une région non souhaitée, consultez d’autres approches multirégions pour obtenir des informations sur les coûts possibles.

Configurer une réplication et préparer un basculement

Par défaut, la réplication des données interrégions est automatiquement configurée lorsque vous créez un hub IoT dans une région jumelée. Ce processus est une option par défaut et ne nécessite aucune intervention de vous. Dans les régions à l’exception du Brésil Sud et Sud-Est (Singapour), vos données client ne sont pas stockées ou traitées en dehors de la zone géographique où vous déployez l’instance de service.

Si votre hub IoT se trouve dans les régions Brésil Sud ou Asie Sud-Est (Singapour), vous pouvez désactiver la réplication des données et refuser le basculement. Pour plus d’informations, consultez Désactiver la récupération d’urgence.

Si votre hub IoT se trouve dans une région non jumelée, vous devez planifier votre propre approche de réplication et de basculement inter-régions. Pour plus d’informations, consultez Les autres approches multirégions.

Opérations normales

Cette section décrit ce qu’il faut attendre lorsqu’un hub IoT est configuré pour la réplication et le basculement interrégions, et que la région primaire est opérationnelle.

• Réplication des données entre les régions : Les données sont répliquées automatiquement dans la région jumelée. La réplication s’effectue de manière asynchrone, ce qui signifie que certaines pertes de données sont possibles si un basculement se produit. Il n’y a aucune réplication de données entre régions pour les hubs IoT qui se trouvent dans des régions non jumelées.

• Routage du trafic entre les régions : Dans les opérations normales, le trafic transite uniquement vers la région primaire.

Expérience vers le bas de la région

Cette section décrit ce qu’il faut attendre lorsqu’un hub IoT est configuré pour la réplication et le basculement inter-régions et qu’il existe une panne dans la région primaire.

• Détection et réponse : La responsabilité de détecter et de répondre à une panne dans la région primaire peut varier.

  • Basculement initié par le client : la détection d’une perte de région et la décision du moment auquel effectuer le basculement relèvent de votre responsabilité. Pour plus d’informations sur la façon d’effectuer un basculement initié par le client entre des régions jumelées, consultez Effectuer un basculement manuel pour un hub IoT.

    Des limites existent quant à la fréquence à laquelle vous pouvez effectuer un basculement ou une restauration automatique initiés par le client :

    • Les utilisateurs sont autorisés à effectuer deux opérations de basculement réussies et deux opérations de retour arrière réussies par jour.

    • Des opérations consécutives de basculement ou de restauration automatique ne sont pas autorisées. Vous devez attendre une heure entre ces opérations.

  • Basculement initié par Microsoft : Microsoft peut décider d’effectuer un basculement si la région primaire est perdue. Ce processus peut prendre plusieurs heures après la perte de la région primaire, voire plus longtemps dans certains scénarios. Le basculement de ressources IoT Hub peut ne pas se produire en même temps que d’autres services Azure.

• Demandes actives : Toutes les demandes traitées par la région primaire pendant un basculement sont susceptibles d’être perdues. Les clients doivent réessayer les demandes une fois le basculement terminé.

• Perte de données attendue : Pour les régions jumelées, les données sont répliquées de manière asynchrone vers la région jumelée. Par conséquent, il faut prévoir une certaine perte de données suite au basculement. Ce processus s’applique aux basculements gérés par Microsoft et gérés par le client. Le tableau suivant décrit l’objectif de point de récupération (RPO) ou la perte de données attendue, de chaque type de données que les hubs IoT stockent.

  Type de données	Objectif de point de récupération
  Registre des identités	Perte de données de 0 à 5 minutes
  Données de jumeau d’appareil	Perte de données de 0 à 5 minutes
  Messages cloud-à-appareil 1	Perte de données de 0 à 5 minutes
  Tâches de parent 1 et d’appareil	Perte de données de 0 à 5 minutes
  Messages appareil-à-cloud	Perte de tous les messages non lus
  Messages de rétroaction cloud-à-appareil	Perte de tous les messages non lus

  ¹ Les messages cloud-à-appareil et les tâches de parent ne sont pas récupérés lors d’un basculement initié par le client.

• Période d'arrêt prévue : La période d'arrêt pendant le basculement dans une région dépend du type de basculement.

  • Basculement initié par le client : prévoyez environ 10 minutes à 2 heures de temps d’arrêt entre le moment où la région est perdue et le moment où la ressource devient opérationnelle dans la région jumelée. Le nombre d’appareils inscrits sur l’instance du hub IoT en cours de basculement influence le temps de récupération. Vous pouvez vous attendre à ce que le temps de récupération d’un hub qui héberge environ 100 000 appareils soit d’environ 15 minutes.

  • Basculement initié par Microsoft : prévoyez environ 2 minutes à 26 heures de temps d’arrêt entre le moment où la région est perdue et le moment où la ressource devient disponible dans la région jumelée.

    Le temps de récupération élevé est dû au fait que Microsoft doit effectuer l’opération de basculement au nom de tous les clients concernés de cette région. Pour les systèmes critiques, vous devriez utiliser le basculement initié par le client pour réduire les temps d’arrêt. Toutefois, si vous exécutez une solution IoT moins critique qui peut supporter un temps d’arrêt d’environ un jour, il peut être possible de prendre une dépendance sur l’option lancée par Microsoft pour satisfaire les objectifs globaux de récupération d’urgence de votre solution IoT.

  • Pour les deux types de basculement, le nom de domaine complet de l’instance ioT Hub reste le même après le basculement, ce qui signifie que la chaîne de connexion reste également la même. Toutefois, étant donné que l’adresse IP sous-jacente change, les clients doivent attendre que les enregistrements DNS (Domain Name System) soient mis à jour avant d’accéder au hub IoT après le basculement.

    Important

    Les kits SDK IoT Hub ne mettent pas en cache l’adresse IP du hub IoT. Le code utilisateur interfacant avec les kits SDK ne doit pas non plus mettre en cache l’adresse IP du hub IoT.

    En raison de ces facteurs, le temps d’exécution des opérations d’exécution effectuées sur votre instance IoT Hub pour devenir entièrement opérationnel après le processus de basculement peut être exprimé à l’aide de la fonction suivante :

    Temps de récupération = RTO [10 minutes à 2 heures pour le basculement initié par le client ou 2 à 26 heures pour le basculement initié par Microsoft] + délai de propagation DNS + Heure nécessaire à l’actualisation de l’adresse IP du hub IoT mis en cache

• Réacheminement du trafic : Pendant le processus de basculement, IoT Hub met à jour les enregistrements DNS pour qu’ils pointent vers la région jumelée. Toutes les demandes suivantes sont envoyées à la région jumelée.

  Une fois l’opération de basculement effectuée pour le hub IoT, toutes les opérations de l’appareil et des applications back-end sont censées continuer à fonctionner sans nécessiter d’intervention manuelle. Cette continuité garantit que vos messages appareil-à-cloud continuent de fonctionner et que l’intégralité du registre des appareils est intacte. Si vous émettez des événements via Azure Event Grid, ils peuvent être consommés via les mêmes abonnements que ceux que vous avez configurés précédemment tant que ces abonnements Event Grid continuent d’être disponibles. Aucune autre gestion n’est nécessaire pour les points de terminaison personnalisés.

Configuration post-basculement requise

Selon l’emplacement où vous routez les messages de votre hub IoT, vous devrez peut-être effectuer des étapes supplémentaires une fois le basculement terminé.

• Azure Event Hubs : Le nom et le point de terminaison compatibles avec Event Hubs de votre point de terminaison d’événements intégré au hub IoT changent après le basculement. Cette modification se produit parce que le client Event Hubs n’a pas de visibilité sur les événements IoT Hub.

  Lorsque vous recevez des messages de télémétrie à partir du point de terminaison intégré à l’aide du client Event Hubs ou de l’hôte du processeur d’événements, utilisez la chaîne de connexion du hub IoT pour établir la connexion. Cette approche garantit que vos applications principales continuent de fonctionner sans nécessiter d’intervention manuelle après le basculement.

  Si vous utilisez directement le nom et le point de terminaison compatibles avec Event Hubs dans votre application, vous devez obtenir le nouveau point de terminaison compatible Event Hubs après le basculement pour continuer les opérations. 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 :

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

  • Kit de développement logiciel (SDK) .NET : Pour utiliser la chaîne de connexion IoT Hub pour récupérer le point de terminaison compatible Event Hubs, utilisez l’exemple de code. Cet 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é.

• Azure Functions et Azure Stream Analytics : Si vous utilisez Azure Functions ou Stream Analytics pour vous connecter au point de terminaison d’événements intégré, vous devez mettre à jour le point de terminaison Event Hubs auquel la fonction ou le travail se connecte, en suivant le même processus décrit dans le point de puce précédent. Ensuite, effectuez une action de redémarrage , car tous les décalages de flux d’événements deviennent non valides après le basculement.

• Stockage Azure : Lors du routage vers Stockage Azure, commencez par répertorier les objets blob ou les fichiers. Effectuez ensuite une itération sur eux pour vous assurer que tous les objets blob ou fichiers sont lus sans supposer de partitionnement. La plage de partitions peut potentiellement changer lors d’un basculement initié par Microsoft ou d’un basculement initié par le client. Vous pouvez utiliser l’API List Blobs pour énumérer la liste des objets blob ou l’API List Azure Data Lake Storage pour la liste des fichiers. Pour plus d’informations, consultez Stockage Azure comme point de terminaison de routage.

Restauration automatique

Pour revenir à la région principale, vous pouvez déclencher l’action de basculement une deuxième fois. Il est important de se rappeler des restrictions concernant la fréquence de basculement autorisée.

Si l’opération de basculement d’origine a été effectuée pour récupérer après une panne prolongée dans la région principale d’origine, effectuez la restauration automatique vers la région principale une fois que celle-ci récupère suite à la panne.

Test des défaillances régionales

Pour simuler une défaillance lors d’une interruption de service dans une région, vous pouvez déclencher un basculement manuel de votre hub IoT. Toutefois, étant donné qu’un basculement régional entraîne à la fois un temps d’arrêt et une perte de données, vous devez effectuer des basculements de test uniquement dans des environnements hors production. Pour plus d’informations, découvrez l’Expérience de panne régionale. Envisagez de configurer régulièrement une instance IoT Hub de test pour lancer l’option de basculement planifiée. Les tests périodiques peuvent vous aider à renforcer votre capacité à restaurer et à exploiter efficacement vos solutions de bout en bout lorsqu’un sinistre réel se produit.

Autres approches multirégions

Les fonctionnalités de basculement inter-régions d’IoT Hub ne conviennent pas aux scénarios suivants :

• Votre hub IoT se trouve dans une région non jumelée.

• Vos objectifs de durée de bon fonctionnement des activités ne sont pas satisfaits par le temps de récupération ou la perte de données que fournit l’option de basculement intégrée.

• Vous devez basculer vers une région qui n’est pas jumelée à votre région principale.

Vous pouvez concevoir une solution de basculement interrégionale adaptée à chaque appareil individuel. Un traitement complet des topologies de déploiement dans les solutions IoT est en dehors de l’étendue de cet article, mais vous pouvez envisager un modèle de déploiement multirégion. Dans ce modèle, votre hub IoT principal et votre back-end de solution s’exécutent principalement dans une région Azure. Un hub IoT secondaire et un back-end sont déployés dans une autre région Azure. Si le hub IoT dans la région primaire rencontre 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.

• Temps d’arrêt attendu : Cette approche a moins d’une minute d’arrêt, mais peut être complexe à implémenter.

• Perte de données attendue : La quantité de perte de données dépend des magasins de données spécifiques que vous utilisez et de la façon dont vous configurez la géoréplication entre eux.

• Coût: Cette approche vous oblige à provisionner au moins un hub IoT supplémentaire, ce qui augmente votre coût global.

À un niveau élevé, pour implémenter un modèle de basculement régional avec IoT Hub, vous devez prendre les mesures suivantes :

• Un hub IoT secondaire et une logique de routage des appareils : Si le service de votre région primaire est interrompu, les appareils doivent commencer à se connecter à votre région secondaire. Étant donné la conscience d’état de la plupart des services impliqués, les administrateurs de solution déclenchent souvent de façon manuelle le processus de basculement interrégional. La meilleure manière de communiquer le nouveau point de terminaison aux appareils tout en gardant le contrôle sur le processus est de leur faire vérifier régulièrement un service de conciergerie pour connaître le point de terminaison actif actuel. Le service concierge peut être une application web répliquée et accessible à l’aide de techniques de redirection DNS, telles qu’Azure Traffic Manager.

  Remarque

  Traffic Manager n’a pas de prise en charge intégrée pour IoT Hub. Vous pouvez configurer des points de terminaison Traffic Manager personnalisés pour chaque hub IoT. Configurez la sonde d’intégrité du point de terminaison Traffic Manager pour utiliser le point de terminaison du hub IoT.

• Réplication du Registre des identités : Pour être utilisable, le hub IoT secondaire doit contenir toutes les identités d’appareil qui peuvent se connecter à la solution. La solution doit conserver des sauvegardes géorépliquées des identités des appareils et les charger sur le hub IoT secondaire avant de modifier 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, consultez Comprendre le registre des identités dans votre IoT Hub.

• Logique de fusion : Lorsque la région primaire devient à nouveau disponible, tous les états et données créés dans la région secondaire doivent être migrés vers la région primaire. 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, utilisez des opérations idempotentes . Les 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. En outre, la logique d’application doit être conçue pour tolérer des incohérences potentielles ou un état légèrement obsolète. Ce scénario peut se produire en raison du temps supplémentaire nécessaire au système pour guérir en fonction des RPO.

Sauvegardes

Pour la plupart des solutions, vous ne devez pas vous appuyer exclusivement sur les sauvegardes. Utilisez plutôt les autres fonctionnalités décrites dans ce guide pour prendre en charge vos exigences de résilience. Toutefois, les sauvegardes protègent contre certains risques que d’autres approches ne le font pas. Pour plus d’informations, consultez Redondance, réplication et sauvegarde.

Le service IoT Hub active les opérations d’exportation en bloc, ce qui vous permet d’exporter l’intégralité du registre d’identités d’un hub IoT. Ces données sont transférées vers un conteneur de blob de stockage Azure à l’aide d’une signature d’accès partagé. Cette méthode vous permet de créer des sauvegardes fiables de vos informations d’appareil dans un conteneur d’objets blob que vous contrôlez. Pour plus d’informations, consultez Importer et exporter des identités d’appareil IoT Hub en bloc.

Vous pouvez également exporter le modèle Azure Resource Manager (modèle ARM) d’Un hub IoT existant pour créer une sauvegarde de la configuration du hub IoT. Pour plus d’informations, consultez Migrer manuellement un hub IoT à l’aide d’un modèle ARM.

Contrat de niveau de service

Le contrat de niveau de service (SLA) pour IoT Hub décrit la disponibilité attendue du service et les conditions qui doivent être remplies pour atteindre cette attente de disponibilité. Pour comprendre ces conditions, il est important de passer en revue les contrats SLA pour les services en ligne.

Contenu connexe

• Fiabilité dans Azure
• Scalabilité de solution IoT, haute disponibilité et récupération d’urgence