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

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

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

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

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

Multi-Tier Regional Center Scheme 多階層型地域解析センターモデル Multi-Tier Regional Center Scheme Tier2 Center ~1 TIPS Online System Offline Farm ~20 TIPS CERN Computer Center >20 TIPS US Regional Center France Regional Center Italy Regional Center Germany Regional Center Institute Institute ~0.25TIPS Workstations ~100 MBytes/sec ~2.4 Gbits/sec 100 - 1000 Mbits/sec HPSS Bunch crossing per 25 nsecs. 100 triggers per second Event is ~1 MByte in size 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 Physics data cache ~PBytes/sec ~622 Mbits/sec or Air Freight ~622 Mbits/sec Tier 0 Tier 1 Tier 3 Tier 4 1 TIPS = 25,000 SpecInt95 PC (1999) = ~15 SpecInt95 Tier 2 ~4 TIPS 2001/09/28 Linux Conference 2001 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

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

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

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

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

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

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

いろんなWindow Size いろいろ “cwnd” 2001/09/28 Linux Conference 2001

輻輳発生時 win = 256K “cwnd” 2001/09/28 Linux Conference 2001

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 ← 受 2001/09/28 Linux Conference 2001

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

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

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

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

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

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

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

Testbed セットアップ (1) Delay : 300msec PentiumIII 733MHz 128MB / SSIIILE 192.168.148.105:eth2 PentiumIII 733MHz 128MB / SSIIILE Router (FreeBSD) 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 PentiumIII 800MHz 256MB / P3B-F Host A (Linux) PentiumIII 800MHz 256MB / P3B-F Host a (Linux) 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 2001/09/28 Linux Conference 2001

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

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

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

パフォーマンスが伸びない理由 tcpdumpで追っかけてみると セグメント 2206753:2208201(1448) が抜けている 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の種類を変えても再現するので、おそらくネットワークカーネルのバグ？ 2001/09/28 Linux Conference 2001

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

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

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

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

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

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

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

Testbed セットアップ (2) Delay : 300msec Gigabit 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) 2001/09/28 Linux Conference 2001

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

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

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

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