Gruppi di disponibilità per SQL Server in Linux

Si applica a:SQL Server su Linux

Questo articolo descrive le caratteristiche dei gruppi di disponibilità in installazioni di SQL Server basate su Linux. Vengono inoltre illustrate le differenze tra gruppi di disponibilità basati su cluster di failover Linux e su cluster di failover Windows Server (WSFC). Vedere Che cos'è un gruppo di disponibilità Always On? per le nozioni di base dei gruppi di disponibilità, poiché funzionano allo stesso modo in Windows e Linux, ad eccezione del WSFC.

Dal punto di vista generale, i gruppi di disponibilità in SQL Server in Linux sono gli stessi delle implementazioni basate su WSFC. In altre parole, non vi sono differenze in termini di limitazioni e funzionalità, con alcune eccezioni. Di seguito sono elencate le principali differenze:

• Microsoft Distributed Transaction Coordinator (DTC) è supportato in Linux a partire da SQL Server 2017 CU 16. Tuttavia, DTC non è ancora supportato nei gruppi di disponibilità in Linux. Se le tue applicazioni richiedono l'uso di transazioni distribuite e richiedono un gruppo di disponibilità (AG), distribuire SQL Server su Windows.
• Le distribuzioni basate su Linux che richiedono disponibilità elevata usano Pacemaker per il clustering anziché un cluster WSFC.
• A differenza della maggior parte delle configurazioni di disponibilità dei gruppi in Windows, fatta eccezione per lo scenario di cluster del gruppo di lavoro, Pacemaker non richiede Active Directory Domain Services (AD DS).
• Come eseguire il failover di un gruppo di alta disponibilità da un nodo a un altro è diverso tra Linux e Windows.
• Alcune impostazioni, ad esempio required_synchronized_secondaries_to_commit, possono essere modificate solo tramite Pacemaker in Linux, mentre un'installazione basata su WSFC usa Transact-SQL.

Numero di repliche e nodi del cluster

Un AG in SQL Server Standard Edition può avere un totale di due repliche: una primaria e una secondaria utilizzabile solo per scopi di disponibilità. Non è possibile usarle per altri scopi, ad esempio per le query leggibili. Un gruppo di disponibilità (AG) in SQL Server Enterprise edition può avere fino a nove repliche totali: una replica primaria e fino a otto repliche secondarie, di cui fino a tre (compresa la replica primaria) possono essere sincrone. Se si usa un cluster sottostante, possono essere presenti al massimo 16 nodi in totale, quando viene usato Corosync. Un gruppo di disponibilità può estendersi al massimo nove dei 16 nodi con SQL Server Enterprise Edition e due con SQL Server Standard Edition.

Per una configurazione a due repliche in cui è richiesta la possibilità di eseguire automaticamente il failover in un'altra replica, è necessario usare una replica di sola configurazione, come descritto in Replica di sola configurazione e quorum. Le repliche di sola configurazione sono state introdotte con SQL Server 2017 (14.x) a partire dall'Aggiornamento Cumulativo 1 (CU 1), quindi questa dovrebbe essere la versione minima implementata per tale configurazione.

Se usato, Pacemaker deve essere configurato correttamente in modo da rimanere attivo. Ciò significa che il quorum e l'isolamento di un nodo non riuscito devono essere implementati correttamente dal punto di vista di Pacemaker, oltre a qualsiasi requisito di SQL Server, come una replica solo di configurazione.

Le repliche secondarie leggibili sono supportate solo con SQL Server Enterprise Edition.

Tipo di cluster e modalità di failover

Nuovo a SQL Server 2017 (14.x) è l'introduzione di un tipo di cluster per i gruppi di disponibilità (AGs). Per Linux, i valori validi sono due: Esterno and Nessuno. Se il tipo di cluster è "External", Pacemaker viene utilizzato come cluster sottostante al gruppo di disponibilità (AG). L'uso di External per il tipo di cluster richiede che la modalità di failover sia impostata anche su Esterno (anche nuova in SQL Server 2017 (14.x)). Il failover automatico è supportato, ma a differenza di un WSFC, quando si utilizza Pacemaker, la modalità di failover è impostata su External, non automatica. Diversamente da quanto avviene per un cluster WSFC, l'elemento Pacemaker del gruppo di disponibilità viene creato dopo la configurazione del gruppo.

