vSphere 7で改良されたvMotion/Storage vMotionについて調べたことを記事にしたいと思います。
この記事は以下のVMwareのブログを参考にしています。
https://blogs.vmware.com/vsphere/2020/03/vsphere-7-vmotion-enhancements.html
https://blogs.vmware.com/vsphere/2020/06/vsphere-7-storage-vmotion-improvements.html
vMotion
vMotionは私がVMware製品と関わり始めた新人のペーペーだった頃(まだVCがVirtual Centerと呼ばれていた時代)から
存在するもはや皆さんご存じの代表的な機能だと思います。
動いてる仮想マシンを、ESXiから別のESXiに移動させるすごーい機能ですね。はい。
そもそも、どうやってそんなこと実現してるのかというと、移行元ESXiのメモリ上にある仮想マシンのデータを
vMotionを有効にしたvmkernel経由で移行先ESXiに渡しています。
と、この辺まではみなさんご存じではないでしょうか。
今回、先にご紹介したブログにvSphere 6.7までのvMotionの仕組みも解説されていまして、
それを読んでみますと、準備段階として、仮想マシンのvCPUにメモリ状態をトレースするツールをインストール
します。
これは、vMotion中に行われた変更を移行先ESXiにも送らないといけないからです。
もうちょっと詳細に書くと、メモリのどの部分が変更されたのかを追いかけてその情報を送信しないといけないからです。
vMotionが開始されると、そのツールのを使ってメモリ情報の更新を追いかけていくわけですが・・・
このときに従来のやり方では、仮想マシンのvCPUを一瞬(マイクロ秒らしい)停止させるという動きをしていたようです。
新しいvMotionは、全部のvCPUではなくvCPUを一つだけにして他のvCPUは処理を継続できるように改良したそうです。
これは、モンスターVM(ものすごいスペックの仮想マシン)をvMotionする場合を想定し、処理が中断しないように
するためのようです。
Storage vMotion
仮想マシンの各種ファイルは通常データストア内に存在します。
vmx、vmdk等々ですね、これらのファイルを元のデータストアから別のデータストアに移すのがStorage vMotionですね。
こちらにも、vMotion同様モンスターVMへの対応で改良がくわえられたようです。
改良がくわえられたのはFast Suspend and Resume（FSR）という機能です。
Storage vMotionは仮想マシンがホストを移動しませんが、実は同じホスト上で宛先となる仮想マシンを作成しそちらの
マシンに切り替えを行うのですが、その際にデバイスの状態とメモリデータの転送を同じホスト上で行う機能です。
FSRが処理を行うために要求されるvCPUは1つとなりますが、一時的にすべてのvCPUがスリープ状態になっていたようです。
小さい仮想マシンであれば影響は少ない(1秒以内？)ようですが、モンスターVMになれば・・・お察しですね。
どう改良されたのかについてブログの内容を確認しますと、面白いことにvMotionとは逆で1つのvCPUから全部のvCPUを
使って処理を行うことで処理の効率化を行い、ブログにもありますが、メモリ1TBとvCPU48個の仮想マシンで
かかる時間が7.7秒→500ミリ秒に短縮されたようです。
今回はvMotionとStorage vMotionの改良についての内容でした。
次回はRDSの改良について調べたいと思います。
