vHoge

VMwareのアレコレ備忘録。CLIでがんばるネタ多め。

vMotion のスタン時間に対するチューニング要素はあるのか?

お仕事でそんな話をしていたのでちょっとまとめ。

TL;DR

チューニングに時間をかけるより、SLA 見直すなりアプリのアーキテクチャを見直す方が健全。

今さらながら vMotion とは

vMotion とは vSphere において超が付くほどの代表的な機能で、 x86 サーバにおける仮想マシンのオンラインマイングレーションを商用レベルで初めて実現したもの。
(メインフレームとか UNIX サーバはまで知らないが聞いたこともないような?)

仮想マシンを稼働させたまま、ある ESXi ホストから別の ESXi ホストへ移動させる機能で、仮想マシンから見るとその影響はほぼ観測できず、仮想マシン外から見ても Ping を 1個落とすか落とさないかのレベルで移動ができる。
vMotion により vSphere 基盤のメンテナンス性を高めることができ、停止を伴うような ESXi ホストのメンテナンスや基盤リプレースでの移行を仮想マシンを停止させることなく実施ができる。

かれこれ 20年近く歴史がある機能であり、利用実績も凄まじいため、vMotion のために vSphere を使っているという人も多い。

vMotion のスタン時間

仮想マシンを停止させることなく別ホストへ移動ができる vMotion ではあるが、前述の通り仮想マシン外から見た際には Ping を 1個落とすか落とさないかということで、完全無停止というものではない。
公式での仕様としても1秒以下の停止(=スタン時間)が発生する、となっている。

なので、このスタンを嫌がる人もいて DRS はおろか、vMotion すら利用しないというところもあったり…
なんとかチューニングでこのスタン時間を短縮化できないかというお話。

vMotion の挙動

詳細についてはホワイトペーパーを参照。
https://www.vmware.com/docs/vmotion-7u1-perf

もしくは下記の公式ブログにて詳しくまとめられている。
blogs.vmware.com
かなり詳細に書かれているが、要点だけピックアップすると以下の流れ

  1. ターゲットホストで互換性チェックを実行
  2. 仮想マシンの移行スペックを作成
  3. 移行スペックよりターゲットホストで仮想マシンリソースを確保しプロセスを作成
  4. ソースホストの仮想マシンにてページトレーサを有効化
  5. ソースホストからターゲットホストへ仮想マシンのメモリをプレコピー
    1. 仮想マシンのメモリをコピー/コピー中にメモリが n GB 変更される
    2. 次のコピーが 500ms で完了するか計算
    3. 完了しない場合、変更された n GB のメモリをコピー/コピー中にさらにメモリが m GB 変更される
    4. 次のコピーが 500ms で完了するか計算
    5. 完了しない場合、変更された m GB のメモリを(ry
  6. 完了する場合、ソースホスト内で RPC を発行し仮想マシンをスタンさせ、最後のメモリを転送
  7. ターゲットホストにて転送されたメモリより仮想マシンのチェックポイントより復元
  8. ターゲットホストで仮想マシンを再開
  9. マイグレーションが完了

ホワイトペーパーを追っていくとトレーサーなり SDPS、スイッチオーバーで色々な改善・最適化が含まれていることが記述されているが、ここではひとまず割愛。

この流れにおいてスタン時間は 6~8 の間となっており、時間としては

  • 最後のメモリ転送時間 max 500ms
  • RPC 周りのオーバーヘッド 100~200ms

にて机上では最大でおよそ 700ms-800ms 程度となり、1秒以下とはなる。

Migrate.PreCopySwitchoverTimeGoal

あまりチューニング要素は無さそうですが…この中で最後のメモリコピーの処理時間の閾値となっている 500ms という部分は実は ESXi の詳細パラメータにだったりする。
リンクは 6.0 の詳細設定集ですが、最新の 8.0 U3 にも存在している。 github.com

・Migrate.PreCopySwitchoverTimeGoal
Goal time in milliseconds to send changed pages after pre-copy completes

上の流れからすると、例えば Migrate.PreCopySwitchoverTimeGoal の値を半分の 250 にすれば、全体としては 250+200+α で 500ms 程度には収まる計算にはなる

ただし、Migrate.PreCopySwitchoverTimeGoal を短くするということはスイッチオーバータイミングの判定がシビアになるため、メモリのプレコピー反復がなかなか終わらず vMotion 全体の処理が長期化してしまう、メモリ変更量がいつまでたっても転送時間に追い付かず SDPS の影響を受け続ける、(もしくは vMotion が終わらず中断される?)と言ったことが考えられ、ハードや環境要素も絡む中で効果が出るかはかなりの検証が必要。

また事例としてもこのパラメータでチューニングを行ったという情報は見たことがなく…

効果があったとしても…

仮に効果があったとしてもここまでの内容はあくまでプロセスの切替時間
実影響レベルで考えた場合、Ping 疎通の話で見るとプロセス以外にネットワークレベルでの切り替えが必要であり、RARP によるネットワーク機器の MAC アドレステーブル変更が行われる。
knowledge.broadcom.com

この部分についてはネットワーク構成やネットワーク機器での話となってくるため、 vSphere ではがんばれない世界…

結局

Migrate.PreCopySwitchoverTimeGoal で vMotion スタン時間短縮に多少の効果はあるかもしれないが、プロセス切替/ネットワーク切替含めた全体から見ると微々たるレベルであり、その上でリスクを考慮しつつ妥当なパラメータ値を検証して値を決めていくのはかかる工数に対しては見合わないのではないのかなぁと…

ここに労力をかけるよりは SLA やアプリ側のアーキテクチャを見直し、vMotion 影響を無視できる方向に進んでいく方が全体としてはシンプルで健全なのではないでしょうか。

他のチューニング要素

あまり深追いはしていなので、もし他のチューニング要素あれば教えてくださいmm