test

Sun N1 Grid Engine 6.1 管理ガイド

第 3 章 コンプレックスリソース属性の構成

この章では、リソース属性の定義の構成方法を説明します。リソース属性の定義は、Grid Engine システムコンプレックスと呼ばれるエンティティーに格納されます。コンプレックスおよびそれに関連する概念に関する内容説明に加えて、この章では次のタスクを完了する方法を詳細に解説します。

コンプレックスリソース属性

コンプレックス構成は、qsub -l または qalter -l コマンドを使用してユーザーがジョブに対して要求できるリソース属性に関連するすべての情報を提供します。またコンプレックス構成は、Grid Engine システムがこれらのリソース属性をどのように解釈すべきであるかに関する情報も提供します。

またコンプレックスは、システムの消費可能リソース機能のフレームワークも構築します。コンプレックスで定義されるリソース属性は、グローバルクラスタ、ホスト、またはキューインスタンスに関連付けることができます。関連付けられた属性は、リソースと、関連する機能を結び付けます。スケジューリングプロセスでは、リソースとジョブ要件の可用性が考慮されます。また Grid Engine システムは、消費可能リソースの過剰な予約を防止するために必要なブックキーピングと容量計画を実行します。

一般的な消費可能リソース属性には次のものが含まれます。

Grid Engine のコンプレックスにおける属性の定義は、リソース属性をどのように解釈する必要があるかを定義します。

リソース属性の定義には次の要素が含まれます。

コンプレックスリソース属性を定義するには、図 3–1 に示されている「QMON Complex Configuration」ダイアログボックスを使用します。

QMON を使用したコンプレックスリソース属性の構成

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

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

「Complex Configuration」ダイアログボックスでは、コンプレックスリソース属性の追加、変更、または削除を行うことができます。

新しい属性を追加するには、まず「Attributes」テーブルで行が選択されていないことを確認します。「Attributes」テーブル上のフィールドで、必要な値を入力または選択してから「Add」をクリックします。

注 –

新しい属性を追加する必要があり、既存の属性が選択されている場合は、選択をクリアする必要があります。選択されている属性を選択解除するには、Control キーを押したままマウスボタン 1 をクリックします。

既存の属性をコピーしてからそれを変更することによって、新しい属性を追加できます。属性名とそのショートカットが一意であることを確認します。

「Attributes」テーブルに表示されている属性を変更するには、それを選択します。選択した属性の値は、「Attributes」テーブル上に表示されます。属性値を変更してから「Modify」をクリックします。

構成の変更をファイルに保存するには、「Save」をクリックします。ファイルの値をコンプレックス構成に読み込むには、「Load」をクリックして、表示されるリストからファイルの名前を選択します。

「Attribute」テーブルの属性を削除するには、属性を選択してから「Delete」をクリックします。

テーブルの行とカラムの意味の詳細については、complex(5) のマニュアルページを参照してください。

新しいコンプレックス構成または変更したコンプレックス構成を sge_qmaster に登録するには、「Commit」をクリックします。

キュー、ホスト、およびグローバルクラスタへのリソース属性の割り当て

リソース属性は次のように使用することができます。

各キューおよびホストには、デフォルトのリソース属性のセットがすでに関連付けられています。デフォルトのリソース属性はシステムに組み込まれ、削除したり、その型を変更することはできません。

ユーザー定義のリソース属性は、キューインスタンス、ホスト、またはグローバルクラスタに割り当てる前に、まずコンプレックスで定義する必要があります。リソース属性をこれらのターゲットの 1 つに割り当てる場合には、属性の値を指定します。

次の節では、各属性の型を詳細に説明しています。

キューリソース属性

デフォルトのキューリソース属性は、キュー構成で定義されているパラメータのセットです。これらのパラメータは、queue_conf (5) のマニュアルページで説明されています。

デフォルトの属性には新しいリソース属性を追加できます。新しい属性は、ユーザーが変更したキューインスタンスにのみ関連付けられます。特定のキューインスタンスの構成が、コンプレックスで定義されているでリソース属性を参照している場合、そのキュー構成は属性定義の値を提供します。キュー構成の詳細については、「キューの構成」を参照してください。

