test

Sun N1 Grid Engine 6.1 管理ガイド

消費可能リソース

消費可能リソースは、使用可能なメモリー、ファイルシステム上の空き容量、ネットワーク帯域幅、浮動ソフトウェアライセンスなど、制限のあるリソースを管理するための効率的な手段になります。消費可能リソースはコンシューマブルとも呼ばれます。コンシューマブルの使用可能な総量は、管理者によって定義されます。対応するリソースの消費は、Grid Engine ソフトウェア内部のブックキーピングにより監視されます。Grid Engine システムは、すべての実行中のジョブに関してこのリソースの消費を把握します。ジョブが振り分けられるのは、内部のブックキーピングにより十分な消費可能リソースが使用可能であることが示された場合のみです。

コンシューマブルは、デフォルトの負荷パラメータや、ユーザー定義の負荷パラメータと結び付けることができます。消費可能属性に対しては、負荷値を報告できます。逆に、負荷属性に対しては Consumable フラグを設定できます。負荷は、リソースの可用性の測定値になります。消費可能リソースの管理では、負荷と、内部のブックキーピングの両方が考慮され、両方とも指定の制限を超えません。負荷パラメータの詳細については、「負荷パラメータ」を参照してください。

消費可能リソースの管理を有効にするには、リソースの総量を定義する必要があります。リソースの容量の定義は、指定したホスト、および指定したキューに対してだけでなく、クラスタに対してグローバルに行うことができます。これらのカテゴリは、列挙したのとは逆の順序で別のカテゴリに優先することができます。したがって、ホストがグローバルリソースの可用性を制限し、キューがホストリソースとグローバルリソースを制限することも可能です。

リソースの容量を定義するには、キューおよびホストの構成で complex_values 属性を使用します。global ホストの complex_values 定義が、グローバルクラスタのコンシューマブルの設定を定義します。詳細については、host_conf(5) および queue_conf(5) のマニュアルページだけでなく、「キューの構成」および 「ホストの構成」も参照してください。

complex_values リスト内の各消費可能属性に対して、そのリソースの使用可能な最大量を示す値が割り当てられます。内部のブックキーピングは、この合計から、(ジョブのリソース要求によって表現された) すべての実行中のジョブによる推定のリソース消費量を差し引きます。

並列ジョブは、ジョブスロットを消費するのと同じ数だけ消費可能リソースを消費します。たとえば、次のコマンドは合計 800M バイトのメモリーを消費します。


qsub -l mem=100M -pe make=8

メモリーの使用は、ジョブが実行されるキューとホストに分割されます。ホスト A で 4 つのタスクが実行され、ホスト B で 4 つのタスクが実行されている場合、そのジョブは各ホストで 400M バイトを消費します。

消費可能リソースの設定

コンシューマブルとしては数値属性のみが構成可能です。数値属性とは、その型が INT、DOUBLE、 MEMORY、または TIME である属性です。

「QMON Main Control」ウィンドウで「Complex Configuration」ボタンをクリックします。図 3–1 に示すように、「Complex Configuration」ダイアログボックスが表示されます。

属性に関するコンシューマブルの管理を使用可能にするには、コンプレックス構成の属性に対して Consumable フラグを設定します。たとえば次の図は、virtual_free メモリーリソースに対して Consumable フラグが設定されていることを示します。

図 3–2 「Complex Configuration」ダイアログボックス: virtual_free

次の各節で詳細が説明されている例をガイドとして、そのほかの消費可能リソースを設定します。

続いて、Grid Engine ソフトウェアに必要な容量計画を実行させる対象の各キューまたはホストに対して、complex_values リストで容量を定義する必要があります。次の図に示す例では、1G バイトの仮想記憶が現在のホストの容量値として定義されています。

図 3–3 Add/Modify Exec Host: virtual_free

そのホスト上のすべてのキューで並行して実行中のすべてのジョブの仮想記憶の要件は、累積されます。続いて使用可能な仮想記憶を決定するため、 1G バイトの容量から要件が差し引かれます。virtual_free に対するジョブ要求が使用可能な量を超える場合、ジョブはそのホスト上のキューに対して振り分けられません。

