Grid Workflow SchedulerGrid Workflow Scheduler高橋 慧高橋 慧

2

Grid Scheduler とはGrid Scheduler とはたくさんの逐次タスクを、グリッド上で

効率よく簡単に実行するシステムタスク分配ファイル転送

逐次のアプリケーションを書き換えることなく、手軽にグリッドの能力を発揮できる

たくさんの逐次タスクを、グリッド上で効率よく簡単に実行するシステムタスク分配ファイル転送

逐次のアプリケーションを書き換えることなく、手軽にグリッドの能力を発揮できる

3

依存性のあるジョブへの対応依存性のあるジョブへの対応Workflow とは ( 特に Scientific Workflow)

複数のタスクの実行手順を記述したもの依存性を持ち、主に DAG によって表される

Workflow のスケジューリング多くの考慮すべき条件

データの場所 (locality)前のジョブの終了時間

賢い戦略が必要になる

Workflow とは ( 特に Scientific Workflow)

複数のタスクの実行手順を記述したもの依存性を持ち、主に DAG によって表される

Workflow のスケジューリング多くの考慮すべき条件

データの場所 (locality)前のジョブの終了時間

賢い戦略が必要になる

4

実例 1 : 自然言語処理実例 1 : 自然言語処理単語の用例別統計の抽出

パーズ後、キーワードごとの用例を抽出単語の用例別統計の抽出

パーズ後、キーワードごとの用例を抽出

Corpus Phrases(by words)

Corpus

Corpus

ParsedCorpus

ParsedCorpus

ParsedCorpus

Phrases (by words)

Phrases (by words)

Concurrenceanalysis

Concurrenceanalysis

Concurrenceanalysis

5

実例 2 : 量子化学実例 2 : 量子化学FMO (Fragment Molecular Orbital)

部分に分けて量子シミュレーションを行う部分計算後につなぎ合わせる「補正」を行

う部分構造の結果を使い回せる

例えば CH3 や OH など

FMO (Fragment Molecular Orbital)部分に分けて量子シミュレーションを行う部分計算後につなぎ合わせる「補正」を行

う部分構造の結果を使い回せる

例えば CH3 や OH など

( 但し扱うデータサイズは小さい )

6

スケジューリング戦略 [1]スケジューリング戦略 [1]

スケジュラーの構成 集中的 : 一つのスケジュラーが全プロセッサを担当 階層的 : クラスタ単位でのスケジューリングを行い、

　　　　　　細かいタスク割り当ては各クラスタで行う 分散的 : 全体を統括するスケジュラーを持たない

リソースとタスクの割り当て (Planning Scheme) 静的 : 実行前に決める

実行時間予測が必要 動的 : 実行中に決める

Matchmaking ( 性能・ data locality などを考慮 )完全に動的だと、賢い戦略は取りにくい

スケジュラーの構成 集中的 : 一つのスケジュラーが全プロセッサを担当 階層的 : クラスタ単位でのスケジューリングを行い、

　　　　　　細かいタスク割り当ては各クラスタで行う 分散的 : 全体を統括するスケジュラーを持たない

リソースとタスクの割り当て (Planning Scheme) 静的 : 実行前に決める

実行時間予測が必要 動的 : 実行中に決める

Matchmaking ( 性能・ data locality などを考慮 )完全に動的だと、賢い戦略は取りにくい

[1] Srikumar Venugopal, et al., "A taxonomy of Data Grids for distributed data sharing, management, and processing” ACM Computing Surveys (CSUR) archive Vol.38, Issue 1 (2006)

7

既存システム既存システムWorkflow に対応したスケジュラー

Condor DAGManPegasus (DAGMan の改良 )

Triana, JOperaGrADS

スケジュラーではないけど…DmakeDistCC

Workflow に対応したスケジュラーCondor DAGMan

Pegasus (DAGMan の改良 )Triana, JOperaGrADS

スケジュラーではないけど…DmakeDistCC

8

DAGMan[2] : 動的に配分DAGMan[2] : 動的に配分最も有名な Grid Scheduler

単一ジョブ : Condor-Gデータ転送 : StorkWorkflow : DAGMan

DAGMan は依存性を解析し、 Condor とStork に ( ばらばらに ) ジョブを投入Data Intensive アプリでは、データ転送が静的解析により、データ転送時にレプリカ

を作成し、高速化を図る研究もある ( 松岡研 )

最も有名な Grid Scheduler単一ジョブ : Condor-Gデータ転送 : StorkWorkflow : DAGMan

DAGMan は依存性を解析し、 Condor とStork に ( ばらばらに ) ジョブを投入Data Intensive アプリでは、データ転送が静的解析により、データ転送時にレプリカ

を作成し、高速化を図る研究もある ( 松岡研 )

[2] http://www.cs.wisc.edu/condor/

9

Condor のスケジューリングCondor のスケジューリングタスクをキューから一つずつ取り出しMatchmaking によって実行ノードを決

定ノードの利用権限使用可能ディスクサイズノードの混み具合計算元データの場所

タスクをキューから一つずつ取り出しMatchmaking によって実行ノードを決

定ノードの利用権限使用可能ディスクサイズノードの混み具合計算元データの場所

10

Pegasus[3] : Job をグループ化Pegasus[3] : Job をグループ化ジョブをグループ化 ( クラスタリング )

必要とするファイルによって分類クラスタ (site) ごとにジョブを割り当て

密に結合したジョブは近いマシンに実行時間予測はしない静的分析

ジョブをグループ化 ( クラスタリング )必要とするファイルによって分類

