Teilen über

Verschieben von Ressourcen in eine andere Region – Azure SQL-Datenbank

  • Artikel

Gilt für: Azure SQL-Datenbank

In diesem Artikel finden Sie einen allgemeinen Workflow zum Verschieben Ihrer Datenbank oder Ihres Pools für elastische Datenbanken in eine neue Region.

Hinweis

  • Sie können für das Verschieben von Datenbanken und Pools für elastische Datenbanken in eine andere Azure-Region auch den empfohlenen Azure Resource Mover verwenden.
  • Dieser Artikel betrifft Migrationsvorgänge innerhalb der öffentlichen Azure-Cloud oder innerhalb derselben Sovereign Cloud.

Übersicht

Es gibt verschiedene Szenarien, in denen Sie Ihre vorhandene Datenbank oder Ihren vorhandenen Pool von einer Region in eine andere verschieben möchten. Beispiel: Sie erweitern Ihr Unternehmen in eine neue Region und möchten es für die neue Kundenbasis optimieren. Oder Sie müssen die Vorgänge aus Compliancegründen in eine andere Region verlegen. Oder Azure hat eine neue Region freigegeben, die eine bessere Nähe bietet und die Kundenzufriedenheit verbessert.

Der allgemeine Workflow zum Verschieben von Ressourcen in eine andere Region besteht aus den folgenden Schritten:

  1. Überprüfen der Voraussetzungen für das Verschieben.
  2. Vorbereiten auf das Verschieben der Ressourcen im Gültigkeitsbereich.
  3. Überwachen der Vorbereitung.
  4. Testen des Verschiebungsvorgangs.
  5. Initiieren der eigentlichen Verschiebung.

Überprüfen der Voraussetzungen zum Verschieben der Datenbank

  1. Erstellen Sie einen Zielserver für jeden Quellserver.
  2. Konfigurieren Sie die Firewall mit den richtigen Ausnahmen mithilfe von PowerShell.
  3. Konfigurieren Sie beide Server mit den richtigen Anmeldedaten. Wenn Sie nicht der Subscription- oder SQL Server-Administrator sind, wenden Sie sich an den Administrator, damit dieser Ihnen die erforderlichen Berechtigungen zuweist. Weitere Informationen finden Sie unter Verwalten der Sicherheit der Azure SQL-Datenbank nach der Notfallwiederherstellung.
  4. Wenn Ihre Datenbanken mit Transparent Data Encryption (TDE) und BYOK (Bring Your Own Key oder kundenseitig verwalteter Schlüssel) in Azure Key Vault verschlüsselt sind, stellen Sie sicher, dass in den Zielregionen die richtigen Verschlüsselungskomponenten bereitgestellt werden.
    • Als einfachste Möglichkeit fügen Sie dazu den Schlüssel aus dem vorhandenen Schlüsseltresor (der als TDE-Schutzvorrichtung auf dem Quellserver verwendet wird) auf dem Zielserver hinzu und legen anschließend den Schlüssel als TDE-Schutzvorrichtung auf dem Zielserver fest, denn ein Server in einer Region kann jetzt mit einem Schlüsseltresor in einer anderen Region verbunden werden.
    • Um sicherzustellen, dass der Zielserver Zugriff auf ältere Schlüssel hat (erforderlich zum Wiederherstellen von Datenbanksicherungen), hat es sich bewährt, das Cmdlet Get-AzSqlServerKeyVaultKey auf dem Quellserver auszuführen, um die Liste der verfügbaren Schlüssel zurückzugeben, und diese Schlüssel dann auf dem Zielserver hinzuzufügen.
    • Weitere Informationen und bewährte Methoden zum Konfigurieren von kundenseitig verwalteter TDE auf dem Zielserver finden Sie unter Azure SQL Transparent Data Encryption mithilfe eines kundenseitig verwalteten Schlüssels in Azure Key Vault.
    • Informationen zum Verschieben des Schlüsseltresors in die neue Region finden Sie unter Regionsübergreifendes Verschieben eines Azure Key Vault.
  5. Wenn die Überwachung auf Datenbankebene aktiviert ist, deaktivieren Sie sie, und aktivieren Sie stattdessen die Überwachung auf Serverebene. Nach dem Failover ist für die Überwachung auf Datenbankebene überregionaler Datenverkehr erforderlich. Dies ist nach der Verschiebung jedoch nicht gewünscht oder möglich.
  6. Stellen Sie für Überwachung auf Serverebene Folgendes sicher:
    • Der Speichercontainer, Log Analytics oder der Event Hub mit den vorhandenen Überwachungsprotokollen wird in die Zielregion verschoben.
    • Die Überwachung ist auf dem Zielserver konfiguriert. Weitere Informationen finden Sie unter Erste Schritte mit der SQL-Datenbanküberwachung.
  7. Wenn für Ihren Server eine Richtlinie für die Langzeitaufbewahrung (LTR) vorhanden ist, bleiben die vorhandenen LTR-Sicherungen dem aktuellen Server zugeordnet. Da ein anderer Zielserver verwendet wird, können Sie über den Quellserver auf die älteren LTR-Sicherungen in der Quellregion zugreifen, selbst wenn der Server gelöscht wird.