たとえば、キュー構成値 h_vmem は、仮想記憶サイズの制限に使用されます。この値は、各ジョブが消費できる合計メモリーの量を制限します。キュー構成の complex_values リストにあるエントリが、ホスト上、またはキューに割り当てられた使用可能な仮想記憶の総量を定義します。 消費可能リソースの詳細については、「消費可能リソース」を参照してください。

ホストリソース属性

ホストリソース属性は、ホストごとに管理されるパラメータです。

デフォルトのホスト関連の属性は、負荷値です。すでに 「キューリソース属性」で説明したように、デフォルト属性には新しいリソース属性を追加できます。

各 sge_execd は、定期的に sge_qmaster に対して負荷を報告します。「負荷パラメータ」で説明されているように、報告される負荷値は、CPU 負荷の平均などの標準的な負荷値か、管理者によって定義された負荷値です。

標準的な負荷値の定義はデフォルトのホストリソース属性の一部ですが、管理者定義の負荷値は、ホストリソース属性の拡張を必要とします。

一般的にホスト関連の属性は、標準ではない負荷パラメータを含むよう拡張されます。ホスト関連の属性も、ホストに割り当てられているソフトウェアライセンスの数や、ホストのローカルファイルシステムで使用可能なディスク容量など、ホスト関連のリソースを管理するよう拡張されます。

ホスト関連の属性が、ホスト、またはそのホスト上のキューインスタンスに関連付けられている場合、特定のホストリソース属性の具体的な値は、次のいずれかの項目によって決定されます。

場合によっては、これらの値が 1 つも使用できないことがあります。たとえば、値が負荷パラメータであると想定されていても、 sge_execd がそのパラメータの負荷値を報告しない場合などです。このような場合、属性は定義されておらず、また qstat –F コマンドではその属性が適用不可であることが示されます。

たとえば、空き仮想記憶の合計の属性 h_vmem は、キュー構成で制限として定義され、また標準的な負荷パラメータとしても報告されます。ホスト上の仮想記憶の使用可能な総量は、ホストの complex_values リストで定義されます。ホスト上のキューインスタンスに関連付けられた仮想記憶の使用可能な総量は、そのキューインスタンスの complex_values リストで定義できます。 h_vmem を消費可能リソースとして定義することで、(多くの場合スワッピングが原因でシステムパフォーマンスを低下させる) メモリーの過剰な予約のリスクを冒すことなく、マシンのメモリーを効率的に活用できます。消費可能リソースの詳細については、「消費可能リソース」を参照してください。

注 –

デフォルトのリソース属性に関しては、「Shortcut」、「Relation」、「Requestable」、「Consumable」、および「Default」の各カラムのみ変更可能です。デフォルトの属性は削除できません。

グローバルリソース属性

グローバルリソース属性は、ファイルサーバーの使用可能なネットワーク帯域幅や、ネットワーク全体の使用可能なファイルシステム上の空きディスク容量など、クラスタ全体のリソース属性です。

対応する負荷レポートに、「負荷パラメータ」で説明されている GLOBAL 識別子が含まれる場合、グローバルリソース属性は、負荷レポートと関連付けることもできます。クラスタ内の任意のホストからグローバル負荷値を報告させることもできます。グローバル負荷値はデフォルトでは報告されないため、デフォルトのグローバルリソース属性は存在しません。

グローバルリソース属性の具体的な値は、次の項目によって決定されます。

場合によっては、上記のケースがいずれも適用されません。たとえば、負荷値がまだ報告されていない場合などです。このような場合、その属性は存在しません。

コンプレックスへのリソース属性の追加

コンプレックスにリソース属性を追加することにより、管理者は Grid Engine システムにより管理される属性のセットを拡張できます。また管理者は、ユーザー定義属性の影響を、特定のキューやホスト、またはその両方に制限することもできます。

