Sun and OracleChannel SunHow to BuyLog InDeutsch

N1 Grid Engine 6 ユーザーズガイド
  Suchtext Nur in diesem Buch
Suche Hilfe
Sehen Sie dieses Buch:
Innerhalb
Nach weiteren Dokumenten suchen
Support-Ressourcen
 Dieses Buch im PDF-Format herunterladen (2553 KB)

第 3 章 ジョブの発行

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

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

単純なジョブの発行

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

注 –

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

Vorgehensweiseコマンド行からの単純なジョブの提出方法

すべての 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. 次の単純なジョブスクリプトをクラスタに発行します。

    次のジョブを /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

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


    % qsub simple.sh

    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 システムではじめて実行されるジョブの場合に使用されます。

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

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

手順

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


    % qmon

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

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

    「QMON Main Control」ウィンドウまず「Job Control」ボタンをクリックして、「Submit Jobs」ボタンをクリックしなければならないことを示すコメントを表示します。

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

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

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

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

    「Submit Job」というタイトルのダイアログボックスまずスクリプトボタンをクリックした後、「Submit」ボタンをクリックして、ジョブを発行しなければならないことを示すコメントを表示します。

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

    「Job Control」というタイトルのダイアログボックスジョブ 情報を示す「Running Jobs」タブを表示します。ジョブを操作するボタンを表示します。

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

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

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

    「Select a File」というタイトルのダイアログボックスジョブスクリプトを選択するディレクトリとファイルのリストを表示します。「OK」、「Filter」、「Cancel」および「Help」ボタンを表示します。

  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 にある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 によって決められます。

  • shell_start_mode が unix_behavior に設定されると、スクリプトファイルの 1 行目でコマンドインタプリタが指定されます。スクリプトファイルの 1 行目は、#! で始めてください。1 行目が #! で始まっていない場合、デフォルトでは Bourne シェル sh が使用されます。

  • shell_start_mode のその他のすべての設定では、デフォルトのコマンドインタプリタは、ジョブが開始されるキューの shell パラメータによって決まります。「キューとキュープロパティーの表示」とqueue_conf(5) のマニュアルページを参照してください。

出力のリダイレクト

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

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

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

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

  • HOME – 実行マシン上のホームディレクトリ

  • USER – ジョブ所有者のユーザー ID

  • JOB_ID – 現在のジョブ ID

  • JOB_NAME – 現在のジョブ名。-N オプションを参照してください。

  • HOSTNAME – 実行ホストの名前

  • TASK_ID – 配列ジョブタスクのインデックス番号

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

詳細は、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 の元でサンプルの FORTRAN プログラムを
# コンパイルし、実行するスクリプトファイルの例です。
# Grid Engine に、ジョブの開始時と終了時に 
# メールを送信させるように
# します。

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

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

#$ -o flow.out -j y

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

cd TEST

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

f77 flow.f -o flow

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

flow

環境変数

