SQL Server Cluster di failover: guida completa per DBA [2026]

SQL Server il cluster di failover è un soluzione ad alta disponibilità che mantiene un SQL Server istanza operativa anche in caso di guasto di un server. Ciò è possibile eseguendo la stessa istanza su più server fisici, chiamati nodi, in modo che, se un server si guasta, un altro subentri automaticamente senza richiedere interventi manuali o modifiche sul lato client.

1.2 Componenti chiave e architettura

A SQL Server L'istanza del cluster di failover è costituita da cinque componenti principali, ognuno dei quali svolge un ruolo distinto. Insieme, formano un'unica unità logica con cui i client interagiscono come se si trattasse di un unico server.

nodi: I server fisici che partecipano al cluster. In qualsiasi momento, esattamente un nodo è attivo ed esegue il SQL Server istanza; i nodi rimanenti restano in attesa e monitorano lo stato di salute del nodo attivo.
Archiviazione condivisa: Un volume di storage (SAN, iSCSI, Storage Spaces Direct o condivisione file SMB) accessibile da tutti i nodi contemporaneamente. Poiché ogni nodo legge e scrive sullo stesso storage, non è necessaria alcuna replica dei dati tra i nodi e gli stessi file di database sono immediatamente disponibili indipendentemente dal nodo che assume il controllo.
Nome della rete virtuale e indirizzo IP virtuale: Un'identità stabile a cui i client si connettono sempre, indipendentemente dal nodo fisico attualmente attivo. Quando si verifica un failover, il nome della rete virtuale e l'indirizzo IP vengono nuovamente registrati sul nuovo nodo attivo, rendendo il passaggio trasparente alle applicazioni.
Clustering di failover di Windows Server (WSFC): La piattaforma sottostante che tiene tutto insieme. WSFC monitora costantemente lo stato di salute dei nodi e delle risorse tramite una rete heartbeat, gestisce la proprietà dei gruppi di risorse e orchestra il processo di failover quando viene rilevato un errore.
Quorum: Un meccanismo di voto all'interno di WSFC che previene scenari di split-brain. Ogni nodo esprime un voto sullo stato di salute del cluster; un disco witness o una condivisione file fornisce un voto aggiuntivo sui cluster con nodi pari. Il cluster rimane online solo quando la maggior parte dei voti è raggiungibile, garantendo che due gruppi di nodi isolati non possano mai rivendicare contemporaneamente la proprietà del cluster. SQL Server esempio.

Questi componenti funzionano in una gerarchia chiara: WSFC gestisce i nodi e impone il quorum, i nodi condividono l'accesso allo stesso storage e il nome della rete virtuale fornisce ai client un punto di connessione coerente su tutto. Quando un nodo si guasta, WSFC rileva la perdita del heartbeat, conferma che il quorum è ancora valido, trasferisce la proprietà del gruppo di risorse, inclusi il nome della rete virtuale, l'IP virtuale e lo storage, a un nodo di standby e lo ripristina. SQL Server di nuovo online. L'intera sequenza avviene automaticamente e senza alcuna modifica richiesta dal lato client.

1.3 FCI vs Gruppi di disponibilità Always On

SQL Server fornisce due tecnologie Always On basate su WSFC. Le principali differenze:

Istanza del cluster di failover (FCI): Alta disponibilità (HA) a livello di istanza. Tutti i database eseguono il failover contemporaneamente. Richiede storage condiviso. Nessuna replica dei dati tra i nodi. Nessun disaster recovery (DR) integrato.
Gruppi di disponibilità sempre attivi (AG): Alta disponibilità a livello di database. Replica basata su log su repliche secondarie. Non è richiesto alcun storage condiviso. Supporta sia HA che DR.

Utilizzare FCI per il failover a livello di istanza con storage condiviso esistente. Combinare FCI con un AG quando sono richiesti anche disaster recovery o storage secondari leggibili.

1.4 Vantaggi e limitazioni

Vantaggi:

