Eseguire la migrazione di un'istanza del cluster di failover Always On di SQL Server alla soluzione Azure VMware

Questo articolo illustra come eseguire la migrazione di un'istanza del cluster di failover di SQL Server alla soluzione Azure VMware. Attualmente il servizio soluzione Azure VMware non supporta la modalità collegata ibrida VMware per connettere un server vCenter locale con un server vCenter in esecuzione nella soluzione Azure VMware. A causa di questo vincolo, questo processo richiede l'uso di VMware HCX per la migrazione. Per altre informazioni sulla configurazione di HCX, vedere Installare e attivare VMware HCX nella soluzione Azure VMware.

VMware HCX non supporta la migrazione di macchine virtuali con controller SCSI in modalità di condivisione fisica collegata a una macchina virtuale. Tuttavia, è possibile superare questa limitazione eseguendo i passaggi illustrati in questa procedura e usando VMware HCX Cold Migration per spostare le diverse macchine virtuali che costituiscono il cluster.

Nota

Questa procedura richiede un arresto completo del cluster. Poiché il servizio SQL Server non è disponibile durante la migrazione, pianificare di conseguenza il periodo di inattività.

Microsoft SQL Server 2019 e 2022 sono stati testati con Windows Server 2019 e 2022, Data Center Edition, con le macchine virtuali distribuite nell'ambiente locale. Windows Server e SQL Server sono stati configurati in conformità 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

Esaminare e registrare la configurazione di archiviazione e rete di ogni nodo del cluster.
Esaminare e registrare la configurazione WSFC.
Gestire i backup di tutti i database di SQL Server.
Eseguire il backup delle macchine virtuali del cluster.
Rimuovere tutte le VM dei nodi del cluster da tutti i gruppi e da tutte le regole di Distributed Resource Scheduler (DRS) di cui fanno parte.
Configurare VMware HCX tra il data center locale e il cloud privato soluzione Azure VMware che esegue i carichi di lavoro migrati. Per altre informazioni sull'installazione di VMware 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.

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. La migrazione delle istanze del cluster di failover di SQL Server Always On alla soluzione Azure VMware richiede tempi di inattività completi del database e di tutti i nodi del cluster, ma è consigliabile pianificare l'esecuzione della migrazione durante le ore di minore attività con una finestra di modifica approvata.

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 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

Windows Server Failover Cluster richiede un meccanismo quorum per gestire il cluster.

Usare un numero dispari di elementi di voto, ottenuto tramite un numero dispari di nodi nel cluster o mediante un witness. I testimoni possono essere configurati in tre forme diverse:

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 l'archiviazione condivisa del cluster usando il cluster di failover di migrazione.

Se il cluster usa un filewcondivisione itness in esecuzione on-premises, il tipo di witness per il cluster migrato dipende dallo scenario di soluzione Azure VMware:

Estensione data center: gestire la condivisione file di controllo locale. I carichi di lavoro vengono distribuiti nel data center e nella soluzione Azure VMware, pertanto la connettività tra entrambi 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 entrambi i casi, è possibile mantenere il controllo di condivisione file in locale durante la migrazione nel caso in cui sia necessario effettuare un rollback.
- 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à operativa: per uno scenario di ripristino di emergenza, l'opzione migliore e più affidabile consiste nel creare un Cloud Witness 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 altre informazioni sulla configurazione e la gestione del quorum, vedere la documentazione di Failover Clustering. Per altre informazioni sulla distribuzione di un server di controllo cloud in Archiviazione BLOB di Azure, vedere la documentazione Distribuire un server di controllo cloud per un cluster di failover per informazioni dettagliate.

Eseguire la migrazione del cluster di failover

A scopo illustrativo, in questo documento viene usato un cluster a due nodi con Windows Server 2019 Datacenter e SQL Server 2019 Enterprise. Con questa procedura sono supportati anche Windows Server 2022 e SQL Server 2022.

Dall'arresto del client vSphere, il secondo nodo del cluster.
Accedere al primo nodo del cluster e aprire Gestione cluster di failover.
- Verificare che il secondo nodo sia in stato Offline e che tutti i servizi e l'archiviazione in cluster siano sotto il controllo del primo nodo.
- Arrestare il cluster.
- Verificare che tutti i servizi cluster siano stati arrestati senza errori.
Spegnere il primo nodo del cluster.
Dal client vSphere modificare le impostazioni del secondo nodo del cluster.
- Rimuovere tutti i dischi condivisi dalla configurazione della macchina virtuale.
- Verificare che la casella di controllo Elimina file dall'archivio dati non sia selezionata perché elimina definitivamente il disco dall'archivio dati. In questo caso, è necessario ripristinare il cluster da un backup precedente.
- Impostare Condivisione bus SCSI da fisico a Nessuno nei controller SCSI virtuali usati per l'archiviazione condivisa. In genere, questi controller sono di tipo paravirtuale VMware.
Modificare le impostazioni della prima macchina virtuale del nodo. Impostare Condivisione bus SCSI da Fisico a Nessuno nei controller SCSI.
Dal client vSphere passare all'area del plug-in HCX. In Servizi selezionare Migrazione>Eseguire migrazione.
- Selezionare la macchina virtuale del secondo nodo.
- Impostare il cluster vSphere nel cloud privato remoto, che 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 se si desidera inserire le macchine virtuali in una cartella specifica. Non è obbligatorio, ma è consigliabile separare i diversi carichi di lavoro nel cloud privato della soluzione Azure VMware.
- Mantenere lo stesso formato dell'origine.
- Selezionare Migrazione a freddo come profilo di migrazione.
- In Opzioniestese 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 con impostazione di condivisione fisica.
- Selezionare Vai e viene avviata la migrazione.
Ripetere lo stesso processo per il primo nodo.
Accedere al client vSphere della soluzione Azure VMware e modificare le prime impostazioni del nodo e tornare al bus SCSI fisico che condivide il controller SCSI o i controller che gestiscono i dischi condivisi.
Modificare le impostazioni del nodo 2 in vSphere Client.
- Reimpostare la condivisione del bus SCSI su fisico nel controller SCSI che gestisce lo storage condiviso.
- Aggiungere i dischi condivisi del cluster al nodo come spazio di archiviazione aggiuntivo. Assegnarli al secondo controller SCSI.
- Verificare che la configurazione di archiviazione sia uguale a quella registrata prima della migrazione.
Avviare la macchina virtuale del primo nodo.
Accedere alla prima macchina virtuale nodo con VMware Remote Console.
- Verificare la configurazione della rete delle macchine virtuali e assicurarsi che sia in grado di raggiungere le risorse locali e di Azure.
- Aprire Gestione cluster di failover e verificare i servizi cluster.
Accendere la macchina virtuale del secondo nodo.
Accedere alla seconda macchina virtuale del nodo dalla console remota VMware.
- Verificare che il Windows Server possa raggiungere lo spazio di archiviazione.
- In Gestione cluster di failover, verificare che lo stato del secondo nodo risulti Online.
Usando SQL Server Management Studio, connettersi al nome della rete di risorse del cluster di SQL Server. Verificare che tutti i database siano online e accessibili.

Controllare la connettività a SQL Server da altri sistemi e applicazioni nell'infrastruttura. Verificare che tutte le applicazioni che usano il database o i database possano comunque accedervi.

Ulteriori informazioni

Commenti e suggerimenti

Questa pagina è stata utile?

Last updated on 2026-06-03