I recently used hanfs using DRBD as a backend, in my situation I run active / standby, but I successfully tested it using OCFS2 in main / main mode. There, unfortunately, there is not much documentation on how to best achieve this; most of those that exist are, at best, of little use. If you are on the drbd route, I highly recommend you join the drbd mailing list and read all the documentation. Here's my ha / drbd and script setup I wrote to handle ha failures:
DRBD8 required - this is provided by drbd8-utils and drbd8-source. Once they are installed (I believe they are provided by backports), you can use the helper module to install it - mai drbd8. Either depmod -a, or reboot at this point, if you are depmod -a, you will need modprobe drbd.
You will need a backend section to use drbd, do not create this LVM section, otherwise you will encounter all the problems. Do not put LVM on the drbd device, or you will run into all the problems.
Hanfs1:
/etc/drbd.conf global { usage-count no; } common { protocol C; disk { on-io-error detach; } } resource export { syncer { rate 125M; } on hanfs2 { address 172.20.1.218:7789; device /dev/drbd1; disk /dev/sda3; meta-disk internal; } on hanfs1 { address 172.20.1.219:7789; device /dev/drbd1; disk /dev/sda3; meta-disk internal; } }
Hanfs2 / etc / drbd.conf:
global { usage-count no; } common { protocol C; disk { on-io-error detach; } } resource export { syncer { rate 125M; } on hanfs2 { address 172.20.1.218:7789; device /dev/drbd1; disk /dev/sda3; meta-disk internal; } on hanfs1 { address 172.20.1.219:7789; device /dev/drbd1; disk /dev/sda3; meta-disk internal; } }
After configuration, we need to call drbd again.
drbdadm create-md export
drbdadm attach export
drbdadm connect export
Now we have to perform the initial data synchronization - obviously, if this is a new drbd cluster, it does not matter which one to choose node.
Once you're done, you'll need the mkfs.yourchoiceoffilesystem on your drbd device — the device in our configuration file above / dev / drbd 1. http://www.drbd.org/users-guide/p-work.html — a useful document for reading while working with drbd.
heartbeats
Install heartbeat2. (Pretty simple, apt-get install heartbeat2).
/etc/ha.d/ha.cf on each machine should consist of:
hanfs1:
logfacility local0 keepalive 2 warntime 10 deadtime 30 initdead 120
ucast eth1 172.20.1.218
auto_failback no
node hanfs1 node hanfs2
hanfs2:
logfacility local0 keepalive 2 warntime 10 deadtime 30 initdead 120
ucast eth1 172.20.1.219
auto_failback no
node hanfs1 node hanfs2
/etc/ha.d/haresources should be the same for both mailboxes:
hanfs1 ipaddr :: 172.20.1.230/24/eth1
hanfs1 HeartBeatWrapper
I wrote a wrapper script to deal with idiosyncrasies caused by nfs and drbd in a script to switch to another resource. This script must exist in / etc / ha.d / resources.d / on each machine.
!/bin/bash
heartbeat fails hard.
so this is a wrapper
to get around that stupidity
I'm just wrapping the heartbeat scripts, except for in the case of umount
as they work, mostly
if [[ -e /tmp/heartbeatwrapper ]]; then runningpid=$(cat /tmp/heartbeatwrapper) if [[ -z $(ps --no-heading -p $runningpid) ]]; then echo "PID found, but process seems dead. Continuing." else
echo "PID found, process is alive, exiting."
exit 7
fi
fi
echo $$ > /tmp/heartbeatwrapper
if [[ x$1 == "xstop" ]]; then
/etc/init.d/nfs-kernel-server stop #>/dev/null 2>&1
NFS init script isn't LSB compatible, exit codes are 0 no matter what happens.
Thanks guys, you really make my day with this bullshit.
Because of the above, we just have to hope that nfs actually catches the signal
to exit, and manages to shut down its connections.
If it doesn't, we'll kill it later, then term any other nfs stuff afterwards.
I found this to be an interesting insight into just how badly NFS is written.
sleep 1
elif [[x $1 == "xstart" ]];
#start up drbd first /etc/ha.d/resource.d/drbddisk export start >/dev/null 2>&1 if [[ $? -ne 0 ]]; then echo "Something seems to have broken. Let check possibilities..." testvar=$(egrep -o "st:[A-Za-z/]*" /proc/drbd | cut -d: -f2) if [[ $testvar == "Primary/Unknown" ]] || [[ $testvar == "Primary/Secondary" ]] then echo "All is fine, we are already the Primary for some reason" elif [[ $testvar == "Secondary/Unknown" ]] || [[ $testvar == "Secondary/Secondary" ]] then echo "Trying to assume Primary again" /etc/ha.d/resource.d/drbddisk export start >/dev/null 2>&1 if [[ $? -ne 0 ]]; then echo "I give up, something seriously broken here, and I can't help you to fix it." rm -f /tmp/heartbeatwrapper exit 127 fi fi fi sleep 1
elif [[ "x $1" == "xstatus" ]];
#Lets check to make sure nothing is broken. #DRBD first /etc/ha.d/resource.d/drbddisk export status >/dev/null 2>&1 if [[ $? -ne 0 ]]; then echo "stopped" rm -f /tmp/heartbeatwrapper exit 3 fi #mounted? grep -q drbd /etc/mtab >/dev/null 2>&1 if [[ $? -ne 0 ]]; then echo "stopped" rm -f /tmp/heartbeatwrapper exit 3 fi #nfs running? /etc/init.d/nfs-kernel-server status >/dev/null 2>&1 if [[ $? -ne 0 ]]; then echo "stopped" rm -f /tmp/heartbeatwrapper exit 3 fi echo "running" rm -f /tmp/heartbeatwrapper exit 0
code>
When doing all of the above, you just want to configure / etc / exports
/ export 172.20.1.0/255.255.255.0(rw,sync,fsid=1,no_root_squash)
Then this is just a case of running a beat on both machines and issuing hb_takeover on one of them. You can verify that it works by making sure that the one you released is primary - check / proc / drbd, that the device is installed correctly and that you can access nfs.
-
Good luck. It was a very painful experience for me.