注 –

Requestable パラメータの FORCED 値を介して、リソースを要求し、仮定の消費量を指定するよう、ジョブを強制することができます。

ジョブによって明示的には要求されていない消費可能属性に関しては、管理者はリソース消費量に対してデフォルト値を事前に定義できます。このような作業に意味があるのは、前の注で説明したように、属性の要求が強制されていない場合のみです。デフォルト値として 200M バイトが設定されています。

消費可能リソースの設定の例

サイトに対して消費可能リソースを設定する場合は、次の例をガイドとして使用してください。

例 1: 浮動ソフトウェアライセンスの管理

クラスタでソフトウェアパッケージ pam-crash を使用し、10 個の浮動ライセンスへのアクセス権があると仮定します。ソフトウェアのアクティブな呼び出しが 10 を超えないかぎり、あらゆるシステムで pam-crash を使用できます。目標は、実行中のそのほかの pam-crash ジョブによって 10 個のライセンスがすべて占有される間は pam-crash ジョブのスケジューリングを避けるように Grid Engine システムを構成することです。

消費可能リソースを使用すると、この目標を簡単に達成できます。まず、グローバル消費可能リソースとして、使用可能な pam-crash ライセンスの数を、コンプレックス構成に追加する必要があります。

消費可能属性の名前は pam-crash に設定されています。その代わりに、qalter -l、 qselect -l、qsh -l、qstat -l、または qsub -l コマンドで、ショートカットとして pc を使用できます。

属性の型は整数カウンタに定義されています。

Requestable フラグは FORCED に設定されています。この設定では、ジョブが発行された時点で、ジョブがいくつの pam-crash ライセンスを占有するかをユーザーが要求しなければならないことが指定されています。

Consumable フラグは、その属性が消費可能リソースであることを指定します。

Requestable は (すべてのジョブでこの属性に対して要求値を受信する必要があることを意味する) FORCED に設定されているため、設定 Default は無関係になります。

コンシューマブルは、complex_values リストを介して、グローバル、ホスト、またはキュー構成からその値を受け取ります。host_conf(5) および queue_conf(5) のマニュアルページだけでなく、「キューの構成」 および 「ホストの構成」を参照してください。

この属性とクラスタに対してリソース計画をアクティブにするには、使用可能な pam-crash ライセンスの数をグローバルホスト構成で定義する必要があります。

属性 pam-crash の値は 10 に設定され、これは 10 個の浮動ライセンスに対応します。

注 –

テーブル Consumables/Fixed Attributes は、ホスト構成ファイル書式 host_conf(5) で説明されている complex_values エントリに対応します。

ユーザーが次のジョブを発行すると仮定します。


% qsub -l pc=1 pam-crash.sh

ジョブは、10 未満の pam-crash ライセンスが現在占有されている場合にのみ起動します。ジョブはクラスタ内の任意の場所で実行可能ですが、実行時間の全体において 1 つの pam-crash ライセンスを占有します。

クラスタ内のホストの 1 つを、浮動ライセンスに含めることができない場合があります。たとえば、そのホストに対しては pam-crash バイナリを使用できません。このような場合、pam-crash ライセンス管理からそのホストを除外できます。消費可能属性 pam-crash に関して、そのホストに関連する容量をゼロに設定することで、そのホストを排除できます。「Host Configuration」ダイアログボックスの「Execution Host」タブを使用します。

注 –

コンプレックスのグローバル属性はすべての実行ホストにより継承されるため、pam-crash 属性は暗黙に実行ホストに対して使用可能になります。容量をゼロに設定することで、1 つのホストが管理できるライセンスの数を、2 などのゼロ以外の値に制限することもできます。この場合、そのホストには最大 2 つの pam-crash ジョブが共存できます。

