大規模で不均質なグリッドを 簡便に利用するための枠組み

大規模で不均質なグリッドを 簡便に利用するための枠組み

渡邊 啓正

電気通信大学 大学院情報システム学研究科 博士 ( 工学 ) の学位申請論文

2008 年 3 月

大規模で不均質なグリッドを 簡便に利用するための枠組み

博士論文審査委員会

主査 本多 弘樹 教授

委員 曽和 将容 教授

委員 加藤 聰彦 教授

委員 出澤 正徳 教授

委員 吉永 努 准教授

著作権所有者 渡邊 啓正

2008

Frameworks for Using

Large-scale Heterogeneous Grid Handily Hiromasa WATANABE

Abstract

 In high performance computing for scientific technologies, “grid” is watched with keen interest, which constructs one compound computer system combining compu- tational resources over wide area network. Improving handiness is an important issue in grid. Since computers (servers) in grid are heterogeneous in point of ma- chine composition and each is administrated along with individual site policy, grid users have to use servers while adapting to machine composition and administra- tion policy. In grid that consists of many servers, cost for the adaptive use is huge.

Therefore, it is important to reduce such burdens for improving handiness of grid.

In this paper, frameworks for reducing above-mentioned burdens are proposed.

They focus on “deployment” and “execution” work for grid applications, which strongly need handiness for users. The two frameworks have the following features.

( 1 ) Relis-G: a framework for automatic library deployment

• Relis-G enables users to deploy a library to servers simultaneously and automatically with fewer burdens than conventional manual method. Es- pecially, it can deploy with very few burdens in frequent deployment like debugging.

• In order to reduce user’s burdens for learning know-how about making a library portable, Relis-G provides users with library deployment system that automatically adds portability to a machine-dependent library.

• Relis-G provides users with library deployment system that deploys while automatically adapting to server’s administration policy (such as usage rule of secondary memory).

( 2 ) F-Omega: a framework for dynamic server change in grid applications

• In order to free users from complicated adaptation work to server sta- tus change, F-Omega enables grid applications to automatically changes servers appropriately that cooperate with server monitoring system.

• For automatic monitoring of server status change corresponding to com- plex server use agreement like advanced reservation, which has been man- ually managed by users and server administrators until now, F-Omega provides users with automatic monitoring system for server administra- tion schedule.

• To free application developers from complicated implementation work about server management, F-Omega provides automatic server manage- ment module for GridRPC applications.

For verifying effectiveness of the proposed frameworks, each of them was imple- mented as middleware, and its application experiment was performed.

Results of Relis-G application experiment in actual grid show that the middle- ware reduces user’s burdens to deploy sample libraries. They also show that the library portabilization function and the administration policy automatic adapta- tion function enable users to deploy without considering servers’ composition and administration policy.

In F-Omega application experiment, F-Omega middleware implementation is ap- plied to a sample grid application, and it is executed in experimental grid environ- ment. While servers’ status changes per several hours, the application automatically changes its servers appropriately and runs successfully over 2.8 days.

As future works for Relis-G, I indicated need for development of on-demand auto- matic deployment function for dynamically-specified servers. For F-Omega, I indi- cated need for interoperability in writing server administration schedule information.

Contributions of this study are proposal of new approaches for reducing burdens that come from large-scale and heterogeneous grid and verification of their effective- ness in realistic grid environment. Results of this study are significant in point of indicating how grid user assistance tools should be.

大規模で不均質なグリッドを 簡便に利用するための枠組み

渡邊 啓正 概要

 広域ネットワーク上の計算資源を組み合わせて一つの複合的な計算機システムを 構築する「グリッド」が，科学技術計算などの高性能計算において注目されている．

グリッドにおいて，簡便性の向上が重要な課題である．グリッドの計算機（サーバ）

は，構成が不均質で，各々が個別の運用方針に従うため，ユーザはそれぞれの構成 や運用方針に適応しながらサーバを利用する必要がある．多数のサーバを用いるグ リッドにおいて，この適応的な利用作業のコストは莫大となる．そのため，この煩 雑さの軽減がグリッドの簡便性の向上において大きな課題である．

本論文では，この煩雑さを軽減するための枠組みを提案する．提案する枠組みで は，グリッドで特に簡便さが重要となる，グリッドアプリケーションの「配置」と

「実行」の作業に焦点を置く．提案する二つの枠組みはそれぞれ次の特徴を持つ．

( 1 ) Relis-G：ライブラリの自動配置の枠組み

• 従来の手作業の配置に比べて少ない入力コストで，多数のサーバに対す るライブラリの一斉配置を可能とする．特に，デバッグなど頻繁なライ ブラリ更新を必要とする場合に，極めて少ないコストで配置可能とする．

• ライブラリの可搬化に関するノウハウの習得などの煩雑さを軽減するべ く，ライブラリを自動的に可搬化させる機能を持ったライブラリ配置シ ステムを提供する．

• サーバ毎の運用方針(二次記憶の利用規則など)への適応における煩雑さ を軽減するべく，運用方針に自動的に適応しながら配置を行うライブラ リ配置システムを提供する．

( 2 ) F-Omega：グリッドアプリケーションのサーバ動的切り替えの枠組み

• 従来手作業で行っていたサーバ稼動状況の監視，サーバ切り替え指示と いった煩雑な作業を不要とするべく，グリッドアプリケーションに対し，

サーバ監視機構と連携しながら利用するサーバを自動的に適切に切り替 え可能とする．

• 従来ユーザとサーバ管理者が手作業で管理していた，事前予約などの複 雑なサーバ利用契約に応じたサーバ利用可能量の変化を自動的に監視可 能とするべく，サーバの運用計画の自動監視機構を提供する．

• アプリケーション開発者を煩雑なサーバ管理の実装から開放するべく，

GridRPCのためのサーバ自動管理モジュールをアプリケーション開発者

に提供する．

提案する枠組みの有効性を検証するべく，それぞれの枠組みをミドルウェアとし て実装し，適用実験を行った．

Relis-Gについては，実グリッド環境での実験の結果，従来の手作業よりも少ない

入力コストでライブラリを自動一斉配置できることを確認した．また，ライブラリ の可搬化機能，運用方針への自動適応機能が有効に機能し，サーバの構成や運用方 針の差異についてユーザが意識することなく，自動的にライブラリを配置できるこ とを確認した．

F-Omegaについては，サンプルアプリケーションを試験的グリッドで動作させた

結果，サーバ群の稼働状況が数時間おきに度々変動する状況において，サーバ監視 機構・切り替え指示機構・並列プログラミングミドルウェアが有効に機能して，利 用するサーバが自動的に適切に切り替えられ2.8日間安定して計算が継続されるこ とを確認した．この効果は，サーバ自動管理機構を持たない従来のGridRPCミド ルウェアで得ることはできない．また，サーバ監視機構と連携しない並列プログラ ミングミドルウェアと比較して，サーバ切り替えの指示のためのコストが大きく軽 減されている．

本研究の今後の課題として，Relis-Gについては，サーバが動的に定まる状況のた めのオンデマンド自動配置機能の必要性を示した．F-Omegaについては，サーバの 運用計画情報の記述における相互運用性の必要性を示した．

