Fonctionnement du basculement du compte de stockage géré par le client

Article
10/24/2023

Le basculement géré par le client des comptes de stockage Azure vous permet de basculer l’intégralité de votre compte de stockage géoredondant vers la région secondaire si les points de terminaison de service de stockage de la région primaire ne sont plus disponibles. Pendant le basculement, la région secondaire d’origine devient la nouvelle région primaire et tous les points de terminaison de service de stockage pour les objets blob, les tables, les files d’attente et les fichiers sont redirigés vers cette nouvelle région primaire. Une fois la panne du point de terminaison de service de stockage résolue, vous pouvez effectuer une autre opération de basculement pour restaurer vers la région primaire d’origine.

Cet article décrit les différentes étapes du basculement et de la restauration automatique d’un compte de stockage géré par le client.

Important

Le basculement de compte géré par le client pour les comptes qui ont un espace de noms hiérarchique (Azure Data Lake Storage Gen2) est actuellement en préversion et uniquement pris en charge dans les régions suivantes :

(Asie-Pacifique) Inde Centre
(Asie-Pacifique) Asie Sud-Est
(Europe) Europe Nord
(Europe) Suisse Nord
(Europe) Suisse Ouest
(Europe) Europe Ouest
(Amérique du Nord) Canada Centre
(Amérique du Nord) USA Est 2
(Amérique du Nord) USA Centre Sud

Pour vous inscrire à la préversion, consultez Configurer des fonctionnalités d’évaluation dans un abonnement Azure et spécifiez AllowHNSAccountFailover comme nom de fonctionnalité.

Pour connaître les conditions juridiques qui s’appliquent aux fonctionnalités Azure en version bêta, en préversion ou plus généralement non encore en disponibilité générale, consultez l’Avenant aux conditions d’utilisation des préversions de Microsoft Azure.

En cas de sinistre important affectant la région primaire, Microsoft gère le basculement pour les comptes avec espace de noms hiérarchique. Pour plus d’informations, consultez Basculement géré par Microsoft.

Gestion de la redondance pendant le basculement et la restauration automatique

Conseil

Pour comprendre les différents états de redondance et leurs définitions pendant le basculement du compte de stockage et le processus de restauration automatique en détail, consultez Redondance de stockage Azure.

Lorsqu’un compte de stockage est configuré pour la redondance GRS ou RA-GRS, les données sont répliquées trois fois localement dans les régions primaires et secondaires (LRS). Lorsqu’un compte de stockage est configuré pour la réplication GZRS ou RA-GZRS, les données sont redondantes interzone dans la région primaire (ZRS) et répliquées trois fois localement dans la région secondaire (LRS). Si le compte est configuré pour l’accès en lecture (RA), vous pourrez lire des données à partir de la région secondaire tant que les points de terminaison du service de stockage vers cette région sont disponibles.

Lors du processus de basculement géré par le client, les entrées DNS pour les points de terminaison du service de stockage sont modifiées de sorte que celles de la région secondaire deviennent les nouveaux points de terminaison principaux de votre compte de stockage. Après le basculement, la copie de votre compte de stockage dans la région primaire d’origine est supprimée et votre compte de stockage continue d’être répliqué trois fois localement dans la région secondaire d’origine (la nouvelle région primaire). À ce stade, votre compte de stockage devient localement redondant (LRS).

Les configurations de redondance d’origine et actuelles sont stockées dans les propriétés du compte de stockage pour vous permettre d’éventuellement revenir à votre configuration d’origine lorsque vous effectuez une restauration automatique.

Pour récupérer la géoredondance après un basculement, vous devez reconfigurer votre compte en tant que GRS. (GZRS n’est pas une option après le basculement, car la nouvelle région primaire sera LRS après le basculement). Une fois le compte reconfiguré pour la géoredondance, Azure commence immédiatement à copier des données de la nouvelle région primaire vers la nouvelle région secondaire. Si vous configurez votre compte de stockage pour l’accès en lecture (RA) à la région secondaire, cet accès sera disponible, mais il faudra peut-être un certain temps pour que la réplication à partir de la région primaire mette à jour la région secondaire.

Avertissement

Une fois votre compte reconfiguré pour la géoredondance, il peut s’écouler beaucoup de temps avant que les données existantes dans la nouvelle région primaire ne soient entièrement copiées dans la nouvelle région secondaire.

Pour éviter toute perte de données majeure, vérifiez la valeur de la propriété Dernière heure de synchronisation avant de procéder à la restauration automatique. Comparez la dernière heure de synchronisation aux dernières heures où ces données ont été écrites dans la nouvelle région primaire afin d’évaluer la perte de données potentielle.

Le processus de restauration automatique est essentiellement identique au processus de basculement, à l’exception d’Azure qui restaure la configuration de réplication à son état d’origine avant son basculement (la configuration de réplication, et non les données). Par conséquent, si votre compte de stockage a été initialement configuré en tant que GZRS, la région primaire après la restauration automatique devient ZRS.

Après la restauration automatique, vous pouvez configurer votre compte de stockage pour qu’il soit de nouveau géoredondant. Si la région primaire d’origine était configurée sur LRS, vous pouvez la configurer sur GRS ou RA-GRS. Si la région primaire d’origine était configurée comme ZRS, vous pouvez la configurer sur GZRS ou RA-GZRS. Pour des options supplémentaires, consultez Modifier la manière dont un compte de stockage est répliqué.

