GlusterFS 容量フル時の挙動を確かめてみた

容量フルにならない運用を心がけるのは当然なんでしょうが、一応、そうなっちゃった時の挙動を確かめておきました。

■使用環境
CentOS5.7
GlusterFS3.2.5

■テスト方法
ダミーファイルをxfsでフォーマットし、適当にマウントし、GlusterFSで束ねます。
ダミーファイルの大きさを不均等にしておいて挙動を見ます。
今回はローカルでのテストなので、ネットワーク越しだと違うかも知れません。

■用意(zero1だけ200MB、他は1GB)
dd if=/dev/zero of=/glvols01/disk01/zero1 seek=200 bs=1M count=1
dd if=/dev/zero of=/glvols01/disk02/zero2 seek=1000 bs=1M count=1
dd if=/dev/zero of=/glvols01/disk03/zero3 seek=1000 bs=1M count=1
dd if=/dev/zero of=/glvols01/disk04/zero4 seek=1000 bs=1M count=1
mkfs.xfs /glvols01/disk01/zero1
mkfs.xfs /glvols01/disk01/zero2
mkfs.xfs /glvols01/disk01/zero3
mkfs.xfs /glvols01/disk01/zero4
mkdir /glvols01/zero1
mkdir /glvols01/zero2
mkdir /glvols01/zero3
mkdir /glvols01/zero4
mount -t xfs -o loop /glvols01/disk01/zero1 /glvols/zero1
mount -t xfs -o loop /glvols01/disk01/zero2 /glvols/zero2
mount -t xfs -o loop /glvols01/disk01/zero3 /glvols/zero3
mount -t xfs -o loop /glvols01/disk01/zero4 /glvols/zero4
gluster volume create zero replica 2 192.168.0.252:/glvols/zero1 192.168.0.252:/glvols/zero2 192.168.0.252:/glvols/zero3 192.168.0.252:/glvols/zero4

■テスト結果：レプリカディレクトリの空き容量が均等な場合
空き容量不足で正常に終了するようです。

[root@kfs02 glvols01]# dd if=/dev/zero of=/zero/zero bs=1M
dd: writing `/zero/zero': デバイスに空き領域がありません
dd: 出力ファイル `/zero/zero' をクローズ: デバイスに空き領域がありません

[root@kfs02 glvols01]# df -kh
Filesystem サイズ 使用 残り 使用% マウント位置
/glvols01/disk01/zero1
197M 4.3M 193M 3% /glvols01/zero1
/glvols01/disk02/zero2
997M 4.3M 993M 1% /glvols01/zero2
/glvols01/disk03/zero3
997M 997M 20K 100% /glvols01/zero3
/glvols01/disk04/zero4
997M 997M 20K 100% /glvols01/zero4
glusterfs#192.168.0.252:zero
1.2G 1001M 192M 84% /zero

■テスト結果：レプリカディレクトリの空き容量が不均等の場合
片方が埋まっても、両方が埋まるまで超低速で書き込みが続いてしまうようです。
正確な速度は調べてませんが、0.5MB/sも出てない感じ。
未確認ですが、この状態で書き込みが集中すると鯖落ちということになるんでしょうか。

[root@kfs02 glvols01]# dd if=/dev/zero of=/zero/azero bs=1M

[root@kfs02 glvols01]# df -kh
Filesystem サイズ 使用 残り 使用% マウント位置
/glvols01/disk01/zero1
197M 197M 20K 100% /glvols01/zero1　←注目
/glvols01/disk02/zero2
997M 237M 761M 24% /glvols01/zero2　←注目（zero1を超えてる）
/glvols01/disk03/zero3
997M 997M 20K 100% /glvols01/zero3
/glvols01/disk04/zero4
997M 997M 20K 100% /glvols01/zero4
glusterfs#192.168.0.252:zero
1.2G 1.2G 0 100% /zero

■考察
ファイル名でハッシュ値をとって分散しているので、brick間での空き容量に関係なく書き込みが試行されます。
書き込み先のbrickが一杯になった時点で容量フルのエラー応答。
書き込み先のbrickのうちミラーの片割れだけが容量フルになっても、エラーを返さず超低速で動き続けます。容量フルのbrickのファイルのタイムスタンプも更新され続けているので、書き込みを試行し続けているのかな。動作が遅くなるのはxfsのせいだろうか？ CPUはほとんどidolで、何をやってるのかよくわかりません。
レプリカの正誤判定は、タイムスタンプの新しいほうを正とみなす、なんてロジックでしたっけ？　だとすると破滅的な挙動に繋がるかも知れませんが確かめておらず。

■まとめ
brickごとに容量監視が必要です。
replicaで対になるbrickの容量は揃えておいたほうが良さそうです。
対にならないbrickに関しては容量が揃っていなくても深刻な問題は無さそうですが、分散アルゴリズム上、容量差は考慮されないので、容量が大きい方が無駄になる可能性が高いようです。
適当にディレクトリを切ってbrickごとの容量差を近づければ無駄にはなりませんが、パフォーマンスが落ちるであろう点と、後でbrickを1つに合併させるのは困難であろう点が気になります。
長期運用中にディスクを追加したくなった場合に、その時点でバイト単価の最も安いディスクをチョイスしても無駄になっちゃいますね。
しかし全リプレースするにしてもreplace-brickにかかる時間が馬鹿にならないだろうし、ディスク追加のパフォーマンスは良くないように思います。

このへんはZFSを組み合わせてローカルディスクを単一ディレクトリにまとめてしまえば回避できますが、メモリ＆CPUリソースが食われるんでGlusterFSの長所が一つ潰れてしまいます。
しかもZFS＠FreeBSDではattrが使えないんで、そもそもだめですね。
ついでにGlusterFS公式ではFreeBSDやZFSでの動作は検証の対象外のようですね。そりゃGlusterFS自体がRedHat傘下だしなぁ。大量データを任せるのはハイリスクなんじゃないでしょうか。

なんだか、スモールスタートでの長期運用には向いていないんじゃないか、って感じがします。
最初から構成を固定するとか、一時的かつ再現可能なデータに限って使用するとか、将来的に代替ハードを用意＆大容量データを全コピー（低速）する羽目に陥るリスクを受容するとか、何らかの妥協がいりそうです。。