本研究の貢献は，グリッドの大規模性・不均質性から生じる，従来で未解決の煩 雑さを軽減するためのアプローチを提案し，その有効性を実証した点にある．この 成果は，グリッドの利用支援ツールのあり方を示すものとして意義がある．

目 次 i

目 次

1 緒言 1

1.1 本研究の背景と目的 . . . . 1

1.2 本論文の構成 . . . . 6

2 グリッドアプリケーションの配置・実行の関連研究 9 2.1 グリッドアプリケーションの配置の関連研究 . . . . 9

2.2 グリッドアプリケーションの実行の関連研究 . . . . 10

3 グリッドにおけるライブラリ自動配置の枠組みの提案 13 3.1 Relis-G: ライブラリ自動配置の枠組み . . . . 13

3.1.1 Relis-Gにおけるライブラリ配置の流れ . . . . 14

3.1.2 Relis-Gの実用的特徴 . . . . 16

3.1.3 VMを用いるアプローチの検討と本研究の意義. . . . 16

3.2 ミドルウェアの設計および実装 . . . . 18

3.2.1 ライブラリ自動配置機能 . . . . 18

3.2.2 ライブラリ可搬化機能 . . . . 22

3.2.3 運用方針自動適応機能 . . . . 24

3.2.4 適用範囲 . . . . 24

3.2.5 Globus Toolkitが利用できない場合への対応 . . . . 25

3.3 評価 . . . . 26

3.3.1 自動配置機能の有効性 . . . . 26

3.3.2 ライブラリ可搬化機能の有効性 . . . . 29

3.3.3 運用方針自動適応機能の有効性 . . . . 30

4 グリッドアプリケーションのサーバ動的切り替えの枠組みの提案 33 4.1 F-Omega: サーバ動的切り替えの枠組み . . . . 33

4.1.1 F-Omegaにおけるサーバ動的切り替えの流れ . . . . 34

4.1.2 F-Omegaの実用的特徴 . . . . 35

4.1.3 耐故障技術との関係 . . . . 37

4.2 ミドルウェアの設計および実装 . . . . 39

4.2.1 サーバ切り替え指示システム . . . . 39

目 次 ii

4.2.2 サーバ切り替え指示に対応可能なGridRPCアプリケーション

の開発方法 . . . . 40

4.3 評価 . . . . 46

4.3.1 サーバ動的切り替えの性能 . . . . 46

4.3.2 サーバ運用計画ファイルの作成に要するコスト . . . . 51

4.3.3 サーバ利用方針ファイルの書式の実用性 . . . . 52

5 今後の課題 53 5.1 ライブラリ自動配置の枠組みにおける今後の課題 . . . . 53

5.2 サーバ動的切り替えの枠組みにおける今後の課題 . . . . 55

6 結言 57

謝辞 62

A 付録1：F-Omega を適用したサンプルGridRPCアプリケーション 69

B 付録2：実験中のサーバ運用計画の導出方法 71

C 付録3：サーバ利用方針ファイルの記述例 72

図 目 次 iii

図 目 次

1 ユーザ，計算機環境とグリッドの関係 . . . . 2

2 関連研究における Relis-G の位置づけ. . . . 10

3 関連研究におけるF-Omegaの位置づけ . . . . 11

4 Relis-G におけるライブラリ自動配置の流れ . . . . 15

5 インストール環境定義ファイルの例 . . . . 20

6 インストールワークフロー定義ファイルの例 . . . . 23

7 ライブラリ可搬化の流れ . . . . 23

8 運用方針への自動適応の流れ . . . . 24

9 従来手法とRelis-Gにおける配置時間 . . . . 29

10 F-Omega におけるサーバ動的切り替えの流れ . . . . 36

11 サーバ運用計画ファイルの例 . . . . 41

12 サーバ利用方針ファイルの例 . . . . 42

13 F-OmegaにおけるGridRPCアプリケーションのソースコード例. . . 43

14 実験中の利用プロセッサ数の推移（利用方針1.） . . . . 49

15 実験中の利用プロセッサ数の推移（利用方針2.） . . . . 50

表 目 次 iv

表 目 次

1 グリッドにおける課題と主な技術キーワード . . . . 3

2 Relis-G ミドルウェアの適用実験環境 . . . . 26

3 適用実験環境における従来手法の配置時間 . . . . 27

4 適用実験環境におけるRelis-Gの配置時間の内訳 . . . . 28

5 F-OmegaモジュールAPI . . . . 42

6 F-Omega ミドルウェアの適用実験環境 . . . . 46

7 サーバ運用計画ファイルの行数の内訳 . . . . 51

1

1 緒言

1.1 _{本研究の背景と目的}

気象，素粒子物理学などの自然現象の解明，医薬や大規模LSIの開発において，高 性能計算機を用いた計算が必須となっている[1, 2, 3, 4]．より高精度のシミュレー ションや，増大する探索空間への対応などのため，より大規模で高速な計算が切望 されている．

このような高性能アプリケーションのための計算環境として，いわゆるスーパー コンピュータ[2, 5]やクラスタ並列計算機といった高性能計算機が多く使われるが [6, 7, 8]，ユーザはそういった計算機の運用コストを削減することを求めている．

これに対し，高性能計算機環境を低コストに調達するアプローチとして，広域ネッ

トワーク(WAN)上の遠隔計算機を用いる広域分散コンピューティングが注目され

ている．広域分散コンピューティングでは「他人」が運用する計算機を用いて計算 を行うため，ユーザに生ずる計算機運用コストを増やさずに，より大規模な計算機 環境を利用できる．また，近年インターネットに代表されるWANでは光ファイバ などを用いた高速な通信手段が普及したことで[9]，広域分散コンピューティングの ための下地が整ってきたといえる．

多くの広域分散コンピューティングの実験で，高い計算性能が得られたと報告さ れている[4, 10, 11, 12]．たとえば，その先駆者と言えるSETI@homeでは，2001年 7月から1年間に平均27.36TFlopsもの処理能力が実現された[13]．今後，世界的に 計算機の高性能化と普及が進むにつれて，広域分散コンピューティングで得られる 計算性能はさらに増大していくと見込まれる．

このように広域分散コンピューティングは高い計算性能を(潜在的に)備えている が，ユーザにとって煩雑な計算機環境であるという問題がある．これは次の理由によ る．一般に，WAN上の遠隔計算機は各管理者の独自方針に基づいて構成・運用され ているため，ユーザは各計算機の構成（OS種別など）や運用方針（二次記憶の利用規 則や稼動計画など）に適応しながら利用しなければならない（実例：TeraGrid[14]）．

計算機の台数が多い広域分散コンピューティング環境では，計算機毎にこういった 詳細について適応しながら利用する際のコストが莫大となる．

このような煩雑さを軽減するべく，WAN上の計算機群を組み合わせて一つの複 合的な計算機システムとしてユーザに提供する「グリッド」(図1)が盛んに研究され

1.1 本研究の背景と目的 2

図 1: ユーザ，計算機環境とグリッドの関係

ている．ユーザが計算資源の監視・計算の割当てといった煩雑な手続きを行わずに，

容易に安定的にWAN上の計算機群を利用できることが，グリッドの理想といえる．

このためには，以下のような要素技術を開発する必要がある．

• 不均質性対応・相互運用性[15, 16, 17, 18, 19]

