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.
Cet article décrit la prise en charge de la fiabilité dans Azure Storage Actions, et couvre la résilience intra-régionale avec zones de disponibilité et reprise d’activité et continuité d’activité entre régions. Pour obtenir une vue d’ensemble plus détaillée de la fiabilité dans Azure, consultez Fiabilité d’Azure.
Azure Storage Actions est une infrastructure serverless que vous pouvez utiliser pour effectuer des opérations de données courantes sur des millions d’objets parmi plusieurs comptes de stockage. Le service lui-même est régional, n’a pas de références SKU, et ne prend pas en charge les zones de disponibilité. Toutefois, le plan de contrôle du service prend automatiquement en charge la redondance interzone. Le plan de données peut également prendre en charge la redondance selon que le compte de stockage s’exécute ou non sur une configuration redondante interzone.
Prise en charge des zones 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.
Bien que le service Azure Storage Actions soit régional et n’offre pas de références SKU ni de zones de disponibilité, la redondance de zone est disponible à partir du plan de contrôle et de manière conditionnelle à partir du plan de données :
Le plan de contrôle du service est redondant interzone. Lorsqu’une zone est en panne dans une région, le plan de contrôle continue d’être disponible. Dans un scénario de zone en panne, vous pouvez continuer à gérer la définition et l’affectation des tâches.
Le plan de données (exécution de l’affectation de tâche) hérite des propriétés zonales du compte de stockage parent. Si le compte de stockage est déployé dans une zone en panne, le compte devient indisponible et du point de vue du client, le plan de données n’est pas disponible. Si le compte de stockage est redondant interzone, le compte reste disponible, et le service continue d’effectuer l’opération sur le compte.
Expérience en cas de panne de zone
Dans un scénario de zone en panne, le service Storage Action continue d’être disponible. La progression des tâches dépend de la prise en charge par la zone de disponibilité des comptes de stockage sur lesquels elles s’exécutent. Si le compte n’est pas affecté par la zone en panne, les tâches continuent de progresser. Sinon, les tâches échouent.
Préparation aux pannes de zone et récupération
Le service Storage Action n’est pas zonal, mais le compte de stockage l’est. Si le compte de stockage est affecté par une panne de zone, les tâches de stockage affectées au compte échouent. Une fois la zone et le compte de stockage disponibles, les tâches planifiées continuent d’être exécutées selon la planification. Si la tâche est configurée pour s’exécuter une seule fois, vous devrez peut-être planifier la réexécution de la tâche.
Reprise d’activité et continuité d’activité entre régions
La reprise après sinistre (DR) fait référence aux pratiques utilisées par les organisations pour se remettre d’événements à fort impact, tels que des catastrophes naturelles ou des déploiements échoués qui entraînent des temps d’arrêt et des pertes de données. Quelle que soit la cause, la meilleure solution pour une catastrophe est un plan de récupération d’urgence bien défini et testé, et une conception d’application qui prend activement en charge la récupération d’urgence. Avant de commencer à créer votre plan de reprise après sinistre, consultez Recommandations pour la conception d'une stratégie de reprise après sinistre.
Pour la récupération d’urgence, Microsoft utilise le modèle de responsabilité partagée. Dans ce modèle, Microsoft garantit que l’infrastructure de base et les services de plateforme sont disponibles. Cependant, de nombreux services Azure ne répliquent pas automatiquement les données ou ne reviennent pas d’une région défaillante pour effectuer une réplication croisée vers une autre région activée. Pour ces services, vous êtes responsable de la configuration d’un plan de récupération d’urgence qui fonctionne pour votre charge de travail. La plupart des services qui s’exécutent sur des offres PaaS (Platform as a Service) Azure fournissent des fonctionnalités et des instructions pour la prise en charge de la récupération d’urgence. Vous pouvez utiliser des fonctionnalités spécifiques au service pour prendre en charge une récupération rapide afin de vous aider à développer votre plan de reprise après sinistre.
Les comptes de stockage avec GRS et GZRS répliquent les données dans une région secondaire en cas de basculement de compte de stockage. La continuité d’activité des actions de stockage dépend considérablement de la configuration de redondance du compte de stockage cible. Les comptes de stockage configurés avec la géoredondance bénéficient d’un processus de basculement automatisé. Cette gestion automatique garantit que les futures itérations d’attribution de tâches, qu’elles soient uniques ou récurrentes, s’exécutent dans la région secondaire sans problème. Toutefois, les tâches de stockage en cours au moment du basculement peuvent rencontrer des échecs. Les nouvelles tâches de stockage et les affectations de tâches de stockage continuent de fonctionner comme prévu.
La surveillance cohérente du compte de stockage est cruciale. Avec un basculement, vous devez examiner soigneusement les rapports et la surveillance des tâches pour vérifier la réussite de toutes les opérations d’objet blob et identifier les différences qui nécessitent une attention particulière.
Détection, notification et gestion des pannes
Les tâches de stockage n’envoient aucune notification en cas de panne dans le service lui-même. Il est important de vérifier l’état de la tâche de stockage, et de réessayer les tâches après la récupération du service/de la région.