test

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

第 3 章 コンテナの概要と製品の起動

この章では、コンテナとプロジェクトについて、また製品の起動方法について説明します。

この章では、以下の内容について説明します。

コンテナ管理の概要

プロジェクトは、ホストに関連付けられているコンテナです。プロジェクトは、一連の物理システムリソースの構成と管理に使用します。プロジェクトは、全体的なサーバー統合計画を実行するときに役立ちます。プロジェクトには、次の機能があります。

ソフトウェアをインストールし、設定したら、すぐに使用できるデフォルトプロジェクトがいくつかあります。ウィザードに従って独自のプロジェクトを作成することもできます。すべてのプロジェクトはコンテナに関連付けられています。このコンテナは、新規プロジェクトの作成に繰り返し使用できます。プロジェクトには、次の利点があります。

GUI はブラウザに表示され、3 つの表示 (タブ) があります。ホストの観点からの表示、コンテナの観点からの表示、および未確認のアラームの表示です。 ホストの表示とコンテナの表示は、グループを作成し、グループに含める要素を選択することで、構成を変更できます。

また、ソフトウェアを使用し、コンテナ内で実行されているプロセスと使用されているリソースを簡単に確認できます。コンテナまたはホストごとのリソース使用状況を評価するのに役立つグラフのオプションもいくつかあります。データをファイルにエクスポートすることもできます。これらの機能を使用すると、リソース消費を監視および再評価し、適切に調整できます。

ソフトウェアのアラーム機能を使用すると、コンテナのリソース消費が設定したしきい値に達したときに電子メールの通知を受け取ることができます。GUI では、ホストとコンテナにアラームのアイコンが表示されます。

リソース変更ジョブ機能を使用すると、1 回の要求で、1 つまたは複数のコンテナの現在のリソース境界を変更するスケジュールを 設定できます。リソース変更ジョブの作成または変更は、ウィザードに従って行うことができます。

コンテナのプロパティ

コンテナには、次のプロパティがあります。

コンテナに割り当てる名前は変更できません。プロジェクト名も同様です。コンテナのその他の識別情報は変更できます。

コンテナはソフトウェアによって保存され、コンテナが削除されるまで繰り返し使用できます。プロジェクトは、ホストに関連付けられているコンテナです。プロジェクトは、ホストに関連付け、リソース予約を設定したときに有効になります。

定義とリソース予約が同じ複数のプロジェクトを複数の異なるホストで同時に有効にできるので、コンテナを使用してデータセンター全体のプロジェクトを簡単に管理できます。コンテナを保存したら、そのコンテナを使用して、任意のホストでプロジェクトを有効にできます。つまり、コンテナは、新規プロジェクト作成用のテンプレートとして使用できます。

コンテナは、複数のプロジェクトのテンプレートとして機能します。コンテナでは、プロジェクトの共通のプロパティが 1 個所に保存されます。プロジェクトの共通のプロパティは、次のとおりです。

CPU シェアやメモリー制限などのその他のプロパティは、プロジェクトが有効になっているホストに固有です。Solaris Container Manager 1.1 では、この一連の共通のプロパティをコンテナといいます。コンテナが特定のホストで有効になると、Solaris プロジェクトとしてインスタンス化され、/etc/project に保存されます。

たとえば、電子メールアプリケーション用のコンテナを設定するとします。プロジェクトの共通のプロパティは、次のとおりです。

コンテナが特定のホストで有効になると、プロジェクトをインスタンス化し、リソースプール、CPU シェア数、およびメモリー制限を指定できるようになります。

図 3–1 コンテナとプロジェクト

コンテナは、複数のプロジェクトを作成するためのテンプレートとして機能

コンテナを使用して複数のゾーンやホストに複数のプロジェクトを作成できます。たとえば、単一のコンテナを使用して、3 つの異なるホストに 3 つの有効なプロジェクトを作成した場合、1 つのコンテナと、そのコンテナに 3 つのプロジェクトができます。コンテナの情報を変更すると、そのコンテナに基づいているすべてのプロジェクトが変更されます。

新規プロジェクトウィザードでは、すべての手順を完了したときに有効になるプロジェクトを作成できます。同時にコンテナが作成され、その名前が GUI に保存されます。コンテナだけを作成し、ウィザードに従ってプロジェクトを後で有効にすることもできます。

コンテナは、GUI を使用して次の操作を行うことができます。

プロジェクトは、GUI を使用して次の操作を行うことができます。

プロジェクトの状態