Failover automatico in caso di guasto dell'hardware, del sistema operativo o del servizio;
nessuna riconfigurazione del client;
tempo di failover prevedibile tramite checkpoint indiretti;
opzioni di archiviazione condivisa flessibili.

limitazioni:

L'archiviazione condivisa rappresenta un singolo punto di errore, a meno che l'archiviazione stessa non sia ridondante;
Viene eseguito solo un nodo SQL Server in un momento in cui non c'è bilanciamento del carico di lettura;
Nessuna DR integrata senza associazione con un AG.

2. Prerequisiti e requisiti

Hardware e software 2.1

Almeno due server fisici con hardware identico o equivalente, processori a 64 bit e controller di archiviazione certificati per il clustering di failover.
Windows Server 2016, 2019 o 2022 (Standard o Datacenter). Tutti i nodi devono eseguire la stessa edizione, versione e livello di aggiornamento cumulativo del sistema operativo.
SQL Server Edizione Standard o Enterprise. Tutti i nodi devono eseguire lo stesso SQL Server versione e livello di patch.

2.2 Requisiti di rete e dominio

Tutti i nodi devono appartenere allo stesso dominio Active Directory. I cluster di gruppi di lavoro, i cluster multidominio e i controller di dominio di sola lettura non sono supportati.
Assegnare indirizzi IP statici a tutti gli adattatori. Dedicare almeno una scheda di interfaccia di rete (NIC) per nodo al traffico heartbeat del cluster. Configurare il Domain Name System (DNS) per la risoluzione dei nomi.
L'account di installazione richiede diritti di amministratore locale su tutti i nodi e Creare oggetti informatici autorizzazione in Active Directory.

2.3 Opzioni di archiviazione condivisa

SQL Server Il clustering di failover supporta diverse tecnologie di storage condiviso. Scegli quella più adatta alla tua infrastruttura e al tuo budget:

SAN (Fibre Channel o iSCSI): La situazione più comune. Tutti i nodi devono accedere agli stessi numeri di unità logiche (LUN). Utilizzare I/O multipath (MPIO) per evitare guasti a percorso singolo.
Spazi di archiviazione diretti (S2D): Unità NVMe o SSD collegate localmente e distribuite tra i nodi. Richiede Windows Server 2016 Datacenter o versione successiva.
Condivisioni file Server Message Block (SMB) e Cluster Shared Volumes (CSV): Supportato da SQL Server Dal 2014 in poi.

Formattare tutti i dischi del cluster come file system NT di base (NTFS). Evitare volumi montati sui nodi del cluster.

3. Pianificazione del cluster

Prima dell'installazione, è necessario pianificare il tipo di configurazione del nodo e la configurazione del quorum, che influiscono direttamente sull'affidabilità del cluster e sul costo dell'hardware:

3.1 Tipi di configurazione

SQL Server I cluster di failover supportano quattro tipi di configurazioni dei nodi, ognuna delle quali offre un diverso compromesso tra semplicità, costo hardware e capacità di standby.

Tipo 1: Attivo/Standby. 1 FCI, 2 nodi. Il nodo 1 è attivo; il nodo 2 è di standby. Il nodo di standby monitora continuamente il heartbeat del nodo attivo e subentra nell'FCI in caso di guasto del nodo attivo. Questa è la configurazione più semplice e più comune in produzione.
Tipo 2: Attivo/Attivo. 2 FCI che condividono 2 nodi fisici. Il Nodo 1 è il Nodo Attivo per l'FCI 1 e il Nodo di Standby per l'FCI 2; il Nodo 2 è il Nodo Attivo per l'FCI 2 e il Nodo di Standby per l'FCI 1. I due nodi sono standby reciproci: entrambi gestiscono carichi di lavoro attivi durante il normale funzionamento. In caso di guasto di uno dei due nodi, il nodo superstite subentra al FCI del nodo guasto, continuando a gestire il proprio. Ogni nodo deve quindi essere dimensionato per gestire il carico di lavoro combinato di entrambi i FCI.
Tipo 3: N+1. N FCI che condividono N+1 nodi. Ogni FCI ha un nodo attivo; tutti gli N FCI condividono un singolo nodo di standby comune. Il nodo di standby condiviso deve essere in grado di assorbire in modo indipendente l'intero carico di lavoro di un qualsiasi nodo attivo guasto.
Tipo 4: N+M. N FCI che condividono N+M nodi. Ogni FCI ha un nodo attivo; tutti gli N FCI condividono M nodi in standby. I M nodi in standby coprono collettivamente il failover per tutti gli N nodi attivi, distribuendo il carico potenziale su una maggiore capacità in standby e riducendo i requisiti hardware per nodo rispetto a N+1.

