リソース予約 (CPU シェア数) (Solaris Container Manager 1.1 インストールと管理)

Solaris Container Manager 1.1 インストールと管理

リソース予約 (CPU シェア数)

プロジェクトを使用してアプリケーションのリソース管理を開始する前に、アプリケーションのリソースの傾向を把握する必要があります。ORACLE® など、特定のアプリケーションは、メモリーキャップの容量が不足すると、パフォーマンスが低下します。すべてのプロジェクトで、最小 CPU シェア数と、必要な場合は最大メモリー予約容量 (メモリーキャップ) のリソース予約を設定する必要があります。プロジェクトを使用してこれらの予約の管理を開始する前に、アプリケーションに必要なリソースを把握する必要があります。

注意 –

アプリケーションが通常使用するよりも少ない物理メモリーキャップをプロジェクトに設定しないでください。物理メモリーキャップが少ない場合、アプリケーションで仮想メモリーを使用する必要があるので、ページングとスワッピングが多くなり、アプリケーションのパフォーマンスが低下し、大幅な遅延が発生する可能性があります。

プロジェクトを使用してシステムリソースの管理を開始する前に、サーバー統合計画が仕上がっている必要があります。また、統合計画に含めるアプリケーションのリソース消費傾向を把握することも重要です。計画を本稼働環境に実装するまえに、テスト環境でアプリケーションのリソース消費傾向を 1 か月以上、観察することが理想的です。CPU とメモリーの消費傾向を把握したら、通常の必要なメモリーに数パーセントポイントを上乗せします。

プロジェクトに必要な CPU シェア数を予約するときは、CPU 数を整数で割り当てます。たとえば、25、1、および 37 は有効な値です。「シェア」とは、システムの CPU リソースのうち、プロジェクトに割り当てる分です。プロジェクトに割り当てる CPU シェア数を他のプロジェクトよりも多くすると、そのプロジェクトが公平配分スケジューラから受け取る CPU リソースも多くなります。

CPU シェアは、CPU リソースの比率ではありません。シェアは、他の作業負荷との比較に基づいた作業負荷の相対的な重要性を定義します。たとえば、営業プロジェクトが、マーケティングプロジェクトの 2 倍重要である場合は、営業プロジェクトに、マーケティングプロジェクトの 2 倍のシェア数を割り当てます。割り当てるシェア数は重要ではありません。営業プロジェクトに 2 シェア、マーケティングプロジェクトに 1 シェア割り当てることは、営業プロジェクトに 18 シェア、マーケティングプロジェクトに 9 シェア割り当てることと同じです。どちらの場合も、営業プロジェクトに、マーケティングプロジェクトの 2 倍の CPU 数を使用する権利が与えられます。

CPU シェアは、次の 2 種類に分類できます。

CPU シェア
(Solaris 10 のみ) プロジェクトの CPU シェア (特定のゾーン)

プールまたはプロジェクトの作成時の CPU シェア数の割り当て

Solaris 8 OS のホストでは、リソースプール pool_default だけが使用可能です。pool_default の CPU シェア数は 100 です。

Solaris 9 と Solaris 10 OS のホストでは、新規リソースプールを作成すると、プールの CPU シェア数が設定されます。Solaris Container Manager でデフォルト値が入力されますが、任意の整数を入力できます。たとえば、リソースプールに使用可能な CPU 当たり 100 CPU シェアという公式を使用できます。この場合、1 CPU のプールには、100 CPU シェアを割り当てます。

このプールに、Project X、Project Y、および Project Z の 3 つのプロジェクトがあるとします。もっとも重要なプロジェクト Project X に 50 CPU シェア、次のプロジェクト Project Y に 10 シェア、そして次のプロジェクト Project Z に 40 シェア割り当てます。

図 3–8 プロジェクトの CPU シェア数

新規プロジェクトウィザードを使用してプロジェクトを作成するときに、プロジェクトに CPU シェア数を割り当てます。新規プロジェクトウィザードでは、プールの予約されていない CPU シェア数が表示されるので、使用可能な CPU シェア数がわかり、適切な数をプロジェクトに割り当てることができます。

図 3–9 CPU シェア数

(Solaris 10 のみ) ゾーン作成時の CPU シェア数の割り当て

ホストで Solaris 10 オペレーティングシステムを使用している場合は、ゾーンを作成し、ゾーン全体に CPU 数を割り当て、ゾーン内のプロジェクトにプロジェクトの CPU シェア数を割り当てることができます。これらのシェアは似ています。

CPU シェア数とプロジェクトの CPU シェア数は、新規ゾーンウィザードを使用してゾーンを作成するときに割り当てます。新規ゾーンウィザードの手順 4 で、リソースプールを選択します。すると、プールの総 CPU シェア数と使用可能な CPU シェアの総数が表示されます。