同様に、あるキューが pam-crash ジョブを実行することを防止したい場合があります。たとえば、キューが、pam-crash には適切ではないメモリーと CPU 時間の制限を持つ、エクスプレスキューである場合です。この場合、次の図に示すように、キュー構成で対応する容量をゼロに設定します。

注 –

コンプレックスのグローバル属性はすべてのキューにより継承されるため、pam-crash 属性は暗黙にキューに対して使用可能になります。

例 2: 仮想記憶の容量の共有

メモリーの過剰予約を原因とするパフォーマンスの低下、そしてその結果としてマシンでスワップが起きないようにシステムをチューニングすることは、システム管理者がよく行う仕事です。Grid Engine ソフトウェアは、消費可能リソースの機能を介して、ユーザーが行うこのタスクをサポートできます。

標準的な負荷パラメータ virtual_free は、使用可能な空き仮想記憶、つまり使用可能なスワップ容量と使用可能な物理メモリーの結合量を報告します。 スワッピングを回避するには、スワップ容量の使用量を最小限にする必要があります。理想的なケースでは、ホストで実行中のすべてのプロセスで必要なすべてのメモリーが、物理メモリーに収まっています。

Grid Engine ソフトウェアは、次の前提と構成の下では、Grid Engine システムを介して開始されるすべてのジョブに必要なメモリーが使用可能であることを保証できます。

考えられる virtual_free リソース定義の例は、図 3–2 にあります。1G バイトのメインメモリーを搭載したホストの、対応する実行ホストの構成は、図 3–3 にあります。

virtual_free リソース定義の例では、グローバル構成の例と同じように、Requestable フラグは、FORCED ではなく YES に設定されています。これは、ユーザーはジョブのメモリー要件を指定する必要がないことを意味します。明示的なメモリーの要求がない場合に、「Default」フィールドの値が使用されます。この場合のデフォルト要求としての 1G バイトの値は、要求を持たないジョブがすべての使用可能な物理メモリーを占有すると想定されていることを意味します。

注 –

virtual_free は、Grid Engine システムの標準的な負荷パラメータの 1 つです。仮想記憶の容量計画では、最近のメモリー統計の追加の可用性が、システムにより自動的に考慮されます。空き仮想記憶の負荷レポートが、Grid Engine ソフトウェアの内部のブックキーピングにより取得される値を下回る場合、メモリーの過剰予約を防ぐために負荷値が使用されます。Grid Engine システムを使用せずにジョブが起動された場合は、報告される負荷値と内部のブックキーピングの違いは容易に生じます。

1 つのマシンでさまざまなメモリー要件のさまざまなジョブクラスを実行する場合は、これらのジョブクラスが使用するメモリーを分割したい場合があります。この機能は、容量の共有と呼ばれます。各ジョブクラスに対してキューを構成することで、この機能を実現できます。続いて、そのホスト上の合計メモリーの一部を各キューに割り当てます。

例では、キュー構成が、ホスト carc に使用可能な合計メモリーの半分を、ホスト carc の fast.q キューに割り当てます。そのため、ホスト carc 上のキュー fast.q で実行中のすべてのジョブの累積メモリー消費量は、500M バイトを超えることができません。そのほかのキューのジョブは考慮されません。それにもかかわらず、ホスト carc 上で実行中のすべてのジョブの合計メモリー消費量は、1G バイトを超えることができません。

注 –

属性 virtual_free は、コンプレックスからの継承を介して、すべてのキューに使用可能です。

ユーザーは、次のいずれかの形式の例と同じように構成されているシステムに対して、ジョブを発行する場合があります。


% qsub -l vf=100M honest.sh
% qsub dont_care.sh

最初のコマンドにより発行されるジョブは、少なくとも 100M バイトのメモリーが使用可能になるとすぐに開始できます。この量は、virtual_free の消費可能なリソースの容量計画において考慮されます。2 番目のジョブは暗黙にすべての使用可能なメモリーを要求するため、2 番目のジョブが実行されるのは、システム上にそのほかのジョブが存在しない場合のみです。また、2 番目のジョブはキューのメモリー容量を超えるため、このジョブはキュー fast.q では実行できません。

