Note
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de changer d’annuaire.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de changer d’annuaire.
Azure Device Registry stocke des informations sur les ressources et les appareils dans le cloud. Device Registry projette des ressources en tant que ressources Azure dans le cloud au sein d’un registre unique. Le registre unique est une source de vérité pour les métadonnées des appareils et des ressources, ainsi que pour les fonctionnalités de gestion des ressources. Device Registry peut être utilisé conjointement avec Les opérations Azure IoT.
Lorsque vous utilisez Azure, la fiabilité est une responsabilité partagée. Microsoft fournit une gamme de fonctionnalités pour prendre en charge la résilience et la récupération. Vous êtes responsable de comprendre le fonctionnement de ces fonctionnalités dans tous les services que vous utilisez et de sélectionner les fonctionnalités dont vous avez besoin pour atteindre vos objectifs métier et vos objectifs de temps d’activité.
Cet article explique comment rendre Device Registry résilient à diverses pannes et problèmes potentiels, notamment les pannes temporaires, les pannes de zone de disponibilité et les pannes de région.
Note
Les opérations Azure IoT incluent différents autres composants au-delà de Device Registry. Pour plus d’informations sur la haute disponibilité et les fonctionnalités de perte de données des composants Opérations Azure IoT, reportez-vous aux Questions fréquentes (FAQ) sur Opérations Azure IoT.
Résilience aux 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 puissent gérer 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, consultez Recommandations pour la gestion des erreurs temporaires.
Les clients interagissent avec Device Registry à l’aide d’Azure Resource Manager. En règle générale, vous utilisez le portail Azure, Azure CLI ou les Kits de développement logiciel (SDK) Azure pour interagir avec les ressources Device Registry, et ces outils fournissent une gestion automatique des erreurs temporaires. Si vous utilisez directement les API Resource Manager, veillez à gérer les erreurs temporaires.
Résilience aux échecs de zone de disponibilité
Les zones de disponibilité sont des groupes physiquement distincts de centres de données au sein d’une région Azure. Lorsqu'une zone tombe en panne, les services peuvent basculer vers l'une des zones restantes.
Azure Device Registry est redondant interzone par défaut, ce qui signifie qu’il réplique automatiquement vos données dans plusieurs zones de disponibilité. Cette configuration améliore la résilience du service en fournissant une haute disponibilité. En cas de défaillance dans une zone, le service peut continuer à fonctionner en toute transparence à partir d’une autre zone.
Microsoft gère l’installation et la configuration de la redondance de zone dans Registre de Dispositifs Azure. Vous n’avez pas besoin d’effectuer une configuration supplémentaire pour activer cette redondance de zone. Microsoft garantit que le service est configuré pour fournir le niveau de disponibilité et de fiabilité le plus élevé.
Soutien régional
La liste suivante des régions prend en charge les zones de disponibilité dans Device Registry :
| Americas | Europe |
|---|---|
| East US | Allemagne Centre-Ouest |
| USA Est 2 | North Europe |
| West US | West Europe |
| USA Ouest 2 | |
| USA Ouest 3 |
Cost
Il n’existe aucun coût supplémentaire pour utiliser la redondance de zone pour Device Registry.
Configurez la prise en charge des zones de disponibilité
Nouvelles ressources : Lorsque vous créez une ressource Device Registry dans Azure IoT Operations, elle inclut automatiquement la redondance de zone par défaut. Il n’est pas nécessaire d’effectuer une configuration supplémentaire.
Comportement lorsque toutes les zones sont saines
Les informations suivantes décrivent ce qui se passe lorsque vous disposez d’un registre d’appareils redondant interzone et que toutes les zones de disponibilité sont opérationnelles :
Routage du trafic entre les zones : Les demandes sont réparties automatiquement sur chaque zone de disponibilité. Une demande peut accéder à une instance device Registry dans n’importe quelle zone de disponibilité.
Réplication des données entre les zones : Les données d’appareil sont répliquées de manière synchrone entre les zones de disponibilité.
Comportement lors d’une défaillance de zone
Les informations suivantes décrivent ce qui se passe lorsque vous disposez d’un registre d’appareils redondant interzone et qu’une zone de disponibilité subit une panne.
- Détection et réponse : Étant donné que Device Registry détecte et répond automatiquement aux défaillances dans une zone de disponibilité, vous n’avez rien à faire pour lancer un basculement de zone de disponibilité.
- Notification : Microsoft ne vous avertit pas automatiquement lorsqu’une zone est en panne. Toutefois, vous pouvez utiliser Azure Service Health pour comprendre l’intégrité globale du service, y compris les défaillances de zone, et vous pouvez configurer des alertes Service Health pour vous avertir des problèmes.
Demandes actives : Certaines requêtes actives peuvent être supprimées et doivent donc être retentées de la même façon que d’autres erreurs temporaires. Pour vous assurer que votre application est résiliente à toutes les erreurs temporaires, consultez Résilience aux erreurs temporaires.
Perte de données attendue : Une défaillance de zone n’est pas censée entraîner une perte de données.
Temps d’arrêt attendu : Une défaillance de zone ne devrait pas entraîner un temps d’arrêt de vos ressources.
Récupération de la zone
Lorsque la zone de disponibilité récupère, Device Registry restaure automatiquement les opérations dans la zone de disponibilité.
Tester les pannes de zone
La plateforme Device Registry gère le routage du trafic, le basculement et la reprise entre les zones de disponibilité. Vous n’avez pas besoin de lancer quoi que ce soit. Étant donné que cette fonctionnalité est entièrement gérée, vous n’avez pas besoin de valider les processus d’échec de zone de disponibilité.
Résilience aux défaillances à l’échelle de la région
Device Registry est un service à région unique. Si la région devient indisponible, vos ressources Device Registry sont également indisponibles.
Toutefois, les données de votre registre sont répliquées dans la région jumelée. En cas de panne prolongée de région, Microsoft peut choisir de basculer vers la région jumelée. Dans ce cas, votre registre continue d’être disponible dans la région jumelée.
Soutien régional
La réplication et le basculement par défaut sont pris en charge dans toutes les régions dans lesquelles Device Registry est disponible, car toutes ces régions sont jumelées.
Cost
Il n’existe aucun coût supplémentaire pour la réplication ou le basculement des données entre régions.
Configurer une réplication et préparer un basculement
Par défaut, la réplication des données inter-régions est automatiquement configurée lorsque vous créez des ressources dans le Registre de périphériques dans une région avec une paire. Ce processus est une option par défaut et ne nécessite aucune intervention de vous.
Comportement lorsque toutes les régions sont saines
Cette section décrit ce qu’il faut attendre lorsqu’un registre d’appareils 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.
Routage du trafic entre les régions : Dans les opérations normales, le trafic transite uniquement vers la région primaire.
Comportement lors d’une défaillance de région
Cette section décrit ce qu’il faut attendre lorsqu’un registre d’appareils 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 : 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 des ressources du registre des périphériques peut ne pas se produire en même temps que les autres services Azure.
Notification: Les événements d’échec de région peuvent être surveillés via Azure Service Health. Configurez des alertes pour recevoir des notifications de problèmes au niveau de la région.
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 : Les données sont répliquées de manière asynchrone dans la région jumelée. Par conséquent, il faut prévoir une certaine perte de données suite au basculement. Vous pouvez vous attendre à une perte de données inférieure à 15 minutes après un basculement de région.
Temps d’arrêt prévu : Prévoyez un temps d’arrêt d’environ 24 heures entre le moment où la région est perdue et celui où la ressource est disponible dans la région jumelée.
Réacheminement du trafic : Pendant le processus de basculement, Device Registry 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 du registre terminée, toutes les opérations provenant du périphérique et des applications back-end devraient continuer à fonctionner sans intervention manuelle.
Récupération de la région
Lorsque la région primaire récupère, Device Registry restaure automatiquement les opérations dans la région.
Tester les défaillances régionales
La plateforme Device Registry gère le routage du trafic, le basculement et la reprise entre les régions associées. Vous n’avez pas besoin de lancer quoi que ce soit. Étant donné que cette fonctionnalité est entièrement gérée, vous n’avez pas besoin de valider les processus d’échec de région jumelés.