Mia mamma usa Linux! » Linux HA http://www.miamammausalinux.org Perché niente è impossibile da capire... Se lo spieghi bene ! Tue, 27 Jul 2010 12:03:21 +0000 en hourly 1 http://wordpress.org/?v=3.0.1 Evoluzione dell’alta affidabilità su Linux: confronto pratico tra Heartbeat classico ed Heartbeat con Pacemaker http://www.miamammausalinux.org/2010/06/evoluzione-dellalta-affidabilita-su-linux-confronto-pratico-tra-heartbeat-classico-ed-heartbeat-con-pacemaker/ http://www.miamammausalinux.org/2010/06/evoluzione-dellalta-affidabilita-su-linux-confronto-pratico-tra-heartbeat-classico-ed-heartbeat-con-pacemaker/#comments Mon, 21 Jun 2010 07:00:44 +0000 Raoul Scarazzini http://www.miamammausalinux.org/?p=966 linux-ha    Pacemaker

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.

]]> http://www.miamammausalinux.org/2010/06/evoluzione-dellalta-affidabilita-su-linux-confronto-pratico-tra-heartbeat-classico-ed-heartbeat-con-pacemaker/feed/ 8 Evoluzione dell’alta affidabilità su Linux: come orientarsi fra Hertbeat, Pacemaker, OpenAIS e Corosync http://www.miamammausalinux.org/2010/04/evoluzione-dellalta-affidabilita-su-linux-come-orientarsi-fra-hertbeat-pacemaker-openais-e-corosync/ http://www.miamammausalinux.org/2010/04/evoluzione-dellalta-affidabilita-su-linux-come-orientarsi-fra-hertbeat-pacemaker-openais-e-corosync/#comments Tue, 06 Apr 2010 12:51:39 +0000 Raoul Scarazzini http://www.miamammausalinux.org/?p=871 linux-ha    Pacemaker

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

Figura 1

passando dal supporto di più nodi:

Figura 2

Figura 2

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

Figura 3

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.

]]> http://www.miamammausalinux.org/2010/04/evoluzione-dellalta-affidabilita-su-linux-come-orientarsi-fra-hertbeat-pacemaker-openais-e-corosync/feed/ 6 RAID Software : Proteggere i dati con l’aiuto del kernel (5 di 5) http://www.miamammausalinux.org/2009/04/raid-software-proteggere-i-dati-con-l%e2%80%99aiuto-del-kernel-5-di-5/ http://www.miamammausalinux.org/2009/04/raid-software-proteggere-i-dati-con-l%e2%80%99aiuto-del-kernel-5-di-5/#comments Tue, 07 Apr 2009 07:20:31 +0000 Raoul Scarazzini http://www.miamammausalinux.org/?p=578 linux

Dopo il primo case study relativo all’impiego di mdadm per la creazione di un sistema RAID 1 con disco estraibile, l’ultima puntata di questa serie di articoli presenta nel dettaglio una soluzione di network Raid 1 creata attraverso il software drbd, per una replica in rete del disco contenente i dati e la condivisione di questi attraverso i servizi NFS e SAMBA, in alta affidabilità.

DRBD : Network RAID 1

Fino ad ora sono state illustrate soluzioni RAID applicate a singole macchine, ma è possibile garantire la protezione dai dati anche attraverso RAID distribuiti, in soluzioni ad alta affidabilità. Uno fra i progetti più interessanti in questo ambito, giunto allo stato di piena maturità, è sicuramente DRBD (http://www.drbd.org).
DRBD permette di replicare dati (in mirror, sul modello del RAID 1) da una macchina primaria definita “master” ad una secondaria definita “slave” attraverso una connessione di rete dedicata, tipicamente ottenuta dal collegamento di due schede di rete attraverso un cavo “cross” (senza disporre quindi di uno switch apposito).
Tecnicamente DRBD è un modulo del kernel, proprio come sono moduli quelli del RAID e come per questi moduli la gestione di DRBD è affidata ad una serie di utilities che comprende (come per mdadm) un demone che gestisce ed attiva le configurazioni. La sostanziale differenza tra DRBD ed i moduli standard di RAID è che questo modulo non è ancora incluso nei sorgenti ufficiali del kernel. Per questo motivo prima di poter utilizzare DRBD è necessario compilare il moduli del kernel partendo dai sorgenti.
Tipicamente DRBD viene utilizzato insieme al programma heartbeat, che consente di estenderne le funzionalità attraverso la gestione dei failover. Per failover si intendono tutte quelle situazioni in cui un servizio erogato da una macchina, se questa smette di funzionare, rimane accessibile attraverso una seconda che ne garantisce l’accessibilità costante.
I servizi erogabili attraverso heartbeat sono molteplici e possono riguardare i più svariati utilizzi : da un webserver ad un database MySQL, per arrivare a dei filesystem condivisi via NFS o SAMBA.
Nel case study di questo paragrafo verranno illustrate le operazioni necessarie all’installazione di DRBD e alla sua integrazione con heartbeat affinché condivida un filesystem in rete via NFS e SAMBA.

Case Study 2 – DRBD in una soluzione di alta affidabilità con heartbeat, NFS e SAMBA.

Il seguente case study descrive quanto è stato fatto per la società 3Dvision che effettua consulenza, supervisione e produzione di elaborazioni digitali destinate ai settori pubblicitario, promozionale e televisivo.
La grande quantità di dati trattati e la criticità del loro contenuto hanno sempre imposto la memorizzazione di questi attraverso hardware proprietario. Nella rete era infatti installato un dispositivo NAS (Network Attached Storage), che attraverso un sistema operativo proprietario, rendeva disponibile il proprio spazio.
Nel momento in cui il NAS si è guastato, si è optato per una scelta di radicale cambiamento, basata su hardware di consumo e software Opensource. E’ stato quindi acquistato hardware per creare due macchine identiche ciascuna con processore AMD Sempron 3200 MegaHertz, un GigaByte di RAM, due schede di rete Gigabit e quattro dischi da 300 GigaByte.
L’obiettivo finale è stato quello di ottenere 1,2 Tb di spazio debitamente protetto e condiviso in rete attraverso SAMBA ed NFS.

Sviluppo del progetto

Su entrambe le macchine è stato installato il sistema operativo Debian Sarge in forma minimale, senza cioè ambiente grafico, attraverso un lettore DVD esterno collegato via USB. In questo modo si sono potuti sfruttare tutti e due i canali IDE per il collegamento dei quattro dischi da 300 GigaByte gestiti attraverso il kernel in RAID 0, per un totale di 1,2 TeraByte di spazio disponibile.
Per ovviare all’insicurezza dettata dalla scelta del RAID 0 (se un disco dei quattro cessa di funzionare, tutto il sistema cade) si è scelto di effettuare un RAID 1 in rete attraverso DRBD. In questo modo si è sfruttata la capacità di scrittura parallela del RAID 0 e l’affidabilità della copia dati del Network RAID 1 via DRBD.
Il progetto è rappresentato in figura 5 :

Figura 5

Figura 5

Configurazione di DRBD

Al termine delle installazioni lo schema di partizionamento delle macchine è il seguente :

$ fdisk -l
 
Disk /dev/hda: 300.0 GB, 300090728448 bytes
255 heads, 63 sectors/track, 36483 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
 
   Device Boot      Start         End      Blocks   Id  System
/dev/hda1               1          30      240943+  82  Linux swap / Solaris
/dev/hda2              31        1246     9767520   83  Linux
/dev/hda3            1247       36483   283041202+  fd  Linux raid autodetect
 
Disk /dev/hdb: 300.0 GB, 300090728448 bytes
255 heads, 63 sectors/track, 36483 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
 
   Device Boot      Start         End      Blocks   Id  System
/dev/hdb1               1          30      240943+  82  Linux swap / Solaris
/dev/hdb2              31       36483   292808722+  fd  Linux raid autodetect
 
Disk /dev/hdc: 300.0 GB, 300090728448 bytes
255 heads, 63 sectors/track, 36483 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
 
   Device Boot      Start         End      Blocks   Id  System
/dev/hdc1               1          30      240943+  82  Linux swap / Solaris
/dev/hdc2              31       36483   292808722+  fd  Linux raid autodetect
 
Disk /dev/hdd: 300.0 GB, 300090728448 bytes
255 heads, 63 sectors/track, 36483 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
 
   Device Boot      Start         End      Blocks   Id  System
/dev/hdd1               1          30      240943+  82  Linux swap / Solaris
/dev/hdd2              31       36483   292808722+  fd  Linux raid autodetect
 
Disk /dev/md0: 1189.3 GB, 1189342216192 bytes
2 heads, 4 sectors/track, 290366752 cylinders
Units = cylinders of 8 * 512 = 4096 bytes
 
Disk /dev/md0 doesn't contain a valid partition table

Ciascuno dei quattro dischi contiene un’area di swap ed un’area dedicata al RAID, solo il primo dei quattro contiene una partizione da 10 Giga destinata alla partizione root.
Lo stato del RAID 0 sulle due macchine è il seguente :

$ cat /proc/mdstat
Personalities : [linear] [raid0] [raid1] [raid5] [multipath] [raid6] [faulty]
md0 : active raid0 hdd2[3] hdc2[2] hdb2[1] hda3[0]
      1161467008 blocks 64k chunks
 
unused devices: <none>

Entrambe possiedono una device /dev/md0 di circa 1,2 TeraByte gestita in RAID 0 dal kernel.
La prima fase del progetto riguarda l’installazione dei pacchetti necessari a ricompilare il kernel secondo la comodissima metodologia Debian, insieme alle utility ed ai sorgenti di DRBD :

$ apt-get install kernel-source kernel-package bzip2 libncurses5-dev drbd0.7-utils drbd0.7-module-source

Per creare il kernel personalizzato vanno decompressi i sorgenti e lanciata la configurazione che va effettuata sulla base dell’hardware delle macchine impiegate :

$ cd /usr/src/
$ tar -xjvf kernel-source-2.6.8.tar.bz2
$ cd /usr/src/kernel-source-2.6.8
$ make menuconfig

Terminata questa fase, andranno creati i pacchetti relativi al kernel ed ai moduli DRBD :

$ make-kpkg --revision 1 --append-to-version rasca-3dv kernel_image
$ make-kpkg --revision 1 --append-to-version rasca-3dv modules_image
$ ls -1 /usr/src/
drbd0.7-module-2.6.8rasca-3dv_0.7.10-4+1_i386.deb
drbd0.7.tar.gz
kernel-image-2.6.8rasca-3dv_1_i386.deb
linux-source-2.6.8
linux-source-2.6.8.tar.bz2
modules

E di conseguenza installati :

$ dpkg -i kernel-image-2.6.8rasca-3dv_1_i386.deb drbd0.7-module-2.6.8rasca-3dv_0.7.10-4+1_i386.deb

Il sistema va avviato col nuovo kernel (vanno ignorati gli errori in fase di boot del demone DRBD in quanto non è stato ancora configurato). Per verificare che il sistema sia stato avviato col nuovo kernel è sufficiente lanciare il comando “uname -a” :

$ uname -a
Linux 3dv-ha-1 2.6.8rasca-3dv #1 PREEMPT Sat Jun 17 20:56:39 CEST 2006 i686 GNU/Linux

Il sistema è quindi pronto per la configurazione di DRBD. Come da specifiche, le interfacce presenti nel sistema sono 3, eth0 (Gigabit, PCI) collegata alla LAN, eth1 (Gigabit, PCI) collegata attraverso il cavo cross all’altra macchina e eth2 (Megabit, integrata nella scheda madre) scollegata :

$ ifconfig -a
eth0      Link encap:Ethernet  HWaddr 00:14:C1:0F:50:AF
          inet addr:192.168.0.8  Bcast:192.168.0.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:19841 errors:0 dropped:0 overruns:0 frame:0
          TX packets:32402 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:6882512 (6.5 MiB)  TX bytes:42354250 (40.3 MiB)
          Interrupt:177 Base address:0xe000
 
eth1      Link encap:Ethernet  HWaddr 00:14:C1:0F:50:AA
          inet addr:10.0.0.1  Bcast:10.0.0.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:3 errors:0 dropped:0 overruns:0 frame:0
          TX packets:3 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:218 (218.0 b)  TX bytes:218 (218.0 b)
          Interrupt:185
 
eth2      Link encap:Ethernet  HWaddr 00:15:F2:D0:FC:B9
          BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)
          Interrupt:193 Base address:0xa400

Il file di configurazione di DRBD è /etc/drbd.conf ed è diviso a blocchi. Per ogni risorsa esiste un blocco nominato “resource” contenente dei sotto-blocchi. Ciascuno dei blocchi si apre e si chiude con una parentesi graffa. Per le esigenze del progetto, la compilazione ideale è la seguente :

resource drbd0 {
  protocol C;
  incon-degr-cmd "echo '!DRBD! primario sui dati inconsistenti' | wall ; sleep 60 ; halt -f";
 
  startup {
    degr-wfc-timeout 120;
  }
 
  disk {
    on-io-error   detach;
  }
 
  net {
    timeout       80;
    connect-int   10;
    ping-int      10;
    ko-count      4;
    max-buffers   4096;
    max-epoch-size  2048;
  }
 
  syncer {
    rate 650M;
    group 0;
    al-extents 521;
  }
 
  on 3dv-ha-1 {
    device     /dev/drbd0;
    disk       /dev/md0;
    address    10.0.0.1:7788;
    meta-disk  internal;
  }
 
  on 3dv-ha-2 {
    device    /dev/drbd0;
    disk      /dev/md0;
    address   10.0.0.2:7788;
    meta-disk internal;
  }
}

Le opzioni del file sono auto esplicative ed attraverso la man page di drbd.conf è possibile conoscerne tutti i particolare (digitando “man drbd.conf”).
All’interno del blocco “resource” viene indicato il nome che la device DRBD avrà per il sistema ed il messaggio che il kernel riceverà in caso di malfunzionamento.
Il blocco “startup” contiene il tempo di attesa che in fase di boot il demone DRBD attenderà per ricevere notifica di esistenza da parte della macchina associata.
“disk” è il blocco contenente il tipo di comportamento che il demone dovrà assumere in caso di errori relativi alla device, nel caso descritto sarà “detach” ossia “Stacca”, “Sconnetti”.
Nel blocco “net” sono presenti le dichiarazioni relative al collegamento di rete tra le due macchine ossia il tempo che deve trascorrere tra un ping e l’altro (necessario per capire se l’altra macchina è in linea), la grandezza del buffer e così via.
Nel blocco “syncer” è contenuta una tra le opzioni più importanti per le performances, e cioè “rate”. Tale parametro infatti regola il numero massimo di byte per secondo che il demone utilizzerà per replicare i dati tra il computer master e lo slave. Nel caso illustrato tale parametro, in forza alle interfacce Gigabit con cui le due macchine sono collegate fra loro, è stato settato al massimo disponibile, ossia 650 MegaByte.
Gli ultimi due blocchi descrivono le due macchine impiegate nel RAID 1 e per ciascuna la device DRBD utilizzata, il filesystem locale condiviso, l’IP della macchina, la porta di ascolto del demone DRBD ed il tipo di meta-disk (interno).
Terminata la compilazione del file, che dovrà essere IDENTICO per ciascuna delle due macchine, si potrà procedere al riavvio del servizio DRBD su entrambi i nodi :

$ /etc/init.d/drbd restart

All’interno del file /var/log/syslog verranno riportate le fasi di attivazione del Network RAID 1 :

