Migrieren einer SQL Server Always On-Verfügbarkeitsgruppe zu Azure VMware Solution

Artikel
05/08/2024

In diesem Artikel erfahren Sie, wie Sie eine SQL Server Always On-Verfügbarkeitsgruppe zu Azure VMware Solution migrieren. Für VMware HCX können Sie das VMware vMotion-Migrationsverfahren befolgen.

Microsoft SQL Server (2019 und 2022) wurde mit Windows Server 2019 und 2022 Data Center Edition mit den VMs getestet, die in der lokalen Umgebung bereitgestellt wurden. Windows Server und SQL Server werden gemäß bewährten Methoden und Empfehlungen von Microsoft und VMware konfiguriert. Die lokale Quellinfrastruktur bestand aus VMware vSphere 7.0 Update 3 und VMware vSAN, die auf Dell PowerEdge-Servern und Intel Optane P4800X SSD NVMe-Geräten ausgeführt wurden.

Voraussetzungen

Im Folgenden sind die Voraussetzungen für die Migration Ihrer SQL Server-Instanz zu Azure VMware Solution aufgeführt.

Überprüfen und Notieren der Speicher- und Netzwerkkonfiguration der einzelnen Knoten im Cluster
Aufbewahren von Sicherungen aller SQL Server-Datenbanken
Sichern der VMs, auf denen SQL Server gehostet wird
Entfernen der VM aus allen DRS-Gruppen (Distributed Resource Scheduler) und -Regeln in VMware vSphere
VMware HCX muss zwischen dem lokalen Rechenzentrum und der privaten Azure VMware Solution-Cloud konfiguriert werden, in der die migrierten Workloads ausgeführt werden. Weitere Informationen zum Konfigurieren von HCX finden Sie in der Azure VMware Solution-Dokumentation.
Sicherstellen, dass alle Netzwerksegmente, die von SQL Server und Workloads verwendet werden, in Ihre private Azure VMware Solution-Cloud erweitert werden. Informationen zum Überprüfen dieses Schritts finden Sie unter Konfigurieren der VMware HCX-Netzwerkerweiterung.

Als Netzwerkkonfiguration für die Migration kann entweder VMware HCX über VPN oder ExpressRoute-Konnektivität verwendet werden.

VMware HCX über VPN ist aufgrund seiner begrenzten Bandbreite in der Regel für Workloads geeignet, die längere Downtime (z. B. Nichtproduktionsumgebungen) verkraften können.

Bei den folgenden Instanzen wird ExpressRoute-Konnektivität für eine Migration empfohlen:

Produktionsumgebungen
Workloads mit großen Datenbankgrößen
Szenarien, in denen Downtime minimiert werden muss, wird ExpressRoute-Konnektivität für die Migration empfohlen.

Weitere Überlegungen zur Downtime werden im nächsten Abschnitt erläutert.

Überlegungen im Zusammenhang mit der Downtime

Die Downtime während einer Migration hängt von der Größe der zu migrierenden Datenbank und der Geschwindigkeit der privaten Netzwerkverbindung mit der Azure-Cloud ab. Die Migration von SQL Server-Verfügbarkeitsgruppen kann zwar mit minimaler Lösungsdowntime ausgeführt werden, aber es ist optimal, die Migration außerhalb der Spitzenzeiten innerhalb eines vorab genehmigten Änderungsfensters auszuführen.

In der folgenden Tabelle ist die geschätzte Downtime für die Migration der einzelnen SQL Server-Topologien angegeben.

Szenario	Erwartete Downtime	Hinweise
Eigenständige SQL Server-Instanz	Niedrig	Die Migration erfolgt mithilfe von VMware vMotion. Die Datenbank ist während der Migration verfügbar, es wird jedoch nicht empfohlen, während der Migration kritische Daten zu committen.
SQL Server Always On-Verfügbarkeitsgruppe	Niedrig	Das primäre Replikat ist während der Migration des ersten sekundären Replikats immer verfügbar, und das sekundäre Replikat wird nach dem anfänglichen Failover zu Azure zum primären Replikat.
SQL Server Always On-Failoverclusterinstanz	Hoch	Alle Knoten des Clusters werden heruntergefahren und mit der kalten VMware HCX-Migration migriert. Die Dauer der Downtime hängt von der Datenbankgröße und der Geschwindigkeit des privaten Netzwerks in der Azure-Cloud ab.

