Migrieren einer SQL Server-Always On-Failoverclusterinstanz zu Azure VMware Solution

In diesem Artikel wird erläutert, wie Sie eine Instanz eines SQL Server-Failoverclusters zu Azure VMware Solution migrieren. Derzeit unterstützt der Azure VMware Solution-Dienst VMware Hybrid Linked Mode nicht, um eine lokale vCenter Server-Instanz mit einer in Azure VMware Solution ausgeführten Instanz zu verbinden. Aufgrund dieser Einschränkung erfordert dieser Prozess die Verwendung von VMware HCX für die Migration. Weitere Informationen zum Konfigurieren von HCX finden Sie unter Installieren und Aktivieren von VMware HCX in Azure VMware Solution.

VMware HCX unterstützt die Migration von VMs mit SCSI-Controllern im physischen Freigabemodus nicht, die an eine VM angeschlossen sind. Sie können diese Einschränkung jedoch umgehen, indem Sie die in diesem Verfahren gezeigten Schritte ausführen und die kalte VMware HCX-Migration verwenden, um die verschiedenen VMs zu verschieben, die den Cluster bilden.

Hinweis

Für dieses Verfahren muss der Cluster vollständig heruntergefahren werden. Da der SQL Server-Dienst während der Migration nicht verfügbar ist, planen Sie die Downtime entsprechend.

Microsoft SQL Server 2019 und 2022 wurden 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 wurden 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

• Überprüfen und Notieren der Speicher- und Netzwerkkonfiguration der einzelnen Knoten im Cluster
• Überprüfen und Notieren Sie der WSFC-Konfiguration
• Aufbewahren von Sicherungen aller SQL Server-Datenbanken
• Sichern der Cluster-VMs
• Entfernen aller Clusterknoten-VMs aus allen DRS-Gruppen (Distributed Resource Scheduler) und -Regeln, zu denen sie gehören
• 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 Installieren von VMware 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.

Ü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. Für die Migration von SQL Server Always On-Failoverclusterinstanzen zu Azure VMware Solution ist eine vollständige Downtime der Datenbank und aller Clusterknoten erforderlich. Sie sollten die Migration jedoch außerhalb der Spitzenzeiten mit einem genehmigten Änderungsfenster planen.

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

Für Windows Server-Failovercluster ist ein Quorummechanismus für die Verwaltung des Clusters erforderlich.

Verwenden Sie eine ungerade Anzahl von Abstimmungselementen. Dies kann durch eine ungerade Anzahl von Knoten im Cluster oder mithilfe eines Zeugen erreicht werden. Zeugen können auf drei unterschiedliche Arten konfiguriert werden:

• Datenträgerzeuge
• Dateifreigabenzeuge
• Cloudzeuge

Wenn der Cluster einen Datenträgerzeugen verwendet, muss der Datenträger mit dem freigegebenen Clusterspeicher anhand der Anweisungen unter Migrieren des Failoverclusters migriert werden.

Wenn das Cluster einen Dateifreigabenzeugen verwendet, der lokal ausgeführt wird, hängt der Typ des Zeugen für Ihr migriertes Cluster vom Azure VMware Solution-Szenario ab:

• Rechenzentrumserweiterung: Verwalten Sie den Dateifreigabezeugen lokal. Ihre Workloads werden über Ihr Rechenzentrum und Ihre Azure VMware Solution-Instanz verteilt, daher sollte die Konnektivität zwischen beiden 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: In beiden Fällen können Sie den Dateifreigabezeugen während der Migration lokal verwalten, falls Sie 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.

Weitere Informationen zur Quorumkonfiguration und -verwaltung finden Sie in der Dokumentation zum Failoverclustering. Ausführliche Informationen zum Bereitstellen eines Cloudzeugen in Azure Blob Storage finden Sie in der Dokumentation zum Bereitstellen eines Cloudzeugen für einen Failovercluster.

Migrieren eines Failoverclusters

Zur Veranschaulichung verwenden wir in diesem Dokument einen Cluster mit zwei Knoten mit Windows Server 2019 Datacenter und SQL Server 2019 Enterprise. Windows Server 2022 und SQL Server 2022 werden bei diesem Verfahren ebenfalls unterstützt.

1. Beim Herunterfahren des vSphere-Clients der zweite Knoten des Clusters.

2. Greifen Sie auf den ersten Knoten des Clusters zu, und öffnen Sie Failovercluster-Manager.

   • Stellen Sie sicher, dass sich der zweite Knoten den Status Offline hat und dass alle gruppierten Dienste und Speicher der Kontrolle des ersten Knotens unterliegen.

   • Fahren Sie den Cluster herunter.

     

   • Überprüfen Sie, ob alle Clusterdienste erfolgreich und ohne Fehler beendet wurden.

3. Fahren Sie den ersten Knoten des Clusters herunter.

