mhddfsとGlusterFSの組み合わせ方

GlusterFSとmhddfsの組み合わせ方を逆にしてみようと思いました。
神が舞い降りてきた感じがします。

■これまでの発想
ハードディスクをmhddfsで束ねて作った領域を、他サーバとGlusterFSでミラーリングする。
クライアントでGlusterFSをマウントする。

■これからの発想
ハードディスクをGlusterFSで他サーバのハードディスクとミラーリングする。
クライアントでGlusterFSをマウントし、それをmhddfsで束ねる。

■絵にしてみた

■違い
これまでは、サーバ内で複数のHDDをmhddfsで束ねたうえで、そこにフォルダを掘って、GlusterFSでサーバ間ミラーしようと思っておりました。
これからは、ディスク単体についてGlusterFSでサーバ間ミラーしたうえで、クライアント側でmhddfsを使って領域を結合しようと思いました。

"これまでの構成"だとディスクの容量がバラバラでも余すところなく使えますが、反面、どのディスクに何のファイルが入っているか明確になりません。たとえ容量が揃っていても、ディスクが欠落するとGusterFSが他のディスクに復元を始めてしまいます。復元を完了させるにはディスクの全域にわたってfind&statしなければならず、容量に比例して所要時間が膨大なものになります。両サーバのHDDが1台づつ故障した時点でデータロストが発生します。また、GlusterFSがmhddfsを経由してディスクにアクセスするなんてことはGlusterFS開発陣は想定していないでしょうから、どのような不具合が出るか、わかりません。

"これからの構成"だと、対になるディスクは容量が揃っていないとGlusterFSの動作に不具合が生じますが、ディスクのペアごとに、記録内容が完全に一致します。あるディスクが停止しても、GlusterFSはHAを維持してくれますが、勝手に復元することはありません。復元を完了させるには当該ペアだけfind&statすればよく、範囲を限定できます。ペアのディスクが同時に故障した時点でデータロストが発生しますが、これまでの構成よりは確率的に低いといえるでしょう。GlusterFSへの書き込みはmhddfsを使用しますが、GlusterFS自体は検証済みのファイルシステムを直接使用しますから、問題が発生する可能性は少ないでしょう。

"これからの構成"の欠点としては、全クライアントにmhddfsを導入しなければならないので、OS環境を選びます。現在主力のCentOS5.7では正しく使用できません。まぁこれは、SPOFを受認しなければなりませんが、GlusterFS+mhddfsをNFSで再エクスポートする中継サーバを用意すれば回避できそうに思います。あとディスク構成を変更した場合にクライアント間で設定変更のタイムラグが発生しますので、運用手順をよく検討すればいいかなと。

■雑感
そもそも言ってしまえば、GlusterFSのバランシングアルゴリズムが微妙なんですよねぇ。性能差を考慮しない均等なハッシュ割り当てって、ちょっとねぇ。それによる諸問題をmhddfsで回避して、実用的にしてみようという試みです。

こんな感じで、あと一晩考えてみたいと思います。