どうも、Tです。
以前、疾風のように現れたvCLS(vSphere Cluster Services)の記事を書きました。
当時はvCenter7.0Update 2bで確認していたのですが、その後1か月おきくらいにvCenterのパッチがリリースされるという嵐のような月日が流れております。
今回、Update3がでたので、変わった部分をまとめてみました。
目次
環境
- vcsa：7.0 Update3 18700403
- VMware ESXi, 7.0.2, 17867351
ESXiはアップデートする余力なかったのでUpdate3じゃないです・・・。
vCLSの名前が変わった
vCLSの仮想マシン名の命名規則が変わりました。
vSphere 7.0 Update 3 環境にデプロイされた新しい vCLS 仮想マシンで互換性の問題が発生する
vSphere 7.0 Update 3 環境にデプロイされた新しい vCLS 仮想マシンのデフォルト名には、パターン vCLS-UUID が使用されます。以前の vCenter Server バージョンで作成された vCLS 仮想マシンは、パターン vCLS (n) を引き続き使用しています。括弧 () の使用は、vSphere と相互運用する多くのソリューションでサポートされていないため、互換性の問題が発生することがあります。
以前は、vCLS(1)などの連番だったのものが、vCLS-UUIDになっています。(n)の採番とかありえねーだろと思っていたのでまともな名前になってくれてうれしい限りです。
なお、Retreatモードの有効無効を行うと、vCLSが再作成される動きは変わっておらず、Retreatモードを使用するとUUIDは異なる番号になります。
配置するデータストアを選択できる
vCLSがデプロイされるデータストアは、自動的に選択されていましたが、ある程度ユーザー側で制御できるようになりました。
- vSphere クラスタ サービス (vCLS) の機能強化：vSphere 7.0 Update 3 では、vSphere 管理者は、vCLS 仮想マシンのデータストアの優先順位をクラスタごとに構成することで、vCLS 仮想マシンが特定のデータストアで実行されるように構成できます。管理者は、vSphere Distributed Resource Scheduler (DRS) による vCLS エージェント仮想マシン（vCLS 仮想マシン）とワークロード仮想マシンのその他のグループの配置方法を指定するコンピューティング ポリシーを定義することもできます。
検証環境では、下記のようなデータストア構成でした。仮想マシン用としては、「iSCSI-Datastore」「testds06」「testds07」が使用できます。
vCLSがデプロイされると、testds06にデプロイされました。空き容量が一番多いからなのか、他の仮想マシンが存在しないからなのか・・・真実はVMware社のみぞしる・・・・。
testds06は使ってほしくないなぁとなった時に、「クラスタ」->「構成」->「vSphereクラスタサービス」->「データストア」画面で設定できるようになりました。
追加から、vCLSの利用に許可するデータストアを選択して追加をクリックします。
vCLSが削除され、再度デプロイが始まります。
testds07にvCLSがデプロイされました。「iSCSI-Datastore」が使われなかったのは容量がすくなかったからなのか・・・真実はVMware社のみぞしる・・・・。
シビアな要件ないと使わなくていいかな・・・・。
vCLSの非アフィニティ設定ができる
vCLSと仮想マシンの間に非アフィニティ設定を行い、特定の仮想マシンをvCLSとは異なるホストで稼働させることができるようになりました。
- vSphere クラスタ サービス (vCLS) の機能強化：vSphere 7.0 Update 3 では、vSphere 管理者は、vCLS 仮想マシンのデータストアの優先順位をクラスタごとに構成することで、vCLS 仮想マシンが特定のデータストアで実行されるように構成できます。管理者は、vSphere Distributed Resource Scheduler (DRS) による vCLS エージェント仮想マシン（vCLS 仮想マシン）とワークロード仮想マシンのその他のグループの配置方法を指定するコンピューティング ポリシーを定義することもできます。
vCLS 仮想マシン非アフィニティ ポリシーでは、vCLS 仮想マシンとアプリケーション仮想マシンを同じホストに配置することは推奨されません。このタイプのポリシーは、vCLS 仮想マシンと重要なワークロードを実行している仮想マシンを同じホスト上で実行しない場合に有用です。SAP HANA などの重要なワークロードを実行するためのいくつかのベスト プラクティスには、専用ホストが必要です。
まず、タグカテゴリとタグを作っておきます。
「ポリシーおよびプロファイル」->「コンピューティングポリシー」を開き追加をクリックいます。コンピューティングポリシーは、Update3で新しく追加された項目ですね。
ポリシータイプに「vSphereクラスタサービス(vCLS)仮想マシンとの非アフィニティ」を選択します。今のところこのポリシーしか存在していません。
後は、名前や作成したタグを指定して作成をクリックします。
コンピューティングポリシーが作成されました。
以下のようにvCLSと仮想マシンは各ホストに混在している状態です。esxi004だけvCLSが存在していません。
vCLSと同じホストで動いてい欲しくない仮想マシンに対して作成していたタグを設定します。
vCLSとの非アフィニティに関する警告がでてきます。割当をクリックします。
タグの設定ができました。
しばらくすると、DRSによりvCLSがvMotionされます。
vCLSがUbuntu01とは異なるホストへDRSで移動されました。
じゃあ他のUbuntuマシン全部にタグをつけたらどうなるかと思って試してみたとこｒ、vCLSがタグのついていない仮想マシンがいないホストに集約されました。非アフィニティルールがちゃんと聞いています。
コンピューティングポリシーを見ると、どの仮想マシンに設定されているのか一覧でわかります。
この機能もシビアな要件がないと使わなさそう・・・？普通に仮想マシンに対する非アフィニティの設定箇所が分散されてややこしいなというのが正直な感想・・・・。
まとめ
Update3では、vCLS以外にもいろんなアップデートかかってて・・・・というかvCenterバージョンアップしすぎだろ・・・。
vCLSも今後、他の機能を持つような噂もあるので追いかけるの大変そうだなぁ。