ワークフローシステム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