1 / 40

ロングファットネットワーク上での 高速データ転送 「 ATLAS 地域解析センター Testbed 環境の構築」

ロングファットネットワーク上での 高速データ転送 「 ATLAS 地域解析センター Testbed 環境の構築」. 高エネルギー加速器研究機構 計算科学センター 佐藤博之. 始めにご注意. この presentation は実際に存在するロングファットネットワーク上でデータ転送実験を行ったものではありません さらに High Throughput を達成するためのプログラム等を開発したわけでは（今のところ）ありません RTT/cwnd/ssthresh などの用語を何の断りもなく使用します.

ethan
Download Presentation

ロングファットネットワーク上での 高速データ転送 「 ATLAS 地域解析センター Testbed 環境の構築」

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. ロングファットネットワーク上での 高速データ転送 「ATLAS地域解析センターTestbed環境の構築」 高エネルギー加速器研究機構 計算科学センター 佐藤博之 Linux Conference 2001

  2. 始めにご注意 • このpresentationは実際に存在するロングファットネットワーク上でデータ転送実験を行ったものではありません • さらにHigh Throughputを達成するためのプログラム等を開発したわけでは（今のところ）ありません • RTT/cwnd/ssthreshなどの用語を何の断りもなく使用します Linux Conference 2001

  3. 話の進み方 • （１） 前回のおさらい • LHC , ATLAS , 地域解析センター , WANとLAN , ネットワークシミュレータの構築 • （２） ネットワークシミュレータを利用した測定 • 遅延 , 輻輳 , Window Size , Slow Start , パフォーマンス測定 • （３） 結果に対する考察 • 何が足りないのか？ Linux Conference 2001

  4. Detector forLHCb experiment Detector for ALICE experiment 次期陽子陽子衝突型実験 取得データ量 １００MB/sec ↓ １PB/year これを３４ヶ国の １８５０人が利用する (ATLASの場合) Linux Conference 2001

  5. 物理データ解析のチャレンジ "干し草の山の中から針を探しだす" • 毎秒 10億回の衝突事象オンラインで選別 毎秒 100 事象を保存1年あたり 10億事象 • データサイズ 1 Mbyte/事象 4実験で年間数ペタバイト • 事象再構築: ~ 300 SPECint95*秒/事象事象再構築だけで 20万SPECint95 のCPUパワーが必要データ解析にさらにその数倍が必要になるデータ解析も国際協力で！  "MONARC"プロジェクト High Throughput, Data-Intensive Computing Linux Conference 2001

  6. 1 TIPS = 25,000 SpecInt95 PC (1999) = ~15 SpecInt95 ~PBytes/sec Online System ~100 MBytes/sec Offline Farm~20 TIPS Bunch crossing per 25 nsecs.100 triggers per secondEvent is ~1 MByte in size ~100 MBytes/sec Tier 0 CERN Computer Center >20 TIPS ~622 Mbits/sec or Air Freight HPSS Tier 1 US Regional Center France Regional Center Germany Regional Center Italy Regional Center HPSS HPSS HPSS HPSS ~2.4 Gbits/sec Tier 2 Tier2 Center ~1 TIPS Tier2 Center ~1 TIPS Tier2 Center ~1 TIPS Tier2 Center ~1 TIPS Tier2 Center ~1 TIPS ~622 Mbits/sec Tier 3 Physicists work on analysis “channels”. Each institute has ~10 physicists working on one or more channels Data for these channels should be cached by the institute server Institute ~0.25TIPS Institute Institute Institute Physics data cache 100 - 1000 Mbits/sec Tier 4 Workstations 多階層型地域解析センターモデル Multi-Tier Regional Center Scheme ~4 TIPS Linux Conference 2001 24 March 2000, WW A/C Panel, P. Capiluppi

  7. アトラス日本グループの地域解析センター • KEKと東大・素粒子国際研究センター(ICEPP)の共同で技術開発を推進 • 2006年までに 約6万SPECint95の計算機からなるTier-1データ解析システムを国内に構築、ストレージを約1ペタバイトまで段階的に増強 • 補完的役割を担うCERN分室を設立 • 2001年末から始まるアトラスのデータ・チャレンジに参加 • NIIのSuperSINET計画にGrid/アトラスの専用回線 • 2001年度末に KEK-ICEPP間に 1 ~ 10 Gbps Linux Conference 2001

  8. 地域解析センター実現のための技術課題 今回はこれに特化した話です • 広域広帯域ネットワークの利用 • TCP/IPの技術的制約と効率的ファイル転送技術の必要性 • サイト間にまたがる研究者の認証とセキュリティの確保 • 実験データの分配・複製機構 • 計算資源の効率的管理 • 大規模データストレージと大規模CPUクラスター • スケーラブルでフォルトトレラントな大規模システム • 共同研究者間で透過的に利用できる広域データ共有システム Linux Conference 2001

  9. ノード A ノード a ノード B ノード b ハブ ハブ ノード C ノード c ノード D ノード d ノード E ノード e 帯域幅の使われ方 • 普通（？）の場合 帯域幅 • 今回の目標 帯域幅 ハブ ノードa ハブ ノードA Linux Conference 2001

  10. WANとLANの違い • 遅延時間が長い • 数百msec単位 / LANでは数msec単位かそれ以下 • 途中経路に広い回線から細い回線へのルータが存在している可能性が高く、そこでのキュー容量の制限によりパケットロスが生じ輻輳が発生する • このため、TCPのようなコネクション指向のプロトコルにおいては、そのスループットを安全に最大へと誘導する通信メカニズムが必要 ⇒ 一般にはSlow Startの機構が動作する Linux Conference 2001

  11. WANでのデータ転送（１） • 拡大図 • 標準設定 RTT 25Mbps ( KEK-CERN Backup Network ) Linux Conference 2001

  12. なぜ遅い？ • 送信側は受信側からの応答確認（ack）があるまで次のセグメントをネットワーク上へ流すことができない • 一回に流すセグメント数（cwnd）が10Kbytesほどで頭打ちになっている • LANだとRTTが小さいためほとんど気にならないがWANではその数百倍（100ms単位）にもなるためパフォーマンスが低下する Linux Conference 2001

  13. じゃあどうする？ • 一回に流す（バーストさせる）パケット量を増やして１RTTあたりの転送レートを上げる • そのためには受信側から告知されOffered Window Sizeを変えてcwndのとれる最大値を大きくしてやればよい • ただしSlow Startによる輻輳回避戦略のため、cwndは確認応答を受信しながら徐々に大きくなっていく Linux Conference 2001

  14. いろんなWindow Size • “cwnd” • いろいろ Linux Conference 2001

  15. 輻輳発生時 • “cwnd” • win = 256K Linux Conference 2001

  16. RTTとWindow Size • RTTが小さいとき RTTが大きい時に利用効率を上げるためには広いWindow Sizeが必要 time 5: (cwnd = 6) 送 → → 受 seg6 seg5 seg4 ← 受 送 ← ack1 ack2 ack3 • RTTが大きいとき time 10: (cwnd = 6) → 受 seg6 seg5 seg4 ← 受 ack1 ack2 ack3 time 15: (cwnd = 16) 送 → → 受 seg16 seg15 seg14 seg13 seg12 seg11 seg10 seg9 送 ← ← 受 ack1 ack2 ack3 ack4 ack5 ack6 ack7 ack8 Linux Conference 2001

  17. KEKでのMONARC Testbed • KEK⇔CERN回線 • 地上回線 4Mbps RTT～300ms (nacsis提供) • 衛星回線 2Mbps RTT～600ms (crl提供) • 両端にSolaris/Linux等を設置しOODB（Objectivity/DB）やファイル転送等の性能測定を行ってきた • 将来、広帯域（数百Mbps～数Gbps）で接続された場合のTestbedも行いたい • 接続先のマシン設定を自由に変更したい → 疑似遅延環境を構築してそこでTestbedを行う Linux Conference 2001

  18. 遅延の実現方法 • 一番簡単かつ確実な方法 • ケーブルを必要なだけとぐろ巻きにする • 数百msecだととてもじゃないがやってられない • 市販の遅延器（？）を使う • ATM用のがあるらしい • コストが不明….. • そこでお手軽にLinux PCのルーターに小細工をして自分で作ることにする Linux Conference 2001

  19. 遅延ルーティング用プログラム • あるifからパケットをひたすら取り込みそれを分離スレッドにして遅延をかけた後でそれを別のifから送信する • 必要なもの • パケットキャプチャー • パケットインジェクター • 詳細は以下をどうぞ • http://atlas.kek.jp/People/yuki/lc2k_fall/ Linux Conference 2001

  20. Gigabit Ethernet • 昔は高値の花だったが今は１万円を切るものもある • 光ファイバーでなく銅線利用のものが多くなってきた • 1000Mbps出すには • 優秀なチップセット • 64bitPCIバス • ジャンボフレーム （MTU=9000) • がおそらく必要 • ただしジャンボフレームを通すハブはまだまだ高価なので、しばらくはFast Ethernetの２～３倍程度の速度での運用か （SuperSINETは？） Linux Conference 2001

  21. 990Mbps Transfer speed in Mbit/s Message size in KB Gigabit Ethernetの測定例 ネットワーク性能 ServerSetIIILEチップセット搭載機 （64bitPCI付き） はっきし言って バケモンである 恐るべしServerSet..... Linux Conference 2001

  22. で、Linuxでうまく行ったの？ • 数＋Mbpsぐらいならうまくいったんですが • それを超えると完全にアウトで、パケット落ちまくり • うーん..…どうしよう • そんなとき、悪魔の囁きによりFreeBSDへと浮気..................... Linux Conference 2001

  23. DUMMYNET • さまざまな条件下でのネットワークのシミュレーションを行う • FreeBSDのカーネルに組み込んで使用 • 以下の様なものが制御できる • 帯域幅 • 遅延 • パケット損失 • http://info.iet.unipi.it/~luigi/ip_dummynet/ Linux Conference 2001

  24. PentiumIII 733MHz 128MB / SSIIILE Router (FreeBSD) PentiumIII 800MHz 256MB / P3B-F PentiumIII 800MHz 256MB / P3B-F Host A (Linux) Host a (Linux) Testbed セットアップ (1) Delay : 300msec 192.168.148.105:eth2 eth1:192.168.158.105 Gigabit-Ethernet Gigabit-Ethernet GB+FE Hub GB+FE Hub Fast-Ethernet Fast-Ethernet 192.168.148.101:eth1 eth1:192.168.158.103 Destination Gateway Iface default gw1.kek.jp eth0 192.168.158.0 192.168.148.105 eth1 Destination Gateway Iface default gw1.kek.jp eth0 192.168.148.0 192.168.158.105 eth1 Linux Conference 2001

  25. FE(16)+GB(2) Hub ぼろい..... こうなってます ルータマシン Linux Conference 2001

  26. WANでのThroughput向上のために • 標準的な手法としてよく採られるのは以下の２つ • （１） Window Sizeの拡大 • （２） Parallel Connectionにする • しかしながらこれらの方法では十二分にパフォーマンスを上げることができないことがシミュレーションを利用した測定により判明 Linux Conference 2001

  27. シミュレータを利用した測定（１） • Window SizeとThroughput (Linux2.2の場合） 700kbytesまでは上昇するがそのあとが伸びない Linux Conference 2001

  28. パフォーマンスが伸びない理由 • tcpdumpで追っかけてみると 15:43:02.772309 > foo01.1133 > foo02.1338: P 2202409:2203857(1448) ack 1 15:43:02.772312 > foo01.1133 > foo02.1338: P 2203857:2205305(1448) ack 1 15:43:02.772315 > foo01.1133 > foo02.1338: P 2205305:2206753(1448) ack 1 15:43:02.772317 > foo01.1133 > foo02.1338: P 2208201:2209649(1448) ack 1 15:43:02.772320 > foo01.1133 > foo02.1338: P 2209649:2211097(1448) ack 1 • セグメント2206753:2208201(1448)が抜けている • NICの種類を変えても再現するので、おそらくネットワークカーネルのバグ？ Linux Conference 2001

  29. シミュレータを利用した測定（２） • Window SizeとThroughput (FreeBSD4.2の場合） Linuxよりかは伸びるがそれでも途中で息切れ Linux Conference 2001

  30. Window Sizeを拡大する方法は • Linuxではセグメント落ちのバグのため途中で頭打ち • FreeBSDでもLinuxよりかは伸びるがそれでもCPUパワーでリミットがかかる • さらに輻輳発生時の回復過程時のパフォーマンスの低下を考えると、Window Sizeを拡大しすぎるのも考えもの • それではparallelにやる方法は？ Linux Conference 2001

  31. シミュレータを利用した測定（３） • Window SizeとThroughput (Linux2.2の場合） Parallel ConnectionによりThroughputが上昇している Linux Conference 2001

  32. 実際にファイルを転送してみると • Parallel Connectionの設定値（Window Size, Connection数）で実際にファイルからデータを読み込み、転送を行い、ファイルへと書き込むと • これが全く性能が出ない • 測定に再現性も無い • なぜ？ Linux Conference 2001

  33. ファイルに書くと駄目な理由 • ファイルとの入出力はメモリを介して行われる • ところがメモリが一杯になりディスクへのフラッシュが発生した瞬間に輻輳が発生したのと同様な状態になる • その結果として輻輳Window Sizeが縮小しThroughputが低下する Linux Conference 2001

  34. さらにおまけ • Parallel Connectionの各ソケットが同時にSlow Startを始めるとパフォーマンスが低下する • 前のプロットでは各Connection 0.5秒程、ずらしながら測定した • 同時にやると次のプロットのようになる • 世の中に存在するparallel指向のデータ転送プログラムがここんとこを考慮しているかは不明 Linux Conference 2001

  35. シミュレータを利用した測定（４） • Window SizeとThroughput (Linux2.2の場合） 同時にSlow Startを始めるとパフォーマンスが出ない Linux Conference 2001

  36. Testbed セットアップ (2) Gigabit Delay : 300msec Fast PentiumIII 733MHz 128MB / SSIIILE PentiumIII 800MHz 256MB / P3B-F PentiumIII 800MHz 256MB / P3B-F Router (FreeBSD) Host A (Linux) Host a (Linux) PentiumIII 800MHz 256MB / P2XBL PentiumIII 800MHz 256MB / P2XBL Host B (Linux) FE+GB Hub FE+GB Hub Host b (Linux) PentiumIII 600MHz 256MB / P6SBA PentiumIII 450MHz 128MB / P2B-F Host C (Linux) Host c (Linux) PentiumIII 800MHz x2 256MB / Tiger100 PentiumIII 800MHz x2 256MB / Tiger100 Host D (Linux) Host d (Linux) Linux Conference 2001

  37. シミュレータを利用した測定（５） • PCの台数とThroughput (Linux2.2の場合） WindowSize：４５０Kbytes #’ connection:８ に固定 落ちる原因 ↓ ルータのCPUパワーが 足りないため ３台目までは順調に伸びるがそれを超えると落ちる Linux Conference 2001

  38. 2.4と2.2の違い • Slow Startの立ち上がりは2.2よりも速い • Window Sizeの自動コントロール • ある意味「余計なことしてくれるな」 • ssthreshをキャッシュして再利用 • このため輻輳が発生した後はパフォーマンスが著しく低下する • クリアするためにはifdownさせるかカーネルソースを直すしかない？　（FreeBSDではコマンドで変更可） • 2.2の方がよかった…..かも Linux Conference 2001

  39. 今後の予定 • もうちょっとパフォーマンスを引っ張りたいので新しいPCが欲しいかなぁ、と （センター長さん、予算下さい.....） • データグラムを用いたファイル転送 （教科書には「やるな！」と書いてある） • 擬似的なprocedureを作り、データ生成→転送→データ読込の連続運転をしてみる Linux Conference 2001

  40. まとめ • 地域解析センター Testbeds環境構築のため、遅延時間300msのシミュレータを組みその上で各種測定を行った • 現在あるTCP/ハードウェアで高遅延広帯域を効率よく利用するのは困難 • もうちょと工夫が必要 • TCPの見直し？ • 何か良い方法ないですか？ Linux Conference 2001

More Related