VMwareな日々

VMware環境関連の管理者/導入/トラブルシュートなどに役立ちそうな情報を備忘録として掲載とその他を少々投稿していくブログ

EVCに関する基本と考察と検証

こちらは先日のトレーニングで出た話題です。

先日はvMotionの話をしましたが、EVC(Enhanced vMotion Compatibility)で盛り上がりました。

 

そもそもEVCとは・・・と言うことで、"5行でわかる、EVC"です

  • Enhanced vMotion Compatibilityと呼ばれるvCenter Serverが持つ機能である。
  • vMotionによる、仮想マシンのホスト間移動を行うために、ホスト間のCPU間での互換性を保つ機能である。
  • クラスター単位で設定をする機能である。
  • IntelAMDの混在は不可、同ベンダーのプロセッサー間での世代差を埋める。
  • 仕組みは、CPUが持つ命令セットをホスト間で揃えるというもの。

こちらの図では、左側3つのホストは、EVCによりCPUの互換性が整えられており、VMのホスト間移動が"vSphere vMotion"にて可能なことを示している。全てが、命令セットを共通のものを使っている(例としては、命令セットA)

しかし、一番右のホストは”命令セットB”を使っているため、vMotionが出来ないということを示しています。

「VMware EVC」の画像検索結果 

現実の世界では、例えば次のような環境でEVCが活躍します。

  • 既存のvSphere ESXiクラスターが存在し、それらを構成するホストは複数のCPU世代が混在している。これらの互換性を埋め合わせるのにEVCを使う。

  • 既存のvSphere ESXiクラスターが存在し、それらを構成するホストは単一のCPU世代で形成されている。システムのリプレイスがあり、リプレイスのために一時的にCPUの世代が混在してしまう。この場合、ホスト間のCPU互換を整え、既存ホストから、新規ホスト上に仮想マシンを動かすために、"EVC"を有効にする。

 

そこで、EVCに関連してこんな質問が出ました。

この点において、検証を持って回答を正確に確認してみたいと思います。

まずはじめに次のような環境を用意しました。

f:id:instructor8010:20170727203557p:plain

【物理サーバー】

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は無効です)

f:id:instructor8010:20170727204057p:plain

何事もなく一瞬で終わります。(これは予想通りです)

f:id:instructor8010:20170727204159p:plain

検証1の結果:EVC無効な既存クラスターへの新規ホスト追加では、既存環境上の仮想マシンもホストも停止は不要。

 検証2

検証1の後、EVCを有効にする。

以下のメニューより、EVCを有効化します。今回は2つのプロセッサーの共通の世代として、Sandybridgeを選択します。

f:id:instructor8010:20170727204447p:plain

設定画面はこんな感じです。

f:id:instructor8010:20170727204822p:plain

ちなみに正しくないEVCレベルを設定しようとすると次のようなエラーが表示されます。

f:id:instructor8010:20170727204906p:plain

それでは、正しい設定(Sandybridge)を選択し、OKをクリックします。

f:id:instructor8010:20170727205122p:plain

結果は上記の通り、1秒で設定完了です。またT620上の仮想マシンも停止していません。

 

検証2の結果:新世代CPU側の新命令セットの無効化のためのEVC有効化では、旧世代プロセッサーで動作する仮想マシンの停止は発生しない。つまり、既存環境上の仮想マシンは停止が必要ありませんでした。

検証3

EVC有効なクラスターに、新世代CPUを搭載したノードを追加する。

検証2を終えた段階で、PowerEdge R630とPowerEdge T620は同一クラスター内に存在しています。まずこの検証を行うために、一旦PowerEdge R630を切り離します。

この際、仮想マシンを停止することなくホストをクラスターからはずすことができました。

なおこの際、クラスターから外すホストは、メンテナンスモードにする必要があるのでご留意ください。つまり、本番の環境の場合は、既存クラスターノードに対しvMotionを行い仮想マシンを逃がすか、切り離すノード上で仮想マシンを停止する必要があるという事です。

f:id:instructor8010:20170727205531p:plain

この点だけ取って見れば、本運用環境では、新旧CPU世代混在のマルチポストクラスターにおいて、旧世代CPU搭載のホストをリタイアする時の操作とも言えます。

実際クラスターホストのリプレイスということを考えれば、リタイア予定のホスト上で仮想マシンを動かすことは無いと思いますので、メンテナンスモードにすること自体は問題ありません。もちろん新旧ホストを比較した際に、新ホスト側でメモリやCPUなどのハードウェアリソースが足りない、ということが無いようにしましょう。

 

さて、本題です。現在上記EVC-Clusterは、”SandybridgeのレベルでのEVCが有効"な状態です

ここで更に2パターンに派生した検証をしてみたいと思います。

3-1 新世代のCPUを搭載するホスト上で仮想マシンを稼動させたまま、既存のEVCが有効なクラスターに追加をする

3-2 新世代のCPUを搭載するホスト上で仮想マシンを稼動させず、既存のEVCが有効なクラスターに追加をする

 

まず3-1です。Test-VMPowerEdge R630(Haswell)上で起動し、このままEVC-Clusterに投入を試みます。

f:id:instructor8010:20170727211117p:plain

ドラッグアンドドロップでホストをクラスター追加した後、即座にエラーが発生しました。

f:id:instructor8010:20170727211231p:plain

エラー内容詳細はこちら。

f:id:instructor8010:20170727211349p:plain

簡単に言えば、EVCレベル内に収まらない命令セットが利用されている仮想マシンがいるため、互換性に合わない状況です。つまり仮想マシンをダウンさせることでホスト追加ができると予想ができます。

 

検証3-1の結果:新世代CPUを搭載したホストで、仮想マシンを稼動させたままのEVCクラスターへの追加は、EVCの設定レベルによるが、追加ができないケースがある。

 

