Planification de la récupération d’urgence et basculement du stockage Azure

  • 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. Les principaux composants d’un bon plan de récupération d’urgence contiennent des stratégies pour :

Cet article décrit le basculement pour les comptes de stockage globalement redondants (GRS, GZRS et RA-GZRS), et la conception de vos applications pour qu’elles soient hautement disponible en cas de panne et de basculement ultérieur.

Choisir l’option de redondance appropriée

Stockage Azure conserve plusieurs copies de votre compte de stockage afin de garantir la durabilité et la haute disponibilité. L’option de redondance que vous choisissez pour votre compte dépend du degré de résilience dont vous avez besoin pour vos applications.

Avec le stockage localement redondant (LRS), trois copies de votre compte de stockage sont automatiquement stockées et répliquées dans un seul centre de données. Avec le stockage redondant interzone (ZRS), une copie est stockée et répliquée dans trois zones de disponibilité distinctes au sein de la même région. Pour plus d’informations sur les zones de disponibilité, consultez Zones de disponibilité Azure.

La récupération d’une seule copie d’un compte de stockage se produit automatiquement avec les stockages LRS et ZRS.

Stockage globalement redondant et basculement

Avec un stockage globalement redondant (GRS, GZRS et RA-GZRS), Azure copie vos données de manière asynchrone dans une région géographique secondaire située à au moins des centaines de kilomètres. Cela vous permet de récupérer vos données en cas de panne dans la région primaire. La caractéristique qui distingue le stockage globalement redondant de LRS et ZRS est la possibilité de basculer vers la région secondaire en cas de panne dans la région primaire. Le processus de basculement met à jour les entrées DNS des points de terminaison de votre service de stockage de sorte que les points de terminaison de la région secondaire deviennent les nouveaux points de terminaison primaires de votre compte de stockage. Une fois le basculement terminé, les clients peuvent commencer à écrire dans les nouveaux point de terminaison primaires.

Les configurations de redondance RA-GRS et RA-GZRS fournissent un stockage géoredondant avec l’avantage d’un accès en lecture sur le point de terminaison secondaire en cas de panne dans la région primaire. Si une panne se produit sur le point de terminaison primaire, les applications configurées pour l’accès en lecture sur la région secondaire et conçues pour la haute disponibilité peuvent continuer à lire sur le point de terminaison secondaire. Microsoft recommande un stockage RA-GZRS pour une disponibilité et une durabilité maximales de vos comptes de stockage.

Pour plus d’informations sur la redondance dans Stockage Azure, consultez Redondance de Stockage Azure.

Planifier le basculement du compte de stockage

Les comptes de stockage Azure prennent en charge deux types de basculement :

1Le basculement géré par Microsoft ne peut pas être lancé pour des comptes de stockage, des abonnements ou des locataires individuels. Pour plus d’informations, consultez Basculement géré par Microsoft.
2 Votre plan de récupération d’urgence doit être basé sur le basculement géré par le client. Ne comptez pas sur le basculement géré par Microsoft, car il est utilisé seulement dans des circonstances extrêmes.

Chaque type de basculement a un ensemble unique de cas d’usage, des attentes correspondantes pour la perte de données et une prise en charge des comptes avec un espace de noms hiérarchique activé (Azure Data Lake Storage Gen2). Ce tableau récapitule les aspects de chaque type de basculement :

Type Étendue de basculement Cas d’utilisation Perte de données attendue Espace de noms hiérarchique pris en charge
Gérée par le client Storage account Les points de terminaison du service de stockage pour la région primaire sont indisponibles, mais la région secondaire est disponible.

Vous avez reçu un avis Azure dans lequel Microsoft vous conseille d’effectuer une opération de basculement des comptes de stockage potentiellement affectés par une panne.		 Oui Oui (en préversion)
Microsoft-managed Unité d’échelle ou région entière La région primaire est complètement indisponible en raison d’un sinistre important, mais la région secondaire est disponible. Oui Oui

Basculement géré par le client

Si les points de terminaison de données des services de stockage de votre compte de stockage sont indisponibles dans la région primaire, vous pouvez basculer vers la région secondaire. Une fois le basculement terminé, la région secondaire devient la nouvelle région primaire dans laquelle les utilisateurs peuvent continuer à accéder aux données.

