Sélectionner des régions Azure pour une migration

Article
04/15/2024

Lorsque vous migrez un environnement existant vers Azure, vous devez sélectionner une région Azure ou un ensemble de régions pour héberger les composants migrés. La sélection de zone implique les étapes générales suivantes :

Passez en revue les conseils de sélection de région Azure principale pour comprendre comment sélectionner des régions Azure répondant à vos besoins.
Stockez et documentez l’état actuel de votre environnement.
Implémentez une approche générale de votre migration, notamment si elle doit s’effectuer s’exécuter dans une seule région, utiliser plusieurs zones de disponibilité ou utiliser plusieurs régions.
Évaluez les changements de processus qui peuvent être requis.
Planifiez un processus de migration.
Optimisez et encouragez les changements de processus.

Cet article fournit des conseils sur la façon de choisir des régions Azure répondant à vos besoins de migration. Si ce n’est déjà fait, vous devrez peut-être étendre vos régions de zone d’atterrissage pour prendre en charge les approches multirégions.

Remarque

Cet article traite des considérations spécifiques aux migrations de charge de travail. Vous devez également comprendre les principes généraux de sélection des régions Azure pour n’importe quelle organisation ou charge de travail. Pour plus d’informations, consultez Sélectionner des régions Azure.

Documenter la complexité de votre scénario

Déterminez si votre scénario nécessite une documentation et un alignement des processus. L’approche suivante peut vous aider à évaluer les défis potentiels et à établir un cours d’action général :

Envisagez une implémentation plus robuste de la préparation et de la gouvernance.
Inventoriez les zones géographiques affectées. Dressez la liste des pays et régions affectés.
Documentez la base utilisateur. Les employés, partenaires ou clients dans la région ou le pays identifié seront-ils affectés par la migration vers le cloud ?
Documentez les ressources et centres de données. L’effort de migration inclut-il des ressources dans le pays ou la région identifiés ?
Documentez la disponibilité de la version du produit et les exigences de basculement au niveau régional.
Documentez vos exigences en matière de résilience pour déterminer si les zones de disponibilité sont requises. En règle générale, les exigences en matière de résilience sont prises en compte pour l’ensemble du scénario, et non pour les régions individuelles.
Documentez vos exigences de souveraineté et vos exigences de résidence des données. Les charges de travail qui ont des exigences spécifiques en matière de souveraineté ou de résidence des données peuvent influencer votre choix de régions Azure.

Tout au long du processus de migration, réfléchissez à la manière d’aligner les modifications sur vos différents scénarios et inventaires. La table suivante donne un exemple de la manière de documenter différents scénarios.

Région	Pays/région	Employés locaux	Utilisateurs externes locaux	Ressources ou centres de données locaux	Exigences de souveraineté des données
Amérique du Nord	États-Unis	Oui	Partenaires et clients	Oui	Non
Amérique du Nord	Canada	Non	Clients	Oui	Oui
Europe	Allemagne	Oui	Partenaires et clients	Non - Réseau uniquement	Oui
Asie-Pacifique	Corée du Sud	Oui	Partenaires	Oui	No

Pourquoi l’emplacement des utilisateurs est-il important ?

Les organisations qui prennent en charge des utilisateurs dans plusieurs pays ou régions développent des solutions techniques qui traitent le trafic des utilisateurs. Dans certains cas, les solutions impliquent la localisation des ressources. Dans d’autres scénarios, l’organisation peut choisir de mettre en œuvre des solutions de réseau étendu globales pour gérer des bases d’utilisateurs disparates par le biais de solutions axées sur le réseau. Dans les deux cas, les profils d’utilisation d’utilisateurs disparates peuvent affecter la stratégie de migration.

Par exemple, si une organisation prend en charge les employés, les partenaires et les clients en Allemagne, mais ne dispose pas actuellement de centres de données dans ce pays, elle implémente probablement une solution de ligne allouée. Ce type de solution route le trafic vers les centres de données dans d’autres pays ou régions. Ce routage existant présente un risque significatif pour les performances perçues des applications migrées. L’injection de sauts supplémentaires dans un WAN global établi et réglé peut créer la perception d’applications sous-performantes après la migration. La recherche et la résolution de ces problèmes peuvent entraîner des retards importants pour un projet.

Chacune des sections suivantes comprend des conseils sur la façon de résoudre cette complexité dans les prérequis et les processus d’évaluation, de migration et d’optimisation. Il est essentiel de comprendre les profils utilisateur dans chaque pays ou région pour gérer correctement cette complexité.

Pourquoi l’emplacement des centres de données est-il pertinent ?

L’emplacement des centres de données existants peut affecter une stratégie de migration. Considérons les facteurs suivants :