3.2 Linee guida sul quorum

Il quorum determina se il cluster ha un numero sufficiente di membri attivi per rimanere online. Tenere presenti le seguenti linee guida quando si imposta e si gestisce il quorum:

Configurare un numero totale dispari di voti per il quorum per garantire la maggioranza in uno scenario di divisione ed evitare lo split-brain.
Per cluster a due nodi, utilizzare Maggioranza di nodi e dischi con un disco di controllo come terzo voto. Il disco di controllo non necessita di una lettera di unità.
Se il quorum viene completamente perso, come ultima risorsa forzare il quorum per recuperare i nodi rimanenti, quindi riconfigurare immediatamente prima di tornare in produzione.

4. Installazione di Windows Server Failover Cluster (WSFC)

4.1 Preparare l'archiviazione condivisa

Collegare e configurare tutto lo storage condiviso prima di creare il cluster.

Collegare fisicamente o fornire tutti i LUN di storage a ogni nodo del cluster.
Sulla solo il primo nodo, Aperto Gestione disco, portare ogni disco online, inizializzarlo e creare un NTFS volume con una lettera di unità. Creare un piccolo volume (1–2 GB) per il disco di controllo: non è richiesta una lettera di unità.
Su ogni nodo rimanente, apri Gestione disco e portare i dischi solo online. Non reinizializzare o riformattare. Assegnare manualmente le lettere di unità se non corrispondono al primo nodo.

4.2 Installare la funzionalità di clustering di failover e convalidare

Installare la funzionalità Failover Clustering su ogni nodo, quindi convalidare prima di creare il cluster.

Su ogni nodo, apri Server manager -> Aggiungi ruoli e funzionalità -> Funzioni, selezionare Clustering di failovere fare clic InstallazioneRiavviare se richiesto. Alternativa a PowerShell:
```
Install-WindowsFeature -Name Failover-Clustering -IncludeManagementTools
```
Su un nodo qualsiasi, apri Gestore del cluster di failover -> Convalida la configurazioneAggiungere tutti i nomi host dei nodi ed eseguire tutti i test. Alternativa PowerShell:
```
Test-Cluster -Node Node1, Node2
```
Risolvere tutti gli errori nel report di convalida prima di procedere. Gli avvisi di Storage Spaces Direct possono essere ignorati se S2D non è in uso.

4.3 Creare il WSFC

Dopo aver superato la convalida, creare il cluster e verificarne la configurazione.

In Gestore del cluster di failover, fare clic su Crea cluster, aggiungi tutti i nomi host dei nodi, inserisci il nome del cluster e un indirizzo IP virtuale statico, quindi fai clic AvantiAlternativa a PowerShell:
```
New-Cluster -Name ClusterName -Node Node1, Node2 -StaticAddress x.x.x.x
```
Se le autorizzazioni di dominio sono limitate, chiedere all'amministratore di Active Directory di predisporre l'oggetto computer del nome del cluster prima di eseguire questo passaggio.
Dopo la creazione, confermare che il quorum sia visualizzato Maggioranza di nodi e dischi con il disco testimone assegnato.
Sotto Archiviazione -> Dischi, rinominare ogni disco del cluster per riflettere il suo ruolo (ad esempio, SQL_DATA, SQL_LOG, TESTIMONE). Sotto Reti, rinominare ogni rete cluster in modo che rifletta il tipo di traffico.

