例

この節では、Solaris Resource Manager の機能を使ってシステム資源や割り当てを制御したり、情報を表示したりする例を示します。

サーバーの統合

最初の例では、3 つのコマンドを使用します。

liminfo

ユーザーのパスワード属性と制限値の情報を端末ウィンドウに表示します。

limadm

一連のユーザーの制限属性を変更したり、リミットデータベースエントリを削除したりします。

srmadm

Solaris Resource Manager の動作モードやシステム全体で調整可能なパラメータを表示または設定します。

srmstat

l ノードの動作情報を表示します。

データベースアプリケーションがそれぞれ動作する 2 つのサーバーを 1 つのマシンに統合するとします。両方のシステムを単純に同じマシンで実行するだけでもシステムは機能します。Solaris Resource Manager がない場合、Solaris オペレーティングシステムは、資源を同等に使用するとみなしてアプリケーションに割り当てるため、あるアプリケーションが他のアプリケーションの要求と競合してもこれを保護しません。しかし、Solaris Resource Manager には、アプリケーション資源の枯渇を防ぐ機構があります。Solaris Resource Manager は、そのために、databases、db1 と db2 を参照する l ノードに接続してそれぞれのデータベースを起動します。このためには、3 つの管理専用ユーザーを新たに作成する必要があります。たとえば、これを databases、db1、db2 として、l ノードデータベースに追加します。l ノードは UNIX のユーザー ID に対応しているので、これらのユーザーを passwd ファイル (または、システムが NIS や NIS+ などのネームサービスを使用している場合には、パスワードマップ) にも追加する必要があります。ユーザー ID が passwd ファイルかパスワードマップに追加されているとして、管理専用ユーザー db1 と db2 を databases l ノードグループに割り当てるには、次のようにします。

#  limadm set sgroup=0 databases
#  limadm set sgroup=databases db1 db2

この場合、/usr/srm/bin がユーザーのパスにあるものとします。

図 9-1 サーバーの統合

この他に定義されているグループがないので、現在のところ databases グループがマシンをすべて使用します。databases に対応する 2 つの l ノードがすでに動作していて、データベースアプリケーションを実行するプロセスを適切な l ノードに接続するには、データベースインスタンス用の起動スクリプトの srmuser コマンドで次のようにします。

# srmuser db1 /usr/bin/database1/init.db1
# srmuser db2 /usr/bin/database2/init.db2

データベース db1 か db2 を起動したら、srmuser コマンドを使って、データベースが正しい l ノードに接続され、正しく負担させるようにします (srmuser はこれを実行するプロセスの所有権には影響を与えません)。上のコマンドを実行するには、init.db1 を実行するのに必要な UNIX 上のアクセス権と、プロセスを l ノード db1 に接続するための管理上のアクセス権が必要です。ユーザーがログインし、データベースを使用すると、データベースの動作は l ノード db1 と db2 で徐々に増加します。

各 l ノードに対しデフォルトの割当数 1 を使用することによって、databases グループ内の使用量が時間の経過とともに平均化し、databases、db1、および db2 に対するマシンの割り当てが等しくなります。具体的には、databases グループに対し割当数が 1 つあり、これを databases グループが所有しています。l ノード db1 と db2 にも、デフォルトの割り当てとしてそれぞれ 1 つの割当数が与えられます。databases グループには 2 つの割当数があるので、db1 と db2 は databases の資源から同じ割当数を得ます。この簡単な例では、割り当ての競合がないため、databases がシステム全体を使用します。

Database1 の動作にマシンの CPU 容量の 60 パーセントが必要であり、Database2 では容量の 20 パーセントが必要であるとします。システム管理者は、(アプリケーションが要求すれば) システムが少なくともこの量をそれぞれに割り当てるように指定できます。それには、次のようにして、db1 に割り当てる cpu.shares の数を増やします。

# limadm set cpu.shares=3 db1

