Pacemaker per i gruppi di disponibilità e le istanze di cluster di failover su Linux

Si applica a:SQL Server su Linux

A partire da SQL Server 2017 (14.x), SQL Server è supportato sia in Linux che in Windows. Analogamente alle distribuzioni di SQL Server basate su Windows, SQL Server database e istanze devono essere a disponibilità elevata in Linux. Questo articolo illustra le informazioni di base per comprendere Pacemaker con Corosync e come pianificarlo e distribuirlo per le configurazioni SQL Server.

Nozioni di base sulle estensioni e sui componenti aggiuntivi a disponibilità elevata

Tutte le distribuzioni attualmente supportate forniscono un'estensione o un componente aggiuntivo a disponibilità elevata, basato sullo stack di clustering di Pacemaker. Questo stack incorpora due componenti principali: Pacemaker e Corosync Tutti i componenti dello stack sono:

• Stimolatore cardiaco. Il componente di clustering principale, che esegue operazioni come il coordinamento dei computer in cluster.
• Corosync. Un framework e un set di API che consente, ad esempio, il quorum, la possibilità di riavviare i processi non riusciti e così via.
• libQB. Fornisce, ad esempio, funzionalità come la registrazione.
• Agente della risorsa. Funzionalità specifica fornita per consentire l'integrazione di un'applicazione con Pacemaker.
• Agente di recinzione. Script/funzionalità che facilitano l'isolamento dei nodi e li gestiscono in caso di problemi.

Questa soluzione è in qualche modo simile a, ma in molti modi diversi dalla distribuzione di configurazioni in cluster tramite Windows. In Windows, la modalità di disponibilità del clustering, denominata cluster di failover Windows Server (WSFC), è incorporata nel sistema operativo e la funzionalità che consente la creazione di un cluster WSFC, il clustering di failover, è disabilitata di default. In Windows, gli Availability Groups (AG) e le istanze del cluster di failover (FCI) si basano su un cluster WSFC e hanno un'integrazione stretta a causa della DLL di risorse specifica fornita da SQL Server. Questa soluzione strettamente integrata è possibile in gran parte perché tutti gli elementi provengono da un unico fornitore.

In Linux ogni distribuzione supportata, nonostante disponga di Pacemaker, può essere personalizzata e avere implementazioni e versioni leggermente diverse. Alcune delle differenze risulteranno evidenti dalle istruzioni riportate in questo articolo. Il livello di clustering è open source, quindi anche se viene fornito con le distribuzioni, non è strettamente integrato nello stesso modo in cui un cluster WSFC è in Windows. Questo è il motivo per cui Microsoft fornisce mssql-server-ha, in modo che SQL Server e lo stack Pacemaker possano offrire un'esperienza simile, ma non esattamente la stessa, per i gruppi di disponibilità (AG) e le istanze del cluster di failover (FCI) come sotto i sistemi operativi Windows.

Per la documentazione completa su Pacemaker, inclusa una spiegazione più approfondita di tutti i componenti con informazioni di riferimento complete, per RHEL e SLES:

• RHEL
• SLES
• Ubuntu

Per altre informazioni sull'intero stack, vedere anche la pagina della documentazione di Pacemaker ufficiale sul sito di Clusterlabs.

Concetti e terminologia di Pacemaker

Questa sezione illustra la terminologia e i concetti comuni per un'implementazione di Pacemaker.

nodo

Un nodo è un server che partecipa al cluster. Un cluster Pacemaker supporta a livello nativo un massimo di 16 nodi. Questo numero può essere superato se Corosync non è in esecuzione su nodi aggiuntivi, ma Corosync è necessario per SQL Server. Di conseguenza, il numero massimo di nodi che un cluster può avere per qualsiasi configurazione basata su SQL Server è 16; questo è il limite di Pacemaker e non ha nulla a che fare con le limitazioni massime per i gruppi di disponibilità (AG) o le istanze del cluster di failover (FCI) imposti da SQL Server.

Conto risorse

