Fiabilité dans stockage Azure Mover

stockage Azure Mover est un service entièrement géré qui migre les fichiers et dossiers vers stockage Azure, et conserve les fichiers synchronisés entre les comptes de stockage. Utilisez storage Mover lorsque vous déplacez des données dans Azure, ou lorsque vous devez conserver des données synchronisées entre différents emplacements dans Azure.

Lorsque vous utilisez Azure, la fiabilité est une responsabilité partagée. Microsoft offre une gamme de fonctionnalités permettant de prendre en charge la résilience et la récupération. Vous êtes responsable de comprendre le fonctionnement de ces fonctionnalités dans tous les services que vous utilisez et de sélectionner les fonctionnalités dont vous avez besoin pour atteindre vos objectifs métier et vos objectifs de temps d’activité.

Cet article explique comment stockage Azure Mover répond à diverses pannes et problèmes potentiels, notamment les erreurs temporaires, les défaillances de zone de disponibilité et les défaillances à l’échelle de la région. Il décrit également comment protéger votre configuration de Storage Mover.

Important

Cet article traite de la fiabilité du service mover stockage Azure et de ses ressources uniquement. La fiabilité d’une migration de bout en bout dépend de tous les composants : le service Storage Mover, les agents storage Mover que vous déployez, l’environnement source et la connectivité réseau, ainsi que le compte de stockage cible. Vous êtes responsable de la fiabilité des agents, des systèmes sources et du stockage cible. Pour plus d’informations sur la fiabilité stockage Azure, consultez Fiabilité dans Stockage Blob Azure et Fiabilité dans Azure Files.

Vue d’ensemble de l’architecture de fiabilité

Cette section décrit certains des aspects importants du fonctionnement du service qui sont les plus pertinents du point de vue de la fiabilité. La section présente l’architecture logique, qui inclut certaines des ressources et fonctionnalités que vous déployez et utilisez. Il traite également de l’architecture physique, qui fournit des détails sur le fonctionnement du service sous les couvertures.

Architecture logique

stockage Azure Mover est conçu pour migrer et synchroniser des données entre des emplacements de stockage, et non pour traiter les demandes dans le chemin d’exécution d’une charge de travail de production. Il a une hiérarchie de ressources qui définit les composants que vous déployez et gérez. La ressource de niveau supérieur est appelée moteur de stockage. Dans un mover de stockage, vous définissez des projets qui contiennent des définitions de travail décrivant ce qu’il faut migrer et où effectuer la migration. Les points de terminaison définissent les emplacements source et cible d’une tâche de migration ou de synchronisation.

Pour certains scénarios, tels que les migrations à partir d’environnements locaux, vous déployez également un ou plusieurs agents Storage Mover. Un agent est un logiciel que vous exécutez sur une machine que vous contrôlez, comme une machine virtuelle ou une machine physique. Certains scénarios ne nécessitent pas d’agent.

Le service stocke les métadonnées de configuration, notamment les projets, les points de terminaison, les inscriptions d’agents, les définitions de travaux et l’historique des exécutions de travaux. Ces métadonnées n’incluent pas les données que vous migrez.

Architecture physique

Le service stockage Azure Mover s’exécute sur une infrastructure gérée par Microsoft. Les agents s’exécutent sur le matériel que vous gérez. Vous êtes responsable de la fiabilité des agents, qui est hors de portée pour cet article.

Résilience aux erreurs temporaires

Les erreurs temporaires sont des défaillances courtes et intermittentes dans les composants. Elles se produisent fréquemment dans un environnement distribué comme le cloud, et font partie intégrante des opérations ordinaires. Les erreurs temporaires se corrigent après une courte période de temps. Il est important que vos applications puissent gérer les erreurs temporaires, généralement en réessayant les requêtes affectées.

Toutes les applications hébergées dans le cloud doivent suivre les instructions de gestion des erreurs temporaires Azure lorsqu’elles communiquent avec toutes les API, bases de données et autres composants hébergés dans le cloud. Pour plus d’informations, voir Recommandations concernant le traitement des pannes transitoires.

