Condividi tramite

Clustering di failover e Gruppi di disponibilità Always On (SQL Server)

  • Articolo

Si applica a: SQL Server - Solo Windows

Gruppi di disponibilità Always On, la soluzione per disponibilità elevata e ripristino di emergenza introdotta in SQL Server 2012 (11.x), richiede WSFC (Windows Server Failover Clustering). Inoltre, sebbene Gruppi di disponibilità Always On non dipenda dal clustering di failover di SQL Server, è possibile usare un'istanza di clustering di failover per ospitare una replica di disponibilità per un gruppo di disponibilità. È importante conoscere la funzione di ogni tecnologia di clustering e sapere quali sono le considerazioni necessarie per la progettazione di un ambiente di Gruppi di disponibilità Always On.

Nota

Per altre informazioni sui concetti relativi ai Gruppi di disponibilità Always On, vedere Panoramica dei gruppi di disponibilità Always On (SQL Server).

Clustering di failover di Windows Server e gruppi di disponibilità

La distribuzione di Gruppi di disponibilità Always On richiede un cluster WSFC (Windows Server Failover Cluster). Per essere abilitata per Gruppi di disponibilità Always On, un'istanza di SQL Server deve trovarsi in un nodo WSFC e il nodo e il cluster WSFC devono essere online. Inoltre, ogni replica di disponibilità di un gruppo di disponibilità deve risiedere in un nodo diverso da quello del cluster WSFC. L'unica eccezione è che quando viene eseguita la migrazione a un altro cluster WSFC, un gruppo di disponibilità può risiedere temporaneamente in due cluster.

Gruppi di disponibilità Always On si basa sul cluster WSFC (Windows Server Failover Cluster) per monitorare e gestire i ruoli correnti delle repliche di disponibilità che appartengono a un determinato gruppo di disponibilità e per determinare in che modo un evento di failover influisce sulle repliche di disponibilità. Il gruppo di risorse WSFC viene creato per ogni gruppo di disponibilità che viene creato. Il cluster WSFC esegue il monitoraggio del gruppo di risorse per valutare lo stato di integrità della replica primaria.

Il quorum di Gruppi di disponibilità Always On si basa su tutti i nodi del cluster WSFC, indipendentemente dal fatto che un nodo del cluster ospiti una replica di disponibilità o meno. A differenza del mirroring del database, non esiste alcun ruolo del server di controllo in Gruppi di disponibilità Always On.

L'integrità complessiva di un cluster WSFC è determinata dai voti di un quorum di nodi nel cluster. Se il cluster WSFC viene portato offline a causa di un'emergenza non pianificata o di un errore persistente dell'hardware o di comunicazione, è necessario un intervento amministrativo manuale. Un amministratore di cluster Windows Server or WSFC dovrà forzare un quorum e, successivamente, riportare online i nodi del cluster ancora esistenti in una configurazione non a tolleranza d'errore.

Importante

Le chiavi del Registro di sistema di Gruppi di disponibilità Always On sono sottochiavi del cluster WSFC. Se si elimina e si ricrea un cluster WSFC, è necessario disabilitare e riabilitare la funzionalità Gruppi di disponibilità Always On in ogni istanza di SQL Server in cui è ospitata una replica di disponibilità nel cluster WSFC originale.

Per informazioni sull'esecuzione di SQL Server nei nodi WSFC e sul quorum WSFC, vedere Windows Server Failover Clustering con SQL Server.

Istanze del cluster di failover e gruppi di disponibilità di SQL Server

È possibile configurare un secondo livello di failover a livello di istanza del server implementando un'istanza del cluster di failover di SQL Server insieme al cluster WSFC. Una replica di disponibilità può essere ospitata da un'istanza autonoma di SQL Server o da un'istanza del cluster di failover. Solo un partner di un'istanza del cluster di failover può ospitare una replica per un gruppo di disponibilità. Quando una replica di disponibilità viene eseguita in un'istanza del cluster di failover, l'elenco dei possibili proprietari per il gruppo di disponibilità conterrà solo il nodo FCI attivo.

