Eseguire la migrazione di un gruppo di disponibilità AlwaysOn di SQL Server a soluzione Azure VMware

Articolo
12/18/2023

Questo articolo illustra come eseguire la migrazione di un gruppo di disponibilità Always On di SQL Server a soluzione Azure VMware. Per VMware HCX, è possibile seguire la procedura di migrazione di VMware vMotion.

Microsoft SQL Server (2019 e 2022) è stato testato con Windows Server (2019 e 2022) Data Center Edition con le macchine virtuali distribuite nell'ambiente locale. Windows Server e SQL Server sono configurati seguendo le procedure consigliate e le raccomandazioni di Microsoft e VMware. L'infrastruttura di origine locale era VMware vSphere 7.0 Update 3 e VMware vSAN in esecuzione nei server Dell PowerEdge e nei dispositivi NVMe SSD Intel Optane P4800X.

Prerequisiti

Di seguito sono riportati i prerequisiti per la migrazione dell'istanza di SQL Server a soluzione Azure VMware.

Esaminare e registrare la configurazione di archiviazione e rete di ogni nodo del cluster.
Gestire i backup di tutti i database di SQL Server.
Eseguire il backup della macchina virtuale o delle macchine virtuali che ospitano SQL Server.
Rimuovere la macchina virtuale da qualsiasi gruppo e regole dell'utilità di pianificazione delle risorse distribuite VMware vSphere.
VMware HCX deve essere configurato tra il data center locale e il cloud privato soluzione Azure VMware che esegue i carichi di lavoro migrati. Per altre informazioni su come configurare HCX, vedere soluzione Azure VMware documentazione.
Assicurarsi che tutti i segmenti di rete in uso da SQL Server e i carichi di lavoro che lo usano vengano estesi nel cloud privato soluzione Azure VMware. Per verificare questo passaggio, vedere Configurare l'estensione di rete VMware HCX.

La connettività VMware HCX tramite VPN o ExpressRoute può essere usata come configurazione di rete per la migrazione.

Con VMware HCX tramite VPN, a causa della larghezza di banda limitata, è in genere adatto per i carichi di lavoro che possono sostenere periodi di inattività più lunghi, ad esempio ambienti non di produzione.

Per una delle istanze seguenti, è consigliabile usare la connettività ExpressRoute per una migrazione:

Ambienti di produzione
Carichi di lavoro con dimensioni di database di grandi dimensioni
Per la migrazione è consigliabile ridurre al minimo i tempi di inattività della connettività ExpressRoute.

Altre considerazioni sul tempo di inattività sono illustrate nella sezione successiva.

Considerazioni sul tempo di inattività

Il tempo di inattività durante una migrazione dipende dalle dimensioni del database di cui eseguire la migrazione e dalla velocità della connessione di rete privata al cloud di Azure. Sebbene le migrazioni del gruppo di disponibilità di SQL Server possano essere eseguite con tempi di inattività minimi della soluzione, è consigliabile eseguire la migrazione durante le ore di minore attività entro una finestra di modifica preapprovata.

La tabella seguente indica il tempo di inattività stimato per la migrazione di ogni topologia di SQL Server.

Scenario	Tempo di inattività previsto	Note
Istanza autonoma di SQL Server	Basso	La migrazione viene eseguita usando VMware vMotion, il database è disponibile durante la migrazione, ma non è consigliabile eseguire il commit di dati critici durante il processo.
Gruppo di disponibilità AlwaysOn di SQL Server	Basso	La replica primaria sarà sempre disponibile durante la migrazione della prima replica secondaria e la replica secondaria diventerà la replica primaria dopo il failover iniziale in Azure.
Istanza del cluster di failover AlwaysOn di SQL Server	Alto	Tutti i nodi del cluster vengono arrestati ed è stata eseguita la migrazione tramite la migrazione a freddo di VMware HCX. La durata del tempo di inattività dipende dalle dimensioni del database e dalla velocità della rete privata al cloud di Azure.

Considerazioni sul quorum del cluster di failover di Windows Server

I gruppi di disponibilità Always On di Microsoft SQL Server si basano sul cluster di failover di Windows Server, che richiede un meccanismo di voto quorum per mantenere la coerenza del cluster.

È necessario un numero dispari di elementi di voto, ottenuto da un numero dispari di nodi nel cluster o tramite un server di controllo del mirroring. Il server di controllo del mirroring può essere configurato in tre modi diversi:

Disco di controllo
Condivisione file di controllo
Cloud di controllo

Se il cluster usa il server di controllo del disco, è necessario eseguire la migrazione del disco con il resto dell'archiviazione condivisa del cluster usando la procedura descritta in questo documento.

Se il cluster usa un server di controllo della condivisione file in esecuzione in locale, il tipo di server di controllo del cluster migrato dipende dallo scenario di soluzione Azure VMware, sono disponibili diverse opzioni da considerare.

