Ecco le parti finali del seminario di miamammausalinux.org, intitolato “Evoluzione dell’alta affidabilita’ su Linux” che si è svolto nella giornata del 24 giugno 2011, presso l’hotel Holiday Inn di Rho.

La quinta e la sesta parte descrivono nel dettaglio la soluzione operativa di un sistema cluster in modalità active-active, mediante configurazioni e test funzionali.

Parte cinque di sei – Il Progetto (parte prima):

Parte sei di sei – Il Progetto (parte seconda):

Serie completa:

• Seminario “Evoluzione dell’alta affidabilita’ su Linux”: video uno e due di sei – “Introduzione” e “Cluster”
• Seminario “Evoluzione dell’alta affidabilita’ su Linux”: video tre e quattro di sei – “Heartbeat/Corosync” e “DRBD”
• Seminario “Evoluzione dell’alta affidabilita’ su Linux”: video cinque e sei di sei – “Il Progetto”

Un ringraziamento particolare a Lorenzo, per il preziosissimo supporto video che ci ha permesso di condividere l’evento con quanti non sono riusciti a partecipare.

Buona visione!

Ecco presentate le parti centrali del seminario di miamammausalinux.org, intitolato “Evoluzione dell’alta affidabilita’ su Linux” che si è svolto nella giornata del 24 giugno 2011, presso l’hotel Holiday Inn di Rho.

La terza parte introduce Heartbeat e Corosync, mentre nella quarta si approfondisce l’argomento DRBD.

Parte tre di sei – Heartbeat e Corosync:

Parte quattro di sei – DRBD:

Serie completa:

• Seminario “Evoluzione dell’alta affidabilita’ su Linux”: video uno e due di sei – “Introduzione” e “Cluster”
• Seminario “Evoluzione dell’alta affidabilita’ su Linux”: video tre e quattro di sei – “Heartbeat/Corosync” e “DRBD”
• Seminario “Evoluzione dell’alta affidabilita’ su Linux”: video cinque e sei di sei – “Il Progetto”

Un ringraziamento particolare a Lorenzo, per il preziosissimo supporto video che ci ha permesso di condividere l’evento con quanti non sono riusciti a partecipare.

Buona visione!

Nella giornata del 24 giugno 2011, presso l’hotel Holiday Inn di Rho si è svolto il primo seminario di miamammausalinux.org, intitolato “Evoluzione dell’alta affidabilita’ su Linux“.

Viste le numerose richieste ricevute e rispettando sempre la filosofia alla base del progetto miamammausalinux.org, il video del seminario viene proposto integralmente nelle sue sei parti, insieme alla documentazione fornita ai partecipanti.

Ecco le prime due parti.

Parte uno di sei – Introduzione:

Parte due di sei – Cluster:

Ed ecco il link alla documentazione:

Evoluzione dell'alta affidabilita' su Linux - Documentazione

Serie completa:

• Seminario “Evoluzione dell’alta affidabilita’ su Linux”: video uno e due di sei – “Introduzione” e “Cluster”
• Seminario “Evoluzione dell’alta affidabilita’ su Linux”: video tre e quattro di sei – “Heartbeat/Corosync” e “DRBD”
• Seminario “Evoluzione dell’alta affidabilita’ su Linux”: video cinque e sei di sei – “Il Progetto”

Un ringraziamento particolare a Lorenzo, per il preziosissimo supporto video che ci ha permesso di condividere l’evento con quanti non sono riusciti a partecipare.

Buona visione!

Evoluzione dell’alta affidabilità su Linux
Venerdì 24 Giugno 2011
9:00 – 17:30
HOLIDAY INN MILAN RHO FAIR
Via Alessandro Volta, snc
20017 Rho Milano – Italy

Evoluzione dell'alta affidabilita' su Linux

Un seminario gratuito, che nel corso di una giornata tratterà di Linux, Opensource ed alta affidabilità, affrontando nel dettaglio argomenti quali Heartbeat, Corosync e DRBD per arrivare ad implementare nel laboratorio una soluzione NFS active-active completamente operativa.

L’evento è completamente gratuito e comprende il pranzo offerto da MMUL. I posti sono limitati a venti.

Per iscriversi, compilare il seguente form:

Per qualsiasi informazione, chiarimento o problema tecnico, scrivete una mail a info@miamammausalinux.org

Finalmente, dopo mesi di interminabile attesa, gli sviluppatori del progetto hanno ufficializzato l’uscita della nuova release del sistema operativo Debian GNU/Linux: Squeeze, la release 6.0.
Indicata da molti come la migliore Debian di sempre senza proclami altisonanti è forse il caso di sottolineare come questa release del sistema operativo abbia effettivamente numerose frecce all’arco, nell’ambito Desktop e, soprattutto, nell’ambito Server.
In particolare tra i software di natura Enterprise, vanno citati:

Sistema:
* GNU Compiler Collection 4.4.5
* Linux 2.6.32

Database:
* PostgreSQL 8.4.6
* MySQL 5.1.49

Web:
* Apache 2.2.16
* OpenJDK 6b18
* Tomcat 6.0.18

Integrazione:
* Samba 3.5.6

Monitoring:
* Nagios 3.2.3

Clustering:
* Pacemaker 1.0.9
* Heartbeat 3.0.3
* Corosync 1.2.1

Virtualizzazione:
* Xen Hypervisor 4.0.1 (con il supporto per dom0 e per domU)
* Qemu-KVM 0.12.5
* libvirt 0.8.3

Come è facile intuire, questa nuova Debian risulta certamente una scelta vincente in ambiti produttivi professionali. Tutte le informazioni su come scaricare, installare ed utilizzare questa nuova Debian sono sul rinnovato sito ufficiale:

http://www.debian.org/distrib/

Un nuovo importante capitolo è stato quindi aggiunto alla storia dei sistemi operativi!

Buon lavoro a tutti

Tomcat è un Application Server: un contenitore di applicazioni sviluppate attraverso il linguaggio di programmazione Java. Tomcat viene impiegato generalmente per l’esposizione di web service e questa sua attitudine, in caso di applicazioni critiche per importanza, deve essere obbligatoriamente associata all’alta affidabilità. Esso nativamente supporta un modello di cluster, che consente a diverse istanze di condividere le sessioni, in modo da garantire la sopravvivenza del servizio: se quindi un’istanza smette di funzionare, il suo ruolo viene assunto dall’istanza sopravvissuta.
Ma chi si occupa del controllo delle istanze stesse?
Questo articolo descrive un caso di studio relativo ad un cluster nativo Tomcat le cui istanze vengono gestite da Heartbeat attraverso il Cluster Resource Manager Pacemaker.

Installazione di Java

Java è essenziale per il funzionamento di Tomcat ed è anche il primo software da configurare per ottenere il risultato prefissato in questo articolo. Per prima cosa quindi sarà necessario scaricare il pacchetto di installazione dal sito ufficiale di SUN presso il link http://www.java.com/it/download/linux_manual.jsp?locale=it&host=www.java.com.
Ottenuto il file jre-6u23-linux-i586.bin, il cui nome potrà variare a seconda della versione, questo va eseguito:

# chmod +x jre-6u23-linux-i586.bin 
# ./jre-6u23-linux-i586.bin

L’esecuzione del file creerà una cartella nominata jre1.6.0_23 che sarà possibile spostare in un path consono, ad esempio /usr/local, per il quale potrà essere creato un link simbolico:

# mv jre1.6.0_23 /usr/local
# ln -s /usr/local/jre1.6.0_23 /usr/local/java

In questo modo sarà possibile far riferimento al path /usr/local/java per il raggiungimento degli eseguibili java ed inoltre, in caso di installazioni di versioni diverse di Java, basterà cambiare il puntamento del link simbolico.

Installazione di Tomcat