Décisions d’architecture : la définition de la région cible est l’une des premières étapes de la conception d’une stratégie de migration. L’emplacement des ressources existantes influence souvent cette détermination. En outre, la disponibilité des services cloud et le coût unitaire de ces services peuvent varier d’une région à l’autre. Les exigences de résidence des données, y compris les exigences de souveraineté, peuvent également influencer la décision d’architecture. La compréhension de l’emplacement des ressources actuelles et futures affecte les décisions d’architecture et peut influer sur les estimations de budget.

Dépendances des centres de données : les exemples de scénarios dans le tableau de la section Documenter la complexité montrent que vous devez probablement planifier les dépendances entre les différents centres de données mondiaux. Les organisations qui opèrent à cette échelle peuvent ne pas documenter ou comprendre clairement ces dépendances. L’approche qu’utilise votre organisation pour évaluer les profils utilisateur vous aide à identifier certaines de ces dépendances au sein de votre organisation. Votre équipe doit également explorer des étapes d’évaluation supplémentaires pouvant atténuer les risques et les complexités liés aux dépendances.

Implémenter une approche générale

L’approche suivante utilise un modèle piloté par les données pour répondre aux complexités de la migration globale. Si l’étendue d’une migration comprend plusieurs régions, l’équipe d’adoption cloud doit évaluer les considérations suivantes relatives à la disponibilité :

Déterminer si vous pouvez répondre aux exigences de votre entreprise : utilisez plusieurs zones de disponibilité pour déterminer les exigences en matière de haute disponibilité, de résilience, de performances et de coûts. Si ces exigences ne sont pas remplies, déterminez si vous avez besoin d’une approche multirégion.
Évaluer la souveraineté des données : la souveraineté des données peut nécessiter la localisation de certaines ressources, mais il existe de nombreuses ressources qui ne sont pas régies par ces contraintes de conformité. Des services tels que la journalisation, la création de rapports, le routage réseau, l’identité et d’autres services informatiques centraux peuvent être admissibles pour être hébergés en tant que services partagés sur plusieurs abonnements ou régions. Évaluez la souveraineté des données à l’aide d’un modèle de service partagé pour ces services. Pour obtenir un aperçu de cette approche, consultez l’architecture de référence d’une topologie hub-and-spoke avec des services partagés.
S’assurer de la mise à l’échelle de l’environnement : si vous déployez plusieurs instances d’environnements similaires, vous pouvez mettre en place une équipe dédiée pour les migrations de l’environnement afin de créer la cohérence, d’améliorer la gouvernance et d’accélérer le déploiement. Le guide de gouvernance pour les entreprises complexes établit une approche qui crée un environnement qui évolue dans plusieurs régions.

Prérequis pilotés par les données

Une fois que votre équipe est à l’aise avec l’approche de référence et que la préparation est alignée, tenez compte de ces prérequis pilotés par les données :

Effectuer une découverte générale : remplissez le tableau dans Documenter la complexité pour évaluer la complexité de votre stratégie d’adoption du cloud.
Analyser le profil des utilisateurs pour chaque pays ou région affecté : il est important de comprendre le routage général des utilisateurs au début du processus de migration. La modification des lignes d’emprunt globales et l’ajout de connexions comme Azure ExpressRoute à un centre de données cloud peut entraîner des mois de retards réseau. Abordez le routage des utilisateurs aussi tôt que possible dans le processus.
Effectuer une rationalisation initiale du patrimoine numérique : si vous introduisez un certain degré de complexité dans une stratégie de migration, effectuez une rationalisation initiale de l’infrastructure numérique. Pour plus d’informations, consultez Qu’est-ce qu’un patrimoine numérique ?.
Utiliser des étiquettes pour les exigences relatives au patrimoine numérique : établissez des stratégies d’étiquetage pour identifier les charges de travail affectées par les exigences de souveraineté des données. Assurez-vous que les balises requises commencent par la rationalisation de l’infrastructure numérique et traversent les ressources migrées.
Évaluer un modèle hub-and-spoke : les systèmes distribués partagent souvent des dépendances communes. Vous pouvez souvent résoudre les dépendances partagées en implémentant un modèle hub-and-spoke. Bien que l’implémentation d’un modèle hub-and-spoke n’entre pas dans le cadre du processus de migration, marquez le modèle pour en tenir compte lors des itérations futures des processus de préparation.
Définir la priorité du backlog de migration : si vous avez besoin de modifier le réseau pour prendre en charge le déploiement de production d’une charge de travail qui prend en charge plusieurs régions, l’équipe de stratégie cloud doit effectuer le suivi et la gestion des escalades résultant des modifications du réseau. Ce niveau le plus élevé du support exécutif contribue à accélérer le changement en permettant à l’équipe de stratégie de modifier les priorités du backlog et de s’assurer que les modifications du réseau ne bloquent pas les charges de travail globales. Les charges de travail globales ne doivent être classées par ordre de priorité qu’au terme des modifications du réseau.

