Cluster di failover di Windows Server con SQL Server
Si applica a: 
SQL Server su VM di Azure
Questo articolo descrive le differenze quando si usa la funzionalità Cluster di failover di Windows Server con SQL Server in macchine virtuali di Azure per la disponibilità elevata e il ripristino di emergenza (HADR), ad esempio per i gruppi di disponibilità AlwaysOn o le istanze del cluster di failover (FCI).
Per altre informazioni sulla funzionalità di Windows stessa, vedere la documentazione del cluster di failover di Windows Server.
Panoramica
Le soluzioni a disponibilità elevata di SQL Server in Windows, ad esempio gruppi di disponibilità AlwaysOn o istanze del cluster di failover si basano sul servizio WSFC (Windows Server Failover Clustering).
Il servizio cluster monitora le connessioni di rete e l'integrità dei nodi nel cluster. Questo monitoraggio è oltre ai controlli di integrità eseguiti da SQL Server come parte della funzionalità del gruppo di disponibilità o dell'istanza del cluster di failover. Se il servizio cluster non riesce a raggiungere il nodo o se il ruolo del gruppo di disponibilità o dell'istanza del cluster di failover nel cluster non è integro, il servizio cluster avvia le azioni di ripristino appropriate per ripristinare e portare online applicazioni e servizi, nello stesso nodo o in un altro nodo del cluster.
Monitoraggio dell'integrità del cluster
Per garantire la disponibilità elevata, il cluster deve garantire l'integrità dei diversi componenti che costituiscono la soluzione in cluster. Il servizio cluster monitora l'integrità del cluster in base a diversi parametri di sistema e di rete per rilevare e rispondere agli errori.
L'impostazione della soglia per la dichiarazione di un errore è importante per ottenere un equilibrio tra rispondere tempestivamente a un errore ed evitare falsi errori.
Esistono due strategie per il monitoraggio:
| Monitoraggio | Descrizione |
|---|---|
| Aggressive | Fornisce il rilevamento rapido degli errori e il ripristino di errori hardware, che offre i livelli più elevati di disponibilità. Il servizio cluster e SQL Server sono entrambi meno forgiving di un errore temporaneo e in alcune situazioni può essere prematuramente eseguito il failover delle risorse in caso di interruzioni temporanee. Una volta rilevato un errore, l'azione correttiva che segue potrebbe richiedere tempo aggiuntivo. |
| Relaxed | Offre un maggior livello di tolleranza al rilevamento degli errori con una maggiore tolleranza per brevi problemi di rete temporanei. Evita errori temporanei, ma introduce anche il rischio di ritardare il rilevamento di un vero errore. |
Le impostazioni aggressive in un ambiente cluster nel cloud possono causare errori prematuri e interruzioni più lunghe, pertanto è consigliabile una strategia di monitoraggio meno rigoroso per i cluster di failover nelle macchine virtuali di Azure. Per modificare le impostazioni di soglia, vedere Procedure consigliate per il cluster per altri dettagli.
Heartbeat del cluster
Le impostazioni principali che influiscono sull'heartbeat del cluster e sul rilevamento dell'integrità tra i nodi:
| Impostazione | Descrizione |
|---|---|
| Ritardo | In questo modo viene definita la frequenza con cui gli heartbeat del cluster vengono inviati tra i nodi. Il ritardo è il numero di secondi prima dell'invio dell'heartbeat successivo. All'interno dello stesso cluster possono essere configurate impostazioni di ritardo diverse tra nodi nella stessa subnet e tra nodi che si trovano in subnet diverse. |
| Threshold | La soglia è il numero di heartbeat che possono essere mancati prima che il cluster esegua l'azione di ripristino. All'interno dello stesso cluster possono essere configurate impostazioni di soglia diverse tra i nodi nella stessa subnet e tra nodi che si trovano in subnet diverse. |
I valori predefiniti per queste impostazioni potrebbero essere troppo bassi per gli ambienti cloud e potrebbero causare errori non necessari a causa di problemi di rete temporanei. Per essere più tollerante, usare le impostazioni di soglia meno rigorose per i cluster di failover nelle macchine virtuali di Azure. Per altre informazioni, vedere le procedure consigliate per i cluster.
Quorum
Anche se un cluster a due nodi funziona senza una risorsa quorum, i clienti sono strettamente tenuti a usare una risorsa quorum per avere il supporto di produzione. La convalida del cluster non passerà alcun cluster senza una risorsa quorum.
Tecnicamente, un cluster a tre nodi può sopravvivere a una perdita di un singolo nodo (fino a due nodi) senza una risorsa quorum. Tuttavia, dopo che il cluster è inattivo a due nodi, c'è il rischio che le risorse cluster vengano offline per evitare uno scenario split-brain se un nodo viene perso o si verifica un errore di comunicazione tra i nodi. La configurazione di una risorsa quorum consentirà alle risorse del cluster di rimanere online con un solo nodo online.
Il disco di controllo è l'opzione quorum più resiliente, ma per usare un disco di controllo su SQL Server in una macchina virtuale Azure, è necessario usare un disco condiviso di Azure, che impone alcune limitazioni per la soluzione a disponibilità elevata. Di conseguenza, è consigliabile usare un disco di controllo quando si configura l'istanza del cluster di failover con dischi condivisi di Azure, altrimenti usare un cloud di controllo quando possibile.
La tabella seguente elenca le opzioni quorum disponibili per SQL Server nelle macchine virtuali di Azure:
| Cloud di controllo | Disco di controllo | Condivisione file di controllo | |
|---|---|---|---|
| Sistema operativo supportato | Windows Server 2016+ | Tutte le date | Tutte le date |
| Descrizione | Un cloud di controllo è un tipo di quorum di controllo del cluster di failover che usa Microsoft Azure per fornire un voto sul quorum del cluster. La dimensione predefinita è di circa 1 MB e contiene solo il timestamp. Un cloud di controllo è ideale per le distribuzioni in più siti, più zone e più aree. Usare un cloud di controllo quando possibile, a meno che non sia disponibile una soluzione cluster di failover con archiviazione condivisa. | Un disco di controllo è un disco in cluster di piccole dimensioni nel gruppo Cluster Disponibile Archiviazione. Questo disco è a disponibilità elevata e può eseguire il failover tra nodi. Contiene una copia del database del cluster, con dimensioni predefinite inferiori a 1 GB. Il disco di controllo è l'opzione quorum più resiliente ed è preferibile per qualsiasi cluster che usa Dischi condivisi di Azure (o qualsiasi soluzione di dischi condivisi, ad esempio SCSI condiviso, iSCSI o SAN Fibre Channel). Un volume condiviso cluster non può essere usato come disco di controllo. Configurare un disco condiviso di Azure come disco di controllo. | Il controllo della condivisione file è una condivisione file SMB in genere configurata in un file server che esegue Windows Server. Gestisce le informazioni di clustering in un file witness.log, ma non ne archivia una copia del database del cluster. In Azure è possibile configurare una condivisione file in una macchina virtuale separata all'interno della stessa rete virtuale. Usare un server di controllo della condivisione file se un server di controllo del disco o un cloud di controllo non è disponibile nell'ambiente in uso. |
Per iniziare, vedere Configurare il quorum del cluster.
VNN (nome di rete virtuale)
Per replicare l'esperienza locale di connessione al listener del gruppo di disponibilità o all'istanza del cluster di failover, 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 per instradare il traffico alla soluzione HADR. Per altre informazioni, vedere Gruppo di disponibilità su più subnet e Istanza del cluster di failover su più subnet.
In un ambiente locale tradizionale, le risorse in cluster, ad esempio istanze del cluster di failover o gruppi di disponibilità Always On, si basano sul Nome Rete virtuale per instradare il traffico alla destinazione appropriata, ovvero l'istanza del cluster di failover o il listener del gruppo di disponibilità AlwaysOn. Il nome virtuale associa l'indirizzo IP in DNS e i client possono usare il nome virtuale o l'indirizzo IP per connettersi alla destinazione a disponibilità elevata, indipendentemente dal nodo attualmente proprietario della risorsa. La rete virtuale è un nome di rete e un indirizzo gestito dal cluster e il servizio cluster sposta l'indirizzo di rete dal nodo al nodo durante un evento di failover. Durante un errore, l'indirizzo viene portato offline nella replica primaria originale e portato online nella nuova replica primaria.
In Azure Macchine virtuali in una singola subnet è necessario un componente aggiuntivo per instradare il traffico dal client al Nome Rete virtuale della risorsa cluster (istanza del cluster di failover o listener di un gruppo di disponibilità). In Azure, un servizio di bilanciamento del carico contiene l'indirizzo IP per la rete virtuale su cui si basano le risorse di SQL Server in cluster ed è necessario instradare il traffico alla destinazione di disponibilità elevata appropriata. Il servizio di bilanciamento del carico rileva anche gli errori con i componenti di rete e sposta l'indirizzo in un nuovo host.
Il servizio di bilanciamento del carico distribuisce i flussi in ingresso che arrivano al front-end e quindi indirizza il traffico alle istanze definite dal pool back-end. Per configurare il flusso del traffico, usare regole di bilanciamento del carico e probe di integrità. Con l'istanza del cluster di failover di SQL Server, le istanze del pool back-end sono le macchine virtuali di Azure che eseguono SQL Server e con i gruppi di disponibilità, il pool back-end sono le macchine virtuali che possono diventare la replica primaria per il listener. Si verifica un lieve ritardo di failover quando si usa il servizio di bilanciamento del carico, perché il probe di integrità esegue controlli attivi ogni 10 secondi per impostazione predefinita.
Per iniziare, informazioni su come configurare Azure Load Balancer per un'istanza del cluster di failover o un gruppo di disponibilità.
Sistema operativo supportato: tutti
Versione di SQL supportata: tutte
Soluzione HADR supportata: Istanza del cluster di failover e gruppo di disponibilità
La configurazione della rete virtuale può essere complessa, si tratta di un'origine aggiuntiva di errore, può causare un ritardo nel rilevamento degli errori ed è previsto un sovraccarico e un costo associato alla gestione della risorsa aggiuntiva. Per risolvere alcune di queste limitazioni, SQL Server ha introdotto il supporto per la funzionalità Nome rete distribuita.
DNN (nome di rete distribuita)
Per replicare l'esperienza locale di connessione al listener del gruppo di disponibilità o all'istanza del cluster di failover, 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 da un DNN per instradare il traffico alla soluzione HADR. Per altre informazioni, vedere Gruppo di disponibilità su più subnet e Istanza del cluster di failover su più subnet.
Per le macchine virtuali di SQL Server distribuite in una singola subnet, la funzionalità Nome di rete distribuita offre un modo alternativo per i client SQL Server di connettersi all'istanza del cluster di failover di SQL Server o al listener del gruppo di disponibilità senza usare un servizio di bilanciamento del carico. La funzionalità del nome di rete distribuita è disponibile a partire da SQL Server 2016 SP3, SQL Server 2017 CU25 e SQL Server 2019 CU8, in Windows Server 2016 e versioni successive.
Quando viene creata una risorsa DNN, il cluster associa il nome DNS agli indirizzi IP di tutti i nodi del cluster. Il client tenterà di connettersi a ogni indirizzo IP in questo elenco per trovare la risorsa a cui connettersi. È possibile accelerare questo processo specificando MultiSubnetFailover=True nella stringa di connessione. Questa impostazione indica al provider di provare tutti gli indirizzi IP in parallelo, in modo che il client possa connettersi immediatamente all'istanza del listener o all'istanza del cluster di failover.
Un nome di rete distribuito è consigliato su un servizio di bilanciamento del carico quando possibile perché:
- La soluzione end-to-end è più affidabile perché non rende più necessario gestire la risorsa del servizio di bilanciamento del carico.
- L'eliminazione dei probe di bilanciamento del carico riduce al minimo la durata del failover.
- Il nome di rete distribuita semplifica il provisioning e la gestione dell'istanza del cluster di failover o del listener del gruppo di disponibilità con SQL Server nelle macchine virtuali di Azure.
Quando si usa il nome di rete distribuita, la maggior parte delle funzionalità di SQL Server funziona in modo trasparente con l'istanza del cluster di failover e i gruppi di disponibilità, ma esistono alcune funzionalità che possono richiedere particolari considerazioni.
Sistema operativo supportato: Windows Server 2016 e versioni successive
Versione di SQL supportata: SQL Server 2019 CU2 (FCI) e SQL Server 2019 CU8 (AG)
Soluzione HADR supportata: Istanza del cluster di failover e gruppo di disponibilità
Per iniziare, informazioni su come configurare una risorsa nome di rete distribuita per un'istanza del cluster di failover o un gruppo di disponibilità.
Quando si usa la DNN con altre funzionalità di SQL Server è necessario fare altre considerazioni. Per altre informazioni, vedere Interoperabilità tra istanza del cluster di failover e nome di rete distribuita e Interoperabilità tra gruppo di disponibilità e nome di rete distribuita.
Nota
Se sono presenti più gruppi di disponibilità o istanze del cluster di failover nello stesso cluster e si usa un listener DNN o VNN, ogni gruppo di disponibilità o istanza del cluster di failover necessita di un proprio punto di connessione indipendente.
Opzioni di ripristino
Il servizio cluster esegue un'azione correttiva quando viene rilevato un errore. Ciò potrebbe riavviare la risorsa nel nodo esistente oppure eseguire il failover della risorsa in un altro nodo. Una volta avviate le misure correttive, il completamento richiede tempo.
Ad esempio, un gruppo di disponibilità riavviato viene online in base alla sequenza seguente:
- L'IP del listener viene fornito online
- Il nome di rete del listener viene fornito online
- Gruppo di disponibilità viene online
- I singoli database passano attraverso il ripristino, che può richiedere del tempo a seconda di diversi fattori, ad esempio la lunghezza del log di rollforward. Connessione vengono instradati dal listener solo dopo il recupero completo del database. Per altre informazioni, vedere Stima del tempo di failover (RTO).
Poiché il ripristino potrebbe richiedere del tempo, il monitoraggio aggressivo impostato per rilevare un errore in 20 secondi potrebbe causare un'interruzione di minuti se si verifica un evento temporaneo, ad esempio la manutenzione della macchina virtuale di Azure con mantenimento della memoria. L'impostazione del monitoraggio su un valore meno rigido di 40 secondi consente di evitare un'interruzione del servizio più lunga.
Per modificare le impostazioni di soglia, vedere Procedure consigliate per il cluster per altri dettagli.
Percorso del nodo
I nodi in un cluster Windows in macchine virtuali in Azure possono essere separati fisicamente all'interno della stessa area di Azure oppure possono trovarsi in aree diverse. La distanza può introdurre latenza di rete, in modo analogo alla distribuzione dei nodi del cluster tra le posizioni nelle proprie strutture. Negli ambienti cloud la differenza è che all'interno di un'area si potrebbe non essere a conoscenza della distanza tra i nodi. Inoltre, alcuni altri fattori, come componenti fisici e virtuali, il numero di hop e così via, possono anche contribuire a una maggiore latenza. Se la latenza tra i nodi è un problema, prendere in considerazione l'inserimento dei nodi del cluster all'interno di un gruppo di posizionamento di prossimità per garantire la prossimità di rete.
Limiti delle risorse
Quando si configura una macchina virtuale di Azure, si determinano i limiti delle risorse di calcolo per CPU, memoria e I/O. I carichi di lavoro che richiedono più risorse rispetto alla macchina virtuale di Azure acquistata o i limiti dei dischi possono causare problemi di prestazioni della macchina virtuale. La riduzione del livello delle prestazioni può comportare un controllo di integrità non riuscito per il servizio cluster o per la funzionalità di disponibilità elevata di SQL Server. I colli di bottiglia delle risorse possono rendere il nodo o la risorsa venga visualizzata indisponibile nel cluster o in SQL Server.
Operazioni di I/O SQL a elevato utilizzo o operazioni di manutenzione, ad esempio backup, indici o manutenzione delle statistiche, potrebbero causare il raggiungimento dei limiti di velocità effettiva di operazioni di I/O al secondo o MBPS, che potrebbero rendere SQL Server non rispondente a un controllo IsAlive/LookAlive.
Se SQL Server riscontra failover imprevisti, verificare di seguire tutte le procedure consigliate per le prestazioni e monitorare il server per il limite massimo a livello di disco o macchina virtuale.
Manutenzione della piattaforma di Azure
Come ogni altro servizio cloud, Azure aggiorna periodicamente la piattaforma per migliorare l'affidabilità, le prestazioni e la sicurezza dell'infrastruttura host per le macchine virtuali. Lo scopo di questi aggiornamenti include l'applicazione di patch ai componenti software nell'ambiente host, l'aggiornamento dei componenti di rete e la rimozione delle autorizzazioni per l'hardware.
La maggior parte degli aggiornamenti della piattaforma non influisce sulle macchine virtuali dei clienti. Quando non è possibile un aggiornamento senza alcun effetto, Azure sceglie il metodo di aggiornamento a minor impatto sulle macchine virtuali dei clienti. Gli interventi di manutenzione per i quali non è possibile un impatto zero sospendono le macchine virtuali per meno di 10 secondi. In alcuni casi, Azure usa meccanismi di manutenzione con mantenimento della memoria, che sospendono la macchina virtuale per un massimo di 30 secondi e mantengono la memoria nella RAM. Quando viene ripresa l'esecuzione della macchina virtuale, l'orologio viene automaticamente sincronizzato.
La manutenzione con mantenimento della memoria è supportata da oltre il 90% delle macchine virtuali di Azure. Non può essere usata con le serie G, M, N e H. Azure usa sempre più spesso tecnologie di migrazione in tempo reale e meccanismi di manutenzione con mantenimento della memoria per ridurre la durata delle interruzioni. Nel caso in cui la macchina virtuale venga migrata in tempo reale su un host diverso, è possibile che alcuni carichi di lavoro sensibili subiscano un lieve peggioramento delle prestazioni nei pochi minuti che precedono la sospensione della macchina virtuale.
Un collo di bottiglia della risorsa durante la manutenzione della piattaforma potrebbe far apparire il gruppo di disponibilità o l'istanza del cluster di failover come indisponibile nel servizio cluster. Per altre informazioni, vedere la sezione relativa ai limiti delle risorse di questo articolo.
Se si usa un monitoraggio aggressivo del cluster, una pausa della macchina virtuale estesa potrebbe attivare un failover. Un failover causa spesso un tempo di inattività maggiore rispetto alla sospensione della manutenzione, quindi è consigliabile usare il monitoraggio meno rigoroso per evitare di attivare un failover mentre la macchina virtuale viene sospesa per la manutenzione. Per altre informazioni sull'impostazione delle soglie del cluster nelle macchine virtuali di Azure, vedere le procedure consigliate per il cluster.
Limiti
Considerare le limitazioni seguenti quando si usa l'istanza del cluster di failover o i gruppi di disponibilità e SQL Server in Azure Macchine virtuali.
MSDTC
Le macchine virtuali di Azure supportano Microsoft Distributed Transaction Coordinator (MSDTC) in Windows Server 2019, con archiviazione in volumi condivisi del cluster e Azure Load Balancer Standard, oppure nelle VM di SQL Server che usano dischi condivisi di Azure.
Nelle macchine virtuali di Azure, MSDTC non è supportato in Windows Server 2016 o versione precedente con volumi condivisi del cluster per i motivi seguenti:
- La risorsa MSDTC in cluster non può essere configurata per usare la risorsa di archiviazione condivisa. In Windows Server 2016, se si crea una risorsa MSDTC, non verrà visualizzata alcuna risorsa di archiviazione condivisa disponibile per l'uso, anche se lo spazio di archiviazione è disponibile. Questo problema è stato risolto per Windows Server 2019.
- Il servizio di bilanciamento del carico di base non gestisce le porte RPC.
Passaggi successivi
Dopo aver acquisito familiarità con le differenze quando si usa un cluster di failover Windows con SQL Server in macchine virtuali di Azure, è possibile ottenere informazioni sulle funzionalità di disponibilità elevata dei gruppi di disponibilità o delle istanze del cluster di failover. Se si è pronti per iniziare, assicurarsi di esaminare le procedure consigliate per le raccomandazioni di configurazione.