vSphere HAのアドミッションルールの設定についてまとめます。アドミッションルールはvSphere HAのうち何台かに障害が発生した時にリソースを確保できるか否かでエラーまたは警告を発生させる機能です。
この機能を有効活用するには、リソース予約やリソースプールが明確化可能であることを前提としていますので、この前提条件が理解できることを目的として記事をまとめます。
動作確認の構成
ルートリソースプール
以下の環境で動作確認をします。
| 設定値 | 設定項目 |
|---|---|
| ESXi台数 | 3台 |
| ルートリソースプール CPUリソース | 30.15GHz |
| ルートリソースプール メモリリソース | 34.67GB |
アドミッションルールで評価されるのは、物理的なCPUやメモリに収まるかではなく、CPUやメモリの予約ができるかどうかです。予約可能なリソースはルートリソースプールと呼ばれる非表示のリソースプールです。このリソースプールがどれくらい収容可能かを確認するには、「クラスタ名」「監視」「CPU / メモリ」の順に押下し、「予約キャパシティの合計」の値を確認します。
リソース予約
各仮想マシンに以下のリソース予約をします。
| 仮想マシン | CPU予約 | メモリ予約 |
|---|---|---|
| centos50 | 2048MHz | 4096MB |
| centos51 | 2048MHz | 4096MB |
| centos52 | 2048MHz | 4096MB |
| centos60 | 1024MHz | 6144MB |
| centos61 | 1024MHz | 6144MB |
| centos70 | 1024MHz | 3072MB |
| centos71 | 1024MHz | 3072MB |
リソースを予約するには、仮想マシンの右クリックメニューで「設定の編集」を選びます
メモリとCPUの予約に値を入力し、「OK」を押下します。
設定を一覧で確認したい場合は、「クラスタ名」「監視」「CPU / メモリ」の順に押下します。
アドミッションコントロールの設定
クラスタリソースの割合アドミッションコントロール (デフォルト設定)
まずはデフォルト設定のアドミッションコントロールを見てみましょう。アドミッションコントロールの設定を確認するには、「クラスタ名」「設定」「vSphere HAの可用性」「編集」の順に押下します。
「アドミッションコントロール」タブでアドミッションコントロールの設定が可能です。デフォルト設定は1台の障害を許容します。3台構成ならば33%を、4台構成ならば25%を、5台構成ならば20%を障害に備えてフェイルオーバーキャパシティとして予約します。デフォルト設定は以下の通りです。
フェイルオーバーリソースを自動計算させたいならば、「クラスタで許容するホスト障害」の台数のみを変更しましょう。もし二重障害を考慮するような要件ならば、「クラスタで許容するホスト障害」を2以上にします。もし、33%, 25%, 20%のような自動計算で不安があり、ある程度の余裕を見積もりたいならば、「計算されたフェイルオーバーキャパシティのオーバーライド」にチェックを入れ、数値を入れる事で手動計算にする事ができます。
以下はフェイルオーバーキャパシティを33%ではなく40%として設定する例です。
フェイルオーバーキャパシティを40%に設定する事は実践では滅多にみられません。これは仕様理解のために設定した値と認識ください。
「クラスタ名」「設定」「vSphere HAの可用性」の画面で、「アドミッションコントロール」タブを開くと設定確認が可能です。
それでは仮想マシンを起動してアドミッションコントロールによる制限がかかるかどうかを動作確認します。ルートリソースプールに割り当てられたメモリは34.67GBで、フェイルオーバーキャパシティとして割り当てられたのは40%で、使用可能なメモリは60%です。
予約可能なメモリは以下のように計算できます。
34.67 x 0.6 = 20.81
centos50, centos51, centos52, centos60を起動します。この時点で予約しなければならないメモリは18GBですので、正常に起動できます。
ここでさらにcentos61を起動しようとすると必要とする予約メモリは24GBになり、前述の計算の20.81GBを超過するため、アドミッションコントロールの機能によりエラーが返されます。
スロット ポリシー アドミッション コントロール
スロットポリシーアドミッションコントロールは、仮想マシンのリソース割当最大値を「スロット」と呼ばれる単位で管理し、スロット内に収まるかどうかを計算するコントロール方法です。
公式の正確な説明は「スロット ポリシー アドミッション コントロール」を参照ください
アドミッションコントロールの設定を編集するには、「クラスタ名」「設定」「vSphere HAの可用性」「編集」の順に押下します。
ホストのフェイルオーバーキャパシティの定義基準に「スロット ポリシー（パワーオン状態の仮想マシン）」を選びます。
「クラスタ名」「設定」「vSphere HAの可用性」の画面で、「アドミッションコントロール」タブを開くと設定確認が可能です。
検証シナリオ1 : 4G仮想マシンの起動
以下の仮想マシンを起動するシナリオを考えます。
| 仮想マシン | CPU予約 | メモリ予約 |
|---|---|---|
| centos50 | 2048MHz | 4096MB |
| centos51 | 2048MHz | 4096MB |
| centos52 | 2048MHz | 4096MB |
| centos70 | 1024MHz | 3072MB |
| centos71 | 1024MHz | 3072MB |
スロットポリシーは起動される仮想マシンの最大リソースを「スロット」という単位で定義します。CPUリソースのうち最も大きいのは2048GHz、メモリリソースのうち最も大きいのは4096MBです。ですので、2048GHZ, 4096GBを1スロットとして定義します。
さて、ESXi 3台の合計としてルートリソースプールに確保されているのは、30.15GHz, 34.67GBです。従って、ESXi 1台あたりに確保されるリソースは以下のようになります。
30.15GHz / 3 = 10.05GHz 34.67GHz / 3 = 11.55GHz
ESXi 1台のCPUとメモリのそれぞれのスロット数は以下のようになります。
10.05GHz / 2048MHz = 5 (端数切り捨て) 10.55GB / 4096MB = 2 (端数切り捨て)
ESXi 3台のうち1台までの障害を許容する設定ですので、起動できる仮想マシンは4スロットまでになります。これを図示すると以下のようになります。
centos50, centos51, centos52, centos70を起動します。この時点で4スロットを消費します。
ここでさらにcentos71を起動しようとすると必要とする4スロットを超過した5スロットになるので、アドミッションコントロールがエラーを返します。
検証シナリオ2 : 6G仮想マシンの起動
以下の仮想マシンを起動するシナリオを考えます。
| 仮想マシン | CPU予約 | メモリ予約 |
|---|---|---|
| centos50 | 2048MHz | 4096MB |
| centos60 | 1024MHz | 6144MB |
| centos61 | 1024MHz | 6144MB |
スロットポリシーは起動される仮想マシンの最大リソースを「スロット」という単位で定義します。CPUリソースのうち最も大きいのは2048GHz、メモリリソースのうち最も大きいのは6144MBです。ですので、2048GHZ, 6144GBを1スロットとして定義します。
さて、ESXi 3台の合計としてルートリソースプールに確保されているのは、30.15GHz, 34.67GBです。従って、ESXi 1台あたりに確保されるリソースは以下のようになります。
30.15GHz / 3 = 10.05GHz 34.67GHz / 3 = 11.55GHz
ESXi 1台のCPUとメモリのそれぞれのスロット数は以下のようになります。
10.05GHz / 2048MHz = 5 (端数切り捨て) 10.55GB / 6144MB = 1 (端数切り捨て)
ESXi 3台のうち1台までの障害を許容する設定ですので、起動できる仮想マシンは2スロットまでになります。これを図示すると以下のようになります。
centos50, centos60を起動します。この時点で2スロットを消費します。
ここでさらにcentos61を起動しようとすると必要とする2スロットを超過した3スロットになるので、アドミッションコントロールがエラーを返します。
専用フェイルオーバーホスト
ESXiホストのうち1台をフェイルオーバー専用として設定し、正常時は使わないようにする事もできます。この設定をするには、「クラスタ名」「設定」「vSphere HAの可用性」「編集」の順に押下します。
「ホストのフェイルオーバーキャパシティの定義基準」に「専用フェイルオーバーホスト」を選びます。その後、「追加」を押下します。
フェイルオーバーホストとして選ぶESXiにチェックを入れ、「OK」を押下します。
「OK」を押下します。
障害が発生しない限り、フェイルオーバーホストには仮想マシンが格納されません。設定後、しばらく待つと、フェイルオーバーホストに格納された仮想マシンがvMotionされて、他のESXiホストに移動します。
アドミッションコントロールの無効化
デフォルト設定ではESXiホストのうち1台はフェイルオーバーキャパシティとして予約しなければなりません。この挙動は縮退運転のような低予算プロジェクトでは、望まれない挙動です。もし、このような要件を求められた場合は、アドミッションコントロールを無効化する事もできます。アドミッションコントロールを無効化するには、「クラスタ名」「設定」「vSphere HAの可用性」「編集」の順に押下します。
ホストのフェイルオーバーキャパシティの定義基準に「無効」を選びます。
「クラスタ名」「設定」「vSphere HAの可用性」の画面で、「アドミッションコントロール」タブを開くと設定確認が可能です。
パフォーマンス低下のしきい値
パフォーマンス低下の閾値は、十分にリソースを予約できるかのvalidationではなく、使用リソースと予約リソースを比較した時に十分かどうかを警告する機能です。デフォルト設定では一切の警告が発生しないですが、予約リソースを超えるリソースを使用した場合に警告を発生するように設定変更する事もできます。
パフォーマンス低下の閾値を設定変更するには、「クラスタ名」「設定」「vSphere HAの可用性」「編集」の順に押下します。
仮想マシンで許容するパフォーマンスの低下を100%から0%に変更します。0%にした場合は使用リソースが予約リソースを超過した場合に警告が発せられます。
例えば、パフォーマンス低下の閾値を20%にした場合は、使用リソースが予約リソースを20%超過した場合に警告が発生します。
現在のCPUやメモリの使用量は「クラスタ名」「サマリ」の画面から確認すると良いでしょう。
適宜、メモリやCPUリソースを枯渇させ、警告が発生する事を確認します。メモリリソースを消費させる手法の１つとしてメモリディスクを作成する方法を紹介します。以下のようなコマンドでメモリディスクをマウントします。size=7Gとしている部分は消費させたいメモリの量に応じて適宜の変更をお願いします。
mkdir /var/tmp/ram sudo mount -t tmpfs -o size=7G /dev/shm /var/tmp/ram
ddコマンドでメモリ上に適当な大きさのファイルを作成します。以下の例はbs=1M count=7kとなっていますので、ブロックサイズ1MBを7000回書き込む処理になり、計7GBのファイルが作成されます。
dd if=/dev/zero of=/var/tmp/ram/zero bs=1M count=7k conv=fdatasync
availableが小さな値を示しており、確かにメモリが消費された事を確認します。
[root@centos51 ~]# free -m
total used free shared buff/cache available
Mem: 7970 147 456 7176 7366 417
Swap: 511 0 511
[root@centos51 ~]#
ある程度メモリを消費させ、しばらく待つと、「フェイルオーバーリソースを満たすことができません」との警告が発生します。