アプリケーションに設定したリソース消費の境界は、実際にはプロジェクトによって適用されるのではありません。最小 CPU 予約数とメモリーキャップを指定し、プロジェクトが有効になったら、Solaris カーネルによってこれらの境界が適用されます。プロジェクトを使用する前に、プロジェクトの状態を理解する必要があります。プロジェクトには、定義済み、有効、および無効の 3 つの状態があります。

図 3–2 プロジェクトの状態

プロジェクトの状態を示す図。周りのテキストがコンテキストを表します。

プロジェクトは、その存続期間中、これらの状態の間を行き来します。

コンテナとプロジェクト

コンテナは、プロジェクト自体がまだ発生していない初期の段階で作成します。各プロジェクトには固有の名前が必要で、各プロジェクトは無限にデータベースに保存できます。

図 3–2 に、コンテナがホストに関連付けられた後でプロジェクトが有効な状態になるところを示しています。プロジェクトは、無効にし、ホストとの関連付けを解除したら、定義済みの状態に戻すことができます。

プロジェクトの有効化

プロジェクトを有効にするには、まずコンテナをホストに関連付けます。次に、プロジェクトの最小 CPU 予約数とメモリーキャップを割り当ててリソース境界を設定します。プロジェクトは、これらのリソース境界をサポートするホストに関連付ける必要があります。有効なプロジェクトとは、外に出されてホスト上に常駐しているという点から、配備済みとも言えます。

新規プロジェクトウィザードでアプリケーションベースのプロジェクトを作成するときは、アプリケーションに関連するプロジェクトを特定する一致式を指定できます。一致式と一致するプロセスがすべてこのコンテナの下に移動されます。プロジェクトを有効にすると、コンテナが関連付けられているホストで、/etc/project データベースにエントリが作成されます。これに対して、一致するプロセスがコンテナのプロジェクト名の下に移動します。プロセスが移動したら、プロジェクトのすべてのリソース使用状況データが収集され、保存されます。

プロジェクトの無効化

プロジェクトを無効にすると、リソース境界が適用されなくなります。無効にしたプロジェクトは無効な状態になり、ホストの /etc/project ファイルから削除されます。無効なプロジェクトはソフトウェアのデータベースに残っているので、再度有効にできます。無効なプロジェクトを再び有効にすると、コンテナのリソース境界が再び適用されます。

プロジェクトが有効であった間に収集された使用状況データは、すべてデータベースに保存されます。プロジェクトを無効にしてから 30 日以内は、そのプロジェクトの使用状況レポートを要求できます。

Container Manager の GUI

Container Manager ソフトウェアでは、Solaris ソフトウェアのリソース管理の標準のコマンド行コマンドは使用できません。コンテナは、Container Manager のグラフィカルユーザーインタフェース (GUI) を使用して管理する必要があります。GUI は、ブラウザを使用して Java Web Console から起動します。サポートされているブラウザは次のとおりです。

ProcedureContainer Manager の GUI を起動する

手順

  1. /var/opt/SUNWsymon/cfg/esusers ファイルに UNIX ユーザー ID がない場合は、エントリを作成します。

    ユーザーは、esadm または esdomadm のいずれかのグループに割り当てる必要があります。

    エントリの作成とグループへの割り当てについては、『Sun Management Center 3.5 Installation and Configuration Guide』の「Setting Up Users」を参照してください。

  2. ブラウザを起動します。

    サポートされているブラウザの一覧は、「Container Manager の GUI」を参照してください。

  3. 次のように入力して Container Manager の GUI を表示します。


    https://sunmc-server_machine_name:6789/containers

    Java Web Console のログインページが表示されます。

    図 3–3 Java Web Console のログインページ

    Java Web Console のログインページの 3 つのフィールド (サーバー名、ユーザー名、およびパスワード)。

    ログインページが表示されない場合は、Java Web Console を再起動する必要がある可能性があります。再起動の方法については、「Java Web Console を再起動する」を参照してください。

    ヒント –

    「コンソール」ページが表示されたら、「システム」セクションの下にある Solaris Container Manager 1.1 のリンクをクリックして GUI を表示します。

  4. UNIX ユーザー ID とパスワードを使用して Java Web Console にログインします。

    Container Manager の GUI が表示されます。画面には、「ホスト」、「コンテナ」、および「未確認のアラーム」の 3 つのタブがあります。

    図 3–4 Container Manager のメインページ

    Container Manager のメインページの 3 つのタブ (「ホスト」、「コンテナ」、および「未確認のアラーム」)。

