Istanze del cluster di failover Always On (SQL Server)

Nell'offerta SQL Server Always On, le istanze del cluster di failover Always On usano la funzionalità clustering di failover di Windows Server (WSFC, Windows Server Failover Clustering) per fornire la disponibilità elevata in locale tramite la ridondanza a livello di istanza del server, ovvero un'istanza del cluster di failover. Un'istanza del cluster di failover è una sola istanza di SQL Server installata nei nodi del clustering di failover di Windows Server (WSFC) 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à AlwaysOn per offrire ripristino di emergenza remoto a livello di database. Per altre informazioni, vedere Clustering di failover e gruppi di disponibilità AlwaysOn (SQL Server).

Contenuto dell'argomento

• Vantaggi

• Indicazioni

• Panoramica dell'istanza del cluster di failover

• Elementi di un'istanza del cluster di failover

• Concetti e attività di failover di SQL Server

• Argomenti correlati

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à. Quando un'istanza di SQL Server è configurata per essere un'istanza del cluster di failover (anziché un'istanza autonoma), la disponibilità elevata di quell'istanza di SQL Server è protetta dalla presenza di nodi ridondanti nell'istanza del cluster di failover. Solo un nodo per volta nell'istanza del cluster di failover possiede il gruppo di risorse WSFC. 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 WSFC. 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. 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, del sistema operativo, dell'applicazione o del servizio)

  Importante

  In un gruppo di disponibilità Always On, non è supportato il failover automatico da un'istanza del cluster di failover agli 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).

• Per la soluzione del ripristino di emergenza si usa un'istanza del cluster di failover su più subnet o l'esecuzione di un database ospitato dall'istanza del cluster di failover in un gruppo di disponibilità Always On. Con il nuovo supporto per più subnet in MicrosoftSQL Server 2012, un'istanza di fcI multi-subnet non richiede più una rete LAN virtuale, aumentando la gestibilità e la sicurezza di un'istanza di fcI multi 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

• Utilizzo rallentato delle risorse durante i failover

Consigli

In un ambiente di produzione è consigliabile usare indirizzi IP statici in combinazione con l'indirizzo IP virtuale di un'istanza del cluster di failover. È consigliabile evitare l'utilizzo di 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.

Panoramica dell'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'avvio dell'istanza dell'istanza del cluster di failover, uno dei nodi presuppone la proprietà del gruppo di risorse e ne porta online l'istanza SQL Server. Le risorse di proprietà di questo nodo includono:

• Nome della rete

• Indirizzo IP

• Dischi condivisi

• Servizio Motore di database di SQL Server

• servizio SQL Server Agent

• 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 altre informazioni, vedere Modalità quorum WSFC e configurazione di voto (;SQL Server);.

Tempo stimabile di failover

A seconda dell'ultima esecuzione dell'istanza di SQL Server un'operazione di checkpoint, è possibile che nella cache del buffer sia presente una notevole quantità di pagine sporche. 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 MicrosoftSQL Server 2012, l'istanza del cluster di failover può usare checkpoint indiretti per limitare la quantità di pagine sporche 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 MicrosoftSQL Server 2012, 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 Failover Policy for Failover Cluster Instances

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. In caso di errore (errori hardware, errori del sistema operativo, errori dell'applicazione o del servizio) o di un aggiornamento pianificato, la proprietà del gruppo di risorse viene spostata in un altro nodo dell'istanza dell'istanza del cluster di failover. Il numero di nodi supportati in un gruppo di risorse WSFC dipende dall'edizione 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.

Archiviazione
Diversamente dal gruppo di disponibilità Always On, 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 in dischi di cluster WSFC, dischi su una rete SAN o condivisioni di file con 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