Jun 18 21:14:55 3dv-ha-1 kernel: drbd: module cleanup done.
Jun 18 21:14:55 3dv-ha-1 kernel: drbd: initialised. Version: 0.7.10 (api:77/proto:74)
Jun 18 21:14:55 3dv-ha-1 kernel: drbd: SVN Revision: 1743 build by phil@mescal, 2005-01-31 12:22:07
Jun 18 21:14:55 3dv-ha-1 kernel: drbd: registered as block device major 147
Jun 18 21:14:55 3dv-ha-1 kernel: drbd0: Creating state block
Jun 18 21:14:55 3dv-ha-1 kernel: klogd 1.4.1, ---------- state change ----------
Jun 18 21:14:55 3dv-ha-1 kernel: No module symbols loaded - kernel modules not enabled.
Jun 18 21:14:55 3dv-ha-1 kernel: drbd0: resync bitmap: bits=290333984 words=9072938
Jun 18 21:14:55 3dv-ha-1 kernel: drbd0: size = 1107 GB (1161335936 KB)
Jun 18 21:14:55 3dv-ha-1 kernel: drbd0: Assuming that all blocks are out of sync (aka FullSync)
Jun 18 21:15:00 3dv-ha-1 kernel: drbd0: 1161335936 KB now marked out-of-sync by on disk bit-map.
Jun 18 21:15:00 3dv-ha-1 kernel: drbd0: drbdsetup [3151]: cstate Unconfigured --> StandAlone
Jun 18 21:15:00 3dv-ha-1 kernel: drbd0: drbdsetup [3154]: cstate StandAlone --> Unconnected
Jun 18 21:15:00 3dv-ha-1 kernel: drbd0: drbd0_receiver [3155]: cstate Unconnected --> WFConnection
Jun 18 21:15:10 3dv-ha-1 kernel: drbd0: drbd0_receiver [3155]: cstate WFConnection --> WFReportParams
Jun 18 21:15:10 3dv-ha-1 kernel: drbd0: Handshake successful: DRBD Network Protocol version 74
Jun 18 21:15:10 3dv-ha-1 kernel: drbd0: Connection established.
Jun 18 21:15:10 3dv-ha-1 kernel: drbd0: I am(S): 0:00000001:00000001:00000001:00000001:00
Jun 18 21:15:10 3dv-ha-1 kernel: drbd0: Peer(S): 0:00000001:00000001:00000001:00000001:00
Jun 18 21:15:10 3dv-ha-1 kernel: drbd0: drbd0_receiver [3155]: cstate WFReportParams --> Connected
Jun 18 21:15:10 3dv-ha-1 kernel: drbd0: I am inconsistent, but there is no sync? BOTH nodes inconsistent!
Jun 18 21:15:10 3dv-ha-1 kernel: drbd0: Secondary/Unknown --> Secondary/Secondary

I due host avviati da DRBD sono connessi ma il Network RAID 1 non è ancora attivo. Lo si evince dal messaggio “I am inconsistent, but there is no sync?”. Questo perché i due dischi non sono mai stati sincronizzati. Abbiamo comunque la conferma che il primo nodo è primario, quindi ciò che rimane da fare è forzare la prima sincronizzazione attraverso il seguente comando sul nodo master :

$ drbdadm -- --do-what-I-say primary all

Su entrambi i nodi si può osservare lo stato della ricostruzione, visualizzando lo stato del Network RAID 1 contenuto nel file “drbd” della directory /proc, nella stessa maniera in cui veniva visualizzata la ricostruzione per i RAID creati con mdadm :

$ cat /proc/drbd
version: 0.7.10 (api:77/proto:74)
SVN Revision: 1743 build by phil@mescal, 2005-01-31 12:22:07
 0: cs:SyncSource st:Primary/Secondary ld:Consistent
    ns:54361636 nr:0 dw:0 dr:54378020 al:0 bm:3317 lo:27 pe:55 ua:4096 ap:0
        [>...................] sync'ed:  4.9% (1036021/1089109)M
        finish: 5:18:23 speed: 55,492 (54,036) K/sec

Lavorando con quantità di dati così ampie, la prima ricostruzione impiegherà poco più di quattro ore per completarsi :

$ cat /proc/drbd
version: 0.7.10 (api:77/proto:74)
SVN Revision: 1743 build by phil@mescal, 2005-01-31 12:22:07
 0: cs:SyncSource st:Primary/Secondary ld:Consistent
    ns:738278800 nr:0 dw:0 dr:738295184 al:0 bm:45060 lo:0 pe:6 ua:4096 ap:0
        [=============>......] sync'ed: 66.2% (368133/1089109)M
        finish: 1:53:34 speed: 55,288 (53,956) K/sec

Al termine di tale ricostruzione, lo stato del Network RAID 1 è il seguente :

$ cat /proc/drbd
version: 0.7.10 (api:77/proto:74)
SVN Revision: 1743 build by phil@mescal, 2005-01-31 12:22:07
 0: cs:Connected st:Primary/Secondary ld:Consistent
    ns:1115247744 nr:0 dw:0 dr:1115247744 al:0 bm:68070 lo:0 pe:0 ua:0 ap:0

Dal nodo master è quindi possibile creare un filesystem ext3 sulla neo-creata device :

$ mke2fs -j /dev/drbd0
mke2fs 1.37 (21-Mar-2005)
Etichetta del filesystem=
Tipo SO: Linux
Dimensione blocco=4096 (log=2)
Dimensione frammento=4096 (log=2)
145178624 inode, 290333984 blocchi
14516699 blocchi (5.00%) riservati per l'utente root
Primo blocco dati=0
8861 gruppi di blocchi
32768 blocchi per gruppo, 32768 frammenti per gruppo
16384 inode per gruppo
Backup del superblocco salvati nei blocchi:
        32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
        4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968,
        102400000, 214990848
 
Scrittura delle tavole degli inode: fatto
Creazione del journal (8192 blocchi): fatto
Scrittura delle informazioni dei superblocchi e dell'accounting del filesystem: fatto
 
Questo filesystem verrà automaticamente controllato ogni 30 mount, o
180 giorni, a seconda di quale venga prima. Usare tune2fs -c o -i per cambiare.

Ed infine montare il nuovo filesystem nella directory /store (sempre e solo sul nodo master) :

$ mount /dev/drbd0 /store

Attraverso il comando “df”, è possibile osservare lo stato del Network RAID 1 :

$ df -h
Filesystem         Dimens. Usati Disp. Uso% Montato su
/dev/hda2             9,2G 1001M  7,8G  12% /
tmpfs                 443M     0  443M   0% /dev/shm
/dev/drbd0            1,1T   33M  1,1T   1% /store

Ma per ottenere quanto stabilito all’inizio del progetto è necessario spingersi oltre, configurando heartbeat in modo che controlli il filesystem DRBD e ne condivida il contenuto via NFS e SAMBA, in alta affidabilità.
Su ciascuna delle due macchine andranno quindi configurati i due servizi insieme al demone heartbeat.

Configurazione di NFS

La configurazione di NFS va effettuata su entrambe le macchine, in quanto in caso di malfunzionamento di una di queste, l’altra attraverso heartbeat sarà in grado di continuare ad erogare il servizio.
Per installare il pacchetto nfs-kernel-server è sufficiente lanciare il comando :

$ apt-get install nfs-kernel-server

l’installazione di NFS, implica l’avvio del servizio. Ma in funzione del fatto che tale servizio sarà controllato da heartbeat, il demone va fermato :

$ /etc/init.d/nfs-kernel-server stop
Stopping NFS kernel daemon: mountd nfsd.
Unexporting directories for NFS kernel daemon...done.

E rimosso dall’avvio automatico durante il boot del sistema :

$ update-rc.d -f nfs-kernel-server remove
update-rc.d: /etc/init.d/nfs-kernel-server exists during rc.d purge (continuing)
 Removing any system startup links for /etc/init.d/nfs-kernel-server ...
   /etc/rc0.d/K80nfs-kernel-server
   /etc/rc1.d/K80nfs-kernel-server
   /etc/rc2.d/S20nfs-kernel-server
   /etc/rc3.d/S20nfs-kernel-server
   /etc/rc4.d/S20nfs-kernel-server
   /etc/rc5.d/S20nfs-kernel-server
   /etc/rc6.d/K80nfs-kernel-server

Il servizio NFS tipicamente registra le informazioni di lock dei file nella directory /var/lib/nfs. Nel caso in esame però tale servizio, in caso di malfunzionamento, potrebbe cambiare da una macchina all’altra. E’ facile capire come nel caso in cui un file venisse bloccato sulla macchina master (quindi con le informazioni di blocco scritte nella directory /var/lib/nfs della macchina master), se il servizio NFS effettuasse uno switch, tali informazioni non sarebbero più disponibili.
Pertanto, è necessario configurare la cartella dei lock sul filesystem condiviso.
Sulla macchina master quindi andrà copiata la cartella /var/lib/nfs in /store :

$ mv /var/lib/nfs /store/

Mentre sul nodo slave, tale directory andrà rimossa :

$ rm -rf /var/lib/nfs

Il vecchio path andrà infine collegato al nuovo su entrambi i sistemi :

$ ln -s /store/nfs /var/lib/nfs

Sul nodo slave NON esiste la cartella /store/nfs, ma esisterà nel momento in cui il servizio NFS (e quindi il filesystem DRBD) effettuerà lo switch.
Infine, nel file /etc/default/nfs-common, il parametro STATDOPTS andrà modificato così :

STATDOPTS="-n 3dv-ha"

Questa opzione è necessaria in quanto il demone che controlla gli stati del servizio NFS (STATD) associa gli stati che controlla al nome dell’host. Anche in questo caso, nel momento in cui la macchina effettuerà lo switch del servizio, il nome host cambierà. Con questa opzione STATD non farà confusione e assocerà gli stati sempre al nome host “virtuale” 3dv-ha.

L’ultima operazione riguarda la configurazione delle directory condivise nel file /etc/exports su entrambi i nodi :

/store/Progetti 192.168.0.0/255.255.255.0(rw,async)

In questo modo è garantito il permesso a qualsiasi host della rete 192.168.0 di montare in lettura e scrittura la cartella /store/Progetti.

Configurazione di SAMBA

Dopo aver aggiornato i repositories di apt come spiegato nel case study precedente, si può procedere con l’installazione degli ultimi pacchetti SAMBA disponibili :

$ apt-get install samba smbfs smbclient

La più semplice delle configurazioni (personalizzabile a seconda delle esigenze) del file /etc/samba/smb.conf potrebbe essere la seguente :

[global]
   workgroup = 3DVISION
   server string = %h server (Samba %v)
   dns proxy = no
   log file = /var/log/samba/log.%m
   max log size = 1000
   syslog = 0
   panic action = /usr/share/samba/panic-action %d
   encrypt passwords = true
   passdb backend = tdbsam guest
   obey pam restrictions = yes
   invalid users = root
   passwd program = /usr/bin/passwd %u
   passwd chat = *EntersnewsUNIXspassword:* %nn *RetypesnewsUNIXspassword:* %nn .
   load printers = no
   socket options = TCP_NODELAY
 
[Progetti]
   comment = Progetti
   browsable = yes
   path = /store/Progetti
   guest ok = no
   writable = no
   share modes = no
   write list = @3dvision
   create mask = 0770
   directory mask = 0770

Viene quindi garantito l’accesso in scrittura alla cartella “Progetti” (che è stata creata con maschera 770 ed appartiene all’utente “3dv_user”) a tutti gli utenti appartenenti al gruppo “3dvision” :

$ mkdir /store/Progetti
$ chown 3dv_user:3dvision /store/Progetti
$ chmod 770 /store/Progetti
$ ll /store/
totale 28
drwx------  2 root     root     16384 2006-06-19 04:01 lost+found
drwxr-xr-x  4 root     root      4096 2006-06-20 17:47 nfs
drwxrwx---  2 3dv_user 3dvision  4096 2006-06-20 17:52 Progetti

Anche per il servizio SAMBA, è necessario rimuovere l’avvio automatico al boot del sistema :

$ update-rc.d -f samba remove
update-rc.d: /etc/init.d/samba exists during rc.d purge (continuing)
 Removing any system startup links for /etc/init.d/samba ...
   /etc/rc0.d/K19samba
   /etc/rc1.d/K19samba
   /etc/rc2.d/S20samba
   /etc/rc3.d/S20samba
   /etc/rc4.d/S20samba
   /etc/rc5.d/S20samba
   /etc/rc6.d/K19samba

In questo modo anche il servizio SAMBA è configurato.

Configurazione di Heartbeat

L’ultima fase relativa al nostro progetto riguarda l’installazione di heartbeat :

$ apt-get install heartbeat

Per il quale sarà necessario aggiungere l’utente “cluster”, necessario per le interrogazioni sullo stato del cluster :

$ adduser cluster
Adding user `cluster'...
Adding new group `cluster' (1002).
Adding new user `cluster' (1002) with group `cluster'.
Creating home directory `/home/cluster'.
Copying files from `/etc/skel'
Enter new UNIX password:
Retype new UNIX password:
passwd: password updated successfully
Modifica delle informazioni relative all'utente cluster
Inserire il nuovo valore o premere INVIO per quello predefinito
        Nome completo []:
        Stanza n° []:
        Numero telefonico di lavoro []:
        Numero telefonico di casa []:
        Altro []:
Is the information correct? [y/N] y

Il file di configurazione di heartbeat è /etc/ha.d/ha.cf e per il nodo master sarà il seguente :

logfacility daemon
keepalive 1
deadtime 14
warntime 7
initdead 120
udpport 694
baud 19200
serial /dev/ttyS0
ucast eth1 10.0.0.2
ucast eth0 192.168.0.9
auto_failback off
watchdog /dev/watchdog
node    3dv-ha-1
node    3dv-ha-2
ping 192.168.0.69
respawn cluster /usr/lib/heartbeat/ipfail
apiauth ipfail gid=cluster uid=cluster
deadping 30
logfile /var/log/ha.log

Senza studiare a fondo ciascuna delle opzioni, ciò che interessa di più sono i parametri “ucast” che dovranno variare dal nodo master al nodo slave, in quanto rappresentano gli indirizzi IP attraverso i quali avverrà lo scambio delle informazioni per l’alta affidabilità (l’heartbeat appunto o “battito cardiaco”). Tali opzioni infatti sul nodo slave saranno esattamente l’opposto :

ucast eth1 10.0.0.1
ucast eth0 192.168.0.8

Heartbeat necessita per la sicurezza della creazione di una chiave di autenticazione :

$ dd if=/dev/urandom count=4 2>/dev/null | md5sum | cut -c1-32
e0fb55565622e3a893a808ee16f70538

Questo comando, da eseguire sulla sola macchina master, produrrà un output il cui contenuto andrà immesso nel file /etc/ha.d/authkeys su entrambe le macchine, con questa struttura :

auth 1
1 sha1 e0fb55565622e3a893a808ee16f70538

Su questo file andranno settati i permessi e la proprietà all’utente cluster :

$ chmod 600 /etc/ha.d/authkeys
$ chown cluster:cluster /etc/ha.d/authkeys

Rimangono quindi da creare due file su entrambi i nodi : il primo nominato “/etc/heartbeat/resource.d/sleep” con questo contenuto :

sleep $1

La cui funzione sarà quella di immettere una pausa (della durata del parametro passato) durante lo switch del servizio. Tale pausa eviterà di incorrere nell’errore “Stale NFS file handle” (per il quale esiste ampia documentazione in internet) che potrebbe influenzare il regolare funzionamento del servizio.
Il secondo file da creare è /etc/heartbeat/resource.d/killnfsd con questo contenuto :

killall -9 nfsd

Che permetterà ad heartbet durante lo switch del servizio di uccidere eventuali processi NFS residui non più controllati.
A questi script appena creati vanno assegnati i permessi di esecuzione :

$ chmod 755 /etc/heartbeat/resource.d/killnfsd
$ chmod 755 /etc/heartbeat/resource.d/sleep

Come ultimo passo per la configurazione, va creato il file /etc/ha.d/haresources, all’interno del quale verranno dichiarate le risorse condivise da heartbeat :

3dv-ha-1 IPaddr::192.168.0.10/24/eth0 drbddisk::drbd0 Filesystem::/dev/drbd0::/store::ext3 killnfsd nfs-common nfs-kernel-server samba sleep::3

La struttura del file è molto semplice, viene indicato il nodo master, ossia 3dv-ha-1, l’indirizzo IP virtuale a cui i servizi risponderanno ed i servizi stessi, cioè DRBD, NFS e SAMBA insieme agli script di controllo.
Heartbeat è quindi pronto ad essere avviato :

$ /etc/init.d/heartbeat start

E ne si può seguire l’evoluzione nel file /var/log/ha.log :