ジョブが実行されると、多数の変数がジョブの 環境にプリセットされます。次にこれらの変数の一覧を示します。

  • ARC – ジョブが実行されているノードのアーキテクチャー名。この名前は sge_execd バイナリにコンパイルされます。

  • SGE_ROOT – Grid Engine システムのルートディレクトリ。起動する前に sge_execd で設定されたディレクトリ、またはデフォルトの /usr/SGE です。

  • SGE_BINARY_PATH – Grid Engine システムのバイナリがインストールされているディレクトリ。

  • SGE_CELL – ジョブが実行されるセル。

  • SGE_JOB_SPOOL_DIR – ジョブの実行中にジョブ関連データを保存するために sge_shepherd が使用するディレクトリ。

  • SGE_O_HOME – ジョブの発行元になったホスト上にある、ジョブ所有者のホームディレクトリへのパス。

  • SGE_O_HOST – ジョブの発行元になったホスト。

  • SGE_O_LOGNAME – ジョブの発行元になったホストでのジョブ所有者のログイン名。

  • SGE_O_MAIL – ジョブ発行コマンドのコンテキスト内での MAIL 環境変数の内容。

  • SGE_O_PATH – ジョブ発行コマンドのコンテキスト内での PATH 環境変数の内容。

  • SGE_O_SHELL – ジョブ発行コマンドのコンテキスト内での SHELL 環境変数の内容。

  • SGE_O_TZ – ジョブ発行コマンドのコンテキスト内での TZ 環境変数の内容。

  • SGE_O_WORKDIR – ジョブ発行コマンドの作業ディレクトリ。

  • SGE_CKPT_ENV – チェックポイント設定ジョブが実行されるチェックポイント設定環境。チェックポイント設定環境は、qsub -ckpt コマンドで選択されます。

  • SGE_CKPT_DIR – チェックポイント設定インタフェースの ckpt_dir パス。チェックポイント設定ジョブに対してのみ設定されます。詳細は、checkpoint(5) のマニュアルページを参照してください。

  • SGE_STDERR_PATH – ジョブの標準エラーストリームを出力するファイルのパス名。このファイルは、通常プロローグ、エピローグ、並列環境開始スクリプトおよび終了スクリプト、またはチェックポイント設定スクリプトからのエラーメッセージ出力を拡張するために使用されます。

  • SGE_STDOUT_PATH – ジョブの標準出力ストリームを出力するファイルのパス名。このファイルは、通常プロローグ、エピローグ、並列環境開始スクリプトおよび終了スクリプト、またはチェックポイント設定スクリプトからのメッセージ出力を拡張するために使用されます。

  • SGE_TASK_ID – このタスクで表される配列ジョブ内のタスク識別子。

  • ENVIRONMENT – 常に BATCH に設定されます。この変数は、スクリプトがバッチモードで実行されることを示します。

  • HOME – passwd ファイルからのユーザーのホームディレクトリのパス。

  • HOSTNAME – ジョブを実行しているノードのホスト名。

  • JOB_ID – ジョブの発行時に sge_qmaster によって割り当てられる一意の識別子。ジョブ ID は、1 から 9,999,999 の 10 進法の整数です。

  • JOB_NAME – qsub script filename、ピリオド、ジョブ ID で構成されるジョブ名。このデフォルトは、qsub -N で無効にできます。

  • LOGNAME – passwd ファイルからのユーザーのログイン名。

  • NHOSTS – 並列ジョブで使用されるホストの数。

  • NQUEUES – ジョブに割り当てられたキューの数。直列ジョブでは、この数は常に 1 です。

  • NSLOTS – 並列ジョブで使用されるキュースロットの数。

  • PATH – /usr/local/bin:/usr/ucb:/bin:/usr/bin のデフォルトシェル検索パス。

  • PE – ジョブが実行される並列環境。この変数は、並列ジョブでのみ使用されます。

  • PE_HOSTFILE – Grid Engine システムによって並列ジョブに割り当てられた仮想並列マシンの定義を含むファイルのパス。この変数は、並列ジョブでのみ使用されます。このファイルの形式については、「sge_pe」の $pe_hostfile パラメータの説明を参照してください。

  • QUEUE – ジョブが実行されているキューの名前。

  • REQUEST – ジョブの要求名。この名前は、ジョブスクリプトファイル名か、qsub -N コマンドによって明示的にジョブに割り当てられた名前です。

  • RESTARTED – チェックポイント設定ジョブが再開されたかどうかを示します。値が 1 に設定されている場合、ジョブは 1 回以上割り込まれています。よって、ジョブは再開されていることになります。

  • SHELL – passwd ファイルからのユーザーのログインシェル。

    注 –

    SHELL は、ジョブに使用されているシェルとはかぎりません。

  • TMPDIR – ジョブの一時作業ディレクトリへの絶対パス。

  • TMP – TMPDIR と同じです。この変数は、NQS との互換性を確保するために提供されています。

  • TZ – 設定されている場合、sge_execd からインポートされるタイムゾーン変数。

  • USER – passwd ファイルからのユーザーのログイン名。

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

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

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

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

  • Prefix – スクリプト組み込み発行オプションで使用する接頭辞。詳細は、「有効なコメント」を参照してください。

  • Job Script – 使用されるジョブスクリプト。ファイル選択ボックスを開くには、「Job Script」フィールドの右のアイコンをクリックします。ファイル選択ボックスは、図 3–4 に示されています。

  • Job Tasks – 配列ジョブを発行するためのタスク ID の範囲。詳細は、「配列ジョブの発行」を参照してください。

  • Job Name – ジョブの名前。デフォルトは、ジョブスクリプトの選択後に設定されます。

  • Job Args – ジョブスクリプトの引数。

  • Priority – ジョブの初期状態での優先順位を設定するカウントボックス。この優先順位は、1 人のユーザーのジョブ間でのジョブの順番です。優先順位によって、同時に 1 人のユーザーの複数のジョブがシステム内に存在する場合に、どのようにしてそのユーザーのジョブから選択を行うかがスケジューラに伝えられます。

    注 –

    ユーザーが自分のジョブの優先順位を設定できるように、管理者はスケジューラ構成の weight_priority パラメータで優先順位を有効にしなければなりません。詳細は、『N1 Grid Engine 6 管理ガイド』の第 5 章「ポリシーとスケジューラの管理」「Managing Policies and the Scheduler, 」in 『N1 Grid Engine 6 Administration Guide』を参照してください。

  • Job Share – その他のジョブに関連するジョブのチケット共有の定義。ジョブの共有は、共有ツリーポリシーと機能ポリシーにだけ影響します。

  • Start At – ジョブが実行可能とみなされる時点。正しい書式の時間を入力するダイアログボックスを開くには、「Start At」フィールドの右のアイコンをクリックします。

    「Enter a String」というタイトルのダイアログボックス時間値を入力できるフィールドを表示します。「OK」、「Cancel」および「Help」ボタンを表示します。

  • Project – ジョブを下位に持つプロジェクト。「Project」フィールドの右にあるアイコンをクリックして、使用可能なプロジェクトの中からプロジェクトを選択します。

    「Select an Item」というタイトルのダイアログボックス使用可能なプロジェクトのリストと選択されたプロジェクトを示すフィールドを表示します。「OK」、「Cancel」および「Help」ボタンを表示します。

  • Current Working Directory – 現在の作業ディレクトリでジョブを実行するかどうかを示すフラグ。このフラグは、発行ホストと潜在実行ホスト間の同一のディレクトリ階層に対してのみ使用してください。

  • Shell – ジョブスクリプトの実行に使用されるコマンドインタプリタ。詳細は、「コマンドインタプリタの選択方法」を参照してください。ジョブのコマンドインタプリタ指定を入力するダイアログボックスを開くには、「Shell」フィールドの右のアイコンをクリックします。

    「Shell on host」というタイトルのダイアログボックスシェルとその関連ホストのリストを表示します。「Ok」、「Cancel」、「Reset」および「Help」ボタンを表示します。

  • Merge Output – ジョブの標準出力と標準エラー出力を標準出力ストリームにマージするかどうかを示すフラグ。

  • stdout – 使用される標準出力先。詳細は、「出力のリダイレクト」を参照してください。指定がない場合は、デフォルトが使用されます。代わりの出力先を入力するダイアログボックスを開くには、「stdout」フィールドの右のアイコンをクリックします。

    「stdout Path List」というタイトルのダイアログボックスパスとその関連ホストのリストを表示します。「Ok」、「Cancel」、「Reset」および「Help」ボタンを表示します。

  • stderr – 使用される標準エラー出力先。標準出力先と同じようなものです。

  • stdin – 使用される標準入力ファイル。標準出力先と同じようなものです。

  • Request Resources – ジョブのリソース要件を定義するには、このボタンをクリックします。ジョブにリソースが必要な場合、ボタンの色が変わります。

  • Restart depends on Queue – システムクラッシュなどのイベントで中止されたあと、ジョブを再開できるかどうかを定義するには、このボタンをクリックします。このボタンはまた、再開動作をキューによって決めるか、ジョブの要求によって決めるかも制御します。

  • Notify Job – ジョブが一時停止またはキャンセルされる場合に、SIGUSR1 または SIGUSR2 信号によってジョブを通知するかどうかを示すフラグ。

  • Hold Job – ユーザーの待機またはジョブ依存関係がジョブに割り当てられることを示すフラグ。ジョブになんらかの種類の待機が割り当てられている間は、ジョブを実行することはできません。詳細は、「ジョブの監視と制御」を参照してください。「Hold Job」フィールドでは、特定の範囲の配列ジョブのタスクだけに待機を限定することができます。配列ジョブについては、「配列ジョブの発行」を参照してください。

  • Start Job Immediately – 可能であればすぐにジョブを強制的に開始し、不可能な場合は拒否するフラグ。このフラグが選択されている場合、ジョブはキューには入れられません。

  • Job Reservation – リソースをこのジョブ用に予約する必要があることを示すフラグ。詳細は、『N1 Grid Engine 6 管理ガイド』の「リソース予約およびバックフィリング」を参照してください。

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

  • Submit – 現在指定されているジョブを発行します。

  • Edit – vi、または EDITOR 環境変数によって定義されたエディタを使用して、選択したスクリプトファイルを X 端末で編集します。

  • Clear – 指定されたリソース要求など、「Submit Job」ダイアログボックス内のすべての設定を消去します。

  • Reload – 指定したスクリプトファイルを再読込みし、スクリプト組み込みオプションの構文解析やデフォルト設定の構文解析を行い、これらの設定への中間的な手動による変更を廃棄します。詳細は、「有効なコメント」と「デフォルト要求ファイル」を参照してください。この操作は、「Clear」操作の後に前のスクリプトファイルを指定するのと同じです。このオプションが有効なのは、スクリプトファイルがすでに選択されている場合だけです。

  • Save Settings – 現在の設定をファイルに保存します。ファイルを選択するファイル選択ボックスが開かれます。保存されたファイルは、後でロードしたり、デフォルト要求として使用したりできます。詳細は、Load Settingsと「デフォルト要求ファイル」を参照してください。

  • Load Settings – 以前「Save Settings」ボタンで保存した設定を読み込みます。ロードした設定は、現在の設定を上書きします。Save Settingsを参照してください。

  • Done – 「Submit Job」ダイアログボックスを閉じます。