リソースプールからこのゾーンに割り当てる CPU シェア数を入力します。この整数は、プールの使用可能な CPU シェアの総数以下である必要があります。

図 3–10 ゾーンのシェア数

プールの使用可能な CPU シェアの総数が 100 の場合、100 シェアのすべてまたは一部をこのゾーンに割り当てることができます。この例では、20 CPU シェアをリソースプールからゾーンに割り当てています。

ゾーン作成時のプロジェクトの CPU シェア数の割り当て

新規ゾーンウィザードの手順 4 で、プロジェクトの CPU シェア数を入力できます。このフィールドでは、ゾーン内のプロジェクトに割り当てる CPU シェア数を指定します。この値を作成すると、ゾーンのプロジェクトの CPU シェア数が設定されます。整数を入力できます。入力する整数によって、精度が決まります。

たとえば、ゾーン A のプロジェクトの CPU シェア数を 1000 にするとします。物理レベルでは、プロジェクトの CPU シェア数 1000 は、リソースプールから継承された 20 CPU シェアを 1000 シェアに分割したものです。プロジェクトの CPU シェア数 1 つと CPU 数の関係を示す公式を次に示します。

プロジェクトの CPU シェア数 1 = 20 (ゾーンに割り当てられている CPU シェア数)/1000 (プロジェクトの CPU シェア数) = 0.02 CPU シェア

ゾーン A にプロジェクト 1 を作成すると、プロジェクト 1 では、リソースプールから直接ではなく、ゾーンからシェアが取得されます。ゾーン A でプロジェクト 1 に 300 シェアを割り当てた場合、プロジェクトの CPU シェア 300 個 (300/1000 x 20/100 = 0.06 CPU シェア) が割り当てられます。

図 3–11 ゾーンの CPU シェア数

プロジェクトの CPU シェア数は、新規プロジェクトウィザードを起動したときにプロジェクトに割り当てます。新規プロジェクトウィザードの手順 7「プロジェクトに対するリソース予約を指定します」で、「CPU 予約数 (CPU シェア数)」フィールドにプロジェクトの CPU シェア数を入力します。この操作は、Solaris 10 のホストでプロジェクトを作成する場合にのみ可能です。

図 3–12 プロジェクトの CPU シェア数

注 –

Solaris 8 または Solaris 9 のホストにプロジェクトを作成するときは、「予約されていない CPU シェア数」フィールドに CPU シェア数 (プロジェクトの CPU シェア数ではない) を入力します。

注意 –

コマンド行で zonecfg コマンドを使用して CPU シェア数を手動で変更しないでください。手動で変更すると、Solaris Container Manager の計算が妨害されます。

大域ゾーンとそのプロジェクト

大域ゾーンは、1 つのリソースプールにバインドされていない唯一のゾーンです。大域ゾーンは、任意のプールから CPU リソースを取得できます。ホスト上のすべてのリソースプールには隠れた大域ゾーンがあるので、大域ゾーン内のプロジェクトは、ホストのすべてのリソースプールから CPU リソースを取得できます。

たとえば、リソースプール Pool_default には CPU が 4 つあり、zone_1 と zone_2 が配備されているとします。Pool_default の CPU シェア数は 10 です。zone_1 の CPU シェア数は 5、zone_2 の CPU シェア数は 4、大域ゾーンの CPU シェア数は 1 です。

別のリソースプール Pool_1 には CPU が 2つ、CPU シェアが 10 個あります。Pool_1 には、ゾーン zone_3 だけが配備されています。zone_3 の CPU シェア数は 9 です。大域ゾーンの CPU シェア数は 1 です。

大域ゾーン内のプロジェクトでは、配備されているプールの 1 CPU シェアから CPU リソースが取得されます。

Solaris Container Manager では、大域ゾーン内のプロジェクトは pool_default に配備する必要があります。

公平配分スケジューラ (FSS)

Container Manager では、公平配分スケジューラ (FSS) を使用して、設定した最小 CPU シェア数が確保されます。公平配分スケジューラは、デフォルトのスケジューラです。公平配分スケジューラでは、プロジェクトのシェア数を、有効なプロジェクトのシェアの総数で割って、プロジェクトに割り当てる CPU の割合が計算されます。有効なプロジェクトは、CPU を使用するプロセスが 1 つ以上あるプロジェクトです。アイドル状態のプロジェクト (有効なプロセスがないプロジェクト) のシェア数は、計算に入れられません。

たとえば、営業、マーケティング、およびデータベースの 3 つのプロジェクトにそれぞれ 2 つ、1 つ、および 4 つのシェアが割り当てられるとします。すべてのプロジェクトが有効です。リソースプールの CPU リソースは、営業プロジェクトに 2/7、マーケティングプロジェクトに 1/7、データベースプロジェクトに 4/7 が配分されます。営業プロジェクトがアイドル状態の場合は、マーケティングプロジェクトに 1/5、データベースプロジェクトに 4/5 が配分されます。