ユーザー定義属性は、Grid Engine ソフトウェアがどのように属性を処理するかに関する、対応する定義を持つ、属性の名前付きコレクションです。1 つまたは複数のユーザー定義属性を、1 つのキュー、1 つのホスト、またはグローバルにクラスタ内の全ホストに対して関連付けることができます。キュー構成およびホスト構成に対しては、complex_values パラメータを使用します。詳細については、 「キューの構成」および 「ホストの構成」を参照してください。定義済みの属性は、デフォルトのリソース属性に加えて、それぞれキューおよびホストに対して使用可能になります。

キュー構成とホスト構成の complex_values パラメータは、キューおよびホストに対して関連付けられているユーザー定義属性に対して、具体的な値を設定する必要があります。

たとえば、次の図に示すユーザー定義リソース属性 permas、 pamcrash、および nastran が定義されます。

「Modify queue-name」ダイアログボックスの「Complex」タブに表示されているように、少なくとも 1 つ以上のキューに関して、関連付けられたユーザー定義属性のリストに、リソース属性を追加します。キューの構成方法の詳細については、「キューの構成」とその関連の節を参照してください。

また、表示されているキューは、ソフトウェアパッケージ permas の最大 10 個のライセンスを管理するよう構成されています。さらに、「Requested Resources」ダイアログボックスの「Available Resources」リストに示すように、属性 permas はジョブに対して要求可能になります。

ジョブを発行する方法の詳細については、『Sun N1 Grid Engine 6.1 ユーザーズガイド』の第 3 章「ジョブの発行」を参照してください。

または、ユーザーは次のようにコマンド行からジョブを発行し、属性を要求することができます。


% qsub -l pm=1 permas.sh
注 –

完全な属性名 permas の代わりに、pm ショートカットを使用できます。

その結果、これらのジョブに対して適格なキューは、ユーザー定義リソース属性と関連付けられ、permas ライセンスが構成され使用可能になっているキューのみになります。

消費可能リソース

消費可能リソースは、使用可能なメモリー、ファイルシステム上の空き容量、ネットワーク帯域幅、浮動ソフトウェアライセンスなど、制限のあるリソースを管理するための効率的な手段になります。消費可能リソースはコンシューマブルとも呼ばれます。コンシューマブルの使用可能な総量は、管理者によって定義されます。対応するリソースの消費は、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 システムは、ディスク容量のジョブ要件と、使用可能な容量、および報告された最新の負荷値を比較します。使用可能な容量は、内部のリソース計画から得られます。ジョブがホストに振り分けられるのは、両方の基準が満たされた場合のみです。

コマンド行からのコンプレックスリソース属性の構成

コマンド行からコンプレックスを構成するには、適切なオプションを使用して次のコマンドを入力します。


% qconf オプション

qconf コマンドの書式と有効な構文の詳細な定義については、qconf(1) のマニュアルページを参照してください。

次のオプションを使用すると、Grid Engine システムのコンプレックスを変更することができます。

次のコマンドを使用すると、complex(5) のマニュアルページで定義されているファイル形式で、現在のコンプレックス構成が標準出力ストリームに出力されます。


% qconf -sc

次の例に、サンプルの出力を示します。

例 3–1 qconf -sc の出力例


#name      shortcut  type  relop  requestable   consumable  default  urgency
#---------------------------------------------------------------------------
nastran    na        INT   <=     YES           NO          0        0
pam-crash  pc        INT   <=     YES           YES         1        0
permas     pm        INT   <=     FORCED        YES         1        0
#---- # start a comment but comments are not saved across edits -----------

負荷パラメータ

この節では、Grid Engine システムの負荷パラメータについて説明します。また、独自の負荷センサーの記述法も解説します。

デフォルトの負荷パラメータ

デフォルトでは、sge_execd は sge_qmaster に対して、定期的にいくつかの負荷パラメータとそれに対応する値を報告します。これらの値は、「ホストとデーモンについて」で説明されている、sge_qmaster 内部ホストオブジェクトに格納されます。ただし、値が内部で使用されるのは、対応する名前を持つコンプレックスリソース属性が定義されている場合のみです。このようなコンプレックスリソース属性には、負荷値をどのように解釈するかに関する定義が含まれています。詳細については、「キュー、ホスト、およびグローバルクラスタへのリソース属性の割り当て」を参照してください。

