第 9 章 高度な使用方法

この章では、システムにある多様なアプリケーションに優先順位を設定して管理する方法についてさらに検討します。これらの機能や Solaris Resource Manager ソフトウェアに関連した重要な概念を明らかにするために、例を示して説明します。この章の最後では、Sun Cluster 2.2 環境において Solaris Resource Manager を構成する方法を説明します。

バッチの作業負荷

業務処理をしているほとんどの現場では、バッチ処理を必要とします。バッチ処理は通常、日中のオンラインの作業負荷が軽減した後、夜間に実行されています。これには、2 つの理由があります。日中のトランザクションをレポートに出力するためと、バッチの作業負荷でオンラインの負荷に影響を与えないためです。

「例」では、バッチジョブを実行する環境を管理する階層を説明していますので参照してください。またこの節では、その過程で使用する Solaris Resource Manager コマンドについても説明しています。

バッチの作業負荷が使用する資源

バッチの作業負荷は、オンライントランザクション処理 (OLTP) と意思決定支援システム (DSS) の作業負荷を組み合わせたもので、システムに対するこれらの影響はこの 2 者の間のどこかになります。バッチの作業負荷には、データベースに対する多くの繰り返しトランザクションが含まれていて、それぞれが重い処理作業となる可能性があります。単純な例としては、1 日の売上げ計算があげられます。このような場合、バッチ処理は、データベースからその日の各販売トランザクションを検索して、売上げ金額を抽出し、合計の計算を実行していきます。

通常バッチ処理は、プロセッサと入出力の資源が大量に必要です。これはバッチ処理とデータベースが大量の CPU 資源を必要としており、また各トランザクションを検索するために、バックエンドデータベースで多数の入出力が発生するからです。

バッチの作業負荷は、CPU と入出力の使用率を制限することで効果的に制御します。Solaris Resource Manager では、CPU 資源を細かい設定で制御できますが、入出力資源については、各作業負荷に異なる入出力デバイスを割り当てて管理しなければなりません。

資源に対するバッチの影響を軽減するには、通常は次の 2 つの方法を実行します。

• 別個のシステムにデータベースのコピーを作成して、別々のシステムでバッチとレポートの作業負荷を実行する (ほとんどの場合、バッチ処理はオンラインデータベースの一部を更新するため、データベースとは分離できないことに注意してください)。

• CPU 資源の制御を使用する。

バッチの作業負荷で発生する入出力の量は、CPU の使用量と比例するため、CPU サイクルを制限すれば、バッチの作業負荷の入出力使用率を間接的に制御できます。ただし、非常に小さな CPU の要求しかない作業負荷で過度の入出力が発生しないように注意しなければなりません。

バッチ処理に関連した問題

定義では、バッチの作業負荷は制限を受けないで実行される作業負荷であり、最短の時間で処理を終了しようとします。バッチは最悪の資源消費者ということにもなりますが、これはシステムのボトルネック (通常は、システムでデータフローが最小となる時点) で処理が制限されるまで、必要な資源をすべて使おうとするからです。

システム管理者にとってバッチには次の 2 つの問題があります。同時に実行している他のバッチジョブに影響を及ぼすということと、営業時間にオンラインの作業負荷と一緒に実行できないということです。

たとえば、午前 0 時から午前 6 時までのオフタイムにバッチジョブを実行するようにスケジュールしたとしても、システムの問題や売り上げが特に増大した場合などに、バッチの作業負荷が営業時間にずれ込むことがあります。ダウンタイムほど状況は悪くありませんが、午前 10 時 30 分にバッチの作業負荷がまだ実行されている場合、オンラインのユーザーが 1 つのトランザクションで何分も待つことになり、最終的にはトランザクション数が減少する可能性があります。

資源の割り当てを使用することで、バッチの作業負荷で利用できる資源の量を制限し、制御可能な方法で作業負荷を抑制します。

統合

Solaris Resource Manager では、すべてのシステムにわたってシステム資源を割り当てることができ、場合によっては、部門ごとのマシン使用量を考慮して業務に合わせた割り当てを行います。「例」では、これを実行するために Solaris Resource Manager の階層を使用する方法を説明します。

データベース

Solaris Resource Manager 製品は、データベースの種類やその使用方法に応じて、複数のインスタンスでデータベース資源を管理するのに使用できます。