L’installazione di Tomcat viene descritta in maniera generalista, indipendente quindi dalla distribuzione utilizzata.
Per prima cosa quindi è necessario scaricare l’ultima versione dell’application server Tomcat, andando sul sito ufficiale di Tomcat (http://tomcat.apache.org/download-70.cgi) oppure scaricando il pacchetto da uno dei mirror:

# wget http://it.apache.contactlab.it/tomcat/tomcat-7/v7.0.6/bin/apache-tomcat-7.0.6.tar.gz -o /tmp/apache-tomcat-7.0.6.tar.gz

una volta terminato lo scaricamento, è possibile decomprimere il pacchetto in un path di sistema, ad esempio (e per convenzione) /usr/local:

# cd /usr/local
# tar -xzvf /tmp/apache-tomcat-7.0.6.tar.gz
# ln -s apache-tomcat-7.0.6 tomcat

L’ultimo comando lanciato crea un link simbolico, in modo che in futuro per accedere alla directory di Tomcat sarà sufficiente utilizzare il percorso /usr/local/tomcat.

Installazione di Heartbeat e Pacemaker

L’installazione dell’apparato cluster offerto dal progetto Linux-ha non verrà descritta in questo articolo, in quanto ampiamente trattata nei precedenti articoli della serie, in particolare nella puntata confronto pratico tra Heartbeat classico ed Heartbeat con Pacemaker.

Configurazione di Tomcat

La configurazione prevede due fasi: la prima relativa alle credenziali di accesso, la seconda relativa alle impostazioni per il clustering.
All’interno del file /usr/local/tomcat/conf/tomcat-users.xml sono definite le utenze di accesso alle diverse componenti dell’application server, in particolare, per permettere all’utente tomcat di gestire l’installazione di nuove applicazioni attraverso l’interfaccia web disponibile, il contenuto del file dovrà essere il seguente:

<?xml version='1.0' encoding='utf-8'?>
<tomcat-users>
  <role rolename="tomcat"/>
  <role rolename="manager-gui"/>
  <user username="tomcat" password="tomcat" roles="manager,manager-gui,tomcat"/>
</tomcat-users>

Inutile dire come il campo password debba essere modificato in base alla password scelta.
L’abilitazione del cluster Tomcat, data la natura introduttiva dell’articolo, verrà fatta nella modalità più semplice, così come illustrato dalla documentazione ufficiale di Tomcat (http://tomcat.apache.org/tomcat-7.0-doc/cluster-howto.html), abilitando cioè la seguente riga all’interno del file /usr/local/tomcat/conf/server.xml:

<Cluster className="org.apache.catalina.ha.tcp.SimpleTcpCluster"/>

La configurazione preliminare dell’application server è così completa.

Configurazione di Heartbeat e Pacemaker

Appena avviato il demone Heartbeat:

# /etc/init.d/heartbeat start

è possibile definire le configurazioni preliminari del cluster:

# crm configure property stonith-enabled="false"
# crm configure property no-quorum-policy="ignore"
# crm configure primitive ping ocf:pacemaker:ping params host_list="192.168.0.254" name="ping" op monitor interval="10s" timeout="60s" op start timeout="60s" op stop timeout="60s"
# crm configure clone ping_clone ping meta globally-unique="false"

Come spiegato nei precedenti articoli queste configurazioni preliminari indicano di non utilizzare stonith, ignorare l’assenza di quorum e creare una risorsa ping che controlli la connettività in entrambi i nodi attraverso il clone della risorsa stessa.
Maggiori informazioni e spiegazioni approfondite si trovano nella seconda parte del secondo articolo della serie.
In particolare l’ultima definizione, ossia la risorsa clonata per il controllo della connettività, favorisce lo spunto per la configurazione della risorsa Tomcat per la quale esiste un resource agent apposito: http://www.linux-ha.org/doc/re-ra-tomcat.html. Essendo obiettivo del progetto la gestione per mezzo di Pacemaker delle istanze di Tomcat, ed essendo le istanze di Tomcat in tutto e per tutto simili su entrambi nodi, queste potranno essere assimilate ad un’unica risorsa clonata.
Nel dettaglio, la configurazione sarà la seguente:

1
2
3

crm configure primitive cluster_tomcat ocf:heartbeat:tomcat params java_home="/usr/local/java/" catalina_home="/usr/local/tomcat/" op monitor interval="60s" timeout="30s" op start interval="0" timeout="60s" op stop interval="0" timeout="120s"
crm configure clone cluster_tomcat_clone cluster_tomcat meta globally-unique="false" target-role="Started"
crm configure location cluster_tomcat_on_connected_node cluster_tomcat_clone -inf: not_defined ping or ping lte 0

Nel dettaglio:

1. Viene definita la risorsa cluster_tomcat i cui parametri sono il path in cui è installato Java (java_home) ed il path di tomcat stesso (catalina_home);
2. La risorsa cluster_tomcat viene clonata dalla nuova risorsa cluster_tomcat_clone. Così come per la risorsa ping_clone che risiederà su ciascun nodo definito, anche questa avrà lo stesso comportamento;
3. Viene definita una location, ossia un vincolo che obbliga la risorsa clonata a funzionare unicamente sui nodi la cui connettività è comprovata (nodi su cui cioè la risorsa ping esiste e restituisce un risultato positivo);

A questo punto, la situazione del cluster dovrebbe essere la seguente:

============
Last updated: Mon Jan 24 10:17:05 2011
Stack: Heartbeat
Current DC: tomcatcluster-nodo2 (b091eddc-aa64-4d7d-8407-65a7dddafbdf) - partition with quorum
Version: 1.0.10-da7075976b5ff0bee71074385f8fd02f296ec8a3
2 Nodes configured, unknown expected votes
2 Resources configured.
============
 
Online: [ tomcatcluster-nodo1 tomcatcluster-nodo2 ]
 
 Clone Set: ping_clone
     Started: [ tomcatcluster-nodo1 tomcatcluster-nodo2 ]
 Clone Set: cluster_tomcat_clone
     Started: [ tomcatcluster-nodo1 tomcatcluster-nodo2 ]

Ed entrambe le istanze di Tomcat dovrebbero essersi avviate su ciascun nodo. E’ possibile verificarlo provando ad accedere all’interfaccia web di amministrazione presente su ciascun nodo:

http://tomcatcluster-nodo1:8080/manager/html
http://tomcatcluster-nodo2:8080/manager/html

Entrambi link dovrebbero essere funzionanti e richiedere uno username con password per accedervi. Una volta inserite le credenziali definite in fase di configurazione di Tomcat, sarà visibile l’interfaccia di amministrazione delle applicazioni.

Analisi dei log

L’avvio dei servizi Tomcat da parte del cluster può essere seguito dai file di log dell’application server stesso, all’interno dei quali è possibile verificare se il cluster nativo di Tomcat viene attivato correttamente.

# cat /usr/local/tomcat/logs/catalina.out
...
INFO: Cluster is about to start
...
INFO: Setting cluster mcast soTimeout to 500
...
INFO: Server startup in 3153 ms
...
21-gen-2011 17.05.47 org.apache.catalina.ha.tcp.SimpleTcpCluster memberAdded
INFO: Replication member added:org.apache.catalina.tribes.membership.MemberImpl[tcp://{192, 168, 0, 1}:4000,{192, 168, 0, 2},4000, alive=1259, securePort=-1, UDP Port=-1, id={101 64 89 59 2 -44 67 123 -73 23 4 -50 -57 105 8 58 }, payload={}, command={}, domain={}, ]
...

Il server è avviato e certamente ha considerato la configurazione, includendo l’host (memberAdded) 192.168.0.52 nel cluster.

Configurazione applicazione di Test

La configurazione può dirsi completa. E’ possibile quindi installare una semplice applicazione di test per verificare nell’effettivo il funzionamento delle sessioni condivise. Per fare ciò è sufficiente creare un’applicazione configurata con il parametro “” che indica al cluster di sfruttare la configurazione cluster per la condivisione delle sessioni.
L’applicazione TestSession, scaricabile dal portale è stata configurata proprio a questo scopo:

TestSession

Una volta scaricato il file TestSession.war, attraverso la console Tomcat e su ciascun nodo, sarà possibile installare l’applicazione nella sezione “WAR file to deploy”, selezionando il fie “war” scaricato e premendo il tasto “deploy”. Se l’esito sarà “OK”, entrambe le applicazioni saranno disponibili attraverso l’indirizzo:

http://tomcatcluster-nodo1:8080/TestSession
http://tomcatcluster-nodo2:8080/TestSession

E’ possibile dunque avviare i test.

Test di funzionamento

Il principio di funzionamento del cluster è quello di rispondere alle richieste. Generalmente in questo tipo di architettura, gli Application Server risiedono dietro a bilanciatori, cioè apparati hardware o software che distribuiscono il carico attraverso batterie di macchine che offrono servizi.
L’architettura di test predisposta non prevede l’utilizzo di un bilanciatore, a per simulare il bilanciamento del carico tra i due host sarà sufficiente inserire nel file /etc/hosts della propria macchina queste due righe:

192.168.0.1 tomcatcluster
#192.168.0.2 tomcatcluster

Come scritto in precedenza quindi, l’applicazione potrà essere chiamata come segue, senza far riferimento all’IP:

http://tomcatcluster:8080/TestSession/

Il test funzionerà in modo che chiamato l’url relativo al quale si passa un parametro, ad esempio:

http://tomcatcluster:8080/TestSession/session.jsp?aaa=111

la pagina visualizzi quanto segue:

Server info
 
    * Name: tomcatcluster-nodo1
    * Address: 192.168.0.1
 
Session Attributes
 
    * aaa = 111

Ovviamente le chiamate successive con parametri differenti aggiungeranno nuovi attributi.
Nella fattispecie, chiamare:

http://tomcatcluster:8080/TestSession/session.jsp?bbb=222

produrrà:

Server info
 
    * Name: tomcatcluster-nodo1
    * Address: 192.168.0.1
 
Session Attributes
 
    * aaa = 111
    * bbb = 222

Il test a questo punto è semplicissimo, modificando il file /etc/hosts in modo che appaia come segue:

#192.168.0.1 tomcatcluster
192.168.0.2 tomcatcluster

Di fatto il secondo nodo ora sarà quello attivo. Richiamando nuovamente lo script:

http://tomcatcluster:8080/TestSession/session.jsp?ccc=333

Si otterrà il seguente output:

Server info
 
    * Name: tomcatcluster-nodo2
    * Address: 192.168.0.2
 
Session Attributes
 
    * aaa = 111
    * bbb = 222
    * ccc = 333

Da notare come nel Server info ora il nodo sia tomcatcluster-nodo2, mentre i dati di sessione sono stati mantenuti.

Il corretto funzionamento è verificabile anche accedendo singolarmente a ciascun tomcat ai link presenti nella pagina manager nella colonna “Sessions”, dove vengono elencate le sessioni, che ovviamente hanno lo stesso codice su entrambi gli Application server.

Conclusioni

Terminata questa carrellata di concetti e test una cosa è chiara: come sempre questo è solo l’inizio. Sono moltissimi gli ambiti in cui soluzioni come (o simili) a quella presentata possono essere messe in produzione per ottenere infrastrutture stabili, sicure e funzionali. Sempre e comunque altamente affidabili.

Questo articolo illustra come ottenere un’installazione coerente di un fileserver Linux basato su SAMBA, che amministri l’accesso alle condivisioni attraverso utenti che appartengano a gruppi di sistema, gestiti in una forma riconoscibile.
Gli utenti, pur essendo a tutti gli effetti parte del sistema, avranno permessi di accesso unicamente attraverso il protocollo CIFS, gestito dalle macchine Microsoft Windows.

Installazione di SAMBA

La procedura descritta fa riferimento al sistema operativo Ubuntu Server 10.4, ed all’ultima release stabile disponibile in esso per il progetto libero SAMBA, la versione 3.4.7.
L’installazione per Ubuntu ed i sistemi Debian, può essere effettuata come di consueto:

# apt-get install samba

mentre nei sistemi che fanno uso di rpm e di yum il comando sarà invece:

# yum install samba

Prima di effettuare qualsiasi operazione è bene salvare il file di configurazione originale di SAMBA:

# cd /etc/samba
# mv smb.conf smb.conf.org

nel corso dell’articolo partiremo da un file completamente vuoto, per sottolineare come sia possibile impostare pochi parametri per essere operativi nel minor tempo possibile.

Configurazione di SAMBA (impostazioni globali)

Le configurazioni descritte fanno hanno come presupposto il fatto che l’utente con cui si sta operando all’interno del sistema sia “root”. Attraverso l’editor preferito sarà possibile creare un nuovo file smb.conf:

# sudo su -
# vi /etc/samba/smb.conf

All’interno del quale dovranno essere impostati i seguenti parametri:

[global]
   security = user
   workgroup = NETWORK.LOCAL
   server string = %h server (Samba, Ubuntu) 
 
   wins support = yes 
   dns proxy = no 
 
   log file = /var/log/samba/log.%m 
   max log size = 1000 
   syslog = 0 
 
   encrypt passwords = true 
   passdb backend = tdbsam
 
   directory mask = 2770 
   create mask = 0660

Le configurazioni indicano che il server è di tipo standalone (security = user), ossia non collegato a sistemi di autenticazione centralizzati. Il server è parte del gruppo di lavoro “NETWORK.LOCAL” (opzione workgroup, che andrà modificata a seconda delle impostazioni relative propria rete Microsoft Windows) e funzionerà da server WINS (wins support = yes) in modo da gestire la risoluzione dei nomi Microsoft Windows per la rete, ma non controllerà però i nomi effettuando query sul server dns di sistema (dns proxy = no).
Il sistema registrerà un log per ciascuna macchina che si collegherà (log file = /var/log/samba/log.%m), tale log non potrà eccedere un megabyte di grandezza (max log size = 1000). Inoltre nessuna informazione verrà registrata nel file /var/log/syslog (syslog = 0), il file di log generale relativo al sistema. Tutte le informazioni relative all’esecuzione del demone saranno reperibili all’interno del file /var/log/samba/log.smbd.
Il sistema di autenticazione cripterà le password (encrypt passwords) ed utilizzerà il backend tdbsam (opzione passdb backend), ossia il database locale.
Le ultime due opzioni indicate definiscono la maschera attraverso la quale verranno create le directory (directory mask = 2770) ed i file (create mask = 0660). Le directory verranno quindi create con permessi di lettura, scrittura ed esecuzione per il proprietario ed il gruppo, mentre per tutti gli altri saranno inaccessibili. I file verranno creati con i medesimi permessi ad eccezione dell’esecuzione.
Particolarità aggiuntiva della modalità di creazione delle cartelle è quella di possedere il bit setgid (http://it.wikipedia.org/wiki/Setuid_e_setgid) che impone l’appartenenza al gruppo della cartella padre per tutti i file e le cartelle create al suo interno. Questo significa che chiunque appartenga al gruppo della cartella padre potrà creare file e cartelle al suo interno, tali file e cartelle apparterranno al gruppo della cartella padre. In questo modo i permessi specifici di accesso per i gruppi definiti nelle cartelle governeranno la totalità degli accessi.

Configurazione di un gruppo

Ciascun gruppo di accesso verrà nominato in questo modo:

# groupadd samba_rwx_Amministrazione

Il criterio con cui i gruppi vengono creati e nominati è ottenibile scomponendo il nome attraverso i caratteri “_” (underscore), dove “samba” indica che il gruppo è inerente al servizio samba, “rwx” indica il tipo di accesso che può essere appunto “rwx” (permessi di lettura e scrittura) o “rx” (sola lettura), mentre “Amministrazione” indica il nome della condivisione a cui il gruppo si riferisce.

Aggiunta di un’utenza

Ogni utenza creata nel sistema che farà riferimento al servizio samba, avrà come gruppo primario samba, con identificativo “999″, creato con il seguente comando:

# groupadd -g 999 samba

In questo modo, la separazione degli ambiti operativi sarà oltre che configurata nel sistema, anche ben visibile.
Per aggiungere un’utenza al sistema i passi da compiere sono quindi i seguenti:

1. Lanciare il comando:

   # useradd -g samba -s /bin/false -d -c "Utente di test" user1

   In cui user1 rappresenta il nome attraverso il quale l’utente dovrà accedere alle condivisioni. A user1 viene assegnato il gruppo primario “samba” (-g samba), una shell di login nulla in modo che non possa mai effettuare il login nel sistema (-s /bin/false) ed una breve descrizione dell’utenza (-d, generalmente nome e cognome, oppure un indicativo della funzione svolta).

2. L’utente creato va poi aggiunto al database locale SAMBA, attraverso questo comando:

   # smbpasswd -a user1

   indicando per due volte la password scelta, che può essere anche omessa nel caso in cui lo si decida (è sempre consigliabile inserirne una).

3. L’utente va quindi aggiunto ad uno dei gruppi disponibili. Aggiungere utenti al gruppo è possibile con il seguente comando:

   # adduser user1 samba_rwx_Amministrazione

Per controllare quali utenti appartengono al gruppo è sufficiente digitare il seguente comando:

# cat /etc/group | grep "samba_rwx_Amministrazione"
samba_rwx_Amministrazione:user1,user2,user3

Mentre per controllare un singolo utente a quali gruppi appartiene, il comando sarà invece:

# groups user1
user1 : samba samba_rwx_Amministrazione

Aggiunta di una condivisione

Ciascuna condivisione fa riferimento ad un path locale, nel caso descritto viene creata una cartella /share:

# mkdir /share

al di sotto della quale tutte le cartelle condivise verranno create:

1
2
3

# mkdir /share/Amministrazione
# chgrp samba_rwx_Amministrazione /share/Amministrazione
# chmod 2770 /share/Amministrazione

Queste operazioni andranno eseguite per ciascuna nuova condivisione creata e si riassumono come segue:

1. Creazione effettiva della cartella;
2. Assegnazione della cartella al gruppo creato;
3. Impostazione del permesso setgid (vedi sopra) ricorsivo sulla cartella appena creata;

Le condivisioni verranno definite nel file di configurazione smb.conf in coda alle dichiarazioni globali, in un formato simile al seguente:

[Amministrazione] 
comment = Amministrazione 
read only = no 
write list = @samba_rwx_Amministrazione
read list = 
path = /share/Amministrazione

Il codice illustrato definisce una condivisione denominata “Amministrazione” a cui possono accedere in scrittura nella directory “/share/Amministrazione” unicamente gli utenti appartenenti al gruppo “samba_rwx_Amministrazione”.

Pertanto, per aggiungere una condivisione sarà quindi sufficiente eseguire la creazione e l’assegnazione dei permessi come descritto sopra ed inserire all’interno del file /etc/samba/smb.conf una dichiarazione seguendo il modello indicato:

[<NOMECONDIVISIONE>] 
comment = <Descrizione condivisione>
read only = no 
write list = @<gruppo con permessi di scrittura>
read list = @<gruppo con permessi di lettura>
path = <path della condivisione>

Nel caso l’accesso venga deciso unicamente in lettura o unicamente in scrittura, è possibile omettere le righe relative (write list o read list) dalla dichiarazione.

Attivazione delle configurazioni

Per applicare le nuove configurazioni, il servizio SAMBA necessita di essere ricaricato:

# service smbd reload

Da questo momento in poi sarà possibile utilizzare una qualsiasi macchina Microsoft Windows per testare l’effettivo successo delle configurazioni impostate.

Note

Quanto descritto consente di configurare SAMBA affinché possa interagire con client o server Microsoft Windows come se fosse un file e print server Microsoft.
E’ possibile variare le configurazioni in modo che SAMBA agisca da Primary Domain Controller (PDC), Backup Domain Controller o prendere parte ad un dominio Active Directory.
Sul portale tecnico sono disponibili diversi articoli che approfondiscono questi argomenti:

Realizzare un Primary Domain Controller con SAMBA, Openldap e smbldap-tools : (1 di 6)
Realizzare un Primary Domain Controller con SAMBA, Openldap e smbldap-tools : (2 di 6)
Realizzare un Primary Domain Controller con SAMBA, Openldap e smbldap-tools : (3 di 6)
Realizzare un Primary Domain Controller con SAMBA, Openldap e smbldap-tools : (4 di 6)
Realizzare un Primary Domain Controller con SAMBA, Openldap e smbldap-tools : (5 di 6)
Realizzare un Primary Domain Controller con SAMBA, Openldap e smbldap-tools : (6 di 6)

Samba e Active Directory (1 di 3): diventare parte di un Dominio
Samba e Active Directory (2 di 3): interrogare il dominio
Samba e Active Directory (3 di 3): configurare pam per l’autenticazione locale

In attesa quindi di saggiare le meraviglie dell’annunciato SAMBA 4, che conterrà un motore interno volto ad eguagliare l’efficienza e la funzionalità di Microsoft Active Directory, è chiaro come sia già possibile adottare SAMBA in ambiti produttivi di svariato genere, con successo, e senza costi di licenza.

Nel precedente articolo è stato effettuato un confronto tra le tipologie possibili di utilizzo relativo ad Heartbeat, nella modalità classica ed in quella mediante CRM (Cluster Resource Manager) per l’erogazione in alta affidabilità del servizio Apache.
In quest’ultimo articolo verrà proposto un vero case study relativo alla configurazione di un cluster erogante uno storage NFS in alta affidabilità i cui dati verranno ridondati via DRBD (Network Raid 1), mediante la configurazione di Pacemaker.
Peculiarità del progetto sarà l’utilizzo per l’erogazione delle directory NFS di entrambi i nodi, in modo da sfruttare tutte le macchine presenti, per un cluster di tipo active-active.

Il progetto

Quanto si propone di realizzare è un sistema in alta affidabilità che consenta di impiegare tutte le macchine presenti all’interno del cluster per rendere disponibile spazio all’interno di una rete. In altre parole, un Network Attached Storage (NAS), un’entità composta da due macchine collegate alla rete che consentano a dei client di montare le partizioni e fruire dello spazio reso disponibile.
Le componenti impiegate all’interno del progetto saranno:

1. Heartbeat e Pacemaker: per la gestione del cluster;
2. DRBD: per la replica dei dati fra le due macchine attraverso un network raid 1;
3. NFS: per la condivisione attraverso la rete dello spazio;

Il progetto si rifà nelle sue fondamenta a quanto illustrato nella seconda parte del precedente articolo e, se non lo si è ancora fatto, è bene dare una rapida lettura in modo da poter applicare i concetti lì illustrati senza perplessità.
Il cluster verrà costruito su due sistemi (debian-lenny-nodo1 e debian-lenny-nodo2) collegati ciascuno alla rete locale (192.168.1.0/24) e l’uno all’altro da un cavo cross (10.0.0.0/24, connessione necessaria per realizzare il network raid 1 con DRBD), lo spazio locale verrà esportato attraverso il protocollo NFS. In particolare verranno definite due condivisioni distinte, corrispondenti a due cartelle locali chiamate /share-a e /share-b.
Obiettivo ultimo è quello di ottenere ciascuna condivisione esportata da un nodo, in modo da avere (a regime ed in condizioni ottimali) un cluster in cui nessun nodo risulti passivo.
Unico requisito richiesto sui nodi è la presenza dei pacchetti heartbeat e pacemaker (la cui installazione è descritta nell’articolo precedente) e del demone NFS. Nei sistemi Debian ed Ubuntu sarà quindi necessario installare il pacchetto nfs-kernel-server mentre in RedHat/SuSe il pacchetto sarà nfs.

La gestione locale dei dati: device, md, LVM o tutti e tre?

Prima di iniziare a configurare il cluster è bene decidere come verranno gestiti sulle macchine i dati che andranno esposti. Questa scelta, la più delicata poiché intacca direttamente le performance, va fatta sulla base dell’hardware disponibile, partendo da tre ambiti operativi:

• device: partizioni fisiche (ad esempio /dev/sda3, /dev/sda4 e via dicendo);
• md (Multiple Disk): gestione locale dei raid, i dati sono ridondati sulle singole macchine (oltre che in rete);
• LVM (Logical Volume Manager): volumi logici, per una gestire più elastica dello spazio locale;

Partendo dal presupposto che l’utilizzo dei device è indispensabile (visto che si sta parlando di dischi locali), scegliere se configurare raid locali o LVM dipende da quanto si dispone.
Se le macchine utilizzate possiedono una controller RAID hardware, allora si potrà evitare di configurare i dispositivi md, così come se si ritiene la ridondanza locale superflua (del resto i dati verranno comunque ridondati in rete).
Se il sistema necessiterà di frequenti variazioni in termini di spazio sulle partizioni esposte sarà doveroso impiegare volumi logici in modo da gestire con facilità operazioni di ridimensionamento. Inoltre la gestione dei volumi logici potrebbe essere preferita dai più, proprio per la semplicità con cui è possibile apportare variazioni allo spazio disponibile, soprattutto in situazioni complesse.
Lampante è come più livelli di complessità si aggiungono, maggiore sarà il carico che graverà sul sistema operativo e maggiore dovrà essere la capacità di gestire eventuali malfunzionamenti.
Come sempre quindi, la libertà di scelta è totale e dipende unicamente dell’utente.
Nel caso illustrato la scelta è caduta sull’impiego di LVM su due partizioni (/dev/sda3 e /dev/sdb3), in quanto le macchine su cui la soluzione viene implementata possiedono una controller RAID integrata che si occupa di ridondare i due dischi disponibili.
Su entrambe le macchine sono stati definiti due Physical Volume:

# pvcreate /dev/sd[ab]3

Ai quali è stato associato un Volume Group denominato vg_share:

# vgcreate vg_share /dev/sd[ab]3

Ed infine sono stati creati due Logical Volume, denominati lv_drbd0 ed lv_drbd1, i quali rappresenteranno le due condivisioni relative ai device drbd che verranno in seguito creati:

# lvcreate -n lv_drbd0 -L 1G vg_share
# lvcreate -n lv_drbd1 -L 1G vg_share

l’opzione “-L” definisce lo spazio massimo occupabile dal volume logico, chiaramente essendo un progetto con fini puramente didattici lo spazio è stato ridotto per facilitare e velocizzare le operazioni di creazione ed aggiornamento.
All’interno della cartella /dev/mapper/ saranno quindi visibili i seguenti file:

# ls -la /dev/mapper/
totale 0
drwxr-xr-x  2 root root     100 2010-09-14 12:15 .
drwxr-xr-x 17 root root    3700 2010-09-14 12:15 ..
crw-rw----  1 root root  10, 59 2010-09-14 12:15 control
brw-rw----  1 root disk 251,  0 2010-09-14 12:15 vg_share-lv_drbd0
brw-rw----  1 root disk 251,  1 2010-09-14 12:15 vg_share-lv_drbd1

a dimostrazione che i volumi logici sono pronti ad essere utilizzati.

Configurazione preliminare di Heartbeat

La configurazione preliminare di Heartbeat si rifà totalmente a quanto illustrato nel precedente articolo al paragrafo “Configurazione di Heartbeat in modalità CRM con Pacemaker”:

/etc/ha.d/ha.cf:

autojoin none
keepalive 1
deadtime 10
warntime 5
initdead 20
mcast eth0 239.0.0.43 694 1 0
bcast eth1
node    debian-lenny-nodo1
node    debian-lenny-nodo2
crm respawn

/etc/ha.d/authkeys:

auth 1
1 crc

Quindi una volta avviato Heartbeat:

# /etc/init.d/heartbeat start

è possibile definire le configurazioni preliminari del cluster:

# crm configure property stonith-enabled="false"
# crm configure property no-quorum-policy="ignore"
# crm configure primitive ping ocf:pacemaker:ping params host_list="192.168.1.1" name="ping" op monitor interval="10s" timeout="60s" op start timeout="60s" op stop timeout="60s"
# crm configure clone ping_clone ping meta globally-unique="false"

In breve viene disabilitato lo stonith, viene imposto al cluster di ignorare l’assenza di quorum e viene definita una risorsa ping che controlla la connettività in entrambi i nodi attraverso il clone della risorsa stessa.
La situazione del cluster viene così riassunta:

# crm status
============
Last updated: Tue Sep 14 12:17:29 2010
Stack: Heartbeat
Current DC: debian-lenny-nodo1 (1627f3ec-ec7e-4f0c-b69e-e9729933a2cc) - partition with quorum
Version: 1.0.8-042548a451fce8400660f6031f4da6f0223dd5dd
2 Nodes configured, unknown expected votes
1 Resources configured.
============
 
Online: [ debian-lenny-nodo1 debian-lenny-nodo2 ]
 
 Clone Set: ping_clone
     Started: [ debian-lenny-nodo1 debian-lenny-nodo2 ]

Per qualsiasi dubbio in merito alle configurazioni sopra riportate, come già detto, è bene far riferimento al precedente articolo.

Configurazione preliminare di DRBD

In questa fase del progetto è necessario configurare i due volumi logici creati in precedenza affinché possano essere utilizzati con DRBD. Per prima cosa il sistema deve essere predisposto per supportare DRBD, il che significa che vanno installati i pacchetti relativi al modulo che verrà inserito all’interno del kernel. Come sempre tutto dipende dalla distribuzione che si sta utilizzando, nel caso illustrato Debian offre il meta pacchetto drbd8-modules-2.6-686 che si occupa di installare la corretta versione associata al kernel utilizzato:

apt-get install drbd8-modules-2.6-686 drbd8-utils

Con Ubuntu è sufficiente installare il pacchetto drbd8-utils che risolverà le dipendenze ed installerà il modulo, stesso dicasi per SuSe, mentre per RedHat è necessario utilizzare i pacchetti Extra di CentOS.
Maggiori informazioni sulle versioni disponibili sono qui: http://www.drbd.org/download/packages/.

Installato il modulo, per configurare i due volumi logici i passi da seguire sono semplicissimi. In prima istanza va modificato il file /etc/drbd.conf come segue:

global { usage-count no; }
 
common { protocol C; syncer { rate 100M; } }
 
resource r0 {
        device /dev/drbd0;
        meta-disk internal;
        disk /dev/mapper/vg_share-lv_drbd0;
 
        on debian-lenny-nodo1 {
                address 10.0.0.1:7788;
        }
 
        on debian-lenny-nodo2 {
                address 10.0.0.2:7788;
        }
}
 
resource r1 {
        device /dev/drbd1;
        meta-disk internal;
        disk /dev/mapper/vg_share-lv_drbd1;
 
        on debian-lenny-nodo1 {
                address 10.0.0.1:7789;
        }
 
        on debian-lenny-nodo2 {
                address 10.0.0.2:7789;
        }
}

Le dichiarazioni presenti nel file sono auto esplicative: Il tipo di algoritmo con cui verrà gestita la sincronizzazione è C (replicazione sincrona, standard, qui i dettagli sui diversi protocolli disponibili), mentre la velocità a cui i dati verranno sincronizzati è 100 Mega (qui come calcolare la corretta velocità di sincronizzazione).
sono state definite due risorse (resource) che poggeranno su volumi logici interni (disk) e registreranno i meta-dati relativi alla sincronizzazione internamente (meta-disk), ciascuna risorsa farà viaggiare le informazioni per la sincronizzazione sull’interfaccia locale relativa alla rete 10.0.0.0 (address) ad una porta differente (7788 e 7789).

A questo punto i volumi logici vanno inizializzati in modo che il sistema possa iniziare a servirsi dei device. Le operazioni da compiere in sequenza, su entrambi i nodi, sono le seguenti:

1
2
3
4
5

# modprobe drbd
# drbdadm create-md r0
# drbdadm create-md r1
# drbdadm up r0
# drbdadm up r1

Linea per linea, ecco quanto fatto:

1. Caricamento del modulo drbd: il sistema è in grado di supportare dispositivi drbd;
2. Creazione del meta-device sopra il volume logico r0, così come dichiarato nel file di configurazione, il volume /dev/mapper/vg_share-lv_drbd0 viene inizializzato;
3. Creazione del meta-device sopra il volume logico r1, così come dichiarato nel file di configurazione, il volume /dev/mapper/vg_share-lv_drbd1 viene inizializzato;
4. Attivazione del meta-device, da questo momento il sistema “vede” /dev/drbd0;
5. Attivazione del meta-device, da questo momento il sistema “vede” /dev/drbd1;

Come ultima fase per l’inizializzazione dei dispositivi è necessario effettuare la prima sincronizzazione in modo che i volumi remoti vengano allineati. Per far ciò è necessario lanciare il seguente comando su uno solo dei due nodi:

# drbdadm -- --overwrite-data-of-peer primary all

Il comando forza lo stato primario del nodo su cui è stato lanciato ed avvia nel contempo la prima sincronizzazione, al termine della quale lo stato dei meta-device drbd sarà il seguente:

# cat /proc/drbd 
version: 8.3.7 (api:88/proto:86-91)
GIT-hash: ea9e28dbff98e331a62bcbcc63a6135808fe2917 build by root@debian-lenny-nodo1, 2010-09-13 18:03:02
 0: cs:Connected ro:Secondary/Secondary ds:UpToDate/UpToDate C r----
    ns:0 nr:0 dw:0 dr:0 al:0 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:b oos:0
 1: cs:Connected ro:Secondary/Secondary ds:UpToDate/UpToDate C r----
    ns:0 nr:0 dw:0 dr:0 al:0 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:b oos:0

Per concludere la configurazione preliminare di drbd andrà creato un filesystem su ciascuno dei device creati:

# mkfs.ext3 /dev/drbd0
# mkfs.ext3 /dev/drbd1

E rimosso l’avvio automatico del demone dal sistema, poiché questo verrà gestito totalmente dal cluster. Per Debian ed Ubuntu il comando da lanciare sarà:

# update-rc.d -f drbd remove

mentre nel caso di RedHat/CentOS/SuSe:

# chkconfig --level 123456 drbd off

E’ giunto il momento di configurare lo storage condiviso.

Configurazione di Heartbeat e DRBD

Prima implementare l’esposizione dello spazio che abbiamo creato via NFS è necessario configurare il cluster affinché gestisca i dispositivi DRBD e ne amministri lo stato. Come stabilito in precedenza infatti, il controllo di tali componenti sarà totalmente nelle mani del cluster e non del sistema operativo. In altre parole i due componenti DRBD non saranno gestiti come demoni, ma come due risorse distinte.
DRBD, rispetto a quanto illustrato sinora, non è una risorsa standard: non è assimilabile infatti alle risorse comuni poiché necessità di risiedere su (almeno) due nodi, questa peculiarità però non permette comunque di creare un clone della risorsa da ripartire sulle altre macchine, poiché in ciascuno dei nodi su cui essa sarà attiva questa dovrà assumere uno stato differente.
Per questa ragione, dopo aver definito le risorse standard associate ai dispositivi DRBD in precedenza creati (r0 ed r1):

# crm configure primitive drbd0 ocf:linbit:drbd params drbd_resource="r0" op monitor interval="20s" timeout="40s" op start interval="0" timeout="240s" op stop interval="0" timeout="100s"
# crm configure primitive drbd1 ocf:linbit:drbd params drbd_resource="r1" op monitor interval="20s" timeout="40s" op start interval="0" timeout="240s" op stop interval="0" timeout="100s"

è necessario configurare due risorse multi-state:

# crm configure ms ms-drbd0 drbd0 meta master-max="1" notify="true"
# crm configure ms ms-drbd1 drbd1 meta master-max="1" notify="true"

I due comandi, ciascuno relativo ad una risorsa DRBD, definiscono una risorsa multi-state che può avere un solo nodo master (master-max) il quale una volta assunto il proprio stato (master o slave che sia) deve notificare il successo agli altri nodi (notify), in modo che la risorsa sia in uno stato coerente su entrambi i nodi.
Dopo qualche secondo sarà possibile osservare all’interno dello stato del cluster quanto realizzato:

============
Last updated: Wed Sep 15 20:16:44 2010
Stack: Heartbeat
Current DC: debian-lenny-nodo1 (1627f3ec-ec7e-4f0c-b69e-e9729933a2cc) - partition with quorum
Version: 1.0.8-042548a451fce8400660f6031f4da6f0223dd5dd
2 Nodes configured, unknown expected votes
3 Resources configured.
============
 
Online: [ debian-lenny-nodo1 debian-lenny-nodo2 ]
 
 Clone Set: ping_clone
     Started: [ debian-lenny-nodo1 debian-lenny-nodo2 ]
 Master/Slave Set: ms-drbd0
     Masters: [ debian-lenny-nodo1 ]
     Slaves: [ debian-lenny-nodo2 ]
 Master/Slave Set: ms-drbd1
     Masters: [ debian-lenny-nodo1 ]
     Slaves: [ debian-lenny-nodo2 ]

Come si evince dall’output mostrato il nodo master per entrambe le risorse è debian-lenny-nodo1.

Ora che il cluster controlla i dispositivi è necessario esporli. Per fare ciò sono necessarie tre componenti:

1. Indirizzo IP: ossia l’indirizzo di riferimento per l’intera rete a quela specifica condivisione;
2. Filesystem: ovvero il mount del filesystem relativo alla risorsa DRBD in modo che ci si possa scrivere sopra;
3. NFS: in modo da esporre la condivisione con il protocollo NFS e permettere il mount da parte di client di rete;

Esisteranno quindi due gruppi di risorse contenenti le tre risorse descritte, tali gruppi verranno nominati come le cartelle che dovranno esporre, così come definito in fase di studio del progetto: share-a e share-b.

Indirizzo IP

La configurazione degli indirizzi IP è identica a quanto illustrato nel precedente articolo:

# crm configure primitive share-a-ip ocf:heartbeat:IPaddr2 params ip="192.168.1.33" nic="eth0" op monitor interval="20s" timeout="40s"
# crm configure primitive share-b-ip ocf:heartbeat:IPaddr2 params ip="192.168.1.34" nic="eth0" op monitor interval="20s" timeout="40s"

al gruppo che eroga share-a pertanto verrà associato l’indirizzo 192.168.1.33 mentre a share-b 192.168.1.34, entrambe le risorse sono gestite dal il resource agent IPAddr2.

Filesystem

Il dispositivo /dev/drbd0 verrà associato a share-a ed alla directory /share-a, così come share-b monterà /dev/drbd1 sulla directory /share-b.
Andranno quindi create le directory per i mount su entrambi i nodi:

# mkdir /share-a
# mkdir /share-b

Ed infine configurate le risorse attraverso il resource agent Filesystem:

# crm configure primitive share-a-fs ocf:heartbeat:Filesystem params device="/dev/drbd0" directory="/share-a" fstype="ext3" op monitor interval="20s" timeout="40s" op start interval="0" timeout="60s" op stop interval="0" timeout="60s" meta is-managed="true" 
# crm configure primitive share-b-fs ocf:heartbeat:Filesystem params device="/dev/drbd1" directory="/share-b" fstype="ext3" op monitor interval="20s" timeout="40s" op start interval="0" timeout="60s" op stop interval="0" timeout="60s" meta is-managed="true"

NFS

Per permettere l’esportazione di ciascuna share in maniera indipendente, fermo restando che su ogni sistema il demone NFS deve essere in esecuzione, è possibile utilizzare un resource agent denominato exportfs.
Questo resource agent creato da Holger Teutsch, potrebbe non essere disponibile se non si possiede una versione recente di Heartbeat (successiva al marzo 2010). In questo caso il problema è facilmente risolvibile installando il resource agent su entrambi i nodi come segue:

# cd /usr/lib/ocf/resource.d/heartbeat/
# wget http://hg.linux-ha.org/agents/raw-file/c8d8b1126ffd/heartbeat/exportfs
# chmod +x exportfs

In questo modo sarà possibile dichiarare due risorse exportfs affinché espongano le due cartelle:

# crm configure primitive share-a-exportfs ocf:heartbeat:exportfs params directory="/share-a" clientspec="192.168.1.0/24" options="rw,async,no_subtree_check,no_root_squash" fsid="1" op monitor interval="10s" timeout="30s" op start interval="0" timeout="40s" op stop interval="0" timeout="40s"
# crm configure primitive share-b-exportfs ocf:heartbeat:exportfs params directory="/share-b" clientspec="192.168.1.0/24" options="rw,async,no_subtree_check,no_root_squash" fsid="2" op monitor interval="10s" timeout="30s" op start interval="0" timeout="40s" op stop interval="0" timeout="40s"

Il resource agent exportfs si occupa di aggiornare in tempo reale lo stato delle export NFS di sistema, utilizzando appunto il comando exportfs.
Come è facile notare la dichiarazione del resource agent si rifà totalmente alla sintassi del comando exportfs, o più semplicemente al contenuto del file /etc/exports (ossia il file di configurazione di NFS), in particolare:

• directory definisce la directory locale che verrà esportata;
• client_spec definisce quali client potranno accedere alla condivisione;
• options contiene le opzioni di esportazione: lettura/scrittura (rw), l’allineamento del filesystem sarà asincrono (async) e tutto il volume verrà esportato senza controllo alle sotto directory (no_subtree_check), infine sarà possibile per l’utente root del client remoto avere privilegi di root sulla condivisione (no_root_squash);
• fsid definisce un identificatore univoco per la condivisione;

Raggruppare le risorse create

Ora che è terminata la creazione delle risorse, è facile notare come queste abbiano nomi riconducibili al loro utilizzo, ma siano in realtà slegate le une dalle altre. Necessitano quindi, per una corretta gestione, di essere raggruppate. Pacemaker permette di creare quindi gruppi di risorse, la cui definizione sequenziale stabilisce anche l’ordine con cui le risorse verranno avviate:

# crm configure group share-a share-a-fs share-a-exportfs share-a-ip
# crm configure group share-b share-b-fs share-b-exportfs share-b-ip

Sono stati quindi definiti due gruppi share-a e share-b che avvieranno innanzitutto il filesystem, seguito dall’export dello stesso via NFS ed infine l’indirizzo IP. Chiaramente in fase di stop l’ordine sarà logicamente invertito, garantendo in caso di disservizi ai client remoti in prima istanza di perdere connettività con il server (i client non rilevando più l’indirizzo del server tratterranno le connessioni esistenti in stato di attesa, TIME_WAIT) e, una volta che le risorse saranno ripristinate sul nodo attivo, di continuare a scrivere senza alcuna perdita di dati.

Collocazione, ordinamento e controllo connettività delle risorse

La configurazione del cluster non è però ancora completa. Le risorse drbd ed i gruppi share al momento non sono correlati. Infatti per come è stato configurato il sistema su un nodo potrebbe avviarsi share-a, ma non esserci la risorsa drbd0 promossa allo stato di master, quindi non utilizzabile come mount point, né scrivibile.
Per ovviare a questa potenziale situazione, è necessario associare i gruppi share ai nodi su cui la risorsa drbd è master.
Pacemaker gestisce queste operazioni attraverso le colocation:

# crm configure colocation share-a_on_ms-drbd0 inf: share-a ms-drbd0:Master
# crm configure colocation share-b_on_ms-drbd1 inf: share-b ms-drbd1:Master

Viene definita per entrambi i gruppi share una colocation di peso infinito (inf, quindi senza possibilità di variazione) per cui il gruppo si avvierà solo laddove la risorsa multi-state è in stato master.

E’ necessaria un’altra condizione per aggiungere coerenza alla configurazione e riguarda l’ordinamento nell’avvio delle risorse. Chiaramente ciascun gruppo share non ha ragione di avviarsi se non dopo che il dispositivo drbd è attivo. Pacemaker gestisce la cosa attraverso le definizioni order:

# crm configure order share-a_after_ms-drbd0 inf: ms-drbd0:promote share-a:start
# crm configure order share-a_after_ms-drbd1 inf: ms-drbd1:promote share-b:start

Viene definita una order di peso infinito in cui l’operazione di promozione a master della risorsa multi-state vincola l’avvio del gruppo share.

A completamento della configurazione non rimane che associare le risorse ai nodi con connettività, facendo riferimento alla risorsa ping dichiarata in precedenza e clonata in tutti i nodi:

# crm configure location share-a_on_connected_node share-a rule -inf: not_defined ping or ping lte 0
# crm configure location share-b_on_connected_node share-b rule -inf: not_defined ping or ping lte 0

Viene definita una location relativa ai gruppi share la cui regola di peso meno infinito (-inf) si verifica in assenza di connettività: la risorsa ping non è definita oppure restituisce un valore negativo.
In questo modo quando un nodo che ospita un gruppo perderà la connettività Pacemaker tenterà di effettuare uno switch del gruppo su un altro nodo attivo.

Cleanup finale

Ora che la configurazione del cluster è completa è facile immaginare come tutte le operazioni effettuate possano aver falsato lo stato generale del cluster, quindi, al fine di partire da una situazione pura, è possibile lanciare i seguenti comandi:

# crm resource cleanup share-a
# crm resource cleanup share-b

L’operazione di cleanup della risorsa come dice il nome, azzera il conteggio degli errori per le risorse e le riavvia ordinatamente in modo da, come detto, partire da zero a vagliare eventuali problemi.
Lo stato del cluster a configurazione ultimata dovrebbe essere quindi il seguente:

# crm status
============
Last updated: Fri Sep 17 14:33:16 2010
Stack: Heartbeat
Current DC: debian-lenny-nodo1 (1627f3ec-ec7e-4f0c-b69e-e9729933a2cc) - partition with quorum
Version: 1.0.8-042548a451fce8400660f6031f4da6f0223dd5dd
2 Nodes configured, unknown expected votes
5 Resources configured.
============
 
Online: [ debian-lenny-nodo1 debian-lenny-nodo2 ]
 
 Clone Set: ping_clone
     Started: [ debian-lenny-nodo1 debian-lenny-nodo2 ]
 Master/Slave Set: ms-drbd0
     Masters: [ debian-lenny-nodo2 ]
     Slaves: [ debian-lenny-nodo1 ]
 Master/Slave Set: ms-drbd1
     Masters: [ debian-lenny-nodo1 ]
     Slaves: [ debian-lenny-nodo2 ]
 Resource Group: share-a
     share-a-fs (ocf::heartbeat:Filesystem):    Started debian-lenny-nodo1
     share-a-exportfs   (ocf::heartbeat:exportfs):      Started debian-lenny-nodo1
     share-a-ip (ocf::heartbeat:IPaddr2):       Started debian-lenny-nodo1
 Resource Group: share-b
     share-b-fs (ocf::heartbeat:Filesystem):    Started debian-lenny-nodo2
     share-b-exportfs   (ocf::heartbeat:exportfs):      Started debian-lenny-nodo2
     share-b-ip (ocf::heartbeat:IPaddr2):       Started debian-lenny-nodo2

Creare una configurazione active active

Il progetto iniziale prevede che nessun nodo, in condizioni normali, sia passivo. Pertanto per completare la configurazione del cluster è necessario assegnare ciascun gruppo share ad uno specifico nodo.
Tale risultato è ottenibile mediante l’aggiunta di due ulteriori regole di tipo location:

location cli-prefer-share-a share-a rule inf: #uname eq debian-lenny-nodo1
location cli-prefer-share-b share-b rule inf: #uname eq debian-lenny-nodo2

In questo modo, la regola creata impone che share-a venga associata al nodo debian-lenny-nodo1 mentre share-b al nodo debian-lenny-nodo2: i due nodi saranno entrambi operativi, completando così l’obiettivo deciso in fase di progettazione.

Considerazioni sulla stickiness

La politica del cluster in merito al posizionamento di una risorsa dipende dal peso che questa ha. Il peso viene stabilito in base alle condizioni del cluster e della risorsa stessa. Molte delle regole relative a definizioni di location e order fanno infatti riferimento a pesi infiniti in modo che se queste si verificano lo stato del cluster DEVE variare.
Lo stickiness di una risorsa rappresenta il peso necessario al suo spostamento dalla posizione attuale nel momento in cui il cluster subisce variazioni.

Ad esempio…

Il valore di default della stickyness è 0. se una risorsa viene migrata a mano, il cluster aggiunge una regola di location come quelle descritte poco sopra. Se il nodo che eroga la risorsa perde di connettività, allora questa, per la sua sopravvivenza, verrà migrata sul nodo attivo. Quando però il nodo originale tornerà a vivere, la risorsa, per via della regola impostata, verrà nuovamente migrata in quanto non ha vincoli (la stickiness è 0) che la legano al nodo attuale. Questo significa che nel giro i poco tempo si assisterà a due switch della risorsa, assimilabili a due interruzioni di servizio.
Facile capire come non sempre questo possa essere il comportamento desiderato. Basti pensare al caso di database Oracle, ed a tutti i problemi che comporta uno switch.
Inutile dire che meno sono, meglio è.
Fortunatamente Pacemaker consente di impostare il valore di default di stickiness a infinito:

crm configure property default-resource-stickiness=INFINITY

In questo modo se una risorsa associata ad un nodo migra, alla ricomparsa del nodo questa rimarrà dov’è, limitando ulteriori disservizi.
A seconda della decisione presa in merito alla stickiness, si dovrà quindi scegliere se questa dovrà rimanere al suo valore di default o avere altri valori (numeri maggiori di zero per arrivare ad INFINITY).

Configurazione finale

La configurazione estesa (modificabile attraverso il comando crm configure edit) è la seguente:

node $id="1627f3ec-ec7e-4f0c-b69e-e9729933a2cc" debian-lenny-nodo1
node $id="f4380aee-c67b-4472-9449-5fa8e5ddae34" debian-lenny-nodo2
primitive drbd0 ocf:linbit:drbd \
	params drbd_resource="r0" \
	op monitor interval="20s" timeout="40s" \
	op start interval="0" timeout="240s" \
	op stop interval="0" timeout="100s"
primitive drbd1 ocf:linbit:drbd \
	params drbd_resource="r1" \
	op monitor interval="20s" timeout="40s" \
	op start interval="0" timeout="240s" \
	op stop interval="0" timeout="100s"
primitive ping ocf:pacemaker:ping \
	params host_list="192.168.1.1" name="ping" \
	op monitor interval="10s" timeout="60s" \
	op start interval="0" timeout="60s" \
	op stop interval="0" timeout="60s"
primitive share-a-exportfs ocf:heartbeat:exportfs \
	params directory="/share-a" clientspec="192.168.1.0/24" options="rw,async,no_subtree_check,no_root_squash" fsid="1" \
	op monitor interval="10s" timeout="30s" \
	op start interval="0" timeout="40s" \
	op stop interval="0" timeout="40s"
primitive share-a-fs ocf:heartbeat:Filesystem \
	params device="/dev/drbd0" directory="/share-a" fstype="ext3" \
	op monitor interval="20s" timeout="40s" \
	op start interval="0" timeout="60s" \
	op stop interval="0" timeout="60s" \
	meta is-managed="true"
primitive share-a-ip ocf:heartbeat:IPaddr2 \
	params ip="192.168.1.33" nic="eth0" \
	op monitor interval="20s" timeout="40s"
primitive share-b-exportfs ocf:heartbeat:exportfs \
	params directory="/share-b" clientspec="192.168.1.0/24" options="rw,async,no_subtree_check,no_root_squash" fsid="2" \
	op monitor interval="10s" timeout="30s" \
	op start interval="0" timeout="40s" \
	op stop interval="0" timeout="40s"
primitive share-b-fs ocf:heartbeat:Filesystem \
	params device="/dev/drbd1" directory="/share-b" fstype="ext3" \
	op monitor interval="20s" timeout="40s" \
	op start interval="0" timeout="60s" \
	op stop interval="0" timeout="60s" \
	meta is-managed="true"
primitive share-b-ip ocf:heartbeat:IPaddr2 \
	params ip="192.168.1.34" nic="eth0" \
	op monitor interval="20s" timeout="40s"
group share-a share-a-fs share-a-exportfs share-a-ip
group share-b share-b-fs share-b-exportfs share-b-ip
ms ms-drbd0 drbd0 \
	meta master-max="1" notify="true"
ms ms-drbd1 drbd1 \
	meta master-max="1" notify="true"
clone ping_clone ping \
	meta globally-unique="false"
location cli-prefer-share-a share-a \
	rule $id="cli-prefer-rule-share-a" inf: #uname eq debian-lenny-nodo1
location cli-prefer-share-b share-b \
	rule $id="cli-prefer-share-b-rule" inf: #uname eq debian-lenny-nodo2
location share-a_on_connected_node share-a \
	rule $id="share-a_on_connected_node-rule" -inf: not_defined ping or ping lte 0
location share-b_on_connected_node share-b \
	rule $id="share-b_on_connected_node-rule" -inf: not_defined ping or ping lte 0
colocation share-a_on_ms-drbd0 inf: share-a ms-drbd0:Master
colocation share-b_on_ms-drbd1 inf: share-b ms-drbd1:Master
order share-a_after_ms-drbd0 inf: ms-drbd0:promote share-a:start
order share-a_after_ms-drbd1 inf: ms-drbd1:promote share-b:start
property $id="cib-bootstrap-options" \
	dc-version="1.0.8-042548a451fce8400660f6031f4da6f0223dd5dd" \
	cluster-infrastructure="Heartbeat" \
	stonith-enabled="false" \
	no-quorum-policy="ignore" \
	last-lrm-refresh="1284661245"

Test funzionale

Una volta montato da parte di un client lo share NFS:

# mount -t nfs 192.168.1.33:/share-a /mnt/

è possibile lanciare sempre sul client una copia arbitraria di file:

cp -av /usr/ /mnt/

partirà la copia dei file e sarà possibile agire quindi sul cluster, tenendo monitorato sia la copia che lo stato attraverso crm_mon.

Primo test: disconnessione cavo LAN nodo master

Alla disconnessione del cavo la risorsa ping avverte immediatamente l’assenza di connettività e forza la migrazione del gruppo share-a al nodo rimanente, in questo caso il debian-lenny-nodo1. Il tutto è osservabile dal file /var/log/syslog:

Sep 17 18:05:35 debian-lenny-nodo2 heartbeat: [1079]: info: Link debian-lenny-nodo1:eth0 dead.
...
Sep 17 18:05:46 debian-lenny-nodo2 kernel: [20384.996634] block drbd1: peer( Primary -> Secondary ) 
...
Sep 17 18:05:50 debian-lenny-nodo2 Filesystem[27581]: [27636]: INFO: Running start for /dev/drbd0 on /share-a
...
Sep 17 18:05:50 debian-lenny-nodo2 kernel: [20389.636665] EXT3-fs: mounted filesystem with ordered data mode.
...
Sep 17 18:05:51 debian-lenny-nodo2 exportfs[27676]: [27739]: INFO: File system exported
...
Sep 17 18:05:52 debian-lenny-nodo2 IPaddr2[27764]: [27817]: INFO: ip link set eth0 up
...

Lato client, la scrittura su NFS si ferma per qualche secondo e riparte appena l’ultima operazione di start è eseguita da Pacemaker.

Secondo test: migrazione manuale delle risorse

Lanciando il comando migrate sulla risorsa share-a viene forzato manualmente lo switch della risorsa dal nodo attuale al nodo indicato:

crm resource migrate share-a debian-lenny-nodo1

Quanto il cluster fa in questo genere di operazione è quello di modificare la stessa location descritta poco sopra:

# crm configure show
...
...
location cli-prefer-share-a share-a \
	rule $id="cli-prefer-rule-share-a" -inf: #uname eq debian-lenny-nodo1
...
...

In sostanza la location prima impostata su share-a è stata modificata da Pacemaker da inf a -inf invertendo il vincolo che legava la risorsa al nodo debian-lenny-nodo1.
E’ necessario porre particolare attenzione a questa regola, poiché il peso -inf implica che la risorsa sarà da qui in poi SEMPRE associata al nodo debian-lenny-nodo2, poiché non potrà più risiedere sul nodo originale.

Per ripristinare la situazione originaria e rimuovere la regola aggiunta esistono due modi:

1. Lanciare il comando precedente utilizzando unmigrate, in modo che la risorsa torni sul nodo originale (e la regola verrà cancellata, eliminando anche l’impostazione della configurazione originale);
2. Modificare a mano la configurazione del cluster attraverso il comando crm configure edit rimuovendo la linea aggiunta automaticamente, in modo da lasciare la risorsa dove si trova ora senza vincolarne i futuri spostamenti;

Lato client l’operazione è ancora più indolore di prima: dai log il comportamento è simile al precedente test e la scrittura sullo share NFS si ferma il tempo che la risorsa migra.

Terzo test: spegnimento improvviso nodo master

Lo spegnimento improvviso del nodo master rende il comportamento del cluster del tutto simile a quello illustrato primo test, con una differenza sostanziale:

...
Sep 17 18:36:37 debian-lenny-nodo2 heartbeat: [1079]: WARN: node debian-lenny-nodo1: is dead
...
Sep 17 18:36:37 debian-lenny-nodo2 crmd: [1120]: WARN: check_dead_member: Our DC node (debian-lenny-nodo1) left the cluster
...
Sep 17 18:36:37 debian-lenny-nodo2 kernel: [22236.912107] block drbd0: peer( Primary -> Unkno
wn ) conn( Connected -> NetworkFailure ) pdsk( UpToDate -> DUnknown ) 
...

Il cluster ha dovuto rimpiazzare il proprio DC (Designated Coordinator) poiché spento ed ovviamente il dispositivo drbd è in stato Primary sul nodo sopravvissuto, ma ovviamente in stato Unknown nella sua replica.

Anche in questo caso, lato client tutto si è svolto in maniera trasparente, la copia si è fermata per qualche secondo per poi ripartire.

Conclusioni

La soluzione illustrata descrive a pieno le potenzialità del progetto Pacemaker. E’ possibile combinare i suggerimenti espressi in questo lungo articolo immaginando di disporre di un cluster composto da più di due macchine, o segmentando ulteriormente le share esposte, creando ulteriori volumi logici e dispositivi drbd.
Il tutto con dei costi decisamente contenuti rispetto alle soluzioni NAS in commercio: in pratica il solo prezzo dell’hardware!
Bene, con quest’ultima parte la serie “Evoluzione dell’alta affidabilità su Linux” può dirsi conclusa. Sicuramente “Mia Mamma Usa Linux” tornerà su temi inerenti l’argomento, magari trattando l’integrazione delle tecniche di virtualizzazione nel cluster, utilizzando virtual machines come fossero risorse da migrare, magari senza necessità che i sistemi virtualizzati vengano spenti!
Commenti sulla serie sono ben accetti, suggerimenti su futuri argomenti anche di più, proposte di collaborazione sono in assoluto il meglio.
Lunga vita al software libero.

Nel precedente articolo è stata affrontata l’evoluzione del progetto Heartbeat, dalla versione iniziale in cui il supporto era limitato a due macchine e con un CRM (Cluster Resource Manager) dalle funzionalità ridotte, per arrivare all’evoluzione del progetto culminata in Pacemaker, il CRM avanzato con il quale è possibile specificare priorità, ordini e dipendenze delle risorse al fine di ottenere il controllo totale su quanto erogato dal cluster.
In questo nuovo articolo viene analizzata a fondo, con un esempio pratico, la configurazione delle due modalità operative di Heartbeat, al fine di effettuare un confronto sul funzionamento del cluster con e senza Pacemaker.

Versioni di Heartbeat ed installazione

Fino alla versione 3 il progetto Heartbeat era un unico monolite contenente tutte le componenti funzionali all’esecuzione del software. L’evoluzione del programma ha comportato la suddivisione dello stesso in sotto progetti, ciascuno sviluppato indipendentemente rispetto agli altri, ma critico per una specifica funzione all’interno dell’architettura cluster.
Ad oggi l’intero progetto Heartbeat è quindi suddiviso in tre componenti:

1. Heartbeat: comprendente il demone heartbeat, fornitore dell’infrastruttura cluster;
2. Cluster Glue: un insieme di librerie con scopi specifici:
   • LRM (Local Resource Manager): incaricato di ricevere le istruzioni dal CRM, passarle ai Resource Agents e riportarne l’esito;
   • STONITH (Shoot The Other Node In The Head): incaricato di gestire situazioni ambigue in cui una risorsa potrebbe essere utilizzata contemporaneamente da più nodi;
   • hb_report: incaricato di fornire dettagli sugli errori che si verificano nel sistema;
   • Cluster Plumbing Library:una libreria per la comunicazioni interne al cluster;
3. Resource Agents: comprendente un insieme di script standard per le risorse del cluster;

A ciascuna di queste componenti corrisponde un pacchetto scaricabile dalla sezione downloads del sito di Heartbeat: http://www.linux-ha.com/wiki/Downloads.
Le maggiori distribuzioni al momento distribuiscono ancora pacchetti di Heartbeat nelle versioni precedenti alla 3.
Scegliendo di utilizzare la versione più recente di ciascun software, è quindi possibile ricompilare manualmente i pacchetti partendo dai sorgenti oppure utilizzare pacchetti ricompilati.
Nel caso si usasse Debian Lenny è possibile dichiarare il seguente repository all’interno del file /etc/apt/sources.list:

deb http://people.debian.org/~madkiss/ha lenny main

Mentre per Ubuntu Hardy Heron i repository sono i seguenti:

deb http://ppa.launchpad.net/ubuntu-ha/ppa/ubuntu karmic main

Ubuntu Lucid Lynx supporta invece la versione più recente della suite Heartbeat.

Per l’installazione sarà quindi necessario utilizzare lo strumento di gestione pacchetti fornito con la propria distribuzione: apt per Debian ed Ubuntu, yast per SuSe/OpenSuse e yum per CentOS/RedHat.

L’esempio che verrà implementato nel corso dell’articolo prevede la messa in alta affidabilità di due servizi nelle due versioni di Heartbeat: un indirizzo IP ed il webserver apache2. Il presupposto da cui si partirà è quello di avere un cluster composto da due nodi, collegati ciascuno alla rete locale (192.168.1.0/24) e l’uno all’altro da un cavo cross (10.0.0.0/24).

Configurazione di Heartbeat in modalità classica (senza CRM)

Sebbene Heartbeat sia giunto ormai alla versione 3.0.3 ed il CRM sia stato introdotto dalla versione 2, la modalità predefinita con cui il software viene avviato è quella senza CRM.
Qualsiasi configurazione Heartbeat 1.x quindi funzionerà verosimilmente su tutte le versioni successive.
Al di là delle innovazioni a livello software apportate al progetto, il principio di funzionamento senza CRM rimane quindi invariato, così come i file di configurazione necessari al funzionamento del cluster, come illustrato nel precedente articolo.
Il primo di questi è /etc/ha.d/ha.cf, il cui contenuto dovrà essere simile a quanto segue (ed identico in entrambi i nodi):

##      keepalive: how long between heartbeats?
keepalive 1
##      deadtime: how long-to-declare-host-dead?
deadtime 10
##      warntime: how long before issuing "late heartbeat" warning?
warntime 5
##      Very first dead time (initdead)
initdead 20
##      What interfaces to unicast heartbeats over?
ucast eth1 10.0.0.1
ucast eth1 10.0.0.2
ucast eth0 192.168.1.86
ucast eth0 192.168.1.66
##      Should we autofailback?
auto_failback off
##      Who is part of the cluster?
node    debian-lenny-nodo1
node    debian-lenny-nodo2
##      Network monitoring
ping 192.168.1.50
respawn hacluster /usr/lib/heartbeat/ipfail
apiauth ipfail gid=haclient uid=hacluster

I commenti presenti all’interno del listato rendono le opzioni autoesplicative. Particolare attenzione va posta relativamente ad alcune opzioni:

auto_failback si riferisce alle risorse: se impostata ad “on” nel momento in cui una risorsa effettua uno switch su un nodo differente dall’attuale (per via di un malfunzionamento di quest’ultimo) nel momento in cui il nodo tornerà attivo la risorsa effettuerà un nuovo switch.

ping definisce un indirizzo ip che verrà usato come riferimento per capire se un nodo è parte della rete: “vedendo” l’indirizzo indicato il nodo avrà coscienza di essere presente sulla rete. A tutti gli effetti l’ip indicato è considerato un nodo del cluster, pertanto dovrà essere un ip affidabile, ad esempio quello del gateway di rete. E’ inoltre possibile definire un gruppo di ip, attraverso la direttiva ping_group in modo da non affidarsi ad un unico host per il monitoring.

respawn e apiauth definiscono rispettivamente un comando e l’utente con cui questo deve essere lanciato. Insieme alla definizione del nodo ping completano la parte di monitoraggio della connettività necessaria ad Heartbeat per regolarsi in caso di connettività limitata od assente.

Le ultime tre opzioni descritte, come apparirà chiaro in seguito, risultano di importanza critica in configurazioni senza CRM.

Il secondo file essenziale alla costruzione del cluster è /etc/ha.d/haresources:

debian-lenny-nodo1 IPaddr::192.168.1.200/24/eth0 apache2

Il contenuto definisce il nodo master per le due risorse definite: l’indirizzo ip 192.168.1.200 (associato all’interfaccia eth0) e apache2, il demone che controlla il webserver. Entrambe le risorse verranno quindi, in condizioni normali, avviate sul nodo identificato come debian-lenny-nodo1.

L’ultimo file ad essere creato è /etc/ha.d/authkeys e contiene le informazioni per la sicurezza delle comunicazioni tra i due nodi. Non essendo vincolante ai fini del progetto avere una comunicazione criptata tra i nodi, il contenuto del file può essere il seguente:

auth 1
1 crc

Che sta ad indicare come non esisterà sicurezza nella comunicazione fra i nodi (eccettuato il controllo sulla corruzione dei pacchetti).

Prima di avviare il demone per la prima volta ed effettuare i test è necessario accertarsi che il demone apache non venga avviato al boot del sistema, poiché verrà gestito da heartbeat. In Debian/Ubuntu si può rimuovere così:

# update-rc.d -f apache2 remove

Mentre in RedHat/Centos/Opensuse il comando da usare è chkconfig:

# chkconfig --level 123456 apache2 off

A questo punto è possibile avviare su entrambi i nodi il demone heartbeat:

# /etc/init.d/heartbeat start

dopo alcuni minuti i servizi dovrebbero salire sul nodo che secondo quanto impostato nella configurazione sarà master, debian-lenny-nodo1. Il tutto è verificabile attraverso il controllo sullo stato dell’interfaccia eth0:0:

# ifconfig eth0:0
eth0:0    Link encap:Ethernet  HWaddr 08:00:27:59:18:22  
          inet addr:192.168.1.200  Bcast:192.168.1.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          Interrupt:10 Base address:0xd020

E sull’effettiva esecuzione del demone apache2:

# ps -ef| grep apache
root      2052     1  0 11:30 ?        00:00:00 /usr/sbin/apache2 -k start
www-data  2053  2052  0 11:30 ?        00:00:00 /usr/sbin/apache2 -k start
www-data  2054  2052  0 11:30 ?        00:00:00 /usr/sbin/apache2 -k start
www-data  2057  2052  0 11:30 ?        00:00:00 /usr/sbin/apache2 -k start

Test di Heartbeat in modalità classica (senza CRM)

Il comportamento nelle varie situazione del demone heartbeat è osservabile attraverso il principale file di log di sistema, su entrambi i nodi:

tail -f /var/log/syslog

Primo test: disconnessione cavo LAN

Il primo test riguarderà la disconnessione del cavo di rete LAN relativo al nodo master, l’operazione genererà alcune righe di log, la più importante delle quali, sull’unico nodo rimasto attivo in rete, riporterà quanto segue:

...
ResourceManager[14403]: [14415]: info: Acquiring resource group: debian-lenny-nodo1 IPaddr::192.168.1.200/24/eth0 apache2
...

l’indicazione è chiara: le risorse sono state acquisite dal nodo secondario. A rilevare l’assenza di connettività è stato, come precedentemente illustrato, l’esegubile ipfail.

Secondo test: disconnessione cavo Heartbeat

Il secondo test prevede la rimozione del cavo che collega i due nodi del cluster:

...
Apr  8 16:24:16 debian-lenny-nodo1 kernel: [17722.012482] eth1: link down
Apr  8 16:24:25 debian-lenny-nodo1 heartbeat: [14269]: info: Link debian-lenny-nodo2:eth1 dead.
Apr  8 16:24:25 debian-lenny-nodo1 ipfail: [14297]: info: Link Status update: Link debian-lenny-nodo2/eth1 now has status dead
Apr  8 16:24:25 debian-lenny-nodo1 ipfail: [14297]: debug: Found ping node 192.168.1.50!
Apr  8 16:24:26 debian-lenny-nodo1 ipfail: [14297]: info: Asking other side for ping node count.
Apr  8 16:24:26 debian-lenny-nodo1 ipfail: [14297]: debug: Message [num_ping] sent.
Apr  8 16:24:26 debian-lenny-nodo1 ipfail: [14297]: info: Checking remote count of ping nodes.
Apr  8 16:24:27 debian-lenny-nodo1 ipfail: [14297]: debug: Got asked for num_ping.
Apr  8 16:24:27 debian-lenny-nodo1 ipfail: [14297]: debug: Found ping node 192.168.1.50!
Apr  8 16:24:28 debian-lenny-nodo1 ipfail: [14297]: info: Ping node count is balanced.
Apr  8 16:24:28 debian-lenny-nodo1 ipfail: [14297]: debug: Abort message sent.
Apr  8 16:24:28 debian-lenny-nodo1 ipfail: [14297]: info: No giveup timer to abort.
...

I messaggi riguardano l’interfaccia secondaria e, come è osservabile, la perdita di questa interfaccia non provoca alcun tipo di switch, in quanto la comunicazione tra i nodi funziona ancora attraverso l’interfaccia primaria, quindi attraverso la LAN.

Terzo test: spegnimento improvviso nodo master

Il terzo test consiste nella rimozione improvvisa dell’alimentazione relativa al nodo master:

Apr  8 16:24:16 debian-lenny-nodo2 heartbeat: [8170]: WARN: node debian-lenny-nodo1: is dead
Apr  8 16:24:16 debian-lenny-nodo2 ipfail: [8233]: info: Status update: Node debian-lenny-nodo1 now has status dead
...
...
Apr  8 16:24:16 debian-lenny-nodo2 ResourceManager[8913]: [8925]: info: Acquiring resource group: debian-lenny-nodo1 IPaddr::192.168.1.200/24/eth0 apache2
Apr  8 16:24:17 debian-lenny-nodo2 ipfail: [8233]: debug: Found ping node 192.168.1.50!
Apr  8 16:24:17 debian-lenny-nodo2 IPaddr[8937]: [8972]: INFO:  Resource is stopped
Apr  8 16:24:17 debian-lenny-nodo2 ResourceManager[8913]: [8987]: info: Running /etc/ha.d/resource.d/IPaddr 192.168.1.200/24/eth0 start
Apr  8 16:24:17 debian-lenny-nodo2 ipfail: [8233]: info: NS: We are still alive!
...
...

Lo switch avviene in maniera corretta, è possibile notare il messaggio “We are still alive!” che indica come il nodo secondario abbia rilevato che il nodo primario sia assente, acquisendone le risorse, una volta accertato il proprio grado di connettività con la rete.

Quarto test: migrazione manuale delle risorse

Heartbeat dispone di un ristretto set di comandi che consentono di interagire con le risorse. Questi comandi sono contenuti nella cartella /usr/share/heartbeat/, ed il comando che consente di gestire le risorse dichiarate è hb_takeover, la cui sintassi d’impiego è la seguente:

# /usr/share/heartbeat/hb_standby all|foreign|local|failback

I parametri passabili al comando comprendono la possibilità da parte di un nodo di acquisire tutte le risorse (all), le risorse del nodo secondario (foreign), le risorse di proprietà (local), le risorse precedentemente migrate (failback).
Nel caso che si vuole simulare il nodo secondario lancerà il seguente comando:

# /usr/share/heartbeat/hb_standby foreign

Ed il comportamento del cluster, osservabile dal nodo primario, sarà il seguente:

Apr  8 16:28:36 debian-lenny-nodo1 heartbeat: [14269]: info: debian-lenny-nodo1 wants to go standby [local]
Apr  8 16:28:36 debian-lenny-nodo1 heartbeat: [14269]: info: standby: debian-lenny-nodo2 can take our local resources
Apr  8 16:28:36 debian-lenny-nodo1 heartbeat: [14859]: info: give up local HA resources (standby).
Apr  8 16:28:36 debian-lenny-nodo1 ResourceManager[14872]: [14884]: info: Releasing resource group: debian-lenny-nodo1 IPaddr::192.168.1.200/24/eth0 apache2
Apr  8 16:28:36 debian-lenny-nodo1 ResourceManager[14872]: [14895]: info: Running /etc/init.d/apache2  stop
Apr  8 16:28:38 debian-lenny-nodo1 ResourceManager[14872]: [14929]: info: Running /etc/ha.d/resource.d/IPaddr 192.168.1.200/24/eth0 stop
Apr  8 16:28:38 debian-lenny-nodo1 IPaddr[14956]: [14968]: INFO: ifconfig eth0:0 down
Apr  8 16:28:38 debian-lenny-nodo1 IPaddr[14930]: [14972]: INFO:  Success

Le risorse sono state correttamente spostate su debian-lenny-nodo2.

Quinto test: standby manuale di un nodo

Il quinto test della serie prevederà la messa in standby del nodo attivo, al fine di verificare il corretto spostamento delle risorse. Il controllo di questa funzionalità da parte del cluster è possibile mediante lo stesso comando precedentemente illustrato, lanciato senza argomenti (che equivale a lanciarlo parametro “all”) sul secondo nodo:

# /usr/share/heartbeat/hb_standby

Il comportamento è il seguente:

Apr  8 16:29:48 debian-lenny-nodo1 heartbeat: [14269]: info: debian-lenny-nodo2 wants to go standby [all]
Apr  8 16:29:49 debian-lenny-nodo1 ipfail: [14297]: debug: Other side is unstable.
Apr  8 16:29:51 debian-lenny-nodo1 heartbeat: [14269]: info: standby: acquire [all] resources from debian-lenny-nodo2
Apr  8 16:29:51 debian-lenny-nodo1 heartbeat: [14974]: info: acquire all HA resources (standby).
Apr  8 16:29:51 debian-lenny-nodo1 ResourceManager[14987]: [14999]: info: Acquiring resource group: debian-lenny-nodo1 IPaddr::192.168.1.200/24/eth0 apache2
Apr  8 16:29:52 debian-lenny-nodo1 IPaddr[15011]: [15046]: INFO:  Resource is stopped
Apr  8 16:29:52 debian-lenny-nodo1 ResourceManager[14987]: [15061]: info: Running /etc/ha.d/resource.d/IPaddr 192.168.1.200/24/eth0 start
Apr  8 16:29:53 debian-lenny-nodo1 IPaddr[15088]: [15121]: INFO: Using calculated netmask for 192.168.1.200: 255.255.255.0
Apr  8 16:29:53 debian-lenny-nodo1 IPaddr[15088]: [15143]: INFO: eval ifconfig eth0:0 192.168.1.200 netmask 255.255.255.0 broadcast 192.168.1.255
Apr  8 16:29:53 debian-lenny-nodo1 IPaddr[15062]: [15162]: INFO:  Success
Apr  8 16:29:53 debian-lenny-nodo1 ResourceManager[14987]: [15183]: info: Running /etc/init.d/apache2  start

Tutte le risorse vengono acquisite dal nodo debian-lenny-nodo2.

Sesto test: interruzione manuale di un servizio

L’ultimo test della serie comprende lo stop manuale di uno dei servizi erogati. Ad esempio apache:

# /etc/init.d/apache2 stop

è facile verificare come nessuna azione venga svolta da Heartbeat, il servizio infatti rimane spento, e l’unica via per fare in modo che il cluster lo riavvii è quella di mandare in standby manualmente il nodo.

Gli ultimi tre test mostrano come in realtà il controllo manuale del cluster sia unicamente la simulazione della messa in standby di un nodo o lo stop di un servizio attivo. Lo standby non avviene in maniera totale, il nodo non viene escluso dal cluster, semplicemente rilascia le proprie risorse e lo stesso vale per i servizi.
Quanto descritto rappresenta una grossa differenza nei confronti dell’utilizzo del CRM Pacemaker, ed il concetto sarà ancora più chiaro nei paragrafi successivi.

Configurazione di Heartbeat in modalità CRM con Pacemaker

L’esecuzione di Heartbeat in modalità CRM prevede che nel sistema sia installato il pacchetto Pacemaker. Questo pacchetto è disponibile nelle maggiori distribuzioni (e nei repository indicati nel primo capitolo dell’articolo) e tra le varie librerie e file che installa uno su tutti sarà fondamentale nel proseguo dell’articolo: /usr/sbin/crm. Come verrà illustrato in seguito il comando crm consente di interagire direttamente con il cluster, il suo comportamento e la sua configurazione.
Prima di procedere è necessario predisporre nuovamente il file di configurazione /etc/ha.d/ha.cf con questo contenuto, su entrambi i nodi:

autojoin none
keepalive 1
deadtime 10
warntime 5
initdead 20
mcast eth0 239.0.0.43 694 1 0
bcast eth1
node    debian-lenny-nodo1
node    debian-lenny-nodo2
crm respawn

Le differenze con la precedente configurazione sono subito evidenti. Esiste una nuova opzione chiamata autojoin none che disabilita la funzione automatica di scoperta ed aggiunta di nodi sulla rete, inoltre sono state modificate le informazioni relative alla rete: non viene più definito un unicast per ciascuna interfaccia interessate alla comunicazione del cluster, i pacchetti viaggeranno in multicast per la rete locale ed in broadcast per la rete non condivisa (il cavo cross che collega le due macchine).
Infine, l’opzione crm respawn indica che il cluster userà il Cluster Resource Manager, Pacemaker.
Va sottolineato come siano assenti i parametri relativi al monitoraggio della connettività, che verrà gestita in maniera totale da Pacemaker.
E’ chiaro come in questa configurazione il file /etc/ha.d/haresources non ha più ragione di esistere in quanto, così come spiegato nel precedente articolo, a preoccuparsi della gestione delle risorse è il CRM stesso.
Il file relativo al protocollo di comunicazione e sicurezza /etc/ha.d/authkeys rimane invece identico.

E’ quindi possibile avviare Heartbeat per la prima volta:

# /etc/init.d/heartbeat start

Le fasi di avvio sono visibili attraverso il log, oppure utilizzando il già citato comando crm con il parametro status.
Inizialmente lo stato del cluster sarà il seguente:

# crm status
============
Last updated: Wed Jun 16 11:34:38 2010
Current DC: NONE
0 Nodes configured, unknown expected votes
0 Resources configured.
============

Dopo qualche minuto, una volta che i nodi avranno avviato le comunicazioni la situazione varierà in questa forma:

# crm status
============
Last updated: Wed Jun 16 11:35:48 2010
Stack: Heartbeat
Current DC: debian-lenny-nodo2 (e1f7faf3-7152-4c51-bfc4-b5382944a62e) - partition with quorum
Version: 1.0.8-2c98138c2f070fcb6ddeab1084154cffbf44ba75
2 Nodes configured, unknown expected votes
0 Resources configured.
============
 
Online: [ debian-lenny-nodo1 debian-lenny-nodo2 ]

Il cluster può dirsi così avviato. Sebbene non ci siano risorse configurate (“0 Resources configured.“) i due nodi configurati risultano “Online”, pronti cioè ad erogare risorse e debian-lenny-nodo2 ha il ruolo di DC, Designated Coordinator, il nodo “master” che guiderà cioè le operazioni.

Qualsiasi tipo di configurazione sul cluster può essere effettuata attraverso il comando crm, mediante il parametro configure seguito dalle impostazioni da modificare.
Di seguito in quattro fasi viene illustrata una configurazione che rispetti fedelmente quanto fatto per la versione senza CRM.

Prima fase: comportamento generale del cluster

# crm configure property stonith-enabled="false"

Disabilitazione dello stonith: come anticipato in apertura di articolo, lo stonith prevede la configurazione di device specifici che possano essere guidati al fine di spegnere immediatamente un nodo in situazioni in cui non si ha la certezza di quale nodo sia ancora vivo. Nel caso illustrato la configurazione dello stonith verrà pertanto disabilitato.
Una interessante documentazione su come configurare lo stonith su Heartbeat è disponibile sul sito Novell, a
questo indirizzo.

# crm configure property no-quorum-policy="ignore"

Non considerazione dell’assenza di quorum: se la locazione comune dei dati relativi al cluster (quorum) non sarà accessibile da parte dei nodi, il cluster non dovrà prendere alcun provvedimento. Le opzioni disponibili sono ignore, stop, freeze e suicide.
Il valore stop porterà il cluster a fermare ordinatamente tutte le risorse.
Il valore freeze consentirà al cluster di continuare ad erogare le risorse in esecuzione senza però avviarne di nuove.
Il valore suicide obbligherà il cluster a spegnere immediatamente tutti i nodi con limitato accesso al quorum.

Chiaramente le due opzioni stonith-enabled e no-quorum-policy non vengono considerate nella configurazione classica. Il concetto di quorum e stonith si applica solo a cluster gestiti da CRM, in cui esiste una memoria comune.

Seconda fase: controllo della connettività

Il controllo della connettività con Pacemaker è possibile attraverso la definizione di una risorsa denominata “ping”:

# crm configure primitive ping ocf:pacemaker:ping params host_list="192.168.1.1" name="ping" op monitor interval="10s" timeout="60s" op start timeout="60s" op stop timeout="60s"

Il comando crea una risorsa (primitive) denominata ping, il cui Resource Agent (RA) è di tipo ocf, fornito da pacemaker: il path effettivo dell’eseguibile sarà quindi /usr/lib/ocf/resource.d/pacemaker/ping (si veda l’articolo precedente per l’approfondimento sulle tipologie di resource agent e loro posizionamento).
Il RA supporta diversi parametri, fra questi host_list deve contenere la lista degli host da controllare per verificare la connettività (in questo caso il gateway di rete) e name dovrà corrispondere al nome interno della risorsa (si veda la quarta fase).
Infine le indicazioni che seguono le voci “op” (abbreviazione di operations) consentono di definire le politiche di monitoring della risorsa: come deve essere controllata (ad intervalli di 10 secondi e con 60 secondi di timeout) ed in quanto tempo si deve avviare e fermare (entro i 60 secondi di timeout).

La definizione della risorsa ping non è però sufficiente per fornire ad ogni nodo uno strumento per il controllo della connettività, poiché, definita nel modo indicato, la risorsa ping verrà eseguita su un unico nodo. Proprio per ovviare a questo problema e fare in modo che la stessa risorsa possa girare su più nodi è possibile clonarla:

# crm configure clone ping_clone ping meta globally-unique="false"

Il comando indica al cluster di creare la risorsa ping_clone che girerà su tutti i nodi, indistintamente (meta globally-unique=”false”).

Terza fase: definizione delle risorse

Per riprodurre il test e confrontarlo con il precedente rimangono da definire le due risorse scelte ip e apache. La risorsa ip verrà dichiarata come segue:

# crm configure primitive cluster-ip ocf:heartbeat:IPaddr2 params ip="192.168.1.200" nic="eth0" op monitor interval="10s" timeout="20s" op start timeout="20s" op stop timeout="20s"

il nome della risorsa è cluster-ip ed il resource agent utilizzato sarà di tipo OCF, con fornitore heartbeat.
I parametri comprendono l’indirizzo ip che verrà erogato ed il nic (la scheda di rete) a cui verrà associato.
Per quanto riguarda le politiche di monitoring vale quanto detto poco sopra per la risorsa ping.

Il servizio apache2 verrà dichiarato in maniera similare:

crm configure primitive cluster-apache2 ocf:heartbeat:apache params configfile="/etc/apache2/apache2.conf" httpd="/usr/sbin/apache2" port="80" op monitor interval="10s" timeout="60s" op start timeout="40s" op stop timeout="60s"

E’ da notare che il Resource Agent utilizzato non è, come per la configurazione di Heartbeat senza CRM, lo script di avvio del demone presente in /etc/init.d, ma un vero e proprio resource agent di tipo OCF. I parametri necessari al funzionamento sono il file di configurazione (configfile), l’eseguibile del demone (httpd) e la porta su cui apache sarà in ascolto (port).
Anche in questo caso per le opzioni di monitoring vale quanto espresso in precedenza.

Per completare la configurazione delle risorse verrà definito un gruppo, denominato cluster, a cui verranno associate le risorse definite:

# crm configure group cluster cluster-ip cluster-apache2

Il gruppo cluster potrà essere utilizzato nella configurazione come un unica risorsa, le cui operazioni di avvio e stop rispetteranno l’ordine indicato nella definizione: in fase di start del gruppo cluster verrà avviato prima cluster-ip e poi cluster-apache2, in fase di stop verrà prima stoppato cluster-apache2 e poi cluster-ip.

Quarta fase: associazione delle risorse al nodo attivo

La configurazione del cluster, definiti i parametri di monitoraggio della connessione ed il gruppo delle risorse, potrebbe sembrare a questo punto completa:

# crm status
============
Last updated: Wed Jun 16 15:36:43 2010
Stack: Heartbeat
Current DC: debian-lenny-nodo2 (e1f7faf3-7152-4c51-bfc4-b5382944a62e) - partition with quorum
Version: 1.0.8-2c98138c2f070fcb6ddeab1084154cffbf44ba75
2 Nodes configured, unknown expected votes
2 Resources configured.
============
 
Online: [ debian-lenny-nodo1 debian-lenny-nodo2 ]
 
 Clone Set: ping_clone
     Started: [ debian-lenny-nodo1 debian-lenny-nodo2 ]
 Resource Group: cluster
     cluster-ip	(ocf::heartbeat:IPaddr2):	Started debian-lenny-nodo1
     cluster-apache2	(ocf::heartbeat:apache):	Started debian-lenny-nodo1

Ma non è così. E’ vero che al momento il cluster eroga quanto stabilito, ma non è ancora stato definito il comportamento da assumere in caso di assenza di connettività. Se infatti si dovesse rimuovere il cavo di rete LAN dal nodo debian-lenny-nodo1 le risorse non verrebbero automaticamente migrate sul secondo nodo.
Questo perché il cluster non è istruito a dovere in merito al comportamento da assumere a fronte di un esito negativo delle operazioni effettuate dalla risorsa clonata ping.
Quanto descritto rappresenta un’altra grossa differenza tra le due tipologie di funzionamento: in un caso la definizione di ipfail forzava lo standby delle risorse in autonomia (e minor controllo), con Pacemaker la filosofia cambia: tutto va definito, aggiungendo certamente complessità all’architettura, ma rendendo il controllo sul cluster totale.
Per definire quindi un vincolo sull’erogazione delle risorse è necessario definire una “location”:

# crm configure location cluster_on_connected_node cluster rule -inf: not_defined ping or ping lte 0

Viene definita cioè una regola denominata cluster_on_connected_node associata alla risorsa cluster che prevede di dare il peso di meno infinito (-inf, rendere cioè incapace di erogare risorse) al nodo in cui la risorsa nominata ping non sia definita (not_defined) o il cui codice di uscita sia minore o uguale a zero (lte 0 e quindi il comando ping non ha avuto esito positivo, il ping node non risponde).

Grazie a questa regola la struttura realizzata con Heartbeat e Pacemaker risulta l’esatta replica della soluzione Heartbeat senza CRM per comportamento e configurazione.

La configurazione completa

E’ possibile ottenere il resoconto della configurazione, completo di highlight attraverso il comando crm configure show:

# crm configure show
node $id="1984521f-539f-4967-b0ff-eb23f3cf9ccf" debian-lenny-nodo1
node $id="e1f7faf3-7152-4c51-bfc4-b5382944a62e" debian-lenny-nodo2
primitive cluster-apache2 ocf:heartbeat:apache \
	params configfile="/etc/apache2/apache2.conf" httpd="/usr/sbin/apache2" port="80" \
	op monitor interval="10s" timeout="60s" \
	op start interval="0" timeout="40s" \
	op stop interval="0" timeout="60s"
primitive cluster-ip ocf:heartbeat:IPaddr2 \
	params ip="192.168.1.200" nic="eth0" \
	op monitor interval="10s" timeout="20s" \
	op start interval="0" timeout="20s" \
	op stop interval="0" timeout="20s"
primitive ping ocf:pacemaker:ping \
	params host_list="192.168.1.1" name="ping" \
	op stop interval="0" timeout="60s" \
	op start interval="0" timeout="60s" \
	op monitor interval="10s" timeout="60s"
group cluster cluster-ip cluster-apache2
clone ping_clone ping \
	meta globally-unique="false"
location cluster_on_connected_node cluster \
	rule $id="cluster_on_connected_node-rule" -inf: not_defined ping or ping lte 0
property $id="cib-bootstrap-options" \
	dc-version="1.0.8-2c98138c2f070fcb6ddeab1084154cffbf44ba75" \
	cluster-infrastructure="Heartbeat" \
	stonith-enabled="false" \
	no-quorum-policy="ignore" \
	last-lrm-refresh="1276694458"

E’ da notare che oltre ad essere un comando invocabile con specifiche opzioni, crm può essere lanciato senza argomenti, in modo da accedere alla console di amministrazione interattiva che permette di controllare il cluster su tutti i livelli. Ad esempio digitando in sequenza:

# crm
crm(live)# configure
crm(live)configure# edit

Si accederà alla configurazione riportata sopra all’interno dell’editor di testo vi, questa configurazione potrà essere modificata a piacimento e salvata attraverso il comando vi “:wq”.
Le modifiche verranno applicate digitando:

crm(live)configure# commit

L’interfaccia analizzerà quanto digitato ed applicherà alla configurazione effettiva del cluster le modifiche, ovviamente se e soltanto se queste rispettano la sintassi e la struttura del cluster.

Test di Heartbeat in modalità CRM con Pacemaker

Anche nella configurazione con Pacemaker il comportamento di Heartbeat è osservabile dal file di log di sistema /var/log/syslog. La quantità di log relativa a questa configurazione di Heartbeat è decuplicata rispetto alla configurazione classica, il che rende a volte complicato seguire quanto avviene nel cluster. Un buon approccio in caso di disservizi o comportamenti divergenti da quanto ci si aspetta è quello di cercare parole chiave come “error” o “warning” in modo da evidenziare subito potenziali problemi.

Primo test: disconnessione cavo LAN

Il comportamento di Heartbeat nei confronti della disconnessione del cavo LAN è il seguente (vengono riportate solo alcune righe del log del nodo attivo):

Jun 17 17:11:42 debian-lenny-nodo1 attrd: [2426]: info: attrd_trigger_update: Sending flush op to all hosts for: ping (0)
...
Jun 17 17:11:43 debian-lenny-nodo1 lrmd: [2424]: info: rsc:cluster-apache2:16: stop
...
Jun 17 17:11:46 debian-lenny-nodo1 lrmd: [2424]: info: rsc:cluster-ip:17: stop
...
Jun 17 17:11:49 debian-lenny-nodo1 lrmd: [2424]: info: perform_op:2873: operation monitor[11] on ocf::ping::ping:1 for client 2427, its parameters: CRM_meta_clone=[1] host_list=[192.168.1.1]

Il nodo attivo segnala di aver perso connettività (leggendo la risposta del comando clonato ping) e procede con lo stop delle due risorse interessate (che verranno attivate sul nodo secondario, ovviamente se questo ha connettività).
Il nodo debian-lenny-nodo1 continua a tentare la connessione al nodo ping.
Da notare che debian-lenny-nodo1 non viene in alcuna maniera escluso dal cluster poiché l’interfaccia Heartbeat (il cavo che collega fra loro le due macchine) è attiva, garantendo la comunicazione dei due nodi.

Secondo test: disconnessione cavo Heartbeat

La rimozione del cavo heartbeat, così come il secondo test di Heartbeat senza CRM, non comporta alcuna variazione nello stato del cluster:

Jun 18 10:57:12 debian-lenny-nodo1 kernel: [ 3020.112982] eth1: link down
Jun 18 10:57:20 debian-lenny-nodo1 heartbeat: [11076]: info: Link debian-lenny-nodo2:eth1 dead.

Viene unicamente rilevata (sia dal kernel che da heartbeat) l’assenza di connettività sull’interfaccia eth1, ma la comunicazione del cluster è ancora garantita dal link eth0.

Terzo test: spegnimento improvviso nodo master

Ecco cosa avviene all’atto di spegnimento improvviso del nodo erogante i servizi:

1
2
3
4
5
6
7
8
9
10
11
12
13

Jun 18 11:00:44 debian-lenny-nodo1 heartbeat: [11076]: WARN: node debian-lenny-nodo2: is dead
Jun 18 11:00:44 debian-lenny-nodo1 heartbeat: [11076]: info: Link debian-lenny-nodo2:eth0 dead.
Jun 18 11:00:44 debian-lenny-nodo1 heartbeat: [11076]: info: Link debian-lenny-nodo2:eth1 dead.
...
Jun 18 11:00:45 debian-lenny-nodo1 crmd: [11091]: WARN: check_dead_member: Our DC node (debian-lenny-nodo2) left the cluster
...
Jun 18 11:00:48 debian-lenny-nodo1 crmd: [11091]: info: do_dc_takeover: Taking over DC status for this partition
...
Jun 18 11:00:53 debian-lenny-nodo1 pengine: [12660]: notice: unpack_config: On loss of CCM Quorum: Ignore
...
Jun 18 11:00:53 debian-lenny-nodo1 lrmd: [11088]: info: rsc:cluster-ip:13: start
...
Jun 18 11:00:53 debian-lenny-nodo1 lrmd: [11088]: info: rsc:cluster-apache2:15: start

In sequenza quanto avviene sul nodo sopravvissuto è:

• linea 1,2,3) Rilevazione della perdita di connettività totale con l’altro nodo;
• linea 5) Rilevazione della perdita di DC;
• linea 7) Presa i carico da parte del nodo attuale del ruolo di DC;
• linea 9) Come da configurazione l’assenza di quorum viene ignorata;
• linea 11,13) Avvio dei servizi;

