GlusterFSとZFSを組み合わせるには

GlusterFSとZFSを組み合わせて使うのに、一悶着あったので、書き残しておきます。
何かを見落としていなければ、かなりの冒険が必要のようです。

■結論（持ち越し）
・ZFSとGlusterFSは、そのままでは組み合わせ不可能（ZFSがxattrに対応してないから）
・ZVOLを作ってUFSフォーマットしてマウントすれば使えるが… えー、それマジっすか？

・ソリューション選択で何とかならないかなぁ。
FreeBSD＋ZFS(ZVOL)＋UFS＋GlusterFS
CentOS+ZFS-FUSE(ZVOL)+XFS＋GlusterFS
CentOS+mhddfs＋XFS＋GlusterFS（そもそもZFS無くても良くね？ と思ってきた）

■GlusterFSとZFSの併用について
GlusterFSはディレクトリを束ねるソリューションであって、ストレージの挙動には関与しません。データの中身の整合性であるとか、ディスクのリプレースとか容量拡張とか、考慮されていません。それはそれで正しいんでしょうけど、これで複数のディスクを束ねて順次拡張しながら長期運用しようとすると困難に直面することがあるようです。（ディスクを止められないとか、最小容量のディスクに引っ張られるとか、挙動が怪しくなるとか）

その点、ZFSが併用できれば便利そうです。データをチェックサムで点検したり、書き込みホール無しのダブルパリティで物理障害に備えたり、ホットスペアを用意したり、容量の異なるディスクを継ぎ接ぎしたり、スナップショットとれたり、持続的な発展的運用にはもってこいじゃないですか。（メモリ食うし安定させるの大変だけど）

■プラットフォームの問題
GlusterFSは一応RedHat系Linuxが推奨環境になります。ZFSはFreeBSDなら安心ですが、Linuxですと今のところZFS-FUSEになるかと思います。あんまり安心して使える感じじゃないんですよね。

ここはソリューション選択で解決できそうな気がします。
・GlusterFSでミラーされてるしバックアップもあるし、データ保護は半ばどうでもいいのでZFS-FUSEを使う。
・ZFSの安定性を重視するなら（いろいろ間違ってる気がするが）Debian GNU/kFreeBSDにGlusterFSを入れる。

うーん、一応両方評価してみようかなと思います。。

■ZFSの仕様の問題
しかし、しかしです。ZFSには重大な欠点があります。GlusterFSの必須用件であるattrがサポートされていません； GlusterFSとZFSを組み合わせることは、そもそも不可能なんです；

ZFS上でattrコマンドを実行するとエラーです。
zfs set xattr=onも通りません。

これはSolarisと他OSにおける「attr」の仕組みの違いによるものです。Sorarisにはext2/3やXFS、UFSでいうところの「attr」と一致するものが存在しません（しないようです）。なのでZFSではそんなものは仕様上考慮されておらず、搭載されていないと。こりゃ時間が解決してくれる手の問題ではなさそうで、どうにもなりません。

このattr問題に関し、FreeBSD.orgのドキュメントを参照しますと驚愕の対処法が書かれています。

# zfs create -V 10g tank/ufs
# newfs /dev/zvol/tank/ufs
# mount /dev/zvol/tank/ufs /ufs

引用元：http://wiki.freebsd.org/ZFSQuickStartGuide

なんと斬新な・・・ 驚愕を通り越して感動すら憶えます。しかし、最近のFreeBSDにはSoftUpdateが付いてるとはいえ、これでsnapshotとか取って大丈夫なんだろうか。。疑問疑問。。スマートとも言えない。。ですよね。。容量拡張はZFSでサイズ変更してからgrowfsか？

しかしZFSを使う限り宿命なので、これで検証することにします。フォーマットは、FreeBSDならUFS、LinuxならXFSでしょうか。

■ZFSやめようかな
単にHDDを束ねるだけならmhddfs（FUSE）という手がある。ディレクトリをコンカチしてくれる素敵ソリューション。

・ファイルシステムの上のレイヤーで動くJBODのようなもの。複数のディレクトリを束ね、1つのものとして見せてくれる。mhddfs自体は中継レイヤーであり、普通のファイルシステムではない。

・mhddfsで束ねたディレクトリに書き込むと、束ねる際に指定した順番で前方のディレクトリから順次、容量フルになるまで書き込まれていく（デフォルト設定ではフルになる前に次のディレクトリに移行するけど）。

・書き込みはブロック単位ではなくファイル単位で行われる。ファイルがディレクトリをまたがって書き込まれることは無い。追記途中でディレクトリが一杯になったら次のディレクトリに自動的にマイグレーションされる（けどサイズが大きいと時間かかりまくるんじゃないかなと想像。。これは善し悪しかも知れない。）

・束ねたディレクトリは1つづつ独立した普通のディレクトリなので単独でマウントして中身を拾えるし、マウントパラメータ以外に管理情報も持っていないので運用中に適当に抜いたり追加したりしても大丈夫。

・運用中に構成ディレクトリを外すとそこにあったファイルは見えなくなるが、元通りマウントすれば復活する。冗長性は無いが、ディスクが故障した場合、そこに記録されているファイルは失われるが他のファイルは無事なので全損にはならない。

・束ねるディレクトリ間でファイル名やディレクトリ名が衝突した場合、一番前方のディレクトリにあるもののみが読み書きの対象になる。ということは、ファイルを更新してもディレクトリのタイムスタンプが更新されないケースが生じうる。プログラム的にはここ要注意かも知れない。

冗長性はGlusterFSによるreplicaでカバーできるものとすれば、これこそGlusterFSと相性がいいと言えるかも知れない。

○ディスク数を減らしたい場合
・ディスクを外したいサーバのGlusterFSプロセスを落とす（自動フェイルオーバーで稼働継続）
・mhddfsをumountして交換したいディスクのマウントポイントを外してmountし直す（欠損が発生）
・GlusterFSプロセスを上げる
・欠損部分がミラーで自動修復される（笑

○ディスク数を増やしたい場合
・ディスクを追加したいサーバのGlusterFSプロセスを落とす（自動フェイルオーバーで稼働継続）
・mhddfsをumountして取り付けたディスクのマウントポイントを最後に追加してmountし直す
・GlusterFSプロセスを上げる
・既存ディスクが埋まり次第、新しいディスクが使われていく

というわけで、チェックサムによるデータ保護はないものの、brickの構成を変更せずに素早くディスクを切り替えられてhappyになれる。

しかし。

・mhddfsはFUSEを使う。FUSEが2重になるとパフォーマンスや安定性が微妙そうな気が何となくする。
・mhddfsをCentOSに導入するのは大変そうだ。公式パッケージは無い。

うーん、決定打がない。

いっそmhddfsを改造するとかして、同期レプリケーションに特化した新しいファイルシステムを作っちゃうか？

・write系は、両方に同期ミラーで書く。
・read系は、両方から読む。データは比較してもしなくてもいいや。
・read系で、片方にファイルが無かった場合は、もう片方からコピってくる。
・タイムアウトなりエラー検知なりした場合、そのディレクトリの使用を中止する。

これでNFSを束ねれば十分じゃないか？ ていうか、もしかして現存するんじゃないか？

なんか徒然と書いてしまいましたが、今日はこの辺で。

※2012/2/1修正
徒然し過ぎていたのでちょっと整理整頓しました。