Pour bien comprendre l’impact du basculement de compte géré par le client sur vos utilisateurs et applications, il est utile de savoir ce qui se passe à chaque étape du processus de basculement et de restauration automatique. Pour plus d’informations sur le fonctionnement du processus, consultez Fonctionnement du basculement des comptes de stockage gérés par le client.

Basculement géré par Microsoft

Dans des circonstances extrêmes où la région primaire d’origine est considérée comme irrécupérable dans un délai raisonnable en raison d’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. Vos applications peuvent lire à partir de la région secondaire si votre compte de stockage est configuré pour RA-GRS ou RA-GZRS.

Important

Votre plan de récupération d’urgence doit être basé sur le basculement géré par le client. Ne comptez pas sur le basculement géré par Microsoft, car il est utilisé seulement dans des circonstances extrêmes. Un basculement géré par Microsoft peut être lancé pour une unité physique entière, par exemple, une région ou une unité d’échelle. Il ne peut pas être lancé pour des comptes de stockage, des abonnements ou des locataires individuels. Pour pouvoir basculer de manière sélective vos comptes de stockage individuels, utilisez le basculement de compte géré par le client.

Anticiper la perte de données et les incohérences

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. Dans votre plan de récupération d’urgence, tenez compte de l’impact qu’un basculement de compte peut avoir sur vos données avant d’en lancer un.

Parce que les données sont écrites de façon asynchrone de la région primaire vers la région secondaire, il y a toujours un délai avant qu’une écriture de la région primaire soit copiée dans la région secondaire. Si la région primaire n’est plus disponible, les écritures les plus récentes risquent de ne pas encore avoir été copiées dans la région secondaire.

En cas de basculement, toutes les données de la région primaire sont perdues, car la région secondaire devient la nouvelle région primaire. Toutes les données déjà copiées vers la région secondaire sont conservées quand le basculement se produit. Toutefois, les données écrites dans la région primaire qui n’ont pas encore été copiées dans la région secondaire sont définitivement perdues.

La nouvelle région primaire est configurée pour être redondante localement (LRS) après le basculement.

Vous pouvez également rencontrer des incohérences de fichiers ou de données si vos comptes de stockage ont un ou plusieurs des éléments suivants activés :

Heure de la dernière synchronisation

La propriété Dernière heure de synchronisation 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. Pour les comptes qui ont un espace de noms hiérarchique, la même propriété Dernière heure de synchronisation s'applique également aux métadonnées gérées par l'espace de noms hiérarchique, y compris les ACL. Toutes les données et métadonnées écrites avant la dernière heure de synchronisation sont disponibles sur le secondaire, tandis que les données et métadonnées écrites après la dernière heure de synchronisation peuvent ne pas avoir été écrites sur le secondaire et peuvent être perdues. Utilisez cette propriété en cas de panne pour estimer la perte de données que peut entraîner un basculement de compte.

En guise de bonne pratique, concevez votre application afin de pouvoir utiliser la 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.

Pour plus d’informations sur la vérification de la propriété Heure de la dernière synchronisation, consultez Vérification de la propriété Heure de la dernière synchronisation d’un compte de stockage.

Cohérence des fichiers pour Azure Data Lake Storage Gen2

La réplication des comptes de stockage avec un espace de noms hiérarchique activé (Azure Data Lake Storage Gen2) se produit au niveau du fichier. Cela signifie que si une panne se produit dans la région primaire, il est possible que seuls certains fichiers d’un conteneur ou d’un répertoire aient été correctement répliqués dans la région secondaire. La cohérence de tous les fichiers d’un conteneur ou d’un répertoire après le basculement d’un compte de stockage n’est pas garantie.

Flux de modification et incohérences des données d’objet blob

Le basculement d’un compte de stockage vers un compte de stockage géoredondant avec le flux de modification activé peut entraîner des incohérences entre les journaux du flux de modification et les données et/ou métadonnées de blob. Ces incohérences peuvent être le résultat de la nature asynchrone des mises à jour des journaux des modifications et de la réplication des données d’objet blob de la région primaire vers la région secondaire. Le seul cas où vous pouvez éviter des incohérences est quand tous les enregistrements de journal actuels ont pu être vidés dans les fichiers journaux et que toutes les données de stockage ont pu être répliquées de la région primaire vers la région secondaire.

Pour obtenir plus d’informations sur le fonctionnement du flux de modification, consultez Fonctionnement du flux de modification.

