mhddfs＋GlusterFSでレプリケーションを復元してみる

相変わらずローカル環境でのテストを続けております。
今回は、GlusterFSによるレプリケーションの自動修復を試してみました。

■準備
書き込み稼動中のディスク1台分のマウントを外してみた（umount -f）
→mhddfsおよびGlusterFSでinput/output errorが出て書き込めなくなった。今回はサーバ一台だけでテストしてますが、これ、複数サーバの1つが落ちた状態でも同じ動作なら意味ないですね。全然HAじゃない。要検証。

外したディスクをフォーマットした（mkfs.ext4 /dev/sda）
→あえてXFSじゃないのは、ext4も試してみたかったから。安定するならどっちでもいい。

ext4をmountした（mount）
→mhddfsもGlusterFSも、自動復帰しなかった。

mhddfsをrestartした（umount＆mount）
→GlusterFSは自動復帰しなかった。

GlusterFSをrestartしてクライアントでマウントし直した（service gusterd restart, umount & mount）
→アクセスおk

■自動修復させてみた
ファイルにアクセスする度に自動復元されますが、案の定と言いますか、想像並みに重い感じでした。

ディレクトリの内容をlsすると、そのディレクトリ内のファイルが復元され、lsが帰ってきます。この段階ではファイルが欠損しているほうのディスクに空ファイルが作られるのみで、（おそらくそこにはattrで色々書かれていて）データ本体はまだミラーされていない状態に留まります。データ本体は同期しないので高速なんでしょうが、3000ファイルで30秒くらいかかりました。その間lsはフリーズ状態で待機です。対象ディレクトリに子ディレクトリエントリが含まれていた場合、おそらくその子ディレクトリ内のファイルの数を確定するためでしょうが、やたらめったら時間がかかります。複数のサブディレクトリ内に合計ウン十万個のファイルがあるディレクトリをlsした時、時間は計り忘れましたが2時間近くはCtrl-Cも効かなかったかなぁ。

データ本体はデータを読み出した時に復元されます。読みながら書いていくので、所要時間もそれなりです。ただlsの場合と違ってデータ本体に一括アクセスすることは普通ないと思いますので、これはさほど問題ないかなと思いました。でも3000ファイル4GBをtime cat * > /dev/nullで6分強。全体を完全に同期完了させるには全ファイルを読み出さないとならないので、データ量が増えると所要時間が半端無いですね。まぁ未使用領域はスキャンしないので、mdadmよりはマシと思うことにしましょうか。。brickに直接アクセスして同期すべきファイルを特定するスクリプトを作って回したら、読み出す範囲を限定できるので、部分的な損傷の時に高速化できるかなぁと思った。ちなみにcatで読み出すより公式コマンド「find <gluster-mount> -print0 | xargs --null stat >/dev/null」のほうが倍くらい速かった。20〜30MB/secくらい。バックアップマシンからrsyncでリストアするよりもちょびっと速いかも知れない。

■まとめ
当然ながらGlusterFSでのミラー復元はデータ量に応じて膨大な時間を要するので、これをアテにしたHDDの取り付け取り外しは現実的じゃないなと思いました。とはいえ普通のRAIDだって復元には膨大な時間がかかるわけですので、純粋に筐体間RAIDと考えて非常事態に備えるHA目的での運用は、あり得るのかなと思いました。

あとは複数サーバをまたがるボリュームの、異常系の動作検証が必要ですね。書き込みエラーでも動作継続できますように。