360 likes | 483 Vues
広域分散計算環境における 適応的なメッセージパッシングシステムの 設計と実装. 田浦研究室 46411 斎藤秀雄 2006 年 2 月 13 日. ID=0. ID=2. TCP/IP. Shared Memory. ID=1. ID=3. メッセージパッシング. 従来のクラスタ環境で広く用いられてきた並列プログラミングモデル Point-to-point 通信( send, receive ) 集合通信( broadcast, reduction ) メッセージパッシングレイヤという抽象化. broadcast. reduction.
E N D
広域分散計算環境における適応的なメッセージパッシングシステムの設計と実装広域分散計算環境における適応的なメッセージパッシングシステムの設計と実装 田浦研究室 46411 斎藤秀雄 2006年2月13日
ID=0 ID=2 TCP/IP Shared Memory ID=1 ID=3 メッセージパッシング • 従来のクラスタ環境で広く用いられてきた並列プログラミングモデル • Point-to-point通信(send, receive) • 集合通信(broadcast, reduction) • メッセージパッシングレイヤという抽象化 broadcast reduction
広域メッセージパッシング • 近年、WANの帯域が増加 • 広域環境において並列計算を行う機会が増加 • 物理的に異なる位置に存在する複数のクラスタ • 広域環境はクラスタ環境より複雑 • メッセージパッシングのもたらす恩恵はさらに大きい • メッセージパッシングシステムはクラスタ環境用のものより複雑なものが必要 WAN
NAT Firewall 広域環境とクラスタ環境の相違点 • クラスタ環境 • ノード間で全対全で接続を張るのが単純かつ効果的 • 広域環境 • 直接は接続できないノード • Firewallの後ろにあるノード • Private IPしか持っていないノード (NAT) • メッセージを中継する必要がある
Root WAN Root Cluster Cluster 広域環境とクラスタ環境の相違点 • クラスタ用の集合通信 • すべてのリンクの速度が等しいという仮定の基に設計されている • 広域環境用の集合通信 • リンクの速度の違いを考慮する必要がある
既存手法の問題点 • 広域計算環境は、静的に捉えてもクラスタ環境より複雑 • 既存のグリッド用メッセージパッシングシステムは、広域計算環境を静的に捉えた上で工夫 • リンクの速度を考慮した集合通信、etc. • 広域計算環境はさらに動的!実行環境は • 実行時まで不明 • 実行毎に変化 • 実行中にも変化(e.g., 計算中の資源の増減)
本研究の貢献 • MPI/GXP • 広域環境を動的に捉えた適応的なメッセージパッシングシステム • 広域環境用の集合通信 • 広域環境に適応する高性能なbroadcastとreduction • 計算中に資源の増減があっても高い性能を維持できる
発表の流れ • 背景 • 関連研究 • MPI/GXP • 広域環境用の集合通信 • まとめ
Root LAN Coord. Node Coord. Node LAN LAN MagPIe • Kielmann et al. ’99 • クラスタ間・内で異なる静的な木を用いる • Broadcast • クラスタ間:flat tree • クラスタ内:binary tree • 実行環境毎に手動で設定する必要がある • 各クラスタのノード数 • 各ノードの属すクラスタ
MPICH-G2 • Karonis et al. ‘03 • より多くの階層のトポロジーを考慮した集合通信 • MagPIeより高性能。でもやはり静的! • ノード間で全対全で接続を張る • Firewall/NATのある環境で動作しない • TCP send/receive buffer用に大量にメモリが必要 • Bufferに割り当てるべきメモリ量>帯域遅延積
Unconnectable Any-to-Any One-Way プロキシを用いるシステム • クラスタ間の通信にプロキシを用いるグリッド用メッセージパッシングシステム • PACX-MPI (Gabriel et al. ’98) • StaMPI (Imamura et al. ’00) • MPICH/MADIII(Aumage et al. ’03) Manually- Configured Proxy
発表の流れ • 背景 • 関連研究 • MPI/GXP • 広域環境用の集合通信 • まとめ
istapr.i.u-tokyo.ac.jp istbs000.i.u-tokyo.ac.jp istsun0.i.u-tokyo.ac.jp … Machinesファイル MPI/GXPの概要 • 広域環境を動的に捉えた適応的なメッセージパッシングシステム • C言語で約8000行 • Message Passing Interface (MPI)の主な部分を実装 • Machinesファイルや接続性に関する情報なしで起動 • Firewall/NATのある環境で動作 • 広域接続の数を制限 • Bufferに割り当てるメモリを節約 • Stateful Firewallが覚えられる接続の数を超えてしまうことを防ぐ
影響小 影響大 MPI/GXPの接続確立 • 実際に接続を試みることによってFirewallの後ろにあるノードを自動的に検出 • 実行時に測定した遅延情報を用いて広域接続の数を制限 • 各ノードpから他のすべてのノードqへの経路が、pからqへの最短経路のk倍以内になるようしながら、最小限の接続を張る
三角不等式を用いたRTT見積もり • 全ノード間のRTTを測定するのには長時間かかる • 三角不等式を用いて、実際には測定していないRTTを見積もる • If (rttp,r + rttr,q) / |rttp,r – rttr,q| < k: • pからrを経由してqへ行く経路は、pから直接qへ行く経路のk倍より短い Route via r r p q Direct route
実験:接続数 • 様々なkにおいて張られた接続数を数えた • 3台のクラスタに分散された292ノードを使用 HONGO_B 188 nodes (0.1 ms) RTT: 4.5 ms RTT: 0.3 ms NAT RTT: 4.6 ms KASHIWA_D 64 nodes (0.2 ms) HONGO_A 40 nodes (0.2 ms)
約4000しか接続を 覚えられない 性能評価 • 様々な環境でMPI/GXPを用いてNAS Parallel Benchmarksを実行 • 8つのうち5をコンパイル・実行することに成功 • 残りの3つはMPI/GXPがFortran90に未対応(CとFortran77には対応)などの理由で実行不可 Firewall Linux Cluster 128 nodes (Eng. 14) Solaris Cluster 128 nodes (Sci. 7)
性能評価 • 様々な環境でMPI/GXPを用いてNAS Parallel Benchmarksを実行 • 8つのうち5をコンパイル・実行することに成功 • 残りの3つはMPI/GXPがFortran90に未対応(CとFortran77には対応)などの理由で実行不可 NAT RTT: 4.5 ms Bandwidth: 1 Gbps Linux Cluster 128 nodes (Hongo) Linux Cluster 128 nodes (Kashiwa)
NPBの結果 • 1クラスタではMPICHとほぼ同等の性能 • EP • 2クラスタでかなりの性能向上 • LU, MG • 1クラスタ64プロセッサよりは2クラスタ128プロセッサの方が速かった • CG, IS • 2クラスタ用いると遅くなった
発表の流れ • 背景 • 関連研究 • MPI/GXP • 広域環境用の集合通信 • まとめ
提案手法の概要 Root • トポロジーを考慮したスパニングツリーを実行時に生成する • 遅延を考慮した木(短いメッセージ用) • 帯域を考慮した木(長いメッセージ用) • 生成された木に沿ってブロードキャストとリダクションを行う • プロセスの増減時には木を更新する Root
RTT RTT RTT スパニングツリーの生成 • 各プロセスをルートとする木を生成する • メッセージパッシングでは全プロセスがブロードキャストやリダクションのルートになれる必要がある • 各プロセスが自律的に… • 自分とランダムに選んだ他のプロセスの間のRTTを測定 • 各木において適切な親を探す Root
Rationale • Bernaschi et al. ’98 • 集合通信の性能をモデル化 • 遅延→∞:最適なbroadcast treeはflat tree • 遅延→0:最適なbroadcast treeはbinomial tree Root Root Flat Tree Binomial Tree
Root Binomial Tree Root Binary Tree 目標 • クラスタ内の遅延は小さいが、最適な木はネットワーク性能による • 既存のライブラリはクラスタ内では深さlog2pの木を使用(p:プロセス数) • MPICH: binomial tree • MagPIe: binary tree • 目標:最適に近い木を生成すること • クラスタ間:深さ 1 の木 • クラスタ内:深さ約 log2p の木
Cluster Cluster Cluster 親の選択 • 各プロセスができる限り自分に近いプロセスを親にすれば、クラスタ間でflat treeができる Root
クラスタ内の木の深さ Closest Parent My Algorithm log2p
親の選択 • プロセスpは、以下の条件が両方満たされたら、現在の親parentから親候補candに親を乗り換える • rttp,cand < rttp,parent • distcand,root < distp,root root distp,root p
Migration of Virtual Nodes 15-19 0-9 15-19 Broadcast • 生成したスパニングツリーに沿ってメッセージを転送 • Self-tuningなので、MPIのような計算資源が変化しないモデルでも十分有用 • Phoenix(Taura et al. ’03)のような計算資源の増減があるようなモデルにも適用できる send(15) 10-14 10-19
全仮想ノードにメッセージを届ける 子に転送するメッセージのヘッダに、その子を経由して到達すべき全仮想ノードを列挙しておく ヘッダと木が一致しない場合は、point-to-point通信を用いる {1} {3,4} {2} Point-to-Point Message to Virtual Node 4 Phoenix用のBroadcast Root 0 1 1,4 2 3 4 Migration of Virtual Node 4
1-Byte Broadcast • MPIのようなbroadcast • 1仮想ノード/プロセス • 3台のクラスタに分散された201プロセッサ Grid-unaware (MPICH-like) My Implementation Static Grid-aware (MagPIe-like)
Leave Re-join プロセス参加・脱退時の挙動 • 4 MBのbroadcastを繰り返し実行 • 4台のクラスタに分散された160プロセッサ • Broadcast中にプロセスが脱退・再参加 • t = 0 [s] • 1仮想ノード/プロセス • t = 60 [s] • 半分のプロセスが脱退 • t = 90 [s] • プロセスが再参加
発表の流れ • 背景 • 関連研究 • MPI/GXP • 広域環境用の集合通信 • まとめ
まとめ • MPI/GXP • Firewall/NATのある環境で動作 • クラスタ間の接続を2%に制限 • 1クラスタでMPICHとほぼ同等の性能 • 2クラスタでEP/LU/MGを1クラスタより高速に実行 • 広域環境用の集合通信 • 静的にGrid-awareな実装の2倍以内の遅延のbroadcast • プロセスが参加・脱退しても高性能なbroadcastを継続
今後の課題 • 提案した集合通信のMPI/GXPへの組み込み • ノードの故障や参加・脱退にも適応するメッセージパッシングシステムの作成 • ノードの使用状況などにも適応するシステムの研究
発表文献 • ジャーナル・トランザクション • International Journal of High Performance Computing and Networking (IJHPCN). Vol.3, No.4, 2006 (To appear) • 情報処理学会論文誌:コンピューティングシステム.Vol.46 No. SIG 12 (ACS 11),2005年8月. • 情報処理学会論文誌:コンピューティングシステム.Vol.45 No. SIG 11 (ACS 7),2004年10月. • 査読付き学会 • 6th IEEE/ACM International Workshop on Grid Computing (Grid2005), Seattle, November 2005. • 先進的計算基盤システムシンポジウム(SACSIS2004),札幌,2004年5月 • その他査読なし学会2件、ポスター発表1件