Migrace skupiny dostupnosti AlwaysOn SQL Server na Řešení Azure VMware

V tomto článku se dozvíte, jak migrovat skupinu dostupnosti SQL Server AlwaysOn na Řešení Azure VMware. V případě VMware HCX můžete postupovat podle postupu migrace VMware vMotion.

Diagram znázorňující architekturu funkce AlwaysOn SQL Server pro Řešení Azure VMware.

Microsoft SQL Server (2019 a 2022) byla testována s edicí datacentra Windows Server (2019 a 2022) s virtuálními počítači nasazenými v místním prostředí. Windows Server a SQL Server se konfigurují podle osvědčených postupů a doporučení z Microsoft a VMware. Místní zdrojová infrastruktura byla VMware vSphere 7.0 Update 3 a VMware vSAN spuštěná na serverech Dell PowerEdge a zařízení NVMe ssd Intel Optane P4800X.

Prerequisites

Níže jsou uvedené požadavky na migraci instance SQL Server na Řešení Azure VMware.

  • Zkontrolujte a zaznamenejte konfiguraci úložiště a sítě každého uzlu v clusteru.
  • Udržujte zálohy všech databází SQL Server.
  • Zálohujte virtuální počítač nebo virtuální počítače hostující SQL Server.
  • Odeberte virtuální počítač ze všech skupin a pravidel plánovače distribuovaných prostředků VMware vSphere.
  • Mezi místním datacentrem a privátním cloudem Řešení Azure VMware, který spouští migrované úlohy, musí být nakonfigurovaný VMware HCX. Další informace o konfiguraci HCX najdete v Řešení Azure VMware dokumentaci.
  • Ujistěte se, že všechny síťové segmenty používané službou SQL Server a úlohami, které ji používají, byly rozšířeny do privátního cloudu Řešení Azure VMware. Pokud chcete tento krok ověřit, přečtěte si téma Konfigurace síťového rozšíření VMware HCX.

Jako konfiguraci sítě pro migraci je možné použít připojení VMware HCX přes VPN nebo ExpressRoute.

Nasazení VMware HCX přes VPN je kvůli omezené šířce pásma obvykle vhodné pro úlohy, které snesou delší dobu nedostupnosti (jako jsou neprodukční prostředí).

Pro některou z následujících instancí se pro migraci doporučuje připojení ExpressRoute:

  • Produkční prostředí
  • Úlohy s velkými velikostmi databází
  • Pro migraci se ve scénářích, kde je třeba minimalizovat prostoje, doporučuje konektivita ExpressRoute.

Další aspekty výpadků jsou popsány v další části.

Důležité informace o výpadku

Výpadek během migrace závisí na velikosti databáze, která se má migrovat, a rychlosti připojení privátní sítě do Azure cloudu. I když lze migrace skupin dostupnosti SQL Serveru provést s minimálním výpadkem řešení, je optimální provést migraci mimo špičku v předem schváleném okně pro změny.

Následující tabulka uvádí odhadovaný výpadek migrace jednotlivých SQL Server topologie.

Scenario Očekávaný výpadek Notes
SQL Server samostatné instance Nízký Migrace se provádí pomocí VMware vMotion. Databáze je k dispozici během migrace, ale doporučuje se během ní ne commitovat žádná důležitá data.
SQL Server Always On skupina dostupnosti Nízký Primární replika bude během migrace první sekundární repliky vždy dostupná a sekundární replika se po počátečním převzetí služeb při selhání do prostředí Azure stane primární replikou.
Instance clusteru s podporou převzetí služeb při selhání Always On v SQL Serveru Vysoká Všechny uzly clusteru se vypínají a migrují pomocí studené migrace VMware HCX. Doba trvání výpadku závisí na velikosti databáze a rychlosti privátní sítě pro Azure cloudu.

Požadavky na kvorum clusteru s podporou převzetí služeb při selhání ve Windows Serveru

Skupiny dostupnosti Always On v Microsoft SQL Serveru využívají cluster s podporou převzetí služeb při selhání systému Windows Server, který vyžaduje hlasovací mechanismus kvora pro zachování konzistence clusteru.

Je vyžadován lichý počet hlasovacích prvků, čehož lze dosáhnout lichým počtem uzlů v clusteru nebo použitím svědka. Witness lze nakonfigurovat třemi různými způsoby:

  • Diskový svědek
  • Svědek sdílení souborů
  • Cloudový svědek

Pokud cluster používá diskového svědka, musí být i tento disk migrován spolu se zbytkem sdíleného úložiště clusteru pomocí postupu popsaného v tomto dokumentu.

Pokud cluster používá svědka na sdílené složce provozovaného v místním prostředí, pak typ svědka pro váš migrovaný cluster závisí na scénáři Řešení Azure VMware; je třeba zvážit několik možností.

  • Přípona datacentra: Udržovat sdílenou složku s kopií clusteru místně. Vaše úlohy se distribuují napříč vaším datacentrem a Azure. Připojení mezi vaším datacentrem a Azure by proto mělo být vždy dostupné. V každém případě vezměte v úvahu omezení šířky pásma a odpovídajícím způsobem naplánujte.
  • Konec datacentra: Pro tento scénář existují dvě možnosti. U obou možností můžete během migrace zachovat svědka na sdílené složce v místním prostředí pro případ, že bude v průběhu procesu potřeba provést vrácení změn.
    • Nasaďte do privátního cloudu Řešení Azure VMware nového svědka sdílené složky.
    • Nasaďte Cloud Witness spuštěný v Azure Blob Storage ve stejné oblasti jako privátní cloud Řešení Azure VMware.
  • Obnovení po havárii a kontinuita podnikání: Pro scénář obnovení po havárii je nejlepší a nejspolehlivější možností vytvořit Cloud Witness spuštěnou v Azure Storage.
  • Modernizace aplikací: Pro tento případ použití je nejlepší volbou nasadit Cloud Witness.