標準化・統一化された計算機利用インタフェースにより，計算機毎の適応に要 するユーザのコストを軽減する．

• 動的資源管理[20, 21, 22, 23]

計算機の稼動状況に応じて適切な計算機を動的に組み合わせながら，アプリ ケーションを安定して実行可能とする．

• 高性能化[24, 25, 26, 21]

十数サイト，1,000CPUにおよぶ大規模計算機群を用いて，全体的に高い計算 性能を達成可能とする．

• 安全性[17]

計算機を不正な利用から守るためのセキュリティを実現する．

• 仮想組織[27]

WAN上で複数分野にまたがった人々による連携作業を円滑に行えるようにす るべく，仮想的な組織を単位として計算環境を利用可能とする．

1.1 本研究の背景と目的 3

表 1: グリッドにおける課題と主な技術キーワード

課題 キーワード

・不均質性対応 ・VM

・相互運用性 ・標準化

・Webサービスベース（WSRF[18]等）

・動的資源管理 ・資源発見，監視

・資源管理オーバーレイ

・耐故障性

・高性能化 ・粗粒度並列分散処理

・ジョブスケジューリング

・耐遅延性

・ネットワーク階層への適応

・安全性 ・PKI認証

・シングルサインオン

・仮想組織 ・VOアクセス制限

・履歴管理

前述の要素技術のうち，本論文では，不均質性対応と動的資源管理に関する問題 を提起する．以下では，本研究で対象とするグリッド利用シナリオを(1)グリッドア プリケーションの開発，(2)利用計算機の選択，(3)グリッドアプリケーションの配 置，(4)グリッドアプリケーションの実行に分け，そこでの前提や問題点を述べる．

( 1 ) グリッドアプリケーションの開発

ユーザがグリッドで実行する分散並列アプリケーション(グリッドアプリケー ション)の開発には，WAN上の計算機に対して統一的でセキュアなアクセスを 可能とする仕組みと，その上で動作可能な分散並列プログラミングモデル(お よびミドルウェア)が必要である．それぞれ，本研究では以下を想定している．

 統一的・セキュアな計算機アクセスのために，本研究では各計算機上に資 源管理ミドルウェアGlobus Toolkit[17]が稼動していることを想定する．今日 のグリッド研究分野において，Globus Toolkit を計算機に配備しておくこと が，事実上標準の計算機構成として認識されており，この想定は妥当といえ る．Globus Toolkitは，計算機への相互運用性のあるアクセス機構（ジョブ投 入や監視等）と，PKI（公開鍵基盤）を基にしたユーザ認証機構を含む．

1.1 本研究の背景と目的 4

 分散並列プログラミングモデルとして，本研究ではGridRPC[19]を想定す る(ミドルウェアにはGlobus Toolkit上で動作する参照実装であるNinf-G[28]

を用いる)．GridRPCでは，クライアントホストからサーバホスト群に向けた 非同期RPCの複数並列実行により，分散並列処理が行われる．これは複雑な プロセス間同期が少ない粗粒度のタスク並列処理であり，通信遅延の大きい WANでの広域分散計算に適している．また，GridRPCでは，サーバ計算機毎 にサーバプログラムの起動/終了を制御しやすいため，耐故障処理を実装する のに向いている．今日のグリッド計算において，GridRPCは現実的なグリッ ド向けプログラミングモデルの一つとしてしばしば用いられている[26][24]．

( 2 ) 利用計算機の選択

利用計算機の選択はグリッド全体の性能を大きく左右するため，盛んに研究が なされているが，本論文では深く議論しない．これは，後述するグリッドアプ リケーションの「配置」と「実行」における煩雑さを軽減し，グリッドを実用 的計算環境として使えるようにすることが先決の課題と考えるからである．

以下の議論では，構成と運用方針が不均質な計算機群が選択されることを想定 する（これはグリッドで一般的である）．

( 3 ) グリッドアプリケーションの配置

アプリケーションの計算依頼に先立って，利用されるライブラリをサーバ計算 機上に配置する必要がある．ここで配置とは，サーバ上でライブラリのソース ファイルをコンパイル・リンクし，サーバ上のグリッド用サービスとして登録 する作業である．本研究では，ライブラリ開発者がC，Fortranなどの慣れ親 しんだ言語でライブラリを作成することを踏まえて，JavaVM等を用いない，

ネイティブライブラリの配置を想定する．

ライブラリの配置において，次の煩雑さが問題である．

ライブラリの可搬化コスト これまで均質の計算機環境を対象として開発を行っ てきたユーザ（ライブラリ開発者）にとって，ライブラリに可搬性を持た せるソフトウェアパッケージを作成するためのノウハウの習得，時間と いったコストが大きい．このパッケージは次の理由で必要となる．一般 に，ユーザが作成したライブラリのソースコードは機種依存性を持つた

1.1 本研究の背景と目的 5

め，グリッドの不均質計算機上でコンパイルに失敗することが多い．コ ンパイル可能とするには，通例，ソースコードの機種依存性を解消させ るソフトウェアパッケージを新たに作成する必要がある．

遠隔操作コマンドの入力コスト 従来¹では，ライブラリ配置作業はsshや scp 等の遠隔操作ツールを用いてユーザの手作業で行われてきた．しかし，多 数のサーバを使用する状況や，デバッグ等の理由でライブラリを頻繁に 更新する状況において，遠隔操作コマンドの入力コストが莫大になる．

サーバ運用方針への適応コスト 多数のサーバへライブラリを配置する際，サー バ毎に異なる運用方針に沿って行うためのコストが莫大となる．ここで，

運用方針は具体的には，二次記憶の利用規則（ライブラリの配置先フォ ルダなど）や環境変数の値を指す．

( 4 ) グリッドアプリケーションの実行

グリッドアプリケーションの実行には，利用するサーバの適切な動的切り替え が不可欠である．これは次の理由による．グリッドを実用的な計算環境とする には，グリッドアプリケーションが計算をやり直すことなく数日から数週間計 算し続ける必要がある．その一方，サーバの性能は，システムメンテナンスや 他ユーザによる高優先度ジョブの割り込みといった運用上の理由で変動する²． グリッドアプリケーションにおけるサーバ動的切り替えには，次の問題がある．

サーバ切り替えの指示コスト 従来，アプリケーションに対するサーバ切り替 えの指示をユーザが手作業で行っていたが，そのコストが莫大である．

サーバ群全体の稼働状況が運用上の理由によりしばしば不定期に変動し，

その度に，ユーザが利用可能なサーバを判別してサーバ切り替えの指示 を出さなければならないためである．

サーバ運用計画の監視コスト 従来，電子メール・ウェブページを用いて，ユー ザがサーバの運用計画を監視していたが，そのコストが莫大である．こ れは次の理由による．他ユーザによる予約ジョブの追加などによりサー バの運用計画が不定期に変化するため，ユーザ側はこれを定期的に監視

1提案する枠組みRelis-Gの発表時点（2003年10月）．

2ハードウェア故障等による突発的なサーバ障害に対する本研究での対応については4.1.3節を参 照．

1.2 本論文の構成 6

する必要がある．また，サーバ毎に運用計画情報を公開する方法が異な り，書式が統一されていないため，手作業の監視が煩雑である．さらに，