ProcedureJava Web Console を再起動する

Java Web Console にアクセスできない場合は、このコマンドを使用して再起動します。

手順

    スーパーユーザー (su -) で、次のように入力して Java Web Console を再起動します。


    # /usr/sbin/smcwebserver restart

Container Manager の GUI のタブ

Container Manager の GUI の右側に表示されるタブの説明を次の表に示します。

表 3–1 Container Manager の GUI のタブ

タブ 

タブ名 

内容 

ホスト (表示) 

内容 

選択したホスト上のリソースプールに関する情報が表示されます。 
 

プロパティ 

選択したホスト、ゾーン、プロジェクト、またはリソースプールに関する情報が表示されます。 
 

使用状況 

ホスト、ゾーン、プロジェクト、またはプールの日別、週別、または月別のリソース使用状況に関する情報が表示されます。有効なプロジェクトについては、リアルタイムの使用状況データが表示されます。このタブは、Performance Reporting Manager ソフトウェアがインストールされている場合にのみ使用できます。 
 

プロジェクト 

ホストに関連付けられているプロジェクトに関する情報が表示されます。 
 

ゾーン 

ホストに関連付けられているゾーンに関する情報が表示されます。 

コンテナ (表示) 

内容、ホスト 

プロジェクトに関する情報が表示されます。 
 

プロパティ 

選択したホスト、コンテナ、プロジェクト、またはリソースプールに関する情報が表示されます。 
 

使用状況 

ホスト、ゾーン、プロジェクト、またはプールの日別、週別、または月別のリソース使用状況に関する情報が表示されます。有効なプロジェクトについては、リアルタイムの使用状況データが表示されます。このタブは、Performance Reporting Manager ソフトウェアがインストールされている場合にのみ使用できます。 
 

ジョブ (リソース変更ジョブ) 

予定されているリソース変更ジョブに関する情報が表示されます。このタブで新規リソース変更ジョブを作成することもできます。デフォルトコンテナにリソース変更ジョブを関連付けることはできません。 

未確認のアラーム 

 

重要度、メッセージ、管理対象オブジェクト、開始時刻、確認など、未確認のアラームに関する情報が表示されます。 

リソースプール (下の階層) 

内容 

選択したリソースプールのゾーンに関する情報が表示されます。 
 

プロパティ 

選択したリソースプールのプロパティに関する情報が表示されます。 
 

使用状況 

プールの日別、週別、または月別のリソース使用状況に関する情報が表示されます。このタブは、Performance Reporting Manager ソフトウェアがインストールされている場合にのみ使用できます。 
 

プロジェクト 

選択したリソースプールに関連付けられているプロジェクトに関する情報が表示されます。 

ゾーン (下の階層) 

内容 

選択したゾーンのプロジェクトに関する情報が表示されます。 
 

プロパティ 

選択したゾーンのプロパティに関する情報が表示されます。 
 

使用状況 

ゾーンの日別、週別、または月別のリソース使用状況に関する情報が表示されます。このタブは、Performance Reporting Manager ソフトウェアがインストールされている場合にのみ使用できます。 

プロジェクト (下の階層) 

プロパティ 

選択したプロジェクトのプロパティに関する情報が表示されます。 
 

使用状況 

プロジェクトの日別、週別、または月別のリソース使用状況に関する情報が表示されます。このタブは、Performance Reporting Manager ソフトウェアがインストールされている場合にのみ使用できます。 
 

プロセス 

選択したプロジェクトのプロセスに関する情報が表示されます。 
 

アラームしきい値 

アラームしきい値を設定または削除できます。 

ホスト表示

ホスト表示では、ホストの観点から情報が構成されます。管理しているエージェントマシンがすべてナビゲーションウィンドウに表示されます。ホスト名の横の三角形をクリックすると、各ホストで使用可能なリソースプールが表示されます。この表示では、ホストに関連付けられているコンテナを管理することもできます。

ソフトウェアがインストールされているエージェントのホストは、すべて自動的に検出され、ホスト表示に追加されます。この表示は、ナビゲーションウィンドウの左側のタブから表示します。検出されたエージェントのホストは、最初は「ホスト」というデフォルトのグループの下に配置されます。新規グループを作成し、関連するグループにホストを移動することで、このビューの構成を変更できます。

注 –

Sun Management Center のサーバーコンテキストに含まれ、かつ Solaris Container Manager 1.1 がインストールされているエージェントマシンだけがホスト表示に読み込まれます。サーバーコンテキストについては、『Sun Management Center 3.5 ユーザーガイド』の「Sun Management Center のアーキテクチャ」を参照してください。