データベーストポロジー

通常データベースは、2n またはマルチスレッドサーバー (MTS) という 2 つのモードのどちらかで稼働しています。2n モードの場合、データベースの各ユーザーのために、個別のプロセスが存在します。マルチスレッドモードの場合、単一プロセスが多くのユーザーにサービスを提供します。マルチスレッドの単一プロセスとして実行されるデータベース、たとえば Oracle MTS のようなデータベースを管理する場合、Solaris Resource Manager を使用することはできません。

上記の例では UID=oracle となっており、全ユーザーが同じユーザー ID に対して CPU を使用しているため、データベースレベルの場合に限って、Solaris Resource Manager で MTS モードのデータベースを制御できます。Solaris Resource Manager を使用して MTS データベースを統合できますが、データベース内でユーザーについては細かく制御できません。

Oracle 8i のようなデータベースには、照会またはユーザー単位で CPU の割り当てを制限するなどの資源の制御機能があります。この場合、資源の管理ポリシーと管理は、Solaris Resource Manager とは独立しており、別のツールセットで保守する必要があります。

2n モードで稼働しているデータベース資源は、はるかに簡単に管理できます。同一ユーザーとしてデータベースのすべての処理を実行するのではなく、各ユーザーは異なるユーザー ID に対して処理を実行しています。

各ユーザーのために個別にプロセスを使用し、階層では各ユーザーに固有の l ノードが割り当てられているため、通常 2n モードでは Solaris Resource Manager を使用できます。

Solaris Resource Manager における 2n モード の Oracle

Oracle は 2n データベースの資源管理の実行方法を説明する格好の例です。2n モードの Oracle では、データベースに接続する各ユーザーに対して、「Oracle シャドウプロセス」という別のプロセスを生成します。このシャドウプロセスは、中央共有メモリー資源に接続して、データベースファイルに対して直接入出力処理を実行します。たとえ Oracle シャドウプロセスが setuid を設定した Oracle プロセスであっても、これらのプロセスは Solaris Resource Manager の別の l ノードには接続しません。これは、ログイン時に setuid() システムコールによって l ノードに接続しているため、ターゲットプログラムが setuid() を呼び出さない限り、setuid() プログラムの実行時に l ノードが変更されないからです。

次の図では、2n モードの Oracle が Solaris Resource Manager を使用する方法について説明します。

2n モード Oracle のクライアントサーバーモード

クライアントサーバーモードの場合、Oracle ネットワークリスナーという補足的なプロセスがログイン手順に含まれ、これが原因となって、ユーザーコンテキスト情報を消失する場合があります。ネットワークリスナーはクライアントマシンからの接続を受け入れ、ユーザーのために Oracle シャドウプロセスを起動します。

Oracle リスナーによってシャドウプロセスを正しい l ノードに接続させるには、多少カスタマイズが必要な場合があります。

仮想メモリーとデータベース

Solaris Resource Manager 製品では、ユーザーと作業負荷が使用する仮想メモリー量を制限する機能を提供しています。この機能は物理メモリーを管理するのではなく、各ユーザーが使用する広域的なスワップ空間の容量を効果的に制限します。

ユーザーまたは作業負荷が l ノードの仮想メモリー制限値に達すると、システムはアプリケーションにメモリー割当エラーを返します。つまり、malloc() の呼び出しが失敗します。このエラーコードは、スワップ空間が不足しているかのようにアプリケーションに報告されます。

メモリー割当エラーに十分に対処できるアプリケーションはほとんどありません。したがって、データベースサーバーが仮想メモリー制限値に達するのを放置するのは危険です。制限値に達した場合、データベースエンジンがクラッシュして、データベースが壊れる可能性があります。

仮想メモリー制限値は、通常の状況ではその値に達しないように、高く設定しなければなりません。また、仮想メモリー制限値を使用して、データベースサーバー全体に上限を設定できますが、こうすることで、メモリーリークをともなう障害を起こしたデータベースがシステム上の他のデータベースや作業負荷に影響を与えるのを防止できます。

NFS の管理

NFS^TM は Sun の分散コンピューティング環境ですが、カーネルスレッドとして実行され、カーネルスケジューリングクラス SYS を使用します。NFS のスケジューリング割り当ては Solaris Resource Manager SHR クラスで管理していないため、NFS の CPU 資源は制御できません。NFS サービスをよく使用するシステムでは、プロセッサ資源を割り当てる Solaris Resource Manager 製品の機能が発揮できない可能性があります。