サーバの台数が多いグリッドでは，監視に要するコストが莫大となる．

切り替え指示に対応可能なアプリケーションの開発コスト  Ninf-Gといった

GridRPCミドルウェアでは，サーバを管理し，切り替え指示に応じてサー

バを動的に変更する処理の実装が煩雑である．なぜなら，サーバプログ ラムの起動/終了，RPCの発行/キャンセルといったプリミティブな機能・

APIしか提供されず，アプリケーション開発者がサーバ管理処理を実装 しなければならないためである．

本研究の目的は，グリッドの計算機の大規模・不均質性に起因するこれらの煩雑 さに対する解決方法を提案し，その有効性を明らかにすることである．

1.2 本論文の構成

本論文は6つの章から構成される．

第1章は本章であり，本研究の背景および目的を述べた．

第2章では，グリッドアプリケーションの「配置」と「実行」に関して，従来の グリッドや関連研究で用いられた方式を整理し，新たな配置・実行方式としての提 案枠組みの位置づけを明確にする．

第3章では，新しいグリッドアプリケーション配置の枠組みとして，サーバの不 均質性に自動的に対処可能とするライブラリの自動配置の枠組み Relis-G を提案 する．枠組みの検討方針として，3つの着眼点を示す．(a)グリッド上で可搬性のあ るライブラリ自動配置システムの設計方法．(b)不均質なコンパイル環境でのライ ブラリのコンパイルを支援する，ライブラリ可搬化方法．(c)不均質なサーバ運用方 針に適応した配置作業を支援する，運用方針への自動適応方法．続いて，提案方式 を用いたライブラリ配置の流れを示し，着眼点における提案方式の有用性を述べる．

次に，枠組みのミドルウェア実装について設計・実装を述べる．実グリッド環境で ミドルウェア実装の適用実験を行い，提案方式の有効性を述べる．

第4章では，グリッドアプリケーションを対象とした新しいサーバ動的切り替え の枠組みとして，サーバ監視機構と連携する「自動ステアリングシステム」をユー ザに提供する，F-Omega を提案する．グリッドアプリケーションにおけるサーバ

1.2 本論文の構成 7

動的切り替えの枠組みの検討方針として，3つの着眼点を示す．(a)サーバ運用計画 情報の自動的な監視方法．(b)サーバ切り替えの自動的な指示方法．(c)サーバ切り 替え指示に対応可能なグリッドアプリケーションの開発方法．続いて，提案方式を 用いたサーバ動的切り替えの流れを示し，着眼点における提案方式の有用性を述べ る．また，耐故障技術と提案枠組みの関係を明確にする．次に，枠組みのミドルウェ ア実装について，設計・実装を述べる．試験的グリッドでF-Omegaのミドルウェア 実装の適用実験を行い，提案方式の有効性を述べる．

第5章では，グリッドアプリケーションの「配置」と「実行」の枠組みそれぞれ について，今後取り組むべき課題を整理する．

第6章では，本研究の結言として，研究成果についてまとめ，本研究の意義を述 べる．

1.2 本論文の構成 8

9

2 グリッドアプリケーションの配置・実行の関連研究

本章では，本論文で提案する二つの枠組み「グリッドにおけるライブラリ自動配 置の枠組み」「グリッドアプリケーションのサーバ動的切り替えの枠組み」について，

既存研究との関連を示し，枠組みの位置づけを明確にする．

2.1 グリッドアプリケーションの配置の関連研究

ソフトウェア配置の従来研究と比べた本研究の新規性は，計算機の構成・運用方針 の不均質性に自動的に対処可能とする機能を有する点にある．一方，従来研究は，イ ントラネット内の計算機を対象とした自動配置システムと，インターネット上の計算 機を対象とした自動配置システムに大別できる．両者の違いは，Globus Toolkit を はじめとするグリッド標準のセキュリティ技術に基づく計算機の保護の有無である．

以下では，ソフトウェア配置に関する従来研究と本研究を比較する（図2）．

オフィスPC群等のイントラネット内の計算機群を対象としたソフトウェア自動 配置システム[29, 30, 31, 32, 33, 34, 35, 36, 37]は，以下のようにグリッドでの利用 に向いていない³．(1)グリッドで必要なSSL等の技術に基づくセキュリティメカニ ズムがサーバ上に配備されていない．(2)不均質計算機上で動作するように実装され てはいない．(3)コンパイル済みのソフトウェアの配布を想定しているため，不均質 計算機上でのソフトウェアのコンパイルに対応できない．

PCT4G[38]とGXP[39]は，提案枠組みRelis-Gと同時期に発表された，インター ネット上の計算機を対象としたソフトウェア配置を支援するツールであるが，計算機 の不均質性への対処を支援する機能が含まれていない．具体的には，不均質環境向 けのパッケージの自動作成，資源の運用方針への自動的な適応といった機能がない．

計算依頼時にサーバヘプログラムコードを自動的に転送（ステージング）可能な グリッドミドルウェアがある[16, 40]．これらの特長として，ユーザが明示的なプロ グラム配置作業を一切行う必要がなく，サーバ群へのプログラムの配備が自動的に 行われることがあげられる．しかし，Java言語で書かれたプログラムの実行しか行 えないといった問題をかかえている．

他のグリッドミドルウェア[41, 20, 42, 43]にもプログラムのステージング機能を 提供するものがあるが，いずれにおいてもグリッドの不均質環境におけるライブラ

3これらの理由のため，従来sshなどの遠隔操作ツールを用いて手作業で配置が行われていたと考 えられる．

2.2 グリッドアプリケーションの実行の関連研究 10

図 2: 関連研究における Relis-G の位置づけ リのコンパイルに関する問題が解決されていない．

ライブラリの可搬化に関する既存技術として，metaconfig[44]はプログラムのソー スコードからconfigure スクリプトを自動作成する機能を持つが，Relis-G はプロ グラマのコストをこれよりもさらに軽減している．双方のコストは具体的には以下 のとおりである．metaconfigでは，ソースコード中の機能検査用プリプロセッサ文

（BSDソケットインタフェースの有無を検査する#ifdef HAS_SOCKETなど）を基に

configure スクリプトを作成する．そのため，利用する全てのAPI関数に対応する

metaconfig特有のプリプロセッサ記述をプログラマが調べて，ソースコードに逐一挿

入しなければならない．Relis-Gでは，ソースコード中でインクルードされているシ ステムライブラリヘッダを基に，configureスクリプトを自動的に作成し，metaconfig と同等のプリプロセッサ記述をソースコードに自動的に挿入する．

InstallShield 等のソフトウェアパッケージ作成システム[45, 46, 47, 48, 49]には，

Relis-G のライブラリ可搬化機能のように，グリッドの不均質な計算機上でコンパ

イル可能なパッケージを自動作成するものはない．

2.2 グリッドアプリケーションの実行の関連研究

サーバ動的切り替えに関する従来研究と比較した，本研究の新規性は，監視機構 と連携したサーバ自動切り替え機能を有する点にある．また，監視機構として，グ

2.2 グリッドアプリケーションの実行の関連研究 11

図 3: 関連研究におけるF-Omegaの位置づけ

リッドサーバの運用計画を自動的に監視可能としている点が新規である．加えて，従

