Condividi tramite

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

  • Articolo

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.

Diagramma che mostra l'architettura del failover di SQL Server per la soluzione Azure VMware.

Nota

Questa procedura richiede un arresto completo del cluster. Poiché il servizio SQL Server non sarà 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 attenendosi alle procedure consigliate e agli 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

  • 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 macchine virtuali del nodo del cluster da tutti i gruppi di Utilità di pianificazione delle risorse distribuite (DRS) e le regole di cui fanno parte.
  • 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 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 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.

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

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

Usare un numero dispari di elementi di voto per ottenere un numero dispari di nodi nel cluster o usando un server di controllo del mirroring. 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 fileserver di controllo della condivisione in esecuzione in locale, il tipo di server di controllo del cluster migrato dipende dallo scenario della 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 gestire la condivisione file di controllo locale durante la migrazione nel caso in cui sia necessario eseguire il rollback.
    • 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 altre informazioni sulla configurazione e la gestione del quorum, vedere la documentazione sul clustering di failover. 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.

  1. Dall'arresto del client vSphere, il secondo nodo del cluster.

  2. 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. Diagramma che mostra la verifica dell'archiviazione cluster di Gestione cluster di failover di Windows Server.

    • Arrestare il cluster.

      Diagramma che mostra un cluster di arresto con Gestione cluster di failover di Windows Server.

    • Verificare che tutti i servizi cluster siano stati arrestati senza errori.

  3. Arrestare il primo nodo del cluster.

  4. Dal client vSphere modificare le impostazioni del secondo nodo del cluster.

    • Rimuovere tutti i dischi condivisi dalla configurazione della macchina virtuale.
    • Assicurarsi 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.

  5. Modificare le impostazioni della prima macchina virtuale del nodo. Impostare Condivisione bus SCSI da Fisico a Nessuno nei controller SCSI.

  6. Dal client vSphere passare all'area del plug-in HCX. In Servizi selezionare Migrazione>Eseguire migrazione.

    • Selezionare la seconda macchina virtuale 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 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 con impostazione di condivisione fisica.
    • Selezionare Vai e viene avviata la migrazione.

  7. Ripetere lo stesso processo per il primo nodo.

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

  9. Modificare le impostazioni del nodo 2 in vSphere Client.

    • Impostare la condivisione del bus SCSI su fisico nel controller SCSI che gestisce l'archiviazione condivisa.
    • Aggiungere i dischi condivisi del cluster al nodo come spazio di archiviazione aggiuntivo. Assegnarli al secondo controller SCSI.
    • Assicurarsi che tutta la configurazione di archiviazione sia uguale a quella registrata prima della migrazione.

  10. Accendere la prima macchina virtuale del nodo.

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

      Diagramma che mostra un riepilogo del cluster in Gestione cluster di failover.

  12. Accendere la seconda macchina virtuale del nodo.

  13. Accedere alla seconda macchina virtuale del nodo dalla console remota VMware.

    • Verificare che Windows Server possa raggiungere lo spazio di archiviazione.
    • In Gestione cluster di failover verificare che il secondo nodo venga visualizzato come stato online. Diagramma che mostra lo stato di un nodo del cluster in Gestione cluster di failover.

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

Il diagramma mostra una verifica della connessione di SQL Server Management Studio al database dell'istanza del cluster migrato.

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