Fonctionnement du basculement planifié géré par le client (préversion)
Le basculement planifié géré par le client peut être utile dans des scénarios tels que la planification et les tests de récupération d’urgence, la correction proactive des sinistres à grande échelle prévus, et les pannes non liées au stockage.
Pendant le processus de basculement planifié, les régions primaires et secondaires de votre compte de stockage sont échangées. La région primaire d’origine est rétrogradée et devient la nouvelle région secondaire, tandis que la région secondaire d’origine est promue et devient la nouvelle région primaire. Le compte de stockage doit être disponible dans la région primaire et la région secondaire avant de pouvoir lancer un basculement planifié.
Cet article décrit les différentes étapes du basculement planifié géré par le client et de la restauration automatique. Pour comprendre le fonctionnement d’un basculement en raison d’une panne inattendue des points de terminaison de stockage, consultez Fonctionnement du basculement géré par le client (non planifié).
Important
Le basculement planifié géré par le client est actuellement en PRÉVERSION et limité aux régions suivantes :
- France Centre
- France Sud
- Inde Centre
- Inde Ouest
- Asie Est
- Asie Sud-Est
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.
Important
Après un basculement planifié, la valeur Heure de dernière synchronisation d’un compte de stockage peut apparaître obsolète ou signalée comme nulle lorsque les données Azure Files sont présentes.
Des instantanés système sont régulièrement créés dans la région secondaire d’un compte de stockage pour conserver des points de récupération cohérents utilisés pendant le basculement et la restauration automatique. Au lancement d’un basculement planifié géré par le client, la région primaire d’origine devient la nouvelle région secondaire. Dans certains cas, aucun instantané système n’est disponible sur la nouvelle région secondaire une fois le basculement planifié terminé, ce qui fait que la valeur Heure de dernière synchronisation globale du compte apparaît comme étant obsolète ou Null.
Comme les activités utilisateur telles que la création, la modification ou la suppression d’objets peuvent déclencher la création d’instantanés, les comptes sur lequel ces activités se produisent après le basculement planifié ne nécessitent pas d’attention supplémentaire. Toutefois, les comptes qui n’ont pas d’instantanés ou d’activité utilisateur peuvent continuer à afficher une valeur Heure de dernière synchronisation Null jusqu’à ce que la création d’instantanés système soit déclenchée.
Si nécessaire, effectuez une des activités suivantes pour chaque partage au sein d’un compte de stockage afin de déclencher la création d’un instantané. Une fois l’opération terminée, votre compte doit afficher une valeur Heure de dernière synchronisation valide dans un délai de 30 minutes.
- Montez le partage, puis ouvrez n’importe quel fichier pour la lecture.
- Chargez un test ou un exemple de fichier sur le partage.
Gestion de la redondance pendant le basculement planifié et la restauration automatique
Conseil
Pour comprendre les différents états de redondance pendant le processus de basculement géré par le client et de restauration automatique, ainsi que leurs définitions, consultez Redondance de stockage Azure.
Pendant le processus de basculement planifié, les points de terminaison de service de stockage de la région primaire passent en lecture seule alors que les mises à jour restantes terminent la réplication vers la région secondaire. Ensuite, toutes les entrées DNS (Domain Name Service) du point de terminaison de service de stockage sont basculées. Les points de terminaison secondaires de votre compte de stockage deviennent les nouveaux points de terminaison primaires et les points de terminaison primaires d’origine deviennent les nouveaux secondaires. La réplication de données au sein de chaque région reste identique, même si les régions primaires et secondaires sont basculées.
Le processus de restauration automatique planifiée est essentiellement identique au processus de basculement planifié, mais à une exception près. Pendant la restauration automatique planifiée, Azure stocke la configuration de redondance d’origine de votre compte de stockage et restaure celui-ci à son état d’origine lors de la restauration automatique. Par exemple, si votre compte de stockage a initialement été configuré comme GZRS, le compte de stockage devient GZRS après la restauration automatique.
Remarque
Contrairement au basculement géré par le client (non planifié), pendant un basculement planifié, la réplication de la région primaire vers la région secondaire doit être achevée avant que les entrées DNS pour les points de terminaison ne soient remplacées par celles de la nouvelle région secondaire. De ce fait, aucune perte de données n’est attendue pendant un basculement ou une restauration automatique planifiés tant que les régions primaires et secondaires sont disponibles pendant le processus.
Comment lancer un basculement
Pour apprendre à lancer un basculement, consultez Lancer un basculement de compte.
Le processus de basculement et de restauration automatique planifiés
Les diagrammes suivants montrent ce qui se produit pendant le basculement planifié géré par le client et la restauration automatique d’un compte de stockage.
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 :
Le processus de basculement planifié (GRS/RA-GRS)
Commencez des tests de récupération d’urgence en lançant un basculement de votre compte de stockage vers la région secondaire. Les étapes suivantes expliquent le processus de basculement et l’image suivante fournit une illustration :
- La région primaire d’origine passe en lecture seule.
- Une réplication de toutes les données de la région primaire vers la région secondaire s’achève.
- Les entrées DNS pour des points de terminaison de service de stockage sont favorisées et deviennent les nouveaux points de terminaison primaires de votre compte de stockage.
Le basculement prend généralement environ une heure.
Une fois le basculement terminé, la région primaire d’origine devient la nouvelle région secondaire (1), et la région secondaire d’origine devient la nouvelle région primaire (2). Les URI pour les points 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 de façon à pointer vers la nouvelle région primaire (3). Les utilisateurs peuvent reprendre l’écriture de données dans le compte de stockage de la nouvelle région primaire, et les données sont ensuite copiées de manière asynchrone dans la nouvelle région secondaire (4) tel qu’illustré dans l’image suivante :
Pendant l’état de basculement, effectuez vos tests de récupération d’urgence.
Le processus de restauration automatique planifiée (GRS/RA-GRS)
Après la fin des tests, effectuez un autre basculement pour effectuer une restauration automatique vers la région primaire d’origine. Pendant le processus de basculement, tel que montré dans l’image suivante :
- La région primaire d’origine passe en lecture seule.
- Toutes les données terminent la réplication de la région primaire actuelle vers la région secondaire actuelle.
- Les entrées DNS pour les points de terminaison de service de stockage sont modifiées pour pointer vers la région qui était primaire avant l’exécution du basculement initial.
Le basculement prend généralement une heure environ.
Une fois le basculement terminé, le compte de stockage est restauré vers sa configuration de restaurer d’origine. Les utilisateurs peuvent reprendre l’écriture de données dans le compte de stockage de la région primaire d’origine (1) pendant la poursuite de la réplication vers la région secondaire d’origine (2) comme avant le basculement :
