Partager via

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 pannes de service non prévues peuvent parfois se produire. Les principaux composants d’un bon plan de récupération d’urgence contiennent des stratégies pour :

Cet article décrit les options disponibles pour les comptes de stockage globalement redondants et fournit des recommandations pour le développement d’applications hautement disponibles et le test de votre plan de récupération d’urgence.

Choisir l’option de redondance appropriée

Stockage Azure gère plusieurs copies de votre compte de stockage pour garantir que les objectifs de disponibilité et de durabilité sont respectés, même en cas de défaillances. La façon dont les données sont répliquées fournit des niveaux de protection différents. Chaque option offre ses propres avantages, de sorte que l’option que vous choisissez dépend du degré de résilience dont vos applications ont besoin.

Le stockage localement redondant (LRS), l’option de redondance la moins chère, stocke et réplique automatiquement trois copies de votre compte de stockage au sein d’un seul centre de données. Bien que LRS protège vos données contre les défaillances de rack de serveurs et de disque, il ne tient pas compte des sinistres tels que les incendies ou les inondations d’un centre de données. Face à ces sinistres, tous les réplicas d’un compte de stockage configuré pour utiliser LRS peuvent être perdus ou irrécupérables.

Par comparaison, le stockage redondant interzone (ZRS) conserve une copie d’un compte de stockage et le réplique dans chacune des trois zones de disponibilité distinctes 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 géoredondant (GRS) et basculement

Le stockage géoredondant (GRS), le stockage géoredondant interzone (GZRS) et le stockage géoredondant interzone avec accès en lecture (RA-GZRS) sont des exemples d’options de stockage globalement redondantes. Lorsqu’il est configuré pour utiliser le stockage globalement redondant (GRS, GZRS et RA-GZRS), Azure copie vos données de manière asynchrone dans une région géographique secondaire. Ces régions se trouvent à des centaines, voire des milliers de kilomètres. Ce niveau de redondance vous permet de récupérer vos données en cas de panne dans toute la région primaire.

Contrairement à LRS et ZRS, le stockage globalement redondant prend également en charge le basculement non planifié vers une région secondaire en cas de panne dans la région primaire. Pendant le processus de basculement, les entrées DNS (Domain Name System) pour vos points de terminaison de service de compte de stockage sont automatiquement mises à jour afin que les points de terminaison de la région secondaire deviennent les nouveaux points de terminaison de la région primaire. Une fois le basculement non planifié terminé, les clients peuvent commencer à écrire dans les nouveaux point de terminaison primaires.

Le stockage géoredondant avec accès en lecture (RA-GRS) et le stockage géoredondant interzone avec accès en lecture (RA-GZRS) fournissent également un stockage géoredondant, mais offrent l’avantage supplémentaire de l’accès en lecture au point de terminaison secondaire. Ces options sont idéales pour les applications conçues pour les applications vitales pour l’entreprise à haute disponibilité. Si le point de terminaison de la région primaire rencontre une panne, les applications configurées pour l’accès en lecture à la région secondaire peuvent continuer à fonctionner. 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

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

1 Le 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 Utilisez les options de basculement géré par le client pour développer, tester et implémenter vos plans de récupération d’urgence. 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
Basculement planifié géré par le client (préversion) Compte de stockage Les points de terminaison du service de stockage pour les régions primaires et secondaires sont disponibles et vous souhaitez effectuer des tests de récupération d’urgence.

Les points de terminaison du service de stockage pour la région primaire sont disponibles, mais un autre service Microsoft ou tiers empêche vos charges de travail de fonctionner correctement.

Pour vous préparer de manière proactive aux catastrophes à grande échelle, comme un ouragan, qui peuvent avoir un impact sur une région.		 Aucun Oui
(En préversion)
Basculement géré par le client (non planifié) 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 Région entière La région primaire est indisponible en raison d’un sinistre important, mais la région secondaire est disponible. Oui Oui

Le tableau suivant compare l’état de redondance d’un compte de stockage après chaque type de basculement :

Résultat du basculement sur... Basculement planifié géré par le client (préversion) Basculement géré par le client (non planifié)
...la région secondaire La région secondaire devient la nouvelle région primaire La région secondaire devient la nouvelle région primaire
...la région primaire d’origine La région primaire d’origine devient la nouvelle région secondaire La copie des données dans la région primaire d’origine est supprimée
...la configuration de la redondance du compte Le compte de stockage est converti en GRS Le compte de stockage est converti en LRS
...la configuration de la redondance La géoredondance est conservée La géoredondance est perdue

Le tableau suivant récapitule la configuration de la redondance résultante à chaque étape du processus de basculement et de restauration automatique pour chaque type de basculement :

Original
configuration		 Après
failover		 Après réactivation
Géoredondance		 Après
Restauration automatique		 Après réactivation
Géoredondance
Basculement planifié géré par le client
GRS GRS n/a 2 GRS n/a 2
GZRS GRS n/a 2 GZRS n/a 2
Basculement géré par le client (non planifié)
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é et doit être reconfigurée manuellement.
2 La géoredondance est conservée pendant un basculement non planifié et n’a pas besoin d’être reconfigurée manuellement.

