Partager via

Récupération d’urgence et basculement pour Azure Files

  • Article

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.

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 :

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 :

Diagramme montrant comment les clients écrivent des données dans le compte de stockage dans la région primaire.

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 :

Diagramme montrant que la région primaire n’étant pas disponible, les clients ne peuvent pas écrire de données.

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 :

Diagramme montrant que le client lance le basculement de compte vers le point de terminaison secondaire.

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 Implications importantes du basculement de compte.

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.

Voir aussi