Fonctionnement du basculement (non planifié) géré par le client
Le basculement (non planifié) géré par le client 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. Tous les points de terminaison de service de stockage sont ensuite redirigés vers la 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 (non planifié) géré par le client et de la restauration automatique.
Important
Le basculement géré par le client (non planifié) pour les comptes dans lesquels Azure Data Lake Storage Gen2 est activé est actuellement en PRÉVERSION et est pris en charge dans toutes les régions GRS/GZRS publiques.
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é.
Important
Le basculement géré par le client (non planifié) pour les comptes utilisant SFTP (protocole FTP sécurisé avec SSH) est actuellement en PRÉVERSION et pris en charge uniquement 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 non planifié et la restauration automatique
Conseil
Pour comprendre les différents états de redondance et leurs définitions pendant le basculement non planifié et le processus de restauration automatique en détail, consultez Redondance de stockage Azure.
Lorsqu’un compte de stockage est configuré pour la redondance de stockage géoredondant (GRS) ou de stockage géoredondant en lecture (RA-GRS), les données sont répliquées trois fois dans les régions primaires et secondaires du stockage localement redondant (LRS). Lorsqu’un compte de stockage est configuré pour la réplication de stockage géoredondant interzone (GZRS) ou de stockage géoredondant interzone avec accès en lecture (RA-GZRS), les données sont redondantes interzone dans la région primaire du stockage redondant interzone (ZRS) et répliquées trois fois dans la région secondaire LRS. Si l’accès en lecture (RA) est configuré pour le compte, 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.
Pendant le processus de basculement géré par le client (non planifié), les entrées DNS (Domain Name System) pour les points 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. 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 nouvelle région primaire. À ce stade, votre compte de stockage devient localement redondant et utilise le stockage localement redondant (LRS).
Les configurations de redondance originales et actuelles sont stockées dans les propriétés du compte de stockage. Cette fonctionnalité vous permet de revenir à votre configuration d’origine en cas d’échec. Pour obtenir la liste complète des configurations de redondance résultantes, lisez Planification de la récupération d’urgence et basculement.
Pour récupérer la géoredondance après un basculement, vous devez reconfigurer votre compte en tant que GRS. 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 l’accès en lecture à la région secondaire pour votre compte de stockage, cet accès est disponible. Toutefois, la réplication de la région primaire vers la région secondaire peut prendre un certain temps.
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. Pour évaluer les éventuelles pertes de données, comparez la dernière heure de synchronisation aux dernières heures où ces données ont été écrites dans la nouvelle région primaire.
Le processus de restauration automatique est essentiellement le même que le processus de basculement, sauf que la configuration de réplication est restaurée à son état d’origine avant le basculement.
Après la restauration automatique, vous pouvez reconfigurer votre compte de stockage pour bénéficier de la géoredondance. Si la région primaire d’origine était configurée comme ZRS, vous pouvez la configurer sur GZRS ou RA-GZRS. Pour d’autres options, consultez Modifier la manière dont un compte de stockage est répliqué.
Comment lancer un basculement non planifié
Pour apprendre à lancer un basculement non planifié, consultez Lancer un basculement de compte.
Attention
Le basculement non planifié 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 de lancer ce type de basculement.
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 non planifié et de restauration automatique
Cette section récapitule le processus de basculement d’un basculement (non planifié) géré par le client.
Résumé de la transition de basculement non planifié
Après un basculement géré par le client (non planifié) :
- 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 (non planifié) 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 1 | LRS | GRS 1 |
| GZRS | LRS | GRS 1 | ZRS | GZRS 1 |
1 La géoredondance est perdue pendant un basculement (non planifié) géré par le client et doit être reconfigurée manuellement.
Détails de la transition de basculement non planifié
Les diagrammes suivants illustrent le processus de basculement et de restauration automatique géré par le client (non planifié) pour 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.
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), une perte de données doit être attendue est donc à prévoir. L’illustration suivante montre le scénario dans lequel les points de terminaison principaux deviennent indisponibles, mais avant la récupération :
Le processus de basculement non planifié (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 comme ici :
Le basculement (non planifié) 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 pour qu’il utilise le GRS, Azure commence à copier vos données de manière asynchrone dans la nouvelle région secondaire (1), comme le montre cette illustration :
L’accès en lecture à la nouvelle région secondaire n’est à nouveau disponible que lorsque le problème empêchant la résolution de la panne d’origine est résolu.
Le processus de restauration automatique non planifiée (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.
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.
Une fois le problème à l’origine de la panne résolu, vous pouvez lancer la restauration automatique vers la région primaire d’origine. Ce processus est décrit dans l’illustration suivante :
- La région primaire actuelle est en lecture seule.
- Avec le basculement et la restauration automatique initiés par le client, la réplication de vos données vers la région secondaire n’est pas autorisée 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 de service de stockage échangées. Les points de terminaison dans la région secondaire deviennent les nouveaux points de terminaison de région primaire 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 :
Pour reprendre la réplication vers la région secondaire d’origine, 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 la reconfiguration du compte comme GRS, la réplication vers la région secondaire d’origine reprend comme le montre cette illustration :