これで databases グループの割当数は 4 つになりました。db1 に 3 つ、db2 に 1 つです。上のコマンドを実行すると、この変更が直ちに有効になります。Solaris Resource Manager は時間の経過とともに使用量を平均化しようとするので、l ノード db1 (Database1) に割り当てられる量が、実際には、ある期間に渡ってマシン資源が持つ権利の 60 パーセントを超えることがあります。しかし、減少大域パラメータによって異なりますが、これは長くは続きません。

任意の時点でこの動作を監視するには、別のウィンドウで liminfo (「一般的なアプリケーションサーバー」を参照) と srmstat コマンドを使用します。srmstat では、定期的に画面表示が更新されることに注意してください。srmstat の補足説明については、srmstat(1SRM) のマニュアルページを参照してください。

現在、マシンでは 2 つのデータベースアプリケーションが動作し、一方は資源の 75 パーセント、他方は 25 パーセントを受け取ります。root は一番上のグループヘッダーユーザーです。したがって、root として動作するプロセスは、要求すればシステム全体にアクセスできます。そのため、従来のように root プロセスがマシン全体を占有したりしないように、バックアップ、デーモンなどのスクリプトが動作する l ノードをさらに作成する必要があります。

数値計算用バッチアプリケーションを使用するユーザーの追加

この例では、次のコマンドを使用します。

srmkill

l ノードに接続されているすべての動作中のプロセスを強制終了する

財務部門がデータベースシステムを所有しているが、技術部門のユーザー (Joe) が計算バッチジョブを実行する必要があり、財務部門のシステムが空いている時間にこのマシンを使用したいと思っています。財務部門は、システムの主要なジョブを妨げない限り、Joe の仕事を実行してもよいことにし、Joe の仕事がデータベースよりも重要ではないと判断しました。このポリシーを設定するには、新しいグループ (batch) を l ノード database に追加し、Joe をサーバーの l ノード階層の新しい batch グループに追加します。

#  limadm set cpu.shares=20 databases
#  limadm set cpu.shares=1 batch
#  limadm set cpu.shares=1 joe
#  limadm set sgroup=batch joe

図 9-2 数値計算バッチアプリケーションの追加

このコマンドシーケンスによって与えられる割当数が変更され、databases グループが 20 の割当数、batch グループが 1 つの割当数を持ちます。つまり、batch グループのメンバー (Joe のみ) は、databases グループが動作中なら、最大でマシンの 1/21 を使用します。databases グループは、20/21 または 95.2% を受け取ります。データベース作業の処理には 60% + 20% = 80% があれば十分であると以前判断しましたが、この値はそれ以上です。databases が割り当てをすべて要求しなければ、Joe が自分の 4.8% よりも多い割り当てを得ます。databases が動作中でなければ、Joe の割り当てが 100% になることもあります。databases に割り当てられている割当数を 1 から 20 に増やす場合、db1 と db2 の割当数を変更する必要はありません。databases グループ内には、まだ 4 つの割当数が 3:1 の割合であります。スケジューリングツリーのそれぞれのレベルは完全に独立しています。重要なのは、ピアのグループ間の割当数の割合です。

このような保証をしたにもかかわらず、財務部門は、Joe が使用量の多い昼の時間にログインできないようにすることを望んでいます。そのためには、batch グループに対し何らかのログイン制御を行う必要があります。この制御は時刻に関係するので、特定の時間に batch グループのログインを許可するだけのスクリプトを実行します。 たとえば、この制御を行うには、次のような crontab エントリを使用します。

0 6 * * * /usr/srm/bin/limadm set flag.nologin=set batch 
0 18 * * * /usr/srm/bin/limadm set flag.nologin=clear batch

午前 6:00 では、batch はログインする許可を与えられていませんが、18:00 時 (午後 6 時) になると、この制限は解除されます。

さらに厳しいポリシーを導入する場合は、crontab エントリに次の行を追加します。

01 6 * * * /usr/srm/bin/srmkill joe

この場合、午前 6:01 に l ノード Joe に接続されているプロセスがあれば、srmkill(1MSRM) コマンドを使って終了させます。ジョブに必要な資源が Solaris Resource Manager が制御する資源だけであれば、これは必要ありません。このアクションは、通常の仕事を妨げるそれ以外の資源が Joe の作業で使用されるような場合には役立ちます。この例としては、キーデータベースロックを保持したり、入出力チャネルを占有したりするジョブがあげられます。

