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

Questo articolo illustra come eseguire la migrazione di un gruppo di disponibilità AlwaysOn di SQL Server alla 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 in base alle best practice e alle 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 alla 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 o regola di VMware vSphere Distributed Resource Scheduler (DRS).
VMware HCX deve essere configurato tra il data center locale e il cloud privato della soluzione Azure VMware che esegue i carichi di lavoro di cui si è eseguita la migrazione. Per altre informazioni su come configurare HCX, vedere la documentazione della soluzione Azure VMware.
Assicurarsi che tutti i segmenti di rete usati 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, a causa della larghezza di banda limitata, HCX tramite VPN è in genere adatto per i carichi di lavoro che possono sostenere periodi di inattività più lunghi, ad esempio ambienti non di produzione.

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

Ambienti di produzione
Carichi di lavoro con database di grandi dimensioni
Negli scenari in cui è necessario ridurre al minimo i tempi di inattività, la connettività ExpressRoute è consigliata per la migrazione.

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 il periodo di migrazione, ma è consigliabile non eseguire il commit di dati critici durante la migrazione.
Gruppo di disponibilità Always On di SQL Server	Basso	La replica principale sarà sempre disponibile durante la migrazione della prima replica secondaria e la replica secondaria diventerà la replica principale dopo il failover iniziale in Azure.
Istanza del cluster di failover Always On SQL Server	Alto	Tutti i nodi del cluster vengono arrestati e migrati mediante VMware HCX Cold Migration. 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.

È richiesto un numero dispari di elementi di quorum, ottenibile con un numero dispari di nodi nel cluster o utilizzando un witness. Il Witness 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 testimone di condivisione file in esecuzione nell'ambiente locale, il tipo di testimone per il 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 mantenere il controllo condivisione file in locale durante la migrazione, nel caso in cui sia necessario effettuare un rollback durante il processo.
- Distribuire un nuovo controllo del quorum di condivisione file nel cloud privato di soluzione Azure VMware.
- Distribuire un Cloud witness eseguito in Archiviazione BLOB di Azure nella stessa area geografica del cloud privato di 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 server di controllo cloud in esecuzione in Archiviazione di Azure.
Modernizzazione delle applicazioni: per questo caso d'uso, l'opzione migliore consiste nel distribuire un server di controllo cloud.

Per informazioni sulla configurazione e la gestione del quorum, vedere la documentazione di Failover Clustering. Per informazioni sulla distribuzione del cloud witness nell'Archiviazione BLOB di Azure, vedere Gestire un quorum di cluster per un cluster di failover.

Eseguire la migrazione del gruppo di disponibilità Always On 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 Gruppo di disponibilitàProprietà.
- 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>Eseguire 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 della 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 Valida e verificare che tutti i controlli siano completati con esito positivo. L'errore più comune è correlato alla configurazione di archiviazione. Verificare 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 Perdita di dati nella colonna Idoneità al failover è previsto, poiché la replica non è sincronizzata con il database primario durante la migrazione.
Modificare di nuovo le Proprietà del Gruppo di disponibilità e reimpostare la Modalità di disponibilità su 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 Avviare la procedura guidata di failover.
Selezionare la replica migrata e selezionare Avanti.
Connettersi alla replica nella schermata successiva con le credenziali di amministratore del database.
Esaminare le modifiche e selezionare Fine per avviare l'operazione di failover.
Monitorate l'avanzamento del failover nella schermata successiva. Selezionare Chiudi al termine dell'operazione.
Aggiornare la vista 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 le restanti 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 siano in uno stato sincronizzato .
- Modifica le Proprietà del gruppo di disponibilità e imposta Modalità failover su Automatico in tutte le repliche.

Passaggi successivi

Commenti e suggerimenti

Questa pagina è stata utile?

Last updated on 2026-06-03