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 nella macchina virtuale di Azure

Questo articolo illustra come eseguire la migrazione del 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 bilanciamento del carico di Azure 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à AlwaysOn in una singola subnet o in più subnet (multi-subnet). Una configurazione su più subnet semplifica l'ambiente del gruppo di disponibilità rimuovendo 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 stringa 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 DNN per il listener e ora si vuole ridurre la complessità passando a una configurazione con più subnet, è possibile farlo con alcuni passaggi manuali.

Prima di avviare una migrazione di un ambiente esistente, valutare i rischi di cambiare un ambiente in uso.

Considerare i due modi 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, quindi come sempre 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 route scelta, è necessario:

  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 ripristinarli nel nuovo ambiente

Inizialmente nel nuovo ambiente con più subnet creare il listener con un nome diverso rispetto all'ambiente a subnet singola esistente. Un listener appena denominato in un nuovo gruppo di disponibilità consente il test side-by-side dell'applicazione (test con la multi-subnet e il servizio di bilanciamento del carico corrente o DNN sul posto).

Dopo aver convalidato accuratamente l'ambiente con più subnet, è possibile passare 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, rimuovere 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, quello usato nell'applicazione stringa di connessione.

La configurazione di un nuovo ambiente in una configurazione con più subnet è ora più semplice con l'esperienza di distribuzione 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 ion già in usoMultiSubnetFailover = true

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

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

  2. Determinare l'IP del cluster e l'indirizzo 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 (primario) 10.1.1.0/24 (subnet esistente) 10.1.1.15 10.1.1.16
    VM2 (secondario) 10.1.2.0/24 (nuova subnet) 10.1.2.15 10.1.2.16

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

  4. Nella portale di Azure spostare il server secondario nella nuova subnet passando alle configurazioni IP dell'interfaccia > di rete della macchina >> virtuale. Lo spostamento del server in una nuova subnet riavvia il server di replica secondario.

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

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

  7. Eliminare il listener.

  8. Se si usa Windows Server 2019 e versioni successive, ignorare questo passaggio. Se si usa Windows Server 2016, aggiungere manualmente gli INDIRIZZI IP del cluster all'istanza del cluster di failover.

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

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

Passaggi successivi