Dopo le esperienze con i prodotti commerciali di HP e SUN per i filesystem condivisi, l’alta disponibilità, clusters, LB etc. etc. (nel mio caso: service guard, vpars, fs veritas, ldoms e altre diavolerie in ambito HPUX e Sun SOLARIS..) ritorno con piacere alla reatà che preferisco di linux e del software open-source e sopratutto alla facilità ed immediatezza della tastiera/console abbandonando almeno per un po’ 😛 quelle maledette freccette, i drags and drops, le caselline introvabili e le acrobazie del mouse su quei costosissimi e sempre uguali web_services_java_based che fanno tutto e di più..
apparte le mie paranoie digitali quindi 😛 cominciamo subito con lo scegliere cosa usare per condividere ai nodi del nostro cluster un unico filesystem..
per realizzare cio’ ho optato per DRBD (dovrebbe essere l’acronimo di distribuited
replicated block device”)..praticamente non è altro che un RAID1 (un mirror)
tra due dispositivi di rete: il suo lavoro è quello di propagare dati da un nodo all’altro(sincronizzare praticamente)..
Partizioniamo su ogni nodo la “parte” che dedicheremo al nostro sistema (non vi dico come si fa, lo sapete già questo) questa partizione verà “letta” dal DRBD che abbiamo installato sul nodo e verà cosi creato il device /dev/drbd*..
lo stesso DRBD poi, attraverso il suo file di configurazione /etc/drbd.conf stabilirà se scrivere o meno sul device in questione (questo in base ai criteri del nodo, se questo è primario allora potrà montare il device in +w).
Per avere una più affidabile configurazione del nostro cluster sarà meglio utilizzare 2 schede di rete ridondanti per ogni nodo, per farlo basterà abilitare il modulo “bonding” del kernel (trovate il modulo sotto “NEtwork device” nel menuconf del kernel) e quindi per ogni nodo del cluster dare:
#modprobe bonding {attiviamo il modulo del kernel linux per il bonding}
#ifconfig bind0 “ip” up {attiviamo l’interfaccia di bonding}
#ifenslave bond0 eth0 eth1 {creiamo il channel bonding nel nostro nodo}
..creeremo quindi anche uno script che faccia il tutto ad ogni riavvio della macchina
in /etc/rc.d/net.bond0 configurando anche /etc/rc.d/ifenslave
(i path ovviamente possono variare a secondo della distribuzione linux che usate 😉
perfetto, dando adesso per scontato che abbiate “fisicamente” predisposto il cluster
[cavo cross tra le schede di rete] [poi vedremo anche di usare un cavo seriale tra
le due porte seriali ;)] e partizionato le 2 porzioni di fs dedicate a DRBD su ogni nodo.
Configurate DRBD [/etc/drbd.conf] seguendo il solito file di configurazione di esempio
e create quindi il famoso device con:
#mknod -m 0760 /dev/drbd0 b 147 0
avviamo il servizio:
#/etc/rc.d/drbd start
montiamo adesso sul primo nodo il device come master:
#drbdadm — –do-what-I-say primary shared
in questa maniera il device è già su ed è possibile,
dal nodo primario, montare su /shared la nostra partizione condivisa con DRBD..
ovviamente se volete potrete anche utilizzare LVM sui due nodi creando il volume
corrispondente al device di DRBD /dev/drbd0 su ogni macchina del cluster.
per poter gestire adesso il failover del nostro servizio nel nostro cluster useremo Heartbeat:
prima di tutto configuriamo sui due nodi, seguendo il solito esempio, il file ha.cf
## /etc/ha.d/ha.cf
keepalive 1
deadtime 20
warntime 3
initdead 20
serial /dev/ttyS0
bcast eth1
auto_failback yes
node host_del_nodo1
node host_del_nodo2
crm no
successivamente configuriamo /etc/ha.d/haresources sui due nodi inserendo le risorse che migreremo tra le due macchine (quindi nel nostro caso l’unico servizio per il failover è quello di drbd):
hostnodo1 drbddisk::shared script_avvio_lvm Filesystem::/dev/drbd0::/shared0::fs_scelto
(se non lo avete fatto: attivate il supporto a watchdog del kernel e create il corrispondente device:
#mknod /dev/watchdog c 10 130 )
per una maggiore sicurezza infine nel file /etc/ha.d/authkeys impostiamo la crittografia dei dati
tra i nodi:
## /etc/ha.d/authkeys
auth 1
1 sha HeartbeatPassword
diamo i permessi:
# chmod 600 /etc/ha.d/authkeys
e infine riconfiguriamo l’altro nodo con le stesse impostazioni oppure
piu semplicemente:
#scp /etc/ha.d/authkeys root@nodo2:/etc/ha.d/
prima di concludere il tutto vi consiglio un breve periodo di test ed infine un buon tuning per
una piu’ appropiriata scelta dei deadtimes di heartbeat e di tutti gli altri parametri e/o dei filesystem per le partizioni di drdb 😉
PS: Appena avro’ tempo scrivero’ qualche altro appunto in merito alla possibilita’ del load-balancing su linux
utilizzando un unico host con LVS e i nodi linux-director 😉
Saluti! 🙂