例 3: 使用可能なディスク容量の管理

一部のアプリケーションでは、ファイルに格納されている大量のデータセットを操作する必要があります。このようなアプリケーションは、実行時間全体を通じて、十分なディスク容量を利用できる必要があります。この要件は、前の例で説明した使用可能なメモリーの容量の共有に似ています。主な違いは、Grid Engine システムでは、標準的な負荷パラメータの 1 つとして空きディスク容量が用意されていない点です。ディスクは通常、サイト固有の方法でファイルシステムに分割されているため、空きディスク容量は標準的な負荷パラメータではありません。サイト固有のパーティション分割により、対象のファイルシステムの識別を自動で行うことができません。

それにもかかわらず、使用可能なディスク容量は、消費可能リソースの機能を通じて、システムによって効率的に管理することができます。この目的のためには、ホストリソース属性 h_fsize を使用する必要があります。

まず、次の図に示すように、属性を消費可能リソースとして構成する必要があります。

ローカルホストファイルシステムの場合、次の図に示すように、ディスク容量のコンシューマブルに関するリーズナブルな容量の定義を、ホスト構成に配置することができます。

このように構成された Grid Engine システムに対するジョブの発行は、以前の例と同じように機能します。


% qsub -l hf=5G big-sort.sh

ここで h_fsize 属性が推奨されているのは、h_fsize は、キュー構成において固定ファイルサイズ制限値としても使用されているためです。ファイルサイズの制限値は、ジョブ発行時に指定されるよりも大きなサイズのファイルを作成するジョブの権限を制限します。この例の qsub コマンドは、5G バイトのファイルサイズの制限値を指定しています。ジョブが属性を要求しない場合、キュー構成またはホスト構成からの対応する値が使用されます。例で h_fsize の Requestable フラグが FORCED に設定されている場合、qsub コマンドには要求が含まれている必要があります。Requestable フラグが設定されていない場合は、qsub コマンドでは要求はオプションになります。

消費可能リソースとしてキュー制限値を使用することで、ジョブスクリプトによる実際のリソース消費量の代わりに、ユーザーが指定する要求を制御します。制限値の違反は制裁されるため、最終的にはジョブが異常終了します。キュー制限値により、Grid Engine システム内部の容量計画のベースとなる、リソース要求の信頼性が確保されます。詳細については、queue_conf(5) および setrlimit(2) のマニュアルページを参照してください。

注 –

一部のオペレーティングシステムでは、プロセスごとのファイルサイズの制限値のみ使用できます。この場合は、ジョブは制限値までのサイズの複数のファイルを作成する場合があります。ジョブごとのファイルサイズの制限値をサポートしているシステムでは、Grid Engine システムは h_fsize 属性とともにこの機能を使用します。詳細については、queue_conf(5) のマニュアルページを参照してください。

Grid Engine システムに発行されないアプリケーションに、同時にディスク容量を占有させたい場合があります。このような場合、ディスク容量の不足により、内部のブックキーピングではアプリケーション障害を防ぐのに十分ではない場合があります。この問題を回避するため、ディスク容量の使用量に関する統計を定期的に受信することができます。そうした統計によって、Grid Engine システムの外部で発生しているものも含めて、全体のディスク領域の消費量が分かります。

負荷センサーインタフェースを使用すると、ファイルシステム上で使用可能なディスク容量など、サイト固有の情報を持つ、標準的な負荷パラメータのセットを強化することができます。詳細については、「サイト固有の負荷パラメータの追加」を参照してください。

適切な負荷センサーを追加し、 h_fsize に関して空きディスク容量を報告することで、消費可能リソースの管理とリソースの可用性の統計を組み合わせることができます。Grid Engine システムは、ディスク容量のジョブ要件と、使用可能な容量、および報告された最新の負荷値を比較します。使用可能な容量は、内部のリソース計画から得られます。ジョブがホストに振り分けられるのは、両方の基準が満たされた場合のみです。