Zielzonenregionen
In diesem Artikel wird erläutert, wie Zielzonen Azure-Regionen verwenden. Die Azure-Zielzonenarchitektur ist regionsunabhängig, aber Sie müssen Azure-Regionen angeben, um Ihre Azure-Zielzonenarchitektur bereitzustellen. In der folgenden Anleitung wird beschrieben, wie Sie eine Region zu einer bestehenden Zielzone hinzufügen und was Sie beachten müssen, wenn Sie Ihren Azure-Bestand in eine andere Region migrieren.
In manchen Situationen sollten Sie Anwendungen in mehreren Azure-Regionen bereitstellen, um Ihre Geschäftsanforderungen an die Hochverfügbarkeit und Notfallwiederherstellung zu erfüllen. Vielleicht haben Sie keinen unmittelbaren Bedarf an Anwendungen für mehrere Regionen, aber Sie sollten Ihre Azure Zielzonen-Plattform so konzipieren, dass sie mehrere Regionen unterstützt, insbesondere für Konnektivität, Identität und Verwaltungsdienste. Stellen Sie sicher, dass Sie Zielzonen für mehrere Regionen schnell aktivieren und unterstützen können.
Weitere Informationen finden Sie unter Azure-Regionen.
Zielzonen und Azure-Regionen
Azure-Zielzonen bestehen aus einer Menge von Ressourcen und Konfigurationen. Einige dieser Elemente, z. B. Verwaltungsgruppen, Richtlinien und Rollenzuweisungen, werden entweder auf Mandanten- oder Verwaltungsgruppenebene innerhalb der Azure-Zielzonenarchitektur gespeichert. Diese Ressourcen werden nicht in einer bestimmten Region bereitgestellt, sondern stattdessen global bereitgestellt. Sie müssen jedoch weiterhin eine Bereitstellungsregion angeben, da Azure einige der Ressourcenmetadaten in einem regionalen Metadatenspeicher nachverfolgt.
Andere Ressourcen werden regional bereitgestellt. Abhängig von Ihrer eigenen Zielzonenkonfiguration verfügen Sie möglicherweise über einige oder alle der folgenden regional bereitgestellten Ressourcen:
- Ein Arbeitsbereich für Azure Monitor-Protokolle, einschließlich ausgewählter Lösungen
- Ein Azure Automation-Konto
- Ressourcengruppen, für die anderen Ressourcen
Wenn Sie eine Netzwerktopologie bereitstellen, müssen Sie eine Azure-Region auswählen, in der die Netzwerkressourcen bereitgestellt werden sollen. Diese Region kann sich von der Region unterscheiden, die Sie für die in der vorherigen Liste aufgeführten Ressourcen verwenden. Abhängig von der von Ihnen ausgewählten Topologie können die von Ihnen bereitgestellten Netzwerkressourcen folgendes beinhalten:
- Azure Virtual WAN, einschließlich Virtual WAN-Hub
- Virtuelle Azure-Netzwerke
- VPN Gateway
- Azure ExpressRoute-Gateway
- Azure Firewall
- Azure DDoS Protection-Pläne
- Private Azure DNS-Zonen, einschließlich Zonen für Azure Private Link
- Ressourcengruppen, die die oben aufgeführten Ressourcen enthalten
Hinweis
Um die Auswirkungen regionaler Ausfälle zu minimieren, empfiehlt es sich, Ressourcen in derselben Region wie die Ressourcengruppe zu platzieren. Weitere Informationen finden Sie unter Ausrichtung des Standorts der Ressourcengruppen.
Hinzufügen einer neuen Region zu einer vorhandenen Zielzone
Sie sollten eine Strategie für mehrere Regionen in Betracht ziehen, entweder gleich zu Beginn Ihrer Cloud-Journey, oder indem Sie mehr Azure-Regionen erweitern, nachdem Sie die anfängliche Bereitstellung Ihrer Azure-Zielzonenarchitektur abgeschlossen haben. Wenn Sie beispielsweise die Notfallwiederherstellung Ihrer virtuellen Computer mithilfe von Azure Site Recovery aktivieren, sollten Sie sie in eine andere Azure-Region replizieren. Berücksichtigen Sie die folgenden Empfehlungen, um Azure-Regionen innerhalb Ihrer Azure-Zielzonenarchitektur hinzuzufügen:
| Bereich | Empfehlung |
|---|---|
| Verwaltungsgruppen | Keine Aktion erforderlich. Verwaltungsgruppen sind nicht an eine Region gebunden. Sie sollten keine Verwaltungsgruppenstruktur auf der Grundlage von Regionen erstellen. |
| Abonnements | Abonnements sind nicht an eine Region gebunden. |
| Azure Policy | Nehmen Sie in Azure Policy Änderungen vor, wenn Sie Richtlinien zugewiesen haben, um die Ressourcenbereitstellung in allen Regionen zu verweigern, indem Sie eine Liste der „zulässigen“ Azure-Regionen angeben. Aktualisieren Sie diese Zuweisungen, um die Bereitstellung von Ressourcen in der neuen Region zu ermöglichen, die Sie aktivieren möchten. |
| Rollenbasierte Zugriffssteuerung (Role-Based Access Control, RBAC) | Keine Aktion erforderlich. Azure RBAC ist nicht an eine Region gebunden. |
| Überwachung und Protokollierung | Entscheiden Sie, ob Sie einen einzigen Azure Monitor Protokoll-Arbeitsbereich für alle Regionen verwenden oder mehrere Arbeitsbereiche erstellen möchten, um verschiedene geographische Regionen abzudecken. Jeder Ansatz hat Vor- und Nachteile, einschließlich möglicher regionsübergreifender Netzwerkgebühren. Für weitere Informationen, siehe Entwerfen Sie eine Log Analytics Arbeitsbereich-Architektur. |
| Netzwerk | Erweitern Sie das Netzwerk auf die neue Azure-Region, wenn Sie eine Netzwerktopologie festgelegt haben (Virtual WAN oder das herkömmliche Hub-and-Spoke-Modell). Erstellen Sie einen weiteren Netzwerkhub, indem Sie die erforderlichen Netzwerkressourcen im vorhandenen Konnektivitätsabonnement in der neuen Azure-Region bereitstellen. Azure Virtual Network Manager kann die Erweiterung und Verwaltung virtueller Netzwerke im großen Stil in mehreren Regionen erleichtern. Aus Domain Name System (DNS)-Sicht können Sie auch auf Wunsch Forwarder (sofern verwendet) in der neuen Azure-Region bereitstellen. Verwenden Sie Weiterleiter für die Auflösung für virtuelle Spoke-Netzwerke in der neuen Region. Azure DNS-Zonen sind globale Ressourcen und nicht an eine einzelne Azure-Region gebunden, so dass sie keine Maßnahmen erfordern. |
| Identität | Erweitern Sie Active Directory Domain Services oder Microsoft Entra Domain Services in die neue Azure-Region, wenn Sie diesen Dienst im Abonnement oder in Spoke Ihrer Identität bereitgestellt haben. |
Hinweis
Außerdem sollten Sie Verfügbarkeitszonen für Hochverfügbarkeit innerhalb einer Region verwenden. Prüfen Sie, ob Ihre Regionen und Dienste Verfügbarkeitszonen unterstützen.
Microsoft Cloud for Sovereignty enthält Richtlinien zum Einschränken von Diensten und Regionen. Sie können diese Richtlinien verwenden, um die Dienstkonfiguration zu erzwingen, damit Kunden ihre Anforderungen an die Datenresidenz erreichen können.
Übergeordnete Vorgehensweise
Befolgen Sie für das Erweitern einer Azure-Zielzone auf eine neue Region die Schritte in den folgenden Abschnitten. Bevor Sie beginnen, müssen Sie sich für mindestens eine neue Azure-Region für die Erweiterung entscheiden.
Netzwerk
Herkömmliche Hub-and-Spoke-Architektur
Tipp
Sehen Sie sich eine herkömmliche Hub-and-Spoke-Architektur an.
Entscheiden Sie, ob ein neues Plattformabonnement für die Zielzone erforderlich ist. Für die meisten Kund*innen wird empfohlen, die vorhandenen Konnektivitätsabonnements weiter zu nutzen, auch wenn sie mehrere Regionen verwenden.
Erstellen Sie innerhalb des Abonnements eine neue Ressourcengruppe in der neuen Zielregion.
Erstellen Sie ein neues Hub-VNet in der neuen Zielregion.
Stellen Sie ggf. Azure Firewall oder virtuelle Netzwerkgeräte (NVA) in Ihrem neuen Hub-VNet bereit.
Stellen Sie ggf. VNet-Gateways für VPN- oder ExpressRoute-Konnektivität bereit, und richten Sie Verbindungen ein. Stellen Sie sicher, dass Ihre ExpressRoute-Leitungen und lokalen Standorte den Empfehlungen von Microsoft zur Resilienz entsprechen. Weitere Informationen finden Sie unter Entwurf für die Notfallwiederherstellung mit privatem ExpressRoute-Peering.
Richten Sie das Peering virtueller Netzwerke zwischen dem neuen Hub-VNet und den anderen Hub-VNets ein.
Erstellen und konfigurieren Sie ggf. erforderliches Routing, z. B. Azure Route Server oder benutzerdefinierte Routen.
Richten Sie bei Bedarf DNS-Forwarder für die neue Zielregion ein und verknüpfen Sie sie mit allen privaten DNS-Zonen, um die Namensauflösung zu ermöglichen.
- Einige Kund*innen konfigurieren möglicherweise die Namensauflösung auf ihren Windows Server Active Directory-Domänencontrollern innerhalb des Plattformabonnements für die Zielzone ihrer Identität.
Um Ihre Workloads zu hosten, können Sie dann das Peering virtueller Netzwerke verwenden, um die Speichen der Landing Zones mit dem neuen virtuellen Hub-Netzwerk in der neuen Region zu verbinden.
Tipp
Azure Virtual Network Manager kann die Erweiterung und Verwaltung virtueller Netzwerke im großen Stil in mehreren Regionen erleichtern.
Virtual WAN-Architektur
Tipp
Siehe Virtual WAN-Architektur.
Erstellen Sie in Ihrem vorhandenen Virtual WAN einen neuen virtuellen Hub in der neuen Zielregion.
Stellen Sie Azure Firewall oder andere unterstützte virtuelle Netzwerkgeräte (NVA) in Ihrem neuen virtuellen Hub bereit. Konfigurieren Sie Virtual WAN-Routingabsicht und -Routingrichtlinien, um den Datenverkehr über den neuen geschützten virtuellen Hub weiterzuleiten.
Stellen Sie ggf. VNet-Gateways für VPN- oder ExpressRoute-Konnektivität im neuen virtuellen Hub bereit, und richten Sie Verbindungen ein. Stellen Sie sicher, dass Ihre ExpressRoute-Leitungen und lokalen Standorte den Empfehlungen von Microsoft zur Resilienz entsprechen. Weitere Informationen finden Sie unter Entwurf für die Notfallwiederherstellung mit privatem ExpressRoute-Peering.
Konfigurieren Sie ggf. weiteres Routing, z. B. statische Routen des virtuellen Hubs.
Stellen Sie ggf. DNS-Weiterleitungen für die neue Zielregion bereit, und verknüpfen Sie diese mit allen privaten DNS-Zonen, um die Auflösung zu aktivieren.
Einige Kund*innen konfigurieren möglicherweise die Namensauflösung auf ihren Active Directory-Domänencontrollern innerhalb des Plattformabonnements für die Zielzone ihrer Identität.
In Virtual WAN-Bereitstellungen muss dies heute in einem virtuellen Spoke-Netzwerk erfolgen, das mittels einer VNet-Verbindung mit dem virtuellen Hub verbunden ist und dem Erweiterungsmuster für virtuelle Hubs folgt.
Um Ihre Workloads zu hosten, können Sie dann das Peering virtueller Netzwerke verwenden, um die Speichen der Landing Zones mit dem neuen virtuellen Hub-Netzwerk in der neuen Region zu verbinden.
Identity
Tipp
Überprüfen Sie den Entwurfsbereichs der Azure-Zielzone für Identitäts- und Zugriffsverwaltung.
Entscheiden Sie, ob ein neues Plattformabonnement für die Zielzone erforderlich ist. Für die meisten Kund*innen wird empfohlen, die vorhandenen Identitätsabonnements weiter zu nutzen, auch wenn sie mehrere Regionen verwenden.
Erstellen Sie eine neue Ressourcengruppe in der neuen Zielregion.
Erstellen Sie ein neues virtuelles Netzwerk in der neuen Zielregion.
Richten Sie das Peering virtueller Netzwerke mit dem neu erstellten virtuellen Netzwerk des regionalen Hubs im Konnektivitätsabonnement ein.
Stellen Sie Identitätsworkloads (z. B. VMs für Active Directory-Domänencontroller) im neuen virtuellen Netzwerk bereit.
Möglicherweise müssen Sie weitere Einrichtungsschritte für die Workloads durchführen, nachdem diese bereitgestellt wurden, z. B.:
Stufen Sie die VMs der Active Directory-Domänencontroller auf die vorhandene Active Directory-Domäne hoch.
Erstellen Sie neue Active Directory-Sites und -Subnetze.
Konfigurieren Sie DNS-Servereinstellungen wie bedingte Weiterleitungen.
Verschieben Ihres Azure-Bestands in eine neue Region
Es kann vorkommen, dass Sie Ihr gesamtes Azure-Anwesen in eine andere Region verlegen müssen. Angenommen, Sie haben Ihre Zielzone und Workloads in einer Azure-Region in einem Nachbarland oder einer Nachbarregion bereitgestellt, und dann wird eine neue Azure-Region in Ihrem Heimatland oder Ihrer Heimatregion gestartet. Sie können sich dafür entscheiden, alle Ihre Workloads in die neue Region zu verschieben, um die Kommunikationswartezeit zu verbessern oder die Anforderungen an die Datenresidenz zu erfüllen.
Hinweis
Dieser Artikel enthält nur Informationen zum Migrieren der Zielzonenkomponenten Ihres Bestandes. Weitere Informationen finden Sie unter Cloud-Workloads verschieben.
Konfiguration der globalen Zielzone
Der größte Teil der global bereitgestellten Zielzonenkonfiguration muss in der Regel nicht geändert werden, wenn Sie Regionen verschieben. Stellen Sie jedoch sicher, dass Sie nach Richtlinienzuweisungen suchen, die Regionsbereitstellungen einschränken, und aktualisieren Sie die Richtlinie, um Bereitstellungen in der neuen Region zuzulassen.
Ressourcen für regionale Zielzonen
Regionalspezifische Zielzonen-Ressourcen erfordern oft mehr Überlegung, da Sie einige Azure-Ressourcen nicht zwischen Regionen verschieben können. Berücksichtigen Sie den folgenden Ansatz:
Fügen Sie die Zielregion als zusätzliche Region zu Ihrer Zielzone hinzu: Weitere Informationen finden Sie unter Hinzufügen einer neuen Region zu einer vorhandenen Zielzone.
Stellen Sie zentrale Komponenten in der Zielregion bereit: Stellen Sie z. B. einen neuen Azure Monitor Logs-Arbeitsbereich in Ihrer Zielregion bereit, damit Workloads nach der Migration der Workload mit der Verwendung der neuen Komponente beginnen können.
Migrieren Sie Ihre Workloads von der Ursprungsregion in die Zielregion: Konfigurieren Sie während des Workloadmigrationsprozesses die Ressourcen neu, um die Netzwerkkomponenten, Identitätskomponenten, Log Analytics-Arbeitsbereiche und andere regionale Ressourcen der Zielregion zu verwenden.
Legen Sie die Ressourcen in der Quellregion still, nachdem Sie die Migration abgeschlossen haben..
Beachten Sie die folgenden Tipps, wenn Sie Zielzonenressourcen regionsübergreifend migrieren:
Verwenden Sie die Infrastruktur als Code: Verwenden Sie Bicep, Azure Resource Manager-Vorlagen (ARM-Vorlagen), Terraform, Skripting oder einen ähnlichen Ansatz, um komplexe Konfigurationen zu exportieren und wieder zu importieren, z. B. Regeln für Azure Firewall.
Automatisierung: Verwenden Sie Skripts zum Migrieren von Automatisierungsressourcen zwischen Regionen.
ExpressRoute: Überlegen Sie, ob Sie die ExpressRoute Local-SKU in Ihrer Zielregion verwenden können. Wenn sich Ihre lokalen Umgebungen innerhalb desselben Ballungsraums wie Ihre Azure-Region befinden, kann ExpressRoute Local eine kostengünstigere Option als andere ExpressRoute-SKUs bieten.