最初のインストール後、負荷パラメータの標準的なセットが報告されます。標準的な負荷パラメータに必要なすべての属性は、ホスト関連の属性として定義されます。N1 Grid Engine 6.1 ソフトウェアの今後のリリースでは、デフォルトの負荷パラメータの拡張セットが提供される可能性があるため、デフォルトで報告される負荷パラメータのセットは、ファイル sge-root/doc/load_parameters.asc に記載されています。

負荷属性の定義方法は、それらのアクセス可能性を決定します。負荷パラメータをグローバルリソース属性として定義すると、それらは、クラスタ全体とすべてのホストに対して使用可能になります。負荷パラメータをホスト関連の属性として定義すると、あらゆるホストにその属性が提供されますが、グローバルクラスタには提供されません。

注 –

負荷属性は、キュー属性としては定義しないでください。キュー属性は、ホストに対してもクラスタに対しても使用可能にはなりません。

サイト固有の負荷パラメータの追加

デフォルトの負荷パラメータのセットは、クラスタにおける負荷の状況を完全に記述するのには不適切である場合があります。特に、サイト固有のポリシー、アプリケーション、および構成に関してはこの可能性が高くなります。したがって、Grid Engine ソフトウェアには負荷パラメータのセットを拡張する手段が用意されています。この目的のため、sge_execd は、負荷パラメータと現在の負荷値を sge_execd に供給するインタフェースを提供します。そのあと、これらのパラメータはデフォルトの負荷パラメータと同じように扱われます。デフォルトの負荷パラメータに関しては、サイト固有の負荷パラメータを有効にするには、対応する属性をコンプレックスで定義する必要があります。詳細については、「デフォルトの負荷パラメータ」を参照してください。

独自の負荷センサーの記述

sge_execd に追加の付加情報を供給するには、負荷センサーを用意する必要があります。負荷センサーには、スクリプトとバイナリ実行ファイルを使用できます。どちらの場合も、負荷センサーの標準入出力ストリームの処理および制御フローは次の規則に従っている必要があります。

続いて負荷センサーは、目的の負荷値を計算するために必要なすべての処理を実行します。サイクルの終了時点で、負荷センサーは結果を STDOUT に書き込みます。

注 –

負荷の取得に長時間を要する場合、負荷レポートを送信した直後に負荷測定プロセスを開始できます。quit が受信されると、負荷値は送信できるようになります。

負荷センサーの規則の書式

負荷センサーの規則の書式は次のとおりです。

負荷センサースクリプトの例

次の例に負荷センサーを示します。負荷センサーは Bourne シェルスクリプトです。

例 3–2 負荷センサー – Bourne シェルスクリプト


#!/bin/sh

myhost=`uname -n`

while [ 1 ]; do
     # wait for input
     read input
     result=$?
     if [ $result != 0 ]; then
          exit 1
     fi
     if [ $input = quit ]; then
          exit 0
     fi	
     #send users logged in
     logins=`who | cut -f1 -d" " | sort | uniq | wc -l` | sed "s/^ *//"
     echo begin
     echo "$myhost:logins:$logins"
     echo end
done

# we never get here

exit 0

このスクリプトを、ファイル load.sh に保存します。chmod コマンドを使用して、このファイルに実行可能権限を割り当てます。コマンド行からスクリプトを対話形式でテストするには、load.sh と入力し、Return キーを繰り返し押します。

手続きが機能するようになるとすぐ、任意の実行ホストにインストールできます。手続きをインストールするには、クラスタ構成、グローバル構成、またはホスト固有の構成の load_sensor パラメータとして、負荷センサーのパスを構成します。詳細については、「基本クラスタ構成」または sge_conf(5) のマニュアルページを参照してください。

対応する QMON ウィンドウは次の図のようになります。

報告される負荷パラメータ logins は、対応する属性がコンプレックスに追加されるとすぐに使用できるようになります。必要な定義は、次の図に示す最後のテーブルエントリのようになります。