Cluster di failover di Windows Server con SQL Server in macchine virtuali di Azure

Si applica a: SQL Server nella macchina virtuale 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à di Always On o le istanze del cluster di failover.

Per altre informazioni sulla funzionalità di Windows stessa, vedere la documentazione del cluster di failover di Windows Server.

Panoramica

SQL Server soluzioni a disponibilità elevata in Windows, ad esempio Always On gruppi di disponibilità (AG) o istanze del cluster di failover (FCI) si basano sul servizio WSFC (Windows Server Failover Clustering) sottostante.

Il servizio cluster monitora le connessioni di rete e l'integrità dei nodi nel cluster. Questo monitoraggio si aggiunge ai controlli di integrità che SQL Server fa 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 diventa 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 la risposta tempestiva a un errore e l'evitare errori falsi.

Esistono due strategie per il monitoraggio:

Monitoraggio Descrizione
Aggressive Fornisce il rilevamento rapido degli errori e il ripristino di errori rigidi, che offre i livelli più elevati di disponibilità. Il servizio cluster e le SQL Server sono entrambi meno forgiving di un errore temporaneo e in alcune situazioni possono eseguire il failover prematuro delle risorse in caso di interruzioni temporanee. Una volta rilevato un errore, l'azione correttiva che segue potrebbe richiedere tempo aggiuntivo.
Relaxed Offre più funzionalità per il rilevamento degli errori con una maggiore tolleranza per brevi problemi di rete temporanei. Evita gli errori temporanei, ma introduce anche il rischio di ritardare il rilevamento di un errore vero.

Le impostazioni aggressive in un ambiente cluster nel cloud possono causare errori prematuri e interruzioni più lunghe, pertanto è consigliabile una strategia di monitoraggio rilassata 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 sul battito cardiaco del cluster e sul rilevamento dell'integrità tra i nodi:

Impostazione Descrizione
Ritardo In questo modo viene definita la frequenza di invio degli heartbeat del cluster 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.
Soglia La soglia è il numero di heartbeat che possono essere persi prima che il cluster esecuzioni di ripristino. All'interno dello stesso cluster possono essere configurate impostazioni di soglia diverse tra 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 relaxed per i cluster di failover nelle macchine virtuali di Azure. Per altri dettagli, vedere Procedure consigliate per il cluster .

Quorum

Anche se un cluster a due nodi funzionerà senza una risorsa quorum, i clienti devono usare rigorosamente una risorsa quorum per supportare la 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 nodo singolo (fino a due nodi) senza una risorsa quorum. Tuttavia, dopo che il cluster è sceso a due nodi, c'è il rischio che le risorse in cluster vadano 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 in una SQL Server in una macchina virtuale di Azure, è necessario usare un disco condiviso di Azure che impone alcune limitazioni per la soluzione a disponibilità elevata. Di conseguenza, usare un disco di controllo quando si configura l'istanza del cluster di failover con Dischi condivisi di Azure. In caso contrario, 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+ Tutti Tutti
Descrizione Un cloud di controllo è un tipo di controllo del quorum 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 piccolo disco cluster nel gruppo Archiviazione disponibile cluster. Questo disco è a disponibilità elevata e può eseguire il failover tra i nodi. Contiene una copia del database cluster, con dimensioni predefinite inferiori a 1 GB. Il server di controllo del disco è l'opzione quorum preferita per qualsiasi cluster che usa dischi condivisi di Azure (o qualsiasi soluzione disco condiviso, 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. Un server di 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 archivia una copia del database cluster. In Azure è possibile configurare una condivisione file in una macchina virtuale separata all'interno della stessa rete virtuale. Usare un controllo di condivisione file se un server di controllo del disco o un server di controllo cloud non è disponibile nell'ambiente in uso.

Per iniziare, vedere Configurare il quorum del cluster.

VNN (nome di rete virtuale)

Per soddisfare l'esperienza locale per la connessione al listener del gruppo di disponibilità o all'istanza del cluster di failover, distribuire le macchine virtuali SQL Server in più subnet all'interno della stessa rete virtuale. La presenza di più subnet nega la necessità di una dipendenza aggiuntiva da un 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, risorse cluster come istanze del cluster di failover o Always On gruppi di disponibilità 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à Always On. 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 da nodo a 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 SQL Server 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 SQL Server fcI, 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 è il listener. Si verifica un leggero 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à.

Sistemi operativi supportati: Tutti
Versione di SQL supportata: Tutti
Soluzione HADR supportata: Istanza del cluster di failover e gruppo di disponibilità