N’oubliez pas que d’autres fonctionnalités de compte de stockage nécessitent l’activation du flux de modification, telles que la Sauvegarde opérationnelle de Stockage Blob Azure, la Réplication d’objets et la Restauration à un instant dans le passé pour des objets blob de blocs.

Incohérences de la restauration à un instant dans le passé

Le basculement géré par le client est pris en charge pour les comptes de stockage de niveau standard v2 à usage général qui incluent des objets blob de blocs. Cependant, l’exécution d’un basculement géré par le client sur un compte de stockage réinitialise le point de restauration le plus ancien possible pour le compte. Les données pour la Restauration à un instant dans le passé pour des objets blob de blocs sont cohérentes uniquement jusqu’à l’heure d’achèvement du basculement. Par conséquent, vous pouvez uniquement restaurer des objets blob de blocs à un point dans le temps qui n’est pas antérieur à l’heure d’achèvement du basculement. Vous pouvez vérifier l’heure d’achèvement du basculement dans l’onglet redondance de votre compte de stockage dans le Portail Azure.

Par exemple, supposons que vous avez définir la période de rétention sur 30 jours. Si plus de 30 jours se sont écoulés depuis le basculement, vous pouvez restaurer le compte à n’importe quel point au cours de ces 30 jours. Toutefois, si moins de 30 jours se sont écoulés depuis le basculement, vous ne pouvez pas restaurer le compte à un point antérieur au basculement, quelle que soit la période de rétention. Par exemple, si 10 jours se sont écoulés depuis le basculement, le point de restauration le plus éloigné possible est 10 jours dans le passé, et non 30 jours dans le passé.

Temps et coût du basculement

La durée entre le début et la fin d’un basculement peut varier, bien que cela prenne généralement moins d’une heure.

Un basculement géré par le client perd sa géoredondance après le basculement (et la restauration automatique). Votre compte de stockage est automatiquement converti en stockage localement redondant (LRS) dans la nouvelle région primaire pendant le basculement, et le compte de stockage de la région primaire d’origine est supprimé.

Vous pouvez réactiver le stockage géoredondant (GRS) ou le stockage géoredondant avec accès en lecture (RA-GRS) pour le compte, mais notez que la conversion de LRS en GRS ou RA-GRS entraîne un coût supplémentaire. Le coût est dû aux frais de sortie du réseau pour répliquer à nouveau les données dans la nouvelle région secondaire. Par ailleurs, tous les blobs archivés doivent être réhydratés à un niveau en ligne pour que le compte puisse être configuré pour la géoredondance, ce qui entraîne des frais. Pour plus d’informations sur les tarifs, consultez :

Une fois que vous avez réactivé GRS pour votre compte de stockage, Microsoft commence à répliquer les données de votre compte dans la nouvelle région secondaire. La durée de la réplication dépend de nombreux facteurs, notamment :

  • Le nombre et la taille des objets du compte de stockage. La réplication de nombreux petits objets peut prendre plus de temps que celle d’objets moins nombreux et plus grands.
  • Les ressources disponibles pour la réplication en arrière-plan, telles que l’UC, la mémoire, le disque et la capacité WAN. Le trafic en direct est prioritaire sur la géoréplication.
  • Si votre compte de stockage contient des blobs, le nombre d’instantanés par blob.
  • Si votre compte de stockage contient des tables, la stratégie de partitionnement des données. Le processus de réplication ne peut pas évoluer au-delà du nombre de clés de partition que vous utilisez.

Types de compte de stockage pris en charge

Toutes les offres géoredondantes prennent en charge le basculement géré par Microsoft. De plus, certains types de comptes prennent en charge le basculement de compte géré par le client, comme indiqué dans le tableau suivant :

Type de basculement GRS/RA-GRS GZRS/RA-GZRS
Basculement géré par le client Comptes v2 universels
Comptes v1 universels
Comptes Stockage Blob hérités		 Les comptes de stockage à usage général v2
Basculement géré par Microsoft Tous les types de comptes Les comptes de stockage à usage général v2

Comptes de stockage Classic

Important

