Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
ワークフローシステムPwrakeの耐障害性 / Pwrake FT - GfarmWS2016
Search
Masahiro Tanaka 田中昌宏
October 21, 2016
Technology
0
110
ワークフローシステムPwrakeの耐障害性 / Pwrake FT - GfarmWS2016
Gfarmワークショップ2016@神戸
http://oss-tsukuba.org/event/gw2016
Masahiro Tanaka 田中昌宏
October 21, 2016
Tweet
Share
More Decks by Masahiro Tanaka 田中昌宏
See All by Masahiro Tanaka 田中昌宏
Progress of Ruby-Numo: Numerical Computing for Ruby
masa16tanaka
4
8.1k
Pwrakeチュートリアル / Pwrake Tutorial - GfarmWS2016
masa16tanaka
0
130
Pwrake: Distributed Workflow Engine based on Rake
masa16tanaka
2
4.4k
Other Decks in Technology
See All in Technology
インフラとバックエンドとフロントエンドをくまなく調べて遅いアプリを早くした件
tubone24
1
430
日経電子版のStoreKit2フルリニューアル
shimastripe
1
140
RubyのWebアプリケーションを50倍速くする方法 / How to Make a Ruby Web Application 50 Times Faster
hogelog
3
950
誰も全体を知らない ~ ロールの垣根を超えて引き上げる開発生産性 / Boosting Development Productivity Across Roles
kakehashi
1
230
Application Development WG Intro at AppDeveloperCon
salaboy
0
190
TypeScript、上達の瞬間
sadnessojisan
46
13k
Introduction to Works of ML Engineer in LY Corporation
lycorp_recruit_jp
0
140
DynamoDB でスロットリングが発生したとき_大盛りver/when_throttling_occurs_in_dynamodb_long
emiki
1
430
Incident Response Practices: Waroom's Features and Future Challenges
rrreeeyyy
0
160
Python(PYNQ)がテーマのAMD主催のFPGAコンテストに参加してきた
iotengineer22
0
500
組織成長を加速させるオンボーディングの取り組み
sudoakiy
2
210
The Role of Developer Relations in AI Product Success.
giftojabu1
0
140
Featured
See All Featured
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
93
16k
Typedesign – Prime Four
hannesfritz
40
2.4k
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
159
15k
For a Future-Friendly Web
brad_frost
175
9.4k
Fashionably flexible responsive web design (full day workshop)
malarkey
405
65k
Thoughts on Productivity
jonyablonski
67
4.3k
The MySQL Ecosystem @ GitHub 2015
samlambert
250
12k
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
44
6.8k
Responsive Adventures: Dirty Tricks From The Dark Corners of Front-End
smashingmag
250
21k
Fight the Zombie Pattern Library - RWD Summit 2016
marcelosomers
232
17k
Save Time (by Creating Custom Rails Generators)
garrettdimon
PRO
27
840
Why You Should Never Use an ORM
jnunemaker
PRO
54
9.1k
Transcript
ワークフローシステムPwrake の耐障害性 田中昌宏 筑波大学 計算科学研究センター 2016-10-21 GfarmWS@神戸 1
内容 ▶ 背景 ◦ Pwrakeワークフローシステム ◦ Gfarmファイルシステム ▶ Pwrake耐障害機能の設計と実装 ▶
評価 ◦ 自動複製作成の性能への影響 ◦ 障害発生時のワークフロー継続性 ▶ まとめ 2016-10-21 GfarmWS@神戸 2 HPC155(SWoPP2016)およびMTAGS16で発表
背景:科学データの並列処理 ▶ 観測装置の進化による データ量の増加 ◦ 例:すばる望遠鏡HSC ▶ 計算機クラスタを用いた並列処理 が必要に ▶
並列処理のアプローチ ◦ MPIを用いて並列プログラムを記述 • 実装コストが大きい ◦ ワークフローシステム • 従来のプログラムを並列分散実行 2016-10-21 GfarmWS@神戸 3 すばる望遠鏡 HSC 焦点面CCD 有効視野角: 1.5度角(Suprime-Camの3倍) CCD数: 116枚 1CCD画素数: 4272×2272 一晩で約 300 GB のデータを生成
ワークフローシステムPwrake ▶ Parallel Workflow extension for RAKE ▶ Rake (Ruby版Make)
がベース ◦ ワークフロー記述力が高い ▶ Gfarmファイルシステム ◦ ノード間のファイル共有 ◦ スケーラブルな並列I/O性能 ▶ Pwrakeの実装 ◦ タスクの並列実行・スケジューリング ◦ SSHによるリモートワーカー実行・通信 2016-10-21 GfarmWS@神戸 4 https://github.com/masa16/Pwrake/
Pwrake master fiber pool fiber sh fiber sh fiber sh
pwrake worker communicator Pwrake の構成 Worker nodes Master node enq deq Task Graph Task Queue fiber sh pwrake worker communicator Scheduling Gfarm files files files files process process process process SSH SSH 2016-10-21 5 GfarmWS@神戸
Global Directory Tree / /dir1 file1 file2 /dir2 file3 file4
file2 file3 file1 Metadata Server (MDS) ファイルの実体をFSN のストレージに格納 ディレクトリツ リーやファイ ル格納場所を 管理 File System Nodes (FSN) Local Storage Client Directory lookup File access … compute process local access FSN は 計算 ノードを兼ねる Gfarmファイルシステム ▶ 計算ノードのローカルストレージを束ねて構 成する分散ファイルシステム 2016-10-21 GfarmWS@神戸 6 http://oss-tsukuba.org/software/gfarm
ファイルアクセスパターンとI/O性能 ▶ ファイルアクセス速度 ◦ Local > Remote ◦ Cached >
Disk • Disk Cache (Buffer/Page Cache) 39 70 71 592 0 100 200 300 400 500 600 Remote Local MB/s Read performance of Gfarm file (HDD, GbE) disk cache Gfarm disk cache file file disk cache file file process Local Remote 2016-10-21 7 GfarmWS@神戸
IOを考慮したタスクスケジューリングに関 する研究 ▶ ローカルアクセスの向上 ◦ “Workflow scheduling to minimize data
movement using multi-constraint graph partitioning” ◦ CCGrid 2012 ◦ タスク実行ノードを決めるスケジューリング ▶ キャッシュ効率向上 ◦ “Disk Cache-Aware Task Scheduling For Data-Intensive and Many-Task Workflow” ◦ IEEE Cluster 2014 ◦ タスク実行順序を決めるスケジューリング 2016-10-21 GfarmWS@神戸 8
キャッシュ効果による性能向上 (1-12 nodes, Logarithmic graph) 1node 8cores 4nodes 32cores ∝
1/ncores x1.9 speedup from FIFO 2016-10-21 9 スケールアウトを超える高速化: ノード数増加によりメモリが増え、 キャッシュアクセスが増加 GfarmWS@神戸 ⇐ better
Gfarm+Pwrakeの耐障害性 2016-10-21 GfarmWS@神戸 10
Gfarmの耐障害機能 ▶ メタデータサーバ(MDS) ◦ スレーブMDSによる冗長化 • マスターMDS故障時に交替して運用継続 ▶ ファイルシステムノード(FSN) ◦
ノードの動的な参加・脱退 • 故障したFSNは離脱して運用継続 ◦ ファイル自動複製作成 • FSN故障時に、ファイル消失を防ぐ 2016-10-21 GfarmWS@神戸 11
Gfarmファイル自動複製作成 ▶ ファイル書き込み後クローズ時に、自動的に 他のノードに複製を作成する機能 ▶ gfncopy コマンドを用いて設定 ▶ ワークフロー実行時の設定 ◦
出力ファイルのディレクトリに対して、複製数を2 以上に設定 ▶ ワーカーノード=FSN故障時 ◦ 出力ファイルの消失を防ぐ ◦ 複製ファイルへのアクセスを継続 2016-10-21 GfarmWS@神戸 12
Pwrakeにおける耐障害機能の方針 ▶ ワーカーノード障害 ◦ 実行中のワークフローが止まらずに継続 ◦ Gfarmファイル自動複製作成機能を活用 ▶ マスターノード障害 ◦
自動的な復旧は行わない ◦ 中断したワークフローの途中からの再開 • Rakeから引き継ぐ特徴 • 中間ファイルがチェックポイント 2016-10-21 GfarmWS@神戸 13
ワーカーノード障害検知 ▶ Pwrakeの方針: ◦ ワーカーノード障害時に脱退して続行 ▶ 障害検知方法: ◦ ワーカーノードとの通信切断 ◦
ハートビートのタイムアウト ◦ 失敗タスクをリトライした結果 2016-10-21 GfarmWS@神戸 14
失敗タスクのリトライ 2016-10-21 GfarmWS@神戸 15 Task A Task A Retry Task
B Task A Task A Retry Task B 同一ノードで連続失敗した場合、 ノードに障害があると判定し、 ノードを脱退させて継続。 同一タスクが連続失敗した場合、 タスクに不具合があると判定し、 後続タスクの実行は行わない。 タスクが実行に失敗したとき、別のノードで再実行
評価実験 • 自動複製作成の性能への影響 • 障害時のワークフロー継続性 2016-10-21 GfarmWS@神戸 16
2016-10-21 GfarmWS@神戸 評価環境 クラスタ 筑波大HPC研究室クラスタ CPU Intel Xeon E5620 (2.40GHz)
コア数×CPU/ノード 4 cores × 2 cpus 主記憶容量 24GB FSNストレージ HDD 計算ノード数 8 ネットワーク 1Gb Ethernet OS CentOS 6.8 Gfarm ver. 2.6.11 Ruby ver. 2.3.0 Pwrake ver. 2.1.0 17
▶ 天文画像合成処理ソフト 2016-10-21 GfarmWS@神戸 Montageワークフロー ▶ 使用コア数: 64 (8ノード、1ノード8コア) mProjectPP
mDiff+mFitplane mBGModel mBackground mShrink mAdd mAdd mJPEG 入力ファイル 2MASS 入力ファイル数 309 入力ファイルサイズ(合計) 639 MB 出力ファイル数 3,675 出力ファイルサイズ(合計) 6,980 MB タスク数 2,252 18 MontageのDAG
複製作成によるワークフロー実行時間へ の影響 ▶ 複製数を2に設定(gfncopy -s 2) ◦ ワークフロー経過時間が 約 5%
増 ◦ タスク累積実行時間が 約 9% 増 ◦ Gbit Ethernetへの負荷が増加したと考えられる。 2016-10-21 GfarmWS@神戸 19 61.8 65 0 20 40 60 80 複製なし 複製数2 経過時間(秒) ワークフロー実行時間 2416 2637 0 500 1000 1500 2000 2500 3000 複製なし 複製数2 累積実行時間(秒) タスク累積実行時間
ワーカーノード障害の実験 ▶ 疑似的な障害発生方法 (1) Pwrake のワーカープロセスをkill する. • kill -KILL
[Pwrake worker process ID] (2) FSN のデーモンプロセスgfsd をkill する. • pkill -KILL gfsd (3) ノード内のユーザ所有プロセスを全てkill する. • kill -KILL -1 ▶ 複製数2でワークフローを実行中にワーカー ノードのうち1台に疑似障害発生 2016-10-21 GfarmWS@神戸 20
障害発生による プロセス数の推移 ▶ 20秒付近で疑似障害発生: ▶ (1)(3):プロセス数 64 → 56 に減少して続行
▶ (2)(3):障害ノードのストレージが使用不可に ▶ いずれも正常な結果が得られた 2016-10-21 GfarmWS@神戸 21 0 10 20 30 40 50 60 70 0 10 20 30 40 50 60 70 80 # of running processes time (sec) (1) Pwrake ワーカープロセスをkill 0 10 20 30 40 50 60 70 0 10 20 30 40 50 60 70 80 # of running processes time (sec) (2) gfsd をkill 0 10 20 30 40 50 60 70 0 10 20 30 40 50 60 70 80 # of running processes time (sec) (3) ノード内のユーザ所有プロセスを全てkill
障害発生時のワークフロー実行時間 ▶ (2)のgfsdのみkillのケースでは、使用コア数が減っていないにもかかわらず、 (1)(3)の使用コア数が減ったケースより実行時間が長い。 ▶ gfsd をkill したノードではファイルアクセスが常にリモートとなり、ファイルI/O にか かる時間が増えたことが考えられる。
2016-10-21 GfarmWS@神戸 22 67.6 72.0 70.9 0 20 40 60 80 (1) kill worker (2) kill gfsd (3) kill all 経過時間(秒) ワークフロー実行時間 2,560 2,836 2,679 0 500 1000 1500 2000 2500 3000 (1) kill worker (2) kill gfsd (3) kill all 累積時間(秒) タスク累積実行時間
関連研究 ▶ Pegasus ◦ ハードレベル: Condor DAGMan ◦ ワークフローレベル: •
リトライ・チェックポイント – チェックポイントのオーバーヘッドが問題 ▶ Swift ◦ ハードレベル: CoG Karajan または Falkon ◦ ワークフローレベル: • リトライ、チェックポイント、重複実行 ▶ Pwrake ◦ ハードレベル: PBSなどの使用を想定 ◦ ワークフローレベル: • リトライ(今回実装)、チェックポイント(Rake)、ファイル複製(Gfarm) ◦ Gfarmファイルシステムのファイル自動複製作成により、ファイル消失を防ぐ 2016-10-21 GfarmWS@神戸 23
まとめ ▶ ワークフローシステムPwrakeの耐障害機能 ◦ ファイル自動複製(Gfarm) ◦ ワークフローの途中からの再実行(Rake) ◦ タスクリトライ(Pwrake) ◦
障害復帰機能は持たない ▶ 評価実験 ◦ 自動複製作成のオーバーヘッド • ワークフローの実行時間の増加が5%程度 ◦ ワークフロー実行中の疑似障害発生 • ワークフローが続行し、正常な結果を確認 2016-10-21 GfarmWS@神戸 24