LCG@ICEPP…

1. LCG@ICEPP… 田中純一ICEPP Gfarm meeting

2. 内容 • LCG • ATLAS実験のグリッド • 実験データとジョブ Gfarm meeting

3. LHC Computing Grid Project • 略称 = LCG • LHC 4実験共同でGridを配備する計画 • フェーズ1=研究開発 • 2002年～2005年 • Gridミドルウエア仕様決定 • 2005年LHC Global Grid Technical Design Report • フェーズ2=配備 • 2006年～ • LHC実験データ解析プラットフォーム • 高エネルギー物理学実験のための“グリッド”標準になる可能性がある。 http://lcg.web.cern.ch Gfarm meeting

4. LHC 4実験 ATLAS、CMS、Alice、LHCｂ実験の合計4実験がある。 3.5PB/年のデータを 保存して、解析する。 この見積もりは、若干古い。 例えば、ATLAS実験は 100MB/ｓから300～400MB/sへ 上がっている。10~15PB/年 Gfarm meeting

5. 国際ネットワーク NII(国立情報学研究所) (予定) 日本 NewYork 欧州 日本からアメリカを経由して欧州へ：10Gbps Gfarm meeting

6. CERN IT （その１） 1445m2 Gfarm meeting

7. CERN IT （その２） Gfarm meeting

8. LCGとは？ • グリッド環境を構築することが仕事。 • ミドルウェアは既存のものから採用して、どれが優れているかを判断することが仕事。 Deployment not Development • LCGバージョン1の構成 • EDT 1.1 • EDG 2.0 • VDT 1.1.8 • Redhat 7.3 EUとUSの寄せ集め Gfarm meeting

9. LCGのバージョン • LCG0 ： 2003年4月～ • ICEPP：インストールしたが、すでに停止。 • LCG1 ： 2003年7月～ • ICEPPで稼動中 • LCG2 ： 2004年2月～ • ICEPPではこれから。 • 10サイト程度で稼動中 • データ生成・保存のために利用中 （Alice実験） そのため、LCGチームは非常に忙しい!! • 10サイト以外は、自力でインストール • LCGチームは、それどころではない。。。 Gfarm meeting

10. ノードの構成 • 各サイトにすべて必要というわけではないが、以下のような役割を持ったノードを準備する。 MON IC NM VOMS RB LCFG MDS BDII RLS CE SE WN PROX VO UI 現状では名前だけ @LCG1 Gfarm meeting

11. LCGの現状@ICEPP • LGCバージョン1で稼動中 • CE、SE、UI、WNの最小構成でスタート。 • LCFG = Local Configuration system • OSを含めて、各ノードのインストール、設定を自動的に行う。 • 各ノードの設定変更もここで行う。 • 設定ファイルの変更  XMLに変換 ノードに変更があったことを通知 ノードはhttp経由でXMLファイルを取得  設定変更 • このシステムに慣れる必要がある。 • LCGバージョン2は、これから。 • もちろん、LCFGに100%依存しなくてもよい。 Gfarm meeting

12. 稼動状況@ICEPP Gfarm meeting

13. 計算機環境@ICEPP PenIII 1.4GHz 10GbE Gfarm meeting

14. 計算機環境@ICEPP Xeon 2.8GHz LTO2 Gfarm meeting

15. グリッドモニター Gfarm meeting

16. グリッドモニター これらは、http://www.grid-support.ac.uk/GOC/ からアクセス可能 Gfarm meeting

17. ATLAS実験のグリッドのお話 ～2004年の予定～ Gfarm meeting

18. ATLAS実験のグリッドミドルウェア 主目的は、“データ生成” • 2004年ー2005年に行われる運用テスト • 3つのグリッドミドルウェアの採用 • 1つに統一することはできなかった。 • ICEPPが採用するミドルウェア • LCG－ ホスト研究所CERNが採用する LCG （欧州発） Grid3 （米国発） NorduGrid （北欧発） Gfarm meeting

19. ATLAS実験のグリッドミドルウェア • 3つをどう扱うか？（現段階で分かっていること） • データ生成のためのジョブの投入 • それぞれの言語で、それぞれ独立に。 • RSL：Resource Specification Language • JDL：Job Description Language • 生成されたデータの取り扱い（つまり、物理解析） • 各SEのデータに、相互にアクセスできる（予定） ←物理解析@グリッドに関して、議論/開発中。 Gfarm meeting

20. 実験データとジョブのお話 ～高エネルギー業界が必要としていること？～ Gfarm meeting

21. 3 • 最終的に、毎秒100MBのデータが保存される。 • 年間、約107秒稼動するので、1PB/yearのデータになる。 2 • 技術的に無理。 • そもそも、すべてが興味ある物理事象ではない。多くはゴミ事象 • 保存する前に、必要かどうかを高速に判断する。 実験データの流れ（その１） CMS実験 1 • 1秒間に40M回の衝突が起こる。 • 衝突1回分のデータサイズは約1MB。 • 全部、保存するなら40TB/sのデータがやってくる。 Gfarm meeting

22. 主CE CERN RC (Reginal Center) グリッド ATLAS実験のデータの流れ（その２） 物理解析に使える形式までプロセスが必要。 点の情報から、 線や塊（粒子）を見つける。 100MB/sで保存されたデータ Raw Data（1MB/event） = Reconstruction（再構成）する。（トラックやジェットを作る。） Event Summary Data （ESD, 100kB/eventのデータ） 新しい検出器情報を使って、トラックやジェットの情報を更新。 物理研究ごとにAODを作成。 Analysis Object Data（AOD, 10kB/eventのデータ） 物理解析 Gfarm meeting