来のGridRPCミドルウェアとの新規性として，サーバを自動管理し，外部からの

サーバ切り替え要求に応じてサーバを変更可能なアプリケーションモジュールを提 案している．

以下では，グリッドアプリケーションのサーバ動的切り替えに関連する従来研究 と本研究を比較する（図3）．

資源監視ミドルウェア[50, 51, 52]は，計算機の稼動状況を可視化するが，これら をサーバ動的切り替えに適用する際のユーザのコストが大きい．その場合，ユーザ が継続的に全サーバの可視化結果を監視し，適切なサーバを選び，随時切り替えを 指示しなければならない．サーバの台数が多いグリッドにおいて，このコストは莫 大となる．

Condor[20]といったジョブバッチシステムはサーバ監視と連携してジョブ割り当

てを行うが，本研究で対象としているようなサーバ運用計画を扱えず，サーバ動的 切り替えには不十分である．例として，事前予約に基づくサーバの利用を考える．

F-Omegaでは，予約契約に基づくサーバ利用可能量（たとえばプロセッサ数）の変

2.2 グリッドアプリケーションの実行の関連研究 12

化をサーバ管理者がサーバ運用計画ファイルとして記述し，それを監視するサーバ 切り替え指示システムにより，自動的にサーバ切り替えを行うことができる．一方

Condorでは，このようなサーバ利用可能量の変化をサーバ監視機構が扱うことがで

きない．したがって，ユーザとサーバ管理者が手作業で監視しなければならず，監 視結果と連携したサーバ切り替えのコストが大きい．また，Condorをグリッドアプ リケーションのジョブ投入機構として用いるには，別途並列プログラミングミドル ウェアが必要となる⁴．

サーバを動的に変更可能な並列プログラミングミドルウェア[22, 23]には，F-Omega のような，サーバの運用計画に連携して自動的にサーバを切り替える機能がない．

この場合，サーバ運用計画の監視・サーバ切り替えの指示のためのユーザのコスト が莫大となる．

武宮らの大規模長時間実行GridRPCアプリケーション[24] では，ユーザ定義の サーバ利用方針に基づいたサーバ動的切り替えを行えるが，サーバ切り替え機構の 再利用が困難である．GridRPCアプリケーションのための共通モジュールからなる

F-Omega のアプローチと異なり，この機構はアプリケーション自身に静的にアプリ

ケーション独自の方法で実装されている（サーバ利用方針を記述したファイルを読 み込み，サーバ利用をそれに適応させるアプリケーション処理工程からなる）．し たがって，任意のアプリケーションにこのアプローチを適用することが難しい．

Globus ToolkitのDUROC (Dynamically-Updated Request Online Coallocator)[53]

はサーバの性能パラメータを考慮してジョブに対して初期サーバ群を自動的に割り 当てるが，F-Omegaで提供するような，アプリケーション実行中のサーバ動的切り 替えの機能を持たない．

4たとえば，Ninf-Gはジョブ投入機構としてCondorに対応している．

13

3 グリッドにおけるライブラリ自動配置の枠組みの提案

本章では，グリッドにおけるライブラリの自動配置の枠組みRelis-G を提案する．

まず，ライブラリ自動配置の枠組みを検討する際の着眼点を述べる．次に，Relis-G の概要を述べ，着眼点に関してRelis-Gの有用性が高いことを示す．続いて，Relis-G のミドルウェアとしての実装に関して，設計と実装を述べる．最後に，グリッドで のライブラリの自動配置におけるRelis-G のミドルウェア実装の性能を評価する．

3.1 Relis-G: ライブラリ自動配置の枠組み

グリッドを対象としたライブラリ配置の枠組みの提案において，検討されるべき 点を，その理由とともに以下に述べる．

1. 配置システムの設計

自動一斉配置 多数のサーバに対して一斉に自動的にライブラリを配置できる 機能が必要である．これは次の理由による．従来，ライブラリ配置作業 は sshや scp 等の遠隔操作ツールを用いてユーザの手作業で行われてき たが，多数のサーバを用いるグリッドでは，ユーザの入力コストが莫大 となる．また，ライブラリのデバッグ等のために配置を頻繁に行う状況 では，さらにコストが倍増する．

可搬性の高い実装 構成が不均質な計算機で配置システムを実行できる必要が ある．なぜなら，配置システムは，ユーザの作業用クライアント機や，グ リッドポータル[54]のポータルサーバ機など，グリッド上の任意の計算 機で実行されることが想定されるためである．

2. ライブラリの可搬化方法

自動可搬化 機種依存性のあるライブラリに対して自動的に可搬性を持たせる 必要がある．従来のローカル計算機環境のみを対象として開発を行って きたライブラリ開発者にとって，ライブラリに可搬性を持たせる作業は コストが大きいためである．可搬性を持たせる作業とは，具体的には，ラ イブラリのソースコードを計算機環境に適応させるためのconfigure スク リプトを作成する作業である．

3.1 Relis-G: ライブラリ自動配置の枠組み 14

3. 運用方針への適応方法

自動適応 配置作業を行う際，サーバ毎の運用方針に自動的に適応する必要が ある．従来の手作業による適応では，サーバの台数が多いグリッドにお いて，全サーバの運用方針を調査しそれに応じて各配置作業を変更しな ければならず，ユーザのコストが莫大となる．

以上を踏まえ，ライブラリの自動配置の枠組みRelis-Gを提案する．Relis-G は，

ユーザに対し，ソースコード環境適応化に基づくライブラリ可搬化機能およびサー バ運用方針に自動適応する配置機能を備えた，ライブラリ自動配置システムを提供 する．これにより，ユーザはライブラリ配置における前述の煩雑な作業から開放さ れ，より簡便にグリッドを利用できる．

ライブラリ自動配置システムは，システムの可搬性と標準的・セキュアなサーバ アクセスを考慮し，Globus Toolkitと(Bourne)シェルスクリプトを用いて実装した．

3.1.1 Relis-Gにおけるライブラリ配置の流れ

Relis-Gのライブラリ自動配置システムを用いたライブラリ配置の流れを示す（図

4）．以下の列挙番号には，時系列順に作業項目を並べた場合の順序を記す．

サーバ群に対し自動的に一斉にライブラリの配置を行うべく，まず，ユーザは次 の手順でライブラリ自動配置システムを起動する．

( 1 ) ライブラリのソースファイル群を用意する．

( 2 ) ライブラリソースファイルのパス，およびサーバ群へのアクセス方法を含む，

インストール環境定義ファイルを作成する．

( 3 ) サーバ上で実行される配置用コマンド列を含む，インストールワークフロー定

義ファイルを作成する．

( 5 ) Relis-G ライブラリ自動配置シェルスクリプトを起動する．

続いて，次の手順で，ライブラリ自動配置シェルスクリプトがサーバへライブラ リの配置を行う．

( 6 ) インストール環境定義ファイルとインストールワークフロー定義ファイルを読

み込む．

3.1 Relis-G: ライブラリ自動配置の枠組み 15

図 4: Relis-G におけるライブラリ自動配置の流れ

( 9 ) ライブラリのソースファイル群を各サーバへ転送する．

( 10 ) 各サーバに対して，ライブラリをコンパイル・リンクし，GridRPC用サービ

