Bearbeiten

Verschieben von Azure-Ressourcen zwischen Regionen

Microsoft Entra
Azure ExpressRoute
Azure Load Balancer
Azure VPN Gateway

Diese Lösung verschiebt Azure-Ressourcen effizient, sicher und nahtlos in verschiedene Regionen. Hier finden Sie die wichtigen Schritte, Überlegungen und Strategien zum Planen und Ausführen einer Migration.

Aufbau

Diagramm des Datenflusses beim Verschieben von Azure-Ressourcen zwischen verschiedenen Regionen.

Laden Sie eine Visio-Datei dieser Architektur herunter.

Datenfluss

  • Lokales Rechenzentrumsnetzwerk: Ein in einer Organisation betriebenes privates lokales Netzwerk zur Unterstützung der lokalen Ressourcen.

  • ExpressRoute-Verbindung: ExpressRoute-Verbindungen nutzen eine dedizierte private Verbindung über einen Drittanbieter für die Konnektivität. Die private Verbindung erweitert ein lokales Netzwerk auf Azure.

  • Lokale Edgerouter: Router, die das lokale Netzwerk mit der durch den Drittanbieter verwalteten Verbindung verbinden. Je nachdem, wie Sie die Verbindung bereitgestellt haben, müssen Sie möglicherweise die öffentlichen IP-Adressen angeben, die von den Routern verwendet werden.

  • Microsoft Edge-Router: Zwei Router in einer Aktiv/Aktiv-Konfiguration mit Hochverfügbarkeit. Diese Router ermöglichen es einem Drittanbieter für die Konnektivität, ihre Verbindungen direkt mit dem Rechenzentrum zu verbinden. Je nachdem, wie Sie die Verbindung bereitgestellt haben, müssen Sie möglicherweise die öffentlichen IP-Adressen angeben, die von den Routern verwendet werden.

  • VPN Gateway: Mithilfe des VPN Gateway-Diensts können Sie das virtuelle Netzwerk mit dem lokalen Netzwerk verbinden.

  • Active Directory-Subnetz: Die meisten Organisationen großer Unternehmen verfügen im lokalen Rechenzentrum über eine AD DS-Umgebung (Active Directory Domain Services). Um die Verwaltung von Assets zu ermöglichen, die aus Ihrem lokalen Netzwerk nach Azure verschoben werden, sollten Sie AD DS-Domänencontroller in Azure in einem zentralen VNET-Hub (Virtuelles Netzwerk) hosten, auf den abhängige Workloads zugreifen können.

  • VNET-Peering: Mehrere VNETs, die durch Peering verbunden sind. VNET-Peering ermöglicht Gruppenanwendungen in entsprechenden virtuellen Netzwerken und bietet eine Verbindung mit geringer Latenz und hoher Bandbreite.

  • Webanwendungen mit mehreren Ebenen, die in der Cloudumgebung ausgeführt werden: Diese Beispielarchitektur trifft auf viele Branchen zu, die robuste Anwendungen mit mehreren Ebenen in der Cloud bereitstellen müssen. Die Anwendung in diesem Szenario umfasst drei Ebenen:

    • Webebene: Die oberste Ebene, die auch die Benutzeroberfläche enthält. Diese Ebene analysiert Benutzerinteraktionen und übergibt die Aktionen zur Verarbeitung an die nächste Ebene.
    • Geschäfts- oder Anwendungsebene: Verarbeitet die Benutzerinteraktionen und trifft logische Entscheidungen hinsichtlich der nächsten Schritte. Diese Ebene verbindet die Webebene mit der Datenebene.
    • Datenebene: Speichert die Anwendungsdaten. In diesem Fall werden die Daten in einer SQL-Datenbank gespeichert.

  • Interner Lastenausgleich: Netzwerkverkehr aus dem VPN Gateway wird über einen Endpunkt für den internen Lastenausgleich (Internal Load Balancer, ILB), der sich im Subnetz der Anwendungsebenen befindet, an die Cloudanwendung weitergeleitet.

  • PaaS-Ressourcen (Platform as a Service) : In dieser Beispielumgebung gibt es einige PaaS-Dienste wie Azure IoT Hub, Azure Key Vault und Azure App Service.

Komponenten

Die Beispielarchitektur verwendet die folgenden Komponenten:

Szenariodetails

Aufgrund des Wachstums von Microsoft Azure und der steigenden Anzahl von Regionen weltweit ist es für Kunden erforderlich, Bereitstellungen von einer Region in eine andere zu verschieben. Das Verschieben von Anwendungen zwischen Regionen ist eine Aktivität, die einen gut durchdachten Plan erfordert, damit ein nahtloses Verschieben aller Ressourcen sichergestellt ist und die Anwendungen mit minimaler Ausfallzeit in der neuen Region ausgeführt werden.