23. 計算機資源をどう使うか？ ～我々のジョブの特徴～ • 大きく分けて、2種類のジョブがある。 • データ生成のためのジョブ • 実験：ESDやAODの生成 • シミュレーションデータの生成 • 一つのジョブで、数GBのファイルを一つ作る。 • 数GBファイル = 数100~数105のイベントの集まり。 • 物理解析ジョブ • 生成されたデータを解析する。 • 一つのジョブで、数100ファイルを使うことが多い。 • 結果は、数個のファイル。（ヒストグラムやログ・ファイル） Gfarm meeting

24. “データ生成“ジョブの特徴 １ • 一般に、イベント単位 （ATLAS実験が例外かもしれないが） • 1ファイルに数100~数105イベント保存されていても、必ず、イベントごとに区別されている。 • 1イベントに1日、1時間もかかることはなく、長くても5~10分ぐらい。（数時間かかる実験もあるが。） →1イベントを細分化して、複数のCPUを利用する必要はない。 →イベントで分ける並列化処理は歓迎。 • シミュレーションのときは、乱数の取り扱いに注意する。 • 並列化しても、最終的に、1ファイルになればOK。 • 2GBリミットの壁があるが、これは改善されるはず。(ROOT v4) Gfarm meeting

25. “データ生成“ジョブの特徴 ２ • グリッド環境にインストールされたソフトを起動する。 • Input Fileはパラメータ等の設定のみ、つまり、サイズは小さい。 • Output Fileのサイズは、それなりに大きい。つまり、数GB～数10GB • Output FileはSEに転送されて、皆様に利用してもらう。 • この転送は“必要なこと”。 バッチジョブの特徴を持つグリッドで十分 現行のLCGで十分 Gfarm meeting

26. “物理解析”ジョブの特徴 １ • イベント単位で、解析する。 • 1つのジョブで、たくさんのファイルを利用する。 • 数100ファイルは当たり前。 • 結果は、ヒストグラム等に集約される必要がある。 • グリッド環境にインストールされたソフトを起動する。 • Input Fileが非常に大きい。 • 数GB x 数100ファイル • Output Fileは小さい。 Gfarm meeting

27. “物理解析”ジョブの特徴 ２ • Input Fileのためのファイル転送は無駄。 • そもそも、一般にCEに置けない！ • 解析ソフトからは、必要なデータファイルは見えるべき。 • NFS：SEのDiskをCEにマウント • 他のファイルシステム？AFS、GSIFS？ • “すべてのCE”から“すべてのSEのデータ”が見えることは困難？ • ジョブを分離することで、データの見えるCEで解析して、結果を集計する。 ここの解は、はっきりと見えていない！ Gfarm meeting

28. まとめ • LCG • 今後は、LCG2の利用が中心となる。 • Alice実験がデータ生成を行っている。 • Grid@ATLAS • LCG、Grid3、NorduGridを利用する。 • ICEPPはLCGを採用。 • 5月ごろから、データ生成開始。 • “物理解析“へのグリッド利用方法 • ぼんやりとした解のみ • 我々は、LCGを無視することはできない。 • 共存のみ。 Gfarm meeting

29. おしまい Gfarm meeting

30. バックアップ LCG１でのお話 LCG2では情報管理系の 構造が変化しているかも？ Gfarm meeting

31. 情報管理 • 各ノードの状況を把握することは非常に重要なことである。どこにジョブを投げる等を的確に判断するため。 GRISLocal GIIS Region GIIS BDII GlobusのMDS（Monitoring and Discovery Service）と Berkeley DB Index Informationで構成 冗長性を確保 Gfarm meeting

32. ジョブの流れ RLS RB b:ジョブを投げる c:調べる d:サイトに適した ジョブの形にする。 e:ジョブをCEに 受け渡す。 f:必要ならSEを 使ってジョブを実行する。 i:ジョブ終了。 結果をRBに戻す。 j:ユーザーに 結果を戻す。 UI BDII CE+WN SE Gfarm meeting

33. データの管理 • RLS(= Replica Location Service)がサービスを提供する。 • 冗長性やファイルアクセスの負荷を考えると、レプリカを作る必要がある。DMS(=Data Management Service)を使って レプリカ作成を行うことができる。 • ファイルの管理 －２つのカタログ • GUID(=Grid Universal/Unique ID)でファイルを一意に管理。 • 物理的なファイルとの対応：LRC(=Local Replica Catalogue) • レプリカがあるので、物理的には複数あってよい。 • メタデータとの対応：RMC(=Replica Metadata Catalogue) • 抽象的な名前も複数あってよい。 Gfarm meeting

34. 長時間ジョブとプロキシ証明書問題 • GSIではプロキシの概念(プロキシ証明書)を取り入れて、シングル・サインオンを実現している。 • 証明書が切れたら、その時点で実行されているジョブは中途半端に終わってしまう。再投入はリソースの無駄 • 実行中のジョブを監視して、必要があればプロキシ証明書を自動で更新する。→このサービス機能を追加した。 • デフォルトで7日間有効だが、この期間自体は更新可能。 • 例) 6日目に、あと3日ぐらい時間がほしい、と思ったら、期間を更新すればよい。 Gfarm meeting