Migrera en SQL Server AlwaysOn-tillgänglighetsgrupp till Azure VMware Solution

I den här artikeln får du lära dig hur du migrerar en SQL Server AlwaysOn-tillgänglighetsgrupp till Azure VMware Solution. För VMware HCX kan du följa migreringsproceduren för VMware vMotion.

Diagram som visar arkitekturen för Always On SQL Server för Azure VMware Solution.

Microsoft SQL Server (2019 och 2022) testades med Windows Server (2019 och 2022) Med de virtuella datorerna distribuerade i den lokala miljön. Windows Server och SQL Server är konfigurerade enligt metodtips och rekommendationer från Microsoft och VMware. Den lokala källinfrastrukturen var VMware vSphere 7.0 Update 3 och VMware vSAN som kördes på Dell PowerEdge-servrar och Intel Optane P4800X SSD NVMe-enheter.

Förutsättningar

Följande är kraven för att migrera SQL Server-instansen till Azure VMware Solution.

  • Granska och registrera lagrings- och nätverkskonfigurationen för varje nod i klustret.
  • Underhåll säkerhetskopior av alla SQL Server-databaser.
  • Säkerhetskopiera den virtuella datorn eller virtuella datorer som är värdar för SQL Server.
  • Ta bort den virtuella datorn från alla grupper och regler för VMware vSphere Distributed Resource Scheduler (DRS).
  • VMware HCX måste konfigureras mellan ditt lokala datacenter och det privata Azure VMware Solution-molnet som kör de migrerade arbetsbelastningarna. Mer information om hur du konfigurerar HCX finns i dokumentationen om Azure VMware Solution.
  • Se till att alla nätverkssegment som används av SQL Server och arbetsbelastningar som använder det utökas till ditt privata Azure VMware Solution-moln. Information om hur du verifierar det här steget finns i Konfigurera VMware HCX-nätverkstillägg.

Antingen kan VMware HCX via VPN- eller ExpressRoute-anslutning användas som nätverkskonfiguration för migreringen.

Med VMware HCX över VPN, på grund av dess begränsade bandbredd, passar vanligtvis för arbetsbelastningar som kan upprätthålla längre perioder av stilleståndstid (till exempel icke-produktionsmiljöer).

För någon av följande instanser rekommenderas ExpressRoute-anslutning för en migrering:

  • Produktionsmiljöer
  • Arbetsbelastningar med stora databasstorlekar
  • Scenarier där det finns ett behov av att minimera stilleståndstiden för ExpressRoute-anslutningen rekommenderas för migreringen.

Ytterligare avbrottsöverväganden diskuteras i nästa avsnitt.

Överväganden vid stilleståndstid

Stilleståndstid under en migrering beror på storleken på databasen som ska migreras och hastigheten på den privata nätverksanslutningen till Azure-molnet. Även om migrering av SQL Server-tillgänglighetsgrupp kan utföras med minimal stilleståndstid för lösningen är det optimalt att utföra migreringen under tider med låg belastning inom ett i förväg godkänt ändringsfönster.

Följande tabell anger den uppskattade stilleståndstiden för migrering av varje SQL Server-topologi.

Scenario Stilleståndstid förväntas Anteckningar
Fristående SQL Server-instans Låg Migreringen utförs med VMware vMotion, databasen är tillgänglig under migreringstiden, men vi rekommenderar inte att du checkar in några kritiska data under den.
SQL Server AlwaysOn-tillgänglighetsgrupp Låg Den primära repliken kommer alltid att vara tillgänglig under migreringen av den första sekundära repliken och den sekundära repliken blir den primära efter den första redundansväxlingen till Azure.
SQL Server Alltid på redundansklusterinstans Högt Alla noder i klustret stängs av och migreras med VMware HCX Cold Migration. Stilleståndstiden beror på databasens storlek och privata nätverkshastighet till Azure-molnet.

Kvorumöverväganden för Windows Server-redundanskluster

Microsoft SQL Server AlwaysOn-tillgänglighetsgrupper förlitar sig på Windows Server-redundanskluster, vilket kräver en kvorumröstningsmekanism för att upprätthålla klustrets enhetlighet.

Ett udda antal röstningselement krävs, vilket uppnås med ett udda antal noder i klustret eller med hjälp av ett vittne. Vittnet kan konfigureras på tre olika sätt:

  • Diskvittne
  • Filresursvittne
  • Molnvittne

Om klustret använder Diskvittne måste disken migreras med resten av klustrets delade lagring med hjälp av proceduren som beskrivs i det här dokumentet.

Om klustret använder ett filresursvittne som körs lokalt, beror typen av vittne för det migrerade klustret på scenariot med Azure VMware Solution, det finns flera alternativ att överväga.

  • Datacentertillägg: Underhåll filresursvittnet lokalt. Dina arbetsbelastningar distribueras över ditt datacenter och Azure. Därför bör anslutningen mellan ditt datacenter och Azure alltid vara tillgänglig. Ta i alla fall hänsyn till bandbreddsbegränsningar och planera därefter.
  • Datacenteravslut: I det här scenariot finns det två alternativ. I båda alternativen kan du underhålla filresursvittnet lokalt under migreringen om du behöver återställa under processen.
    • Distribuera ett nytt filresursvittne i ditt privata Azure VMware Solution-moln.
    • Distribuera ett molnvittne som körs i Azure Blob Storage i samma region som det privata azure VMware Solution-molnet.
  • Haveriberedskap och affärskontinuitet: För ett haveriberedskapsscenario är det bästa och mest tillförlitliga alternativet att skapa ett molnvittne som körs i Azure Storage.
  • Programmodernisering: För det här användningsfallet är det bästa alternativet att distribuera ett molnvittne.