Estensione data center: gestire la condivisione file di controllo locale. I carichi di lavoro vengono distribuiti nel data center e in Azure. Pertanto, la connettività tra il data center e Azure deve essere sempre disponibile. In ogni caso, prendere in considerazione i vincoli di larghezza di banda e pianificare di conseguenza.
Uscita dal data center: per questo scenario sono disponibili due opzioni. In entrambe le opzioni è possibile gestire la condivisione file di controllo locale durante la migrazione nel caso in cui sia necessario eseguire il rollback durante il processo.
- Distribuire una nuova condivisione file di controllo nel cloud privato soluzione Azure VMware.
- Distribuire un cloud di controllo in esecuzione in Archiviazione BLOB di Azure nella stessa area del cloud privato soluzione Azure VMware.
Ripristino di emergenza e continuità aziendale: per uno scenario di ripristino di emergenza, l'opzione migliore e più affidabile consiste nel creare un cloud di controllo in esecuzione in Archiviazione di Azure.
Modernizzazione delle applicazioni: per questo caso d'uso, l'opzione migliore consiste nel distribuire un cloud di controllo.

Per informazioni dettagliate sulla configurazione e la gestione del quorum, vedere la documentazione sul clustering di failover. Per informazioni sulla distribuzione di Cloud witness in Archiviazione BLOB di Azure, vedere Gestire un quorum del cluster per un cluster di failover.

Eseguire la migrazione del gruppo di disponibilità AlwaysOn di SQL Server

Accedere al gruppo di disponibilità AlwaysOn con SQL Server Management Studio usando le credenziali di amministrazione.
- Selezionare la replica primaria e aprire Proprietà gruppodi disponibilità.
- Modificare la modalità di disponibilità in Commit asincrono solo per la migrazione della replica.
- Impostare Modalità di failover su Manuale per ogni membro del gruppo di disponibilità.
Accedere al server vCenter locale e passare all'area HCX.
In Servizi selezionare Migrazione>migrazione.
- Selezionare una macchina virtuale che esegue la replica secondaria del database di cui verrà eseguita la migrazione.
- Impostare il cluster vSphere nel cloud privato remoto, che ora ospita la macchina virtuale o le macchine virtuali di SQL Server di cui è stata eseguita la migrazione come contenitore di calcolo.
- Selezionare l'archivio dati vSAN come archiviazione remota.
- Selezionare una cartella. Non è obbligatorio, ma è consigliabile separare i diversi carichi di lavoro nel cloud privato soluzione Azure VMware.
- Mantenere lo stesso formato dell'origine.
- Selezionare vMotion come profilo di migrazione.
- In Opzioni estese selezionare Esegui migrazione di attributi personalizzati.
- Verificare che i segmenti di rete locali abbiano il segmento esteso remoto corretto in Azure.
- Selezionare Convalida e verificare che tutti i controlli vengano completati con lo stato del passaggio. L'errore più comune è correlato alla configurazione di archiviazione. Verificare di nuovo che non siano presenti controller SCSI virtuali con l'impostazione di condivisione fisica.
- Selezionare Vai per avviare la migrazione.
Al termine della migrazione, accedere alla replica migrata e verificare la connettività con il resto dei membri nel gruppo di disponibilità.
In SQL Server Management Studio aprire il dashboard del gruppo di disponibilità e verificare che la replica venga visualizzata come online.
- Lo stato della perdita di dati nella colonna Preparazione failover è previsto perché la replica non è sincronizzata con la replica primaria durante la migrazione.
Modificare di nuovo le proprietà del gruppodi disponibilità e impostare di nuovo la modalità di disponibilità sul commit sincrono.
- La replica secondaria inizia a sincronizzare tutte le modifiche apportate alla replica primaria durante la migrazione. Attendere che venga visualizzato nello stato Sincronizzato.
Nel dashboard del gruppo di disponibilità, in SSMS, selezionare Avvia failover guidato.
Selezionare la replica migrata e selezionare Avanti.
Connessione alla replica nella schermata successiva con le credenziali di amministratore del database.
Esaminare le modifiche e selezionare Fine per avviare l'operazione di failover.
Monitorare lo stato del failover nella schermata successiva, selezionare Chiudi al termine dell'operazione.
Aggiornare la visualizzazione Esplora oggetti in SQL Server Management Studio (SSMS), verificare che l'istanza migrata sia ora la replica primaria.
Ripetere i passaggi da 1 a 6 per il resto delle repliche del gruppo di disponibilità.

Nota

Eseguire la migrazione di una replica alla volta e verificare che tutte le modifiche vengano sincronizzate con la replica dopo ogni migrazione. Non eseguire la migrazione di tutte le repliche contemporaneamente usando la migrazione in blocco di HCX.
Al termine della migrazione di tutte le repliche, accedere al gruppo di disponibilità Always On con SQL Server Management Studio.
- Aprire il dashboard e verificare che non si verifichi alcuna perdita di dati in una delle repliche e che tutti si trovino in uno stato sincronizzato .
- Modificare le proprietà del gruppo di disponibilità e impostare Modalità failover su Automatico in tutte le repliche.