5. Installazione SQL Server Istanza del cluster di failover

5.1 Scegliere un metodo di installazione

SQL Server Il programma di installazione offre due approcci per l'installazione di un'istanza del cluster di failover. Seleziona quello più adatto al tuo ambiente.

Installazione integrata (Aggiungi nodo): Installare un FCI completo e operativo sul primo nodo, quindi aggiungere ogni nodo successivo utilizzando Aggiungi nodo Opzione più semplice e consigliata per la maggior parte delle implementazioni.
Installazione avanzata/aziendale: Correre Preparare il cluster di failover prima su tutti i nodi, poi esegui Cluster di failover completo sul nodo proprietario del disco condiviso. Utilizzare questo approccio per grandi implementazioni multi-nodo in cui si desidera preparare tutti i nodi in parallelo prima del commit.

5.2 Prima installazione del nodo

Correre SQL Server Impostare sul primo nodo la creazione dell'FCI utilizzando il metodo integrato.

Correre Setup.exe come amministratore. Seleziona Installazione -> New SQL Server installazione del cluster di failover.
On Selezione funzionalitàscegli Servizi del motore di database and Strumenti di gestione - Base.
On Configurazione dell'istanza, Inserisci il SQL Server Nome di rete: il nome virtuale utilizzato dai client per connettersi.
On Gruppo di risorse del cluster, immettere un nome descrittivo per il gruppo.
On Selezione del disco del cluster, seleziona dischi condivisi per dati, log e file di backup.
On Configurazione della rete del cluster, assegna un indirizzo IP per ogni subnet. Il programma di installazione imposta automaticamente una dipendenza OR per i cluster multi-subnet.
On Configurazione del server, imposta gli account di servizio. Utilizza un account di servizio gestito da gruppo (gMSA) per la gestione automatizzata delle password; utilizza gli account di dominio come fallback.
On Configurazione del motore di database, scegli una modalità di autenticazione e imposta i percorsi delle directory dei dati. Posiziona i database di sistema, i database utente, i log, i backup e TempDB su dischi separati.
Rivedi il riepilogo e clicca Installazione.

5.3 Aggiungi nodi rimanenti

Dopo aver completato il primo nodo, aggiungere ogni nodo aggiuntivo all'FCI.

Sul nodo aggiuntivo, esegui Setup.exe e seleziona Installazione -> Aggiungi nodo a un SQL Server cluster di failover.
On Configurazione dei nodi del cluster, seleziona l'istanza FCI esistente.
On Configurazione della rete del cluster, assegna l'indirizzo IP per la subnet di questo nodo.
On Conti di servizio, confermare che le password dell'account di servizio corrispondano a quelle impostate sul primo nodo, quindi fare clic su Installazione.
Ripetere l'operazione per ogni nodo aggiuntivo.

6. Post-installazione: configurazione e test

6.1 Essenziale SQL Server Impostazioni profilo

Applicare queste impostazioni subito dopo che l'FCI è operativo.

Impostato memoria massima del server per tappare SQL Servermemoria e lasciare spazio per i servizi del sistema operativo e del cluster:
```
EXEC sp_configure 'show advanced options', 1; RECONFIGURE;
EXEC sp_configure 'max server memory', <value_in_MB>; RECONFIGURE;
```
Impostato massimo grado di parallelismo (MAXDOP) in base alla topologia NUMA (Non-Uniform Memory Access).

Spostare TempDB su un volume dedicato per isolarne l'I/O:

USE master;
ALTER DATABASE tempdb MODIFY FILE (NAME = tempdev, FILENAME = 'D:\TempDB\tempdb.mdf');
ALTER DATABASE tempdb MODIFY FILE (NAME = templog, FILENAME = 'D:\TempDB\templog.ldf');

Riavvia il SQL Server servizio affinché lo spostamento del file abbia effetto.

