Déplacer des ressources Azure entre les régions

Microsoft Entra
Azure ExpressRoute
Azure Load Balancer
Passerelle VPN Azure

Cette solution déplace les ressources Azure entre les régions de manière efficace, sécurisée et transparente. Consultez les étapes clés, les considérations et les stratégies de planification et de réalisation d’un déplacement.

Architecture

Diagramme montrant le flux de données des ressources Azure qui se déplacent à travers la solution de régions.

Téléchargez un fichier Visio de cette architecture.

Dataflow

  • Réseau du centre de données local : Un réseau local privé qui s’exécute au sein d’une organisation pour prendre en charge les ressources locales.

  • Circuit ExpressRoute : Les connexions ExpressRoute utilisent une connexion privée et dédiée via un fournisseur de connectivité tiers. La connexion privée étend un réseau local à Azure.

  • Routeurs de périphérie locaux : Les routeurs qui connectent le réseau local au circuit géré par le fournisseur tiers. Selon la méthode d’approvisionnement de votre connexion, vous devrez peut-être fournir les adresses IP publiques utilisées par les routeurs.

  • Routeurs Microsoft Edge : Avec deux routeurs, vous disposez d’une configuration hautement disponible en mode actif-actif. Ces routeurs permettent à un fournisseur de connectivité tiers de connecter ses circuits directement à son centre de données. Selon la méthode d’approvisionnement de votre connexion, vous devrez peut-être fournir les adresses IP publiques utilisées par les routeurs.

  • Passerelle VPN : Grâce au service de passerelle VPN, vous pouvez connecter le réseau virtuel au réseau local.

  • Sous-réseau Active Directory : La plupart des organisations incluent un environnement Active Directory Domain Services (AD DS) dans leur centre de données local. Pour simplifier la gestion des ressources déplacées vers Azure à partir de votre réseau local qui dépend d’AD DS, envisagez d’héberger des contrôleurs de domaine AD DS dans Azure dans un hub de réseau virtuel (VNET) central auquel les charges de travail dépendantes peuvent accéder.

  • VNET Peering : Plusieurs réseaux virtuels avec Peering entre eux. Le Peering de réseaux virtuels permet d’obtenir des applications de groupe dans des réseaux virtuels respectifs, et fournit une connexion à bande passante élevée et à faible latence.

  • Applications web multicouches s’exécutant dans l’environnement cloud : Cet exemple d’architecture s’applique à de nombreux secteurs qui ont besoin de déployer des applications multicouches résilientes dans le cloud. Dans ce scénario, l’application se compose de trois couches :

    • Couche web : couche supérieure comprenant l’interface utilisateur. Cette couche analyse les interactions utilisateur et transmet les actions à la couche suivante pour le traitement.
    • Couche entreprise ou application : traite les interactions utilisateur et prend des décisions logiques concernant les étapes suivantes. Cette couche relie la couche web et la couche données.
    • Couche données : stocke les données d’application. Dans ce cas, une base de données SQL stocke les données.

  • Équilibreur de charge interne : Le trafic réseau de la passerelle VPN est acheminé vers l’application cloud via un point de terminaison d’équilibreur de charge interne (ILB) qui se trouve dans le sous-réseau de couche application.

  • Ressources Platform as a Service (PaaS) : Dans cet exemple d’environnement, il existe quelques services PaaS tels que le hub IoT Azure, Azure Key Vault et Azure App Service.

Composants

L’exemple d’architecture utilise les composants suivants :

Détails du scénario

Avec la croissance de Microsoft Azure et de son ensemble évolutif de régions dans le monde entier, les clients ont besoin de déplacer des déploiements d’une région à une autre. Le déplacement d’applications entre les régions est une activité qui requiert un plan bien pensé pour vous assurer de déplacer toutes les ressources en toute transparence, et que les applications sont opérationnelles dans la nouvelle région avec un temps d’arrêt minimal.

