Istanze del cluster di failover Always On (SQL Server)

Si applica a: SQL Server

Le istanze del cluster di failover AlwaysOn di SQL Server usano cluster di failover Windows Server (Windows Server Failover Clustering, WSFC) per offrire disponibilità elevata locale. Un'istanza del cluster di failover (failover cluster instance, FCI) è ridondante a livello di istanza del server. Un'istanza del cluster di failover è una sola istanza di SQL Server installata nei nodi del cluster di server Windows e, possibilmente, in più subnet. In rete, un'istanza del cluster di failover appare come un'istanza di SQL Server in esecuzione in un singolo computer, le cui funzionalità forniscono il failover da un nodo WSFC a un altro, quando il nodo corrente non è più disponibile.

Un'istanza del cluster di failover può sfruttare i gruppi di disponibilità Always On per offrire il ripristino di emergenza remoto a livello di database. Per altre informazioni, vedere Clustering di failover e gruppi di disponibilità (SQL Server).

Vantaggi di un'istanza del cluster di failover

Quando si verifica un errore dell'hardware o del software di un server, le applicazioni o i client che si connettono al server subiranno tempi di inattività. I nodi ridondanti proteggono la disponibilità dell'istanza di SQL Server quando si tratta di un'istanza del cluster di failover anziché di un'istanza autonoma. Solo un nodo per volta nell'istanza del cluster di failover possiede il gruppo di risorse WSFC. Nel caso di errore (errore hardware, errori del sistema operativo, dell’applicazione o del servizio) o di un aggiornamento pianificato, la proprietà del gruppo di risorse viene spostata dal cluster a un altro nodo WSFC. Questo processo è trasparente per il client o l'applicazione che si connette a SQL Server. Ciò riduce al minimo il tempo inattivo dell'applicazione o dei client durante un errore. Di seguito vengono elencati i vantaggi principali offerti dalle istanze del cluster di failover di SQL Server:

• Protezione a livello di istanza tramite ridondanza.

