Condividi tramite

Clustering di failover e gruppi di disponibilità AlwaysOn (SQL Server)

  • Articolo

Always On gruppi di disponibilità, la soluzione di ripristino di emergenza e disponibilità elevata introdotta in SQL Server 2014, richiede il clustering di failover di Windows Server (WSFC). Inoltre, anche se Always On gruppi di disponibilità non dipende da SQL Server clustering di failover, è possibile usare un'istanza di clustering di failover per ospitare una replica di disponibilità per un gruppo di disponibilità. È importante conoscere il ruolo di ogni tecnologia di clustering e sapere quali considerazioni sono necessarie durante la progettazione dell'ambiente gruppi di disponibilità Always On.

Nota

Per informazioni sui concetti relativi ai gruppi di disponibilità Always On, vedere Panoramica dei gruppi di disponibilità AlwaysOn (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 Clustering). Per essere abilitato per i gruppi di disponibilità Always On, è necessario che un'istanza di SQL Server si trovi in un nodo WSFC e il cluster WSFC sia online. Inoltre, ogni replica di disponibilità di un gruppo di disponibilità deve risiedere in un nodo diverso dello stesso 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.

Always On Gruppi di disponibilità si basa sul cluster WSFC (Windows Failover Clustering) per monitorare e gestire i ruoli correnti delle repliche di disponibilità appartenenti a un determinato gruppo di disponibilità e per determinare come un evento di failover influisce sulle repliche di disponibilità. Il gruppo di risorse WSFC viene creato per ogni gruppo di disponibilità che viene creato. Con il cluster WSFC è possibile eseguire il monitoraggio del gruppo di risorse per valutare lo stato di integrità della replica primaria.

Il quorum per i gruppi di disponibilità di Always On è basato su tutti i nodi nel cluster WSFC, indipendentemente dal fatto che un determinato nodo del cluster ospita repliche di disponibilità. Al contrario del mirroring del database, non esiste alcun ruolo di controllo nei 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

Always On le chiavi del Registro di sistema dei gruppi di disponibilità sono sottochiave del cluster WSFC. Se si elimina e si crea nuovamente un cluster WSFC, è necessario disabilitare e riabilitare la funzionalità gruppi di disponibilità Always On in ogni istanza di SQL Server che ospitava una replica di disponibilità nel cluster WSFC originale.

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

Migrazione tra cluster di gruppi di disponibilità AlwaysOn per l'aggiornamento del sistema operativo

A partire da SQL Server 2012 SP1, Always On Gruppi di disponibilità supporta la migrazione tra cluster dei gruppi di disponibilità per le distribuzioni in un nuovo cluster WSFC (Windows Server Failover Clustering). In una migrazione tra cluster un gruppo o un batch di gruppi di disponibilità viene spostato nel nuovo cluster WSFC di destinazione con tempi di inattività minimi. Il processo di migrazione tra cluster consente di gestire i contratti di servizio (SLA, Service Level Agreement) durante l'aggiornamento a un cluster Windows Server 2012. SQL Server 2012 SP1 (o una versione successiva) deve essere installato e abilitato per AlwaysOn nel cluster WSFC di destinazione. L'esito positivo della migrazione tra cluster dipende da una pianificazione e una preparazione dettagliate del cluster WSFC di destinazione.

Per ulteriori informazioni, vedere Migrazione tra cluster di gruppi di disponibilità AlwaysOn per l'aggiornamento del sistema operativo.

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 SQL Server clustering di failover 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.

Always On Gruppi di disponibilità non dipende da alcuna forma 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 SQL Server per ospitare una replica di disponibilità" dei prerequisiti, delle restrizioni e delle raccomandazioni per i gruppi di disponibilità AlwaysOn (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à
Utilizzo di cluster WSFC Sì Sì
Livello di protezione Istanza Database
Tipo di archiviazione Condiviso Non condivisi

Si noti che, 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
Repliche 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 del clustering di failover e sui gruppi di disponibilità AlwaysOn per diverse edizioni 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 AlwaysOn per le istanze del cluster di failover (FCI). Per altre informazioni, vedere Prerequisiti, restrizioni e consigli per i gruppi di disponibilità AlwaysOn (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.

Potrebbe essere necessario configurare un cluster WSCF (Windows Server Failover Clustering) 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. A due dei nodi è consentito ospitare un'istanza del clustering di failover di SQL Server (FCI) nel data center principale, nonché accedere 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 del cluster 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 i gruppi di disponibilità di Always On. In NODE02, consente Instance3 di Always On gruppi di disponibilità. 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 NODE01e il cluster WSFC comporta il failover di fciInstance1 in NODE02. Dopo il failover, fciInstance1 è un'istanza abilitata per i gruppi di disponibilità Always On in esecuzione nel ruolo primario in NODE02. Tuttavia, Instance3 si trova ora nello stesso nodo WSFC di fciInstance1. Ciò viola il vincolo Always On gruppi di disponibilità.
Per risolvere il problema presentato in questo scenario, l'istanza autonoma, Instance3, deve trovarsi in un altro nodo dello stesso cluster WSFC come per NODE01 e NODE02.

Per altre informazioni su SQL Server clustering di failover, vedere Istanze del cluster di failover AlwaysOn (SQL Server).For more information about SQL Server failover clustering, see AlwaysOn Failover Cluster Instances (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 utilizzare 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.

Contenuto correlato

Vedere anche

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