Gruppi di disponibilità AlwaysOn in SQL Server su macchine virtuali di Azure

Articolo
03/28/2024

Questo articolo presenta i gruppi di disponibilità AlwaysOn per SQL Server in Macchine virtuali di Azure.

Per iniziare, vedere l'esercitazione sul gruppo di disponibilità.

Panoramica

I gruppi di disponibilità AlwaysOn in Macchine virtuali di Azure sono simili ai gruppi di disponibilità AlwaysOn locali e si basano sul cluster di failover di Windows Server sottostante. Tuttavia, poiché le macchine virtuali sono ospitate in Azure, è necessario considerare anche altri aspetti, come la ridondanza di VM e il traffico di routing nella rete di Azure.

Il diagramma seguente illustra un gruppo di disponibilità per SQL Server in Macchine virtuali di Azure:

Availability Group

Nota

È ora possibile trasferire in modalità lift-and-shift la soluzione dell'istanza del gruppo di disponibilità a SQL Server in VM di Azure usando Azure Migrate. Per altre informazioni, vedere Eseguire la migrazione di un gruppo di disponibilità.

Ridondanza di VM

Per aumentare la ridondanza e la disponibilità elevata, le VM di SQL Server devono trovarsi nello stesso set di disponibilità o in zone di disponibilità diverse.

