VMware Infrastructure 3 の Enterprise 以上のエディション(新バージョンで製品の名称が変更。VMware vSphere 4 の Advanced) で利用可能になる VMotion は、ホスト間でゲスト OS を動作させたまま移動させる目玉機能の一つでぜひ使ってみたいところだが、コストその他諸々の理由で、残念ながら自宅サーバーごときに気軽に導入できる代物ではない。そこで VMotion を期待する方にコレジャナイロボ的なガックリ感を与える恐れもある無理やりマイグレーションシステムを構築して「ナンチャッテ VMotion」と勝手に命名し、「ちょっと便利になったかも」と言うことで我慢することにする。もちろんライブ・マイグレーションではなく単なるコールド・マイグレーションなので、なるべくダウンタイムを短くする方針で行く。

と言っても、カラクリは次のように単純だ。

  1. VMware Server が稼動する VM ホストを 2台(「A」及び「B」)用意する。
  2. 何らかの方法で LAN 上に共有ストレージを用意する。
  3. VM ゲスト「C」を共有ストレージ上に配置する。
  4. A、B それぞれで C を VM ゲストとして登録し、普段は A 上で C を動作させる(※ 双方で同時に動作させないこと)。
  5. A で「A 上の C」の死活を常時監視させ、「A 上の C」が正常にシャットダウンしたか一定期間応答しない場合は、何らかの方法で B に通知する。
  6. B は A から「A 上の C」が停止した通知を受けるか、一定期間 A から応答が途絶えた場合は自身で A 及び「A 上の C」の状態を確認。「A 上の C」が停止している可能性が高いと判断した場合は、「B 上の C」を起動させる。

VM ホスト間の「通知」は、相手に伝われば何でもいいので、共有ストレージ上等に「置手紙」を置くだけでも十分だ。僕はこのファイルの有無をトリガーにする原始的な手法をよく使う。また各 VM ホスト上での VM の状態確認や操作は、一般的なコマンドや vmware-cmd コマンドを活用してシェルスクリプトを自作することで、ある程度自動化させられる。もちろん状況によっては、VMware Server Console 等から手動で VM を停止/起動させるだけでもいい。

実は一時期、LAN 上の共有ストレージが存在しない状態でこの「ナンチャッテ VMotion」を強行していたのだが、上記手順の途中で「10数GB の VM を丸ごとコピーする」操作が入るため、我が家の家庭内 LAN はギガビット化されているとは言え、ゲスト OS を 1台移動させるのに 20~30分かかっていた。更に復旧時にもまた逆方向に同じ操作をするため、非常に効率が悪かった。

そこへ方法は何でも構わないが、LAN 上の共有ストレージ(僕の場合は BUFFALO の NAS 製品 LS-WH2.0TGL/R1)を利用すると切替は VM の停止&起動だけなので、VM のダウンタイムは劇的に短くなる。VM のコピーが終わるまでボケーっと待つしかなかった原始時代と比べれば、ライブ・マイグレーションと見紛うような時間短縮が実現されたと言っても過言ではない(※ 誇張してます)。VM をローカルストレージと NAS 上に置いた場合の性能比較は、いずれ紹介するかもしれない。

ただ、現在我が家の物理サーバーは、残念ながら Linux が 1台のみ。他の VM ホストになり得る PC 2台は全て Windows クライアントなので、一時期実稼動していた自動「ナンチャッテ VMotion」は、今は手動で行っている。

さて、vmawre-cmd コマンドはシェルスクリプト等と組み合わせることで、VM の管理に絶大な効果を発揮する。このコマンドは Windows 版、Linux 版双方の VMware Server で同じように使えるが、VMware Server を本格的に運用するなら、ホスト OS は手軽なスクリプト作成・実行環境が充実した Linux の方が、柔軟な運用ができて楽しいと思う。

Comments are closed.