Hinweis

Das Migrieren von Datenbanken mit vorhandenen LTR-Sicherungen zwischen souveränen und öffentlichen Regionen wird nicht unterstützt, weil dafür LTR-Sicherungen auf den Zielserver verschoben werden müssen, was derzeit nicht möglich ist.

Vorbereiten der Ressourcen

  1. Erstellen Sie eine Failovergruppe zwischen dem Server der Quelle und dem Server des Ziels.
  2. Fügen Sie die Datenbanken hinzu, die Sie in die Failovergruppe verschieben möchten. Die Replikation aller hinzugefügten Datenbanken wird automatisch initiiert. Weitere Informationen finden Sie unter Verwenden von Failovergruppen mit SQL-Datenbank.

Überwachen des Vorbereitungsprozesses

Sie können in regelmäßigen Abständen Get-AzSqlDatabaseFailoverGroup aufrufen, um die Replikation Ihrer Datenbanken vom Quell- zum Zielserver zu überwachen. Das Ausgabeprojekt von Get-AzSqlDatabaseFailoverGroup umfasst eine Eigenschaft für den ReplicationState:

  • ReplicationState = 2 (CATCH_UP) gibt an, dass die Datenbank synchronisiert ist und das Failover sicher ausgeführt werden kann.
  • ReplicationState = 0 (SEEDING) gibt an, dass das Seeding für die Datenbank noch nicht abgeschlossen ist und bei einem Failover ein Fehler auftritt.

Testen der Synchronisierung

Nachdem ReplicationState den Wert 2 aufweist, stellen Sie eine Verbindung mit den einzelnen Datenbanken oder einer Teilmenge der Datenbanken mit dem sekundären Endpunkt <fog-name>.secondary.database.windows.net her, und führen Sie eine Abfrage der Datenbanken durch, um Konnektivität, die richtige Sicherheitskonfiguration und Datenreplikation sicherzustellen.

Initiieren der Verschiebung

  1. Stellen Sie über den sekundären Endpunkt <fog-name>.secondary.database.windows.net eine Verbindung zum Zielserver her.
  2. Verwenden Sie Switch-AzSqlDatabaseFailoverGroup, um den sekundären Server auf den primären mit vollständiger Synchronisation umzuschalten. Dieser Vorgang wird erfolgreich ausgeführt oder zurückgesetzt.
  3. Vergewissern Sie sich, dass der Befehl erfolgreich abgeschlossen wurde, indem Sie nslook up <fog-name>.secondary.database.windows.net verwenden, um sicherzustellen, dass der DNS CNAME-Eintrag auf die IP-Adresse der Zielregion verweist. Wenn beim Switch-Befehl ein Fehler auftritt, wird CNAME nicht aktualisiert.

