vSphere HAのアドミッションコントールについてまとめてみる

どうも、Tです。

vSphere HAのアドミッションコントロールのリソースの使い方が、いつもあやふやになるのでちゃんとまとめてみることにしました。

環境

vSphere環境

vCenter Server 7.0.2 18356314
ESXi 7.0.2, 17867351

vCenterはリソース計算の邪魔にならないように、検証用のクラスタとは別クラスタに作成しています。

ESXiホストはNested ESXiとして仮想マシンとして構築しています。検証のクラスタ「Cluster-EVC」CPU・メモリリソースは、下記のようになっています。

ホスト名	CPU周波数	CPUコア数（物理）	メモリ容量
testesxi001	1.8GHz	4	12GB
testesxi002	1.8GHz	4	12GB
testesxi003	1.8GHz	4	12GB
Cluster-EVCクラスタのリソース合計	1.8GHz×12コア=21.6GHz		36GB

DRSは、完全自動化で設定しています。

テスト用仮想マシン

Gest OS：Ubuntu 20.04.1 LTS

下記のvCPUとメモリを割り当てています。

ホスト名	CPUコア	メモリ	備考
ubuntu01	2vCPU	8GB
ubuntu02	2vCPU	8GB
ubuntu03	2vCPU	8GB
ubuntu04	2vCPU	8GB
ubuntu05	2vCPU	8GB

アドミッションコントロールとは

アドミッションコントロールの内容について一旦まとめてみます。下記のドキュメントから色々引用しています。

アドミッションコントロールの役割