Il concetto di risorsa è proprio sia dei cluster WSFC che dei cluster Pacemaker. Una risorsa è una funzionalità specifica che viene eseguita nel contesto del cluster, ad esempio un disco o un indirizzo IP. Ad esempio, in Pacemaker possono essere create sia risorse di istanza del cluster di failover (FCI) che risorse del gruppo di disponibilità (AG). Questo non è dissimile da quanto viene fatto in un cluster WSFC, dove si visualizza una risorsa SQL Server sia per un'istanza del cluster di failover che per una risorsa del gruppo di disponibilità durante la configurazione di un gruppo di disponibilità. Tuttavia, non è esattamente la stessa cosa a causa delle differenze fondamentali nel modo in cui SQL Server si integra con Pacemaker.

Pacemaker ha risorse standard e risorse clonate. Le risorse clone sono quelle che vengono eseguite simultaneamente in tutti i nodi. Un esempio può essere quello di un indirizzo IP eseguito su più nodi per bilanciare il carico. Tutte le risorse create per le istanze di cluster di failover (FCI) usano una risorsa standard, poiché soltanto un nodo può ospitare un'istanza di cluster di failover (FCI) in un dato momento.

Quando viene creato un AG, è necessario un tipo specifico di risorsa di clone denominato risorsa multi-stato. Anche se un gruppo di disponibilità ha una sola replica primaria, il gruppo di disponibilità in sé è in esecuzione in tutti i nodi che è configurato per usare e può potenzialmente consentire azioni come l'accesso in sola lettura. Poiché si tratta di un uso "live" del nodo, le risorse hanno due tipi di stati: Promoted (già Master) e Unpromoted (già Slave). Per altre informazioni, vedere Multi-state resources: Resources that have multiple modes (Risorse a più stati: risorse con più modalità).

Set/Gruppi di risorse

Analogamente ai ruoli in un cluster WSFC, un cluster Pacemaker si basa sul concetto di gruppo di risorse. Un gruppo di risorse, denominato set in SLES, è una raccolta di risorse che interagiscono tra loro e possono effettuare il failover da un nodo a un altro come singola unità. I gruppi di risorse non possono contenere risorse configurate come Promoted o Unpromoted; pertanto, non possono essere usati per i gruppi di disponibilità. Anche se un gruppo di risorse può essere utilizzato per le istanze del cluster di failover, generalmente non è consigliato come configurazione.

Vincoli

I cluster WSFC presentano diversi parametri per le risorse, oltre, ad esempio, alle dipendenze, che indicano al cluster WSFC una relazione padre/figlio tra due risorse diverse. Una dipendenza è semplicemente una regola che indica al cluster WSFC quale risorsa deve essere online per prima.

Un cluster Pacemaker non prevede il concetto di dipendenze, ma quello dei vincoli. Esistono tre tipi di vincoli: collocazione, posizione e ordinamento.

• Un vincolo di colocation impone se due risorse devono essere in esecuzione nello stesso nodo o meno.
• Un vincolo di posizione indica al cluster Pacemaker dove una risorsa può essere eseguita o meno.
• Un vincolo di ordinamento indica al cluster Pacemaker l'ordine in cui le risorse devono essere avviate.

Quorum, agenti di isolamento e STONITH

Il concetto di quorum in Pacemaker è simile a WSFC. Lo scopo generale del meccanismo di quorum di un cluster è garantire che il cluster rimanga operativo. Sia il cluster WSFC che i componenti aggiuntivi a disponibilità elevata per le distribuzioni Linux presentano il concetto di voto, in cui ogni nodo viene conteggiato ai fini del quorum. È necessario che la maggior parte dei voti sia positiva. In caso contrario, nel peggiore degli scenari, il cluster verrà arrestato.

A differenza di un WSFC, non c'è una risorsa witness da usare con il quorum. Analogamente a un cluster WSFC, l'obiettivo è quello di mantenere dispari il numero dei votanti. Nella configurazione del quorum, le considerazioni per i gruppi di disponibilità (AG) sono diverse da quelle per le istanze di cluster di failover (FCI).

