Partager via

Fiabilité dans Azure Storage Mover

  • Article

Cet article décrit la prise en charge de la fiabilité dans azure Storage Mover et couvre la résilience intra-régionale avec zones de disponibilité et reprise d’activité interrégion et la continuité d’activité. 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é Azure sont au moins trois groupes physiquement distincts de centres de données dans chaque région Azure. Les centres de données de chaque zone sont équipés d’une infrastructure réseau, de refroidissement et d’alimentation indépendante. En cas de défaillance de zone locale, les zones de disponibilité sont conçues de telle sorte que si une zone est affectée, les services, la capacité et la haute disponibilité de la région sont pris en charge par les deux autres zones.

Les défaillances sont aussi bien des défaillances logicielles et matérielles que des événements de type tremblements de terre, inondations et incendies. La tolérance aux défaillances est obtenue par la redondance et l’isolation logique des services Azure. Pour obtenir des informations détaillées sur les zones de disponibilité dans Azure, consultez Régions et zones de disponibilité.

Les services Azure compatibles avec les zones de disponibilité sont conçus pour fournir le niveau approprié de fiabilité et de flexibilité. Ils peuvent être configurés de deux façons. Un service peut être redondant interzone, avec une réplication automatique entre les zones, ou zonal, avec des instances épinglées à une zone spécifique. Vous pouvez également combiner ces approches. Pour plus d’informations sur l’architecture zonale et redondante interzone, consultez Recommandations relatives à l’utilisation de zones de disponibilité et de régions.

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 d’instance Du mover stockage Azure incluent des projets, des points de terminaison, des agents, des définitions de travaux et l’historique des exécutions de travaux, 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

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-guérir et réé balancer lui-même pour tirer parti 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.

Récupération d’urgence et continuité d’activité inter-région

La récupération d’urgence (DR) consiste à récupérer après des évènements à fort impact, comme des catastrophes naturelles ou des échecs de déploiements, qui entraînent un temps d’arrêt et une perte de données. Quelle qu’en soit la cause, la meilleure solution en cas de sinistre est d’avoir un plan de DR bien défini et testé, et une conception d’application qui prend activement en charge la DR. Avant de commencer à réfléchir à la création de votre plan de récupération d’urgence, consultez Suggestions pour la conception d’une stratégie de récupération d’urgence.

En ce qui concerne la récupération d’urgence (DR), Microsoft utilise le modèle de responsabilité partagée. Dans un modèle de responsabilité partagée, Microsoft garantit que l’infrastructure de référence et les services de plateforme sont disponibles. En même temps, de nombreux services Azure ne répliquent pas automatiquement les données ou reviennent 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 conseils pour prendre en charge la récupération d’urgence et vous pouvez utiliser fonctionnalités spécifiques au service pour prendre en charge la récupération rapide pour vous aider à développer votre plan de récupération d’urgence.

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 :

  • de récupération d’urgence lancée par Azure
  • de récupération d’urgence initiée par le client

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 effectuer l’une des deux opérations 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.

Inscription du 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.

Affectation de l’agent aux définitions de travaux

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

Octroi de l’accès de l’agent 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 des travaux de migration à l’aide des ressources de mover de stockage nouvellement déployées.

Étapes suivantes