拡張ジョブの例

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

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

「Submit Job」というタイトルのダイアログボックス「General」タブを表示します。表示されているパラメータとボタンは、前の節で説明されています。

この例で設定されているジョブパラメータは、次のような意味を持ちます。

  • ジョブは、スクリプトファイル flow.sh を持っています。このファイルは、QMON の作業ディレクトリになければなりません。

  • ジョブの名前は Flow です。

  • スクリプトファイルは、1 つの引数 big.data を取ります。

  • ジョブは、優先順位 3 で開始されます。

  • ジョブは、2004 年 4 月 22 日の午前 4 時 30 分 44 秒より前には実行できません。

  • プロジェクト定義は、ジョブがプロジェクト crash の下位にあることを示しています。

  • ジョブは、発行作業ディレクトリで実行されます。

  • ジョブは、tcsh コマンドインタプリタを使用します。

  • 標準出力と標準エラー出力は flow.out ファイルにマージされます。このファイルは、現在の作業ディレクトリに作成されます。

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

コマンド行から図 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」タブでは、次の追加パラメータを定義できます。

  • Parallel Environment – 使用される並列環境インタフェース

  • Environment – ジョブの実行前にジョブに対して設定される一連の環境変数。エクスポートする環境変数を定義するダイアログボックスを開くには、「Environment」フィールドの右のアイコンをクリックします。

    「Environment Variable List」というタイトルのダイアログボックス環境変数とその値のリストを表示します。

    環境変数は、QMON の実行環境から取ることができます。また、独自の環境変数を定義することもできます。

  • Context – ジョブ関連情報の保存または転送に使用できる名前と値のペアのリスト。この情報には、クラスタ内のどこからでもアクセスできます。コンテキスト変数は、コマンド行から qsub、qrsh、qsh、qlogin および qalter の -ac、-dc および -sc オプションを使用して変更できます。コンテキスト変数の検索は、 qstat -j コマンドで行えます。

    「Context Variable List」というタイトルのダイアログボックスコンテキスト変数とその値のリストを表示します。「Clear」、「Ok」、「Cancel」および「Help」ボタンを表示します。

  • Checkpoint Object – ジョブのチェックポイント設定が必要で適切な場合に使用されるチェックポイント設定環境。詳細は、「ジョブチェックポイント設定の使用」を参照してください。

  • Account – ジョブと関連付けられるアカウント文字列。アカウント文字列は、ジョブのために維持されるアカウンティングレコードに追加されます。アカウンティングレコードは、あとでアカウンティング分析に使用できます。

  • Verify Mode – ジョブの一貫性チェックモードを決定する確認フラグ。ジョブ要求の一貫性をチェックするために、Grid Engine システムは空で読み込み解除されたクラスタを想定します。システムは、ジョブを実行できるキューを 1 つ以上見つけようとします。次のようなチェックモードを使用できます。

    • Skip – 一貫性はチェックされません。

    • Warning – 不一致は報告されますが、ジョブは受け付けられます。警告モードは、ジョブの発行後にクラスタ構成を変更しなければならない場合に適しています

    • Error – 不一致が報告されます。不一致がある場合、ジョブは拒否されます。

    • Just verify – ジョブは発行されません。ジョブがクラスタ内の各ホストとキューに適しているかどうかについての詳しいレポートが生成されます。

  • Mail – ユーザーに電子メールで通知するイベント。イベントの開始、終了、中止、および一時停止が、現在ジョブに対して定義されています。

  • Mail To – これらの通知を送信する電子メールアドレスのリスト。メーリングリストを定義するダイアログボックスを開くには、「Mail To」フィールドの右のアイコンをクリックします。

    「Send mail to mail address」というタイトルのダイアログボックスメールアドレスのリストとデータ入力フィールドを表示します。「Ok」、「Cancel」、「Delete」、「Reset」および「Help」ボタンを表示します。

  • Hard Queue List、Soft Queue List – ジョブの実行の必須選択項目として必要なキュー名のリスト。「Hard Queue List」と「Soft Queue List」は、対応するリソース要件と同様に処理されます。

  • Master Queue List – 並列ジョブのマスターキューとして実行可能なキュー名のリスト。 並列ジョブはマスターキューで開始されます。ジョブが並列タスクを生成するその他のすべてのキュー は、スレーブキューと呼ばれます。

  • Job Dependencies – 発行したジョブを開始する前に終了しなければならないジョブの ID のリスト。新たに作成されるジョブは、ジョブの完了によって異なります。

  • Deadline – 期限付きジョブの開始期限。開始期限は、期限付きジョブが指定期限前に終了されるために最高の優先順位を持つ時点を定義します。開始期限を決定するには、最高の優先順位での期限付きジョブの実行時間を指定の期限から引いて差を求めます。次のダイアログボックスを開くには、「Deadline」フィールドの右のアイコンをクリックします。

    「Enter a String」というタイトルのダイアログボックス期限を入力できるフィールドを表示します。「OK」、「Cancel」および「Help」ボタンを表示します。
    注 –

    一部のユーザーは、期限付きジョブを発行できません。自分が期限付きジョブを発行できるかどうかは、システム管理者にお問い合わせください。期限付きジョブに与えられる最高の優先順位については、クラスタ管理者にお問い合わせください。