Die Empfehlungen und die Architektur in diesem Beispiel bieten Anleitungen für das effiziente, sichere und nahtlose Verschieben von Azure-Ressourcen zwischen Regionen.

Mögliche Anwendungsfälle

Zu den wichtigsten Gründen für das Verschieben von Ressourcen in eine andere Region zählen folgende Fälle:

  • Ausrichtung an einer neuen Region: Verschieben von Ressourcen in eine neu eingeführte Azure-Region, die zuvor noch nicht verfügbar war.
  • Ausrichtung für Dienste oder Features: Verschieben von Ressourcen, um die Vorteile der Dienste oder Features zu nutzen, die in einer bestimmten Region verfügbar sind.
  • Reagieren auf Geschäftsentwicklungen: Verschieben von Ressourcen in eine Region als Reaktion auf Geschäftsänderungen, z.B. Fusionen oder Akquisitionen.
  • Ausrichtung an einer nahegelegenen Region: Verschieben von Ressourcen in eine Region, die für Ihr Unternehmen lokal ist.

Schritte zum Verschieben von Ressourcen zwischen Regionen

Da Ihre Anforderungen von der Beispielarchitektur abweichen können, verwenden Sie die folgenden Empfehlungen als Ausgangspunkt:

  1. Überprüfen der Voraussetzungen für das Verschieben

    • Geplante Ausfallzeit: Planen Sie die Regionsverschiebung als Wartungsaktivität mit geplanter Ausfallzeit, um die Auswirkungen für Kunden zu minimieren.

    • Grenzwerte und Kontingente von Azure-Abonnements: Stellen Sie sicher, dass Ihr Abonnement über ausreichende Ressourcen verfügt, um den jeweiligen Ressourcentyp zu unterstützen. Stellen Sie z. B. sicher, dass die Zielregion virtuelle Computer mit Größen unterstützt, die den virtuellen Computern in der Quellregion entsprechen. Wenden Sie sich ggf. an den Support, um das erforderliche Kontingent zu aktivieren. Weitere Informationen finden Sie unter Grenzwerte für Azure-Abonnements und Dienste, Kontingente und Einschränkungen.

    • Kontoberechtigungen: Wenn Sie ein kostenloses Azure-Konto erstellt haben, sind Sie der Administrator Ihres Abonnements. Wenn Sie nicht der Abonnementadministrator sind, wenden Sie sich an den Administrator, damit dieser Ihnen die Berechtigungen zuweist, die zum Verschieben der Ressourcen erforderlich sind. Vergewissern Sie sich, dass Sie mit Ihrem Azure-Abonnement die erforderliche Ressource in der Zielregion erstellen können.

    • Ressourcenidentifikation: Identifizieren und kategorisieren Sie Ihre Ressourcen basierend auf dem Ressourcentyp, der zum Exportieren einer Azure Resource Manager-Vorlage (ARM) oder zum Starten der Replikation mithilfe verschiedener Technologien benötigt wird. Die Schritte können für jeden zu verschiebenden Ressourcentyp unterschiedlich sein. Die entsprechenden Schritte für den jeweiligen Ressourcentyp finden Sie unter Verschieben von Azure-Ressourcen zwischen Regionen.

  2. Verschieben der Netzwerkkomponenten

    • Netzwerksicherheitsgruppen: Sie können Netzwerksicherheitsgruppen nicht aus einer Region in eine andere verschieben. Sie können jedoch eine ARM-Vorlage verwenden, um die vorhandene Konfiguration und die vorhandenen Sicherheitsregeln einer Netzwerksicherheitsgruppe zu exportieren. Anschließend können Sie die Ressource in einer anderen Region stagen, indem Sie die Gruppe in eine Vorlage exportieren, die Parameter so ändern, dass sie der Zielregion entsprechen, und die Vorlage dann in der neuen Region bereitstellen.

    • Virtuelles Netzwerk: Sie können zum Verschieben des virtuellen Netzwerks in eine andere Region eine Azure Resource Manager-Vorlage verwenden. Exportieren Sie das virtuelle Netzwerk in eine Vorlage, ändern Sie die Parameter entsprechend der Zielregion, und stellen Sie die Vorlage dann in der neuen Region bereit.

    • Peering virtueller Netzwerke: Das VNET-Peering wird nicht neu erstellt, und VNET-Peers schlagen fehl, wenn sie noch in der Vorlage vorhanden sind. Entfernen Sie vor dem Exportieren der Vorlage alle VNET-Peers. Sie können diese nach dem Verschieben des virtuellen Netzwerks wiederherstellen.

    • Öffentliche IP-Adressen: Da öffentliche Azure-IP-Adressen regionsspezifisch sind, können sie nicht aus einer Region in eine andere verschoben werden. Sie können jedoch eine ARM-Vorlage verwenden, um die vorhandene Konfiguration und die vorhandenen Sicherheitsregeln einer Netzwerksicherheitsgruppe zu exportieren. Anschließend können Sie die Ressource in einer anderen Region stagen, indem Sie die Gruppe in eine Vorlage exportieren, die Parameter so ändern, dass sie der Zielregion entsprechen, und die Vorlage dann in der neuen Region bereitstellen.

  3. Verschieben der App-Komponenten

  4. Verschieben der PaaS-Dienste: Zur Orchestrierung des Verschiebens weisen PaaS-Dienste eigene spezifische Schritte auf. Die neuesten Informationen zur Liste der unterstützten Dienste finden Sie unter Unterstützung für das regionenübergreifende Verschieben von Azure-Ressourcen.

  5. Verschieben der lokalen Infrastruktur: Um sicherzustellen, dass Sie die vollständige Quellregion in der Zielregion neu erstellt haben, müssen Sie Ihre lokalen Komponenten wie zuvor einrichten und konfigurieren und sie mit dem Azure-Netzwerk verbinden.

