Scénario : Transition des groupes de gestion vers l'architecture conceptuelle de la zone d'atterrissage Azure

Cet article décrit les considérations et les instructions pour migrer et faire la transition de votre environnement existant vers l’architecture conceptuelle des zones d’atterrissage Azure. Ce scénario couvre un ou plusieurs groupes de gestion.

Dans ce scénario, on suppose que le client utilise déjà Azure. Ils disposent d'une hiérarchie de groupes de gestion avec plusieurs abonnements qui hébergent quelques applications ou services au sein de la plateforme. Mais leur mise en œuvre actuelle limite leur évolutivité et leur croissance liées à leur stratégie cloud first.

Dans le cadre de cette expansion, ils prévoient de migrer de leurs centres de données sur site vers Azure. Au cours de la migration, ils mènent la modernisation et la transformation de leurs applications ou services pour utiliser des technologies cloud natives lorsque cela est possible. Par exemple, il peut utiliser Azure SQL Database et Azure Kubernetes Service (AKS). Ils savent que cela demande beaucoup de temps et d’efforts, c’est pourquoi ils prévoient de se déplacer pour commencer. Initialement, ce plan nécessite une connectivité hybride via des services tels que Azure passerelle VPN ou Azure ExpressRoute.

Le client souhaite déplacer son environnement existant vers l’architecture conceptuelle des zones d’atterrissage Azure. Cette architecture prend en charge leur stratégie cloud first et dispose d'une plate-forme robuste qui évolue à mesure que le client met hors service ses centres de données sur site.

État actuel

Dans ce scénario, l’état actuel de l’environnement Azure du client comprend :

• Un ou plusieurs groupes de gestion.
• Hiérarchie de groupe de gestion basée sur la structure organisationnelle ou la géographie.
• Une souscription Azure pour chaque environnement d'application, comme le développement, les tests ou la production (dev/test/prod).
• Répartition non uniforme des ressources. Les ressources de plateforme et de charge de travail pour un environnement unique sont déployées dans les mêmes abonnements Azure.
• Affectations d’Azure Policy avec effets d’audit et effets de refus attribués au niveau du groupe d’administration et de la souscription.
• Attributions de rôles de contrôle d'accès basées sur les rôles pour chaque abonnement et groupe de ressources.
• Un réseau virtuel hub, tel qu’Azure passerelle VPN ou Azure ExpressRoute, pour une connectivité hybride.
• Un réseau virtuel pour chaque environnement d'application.
• Applications déployées dans l'abonnement respectif en fonction de la classification de leur environnement, telle que le développement, les tests ou la production.
• Une équipe informatique centrale qui contrôle et exploite l’environnement.

Le diagramme suivant montre l’état actuel de ce scénario.

Passage à l’architecture conceptuelle de la zone d’atterrissage Azure

Avant de mettre en œuvre cette approche, passez en revue l’architecture conceptuelle de la zone d’atterrissage Azure, les principes de conception de la zone d’atterrissage Azure et les zones de conception de la zone d’atterrissage Azure.

Pour passer de l’état actuel de ce scénario à une architecture conceptuelle de zone d’atterrissage Azure, utilisez l’approche suivante :

1. Déployez l'accélérateur de zone d'atterrissage Azure dans le même locataire Microsoft Entra ID en parallèle avec l'environnement actuel. Cette méthode permet une transition fluide et progressive vers la nouvelle architecture de zone d'atterrissage avec une perturbation minimale des charges de travail actives.

   Ce déploiement crée une nouvelle structure de groupe d'administration. Cette structure s’aligne sur les principes et suggestions de conception des zones d’atterrissage Azure. Cela garantit également que ces changements n’affectent pas l’environnement existant.

   Pour plus d’informations, consultez Comment gérer une zone d’atterrissage de charge de travail dev/test/prod.

2. (Facultatif) Travaillez avec les équipes d'application ou de service pour migrer les charges de travail déployées dans les abonnements d'origine vers de nouveaux abonnements Azure. Pour plus d’informations, consultez Transition d’un environnement Azure existant vers l’architecture conceptuelle de la zone d’atterrissage Azure. Vous pouvez placer les charges de travail dans la hiérarchie du groupe de gestion de l’architecture conceptuelle de la zone d’atterrissage Azure nouvellement déployée sous le groupe de gestion approprié, tel que l’entreprise ou en ligne dans le diagramme suivant.

   Pour plus de détails sur l'effet sur les ressources lors de la migration, voir Stratégies.

   Finalement, vous pouvez annuler l’abonnement Azure existant et le placer dans le groupe d’administration mis hors service.

   Remarque

   Vous n’êtes pas nécessairement obligé de migrer les applications ou services existants vers de nouvelles zones d’atterrissage ou des abonnements Azure.

3. Créez de nouveaux abonnements Azure pour fournir des zones d’atterrissage qui prennent en charge les projets de migration sur site. Placez-les sous le groupe de gestion approprié, tel que l'entreprise ou en ligne dans le diagramme suivant.

   Pour plus d'informations, consultez Préparer votre zone d'atterrissage pour la migration.

Le diagramme suivant montre l'état de ce scénario pendant la migration.

Résumé

Dans ce scénario, le client a réalisé ses plans d’expansion et de mise à l’échelle au sein d’Azure en déployant l’architecture conceptuelle de la zone d’atterrissage Azure parallèlement à son environnement existant.