Ubuntu 12.04 LTS に GlusterFS をインストールし、定義し、マウントした。もう少し実際の運用に近い形で使ってみる。ここでは障害テストを行う。
スポンサードリンク
障害テスト
192.168.1.12 を切断
それにしても流石に9MB/s では遅いので、思いついたように障害テストを決行する。対象は192.168.1.12 。なぜなら192.168.1.11 をマウント指定しているから。
この間も書き込みは継続している（あと、192.168.1.12 が死んだとみなされたからか192.168.19.129 から行なっている書き込み速度が15MB/s に向上した）
すこし時間を置いてから電源を切断した192.168.1.12 を再稼働させた。ファイルが不足しているのが確認できる。
何の操作もしていないが、ファイルの不足が補われたようだ。しかし、ファイルサイズは0バイト。
さらに時間を置くとファイルが正しいサイズになった。これは素晴らしい。
192.168.1.11 を切断
192.168.19.129 改め192.168.1.13 から書き込みを行なっている最中に、今度は同様に192.168.1.11 を切断する。これは障害が発生するだろう予測は予め立つ。なぜなら、マウント指定しているのが192.168.1.11 だから。
192.168.1.13 がエラーを出さなかったのは意外だった。しかし、書き込みも停止した。もう少し正確に書くと、load average が増加したが、コネクションエラーにはならなかった。詳しく検査していないが、内部に蓄積したのだろうか。
しばらくして192.168.1.11 を復帰させると、継続中だった書き込みが復帰した。ファイルに欠落はなかったように記憶している。
単一障害点
こ こで思うのはマウント指定したマシンがダウンすると単一障害点になりうる可能性があるだろうこと。しかし、IP アドレスやホスト名を代理応答するように構成することも（他の技術と組み合わせれば）可能だろうから、マウントのしかたに注意すれば無停止も可能ではない だろうか。
ダミーファイルの主に数とサイズのみに着目しているからバイナリレベルでの整合性は不明だが、短時間にあちこち落としても確認し た範囲では正常に動作していることからも、実用的に廉価に気軽に導入できそうだ。何よりGlusterFS のピア内にファイルの実態が確認できるのが嬉しい。
ただ、いくつかの文献で確認した範囲ではマウントしてから操作せよと書かれており、さらにマウントしないとハングアップすると（たしか公式に）記載されていたと思うのだが、それらに対して直接作業しても正しく動作したのは嬉しい誤算か。読み間違いかもしれないけれど。
→ 続く・・・とすればスケールアウトと異なる容量の場合どうなるかを試す。もしかしたら単一障害点にならないようにする方法も？
コメント