Partager via


Sélectionner une stratégie de relocalisation pour les charges de travail cloud

Avant de commencer à migrer la charge de travail vers une autre région, vous devez planifier votre stratégie de relocalisation. La stratégie inclut la méthode de relocalisation, l’automatisation de la relocalisation des services et l’automatisation de la relocalisation des données. Cet article présente les options de chaque composant de la stratégie et vous guide dans la prise de décision. Au final, les sélections que vous effectuez dépendent des services et du caractère critique de la charge de travail.

Diagramme montrant le processus de relocalisation et mettant en évidence l’étape Sélectionner de la phase Déplacer. Dans le processus de relocalisation, il y a deux phases et cinq étapes. La première phase est la phase d’initialisation, et elle comporte une étape appelée Initialisation. La deuxième phase est la phase de déplacement, et elle comporte quatre étapes que vous répétez pour chaque charge de travail. Les étapes sont Évaluer, Sélectionner, Migrer et Basculer.

Sélectionner une méthode de relocalisation

Il existe trois méthodes principales pour relocaliser des charges de travail. La méthode de relocalisation que vous choisissez dépend des services dans la charge de travail et de la mesure dans laquelle la charge de travail est critique pour les fonctions métier essentielles. Vous pouvez envisager des méthodes de relocalisation différentes pour les environnements de production et les environnements hors production. La relocalisation dite « à froid » convient aux charges de travail non essentielles. La relocalisation dite « à chaud » et « tiède » convient aux charges de travail critiques. La méthode de relocalisation que vous choisissez détermine les outils de relocalisation des services et des données que vous utilisez pour relocaliser la charge de travail. Utilisez l’arbre de décision de relocalisation suivant pour avoir une idée générale de la méthode de relocalisation appropriée et validez votre décision en lisant la vue d’ensemble des trois méthodes de relocalisation.

Diagramme montrant un arbre de décision pour la sélection de la méthode de relocalisation appropriée. Il y a deux points essentiels pour la décision. 1. Un temps d’arrêt est-il acceptable ? Si oui, la relocalisation « à froid » est la méthode de relocalisation correcte. 2. Le service prend-il en charge la réplication synchrone des données ? Si oui, la relocalisation « à chaud » est la méthode de relocalisation correcte. Si non, la relocalisation « tiède » est la méthode de relocalisation correcte.

Relocalisation « à froid »

La relocalisation « à froid » convient aux charges de travail qui peuvent s’accommoder d’un temps d’arrêt. C’est l’approche la plus économique pour la relocalisation, car vous ne dupliquez pas d’environnements lors de la relocalisation. Voici une vue d’ensemble du processus de relocalisation « à froid ».

  1. Sauvegardez les données de la charge de travail dans la nouvelle région cible.
  2. Placez la région source hors connexion et arrêtez les services.
  3. Déployez les services cloud sur la nouvelle région cible.
  4. Restaurez les données de la charge de travail.

La relocalisation « à froid » peut prendre quelques minutes ou quelques jours, en fonction du nombre de services et du volume de données.

Relocalisation « à chaud »

La méthode de relocalisation « à chaud » convient aux charges de travail qui nécessitent un temps d’arrêt minimal (en secondes ou en minutes) ou nul. Pour les charges de travail critiques, vous devez voir si le service prend en charge la relocalisation « à chaud » avant d’essayer une approche « tiède ». La relocalisation « à chaud » permet de réduire au minimum le delta des données après le basculement. La relocalisation « à chaud » est possible seulement si le service prend en charge la réplication synchrone des données. Certains services ne disposent pas de cette fonctionnalité, et vous devez utiliser à la place une approche de relocalisation « tiède ». Voici le processus de relocalisation « à chaud ».

  1. Effectuez la réplication des services dans la nouvelle région cible.
  2. Maintenez la charge de travail en cours d’exécution dans la région source.
  3. Démarrez la réplication synchrone des données.
  4. Une fois les données synchronisées, activez et vérifiez les points de terminaison.
  5. Arrêtez la synchronisation des données.
  6. Arrêtez le service dans la région source.

Relocalisation « tiède »