Si une erreur temporaire affecte la communication entre un agent et le service Storage Mover, ou lors de la connexion à une source ou une cible, l’agent retente automatiquement. Pour les tâches d’Azure à Azure, le service résiste également à de nombreuses défaillances transitoires. Lorsque la connectivité est rétablie, les travaux de migration en cours reprendnt.

Dans certains cas, les erreurs temporaires apparaissent comme des erreurs dans l’historique des exécutions du travail. Pour obtenir une description des codes d’erreur, y compris les erreurs temporaires, consultez stockage Azure codes d’état du mover et types d’erreurs. Pour obtenir des conseils sur la résolution des problèmes de connectivité réseau persistants, consultez Résoudre les problèmes de connectivité réseau stockage Azure Mover.

Résilience aux échecs de zone 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.

Dans les régions qui prennent en charge les zones de disponibilité, la plateforme répartit, dans la mesure du possible, les métadonnées de configuration d’un agent de transfert de stockage entre les zones, mais ce comportement n’est pas garanti. Si vos migrations de stockage doivent résister à la perte d’une zone, concevez votre processus de migration de façon à tolérer la perte d’un agent de migration du stockage, et consultez Résilience aux défaillances à l’échelle d’une région.

Tenez compte de l’effet d’une défaillance de zone dans le contexte de l’utilisation de Storage Mover. Le service orchestre la migration et la synchronisation des données, et n’est généralement pas sur le chemin d’exécution de votre charge de travail de production. Si un mover de stockage n’est pas disponible pendant une défaillance de zone, une tâche de migration ou de synchronisation est généralement retardée plutôt que de provoquer une panne de production, et vous pouvez reprendre ou réessayer le travail après la récupération du service. Storage Mover n’offre pas non plus de contrat de niveau de service de disponibilité (SLA), de sorte que votre conception ne doit pas supposer que le service est disponible en permanence. Si votre charge de travail dépend de la synchronisation continue, évaluez si ce type de retard est acceptable pour votre scénario.

Le diagramme suivant illustre un mover de stockage avec des métadonnées d’infrastructure et de configuration réparties entre trois zones :

Schéma d’un service de déplacement de stockage redondant entre zones, réparti sur trois zones de disponibilité.

Note

La fiabilité de toute migration de données dépend également des comptes de stockage et des agents que vous utilisez. Par exemple, si votre compte de stockage cible utilise un stockage localement redondant (LRS), il n’est pas résilient à une défaillance de zone. Pour rendre une migration résiliente à une défaillance de zone, utilisez un compte de stockage cible redondant interzone.

Exigences

Prise en charge de la région : La distribution optimale des métadonnées de configuration entre les zones peut se produire uniquement dans une région qui prend en charge les zones de déplacement de stockage et de disponibilité. Vérifiez la disponibilité de la région storage Mover et comparez-la à la liste des régions qui prennent en charge les zones de disponibilité. Même dans ces régions, la résilience des zones n’est pas garantie.

Coûts

Storage Mover ne prend pas en charge les zones de disponibilité configurables. Vous n’avez donc aucun coût supplémentaire lié aux zones de disponibilité. Pour plus d’informations sur le mode de facturation de Storage Mover, consultez Comprendre la facturation d’stockage Azure Mover.

Configurez la prise en charge des zones de disponibilité

Storage Mover ne prend pas en charge les zones de disponibilité configurables. Il n’y a donc rien à activer ou à choisir. Pour plus d’informations sur la création d’une ressource Storage Mover, consultez Planification du déploiement pour stockage Azure Mover.

Comportement lorsque toutes les zones sont saines

Cette section décrit ce à quoi s’attendre lorsqu’un agent de déplacement du stockage est situé dans une région où les zones de disponibilité sont prises en charge et où toutes les zones sont opérationnelles.

  • Opération interzone : L’infrastructure dans l’une des zones de disponibilité de la région peut servir les opérations de gestion et l’accès aux métadonnées. Les connexions d'agent peuvent atteindre le service via n'importe quelle zone.

  • Distribution des données interzones : Le service vise à répliquer de manière synchrone les métadonnées de configuration entre les zones de disponibilité de la région.