Le basculement de compte géré par le client est pris en charge uniquement pour les comptes de stockage déployés à l’aide du modèle de déploiement Azure Resource Manager (ARM). Le modèle de déploiement Azure Service Manager (ASM), également appelé classique, n’est pas pris en charge. Pour que les comptes de stockage classiques soient éligibles au basculement de compte géré par le client, ils doivent d’abord être migrés vers le modèle ARM. Comme votre compte de stockage doit être accessible pour effectuer la mise à niveau, la région primaire ne peut pas être en état d’échec à ce moment-là.

Si un sinistre affecte la région primaire, Microsoft gère le basculement pour les comptes de stockage classiques. Pour plus d’informations, consultez Basculement géré par Microsoft.

Azure Data Lake Storage Gen2

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.

Si un sinistre important affecte la région primaire, Microsoft gère le basculement pour les comptes qui ont un espace de noms hiérarchique. Pour plus d’informations, consultez Basculement géré par Microsoft.

Fonctionnalités et services non pris en charge

Les fonctionnalités et services suivants ne sont pas pris en charge pour le basculement de compte :

  • Azure File Sync ne prend pas en charge le basculement de compte de stockage lancé par le client. Les comptes de stockage qui contiennent des partages de fichiers Azure servant de points de terminaison cloud dans Azure File Sync ne doivent pas être basculés. Cela provoquera en effet un arrêt de la synchronisation et pourra entraîner une perte inattendue de données dans le cas de fichiers nouvellement hiérarchisés. Pour en savoir plus, consultez Meilleures pratiques pour la récupération d’urgence avec Azure File Sync.
  • Un compte de stockage contenant des blobs de blocs Premium ne peut pas être basculé. Les comptes de stockage qui prennent en charge les blobs de blocs Premium ne prennent pas en charge la géoredondance.
  • Le basculement géré par le client n’est pas pris en charge pour le compte source ou de destination dans une stratégie de réplication d’objet.
  • Pour basculer un compte avec le protocole SFTP (SSH File Transfer Protocol) activé, vous devez d’abord désactiver SFTP pour le compte. Si vous souhaitez reprendre l’utilisation de SFTP une fois le basculement terminé, il vous suffit de le réactiver.
  • Le système de fichiers réseau (NFS) 3.0 (NFSv3) n’est pas pris en charge pour le basculement de compte de stockage. Vous ne pouvez pas créer de compte de stockage configuré pour la redondance globale avec NFSv3 activé.

Le basculement ne convient pas à la migration de compte

Le basculement d’un compte de stockage ne doit pas être utilisé dans le cadre de votre stratégie de migration des données. Le basculement est une solution temporaire à une panne de service. Pour plus d’informations sur la migration de vos comptes de stockage, consultez Vue d’ensemble de la migration de Stockage Azure.

Comptes de stockage contenant des blobs archivés

Les comptes de stockage contenant des objets blob archivés peuvent faire l’objet d’un basculement. Toutefois, après un basculement géré par le client, tous les blobs archivés doivent être réhydratés à un niveau en ligne pour que le compte puisse être configuré pour la géoredondance.

Fournisseur de ressources de stockage

Microsoft fournit deux API REST pour l’utilisation des ressources Stockage Azure. Ces API constituent la base de toutes les actions que vous pouvez effectuer sur Stockage Azure. L’API REST de Stockage Azure vous permet d’utiliser les données de votre compte de stockage, y compris les données des objets blob, des files d’attente, des fichiers et des tables. L’API REST du fournisseur de ressources Stockage Azure vous permet de gérer le compte de stockage et les ressources associées.

Une fois le basculement terminé, les clients peuvent à nouveau lire et écrire des données Stockage Azure dans la nouvelle région primaire. Toutefois, le fournisseur de ressources Stockage Azure ne bascule pas ; les opérations de gestion des ressources doivent donc toujours avoir lieu dans la région primaire. Si la région primaire n’est pas disponible, vous ne pourrez pas effectuer d’opérations de gestion sur le compte de stockage.

Étant donné que le fournisseur de ressources Stockage Azure ne bascule pas, la propriété Emplacement retourne l’emplacement primaire d’origine une fois le basculement terminé.

Machines virtuelles Azure

Les machines virtuelles Azure ne basculent pas pendant le basculement de compte. Si la région primaire devient indisponible et que vous basculez vers la région secondaire, vous devez recréer toutes les machines virtuelles après le basculement. Par ailleurs, il existe un risque de perte de données lié au basculement de compte. Microsoft vous recommande de suivre les recommandations suivantes en matière de haute disponibilité et récupération d’urgence propres aux machines virtuelles dans Azure.

