Partager via


Migrer une charge de travail cloud vers une autre région

L’étape Migrer de la relocalisation est le moment où vous déplacez la charge de travail vers la nouvelle région. En fonction de votre charge de travail, vous pouvez avoir quelques exigences techniques à préparer, mais la stratégie de relocalisation de la charge de travail doit être claire. Vous devez être prêt à exécuter la relocalisation.

Diagram showing the relocation process and highlights the Migrate step in the Move phase. In the relocation process, there are two phases and five steps. The first phase is the Initiate phase, and it has one step called Initiate. The second phase is the Move phase, and it has four steps that you repeat for each workload. The steps are Evaluate, Select, Migrate, and Cutover.

Préparer

Avant de commencer la relocalisation de la charge de travail, vous devez préparer la région cible. Si nécessaire, suivez ces étapes pour préparer votre environnement de charge de travail avant la relocalisation. Ceci vous garantit de disposer d’un réseau régional de base, comme un hub régional et si nécessaire, d’une connectivité intersite.

Établissez une zone d'atterrissage. Lorsque vous planifiez votre déménagement, évaluez s'il élargit la portée de votre zone d'atterrissage Azure. Si une extension est nécessaire, il convient de consulter les orientations relatives à la zone d'atterrissage d'Azure en tant qu'étape fondamentale. Cette étape permet de s'assurer que votre approche est conforme aux meilleures pratiques établies. Pour plus d’informations, consultez Ajouter une nouvelle région à une zone d’atterrissage Azure existante. Les éléments importants à prendre en compte pour la mise en place de votre nouvelle zone d'atterrissage sont les suivants :

  • Mise en réseau : évaluez la structure du réseau, les voies d'acheminement et les exigences de connectivité pour la zone d'atterrissage dans la nouvelle région.
  • Intégration : déterminez s'il est nécessaire d'intégrer la nouvelle zone d'atterrissage à celle de votre région source.
  • Réaffectation sélective des ressources : déterminez si toutes les ressources se déplacent vers la nouvelle région. Si certaines ressources restent sur le site d'origine, prévoyez une topologie de réseau interrégionale durable pour gérer efficacement ces ressources distribuées.

Créez de nouveaux abonnements seulement si c’est nécessaire. Créez des abonnements seulement si vous devez restructurer les services et les ressources impliqués. Essayez de conserver la charge de travail dans son abonnement existant si possible, car la création d'un nouvel abonnement ajoute de la complexité. Les abonnements servent de limites pour les budgets, les stratégies et les contrôles d’accès en fonction du rôle (RBAC). Pour tout nouvel abonnement, vous devez valider les budgets, les stratégies et les contrôles d’accès en fonction du rôle. Si vous ne déplacez pas toutes les ressources d’un abonnement, vous devez re définir l’étendue des stratégies d’identité et de sécurité pour qu’elles correspondent au regroupement de taille inférieure des ressources. Pour créer un abonnement, vous devez créer, délimiter et implémenter les stratégies Azure et les rôles RBAC nécessaires dans l’abonnement cible. L’objectif est de maintenir la posture de gouvernance et de sécurité.

Configurez un nouveau nom de domaine si nécessaire. Quand il y a un changement dans le domaine personnalisé de la charge de travail, vous devez configurer un nouveau nom de domaine. Créez le nouveau nom d’hôte, affectez-le à votre application ou à votre service, puis vérifier la résolution du nom. Vous pouvez aussi prévoir de réduire et de configurer la durée de vie, et de la définir dans l’étape de basculement pour qu’elle expire automatiquement. Pour plus d’informations, consultez Ajouter votre domaine personnalisé et Mapper un nom DNS à un plan App Service.

Créez des certificats SSL/TLS si nécessaire. Vous devez créer de nouveaux certificats SSL/TLS (X.509) pour tout nouveau nom de domaine. Ces certificats permettent le chiffrement par clé publique-privée et sécurisent la communication réseau (HTTPS). Utilisez Azure Key Vault pour créer ou importer des certificats X.509. Pour plus d’informations, consultez Certificats Azure Key Vault et Méthodes de création de certificats