ホスト表示のタブと情報を表 3–1 に示します。

ホストに関連付けられているプロジェクトインスタンスに関する情報は、「プロジェクト」表に表示されます。

デフォルトプールに関連付けられている「プロジェクト」表が表示されている「ホスト」表示を次の図に示します。

図 3–5 例: 「プロジェクト」表が表示された「ホスト」表示

「ホスト」ビューに表示された「プロジェクト」表のスクリーンキャプチャ。周りのテキストがコンテキストを表します。

「プロジェクト」表には、各プロジェクトに関する情報が表示されます。1 行に 1 つのプロジェクトが表示されます。表示される情報は、次のとおりです。

プロジェクト名

プロジェクトの名前

コンテナ名

コンテナの名前

状態

プロジェクトの状態 (有効または無効)

リソースプール名

プロジェクトがバインドされているリソースプール

ゾーン名

プロジェクトが常駐するゾーンの名前。Solaris 8 と Solaris 9 のホストでは、ゾーン名は常に「global」です。

CPU 予約数 (CPU シェア数)

プロジェクトの最小 CPU シェア数

CPU 使用量 (CPU 数)

プロジェクトで使用されている CPU 数

メモリーキャップ (M バイト)

メモリーの上限 (M バイト単位)

メモリー使用量 (M バイト)

プロジェクトで使用されているメモリー (M バイト単位)

共有メモリー (M バイト)

プロジェクト内で実行されるプロセスに使用できるメモリーの総容量 (M バイト単位)

「リソースプール」表には、各リソースプールに関する情報が表示されます。表示される情報は、次のとおりです。

リソースプール名

リソースプールの名前です。

現在の CPU 数

リソースプールに現在設定されている CPU 数

予約されていない CPU シェア数

リソースプール内で、ゾーンまたはプロジェクトに割り当てられていない CPU シェア数

スケジューラ

リソースプールに設定されているスケジューラ (タイムシェアスケジューラまたは公平配分スケジューラ)

CPU シェア数

リソースプールに設定されている CPU シェア数

最小 CPU 予約数

リソースプールに設定されている最小 CPU 数

最大 CPU 予約数

リソースプールに設定されている最大 CPU 数

「ゾーン」表には、各ゾーンに関する情報が表示されます。表示される情報は、次のとおりです。

ゾーン名

ゾーンの名前です。

ゾーンの状態

ゾーンの状態 (構成済み、不完全、インストール済み、準備完了、稼働、停止、またはダウン)

ゾーンのホスト名

仮想ホストとしてのゾーンの一意の名前

ゾーンのパス

ルート (/) ディレクトリを基準にした絶対パス

IP アドレス

ゾーンの IP アドレス

プロジェクトの CPU シェア数

ゾーン内のプロジェクトに割り当てられている CPU シェア数

予約されていない CPU シェア数

ゾーンに関連付けられているプロジェクトに割り当て可能な CPU シェア数

予約済み CPU シェア数

リソースプール内でこのゾーンに割り当てられている CPU シェア数

リソースプール

ゾーンのリソースプール

コンテナ表示

コンテナ表示では、コンテナの観点から情報が構成されます。コンテナとプロジェクトがすべてナビゲーションウィンドウに表示されます。コンテナは新規プロジェクトの作成に繰り返し使用できるので、このビューではコンテナに簡単にアクセスでき、またその他の管理作業を行うことができます。

インストールとセットアップが完了したら、コンテナ表示に「コンテナ」グループがデフォルトで自動的に追加されます。コンテナはコンテナ表示で管理します。

コンテナ表示を次の図に示します。

図 3–6 例: デフォルトコンテナに関連付けられているホストが表示された「コンテナ」表示

「コンテナ」表示のスクリーンキャプチャ。周りのテキストがコンテキストを表します。

コンテナ表示に表示される情報は表 3–1 にあります。

ホストとコンテナのグループ化

ホスト表示には、デフォルトのグループ「ホスト」があります。ソフトウェアのインストール後に検出されたホストはすべてこのグループに配置されます。同様に、コンテナ表示にはデフォルトのグループ「System」があり、ホストのデフォルトコンテナがすべてこのグループに配置されます。これらのビューでは、ホストやコンテナを構成する追加グループを作成できます。