La configurazione della rete neurale 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 associati alla gestione della risorsa aggiuntiva. Per risolvere alcune di queste limitazioni, SQL Server introdotto il supporto per la funzionalità Nome rete distribuita.

DNN (nome di rete distribuita)

Per soddisfare l'esperienza locale per la connessione al listener del gruppo di disponibilità o all'istanza del cluster di failover, distribuire le macchine virtuali SQL Server in più subnet all'interno della stessa rete virtuale. La presenza di più subnet nega la necessità di una dipendenza aggiuntiva da una rete neurale neurale 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 SQL Server macchine virtuali distribuite in una singola subnet, la funzionalità dei nomi di rete distribuita offre un modo alternativo per SQL Server client di connettersi all'istanza del cluster di failover SQL Server o al listener del gruppo di disponibilità senza usare un servizio di bilanciamento del carico. La funzionalità DNN è disponibile a partire da SQL Server 2016 SP3, SQL Server 2017 CU25, 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 cluster di failover o al listener.

Quando possibile, è consigliabile un nome di rete distribuito su un servizio di bilanciamento del carico perché:

  • La soluzione end-to-end è più affidabile perché non è più necessario gestire la risorsa di bilanciamento del carico.
  • L'eliminazione dei probe di bilanciamento del carico riduce al minimo la durata del failover.
  • DNN 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.

La maggior parte delle funzionalità di SQL Server funziona in modo trasparente con l'istanza del cluster di failover e i gruppi di disponibilità quando si usa la rete neurale neurale del database, ma esistono alcune funzionalità che possono richiedere una particolare considerazione.

Sistemi operativi supportati: Windows Server 2016 e versioni successive
Versione 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 DNN con altre funzionalità di SQL Server, è necessario tenere presenti considerazioni aggiuntive. Per altre informazioni, vedere Interoperabilità tra istanze del cluster di failover e DNN e interoperabilità del gruppo di disponibilità e rete neurale neurale .

Azioni 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 fornito online in base alla sequenza seguente:

  1. L'IP del listener viene fornito online
  2. Il nome della rete del listener viene fornito online
  3. Il gruppo di disponibilità viene fornito online
  4. 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. Le connessioni vengono instradate dal listener solo dopo il ripristino 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 dei 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 più rilassato di 40 secondi consente di evitare un'interruzione più lunga del servizio.

Per modificare le impostazioni di soglia, vedere Procedure consigliate per il cluster per altri dettagli.

Posizione 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 dispersione dei nodi del cluster tra le posizioni nelle proprie strutture. Negli ambienti cloud, la differenza è che all'interno di un'area potrebbe non essere a conoscenza della distanza tra i nodi. Inoltre, alcuni altri fattori, ad esempio componenti fisici e virtuali, numero di hop e così via, possono contribuire anche a una maggiore latenza. Se la latenza tra i nodi è un problema, valutare la possibilità di inserire i 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 delle prestazioni può comportare un controllo di integrità non riuscito per il servizio cluster o per la funzionalità di disponibilità elevata SQL Server. I colli di bottiglia delle risorse possono rendere il nodo o la risorsa visualizzata nel cluster o 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 operazioni di I/O al secondo o mbps, che potrebbero rendere SQL Server non rispondere a un controllo IsAlive/LookAlive.

Se il SQL Server riscontra failover imprevisti, verificare di seguire tutte le procedure consigliate per le prestazioni e monitorare il server per il limite a livello di disco o macchina virtuale.

Manutenzione della piattaforma Azure

Come qualsiasi 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. Quando la macchina virtuale viene migrata in tempo reale in un host diverso, alcuni carichi di lavoro sensibili, ad esempio SQL Server, potrebbero mostrare una lieve riduzione delle prestazioni nei pochi minuti che portano alla sospensione della macchina virtuale.

Un collo di bottiglia delle risorse durante la manutenzione della piattaforma può rendere il gruppo di disponibilità o l'istanza del cluster di failover nel servizio cluster. Per altre informazioni, vedere la sezione relativa ai limiti delle risorse di questo articolo.

Se si usa il monitoraggio aggressivo del cluster, una pausa estesa della macchina virtuale può attivare un failover. Un failover spesso causerà più tempi di inattività rispetto alla sospensione della manutenzione, quindi è consigliabile usare il monitoraggio rilassato 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.

Limitazioni

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, vedere i gruppi di disponibilità a disponibilità elevata o le istanze del cluster di failover. Se si è pronti per iniziare, assicurarsi di esaminare le procedure consigliate per le raccomandazioni sulla configurazione.