LCG@ICEPP… 田中純一 ICEPP Gfarm meeting 2004年3月18日 1 内容 LCG ATLAS実験のグリッド 実験データとジョブ Gfarm meeting 2004年3月18日 2 LHC Computing Grid Project http://lcg.web.cern.ch 略称 = LCG LHC 4実験共同でGridを配備する計画 フェーズ1=研究開発 フェーズ2=配備 2002年～2005年 Gridミドルウエア仕様決定 2005年LHC Global Grid Technical Design Report 2006年～ LHC実験データ解析プラットフォーム 高エネルギー物理学実験のための“グリッド”標準に なる可能性がある。 Gfarm meeting 2004年3月18日 3 LHC 4実験 ATLAS、CMS、Alice、LHCｂ 実験の合計4実験がある。 3.5PB/年のデータを 保存して、解析する。 この見積もりは、若干古い。 例えば、ATLAS実験は 100MB/ｓから 300～400MB/sへ 上がっている。 10~15PB/年 Gfarm meeting 2004年3月18日 4 国際ネットワーク NII(国立情報学研究所) (予定) NewYork 日本 欧州 日本からアメリカを 経由して欧州へ：10Gbps Gfarm meeting 2004年3月18日 5 CERN IT （その１） 1445m2 Gfarm meeting 2004年3月18日 6 CERN IT （その２） Gfarm meeting 2004年3月18日 7 LCGとは？ グリッド環境を構築することが仕事。 ミドルウェアは既存のものから採用して、 どれが優れているかを判断することが仕事。 Deployment not Development LCGバージョン1の構成 EDT 1.1 EDG 2.0 VDT 1.1.8 Redhat 7.3 EUとUSの寄せ集め Gfarm meeting 2004年3月18日 8 LCGのバージョン LCG0 ： 2003年4月～ LCG1 ： 2003年7月～ ICEPP：インストールしたが、すでに停止。 ICEPPで稼動中 LCG2 ： 2004年2月～ ICEPPではこれから。 10サイト程度で稼動中 データ生成・保存のために利用中 （Alice実験） そのため、LCGチームは非常に忙しい!! 10サイト以外は、自力でインストール LCGチームは、それどころではない。。。 Gfarm meeting 2004年3月18日 9 ノードの構成 各サイトにすべて必要というわけではないが、以下のような 役割を持ったノードを準備する。 MON IC NM VOMS RB LCFG MDS BDII RLS CE SE WN PROX VO UI 現状では 名前だけ @LCG1 Gfarm meeting 2004年3月18日 10 LCGの現状@ICEPP LGCバージョン1で稼動中 CE、SE、UI、WNの最小構成でスタート。 LCFG = Local Configuration system OSを含めて、各ノードのインストール、設定を自動的に行う。 各ノードの設定変更もここで行う。 設定ファイルの変更 XMLに変換 ノードに変更があったことを通知 ノードはhttp経由でXMLファイルを取得 設定変更 このシステムに慣れる必要がある。 LCGバージョン2は、これから。 もちろん、LCFGに100%依存しなくてもよい。 Gfarm meeting 2004年3月18日 11 稼動状況@ICEPP Gfarm meeting 2004年3月18日 12 計算機環境@ICEPP PenIII 1.4GHz 10GbE Gfarm meeting 2004年3月18日 13 計算機環境@ICEPP LTO2 Gfarm meeting Xeon 2.8GHz 2004年3月18日 14 グリッドモニター Gfarm meeting 2004年3月18日 15 グリッドモニター これらは、http://www.grid-support.ac.uk/GOC/ からアクセス可能 Gfarm meeting 2004年3月18日 16 ATLAS実験のグリッドのお話 ～2004年の予定～ Gfarm meeting 2004年3月18日 17 ATLAS実験のグリッドミドルウェア 2004年ー2005年に行われる運用テスト 主目的は、 “データ生成” 3つのグリッドミドルウェアの採用 1つに統一することはできなかった。 LCG （欧州発） Grid3 （米国発） NorduGrid （北欧発） ICEPPが採用するミドルウェア LCG － ホスト研究所CERNが採用する Gfarm meeting 2004年3月18日 18 ATLAS実験のグリッドミドルウェア 3つをどう扱うか？ （現段階で分かっていること） データ生成のためのジョブの投入 それぞれの言語で、それぞれ独立に。 RSL：Resource Specification Language JDL：Job Description Language 生成されたデータの取り扱い（つまり、物理解析） 各SEのデータに、相互にアクセスできる（予定） ←物理解析@グリッドに関して、議論/開発中。 Gfarm meeting 2004年3月18日 19 実験データとジョブのお話 ～高エネルギー業界が必要としていること？～ Gfarm meeting 2004年3月18日 20 実験データの流れ（その１） 1 CMS実験 1秒間に40M回の衝突が起 こる。 衝突1回分のデータサイズは 約1MB。 全部、保存するなら40TB/s のデータがやってくる。 3 最終的に、毎秒 100MBのデータが 保存される。 年間、約107秒稼動 するので、1PB/year のデータになる。 2 Gfarm meeting 技術的に無理。 そもそも、すべてが興味あ る物理事象ではない。 多くはゴミ事象 保存する前に、必要かど うかを高速に判断する。 2004年3月18日 21 ATLAS実験のデータの流れ（その ２） 物理解析に使える形式までプロセスが必要。 = 100MB/sで保存されたデータ Raw Data（1MB/event） 主CE 点の情報から、 線や塊（粒子）を 見つける。 Reconstruction（再構成）する。（トラックやジェットを作る。） CERN Event Summary Data （ESD, 100kB/eventのデータ） 新しい検出器情報を使って、トラックやジェットの情報を更新。 物理研究ごとにAODを作成。 グリッド Analysis Object Data （AOD, 10kB/eventのデータ） RC (Reginal Center) 物理解析 Gfarm meeting 2004年3月18日 22 計算機資源をどう使うか？ ～我々のジョブの特徴～ 大きく分けて、2種類のジョブがある。 データ生成のためのジョブ 実験：ESDやAODの生成 シミュレーションデータの生成 一つのジョブで、数GBのファイルを一つ作る。 数GBファイル = 数100~数105のイベントの集まり。 物理解析ジョブ 生成されたデータを解析する。 一つのジョブで、数100ファイルを使うことが多い。 結果は、数個のファイル。（ヒストグラムやログ・ファイル） Gfarm meeting 2004年3月18日 23 “データ生成“ジョブの特徴 １ 一般に、イベント単位 （ATLAS実験が例外かもしれないが） 1ファイルに数100~数105イベント保存されていても、 必ず、イベントごとに区別されている。 1イベントに1日、1時間もかかることはなく、長くても 5~10分ぐらい。（数時間かかる実験もあるが。） →1イベントを細分化して、 複数のCPUを利用する必要はない。 →イベントで分ける並列化処理は歓迎。 シミュレーションのときは、乱数の取り扱いに注意する。 並列化しても、最終的に、1ファイルになればOK。 2GBリミットの壁があるが、これは改善されるはず。(ROOT v4) Gfarm meeting 2004年3月18日 24 “データ生成“ジョブの特徴 ２ グリッド環境にインストールされたソフトを起動する。 Input Fileはパラメータ等の設定のみ、 つまり、サイズは小さい。 Output Fileのサイズは、それなりに大きい。 つまり、数GB～数10GB Output FileはSEに転送されて、皆様に利用してもらう。 この転送は“必要なこと”。 バッチジョブの特徴を持つグリッドで十分 現行のLCGで十分 Gfarm meeting 2004年3月18日 25 “物理解析”ジョブの特徴 １ イベント単位で、解析する。 1つのジョブで、たくさんのファイルを利用する。 数100ファイルは当たり前。 結果は、ヒストグラム等に集約される必要がある。 グリッド環境にインストールされたソフトを起動する。 Input Fileが非常に大きい。 数GB x 数100ファイル Output Fileは小さい。 Gfarm meeting 2004年3月18日 26 “物理解析”ジョブの特徴 ２ Input Fileのためのファイル転送は無駄。 そもそも、一般にCEに置けない！ 解析ソフトからは、必要なデータファイルは見えるべき。 NFS：SEのDiskをCEにマウント 他のファイルシステム？AFS、GSIFS？ “すべてのCE”から“すべてのSEのデータ”が見えることは 困難？ ジョブを分離することで、 データの見えるCEで解析して、結果を集計する。 ここの解は、はっきりと見えていない！ Gfarm meeting 2004年3月18日 27 まとめ LCG Grid@ATLAS LCG、Grid3、NorduGridを利用する。 ICEPPはLCGを採用。 5月ごろから、データ生成開始。 “物理解析“へのグリッド利用方法 今後は、LCG2の利用が中心となる。 Alice実験がデータ生成を行っている。 ぼんやりとした解のみ 我々は、LCGを無視することはできない。 共存のみ。 Gfarm meeting 2004年3月18日 28 おしまい Gfarm meeting 2004年3月18日 29 バックアップ LCG１でのお話 LCG2では情報管理系の 構造が変化しているかも？ Gfarm meeting 2004年3月18日 30 情報管理 各ノードの状況を把握することは非常に重要なことである。 どこにジョブを投げる等を的確に判断するため。 GRIS Local GIIS Region GIIS BDII GlobusのMDS （Monitoring and Discovery Service）と Berkeley DB Index Informationで構成 冗長性を確保 Gfarm meeting 2004年3月18日 31 ジョブの流れ RB b:ジョブを投げる UI c:調べる d:サイトに適した ジョブの形にする。 e:ジョブをCEに 受け渡す。 f:必要ならSEを 使ってジョブを実行する。 i:ジョブ終了。 結果をRBに戻す。 j:ユーザーに 結果を戻す。 RLS BDII CE+WN Gfarm meeting SE 2004年3月18日 32 データの管理 RLS(= Replica Location Service)がサービスを提供する。 冗長性やファイルアクセスの負荷を考えると、 レプリカを作る必要がある。 DMS(=Data Management Service)を使って レプリカ作成を行うことができる。 ファイルの管理 －２つのカタログ GUID(=Grid Universal/Unique ID)でファイルを一意に管理。 物理的なファイルとの対応：LRC(=Local Replica Catalogue) レプリカがあるので、物理的には複数あってよい。 メタデータとの対応：RMC(=Replica Metadata Catalogue) 抽象的な名前も複数あってよい。 Gfarm meeting 2004年3月18日 33 長時間ジョブとプロキシ証明書問題 GSIではプロキシの概念(プロキシ証明書)を取り入れて、シングル・サ インオンを実現している。 証明書が切れたら、その時点で実行されているジョブは中途半端に 終わってしまう。 再投入はリソースの無駄 実行中のジョブを監視して、必要があればプロキシ証明書を自動で 更新する。→このサービス機能を追加した。 デフォルトで7日間有効だが、この期間自体は更新可能。 例) 6日目に、あと3日ぐらい時間がほしい、と思ったら、期間を更新すればよい。 Gfarm meeting 2004年3月18日 34
© Copyright 2024 ExpyDoc