Les suggestions et l’architecture dans cet exemple fournissent des conseils de déplacement efficace, en toute sécurité et en toute transparence des ressources Azure entre les régions.

Cas d’usage potentiels

Parmi les raisons principales de déplacement de ressources vers une autre région, citons les cas suivants :

  • Aligner sur un lancement d’une région : Déplacer des ressources vers une région Azure récemment introduite qui n’était pas disponible auparavant.
  • Aligner en raison des services ou de fonctionnalités : Déplacer des ressources pour profiter des services ou fonctionnalités qui sont disponibles dans une région spécifique.
  • Répondre au développement de l’activité : Déplacer des ressources vers une région en réponse à des changements de l’activité, comme des fusions ou des acquisitions.
  • Aligner pour cause de proximité : Déplacer des ressources vers une région proche de votre entreprise.

Étapes pour déplacer des ressources entre les régions

Étant donné que vos exigences peuvent être différentes de celles de l’exemple d’architecture, utilisez les suggestions suivantes comme point de départ :

  1. Vérifiez les prérequis pour le déplacement

    • Temps d’arrêt planifié : Planifiez le déplacement de la région en tant qu’activité de maintenance avec un temps d’arrêt planifié pour réduire l’impact sur le client.

    • Quotas et limites d’abonnement Azure : Assurez-vous que votre abonnement dispose de suffisamment de ressources pour prendre en charge le type de ressource spécifique. Par exemple, assurez-vous que la région cible prend en charge les machines virtuelles dont la taille correspond aux machines virtuelles de votre région source. Contactez le support pour activer le quota nécessaire au besoin. Pour en savoir plus, consultez Abonnement Azure et les limites, quotas et contraintes des services.

    • Autorisations du compte : Si vous avez créé un compte Azure gratuit, vous êtes l’administrateur de votre abonnement. Si vous n’êtes pas l’administrateur de l’abonnement, collaborez avec l’administrateur pour attribuer les autorisations dont vous avez besoin pour déplacer les ressources. Vérifiez que votre abonnement Azure vous permet de créer la ressource nécessaire dans la région cible.

    • Identification de la ressource : Identifiez et classez vos ressources en fonction du type de ressource nécessaire pour exporter un modèle Azure Resource Manager ou pour démarrer la réplication à l’aide de diverses technologies. Pour chacun des types de ressources que vous souhaitez déplacer, les étapes peuvent être différentes. Reportez-vous à Déplacement des ressources Azure entre les régions pour identifier les étapes correspondantes pour chacun des types de ressources.

  2. Déplacez les composants de la mise en réseau.

    • Groupes de sécurité réseau : Vous ne pouvez pas déplacer des groupes de sécurité réseau d’une région vers une autre. Vous pouvez toutefois utiliser un modèle Resource Manager (ARM) pour exporter la configuration existante et les règles de sécurité d’un groupe de sécurité réseau. Vous pouvez ensuite déplacer la ressource dans une autre région en exportant le groupe vers un modèle, en modifiant les paramètres pour qu’ils correspondent à la région de destination, puis en déployant le modèle dans la nouvelle région.

    • Réseau virtuel : Vous pouvez utiliser un modèle Azure Resource Manager pour terminer la migration du réseau virtuel vers une autre région. Exportez le réseau virtuel vers un modèle, modifiez les paramètres pour qu’ils correspondent à la région de destination, puis déployez le modèle dans la nouvelle région.

    • Appairage de réseaux virtuels : Le Peering de réseaux virtuels n’est pas recréé et les homologues de réseaux virtuels échouent s’ils sont toujours présents dans le modèle. Avant d’exporter le modèle, supprimez les homologues de réseaux virtuels. Vous pouvez les rétablir après le déplacement du réseau virtuel.

    • Adresses IP publiques : Étant donné que les adresses IP publiques Azure sont spécifiques à une région, vous ne pouvez pas les déplacer d’une région à une autre. Vous pouvez toutefois utiliser un modèle Resource Manager (ARM) pour exporter la configuration existante et les règles de sécurité d’un groupe de sécurité réseau. Vous pouvez ensuite déplacer la ressource dans une autre région en exportant le groupe vers un modèle, en modifiant les paramètres pour qu’ils correspondent à la région de destination, puis en déployant le modèle dans la nouvelle région.

  3. Déplacez les composants d’application.

  4. Déplacez les services PaaS : Les services PaaS ont leurs propres étapes spécifiques pour orchestrer le déplacement. Pour obtenir les dernières informations sur la liste des services pris en charge, consultez Prise en charge du déplacement des ressources Azure entre les régions.

  5. Déplacez l’infrastructure locale : Pour vous assurer que la région source complète a été recréée sur la région cible, rétablissez et configurez vos composants locaux tels qu’ils étaient avant et connectez-les au réseau Azure.