アドミッションコントロールは、vSphere HA設定の1つになります。ホスト障害でHAが発生した際に、HAされた仮想マシンが起動できるように事前にリソースを確保する役割があります。アドミッション(入会？別ホストでの起動許可）をコントロールするという意味です。

アドミッションコントロールでリソースを確保した以上のリソースを使われようとした場合に、仮想マシンの下記のアクションを制限します。

仮想マシンのパワーオン
仮想マシンの移行
仮想マシンの CPU またはメモリ予約の増加

また、アドミッションコントロールの対象となるリソースは、CPUとメモリだけです。ネットワークやストレージのリソースに対する制御は行われません。

方式は3種類

アドミッションコントロールの設定は、「クラスタ」->「設定」->「vSphereの可用性」->「編集」から行えます。

アドミッションコントロールタブの「ホストのフェイルオーバーキャパシティの定義基準」のリストで設定を選択します。

アドミッションコントロールでリソースを確保する方式として、下記の3種類があります。

クラスタリソースの割合
スロットポリシー
専用フェイルオーバーホスト

4つ目の設定の「無効」は、アドミッションコントロールを行わない意味なので今回は考えません。本記事では3種類の設定について、どのようにリソース確保されるかを確認します。

考慮される仮想マシンリソースは予約済みCPU・メモリ

アドミッションコントロールでは、リソースを確保するために各仮想マシンのリソースを評価します。この評価の対象となるのは、仮想マシンに設定したCPU・メモリの予約値です。

仮想マシンに割り当てた、vCPU・メモリや実際に消費しているリソースは評価対象ではないことに注意が必要です。

役割によって評価方法が異なるので、後述で補足します。

考慮されるvSphereのリソースはルートリソースプールのCPU・メモリ

アドミッションコントロールで、リソース確保のためにvSphere HAが設定されているクラスタ全体のリソースも評価しなければなりません。

クラスタ全体のリソースの評価対象となるのは、物理リソースの合計ではなくルートリソースプールであることに注意が必要です。ルートリソースプールは、各ホストの物理リソースからESXiとして稼働するために必要となるリソースを減算し仮想マシンを稼働するための(仮想マシンの予約値として使用できる）リソースとなります。この計算は、vSphere内で自動的に計算されるため、ルートリソースプールの値を手動で変更することはできません。

クラスタのリソース状況として、サマリ画面でCPUとメモリのキャパシティが表示されますが、この表示はクラスタに参加してメンテナンスモードではないホストの物理リソースの合計値になります。こちらは、アドミッションコントロールの評価対象ではありません。

アドミッションコントロールのクラスタのCPUリソースの評価対象のルートリソースプールのCPUリソースは、「クラスタ」->「監視」->「リソース割り当て」->「CPU」->「予約キャパシティの合計」で確認ができます。

クラスタ合計キャパシティは、クラスタのサマリタブに表示されている物理リソースの合計です。

アドミッションコントロールのクラスタのメモリリソースの評価対象のルートリソースプールのメモリリソースは、「クラスタ」->「監視」->「リソース割り当て」->「メモリ」->「予約キャパシティの合計」で確認ができます。

クラスタ合計キャパシティは、クラスタのサマリタブに表示されている物理リソースの合計です。

ここまでの情報をまとめると下記のようになります。CPUの合計は正確には21.6GHzになりますが、表示されている21.55GHzを正として扱います。

項目	CPU	メモリ
クラスタ合計キャパシティ	21.55GHz	36GB
予約キャパシティの合計	15.9GHz	22.92GB
差分	5.65GHz	13.08GB

アドミッションコントロールで、評価されるのは予約キャパシティの合計(仮想マシンの予約に割当できる値)です。差分の値は、ESXiホストが稼働するために必要と判断したシステムリソースです。

この差分は、vSphere内で自動計算されているため今回の検証環境では、ホスト1台あたり下記のシステムリソースが必要と判断されたようです。

5.65GHz / 3ホスト = 1.88GHz
13.08GB / 3ホスト = 4.36GB

このシステムリソースは、同じ環境でもESXiホストの再起動や稼働マシンの稼働状況で1GB前後(メモリ搭載容量では数GB以上）程度変化しました。また、搭載ハードウェアの容量、NSX、vSAN、サードパーティのVIB導入状況により変わってくるのでどの程度のルートリソースプールがあるのかは実機を確認するのが確実だと考えています。

今回も検証で画面ショットに多少の変動がありますが、大まかに計算しているので無視していただければばと思います。

クラスタリソースの割合

アドミッショコントロール設定

まずクラスタリソースの割合から確認していきます。「クラスタリソースの割合(%)」を選択し後はデフォルト状態です。デフォルトではクラスタで許容するホスト障害「1」で設定します。

アドミッションコントロールとみるとCPUとメモリのキャパシティ（フェイルオーバー時に確保するリソース）として33%が自動で指定されています。これはホスト3台のうち障害の許容を1台にしているため100% / 3ホスト = 33%になっています。

クラスタのサマリ画面でも確認が行えます。

リソース確保のされ方

この時点のリソースの状況は、下記のようになっています。

クラスタのサマリで置き換えると下記のような状況です。

この後は、仮想マシンのリソース予約が67%までは、パワーオンなどの操作には制限がかからなくなります。仮想マシンに予約をしていない場合は、CPU予約は32MHz、メモリ予約は0MBとして扱われます。

vSphere HA では、仮想マシンの実際の予約が使用されます。仮想マシンに予約がない、つまり予約が 0 の場合は、デフォルトの 0MB のメモリおよび 32MHz の CPU が適用されます。

なお、メモリ予約は0MBとして扱われますが、仮想マシンを動かすためのメモリオーバーヘッド(十数MB～数百MB）は評価対象となります。

パワーオン状態の各仮想マシンのメモリ予約（およびメモリオーバーヘッド）を合計することによる、メモリコンポーネントの値。

「クラスタ」->「監視」->「vSphere HA」->「サマリ」->「詳細ランタイム情報」でキャパシティの計算結果が簡易的に見えるのですが、33%がルートリソースプールではなく、物理リソースから計算されているため誤差が生じています。検証結果からも、本記事の計算方式が正しく、こちらに表示される計算結果は誤りと思われます。

仮想マシンの予約状況

仮想マシン	CPU予約	メモリ予約	備考
ubuntu01	0GHz	4096MB
ubuntu02	0GHz	4096MB
ubuntu03	0GHz	4096MB
ubuntu04	0GHz	4096MB
ubuntu05	0GHz	０MB	予約なし

アドミッションコントロールが有効に効いているか確認するために上記のような予約を割り当てました。メモリの予約だけで確認を行います。

起動確認

想定する動作

ubuntu01から順番に起動していくと仮想マシンとして利用できる15.3GBの仮想マシン(ubuntu04)を起動するときに制限がかかるはずです。

Ubuntu01起動(メモリ予約4GB)

Ubuntu01を起動しました。ここで使用済みの予約が11.63GBまで跳ね上がりました。

これは、クラスタ内の1台目の仮想マシンが起動するタイミングで、仮想マシンのメモリ予約（4GB）とクラスタキャパシティの33%(7.56GB)の両方が使用済みの予約としてカウントされるためかと思われます。

Ubuntu02起動(メモリ予約4GB)

Ubuntu02も正常に起動しました。メモリ予約の4GB分が使用済み予約に追加されました。

Ubuntu03起動(メモリ予約4GB)

Ubuntu03を起動しました。メモリ予約の4GB分が使用済み予約に追加されました。この時点で使用可能な予約は3.06GBになっているので、メモリ予約が3.06GB以上(正確には、メモリオーバーヘッドも含む）稼働マシンは起動できないはずです。

Ubuntu04起動(メモリ予約4GB)

Ubuntu04を起動すると「vSphere HAの設定済みフェイルオーバーレベルに十分なリソースがありません。」が表示され起動することはできません。

Ubuntu05起動(メモリ予約0MB)

Ubuntu05はメモリ予約がないため、起動が行えます。

使用可能な予約が数十MBのようなパターンでは、メモリ予約が0MBでも仮想マシンを起動するためのオーバーヘッドメモリが必要なため、Ubuntu04のように起動が制限されます。

予約は超えないが、実使用量が超えた場合

念のため仮想マシン全体でメモリ予約量は超えていないが、メモリの実使用量が超えている場合も確認してみました。

Ubuntu01,02を起動してStressコマンドで搭載メモリ8GBをすべて使いきってみます。

Ubunut01,02で計16GBのメモリを消費しています。

実消費量はアドミッションコントロールの評価対象とはならないため、メモリ予約4GBを設定しているUbuntu03を起動することができます。

予約が超えなければ、パワーオンなどの制限はかかりませんがクラスタで「実行中の仮想マシンの使用率では、設定されている<クラスタ名>のフェイルオーバーリソースを満たすことができません」との警告が表示されます。