高度なジョブの例

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

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

「Submit Job」というタイトルのダイアログボックス「Advanced」タブを表示します。表示されているパラメータとボタンは、前の節で説明されています。

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

  • 並列環境 mpi を使用する必要があります。4 つ以上のプロセスを作成する必要があり、使用可能な場合、プロセスを 16 個まで使用できます。

  • ジョブに対して 2 つの環境変数が設定され、エクスポートされます。

  • 2 つのコンテキスト変数が設定されます。

  • アカウント文字列 FLOW が、ジョブアカウンティングレコードに追加されます。

  • ジョブの開始と終了直後に、me@myhost.org にメールが送信されます。

  • ジョブは、なるべくキュー big_q 内で実行する必要があります。

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

コマンド行から図 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

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

  • アカウント文字列は、myproject です。

  • ジョブは、現在の作業ディレクトリ内で実行されます。

  • メールの通知は、ジョブの最初と最後に me@myhost.com に送信されます。

  • 標準出力と標準エラー出力はマージされます。

  • 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」ダイアログボックス

「Requested Resources」というタイトルのダイアログボックスハードリソースとソフトリソース、および使用可能なリソースのリストを表示します。

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

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

注 –

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

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

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


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

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

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

  • k – 値に 1000 を掛ける。

  • K – 値に 1024 を掛ける。

  • m – 値に 1000 × 1000 を掛ける。

  • M – 値に 1024 × 1024 を掛ける。

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 を使用して、タスク 2、4、6、8 または 10 であるかどうかを調べます。タスクはインデックス番号を使用して、データファイル data.in 内の入力データレコードを見つけることもできます。