Überlegungen zum Quorum für Windows Server-Failovercluster

Microsoft SQL Server Always On-Verfügbarkeitsgruppen basieren auf Windows Server-Failoverclustern, was einen Quorumabstimmungsmechanismus erfordert, um die Kohärenz des Clusters aufrechtzuerhalten.

Eine ungerade Anzahl von Abstimmungselementen ist erforderlich. Dies wird durch eine ungerade Anzahl von Knoten im Cluster oder mithilfe eines Zeugen erreicht. Der Zeuge auf drei unterschiedliche Arten konfiguriert werden:

Datenträgerzeuge
Dateifreigabenzeuge
Cloudzeuge

Wenn der Cluster einen Datenträgerzeugen verwendet, muss der Datenträger mit dem restlichen freigegebenen Clusterspeicher anhand des in diesem Dokument beschriebenen Verfahrens migriert werden.

Wenn der Cluster einen Dateifreigabenzeugen verwendet, der lokal ausgeführt wird, hängt der Typ des Zeugen für Ihren migrierten Cluster vom Azure VMware Solution-Szenario ab. Es gibt verschiedene Optionen zu berücksichtigen:

Rechenzentrumserweiterung: Verwalten Sie den Dateifreigabezeugen lokal. Ihre Workloads werden im Rechenzentrum und in Azure verteilt. Daher muss die Konnektivität zwischen Ihrem Rechenzentrum und Azure immer verfügbar sein. Berücksichtigen Sie in jedem Fall Bandbreiteneinschränkungen, und planen Sie entsprechend.
Auflösung des Rechenzentrums: In diesem Szenario gibt es zwei Optionen: Bei beiden Optionen können Sie den Dateifreigabezeugen während der Migration lokal verwalten, falls Sie während des Vorgangs ein Rollback ausführen müssen.
- Stellen Sie einen neuen Dateifreigabezeugen in Ihrer privaten Azure VMware Solution-Cloud bereit.
- Stellen Sie einen in Azure Blob Storage ausgeführten Cloudzeugen in derselben Region wie die private Azure VMware Solution-Cloud bereit.
Notfallwiederherstellung und Geschäftskontinuität: Für ein Notfallwiederherstellungsszenario besteht die beste und zuverlässigste Option darin, einen Cloudzeugen zu erstellen, der in Azure Storage ausgeführt wird.
Anwendungsmodernisierung: Für diesen Anwendungsfall besteht die beste Option darin, einen Cloudzeugen bereitzustellen.

Ausführliche Informationen zum Konfigurieren und Verwalten des Quorums finden Sie in der Dokumentation zum Failoverclustering. Informationen zur Bereitstellung von Cloudzeugen in Azure Blob Storage finden Sie unter Verwalten eines Clusterquorums für einen Failovercluster.

Migrieren einer SQL Server-Always On-Verfügbarkeitsgruppe