公平配分スケジューラでは、CPU の競合がある場合にのみ CPU の使用が制限されます。システムで唯一有効なプロジェクトであるプロジェクトは、シェア数にかかわらず、CPU を 100 パーセント使用できます。CPU サイクルは無駄になりません。あるプロジェクトにおいて、実行する処理がなく、使用する権利があるすべての CPU が使用されていない場合、残りの CPU リソースはほかの有効なプロセスの間で配分されます。プロジェクトの CPU シェア数が定義されていない場合は、1 つのシェアが割り当てられます。シェアが 0 個のプロジェクト内のプロセスは、実行の優先順位が最低になります。このようなプロセスが実行されるのは、シェア数がゼロ以外のプロジェクトが CPU リソースを使用していないときだけです。

タイムシェアスケジューラ (TS)

タイムシェアスケジューラでは、優先順位に基づいて CPU 時間が割り当てられ、使用可能な CPU がすべてのプロセスに比較的均等に配分されます。TS は管理の必要がないので、簡単に使用できます。ただし、TS では、特定のアプリケーションのパフォーマンスは保証されません。TS は、CPU の割り当てが必要ない場合に使用します。

たとえば、2 つのプロジェクトが FSS リソースプールに割り当てられ、それぞれに 2 つのシェアがある場合、これらのプロジェクト内で実行されているプロセス数は重要ではありません。1 つのプロジェクトは、使用可能な CPU の 50 パーセントだけを使用できます。したがって、1 つのプロセスが営業プロジェクト内で実行されていて、99 個のプロセスがマーケティングプロジェクト内で実行されている場合、営業プロジェクト内の 1 つのプロセスが CPU の 50 パーセントを使用できます。マーケティングプロジェクト内の 99 個のプロセスは、使用可能な CPU リソースの 50 パーセントを共有する必要があります。

TS のリソースプールでは、CPU がプロセスごとに割り当てられます。営業プロジェクトの 1 つのプロセスは、CPU の 1 パーセントだけを使用でき、マーケティングプロジェクトの 99 個のプロセスが、使用可能な CPU リソースの 99 パーセントを使用できます。

公平配分スケジューラとタイムシェアスケジューラについては、『Solaris のシステム管理 (ネットワークサービス)』を参照してください。

Container Manager の使用によるアプリケーションのリソース消費の管理

次の手順で、テスト環境で Container Manager をツールとして使用して、アプリケーションのリソース消費の傾向を把握できます。

Container Manager ソフトウェアと必要なソフトウェアをインストールおよびセットアップします。

詳細は、第 2 章「Container Manager のインストールと設定」を参照してください。
監視するすべてのエージェントマシンに Performance Reporting Manager をインストールします。

詳細は、第 2 章「Container Manager のインストールと設定」および『Sun Management Center 3.5 Performance Reporting Manager ユーザーガイド』を参照してください。
傾向を把握するアプリケーション用に、有効なアプリケーションベースのコンテナを作成します。新規プロジェクトウィザードで、最小 CPU 予約数だけを設定します。メモリーキャップは設定しません。

詳細は、「アプリケーションベースのプロジェクトの作成」および「アプリケーションベースのプロジェクトを作成する」を参照してください。
日別、週別、またはリアルタイムのグラフで、使用されているリソースを数週間、監視します。1 つのホストで実行中のコンテナの CPU とメモリーリソースの 2 つのグラフを確認できます。また、「プロセス」表でアプリケーション内で実行中のプロセスを監視することもできます。

詳細は、「有効なプロジェクトのリソース使用状況レポートを要求する」および「プロジェクトのプロセスの表示」を参照してください。
アプリケーションに必要な物理メモリーの最大容量を把握したら、コンテナのプロパティを変更してメモリーキャップを設定します。メモリーキャップは、アプリケーションで使用される最大メモリー容量以上にします。

詳細は、「プロパティシートを使用してプロジェクトを変更する」を参照してください。
使用メモリーが、設定したメモリーキャップを超え始めたときに通知を受け取るようにアラームを設定します。必要な場合は、プロパティシートでメモリーキャップを調整します。

詳細は、「アラームのしきい値を設定する」および「プロパティシートを使用してプロジェクトを変更する」を参照してください。

Container Manager を使用してリソース使用状況の傾向を把握したら、コンテナを使用して本稼働環境でサーバーを統合できます。

サーバーの統合の計画および実行については、David Hornby、Ken Pepple 共著『Consolidation in the Data Center』(Sun Blueprints) を参照してください。ORACLE データベースを使用しているシステムのサーバー統合については、Sun のホワイトペーパー『Consolidating Oracle RDBMS Instances Using Solaris Resource Manager Software』を参照してください。