スとして登録するように，遠隔コマンド実行を行う．

ライブラリの可搬化は次の手順で行われる．

( 7 ) ライブラリ可搬化機能により，ライブラリのソースコードに対し，環境適応化

モジュールを自動作成する（付加する）．

サーバの運用方針への自動適応は次の手順で行われる．

( 4 ) 各サーバ管理者が運用方針情報を各MDSに登録する．

( 8 ) ライブラリ自動配置シェルスクリプトが，各サーバの運用方針情報をMDSか

ら取得し，配置用コマンド列中の変数の値に設定する．MDSのアクセス方法 はインストール環境定義ファイルから取得する．

3.1 Relis-G: ライブラリ自動配置の枠組み 16

3.1.2 Relis-Gの実用的特徴

先述した，ライブラリの配置の枠組みに関する検討点について，対応するRelis-G の機能や特徴を述べる．

1. 配置システムの設計

自動一斉配置 ライブラリ自動配置シェルスクリプトを用いて，ユーザはサー バ群に対して自動的に一斉にライブラリを配置できる．インストール環境 定義ファイル・インストールワークフロー定義ファイルの再利用により，

デバッグ等における頻繁な配置において，少ないコストで実行できる．

可搬性の高い実装 グリッドの多くの計算機上で利用可能なGlobus Toolkitと シェルスクリプトに基づく実装により，可搬性の高いライブラリ自動配 置システムとなっている．

2. ライブラリの可搬化方法

自動可搬化 ライブラリのソースコードから可搬化のための configure スクリ プトを自動的に生成するツールをユーザに提供する．ユーザにとって，可 搬化のためのノウハウの習得や時間といったコストが大きく軽減される という点で有用である．

3. 運用方針への適応方法

自動適応 ライブラリ自動配置シェルスクリプトが各サーバの運用方針データ

ベース(MDS)に対して問い合わせを行い，その結果を反映した配置作業

を自動的に行う．これにより，ユーザはサーバ毎の運用方針の差異を意 識せずに，運用方針を自動的に守ってライブラリを配置できる．

以上より，グリッドにおけるライブラリ自動配置の枠組みに求められる特徴を

Relis-G が備えており，有用性が高いことを示した．

3.1.3 VMを用いるアプローチの検討と本研究の意義

計算機の構成・運用方針の不均質性を隠蔽するアプローチとして，OSのVM（仮 想マシン）を用いる方法が考えられる．この方法では，数ギガバイトのOSイメージ

3.1 Relis-G: ライブラリ自動配置の枠組み 17

ファイルの転送のために高速なネットワーク通信環境が必要である．一般ユーザが そのようなネットワークを利用可能となるには今後数年を要すると考えられる．本 論文は，そのような高速なネットワーク通信環境を持たない一般ユーザが利用可能 な不均質性対処の方法を提案している点で，意義がある．

3.2 ミドルウェアの設計および実装 18

3.2 ミドルウェアの設計および実装

Relis-Gのライブラリ自動配置システムの設計・実装について述べる．

本システムは次の機能で構成されている（図4を参照）．

ライブラリ自動配置機能 遠隔サーバ群へのライブラリの配置を自動的に行う．

ライブラリ可搬化機能 不均質なサーバ環境でコンパイル可能なライブラリのパッ ケージを作成する．

運用方針自動適応機能 サーバの運用方針に配置手順を適合させる．

以下，各機能について述べる．

3.2.1 ライブラリ自動配置機能

本機能はライブラリの自動一斉配置の基本的な機能性を提供する．

本機能は次の特徴を有していなければならない．

• 遠隔サーバアクセスのために，シングルサインオン機能を備えたユーザ認証機 構を用いること．

• グリッドの不均質な計算機環境で動作可能であること．

これらのため，本機能は以下の方法で実現されている．

1. 遠隔サーバアクセス方法

Globus Toolkit[17] を用いる．このツールは以下の特徴を持つ．

• 多くのグリッド研究機関において事実上標準で利用されている．

• 公開鍵暗号やX.509証明書に基づく，シングルサインオン機能を有する セキュリティインフラ（Grid Security Infrastructure: GSI）を含む．

• 遠隔にプロセスを起動する機能GRAM（Globus Resource Allocation Man-

ager）と，ファイルを転送する機能GridFTP を有する．

2. 配置プログラムの実装方法

Bourne シェルスクリプトで実装する．これは次の理由に基づく．

3.2 ミドルウェアの設計および実装 19

• グリッドの不均質な計算機において可搬性が高い．

• 複数のサーバへの並行インストールをプロセスのforkを用いて容易に実 装できる．

• 遠隔アクセスツールのコマンド群を組み合わせることで本機能を実装で きる．

本機能はライブラリのインストールを行う環境に関する情報を受け取るために，

ユーザ定義のテキストファイルを用いる．この方式は，多くの場合にシェルが端末 として使用される，グリッドアプリケーションの開発プロセスに適している．

そのファイルとは，インストール環境定義ファイル，およびインストールワーク フロー定義ファイルである．ユーザはいったんこれらのファイルを作成すれば，同じ サーバ環境に対して同じライブラリ配置作業を容易に何度も実行できる．したがっ て，本システムは，ライブラリのデバッグ等，複数回のライブラリ配置作業を必要 とする状況において大変有用である．

このファイルの分離は次の理由に基づく．(1)インストールワークフロー（サーバ 上で実行される配置用コマンド列）はサーバ環境によって変化しないため．(2)イン ストールワークフローが，同じグリッドミドルウェアが使われている限り再利用で きるため．

これらのファイルの詳細について，以下に述べる．

インストール環境定義ファイル

このファイルにはライブラリの配置が行われるサーバ環境についての情報を（ユー ザが）記述する．

本ファイルはXMLで記述されている．これは多数の設定項目をユーザが記述す るために，XMLの木構造と高い可読性が有用であるためである．

このファイルは大別すると，以下の３つの設定項目で構成されている（図5を参照）．

• ライブラリのインストール手順に関する設定（約11行）

3行目以降の<client>タグ内にあたる．ライブラリのソースファイル群の存 在するフォルダのパス，使用するインストールワークフロー定義ファイル等を 指定する．サーバ環境にかかわらず，ユーザは必ずこの設定を指定する必要が ある．

3.2 ミドルウェアの設計および実装 20

<?xml version=’1.0’?>

<install-env>

<client>

<host name="‘hostname‘"/>

<user name="watanabe"/>

<library name="mmul" version="1.0">

<source dir="./mmul/server"/>

<configure create="yes" update="no" staticlink="yes"/>

<compile always="no"/>

<workflow file="./wffile.xml"/>

<mfheader package="globus_common"/>

</library>

</client>

<modreps>

<modrep-group>

<host name="gex1.yuba.is.uec.ac.jp"/>

<rsh type="globus-gram"/>

<rsh type="ssh"/>

<dbhost type="globus-mds"/>

<dbhost type="https" file="/adminpolicy.tar.gz"/>

</modrep-group>

</modreps>

<servers>

<server-group>

<host name="(gex1|grid0[0-3]).yuba.is.uec.ac.jp"/>

<rsh type="globus-gram"/>

<dbhost name="gex1.yuba.is.uec.ac.jp" type="globus-mds"/>