Greifen Sie mit SQL Server Management Studio unter Verwendung von Administratoranmeldeinformationen auf Ihre Always On-Verfügbarkeitsgruppe zu.
- Wählen Sie Ihr primäres Replikat aus, und öffnen Sie Verfügbarkeitsgruppe Eigenschaften.
- Ändern Sie Verfügbarkeitsmodus nur für das zu migrierende Replikat in Asynchroner Commit.
- Ändern Sie Failovermodus für jedes Mitglied der Verfügbarkeitsgruppe in Manuell.
Greifen Sie auf die lokale vCenter Server-Instanz zu, und gehen Sie zum HCX-Bereich.
Wählen Sie unter Dienste die Option Migration>Migrieren aus.
- Wählen Sie eine VM aus, auf der das sekundäre Replikat der Datenbank ausgeführt wird, die migriert werden soll.
- Legen Sie den vSphere-Cluster in der privaten Remotecloud fest, die jetzt die migrierten SQL Server-VMs als Computecontainer hostet.
- Wählen Sie vSAN-Datenspeicher als Remotespeicher aus.
- Wählen Sie einen Ordner aus. Es ist zwar nicht obligatorisch, aber es wird empfohlen, die verschiedenen Workloads in Ihrer privaten Azure VMware Solution-Cloud zu trennen.
- Behalten Sie das gleiche Format bei, das auch die Quelle hat.
- Wählen Sie vMotion als Migrationsprofil aus.
- Wählen Sie unter Erweiterte Optionen die Option Benutzerdefinierte Attribute migrieren aus.
- Stellen Sie sicher, dass lokale Netzwerksegmente das richtige Remotestretchingsegment in Azure aufweisen.
- Wählen Sie Überprüfen aus, und stellen Sie sicher, dass alle Überprüfungen mit dem Status „Bestanden“ abgeschlossen wurden. Der häufigste Fehler tritt im Zusammenhang mit der Speicherkonfiguration auf. Vergewissern Sie sich erneut, dass keine virtuellen SCSI-Controller mit der Einstellung für die physische Freigabe vorhanden sind.
- Wählen Sie Los aus, um die Migration zu starten.
Nachdem die Migration abgeschlossen ist, greifen Sie auf das migrierte Replikat zu, und überprüfen Sie die Verbindung mit den restlichen Mitgliedern in der Verfügbarkeitsgruppe.
Öffnen Sie in SQL Server Management Studio das Dashboard „Verfügbarkeitsgruppe“, und stellen Sie sicher, dass das Replikat als Online angezeigt wird.
- Der Status Datenverlust in der Spalte Failoverbereitschaft wird erwartet, da das Replikat während der Migration nicht mit dem primären Element synchronisiert ist.
Bearbeiten Sie erneut die Eigenschaften derVerfügbarkeitsgruppe und legen Sie den Verfügbarkeitsmodus wieder auf Synchroner Commit fest.
- Das sekundäre Replikat beginnt erneut mit der Synchronisierung aller Änderungen, die während der Migration am primären Replikat vorgenommen wurden. Warten Sie, bis der Status „Synchronisiert“ angezeigt wird.
Wählen Sie in SSMS auf dem Dashboard „Verfügbarkeitsgruppe“ die Option Failover-Assistenten starten aus.
Wählen Sie das migrierte Replikat und dann Weiter aus.
Stellen Sie auf dem nächsten Bildschirm mit Ihren DB-Administratoranmeldeinformationen eine Verbindung mit dem Replikat her.
Überprüfen Sie die Änderungen, und wählen Sie Fertig stellen aus, um den Failovervorgang zu starten.
Überwachen Sie den Fortschritt des Failovers auf dem nächsten Bildschirm, und wählen Sie Schließen aus, wenn der Vorgang abgeschlossen ist.
Aktualisieren Sie die Ansicht im Objekt-Explorer in SQL Server Management Studio (SSMS), und überprüfen Sie, ob die migrierte Instanz jetzt das primäre Replikat ist.
Wiederholen Sie die Schritte 1 bis 6 für die restlichen Replikate der Verfügbarkeitsgruppe.

Hinweis

Migrieren Sie jeweils ein Replikat, und stellen Sie sicher, dass nach jeder Migration alle Änderungen wieder mit dem Replikat synchronisiert werden. Migrieren Sie nicht alle Replikate gleichzeitig mit der HCX-Massenmigration.
Nachdem die Migration aller Replikate abgeschlossen wurde, greifen Sie mit SQL Server Management Studio auf Ihre Always On-Verfügbarkeitsgruppe zu.
- Öffnen Sie das Dashboard, und stellen Sie sicher, dass kein Datenverlust bei den Replikaten auftritt und alle den Status Synchronisiert haben.
- Bearbeiten Sie die Eigenschaften der Verfügbarkeitsgruppe, und legen Sie Failovermodus für alle Replikate auf Automatisch fest.