VMwareに先行したVxRailの優秀な機能
VxRail LCM
VxRailを代表する優秀な機能です。VxRail ManagerがvCenter（内部型に限る）とESXi とハードウェア関連（Driver/Firmware）のコンポーネントを一元管理のもとUpgradeします。Upgrade前後の互換性やUpgrade手順はすべてDellによって動作検証済みであり、ユーザによる事前の動作検証や手順確認を必要としません。
一方でvSphere/vSAN観点では、VxRail LCM から遅れること約4年後の2020年にvSphere LCMという機能をリリーしました。vSphereで管理できないハードウェア関連コンポーネントは、各サーバベンダが提供するHSM（Hardware Support Manager）と連携することで一元バージョン管理を実現しています。
しかしながら、vLCMはvCenterやHSM自体のUpgradeが含まれません。手順の最適化やUpgradeファイルのパッケージ化など様々な面でVxRail LCMのほうが機能面・品質面でも先行し続けています。
vSAN Cluster Shutdown
こちらもVxRailが当初から提供している機能です。VxRail 上の管理VM（VxRail Manager や vCenter）を含め、vSAN Clusterを安全に正しい手順でシャットダウンします。
VxRailのリリース初期のころは、またVMwareのvSAN自体がそれほど世間から認知・浸透しておらず、通常の３Tierと同じ手順でShutdownしてしまった結果、Shtudownできなくなったり、アクセス不可となるような事例もしばしば目にしました。しかしながらVxRailであればそういった心配なく誰でも簡単に正しい手順でShutdownができます。
あまり知られていませんが、VxRail Shutdown機能はShutdownだけでなく、PowerUp時にも活躍します。Shutdown時と同様にPowerUp時もvSAN特有の手順や考慮事項が必要になりますが、VxRailであれば、サーバの電源ボタンを押すだけで自動的に、① ESXi の起動の待ち合わせ~②メンテナンスモード解除～③vSANの有効化～④管理VMの起動、が実行されます。
一方で、vSphere/vSAN観点でこの機能が追加されたのは、VxRailから遅れること約5年後の2021年のvSAN 7U3からです。この新機能はVxRail の Cluster Shutdown と近しい機能レベルに仕上がっています。
vCenter on vSAN クラスタのブートトラップ
vSANを構築するにはvCenterが必要です。
vCenter を構築するには、ESXiとDatastoreが必要です。
では？vCenterをvSAN Datastore上に構築したい場合はどうしますか？
勘のよい方なら、金庫の中のカギ状態や、鶏と卵の問題と同様のジレンマに陥っていることに気づかれたと思います。
しかしながら、vCenter と vSAN の関係性については抜け道があります。実はvSAN はvCenterが無くても構築できるのです。ただしGUIで実施するより難易度が高いです。
そのため、vSANがリリースされた初期のころは vCenterを先に”別の場所”に構築しておいてから、あとでvSANを構築し、vCenterをvSAN DatastoreにMigrationする、といった手順を採用することがほとんどだったと思います。
しかしながら、”別の場所” を用意してもらうようであればHCIとしては期待外れと言わざるを得ないでしょう。もちろん VxRail はそんなことはさせません。VxRailでは、vSANの構築やvCenterのインストールも含めてすべて自動化されています。
一方でvSphere/vSAN観点では、vCenterの構築とvSANの有効化が同時できるようになったのはvSAN6.6からであり、VxRailのほうが1年以上先行しています。
vCenterを停止せずにEVCを有効化
最後はちょっとだけ毛色の異なる機能に着目してみます。
1つ前のvCenter on vSAN のブートスラップとも関係するのですが、同じような関係性として、vCenter と EVC があげられます。なぜならば、EVCを設定するためにはvCenterが必要でありながら、vCenterがいることでEVCを設定できなくなるからです。
vSphere ClusterにおいてはEVCはデフォルト無効であり、通常はvCenterの構築よりも先に有効化をしておく必要はありません。
しかしながらVxRailは異なります。VxRailは過去のCPU世代のサーバとの混在をサポートしています。古いCPUのノードが追加されることを考慮して、あらかじめEVCを古い世代に合わせておく必要があるのです。そのため、VxRailは初期構築直後ですでにHaswellという古いCPU世代でEVCモードが有効化されています。
EVCを始めて有効化する際や、EVCモードを古いCPU世代に変更する場合は、クラスタ上の全VMの停止が必要です。VxRailでこれをやろうとするとvCenterを含めたすべてのVMを停止する必要があり、結果としてvCenterが停止しているのでEVCを有効化する手段がなくなります。
では、VxRailはどのようにして、vCenterを稼働させたままEVCを有効化するのでしょうか？
実はvCenterとEVCの関係にも抜け道があります。先ほどはすべてのVMを停止させる必要があると記載しましたが、厳密にはEVC有効化後に利用できなくなる（マスクされる）CPU機能を利用しているVMをすべて停止する必要があります。したがって、vCenterがマスクされるCPU機能を利用していなければ、vCenterを起動しながらEVCを有効化できます。
しかしながら、EVCが有効になる前に仮想マシンを起動すると利用可能なCPU機能のすべてが利用できる状態で稼働してしまいます。
勘のいい方なら Per VM EVCを使っているのだな、と勘づいたかもしれませんが、残念ながらハズレです笑
vSphereがPer VM EVCをリリースしたのは2019年のvSphere 6.7からです。一方でVxRail は vSphere 6.0 のころから初期構築中にEVCを有効化できてますので、Per VM EVCを利用せずに実現できていることになります。（そもそも Per VM EVC は稼働中のVMには設定できない）
実はこのEVCにかかわる仕組みについてはもう一つ抜け道を利用しています。冒頭でEVCを設定するためには、vCenterが必要だと説明しましたが、ここの抜け道があります。実はEVCで移用されるCPU 機能マスクの設定を直接ESXiの構成ファイルに記載することでも実現できるのです。
VxRailで利用されるノードは、工場から出荷された状態で既にEVC設定が書き込まれています。もしくは、Reimageした場合や、vxrail-primary コマンドで再セットアップした場合も書き込まれるようになっています。Per VM EVCではなく、Per Host EVCといったイメージです。
この Per Host EVC （仮称）については、ノード内の以下のPythonスクリプトで実施されています。
/usr/lib/vmware/marvin/vxrail_primary.py
CPUマスクの手動設定というと難しそうに感じますが、実際の操作はコピペですね笑
一方で、vSphere/vSAN観点では、vCenterが稼働するESXi クラスタ の EVC モードを古いCPU世代にするためには以下のKBで説明される手順を手動で実施しなくてはなりません。
https://kb.vmware.com/s/article/1013111
古いCPU世代との混在を考慮したクラスタ管理機能という観点においても、VxRailはただvSphere/vSANを利用するだけでなく、それ以上の技術を用いて高品質・高機能を提供しているといえます。
コメント
コメントを投稿