GlusterFSはmhddfsと相性が良さそうだ

GlusterFSとZFSを組み合わせるのを、やめることにしました。mhddfsにします。

ZFSとGlusterFSの相性は、前回エントリの通り、最悪です。チェックサムによるデータ保護やsnapshotを諦めてしまえば、mhddfsがとても素敵に見えます。（どうしてもチェックサムやsnapshotが欲しければ、GlusterFS Geo Replicationかrsyncか何かでZFSに非同期バックアップを取っておけば、それで十分かなと思った。）

1ストレージサーバに複数ディスクを取り付けてGlusterFSで束ねるべく、1サーバに複数のbrick（1ディスク＝1brick）を割り当てると、ものすごく使いにくい。
ディスクが壊れてもbrickを個別停止できません。GlusterFSのデーモンを落としてサーバを丸ごと停止する必要があります。
デーモンを落とさずbrickをマウント解除すると空ディレクトリに書き込みを始めてしまうし、ディレクトリを消すとまともに動かない。
ディスクが壊れる前に事前にデーモンを落とせれば良いが、そうでない場合、致命傷を受ける可能性があります。
束ねる際に対になるディスクは容量が揃ってないと予期せぬ動作を催します。空き容量に関係なくファイル名ハッシュで満遍なく分散保存されてしまうので、対になってないディスクでも容量が大きい分が丸ごと無駄です。
brick内のファイルを直接触るのは危険です。容量が増えれば増えるほど再構成の負担が増大します。

そこで、mhddfsでディスクをコンカチして、そこにディレクトリを掘って、GlusterFSでサーバー間でミラーリングすると、全て解決します。
ディスクが壊れたら、そのディスクのマウントポイントを削除すれば、mhddfsはそのディスクが無かったものとして動作続行し、GlusterFSがミラー復旧に努めてくれます。（マウント解除されると空ディレクトリに書き込まれちゃうのは同じなんですが、マウントポイントが消失しても問題ないのが良い点）
ディスクとbrickが結びついていないので、brickをマウント解除したりディレクトリを消去することはありません。（外したディスク以外にディレクトリエントリが記録されていなかった場合を除くものの）
よって事前にデーモンを落とせなくても、GlusterFSの困った動作の影響は受けません。（大体は。まぁメリットはエラー対処よりディスク容量問題の方が大きいんで堪忍してください）
個々のディスクの容量を揃える必要はありません。サーバ間で揃っていれば良いし、あるいはまったく揃えずとも満杯になりそうになったらディスクを手軽に追加投入して解消できます。手持ちのディスクを空きポートの数だけ全部突っ込めます。
ディスクは前方から順番に使用されていきます。負荷分散はできませんが、各ディスクのファイルは直接触っても問題ないので、ファイルを手動でコピーすればいかようにも再構成できます。

まぁパフォーマンスは測定しないといけませんけど、いいことづくめではないでしょうか。ストレージプールに追加したディスクは絶対に取り外せないZFSよりもHA運用に向いていると言えなくもないくらいじゃないですか・・・？

この路線で考えてみます。