Een AlwaysOn-beschikbaarheidsgroep van SQL Server migreren naar Azure VMware Solution

Artikel
01/08/2025

In dit artikel leert u hoe u een SQL Server AlwaysOn-beschikbaarheidsgroep migreert naar Azure VMware Solution. Voor VMware HCX kunt u de VMware vMotion-migratieprocedure volgen.

Microsoft SQL Server (2019 en 2022) is getest met Windows Server (2019 en 2022) Met de virtuele machines die zijn geïmplementeerd in de on-premises omgeving. Windows Server en SQL Server worden geconfigureerd volgens aanbevolen procedures en aanbevelingen van Microsoft en VMware. De on-premises broninfrastructuur was VMware vSphere 7.0 Update 3 en VMware vSAN die wordt uitgevoerd op Dell PowerEdge-servers en Intel Optane P4800X SSD NVMe-apparaten.

Vereisten

Hier volgen de vereisten voor het migreren van uw SQL Server-exemplaar naar Azure VMware Solution.

Controleer en noteer de opslag- en netwerkconfiguratie van elk knooppunt in het cluster.
Back-ups van alle SQL Server-databases onderhouden.
Maak een back-up van de virtuele machine of virtuele machines die als host fungeren voor SQL Server.
Verwijder de virtuele machine uit drS-groepen en -regels (VMware vSphere Distributed Resource Scheduler).
VMware HCX moet worden geconfigureerd tussen uw on-premises datacenter en de azure VMware Solution-privécloud waarop de gemigreerde workloads worden uitgevoerd. Zie de documentatie van Azure VMware Solution voor meer informatie over het configureren van HCX.
Zorg ervoor dat alle netwerksegmenten die worden gebruikt door SQL Server en workloads die deze gebruiken, worden uitgebreid naar uw Azure VMware Solution-privécloud. Zie VMware HCX-netwerkextensie configureren om deze stap te controleren.

VMware HCX via VPN- of ExpressRoute-connectiviteit kan worden gebruikt als de netwerkconfiguratie voor de migratie.

Met VMware HCX via VPN is vanwege de beperkte bandbreedte doorgaans geschikt voor workloads die langere perioden van downtime (zoals niet-productieomgevingen) kunnen ondersteunen.

Voor een van de volgende exemplaren wordt ExpressRoute-connectiviteit aanbevolen voor een migratie:

Productieomgevingen
Workloads met grote databasegrootten
Scenario's waarin downtime moet worden geminimaliseerd, wordt de ExpressRoute-connectiviteit aanbevolen voor de migratie.

In de volgende sectie worden verdere overwegingen voor downtime besproken.

Overwegingen voor downtime

Downtime tijdens een migratie is afhankelijk van de grootte van de database die moet worden gemigreerd en de snelheid van de privénetwerkverbinding met de Azure-cloud. Hoewel migraties van SQL Server-beschikbaarheidsgroepen met minimale downtime van oplossingen kunnen worden uitgevoerd, is het optimaal om de migratie uit te voeren tijdens daluren binnen een vooraf goedgekeurd wijzigingsvenster.

De volgende tabel geeft de geschatte downtime aan voor de migratie van elke SQL Server-topologie.

Scenario	Verwachte downtime	Notes
Zelfstandig EXEMPLAAR van SQL Server	Beperkt	Migratie wordt uitgevoerd met behulp van VMware vMotion, de database is beschikbaar tijdens de migratie, maar het wordt niet aanbevolen om kritieke gegevens tijdens de migratie door te voeren.
AlwaysOn-beschikbaarheidsgroep van SQL Server	Beperkt	De primaire replica is altijd beschikbaar tijdens de migratie van de eerste secundaire replica en de secundaire replica wordt de primaire na de eerste failover naar Azure.
Sql Server AlwaysOn-failoverclusterexemplaren	Hoog	Alle knooppunten van het cluster worden afgesloten en gemigreerd met behulp van koude VMware HCX-migratie. Downtime is afhankelijk van de grootte van de database en de snelheid van het privénetwerk naar de Azure-cloud.

Overwegingen voor quorum van Windows Server-failovercluster

Microsoft SQL Server AlwaysOn-beschikbaarheidsgroepen zijn afhankelijk van een Windows Server-failovercluster. Hiervoor is een quorumstemmechanisme vereist om de samenhang van het cluster te behouden.

Een oneven aantal stemelementen is vereist, wat wordt bereikt door een oneven aantal knooppunten in het cluster of door een witness te gebruiken. Witness kan op drie verschillende manieren worden geconfigureerd:

Schijfwitness
Bestandsshare-witness
Cloudwitness

Als het cluster schijfwitness gebruikt, moet de schijf worden gemigreerd met de rest van de gedeelde clusteropslag met behulp van de procedure die in dit document wordt beschreven.

Als voor het cluster een bestandssharewitness wordt gebruikt die on-premises wordt uitgevoerd, is het type witness voor uw gemigreerde cluster afhankelijk van het Scenario van Azure VMware Solution. Er zijn verschillende opties om rekening mee te houden.