6.2 Failover di test

Convalidare il comportamento del failover prima di spostare il cluster in produzione.

In Gestore del cluster di failover, fai clic con il pulsante destro del mouse su SQL Server Ruolo e selezione FCI Sposta -> Seleziona nodo. Scegli il nodo secondario e clicca OK.
Attendi finché non viene visualizzato lo stato del ruolo corsa sul nuovo nodo.
Da una macchina client, connettiti a SQL Server utilizzando il nome della rete virtuale e confermare che la connessione abbia esito positivo senza modificare la stringa di connessione.
Consulta gli SQL Server Il registro degli errori e il registro eventi del cluster Windows confermano un failover corretto entro il tempo di ripristino previsto (RTO).

7. Gestione, buone pratiche e risoluzione dei problemi

7.1 Politica di failover e monitoraggio

In Gestore del cluster di failover, fai clic con il pulsante destro del mouse su SQL Server Ruolo FCI -> Proprietà a Confronto -> failover per impostare il livello di condizione di errore e il timeout del controllo di integrità. Aumentare il timeout sui server con carichi elevati per evitare falsi failover.
Monitorare lo stato del cluster tramite Gestore del cluster di failover, Visualizzatore eventi di Windows, il SQL Server registro degli errori e SQL Server Activity Monitor per la visibilità in tempo reale delle risorse e delle sessioni.
Dopo ogni failover automatico, rivedere il SQL Server registri diagnostici (memorizzati insieme al registro degli errori) per lo stato del componente che ha portato all'evento. Utilizzare SQL Server Eventi estesi per acquisire una traccia dettagliata dello stato di salute delle risorse e delle condizioni di errore relative alla finestra di failover.

7.2 Migliori pratiche

Utilizzare indirizzi IP statici su tutti i nodi. La scadenza del lease DHCP (Dynamic Host Configuration Protocol) durante il failover prolunga i tempi di inattività e complica la registrazione DNS.
Mantenere sempre un numero dispari di voti per il quorum. Aggiungere un testimone se l'aggiunta di un nodo rende il conteggio pari.
Eseguire la convalida del cluster dopo qualsiasi modifica hardware, aggiornamento del driver o modifica significativa della configurazione del sistema operativo.
Assegnare lettere di unità identiche su tutti i nodi prima SQL Server installazione. Le incongruenze bloccano l'installazione e sono difficili da risolvere in seguito.
Contatta l'amministratore di Active Directory prima del giorno dell'installazione. Le autorizzazioni per la creazione di oggetti computer sono il problema più comune che può bloccare l'installazione.
Mantenere un test SQL Server di riserva strategia anche con FCI in atto. FCI protegge dai guasti dei nodi, non dal danneggiamento dei dati, dall'eliminazione accidentale o dalla perdita a livello di storage: una pianificazione regolare di backup e ripristino è l'unica salvaguardia in questi scenari.

7.3 Problemi comuni e soluzioni

Errori di autorizzazione di Active Directory: Chiedi all'amministratore di Active Directory (AD) di predisporre l'oggetto computer del cluster o di concedere Creare oggetti informatici and Leggi tutte le proprietà all'account di installazione.
Archiviazione condivisa non visibile sui nodi: Riavvia il Server di destinazione iSCSI Avviare il servizio sull'host di archiviazione, quindi riconnettersi dall'iniziatore iSCSI su ciascun nodo. Verificare il masking e lo zoning delle LUN.
Avvisi di convalida sui driver o sui livelli di aggiornamento: Applicare l'ultimo aggiornamento cumulativo da Windows Update su tutti i nodi prima di rieseguire la convalida.
WSFC va offline dopo un errore del nodo: Utilizzare il quorum forzato per portare online i nodi sopravvissuti, recuperare tutti i database interessati dal guasto, ripristinare il quorum, quindi riconfigurare prima di tornare alla produzione. Eseguire DBCC CHECKDB su ogni database recuperato per confermarne l'integrità prima di riprendere i normali carichi di lavoro.
Falsi failover automatici: Aumentare il timeout del controllo di integrità nelle proprietà del ruolo FCI. Esaminare i log diagnostici per distinguere un errore reale da un picco transitorio di risorse.

