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

Articolo
08/27/2013

Gruppi di disponibilità AlwaysOn, la soluzione di ripristino di emergenza a disponibilità elevata introdotta in SQL Server 2012, richiede WSFC (Windows Server Failover Clustering). Sebbene inoltre Gruppi di disponibilità AlwaysOn non dipenda dal clustering di failover di SQL Server, è possibile utilizzare 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à AlwaysOn.

[!NOTA]

Per informazioni sui concetti Gruppi di disponibilità AlwaysOn, vedere Panoramica di Gruppi di disponibilità AlwaysOn (SQL Server).

Contenuto dell'argomento

Windows Server Failover Clustering
Clustering di failover di SQL Server
Le restrizioni sull'utilizzo di Gestione cluster di failover WSFC con i gruppi di disponibilità

Clustering di failover di Windows Server e gruppi di disponibilità

La distribuzione dei Gruppi di disponibilità AlwaysOn richiede un cluster WSCF (Windows Server Failover Clustering). Per essere abilitata per Gruppi di disponibilità AlwaysOn, 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 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.

Gruppi di disponibilità AlwaysOn si basa sul cluster WSFC (Windows Server Failover Clustering) 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 influisca 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 di Gruppi di disponibilità AlwaysOn si basa su tutti i nodi del cluster WSFC, indipendentemente dal fatto che un nodo del cluster ospiti una replica di disponibilità. A differenza del mirroring del database, non esiste alcun ruolo del server di controllo in Gruppi di disponibilità AlwaysOn.

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à AlwaysOn sono sottochiavi del cluster WSFC. Se si elimina e si ricrea un cluster WSFC, è necessario disabilitare e riabilitare la funzionalità di Gruppi di disponibilità AlwaysOn in ogni istanza di SQL Server nel cui cluster WSFC originale era ospitata una replica di disponibilità.

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

Icona freccia utilizzata con il collegamento Torna all'inizio [Inizio pagina]

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

A partire da SQL Server 2012 SP1, in Gruppi di disponibilità AlwaysOn è supportata migrazione tra cluster di gruppi di disponibilità per 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 versioni successive) 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 il clustering 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 FCI. 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à AlwaysOn non dipende da alcun mezzo di archiviazione condivisa. Tuttavia, se si utilizza un'istanza del cluster di failover (FCI) di SQL Server per ospitare una o più repliche di disponibilità, per ognuna di queste FCI sarà richiesta l'archiviazione condivisa in base all'installazione dell'istanza del cluster di failover di SQL Server standard.

Per ulteriori informazioni sui prerequisiti aggiuntivi, vedere la sezione "Prerequisiti e restrizioni per l'utilizzo 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à 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	Shared	Non condivisa1
Soluzioni di archiviazione	Collegamento diretto, rete SAN, punti di montaggio, SMB	Dipende dal tipo di nodo
Secondarie leggibili	No2	Sì
Impostazioni dei criteri di failover applicabili	Quorum WSFC Specifiche per FCI Impostazioni dei gruppi di disponibilità3	Quorum WSFC Impostazioni dei gruppi di disponibilità
Risorse di cui è stato eseguito il failover	Server, istanza e database	Solo database

1Mentre le repliche di un gruppo di disponibilità non condividono l'archiviazione, per una replica ospitata da un'istanza FCI viene utilizzata una soluzione di archiviazione condivisa come richiesto da quell'istanza FCI. La soluzione di archiviazione è condivisa solo dai nodi all'interno dell'istanza FCI e non tra le repliche del gruppo di disponibilità.

2Mentre 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 FCI non hanno consentito l'avvio delle rispettive istanze di SQL Server e, pertanto, non sono leggibili. In un'istanza FCI, 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 FCI. 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.

3Le 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 FCI.

[!NOTA]

Per ulteriori informazioni su Numero di nodi all'interno di Clustering di failover e Gruppi di disponibilità AlwaysOn 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 AlwaysOn per le istanze del cluster di failover (FCI). Per ulteriori 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 Server, fciInstance1, sia in NODE01 sia in 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à AlwaysOn. In NODE02 abilita Instance3 per Gruppi di disponibilità AlwaysOn. 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 comporta il failover di fciInstance1 in NODE02. Dopo il failover, fciInstance1 è un'istanza abilitata per Gruppi di disponibilità AlwaysOn in esecuzione nel ruolo primario di NODE02. Tuttavia, Instance3 si trova ora nello stesso nodo WSFC di fciInstance1. Viene pertanto violato il vincolo Gruppi di disponibilità AlwaysOn.

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 ulteriori informazioni sul clustering di failover di SQL Server, vedere Istanze del cluster di failover AlwaysOn (SQL Server).

Icona freccia utilizzata con il collegamento Torna all'inizio [Torna all'inizio]

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 utilizzare Transact-SQL o SQL Server Management Studio.

Icona freccia utilizzata con il collegamento Torna all'inizio [Inizio pagina]