1 / 33

広域計算環境用のスケーラブルな 高性能通信ライブラリ

広域計算環境用のスケーラブルな 高性能通信ライブラリ. SWoPP2008 (HPC-116) 斎藤秀雄　田浦健次朗 ( 東京大学 ) 2008 年 8 月 7 日. 並列計算のできる広域環境の整備. WAN のバンド幅の増加 (〜40Gbps) SINET3 ( 日本 ) 、 SURFnet ( オランダ ) 、 etc.  複数のクラスタを WAN で接続して 並列計算を行うことが現実的に なってきている InTrigger ( 日本 ) DAS-3 ( オランダ ) Grid 5000 ( フランス ) etc. 現状.

bianca-campbell
Download Presentation

広域計算環境用のスケーラブルな 高性能通信ライブラリ

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 広域計算環境用のスケーラブルな高性能通信ライブラリ広域計算環境用のスケーラブルな高性能通信ライブラリ SWoPP2008 (HPC-116) 斎藤秀雄　田浦健次朗 (東京大学) 2008年8月7日

  2. 並列計算のできる広域環境の整備 • WANのバンド幅の増加 (〜40Gbps) • SINET3 (日本)、SURFnet (オランダ)、etc. 複数のクラスタをWANで接続して並列計算を行うことが現実的になってきている • InTrigger (日本) • DAS-3 (オランダ) • Grid 5000 (フランス) • etc.

  3. 現状 • 広域環境で実行できると嬉しいものは多数ある • メッセージパッシング • データインテンシブアプリ • 分散ファイルシステム • しかし、現状ではこれらを数十クラスタ・数千ノードの広域環境で高速に実行するのは困難 • ハードウェアの性能は十分ある • ソフトウェアが並列計算の様々な要求に対応できない • 接続性、スケーラビリティ、通信性能

  4. 接続性 • 広域環境では、直接通信できないノードがある • FWによって通信が遮断されているノード • NATをしていてPrivate IPしか持っていないノード FW

  5. スケーラビリティ • 「つなげるノードはできるだけつなぐ」ような単純な手法では様々な資源の制限に触れる • TCPのバッファメモリ (≥ 帯域遅延積) • NATの同時セッション数 (≈ 65,000) • FWの同時セッション数 (10,000〜1,000,000) 接続 (特にWANの接続)の数を制御する必要がある

  6. 通信性能 • 「できるだけつないで」多数の接続が協調せずに通信すると、通信性能が悪い • コンジェスチョンによるパケットロス • セキュリティのために意図的に落とされるパケット • 一方、とにかく接続を間引いて中継を行えば良いというわけでもない • 近いノード間や頻繁に通信するノード間の中継の回避 • 中継ノードがボトルネックにならないように中継ノードの数や位置の考慮

  7. 賢い通信ライブラリの必要性 • 接続性、スケーラビリティ、性能をすべて考慮して並列アプリを開発するのは困難 • 様々な環境に対応する必要性 • 未知の環境に対応する必要性 • 環境に自動的に適応して高性能な通信を可能にするライブラリが必要

  8. 本研究の貢献 • 広域環境における並列計算用のスケーラブルな高性能通信ライブラリScalable Sockets(SSOCK) • Socket API • オーバレイネットワークを用いたFW/NAT越え • 数十クラスタ数千ノードでも資源を使い切らずに動作 • 高い1対1通信性能及び多対多通信性能 • 設定はほとんど必要ない

  9. 発表の流れ • はじめに • 関連研究 • SSOCKの設計と実装 • 実験結果 • まとめと今後の課題

  10. TCP Splicing/UDP Hole Punching • TCP Splicing (Denis et al. ‘04) • UDP Hole Punching (RFC 3489) • 問題点: • 複雑なネットワークではうまくいかない • 多様な環境で並列計算を行うためには不十分 FW FW

  11. プロキシサーバ • SOCKS (RFC 1928) • 問題点: • 複雑なネットワークでは複雑な設定が必要 • 様々な環境、未知の環境に対応するのは困難 プロキシ1 FW プロキシ2

  12. SmartSockets (1/2) • Maassen et al. ’07 • 多様な環境に自動的に適応して接続性の問題を解決するライブラリ • Javaのソケットクラスを拡張 • アプリにはあたかもFW等がなくて直接コネクトできるかのように見える • ライブラリ内では直接コネクトできない場合は逆向きコネクト、TCP Splicing、中継などを行う • 設定はほとんど必要ない

  13. SmartSockets (2/2) • 直接コネクトできる場合は直接コネクトする 高い1対1通信性能 • WANで多数の接続を確立する可能性がある スケーラビリティの低下、通信性能の低下 SSOCKは同様のインタフェースで、大規模な並列計算に必要なスケーラビリティと性能を提供する

  14. P2Pオーバレイネットワーク • 各ノードは一部のノードとのみ通信 • 直接通信できない (しない) ノードのために中継 • 分散ハッシュテーブルを用いたルーティング • nノードがそれぞれO(logn)ノードについて情報を保持すれば、平均O(logn)ホップで通信できる • 問題点: • P2Pアドレス空間でルーティングを行うため、物理ネットワークではメッセージが遠回りをしてしまう

  15. IP over P2P (IPOP) • Ganguly et al. ‘06 • P2Pオーバレイネットワークを用いてIPトンネリングを行う (IPの仮想化) • 頻繁に通信するノードの間にはショートカット接続を確立する • 問題点: • 多数のノードが頻繁に通信するアプリでは多数のショートカット接続が確立されてしまう • IPトンネリングを行うために用いる仮想インタフェースのオーバヘッドが並列アプリには大きすぎる

  16. 発表の流れ • はじめに • 関連研究 • SSOCKの設計と実装 • 実験結果 • まとめと今後の課題

  17. Scalable Sockets (SSOCK) • 広域環境における並列計算用のスケーラブルな高性能通信ライブラリ • Socket API • FW/NAT越え (任意のノード間でコネクトできる) • スケーラブルな資源消費 (全ノード間でコネクトできる) • 高い1対1及び多対多通信性能 • 設定はほとんど必要ない

  18. 動作の概要 Bootserv (システム全体に一つ) オーバレイ ネットワーク Libssock 仮想接続 Ssockd (各LANに一つ以上) 実接続

  19. Bootserv • SsockdとLibssockのためのランデブポイント • Ssockdには他のSsockdのエンドポイントを教える • Libssockには接続すべきSsockdのエンドポイントを教える • すべてのSsockdとLibssockからアクセスできるエンドポイントを持つ必要がある • SSOCKの唯一の設定項目 (SsockdとLibssockが起動時に読む設定ファイルに書いておく)

  20. Libssock (ライブラリ部分) • Socket APIを提供 • connect/accept, send/recv, etc. • アプリから見た動作 • connectを呼ぶと相手と直接接続が確立される • ライブラリ内の動作 • 同じSsockdと接続している相手とは実接続を確立 • 違うSsockdと接続している相手とは仮想接続を確立

  21. Ssockd (デーモン部分) • Bootservを介して互いのエンドポイントを知る • 局所性を考慮したオーバレイを構築する (詳細は次スライド) • データを中継する • Libssock→Ssockd • Ssockd→Ssockd プロキシ サーバ Ssockd

  22. 遠い 近い 局所性を考慮したオーバレイ • Multi-Cluster MPIの局所性を考慮した接続管理 (Saito et al. ‘07) • 各プロセスは他のプロセスとのRTTを測定 • 各プロセスはRTTを基にO(logn)個の他のプロセスを選択 (n:プロセス数) • 選択したプロセスとベストエフォートで接続を確立 ... /4 / /2

  23. Ssockdの数 • 少数のSsockdでのみオーバレイを構築する 全ノードでオーバレイを構築するよりルーティングが単純化される • しかし、Ssockdの数を減らしすぎるとSsockdがボトルネックになってしまう • 少数のSsockdではWANの帯域を使い切れない場合 • いくつ、どこに配置すべきかが重要 • 今後の課題だが、簡単に色々試せるような設計にはなっている

  24. 発表の流れ • はじめに • 関連研究 • 設計と実装 • 実験結果 • まとめと今後の課題

  25. InTrigger 11クラスタ+ その他2クラスタ • 13クラスタ506ノード (1,264コア) 実験環境

  26. 実験1: 接続性とスケーラビリティ(1/2) • 全1,264コアで1個ずつプロセスを立ち上げ、全対全で接続を確立しようとした • Socketライブラリを用いた場合 • 問題1. Imade (NAT)とKyoto (NAT)が通信できなかった • 問題2. 1プロセスが開けるファイルディスクリプタの数の制限 (1,024) に引っかかった • 問題3. Imadeが53,800本接続を確立したところでNATテーブルが溢れた

  27. 実験1: 接続性とスケーラビリティ(2/2) • SSOCKを用いた場合 (各クラスタでSsockdを1個起動) • 1,264プロセスを全対全で接続することができた • クラスタ間の接続はいくつかのSsockdによって中継される仮想接続として確立された Libssock Libssock Ssockd Ssockd Ssockd Kyoto (NAT) Imade (NAT) Kobe (Firewall)

  28. 実験2: 同時接続確立 • 多数のプロセスが同時に接続を確立しようとしたときの挙動を調査 • 全対全で通信できる10クラスタ (ネットワークが”Global”なもの) のみ利用 • 各クラスタで同じ数のプロセスを起動 • 全プロセスに同時に互いにノンブロッキングコネクトをさせた

  29. 実験2: 結果

  30. 実験3: 一対一通信性能 (1/2) • クラスタ内 (Kototoi) のピンポン性能

  31. 実験3: 一対一通信性能 (2/2) • クラスタ間 (Hongo-Okubo) のピンポン性能

  32. 発表の流れ • はじめに • 関連研究 • 設計と実装 • 実験結果 • まとめと今後の課題

  33. まとめと今後の課題 • 広域環境における並列計算用のスケーラブルな高性能通信ライブラリSSOCK • FW/NATのある環境で様々な資源を使い切ることなく1,262プロセスを全対全で接続を確立できた • 同時に多数の接続を確立してもSocketライブラリのようにタイムアウトすることがなかった • 今後の課題 • Ssockdの数・位置の決定アルゴリズム • 様々なミドルウェアの10クラスタ1000コア化

More Related