グループを使用して、データセンター内の 10 個のシステムでも、100 個のシステムでも構成できます。たとえば、同じ場所にあるホストを 1 つのグループに入れることができます。また、同じ顧客 (内部または外部) または部署が所有するコンテナを 1 つのグループに入れることができます。同様に、似ているアプリケーションのコンテナを 1 つのグループに入れることができます。

Procedureコンテナグループまたはホストグループを作成する

手順

  1. Container Manager の GUI が開いていない場合は、「Container Manager の GUI を起動する」に従って起動します。

  2. ナビゲーションウィンドウでビューを選択します。

    • 新規コンテナグループを作成するには、コンテナ表示を選択します。右側の区画に「コンテナ」表が表示されます。

    • 新規ホストグループを作成するには、ホスト表示を選択します。右側の区画に「ホストとグループ」表が表示されます。

  3. 「新規グループ」ボタンをクリックします。

    ダイアログが表示されます。

  4. グループの名前を入力し、「了解」をクリックします。

    名前は 32 文字を超えてはいけません。

    新しいグループが選択したビューに表示されます。

Procedureコンテナまたはホストを別のグループに移動する

手順

  1. Container Manager の GUI が開いていない場合は、「Container Manager の GUI を起動する」に従って起動します。

  2. ナビゲーションウィンドウでビューを選択します。

    • コンテナを別のグループに移動するには、コンテナ表示を選択します。右側の区画に「コンテナ」表が表示されます。

    • ホストを別のグループに移動するには、ホスト表示を選択します。右側の区画に「ホストとグループ」表が表示されます。

  3. 表の「移動」ボタンを使用可能にするには、移動するコンテナまたはホストのチェックボックスを選択します。

  4. 右側の区画で、「移動」ボタンをクリックします。

    使用可能なグループがダイアログに表示されます。

  5. コンテナまたはホストを移動するグループを選択します。

  6. 「了解」をクリックします。

    コンテナまたはホストが、選択したグループに移動します。

デフォルトのコンテナ

ソフトウェアを設定したら、コンテナ表示に「System」というグループが読み込まれます。Solaris 9 または Solaris 10 オペレーティングシステム (OS) のホストでは、このグループに次の 5 つのデフォルトコンテナがあります。

各デフォルトコンテナは、/etc/project ファイル内に対応するエントリがあります。default、noproject、user.root、system、および group.staff です。

注 –

Solaris 8 のホストでは、Users with Group Staff (group.staff) のコンテナは存在しません。その他のデフォルトコンテナは同じです。

図 3–7 例: 「System」コンテナグループのコンテナの表示

「システム」コンテナグループの内容が表示された画面のスクリーンキャプチャ。周りのテキストがコンテキストを表します。

各デフォルトコンテナは有効な状態で、境界は最小 CPU 予約数 (CPU シェア数) 1 とメモリーキャップなしに設定されています。デフォルトコンテナは、必ずホストのデフォルトのリソースプール (pool_default ) にバインドされます。Performance Reporting Manager がインストールされている場合は、リソース使用状況を監視し、各デフォルトコンテナのレポートを実行できます。

デフォルトコンテナは、無効化、編集、または削除できません。したがって、各デフォルトコンテナには「読み取り専用」と表示されています。

すべての UNIX ユーザーはデフォルトプロジェクトに割り当てられ、その結果、デフォルトコンテナに割り当てられます。最初は、システムで実行されているすべてのプロセスがデフォルトコンテナに保持されます。プロジェクトを作成すると、プロセスは、対応するデフォルトコンテナから、作成したプロジェクトに移動されます。

コンテナの作成

プロジェクトはコンテナに基づきます。プロジェクトには 3 種類があります。種類は作成時に選択します。プロジェクトの種類によって、プロセスの追跡方法が決まります。

プロジェクトの種類

新規コンテナを作成するときは、プロジェクトの種類を選択する必要があります。プロジェクトは、ネットワーク全体で関連する作業を管理するための識別子 (ID) です。コンテナ内で実行されるプロセスはすべてプロジェクト ID が同じで、コンテナによってプロジェクト ID で使用されるリソースが追跡されます。コンテナの種類は、コンテナの作成時に選択します。

すべてのコンテナには、変更できないプロジェクト名があります。ホストでコンテナが有効になると、そのホストの /etc/project ファイルにこのプロジェクト名が追加されます。このエントリは、そのホストでコンテナが有効である間、維持されます。

1 つのホストで同じプロジェクト名のプロジェクトを同時に 2 つ有効にすることはできません。コンテナ内で実行されるプロセスはプロジェクト ID で追跡されるので、ホスト上のプロジェクト名はすべて固有である必要があります。