Podrobnosti o konfiguraci a správě kvóra najdete v dokumentaci k Failover Clustering. Informace o nasazení cloudového svědka v Azure Blob Storage najdete v tématu Správa kvora clusteru pro cluster s podporou převzetí služeb při selhání.

Migrujte skupinu dostupnosti Always On v SQL Serveru

  1. Přístup ke skupině dostupnosti AlwaysOn pomocí SQL Server Management Studio pomocí přihlašovacích údajů pro správu.

    • Vyberte primární repliku a otevřete Skupina dostupnostiVlastnosti. Diagram znázorňující vlastnosti skupiny dostupnosti AlwaysOn
    • Změňte režim dostupnosti na asynchronní potvrzení pouze pro migrovanou repliku.
    • Změňte režim převzetí služeb při selhání na Ruční pro každého člena skupiny dostupnosti.

  2. Přejděte k místnímu vCenter Serveru a přejděte do oblasti HCX.

  3. V části Služby vyberte Migrace>Migrovat.

    • Vyberte jeden virtuální počítač, na kterém bude spuštěna sekundární replika databáze, která se bude migrovat.
    • Nastavte cluster vSphere ve vzdáleném privátním cloudu, na kterém nyní běží migrovaný virtuální počítač SQL Serveru nebo migrované virtuální počítače SQL Serveru, jako Compute Container.
    • Vyberte úložiště dat vSAN jako vzdálené úložiště.
    • Vyberte složku. Není to povinné, ale doporučuje se oddělit různé úlohy ve vašem Řešení Azure VMware privátním cloudu.
    • Zachovat stejný formát jako zdroj
    • Jako profil migrace vyberte vMotion.
    • V rozšířených možnostech vyberte Migrovat vlastní atributy.
    • Ověřte, že místní síťové segmenty mají ve Azure správný vzdálený roztažený segment.
    • Vyberte Ověřit a ujistěte se, že všechny kontroly mají stav Úspěšné. Nejběžnější chyba souvisí s konfigurací úložiště. Ověřte, že neexistují žádné virtuální řadiče SCSI, které mají nastavení fyzického sdílení.
    • Vyberte možnost Spustit a zahajte migraci.

  4. Po dokončení migrace přejděte k migrované replice a ověřte připojení ke zbývajícím členům ve skupině dostupnosti.

  5. V SQL Server Management Studio otevřete řídicí panel skupiny dostupnosti a ověřte, že se replika zobrazí jako Online. Diagram znázorňující řídicí panel skupiny dostupnosti AlwaysOn

    • Stav ztráty dat ve sloupci Připravenost při selhání se očekává, protože replika není synchronizovaná s primárním serverem během migrace.

  6. Znovu upravte vlastnostiskupiny dostupnosti a nastavte režim dostupnosti zpět na synchronní potvrzení.

    • Sekundární replika začne synchronizovat všechny změny provedené v primární replice během migrace. Počkejte, až se zobrazí v synchronizovaném stavu.

  7. V nástroji SSMS na řídicím panelu skupiny dostupnosti vyberte možnost Spustit průvodce převzetím služeb při selhání.

  8. Vyberte migrovanou repliku a vyberte Další.

    Diagram znázorňující nový způsob výběru primární repliky pro Always On.

  9. Připojte se k replice na další obrazovce pomocí přihlašovacích údajů správce databáze. Diagram znázorňující připojení nových přihlašovacích údajů správce primární repliky

  10. Zkontrolujte změny a vyberte Dokončit. Tím spustíte operaci převzetí služeb při selhání.

    Diagram znázorňující přehled fungování skupiny dostupnosti Always On.

  11. Sledujte průběh převzetí služeb po selhání na následující obrazovce. Po dokončení operace vyberte Zavřít . Diagram zobrazující úspěšné dokončení clusteru SQL Server AlwaysOn.

  12. Aktualizujte zobrazení Průzkumník objektů v SQL Server Management Studio (SSMS). Ověřte, že migrovaná instance je teď primární replikou.

  13. Opakujte kroky 1 až 6 pro ostatní repliky skupiny dostupnosti.

    Poznámka

    Migrujte vždy jednu repliku a po každé migraci ověřte, že se všechny změny synchronizují zpět do repliky. Nemigrujte všechny repliky současně pomocí hromadné migrace HCX.

  14. Po dokončení migrace všech replik přejděte ke skupině dostupnosti AlwaysOn pomocí SQL Server Management Studio.

    • Otevřete řídicí panel a ověřte, že v žádné replice nedošlo ke ztrátě dat a všechny jsou v synchronizovaném stavu. Diagram znázorňující řídicí panel skupiny dostupnosti s novou primární replikou a všemi migrovanými sekundárními replikami v synchronizovaném stavu

    • Upravte vlastnosti skupiny dostupnosti a nastavte režim převzetí služeb při selhání na automaticky ve všech replikách.

      Diagram zobrazující nastavení zpětného převzetí služeb při selhání na možnost Automatické pro všechny repliky.

Další kroky

  • Last updated on