Ces prérequis vous aident à établir des processus qui peuvent résoudre la complexité durant l’exécution de la stratégie de migration.

Évaluer les changements de processus

Si votre scénario de migration implique des ressources globales et des bases d’utilisateurs complexes, ajoutez des activités clés pour évaluer vos candidats à la migration. Ces activités produisent des données qui vous aident à clarifier les obstacles et les issues pour les utilisateurs et les ressources globaux.

Actions suggérées pendant le processus d’évaluation

Évaluer les dépendances entre les centres de données : les outils d’analyse des dépendances d’Azure Migrate peuvent vous aider à identifier les dépendances. Utilisez ces outils avant de commencer la migration. Si votre scénario implique une complexité globale, l’évaluation des dépendances est une étape nécessaire dans le processus d’évaluation. Vous pouvez utiliser le regroupement des dépendances pour visualiser les dépendances et identifier les adresses IP et les ports des ressources requises pour prendre en charge la charge de travail.

Important

Vous avez besoin d’un expert technique (SME) qui comprenne le placement des ressources et des schémas d’adresses IP pour identifier les ressources qui se trouvent dans un centre de données secondaire.
Évaluez les dépendances et les clients en aval dans la visualisation pour comprendre les dépendances bidirectionnelles.

Identifier l’impact global sur les utilisateurs : la sortie de l’analyse du profil utilisateur prérequise doit identifier toute charge de travail affectée par les profils utilisateur globaux. Si un candidat à la migration se trouve dans la liste des charges de travail concernées, l’architecte de la migration doit consulter des experts en réseaux et opérations. Ces experts aident à valider les attentes en matière de routage et de performances du réseau. Au minimum, l’architecture doit comprendre une connexion ExpressRoute entre le centre d’opérations réseau le plus proche et Azure. L’architecture de référence pour les connexions ExpressRoute peut faciliter la configuration des connexions réseau nécessaires.

Concevoir pour la conformité : la sortie de l’analyse du profil utilisateur prérequise doit également identifier toute charge de travail affectée par les exigences de souveraineté des données. Pendant les activités d’architecture du processus d’évaluation, l’architecte affecté doit consulter des experts en matière de conformité. Ces experts peuvent aider l’architecte à comprendre les exigences en matière de migration et de déploiement dans plusieurs régions. Ces exigences ont un impact important sur les stratégies de conception. Les architectures de référence suivantes peuvent aider à la conception :

Avertissement

Si vous utilisez l’architecture de référence pour ExpressRoute ou les architectures de référence pour les applications, il peut être nécessaire d’exclure des éléments de données spécifiques des processus de réplication pour respecter les exigences de souveraineté des données. La tâche d’exclusion d’éléments de données spécifiques ajoute une étape au processus de promotion.

Modifications du processus de migration

Si vous migrez une application qui doit être déployée dans plusieurs régions, l’équipe d’adoption du cloud doit tenir compte de quelques considérations supplémentaires. La conception des coffres Azure Site Recovery et des serveurs de configuration et de processus sont deux de ces considérations. La conception de la bande passante du réseau et la synchronisation de données sont deux autres considérations.

Actions suggérées pendant le processus de migration

Conception du coffre Site Recovery : Site Recovery est l’outil suggéré pour la réplication native dans le cloud et la synchronisation des ressources numériques sur Azure. La récupération de site réplique les données relatives à chaque ressource dans un coffre de récupération de site. Ce coffre est lié à un abonnement spécifique dans une région et un centre de données Azure spécifique. Si vous répliquez des ressources dans une autre région, un deuxième coffre de récupération de site peut également vous être nécessaire.

Conception du serveur de configuration et de traitement : la récupération de site fonctionne avec une instance locale d’un serveur de configuration et de traitement, qui est liée à un seul coffre de récupération de site. Quand vous utilisez cette configuration, vous devez peut-être installer une deuxième instance de ces serveurs dans le centre de données source pour faciliter la réplication.

Conception de la bande passante réseau : pendant la réplication et la synchronisation continue, vous déplacez les données binaires sur le réseau du centre de données source vers le coffre de récupération de site dans le centre de données Azure cible. Le processus de réplication et de synchronisation consomme de la bande passante. La duplication de la charge de travail dans une deuxième région double la quantité de bande passante consommée.

