ジョブを発行するときに、ジョブに対して要件プロファイルを指定できます。ユーザーは、実行を成功させるためにジョブに必要なホストやキューの属性または特徴を指定できます。Grid Engine ソフトウェアは、これらのジョブ要件をクラスタのホストとキュー構成に対応付けることによって、ジョブに適したホストを見つけます。
ジョブ要件の指定に使用できる属性は、次のいずれかと関連があります。
ネットワーク共有ディスクで必要な空間などのクラスタ
オペレーティングシステムアーキテクチャーなどの個別ホスト
使用できる CPU 時間などのキュー
属性は、特定のホスト上だけで使用できるインストールソフトウェアなどのサイトポリシーから派生することもあります。
次のような属性を使用できます。
キュープロパティーリスト – 「キューとキュープロパティーの表示」を参照
グローバル属性とホスト関連の属性のリスト – 『Sun N1 Grid Engine 6.1 管理ガイド』の「キュー、ホスト、およびグローバルクラスタへのリソース属性の割り当て」を参照
管理者定義の属性
管理者は便宜上よく、すべての使用可能な属性のサブセットを要求できるように定義します。
現在要求可能な属性は、次の図の「Requested Resources」ダイアログボックスに表示されています。
「Requested Resources」ダイアログボックスにアクセスするには、「QMON Submit Job」ダイアログボックスを使用してください。要求可能な属性は「Available Resources」の下に一覧表示されます。
構成済みのリソース属性のリストを表示するには、コマンド行から次のコマンドを入力してください。
% qconf -sc |
Grid Engine システムコンプレックスには、すべてのリソース属性の定義が含まれています。リソース属性の詳細は、『Sun N1 Grid Engine 6.1 管理ガイド』の第 3 章「コンプレックスリソース属性の構成」を参照してください。complex(5) マニュアルページの複雑な書式の説明も参照してください。
qconf -sc コマンドの出力は、例 2–2 のようになります。
gimli% qconf -sc #name shortcut type relop requestable consumable default urgency #---------------------------------------------------------------------------------------- arch a RESTRING == YES NO NONE 0 calendar c STRING == YES NO NONE 0 cpu cpu DOUBLE >= YES NO 0 0 h_core h_core MEMORY <= YES NO 0 0 h_cpu h_cpu TIME <= YES NO 0:0:0 0 h_data h_data MEMORY <= YES NO 0 0 h_fsize h_fsize MEMORY <= YES NO 0 0 h_rss h_rss MEMORY <= YES NO 0 0 h_rt h_rt TIME <= YES NO 0:0:0 0 h_stack h_stack MEMORY <= YES NO 0 0 h_vmem h_vmem MEMORY <= YES NO 0 0 hostname h HOST == YES NO NONE 0 load_avg la DOUBLE >= NO NO 0 0 load_long ll DOUBLE >= NO NO 0 0 load_medium lm DOUBLE >= NO NO 0 0 load_short ls DOUBLE >= NO NO 0 0 mem_free mf MEMORY <= YES NO 0 0 mem_total mt MEMORY <= YES NO 0 0 mem_used mu MEMORY >= YES NO 0 0 min_cpu_interval mci TIME <= NO NO 0:0:0 0 np_load_avg nla DOUBLE >= NO NO 0 0 np_load_long nll DOUBLE >= NO NO 0 0 np_load_medium nlm DOUBLE >= NO NO 0 0 np_load_short nls DOUBLE >= NO NO 0 0 num_proc p INT == YES NO 0 0 qname q STRING == YES NO NONE 0 rerun re BOOL == NO NO 0 0 s_core s_core MEMORY <= YES NO 0 0 s_cpu s_cpu TIME <= YES NO 0:0:0 0 s_data s_data MEMORY <= YES NO 0 0 s_fsize s_fsize MEMORY <= YES NO 0 0 s_rss s_rss MEMORY <= YES NO 0 0 s_rt s_rt TIME <= YES NO 0:0:0 0 s_stack s_stack MEMORY <= YES NO 0 0 s_vmem s_vmem MEMORY <= YES NO 0 0 seq_no seq INT == NO NO 0 0 slots s INT <= YES YES 1 1000 swap_free sf MEMORY <= YES NO 0 0 swap_rate sr MEMORY >= YES NO 0 0 swap_rsvd srsv MEMORY >= YES NO 0 0 swap_total st MEMORY <= YES NO 0 0 swap_used su MEMORY >= YES NO 0 0 tmpdir tmp STRING == NO NO NONE 0 virtual_free vf MEMORY <= YES NO 0 0 virtual_total vt MEMORY <= YES NO 0 0 virtual_used vu MEMORY >= YES NO 0 0 # >#< starts a comment but comments are not saved across edits -------- |
name の列は、qconf -sq コマンドによって表示される最初の列と同じです。shortcut の列には、最初の列のフルネームの省略形が入ります。省略形は管理者によって定義されます。qsub コマンドの要求オプションでは、フルネームまたはショートカットのどちらでも指定できます。
requestable の列には、リソース属性が qsub コマンドで使用できるかどうかが示されています。管理者は、たとえば、クラスタのユーザーが特定のマシンまたは自分のジョブのキューを直接要求できないようにすることもできます。管理者は、エントリ qname、hostname、またはこの両方を要求不可にすることができます。キューまたはホストを要求不可能にすると、実行可能なユーザー要求を通常複数のキューで満足させることができ、Grid Engine システムの負荷均衡機能が実行されます。
relop の列には、キューまたはホストがユーザー要求を満たせるかどうかを計算するための関係演算子が定義されています。次のような比較が行われます。
User_Request relop Queue/Host/... -Property |
比較結果が偽の場合、ユーザーのジョブをそのキューまたはホストで実行することはできません。たとえば、キュー q1 を 100 秒のソフト CPU 時間制限で構成したとします。キュー q2 は、1000 秒のソフト CPU 時間制限があるように構成します。ユーザープロセス制限の説明は、 queue_conf(5) および setrlimit(2) のマニュアルページを参照してください。
consumable と default の列は、管理者の消費可能リソースの宣言方法に影響します。『Sun N1 Grid Engine 6.1 管理ガイド』の「消費可能リソース」を参照してください。
ユーザーは、ほかの属性とまったく同じように消費可能リソースを要求します。ただし、Grid Engine システムがリソースの内部帳簿機能をつける点が異なります。
ユーザーが次の要求を発行したとします。
% qsub -l s_cpu=0:5:0 nastran.sh |
s_cpu=0:5:0 要求は、5 分以上のソフト制限 CPU 時間を許可するキューを求めます。したがって、5 分以上のソフト CPU 実行時間制限を提供するキューだけが適切に設定され、ジョブを実行できます。構文の詳細は、qsub(1) のマニュアルページを参照してください。
Grid Engine ソフトウェアは、複数のキューまたはホストがジョブを実行できる場合だけ、スケジューリングプロセスの作業負荷情報を考慮します。