Partager via

Fiabilité dans Azure Storage Mover

Cet article décrit la prise en charge de la fiabilité dans Azure Storage Mover et couvre à la fois la résilience intrarégionale avec les zones de disponibilité et la récupération d’urgence interrégionale et la continuité des activités. Pour obtenir une vue d’ensemble plus détaillée de la fiabilité dans Azure, consultez fiabilité d’Azure.

Prise en charge des zones de disponibilité

Les zones de disponibilité sont des groupes physiquement distincts de centres de données au sein d’une région Azure. Lorsqu'une zone tombe en panne, les services peuvent basculer vers l'une des zones restantes.

Azure Storage Mover prend en charge un modèle de déploiement redondant interzone.

Lorsque vous déployez une ressource Azure Storage Mover, vous devez sélectionner une région particulière dans laquelle les métadonnées d’instance de la ressource sont stockées.

Si la région prend en charge les zones de disponibilité, les métadonnées d’instance sont automatiquement répliquées sur plusieurs zones de disponibilité au sein de cette région.

Important

Les métadonnées de l’instance Azure Storage Mover incluent les projets, les points de terminaison, les agents, les définitions de tâches et l’historique d’exécution des tâches, mais n’incluent pas les données réelles à migrer. Les comptes de stockage Azure utilisés comme cibles de migration ont leur propre prise en charge de fiabilité.

Prérequis

  • Pour déployer avec la prise en charge des zones de disponibilité, vous devez choisir une région qui prend en charge les zones de disponibilité. Pour voir quelles régions prennent en charge les zones de disponibilité, consultez la liste des régions prises en charge.

  • (Facultatif) Si votre compte de stockage cible ne prend pas en charge les zones de disponibilité et que vous souhaitez migrer le compte vers la prise en charge AZ, consultez Modifier la façon dont un compte de stockage est répliqué.

Expérience en cas de panne de zone

Lors d’une panne à l’échelle de la zone, aucune action n’est requise lors de la récupération de zone. Azure Storage Mover est conçu pour s’auto-réparer et se rééquilibrer afin de profiter automatiquement de la zone saine.

Tout compte de stockage cible de migration peut nécessiter ses propres étapes de récupération. Cette exigence dépend des options de redondance choisies pour chaque compte de stockage. Consultez le guide de récupération d’urgence compte de stockage pour déterminer si d’autres étapes sont nécessaires.

Si un stockage local a été choisi au lieu d’options de redondance, vous devrez peut-être créer un compte de stockage à utiliser lors de la panne.

Reprise d’activité et continuité d’activité entre régions

La reprise après sinistre (DR) fait référence aux pratiques utilisées par les organisations pour se remettre d’événements à fort impact, tels que des catastrophes naturelles ou des déploiements échoués qui entraînent des temps d’arrêt et des pertes de données. Quelle que soit la cause, la meilleure solution pour une catastrophe est un plan de récupération d’urgence bien défini et testé et une conception d’application qui prend activement en charge la récupération d’urgence. Avant de commencer à créer votre plan de reprise après sinistre, consultez Recommandations pour la conception d'une stratégie de reprise après sinistre.

Pour la récupération d’urgence, Microsoft utilise le modèle de responsabilité partagée. Dans ce modèle, Microsoft garantit que l’infrastructure de base et les services de plateforme sont disponibles. Cependant, de nombreux services Azure ne répliquent pas automatiquement les données ou ne reviennent pas d’une région défaillante pour effectuer une réplication croisée vers une autre région activée. Pour ces services, vous êtes responsable de la configuration d’un plan de récupération d’urgence qui fonctionne pour votre charge de travail. La plupart des services qui s’exécutent sur des offres PaaS (Platform as a Service) Azure fournissent des fonctionnalités et des instructions pour la prise en charge de la récupération d’urgence. Vous pouvez utiliser des fonctionnalités spécifiques au service pour prendre en charge une récupération rapide afin de vous aider à développer votre plan de reprise après sinistre.

Lorsqu’un agent Storage Mover est inscrit, il se connecte à la région dans laquelle la ressource Storage Mover est inscrite. Si la région Azure d’un agent subit une panne, l’agent lui-même n’est pas affecté, mais les opérations de gestion qui s’appuient sur Azure peuvent ne pas être terminées. En outre, toutes les migrations de données actives vers des comptes de stockage situés dans la région affectée peuvent échouer.

Storage Mover prend en charge deux formes de récupération d’urgence :

Important

La récupération d’urgence pour les sources de données locales est la responsabilité du client.

Reprise d’activité lancée par Azure

La récupération d’urgence initiée par Azure s’applique uniquement aux régions qui ont des paires de régions. Lorsque la réplication interrégion est utilisée, les métadonnées d’instance sont répliquées dans chaque région, mais ne sont jamais autorisées à quitter la zone géographique.

Azure Storage Mover utilise Cosmos DB pour stocker les métadonnées d’instance. La perte de données peut se produire uniquement avec une catastrophe irrécupérable dans Azure Cosmos DB. Pour plus d’informations, consultez Pannes régionales. La récupération lancée par Azure est active-passive et la récupération complète d’une région peut atteindre 24 heures.