I cluster WSFC monitorano lo stato dei nodi partecipanti e li gestiscono quando si verifica un problema. Le versioni più recenti dei cluster WSFC offrono funzionalità di questo tipo, ad esempio la messa in quarantena di un nodo non funzionante o non disponibile (il nodo non è attivo, la comunicazione di rete è inattiva e così via). Nel contesto di Linux, questo tipo di funzionalità viene fornito da un fence agent. Il concetto viene talvolta definito recinzione. Tuttavia, questi agenti di isolamento sono specifici della distribuzione e spesso vengono messi a disposizione dai fornitori di hardware e da alcuni fornitori di software, ad esempio quelli che forniscono gli hypervisor. Ad esempio, VMware fornisce un agente di isolamento che può essere usato per le macchine virtuali Linux virtualizzate con vSphere.

Il quorum e il fencing sono collegati a un altro concetto noto come STONITH, acronimo di "Shoot The Other Node In The Head". STONITH deve avere un cluster Pacemaker supportato in tutte le distribuzioni Linux. Per altre informazioni, vedere Fencing in a Red Hat High Availability Cluster (RHEL) (Isolamento in un cluster a disponibilità elevata Red Hat - RHEL).

corosync.conf

Il file corosync.conf contiene la configurazione del cluster. Si trova in /etc/corosync. Nel corso delle normali operazioni quotidiane, se il cluster è configurato correttamente, non dovrebbe essere mai necessario modificare questo file.

Percorso del log cluster

I percorsi dei log per i cluster Pacemaker variano a seconda della distribuzione.

• RHEL e SLES: /var/log/cluster/corosync.log
• Ubuntu: /var/log/corosync/corosync.log

Per cambiare il percorso di registrazione predefinito, modificare corosync.conf.

Pianificare cluster Pacemaker per SQL Server

Questa sezione illustra i punti di pianificazione importanti per un cluster Pacemaker.

Virtualizzare cluster Pacemaker basati su Linux per SQL Server

L'uso di macchine virtuali per distribuire distribuzioni di SQL Server basate su Linux per gruppi di disponibilità e istanze del cluster di failover è coperto dalle stesse regole delle controparti basate su Windows. È disponibile un set di regole di base per supportare le distribuzioni di SQL Server virtualizzate fornite da Microsoft nei criteri Support per i prodotti Microsoft SQL Server in esecuzione in un ambiente di virtualizzazione hardware. Nel caso di hypervisor diversi, come Hyper-V di Microsoft e ESXi di VMware, potrebbero esserci variazioni differenti a causa delle differenze specifiche delle piattaforme stesse.

Quando si tratta di gruppi di disponibilità (AG) e di istanze del cluster di failover (FCI) soggetti a virtualizzazione, accertarsi che l'anti-affinità per i nodi di un determinato cluster Pacemaker sia impostata. Quando configurate per l'alta disponibilità in una configurazione del gruppo di disponibilità o dell'istanza del cluster di failover, le macchine virtuali che ospitano SQL Server non devono mai essere in esecuzione sullo stesso host hypervisor. Ad esempio, se viene implementato un FCI a due nodi, dovranno essere presenti almeno tre host di hypervisor, in modo che ci sia uno spazio disponibile per trasferire una delle VM che ospitano un nodo in caso di guasto dell'host, specialmente se si utilizzano funzionalità come Live Migration o vMotion.

Per la documentazione di Hyper-V, vedere Using Guest Clustering for High Availability

Rete

Diversamente da un cluster WSFC, Pacemaker non richiede un nome dedicato o nemmeno un indirizzo IP dedicato per il cluster Pacemaker in sé. I gruppi di disponibilità (AG) e le istanze del cluster di failover (FCI) richiedono un indirizzo IP (per ulteriori informazioni, vedere la documentazione specifica), ma non i nomi, poiché non è disponibile una risorsa di nome di rete. SLES consente la configurazione di un indirizzo IP per finalità amministrative, ma non è obbligatorio, come illustrato in Creare il cluster Pacemaker.

