Istanze del cluster di failover Always On (SQL Server)

2025-06-27

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 ulteriori informazioni, vedere Clustering di failover e gruppi di disponibilità Always On (SQL Server).

Le istanze del cluster di failover di SQL Server supportano Storage Spaces Direct (S2D) per risorse di archiviazione del cluster, introdotte in Windows Server 2016 Datacenter Edition. Per altre informazioni, vedere Spazi di archiviazione diretta in Windows Server 2016.

Le istanze del cluster di failover supportano anche i volumi condivisi cluster (clustered shared volumes, CSV). Per altre informazioni, vedere Comprendere i volumi condivisi cluster in un cluster di failover.

Vantaggi di un'istanza del cluster di failover

Quando si verifica un errore hardware o software di un server, le applicazioni o i client che si connettono al server riscontrano tempi di inattività. I nodi ridondanti garantiscono la disponibilità dell'istanza di SQL Server quando è in un cluster di failover anziché un'istanza autonoma. Solo un nodo per volta nell'istanza del cluster di failover possiede il gruppo di risorse WSFC. Se si verifica un errore (ad esempio un errore hardware, un errore del sistema operativo, un errore dell'applicazione o del servizio) o durante un aggiornamento pianificato, il cluster sposta la proprietà del gruppo di risorse in 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 automatica in caso di malfunzionamento (malfunzionamenti hardware, malfunzionamenti del sistema operativo o malfunzionamenti delle applicazioni e dei servizi).

Importante

In un gruppo di disponibilità, il failover automatico da un'istanza di failover ad altri nodi all'interno del gruppo di disponibilità non è supportato. Ciò significa che le istanze dei cluster di failover (FCI) e i nodi autonomi non devono essere accoppiati insieme in un gruppo di disponibilità, se il failover automatico è un componente importante nella vostra soluzione di alta disponibilità. 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 insieme all'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.

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 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:

A meno che non si verifichi un errore hardware o di sistema, tutte le pagine dirty della cache del buffer vengono scritte su disco.
Tutti i rispettivi servizi SQL Server nel gruppo di risorse vengono arrestati sul nodo attivo.
La proprietà del gruppo di risorse viene trasferita a un altro nodo nell'istanza del cluster di failover.
I servizi SQL Server vengono avviati dal nuovo proprietario del gruppo di risorse.
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. Anche se questo usa più risorse con un carico di lavoro regolare, rende il tempo di failover più prevedibile e più configurabile. Ciò è utile quando il contratto di servizio nell'organizzazione specifica l'obiettivo del tempo di ripristino (RTO) per la soluzione a disponibilità elevata. Per ulteriori informazioni sui checkpoint indiretti, vedere Indirect Checkpoints.

Criteri di failover flessibili e monitoraggio dell'integrità affidabile

Dopo l'inizio del FCI, il servizio WSFC monitora sia l'integrità del cluster WSFC che 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 un criterio di failover più flessibile, in cui è possibile scegliere quali condizioni di errore attivano i failover e quali condizioni di errore non lo fanno.
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. In caso di errore (errori hardware, errori del sistema operativo o errori delle applicazioni e dei servizi) o di un aggiornamento pianificato, la proprietà del gruppo di risorse viene trasferita a un altro nodo nell'FCI. 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.

File 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 da WSFC.

Immagazzinamento

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

Concetti e attività	Articolo
Descrive il meccanismo di rilevamento dell'errore e i criteri di failover flessibili.	Criteri di failover per istanze del cluster di failover
Descrive i concetti dell'amministrazione e della manutenzione dell'istanza del cluster di failover.	Amministrazione e manutenzione dell'istanza del cluster di failover
Descrive la configurazione di più subnet e concetti	Clustering su più subnet di SQL Server (SQL Server)

Configurazione supportata dell'istanza del cluster di failover di SQL Server nel cluster di failover di Windows Server (WSFC)

Microsoft supporta le istanze di cluster di failover SQL Server basate su WSFC nei seguenti prodotti:

Windows Server 2012
Windows Server 2012 R2
Edizioni Standard e Datacenter di Windows Server 2016
Edizioni Standard e Datacenter di Windows Server 2019
Windows Server 2022 Standard e Datacenter Editions

Nota

Per Windows Server 2012 e 2012 R2, vedere i criteri di supporto Microsoft per i cluster di failover di Windows Server.

Windows Server offre due tipi di servizi di clustering:

Solo le soluzioni cluster server possono essere usate insieme a SQL Server per la disponibilità elevata se un nodo viene perso o se si verifica un problema con un'istanza di SQL Server. Il bilanciamento del carico di rete può essere usato in alcuni casi insieme alle installazioni di SQL Server di sola lettura autonome.

Ogni istanza del cluster di failover di SQL Server richiede:

Un gruppo di cluster dedicato con lettere di unità disco assegnate in modo univoco.
Almeno un indirizzo IP univoco.
Nomi univoci di istanza e server virtuali all'interno del dominio.

Supporto della soluzione cluster di terze parti

SQL Server viene sviluppato e testato con Microsoft Server Clustering. Quando si usa un prodotto di clustering di terze parti, il contatto principale del supporto tecnico per problemi di installazione, prestazioni o comportamento del cluster deve essere il provider di soluzioni di terze parti. Microsoft offre supporto commerciale ragionevole per le installazioni di cluster di terze parti, in modo analogo al supporto per le distribuzioni autonome di SQL Server.

Numero di nodi supportati

Per informazioni dettagliate sul numero massimo di nodi supportati per le istanze del cluster di failover Always On, vedere:

Sistema operativo supportato

Per i sistemi operativi supportati per il clustering di failover di SQL Server, vedere Verificare il sistema operativo prima di installare il clustering di failover.

Unità montate

L'uso di unità montate non è supportato in un cluster che include un'installazione di SQL Server. Per altre informazioni, vedere Supporto di SQL Server per i volumi montati.

Volumi condivisi cluster

SQL Server 2012 (11.x) e versioni precedenti non supportano l'uso di CSV per SQL Server in un cluster di failover.

Per usare CSV con SQL Server 2014 (12.x) o versioni successive, esaminare le risorse seguenti:

Restrizioni del controller di dominio

Le istanze del cluster di failover di SQL Server non sono supportate nei nodi dell'istanza del cluster di failover configurati come controller di dominio.

Considerazioni sulla migrazione del dominio

Non è possibile eseguire la migrazione di SQL Server 2005 (9.x) e versioni successive a un nuovo dominio. È necessario disinstallare e reinstallare i componenti del cluster di failover. Per altre informazioni su come spostare un cluster Windows Server da un dominio a un altro, vedere Spostare un cluster Windows Server da un dominio a un altro.

Prima di disinstallare SQL Server, è necessario eseguire i passaggi seguenti:

Impostare SQL Server per usare la sicurezza in modalità mista o aggiungere nuovi account di dominio agli account di accesso di SQL Server.
Rinominare la cartella DATA contenente i database di sistema in modo che possa essere nuovamente scambiata dopo la reinstallazione per ridurre i tempi di inattività.
Non rimuovere uno dei componenti seguenti: file di supporto di SQL Server, SQL Server Native Client, Integration Services o Componenti workstation, a meno che non si ricompila l'intero nodo.

Avvertimento

Se si verificano errori durante il processo di annullamento dell'installazione, potrebbe essere necessario ricompilare il nodo per installare di nuovo SQL Server.

Condividi tramite