Il nodo debian-lenny-nodo1 ha quindi preso in carico la totalità delle risorse, in maniera automatica.

Quarto test: migrazione manuale delle risorse

La migrazione manuale delle risorse è possibile sempre attraverso l’utilizzo del comando crm:

1

# crm resource migrate cluster debian-lenny-nodo2

In questo caso, il gruppo di risorse cluster viene migrato dal nodo attuale al nodo debian-lenny-nodo2: è possibile migrare indistintamente un gruppo o una singola risorsa, ma se questa fa parte del gruppo, allora tutto il gruppo verrà migrato.
La migrazione della risorsa genera automaticamente un’aggiunta nella configurazione del cluster di questo tipo:

location cli-prefer-cluster cluster \
	rule $id="cli-prefer-rule-cluster" inf: #uname eq debian-lenny-nodo2

il cui scopo è chiaro: la regola infatti indica al cluster di dare priorità inf (ossia infinità) all’esecuzione della risorsa cluster sul nodo il cui comando uname equivale a debian-lenny-nodo2. Non a caso, la regola viene automaticamente battezzata “cli-prefer-cluster”. Va chiarito che sebbene il peso della regola sia infinito, questa decade in caso il nodo preferito smetta di funzionare.
E’ possibile ripristinare la migrazione attraverso il comando inverso:

