情報技術を扱う組織では、通常、コストを制御し、基幹アプリケーションのサービスレベルを保証する必要があります。資源管理者はさまざまな方法を用いて、組織全体の総コストを下げたり、システムをだれがどのように使用するかをより正確に制御したりします。
Solaris Resource Manager ソフトウェアを使って使用量による優先付けを行えば、管理者は、閑散時の余剰能力を効果的に利用でき、処理能力を拡大する必要もなくなります。
システム管理者は Solaris Resource Manager を使用してシステムの中で作業負荷を分散できるため、性質の異なるアプリケーションを同じシステムで実行したり管理したりできます。したがって、システム全体 (ピーク時の能力全体) を個々のアプリケーションに割り当てる必要はありません。従来、予測可能な応答時間にサービスを受けるためには、1 つのシステムで 1 つの機能を行うことが最も一般的な方法でした。この方法は確かに有効ですが、データセンターのシステムを拡大するにはコストがかかり、管理もむずかしくなります。
Solaris Resource Manager は、複数のアプリケーションを 1 台の UNIX サーバーに統合し、すべての使用可能な資源を完全に利用できるようにします。それと同時に、すべてのユーザーは、自分のサービスレベルと作業の相対的な重要性に見合った資源を使用できる必要があります。
次の表では、このマニュアルで説明する主なシステム資源の制御機能を示します。
システム資源 | Solaris Resource Manager パラメータ | 説明 |
---|---|---|
CPU 割当数 | cpu.shares | l ノードに割り当てる CPU 時間の量。リミットデータベースファイルでは、割当数として指定します。Solaris Resource Manager は、利用できるシステム資源をすべて割り当てます。したがって、資源が利用可能な場合は、l ノードは割り当てを超えて資源を利用できます。 |
CPU 総使用量 | cpu.accrue | 現在の l ノードの使用量、およびグループ内にあるすべての l ノードの CPU 総使用量 |
メモリー制限値 | memory.limit | l ノードに接続された全プロセスに許される仮想メモリーの最大使用量。この制限値は、リミットデータベースファイルに指定された固定値です。値 0 は、制限がないことを示します。 |
プロセスのメモリー制限値 | memory.plimit | プロセスあたりの最大仮想メモリーの制限値。これは、リミットデータベースファイルに指定される固定値です。値 0 は、制限がないことを示します。 |
メモリー総使用量 | memory.accrue | 一定期間に使用するメモリー資源の総使用量。値はバイト秒で測定します。 |
プロセス数 | process.limit | リミットデータベースファイルに指定される固定値に従って、ユーザーが同時に実行できるプロセス数を制限します。 |
ユーザーあたりのログイン数 | flag.onelogin flag.nologin | リミットデータベースファイルに指定される固定値に従って、ユーザーまたはスケジューリンググループごと、あるいはその両方のログイン数または同時に開始できるログインセッション数を制限します。Solaris Resource Manager は、PAM 認証レコードと utmp(4) エントリを使用して、ログインカウントを追跡します。このカウンタは、動的に加算および減算されます。 |
接続時間 | terminal.limit terminal.usage terminal.accrue | Solaris Resource Manager は動的にユーザーの接続時間を追跡して、この値とシステム管理者やグループヘッダーがリミットデータベースファイルに指定した固定制限値とを比較します。ユーザーの接続時間が制限値に近づくと、Solaris Resource Manager は警告メッセージをユーザーの端末に送信します。接続時間が制限値に達すると、ユーザーに通知され、短い猶予時間の後に強制的にログアウトされます。 |
Solaris Resource Manager では、さまざまな状況で資源を効果的に制御できます。たとえば、サーバーの統合、インターネットサービスプロバイダ (ISP) の Web サービス、バッチ処理、多数のユーザーをもつあるいはユーザー数が変動するサイトの管理、適切な応答時間でアプリケーションを使用できるポリシーを確立したい時などです。
複数のアプリケーションを 1 台のサーバーに統合しようとする環境では、Solaris Resource Manager の効果がもっとも期待できます。多数のマシンの管理は複雑でコストがかかるため、システム管理者にとっては、アプリケーションをより大きなスケーラブルなシステムに統合することが必要です。Solaris Resource Manager を使用すれば、このような規模のシステムを経済的に統合できます。
たとえば、1 台のサーバーがあれば、アプリケーション、ファイル、印刷などの異機種クライアントに対するサービス、メッセージやメールサービス、Web サービス、基幹業務データベースアプリケーションを同時に提供できます。Sun EnterpriseTM サーバーは 1 個から 64 個のプロセッサまで拡張可能なため、1 台のサーバーをいくつかの部門で共有することも、企業全体で使用することもできます。サーバーの統合例としては、開発環境、プロトタイプ環境、および実際の環境を 3 つの別々のサーバーに作成する代わりに、Sun Enterprise 10000 や Sun Enterprise 6500 などの大きな 1 台のマシンに統合する場合があります。また、データベースサーバーとアプリケーションサーバーを同じマシンまたは複数のデータ供給マシンに統合することもあります。Solaris Resource Manager を使用すると、アプリケーションの種類や構成に関わらず、あらかじめ定義したポリシーに従ってシステムの資源をすべてのユーザー、アプリケーション、およびグループに割り当てることが容易になります。重要なアプリケーションには必要なシステム資源の使用が保証されるため、これらのアプリケーションが保護されます。
今までは ISP はクライアントごとに占有マシンを割り当てなければならなかったため、コストがかかり、複雑な作業が必要でした。Solaris Resource Manager を使用すれば、ISP は数千以上の Web サーバーを 1 台のマシンに収容できます。管理者は、資源の使用量を Web サイトごとに制御できるため、あるサイトでの資源使用が他のサイトの過剰な使用によって制限されることを防止できます。さらに、Solaris Resource Manager を使用すれば、欠陥のある CGI (Common Gateway Interface) スクリプトが CPU 資源を占有したり、ユーザーアプリケーションが使用可能なすべての仮想メモリーをリークしたりすることを防止できます。
Solaris Resource Manager では、バッチの作業負荷が通常の業務活動や同時に実行される他のバッチジョブに影響するのを防止できます。
Solaris Resource Manager を使用すると、ユーザーは多数のシステムでの資源管理を簡単に行えます。そのような例として多種多様なユーザーにサービスを提供する教育機関があります。実際、Solaris Resource Manager は、University of Sydney と University of New South Wales によって開発された初期の CPU 資源スケジューラが基になっています。いろいろな作業負荷が混在している場合には、一定のユーザーを優先するように Solaris Resource Manager ソフトウェアを構成できます。たとえば、大きな証券会社のトレーダは、照会や計算を行うために高速アクセスが必要になることがあります。一方、他のシステムユーザーの作業負荷はもっと一定です。Solaris Resource Manager を使用してトレーダにその作業に応じた処理能力を与えれば、必要な応答性を得ることができます。
Solaris Resource Manager には、システムの処理時間、仮想メモリー、プロセス数、ログイン回数、接続時間など、さまざまな重要資源の使用を管理する機能があります。Solaris Resource Manager 管理モデルでは、階層内での管理権限の委任が許されるため柔軟性が増し、データセンターのスタッフがグループ内の管理トランザクションに関与する必要がなくなります。さらに、Solaris Resource Manager には、資源の使用状況のデータを収集する機能があり、容量計画や課金のために使用されています。
オペレーティングシステムの基本的な仕事の 1 つは、各プロセスでのシステム資源の使用量を調整することです。デフォルトの Solaris タイムシェア (TS) スケジューラでは、各プロセスでシステム資源をほぼ同等に使用することを許可します。使用が制限されるのは、物理的なメモリー資源がないプロセス (実行は許可されない) と保留中の入出力要求があるプロセス (ブロックされる) です。
最近のほとんどのオペレーティングシステムではこの方式が基本です。この方式は、「すべてが同等な使用権利を持つ」ことが組織のポリシーである限りうまく機能します。しかし、異なるポリシーの下では、もっと精巧な機構が必要です。たとえば、製造部門は大きなシステムを持っていますが、季節によって需要が変わるため、その負荷は軽くなります。一方、技術部門はほとんど常にもっと大きな計算能力を必要としています。大きなマシンの資源を有効に使用しないのは不経済なことですが、製造システムを技術部門と共有することは今まで課題でした。単純なスケジューリングポリシーでは、同じシステムにおいて製造部門のユーザーの方が技術部門のユーザーよりも重要であることをオペレーティングシステムに知らせることができません。製造部門の重要なジョブがシステム資源の 75 パーセントを使用する場合には、他のすべてのジョブがシステムの 25 パーセント以下しか要求しなければ、ジョブの適切な進捗が保たれます。しかし、システムの 50 パーセントを必要とする技術部門のジョブが入ってくると、この製造部門のジョブは、十分な進捗を保つために必要な資源を得られないでしょう。この問題は、システムがこれらのジョブを同等に扱おうとするため起こります。
ここで、管理者が、製造の通常の処理要件がマシンの能力の 80 パーセントを使用すれば満足されると判断したとします。Solaris Resource Manager を使用すれば、システム管理者は、製造部門のユーザーが要求する場合には、システムの処理能力の 85 パーセントをこのユーザーに割り当て、残りをスケジューラが任意のユーザーに割り当てるように指定できます。さらに極端な場合には、製造部門のユーザーに必要ならシステムの 100 パーセントを割り当てるように指定できます。この場合には、製造部門で実際にシステム全体を使用すると、他のグループのプロセスは事実上実行できなくなります。
Solaris Resource Manager には、標準のタイムシェアスケジューラを置き換える CPU スケジューリングクラスがあります。SHR スケジューラと呼ぶこのモジュールでは、フェアシェアスケジューラ (fair share scheduler) が実装されます。この用語は正しい意味を表わしていません。「フェア」の意味を具体的に決定するのはシステム管理者です。上の例では、「フェア」は、製造がシステムの 100 パーセントを使用できることでした。SHR スケジューラでは、管理プロファイルに指定された計画に従って資源を割り当てます。
Solaris Resource Manager には、資源の使用量とそれに対応する制限値を表すデータベースがあります。
SHR スケジューラは、資源の使用に関する管理者の指定を考慮に入れます。このスケジューラは、CPU などの再生可能資源やプロセス数などの固定資源を管理できます。
さらに、Solaris Resource Manager の他のモジュールが、いろいろな資源の使用を制限します。たとえば、接続時間とユーザーのログインは、Pluggable Authentication Module (PAM) が管理します。PAM は、ユーザーがログインするたびに Solaris Resource Manager データベースを参照します。システムが通常パスワードの照合によってユーザーを確認すると、ユーザーの接続時間と現在のログイン回数が上限値を超えていないか検査されます。どちらかの限度を超えると、ログインは拒否されます。
Solaris オペレーティング環境には、ある種の資源を制御する機能が他にいくつかあります。リアルタイムスケジューリング、nice(1)、ディスククォータ、プロセッサセットなどの機能は、基本的な Solaris システムに含まれています。
Sun Bandwidth Allocator はアンバンドルのソフトウェアパッケージです。また、動的システムドメインは Sun Enterprise 10000 システムプラットフォームの機能、動的再構成は Sun Enterprise 6500 システムプラットフォームの機能です。
これらの構成要素はどれも資源管理を実行しますが、Solaris Resource Manager の機能とは何らかの点で異なります。
リアルタイムスケジューリング
標準の Solaris オペレーティングシステムは、従来のほとんどの仕事に対し TS スケジューリングクラスを使用しますが、十分な特権を持つユーザーに対してはリアルタイム (RT) スケジューリングを使用します。RT スケジューリングクラスでは、特定の作業負荷やプロセスがプロセッサに直ちにアクセスできるように、他とは非常に異なった (そして、意図的に大きな重みを加味した) スケジューリングポリシーが使用されます。
Solaris Resource Manager は、RT スケジューリングクラスと同じシステムで使用できますが、RT クラスで動作しているプロセスを制御することはできません。Solaris Resource Manager フェアシェアスケジューラでは、RT スケジューリングクラスで動作していないプロセスの CPU 時間資源しか管理できません。たとえば、4 個のプロセッサを持つシステムでは、単一スレッドのプロセスが 1 つのプロセッサ全体を占有することがあります。実際、要求プロセスが CPU を占有するプロセスだと、このようなことが起ります。このシステムでさらに Solaris Resource Manager が動作している場合には、通常ユーザーのプロセスは、リアルタイムプロセスによって使用されていない 3 つの CPU に対して割り当てられます。RT プロセスが CPU を継続して使用するとは限らないので、RT プロセスがアイドルのときは、Solaris Resource Manager が 4 個のプロセッサをすべて制御します。
nice(1) コマンド
nice(1) コマンドでは、ユーザーが実行優先順位を変更できます。ただし、スーパーユーザー特権がない場合は、優先順位を低くすることしかできません。たとえば、対話ログインセッションから優先順位の低いバッチジョブを起動する場合など、場合によっては便利な機能ですが、ユーザーの操作が不可欠です。Solaris Resource Manager では管理ポリシーを強制的に適用するので、ユーザーの操作は特に必要ありません。
ディスク割り当て
Solaris ファイルシステムのディスク割り当て機能で、管理者が個々のユーザーのディスク使用量を制限できます。この機能は、Solaris Resource Manager とは独立したものです。
プロセッサセット
プロセッサセットは Solaris 2.6 で導入された機能です。この機能では、管理者がマルチプロセッサシステムを論理グループに分割することによって、ユーザーがこれらのグループでプロセスを起動できます。この利点は、あるプロセッサセットで動作する作業負荷が他のプロセッサセットで行われている CPU 動作には影響を与えないということです。これはある点で Solaris Resource Manager の機能と似ていますが、基本的に 2 つの機能は全く異なっています。プロセッサセットは CPU 動作だけを制御します。この制御は比較的設定が細かくないハードウェアレベルのものです。ある時点ではプロセッサは 1 つのプロセッサセットだけに所属します。特にプロセッサの少ない比較的小さなシステムでは、設定が細かくできないことがあります。4 個のプロセッサを持つシステムの場合は、割り当て可能な資源はシステムの 25 パーセントです。
Solaris Resource Manager ではもっと細かい制御が可能です。各ユーザーにはシステムの割当数が与えられます。これらの割当数を細かく指定すれば、スケジューラがそれに従って資源を割り当てます。たとえば、割当数 50 であるユーザーの割当数が 40 だとすると、このユーザーは資源の 80 パーセント (40/50=80) を獲得します。同じように、全体として割当数 67 である場合には、割当数 57 を持つユーザーは資源の 85 パーセントを獲得します。また、Solaris Resource Manager では CPU 以外の資源も制御できます。Solaris Resource Manager とプロセッサセットの相互動作については、「プロセッサセットの役割と効果」を参照してください。
動的ドメイン
Sun Enterprise 10000 には「動的システムドメイン」と呼ばれる機能があります。管理者が 1 つのシステムラックをいくつかの独立したシステムに論理的に (メインフレームのパーティション分割のように) 分割します。各システムは独自の Solaris のコピーを実行できます。たとえば、8 つのシステムボードに 32 個の CPU を持つマシンは、16 個の CPU を持つシステムが 1 つと 8 個の CPU を持つシステムが 2 つとして使用できます。このような場合には、Solaris の 3 つのコピーが動作します。 動的システムドメインは、Solaris の各コピーに資源を追加したり、取り除いたりする処理を管理するツールを提供しているため、物理資源を管理する広範な機能を実現しています。
Solaris Resource Manager は、資源を割り当てる機能を管理者に提供する点で動的システムドメインに似ていますが、その方法は全く異なっています。Solaris Resource Manager は Solaris の単一インスタンスの中で動作し、システムの資源を管理する上で設定を細かくして制御できます。Solaris Resource Manager は、Sun Enterprise 10000 システム内の各 Solaris インスタンスにおいて多くのユーザー間、あるいはアプリケーション間で資源を分割するのに使用でき、また動的システムドメインとともに使用できます。
動的再構成機能
Sun Enterprise サーバーの動的再構成機能では、プロセッサ、メモリー、入出力デバイスなどのハードウェア資源が含まれているシステムボードをユーザーが動的に追加または削除できます。メモリーを動的に再構成しても Solaris Resource Manager でのメモリー制限値検査には影響ありません。
Sun Bandwidth Allocator
Sun Bandwidth Allocator はアンバンドルパッケージです。Solaris カーネルとともに動作し、ネットワークの帯域幅の使用に対し制限を設定します。Sun Bandwidth Allocator は、いろいろなクラスの資源に適用される一種の資源管理ソフトウェアです。Solaris Resource Manager と Sun Bandwidth Allocator は、それぞれ性質の異なる別々の管理ドメインで使用します。Solaris Resource Manager はユーザーやアプリケーションの単位で動作しますが、Sun Bandwidth Allocator はポート、サービス、プロトコルの単位で管理します。
Solaris Resource Manager は、システムの他の多くのソフトウェア構成要素と関連していますが、それらに代わるものではありません。
Bandwidth Allocator はさまざまな種類の資源を管理します。
Solaris Resource Manager はシステム管理とシステム監視の機能を備えていますが、これは Sun Enterprise SyMONTM 2.0 でいう意味のシステム監視機能ではありません。
Solaris Resource Manager は本来の容量計画ツールでもありません。Solaris Resource Manager を使えば、管理者は簡単に容量の管理ができ、課金機能で作成された記録により使用量の傾向を分析できます。Solaris Resource Manager は従来の意味でいう容量計画は行いません。
Solaris Resource Manager はジョブスケジューラでもありません。ホストシステムでプロセスをどのように実行するかは制御しますが、いつどこで実行するかは制御しません。
Solaris Resource Manager は単一システムで動作するため、複数のクラスタメンバーの負荷バランスを調整する機構でもありません。しかし、Solaris Resource Manager を使えば、クラスタの各メンバーごとに作業負荷を効果的に管理できます。たとえば、高い可用度を持つクラスタのメンバーに障害があった場合、その作業の優先順位を予備メンバーで動作するバックグラウンドの作業負荷よりも高くすることができます。