• Failover automatico in caso di errore (errore hardware, errore del sistema operativo, dell'applicazione o del servizio).

  Importante

  In un gruppo di disponibilità non è supportato il failover automatico da un'istanza del cluster di failover ad altri nodi all'interno del gruppo di disponibilità. Questo vuole dire che le istanze del cluster di failover e i nodi autonomi non devono essere accoppiati all'interno di un gruppo di disponibilità se il failover automatico è un importante componente della soluzione di disponibilità elevata. Tuttavia, è possibile creare questo accoppiamento per il ripristino di emergenza .

• Il supporto per una matrice estesa di soluzioni di archiviazione, tra cui i dischi WSFC (iSCSI, Fiber Channel e così via) e le condivisioni di file Server Message Block (SMB).

• Il ripristino di emergenza che usa un'istanza del cluster di failover su più subnet o che esegue un database ospitato dall'istanza del cluster di failover in un gruppo di disponibilità. Con il nuovo supporto di più subnet in Microsoft SQL Server 2012 (11.x), un'istanza del cluster di failover su più subnet non richiede più una LAN virtuale, aumentando la facilità di gestione e la sicurezza di un'istanza del cluster di failover su più subnet.

• Nessuna riconfigurazione di applicazioni e client durante i failover.

• Criteri di failover flessibili per gli eventi del trigger granulari per failover automatici.

• Failover affidabili tramite il rilevamento di integrità periodico e dettagliato utilizzando connessioni dedicate e persistenti.

• Configurabilità e prevedibilità della durata del failover tramite checkpoint di background indiretti.

• Uso delle risorse rallentato durante i failover.

Consigli

In un ambiente di produzione:

• Usare indirizzi IP statici in combinazione con l'indirizzo IP virtuale di un'istanza del cluster di failover.
• Evitare di usare DHCP in un ambiente di produzione. In caso di inattività, se il lease IP DHCP scade, per la registrazione del nuovo indirizzo IP DHCP associato al nome DNS viene richiesto tempo aggiuntivo.

Informazioni generali sull'istanza del cluster di failover

Un'istanza del cluster di failover viene eseguita in un gruppo di risorse WSFC con uno o più nodi WSFC. Quando l'istanza del cluster di failover viene avviata, uno dei nodi presume la proprietà del gruppo di risorse e attiva la modalità online dell'istanza di SQL Server. Le risorse di proprietà di questo nodo includono:

• Nome rete

• Indirizzo IP

• Dischi condivisi

• Servizio Motore di database di SQL Server

• Servizio Agente di SQL Server

• SQL Server Analysis Services, se installato

• Una risorsa di condivisione file, se la funzionalità FILESTREAM è installata

In qualsiasi momento, solo il proprietario del gruppo di risorse, e nessun altro nodo nell'istanza del cluster di failover, esegue i rispettivi servizi di SQL Server nel gruppo di risorse. Quando si verifica un failover, ad esempio un failover automatico o un failover pianificato, si verifica la seguente sequenza di eventi:

1. A meno che non si verifichi un errore hardware o di sistema, tutte le pagine dirty della cache del buffer vengono scritte su disco.

2. Tutti i rispettivi servizi SQL Server nel gruppo di risorse vengono arrestati sul nodo attivo.

3. La proprietà del gruppo di risorse viene trasferita a un altro nodo nell'istanza del cluster di failover.

4. I servizi SQL Server vengono avviati dal nuovo proprietario del gruppo di risorse.

5. Le richieste di connessione dell'applicazione client vengono dirette automaticamente al nuovo nodo attivo utilizzando lo stesso nome della rete virtuale (VNN, Virtual Network Name).

L'istanza del cluster di failover è online finché l'integrità del quorum del cluster WSFC sottostante è buona (la maggioranza dei nodi WSFC del quorum è disponibile come destinazione del failover automatico). Quando il cluster WSFC perde il quorum per un errore hardware, software, di rete o per la configurazione impropria del quorum, l'intero cluster WSFC, insieme all'istanza del cluster di failover viene portato offline. Quindi, in questo scenario di failover non pianificato è richiesto l'intervento manuale per ristabilire il quorum nei nodi disponibili restanti in modo da riportare il cluster WSFC e l'istanza del cluster di failover online. Per ulteriori informazioni, vedere Modalità Quorum della funzionalità clustering di Windows Server e configurazione del voto (SQL Server).

Tempo di failover stimabile

A seconda di quando l'istanza di SQL Server ha eseguito l'ultima operazione di checkpoint, è possibile che vi sia un numero sostanziale di pagine dirty nella cache del buffer. Di conseguenza, i failover durano per tutto il tempo che occorre per scrivere le pagine dirty restanti sul disco che può comportare un tempo di failover lungo e imprevedibile. A partire da Microsoft SQL Server 2012 (11.x), l'istanza del cluster di failover può usare checkpoint indiretti per limitare il numero di pagine dirty mantenute nella cache del buffer. Sebbene vengano utilizzate risorse aggiuntive sotto un carico di lavoro normale, la durata del failover è più stimabile e configurabile. Questa operazione si rivela utile quando il contratto di servizio dell'organizzazione specifica l'obiettivo del tempo di recupero (RTO, Recovery Time Objective) per la soluzione di disponibilità elevata. Per ulteriori informazioni sui checkpoint indiretti, vedere Indirect Checkpoints.

Criteri di failover flessibili e monitoraggio dell'integrità affidabile

Una volta avviata l'istanza del cluster di failover, il servizio WSFC esegue il monitoraggio dell'integrità del cluster del servizio WSFC sottostante e l'integrità dell'istanza di SQL Server. A partire da Microsoft SQL Server 2012 (11.x), il servizio WSFC usa una connessione dedicata per eseguire il polling dell'istanza di SQL Server attiva per la diagnostica dettagliata dei componenti tramite una stored procedure di sistema. L'implicazione di ciò è costituita da tre riduzioni:

• La connessione dedicata all'istanza di SQL Server consente di eseguire il polling costantemente in modo affidabile per la diagnostica dei componenti, anche quando il carico di lavoro dell'istanza del cluster di failover è elevato. In tal modo è possibile distinguere tra un sistema in carico di lavoro elevato e un sistema che effettivamente è in condizione di errore, evitando pertanto problemi quali failover falsi.

• La diagnostica dettagliata dei componenti consente di configurare più criteri di failover flessibili per permettere di scegliere le condizioni di errore che attivano i failover e quelle che non li attivano.

• La diagnostica dettagliata dei componenti abilita anche una migliore risoluzione dei problemi dei failover automatici in modo retroattivo. Le informazioni di diagnostica vengono archiviate in file di log che vengono collocati insieme ai log degli errori di SQL Server. È possibile caricare i file nel visualizzatore file di log per controllare gli stati dei componenti precedenti all'occorrenza del failover per determinare la causa del failover.

Per altre informazioni, vedere Criteri di failover per le istanze del cluster di failover

Elementi di un'istanza del cluster di failover

Un'istanza del cluster di failover è costituita da un set di server fisici (nodi) con configurazioni hardware simili e configurazioni software identiche, tra cui la versione del sistema operativo e il livello della patch e la versione di SQL Server, il livello della patch, i componenti e il nome dell'istanza. La configurazione del software identica è necessaria assicurarsi che l'istanza del cluster di failover possa essere totalmente funzionale quando si verifica un errore tra i nodi.

Gruppo di risorse WSFC
Un'istanza del cluster di failover di SQL Server viene eseguita in un gruppo di risorse WSFC. Ogni nodo nel gruppo di risorse gestisce una copia sincronizzata delle impostazioni di configurazione e delle chiavi del Registro di sistema del checkpoint per assicurare la funzionalità completa dell'istanza del cluster di failover dopo un failover e solo un nodo per volta (il nodo attivo) possiede nel cluster il gruppo di risorse. Il servizio WSFC gestisce il cluster del server, la configurazione del quorum, i criteri del failover e le operazioni del failover, nonché il nome di rete virtuale e gli indirizzi IP virtuali per l'istanza del cluster di failover. Nel caso di errore (hardware, del sistema operativo, di applicazione o del servizio) o di aggiornamento pianificato, la proprietà del gruppo di risorse viene spostata a un altro nodo nell'istanza del cluster di failover. Il numero di nodi supportati in un gruppo di risorse WSFC dipende dall'edizione di SQL Server. Inoltre, lo stesso cluster WSFC può eseguire più istanze del cluster di failover (più gruppi di risorse), a seconda della capacità hardware, ad esempio CPU, memoria e numero di dischi.

Binari di SQL Server
I file binari del prodotto sono installati in locale in ogni nodo dell'istanza del cluster di failover, come avviene per le installazioni autonome di SQL Server. Tuttavia, durante l'avvio, i servizi non vengono avviati automaticamente, ma gestiti dal servizio WSFC.

Storage
Diversamente dal gruppo di disponibilità, un'istanza del cluster di failover deve usare l'archiviazione condivisa tra tutti i nodi dell'istanza del cluster di failover per l'archiviazione di log e database. L'archiviazione condivisa può avvenire sotto forma di dischi di cluster WSFC, dischi su una rete SAN, Spazi di archiviazione diretta (S2D) o condivisioni di file su un protocollo SMB. In tal modo, tutti i nodi nell'istanza del cluster di failover dispongono della stessa vista di dati dell'istanza quando si verifica un failover. Tuttavia, questo vuole dire che l'archiviazione condivisa potenzialmente potrebbe essere l'unico punto di errore e l'istanza del cluster di failover dipende dalla soluzione di archiviazione sottostante per assicurare la protezione dei dati.

Nome rete
Il nome della rete virtuale (VNN, Virtual Network Name) fornisce un punto di connessione unificato per l'istanza del cluster di failover. In tal modo le applicazioni possono connettersi al nome VNN senza il bisogno di conoscere il nodo al momento attivo. Quando si verifica un failover, il VNN viene registrato nel nuovo nodo attivo dopo l'avvio. Questo processo non è visibile al client o all'applicazione che si connette a SQL Server, riducendo di conseguenza i tempi d'inattività dell'applicazione o dei client durante un errore.

IP virtuali
Nel caso di un'istanza del cluster di failover su più subnet, un indirizzo IP virtuale viene assegnato a ogni subnet nell'istanza del cluster di failover. Durante un failover, il VNN sul server DNS viene aggiornato per puntare all'indirizzo IP virtuale per la rispettiva subnet. Le applicazioni e i client si possono connettere quindi all'istanza del cluster di failover utilizzando lo stesso VNN dopo un failover su più subnet.

Concetti e attività di failover di SQL Server

Argomenti correlati