test

Sun N1 Grid Engine 6.1 ユーザーズガイド

第 3 章 ジョブの発行

この章では、ジョブの発行の内容説明と、処理を行うためにジョブを発行する手順について説明します。まず、単純なジョブの実行例から始めて、より複雑なジョブの実行手順に進みます。

この章には、次の作業の実行方法が記載されています。

単純なジョブの発行

この節の情報と手順を読んで、ジョブの発行を行うための基本的な手順に慣れてください。

注 –

非特権ユーザーアカウントで N1 Grid Engine 6.1 ソフトウェアをインストールした場合は、ジョブを実行できるユーザーとしてログインする必要があります。詳細は、『Sun N1 Grid Engine 6.1 インストールガイド』の「インストールアカウント」を参照してください。

Procedureコマンド行からの単純なジョブの発行方法

すべての Grid Engine システムコマンドを実行する前に、まず実行可能な検索パスやその他の環境条件を適切に設定する必要があります。

  1. コマンド行から次のコマンドのいずれかを入力します。

    • コマンドインタプリタとして csh または tcsh を使用している場合は、次のように入力します。


      % source sge-root/cell/common/settings.csh

      sge-root は、Grid Engine システムのルートディレクトリの場所を指定します。このディレクトリは、インストール手順の最初に指定されています。

    • コマンドインタプリタとして sh、ksh、または bash を使用している場合は、次のように入力します。


      # . sge-root/cell/common/settings.sh
      注 –

      これらのコマンドは、.login、 .cshrc、または .profileファイルの中で適当なものに追加できます。これらのコマンドを設定すると、今後開始するすべての対話セッションに適切な設定を保証できます。

  2. 次のコマンドを入力して、クラスタに単純なジョブスクリプトを発行します。


    % qsub simple.sh

    コマンドは、simple.sh がスクリプトファイルの名前で、このファイルがユーザーの現在の作業ディレクトリにあるとみなします。

    次のジョブを /sge-root/examples/jobs/simple.sh ファイル内で見つけることができます。


    #!/bin/sh
#
#
# (c) 2004 Sun Microsystems, Inc. Use is subject to license terms.

#  SGE バッチスクリプトの簡単な例

# Bourne シェルに次のジョブを要求する。
#$ -S /bin/sh

#
# 日時を印刷する
date
# 20 秒スリープする
sleep 20
# 日時を再び印刷する
date

    ジョブが正しく発行されると、qsub コマンドは次の例のようなメッセージで応答します。


    your job 1 (“simple.sh”) has been submitted

  3. 次のコマンドを入力して、ジョブのステータス情報を検索します。


    % qstat

    Grid Engine システムが現在認識しているすべてのジョブの情報が示されたステータスレポートを受け取ることができるはずです。ステータスレポートは、ジョブごとに次の項目を一覧表示します。

    • 発行の確認に含まれる一意の番号であるジョブ ID

    • ジョブスクリプトの名前

    • ジョブの所有者

    • 実行中を表す r などの状態インジケータ

    • 発行時または開始時

    • ジョブが実行されるキューの名前

    qstat を実行しても何も出力されなかった場合、システムが認識しているジョブはありません。たとえば、ジョブはすでに終了している可能性もあります。

    stdout および stderr リダイレクトファイルをチェックすると、終了ジョブの出力を制御できます。デフォルトでは、これらのファイルはジョブを実行したホスト上のジョブ所有者のホームディレクトリに生成されます。ファイルの名前は、stdout ファイルの場合は .o、stderr ファイルの場合は .e の拡張子が付くジョブスクリプトのファイル名のあとに一意のジョブ ID が続く構成となります。ジョブの stdout および stderr ファイルは、それぞれ simple.sh.o1 と simple.sh.e1 という名前で見つけることができます。これらの名前は、そのジョブが、新たにインストールされた Grid Engine システムで初めて実行されるジョブの場合に使用されます。

ProcedureQMON により単純なジョブを発行する

グラフィカルユーザーインタフェースの QMON を使用すると、ジョブの発行と制御および Grid Engine システムの概要の取得をより便利に行うことができます。ほかにも機能はありますが、QMON は、ジョブの発行と監視を行うためのジョブ発行ダイアログボックスと「Job Control」ダイアログボックスも提供しています。

  1. 次のコマンドを入力して QMON GUI を起動します。


    % qmon

    起動中にメッセージウィンドウが表示され、「QMON Main Control」ウィンドウが表示されます。

    図 3–1 「QMON Main Control」ウィンドウ

  2. 「Job Control」ボタンをクリックしたあと、「Submit Jobs」ボタンをクリックします。

    ヒント –

    「Job Control」などのボタン名は、ボタン上にマウスポインタを置くと表示されます。

    「Submit Job」ダイアログボックスと「Job Control」ダイアログボックスが、次の図のように表示されます。

    図 3–2 「Submit Job」ダイアログボックス

    図 3–3 「Job Control」ダイアログボックス

  3. 「Submit Job」ダイアログボックスで「Job Script」フィールドの右にあるアイコンをクリックします。

    「Select a File」ダイアログボックスが表示されます。

    図 3–4 「Select a File」ダイアログボックス

  4. スクリプトファイルを選択します。

    たとえば、コマンド行の例で使用した simple.sh ファイルを選択します。

  5. 「OK」をクリックして、「Select a File」ダイアログボックスを閉じます。

  6. 「Submit Job」ダイアログボックスで「Submit」をクリックします。

    数秒後には、「Job Control」ダイアログボックスでジョブを監視できるはずです。最初に「Pending Jobs」タブで自分のジョブを確認します。ジョブの実行が開始されると、ジョブはすぐ「Running Jobs」タブに移ります。

バッチジョブの発行

次の節では、Grid Engine システムでより複雑なジョブを発行する方法について説明します。