Dans certains scénarios, la bande passante est limitée. Dans d’autres, une charge de travail implique une configuration ou une dérive de données substantielle. Dans ce cas, la réplication de données vers une deuxième région peut interférer avec le temps nécessaire pour terminer la migration. Plus important encore, ces contraintes peuvent nuire à l’expérience des utilisateurs ou des applications qui dépendent toujours de la bande passante disponible dans le centre de données source.

Synchronisation de données : souvent, le plus gros drainage de la bande passante provient de la synchronisation de la plateforme de données. Si vous déployez dans plusieurs zones de disponibilité, vous pouvez utiliser des services de données redondants interzones qui synchronisent automatiquement vos données entre plusieurs zones de disponibilité. Le déploiement dans plusieurs régions nécessite souvent la synchronisation de données pour maintenir l’alignement des applications. Cette approche est définie dans les architectures de référence pour les applications web multirégions et les applications multirégions multiniveaux.

Si la synchronisation des applications est l’état opérationnel que vous souhaitez pour vos applications, vous pouvez synchroniser la plateforme de données source avec chaque plateforme cloud. Effectuez cette synchronisation avant de migrer les ressources d’application et de niveau intermédiaire.

Reprise d’urgence d’Azure vers Azure : une autre option peut encore réduire la complexité. Si vous utilisez un déploiement en deux étapes pour répondre aux besoins de chronologie et de synchronisation de données, la récupération d’urgence Azure vers Azure peut être une solution acceptable. Dans ce scénario, vous migrez la charge de travail vers le premier centre de données Azure à l’aide d’un seul coffre de récupération de site et d’une conception de serveur de configuration et de traitement. Après avoir testé la charge de travail, vous pouvez la récupérer dans un deuxième centre de données Azure à partir des ressources migrées.

Cette approche réduit l’effet sur les ressources dans le centre de données source. La récupération d’urgence Azure à Azure tire également parti des vitesses de transfert rapides et des limites de bande passante élevées entre les centres de données Azure.

Remarque

L’approche de récupération d’urgence Azure vers Azure peut augmenter les coûts de migration à long terme en raison de frais de bande passante en sortie supplémentaires.

Modifications du processus de mise en production

Quand vous traitez la complexité globale pendant l’optimisation et la promotion, vous devrez peut-être déployer des efforts identiques dans toutes les régions où vous déployez. Si vous utilisez une seule région, il se peut que vous deviez répliquer les tests métier et les plans de changement métier.

Actions suggérées pendant le processus de mise en production

Optimisation prétest : les tests d’automatisation initiaux peuvent identifier des opportunités d’optimisation potentielles, comme avec tout effort de migration. Pour les charges de travail globales, testez indépendamment la charge de travail dans chaque région. Des modifications mineures de la configuration du réseau ou du centre de données Azure choisi peuvent affecter les performances.

Plan de changement métier : créez un plan de changement métier pour tout scénario de migration complexe. Un plan de changement métier garantit une communication claire en ce qui concerne les modifications apportées aux processus d’entreprise et aux expériences utilisateur. Le plan permet également de garantir une communication claire sur le calendrier des efforts nécessaires à l’intégration des changements. Dans le cadre d’un effort de migration global, le plan doit inclure des considérations pour les utilisateurs dans chaque zone géographique affectée.

Test d’entreprise : chaque région peut également nécessiter des tests métier. Ces tests permettent de garantir des performances adéquates et le respect des modèles de routage réseau modifiés.

Versions d’évaluation de promotion : la promotion se produit souvent sous la forme d’une activité unique, et le trafic de production est immédiatement réacheminé vers les charges de travail migrées. Dans le cadre d’un effort de lancement global, il est recommandé d’effectuer la promotion dans des groupes prédéfinis d’utilisateurs appelés versions d’évaluation. Les versions d’évaluation de promotion donnent à l’équipe de stratégie cloud et à l’équipe d’adoption du cloud de mieux observer les performances et d’améliorer la prise en charge des utilisateurs dans chaque région. Vous pouvez contrôler les volées de promotion au niveau réseau. Plus précisément, vous pouvez modifier le routage des plages d’adresses IP spécifiques entre les ressources de charge de travail source et les ressources nouvellement migrées. Après avoir migré un groupe d’utilisateurs spécifique, vous pouvez réacheminer le groupe suivant.

Optimisation des versions d’évaluation : l’un des avantages des versions d’évaluation de promotion est qu’elles vous permettent d’obtenir des observations plus approfondies et d’optimiser les ressources déployées. Après une courte période d’utilisation de la première version d’évaluation en production, vous pouvez affiner les ressources migrées conformément aux procédures opérationnelles du service informatique.