Szenario: Umstellen einer regionalen Organisation auf die konzeptionelle Azure-Zielzonenarchitektur

Dieser Artikel beschreibt Überlegungen und Anweisungen zur Migration und Umstellung Ihrer Azure-Umgebung auf die konzeptionelle Azure-Zielzonenarchitektur. Dieses Szenario umfasst eine regionale Organisation mit Managementgruppen, die in Entwicklungs-, Test- und Produktivumgebungen (dev/test/prod) unterteilt sind.

In diesem Szenario hat der oder die Kund*in einen großen Speicherbedarf in Azure. Es gibt eine Hierarchie der Verwaltungsgruppen, die nach Entwicklungs-/Test-/Produktionsumgebungen und dann nach Regionen gegliedert ist. Die aktuelle Implementierung schränkt die Skalierbarkeit und das Wachstum ein. Es wurden Anwendungen auf der ganzen Welt bereitgestellt. Ein zentrales IT-Team verwaltet jede Region. In diesem Szenario sind die Regionen Amerika; Europa, der Nahen Osten und Afrika (EMEA); und Asien-Pazifik (APAC).

Der oder die Kund*in möchte die vorhandene Umgebung in die konzeptionelle Azure-Zielzonenarchitektur verschieben. Dieser Ansatz unterstützt die Cloud First-Strategie und verfügt über eine robuste Plattform, die skaliert wird, während die lokalen Rechenzentren außer Betrieb genommen werden.

Aktueller Status

In diesem Szenario sieht die aktuelle Azure-Umgebung wie folgt aus:

• Mehrere Verwaltungsgruppen
• Eine Verwaltungsgruppenhierarchie basierend auf Entwicklungs-/Test-/Produktionsumgebungen auf der ersten Ebene und dann basierend auf der Geografie auf der zweiten Ebene.
• Ein Azure-Abonnement für jede Geografie und Anwendungsumgebung wie dev/test/prod. Dieses Abonnement ist erforderlich, um Entwickler*innen eine ungezwungene Umgebung für Tests und Innovationen zu bieten.
• Einige kritische Workloads, die in den Bereichen Entwicklung/Test/Produktion dasselbe Governance-Modell benötigen, was für den oder die Kund*in zu Governance-Herausforderungen führen kann.
• Keine einheitliche Ressourcenverteilung Plattform- und Workloadressourcen für eine einzige Umgebung werden im gleichen Azure-Abonnement bereitgestellt.
• Anwendungen, die auf der Grundlage ihrer Region und Umgebungsklassifizierung (z. B. dev/test/prod) in den jeweiligen Abonnementen bereitgestellt werden.
• Richtlinienzuweisungen, wie Überprüfungseffekte und Verweigerungseffekte, die auf Verwaltungsgruppen- und Abonnementebene zugewiesen sind.
• Der gleiche Satz von Azure-Richtlinien, die auf alle Anwendungen in derselben Region und in demselben Umgebungstyp angewendet werden.
• Rollenzuweisungen für rollenbasierte Zugriffssteuerung für jedes Abonnement und jede Ressourcengruppe.
• Ein virtuelles Hub-Netzwerk, wie z. B. Azure VPN Gateway oder Azure ExpressRoute für hybride Konnektivität.
• Ein virtuelles Netzwerk für jede Anwendungsumgebung.
• Ein zentrales IT-Team, das die jeweilige Verwaltungsgruppe für jede Region steuert und betreibt. Aufgrund der Tatsache, dass einige Anwendungen in mehreren Regionen bereitgestellt werden, steht das Team vor einigen Herausforderungen in Bezug auf Konsistenz, Konfiguration und Compliance, was Richtlinien, Zugriffssteuerung, Konfiguration von Plattformressourcen und Sicherheits-Compliance angeht.

Die folgende Abbildung zeigt den aktuellen Zustand dieses Beispielszenarios.

Übergang zur konzeptionellen Architektur der Azure-Zielzone

Überprüfen Sie vor der Implementierung dieses Ansatzes die konzeptionelle Azure-Zielzonenarchitektur, die Entwurfsprinzipien für Azure-Zielzonen und Entwurfsbereiche für Azure-Zielzonen.

Für den Wechsel vom aktuellen Zustand dieses Szenarios zu einer konzeptionellen Azure-Zielzonenarchitektur empfiehlt sich folgender Ansatz:

1. Stellen Sie den Beschleuniger für Azure-Zielzonen parallel zur aktuellen Umgebung im selben Microsoft Entra ID-Mandanten bereit. Diese Methode bietet einen reibungslosen und schrittweisen Übergang zur neuen Zielzonenarchitektur mit minimalen Unterbrechungen für aktive Workloads.

   Durch diese Bereitstellung wird eine neue Verwaltungsgruppenstruktur erstellt. Diese Struktur ist an den Entwurfsprinzipien und Empfehlungen für Azure-Zielzonen ausgerichtet. Außerdem wird sichergestellt, dass die vorhandene Umgebung von diesen Änderungen nicht betroffen ist.

   Weitere Informationen finden Sie unter Umgang mit einer Entwicklungs-/Test-/Produktions-Workload-Zielzone.

   Informationen zur Verwendung der Sandbox-Verwaltungsgruppenhierarchie, um Entwickler*innen das Testen und Experimentieren ohne Auswirkungen auf andere Umgebungen zu ermöglichen, finden Sie in Anleitungen zur Sandboxumgebung in Azure-Zielzonen.

   Informationen zum Minimieren von Unterbrechungen für Anwendungen und Dienste während der Migration finden Sie unter Einführung von richtliniengesteuerten Schutzmaßnamen.

2. (Optional) Arbeiten Sie mit Anwendungs- oder Serviceteams zusammen, um die Workloads, die in den ursprünglichen Abonnements bereitgestellt wurden, in neue Azure-Abonnements zu migrieren. Weitere Informationen finden Sie unter Übertragen vorhandener Azure-Umgebungen auf die konzeptionelle Architektur der Azure-Zielzone. Sie können Workloads in der neu eingerichteten Verwaltungsgruppenhierarchie der konzeptionellen Azure-Zielzonenarchitektur in der richtigen Verwaltungsgruppe platzieren, wie z. B. unternehmenseigen oder online in der folgenden Abbildung.

   Details zu den Auswirkungen auf Ressourcen bei der Migration finden Sie unter Richtlinien.

   Schließlich können Sie das bestehende Azure-Abonnement kündigen und es in die außer Betrieb gesetzte Verwaltungsgruppe aufnehmen.

   Hinweis

   Sie müssen nicht unbedingt die bestehenden Anwendungen oder Dienste in neue Zielzonen oder Azure-Abonnements migrieren.

3. Erstellen Sie neue Azure-Abonnements, um Zielzonen bereitzustellen, die neue Anwendungen und Workloads unterstützen können. Platzieren Sie diese in der richtigen Verwaltungsgruppe, z. B. unternehmenseigen oder online in der folgenden Abbildung.

   Weitere Informationen finden Sie unter Anleitung zur Vorbereiten Ihrer Zielzone für die Migration

Die folgende Abbildung zeigt den Status dieses Szenarios während der Migration.

Zusammenfassung

In diesem Szenario hat der oder die Kund*in die notwendige Grundlage geschaffen, um Wachstums- und Skalierungspläne für Workloads in Azure zu unterstützen. Dazu wurde parallel zur bestehenden Umgebung die konzeptionelle Azure-Zielzonenarchitektur implementiert.