Gruppi di disponibilità Always On non dipende da alcun mezzo di archiviazione condivisa. Tuttavia, se si usa un'istanza del cluster di failover di SQL Server per ospitare una o più repliche di disponibilità, per ognuna di tali istanze sarà richiesta l'archiviazione condivisa in base all'installazione dell'istanza del cluster di failover di SQL Server standard.

Per altre informazioni sui prerequisiti aggiuntivi, vedere la sezione "Prerequisiti e restrizioni per l'uso di un'istanza del cluster di failover di SQL Server per ospitare una replica di disponibilità" di Prerequisiti, restrizioni e consigli per i gruppi di disponibilità Always On (SQL Server).

Confronto tra le istanze del cluster di failover e i gruppi di disponibilità

Indipendentemente dal numero di nodi nell'istanza FCI, in un'intera FCI viene ospitata una sola replica all'interno di un gruppo di disponibilità. Nella tabella seguente sono descritte le differenze dei concetti tra i nodi di un'istanza FCI e le repliche all'interno di un gruppo di disponibilità.

Nodi all'interno di un'istanza FCI Repliche all'interno di un gruppo di disponibilità
Usa cluster WSFC Sì Sì
Livello di protezione Istanza Database
Tipo di archiviazione Condiviso Non condivisi

Mentre le repliche di un gruppo di disponibilità non condividono le risorse di archiviazione, una replica ospitata da un'istanza del cluster di failover usa una soluzione di archiviazione condivisa come richiesto da tale istanza. La soluzione di archiviazione è condivisa solo dai nodi all'interno dell'istanza FCI e non tra le repliche del gruppo di disponibilità.
Soluzioni di archiviazione Collegamento diretto, rete SAN, punti di montaggio, SMB Dipende dal tipo di nodo
Secondarie leggibili No* Sì
Impostazioni dei criteri di failover applicabili Quorum WSFC

Specifiche per FCI

Impostazioni dei gruppi di disponibilità**		 Quorum WSFC

Impostazioni gruppo di disponibilità
Risorse di cui è stato eseguito il failover Server, istanza e database Solo database

* Mentre le repliche secondarie sincrone di un gruppo di disponibilità sono sempre in esecuzione nelle rispettive istanze di SQL Server, i nodi secondari in un'istanza del cluster di failover non hanno avviato le rispettive istanze di SQL Server e quindi non sono leggibili. In un'istanza del cluster di failover, un nodo secondario consente di avviare l'istanza di SQL Server solo quando la proprietà del gruppo di risorse viene trasferita a questo nodo durante un failover dell'istanza del cluster di failover. Tuttavia, nel nodo FCI attivo, se un database ospitato da FCI appartiene a un gruppo di disponibilità e la replica di disponibilità locale è in esecuzione come replica secondaria leggibile, il database è leggibile.

** Le impostazioni dei criteri di failover per il gruppo di disponibilità si applicano a tutte le repliche, indipendentemente dal fatto che siano ospitate in un'istanza autonoma o in un'istanza del cluster di failover.

Nota

Per altre informazioni sul numero di nodi all'interno delle istanze del cluster di failover e sui Gruppi di disponibilità Always On per edizioni diverse di SQL Server, vedere Funzionalità supportate dalle edizioni di SQL Server 2012 (https://go.microsoft.com/fwlink/?linkid=232473).

Considerazioni sull'hosting di una replica di disponibilità in un'istanza FCI

Importante

Se si intende ospitare una replica di disponibilità in un'istanza del cluster di failover di SQL Server (FCI), assicurarsi che i nodi host di Windows Server 2008 soddisfino i prerequisiti e le restrizioni di Always On per le istanze del cluster di failover (FCI). Per altre informazioni, vedere Prerequisiti, restrizioni e consigli per i gruppi di disponibilità Always On (SQL Server).

Le istanze del cluster di failover di SQL Server non supportano il failover automatico da gruppi di disponibilità, pertanto le replica di disponibilità ospitate da un'istanza del cluster di failover possono essere configurate solo per il failover manuale.