これで Joe は夜だけログインしてジョブを実行できます。Joe (と batch グループ全体) の割当数は他のアプリケーションよりもはるかに少ないため、Joe のアプリケーションはマシンの 5 パーセント未満で実行されます。これと同様に、nice(1) を使用すれば、このジョブに接続されるプロセスの優先順位を低くできます。それによって、このジョブは、Solaris Resource Manager の同じ割当数で動作する他のジョブよりも低い優先順位で実行されます。

この時点で、財務部門は、データベースアプリケーションがシステムを十分に使用でき、相互の仕事を妨げないようにできました。さらに、Joe の夜間バッチ処理の負荷を吸収する一方で、この仕事が部門の基幹業務処理を妨げないようにできました。

Web フロントエンドプロセスの追加

Web フロントエンドを Database1 に追加するとします。このアプリケーションで同時に処理できるユーザー数を 10 に制限します。これを行うには、プロセス制限値の機能を使用します。

まず、ws1 という l ノードを新たに作成します。ws1 l ノードの下で Web サーバーアプリケーションを起動すれば、このアプリケーションで使用できるプロセスの数 (動作中の http セッションの数) を制御できます。

図 9-3 Web フロントエンドプロセスの追加

Web サーバーは Database1 アプリケーションの一部なので、これに db1 l ノードの割当数を与え、Database1 と競争して資源を得るとします。ここでは、次のようにして、計算資源の 60 パーセントを Web サーバーに割り当て、40 パーセントを Database1 アプリケーション自身に割り当てます。

#  limadm set cpu.shares=6 ws1
#  limadm set sgroup=db1 ws1
#  limadm set cpu.myshares=4 db1
#  srmuser ws1 /etc/bin/Webserver1/init.webserver 

最後の行では、Web サーバーを起動し、アプリケーションを ws1 l ノードに負担させます。Database1 には、cpu.myshares を 4 として割り当てます。これによって、db1 がその子プロセス Web サーバーと競合する割当数の割合は 4:6 になります。

cpu.shares は階層内の同等レベルでの資源割り当ての割合ですが、cpu.myshares は、親が実行するアプリケーションが動作中であるときの親対子レベルにおける資源割り当ての割合です。Solaris Resource Manager は、それぞれのレベルにおけるすべての動作中の l ノードの割当数の割合に基づいて資源を割り当てます。「それぞれのレベル」には、グループの親とすべての子の my.shares が含まれます。

Web サーバーが実行できるプロセスの数を制御するには、プロセス制限を ws1 l ノードに設定します。この例では 20 を使用します。Web サーバー照会は一般に 2 つのプロセスを生成するので、動作中の Web サーバー照会の数は実際には 10 に制限されます。

# limadm set process.limit=20 ws1

これで、スケジューリングツリーの動作中の l ノードの下に、別のアプリケーションが葉ノードとして追加されました。CPU 資源を動作中の親と子の間で分配するには、cpu.myshares を使って、使用可能な資源のある部分を親に、他の部分を子に割り当てます。プロセス制限値は、l ノードに対する動作中のセッションの数を制限するときに使用します。

特別なメモリー要件を持つユーザーをさらに追加

この例では、資源制御の機構である CPU 割当率、プロセス制限値、およびログイン制御を示します。さらに、l ノードを出力し、動作中の l ノードを表示するための表示ツールを扱います。

srmadm

Solaris Resource Manager を管理します。

limreport

選択したユーザーの情報を出力します。

limdaemon

制限値に達したらメッセージを送信するようにデーモンに指示します。

もう 1 人のユーザー Sally が夜間にマシンを使用してアプリケーションを実行することを望んでいます。このアプリケーションは CPU をかなり使用するため、Joe のアプリケーションに影響を与えないためには、Sally の仮想メモリー使用量に対し、合計使用量と「プロセス当たり」使用量の観点から制限を設定する必要があります。

#  limadm set memory.limit=50M sally
#  limadm set memory.plimit=25M sally

図 9-4 ユーザーの追加

