Condividi tramite

Eseguire la migrazione di un gruppo di disponibilità di SQL Server a più subnet - SQL Server in Macchine virtuali di Azure

  • Articolo

Si applica a: SQL Server su VM di Azure

Questo articolo illustra come eseguire la migrazione di un gruppo di disponibilità Always On da una singola subnet a più subnet per semplificare la connessione al listener in Azure con SQL Server in Macchine virtuali di Azure.

Suggerimento

Esistono molti metodi per distribuire un gruppo di disponibilità. Semplificare la distribuzione ed eliminare la necessità di un servizio di Azure Load Balancer o di un nome di rete distribuito (DNN) per il gruppo di disponibilità AlwaysOn creando le macchine virtuali (VM) di SQL Server in più subnet all'interno della stessa rete virtuale di Azure. Se il gruppo di disponibilità è già stato creato in una singola subnet, è possibile eseguirne la migrazione a un ambiente con più subnet.

Panoramica

I clienti che eseguono SQL Server in Macchine virtuali di Azure possono implementare un gruppo di disponibilità Always On in una singola subnet o in più subnet. Una configurazione su più subnet semplifica l'ambiente del gruppo di disponibilità eliminando la necessità di un servizio di bilanciamento del carico di Azure o di un nome di rete distribuita (DNN) per instradare il traffico al listener nella rete di Azure. Sebbene sia consigliabile usare un approccio con più subnet, è necessario che le stringhe di connessione per un'applicazione usino MultiSubnetFailover = true, che potrebbe non essere possibile immediatamente a causa di modifiche a livello di applicazione.

Se in origine è stato creato un gruppo di disponibilità in una singola subnet e si usa un'istanza di Azure Load Balancer o un nome di rete distribuita per il listener e ora si vuole ridurre la complessità passando a una configurazione con più subnet, è possibile farlo seguendo alcuni passaggi manuali.

Prima di avviare una migrazione di un ambiente esistente, valutare i rischi legati al cambiamento di un ambiente in uso.

Considerare i due metodi seguenti per eseguire la migrazione del gruppo di disponibilità a più subnet:

  • Creare un nuovo ambiente per eseguire test side-by-side
  • Spostare manualmente un gruppo di disponibilità esistente

Attenzione

L'esecuzione di qualsiasi migrazione comporta un certo rischio. Come sempre, si consiglia di eseguire test approfonditi in un ambiente non di produzione prima di passare a un ambiente di produzione.

Nuovo ambiente con test side-by-side

Il primo metodo per passare a un gruppo di disponibilità su più subnet consiste nel configurare un nuovo ambiente. Se si tratta della soluzione scelta, procedere come segue:

  1. Creare nuove macchine virtuali
  2. Creare un nuovo gruppo di disponibilità in una configurazione con più subnet
  3. Eseguire il backup del database corrente e ripristinare il tutto nel nuovo ambiente

Per prima cosa, creare nel nuovo ambiente con più subnet il listener con un nome diverso rispetto all'ambiente con subnet singola esistente. Un listener appena denominato in un nuovo gruppo di disponibilità consente il test side-by-side dell'applicazione (test con più subnet e il servizio di bilanciamento del carico corrente o nome di rete distribuita in uso).

Dopo aver convalidato accuratamente l'ambiente con più subnet, è possibile eseguire il cutover alla nuova infrastruttura. A seconda dell'ambiente (produzione, test), usare una finestra di manutenzione per completare la modifica. Durante la finestra di manutenzione, ripristinare il database nella nuova replica primaria, eliminare il listener del gruppo di disponibilità in entrambi gli ambienti e quindi ricreare il listener nell'ambiente con più subnet usando lo stesso nome del listener precedente, ovvero quello usato nella stringa di connessione dell'applicazione.

La configurazione di un nuovo ambiente in una configurazione con più subnet è ora più semplice con l'esperienza di distribuzione del portale di Azure.

Spostare manualmente un gruppo di disponibilità esistente

L'altra opzione consiste nel passare manualmente dall'ambiente a subnet singola a un ambiente con più subnet. Per eseguire la migrazione tramite questo metodo, sono necessari i prerequisiti seguenti:

  • Un indirizzo IP per ogni computer in una nuova subnet
  • Stringhe di connessione con MultiSubnetFailover = true già in uso

Per eseguire la migrazione del gruppo di disponibilità a una configurazione con più subnet, seguire questa procedura:

  1. Creare una nuova subnet per ogni replica secondaria, perché tutte le macchine virtuali si trovano attualmente nella stessa subnet.

  2. Determinare l'IP del cluster e l'IP del listener per tutti i server nel gruppo di disponibilità. Ad esempio, se si dispone di un gruppo di disponibilità con due nodi, sono disponibili le opzioni seguenti:

    Nome macchina virtuale Subnet IP cluster Listener IP (IP listener)
    VM1 (primaria) 10.1.1.0/24 (subnet esistente) 10.1.1.15 10.1.1.16
    VM2 (secondaria) 10.1.2.0/24 (nuova subnet) 10.1.2.15 10.1.2.16

  3. Aggiungere l'IP del cluster e l'IP del listener al server della replica primaria. L'aggiunta di questi indirizzi IP è un'operazione online.

  4. Nel portale di Azure, spostare il server secondario nella nuova subnet andando alla macchina virtuale > Networking > Interfaccia di rete > Configurazioni IP. Lo spostamento del server in una nuova subnet provoca il riavvio del server della replica secondaria.

  5. Aggiungere l'IP del cluster e l'IP del listener al server della replica secondaria. L'aggiunta di questi indirizzi IP è un'operazione online.

  6. A questo punto, poiché gli indirizzi IP e le subnet sono attivi, è possibile eliminare il servizio di bilanciamento del carico.

  7. Eliminare il listener.

  8. Ignorare questo passaggio se si usa Window Server 2019 o versioni successive. Se si usa Windows Server 2016, aggiungere manualmente gli IP del cluster all'istanza del cluster di failover.

  9. Ricreare il listener con i nuovi IP del listener.

  10. Scaricare il DNS in tutti i server usando il comando ipconfig /flushdns.

Passaggi successivi