シェルスクリプトについて

バッチジョブとも呼ばれるシェルスクリプトは、ファイル内でアセンブルされる一連のコマンド行命令です。スクリプトファイルは、 chmod コマンドによって実行可能になります。スクリプトを呼び出すと、コマンドインタプリタが起動されます。各命令は、スクリプトを実行するユーザーが手で入力しているかのように解釈されます。一般的なコマンドインタプリタには、csh、tcsh、 sh、または ksh があります。シェルスクリプト内からは、任意のコマンド、アプリケーション、およびその他のシェルスクリプトを呼び出すことができます。

コマンドインタプリタは、ログインシェルとして呼び出すことができます。このためには、ジョブを実行している特定のホストおよびキューに対して有効な Grid Engine システムの構成の login_shells リストに該当コマンドインタプリタの名前を含める必要があります。

注 –

Grid Engine システムの構成は、クラスタ内のさまざまなホストやキューによって異なる場合があります。有効な構成は、qconf コマンドの -sconf オプションと -sq オプションで表示できます。詳細は、qconf(1) のマニュアルページを参照してください。

コマンドインタプリタをログインシェルとして呼び出すと、ジョブの環境はスクリプトにログインして実行した場合と同じになります。たとえば、csh を使用すると、/etc/login などのシステムのデフォルト起動リソースファイル以外に .login と .cshrc が実行されます。一方、csh を login-shell として呼び出さなかった場合は、.cshrc だけが実行されます。login-shell として呼び出す場合と呼び出さない場合の違いについては、お使いのコマンドインタプリタのマニュアルページを参照してください。

シェルスクリプトの例

例 3–1 に単純なシェルスクリプトを示します。このスクリプトは、まずアプリケーション flow を Fortran77 ソースからコンパイルしたあと、このアプリケーションを実行します。

例 3–1 単純なシェルスクリプト


#!/bin/csh
# N1 Grid Engine 6.1 にある FORTRAN プログラムのサンプルを 
#  コンパイルし、実行するスクリプトファイルの例
cd TEST
# プログラム "flow.f" をコンパイルし、実行可能な "flow" を
# ファイル名として命名する必要がある。
f77 flow.f -o flow

ローカルシステムのユーザーズガイドには、シェルスクリプトの作成とカスタマイズに関する詳細情報が記載されています。sh、ksh、csh または tcsh のマニュアルページも参照してください。以降の節では、Grid Engine システム用のバッチスクリプトの作成時に、特に考慮すべき事柄を重点的に説明します。

一般的に、コマンドプロンプトから手動で実行できるすべてのシェルスクリプトは、Grid Engine システムに発行できます。 このシェルスクリプトは、端末接続や対話形式のユーザー介入を必要としてはなりません。ただし、自動的にリダイレクトされる標準エラーと標準出力デバイスは例外です。したがって、例 3–1 では Grid Engine システムへの発行準備が整っており、スクリプトは指定の処理を行います。

通常のシェルスクリプトの拡張

通常のシェルスクリプトを拡張すると、Grid Engine システムの制御下で実行されるスクリプトの動作に影響が出る場合があります。次の節では、これらの拡張機能について説明します。

コマンドインタプリタの選択方法

図 3–5 に示すように、発行時には、ジョブスクリプトファイルの処理に使用するコマンドインタプリタを指定できます。何も指定しなかった場合、コマンドインタプリタの選択方法は構成変数 shell_start_mode によって決められます。

出力のリダイレクト

バッチジョブには端末接続がないため、標準出力と標準エラー出力はファイルにリダイレクトしなければなりません。Grid Engine システムでは、出力のリダイレクト先となるファイルの場所を定義できます。出力ファイルが指定されていない場合は、デフォルトが使用されます。

ファイルの標準的な場所は、ジョブが実行される現在の作業ディレクトリです。デフォルトの標準出力ファイル名は job-name.o job-id で、デフォルトの標準エラーの出力先は job-name>.ejob-id にリダイレクトされます。job-name はスクリプトファイル名から作成するか、ユーザーが定義できます。たとえば、submit(1) のマニュアルページの -N オプションを参照してください。job-id は、Grid Engine システムによってジョブに割り当てられる一意の識別子です。

配列ジョブのタスクの場合 、タスクの識別子はドットで区切られて、これらのファイル名に追加されます。リダイレクト後の標準出力先パスは、 job-name.ojob-id.task-id> と job-name.e job-id.task-id になります。詳細は、「配列ジョブの発行」を参照してください。

標準の場所が適切でない場合は、 図 3–6 のように、QMON で出力先を指定できます。また、qsub コマンドの -e や -o オプションを使用して、出力先を指定することもできます。標準出力と標準エラー出力は、1 つのファイルにマージすることもできます。リダイレクトは、実行ホストごとに指定できます。その場合、ジョブが実行されるホストによって、出力するリダイレクトファイルの場所は異なります。一意のカスタマイズリダイレクトファイルパスを作成するには、qsub の -e および -o オプションと一緒に使用できるダミー環境変数を使用します。次にこれらの変数の一覧を示します。

ジョブを実行すると、これらの変数に実際の値が入り、その値でリダイレクトパスが作成されます。

詳細は、qsub(1) のマニュアルページを参照してください。

有効なコメント

