GlusterFSとucarpを使って、冗長構成なNFSを作ってみる。
まぁ、難しいことは何もなく、普通に動いた。
aとbがGlusterFS/NFSサーバ、cがクライアント。
いずれもFreeBSD 10.1-RELEASE-amd64。
GlusterFSの設定。
a# zfs create -o mountpoint=/glusterfs-data zroot/glusterfs-data b# zfs create -o mountpoint=/glusterfs-data zroot/glusterfs-data a# gluster volume create gv0 replica 2 10.0.0.1:/glusterfs-data/brick 10.0.0.2:/glusterfs-data/brick a# gluster volume start gv0
ucarpの設定は/etc/rc.confにて。
ucarp_enable="YES" ucarp_addr="10.0.0.127" ucarp_if="em0" ucarp_src="10.0.0.1" ucarp_pass="password" ucarp_vhid="127" ucarp_upscript="/usr/local/sbin/ucarp-up" ucarp_downscript="/usr/local/sbin/ucarp-down" ucarp_xparam="em0 ${ucarp_addr}"
b側はucarp_srcを10.0.0.2に。
あとは第3のホストからNFSをマウントするだけ。
c# mkdir /glusterfs c# mount -t nfs 10.0.0.127:/gv0 /glusterfs
aやbをrebootしたりしてみても、キチンと接続は維持されている。
……でも実感がないので少々いじめてみる。
いじめ用スクリプトはこちら。
- aがMASTER時に、aをshutdown。
もちろん問題なし。ただし、shutdownしてから少しの間は固まる。 - aがMASTER時に、a, bの順にshutdown、a, bの順に起動。
aを起動しても回復しない(cは固まりっぱなし)が、bが起動してから回復。
起動時にpeerをチェックしてるのかな? - aがMASTER時に、a, bの順にshutdown、b, aの順に起動。
これも動作としては変わらず。すでに動いている場合はともかく、単独では起動できないらしい。
split brainになって壊れないかなーと思ったけどならない。
quorumが有効なのかと思って調べたけどそんなこともない。
# gluster volume set help (...snip...) Option: cluster.quorum-type Default Value: none
そもそもquorumが有効だったら、片方が落ちた時点で書き込めなくなるハズだしね。