SANBOOT実験がてら、ようやくWindows Storage ServerとiSCSI-Targetの環境が確立したので、さっそくLive Migrationの構成をとってみました。

実際には

• Windows Storage Server側でiSCSI-Targetならびに論理ディスクを作成
• これをiSCSI経由で参照できるように各クラスタノードのiSCSI-initiatorを構成します。
• 見えたディスクをいったんフォーマットします
• クラスタにディスクを登録します（一般的なボリュームとして）
• 登録したディスクをクラスタ共有ボリュームとして登録します
  • クラスタにディスク登録した段階でいったんドライブ文字が割り当てられますが（今回Zが割り当てられた）、クラスタ共有ボリュームとして構成した時点で、「C:\ClusterVolume\Volumex (x:任意の値)」にマウントされた状態での攻勢となります。
• このクラスタ共有ボリューム上に、仮想マシンを構成します

という流れになります。

実際にLive Migrationさせてみると確かにすごい。pingの欠落が1パケットしかありませんでした。

Quick Migrationの場合、「イメージ凍結」→「ディスク切り替え」→「凍結状態解除」の3ステップを踏むのですが、Live Migrationだと「移行」という1つのステップで済んでしまうためにこうして高速化するものと考えられます。メンテナンスでは結構重宝するのではないかと、ちょっぴり期待が持てます。切り替えはおよそ1分程度で完了しましたが、まだ搭載したVMがウイルス対策ソフトしか入れてない状況のため、実際にはもう少しかかるんじゃないかとみています。それでもQuick Migrationよりは早いんじゃないかなぁ？

さて、傾向の違いを確認するためにパフォーマンスモニターで計測もしてみました。

左から

• Quick Migration：サーバAからサーバB
• Quick Migration：サーバBからサーバA
• Live Migration：サーバAからサーバB
• Live Migration：サーバBからサーバA

サーバAというのは、計測対象のサーバ、サーバBというのはもう一台のサーバを意味しています。傾向としては、Quick Migrationはディスクに高い負荷がかかっているのに対して、Live Migrationはネットワークに高い負荷がかかっていることです。

Quick Migrationはイメージ凍結時にそれまでメモリに蓄えられた情報をディスクI/Oに送り込む、いわゆるハイバネーションを実行するため、このようにディスクI/Oが発生するものと考えられます。グラフでは読み取れませんが、およそ40MB/secのランダムIOが発生してました。逆にネットワークに関しては特に負荷がかかってません。

これに対してLive Migrationはイメージ凍結というよりは、サスペンドに近いことを行い、サスペンドして凍結したメモリ情報を一気にネットワークで伝送するようです。ゆえにハイバネーション切り替えなQuick Migrationと異なり、ディスク負荷は極端に低いものとなってます。そんで、切り替えも早いと。ディスクは行って数百KB/secなのに対してネットワークはなんと500～800Mbps使用していました。従来通りのインターコネクト(100Mbps)で挑んじゃったらこりゃ死んじゃいますな＾＾；本気でOracle RAC級のインターコネクトを検討したほうがよさそうです。

CPUはどちらにしてもそれなりの負荷がかかるようです。今回Quick Migrationの対象は一気に2台、Live Migrationの対象は1台と基準が異なっているため、なんとも言えないところがありますが、結局はディスクI/OやネットワークI/Oに引っ張られて負荷が上昇しているものと予想されます。

個人的にはこうしたメンテナンス時の瞬間停止は覚悟して然るべきものと認識しており、少なくともチキンな日本企業がいくら「Live Migrationなら無停止で行けますぜ！」なんていわれても、信用なんてするはずがなくて。vMotion使って定期メンテナンスを無停止でやりました・・・なーんて言う企業があるとはとても思えんのですけど・・・というか、メモリリークを恐れてゲストOSを定期リブートする運用だってあるだろうに。そう考えると、Quick Migrationのほうがまだ制御になじみがあり、安心感を持って操作できるかなぁと思います。

逆にLive Migrationはまだまだ未知。の世界なのかなと。どちらかというとLive Migrationよりもクラスタ共有ボリュームに興味があります。RACに近い共有ディスクのコンセプトで、今後そのうちSQL ServerでもRACチックなことはできたりしないかと。ささやかに負荷分散＋稼働率の高いクラスタが登場することをひっそりと願ったりしています。

しかしおんなじHyper-VでもMigration方式違うとこんなにやり方変るのね・・・面白いわぁ（笑）