Datacenterextensie: onderhoud de bestandssharewitness on-premises. Uw workloads worden verdeeld over uw datacenter en Azure. Daarom moet de connectiviteit tussen uw datacenter en Azure altijd beschikbaar zijn. In elk geval moet u rekening houden met bandbreedtebeperkingen en dienovereenkomstig plannen.
Datacenter afsluiten: Voor dit scenario zijn er twee opties. In beide opties kunt u de bestandssharewitness on-premises behouden tijdens de migratie, voor het geval u tijdens het proces terugdraait.
- Implementeer een nieuwe bestandssharewitness in uw Azure VMware Solution-privécloud.
- Implementeer een cloudwitness die wordt uitgevoerd in Azure Blob Storage in dezelfde regio als de azure VMware Solution-privécloud.
Herstel na noodgevallen en bedrijfscontinuïteit: voor een noodherstelscenario is de beste en meest betrouwbare optie om een cloudwitness te maken die wordt uitgevoerd in Azure Storage.
Toepassingsmodernisatie: Voor deze use case is de beste optie om een cloudwitness te implementeren.

Zie de documentatie over failoverclustering voor meer informatie over het configureren en beheren van het quorum. Zie Een clusterquorum voor een failovercluster beheren voor informatie over de implementatie van cloudwitness in Azure Blob Storage.

Sql Server AlwaysOn-beschikbaarheidsgroep migreren

Open uw AlwaysOn-beschikbaarheidsgroep met SQL Server Management Studio met behulp van beheerreferenties.
- Selecteer uw primaire replica en open eigenschappen van de beschikbaarheidsgroep.
- Wijzig de beschikbaarheidsmodus in Asynchrone doorvoer alleen voor de replica die moet worden gemigreerd.
- Wijzig de failovermodus in Handmatig voor elk lid van de beschikbaarheidsgroep.
Open de on-premises vCenter Server en ga verder met het HCX-gebied.
Selecteer Onder Services de optie Migratie>migreren.
- Selecteer één virtuele machine waarop de secundaire replica van de database wordt uitgevoerd.
- Stel het vSphere-cluster in de externe privécloud in, die nu als host fungeert voor de gemigreerde SQL Server-VM of VM's als rekencontainer.
- Selecteer het vSAN-gegevensarchief als externe opslag.
- Selecteer een map. Het is niet verplicht, maar wordt aanbevolen om de verschillende workloads in uw Azure VMware Solution-privécloud te scheiden.
- Behoud dezelfde indeling als de bron.
- Selecteer vMotion als migratieprofiel.
- Selecteer in Uitgebreide opties Aangepaste kenmerken migreren.
- Controleer of on-premises netwerksegmenten het juiste externe stretched segment in Azure hebben.
- Selecteer Valideren en zorg ervoor dat alle controles zijn voltooid met de wachtwoordstatus. De meest voorkomende fout is gerelateerd aan de opslagconfiguratie. Controleer opnieuw of er geen virtuele SCSI-controllers zijn met de instelling voor fysiek delen.
- Selecteer Ga om de migratie te starten.
Zodra de migratie is voltooid, opent u de gemigreerde replica en controleert u de connectiviteit met de rest van de leden in de beschikbaarheidsgroep.
Open in SQL Server Management Studio het dashboard beschikbaarheidsgroep en controleer of de replica online wordt weergegeven.
- De status gegevensverlies in de kolom Failovergereedheid wordt verwacht omdat de replica niet is gesynchroniseerd met de primaire tijdens de migratie.
Bewerk de eigenschappen van de beschikbaarheidsgroep opnieuw en stel de beschikbaarheidsmodus weer in op Synchrone doorvoer.
- De secundaire replica begint met het synchroniseren van alle wijzigingen die tijdens de migratie zijn aangebracht in de primaire replica. Wacht totdat deze wordt weergegeven in de gesynchroniseerde status.
Selecteer in het dashboard van de beschikbaarheidsgroep in SSMS de wizard Failover starten.
Selecteer de gemigreerde replica en selecteer Volgende.
Maak in het volgende scherm verbinding met de replica met uw DB-beheerdersreferenties.
Controleer de wijzigingen en selecteer Voltooien om de failoverbewerking te starten.
Controleer de voortgang van de failover in het volgende scherm en selecteer Sluiten wanneer de bewerking is voltooid.
Vernieuw de weergave Objectverkenner in SQL Server Management Studio (SSMS), controleer of het gemigreerde exemplaar nu de primaire replica is.
Herhaal stap 1 tot en met 6 voor de rest van de replica's van de beschikbaarheidsgroep.

Notitie

Migreer één replica tegelijk en controleer of alle wijzigingen na elke migratie worden gesynchroniseerd met de replica. Migreer niet alle replica's tegelijk met hcx-bulkmigratie.
Nadat de migratie van alle replica's is voltooid, opent u uw AlwaysOn-beschikbaarheidsgroep met SQL Server Management Studio.
- Open het dashboard en controleer of er geen gegevensverlies is in een van de replica's en of alles de status Gesynchroniseerd heeft .
- Bewerk de eigenschappen van de beschikbaarheidsgroep en stel de failovermodus in op Automatisch in alle replica's.