Entfernen von Quelldatenbanken

Nachdem der Verschiebe Vorgang abgeschlossen ist, entfernen Sie die Ressourcen in der Quellregion, um unnötige Gebühren zu vermeiden.

  1. Löschen Sie die Failovergruppe mit Remove-AzSqlDatabaseFailoverGroup.
  2. Löschen Sie jede Quelldatenbank mit Remove-AzSqlDatabase für jede der Datenbanken auf dem Quellserver. Dadurch werden die Links für die Georeplikation automatisch beendet.
  3. Löschen Sie den Quellserver mit Remove-AzSqlServer.
  4. Entfernen Sie den Schlüsseltresor, die Überwachungsspeichercontainer, den Event Hub, den Microsoft Entra-Mandanten und andere abhängige Ressourcen, damit Ihnen diese nicht mehr in Rechnung gestellt werden.

Überprüfen der Voraussetzungen zum Verschieben des Pools

  1. Erstellen Sie einen Zielserver für jeden Quellserver.
  2. Konfigurieren Sie die Firewall mit den richtigen Ausnahmen mithilfe von PowerShell.
  3. Konfigurieren Sie die Server mit den richtigen Anmeldedaten. Wenn Sie nicht der Subscription- oder Serveradministrator sind, wenden Sie sich an den Administrator, damit dieser Ihnen die erforderlichen Berechtigungen zuweist. Weitere Informationen finden Sie unter Verwalten der Sicherheit der Azure SQL-Datenbank nach der Notfallwiederherstellung.
  4. Wenn Ihre Datenbanken mit transparenter Datenverschlüsselung verschlüsselt sind und Sie Ihren eigenen Schlüssel in Azure Key Vault verwenden, stellen Sie sicher, dass das richtige Verschlüsselungsmaterial in den Zielregionen bereitgestellt wird.
  5. Erstellen Sie für jeden Quellpool für elastische Datenbanken einen Zielpool, und stellen Sie sicher, dass der Pool in der gleichen Serviceebene, mit dem gleichen Namen und der gleichen Größe angelegt wird.
  6. Wenn die Überwachung auf Datenbankebene aktiviert ist, deaktivieren Sie sie, und aktivieren Sie stattdessen die Überwachung auf Serverebene. Nach dem Failover ist für die Überwachung auf Datenbankebene überregionaler Datenverkehr erforderlich. Dies ist nach der Verschiebung jedoch nicht gewünscht oder möglich.
  7. Stellen Sie für Überwachung auf Serverebene Folgendes sicher:
    • Der Speichercontainer, Log Analytics oder der Event Hub mit den vorhandenen Überwachungsprotokollen wird in die Zielregion verschoben.
    • Die Überwachungskonfiguration ist auf dem Zielserver konfiguriert. Weitere Informationen finden Sie unter SQL-Datenbanküberwachung.
  8. Wenn für Ihren Server eine Richtlinie für die Langzeitaufbewahrung (LTR) vorhanden ist, bleiben die vorhandenen LTR-Sicherungen dem aktuellen Server zugeordnet. Da ein anderer Zielserver verwendet wird, können Sie über den Quellserver auf die älteren LTR-Sicherungen in der Quellregion zugreifen, auch wenn der Server gelöscht wird.

Hinweis

Das Migrieren von Datenbanken mit vorhandenen LTR-Sicherungen zwischen souveränen und öffentlichen Regionen wird nicht unterstützt, weil dafür LTR-Sicherungen auf den Zielserver verschoben werden müssen, was derzeit nicht möglich ist.

