リソース プールは、リソースを柔軟に管理するための論理上の抽象概念です。リソース プールは階層にグループ化することができ、使用可能な CPU リソースとメモリ リソースを階層状にパーティショニングするために使用できます。
各スタンドアロン ホストと各 DRS クラスタには、（非表示の） ルート リソース プールがあり、そのホストまたはクラスタのリソースがグループ分けされています。ホスト （またはクラスタ） のリソースとルート リソース プールのリソースは常に同じであるため、ルート リソース プールは表示されません。
ユーザーは、ルート リソース プールの子リソース プール、またはユーザーが作成した任意の子リソース プールの子リソース プールを作成できます。それぞれの子リソース プールは、親のリソースの一部を保持し、これによって、連続した小さな単位のコンピュータ機能を表す子リソース プールの階層構造が形成されます。
リソース プールには、子リソース プール、仮想マシン、またはその両方を格納できます。共有リソースの階層を形成できます。より上位にあるリソース プールを親リソース プールと呼びます。同じレベルにあるリソース プールと仮想マシンを兄弟と呼びます。クラスタ自体は、ルート リソース プールを表します。子リソース プールを作成しない場合は、ルート リソース プールだけが存在します。
次の例の RP-QA は、RP-QA-UI の親リソース プールです。RP- マーケティングと RP-QA は兄弟です。RP- マーケティングのすぐ下にある 3 台の仮想マシンも兄弟です。
各リソース プールに対し、予約、制限、シェア、予約拡張の可否を指定します。リソース プールのリソースは、その子リソース プールと仮想マシンからも使用できます。
リソース プールを使用する理由
リソース プールを使用すると、ホスト （またはクラスタ） のリソース管理を委任できます。 リソース プールを使用して、クラスタ内のすべてのリソースを区分化する場合にメリットがあります。ホストまたはクラスタの直接の子として、複数のリソース プールを作成し、構成できます。その後、リソース プールの管理をほかの個人または組織に委任できます。
リソース プールを使用すると、次のメリットを得られる場合があります。
- 柔軟な階層型編成： 必要に応じて、リソース プールを追加、削除、再編成し、リソース割り当てを変更します。
- プール間での分離とプール内での共有： 最上位レベルの管理者は、リソース プールを部門レベルの管理者が使用できるようにすることができます。1 つの部門のリソース プールの内部的な割り当ての変更が、ほかの無関係なリソース プールに不当な影響を及ぼすことはありません。
- アクセス コントロールと委任： 最上位レベルの管理者が、リソース プールを部門レベルの管理者が使用できるようにした場合、部門レベルの管理者は、現在の設定 （シェア、予約、制限） によってリソース プールに割り当てられるリソースの限度内で、すべての仮想マシンの作成と管理を実行できます。委任は、通常、権限の設定と結び付けて行われます。
- リソースとハードウェアとの分離： DRS が有効に設定されているクラスタを使用している場合、すべてのホストのリソースは、常にそのクラスタに割り当てられます。これは、リソースを提供する実際のホストと無関係に管理者がリソース管理を実行できることを意味します。たとえば 3 台の 2GB ホストを 2 台の 3GB ホストに置き換える場合、リソース割り当てを変更する必要はありません。
このように切り離して考えることで、管理者は個々のホストというより、コンピューティング能力全体に注意を払えるようになります。
- 多層サービスを実行する一連の仮想マシンの管理： リソース プール内で多層サービス用に仮想マシンをグループ化します。それぞれの仮想マシン上でリソースを設定する必要はありません。代わりに、それらの仮想マシンを含むリソース プール上で設定を変更することで、仮想マシンのセットに対するリソースの全体的な割り当てを制御できます。
たとえば、ホストにいくつかの仮想マシンがあるとします。マーケティング部門は 3 台の仮想マシンを使用し、QA 部門は 2 台の仮想マシンを使用します。QA 部門は、より多くの CPU とメモリを必要とするため、管理者は、グループごとに 1 つのリソース プールを作成します。QA 部門のユーザーは自動化されたテストを実行するため、管理者は QA 部門のプールの [CPU シェア] を [高] に設定し、マーケティング部門のプールを [標準] に設定します。CPU とメモリのリソースがより少ない 2 番目のリソース プールでも、マーケティング スタッフの負荷は軽いので十分です。QA 部門が割り当て分のすべてを使用していない場合、マーケティング部門はいつでも使用可能リソースを使用できます。
次の図の数値は、リソース プールに対する実際の割り当てを示しています。
リソース プールの作成
任意の ESXi ホスト、リソース プール、または DRS クラスタの子リソース プールを作成できます。
前提条件
vSphere Clientは、vCenter Server システムに接続されます。
手順
結果
例: リソース プールの作成
マーケティング部門と QA 部門の間で共有する必要がある、6GHz の CPU と 3GB のメモリを備えたホストがあると仮定します。また、リソースを均一に共有するのではなく、一方の部門 （QA） に高い優先順位を与えたいものとします。これは、各部門でリソース プールを作成し、[シェア] 属性を使用してリソース割り当ての優先順位を設定することで実現できます。
この例では、ESXi ホストを親リソースとするリソース プールの作成方法を説明します。
- [新規リソース プール] ダイアログ ボックスで、QA 部門のリソース プールの名前を入力します（例：RP-QA）。
- RP-QA の CPU リソースとメモリ リソースについて、[シェア] を [高] に指定します。
- 2 番目のリソース プールの RP- マーケティングを作成します。
CPU とメモリのシェアは、[標準] のままにします。
- [OK] をクリックします。
リソースの競合がある場合、RP-QA は 4GHz および 2GB のメモリを受け取り、RP- マーケティングは 2GHz および 1GB を受け取ります。競合がない場合は、どちらも前述の値を上回る割り当てを受け取ります。その後、これらのリソースはそれぞれのリソース プール内の仮想マシンで使用できます。
リソース プールの編集
リソース プールの作成後、CPU およびメモリのリソース設定を編集できます。
手順
- vSphere Clientで、リソース プールを参照して移動します。
- [アクション]ドロップダウン メニューから [リソース設定の編集] を選択します。
- （オプション） リソース プールの作成で説明されているように、選択したリソース プールの属性はすべて変更できます。
- スケーラブル シェアを有効にする場合は、チェックボックスを選択します。
注： シェアは親レベルでスケーリングされます。スケーラブル シェアを持つ親から作成されたすべての子孫リソース プールは、デフォルトでスケーラブル シェアを持ちます。
- [CPU] で、CPU リソースの設定を選択します。
- [メモリ] で、メモリ リソース設定を選択します。
- スケーラブル シェアを有効にする場合は、チェックボックスを選択します。
- [OK] をクリックして、変更内容を保存します。
リソース プールへの仮想マシンの追加
仮想マシンを作成する場合、作成プロセスの一環として、リソース プールの場所を指定できます。既存の仮想マシンをリソース プールに追加することもできます。
- 仮想マシンの予約と制限は変更されません。
- 仮想マシンのシェアが高、標準、または低の場合、シェア率は、新規リソース プールで使用されているシェア数の合計に合わせて調整されます。
- 仮想マシンにカスタム シェアが割り当てられている場合は、そのシェア値が維持されます。
注： シェアの割り当てはリソース プールに対して相対的なので、仮想マシンをリソース プールに移動する場合は、新規リソース プール内の相対的な値と仮想マシンのシェアが一致するように、仮想マシンのシェアを手動で変更しなければならない場合があります。合計シェアに対して非常に大きい （または非常に小さい） 割合が仮想マシンに割り当てられると、警告が表示されます。
- [監視] では、[リソース予約] タブに表示される、リソース プールの予約済みおよび未予約の CPU とメモリのリソースに関する情報は、仮想マシンに関連付けられた予約（ある場合）に合わせて変更されます。
注： 仮想マシンがパワーオフまたはサスペンド状態の場合、その仮想マシンを移動することはできますが、リソース プール全体で使用可能なリソース （予約済みおよび未予約の CPU とメモリなど） は変更されません。
手順
- vSphere Clientで、仮想マシンを参照して移動します。
- データセンター、フォルダ、クラスタ、リソース プール、またはホストを選択して、仮想マシンを検索します。
- [仮想マシン] タブをクリックします。
- 仮想マシンを右クリックして、[移行] を選択します。
- 仮想マシンは別のホストに移動できます。
- 仮想マシンのストレージは別のデータストアに移動できます。
- 仮想マシンを別のホストに移動し、そのストレージを別のデータストアに移動できます。
- 仮想マシンを配置するリソース プールを選択します。
- 選択内容を確認し、[終了] をクリックします。
結果
仮想マシンがパワーオン状態で、ターゲットのリソース プールに仮想マシンの予約を確保するだけの十分な CPU またはメモリがない場合、仮想マシンの移動はアドミッション コントロールによって許可されないため、失敗します。エラー ダイアログ ボックスには、使用可能なリソースと要求されたリソースが表示されるので、調整することで問題が解決されるかどうかを判断できます。
リソース プールからの仮想マシンの削除
仮想マシンを別のリソース プールへ移動するか、仮想マシンを削除することにより、仮想マシンをリソース プールから削除できます。
仮想マシンをリソース プールから削除すると、リソース プールに関連付けられたシェアの総数が減り、残りの各シェアが、より多くのリソースを表すようになります。たとえば、シェアを [標準] に設定した 3 台の仮想マシンを含み、6GHz を割り当てられたプールがあるとします。仮想マシンが CPU バインドであったとすると、各仮想マシンは、均等に 2GHz を割り当てられます。仮想マシンの 1 台を別のリソース プールに移動した場合、残りの 2 台の仮想マシンは、それぞれ均等に 3GHz を割り当てられます。
手順
- vSphere Clientで、リソース プールを参照して移動します。
- 次のいずれかの方法で、仮想マシンをリソース プールから削除します。
- 仮想マシンを右クリックし、[移動先...] を選択して、仮想マシンを別のリソース プールに移動します。
仮想マシンを移動する前に仮想マシンをパワーオフする必要はありません。
- 仮想マシンを右クリックし、[ディスクから削除] を選択します。
仮想マシンを完全に削除するには、事前に仮想マシンをパワーオフする必要があります。
- 仮想マシンを右クリックし、[移動先...] を選択して、仮想マシンを別のリソース プールに移動します。
リソース プールの削除
リソース プールをインベントリから削除できます。
手順
リソース プールのアドミッション コントロール
リソース プール内の仮想マシンをパワーオンする場合、または子リソース プールの作成を試みる場合、システムは追加のアドミッション コントロールを実行して、リソース プールの制限に違反しないことを確認します。
仮想マシンをパワーオンしたり、リソース プールを作成したりする前に、vSphere Clientの [リソース予約] タブを使用して、リソースが十分にあることを確認します。CPU とメモリの[使用可能な予約]値で、未予約のリソースが表示されます。
使用可能な CPU とメモリ リソースの計算法、およびアクションが実行されるかどうかは、[予約タイプ]によって決まります。
| 予約タイプ | 説明 |
|---|---|
| [固定] | 選択されたリソース プールに予約のないリソースが十分にあるかどうかをシステムが確認します。ある場合、アクションを実行できます。ない場合、メッセージが表示され、アクションを実行することはできません。 |
| [拡張可能] （デフォルト） |
システムは、選択されたリソース プールおよび直接の親のリソース プール内で使用可能なリソースを考慮します。親のリソース プールでも [拡張可能な予約] オプションが選択されている場合は、その親のリソース プールからリソースを借りることができます。[拡張可能な予約] オプションが選択されているかぎり、リソースの借用は、現在のリソース プールの先祖から繰り返し発生します。このオプションを選択しておくと、柔軟性が高まりますが、同時に保護が弱くなります。子リソース プールの所有者は、予想以上のリソースを予約することがあります。 |
事前構成された [予約] または [制限] の設定に違反することはできません。リソース プールを再構成するごとに、または仮想マシンをパワーオンするごとに、システムはすべてのパラメータを検証して、すべてのサービス レベルを保証できるようにします。
拡張可能な予約の例 1
この例では、拡張可能な予約を持つリソース プールの機能を示します。
管理者が、プール P を管理し、2 人の異なるユーザー （または 2 つの異なるグループ） 用に 2 つの子リソース プール S1 と S2 を定義するとします。
管理者は、予約を持つ仮想マシンをユーザーがパワーオンしたいことを知っていますが、各ユーザーがどれだけの量を予約する必要があるかは知りません。S1 と S2 の予約を拡張可能にすると、管理者は、プール P の共通の予約をより柔軟に共有および継承できます。
拡張可能な予約を使用しない場合、管理者は、特定の量を明示的に S1 と S2 に割り当てる必要があります。このような特定の割り当ては、特に深いリソース プール階層において柔軟性がなくなる場合があり、リソース プール階層での予約設定が複雑になる場合があります。
拡張可能な予約では、厳密な分離がなくなります。つまり、S1 は、P の予約をすべて使い始めることができ、S2 が直接使用できるメモリまたは CPU がなくなります。
拡張可能な予約の例 2
この例では、拡張可能な予約を持つリソース プールの機能を示します。
図に示すように、次のシナリオを想定しています。
- 親プールの RP-MOM に、6GHz の予約と、1GHz を予約する実行中の 1 台の仮想マシン VM-M1 があります。
- 2GHz の予約を持ち、[拡張可能な予約] が選択された子リソース プール RP-KID を作成します。
- それぞれ 2GHz の予約を持つ 2 台の仮想マシン VM-K1 と VM-K2 を子リソース プールに追加し、これらの仮想マシンのパワーオンを試みます。
- VM-K1 は、（2GHz を持つ） RP-KID からリソースを直接予約できます。
- VM-K2 が使用できるローカル リソースはないので、VM-K2 は親リソース プール RP-MOM からリソースを借ります。RP-MOM は、6GHz マイナス 1GHz （仮想マシンによる予約） マイナス 2GHz （RP-KID による予約） を持ち、3GHz が未予約として残ります。3GHz が使用可能なので、2GHz の仮想マシンをパワーオンすることができます。
図 3. 拡張可能なリソース プールを使用したアドミッション コントロール：正常にパワーオンされた場合
次に、VM-M1 と VM-M2 を使用した別のシナリオについて考えます。
- 予約の合計が 3GHz である、RP-MOM 内の 2 台の仮想マシンをパワーオンします。
- この場合でも、2GHz はローカルで使用可能なので、RP-KID 内の VM-K1 をパワーオンすることができます。
- VM-K2 をパワーオンするとき、RP-KID には未予約の CPU 容量がないため、親を確認します。RP-MOM には未予約で使用可能な容量が 1GHz しかありません （RP-MOM 用に 5GHz が使用済みで、ローカル仮想マシンが 3GHz を予約し、RP-KID が 2GHz を予約しています）。その結果、2GHz の予約が必要な VM-K2 をパワーオンできません。
図 4. 拡張可能なリソース プールを使用したアドミッション コントロール：正常にパワーオンされなかった場合