しかし、ネットワークポートの資源管理で NFS を制御できます。たとえば、サーバー上の NFS パケット数を制御するために、Sun Bandwidth Allocator を使用できます。また場合によっては、システムクラスで使用可能な CPU 数を制限するプロセッサセットによって、NFS を管理することができます。

Web サーバーの管理

Solaris Resource Manager ソフトウェアは、CPU と仮想メモリーの使用量を管理することで、Web サーバー上の資源を管理できます。Web サーバーを実行するシステムでは、3 つの基本的なトポロジーを使用できます。

統合 Web サーバーの資源管理

Web サーバー全体で使用できる資源の量を制御することで、単一の Web サーバーを管理できます。Web サーバーが他の作業負荷と統合されている環境では、この方法が役立ちます。これは最も基本的な資源管理の方法であり、他の作業負荷が Web サーバーの性能に影響を与えず、逆の場合も同様です。たとえば、Web サーバーの CGI スクリプトがメモリーリークを発生して制御不能になった場合、システム全体でスワップ空間が不足するのではなく、Web サーバーだけに影響が出ます。

この例の Web サーバーには割当数 20 を指定していますが、これは、データベースでプロセッサへの要求が過度に大きくなった場合、プロセッサ資源の最低 20 パーセントを保証することを意味しています。

補足的な Web サーバーの例については、「Web フロントエンドプロセスの追加」を参照してください。

単一 Web サーバーにおける詳細な資源管理

単一 Web サーバー内で資源管理を使用して動作を制御するには、いくつか条件が必要なことがあります。たとえば、単一 Web サーバーは、それぞれが独自の cgi-bin プログラムを持つ多くのユーザーで共有されることがあります。

この場合に cgi-bin プログラムの 1 つでエラーが発生すると、Web サーバー全体で処理が遅くなることがあります。メモリーリークが発生した場合、Web サーバーがダウンする可能性さえあります。これを防ぐには、プロセス単位の制限が必要です。

複数の仮想 Web サーバーの資源管理

複数の仮想 Web サーバーを実行するのに、統合した形で単一マシンを使用することがあります。このような場合、 httpd Web サーバープロセスのインスタンスが複数存在しているため、Solaris Resource Manager で資源を管理する必要性がもっとも高まります。

Web サーバー構成ファイルでパラメータを設定することで、異なる UNIX ユーザー ID で各 Web サーバーを実行させることができます。こうすることで、各 Web サーバーは、Solaris Resource Manager 階層にある異なる l ノードに効果的に接続されます。

たとえば、Sun WebServer^TM の場合、構成ファイル /etc/http/httpd.conf に次のようなパラメータが設定されます。

# Server parameters
 server  {
   server_root                   "/var/http/"
   server_user                   "webserver1"
   mime_file                     "/etc/http/mime.types"
   mime_default_type             text/nlain
   acl_enable                    "yes"
   acl_file                      "/etc/http/access.acl"
   acl_delegate_depth            3
   cache_enable                  "yes"
   cache_small_file_cache_size   8                       # megabytes
   cache_large_file_cache_size   256                     # megabytes
   cache_max_file_size           1                       # megabytes
   cache_verification_time       10                      # seconds
   comment                       "Sun WebServer Default Configuration"
 
   # The following are the server wide aliases
 
   map   /cgi-bin/               /var/http/cgi-bin/              cgi
   map   /sws-icons/             /var/http/demo/sws-icons/
   map   /admin/                 /usr/http/admin/
 
 # To enable viewing of server stats via command line,
 # uncomment the following line
   map   /sws-stats              dummy                           stats
 }

各 Web サーバーを異なる UNIX ユーザー ID で実行するように構成することで、各 Web サーバーに個別に制限値を設定できます。多くの Web サーバーを実行しているマシンの場合、この方法は資源利用の制御と課金の両面でとても役立ちます。

このような場合、Solaris Resource Manager の資源制御と制限機能のほとんど、あるいはすべてを活用できます。

Shares [cpu.shares]

cpu.shares を使用していろいろな Web サーバーに特定の比率で資源を割り当てることができます。