ユーザーベースまたはグループベースのプロジェクトを作成するとき、ユーザー名またはグループ名がプロジェクト名の一部に使用されます。ユーザーベースのコンテナの場合、プロジェクト名は user.username の書式で指定します。グループベースのコンテナの場合、プロジェクト名は group.groupname になります。したがって、ユーザーベースまたはグループベースのプロジェクトを作成するときは、/etc/project ファイルのデフォルトコンテナのエントリと重複するユーザー名またはグループ名を使用できません。詳細は、「デフォルトのコンテナ 」を参照してください。

アプリケーションベースのコンテナを作成するときは、任意のプロジェクト名を指定します。新規プロジェクトウィザードでは、異なるアプリケーションベースのプロジェクトに重複するプロジェクト名を指定できます。ただし、プロジェクト名が同じ 2 つのアプリケーションベースのプロジェクトを同じホストで同時に有効にすることはできません。コンテナを別のホストで有効にする場合にのみプロジェクト名を再利用してください。同じプロジェクト名のプロジェクトがあるホストでプロジェクトを有効にしようとすると、有効化に失敗します。

3 つのプロジェクトの種類の詳細と、選択したときの変更内容を次の表に示します。

表 3–2 プロジェクトの種類の詳細

プロジェクトの種類 

OS バージョン 

詳細 

ユーザーベース 

Solaris 8 

Solaris 8 でサポートされている唯一のプロジェクトの種類です。 

/etc/project ファイルのプロジェクト名は user.username になります。プロジェクトはユーザーの一次デフォルトプロジェクトになります。

 

Solaris 9 および Solaris 10 

/etc/project ファイルのプロジェクト名は user.username になり、このプロジェクトに後で加わることができる UNIX ユーザーの一覧が指定されます。

有効な書式は username です。

グループベース 

Solaris 9 および Solaris 10 

/etc/project ファイルのプロジェクト名は group.groupname になります。

有効な書式は groupname です。

アプリケーションベース 

Solaris 9 および Solaris 10 

プロジェクト名には、アプリケーション名またはその他の任意の名前を使用できます。指定した名前が /etc/project ファイルに追加されます。

一致式を指定して、一致するプロセスをプロジェクト名に自動的に移動できます。一致式では、大小文字が区別されます。 

プロセスの実行に使用される、対応する username または groupname を指定する必要があります。

リソース予約 (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 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 シェア数が表示されるので、使用可能な CPU シェア数がわかり、適切な数をプロジェクトに割り当てることができます。

図 3–9 CPU シェア数

プロジェクトへの CPU シェア数の割り当て

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

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

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

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

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

ゾーンへの CPU シェア数の割り当て

プールの使用可能な 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 シェア数

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

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

プロジェクトへのプロジェクトの 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 をツールとして使用して、アプリケーションのリソース消費の傾向を把握できます。

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

    詳細は、第 2 章「Container Manager のインストールと設定」を参照してください。

  2. 監視するすべてのエージェントマシンに Performance Reporting Manager をインストールします。

    詳細は、第 2 章「Container Manager のインストールと設定」および『Sun Management Center 3.5 Performance Reporting Manager ユーザーガイド』を参照してください。

  3. 傾向を把握するアプリケーション用に、有効なアプリケーションベースのコンテナを作成します。新規プロジェクトウィザードで、最小 CPU 予約数だけを設定します。メモリーキャップは設定しません。

    詳細は、「アプリケーションベースのプロジェクトの作成」および「アプリケーションベースのプロジェクトを作成する」を参照してください。

  4. 日別、週別、またはリアルタイムのグラフで、使用されているリソースを数週間、監視します。1 つのホストで実行中のコンテナの CPU とメモリーリソースの 2 つのグラフを確認できます。また、「プロセス」表でアプリケーション内で実行中のプロセスを監視することもできます。

    詳細は、「有効なプロジェクトのリソース使用状況レポートを要求する」および「プロジェクトのプロセスの表示」を参照してください。

  5. アプリケーションに必要な物理メモリーの最大容量を把握したら、コンテナのプロパティを変更してメモリーキャップを設定します。メモリーキャップは、アプリケーションで使用される最大メモリー容量以上にします。

    詳細は、「プロパティシートを使用してプロジェクトを変更する」を参照してください。

  6. 使用メモリーが、設定したメモリーキャップを超え始めたときに通知を受け取るようにアラームを設定します。必要な場合は、プロパティシートでメモリーキャップを調整します。

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

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

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