Vorbereiten der Verschiebung

  1. Erstellen Sie eine separate Failovergruppe zwischen dem Pool für elastische Datenbanken auf dem Quellserver und dem jeweiligen Gegenstück auf dem Zielserver.

  2. Fügen Sie alle Datenbanken im Pool zur Failovergruppe hinzu. Die Replikation der hinzugefügten Datenbanken wird automatisch initiiert. Weitere Informationen finden Sie unter Verwenden von Failovergruppen mit SQL-Datenbank.

    Hinweis

    Es ist zwar möglich, eine Failovergruppe zu erstellen, die mehrere Pools für elastische Datenbanken umfasst, aber es wird dringend empfohlen, für jeden Pool eine eigene Failovergruppe zu erstellen. Wenn Sie eine große Anzahl von Datenbanken über mehrere Pools für elastische Datenbanken verteilt haben, die Sie verschieben müssen, können Sie die Vorbereitungsschritte parallel ausführen und dann den Verschiebungsschritt parallel starten. Dieser Prozess kann besser skaliert werden und nimmt weniger Zeit in Anspruch als mehrere Pools für elastische Datenbanken in derselben Failovergruppe.

Überwachen des Vorbereitungsprozesses

Sie können in regelmäßigen Abständen Get-AzSqlDatabaseFailoverGroup aufrufen, um die Replikation Ihrer Datenbanken von der Quelle zum Ziel zu überwachen. Das Ausgabeprojekt von Get-AzSqlDatabaseFailoverGroup umfasst eine Eigenschaft für den ReplicationState:

  • ReplicationState = 2 (CATCH_UP) gibt an, dass die Datenbank synchronisiert ist und das Failover sicher ausgeführt werden kann.
  • ReplicationState = 0 (SEEDING) gibt an, dass das Seeding für die Datenbank noch nicht abgeschlossen ist und bei einem Failover ein Fehler auftritt.

Testen der Synchronisierung

Sobald ReplicationState den Wert 2 aufweist, stellen Sie eine Verbindung mit den einzelnen Datenbanken oder einer Teilmenge der Datenbanken mit dem sekundären Endpunkt <fog-name>.secondary.database.windows.net her, und führen Sie eine Abfrage der Datenbanken durch, um Konnektivität, die richtige Sicherheitskonfiguration und Datenreplikation sicherzustellen.

Initiieren der Verschiebung

  1. Stellen Sie über den sekundären Endpunkt <fog-name>.secondary.database.windows.net eine Verbindung zum Zielserver her.
  2. Verwenden Sie Switch-AzSqlDatabaseFailoverGroup, um den sekundären Server auf den primären mit vollständiger Synchronisation umzuschalten. Dieser Vorgang wird entweder erfolgreich ausgeführt oder zurückgesetzt.
  3. Vergewissern Sie sich, dass der Befehl erfolgreich abgeschlossen wurde, indem Sie nslook up <fog-name>.secondary.database.windows.net verwenden, um sicherzustellen, dass der DNS CNAME-Eintrag auf die IP-Adresse der Zielregion verweist. Wenn beim Switch-Befehl ein Fehler auftritt, wird CNAME nicht aktualisiert.

Entfernen der Quellpools für elastische Datenbanken

Nachdem der Verschiebe Vorgang abgeschlossen ist, entfernen Sie die Ressourcen in der Quellregion, um unnötige Gebühren zu vermeiden.

  1. Löschen Sie die Failovergruppe mit Remove-AzSqlDatabaseFailoverGroup.
  2. Löschen Sie jeden Quellpool für elastische Datenbanken auf dem Quellserver mit Remove-AzSqlElasticPool.
  3. Löschen Sie den Quellserver mit Remove-AzSqlServer.
  4. Entfernen Sie den Schlüsseltresor, die Überwachungsspeichercontainer, den Event Hub, den Microsoft Entra-Mandanten und andere abhängige Ressourcen, damit Ihnen diese nicht mehr in Rechnung gestellt werden.

Nächste Schritte

Verwalten Sie Ihre Datenbank nach der Migration.