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

分散環境における耐故障並列計算を支援する通信ライブラリ分散環境における耐故障並列計算を支援する通信ライブラリ電子情報工学科近山・田浦研究室 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 故障時のRollbackする位置が異なってしまう恐れがある故障次回のcheckpoint

　本研究の手法（故障検知） × • リング構造 • 各プロセスは両隣の状態を監視 • 階層的ブロードキャスト • スケーラビリティがある　　（メッセージ数：2n, 伝達時間: O(log (n)） • 情報の一貫性を維持 • システムの対称性（耐故障性）

本研究の手法（Rollback位置の保証） • Atomic Barrierを用意 • 全プロセスがこのバリア地点に到達したら全プロセスがCommit、到達せず故障したプロセスがあったら全プロセスがAbort • Barrier中に故障が生じてもAtomicityを満たす • 各プロセスにつきO(log(n))の通信で達成 ⇒ これを利用してRollbackする位置を全プロセスで一致させることができる

API 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(); • monitor_init() : システムをbackgroundで起動 • monitor_has_broken_procinfo() : 故障情報があるかどうか調べる • monitor_get_broken_info() ：　　故障情報を取得。 • monitor_barrier(int) ： atomic barrierを行う関数 • 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の影響でやや性能が落ちている Normal: 通常の並列計算 System: システムをbackgroundで動かしたのみの並列計算 FT : システムを用いて耐故障性を持たせた並列計算

まとめと課題 • ユーザの要求に柔軟に対応できる包括的な耐故障支援システムを実装・評価 • プロセス数によらずシステムのオーバヘッドは無視できるほど小さい • Atomic Barrierのスケーラビリティに課題 • 記述力・汎用性の高さを確認 • 今後の課題 • 動的なプロセス増加に対応 • グリッド環境に対応

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