資源管理機能は、Solaris コンテナ環境の構成要素です。資源管理を利用すると、アプリケーションが利用可能なシステム資源をどのように使用するかを制御できます。次のような制御が可能になります。
プロセッサ時間などのコンピュータ資源を割り当てます
割り当てた資源の使用状況を監視し、必要に応じて調整します
解析、課金、および容量計画のために拡張アカウンティング情報を生成します
この章の内容は次のとおりです。
今日のコンピューティング環境では、システム上で実行されるアプリケーションによって生成されるさまざまな作業負荷に柔軟に対応できる能力が求められます。「作業負荷」とは、1 つのアプリケーションまたは一連のアプリケーションが持つすべてのプロセスの集まりです。資源管理機能を使用しない場合、Solaris オペレーティングシステムは、新しいアプリケーションの要求に動的に適応することによって作業負荷の要求に対応しています。このデフォルトの動作は、通常、システムのすべてのアクティビティーに対して資源へのアクセスを同等に与えることを意味します。Solaris の資源管理機能を使用すると、作業負荷を個別に扱うことができるようになります。次のような制御が可能になります。
特定の資源へのアクセスを制限します
優先順位に基づいて作業負荷に資源を提供します
作業負荷を互いに分離します
作業負荷が相互に影響し合うことによる性能の低下を最小限に抑える機能と、資源の使用状況や使用率を監視する機能を総称して「資源管理機能」といいます。資源管理機能は、いくつかのアルゴリズムの集合として実装されます。これらのアルゴリズムは、アプリケーションがその実行過程で発行する一連の資源要求を処理します。
資源管理機能を使用すると、さまざまな作業負荷に対してオペレーティングシステムのデフォルトの動作を変更できます。この場合の「動作」とは、主に、アプリケーションが 1 つ以上の資源要求をシステムに発行したときに、オペレーティングシステムのアルゴリズムが行う一連の決定処理のことです。資源管理機能は、次の目的で使用できます。
あるアプリケーションに対して、資源の割り当てを拒否したり、ほかのアプリケーションに許可されているよりも大きい割り当てを与えたりします
特定の割り当てを個別にではなく一括して行います
資源管理機能を使用できるようにシステムを構成すると、いくつかの目的が達成できます。次のような制御が可能になります。
アプリケーションが際限なく資源を浪費するのを防止します
外部イベントに基づいてアプリケーションの優先順位を変更します
一連のアプリケーションに資源の使用を保証する一方で、システムの使用率を最大限に高めます
資源管理機能をシステム構成に組み込むときは、次のような作業が事前に必要です。
システム上で競合する作業負荷の特定
競合しない作業負荷と、主要な作業負荷に影響を与えるような性能要件を伴った作業負荷との区別
競合しない作業負荷と競合する作業負荷を特定したら、システムの能力が許す範囲内で、業務サービスへの影響を最小限に抑えた資源構成を構築できます。
効率のよい資源管理を実現するために、Solaris システムには制御機構、通知機構、および監視機構が用意されています。これらの機能の多くは、proc(4) ファイルシステム、プロセッサセット、スケジューリングクラスなどの既存メカニズムの拡張機能として提供されます。その他の機能は資源管理に固有です。これらの機能については、以降の章で説明します。
資源は、アプリケーションの動作を変更する目的で操作されるコンピューティングシステムのあらゆる側面を意味します。つまり、資源は、アプリケーションが暗黙的または明示的に要求する機能です。この機能が拒否または制限された場合は、堅固に作成されているアプリケーションの実行速度が低下します。
資源の分類は、資源の識別とは対照的に、多くの基準に基づいて行うことができます。たとえば、資源は、暗黙的な要求か明示的な要求か、時間 (CPU 時間など) に基づいた要求か時間に無関係な要求 (割り当てられた CPU 配分など) か、などを基準に行うことができます。
通常、スケジューラに基づいた資源管理は、アプリケーションが暗黙的に要求する資源に適用されます。たとえば、実行を継続するときは、アプリケーションは暗黙的に追加の CPU 時間を要求します。ネットワークソケットにデータを書き込むときは、アプリケーションは暗黙的に帯域幅を要求します。暗黙的に要求される資源の総使用量に対して制約を設けることができます。
帯域幅または CPU サービスのレベルを明示的に折衝できるように、インタフェースを追加することもできます。追加スレッドの要求のように明示的に要求される資源は、制約によって管理できます。
Solaris オペレーティングシステムでは、制約、スケジューリング、区分の 3 種類の制御機構を使用できます。
制約を使用すると、管理者やアプリケーション開発者は、作業負荷が使用する特定の資源の消費にいくつかの制限を設定できます。制限を設定すると、資源の消費シナリオを簡単にモデル化できます。また、制限を設定することにより、無秩序に資源を要求してシステムの性能や可用性に悪影響を及ぼす可能性がある悪質なアプリケーションを制御できます。
制約は、アプリケーションに制限を課します。アプリケーションとシステムの関係は、アプリケーションが動作できないところまで悪化してしまう可能性があります。そのような事態を回避する方法の 1 つは、資源に関する動作が不明なアプリケーションに対する制約を徐々に強めていくことです。第 6 章資源制御 (概要)で説明する資源制御機能が、制約機構を提供します。新たに作成するアプリケーションであれば、資源の制約をアプリケーションが認識するようにすることもできます。ただし、すべての開発者がこの機能を使用するとは限りません。
スケジューリングとは、一定の間隔で割り当てを決定することです。この決定は、予測可能なアルゴリズムに基づいて行われます。現在割り当てられている資源を必要としないアプリケーションは、ほかのアプリケーションが使用できるように、その資源を解放します。スケジューリングに基づいて資源管理を行うと、資源に余裕がある構成の場合は使用率を最大限にできると同時に、資源が限界まで、あるいは過剰に使用されている場合には、割り当てを制御できます。スケジューリングのアルゴリズムにより、「制御」という用語の意味が決まります。場合によっては、スケジューリングアルゴリズムは、すべてのアプリケーションが資源にある程度アクセスできることを保証します。第 8 章公平配分スケジューラ (概要)で説明する公平配分スケジューラ (FSS) は、アプリケーションが制御された方法でCPU 資源にアクセスするように管理します。
区分は、作業負荷をシステム上で使用可能な資源の一部に結合 (バインド) するために使用されます。資源と結合することにより、作業負荷は常に一定量の資源を使用できることが保証されます。第 12 章資源プール (概要)で説明する資源プール機能を使用すれば、作業負荷をマシンの特定の部分に制限できます。
区分を使用する構成では、システム全体が過剰使用されるのを防ぐことができます。ただし、この方法では、高い使用率の達成は難しくなります。プロセッサなど、予約済みの資源に結合されている作業負荷がアイドル状態になっている場合でも、別の作業負荷がその資源を使用することはできないためです。
資源管理構成の一部をネットワークのネームサービスに置くことができます。この機能により、管理者は、資源管理制約をマシンごとに排他的に適用するのではなく、複数のマシンに対して一括して適用できます。関連する作業は共通識別子を共有でき、その作業の使用状況はアカウンティングデータに基づいて表形式で表すことができます。
資源管理構成と作業負荷識別子の詳細については、第 2 章プロジェクトとタスク (概要)を参照してください。これらの識別子をアプリケーションの資源使用状況と結び付ける拡張アカウンティング機能については、第 4 章拡張アカウンティング (概要)を参照してください。
資源管理機能を Solaris ゾーンと組み合わせて使用すると、アプリケーション環境をさらに細かく調整できます。資源管理機能とゾーンの相互動作については、このマニュアルの該当部分で説明します。
資源管理機能を使用して、アプリケーションが必要な応答時間を確保できるようにします。
また、資源管理機能により、資源の使用率を向上させることができます。使用状況を分類して優先付けすることにより、オフピーク時に余った資源を効率よく使用でき、処理能力を追加する必要がなくなります。また、負荷の変動が原因で資源を無駄にすることもなくなります。
資源管理機能は、多くのアプリケーションを 1 台のサーバー上で統合できる環境で使用するともっとも高い効果を発揮します。
多数のマシンの管理は複雑でコストがかかるため、より大規模で拡張性の高いサーバーにアプリケーションを統合することが望まれます。個々の作業負荷を別々のシステムで実行して、そのシステムの資源への完全なアクセスを与える代わりに、資源管理ソフトウェアを使用すれば、システム内の作業負荷を分離できます。資源管理機能を使用すると、1 つの Solaris システムで複数の異なるアプリケーションを実行して制御することにより、システムの総保有コスト (TCO) を低減することができます。
インターネットサービスやアプリケーションサービスを提供する場合は、資源管理を使用すると、次のことが可能になります。
1 台のマシンに複数の Web サーバーを配置します。各 Web サイトの資源消費を制御し、各サイトをほかのサイトで起こる可能性のある過剰使用から保護します。
欠陥のある CGI (Common Gateway Interface) スクリプトが CPU 資源を浪費するのを防止します。
不正な動作をするアプリケーションによって引き起こされる、仮想メモリーのリークを防止します。
顧客のアプリケーションが、同じサイトで実行されている別の顧客のアプリケーションの影響を受けないようにします。
同一マシン上で異なるレベルまたはクラスのサービスを提供します。
課金目的でアカウンティング情報を取得します。
資源管理機能は、特に、教育機関のように大規模で多様なユーザーが利用するシステムでその効果を発揮します。さまざまな作業負荷が混在している場合は、特定のプロジェクトに高い優先順位を与えるようにソフトウェアを構成できます。
たとえば、大きな証券会社のトレーダは、データベースのクエリーや計算を実行するために、一時的に高速なアクセスが必要になる場合があります。一方、ほかのユーザーの作業負荷は、一定しています。トレーダのプロジェクトに、作業量に応じてより高い処理能力を割り当てれば、トレーダは必要とする応答性を確保できます。
また、資源管理機能は、シン (thin) クライアントシステムをサポートするのにも適しています。これらのプラットフォームは、フレームバッファーとスマートカードのような入力デバイスを持つステートレスなコンソールを備えています。実際の処理は共有サーバー上で行われるため、タイムシェアリング型の環境とみなすことができます。資源管理機能を使ってサーバー上のユーザーを分離してください。こうすることで、過剰な負荷を引き起こしたユーザーがハードウェア資源を占有し、システムを使用するほかのユーザーに重大な影響を与えることがなくなります。
次の作業マップに、システム上で資源管理機能を設定する際に必要となる作業の概要を示します。
タスク |
説明 |
説明 |
---|---|---|
システム上の作業負荷を特定し、各作業負荷をプロジェクト別に分類します。 |
/etc/project ファイル、NIS マップ、または LDAP ディレクトリサービス内にプロジェクトエントリを作成します。 | |
システム上の作業負荷に優先順位を付けます。 |
どのアプリケーションが重要かを判定します。重要な作業負荷には資源への優先的なアクセスが必要になる場合があります。 |
サービスの目的を考慮してください。 |
システム上で実際のアクティビティーを監視します。 |
パフォーマンスツールを使用して、システムで実行されている作業負荷の現在の資源消費量を表示します。その上で、特定の資源へのアクセスを制限する必要があるかどうか、あるいは特定の作業負荷をほかの作業負荷から分離する必要があるかどうかを判定できます。 |
「システム単位の監視」および cpustat(1M)、iostat(1M)、mpstat(1M)、prstat(1M)、sar(1)、および vmstat(1M) のマニュアルページ |
システムで実行されている作業負荷を一時的に変更します。 |
変更可能な設定値を決めるには、Solaris システムで使用できる資源制御を参照します。タスクまたはプロセスが実行している間は、コマンド行から値を更新できます。 |
「使用可能な資源制御」、「資源制御値に対応付けられた大域アクションと局所アクション」、「動作中のシステム上の資源制御値を一時的に更新する」、および rctladm(1M) と prctl(1) のマニュアルページ |
project データベースまたはネームサービスプロジェクトデータベース内のプロジェクトエントリごとに資源制御とプロジェクト属性を設定します。 |
/etc/project ファイルまたはネームサービスプロジェクトデータベース内の各プロジェクトエントリには、資源制御または属性を 1 つ以上含めることができます。これらの資源制御は、そのプロジェクトに属するタスクとプロセスを制約します。資源制御で指定する各しきい値に対しては、その値に達したときに行われるアクションを 1 つ以上対応付けることができます。 資源制御は、コマンド行インタフェースを使って設定できます。一部の構成パラメータは、Solaris 管理コンソールでも設定できます。 |
「project データベース」、「ローカルの /etc/project ファイルの形式」、「使用可能な資源制御」、「資源制御値に対応付けられた大域アクションと局所アクション」、および第 8 章公平配分スケジューラ (概要) |
プロジェクト内のプロセスの集合が消費する物理メモリーの容量に上限を設けます。 |
資源上限デーモンは、/etc/project ファイルでプロジェクトの rcap.max-rss 属性に指定されたとおり、物理メモリーの資源上限を制限します。 | |
資源プール構成を作成します。 |
資源プールは、プロセッサなどのシステム資源を区分する手段を提供し、再起動時にもそのパーティションを保持します。/etc/project ファイルの各エントリに project.pool 属性を 1 つ追加できます。 | |
公平配分スケジューラ (FSS) をデフォルトのシステムスケジューラとして設定します。 |
単一の CPU システムまたはプロセッサセット内のすべてのユーザープロセスが同じスケジューリングクラスに属するようにします。 |
「FSS の構成」および dispadmin(1M) のマニュアルページ |
拡張アカウンティング機能を起動し、タスクまたはプロセスに基づき資源消費を監視して記録します。 |
拡張アカウンティングデータを使って現在の資源制御を評価し、将来の作業負荷のための容量要件を計画します。システム全体の総使用状況を追跡できます。複数のシステムに渡って相互に関連しあう作業負荷について完全な使用統計を取得するために、プロジェクト名は複数のマシンで共有できます。 |
「プロセス、タスク、およびフローの拡張アカウンティングを起動する方法」および acctadm(1M) のマニュアルページ |
(省略可能) 構成をさらに調整する必要がある場合は、引き続きコマンド行から値を変更できます。値は、タスクまたはプロセスの実行中でも変更できます。 |
既存のタスクに対しては、プロジェクトを再起動しなくても、変更を一時的に適用できます。満足のいく性能が得られるまで値を調整します。次に、/etc/project ファイルまたはネームサービスのプロジェクトデータベースで現在の値を更新します。 |
「動作中のシステム上の資源制御値を一時的に更新する」および rctladm(1M) と prctl(1) のマニュアルページ |
(省略可能) 拡張アカウンティングデータを取得します。 |
アクティブなプロセスおよびタスクの拡張アカウンティングレコードを書き込みます。作成されるファイルは、計画、チャージバック、および課金のために使用できます。libexacct への Perl (Practical Extraction and Report Language) インタフェースを使用して、報告および抽出用のカスタムスクリプトを作成することもできます。 |
wracct(1M) のマニュアルページおよび 「libexacct に対する Perl インタフェース」 |