La relocalisation « tiède » convient aux charges de travail critiques qui ne prennent pas en charge la relocalisation « à chaud ». La relocalisation « tiède » utilise la réplication asynchrone des données et la réplication asynchrone de l’environnement. Voici le processus de relocalisation « tiède ».

  1. Effectuez la réplication des services dans la nouvelle région cible.
  2. Maintenez la charge de travail en cours d’exécution dans la région source.
  3. Créez une sauvegarde des données sources. C’est une bonne pratique que de créer la sauvegarde pendant les heures creuses. Vous devez aussi activer la réplication des données entrantes pour synchroniser les données et réduire le delta des données.
  4. Restaurez les données dans la nouvelle région cible.
  5. Basculez et vérifiez les points de terminaison.
  6. Arrêtez la charge de travail dans la région source.

La relocalisation « tiède » peut prendre quelques minutes ou une heure, en fonction du nombre de services et du volume de données.

Sélectionner l’automatisation de la relocalisation des services

Il existe deux méthodes principales d’automatisation du déplacement des services : l’infrastructure en tant que code (IaC) et Azure Resource Mover. Chaque service Azure prend en charge une ou les deux approches d’automatisation. Utilisez le guide de déplacement des services Azure pour connaître la méthode d’automatisation prise en charge par chaque service Azure et les étapes détaillées du déplacement. Voici une vue d’ensemble de l’automatisation utilisée par le guide de déplacement des services :

  • Infrastructure en tant que code (IaC) : IaC peut déplacer chaque service Azure. Exportez le modèle Azure Resource Manager (ARM) (JSON) d’un service Azure existant. Modifiez le modèle si nécessaire et redéployez-le dans une nouvelle région. Vous pouvez convertir des modèles ARM en modèles Bicep en collant le JSON dans Visual Studio Code. Lorsque vous utilisez IaC pour déployer une nouvelle instance d'un service Azure, vous pouvez déployer plusieurs copies de la ressource en parallèle. Avec plusieurs copies, vous pouvez utiliser l'une des techniques de basculement pour rediriger les connexions vers les charges de travail dans la nouvelle région cible. L’infrastructure en tant que code (IaC) ne déplace pas les données. Le déplacement des données nécessite des étapes supplémentaires pour les déplacer vers la nouvelle ressource déployée dans la région cible. Pour plus de détails, consultez le guide d’automatisation du déplacement des données.

  • Azure Resource Mover : Azure Resource Mover vous permet de déplacer un nombre limité de ressources Azure prises en charge avec ses dépendances entre les régions, les abonnements et les groupes de ressources.

Sélectionner l’automatisation de la relocalisation des données

Si vous avez utilisé IaC pour déplacer des services Azure avec état, vous devez utiliser une méthode d’automatisation de déplacement des données pour déplacer vos données. Pour le déplacement des données, vous devez disposer du service en cours d’exécution dans la région cible avant de déplacer les données. Passez en revue les méthodes de déplacement pour avoir une idée de la séquence de déplacement et de la place qu’occupe le déplacement des données. Voici une liste d’outils d’automatisation que vous pouvez utiliser pour déplacer les données :

  • Réplication synchrone des données : la réplication synchrone des données réplique les données en quasi-temps réel entre les régions. C’est l’approche de relocalisation des données préférée pour la relocalisation « à chaud », car elle limite les temps d’arrêt et les migrations delta des données après le basculement. Cette fonctionnalité est intégrée à certains services Azure, comme Synchronisation des données dans la base de données Azure SQL. Vous devez vérifier chaque service de votre charge de travail pour voir s’il prend en charge la réplication synchrone des données.

  • Géoréplication : la géoréplication peut être un outil de relocalisation de données pratique pour les services Azure qui la prennent en charge. La façon dont une fonctionnalité de géoréplication gère les données et l’instance du service sous-jacent varie selon les services Azure pris en charge. Avant d’utiliser la géoréplication pour la relocalisation des données, vous devez comprendre la fonctionnalité de géoréplication du service spécifique que vous relocalisez. Pour obtenir des exemples, consultez Azure SQL et Cosmos DB.

  • Azure Site Recovery : Azure Site Recovery peut relocaliser des services et des données. Il prend en charge le déplacement à chaud et à froid. Pour plus d’informations, consultez Vue d’ensemble d’Azure Site Recovery.

  • AzCopy : AzCopy est un utilitaire en ligne de commande qui automatise les mouvements de données en entrée et en sortie de Stockage Azure. Vous devez télécharger l’outil, puis utiliser Microsoft Entra ID ou des jetons de signature d’accès partagé (SAS) pour autoriser le déplacement. Pour plus d’informations, consultez Vue d’ensemble d’AzCopy et Utiliser AzCopy

  • Pipelines et activités dans Azure Data Factory ou Synapse Analytics : Azure Data Factory est un service d’intégration de données entièrement managé basé sur le cloud, qui orchestre et automatise le déplacement et la transformation des données. Les pipelines Azure Data Factory peuvent déplacer des lacs et des entrepôts de données. L’activité de copie de Synapse Analytics peut également déplacer des données. Pour plus d’informations, consultez Cibles et sources prises en charge et Outil de copie de données.

  • Explorateur Stockage Azure : Explorateur Stockage Azure est une application autonome qui vous permet de relocaliser des données de Stockage Azure. Pour plus d’informations, consultez Comment utiliser Explorateur Stockage.

  • Sauvegarde Azure : avec Sauvegarde Azure, vous pouvez sauvegarder et restaurer des données dans une autre région. Essayez d’abord Sauvegarde Azure pour les relocalisations « à froid » et « tièdes » non essentielles. Sauvegarde Azure fournit des sauvegardes de cohérence des applications, de cohérence des systèmes de fichiers et de cohérence des plantages pour les machines virtuelles. Il prend également en charge les disques managés, les partages de fichiers et les objets blob. Vous ne pouvez pas transférer les points de restauration des sauvegardes existantes vers la nouvelle région cible. Envisagez de conserver le coffre-fort dans votre région source jusqu'à ce que les sauvegardes ne soient plus nécessaires. Pour plus d’informations, consultez Vue d’ensemble du service Sauvegarde Azure.

  • Sauvegarde et restauration manuelles : la sauvegarde et la restauration font ici référence à un processus et non pas à un outil spécifique. De nombreux services dans Azure fournissent des options de redondance qui vous permettent de sauvegarder des données dans une région distincte et de les restaurer manuellement. Vous devez effectuer une sauvegarde et une restauration manuelles pour des services spécifiques, comme Azure Key Vault. Pour plus d’informations, consultez Déplacer Key Vault vers une autre région.

