第 1 章 Solaris Container Manager 3.6.1 の紹介
この章では、Solaris Container Manager 3.6.1 (Container Manager) の概要を示します。
この章では、以下の内容について説明します。
Container Manager の概要
Solaris Container Manager 3.6 は、Sun Management Center 3.6.1 リリースのアドオン製品です。この製品を使用すると、サーバーを統合し、多数のサーバーとソフトウェアを使用するネットワークのコストを抑えることができます。Container Manager では、コンテナ、プロジェクト、リソースプール、およびゾーンを作成および管理できます。ハードウェアリソースの使用率が上がり、またサーバー数に対する管理者数を減らすことができるという利点があります。
この製品では、次の作業を行うことができます。
IP アドレス、ディスク記憶装置、およびアプリケーションを含めて、ユーザーが独自の仮想的環境を必要とするような組織にとって、コンテナは理想的です。たとえば、メールサーバー、Web サーバー、データベースなどの特定のアプリケーション用のコンテナを設定できます。また、米国、南北アメリカ、ヨーロッパ、アジア太平洋などの地域用のコンテナを設定することもできます。同様に、人事、研究開発、営業などの機能部門用のコンテナを設定することもできます。
業界によっても、コンテナまたはゾーンを使用する目的が異なります。大学は、学生ごとにゾーンを設定し、OS のインスタンス、システムリソースの共有、および root パスワードを割り当てることができます。ワイヤレス企業は、長距離通話サービス、市内通話サービス、ボイスメールなどのサービスを監視するコンテナを設定できます。ケーブル会社やインターネットサービスプロバイダは、DSL、ケーブルモデム、またはケーブルテレビサービス用のコンテナを設定できます。金融機関は、データウェアハウスに対して複雑な照会を実行するユーザーと、オンライントランザクション処理が必要なユーザーに別々のコンテナを設定できます。独立ソフトウェアベンダー (ISV) は、ソフトウェアやサービスを販売する顧客ごとにコンテナまたはゾーンを設定できます。
Container Manager およびその他のリソース管理ユーティリティ
この製品では、Solaris 8、Solaris 9、および Solaris 10 で動作する既存のリソース管理ユーティリティがまとめられます。具体的には、この製品には、Solaris Resource Manager 1.3 と Solaris 9 Resource Manager の設定を簡素化するツールが含まれます。
Solaris リソース管理ユーティリティに関する詳細は、『Solaris Resource Manager 1.3 System Administration Guide』および『Solaris のシステム管理 (ネットワークサービス)』を参照してください。
Solaris Container モデル
Solaris Container は、物理的なシステムリソースの集合を体系づけて管理するのに役立つ抽象化層です。コンテナを使用して、アプリケーションに必要なリソース要件の詳細な計画を立てることができます。アプリケーションに対するリソース要件が、Solaris Container モデルの中心となります。このモデルでは、サービスまたは作業負荷に注目します。サービスは、アプリケーションによってもたらされ、システムへの作業負荷となります。実行中のアプリケーションなど、関連する一連のプロセスが作業負荷となります。
Solaris Resource Manager 1.3 では、作業負荷に基づいた古い方式の管理が実装されていました。このリリースでは、作業負荷が制限ノード (lnode) に関連付けられていました。Container Manager ソフトウェアでは、この方式を拡張しています。現在のコンテナモデルは、サービスに対してリソースの継続的な割り当てを構成および管理する手段を提供しています。一般的なサービスの例には、給与、顧客の注文の検索、Web サービスの配信があります。
サーバー統合では、アプリケーションを制限する環境を記述できる必要があります。この記述を設定すると、サーバー当たり 1 つのアプリケーションを実行する環境から、単一のサーバーで複数のアプリケーションを実行する環境に移行できます。コンテナは、この記述であると同時に、そのインスタンス化でもあります。たとえば、簡単なコンテナでは、CPU、物理メモリー、および帯域幅などのシステムリソースを記述できます。複雑なコンテナでは、セキュリティ、名前空間の独立、およびアプリケーション障害も制御できます。
次の Solaris Container の図に、サービスとリソースの関係を示します。
図 1–1 Solaris Container の例
枠がコンテナを表します。サービスを囲む枠の x、y、および z の各軸に沿って 3 種類のリソースがあります。このモデルでは、CPU、メモリー、および帯域幅が基本リソースです。サービスは、コンテナにどのように包含されるかを示すために枠で囲まれています。このリリースでは、Container Manager によって 3 つの基本リソースである CPU、物理メモリー、および帯域幅がすべて制御されます。
Container Manager は作業負荷に注目するため、単一のホストで使用されるリソース量は監視されません。ホストとは、Container Manager のエージェントソフトウェアがインストールされ、また Sun Management Center サーバーのコンテキストに含まれるシステムです。インストールが完了すると、ホストは自動的に検出され、その名前が「ホスト」表示のナビゲーションウィンドウに追加されます。ソフトウェアによって、サービスで使用されるリソース量が監視されます。このモデルでは、サービスのインスタンス 1 つが、個別のホストで実行される 1 つ以上のプロセスを表します。データは、システムの健全性の監視とアカウンティングのために保持されます。
図 1–2 ホスト上のコンテナの例
単一のホストで同時に複数のコンテナを有効にできます。単一のホストに複数のコンテナがある場合、ホストがコンテナを拡張および縮小できるように、コンテナの境界を設定できます。この場合、ほかのコンテナが使用していないリソースがあれば、そのリソースを使用したいコンテナに割り当てられるようになります。最終的に、単一のホストで有効にできるコンテナ数は、使用可能な CPU 数とメモリー容量、および各コンテナで予約されているこれらのリソース量によって決まります。システムは、すべての有効なコンテナに必要なリソースの総量を備えている必要があります。リソース量は、アプリケーションのニーズによって決まります。
Container Manager でのコンテナの管理については、第 4 章「プロジェクトの管理」を参照してください。
資源管理
一般に、リソースは、プロセスにバインド可能な OS のエンティティを表します。通常は、カーネルサブシステムによって構築され、分割が可能なオブジェクトを表します。リソースは、アプリケーションの動作を変更するために操作可能な計算機システムの一部と考えることもできます。リソースの例には、物理メモリー、CPU、またはネットワーク帯域幅があります。
Container Manager は、Solaris 8、Solaris 9、および Solaris 10 のリソース管理ユーティリティと連動します。Solaris 8 では、Solaris Resource Manager 1.3 によってリソースが管理されます。各サービスは lnode で表されます。lnode を使用して、リソース割り当てポリシーとリソースの使用状況データが記録されます。lnode は、UNIX ユーザー ID (UID) に対応します。UID は、デフォルトで個々のユーザーとアプリケーションを表します。lnodes およびリソース管理の詳細は、『Solaris Resource Manager 1.3 System Administration Guide』の「Limit Node Overview」を参照してください。
Solaris 9 と Solaris 10 では、Resource Manager によってリソースが管理されます。このリリースでは、lnode に似ているものとしてプロジェクトがあります。プロジェクトは、関連する処理のネットワーク全体の管理 ID です。コンテナ内で実行されるすべてのプロセスはプロジェクト識別子 (プロジェクト ID) が同じです。Solaris カーネルによって、プロジェクト ID を使用してリソース使用状況が追跡されます。同じ追跡方法を使用する拡張アカウンティングを使用して履歴データを収集できます。Container Manager では、プロジェクトがコンテナに相当します。
図 1–3 ホスト上のプロジェクトの例
コンテナ内で実行されるプロセスに関する情報は、Container Manager の GUI で確認します。ソフトウェアを使用してコンテナを作成および管理すると、データは透過的に収集されます。
コンテナの境界は、複数の方法で作成できます。リソースプールを使用してシステムを分割する方法と、リソース制御によってプロジェクトに制限を設定する方法があります。
リソースプール
リソースプール (またはプール) は、Solaris 9 と Solaris 10 で、ホストのリソースを分割するために使用されているソフトウェア構成機構です。リソースセットは、プロセスにバインド可能なリソースです。リソースセットの例には、メモリーセットやプロセッサセットがあります。Solaris 9 と Solaris 10 では、プロセッサセットだけを使用できます。プールは、ホスト上で使用可能なさまざまなリソースセットをバインドしたものです。
リソースプールは、1 つまたは複数のプロジェクトを保持できます。プロジェクトが 1 つの場合、プールに関連付けられているリソースは、そのプロジェクト専用です。プロジェクトが複数の場合、プールに関連付けられているリソースは、プロジェクト間で共有されます。
Solaris 10 オペレーティングシステムでは、製品に動的リソースプールという機能があります。動的リソースプールを使用すると、システムイベントや負荷の変更に応じて各プールのリソース割り当てを調整できるので、パフォーマンスを向上できます。この機能については、「動的資源プール」を参照してください。
Solaris 8 オペレーティングシステムでは、ホストで使用できるリソースプールは 1 つだけです。このプールを pool_default といいます。この OS バージョンでは、リソースプールは存在しないので、見かけ上、pool_default が作成されます。Solaris 8 が動作するホスト上の CPU はすべて単一のプールに含まれると見なされます。
Container Manager によるリソースプールの管理については、第 5 章「リソースプールの管理」を参照してください。
リソースの制御
複数のプロジェクトが単一のプールにバインドされている場合は、単一のプロジェクトに保証 (制限) を設定できます。この制限をリソース制御といいます。制御の例には、公平配分スケジューラ (FSS) を使用する場合などの最小 CPU 制限の設定があります。また、rcapd デーモンを使用する場合などの物理メモリーキャップの設定もあります。最小 CPU 保証を設定すると、1 つのプロジェクトのアイドル状態の CPU サイクルを、ほかのプロジェクトのアプリケーションが使用できます。
ゾーン
ゾーンは、アプリケーションを実行するための独立した安全な環境です。ゾーンを使用すると、Solaris のインスタンス内で仮想化されたオペレーティングシステム環境を作成できます。ゾーンを使用すると、1 つまたは複数のプロセスを、システムのほかのプロセスから独立して実行できます。たとえば、ゾーン内で実行されているプロセスは、ユーザー ID やその他の資格情報に関係なく、同じゾーン内のほかのプロセスだけにシグナルを送信できます。エラーが発生した場合は、ゾーン内で実行されているプロセスだけに影響します。
大域ゾーン
すべての Solaris 10 システムには、OS の旧バージョンと同様に、大域ゾーンという一般的な大域環境が含まれます。大域ゾーンには 2 つの機能があります。大域ゾーンはシステムのデフォルトゾーンであり、またシステム全体の管理制御に使用されるゾーンでもあります。大域管理者が、非大域ゾーン (単に「ゾーン」ともいう) を作成していない場合、すべてのプロセスは大域ゾーン内で実行されます。
非大域ゾーンの構成、インストール、管理、およびアンインストールは、大域ゾーンからのみ行うことができる。システムハードウェアから起動できるのは、大域ゾーンだけです。物理デバイス、ルーティング、または動的再構成 (DR) などの管理作業は、大域ゾーンでのみ行うことができます。大域ゾーンで実行中の、適切な権限を持つプロセスやユーザーは、ほかのゾーンに関連付けられているオブジェクトにアクセスできます。
大域ゾーン内の権限がないプロセスやユーザーは、非大域ゾーン内の権限を持つプロセスやユーザーに許可されていない処理を行うことができる場合があります。たとえば、大域ゾーンのユーザーは、システムのすべてのプロセスに関する情報を表示できます。ゾーンを使用すると、管理者は、システム全体のセキュリティーを保ちながら、一部の管理作業を委任できます。
非大域ゾーン
非大域ゾーンには、専用の CPU、物理デバイス、物理メモリー領域が不要です。これらのリソースは、単一のドメインまたはシステム内で実行されている複数のゾーンで共有できます。ゾーンは、起動または再起動しても、システム上のほかのゾーンに影響ありません。各ゾーンの要件に応じて、カスタマイズしたサービスを提供できます。プロセスの基本的な独立のため、プロセスは同じゾーン内のプロセスだけを認識でき、また同じゾーン内のプロセスだけにシグナルを送信できます。ゾーン間の基本的な通信は、各ゾーンに 1 つ以上の論理ネットワークインタフェースを与えることで可能になっています。1 つのゾーン内で実行されているアプリケーションは、別のゾーンのネットワークトラフィックを確認できません (パケットのストリームは同じ物理インタフェースを通ります)。
ネットワーク接続が必要な各ゾーンには、1 つまたは複数の専用 IP アドレスを設定します。
ゾーンの詳細は、『Solaris のシステム管理 (Solaris コンテナ : 資源管理とSolaris ゾーン)』を参照してください。
リソース使用状況レポートおよび拡張アカウンティングデータ
Performance Reporting Manager アドオン製品が Container Manager とともにインストールされている場合は、リソース使用状況の履歴データのレポートをコンテナ、リソースプール、ゾーン、プロジェクト、またはホストごとに作成できます。CPU データ、メモリー使用状況データ、および CPU の拡張アカウンティングデータは、Performance Reporting Manager のデータ収集サービスによってデータベースに保存されます。GUI から、リソース使用状況の詳細を示すグラフレポートを要求するか、コンマ区切り (CSV) 形式のテキストファイルにデータをエクスポートできます。テキストファイルは、たとえば請求や会計のアプリケーションで使用できます。
Performance Reporting Manager ソフトウェアの詳細については、『Sun Management Center 3.6.1 Performance Reporting Manager User’s Guide』を参照してください。使用可能なレポートとアカウンティングデータについては、「レポート」を参照してください。
Container Manager をご使用になる前に
Container Manager ソフトウェアをインストールし、使用する前に、リソース消費のニーズを評価します。コンテナ作成処理の一環として、コンテナ内で実行されるプロセスの最小 CPU 予約数と、必要に応じて物理メモリーキャップを指定します。ニーズを評価し、目標を定め、リソース計画が決定していると、コンテナの作成処理が簡単になります。また、作業の前にすべてのハードウェアの仕様のマスターリストも用意すると役立ちます。
サーバーを統合する場合
サーバーの統合を成功させるためには、統合の候補のすべてのサーバー、記憶装置、およびアプリケーションのマスターリストが重要です。統合計画が完成したら、このリストを使用して計画を実施します。
データセンターでサーバーを統合する場合は、Container Manager ソフトウェアをインストールし、使用する前に必要な作業があります。次の作業が必要です。
-
統合するアプリケーションを選択します。
-
アプリケーションの作業負荷を構成するプロセス、ユーザーのグループ、ユーザーなどのコンポーネントを特定します。
-
定義した各作業負荷のパフォーマンス要件を決定します。この作業では、CPU、メモリー、ネットワーク、および記憶装置の必要量と使用状況を含めて、現在のシステムでアプリケーションのリアルタイムのアクティビティを監視する必要があります。また、新しいシステムを構成し、読み取り専用ファイルシステム、ライブラリ、マニュアルページなどのリソースを効率よく共有するために各作業負荷が使用する、ファイルシステム、共有ファイルシステム、および共有ライブラリの種類を判断する必要があります。
-
どのアプリケーションにもっともリソースが必要か、およびリソースが必要な期間によって、システムリソースを共有する作業負荷に順位を付けます。同じシステム内の競合する作業負荷を特定する必要もあります。
-
これらの作業負荷のプロジェクトを特定します。プロジェクトは、関連する作業をグループにまとめるための管理名です。たとえば、Web サービスのプロジェクトや、データベースサービスのプロジェクトを設定できます。
注 –
Solaris オペレーティングシステムでは数千個のコンテナを使用できますが、実際上は、またパフォーマンスのためには、200 個のホスト、ホスト当たり 10 ゾーン、ゾーン当たり 10 プロジェクトを推奨します。
サーバーの統合の計画および実行については、David Hornby、Ken Pepple 共著『Consolidation in the Data Center』(Sun Blueprints) を参照してください。
Container Manager 使用例
Container Manager の使用例を示します。
Oracle 用のゾーンがある複数のプロジェクト
この例では、ゾーンが設定されたデフォルトのリソースプールがあるとします。ここで、ゾーンが 2 つ、リソースプールが 1 つあるコンテナを 1 つ設定します。一方のゾーン zone_ora1 に Oracle データベースアプリケーション、他方のゾーン zone_ws01 に Web サーバーアプリケーションがあります。リソースプールにはそれぞれ 2 つの CPU があります。コンテナに 8 個の CPU シェア数を設定します。zone_ora1 用に 4 つ、zone_ws01 用に 3 つです。コンテナでは、公平配分スケジューラを使用します。
動的リソースプールの例
この例では、リソースプールが 2 つあるコンテナを 1 つ設定します。pool1 には、1 〜 3 個の CPU が割り当てられます。pool1 の負荷の目標は、20 ％ より大きく、80 ％未満です。pool2 は、メールサーバーで使用されます。他方のプールは動的なので、メールサーバーに必要な負荷によって、アプリケーションに 1 〜 3 個の CPU を使用できます。
同一コンテナを共有するアプリケーション
この例では、ゾーンが 2 つあるコンテナを 1 つ設定します。最初のゾーン zone_ora02 には、7 つのプロジェクトがあります。ユーザー ORACLE 用のプロジェクト、データベース管理者のグループによって実行されるプロセス用のプロジェクト、および system、user.root、noproject、default、および group.staff の 5 つのデフォルトプロジェクトです。最初のゾーンには合計 100 個の CPU シェアがあります。デフォルトプロジェクトには、それぞれ 1 つのシェアを割り当てます。ユーザー ORACLE の最初のプロジェクトには 75 個のシェアを割り当て、group.dba 用の 2 つめのプロジェクトに 20 個のシェアを割り当てます。
2 つめのゾーン zone_ws_02 は Web サーバー用です。
複数のシステム上の Oracle 10g ラック
この例では、Oracle 10g アプリケーションを複数のシステムで実行します。Oracle 10g アプリケーション用に 1 つのプールと 1 つのゾーンがあるプロジェクトをシステム 1 に作成します。ゾーンとプールを含むプロジェクトを別のシステムにコピーし、そのシステムでプロジェクトを Oracle 10g アプリケーションに関連付けます。
複数のリソースプールがある複数のシステム
この例では、2 つのシステムがあり、それぞれに 2 つのプールがあります。Web サーバーがあるプロジェクトがシステム 1 に、Web サーバーがあるプロジェクトがシステム 2 にあります。各プロジェクトには 10 個の CPU シェアがあり、各 Web サーバーに 5 個のシェアを割り当てます。残りの 5 つのシェアは、将来のために残しておきます。
Solaris Container Manager 3.6 および 3.6.1 の新機能と変更点
Solaris Container Manager は、次に示す新機能を備えています。機能は、オペレーティングシステムによって異なります。
表 1–1 Solaris Container Manager 3.6 の新機能|
利点 |
機能 |
Solaris 10 (SPARC および x86) |
Solaris 9 (SPARC および x86) |
Solaris 8 (SPARC) |
|---|---|---|---|---|
|
プロセスを独立して仮想 OS 環境で実行 |
ゾーン管理 |
あり | ||
|
システムパフォーマンスの目標の設定と取得 |
動的リソースプール |
あり | ||
|
ネットワークの輻輳の回避 |
IPQoS (Internet Protocol Quality of Service) |
あり | ||
|
より柔軟なプロセス管理 |
コンテナ間でのプロセスの移動 |
あり |
あり | |
|
タイムシェアスケジューラのサポート |
ほかのスケジューラクラスのサポート |
あり |
あり |
あり |
|
仮想化ツールの改善 |
グラフの改善 |
あり |
あり |
あり |
|
メモリーを割り当てるゾーンを認識するコンテナ |
コンテナの改善 |
あり |
あり |
あり |
|
上位 5 つのリソースオブジェクトの使用状況レポート |
グラフの改善 |
あり |
あり |
あり |
Solaris Container Manager 3.6.1 ではゾーンのコピー機能が強化されました。単一ホストで非大域ゾーンの複数のコピーを、または複数のホストで 1 つの非大域ゾーンのコピーを作成することができます。この機能の詳細は、「非大域ゾーンのコピー」第 6 章「ゾーンの管理」を参照してください。
ゾーン管理
Container Manager を使用すると、非大域ゾーンを作成、削除、変更、停止、および再起動できます。Container Manager では、既存のゾーンの検出、ゾーンの変更の検出、ゾーンの CPU 、メモリー、およびネットワークの使用状況の監視とアーカイブ、およびゾーンの起動/停止アラームの生成も可能です。
ゾーンについては、第 6 章「ゾーンの管理」を参照してください。
動的資源プール
動的リソースプールでは、設定されたシステムパフォーマンスの目標を達成できるように各リソースプールのリソース割り当てが動的に調整されます。動的リソースプールによって、システム管理者が決定する必要のある事項が減ります。調整は、システム管理者が指定したシステムパフォーマンスの目標を満たすように自動的に行われます。
動的リソースプールは、Solaris 10 システムで作成、変更、および削除できます。最小と最大の CPU 数、使用状況の目標、局所性の目標、CPU シェアなど、動的リソースプールの制約を設定したら、Container Manager のエージェントによって、リソースが使用可能かどうか、また消費の状況に合わせてプールのサイズが動的に調整されます。
リソースプールの設定は、エージェントとサービスの両方のデータベースに保存されます。
IPQoS を使用した帯域幅制御
IP Quality-of-Service 機能によって、ネットワークユーザーに一貫したレベルのサービスを提供し、またネットワークトラフィックを管理できます。このサービスを使用すると、ネットワークの統計情報の順位付け、制御、および収集が可能です。
この機能では、Solaris ゾーンのインバウンドトラフィックとアウトバウンドトラフィックが管理されます。ゾーンの入力/出力ネットワーク帯域幅の上限を指定します。制限を超えると、パッケージは破棄されます。IPQoS には、CPU オーバーヘッドが相当量あるので、これはオプションの機能です。
Container Manager によって、作業の使用状況データが監視および収集され、ネットワーク使用状況の履歴グラフが作成されます。
柔軟性のあるプロセス管理
プロセス管理の柔軟性を高めるため、Container Manager 3.6 ではプロセスをコンテナ間で移動できます。Solaris 9 システムでは、プロセスをコンテナ間で移動できます。Solaris 10 システムでは、同じゾーン内のコンテナ間だけでプロセスを移動できます。
タイムシェアスケジューラ
Container Manager 1.0 では、公平配分スケジューラ (FSS) だけを使用できました。Container Manager 3.6 では、リソースプールを作成または変更するときに、公平配分スケジューラクラスまたはタイムシェアスケジューラクラスのいずれかを選択することができます。スケジューラクラスによってプロセスの優先順位、つまり次に実行されるプロセスが決まります。
リソースプールのスケジューラクラスを変更したら、そのリソースプールの新しいプロセスが、リソースプールのスケジュールクラスに変更されます。Container Manager では、実行中のプロセスのスケジューラクラスは変更されません。
コンテナの強化機能
Container Manager には、コンテナに次の拡張機能があります。
-
Solaris 10 の場合、コンテナはゾーンを認識します。各ゾーンには 5 つのデフォルトコンテナがあります。
-
1 つのコンテナに特定の量のシェアメモリーを割り当てることができます。
Container Manager のマニュアル
この製品の関連マニュアルを次の表に示します。Solaris Container Manager 3.6 のマニュアルは、http://docs.sun.com/app/docs/coll/810.4 で入手できます。
表 1–2 関連マニュアル|
作業 |
リソース |
|---|---|
|
コンテナのインストールおよび管理 |
Solaris Container Manager 3.6 インストールと管理 (このマニュアル) |
|
製品でヘルプの表示 |
Solaris Container Manager 3.6 オンラインヘルプ。このヘルプにアクセスするには、Solaris Container Manager の GUI で「ヘルプ」のリンクをクリックします。 |
|
Sun Management Center 3.6 およびアドオン製品のインストール (Container Manager を含む) | |
|
インストールに関する問題、実行時の問題、最新情報 (サポート対象のハードウェアを含む)、およびマニュアルの問題に関する情報の確認 | |
|
Container Manager のオプションのアドオン Performance Reporting Manager に関する情報の確認 |
『Sun Management Center 3.6.1 Performance Reporting Manager User’s Guide』 |
|
Solaris 8 オペレーティングシステムを使用している場合に、Solaris Resource Manager 1.3 に関する情報の確認 |
『Solaris Resource Manager 1.3 Installation Guide』 『Solaris Resource Manager 1.3 System Administration Guide 』 『Solaris Resource Manager 1.3 Release Notes』 |
|
Solaris 9 または 10 オペレーティングシステムを使用している場合に、Solaris リソース管理とゾーンに関する情報の確認 |
『Solaris のシステム管理 (Solaris コンテナ : 資源管理と Solaris ゾーン)』 |
基本的な使用方法
Solaris Container Manager をすでにインストールして設定している場合は、次のリンクをクリックすると、製品の操作方法を確認できます。
- © 2010, Oracle Corporation and/or its affiliates