Basculement planifié géré par le client (préversion)

Important

Le basculement planifié géré par le client est actuellement en PRÉVERSION et limité aux régions suivantes :

  • Australie Est
  • USA Centre
  • Asie Est
  • USA Est 2
  • France Centre
  • Inde Centre
  • Inde Ouest
  • Asie Sud-Est
  • Suisse Nord
  • Suisse Ouest
  • Sud du Royaume-Uni
  • Europe Ouest

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.

Pour vous inscrire à la préversion, consultez Configurer des fonctionnalités d’évaluation dans un abonnement Azure et spécifiez AllowSoftFailover comme nom de fonctionnalité. Le nom du fournisseur pour cette fonctionnalité d’évaluation est Microsoft.Storage.

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, il n’existe aucun instantané système disponible sur la nouvelle région secondaire une fois le basculement planifié terminé, ce qui entraîne la valeur LST globale du compte à être signalée comme obsolète ou comme Null.

Étant donné que 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, n’importe quel compte sur lequel ces activités se produisent après le basculement planifié ne nécessite pas d’attention supplémentaire. Toutefois, les comptes qui n’ont pas d’instantanés ou d’activité utilisateur peuvent continuer à afficher une valeur LST Null jusqu’à ce que la création d’instantanés système soit déclenchée.

Si nécessaire, effectuez l’une des activités suivantes pour déclencher la création d’instantanés. Une fois l’opération terminée, votre compte doit afficher une valeur LST 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.
  • Créez un instantané de partage pour le partage à partir du Portail Azure.

Il existe de nombreux scénarios pour lesquels le basculement planifié est idéal. Ces scénarios sont les suivants :

  • Planification et tests de la récupération d’urgence.
  • La récupération pendant une panne qui n’affecte pas les points de terminaison de service de stockage de votre région primaire, mais qui empêche un autre service Microsoft ou tiers de fournir l’accès à vos charges de travail.
  • Pour vous préparer de manière proactive aux catastrophes à grande échelle, comme un ouragan, qui peuvent avoir un impact sur une région.

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é).

Basculement géré par le client (non planifié)

Si les points de terminaison de données des services de stockage de votre compte de stockage deviennent indisponibles dans la région primaire, vous pouvez lancer un basculement non planifié vers la région secondaire. Une fois le basculement terminé, la région secondaire devient la nouvelle région primaire et les utilisateurs peuvent continuer à accéder aux données dans celle-ci.

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 non planifié et de restauration automatique. Pour plus d’informations sur le fonctionnement du processus, consultez Fonctionnement du basculement géré par le client (non planifié).

Basculement géré par Microsoft

Microsoft peut lancer un basculement régional dans des circonstances extrêmes, comme une urgence catastrophique qui a un impact sur l’ensemble d’une région géographique. Pendant ces événements, aucune action de votre part n’est requise. Si votre compte de stockage est configuré pour le stockage RA-GRS ou RA-GZRS, vos applications peuvent lire à partir de la région secondaire pendant un basculement géré par Microsoft. Toutefois, vous n’avez pas accès en écriture à votre compte de stockage tant que le processus de basculement n’est pas terminé.

Important

Utilisez les options de basculement géré par le client pour développer, tester et implémenter vos plans de récupération d’urgence. 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 un centre de données. 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 géré par le client (non planifié) implique généralement une certaine perte de données et peut également introduire des incohérences 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 devient indisponible, il est possible que les écritures les plus récentes ne soient pas encore copiées dans la région secondaire.

En cas de basculement non planifié, toutes les données de la région primaire sont perdues lorsque 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, toutes les données écrites dans la région primaire qui ne sont pas encore dans la région secondaire sont perdues définitivement.

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é Heure de la dernière synchronisation indique l’heure la plus récente à laquelle les données de la région primaire ont également é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 l’heure de la dernière synchronisation sont disponibles dans la région secondaire. En revanche, les données et les métadonnées écrites après l’heure de la dernière synchronisation peuvent ne pas encore être copiées dans la région secondaire et potentiellement perdues. Lors d’une panne, utilisez cette propriété pour estimer la perte de données que peut entraîner le lancement d’un basculement de compte.

En guise de bonne pratique, concevez votre application afin de pouvoir utiliser l’heure de la dernière synchronisation pour évaluer la perte de données attendue. Par exemple, la journalisation de toutes les opérations d’écriture vous permet de comparer les heures de votre dernière opération d’écriture à l’heure de la dernière synchronisation. Cette méthode vous permet de déterminer quelles écritures ne sont pas encore synchronisées avec la région secondaire et risquent d’être perdues.

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. Étant donné que la réplication se produit à ce niveau, une panne dans la région primaire peut empêcher certains fichiers d’un conteneur ou d’un répertoire d’être répliqués avec succè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 géré par le client (non planifié) des comptes de stockage 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 résulter de la nature asynchrone des mises à jour du journal des modifications et de la réplication des données entre les régions primaires et secondaires. Vous pouvez éviter les incohérences en prenant les précautions suivantes :

  • Vérifiez que tous les enregistrements de journal sont vidés dans les fichiers journaux.
  • Vérifiez que toutes les données de stockage sont répliquées de la région primaire vers la région secondaire.

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