Mem limit [memory.limit]

memory.limit を使用して、Web サーバーが使用する仮想メモリーの容量を制限できますが、これによって、ある Web サーバーが原因で、他の Web サーバーがメモリー割当による障害を発生することがなくなります。

Proc mem limit [memory.plimit]

プロセス単位のメモリー制限によって、1 つの cgi-bin プロセスが使用する仮想メモリーの容量を制限できます。これによって、cgi-bin プロセスが Web サーバーを停止させることを防止します。

Process limit [process.limit]

Web サーバーに接続できるプロセスの最大数を指定することで、同時に実行できる cgi-bin プロセスの数を効果的に制限します。

プロセッサセットの役割と効果

Solaris Resource Manager ソフトウェアを使用中でも、プロセッサセットは依然として資源の割り当てに大きな役割を果たしています。システムが資源ポリシーに強い制限値を適用しなければならない場合があります。たとえば、24 プロセッサの単一システムを購入して、この同一マシンに異なる 2 つの部門を含むような場合です。両部門はマシンのコストを折半しており、たとえば、40 パーセントと 60 パーセントという割合で負担します。この場合、管理者は 40 パーセントの負担をしている部門には、資源の割当率も 40 パーセントにとどめておこうと考えるでしょう。

プロセッサセットがある場合、40 パーセントの部門に 10 プロセッサを割り当て、60 パーセントの部門に 14 プロセッサを割り当てれば、作業負荷を 40 パーセントと 60 パーセントに分けることができます。

プロセッサセットで Solaris Resource Manager 製品を使用する場合、この 2 つの技術の相互作用について理解することが重要です。状況によっては、全体的な結果が期待に反することもあります。

単純な例

次の図では、Solaris Resource Manager とプロセッサセットの単純な組み合わせを示します。この例では、プロセッサセットと Solaris Resource Manager の CPU 割当数の両方を図示しています。

ユーザー 1 は Solaris Resource Manager の割当数が 25 で、利用できるのがプロセッサセット A (1 CPU) に制限されています。ユーザー 2 は Solaris Resource Manager の割当数が 75 で、プロセッサセット B (1 CPU) に制限されています。

この例では、ユーザー 2 が割り当てられたプロセッサセット全体 (システムの 50 パーセント) を使用することになります。ユーザー 2 は (割り当てられた 75 パーセントではなく) 50 パーセントしか使用しないため、ユーザー 1 は残りの 50 パーセントを使用できます。つまり、それぞれのユーザーがシステムの 50 パーセントを与えられたことになります。

より複雑な例

次の例では、プロセッサセットと Solaris Resource Manager CPU 割当数を組み合わせたより複雑な場合を説明します。

ユーザー 1 と 3 は、Solaris Resource Manager の割当数がそれぞれ 10 となっており、その使用がプロセッサセット A (1 CPU) に制限されています。ユーザー 2 は Solaris Resource Manager の割当数が 80 となっており、プロセッサセット B (1 CPU) に制限されています。

この例では、ユーザー 2 がプロセッサセット全体 (システムの 50 パーセント) を使用することになります。ユーザー 2 は (割り当てられた 80 パーセントではなく) 50 パーセントしか使用していないので、ユーザー 1 と 3 は残りの 50 パーセントを使用することができます。つまり、ユーザー 1 と 3 は 10 の割当数しか指定されていませんが、システムの 25 パーセントを使用できることになります。

回避すべき状況

次のような状況は回避しなければなりません。

この場合では、1 人のユーザーが両方のプロセッサセットでプロセスを実行します。ユーザー 1 は Solaris Resource Manager の割当数が 20 で、両方のプロセッサセットで処理を実行します。ユーザー 2 は Solaris Resource Manager の割当数が 80 で、その使用がプロセッサセット B (1 CPU) に制限されています。

ユーザー 1 の最初の処理が割り当てられたプロセッサセット全体 (システムの 50 パーセント) を使用します。ユーザー 2 は割当数が 80 であるため、ユーザー 2 の処理はプロセッサセット全体 (50 パーセント) を使用することになります。したがって、ユーザー 1 の第 2 の処理には CPU の割当が与えられません。

例

この節では、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 製品の簡潔なレポートツールでは、任意の時点や時間経過におけるシステムの状況をユーザーやシステム管理者が正確に把握できます。このレポート生成機能を使用すると、容量計画や課金のために、アプリケーションやグループ間における資源の使用状況を知ることができます。

