2009 年 11 月
サイエンティフィック・システム研究会

Grid Computing 検討 WG

1. はじめに
1.1.
1.2.

1

設立時の Grid Computing 検討 WG 活動内容･････････････････････････････････････････････････････････････････････････････････････････････････････････････････････････････････････････････････････････････
活動経緯

2. WG 活動経緯
2.1.
2.2.

活動メンバー
WG 活動経過2････････････････････････････････････････････････････････････････････････････････････････････････････････････････････････････････････････････････････････････････････････････････････････････････････････････････････

3. Grid Computing 技術動向調査
3.1.
3.2.
3.3.
3.4.

マシンの仮想化と Grid との関連－OGF や DMTF での標準化動向－･･････
データグリッド－RNS と Gfarm v2 ファイルシステム－･･･････････････････････････････････････････････････････････････････････････････････････････････････････
天文学研究におけるデータグリッド･･････････････････････････････････････････････････････････････････････････････････
クラウド・コンピューティング

4. NAREGI 関係報告
4.1.
4.2.
4.3.

NAREGI の現状と今後･･･････････････････････････････････････････････････････････････････････････････････････････････････････････････････････････････････････････････････････････
NAREGI ミドルウェアの導入と運用･･･････････････････
研究コミュニティ形成のための資源連携技術に関する研究報告

5. NAREGI など Grid 適用実験・運用
5.1.
5.2.
5.3.
5.4.
5.5.
5.6.
4.5.

NAREGI PKI をめぐる周辺－連携実証実験での事例－･･･････････････････････････････
高エネルギー加速器研究機構におけるグリッド配備の現状 ･･･････････････････････････････････････････････････････････････････････････････
NAREGI ミドルウェアによる 6 拠点連携実験････････････････････････････････････････････････････････････････････････････････････････････････
九州大学導入報告････････････････････････････････････････････････････････････････････････････････････････････
名古屋大学導入事例･･････････････････････････
京都大学学術情報メディアセンターのグリッドへの取り組み･･･････････････････････････････････････････････
９大学情報基盤センターへのグリッド配備・運用

6. おわりに

1
1

2
2

4
4
10
15
19

25
25
29
40

45
45
48
55
61
67
72
73

77

1. はじめにSS 研において Grid に関する WG は初代 Grid Computing WG(2002～2003 年度)から始まり、
Grid Computing 2004 WG(2004~2007 年)まで WG 活動が継続されました。
Grid 関係としては 3 回目となる「Grid Computing 検討 WG」は 2007 年度にスタートしました。
以下に当初の活動内容を示します。

1.1. 設立時の Grid Computing 検討 WG 活動内容
高速ネットワークを介して多数の分散したコンピュータを連携させ、計算資源，データ，人的資源の共有を図り、資源の有効利用を図る Grid Computing が注目を集めてきた。国内でもすでにNAREGI，ITBL，VizGrid 等のプロジェクトによって、Grid Computing の実用の時代に移っており、
ますますその関心が高まっている。
新 WG においては初代 Grid ComputingWG(2002～2003 年度)の初心に戻り、まずは広く Grid
技術の動向調査と情報共有を行う。また、前 WG での試行に続いて、 NAREGI などの Grid
Middleware を実際に動作させ、その経験に基づいて Grid 技術のあり方を検討し、センター等における Grid のメリットについて検討する。
これらにより、会員間での Grid 技術活用の目的を明確化し、問題点があればその解決を図る。
1. Grid Computing 技術の動向調査と WG 内での情報共有 (セミナー開催)
2. Grid Middleware（NAREGI など）による技術検討 および センター等における Grid 技術導入メリットの検討 など

1.2. 活動経緯
これらにより、会員間での Grid 技術活用の目的を明確化し、問題点があればその解決を図る。
実際に行った活動内容は以下のとおりです。
Grid に関する情報共有活動では、仮想化、データグリッド、クラウド・コンピューティング、天文学におけるデータグリッド、会員期間の Grid 適用事例などの紹介を行い、会員間での情報の共有を図りました。Grid ミドルウェアは、参加委員の意向により、NAREGI に絞るものとして、NAREGI プロジェ
クトの紹介により会員間の常用共有を図りました。また最新の NAREGI ミドルウェアについての技
術検討、会員による V1.0、V1.1 の導入状況報告および意見交換を行いました。その際、一部の会員が参加している 7 センター間グリッド研究会での活動と本 WG 活動との足並みを揃えることにしました。この結果、より充実した成果を求めることができました。この活動の同期化によって、予定していた 2 ヵ年(2007 年 8 月～2009 年 8 月)の活動機関を 2 ヶ月延長しました。

-1-

2. WG 活動経緯
2.1. 活動メンバー
担当
担当幹事
担当幹事
まとめ役

まとめ役

話題提供

氏名
岩宮 敏幸
水本 好彦
内田 啓一郎
井町 智彦
南里 豪志
義久 智樹
金澤 正憲
佐々木 節
宇佐見 仁英
白崎 祐治
津田 知子
近堂 徹
黒川 原佳
藤崎 正英
井口 裕次
楢橋 幹一郎
畑瀬 圭太
北村 正和
石原 康秀
荒井 雄二
坂口 吉生
岸本 光弘
友石 正彦
建部 修見
東田 学
青柳 睦
槌本 裕一
三浦 謙一
合田 憲人

2007 2008 2009
機関名
宇宙航空研究開発機構○○
国立天文台天文データセンター○
神奈川大学メディア教育・情報システムセンター○○○
金沢大学総合メディア基盤センター○○○
九州大学情報基盤研究開発センター○○○
京都大学学術情報メディアセンター○
京都大学学術情報メディアセンター○
高エネルギー加速器研究機構計算科学センター○○○
国立情報学研究所リサーチグリッド研究開発センター○○○
国立天文台天文データセンター○○○
名古屋大学情報基盤センター○○○
広島大学情報メディア教育研究センター○○○
理化学研究所○○○
富士通 ＴＣソリューション事業本部○○○
富士通 次世代テクニカルコンピューティング開発本部○○
富士通 文教ソリューション事業本部○○○
富士通 文教ソリューション事業本部○○○
富士通 文教ソリューション事業本部○○○
富士通 ＴＣソリューション事業本部○○○
富士通 ＴＣソリューション事業本部○○○
富士通 ＴＣソリューション事業本部○○○
富士通研究所 ｸﾗｳﾄﾞｺﾝﾋﾟｭｰﾃｨﾝｸﾞ研究センター○○○
国立情報学研究所リサーチグリッド研究開発センター
②
筑波大学
③
大阪大学
③
九州大学情報基盤研究開発センター④
富士通研究所 ｸﾗｳﾄﾞｺﾝﾋﾟｭｰﾃｨﾝｸﾞ研究センター④
国立情報学研究所リサーチグリッド研究開発センター②⑤⑥
国立情報学研究所リサーチグリッド研究開発センター⑥○付き数字は出席会合の回数

2.2. WG 活動経過
各開催 WG での概要は、表 2-1 に示す。
表 2-1 WG 会合の概要
日 時
場 所
活動内容
2007 年 10 月 31 日(水)・ WG 活動内容の検討
第1回
富士通本社
14:30～17:30
・各種話題提供・ マシンの仮想化と Grid との関連
2008 年 2 月 22 日(金)
第2回
富士通本社
・ NAREGI の現状と今後
14:30～17:45
・ NAREGI の認証、PKI の話題
・成果報告書における著作物等使用許諾について

-2-

第3回

2008 年 6 月 9 日(月)富士通本社
14:30～17:30

第4回

2008 年 9 月 18 日(木)富士通本社
14:30～17:40

第5回

2009 年 1 月 21 日(水)富士通本社
14:30～17:30

第6回

2007 年 8 月 18 日(火)富士通本社
14:00～17:30

・2008 年度の活動について
・各種話題提供・ 高エネルギー分野での Grid 適用事例
・ データグリッド最新の話題
・ NAREGI ミドルウェアによる 6 拠点連携実験の話題
・成果報告書の方向性について
・各種話題提供・ クラウド・コンピューティング
・ 天文学研究におけるデータグリッド
・ NAREGI に関する話題提供
・成果報告書のまとめ方
・各種話題提供・ NAREGI の状況報告(九大)・ NAREGI の状況報告(名大)・ 研究コミュニティ形成のための資源連携技術に関する研究報告
・成果報告書のまとめ方
・各種話題提供・ NAREGI の状況報告(九大)・ NAREGI の状況報告(名大)・ NAREGI の今後・成果報告書のまとめ方-3-

3. Grid Computing 技術動向調査
3.1. マシンの仮想化と Grid との関連－OGF や DMTF での標準化動向－
報告：富士通研究所 クラウドコンピューティング研究センター）岸本光弘
マシンの仮想化技術が成熟し、性能オーバヘッドや機能制限が減少するにつれ、マシン仮想化のユーザが増加しつつある。本報告は、マシン仮想化技術とグリッド技術の関係の整理と、関連する標準化団体の最新動向を説明する。

3.1.1. グリットと仮想技術
エンタプライズ IT アーキテクチャは、良く管理された集中型システムから、価格性能比の良い分散型システムに移行してきたが、硬直したサイロが多数出現してしまった。そこで、サイロの数を削減する「サーバ統合」が登場し普及してきた。今後は、全体管理が可能な統合型システムへ展開してゆくと考える。
統合型システムとは、ライフサイクルの異なる業務アプリケーションと IT 基盤を分離し、両者を動的かつ柔軟に組み合
わせ全体を最適化するもので、自律・仮想技術とグリッドインフラにより実現
される。

応用
システム

グリッド
技術

WEB
サービス

計算グリッドデータグリッド

データセンタグリッド

センサグリッド

適用型ジョブ制御

コラボレーション

アプリ管理

GRIDセキュリティ

仮想組織

ジョブ実行管理

データ管理

アプリ仮想化

デプロイ機能ロギング

ジョブ仮想化

分散管理

従量制課金

データ仮想化

CIMプロファイル

情報サービスコンテナ仮想化

WS-Addressing

Notification

サーバ仮想化・VM 

CIM情報モデル

WS-Security

ネットワーク仮想化

HTTP(S)/SOAP

WSDL

ストレージ仮想化

仮想化技術
図 3-1：グリッドと仮想化の要素技術

3.1.2. グリッドでの仮想化技術の活用
GT4 virtual Workplaces は、Globus incubation project のひとつであり、最新リリースは v1.3.1(2008.2.14)である。ユーザの作業環境提供に仮想マシンを活用することで、ユーザが所望の OS,
ソフトスタック, アクセスポリシを備えた実行環境を作成可能になる。ユーザは、VM イメージの実行
開始・停止・再開・マイグレーションを制御でき、資源割り当て量を厳密に配分するとともに、ユーザ間の完全な分離を可能にしている。

3.1.3. OGF でのマシン仮想化の標準化
OGF は、仮想サーバに関する標準化活動を行うため、Grid-VirtWG を OGF19(2007/1)でトップダウンに創設した。しかし、標準仕様の開発を目指しているわけではないし、まだ、具体的な活動も始
まっていない。

3.1.4. DMTF でのマシン仮想化の標準化
DMTF はシステム管理の標準仕様を開発する標準化団体で、対象システムの情報モデル
Common Information Model (CIM)や、管理プロトコル (Web Based Enterprise Management )勧告を公表している。
DMTF の System Virtualization WG は、これまではクラスタシステムや、LPAR の CIM モデルを検討していたが、マシン仮想化以前の活動は、あまり活発ではなかった。しかし、マシン仮想化に関しては多数の有力ベンダが活動に参加しており、仮想システム向けの CIM 拡張プロファイルと、仮想マシンの標準パッケージフォーマット(Open virtualization Format)を開発し公開した。

3.1.5. まとめ
グリッドと仮想技術は、相互補完の関係にあると考える。特に、仮想化技術を使うことで、グリッド-4-

の適用範囲が広がり有用性が大幅に増す(Amazon EC2 や Globus Virtual Workspaces が好例)。
OGF の GridVirt-WG は、グリッドユースケースを議論しているが低調である。一方、DMTF のSVPC-WG は、仮想サーバの標準仕様を作成しており活発である。
添付資料 ・・・第 2 回会合（2008 年 2 月 22 日）報告

アウトライン
Grid Computing 検討WG 第2回会合

グリッドと仮想化技術
グリッドでの仮想化技術の活用
OGFでのマシン仮想化の標準化

マシンの仮想化とグリッドとの関連～OGFやDMTFでの標準化動向を中心に～

DMTFでのマシン仮想化の標準化
まとめ
岸本光弘
（株）富士通研究所
2008.2.22
1

エンタプライズITアーキテクチャの発展
AP
AP AP

AP

WM

WM WM

WM

メインフレーム

HW HW

集中 型システム

分散型 システ ム

…

HW

AP
WM

AP

仮想とは（一般的定義）ITリソースの個々の違いを隠蔽し、利用・管理が容易な論理的なリソースに
する技術

… WM

グリッドインフラ

HW … HW
統合型システム

AP: 業務アプリケーション
WM: アプリ実行基盤
HW: ハードウェア（ITリソース）律•良く管理された集中型システムから、価格性能比の良い分散型システムに移行。しかし、硬直したサイロが多数出現

自全体自動運用管理が可能な
統合型システム

自律とはシステム自身が状態や障害などを把握して、自己管理する技術

仮想

AP AP … AP

グリッド技術と仮想化技術

グリッド•サイロの数を削減する「サーバ統合」が普及

グリッドとはネットワークで接続された複数のITリソースを効率よく利用する技術•ライフサイクルの異なる業務アプリケーションとIT基盤を分離し、両者を動的かつ柔軟に組み合わせ全体を最適化する•自律・仮想技術とグリッドインフラにより、全体管理が可能な統合型システムへ展開

Ian Foster, Describing the Elephant: The
Different Faces of IT as Service, ACM
Queue vol. 3, no. 6 - July/August 2005

仮想化の定義グリッドと仮想化の要素技術

 ITリソースの個々の違いを隠蔽し、利用・管理が容易な論理的なリソースにする 単一の物理リソース（サーバ、OS、アプリケーション、補助記憶装
置など）を複数の論理リソースに見せる 複数の物理リソース（複数の補助記憶装置群やサーバ群）を単一の論理リソースに見せる 単一の物理リソースを、何らかの特性の異なる単一の論理リソー
スに見せる

応用
システム

グリッド
技術

WEB
サービス

計算グリッドデータグリッド

データセンタグリッド

センサグリッド

適用型ジョブ制御

コラボレーション

アプリ管理

GRIDセキュリティ

仮想組織

ジョブ実行管理

データ管理

アプリ仮想化

デプロイ機能ロギング

ジョブ仮想化

分散管理

従量制課金

データ仮想化

CIMプロファイル

情報サービスコンテナ仮想化

WS-Addressing

Notification

サーバ仮想化・ VM 

CIM情報モデル

WS-Security

ネットワーク仮想化

HTTP(S)/SOAP

WSDL

ストレージ仮想化

仮想化技術
出展：wikipedia-5-

仮想化技術アウトライン

仮想化技術
仮想組織

技術内容
VOマネジメント

アプリ仮想化

ライセンス管理、実装隠蔽

ジョブ仮想化

実行位置透過、リスタート機能、
CPR, DR

データ仮想化
コンテナ仮想化
サーバ仮想化グリッドと仮想化技術
グリッドでの仮想化技術の活用
OGFでのマシン仮想化の標準化
DMTFでのマシン仮想化の標準化

分散・遠隔ファイルシステム
フェデレーション

まとめ

プロビジョニング、リパーパシング
VM, LPAR, VPAR, PPAR, クラスタ

ネットワーク仮想化

VLAN, VPN, プロビジョニング

ストレージ仮想化

SAN, NAS, iSCSI, SMI-S

Amazon EC2