N’oubliez pas que toutes les données stockées dans un disque temporaire sont perdues quand la machine virtuelle est arrêtée.

Disques non managés Azure

En guise de bonne pratique, Microsoft vous recommande de convertir les disques non managés en disques managés. Toutefois, si vous avez besoin d’effectuer le basculement d’un compte qui contient des disques non managés attachés à des machines virtuelles Azure, vous devez arrêter la machine virtuelle avant de lancer le basculement.

Les disques non managés sont stockés en tant qu’objets blob de pages dans Stockage Azure. Quand une machine virtuelle s’exécute dans Azure, les disques non managés attachés à la machine virtuelle sont loués. Un basculement de compte ne peut pas se produire quand il existe un bail sur un blob. Pour effectuer le basculement, effectuez les étapes suivantes :

  1. Avant de commencer, notez les noms de tous les disques non managés, leurs numéros d’unité logique (LUN) et la machine virtuelle à laquelle ils sont attachés. Cela facilitera le réattachement des disques après le basculement.
  2. Arrêtez la machine virtuelle.
  3. Supprimez la machine virtuelle, mais conservez les fichiers de disque dur virtuel pour les disques non managés. Notez l’heure à laquelle vous avez supprimé la machine virtuelle.
  4. Attendez que la Dernière heure de synchronisation ait été mise à jour et soit postérieure à l’heure à laquelle vous avez supprimé la machine virtuelle. Cette étape est importante, car si le point de terminaison secondaire n’a pas été totalement mis à jour avec les fichiers VHD quand le basculement se produit, la machine virtuelle risque de ne pas fonctionner correctement dans la nouvelle région primaire.
  5. Lancez le basculement de compte.
  6. Attendez que le basculement de compte soit terminé et que la région secondaire soit devenue la nouvelle région primaire.
  7. Créez une machine virtuelle dans la nouvelle région primaire et réattachez les disques durs virtuels.
  8. Démarrez la nouvelle machine virtuelle.

N’oubliez pas que toutes les données stockées dans un disque temporaire sont perdues quand la machine virtuelle est arrêtée.

Copie de données comme alternative au basculement

Si votre compte de stockage est configuré pour l’accès en lecture sur la région secondaire, vous pouvez concevoir votre application pour qu’elle puisse lire sur le point de terminaison secondaire. Si vous préférez ne pas effectuer de basculement en cas de panne dans la région primaire, vous pouvez utiliser des outils comme AzCopy ou Azure PowerShell pour copier les données de votre compte de stockage dans la région secondaire vers un autre compte de stockage dans une région non affectée. Vous pouvez ensuite faire en sorte que vos applications pointent vers ce compte de stockage pour la disponibilité en lecture et en écriture.

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 :

Gardez à l’esprit ces bonnes pratiques pour maintenir la haute disponibilité de vos données de Stockage Azure :

  • Disques : utilisez Sauvegarde Azure pour sauvegarder les disques de machine virtuelle utilisés par vos machines virtuelles Azure. Vous pouvez aussi utiliser Azure Site Recovery pour protéger vos machines virtuelles en cas de sinistre régional.
  • Objets blob de blocs : activez la suppression réversible pour protéger contre les suppressions et remplacements au niveau objet, ou copiez les objets blob de blocs vers un autre compte de stockage dans une région différente à l’aide d’AzCopy, d’Azure PowerShell ou de la bibliothèque de déplacement de données Azure.
  • Fichiers : Utilisez le service Sauvegarde Azure pour sauvegarder vos partages de fichiers. Activez également la suppression réversible pour vous protéger des suppressions accidentelles de partages de fichiers. Afin de bénéficier de la géoredondance quand le stockage GRS n'est pas disponible, utilisez AzCopy ou Azure PowerShell pour copier vos fichiers dans un autre compte de stockage dans une autre région.
  • Tables : utilisez AzCopy pour exporter les données de table vers un autre compte de stockage dans une région différente.

Effectuer le suivi des pannes

Les clients peuvent s’abonner au tableau de bord Azure Service Health pour effectuer le suivi de l’intégrité et de l’état de Stockage Azure et d’autres services Azure.

Microsoft vous recommande é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.

Voir aussi