一般的なアプリケーションサーバー

前節の終わりで db1 に対し次のような liminfo を実行すると、下記の出力が得られます。

# liminfo db1

図 9-7 liminfo のリスト

この節の後半では、図 9-7 で作成した liminfo の出力について説明します。次のフィールドの詳細は、liminfo(1SRM) または srm(5SRM) のマニュアルページを参照してください。

• liminfo コマンドで出力される最初の 2 行は、l ノードユーザー ID と l ノードツリーにおけるその位置に関連する事柄を表わしています。

Login name

接続した l ノードのユーザー ID に対応するパスワードマップからのログイン名と初期グループ ID です。どの l ノードもシステムユーザー ID に対応付けられています。各 l ノードのユーザー ID にはシステムアカウントをできるだけ作成してください。ここでは、db1 の Database1 に管理専用ユーザー ID が使用されています。

Solaris Resource Manager の下のデフォルトの PAM 構成では、l ノードを持たないユーザーがログインすると l ノードを作成します。デフォルトでは、スーパーユーザーや、uselimadm フラグが設定されたユーザーが作成する l ノードは、ユーザー other の l ノードを親として作成されるか、これがない場合は、root l ノードを親として作成されます。管理フラグが設定されたユーザーが作成する l ノードは、そのユーザーを親として作成されます。l ノードの親を変更するには、l ノード属性を変更する limadm コマンドを使用します。

Uid

現在のプロセスに接続されている l ノードのユーザー ID です。通常、これは、そのプロセスの実ユーザー ID (ログインしたユーザー) と同じですが、状況によっては異なる場合があります。これについては、あとで説明します。

Gid

現在のプロセスに接続された l ノードのグループ ID です。

R,Euid and R,Egid

現在のプロセスの実ユーザー ID および実効ユーザー ID と実グループ ID および実効グループ ID です。これは、標準のシステムコマンド id(1M) で得られる情報と同じです。この情報は、厳密にいえば Solaris Resource Manager とは関係ありませんが、参考のために表示されます。これらのフィールドは、liminfo によって、デフォルト以外のユーザー (ログイン名かユーザー ID が引数として指定されている) の情報を表示するときには表示されません。

Sgroup (uid) [sgroup]

l ノードツリー階層における親 l ノードの名前とユーザー ID です。root l ノードの場合は空白です。Solaris Resource Manager の多くの機能は、l ノードがツリー階層のどこにあるかに依存します。したがって、親 l ノードを順番にツリーのルートまでたどることは意味があります。

• 空白行に続き、liminfo で表示される次の 3 行は、CPU スケジューリングに関するフィールドです。

Shares [cpu.shares]

当該ユーザーに割り当てられている CPU の使用権利の割当数です。これは、同じ親 l ノードを持つ他のユーザーや親 l ノード自体の「自割当数」値に対してのみ直接比較できます。通常、管理者は、特定のスケジューリンググループ内のすべてのユーザーの割当数を同じ値に設定します (これらのユーザーに同等の権利を与えます)。通常、この値には 1 より大きい値を設定し、必要なときには管理者が特定のユーザーの割当数を減らします。

Myshares [cpu.myshares]

この値は、当該ユーザーが動作中の (プロセスが接続されている) 子 l ノード (このユーザーの sgroup 値を持つ l ノードが他にある) を持っているときだけ使用されます。該当する場合には、この値は、この l ノードの子 l ノードに接続されているプロセスと比較した、この l ノードに接続されているプロセスの相対 CPU 割当率を示します。

Share

現在のユーザーが権利を持つシステム CPU 資源の割合を計算した割当率です。この計算には動作中のユーザーだけが含まれるため、他のユーザーがログインまたはログアウトするたびに、あるいは l ノードが動作中または非動作中になるたびに、この値は変わります。この計算には、現在のユーザーによる最近の使用量は含まれません。

E-share

