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

Article
12/18/2023

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.

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.

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 ».

Sauvegardez les données de la charge de travail dans la nouvelle région cible.
Placez la région source hors connexion et arrêtez les services.
Déployez les services cloud sur la nouvelle région cible.
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 ».

Effectuez la réplication des services dans la nouvelle région cible.
Maintenez la charge de travail en cours d’exécution dans la région source.
Démarrez la réplication synchrone des données.
Une fois les données synchronisées, activez et vérifiez les points de terminaison.
Arrêtez la synchronisation des données.
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 ».

Effectuez la réplication des services dans la nouvelle région cible.
Maintenez la charge de travail en cours d’exécution dans la région source.
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.
Restaurez les données dans la nouvelle région cible.
Basculez et vérifiez les points de terminaison.
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 trois approches principales de la relocalisation des services. Les paragraphes qui suivent donnent une vue d’ensemble de chacune d’entre elles, avec des liens vers d’autres conseils. Si vous utilisez l’automatisation de l’infrastructure en tant que code (IaC) pour déplacer la charge de travail, vous devez trouver une approche de relocalisation des données distincte. Vous devez passer en revue les fonctionnalités de chaque outil de relocalisation des services et sélectionner l’outil qui répond le mieux à vos besoins.

Azure Resource Mover : Azure Resource Mover est un service Azure intégré qui vous permet de déplacer des ressources Azure entre des régions, des abonnements et des groupes de ressources. Azure Resource Mover peut déplacer les ressources Azure prises en charge avec leurs dépendances en analysant et en préparant les ressources avant le déplacement. Pour en savoir plus, consultez Vue d’ensemble d’Azure Resource Mover.

Azure Site Recovery : Azure Site Recovery peut répliquer n’importe quelle application s’exécutant sur une machine virtuelle prise en charge dans Azure. C’est un outil de reprise d’activité par conception, mais vous pouvez également l’utiliser pour relocaliser des charges de travail. Site Recovery utilise un coffre Recovery Services comme le fait Sauvegarde Azure et peut déplacer des services rapidement. Il nécessite quelques étapes de nettoyage après le déplacement, car c’est un outil de reprise d’activité. Pour plus d'informations, consultez les pages suivantes :

Infrastructure en tant que code (IaC) : IaC vous permet de copier et de redéployer des services Azure. Vous pouvez utiliser Azure Resource Manager, Bicep ou des modèles Terraform pour les services de la région source. Vous pouvez déployer le modèle dans la nouvelle région cible avec l'outil IaC de votre choix. Pour les services avec état, vous avez besoin d’un autre outil pour relocaliser les données de la charge de travail. Pour plus d’informations, consultez Vue d’ensemble de l’infrastructure en tant que code (IaC).

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.

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

Si votre automatisation de la relocalisation des services ne déplace pas les données, vous devez également choisir une automatisation de la relocalisation des données. Pour la relocalisation des données, vous devez avoir le 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 relocalisation pour avoir une idée de la séquence. Voici une liste d’outils d’automatisation que vous pouvez utiliser pour relocaliser les données. La liste commence par les outils de relocalisation « à chaud » et se termine par les outils « à froid ». Ce n’est pas un ordre lié à la préférence. Évaluez chaque outil d’automatisation et choisissez celui qui convient à votre charge de travail.

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 Data Sync dans 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 les stratégies de relocalisation « à froid » et « à chaud ». 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.

Migrer

Share via