仮想サーバ・インフラ

 Amazon EC2 (Elastic Compute Cloud）
 Amazon Elastic Compute Cloud 3tera AppLogic

Amazonのコンピューティングリソースをユーティリティサービスとして提供

 Amazon S3 (Simple Storage Service)を利用した実行環境
専用ツールでAMI (Amazon Machine Image)を作成し、S3にアップロード
EC2は仮想サーバ環境でAMIを動作 CPU:1.7GHz Xeon, メモリ:1.75GB, HDD:160GB, Bandwidth: 250Mb/sのサーバと同等のマシンパワー サービス利用料
初期費用や月額メンテナンス料なし$0.10/インスタンス/時間 (1インスタンスを常時利用した場合、$72/月)
 使用ストレージ容量 : $0.15/GB/ 1カ月 データ転送(バンド幅) : $0.20/GB (EC2とS3間は無料)

仮想
リソース




ユーザ

Amazon Machine Image

物理
リソース

S3
http://aws.amazon.com/ec2

GT4 virtual Workplaces

アウトライン Globus incubation projectのひとつ
 Leader: Kate Keahey (ANL) 最新リリースは v1.3.1 (2008.2.14)

グリッドと仮想化技術
グリッドでの仮想化技術の活用
OGFでのマシン仮想化の標準化 ユーザの作業環境提供に仮想マシンを活用
 ユーザが、所望のOS, ソフトスタック, アクセスポリシを備えた実行環境を作成可能
 ユーザが、VMイメージの開始・停止・再開・マイグレーションを制御可能
 資源割り当て量を厳密に履行可能 ユーザ間の完全な分離可能

DMTFでのマシン仮想化の標準化
まとめGridVirt-WG

Recap:
Evolution of Server Virtualization

 OGFで仮想サーバに関する標準化活動を行うため、OGF19(2007/1)にトップダウンで創設

3rd Gen…
Infrastructure-wide Virtualization

議長：Erol Bozak (SAP), Wolfgang Reichert (IBM)2006 + ...

 目的(案）
Verification that within existing Grid standards the specifications areneutral to virtualized systems and resources

1.
••

1st Generation
Single System
Hypervisor-based
Stack

The request for “resources” may be satisfied either by “virtualized resources” or“physical resources”
Is virtualization “transparent to the current Grid standards”?

Explore how virtualization technologies can be exploited to bettersupport Grid use cases

2.
••

2nd Generation
Virtual Infrastructure
2003-2006• Automation• Aggregation• Availability• Optimization

CentralManagement

CentralManagement

Enterprise-Class
Virtualization

Enterprise-Class
Virtualization

1999-2003

Define the use cases / scenarios wherein the Grid infrastructure is seen interactingwith system virtualization platforms and making use of its capabilities
Exploit existing concepts and work, e.g.

 標準仕様の開発を目指しているわけではないし、活動も始まって
いない

VM

…

VM

HW

©2007 Open Grid Forum

-6-

VM

HW

…

VM

VM

…

HW

Source: OGF GridVirt-WG OGF21

VM

Workstream 1: High-level Use Cases Description & Alignment of
Grid Reference Architecture in the Context of System
Virtualization• Define the requirements to the grid architecture for integration withsystem virtualization platforms•

Workstream 2: Refine the Resizing and Migration Use Case
• Define Interaction among the components in the architecture tocreate / discover, configure and start a Virtual System• Describe relationship to SVPC Model•

Workstream 3: Refine the Provisioning Use Case
• Define Interaction among the components in the architecture tocreate / discover, configure and start a Virtual System• Describe relationship to SVPC Model & OVF (Open Virtual Machine
Format)Provisioning©2007 Open Grid Forum

Isolation•

Snapshotting

Virtualization capabilities
Virtualization use cases• Power saving• Planned maintenance• Changing capacity requirements• Changing capacity offering/availability• Stateful cloning• Protecting long running jobs from system failures• Reproducing situations• Metering of job resource consumption• Resource consumption enforcement• Protection against malware• Ensuring Security• Avoiding conflicts• Emulating an environment for legacy jobs
Dynamic resizing

Workstreams

Live migration

Recap: Use Cases Overview

Source: OGF GridVirt-WG OGF21©2007 Open Grid Forum

アウトライン

Source: OGF GridVirt-WG OGF21

Distributed Management Task Forceグリッドと仮想化技術
グリッドでの仮想化技術の活用
OGFでのマシン仮想化の標準化
DMTFでのマシン仮想化の標準化
まとめ

DMTFの技術一覧

DMTFの代表技術仕様
 Systems Management Architecture for Server Hardware (SMASH) Set of specifications that deliver standards-based management for servers

and includes both a command line protocol and a web services based
programmatic interface.

 Desktop and m obile Architecture for System Hardware (DASH)
 Set of specifications that deliver standards-based web services managementfor desktop and mobile client systems.

 Common Diagnostics Model (CDM)
 An extension of CIM, the CDM specification is used to evaluate the health ofcomputer system components.
 Common Information Model (CIM) System Virtualization Management

Conceptual object-oriented model for describing a company’s computing and networking
environments. It defines “rules” and provides the details for integration with othermanagement models.

 Standards specifications for managing a virtualized environment and the Web-Based Enterprise Management (WBEM)


lifecycle of virtual machines and deployments.

Set of management and Internet specifications developed to unify the management of
distributed computing environments.

System Virtualization WG
 System Virtualization Partitioning and Clustering (SVPC)
Workgroup クラスタシステムや、LPARのCIMモデルを検討していた昔からあるWG
 VM以前の活動は、あまり活発ではなかった

 Work ongoing to produce CIM model (CIM profile andassociated CIM schema changes) for virtual systems and thevirtual resources which compose them.
 Virtual Machine Image Format
 Open Virtual Machine Format Specification (OVF)-7-

SVPC document• Developed by Dell, HP, IBM, Microsoft, VMware, XenSource• The OVF specification is accepted as a draft specification by the
DMTF (2007/9)• OVF 1.0 specification is expected in the first half of 2008.

-8-

まとめ
 グリッドと仮想技術は、相互補完的 仮想化技術を使うことで、グリッドの適用範囲が広がり有用性が増す 例：

Amazon EC2やGlobus Virtual Workspaces

 OGFのGridVirt-WGは、グリッドユースケースを議論
 DMTFのSVPC-WGは、仮想サーバの標準仕様を作成
 Virtual System Profile
 System Virtualization Profile Resource Allocation Profile, Allocation Capabilities Profile Open Virtual Machine Format Specification-9-3.2. データグリッド－RNS と Gfarm v2 ファイルシステム－
報告：筑波大学）建部修見
添付資料 ・・・第 3 回会合（2008 年 6 月 9 日）報告
SS研Grid WG
2008年6月9日＠汐留

データグリッド最新の話題
Open Grid Forum (OGF)におけるデータエリアの状況
Grid File System (GFS) WG
Grid Storage Management (GSM) WG
OGSA Data Movement Interface (DMI) WG
Database Access and Integration Service(DAIS) WG
OGSA ByteIO WG
終了：OGSA Data WG
休止？：GridFTP WG, InfoD WG, DFDL WG

データグリッド最新の話題- RNSとGfarm v2ファイルシステム
建部 修見
筑波大学
tatebe@cs.tsukuba.ac.jp

データエリアのREC文書(1)Document Title
GFD.???

Authors

Data Movement
Interface
A. Sim, A.
SRM 2.2
Shoshani
S. Davey, et al.
Information
Dissemination
M. Pereira, O.
RNS
Tatebe, et al.
M. Morgan
ByteIO WSRF
Rendering
M. Morgan
ByteIO 1.0

GFD.129
GFD.110
GFD.101
GFD.88
GFD.87

データエリアのREC文書(2)
WG

Document Title

Authors

WG

DMI

GFD.76

WS-DAIR

DAIS

GSM

GFD.75

WS-DAIX

INFOD

GFD.74

WS-DAI

GFS

GFD.47

GridFTP v2

ByteIOGFD.20

GridFTPM. Antonioletti,
et al
M. Antonioletti,
et al
M. Antonioletti,
et al
I. Mandrichenko,
et al
W. Allcock

ByteIO

ogf
data

gfs

file1

file2

file1

file2 • 仮想ディレクトリ
file4• ジャンクション• 仮想名前空間から任意のリソー
スの参照へのマッピング• （シンボリックリンクのようなもの）

EPR2

EPR1

http://www.ogf.org/documents/GFD.101.pdf©2006 Open Grid ForumDATA

add ( string: name, EPR: reference, . . . )list ( [ string: regexp ] )update ( [ EPR: parent, string: name, EPR:
reference, . . . ] )query ()
remove ( [ string: name | string: regexp ] )• 仮想名前空間のディレクトリ

file3

GridFTPRNS Operations• 階層的な名前空間の管理• 名前とリソースのマッピングを行う• 基本コンポーネント

jp

DAIS

http://www.ogf.org/documents/GFD.???.pdf

Resource Namespace Service(GFD‐P‐R.101)
/grid

DAIS

5

©2006 Open Grid Forum- 10 -

6

RNSにおけるメタデータ
/grid

…

data

…

gfs
…

file1

• 任意のメタデータを仮想ディレクトリ、ジャンクションに付加可能
metadatajp• 任意の拡張が可能

metadata

metadata

ogf

file1

…

file2

GFS Naming Profile

…

file2

…

file3

…

…

file4

GFS Naming Profile

Resource Namespace• GFS Naming Profile• Life Science Resource
Profile• ...

Service (RNS)• Define necessary feature for GFS on top of
RNS• Entry property for GFS• Iterator – WS‐Enumeration• Resolver – WS‐Naming

EPR2

EPR1

7

©2006 Open Grid Forum

String representation of the actual checksum corresponding
to the physical file or fileset symbolized by this data resource
junction.

ChecksumType

String representation of the checksum type or algorithm
used to produce the checksum.

ChildCount*

Number of subentries corresponding to this VFDS entry, if
and only if the entry is a virtual directory; zero or NULL
otherwise.

Description*

Description of entry.

Complete

Identifies whether or not the file or filesystem source
targeted by this VFDS entry is complete. In the case of files, avalue of true connotes all of the file content is embodied in
the file; for filesets (filesystem subtrees) this identifies
whether or not the fileset is complete in terms of number offiles participating and the coherency of these files.

©2006 Open Grid Forum8©2006 Open Grid ForumGFS Entry Property (1)Checksum

Other Naming Profile

GFS Entry Property (2)MutableSource

Identifies whether or not the file or filesystem source
targeted by this VFDS entry can change.

ReadOnly

Identifies whether or not a local copy of the data should be
locally read‐only.

ReplicaCopy

Identifies whether or not the file or filesystem source
targeted by this VFDS entry is a replica copy.

Size

The physical size of the targeted data source. If the target
data is in the form of a file (implying a Physical File Name)then this value discloses the size of the file in bytes. If thetarget data is in the form of a fileset (implying a Physical File
System Name) then this value discloses the summation sizeof all the contained files.

ModificationTime* The replica or fileset’s point‐in‐time timestamp

corresponding to the time at which the source snapshot was
made.

The version number of the targeted data if available.

Version9©2006 Open Grid Forum

10

Iterator

Further Consideration• WS‐Enumeration (http://www.w3.org/Submission/WS‐• Performance

Enumeration/)• Enumerate ( EndTo, Expires, Filter )• Pull ( EnumerationContext, MaxTime, MaxElements,
MaxCharacters )• Renew ( EnumerationContext, EndTo, Expires, Filter )• GetStatus ( EnumerationContext, EndTo, Expires, Filter )• Release ( EnumerationContext )• EnumerationEnd ( EnumerationContext, Code, Reason )• Need NFSv4‐like COMPOUND procedure• it is used to combine one or more operations into asingle RPC request• Security• Access control list

• Difference from “RNS Iterator”• To namespace information• To the target resource that the namespace refers to• WS‐Enumeration does not provide the number of entries• WS‐Enumeration has only “implicit iteration”, no “explicit
iteration” using IteratorIndex©2006 Open Grid Forum11©2006 Open Grid Forum12

GFS‐WGのこれから• GFS Naming ProfileからFile Catalog Service
Profileへ

Gfarm v2ファイルシステム• グリッドにおいては、ファイルカタログが広く利用されるが互換性なし• gLiteのLFC、Fireman、SRBのMCAT、GlobusのRLS、NaregiのGfarm• File catalogはFile System Directoryとほとんど変わらない• ファイルカタログサービスの標準策定へ©2006 Open Grid Forum13- 11 -

Gfarmグリッドファイルシステム（１）Gfarmグリッドファイルシステム（２）ストレージを束ねた分散ファイルシステム
マウントして世界中から利用可能。アプリケーションを選ばない
利用者、プログラムの並列性に応じたスケーラブルなI/O性能
自動ファイル複製選択による耐故障性の実現とアクセス集中の回避

ファイルはどこからでも共有可能
実際には、ファイルは複製が作成され、どこかのファイルシス
テムノードに格納される
アプリケーションは格納場所を意識することなくアクセス可能
GridFTP, samba, NFS server
GridFTP, samba, NFSサーバ
Compute & fs node

Globalnamespace /gfarm
ggf
aist

jp
gtrc

file1

file2

file1
file3

マッピング
file2

file4

ファイル複製作成

Gfarmメタデータサーバ

metadata

Compute & fs nodeCompute & fs nodeFile A

Compute & fs nodeCompute & fs nodeFile File
B C

Compute & fs nodeCompute & fs nodeFile A

Compute & fs node

Gfarm File System/gfarmCompute & fs nodeUS

Compute & fs nodeFile B

Compute & fs nodeFile C

クライアントPC

File A
ノート
PC

File C
File B
Gfarm
ファイルシステム…

Japan

スケーラブルなI/O性能の実現（１）スケーラブルなI/O性能の実現（２）ローカルディスク優先の分散ディスクアクセス
ファイルの新規作成時

Gfarmにおける実行の挙動

利用者からの見え方（ファイル・アフィニティ・スケジューリング）

十分な空きがあれば、ローカルディスクに書き込む
なければ、近くて暇なノードに書き込む

既存ファイルのアクセス時

User A submits Job A that accesses File A

Job A is executed on a node that has File A

User B submits Job B that accesses File B

Job B is executed on a node that has File B

ネットワーク

ファイル複製があれば、ローカルディスクをアクセスする
なければ、ファイル複製を持つ近くて暇なノードをアクセスする

PCクラスタ、グリッド
PCクラスタ、グリッド

ファイル・アフィニティ・スケジューリング
指定されたファイルの複製をもっているノードでプログラムを実行させる

CPU

CPU

CPU

CPU

Gfarmファイルシステム

ファイルシステムノード = 計算ノード

ネットワーク共有ファイルシステム

ローカルディスクをアクセスする機会が増大

CPUとストレージを分離するのではなく、処理とデータアクセスを分散させる
大規模データを移動させるのではなく、そこでプログラムを起動する
ローカルディスクの積極的な利用がスケーラブルなI/O性能の鍵

Belle実験データ解析

Japan Lattice Data Grid

• 1112ノードを束ね、26 TBのGfarmファイルシステムを構築• 24.6 TBの全Belle実験データを格納• 並列読込み性能で52.0GB/sを達成→ ディスクI/O性能を3,024倍に• b → s γ崩壊のスキムで704ノードを利用して24.0GB/sを達成→3週間を30分以内に

I /O bandwidth [GB/ se c]O. Tatebe et al, “High Performance Data Analysis for Particle
Physics using the Gfarm File System”, SC06 HPC Storage
Challenge, Winner – Large Systems, 2006

計算素粒子物理学の高度データ共有基盤JLDGの構
築・運用

52.0 GB/sec

60

広島大

KEK

京大

阪大

6.4 TB

6.4 TB50

6.4 TB40

6.4 TB30
20
10

Gfarmメタデータ
キャッシュサーバ

SINET3

0
0

200

4 00
600
80 0
number of clien t n odes

1 000

12 00

1112
ノード

VOMS

CA/RA

研究グループ単位のアクセス制御

gfsd
GridFTPサーバ

6.4 TB

GridFTP
クライアント クライアント

Gfarmファイルシステム
6.4 TB disk (500 GB x 16 RAID6)
Dualcore 2.33GHz Xeon x 2
4 GB memory

LAN
スパコン

PRAGMA Grid
C. Zheng, O. Tatebe et al, “Lessons Learned Through Driving
Science Applications in the PRAGMA Grid”, Int. J. Web andGrid Services, Inderscience Enterprise Ltd., 2007

• アジア、東南アジア、オセアニ
ア、北米、中南米、ヨーロッパの14カ国、29組織からなるテスト
ベッドを構築• ファイル共有基盤としてGfarm
ファイルシステムを運用→ 実行コード、入出力データの共有がGridで可能に！
→ 並列アプリケーションがステー
ジングなしで実行可能に！

Gfarm v2の設計と実装- 12 -

Gfarm v2の設計の特徴

Gfarm v2ファイルシステムの構成
MDS

Gfarm client

ac

ce
ss

Gfarm client
Local access
I/O Server

I/O Server
Local filesystemStand-by MDS

data

te

upd

Metadata inquiryRemoLocal file
Local filesystemsystemat e

Gfarm client

Backend DB
Backend DB

Meta

Clients
Gfarm client

MDS
MDS

Gfarm2fs Gfarm cmds
Gfarm libraryGfarm client

NFSv4のコンパウンドRPCを拡張

Gfarm client

I/O Server

Local filesystem

メタデータのメモリ上へのキャッシュ
ファイルシステムノードの選択コストの削減
メタデータサーバによるモニタリング
ユーザ，グループ管理
特権ユーザの導入
グローバルユーザ，ローカルユーザ間のマッピング

I/O Server

Local filesystemLocal filesystemFile System Nodes and Clients
Institute A

ファイル複製管理
任意数，任意の場所の複製を管理
Close-to-open一貫性セマンティクスを保持するため，集中管理
メタデータと実ファイルの間の一貫性の保持
クライアントクラッシュ時のメタデータの更新
実ファイルの不正アクセス禁止
ファイル消去時，ファイルシステムノードが落ちていたら，不要複製リス
トにファイル操作の遅延時間削減
コンパウンドRPCの導入によるRPC回数の削減

Institute B

close-to-open一貫性の保持

Consistent update of metadata (1)クローズ時に他のファイル複製を消去

Gfarm v1 – Gfarm library updates metadata
open

プロセス１

メタデータサーバ
file2

jp
file1

Application

fopen(“/grid/jp/file2”, “rw”) fopen(“/grid/jp/file2”, “r”)

/grid
ggf

プロセス２

file2
FSN2
FSN1
fclose() ファイル
アクセス

file2

FSN1
close

Gfarm library

Metadata server

Update metadata

fclose()Metadata is not updated
at unexpected application crash

ファイル
アクセス

File system node

FSN1

FSN2

Invalidな複製を消去
アクセスは続行

FSN1

クローズまえであれば任意の複製をアクセス

Consistent update of metadata (2)Software Stack

Gfarm v2 – file system node updates metadata

Gfarm
Application

open

Application

FSN1

Metadata server

Windows
Appli..
Appli(Word,PPT
Word,P PT,
Exc
Excel
el e
etc)
tc)

UNIX Command
Gfarm
CommandGfarm librarycloseor broken pipe

UNIX
Application

NFS
ClientWindows
Client

nfsd

samba

FTP
Client

SFTP
/ SCP

Web
Browser/ Client

ftpd

sshd

httpd

Update metadata
GfarmFS--FUSE (that mounts FS in UserGfarmFS
User-space)libgfarm - Gfarm I/O Library

File system node

Gfarm Grid File System
FSN1

Metadata is updated by file system nodeeven at unexpected application crash

オープンソース開発

性能評価

Sourceforge.net
http://sourceforge.net/projects/gfarm

評価環境
メタデータサーバ – 筑波大
ファイルシステムノード
筑波大 産総研
148
ノード数

Latest Source code
svn co http://gfarm.svn.sourceforge.net/svnroot/gfarm/
gfarm_v2/trunk gfarm_v2
svn co http://gfarm.svn.sourceforge.net/svnroot/gfarm/
gfarm2fs/trunk gfarm2fs

RTT[msec]

0.202

0.787

SDSC
3
119

評価項目
並列I/Oバンド幅

Nominate Now!

各クライアントが異なる1GBファイルを読込

ファイル操作の所要時間- 13 -

NFSのI/Oバンド幅

Gfarm v2のI/Oバンド幅

同時読込クライアント数

Univ Tsukuba

AIST

1~3 msec

U Tsukuba
NFS(async)Local FS

10000

SDSC (v1)

1000

5.8倍

SDSC
AIST (v1)

100

12.6倍

10

U Tsukuba (v1)
22.8倍
AIST
U Tsukuba

1

Gfarm v2の展開，build時間

200

157.02

[sec]

150
100
50
0

72.02

50.2

54.26

12.99

14.79

ext3

NFS

88.85

92.69

u+
w
ch
m
od

ut
im
e

lo
se

rm ‐rfconfiguregunzip+untar

1.4倍

62.15
2.2倍33.64
15.461.8倍

seGfarm v2ソースディレクトリの移動
ディレクトリ数
173
ファイル数
1,251
make

91.782.9倍
63.39

clo

ディレクトリのmove

1,424
1.37 MByte
154.21

op
en
+c

rm
di
r

2~4 RTT

cr
ea
t+

m
kd
ir

0.1

re
na
m
e

SDSC

[msec][msec]

238 msec

ファイル数
全ファイルサイズ

SDSC

Gfarm v1との比較

ファイル操作の所要時間

0.2~0.5 msec

AIST

un
li n
k

ファイル読込性能

1,433 MB/s

37.0 MB/s

30.68

ディレクトリの移動

Gfarm v2

Gfarm v1

v1+agent

<0.00

20.98

21.15
[second]Gfarm v2 Gfarm v1 v1+agent

まとめ
Gfarm v2ファイルシステム
ファイルシステム一貫性の向上，セキュリティ向上，アクセ
ス速度向上
広域のクライアントによるスケーラブルなI/O性能
日米の22クライアントから1,433 MB/sec

ファイル操作はメタデータサーバまでのRTTの2~4倍
ローカルクラスタではNFS(async)とほぼ同等
Gfarm v1と比べ最大23倍の高速化./configureはNFS(async)とほぼ同等，Gfarm v1より2.2倍高速
オープンソース開発
2008年5月27日にGfarm version 2.1.0をリリース
http://sf.net/projects/gfarm- 14 -

3.3. 天文学研究におけるデータグリッド
報告：国立天文台天文データセンター）白崎裕治
全世界の天文データは 1 年で倍増、あるいはそれ以上の勢いで増え続けている。また、そうしたデータの大部分は無償で公開されており、様々な国の研究者がインターネットを介して利用することが可能である。天文学上の新たな発見が、そうした公開アーカイブデータの活用により次々となされており、アーカイブデータを利用した研究が主要な研究手法の一つとなってきている。
国立天文台がハワイのマウナケア山頂において運用を行っているすばる望遠鏡は、10 年前に運用を開始してからこれまでに 10TB を超える観測データを蓄積してきている。すばる望遠鏡では 9種類の観測装置が利用されているが、中でも特に、広視野撮像カメラである Suprime-Cam は、すばる望遠鏡による全データの 9 割程度を占め、大量のデータを生成する観測装置である。
天文研究者がすばる望遠鏡のデータを利用する際は自分が利用する計算機へ、データアーカイ
ブから ftp によりデータを手作業でダウンロードする必要がある。また、データアーカイブから取得できるデータは生データであり、天文学的な解析を行う前にはデータの整約処理を行う必要がある。
その整約処理では、多数のデータを処理する必要があり、その処理に要する時間も膨大な時間が必要である。すべての Suprime-Cam データをシングルスレッドジョブで処理しようとすると、アーカイブからのダウンロード作業も含めると１年以上はかかる大変な作業となる。
Suprime-Cam は 2011 年に Hyper Suprime-Cam (HSC) へのアップグレードが予定されており、これによりデータ量が 10 倍となる予定である。HSC のデータをこれまでのように、研究者が手元にダウンロードして解析を行うのは、たった 1 つの観測データセットですら量が膨大であるため不可能となり、整約処理されたデータの配信が不可欠となる。国立天文台天文データセンターでは、そのための並列計算システムの構築を行うとともに、それら多数の計算ノードに大量の観測データを効率的に配信することができる、データグリッドの仕組みを実現する研究を行っている。
天文データセンターでは、すばる望遠鏡のデータ配信だけではなく、世界中の天文データをシームレスに取得するためのポータルサイト Japanese Virtual Observatory (JVO) の開発も行っている。
International Virtual Observatory Alliance (IVOA) において、天文データサービスの公開方法なら
びにアクセス方法についての国際標準規格が策定されている。この規格に基づいてデータサービスを提供することにより、様々なデータサービスに対し自動で検索実行、データ取得ができ、天文デー
タグリッドの構築が可能となる。
JVO は IVOA の規格に準拠したインターフェイスを有するデータサービスに対し、ユーザからのリクエストにもとづきユーザに代わって自動でそれらのサービスに対して検索を実行する機能を持つ。
JVO を利用することにより、世界中に存在する様々な観測データを容易に集めることができ、多波長データを利用した研究が進展することが期待される。

添付資料 ・・・第 4 回会合（2008 年 9 月 18 日）報告

• 全世界の天文データは１年で倍増• 様々な装置による様々なデータが無償で公開されている。
• これらの多波長データを利用した天文学研究が主要な研
究手法の一つとなりつつある。
• データ量の増加だけでなく、データを生み出す
装置に投資される予算規模も大きくなり、デー
タの価値もどんどん高
まってきている。

国立天文台 天文データセンター
白崎裕治

10 00
10 0

10
1
0 .1

19 70

- 15 -

19 75

1 98 01 98 5

1 99 0

1 99 5

20 00

CCD s

Gla ssSubaru 8.2m Optical-Infrared Telescope
Nobeyama 45m
Kiso 105cm Schmidt Camera• Okayama 188cm Optical Telescope• Nobeyama 45m Radio Telescope• Nobeyama Millimeter Array
Subaru• Nobeyama Radioheliograph• VSOP• VERAASCA X-ray astronomy satellite
YOHKO solar physics satellite
ASCA• Ginga X-ray astronomy satellite• HALCA VLBI satellite• Geotail geomagnetosphere satellite• Akebono aurora observation satellite

•

•

•

•

AKARI Infrared satellite
SUZAKU X-ray satellite• HINODE
Optical Solar
Satellite
•
•

ALMA

•

AKARI

HALCA

ESO VLT @ Paranal
ESO telescopes @ La Silla• Telescopes in Mauna Kea
Subaru, Keck, JCMT, CSO, SMA,,,• Telescopes on board satellites
HST, GALEX,,,,
•




•





















すばる望遠鏡 (1999~)
FMOS(2009~)

一度に400天体のスペクトル観測が可能になる。(これまでは数
十天体)

HSC(2011~)

HSC視野中の4000天体のスペクトルを一度に観測可能になる。

http://www.aanda.org/
http://www.journals.uchicago.edu/ApJ/
http://www.black wellpublishing.com/journal.asp?ref=0035‐8711&site=1
http://www.asj.or.jp/pasj/
http://adsabs.harvard.edu/
http://nrodb.nro.nao.ac.jp/
http://www.arxiv.org/
http://cxc.harv ard.edu/
http://www.darts.isas.jaxa.jp/
http://heasarc.gsfc.nasa.gov/
http://www.sdss.org/

http://www.ipac.caltech.edu/2mass/
http://irsa.ipac.caltech.edu/
http://www.ukidss.org/
http://lambda.gsfc.nasa.gov/
http://www.astro‐wise.org/
http://archiv e.stsci.edu/
http://terapix.iap.fr/
http://nedwww.ipac.caltech.edu/
http://www.roe.ac.uk/ifa/wfau/
http://nssdc.gsfc.nasa.gov/
http://www.jach.hawaii.edu/UKIRT/
http://www.spitzer.caltech.edu/
http://www.cfht.hawaii.edu/Science/CFHTLS/
http://cdsweb.u‐strasbg.fr/
http://swire.ipac.calt ech.edu/swire/swire.html
http://cfa‐www.harvard.edu/iauc/SearchIAUC.html

http://www.oamp.fr/virmos/virmos_vv ds.htm
http://www1.cadc‐ccda.hia‐iha.nrc‐cnrc.gc.ca/cadc/

http://deep.ucolick.org /http://skyview.gsfc.nasa.g ov/

http://www.eso.org/science/eis/
http://archiv e.eso.org/

http://www.galex.caltech.edu/
http://dbc.nao.ac.jp/

http://www.stsci.edu/science/g oods/
http://idlast ro.gsfc.nasa.g ov/

http://www.ast.cam.ac.uk/~wfcsur/
http://www.noao.edu/noao/noaodeep/
http://www.esa.int/SPECIALS/ESAC/index.html

http://www.eso.org/public/astronomy/archive.html

 すばる望遠鏡 400 億円 + α
 ４４５ refereed papers (~2007年)Æ 1億円/paper

 TMT 1000 億円？
 国内研究者が分担額 (1/4) に見合った成果を上げることが求められる

WFMOS(2017?~)

 データの占有期間（１年？）内に結果を出さないと ...

観測視野がこれまでの10 倍になる。データ量も10 倍

 「どういったサイエンスをするか」 に加え、「いかに効率的に成果を達成するか」 といった戦略が必要

取得したデータを速やかに解析できる環境を構築し、国内研究者間で共有できる仕組みづくり。
 アーカイブデータを利用できる形で配信し、研究成果をさらに促す。

TMT (2017?~)

30m 望遠鏡
アメリカ＋カナダ＋（日本）

生データ

15 TB/year

TMT : 15 TB/year

1.5 TB/year

処理済み データ

Upgrade toHyper‐SuprimeCam

カタログ- 16 -• データ量 : 大 例: SXDS 1TB ~70,000 フレーム
• Web IF をもつデータアーカイブから手動でインタラクティブにダウンロード• 物理量（位置、明るさ、波長...）を測 定可能にするためリダクション。
データを目視で確認しなが らインタラクティブに解析• 装置毎に固有の解析 ソフトを利用• 観測装置の性 能やくせ、さらには観測時の気象条件などについても知っている必要がある。解 析のための難易 度が高い
• データ量 : 小 例: SXDS 1GB 25 フレーム
• 観測 装置の特性によるデータの歪みが補正されたデータ。物理量の 測定が可能な 状態。
• 汎用 の解析ソフトにより容易に解析。天体の位置、明るさ、スペク
トルライン Æ カタログ
• データ量 : 小～中 例: SXDS 3GB 1,000,000天体• 画像 やスペクトルデータから測定された天体の属性値のテーブル• この段 階のデータが公 開されると、科学的成 果が得られや すい1. 様々なサイトで公開されている処理済みデータ＆カタログへのアクセス
2. 巨大になってきたデータの処理方法• 世界各国の 16 VO プロジェクトが参加

データアーカイブ
サイト数• 天文データの共有をより容易で効率的に行うための基盤整備• データベースアクセス方式の標準化• 検索言語や検索結果フォーマットの標準化

従来の 天文学研究

天文コミュニティー内で閉じたデータグリッドの実現• 分散ファイル共有を行うための仕様
データ処
理時間

データ量

• シングルサインオン方式• 非同期検索実行方式

問題点１: 分散データ
アーカイブ へのアクセス

猫の手も 借りたい

国立天文台では Japanese
Virtual Observatory (JVO)
を開発 (ポータル)

データが検索可能なこと
 いくつものデータベースに分散しているデータを条件で絞って一括取得したい。
 座標、波長域、観測装置、観測の時刻、観測の深さ ...
 データフォーマットの共通化


巨大なカタログ間のクロスマッチ
 異なるカタログにある同じ天体をクロス ID し、多波長カタロ

グを作成したいデータベースアクセスインターフェイスの共通化

 SDSS (2億天体) + TWOMASS (3億天体)
 大量データの移動が必要

データ
取得を
自動化



 ただし、一部の観測データについては観測者に一定期間優教育用教材としても利用可1



ユーザ認証なしが基本
先利用期間がある。

1. 画像データ、スペクトルデータ、天体カタログ ...

単純なことが簡単にできること。

 データ形式は FITS または VOTable (XML) 利用頻度が高く、データ転送量が比較的小さなユースケー

スについては、実装が容易でファイアーウォールの透過性のよいプロトコルがよい (http)。
 同期型のインターフェイスが使いやすい。

2. 必要なデータの条件を指定して検索より高度なことができるよう拡張可能であること。

3. どこにどんなデータがあるかはメタデータのデータベースである Registry に登録されている。

 座標、観測波長、観測装置、データの質 ...
 HTTP get によるパラメター指定、 SQL による検索もサポート

 データ転送量が中規模なユースケースについては非同期型のインターフェイスが必要

4. 条件にあうデータリストが VOTable フォーマットで返る データ転送量が大規模なユースケースについては基本的にはデータを動かさず、データのある場所で必要な処理を行
いサイズを小さくしてから移動 Æ 問題点２

 画像やスペクトルデータの場合はそのメタデータとデータへのポインタ (URL) が返る。
 カタログデータの場合はテーブルのレコードが返る。

Metadata

Searchable
Searchab leRegistry② Harvest(collection)• identifier of the service• access URL• contents (star, galaxy,
AGN, ...)• spectrum coverage• ...

Metadata• over 1,000 data resources
are queried at once.
• impossible to do this byhand !
• Takes ~ 10 minutes toc omplete① Registration
Analysis
Service

OAI-PMH
SOAP/WS③ Discovery

Publishing
Registry
VO

Htt p
/WS
SOAP

arc h
④ Se

Data
Service

Storage
Service- 17 -

• 複数サイト間のデータ連携はデータ転送量が小規模 (< GB) であるなら
ば、現在のバーチャル天文台の仕様で解決可能。

大量データ検索に対応していない。
 現状同期型検索のみが標準規約として定義

サイト数

 検索条件が多数になる場合に対応していない。

非同期検索用のインターフェイスも検討中
 VOSapce を利用したデータ検索
• データ量が多い場合 (< TB?) は
VOSpace を利用した非同期検索実行により解決される。

 VOSpace: バーチャル天文台における分散ファイルシス

テムの標準規約

従来の 天文学研究 検索結果を VOSpace 上に一時保存
 検索条件をテーブルとして作成し VOSpace 上に保存、そ

データ処
理時間

のテーブルとのジョインという形で検索実行

データ量

大容量ディスク＋並列計算システムが必要
 生データのリダクションは装置毎に異なりラーニングコ
ストが高い リダクションソフトがすべての OS 環境で正しく動くとは限らない...


データアーカイブと解析システムをセットにする データ移動のコスト最小化
 アーカイブ側に計算機資源を集中（並列計算システム）。

計算資源の共有。
 リダクションソフトの管理を一元化。過去バージョンのソフトによる再リダクションをサポート。
 請求の多い処理済みデータはアーカイブに蓄積。同じリ

ManualManual（Instr.A）（Instr.A）

ManualManual（Instr.B）（Instr.B ）ダクションを繰り返さない。

Ma
nual
Manual（Instr.
（Instr.
C）
C）

Softwa re for i nstr. A

Subaru Telescope
Data Archive（10TB）

Down loadby hand

4. 処理済みデータ

3. 処理済みデータ

Data Archive
Archive
Data

Software for instr. B
Software for i nstr. C

1. データ請求

大規模データのリダクション
 すばるや TMT などの、規模が大きく、かつサイエンスアウト

5. Data Transfer FTP

0. DAS server periodic ally report
its status (load average…)

48 CPU Cores

MDS

DAS

Monitoring andDiscovering
Service

プットの最大化が大きく望まれるデータに特化
 装置に関する特別な知識なしにリダクションを可能にする

2. データ処理の実行要求
またはアーカイブから処理済
Portal Service みデータを取得

Data Analysis Service
1 Gbps x 28 ports

すばるデータリダクション解析システム

JVO
Portal

48 Gbps

 データアーカイブと並列解析システムを専用ネットワークで高速接続 (128Gbpsバックプレーン)

1 Gbps x 12 ports 合計４８ CPU コアにより過去５年間分のデータを約１週間でSRS

モザイク画像まで作成可能
 Web ブラウザ IF でユーザがジョブ実行可能

2. Query an available
DAS server.

DSS

3. J ob submit
6. Data Transfer FTP

1. DataRequestStorage Service
100 TB

4. Search data location on SRS• TMT 観測所から デ ー タ を国 立
天文台へミラー
JVO

サイト数• 国立天文台 TMT アーカイブから国内の複数拠点へ再ミラー• 拠点ミラーからサブセットのみを国内の希望す る大学・研究 所へ配布• 各サイトには解析シ ステ ムも 配置。これらの解析シス テムはデー
タセンターが全件リダクシ ョンを行う際、または一般ユーザがJVO経由に よる リダク ション 実行する 場
合に利用される。
• 各サイトの解析シス テムはホスト大学・研究所の研究者は自由に利用可。
• デー タ移動時間のロスを軽減、計算資源の有効利用。

データと解析資源
集 中投下（解析をデータのある場
所で行う）

Archive
Archive

従来の 天文学研究

Archive
Archive

データ処
理時間

データ量

Archive- 18 -



多サイトの天文データベースを連携する基本的仕組
みはほぼ完成した。(バーチャル天文台)
 小規模データに限定。
 単純なデータ検索バーチャル天文台の仕様拡張が現在進行中
 中規模データにも対応。
 より高度な検索。
 オントロジーにもとづくデータ発見など



大規模データの利用はデータアーカイブと並列計算システムをセットとしたシステムを日本各地に分散配置して対応したい。

3.4. クラウド・コンピューティング
報告：富士通研究所 クラウドコンピューティング研究センター）槌本裕一
クラウド・コンピューティングという言葉・概念が急速に普及してきている。人や場面により言葉の使い方も異なりそれぞれの意図も絡むことが多いため、定義しにくい概念であるが、大まかには「ネット経由でよそのＩＴケーパビリティを使うこと」と言うことができる。つまり特定の技術を指す言葉ではなく、多くの技術の普及を背景とした新しいＩＴ利用のトレンドを包括的に指した言葉である。
ネット経由で提供されるＩＴケーパビリティを「クラウド上のサービス」と呼ぶ。サービスは物理資源からデスクトップアプリから様々であり、そのターゲットユーザも企業、コンシューマー、開発者など様々である。
クラウド・コンピューティングについての様々な議論を見ると、これらのサービスについてのみではなく、別の二つの観点に派生した議論が多い。一つは、サービスの外側で築かれる「エコシステム」。もう一つは、サービスの内側で使われる「実装技術」である。（右図）
このようなクラウド・コンピューティングの普及は、規模の経済追及の必然的結果であり、コンシューマーや中小企業だけでなく、いずれ大企業や社会インフラへも浸透すると思われる。しかし、成熟するには数年が必要であり、それまで、部分的に採用されるなど企業システムの形はむしろ多様化するであろう。
実装技術の観点でも、Google の MapReduce や Amazon の Dynamo など、新しい試みが盛んにおこなわれている。これらのミドルウェアはサービス提供者自らが設計しており、従来とは異なる発想で最適化が行われている。したがって、しばらくはサービスのカテゴリ毎に試行錯誤が行われるため、ここでも多様化が進むと思われる。
報告会では以上のような動向と、企業 IT システムへのインパクトの考察を紹介した。

- 19 -

添付資料 ・・・第 4 回会合（2008 年 9 月 18 日）報告

目次
 クラウド・コンピューティングとは クラウドのインパクト 参考: 実装技術の例

クラウド・コンピューティング 考察

2008年9月18日
株式会社 富士通研究所
ＩＴシステム研究所
システムミドルウェア研究部
槌本 裕一
2Copyright 20 08 FUJITSU LABORATORIES LIMITED

Copyright 2008 FUJITSU LABORATORIES LIMITED

クラウドコンピューティングとは データもプログラム も雲（クラウド）の上に置かれている。ネッ トに接続するブラウザがあれば、どんな 端末からでも雲に届く by Eric Schmidt, Google CEO

クラウド・コンピューティングとは

 一連のITケーパビリティをサービスとして外部に提供すること
 by Gartner

 インターネットという「雲 = クラウド」の向こう側に、サービス を提供する
サーバな どがあるが、ユーザーはサーバの場所も台数も構成も認識できず、単にサービスを受け取る
 by Wikipedia

ここではクラウド・コンピューティングの基本定義を「ネット経由でよそのＩＴケーパビリティを使う こと」
とする

3

4

Copyright 20 08 FUJITSU LABORATORIES LIMITED

クラウド上のサービス

サービス例: Amazon EC2/S3/EBS サービスの形は多様
対象ユーザも、企業、コンシ ューマー、開発者など様々
 提供されるレイヤーも、物理資源からエンドユーザアプリまで様々

クレジットカードを使い、WEBから利用者登録（約15分）
利用環境設定、VMイメージ作成構築、起動（約30分）



Elastic Compute Cloud

Simple Storage ServiceElastic Block Storage




 主な例





デスク トップアプリ



ソ ーシャルウェア• メール (GMail 等)、オフィス (Google Docs 等)、…

$73 / 月・仮想サーバ$230 / 月・TB download$150 / 月・TB
$100 /月・TB

仮想
リソース

• SNS (Facebook 等)、SBM (はてなブックマーク等)、 …
Copyright 20 08 FUJITSU LABORATORIES LIMITED

企業向け業務パッケージ

ユーザ• CRM (Salesforce.com 等)、ERP (NetSuite 等)、 …


開発環境



ミドルウェア

物理資源• 言語 (Salesforce.com の Apex 等)、プラットフォーム (Force.com 等)、…

Amazon Machine Image

物理
リソース

• DB (Amazon Simple DB 等)、 …
S3• VM ホスティング (Amazon EC2 等)、オンラインストレージ (Amazon S3 等)、…
5

6

Copyright 20 08 FUJITSU LABORATORIES LIMITED

Copyright 20 08 FUJITSU LABORATORIES LIMITED

クラウドの派生した観点

サービス利用の成功例: animoto

 ク ラウド・コンピューティングについての様々な議論を見ると、クラウド上で 提供される１サービスについてのみではなく、異なる観点に派生した議論がある。それらを以下の二つの方向にわけて考える。

http://www.animoto.com/
写真と音楽をアップするだけで音楽にあわせたスライドショーを自 動生成するサービス

1. サービスの外側で築かれるエ コシ ステムについて

元々50台の仮想サーバで運営していたが、 Facebookで有名になったのが原因で、3,500台まで3～4日で急遽増設

ここでは「エコシステム」を、パートナーや開発者コミュニティやユーザなどに影響を与えるもの全体、という広い意味で使う• 開発・連携の仕組み・場 (Salesforce.com の Force.com 等)• 金のまわり方 (Google の AdSence 等)• 技術者育成 (Google 101 等)• etc.

2. サービスの内側で使われる実装技術について

従来の技術スタック (例えばウェブ３階層) とは異なる技術要素に着目• 大規模データ処理の容易にするフレームワーク (Google の map-reduce 等)• 多数の顧客に対するサービスを１インスタンスのアプリ・ＤＢで実行 (Salesforce.com のmulti-tenant 等)• オンラインサービスの高可用化 (Amazon の eventually-consistent 等)• etc.
7

Copyright 20 08 FUJITSU LABORATORIES LIMITED- 20 -

8

Copyright 20 08 FUJITSU LABORATORIES LIMITED

グリッドとクラウド （私の理解）

３つの観点の概念図

 グリッドク ラウドのエコシステム



関連コンセプト: Web 2.0, Web Platform

クラウドのサービス

人・モ ノを集める工夫

関連コンセプト: SaaS, Utility Computing

 ク ラウド

出発点は、主に科学技術計算分野での現実の課題と、それに対する技術的
ビジョン「技術的な理想」を表すバズワードへ
ＩＴリソースの現状は不可避な前提条件という立場。主に三つの異なる技術的課題にフォーカス

出発点は、主にコンシューマや中小企業向けのタダ・安価な魅力的サービス群の成功と、その提供者の思惑
 「ＩＴ利用環境の変化」を表すバズワー
ドへ 技術についてはニュートラル。ＩＴリソー
スの在り方も含めて、単純に手段として優劣が問われる。その背景:
• 大量の不揃いなリソースをどう活用するか？ Æ クラスタのヘテロ版・クラスタのクラスタ• データボトルネックをどう克服するか？ Æ
オンメモリ分散データ共有・大規模データの分散管理など• 複数の管理主体の下にあるリソースをどう扱うか？ Æ 標準化

集めたものを活かす工夫

クラウドの実装技術• サービス提供者（インフラ屋ではなくアプリ屋）が単独で設計• 規模の経済を極限まで追求• 利用者からはサービスの実装を隠蔽し垂直に全体最適化

クラウドの技術

グリッド

関連コンセプト: Grid Computing, P2P

例: WS**

9

例: map-reduce

10

Copyright 20 08 FUJITSU LABORATORIES LIMITED

例: eventual consistency

Copyright 20 08 FUJITSU LABORATORIES LIMITED

SaaS とクラウド （私の理解） SaaS ク ラウド「ソフトウェアのパッケージ販売」との対比で使われるため、以下が暗黙の前
提• 利用者: 企業・開発者・コンシューマー• 契約: 購読モデル・広告モデル• 提供レベル: 何でもあり• 利用者: 企業• 契約: 購読モデル• 提供レベル: アプリケーション
「ローカルなＩＴ資源の利用」との対比で使われるため、対象が SaaS より広い

クラウドのインパクト• Paa S など も含 む

マーケティング上 ASP との区別も必要とされたため、 さらに “multitenancy” などの苦しい条件がつく
要するに Salesforce.com が自社のユニーク性を強調するためのソフトウェア
ビジネスモデル名





ＳａａＳ

企業内の「ミニクラウド」なども一緒に議論されるため、さらに範囲が広くなっている
要するに Google 等が世の中のＩＴ利用形態の変化と重ねて自社のビジョン
を大きく語るための言葉

クラウド のサービス
例: ウェブメール、ＶＭホスティング

11

The Big Switch (by Nicholas Carr) 自然に得られる利点

 電力とITは非常に広範に利用できるので 、供給を集約することができれば、汎用技術は規模の経済の利点を享受できる

ネット上にあること

ローカルにもたないこと• どこからでもアクセスできる• 誰とでも（共有したければ）共有できる ユーティリティコンピューティングの興隆は、これまでのビジネス モデルを破壊する脅威である。数千から数億のユーザが使えるようなス ケーラブ
ルなサービス は、企業や SMB 向けソリューションの特徴とコストを激変させる (Bill Gates)• セットアップや移動が不要• ローカル資源の管理が不要

 サービス提供者への期待（集約効果から還元されることへの期待） 中小企業は完全ユーテ ィリティモデルにより、大幅な経済的恩恵を受けら れる。一方、大部分の大企業は、過去のインハウスへの IT 投資と、
ユ ーテ ィリティの利点を慎重にバランスしなければいけない

安い• 従量制あるいはタダ



柔軟



自前で全部やらなくてよい ユーティリティコンピューティングが成熟するには、数年が必要である。
も っとも困難なのは、企業が所有するシス テムをあきらめさせ、データセンタを使うよう仕向ける点である• いつでも必要に応じて増減できる• 建屋、ハード、ソフトなどのエキスパートにならなくてよい• 災害対策やセキュリティ対策やコンプライアンスなども 従来のハードウェア（・ソフトウェア）ビジネスの多くが、単純に失われるだろう

最新の機能が利用できる• サービス提供者のペースで機能拡張が可能
13





by Dennis Gannon
プラットフォーム
Level 3: Runtime Environment

サ ービスの運用 場所: 自社ネッ トワーク内 ／自社 ネッ トワー ク外サ ービスの利用 形態: 直接（ユーザか ら）／ 間接（他の サービス経由 ）サ ービスの所有 者: 自 社／他 社
プ ラットフォームの所 有者: 自 社／他 社

アプ リ

従来型システム
内部直接利用

ハー ド

用
利
接

ハ ード

間
内部

ミドル

ア プ リ アプ リ

ハ ード

利用

ハード

ハード

ハー ド

ハード

ハー ド

ハード

ハード

プラットフォーム
Level 1: Access API
ミドル

ハ ード

ハー ド

ハード

ハー ド

ハー ド

ミドル
ハ ード

ハー ド

ミドル

外部間
接

ア プ リ アプ リ

ハー ド

ハー ド

ハー ド

プラットフォーム
Level 2: Plug-in API

アプ リ

ハー ド

ハー ド

ハー ド

自社開発者

ミドル

ハ ード

ハー ド

ハ ード

外部直接利用アプ リ

リソース配 備を容易にする

アプリ

ミドル

ハ ード

自社ネットワーク利用者

Copyright 20 08 FUJITSU LABORATORIES LIMITED

クラウドのプログラミングモデル

企業にとってもクラウドの（部分的な）利用は不可避
利用形態には様々な組み合わせが可能であり、多様化が進むと思われる


14

Copyright 20 08 FUJITSU LABORATORIES LIMITED

企業システムの多様化

Copyright 20 08 FUJITSU LABORATORIES LIMITED

企業システムへの影響

サービス利用者からみた利点



12

Copyright 20 08 FUJITSU LABORATORIES LIMITED

ハー ド

ハ ード
ハー ド ハ ード

ハード

ハー ド

ハー ド

ハー ド

ハー ド

ハー ド

ハ ード

企業内 「ミニクラウド」

３種類のプラット フォーム
by Marc Andreessen
15

Copyright 20 08 FUJITSU LABORATORIES LIMITED- 21 -

サービス開発を容易にする

並列性を引き出す
16

Copyright 20 08 FUJITSU LABORATORIES LIMITEDクラウドの標準化は時期尚早

クラウドを支える実装技術
業務 支援層分散 処理層ジョブ管理層インフラ管理層システム・ リソース

z
z
z
z

開発コミュニティ育成
SaaS, PaaS基盤
各種サービス部品
サービス開発環境

z
z
z
z
z
z

言語
並列通信処理ジョブ管理
イベント処理分散データ共有
分散ストレージ

Sawzall
Pig
Apex





MapReduce
HadoopDryad

Google Work Queue

Simple Queue Service
GigaSpaces
GemStone
Coherence
Simple DB
Dynamomemcached
GFS
HDFS

z
z
z
z

業務論理構成情報定義
業務ライフサイクル管理
アプリ・マッピング機能
サービスレベル監視zz

ポリシーベースプール
仮想環境管理








z
z

ネットワーク仮想化
仮想ストレージ17 クラウドは最新先端技術のため、クラウド・ベンダは差別化競争に注力している

実装例




 標準化には時期尚早
 グリッドの第二世代（1999~2002）に相当

 ユーザにはスタートアップ企業が多いため、ベンダ
ロックイン回避の優先度は高くない 標準化への圧力・動機付けは弱い 相互接続性ではなく、ベンダー間の移植性を実現する技術が模索されている
 Elastic Server on Demand (CohesiveFT) @ OGF23
 移植性があれば十分
 DMTF Open Virtualization Format (OVF) の活用
18

Copyright 20 08 FUJITSU LABORATORIES LIMITED

Copyright 20 08 FUJITSU LABORATORIES LIMITED

Apache Hadoop プロジェクト
 Google の MapReduce, GFS のオープンソース版
 Yahoo! が支援し社内で実利用
 Google 自身も教育プログラムで 活用

参考: 実装技術の例

 性能実績
 the annual general purpose (daytona) terabyte sort benchmark で優勝• 209 seconds (3.48 minutes)
910 nodes x (4 dual-core processors, 4 disks, 8 GB memory) 利用実績
(http://wiki.apache.org/hadoop/PoweredBy によると 200809-18 現在 43組織)

クラウド実装技術の技術要素のうち、ここでは比較的新しく特徴的な２つの並列分散技術を紹介•Apache Hadoop (OSS プロジェクト)•Amazon’s Dynamo (論文) Yahoo!: 10,000ノードで Hadoop を利用 A9.com (Amazon): 製品に関するインデックスサーチにHadoop New York Times: 大規模画像の変換処理に Amazon EC2 +Hadoop19

20

Copyright 20 08 FUJITSU LABORATORIES LIMITED

Copyright 20 08 FUJITSU LABORATORIES LIMITED

MapReduce と HDFS

性能測定: 細粒度タスクの効率

 大規模データの処理を簡単に書くことができる、分散計算のフレー
ムワーク

 PRIMERGY BX600 （Xeon 3.20GHz×2, 2GB memory
master: 1台, slave: 10台（1台はmasterと同居） → 20 CPU
 モンテカルロ法でπの値を見積るサンプルコードを実行フ ィルター関数（mapper）と集約関数（reducer）だけ記述すればよい

サーバ台数、ジョブスケジューリング、サーバ故障などを考えなくてよい HDFS （分散ファイルシステム）

mapタスク： 乱数を用いた試行を計算
reduceタスク： mapタス クの出力結果を集計し、πの値を計算

 処理時間の測定結果

 特徴：



mapタスク数を100個とし、mapタスクあたりの粒度（計算量）を変えて、
map/reduceの所要時間を測定した
 細粒度なmapタスクで は、ジ ョブスケジューリングなどのオーバヘッドにより並列処理の効果がでない
 粗粒度なmapタスクで は、計算量に応じて実行時間がリニアに増加した• レプリカによる信頼性向上• ファイルは write-once• 大きなファイル のstreaming read への最適化

 MapReduce （分割→分散→集約）

 Hadoop

 特徴：

• 効率的な計算処理• ジョブを多数のタスクに分割して並列実行• データをkey-value の組の集合体として取り扱う
21

大規模データ処理のような、粗粒度タスクに分割できるジョブが得意• 10sec ごとのジョブスケジ ューリングが デフォルト• それ以上の計算 時間を要するタスクで 効果がある
22

Copyright 20 08 FUJITSU LABORATORIES LIMITED

細粒度タスクは不得意

Amazon Dynamo

 Hadoop：粗粒度並列な大規模データ処理が目的→ 細粒度並列は不得意100000nMap=100
実行時間 （秒）

10000







約 4320sec/mapタスク

約 434sec/mapタス ク

100

従来のRDBMSで常識だった「データの完全な一貫性」を保証することよりも、「いつでも必ずデータを書き込める」というレスポンスを優先したアプローチを採用
一貫性を少し犠牲にすることで可用性の大幅な向上を実現

特徴


一貫性



SLA



インタフェース

性能、可用性、一貫性の調整• 一 貫性をある 程度緩 めることで書 き込み を高速 化（ eve ntual consiste ncy ）約 45sec/mapタスク

10

Amazon 内部で使われている技術を論文として発表したもの
スケーラビリティ・可用性を重視し、単純な key-value I/F を持つデータストレージ技術

取 り組み 方

細粒度タスクは不得 意（Hadoop の オーバヘッドだけが見えていると考えられる）

1000

Dynamo とは

粗 粒度タスクの
実 行時間は計算量に対してリニアに増加

Copyright 20 08 FUJITSU LABORATORIES LIMITED• read/wr ite リクエストの99.9 %が3 00ms以 内に応 答を返す 事

slave上での実 行時間：
約 5.3sec/mapタスク• get(ke y), put(key, context, value) のみ 提供 （context はデータのバ ージョンなど に関 する情 報）

1• アプリ の特性 に合わせ て、パラメ ータで調整 可能

1

2

3

4
5
6
7
8
9
mapタスクあたりの試行回数 （10^n回）
23

10

11

Copyright 20 08 FUJITSU LABORATORIES LIMITED- 22 -

24

Copyright 20 08 FUJITSU LABORATORIES LIMITEDEventual consistency

Dynamo の使われ方

 更新の仕方 何に使われているか

全 レプリカへの 更新は非同期 で行われる

 Amazon の内部サービスに使われている• 高速だが、あるデータに複数のバージョンが存在する事がある 一貫性の取り方
 AWS の SimpleDB にも同様のコンセプトがみられる

複 数のバージョンをどう統合するかはアプリ側の責任 実績• この時 context 情報を使う 例（ショッピングカートサービス） ショッピングカートサービス

あるユーザがカートに複数の商品を追加・削除する

ロボットなどによる同時書き込 み（追加・削除 処理）があると、ノード毎にカートの中身が 異なる場合がある

最 終的（決算時 ）には、各ノード毎のカートの中身が統 合され る

一 度削除した商品が復活している可能性はあるが、決算時に顧客がカートの中身を再 確認するので問題ない。

• 数千万リクエスト（300万チェックアウト/日）を処理
 セッション管理のサービス• 数10万同時セッションを実現
 数百ノードのシステムに適用可 参考

（数千ノードへの拡張は難しく、階層化が必要）

http://www.allthingsdistributed.com/2007/12/eventually_consis tent.html
25

26

Copyright 20 08 FUJITSU LABORATORIES LIMITED

Copyright 20 08 FUJITSU LABORATORIES LIMITED

企業ＩＴシステムの変遷
1960年頃～
メインフレーム（Cobol)

考察

ド

ハード開発

ハード開発

オープン化

ウェブ化

クラウド

？

ソ
フ
ト

ハ
ー

？

？

？

構築・
運用

ハード開発

Copyright 20 08 FUJITSU LABORATORIES LIMITED

垂直統合による最適化
 従来
？

？

？



構築・
運用

構 築・
運用

構築 ・
運用

ソフト開発

ソフト開発

ソフト開発

ハード開発

ハー ド開発

ハード開発

ソフト開発
ハード開発
ウェブ化



ソフト開発

水平分業が進んでいた…

• cpu は Intel、OS はMicrosoft 、RDB は Ｏｒａｃｌｅなど

ミドル

そのため標準 Ｉ/F に分断されて、アプリの観点では総合的な最適化ができなかっ
た。

ハード

ＯＳ

 ク ラウド・コンピューティング


ハード開発
クラウド

 クラウド化 ＝ 構築・運用のコ モディティ化
 その次は何か？
 ハード開発 ＋ ソフト開発 ＋ 構築・運用 Î メインフレームの時代と同じ構造？
31

ソフ ト開発30

構築・ 運用

オープン化

ソフト開発

Copyright 20 08 FUJITSU LABORATORIES LIMITED

コモディティ化の層は徐々に上位へ

メインフレーム

構築・ 運用クラウド化 ＝ 構築・運用のコモディティ化

企業ＩＴシステムのコモディティ化

ハード開発

構 築・
運用

メインフレーム

通信プロトコル(http/TCP/IP)
サーバソフト(ウェブサーバ, アプリサー
バ)
クライアントソフト(ウェブブラウザ)
29

ソフト開発



ソフト開発



ソフト開発



ハード開発



PC用のＯＳ (windows, li nux) が 企業
システムのサーバＯＳにインターネット用 のプロトコル・ソフトが企業システムのプロトコル・ソフトに

ハー ド開発



ハード開発



ＷＳ用のハ ード (RISC)
が企業システムのサー
バ機にPC用のハード (x86) が企業システムのクライア
ント機に

コモディティ化の層は徐々に上位へ
シェア

2000年頃～
ウェブ化(Java)

クラウド？



企業ＩＴシステムのコモディティ化
単価

1990年頃～オープン化(C)

Copyright 20 08 FUJITSU LABORATORIES LIMITED

構築 ・
運用

1960年頃～
メインフレーム（Cobol)28

Copyright 20 08 FUJITSU LABORATORIES LIMITED

ローエンド市場からの技術流入

2000年頃～
ウェブ化(Java)

クラウド？

27

1990年頃 ～オープン化(C)Copyright 20 08 FUJITSU LABORATORIES LIMITED- 23 -

サービスの後ろはブラック
ボック スであり、ア プリに合
わせ、全体の最適化が可能。
• 実際、Google, Amazon,
Salesforce.com はそれをうまくやっているように見える。

ア プリ 層デ ータ 層検索

ソ ーシ ャ ル サ

オン ラ イ ン商

業務 アプ リ金融 商品 取（ 大規模デ ータ に対する
バ ッチ 処 理）

イト店( 小規模顧 客への 柔軟な
カ スタマ イ ズ対 応など )引

Map:/ Reduce的なフレ ームワーク

大規模分散フ ァイルシステム( スモール スター ト、（リ ア ルタ イ ムの

ア ジャ イ ル開 発、
ス ケ ールアウト ）人間 から の大量 アクセスへの 安定し た 対応 ）ウェブアプリフレ ームワーク

分散キャッ シュ 共有（シ ステムト レー ドな ど に対する 高速 なレ ス ポン ス）制御された実行環境Event uall y con
si stent

Mult -i tenancy…

イベント 処理

オンメモリ・データ 共有資 源管 理管理

32

Copyright 20 08 FUJITSU LABORATORIES LIMITED意味することまとめ 企業システムも含めクラウドへの移行は進む

ビジネス面


クラウドはオープン化・ウェブ化に匹敵する大きな変化• 主 戦場も技術 もプレ ーヤーも一変する 可能性 がある クラウド利用の形態は様々な可能性がある

新しい主戦場はどこか？
• 予 想: コンシ ューマ市 場か らの 技術流 入が起 こるのだとすると、「顧 客参加 型のエ コシステ ム構築 」あたりか ？



技 術面


 必要とされている実装技術は幅広い

ソフトウェアアーキテクチャ• メ インフレーム Æ クラサ バ Æ ウェ ブ３階 層 Æ ？
• ウェ ブ３階層 は、クライアン トから「ロ ジッ ク」を 取り除 いて運 用管理 を簡素 化し、「ステート」を「ロジ ック」から物理 的に分離 することで「ロジ ック」のスケールア ウトを 容易にした。
• 次 の課題 は？
• 予 想: 「データ層 ボトル ネックの解 消」と「物理 構成・論理 構成の 分離独 立」言語 主戦場・技術・プレーヤーが一変する可能性がある• C obol Æ C Æ Java Æ ？
• Java は「ポインタ (cpu) が分か らない人でも大 規模シ ステ ムを構 築できる」という世界（幻想 ？）をうま く作った
• 次 の言語 がうま く作る べき世 界は？
• 予 想: 「 IO や 異常系 (分 散シ ステ ム) が 分か らない人でもクラウド上でやり たいことを効 率よく やれる 」という世界チップ• メ インフレーム Æ RISC Æ x86 Æ ?
• x86 はＰ Ｃ市場 の経済 規模の 勝利。
• 次 は何市 場？
• 予 想： 「携 帯」 (64-bit は不要 。ア ドレスは もはや pointer では なく url なのだから )33

Copyright 20 08 FUJITSU LABORATORIES LIMITED- 24 -

34

Copyright 20 08 FUJITSU LABORATORIES LIMITED4. NAREGI 関係報告
4.1. NAREGI の現状と今後
報告：国立情報学研究所リサーチグリッド研究開発センター）宇佐見仁英

4.1.1. NAREGI の開発状況
NAREGI は、2003 年から文部科学省が進める「超高速コンピュータ網形成プロジェクト(National
Research Grid Initiative：通称 NAREGI)」としてスタートした。広域分散型の最先端研究教育用大規模計算(サイエンスグリッド)環境を実現するための世界標準による実運用に耐える品質のグリッド
ミドルウェアを研究開発することを目的としてきた。2008 年 3 月末に当初の目標であるサイエンスグ
リッド向けミドルウェアを完成させてプロジェクトは終了する予定である。

4.1.2. 研究コミュニティと仮想組織(VO)
仮想組織は共通の目的の下、複数組織に跨って資源を共有するために動的に形成する仮想的な組織であり、研究コミュニティを形成するための重要なインフラとなる。これからの革新的な研究開
発では、異分野の最先端の研究の融合化が重要であり、NAREGI では、グリッド上の大規模な広域分散資源を仮想組織化するための機能を実現している。

4.1.3. 連成解析の実現
広域分散環境下の異種資源のグリッド管理化、予約方式による同期実行制御により最先端の解析パラダイムである連成解析を実現している。

4.1.4. NAREGI における VO 運用－概観
NAREGI ミドルウェアが想定している VO 運用モデルを提示するとともに、グリッド運用上、重要となる課金問題に対し、各センターの課金へのマッピングを示した。

4.1.5. NAREGI ミドルウェアの配布
研究開発成果物であるサイエンスグリッド向けミドルウェアを RPM パッケージング化し、「NAREGI ミドルウェア Ver.1.0」として提供する予定である。

4.1.6. NAREGI ミドルウェアの品質確保計画
NAREGI も来年度配布後は、オープンソース化して、利用者を中心としたコミュニティが育てて行くことになる。オープンソース・コミュニティソフトウェアとしての開発・テスト体制の確立を図って行く必要がある。

4.1.7. GOC(Grid Operation Center)の設置
オープンソース・コミュニティソフトウェを育てて行くために、NII が自ら利用者となって問題点を把握し、サポートする必要がある。そのために NAREGI お試し環境を運用しながらグリッドによるコン
ピュータ運用を支援する組織(GOC)を設置する。

4.1.8. 次世代計算研究環境としてのグリッド展開
基盤センターを中心としたグリッド環境が構築できるようになった。今後は、次世代スパコンを見据えた上位方向への展開と現場の研究者を巻き込むために、研究室レベルの計算資源もグリッド環
境、仮想組織内に組み込めるような下方展開を計画している。

- 25 -

添付資料 ・・・第 2 回会合（2008 年 2 月 22 日）報告
1

2

“学術研究方法論の変革”と国際大競争時代

ＳＳ研 Ｇｒｉｄ Ｃｏｍｐｕｔｉｎｇ 検討ＷＧ資料•ｅ－サイエンスとその基盤の欧，米での急激な立ち上がり•先進分野での成功事例

NAREGIの現状と今後～ Ｇｒｉｄのトピックス的な話題 ～我が国の現状は、明確なビジョンの下での体系的／戦略的推進が行われていなかった

2008年2月22日
国立情報学研究所
リサーチグリッド研究開発センター
宇佐見 仁英サイバーサイエンスインフラ構想（次世代研究環境）

43

研究コミュニティーとしての仮想組織（ＶＯ）

インフラなくしてイノベーションなし

ＶＯは共通の目的の下、複数組織に跨って資源を共有するため、動的に形成する仮想的な組織
 異な る実組織に所属する利用者が共通のVOに所属 異な る実組織で管理している異種混在した資源をVOで共有利用
 VOの資源構成を柔軟に変更可能
 利用者は必要に応じて複数のVOに所属することも可能
 資源を複数の VO間の共有資源として構成することも可能
 利用者が資源を相互共有することにより、研究開発を促進
VO1とVO2に所属する利用者

VO2のみに所属する利用者

VO3

VO2

VO 2とVO3で共有する資源VO1

C 大学

VO1のみで占有する資源

D 大学

B 研究所
A 大学

実組織
E 研究所

スーパーSINET

VO = メンバー + 計算資源 + ドメイン知5

6

欧州グリッドのVOの例

VO （Virtual Organization ）で実現する共同研究
課 題１）研究中のプログラムは常に進化している
２）研究中のプログラムの計算機環境を移すには多大の労力が必要

A大学では真空中でのたんぱく質の電子構造を解析するプログラムを研究

 欧州のLCG加速器実
験では、その大規模グリッドインフラ(数万CPU,数ペタバイト)を利用する際に、VOへの加入が必要 VOは多数作れる・ある

第1原理に基づき取扱う

溶液中の電子構造

グリッドにより計算機環境を変えずに容易に連携
実験・研究グループ毎にVO連続体として統計的に取扱う計算理論が異なり、計算機に要求される性能が異なる。
それぞれの理論に適した計算資源で計算させることで効率よく計算資源を使える。

B研究所では溶媒分布を解析するプログラムを研究

87

NAREGIミドルによる連成解析（処理フロー）

連成解析処理を実現する予約方式

RI SM
ﾌﾟﾛ ｸﾞﾗﾑ
FMO

これからの計算科学では様々な物理現象を連携させ、より現実に近い状態の解析をする連成解析が重要になる
条 件
物理現象Ａの計算に適した計算資源Ａタイプ
物理現象Ｄの計算に適した計算資源Ｈタイプ
スケジューラ予約

b: ｱ ﾌﾟﾘ 配置

c: 編 集
IMPI

CA

P SE

WFT

ス ー パース ケ ジュ ー ラ

2: 資 源 探 索

計算資源：Ａ

物理現象：Ｄを計算

計算資源：Ｈ

分散 情報
サ ー ビス

3: 予約交渉

２）計算資源の予定を調べ同時に使える
時間に各計算資源に予約を入れる。
物理現象：Ａを計算

合意
9: ｱｶ ｳﾝ ﾃｨ ﾝ ｸﾞ

２）それぞれの計算資源に物理現象を計算するプログラムをインストールする。

グ リッドVM

グリ ッド VM

ﾛｰｶﾙ
ｽｹｼ ﾞｭｰﾗ

ﾛｰｶﾙ
ｽｹｼ ﾞｭｰﾗ

グリ ッド VM

4: 資 源 予 約（ｺ ｱﾛ ｹｰ ｼｮﾝ ）３）時間が来ると予約された各計算資源が起動し、計算結果のデータをプログラムに従いやり取りして、計算処理を進める。

5 : IMP I起 動

IMPI
サー バ

グリッドは連成解析の重要な解である

7: MP I初 期 化

ジョ ブ(S M Pマシ ン )－26－

4: 資 源 予 約（ｺｱ ﾛｹｰ ｼｮﾝ ）ﾛｰｶﾙ
ｽｹｼ ﾞｭ ｰﾗ

6: ｻﾌ ﾞｼﾞｮﾌ ﾞ起 動

RISM

RISM
RIS M
SMP
64 CPU

FMO
FMO
PCｸﾗｽﾀ128 CPU

グリッドMPI
出力ﾌｧｲﾙ

1 : サ ブ ミ ット

１）スケジューラはネットワークに繋がった
計算資源の中からＡタイプ、Ｈタイプを探す。

予約

入力ﾌｧｲﾙワー ク
フローﾌﾟ ﾛｸ ﾞﾗ ﾑ
a: 利 用 者 登 録

グ リッド
M PI

6 : ｻﾌ ﾞｼﾞｮﾌ ﾞ起 動

FMO
ジョ ブ

(PC クラ スタ )グリッド可視化
8: 可視化10

9

サービスコンポネントによるソフトウェア階層

ＮＡＲＥＧＩグリッドミドルウェア構成

バイオ研究コミュニティ

WP6：ナノテクシミュレーションのグリッドへの対応
WP2:
WP3：グリッドﾞ可視化
WP3 ：グリッド PSE
グリッド
プログラミング
WP3:グリッ ドワークフロー
・グリッドRPC
・グリッドMPI WP1: スーパースケジューラ WP1:分散情報サービス

エンドユーザ
サービス

データ
グリッド

WP4：

WP1：グリッドVM

SINET3

セ キュリティサービス

アプリケーション
コ ンテンツ
サービス

情報
サービス

ワークフロー
サービス

可視化
サ ービス

データ
サービス

実行
管理

資源
管理

ネットワーク資源

共同研 究機関

分子科学 研究所

利用者 メタデータサービス
アプ リ配 置サービス

コアグリッドサービス

WP5: ネットワーク通信基盤、性能評価、セキュリティ･認証

国 立情報学研究所

Proxy 証 明書
サービス

ゲートウエイサービス（UNICORE,Globus,Condor,Î OGSA
OGSA))

ナノ研究コミニュティ
ポータ ル
GUI

ポータル
GUI

ネットワーク
資源管 理

その他

計算資源

計 算 資 源PSE: Problem Solving Environment ( 問題解決環境）

11

12

NAREGI ミドルで「何が」できる?

NAREGIにおけるVO運用-概観• CSI中の個人 – 全国(世界)でユニークなIDで特定• NAREGIミドルは様々な機能を持つが。。。

– ≒研究者番号、ただし電子認証可能– CSIの全国認証基盤に遵守、現状ではPKIの証明書、(将来はShibbolethなども?)– ユーザ側：仮想研究組織（VO)の構成、VO毎の仮想化された計算やデータなどの資源(=グリッド
インフラ)の透過な利用（利用手順の標準化）、
VO毎の研究用Web Servicesの立上げ、大規模なデータ共有、国際VOとの連携、など• VOは指定されたグリッドセンター(例： NII、基盤セン
ターなど)に登録、全国レベルへその情報が配布– 多くの場合、指定されたグリッドセンターがVOの実際の「運用」をホスティング(VO自身で管理も可能)– センター側: 計算機やストレッジによるグリッドイ
ンフラの管理運用（利用の平準化）、国際グリッド
インフラとの連携、VO管理のホスティング、など• つまり、「グリッドセンター」は、スパコンや大規模ス
トレッジなどの資源プロバイダーでもあり、かつ VOや、その固有の(Web Services, Web DB, Web
Portalなど)のホスティングサイトでもあるではVOとは正確には何？CSIやグリッドとどう関係がある？センターはどう対応する?

– 「情報基盤センター」のCSI時代への進化
13

NAREGI のVO運用モデル
グリッドユーザ
京大地震

PortalP ortalVO
VO “Ｓ eismological”
Portal“Ｍ eteorology”

VO

SS

IS

“Ｂｉｏｌｏｇｙ”

V OMS

各センターは従来の課金制度のまま

VOMS
SS

IS

VO “ＡＳＴＲＯ”

VOMS

SS

VO がそのまま各セン
ターの課金グループに
写像される

阪大

グリッドユーザ

VOMS
IS

IS

VO計算機利用
研究経費配分
(例：科研の分担金)& アカウント申請

SS

VO用サービス群

IS

PBS- Pro
Grid VM

NQ S-II
GridVM

クラスタ1

クラスタ２

SX-8R

従来ユーザ

資源プロバイダ側

京大 情報メディアセンター

クラスタ2

P rime PowerSGE

G ridVM

NQ S

G ridVM

GridVM
SG E

G ridVM
P BS- Pro

(センターでホスティング)

クラスタ 1

Virtual Org. “Nano1”
Leader: Shimojo
Member1: Shimojo
Member2: Aoyagi
Member3: Okabe
Member4: Ishikawa
Hosted by: Osaka-U CMC / NII“Shimojo”
証明書

Globus
Gridmap File
Shimojo→
Sh imojo -CMC
Aoyagi→Ao yagi -CMC…

VO計算機利用
研究経費配分
(例：科研の分担金)& アカウント申請

阪大CMC 課金グループ“Nano1-CMC”
支払い責任者: Aoyagi-CMC
Member1: Shimojo-CMC (local Unix ID)
Member2: Aoyagi-CMC
Member3: Okabe-CMC
Member4: Ishikawa-CMC

従来ユーザ
阪大CMC

“Aoyagi”
証明書

Globus
Gridma p File
Shi mojo→
Shimojo-KU
Aoyagi →Aoyagi-KU…

各センターはVO →課金グループのGridMapファ
イルを管理

京大情報メディアセンター
課金グループ “Nano1-KU”
支払い責任者: Okabe-KU
Member1: Shimojo-KU (local Unix ID)
Member2: Aoyagi-KU
Member3: Okabe-KU
Member4: Ishikawa-KU
16

15

グリッドミドルウェア研究開発のマイルストーン
２００３

２００４

２００５

２００６

要素技術を
ナノサイエンス研究に適用し評価– 欧州EGEEおよび米国 OSGグリッドのコアミドルのgLite-LCGとのインタオペレーション機能 (後述 )– GridRPC (& GridMPI) とワークフローや SSとの連携化– 非予約・予約ジョブ、パラメタ・サーベイ向けバルク・ジョブ– Globus 連携強化 (ws-gram/if 直サポート)– 種々のローカルスケジュラ(バッチキュー )サポート

NAREGI広域分散テストベッドで開発

NAREGI テストベッドで開発
グリッドミドル要素
技術のプロトタイプ

NAREGI β2およびV.1.0• 新機能群

２００７

ＯＧＳＡをベースに世界先端標準に合わせた開発

ＵＮＩＣＯＲＥをベースに開発体制を構築

β版

Version
1． 0• NEC NQSII(β2), Sun GE(β2), Fujitsu NQS(v.1.0), Condor…
グリッド統合ミドルα版の研究開発↓
NAREGI テストベッド
で評価

α版– フルVOサービス強化（複数VO、VO間 RP資源共有、管理機構など）– 運用ツール、資源管理のポリシ設定（ option)– プライベートアドレスへの一部対応– (学内の )W S-Security, Shibboleth, およびGSI全てと親和性が高いセキュリティ機構α版による NII-IMS
での評価
β版によるアプリケーション
研究開発拠点での評価
グリッドミドルβ版の研究開発↓
NAREGI 広域分散
テストベッドで評価• 性能・安定性

β版の配布

OGSAベース版の開発– 耐故障性の強化-再実行機能など– コンポーネンツ内の再設計・実装によるさらなる速度向上・スケーラビリ
ティ向上– 分散情報サービス (IS) 群によるアプリ・管理・障害情報の一元管理

最終版の
開発
実証・評価

NAREGIシンポジューム２００５より- 27 -

14

NII or CMC 発行の IGTF
グリッド証明書によるグローバルID

Po rtal

VO側IS

VO用サービス群

NAREGIのVOと各センター課金への写像

18

17

β2以降のNAREGIミドルの品質確保の計画•

NAREGI v.1.0以降- CSI実現に向けて• インフラとしての運用の必要性：NAREGIミド
ルだけではCSIは構成できない

β 1は最初のWS-ベースの開発として、それぞれのコンポーネンツの機能実現を最重要視したので、インストールや管理の容易性は二次的になった– 運用体制 – Grid Operations Center(s)– 全国認証基盤 (UPKI)– 他のWS&グリッドミドル—各種ポータル・VO固有サービスやツール・センター固有のツール– 資源プロバイダーとしての各情報基盤センターにおける計算・データ資源整備– VOホスティングとしての各情報基盤センターの体制づくり– SINET3など高速ネットワーク基盤– 勿論、多くのVOの形成• NII-GOC/基盤センター群/分野研究機関等を中心としたミドル・運用・VOコミュニティの形成が肝要– 結果、インストール・運用性は柔軟性に欠け、大変困難に– インストール不備が多くの「バグ」の原因に→β2以降の最重要課題•

NAREGIβ 1: バグレポートやインストール体制の整備•

NAREGIβ 2: パッケージングおよびテスト体制の根本的な拡充– バグトラッキング・レポーティングシステム、インストール専属SE, インストー
ルドキュメントの整備– オープンソース・コミュニティソフトウェアとしての開発・テスト体制の確立– 自動ツール群の採用: Linux APT-RPM パッケージング– インストール・運用の容易性： サービスコンポーネンツのVM上の動作、あらかじめパッケージ化した「VMディストリビューション」– NSF-NMI Build & Test環境における自動ビルド・自動テストの実現– パッケージング・テスト・品質管理チームの創設•

NAREGI V.1.0– 各種パッケージ：クライアントパッケージ、VOパッケージなど– 定期的な build & test
– APTの機能を使ったAuto Update
19

GOCの位置付け （２００８度より正式活動予定）

GOC（Grid Operation Center）の設置

国立情報学研究所
国立情報学研究所

グリッドによるコンピュータ運用の支援組織（GOC）

国際連携・貢献
国際連携・貢献
開発拠点■ GOCの機能・サービス
・NAREGIグリッドミドルウェアの導入支援
・NAREGIグリッドミドルウェアの利用及び技術支援（ヘルプデスクの設置）
・グリッド利用者のための認証局の運用（国際的に通用するグリッド証明書の発行等）
・グリッドを利用する研究グループ（ VO）の利用者管理
・ユーザトレーニング、セミナー等開催（平成19年度より実施）
・NAREGIグリッドミドルウェア開発者への不具合等のフィードバック 等■ NAREGIお試し環境の運用
・アプリケーションユーザを対象としたNAREGIミドルウェアお試し利用環境の提供

学術情報ネットワーク
運営・連携本部

リサーチグリッド
研究開発センター（CSIの構築）

R&D連携・運用連携（ミドルウェア の研究開 発）

学術コンテンツ運営・連携本部

研究開発・
運用サポート

企画・運営連携
フィードバック

注）．ＶＯ名は 仮称

グリッド作業部会

アプ リケ ー ショ ン
ユーザ

N A R E G Iお 試 し サ ー バ

ペタス ケール
システムＶＯ

GOC

SS

企画・運営
サポート

P o rt a l
ア プ リケ ー シ ョンユーザジジ ョョ ブブ・ミドルウェアの導入、運用、技術等支援
・認証局の運用・ＶＯ利用者管理・ユーザトレーニング
・ミドルウェア不具合のフィードバック 等

認証作業部会大 学 ／ 研 究 所

ISVO M S , U M S
M y Pro xy

・ EGEE・ TeraGrid
・ DEISA・ OGF etc

e-サイエンスコミュニティ
サイエンスコミュニティe-（ グリッ ド運用支援 組織） 運用拠点

N II（ 西 千 葉 ）20

ネットワーク作業部会ジジ ョョ ブブ

産業界プロジェクト対応 VO

プロジ ェクト対応ＶＯ

大学・大学共同利用機 関ＶＯ（情報基盤センター群等）

分野別研究機関ＶＯ（IMS,AIST,KEK,NAO etc)

NAREGI
グリッドミドルウェア

I TBLコミュニティVOG r id VM

認証基盤システム

1

N A R E G I計 算 資 源
計 算 機 セ ン タ ー （大 学 ／ 研 究 所 ）企画・整備・運用

ネットワーク・インフラ（
ネットワーク・インフラ（SINET3SINET3））

NAREGIグリッドミドルウェアの導入及び運用を支援するため、 NII内にGOCを設置

The social process of science（Need for a new type of Grid）

科学技術・学術研究の基盤となるスパコンネットワークの構築
次世代スパコン
次世代スパコン
世界のグリッドと繋がる

大学・研究機関のスパコン
大学・研究機関のスパコン

TeraGrid

Virtual Learning
Environment

Provide support for scientists tomanage their domain’s data

大規模データを扱う計算を得意とするスパコン
［ＮＬＳ］

EGEE

22

Undergraduate
Students

主に中規模データを扱う計算を得意とするスパコン ［ＮＩＳ］

DigitalLibraries

スパコンを中核としたネットワークによって、様々な規模のスパコンの各々が連携しながら計算を行えることで、我が国の計算資源を効率的に利活用することができる。

scientists

Graduate
Students

Reprints

ループ化を 図る

PeerReviewed
Journal &Conference
Papers：1G～10G：10G：2 0G～40G

学術情報ネットワーク

研究室レベルのシステム研究室レベルのシステム

Preprints&
Metadata

主に小規模データを扱うＰＣ及びＰＣクラスタ [ＬＬＳ]

ユーザが日頃使用しているＰＣ及びＰＣクラスタ（ＬＬＳ）から大学・研究機関のスパコン（ＮＩＳ）、
さらには次世代スパコン(ＮＬＳ)へと気軽に利用できる環境を実現する。

Repositories

安心して研究教育に専念できるシームレスな研究環境の完成

Technical
Reportsexperimentation

Local
Web

Prof David De Roure “The New e-Science” より

23Grid Environments?

Data, Metadata
Certified
ProvenanceExperimental
Workflows
Results & Analyses
Ontologies

次世代計算研究環境としてのグリッドの展開

まとめ

ペタスケール
計算環境

１）ＮＡＲＥＧＩグリッドミドルウェアはサイバーサイエンスインフラ（CSI)
構想におけるインフラの構築、コミュニティー形成、計算機利用環境構築のための重要な要素技術となるものです
２）ＮＡＲＥＧＩ Ver.1.0では情報基盤センターでの運用、分野別ＶＯの運用を目指し、信頼性の高いグリッドミドルウェア開発を進めます

情報基盤センター
グリッド

NAREGI
グリッドミドルウェア

分野別研究機関グリッド

３）さらに次世代スパコンプロジェクトで開発されるシステムも含めた階層的な計算研究環境の実現を目指したグリッドミドルウェアの開発を進めます国際連携（ GIN,EGEE,Teragrid etc.)

４）ＧＯＣ（Grid Operation Center）を設置し、グリッド利用者のための認証局の運用を推進します
研究室レベル
クラスター

学内計算資源

分野別研究コミュニティ

５）さらにNAREGIグリッドミドルウェアの導入支援、利用及び技術支援（ヘルプデスクの設置）を実施します

－28－

24

4.2. NAREGI ミドルウェアの導入と運用
報告：九州大学情報基盤研究開発センター）青柳睦
執筆：九州大学情報統括本部情報システム部）上田将嗣 戸川忠嗣
九州大学情報基盤研究開発センター）小林泰三 天野浩文

4.2.1. はじめに
平成 15(2003)年度から開発が進められてきた NAREGI ミドルウェア[1] の Ver. 1.0 は、平成
20(2008)年 5 月に公開された。センター長会議およびグリッドコンピューティング研究会での議論の結果、同年 8 月には国立情報学研究所および 7 大学に加えて筑波大学および東京工業大学も参加したグリッド配備・運用タスクフォース[2]が設置され、NAREGI ミドルウェアを活用したグリッド環境の構築と試験運用に取り組むこととなった。さらに平成 21(2009)年 9 月には NAREGI アーキテクトタ
スクフォースも発足して実運用に焦点を合わせた Grid 開発も開始された。
九州大学情報基盤研究開発センター(以下センター)においても、全国共同利用の研究用計算機
システムの一部に NAREGI ミドルウェアを導入し、いわゆる「CSI グリッド」(CC グリッドと呼ぶ場合がある)の試験運用に供している。
本稿では、当センターにおける NAREGI ミドルウェアの導入とその運用を中心にグリッド配備・運用タスクフォースの活動を報告する。

4.2.2. NAREGI の導入
4.2.2.1.

基本方針

平成 20 年 8 月 20 日に開催された第 17 回グリッドコンピューティング研究会において、「全国共同利用情報基盤センター群(7 センター+筑波大学+東京工業大学+国立情報学研究所)」にグリッドミ
ドルウェアを配備するための基本構成を「ミニマム構成」と定義し、この構成を基に各センターで配備・運用を進めていくこととした。
ミニマム構成の主な内容は以下のとおりである。
1) NAREGI v1.1 を使用
2) VO は全体で 1 つ(将来的には拡張にも対応)
3) 管理ノード群一式を国立情報学研究所にて GOC として管理運用
4) 各センターには計算ノードのみを配備
5) データグリッドの配備については当面保留
また、各センターの計算ノードは CSI-Grid 網(L3-VPN)に接続することとした。

4.2.2.2.

センター計算機への導入

ミニマム構成を受けて、センターでは NAREGI を導入するにあたり以下のような方針をとった。
1) スーパーコンピュータシステム内の PC クラスから専用ノードを切り出す
2) OS およびローカルスケジューラについては必要があれば変更

4.2.2.3.

PC クラスタシステム(1)システム構成
NAREGI を導入した PC クラスタは、平成 19 年 6 月より運用を開始したスーパーコンピュータシス
テムの一部で、Fujitsu PRIMERGY RX200S3 全 384 ノードで構成されている。PC クラスタのシス
テム概要を図 4-2-1 に示す。

－29－

図 4-2-1：PC クラスタシステム概要(2)PC クラスタソフトウェア
NAREGI 導入作業時の PC クラスタの OS およびローカルスケジューラを表 4-2-1 に、NAREGI
ver1.1 で正式対応していた OS およびローカルスケジューラを表 4-2-2 に示す。
表 4-2-1：PC クラスタソフトウェア
OS
ローカルスケジューラ
Red Hat Enterprise Linux WS
Parallelnavi NQS for Linux V2.0
（v.4 for x86, AMD64 and EMT64）
表 4-2-2：NAREGI ver1.1 正式対応ソフトウェア (平成 20 年 8 月現在)
OS
ローカルスケジューラ
PBS Pro9
CentOS 5.x （x86 32bit）
SGE+PluS
openSuSE 10.x （x86 64bit）
AIX
Load Leveler

PC クラスタの両ソフトウェアともに正式対応していなかったため、正式対応ソフトへの入れ替えを検討する必要があった。

4.2.2.4.

ノードの切り出し

全 384 ノード中 12 ノードを NAREGI 専用ノードとして切り出すこととした。

(1)OSOS を入れ替えた場合、ベンダ提供のコンパイラやライブラリ、アプリケーションが動作しない可能性や、ファイルシステムが対応できずに NFS によるファイルサーバへのアクセスとなる可能性があるなど非常に影響が大きいことが予想された。
そこで、NAREGI のインストールを支援するために開発されていた rpm パッケージ[3]を改良して、
Red Hat Enterprise Linux WS v4(以下 RHEL4)に対応した NAREGI ミドルウェア rpm パッケージを作成し OS の変更は行わないこととした。

(2)ローカルスケジューラ
ローカルスケジューラについては、正式対応済みの PBS Pro をインストールすることとした。まず、
NAREGI 用に切り出す 12 ノードを Parallelnavi NQS for Linux V2.0(以下 Parallelnavi 2.0)のジョ
ブキューの割り当てをはずした。その後、PBS Pro をインストールしそのうち 1 ノードをサーバホスト
とした。

－30－

(3)hostname の変更
NAREGI ミドルウェアのインストール時に hostname が FQDN である必要があったため、12 ノードに関して変更を行った。

(4)NAREGI ミドルウェアのインストール
RHEL4 は NAREGI が正式にはサポートしていない OS であるので、配備運用タスクフォースの場
で了承を得て RHEL4/x86_64 用の rpm packaging とインストーラの移植を行った。プラットフォー
ムである Linux の相違に起因する NAREGI ミドルの前提ソフトの不整合を解決した。特に gangliaのバージョン変更に伴い IS-LRPS に ganglia の書式変更に伴う修正を施している。RHEL4 移植版
は配備運用タスクフォース内で共有され、京都大学のセンターでも利用されている。この RHEL4 対応の rpm を利用して、NAREGI ミドルウェアのインストールを行った。
PBS Pro のサーバホストノードを GridVMScheduler(以下 GVMS)ノードとして設定した。

4.2.2.5.

ネットワーク接続

GVMS ノードについては CSI-Grid 網(L3-VPN)に接続する必要があったため LAN カードを増設し接続を行った。残りのノードは、直接 CSI-Grid 網に接続するのではなく、NAT 変換により GVMS ノードを経由してアクセスできるようにした。
ノードの切り出しおよびネットワーク接続完了後のシステム概要を図 4-2-2 に示す。

図 4-2-2：ノード切り出し後のシステム概要

4.2.3. NAREGI の運用
4.2.3.1.

利用者管理 DB

センターの通常運用では、ユーザアカウントを「利用者管理 DB」内の「ユーザテーブル」にて管理しているが、NAREGI の運用にあわせて新たに「Grid ユーザテーブル(reg_griduser)」(表 4-2-3)を作成した。
表 4-2-3：Grid ユーザテーブル（reg_griduser）
NO
ラベル
名称
備考
1 usrnoローカルアカウント主キー
2 gpid
グリッドパック整理番号
3 dn
ユーザ DN
－31－

4
5
6
7
8
9
10
11

4.2.3.2.

mflg01
mflg02
mflg03
mflg04
mflg05procidrgstdate
edrnwldt

計算機別利用フラグ 1
計算機別利用フラグ 2
計算機別利用フラグ 3
計算機別利用フラグ 4
計算機別利用フラグ 5
処理区分
登録日
レコード処理日計算機群 1
計算機群 2計算機群 3計算機群 4計算機群 5
処理中/有効/無効

利用者登録フロー通常運用の利用者登録フローは以下に示すとおりである(図 4-2-3 も併せて参照)。
1) 利用者情報登録(ユーザテーブル)
2) アカウント作成
3) 利用承認書の送付
一方、NAREGI ユーザ登録フローでは以下のようにいくつかの作業が追加される。
1) 利用者情報登録(ユーザテーブル+Grid ユーザテーブル)
2) アカウント作成
3) DN 情報の処理
4) grid-mapfile の処理
5) 利用承認書の送付+GOC への通知

図 4-2-3：利用者登録フロー

4.2.3.3.

DN 情報と grid-mapfile の処理

Grid のアカウントとローカルのアカウントをマッピングするのが grid-mapfile である。Grid の運用と管理では、この grid-mapfile の自動管理が重要になる。そこで配備運用タスクフォースで議論の上、以下の方法で解決をした。
ここでは上述の 3)DN 情報の処理と 4)grid-mapfile の処理の詳細を述べる。

(1)DN 情報の処理
2 段階で処理をする。初めに GOC svn repo から DN 情報を取得し、次いで利用者管理 DB側の処理をする。
1. ツール gmap tool1 を実行する
gmap tool1 は GOC svn repo から dn.txt （各センター別 [GPID]・[DN] のリスト）を取得して、更新があれば処理中のフラグを立て、利用者管理 DB 向けのファイルを生成し、全国共同利用担
当者にメールで通知を行う。gmap tool1 は処理中のフラグが立っていれば svn repo の local
copy の更新は行わない。また、更新が無ければ当日の作業はこれで終了する。
2. 利用者管理 DB ツールを実行する（a）GPID のチェック
Grid ユーザテーブルに GPID がなければ 1) 利用者情報登録と 2)アカウント作成 の作業が完－32－

了するまで保留する。
（b）Grid ユーザテーブルの編集
GVMS のみの変更の場合は gmap tool1 の為の処理中フラグを立てて、ここから処理を開始する。[DN] の削除と追加をし、利用可能な計算機資源を GVMS 毎に設定する。削除処理の後に追加処理を行い、追加／削除／変更に対処する。
（c）整合性のチェック
Grid ユーザテーブルと dn.txt との整合性をチェックする。
（d）grid-mapﬁle 編集用データファイルの生成
Grid ユーザテーブルの [ローカルアカウント]・[DN] から grid-mapﬁle 編集用データファイルを作成する。

(2)grid-mapfile の処理
gmap tool2 が処理を担当する。このツールは、処理中のフラグが立ち、且つ、grid-mapﬁle 編集
用データファイルが存在する場合に grid-mapﬁle の編集を行う。次いで、整合性をチェックして問題が無ければ処理中のフラグを消して、全国共同利用担当者にメールで通知を行う。
gmap tool1 および 2 で送信されたメールと Grid ユーザテーブルとの整合性を全国共同利用担当者でチェックし GOC 宛に登録完了のメールを送信する。

4.2.4. 現状と課題
4.2.4.1.

ローカルスケジューラへの対応

今回の NAREGI 導入に当たって、センターPC クラスタに搭載されていた OS およびローカルスケ
ジューラが正式対応されていなかったため、両ソフトウェアの入れ替えを検討することとなった。その結果、ローカルスケジューラに関しては実際に入れ替え作業が必要となった。
しかし、こうした入れ替え作業は、メーカーのサポートの点からあまり好ましいものとは言えない。
また、OS やローカルスケジューラは計算機システムの運用の根幹を左右するソフトウェアであり、センターの計算機資源の中のセンターがローカルに運用する部分とグリッドに供出する部分とでそれぞれ別の OS を使用することが必要になると、各センターのシステム運用計画を煩雑にしてしまう。
今後は、正式対応される OS およびローカルスケジューラが拡大されていくことを期待したい。

4.2.4.2.

典型的な利用者ジョブをグリッドで実行するためのテンプレート作成

現時点では、各センターがグリッドに供出した計算機資源が相互利用可能になったことを確認できているのみで、まだ NAREGI になじみの薄い一般の利用者に広く使ってもらえる状況になったとは言い難い。
今後、典型的なアプリケーションのいくつかについて、複数サイトの計算機のどれに投入されても実行可能な「グリッドジョブ」のテンプレートを作成し、利用者の便宜を図る必要がある。このためには、供出された各種計算機のハードウェア・OS の差異だけでなく、計算ノードからの利用者のホー
ムディレクトリや作業ディレクトリの「見え方」の差異なども吸収できるようなジョブスクリプトを設計しなければならない。
また、インストール済みアプリケーションを利用するジョブ以外に、自作ソースプログラムをコンパイルして実行するジョブもセンター利用の中で大きな比重を占めている。このため、自作プログラムを使用するジョブのグリッド化についても検討する必要がある。
今後は、これらのジョブテンプレートの設計について、グリッド配備・運用タスクフォースのメンバー
各位と協力しながら、努力していきたい。

4.2.4.3.

予約ジョブと非予約ジョブの共存

NAREGI Ver.1.0 から、それまでの「予約ジョブ」の他に「非予約ジョブ」がサポートされるようになり、計算機資源を予約不可に設定した場合、計算資源上のローカルスケジューラに直接投入された－33－

ジョブ(ローカルジョブ)とグリッドジョブ(NAREGI ミドルウェアから投入されたジョブ)との共存が可能になった[4]。
従来のセンター運用におけるバッチジョブは実行開始時刻を特定しない非予約型のジョブである
ため、各センターの判断で「予約不可」を選択すること自体に大きな問題はない。むしろ、ローカルジ
ョブとグリッドジョブを混在させることによって効率的運用を目指すなら、予約不可と設定することを選択することが多いものと予想する。
しかし、「予約不可」と設定された計算機資源ばかりとなってしまっては、NAREGI の特徴の一つである「連成ジョブ」が実行できないことになる。
その長所を生かしつつ各センターの運用の中にうまく NAERGI を位置付けていくためには、予約
ジョブと非予約ジョブを共存させられるよう、予約ジョブの実行方法に再検討を加える必要があるのではないかと考えている。

4.2.4.4.

階層型管理運用機構の構築

また、複数のセンターに分散している資源を連携して利用する Grid の運用には、例えばあるセンターの管理者が他のセンターの管理者である可能性は低く、必然的に複数の階層の管理運用機構が必要である。実運用 Grid としての NAREGI には、Grid ミドルの開発だけではなく、大規模な広域分散システムの管理機構の開発も同様に期待したい。

4.2.4.5.

現在の CSI グリッド環境（9 センターと国立情報学研究所）

国立情報学研究所の管理ノードを中心とした 9 機関の演算ノードの内訳を表 4-2-4 に示す。
表 4-2-4：CSI グリッドの演算ノード群（平成 21 年 9 月現在）
機種名

OS

北海道大学

HITACHI HA8000
DELL PowerEdge R200

CentOS 5

東北大学

NEC SX-9

SUPER-UX
ver18.1

筑波大学

Appro XtremeServer-X3

RHEL 5東京大学

HITACHI HA8000-tc/RS425 RHEL 5

東京工業大学 Sun Fire X4600

名古屋大学

分離型／
一体運用型
分離型
PBS Pro930 ノード(約 60CPU)
一体運用型
NQSⅡ ver2.50
Job
Manipulator 最大 4 ノード
ver1.20(64CPU)
一体運用型
Grid Engine
最大 32 ノード
(512CPU)
分離型
日立 OSCNQS
8 ノード
または独自ｲﾝｽﾄｰﾙ(128CPU)
スケジューラ

演算性能(GFLOPS)
638.4

6,553.6

4,710.4

1,177.6

SLES 9Sun N1 Grid Engine(2008/10
一体運用型
6.1
SLES 10 SP2 に東工大ｶｽﾀﾏｲｽﾞ版 未定
移行)

Fujitsu
CentOS 5.2
PRIMERGY RX200 S3/S2
Fujitsu
Solaris 8
PRIMEPOWER HPC2500

PBS Pro9.1

6 ノード(12CPU)

Parallelnavi 2.3

2 ノード(64CPU)
分離型
4 ノード(64CPU)

490.8

京都大学

Fujitsu HX600

RHEL AS 4

Parallelnavi 3

大阪大学

NEC SX-8R

SUPER-UX
ver17.1

NQSⅡ ver2.40
Job Manipulator

NEC SX-9R

SUPER-UX
ver18.1

NQSⅡ ver2.50
Job Manipulator

－34－

一体運用型
最大 8 ノード(64CPU)
一体運用型
最大 8 ノード(128CPU)

588.8

16,896.0

九州大学

NEC
Express 5800/120Rg-1

SLES 10.1

NQSⅡ ver2.40
Job Manipulator

一体運用型
最大 32 ノード
(128CPU)

Fujitsu
PRIMERGY RX200 S3

RHEL WS 4

PBS Pro9.2.2

分離型
576.0
12 ノード(48CPU)
合計

31,631.6

4.2.5. おわりにNAREGI ミドルウェアは、過去に進められた 2 つの大がかりなプロジェクト「超高速コンピュータ網形成プロジェクト」および「最先端・高性能汎用スーパーコンピュータの開発利用プロジェクト
NAREGI プログラム」の成果物として誕生したものである。これに投じられた資金と労力を無駄にしないために、NAREGI をできるだけ活用する形でわが国にグリッドコンピューティング環境を構築することが望ましい。
一方、7 センターを含むわが国の計算機センター群は、米国や欧州でグリッドコンピューティングの気運が高まるよりずっと以前から学術研究のための計算基盤を支えてきており、その運営にあたってさまざまな工夫と努力を重ねてきた。その結果、これらのセンターが擁する大規模計算機システム
は、NAREGI ミドルウェアの開発者があまり想定していなかったような、NAREGI には必ずしも都合のよくない運用形態や課金制度を持っていることも多い。また、NAREGI の運用を継続するためには、実用規模の CA の運用など、開発フェーズとは異なる新たな人的資源が必要となることもわかってきている。
NAREGI を今後の全国共同利用情報基盤センター群のサービスの中に位置付けていくためには
まださまざまな困難があるものと想像するが、グリッド環境の持つ利点をユーザに提供できるよう、
今後も一層努力していきたい。
参考文献：[1] 国立情報学研究所リサーチグリッド研究開発センター：http://www.naregi.org/[2] グリッド配備・運用タスクフォース：http://server-500.cc.kyushu-u.ac.jp/csi-grid/[3] T. Kobayashi, R. Mibu, J. Ooba, T. Takami, J. Maki, R. Nogita, M. Aoyagi, “ A New
Concept for Constructing HPC environment — packaging the NAREGI grid middlewareby apt-rpm — ”, Proc. HPCAsia07, (2007) , 249-250[4] 国立情報学研究所リサーチグリッド研究開発センター：「NAREGI Middleware Version 1.1.3
リリースノート」、http://middleware.naregi.org/Download/Docs/ReleaseNotes-j.txt 2009年 3 月．
添付資料 ・・・第 4 回会合（2008 年 9 月 18 日）報告
1

2

ＮＡＲＥＧＩプロジェクトの目的と当初計画
１）100テラフロップス級の世界水準の高速グリッドコンピューティング環境を構築する国際水準の基盤ソフトウェアを開発する。

NAREGIに関する話題提供

２）その環境を活用し、ナノ分野と情報通信分野との異分野間の融合領域の研究の加速、産学官連携の推進を図り、先端科学技術の研究や製品開発
プロセスを革新し、わが国の国際競争力を強化し、大きな経済効果を得る。

- NAREGIのこれまでと今後-

平成 15年度

平成16年 度

平成 17年 度

平 成18年 度

評価

実証

平成 19年 度

平 成20年 度

当初研究計画研 究開 発情報基盤研究開発センター

要素技術のプロトタイプ開発

ﾅﾉｻｲｴﾝｽで評価

２）α版 の研 究開 発３）β版 の研 究開 発４）統合 1.0版の研究開発

ＳＳ研 Grid Computing 検討WG, 2008.09.18

α版

分子研 評 価

公開

△

青柳 睦

ＳＳ研 Grid Computing 検討WG, 2008.09.18

－35－

β版

分子研 評価NAREGIﾐﾄﾞﾙｳｪｱ
Ver. 1.0

評 価・実証成果 活用
大学・国公立研究機関の技術をスムーズに民間移転できる実用的な仕組み

１）プロト タイプの 研究 開発

中間評価

九州大学

高 度化・強 化

4

3

プロジェクト期間中の状況変化

NAREGIプロジェクトの研究開発体制

１） 東工大TSUBAMEをはじめ、情報基盤センターに１００テラフロップス級の文部科学省 / 理化学研究所
連 携

リサーチグリッド研究開発センター
スーパーコンピューティング技術産業応用協議会（情報・システム研究機構 国立情報学研究所）

研究顧問委員会

２） EGEE、Teragrid、UK e-Scienceなどの運用経験から、グリッドは研究環

研究開発リーダ：三浦教授

境としての位置づけが重要であることが分かってきた。
グリッドミドルウェア
研究開発

グリッドミドルウェア
統合・運用

・グリッド環境における資源 管理
・グリッドプロ グラミング環境
・グリッドアプリ ケーション環境
・データグリッド 環境
・ネットワーク環境・ﾅﾉｱﾌﾟﾘ ｹｰ ｼｮﾝのグリッド 化対応
・グリッドミドル の利活用技 術

・N AREGIグリッド ミドルウェ アの統合 ・配布・グリッ ド基 盤ソフトウェ ア
研究開 発システ ム運用
・N AREGI認 証局運用
（AP Gri dPMA 連 携）
・N AREGI テ ストベッド運用支 援

共同研究

国際連携

・EGEE
・UniGridS・TeraGrid
・OGF etc.

する次世代スーパーコンピュータの開発プロジェクトがスタートした。

（CSI）

運営委員会
東工大、九大阪大、九工大産総研、
原子力機構
富士通、日立日本電気

計算資源が設置されるようになり、さらに１０ペタフロップスの性能を目標と

学術情報
ネットワーク運営・連携 本部連 携・研究コミュニティーとしての仮想組織：VO（Virtual Organization）

７大学情報基盤センター、KEK、
天文台等

連 携

・計算資源、大規模データ利用の平準化

利 用

３） 国立情報学研究所を中心に最先端学術情報基盤構想（サイバー・サイエ

SINET 3

ンス・インフラ）がスタートし、NAREGIミドルウェアが重要な要素技術の

連 携

ITBL

ひとつとして位置付けられた。
連 携（実証・評価・ナノVO）

東大物性研
東北大金研
京大化研
産総研
KEK物構研

共同研究

連 携・公募研究

分子科学研究所

４） グリッドの世界標準仕様がWSRF（Web Service Resource Framework）
をベースに固まってきた。

ＳＳ研 Grid Computing 検討WG, 2008.09.18

ＳＳ研 Grid Computing 検 WG, 2008.09.18
討

5

6

修正後の研究開発経過
平成 15 年 度

平 成 1 6年 度

平 成 17 年 度

平 成 1 8年度

評価

実証

研 究 開発要 素技術 のプ ロトタ イプ開発

ﾅﾉｻｲｴﾝｽで評価
α版
O GSA プ ロ トタイ プ

平成1 9年 度

平 成 20 年度

計算科学をサポート １）予約によるジョブ実行によるアーキテクチャの異なる

高 度 化 ・強 化

中間評価

研 究 の 推移

NAREGIミドルウェアVer.1.0の主要機能
計算資源間での連成解析
２）バルクジョブ実行
３） GridMPI、GridRPCの組み込み
４）資源管理と連携したデータグリッド

事 後評価 委員会△

分 子研 ・7セン ター
等 評価

①

β版

した 仕 様へ 変 更（ OGS A/WS R F）

研究コミュニティーをサポート

分 子研 ・
7センタ ー等 評価

国 際連携 実証②

当 初 の 最 終版 の 機能 ＋
研 究 環境 に対 応 し た機 能

制分子 科学研究所による実証評価

・ナノ実証研 究・大規 模実証β版‐Ⅱ（ OGS A/WS R F）

用対応の
③ 運
機 能 を追加
体

追加機能
追加機能

公開

△
WSRFに対 応

ベータ版からの利用環境の高度化・平準化

5月）
NAREGIﾐﾄﾞﾙｳｪｱ 公 開（予定Ver. 1.0△

１） VO（Virtual Organization)単位のサービス
２） VO管理に必要なアクセス管理・制御・管理機能設定

追加機能
追加機能

３） ITBLとの連携ミドルウェア

追加機能１）ポータルにより平準化された利用環境
２） GUIによる計算資源を意識しない操作、利用追加機能３）適合した計算資源の自動選択
４）コマンドラインインターフェイスによるジョブ実行

追加機能

１)計算資源利用効率向上
予約ジョブ実行と非予約ジョブ実行の両立等
２）管理者支援機能

追加機能
追加機能
追加機能

３）グリッドジョブとローカルスケジューリングジョブの共存
４）インストール・運用性の向上 （Installer + APT/RPM）

追加機能
追加機能

・ナノ分 野によ る分 野別 研究 機関で の 運用 評価④

阪大 ・東工大
連 携運用

データグリッド研究開 発グループを新設

運用をサポート

グリッド作 業部会 設立（2006/06)△
グリッド作 業部会メンバーの評 価
・情報 基盤センターでの運用に必 要な機 能等の 評価

グリッド作業部会メン バー等に順次 導入

ＳＳ研 Grid Computing 検討WG, 2008.09.18

ＳＳ研 Grid Computing 検 WG, 2008.09.18
討7

計算資源、分散した大規模データを意識せずに利用計算・研究資源をどこからでも同じように使える平準化された環境

WP6：ナノテクシミュレーションのグリッドへの対応

B 研究所

WP2:
WP3：グリッドﾞ可視化
WP3：グリッド PSE
グリッド
WP3:グリッドワークフロー
プログラミング
WP1:・グリッドRPC
・グリッドMPI WP1:スーパースケジューラ 分散情報サービス

C 大学

WP4：

デ ータ
グリッド

ポータル
A 大学

8

NAREGIグリッドミドルウェアの構造

NAREGIミドルウェアVer.1.0による研究環境

ITBL→
NAREGI
移行ツール

WSRF（（NAREGI implementation + Globus 4）
WSRF
4）

D 大学

WP1：グリッドVM
バーチャルな研究コミュニティー
（VO)を容易に形成

WP5:ネットワーク通信基盤、性能評価、セキュリティ･認証

計算・研究資源を連携した研究が容易（リアルタイムコラボレーション）

仮想組織（Virtual Oganization）

SINET3

国立 情報学研究所

A 大学
D 大学

C 大学

分子 科学研究所

実組織

B 研 究所

共同 研究機 関

情報基盤 センター群

その他

計 算 資 源研究中のプログラムA

研究中のプログラムB

PSE: Problem Solving Environment (問題解決環境）
ＳＳ研 Grid Computing 検討WG, 2008.09.18

ＳＳ研 Grid Computing 検 WG, 2008.09.18
討

10

9

NAREGIミドルウェアVer.1.0の利用環境

NAREGIミドルウェアVer.1.0の展開例① PSE（Problem Solving Environment）

管理ノード

ポータルから Single Sign On・アプリケーションプログラムを適切な計算資源に登録・配置し、コンパイル。

② WFT（Work Flow Tool)
・利用するデータの取り込み、計算処理手順などをGUIアイコンの組み合わせにより設定。
・ジョブの投入、進捗のモニタ
・WETに組み込まれた処理要件に基づき、スーパースケジューラが計算資源を自動選択④ データグリッド③ グリッド可視化・グリッド環境でのファイルの配置・登録・共有ファイルシステムへの
インポート
・WFTと連携した計算処理へのデータの取り込み。

・グリッド上に分散した計算
結果を分散したまま可視化。

データノード計算ノード
ＳＳ研 Grid Computing 検 WG, 2008.09.18
討

計算ノード
ＳＳ研 Grid Computing 検 WG, 2008.09.18
討

－36－

12

11

グリッド実証アプリケーション一覧表

NAREGIミドルウェア実証評価体制
分子科学研究所での実証

情報基盤センターでの実証

分野別研究機関のモデルとして実施
１）2005年4月からα版で実証研究
２）2006年5月からβ版で実証研究
３）2007年6月からβ版-Ⅱで実証研究

情報基盤センターでの利用モデルとして実施
１）2005年11月からα版を限定配布により評価
２）2006年5月からβ版を公開配布により評価
３）2007年7月からβ版-Ⅱによる実証環境を
阪大、東工大に構築
４）2007年10月からグリッド作業部会メンバーに限定公開し、評価①メタコンピューティング、ハイスループッ
トコンピューティング、リアルタイムコラボ
レーションの実証研究を実施。
②22件のナノサイエンスアプリケーション
によるミドルウェア実証研究を実施。
NAREGIミドルウェアVer1.0への反映。

①認証ポリシーが異なるセンター間の相互連携②VO形成、相互の資源予約管理③運用関係の評価③ナノサイエンスVOの構築④ナノ設計実証公募研究による産学研究

KEK-NAOJ解析連携環境

５０テラフロップス規模の大規模実証実験を2008年3月に実施（大阪大学、東京工業大学、九州大学、名古屋大学、分子科学研究所、グリッド研究開発推進拠点）

全国７＋２大センター群での試験運用へ向けて2009年4月(予定)

1
2
3
4

MP2（GridMPI）
非断熱遷移（GridMPI）
熱力学的積分（GridRPC）
密度行列繰り込み群（GridRPC）

永瀬（分子研）那須（物構研）、石田（東芝）岡崎（分子研）遠山（京大）

5
6
7
8
9
10
11

双極子系の Ewald 和（GridRPC）
RISM-Replica 交換 MC（連成計算）
MD-MO（連成計算）
Gaussian 1000 本（バルクジョブ）
大規模 MD 可視化（可視化）
レプリカ交換 MC（GridMPI）
大規模 MD（GridMPI）

富田（物性研）平田（分子研）、岡本（名大）岡崎（分子研）、森田（東北大）
高棹（旭化成）
岡崎（分子研）岡本（名大）
兵頭（豊田中研）

12
13
14
15

有限要素法（GridMPI）
不規則系コンダクタンス（GridMPI）
トランスコリレイティッド法電子状態計算（GridMPI）
ALPS/parpack+looper（GridMPI）

市村（日立）
伊藤、井上（名大）常行（東大）藤堂（東大）

16 スピン系のツリー近似計算（GridMPI）
17 積分方程式を用いた第一原理量子輸送計算（GridMPI）
18 QMAS（GridMPI）

川島（物性研）小林（筑波大）石橋（産総研）

19
20
21
22

矢花（筑波大）宮本（NEC）
土田（産総研）高見（九大）

rtdft（GridMPI）
FPSEID（GridMPI）
有限要素基底の電子状態計算法（ GridMPI）
3D-RISM-FMO（連成計算）（旧７帝大系センター、東工大、筑波大、国情研グリッド研究開発推進拠点）
ＳＳ研 Grid Computing 検討WG, 2008.09.18

ＳＳ研 Grid Computing 検 WG, 2008.09.18
討

13

14

大規模実証実験環境の構成
大阪大学

RENKEI-Osaka

東京工業大学NII

KEK-NAOJ連携解析環境実証• 両研究機関に共通する大量データの解析環境の実
証評価実験• 両研究機関でNAREGIα版、β版を導入して評価• KEK-NII 連携テスト （平成19年10月）• KEK-NAOJ 連携テスト （平成20年3月）

VO1

IMS

NAREGI CA

Osaka Univ. Grid CA

GSIC-VOSRENKEI-Naregi

CA/RA

CA/RA

RA
U ser cert
Host cert
Portal133.1.65.1 34

UMS
VOMS

UMS/VOMS
210.146.75.240

Portal210.146.75.237

SS連携

SS
133.1.65.135

UMS/VOMS
pfg300 4

SS
210 .146.75.239

Portaladm5

UMS/VOMSSS
rcs png2008

IS-NAS
210.1 46.75.23 8

IS‐NAS133.1.65 .136

Portalpfg20 26

SS
ad m6

IS-NAS
png2009

GridVMS ch
dpca064
GridVMSchdpca128
GridVMSchdpcb064
GridVMSchdpcb128
GridVMSchdpcc128
GridVMSch
dpcd048
GridVMSch
dpcd049
GridVMSch
dpcd057
GridVMS ch
sr11k

IS‐CDAS
dpcd058

名古屋大学

IS‐CDAS133.1.65.137

内部 利用 p ortal /…/cdas

IS‐CDAS
png2010

IS‐CDAS210.146.75.232

IS ‐CDAS
png2011

CDAS /GVM‐S
vm130
GridVMSch
133.1.65.138

GridVMSch
133.1.65.139

GridVM Sch
133.1.65.140

GridVMS chnaregi 4.cc

Gri dVM Sch
ngrd1.cc

遊休(Linux)(Solaris)

GridVMSch
210.146.75.233

ジョブの投入結果の転送

KEK
NAREGI
Servers

vo1利用
Gri dVM
pbg2043

九州大学

Astro lib
(1GB)
Data 2.7GB

松岡 研内
GridVM
png3000

GridVMS &E
png1053

GridVM
png1051

GridVM Sch
dpc.kyushu

sng0001(sx)

png1054

Gri dVM
pfg1005(Linux)GridVM Engines

GridVM Engines

NAOJ
NAREGI
Servers

KEK:高ｴﾈﾙｷﾞｰ加速器研究機構

GridVM Engines

ＳＳ研 Grid Computing 検討WG, 2008.09.18

NAOJ: 国立天文台

ＳＳ研 Grid Computing 検討WG, 2008.09.18

15

16

これまでの目標と達成状況

KEK-NAOJ連携のテストベッド
ユーザ･ブラウザ

NAOJ Site

Compute nodes

KEK Site

Por talPortalPortalSS

SS

SuperSched

IS-NAS

IS-NAS
IS-CDAS

IS-CDAS

GridVM Eng

分子科学研究所による実証研究、情報基盤センター等による実証評価により、本プロジェクトで開発したミドルウェアで下記目標性能をほぼ達成したことを確認した。

ユーザ・ブラウザ

SINET3１）大規模な計算資源環境構築によるハイスループット処理
Private network

Infosys-NAS

192 .168 .2.101~

Infosys-CDAS

Gr idVM Eng

２）アーキテクチャの異なる計算資源を連携させた連成解析（メタコンピューティング）
３）100テラフロプス級のグリッド環境を構築する基盤ソフトウェア

GVM Ser

GridVM Ser

G ridVM ServMDS
MDSFireWall

AMS

AMS.
AMS

Gfarm
Gfarm

（運用中の総計１００テラフロップス級の計算センター（複数）から動員可能な資源を連携して評価）MetaData Serv
AccessManage

４）グリッドにより、計算資源を意識せずに利用でき、平準化した

Gfarm
Storage

DataGrid part
NAT/DNS

NAT/DNS

VOMS/KEK

UMS/VOMS

UMS/VOMS

利用環境
５）研究環境に必要な研究コミュニティーをサポートするVO形成

NAT/DNS

６）情報基盤センター等、研究環境での運用に対応した機能

Compute nodes

UMS/VOMS

Test VO: naokek
ＳＳ研 Grid Computing 検討WG, 2008.09.18

ＳＳ研 Grid Computing 検討WG, 2008.09.18

開発拠点
リサーチグリッド
研究開発センター（CSIの構築 ）その後の展開国際連携・貢献
国際連携・貢献

国立情報学研究所
国立情報学研究所
学術情報ネットワーク
運営・連携本部

18

17

NAREGIグリッド運用モデル （２００８～）（ミドルウェアの研究開 発）

R&D連携・運用連携

７センターのNAREGIミドルウェア導入へ向けた動き
７センターのNAREGIミドルウェア導入へ向けた動き

・EGEE
・TeraGrid
・DEISA・OGF etc

・平成20年7月17日臨時センター長会議（東大）
・平成20年7月17日臨時センター長会議（東大） グリッド研究会の再開を決定
グリッド研究会の再開を決定
・平成20年8月20日グリッド研究会再開（京大）
・平成20年8月20日グリッド研究会再開（京大） グリッド配備・運用ＴＦを設置
グリッド配備・運用ＴＦを設置
・平成20年9月17日グリッド配備・運用タス
クフォース開催（国情研）
・平成20年9月17日グリッド配備・運用タスクフォース開催（国情研）
９演算＋１管理サイトsの「ミニマム構成」「GOC CA」「ＳＩＮＥＴ３
９演算＋１管理サイト sの「ミニマム構成」「GOCCA」「ＳＩＮＥＴ３L3/VPN+Com」
L3/VPN+Com」

学術コンテンツ運営・連携本部

研究開発・
運用サポート

企画・運営連携
フィードバック

e-サイエンスコミュニティ
e-サイエンスコミュニティ
注）．ＶＯ名は 仮称

グリッド作業部会

GOC（ グリッド運用支援 組織） 運用拠点

認証作業部会
企画・運営
サポート
ネットワーク作業部会

・ミドルウェアの導入、運用、技術等支援
・認証局の運用・ＶＯ利用者管理・ユーザトレーニング
・ミドルウェア不具合のフィードバック 等

グリッド認証局の本格運用へ向けた動き
グリッド認証局の本格運用へ向けた動き

ペタス ケール
システムＶＯ
産業界プロジェクト対応VO

プロジェクト対応ＶＯ

大学・大学共同利用機 関ＶＯ（情報基盤センター群等）

分野別研究機関ＶＯ（IMS,AIST,KEK,NAO etc)

NAREGI
グリッドミドルウェア

・・OGF24
OGF24(平成
(平成20
20年
年99月
月11５日
５日-)-) LRA
LRA運用を含む
運用を含むIGTF
IGTFへの提案が認められたへの提案が認め られた

NAREGグリッドミドルウェアV1.1のソース凍結を正式決定
NAREGグリッドミドルウェア V1.1のソース凍結を正式決定

平成
平成20
20年
年99月
月55日グリッド研究開発拠点センター会議（ＰＳＬ会議）
日グリッド研究開発拠点センター会議（ＰＳＬ会議）
今後は、
今後は、
・オープンソースとしての健全な発展を支援する体制の検討
・オープンソースとしての健全な発展を支援する体制の検討
・グリッド研究開発センターも１つの重要なコントリビュータ
・グリッド研究開発センターも１つの重要なコントリビュータ
・今後、開かれた組織による・今後、開かれた組織によるV1.2
V1.2仕様策定と開発体制、成果認定プロセスの整備仕様策定と開発体制、成果認定プロセス の整備
Who
WhoisisNAREGINAREGIアーキテクト
アーキテクト??

I TBLコミュニティ VO

認証基盤システム
企画・整備・運用

ＳＳ研 Grid Computing 検討WG, 2008.09.18

ネットワーク・インフラ（
ネットワーク・インフラ（SINET3SINET3））

ＳＳ研 Grid Computing 検討WG, 2008.09.18－37－

ミニマム構成でも幾つかの課題がある( GridVM )９演算サイト＋１管理サイト（ＮＩＩ）から構成される「ミニマム構成」（案）まずは平成21年3月末までに、Single VO, Single SS, (DataGridはOpt.)の「ミニマム構成」で試験運用環境を構築することを目標とする。

GridVM /NAREGI ver1.1 supports:- CentOS 5.x（x86 32bit） ＋ PBS Pro9
- openSuSE 10.x（x86 64bit） ＋ SGE+PluS- AIX 5.2 ＋ corresponding. LL

北大、東北大筑波大、東大東工大、名古屋大
京大、阪大、九大

国情研

計算資源提供サイト(9機関）の選択肢 （課題１）A) 計算機環境をNAREGI がサポートする状態に変更する。ただし、その場合は、ベンダ提供のコンパイラやライブラリ類が動作しなくなる可能性があり、それに付随して利用しているアプリやファイルサーバへのアクセスも変更する必要が生じる場合がある。
B) GirdVMをセンターのベンダー提供運用ＯＳ＆ローカルスケジューラへ移植する。

ＳＳ研 Grid Computing 検討WG, 2008.09.18

ＳＳ研 Grid Computing 検討WG, 2008.09.18

ミニマム構成でも幾つかの課題がある( SINET3 )ミニマム構成でも幾つかの課題がある( 総合代理店？ )NAREGI ver1.x は多くのportを使用：（課題３） 従来の全国共同利用セン
ターにおける「利用申請→（審査）→アカウント作成→利用承認書発行→利用の開始／課金→利用の終了→
報告書」という業務フローをグリッド環境の時代に即した形に改定する必要がある。

計算資源提供サイト(9機関）↑↓ ネットワーク構成の選択 （課題２）
国立情報学研究所の管理サイト
A) 国情研設置のPortal のみをｺﾓﾃﾞｨﾃｨSINETに晒し、管理ノード群と各大学の演算サー
バーは SINET3 L3/VPN ま たはL2/VPN接続
する（９機関外からのデータの流れが大回りする）。

・申請時 「グリッドパック？」・対面認証 （ＬＲＡ運用）

LRAの運用課題もある

・各機関の審査条件、課金ポリシー調整・証明書(DN)⇔gridmap file ⇔UID

B) 全ＮＡＲＥＧＩコンポーネント間をｺﾓﾃﾞｨﾃｨ
SINETで接続 （Ｇｒｉｄセキュリティーについて別途、厳重な対策が必要）。

総合代理店方式の検討
コードシェア便方式の導入？
資源買上げ方式？

c.f. 阪大－東工大連携実験： G-NPLS 網
T2K Grid 連携 ： おそらく SINET3 L2-VPN
ＳＳ研 Grid Computing 検討WG, 2008.09.18

ＳＳ研 Grid Computing 検討WG, 2008.09.18

まとめ

７＋２＋１センター グリッド配備・運用計画Phase1（案）24• ＮＡＲＥＧＩプロジェクトの成果物としてのNAREGIグリッドミドルウェア
第１版（Ver.1.0)の開発とオープンソースによる一般公開
V1.1 (平成20年10月公開予定)をもって凍結→オープンコミュニティーにおける発展• これからの計算研究環境に不可欠な機能である仮想組織（VO) の開発によるサイバーサイエンスインフラへの足掛かりを提案• 大規模実証研究により、サイエンスグリッドとして情報基盤センター向け機能と分野別研究機関（例：分子科学研究所、KEK,国立天文台）向けの機能を有することを確認→今後、運用へ。
• 国際標準の準拠と貢献、海外の主要なグリッドプロジェクトとの連携による国際的なグリッドミドルウェアとして認知される。
• 認証を含む運用グリッドに向けての方向付けを確固たるものにIGTF準拠のＧＯＣ－ＣＡの実運用• 北大・東北大・筑波大・東大・東工大・名大・京大・阪大・九大・国情研、連携による全国共同利用環境への展開と少なくとも３つの検討課題
ＳＳ研 Grid Computing 検討WG, 2008.09.18

ＳＳ研 Grid Computing 検討WG, 2008.09.18

26

国際連携への取り組み
研究開発成果を国際標準仕様に反映する国際貢献により、NAREGIミドルウェア
普及および国際的なe-Science/グリッドインフラに貢献する基盤を形成。

以下、補足資料

１）OGF (Open Grid Forum)への標準化提案① 資源管理ミドルウェアの先進的な実装例としてNAREGI仕様を提示。
② GridRPC APIの仕様「A GridRPC Models and API for End-User
Applications」がOGF初の標準仕様として2007年9月に承認。
③ 認証局ソフトウェアであるNAREGI－CAがIGTF（International Grid Trust）
が定めた運用基準を満たす認証局に利用可能であり、国際連携に対応。
（サンディエゴ計算機センターのRocksRollにNAREGI-CAが採用される）④ グリッド 環境でのアプリケーション共有のための標準仕様をACS V1.0として纏め、世界で最初の参照実装を実現、 GridForgeにソースを登録し公開。
２）EGEE等との国際連携
OGFのGIN-WGにおいて、EGEEと連携してグリッド情報の相互交換・相互ジョブ
サブミッション・共有ファイルシステムへアクセス・双方向のファイル転送など、基本的な機能のインタオペレーションを実現。

ＳＳ研 Grid Computing 検討WG, 2008.09.18

ＳＳ研 Grid Computing 検討WG, 2008.09.18

－38－

28

27

人材の育成
１）人材育成対象者
・ポスドク（産学官連携研究員）

研究成果普及への取り組み
１）特許権等の出願状況
標準化への貢献・ソースコードのオープン化を迅速に行い、先鞭をつけること
によって国際的に優位性を保つことが重要であるとの戦略に立ち、特許によりそのような努力が阻害されないように留意しつつプロジェクトを推進。

： ３８名

・大学院・学部生（主要参画大学）： ５９名

・研究開発者（主要参画企業）：２６４名

２）製品化・企業化
１）企業では、研究開発成果のビジネス化・製品化を検討。
・NAREGI ミドルウエアVer.1.0をベースとしたミドルウェアビジネス
・NAREGIミドルウエアVer.1.0をベースとした分野対応のパッケージビジネス
・グリッドシステム構築ビジネス
・アプリケーション環境構築ビジネス
・グリッド構築・運用コンサルティングビジネス

・プロジェクト管理者（主要参画企業）： １３名
・運用サポートSE：１１６名

２）人材育成の育成方法① 国際会議、OGF委員会での活動による一流研究者の育成。
② IT企業に対する開発発注、技術検討会、チュートリアルによる先端グリッド

３）企業化の検討
・ASP(Application Service Provider)サービスの本格化
・データグリッド、センサー グリッドをベースとした新市場創設
・「知的ものづくり」関連の新ソフトウェア研究開発
・「知的ものづくり」に基づく新製造プロセス研究開発

エンジニアの育成。
③ α版、β版の試作ミドルウェアによる実証評価を通じた、運用管理に習熟した人材の育成。
④ グリッド実習講習会の開催によるグリッド環境利用者の育成

ＳＳ研 Grid Computing 検討WG, 2008.09.18

ＳＳ研 Grid Computing 検討WG, 2008.09.18

29

30

学術的成果

期待される効果
１）本研究開発に従事した人材が、今後も我が国の研究開発や関連する技術の製品開発、国際標準化に従事

我が国の研究開発、国際競争力の強化に貢献２）分子研等が独自に開発した優れた方法論にもとづいたアプリケーションのグリッド対応化、連成化を世界に先駆けて実施

計算科学、情報科学両分野での我が国の研究開発の強化に貢献

３）情報研、分子研の先端的な研究者・技術者
による異分野間の技術交換と共同作業

大学だけでは人材育成が困難なHPC分野で活躍を期待できる計算科学者の育成

４）本プロジェクトで大学関係者97名を育成

今後情報基盤センター・各研究機関でのグリッド環境活用・運用の大きな戦力

５）本プロジェクトで企業関係者393名を育成

学 術活動の 成果１（ 学術論 文・総説解説）

平成15年度

平成16年度

平成17年度

平成18年度

平成19年度

学術論文

３件

７件

２５件

１９件

４２件

総説解説

―

６件

―

―

１件

学 術活動の 成果２（ 研究発 表・講演 ）今後グリッドを研究環境として展開・運用に向けて不可欠な企業側からのサポートの大きな戦力

ＳＳ研 Grid Computing 検討WG, 2008.09.18

平成15年度

平成16年度

平成17年度

平成18年度

平成19年度

招待講演(国内)

２０件

２８件

２８件

１５件

２３件

招待講演(国際)

１６件

２７件

２２件

１９件

１６件

口頭発表(国内)

２１件

２３件

１６件

３１件

３５件

口頭発表(国際)

１０件

１８件

１２件

１９件

１９件

受賞等

―

２件

３件

ＳＳ研 Grid Computing 検討WG, 2008.09.18

31

32

メディアへの情報発信、および新聞報道の実績

プロジェクト外部との関係・関連事項

１）新聞報道等への情報発信① 2003年7月にプロジェクト開所式にあたり記者会見を実施② 2004年11月日刊工業新聞と共催で最新情報戦略フォーラムを実施③ 2004年、2005年2006年、2007年のNAREGIシンポジウム開催に際してメディアを招請④ 2006年5月にNAREGIミドルウェアβ版公開に当り、記者会見を実施⑤ 2008年5月にNAREGIミドルウェアVer.1.0の公開に当り、プレスリリース

国内プロジェクトとの関連
ビジネスグリッド：初期の段階での技術交流
バイオグリッド：データグリッドを継承
ITBL：ワークフローGUIの共通化、ITBL⇒NAREGI連携ソフトの開発
海外プロジェクトとの関連
UNICORE （ドイツ）：α版にてUNICOREミドルを使用
EGEE （EU)： OGFのGIN-WGで相互連携のデモを実施
DEISA （EU)： 技術交流、NAREGIスケジューラを提供予定
TeraGrid （米国）：相互連携に向けて技術交流。
Globus （米国）：β版、V1.0 にてGlobus Toolkitを使用
Condor （米国）: α版で連携ソフトを開発
Grid5000 （フランス）：NAREGI成果を用いてのネットワーク計測

２）Webでの公開
和文：http://www.naregi.org 、英文 http://www.naregi.org/index_e.htmlのホームページを公開し、活動内容、資料を公開
３）広報活動の取り組み① NAREGIシンポジウムを毎年開催し、講演、デモンストレーション、展示② 活動内容、研究目的をまとめたリーフレットの作成（研究の進捗に合わせ4回更新）と配布。
③ 国内、海外の学会、展示会での講演・デモンストレーション・展示の実施
例：グリッドワールド、Supercomputer and Networking Conference(SC)ＳＳ研 Grid Computing 検討WG, 2008.09.18

ＳＳ研 Grid Computing 検討WG, 2008.09.18－39－

4.3. 研究コミュニティ形成のための資源連携技術に関する研究報告
報告：国立情報学研究所リサーチグリッド研究開発センター）三浦謙一
このプロジェクトは研究室に設置される計算機やストレージ等(LLS：Laboratory Level System)から計算機センター等に設置される計算機やストレージ等(NIS：National Infrastructure System)に至るまでの資源上で提供される、計算能力・データ・データベース・アプリケーションなどを必要性に応じて柔軟に共有または連携させて e-サイエンスを実現するための基盤技術を確立するための、国際標準に準拠したソフトウェアの研究・開発を行うものである。
e-サイエンスは、計算機やデータ等の資源とユーザからなる研究コミュニティを柔軟に形成するための新たな研究基盤であり、NAREGI 等で開発された計算の連携や、データの連携を仮想組織(VO)を用いて実現するグリッドは、e-サイエンスを実現するための鍵となる技術として期待されている。
このプロジェクトは国立情報学研究所を代表機関とし、既に NAREGI グリッドミドルウェアの開発で得られた実績と経験をベースとして、5 つのサブテーマについて研究開発が進められている。サブテーマ(1)は計算連携技術に関する研究で、国立情報学研究所、玉川大学、富士通株式会社が実施する。サブテーマ(2)はデータ共有技術に関する研究であり、大阪大学と筑波大学が実施する。サブテーマ(3)はデータベース連携技術に関する研究で産業技術総合研究所が研究を実施する。サブテーマ(4)はマルチグリッドミドルウェア環境下でのアプリケーションインタフェースに関する研究で、高エネルギー加速器研究機構が研究を実施する。サブテーマ(5)は実証評価・ユーザ連携であり、東京工業大学が他大学の情報基盤センターからの協力のもと、実証評価を行うとともに、実証評価を通して得られたユーザからの要求を開発へフィードバックする。なお開発に際しては当初からエンドユーザとしての研究者層のニーズを十分に反映できる体制になっている。
なおこのプロジェクトは文部科学省の「e-サイエンス実現のためのシステム統合・連携ソフトウェア
ソフトウェアの研究開発」の一環として行われている。
添付資料 ・・・第 5 回会合（2009 年 1 月 21 日）報告
1
次世代ＩＴ基盤構築のための研究開発：「e-サイエンス実現のためのシステム統合・連携ソフトウェアの研究開発」
NII:1.46億円，東大：1.58億円

研究コミュニティ形成のための資源連携技術に関する研究
２００９年1月２１日
研究代表者
国立情報学研究所
リサーチグリッド研究開発センター
教授 三浦 謙一

－40－

3

背景と目的

科学技術・学術研究の基盤となるスパコンネットワークの構築 e‐サイエンス

次世代スパコン
次世代スパコン
世界のグリッドと繋がる

 計算機やデータ、ユーザ等からなる研究コミュニティを柔軟に形成することにより実現する新たな科学技術研究手法

大規模データを扱う計算を得意とするスパコン
［ＮＬＳ］

EGEE

大学・研究機関のスパコン
大学・研究機関のスパコン

 e‐サイエンスの実現

主に中規模データを扱う計算を得意とするスパコン ［ＮＩＳ］

TeraGrid 単一のグリッドによる研究基盤とコミュニティの形成からさらに発展の段階へ

スパコンを中核としたネットワークによって、様々な規模のスパコンの各々が連携しながら計算を行えることで、我が国の計算資源を効率的に利活用することができる。

 運用形態の異なる資源間の連携が新たに必要。

ルー プ 化を 図る

 研究室レベルの資源と情報基盤センターレベルの資源の連携
 異種グリッドミドルウェア 間の連携

： 1G～ 10 G
： 10G
：2 0G～ 40G

学術情報ネットワーク

目的
研究室の資源（LLS）、情報基盤センターの高性能資源群（NIS）、
異種グリッドミドルウェア上で提供される計算、データ、データベース等を柔軟に共有・連携させ、仮想研究コミュニティを形成しかつ運用するための基盤技術を確立する。

研究室レベルのシステム研究室レベルのシステム

主に小規模データを扱うＰＣ及びＰＣクラスタ [ＬＬＳ]

ユーザが日頃使用しているＰＣ及びＰＣクラスタ（ＬＬＳ）から大学・研究機関のスパコン（ＮＩＳ）、
さらには次世代スパコン(ＮＬＳ)へと気軽に利用できる環境を実現する。

安心して研究教育に専念できるシームレスな研究環境の完成
４

ＮＩＳ：Ｎａｔｉｏｎａｌ Ｉｎｆｒ ａｓｔｒｕｃｔｕｒｅ Ｓｙｓｔｅｍｓ， ＬＬＳ：Ｌａｂｏｒａｔｏｒｙ Ｌｅｖｅｌ Ｓｙｓｔｅｍｓ

e-サイエンス実現のため のシステム統合・連携ソフトウェアの研究開発

次世代計算研究環境としてのグリッドの展開
ペタスケール
計算環境

情報基盤センター
グリッド

分野別研究機関グリッド

NAREGI
グリッドミドルウェア

計算アプリケーションユーザ

データベースユーザ

サブテーマ(1) 計算連携
目的：研究室レベル・情報基盤センターレベル間でのシームレスなジョブ実行技術に関する研究
H20年度計画：•ワークフローシステムの検討，プ
ロトタイプ設計および実装着手•異種グリッド環境間の相互運用
アーキテクチャの検討，プロトタイ
プ設計および実装着手•アプリケーション共有方式検討，
プロトタイプ設計

サブテーマ(3) データベース連携
目的：異種データベースの連携・統合，ユーザ認証情報の管理技術に関する研究
H20年度計画：•データベース連携・統合ミドルウェ
アの設計，実装方法の検討•ユーザ認証情報管理ツールの設計，プロトタイプの実装

サブテーマ(4) ア プリケーションインタフェース
目的：異種グリッド環境下でのアプリケーション
開発者向けインタフェースに関する研究
H20年度計画：•要素技術およびユースケース調査
•設計着手

DB

DB

DB

海外との
インターオペレーション

グリッドミドルウェア

国際連携（GIN,EGEE, Teragrid et c.)6

ア プリケーション開発者

研究室
情報基盤センター群研究室レベル
クラスター

学内計算資源分野 別研究コミュニティ（１）計算連携技術に関する研究

ア
プ
リ
ケ
｜
シ
ョ
ン
研
究
者
層

ニ ーズ

（３）データベース連携技術に
関する研究

開発

8

（２）データ共有技術に関する研究開発（４）マルチグリッドミドルウエア
環境下でのアプリケーションイ
ンタフェースに関する研究(2)データ共有技術

基本設 計

プロトタイプ実装
・評価(3)データベース
連携技 術

プロトタイプ実装着 手(5)実証評価 ・
ユーザ連携

フィードバック

東京工業大学・松岡聡

実証評 価基盤構
築・計測評価技術
開発
LLS・NIS計算資源調査，ユーザ開拓
着手

協力

情報基盤センター群
テストベッドインフラ

H22

H23

詳 細（機能）設計

機能強化

実証評価

実証評価

品質向上

システム実装（５）実証評価・ユーザ連携

フィードバック

H21(4)アプリケーション
インタ フェース

KEK
・佐々木節

筑波大学
・建部修見

研究

H20

開発
産総研
・関口智嗣

開発

計算／データグリッド
アプリケーションユーザ

(1)計算連携 技術

富士通
・金澤宏幸

大阪大学
・松田秀雄

グリッドミドルウェア

総合開発スケジュール

研究代表者
国情研 三浦謙一

国情研・合田 憲人NII CSI委託事業

DB
サブテーマ(2 ) データ共有
目的：研究室レベル・情報基盤センターレベル間，異種グリッド環境下でのデータ共有技術に関する研究H20年度計画：•研究室レベル・情報基盤センター
レベル間の分散ファイルシステムの設計，基本機能の実装．
•異種グリッドミドルウェア環境下のファイルカタログシステムの基本機
能の開発

7

実施体制

玉川大学
・宇佐見仁英

情報基盤センターユーザ

サブテーマ(5 ) 実証評価・ユーザ連携
目的：実証評価基盤の構築，情報基盤センターおよびエンドユーザと連携した実証評価H20年度計画：•事前実証評価環境の構築および計
測評価技術の開発•研究室レベル・情報基盤センターレベル間でのデータ共有技術に関する
事前評価

国情 研
運用支援 組織（ GOC)

予算

１．６４億円9

実 証基盤仮運用
ユーザ開拓拡張

実証基盤拡 張・運用

実証評価 および
実 証評価および開発へのフィード
開 発へのフィードバック
バ ック

１．４６億円？

運用レベル実証評
価および開発へのフィードバック
ユーザ利用促進？

計算連携技術に関する研究
 背景
 従来のグリッドコンピューティングの限界→異なる運用形態の計算資源にまたがった計算を実行できない．
 研究室レベル（LLS），基盤センターレベル（NIS），異なるグリッドミドル
ウェア

サブテーマ1
計算連携技術に関する研究 目的

国立情報学研究所，玉川大学，富士通

 研究開発項目

 運用形態の異なる計算資源間のシームレスな計算（ジョブ）実行を実現し，計算資源を効率的かつ柔軟に活用する．
 ワークフローシステム
 LLS，NISに対するシームレス なジョブ実行の実現

 異種グリッドミドルウェア間インタオペレーション
 異種グリッドミドルウェア間でのシ ームレスなジョブ実行の実現

 アプリケーション共有方式
 LLS，NISにまたがった計算資源間でのシームレスなアプリケーション
共有の実現

－41－

10

11

ワークフローシステム

12

異種グリッドミドルウェア間インタオペレーション

 目的

 目的

 LLSとNIS（NAREGI）間のシームレスなジョブ実行

 異なるミドルウェアにより運用されるグリッド間（NAREGI－gLite）での相互ジョブ実行
 国際的なグリッドインタオペレーションの実現

 利用例Pre/Post処理は研 究室計算機、計算はNAREGI資源

 方法

 研究室ジョブのジョブ要件記述、ジョブ間のワーク フローの記述に関して
NAREGIと同様のGUI記述によるシームレスな指定
 研究室ジョブに関してはローカルスケジューラに投入，NAREGIジョブに関してはNAREGIシステムに投入を行いジョブのモニタリングを行うワークフ
ロー制御
 研究室・NAREGI間のデータの連携として、サブテーマ２の広域分散ファイ
ルシステ ムが利用可能
GridSAM(Globus-SGE) 方法
 NAREGI・gLite間のジョブ実行連携の実現
 NAREGI (SS) → gLite (lcgCE)
 gLite (WMS) → WS GRAM
 GridVMを経 由しない負荷情報とUsage Record収集

 国際標準インタフェース（BES）経由のジョブサブミッション
 BESの動向を見ながら開発

Laboratory - A
Local Resources

海外とのインターオペレーション

for VO1+ Lab-AWF engine

WFT

AHS

SS Client API

PortalSuper Scheduler

PortalServer

NAREGI-WFengine

NAREGI-VO1
SS server

NAREGI

GridVM

gLite

GridVM研究室

11

システム概念13

アプリケーション共有
 目的

14

Clients ( End Users)

 研究コミュニテ ィ、あるいは研究グループで共有したい知の集積としてのアプリケーションをLLS とNIS の異なった運用環境において、統一的に共有・管理する使い勝手の良いAHS（Application Hosting Service）の方式と実証に関する研究を実施する。
仮想組織（Virtual Organization）
グループ単位の管理
VO１
V O２

V O３
アプ リ
開発者

アプリ
利 用者

A 大学
D 大学

B大学

C 大学

NIS
Grid

LLS
Grid

NAREGI Portal

Application
Developers’
Tools (ＫＥＫ)

UK e-Sci . AHE 等

AHS ＰＳＥ

国際的軽量級ミドルアプリ開発者は、研究コミュニティ
で利用可能なNIS、LLS資源にア
プリケーションを配置（赤線）しておく。アプ リ利用者は、例えば、
小規模解析ならLLSで、大規模な場合はNIS資源でとのように適時使い分けて同じアプリケーション
を同じ操作環境で実行（緑線）することができる。解析のための実験データ等は、データ共有機構
によりコミュニティの中で仮想的に統合管理（青線）されているので、特に意識する必要が無く解析実験が出来る。

拡張
ＷＦＴ

WFT

SAGA/JSAGA

SchemaNAREGI SS/IS Translator

GridSAME GEE/gLite

BES Client

globuscondor

SGE

OSG/
VDT

LLS
BES I/F
LLS
Resources

GridVM

NAREGI
Resources

Int eroperation with
Other Grids

NIS

広域分散ファイルシステム

国際共同研究コミュニティ

データ共有
/DB共有

File
ServerFil e
Se rver

Fi leServerStorage

Stor age

Storage凡例
本プロジェクト

NAREGI

Others1615

データ共有技術に関する研究
研究の背景
実験技術やITの進歩により、研究室レベルで大量データが発信→ データが広域に分散しているため利用が困難

サブテーマ2
データ共有技術に関する研究

研究方針
次の２つのアプローチで研究を進める
1. 広域分散ファイルシステムに関する研究 建部修見（筑波大学）（目標）国内に散在する研究データに対して、どの場所からでも効率的にアクセスできる（研究項目）ファイル複製の配置によるアクセスの効率化・耐故障性向上

大阪大学，筑波大学

2. ファイルカタログシステムに関する研究 松田秀雄（大阪大学）（目標）海外で運用されている異種グリッドミドルウェア上のデータを共有（研究項目）ファイルカタログの標準化と異種グリッドミドルウェア間での相互運用

広域分散ファイルシステムに関する研究

18

17

ファイルカタログシステムに関する研究

本研究参画者は、高エネルギー分野での大容量実データに対して、効率的な 分
散ファイルシステムの構築実績を持つ(SC2006 ストレージチャレンジ 優勝）
この技術をベース にして、最適な複製の自動配置技術を新規に開発することで、広域に分散したどの場所からでも同等のアクセス性能でのファイル共有を実現
重要な研究データの自動複製による耐故障性技術の開発

ファイルカタログ：ネットワーク上で分散したデータの位置を管理する仕組み［問題点］グリッドミドルウェアごとにインタフェース が異なるため相互運用が困難［本申請］OGFの国際標準であるRNS(Resource Namespace Service)に基づくファイ
ルカタログシステムを構築
OGFにおける標準化は、本研究参画者が主導で策定中→ミドルウェアの異なるグリッド間で、フ ァイルカタログの国際的な 相互運用を実現

クライアントクライアントクライアントクライアントOGFの WGで、gLite 開発グループ、 SRB 開発グループ等と共同で 相互運用インタフェースを開発中

クライアントクライアントファイル(1) ファイルの 問合せ

仮想的な分散共有ファイルシステム
仮想的な分散共有ファイルシステム
最適な複製の 自動配置
ファイル
ファイル
サーバ
サーバ11
ファイル
ディスク
ディスク 複製装置
装置

クライアント

ファイル
ファイル
サーバ
サーバ22

ファイル
ファイル
サーバ
サーバ33

ファイル
複製 ディスク
ディスク
装置
装置

ファイル
複製 ディスク
ディスク
装置
装置

ファイルカタログシステム(2)ファイルの 位置を返答(3) データへの
アクセス

－42－

ヨーロッパ

アメリカ

日本

gLiteファイルサーバ

SRBファイルサーバ

広域分散ファイル
システム

20

19

データベース連携技術に関する研究（１／３）


背景



目的







地 球科学分 野、バイオ分野 、高度医療 情報分野、天 文分野な ど、取 り扱 うデータが大規模で 分散 配置されたデータベース を連携 して 扱う 必要のある 分野は多岐 にわ たる 。異な るデータ格納方法 、アクセス方 法、ス キーマ、データポリシな どが混 在した
データベース 群を扱う 技術は確 立されていな い。
分 散環境で の異種 多様な データベース を、簡 便かつ統一したインタフェースで 安全に連携させる 技術を開 発し、上記分野 等
様 々な 分野における 潜在的な 多数 のユーザに対してe‐サ イエン スの利 用を推進 し、 科学技術の 発展に貢献する 。

応用例


複 数のデータベース連 携による地 滑り予 測

サブテーマ3
データベース連携技術に関する研究

AMEDAS 等による
雨量データ

地質データ

産業技術総合研究所

ハザードマップ作成

MET

GEO
ASTER

衛星データによる
高解像度標高モデル

複数データベースからの情報と高性能計算機を用いた大規模
地滑りシミュレーション
22

21

データベース連携技術に関する研究（２／３）


データベース連携技術に関する研究（３／３）

内容

 詳細

１． 異種 の分散データベースを連携・統 合するミド ルウェアの研究 開発【特徴】
・ 分散 統合を含む データベース 統合処理 を可能とする。
・ W ebDBやR DFに加え 、全文検 索エ ンジ ンもデータソース として取り込むな ど、 異種多様な ソース を結合する 。
・ エ ンドユーザ や応用プ ログラムに対して簡 便なイ ンタフェース を提供 する。
２． ユーザ 認証情報生 成管理技術 の研究【特徴】
・ データベースへの アクセス 制御の基礎 とな るユーザの 認証情報 を簡便かつ様 々な手 段で生 成・管理する 。
・ ユーザ名・パスワードによる、OpenIDをベースにする、手持ちのユーザ証明書を用いる、など。

エンドユーザや応用プ
ログラムに対して簡便なインタフェースを提供
する

Query
宣言的な言語（SQL
宣言的な言語（SQLやSPARQL)で複数のＤＢを連携•ＤＢのＤＢの異種性（全文検索やＲＤＦ)を吸収する機能•分散
分散処理の実行順序の（動的な）最適化機能

認証情報を簡便かつ様々な手段で生成・
管理する

user

分散環境における異種多様なデータベー
スを連携・統合する

１． 異種の分散データベースを連携・統合するミドルウェアの研究開発

分散統合を含む
データ ベース統合処
理を可能とする

Ａ

認証情報

OGSA‐‐DQP
OGSA

OGSA‐ DQP

OGSA‐WebDB

DIP
DIP

STRINGXMLXML DBs
DBs

RRelationalelational DBs
DB s

Swissprot
W eb DBsWeb

２． 多様なＩＤからグリッド 認証情報の生成

RDB

XMLDB

WebDB

RDF

関係（Ｒｅｌａｔｉｏｎａｌ）
データベース

ＸＭＬデータベース

Ｗｅｂ上で検索可能なデータベース

セマンティックＷｅｂのデータ ベース

１．
２．
３．
４．
５．

検索
エ ンジン
Ｇｏｏｇｌｅ，Ｙａｈｏｏなど

OpenID
Shibboleth
Kerberos
Usernam e/password
PKI (X.509 certificates)

それぞれの認証認可システムに対応したそれぞれの認証認可システムに対応した動的な証明書の生成と動的な証明書の生成と統合的な管理統合的な管理24

23

研究開発の動機と目的
 動機
 KEKでは、複数のグリッドミドルウエアを実際に運用し、アプリケーションのグリッド化を行って おり、利用者の立場から、異ミドルウエア混在環境
におけるグリッドアプリケーシ ョン開発の効率化の必要性を強く感じている

サブテーマ4
マルチグリッドミドルウエア環境下でのアプ
リケーションインタフェースに関する研究 目的
 我が国で開発されたアプリケーションの世界への普及
 同一アプリケーションソフトウエアを、複数のグリッドミドルウエア 環境で利用可能にするためのAPIの開発を行う
 グリッド 環境のない大学研究室も 含めて、世界的に共同して行うeScienceに参加していくための基盤を創る
 ワーク フローが複雑でプログラム 言語やスクリプト言語による条件分岐の記述が必要な分野向けのユーザ環境を開発する
 研究室と複数のグリッド上の資源（計算機、データなど）をシームレス に利用できる環境の構築を行う

高エネルギー加速器研究機構

26

25

Architecture

開発の目標 エンドユーザが研究室のＰＣから、データ検索、データ解析、シ ミュレーションなどをローカルな資源とグリッド上 の資源を問わず 利用できる 。
ここで資 源とは、各種計算 機、データ格納装置、データ類、データベースなど

End users

Browsers

既存
新規開 発

PC

FireWallUser Applications

 どのグリッドミドルウエアも同じユーザ環境 (アプリケーション開発ユーザ向け)で利用できる。

(Web Service)“Non-GRID”‘UniversalGrid-API’ (Python Library)
SAGA C++ Engine

 複数のグリッドミドル ウエア下にある資源も必要に応じて、同時に利用できる。

Adaptors

 大学研究室では、グリッドミドルウエアに関するノウハウや保守を必要としない。

Adaptors

Adaptors
SSH protocol

 ＯＧＦで、既 に標準 化を目指しているＳＡＧＡをベースに開発し、足りない機能( 資源情報、RNS参照など)は独自に開発する。
SAG A: Simple API for Grid Applications

GRID

UI-CLINAREGI-CLI

gLite

NAREGIHTTPSRNSServer ファイルカタログ情報は、ＲＮＳをベースに検索する。

サブテーマ２

 アプリケーション開 発ユーザ には、Python環境で提 供する。

WGS

Local

FireWall－43－

DSI to Storages(HPSS, SRB,..)

27

28

サブテーマ(5)：実証評価・ユーザ連携
 実証評価 NISレベルの実証評価基盤の提供
 LLS レベルの計算資源の開拓と実証評価基盤への取り込み

サブテーマ5
実証評価・ユーザ連携

 ユーザ連携 大学等のe‐サイエンス基盤を必要とするアプリケーション

研究者の開拓とニーズの把握
 アプリケーションによるサブテーマ(1)～(4)の技術の実証

東京工業大学

評価と研究開発へのフィードバック

29

30

NISレベルでの実証評価基盤の提供

1GB/sを維持可能な性能計測原器の配置• すべての実証評価の基盤となる広域分散ファイルシステ
ムをNISへ配備 (初年度)
1.

10Gbp s(9.29 42Gb ps)

プロトタイピング• 長距離広帯域ネットワークで1GB/s転送を維持

2.

SINET3
JG N2 plus

12 .8GB /s– NISを相互接続するSINET3、JGN2plusの10Gbps WAN回線– 性能指標を取得するプロトタイプ (性能評価指標となる「原器」) をNISへ配置– 定期的な計測を行いネットワークや開発されるミドルウェアの安定性・不安定性をベン
チマーク

S310
- PCIe ×8- la ne s (2GB /s × 2)
- Off lo ad En gine s (LRO, TSO, TOE ,…)プロモーション
• ペタバイト級の実運用ストレージをLLS連携へのインセンティブとして提供

RAID5085- PCIe ×8- la ne s (2GB /s × 2)
- SATA/SAS 8 -po rts (300 MB/ s ×8 = 2 .4GB /s)– グリッド認証基盤の浸透を図る– アプリケーション共有、データ共有を促す– 開発されるミドルウェアの実運用評価に結びつける

Ram Dis kType-B: ネットワーク性能検証

SSD-SL C RAID-0/ 8-stripe s- Re ad: 25 0MB /s ×8 = 2.00 GB/s
- Write : 170 MB/ s ×8 = 1 .36GB /s

実証評価環境の安定性・不安定性を随時表示•開発者 ⇒ 性能向上の指標•利用者 ⇒ アベイラビリティの把握

Type-A: ディスクI /Oを伴うネットワーク性能検証(初年度に東工大・阪大に設置予定)
31“Traffic Weather Map” の例

LLSレベルの計算資源の開拓と実証評価基盤への取り込み
 NISからの「プロトタイピング」と「プロモーション」によるインセンティブを示してLLS連携を開拓
 身近なNISとの連携により実証評価基盤へマイグレートしていく
e.g. 大阪大学サイバーメディアセンター
 超高圧電子顕微鏡センター
 核物理研究センター (JLDG: Japan Lattice Data Grid) レーザーエネルギー学研究センター

e.g. 名古屋大学情報基盤センター
 太陽地球環境研究所

SC08でのデモンス トレーション例 (JGN2plus, APAN-JP)

－44－

32

5. NAREGI など Grid 適用実験・運用報告
5.1. NAREGI PKI をめぐる周辺－連携実証実験での事例－
報告：国立情報学研究所リサーチグリッド研究開発センター）友石正彦
大規模連携実証実験において必要となる複数の PKI ドメインが同時にシステム上に存在する状態での NAREGI の動作、設定などについての事例について報告を行った。
・・・

組織としては、大阪大学、九州大学、東京工業大学、NAREGI プロジェクトが参加。
NAREGI による各組織システム連携後の大規模システムでは、大阪大学認証局、NAREGI認証局が併用され、双方発行の証明書を利用。
・ ポリシーは一つではない－特にユーザ／発行ポリシーについては大きく異なる
・ 計算資源の利用については検討可能
ポリシーの検討とルート CA の導入。
・ 発行、資源利用、ローカルアカウントそれぞれのポリシーとのすりあわせ・ 発行ノードでの双方のルート CA の導入
・ 非計算ノードではポリシーに応じた CA の導入

図 5-1：実験時の PKI ドメイン(色分け)の様子
東工大、および、計算ノードは複数のドメインに属している- 45 -

添付資料 ・・・第 2 回会合（2008 年 2 月 22 日）報告
1

2

ＮＡＲＥＧＩミドルウェア 概要(caも)VO側
VO側

NAREGI PKIをめぐる周辺

VO-NASDBIS～ 連携実証実験での事例～

計算リソース側

WFT

SS

PSE
ポータル

2008年2月22日
国立情報学研究所
リサーチグリッド研究開発センター
友石 正彦

SCDAS

MCDAS

RUS

UMS/VOMS

ユーザ証明書： ジョブの流れるところ

LRPS

LRPS

ホスト証明書： 通信するところ

GridVM sch

GridVM sch

globu s ローカルスケジューラ

認証局

SBC

ローカルスケジューラ

セルドメインセルドメイン

4

3

NAREGIミドルウェア ユーザ証明書

NAREGIミドルウェア 証明書の種類• ユーザ証明書 + VO(属性)• ホスト証明書• ユーザ証明書• VO(属性)証明書– 計算リソース毎に受け入れVO情報– 計算リソースの gridmapファイルでユーザDNとローカルアカウントとの対応情報– 上位/ポータル側に伝達– ユーザ証明書にVOの属性情報を追加– VOMSのホスト証明書を利用• 各ノードにルート証明書• (委譲)プロキシ証明書 – 実際に使われる• コンテナ証明書• 認証局が発行• UMSに保存• 各ノードでプロキシ証明書として利用– ホスト証明書を利用

5

6

PKIドメイン連携実験
運用を前提に!

• お試し環境ではよく: SimpleCA (openssl)

•
•
•
•

• NAREGI 認証局– 本格運用ソフトウェア: naregi-ca– APGrid 対応のCP/CPS, 運用中

大阪大学
東京工業大学
九州大学
NAREGI(IMS, NII)

• 大阪大学認証局• NAREGI認証局• ほとんど、シングルPKIドメインで• NAREGIミドルウェアβ2

8Phase-I プラン

7

役割 Phase I
CMCGSIC_Osaka• 利用者

VO管理者：阪大
リソースプロバイダ：阪大、東工大
CA/RA– 阪大、東工大、九大• リソースプロバイダ

UMS

PortalVOMS– 阪大、東工大• ポータル、スケジューラ提供(VO管理者)

SS

PortalIS-NAS

IS-NAS

SS

大阪大学

UMS
VOMS

東京工業大学

– 阪大

• 証明書
– 阪大

IS-CDAS• 支援

IS-CDAS
GridVM Server– 九大、NAREGI

GridVM Server

SINET3（CSI-GRID網）
GridVM Clients

GridVM Clients

Single PKI domain

－46－

10

9

学内PKI、計算機に関する規則など

シングルドメインでも調整あり• ローカルアカウントが全計算リソースに必要、証明書も必要• 発行は対面認証のところも– 身分証、入退室 の次のアプリは？
– UPKI/無線LAN? Grid？

– 大阪大学のアカウント– 東工大のアカウント(学外?)– 大阪大学認証局 証明書• 発行者と利用者がほとんどいっしょ• これは阪大ポータルからワンタッチの作り込み• 証明書の受入れが必要• ユーザ証明書以外の証明書の扱いは？
• 外部からの受け入れは？
• 外部で使うには？

– ルートCA + gridmapfile– 受け入れポリシーは？..

11

12異なるポリシー(発行)証明書受け入れ• (何といっても)発行するとき… 対面確認は• CP/CPSは認証局のもの、計算リソース管理組織と一致するとは限らない• 組織 運用規則• 組織 内規– いる？ - 世界(APGrid)にあわせる– いらない？ - 共通アカウントからの実績• 発行した証明書、鍵のあつかい– ユーザ本人 + ソフトウェア– ユーザ本人 + ハードウェア(トークンの中のみ)– UMSなどシステムで管理– システムから出さない(発行以上の規則)• 外部から？
• 実験だから？
• ホスト証明書？
• つまり、受入れは想定外、そもそも規則がない• (計算機の利用だけなら、そもそも証明書が面倒!)

14

13

役割プラン Phase II

Phase‐2予定
連携VO
NANO_Osaka
BIO_Osaka
VO管理者：阪大
VO管理者：阪大
VO管理者：阪大
RP：阪大、東工大 RP：阪大、東工大
RP：阪大、東工大

• 利用者
CA/RA

– 阪大、東工大、九大

UMS• リソースプロバイダ

Single PKI domain

東京工業大学P ortal
UMS /VOMS

VOMS– 阪大、東工大(SS連携)

大阪大学• ポータル、スケジューラ提供(VO管理者)

Po rtalSS
SS

IS ‐NAS– 阪大、東工大
東工大

IS ‐NAS

SINET3（CSI‐GRID網）• 証明書

IS‐CDAS

IS ‐CDAS
13 3.1.6 5.13 7– 阪大

Grid VM Sch edul er

Grid VM Schedu ler

G ridVM Sch edul er• 支援

GridVM Engines

Grid VM Engines– 九大、NAREGI

16

15

Phase 2.0 PKIドメイン

複数SS• 計算資源

PKIと離れますが、• 現在の計算資源の利用状況は情報サービス
を通じて、それぞれのメタスケジューラに伝達、– 受け入れるジョブの証明書発行CAのドメインには必ず所属• ポータル– 組織(VO)所属ユーザの利用が前提• 東工大が(グリッド用認証局を上げていないので) 認証局として阪大を選択すれば、シングルドメイン!
• ところが、、• 将来の計算資源の利用状況(予約状況)は？
– 複数のメタスケジューラで予約情報を共有できるように- 47 -

19

20

Phase‐2.2
連携VO
VO管理者：阪 大
RP：阪大 、東工大

NANO_O saka
VO管理 者：阪大
RP： 阪大、東工大

BIO_Os aka
VO管 理者：阪大
RP ：阪大、東 工大

連携VO
VO管理者：阪大
RP：阪大、東工大

東京工業大学

NII

大阪大学

Phase‐2.2 PKIドメイン修正版
BIO_Osaka
VO管理者：阪大
RP：阪大、東工大

NII

東京工業大学

大阪大学

CA/RA

User cert

CA/RA

NANO_Osaka
VO管理者：阪大
RP：阪大、東工大

CA/RAUser cert

CA/RA
PortalPortalU MS/VOMS

UMS

P ortalU MS/VOM S

Host cert

VOMS

UMS/VOMS

UMS

PortalVOMS

SS

UMS/VOMS

PortalHost cert

SS

SS連携

SS

Portal

SS連携

SS

SS

SS

IS-NAS

IS-NAS

IS-NAS

IS-NAS

IS‐NAS

IS‐NAS

IS‐CDAS

IS-CDAS

IS‐CDAS

IS-CD AS

IS-CDAS

IS-CD AS

Grid VM Sched uler
GridVM Sched uler

GridV M S che du ler

GridVM Sch edul er
Grid VM Schedu leGrid VM Engines

GridVM Engines

GridVM Engines
SINET3 （CSI‐GRID網）

GridVM Scheduler
GridVM Scheduler

GridVM Scheduler

GridVM Scheduler
GridVM Schedule

GridVM Engines
pn g

SINET3（ CSI‐GRID網）

GridVM Engines

GridVM Engines

SINET3（CSI‐GRID網）

png

SINET3（CSI‐GRID網）

21

22

Phase 2.2 PKIドメイン

ポリシーふたたび• 計算資源、ポータル• 異なるポリシーの受入れは？

– 受け入れるジョブの証明書発行認証局のドメインに所属– 計算させるだけなら？
– 証明書(というよりポリシー)次第では？

• ホスト証明書と異なる証明書受け入れ。
• つまり、ポータルも複数のドメインに所属• (受入れ条件は？)• 相手CP/CPSで/を明示的に協議/reviewできる– 複数のドメイン/ルートCAのインストールに対応• 異なるドメインのユーザ証明書の受け入れも可能？
(複数のドメインを意識した運用?)• パフォーマンス• 組織内での切り分けも– 学内、国内連携組織、海外連携• 実験は現在は、東工大でジョブが動いたところまで。

24

23

まとめ

NAREGIミドルウェア V1•• ユーザの手元に証明書と鍵を置ける• UMSも利用可能•• Webエンロール拡張• 認可サービス• プロキシ証明書のリニューアル••組織（学内）PKIは進展中– Gridは大きなアプリケーション– これまでのユーザレベルで理解されているとは限らない– （（ユーザ）秘密キーをちゃんと管理してもらえるか。。）– （UMSは大きな「セキュリティトークン」？）
発行ポリシーは一つとはかぎらない– APGrid vs ...
– （専門家は厳しく、現場は（ユーザに）やさしくなりがちな感じ）– ユーザ毎に違う範囲の機械を使うことになるかも– 決定打はない？
柔軟な受入れポリシーの検討を– 相手CP/CPSがあれば、明示的に検討可能実証実験では、阪大発行証明書とNAREGI発行証明書– 計算ノード以外での双方の ルートCAでの運用も5.2. 高エネルギー加速器研究機構におけるグリッド配備の現状
報告：高エネルギー加速器研究機構計算科学センター）佐々木節
高エネルギー加速器研究機構(以下、KEK)では、複数のグリッドミドルウェアを実際に配備し、運用を行っている。その現状を報告するするとともに、将来に向けた開発項目を提起したい。
KEK で行われているのは、加速器を用いた研究が主となっている。衝突型加速器、固定標的型
加速器、ニュートリノ発生装置、放射光発生装置など様々な大規模装置が稼働しており、日々大量のデータの集積されている。世界各地から多くの研究者が利用しており、世界的な規模における大量データの共有というのが課題となってきた。過去においては、データ解析のためには、KEK に研究者が実際に出向いて計算機を利用する必要があったが、ICT の進歩により、各大学においてデー
タ解析を行うために必要な環境の整備が進んでいる。ちなみに、KEK は、日本で最も早くインターネットに接続された機関の一つであり、ICT の発展に寄与する努力も行ってきた。
－48－

グリッド技術に対しては、早くから、加速器科学への応用の可能性が探られており、ヨーロッパでは、CERN（欧州原子核研究機構）が主導し EGEE(Enable Grids for E-sciencE)が組織され、gLite と い う ミ ド ル ウ ェ アが 開 発さ れた 。 米 国に お い て は 、Caltech を 中心 に (Open Science
GRID)OSG と団体が組織され、VDT(Virtual Data Toolkit)というミドルウェアが開発さえた。それぞれのミドルウェアは独立に開発され、独自に運用されている。
我が国においては、人的資源に恵まれていないことから、加速器科学の分野で独自にミドルウェ
アを開発されることはなかった。メンバーとなることはなかったが、国立情報学研究所(NII)が主導する NAREGI ミドルウェアの開発プロジェクトに積極的に関与し、データグリッド機能の拡充、グリッドミ
ドルウェア間相互運用性の確立に寄与した。
現在、KEK においては、国内に 3 つあるグリッド IGTF(International GRID Trust Federation) CA
局の一つを運用するとともに、gLite および NAREGI ミドルウェアの運用を行っている。gLite は、先行した分、多くの研究プロジェクトに供され、利用されている。NAREGI に関しては、国内の機関の基盤整備に利用し、グリッドミドルウェア間相互運用機能を用いることで、異なるミドルウェア間での計算資源と情報の共有を図る予定である。欧米の研究機関に比べ、我が国の研究機関におけるICT 担当者の数は非常に少なく、欧米型の運用モデルをそのまま実施することは困難であり、我が国独自の方式を確立する必要がある。そのほか、SRB、iRODS、gFarm と言ったデータグリッドミド
ルウエアを運用し、必要とするグループに供している。
加速器科学の分野でグリッド技術が早く浸透した理由の一つとして、国際共同研究を行う際に、加速器および検出器の建設、データ解析に必要なコストを分担して行う文化があったことだと考えている。計算資源を提供することで、コストを分担したことになるので、加速器を持たない機関の研究競争力向上にもつながると歓迎された。
さて、実際にグリッド技術を用いてデータ解析を行ってみると、グリッド技術の範疇外での困難に突き当たる。複雑で規模の大きなソフトウェアを異なるフレーバーの計算機に導入数することは容易ではない。特に、多くのリモートサイトに対して、各種ソフトウェアをインストールし、そのバージョンを管理することには、困難を感じている。これを自動化する仕組みを開発するか、仮想計算機の性能が向上してきたので、仮想計算機をうまく利用し、クラウドとグリッドのハイブリッド型のサービスの提供を行うことが望まれる。
グリッド技術は、世界中の計算資源を結びつけ、世界中の情報にアクセスすることを可能とした。
しかし、その運用には、豊富な人的資源が仮定されており、我が国の学術機関の現状に必ずしも適合するものではない。国情に見合った技術が必要であり、NAREGI の今後の展開に大きな期待を寄せている。
添付資料 ・・・第 3 回会合（2008 年 6 月 9 日）報告

Basic strategy• GRID deployment and operations for projects at KEK– Belle, J‐PARC, ILC and so on

GRID activities and future plansat KEK• LHC regional center– Univ. of Tokyo is operating tier‐2, but no tier‐1 in Japan– Preparing for future tier‐1 level GRID center operation at KEK
toward ILC• Depends on the decision of the society• Technical assessments and staff training

Takashi Sasaki
KEK Computing Research Center• University support– Help for deployment and operations of LCG at universities out
side of WLCG

KEK: Inter University Research Corporation
High Energy Accelerator Research Organization• NAREGI– Our human resource is very limited and we want to depend on
the operation infrastructure of NAGEI if possible– Would help university people and non‐HEP users- 49 -

High Energy Physics in Japan•

Major High Energy Activities in Japan– Terminated in the last FY• K2K Experiment at Kamiokande and KEK
CDF at FNALATLAS at LH C

– Active Experiments• Belle Experiment at KEK• KamLAND at Kamioka• CDF at FermiLab/USA
KamLand– Under construction

Osaka U.

– Future Plan•

Tohoku U.

Kanazawa U.
Kyoto U.

JAEA Tokai

KEK
Tsukuba U.
ICRR/Tpkyo
U. Tokyo

Osaka city U.

High Energy Physics Network in Japan

J- PARC

Shinshu U.
Nagoya U.

Nara Women U.

HEPnet-J:–

RIKEN

Niigata U.

• SuperB Factory
Okayama U.
• International Linear ColliderHiroshima(ILC) U Kobe U.

INTRODUCTIONTokyo Metropolitan U.

Kamioka

S uperKamiokan de• J-PARC– T2K Experiment at Tokai and Kamioka• ATLAS and ALICE at LHC

Waseda U.

Tokyo Inst. of Tech.

KEK provides the network facility, NEPnet-J,on the SINET/SuperSINET (NII)。

K EK BE LLE
SuperSINET nodes
SINET nodes

Int roduction to KEK

KCL 18MAR2008

High Energy Accelerator Research Organization

4

J - PARC ( Tokai )KEKJ-PARC = Japan Proton Accelerator Research Complex
Hadron Beam Facility

Materials and Life Science
Experimental Facility

J- PARC

Tokai
Tsukuba
Neutrino to
SuperKamiokande

B-Factory
LC--Test Facility
LC

Narita Airport

Linac(330m)

Photon--Factory
PhotonKCL 18MAR2008

Introducti on to KEK

5

KCL 18MAR2008

3 GeV Synchrotron(25 Hz, 1MW)

50 GeV Synchrotron(0.75 MW)

Joint ProjectIntroducti
between
KEK and JAEA
on t o KEK

6J-PARC (T2K Experiment)
KEK (Tsukuba site)
Mt. Tsukuba

Neutrino Experimental
Facility
295 kmWest

Belle Experiment
KEKB

Photon Factory-AR:6.5GeV

Computing Research Center

Super Kamiokande

Super-Kamiokande
Photon Factory: 2.5GeV

J‐ PARC
Kamiokae+/ e- Linac

KCL 18MAR2008

Introducti on to KEK

7

KCL 18MAR2008

KEKB e+ e-- Collider

Introducti on t o KEK

ILCBelle Experiment
13 countries, 57 institutes, ~400 collaborators• International Linear Collider
SCC RF(HER)

8 GeV

e-

3.5 GeVe+

ARES
Ares RFcavity(LER)e+ source

Observation of CPV
in the B meson system
Introducti on to KEK

KCL 18MAR2008

B0 ÆJ/ψKS
B 0ÆJ/ψKS

9－50－• 素粒子の質量の起源、時空の対称性、宇宙創成などの根源的な疑問を解明する為に国際的な協力で建設する計画の最高エネルギー電子・陽電子衝突の線形相互衝突型加速器• 日本への誘致を目指している• http://www.linear‐collider.org

8

Why GRID?
• 国際共同研究– 手元にデータがほしい• 研究効率の改善• 処理すべきデータ量、計算量が膨大になりす
ぎ、分業する必要に迫られている– 解析そのものよりも、シミュレーションに必要な計
算量が膨大

LCG

• 収集する事象数以上は最低でも必要

VOMS operated at KEK

Brief Summary of GRID Deployment•

2 sites are in operation•

JP‐KEK‐CRC‐01

–
–
–

•

Since Jan 2006
More stable services based on experience at
KEK‐1• VOMS has been serviced in production since Sep 2006.

belle
ppj
ilc, calice
g4med
dteam, ops
naokek (The same VOMS is used for NAREGI)
apdg

–
–
–
–
–
–
–

Since Nov 2005
Usage: e xperimental use and R&D, but
production in LCG framework

JP‐KEK‐CRC‐02––•

Accepted VOs are•

Deployed in different network logically– Tested from Nov 2005.

– BELLE: Belle Experiments (belle only registered in CIC)
• The biggest target for us– PPJ: Accelerator Science in Japan– G4MED: Geant4 Medical Application for Radiotherapy– NAOKEK: Interpretational VO between National Astronomical
Observatory of Japan and KEK– APDG: The R&D of Data Grid among Asia‐Pacific region– ATLASJ: The ATLAS Experiment only for Japanese Group– AIL: Associated International Laboratory between KEK andFranceNAREGI––

Using NAREGI beta1 released on May 2006.
Testing , evaluation, requirement assessment

SINET

outsideJP‐
JP‐ KEK
KEK‐‐CRC
CRC‐‐02
JP‐KEK‐CRC‐02

KEK FW

insideKEK‐‐LAN
KEK
KEK‐LANmovmovee out very
very soon,mid‐
mid‐of‐of‐April
Apr il

JP‐‐KEK‐JP
KEK‐ CRC
CRC‐‐01
JP‐KEK‐CRC‐01

NAREGI

Integration of existing storage using
SRB‐DSIBELLE: The VO for the Belle Exp.
•

Belle VO is federated among 5 countries, 7
institutes, 10 sites.
–•

Nagoya University, University of Melbourne,
ASGC, NCU, CYFRONET, Korea University and
KEK

VOMS is provided by KEK–

http://voms.kek.jp/

http://voms.kek.jp• VOMS support the VO for•

LCG user

Past Activities
–
–
–
–
–
–

LCG userFederation was establishe d
Library installation
Submitting MC production job for more
realistic use
Long‐term jobs, MC is taken ~1 week usuallyFunctional tests and performance tests overthe VOInterface to existing peta‐bytes of data

M elb ourne
Melbo
urne

KU

CYFRONET

APAN
APAN

GEANT2
GEANT2
GEANT2

KEK‐‐DMZKEK
KEK‐DMZ

GridFTP

ASGC

NCU

SINET

KEK FWSRB

KEK‐‐LAN
KEK
KEK‐

Nagoya

KEK
KEK‐
‐2
KEK‐2
KEK‐
KEK‐ 1
KEK‐

SRB
SRB‐
‐ DSI
SRB‐DSI

KEK
Jap
an
Japan
Jap
an
C YFRONETCYFR ONETONETCYFRPo landPol
andEnhanced
GridFTP service
GridFTP
service

SR B server
SRB

Reference
NFS
Registration

Kor
ea
Ko
Korreaea Un
Un iv.
iv.
K orea

•
ASGC
ASGC
Tai
Taiwanwan

A user can access by just using GridFTP
client from out side–

NCU
Taiwan
wan
Tai

–
–

Univ. ooff MelboUniv.
Me lbo urn eAustralia

•

MCAT

3.5PB
HSM

SRB clie nt can access HSM also frominside.
Benefit for both SRB user and LCG user
Both user can read and write from/to
HSM without considering protocol.

SRB
SR B client
clientLSF
Computing Farm

Both protocols are authorized by GSI

Still not integration with Grid

ILC/CALICE: The VO for Linear ColliderExp.

B elle Net
Bellededicated insideinsi dePluggable
Extension

Nagoya Un iv.
Japan
Jap
an

Belle analysis user

Operation statistics in Last 2yrs

• ILC/CALICE VO is supported at KEK– Since end of 2006

• File sharing/transfer among DESY, IN2P3 and KEK over the VO• ILC– Number of cores: 32,793– SPEC: 35,384 kSI2K– Storage: 68.4TB (12.6TB in use)
– Members: 69 (4 from Japan)

ILC• Number of Jobs: 150,269

CALICE• Number of Jobs: 145,776– 955 of 150,269 has beenprocessed at KEK‐1/2– 579 of 145,776 has beenprocessed at KEK‐1/2• 323,251 CPU timenormalized by 1kSI2K(hrs*kSI2K)• Calice– Number of cores: 13,469– SPEC: 15,140 kSI2K– Storage: 203TB (15.6TB in use)
– Members: 52 (3 from Japan)– 569 of 323,251 has been usedat KEK‐1/2• KEK offer small resource- 51 -• 338,531 CPU timenormalized by 1kSI2K(hrs*kSI2K)– 1,061 of 338,531 has beenused at KEK‐1/2

Plans on LCG operation

Prototype of GOC
Nagoyaiv.
Nagoya Un
Univ.

• Computer system upgradeToho
ku Univ.
To hoku
Univ.

Ko
Kobe
be U
Univ.
niv.

– New system will start the operation on March 2 nd , 2009

Hiros
Hiroshima
hima IT• Bidding will be done in August 2008
• The specification will be open on June 11, 2008

KEK
KEK

– LCG+NAREGI share all of the computing nodes and storage

Univ.
Univ. of Tsukuba
CComputing
omputing Resources over the PPJ
PPJ VOVO
Toho
Tohokuku U

KEKCPU (kSI2K)(kSI2K)

0.68
0.
68

91

5.1

8.3

8. 5

1.2

115

SE (GB)150

2,6 76
2,676

Tsu ku ba U

65

Nagoya U

150

68

Ko bee U
Kob

36

HIT

3,145

Tot alTotal

KEK behaves as the GOC•Remote installation•Monitoring
We have a common VO, but do NOT depend on scient ific project s.
•Software updates–
To tes t each site .
Federated among major univ ersity groups and KEK in Japan.

•

–
–
–
–
–

•

Tohoku‐U
Tsukub a‐U
Nagoya‐U
Kobe ‐U
Hiros hima‐IT(KAMLAND, ILC )(CDF)(BELLE, ATLAS)(ILC, ATLAS)(ATLAS, C ompu ting Scie nce )KEK assists their operation over the this VO•–

same motivation w ith ops V O

Monitoring System for our GOC
Summary
Summary
vview:
iew: Each
Each
site
iconified
Summary view:
Eachsitesite isis iconified
iconified and
and
shown
shown
the
ir status
ststatus
at us asasfew
w color,e.g.,
shown theirt heiras aaafefew
color, e.g.,
e.g.,yellow
warning””,, redwarning
rederror””..
error
yellowshow
show““warning”,
red showshow““error”.
The
ss and
of
line
ness
color
indicates
Thetthickne
thickhicknessand colorcolorofoflineline indicate
indicatess RTT
RTT
work status.
andnetworkand netnetworkstatus.

SSupport
monit
oring
Supportupportsystem:
system:system:consists
consists ofof ““monitoring
monitoringsystem”” andknowledge
FAQ
systemknowledge DB
DDB”
B” andF AQ bysystem”
and ““knowledgeand “““FAQ
by
wiki”
wiki
”
wiki”

NAREGI
Monitoring Portal••

The monitoring system based on nagios and wiki
The monitoring portal creates a link automatically based on
knowledgebase and navigates administrators to appropriate
troubleshooting page on wiki.

Monitoring
Monitoring
statusus is
isMonitoring system:
system:The
The sitesite stat
statusischeckedchecke
d by
by
few
jobs
commands,
checkedbyaa fefew
wsimplesimplejobs
jobs ororcommands,
commands,
and
and
here.
to
is
generated as
as
and isis listed
listed here.
here.Link
Linktot o FAQ
FAQ isis generated
generatedastodescription.
toto errorerror description.
description.

Strongly inspired
insp ired ASGC NAGIOS Monitoring Service maintained
main tained by Joanna
Joanna Huang,
Huang, APROCNAREGI β2 status

Introduction• NAREGI: NAtional REsearch Grid Initiative• Released in Oct. 2007, revised in Jan. 2008
• Additional features to β1 version– Foundation: 2003-2007 10 billion Yen for 5 years– Host institute: National Institute of Infomatics(NII)– Core collaborations: IM S(molecular science), AIST(industrial app.),
TIT, Osaka, Hitachi, Fujitsu, NEC– Auto installation with apt-rpm– Provides script for operation (Full Server
start/stop/restart/status)– Full VOMS integration• Mission:– R&D of the Grid middleware for research and industrial application
toward the advanced infrastructure– Primary target application is nano technology for innovative andintelligent materials production.

• Resource Sharing with multi V O’s• Data access and data space manageme nt with the VOMS

– Provides Gfarm-DSI: GridFTP interface of the DataGrid– Improved performance– Interoperation with gLite/EGGE (not released yet, internal
evaluation process)• More focu sed in the comp utin g grid for linking supercompu ter centers forcou pled simulation of multi-scale physics• Support heterogeneous co mpu ter architectures (vecto r & super parallel &clusters)• Data grid p art were integrated in 2005
2008.04.10

2008.04.10

23

24

Testbed for NAO-KEK federation
March 2008

ＮAREGI-β at KEK• Testbed: 9 server nodes + 5 compute nodes• Middleware installation

NAO Site– NAREGI-beta 1.0.1 : Jun. 2006 - Nov. 2006
• Manu al installation for all the steps• Confirmed functionalities of Information Service, PSE, WFT, GVS

GridVM Eng– NAREGI-beta 1.0.2 : Feb 2007

PortalPortalPortalSS

SS

SuperSchedIS ‐NASI S‐N AS

IS ‐CDASI S‐ CDASSINET3

KEK Site
Private network

Infosys‐NAS

192.168.2.101~

Infosys‐CDAS

GridVM Eng

GVM Se r

G ri dVM Se r

GridVM Serv• DG co mpreh ensive installation manual was released in Jan . 2007

– NAREGI-beta 2.0.0: Oct. 2007
– NAREGI-beta 2.0.1: Dec. 2007

User Browsers

User Browsers

MDS
MD S

Compute nodes

apt-rpm installation

AMS

FireWall

AM
S.
AMS

G fa rm
Gfarm• Site federation test

MetaData Serv
Acces sManage
Gfarm
Storage

DataGrid part

– KEK-NAREGI/NII :Oct. 2007
– KEK-National Astronomy Observatory (NAO): March 2008

NAT /DNS

N AT/DN S

U MS/VO MS

VOMS/KEK

UMS /VOM S

NAT/DNS

UMS/VOMS

Compute nodes

Test VO: n aokek
2008.04.10

2008.04.10

25- 52 -

26

Federation Test with NAO(National Astronomical Observatory )Federation Test with NAO-KEK
SUBARU Telescop e in Ha waii

• Aim: Evaluation of application environments of NAREGI••• Test Applications•– N AO: JVO(Japanese Virtual Observatory) applications– K EK: HEP Data Analysis, ex Belle simulation
Geant4 MPI simulation

job sub

NAO• Status:

27

Visualization

50,000 objects identified in t his fra me.

2008.04.10

28

DataGrid:Gfarm File access
nrg00
nrg02

DataGrid part is consist of Gfarm distributed file system

Grid FTP
Server/Clients– data files are stored in the multiple disk servers under the Gfarm file system software

nrg01
nrg04

Input and output data are staged-in and staged-out to the Gfarm storage.

• Data Staging• File transfer

Porta l
IS

SS

wn101
wn102

GridVM Ser
192. 168. 2.4: g vms– c onfirmed within KEK site and between KEK and NAO site•

senser calib.
adjust deformation
positioning
mosaicingsumming 17frames

Output data was processed with vis.
software a s shown in the right pic ture.

gLite/EGEE, etc•

Process: 10 Hours

Astro lib
(1GB)
Data 2.7GB

Test of data storage with Gfarm•

NAREG I
Servers

retrieve•

Input Data:(2.7 GB)
10 CCD mosaic images
160MB x 17

KEK

NAREGI
Servers– N AO installed NAREGI β2 in the te stbed Feb. 2008
(DataGrid part is not ye t installed.)– Test VO: naokek hosted by KEK VOMS server/gLite– Simple Job submission and retrieve were successfully tested in the endof March– Remote data file staging-in/-out ha s been confirmed.
– A stro application job has been submitted to K EK site and retrieved theresult to post-process for visualization. Apr. 20082008.04.10

Setup Astro Librarie s at KEK site
Job submission to KEK with Work FlowTool(WFT) a t the NAO Portal
Input data are transferred from NAO a nd
Output data are staged-out to NAO portal

Staging

GridFTP interface supported in the β2

nrg09

MD S

nrg10
AMS
.
AMS

Transfer– data file transfer tested between gLite site and NAREGI site
– File name space is the sa me between TURL and Program IO(using Gfarm-Fuse) a s
shown in the next slide.

wn103
wn104

nrg11

Program IO

wn105

Gfarm

– Grid FTP• Program IO– with Gfarm Fuse
– Data analysis program
can read/write data
files without
any modification

Gfarm data files•

Data file access from application program

NAT /DNS

Transfer URL through Gfarm‐DSI:
192. 168. 2.6: g wy Program access name space for VO:
gsiftp://nrg11.cc. kek.jp /gfarm/ user01/data1‐22.dat/gfarm/user01/data1‐22.dat
UMS /VOMS– Gfarm client installed in the Engine nodes (Worke r nodes) with FUSE
– User can mount the Gfarm file system in the job by user privilege– Get access the data file through progra m read/write directly with no change in thea pplication program (Belle event sim ulation), as if local files.
– IO speed is severa l times slowe r than the local disk file IO. Tolerable depending on thedata IO portion in the application program.
2008.04.10

2008.04.10

29

Test Applications•

Data Grids Installation at KEK
2007.2.9

Data Analysis program :Carbon Ion Scattering in the water measured with
Emulsion at 150 MeV, 300MeV•
Data analysis program (written in ruby)•
Input data was in the Gfarm and analyzed data were stored in the Gfarm
files and also transferred to the SRB storage with Grid FTP•
Typical elapsed time of a job is about 2 hours.

•

Geant4 Simulation with MPI•

Belle event Simulation

•

•
•

•

30

gLite/EGEE
gLite/EGEE
CPUs
SRB
MCAT

Naregi‐kek

Parallel processing Geant4 simulation with GridMPI of NAREGI has
been test on the b1.

SRB‐DSI

full simulation softwares with libraties and database are installled
and tested successfully in KEK site.
plan to inter‐operate with gLite/EGEE belle VO

gLite/
CRC-01gLite/
CRC-02SUBARU telescope image enhancement
2008.04.10

31

Future Plan on NARGI at KEK– Migration to the production version•

Release of NAREGI v. 1.0 will be in May 2008

– We will cooperate with Grid Operation Center in
National Institute of Informatics•

Planed to be started the operation JFY2008– Multi site federation test with full specification
will be done
– KEK leads improvement of the middleware in
the application domain

2008.04.10

SRB files
Local files

Grid files

2008.04.10

SRB
serverOTHER ACTIVITIES

33- 53 -HPSS

32

KEK Grid CA

RNS• KEK Grid CA has been started since Jan 2006.

• Middleware independent file catalogue isstrongly desirable to operate multi‐middlewareand share data

– 75 CAs are in production all over the world, 3 in http://gridca.kek.jp
Japan.
• AIST, NAREGI, and KEK– accredited as an IGTF (International Grid Trust Federation)compliant CA– Robustness and scalability are issue• RNS: Resource Naming Service is standardized at
OGF already• KEK Grid CA has been audited by Yoshio Tanaka (chair of
APGridPMA), AIST on May 2007

– http://www.ogf.org/documents/GFD.101.pdf– Two independent implementations are going on

KEK Grid CA: Statis
Statistics
tics of Issued Certificates
JFY20
JFY2006
06
Apr 22006
006 ‐ MarMar 2007

JFY200 7
JFY2007
Apr
Apr 2007 ‐Globus Client
C lient Certificate(Personal cert.)
cert.)

68
68

119
119

Globus Server
Server Certificate(Host(Hos t cert.)

139
139

238
238

Web Server CCertificate
ertificate

4400• U. of Tsukuba– http://www.ogf.org/OGF21/materials/957/OGF21%20RNS.pdf• University of Virginia• We have requested NAREGI to support RNS

iRODs

GRID interoperability• We are waiting for iRODs becomes matured
enough to replace SRB• Small contribution to the development• gLite and NAREGI interoperability is our great
concern– Discussion and collaboration with the NAREGI
team– https://www.irods.org/index.php/Performance• GIN• Data GRID

• People at iRODs workshop had seen

– Collaboration with Adil Hasan(RAL, UK) and Jean‐
Yves Nief (CC‐IN2P3)– Collaboration with CC‐IN2P3, Lyon
• SAGA(Simple API for GRID Applications)/JSAGA• NAREGI has been installed at CC‐IN2p3

Summary• Many kinds of GRID middleware have been
deployed and in operation– Related R&D is also going on• Future strategy for the regional center will bedecided by the Japanese HEP society– Super B, T2K, ILC, LHC and etc.

SUMMARY ANDACKNOWLEDGEMENTS• In our experience, human network is much
more important than computer network.

Acknowledgements II

Acknowledgement I•

Daily operation– All members of APROC (ASGC)– All of ROCs
– K. Ishikawa, M. Matsui (ISE Co., Ltd)•

Belle virtual organiz ation
K. Inami, M. Kaga (Nagoya Univ.)
P. Lason (CYFRONET)J. Shih, M. Tsai (ASGC)
M. Rosa, G. Moloney (Univ. of
Melbourne)– S. Lee (Korea University)

–
–
–
–

•

ILC/Calice virtual organization• Some part of the work are partly supported by CSIProgram of NII– R. Poeschl (LAL)– A. Miyamoto (KEK)– People in DESY‐IT•

Accelerator Science
–
–
–
–
–

M. Fujii, Y. Nagasaka (Hiroshima‐IT)
J. Ebihara, K. Yamada (Soum Co.,Ltd)
Y. Takeuchi (Univ. of Tsukuba)
K. Kawagoe (Kobe University)
T. Nagamine (Tohoku Univ.)

2008.04.10- 54 -

42

5.3. NAREGI ミドルウェアによる 6 拠点連携実験
報告：大阪大学）東田学
添付資料 ・・・第 3 回会合（2008 年 6 月 9 日）報告

NAREGIミドルウェアによるPhase‐1:
SC07出展対応

6拠点連携実証実験
Manabu Higashidamanabu@cmc.osaka-u.ac.jp

2008/06/09

SC07 Demonstration at Booth#3059
9 すべての共同利用ユーザにGrid証明書を発行します!
9 すべての計算機資源をGridに提供します!
9 東工大GSIC‐TSUBAMEと連携しています!

The Grid Operation Center at the Cybermedia
Center

The Grid operation center at our center is engaged in the research of the application of Grid technology to our ce nter operations,and has actively been involved in the development of Grid middleware. We provide the user with our PC clusters as part of theGrid resources. Furthermore we are preparing a pioneering framework which enables resource provision including the vector
system.
The supercomputer centers of the seven major national universities in Japan have charged for electricity based on the actual
amount of use. As part of the Grid middleware established so far, the secure framework of authentication based on PKI was
implemented first. On the other hand, the development of the virtual organization management system and the accounting
function is expected for earlier deployment of the Grid technology for our center operation.
So far, the application procedure for the use of computing
resources has not required person authentication becauseof the guaranteed payment for the usage of the system.
However, the issuance of a Grid certificate requires person
identification through interview regarding the PMA's
classic profile. At present registration authorities havenot been deployed nationwide, which is the largest
obstacle in the deployment of Grid services.
We give first priority to the issuance of Grid certificates toall of nationwide users of our center and have built ourown accounting system. Finally, we stipulated thecertificate issuance procedure that does not require
person identification through interview so that it does notinterfere with Grid operations. We are prepared for
proposing it to PMA as a profile. Such outcomes havealso contributed to the Japanese NAREGI project(National Research Grid Initiative). Now the cooperativeevaluation project using the Tokyo Institute ofTechnology's TSUBAME system is in progress and it isexpected to become the foundation of the Grid system inJapan at a full‐scale operational level.

途中 結果は どう
やっ て見る の？

途 中結果は可 視化で きるの？

コマンド ラインでジ ョブ投 入で きるの ？

SC08
Austin TX
Nov. 15‐21- 55 -Gri dVMに直接 アクセスで きるの？

ステー ジング
いらなくな い？

例えばファイルをリネームするには？

何のため の実証実験な の？

ゴールは？

“NAREGI 100T Project” (仮称) の課題: SC07の反省
ゴールは9 とにかく一度はきちんと「仕様どおり」に動かしてみたいz GridVMのことはかなりよくわかった¾ ローカル・スケジューラのことを熟知しているから

z IS (Information Service) も何故かよくわかった¾ OGSA‐DAI≒SQLだから

z SS (Super Scheduler) のダークサイドぶりが際だつ

Grid Operationの恒常化¾ まるでちゃんと動いている気がしない･･･? “Missing”: 落ちるとジョブが消失、ただしローカル・スケジューラにはジョブが残ったまま･･･? “Exception” : 何が原因で落ちたか一切不明･･･¾ このままでは何がどう「仕様どおりでないか」すらフィードバックできない･･･

9 再挑戦するなら「連携実証」の名に相応しい連携をやってみたいと既存の全国共同利用業務の両立

z ポリコム分配器が許す限り多くの拠点で連携したい¾ 阪大、東工大、九大、国情研、分子研、名大z ミドルウェアの連携機能を実証したい¾ IS 連携¾ SS連携 (V1の機能を先出し導入)

なぜ今回の大規模実証は「失敗しなかった」のか!?

なぜ “NAREGI” の評判は良くないのか!?
9 そもそも認証局がないと評価できない

9 SC07対応の経験を受け、今回限りの “GOC” が機能した

9 とにかく安定して動かせないzz 国情研で友石さんが登録「代理店」業務を担ってくれた

設定が煩雑¾ 度重なる仕様変更¾ 基盤センターへの共同利用登録申請の代行? 設定ファイルの記述の更新が追い付いていない･･･¾ 各拠点からのDN情報の収集・分配? 最後の最後でSSクライアントの仕様変更で、それまで無事動いていた
GridRPCが動かなくなる･･･zz V1のSSを先行導入し、ISも含めて連携構成¾ 当初は「そんな無茶な」と思ったが･･･

サーバが不安定¾ うまく導入できている拠点を生かしながら、徐々に連携の輪を広げることができた (狐に抓まれたみたい･･･)¾ 短期間の統合試験で動作検証を成功させるための甘い実装が「2000年問題」
化している

z SSを集中的に監視する “GOCツール” が間に合った¾ 統合試験では検証できない複雑な構成を組むと落ちる: 「分子研問題」¾ SSの予約キャッシュサービスの状態推移を逐次監視

Phase‐2:“NAREGI 100T Project”
NAREGIミドルウェアで100TFLOPS級のグ
リッド環境を構築できるか!?

“NAREGI 100T Project”
大阪大学

Phase‐2: 3/27時点のノード構成
東京工業大学
GSIC‐VO S

Fact Sheet 1: 管理ノード構成

分子科学研究所

NAREG I CA

RENKEI -OsakaO saka Univ. Gr id CA

NII

Phase‐1/
Phase‐2

VO1

RENKEI‐Naregi

CA/RA

CA/RA

動き出したサイエ ンスグリッドNAR EGI―研究リソース共有の世界を広げるミドルウェアを公開―
平成 20年5月9日付けプレスリリースより抜粋

SINET3
接続

グリッド認
証局

IS
ポータル

SS

RA

NAS

CDAS

User cert
Host cert

UMS

PortalPortal

UMS/VOMS
UMS/VOMSPo
Po rtalrtal

UMS
UMS /VOMS/VOMS

PortalPortal

UMS/VOMSPort al大阪大学

10Gbps

○

○

○

○

○

東京工業大学

4Gbps

－

○

○

○

○

九州大学

－

－

－

－

－

－

NII/NAREGI

1Gbps

○

○

◎ ※1

○

○

SS連携

VOMS
VOMS

SS

SS

rcs
rcs

SS

SS
SS

2007年 8月
IS‐NAS
IS‐NAS

IS‐NAS

IS‐N AS

Grid
VM
Sch
Grid
VM64
Sch
d pca0IS‐CDAS

名古屋大学
IS‐C DAS

内部利用 portal /… /cdas

IS‐CDAS
IS‐CDAS

IS‐CDAS
IS‐CDAS

IS‐CDAS
IS‐CDAS

CDAS/GV M‐S

vo1利用
Gri dVM
pbg2043

九州大学

松岡研 内
Gr
Gr idVM
idVM SchSch

Gri
Gri dVM
dVM SchSch

Grid
Grid VM
VM Sc
Sc h
h

Gr idV M Sch

Gr idV
idV M
M Sch
Sch
Gr

遊休
休
遊

(L in ux)

(Solar is)

GridVM Engines

GridVM Sch

GridVM Engines

GridV
M Sch
dpca128
dpca128
GridV M Sch
dpcb064
dpcb064
GridV M
M Sch
Sch
GridV
dpcb128
GridV
GridV M
M Sch
Sch
dpcc128
GridV
M
GridV
M Sch
Sch
dpcd048
GridV
M
GridV
M Sch
Sch
dpcd049
GridV
GridV M
M Sch
Sch
dpcd057
Grid VM Sch
sr1 1kGrid VM

Grid
Grid VM
VM S&
S& EE

Grid VM
pn g1051

Gr idV M Sch
dpc.kyus
dpc.kyus huhusng000 1(s x)

png10 54

GridVMp fg1 005

(Linux)(Linux)分子科学研究所

2008年1月

1Gbps

－

○

○

－

○

名古屋大学

2008年3月

1Gbps

－

△※2

△※2

△ ※2

○

2ヶ所

4ヶ所

4ヶ所

3ヶ所

5ヶ所

※1 NII/NAREGIにSS/RCS (NAREGIv1の予約サービス機能) を設置※2 名古屋大学の管理ノードは、学内サービス向けの設定のまま、IS‐CDAS以下を連携用に追加設定

GridVM En gines－56－Fact Sheet 2: 計算ノード構成
OS

スケジューラgridvms1.hpc.cmc

SX‐8R

SUPER‐UX

NE C NQS‐II

1

0.3

gridvms2.hpc.cmc

x86

Linux

NE C NQS‐II

80.4

アーキテクチャ

大阪大学

TFLOPS

ノード数

gridvms3.hpc.cmc

x86

Linux

NE C NQS‐II

450

16.8

東京工業大学

tggn‐vms2.grp.gsic

x86+ClearSpeed

Linux

S un Gri dEngi ne

120

18.9

九州大学

dpc.kyushu.grid

x86

Linux

PBS Propbg2043

SX‐8SUPER‐UX

NE C NQS‐II2

0.2

pfg1005, png1051, png1053,
png3000

x86

Linux

PBS Pro14

0.1

dpca064.grid, dpca128.grid,
dpcb064.grid, dpcb128.grid,
dpcc128.grid, dpcd048.grid,
dpcd049.grid, dpcd057.grid

x86

Linux

PBS Pro278

3.4

sr11k.grid

POWER5AIX

LoadLev eler

32

3.5

naregi4.cc

x86

Linux

PBS Pro6

0.2

ngrd1.cc

SPARC

SolarisParal lelnavi

2

NII/NAREGI

分子科学研究所

名古屋大学

0.1

0.3
44.1

各拠点の実情に合わせた多様な計算機資源の提供を受けた連携「先駆的なWebサービスだから･･･」
運用が難しいのか!?
9 構成要素間の通信によるサーバの状態遷移z

これまでのNAREGI統合では (たぶん) ログ解析だけ

z

サーバの状態そのものをモニタするツールがない

9 Webサービスの状態遷移を過去に遡って静的解析、動的解析を組み合わせて検証可能なツールを急造!!
z

静的解析: LXR、動的解析: GDBをAjaxでマッシュアップz

輝かしい成果¾ WS‐Notificationが正常に動作するようになった? 過去抱えていた多くの問題が一気に解決!!
¾ コアダンプ時には、事象を引き起こしたメッセージを速やかに特定? 「分子研問題」の解決につながる¾ GridVMサーバとの不整合検出? インストール不良 (二重登録) と判明

SSの「2000年問題」

今回の連携に参加したクラスタ群:
3/26 16:14:28 時点で•17クラスタ• 887ノード

Webサービスのメッセージ交換に

9 統合に支障を来すエラー処理は華麗に(エラーメッセージも出さずに) スルー

よる状態推移をす
べて記録z 統合してとにかく動くことを最優先!?
Webサービスのメッセージ (SOAP
Envelope) を解析す

¾ VO名はURIとして処理されるが、無効な文字列が含まれているといきなりワイルドカード扱い

るためのオプション

投入したジョブが想定 外のクラスタへディスパ ッチされる¾ “CMC_Osaka” → “CMC-Osaka”→ “RENKEI-Osaka”

上記のうち、阪大
CMC の遊休時利用型

z そんなものを現場にもっていっても、いきなり運用できるわけがない･･･

クラスタ (449ノード) の予約マップ

How SS Works:
モニタツールによる監視

東工大TSUBAME 120ノードの予約マップ

ここ のテストのテスト ジョブがジョブがわだ かまってわだ
かまって いて･･･
いて･･･

本当 に動かし たい
ジョブ が実行で きないISによる利用統計情報

Out ofService

W ed Mar 26
21:54:00

T hu Mar 27
09:00:00

How SS Works:
モ ニタツールによる監視- 57 -

資料協力: 九州大学 青柳研究室

Phase‐3:?
資料協力: 大阪大学レーザー エネルギー学研究センター ( 平成19年度CSI委託事業報告交流会 発表予定資料より抜粋)

グリッド認証局“RENKEI‐Osaka”“RENKEI‐Osaka”“RE“RE NKEI‐NKEI‐Osaka”
Osaka”

VO

ドメイン
ドメイン

9 NII/NAREGI認証局 (次年度はNII/GOC認証局)

“vo1”
“vo1”

z

APGrid PMAプロダクション・レベル¾ クラッシック・プロファイル

PKI

9 阪大CMCグリッド認証局

NII/NAREGINII/NAREGI
認証局
認証局

ドメイン
ドメイン

z
阪大 CMC
認証局

APGrid PMA実験レベル¾ 限りなくプロダクション・レベルにある? 登録局での対面による本人確認を要求していない (運用上無理だから)¾ APGrid PMAにMICSプロファイルの導入と適用を交渉中･･･

RO

6拠点
6拠点

九州大学

大阪 大学

名古屋大学

分子科学研究所

東京工業大学z

NII/NAREGINII/NAREGI

阪大CMCの全国共同利用登録者を対象に “1‐Click”でグリッド証明書を発行¾ 既存の全国共同利用の窓口が登録局として機能? 煩雑な業務処理を自動化し、事務員からも利用者からも隠蔽¾ 抜け駆けしたわけではないけれど、気がつけば基盤センターではうちだけ?!

VO: Virtual Organization
RO: Real Organization
PKI: Public Key Infrastructure

グリッド認証局と仮想組織? CA/RA室の維持、人員の配置 (最低6名) など相応のコストが発生･･･

MICSプロファイル

阪大CMCの業務システム

Member Integrated X.509 PKI Credential Service
9 「1年1ヶ月」以上存続している既存の認証基盤と連動してグリッド証明書を発行する
z The initial vetting of identity for any entity in the primaryauthentication system that is valid for certification should be b ased ona face‐to‐face meeting and should be confirmed via photo‐

9 導入例
z TeraGridの NCSA グリッド認証局 ( 仮承認 ?)¾ NCSAがこれまで行ってきた「ピアレビュー」によるアカウント発行の9 共同利用掛が利用者登録に使っている管理者システム (NEC製DEVIAS)z 管理者インターフェイスに、グリッ ド証明書発行に必要な「ライセンスID」の払い出しや「所枠組みを活かすz TACCの グリッド認証局¾ Clas sicプロファイルのグリッド認証局と併存?

identification and /or similar valid official documents .

属VO」の設定項目を追加
z バックエンド処理システムに、Unixアカウントの発行などと同様に、グリッドマップファイルの生成などのグリッド用の処理を追加“IGTF Accrediati on Rev iew of MICS Authenti cation Profile (Update)”by Marg Murr ay, TACC, 2007/05/3 0

更新
期間

VOの普及過程遷移

有効期間: 最長13ヶ月
更新
期間

年度末処理

9 Phase‐0 (2006‐)
z

年度末処理

阪大独自の取り組み¾ すべての利用登録者にGrid PKI証明書を発行 (できるようにLicense IDを発行)?
?

Default VO: “CMC_Osaka”
証明書SubjectDN Q UID 1 課金グループ? grid-mapfileを課金システム “NAVIAS” (仮称) が自動生成

9 Phase‐1 (2007/06‐)z

東工大との連携 (+九大+NII)¾ 阪大へ利用申請し、東工大のUIDを紐付ける?
?

1‐Click

阪大がVOホスティング: “CMCGSIC_Osaka”
証明書SubjectDN@阪大 Q UID@阪大 1 課金グループ@阪大
証明書SubjectDN@阪大 Q UID@東工大 1 課金グループ@東工大? grid-mapfieは手動で変更する必要あり

9 Phase‐2
z

－58－

VO連携

?

ユーザ情報のセキュアな伝達手段の確立が必要?

これらを開発するなら費用負担発生･･･

“Registration Agency” 構想に向けて「夢のグリッド」の実現に向けて原因の一 端は、国 内の計算 機センタ ー組織の構造にもある。米国でも欧州でも、一般 に大学組織内でのグリッド管理は大学内の計算機 センターが担う。しかし、計算機 センターの 性格が、 国内と欧米とでは多少異 なるように思 える。欧 米の大学計算機 センター
はそれ自身が独立した研究組織として機能しており、 学生やポス
ドクを含め、多くの計算科学者を内 部に抱え、新 しい技術の開発

Phase‐0:や導入 を独 自に行う地 力を備え る。これに対し、 （すくなくともこれまでの ）国 内の計算機センターの 多くは 、研究者 を内部に持たず、既存の計算資源を既存の方法で運用するだけベンダーから派遣される SEに依存し、の硬直 した機関 になって いたのではないか。
科学技術 計算の 需要は今 後も増え続けること が予想さ れる。こ阪大CMCの場合

れに対して有限の資源で答えるためには、 グリッド的な技 術を用いて、資源を適切に配分することで、有効に活用していくしかない。そのための大学での受 け皿は 、やは り各 計算機
センター以外 には ないだろう。各計算 機セン ターに適 切な拡 充を行い、 グリッド運用の積 極的な主体とすることが、今 後の計算 科学の発展に必要であると考える。

中田秀基, 「グリッドのこれまでとこれから」京都大学学術情報メディアセンター全国共同利用版［広報］Vol.6 No.2 (Oct. 2007)
国内でグリッ ド技術が普 及しないのは何 故か?!

阪大CMCの取り組み
9 “Grid Operation” を単純化・簡素化し、既存のセンター
運用業務へ取り込むz すべての高性能計算機資源をGrid資源として提供¾ ベクトル型スーパーコンピュータへのミドルウェアの移植

適切なレベルの認証局がない･･･¾ PCクラスタをセンター運用に耐えうる品質に引き上げるz すべての利用登録者にGrid PKI証明書を発行¾ CMC以外の学内共同利用センターからの登録者も含む? レーザーエネルギー学研究センター (ILE)? 核物理研究センター (RCNP)

すべての利用登録者にGrid PKI証明書を発行

すべての高性能計算機資源を
Grid資源として提供
9

9 ローカルスケジューラの統一とNAREGI GridVM対応(CSI委託事業として)z

NAREGI‐CAによるGrid PKIの構築と阪大CMC認証局CP/CPS策定 (v1.0 RC)zz¾ 対応機種SX: SUPER‐UX?

PC Cluster: SuSE Enterprise Linux,
OpenSuSE¾ 多段キュー: Faire Share Queue + Job
Assigned Map?

フェアシェア型定額制?

飽き資源情報の提供と実行予約¾

秘密のCA室¾

本人性の検証・確認は簡素化?

NEC NQS‐II?

AP Grid PMA minimum CA requirements準拠?!

z¾¾

License IDによる申請者の検証を隠蔽
Passphraseによる秘密鍵の暗号化を隠蔽¾

Campus CAからKerberos PKINIT (RFC4556) によるGrid CAへのフェデレーションを視野に業務に乗らない、簡素化・隠蔽できない処理も･･･¾

9- 59 -

失効処理

RA業務を共同利用掛の通常業務に組み込む
z

SXもGrid資源として提供（現時点ではGridMPI未対応）

支払責任者・経理責任者の印鑑で十分じゃないの?!

Web I/FとKerberos認証によるソーシャル・エンジニアリング・フローの簡素化

NEC DEVIAS X NAVIAS (仮称)

認証局 CP/CPS の策定
利 用者の実 在性と同 一性の確 認を申請 責任者が 行なう

遊 休時利用 PCクラスタ
NEC Express‐5800 56Xd

申請責任者が利用者の実在性・同一性を担保
利用者受 付

Not YetInstalled

450‐nodes

16.4 TFLOPS
10.0 TB

18.3 TFLOPS
1.0 TB

申請責任者の確認
大 規模計算 機システ ム利用 申請（証 明書申請 ）

利 用者

導入 初期
|
| 従来
従来 の利用の利用 申請で証
申請で証 明書申請
明書申請 を兼ねを兼ね る
る

申請責 任者

ps
10
Gb ps
10Gb

| 従来 の業務 をベース とする認 証局業 務

1‐ nodeAPGr id P MA に よる “Minimum CA
requi rements” を満た す運用 規程の策 定

支払責 任者

利用者管理
システムDB

5.3 TFLOPS
3.0 TB

NEC SX‐8R

Î 対面によ る本人 性確認を 担保でき ず
これ までは~ 大学 や研究 機関に所 属

8‐nodes~支 払責任者 、経理 責任者の 印鑑（支 払の担保 ）6.1 TFLOPS
2.0 TB

経理責 任者

対面による本人性確認は運用上不可

Local
Authenti cation

CA/RA
CA/RA

Grid
Grid LDAP
LDAP

Total: 46.1 TFLOPS, 16.0 TB

阪大CMCの大規模計算機システム構成

NARE GI Grid Middlewar e β2

VOMS
VOMS

QueuedRunning

Done

UMS
UMS

(CM
(CM C
C Propri
Propri eta
eta ry)ry)

GridVM Ser ver
forfor PC‐Clust
PC‐Clust er
er

MyProxy

MyProxy+

Grid Portal

SS
SS

GridVM Ser ver
forfor PC‐Clust
PC‐Clust er
er
GridVM Ser ver
forfor SXSX

実行順の入れ替え
IS‐NAS
IS‐NAS

user
user

IS‐CDAS
IS‐CDAS

frontend
frontend
login

Local Scheduler:
NEC NQS ‐II
w/JobManipulato r
w/Grid ScheduleMaster

Kerberos KDC

遊休
遊休 時利用P
時利用P C
Cクラスタ
クラスタ
NE C Ex pr ess ‐58 00 5 6 Xd
NE C Ex pr ess ‐58 00 5 6 Xd

16 .4 TF LOP S
10 .0 TB

1 83
. TFL OPS
1 .0 TBp ss
0Gb p
11 0GbNEC SX‐8R

5 .3 T FLOP S
3 .0 T B

6 .1 T FLOP S
2 .0 T B

NAREGI M/W の各コンポー ネントと阪大 CMC の構成との 位置関係

AssignedDone

エスカーレーション

Assigned

バックフィル

Running

Running

Queuedロ ーカルスケジューラNE C NQS ‐II の特徴

ロ ーカルスケジューラNE C NQS ‐IIの特徴

地球シミュレータの運用からの要請T
NEC NQS‐II
w/JobManipulator

sx800
sx801
sx804
sx805
sx806
sx807
sx812
sx813
sx814
sx815
sx816
sx817
sx818
sx819
2007-12-15 11:00|88888888|11111221|14444122|44441122|1122....|14444122|88888888|88888888|16161616|16161616|88888888|88888888|88888888|88888888|
2007-12-15 14:00|88888888|11111221|14444122|44441122|1122....|14444122|88888888|88888888|16161616|16161616|44448888|88888888|88888888|88888888|
2007-12-15 17:00|88888888|11111221|14444122|44441122|1221122.|14444122|88888888|88888888|16161616|16161616|4444....|88888888|88888888|88888888|
2007-12-15 20:00|88888888|1111221.|14444122|44441444|1221....|14444122|88888888|88888888|16161616|16161616|........|88888888|88888888|88888888|
2007-12-15 23:00|88888888|111221..|11444414|14444122|1221....|14444122|88888888|88888888|16161616|16161616|........|88888888|88888888|88888888|
2007-12-16 02:00|88888888|1111221.|11444422|14444122|44441...|14444122|88888888|88888888|16161616|16161616|........|88888888|88888888|88888888|
2007-12-16 05:00|88888888|11221...|14444221|14444122|44444444|14444122|88888888|88888888|16161616|16161616|........|88888888|88888888|88888888|
2007-12-16 08:00|88888888|14444122|14444221|14444122|4444....|11224444|32323232|32323232|16161616|16161616|32323232|88888888|88888888|88888888|
2007-12-16 11:00|88888888|44441221|14444221|14444122|4444....|11224444|32323232|32323232|16161616|16161616|32323232|88888888|32323232|88888888|
2007-12-16 14:00|88888888|44441221|14444221|14444122|4444....|11224444|32323232|32323232|16161616|16161616|32323232|88888888|32323232|........|
2007-12-16 17:00|88888888|44441221|11144444|14444122|4444....|11224444|32323232|32323232|16161616|16161616|32323232|88888888|32323232|........|
2007-12-16 20:00|88888888|44441221|11444422|11114444|4444....|11224444|32323232|32323232|16161616|16161616|32323232|88888888|32323232|........|
2007-12-16 23:00|44444444|44441221|11444422|1111122.|4444....|11224444|32323232|32323232|16161616|16161616|32323232|........|32323232|........|
2007-12-17 02:00|44444444|44441122|11444422|1111122.|4444....|14444122|32323232|32323232|........|........|32323232|........|32323232|........|
2007-12-17 05:00|44448888|44441221|11444422|1111122.|44444444|14444122|........|........|........|........|........|........|........|........|
2007-12-17 08:00|88888888|44444444|11224444|1111122.|4444....|14444122|........|........|........|........|........|........|........|........|
2007-12-17 11:00|88888888|44441221|11224444|1111122.|4444....|14444122|XXXXXXXX|XXXXXXXX|XXXXXXXX|XXXXXXXX|XXXXXXXX|XXXXXXXX|XXXXXXXX|XXXXXXXX|
2007-12-17 14:00|11888888|44441221|11224444|1111122.|4444....|14444122|XXXXXXXX|XXXXXXXX|XXXXXXXX|XXXXXXXX|XXXXXXXX|XXXXXXXX|XXXXXXXX|XXXXXXXX|
2007-12-17 17:00|11144441|44441221|14444224|1111122.|4444....|14444122|XXXXXXXX|XXXXXXXX|XXXXXXXX|XXXXXXXX|XXXXXXXX|XXXXXXXX|XXXXXXXX|XXXXXXXX|
2007-12-17 20:00|11144441|44441221|44444444|1111122.|4444....|11444412|XXXXXXXX|XXXXXXXX|XXXXXXXX|XXXXXXXX|XXXXXXXX|XXXXXXXX|XXXXXXXX|XXXXXXXX|
2007-12-17 23:00|11144441|44441221|44444444|11111122|4444....|11444422|XXXXXXXX|XXXXXXXX|XXXXXXXX|XXXXXXXX|XXXXXXXX|XXXXXXXX|XXXXXXXX|XXXXXXXX|
2007-12-18 02:00|11144441|22444412|44444444|11111221|4444....|11444411|XXXXXXXX|XXXXXXXX|XXXXXXXX|XXXXXXXX|XXXXXXXX|XXXXXXXX|XXXXXXXX|XXXXXXXX|
2007-12-18 05:00|11144441|22444411|44444444|11111221|44444444|11444411|XXXXXXXX|XXXXXXXX|XXXXXXXX|XXXXXXXX|XXXXXXXX|XXXXXXXX|XXXXXXXX|XXXXXXXX|
2007-12-18 08:00|11144441|44442244|4444....|11111221|4444....|1444411.|XXXXXXXX|XXXXXXXX|XXXXXXXX|XXXXXXXX|88888888|44444444|44444444|88888888|
2007-12-18 11:00|11144441|44442211|4444....|11111221|4444....|1444411.|XXXXXXXX|XXXXXXXX|XXXXXXXX|XXXXXXXX|88888888|44444444|44444444|88888888|
2007-12-18 14:00|11144441|44442211|88888888|1111122.|4444....|111.....|XXXXXXXX|XXXXXXXX|XXXXXXXX|XXXXXXXX|88888888|44444444|44444444|88888888|
2007-12-18 17:00|11......|44442211|88888888|1111122.|4444....|111.....|XXXXXXXX|XXXXXXXX|XXXXXXXX|XXXXXXXX|88888888|44444444|44444444|88888888|
2007-12-18 20:00|11......|44442211|88888888|1111122.|4444....|111.....|XXXXXXXX|XXXXXXXX|XXXXXXXX|XXXXXXXX|88888888|44444444|44444444|88888888|
2007-12-18 23:00|11......|44442211|88888888|1111122.|4444....|111.....|XXXXXXXX|XXXXXXXX|XXXXXXXX|XXXXXXXX|88888888|44444444|44444444|88888888|
2007-12-19 02:00|11......|44442211|88888888|111122..|4444....|111.....|XXXXXXXX|XXXXXXXX|XXXXXXXX|XXXXXXXX|88888888|44444444|44444444|88888888|
2007-12-19 05:00|11......|444411..|88888888|111122..|4444....|11......|XXXXXXXX|XXXXXXXX|XXXXXXXX|XXXXXXXX|88888888|44444444|44444444|88888888|
2007-12-19 08:00|11......|44441...|88888888|111122..|........|11......|XXXXXXXX|XXXXXXXX|XXXXXXXX|XXXXXXXX|88888888|44444444|44444444|88888888|
2007-12-19 11:00|11......|1.......|88888888|111122..|........|11......|XXXXXXXX|XXXXXXXX|XXXXXXXX|XXXXXXXX|88888888|44444444|44444444|88888888|
2007-12-19 14:00|11......|1.......|88888888|11122...|........|1.......|XXXXXXXX|XXXXXXXX|XXXXXXXX|XXXXXXXX|88888888|44444444|44444444|88888888|
2007-12-19 17:00|11......|1.......|88888888|11122...|........|1.......|XXXXXXXX|XXXXXXXX|XXXXXXXX|XXXXXXXX|88888888|44444444|44444444|88888888|
2007-12-19 20:00|11......|1.......|88888888|11122...|........|1.......|XXXXXXXX|XXXXXXXX|XXXXXXXX|XXXXXXXX|88888888|44444444|44444444|88888888|
2007-12-19 23:00|11......|1.......|88888888|11122...|........|1.......|XXXXXXXX|XXXXXXXX|XXXXXXXX|XXXXXXXX|88888888|44444444|44444444|88888888|
2007-12-20 02:00|11......|1.......|88888888|1.......|........|1.......|XXXXXXXX|XXXXXXXX|XXXXXXXX|XXXXXXXX|88888888|44444444|44444444|88888888|
2007-12-20 05:00|11......|1.......|88888888|1.......|........|1.......|XXXXXXXX|XXXXXXXX|XXXXXXXX|XXXXXXXX|88888888|44444444|44444444|88888888|
2007-12-20 08:00|11......|1.......|88888888|1.......|........|1.......|XXXXXXXX|XXXXXXXX|XXXXXXXX|XXXXXXXX|88888888|44444444|44444444|88888888|
2007-12-20 11:00|11......|1.......|88888888|1.......|........|1.......|XXXXXXXX|XXXXXXXX|XXXXXXXX|XXXXXXXX|88888888|44444444|44444444|88888888|
2007-12-20 14:00|11......|1.......|88888888|1.......|........|1.......|XXXXXXXX|XXXXXXXX|XXXXXXXX|XXXXXXXX|88888888|44444444|44444444|88888888|
2007-12-20 17:00|11......|1.......|........|1.......|........|1.......|XXXXXXXX|XXXXXXXX|XXXXXXXX|XXXXXXXX|88888888|44444444|44444444|88888888|
2007-12-20 20:00|11......|1.......|........|1.......|........|1.......|XXXXXXXX|XXXXXXXX|XXXXXXXX|XXXXXXXX|88888888|44444444|44444444|88888888|
2007-12-20 23:00|11......|1.......|........|1.......|........|1.......|XXXXXXXX|XXXXXXXX|XXXXXXXX|XXXXXXXX|88888888|44444444|44444444|88888888|
2007-12-21 02:00|11......|1.......|........|1.......|........|1.......|XXXXXXXX|XXXXXXXX|XXXXXXXX|XXXXXXXX|88888888|44444444|44444444|88888888|
2007-12-21 05:00|11......|1.......|........|1.......|........|1.......|XXXXXXXX|XXXXXXXX|XXXXXXXX|XXXXXXXX|88888888|44444444|44444444|88888888|
2007-12-21 08:00|11......|1.......|........|1.......|........|........|XXXXXXXX|XXXXXXXX|XXXXXXXX|XXXXXXXX|88888888|44444444|44444444|88888888|
2007-12-21 11:00|11......|1.......|........|1.......|........|........|XXXXXXXX|XXXXXXXX|XXXXXXXX|XXXXXXXX|88888888|44444444|44444444|88888888|
2007-12-21 14:00|11......|1.......|........|1.......|........|........|XXXXXXXX|XXXXXXXX|XXXXXXXX|XXXXXXXX|88888888|44444444|44444444|88888888|
2007-12-21 17:00|11......|1.......|........|1.......|........|........|XXXXXXXX|XXXXXXXX|XXXXXXXX|XXXXXXXX|88888888|44444444|44444444|88888888|
2007-12-21 20:00|11......|1.......|........|1.......|........|........|XXXXXXXX|XXXXXXXX|XXXXXXXX|XXXXXXXX|88888888|44444444|44444444|88888888|
2007-12-21 23:00|11......|1.......|........|........|........|........|XXXXXXXX|XXXXXXXX|XXXXXXXX|XXXXXXXX|88888888|44444444|44444444|88888888|
2007-12-22 02:00|11......|1.......|........|........|........|........|XXXXXXXX|XXXXXXXX|XXXXXXXX|XXXXXXXX|88888888|44444444|44444444|88888888|
2007-12-22 05:00|11......|........|........|........|........|........|XXXXXXXX|XXXXXXXX|XXXXXXXX|XXXXXXXX|88888888|44444444|44444444|88888888|
2007-12-22 08:00|1.......|........|........|........|........|........|XXXXXXXX|XXXXXXXX|XXXXXXXX|XXXXXXXX|88888888|44444444|44444444|88888888|
2007-12-22 11:00|1.......|........|........|........|........|........|XXXXXXXX|XXXXXXXX|XXXXXXXX|XXXXXXXX|88888888|44444444|44444444|88888888|
2007-12-22 14:00|1.......|........|........|........|........|........|XXXXXXXX|XXXXXXXX|XXXXXXXX|XXXXXXXX|88888888|44444444|44444444|88888888|
2007-12-22 17:00|........|........|........|........|........|........|XXXXXXXX|XXXXXXXX|XXXXXXXX|XXXXXXXX|88888888|44444444|44444444|88888888|
2007-12-22 20:00|........|........|........|........|........|........|XXXXXXXX|XXXXXXXX|XXXXXXXX|XXXXXXXX|88888888|44444444|44444444|88888888|
2007-12-22 23:00|........|........|........|........|........|........|XXXXXXXX|XXXXXXXX|XXXXXXXX|XXXXXXXX|88888888|44444444|44444444|88888888|
2007-12-23 02:00|........|........|........|........|........|........|XXXXXXXX|XXXXXXXX|XXXXXXXX|XXXXXXXX|88888888|44444444|44444444|88888888|
2007-12-23 05:00|........|........|........|........|........|........|XXXXXXXX|XXXXXXXX|XXXXXXXX|XXXXXXXX|88888888|44444444|44444444|88888888|

6‐months
6‐months

6‐months
6‐months•資源予約単位を、ノード毎からCPU毎に拡張•伴って、メモリの資源管理も可能
100TFLOPS集まらなかったのは･･･－60－

5.4. 九州大学導入報告
報告者：九州大学情報基盤研究開発センター）南里豪志
平成 20 年 7 月から平成 21 年 3 月にかけて、全国の情報基盤センター群への NAREGI ミドルウ
ェア配備、及び運用準備を目的として、NAREGI 運用実験が行われた。今回の実験における目標
は、以下の 2 点である。
・ 「ミニマム構成」による NAREGI のセンター間動作実験
・ 業務フロー「グリッドパック」の策定
このうちミニマム構成は、今回の実験に向けて策定した、NAREGI ミドルウェアの最小限の機能を用いた最もシンプルな構成であり、具体的な内容は以下の通りである。
・ VO は 1 個のみとする。
・ Portal、IS、SS 等の管理ノード群は全体で 1 組する。
・ 各センターは演算ノードのみを提供する。
これらのうち管理ノード群は全て NII に設置された GOC(Grid Operation Center) で運用する。
なお、NAREGI ミドルウェアのインストールに当たっては、九州大学で開発したインストールツールを用いた。これは、複雑な NAREGI ミドルウェアの各ノードへのインストールを、パッケージ管理ツー
ル YUM (もしくは APT) を用いて半自動的に行うものである。このツールにより、従来数ヵ月かかっていたインストール作業を 1 日で完了させることができるようになった。
今回の運用実験に参加した大学は、北海道大学、東北大学、筑波大学、東京大学、東京工業大学、名古屋大学、京都大学、大阪大学、九州大学の 9 大学であり、それぞれ、共同利用計算機資源の一部を本実験用に提供した。なお、資源を運用から分離して提供するか、もしくは運用中の資源をこの実験経由でも利用可能とするかは、各大学の都合で選択できることとした。例えば九州大
学では、運用から分離した計算ノード 12 台を提供した。各ノードはローカルネットワークで接続されており、さらにこのうち 1 ノードは、ゲートウェイとして、本実験用の VPN とも接続している。
さらに、このミニマム構成の NAREGI 環境が正しく構築されていることを確認するためのツールとして、「ミニマム構成テストスイート」が開発された。
これは、CUI による Single Sigh On、テストジョブ投入、及び実行状況の確認を行うものである。
このツールを用い、全参加組織で NAREGI のミニマム構成の基本動作を確認した。
一方、「グリッドパック」の策定に当たって、各大学における利用申請等の業務フローを参考に、新規利用申請及び変更申請について、利用者、第 1 センター、GOC 及び第 2 センターそれぞれの役
割と処理の流れを明確化した。提出された利用申請書を受理したセンターを第 1 センター、利用申
請暑中で利用希望のあったセンターのうち第 1 センター以外のセンターを第 2 センターと呼ぶ。また、
グリッドパックでは、全センターで一意に利用者を特定するために GPID(Grid Pack ID)と呼ばれるID を定義する。グリッドパックによる新規利用申請の流れは、以下の図 5-4 の通りである。

図 5-4：グリットパックによる新規申請の流れ- 61 -

こ の 中 で 「 DN(Distinguish Name) 情 報 取 得 」 は 、 GOC と の 間 で バ ー ジ ョ ン 管 理 シ ス テ ム
SVN(Subversion)を用いて行う。これは定期的(1 日 1 回程度)に行うことを想定しているため、ツールとしてまとめている。なお、SVN の利用にはパスフレーズの入力が必要であるため、安全のため
このツールの起動は毎回手動で行っている。
DN 情報に変更があった場合、「grid-mapfile 設定」を行う。この grid-mapfile の更新手段は大学毎に異なる。ちなみに九州大学ではこの grid-mapfile 更新用のツールを開発、公開しており、北海
道大学、東北大学、東京工業大学、名古屋大学が、このツールを各大学の状況に合わせて修正して利用している。
以上のように、各大学でミニマム構成による NAREGI 動作実験と、グリッドパックによる業務フローの策定を行った。これにより、実運用のための基盤を確立できた。今後は実運用に向けた課題の抽出とその解決を行い、将来の本運用を目指す。
添付資料 ・・・第 5 回会合（2009 年 1 月 21 日）報告

¬ グリッドコンピューテ ィング研究会において７センターへのNAREGI配備・運用に向けた検討開始¬ 2008年7月¬ グリッドタスクフォース発足¬ グリッドコンピューティング研究会の中¬ 主査： 青柳グリッドコンピューテ ィング研究会主査

大学間NAREGI運用実験¬ 参加大学： ７センター＋東京工業大＋筑波大＋NII

九州大学 南里豪志¬ 東京工業大：大阪大 学との連携運用デモを実施済み¬ 筑波大：T2Kの枠組みでグリッドミドルウェアの使用を検討中
2

各大学の計算機資源
機 種名¬ 平成20年度末までに、各参加大学の計算機環境に

北 海道 大 学OS

HITA CHI H A8 000
DEL L P o we rE dge R 200

Cen tOS 5

S U PE R -UX ve r18 .1

スケ ジュー ラ

分離 型／ 一 体運 用型

P B S P ro9

分 離型
3 0ノード (約6 0CP U )N QS Ⅱ ver 2.50

一 体運 用型

Jo b Manipu lat or ver 1.20

最 大4 ノード( 64CP U)

NAREGIミドルウェアを配備し、運用の準備を整える。

東北 大学

NEC S X -9

¬ 「ミニマム構成」による運用実験の実施¬ NAREGIの基本機能 を用いた最もシンプルな構成を選択

筑波 大学

A ppro X t re meS er ver -X 3

R H EL 5

Gr id E ngine

東京 大学

HITA C HI H A8 000 -t c/R S 425

R H EL 5

日立 OS C NQS
ま たは 独自 イ ンス トー ル

分 離型
8 ノード( 128 CPU)

S un N1 Gr id E ngin e 6 .1
東工 大 カスタ マイ ズ版

一 体運 用型
未定

東 京工 業大 学¬ 「グリッドパック」の策定

名 古屋 大 学¬ 利用者の利用申請から証明書発行、利用開始を経て利用終了 ま

京都 大学

での業務フローと実施体 制
大阪 大学

九州 大学

Su n F ire X 460 0

S LE S 9(2 008 /10 SL ES 10 S P 2 に移行 )一 体運 用型
最 大3 2ノード (51 2CP U )Fujit su PR I MER GY R X 20 0 S 3/ S2

Cen tOS 5 .2

P B S P ro9 .1

Fujit su PR I ME POW ER HP C 2 500

S olar is 8

P ar allelnavi 2.3

2 ノード( 64CP U )Fujit su HX6 00

R H EL A S 4

P ar allelnavi 3

分 離型
4 ノード( 64CP U )6 ノード( 12CP U )NEC S X -8 R

S U PE R -UX ve r17 .1

N QS Ⅱ ver 2.40

一 体運 用型

Jo b Manipu lat or

最 大8 ノード( 64CP U)

NEC S X -9 R

S U PE R -UX ve r18 .1

N QS Ⅱ ver 2.50
Jo b Manipu lat or

一 体運 用型
最 大8 ノード( 128 C PU)

NEC E xpr ess 580 0/1 20R g-1

S LE S 10.1

N QS Ⅱ ver 2.40
Jo b Manipu lat or

一 体運 用型
最 大3 2ノード (12 8CP U )Fujit su PR I MER GY R X 20 0 S 3

R H EL WS 4

P B S P ro9 .2.2

分 離型
1 2ノード (48 CPU)
合計

4

3

スケジュール

ミニマム構成¬ NAREGI v1.x の必要最小限なコンポーネントを選択¬ 今回，データグリッドは保留¬ VOは 1つのみ
¬ Portal, IS, SS等の管理ノード群も全体で 1組¬ 各センターは演算ノードのみを提供¬ 管理ノード群は GOC(NII)で運用¬ 演算ノードは実運用から切り出しても良い¬ Firewall問題回避のため，L3-VPNによる専用線を利用

5

6- 62 -

演 算性 能( GFL OP S )63 8.4

6,55 3.6

4,71 0.4

1,17 7.6

49 0.858 8.816,89 6.0

57 6.031,63 1.6

NAREGI v1.x のコンポーネント

ミニマム構成の例¬¬ Case 1: IS-?CDASを各セン¬

Por tal¬

GVS (Gri d Visu al iza ti on S yste m)¬¬

WFT (Wo rk Flow To ol )PS E (Prob le m Solv ing Envi ron men t)

ターに配置¬ 計算ノード数が大きい場合

IS ( Information Service)¬¬¬ 利用統計を各センターで独自

N AS (No de Agg reg atio n Ser vice ){MS }CD AS ({Mon ito rin g, S ucce ssive }C el ld oma in Ag gre ga tion S ervi ce¬

SS Scheduler)¬

CA (Certification Authority),
RA (Registration Authority)¬

UMS (User Management Server),
VOMS (VO Membership Service)¬

GVM{SE} (Grid Virtual Machine{Scheduler, Engine})¬

LRPS (Local Resource Provider Service)に行う場合¬ Case 2:IS-?CDASをNIIのみに配置¬ 小規模（? 30ノード程度）向き

87

実験環境構成図

グリッドパック¬ コンポーネント間の通信に多数の¬ グリッド運用に向けた業務フローの策定

ポートを使用¬ 利用申請? 利用開始? 利用終了

¬ Firewall問題の回避¬ 基本方針¬ 今回は、L3-VPNにより本実験専¬ 今までのセンターでの業務フローを出来るだけ踏襲

用のネットワークを整備¬ 利用者は１回の手続きで利用可能に¬ GOC: センター間に跨がる事項への対応を担当¬ 課金については平成21年度以降に検討¬ 平成21年度は課金無 しで試験運用

10

9

業務フロー案 

今回の実験環境構築¬ 利用申請書：¬ 各センターの申請書をマージし¬ 主な作業：

インスト ールスクリプトの実行と，各種設定ファイルの転送たものを用意¬ 設定ファイルの編集は、¬ 証明書の運用手段：¬ LRA(Local RA)による運用¬ 利用者は全ての作業を最寄りのセンターで行う¬ 証明書発行時に対面認証¬ 少なくともH21年度中は必須¬ 各センターは、これに応じてグ
リッドマップファイルを更新

ほぼ不要

¬ 担当：
¬ 管理ノード群：NII¬ 演算ノード群：各セン
ター

12

11

NAREGIミドルウェア v1.1.xのインストーラ

九大センターの実験環境¬ 階層的なパッケージ管理ツール¬ ノード間管理層:ノード間でグリッドサービス設定¬ ノード内管理層:ノード内のパッケージ管理（YUM or APT)ベース¬ 計算機：¬ Fujitsu PRIMERGY RX200 S3¬ Intel Xeon 3.0GHz 4core, 8GB RAM¬ インストール作業の効率が飛躍的に向上¬ ノード数 12¬ コマンド数:100以下¬ インターコネク ト InfiniBand（NAREGI β: 4,529)¬ 所要時間：１日程度（NAREGI β: 約5ヶ月）¬ XMLの編集： 0（NAREGI β: 119）
¬ 特にミスを大幅に低減¬ 対応OS¬ RHEL4, CentOS5,
OpenSuSE10¬ ソフトウェア：¬ OS RedH at Enterprise Linux WS4¬ PBS Pro9.2.2¬ 一般運用から分離して提供
出典：“グリッドミ ドル ウェア の階層的管理機構による N AREGI イン ストーラ の設計と実装”,
壬生亮太, 小林泰三, 大庭淳一, 高見利也,上田将嗣,山元 祐介, 増 原裕之, 天野 浩文, 青柳 睦,
情報処理学会杯パフォ ーマン スコン ピューティ ング研究会 HPC-118-4, 2008年12月

1314- 63 -

九大センター環境のネットワーク

導入時の主なトラブル¬ 演算ノードの１つをNATとして、全ノードから実験用VPNへの¬ PBS Proでジョブが実行されない

アクセス確保

¬ PBS Proのライセンスをホスト名で 登録していた¬ インストール時のRPM取得と¬ NAREGIの全ノードは hostnameとして FQDNを設定するため、

IS-NASへの SBC IS-handleの通信に必要

PBS Proのライセンスを認識できなかった

実験用VPN¬ ライセンスファイル中で FQDNに書き換え て解決
local network¬ ライセンスの再取得は 不要

CSI‐
GRID

¬ NATが使えない¬ IPフォワーディングが無効になっていた¬ RHELのデフォルト設定

NAT
PBS

…

GVMS
GVME(1)

GVME(2)

node 1

node 2

GVME(12)15

node 12¬ あとは、ルーテ ィングの設定ミス程度

/home

16

まとめ
¬ NAREGI運用実験¬ 「ミニマム構成」を選定¬ 各大学で作業中¬ グリッドパック¬ 実運用に向けたワークフローの策定¬ 九大センターでの実験環境構築¬ インストーラにより、ほぼ順調に進捗

17

添付資料 ・・・第 6 回会合（2009 年 8 月 18 日）報告

構成
¬ NAREGIミニマム構成実験の概要¬ 九州大学のNAREGI実験環境

九州大学における
NAREGI実験環境¬ グリッド利用申請フロー「グリッドパック」

2009年8月18日 富士通SS研グリッドWG
九州大学 南里豪志¬ グリッド利用者情報編集支援ツール gmap_tool{1,2}2

各大学の計算機資源
機 種名¬ 平成20年度末までに、各参加大学の計算機環境に¬ 「ミニマム構成」による運用実験の実施¬ NAREGIの基本機能を用いた最 もシンプルな構成を選択

東北 大学

N EC S X -9

S UPE R -U X ve r18 .1

筑波 大学

A ppro X t re meS er ver -X 3

R HEL 5

Gr id E ngine

東京 大学

HITA CH I H A8 000 -t c/R S 425

R HEL 5

日立 OS CN QSまたは 独自 イ ンス トー ル

分 離型
8 ノード( 128 C PU)

Su n F ire X 460 0

S LE S 9(2 008 /10 SL ES 10 S P 2 に移行 )S un N1 Gr id E ngin e 6 .1
東工 大 カス タ マ イ ズ版

一 体運 用型
未定

名 古屋 大 学¬ 利用者の 利用申請から 証明書発行、利用 開始を経て利用終了 ま分離 型／ 一 体運 用型

C en tOS 5

東 京工 業大 学¬ 「グリッドパック」の策定

ス ケ ジ ュー ラ

HITA CH I H A8 000
DEL L P o we rE dge R 200

北 海道 大 学

NAREGIミドルウェアを配備し、運用の準備を整える。

OS

(再掲)

京都 大学

での業務 フローと実施体制
大阪 大学

九州 大学

P B S P ro9

分 離型
3 0ノード (約6 0CP U)

NQS Ⅱ ver 2.50

一 体運 用型

Jo b Manipu lat or ver 1.20

最 大4 ノード( 64C P U)
一 体運 用型
最 大3 2ノード (51 2CP U)

Fujit su PR I MER GY R X 20 0 S 3/ S2

C en tOS 5 .2

P B S P ro9 .1

Fujit su PR I ME POW ER HP C2 500

S olar is 8

P ar allelnavi 2.3

2 ノード( 64CP U)

Fujit su HX6 00

R HEL A S 4

P ar allelnavi 3

分 離型
4 ノード( 64CP U)

NEC S X -8 R

S UPE R -U X ve r17 .1

NEC S X -9 R

S UPE R -U X ve r18 .1

NEC E xpr ess 580 0/1 20R g-1

S LE S 10.1

Fujit su PR I MER GY R X 20 0 S 3NQS Ⅱ ver 2.40

R HEL WS 4

6 ノード( 12CP U)

最 大8 ノード( 64C P U)
一 体運 用型
最 大8 ノード( 128 CPU )NQS Ⅱ ver 2.40

一 体運 用型

Jo b Manipu lat or

最 大3 2ノード (12 8CP U)
分 離型
1 2ノード (48 C PU)
合計

4

3

- 64 -

63 8.4

6,55 3.6

4,71 0.4

1,17 7.6

49 0.858 8.8一 体運 用型

Jo b Manipu lat or
NQS Ⅱ ver 2.50
Jo b Manipu lat or

P B S P ro9 .2.2

演 算性 能( GFL OP S )16,89 6.0

57 6.031,63 1.6

ミニマム構成

NAREGIミドルウェア v1.xのインストーラ(再掲)(再掲)¬ 階層的なパッケージ管理ツール¬ ノード間管理層:ノード間でグリッドサービス設定¬ ノード内管理層:ノード内のパッケージ管理（YUM or APT)ベース¬ NAREGI v1.x の必要最小限なコンポーネントを選択¬ 今回，データグリッドは保留¬ インストール作業の¬ VOは 1つのみ

効率が飛躍的に向上¬ コマンド数:100以下¬ Portal, IS, SS等の管理ノード群も全体で 1組（NAREGI β: 4,529)¬ 所要時間：１日程度¬ 各センターは演算ノードのみを提供¬ 管理ノード群は GOC(NII)で運用（NAREGI β: 約5ヶ月）¬ XMLの編集： 0（NAREGI β: 119）
¬ 特にミスを大幅に低減¬ 演算ノードは実運用から切り出しても良い¬ Firewall問題回避のため，L3-VPNによる専用線を利用
出典：“グリッドミ ドル ウェア の階層的管理機構による N AREGI イン ストーラ の設計と実装”,
壬生亮太, 小林泰三, 大庭淳一, 高見利也,上田将嗣,山元 祐介, 増 原裕之, 天野 浩文, 青柳 睦,
情報処理学会杯パフォ ーマン スコン ピューティ ング研究会HPC-118-4, 2008年12月

5

九大センターの実験環境

6

九大センター環境のネットワーク(再掲)(再掲)¬ 演算ノードの１つをNATとして、全ノードから実験用VPNへの¬ 計算機：¬ Fujitsu PRIMERGY RX200 S3

アクセス確保¬ インストール時のRPM取得と¬ Intel Xeon 3.0GHz 4core, 8GB RAM

IS-NASへの SBC IS-handleの通信に必要¬ ノード数 12

実験用VPN¬ インターコネク ト InfiniBandlocal network
CSI‐
GRID

¬ ソフトウェア：¬ OS RedH at Enterprise Linux WS4¬ PBS Pro9.2.2

NAT
PBS

¬ 一般運用から分離して提供

7

…

GVMS
GVME(1)

GVME(2)

node 1

node 2

GVME(12)/home

node 128NAREGIの改良

ミニマム構成テストスイート¬ 九大の環境（RedHat Enterprise Linux 4 x86_64）¬ ミニマム構成のNAREGI環境が正しく構築されて いることを確認のサポート追加¬ NAREGIの全コンポーネントに対して追加¬ CUIによる SSO，テストジョブ投入，実行状況確認（Portal, IS, SS, GVMS, GVME etc.）¬ 将来，一般利用者でも実行可能なように管理者権限は不要¬ RPMで 提供¬ 現バージョンNAREGI-1.1.3のサポート対象：¬ CentOS5/i386，openSuSE10/x86_64¬ CentOS5 (i386, x86_64(32bitで動作))¬ 確認状況：¬ RedHat Enterprise Linux 5 (i386, x86_64(32bitで動作))¬ 以下の全参加組織で基本動作を確認：¬ RedHat Enterprise Linux 4 (x86_64)

北大，東北大，筑波大，東大，東工大，名大，京大，阪大，九大¬ openSuSE10 (x86_64)

109

利用申請業務フロー「グリッドパック」

新規利用申請の流れ
利用者¬ 新規利用申請及び変更申請について，

申請書提出

利用者，第1センター，GOC, 第2センター
それぞれの役割と処理の流れを明確化

第1センター

第2センター

GOC

本人確認・受理
GPID作成登録依頼

受理申請書, LRAの署名,
GPID¬ GOC及び全センター共通の GPID(Grid Pack ID) を定義

CAのライセンス¬ 利用者を一意に特定するためのID¬ 組織間で利用者に関する情報を共有する際に便利

アカウント作成

受理

CN (Common
Name)
アカウント作成
DN情報取得grid-mapfile 設定完了¬ 利用者の手続きを出来るだけ減らすよう設計

DN作成
GPID, DNの対を登録

DN情報取得

VOに登録

grid-mapfile 設定

第1センターのアカウント完了
GPIDと利用可能ノード情報
第2センターのアカウント11- 65 -

完了
12九州大学における利用登録

Gridユーザテーブル¬ 通常：¬ Gridの利用者情報を管理するため，

１．利用者情報登録
２．アカウント作成
３．利用承認書送付

利用者管理データベースに新設¬ 内容：¬ グリッドパック：

１．利用者情報登録 ＋ Gridユーザテーブル登録
２．アカウント作成
３．DN情報の取得
４． grid-mapfile編集
５．利用承認書を利用者に送付し，GOCに完了通知

ラベル

名称

備考

USRNO

ローカルアカウント

主キー

GPID

グリッドパックID

DN

ユーザDN

MFLG01

計算機別利用フラグ１

計算機群１

MFLG02

計算機別利用フラグ２

計算機群２

MFLG03

計算機別利用フラグ３

計算機群３

PROCID

処理区分

処理中／有効／無効

PGSTDATE

登録日

EDRNWLDT

レコード処理日

13

14

利用者登録（と削除）処理の流れ

DN更新情報取得ツール (gmap_tool1)とgrid-mapfile更新ツール(gmap_tool2)¬ DN情報に対する変更を¬ 1日1回程度実行し，GOCにおける利用者情報の変更を

九大のシステムに反映させる

抽出し，Gridユーザテーブル
及び grid-mapfileを更新¬ Gridユーザテーブルの修正：¬ 基本的に主導で起動し，毎回パスフレーズを入力¬ 別途，安全な接続が確保できれば cronによる自動化も可

九大の利用者管理DBツールを利用¬ GOCとのDN情報の共有にはバージョン管理システム

SVN(Subversion) を利用¬ DN更新情報の取得，

grid-mapfileの更新：
ツールを新たに作成

1615

gmap_tool1 によるDN更新情報取得

gmap_tool2 による
grid-mapfileの更新

1. フラグ判定：「処理中」のフラグが立っていなければ

1. フラグ判定：「処理中」のフラグが立っていて，grid-mapfile

以下の処理を実行

更新用データファイルがある場合に以下の処理を実行

2. DN情報の取得：GOCの Svn から自センターの DNの

2. 全Grid演算サーバに対し，ssh + sudo で grid-mapfileのエ

最新のリストを取得

ントリ削除及び追加

3. 差分情報の抽出：前回のリストと比較し，更新があれば「処理3. 更新後のgrid-mapfileと，GOCにおける最新のDN情報とを中」のフラグを立てる

比較し，整合性を確認

4. 利用者管理DB用の差分ファイルを作成：

4. 「処理中」のフラグを下し，作業終了を全国共同利用担当者

削除項目と追加項目に分けて作成にメールで通知5. 全国共同利用担当者にメールで通知：

担当者はgrid-mapfile更新用にLN(Local Name)情報を付与
1817

gmap_tool2 の他サイトでの利用まとめと今後の予定¬ grid-mapfile は前演算ノードでの設定が必要¬ NAREGIミニマム構成実験¬ 基本的な動作を確認¬ いくつかの便利なツールを開発¬ インストールツール¬ DN情報更新ツール⇒ 自動化したい¬ しかし，grid-mapfile の更新手段はサイトごとに異なる。

（利用者情報を管理する方法の違い）⇒ サイトごとに異なるツール¬ 今後のグリッドタスクフォース 全体の予定：

実運用に向けた課題の抽出とその解決¬ 今回，九大向けに開発したツールを公開¬ 課金回り¬ 北大，東北大，東工大，名大で は，このツールを多少修正し¬ 九州大学の予定：¬ SR16000の対応¬ 主にインストールツールの調整て利用可能¬ 阪大は別途作成

1920- 66 -

5.5. 名古屋大学導入事例
報告者：名古屋大学情報基盤センター）津田知子
名古屋大学情報基盤センターでは、グリッドの実証実験として、NAREGI グリッドミドルウェアを用いてグリッド環境を構築してきた。2006 年度の NAREGI ミドルウェアのα版のインストールから始まり、2007 年度には、β版による 6 拠点の連携接続実証実験にも参加した。2008 年秋には、全国共同利用情報基盤センターである 7 つのセンター、国立情報学研究所、東京工業大学および筑波大学の 10 機関によるグリッド配備／運用プロジェクトが始まった。これらの経緯を踏まえて、WG では
その時点における名古屋大学情報基盤センターのグリッド環境の現状を報告するとともに、問題点を提示した。

5.5.1. NAREGI グリッドミドルウェアによるグリッド環境の構築
NAREGI グリッドミドルウェア V1 による実験環境の構築と問題点
NAREGI ミドルウェア V1.0 と V1.1 におけるインストール及び利用上の問題点とその原因及び対処について述べるとともに、データグリッドにおける問題点も提示した。
2) 10 機関によるグリッド配備／運用計画と接続での問題点
3) H21.10 以降の名大のグリッド環境について

1)

添付資料 ・・・第 5 回会合（2009 年 1 月 21 日）報告
【SS研Grid Computing検討WG ‘09 .1.21】• ＮＡＲＥＧＩグリッドミドルウェアＶ１による実験環境の構築と問題点

NAREGIグリッドミドルウェアによるグリッド環境の構築• １０機関によるグリッド配備／運用計画と接続での問題点
名古屋大学情報連携基盤センター
津田 知子

NAREGIグリッドミドルウェアV1版実験環境

金田研

名古屋大学情報連携基盤センター

GridVM
SI NET3

CSI-GRID

データ
グリッド(CentOS) (gfar m-fs)

MPLS（B)
202.241.97.12

202.241.97.129

データグリッド<gvms1>

Catalyst

計算
Node<gfsrm-vo>
202 .241.97.142

HUB<voms >

202.241.97.141(S Linux)<iscdas ><isnas >2 02.2 41.97 .135

IS-CDAS
Node

IS-NAS
Node

202.241.97 .130

SS Node(CentOS) 202.241.97.132

300GB<gvms 1>
<gvmc1-1> <vgmc1-2>
GridVM Node
計算
計算
＆
Node
Node
計算Node202.241.97.1 31<ss ><grid-portal>2 02.2 41.97 .134
Potal
Node
133.6.90.83

n agoya-vo2

計算
Node

計算ノード×４

202.241.97.141

GridVM
データ
グリッド

計算ノード×４

202.241.97.138 20 2.24 1.97.139 202 .241.97.140

データ
グリッド
(gfarm-fs)

データグリッド <gfarm-fs>

金田研

太陽研
GridVM

計算
Node

データ
グリッド
(Gfarm-fs)

キャンパスLAN（NICE）

太陽研
GridVM

計算
Node<dguft>

900GB(CentOS)計算
Node<gfsr m-vo>

2 02.24 1.97.136 202 .241.97.137<gvmc1-3> <gvmc1-4> <gvmc1-5>
計算
Node

計算
Node

計算
Node

<gvmc1-3> <gvmc1-4> <gvmc1-5>

202 .241.97.1494506<gvmc1-1> <vgmc1-2>

GridVM Node＆
計算Node<dguft>133.6.90.28
202.241.97.158

VOMS

ＶＯ構成

<gfarm- fs>

nagoya-vo3

Xeon 3.2GHz×5
Xeon 3.0GHz×1
メモリ：2 GB／node
Total : 152Gflop s

nagoya-vo1- 67 -

NAREGIグリッドミドルウェアでの問題点（その１）＜NAREGI V1.0＞--- 2008.8 ～ 2008.10---

NAREGIグリッドミドルウェアでの問題点（その２）

項番

内容

原因と対処

１

PSEのメニューでAction Status
Browse the action statusを選択したときエラーとなる。

pse_dbというデータベースが存在 していないため。（未解決）

Register Ap plicationでプログラムの登録ができない。
WFTにてWo rking Directoryを指定するとジョブがException。

同上

２

３

＜NAREGI V1.1＞--- 2008.11 ～
項番

内容

１

ジョブをsu bmitすると” Cannot get
proxy Certification from
MyProxy,” のエラー

Grid VM管理ノードのファイル（自動生成）に「” 」が2つあり、grid-mapfileの内容と異なったため。
DNにスペースを含んでいたため。
O=Nagoya University

４

ISのCPUグラフが表示されない。

５

ISでCPUグラフ表示をし、Sign out V1.1では 解決していた。
した後、再度グラフを表示させると、HTTPステ ータス500のエラー。

grid-mapfileの記述を
emailAddress=からE=に変更

原因と対処

V1.1のUMSは証明書 にE-Mailの項目が含まれていると、正常に動作しない。UM Sノードが 動作しているScientific Linuxと他のノードが 動作しているCen tOSのOpen sslのバー
ジョンの違いが原因。
E=を指定 しない証明書を用いることで 対処。
PSEのRegister Application の証明書のDNの項目にスペースがResource Requirement でShow
含まれる場合と最新のPESを使用
Serversを行 うとエラー。また、して いる場合に発生。
Compile Applicationでも同様のエ PSEのアップデートとISハンドルのラー。
再作成で対処。

２＜Data Grid＞
項番

内容

原因と対処

３

NIIのホスト証明書を取得時に“SSL Send alert:[Fatal alert]
BAD_CERTIFICATEのエラー証明書取得にあたって NIIのRA証
明書をインポートすべきところをCA
証明書をインポートしていたため

４

ISでHTTPステータス500の エラー

メモリ不足が原因か？
Portalで一 度ヒープメモリ不足の現象が発生すると、回復手段なし。
サービスの再起動で対処。
Portalノードの 推奨メモリは2GB以上。名大センターのPortalのメモリ
は2GB。

北海道大学

予定されている演算ノード群

HITACHI HA8000 × 13
DELL PowerEdge R200 × 17

筑波大学

GOC@NII

原因と対処

１

DGAMS設定ファイルのファイルのアップロード時のファイルサイズ上
限値のパラメータにて対処。
1GB → 2GB

２

1 GB のファイルのダウンロードで
約 25％のところで必ず失敗。

・メモリリークの可能性のあるモジュールの修正 を行ったが未解 決。
・GridFTP Clientにてタイムアウトエ
ラー発生のため。モジュールを置き換えて解 決。

３

Datagrid Access Man agemn t
Systemにアクセス できない。

dguftノードのファイルシステムが100%になっていたため。
データグリッドで転送したファイルがゴミとして残っ ていたため（修正を検討中）。

IS-NAS

NEC SX-9（1ノードあたり16CPU、
1.6Tflops、Mem:1TB）＜分離：2、一体：最大 4＞

IS-CDAS

東京工業大学HIT ACHI HA8000-tc/R425

Portal1. 名大センターでは、APGrid PMA プロダクションレベルのNII
認証局の証明書を使用する(サーバ、ユーザ共に）。
2. 本人確認の手続きをスムーズにおこなうため、LRA（ローカル登録局）を設置。
3. ＮＩＩから取得したサーバ用証明書を配置。
4. ＮＩＩのＤＮＳに逆引きの設定依頼。
5. 基盤センターＶＯ環境に名大の演算ノード群追加。

Sun-Fire X4600（ノードあたり16コア、153.6Gflops、Me m：32GB)
＜一体＞

東京大学

SS

NII＠GOCの管理ノードへの接続

Appro XtermeServer-X3（ノードあたり16コア、147.2Gflops、Mem：32GB）＜一体：32?＞

東北大学

UMS/
VOMS

内容
1 GB のファイルのアップロードでエ ラー。

基盤センターＶＯ

グリッド配備／運用計画（平成21年度実施予定）

CA/RA

項番

京都大学

名古屋大学

Fujitsu HX600× 4（1ノードあたり16コア、147.2Gflops、Mem：32GB）

富士通 PRIMERGY RX200 S2×5
富士通 PRIMERGY RX200 S3×1

大阪大学

九州大学

NEC SX-8R （一体：最大8）
NEC SX-9 （一体：最大8）NEC Express 5800/120Rg-1＜一体：最大32＞

富士通 PRIMERGY RX200 S3（1ノードあたり4コア、
48Gflops、Mem：8GB）＜追加での問題点＞¾ ＮＩＩ@GOCから名大の演算ノードが見えない（LRPSも認識しない）。
－インストーラによるインストールの失敗が原因か？－（名大のNAREGI管理システムへの影響）¾ Portalノード上のデータグリッドに関係したファイルが初期化された。
¾ ＷＦＴでユーザが作成したＷＦ Ｔ用のファイルが初期化された。
¾ 管理ノードIS-NASにて大量のログ出力。
¾ 演算ノードでのGridMPIジョブ実行不可。

利用者
第 1回グリッ ド配 備・運用タス クフォース会 議（‘08.9.1 7)資料より

名大センターの新システム（‘09.5.18～）
ス ーパー
コンピュータＳ１
SPARC Ent erpris e M9000
× 2ノード（128core、メモリ：1TB/
ノード）

スーパーコンピュータ
Ｓ３

アプリ
サーバ

スーパー
コンピュータＳ２／ノード）
FX1 × 768ノード（4core、メモリ：32GB／ノード

GridVM

1.15PB

MPLS（B)
202.241.97.12

データグリッド<gfarm- fs><dguft>133.6.90.28
202.241.97.158

Catal yst

202 .241.97.149

3750E<gfsrm-vo>
202 .241.97.142

HUB

202 .241.97.141

VOMS

HX600 × 152ノード（16core、メモリ：64GB／ノード(S Linux)<iscdas ><isnas >2 02.2 41.97 .135

IS-CDAS
Node

IS-NAS
Node

202.241.97 .130

202.241.97.1 31<ss >Solaris用
ログインノードSPARC Enterprise
M9000

SI NET3
DWDM

202.241.97.129<voms >

(54)

(256)

CSI-GRID

データ
グリッド(CentOS) (gfar m-fs)（１
６）

名古屋大学情報連携基盤センター

グリッド環境（H21.10以降）

金田研

CSI-GRID

SS NodeＬｉｎｕｘ用ログインノード(CentOS) 202.241.97.132<gvms 1>
<gvmc1-1> <vgmc1-2>
GridVM Node
計算
計算
＆
Node
Node
計算Node<grid-portal>2 02.2 41.97 .134
Potal
Node
133.6.90.83

2 02.24 1.97.136 202 .241.97.137<gvmc1-3> <gvmc1-4> <gvmc1-5>
計算
Node

計算
Node

計算
Node

202.241.97.138 20 2.24 1.97.139 202 .241.97.140

キャンパスLAN（NICE）

キャンパスＬＡＮ

スーパーコンピュータ
システム2
HX600 16ノード

300TB- 68 -

HX600 ×16
(Opteron 2.5GHz)
メモリ： 64GB／node
Total : 2560Gflops(CentOS)太陽研
GridVM
計算ノード×４

データ
グリッド(gfarm-fs)

300GB

グリッド配備／運用計画（平成21年度実施予定）

基盤センターＶＯ
北海道大学

予定 され ている演算ノード群

HITACHI HA8000 × 13
DELL PowerEdge R200 × 17

GOC@NII

東北大学
IS-NAS

IS-CDASCA/RA

NEC SX-9（1ノードあたり16CPU、
1.6Tflops、Mem:1TB）＜分離：2、一体：最大 4＞

東京大学
UMS/
VOMS

SS
PortalHIT ACHI HA8000-tc/R425

筑波大学
Appro XtermeServer-X3（ノードあたり16コア、147.2Gflops、Mem：32GB）＜一体：32?＞

東京工業大学
Sun-Fire X4600（ノードあたり16コア、153.6Gflops、Me m：32GB)
＜一体＞

京都大学

名古屋大学

Fujitsu HX600× 4（1ノードあたり16コア、147.2Gflops、Mem：32GB）

Fujitsu HX600 × 16 （H21.10）
富士通 PRIMERGY RX200 S2×5
富士通 PRIMERGY RX200 S3×1

大阪大学
NEC SX-8R （一体：最大8）
NEC SX-9 （一体：最大8）NEC Expr ess 5800/120Rg-1＜一体：最大32＞

九州大学
富士通 PRIME RGY RX200 S3（1ノードあたり4コア 、
48Gflops、Mem：8GB）

利用者

5.5.2. 名大でのグリッド配備の現状
10 機関によるグリッド配備／運用の名大での現状
第 5 回の WG での接続に関する事後報告と 8 月に行ったインストーラによる V1.1.3 への update
およびグリッド配備／運用プロジェクトで行われたグリッドパック申請処理に関する名大での取り組みを報告した。
2) 名大で構築しているデータグリッドの現状と問題点
名古屋大学では、情報基盤センターの他に、太陽地球環境研究所および計算理工学の金田研究室でも NAREGI によるグリッド環境を構築している。太陽研では地球磁気圏のシミュレーション
データを金田研では乱流のシミュレーションデータをデータグリッドとして構築している。ここでは、データグリッドの利用シナリオを示すとともに実際に使用しての河野氏（太陽地球環境研究所）の感想を紹介した。
3) 10 月からの名大のグリッド配備の構成
名古屋大学情報基盤センターでは、5 月と 10 月にスーパーコンピュータの機種更新が行われる。
それに伴い、10 月には、スーパーコンピュータ HX600 の 16 ノード（2.56Tflops）をグリッド配備の演算サーバとして提供予定であることを紹介した。

1)

添付資料 ・・・第 6 回会合（2009 年 8 月 18 日）報告
【SS研Grid Computing検討WG ‘09 .8.18 】

Ⅰ．１０機関によるグリッド配備／運用の名大での現状

名大でのグリッド配備の現状

Ⅱ．データグリッドについて
Ⅲ．１０月からの名大のグリッド配備の構成

名古屋大学情報基盤センター
津田 知子- 69 -

基盤センターＶＯ
csi-grid-cc

グリッド配備／運用（平成21年度実施）

北海道大学

予定されている演算ノード群

HITACHI HA8000 × 13
DELL PowerEdge R200 × 17

Ⅰ．１０機関によるグリッド配備／運用の名大での現状

GOC@NII
IS-NAS

NEC SX-9（1ノードあたり16CPU、
1.6Tflops、Mem:1TB）＜分離：2、一体：最大 4＞

IS-CDAS

CA/RA¾ 前回ＷＧでの報告以後の状況¾ v1.1.3へのupdateについて¾ グリッドパック申請の状況

筑波大学
Appro XtermeServer-X3（ノードあたり16コア、147.2Gflops、Mem：32GB）＜一体：32?＞東北大学

東京工業大学Sun- Fir e X4600 × 10
（ノードあたり16コア、153.6Gflops、Me m：32GB)
＜一体＞

東京大学
UMS/
VOMS

HIT ACHI HA8000-tc/R425

SS
Portal

京都大学

名古屋大学

Fujitsu HX600× 4（1ノードあたり16コア、147.2Gflops、Mem：32GB）

富士通 PRIMERGY RX200 S2×5
富士通 PRIMERGY RX200 S3×1

大阪大学

九州大学

NEC SX-8R （一体：最大8）
NEC SX-9 （一体：最大8）NEC Express 5800/120Rg-1＜一体：最大32＞

富士通 PRIMERGY RX200 S3（1ノードあたり4コア、
48Gflops、Mem：8GB）

利用者
第 1回グリッ ド配 備・運用タス クフォース会 議（‘08.9.1 7)資料より

NAREGIグリッドミドルウェアV1版実験環境

金田研

名古屋大学情報基盤センター

GridVM

NII＠GOCの管理ノードへの接続での問題点

MPLS（B)
202.241.97.12

202.241.97.129
Catalyst

202 .241.97.149

4506<gfsrm-vo>
202 .241.97.142

HUB<voms >

202.241.97.141

VOMS

ＮＩＩ@GOCから名大の演算ノードが見えない（LRPSも認識しない）。

(S Linux)<iscdas >2 02.2 41.97 .135

IS-CDAS
Node

IS-NAS
Node

2 02.2 41.97 .134

SS Node(CentOS) 202.241.97.132（原因２） インストーラによるアップデートの手順に問題があったことにより、
GVMSの設定ファイルのパラメ ータが空白となり、IS-NAS
ノードの データベースが情報を正常に取得できなかった。

<grid-portal>
Potal
Node

<gvmc1-3> <gvmc1-4> <gvmc1-5>

キャンパスLAN（NICE）

計算ノード×４

計算
Node<gvmc1-3> <gvmc1-4> <gvmc1-5>
計算
Noden agoya-vo2

計算
Node

計算
Node

データグリッド <gfarm-fs><dguft><gfsr m-vo>
金田研

太陽研
GridVM

GridVM

202.241.97.141

データ
グリッド

計算ノード×４
データ
グリッド(Gfarm-fs)

データ
グリッド
(gfarm-fs)

Xeon 3.2GHz×5
Xeon 3.0GHz×1
メモリ：2 GB／node
Total : 152Gflop s

アップデートの手順 全てのノードでOSのupdateをコマンドベースで実施
 インスローラによる演算ノードの追加を実施↓
インストーラによる演算ノード群のインストール処理が飛ばされた。
↓
GVMSの設定ファイルのパラメータが空白となった。
↓
IS-NASノードのデータベースが情報を正常に取得できなかった。
↓
 NII@GOCへの接続不可
 名大のNAREGI管理システムで不具合発生<gvmc1-1> <vgmc1-2>
計算
Node

計算
Node

900GB

太陽研
GridVM<gvms1>

計算
Node202.241.97.138 20 2.24 1.97.139 202 .241.97.140(CentOS)

GridVM Node＆
計算Node

計算
Node

計算
Node

2 02.24 1.97.136 202 .241.97.137

計算
Node

133.6.90.83

300GB<gvmc1-1> <vgmc1-2>

GridVM Node＆
計算Node202.241.97.1 31<ss >（原因１） 名大のGridVM管理ノードがフィルタリングしていた。

<gvms 1><isnas >202.241.97 .130

ＶＯ構成

データグリッド <gfarm- fs><dguft>133.6.90.28
202.241.97.158＜前回のWGでの報告＞
基盤センターＶＯ(csi-grid-cc)に名大の演算ノード群追加。
¾

SI NET3

CSI-GRID

データ
グリッド(CentOS) (gfar m-fs)

情 報基盤センター¾¾¾¾

nagoya-vo3

VOのリストが初期化された。
Portalノード上のデータグリッドに関係したファイルが初期化された。
WFTでユーザが作成したWFT用のファイルが初期化された。
名大の演算ノードでGridMPIの実行不可。

nagoya-vo1【グリッドパック申請処理】
通常のアカウント登録処理に以下の処理を追加¾ LRA担当者による本人確認¾ Gridユーザ情報の管理
グリッドパック整理番号（GPID）とローカルアカウントの対応付け¾ GOCへの書類発送¾ 第二センターへの申請書類の送付¾ GOCのDBからのDN情報の取得(gmap_tool1)
GOCではDN情報はsvnで管理¾ grid-mapfileの編集(gmap_tool2)¾ GOCへの設定完了通知の送付

インストーラによるV1.1.3へのupdate 8/5,6に実施
 ＶＯのリストが初期化されることを除いて、正常に更新作業が終了した。
（インストーラは、複数ＶＯをサポートしていないため）（ここでの書類送付は、メールにて実施）【名大へのグリッドパック申請状況】（8/17現在）
第1センター登録： 2
第2センター登録： 20
grid-map登録完： 21- 70 -

九大の小林先生が作成されたツールをセンター用にカスタマイズして使用データグリッド構築環境
SI NET3

CSI-GRID
202.241.97.129
133.6.90.28
202.241.97.158

Ⅱ．データグリッドについて

Catalyst

4506

金田研

HUB

<voms >VOMS
(S Linux)<iscdas ><isnas >2 02.2 41.97 .135

IS-CDAS
Node

IS-NAS
Node

202.241.97 .130

データグリッド <gfarm-fs><dguf t>202.241.97.1 31<ss >SS Node(CentOS)202.241.97.1 49<gfsrm-vo><grid-portal>
Potal
Node

(CentOS) 202.241.97.132

データ
グリッド
( gfarm-fs)

202.241.97.1 42
202.241.97.1 41

1.5T B

300GB

133.6.90.83

名古屋大学情報基盤センター

キャンパスLAN（NICE）
太陽研

地球 磁気圏のシミュレーション
データ(CentOS)

データ
グリッド(gfarm-fs)

データグリッドの利用のシナリオ

2.4TB

データグリッドでの使いにくいところ
・ データ加工のプログラム
・ 可視化プログラ ム

名古屋大学太陽地球環境研究所ジオスペース研究センター
河野 貴久さんの報告より（’09.3.31まで名古屋大学情報連携基盤センター）

ＷＦＴ

Portal 画面で複 数ファイルやディレクトリを選 択してのインポートが不可。（複数の ファイルを扱う場合は、アーカイブにしてファイル数を減らして対処した。）

機能 面

Portal 画面でメタデータにコ メントを付加することができるが、データが大量にある場合には入力が面倒。

操作 性

データ
グリッド

乱流の
シミュレーション
データ

・ 観測データ・ スパコンの計算結 果

データグリッドでファイルを削除して も画面の情報が自動的に更新されない（手動でReloadボタンを押す必要あり）

データ
グリッド

実際の動き
使用環境によっては、画 面のレイアウトがおかしくなる。
（Linux のFirefox）

NAREGIミドルウェアV1.1.3環境

計算科学センター

GridVM
CSI-GRID

データ
グリッド(Red Hat E nterpr ise
Linux4)
Catalyst3750E

HUB<voms >

～演算ノード：実験環境から運用環境へ～

gvms-hx.cc.nagoya -u.a c.jp
202.241.97.136

133.6.90.28
202.241.97.158

VOMS

名古屋大学情報基盤センター’09.10.1

202.241.97.129(CentOS)

Ⅲ．１０月からの名大のグリッド配備の構成

SI NET3
DWDM

gvms1.cc.nago ya-u.ac. jp(S Linux)<iscdas >2 02.2 41.97 .135

IS-CDAS
Node

スーパ ー
コンピュータ
HX600<isnas >IS-NAS
Node

202.241.97 .130

202.241.97.1 31

GridVM Node＆
計算Node<grid-portal> 202.241.97.134
Potal
e
計算
Node

<ss >

SS Node(CentOS) 202.241.97.132

133.6.90.83(CentOS)

16ノード(2.56Tflops)
20TB

N

Node

データグリッ ド <gfarm- fs><gvmc1-1> ～ <gvmc1-5>
900GB<dguft>202.241.97.149(CentOS)太陽研
GridVM
計算ノード×４

Ⅳ．おわりに 基盤センターＶＯの利用環境はほぼ整った。
 グリッド環境をどのように利用促進していくのか？

- 71 -

データ
グリッド(Gfarm-fs )キャンパスLAN（NICE）<gfsrm-vo>
202.241.97.142
202.241.97.141 300GB(152Gflops)5.6. 京都大学学術情報メディアセンターのグリッドへの取り組み
報告者：京都大学学術情報メディアセンター）岩下武史

5.6.1. はじめに
京都大学学術情報メディアセンターでは従来から NAREGI、ITBL によるグリッド形成実験に参画してきた。しかしながら、2008 年 5 月以前はスーパーコンピュータの OS が Solaris であったこともあり、別途用意した PC サーバ等における実証実験に留まっていた。一方、2008 年度において、国立情報学研究所と 7 大学センター、筑波大学、東京工業大学によるグリッドタスクフォースがグリッド研究会の下に組織化され、NAREGI ミドルウェアによるグリッドの運用に向けた議論が開始された。
また、京都大学センターでは、筑波大学、東京大学と連携した所謂 T2K の枠組みにおいて、
Globus ミドルウェアによる T2K グリッドの構築に 2007 年度より取り組んだ。これらの取り組みについて以下に簡単に述べる。

5.6.2. NAREGINAREGI によるグリッド環境の構築には上記、タスクフォースの主導のもとで、行った。具体的には京大センター所有の富士通製 HX600 に NAREGI ミドルウェアをインストールし、国立情報学研究所で設定した VO に参加することにより、上記タスクフォースに参加した各機関のサーバがNAREGI のポータル上で利用可能となった。本取り組みにおいて以下の問題が生じたので付記する。まず、HX600 で利用している Redhat Linux AS V4 およびジョブスケジューラ NQS は NAREGIの対応 OS、スケジューラではないという問題あった。そこで、ジョブスケジューラ PBSpro を別途購入し、HX600 上にインストールするとともに、一部の NAREGI ソフトウェアのソースコードを京大セン
ター技術職員が分析、改変することにより、NAREGI のインストールを可能とした。また、京大センタ
ーでは運用マシンの一部を専用クラスタコースの枠組みで NAREGI グリッドに資源提供しているが、その過程で、NQS と NAREGI の不整合の問題が生じている。NQS（Paranavi）はジョブ管理に留ま
らず、HX600 計算ノードの監視や電源管理といった計算ノードの運転に関わるすべてに関わっている。従って、NAREGI グリッドを運用マシンで利用するためには Paranavi と NAREGI が共存できる必要があるが、一例で言えばノードを識別するための hostname をどうするかというような点で両者に不整合が生じる現状がある。従って、今後さらに NAREGI ソフトウェアを運用マシン（HX600）で活用するには本課題を解決することが必要となる。

5.6.3. T2K グリッド
T2K グリッドでは、2008 年 4 月までに Linux PC による Globus、gfarm に基づいたシングルサイ
ンオン、分散ファイルシステムの構築の実現を行った。なお、京大センターではセンター自身が利用者向けの証明書を当面、発行しない方針としており、利用するには筑波大学あるいは東京大学で証明書を取得する必要がある。次に、2008 年 6 月の HX600 導入後、運用マシンにおける Globus、
gfarm の導入を行った。本導入は技術系職員が行ったが、大きな問題は生じなかった。次に、GRAM インターフェースにて、NQS が利用可能となるようにした。本件については、GRAM のモジュール等の分析、ログ生成プログラムの作成など、技術系職員の多大な尽力により、最終的に可能となった。現在、GRAM の RSL ファイルの記述により、NQS に対してジョブを投入、ステータス確認、
ジョブ消去ができるようになっており、キュー名やプロセス、スレッド数の指定などの NQS パラメータの記述もできるようになっている。上記 T2K グリッドで利用できるサービスについては、実際にユー
ザに東大との連携が可能であることを確認してもらっている。

- 72 -

5.7. ９大学情報基盤センターへのグリッド配備・運用
報告：国立情報学研究所リサーチグリッド研究開発センター）合田憲人
国立情報学研究所(NII)では、大学の全国共同利用情報基盤センター等との連携し、サイバー・サ
イエンス・インフラストラクチャ(CSI： Cyber Science Infrastructure)の構築を推進している[1]。CSI
は、全国の大学・研究機関等が有しているコンピュータ等の設備、基盤的ソフトウェア、学術コンテンツ／データベース、人材、研究グループそのものを超高速ネットワーク上で共有する最先端の学術情報基盤である。グリッドは、CSI の基盤を構成する技術の一つとして位置づけられており、2003 年
より NII を中心としてグリッドミドルウェア(NAREGI ミドルウェア)の開発が行われた[2]。2008 年には、NAREGI ミドルウェア Ver.1.0 が公開され、北海道大学、東北大学、筑波大学、東京大学、東京工業大学、名古屋大学、京都大学、大阪大学、九州大学の情報基盤センターが運用するスーパーコンピ
ュータへの NAREGI ミドルウェアの導入および試験運用が開始されている。
9 大学によるグリッド試験運用では、各大学が計算資源プロバイダとしての役割を持ち、NII はオ
ペレーションセンターとしての役割を担っている。具体的には、9 大学は、各自が運用するスーパーコンピュータの一部を NAREGI 環境の計算資源として提供し、NII では情報サービス、ブローカリン
グ、ポータル等のグリッドサービスを提供するサーバを運用している。また NII では、これらサーバ群の運用の他に、NAREGI ミドルウェアの運用者や利用者に対するヘルプデスク業務、グリッド認証
局業務も行っている。
グリッドの運用では、ミドルウェアの導入・運用に加えて、ユーザ管理などの管理業務を確立することも重要な課題である。本試験運用では、ユーザが最寄りの情報基盤センターで申請を行うことにより、グリッド用のユーザ証明書および最大 9 大学のローカルアカウントを取得可能なユーザ管理方式を提案し、現在試験運用を行っている。
本試験運用では、現在、NAREGI ミドルウェアの運用性評価およびユーザ管理業務の評価を進めている。今後、課金方法に関する議論等を行い、本格運用に向けて準備を進める予定である。
参考文献：[1] Cyber Science Infrastructure, http://csi.nii.ac.jp/[2] National Research Grid Initiative, http://www.naregi.org/
添付資料 ・・・第 6 回会合（2009 年 8 月 18 日）報告
2

概要
サイバーサイエンスインフラストラクチャ（CSI）
9大学情報基盤センターでのグリッド配備・運用

９大学情報基盤センターへのグリッド配備・運用

まとめ

合田 憲人
国立情報学研究所

Kento Aida, National Institute of Informatic s- 73 -

サイバーサイエンスインフラストラクチャ（CSI）

サイバーサイエンスインフラストラクチャ（続）3

最先端学術情報基盤
大学等や研究機関が有しているコンピュータ等の設備，基盤的ソフトウェア，コンテンツ及び
データベース，人材，研究グループそのものを超高速ネットワークの上で共有．
サービス

Industry/Societal Feedback¾ネットワーク，認証，グリッド

Virtual Labs
Live Co llabo rations

NAREGI: National Research Grid Initiative

UPKI: National Research PKI Infrastructure

SINET3: Lambda-based
Academic Networking
Backbone

Hok ka ido -U●

Kyo to -U★

（T itech, Wase da-U, KEK, e tc.)

6

9大学情報基盤センターグリッド
CSIにおけるグリッド本格運用に向けて¾2008年秋¾2009年春

NLS

研究機関

グリッド運用 支援

グリッド¾NAREGI middleware V.1.1.3
9ミドルウェアの機能・品質を実運用の視点で評価する．
9運用者・ユーザからの声を収集
9品質向上

情報基盤センターグリッド
9大学情 報基 盤センター間でのNAREGIミドルウェアVer.1.1を用いたグリッド試験運用の開始（2009年春）NIS
National Infrastructure System

運用¾情報基盤センターにおけるグリッド運用のための課
題検討

研究室

LLS

SINET

Laboratory Level System

キックオフ
試験運用開始ミドルウェア

NAREGIミドルウェア を用いたグリッド管理者／利用者向け支 援の開始
（2008年秋）

EU, US, …

連携の拡大

Os aka -U

Kento Aida, National Institute of Informatic s

National Leadership System

LLS，NIS，国際グリッド間の連携を実現する新しいミ
ドルウェア研究開発を目的とした“RENKEI”プロジェ
クトの開始（2008年秋）

To ho ku -U
T o kyo -U

5

次世代スーパーコンピュータ

情報基盤
センター

Ｎ ＩＩ

Nag o ya- U

Kento Aida, National Institute of Informatic se‐サイエンスのための
ミドルウェア・運用技術に関する研究開発
グリッドミドルウェア

★

★

☆ ★
★

★
★

Kyu sh u- U

NAREGIミドルウェア
Ver.1.1の公開（2008年秋）

International Infrastructural Collaboration

NII- REO (Repository of Elect ronic
Journals and On lin e Publicat ions
GeNii (Global Environment fo r
Networked Intellectual Informat ion)

4

9ユーザ管理，課金，…

サイバーサイエンスインフラ ストラクチャにおける計算資源
Kento Aida, National Institute of Informatic s

Kento Aida, National Institute of Informatic s

78

ジョブ実行シナリオ

NAREGIミドルウェア

Application requirement definition

CA/RA

MPI 1.0/2.0

Gr id PSE
Grid
PSE ACS

Grid
Grid Visualizati
Visualization
on
Grid
Gri
d Workflow Tool

CIM
Super
Information Service
Super Scheduler
OGSA
OGSA
JSDL
-EMS
-DAI
OGSAWSRF
WSRF（（NAREGI implementati
WSRF
implementationon ++ Globus 4)
RUS

a: Sign-on
Data Grid
Grid

User
cert.

GridFTPGFS… Co-allocation
Job

WFT
1: Submission

GVS

8 : Visua lization

2: Resource discovery

Super
Scheduler

In formation
Service

3: Reservation (Co-Allocation)

XKMS
9: Accoun ting
GridVM
5: IMPI starts
Local
Scheduler

security

VOMS

SuperSINET

Research
Organizations

IMPI
Serveretc

Site ρ

Computing Resources
Kento Aida, National Institute of Informatic s
9

参加組織
計算機資源プロバイダFMO
P C c ul st er
12 8 CP U s

Outpu t files(User DN, VO)

X.509

IMS

c : Edit

PSE

MyProxyRI SM
S M P mach ni e
64 CP U s

GridMP I

VOMSProxy cert.

Grid VM
Grid
VM

NII

I MPI

b: Deployment
PortalGr
Grid
id
Programming
Progr amming
LibrarLi braries
ies-- GridRPC
GridRPC
GridRPC-- GridMPI
GridMPI

Input files

Workflow

MPI
sourceGridGrid-Enabl
Enabl ed NanoNano-Appl
Applicati
ications
ons• 北海道大学情報基盤センター

GridVM
6: MPI job starts
Local
Scheduler
7: MPI init.
GridMPI

GridVM

Network
monitor

RISM
Job
Si te α4: Reserva tion
Local
Scheduler
FMO
Job

DataGrid

2: Monitoring

Site μGrid File System

Kento Aida, National Institute of Informatic s

ネットワーク（SINET3）

10

http://www.sinet.ad.jp/

運用センター• 国立情報学研究所リサーチグリッド
研究開発センター•名古屋大学情報基盤センター• 東北大学サイバーサイエ ンスセンター•九州大学情報基盤研究開発センター

SI NET3• 京都大学学術情報メディアセンター• 大阪大学サイバーメディアセンター• 筑波大学計算科学研究センター• 東京大学情報基盤センター• 東京工業大学学術国際情報センター

Kento Aida, National Institute of Informatic s- 74 -

Kento Aida, National Institute of Informatic s

11

12

計算機資源

VO設定

computer center

計算ノード（情報基盤センター）

IS‐CDAS¾計算サービス¾Linuxクラスタ（CentOS 5.2 + PBS Pro 9.1 / OpenSUSE+ Sun Grid Engine） x8¾ベクトル計算機 （NEC SX） x2

PortalGridV M
GridVM
engineGridVM
engineGridVM
engineengine管理ノード（NII）

DG‐UFT

IS‐CDAS

DG‐DRMS‐SVSS

GridVMscheduler
GridVM
GridVM
engineGridVM
engineGridVM
engineengineIS‐NAS

computer center¾グリッドサービス（セキュリティ，情報サービス，ブローカリング，ポータル，…）¾Linux計算ノード（CentOS 5.2）

UMS/VOMS

WF
WF

GridVM

SINET3

NAREGI CA

IS‐CDASCA

GridVMschedulerRA

GridV M
GridVM
engineGridVM
engineGridVM
engineengineKento Aida, National Institute of Informatic s

Kento Aida, National Institute of Informatic s
14

13

ヘルプデスクNAREGI認証局

オンラインサポート

CSI参加組織（含ユーザ）向けのグリッド認証局
運用¾電子メールによる受付¾リクエストトラッカによる進捗管理¾クライアント（ユーザ）証明書，サーバ証明書サービス

Asia Pacific Grid Policy Management Authority(APGrid PMA)認定¾NAREGIミドルウェアのインストールおよび運用支援¾グリッド運用上の問題関するコンサルティング¾NAREGIミドルウェアの問題点の収集

情報基盤センターとの連携¾情報基盤センターや研究機関でのLRA（ローカル登録局）の運用9NAREGI開発者との連携¾ドキュメント作成・公開

Kento Aida, National Institute of Informatic s

Kento Aida, National Institute of Informatic s
16

15

ユーザ管理

ユーザアカウント申請
offline co mmunicationo nline co mmunication

Computer Center A

Userユーザアカウント申請

account
request¾ユーザが9枚のユーザアカウント申請書を書くのは大変．
¾ユーザがグリッド証明書申請のためにNIIまで来るのは大変．

Computer Center B …
acco untrequest+GPID

admin.

admin.
user
account

grid‐mapfileの作成

user
account¾ローカルアカウントの管理方針は情報基盤センター毎に異なる．

課金

Kento Aida, National Institute of Informatic s

グリッド証明書とgrid‐mapfile
Computer Center A

User

F2F interview

LRA
operator18

スケジュールoffline co mmun icationcert.
req uest+
GPID

UMS acct+passwd+
licens e ID

LRAadmin.

Computer Center B…
NAREG I Po rtal

09/2008

online co mmun ication

NII

cert.
requestKento Aida, National Institute of Informatic s

17

ミドルウェア開発

GPID‐DN
list

LRA
admin.

computeradmin.
GPID‐DN
list

UMS
GPID‐DN
list<GPID> <DN>
<GPID> <DN>
<GPID> <DN>

computeradmin.
GPID‐DNlist

SVN repo.
grid‐mapfileミドルウェアの機能・品質 向上

試験運用準備
9ユーザ管理方針
9ツール<GPID> <LN>
<GPID> <LN>

cert.

<GPID> <LN>
<GPID> <LN>

04/2010

9大学情報基盤センターへの展開

NAREGI CA
system

UMS acct+passwd+
license ID
GPID‐DN
list

05/2009

試験運用（ユーザ限定）
9ミドルウェア評価
9評価結果の フィードバック
9無料
本格運用に向 けた検討
9ツール
9課金方法

運用拡大

grid‐
mapfileKento Aida, National Institute of Informatic s- 75 -

Kento Aida, National Institute of Informatic s

19

まとめ
NIIでは，最先端学術情報基盤（CSI）の構築を進
行中．
¾ネットワーク，認証，グリッド

9大学情報基盤センターでは，NAREGIミドルウェ
アを用いたグリッド試験運用を開始．
¾グリッドの実運用の視点でのNAREGIミドルウェアの評価¾情報基盤センターにおけるグリッド運用上の課題検討．

Kento Aida, National Institute of Informatic s- 76 -

6. おわりに2 年強の活動を振り返ると、当初の計画に沿って活動が行われたと思われます。Grid 技術に関する多くの技術紹介は会員間での情報共有に有効でした。この WG 活動期間中に Grid
Computing と広い範囲で共通の考え方として Cloud Computing という言葉が世の中に広まり、現在ではこの言葉の方が広く使われる状況になっています。Grid の定義はかなり明解ですが、Cloud の方は広く使われているわりに、人によって意味するところが異なる場合も多いと思われます。したがって、Cloud computing 技術のサーベイの紹介を受け、Grid と Cloud の間の区別についてのイメージを固めるために会員間の情報共有に貢献したと思われます。
NAREGI プロジェクトの現状と今後についても、詳細に紹介を受けました。本 WG 開催中に NAREGI 開発プロジェクトは一応終焉し、情報学研究所には運用を継続するグループは立
ち上がりました。会員による Grid 技術の先行導入事例や、NAREGI を応用した事例が報告されました。大学間 NAREGI 運用実験とそこでの PKI（Public Key Infrastructure）に基づく、証明書の発行、ユーザ認証についての事例の紹介がありました。
国立大学センターの会員はこのグループと連携しながら、さらに別途 7 センターグリッド研究会での活動を維持し、NAREGI ソフトウェアの試験的な導入と運用を行いました。その成果が本 WG で報告されました。
これらの実運用実績により、NAREGI ソフトウェアの評価と問題点の指摘がありました。今後の NAREGI ソフトウエアの基盤整備にも役に立つものと信じます。
技 術 的 な 検 討 課 題 と し て 、 複 数 の 認 証 局 の 下 で 複 数 の 証 明 書 に よ っ て VO （ Virtualorganization）の中での認証管理運用をいかに簡便に行うか、複数 VO のスムーズな実運用が可能かなど問題点も残されています。今後の NAREGI のフル機能を実現した時の問題点でのフィードバックを期待したいと思います。
以上のような活動により、本 WG は当初目的を達成し、今後、教育や研究において Grid 技術が活用され発展することを WG 会員は期待しています。
活動期間中に WG 活動に協力いただいた会員各位、すべての話題提供者の方々、とくに非会員にも関わらず先進的な話題を提供頂いた方々、実証試験に協力した頂いた各機関の技術者・研究者の皆さん、さらに活動を支えていただいた SS 研事務局の皆さんに、深く感謝します。
2009 年 10 月吉日
まとめ役 内田 啓一郎- 77 -

【発行】 サイエンティフィック・システム研究会【編集】 Grid Computing 検討 WG◆ ◆ ◆＜連絡先＞ サイエンティフィック・システム研究会 事務局〒105-7123 東京都港区東新橋 1-5-2
TEL：03-6252-2582 FAX：03-6252-2934
e-mail：ssken@ssken.gr.jp

http://www.ssken.gr.jp/MAINSITE/※ 記載の会社名、製品名、名称などの固有名詞は各社の商標または登録商標です。
※ 著作権は各原稿の著者または所属機関に帰属します。無断転載を禁じます。
※ SS 研会員限定情報を含むため、SS 研会員にのみ配布しております。