当該ユーザーの実効割当率です。つまり、このユーザーが割当数を要求し、他のすべての動作中のユーザーも要求しているときに、このユーザーに短期的に与えられるシステム CPU 資源の実際の割合です。これは、Solaris Resource Manager が現在この l ノードにこれだけの CPU 資源を割り当てる予定であることを示します。この値は、ユーザーが CPU 資源を使用したり使用をやめたりすることで時間とともに変わります。l ノードが動作中であってもアイドル状態 (つまり、接続されているプロセスがスリープ状態) のため、使用量が少ない場合は、その l ノードに大きな実効割当率が与えられます。その結果、CPU を活発に使用するプロセスが接続されているユーザーには、非常に小さな実効割当率が与えられることがあります。

Usage [cpu.usage]

スケジューリングの優先順位を決めるときに使用されるシステム資源の累積使用量です。通常、この値は最近の CPU 使用量を表わしますが、他のパラメータが考慮に入れられることがあります。使用されているパラメータの組み合わせは、srmadm コマンドで参照できます。この値に対する各増分は時間とともに指数的に減少するので、Solaris Resource Manager はいずれこの資源使用量を無視します。この減少速度は半減期で表わすのが最も簡単です。これは、srmadm コマンドで参照できます。

Accrued usage [cpu.accrue]

これは「cpu.usage」と同じように資源の累積を表わしますが、減少しません。Solaris Resource Manager がこれを直接使用することはありませんが、管理者が課金の目的で使用することができます。Usage とは異なり、この値は、現在の l ノードだけでなく、グループのすべての l ノードの使用量の合計を表わします。

• 2 つ目の空白行に続き、liminfo で表示される次の 4 行は、仮想メモリーと端末の使用に関するフィールドです。

Mem usage [memory.usage][memory.myusage]

この l ノードに接続されているすべてのプロセスの合計メモリー使用量です。

2 つの値がスラッシュ (/) で区切られて表示されている場合は、この l ノードがグループヘッダーであることを示しています。最初の値がスケジューリンググループ全体の使用量で、2 つ目の値が現在のユーザーだけの使用量です。

Mem limit [memory.limit]

この l ノードとそのメンバー (存在する場合) に接続されたすべてのプロセスに許される最大のメモリー使用量です。つまり、グループ内のすべてのプロセスとグループヘッダーに接続されたすべてのプロセスの合計メモリー使用量がこの値を超えることはできません。この例の場合の「0」値は制限がないことを示します。

Proc mem limit [memory.plimit]

プロセス当たりのメモリー制限値は、この l ノードやそのメンバーに接続された 1 つのプロセスに許される最大のメモリー使用量です。

Mem accrue [memory.accrue]

memory.accrue 量はバイト秒で測定されたもので、ある期間に使用されたメモリー資源全体を表わします。

Term usage [terminal.usage]

現在グループに負担させている接続時間の秒数です。

Term accrue [terminal.accrue]

グループが使用している接続時間の秒数です。

Term limit [terminal.limit]

terminal.usage 属性の最大許容値です。この値が 0 である場合、継承によって制限を受けない限り、制限がないことになります。

• 3 つ目の空白行に続き、liminfo で表示される残りの 2 行は、ユーザーとプロセスに関するフィールドです。

Processes [process.usage][process.myusage]

この l ノードに接続されているプロセスの数です。これはプロセスだけの数で、プロセス内のスレッドは入っていません。

2 つの値がスラッシュ (/) で区切られて表示されている場合は、この l ノードがグループヘッダーであることを示しています。最初の値がスケジューリンググループ全体の使用量で、2 つ目の値が現在のユーザーだけの使用量です。

Process limit [process.limit]

この l ノードとそのメンバーに接続できるプロセス最大合計数です。

Current logins [logins]

当該ユーザーの Solaris Resource Manager で現在並行してログインしているセッションの数です。ユーザーが標準のシステムログイン機構 (login(1)、rlogin(1)、基本的に PAM を使って認証を行い、utmp(4) エントリを作成するもの) のどれかを使ってログインすると、このカウンタが増加します。セッションが終了すると、カウンタが減少します。

flag.onelogin フラグが設定されていると、ユーザーは、1 つの Solaris Resource Manager ログインセッションしか持てません。

• 4 つ目の空白行に続き、liminfo の次の 4 行には次のフィールドが表示されます。

Last used [lastused]

最後に l ノードが動作中になっていた時間を示します。通常、ユーザーが最後にログアウトした時間です。

Directory

ユーザーのホームディレクトリです。便宜上、Solaris Resource Manager の項目ではなく、パスワードマップの項目が示されます。