Überlegungen

Diese Überlegungen beruhen auf den Säulen des Azure Well-Architected Frameworks, d. h. einer Reihe von Grundsätzen, mit denen die Qualität von Workloads verbessert werden kann. Weitere Informationen finden Sie unter Microsoft Azure Well-Architected Framework.

Beachten Sie beim Verschieben zwischen Regionen die folgenden Punkte:

  • In Ihrem Plan für die Migration zwischen Regionen muss die komplexe Infrastruktur berücksichtigt sein. Moderne Infrastrukturumgebungen erstrecken sich häufig über die lokale Infrastruktur bis in die Cloud. Einige haben sogar eine zusätzliche Komplexitätsebene mit einer Multi-Cloud-Strategie, die private oder öffentliche Bereitstellungen umfasst.

  • Verschieben Sie Ressourcentypen gemeinsam. Indem Sie das Verschieben ähnlicher Ressourcentypen kombinieren (z. B. 50 virtuelle Computer oder 20 SQL-Datenbanken), können Sie den Vorbereitungsschritt für das Verschieben leichter planen und sicherstellen, dass Vorgänge mit langer Ausführungszeit parallel ausgeführt werden. Auf diese Weise können Ausfallzeiten reduziert werden.

  • Verschieben Sie alle Ressourcen innerhalb einer Anwendung gemeinsam. Sie können die Ressourcen einer Anwendung auswählen und versuchen, diese gemeinsam als Gruppe zu verschieben. Dadurch wird sichergestellt, dass Sie die App auf orchestrierte Weise in der Zielregion aufrufen können.

  • Stellen Sie sicher, dass Sie Ihre Kapazitätsanforderungen abgedeckt sind. Eine Möglichkeit zum Überprüfen der Kapazität oder des Kontingents ist in der Zielregion verfügbar, um das aktuelle und potenzielle Geschäftswachstum vor dem eigentlichen Verschieben zu unterstützen.

  • Es sollte während des Verschiebevorgangs nur minimale oder gar keine Auswirkungen auf die aktuellen geschäftskritischen Anwendungen oder die Infrastruktur in der Quellregion geben.

  • Um Geschäftskontinuität zu gewährleisten, sollten Sie mit möglichst geringer Ausfallzeit über eine funktionsfähige Umgebung in der Zielregion verfügen.

  • Die Möglichkeit zum Überprüfen der Migration vor dem endgültigen Commit zur Zielseite ist von entscheidender Bedeutung, insbesondere wenn Sie Workloads der Ebene 0 und Ebene 1 in der Finanzdienstleistungsbranche (FSI) oder im Gesundheitswesen unterstützen.

  • Stellen Sie sicher, dass eine sorgfältige Überprüfung durch Testen und Validieren der ursprünglichen Konfigurationen, Konnektivität, ordnungsgemäßen Sicherheitskonfiguration, Richtlinien, Datenreplikation und Datenbankverbindungen gewährleistet ist, bevor Sie den Wechsel zur Zielregion durchführen.

  • Nachdem Sie die Ressourcen in das Ziel verschoben haben, stellen Sie sicher, dass die endgültige Konfiguration einsatzbereit ist, indem Sie abschließende Änderungen wie die folgenden vornehmen:

    • Ändern Sie die DNS-Konfiguration so, dass sie auf eine neue IP-Adresse verweist.
    • Löschen Sie Ressourcen in der Quellregion, um eine doppelte Abrechnung zu vermeiden und Probleme aufgrund von zwei separaten Datasets zu verhindern, die sich in Bereich und Konfiguration überschneiden.
    • Löschen Sie alle Hilfsressourcen, die für das Verschieben erstellt wurden. Löschen Sie beispielsweise alle Speicherkonten, die für den Zwischentransfer verwendet wurden.

Nächste Schritte