L'inserimento di un set di VM nello stesso set di disponibilità protegge un data center dalle interruzioni causate da errori delle apparecchiature (le VM all'interno di un set di disponibilità non condividono risorse) o da aggiornamenti (le VM all'interno di un set di disponibilità non vengono aggiornate contemporaneamente).

Le zone di disponibilità offrono protezione dagli errori di un intero data center, con ogni zona che rappresenta un set di data center all'interno di un'area. Inserendo le risorse in zone di disponibilità diverse, ci si assicura che nessuna interruzione a livello di data center porti tutte le VM offline.

Quando si creano le VM di Azure, è necessario scegliere se configurare i set di disponibilità o le zone di disponibilità. Una VM di Azure non può essere inserita in entrambi.

Anche se le zone di disponibilità possono offrire una disponibilità migliore rispetto ai set di disponibilità (99,99% rispetto al 99,95%), è consigliabile considerare anche le prestazioni. Le macchine virtuali all'interno di un set di disponibilità possono essere inserite in un gruppo di posizionamento di prossimità che garantisce che siano vicine tra loro, riducendo al minimo la latenza di rete tra di esse. Le macchine virtuali situate in zone di disponibilità diverse hanno una latenza di rete maggiore tra di esse, che può aumentare il tempo necessario per sincronizzare i dati tra le repliche primarie e secondarie. Ciò può causare ritardi nella replica primaria e aumentare la probabilità di perdita di dati in caso di failover non pianificato. È importante testare la soluzione proposta sotto carico e assicurarsi che soddisfi i contratti di servizio sia per le prestazioni che per la disponibilità.

Connettività

Per replicare l'esperienza locale di connessione al listener del gruppo di disponibilità, distribuire le macchine virtuali di SQL Server in più subnet all'interno della stessa rete virtuale. La presenza di più subnet annulla la necessità di una dipendenza aggiuntiva su Azure Load Balancer o da un nome di rete distribuita per instradare il traffico al listener.

Se si distribuiscono le macchine virtuali di SQL Server in una singola subnet, è possibile configurare un nome di rete virtuale (VNN) e un'istanza di Azure Load Balancer o un nome di rete distribuita (DNN) per instradare il traffico al listener del gruppo di disponibilità. Esaminare le differenze tra le due soluzioni, quindi distribuire un nome di rete distribuita (DNN) o un nome di rete virtuale (VNN) per il gruppo di disponibilità.

Quando si usa il nome di rete distribuita, la maggior parte delle funzionalità di SQL Server funziona in modo trasparente con i gruppi di disponibilità, ma esistono alcune funzionalità che possono richiedere particolari considerazioni. Per altre informazioni, vedere Interoperabilità tra gruppo di disponibilità e nome di rete distribuita.

Esistono inoltre alcune differenze di comportamento importanti tra la funzionalità del listener VNN e il listener DNN:

Tempo di failover: il tempo di failover è più veloce quando si usa un listener DNN perché non è necessario attendere che il servizio di bilanciamento del carico di rete rilevi l'evento di errore e modifichi il routing.
Connessioni esistenti: le connessioni effettuate a un database specifico all'interno di un gruppo di disponibilità con failover verranno chiuse, ma altre connessioni alla replica primaria rimarranno aperte perché il nome di rete distribuita rimane online durante il processo di failover. Non si tratta di un ambiente VNN tradizionale, dove tutte le connessioni alla replica primaria in genere si chiudono quando il gruppo di disponibilità esegue il failover, il listener passa offline e la replica primaria passa al ruolo secondario. Quando si usa un listener DNN, potrebbe essere necessario modificare le stringa di connessione dell'applicazione per assicurarsi che le connessioni vengano reindirizzate alla nuova replica primaria al momento del failover.
Transazioni aperte: le transazioni aperte su un database in un gruppo di disponibilità con failover si chiuderanno ed eseguiranno il rollback, per cui sarà necessario riconnettersi manualmente. Ad esempio, in SQL Server Management Studio, è necessario chiudere la finestra della query e aprirne una nuova.

La configurazione di un listener VNN in Azure richiede un servizio di bilanciamento del carico. Esistono due opzioni principali per i servizi di bilanciamento del carico in Azure: esterni (pubblici) o interni. Il servizio di bilanciamento del carico esterno (pubblico) è con connessione Internet ed è associato a un indirizzo IP pubblico virtuale (VIP) accessibile tramite Internet. Un servizio di bilanciamento del carico interno supporta solo i client all'interno della stessa rete virtuale. Per entrambi i tipi di bilanciamento del carico è necessario abilitare Direct Server Return.

È comunque possibile connettersi separatamente a ogni replica di disponibilità effettuando la connessione direttamente all'istanza del servizio. Inoltre, poiché i gruppi di disponibilità sono compatibili con le versioni precedenti dei client di mirroring del database, è possibile connettersi alle repliche di disponibilità come partner per il mirroring del database purché le repliche siano configurate in modo analogo al mirroring del database:

Sono presenti una replica primaria e una replica secondaria.
La replica secondaria è configurata come non leggibile (opzione Secondaria leggibile impostata su No).

Di seguito è riportata una stringa di connessione client di esempio corrispondente a questa configurazione simile al mirroring del database usando ADO.NET o SQL Server Native Client:

Data Source=ReplicaServer1;Failover Partner=ReplicaServer2;Initial Catalog=AvailabilityDatabase;

Per altre informazioni sulla connettività client, vedere:

Una singola subnet richiede il servizio di bilanciamento del carico

Quando si crea un listener del gruppo di disponibilità in un cluster di failover di Windows Server locale (WSFC), viene creato un record DNS per il listener con l'indirizzo IP specificato. Questo indirizzo IP viene mappato all'indirizzo MAC della replica primaria corrente nelle tabelle ARP di commutatori e router nella rete locale. Il cluster esegue questa operazione usando l'ARP gratuito (GARP), in cui trasmette il mapping più recente di indirizzi IP a MAC alla rete ogni volta che viene selezionata una nuova replica primaria dopo il failover. In questo caso, l'indirizzo IP è per il listener e il MAC è della replica primaria corrente. Il GARP forza un aggiornamento alle voci della tabella ARP per i commutatori e i router, mentre tutti gli utenti che si connettono all'indirizzo IP del listener vengono instradati senza problemi alla replica primaria corrente.

Per motivi di sicurezza, la trasmissione in qualsiasi cloud pubblico (Azure, Google, AWS) non è consentita, quindi l'uso di ARP e GARP in Azure non è supportato. Per superare questa differenza negli ambienti di rete, le macchine virtuali di SQL Server in un gruppo di disponibilità in subnet singola si basano sui servizi di bilanciamento del carico per instradare il traffico agli indirizzi IP appropriati. I servizi di bilanciamento del carico vengono configurati con un indirizzo IP di front-end che corrisponde al listener e viene assegnata una porta probe in modo che Azure Load Balancer possa eseguire periodicamente il polling dello stato delle repliche nel gruppo di disponibilità. Poiché solo la macchina virtuale di SQL Server della replica primaria risponde al probe TCP, il traffico in ingresso viene quindi instradato alla macchina virtuale che risponde correttamente al probe. Inoltre, la porta probe corrispondente è configurata come IP del cluster WSFC, assicurando che la replica primaria risponda al probe TCP.

I gruppi di disponibilità configurati in una singola subnet devono usare un servizio di bilanciamento del carico o un nome di rete distribuita (DNN) per instradare il traffico alla replica appropriata. Per evitare queste dipendenze, configurare il gruppo di disponibilità in più subnet in modo che il listener del gruppo di disponibilità sia configurato con un indirizzo IP per una replica in ogni subnet e possa instradare il traffico in modo appropriato.

Se il gruppo di disponibilità è già stato creato in una singola subnet, è possibile eseguirne la migrazione a un ambiente con più subnet.

Meccanismo lease

Per SQL Server la DLL della risorsa del gruppo di disponibilità determina l'integrità del gruppo sulla base del meccanismo di lease del gruppo di disponibilità e del rilevamento di integrità Always On. La DLL della risorsa del gruppo di disponibilità espone lo stato di integrità della risorsa tramite l'operazione IsAlive. Il monitoraggio risorse esegue il polling di IsAlive all'intervallo di heartbeat del cluster, impostato dai valori CrossSubnetDelay e SameSubnetDelay validi a livello di cluster. Su un nodo primario il servizio cluster avvia il failover ogni volta che la chiamata IsAlive alla DLL della risorsa indica che il gruppo di disponibilità non è integro.

La DLL della risorsa del gruppo di disponibilità esegue il monitoraggio dello stato dei componenti interni di SQL Server. Sp_server_diagnostics segnala a SQL Server l'integrità di questi componenti in un intervallo controllato da HealthCheckTimeout.

A differenza di quanto accade in altri meccanismi di failover, nel meccanismo lease l'istanza di SQL Server svolge un ruolo attivo. Il meccanismo lease viene usato come convalida Looks Alive tra l'host di risorse cluster e il processo di SQL Server. Con il meccanismo ci si assicura che i due lati, cioè il servizio cluster e il servizio SQL Server, abbiano contatti frequenti e che si controllino a vicenda lo stato per impedire, in definitiva, uno scenario split brain.

Quando si configura un gruppo di disponibilità nelle macchine virtuali di Azure, spesso è necessario configurare queste soglie in modo diverso rispetto a quanto configurato in un ambiente locale. Per configurare le impostazioni di soglia in base alle procedure consigliate per le macchine virtuali di Azure, vedere le procedure consigliate per i cluster.

Configurazione di rete

Distribuire le macchine virtuali di SQL Server in più subnet, quando possibile, per evitare la dipendenza da un servizio di bilanciamento del carico di Azure o da un nome di rete distribuita (DNN) per l'instradamento del traffico al listener del gruppo di disponibilità.

In un cluster di failover di macchine virtuali di Azure è consigliabile usare una sola scheda di rete per ogni server (nodo del cluster). La ridondanza fisica della rete di Azure rende superfluo l'uso di altre schede di rete in un cluster di failover di macchine virtuali di Azure. Anche se il report di convalida del cluster avvisa che i nodi sono raggiungibili solo in una rete, tale avviso potrà essere tranquillamente ignorato per i cluster di failover delle macchine virtuali di Azure.

Gruppo di disponibilità di base

Poiché il gruppo di disponibilità di base non consente più di una replica secondaria e l'accesso in lettura a quest'ultima non è consentito, è possibile usare le stringhe di connessione di mirroring del database per i gruppi di disponibilità di base. L'uso della stringa di connessione annulla la necessità di avere listener. La rimozione della dipendenza del listener è utile per i gruppi di disponibilità nelle macchine virtuali di Azure perché annulla la necessità di un servizio di bilanciamento del carico o dell'aggiunta di altri IP al servizio di bilanciamento del carico quando si dispone di più listener per database aggiuntivi.

Ad esempio, per connettersi in modo esplicito tramite TCP/IP al database del gruppo di disponibilità AdventureWorks in Replica_A o Replica_B di un gruppo di disponibilità di base (o a qualsiasi gruppo di disponibilità che disponga di una sola replica secondaria e per cui l'accesso in lettura non è consentito nella replica secondaria), un'applicazione client potrebbe specificare la stringa di connessione del mirroring del database seguente per connettersi correttamente al gruppo di disponibilità

Server=Replica_A; Failover_Partner=Replica_B; Database=AdventureWorks; Network=dbmssocn

Opzioni di distribuzione

Suggerimento

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 diverse subnet all'interno della stessa rete virtuale di Azure.

Sono disponibili diverse opzioni per la distribuzione di un gruppo di disponibilità in SQL Server in Macchine virtuali di Azure, alcune con più automazione di altre.

La tabella seguente include un confronto delle opzioni disponibili:

	Portale di Azure,	Interfaccia della riga di comando di Azure/PowerShell	Modelli di avvio rapido	Manuale (subnet singola)	Manuale (multi-subnet)
Versione di SQL Server	2016 e successive	2016 e successive	2016 e successive	2012 e successive	2012 e successive
Edizione di SQL Server	Enterprise	Enterprise	Enterprise	Enterprise, Standard	Enterprise, Standard
Versione di Windows Server	2016 e successive	2016 e successive	2016 e successive	Tutti	Tutti
Crea automaticamente il cluster	Sì	Sì	Sì	No	No
Crea il gruppo di disponibilità e il listener per l'utente	Sì	No	No	No	No
Crea il listener e il servizio di bilanciamento del carico in modo indipendente	N/D	No	No	Sì	N/D
È possibile creare un listener di DNN con questo metodo?	N/D	No	No	Sì	N/D
Configurazione del quorum WSFC	Cloud di controllo	Cloud di controllo	Cloud di controllo	Tutti	Tutti
Ripristino di emergenza con più aree	No	No	No	Sì	Sì
Supporto per più subnet	Sì	No	No	N/D	Sì
Supporto di un dominio dell'applicazione esistente	Sì	Sì	Sì	Sì	Sì
Ripristino di emergenza con più zone nella stessa area	Sì	Sì	Sì	Sì	Sì
Gruppo di disponibilità distribuito senza AD	No	No	No	Sì	Sì
Gruppo di disponibilità distribuito senza cluster	No	No	No	Sì	Sì
Richiede servizio di bilanciamento del carico o DNN	No	Sì	Sì	Sì	No

Passaggi successivi

Per iniziare, esaminare le procedure consigliate per HADR, quindi distribuire manualmente il gruppo di disponibilità con l'esercitazione sul gruppo di disponibilità.

Per altre informazioni, vedere: