高エネルギー物理学研究におけるグリッドの現状～ LHC ATLAS...

2004 3 8年月日74 @第回研究セミナー京都大学学術情報メディアセンター 1

高エネルギー物理学研究における

グリッドの現状～ LHC ATLAS 実験開始に向けて～

田中純一東京大学素粒子物理国際研究センター（ ICEP

P ）


内容グリッド高エネルギー物理学実験

Belle 実験 LHC ATLAS 実験

LHC Computing Grid Project NorduGrid GSI-enabled pftp : HPSS バンド幅テストまとめ


… グリッド The Grid: Blueprint for a New

Computing Infrastructure, in 1998 Ian Foster & Carl Kesselman “a hardware and software infras

tructure that provides dependable, consistent, pervasive and inexpensive access to high-end computational capabilities.”


グリッド技術グリッドとは ?

計算機を、情報コンセントに挿すだけで、いつでもどこでも必要な計算機リソースが取り出せる、というイメージ。

電力（ Power Grid ）からの発想。

From IBM

最近は、いろいろな“グリッド“があるが、高エネルギー物理学実験では、この意味に近い。


グリッドを利用するためには電力と同様に、

十分な設備

契約が必要

ネットワークの充実、実現のためのソフトの開発

（ミドルウェア）認証と許可


ネットワークインフラの進歩するス

ピード CPU 18 ヶ月で 2 倍 Storage 12 ヶ月で 2 倍 Network 9 ヶ月で 2 倍

分散した計算機を接続するというアイデアが現実的なものとなった。しかも、世界規模で！

100BaseTx は当たり前。GbE NIC は身近になった。

5 年で 100 倍


国内の学術ネットワークバックボー

ンはすでに１０ Gbps

主な大学・研究所は ~Gbps で接続されている。


国際ネットワーク

日本 NewYork

( 予定 )

欧州日本からアメリカを

経由して欧州へ： 10Gbps

NII( 国立情報学研究所 )


世界中のグリッドプロジェクト

グリッドといえば、予算が出た / 出るらしい。もらったからには、結果が必要。

いろいろなグリッドミドルウェアができた。

（高エネルギー物理学実験に関連するものの一部）


グリッドミドルウェアと Globus

グリッドミドルウェアグリッドを実現するための“ OS” のようなもの。多くの場合、 Globus ベース。

Globus グリッドのソフトを開発 / 構築するときに用いられるツールキット。

これですべてができるわけではない。あくまでもツールキット。

デファクトスタンダードになった。セキュリティを重視した構成になっている。 GT2.x と GT3.yのバージョンがある。

高エネルギー物理学実験の世界では、前者が主流。

Globus ≠ Grid


認証と許可の話グリッドの誤解の１つとして、“誰でも他人の計

算機リソースを勝手に使える”というものがある。

認証と許可の手続きが必要

ボランティアを行う技術ではない。（そういう使い方をしてもいいが）

グリッドの誤解の１つとして、“余剰計算機リソースを提供 / 利用する”というものがある。例 :SETI@homeただし、最近の動向としてはこれも“グリッド“になりつつある。


認証と許可の例日本 HepCA （日本の高エネの認証局 :仮称）欧州 HepCA （欧州の高エネの認証局 :仮称）

日本 HepCA

ユーザー A 計算機リソース B

欧州 HepCA

認証認証

使えるはずがない


認証と許可の例

日本 HepCA

ユーザー A 計算機リソース B

欧州 HepCA

認証認証

“ 欧州 HepCA を信頼するよ。”“ 日本 HepCA を信頼するよ。”

“ユーザー A を Unixユーザー guestとして許可を与えるよ。”

やっと使える！シングルサインオン

“ 欧州 HepCA を信頼するよ。”“ 日本 HepCA を信頼するよ。”


プロキシ証明書ユーザーは、 grid_proxy_init でグリッド環境にロ

グインする。このとき、ユーザー証明書からプロキシ証明書が生成さ

れる。 (/tmp にあることが多い。 ) グリッド環境のリソースを利用するときは、このプロキシ証明書を利用する。

プロキシ証明書は、連鎖して生成される。シングル・サインオンを可能に！

ユーザー証明書プロキシ証明書プロキシ証明書


高エネルギー物理学実験とは？

素粒子物理学素粒子を研究対象とし、

物質と力の根源を探求する学問例 ) なぜ質量があるのか？

必ず実験で検証する必要がある。その一つとして、加速器を用いた実験を行う。→粒子を高速に加速した後、衝突させることで物

理現象を発生させる。これを検出器で捕らえ、データにして保存する。これを解析することで、理論の検証を行う。


素粒子

影で覆われているものは、未発見。ヒッグス粒子の発見は非常に重要！超対称性粒子は、理論的な観点から予想されている。

標準理論


Belle 実験つくば市の高エネルギー加速器研究機構 (KE

K) にある加速器を用いた実験。

Belle検出器

世界最高のルミノシティー

1.1x1034cm-2s-1

B 中間子を生成する工場＝ B-factory衝突エネルギー 10.5GeV

蓄積したデータ（約 5 年）約 1PB のデータを保存。


ジュネーブ空港

LHC トンネル ( 一周 27km)（地下 ~100m ）

CERN

スイス

フランス

ジュラ山脈

Large Hadron Collider

ATLASCMS

Alice

LHCb


ATLAS 実験

•40MHzでビームが衝突•Raw data = 320Mbyte/sec (~1TB/hour)• 読み出しチャンネル = 1億 6千万

2007 年実験開始

22m

44m

衝突エネルギー 14TeV

ルミノシティー 1034cm-2s-1

これまでのもやもやを一気に振り払う実験


ATLAS 実験のアニメーション


LHC 4 実験ATLAS 、 CMS 、 Alice 、LHCｂ実験の合計 4 実験がある。

3.5PB/ 年のデータを保存して、解析する。

この見積もりは、若干古い。例えば、 ATLAS 実験は

100MB/ｓから300 ～ 400MB/s

へ上がっている。

←設計上は問題なし。


必要なリソースの例（概算） Super B ：次期 Belle 実験 ( 計画中 )

50000 GHz PenIII 10 PB

ATLAS 実験 (2007 年開始 ) 24000 GHz PenIII (=12M SI2000) 15 PB 実験開始時に

準備しなければならないリソース

4 実験の 1 つ→ 4 倍ぐらいは必要


CERN IT （その１）

1445m2


CERN IT （その２）


実験データの流れ（その１） 1秒間に 40M回の衝突が起こる。

衝突 1 回分のデータサイズは約 1MB 。

全部、保存するなら 40TB/s のデータがやってくる。

技術的に無理。そもそも、すべてが興味

ある物理事象ではない。多くはゴミ事象

保存する前に、必要かどうかを高速に判断する。

2

1

最終的に、毎秒 100MB のデータが保存される。

年間、約 107秒稼動するので、 1PB/year のデータになる。

3

CMS 実験


グリッド

ATLAS 実験のデータの流れ（その２）

100MB/s で保存されたデータRaw Data （ 1MB/event ）

物理解析に使える形式までプロセスが必要。

=

物理解析

Reconstruction （再構成）する。（トラックやジェットを作る。）

Event Summary Data（ ESD, 100kB/event のデー

タ）新しい検出器情報を使って、トラックやジェットの情報を更

新。物理研究ごとに AODを作成。

Analysis Object Data（ AOD, 10kB/event のデータ）

点の情報から、線や塊（粒子）を見つける。

RC(ReginalCenter)

CERN

主 CE


Event Display

点の情報から、線や塊（粒子）を見つける。


計算機資源をどう使うか？大きく分けて、 2種類のジョブがある。

データ生成のためのジョブ実験： ESDや AODの生成シミュレーションデータの生成一つのジョブで、数 GB のファイルを一つ作る。数 GB ファイル = 数 100~数 105 のイベントの集まり。

物理解析ジョブ生成されたデータを解析する。一つのジョブで、数 100 ファイルを使うことが多い。結果は、数個のファイル。（ヒストグラムやログ・

ファイル）

～我々のジョブの特徴～


“ データ生成“ジョブの特徴一般に、イベント単位（ ATLAS 実験が例外かもしれないが）

1 ファイルに数 100~数 105 イベント保存されていても、

必ず、イベントごとに区別されている。 1 イベントに 1 日、 1時間もかかることはなく、長くて

も 5~10 分ぐらい。（数時間かかる実験もあるが。）→1 イベントを細分化して、複数の CPU を利用する必要はない。

→イベントで分ける並列化処理は歓迎。シミュレーションのときは、乱数の取り扱いに注意す

る。並列化しても、最終的に、 1 ファイルになれば OK 。

2GB リミットの壁があるが、これは改善されるはず。


“ 物理解析”ジョブの特徴イベント単位で、解析する。 1 つのジョブで、たくさんのファイルを利用する。

数 100 ファイルは当たり前。結果は、ヒストグラム等に集約される必要がある。

グリッド環境で、“物理解析”をどう行うか？イベントで分ける並列処理を行う。

ファイルの移動等問題の回避。並列処理した結果を集約する。


ATLAS 実験におけるグリッド環境

グリッド技術を用いて、各地の地域解析センター (RC)を接続しリソースを共有する。

これだけの規模で行うのは、恐らく、初めての試み。


ATLAS 実験のグリッドミドルウェア

2004 年ー 2005 年に行われる運用テスト 3 つのグリッドミドルウェアの採用

1 つに統一することはできなかった。

東大 ICEPP が採用するミドルウェア LCG －ホスト研究所 CERN が採用する（ NorduGrid の導入試験の経験はある。）

LCG （欧州発）Grid3 （米国発）NorduGrid （北欧発）

主目的は、“データ生成”


ATLAS 実験のグリッドミドルウェア

3 つをどう扱うか？（現段階で分かっていること）データ生成のためのジョブの投入

それぞれの言語で、それぞれ独立に。 RSL ： Resource Specification Language JDL ： Job Description Language

生成されたデータの取り扱い（つまり、物理解析）

各 SE のデータに、相互にアクセスできる（予定）←物理解析@グリッドに関して、議論 / 開発中。


計算機環境@ICEPP

10GbE

PenIII1.4GHz


計算機環境@ICEPP

Xeon 2.8GHzLTO2


LHC Computing Grid Project

略称 = LCG LHC 4 実験共同で Grid を配備する計画

フェーズ 1=研究開発 2002 年～ 2005 年 Grid ミドルウエア仕様決定 2005 年 LHC Global Grid Technical Design Report

フェーズ 2=配備 2006 年～ LHC 実験データ解析プラットフォーム

高エネルギー物理学実験のための“グリッド”標準になる可能性がある。


LCG とは？グリッド環境を構築することが仕事。

ミドルウェアは既存のものから採用して、

どれが優れているかを判断することが仕事。 Deployment not Development

LCG バージョン 1 の構成 EDT 1.1 EDG 2.0 VDT 1.1.8 Redhat 7.3

EU と US の寄せ集め


ノードの構成各サイトにすべて必要というわけではないが、以下のような役割を持ったノードを準備する。

RBLCFGMDSBDIIRLSCESEWN

PROXVOUI

MONICNM

VOMS

現状では名前だけ


LCG の現状 @ICEPP LGC バージョン 1 で稼動中

CE 、 SE 、 UI 、WN の最小構成でスタート。 LCFG = Local Configuration system

OS を含めて、各ノードのインストール、設定を自動的に行う。

各ノードの設定変更もここで行う。設定ファイルの変更 XML に変換

ノードに変更があったことを通知ノードは http 経由で XML ファイルを取得設定変更

このシステムに慣れる必要がある。ノード数を増やすために環境構築の R&Dを行ってい

る。 WN を広域ネットワークに置かないように。


稼動状況@ICEPP

現在、ローカルネットワークに新しいノードを追加中追加テストは完了


グリッドモニター常時、各サイトをモニターするための研究開発


グリッドモニター

これらは、 http://www.grid-support.ac.uk/GOC/ からアクセス可能


情報管理各ノードの状況を把握することは非常に重要なことである。

どこにジョブを投げる等を的確に判断するため。

Globus のMDS （Monitoring and Discovery Service ）とBerkeley DB Index Information で構成

GRISLocal GIIS Region GIIS BDII

冗長性を確保


ジョブの流れRLS

BDII

RB

CE+WN SE

UIb: ジョブを投げるc:調べるd:サイトに適したジョブの形にする。e: ジョブを CE に受け渡す。f: 必要なら SE を使ってジョブを実行する。i: ジョブ終了。結果を RB に戻す。j:ユーザーに結果を戻す。


データの管理

RLS(= Replica Location Service) がサービスを提供する。冗長性やファイルアクセスの負荷を考えると、レプリカを作る必要がある。 DMS(=Data Management Service) を使ってレプリカ作成を行うことができる。

ファイルの管理－２つのカタログ GUID(=Grid Universal/Unique ID) でファイルを一意に管理。物理的なファイルとの対応： LRC(=Local Replica Catalogue)

レプリカがあるので、物理的には複数あってよい。メタデータとの対応： RMC(=Replica Metadata Catalogue)

抽象的な名前も複数あってよい。


長時間ジョブとプロキシ証明書問題

GSI ではプロキシの概念 ( プロキシ証明書 ) を取り入れて、シングル・サインオンを実現している。

証明書が切れたら、その時点で実行されているジョブは中途半端に終わってしまう。再投入はリソースの無駄

実行中のジョブを監視して、必要があればプロキシ証明書を自動で更新する。→このサービス機能を追加した。

デフォルトで 7 日間有効だが、この期間自体は更新可能。例 ) 6 日目に、あと 3 日ぐらい時間がほしい、と思ったら、期間を更新すればよい。


グリッド環境上の資源グリッドに提供した資源は、常に利用可能な状態。→理想はこれ！しかし、… 計算機が多いため、故障も多い。

常時稼動のためには、重要なノードは多重化。データも多重化。計算中だったジョブは、自動再投入。

各サイトの管理者は、メンテナンスを行うために、容易に自前のリソースをグリッドから切り離せる。ダイナミックにリソースの増減が可能。ユーザーレベルでは、“お知らせ不要“が理想。→ ”ユーザーは気づかない。”が理想。


NorduGrid

NorduGrid とは ? 北欧 4 国（デンマーク、ノルウェー、スウェーデン、フィンランド）からなるグループが開発したミドルウェア。

環境構築は比較的容易。バージョン 0.3.x

近々 0.4 へ。


北欧との接続テスト（ 2002-2003 ）

距離的には十分離れてる地域間の接続テスト！ ICEPP に 1台、 KEK( つくば市 ) に 1台の計算

機を設置。すべて広域ネットワークで接続。


北欧からのジョブサブミッション

時差 9時間

北欧の CA で認証を受け、ICEPP の計算機で許可を受けたユーザー


NorduGrid の特徴 PBS が稼動している既存のクラスターに、一枚皮を被せるイメージ。どこにでも意識せずにジョブが投げれるようになる。バージョン 0.4 では、 SGE 、 Condor等もサポート。

パーソナル RB “ どこのサイトで実行するか？”の判断は、ジョブを投げる時点に行われる。そのときの最適な場所。

大元締めがいるわけではないので、他が空いても自動的にジョブは移動しない。

サポートが素晴らしい。（ML の活用）


GSI-enabled pftp : HPSS 既存のアプリケーションで、 GSI 認証を行うことが

できれば、それなりに便利。 GSI = Grid Security Infrastructure GSI-enabled OpenSSH などもある。

KEK( つくば市 ) には、 HPSS が稼動中。 High Performance Storage System

通常は、ケルベロス認証を使う。容量 120TB これを SE のひとつとして、利用できれば便利。→ pftp を GSI 認証できるようにする。

