分散環境における耐故障並列計算を支援する通信ライブラリ

電子情報工学科近山・田浦研究室20394 堀田 勇樹

背景

大規模計算計算資源の分散化長時間にわたる計算

⇒ 処理中に計算資源（またはプロセス）の故障が生じる確率の上昇

　 耐故障性 (フォールトトレランス )が重要

本研究の貢献

耐故障支援システムの提案・実装耐故障性がある一貫性のある故障情報の提供スケーラビリティのある（負荷が小さい）Atomic な状態保存を支援

ユーザが利用するための API を用意耐故障アプリケーションの実装

耐故障アプリケーションの実演

アプリケーション– 耐故障並列 N-Queen （ 64nodes, 16Queen)

実験環境– 近山・田浦研の Sheep クラスタ（ 64 ノー

ド : sheep01~sheep64 ）• CPU : Intel(R) Xeon(TM) 2.40GHz

• Memory : 2.0GB

• OS : Linux

発表の流れ

• 関連研究＆問題意識• 本システムの手法• 実装と評価• まとめ

チェックポインティング• ローカルなディスクにプロセスの状態を保存• 故障したときは保存したチェックポイントから

再起動長所

– 汎用的である– transparent に耐故障処理を行える

短所– 同じプロセス数で復旧する必要がある– 自律的に復旧することはあまり考慮されていない

現実の耐故障モデル実際にはチェックポインティングはあまり用いられていな

い– 状態が失われても残っているプロセスで補える

( 例 ) Master-Worker 型 Worker が死んでも Master がそれに気づき、その失われたタ

スクを再び他の Worker に割り当てることにより復旧が可能– 自律的に復旧を行いたい

⇒ チェックポインティングに頼らず、ユーザが独自に耐故障を実現することが多い

ユーザの要求に柔軟に対応できる包括的な耐故障支援の枠組みが必要

支援システムとしての要求• 機能として

– 迅速な故障検知・伝達– Rollback する位置の保証

• システムとして– 耐故障性を備えている– 負荷が小さい– スケーラビリティがある– 全体として一貫性を持った情報提供

復旧における難点p1 p2 p3 p4前回の

checkpoint

次回のcheckpoint

故障

故障時の Rollbackする位置が異なってしまう恐れがある

　本研究の手法（故障検知）

• リング構造• 各プロセスは両隣の状態を監視• 階層的ブロードキャスト

スケーラビリティがある　　（メッセージ数： 2n, 伝達時間 : O(log

(n) ） 情報の一貫性を維持 システムの対称性（耐故障性）

×

本研究の手法（ Rollback 位置の保証）

• Atomic Barrier を用意– 全プロセスがこのバリア地点に到達したら全プロ

セスが Commit 、到達せず故障したプロセスがあったら全プロセスが Abort

– Barrier 中に故障が生じても Atomicity を満たす– 各プロセスにつき O(log(n)) の通信で達成

⇒ これを利用して Rollback する位置を全プロセスで一致させることができる

API• monitor_init() : システムを background で起動• monitor_has_broken_procinfo() : 故障情報があるかどうか調べる• monitor_get_broken_info() ： 　　 故障情報を取得。• monitor_barrier(int) ： 　　 atomic barrier を行う関数• monitor_finalize() : システムの終了

monitor_init();for(iter=0; iter<MAXITER ;iter++){ /* compute something */

/** the point that is for fear of being an infinite loop **/ while(...){ if(monitor_has_broken_procinfo()){ while((broken_id = monitor_get_broken_procinfo()) != NULL){ fault_handler(broken_id); } /* go back to the last checkpoint */ } }

/****** the case you make checkpoint ******/ checkpoint(); if(monitor_barrier(iter) == -1){ while((broken_id = monitor_get_broken_procinfo()) != NULL){ fault_handler(broken_id); } /* go back to the last checkpoint */ } /************************************************/}monitor_finalize();

実装• システムおよび API の実装

– C 言語で約 4500 行• 耐故障アプリケーションの実装

– 実装環境： C 言語　　　　　　　　　 Phoenix ライブラリ（並列計算支援

ライブラリ）

– 耐故障並列 N-Queen– 耐故障並列 SOR

耐故障並列 N-Queen

• 並列 N-Queen– Lazy Task Creation の手法で実装– タスクを持っていないプロセスはランダムに　周りのプロセスにタスクを要求する– 要求されたプロセスは自分のタスクを分け与える– タスクを完了したら親ノードに結果を返す

• 耐故障並列 N-Queen– 自分の子ノードが故障したら、そのタスクは未処理のものとして再計算する

耐故障並列 SOR

• 並列 SOR– 領域を分割し、各プロセスで分担– 隣合うプロセス間で境界部分のやり取り

• 耐故障並列 SOR– ペアを作りお互い相手に自分の状態を定期的に渡す– Atomic Barrier を用いることで保存状態の一貫性を保

持– 故障時は、故障プロセスの状態を保持していたプロ

セスが代わりの役割を担ういずれも従来では容易に記述できない手法！

オーバヘッドの測定

• N-Queen 、 SOR共にシステム自体の overhead は無視できるほど小さい

• N-Queen ではプロセス数増やすと性能改善• SOR は Atomic Barrier の影響でやや性能が落ちている

Performance comparison of SOR

95

96

97

98

99

100

2 4 8 16 32 64

number of processes(n)

rela

tive

per

form

ance

[%]

Normal

System

FT

hb interval = 3[s]problem size =1024*(512*n)

Performance Comparison of N-Queen

95

96

97

98

99

100

8 16 32 64

number of processes(n)

rela

tive

per

form

ance

[%]

Normal

System

FT

hb interval = 3[s]problem size ：n=8, 16, 32 : N = 16n=64 : N = 17

Normal: 通常の並列計算

System: システムを background で動かしたのみの並列計算

FT : システムを用いて耐故障性を持たせた並列計算

まとめと課題• ユーザの要求に柔軟に対応できる包括的な耐

故障支援システムを実装・評価– プロセス数によらずシステムのオーバヘッドは無

視できるほど小さい– Atomic Barrier のスケーラビリティに課題– 記述力・汎用性の高さを確認

• 今後の課題– 動的なプロセス増加に対応– グリッド環境に対応