Può essere necessario configurare un cluster WSCF per includere i dischi condivisi che non sono disponibili in tutti i nodi. Ad esempio, si consideri un cluster WSFC in due data center con tre nodi. Due dei nodi ospitano un'istanza FCI di SQL nel data center principale e hanno accesso agli stessi dischi condivisi. Al terzo nodo è permesso ospitare un'istanza autonoma di SQL Server in un data center diverso, ma non è consentito accedere ai dischi condivisi dal data center principale. Questa configurazione WSFC supporta la distribuzione di un gruppo di disponibilità se nell'istanza FCI è ospitata la replica primaria e in quella autonoma la replica secondaria.

Se si decide che in un'istanza FCI venga ospitata una replica di disponibilità per un determinato gruppo di disponibilità, assicurarsi che un failover dell'istanza FCI non possa comportare il tentativo da parte di un unico nodo WSFC di ospitare due repliche di disponibilità per lo stesso gruppo di disponibilità.

Nello scenario di esempio seguente si descrivono i potenziali problemi causati da questa configurazione:

Marcel configura un cluster WSFC con due nodi, NODE01 e NODE02. Installa un'istanza del cluster di failover di SQL ServerfciInstance1 in NODE01 e NODE02, dove NODE01 è il proprietario corrente di fciInstance1.
In NODE02 Marcel installa un'altra istanza di SQL Server, Instance3, che è un'istanza autonoma.
In NODE01 Marcel abilita fciInstance1 per Gruppi di disponibilità Always On. In NODE02 abilita Instance3 per Gruppi di disponibilità Always On. Successivamente configura un gruppo di disponibilità per il quale in fciInstance1 è ospitata la replica primaria e in Instance3 quella secondaria.
A un certo punto fciInstance1 non è più disponibile in NODE01 e il cluster WSFC causa il failover di fciInstance1 in NODE02. Dopo il failover, fciInstance1 è un'istanza abilitata per Gruppi di disponibilità Always On in esecuzione con il ruolo primario in NODE02. Tuttavia, Instance3 si trova ora nello stesso nodo WSFC di fciInstance1. Questa è una violazione del vincolo di Gruppi di disponibilità Always On.
Per risolvere il problema presentato in questo scenario, l'istanza autonoma, Instance3, deve trovarsi in un altro nodo dello stesso cluster WSFC come NODE01 e NODE02.

Per altre informazioni sulle istanze del cluster di failover di SQL Server, vedere Istanze del cluster di failover Always On (SQL Server).

Le restrizioni sull'utilizzo di Gestione cluster di failover WSFC con i gruppi di disponibilità

Non utilizzare Gestione cluster di failover per modificare i gruppi di disponibilità, ad esempio:

  • Non aggiungere o rimuovere risorse nel servizio del cluster (gruppo di risorse) per il gruppo di disponibilità.

  • Non modificare le proprietà del gruppo di disponibilità, ad esempio i possibili proprietari e i proprietari preferiti. Queste proprietà vengono impostate automaticamente dal gruppo di disponibilità.

  • Non usare Gestione cluster di failover per spostare i gruppi di disponibilità in altri nodi o per effettuarne il failover. Gestione cluster di failover non è in grado di rilevare lo stato di sincronizzazione delle repliche di disponibilità, pertanto possono verificarsi tempi di inattività prolungati. È necessario usare Transact-SQL o SQL Server Management Studio.

Avviso

L'uso di Gestione cluster di failover per lo spostamento di un'istanza di cluster di failover che ospita un gruppo di disponibilità in un nodo che ospita già una replica dello stesso gruppo di disponibilità può causare la perdita della replica del gruppo di disponibilità, impedendo che venga portato online sul nodo di destinazione. Un singolo nodo di un cluster di failover non può ospitare più di una replica dello stesso gruppo di disponibilità. Per altre informazioni su come si verifica questa situazione e sulle misure da adottare, vedere il blog Replica rimossa in modo imprevisto nel gruppo di disponibilità.

Contenuto correlato

Vedi anche

Panoramica di Gruppi di disponibilità AlwaysOn (SQL Server)
Abilitare e disabilitare i gruppi di disponibilità Always On (SQL Server)
Monitorare Gruppi di disponibilità (Transact-SQL)
Istanze del cluster di failover Always On (SQL Server)