ATLAS実験データ解析に向けた、長距離広帯域ネットワークにおけるデータ転送

Presentation on theme: "ATLAS実験データ解析に向けた、長距離広帯域ネットワークにおけるデータ転送"— Presentation transcript:

1 ATLAS実験データ解析に向けた、長距離広帯域ネットワークにおけるデータ転送
東京大学素粒子物理国際研究センター 磯部忠昭，坂本宏，真下哲郎，上田郁夫， 田中純一，松永浩之 日本物理学会　第63回年次大会＠近畿大学

2 ATLASデータグリッドにおける東京解析センター
10G Line 国内でのデータ解析を円滑に行う為、Tier2サイトとして参加し ている 年間1ペタバイト程の転送→数十MByte/secのthroughputが必要 CERN研究所→フランス、リヨン→東京 帯域は10Gbpsになった, (Round Trip Time(RTT)~280ms) ATLASのモデル想定外だが、ICEPP – CERN (東大保有のク ラスター)のラインも我々には重要 帯域は1Gbps, 経路はほぼ同じ(RTT~270ms)

3 長距離広帯域ネットワークにおけるデータ転送
広帯域だが、RTTが長いため効率 よくパケットを送るための調整が 必要になる TCP window sizeの調整 同時転送ファイル数、ストリーム 数を増やすことでメモリ/CPUに負 荷はかかるが、高いパフォーマン スが期待できる しかしFile Fragmentationによる Disk I/O性能の低下も懸念される ポイント 効率よい転送を実現するため、 Memory-to-memory, disk-to-disk での転送テストを基にシステムの 最適化を行う Internet

4 測定その１:メモリ間でのネットワーク測定（東京⇔リヨン）
iperf を用いてディスクI/Oの効果が無いnetwork throughputを測定した 東京地域解析センターに２タイプのサーバを設置 Scientific Linux CERN(SLC) 3: kernel 2.4系 Scientific Linux CERN(SLC) 4: kernel 2.6系 LYON, CC-IN2P3にも２タイプ設置 SL3(kernel 2.4)とSL4(kernel 2.6)を準備 RTT～280msec. TCP window sizeを8MByteに固定した Network Cardは1Gbpsのものを利用しているため、 1Gbpsで頭打ちになる

5 iperfによるメモリ間throughput測定
Window size: 8M, ストリーム数: 8で5秒毎のthroughputを測定した kernel 2.4系の場合 kernel 2.6系の場合 kernelの違いにより大きくthroughputが異なる kernel 2.6系にBicTCPが導入された為と思われる kernel2.4系の場合は緩やかなthroughputの上昇が見られる kernel2.6系の場合はthrouthputの上昇が2.4に比べ早く、リカバリも早い Lyon<->Tokyoの方向の違いによるthroughputの差は現在調査中

6 throughput長期測定(リヨン→東京)
２分間パケットを流し、平均速度を各ストリーム数についてプロットした １０日間ほど測定したが、時間帯によらず、ほぼ安定した速度が出ている

7 測定その２:各サイトのファイルサーバ間における実ファイル転送環境
東京地域解析センター Intel Xeon 3.0GHz, 8GByte memory, 10GB-NIC TOKYO siteがATLAS Data GRIDに提供している機種 SLC4.6, xfs file system, gridftpはglobus toolkit 4.0.5のものを使用 CERN研究所内にある東大素粒子センターオフィス Intel Xeon 2.4GHz, 2GByte memory, 1GB-NIC SLC4.6, ext3 file system, gridftpはgLite middleware (v3.0)で提供し ているものを使用 フランス-リヨン、CC-IN2P3 Thumper, Solaris OS, ZFS Grid middlewareのFile Transfer Service(FTS)により転送が制御され ている ファイル転送後、cat “files” > /dev/nullで読み出し速度を測定 した。

8 GRIDFTPによる実ファイル転送の測定 (CERN東大オフィス→東大ICEPP)
ストリーム数依存性 同時転送ファイル数依存性 １ホスト-to-１ホストで最大約75MByte/sec.での転送に成功 総ストリーム数が多すぎると速度が低下する→サーバへの負荷による効果と思われる File Fragmentation による読み出し速度の低下が見られる(約半分の速度まで低下) これらのファイルは一度別にコピーすることで読み出し速度が回復する bbftpでもいくつかテストを行ったが、転送速度はgridftpの方が２倍以上速い

9 ATLASデータグリッドにおけるリヨン→東京のファイル転送パフォーマンス
Gridftpのログを基に30sec.平均でのファイル転送速度を測定 素粒子センターに設置されている６台のファイルサーバーへの転送状態(合計)をプロットした 転送効率を上げるため、同時転送ファイル数を調整した M6 東京解析センター への実効転送速度 M6 同時転送ファイル数 同時転送ファイル数～40程で限界値だった 10Gbpsの恩恵もあり、最大値で360MByte/secを達成 M6のデータを安定して高速に転送できている(約4TByteのデータ) #stream/Trans.=10

10 まとめ iperfを用いてmemory-to-memoryでのネットワーク性能を 測定した gridftpによる実データの転送試験を行った
kernel2.4系よりkernel2.6系の方がthroughtputの上昇が早く 大容量データ転送に適している 日本⇔ヨーロッパ間のネットワークは安定している gridftpによる実データの転送試験を行った 同時転送ファイル数やストリーム数といったパラメータの調 整によりCERNから効率よくデータが転送できた 同時転送ファイル数が多い場合、File Fragmentationによる ファイルの読み出し速度低下が考えられるので調整が必要 ATLAS グリッドのデータ転送を高速に安定して行った リヨンから最大360MByte/sec.でのデータ転送に成功した M6で約4TByteのデータを転送した

11 backup

12 throughput長期測定(東京⇔リヨン)
東京→リヨン リヨン→東京 ２分間パケットを流し、平均速度を各ストリーム数についてプロットした １０日間ほど測定したが、時間帯によらず、ほぼ安定した速度が出ている