続いて検証3-2です。3-1と違い、R630上では仮想マシンを停止してからクラスターへホストを追加しました。結論としては、想定どおり仮想マシンを停止すれば、クラスターへの追加は可能です。

f:id:instructor8010:20170727211653p:plain

 

3-1 新世代のCPUを搭載するホスト上で仮想マシンを稼動させたまま、既存のEVCが有効なクラスターに追加をする ⇒ ホスト追加出来ません。

3-2 新世代のCPUを搭載するホスト上で仮想マシンを稼動させず、既存のEVCが有効なクラスターに追加をする ⇒ ホスト追加出来ます。

 以上です。

 

今回のシナリオは、既存のクラスター環境に対し、新規での製品を追加するであったり、既存クラスターノードを新製品にリプレイスするようなケースで有用なデータだと言えます。

新製品上で仮想マシンを動かしたまま、既存環境に追加をするシナリオは原則ないとは思いますが、ホストの追加作業だけであれば、ダウンタイムが発生しないということが本検証で明らかになったといえます。

 

但し、1点考慮をする必要があるのは、仮想マシンが利用する命令セットについてです。

仮想マシンの EVC モードの決定

f:id:instructor8010:20170727213623p:plain

上記のように、仮想マシンが利用するCPUの命令セットは、仮想マシンが"パワーオン"されたときに決定されます。つまりこのことは、例えば既存クラスター内のホストを総入れ替えした後に、EVCを無効化するとします。(例としては、Sandybridge世代とHaswell世代が混在した環境のクラスターから、Sandybridgeホストを全てを取り外し、クラスターを、クラスター内のプロセッサーがSandybridgeのみとなり、EVCが不要となる。このためEVCを解除する、というシチュエーション)

この際、EVCを無効にする=仮想マシンが、新しいCPU命令セットを即座に使えるわけではありません。

EVCによってマスキングされていたCPU機能は、仮想マシンを一度停止し、再度パワーオンしたタイミングから利用が出来るようになります。

ですので、CPUの機能を全て利用するためには、仮想マシンの停止とパワーオンが必要です。

 

また、この検証はあくまでもEVCに対するものだけですので、それ以外の作業などについては考慮していませんので、ホストの追加時にダウンタイムが本当にユーザーの環境で発生しないかと言われればその次第ではない、ということは強調しておきたいと思います。

 

 

<あとがき>

サポートの現場に長くいた身として、こんな体験談を聞くことがあります。

  • 複数のホストを持つvSphere Cluster内で、システムのトラブルが発生
  • これにより、クラスター内のメモリやCPUリソースが足りなくなり、既存仮想マシン環境にこれらを急遽足す必要が出る
  • 社内を探し回った結果、リタイア済みのホストを持ち寄り、応急処置としてそれをコンピュートリソース提供用に、既存クラスターに追加をする
  • 応急処置としての、ホストを追加後、vMotionにて複数の仮想マシンを、応急処置としてのホスト上に移動をする

これは、一見納得しうるアクションとも言えますが、”既存ホストと新規参加ホスト間でCPUの世代が同一(EVCを使わなくて良い)場合のみ有効なアクションです。”

さらに言えば、既存のホストCPU世代(古い)<新規加入のホストCPU世代(新しい)場合のみ有効です。

 

EVCの基本原則として、こちらを思い出して見てください。

f:id:instructor8010:20170727213623p:plain

つまりこういうことです。vMotionのためには新世代CPUと旧世代CPUとの互換を揃えるために、”EVCを有効にする必要がありますが、一旦仮想マシンを停止しないとEVCが有効に出来ません”

f:id:instructor8010:20170728071817p:plain

もちろん、上記の追加は全く無意味というわけではなくコンピュートリソース(CPUやメモリ)自体は純増します。

しかし、EVCを有効にしようとすると、検証3-1で得られた結果と同じく、”上位の命令セットを使った仮想マシンがいるため、EVCの有効化のためには一度それに該当する仮想マシンをシャットダウンが必要”となるわけです。

 

では、"ということは、vMotionにこだわらず、取り敢えずレガシーCPU搭載ホスト上で仮想マシンを動かしたい場合は、仮想マシンを停止して移動すればよいのか?"と言われれば、その通りです。

ですから、停止状態にある仮想マシンを起動するためのCPUやメモリリソースが足りないというケースであれば、上記の図で取り扱うホスト追加は有効な手段だと言えます。

(このレベルの話になると、既にブログの本題のEVCとは何の関係もありませんが)

 

トラブルが発生した場合は誰しも迅速で正確な判断を求められます。

 

このあとがき記載は、”トラブルに伴うコンピュートリソース不足に対し、レガシーなハードウェアを搭載するホストを追加すること”を推奨するものではありません。

そもそも論ですが、クラスターというのは、前項でもお話した通り耐障害性のために組むのであって、障害が起きてリソースが足りないというのは、極端な言い方をすればナンセンスなわけです。サイジングや運用に問題があるとも言えてしまうわけです。

instructor8010.hatenablog.jp

 ですので、応急処置は応急処置であって、それが現場にそぐわないケースもあるため、もし仮にそうしたアクションを取る場合の考慮事項として載せています。

 

いつもvMotionのトレーニングは、サポート向けに対し講義を行う場合はBIOSファームウェア更新などの計画ダウンタイム取得に使う機能であったり、ディザスタリカバリサイトへの移行などのお話をするのですが、今回はセールスの方が受講者ということもあり、新規ホスト追加など別視点での質問を多く得られたことは、私自身も大変いい経験が出来たと思いました。

 

しかし、今回の記事は長くなったなと改めて感じました(笑)