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
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.