Relocalisez Azure Key Vault. Vous devez relocaliser Azure Key Vault avant de déplacer votre charge de travail. Vous devez avoir un coffre de clés par environnement d’application, et votre coffre de clés ne doit pas partager de secrets entre les régions, de façon à garantir la confidentialité. Vous devrez peut-être créer un coffre de clés dans la nouvelle région cible pour vous aligner sur ces conseils.

Créez un nouvel espace de travail Log Analytics. Vous devez disposer d'un espace de travail Log Analytics distinct pour chaque région. Créer un nouvel espace de travail dans la région cible. Comme il n'est pas possible de déplacer un espace de travail Log Analytics vers une autre région, vous devez créer un nouvel espace de travail Log Analytics dans la région cible. Deux options permettent de préserver les données dans l'espace de travail d'origine. Vous pouvez conserver l'espace de travail actuel jusqu'à ce que vous n'ayez plus besoin des données, en les traitant en lecture seule. Vous pouvez également exporter les données de l'espace de travail vers un compte de stockage dans la nouvelle région Azure cible.

Migrer des services

Vous pouvez commencer la migration des services dans votre charge de travail. Pour effectuer cela, suivez les conseils disponibles pour l’automatisation de la relocalisation que vous avez sélectionnée. Azure Resource Mover et Azure Site Recovery ont des tutoriels pas à pas à suivre pour la relocalisation des services. Pour plus d’informations, consultez l’article suivant :

Vous pouvez créer des modèles ou des scripts d'infrastructure en tant que code pour les ressources que vous ne pouvez pas déplacer. Vous pouvez également exécuter les déploiements manuellement dans le portail Azure. Les étapes à suivre dépendent des services Azure que vous utilisez et de leur configuration. Pour plus d’informations, consultez Vue d’ensemble de l’infrastructure en tant que code (IaC).

Migration des données

Cette étape est pertinente seulement quand la charge de travail nécessite une migration de données. Effectuez la migration des données avec l’automatisation choisie. Avant le basculement vers la charge de travail dans la région cible, vous devez vérifier que les données associées sont synchronisées avec la région source. La cohérence des données est un aspect important qui nécessite de l’attention. Voici des conseils à suivre pour migrer les données des charges de travail.

  1. Migrez les données de la région source. L’approche de la migration des données de la région source doit suivre la méthode de relocalisation pour le service de la charge de travail. Les méthodes dites « à chaud », « à froid » et « tièdes » ont des processus différents pour gérer les données dans la région source.

  2. Synchronisez les données. La technique de synchronisation dépend de l’architecture de la charge de travail et de la demande de l’application. Par exemple, dans une synchronisation à la demande, les modifications sont extraites lorsque les données sont consultées pour la première fois. L’extraction et la fusion des modifications se produisent seulement dans les cas où il existe une différence entre le dernier accès et l’accès en cours de l’application.

  3. Résolvez les conflits de synchronisation. Vérifiez que les données dans l’emplacement source et l’emplacement cible sont synchronisées et résolvez les éventuels conflits des données. Vous voulez que les utilisateurs essaient d’accéder seulement aux données disponibles. Par exemple, Azure Cosmos DB peut sérialiser des écritures concurrentes pour garantir la cohérence des données.

Mettre à jour les chaînes de connexion

La configuration de la chaîne de connexion dépend du service auquel l’application se connecte. Vous pouvez rechercher « chaîne de connexion » dans notre page de documentation pour trouver des conseils spécifiques au service et les utiliser pour mettre à jour la chaîne de connexion. Pour plus d’informations, consultez la documentation technique.

Identités managées

Les identités managées affectées par le système ont un cycle de vie lié à la ressource Azure. La stratégie de relocalisation de la ressource Azure détermine donc la façon dont l’identité managée affectée par le système est gérée. Si une nouvelle instance de la ressource est créée dans la cible, vous devez accorder à la nouvelle identité managée affectée par le système les mêmes autorisations que l’identité managée affectée par le système dans la région source.

Par contre, l’identité managée affectée par l’utilisateur a un cycle de vie indépendant et vous pouvez mapper l’identité managée affectée par l’utilisateur à la nouvelle ressource dans la région cible. Pour plus d’informations, consultez Vue d’ensemble des identités managées.

Étapes suivantes

Vous avez migré les services et les données de votre charge de travail. Vous devez maintenant terminer la relocalisation avec un basculement.