Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
In diesem Artikel werden Überlegungen und Anweisungen zum Migrieren und Übergang Ihrer vorhandenen Umgebung in die konzeptionelle Architektur von Azure-Landezonen beschrieben. In diesem Szenario werden einzelne oder mehrere Verwaltungsgruppen behandelt.
In diesem Szenario wird davon ausgegangen, dass der Kunde Bereits Azure verwendet. Sie verfügen über eine Verwaltungsgruppenhierarchie mit mehreren Abonnements, die einige Anwendungen oder Dienste innerhalb der Plattform hosten. Ihre aktuelle Implementierung beschränkt jedoch ihre Skalierbarkeit und ihr Wachstum im Zusammenhang mit ihrer Cloud-First-Strategie .
Im Rahmen dieser Erweiterung planen sie, ihre lokalen Rechenzentren aufzulösen und in Azure zu migrieren. Während der Migration führen sie mit der Modernisierung und Transformation ihrer Anwendungen oder Dienste, um cloudeigene Technologien nach Möglichkeit zu nutzen. Sie können beispielsweise Azure SQL-Datenbank und Azure Kubernetes Service (AKS) verwenden. Sie wissen, dass es viel Zeit und Mühe braucht, daher planen sie, mit einem Lift-and-Shift zu beginnen. Zunächst erfordert dieser Plan hybride Konnektivität über Dienste wie Azure VPN-Gateway oder Azure ExpressRoute.
Der Kunde möchte seine vorhandene Umgebung in die konzeptionelle Architektur der Azure-Landezonen verschieben. Diese Architektur unterstützt ihre Cloud-First-Strategie und verfügt über eine robuste Plattform, die skalieren kann, wenn der Kunde seine lokalen Rechenzentren außer Betrieb nimmt.
Aktueller Status
In diesem Szenario besteht der aktuelle Status der Azure-Umgebung des Kunden aus:
- Eine oder mehrere Verwaltungsgruppen.
- Eine Verwaltungsgruppenhierarchie, die auf organisationsstruktur oder geografie basiert.
- Ein Azure-Abonnement für jede Anwendungsumgebung, z. B. Entwicklung, Test oder Produktion (Dev/test/prod).
- Nichtuniforme Ressourcenverteilung. Plattform- und Workloadressourcen für eine einzelne Umgebung werden in den gleichen Azure-Abonnements bereitgestellt.
- Richtlinienzuweisungen mit Überwachungseffekten und Verweigerungseffekten, die auf Verwaltungsgruppen- und Abonnementebene zugewiesen sind.
- Rollenzuweisungen für rollenbasierte Zugriffssteuerung für jedes Abonnement und jede Ressourcengruppe.
- Ein virtuelles Hubnetzwerk, z. B. Azure VPN-Gateway oder Azure ExpressRoute, für hybride Konnektivität.
- Ein virtuelles Netzwerk für jede Anwendungsumgebung.
- Anwendungen, die in dem jeweiligen Abonnement bereitgestellt werden, basierend auf ihrer Umgebungsklassifizierung, z. B. Entwicklung, Test oder Produktion.
- Ein zentrales IT-Team, das die Umgebung steuert und betreibt.
Das folgende Diagramm zeigt den aktuellen Status dieses Szenarios.
Übergang zur Referenzarchitektur der Azure-Zielzone
Überprüfen Sie vor der Implementierung dieses Ansatzes die Referenzarchitektur der Azure-Zielzone, die Entwurfsprinzipien für Azure-Zielzonen und die Entwurfsbereiche der Azure-Zielzone.
Verwenden Sie den folgenden Ansatz, um vom aktuellen Zustand dieses Szenarios zu einer Referenzarchitektur der Azure-Zielzone zu wechseln:
Stellen Sie die Azure-Zielzone parallel zur aktuellen Umgebung in demselben Microsoft Entra ID-Mandanten bereit. Diese Methode bietet einen reibungslosen und phasenweisen Übergang zur neuen Zielzonenarchitektur mit minimaler Beeinträchtigung für aktive Workloads.
Diese Bereitstellung erstellt eine neue Verwaltungsgruppenstruktur. Diese Struktur richtet sich an die Entwurfsprinzipien und Empfehlungen für Azure-Landezonen. Außerdem wird sichergestellt, dass sich diese Änderungen nicht auf die vorhandene Umgebung auswirken.
Weitere Informationen finden Sie unter Verwalten einer Entwicklungs-/Test-/Produktiv-Workload-Startzone.
(Optional) Arbeiten Sie mit Anwendungs- oder Dienstteams zusammen, um die Workloads zu migrieren, die in den ursprünglichen Abonnements in neue Azure-Abonnements bereitgestellt werden. Weitere Informationen finden Sie unter Eine bestehende Azure-Umgebung in die Azure Landing Zone Referenzarchitektur überführen. Sie können Arbeitslasten in der neu bereitgestellten Azure Landing Zone Referenzarchitektur-Verwaltungsgruppenhierarchie in der richtigen Verwaltungsgruppe, wie Corporate oder online, im folgenden Diagramm platzieren.
Ausführliche Informationen zu den Auswirkungen auf Ressourcen bei der Migration finden Sie unter "Richtlinien".
Schließlich können Sie das vorhandene Azure-Abonnement kündigen und es in die Verwaltungsgruppe für außer Betrieb genommene Abonnements verschieben.
Hinweis
Sie müssen nicht unbedingt die vorhandenen Anwendungen oder Dienste in neue Zielzonen oder Azure-Abonnements migrieren.
Erstellen Sie neue Azure-Abonnements, um Zielzonen bereitzustellen, die Migrationsprojekte von lokalen Umgebungen unterstützen. Platzieren Sie sie unter der richtigen Verwaltungsgruppe, z. B. unternehmensintern oder online im folgenden Diagramm.
Weitere Informationen entnehmen Sie der Anleitung zur Vorbereitung Ihrer Landing Zone für die Migration.
Das folgende Diagramm zeigt den Status dieses Szenarios während der Migration.
Zusammenfassung
In diesem Szenario hat der Kunde seine Erweiterungs- und Skalierungspläne in Azure erreicht, indem er die Referenzarchitektur der Azure-Zielzone parallel zu ihrer vorhandenen Umgebung bereitstellt.