Istanze del cluster di failover AlwaysOn (SQL Server)

Nell'offerta SQL Server AlwaysOn, le istanze del cluster di failover AlwaysOn utilizzano 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: l'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 fornire il ripristino di emergenza remoto a livello di database. Per ulteriori 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à AlwaysOn, 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 utilizza 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à AlwaysOn. Con il nuovo supporto di più subnet in Microsoft SQL Server 2012, 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

• Utilizzo rallentato delle risorse durante i failover

Indicazioni

In un ambiente di produzione è consigliabile utilizzare indirizzi IP statici insieme all'indirizzo IP virtuale di un'istanza del cluster di failover, nonché evitare l'utilizzo del protocollo DHCP. 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.

[Inizio pagina]

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'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 della rete

• Indirizzo IP

• Dischi condivisi

• Servizio del motore di database di SQL Server

• Servizio SQL Server Agent

• Il servizio 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 WSFC e configurazione del voto (SQL Server).

Tempo stimabile di failover

A seconda di quando l'istanza di SQL Server ha eseguito l'ultima operazione di checkpoint, è possibile che vi sia una quantità 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, l'istanza del cluster di failover può utilizzare checkpoint indiretti per limitare la quantità 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 Checkpoint indiretti.

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, il servizio WSFC utilizza 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 ulteriori informazioni, vedere Criteri di failover per istanze del cluster di failover

[Inizio pagina]

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 (hardware, del sistema operativo, dell'applicazione o del servizio) o di un aggiornamento pianificato, la proprietà del gruppo di risorse viene spostata a un altro nodo dell'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.

• Archiviazione
  Diversamente dal gruppo di disponibilità AlwaysOn, un'istanza del cluster di failover deve utilizzare 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 della 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.

[Inizio pagina]

Concetti e attività di failover di SQL Server

[Inizio pagina]

Argomenti correlati

[Inizio pagina]