Se il tipo di cluster è None, significa che Pacemaker non è necessario e non viene usato dal gruppo di disponibilità. Anche nei server in cui è configurato Pacemaker, se un gruppo di disponibilità è configurato con un tipo di cluster None, Pacemaker non vede né gestisce quel gruppo di disponibilità. Un tipo di cluster "None" supporta solo il failover manuale dalla replica primaria a quella secondaria. Un gruppo di disponibilità creato con l'impostazione 'Nessuno' è destinato principalmente agli aggiornamenti e alla scalabilità in lettura. Sebbene possa essere utilizzato in scenari come il ripristino di emergenza o la disponibilità locale dove non è richiesta una commutazione automatica, non è consigliato. Senza Pacemaker, la storia del listener diventa più complessa.

Il tipo di cluster viene archiviato nella SQL Server DMV (Dynamic Management View) sys.availability_groups, nelle colonne cluster_type e cluster_type_desc.

secondari_sincronizzati_richiesti_per_commettere

La novità di SQL Server 2017 (14.x) è un'impostazione utilizzata dai gruppi di disponibilità, chiamati required_synchronized_secondaries_to_commit. Questa impostazione indica all'AG il numero di repliche secondarie che devono essere completamente allineate con quella primaria. Ciò consente di eseguire operazioni come il failover automatico, solo se integrato con Pacemaker con un tipo di cluster External, e controlla il comportamento di determinate funzionalità, come la disponibilità della replica primaria se il numero corretto di repliche secondarie è online oppure offline. Per comprendere questa modalità di funzionamento, vedere Disponibilità elevata e protezione dei dati per le configurazioni del gruppo di disponibilità. Il valore required_synchronized_secondaries_to_commit viene impostato per impostazione predefinita e gestito da Pacemaker/SQL Server. È possibile eseguire l'override di questo valore manualmente.

La combinazione di required_synchronized_secondaries_to_commit e il nuovo numero di sequenza (archiviato in sys.availability_groups) informa Pacemaker e SQL Server che, ad esempio, il failover automatico può aver luogo. In tal caso, una replica secondaria ha lo stesso numero di sequenza di quella primaria e pertanto è aggiornata con tutte le informazioni di configurazione più recenti.

Per required_synchronized_secondaries_to_commit è possibile impostare tre valori, ovvero 0, 1 o 2. Questi valori controllano il comportamento di ciò che accade quando una replica diventa non disponibile. I numeri corrispondono al numero di repliche secondarie che devono essere sincronizzate con la replica primaria. In Linux si verifica il comportamento seguente:

required_synchronized_secondaries_to_commit controlla non solo il comportamento dei failover con le repliche sincrone, ma anche la perdita di dati. Con un valore 1 o 2, una replica secondaria deve essere sempre sincronizzata per assicurare la ridondanza dei dati. Ciò significa che non si verificherà alcuna perdita di dati.

Per modificare il valore di required_synchronized_secondaries_to_commit, usare la sintassi seguente:

Red Hat Enterprise Linux (RHEL) e Ubuntu

sudo pcs resource update <AGResourceName> required_synchronized_secondaries_to_commit=<value>

SUSE Linux Enterprise Server (SLES)

sudo crm resource param ms-<AGResourceName> set required_synchronized_secondaries_to_commit <value>

In questo esempio, <AGResourceName> è il nome della risorsa configurata per l'AG, e <value> è 0, 1 o 2. Per ripristinare l'impostazione predefinita in base alla quale Pacemaker gestisce il parametro, eseguire la stessa istruzione senza alcun valore.

Il failover automatico di un gruppo di disponibilità è possibile quando sono soddisfatte le condizioni seguenti:

• Per la replica primaria e quella secondaria è impostato lo spostamento dei dati sincrono.
• Lo stato della replica secondaria è sincronizzato (non in fase di sincronizzazione). Ciò significa che le due repliche si trovano nello stesso punto dati.
• Il tipo di cluster è impostato su External. Il failover automatico non è possibile con un tipo di cluster "None".
• Il valore di sequence_number della replica secondaria che diventerà primaria è quello più alto. In altre parole, il valore di sequence_number della replica secondaria corrisponde a quello della replica primaria originale.

Se queste condizioni sono soddisfatte e avviene un guasto del server che ospita la replica primaria, la proprietà dell'Availability Group (AG) passa a una replica sincrona. Il comportamento per le repliche sincrone (che possono essere tre in totale: una primaria e due secondarie) può essere ulteriormente controllato da required_synchronized_secondaries_to_commit. Funziona con i gruppi di disponibilità (AGs) sia su Windows che su Linux, ma viene configurato in modo diverso. In Linux, il valore viene configurato automaticamente dal cluster sulla risorsa AG stessa.

