XENにはFaultToleranceという耐障害性技術があります。
現段階ではただの構想ですが、Hadoopなど冗長性が重要なのに機能的に乏しいシステムに適用できないかなーと思い調べてみました。ゆくゆくは試してみたい構成です。
XEN Fault Toleranceの概要
XenにおけるFault Tolerance技術（耐障害性、略称：FT）と、よく使われるHigh Availability（高可用性、略称：HA）との違いは、 HAは「どれだけ障害が発生しづらいか」であり、 FTは「どれだけ障害に耐えられるか」になります。HAでフェイルオーバーが発生した場合、数秒から数分の接続断が発生しますが、FTは耐えている限りは利用状況に一切影響がないため、 例えばフェイルオーバー時の接続断が発生しない システムを実現できることになります。
これだけ聞けば夢の様な機能なので、新手のXEN使いである俺は調べ始めたのであった…。
参考リンク
Xen Remus
Xen Kemari
XEN Fault Toleranceの構成と比較
KemariとRemus
FTは様々な仮想環境で研究されていますが、俺はXENが大好きなのでXENのFTについて調べたところ、Kemari と Remus の２つが目につきました。Kemari はNTTデータのソフトウェアで主に XEN3 で紹介されていますがOSに依存しないらしく、Xen4 にKemariが組み込まれるかと思っていたら、Xen4 ではカナダのブリティッシュコロンビア大学が開発した Remus が採用されたようです。
Kemariはしっかりとした日本語の資料があるだけに口惜しいですが、今後はRemusの方を強く追うことになるのかなと思います。
動作イメージ
Foult Toleranceの基本イメージはこんな感じ。例えば、Dom0上でディスクイメージをDRBDで同期し、さらにDomU間でメモリデータをネットワーク越しに同期することでTCP接続などを保つ、といったところです。
Remusの動作イメージはこれ。
Kemariの動作イメージはこれ。
HA, FT, Kemariの比較表がわかりやすいです。
ソフトウェアFTとハードウェアFT
これらのようなソフトウェアFTだとディスクイメージとメモリを頑張って同期することで実現するけど、ハードウェアFTだとCPUレベルで処理内容を同期して実現するものが多いようです。ただ特殊なハードウェアを入れると、高いとか、臨機応変に発展できなさそうとか、そもそも楽しくないとか、いう理由をつけて選ぶことはないでしょう。が、資料を読んだり検討することに意味はあるので、ないがしろにしない程度に。。
Remusの実運用に向けて
バージョン
実際に採用するとなると、現時点では Debian Squeeze で Xen 4.0.1 になるので、Remusについて軽く追ってみたのですが、結構な制限があり、パフォーマンス
また、FT にするとパフォーマンスは 1/2 ～ 1/10 に落ちるようですが、ですが、機能的には使えるとしたら、Hadoopのマスターノード（NameNode, JobTracker or ResourceManager）はさほど性能面を求められないため、採用できる可能性はあると考えます。採用できたら、HAだと接続断が発生するとデータロストやジョブの失敗が発生していたところが、一切障害が発生しないことになります。
さらに言えば、同じように高パフォーマンスを必要としないが冗長性が重要なサービスは、仮想環境に入れてしまえばソフトウェアに依存せず完全冗長化できるという、まさに夢が広がりんぐなシステムになります。
ただまぁ、現実的にはFault Tolerance自体の開発研究にとても時間がかかったり、Fault Toleranceの機能自体が不安定で結果的に稼働率が落ちたりしそう、という理由でなかなか手をつけ難いと思います。今、下手に突っ込んでもエンジニアの自己満足で徒労に終わりそうなので、今後に期待したいと思います。
というかそれよりも先にHadoopのちゃんとしたHAに期待したい！