クラスタ (site) ごとにジョブを割り当て密に結合したジョブは近いマシンに

実行時間予測はしない静的分析

[3] Luiz Meyeret al., "Planning Spatial Workflows to Optimize Grid Performance” SAC’06, April, 23-27, 2006, Dijon, France.

11

Pegasus での性能改善Pegasus での性能改善4 手法を比較

ランダムクラスタリングキャッシュデータのある場所

でジョブを実行資源を 10% に制限タスクが多くなると

改善が少ない

4 手法を比較ランダムクラスタリングキャッシュデータのある場所

でジョブを実行資源を 10% に制限タスクが多くなると

改善が少ないPrescript : 同時に submit される job

12

GrADS[4] : 実行時間を予測GrADS[4] : 実行時間を予測実行時間を予測

実行モデル + 小さなデータでの挙動CPU ・メモリ・ネットワーク資源の情報浮動小数点演算の割合 など

各タスクを実行するのにかかる時間を予測スケジューリング

三つのヒューリスティクスから最良を選ぶ静的に行う

実行時間を予測実行モデル + 小さなデータでの挙動

CPU ・メモリ・ネットワーク資源の情報浮動小数点演算の割合 など

各タスクを実行するのにかかる時間を予測スケジューリング

三つのヒューリスティクスから最良を選ぶ静的に行う

[4] Anirban Mandal et.al, "Scheduling Strategies for Mapping Application Workflows onto the Grid“, HPDC’05

13

実行時間の予測実行時間の予測静的に全マシンについて計算する

実行時間 = CPU 時間 + データ転送時間Rank(ci, rj) = w1 * eCost(ci, rj) + w2 * dCost(ci, rj)eCost = ( 演算 + キャッシャミス ) / クロックdCost = sum( データサイズ * レイテンシ / バンド幅 )

Rank( 実行予測時間 )

Task 1

Task 2

Task 3

Task 4

Resource 1 10 6 7 5

Resource 2 6 8 4 5

Resource 3 11 12 2 10

14

スケジューリング戦略スケジューリング戦略三つの戦略で別々に計算

Min-min : 各タスクの最短コスト中、最もコストが小さいものを採用

Max-min : 各タスクの最短コスト中、最もコストが大きいものを採用

Sufferage : 各タスクについて、最短コストと二番目に短いコストの差が最も大きいものを採用

最短の総実行時間のものを採用

三つの戦略で別々に計算Min-min : 各タスクの最短コスト中、最もコ

ストが小さいものを採用Max-min : 各タスクの最短コスト中、最も

コストが大きいものを採用Sufferage : 各タスクについて、最短コスト

と二番目に短いコストの差が最も大きいものを採用

最短の総実行時間のものを採用

15

スケジューリング例スケジューリング例Rank Task 1 Task 2 Task 3 Task 4

Resource 1 1 2 10 6

Resource 2 2 5 11 5

Resource 3 3 6 12 4

Rank Task 1 Task 2 Task 3 Task 4

Resource 1 1 2 10 4

Resource 2 2 5 11 5

Resource 3 3 6 12 6

Rank Task 1 Task 2 Task 3 Task 4

Resource 1 1 2 10 4

Resource 2 2 5 11 5

Resource 3 3 6 12 6

Sufferage

2-1=1Sufferage

5-2=3Sufferage

11-10=1Sufferage

5-4=1

Min-min

Min-max

Sufferage

16

実行結果実行結果4 手法を比較

HA : 本手法 ( 正確な予測 + 賢いマッピング )

HC : ラフな予測 + 賢いマッピングRN : ランダムスケジューリングRA : 予測に基づいた重みを付けてランダ

ム

4 手法を比較HA : 本手法 ( 正確な予測 + 賢いマッピ

ング )HC : ラフな予測 + 賢いマッピングRN : ランダムスケジューリングRA : 予測に基づいた重みを付けてランダ

ムMapped tasks Used nodes Exec. time Makespan

17

DistCC / DMakeDistCC / DMake一ファイルずつスケジュールするっぽい一ファイルずつスケジュールするっぽい

all : main echo "done"

main : main.o a.o b.o c.o d.o gcc -o main main.o a.o b.o c.o d.o

a.o : a.c gcc -c a.c

b.o : b.c gcc -c b.c…

rr56428@sx103> dmakedmake: defaulting to parallel mode.sx103.ecc.u-tokyo.ac.jp --> 1 jobcc -c main.csx103.ecc.u-tokyo.ac.jp --> 2 jobsgcc -c a.csx103.ecc.u-tokyo.ac.jp --> 2 jobsgcc -c b.csx103.ecc.u-tokyo.ac.jp --> 2 jobsgcc -c c.csx103.ecc.u-tokyo.ac.jp --> 2 jobsgcc -c d.csx103.ecc.u-tokyo.ac.jp --> 1 jobgcc -o main main.o a.o b.o c.o d.osx103.ecc.u-tokyo.ac.jp --> 1 jobecho "done"sx103.ecc.u-tokyo.ac.jp --> Job outputecho "done"done

newcamelerminelogosgw

18

まとめ ?まとめ ?

実行時間の解析がポイント動的に再計画するといい ?

対象を絞らないと有り難みが無い依存性が少ないData Intensive でない

Dmake の記述性は良いかも

実行時間の解析がポイント動的に再計画するといい ?

対象を絞らないと有り難みが無い依存性が少ないData Intensive でない

Dmake の記述性は良いかも

19

Sun grid engineSun grid engine