Replica di sola configurazione e quorum

È stata introdotta una replica di sola configurazione per risolvere le limitazioni nella gestione del quorum con Pacemaker, specialmente quando si isola un nodo guasto. La configurazione a due nodi non funziona per un gruppo di disponibilità. Per un'FCI, i meccanismi di quorum forniti da Pacemaker possono essere appropriati perché tutti gli arbitraggi del failover avvengono a livello di cluster. Per un gruppo di disponibilità (AG), l'arbitrato su Linux avviene in SQL Server, dove sono archiviati tutti i metadati. A questo punto entra in gioco la replica di sola configurazione.

Se non vi fosse altro, sarebbero necessari un terzo nodo e almeno una replica sincronizzata. La replica di sola configurazione archivia la configurazione del gruppo di disponibilità nel database master, allo stesso modo delle altre repliche nella configurazione del gruppo di disponibilità. Nella replica di sola configurazione, i database utente non partecipano al gruppo di disponibilità (AG). I dati di configurazione vengono inviati in modo sincrono dal primario. Questi dati di configurazione vengono quindi usati durante i failover, indipendentemente dal fatto che siano automatici o manuali.

Per mantenere il quorum e abilitare i failover automatici con un cluster di tipo External, un gruppo di disponibilità deve soddisfare una delle seguenti condizioni:

• Disporre di tre repliche sincrone (solo SQL Server Enterprise Edition); oppure
• Due repliche (una primaria e una secondaria) e una replica di sola configurazione.

I failover manuali possono verificarsi sia utilizzando il tipo di cluster External che None per le configurazioni AG. Anche se una replica di sola configurazione può essere configurata con un gruppo di disponibilità con tipo di cluster None, questa configurazione non è consigliata perché ha l'effetto di complicare la distribuzione. Per le configurazioni di questo tipo, modificare required_synchronized_secondaries_to_commit manualmente impostando almeno un valore 1, in modo che almeno una replica venga sincronizzata.

Una replica di sola configurazione può essere ospitata in qualsiasi edizione di SQL Server, inclusa SQL Server Express. Ciò riduce al minimo i costi di licenza e garantisce che funzioni con i gruppi di disponibilità in SQL Server Standard Edition. Ciò significa che il terzo server necessario deve soddisfare solo la specifica minima per SQL Server, poiché non riceve traffico delle transazioni degli utenti per l'AG.

Quando viene usata una replica di sola configurazione, si verifica il comportamento seguente:

• Per impostazione predefinita, il valore di required_synchronized_secondaries_to_commit è 0. Questa impostazione può essere modificata manualmente su 1, se lo si desidera.

• Se si verifica un errore nella replica primaria e il valore di required_synchronized_secondaries_to_commit è 0, la replica secondaria diventa primaria ed è disponibile sia per la lettura che per la scrittura. Se il valore è 1, viene eseguito il failover automatico, ma non sono accettate nuove transazioni finché l'altra replica non sarà online.

• Se si verifica un errore nella replica secondaria e il valore di required_synchronized_secondaries_to_commit è 0, la replica primaria accetterà comunque le transazioni. Se però a questo punto si verifica un errore anche nella replica primaria, non sarà disponibile alcuna protezione per i dati e non potrà essere eseguito nemmeno il failover (manuale o automatico), poiché non sarà disponibile una replica secondaria.

• Se si verifica un errore nella replica configurata solo per la configurazione, il gruppo di disponibilità funziona normalmente, ma non è possibile il failover automatico.

• Se si verifica un errore sia in una replica secondaria sincrona che nella replica di sola configurazione, quella primaria non potrà accettare transazioni e non sarà disponibile alcuna replica per il failover.

Gruppi di disponibilità multipli

È possibile creare più di un gruppo di disponibilità (AG) per ogni cluster di Pacemaker o set di server. L'unica limitazione è rappresentata dalle risorse di sistema. La proprietà del gruppo di disponibilità viene visualizzata dal server primario. Gruppi di disponibilità diversi possono essere di proprietà di nodi diversi; non devono tutti funzionare sullo stesso nodo.

Posizione di unità e cartelle per i database

Come nei gruppi di disponibilità basati su Windows, l'unità e la struttura di cartelle per i database utente che fanno parte di un gruppo di disponibilità devono essere identici. Ad esempio, se i database utente si trovano in /var/opt/mssql/userdata nel server A, la stessa cartella deve esistere nel server B. L'unica eccezione è riportata nella sezione Interoperabilità con gruppi di disponibilità e repliche basate su Windows.

