Récupération d’urgence et basculement pour Azure Files
Microsoft s’efforce de faire en sorte que les services Azure soient toujours disponibles. Toutefois, des interruptions de service non planifiées peuvent se produire et vous devez disposer d’un plan de récupération d’urgence (DR) en place pour gérer une panne de service régionale. Une partie importante du plan de reprise d’activité consiste à préparer le basculement vers le point de terminaison secondaire, au cas où le point de terminaison principal deviendrait indisponible. Cet article décrit les concepts et processus impliqués dans la récupération d’urgence et le basculement de compte de stockage.
Important
Azure File Sync prend en charge le basculement du compte de stockage seulement si le service de synchronisation de stockage est également basculé. Cela est dû au fait qu’Azure File Sync nécessite que le compte de stockage et le service de synchronisation de stockage se situent dans la même région Azure. Si seul le compte de stockage est basculé, les opérations de hiérarchisation cloud et de synchronisation du cloud échouent jusqu’à ce que le service de synchronisation de stockage soit basculé dans la région secondaire. Si vous souhaitez basculer un compte de stockage contenant des partages de fichiers Azure utilisés comme points de terminaison cloud dans Azure File Sync, consultez les meilleures pratiques de récupération d’urgence Azure File Sync et la récupération du serveur Azure File Sync.
Basculement planifié géré par le client (préversion)
Le basculement planifié géré par le client peut également être utilisé dans plusieurs scénarios, notamment les tests de récupération d’urgence planifiés, une approche proactive des sinistres à grande échelle ou pour récupérer de pannes non liées au stockage.
Pendant le processus de basculement planifié, les régions primaires et secondaires sont échangées. La région primaire d’origine perd son rôle et devient la nouvelle région secondaire. En même temps, la région secondaire d’origine est promue et devient la nouvelle région primaire. Une fois le basculement terminé, les utilisateurs peuvent continuer à accéder aux données dans la nouvelle région primaire et les administrateurs peuvent valider leur plan de récupération d’urgence. Le compte de stockage doit être disponible dans la région primaire et la région secondaire avant de pouvoir lancer un basculement planifié.
Pendant la procédure de basculement planifié et de restauration automatique, aucune perte de données n’est attendue tant que les régions primaires et secondaires sont disponibles tout au long du processus. Pour plus d’informations, consultez la section Anticiper la perte de données et les incohérences.
Pour comprendre l’effet de ce type de basculement sur vos utilisateurs et applications, il est utile de savoir ce qui se passe lors de chaque étape du processus de basculement planifié et de restauration automatique. Pour plus d’informations sur le fonctionnement du processus, consultez Fonctionnement du basculement géré par le client (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.
Métriques et coûts de récupération
Pour formuler une stratégie de récupération d’urgence efficace, une organisation doit comprendre :
- La quantité de données qu’il peut se permettre de perdre en cas de perturbation (objectif de point de récupération ou RPO)
- La rapidité avec laquelle il doit être en mesure de restaurer des fonctions et des données métier (objectif de délai de récupération ou RTO)
Le coût de récupération d’urgence augmente généralement avec un RPO/RTO inférieur ou nul. Les entreprises qui doivent être opérationnelles en quelques secondes après un sinistre et qui ne peuvent supporter aucune perte de données paieront plus pour la récupération d’urgence, tandis que celles qui ont des numéros RPO/RTO plus élevés paieront moins cher. Azure fournit des solutions qui peuvent fonctionner avec diverses exigences en matière de RPO et de RTO.
Choisir l’option de redondance appropriée
Azure Files offre différentes options de redondance pour protéger vos données contre les événements planifiés et non planifiés, allant des défaillances matérielles temporaires, des pannes de réseau et d’alimentation, aux catastrophes naturelles. Tous les partages de fichiers Azure peuvent utiliser un stockage localement redondant (LRS) ou redondant interzone (ZRS). Pour plus d’informations, consultez Redondance d’Azure Files.
Azure Files prend en charge le basculement de compte pour les comptes de stockage standard configurés avec le stockage géoredondant (GRS) et le stockage géoredondant interzone (GZRS) pour la protection contre les pannes régionales. Avec le basculement de compte, vous pouvez lancer le processus de basculement pour votre compte de stockage si le point de terminaison principal devient indisponible. Le basculement met à jour le point de terminaison secondaire pour qu’il devienne le point de terminaison principal pour votre compte de stockage. Une fois le basculement terminé, les clients peuvent commencer à écrire dans le nouveau point de terminaison principal.
GRS et GZRS présentent toujours un risque de perte de données, car les données sont copiées dans la région secondaire de manière asynchrone, ce qui signifie qu’il y a un délai avant qu’une écriture dans la région primaire soit copiée dans la région secondaire. En cas de panne, les opérations d’écriture sur le point de terminaison principal qui n’ont pas encore été copiées vers le point de terminaison secondaire seront perdues. Cela veut dire qu’une défaillance touchant la région primaire peut entraîner une perte de données si cette région ne peut pas être récupérée. L’intervalle entre les écritures les plus récentes dans la région principale et la dernière écriture dans la région secondaire est appelé objectif de point de récupération (RPO). Azure Files présente généralement un objectif de point de récupération (RPO) de 15 minutes ou moins, même s’il n’existe pas actuellement de contrat de niveau de service pour la durée de réplication des données dans la région secondaire.
Important
GRS/GZRS ne sont pas pris en charge pour les partages de fichiers Azure premium. Toutefois, vous pouvez synchroniser deux partages de fichiers Azure pour obtenir une redondance géographique.
Concevoir pour la haute disponibilité
Il est important de concevoir votre application à des fins de haute disponibilité dès le départ. Pour obtenir des conseils sur la conception de votre application et la planification de la reprise d’activité, consultez ces ressources Azure :
- Conception d’applications résilientes pour Azure : vue d’ensemble des concepts clés de l’architecture des applications hautement disponibles dans Azure.
- Liste de vérification de résilience : liste de contrôle pour vérifier que votre application implémente les bonnes pratiques de conception pour la haute disponibilité.
- Utilisez la géoredondance pour concevoir des applications hautement disponibles : guide de conception pour créer des applications tirant parti du stockage géoredondant pour les partages de fichiers SMB.
Nous vous recommandons également de concevoir votre application pour l’éventualité d’échecs d’écriture. Votre application doit exposer les échecs d’écriture d’une manière qui vous avertit de la possibilité d’une panne dans la région primaire.
En guise de bonne pratique, concevez votre application afin de pouvoir utiliser la propriété Dernière heure de synchronisation pour évaluer la perte de données attendue. Par exemple, si vous enregistrez dans le journal toutes les opérations d’écriture, vous pouvez comparer l’heure de vos dernières opérations d’écriture à la dernière heure de synchronisation pour identifier les écritures qui n’ont pas été synchronisées dans la région secondaire.
Effectuer le suivi des pannes
Vous pouvez vous abonner au tableau de bord Azure Service Health pour effectuer le suivi de l’intégrité et de l’état d’Azure Files et d’autres services Azure.
Comprendre le processus de basculement de compte
Le basculement de compte géré par le client vous permet de basculer votre compte de stockage entier vers la région secondaire si la région primaire devient indisponible pour une raison quelconque. Quand vous forcez un basculement vers la région secondaire, les clients peuvent commencer à écrire des données sur le point de terminaison secondaire une fois le basculement terminé. Le basculement prend généralement environ une heure. Nous vous recommandons la suspension de votre charge de travail autant que possible avant le basculement de compte.
Pour apprendre à lancer un basculement de compte, consultez Lancer un basculement de compte.
Fonctionnement d’un basculement de compte
Dans des circonstances normales, un client écrit des données dans un compte de stockage dans la région primaire, et ces données sont copiées de manière asynchrone vers la région secondaire. L’illustration suivante montre le scénario quand la région primaire est disponible :
Si le point de terminaison principal devient indisponible pour une raison quelconque, le client ne peut plus écrire dans le compte de stockage. L’illustration suivante montre le scénario dans lequel la région primaire n’est plus disponible, mais aucune reprise n’a encore été effectuée :
Le client lance le basculement de compte vers le point de terminaison secondaire. Le processus de basculement met à jour l’entrée DNS fournie par Stockage Azure afin que le point de terminaison secondaire devienne le nouveau point de terminaison principal pour votre compte de stockage, comme illustré dans l’image suivante :
L’accès en écriture est restauré pour les comptes géoredondants une fois que l’entrée DNS a été mise à jour et que les requêtes sont dirigées vers le nouveau point de terminaison principal. Les points de terminaison de service de stockage existants restent les mêmes après le basculement. Les handles et les baux de fichiers ne sont pas conservés lors du basculement, ainsi les clients doivent démonter et remonter les partages de fichiers.
Important
Une fois le basculement terminé, le compte de stockage est configuré pour être localement redondant dans le nouveau point de terminaison/la nouvelle région principale. Pour reprendre la réplication vers la nouvelle région secondaire, configurez à nouveau le compte pour la géoredondance.
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.
Anticiper la perte de données
Attention
Un basculement de compte entraîne généralement une certaine perte de données. Il est important de bien comprendre les implications d’un basculement de compte.
Étant donné que les données sont écrites de manière asynchrone de la région primaire vers la région secondaire, si la région primaire devient indisponible, les écritures les plus récentes n’ont peut-être pas encore été copiées dans la région secondaire.
Lorsque vous forcez un basculement, toutes les données de la région primaire sont perdues, car la région secondaire devient la nouvelle région primaire. La nouvelle région primaire est configurée pour être redondante localement après le basculement.
Toutes les données déjà copiées vers la région secondaire sont conservées quand le basculement se produit. En revanche, les données écrites dans la région primaire mais qui n’ont pas encore été copiées vers la région secondaire seront définitivement perdues.
Vérifier la propriété Heure de la dernière synchronisation
La propriété Dernière heure de synchronisation (LST) indique l’heure la plus récente à laquelle il est garanti que les données de la région primaire ont été écrites dans la région secondaire. Toutes les données écrites avant la dernière heure de synchronisation sont disponibles dans la région secondaire. Quant aux données écrites après la dernière heure de synchronisation, il y a un risque qu’elles n’aient pas été écrites dans la région secondaire et qu’elles soient perdues. Utilisez cette propriété en cas de panne pour estimer la perte de données que peut entraîner un basculement de compte.
Pour garantir la cohérence des partages de fichiers en cas de basculement, un instantané système est créé dans la région primaire toutes les 15 minutes et répliqué dans la région secondaire. Quand un basculement se produit dans la région secondaire, l’état du partage est basé sur le dernier instantané système dans la région secondaire. Si une défaillance se produit dans la région primaire, la région secondaire sera probablement en retard par rapport à la région primaire, car toutes les écritures dans la région primaire n’auront pas encore été répliquées dans la région secondaire. En raison du décalage géographique ou d’autres problèmes, le dernier instantané système dans la région secondaire peut avoir plus de 15 minutes d’antériorité.
Toutes les opérations d’écriture dans la région primaire qui se sont produites avant la dernière heure de synchronisation ont été répliquées avec succès dans la région secondaire, ce qui signifie qu’elles peuvent être lues à partir de la région secondaire. Toutes les opérations d’écriture dans la région principale postérieures à la dernière heure de synchronisation peuvent avoir été répliquées ou non dans la région secondaire, ce qui signifie qu’elles peuvent ne pas être disponibles pour les opérations de lecture.
Vous pouvez interroger la valeur de la propriété Dernière heure de synchronisation en utilisant Azure PowerShell, Azure CLI ou la bibliothèque de client. La propriété Heure de la dernière synchronisation correspond à une valeur de date/heure GMT. Pour plus d’informations, voir Vérifier la propriété Heure de la dernière synchronisation pour un compte de stockage.
Faire attention lors de la restauration automatique vers la région primaire
Comme mentionné plus tôt, le basculement de la région primaire vers la région secondaire, votre compte de stockage est configuré pour être localement redondant dans la nouvelle région primaire. Vous pouvez ensuite configurer le compte pour la géo-redondance dans la nouvelle région primaire. Quand le compte est configuré pour la géo-redondance après un basculement, la nouvelle région primaire commence immédiatement la copie des données vers la nouvelle région secondaire, qui était la région primaire avant le basculement d’origine. Toutefois, il peut s’écouler un certain temps avant que les données existantes dans la nouvelle région principale soient entièrement copiées vers la nouvelle région secondaire.
Une fois le compte de stockage reconfiguré pour la géo-redondance, il est possible de lancer une restauration automatique de la nouvelle région primaire vers la nouvelle région secondaire. Dans ce cas, la région primaire d’origine avant le basculement redevient la région primaire, et elle est configurée pour être redondante localement ou redondante dans une zone, selon que la configuration de la région primaire d’origine était de type GRS ou GZRS. Toutes les données dans la région primaire post-basculement (la région secondaire d’origine) sont perdues durant la restauration automatique. Si la plupart des données dans le compte de stockage n’ont pas été copiées vers la nouvelle région secondaire avant la restauration automatique, vous risquez de subir une perte de données majeure.
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 attendue.
Après une opération de restauration automatique, vous pouvez configurer la nouvelle région primaire de manière à ce qu’elle soit à nouveau géo-redondante. Si la région primaire d’origine était configurée sur LRS, vous pouvez la configurer sur GRS. Si la région primaire d’origine était configurée sur ZRS, vous pouvez la configurer sur GZRS. Pour des options supplémentaires, consultez Modifier la manière dont un compte de stockage est répliqué.
Initier un basculement de compte
Vous pouvez lancer un basculement de compte à partir du portail Azure, de PowerShell, d’Azure CLI ou de l’API du fournisseur de ressources Stockage Azure. Pour plus d’informations sur la façon de lancer un basculement, consultez Lancer un basculement de compte.
Basculement géré par Microsoft
Dans des circonstances extrêmes où une région est perdue suite à un sinistre majeur, Microsoft peut lancer un basculement régional. Dans ce cas, aucune action n’est requise de votre part. Tant que le basculement géré par Microsoft ne sera pas terminé, vous n’aurez pas d’accès en écriture à votre compte de stockage.