Sally のアプリケーションが仮想メモリーの合計制限値かプロセスメモリーの制限値を超えそうになると、limdaemon コマンドは、限度値を超過した旨をコンソールで Sally とシステム管理者に通知します。

システムで動作するユーザーと現在までの使用量を示すレポートを生成するには、limreport コマンドを使用します。limreport は、通常、ある時点でだれがマシンを使用していて、それがユーザー階層の中でどこに位置するのかを知るために使用します。

% limreport 'flag.real' - uid sgroup lname cpu.shares cpu.usage |sort +1n +0n

limreport にはいくつかのパラメータがあります。この例では、「flag.real」を検査し (実 l ノードまたはユーザー ID だけを探す)、次にダッシュ (-) を使い、出力書式のデフォルトとして最善と思われるものを使用するように指定します。「uid sgroup lname cpu.shares cpu.usage」のリストでは、「flag.real」が TRUE である l ノードごとに、これら 5 つのパラメータを出力するように limreport に指定します。出力では 2 つ目の列に対し UNIX の 1 次ソートを行い、最初の列に対し 2 次ソートを行なって、誰がサーバーを使用しているかが簡単にわかるようにします。

正しいパスとアクセス権を持つユーザーであれば、srmadm show コマンドを使って、いつでも Solaris Resource Manager の状態を検査できます。これによって、Solaris Resource Manager の現在の操作状態と主な構成パラメータが、書式化されたレポートとして出力されます。このレポートは、Solaris Resource Manager とすべての制御パラメータが動作中であるかどうかを検査するのに便利です。さらに、このレポートには、Solaris Resource Manager データストアの減少速度や場所など、大域パラメータの値が表示されます。

制限値や CPU スケジューリングを動作中にせずに Solaris Resource Manager を実行することができます。ただし、これらを動作中にしておくと、起動時に、デバッグや Solaris Resource Manager 製品の初期構成のために役立ちます。

# srmadm set share=n:limits=n

部門間でのマシンの共有

他の開発部門のグループが、システムが空いているときに使用できることを条件に、このマシンのアップグレード (プロセッサとメモリー) を購入しようとしています。これはどちらのグループにとっても利益になるはずです。この設定をするには、databases や batch と同じレベルに development というグループを新たに設定します。このグループは元のマシンの CPU 能力とメモリーを 50 パーセント増強したので、development にはマシンの 33 パーセントを割り当てます。

図 9-5 マシンの共有 (ステップ 1)

開発グループには数百人のユーザーがいます。これらのユーザーに対する資源の分配に関与しないためには、Solaris Resource Manager の管理フラグ機能を使って、開発のシステム管理者に資源の分配を任せます。それには、operations と development のレベルに、両者が合意した制限値を設定し、両者がマシンの各部分の制御に必要な作業をします。

階層に新しいレベルを追加するには、operations グループを新しい l ノードとして追加し、batch と databases の親グループを operations に変更します。

# limadm set sgroup=operations batch databases

管理フラグを設定するには、次のようにします。

# limadm set flag.admin=set operations development

通常の状況では、すべてのサーバーでデーモンとバックアップのプロセスを実行するので、別の高いレベルの l ノードにこれらを追加します。

root l ノードには制限値がないので、root は使用しないでください。

図 9-6 マシンの共有 (ステップ 2)

以上の例でわかるように、Solaris Resource Manager を使用すると、異なるタイプのユーザーやアプリケーションを同じマシンに統合できます。CPU 割当率の制御、仮想メモリーの制限値、プロセスの制限値、およびログイン制御をうまく使用することによって、多様なアプリケーションにそれらが必要とする資源を必要なだけ与えることができます。また、制限値によって、アプリケーションやユーザーが他のユーザーやユーザーグループのアプリケーションに悪影響を与えることを防止できます。Solaris Resource Manager 製品の簡潔なレポートツールでは、任意の時点や時間経過におけるシステムの状況をユーザーやシステム管理者が正確に把握できます。このレポート生成機能を使用すると、容量計画や課金のために、アプリケーションやグループ間における資源の使用状況を知ることができます。