Il listener sotto Linux

Il listener è una funzionalità facoltativa per un AG. Offre un singolo punto di ingresso per tutte le connessioni (di lettura/scrittura nella replica primaria e/o di sola lettura nelle repliche secondarie). In questo modo, non è necessario che le applicazioni e gli utenti finali conoscano il server che ospita i dati. In un cluster WSFC, si tratta della combinazione di una risorsa nome di rete e di una risorsa IP, che viene quindi registrata in AD DS (se necessario) e in DNS. In combinazione con la risorsa AG (gruppo di disponibilità) stessa, fornisce tale astrazione. Per altre informazioni su un ascoltatore, vedere Connessione a un ascoltatore di un gruppo di disponibilità Always On.

Il listener in Linux è configurato in modo diverso, ma offre la stessa funzionalità. Non esiste un concetto di risorsa nome di rete in Pacemaker e non è nemmeno presente un oggetto creato in AD DS. In Pacemaker viene semplicemente creata una risorsa indirizzo IP che può essere eseguita su uno qualsiasi dei nodi. È necessario creare una voce associata alla risorsa IP per il listener in DNS con un nome amichevole. La risorsa IP per l'ascoltatore è attiva solo sul server che ospita la replica primaria per il gruppo di disponibilità.

Se si usa Pacemaker e viene creata una risorsa indirizzo IP associata all'ascoltatore, si verifica una breve interruzione perché l'indirizzo IP si arresta su un server e viene avviato sull'altro, indipendentemente dal fatto che si tratti di un failover automatico o manuale. Anche se ciò offre un'astrazione tramite la combinazione di un nome e di un indirizzo IP singoli, l'interruzione non viene mascherata. Un'applicazione deve essere in grado di gestire la disconnessione presentando alcune funzionalità per rilevare l'interruzione e riconnettersi.

La combinazione del nome DNS e dell'indirizzo IP non è tuttavia sufficiente per fornire tutte le funzionalità di un listener in un cluster WSFC, ad esempio il routing di sola lettura per le repliche secondarie. Quando configuri un AG, è comunque necessario configurare un listener in SQL Server. Questa operazione può essere visualizzata nella procedura guidata e nella sintassi Transact-SQL. Esistono due modi in cui è possibile configurare questa opzione per funzionare come in Windows:

• Per un gruppo di disponibilità (AG) con un tipo di cluster External, l'indirizzo IP associato al listener creato in SQL Server deve essere l'indirizzo IP della risorsa creata in Pacemaker.
• Per un gruppo di disponibilità creato con un tipo di cluster Nessuno, usare l'indirizzo IP collegato alla replica primaria.

L'istanza associata all'indirizzo IP fornito assume quindi il ruolo di coordinatore per azioni come le richieste di routing di sola lettura provenienti dalle applicazioni.

Interoperabilità con gruppi di disponibilità e repliche basati su Windows

Un AG con un tipo di cluster External o WSFC non può avere le sue repliche su più piattaforme. Questo vale se il gruppo di disponibilità è SQL Server Standard Edition o SQL Server Enterprise Edition. In altre parole, in una configurazione tradizionale di un Gruppo di Disponibilità (AG) con un cluster sottostante, una replica non può essere in un cluster WSFC mentre l'altra è in Linux con Pacemaker.

Un AG con un tipo di cluster NONE può avere repliche che attraversano i confini tra diversi sistemi operativi, quindi potrebbero esserci repliche basate su Linux e Windows nello stesso AG. Di seguito è riportato un esempio in cui la replica primaria è Windows, mentre la replica secondaria si trova in una delle distribuzioni Linux.

Anche un gruppo di disponibilità distribuito può attraversare i confini dei sistemi operativi. Gli AG sottostanti sono vincolati dalle regole su come sono configurati, ad esempio, uno configurato con External solo per Linux, mentre l'AG al quale viene aggiunto può essere configurato con un WSFC. Si consideri l'esempio seguente:

Contenuto correlato

• Configurare un gruppo di disponibilità di SQL Server per alta disponibilità su Linux
• Configurare un gruppo di disponibilità SQL Server per la scalabilità in lettura in Linux
• Configurare un cluster Pacemaker per gruppi di disponibilità di SQL Server
• Configurare il gruppo di disponibilità Always On di SQL Server in Windows e Linux (multipiattaforma)