<mrhost name="gex1.yuba.is.uec.ac.jp"/>

</server-group>

<server-group>

<host name="asuka.yuba.is.uec.ac.jp"/>

<rsh type="globus-gram"/>

<dbhost type="globus-mds"/>

<mrhost name="gex1.yuba.is.uec.ac.jp"/>

</server-group>

<server-group>

<host name="latitude6.yuba.is.uec.ac.jp"/>

<rsh type="ssh"/>

<dbhost type="https" file="/adminpolicy.tar.gz"/>

<mrhost name="gex1.yuba.is.uec.ac.jp"/>

</server-group>

<server-group>

<host name="(koume|koume0[0-3]).hpcc.jp"/>

<rsh type="ssh"/>

<dbhost name="gex1.yuba.is.uec.ac.jp" type="globus-mds"/>

<mrhost name="gex1.yuba.is.uec.ac.jp"/>

</server-group>

<use only="" never=""/>

</servers>

</install-env>

図 5: インストール環境定義ファイルの例

• （15〜24行目の記述はコンパイルを行うサーバの限定[15] に関する．本論文 では割愛する．）

• サーバ群に関する設定（1ホストにつき約6行）

3.2 ミドルウェアの設計および実装 21

25行目以降の<servers>タグ内にあたる．各サーバ上のGRAM や GridFTP のサービスに遠隔にアクセスするための情報を指定する．ユーザは基本的に サーバごとにこの設定を記述する必要がある．

インストール環境定義ファイルでは，サーバ群のホスト名の記述にnode[0-7].abc.com といった正規表現を用いることができる．これにより，クラスタ環境でディスク領 域がNFSで共有されていない場合に，ユーザがノードごとのライブラリ配置を容易 に指示できる．

このファイルを処理するために，インストール環境定義ファイルの内容をシェルス クリプト形式で書き出すプログラムを，軽量XMLパーサライブラリCrimson[55]を 用いてJava言語で開発した．このプログラムは前述の正規表現の展開も行う．Java による実装はプラットフォーム独立性という点でグリッドの不均質計算機環境に適 している．また，クライアントホスト上でのJava VMの要求は大きな障害にならな い⁵．

インストールワークフロー定義ファイル

このファイルは，グリッドミドルウェア間で統一化されたインストールワークフ ロー（配置用コマンド列）をXMLで記述したものである．

これにより，本機構はグリッドにおける汎用的な自動ソフトウェア配布システム として使用可能となる．本機構が任意のインストールワークフローを実行可能とす るには，コマンド列がグリッドミドルウェア間で統一化された書式で記述される必 要がある．このファイルの書式は次の要件を満たすように設計した．

• シェルに依存しない

ワークフローが様々なワークフロー処理系に容易に流用されるようにするた め，抽象的なプロセス表現を用いる必要がある．また，ユーザはシェルスクリ プトについての知識を強要されるべきではない．

• 配置作業の記述に洗練された仕様を用いる ユーザに配置作業を記述しやすくするため．

インストールワークフロー定義ファイルの内容は以下のとおりである（図6を 参照）．

5クライアントホスト1台のみにJavaVMの導入が必要であり，サーバホスト上には不要である．

3.2 ミドルウェアの設計および実装 22

• 各コマンドの記述（1コマンドあたり約3行）

6行目以降の<exec>タグにあたる．Apache Ant[56]のビルドファイルで使用 可能なタスク（Exec，Copy等）を模した書式になっている．Antのビルドファ イルのタスクの書式はシェルに依存しないコマンドの表現として有用である．

• 複数のコマンド間の制御フローの記述（1フローあたり約2行）

前述のコマンド群を囲む5行目の<sequence>タグにあたる．ビジネスプロセ ス実装言語であるBPEL4WS[57] の構造化アクティビティ（Sequence，While 等）を模した書式になっている．BPEL4WSはビジネスプロセスが自然に記述 されるようにするため，とても洗練されている．

このファイルを処理するために，インストールワークフロー定義ファイルを読み 込んで相当するコマンド列をシェルスクリプト形式で書き出すプログラムを，イン ストール環境定義ファイルと同様にCrimsonを用いてJava言語で開発した．

インストールワークフローを実行する際，特定の環境変数にサーバ固有の値が定 義されていなければならない場合がある（グリッドミドルウェアの動作に必要な環 境変数等）．この値を事前に取得する手段として，本機構では3.2.3節の運用方針自 動適応機能が利用できる．その際，ユーザが環境変数名をこのファイルの中で指定 する（3行目の<require-env>タグ）．

3.2.2 ライブラリ可搬化機能

本機能は，グリッドの不均質な計算機上でのライブラリのコンパイルのために，ビ ルド用ファイル群（configureスクリプト，Makefile等）を自動作成する．

不均質なサーバ環境では，各サーバで個別のライブラリコンパイル手順が必要に なる場合がある（特定のシステムで特定のコンパイルオプションが必要になる等）．

その場合，各サーバに合ったコンパイル手順を実行するために，ビルド用ファイル

群（特にconfigureスクリプト）が必要になる．

本機能では，特定の入力ファイルからconfigureスクリプトを自動生成する，GNU autoconf[58]を用いてconfigureスクリプトが作成される．autoconfの入力ファイル は，従来ライブラリ開発者が手作業で作成していたが，Relis-G では本機能によって ライブラリのソースファイルから自動作成される．その際，実行されるべきソース コードの環境適応処理は，ソースファイルでインクルードされているシステムライ

3.2 ミドルウェアの設計および実装 23

<?xml version=’1.0’?>

<process name="Ninf-G_Install">

<require-env name="NS_DIR"/>

<taskgroup type="oncompileserver">

<sequence name="main1">

<exec executable="./configure"/>

<exec executable="make"/>

<exec executable="${NS_DIR}/bin/ns_gen">

<arg line="*.idl"/>

</exec>

<exec executable="make">

<arg line="-f ${LIBRARY_NAME}.mak"/>

</exec>

</sequence>

</taskgroup>

<distfile file="${LIBRARY_NAME}.o"/>

<taskgroup type="oncomputationserver">

<sequence name="main2">

<exec executable="make">

<arg line="-f ${LIBRARY_NAME}.mak install"/>

</exec>

</sequence>

</taskgroup>

</process>

図 6: インストールワークフロー定義ファイルの例

図 7: ライブラリ可搬化の流れ

ブラリヘッダ名をもとに特定される（図7を参照）．これは多くの機種依存性が外 部ライブラリの使用に起因すると判断したためである．

3.2 ミドルウェアの設計および実装 24

図 8: 運用方針への自動適応の流れ 3.2.3 運用方針自動適応機能

本機能は各計算資源の運用方針を自動的に取得し，それに従ってライブラリのイ ンストールを行う．

計算資源の運用方針情報はGlobus Toolkit に含まれるMDSという情報提供サー ビス（GSIを通してアクセスされるLDAPデータベース）を利用したデータベース で管理される．そして，本機能は次の手順で実装されている（図8を参照）．

• あらかじめ，計算資源の管理者がライブラリのインストールに対する運用方針 情報を，資源上のMDSに登録しておく．登録作業には煩雑なコマンド入力作 業が必要となる．そのため，その管理者は，本機能が提供する，その作業を自 動的に行えるシェルスクリプトを利用できる．

