ロングファットネットワーク上での
高速データ転送
「ATLAS地域解析センター
Testbed環境の構築」
高エネルギー加速器研究機構
計算科学センター
佐藤博之
2001/09/28
Linux Conference 2001
1/99
始めにご注意
• このpresentationは実際に存在するロング
ファットネットワーク上でデータ転送実験を
行ったものではありません
• さらにHigh Throughputを達成するための
プログラム等を開発したわけでは(今のと
ころ)ありません
• RTT/cwnd/ssthreshなどの用語を何の断り
もなく使用します
2001/09/28
Linux Conference 2001
2/40
話の進み方
• (1) 前回のおさらい
– LHC , ATLAS , 地域解析センター , WANとLAN , ネッ
トワークシミュレータの構築
• (2) ネットワークシミュレータを利用した測定
– 遅延 , 輻輳 , Window Size , Slow Start , パフォーマン
ス測定
• (3) 結果に対する考察
– 何が足りないのか?
2001/09/28
Linux Conference 2001
3/40
次期陽子陽子衝突型実験
Detector for
LHCb experiment
取得データ量
100MB/sec
↓
1PB/year
これを34ヶ国の
1850人が利用する
(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でのデータ転送(1)
• 標準設定
• 拡大図
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
じゃあどうする?
• 一回に流す(バーストさせる)パケット量を
増やして1RTTあたりの転送レートを上げる
• そのためには受信側から告知され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
• 昔は高値の花だったが今は1万円を切るものもある
• 光ファイバーでなく銅線利用のものが多くなってきた
• 1000Mbps出すには
–
–
–
–
優秀なチップセット
64bitPCIバス
ジャンボフレーム (MTU=9000)
がおそらく必要
• ただしジャンボフレームを通すハブはまだまだ高価なの
で、しばらくはFast Ethernetの2~3倍程度の速度での運
用か (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向上のために
• 標準的な手法としてよく採られるのは以下
の2つ
– (1) Window Sizeの拡大
– (2) Parallel Connectionにする
• しかしながらこれらの方法では十二分にパ
フォーマンスを上げることができないことが
シミュレーションを利用した測定により判明
2001/09/28
Linux Conference 2001
26/40
シミュレータを利用した測定
(1)
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
シミュレータを利用した測定
(2)
• 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
シミュレータを利用した測定
(3)
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
シミュレータを利用した測定
(4)
• 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
シミュレータを利用した測定
(5)
Total TCP Throughput (Mbps)
• PCの台数とThroughput (Linux2.2の場合)
300
WindowSize:450Kbytes
#’ connection:8
に固定
250
200
150
100
50
0
1
2
3
The number of PC
4
落ちる原因
↓
ルータのCPUパワーが
足りないため
3台目までは順調に伸びるがそれを超えると落ちる
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
ダウンロード

プレゼンテーション(PowerPoint)