Mia mamma usa Linux! » NFS http://www.miamammausalinux.org Perché niente è impossibile da capire... Se lo spieghi bene ! Mon, 02 Jan 2012 11:31:44 +0000 en hourly 1 http://wordpress.org/?v=3.3.1 Evoluzione dell’alta affidabilità su Linux: realizzare un NAS con Pacemaker, DRBD ed exportfs http://www.miamammausalinux.org/2010/09/evoluzione-dellalta-affidabilita-su-linux-realizzare-un-nas-con-pacemaker-drbd-ed-exportfs/ http://www.miamammausalinux.org/2010/09/evoluzione-dellalta-affidabilita-su-linux-realizzare-un-nas-con-pacemaker-drbd-ed-exportfs/#comments Mon, 20 Sep 2010 19:40:13 +0000 Raoul Scarazzini http://www.miamammausalinux.org/?p=1128 linux-ha    Pacemaker    

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

Il progetto

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

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

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

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

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

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

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

# pvcreate /dev/sd[ab]3

Ai quali è stato associato un Volume Group denominato vg_share:

# vgcreate vg_share /dev/sd[ab]3

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

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

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

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

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

Configurazione preliminare di Heartbeat

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

/etc/ha.d/ha.cf:

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

/etc/ha.d/authkeys:

auth 1
1 crc

Quindi una volta avviato Heartbeat:

# /etc/init.d/heartbeat start

è possibile definire le configurazioni preliminari del cluster:

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

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

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

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

Configurazione preliminare di DRBD

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

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

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

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

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

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

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

1
2
3
4
5

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

Linea per linea, ecco quanto fatto:

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

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

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

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

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

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

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

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

# update-rc.d -f drbd remove

mentre nel caso di RedHat/CentOS/SuSe:

# chkconfig --level 123456 drbd off

E’ giunto il momento di configurare lo storage condiviso.

Configurazione di Heartbeat e DRBD

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

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

è necessario configurare due risorse multi-state:

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

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

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

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

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

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

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

Indirizzo IP

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

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

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

Filesystem

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

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

Ed infine configurate le risorse attraverso il resource agent Filesystem:

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

NFS

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

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

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

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

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

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

Raggruppare le risorse create

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

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

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

Collocazione, ordinamento e controllo connettività delle risorse

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

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

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

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

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

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

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

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

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

Cleanup finale

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

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

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

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

Creare una configurazione active active

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

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

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

Considerazioni sulla stickiness

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

Ad esempio…

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

crm configure property default-resource-stickiness=INFINITY

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

Configurazione finale

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

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

Test funzionale

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

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

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

cp -av /usr/ /mnt/

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

Primo test: disconnessione cavo LAN nodo master

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

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

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

Secondo test: migrazione manuale delle risorse

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

crm resource migrate share-a debian-lenny-nodo1

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

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

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

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

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

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

Terzo test: spegnimento improvviso nodo master

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

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

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

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

Conclusioni

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

]]> http://www.miamammausalinux.org/2010/09/evoluzione-dellalta-affidabilita-su-linux-realizzare-un-nas-con-pacemaker-drbd-ed-exportfs/feed/ 8 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