$ tail -f /var/log/ha.log
heartbeat: 2006/06/20_18:34:07 info: Running /etc/ha.d/rc.d/ip-request-resp ip-request-resp
heartbeat: 2006/06/20_18:34:07 received ip-request-resp IPaddr::192.168.0.10/24/eth0 OK yes
heartbeat: 2006/06/20_18:34:07 info: Acquiring resource group: 3dv-ha-1 IPaddr::192.168.0.10/24/eth0 drbddisk::drbd0 Filesystem::/dev/drbd0::/store::ext3 killnfsd nfs-common nfs-kernel-server samba sleep::3
heartbeat: 2006/06/20_18:34:07 info: Running /etc/ha.d/resource.d/IPaddr 192.168.0.10/24/eth0 start
heartbeat: 2006/06/20_18:34:07 info: /sbin/ifconfig eth0:0 192.168.0.10 netmask 255.255.255.0   broadcast 192.168.0.255
heartbeat: 2006/06/20_18:34:07 info: Sending Gratuitous Arp for 192.168.0.10 on eth0:0 [eth0]
heartbeat: 2006/06/20_18:34:07 /usr/lib/heartbeat/send_arp -i 1010 -r 5 -p /var/lib/heartbeat/rsctmp/send_arp/send_arp-192.168.0.10 eth0 192.168.0.10 auto 192.168.0.10 ffffffffffff
heartbeat: 2006/06/20_18:34:07 info: Running /etc/ha.d/resource.d/drbddisk drbd0 start
heartbeat: 2006/06/20_18:34:07 info: Running /etc/ha.d/resource.d/Filesystem /dev/drbd0 /store ext3 start
heartbeat: 2006/06/20_18:34:08 info: Running /etc/ha.d/resource.d/killnfsd  start
heartbeat: 2006/06/20_18:34:08 ERROR: Return code 1 from /etc/ha.d/resource.d/killnfsd
heartbeat: 2006/06/20_18:34:08 info: Running /etc/init.d/nfs-common  start
heartbeat: 2006/06/20_18:34:08 info: Running /etc/init.d/nfs-kernel-server  start
heartbeat: 2006/06/20_18:34:08 info: Running /etc/init.d/samba  start
heartbeat: 2006/06/20_18:34:11 info: Running /etc/ha.d/resource.d/sleep 3 start

L’unico errore rilevato (“ERROR: Return code 1 from /etc/ha.d/resource.d/killnfsd”) si può ignorare, in quanto non esistono processi residui per NFS e l’esito dell’operazione “killall” è comunque coerente.

Per effettuare un test, da una macchina remota, è possibile montare lo share in NFS :

$ mount -t nfs 192.168.0.10:/store/Progetti /mnt/

Se l’esito del comando mount sarà positivo, si potrà provare a creare un file all’interno dello share:

$ ls -la /mnt/
$ touch /mnt/test-ha

Per effettuare una prova di corretto failover basterà spegnere il nodo master e verificare che lo slave prenda il suo posto e sia quindi altamente affidabile.
Mettendosi “in ascolto” sul file di log della macchina slave e spegnendo il nodo master si può controllare quanto succede :

$ tail -f /var/log/ha.log
heartbeat: 2006/06/20_18:39:51 info: Received shutdown notice from '3dv-ha-1'.
heartbeat: 2006/06/20_18:39:51 info: Resources being acquired from 3dv-ha-1.
heartbeat: 2006/06/20_18:39:51 info: acquire local HA resources (standby).
heartbeat: 2006/06/20_18:39:51 info: local HA resource acquisition completed (standby).
heartbeat: 2006/06/20_18:39:51 info: Standby resource acquisition done [all].
heartbeat: 2006/06/20_18:39:51 info: No local resources [/usr/lib/heartbeat/ResourceManager listkeys 3dv-ha-2] to acquire.
heartbeat: 2006/06/20_18:39:51 info: Running /etc/ha.d/rc.d/status status
heartbeat: 2006/06/20_18:39:51 info: Taking over resource group IPaddr::192.168.0.10/24/eth0
heartbeat: 2006/06/20_18:39:51 info: Acquiring resource group: 3dv-ha-1 IPaddr::192.168.0.10/24/eth0 drbddisk::drbd0 Filesystem::/dev/drbd0::/store::ext3 killnfsd nfs-common nfs-kernel-server samba sleep::3
heartbeat: 2006/06/20_18:39:51 info: Running /etc/ha.d/resource.d/IPaddr 192.168.0.10/24/eth0 start
heartbeat: 2006/06/20_18:39:51 info: /sbin/ifconfig eth0:0 192.168.0.10 netmask 255.255.255.0   broadcast 192.168.0.255
heartbeat: 2006/06/20_18:39:51 info: Sending Gratuitous Arp for 192.168.0.10 on eth0:0 [eth0]
heartbeat: 2006/06/20_18:39:51 /usr/lib/heartbeat/send_arp -i 1010 -r 5 -p /var/lib/heartbeat/rsctmp/send_arp/send_arp-192.168.0.10 eth0 192.168.0.10 auto 192.168.0.10 ffffffffffff
heartbeat: 2006/06/20_18:39:51 info: Running /etc/ha.d/resource.d/drbddisk drbd0 start
heartbeat: 2006/06/20_18:39:51 info: Running /etc/ha.d/resource.d/Filesystem /dev/drbd0 /store ext3 start
heartbeat: 2006/06/20_18:39:51 info: Running /etc/ha.d/resource.d/killnfsd  start
heartbeat: 2006/06/20_18:39:51 ERROR: Return code 1 from /etc/ha.d/resource.d/killnfsd
heartbeat: 2006/06/20_18:39:52 info: Running /etc/init.d/nfs-common  start
heartbeat: 2006/06/20_18:39:52 info: Running /etc/init.d/nfs-kernel-server  start
heartbeat: 2006/06/20_18:39:52 info: Running /etc/init.d/samba  start
heartbeat: 2006/06/20_18:39:55 info: Running /etc/ha.d/resource.d/sleep 3 start
heartbeat: 2006/06/20_18:39:58 info: /usr/lib/heartbeat/mach_down: nice_failback: foreign resources acquired
heartbeat: 2006/06/20_18:39:58 info: mach_down takeover complete.
heartbeat: 2006/06/20_18:39:58 info: mach_down takeover complete for node 3dv-ha-1.
heartbeat: 2006/06/20_18:40:06 WARN: node 3dv-ha-1: is dead
heartbeat: 2006/06/20_18:40:06 info: Dead node 3dv-ha-1 gave up resources.
heartbeat: 2006/06/20_18:40:23 info: Link 3dv-ha-1:eth1 dead.
heartbeat: 2006/06/20_18:40:23 info: Link 3dv-ha-1:eth0 dead.

Le due righe :

heartbeat: 2006/06/20_18:39:58 info: mach_down takeover complete.
heartbeat: 2006/06/20_18:39:58 info: mach_down takeover complete for node 3dv-ha-1.

confermano che il failover è stato eseguito con successo.
Per il client che montava la cartella remota tutto si è svolto in maniera trasparente, ed il mount point risponde a dovere :

$ ls /mnt/
test-ha

Stessi test possono essere effettuati per SAMBA.
E’ da notare che nel momento in cui si accenderà nuovamente il nodo master, ad erogare il servizio sarà sempre il nodo slave che cederà le risorse solo in caso di spegnimento o di rottura di componenti hardware.

Anche la descrizione di questo progetto viene conclusa con il giudizio della società : “Questo tipo di sistema ci ha permesso di memorizzare la totalità dei dati che gestiamo e di avere la sicurezza nella ridondanza dei dati. A questo si aggiunge il risparmio sensibile dettato dall’hardware impiegato.” – Dario Colombo, Amministratore Delegato di 3Dvision

Conclusioni

Le potenzialità offerte dalla gestione del RAID software da parte del kernel Linux sono notevoli e questa lunga panoramica lo ha dimostrato. Quello che rimane da fare è cercare di spingere il più possibile le aziende a sperimentare queste soluzioni, perché dopo la logica diffidenza iniziale, rimane solo la soddisfazione di aver fatto una scelta che ha portato un incremento della produttività, un risparmio ed un sistema al passo con i tempi.

Bibliografia essenziale

“The Software-RAID HOWTO” di Jakob Østergaard ed Emilio Bueso http://www.tldp.org/HOWTO/Software-RAID-HOWTO.html

“$ man mdadm”

“DRBD”
http://www.drbd.org/

“DRBD : Linux HA”

http://linux-ha.org/DRBD

“$ man drbd.conf”

Ringraziamenti

Questo documento esiste grazie anche ad alcune persone che mi hanno aiutato nei momenti critici. Grazie quindi a Lorenzo Panarello per le revisioni, al Morby per i consigli sull’applicazione pratica dei RAID ed a mia moglie per la pazienza, in quanto credo che ormai in fatto di RAID ne sappia più di me.

]]> http://www.miamammausalinux.org/2009/04/raid-software-proteggere-i-dati-con-l%e2%80%99aiuto-del-kernel-5-di-5/feed/ 0 RAID Software : Proteggere i dati con l’aiuto del kernel (4 di 5) http://www.miamammausalinux.org/2009/03/raid-software-proteggere-i-dati-con-l%e2%80%99aiuto-del-kernel-4-di-5/ http://www.miamammausalinux.org/2009/03/raid-software-proteggere-i-dati-con-l%e2%80%99aiuto-del-kernel-4-di-5/#comments Tue, 31 Mar 2009 08:19:29 +0000 Raoul Scarazzini http://www.miamammausalinux.org/?p=575 linux

Nel precedente articolo è stato affrontato l’argomento della messa in RAID della partizione di root, partendo da un’installazione standard o da un sistema già esistente.
In questa penultima parte della serie viene affrontato un case study relativo all’impiego di mdadm per la creazione di un sistema RAID 1 con disco estraibile.

Case Study 1 – RAID 1 con HD ide “a cassetto”

Il seguente Case study descrive il progetto realizzato per la società “Immagine & Dettaglio” che si occupa di architettura d’interni, progettazione architettonica e di grafica.
L’esigenza primaria della società era di ottenere la gestione centralizzata dei dati e rimpiazzare il vetusto impianto per i backup, rappresentato da un DAT (Digital Audio Tape) a cassette, con un progetto che offrisse maggiore sicurezza nella registrazione dei dati, minori costi e la possibilità di trasportare tali backup in luoghi diversi dall’ufficio in cui risiedeva il sistema, per ridurre al minimo la possibilità di perdita totale di tutti i dati.
Il progetto ha quindi previsto il riutilizzo di una vecchia macchina (denominata “ied-storage” con processore Intel Celeron 1000 MegaHertz, 256 MegaByte di RAM ed un disco da 20 GigaByte), l’acquisto di tre dischi IDE da 300 GigaByte e due kit per hard disk estraibili.
Questi kit, visibili nella Foto 1 risultano facilmente installabili in qualsiasi slot da 5 pollici e ¼ (ossia lo slot dei lettori cd/dvd) e consentono di collegare un cassetto ad uno dei canali IDE della scheda madre e di rendere il disco che viene inserito all’interno di questo, estraibile.

Foto 1

Foto 1

Sul canale IDE primario della scheda madre sono stati quindi collegati il disco del sistema operativo da 20 GigaByte (come Master) ed il lettore DVD (come Slave) mentre sul canale IDE secondario è stato collegato uno dei dischi da 300 GigaByte (come Master) ed il cassetto IDE (come Slave).
Utilizzando la tecnologia RAID software offerta dal kernel Linux per realizzare un mirror (RAID 1) sui dischi collegati al secondo canale IDE oltre ad avere 300 GigaByte di spazio disponibile in rete, ne si garantisce il completo backup.
Inoltre, attraverso delle sostituzioni schedulate del disco (ad esempio una volta la settimana), si garantisce la possibilità di trasportare il contenuto del disco lontano dall’ufficio, avere tre copie dello stesso dato ad ogni sostituzione e nella peggiore delle ipotesi, ossia quella in cui entrambi i dischi collegati alla macchina si rompano, una sola settimana di ritardo nei backup (presenti sul disco estratto la settimana precedente).
Sul disco primario da 20 GigaByte è stato installato come sistema operativo Debian Sarge 3.1, mentre i due dischi hdc e hdd non sono stati configurati.

Sviluppo del progetto

Lo stato del sistema al primo boot è il seguente:

$ df -h
Filesystem         Dimens. Usati Disp. Uso% Montato su
/dev/hda2            19,2G 1001M 17,8G  12% /
tmpfs                 443M     0  443M   0% /dev/shm

Una partizione root da 19 GigaByte, una swap da 500 MegaByte.
Su ciascuno dei due dischi hdc e hdd vanno quindi create due partizioni hdc1 ed hdd1 (ad esempio attraverso il programma fdisk) della massima grandezza disponibile (quindi 300 GigaByte) ed il RAID 1 ad esse associato:

$ mdadm --create /dev/md0 --level=1 --raid-disks=2 /dev/hdc1 /dev/hdd1
mdadm: array /dev/md0 started.

Al termine della sincronizzazione lo stato del RAID è il seguente:

$ cat /proc/mdstat
Personalities : [raid1]
md0 : active raid1 hdd1[1] hdc1[0]
      2993440 blocks [2/2] [UU]
 
unused devices: <none>

La fase successiva prevede la creazione del filesystem sulla device md0:

$ mke2fs -j /dev/md0

Ed il suo montaggio nella directory /mnt:

$ mount /dev/md0 /mnt

In questo modo è possibile muovere l’attuale contenuto della cartella /home all’interno del nuovo filesystem, questo perché l’obiettivo finale vuole essere quello di rendere lo spazio offerto dal RAID 1 condiviso attraverso SAMBA, che nella configurazione standard condivide le directory home di ciascun utente:

$ mv /home/* /mnt/

Una volta smontata la cartella /mnt:

$ umount /mnt/

E’ possibile associare all’interno del file /etc/fstab la device /dev/md0 al mount point /home, aggiungendo nel file /etc/fstab la seguente riga:

/dev/md0        /home           ext3    defaults        0       0

E forzarne il mount con il comando mount -a, verificando che sia poi correttamente montata:

$ mount -a
$ mount
...
...
/dev/md0 on /home type ext3 (rw)

Configurazione di SAMBA

Nell’installare SAMBA come prima cosa, all’interno del file /etc/apt/sources.list di entrambe le macchine, vanno aggiunti i repositories SAMBA per le ultime versioni:

deb http://it.samba.org/samba/ftp/Binary_Packages/Debian sarge samba

In questo modo pur utilizzando una distribuzione stabile (Sarge) i cui pacchetti relativi a SAMBA sarebbero aggiornati a versioni precedenti alle ultime disponibili, si potrà disporre dei pacchetti allo stato dell’arte.
Effettuata la modifica, è necessario lanciare l’aggiornamento dei repositories:

$ apt-get update

Quindi installare SAMBA lasciando il file di configurazione così com’è, in modo che condivida le cartelle homes di tutti gli utenti (configurazione di default):

$ apt-get install samba smbfs smbclient

Una volta creato un utente locale nel sistema ed in SAMBA:

$ adduser ied-user1
$ passwd ied-user1
$ smbpasswd -a ied-user1

Lo spazio presente nel RAID 1 è accessibile dai client Microsoft Windows della rete che effettuino il login con l’utenza “ied-user1”.

Sostituire il disco estraibile

A completamento del progetto, rimane da schedulare uno spegnimento forzato della macchina necessario alla sostituzione del disco. Inutile dire che il disco non può essere estratto a caldo, pertanto si è stato scelto di spegnere la macchina ogni venerdì, manualmente o attraverso la schedulazione del crontab sostituendo il disco prima di riaccenderla. L’unico accorgimento che va preso in questo senso riguarda la forzatura dell’aggiunta del nuovo disco esterno all’interno del RAID. La motivazione è che controller software del kernel, trovandosi un persistent superblock differente sul disco che è stato sostituito, giudica il RAID in stato inconsistente.
Per ovviare, è sufficiente fare in modo che ad ogni avvio di sistema venga lanciato il seguente comando:

$ mdadm -a /dev/md0 /dev/hdd1

Tale comando nel caso che il disco non cambi non effettuerà alcuna operazione, giudicando il disco “already added”, nel caso che il disco ed il persistent superblock siano differenti, lo aggiungerà avviandone in contemporanea la re sincronizzazione, operazione che impiegherà per una capacità di 300 Giga circa 100 minuti.
Il comando lanciato può essere incluso in uno script denominato ad esempio /etc/init.d/mdadm-raid-recovery, dal seguente contenuto:

#!/bin/bash
#
# Script per il recovery del secondo disco di RAID.
 
mdadm -a /dev/md0 /dev/hdd1

Ed incluso fra gli script di avvio in questo modo:

$ update-rc.d mdadm-raid-recovery start 20 2 3 4 5 .
 Adding system startup for /etc/init.d/mdadm-raid-recovery ...
   /etc/rc2.d/S20mdadm-raid-recovery -> ../init.d/mdadm-raid-recovery
   /etc/rc3.d/S20mdadm-raid-recovery -> ../init.d/mdadm-raid-recovery
   /etc/rc4.d/S20mdadm-raid-recovery -> ../init.d/mdadm-raid-recovery
   /etc/rc5.d/S20mdadm-raid-recovery -> ../init.d/mdadm-raid-recovery

ad ogni avvio del sistema verrà effettuato questo controllo e l’eventuale aggiunta del disco inserito.
In caso sia presente un nuovo disco, verrà sincronizzato e messo in linea, di modo da garantire, al momento della sostituzione e prima di qualsiasi altra nuova scrittura, tre copie identiche dello stesso dato.

Ecco il giudizio sul progetto espresso dalla società : “L’utilizzo di un backup come questo ci ha permesso di avere la totale sicurezza per i dati e la possibilità di conservare una copia di essi lontano dalla sede. A tutto questo si aggiunge il risparmio dovuto al fatto di aver usato una macchina dismessa insieme all’acquisto dei tre dischi e dei relativi kit.” – Luciana Ferrari, Amministratore unico di “Immagine & Dettaglio”

Conclusioni

Nel prossimo ed ultimo articolo verrà illustrato il secondo case study: un network RAID 1 attraverso DRBD.

Note

Questa serie di articoli è apparsa in origine nel libro edito da Duke Italia Clustering e raid software allegato all’edizione italiana di Linux Journal dell’Ottobre 2006.

]]> http://www.miamammausalinux.org/2009/03/raid-software-proteggere-i-dati-con-l%e2%80%99aiuto-del-kernel-4-di-5/feed/ 1 RAID Software : Proteggere i dati con l’aiuto del kernel (3 di 5) http://www.miamammausalinux.org/2009/03/raid-software-proteggere-i-dati-con-l%e2%80%99aiuto-del-kernel-3-di-5/ http://www.miamammausalinux.org/2009/03/raid-software-proteggere-i-dati-con-l%e2%80%99aiuto-del-kernel-3-di-5/#comments Mon, 23 Mar 2009 14:09:03 +0000 Raoul Scarazzini http://www.miamammausalinux.org/?p=565 linux

Nel precedente articolo sono stati illustrati i metodi per la messa in RAID di partizioni nei diversi livelli disponibili.
Di seguito viene affrontata la messa in RAID della partizione root del sistema, sia nel caso di una nuova installazione, sia nel caso di un’installazione già esistente. Il tutto sempre grazie al software Linux mdadm.

Mettere in RAID la partizione root

Sino a questo punto sono state illustrate soluzioni RAID applicate a partizioni diverse da root (intesa come “/”, non come la directory /root), Linux però, offre anche la possibilità di montare la partizione root su una device RAID.
Le situazioni di partenza possono essere due : costruire un sistema partendo da una situazione vergine, oppure disporre di un sistema che non può essere cancellato, ma che si vuole mettere sotto RAID.
Se da una situazione vergine ogni distribuzione offre la possibilità di impostare in fase di configurazione la partizione root in modo che risieda su una device RAID, migrare un sistema esistente può risultare leggermente più complicato.
Verranno descritti entrambi le situazioni possibili, supponendo che il sistema possieda due dischi da 300 Giga collegati al canale IDE primario (quindi hda e hdb) e che si voglia mettere la partizione root sotto RAID 1 (o mirror).

Situazione 1 : Nuova installazione con RAID sulla partizione root creato attraverso l’installer

La maggior parte delle distribuzioni offre la possibilità di configurare in fase di installazione la partizione root in modo che risieda sotto una device RAID. I passi descritti e gli screenshot associati si riferiscono all’installer di Debian Sarge 3.1, ma concettualmente sono applicabili a tutte le distribuzioni.
Verranno descritte solo le fasi che riguardano la configurazione dei dischi in quanto a parte queste, l’installazione su RAID non si differenzia in alcun modo da una standard.
Attraverso il tool di configurazione dei dischi, andranno per prima cosa create per ogni disco una partizione di tipo “Volume fisico per il RAID” e la relativa swap :

Screenshot 1

Screenshot 1

Screenshot 2

Screenshot 2

Successivamente, selezionando “Configurare il RAID software” si accederà al menu di configurazione multidisk per il RAID software :

Screenshot 3

Screenshot 3

Selezionando l’opzione “Creare un device multidisk”, si potrà scegliere il tipo di multidisk da creare. Come stabilito, la scelta che verrà adottata verterà sul RAID 1, o mirror :

Screenshot 4

Screenshot 4

A questo punto andranno indicate al programma di installazione il numero di partizioni attive nel RAID (nel nostro caso 2) :

Screenshot 5

Screenshot 5

Ed il numero di device “spare”, utile soprattutto nei livelli di RAID 4 e 5, e che in questo caso potrà quindi rimanere 0 :

Screenshot 6

Screenshot 6

Per completare le informazioni sul RAID necessarie al programma di installazione, andranno indicate le partizioni attive per il RAID. Le due che sono state indicate durante il partizionamento con il tipo “Volume fisico per il RAID” :

Screenshot 7

Screenshot 7

Sulla neo creata device “RAID 1 dispositivo n° 0″ andrà infine creato il filesystem ext3 associato alla partizione root, e terminate queste modifiche, la situazione dei dischi sarà la seguente :

Screenshot 8

Screenshot 8

Per completare il tutto, sarà necessario “Terminare il partizionamento e scrivere i cambiamenti sui dischi”, procedendo poi per il resto dell’installazione nella maniera consueta.

Situazione 2 : Sistema preesistente, creazione del RAID sulla partizione root attraverso una distribuzione “Live”

Nell’eventualità in cui non si possa cancellare un’installazione esistente e si voglia comunque fare in modo che la partizione root sia sotto RAID verrà proposta tra le tante disponibili una soluzione che prevede l’uso di una distribuzione “Live”, necessaria per l’avvio del sistema con la partizione root non montata, e di un disco USB, necessario per il backup dei dati presenti sulla partizione root.
A sistema avviato, una volta collegato il disco USB, andranno copiate in una cartella nominata “oldroot” le cartelle di sistema ritenute critiche :

$ mkdir /media/usb0/oldroot
$ cp -Rp /bin  /boot /dev /etc /home /lib /mnt /opt  /root  /sbin /tmp /usr /var /media/usb0/oldroot

L’opzione -Rp del comando cp consente di percorrere ricorsivamente le directory e di copiarne il contenuto mantenendo permessi, proprietario, gruppo e date.
Le cartelle indicate sono quelle giudicate “critiche”, ma nulla vieta in presenza di altri dati sensibili di copiarli nello stesso sistema.
Essenziale è comunque avere nella directory /meda/usb0/oldroot del disco USB il contenuto attuale del sistema.
Il sistema andrà riavviato quindi con una distribuzione “Live” recente come “Knoppix”, “Ubuntu” o qualsiasi altra tra le numerose disponibili.
Una volta avviato il sistema si dovrà creare la device virtuale md0 composta dalle due partizioni appartenenti ai diversi dischi :

$ mdadm --create /dev/md0 --level=1 --raid-disks=2 /dev/hda1 /dev/hdb1
mdadm: array /dev/md0 started.

Terminata la sincronizzazione, sarà possibile creare il filesystem sulla device md0 :

$ mke2fs -j /dev/md0

e montarlo su una cartella qualsiasi, copiandoci sopra le cartelle precedentemente salvate sul disco esterno :

$ mkdir /target
$ mount /dev/md0 /target
$ cd /media/usb0/oldroot
$ cp -Rp /bin  /boot /dev /etc /home /lib /mnt /opt  /root  /sbin /tmp /usr /var /target

Alla struttura delle cartelle della partizione root andranno aggiunte le cartelle virtuali di sistema /proc e /sys :

$ mkdir /target/proc
$ mkdir /target/sys

Per completare i lavori ed installare il bootloader che dovrà avviare il sistema dalla device RAID, sarà sufficiente lanciare una shell interattiva nella cartella /target attraverso il comando chroot :

$ chroot /target

E dopo aver montato il filesystem /proc :

$ mount -t proc - /proc

Editare il file /boot/grub/menu.lst (supponendo che sia grub il bootloader installato nel sistema) con le specifiche necessarie all’avvio dalla device RAID :

default	0
timeout	5
color		cyan/blue	white/blue
 
title		Debian GNU/Linux , kernel 2.6.8-2-386
root		(hd0,0)
kernel	/boot/vmlinuz-2.6.8-2-386 root=/dev/md0 ro
initrd	/boot/initrd.img-2.6.8-2-386 root=/dev/md0 ro
savedefault
boot
 
title		Debian GNU/Linux , kernel 2.6.8-2-386 (Single)
root		(hd0,0)
kernel	/boot/vmlinuz-2.6.8-2-386 root=/dev/md0 ro single
initrd	/boot/initrd.img-2.6.8-2-386 root=/dev/md0 ro
savedefault
boot

Anche se a differenza di lilo, grub non necessita di essere reinstallato ogni volta che ne si modifica il contenuto del file di configurazione, lanciare il comando grub-install aiuta a comprendere come il bootloader debba risiedere comunque nel master boot record del disco primario, visto che sarà quella la posizione da cui il BIOS avvierà il sistema operativo :

$ grub-install /dev/hda
Installation is finished. No errors reported.
This is the contents of the device map /boot/grub/device.map.
Check if this is correct or not. If any of the line is incorrect,
fix it and re-run the script 'grub-install'.
 
(hd0)	/dev/hda
(hd1)	/dev/hdb

Ultimo passo da eseguire prima del riavvio è la modifica nel file /etc/fstab della riga che fa riferimento alla partizione /, in modo che non venga più montata su /dev/hda1 ma su /dev/md0. Il contenuto di tale file dovrà quindi essere il seguente :

$ cat /etc/fstab
# /etc/fstab: static file system information.
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
proc		/proc	proc	defaults			0       0
/dev/md0	/	ext3	defaults,errors=remount-ro	0       1
/dev/hda2	none	swap	sw				0       0
/dev/hdb2	none	swap	sw				0       0

A questo punto il sistema è pronto ad essere riavviato ed utilizzato.

Verifica del funzionamento

In entrambe le situazioni, per verificare che le operazioni siano andate a buon fine, sarà sufficiente controllare attraverso il comando mount che la device /dev/md0 sia montata nella cartella / :

$ mount
/dev/md0 on / type ext3 (rw,errors=remount-ro)
...
...

L’output conferma che tutto funziona come dovrebbe.

Considerazione finale sulle aree di swap

Anche se potrebbe risultare immediato pensare che volendo effettuare un mirror dell’intero sistema, anche la partizione di swap debba essere duplicata, non c’è niente di più sbagliato.
Le aree di swap del sistema infatti sono gestite a livello di kernel ed è il kernel a sfruttarle a seconda delle necessità. Mettere in RAID 1 una partizione di swap comporterebbe una perdita di performance notevole. Nel momento in cui il kernel scrivesse sulla partizione di swap primaria un’informazione, il sistema dovrebbe attendere che tale informazione venisse replicata anche sulla partizione swap secondaria. Tale informazione però non verrebbe mai utilizzata da nessuno ! Se a questo si aggiunge che il contenuto della partizione di swap è volatile, si capisce come sia molto più sensato indicare al sistema due aree di swap distinte, una sul primo disco ed una sul secondo, dichiarandole attraverso l’installer (si veda lo screenshot-8) o modificando a mano il file /etc/fstab in modo che contenga le seguenti righe :

/dev/hda2       none            swap    sw              0       0
/dev/hdb2       none            swap    sw              0       0

In questo modo il kernel avrà due aree swap a cui far riferimento, e le performance ne gioveranno.

Conclusioni

Nel prossimo articolo verrà illustrato il primo dei due “case study”, una soluzione RAID 1 con Hard Disk ide “a cassetto”.

Note

Questa serie di articoli è apparsa in origine nel libro edito da Duke Italia Clustering e raid software allegato all’edizione italiana di Linux Journal dell’Ottobre 2006.

]]> http://www.miamammausalinux.org/2009/03/raid-software-proteggere-i-dati-con-l%e2%80%99aiuto-del-kernel-3-di-5/feed/ 0 RAID Software : Proteggere i dati con l’aiuto del kernel (2 di 5) http://www.miamammausalinux.org/2009/03/raid-software-proteggere-i-dati-con-l%e2%80%99aiuto-del-kernel-2-di-5/ http://www.miamammausalinux.org/2009/03/raid-software-proteggere-i-dati-con-l%e2%80%99aiuto-del-kernel-2-di-5/#comments Mon, 16 Mar 2009 09:26:56 +0000 Raoul Scarazzini http://www.miamammausalinux.org/?p=559 linux

Nel precedente articolo sono state introdotte le diverse tipologie di RAID ed i concetti di parità per la gestione della ridondanza.
Di seguito viene affrontata nel dettaglio la creazione e l’amministrazione dei RAID attraverso il software Linux mdadm per configurare il sistema in modo che gestisca i diversi tipi di ridondanza sui dischi disponibili.

RAID software con Linux

Per poter gestire via software i RAID, è necessario che il kernel utilizzato disponga del supporto “Multiple devices driver support” insieme al “RAID Support” ed a tutti i moduli relativi ai livelli di RAID che si vogliono utilizzare. Nei kernel precompilati che vengono installati dalle più diffuse distribuzioni questi moduli sono compresi, quindi è necessario porre attenzione solo in caso di kernel compilati “a mano”.
Il modulo principale che si occupa della gestione dei RAID è denominato “md” (Multiple Disk) che è un alias di “md-mod”. Per verificare che il kernel installato sulla macchina utilizzata abbia questo supporto è sufficiente provare a caricare il modulo :

$ modprobe md

Se il comando non restituisce errori, all’interno del filesystem virtuale /proc verrà creato un file denominato mdstat contenente le informazioni sullo stato della controller RAID software :

$ cat /proc/mdstat
Personalities :
unused devices: <none>

Lo stato del RAID, non avendo effettuato alcuna configurazione, è nullo, ma l’output ricevuto conferma che il sistema supporta il tipo di operazioni che vogliamo effettuare.
A questo punto andranno create le devices, i dispositivi virtuali associati ai RAID. Generalmente in Linux, tali devices vengono nominate con mdX dove X è un numero che partendo da 0 identifica tutti gli array gestiti dal sistema.

Creare i RAID con mdadm

In Linux originariamente, la gestione del RAID software era affidata ad una suite di programmi denominata raidtools che comprendeva una serie di eseguibili attraverso i quali era possibile creare, modificare ed amministrare i RAID software. Nelle recenti distribuzioni il pacchetto raidtools è stato rimpiazzato dal programma mdadm. Oltre a contenere notevoli migliorie, esso presenta l’indubbio vantaggio di consentire la gestione totale dei RAID di sistema attraverso un unico comando.
mdadm è incluso come pacchetto binario in tutte le distribuzioni recenti, mentre i sorgenti sono disponibili a questo indirizzo : http://www.cse.unsw.edu.au/~neilb/source/mdadm/ .

Prima di cominciare è necessario avere ben chiaro ciò che si vuole ottenere. Tenendo come riferimento i pregi ed i difetti di ciascun livello illustrati poco sopra bisogna capire quale livello si adatta di più all’obiettivo che si vuole raggiungere.
Se ad esempio, la sicurezza dei dati è un fattore secondario e si necessita di performance e quanto più spazio possibile, sarà sensato creare un RAID 0, se invece i dati registrati sono di importanza critica, allora converrà optare per un RAID 1 a discapito delle performance, oppure per un RAID 5 nel caso in cui i dischi utilizzabili siano tre o più e si voglia aumentare la velocità di accesso ai dati.
Una volta fatta la scelta sul livello da implementare, è necessario scegliere se si vuole mettere sotto RAID l’intero sistema, compresa quindi la partizione root (ossia “/”), oppure solo alcune partizioni. Tratteremo successivamente la messa in RAID della partizione root, gli esempi illustrati riguardano l’implementazione su partizioni diverse da quella principale. Nel caso particolare sono state utilizzate le partizioni hda5, hda6 ed hda7 tutte di 250 MegaByte. Avrebbe più senso utilizzare partizioni che risiedano su dischi differenti, ed in ambienti di produzione questo è vivamente consigliato, ma per comprendere i meccanismi di funzionamento di mdadm questo tipo di situazione è più che sufficiente. Vincolante è la dimensione delle partizioni che deve essere quantomeno simile per tutte quelle impiegate.
Al comando mdadm, andranno passati come parametri il nome della device che si vorrà creare (ad esempio /dev/md0), il numero di dischi impiegati nell’array ed infine le partizioni che ne faranno parte.

RAID 0

Come primo esempio verrà creato un RAID 0 (striping) con le due partizioni hda5 ed hda6. Il comando che andrà eseguito, sarà il seguente :

$ mdadm --create /dev/md0 -a --level=0 --raid-disks=2 /dev/hda5 /dev/hda6
mdadm: array /dev/md0 started.

il messaggio “mdadm: array /dev/md0 started.” indica che il processo di creazione del RAID 0 è stato avviato con successo. Ciò è verificabile consultando il contenuto del file /proc/mdstat :

$ cat /proc/mdstat
Personalities : [raid0]
md0 : active raid0 hda6[1] hda5[0]
      498688 blocks 64k chunks
 
unused devices: <none>

L’output mostra come tra le “Personalities” (i tipi di raid disponibili) sia presente il RAID 0 e che la controller software gestisce la device md0 che poggia su di un Raid0 formato da hda5 e hda6 (nell’ordine sono i dischi con identificativo 0 e 1).
La device md0 è composta da 498.688 blocchi (ciascuno da 1024 byte), per un totale di circa 500 Mb che equivale alla somma delle dimensioni dei nostri dischi.
L’ultimo valore mostrato è la “Chunck size” che riguarda la dimensione dei blocchi minima registrabile su ciascun disco dell’array. Ad esempio se va registrato un dato da 128k, il sistema registrerà 64k sul primo disco ed i rimanenti 64 sul secondo. Nel caso del Raid1 la chunk size non viene indicata in quanto i dati registrati non devono essere divisi per i dischi ma replicati così come sono su ciascuno di questi. Nel RAID 5 la chunk size è la dimensione del blocco di parità.

RAID 1

Nell’ambito della creazione di un RAID 1 il comando non cambierà di molto, l’unico parametro differente sarà “level” per il quale andrà indicato 1, il numero corrispondente al RAID “striping” :

$ mdadm --create /dev/md0 --level=1 --raid-disks=2 /dev/hda5 /dev/hda6
mdadm: array /dev/md0 started.

Anche in questo caso è possibile seguire lo stato del nuovo RAID creato :

$ cat /proc/mdstat
Personalities : [raid0] [raid1]
md0 : active raid1 hda6[1] hda5[0]
      249344 blocks [2/2] [UU]
      [=================>...]  resync = 86.0% (216000/249344) finish=0.0min speed=6156K/sec
 
unused devices: <none>

Si nota dall’output ottenuto che la device md0 è in stato “resync”. Perché a differenza del RAID 0, unico RAID che non prevede la replicazione dei dati, i due dischi devono sincronizzarsi, processo per il quale, a seconda della grandezza relativa alle partizioni impiegate, è necessario del tempo.
Terminato il “resync”, il contenuto di mdstat sarà il seguente :

$ cat /proc/mdstat
Personalities : [raid0] [raid1]
md0 : active raid1 hda6[1] hda5[0]
      249344 blocks [2/2] [UU]
 
unused devices: <none>

Adesso il RAID 1 è completamente attivo. L’output rispetto alle operazioni precedenti è leggermente differente, infatti oltre alle informazioni relative al tipo di raid impiegato ed al numero di blocchi disponibili nella device md0 esistono anche due voci che indicano lo stato dei dischi che fanno parte del RAID. La voce [2/2] indica con il primo numero il totale dei dischi che fanno parte dell’array ed il secondo il numero di device attive nell’array. La voce [UU] indica invece che entrambi i dischi sono in stato “Up”. Come vedremo in seguito, se uno dei dischi entra in stato “Failure” la lettera “U” verrà rimpiazzata dal carattere “_”.

RAID 4

La creazione di un Raid4 implica che le partizioni impiegate debbano essere tre o più. Una di queste andrà dichiarata come “spare” e conterrà le informazioni di parità :

$ mdadm --create /dev/md0 --level=4 --raid-disks=2 /dev/hda5 /dev/hda6 --spare-disks=1 /dev/hda
mdadm: array /dev/md0 started.

Osservando attraverso il filesystem /proc lo stato del RAID, si nota come le partizioni hda6 ed hda5 risultano entrambe in stato UP, mentre è in corso la sincronizzazione della partizione hda7, che presenta la dicitura “(S)” che sta ad indicare come questa sia la partizione di spare :

$ cat /proc/mdstat
Personalities : [raid0] [raid1] [raid5]
md0 : active raid5 hda7[2](S) hda6[1] hda5[0]
      249344 blocks level 4, 64k chunk, algorithm 0 [2/2] [UU]
      [=================>...]  resync = 88.1% (220368/249344) finish=0.0min speed=6485K/sec
 
unused devices: <none>

Quando l’operazione di sincronizzazione verrà completata lo stato del RAID sarà il seguente :

$ cat /proc/mdstat
Personalities : [raid0] [raid1] [raid5]
md0 : active raid5 hda7[2](S) hda6[1] hda5[0]
      249344 blocks level 4, 64k chunk, algorithm 0 [2/2] [UU]
 
unused devices: <none>

RAID 5

Anche nel caso di un Raid5 le partizioni impiegate devono essere tre o più di tre :

$ mdadm --create /dev/md0 --level=5 --raid-disks=3 /dev/hda5 /dev/hda6 /dev/hda7
mdadm: array /dev/md0 started.

A differenza delle precedenti operazioni di “resync”, la controller software effettua un “recovery”. Questo perché il Raid5 non replica i dati in maniera lineare tra i dischi impiegati ma li divide gestendone la parità :

$ cat /proc/mdstat
Personalities : [raid0] [raid1] [raid5]
md0 : active raid5 hda7[3] hda6[1] hda5[0]
      498688 blocks level 5, 64k chunk, algorithm 2 [3/2] [UU_]
      [================>....]  recovery = 84.0% (209920/249344) finish=0.1min speed=3463K/sec
 
unused devices: <none>

Terminata la fase di “recovery” lo stato del Raid5 sarà il seguente :

$ cat /proc/mdstat
Personalities : [raid0] [raid1] [raid5]
md0 : active raid5 hda7[2] hda6[1] hda5[0]
      498688 blocks level 5, 64k chunk, algorithm 2 [3/3] [UUU]
 
unused devices: <none>

I blocchi impiegati in questo livello sono 498688, corrispondenti a circa 500 Mb, come nell’esempio del Raid0, con la sola differenza che le partizioni impiegate in questo caso sono tre e che quindi il totale di spazio disponibile equivale a due terzi della somma delle dimensioni delle tre partizioni.
La “chunk size” è la stessa, mentre viene indicato il tipo di algoritmo utilizzato dalla controller software che è 2 ed equivale al default. Se approfondendo i metodi di gestione della parità (che non verranno trattati nell’articolo) si volessero scegliere altri tipi di algoritmo implementabili, basterà in fase di creazione dell’array indicare con il parametro “–parity” il tipo di algoritmo desiderato.

SET FAULTY o come simulare la sostituzione di un disco :

Prima di procedere con la creazione del filesystem sulla device md0 creata, verrà simulato il crash di un disco all’interno del Raid5 appena creato, in modo da capire come agire in questo tipo di situazioni.
Supponiamo infatti che anziché essere tre partizioni locali, queste siano divise in tre dischi distinti.
Forziamo il malfunzionamento della prima partizione dell’array, hda5 :

$ mdadm /dev/md0 --set-faulty /dev/hda5
mdadm: set /dev/hda5 faulty in /dev/md0

Il RAID 5 è ancora attivo, ma sta funzionando con solo due partizioni su tre. In caso di rottura di un’ulteriore disco, cesserebbe di funzionare :

$ cat /proc/mdstat
Personalities : [raid0] [raid1] [raid5]
md0 : active raid5 hda7[2] hda6[1] hda5[3](F)
      498688 blocks level 5, 64k chunk, algorithm 2 [3/2] [_UU]
 
unused devices: <none>

[_UU] indica che i dischi disponibili sono due su tre ed il primo di questi non sta funzionando.
Procediamo quindi con la rimozione dall’array e successivamente con la rimozione fisica dalla macchina :

$ mdadm /dev/md0 --remove /dev/hda5
mdadm: hot removed /dev/hda5

A questo punto, una volta collegato il nuovo disco, questo andrà reintrodotto nell’array :

$ mdadm /dev/md0 --add /dev/hda5
mdadm: hot added /dev/hda5

La controller di sistema inizierà ad effettuare il “recovery” del nuovo disco introdotto ed al termine di questa operazione, l’array sarà nuovamente attivo :

$ cat /proc/mdstat
Personalities : [raid0] [raid1] [raid5]
md0 : active raid5 hda5[0] hda7[2] hda6[1]
      498688 blocks level 5, 64k chunk, algorithm 2 [3/3] [UUU]
 
unused devices: <none>

[UUU] indica infatti che i tre dischi sono di nuovo attivi.

Registrare la struttura del RAID

Durante la creazione del RAID mdadm ha registrato su ogni disco facente parte dell’array il “Persistent SuperBlock”. Quest’area, posta all’inizio del disco, memorizza le informazioni di appartenenza del disco all’interno del RAID. Questo consente al kernel di rilevare la struttura del RAID in fase di boot senza doversi leggere le informazioni da un file di configurazione ed ovviamente facilita la possibilità di far risiedere la partizione root su RAID.
Può succedere però che in caso di rottura di uno dei dischi si debba ricostruire la struttura senza le informazioni presenti nel “Persistent Superblock”.
Per ovviare a questo inconveniente è consigliabile registrare le informazioni del RAID creato all’interno del file /etc/mdadm.conf, che verrà consultato solo all’occorrenza.
I semplici passi da seguire sono questi :

$ echo 'DEVICE /dev/hda[567]' > /etc/mdadm/mdadm.conf
$ mdadm  --examine  --scan --config=mdadm.conf >> /etc/mdadm/mdadm.conf

A questo punto il file mdadm.conf conterrà quanto segue :

$ cat /etc/mdadm/mdadm.conf
DEVICE /dev/hda[567]
ARRAY /dev/md0 level=raid5 num-devices=3 UUID=59e81780:c30962ed:c4aa02bd:4dd9dcae

Ovviamente il parametro “DEVICE” rispecchia gli esempi proposti sinora, se si impiegheranno dischi diversi questi andranno indicati con le stesse modalità. Se nell’array che si è costruito vengono utilizzate ad esempio le partizioni hda1, hda2 e hdb1 e hdb2 e hdc3, il parametro “DEVICE” sarà il seguente :

DEVICE /dev/hd[ab][12] /dev/hdc3

Creare un filesystem sulla device /dev/md0

L’ultimo passo da effettuare prima di cominciare ad utilizzare l’array per la registrazione di dati è quello di creare un filesystem sulla device /dev/md0 :

$ mke2fs -j /dev/md0
mke2fs 1.39-WIP (31-Dec-2005)
Etichetta del filesystem=
Tipo SO: Linux
Dimensione blocco=1024 (log=0)
Dimensione frammento=1024 (log=0)
124928 inode, 498688 blocchi
24934 blocchi (5.00%) riservati per l'utente root
Primo blocco dati=1
61 gruppi di blocchi
8192 blocchi per gruppo, 8192 frammenti per gruppo
2048 inode per gruppo
Backup del superblocco salvati nei blocchi:
        8193, 24577, 40961, 57345, 73729, 204801, 221185, 401409
...
...

A questo punto, montando la device su una directory locale, il filesystem sarà disponibile per l’utilizzo nel sistema :

$ mount /dev/md0 /raid5
$ df -h /raid5/
Filesystem         Dimens. Usati Disp. Uso% Montato su
/dev/md0              472M  8,1M  440M   2% /raid5

Per rendere permanente la disponibilità del filesystem sarà necessario aggiungere la seguente riga in /etc/fstab :

/dev/md0        /raid5          ext3    defaults        0       0

Ad ogni riavvio del sistema, il RAID verrà montato nella directory /raid5.

Monitorare i RAID

In Debian, oltre ad avere un eseguibile richiamabile da linea di comando, il pacchetto mdadm contiene anche un demone che monitora lo stato dei RAID e segnala con una e-mail eventuali malfunzionamenti. La configurazione di questo demone è contenuta nel file /etc/default/mdadm :

START_DAEMON=true
MAIL_TO="root"
AUTOSTART=true

I parametri sono auto esplicativi, si può scegliere se avviare mdadm come un demone, a quale mail segnalare malfunzionamenti ed infine se il demone si deve avviare durante il boot di sistema.
Per le distribuzioni che non prevedono l’impiego di un demone per la gestione delle notifiche di malfunzionamento, è comunque possibile monitorare lo stato dei RAID passando il parametro “–monitor” al comando mdadm :

$ mdadm --monitor –mail=casella@dominio.com --delay=1800 /dev/md0

Conclusioni

Nel prossimo articolo verranno presentate diverse soluzioni per mettere in Raid la partizione / del filesystem.

Note

Questa serie di articoli è apparsa in origine nel libro edito da Duke Italia Clustering e raid software allegato all’edizione italiana di Linux Journal dell’Ottobre 2006.

]]> http://www.miamammausalinux.org/2009/03/raid-software-proteggere-i-dati-con-l%e2%80%99aiuto-del-kernel-2-di-5/feed/ 3 RAID Software : Proteggere i dati con l’aiuto del kernel (1 di 5) http://www.miamammausalinux.org/2009/03/raid-software-proteggere-i-dati-con-laiuto-del-kernel-1-di-5/ http://www.miamammausalinux.org/2009/03/raid-software-proteggere-i-dati-con-laiuto-del-kernel-1-di-5/#comments Wed, 11 Mar 2009 09:31:08 +0000 Raoul Scarazzini http://www.miamammausalinux.org/?p=543 linux

In questo saggio verranno analizzate le diverse tipologie di RAID esistenti e come queste possano essere implementate in Linux attraverso il kernel ed il programma mdadm.
Attraverso poi l’illustrazione di due storie di successo, verranno presentate delle soluzioni di RAID che permettano di gestire dei backup programmati e di avere sistemi ad alta affidabilità che gestiscano quantità di dati nell’ordine dei TeraByte.
In questa prima parte verranno illustrate le diverse tipologie di RAID ed analizzati i concetti di parità per la gestione della ridondanza.

RAID : Redundant Array of Inexpensive Disks

Quando si parla di RAID, in italiano “batteria ridondante di dischi a basso costo”, si intende una collezione di due o più dischi sui quali vengono registrati dei dati secondo determinati livelli logici. Tali livelli sono generalmente gestiti attraverso hardware specifico, in alcuni casi integrato nelle schede madri ed in altri presente in schede esterne denominate controller.
Meno frequente è l’impiego di sistemi RAID gestiti via software. Tali sistemi, grazie alla rapida evoluzione dei software non rappresentano più qualcosa di pionieristico e con l’abbassamento del costo dell’hardware, studiare soluzioni affidabili che impieghino RAID software è sicuramente una scelta vincente.
Linux può funzionare da controller RAID software nella stessa maniera in cui funzionano quelle hardware. Tutto questo è reso possibile oltre che dalla struttura del kernel, anche dall’elevata potenza di calcolo dei moderni processori (anche di fascia medio-bassa) che consentono di gestire i dati registrati sui dischi non riducendo in maniera sensibile le performance del sistema.
Ma lo sfruttamento delle potenzialità del kernel Linux non si ferma qui. Esistono progetti Opensource che consentono estendere le funzionalità di RAID verso obiettivi insperati. E’ il caso del progetto “DRBD”, che consente la creazione di RAID su computer diversi connessi in rete (in soluzioni ad alta affidabilità).
Come tutto questo sia applicabile alla realtà verrà illustrato nelle prossime pagine.

I livelli di RAID disponibili in Linux

I livelli di RAID implementabili via software attraverso il kernel Linux sono essenzialmente quattro. Quale livello utilizzare dipende essenzialmente da tre fattori che sono la disponibilità di dischi, la sicurezza e le prestazioni. Definita l’importanza di questi fattori, si potrà proseguire nell’analisi delle soluzioni disponibili.

RAID 0 (Striping)

Viene impiegato laddove si hanno a disposizione un minimo di due dischi approssimativamente della stessa grandezza. La capacità di memoria viene combinata tramite la suddivisione in blocchi dei dati su dischi diversi. L’accesso ai blocchi può avvenire parallelamente, garantendo performances ottimali. Inconveniente di questo tipo di RAID è che non esiste ridondanza, che significa perdita dei dati in caso di malfunzionamento di uno dei dischi.

Figura1

Figura1

RAID 1 (Mirroring)

Viene scelto generalmente quando non si può prescindere dall’integrità dei dati. La struttura prevede l’esistenza di due dischi, l’uno replica esatta dell’altro. Il dato viene scritto su entrambi i dischi e se uno dei due cessa di funzionare, l’informazione rimane comunque disponibile sull’altro. A sfavore di questa scelta sono la limitazione dello spazio disponibile (in pratica quello di un solo disco) e la perdita di performances in caso di massicce scritture.

Figura2

Figura2

RAID 4 (Dedicated parity)

Questa tipologia di RAID si rifà al concetto di parità dedicata. Su uno dei tre, o più dischi impiegati, verranno registrate le informazioni di parità, ossia le informazioni che servono a preservare la ridondanza dei dati.
Ad esempio utilizzando tre dischi (Figura3), i dati verranno distribuiti sui primi due mentre il terzo conterrà le parità. In caso di rottura di uno dei tre dischi, se questo è uno dei due contenente i dati, una volta sostituito, potrà essere ricostruito partendo dalle informazioni di parità. Se invece a rompersi sarà il disco di parità, i dati saranno ancora accessibili, ma nel nuovo disco andranno ricalcolate le stesse.
La sicurezza è legata, quindi, all’affidabilità dei dischi ed in particolare al disco di parità, rotto quello, il RAID assume uno stato instabile. Le prestazioni sono elevate in quanto è possibile l’accesso parallelo a blocchi su dischi differenti. Lo spazio disponibile sarà la somma delle dimensioni di tutti i dischi escluso quello di parità.

Figura3

Figura3

RAID 5 (Distributed parity)

Il RAID 5 differisce dal RAID 4 solo nel fatto che le informazioni di parità anziché essere registrate su di un disco a parte sono invece distribuite su tutti i dischi facenti parte dell’array. Anche in questo caso devono esserci un minimo di tre dischi, ed in caso di rottura di uno dei tre, i dati contenuti in questo saranno ricostruiti partendo dalle informazioni di parità presenti negli altri due (Figura4).
Il livello garantisce sicurezza e performances, ma sono necessari un minimo di tre dischi per la sua realizzazione. Lo spazio disponibile sarà anche in questo caso la somma delle dimensioni di tutti i dischi meno uno (che rappresenta le parità distribuite tra i dischi).

Figura4

Figura4

Oltre ai livelli illustrati, Linux rende disponibile anche il livello Linear che prevede la concatenazione dei dischi sulla linea del Raid 0 ma senza scritture parallele (in pratica quando un disco viene riempito, si passa al successivo) ed il livello 6, un livello 5 con parità raddoppiata. E’ difficile vedere entrambi impiegati in ambienti di produzione e pertanto non verranno trattati negli esempi.

Il calcolo delle parità

Prima di proseguire è necessario approfondire il discorso relativo al calcolo delle parità.
La parità viene ottenuta attraverso il risultato di un’operazione di XOR sui bit che fanno parte dell’informazione. Un’operazione di XOR tra due bit fornisce risultato 0 quando i due bit hanno uguale valore (cioè sono entrambi 1 o entrambi 0), mentre restituisce 1 quando i bit hanno valori opposti (il primo 1 ed il secondo 0, o viceversa).
Si supponga che A, B, C e D rappresentino quattro dischi impiegati in un ipotetico Raid4 mentre “P” rappresenti il disco contenente le parità :

A B C D  P
1 0 0 1  0
0 0 0 1  1
0 0 1 1  0
0 1 1 0  0

Il valore contenuto nella colonna P è il risultato delle operazioni di XOR. Nella prima riga il bit di A è 0, in XOR con il bit di B 0 che risulta 1, che in XOR con il bit C 0 risulta 1, che in XOR con il bit di D 1 risulta 0. 0 è il bit di parità. La verifica immediata la si ottiene facendo il percorso inverso. Simulando cioè un disco in stato “failure” che viene rimpiazzato :

A B C D  P
1 0 X 1  0
0 0 X 1  1
0 0 X 1  0
0 1 X 0  0

il valore del bit C sarà il seguente :

C = (((P XOR D) XOR B) XOR A)

Per la prima riga ad esempio :

C = (((0 XOR 1) XOR 0) XOR 1) = 0

Compreso questo si capisce come l’informazione di parità consenta di ricostruire il dato presente sul disco guasto partendo dal confronto con il dato associato ancora presente.
L’applicazione di quanto dimostrato è visibile in Figura3 e Figura4.

Conclusioni

Terminata la panoramica teorica delle soluzioni RAID, nel prossimo articolo queste verranno applicate alla realtà di Linux.

Note

Questa serie di articoli è apparsa in origine nel libro edito da Duke Italia Clustering e raid software allegato all’edizione italiana di Linux Journal dell’Ottobre 2006.

]]> http://www.miamammausalinux.org/2009/03/raid-software-proteggere-i-dati-con-laiuto-del-kernel-1-di-5/feed/ 1 Postfix in alta affidabilità e massima performance con heartbeat, LVS ed ldirectord (4 di 4) http://www.miamammausalinux.org/2008/10/postfix-in-alta-affidabilita-e-massima-performance-con-heartbeat-lvs-ed-ldirectord-4-di-4/ http://www.miamammausalinux.org/2008/10/postfix-in-alta-affidabilita-e-massima-performance-con-heartbeat-lvs-ed-ldirectord-4-di-4/#comments Mon, 13 Oct 2008 06:32:45 +0000 Raoul Scarazzini http://www.miamammausalinux.org/?p=272 postfix    linux-ha    lvs

L’ultima fase del progetto prevede l’installazione di Postfix su tutti i real server ed il loro bilanciamento attraverso ldirectord. Postfix verrà configurato in modo che le caselle risiedano in un’area condivisa ed i profili dei domini e delle caselle vengano registrati in maniera centralizzata all’interno di un database MySQL. Il tutto verrà gestito dall’interfaccia web offerta dal programma postfixadmin.

Requisito essenziale per la riuscita di questa fase del progetto è la disponibilità di un server per lo storage e di un database che siano condivisi ed accessibili da tutti i real server, così come illustrato nello schema riassuntivo presentato nel primo articolo di questa serie.

Configurazione dello storage condiviso via NFS

Ai fini della buona riuscita del progetto è essenziale che le caselle di posta che verranno servite dalla batteria di server risiedano fisicamente nella stessa posizione. Questo significa che la directory nella quale il servizio postfix di ciascun real server scriverà i messaggi monterà uno storage comune. Questo potrà essere uno share NFS (Network File System), un NAS (Network Attached Storage) o un qualsiasi altro supporto di memorizzazione che sia condivisibile.

Nel caso in oggetto, lo storage comune è di tipo NFS e condivide una cartella nominata “mail” erogata dal server 192.168.0.150. La directory locale nella quale sarà montato tale share è /usr/local/virtual e quindi la riga da aggiungere in ciascun real server nel file /etc/fstab è:

192.168.0.150:/mail     /usr/local/virtual    nfs    rw,bg,vers=3    0 0

I questo modo ad ogni riavvio il filesystem NFS verrà automaticamente montato. Per effettuare il primo mount è sufficiente lanciare il comando come segue:

mount /usr/local/virtual

Configurazione del database condiviso con postfixadmin

Per fare in modo che tutti i real server possano leggere i profili in maniera centralizzata sarà necessario predisporre un database MySQL con una struttura adeguata a supportare la registrazione di tutti i dati relativi al server di posta. Tale server non potrà essere uno dei real server (così come per lo storage condiviso), in quanto una situazione simile annullerebbe la ridondanza implicita nella soluzione sviluppata sinora.

Esiste un progetto Open Source denominato postfixadmin che consente di creare e gestire il database relativo ad un server di posta Postfix attraverso un’intuitiva interfaccia web. Tale software è disponibile presso l’indirizzo http://postfixadmin.sourceforge.net/ e può essere installato su una qualsiasi macchina che possieda un webserver apache installato (ad esempio uno dei real server configurati nello scorso articolo). Una volta reperito il pacchetto sarà sufficiente decomprimerlo nella cartella relativa alla document root del sito erogato da apache:

cd /var/www
wget http://kent.dl.sourceforge.net/sourceforge/postfixadmin/postfixadmin-2.2.1.1.tar.gz
tar -xzvf postfixadmin_2.2.1.1.tar.gz
ln -s postfixadmin-2.2.1.1 postfixadmin

Sul server MySQL andrà creato il database relativo a postfix, attivando la console mysql:

mysql -u root -p

e lanciando i comandi SQL di creazione ed accesso relativi al database:

mysql> CREATE DATABASE postfix;
mysql> CREATE USER 'postfix'@'localhost' IDENTIFIED BY 'password_scelta';
mysql> GRANT ALL PRIVILEGES ON `postfix` . * TO 'postfix'@'192.168.0.50';
mysql> GRANT ALL PRIVILEGES ON `postfix` . * TO 'postfix'@'192.168.0.51';
mysql> GRANT ALL PRIVILEGES ON `postfix` . * TO 'postfix'@'192.168.0.52';
mysql> FLUSH PRIVILEGES;

Da notare come per l’accesso vengono configurati TUTTI i real server, in quanto ciascuno di questi dovrà poter accedere al database per la gestione delle informazioni dei profili. Nel file config.inc.php andranno quindi configurate le informazioni d’accesso al database modificando le seguenti righe:

$CONF['configured'] = true;
$CONF['database_type'] = 'mysql';
$CONF['database_host'] = 'localhost';
$CONF['database_user'] = 'postfix';
$CONF['database_password'] = 'chosen_password';
$CONF['database_name'] = 'postfix';

Collegandosi alla pagina di setup http://192.168.0.50/postfixadmin/setup.php verranno effettuati tutti i controlli sul sistema. Se questi avranno esito positivo, lo script creerà tutte le tabelle necessarie nel database postfix e consentirà di creare l’utente amministratore direttamente dall’interfaccia web. L’ultimo accorgimento necessario, prima di procedere con l’utilizzo dell’interfaccia, sarà quello di cancellare il file setup.php dalla directory di postfixadmin:

cd /var/www/postfixadmin
rm setup.php

La configurazione lato MySQL è così completa ed è accessibile attraverso l’interfaccia web. Da questa si potranno creare i domini, le caselle e gli alias che il server di posta dovrà gestire.

Installazione e configurazione di Postfix

L’installazione e la configurazione di Postfix deve essere effettuata su ciascuno dei server reali in maniera identica. Essa comprende il pacchetto base ed il modulo per l’integrazione con mysql:

apt-get install postfix postfix-mysql

La directory in cui i file di configurazione vengono registrati è /etc/postfix ed il file essenziale per il funzionamento di postfix è mail.cf. All’interno di questo file andrà definito il metodo di accesso ai profili ed alle risorse. Nel dettaglio i parametri essenziali da configurare riguardano quali reti fanno parte del sistema e quindi potranno sfruttare il mailserver per l’invio dei messaggi:

mynetworks = 127.0.0.0/8 192.168.0.0/24

Dove verranno archiviati i messaggini di posta ricevuti (mount NFS condiviso):

use_mbox = no
home_mailbox = /usr/local/virtual

E dove potranno essere reperite le informazioni relative ai profili:

virtual_alias_maps = mysql:/etc/postfix/mysql/virtual_alias_maps.cf
virtual_gid_maps = static:106
virtual_mailbox_base = /usr/local/virtual
virtual_mailbox_domains = mysql:/etc/postfix/mysql/virtual_domains_maps.cf
virtual_mailbox_limit = 1151200000
virtual_mailbox_maps = mysql:/etc/postfix/mysql/virtual_mailbox_maps.cf
virtual_minimum_uid = 105
virtual_transport = virtual
virtual_uid_maps = static:105

La dicitura mysql: indica che le informazioni relative al parametro sono contenute nel file con estensione cf indicato. Nel dettaglio i file indicati andranno creati nel path /etc/postfix/mysql come segue:

/etc/postfix/mysql/virtual_alias_maps.cf :

user = postfix
password = password_scelta
hosts = 192.168.0.200
dbname = postfix
table = alias
select_field = goto
where_field = address

/etc/postfix/mysql/virtual_domains_maps.cf :

user = postfix
password = password_scelta
hosts = 192.168.0.200
dbname = postfix
table = domain
select_field = description
where_field = domain
additional_conditions = and backupmx = '0' and active = '1'

/etc/postfix/mysql/virtual_mailbox_maps.cf :

user = postfix
password = password_scelta
hosts = 192.168.0.200
dbname = postfix
table = mailbox
select_field = maildir
where_field = username
additional_conditions = and active = '1'

Come è facilmente intuibile quanto indicato nei vari file sono i dati di accesso al database con i relativi nomi di tabella, di campo e le condizioni per estrapolare le informazioni relative ad alias, domini e mailbox servite da Postfix. Prima di avviare il servizio è necessaria un’ultima precisazione in merito ai permessi. Infatti Postfix scriverà nella cartella indicata nel parametro home_mailbox attraverso il suo utente, “postfix” appunto, che è stato creato durante l’installazione del pacchetto :

id postfix
uid=105(postfix) gid=106(postfix) gruppi=106(postfix),1(daemon)

Questo comporta che l’utente postfix ed il gruppo postfix devono avere lo stesso uid di sistema su tutti i real server, poiché ciascuno di questi si troverà nella condizione di scrivere nell’area condivisa. Essenziale sarà quindi assegnare la cartella /usr/local/virtual all’utente postfix:

chown postfix:postfix /usr/local/virtual

e che l’id dell’utente e del gruppo sia allineato su tutti i real server. Se le utenze hanno id disallineati è possibile correggere la situazione con i seguenti comandi:

groupmod -g 106 postfix
usermod -u 105 -g 106 postfix

Terminati questi ultimi controlli sarà possibile avviare il servizio postfix su ciascun real server:

/etc/init.d/postfix start

Aggiunta del servizio postfix ad ldirectord

A completamento del progetto l’attenzione viene spostata sui server nei quali è configurato il servizio di bilanciamento in alta affidabilità. All’interno del file /etc/ha.d/ldirectord.cf andranno così aggiunte le righe relative al servizio smtp:

virtual=192.168.0.100:25
real=192.168.0.50:25 gate
real=192.168.0.51:25 gate
real=192.168.0.52:25 gate
service=smtp
scheduler=wlc
persistent=600
protocol=tcp

Rimandando all’articolo precedente per i dettagli relativi a ciascun parametro dichiarato va solamente precisato che il tipo di scheduler selezionato è quello di default, “wlc”, ossia Weighted Least-Connection, che assegna più lavori ai server con minor numero di lavori attivi ed in base al peso che è stato loro assegnato. La configurazione verrà automaticamente attivata al salvataggio del file per via delle impostazioni illustrate nello scorso articolo e dopo alcuni secondi sarà possibile verificare come le nuove regole siano attive:

/sbin/ipvsadm -L -n
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
-> RemoteAddress:Port           Forward Weight ActiveConn InActConn
TCP  192.168.0.100:80 rr
-> 192.168.0.50:80              Route   1      0          0
-> 192.168.0.51:80              Route   1      0          0
-> 192.168.0.52:80              Route   1      0          0
TCP  192.168.0.100:25 wlc persistent 600
-> 192.168.0.50:25              Route   1      0          0
-> 192.168.0.51:25              Route   1      0          0
-> 192.168.0.52:25              Route   1      0          0

Quanto visualizzato conferma che il bilanciamento sta avvenendo per la porta 25 su tutti e tre i server reali configurati.

Test di funzionamento

Così come per il servizio apache, la prima verifica effettuabile sui server reali è quella di mettersi in ascolto sui log di postfix e controllare che le richieste pervenute all’indirizzo bilanciato siano correttamente distribuite:

tail -f /var/log/mail.info

Nei log scritti e visualizzati si dovranno distinguere due diverse tipologie di richieste pervenute, la prima rappresenta connessioni volte all’utilizzo del mail server per il ricevimento o la spedizione di un messaggio:

...
...
Oct  9 12:32:33 real-server-1 postfix/smtpd[30095]: 9325D106103: client=mail.xxxxxxxx.xxx[XX.XXX.XX.XXX]
Oct  9 12:32:33 real-server-1 postfix/cleanup[29792]: 9325D106103: message-id=<449745e7dc352554f0cc511e7cece2ce@localhost.localdomain>
Oct  9 12:32:33 real-server-1 postfix/qmgr[23253]: 9325D106103: from=<sender@xxxxxxxx.xxx>, size=1820, nrcpt=1 (queue active)
Oct  9 12:32:33 real-server-1 postfix/smtpd[30095]: disconnect from mail.xxxxxxxx.xxx[XX.XXX.XX.XXX]
...
...

La seconda tipologia rappresenta le connessioni effettuate dal bilanciatore volte a capire se il real server è responsivo e può ricevere lavori:

...
...
Oct  9 12:32:34 real-server-1 postfix/smtpd[30099]: connect from ha-balancer-1[192.168.0.1]
Oct  9 12:32:34 real-server-1  postfix/smtpd[30099]: disconnect from ha-balancer-1[192.168.0.1]
...
...

Chiaramente un ulteriore test consiste nello spedire dei messaggi attraverso il server e verificarne il corretto recapito.

Conclusioni

Il progetto presentato può chiaramente essere migliorato ed esteso attraverso l’introduzione di nuove funzionalità per Postfix come antispam e antivirus o con l’aggiunta di nuovi servizi bilanciati come pop3 e imap. Tali soluzioni non sono state descritte in questa serie in quanto oltre ad essere documentate in maniera esaustiva altrove non rappresentano l’obiettivo primario del progetto. La finalità primaria dei quattro articoli presentati è stata quella di dare una traccia piuttosto dettagliata di quelle che sono le potenzialità dei prodotti opensource nell’ambito di soluzioni in alta affidabilità.

La serie comprende questi articoli :

Postfix in alta affidabilità e massima performance con heartbeat, LVS ed ldirectord (1 di 4)
Postfix in alta affidabilità e massima performance con heartbeat, LVS ed ldirectord (2 di 4)
Postfix in alta affidabilità e massima performance con heartbeat, LVS ed ldirectord (3 di 4)
Postfix in alta affidabilità e massima performance con heartbeat, LVS ed ldirectord (4 di 4)

Nota :

Questo articolo è originariamente apparso su Tux Journal nell’Ottobre 2008.

]]> http://www.miamammausalinux.org/2008/10/postfix-in-alta-affidabilita-e-massima-performance-con-heartbeat-lvs-ed-ldirectord-4-di-4/feed/ 0 Postfix in alta affidabilità e massima performance con heartbeat, LVS ed ldirectord (3 di 4) http://www.miamammausalinux.org/2008/10/postfix-in-alta-affidabilita-e-massima-performance-con-heartbeat-lvs-ed-ldirectord-3-di-4/ http://www.miamammausalinux.org/2008/10/postfix-in-alta-affidabilita-e-massima-performance-con-heartbeat-lvs-ed-ldirectord-3-di-4/#comments Thu, 02 Oct 2008 07:05:12 +0000 Raoul Scarazzini http://www.miamammausalinux.org/?p=269 postfix    linux-ha    lvs

La terza fase del progetto prevede la creazione di un servizio bilanciato su una batteria di real server. Verrà trattato il bilanciamento di un servizio di test (Apache 2) per verificare che il carico venga correttamente distribuito sui real server che fanno parte del Linux Virtual Server.

Bilanciamento con Linux

Il bilanciamento del carico con Linux è possibile attraverso Linux Virtual Server, l’insieme di moduli del Kernel progettato per adempiere a questo scopo. Sebbene vi sia la possibilità di configurare il funzionamento di tali moduli attraverso il comando ipvsadm, esiste un programma chiamato ldirectord che consente di impostare regole per il load balancing in maniera automatica partendo da un file di configurazione. Oltre a poter essere configurato affinché effettui il monitoring delle risorse configurate sui real server ldirectord possiede un enorme altro vantaggio: è completamente integrato con heartbeat come risorsa del cluster. Questo significa che associando la risorsa ldirectord all’indirizzo IP virtuale (configurato nella puntata precedente) si potrà avere il servizio di bilanciamento in alta affidabilità, eliminando di fatto lo SPOF (Single Point Of Failure) rappresentato dal bilanciatore operante su un singolo nodo.

Installazione di ldirectord e apache2

L’installazione del pacchetto ldirectord, che comprende tutti gli script necessari all’interfacciamento con heartbeat, può essere effettuata attraverso apt-get:

apt-get install ldirectord-2

tra i file installati insieme al pacchetto particolare attenzione va riservata allo script ldirectord nella cartella /etc/ha.d/resource.d/. Esso infatti è il fulcro dietro al quale opererà il bilanciamento software. Su ciascun real server invece andrà installato il pacchetto apache2 che servirà per i test di bilanciamento:

apt-get install apache2

L’installazione attiverà il demone apache che si metterà in ascolto sulla porta TCP 80.

Configurazione di ldirectord

La configurazione del servizio per convenzione è contenuta nel fie /etc/ha.d/ldirectord.cf ed un esempio della composizione dello stesso si trova nel file /usr/share/doc/ldirectord-2/ldirectord.cf.gz installato con il pacchetto. All’interno del file devono essere presenti un’area generale contenente le direttive globali ed un’area specifica relativa al servizio che si vuole bilanciare. L’area globale contiene le seguenti direttive:

checktimeout=3

Rappresenta i secondi dopo i quali la risorsa non rispondendo viene dichiarata morta.

checkinterval=1

Rappresenta i secondi tra un check e l’altro.

fallback=127.0.0.1:80

Valido solo per i servizi http, indica quale server funzionerà da fallback in caso tutti i server reali vengano dichiarati morti.

autoreload=yes

Stabilisce se ldirectord deve continuamente rileggere il file di configurazione dal disco. Se tale campo è valorizzato a “yes” allora le modifiche effettuate al file di configurazione verranno istantaneamente messe in atto dal demone.

logfile="/var/log/ldirectord.log"
#logfile="local0"

Indica dove verranno scritti i log, se in file predeterminato oppure nei log di sistema (syslog).

quiescent=yes

Permette di stabilire il comportamento di ldirectord di fronte ad un server dichiarato morto, se il valore è “yes” (che è il default), un real server morto non viene rimosso dalla tabella ipvs del kernel, ma il suo peso viene settato a zero, che comporta il non servire più le richieste pervenute al bilanciatore. Se il valore è “no” allora il real server morto viene completamente rimosso dalla tabella ipvs del kernel.

I parametri valorizzati rappresentano il dafult per i real server e possono essere modificati nelle singole dichiarazioni in modo da ottenere l’override degli stessi. Terminata la dichiarazione delle direttive globali l’attenzione è spostata sui servizi bilanciati, che sono dichiarati con una direttiva “virtual”:

virtual=192.168.0.100:80
real=192.168.0.50:80 gate
real=192.168.0.51:80 gate
real=192.168.0.52:80 gate
fallback=127.0.0.1:80 gate
service=http
request="index.html"
receive="It Works!”
virtualhost=www.esempio.com
scheduler=rr
protocol=tcp

Nell’esempio ad essere bilanciato è un servizio http. Questo come ogni virtuale ha tre aspetti essenziali: il metodo con cui le richieste vengono inviate ai real server (parametro real, che definisce il packet forwarding method), il tipo di servizio erogato (parametro service) e la tipologia di bilanciamento (parametro scheduler).

real

Ad un server reale corrisponde un indirizzo IP, una porta ed il metodo con cui i pacchetti passano dal virtuale ai reali. Può essere indicato anche il peso di ciascun real server nel caso in cui se ne possiedano con caratteristiche diverse, tale valore di default è 1 e salvo casi particolari può essere omesso. Essenziale però è il “packet forwarding method” che può essere uno di questi valori:

  • gate: che prevede l’utilizzo del direct routing in cui le richieste arrivano al server reale e questo risponde direttamente al client che ha contattato il servizio bilanciato.
  • masq: che prevede l’utilizzo della tecnica di masquerading (network address translation o NAT), dove le risposte dei server reali passano sempre dal bilanciatore che maschera il traffico in modo che appaia al client come proveniente da se stesso.
  • ipip: che prevede l’incapsulamento dei pacchetti arrivati al server bilanciato per la loro immissione all’interno di una sotto rete composta da interfacce virtuali.

La tipologia prevista nel progetto descritto si rifà al metodo gate in quanto i real server risiedono tutti sulla stessa rete (vedi prima puntata). masq è generalmente impiegato quando i real server ed il bilanciatore risiedono su reti differenti, mentre il metodo ipip è tra i tre il più particolare non verrà trattato in questa serie. Approfondimenti in merito agli argomenti descritti, che riguardano LVS nel dettaglio sono disponibili nell’LVS howto, in particolare ai seguenti link :

Direct routing (gate) : http://www.austintek.com/LVS/LVS-HOWTO/HOWTO/LVS-HOWTO.LVS-DR.html

Tun (ipip) : http://www.austintek.com/LVS/LVS-HOWTO/HOWTO/LVS-HOWTO.LVS-Tun.html

Masquerade (masq): http://www.austintek.com/LVS/LVS-HOWTO/HOWTO/LVS-HOWTO.LVS-NAT.html

Service

Il tipo di servizio associato ad un servizio virtuale può essere uno fra ftp, smtp, http, pop, pops, nntp, imap, imaps, ldap, https, dns, mysql, pgsql, sip e none . Il nome di ogni servizio è autoesplicativo. Ldirectord come scritto in precedenza permette anche di effettuare il monitor dei servizi. Questo significa che un servizio oltre a rispondere alla porta associata (che nell’esempio illustrato è la 80) potrà essere interrogato per restituire dei risultati aspettati. Le quattro righe dell’esempio:

service=http
request="index.html"
receive="It Works!”
virtualhost=www.esempio.com

definiscono che il servizio è di tipo http (service), che per i check dovrà essere contattata la pagina index.html (request) e che all’interno di questa dovrà essere contenuto il testo “It Works!” (receive). Il tutto sarà associato al virtual host www.esempio.com. Se questa richiesta non verrà esaudita, il real server verrà dichiarato morto ed escluso quindi dal bilanciamento.

scheduler

L’ultimo parametro da comprendere è quello dello scheduler che rappresenta la tipologia di bilanciamento adottata dall’indirizzo virtuale. I valori possibili per il tipo di scheduler sono i seguenti:

rr – Robin Robin: Distribuisce i lavori equamente sui real server disponibili.

wrr – Weighted Round Robin: assegna i lavori ai real server in base al loro peso. Ad un peso maggiore da parte del real server corrisponderanno più lavori assegnati. Se i server hanno tutti lo stesso peso allora i lavori saranno distribuiti in forma equa.

lc – Least-Connection: assegna più lavori ai server con minor numero di lavori attivi.

wlc – Weighted Least-Connection: assegna più lavori ai server con minor numero di lavori attivi ed in base al peso che è stato loro assegnato. Questo è il default.

lblc – Locality-Based Least-Connection: assegna lavori destinati allo stesso indirizzo IP al medesimo server se questo non è sovraccarico ed è disponibile, in alternativa assegna i lavori ai real server scarichi, ricordando l’associazione nei futuri assegnamenti.

lblcr – Locality-Based Least-Connection with Replication: assegna i lavori destinati allo stesso indirizzo IP al nodo con il minor numero di lavori attivi nel gruppo di server creato per servire le richieste provenienti da questo. Se tutti i nodi del gruppo di server sono sovraccarichi, il lavoro viene accodato al nodo del cluster con il numero minore di lavori che diventa parte del gruppo di server. Se il gruppo di server non è stato modificato per un tempo specifico, allora il server più carico viene rimosso dal gruppo in modo che possa evadere le richieste in coda e garantire di essere replica alle future richieste.

dh – Destination Hashing: assegna i lavori ai real server basandosi sul controllo di un valore di hash assegnato staticamente in base all’indirizzo IP di destinazione.

sh – Source Hashing: assegna i lavori ai real server basandosi sul controllo di un valore di hash assegnato staticamente in base all’indirizzo IP sorgente.

sed – Shortest Expected Delay: assegna un lavoro entrante al real server dal quale si aspetta il minor tempo di attesa. Il tempo di attesa per un lavoro è calcolato con la formula (Ci + 1) / Ui dove Ci è il numero di lavori sul server stesso e Ui è il peso (weight) di questo definito in configurazione.

nq – Never Queue: assegna un lavoro entrante ad un real server inattivo (se c’è) anziché attendere per un real server veloce. Se tutti i real server sono occupati, adotta la tecnica “sed” (vedi sopra) per assegnare il lavoro.

La scelta del tipo di scheduler dipenderà quindi dalla tipologia di servizi impiegati e del tipo di real server dei quali si dispone. Nel caso illustrato lo scheduler è il più semplice, cioè il round robin che assegnerà le richieste in maniera equa su tutti i real server.

Aggiunta del servizio ldirectord a heartbeat

Per fare in modo che heartbeat gestisca la risorsa ldirectord all’interno del file /etc/ha.d/haresources basterà apportare le seguenti modifiche per entrambi i nodi del cluster:

ha-balancer-1 Ipaddr::192.168.0.100/24/eth0 ldirectord::/etc/ha.d/ldirectord.cf

Quanto aggiunto comprende la dichiarazione della risorsa ed il relativo file di configurazione. Per attivare la nuova configurazione sarà sufficiente effettuare il reload del servizio, sempre su entrambi i nodi del cluster:

/etc/init.d/heartbeat reload

La verifica della corretta aggiunta delle regole relative ad LVS è ottenibile attraverso il comando ipvsadm:

/sbin/ipvsadm -L -n
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
-&gt; RemoteAddress:Port           Forward Weight ActiveConn InActConn
TCP  192.168.0.100:80 rr
-&gt; 192.168.0.50:80              Route   1      0          0
-&gt; 192.168.0.51:80              Route   1      0          0
-&gt; 192.168.0.52:80              Route   1      0          0

Tale output conferma che esiste un indirizzo virtuale che bilancia su tre server reali alla porta 80. Tutti i server reali sono raggiungibili ed hanno perciò peso 1 (non avendo specificato preferenze di peso nella loro dichiarazione) che comporta un’eguale distribuzione dei lavori.

Abilitazione del packet forwarding

L’ultima operazione da svolgere sul bilanciatore è quella dell’abilitazione del packet forwarding, necessario affinché le richieste possano passare attraverso il server. Tale funzionalità si ottiene abilitando la seguente riga:

net.ipv4.conf.default.forwarding=1

nel file /etc/sysctl.conf e forzando un nuovo caricamento di questo file, che trasferirà nel kernel quanto dichiarato:

sysctl -p

Ovviamente le stesse operazioni dovranno essere effettuate sul nodo del cluster passivo.

Modifiche sui server reali

Prima di effettuare i test di funzionamento è necessario apportare le ultime modifiche ai server reali. Infatti questi devono essere configurati in modo da vedere il traffico diretto all’indirizzo virtuale come locale. Per fare ciò sarà necessario creare un alias dell’interfaccia di loopback che abbia l’indirizzo virtuale e che questo indirizzo non venga annunciato via ARP sulla rete. Per rendere possibile tutto questo nel file /etc/sysctl.conf è necessario aggiungere le seguenti righe:

net.ipv4.conf.all.arp_ignore = 1
net.ipv4.conf.eth0.arp_ignore = 1
net.ipv4.conf.all.arp_announce = 2
net.ipv4.conf.eth0.arp_announce = 2

Insieme alla dichiarazione della nuova interfaccia nel file /etc/network/interfaces:

auto lo:0
iface lo:0 inet static
address 192.168.0.100
netmask 255.255.255.255
pre-up sysctl -p > /dev/null

L’ultima riga, che effettua un nuovo caricamento delle regole relative a sysctl, attiva le variazioni sul comportamento ARP a livello di kernel. Tali regole saranno attivate con l’interfaccia, attraverso il comando ifup:

ifup lo:0

Il motivo di queste variazioni è insito nella struttura del progetto: quando una richiesta arriva all’indirizzo virtuale e questo la dirige su un real server sarà il real server stesso a rispondere, per via del fatto di possedere lo stesso indirizzo (nell’interfaccia loopback), questo indirizzo però non dovrà essere annunciato sulla rete in modo da non confondere gli switch ed i router implicati nello smistamento dei pacchetti. Va sottolineato che queste variazioni andranno apportate a tutti i real server facenti parte dell’LVS.

Maggiori dettagli su questo tema che può risultare ostico sono ottenibili ai seguenti link:
http://www.ultramonkey.org/3/topologies/hc-ha-lb-eg.html dove viene descritto un progetto simile.
http://kb.linuxvirtualserver.org/wiki/Using_arp_announce/arp_ignore_to_disable_ARP dove vengono descritte le configurazioni possibili per il comportamento degli annunci ARP.

Test di funzionamento

Il test di funzionamento dell’ambiente consiste nel controllo dei log del servizio apache2 su ciascun real server:

tail -f /var/log/apache2/access.log

Inviando poi richieste al sito a mano oppure attraverso software specifici per i test di carico, come http_load si potrà verificare come le richieste vengano correttamente distribuite sui tre server. Un’ulteriore verifica potrà essere effettuata sul bilanciatore dove l’output prodotto dal comando ipvsadm mostrerà per ciascun real server nei campi “ActiveConn” e “InActConn” un numero diverso da zero.

Conclusioni

Nel prossimo articolo, ultimo di questa serie, verrà infine trattata la configurazione di postfix sui real server e l’inclusione del servizio nel bilanciatore.

La serie comprende questi articoli :

Postfix in alta affidabilità e massima performance con heartbeat, LVS ed ldirectord (1 di 4)
Postfix in alta affidabilità e massima performance con heartbeat, LVS ed ldirectord (2 di 4)
Postfix in alta affidabilità e massima performance con heartbeat, LVS ed ldirectord (3 di 4)
Postfix in alta affidabilità e massima performance con heartbeat, LVS ed ldirectord (4 di 4)

Nota :

Questo articolo è originariamente apparso su Tux Journal nell’Ottobre 2008.

]]> http://www.miamammausalinux.org/2008/10/postfix-in-alta-affidabilita-e-massima-performance-con-heartbeat-lvs-ed-ldirectord-3-di-4/feed/ 0 Postfix in alta affidabilità e massima performance con heartbeat, LVS ed ldirectord (2 di 4) http://www.miamammausalinux.org/2008/09/postfix-in-alta-affidabilita-e-massima-performance-con-heartbeat-lvs-ed-ldirectord-2-di-4/ http://www.miamammausalinux.org/2008/09/postfix-in-alta-affidabilita-e-massima-performance-con-heartbeat-lvs-ed-ldirectord-2-di-4/#comments Wed, 17 Sep 2008 07:26:04 +0000 Raoul Scarazzini http://www.miamammausalinux.org/?p=265 postfix    linux-ha    lvs

Terminata l’introduzione al progetto le attenzioni vengono dirette alla messa in pratica, partendo dall’installazione di heartbeat che si occuperà di gestire in alta affidabilità l’indirizzo virtuale sul quale poi andrà bilanciato il servizio Postfix. I passi che verranno descritti fanno riferimento alla distribuzione Debian Etch e, fatta eccezione per la parti relative alle installazioni dei software che dipendono dal sistema di gestione pacchetti utilizzato, sono adattabili a tutte le maggiori distribuzioni.

Requisiti hardware

Il requisito minimo per avere un servizio in alta affidabilità è quello di due macchine, specularmente configurate e collegate l’una all’altra tramite una scheda di rete dedicata attraverso un cavo incrociato, definito “cross”. Le schede di rete dovranno quindi essere due per ciascuna macchina. Le prime collegate agli switch della LAN si occuperanno di erogare l’indirizzo virtuale, mentre le schede di rete secondarie saranno necessarie per comunicare il battito cardiaco (heartbeat, appunto) tra una macchina e l’altra. Questa struttura consente a ciascuna componente di carpire dati fondamentali sullo stato del sistema: se c’è comunicazione con la rete esterna e se c’è connettività tra le due macchine che compongono il cluster.

Configurazione dei sistemi

Presupponendo che in ciascuno dei sistemi scelti esista già un’interfaccia collegata alla rete locale, andrà configurata l’interfaccia per l’heartbeat, aggiungendo al file /etc/network/interfaces le seguenti linee :

auto eth1
iface eth1 inet static
address 10.0.0.1
netmask 255.255.255.0

Sul nodo secondario del cluster l’indirizzo dovrà ovviamente essere 10.0.0.2. Dopo aver attivato l’interfaccia attraverso il comando :

ifup eth1

sarà possibile testare la connettività attraverso un semplice ping :

ping 10.0.0.2
PING 10.0.0.2 (10.0.0.2) 56(84) bytes of data.
64 bytes from 10.0.0.2: icmp_seq=1 ttl=64 time=0.145 ms
64 bytes from 10.0.0.2: icmp_seq=2 ttl=64 time=0.101 ms
64 bytes from 10.0.0.2: icmp_seq=3 ttl=64 time=0.102 ms
64 bytes from 10.0.0.2: icmp_seq=4 ttl=64 time=0.102 ms

A titolo preventivo è bene inserire nel file /etc/hosts di ciascuna macchina le corrispondenze IP nome host relative ai server di modo che queste siano indipendenti dal DNS :

192.168.0.1	ha-balancer-1.pgol.com	ha-balancer-1
192.168.0.2	ha-balancer-2.pgol.com	ha-balancer-2

Il sistema è quindi predisposto a procedere con l’installazione del pacchetto heartbeat :

apt-get install heartbeat-2

I file essenziali per la configurazione di heartbeat sono essenzialmente tre : ha.cf, haresources ed authkeys e si trovano nella directory /etc/ha.d/.

ha.cf

In ha.cf è necessario includere la configurazione relativa alla struttura del cluster per definire quali sono le sue componenti e come calcolare lo stato di salute del sistema. Ecco come viene compilato il file relativo al progetto, che per le ragioni che verranno spiegate avanti potrà essere identico su entrambe le macchine. Per ciascuna opzione è indicata la descrizione :

keepalive 1

Indica l’intervallo tra un heartbeat e l’altro (1 secondo).

deadtime 14

Indica il numero di secondi dopo i quali heartbeat considererà un nodo morto (14 secondi).

warntime 7

Indica il numero di secondi dopo i quali heartbeat allerterà per un ritardo nella comunicazione con un nodo (7 secondi).

initdead 120

Si riferisce al primo avvio e considera il numero di secondi dopo i quali heartbeat considererà un nodo morto (120 secondi, due minuti).

udpport 694

Indica la porta UDP utilizzata per gli scambi heartbeat.

ucast eth1 10.0.0.1
ucast eth1 10.0.0.2
ucast eth0 192.168.0.1
ucast eth0 192.168.0.2

Le quattro righe relative ad ucast indicano le interfacce locali e gli ip di destinazione che devono essere utilizzate per lo scambio di heartbeat. Nei controlli le interfacce locali ignorate, per questa ragione è possibile avere un file identico per entrambi i nodi specificando tutte le interfacce (ed i relativi ip da contattare) di entrambi i sistemi. In questo caso sono state configurate le interfacce collegate via cavo cross e quelle collegate alla LAN.

auto_failback off

Il parametro determina se una risorsa che è stata presa in carico da un nodo secondario (in seguito alla perdita del nodo primario) debba ritornare sul nodo originario una volta che questo torna attivo.

node    ha-balancer-1
node    ha-balancer-2

Le due righe rappresentano l’elenco delle macchine che fanno parte del cluster, identificate come nodi.

ping_group dmz 192.168.0.50 192.168.0.51 192.168.0.52

Questa opzione è necessaria al cluster per capire se è collegato alla rete locale. La connettività da parte del cluster ad almeno una delle macchine facenti parte del gruppo comporta la conferma che il cluster sia connesso alla rete locale.

respawn hacluster /usr/lib/heartbeat/ipfail

Indica il programma che lancia e controlla lo stato delle interfacce (ipfail è il default).

apiauth ipfail gid=haclient uid=hacluster

Specifica quali utenze possono collegarsi a quali API (in questo caso rimane ancora il default relativo ad ipfail, l’unico ad interessare il progetto in corso. Tali utenze sono create automaticamente dall’installazione di heartbeat.

deadping 30

Specifica il numero di secondi dopo i quali il gruppo di ping (definito dmz) verrà ritenuto morto e quindi assumerà la condizione disconnessa per il cluster.

use_logd off
 
logfile /var/log/ha.log

Per facilità di debug e ordine nei log viene disabilitato l’utilizzo di logd (che avrebbe riempito i log di sistema) e dirottata la scrittura dei log nel file /var/log/ha.log. Chiaramente esistono numerose altre opzioni disponibili per la configurazione del cluster e sono tutte illustrate all’indirizzo http://www.linux-ha.org/ha.cf.

haresources

Il secondo file che completa la configurazione di heartbeat è quello relativo alle risorse, haresources. Ciascuna riga contenuta in questo file rappresenta una risorsa ed il formato della stessa è:

<nodo preferito> <risorsa 1> ... <risorsa n>

nel caso relativo al nostro progetto durante la fase iniziale utilizzeremo solo la risorsa “IpAddr” che controllerà l’attivazione di un indirizzo virtuale associato ad un interfaccia reale (con la relativa classe), che nel proseguo diventerà l’indirizzo bilanciato del servizio Postfix :

ha-balancer-1 IPaddr::192.168.0.100/24/eth0

authkeys

Prima di avviare il servizio cluster è necessario effettuare un ultimo ulteriore passo che consiste nella creazione della chiave che verrà utilizzata da heartbeat per autenticare i nodi che faranno parte del cluster. Le informazioni relative alla chiave sono contenute nel file authkeys, la chiave è ottenibile attraverso questo comando (che sfrutta il generatore casuale di numeri del kernel ed il comando md5sum):

dd if=/dev/urandom count=4 2 > /dev/null | md5sum | cut -c1-32
aea572119260bbe6b87c0386c3cc0f75

tale valore va posto nel file authkeys in questa forma :

auth 1
1 sha1 aea572119260bbe6b87c0386c3cc0f75

La prima riga indica l’identificativo della chiave utilizzata, mentre nella seconda questa viene definita attraverso l’identificativo, il tipo (sha1) ed il valore. Questo file deve essere leggibile dal solo utente di root :

chmod 600 /etc/ha.d/authkeys
chown root:root /etc/ha.d/authkeys

Avvio dei servizi

Terminata la configurazione dei tre file, che dovranno essere identici su ciascuno dei due nodi, è possibile avviare il servizio heartbeat :

/etc/init.d/heartbeat start

è possibile seguire l’evoluzione dell’avvio monitorando il file di log ha.log al cui interno, se i file sono stati compilati a dovere, verranno scritte righe come questa :

heartbeat[4271]: 2008/09/01_09:50:37 info: **************************
heartbeat[4271]: 2008/09/01_09:50:37 info: Configuration validated. Starting heartbeat 2.0.7
...

In breve, dopo i controlli sullo stato dei nodi e la loro connettività, si arriverà all’avvio della risorsa definita :

ResourceManager[4445]:  2008/09/01_09:50:53 info: Running /etc/ha.d/resource.d/IPaddr 192.168.0.100/24/eth0 start
IPaddr[4663]:   2008/09/01_09:50:53 INFO: eval /sbin/ifconfig eth0:0 192.168.0.100 netmask 255.255.255.224 broadcast 192.168.0.255
IPaddr[4663]:   2008/09/01_09:50:53 INFO: Sending Gratuitous Arp for 192.168.0.100 on eth0:0 [eth0]
IPaddr[4663]:   2008/09/01_09:50:53 INFO: /usr/lib/heartbeat/send_arp -i 500 -r 10 -p /var/run/heartbeat/rsctmp/send_arp/send_arp-192.168.0.100 eth0 192.168.0.100 auto 192.168.0.100 ffffffffffff
IPaddr[4581]:   2008/09/01_09:50:53 INFO: IPaddr Success

Il riscontro dell’effettivo funzionamento può essere effettuato sul nodo master relativo al servizio tramite il comando ifconfig :

...
eth0:0    Link encap:Ethernet  HWaddr 00:0F:1F:67:CF:C1
inet addr:192.168.0.100  Bcast:212.48.3.255  Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
Interrupt:177
...

che conferma come l’indirizzo virtuale sia correttamente attivo. Effettuando dei ping sull’indirizzo virtuale da macchine diverse dal nodo master si otterrà un’ulteriore conferma dell’effettivo funzionamento del sistema.

Test di failover

Per controllare l’effettivo funzionamento della struttura del cluster andranno effettuati tre diversi test.

Primo test

Il primo test consiste nell’acquisizione da parte delle risorse da parte del secondo nodo attraverso il seguente comando, da eseguire appunto sul nodo che non detiene la risorsa:

/usr/lib/heartbeat/hb_takeover foreign

questo provocherà lo switch della risorsa sul secondo nodo in maniera trasparente per il sistema:

heartbeat: 2008/09/15_10:38:27 info: acquire foreign HA resources (standby).
...
...
heartbeat: 2008/09/15_10:38:31 info: foreign HA resource acquisition completed (standby).
heartbeat: 2008/09/15_10:38:31 info: Standby resource acquisition done [local].
heartbeat: 2008/09/15_10:38:31 info: remote resource transition completed.

I log dimostrano come la risorsa risieda ora sul nodo secondario.

Secondo test

Il secondo test consiste nel restart del servizio heartbeat sulla macchina in cui è attivo il servizio e la verifica che questo sia correttamente acquisito dal nodo ancora attivo:

/etc/init.d/heartbeat restart

Ancora una volta, attraverso i log si ottiene conferma della corretta esecuzione delle operazioni:

heartbeat: 2008/09/15_10:44:16 info: Received shutdown notice from 'ha-balancer-2'.
heartbeat: 2008/09/15_10:44:16 info: Resources being acquired from 'ha-balancer-2'.
heartbeat: 2008/09/15_10:44:16 info: acquire all HA resources (standby).
heartbeat: 2008/09/15_10:44:16 info: Acquiring resource group: from 'ha-balancer-1'
....
....
heartbeat: 2008/09/15_10:44:43 info: remote resource transition completed.

Terzo test

Il terzo test consiste nello spegnimento improvviso della macchina su cui risiede la risorsa e la verifica che l’unico nodo attivo acquisisca la risorsa. Il comportamento dovrebbe risultare del tutto simile a quello degli altri test, con l’identificazione all’interno dei log delle notifica sulla perdita del nodo che deteneva la risorsa:

heartbeat: 2008/09/15_10:48:31 WARN: node ha-balancer-1: is dead

Conclusioni

Il prossimo articolo tratterà dell’implementazione del servizio di bilanciamento via LVS gestito dalla risorsa ldirectord.

La serie comprende questi articoli :

Postfix in alta affidabilità e massima performance con heartbeat, LVS ed ldirectord (1 di 4)
Postfix in alta affidabilità e massima performance con heartbeat, LVS ed ldirectord (2 di 4)
Postfix in alta affidabilità e massima performance con heartbeat, LVS ed ldirectord (3 di 4)
Postfix in alta affidabilità e massima performance con heartbeat, LVS ed ldirectord (4 di 4)

Nota :

Questo articolo è originariamente apparso su Tux Journal nel Settembre 2008.

]]> http://www.miamammausalinux.org/2008/09/postfix-in-alta-affidabilita-e-massima-performance-con-heartbeat-lvs-ed-ldirectord-2-di-4/feed/ 0