すでにそれを行っているグループがあったので、それを使ってテスト。


1Gbps

100Mbps

ICEPP KEK

38CPUs6CPUs

HPSS 120TB

NorduGrid - grid-manager - gridftp-serverGlobus-mdsGlobus-replicaPBS server

NorduGrid - grid-manager - gridftp-serverGlobus-mdsPBS server

PBS clientsPBS clients

GSI pftp server

~ 60km0.2TBSECE

CECE

SE

User PCs

KEK-ICEPP 専用線

1Gbps のプロジェクト専用線

2003.3


GSI-pftp server

0 2 4 6 8 100

20

40

60

80 dsk mver(!=pftpd) to clnt; pftp - pftpd dsk mver(=pftpd) to clnt; GSIftp-GSIpftpd dsk mver(!=pftpd) to clnt; GSIftp -GSIpftpd

# of file transfer in parallelAggregate Transfer speed (M

B/s)

Performance自体はDisk スピードで飽和→ 今後の課題

GSI-pftpd では、データ転送の経路に問題。→ サーバーを必ず通過。

実用化に向けては、これらを改善する必要がある。


CERN-ICEPP ネットワーク ICEPP とホスト研究所である CERN間で、高速

なファイル転送を実現することは重要。バンド幅

2点間の間にある経路（のほとんど）は、“ >1Gbps” あった。ただし、専用線ではない。

“ほとんど”ボトルネックは、両終端の Firewall等。 ICEPP も CERN も現状では 1Gbps 。（特別交渉を除く）

しかも、 RTT は約 300ms もある。単純に計算すると、 37MB の TCP buffer size のシン

グルコネクションで１ Gbps が実現できる。実際は……


バンド幅測定 Iperf というベンチマー

ク用ソフトを利用した。メモリからメモリへの転送速度を測定。

カーネル 2.6 を利用。 2.4 では、コネクション数、 TCP バッファサイズを増やしても、 100Mbps 前後でリミット。

TCP の実装が改善されている ? （未確認）

スケジューリングは改善。


バンド幅測定の結果 5 分平均で、 88.4MB/s(~700Mbps) を達成。

TCP バッファ 4MB 、コネクション数 28


TCP のデータ転送… RTT が 300ms で、しかも、汎用ラインを利用する。

TCP buffer size の変更は OK 。カーネル・パラメータの変更等は OK 。

MTU の変更は、…非現実。（個人的な意見…）これを変更して、結果を出しているものが多いが、

実用的ではない (?) 。“Disk から Disk へ“の転送速度が >1Gbps を実現できる解を見つけ出す必要がある。

UDP を利用してデータを転送する。今後、注目されるはず。ソフト・ API

Tsunami Sabul


まとめ高エネルギー物理学実験

10万 GHｚ（ PenIII ）以上の CPUパワーが必要。年間数ペタバイトのデータを取り扱う必要性。

実験データだけでなく、シミュレーションデータも。

グリッドを世界規模で実用化！ 2007 年までには、どうにかしたい / する。東大 ICEPP も、その一部を担うために R&Dを継続。


おしまい

Path difference

pftp - pftpd

Gridftp – GSI-pftpd

Tape mover

Tape mover

Disk moverpftp Server

Disk mover

CE(pftp client)

x3

x3

Tape mover

Tape mover

Disk moverpftp Server

Disk mover

CE(gridftp client)

x3

x3

高エネルギー物理学研究におけるグリッドの現状～ LHC ATLAS...

Documents

Transcript of 高エネルギー物理学研究におけるグリッドの現状～ LHC ATLAS...

高エネルギー物理学研究における グリッドの現状 ～ LHC ATLAS...

Documents

Transcript of 高エネルギー物理学研究における グリッドの現状 ～ LHC ATLAS...

高エネルギー物理学研究におけるグリッドの現状～ LHC ATLAS...

Transcript of 高エネルギー物理学研究におけるグリッドの現状～ LHC ATLAS...