Reprise d’activité initiée par le client

La récupération d’urgence initiée par le client n’est pas limitée aux régions jumelées.

Avant une panne régionale :

  • Déployez un mover de stockage redondant interzone en créant des ressources de mover de stockage dans une région qui prend en charge les zones de disponibilité.

  • Périodiquement, soit selon une planification, soit après avoir apporté des modifications substantielles, prenez un instantané de vos ressources Storage Mover. Le stockage des instantanés à l’aide d’un système de contrôle de version est un bon moyen de stocker et de suivre l’historique des instantanés. Vous utiliserez la dernière capture instantanée correcte en cas de sinistre où vous devez récupérer vos ressources dans une nouvelle région.

lors d’une panne régionale :

Vous pouvez faire l’une des deux choses suivantes :

  • Choisissez d’attendre qu’Azure récupère la région.
  • Réduisez les temps d’arrêt en redéployant vos ressources dans une autre région. Étant donné que l’accès à vos ressources peut être affecté lors d’une panne, vous devez utiliser la dernière capture instantanée correcte de vos ressources.

Conseil

L’une de ces stratégies peut toujours exiger que vous deviez prendre d’autres mesures avant un sinistre. Veillez donc à passer en revue et à planifier en conséquence.

Déployer des ressources dans une autre région

Consultez la documentation sur l’exportation de modèles pour obtenir des instructions supplémentaires sur l’exportation de ressources en tant que modèle Azure Resource Manager (ARM).

Si votre mover de stockage et vos ressources associées résident dans un conteneur sans ressources supplémentaires, vous devez effectuer une groupe de ressources exporter pour capturer l’état actuel. Toutefois, si votre groupe de ressources contient des ressources non liées, vous devrez peut-être supprimer ou exclure les ressources du modèle.

Les agents existants ne peuvent pas être redéployés dans une autre région. Si la région dans laquelle ils ont été configurés à l’origine a une panne, il se peut qu’il ne soit pas possible d’annuler complètement l’inscription et de réinscrire l’agent. Ce document suppose que les nouveaux agents sont inscrits dans une nouvelle région.

Pour utiliser le modèle exporté pour la récupération d’urgence, quelques modifications apportées au modèle sont requises.

  • Tout d’abord, supprimez les ressources Microsoft.StorageMover/agents et Microsoft.HybridCompute/machines du modèle. Veillez également à supprimer toutes les références de dépendance à ces ressources.
  • Ensuite, supprimez la propriété agentResourceId de toutes les définitions de travaux. Vous devez les affecter à un nouvel agent après le déploiement.
  • Après avoir supprimé toutes les références aux ressources de l’agent et de la machine de calcul hybride, mettez à jour la propriété d’emplacement de la ressource de déplacement de stockage de niveau supérieur. Remplacez le nom de la région actuellement déployée par le nom de la nouvelle région.
  • Enfin, déterminez s’il faut conserver l’ID de ressource du compte de stockage existant. Si nécessaire, remplacez-le par un autre compte de stockage.

Après avoir effectué les étapes précédentes et vérifié que les paramètres du modèle sont corrects, le modèle est prêt pour le déploiement vers une nouvelle région. Vous devez déployer le modèle dans un nouveau groupe de ressources qui a la même région par défaut que la propriété d’emplacement dans le modèle.

Inscrire le nouvel agent

Suivez les étapes décrites dans le déployer un agent Azure Storage Mover article pour inscrire un nouvel agent dans la nouvelle ressource Storage Mover.

Affecter l’agent aux définitions de postes

Une fois que le nouvel agent a été inscrit et signalé en tant que ligne, utilisez le portail Azure ou PowerShell pour associer les définitions de travail existantes au nouvel agent. L’exemple PowerShell suivant est fourni pour des raisons pratiques.

Consultez la définir un nouveau travail de migration pour obtenir des conseils sur l’accès aux définitions de travaux pour votre projet.


## Update the agent in a job definition resource
$resourceGroupName  = "[Your resource group name]"
$storageMoverName   = "[Your storage mover name]"
$projectName        = "[Your project name]"
$jobDefName         = "[Your job definition name]"
$agentName          = "[The name of an agent previously registered to the same storage mover resource]"

Update-AzStorageMoverJobDefinition `
    -ResourceGroupName $resourceGroupName `
    -StorageMoverName $storageMoverName `
    -ProjectName $projectName `
    -Name $jobDefName `
    -AgentName $agentName

Accorder à l’agent l’accès au conteneur de stockage cible

Vous devez attribuer le rôle contributeur de données à l’identité managée pour effectuer une tâche de migration. Affectez l’accès de l’identité managée système de la ressource de calcul hybride à la ressource de compte de stockage cible. Le attribuer un accès d’identité managée à une ressource article fournit des conseils sur la façon d’accorder l’accès à la ressource cible.

Vous êtes maintenant prêt à démarrer les tâches de migration à l’aide des ressources Storage Mover nouvellement déployées.

Étapes suivantes

  • Last updated on