対話型ジョブの発行

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

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

  • qlogin – Grid Engine ソフトウェアが選択したホスト上で開始される telnet のようなセッション。

  • qrsh – 標準的な UNIX rsh 機能と同じ。コマンドは、Grid Engine システムが選択したホスト上でリモート実行されます。コマンドが指定されていない場合は、リモート rlogin セッションがリモートホストで開始されます。

  • qsh – ジョブを実行しているマシンから表示される xterm。表示は、ユーザーの指定または DISPLAY 環境変数の設定に従って設定されます。DISPLAY 変数を設定せず、表示先が定義されていない場合、Grid Engine システムは xterm をジョブが発行された元のホストの X サーバーの 0.0 画面に送ります。

    注 –

    正しい機能のために、すべての機能で Grid Engine システムのクラスタパラメータを正しく構成してください。また、正しい xterm 実行パスを qsh に対して定義してください。この種のジョブでは、対話型キューを使用しなければなりません。クラスタで対話型ジョブを実行できる体制が整っているかどうかについては、システム管理者にお問い合わせください。

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

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

注 –

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

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

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

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

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

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

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

「Submit Job」というタイトルのダイアログボックス対話型ジョブを入れるフィールドを持つ「General」タブを表示します。

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

「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 は、次のようなさまざまな目的に使用できます。

  • 標準的な UNIX 機能である rsh と比較できる Grid Engine システムを使用する対話型アプリケーションのリモート実行。rsh は、HP-UX システムでは remsh とも呼ばれます。

  • Grid Engine システムを使用する対話型ログインセッション機能の提供。標準の UNIX 機能である rlogin に似ています。Grid Engine システムが UNIX telnet 機能を表現するために、qlogin は今でも必要とされます。

  • 端末I/O (標準出力、標準エラーおよび標準入力) および端末制御をサポートするバッチジョブの発行

  • シェルスクリプトに組み込まれていないスタンドアロンプログラムの発行方法の提供

    注 –

    qrsh で --b n オプションを使用してスクリプトを発行することもできます。詳細は、qrsh のマニュアルページを参照してください。

  • バッチジョブが保留中または実行中のときにアクティブのままで、ジョブが終了または取り消されたときだけ停止される発行クライアントの提供

  • 並列ジョブによって割り当てられた分散リソースのフレームワーク内での Grid Engine システム制御によるジョブタスクのリモート実行。『N1 Grid Engine 6 管理ガイド』の「並列環境と Grid Engine ソフトウェアの密統合」を参照してください。

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

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

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


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

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

  • -now yes|no – -now yes は、ただちにジョブのスケジューリングを行うように指定します。適切なリソースを使用できない場合、ジョブは拒否されます。-now yes はデフォルトです。 -now no は、 発行時にジョブを開始できない場合に、バッチジョブのようにジョブをキューに入れるように指定します。

  • -inherit – qrsh は、ジョブタスクを開始するスケジューリングプロセスを実行しません。 qrsh は、そのジョブが、指定されたリモート実行ホスト上に適切な割り当てリソースを持っている並列ジョブに組み込まれているとみなします。この形式の qrsh は一般的に、qmake または密接な並列環境の統合で使用されます。デフォルトでは、外部ジョブ リソースは継承されません。

  • -binary yes|no – n オプションを指定すると、qrsh を使用してスクリプトジョブを発行できます。

  • -noshell – このオプションでは、ユーザーのログインシェルで qrsh に対して指定されているコマンド行は開始されません。このコマンドは、包括するシェルなしで実行されます。このオプションは、シェルの開始およびシェルリソースファイルの調達などのオーバーヘッドを避け、実行速度を速めるために使用してください。

  • -nostdin – 入力ストリーム STDIN を制御します。このオプションを設定すると、qrsh が -n オプションを rsh コマンドに渡します。入力ストリームの抑制は、たとえば make プロセスなどで、qrsh を使用して複数のタスクを並列実行している場合に特に役立ちます。入力を受けるプロセスは未定義です。

  • -verbose – このオプションは、スケジューリングプロセスの出力を表します。-verbose は主にデバッグのために使用されるので、デフォルトではオフになっています。

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

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

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

  • リモートホストの方がより強力で、負荷が少なく、インストールが必要なハードウェアおよびソフトウェアリソースを備えている場合もあります。このようなリモートホストは、アプリケーションをまったく実行できない場合もあるローカルホストより、はるかに実行に適しています。これは当然好ましい違いです。

  • ジョブのリモート起動と Grid Engine システムを通したジョブ処理によって、若干の遅れが生じます。

  • 管理者は、対話型ジョブ (qrsh)、よって qtcsh によるリソースの使用を制限することができます。qrsh によってアプリケーションを開始するのための適切なリソースを十分使用できない場合、またはすべての適切なシステムに負荷がかかりすぎている場合は、暗黙的な qrsh の発行は失敗し、「 Not enough resources ... try later」などの該当エラーメッセージが返されます。

