レベル: 初級 Jeff Mausolf (mausolf@us.ibm.com), IT Architect, IBM Global Services, Global Technology Center, Grid Computing Initiative
2006年 7月 18日 IBM® Tivoli® Workload Scheduler LoadLeveler® は、AIX® および Linux® 対応の拡張スケジューリング・システムです。この記事では、この製品の概要を紹介し、LoadLeveler 環境でジョブを実行依頼、監視、そして制御する方法を説明します。
はじめに
IBM Tivoli Workload Scheduler (TWS) LoadLeveler は、大量の計算ジョブでのリソース使用率とスループットを最大限にするために開発されたジョブ・スケジューリング・システムです。これは当初、AIX を対象に開発されたものですが、現在は Linux にも対応します。TWS LoadLeveler は、優先順位、リソース要件、そしてリソースの可用性に基づいて逐次または並行ジョブをスケジュールします。このシステムは、分散されたリソース全体での実行ジョブの管理、実行、およびアカウンティングの詳細を処理します。
この記事では、TWS LoadLeveler システムの概要とともに、この環境でのジョブの作成および実行に関連したコンセプトについて紹介します。サンプル・ジョブの開発をとおして、ジョブの作成、実行依頼、管理について説明していきます。
TWS LoadLeveler の動作
TWS LoadLeveler プールとは、協調して高スループットのコンピューティング環境を作り出すマシンの集合のことです。このプールは、スケジューラー、セントラル・マネージャー、そして複数の計算ノードからなる分散コンピューティング・クラスターとして考えられます。ユーザーがジョブを実行依頼すると、そのジョブはスケジューラーが管理するジョブ待ち行列に追加されます。
スケジューラーは各ジョブに固有の ID を割り当て、リソースを必要とする新しいジョブがあることをセントラル・マネージャーに通知します。
セントラル・マネージャーは、そのジョブを処理するために使用可能なリソースがあるかどうかを確認します。適切なリソースを見つけるため、ジョブの要件を調べ、使用可能なリソースがその要件に対応できるかどうかを確認します。セントラル・マネージャーは、ジョブ要件に対応可能なリソースを見つけると、これをスケジューラーに通知します。スケジューラーは、この選択されたリソースに接続してジョブの実行を要求します。
計算リソースは、ジョブ実行依頼者のユーザー ID で実行する子プロセスを fork して、ジョブを実行します。ジョブが開始されると、計算リソースはセントラル・マネージャーにジョブが実行中であることを通知します。ジョブが完了すると、LoadLeveler はジョブが使用したリソースに関するアカウンティング情報を生成します。
TWS LoadLeveler を構成するプロセス
多くのプロセスが協調して、この高スループットのコンピューティング環境を実現しています。これらのプロセスは、スケジューラー、セントラル・マネージャー、または計算ノードで実行されるものです。以下に、TWS LoadLeveler 環境を構成するプロセスを要約します。
マスター
マスター・プロセスは、TWS LoadLeveler プールに含まれるすべてのマシン上で実行されます。このプロセスはローカル側の構成情報を読み取ってから、そのマシン上で実行しなければならないその他のプロセスを開始します。マスター以外のプロセスは、そのマシンが計算ノード、スケジューラー、またはセントラル・マネージャーのどれであるかによって異なります。該当するプロセスを開始した後、マスターはこれらのプロセスを監視し、プロセスが失敗するとこれを再開します。プロセスを再開する場合、マスターは管理者にこの問題を Eメールで送信し、失敗したプロセスに関する情報 (終了ステータスやログ・ファイルなど) を提供します。
スケジューラー
スケジューラーはジョブ待ち行列を管理します。スケジューラーがユーザーからのジョブ実行要求を受け取ると、それぞれの新規ジョブに固有の ID を割り当てます。ジョブ要求があることをセントラル・マネージャーに通知し、セントラル・マネージャーがジョブに適切なリソースを特定すると、スケジューラーはジョブを処理するためのシャドー・プロセスを作成します。シャドー・プロセスは計算リソースで実行されるジョブを監視し、ジョブの完了時にスケジューラーに通知します。スケジューラーはこの情報をセントラル・マネージャーに転送します。
シャドー
セントラル・マネージャーがジョブのリソースを選択すると、スケジューラーによってシャドー・プロセスが開始されます。シャドー・プロセスは、ジョブを実行するために選択された計算リソース上の startd プロセスに接続します。すると startd プロセスによって、ジョブの実行を管理するためのスターター・プロセスが作成されます。シャドー・プロセスは、このスターター・プロセスに実行可能プログラムと関連ジョブ情報を送ります。ジョブが完了すると、シャドー・プロセスはスターター・プロセスからジョブの終了ステータスを受け取り、これをスケジューラーに送って終了します。
startd
計算ノードは、startd と呼ばれる開始プロセスを実行します。計算ノードがスケジューラーからジョブの実行要求を受け取ると、startd プロセスがスターター・プロセスを作成し、ジョブならびにマシン上のリソースを監視します。startd はこの情報をセントラル・マネージャーに転送し、セントラル・マネージャーがこの情報を考慮して他のジョブをリソースにマッチングできるようにします。ジョブが完了すると、startd はマシンの状態およびジョブのリソース使用量に関する情報を収集めます。この情報は、アカウンティングのためにセントラル・マネージャーに送信されます。
スターター
startd プロセスはジョブを実行するために、スターター・プロセスを作成します。このプロセスはスケジューリング・マシン上のシャドー・プロセスに接続して、実行可能プログラムとその他のジョブ関連情報を取得します。このプロセスは、ジョブ実行依頼者のユーザー ID で実行する子プロセスを fork することによってジョブを実行し、セントラル・マネージャーにジョブが実行中の状態であることを通知します。子プロセスがジョブの実行を終えると、スターター・プロセスはジョブの終了ステータスをシャドー・プロセスに戻します。シャドー・プロセスはこの情報をスケジューラーに転送して終了します。
セントラル・マネージャー
セントラル・マネージャーは、プール内のすべてのリソースを把握し、ジョブとマシンに関するステータス情報を管理します。マシン情報には、使用可能なリソースを記述する属性のリストが含まれます。セントラル・マネージャーはスケジューラーから新規ジョブの存在についての通知を受け取ると、マシンのリソース属性を調べて、ジョブ要件に対応可能なマシンを決定します。適切なリソースが特定されると、セントラル・マネージャーはジョブの状態を pending に設定し、スケジューラーに該当リソースでそのジョブを実行するように要求します。
TWS LoadLeveler ユーザーのビュー
これまでの説明で、TWS LoadLeveler プール内のマシンとプロセスが協調して、高スループットのコンピューティング環境を提供する方法については、基本的なところは理解できたはずです。
TWS LoadLeveler ジョブ・クラス
TWS LoadLeveler では、リソースでジョブをスケジュールするためにクラスを使用します。ジョブ・クラスによって、ジョブのタイプに関連付けられた優先順位、実行制限、リソースなどの特性が定義されます。管理者は、ジョブ・クラスを作成してわかりやすい名前を付け、ユーザーがそれぞれのジョブがどのジョブ・クラスに対応するかを簡単に見分けられるようににしてください。TWS LoadLeveler のデフォルト・ジョブ・クラスには、small、medium、large、very long、parallel、interactive などがあります。管理者はこれ以外のジョブ・クラスを作成できます。
マシン上で実行可能なジョブ・クラスは、リソースの所有者または管理者が決定します。マシンが許容するジョブ・クラスと、リソースで実行できる各クラスのジョブ数を指定してください。以下の構成例では、マシン上で 8 つの小規模ジョブ、5 つの中規模ジョブ、そして 2 つの大規模ジョブを実行可能であることを指定しています。
CLASS = small(8) medium(5) large(2)
|
TWS LoadLeveler の消費リソース
各マシンに関連付けられた CPU、メモリー、ディスク・スペースなどの属性は、消費リソースとして見なされます。これらのリソースは、ジョブによって指定された量が使用され、ジョブの完了時に解放されるという意味で消費されます。消費リソースは、特定のマシンあるいはクラスター全体に対して指定できます。
マシンのリソースには、そのマシンで使用できる CPU、メモリー、そしてディスク・スペースなどがあります。フローティング・ライセンスのソフトウェアなどの浮動リソースは、クラスター内のマシン全体で使用できます。プール内のマシンおよび浮動消費リソースは、管理者が指定します。セントラル・マネージャーはこれらのリソースを考慮して、ジョブをリソースにマッチングします。ジョブに必要なリソースは、ユーザーがジョブを実行依頼するときに指定します。セントラル・マネージャーは、ジョブに必要な消費リソースを調べ、マシン上で使用可能な消費リソースを確認してジョブを実行する場所を決定します。
ジョブがあるマシン上で実行されるようにスケジュールされると、セントラル・マネージャーはそのマシン上の消費リソースをそのジョブに必要な量だけ減らします。ジョブが完了すると、消費リソースは同じ量だけ増加されます。
TWS LoadLeveler スケジューラー
TWS LoadLeveler には複数のスケジューリング・アルゴリズムがあり、実行する必要のあるジョブのタイプに応じて使用できます。管理者は、使用するスケジューリング・アルゴリズムを TWS LoadLeveler 管理構成ファイルに指定します。TWS LoadLeveler には、デフォルト、バックフィル、およびギャング・スケジューラーが提供されています。
デフォルト・スケジューラー
デフォルト・スケジューラーは、アイドル・リソースにジョブをスケジュールして実行します。デフォルト・スケジューラーは作業負荷に基づいてジョブを開始、中断、再開します。このスケジューラーは逐次ジョブの処理には非常に優れている一方、並行ジョブのスケジューリングは予約によって行います。並行ジョブがスケジュールされた場合、ノードは使用可能になると同時に予約されます。予約されたノードは、並行ジョブを実行するのに十分なノードが使用可能になるまでアイドル状態になります。このように、このプロセスでは十分な数の予約済みノードが揃うまでノードがアイドル状態のままになるため、大量の並行ジョブをスケジュールすると全体的な使用率が下がります。
バックフィル・スケジューラー
バックフィル・スケジューラーは、大量の並行ジョブをリソースの複数のブロックにスケジュールしてから、ブロック間のギャップを埋めるための小規模なジョブを探します。このバックフィル・アルゴリズムでは、大規模なジョブが十分なノードが実行するまで待機する間に、必要なリソース数が少ない短時間のジョブが実行されます。短時間のジョブは、大規模なジョブの開始を遅らせることがない限り、アイドル・リソース上で実行することができます。
スケジューラーは、大規模ジョブの予測開始時間を小規模ジョブの wall_clock_limit と比較することによって、その小規模ジョブを実行できるかどうかを決定します。つまり、小規模ジョブが大規模ジョブの予測開始時間より前に完了するようであれば、実行を許可します。バックフィル・スケジューラーを使用するには、ユーザーがジョブの wall_clock_limit を設定するか、または管理者がそれぞれのジョブ・クラスに wall_clock_limit を設定する必要があります。
wall_clock_limit は、ジョブが完了するまでの所要時間の上限です。ジョブの実行時間がこのウォール・クロック時間を超えるとランナウェイと見なされ、ジョブが終了されます。厳しい制限のように見えますが、ジョブの実行時間を正確に予測することによって、スケジューラーが一層効率的にスケジューリングを行うことが可能になります。
ギャング・スケジューラー
ジョブの開始時間は、待ち行列内でそのジョブの前にあるジョブと、実行中のジョブの完了時間によって決まります。長時間実行するジョブは、他のジョブの開始を遅らせることになります。タイム・シェアリングは、ジョブに対する処理時間少しずつ割り振る機能です。ギャング・スケジューラーは、コンテキスト・スイッチを使用して、タイム・シェアリングとスペース・シェアリングをサポートするオペレーティング・システムのように動作します。このギャングとは、1 つのジョブに関連付けられたタスクのグループのことです。これらのタスクは複数のマシンで同時に実行するようにスケジュールされ、それぞれのタスクに短時間の実行時間が割り振られます。
作業を開始する
ジョブ・コマンド・ファイル
ユーザーはまずジョブ・コマンド・ファイルにジョブを記述し、ジョブを実行するためにこのコマンド・ファイルを TWS LoadLeveler に実行依頼します。
以下の例では、TWS LoadLeveler の機能を説明するために、サンプル・ジョブを実行依頼するための単純なコマンド・ファイルを作成します。コマンド・ファイルには、ジョブを記述し、バージョンの履歴と変更を追跡するためのコメントが組み込まれていなければなりません。行の先頭にあるシャープ記号 (#) は、コメントを示します。シャープ記号の次にアットマーク (@) が続く場合、これはキーワードを示します。キーワードは、ジョブに関連付けられた入力ファイル、出力ファイル、エラー・ファイル、そしてジョブ・クラスを指定するために使用されます。管理者によって事前定義されたクラスを調べるには、 llclass コマンドを使用します。
リスト 1. llclass コマンド
[loadl@blade31 loadl]$ llclass
Name MaxJobCPU MaxProcCPU Free Max Description
d+hh:mm:ss d+hh:mm:ss Slots Slots
--------------- -------------- -------------- ----- ----- ---------------------
large undefined undefined 2 2
medium undefined undefined 5 5
small undefined undefined 8 8
|
-l フラグを使用すると、ジョブ・クラスに関する追加情報が表示されます。
リスト 2. llclass コマンド引数
[loadl@blade31 loadl]$ llclass -l large
=============== Class large ===============
Name: large
Priority: 0
Exclude_Users: adams
Include_Users:
Exclude_Groups:
Include_Groups: staff
Admin:
NQS_class: F
NQS_submit:
NQS_query:
Max_processors: -1
Maxjobs: -1
Resource_requirement:
Class_comment: large job class for grid integration center cluster
Class_ckpt_dir:
Ckpt_limit: undefined, undefined
Wall_clock_limit: 00:30:00, undefined (1800 seconds, undefined)
Def_wall_clock_limit: 00:30:00, undefined (1800 seconds, undefined)
Job_cpu_limit: undefined, undefined
Cpu_limit: undefined, undefined
Data_limit: undefined, undefined
Core_limit: undefined, undefined
File_limit: undefined, undefined
Stack_limit: undefined, undefined
Rss_limit: undefined, undefined
Nice: 0
Free_slots: 2
Maximum_slots: 2
Execution_factor: 1
Max_total_tasks: -1
Max_proto_instances: 2
Preempt_class:
Start_class:
User default: maxidle(-1) maxqueued(-1) maxjobs(-1) max_total_tasks(-1)
|
以下のコマンド・ファイルは小規模ジョブを対象としたもので、エラーを simple.err ファイルに、出力を simple.out ファイルに送信し、ジョブを待ち行列に入れます。ジョブはスリープ状態になってから、ジョブ名とホスト名をエコー出力します。この sleep コマンドは、ジョブが完了する前にジョブのステータスを確認できるようにするために挿入されています。
リスト 3. ジョブ・コマンド・ファイル
#
# Simple sample script that will demonstrate submitting jobs to LL
#
# @ class = small
# @ error = simple.err
# @ output = simple.out
# @ queue
#
sleep 60
echo Job $0 is running on `hostname`
|
ジョブの実行依頼
ジョブを実行するには、llsubmit コマンドの後にコマンド・ファイルを指定します。
[loadl@blade31 loadl]$ llsubmit simple.cmd
llsubmit: The job "blade31.austin.ibm.com.15" has been submitted.
|
ジョブのステータス
ジョブを実行依頼した後にそのステータスを表示するには、llq コマンドを使用します。
リスト 4. llq コマンド
[loadl@blade31 loadl]$ llq
Id Owner Submitted ST PRI Class Running On
------------------------ ---------- ----------- -- --- ------------ -----------
blade31.15.0 loadl 5/12 14:02 R 50 small blade31
1 job step(s) in queue, 0 waiting, 0 pending, 1 running, 0 held, 0 preempted
|
クラスターのステータス
プール内に含まれるすべてのリソースのステータスを表示するには、llstatus コマンドを使用します。
リスト 5. llstatus コマンド
[loadl@blade31 loadl]$ llstatus
blade31.austin.ibm.com Avail 1 1 Run 1 2.00 0 i386 Linux2
i386/Linux2 1 machines 1 jobs 1 running
Total Machines 1 machines 1 jobs 1 running
The Central Manager is defined on blade31.austin.ibm.com
The BACKFILL scheduler is in use
All machines on the machine_list are present.
|
ジョブが完了すると、TWS LoadLeveler が実行依頼者に通知し、Eメールでジョブ要約情報を送ります。
リスト 6. 通知
From loadl@blade31.austin.ibm.com Tue May 16 10:03:53 2006
Date: Tue, 16 May 2006 10:03:53 -0500
From: loadl@blade31.austin.ibm.com
To: mausolf@blade31.austin.ibm.com
Subject: blade31.austin.ibm.com.16
From: LoadLeveler
LoadLeveler Job Step: blade31.austin.ibm.com.16.0
Executable: /home/mausolf/simple.cmd
Executable arguments:
State for machine: blade31.austin.ibm.com
LoadL_starter: The program, simple.cmd, \
exited normally and returned an exit code of 0.
This job step was dispatched to run 1 time(s).
This job step was rejected by Starter 0 time(s).
Submitted at: Tue May 16 09:58:52 2006
Started at: Tue May 16 09:58:53 2006
Exited at: Tue May 16 10:03:53 2006
Real Time: 0 00:05:01
Job Step User Time: 0 00:00:00
Job Step System Time: 0 00:00:00
Total Job Step Time: 0 00:00:00
Starter User Time: 0 00:00:00
Starter System Time: 0 00:00:00
Total Starter Time: 0 00:00:00
|
上記のコマンド・ライン・インターフェースではなく、グラフィカル・ユーザー・インターフェース (GUI) を使用したいというユーザーのために、xloadl も用意されています。
図 1. xloadl -- 実行依頼するジョブの選択
図 2 に、xload GUI によって表示したジョブのステータスを示します。
図 2. xloadl -- ステータス
まとめ
TWS LoadLeveler では、セントラル・マネージャーがプール内のすべてのリソースを把握します。これは、各マシンがそのマシンで使用可能なリソースに関する情報をセントラル・マネージャーに送信するためです。
ユーザーがジョブを実行依頼すると、そのジョブはスケジューラーによってジョブ待ち行列に入れられます。スケジューラーは、セントラル・マネージャーと協調してジョブ要件を満たすリソースを特定し、ジョブを実行するために選択されたリソースに接続します。ユーザーが TWS LoadLeveler にジョブを実行依頼する際には、コマンド・ラインまたは xloadl GUI を使用できます。TWS LoadLeveler は、ジョブを実行する時間と場所の決定に関わるすべての複雑な問題を処理して、ジョブのスループットとリソースの使用率を最大限にします。
TWS LoadLeveler V8.3 は、AIX および Linux に対応しています。
参考文献 学ぶために
製品や技術を入手するために
議論するために
著者について  | 
| | Jeff Mausolf は、テキサス州オースティンの IBM Grid Integration Center (Global Technology Integration and Management Competency の一部) の認定 IT アーキテクトです。アプリケーション・アーキテクト兼ソフトウェア・エンジニアとして、商用および政府機関のポータルを開発してきました。彼はグリッド・コンピューティング・イニシアチブの一員として、グリッド・サービスの開発に関する IBM Redbook の著作を含め、多数のグリッド・プロジェクトに携わっています。14 年前に IBM に入社する以前は、Lockheed、Loral、そして NASA の Ford AeroSpace で働いていました。ジョンソン宇宙センターでは、シャトル・エンジニアリング・シミュレーション (SES) 研究所で宇宙飛行士のミッション・トレーニングを支援し、宇宙ステーションのコンポーネントの構築ならびにスペース・シャトルの AP101S 汎用コンピューター (GPC) に取り組んだ経歴を持ちます。 |
記事の評価
| 
