Condividi tramite

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

Gruppi di disponibilità Always On, la soluzione di disponibilità elevata e ripristino di emergenza introdotta in SQL Server 2014 richiede Windows Server Failover Clustering (WSFC). Anche se i Gruppi di Disponibilità Always On non dipendono dal clustering di failover di SQL Server, è possibile utilizzare un'istanza di clustering di failover per ospitare una replica di disponibilità all'interno di un gruppo di disponibilità. È importante conoscere il ruolo di ogni tecnologia di clustering e sapere quali considerazioni sono necessarie durante la progettazione dell'ambiente dei gruppi di disponibilità AlwaysOn.

Annotazioni

Per informazioni sui concetti relativi ai gruppi di disponibilità AlwaysOn, 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à AlwaysOn richiede un cluster WSFC (Windows Server Failover Clustering). Per abilitare i gruppi di disponibilità AlwaysOn, è necessario che un'istanza di SQL Server risieda in un nodo WSFC e che il cluster e il nodo WSFC siano online. Inoltre, ogni replica di disponibilità di un determinato 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.

I gruppi di disponibilità Always On si basano 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 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 monitora questo gruppo di risorse per valutare l'integrità della replica primaria.

Il quorum per i gruppi di disponibilità AlwaysOn si basa su tutti i nodi del cluster WSFC indipendentemente dal fatto che un determinato nodo del cluster ospiti repliche di disponibilità. A differenza del mirroring del database, non esiste alcun ruolo di controllo nei gruppi di disponibilità AlwaysOn.

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

Importante

Le chiavi del Registro di sistema dei gruppi di disponibilità AlwaysOn sono sottochiavi del cluster WSFC. Se si elimina e si ricrea un cluster WSFC, è necessario disabilitare e riabilitare la funzionalità Gruppi di disponibilità AlwaysOn 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 Windows Server Failover Clustering (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, i gruppi di disponibilità AlwaysOn supportano la migrazione tra cluster dei gruppi di disponibilità per le distribuzioni in un nuovo cluster WSFC (Windows Server Failover Clustering). Una migrazione tra cluster sposta un gruppo di disponibilità o un batch di gruppi di disponibilità nel nuovo cluster WSFC di destinazione con tempi di inattività minimi. Il processo di migrazione tra cluster consente di mantenere i contratti di servizio durante l'aggiornamento a un cluster Windows Server 2012. SQL Server 2012 SP1 (o versione successiva) deve essere installato e abilitato per AlwaysOn nel cluster WSFC di destinazione. L'esito positivo di una migrazione tra cluster dipende dalla pianificazione e dalla preparazione completa del cluster WSFC di destinazione.

Per altre 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 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.

I gruppi di disponibilità Always On non dipendono 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 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à
Usa il cluster WSFC Sì Sì
Livello di protezione Istanza Banca dati
Tipo di archiviazione Condiviso Non condivisi

Si noti che, mentre le repliche in un gruppo di disponibilità non condividono l'archiviazione, una replica ospitata da un'istanza del cluster di failover usa una soluzione di archiviazione condivisa come richiesto dall'istanza del cluster di failover. 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.

Annotazioni

Per altre informazioni sul numero di nodi all'interno del clustering di failover e dei 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 prevede di ospitare una replica di disponibilità in un'istanza del cluster di failover di SQL Server, assicurarsi che i nodi host di Windows Server 2008 soddisfino i prerequisiti e le restrizioni AlwaysOn per le istanze del cluster di failover. 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 WSFC (Windows Server Failover Clustering) per includere dischi condivisi non disponibili in tutti i nodi. Si consideri, ad esempio, un cluster WSFC in due data center con tre nodi. Nel data center primario due nodi ospitano un'istanza di cluster di failover di SQL Server 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 del cluster WSFC (Windows Server Failover Cluster) supporta il deployment di un gruppo di disponibilità se l'FCI ospita la replica primaria e l'istanza stand-alone ospita 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 su NODE01 che su NODE02 dove NODE01 è il proprietario attuale di fciInstance1.
In NODE02Marcel installa un'altra istanza di SQL Server, Instance3, che è un'istanza autonoma.
In NODE01Marcel abilita fciInstance1 per i gruppi di disponibilità AlwaysOn. In NODE02, abilita Instance3 per i gruppi di disponibilità Always On. Quindi configura un gruppo di disponibilità per il quale fciInstance1 ospita la replica primaria e Instance3 ospita la replica secondaria.
A un certo punto fciInstance1 non è disponibile in NODE01, e il cluster WSFC causa un failover di fciInstance1 a NODE02. Dopo il failover, fciInstance1 è un'istanza abilitata per i gruppi di disponibilità Always On in esecuzione nel ruolo primario su NODE02. Tuttavia, Instance3 si trova ora nello stesso nodo WSFC di fciInstance1. In questo modo viene violato il vincolo Gruppi di disponibilità AlwaysOn.
Per risolvere il problema presentato da questo scenario, l'istanza autonoma, Instance3, deve risiedere in un altro nodo nello stesso cluster WSFC di NODE01 e NODE02.

Per ulteriori informazioni sulle istanze AlwaysOn Failover Cluster di SQL Server, vedere 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 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.

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)

  • Last updated on