• 本機構のシェルスクリプトは，インストール実行直前に，MDS検索コマンド

（grid-info-search）を用いてユーザの権限でMDSから運用方針情報を読み出 す．そして，それに従ってライブラリのインストールを行う．

計算サーバの運用方針情報は次のとおりであるが，今後必要に応じて拡張可能で ある．

• ライブラリを配置するフォルダ

• ライブラリの配置に必要な環境変数の値

3.2.4 適用範囲

本機構は，GridRPCのサーバプログラムに限らず，MPIのアプリケーション等の インストールにも適用可能である．

3.2 ミドルウェアの設計および実装 25

サーバ間でインストールワークフローが異なる場合，インストール環境定義ファ イルとインストールワークフロー定義ファイルは別途新たに作成される必要がある．

これは，本機構でのインストールにおいて，１つのサーバ群に対して１つしかイン ストールワークフローが適用できないためである．

3.2.5 Globus Toolkitが利用できない場合への対応

本機構では遠隔アクセスツールとしてGlobus Toolkit の代わりにsshを利用でき る．シングルサインオン機能は ssh-agentを用いて実現される．

運用方針自動遵守機能において，Globus Toolkitの MDS の代わりに https サー バが使用できる．MDSの場合と異なるのは以下の2点である．（1）ユーザがサーバ の認証局（CA）のルート証明書のパスをインストール環境定義ファイルに記述す る．（2）本機構のシェルスクリプトがMDS検索コマンドの代わりにhttpsクライア ントプログラム（本システムが提供）を用いる．

3.3 評価 26

3.3 評価

Relis-Gのライブラリ自動配置機能，ライブラリ可搬化機能，運用方針自動適応機

能の有効性を検証するため，実グリッド環境（表2）にて評価実験を行った．実験環 境は，OSが不均質な計算機群がWANによって接続されている．なお，サイト1(a) の1ホストをクライアントホストとし，表2の全12ホストを配置先サーバとした．

配置するライブラリには，数値計算ライブラリCLAPACK[59]のdgesv関数（連 立一次方程式解法）を遠隔呼び出し可能とするNinf-G[28]用サーバプログラムを用 いた．従って，本実験は，既にサーバ上に存在する高性能な数値計算ライブラリを

Ninf-G用サーバプログラムとリンクさせ，GridRPCを用いて実行する状況の一例

として位置付けられる．

表 2: Relis-G ミドルウェアの適用実験環境

サイト1（電気通信大学）

(a) Globus Toolkit 2.4.3, Ninf-G Ver. 1.1.1, RedHat Linux 7.3 ×5台 (b) Globus Toolkit 2.4.3, Ninf-G Ver. 1.1.1, Solaris 8 ×1台 (c) OpenSSH 3.1p1, Ninf-G Ver. 1.1.1, RedHat Linux 7.3 ×1台

サイト2（産業技術総合研究所）

(d) OpenSSH 3.6.1p2, Ninf-G Ver. 1.1.1, RedHat Linux 7.3 ×5台

3.3.1 自動配置機能の有効性

従来の手作業による配置と，Relis-G を用いた場合の配置におけるユーザに生じ るコスト，特に配置に要する時間を比較する．また，デバッグなどの頻繁なライブ ラリ更新を必要とする場合を考慮し，同一環境に対して複数回配置作業を行う場合 のコストも比較する．配置時間は，コマンド入力等のユーザのキーボード入力に要 する時間（以下，キーボード入力時間）と，指示された計算処理の実行するのに要 する時間（計算機処理時間）の和として算出された．キーボード入力時間は以下の 前提に基づき算出された．

• 1文字あたりの入力時間は1秒

• 入力ミスの頻度は30字に1回

3.3 評価 27

表 3: 適用実験環境における従来手法の配置時間 正しく入力すべき文字数 2741

ミス修正文字数 182 総入力文字数 2923 キーボード入力時間 48分43秒

総入力コマンド数 121 計算機処理時間 1分22秒

配置時間 50分5秒

計算機処理時間は，gettimeofday関数を用いて測定した各コマンドに要する時間の 和として算出された．

手作業の配置作業では，ssh,scp 等の遠隔操作コマンドを用いて全サーバに対して 逐次的に配置作業を行うものとした．

Relis-G の配置作業では，サイト1のサーバ4台とサイト2のサーバ4台のホス

ト名が連番であったため，インストール環境定義ファイルにおいて正規表現による 略記（3.2.1節を参照）により，8ホスト分（48行）の設定記述のコストを省くこと ができた．本実験で用いたインストール環境定義ファイルとインストールワークフ ロー定義ファイルは，それぞれ図5（全50行）および図6（全24行）にあげたもの である．

配置時間の内訳

表3に従来手法における適用実験環境のサーバ群に対する配置時間とその内訳を 示す．また，表4に同環境のRelis-Gにおける配置時間とその内訳を示す．

表4から，Relis-Gの配置時間の大部分を定義ファイルの作成のためのキーボード 入力時間が占めていると分かる．

多数サーバにおける配置時間の比較

適用実験環境よりも多数のサーバを用いる場合の従来手法と本機構の配置時間を，

適用実験環境の測定データに基づき算出した．サーバの台数が12台を超える場合に は表2のサーバ群が同じ構成比で複数群存在するものと仮定して算出を行った．

算出結果を図9に示す．従来手法と，Relis-Gにおける1回目の配置時間を比較す ると，サーバ台数が12台以上の場合，従来手法よりもRelis-Gの方が配置時間が短 いと分かる．この差は，Relis-Gのインストールワークフロー定義ファイルによって，

配置用コマンド列の入力コストが抑えられているためである．また，Relis-G の配

3.3 評価 28

表 4: 適用実験環境におけるRelis-Gの配置時間の内訳 正しく入力すべきコマンド用文

字数

180 インストール環境定義ファイル

の文字数

1571 インストールワークフロー定義

ファイルの文字数

679 ミス修正文字数 162 総入力文字数 2592 キーボード入力時間 43分12秒

総入力コマンド数 4 本機構以外の計算機処理時間 0.35秒 本機構のシェルスクリプトの処理時間の内訳

初期化処理 0.57秒 インストール環境定義ファイル

の変換・読み込み

0.55秒 インストールワークフロー定義

ファイルの変換・読み込み

0.55秒 パッケージ自動作成 1.13秒 運用方針自動取得 10.63秒

（並列）配置 29.86秒 終了処理 0.01秒 計算機処理時間 43秒

配置時間 43分55秒

置時間が台数によらずほぼ一定になっているのは，インストール環境定義ファイル の記述量がサーバの構成の違いに応じて増加するためである（同じ構成のサーバ群 の指定を1つの記述に略記できる）．

定義ファイルの再利用の効果

本機構では，いったんインストール環境定義ファイル・インストールワークフロー 定義ファイルを作成すれば，同じサーバ環境に対して再度配置を行う際にそれらの ファイルを再利用できる．

図9に定義ファイルを再利用した場合の配置時間を示す（Relis-G配置2回目以降 の棒）．この結果から，ユーザが複数回配置を行う際，Relis-Gは，2回目以降の配 置におけるユーザのコストを大幅に軽減すると分かる．