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
140
0
Share
ワークフローシステムPwrakeの耐障害性 / Pwrake FT - GfarmWS2016
Gfarmワークショップ2016@神戸
http://oss-tsukuba.org/event/gw2016
Masahiro Tanaka 田中昌宏
October 21, 2016
More Decks by Masahiro Tanaka 田中昌宏
See All by Masahiro Tanaka 田中昌宏
Progress of Ruby-Numo: Numerical Computing for Ruby
masa16tanaka
4
9.1k
Pwrakeチュートリアル / Pwrake Tutorial - GfarmWS2016
masa16tanaka
0
150
Pwrake: Distributed Workflow Engine based on Rake
masa16tanaka
2
4.7k
Other Decks in Technology
See All in Technology
Amazon Bedrock 経由の Claude Cowork を試してみよう・MCP にも繋いでみよう
sugimomoto
0
280
ビジュアルプログラミングIoTLT vol.23
1ftseabass
PRO
0
160
Dynamic Workersについて
yusukebe
2
510
Oracle AI Database@Google Cloud:サービス概要のご紹介
oracle4engineer
PRO
6
1.5k
マーケットプレイス版Oracle WebCenter Content For OCI
oracle4engineer
PRO
5
1.7k
JJUG CCC 2026 Spring AI時代の開発こそ標準化を武器に! ― 方式・プロセス・プラットフォームの標準化
s27watanabe
2
640
AI時代から振り返るTerraform drift運用の歴史 / AI Age Reflections on the History of Terraform Drift Operations
aeonpeople
0
610
AI時代の私の技術インプットとアウトプット術
tonkotsuboy_com
15
8k
TROCCOで始めるクラウドコストを民主化するためのFinOps
tk3fftk
1
480
APIテストとは?
nagix
0
160
Java正規表現エンジン(NFA)の仕組みと パフォーマンスを維持するための最適化手法
takeuchi_132917
0
160
ルールやカスタム機能、どう使う?理想の出力を引き出すために今知りたいIBM Bob 5つの機能
muehara
0
150
Featured
See All Featured
Deep Space Network (abreviated)
tonyrice
0
160
Leveraging LLMs for student feedback in introductory data science courses - posit::conf(2025)
minecr
1
270
The Cost Of JavaScript in 2023
addyosmani
55
10k
How STYLIGHT went responsive
nonsquared
100
6.1k
Designing Dashboards & Data Visualisations in Web Apps
destraynor
231
55k
Connecting the Dots Between Site Speed, User Experience & Your Business [WebExpo 2025]
tammyeverts
11
930
Pawsitive SEO: Lessons from My Dog (and Many Mistakes) on Thriving as a Consultant in the Age of AI
davidcarrasco
0
150
GitHub's CSS Performance
jonrohan
1033
470k
JavaScript: Past, Present, and Future - NDC Porto 2020
reverentgeek
52
5.9k
The untapped power of vector embeddings
frankvandijk
2
1.7k
Understanding Cognitive Biases in Performance Measurement
bluesmoon
32
2.9k
Color Theory Basics | Prateek | Gurzu
gurzu
0
320
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