1 / 17

Grid Datafarm for a HEP application

SC2002 High-Performance Bandwidth Challenge. Grid Datafarm for a HEP application. Osamu Tatebe (Grid Technology Research Center, AIST) Satoshi Sekiguchi(AIST), Youhei Morita (KEK), Satoshi Matsuoka (Titech & NII), Kento Aida (Titech), Donald F. (Rick) McMullen (Indiana),

coral
Download Presentation

Grid Datafarm for a HEP application

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. SC2002 High-Performance Bandwidth Challenge Grid Datafarm for a HEP application Osamu Tatebe (Grid Technology Research Center, AIST) Satoshi Sekiguchi(AIST), Youhei Morita (KEK), Satoshi Matsuoka (Titech & NII), Kento Aida (Titech), Donald F. (Rick) McMullen (Indiana), Philip Papadopoulos (SDSC) Data Grid ミニワークショップ 国立天文台＠三鷹 2002年12月11日

  2. SC2002 high-performance bandwidth challenge • demonstrate exciting applications at the maximum possible speed

  3. Bandwidth Challenge!!!! Overview of Our Challenge • Seven clusters in US and Japan comprise a cluster-of-cluster file system: Gfarm file system • The FADS/Goofy simulation code based on the Geant4 toolkit simulates the ATLAS detector and generates hits collection (a terabyte of raw data) in the Gfarm file system • The Gfarm file system replicates data across the clusters

  4. 一ヶ所に保存すると 保存箇所以外からの書き込み・読み出しに時間がかかる 災害時などにデータが失われたり、アクセスできなくなったりする グリッド技術（グリッドデータファーム）を用いた テラバイト（１兆文字）クラスの大規模データ • 分けて別々に保存すると • 別々の管理単位になり、管理、アクセスが大変 • 手元にないデータへの読み書きは時間がかかる • 災害時などには部分的にデータが失われたり、アクセスできなくなったりする

  5. グリッドデータファームを使うと • 複数分散ディスクによりファイルシステムを構成 • 分散して書き込まれた複数ファイルを一つのファイルとして扱える • 部分的な複製ができる • 複数の複製により障害に備える • データがある場所でそのデータを高速処理する バルチモア つくば 東京 インディアナ サンディエゴ

  6. Target Application at SC2002: FADS/Goofy • Monte Carlo Simulation Framework with Geant4 (C++) • FADS/Goofy: Framework for ATLAS/Autonomous Detector Simulation / Geant4-based Object-oriented Folly http://atlas.web.cern.ch/Atlas/GROUPS/SOFTWARE/OO/domains/simulation/ • Modular I/O package selection:Objectivity/DB and/or ROOT I/Oon top of Gfarm filesystemwith good scalability • CPU intensive event simulationwith high speed file replicationand/or distribution

  7. Network and cluster configuration for SC2002 Bandwidth Challenge OC-12 Indiana Univ. Indianapolis GigaPoP Tsukuba WAN 1 Gbps OC-12 POS SC2002, Baltimore PNWG AIST Tokyo NOC 10 GE APAN/TransPAC Grid Cluster Federation Booth SCinet 10 GE E1200 OC-12 ATM (271Mbps) StarLight Titech GbE SuperSINET NII-ESnet HEP PVC OC-12 ICEPP KEK ESnet NOC SDSC GbE 20 Mbps US Japan SC会場とのデータ転送の理論総バンド幅 2.1 Gbps KEK Titech AIST ICEPP SDSC Indiana U SC2002 Total disk capacity: 18 TB, disk I/O bandwidth: 6 GB/s

  8. SC2002 バンド幅チャレンジ 2.3 Gbps! 日米間通信 741Mbps 複数経路を 同時利用 世界初！ 実証実験:複製 インディアナ大 産総研 つくば つくばWAN MAFFIN 10Gbps 1Gbps 622Mbps 622Mbps 大手町 シアトル 米 国内網 SC2002 会場 KEK 271Mbps シカゴ 10Gbps 20Mbps 622Mbps 1Gbps 1Gbps サンディエゴ SDSC 東工大 東大 バルチモア

  9. SC会場 GbEで接続された12ノードのPCクラスタをForce10 E1200で10GEでSCinetに接続 LANにおける性能 ネットワークバンド幅は930Mbps ファイル転送性能は75MB/s(=629Mbps) AIST 同等の7ノードのクラスタ。GbEでつくばWAN、Maffinを経て東京XPに接続 Indiana大 FEで接続された15ノードのクラスタ。OC12でIndianapolis GigaPoPに接続 SDSC GbEで接続された8ノードのクラスタ。OC12で外部接続 TransPACの南北ルートのルーティング デフォルトは北ルート SC会場、AISTのそれぞれ3ノードについて南ルートを通るよう東京XP、Maffinで設定 AIST、SC会場間のRTT: 北ルート 199ms、南ルート 222ms 南ルートは271Mbpsにシェーピング GbE PC E1200 OC192 10GE SCinet 12 ノード PC ネットワーク、クラスタ構成の特徴 SC2002会場のネットワーク構成

  10. 大きな遅延 RTT: 北回り 199ミリ秒、南回り 222ミリ秒 socket buffer size の拡大 複数ストリーム、ネットワークストライピング パケットロスによる window size の限界 High Speed TCP(HSTCP, net100）の利用 Sally Floyd の Internet Draft 輻輳ウィンドウの早期復帰 過大な window size によるパケットロスの増大 小さな socket buffer で複数のストリームを利用 ディスク性能の限界 複数のストリームによる並列ディスクアクセス ストライピング・アクセス 適切なストライプ・サイズの選択 複数ホストへの分割 gfarm –断片化されたファイル ノード数が少ないため、必要バンド幅を達成するために必要最小限のノードを利用、単体性能の向上 1ノードあたり平均200Mbps! ネットワークの理論性能近くを達成するためには、全ルートのデバグが必要。（皆様お手数をおかけしました） ルータごとのパケットロス率、 Abileneカンザスシティ、デンバー間のパケットロス修正 北ルート米国方向で35Mbpsから500Mbps強に大改善！ TransPAC南ルート（OC-12 ATM)のセルロス 解決できず。271MbpsにシェープしたPVCを利用 転送可能なレートを超えて送信すると急激に性能低下 送信バッファサイズによる制御 送信間隔による制御 ネットワーク転送のみ：250Mbps程度、ファイル転送：170Mbps程度 シェーピングをはずして、アプリケーションで転送レートを制御しても改善せず HSTCPおよびnet100パッチによる複数TCPストリームのバンド幅不均衡 単一ストリームのバンド幅が過大にならないよう転送レート制御が必要 ネットワーク性能とファイル転送性能の性能差 Incomingとoutgoingストリームの性能は必ずしも輪にならない 片方向だけよりも劣化する場合も APAN/TransPAC における詳細な測定モニタの必要性 1分平均値 → 10秒、1秒、1/10秒平均が必要 Lessons from the Challenge 64KB/0.2sec = 2.62Mbps 200ms 64KB 700Mbpsを達成するには280台（ストリーム）必要、これを4台で達成 チャレンジ Lessons

  11. IperfによるTransPAC性能評価 北ルート 10-sec average bandwidth 南ルート SC会場から南北両ルートに対し、 北ルート2ノード、南ルート3ノード の計10ノードを利用して 753Mbps(10秒平均)を達成 （理論ピーク性能：622+271=893Mbps） 5-min average bandwidth

  12. IperfによるSC会場とのバンド幅測定（1分平均）IperfによるSC会場とのバンド幅測定（1分平均） TransPAC北 SDSC インディアナ大 TransPAC南 TransPACのバンド幅は測定時の 状況により大幅に変化 米国内Abileneのパケットロス障害による

  13. 日米間のグリッド実験 産経新聞12月1日 日経産業新聞11月22日 日本経済新聞11月21日夕刊 読売新聞11月21日夕刊 米国4ノード、日本4ノード、ファイル転送で 741 Mbps達成！ （10秒平均）

  14. TransPACにおけるファイル転送の設定と結果

  15. SC会場とIndianaおよびSDSCのファイル複製性能

  16. Bandwidth Measurement Result 1-sec average bandwidth 10-sec average bandwidth 0.1-sec average bandwidth We achieved 2.3 Gbps using 12 nodes! (outgoing 1.7 Gbps, incoming 0.6 Gps)

  17. Special thanks to • Rick McMullen, John Hicks (Indiana Univ, PRAGMA) • Phillip Papadopoulos (SDSC, PRAGMA) • Hisashi Eguchi (Maffin) • Kazunori Konishi, Yoshinori Kitatsuji, Ayumu Kubota (APAN) • Chris Robb (Indiana Univ, Abilene) • Force 10 Networks, Inc

More Related