Condividi tramite

Cluster di Failover e gruppi di disponibilità Always On (SQL Server)

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). Anche se i gruppi di disponibilità AlwaysOn non dipendono 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 il ruolo di ogni tecnologia di clustering e sapere quali considerazioni sono necessarie durante la progettazione dell'ambiente dei gruppi di disponibilità AlwaysOn.

Nota

Per informazioni sui concetti relativi ai gruppi di disponibilità AlwaysOn, vedere Che cos'è un gruppo di disponibilità AlwaysOn?

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 di testimone 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

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 maggiori informazioni sull'esecuzione di SQL Server nei nodi WSFC e sui quorum di WSFC, vedere Clustering di failover di Windows Server con SQL Server.

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

È 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. Un'istanza autonoma di SQL Server o un'istanza FCI (istanza del cluster di failover) può ospitare una replica di disponibilità. 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 Prerequisiti, restrizioni e consigli per i gruppi di disponibilità AlwaysOn (SQL Server).

Confronto tra istanze del cluster di failover e 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

Anche se 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 in un gruppo di disponibilità sono sempre in esecuzione sulle rispettive istanze di SQL Server, i rispettivi nodi secondari in un gruppo di failover in realtà non hanno avviato le rispettive istanze di SQL Server e pertanto non sono accessibili in lettura. 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, quando un database ospitato dall'istanza del cluster di failover appartiene a un gruppo di disponibilità, il database è leggibile se la replica locale di disponibilità è operativa come replica secondaria leggibile.

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

Considerazioni sull'hosting di una replica di alta disponibilità su un'istanza di un cluster di failover.

Importante

Se si prevede di ospitare una replica di disponibilità in un'istanza Always On di Failover Cluster (FCI) di SQL Server, assicurarsi che i nodi host di Windows Server 2008 soddisfino i prerequisiti e le restrizioni per le istanze di Failover Cluster (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 parte dei gruppi di disponibilità, quindi qualsiasi replica di disponibilità ospitata da un'istanza del cluster di failover può essere configurata solo per il failover manuale.

Potrebbe essere necessario configurare un cluster WSFC per includere 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 nodi costruiscono un'istanza FCI (cluster di failover) di SQL Server nel data center primario e hanno accesso agli stessi dischi condivisi. Il terzo nodo ospita un'istanza autonoma di SQL Server in un data center diverso e non ha accesso ai dischi condivisi dal data center primario. Questa configurazione WSFC supporta la distribuzione di un gruppo di disponibilità se l'FCI ospita la replica primaria e l'istanza autonoma ospita la replica secondaria.

Quando si sceglie un'istanza del cluster di failover per ospitare una replica di disponibilità per un determinato gruppo di disponibilità, assicurarsi che un failover dell'istanza del cluster di failover non possa potenzialmente causare un singolo nodo WSFC a tentare 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:

  • È possibile configurare un cluster WSFC con due nodi, NODE01 e NODE02.
  • Installi un'istanza del cluster di failover di SQL Server fciInstance1sia in NODE01 che in NODE02, in cui NODE01 è l'attuale proprietario di fciInstance1.
  • In NODE02si installa un'altra istanza di SQL Server, Instance3, che è un'istanza autonoma.
  • Su NODE01, si abilita fciInstance1 per i gruppi di disponibilità Always On. Su NODE02, si abilita Instance3 per i gruppi di disponibilità Always On. Si configura quindi un gruppo di disponibilità per il quale fciInstance1 ospita la replica primaria e Instance3 ospita la replica secondaria.
  • A un certo punto, fciInstance1 diventa non disponibile in NODE01, e WSFC causa un failover di fciInstance1 a 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 da questo scenario, l'istanza autonoma, Instance3, deve risiedere in un altro nodo nello stesso cluster WSFC di NODE01 e NODE02.

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

Restrizioni sull'uso di Gestione WSFC con gruppi di disponibilità

Non usare Gestione cluster di failover per modificare i gruppi di disponibilità. Per esempio:

  • Non aggiungere o rimuovere risorse nel servizio cluster (gruppo di risorse) dell'Availability Group.

  • Non modificare le proprietà del gruppo di disponibilità, ad esempio i proprietari possibili 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 nodi diversi o per eseguire il failover dei gruppi di disponibilità. Il Gestore del Cluster di Failover non è a conoscenza dello stato di sincronizzazione delle repliche di disponibilità, e ciò può causare periodi di inattività prolungati. È necessario usare Transact-SQL o SQL Server Management Studio.

Avviso

L'utilizzo di Gestione cluster di failover per spostare un'istanza del cluster di failover che ospita un gruppo di disponibilità su un nodo che già ospita una replica dello stesso gruppo di disponibilità può comportare la perdita della replica del gruppo di disponibilità, impedendo che quest'ultima venga avviata online sul nodo di destinazione. Un singolo nodo di un cluster di failover non può ospitare più repliche per lo stesso gruppo di disponibilità. Per altre informazioni su come si verifica questa situazione e su come eseguire il ripristino, vedere il blog Replica eliminata in modo imprevisto nel gruppo di disponibilità.

Contenuti correlati

  • Last updated on