Comportement lors d’une défaillance de zone

Cette section décrit à quoi s’attendre lorsqu’un agent de transfert de stockage se trouve dans une région qui prend en charge les zones de disponibilité et qu’il y a une panne dans l’une de ces zones.

  • Détection et réponse : La plateforme est conçue pour détecter la perte d’une zone de disponibilité et rediriger le trafic vers des zones saines, mais cette réponse est optimale et n’est pas garantie.
  • Notification : Microsoft ne vous avertit pas automatiquement lorsqu'une zone est en panne. Toutefois, vous pouvez utiliser Azure Resource Health pour surveiller l’intégrité d’une ressource individuelle et configurer des alertes Resource Health pour vous avertir des problèmes. Vous pouvez également utiliser Azure Service Health pour comprendre l’intégrité globale du service, y compris les défaillances de zone, et vous pouvez configurer des alertes Service Health pour vous avertir des problèmes.

  • Demandes actives : Les opérations de gestion en cours qui dépendent de l’infrastructure dans la zone affectée peuvent échouer et vous devez les réessayer. Les travaux de migration de données actifs qui s’exécutent sur des agents peuvent continuer à s’exécuter, mais les opérations de gestion qui dépendent du service de métadonnées peuvent ne pas être disponibles.

  • Perte de données attendue : Les données qu’un agent de migration du stockage est en train de migrer ne sont pas perdues en cas de défaillance de zone.

    Étant donné que Storage Mover ne garantit pas que les métadonnées de configuration sont distribuées entre les zones, une défaillance de zone peut rendre temporairement indisponibles certaines métadonnées de configuration du mover de stockage tant que la zone n’est pas récupérée.

  • Temps d’arrêt attendu : La plateforme tente de restaurer des opérations à l’aide d’une autre zone, mais dans certaines situations, les opérations peuvent être indisponibles jusqu’à ce que la zone affectée récupère. Préparez votre charge de travail en suivant les instructions de gestion des erreurs temporaires.

  • Redistribution: Si la plateforme redirige le trafic vers des zones de disponibilité saines, elle le fait de façon optimale.

Récupération de la zone

Lorsqu’une zone de disponibilité récupère, la plateforme vise à restaurer la capacité dans la zone récupérée et à rééquilibrer le trafic entre les zones. Ce comportement est le meilleur effort et n’est pas garanti. Vous n’avez pas besoin d’effectuer d’action pour lancer la récupération de zone.

Tester les pannes de zone

Vous ne pouvez pas déclencher ni tester une défaillance de zone de disponibilité pour un Storage Mover. Étant donné que Storage Mover ne garantit pas la résilience aux zones, ne supposez pas qu'un Storage Mover survivra à une défaillance de zone. Si votre processus de migration doit résister à la perte d’une zone, validez la résilience de bout en bout de ce processus vous-même et passez en revue la résilience aux défaillances à l’échelle de la région pour les approches qui vous permettent de contrôler le basculement.

Résilience aux défaillances à l’échelle de la région

stockage Azure Mover est un service à région unique. Lorsque vous déployez une ressource mover stockage Azure, vous sélectionnez une région pour stocker les métadonnées de configuration de la ressource. Si la région du Storage Mover connaît une panne, les opérations de gestion exécutées par l’agent et reposant sur Azure peuvent ne pas aboutir. En outre, toutes les migrations de données actives vers des comptes de stockage situés dans la région affectée peuvent échouer.

Si votre Storage Mover se trouve dans une région Azure disposant d’une région jumelée, ses métadonnées de configuration sont répliquées vers la région Azure associée à des fins de reprise d’activité après sinistre, et Microsoft peut déclencher un basculement vers cette région associée en cas de sinistre affectant votre région principale.

