DRBD e Heartbeat configurazione su Devuan 5 in ambiente di test —
In realtà la configurazione di DRBD non differisce da quelle precedentemente illustrate, la differenza sostanziale è che al posto di lavorare su una scheda fisica da 1 G lavora su una bond a 10 G e si tratta di una differenza che fa moltissimo in fase di migrazione e di sync.
Ripeto ancora una volta i files devono essere identici sulle due macchine
cat /etc/drbd.conf
include “drbd.d/global_common.conf”;
include “drbd.d/*.res”;
lasciare inalterato il global_common.conf e scrivere il tutto nelle .res
cat /etc/drbd.d/r0.res
resource r0 {
protocol C;
handlers {
pri-on-incon-degr “echo o > /proc/sysrq-trigger ; halt -f”;
pri-lost-after-sb “echo o > /proc/sysrq-trigger ; halt -f”;
local-io-error “echo o > /proc/sysrq-trigger ; halt -f”;
outdate-peer “/usr/lib/heartbeat/drbd-peer-outdater -t 5”;
pri-lost “echo pri-lost. Have a look at the log files. | mail -s ‘DRBD Alert’ service@intranet.lan”;
split-brain “echo split-brain. drbdadm — –discard-my-data connect $DRBD_RESOURCE ? | mail -s ‘DRBD Alert’ service@intranet.lan”;
}
startup {
wfc-timeout 0;
degr-wfc-timeout 120; # 2 minutes.
#become-primary-on both;
}
disk {
on-io-error detach;
no-disk-flushes;
no-disk-barrier;
c-plan-ahead 10;
c-fill-target 24M;
c-min-rate 10M;
c-max-rate 100M;
}
net {
max-buffers 36k;
sndbuf-size 1024k;
rcvbuf-size 2048k;
#max-epoch-size 16000;
#max-buffers 16000;
#unplug-watermark 128;
#sndbuf-size 524288;
allow-two-primaries;
after-sb-0pri discard-zero-changes;
after-sb-1pri discard-secondary;
after-sb-2pri disconnect;
rr-conflict disconnect;
}
syncer {
#rate 150M;
#al-extents 1801;
# 3389
}
on marino {
device /dev/drbd0;
disk /dev/sda7;
address 172.18.19.245:7778;
meta-disk internal;
}
on pedretti {
device /dev/drbd0;
disk /dev/sda7;
address 172.18.19.246:7778;
meta-disk internal;
}
}
cat /etc/drbd.d/r1.res
resource r1 {
protocol C;
handlers {
pri-on-incon-degr “echo o > /proc/sysrq-trigger ; halt -f”;
pri-lost-after-sb “echo o > /proc/sysrq-trigger ; halt -f”;
local-io-error “echo o > /proc/sysrq-trigger ; halt -f”;
outdate-peer “/usr/lib/heartbeat/drbd-peer-outdater -t 5”;
pri-lost “echo pri-lost. Have a look at the log files. | mail -s ‘DRBD Alert’ service@intranet.lan”;
split-brain “echo split-brain. drbdadm — –discard-my-data connect $DRBD_RESOURCE ? | mail -s ‘DRBD Alert’ service@intranet.lan”;
}
startup {
wfc-timeout 0;
degr-wfc-timeout 120; # 2 minutes.
#become-primary-on both;
}
disk {
on-io-error detach;
no-disk-flushes;
no-disk-barrier;
c-plan-ahead 10;
c-fill-target 24M;
c-min-rate 10M;
c-max-rate 100M;
}
net {
max-buffers 36k;
sndbuf-size 1024k;
rcvbuf-size 2048k;
#max-epoch-size 16000;
#max-buffers 16000;
#unplug-watermark 128;
#sndbuf-size 524288;
allow-two-primaries;
after-sb-0pri discard-zero-changes;
after-sb-1pri discard-secondary;
after-sb-2pri disconnect;
rr-conflict disconnect;
}
syncer {
#rate 150M;
#al-extents 1801;
# 3389
after “r0”;
}
on marino {
device /dev/drbd1;
disk /dev/sda8;
address 172.18.19.245:7779;
meta-disk internal;
}
on pedretti {
device /dev/drbd1;
disk /dev/sda8;
address 172.18.19.246:7779;
meta-disk internal;
}
}
Al solito su ambo i nodi:
drbdadm create-md all
drbdadm up all
su uno solo dei nodi:
drbdadm - - - -overwrite-data-of-peer primary all
armarsi di pazienza e nel frattempo configurare heartbeat
apt-get install heartbeat
da notare che heartbeat (deprecato) si porta dietro corosync pacemaker e un sacco di roba inutile, alla fine dell’installazione apt-get remove – -purge corosync pacemaker && apt-get – -purge -y autoremove in modo da fare pulizia di tutto.
vim /etc/ha.d/authkeys
auth 1
1 una_password
chiudere e cambiare a 600 i permessi del file scp del file su altro nodo nello stesso path.
vim /etc/ha.d/ha.cf
debugfile /var/log/ha-debug
logfile /var/log/ha-log
logfacility local0
keepalive 2
deadtime 30
warntime 10
initdead 120
udpport 694
ucast bond0 172.18.19.245
ucast xenbr0 192.168.2.245
### Nota Molto Bene! gli IP sono quelli dell’altro nodo!
auto_failback on
node marino pedretti
### host name dei due nodi
Questo è l’unico file differente sui due nodi
vim /etc/ha.d/haresorces
#marino partenza::
marino xendom::/etc/xen/xen1.cfg \
MailTo::service@intranet.lan::Transizione_xen1_xen2
#pedretti partenza::
pedretti xendom::/etc/xen/xen2.cfg \
MailTo::service@intranet.lan::Transizione_xen2_xen1
N.B. lo script xendom non è farina del mio sacco, ma bensì il frutto del lavoro e di anni di esperienza dell’azienda che ci supporta nella realizzazione e gestione dei cluster, quindi non viene pubblicato.
In sostanza questo script verifica la condizione del DRBD, la condizione dell’LVM, e con una serie di comandi accende e/o migra da un nodo all’altro le VM, un qualcosa di vagamente simile per rendere il concetto lo si può vedere qui xendom.
Sui volumi DRBD verranno creati i volumi logici con LVM2 per hostare le VM.
Come accennavo nell’introduzione su come funziona un cluster HA per molte ragioni si può verificare la necessita’ di mandare offline uno dei due nodi, anche in questo caso l’onere spetta a heartbeat, in /usr/local/sbin creare i files Master e Slave che contengono rispettivamente:
Master
#!/bin/sh
nome=`basename $0`
echo “conferma passaggio a $nome ?”
read pippo
[ “$nome” = “Slave” ] && /usr/share/heartbeat/hb_standby
[ “$nome” = “Master” ] && /usr/share/heartbeat/hb_takeover
Slave
#!/bin/sh
nome=`basename $0`
echo “conferma passaggio a $nome ?”
read pippo
[ “$nome” = “Slave” ] && /usr/share/heartbeat/hb_standby
[ “$nome” = “Master” ] && /usr/share/heartbeat/hb_takeover
In altre parole sono identici, solo che a seconda di come vengono eseguiti hanno effetto diverso, vale a dire eseguire sul nodo marino Slave vuol dire migrare le VM su pedretti mentre se eseguo Master le VM di pedretti si spostano su marino, l’unico onere umano è quello di premere un tasto qualsiasi quando viene posto il quesito conferma passaggio a $nome ? in modo da confermare.
back home next
Categorised as: Linux | Networking | Work
Comments are disabled on this post