Pacemaker e' un gestore di risorse cluster Open Source.
L'implementazione di un cluster richiede un intero stack
di componenti, di cui Pacemaker e' quello fondamentale.
In questo documento vengono riportati elementi relativi
alla configurazione ed all'amministrazione di un cluster
Linux basato sulle piu' recenti e diffuse tecnologie di cluster
Open Source tra cui:
Pacemaker,
Corosync,
LCMC, ...
Un documento introduttivo sulla tecnologia cluster e'
Unix Clusters.
Mentre indicazioni sulle versioni dei diversi prodotti sono riportate in
questo documento.
La prima parte del documento e' introduttiva e semplificata ma riporta solo gli elementi essenziali mentre la seconda parte del documento e' un poco piu' complessa ma analizza i diversi aspetti in modo piu' compiuto. Il documento e' organizzato nei seguenti capitoli: Introduzione, Installazione, Comandi Cluster, Gestione risorse, LCMC, Architettura, Configurazione servizi, Documentazione, ...
Poiche' nel tempo vi e' stata una notevole evoluzione dal punto di vista di funzionalita' e di modalita' di gestione restringeremo la presentazione di questa pagina alle versioni piu' affidabili ed alle configurazioni piu' utilizzate (a nostro insindacabile giudizio ;-) ovvero Pacemaker 1.1, Corosync 2.4 gestiti con CLI pcs o LCMC 1.7 il tutto su sistema operativo Linux CentOS 7.2.
Un cluster Pacemaker e' composto da una serie di Host
su cui vengono ospitati i servizi applicativi.
Gli Host ed i servizi (Service) possono essere ospitati su uno o piu'
server fisici con configurazioni differenti: Active/Passive, Active/Active, N+1, ...
Il cluster fornisce funzioni di HA (High Availability: Alta affidabilita'):
se un nodo fisico va in errore i servizi vengono migrati (failover) attivi.
Il cluster permette anche un bilanciamento ottimale tra i servizi applicativi
consentendo di migrare le risorse tra i nodi (switchover).
In molte configurazioni di cluster e' anche presente uno Storage condiviso tra tutti i nodi.
Un servizio che viene integrato nel cluster per fornirne l'alta affidabilita'
viene chiamato Resource.
Esistono decine di Agent configurabili per le diverse tipologie
di servizi disponibili (eg. Indirizzi IP, File System, Web Server, DB Server).
Una configurazione cluster e' composta dalla descrizione di tutti i servizi
e delle loro relazioni.
La configurazione dei servizi con Pacemaker puo' essere effettuata in differenti modi:
I nodi del cluster sono in dialogo tra loro mediante una conessione di controllo gestita da Corosync detta Heartbeat. Nel caso in cui un sistema cada, gli altri sistemi ne prendono in carico i servizi effettuando il failover.
Gli elementi riportati sono sufficienti come introduzione... una descrizione piu' approfondita del'architettura si trova nel relativo capitolo.
L'installazione di Pacemaker e' semplice. Naturalmente l'installazione deve essere effettuata su tutti i nodi che compongono il cluster che debbono essere connessi tra loro e poter dialogare in SSH. Utilizzando il comando yum tutti i software prerequisiti (eg. Corosync) vengono scaricati ed aggiornati:
yum install -y pacemaker pcs resource-agents systemctl start pcsd.service systemctl enable pcsd.service
Una volta installato il software si puo' configurare il cluster e fare partire i servizi:
passwd hacluster ... pcs cluster auth nodo1 nodo2 nodo3 pcs cluster setup --name mycluster nodo1 nodo2 nodo3 pcs cluster start --all
A questo punto il cluster e' attivo su tutti i nodi e puo' fornire servizi in alta affidabilita'.
Una volta attivo il cluster e' possibile controllarne lo stato e creare le prime risorse. Il modo piu' semplice e diretto per farlo e' utilizzare comandi in linea:
pcs status
Sono disponibili decine di differenti risorse che possono essere integrate con Pacemaker. Una delle piu' comuni e' un indirizzo IP da assegnare ad un servizio applicativo; per creare una risorsa IP:
pcs resource create MyClusterIP ocf:heartbeat:IPaddr2 \
ip=192.168.0.100 cidr_netmask=32 op monitor interval=30s
Il comando riportato sopra crea una risorsa ClusterIP che mantiene un IP address attivo sul cluster.
Come visto nei due esempi precedenti il comando utilizzato e' pcs (Pacemaker/Corosync configuration system) che consente di gestire ogni aspetto del cluster. Ecco la sintassi:
Vediamo ora i piu' comuni comandi per la gestione delle risorse del cluster. Utilizziamo la risorsa MyReource attiva su nodo1 ed i comandi CRM (Cluster Resource Management):
L'elenco e' stato estratto dalla Stele di rosetta dei comandi cluster...
L'LCMC (Linux Cluster Management Console) fornisce un'interfaccia grafica semplice e consistente per effettuare la configurazione del cluster e per quindi per la sua gestione.
Dal punto di vista tecnico si tratta di un'applicazione Java, che puo' quindi essere eseguita su qualsiasi architettura, che si collega via SSH agli Host che deve gestire. L'installazione e' quindi banale (basta copiare un file) e puo' essere eseguita su un qualsiasi client: tipicamente non viene installata sui nodi del cluster ma sui PC degli amministratori. Un semplice wizard guida nella configurazione dei parametri del cluster:
Una volta definiti gli estremi per la connessione sono visualizzati graficamente gli Host ed i servizi presenti. La gestione dei componenti e' molto semplice: con il tasto destro del mouse si apre un menu a tendina con le opzioni disponibili per ogni oggetto. I servizi che sono legati tra loro da legami che vengono evidenziati con frecce che indicano l'ordine di attivazione:
L'utilizzo dell'interfaccia grafica o dei comandi in linea non presenta differenze dal punto di vista tecnico. La scelta e' quindi guidata dal task specifico che deve essere eseguito o dalle preferenze dell'amministratore.
Un'ultima importante nota: lcmc consente di fare ogni cosa sul cluster, anche bloccare servizi di produzione o l'intero cluster! Meglio utilizzarlo in modalita' read-only e passare alle altre modalita' solo quando necessario.
In questo capitolo entreremo in maggior dettaglio nell'architettura di Pacemaker per compredere le configurazioni piu' complesse.
L'architettura Pacemaker prevede un cluster costituito da una
serie di sistemi connessi tra loro;
spesso sono presenti uno o piu' sistemi di storage condiviso
ovvero replicato (eg. DRDB).
I sistemi debbono essere connessi tra loro anche su una rete privata.
Tipicamente si utilizzano semplici ed affidabili cavi incrociati o, se i nodi
sono piu' di due, un hub dedicato.
Tale connessione, detta Heartbeat, deve essere ridondata per
evitare SPoF (Single Point of Failure).
Un cluster Pacemaker e' composto da una serie di Host su cui vengono ospitati i servizi applicativi. Gli Host ed i servizi (Service) possono essere ospitati su uno o piu' server fisici con configurazioni differenti: Active/Passive, Active/Active, N+1, ... Pacemaker consente tutte le tipologie di configurazioni di cluster per l'alta affidabilita' e/o il bilanciamento dei servizi.
Gli Host fisici vengono configurati come Cluster Node.
Nel caso in cui un sistema cada, gli altri sistemi ne
prendono in carico i servizi effettuando il failover.
I nodi sono in dialogo tra loro mediante una conessione
di controllo detta Heartbeat e gestita da Corosync
(ma l'architettura e' aperta e sono anche supportati Hearbeat e CMAN).
Pacemaker e' composto da 5 componenti chiave:
Cluster Information Base (CIB),
Cluster Resource Management daemon (CRMd),
Local Resource Management daemon (LRMd),
Policy Engine (PEngine or PE),
Fencing daemon (STONITHd)
e dal processo ATTRd che fa da intermediario:
Per disporre di una configurazione affidabile i nodi debbono
poter comunicare tra loro in modo ridondato.
Di questo si occupa l'RRP di Corosync (Redundant Ring Protocol).
L'RRP utilizza due porte UDP per l'invio dei pacchetti (default: receive 5405, send 5404)
ed e' consigliato configurare un secondo anello in ridondanza.
In una configurazione di produzione e' opportuno anche utilizzare il
bonding delle interfacce di rete.
In caso di perdita di connessione tra uno o piu' nodi e'
importante non si verifichi la condizione di split-brain
in cui due gruppi di nodi fisici cercano di attivare le stesse
risorse.
Per evitare questo Corosync utilizza il concetto di Quorum:
solo chi ha la maggioranza assoluta dei voti puo' attivare i servizi.
Nel caso particolare di un cluster con due nodi
[NdE caso molto comune in realta'] va impostato il parametro
two_node: 1 per consentire l'elezione di un nodo a
coordinatore e fornire cosi' l'alta affidabilita'
anche in questa situazione.
Un servizio che viene integrato nel cluster per fornirne l'alta affidabilita'
viene chiamato Resource.
Le risorse hanno una serie di proprieta' che ne definiscono
le caratteristiche tecniche e la gestione.
Le risorse piu' semplici sono chiamate primitive ed hanno un
Resource Agent che ne controlla il funzionamento.
Pacemaker supporta diverse classi di agent (resource standards):
OCF (Open Cluster Framework),
LSB (Linux Standard Base),
Upstart,
Systemd,
Service,
Stonith (utilizzato per il fence, e' l'acronimo di Shoot The Other Node In The Head),
Nagios Plugins (utilizzati per monitorare servizi remoti).
Gli script vengono forniti da diversi resource providers:
heartbeat,
linbit,
openstack,
pacemaker.
OCF e' lo standard piu' completo e flessibile con cui sono realizzate
decine di Agenti. OCF utilizza variabili di ambiente OCF_RESKEY_*
ed ogni agente implementa almeno le azioni di start, stop, monitor e meta-data.
L'exit code e' 0 in caso di corretta esecuzione, 7 se la risorsa
e' in stato di stop, gli altri codici di uscita indicano un errore.
Gli agenti ocf:heartbeat disponibili con un'installazione di default sono oltre
quaranta e coprono tutte le aree di servizi:
file system (Filesystem, LVM, exportfs, nfsserver, iSCSITarget),
networking (IPaddr2, Route),
web server (apache, nginx, tomcat, Squid),
database (mysql, galera, pgsql, oracle, oralsnr, redis, db2),
...
LSB e' la modalita' con cui vengono scritti gli script di init Linux
(ovvero quelli contenuti in /etc/init.d).
Lo standard LSB prevede che lo script implementi
almeno le azioni start, stop, restart, force-reload e status.
L'exit code e' 0 in caso di corretta esecuzione mentre
l'exit code 3 alla richiesta di status indica che il servizio non e' attivo.
Gli agenti disponibili con un'installazione standard
sono parecchi (circa 300) e possono essere ulteriormente arricchiti
con l'installazione o la realizzazione di script specifici.
Le risorse possono essere legate tra loro da Constraint
che definiscono su quali nodi possono essere eseguite (location),
se debbono essere eseguite su nodi che ospitano o meno altre risorse (colocation)
e qual e' l'eventuale ordine di attivazione (order).
Sono inoltre supportati i clone per gestire risorse che debbono essere attive su piu'
nodi ed i multi-state per risorse con stati differenti per nodo (eg. primary/slave).
Un'esigenza molto comune e' quella di legare tra
loro una serie di risorse da attivare sullo stesso nodo in un certo
ordine e da disattvare in ordine inverso (eg. IP, FS, Web Server).
Questo si configura facilmente definendo un Resource Group
composto da risorse primitive.
Oltre che ad uno storage condiviso (tipicamento ospitato su una SAN ed connesso via schede in fibra o via iSCSI) sono supportati sia il DRDB che il GFS2.
La configurazione del cluster Pacemaker e' costituita dall'insieme di tutte le risorse, delle loro caratteristiche e constraints. La configurazione e' mantenuta in modo sinconizzato tra i nodi nel file CIB (Pacemaker's Cluster Information Base) che non puo' essere modificato manualmente. Nel caso sia necessaria una revisione massiva della configurazione i comandi corretti sono:
Riassumendo il tutto in una sola frase...
Pacemaker gestisce lo stato di tutte le risorse presenti nel cluster
richiamando gli specifici agenti e coordina il comportamento dei
nodi con Corosync:
In una configurazione reale i servizi applicativi sono composti da un'insieme di risorse che debbono essere tra loro coordinate. Un web server ad esempio utilizzera' un file system e avra' un IP per il VIP. Dopo aver creato le singole risorse e' necessario configurarne le relazioni come nei seguenti esempi:
Ecco la rappresentazione grafica su LCMC di un cluster completo costituito da piu' servizi:
E' opportuno documentare la configurazione del cluster e dei relativi servizi e mantenere aggiornata tale documentazione. Per la rappresentazione dell'architettura puo' essere utile uno schema come il seguente [NdE disegnato con DIA]:
Nello schema sono riportate le interfacce di rete, gli indirizzi fisici, gli indirizzi dei servizi, le basi dati, le connessioni di heartbeat, le applicazioni ospitate, ... E' quindi orientato ai tecnici.
Piu' vicino alla gestione dei servizi e' invece uno schema come:
In questo caso sono evidenziati i servizi applicativi, le dimensioni dei volumi, i software utilizzati, i preferred server, ...
Un ultimo importante documento e' quello relativo alla certificazione del cluster.
Tali documenti fanno spesso parte dei piani di continuita' operativa (Business Continuity)...
Titolo: Pacemaker: Il Cluster Linux Open Source
Livello: Esperto
Data:
15 Agosto 2016
Versione: 1.0.0 - 15 Agosto 2016
Autore: mail [AT] meo.bogliolo.name