Mer information om hur du konfigurerar och hanterar kvorumet finns i dokumentationen om redundansklustring. Information om distribution av molnvittne i Azure Blob Storage finns i Hantera ett klusterkvorum för ett redundanskluster.

Migrera SQL Server Always On-tillgänglighetsgrupp

  1. Få åtkomst till din AlwaysOn-tillgänglighetsgrupp med SQL Server Management Studio med hjälp av autentiseringsuppgifter för administration.

    • Välj din primära replik och öppna Egenskaper för tillgänglighetsgrupp. Diagram som visar egenskaper för AlwaysOn-tillgänglighetsgrupp.
    • Ändra tillgänglighetsläget till Asynkron incheckning endast för repliken som ska migreras.
    • Ändra redundansläge till Manuell för varje medlem i tillgänglighetsgruppen.
  2. Gå till den lokala vCenter-servern och fortsätt till HCX-området.

  3. Under Tjänster väljer du Migreringsmigrering>.

    • Välj en virtuell dator som kör den sekundära repliken av databasen som ska migreras.
    • Ange vSphere-klustret i det fjärranslutna privata molnet, som nu är värd för den migrerade virtuella SQL Server-datorn eller virtuella datorer som beräkningscontainer.
    • Välj vSAN Datastore som fjärrlagring.
    • Välj en mapp. Det är inte obligatoriskt, men vi rekommenderar att du separerar de olika arbetsbelastningarna i ditt privata Azure VMware Solution-moln.
    • Behåll samma format som källan.
    • Välj vMotion som migreringsprofil.
    • I Utökade alternativ väljer du Migrera anpassade attribut.
    • Kontrollera att lokala nätverkssegment har rätt fjärrsträckt segment i Azure.
    • Välj Verifiera och se till att alla kontroller har slutförts med passstatus. Det vanligaste felet gäller lagringskonfigurationen. Kontrollera återigen att det inte finns några virtuella SCSI-styrenheter som har den fysiska delningsinställningen.
    • Välj för att starta migreringen.
  4. När migreringen är klar får du åtkomst till den migrerade repliken och verifierar anslutningen med resten av medlemmarna i tillgänglighetsgruppen.

  5. Öppna instrumentpanelen för tillgänglighetsgrupp i SQL Server Management Studio och kontrollera att repliken visas som Online. Diagram som visar instrumentpanelen för AlwaysOn-tillgänglighetsgrupp.

    • Status för dataförlust i kolumnen Redundansberedskap förväntas eftersom repliken är osynkroniserad med den primära under migreringen.
  6. Redigera egenskaper för tillgänglighetsgruppigen och ange tillgänglighetsläget tillbaka till Synkron incheckning.

    • Den sekundära repliken börjar synkronisera tillbaka alla ändringar som gjorts i den primära repliken under migreringen. Vänta tills det visas i synkroniserat tillstånd.
  7. Välj Starta redundansguiden i SSMS instrumentpanelen för tillgänglighetsgrupp.

  8. Välj den migrerade repliken och välj Nästa.

    Diagram som visar ny primär replikmarkering för AlwaysOn.

  9. Anslut till repliken på nästa skärm med autentiseringsuppgifterna för db-administratören. Diagram som visar en ny anslutning för autentiseringsuppgifter för primär replikadministratör.

  10. Granska ändringarna och välj Slutför för att starta redundansåtgärden.

    Diagram som visar granskning av alwayson-åtgärd för tillgänglighetsgrupp.

  11. Övervaka redundansväxlingens förlopp på nästa skärm och välj Stäng när åtgärden är klar. Diagram som visar att SQL Server AlwaysOn-klustret har slutförts.

  12. Uppdatera vyn Object Explorer i SQL Server Management Studio (SSMS) och kontrollera att den migrerade instansen nu är den primära repliken.

  13. Upprepa steg 1 till 6 för resten av replikerna i tillgänglighetsgruppen.

    Kommentar

    Migrera en replik i taget och kontrollera att alla ändringar synkroniseras tillbaka till repliken efter varje migrering. Migrera inte alla repliker samtidigt med hjälp av HCX-massmigrering.

  14. När migreringen av alla repliker har slutförts får du åtkomst till din AlwaysOn-tillgänglighetsgrupp med SQL Server Management Studio.

    • Öppna instrumentpanelen och kontrollera att det inte finns någon dataförlust i någon av replikerna och att alla är i synkroniserat tillstånd. Diagram som visar tillgänglighetsgruppens instrumentpanel med ny primär replik och alla migrerade sekundära repliker i synkroniserat tillstånd.

    • Redigera egenskaperna för tillgänglighetsgruppen och ange Redundansläge till Automatisk i alla repliker.

      Diagram som visar en inställning för redundans tillbaka till Automatisk för alla repliker.

Nästa steg