8. FAQs

D: Qual è il numero minimo di nodi richiesti per un SQL Server cluster di failover?

A: Due nodi sono il minimo. Uno funge da nodo attivo che esegue il SQL Server Ad esempio, uno è il nodo di standby; l'altro è quello di riserva. La maggior parte delle implementazioni in produzione inizia con una configurazione attivo/passivo a due nodi.

D: Sì SQL Server FCI richiede uno storage condiviso?

R: Sì. A differenza dei gruppi di disponibilità Always On, un FCI richiede che tutti i nodi accedano allo stesso storage: una SAN (Fibre Channel o iSCSI), Storage Spaces Direct o una condivisione file SMB. Lo storage condiviso è ciò che rende gli stessi file di database accessibili da qualsiasi nodo dopo un failover.

Q: Cosa SQL Server le edizioni supportano il clustering di failover?

A: SQL Server Le edizioni Standard ed Enterprise supportano FCI. Le edizioni Express e Developer no. L'edizione Enterprise supporta più nodi e funzionalità aggiuntive ad alta disponibilità, come le operazioni di indice online durante la manutenzione.

D: Can SQL Server FCI e Always On Availability Group possono essere utilizzati insieme?

R: Sì. Un nodo FCI può ospitare una replica del gruppo di disponibilità, offrendo sia l'alta disponibilità a livello di istanza tramite FCI, sia il ripristino di emergenza a livello di database tramite il gruppo di disponibilità. Tuttavia, il failover automatico del gruppo di disponibilità da o verso una replica ospitata su FCI non è supportato: in questa configurazione è disponibile solo il failover manuale.

D: Quanto dura un SQL Server il failover avviene in genere?

A: Il tempo di failover dipende dal numero di pagine sporche nella cache del buffer che devono essere scritte su disco prima che l'istanza si riavvii sul nuovo nodo. Con i checkpoint indiretti abilitati (l'impostazione predefinita da SQL Server Dal 2012 in poi, le pagine modificate vengono limitate e la maggior parte dei failover si completa in meno di 30 secondi. Il tuo RTO effettivo dipende dal carico di lavoro, dalla velocità di archiviazione e dal tempo di ripristino del database.

D: Cos'è il quorum e perché è importante?

R: Il quorum è il meccanismo utilizzato da WSFC per determinare se il cluster ha abbastanza membri sani per rimanere online e gestire le richieste. Previene uno scenario di "split brain" in cui due gruppi di nodi isolati credono di essere i proprietari autorevoli del cluster. SQL Server Ad esempio, se il quorum viene perso, WSFC mette il cluster offline per proteggere l'integrità dei dati.

D: Can SQL Server FCI può essere installato su un cluster di gruppo di lavoro (senza Active Directory)?

A: No.. SQL Server FCI richiede che tutti i nodi siano membri dello stesso dominio Active Directory. I cluster di gruppi di lavoro, i cluster multidominio e i cluster che includono controller di dominio di sola lettura non sono configurazioni supportate.

D: Cosa succede alle connessioni client quando si verifica un failover?

A: Connessioni attive al SQL Server Le istanze vengono eliminate durante il failover. Dopo che l'istanza torna online sul nuovo nodo, il nome della rete virtuale e l'IP virtuale vengono nuovamente registrati lì e i client che utilizzano la logica di ripetizione nelle loro stringhe di connessione si riconnetteranno automaticamente senza alcuna modifica alla configurazione.

D: Posso aggiungere o rimuovere nodi da un database esistente? SQL Server cluster di failover?

A: Sì. Corri SQL Server Imposta su qualsiasi nodo e scegli Aggiungi nodo a un SQL Server cluster di failover per aggiungere un nodo, o Rimuovi nodo da un SQL Server cluster di failover per rimuoverne uno. L'aggiunta o la rimozione di un nodo non richiede tempi di inattività per gli altri nodi del cluster.