シェルスクリプトでは、ハッシュ記号 (#) が最初にある行はコメントとして扱われます。 ただし、Grid Engine システムは特別なコメント行を認識し、それらの行を特別な方法で使用します。そのような特別なコメントスクリプト行は、qsub コマンドのコマンド行引数リストの一部として扱われます。これらの特別なコメント行内で指定される qsub オプションも「QMON Submit Job」ダイアログボックスで解釈されます。スクリプトファイルを選択すると、対応するパラメータがプリセットされます。

デフォルトでは、特別なコメント行は #$ という接頭辞で識別されます。接頭辞は、 qsub -C コマンドで再定義できます。

このような特別なコメントの使用は、発行引数のスクリプト組み込みと呼ばれます。次に、スクリプト組み込みコマンド行オプションを利用したスクリプトファイルの例を示します。

例 3–2 スクリプト組み込みコマンド行オプションの使用


#!/bin/csh

# Grid Engine のデフォルトのシェルでなければ 
# csh を強制

#$ -S /bin/csh

# これは N1 Grid Engine 6.1 の元でサンプルの FORTRAN プログラムを
# コンパイルし、実行するスクリプトファイルの例です。
# Grid Engine に、ジョブの開始時と終了時に 
# メールを送信させるように
# します。

#$ -M EmailAddress
#$ -m b,e

# 標準出力と標準エラーのためのファイルを
# 命名します。

#$ -o flow.out -j y

# ファイルがあるディレクトリに変更します。

cd TEST

# プログラム "flow.f" をコンパイルし、
# 実行可能な "flow" と命名する必要があります。

f77 flow.f -o flow

# コンパイルを完了すると、そのプログラムを実行できます。

flow

環境変数

ジョブが実行されると、いくつかの変数がジョブの 環境にプリセットされます。

拡張ジョブと高度なジョブの発行

拡張ジョブと高度なジョブは、より複雑なジョブ発行形式です。これらのジョブを発行しようとする前に、プロセスに関する重要な内容説明を理解する必要があります。次の節では、これらのジョブプロセスについて説明します。

QMON による拡張ジョブの発行

「Submit Job」ダイアログボックスの「General」タブでは、拡張ジョブに対して次のパラメータを設定できます。「General」タブは、 図 3–2 に示されています。

「Submit Job」ダイアログボックスの右にあるボタンを使用すると、次のようなさまざまな操作を開始できます。

拡張ジョブの例

図 3–5 に、大部分のパラメータが設定された「Submit Job」ダイアログボックスを示します。

図 3–5 拡張ジョブの発行例

この例で設定されているジョブのパラメータは、次のとおりです。

コマンド行からの拡張ジョブの発行

コマンド行から 図 3–5 に示されている拡張ジョブ要求を発行するには、次のコマンドを入力します。


% qsub -N Flow -p -111 -P devel -a 200404221630.44 -cwd \
	-S /bin/tcsh -o flow.out -j y flow.sh big.data

QMON による高度なジョブの発行

「Submit Job」ダイアログボックスの「Advanced」タブでは、次の追加パラメータを定義できます。

高度なジョブの例

図 3–6 に、高度なジョブの発行例を示します。

図 3–6 高度なジョブの発行例

「拡張ジョブの例」で定義されているジョブは、「QMON による拡張ジョブの発行」のジョブ定義と比較すると、さらに次のような特徴を備えています。

コマンド行からの高度なジョブの発行

コマンド行から図 3–6 に示されている高度なジョブ要求を発行するには、次のコマンドを入力します。


% qsub -N Flow -p -111 -P devel -a 200012240000.00 -cwd \
 -S /bin/tcsh -o flow.out -j y -pe mpi 4-16 \
 -v SHARED_MEM=TRUE,MODEL_SIZE=LARGE \
 -ac JOB_STEP=preprocessing,PORT=1234 \
 -A FLOW -w w -m s,e -q big_q\
 -M me@myhost.com,me@other.address \
 flow.sh big.data

デフォルト要求ファイル

前のコマンドは、特に同じような要求を頻繁に発行する必要がある場合に、高度なジョブ要求は複雑で扱いにくくなる可能性があることを示しています。スクリプトファイルに qsub オプションを組み込むことによって、またはデフォルト要求ファイルを使用することによって、このようなコマンドを入力するという、面倒でエラーを引き起こしやすい作業を回避できます。詳細は、「有効なコメント」を参照してください。

注 –

-binary yes|no オプションで y 引数を指定すると、qrsh を使用してスクリプトラッパーなしで実行可能ジョブを発行できます。詳細は、qsub のマニュアルページを参照してください。

クラスタ管理では、すべての Grid Engine システムユーザーに対してデフォルト要求ファイルを設定できます。一方ユーザーは、ホームディレクトリに保存される個人用デフォルト要求ファイルを作成できます。ユーザーはまた、作業ディレクトリに保存されるアプリケーション固有のデフォルト要求ファイルを作成することもできます。

デフォルト要求ファイルには、デフォルトでは 1 行以上のジョブに適用される qsub オプションが含まれます。グローバルクラスタデフォルト要求ファイルは、sge-root /cell/common/sge_request に保存されます。個人用一般デフォルト要求ファイルは、$HOME/.sge_request に保存されます。アプリケーション固有のデフォルト要求ファイルは、 $cwd/.sge_request に保存されます。

    これらのファイルを複数使用できる場合、これらのファイルは次の優先順位で 1 つのデフォルト要求にマージされます。

  1. アプリケーション固有のデフォルト要求ファイル

  2. 個人用一般デフォルト要求ファイル

  3. グローバルデフォルト要求ファイル

スクリプト組み込みと qsub コマンド行は、デフォルト要求ファイルより優先されます。よって、スクリプト組み込みはデフォルト要求ファイル設定を無効にします。また、qsub コマンド行オプションは、これらの設定を無効にします。

前の設定を破棄するには、デフォルト要求ファイル、組み込みスクリプトコマンド、または qsub コマンド行で qsub -clear コマンドを実行してください。

次に個人用デフォルト要求ファイルの例を示します。


-A myproject -cwd -M me@myhost.com -m b e
-r y -j y -S /bin/ksh

無効にされない限り、このユーザーのすべてのジョブで次のことが言えます。

リソース要件の定義

ここまでの例では、発行オプションはジョブが実行されるホストに対するリソース要件を表していませんでした。Grid Engine システムは、このような場合のジョブはどのホストで実行してもよいとみなします。しかし、実際には、ほとんどのジョブで正常終了のために、実行ホストに関する前提条件が満たす必要があります。この前提条件には、十分な使用可能なメモリー、インストールが必要なソフトウェア、または特定のオペレーティングシステムアーキテクチャーなどがあります。また、クラスタ 管理は通常、クラスタ内のマシンの使用に制限を加えます。たとえば、ジョブが消費できる CPU 時間はしばしば制限されます。

Grid Engine システムでは、クラスタの装置や使用ポリシーの正確な知識を持たなくても、ジョブに適したホストを見つけることができます。ユーザーはジョブの要件を指定し、適切で負荷が少ないホストの検出作業を Grid Engine システムに管理させます。

リソース要件は、「要求可能な属性」で説明されている要求可能な属性によって指定します。 QMON を使用すると、ジョブの要件を指定するのに便利です。「Requested Resources」ダイアログボックスには、現在実行可能な「Available Resource」リストの属性だけが表示されます。「Requested Resources」ダイアログボックスを開くには、「Submit Job」ダイアログボックスの「Request Resources」をクリックします。例については、図 3–7 を参照してください。

図 3–7 「Requested Resources」ダイアログボックス

属性をダブルクリックすると、その属性はジョブの「Hard Resources」または「Soft Resources」に追加されます。True に設定される BOOLEAN 属性以外の属性に値を入力するためのダイアログボックスが表示されます。詳細は、「Grid Engine システムによるリソースの割り当て方法」を参照してください。

図 3–7 に、有効な permas ライセンスを持ち 750M バイト以上のメモリーを備えた solaris64 ホストを必要とするジョブのリソースプロファイルを示します。この指定を満たすキューが複数見つかった場合は、定義されているソフトリソース要件が考慮されます。ハードとソフト要件を満たすキューが見つからなかった場合は、ハード要件を満たすキューが適切なものとみなされます。

注 –

複数のキューが 1 つのジョブに適している場合のみ、スケジューラ構成の queue_sort_method パラメータによってジョブの開始場所が決まります。詳細は、sched_conf (5) のマニュアルページを参照してください。

整数である属性 permas は、グローバルリソース属性の管理者向け拡張属性です。文字列である属性 arch は、ホストリソース属性です。メモリーの属性 h_vmem は、キューリソース属性です。

qsub コマンド行からも、これと同じリソース要件プロファイルを次のように発行できます。


% qsub -l arch=solaris64,h_vmem=750M,permas=1 \
	permas.sh

最初の -l オプションの前の暗黙的な -hard スイッチはスキップされます。

750M バイトを表す 750M は、Grid Engine システムの量を表す構文の例です。メモリー消費が必要な属性に対しては、10 進数の整数、10 進数の浮動小数、8 進数の整数、および 16 進数の整数を指定できます。これらの数には次の乗数を加える必要があります。

8 進数の定数は、最初が 0 で次が 0 から 7 の数字でのみ指定されます。16 進数を指定する場合は、数の前に 0x を付けてください。また、0 から 9、a から f、A から F を使用します。乗数が使用されない場合、値はバイトとしてカウントするとみなされます。10 進数の浮動小数を使用する場合、結果は整数値に切り上げられます。

時間制限を課す属性の時間値は、時間単位、分単位、秒単位、またはこれらを組み合わせて指定することができます。時間、分、秒は、コロンで区切られた 10 進数で指定されます。3:5:11 という時間は 11111 秒に変換されます。時間、分または秒の指定が 0 の場合、コロンが残っていれば指定をしなくても構いません。よって、:5: という値は 5 分と解釈されます。 図 3–7 に示されている「Requested Resources」ダイアログボックスの形式は拡張形式で、QMON 内でのみ有効です。

Grid Engine システムによるリソースの割り当て方法

    前の節で示されているように、Grid Engine ソフトウェアがどのようにリソース要求を処理し、割り当てているのかを理解することは大切です。Grid Engine ソフトウェアのリソース割り当てアルゴリズムの概略は、次のようになります。

  1. すべてのデフォルト要求ファイルを読み込み、構文解析します。詳細は、「デフォルト要求ファイル」を参照してください。

  2. 組み込みオプションのスクリプトファイルを処理します。詳細は、「有効なコメント」を参照してください。

  3. ジョブの発行時には、スクリプトファイル内の位置に関わらず、すべてのスクリプト組み込みオプションを読み取ります。

  4. コマンド行からすべての要求を読み取り、構文解析します。

    すべての qsub 要求が収集されるとすぐに、ハード要件とソフト要求が別々に処理されます。まず、ハード要求が処理されます。要求は、次の優先順位で評価されます。

  1. スクリプトまたはデフォルト要求ファイルの左から右

  2. スクリプトまたはデフォルト要求ファイルの上から下

  3. コマンド行の左から右

言い換えると、コマンド行を使用して組み込みフラグを無効にすることができます。

ハードとして必要なリソースが割り当てられます。要求が有効でない場合、発行は拒否されます。1 つ以上の要求を発行時に満足できない場合、ジョブはスプールされ、後で実行するように再スケジューリングされます。たとえば、要求されたキューがビジーの場合、要求は満たされません。すべてのハード要求が満たされると、要求は割り当てられジョブを実行できます。

ソフトとして必要なリソースがチェックされます。これらの要求の一部またはすべてを満足できない場合もジョブは実行できます。ハード要求を満たす複数のキューがソフトリソースリストの一部を提供している場合、Grid Engine ソフトウェアはもっとも多くのソフト要求を提供しているキューを選択します。

ジョブが開始され、割り当てられたリソースが使用されます。

引数リストオプション、組み込みオプション、ハードおよびソフト要求が互いにどのような影響し合うのかを実際に試すとよいでしょう。hostname または date などの UNIX コマンドを実行する小さなテストスクリプトファイルで実験することができます。

ジョブの依存関係

大部分の場合、複雑なタスクを作成するのに一番便利なのは、タスクをサブタスクに分割することです。これらの場合、依存サブタスクを開始する前にその他のサブタスクの完了を待つ必要があります。たとえば、依存タスクが読み取って処理する出力ファイルが前のタスクによって作成されることなどがあります。

Grid Engine システムは、ジョブ依存関係機能で相互に依存するタスクをサポートしています。ユーザーは、1 つまたは複数のほかのジョブの完了に依存するジョブを設定できます。この機能は、qsub -hold_jid コマンドによって実行されます。発行ジョブが依存するジョブのリストを指定することもできます。ジョブのリストには、配列ジョブのサブセットも含まれます。依存関係リスト内のすべてのジョブが終了しなければ、発行ジョブは実行できません。

配列ジョブの発行

Grid Engine システムの 配列ジョブ機能の理想的な適用は、ジョブスクリプト内に含まれる操作のセットをパラメータ化して繰り返し実行することです。この典型例は、レンダリングなどで、デジタルコンテンツ作成業界でよくみられます。アニメーションのコンピュータ処理はフレームに分割されます。同じレンダリング処理が、各フレームに対して別々に行われます。

配列ジョブ機能によって、このような適用での発行、監視、および制御が便利になります。Grid Engine システムは、1 つのジョブに結合された別々のタスクの配列としてコンピュータ処理を行い、配列ジョブを効率的に実行します。配列ジョブのタスクは、配列インデックス番号によって参照されます。すべてのタスクのインデックスは、配列ジョブ全体のインデックス範囲に及びます。インデックス範囲は、配列ジョブの発行時に qsub コマンドによって定義されます。

ユーザーは、 配列ジョブの監視および制御を行うことができます。たとえば、全体として、またはそれぞれのタスクやタスクのサブセットごとに、配列ジョブを一時停止、再開、取り消しすることができます。タスクを参照するために、対応するインデックス番号が ジョブ ID の前に付けられています。タスクは、一般的なジョブとほぼ同じように実行されます。タスクは、環境変数 SGE_TASK_ID を使用して、独自のタスク インデックス番号を検索し、そのこのタスク 識別子に対する入力データセットにアクセスすることができます。

QMON による配列ジョブの発行

次の情報も考慮しながら、「QMON により単純なジョブを発行する」の手順に従ってください。

QMON による配列ジョブの発行は、 「QMON により単純なジョブを発行する」に説明されている単純なジョブの発行方法とほぼ同じです。 唯一の違いは、 図 3–5 の「Job Tasks」タスク入力ウィンドウにタスク範囲指定があることです。タスク範囲の指定では、qsub -t コマンドと同じ構文を使用します。配列インデックスの構文については、 qsub(1) のマニュアルページを参照してください。

一般的なジョブの監視と制御および特定の配列ジョブについては、「ジョブの監視と制御」と 「コマンド行からのジョブの監視と制御」を参照してください。qstat(1)、qhold(1)、 qrls(1)、qmod(1)、および qdel(1) のマニュアルページを参照してください。

配列ジョブは、通常のジョブで使用可能な Grid Engine システムの全機能にフルアクセスできます。特に、配列ジョブは同時に並列ジョブとなることもできます。配列ジョブも、その他のジョブと相互依存関係を持つことができます。

注 –

配列タスクは、その他のジョブまたはその他の配列タスクとの相互依存関係を持つことはできません。

コマンド行からの配列ジョブの発行

コマンド行から配列ジョブを発行するには、適切な引数を指定して qsub コマンドを入力します。

次に、配列ジョブの発行方法の例を示します。


% qsub -l h_cpu=0:45:0 -t 2-10:2 render.sh data.in

-t オプションは、タスクインデックスの範囲を指定します。この場合、2-10:2 は、2 が最小インデックス番号で、10 が最大インデックス番号という範囲を指定します。 :2 という指定により、1 つ飛ばしのインデックスだけが指定されます。よって、配列ジョブはタスクインデックス 2、4、6、8、10 の 5 つのタスクによって構成されます。各タスクは、-l オプションで 45 分のハード CPU 時間制限を要求します。タスクが Grid Engine システムによって振り分けられ、開始されると、各タスクはジョブスクリプト render.sh を実行します。タスクは SGE_TASK_ID を使用してインデックス番号を探し、その番号を使用してデータファイル data.in 内の入力データレコードを見つけることができます。

対話型ジョブの発行

ユーザーが直接入力を行い、ジョブの結果に影響を与える場合は、 バッチジョブの代わりに対話型ジョブを発行すると便利です。このような場面は、X ウィンドウアプリケーションや、さらに処理を進めるためにユーザーが結果をすぐに解釈しなければいけないタスクなどで一般的に見られます。

対話型ジョブは、次の 3 つの方法で作成できます。

対話型ジョブのデフォルト処理は、バッチジョブの処理とは異なります。発行時に実行できなかった場合、対話型ジョブはキューには入れられません。ジョブがキューに入れられないということは、ジョブの発行時に対話型ジョブを振り分ける適切なリソースが十分なかったということです。クラスタが現在ビジー状態になっている場合は、ユーザーに通知が行われます。

このデフォルト動作は、qsh、 qlogin、および qrsh の -now no オプションで変更できます。このオプションを使用すると、対話型ジョブはバッチジョブのようにキューに入れられます。また、-now yes オプションを使用して、qsub で発行されたバッチジョブを対話型ジョブのように処理することもできます。この場合のバッチジョブはすぐに実行のために振り分けられるか、拒否されます。

注 –

対話型ジョブは、INTERACTIVE タイプのキュー内でのみ実行されます。詳細は、『Sun N1 Grid Engine 6.1 管理ガイド』の「キューの構成」を参照してください。

次の節では、qlogin と qsh 機能の使用方法について説明します。qrsh コマンドは、「透過的なリモート実行」のより広い文脈で説明します。

QMON による対話型ジョブの発行

QMON から発行できる対話型ジョブは、Grid Engine システムが選択したホストで xterm を発行するジョブだけです。

「Interactive」アイコンが表示されるまで、「Submit Job」ダイアログボックスの右側の「Submit」ボタンの上にあるボタンをクリックします。これにより、対話型ジョブを発行するための「Submit Job」ダイアログボックスの準備が整えられます。図 3–8 と図 3–9 を参照してください。

ダイアログボックスの選択オプションの意味と使用方法は、「バッチジョブの発行」のバッチジョブの説明と同じです。違いは、対話型ジョブには適用されない入力フィールドがグレー表示になっていることです。

図 3–8 「Interactive Submit Job」ダイアログボックス、「General」タブ

図 3–9 「Interactive Submit Job」ダイアログボックス、「Advanced」タブ

qsh による対話型ジョブの発行

qsh は、qsub と非常に似ています。qsh は、いくつかの qsub オプション、および呼び出される xterm の表示を指示する追加オプション -display をサポートしています。詳細は、 qsub(1) のマニュアルページを参照してください。

qsh で対話型ジョブを発行するには、次のようなコマンドを入力します。


% qsh -l arch=solaris64

このコマンドは、使用可能な任意の Sun Solaris 64 ビットオペレーティングシステムのホストで xterm を開始します。

qlogin による対話型ジョブの発行

端末または端末エミュレーションで qlogin コマンドを使用して、Grid Engine システムの制御下で対話セッションを開始します。

qlogin で対話型ジョブを発行するには、次のようなコマンドを入力します。


% qlogin -l star-cd=1,h_cpu=6:0:0

このコマンドは、負荷の少ないホストを特定します。ホストには、有効な Star-CD ライセンスがあります。また、ホストには、最低 6 時間のハード CPU 時間制限を持つキューが 1 つ以上あります。

注 –

Grid Engine システムによって使用されるように設定されているリモートログイン機能によっては、ログインプロンプトでユーザー名、パスワード、またはこの両方を入力しなければならない場合があります。

透過的なリモート実行

Grid Engine システムは、特定のコンピュータ処理タスクの透過的なリモート実行をサポートする密接な関連を持つ機能のセットを提供します。この機能の中心的なツールは、「qrsh によるリモート実行」に説明がある qrsh コマンドです。qtcsh と qmake という 2 つの上位機能が qrsh の上にあります。これらの 2 つのコマンドによって、Grid Engine システムは暗黙的なコンピュータ処理タスクを透過的に分散し、標準的な UNIX 機能である make と csh を拡張できます。qtcsh の説明は、「qtcsh による透過的なジョブの分配」にあります。qmake の説明は、「qmake による並列 Makefile 処理」にあります。

qrsh によるリモート実行

qrsh は、標準 rsh 機能を基に構築されています。rsh の関係については、 sge-root/3rd_party の情報を参照してください。qrsh は、次のようなさまざまな目的に使用できます。

これらの機能によって、qrsh は qtcsh および qmake 機能を実装する主な使用可能インフラストラクチャーとなっています。qrsh は、Grid Engine システムを MPI や PVM などの 並列環境と密接に統合するためにも使用されます。

qrsh による透過的なリモート実行の呼び出し

qrsh コマンドを入力し、次の構文に従ってオプションと引数を追加します。


% qrsh	[options] program|shell-script [arguments] \
	[> stdout] [>&2 stderr] [< stdin]

qrsh は、qsub のほとんどすべてのオプションに対応しています。 qrsh は、次のオプションを提供します。

qtcsh による透過的なジョブの分配

qtcsh は、一般的に使用されるよく知られた UNIX C 派生シェル tcsh の完全な互換性を持つ代用コマンドです。 qtcsh は、tcsh を基に構築されています。tcsh の関係については、sge-root/3rd_party の情報を参照してください。qtcsh は、Grid Engine システムを使用する適切で負荷の少ないホストに指定アプリケーションを透過的に分散する拡張機能をコマンドシェルに提供します。.qtask 構成ファイルには、リモート実行するアプリケーションと、実行ホストの選択に適用される要件が定義されています。

ユーザーに対して透過的なこれらのアプリケーションは、qrsh 機能を使用して Grid Engine システムに発行されます。qrsh は、標準出力、エラー出力と標準入力処理、およびリモート実行アプリケーションへの端末制御接続を提供します。アプリケーションをリモートで実行する場合と同一ホストでシェルとして実行する場合の明確な違いは、3 つあります。

標準的な使用以外に、qtcsh は、サン以外のコードやツールとの統合用に適したプラットフォームでもあります。qtcsh のシングルアプリケーション実行形式は、qtcsh -c app-name です。統合環境内部でこの書式の qtcsh を使用すると、ほぼ永久的に変更の必要がない持続的なインタフェースが表示できます。すべての必要なアプリケーション、ツール、統合、サイト、およびユーザー固有の 構成までもが、適切に定義された .qtask ファイルには含まれています。さらに、すべての種類のシェルスクリプト、C プログラム、および Java アプリケーションでも使用できることもこのインタフェースの長所です。

qtcsh の使用

qtcsh の呼び出しは、 tcsh の呼び出しとまったく同じです。qtcsh は、.qtask ファイルのサポートを提供し、特殊化されたシェル内蔵モードのセットを提供することで、tcsh を拡張します。

.qtask ファイルは次のように定義されます。ファイルの各行は次のような書式を持ちます。


% [!]app-name qrsh-options

最初に付けられるオプションのエクスクラメーションマーク (!) は、グローバルクラスタ .qtask ファイルと qtcsh ユーザーの個人用 .qtask ファイルの定義が相反する場合の優先順位を定義します。グローバルクラスタファイルにエクスクラメーションマークがない場合は、ユーザーファイルの定義がグローバルクラスタファイルの定義より優先されます。グローバルクラスタファイルにエクスクラメーションマークがある場合は、グローバルクラスタファイルの定義が優先されます。

app-name は、qtcsh のコマンド行で入力された場合に、リモート実行向けに Grid Engine システムに発行されるアプリケーション名を指定します。

qrsh-options は、使用される qrsh 機能のオプションを指定します。これらの オプションは、アプリケーションのリソース要件を定義します。

アプリケーション名は、アプリケーションが .qtask ファイルで定義されるのとまったく同じようにコマンド行に表示されなければなりません。アプリケーション名の前にパス名が追加されている場合は、ローカルバイナリがアドレス指定されます。リモート実行は行われません。

csh エイリアスは、アプリケーション名との比較が行われる前に拡張されます。リモート実行向けのアプリケーションは、qtcsh コマンド行のどこででも実行できますが、特に標準入出力先のリダイレクトの前後に実行されます。

よって、次の例は有効で意味のある構文となります。


# .qtask file
netscape -v DISPLAY=myhost:0
grep -l h=filesurfer

この .qtask ファイルを前提とすると、次の qtcsh コマンド行は、


netscape
~/mybin/netscape
cat very_big_file | grep pattern | sort | uniq

暗黙的に次のような結果になります。


qrsh -v DISPLAY=myhost:0 netscape
~/mybin/netscape
cat very_big_file | qrsh -l h=filesurfer grep pattern | sort | uniq

qtcsh は複数のモードで実行でき、オンまたはオフの状態であるスイッチに影響を受けます。

これらのモードの設定は、開始時に qtcsh のオプション引数を使用して、または実行時にシェル内蔵コマンド qrshmode を使用して変更できます。詳細は、 qtcsh(1) のマニュアルページを参照してください。

qmake による並列 Makefile 処理

qmake は、標準的な UNIX make 機能の代わりとなる機能です。qmake は、適切なマシンのクラスタ上で make の各手順の分散を可能にすることにより、make の機能を拡張したものです。qmake は、よく使用される GNU-make 機能の gmake を基に構築されています。gmake の関係については、 sge-root/3rd_party の情報を参照してください。

分散 make プロセスを最後まで実行できるように、 qmake はまず、必要なリソースを並列ジョブと同じような方法で割り当てます。qmake は、次にスケジューリング機能と対話せずに、このリソースのセットを管理します。リソースが使用可能になると、qmake は -inherit オプションを設定した qrsh 機能を使用して、 make の手順を分散させます。

qrsh は、標準出力、エラー出力と標準入力の処理、およびリモートで実行されている make 手順への端末制御接続を提供します。このため、 make 手続きのローカル実行と qmake の使用との間には、明確な違いが 3 つあるだけです。

make がもっとも一般的に使用されるのは、複雑なソフトウェアパッケージのコンパイルです。しかし、qmake はコンパイルにはそれほど使用されないこともあります。プログラムファイルは、適切なプログラミングの結果、かなり小さくなることがよくあります。したがって、1 つのプログラムファイルのコンパイル (1 つの make 手順) は、大部分の場合、数秒しかかかりません。さらに通常、コンパイルでは大量のファイルアクセスが行われます。ネスト化されたインクルードファイルは、この問題の原因となりえます。ファイルサーバーがボトルネックとなることがあるため、複数の make 手順に対してコンパイルを並行して実行した場合、ファイルのアクセス速度を速めることができない場合があります。ボトルネックは、すべてのファイルアクセスを事実上直列化するからです。したがって、満足のいく形ではコンパイルプロセスを高速化できない場合があります。

qmake は、その他の使用方法においてより効果を発揮できます。たとえば、makefile によって相互依存関係や複雑な分析処理の作業フローを管理することができます。この環境での make の各手順は一般的に、無視できないリソースとコンピュータ処理時間要件を持つシミュレーションやデータ分析処理です。この場合は、かなりの高速化を達成できます。

qmake の使用

qmake のコマンド行構文は、qrsh の構文と同じようにみえます。


% qmake [-pe pe-name pe-range][options] \
 -- [gnu-make-options][target]
注 –

-inherit オプションは、この節の後半に説明がある qmake によってもサポートされています。

-pe オプションの使用と gmake -j オプションとの関係に特に注意してください。両方のオプションは、達成する並列化の量を表すために使用できます。違いは、 gmake は -j を使用して、使用される並列環境などを指定できないことです。したがって、qmake は、make と呼ばれる並列 make 用のデフォルト環境が構成されていることを前提にします。さらに、gmake の -j では、範囲の指定はできず、1 つの数字しか設定できません。qmake は、-j によって指定された数字を 1-n の範囲として解釈します。これと対照的に、-pe ではこれらのパラメータすべてを詳細に指定できます。結果として、次の 2 つのコマンド行例の意味は同じになります。


% qmake -- -j 10
% qmake -pe make 1-10 --

次の コマンド行は、-j オプションを使用して表現することはできません。


% qmake -pe make 5-10,16 --
% qmake -pe mpi 1-99999 --

構文以外に、qmake は 2 つの呼び出しモードをサポートしています。-inherit オプションを使用せずにコマンド行から対話方式で呼び出すモードと -inherit オプションによってバッチジョブ内で呼び出すモードがあります。これらの 2 つのモードは、次のような別の処理シーケンスを開始します。

詳細は、qmake(1) のマニュアルページを参照してください。

ジョブのスケジューリング方法

Grid Engine ソフトウェアのポリシー管理では、管理目標を最適な形で達成するために、クラスタ内の共有リソースの使用を自動的に制御します。優先順位の高いジョブは優先的に振り分けられ、リソースにより多くアクセスできます。クラスタ管理では、ハイレベルの使用ポリシーを定義できます。次のポリシーが使用可能です。

Grid Engine ソフトウェアは、共有ベースのポリシー、機能ポリシー、または両方を日常的にに使用するように設定できます。これらのポリシーはどんな割合で組み合わせることもできます。1 つのポリシーの重みを 0 にして 2 番目のポリシーだけを使用することも、両方のポリシーに同じ重みを与えることもできます。

ルーチンポリシーに加えて、ジョブに開始期限を付けて発行することもできます。「QMON による高度なジョブの発行」の期限発行パラメータの説明を参照してください。期限ジョブは、ルーチンスケジューリングに干渉します。管理者は、共有ベーススケジューリングと機能スケジューリングを一時的に無効にすることもできます。無効は、個別ジョブ、あるユーザーに関連するすべてのジョブ、部門、またはプロジェクトに対して適用できます。

ジョブの優先順位

すべてのジョブ間で調整を行う 4 つのポリシー以外に、Grid Engine ソフトウェアではユーザーが自分のジョブ間の優先順位を設定できる場合もあります。複数のジョブを発行したユーザーは、たとえば、ジョブ 3 が一番重要で、ジョブ 1 と 2 の重要度は同じだが、ジョブ 3 よりは重要ではないなどと指定することができます。

ジョブの優先順位は、QMON Submit Job パラメータ Priority または qsub -p オプションを使用して設定します。1024 (最低) から 1023 (最高) の優先順位範囲を指定できます。優先順位によって、同時に 1 人のユーザーの複数のジョブがシステム内に存在する場合に、どのようにしてそのユーザーのジョブから選択を行うかがスケジューラに伝えられます。特定のジョブに割り当てられる相対的な重要度は、ユーザーのジョブに対して指定された最高と最低の優先順位、および特定のジョブの優先順位によって異なります。

チケットポリシー

機能ポリシー、共有ベースのポリシーおよび優先ポリシーはすべて、チケットを使用して実行されます。各チケットポリシーには、マルチマシン Grid Engine システムに入力されるジョブに割り当てられるチケットの割り当て元であるチケットプールがあります。 有効な各ルーチンチケットポリシーは、複数のチケットをすべての新しいジョブに割り当てます。チケットポリシーは、スケジューリング間隔で実行中のジョブにチケットを再割り当てすることもできます。各チケットポリシーがチケットを割り当てるために使用する条件を、この節で説明します。

チケットは、3 つのポリシーに重み付けを行います。たとえば、機能ポリシーにチケットが割り当てられていない場合、機能ポリシーは使用されません。同じ数のチケットが機能チケットプールと共有ベースのチケットプールに割り当てられている場合は、両方のポリシーがジョブの重要度の決定において等しい重さを持ちます。

Grid Engine 管理者が、システム構成時にチケットをルーチンチケットポリシーに割り当てます。管理者とオペレータは、いつでもチケットの割り当てを変更できます。無効を示すために追加チケットを一時的にシステムに投入することもできます。チケットポリシーは、チケットの割り当てによって組み合わせられます。チケットが複数のチケットポリシーに割り当てられている場合、ジョブは有効な各チケットポリシーから一部のチケットを受け取ります。

Grid Engine システムは、有効な各チケットポリシーでのジョブの重要度を示すために、システムに入力されるジョブにチケットを与えます。実行中の各ジョブは、チケットを優先ポリシーなどから受け取り、ジョブがリソースの適当な共有以上を受け取っている場合などには、チケットを失います。また各スケジューリング間隔で同じ数のチケットを持ち続けます。ジョブが持っているチケットの数は、Grid Engine システムが各スケジューリング間隔でジョブに与えようとするリソース共有を表します。

ジョブが持っているチケットの数は、 QMON または qstat -ext で表示できます。「QMON を使用したジョブの監視と制御」を参照してください。qstat コマンドは、たとえば qsub -p などによって、優先順位を表示することもできます。詳細は、 qstat(1) のマニュアルページを参照してください。

キューの選択

ジョブをすぐに開始できない場合、Grid Engine システムは不定のキューを要求するジョブを振り分けません。このようなジョブは、 ジョブのスケジューリングを適宜試行する sge_qmaster でスプールとしてマークされます。このようなジョブは使用可能になった次の適切なキューに振り分けられます。

スプーリングジョブとは反対に、名前を指定して特定のキューに発行されたジョブは、ジョブを開始できるかスプールする必要があるかに関わらず、そのキューに直接送られます。したがって、名前を指定されたジョブ要求に対してのみ、Grid Engine システムのキューを情報工学で言われるバッチキューとみなすことができます。特定の要求なしで発行されたジョブは、キューに入るために、sge_qmaster のスプーリングメカニズムを使用するので、より抽象的で柔軟なキュー概念が採用されます。

ジョブのスケジューリングを行い、複数の空きキューがリソース要求を満たす場合、ジョブは通常一番負荷が少ないホストに属する適切なキューに振り分けられます。スケジューラ 構成エントリ queue_sort_method を seq_no に設定すると、クラスタ管理でこの負荷に依存したスキームを固定順のアルゴリズムに変更できます。キュー構成エントリ seq_no は、キュー間の優先順位を定義し、一番高い優先順位をシーケンス番号が一番小さいキューに割り当てます。