Si votre Storage Mover se trouve dans une région non appairée, Microsoft ne réplique pas les métadonnées de configuration et aucun mécanisme de basculement vers une autre région n'est intégré. Toutefois, vous pouvez déployer des ressources distinctes dans plusieurs régions. Dans ce cas de figure, il vous incombe de gérer la réplication, la distribution du trafic et le basculement. Si vous utilisez une région non appairée, ou si la réplication intégrée des métadonnées ne répond pas à vos besoins, vous pouvez créer une stratégie personnalisée de basculement multirégion.

Note

Vous êtes responsable de la récupération d'urgence pour vos sources de données (y compris les sources de données Azure et les sources de données locales), les cibles et les agents.

Basculement vers une région appairée géré par Microsoft

Si votre ressource Storage Mover se trouve dans une région qui est associée à une autre région, Microsoft réplique les métadonnées de configuration de votre mover de stockage dans la région jumelée.

Diagramme montrant un Storage Mover répliquant ses métadonnées vers une région appairée.

En cas de panne de région, Microsoft peut effectuer un basculement vers la région jumelée à l’aide des métadonnées de configuration répliquées. Ce processus est une option par défaut et ne nécessite aucune intervention de vous.

Diagramme montrant le basculement d'un Storage Mover vers une région appairée.

Le basculement des ressources Storage Mover peut se produire à un moment différent de celui du basculement d'autres services Azure.

Important

Microsoft est peu susceptible de lancer un basculement avant un délai important, et celui-ci est effectué selon le principe du best effort. Si vous devez respecter des délais spécifiques pour la récupération de Storage Mover ou si le comportement de réplication et de basculement par défaut ne répond pas à vos besoins, utilisez des solutions multirégions personnalisées pour la résilience pour planifier et lancer votre propre basculement.

La réplication interrégion s’applique uniquement aux métadonnées de configuration. Elle ne s’applique pas aux données sources ou au compte de stockage cible, qui a ses propres options de fiabilité et de réplication. Pour plus d’informations, consultez Fiabilité dans Stockage Blob Azure et fiabilité dans Azure Files.

Exigences

Prise en charge des régions : la réplication interrégion gérée par Microsoft est disponible uniquement pour les ressources Storage Mover que vous déployez dans une région disposant d’une région jumelée. Pour les ressources situées dans des régions non appairées, aucune réplication ni aucun basculement interrégion ne sont fournis. Pour obtenir une résilience interrégion dans des régions non souhaitées, utilisez une solution multirégion personnalisée.

Coûts

Storage Mover ne vous facture pas la réplication interrégion gérée par Microsoft de la configuration de votre instance Storage Mover. Toutefois, il peut y avoir une petite charge pour la réplication interrégion. Pour plus d’informations, consultez Tarification de la bande passante.

Configurer la prise en charge multirégion

la réplication interrégion gérée par Microsoft est automatiquement activée pour les ressources storage Mover dans des régions jumelées. Vous n’avez rien à configurer et vous ne pouvez pas choisir d’activer ce comportement.

Comportement lorsque toutes les régions sont saines

Cette section décrit le comportement attendu lorsqu'un Storage Mover est configuré pour la réplication et le basculement interrégion, et que la région primaire est opérationnelle.

  • Opération interrégion : Votre ressource Storage Mover dans la région primaire répond à toutes les demandes. La région jumelée est utilisée uniquement en cas de basculement initié par Microsoft.

  • Réplication des données interrégions : La région primaire réplique la configuration de manière asynchrone vers la région jumelée. Étant donné que la réplication est asynchrone, les modifications récentes apportées à la configuration peuvent ne pas être reflétées dans la région jumelée au moment d’un échec.

Comportement lors d’une défaillance de région