D: Qual è la differenza tra un failover pianificato e un failover automatico?

R: Un failover pianificato viene avviato manualmente da un amministratore, in genere per operazioni di manutenzione come l'applicazione di patch o la sostituzione dell'hardware. Consente SQL Server per eliminare le pagine errate e arrestare il sistema in modo corretto prima del trasferimento della proprietà, riducendo al minimo i tempi di inattività. WSFC attiva un failover automatico quando il monitoraggio dello stato rileva un errore nel nodo attivo e il tempo di ripristino dipende dall'entità del ripristino in caso di crash richiesto.

D: Come posso recuperare un SQL Server cluster di failover se l'intero WSFC va offline?

A: Se il quorum viene perso e il cluster non può avviarsi normalmente, utilizzare il quorum forzato per portare online i nodi rimanenti in uno stato non tollerante ai guasti. Eseguire il seguente comando PowerShell sul nodo rimanente: Start-ClusterNode -ForcQuorumUna volta che il cluster è online, ripristinare i database, verificare l'integrità dei dati e quindi riconfigurare il quorum con i nodi rimanenti prima di tornare alla produzione.

D: Devo eseguire la procedura guidata di convalida del cluster prima di ogni SQL Server installazione?

R: Sì, e anche dopo qualsiasi modifica significativa all'hardware o alla configurazione. Microsoft supporta solo le configurazioni dei cluster di failover che superano tutti i test di convalida senza errori. Saltare la convalida rischia di causare l'esecuzione di una configurazione non supportata che potrebbe comportarsi in modo imprevedibile in caso di errore.

9. CONCLUSIONE

SQL Server Il clustering di failover offre un'elevata disponibilità trasparente a livello di istanza tramite WSFC, con failover automatico e senza necessità di riconfigurazione del client. È la scelta ideale quando è disponibile storage condiviso ed è necessario che ogni database dell'istanza esegua il failover come un'unica unità. Per gli ambienti che richiedono anche disaster recovery o carichi di lavoro di lettura secondari, è possibile abbinare l'FCI ai gruppi di disponibilità Always On per coprire entrambi gli scenari.

Referenze

Documento ufficiale Microsoft: Cluster di failover di Windows Server con SQL Server
Documento ufficiale Microsoft: Istanze del cluster di failover sempre attive
Documento ufficiale Microsoft: Installa un'istanza del cluster di failover
Documento ufficiale Microsoft: Modalità di quorum e configurazione del voto WSFC

L'autore

Yuan Sheng è un amministratore di database senior (DBA) con oltre 10 anni di esperienza in SQL Server ambienti e gestione di database aziendali. Ha risolto con successo centinaia di scenari di ripristino di database in aziende di servizi finanziari, sanitari e manifatturiere.

Yuan è specializzato in SQL Server Ripristino di database, soluzioni ad alta disponibilità e ottimizzazione delle prestazioni. La sua vasta esperienza pratica include la gestione di database multi-terabyte, l'implementazione di gruppi di disponibilità Always On e lo sviluppo di strategie di backup e ripristino automatizzate per sistemi aziendali mission-critical.

Grazie alla sua competenza tecnica e al suo approccio pratico, Yuan si concentra sulla creazione di guide complete che aiutano gli amministratori di database e i professionisti IT a risolvere problemi complessi SQL Server sfide in modo efficiente. Si mantiene aggiornato con le ultime SQL Server versioni e le tecnologie di database in continua evoluzione di Microsoft, testando regolarmente gli scenari di ripristino per garantire che le sue raccomandazioni riflettano le migliori pratiche del mondo reale.

Hai domande su SQL Server recupero o hai bisogno di ulteriore assistenza per la risoluzione dei problemi del database? Yuan accoglie feedback e suggerimenti per migliorare queste risorse tecniche.