Analogamente a un cluster WSFC, Pacemaker preferisce una rete ridondante, ovvero schede di rete distinte (NIC per schede di interfaccia di rete o pNIC per schede di interfaccia di rete fisica) con indirizzi IP distinti. Per quanto riguarda la configurazione del cluster, ogni indirizzo IP avrà il cosiddetto anello specifico. Tuttavia, come avviene attualmente per i cluster WSFC, molte implementazioni sono virtualizzate o si trovano nel cloud pubblico, dove al server viene presentata una singola scheda di interfaccia di rete virtualizzata. Se tutte le schede di interfaccia di rete fisica e le schede di interfaccia di rete virtualizzata sono connesse allo stesso commutatore fisico o virtuale, non esiste una vera ridondanza a livello di rete, quindi la configurazione di più schede di interfaccia di rete è un po' illusoria per la macchina virtuale. La ridondanza di rete è in genere integrata nell'hypervisor per le distribuzioni virtualizzate ed è sicuramente integrata nel cloud pubblico.

Una differenza tra le schede di interfaccia di rete multiple e Pacemaker rispetto a un cluster WSFC è che Pacemaker consente più indirizzi IP nella stessa subnet, mentre un cluster WSFC non lo fa. Per altre informazioni sulle subnet multiple e sui cluster Linux, vedere l'articolo Configurazione di gruppi di disponibilità Always On con subnet multiple e istanze del cluster di failover.

Quorum e STONITH

La configurazione e i requisiti del quorum sono correlati alle distribuzioni specifiche del gruppo di disponibilità o dell'istanza del cluster di failover di SQL Server.

STONITH è necessario per un cluster Pacemaker supportato. Usare la documentazione della distribuzione per configurare STONITH. Per un esempio per SLES, vedere Storage-based Fencing (Isolamento basato sulla risorsa di archiviazione). Per le soluzioni basate su ESXI è disponibile anche un agente STONITH per VMware vCenter. Per altre informazioni, vedere Stonith Plugin Agent for VMware VM VCenter SOAP Fencing (Unofficial) (Agente di plug-in di Stonith per l'isolamento VCenter SOAP delle macchina virtuali VMware - Non ufficiale).

Interoperabilità

Questa sezione illustra come un cluster basato su Linux può interagire con un cluster WSFC o con altre distribuzioni di Linux.

WSFC

Al momento, non esiste un modo diretto per far funzionare insieme un cluster WSFC e un cluster Pacemaker. Non è quindi possibile creare un AG (gruppo di disponibilità) o un FCI (istanza del cluster di failover) che funzioni sia in un cluster WSFC che in Pacemaker. Esistono due soluzioni di interoperabilità, entrambe progettate per AG. L'unico modo in cui un FCI può partecipare a una configurazione multipiattaforma è se partecipa come istanza in uno di questi due scenari:

• Un gruppo di disponibilità con un tipo di cluster None. Per altre informazioni, vedere la documentazione dei gruppi di disponibilità Windows .
• Un gruppo di disponibilità distribuito è un tipo particolare di gruppo di disponibilità che permette di configurare due diversi gruppi di disponibilità come un unico gruppo di disponibilità autonomo. Per altre informazioni sui gruppi di disponibilità distribuiti, vedere la documentazione Gruppi di disponibilità distribuiti.

Altre distribuzioni Linux

In Linux tutti i nodi di un cluster Pacemaker devono trovarsi nella stessa distribuzione. Questo significa, ad esempio, che un nodo RHEL non può far parte di un cluster Pacemaker con un nodo SLES. Il motivo principale di questa condizione è stato spiegato in precedenza: le distribuzioni potrebbero avere versioni e funzionalità diverse, quindi potrebbero verificarsi dei problemi. La combinazione di distribuzioni equivale alla combinazione di cluster WSFC e Linux: usare None o i gruppi di disponibilità distribuiti.

Contenuto correlato

• Distribuire un cluster Pacemaker per SQL Server on Linux
• Configurare un cluster Pacemaker per gruppi di disponibilità di SQL Server