さらにOCFS2化の実験。
今回は全く綺麗な環境を作って、NBDを使って試してみた。
結論的にはやっぱり失敗。
空いているサーバが2台あるので、片方でNBD serverを動かし、それぞれからNBD clientでつながるようにし、OCFS2を両方で動かしてみた。
DebianはNBD serverが動いている方(以下ginza)がsid、動いてない方(以下shinbashi)がetch。ginzaはAthlon 64 E6000+、shinbashiはCore 2 DUO E8400だ。メモリは両方とも6GBなのだが、shinbashiはなぜか3GBしか認識してない。kernelはどちらも2.6.24.2。
という環境で、まずginza用の/etc/nbd-server/configを作る
[generic] [export] exportname = /dev/sda4 port = 12345 authfile = /etc/nbd-server/allow
authfileは動作がおかしかったので、結局使わず。作らないと「どこからでもOK」になってしまうが、実験だから問題ない。
/etc/nbd-clientは共通で、
AUTO_GEN="n" NBD_DEVICE[0]=/dev/nbd0 NBD_TYPE[0]=r NBD_HOST[0]=192.168.2.27 NBD_PORT[0]=12345
この状態で双方から接続を試すと、それぞれのサーバ上の/dev/nbd0にginzaの/dev/sda4が見える。
OCFS2には/etc/ocfs2/cluster.confが必要なので作ってやるが、これはどのサーバにも共通の内容。
node: ip_port = 7777 ip_address = 192.168.2.14 number = 0 name = kabigon cluster = ocfs2 (中略) node: ip_port = 7777 ip_address = 192.168.2.27 number = 6 name = ginza cluster = ocfs2 node: ip_port = 7777 ip_address = 192.168.2.26 number = 7 name = shinbashi cluster = ocfs2 node: ip_port = 7777 ip_address = 192.168.2.11 number = 8 name = shibuya cluster = ocfs2 cluster: node_count = 9 name = ocfs2
てな感じ。
後は前にやったような手順で設定。ginzaで初期化して双方でmount出来るのを確認した。
程々のディレクトリをcp -aしても問題がないので(iSCSIだとこの時点でコケる)、耐久試験を行う。実験に使うのはこのサーバの/homeディレクトリ。このサーバには2000くらいのユーザがいて、500GB弱使っている。ちょうど/dev/sda4と同じくらいの大きさだ。
nfs mountしてcp -aを開始してそのまま寝て起きたら、双方rebootしていた orz
/ver/log/kern.logによると、開始3時間半くらい経過したところでrebootがかかったようだ。異常らしいものが記録されていないし、ginzaはすんなり再起動しているので(shinbashiはgrubでひっかかっていた)、panicにもならないで再起動したのだろう。だとするとiSCSIの時と同じ現象だ。
実験開始当時は双方からディレクトリの内容は見えているし、特に異常らしいものはなかったので、なんだかよくわからないところで何か起きている。
つーことで現在のところの結論は、「NBD + OCFS2はそこそこは動くけど耐久試験には耐えない」ということだな。OCFS2については、世間で「やってみました」的な情報はいくつかあるのだが、もしかして耐久試験をやってないんじゃないか? 「動く」と言われるものをあれこれ試してこんなに動かないってのも珍しいような気がするが。それとも例によって私が根本的な間違いをしてるのだろうか? node数を減らして試してみるかな。
PS.
複数からmountしないでshinbashiからだけmountしてcpしたら、無事全部コピー出来た。どうも協調動作する何かに問題があるようだ。
PS.2
/etc/ocfs2/cluster.confの記述を、実際に使っているnodeだけにしてみたのだが、やっぱり途中でコケる。OCFS2はいわゆるexperimentalな実装ではないはずなんだが、こんなに簡単にコケるというのが理解出来ない…