Grid環境におけるフォールトトレランスを支援する

Grid環境における
フォールトトレランスを支援する
モニタリングシステム
電子情報工学科４年
近山・田浦研究室
堀田勇樹
背景と動機（１）
 グリッドコンピューティングの発展
 計算資源の分散
・資源状態の把握が困難
・故障が比較的頻繁に発生
⇒ モニタリングシステムの必要性
 長時間にわたる計算
・計算中に計算ノードの故障が生じることあり
・一つのノードでも欠けると計算が台無し
⇒ フォールトトレランス（耐故障性）の必要性
背景と動機（２）
フォールトトレランスを実現するには・・・
ノードの故障検知が必要
 アプリケーションごとに実装しようとすると大変・・・
- ノード間で頻繁に通信して相手に故障がないか確認
- 全ノードが故障検知に対して合意している必要がある
…etc
⇒ 故障情報を得るためのライブラリが欲しい
モニタリングシステムが提供
既存のモニタリングシステム
 MDS、NWS、…
Node
 ノード群を固定的にグループ化
 グループの代表ノードがグループ内の情報を管理
○ 通信量が抑えられる
× 代表ノードがクラッシュするとシステムが
機能しない ( システムの耐故障性の問題）
Representative
node
Group
× 動的なネットワークの変更に対応できな
い（ネットワーク変更に関する問題）
実際には生きているのに、
死んだとみなされてしまう
ネットワーク的には伝達可能
代表ノードがクラッシュしたグ
なのに、情報が伝わらない
ループの情報は得られない
システムに対する要求
① システムの耐故障性
ノードがクラッシュしたとき、システムが機能しなくなってしまうと肝心
の故障情報が得られない
② 故障検知の正確性
誤った故障情報を得るのはできる限り避けたい
③ 故障検知の合意性
ノードによって得られる故障情報が異なってしまうようなことはできる
限り避けたい
既存のモニタリングシステムでは、
①,②の点で不十分
本研究の貢献
 アプリケーションのフォールトトレランスを支
援するモニタリングシステムの設計、実装
- 先の要求を満たすシステムの提案
 システムの耐故障性（どのノードがクラッシュしても対
応可能）
 故障検知の正確性（ネットワーク変更に対処可能）
 故障検知の合意性
- 故障検知APIの提供
本研究の基本方針
 各ノードが全ノードの情報を管理
 各ノードの機能が等価
 個々のノード単独でもシステムが機能する
① どのノードが複数故障しても対応できる！！
＜故障検知＞
定期的にメッセージを送ってもらい、それがある一定時間中
（＝タイムアウト時間）にやってくるかどうかでノードの生死を
判断する
⇒ 各ノードは全ノードに対して自分の生存を示す
メッセージを定期的に届ける必要がある
メッセージの伝達
1. 全てのノード間でできる限りコネクションを張る
⇒ NAT構成やファイアウォール設定でコネクションを張れないことがある
⇒ 他ノードを経由してメッセージを伝達する必要がある
2. 新規メッセージを受け取ったら直ちに周りに転送する
⇒ 結果的に全ノードがブロードキャストする形になる
- 全ノードにメッセージを行き渡らせることが可能
- ネットワークの形に依存しない（到達するパスがあれば情報が伝わる）
② ネットワークの変更
にも対応可能！！
通信量削減の工夫
 このままでは通信量がO(n3) （n:ノード数）
 新規メッセージを受け取ったら周りに転送
⇒ 無駄な通信が生じる
無駄
 送信メッセージに自分のコネクション情報をこの時点で情報は伝わっている
無駄な通信が生じる
含める（転送時は含めない）
4:(2,5,6,7)
2:(1,3,4)
1:(2,3)
 各ノードはその情報をローカルに保持
６
４
２
 各ノードは新規メッセージを受け取ると
１
送信元のコネクションリストに含まれない
ノードにのみメッセージをそのまま転送
無駄な通信を省くことができる！！
通信量 ≒ O(n2)
７
4:(2,5,6,7)
５
３
4:(2,5,6,7)
1:(2,3)
アルゴリズムの正当性
 基本的にメッセージをブロードキャスト
 １つ前のノードが送信してるノードに対するメッセージを省い
ているのみ
⇒ ある一定時間の間に全ノードにメッセージは伝達
⇒ タイムアウト時間を十分に長くとっておけば、生きていれば
必ず他ノードに生きていると判断される
③ 原則として故障検知の合意性は保証される！！
実際にはレイテンシやノードの状態などによって予定よりも
遅延が生じる恐れある
課題：タイムアウト時間の設定
故障検知API
/*** 耐故障性アプリの擬似コード ***/
crash_t crash;
crash_detect_init(char **nodelist);
・・・
/** 他ノードとの通信が生じるときなど**/
If((crash = crash_get_info()) != NULL){
/* 故障ノードの対処 */
}
else{
/* 正常実行 */
}
 ノードの故障情報などモニタリング情
報はローカルなファイルに保存
 ユーザは適宜そのファイルから情報
を読み出す
 APIとして提供



crash_t :
クラッシュしたノードの情報を表す構造体
crash_detect_init(char **nodelist) :
プロセスが動いているノードリストを登録
crash_t crash = crash_get_info() :
関係のあるノードのクラッシュ情報が書き込
まれていたらその情報を返す。通常はNULL を
返す。
実装が比較的容易に！！
今後の課題と計画
＜現状＞
システムの実装を開始した段階
＜課題＞


メッセージ送信頻度・タイムアウト時間の設定、考察
スケーラビリティの問題
＜計画＞
1.
2.
3.
4.
モニタリングシステムの実装・評価（どれぐらいのノード数に耐えら
れるかなど）
APIの作成及びそれを利用したフォールトトレラントなプログラムの
実装
各パラメータ（メッセージ送信頻度・タイムアウト時間など）に関する
実験・考察
スケーラビリティを考慮した工夫（100台以上を目標）

Download Report