Comment lancer un basculement

Pour apprendre à lancer un basculement, consultez Lancer un basculement de compte de stockage.

Attention

Le basculement du compte de stockage implique généralement une perte de données, ainsi que des incohérences potentielles de fichiers et de données. Il est important de comprendre l’impact qu’un basculement de compte aurait sur vos données avant d’en lancer un.

Pour plus d’informations sur la perte de données et les incohérences potentielles, consultez Anticiper la perte de données et les incohérences.

Le processus de basculement et de restauration automatique

Cette section récapitule le processus de basculement d’un basculement géré par le client.

Résumé de la transition de basculement

Après un basculement géré par le client :

La région secondaire devient la nouvelle région primaire
La copie des données dans la région primaire d’origine est supprimée
Le compte de stockage est converti en LRS
La géoredondance est perdue

Ce tableau récapitule la configuration de redondance résultante à chaque étape d’un basculement géré par le client et de la restauration automatique :

Original configuration	Après failover	Après réactivation Géoredondance	Après Restauration automatique	Après réactivation Géoredondance
GRS	LRS	GRS ¹	LRS	GRS ¹
GZRS	LRS	GRS ¹	ZRS	GZRS ¹

¹ la géoredondance est perdue pendant un basculement géré par le client et doit être reconfigurée manuellement.

Détails de la transition de basculement

Les diagrammes suivants montrent ce qui se passe pendant le basculement géré par le client et la restauration automatique d’un compte de stockage configuré pour la géoredondance. Les détails de transition pour GZRS et RA-GZRS sont légèrement différents de GRS et RA-GRS.

GRS/RA-GRS
GZRS/RA-GZRS

Opération normale (GRS/RA-GRS)

Dans des circonstances normales, un client écrit des données dans un compte de stockage dans la région primaire via des points de terminaison de service de stockage (1). Les données sont ensuite copiées de manière asynchrone de la région primaire vers la région secondaire (2). L’image suivante montre l’état normal d’un compte de stockage configuré en tant que GRS lorsque les points de terminaison principaux sont disponibles :

Les points de terminaison de service de stockage deviennent indisponibles dans la région primaire (GRS/RA-GRS)

Si le point de terminaison de service de stockage principal devient indisponible pour une raison quelconque (1), le client ne peut plus écrire dans le compte de stockage. Selon la cause sous-jacente de la panne, la réplication vers la région secondaire peut ne plus fonctionner (2), donc une perte de données doit être attendue. L’illustration suivante montre le scénario dans lequel les points de terminaison principaux ne sont plus indisponibles, mais aucune récupération n’a encore été effectuée :

Le processus de basculement (GRS/RA-GRS)

Pour restaurer l’accès en écriture à vos données, vous pouvez lancer un basculement. Les URI de point de terminaison de service de stockage pour les objets blob, les tables, les files d’attente et les fichiers restent identiques, mais leurs entrées DNS sont modifiées pour pointer vers la région secondaire (1) comme le montre cette image :

Le basculement géré par le client prend généralement environ une heure.

Une fois le basculement terminé, la région secondaire d’origine devient la nouvelle région primaire (1) et la copie du compte de stockage dans la région primaire d’origine est supprimée (2). Le compte de stockage est configuré en tant que LRS dans la nouvelle région primaire et n’est plus géoredondant. Les utilisateurs peuvent reprendre l’écriture de données dans le compte de stockage (3) comme illustré dans cette image :

Pour reprendre la réplication vers une nouvelle région secondaire, reconfigurez le compte pour la géoredondance.

Important

N’oubliez pas que la conversion d’un compte de stockage localement redondant pour utiliser la géo-redondance entraîne des coûts et du temps. Pour plus d’informations, consultez Temps et coût d’un basculement.

Après avoir reconfiguré le compte en tant que GRS, Azure commence à copier vos données de manière asynchrone dans la nouvelle région secondaire (1), comme le montre cette image :

L’accès en lecture à la nouvelle région secondaire ne sera pas disponible tant que le problème empêchant la résolution de la panne d’origine n’est pas résolu.

Le processus de restauration automatique (GRS/RA-GRS)

Avertissement

Une fois votre compte reconfiguré pour la géoredondance, il peut s’écouler beaucoup de temps avant que les données de la nouvelle région primaire ne soient entièrement copiées dans la nouvelle région secondaire.

Une fois le problème à l’origine de la panne résolu, vous pouvez lancer un autre basculement pour effectuer une restauration automatique vers la région primaire d’origine, entraînant les résultats suivants :

La région primaire actuelle est en lecture seule.
Avec le basculement et la restauration automatique initiés par le client, vos données ne sont pas autorisées à terminer la réplication vers la région secondaire pendant le processus de restauration automatique. Veillez donc à vérifier la valeur de la propriété Dernière heure de synchronisation avant de procéder à la restauration automatique.
Les entrées DNS pour les points de terminaison du service de stockage sont modifiées de sorte que celles de la région secondaire deviennent les nouveaux points de terminaison principaux de votre compte de stockage.

Une fois la restauration terminée, la région primaire d’origine redevient la région primaire (1) et la copie du compte de stockage dans la région secondaire d’origine est supprimée (2). Le compte de stockage est configuré comme localement redondant dans la région primaire et n’est plus géoredondant. Les utilisateurs peuvent reprendre l’écriture de données dans le compte de stockage (3) comme illustré dans cette image :