# crm resource unmigrate cluster

Tale operazione ripristinerà la situazione precedente, rimuovendo la regola aggiunta all’interno della configurazione.

Quinto test: standby manuale di un nodo

Anche la messa in standby di un nodo è effettuabile attraverso il comando crm:

# crm node standby debian-lenny-nodo1

Lo stato del cluster al termine di questa operazione sarà quindi il seguente:

...
Node debian-lenny-nodo1 (1984521f-539f-4967-b0ff-eb23f3cf9ccf): standby
Online: [ debian-lenny-nodo2 ]
 
 Clone Set: ping_clone
     Started: [ debian-lenny-nodo2 ]
     Stopped: [ ping:0 ]
 Resource Group: cluster
     cluster-ip (ocf::heartbeat:IPaddr2):       Started debian-lenny-nodo2
     cluster-apache2    (ocf::heartbeat:apache):        Started debian-lenny-nodo2

Le risorse vengono correttamente migrate sul nodo secondario ed il nodo primario viene messo in stato “standby”. Per ripristinare la situazione è sufficiente anche in questo caso forzare debian-lenny-nodo1 a tornare online:

# crm node online debian-lenny-nodo1

Sesto test: interruzione manuale di un servizio

L’ultimo test della serie prevede l’interruzione manuale di un servizio. Verrà simulato il crash del servizio apache2 tramite un comando kill, Il presupposto è che il servizio apache2 sia in esecuzione su debian-lenny-nodo1:

# killall apache2

Ecco le operazioni che il cluster esegue per porre rimedio alla situazione:

1
2
3
4
5

Jun 18 11:29:21 debian-lenny-nodo1 apache[24129]: [24187]: INFO: apache not running
...
Jun 18 11:29:21 debian-lenny-nodo1 crmd: [11091]: WARN: update_failcount: Updating failcount for cluster-apache2 on debian-lenny-nodo1 after failed monitor: rc=7 (update=value++, time=1276853361)
...
Jun 18 11:29:22 debian-lenny-nodo1 lrmd: [11088]: info: rsc:cluster-apache2:45: start

In sequenza quello che avviene è:

• linea 1) Il monitor ha rilevato che il servizio non sta funzionando;
• linea 3) Pacemaker aggiorna il conteggio dei disservizi relativi alla risorsa cluster-apache2;
• linea 5) La risorsa viene nuovamente eseguita;

La risorsa è di nuovo attiva e funzionante.

E’ possibile monitorare in maniera costante lo stato del cluster attraverso il comando crm_mon il cui funzionamento consiste nell’esecuzione del comando crm status ad intervalli regolari. crm_mon supporta il parametro –failcount che permette di avere un sommario dei disservizi rilevati sul cluster. Nell’esempio illustrato, l’output del comando sarà il seguente:

...
Online: [ debian-lenny-nodo1 debian-lenny-nodo2 ]
 
 Clone Set: ping_clone
     Started: [ debian-lenny-nodo1 debian-lenny-nodo2 ]
 Resource Group: cluster
     cluster-ip (ocf::heartbeat:IPaddr2):       Started debian-lenny-nodo1
     cluster-apache2    (ocf::heartbeat:apache):        Started debian-lenny-nodo1
 
Migration summary:
* Node debian-lenny-nodo1: 
   ping:0: migration-threshold=1000000 fail-count=1
   cluster-apache2: migration-threshold=1000000 fail-count=1
* Node debian-lenny-nodo2:

Il Migration summary presenta la situazione relativa alle risorse intaccate dai nostri test, il cui conteggio dei disservizi è 1 (fail-count=1).
E’ possibile azzerare tale conteggio effettuando un cleanup della risorsa:

# crm resource cleanup cluster-apache2
Cleaning up cluster-apache2 on debian-lenny-nodo1
Cleaning up cluster-apache2 on debian-lenny-nodo2

Conclusioni

Giunti al termine di questo lunghissimo articolo le conclusioni da trarre sono molteplici. La prima di queste è che l’argomento Heartbeat/Pacemaker risulta tutt’altro che esaurito: esistono moltissime altre componenti del progetto che qui non sono state nemmeno accennate. Certo è che da questo confronto balza subito all’occhio come le differenze tra i due tipi di impiego siano sostanziali. La soluzione Heartbeat/Pacemaker sebbene sia evidentemente complicata offre un controllo insperato su tutte le componenti del cluster, oltre ad un monitoraggio costante di tutte le risorse configurate. L’implementazione della soluzione classica è immediata, ma come si è visto limitata.
La scelta su quale sia la scelta migliore per la propria infrastruttura è unicamente dell’utente, che come sempre nel mondo OpenSource è libero di scegliere, sperimentare e realizzare.
Nel prossimo articolo verrà presentata una soluzione Heartbeat/Pacemaker per implementare uno Storage NFS Active/Active basato su DRBD.

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:

Figura 1

passando dal supporto di più nodi:

Figura 2

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

Figura 3

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.