VMware EVC設定に関する基本、ユースケース及び検証レポート
本記事は過去に投稿しました”EVCに関する基本設定と考察と検証”に再編集を加えたものです。
5行で分かるEVC
- Enhanced vMotion Compatibilityと呼ばれるvCenter Serverが持つ機能である
- vMotionによる仮想マシンのホスト間移動を行うために、ホスト間のCPU互換性を保つ機能
- クラスター単位で設定をする機能
- IntelとAMDの混在は不可、同ベンダーのプロセッサー間での世代差を埋める
- 仕組みは、CPUが持つ命令セットをホスト間で揃えるというもの
本機能はVMware Infrastructure 3の新機能として世の中に登場して以降、多くのユーザーに親しまれている機能です。
VMware Infrastructure 3 リリース ノート
本機能の重要性図で学ぶ
本記事を投稿しようとしたきっかけとしてはトレーニングで思っていたよりも深い質問が多かったためです。特に、営業と導入作業に携わる方からの質問が多い傾向があります。
本機能はvSphere環境に対して将来的な拡張性をキープするために大変重要な機能となります。
そのため販売時であったり、現地でのESXi追加作業などの際にこれらを気にされる方が多いのも納得です。
EVC基礎と利用事例
上図では、左側3つのホストはEVCによりCPUの互換性が整えられており、VMのホスト間移動が”vSphere vMotion”にて可能なことを示している。全てが、命令セットを共通のものを使っている（例としては、命令セットA）
しかし、一番右のホストは”命令セットB”を使っているため、vMotionが出来ないということを示しています。
現実の世界では、例えば次のような環境でEVCが活躍します。
- 既存のvSphere ESXiクラスターが存在し、それらを構成するホストは複数のCPU世代が混在している。これらの互換性を埋め合わせるのにEVCを使う。
- 既存のvSphere ESXiクラスターが存在し、それらを構成するホストは単一のCPU世代で形成されている。システムのリプレイスがあり、リプレイスのために一時的にCPUの世代が混在してしまう。この場合、ホスト間のCPU互換を整え、既存ホストから、新規ホスト上に仮想マシンを動かすために、“EVC”を有効にする。
そこで、EVCに関連してこんな質問が出ました。
- 既存クラスター(EVC無効)に対し、新世代プロセッサー搭載のノードを追加する際、仮想マシンや既存ホストのダウンタイムはいらないのか？
- 既存クラスター(EVC有効)に対し、新世代プロセッサー搭載のノードを追加する際、仮想マシンや既存ホストのダウンタイムはいらないのか？
- EVCの有効化を行う上での注意点は何かあるか？
EVC有効化に関する検証
この点において、検証を持って回答を正確に確認してみたいと思います。
まずはじめに次のような環境を用意しました。
【物理サーバー】
- PowerEdge R630 – Intel Xeon Processor E5-2603L v3(Haswell, 新世代CPU)
- PowerEdge T620 – Intel Xeon Processor E5-2630 (Sandybridge, 旧世代CPU)
PowerEdge T620はクラスター内に存在する。またT620上では仮想マシンが動作しています。
【ハイパーバイザー】いずれもVMware ESXi 6.5.0、vCenter Serverも6.5.0を利用した環境です。
【検証】
検証1:EVC無効なクラスターに、新世代CPUを搭載したホストを追加する。この際、既存クラスター内では仮想マシンが動作しているとする。
検証2:検証1の後、EVCを有効にする。
検証3:EVC有効なクラスターに、新世代CPUを搭載したホストを追加する。
検証1：仮想マシンが起動しているEVC無効なクラスターに、新世代CPUを搭載したホストを追加する。
以下の状態から、ドラッグアンドドロップでesxi02をクラスターアイコンに追加します。
(この際現在はEVCは無効です)
何事もなく一瞬で終わります。(これは予想通りです)
検証1の結果：EVC無効な既存クラスターへの新規ホスト追加では、既存環境上の仮想マシンもホストも停止は不要。
検証2：検証1の後、EVCを有効にする
以下のメニューより、EVCを有効化します。今回は2つのプロセッサーの共通の世代として、Sandy Bridgeを選択します。
設定画面はこんな感じです。
ちなみに正しくないEVCレベルを設定しようとすると次のようなエラーが表示されます。
それでは、正しい設定(Sandy Bridge)を選択し、OKをクリックします。
結果は上記の通り、1秒で設定完了です。またT620上の仮想マシンも停止していません。
検証2の結果：新世代CPU側の新命令セットの無効化のためのEVC有効化では、旧世代プロセッサーで動作する仮想マシンの停止は発生しない。つまり、既存環境上の仮想マシンは停止が必要ありませんでした。
検証3：EVC有効なクラスターに、新世代CPUを搭載したノードを追加する
検証2を終えた段階で、PowerEdge R630とPowerEdge T620は同一クラスター内に存在しています。まずこの検証を行うために、一旦PowerEdge R630を切り離します。この際、仮想マシンを停止することなくホストをクラスターから外すことができました。
なおこの際、クラスターから外すホストは、メンテナンスモードにする必要があるのでご留意ください。つまり、本番の環境の場合は、既存クラスターノードに対しvMotionを行い仮想マシンを逃がすか、切り離すノード上で仮想マシンを停止する必要があるという事です。
この点だけ取って見れば、本運用環境では、新旧CPU世代混在のマルチホストクラスターにおいて、旧世代CPU搭載のホストをリタイアする時の操作とも言えます。
実際クラスターホストのリプレイスということを考えれば、リタイア予定のホスト上で仮想マシンを動かすことは無いと思いますので、メンテナンスモードにすること自体は問題ありません。もちろん新旧ホストを比較した際に、新ホスト側でメモリやCPUなどのハードウェアリソースが足りない、ということが無いようにしましょう。
さて、本題です。現在上記EVC-Clusterは、”Sandy BridgeのレベルでのEVCが有効”な状態です。
ここで更に2パターンに派生した検証をしてみたいと思います。
3-1：新世代のCPUを搭載するホスト上で仮想マシンを稼動させたまま、既存のEVCが有効なクラスターに追加をする
3-2：新世代のCPUを搭載するホスト上で仮想マシンを稼動させず、既存のEVCが有効なクラスターに追加をする
まず3-1です。Test-VMをPowerEdge R630(Haswell)上で起動し、このままEVC-Clusterに投入を試みます。
ドラッグアンドドロップでホストをクラスター追加した後、即座にエラーが発生しました。
エラー内容詳細はこちら。
簡単に言えば、EVCレベル内に収まらない命令セットが利用されている仮想マシンがいるため、互換性に合わない状況です。つまり仮想マシンをダウンさせることでホスト追加ができると予想ができます。
検証3-1の結果：新世代CPUを搭載したホストで、仮想マシンを稼動させたままのEVCクラスターへの追加は、EVCの設定レベルによるが、追加ができないケースがある。
続いて検証3-2です。3-1と違い、R630上では仮想マシンを停止してからクラスターへホストを追加しました。結論としては、想定どおり仮想マシンを停止すれば、クラスターへの追加は可能です。
3-1新世代のCPUを搭載するホスト上で仮想マシンを稼動させたまま、既存のEVCが有効なクラスターに追加をする ⇒ ホスト追加出来ません。
3-2新世代のCPUを搭載するホスト上で仮想マシンを稼動させず、既存のEVCが有効なクラスターに追加をする ⇒ ホスト追加出来ます。
検証レポートはこれで以上です。
今回のシナリオは、既存のクラスター環境に対し、新規での製品を追加するであったり、既存クラスターノードを新製品にリプレイスするようなケースで有用なデータだと言えます。
新製品上で仮想マシンを動かしたまま、既存環境に追加をするシナリオは原則ないとは思いますが、ホストの追加作業だけであれば、ダウンタイムが発生しないということが本検証で明らかになったといえます。
但し、1点考慮をする必要があるのは、仮想マシンが利用する命令セットについてです。
仮想マシンの EVC モードの決定 – VMware Docs
上記のように、仮想マシンが利用するCPUの命令セットは、仮想マシンが”パワーオン”されたときに決定されます。つまりこのことは、例えば既存クラスター内のホストを総入れ替えした後に、EVCを無効化するとします。(例としては、Sandy Bridge世代とHaswell世代が混在した環境のクラスターから、Sandy Bridgeホストを全てを取り外し、クラスターを、クラスター内のプロセッサーがSandy Bridgeのみとなり、EVCが不要となる。このためEVCを解除する、というシチュエーション)
この際、EVCを無効にする＝仮想マシンが、新しいCPU命令セットを即座に使えるわけではありません。
EVCによってマスキングされていたCPU機能は、仮想マシンを一度停止し、再度パワーオンしたタイミングから利用が出来るようになります。
ですので、CPUの機能を全て利用するためには、仮想マシンの停止とパワーオンが必要です。
また、この検証はあくまでもEVCに対するものだけですので、それ以外の作業などについては考慮していませんので、ホストの追加時にダウンタイムが本当にユーザーの環境で発生しないかと言われればその次第ではない、ということは強調しておきたいと思います。
EVCの有効化に伴うパフォーマンスへの影響
EVCの有効化についての検証が長く続きましたが、本機能利用に伴いアプリケーションへのパフォーマンス懸念も質問として頂きます。この点については次の回答ソースがあります。
- Impact of Enhanced vMotion Compatibility on Application Performance
上記内容によれば、データベースやJavaアプリケーションでは検証の限りではEVCモードのレベル差でパフォーマンス差が生じなかったものの、ビデオエンコードと暗号化の面では特定のEVCレベルにて若干のパフォーマンス変化が見られた事が紹介されています。 - EVC と CPU の互換性の FAQ (1005764) – VMware KB
こちらのKBでは上記のホワイトペーパーとは違い、そもそもアプリケーションが正常動作しないケースについての言及です。アプリケーションがCPUにアクセスをする際に、CPUの情報を取得する方法として、”CPUID命令”を利用しない場合（独自の手法を利用する場合）問題が起きる可能性を示唆しています。CPUID命令を利用せずにCPUの情報を取得した場合、マスクされたCPU機能を仮想マシン内のアプリケーションが利用してしまい、その状態でvMotionを行ってしまうと、移行先でそのCPU機能が利用出来ない場合にアプリケーション動作に問題が生じるというものです。 - Detecting and Using CPU Features in Applications (1005763) – VMware KB
本記事では上記日本語KB(1005764)と同じ事が記述されていますが、より細かいCPUIDについての情報を得たい場合はこちらの記事も合わせて参照ください。
また、インテル社が過去にリリースしているCPUIDについての紹介資料も確認しましたので、興味がある方はこちらもご覧ください。インテル® プロセッサの識別とCPUID命令
vSphere 6.7からの新機能
仮想マシンの属性としての Enhanced vMotion Compatibility – VMware Docs
vSphere 6.7からはEVCをより柔軟に取り扱えるように、仮想マシンレベルでの設定値として同様の機能が利用可能となりました。この機能が登場したことで、クラスターレベルでのEVC設定と仮想マシンレベルでのEVC設定が２つ存在する場合は、仮想マシン側が優先されます。この機能によって得られる利点は２つあると考えられます。
- 特定の仮想マシンにだけ、任意のEVCレベルを設定出来るため、パフォーマンス影響を低減可能
- VMware Cloud on AWSに対してvMotionを行うための互換性設定に利用可能
特に２ですが、オンプレミス環境の仮想マシンで、VMC on AWS環境にvMotionを検討する場合、通常であればEVCはクラスターレベルで指定する必要がありますが、クラウドとオンプレミスのホストは、権限の兼ね合いにより同一クラスターオブジェクトに含むことが出来ません。そのため、CPUの互換性を合わせるためには、従来のEVCが利用出来ないということになります。VMC on AWS環境のホストは、現在ではBroadwellレベルでのCPU互換性として取り扱われています。
つまりこの新機能が無い限り、Broadwellレベルを満たせるオンプレミス環境で無い限りは、クラウドに対するvMotionが実施出来ないと言えます。
今回この機能が登場した事で、オンプレミス環境のみで使う仮想マシンにはクラスターレベルで定義したEVCを利用し、クラウドとの連携も見据えた仮想マシンには仮想マシンレベルでEVCを設定するということが可能になります。
ちなみにDell EMC PowerEdgeの場合、Broadwellが搭載された世代は第13世代のPowerEdgeからとなります。
“Software Defined”データセンターのトレンドに対応： デル、「Xeon E5-2600 v4」搭載の第13世代PowerEdgeサーバを出荷
本記事のまとめ
- EVCはクラスター構成時及び構成後いずれでも設定変更が可能である
- 既存のEVCクラスターに新規ホストを追加する場合は、次のようなホストは追加が出来ない新世代CPUを持つホストで且つ電源状態ONの仮想マシンを保有している場合
- これは仮想マシンが起動する際にCPUの命令セットを決定する仕様に基づく
- 上記ケースの場合は、一旦仮想マシンをシャットダウンし、EVCクラスターにホスト追加を行えばOK
- EVCによって、一部のアプリケーションは動作不可、またはパフォーマンスへの影響も想定されるため、設定前にはパフォーマンスへの影響がサービス提供に影響が無いかを確認するようVMwareは推奨しています
- CPUID命令を利用しないアプリケーションを仮想マシン上で動作させる場合は、EVC環境はこれをサポートしない
- vSphere 6.7からは仮想マシンレベルでCPUレベルを指定が出来る
コメント