ロングファットネットワーク上での 高速データ転送 「ATLAS地域解析センター Testbed環境の構築」 高エネルギー加速器研究機構 計算科学センター 佐藤博之 2001/09/28 Linux Conference 2001 1/99 始めにご注意 • このpresentationは実際に存在するロング ファットネットワーク上でデータ転送実験を 行ったものではありません • さらにHigh Throughputを達成するための プログラム等を開発したわけでは（今のと ころ）ありません • RTT/cwnd/ssthreshなどの用語を何の断り もなく使用します 2001/09/28 Linux Conference 2001 2/40 話の進み方 • （１） 前回のおさらい – LHC , ATLAS , 地域解析センター , WANとLAN , ネッ トワークシミュレータの構築 • （２） ネットワークシミュレータを利用した測定 – 遅延 , 輻輳 , Window Size , Slow Start , パフォーマン ス測定 • （３） 結果に対する考察 – 何が足りないのか？ 2001/09/28 Linux Conference 2001 3/40 次期陽子陽子衝突型実験 Detector for LHCb experiment 取得データ量 １００MB/sec ↓ １PB/year これを３４ヶ国の １８５０人が利用する (ATLASの場合) Detector for ALICE experiment 2001/09/28 Linux Conference 2001 4/40 物理データ解析のチャレンジ "干し草の山の中から針を探しだす" • 毎秒 10億回の衝突事象 オンラインで選別 毎秒 100 事象を保存 1年あたり 10億事象 • データサイズ 1 Mbyte/事象 4実験で年間数ペタバイト • 事象再構築: ~ 300 SPECint95*秒/事象 事象再構築だけで 20万SPECint95 のCPUパワーが必要 データ解析にさらにその数倍が必要になる データ解析も国際協力で！ "MONARC"プロジェクト Linux Conference 2001 5/40 High Throughput, Data-Intensive Computing 2001/09/28 多階層型地域解析センターモデル Multi-Tier Regional Center Scheme ~PBytes/sec Online System Bunch crossing per 25 nsecs. 100 triggers per second Event is ~1 MByte in size Tier 1 France Regional Center ~100 MBytes/sec ~622 Mbits/sec or Air Freight Italy Regional Center Workstations 2001/09/28 US Regional Center ~4 TIPS ~2.4 Gbits/sec Tier2 Center Tier2 Center Tier2 Center Tier2 Center Tier2 Center ~1 TIPS ~1 TIPS ~1 TIPS ~1 TIPS ~1 TIPS ~622 Mbits/sec Institute Institute Institute ~0.25TIPS CERN Computer Center >20 TIPS Tier 0 Tier 2 Physics data cache PC (1999) = ~15 SpecInt95 Offline Farm ~20 TIPS ~100 MBytes/sec Germany Regional Center Tier 3 1 TIPS = 25,000 SpecInt95 Institute 100 - 1000 Mbits/sec Tier 4 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 Linux Conference 2001 6/40 24 March 2000, WW A/C Panel, P. Capiluppi アトラス日本グループの地域解析センター • KEKと東大・素粒子国際研究センター(ICEPP)の共同で 技術開発を推進 • 2006年までに 約6万SPECint95の計算機からなるTier-1 データ解析システムを国内に構築、ストレージを約1ペタ バイトまで段階的に増強 • 補完的役割を担うCERN分室を設立 • 2001年末から始まるアトラスのデータ・チャレンジに参加 • NIIのSuperSINET計画にGrid/アトラスの専用回線 – 2001年度末に KEK-ICEPP間に 1 ~ 10 Gbps 2001/09/28 Linux Conference 2001 7/40 地域解析センター実現のための技術課題 • 広域広帯域ネットワークの利用 – – – – 今回はこれに特化した話です TCP/IPの技術的制約と効率的ファイル転送技術の必要性 サイト間にまたがる研究者の認証とセキュリティの確保 実験データの分配・複製機構 計算資源の効率的管理 • 大規模データストレージと大規模CPUクラスター – スケーラブルでフォルトトレラントな大規模システム – 共同研究者間で透過的に利用できる広域データ共有システム 2001/09/28 Linux Conference 2001 8/40 帯域幅の使われ方 • 普通（？）の場合 帯域幅 ノード A ノード a ノード B ノード C ノード b ハブ ハブ ノード c ノード D ノード d ノード E ノード e • 今回の目標 ノードA 2001/09/28 帯域幅 ハブ ハブ Linux Conference 2001 ノードa 9/40 WANとLANの違い • 遅延時間が長い – 数百msec単位 / LANでは数msec単位かそれ以下 • 途中経路に広い回線から細い回線へのルータが 存在している可能性が高く、そこでのキュー容量 の制限によりパケットロスが生じ輻輳が発生する • このため、TCPのようなコネクション指向のプロト コルにおいては、そのスループットを安全に最大 へと誘導する通信メカニズムが必要 ⇒ 一般にはSlow Startの機構が動作する 2001/09/28 Linux Conference 2001 10/40 WANでのデータ転送（１） • 標準設定 • 拡大図 60 400 転送量（KB） 300 250 25Mbps 50 ( KEK-CERN Backup Network ) 40 転送量（KB） 350 200 150 RTT 30 20 100 10 50 0 0 0 1 2 3 4 5 6 7 8 9 10 0 1 1.5 時間（秒） 時間（秒） 2001/09/28 0.5 Linux Conference 2001 11/40 2 なぜ遅い？ • 送信側は受信側からの応答確認（ack）があ るまで次のセグメントをネットワーク上へ流 すことができない • 一回に流すセグメント数（cwnd）が10Kbytes ほどで頭打ちになっている • LANだとRTTが小さいためほとんど気にな らないがWANではその数百倍（100ms単 位）にもなるためパフォーマンスが低下する 2001/09/28 Linux Conference 2001 12/40 じゃあどうする？ • 一回に流す（バーストさせる）パケット量を 増やして１RTTあたりの転送レートを上げる • そのためには受信側から告知されOffered Window Sizeを変えてcwndのとれる最大値 を大きくしてやればよい • ただしSlow Startによる輻輳回避戦略のた め、cwndは確認応答を受信しながら徐々に 大きくなっていく 2001/09/28 Linux Conference 2001 13/40 いろんなWindow Size • “cwnd” • いろいろ 8 300 7 250 転送量（KB） 転送量（MB） 6 5 4 3 200 150 100 2 50 1 0 0 0 1 2 3 4 5 6 7 8 9 10 1 2 3 4 5 6 7 8 時間（秒） 時間（秒） 2001/09/28 0 Linux Conference 2001 14/40 9 10 輻輳発生時 • “cwnd” 25 250 20 200 転送量（KB） 転送量（MB） • win = 256K 15 10 150 100 5 50 0 0 0 30 60 90 120 150 180 30 60 90 120 150 時間（秒） 時間（秒） 2001/09/28 0 Linux Conference 2001 15/40 180 RTTとWindow Size • RTTが小さいとき time 5: (cwnd = 6) 送 → seg6 seg5 seg4 → 受 送 ← ack1 ack2 ack3 ← 受 • RTTが大きいとき RTTが大きい時に利用 効率を上げるためには 広いWindow Sizeが必要 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 →受 ←受 2001/09/28 Linux Conference 2001 16/40 KEKでのMONARC Testbed • KEK⇔CERN回線 – 地上回線 4Mbps RTT～300ms (nacsis提供) – 衛星回線 2Mbps RTT～600ms (crl提供) • 両端にSolaris/Linux等を設置しOODB （Objectivity/DB）やファイル転送等の性能測定を 行ってきた • 将来、広帯域（数百Mbps～数Gbps）で接続された場 合のTestbedも行いたい • 接続先のマシン設定を自由に変更したい → 疑似遅延環境を構築してそこでTestbedを行う 2001/09/28 Linux Conference 2001 17/40 遅延の実現方法 • 一番簡単かつ確実な方法 – ケーブルを必要なだけとぐろ巻きにする – 数百msecだととてもじゃないがやってられない • 市販の遅延器（？）を使う – ATM用のがあるらしい – コストが不明….. • そこでお手軽にLinux PCのルーターに小細工を して自分で作ることにする 2001/09/28 Linux Conference 2001 18/40 遅延ルーティング用プログラム • あるifからパケットをひたすら取り込みそれ を分離スレッドにして遅延をかけた後でそ れを別のifから送信する • 必要なもの – パケットキャプチャー – パケットインジェクター • 詳細は以下をどうぞ – http://atlas.kek.jp/People/yuki/lc2k_fall/ 2001/09/28 Linux Conference 2001 19/40 Gigabit Ethernet • 昔は高値の花だったが今は１万円を切るものもある • 光ファイバーでなく銅線利用のものが多くなってきた • 1000Mbps出すには – – – – 優秀なチップセット 64bitPCIバス ジャンボフレーム （MTU=9000) がおそらく必要 • ただしジャンボフレームを通すハブはまだまだ高価なの で、しばらくはFast Ethernetの２～３倍程度の速度での運 用か （SuperSINETは？） 2001/09/28 Linux Conference 2001 20/40 Gigabit Ethernetの測定例 990Mbps Transfer speed in Mbit/s 1000 ネットワーク性能 900 800 ServerSetIIILEチップセット搭載機 （64bitPCI付き） 700 600 32-bit P CI(mt u1500) 64-bit P CI(mt u1500) 32-bit P CI(mt u9000) 64-bit P CI(mt u9000) 500 400 300 はっきし言って バケモンである 200 100 0 0.01 1 100 10000 恐るべしServerSet..... Message size in KB 2001/09/28 Linux Conference 2001 21/40 で、Linuxでうまく行ったの？ • 数＋Mbpsぐらいならうまくいったんですが • それを超えると完全にアウトで、パケット落 ちまくり • うーん..…どうしよう • そんなとき、悪魔の囁きによりFreeBSDへ と浮気..................... 2001/09/28 Linux Conference 2001 22/40 DUMMYNET • さまざまな条件下でのネット ワークのシミュレーションを行 う • FreeBSDのカーネルに組み込 んで使用 • 以下の様なものが制御できる – 帯域幅 – 遅延 – パケット損失 • http://info.iet.unipi.it/~luigi/ip_dummynet/ 2001/09/28 Linux Conference 2001 23/40 Testbed セットアップ (1) Delay : 300msec 192.168.148.105:eth2 Gigabit-Ethernet GB+FE Hub PentiumIII 733MHz 128MB / SSIIILE Router (FreeBSD) Fast-Ethernet GB+FE Hub eth1:192.168.158.103 PentiumIII 800MHz 256MB / P3B-F Host A (Linux) 2001/09/28 Gigabit-Ethernet Fast-Ethernet 192.168.148.101:eth1 Destination Gateway default gw1.kek.jp 192.168.158.0 192.168.148.105 eth1:192.168.158.105 PentiumIII 800MHz 256MB / P3B-F Host a (Linux) Iface eth0 eth1 Destination Gateway default gw1.kek.jp 192.168.148.0 192.168.158.105 Linux Conference 2001 Iface eth0 eth1 24/40 こうなってます • FE(16)+GB(2) Hub • ぼろい..... ルータマシン 2001/09/28 Linux Conference 2001 25/40 WANでのThroughput向上のために • 標準的な手法としてよく採られるのは以下 の２つ – （１） Window Sizeの拡大 – （２） Parallel Connectionにする • しかしながらこれらの方法では十二分にパ フォーマンスを上げることができないことが シミュレーションを利用した測定により判明 2001/09/28 Linux Conference 2001 26/40 シミュレータを利用した測定 （１） Throughput (Mbps) • Window SizeとThroughput (Linux2.2の場合） 100 90 80 70 60 50 40 30 20 10 0 1 0 200 400 600 Window Size (kbytes) 800 1000 700kbytesまでは上昇するがそのあとが伸びない 2001/09/28 Linux Conference 2001 27/40 パフォーマンスが伸びない理由 • tcpdumpで追っかけてみると 15:43:02.772309 15:43:02.772312 15:43:02.772315 15:43:02.772317 15:43:02.772320 > > > > > foo01.1133 foo01.1133 foo01.1133 foo01.1133 foo01.1133 > > > > > foo02.1338: foo02.1338: foo02.1338: foo02.1338: foo02.1338: P P P P P 2202409:2203857(1448) 2203857:2205305(1448) 2205305:2206753(1448) 2208201:2209649(1448) 2209649:2211097(1448) ack ack ack ack ack 1 1 1 1 1 • セグメント 2206753:2208201(1448) が抜けている • NICの種類を変えても再現するので、おそらくネッ トワークカーネルのバグ？ 2001/09/28 Linux Conference 2001 28/40 シミュレータを利用した測定 （２） • Window SizeとThroughput (FreeBSD4.2の場合） 40 35 転送量(Mbps) 30 25 20 15 10 5 0 0 500 1000 1500 ウインドウサイズ(kB) 2000 100 90 80 70 60 50 40 30 20 10 0 2500 10秒 30秒 60秒 CPU Linuxよりかは伸びるがそれでも途中で息切れ 2001/09/28 Linux Conference 2001 29/40 Window Sizeを拡大する方法は • Linuxではセグメント落ちのバグのため途中で頭 打ち • FreeBSDでもLinuxよりかは伸びるがそれでも CPUパワーでリミットがかかる • さらに輻輳発生時の回復過程時のパフォーマン スの低下を考えると、Window Sizeを拡大しすぎ るのも考えもの • それではparallelにやる方法は？ 2001/09/28 Linux Conference 2001 30/40 シミュレータを利用した測定 （３） Throughput (Mbps) • Window SizeとThroughput (Linux2.2の場合） 100 90 80 70 60 50 40 30 20 10 0 1 2 4 8 16 0 200 400 600 Window Size (kbytes) 800 1000 Parallel ConnectionによりThroughputが上昇している 2001/09/28 Linux Conference 2001 31/40 実際にファイルを転送してみると • Parallel Connectionの設定値（Window Size, Connection数）で実際にファイルからデー タを読み込み、転送を行い、ファイルへと 書き込むと • これが全く性能が出ない • 測定に再現性も無い • なぜ？ 2001/09/28 Linux Conference 2001 32/40 ファイルに書くと駄目な理由 • ファイルとの入出力はメモリを介して行わ れる • ところがメモリが一杯になりディスクへのフ ラッシュが発生した瞬間に輻輳が発生した のと同様な状態になる • その結果として輻輳Window Sizeが縮小し Throughputが低下する 2001/09/28 Linux Conference 2001 33/40 さらにおまけ • Parallel Connectionの各ソケットが同時にSlow Startを始めるとパフォーマンスが低下する • 前のプロットでは各Connection 0.5秒程、ずらしな がら測定した • 同時にやると次のプロットのようになる • 世の中に存在するparallel指向のデータ転送プロ グラムがここんとこを考慮しているかは不明 2001/09/28 Linux Conference 2001 34/40 シミュレータを利用した測定 （４） • Window SizeとThroughput (Linux2.2の場合） Throughput (Mbps) 100 80 1 2 4 8 16 60 40 20 0 0 200 400 600 800 1000 Window Size (kbytes) 同時にSlow Startを始めるとパフォーマンスが出ない 2001/09/28 Linux Conference 2001 35/40 Testbed セットアップ (2) Delay : 300msec PentiumIII 800MHz 256MB / P3B-F Host A (Linux) PentiumIII 800MHz 256MB / P2XBL Host B (Linux) PentiumIII 733MHz 128MB / SSIIILE Router (FreeBSD) FE+GB Hub FE+GB Hub PentiumIII 600MHz 256MB / P6SBA Host C (Linux) Fast PentiumIII 800MHz 256MB / P3B-F Host a (Linux) PentiumIII 800MHz 256MB / P2XBL Host b (Linux) PentiumIII 450MHz 128MB / P2B-F Host c (Linux) PentiumIII 800MHz x2 256MB / Tiger100 Host D (Linux) 2001/09/28 Gigabit Linux Conference 2001 PentiumIII 800MHz x2 256MB / Tiger100 Host d (Linux) 36/40 シミュレータを利用した測定 （５） Total TCP Throughput (Mbps) • PCの台数とThroughput (Linux2.2の場合） 300 WindowSize：４５０Kbytes #’ connection:８ に固定 250 200 150 100 50 0 1 2 3 The number of PC 4 落ちる原因 ↓ ルータのCPUパワーが 足りないため ３台目までは順調に伸びるがそれを超えると落ちる 2001/09/28 Linux Conference 2001 37/40 2.4と2.2の違い • Slow Startの立ち上がりは2.2よりも速い • Window Sizeの自動コントロール – ある意味「余計なことしてくれるな」 • ssthreshをキャッシュして再利用 – このため輻輳が発生した後はパフォーマンスが著しく 低下する – クリアするためにはifdownさせるかカーネルソースを 直すしかない？ （FreeBSDではコマンドで変更可） • 2.2の方がよかった…..かも 2001/09/28 Linux Conference 2001 38/40 今後の予定 • もうちょっとパフォーマンスを引っ張りたい ので新しいPCが欲しいかなぁ、と （センター長さん、予算下さい.....） • データグラムを用いたファイル転送 （教科書には「やるな！」と書いてある） • 擬似的なprocedureを作り、データ生成→ 転送→データ読込の連続運転をしてみる 2001/09/28 Linux Conference 2001 39/40 まとめ • 地域解析センター Testbeds環境構築のた め、遅延時間300msのシミュレータを組み その上で各種測定を行った • 現在あるTCP/ハードウェアで高遅延広帯 域を効率よく利用するのは困難 • もうちょと工夫が必要 – TCPの見直し？ – 何か良い方法ないですか？ 2001/09/28 Linux Conference 2001 40/40
© Copyright 2024 ExpyDoc