N’oubliez pas que d’autres fonctionnalités de compte de stockage nécessitent également l’activation du flux de modification. Ces fonctionnalités incluent la sauvegarde opérationnelle du Stockage Blob Azure, la réplication d’objets et la restauration à un instant dans le passé pour les 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 Microsoft Azure.

Temps et coût du basculement

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

Un basculement planifié géré par le client ne perd pas sa géoredondance après un basculement et une restauration automatique ultérieure, contrairement à un basculement non planifié géré par le client.

Avec un basculement non planifié géré par le client, votre compte de stockage est automatiquement converti en stockage localement redondant dans la nouvelle région primaire, 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 la seconde réplication des données vers la nouvelle région secondaire entraîne des frais. En outre, tous les objets blob archivés doivent être réhydratés à un niveau en ligne pour que le compte puisse être configuré pour la géoredondance. Cette réhydratation entraîne également des frais supplémentaires. 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 nécessaire à la réplication dépend de plusieurs facteurs. Ces facteurs sont les suivants :

  • 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.
  • Le nombre d’instantanés par objet blob, le cas échéant.
  • La stratégie de partitionnement des données, si votre compte de stockage contient des tables. 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 (non planifié) Comptes v2 universels
Comptes v1 universels
Comptes Stockage Blob hérités		 Les comptes de stockage à usage général v2
Basculement planifié géré par le client (préversion) 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 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é le modèle 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à.

Lors d’un sinistre qui 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.

Espace de noms hiérarchique

Important

Le basculement géré par le client (non planifié) pour les comptes qui ont un espace de noms hiérarchique (Azure Data Lake Storage Gen2) ou SSH File Transfer Protocol (SFTP) 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.

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.

Fonctionnalités et services non pris en charge

Les fonctionnalités et services suivants ne sont pas pris en charge pour le basculement géré par le client :

  • Azure File Sync ne prend pas en charge le basculement de compte de stockage géré par le client. Les comptes de stockage utilisés comme points de terminaison cloud dans Azure File Sync ne doivent pas être basculés. Le basculement interrompt la synchronisation des fichiers et peut entraîner la perte inattendue de données des 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.
  • 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 tableau suivant peut être utilisé pour référencer la prise en charge des fonctionnalités.

Basculement planifié Basculement non planifié
ADLS Gen2 Pris en charge (préversion) Pris en charge (préversion)
Flux de modification Non pris en charge Prise en charge
Réplication d’objets Non pris en charge Non pris en charge
SFTP Pris en charge (préversion) Pris en charge (préversion)
NFSv3 GRS n’est pas pris en charge GRS n’est pas pris en charge
Actions de stockage Non pris en charge Non pris en charge
Restauration à un instant dans le passé (PITR) Non pris en charge Prise en charge

Le basculement ne convient pas à la migration de compte

Les basculements de compte de stockage constituent une solution temporaire qui peut être utilisée pour planifier et tester vos plans de récupération d’urgence ou pour effectuer une récupération à partir d’une panne de service. Le basculement ne doit pas être utilisé dans le cadre de votre stratégie de migration des données. 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 de stockage. Toutes les machines virtuelles qui ont basculé vers une région secondaire en réponse à une panne doivent être recréées une fois le basculement terminé. Le basculement de compte peut entraîner une perte des données stockées dans un disque temporaire lors de l’arrêt de la machine virtuelle. 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.

Disques non managés Azure

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. Avant de pouvoir lancer un basculement sur un compte contenant des disques non managés attachés aux machines virtuelles Azure, les disques doivent être arrêtés. Pour cette raison, les meilleures pratiques recommandées par Microsoft incluent la conversion de disques non managés en disques managés.

Pour effectuer un basculement sur un compte contenant des disques non managés, procédez comme suit :

  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 (VHD) pour les disques non managés. Notez l’heure à laquelle vous avez supprimé la machine virtuelle.
  4. Patientez jusqu’à la mise à jour de l’heure de la dernière synchronisation et vérifiez qu’elle est ultérieure à l’heure à laquelle vous avez supprimé la machine virtuelle. Cette étape garantit que le point de terminaison secondaire est entièrement mis à jour avec les fichiers de disque dur virtuel lorsque le basculement se produit et que la machine virtuelle fonctionne 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

Comme mentionné précédemment, vous pouvez maintenir la haute disponibilité en configurant des applications pour utiliser un compte de stockage configuré pour l’accès en lecture à une région secondaire. Toutefois, si vous préférez ne pas basculer pendant une panne dans la région primaire, vous pouvez copier manuellement vos données en guise d’alternative. Les outils tels que AzCopy et Azure PowerShell vous permettent de copier des données de votre compte de stockage dans la région affectée vers un autre compte de stockage dans une région non affectée. Une fois l’opération de copie terminée, vous pouvez reconfigurer vos applications pour utiliser le compte de stockage dans la région non affectée 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 récupération d’urgence, consultez ces ressources Azure :

Reportez-vous à ces bonnes pratiques pour maintenir la haute disponibilité pour vos données 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