Orientarsi nell’attuale panorama dei cluster sotto Linux potrebbe essere, particolarmente per un neofita, molto complicato. L’insieme di progetti, nomi e versioni è certamente variegato.
Ottenere alta affidabilità di servizi sotto Linux è possibile in svariati modi: si può optare per una soluzione completamente commerciale come Veritas Cluster (http://www.symantec.com/it/it/business/cluster-server), si può considerare un prodotto Opensource sponsorizzato da un’azienda commerciale come la RedHat Cluster Suite (http://www.redhat.com/cluster_suite/), prodotta e manutenuta come dice il nome stesso da RedHat (ma disponibile per quasi tutte le distribuzioni) oppure utilizzare Hertbeat (http://www.linux-ha.org/) prodotto e manutenuto dalla comunità del progetto Linux-HA.
Questo primo articolo cerca di analizzare l’evoluzione del progetto Heartbeat, facendo luce su quali siano oggi i software da utilizzare per creare un’architettura ad alta affidabilità attraverso i software OpenSource disponibili: Hertbeat stesso, Pacemaker sino ad arrivare alla Standard Based Cluster Framework con OpenAIS e Corosync.

In principio era Heartbeat

Il progetto Heartbeat nasce nel 1999 con l’obiettivo di creare e diffondere un software Opensource in grado di garantire l’alta affidabilità nei servizi erogati da sistemi Linux.
Heartbeat è di fatto un software per creare cluster di servizi. Un cluster di servizi è composto da un insieme di macchine, definite nodi, sulle quali vengono distribuiti programmi definiti risorse. Se un nodo per qualsiasi ragione smette di funzionare, al suo posto ne subentra un altro in grado di garantire il funzionamento delle stesse risorse, con lo scopo di recare il minor disservizio possibile all’utente finale.
Questa tipologia di funzionamento è definita active-passive. Una risorsa è attiva su un nodo active mentre gli altri nodi passive sono in attesa, pronti ad erogare la risorsa in caso di malfunzionamenti relativi al nodo attivo.

Prima della versione 2.0, Heartbeat supportava cluster composti unicamente da due macchine ed aveva strumenti integrati in grado di svolgere operazioni sulle risorse stesse in maniera limitata. Non era possibile definire priorità nell’avvio delle risorse o dipendenze di una risorsa rispetto ad un’altra. Relativamente alla singola risorsa Heartbeat si preoccupava solamente dell’avvio, del termine e del posizionamento della stessa all’interno di un nodo specifico.
Il modo in cui il cluster gestiva una risorsa era definito dall’RA, il Resource Agent.
Un Resource Agent era uno script a cui il sistema faceva riferimento per avviare, fermare e controllare lo stato delle risorse. I Resource Agent di Heartbeat 1 erano contenuti all’interno delle directory /etc/ha.d/resource.d e /etc/init.d. Questi altro non erano che script di avvio dei demoni che supportavano operazioni di start, stop e status. Potenzialmente quindi QUALSIASI servizio poteva essere posto sotto cluster (purché supportasse le tre operazioni citate), sebbene il controllo da parte del sistema di questi servizi fosse essenzialmente nullo.

I limiti insiti in un’architettura simile sono subito evidenti. Basti pensare ad uno scenario in cui Heartbeat eroga il database MySQL. Il cluster si preoccupa di avviare il servizio sul nodo attivo. Se però MySQL per qualsiasi ragione (carico di utenti eccessivo, saturazione del buffer, mancanza di spazio o banalmente uno stop manuale) smette di funzionare, Heartbeat non ovvia in alcuna maniera all’inconveniente e solo un eventuale crash del nodo attivo provoca il cosiddetto switch della risorsa, lo spostamento cioè della stessa sul nodo rimanente, che a sua volta diventa attivo.
La possibilità di effettuare controlli sullo stato di salute delle risorse e di agire autonomamente in funzione di disservizi nelle versioni precedenti alla 2.0 di Heartbeat poteva essere abilitata mediante l’utilizzo di programmi esterni (ad esempio keepalived), ma non era parte integrante del cluster.

L’avvento del CRM

Un gestore delle risorse è sempre esistito all’interno del software Heartbeat. In origine infatti le informazioni relative al posizionamento della risorse ed alla struttura del cluster venivano lette in fase di avvio da due file di testo:

• /etc/ha.d/ha.cf contenente la definizione della struttura del cluster (numero ed indirizzo dei nodi, tempistiche di controllo, politica relativa ai log);
• /etc/ha.d/haresources contenente la definizione delle risorse erogate dal cluster;

Questi file (identici su entrambi i nodi) contenevano informazioni che così come erano scritte, tali rimanevano sino al termine dell’esecuzione del programma Heartbeat.
La configurazione era quindi statica ed una variazione, per essere assimilata dal sistema, comportava il cosiddetto reload del servizio Heartbeat, una rilettura totale dei file di configurazione.

Questo limite unito a quelli descritti nel paragrafo precedente sono stati al centro dell’evoluzione del progetto Heartbeat e sono culminati nel CRM, il Cluster Resource Manager.
Il CRM introdotto con Heartbeat 2 evolve radicalmente la funzione del gestore delle risorse attraverso una gestione dinamica delle stesse, un totale controllo sui servizi erogati ed il supporto ad un numero di nodi maggiore di due.
Se abilitato (esplicitamente, all’interno della configurazione di Heartbeat) il CRM consente infatti di gestire l’avvio e la destinazione delle risorse, raggrupparle, controllarne lo stato di salute e definire priorità di esecuzione di una risorsa rispetto ad un’altra. Se non abilitato Heartbeat continua a funzionare nella maniera classica descritta in precedenza.
Utilizzando il CRM, tutte le informazioni relative alla configurazione dei nodi, delle risorse ed dello stato generale del cluster sono mantenute all’interno di un unico file XML denominato CIB, Cluster Information Base.
I file che dalla versione 2 di Heartbeat permettono di definire il cluster sono quindi due:

• /etc/ha.d/ha.cf contenente la definizione della struttura del cluster (che dichiara anche l’opzione crm=on, ed indica al sistema di utilizzare il CRM);
• /var/lib/heartbeat/crm/cib.xml contenente tutte le informazioni relative alle risorse ed allo stato attuale del cluster;

I file illustrati sono identici in tutti i nodi. E va sottolineato come le operazioni manuali dirette sul CIB siano sconsigliate, in quanto esistono tool appositi (primo fra tutti il comando crm, che verrà illustrato nei successivi articoli di questa serie) che permettono di interagire con esso.
L’altra grande novità di Heartbeat 2 risiede nel modo in cui le risorse vengono gestite. Infatti il metodo attraverso Resource Agent classici (sebbene supportato) viene sconsigliato in funzione di Resource Agent di tipo OCF, Open Clustering Framework. Questi Resource Agent oltre a possedere le medesime proprietà di quelli classici (quindi start, stop e status) supportano anche ulteriori opzioni che consentono di definire in maniera approfondita il comportamento della risorsa nelle varie situazioni, per aumentare il più possibile il controllo del sistema.
A differenza degli RA classici, gli RA di tipo OCF risiedono nella cartella /usr/lib/ocf/resource.d/.
Maggiori dettagli sui Resoruce Agent di tipo OCF verranno introdotti nei successivi articoli e sono consultabili all’indirizzo http://www.linux-ha.org/HeartbeatResourceAgent.

L’evoluzione della specie: Pacemaker

La necessità di creare un CRM sempre più evoluto che potesse occuparsi a trecentosessanta gradi delle risorse, rendendo più flessibile la gestione delle stesse ed ovviando ai limiti della componente integrata è stata evidenziata a partire dal 2004, anno in cui al progetto Heartbeat è stata affiancato lo sviluppo di un CRM indipendente.
Il nome di questo progetto è Pacemaker.
Pacemaker rappresenta un progetto di CRM a sé stante, indipendente dalla piattaforma cluster di Heartbeat, il cui obiettivo è quello di proporre un’interfaccia comune alla gestione delle risorse del cluster.
Le figure riportate di seguito (ottenute dal sito ufficiale http://www.clusterlabs.org) riassumono le diverse tipologie di funzionamento di Pacemaker, partendo dalla classica Active-Passive:

passando dal supporto di più nodi:

per arrivare al supporto di più nodi collegati al medesimo storage:

Ciascuna di queste tipologie di cluster rappresenta i diversi livelli di complessità ottenibili mediante l’impiego di Pacemaker.
In questo primo articolo le informazioni illustrate vanno prese con beneficio di inventario, in quanto temi come DRBD o Load Balancing non sono ancora stati trattati. Ciò che però è importante capire sono i tre livelli nei quali il cluster viene diviso:

• Il livello hardware: rappresentato dai nodi fisici;
• Il cluster stack: rappresentato dall’unione del CRM con il sistema di gestione della comunicazione dei nodi;
• Il livello servizi: rappresentato dall’insieme dei servizi del sistema che verranno fruiti;

Balzerà all’occhio il fatto che all’interno del cluster stack, il sistema di gestione della comunicazione dei nodi è identificato come OpenAIS e non come Heartbeat. ll motivo di questo è spiegato nell’ultimo paragrafo di questo primo articolo.

OpenAIS: l’avvento dello Standard Based Cluster Framework

In tutte le immagini illustrate nel precedente paragrafo il cosiddetto cluster stack è rappresentato dall’unione di due componenti: la prima è il CRM su cui è stata fatta sufficiente chiarezza, la seconda è OpenAIS.
Secondo la definizione ufficiale, OpenAIS è uno Standard Based Cluster Framework (ossia una struttura di supporto standard per i cluster) che implementa una serie di API (Application Programming Interface, un insieme di strumenti specifici) e di politiche volte a sviluppare applicazioni che mantengono attivi i servizi nonostante potenziali malfunzionamenti.
OpenAIS rappresenta quindi il mezzo utilizzato dal sistema per garantire la comunicazione tra i nodi e permettere al CRM di interagire con gli stessi.
Questo spiega la presenza di OpenAIS nelle figure presentate: la decisione su cosa utilizzare per rendere disponibile la struttura di supporto del cluster a Pacemaker è dell’utente, poiché Heartbeat non è il solo strumento utilizzabile che supporta lo Standard Based Cluster Framework.
In origine il progetto OpenAIS oltre al Framework rendeva disponibile anche il cluster engine, il programma per la gestione dell’infrastruttura del cluster. Dal Luglio 2008 la parte relativa al cluster engine di OpenAIS è stata separata in un progetto a sé stante denominato Corosync.
Corosync è un cluster engine che si pone allo stesso livello di Heartbeat, il cui modello di configurazione verrà illustrato nei prossimi articoli.

Conclusioni

Il numero di nomi e definizioni illustrate in quest’articolo è oggettivamente enorme e giustifica la difficoltà nel mettere insieme le cose. La stesura di questo articolo ha richiesto molto più tempo del previsto proprio per via del fatto che oltre ai nomi, anche i concetti esposti sono moltissimi e parecchio complicati.
Il rischio è quindi che queste tecnologie, che sono alla portata di tutti, rimangano confinate ai margini dell’utilizzo per via di tutte le variazioni che nel tempo hanno riguardato i vari progetti.
Questo non deve succedere: le potenzialità di Pacemaker (con Hertbeat o Corosync) sono enormi e sarà evidente nel corso dei successivi articoli in cui finalmente verrà illustrato come mettere in pratica tutte queste tecnologie OpenSource.