Considérations

Ces considérations implémentent les piliers d’Azure Well-Architected Framework qui est un ensemble de principes directeurs qui permettent d’améliorer la qualité d’une charge de travail. Pour plus d’informations, consultez Microsoft Azure Well-Architected Framework.

Tenez compte des points suivants lors de l’établissement d’un déplacement entre régions :

  • Votre plan de migration entre les régions doit prendre en compte l’infrastructure complexe. Les environnements d’infrastructure modernes s’étendent souvent de l’infrastructure locale au cloud. Certains ont même un niveau de complexité supplémentaire, avec une stratégie multicloud contenant des déploiements privés ou publics.

  • Déplacez les types de ressources ensemble. En combinant le déplacement de types de ressources similaires (par exemple, 50 machines virtuelles ou 20 bases de données SQL), vous pouvez planifier plus facilement l’étape de préparation de votre déplacement et vous assurer que les opérations de longue durée s’exécutent ensemble, ce qui permet de réduire les temps d’arrêt.

  • Déplacez toutes les ressources d’une application ensemble. Vous pouvez sélectionner les ressources d’une application et essayer de les déplacer dans un ensemble pour vous assurer de pouvoir afficher l’application sur la région cible de manière orchestrée.

  • Assurez-vous de couvrir vos besoins de capacité. Il est possible de vérifier la capacité ou le quota disponible dans la région cible pour prendre en charge la croissance de l’activité actuelle et potentielle avant le déplacement réel.

  • L’impact sur les applications ou l’infrastructure vitales pour l’entreprise actuelles dans la région source doit être minimal voire nul pendant que le déplacement.

  • Pour veiller à la continuité des activités, vous devez disposer d’un environnement fonctionnel et opérationnel sur la région cible avec le moins de temps d’arrêt possible.

  • La possibilité de valider la migration avant la validation finale côté cible est essentielle, et plus particulièrement si vous prenez en charge des charges de travail de niveau 0 et de niveau 1 dans le secteur des services financiers (FSI) ou les secteurs verticaux des soins de santé.

  • Veillez à faire preuve de diligence raisonnable en testant et en validant les configurations d’origine, la connectivité, la configuration de sécurité appropriée, les stratégies, la réplication des données et les connexions de base de données avant de valider le déplacement vers la région cible.

  • Une fois que vous avez déplacé les ressources vers la cible, vérifiez que la configuration finale est opérationnelle en apportant des modifications finales telles que les suivantes :

    • Modifiez la configuration DNS pour qu’elle pointe vers une nouvelle adresse IP.
    • Supprimez les ressources dans la région source afin d’éviter une double facturation et d’éviter des problèmes en raison de l’existence de deux jeux de données distincts qui se chevauchent dans l’étendue et la configuration.
    • Supprimez toutes les ressources auxiliaires créées pour le déplacement. Par exemple, supprimez tous les comptes de stockage qui ont été utilisés pour le transfert intermédiaire.

Étapes suivantes