Outil Méthode de relocalisation
Réplication synchrone des données À chaud, Tiède
Géoréplication À chaud, Tiède
Azure Site Recovery Tiède, À froid
AZCopy Tiède, À froid
Pipelines et activités dans Azure Data Factory ou dans un espace de travail Synapse Tiède, À froid
Azure Storage Explorer Tiède, À froid
Azure Backup Froid
Sauvegarde et restauration manuelles Froid

Sélectionner une approche du basculement

Le basculement se produit quand vous passez de l’ancienne charge de travail à la nouvelle. Vous dirigez le trafic vers la charge de travail dans la région cible et non plus vers la région source. Le système de noms de domaine (DNS) est central pour cette redirection. Pour rappel, DNS indique aux navigateurs et aux clients d’API où obtenir une réponse. Il résout les noms de domaine en adresses IP. Chaque domaine a besoin d’un hôte de domaine pour le gérer. Azure DNS est le service hôte du domaine Azure. Il existe différentes approches du basculement d’une charge de travail, et l’approche que vous adopterez dépend des services de votre charge de travail. Voici quelques exemples.

  • Azure DNS : pour les domaines hébergés dans Azure DNS, vous pouvez effectuer un basculement manuel en changeant le CNAME. Cette approche est un processus de basculement de continuité d’activité qui fonctionne pour le basculement. Pour plus d’informations, consultez Basculement manuel en utilisant Azure DNS.

  • Traffic Manager : il est également possible d’utiliser un service de routage comme Traffic Manager pour le basculer et router le trafic d’une charge de travail vers différents points de terminaison. Traffic Manager est un service de routage basé sur DNS. Pour plus d’informations, consultez Configurer des noms DNS avec Traffic Manager.

  • App Service : les services de la couche application, comme Azure App Service, disposent de fonctionnalités qui vous permettent de mettre à jour le nom de domaine. Pour plus d’informations, consultez Migrer un nom DNS actif vers Azure App Service.

  • Routage de passerelle : si la charge de travail utilise le modèle de routage de passerelle avec un service, comme Azure Front Door, Application Gateway ou Gestion des API Azure, vous pouvez souvent effectuer un basculement de migration de région. Vous utilisez leurs cibles back-ends et leurs fonctionnalités de règles de routage.

Étape suivante

Vous avez sélectionné une méthode de relocalisation et les outils pour relocaliser votre charge de travail. Passez à l’étape Migrer pour exécuter la relocalisation en utilisant ces outils.