4. Bearbeiten Sie im vSphere-Client die Einstellungen des zweiten Knotens des Clusters.

   • Entfernen Sie alle freigegebenen Datenträger aus der VM-Konfiguration.
   • Stellen Sie sicher, dass das Kontrollkästchen Dateien aus dem Datenspeicher löschen nicht aktiviert ist, da dadurch der Datenträger endgültig aus dem Datenspeicher gelöscht wird. In diesem Fall müssen Sie den Cluster auf der Grundlage einer vorherigen Sicherung wiederherstellen.
   • Legen Sie SCSI-Busfreigabe von Physisch auf Keine für die virtuellen SCSI-Controller fest, die für den freigegebenen Speicher verwendet werden. In der Regel sind diese Controller vom Typ „VMware Paravirtual“.

5. Bearbeiten Sie die Einstellungen des ersten VM-Knotens. Legen Sie SCSI-Busfreigabe von Physisch auf Keine für die virtuellen SCSI-Controller fest.

6. Navigieren Sie auf dem vSphere-Client zum HCX-Plug-In-Bereich. Wählen Sie unter Dienste die Option Migration>Migrieren aus.

   • Wählen Sie den zweiten VM-Knoten aus.
   • Legen Sie den vSphere-Cluster in der privaten Remotecloud fest, die die migrierten SQL Server-VMs als Computecontainer hostet.
   • Wählen Sie vSAN-Datenspeicher als Remotespeicher aus.
   • Wählen Sie einen Ordner aus, wenn Sie die VMs in einem bestimmten Ordner platzieren möchten. 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 Kalte Migration als Migrationsprofil aus.
   • Wählen Sie unter Erweitert 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 SCSI-Controller mit der Einstellung für die physische Freigabe vorhanden sind.
   • Wählen Sie Los aus, und die Migration wird initiiert.

7. Wiederholen Sie den gleichen Vorgang für den ersten Knoten.

8. Greifen Sie auf den Azure VMware Solution vSphere-Client zu, und bearbeiten Sie die Einstellungen des ersten Knotens. Legen Sie sie für den SCSI-Controller oder die Controller, die die gemeinsam genutzten Datenträger verwalten, wieder auf die physische SCSI-Busfreigabe zurück.

9. Bearbeiten Sie die Einstellungen des zweiten Knotens auf dem vSphere-Client.

   • Legen Sie die SCSI-Busfreigabe für den SCSI-Controller, der gemeinsam genutzten Speicher verwaltet, wieder auf „Physisch“ fest.
   • Fügen Sie dem Knoten die freigegebenen Clusterdatenträger als zusätzlichen Speicher hinzu. Weisen Sie sie dem zweiten SCSI-Controller zu.
   • Stellen Sie sicher, dass die gesamte Speicherkonfiguration mit der vor der Migration notierten Konfiguration identisch ist.

10. Schalten Sie den ersten VM-Knoten ein.

11. Greifen Sie mit VMware Remote Console auf den ersten VM-Knoten zu.

    • Überprüfen Sie die VM-Netzwerkkonfiguration, und stellen Sie sicher, dass lokale und Azure-basierte Ressourcen erreichbar sind.

    • Öffnen Sie Failovercluster-Manager, und überprüfen Sie Clusterdienste.

      

12. Schalten Sie den zweiten VM-Knoten ein.

13. Greifen Sie über VMware Remote Console auf den zweiten VM-Knoten zu.

    • Stellen Sie sicher, dass Windows Server den Speicher erreichen kann.
    • Überprüfen Sie im Failovercluster-Manager, ob der Status des zweiten Knotens Online lautet.

14. Stellen Sie mithilfe von SQL Server Management Studio eine Verbindung mit dem Netzwerknamen der SQL Server-Clusterressource her. Vergewissern Sie sich, dass alle Datenbanken online und zugänglich sind.

Überprüfen Sie die Konnektivität mit SQL Server von anderen Systemen und Anwendungen in Ihrer Infrastruktur. Vergewissern Sie sich, dass alle Anwendungen, die die Datenbanken verwenden, weiterhin darauf zugreifen können.

Weitere Informationen

• Aktivieren des Azure-Hybridvorteils für SQL Server in Azure VMware Solution
• Erstellen einer Platzierungsrichtlinie in Azure VMware Solution
• Dokumentation zum Windows Server-Failoverclustering
• Microsoft SQL Server 2019-Dokumentation
• Microsoft SQL Server 2022-Dokumentation
• Technische Dokumentation zu Windows Server
• Planen hochverfügbarer, unternehmenskritischer SQL Server-Bereitstellungen mit VMware vSphere
• VMware KB 100 2951: Tipps für das Konfigurieren von Microsoft SQL Server auf einer VM
• Microsoft SQL Server 2019 in VMware vSphere 7.0: Leistungsstudie
• Architektur von Microsoft SQL Server in VMware vSphere: Leitfaden mit Best Practices
• Setup für Windows Server-Failovercluster in VMware vSphere 7.0