標準的な使用以外に、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 を使用して実行される make の明確な違いは、次の 3 つだけです。

  • それぞれの make 手順が特定の時間を持ち、処理する make 手順がそれぞれ十分にある場合、make プロセスの並列化により処理速度を大幅に上げることができます。これは当然好ましい違いです。

  • リモートで起動される make 手順では、qrsh とリモート実行が原因で少しのオーバーヘッドが生じます。

  • qmake の make 手順の分散を利用するためには、並列化の最低レベルを指定する必要があります。つまり、ユーザーは同時に実行可能な make 手順数を指定しなければなりません。さらに、ユーザーは、有効なソフトウェアライセンス、マシンアーキテクチャー、メモリーまたはCPU 時間要件などの、make 手順に必要なリソースの特徴を指定できます。

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 と呼ばれる並列 makes 用のデフォルト環境が構成されていることを確認します。さらに、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 がコマンド行で呼び出されると、make プロセスは qrsh によって、暗黙的に Grid Engine システムに発行されます。プロセスは、qmake コマンド行で指定されたリソース要件を考慮します。次に Grid Engine システムは、並列 make ジョブに関連付けられた並列ジョブを実行するためのマスターマシンを選択します。Grid Engine システムは、ここで make 手続きを開始します。make プロセスがアーキテクチャーに依存している場合もあるので、手続きはここで開始しなければなりません。必要なアーキテクチャーは、qmake コマンド行に指定されています。マスターマシンの qmake プロセスが、それぞれの make 手順の実行をジョブに割り当てられているその他のホストに委託します。手順は、並列環境ホストファイルによって qmake に渡されます。

  • バッチ – この場合、qmake は -inherit オプションを持つバッチスクリプト内にあります。 -inherit オプションがない場合は、最初の例で説明されているように、新しいジョブが生成されます。これにより、qmake は、qmake が組み込まれているジョブに割り当てられているリソースを利用することになります。 qmake は、qrsh -inherit を直接使用して、 make 手順を開始します。qmake をバッチモードで呼び出すと、リソース要件の指定、-pe オプションおよび -j オプションは無視されます。

    注 –

    1 つの CPU ジョブでも次のように並列環境が必要です。


    qmake -pe make 1 --

    並列実行が必要ない場合は、Grid Engine システムオプションと -- のない gmake コマンド行構文で、qmake を呼び出してください。この qmake コマンドは、gmake のように動作します。

詳細は、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 人のユーザーのジョブ間でのジョブの順番です。優先順位によって、同時に 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 は、キュー間の優先順位を定義し、一番高い優先順位をシーケンス番号が一番小さいキューに割り当てます。