Cette section décrit à quoi s’attendre lorsqu’un agent de transfert de stockage est configuré pour la réplication et le basculement inter-régions, et qu’une panne survient dans la région primaire.

  • Détection et réponse : Microsoft détecte les défaillances régionales et détermine s’il convient d’initier un basculement. Microsoft est peu susceptible de lancer un basculement avant un délai important, et le basculement est effectué selon le principe du best effort.

  • Notification : Microsoft ne vous avertit pas automatiquement lorsqu’une région est en panne. Toutefois:

  • Demandes actives : Les demandes de gestion actives sont supprimées et doivent être retentées une fois le basculement terminé. Les travaux de migration de données actifs exécutés sur des agents peuvent échouer s’ils dépendent de la région qui rencontre la panne.

  • Perte de données attendue : Étant donné que la réplication interrégion est asynchrone, toutes les modifications de métadonnées de configuration qui ne sont pas répliquées vers la région jumelée au moment de la panne peuvent être perdues.

  • Temps d’arrêt attendu : Un basculement de région peut prendre jusqu’à 24 heures. Pendant cette période, votre Storage Mover est indisponible.

  • Redistribution : Une fois le basculement terminé, Storage Mover commence à exécuter les travaux depuis la région appairée.

    Vous devez toutefois réinscrire les agents auprès du Storage Mover dans la région appairée.

Récupération de région

Lorsque la région primaire d'origine est rétablie, Microsoft coordonne le retour arrière. Vous devez réenregistrer les agents auprès du gestionnaire de stockage dans la région primaire.

Tester les défaillances régionales

La plateforme stockage Azure Mover gère la réplication interrégion, le basculement et la récupération des régions. Étant donné que Microsoft gère entièrement cette fonctionnalité, vous ne pouvez pas lancer ou tester un basculement de région.

Solutions multirégions personnalisées pour la résilience

Si vous devez contrôler le moment où le basculement se produit, ou si vous utilisez une région non appairée tout en ayant besoin que votre Storage Mover résiste aux pannes régionales, déployez des ressources Storage Mover indépendantes dans plusieurs régions Azure. Vous êtes responsable de tous les aspects de cette approche, notamment :

  • Création et gestion de projets équivalents, points de terminaison, agents et définitions de travaux dans chaque région.
  • Détection des défaillances régionales et décision du moment où effectuer le basculement.
  • Rediriger les agents et les travaux de migration vers la région secondaire.
  • Rapprochement de l'état des travaux et de leur historique d'exécution entre les régions.

Une solution multirégion personnalisée convient aussi bien aux régions jumelées qu’aux régions non jumelées, et vous donne un contrôle total sur votre processus de basculement.

Pour plus d’informations, consultez la récupération d’urgence initiée par le client pour stockage Azure Mover.

Sauvegarde et restauration

stockage Azure Mover est un service d’orchestration de migration et de déplacement de données. Il ne stocke pas les données que vous migrez. Le service stocke uniquement les métadonnées de configuration, telles que les projets, les points de terminaison, les définitions de travaux et l’historique des exécutions de travaux. Il n’existe aucune donnée de migration à sauvegarder.

Pour protéger votre configuration Storage Mover, définissez vos ressources à l’aide de l’infrastructure as code, par exemple avec des fichiers Bicep, et stockez ces définitions dans un système de gestion de code source. Si vous devez recréer une ressource, vous pouvez la redéployer à partir de votre configuration stockée.

Pour la plupart des solutions, vous ne devez pas vous appuyer exclusivement sur les sauvegardes. Utilisez plutôt les autres fonctionnalités décrites dans ce guide pour prendre en charge vos exigences de résilience. Toutefois, les sauvegardes protègent contre certains risques que d’autres approches ne le font pas. Pour plus d’informations, consultez Que sont la redondance, la réplication et la sauvegarde ?.

Résilience à la maintenance du service

Microsoft applique régulièrement des mises à jour de service et effectue d’autres maintenances. La plateforme Azure gère automatiquement ces activités, ce qui garantit que la maintenance est fluide et transparente pour vous. Aucun temps d'arrêt n'est prévu pendant les événements de maintenance, sauf si vous avez été informé via la maintenance planifiée d'Azure Service Health.

Les agents Storage Mover sont automatiquement mis à jour.

Contrat de niveau de service

Storage Mover est un service de migration et n’offre pas de contrat de niveau de service de disponibilité (SLA). Toutefois, la documentation de Storage Mover décrit les objectifs de mise à l’échelle et de performances attendus. Ces cibles sont basées sur des migrations simulées et ne sont pas une garantie ou un engagement.

Contenu connexe

  • Last updated on