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

Articolo
01/08/2025

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 seguendo le procedure consigliate e gli elementi consigliati 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 e regole dell'Utilità di pianificazione delle risorse distribuite (Data Replication Service) VMware vSphere.
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 della 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 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à 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 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 controllo di condivisione file in esecuzione in locale, il tipo di server di controllo del cluster migrato dipende dallo scenario della 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 Controllo di condivisione file nel cloud privato della soluzione Azure VMware.
- Distribuire un server di controllo cloud in esecuzione in Archiviazione BLOB di Azure nella stessa area del cloud privato della 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 dettagliate sulla configurazione e la gestione del quorum, vedere la documentazione sul clustering di failover. Per informazioni sulla distribuzione del server di controllo cloud nell'Archiviazione BLOB di Azure, vedere Gestire un quorum del 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 in Azure il segmento esteso remoto corretto.
- 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 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 selezionareAvvia failover guidato.
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.
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.