Fiabilité dans Azure Storage Actions

Article
06/27/2024

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é interrégion et la continuité d’activité. 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 à travers plusieurs comptes de stockage. Le service lui-même est régional et n’a pas de références SKU ou 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é Azure sont au moins trois groupes physiquement distincts de centres de données dans chaque région Azure. Les centres de données de chaque zone sont équipés d’une infrastructure réseau, de refroidissement et d’alimentation indépendante. En cas de défaillance de zone locale, les zones de disponibilité sont conçues de telle sorte que si une zone est affectée, les services, la capacité et la haute disponibilité de la région sont pris en charge par les deux autres zones.

Les défaillances sont aussi bien des défaillances logicielles et matérielles que des événements de type tremblements de terre, inondations et incendies. La tolérance aux défaillances est obtenue par la redondance et l’isolation logique des services Azure. Pour obtenir des informations détaillées sur les zones de disponibilité dans Azure, consultez Régions et zones de disponibilité.

Les services Azure compatibles avec les zones de disponibilité sont conçus pour fournir le niveau approprié de fiabilité et de flexibilité. Ils peuvent être configurés de deux façons. Un service peut être redondant interzone, avec une réplication automatique entre les zones, ou zonal, avec des instances épinglées à une zone spécifique. Vous pouvez également combiner ces approches. Pour plus d’informations sur l’architecture zonale et redondante interzone, consultez Recommandations relatives à l’utilisation de zones de disponibilité et de régions.

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 l’exécution de la tâche à nouveau.

Récupération d’urgence et continuité d’activité inter-région

La récupération d’urgence (DR) consiste à récupérer après des évènements à fort impact, comme des catastrophes naturelles ou des échecs de déploiements, qui entraînent un temps d’arrêt et une perte de données. Quelle qu’en soit la cause, la meilleure solution en cas de sinistre est d’avoir un plan de DR bien défini et testé, et une conception d’application qui prend activement en charge la DR. Avant de commencer à réfléchir à la création de votre plan de récupération d’urgence, consultez Suggestions pour la conception d’une stratégie de récupération d’urgence.

En ce qui concerne la récupération d’urgence (DR), Microsoft utilise le modèle de responsabilité partagée. Dans un modèle de responsabilité partagée, Microsoft garantit que l’infrastructure de référence et les services de plateforme sont disponibles. En même temps, de nombreux services Azure ne répliquent pas automatiquement les données ou reviennent 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 conseils pour prendre en charge la récupération d’urgence et vous pouvez utiliser fonctionnalités spécifiques au service pour prendre en charge la récupération rapide pour vous aider à développer votre plan de récupération d’urgence.

Storage Action est un service régional et s’exécute sur des comptes dans la même région. Lorsqu’une région est en panne, le compte de stockage et le service sont également inaccessibles. Le service ne prend pas en charge la récupération d’urgence entre les régions. Si vous déclenchez un basculement du compte de stockage vers une autre région, les tâches de stockage ne peuvent pas s’exécuter sur le compte de stockage tant qu’elles ne sont pas rétablies dans la région d’origine. Par conséquent, bien que vous puissiez récupérer le compte de stockage, la tâche de stockage ne pourra pas s’exécuter sur celle-ci.

Important

Si vous migrez votre compte de stockage d’une région primaire GRS ou GZRS vers une région secondaire ou inversement, aucune tâche de stockage qui cible le compte de stockage ne sera déclenchée et les exécutions de tâches existantes peuvent échouer.

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.

Partager via