Grid Engine システムは、特定のコンピュータ処理タスクの透過的なリモート実行をサポートする密接な関連を持つ機能のセットを提供します。この機能の中心的なツールは、「qrsh によるリモート実行」に説明がある qrsh コマンドです。qtcsh と qmake という 2 つの上位機能が qrsh の上にあります。これらの 2 つのコマンドによって、Grid Engine システムは暗黙的なコンピュータ処理タスクを透過的に分散し、標準的な UNIX 機能である make と csh を拡張できます。qtcsh の説明は、「qtcsh による透過的なジョブの分配」にあります。qmake の説明は、「qmake による並列 Makefile 処理」にあります。
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 システム制御によるジョブタスクのリモート実行。『Sun N1 Grid Engine 6.1 管理ガイド』の「並列環境と Grid Engine ソフトウェアの密統合」を参照してください。
これらの機能によって、qrsh は qtcsh および qmake 機能を実装する主な使用可能インフラストラクチャーとなっています。qrsh は、Grid Engine システムを MPI や PVM などの 並列環境と密接に統合するためにも使用されます。
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 または密接な並列環境の統合で使用されます。デフォルトでは、外部ジョブ リソースは継承されません。
-noshell – このオプションでは、ユーザーのログインシェルで qrsh に対して指定されているコマンド行は開始されません。このコマンドは、包括するシェルなしで実行されます。このオプションは、シェルの開始およびシェルリソースファイルの調達などのオーバーヘッドを避け、実行速度を速めるために使用してください。
-nostdin – 入力ストリーム STDIN を制御します。このオプションを設定すると、qrsh が -n オプションを rsh コマンドに渡します。入力ストリームの抑制は、たとえば make プロセスなどで、qrsh を使用して複数のタスクを並列実行している場合に特に役立ちます。入力を受けるプロセスは未定義です。
-verbose – このオプションは、スケジューリングプロセスの出力を表します。-verbose は主にデバッグのために使用されるので、デフォルトではオフになっています。
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 の呼び出しは、 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 は、標準的な 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 手順が特定の時間を持ち、処理する make 手順がそれぞれ十分にある場合、make プロセスの並列化により処理速度を大幅に上げることができます。
リモートで起動される make 手順では、qrsh とリモート実行が原因で少しのオーバーヘッドが生じます。
qmake の make 手順の分散を利用するためには、並列化の最低レベルを指定する必要があります。つまり、ユーザーは同時に実行可能な make 手順数を指定しなければなりません。さらに、ユーザーは、有効なソフトウェアライセンス、マシンアーキテクチャー、メモリーまたは CPU 時間要件などの、make 手順に必要なリソースの特徴を指定できます。
make がもっとも一般的に使用されるのは、複雑なソフトウェアパッケージのコンパイルです。しかし、qmake はコンパイルにはそれほど使用されないこともあります。プログラムファイルは、適切なプログラミングの結果、かなり小さくなることがよくあります。したがって、1 つのプログラムファイルのコンパイル (1 つの make 手順) は、大部分の場合、数秒しかかかりません。さらに通常、コンパイルでは大量のファイルアクセスが行われます。ネスト化されたインクルードファイルは、この問題の原因となりえます。ファイルサーバーがボトルネックとなることがあるため、複数の make 手順に対してコンパイルを並行して実行した場合、ファイルのアクセス速度を速めることができない場合があります。ボトルネックは、すべてのファイルアクセスを事実上直列化するからです。したがって、満足のいく形ではコンパイルプロセスを高速化できない場合があります。
qmake は、その他の使用方法においてより効果を発揮できます。たとえば、makefile によって相互依存関係や複雑な分析処理の作業フローを管理することができます。この環境での make の各手順は一般的に、無視できないリソースとコンピュータ処理時間要件を持つシミュレーションやデータ分析処理です。この場合は、かなりの高速化を達成できます。
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 がコマンド行で呼び出されると、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) のマニュアルページを参照してください。