Name

db1 (finger) 情報。通常、これはユーザー名です。便宜上、Solaris Resource Manager の項目ではなく、パスワードマップの項目が示されます。

Shell

ユーザーの最初のログインシェルです。便宜上、Solaris Resource Manager の項目ではなく、パスワードマップの項目が示されます。

• 5 つ目の空白行に続き、liminfo の最終行にこのフィールドが表示されます。

Flags

評価され設定されたフラグ、または l ノードのグループがここに表示されます。各フラグのあとには値と、フラグがどのように設定されたかが示されます。たとえば、この l ノードから明示的に設定された場合は (+)、継承された場合は (^) が表示されます。

Sun Cluster 2.2 環境における Solaris Resource Manager の構成

有効なトポロジ

Sun Cluster の有効なトポロジで、2 ノードまたはそれ以上のクラスタに、Solaris Resource Manager をインストールできます。有効なトポロジには次のようなものがありますが、これらに限定される訳ではありません。

• 対称 - 2 つのノードを同一に構成します。通常の状況では、両者がデータサービスを提供します。

• 非対称 - 2 ノードの構成ですが、一方のノードが他方のノードのホットスタンバイとして機能します。

• N+1 (星形） - 2 つ以上のノードで構成します。1 つのノードが他方のスタンバイとして機能します。

• N to N (スケーラブル) - すべてのサーバーが共有ディスクセットに直接接続されます。データサーバーは、他のどのサーバーにでもフェイルオーバーできます。

これらのトポロジは、docs.sun.com にある『Sun Cluster 2.2 ソフトウェアのインストール』の第 1 章で詳細に説明しています。

要件の決定

Sun Cluster 環境で Solaris Resource Manager を構成する前に、スイッチオーバーやフェイルオーバーにおいて、資源の制御と追跡管理をどのように実行するかを決定しなければなりません。すべてのクラスタノードを同じように構成すると、使用制限が主ノードとバックアップノードで同等に適用されます。

全ノードの構成ファイルにおいて、アプリケーションの構成パラメータをすべて同じにする必要はありませんが、最低でもマスターになる可能性があるノードでは、構成ファイルにアプリケーションのすべてを指定しなければなりません。たとえば、アプリケーション 1 は phys-host1 で実行しますが、phys-host2 や phys-host3 にスイッチオーバーやフェイルオーバーされる可能性がある場合、アプリケーション 1 は、この 3 つの全ノード (phys-host1、phys-host2、および phys-host3) の構成ファイルに指定しなければなりません。

Solaris Resource Manager は、使用量や総使用量のパラメータを構成するという点では非常に柔軟性があり、Sun Cluster により受ける制約もほとんどありません。構成上の選択は、サイトの条件によって決まります。システムを構成する前に、次の節で説明する一般的なガイドラインを参考にしてください。

メモリー制限値パラメータの設定

Sun Cluster で Solaris Resource Manager を使用する場合は、アプリケーションの不要なフェイルオーバーやピンポン現象を予防するため、メモリー制限値を適切に設定しなければなりません。通常は、次のガイドラインに従ってください。

• メモリー制限値をあまり低く設定しないでください。アプリケーションがメモリー制限値に達した場合、フェイルオーバーとなります。仮想メモリー制限値に達すると、予期せぬ結果となるため、とくにデータベースアプリケーションの場合に重要です。

• 主ノードとバックアップノードでは、同じメモリー制限値に設定しないでください。アプリケーションがメモリー制限値に達した時に、同じメモリー制限値を指定したバックアップノードにフェイルオーバーすると、ピンポン現象が発生します。バックアップノードでは、少しでも高くメモリー制限値を設定してください (高くする値の程度は、サイトのアプリケーション、資源、方針などによって決まります)。こうすると、ピンポン現象を予防して、システム管理者はパラメータの調整を行うのに必要な時間を確保できます。

• 負荷均衡など、設定の細かくない問題解決に、Solaris Resource Manager のメモリー制限値を使用してください。たとえば、欠陥のあるアプリケーションが過剰な資源を使用するのを予防します。

総使用量パラメータの使用

CPU 割当数、ログイン数、接続時間など、システム資源の総使用量を追跡するのに、Solaris Resource Manager のいろいろなパラメータを使用できます。ただし、特に指定しない限り、スイッチオーバーやフェイルオーバーが発生した場合、スイッチオーバーまたはフェイルオーバーされた全アプリケーションの総使用量データ (CPU 使用量、ログイン数、接続時間) は、新しいマスターノードで 0 から記録が再開されます。総使用量のデータは、ノード間で動的に移動されることはありません。Solaris Resource Manager の総使用量レポート機能の正確性を維持するために、総使用量の情報をクラスタノードから収集するスクリプトを作成できます。総使用量のデータを収集する際、どのマスターでアプリケーションが実行されるか分からないため、このスクリプトでは、アプリケーションの全マスターでの総使用量のデータを収集しなければなりません。詳細については、第 8 章「使用量データ」を参照してください。

フェイルオーバーの場合

Sun Cluster の場合、リミットデータベース (/var/srm/srmDB) に記述した資源割り当ての方法が、通常のクラスタ環境でも、あるいはスイッチオーバーやフェイルオーバーの場合でも同じになるように、Solaris Resource Manager を構成することができます。

次の例を考えてください。

2 つのアプリケーションがある 2 ノードクラスタ

2 つの物理ホストがそれぞれ特定のアプリケーションのデフォルトマスターとなるように、2 ノードクラスタで 2 つのアプリケーションを設定できます。どちらの物理ホストも、他方の物理ホストのバックアップノードとなります。両ノードの Solaris Resource Manager リミットデータベースファイルに、両方のアプリケーションを指定しなければなりません。クラスタが正常に動作している場合、各アプリケーションは自らのデフォルトマスターで実行され、このマスターですべての割当数が与えられます (Solaris Resource Manager は利用できる全資源を割り当てるからです)。フェイルオーバーやスイッチオーバーが発生した場合、両方のアプリケーションは 1 つのノードで実行されることになり、構成ファイルに指定した割当数で資源が与えられます。たとえば、この例の構成ファイルでは、同じノードで両方のアプリケーションを実行する場合、アプリケーション 1 には 80 の割当数、アプリケーション 2 には 20 の割当数を与えると指定しています。

# limadm set cpu.shares=80 app1
# limadm set cpu.shares=20 app2
... 

次の図では、この構成における正常な処理とフェイルオーバー処理を示します。

3 つのアプリケーションがある 2 ノードクラスタ

3 つのアプリケーションがある 2 ノードクラスタの場合、第 1 の物理ホスト (phys-host1) を 1 つのアプリケーションのデフォルトマスターとし、第 2 の物理ホスト (phys-host2) を残る 2 つのアプリケーションのデフォルトマスターとするように構成できます。次の例のリミットデータベースファイルを各ノードで使用し、フェイルオーバーやスイッチオーバーが発生しても、リミットデータベースファイルは変わらないものとします。

# limadm set cpu.shares=50	 app1
# limadm set cpu.shares=30	 app2
# limadm set cpu.shares=20	 app3
...

クラスタが正常に動作している場合、アプリケーション 1 にはデフォルトマスター phys-host1 で利用できる割当数がすべて与えられます。アプリケーション 2 と 3 には、デフォルトマスター phys-host2 でそれぞれ 60 と 40 の割当数が与えられますが、これは利用できる全資源の中で適切な割合が各アプリケーションに適用されているからです。フェイルオーバーまたはスイッチオーバーが発生して、アプリケーション 1 が phys-host2 にスイッチオーバーした場合、3 つのアプリケーションの割当数はリミットデータベースファイルに従って再割り当てされ、アプリケーション 1 は 50、アプリケーション 2 は 30、アプリケーション 3 は 20 の割当数となります。

次の図では、この構成における正常な処理とフェイルオーバー処理を示します。

論理ホストだけのフェイルオーバー

複数の論理ホストが同一のデフォルトマスターを持っている構成の場合、デフォルトマスターを停止させずにクラスタ内で動作させたまま、論理ホスト (および関連アプリケーション) だけをバックアップノードにフェイルオーバーまたはスイッチオーバーさせることができます。このような場合、スイッチオーバーやフェイルオーバーが発生したアプリケーションには、バックアップノードの構成ファイルに指定したとおりに資源が割り当てられます。この処理は、2 ノードクラスタで説明した処理と同じです。

次の図では、この構成における正常な処理とフェイルオーバー処理を示します。