Share via

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

  • Articolo

Si applica a:SQL Server - Linux

A partire da SQL Server 2017 (14.x), SQL Server è supportato sia in Linux che in Windows. Come nelle distribuzioni di SQL Server basate su Windows, i database e le istanze di SQL Server devono garantire la disponibilità elevata anche in Linux. Questo articolo illustra le informazioni di base per comprendere Pacemaker con Corosync e come pianificarlo e implementarlo per le configurazioni di 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:

  • Pacemaker. 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. Consente, ad esempio, 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.

Nota

Lo stack di cluster viene comunemente definito Pacemaker in ambito Linux.

Questa soluzione è simile alla distribuzione di configurazioni in cluster con Windows per certi aspetti, ma per altri è molto diversa. In Windows il formato di disponibilità del clustering, denominato WSFC (Windows Server Failover Cluster), è integrato nel sistema operativo e la funzionalità che consente la creazione di un cluster WSFC, il clustering di failover, è disabilitata per impostazione predefinita. In Windows i gruppi di disponibilità e le istanze del cluster di failover sono basati su un cluster WSFC e sono strettamente integrati a causa della DLL della risorsa specifica fornita da SQL Server. Questa soluzione a stretto regime di controllo, in generale, è possibile perché tutti gli elementi provengono da un unico fornitore.

Diagram of high availability basics.

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 del clustering è open source, quindi anche se viene fornito con le distribuzioni, non è così strettamente integrato come un cluster WSFC in Windows. È proprio per questo motivo che Microsoft fornisce mssql-server-ha, in modo che SQL Server e lo stack di Pacemaker possano offrire un'esperienza simile, ma non identica, a quella di Windows per i gruppi di disponibilità e le istanze del cluster di failover.

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

Ubuntu non ha una guida per la disponibilità.

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 in altri nodi, ma Corosync è obbligatorio per SQL Server, quindi il numero massimo di nodi che un cluster può avere per qualsiasi configurazione basata su SQL Server è 16. Questo è il limite di Pacemaker ed è completamente diverso dalle limitazioni massime per i gruppi di disponibilità e le istanze del cluster di failover imposte 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 che risorse di gruppo di disponibilità. Qualcosa di simile accade in un cluster WSFC, in cui è presente una risorsa di SQL Server per una risorsa di istanza del cluster di failover o una risorsa di gruppo di disponibilità quando si configura un gruppo di disponibilità, ma esistono alcune differenze dovute al modo in cui SQL Server si integra con Pacemaker.

Pacemaker ha risorse standard e clone. 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 del cluster di failover usano una risorsa standard, perché in un determinato momento un solo nodo può ospitare un'istanza del cluster di failover.

Nota

Comunicazione senza distorsione

Questo articolo contiene riferimenti al termine slave, un termine che Microsoft considera offensivo se usato in questo contesto. Il termine viene visualizzato in questo articolo perché è attualmente incluso nel software. Quando il termine verrà rimosso dal software, verrà rimosso dall'articolo.

Quando si crea un gruppo di disponibilità, è necessario un tipo specifico di risorsa clone denominata risorsa a più stati. 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 e quindi non possono essere usati per i gruppi di disponibilità. Anche se un gruppo di risorse può essere usato per le istanze del cluster di failover, non è in genere una configurazione consigliata.

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 a cluster WSFC quale risorsa deve essere prima online.

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

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

Nota

I vincoli di condivisione del percorso non sono necessari per le risorse in un gruppo di risorse, perché tali risorse sono considerate una singola unità.

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 cluster WSFC, non esistono risorse di controllo 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à sono diverse da quelle per le istanze del cluster di failover.

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). In ambito Linux questo tipo di funzionalità viene fornito da un agente di isolamento. Il concetto viene talvolta definito isolamento. 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 l'isolamento sono collegati a un altro concetto, quello di STONITH (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. È incluso in /etc/corosync. Nel corso delle normali operazioni quotidiane, se il cluster è configurato correttamente, non dovrebbe essere mai necessario modificare questo file.

Percorso del registro 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 i cluster Pacemaker per SQL Server

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

Virtualizzare i cluster Pacemaker basati su Linux per SQL Server

L'uso di macchine virtuali per eseguire le distribuzioni di SQL Server basate su Linux per i gruppi di disponibilità e le istanze del cluster di failover è soggetto alle stesse regole delle controparti basate su Windows. Microsoft mette a disposizione un set di regole di base per supportare le distribuzioni di SQL Server virtualizzate in Criteri di supporto per i prodotti Microsoft SQL Server eseguiti in un ambiente hardware virtuale. Potrebbero esserci delle differenze a seconda dell'hypervisor, ad esempio Hyper-V di Microsoft ed ESXi di VMware, dovute alle caratteristiche specifiche delle piattaforme.

Quando si tratta di gruppi di disponibilità e di istanze del cluster di failover soggetti a virtualizzazione, verificare che l'anti-affinità per i nodi di un determinato cluster Pacemaker sia impostata. Se configurate per la disponibilità elevata in una configurazione di gruppo di disponibilità o di istanza del cluster di failover, le macchine virtuali che ospitano SQL Server non devono mai essere eseguite nello stesso host dell'hypervisor. Se ad esempio viene distribuita un'istanza del cluster di failover a due nodi, dovranno essere presenti almeno tre host di hypervisor, in modo che sia disponibile uno spazio in cui trasferire una delle macchine virtuali che ospitano un nodo in caso di errore dell'host, soprattutto se si usano funzionalità come Live Migration o vMotion.

Per informazioni più specifiche, vedere:

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à e le istanze del cluster di failover richiedono gli indirizzi IP (per altre informazioni, vedere la documentazione specifica), ma non i nomi, perché non sono disponibili risorse nome della 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 la rete ridondante, ovvero schede di rete distinte (schede di interfaccia di rete o schede di interfaccia di rete fisica per l'ambiente fisico) con indirizzi IP singoli. 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 con le schede di interfaccia di rete multiple e Pacemaker rispetto a un cluster WSFC è che Pacemaker consente più indirizzi IP nella stessa subnet, un cluster WSFC invece no. Per altre informazioni sulle subnet multiple e sui cluster Linux, vedere l'articolo Configurare più subnet.

Quorum e STONITH

I requisiti e la configurazione 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

Attualmente, non è possibile interagire direttamente con un cluster WSFC e Pacemaker. Non è quindi possibile creare un gruppo di disponibilità o un'istanza del cluster di failover che funzioni in un cluster WSFC e in Pacemaker. Esistono tuttavia due soluzioni di interoperabilità, entrambe progettate per i gruppi di disponibilità. Un'istanza del cluster di failover può partecipare a una configurazione multipiattaforma solo 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 sui gruppi di disponibilità di Windows.
  • Un gruppo di disponibilità distribuito, che è un particolare tipo di gruppo di disponibilità che consente di configurare due diversi gruppi di disponibilità come gruppo di disponibilità proprio. 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