Globus入門 · 2019. 12. 6. · 代わりに、Globus Web の Borja Sotamayor氏の素晴らしい...

Globus入門

知りたくても聞けない、Globusについての全て

Globus Toolkitバージョン4対応

日本語版：グリッド協議会

Globus入門 : 知りたくても聞けない、Globusについての全て : Globus Toolkitバージョン4対応


iii

目次

序 ....................................................................................................................................................................... viii 1. ゴールと原則 ............................................................................................................................................ 1

動機づける事例 .................................................................................................................................. 1 エンタープライズ・ワークロード・マネジメント ............................................................. 1 ハイパフォーマンス・データ・キャプチャー ..................................................................... 2 地震工学シミュレーション用ネットワーク ......................................................................... 2 地球システム・グリッド ........................................................................................................ 2 オープン・サイエンス・グリッド ........................................................................................ 3 生物医学情報学研究ネットワーク ........................................................................................ 3

要件とアーキテクチャーの概要 ...................................................................................................... 3 標準化されたメカニズムとインターフェース ..................................................................... 3 インフラストラクチャー ........................................................................................................ 4 監視と発見 ................................................................................................................................ 4 セキュリティ ............................................................................................................................ 5 データ ........................................................................................................................................ 5 コレオグラフィ ........................................................................................................................ 6

Globus アーキテクチャーのまとめ ................................................................................................ 6 貢献する機会 .......................................................................................................................................... 6 より詳しい説明のために ...................................................................................................................... 7

2. サービス指向アーキテクチャー .............................................................................................................. 8 GT4、分散システムとWebサービス ................................................................................................... 8 サービス指向アプリケーションとインフラストラクチャー .......................................................... 8 Webサービスの実装 .............................................................................................................................. 9 Webサービス仕様 .................................................................................................................................. 10

XML, SOAP, WSDL ...................................................................................................................... 10 WS-Securityと関連仕様 ................................................................................................................ 10 WS-Addressing、WSRF及びWS-Notification ............................................................................. 10 ほかの関連仕様 ............................................................................................................................ 11

サービス指向アーキテクチャー .......................................................................................................... 11 より詳しい説明のために ...................................................................................................................... 12

3. GT4 アーキテクチャー .............................................................................................................................. 14 アーキテクチャーの概要 ...................................................................................................................... 14 事前定義済みのGT4サービス ............................................................................................................... 14 GT4コマンドライン・プログラム ....................................................................................................... 15 GT4セキュリティー .............................................................................................................................. 16 GT4コンテナ .......................................................................................................................................... 16 GT4 Webサービスの配置 ...................................................................................................................... 18 GT4 Webサービスの開発: Javaの場合 ................................................................................................. 18

インターフェース: WSDL ........................................................................................................... 19 実装: Java ....................................................................................................................................... 19 配置記述子: WSDD ...................................................................................................................... 19

より詳しい説明のために ...................................................................................................................... 20 4. 実行管理 ...................................................................................................................................................... 21

コンテキスト .......................................................................................................................................... 23 GRAM概要 .......................................................................................................................................... 23 globusrun-ws コマンドライン・クライアント .............................................................................. 24

基本的なジョブの投入 ................................................................................................................ 24 投入されたジョブとのやり取り .............................................................................................. 25 ジョブの状態とライフサイクル .............................................................................................. 26


Globus入門

iv

ファイル・ステージングとその他の機能 ............................................................................. 27 証明書の委譲 ................................................................................................................................ 28 globusrun-ws の主要なオプションとその他の詳細 ................................................................. 29 ジョブ定義言語の詳細 ................................................................................................................ 30

GRAMクライアントAPI ................................................................................................................... 32 GRAMの設定と管理 .......................................................................................................................... 35 関連するソフトウエアとツール .......................................................................................................... 35

DAGman, Condor-G, and GriPhyN Virtual Data System .............................................................. 35 Nimrod-G: グリッド環境でのパラメーター研究を管理する ............................................. 36 MPICH-G2: グリッド環境でのメッセージ・パッシング ................................................... 36 Ninf-G: グリッド環境でのリモート・プロシージャー・コール。 .................................. 36

ケーススタディ ...................................................................................................................................... 36 Execution Management Case Study 1 ............................................................................................ 36 実行管理のケーススタディその2 .............................................................................................. 36

GRAMの動き ........................................................................................................................................ 36 WS-Resource の利用の仕組み ................................................................................................ 37 セキュリティーの課題 .............................................................................................................. 37 データ操作 .................................................................................................................................. 38

実行管理の将来 ...................................................................................................................................... 38 より詳しい説明のために ...................................................................................................................... 38

5. データ管理 ................................................................................................................................................ 39 GridFTP ................................................................................................................................................... 40 Reliable File Transferサービス ............................................................................................................... 40 Replica Location サービス .................................................................................................................... 40 データのアクセスと統合 ...................................................................................................................... 40 関連するソフトウェアとツール .......................................................................................................... 40 ケーススタディ ...................................................................................................................................... 40

データのケーススタディ1 .......................................................................................................... 40 データのケーススタディ2 .......................................................................................................... 40

各機能の動き ...................................................................................................................................... 40 より詳しい説明のために .................................................................................................................. 40

6. 監視と発見 .................................................................................................................................................. 42 MDS4 ....................................................................................................................................................... 43

収集者と情報ソース .................................................................................................................... 43 情報ソースと登録 ........................................................................................................................ 44 収集サービスの3形態 .................................................................................................................. 44 組み込みの情報ソースとMDS-Indexサービス ......................................................................... 45 MDS4とMDS2の比較 ................................................................................................................... 45

関連するソフトウェアとツール .......................................................................................................... 45 ケーススタディ ...................................................................................................................................... 45

Earth System Grid Monitor ............................................................................................................ 45 例 2 ................................................................................................................................................ 45

各機能の動き .......................................................................................................................................... 45 より詳しい説明のために ...................................................................................................................... 45

7. セキュリティー .......................................................................................................................................... 47 セキュリティー原則 .............................................................................................................................. 47 サポートするインフラストラチャー .................................................................................................. 48 Webサービスにおける認証と認可 ...................................................................................................... 48

Community Authorization Service ................................................................................................. 48 委譲サービス ................................................................................................................................ 48 認可フレームワーク .................................................................................................................... 48 メッセージ・レベル、トランスポート・レベルのセキュリティー ..................................... 48

クレデンシャル・サービス ................................................................................................................ 48 MyProxy ......................................................................................................................................... 49


Globus入門

v

SimpleCA ....................................................................................................................................... 49 GSI-OpenSSH .......................................................................................................................................... 49 関連するソフトウェアとツール群 .................................................................................................. 49 ケーススタディ ...................................................................................................................................... 49

The Earth System Grid Portal ......................................................................................................... 49 2つ目の例 ...................................................................................................................................... 49

各機能の動き ...................................................................................................................................... 50 より詳しい説明のために .................................................................................................................. 50

8. ユーザー・インターフェース ................................................................................................................ 51 9. パッケージと配布 ...................................................................................................................................... 52 10. 種々の重要なツール ................................................................................................................................ 53

eXtensible I/Oライブラリ ...................................................................................................................... 53 Grid TeleControl Protocol ........................................................................................................................ 54 Handle System ......................................................................................................................................... 54 GT4IDE .................................................................................................................................................... 54

参考文献 ........................................................................................................................................................... 55


vi

図目次

1.1. グリッド技術は、二つの部署のリソースプールを連合させ、次の効果をもたらす：総保有コスト (TCO) の削減 (戦略A) と提供可能なピーク能力の増加 (戦略B) .............................................. 1 2.1. Webサービス・アーキテクチャーを定義する様々な仕様の抽象的なビュー ................................ 8 2.2. リクエストとレスポンスのパスを示した、Webサービス実装によく出てくる機能コンポーネントのハイレベル・ピクチャー ................................................................................................................. 9 3.1. GT4.0コンポーネントの概略図 .............................................................................................................. 14 3.2. GT4コンテナはサービスとツール (陰影付き部分) を組み込んでおり、オプションのGT4 WSRF Webサービスを含めた異なるサービスをホストすることができ、発見と管理機能もサポートする ......................................................................................................................................................... 17 3.3. 4種類の異なるGT4コンテナ設定 ........................................................................................................... 17 3.4. Axis がインターフェースを実装するのと構成を記述するのに利用する、Java Webサービスと様々なコンポーネント(陰影付き部分)。 ................................................................................................... 19 4.1. GRAMジョブの状態遷移図 .................................................................................................................. 27 4.2. 下から順に、GRAMと関連付けられた四つのWS-Resources (網掛け) 、それらのWS-Resourcesを操作するために使われる四つのインタフェース、そして、それらのインターフェースがサポートするOperation。 ..................................................................................................................................... 33 4.3. GRAMの実装の構造 .............................................................................................................................. 36


vii

表目次

3.1. GT4コマンドライン・プログラム。行ごとに、1セットのプログラムとこのセット中にあるプログラムの数、簡単な説明、詳細を記述するセクションへのポインタを述べる .............................. 15 4.1. Globus と関連する実行管理ツール ....................................................................................................... 22 4.2. GRAMのジョブの状態 .......................................................................................................................... 26 4.3. 主要なglobusrun-wsコマンドのオプション .......................................................................................... 29 4.4. それらのcardinality (blank=[0..1], *=[0..*])であるジョブ定義要素、それらが置換をサポートするか否か、そしてそれらの定義。 ............................................................................................................. 31 4.5. Managed Job Factory リソース・プロパティ ........................................................................................ 33 4.6. Managed Job のリソース・プロパティと、それらの追加の Managed Executable Job と Managed Multi Job リソースに関連付けられたリソース・プロパティ ............................................... 34 5.1. Globusと関連するデータ管理ツール ................................................................................................... 39 6.1. Globus及び関連の監視、発見ツール ..................................................................................................... 42 7.1. Globusと関連するセキュリティー・ツール ....................................................................................... 47 8.1. GT4と関連するユーザー・インターフェースを提供するツール .................................................... 51 9.1. ................................................................................................................................................................... 52 10.1. ................................................................................................................................................................. 53 10.2. GT4に含まれるXIOドライバー ............................................................................................................ 53


viii

序

Globus Toolkit (GT) は、サービス指向の分散計算アプリケーションとインフラストラクチャーの開発をサポートするために、 1990年代末より開発された。GTのコア・コンポーネントは、セキュリティ、リソース・アクセスと管理、データ移動と管理、リソース発見など基本的な課題を扱う。もっと広い範囲の "Globus Universe" は、コアGT4機能をベースにした多くの有用なアプリケーションレベル機能を提供するたくさんのツールとコンポーネントを包含する。これらのツールは、多くのグリッド・

システムとアプリケーションを開発するために使用されている。

2005年4月に発表された Globus Toolkit のバージョン4は、GT3 の Webサービス機能のインプリメンテーションに比べ、提供するコンポーネントの範囲、機能性、標準の準拠、ユーザビリティ、ドキュメンテーションの品質など、いろいろな面で大きく進歩した。この文書は、GT4 および関連ツールの重要機能や、これらのコンポーネントを使ったグリッド・インフラストラクチャーおよびアプリケーションの開発方法について、最初の入門書を提供することを目的とする。この文書は、ユーザーの

視点から見たテクノロジーとそれを利用するアプリケーション、そして GT4 ベースのアプリケーション開発に必要な実践的なテクニックにフォーカスする。

私たちは以下の順に解説する。GT4および関連ツールの開発の動機となるアプリケーションの紹介; グリッドを構築するための4つのタスク: デザイン、ディプロイメント、アプリケーション、オペレーション ; Webサービス (WS) と WS 前のコンポーネントを含めた GT4 ストラクチャー ; Globus Universe とその様々なコンポーネント; GT4 のパフォーマンス、スケーラビリティと機能テスト; 旧バージョンの GT から GT4 への移行; GT4 のユーザー像; 将来の進みそうな方向性と、歴史の簡単な紹介。

この文書はまだ作成中の文書であって、近い将来著しく充実するだろう。その間、どうか作者に今の

コンテンツへのコメントや追加資料の提案を送っていただきたい。


1

第1章ゴールと原則

このドキュメントは、Globus Toolkit と関連ツールの紹介、そして、分散システム・インフラストラクチャーとアプリケーションの構築にあたって、これらのツールをどのように利用するかの紹介を目的とする。私たちの目的は、Globusと関連ソフトウェアがどうのように構築されているか、そして、アプリケーション構築にあたってこれらのソフトウェアの最も有効な利用方法を公開することである。

そのために、以下の順番で見て行く: Globus のデザインの動機になる要件、様々な Globus Toolkit のコンポーネント、関連する技術的仕様、アプリケーションの要件を満たすために Globus と連携して利用できる関連ソフトウェア、またこれらのソフトウェアが実際の環境にどのように使われたか、ど

のように使われるべきかを説明するケーススタディ。この文書は完全なリファレンスではなく、ガイドである。ほとんどの節で、もっと詳しい技術情報を求める読者に対し、参照資料へのポインターを提供する。特に、Globus アプリケーションを開発するのに必要な技術概念を提供し、コマンドラインプログラムについて記述するが、プログラム例は全く提供していない。代わりに、Globus Web の Borja Sotamayor氏の素晴らしいチュートリアル[73]や他のドキュメントへのリンクを読者に提供する。

この文書の私たちの意図は、Globusソフトウェアとそのディプロイメントとアプリケーションについて、理論ではなく実践を説明することである。この序文で少々と、最後の"将来の方向性"の節でもう少し長めに、Globus Toolkitデザインの動機となった分散コンピューティングのビジョンについて話すが、このドキュメントはあくまでも、Globusとグリッドの将来のあるべき姿ではなく、今現在の状況について語る。

動機づける事例

ここで、6つの例を使い、この文章に記述するテクノロジーを開発する動機となったインフラストラクチャーとアプリケーションを説明する

エンタープライズ・ワークロード・マネジメント

最近SAP AGは、Globusベースのグリッドを利用するように修正された主力製品R/3の３つのアプリケーションのデモを行った。これらのデモンストレーションは、エンタプライズ・グリッドがどのようにGlobusの技術を利用して、変化するワークロード要求に適応し、アプリケーションごとに専用ハードウェアが必要とする設定によるハードウェア要求を削減 (あるいはスループットの増加、図 1.1参照) するかを示した。

Internet Pricing and Configurator (IPC) とWorkforce Management (WFM) は SAP の CRMアプリケーションスイートからのアプリケーション、Advanced Plannerand Optimizer (APO) はサプライチェーンマネジメント (SCM) スイートのアプリケーションである。それぞれのアプリケーションは、Webブラウザーのようなインタラクティブなクライアントやバッチ処理から生成される大量なリクエストを受け付け、個々のリクエストをワーカープロセスに分配するようにデザインされている。今回、SAP はこれらのアプリケーションを修正し以下の機能を実現した: (a) 計算要求に応じてワーカープロセスの数を動的に調整する機能。(b) Globusのコンポーネントを使って、これらのワーカープロセスを実行するリソースを発見・予約し、そして、リソース上でワーカープロセスの実行、監視、削除する機能。

図 1.1. グリッド技術は、二つの部署のリソースプールを連合させ、次の効果をもたらす：総保有コスト (TCO) の削減 (戦略A) と提供可能なピーク能力の増加 (戦略B)


ゴールと原則

2

ハイパフォーマンス・データ・キャプチャー

ある会社は、継続的にハイレート (毎秒5～10ギガビット) で受け取る大量なデータをキャプチャーする問題に直面した。ソリューションとして、正確なキャプチャーの後に、データの初期処理とメタデータの抽出を実行して、結果データを確実に保存し、ストレージ施設にあるそのデータをハイレート (合計毎秒10～40 ギガビット) で分散しているクライアントコミュニティから利用できるようにし、更に、そのデータに対して分析とデータ・マイニングを実行するプラットホームを提供しなくてはならなかった。

これらの要求を満たすために構成されたプラットホームに、Globus のコンポーネントが大量に使用された。GridFTP は信頼性の高いデータ・キャプチャーとデータ移動に使われた。データの移動は、データ・キャプチャーとデータストレージ/分散クラスターの間、データストレージ/分散クラスターとアーカイブやリモート・ストレージなどセカンダリー・データ・システムの間、データストレージ/分散クラスターとクライアントの間で行われた。そして、ジョブ管理のために Globus 実行管理コンポーネントが使われた。Globus を利用するメリットは、コモディティなハードウェアとソフトウェアが利用できることである。以前この会社は、独自のハードウェアとソフトウェアを利用して同じよう

なシステムを構築しようとしたが、高価かつサポート困難で、要求変化に対応できなく、完成まで長い期間が必要なシステムになってしまった。

地震工学シミュレーション用ネットワーク

アメリカ国立科学財団の地震工学シミュレーション用ネットワーク (Network for Earthquake Engineering Simulation, NEES) は、全米の地震工学エンジニアを互いに結びつけ、データ・リポジトリー、数値シミュレーション用コンピューター、さらには、振動テーブル、波タンクといった実験用

施設など、様々なリソースと彼らを結びつけた[70、74]。 NEES のソフトウェアは Globus のセキュリティ、データ・アクセス、コンピューター・アクセス、およびこれらの様々なコンポーネントに安全かつ信頼できるリモートアクセスを提供するサービス実装コンポーネントをベースに構築され、異なるサイトの組織が関与し、物理的手法と数値的手法を同時に利用する実験のデザイン、実行、モニ

タリング、事後解析に、リモートユーザーが参加することが可能になった。

地球システム・グリッド

地球システム・グリッド (Earth System Grid, ESG) は、気候変動研究者が作り出した数十テラバイトの気候シミュレーションデータに遠隔アクセスできるように、複数の実験室でサービスを展開した[45]。


ゴールと原則

3

登録済みのユーザーは、ウェブ・ポータル経由でリクエストを出し、それに従いデータを読みだし、

分割し、そして必要に応じて ESG のデータ・サーバーから大量なデータを転送する。Globusと関連サービスは、認証、認可、データ・アクセス、データ移動とシステムモニタリングに利用される。

オープン・サイエンス・グリッド

オープン・サイエンス・グリッド (旧称 Grid2003[54]) は、CERN で行った大規模強粒子衝突実験 (ATLAS と CMS)、スローン・デジタル・スカイ・サーベイプロジェクト (注：銀河地図作製プロジェクト)、LIGO の重力波サーチ実験、Fermilab の BTeV 実験、分子構造分析とゲノム分析用のアプリケーション、コンピューターサイエンス研究プロジェクトなど様々なプロジェクトからのジョブと

データスケジューリング分野で数ヶ月継続的に製品レベルのサービスを提供する要求に答え、マルチ・バーチャルの組織かつアプリケーションドリブンのグリッド実験室を構築した。このインフラストラクチャーは一年以上稼動し、30のサイト、3000のプロセッサー、10個以上のアプリケーションからの1300を超えるシミュレーション・ジョブと、サイト間で2テラ/日以上のデータ転送をこなした。Globus サービスは、他のグリッド・ソフトウェアと連携して、VO (仮想組織) 管理、認証、リソース・アクセス、データ移動およびそれらとの関連機能を提供する。

生物医学情報学研究ネットワーク

生物医学情報学研究ネットワーク(Biomedical Informatics Research Network, BIRN)[41] は国立衛生研究所のプロジェクトで、人間の疾病の大規模研究において基本的に新しい機能を可能にするような、データ共有機能を提供するためのITインフラストラクチャーを構築しようとしている。現在 BIRN コンソーシアムは、12の大学と16のリサーチグループ[63]にまで拡大している。これらすべてのサイトに、計算とストーレジ用クラスターを含む標準ハードウェアが配置されている。このハードウェアの

上に、Globus および関連テクノロジーをベースとした、認証、リソース発見、実行可能ファイルの転送と計算管理、データ・ストレージ・リソースへの安全かつ一貫したアクセスなどの機能を実現した、BIRN 標準ソフトウェアが稼動している。

要件とアーキテクチャーの概要

以上の6つの例だけでは、Globus が使われた多くのアプリケーション全てを、正当に判断することはできない。しかし、これらの例は確かに、再現可能性があるいくつかの重要な特徴を捕えている。例えば、異なるコンピュータ・システム、ワークユニット、部署、組織に分散している、多数のリソースの使用を調整しなくてはならないというニーズがよくある。この節では、これらの重要な特徴をレ

ビューし、 Globus を利用してこれらの関連する要件を満たすためのアーキテクチャー構成を紹介する。

標準化されたメカニズムとインターフェース

6つのすべての例において、一部のタスクを実行するために、一連のソフトウェア・コンポーネントがネットワーク上で、メッセージ交換を使って相互に作用しなければならない。このような分散システムは様々な方法で構成され得るため、コンポーネントインターフェースの記述、メッセージの交換、メッセージ送信権限の検査、特定タスクの実行の要求など、共通機能のメカニズムの標準化は現実的に大きなアドバンテージがある。このような標準化は、個々のコンポーネントの構築と理解、同じインターフェースの異なる実装の相互運用性、コンポーネント共有、アプリケーション開発に有用な再

利用可能なツール群の開発などを促進する効果がある。

これらの考慮点を動機として、GT4は、インターフェースの定義とコンポーネントの構築に、Webサービスのメカニズムを大量に使用している(第2章を参照)。Webサービスは、フレキシブルで、拡張可能な、広く採用された XML ベースのメカニズムであり、ネットワーク・サービスの記述、発見、呼び出しに使われる; その上、Webサービスのドキュメント指向のプロトコルは疎結合の相互作用に適しており、 (その疎結合の相互作用が) 堅固な分散システムとして望ましいということがよく議論されている[62] (2.5節参照)。GT4は、主要な (すべてではない) コンポーネントのサービス・インタ


ゴールと原則

4

ーフェースを Webサービス・インターフェースとして定義しており、標準的な Webサービスのメカニズムを使って GT4 のサービス・インターフェースを記述したり、GT4 サービスを操作したりすることが可能になる。

Webサービス・インターフェースを実装する分散システム・コンポーネントの開発をサポートするツールは、過去数年間いろいろ開発された。これらのソフトウェアは、開発者がアプリケーション・ロジックの実装に専念できるように、メッセージ処理やリソース管理、セキュリティ問題を対処してくれる。GT4 はこれらのソフトウェアと GT4 特有の追加コンポーネントをパッケージして、Java、 C、Python で書かれた GT4 サービスを配置・管理するための Webサービス・コンテナとして提供する。

Webサービスにおいて1つ不利な点は、現在の実装ではパフォーマンスが比較的低いことである。そのために、私たちは、パフォーマンス重視のオペレーション(例えば、高速データ移動) に関しては、他のプロトコルを使う必要があるかもしれない。ゆくゆくは、より速い実装が現れることを期待する。

インフラストラクチャー

エンドユーザーのアプリケーションは一般的に、ポートフォリオの価値計算や、遺伝子配列の分析と

いった比較的抽象なオペレーションに関心があるが、結局、コンピューティングとして、コンピューターやストレージや装置のような物理デバイスを含む、インフラストラクチャーの操作と管理が最終的には必要になってくる。エンドユーザーのアプリケーションを構築するのに使われる、サービス指向の概念と Webサービスのメカニズムは、適切なインターフェースが定義されている限り、前述のインフラストラクチャー構成要素に対するアクセスと管理に使用されることも可能である。

GT4 は次の機能の実現にWebサービス・インターフェースを実装している: 計算用エレメントおよびそのエレメント上で実行する処理の管理機能 (Grid Resource Allocation and Management service, GRAM) 、装置への接続機能 (Grid TeleControl Protocol, GTCP)、データ転送の管理機能 (Reliable File Transfer service, RFT)。GT4 は Webサービス・インターフェースがまだ定義されていない、データ転送サービス GridFTP も提供している。これらの様々なコンポーネントは、信頼性が高く、安全かつ管理可能な相互作用を個々のリソースに提供することによって、より大きなインフラストラクチャーを構築するための基盤を提供する。

GridFTP を除いて、GT4 の様々なコンポーネントで実装されたインターフェースは、まだどんな標準策定組織においても標準化されることがなかった。しかし、私たちは、近い将来それぞれの領域で進歩を見ることを期待する。

監視と発見

監視と発見は、分散システムにおいて重要な機能であり、システムが複数の場所に及び、すべてのコ

ンポーネントの詳細状況を把握する人間が一人もいそうもない場合は、特にそうである。監視機能は、このような環境下で起こり得る問題を見つけ、診断する手段を提供する。一方、発見機能によって、目的のプロパティーを持つリソースやサービスを特定することができる。以上の両タスクとも、複数の、おそらく分散しているであろう情報源から、情報を収集する能力を必要とする。

これらの機能の重要性を認識し、監視と発見のメカニズムは GT4 の基盤レベルで以下で述べるように提供されている。

第1に、GT4 は、XML ベースのリソース・プロパティーとネットワーク・エンティティを関連付けて、これらのプロパティーにプル (クエリー) あるいはプッシュ (サブスクリプション) モードでアクセスする標準メカニズムを提供する。これらのメカニズムは基本的に WSRF と WS-Notification の仕様に基いており、すべての GT4 サービスとコンテナに組み込まれ、ユーザーが開発するいかなるサービスにも簡単に取り入れられることができる。

第2に、GT4は、登録されている情報ソースから最新のステート情報を収集する収集サービス (aggregator services) 3種類を提供している。興味のある情報ソースがすべて WSRF/WS-Notification インターフェースをサポートしているわけではないことを考慮し、これらの収集サービスは、データが


ゴールと原則

5

XML 形式であるかどうかと関係なく、任意の情報ソースから情報収集するように設定することができる。この3種類の収集サービスは、それぞれレジストリ(MDS-Index)、アーカイブ(MDS-Archive)、とイベントドリブンのデータ・フィルター(MDSTrigger)を実装する。

第3に、GT4 は、収集した情報にユーザーが検索、アクセスする手段として、ブラウザー・ベースのインターフェース、コマンドライン・ツールとWebサービス・インターフェースを提供している。

これらの異なるメカニズムは、さまざまな分散コンポーネントの集合を監視したり、発見の目的でコ

ンポーネントの情報を取得したりするための強力なフレームワークを提供する。

セキュリティ

セキュリティはどんなコンピュータシステムでも重要であり、特に複数のロケーションにリソース (時にはユーザーも含む) が散在する分散システムにとっては重要で、挑戦的である。一部のプレーヤーは、「誰が何ができる」とコントロールしようとするかもしれない。例えば、個別のリソースのオーナーや、計算を開始させたユーザーや、リソース共有を管理するため作り出した「仮想組織」を含めてコントロールする。このコントロールは様々な強制的なポリシーとオーディットが含まれるかもしれない。これらの要件を満たすメカニズムをデザインする際、私たちは、コミュニケーションを保

護することだけではなく、バックエンドのシステムが侵入された時のインパクトも制限しなければいけない。すべてのソリューションにおいて一つの完全なセキュリティ"ソリューション"は、必ずアイデンティティの確立、ポリシーの適用、行動のトラッキングなど関連するコンポーネントを結合して、ある特定のセキュリティゴールを達成する。GT4と関連ツールは、このようなシステムを構成するために使える強力なビルディング・ブロックを提供する。

最も低いレベルで、GT4 の標準ベースのセキュリティ・コンポーネントは、メッセージ保護、認証、委譲、認可を実現するための信任状のフォーマットとプロトコルを実装している。GT4 のデフォルト構成では、それぞれのユーザーとサービスが、 X.509 公開鍵信任状を持っていると想定する。プロトコルは、2つのエンティティの間に、互いにの信任状のチェックや、メッセージ保護の目的でセキュアなチャネルの確立や、一定期間中にリモート・コンポーネントが自分の振る舞いをするための (権限) 委譲目的の信任状の作成と転送などできるように実装されている。GT4サービスに関連する認可呼び出しは、特定のオペレーションが許可すべきかどうかを決定するのに利用できる。

GT4 の正式サポート・ツールおよび他のソースから利用可能なサポート・ツールは、ユーザー認証やグループ・メンバーシップの確認などに利用される信任状の作成、格納、および取り出しをサポートする。

データ

Globus アプリケーションの一つの共通テーマは、単一つあるいは複数のサイトにある大量なデータの管理、アクセス方法の提供、そして統合のニーズである。この「データ」問題は、非常に広くて複雑であり、個別のソフトウェアでそれを完全に解決できると主張するソフトウェアはないだろう。しかしながら、複数の GT4 のコンポーネントで実装したメカニズムであれば、個別で利用するか、また他のコンポーネントと連携して興味深いソリューションの開発に利用できる。

GridFTP は、信頼性が高く、安全かつ高性能なメモリ・ツー・メモリとディスク・ツー・ディスクのデータ転送を実現するための、ライブラリとツールの両方を提供する。 GridFTP は、一般的な FTP データ転送プロトコルに GridFTP 拡張を実装して、従来の FTP クライアントとサーバとの間の相互運用もできる。

Globus replica location service (RLS) は複製されたファイルとデータセットの位置に関する情報をメンテナンスし、アクセス手段を提供する、非常にスケーラブルで堅固なシステムである。

英国の eScience プログラムが開発したGlobus Data Access and Integration (DAI) ツールはリレーショナルおよび XML データへのアクセスを提供する。


ゴールと原則

6

コレオグラフィ

Globus アプリケーションの中の最後の共通テーマは、異なるロケーションでの活動を調整するニーズである。調整されるべきである「活動」には、計算タスク、データ転送、装置の操作、サービスまたは物理リソースの監視とコントロールなどが含まれるであろう。この簡潔なリストで示すように、「コーディネート」の概念は、幅広くて多面的であるため、一つのコーディネート・ソリューションだけで、すべての目的を満足させることはできそうもない。

GT4 自体は、コーディネートに関する限られたダイレクト・サポートしか提供していない。しかし、GT4 によって可能になったインターフェースとメカニズムの一様性は、DAGman (疎結合用の、または DAGs のため) や MPICH-G2 (密結合の並列計算) など、より高いレベルのコーディネート・ツールの開発を容易にする。これらのツールについて???第4章で議論する。

Globus アーキテクチャーのまとめ

この節で紹介した GT4 の主要要素をここで要約する。それぞれの要素の詳細について後続の章でカバーする。

サービス指向アーキテクチャー. GT4 ソフトウェアは、標準プロトコル経由でサービスのセットが相互作用するようなアプリケーションをサポートするようにデザインされている。 GT4 ソフトウェアは、完成したサービスと有用なプロトコルを実装するライブラリの両方を含んでいる。開発者は、これらのサービス、ライブラリ、および他の関連するソフトウェアを利用することによって、簡単なものから複雑なシステムまで比較的すばやく構築することができる。

インフラストラクチャー・サービス。GT4 は計算リソースやデータリソースなど、インフラストラクチャー要素へのアクセス、監視、管理、アクセスコントロール用のサービスを含む。

Webサービス。GT4 はサービス記述、発見、アクセス、認証、承認などに業界標準の Webサービスのプロトコルとメカニズムを多用している。

GT4 コンテナ。GT4 ソフトウェアは Java、C、および Python で書かれた、Webサービスをホスティングするための GT4 コンテナの構築に使用することができるコンポーネントを含んでいる。

セキュリティ。高度に標準をベースにしたセキュリティ・サブシステムは、メッセージ保護、認証、委譲、及び認可を扱う。

標準。Globusは、運用可能で再利用可能なコンポーネントの構築と、標準ツールの利用を容易にするために、可能である限り、標準や他の広く採用された仕様を実装している。

関連ツール。GT4 コンポーネントは、一般的に、エンド・ユーザーのニーズを直接的に扱うことがない。Webブラウザーよりも、TCP/IP ライブラリまたは Webサーバーの実装に類似する。代わりに、GT4 は特定のユーザコミュニティーにとって必要とされたより高いレベル機能を提供するさまざまなエンド・ユーザー・コンポーネントとツールを提供する。これらのコンポーネントとツールは GT4 自身と共に「Globus Universe」を構成する。

制約 Globus ソフトウェアは多くの設定で有用であることが分かったが、その能力に完全だというには程遠い、そして、パフォーマンス、ユーザビリティ、および堅固さに関してはまだ改善の余地がある。私たちは、このドキュメントの残りの部分で主な制約を明らかにするよう試みる。

貢献する機会

規模が大きく、多様性のある Globus コミュニティーは、Globus ソフトウェアのスコープと品質を改良するために一生懸命働いている。あなた(読者)が、貢献することに共感を感じることを願っている。あなたが貢献できる方法は様々である。


ゴールと原則

7

ソフトウェアを利用して経験を報告するソフトウェアを使用して、あなたの経験を報告することは、それが肯定的なものでも否定的なものでも、非常に役立つ場合がある。遭遇した問題のレポート、よくドキュメント化されたものは特に、バグフィックスや新機能の順位付けに役にたつ。成功したデプロイメントとアプリケーションのレポートは、ソフトウェア開発の継続的なサポートを正当化するのを助けることができる。

ドキュメントとサンプルの開発相当な進歩があったが、他のユーザーが Globus ソフトウェア及び関連ツールの利用開始を助けることができるコードのサンプル及び関連ドキュメンテーションの提供を熱く期待している。時間をかけて、あなたの成功したアプリケーションをドキュメント化していただきたい。あなたは、他のユーザから十分に感謝され、恐らくあなたの評判も高くなるだろう。

ソフトウェア開発への貢献ユーザが欲しがっている新機能のリストは、いつも Globus 開発者が扱うことができる範囲をはるか超えている。あなたは、バグフィックス、テストケース、新しいモジュールの開発、完全に新しいサブシステムの開発などへの貢献によって、手伝うことができる。問題になるコンポーネントにもよるが、これらの活動は、Apach Software Foundation (www.apache.org) かGlobus (www.globus.org) 管理下のソフトウェアと関連することを含む可能性もある。

より詳しい説明のために

書籍「The Grid: Blueprint for a New Computing Infrastructure (2nd Edition)」 [49] には、この章で紹介したアプリケーション、テクノロジー及び研究チャレンジなどのトピックが含まれている。しかし、Globus や他の特定のテクノロジーの詳細はあまり提供されていない。

論文「The Grid: Computing without Bounds」[44] は、2004年前半におけるグリッドのビジョン、テクノロジー、アプリケーションの現状について、ハイレベルな紹介を提供する。

書籍「Grid Computing: Making the Global Infrastructure a Reality 」[28]は、グリッド・コンピューティングとサイエンス分野での関連アプリケーションについて、多くの研究論文を集めた。

論文「The Anatomy of the Grid」[53] は、仮想組織のコンセプトを紹介して、Grid の展開とアプリケーションに必要な異なったプロトコルの特徴をアーキテクチャー的な絵で提示している。


8

第2章サービス指向アーキテクチャー

ここで、Webサービス関連の基本コンセプト、GT4 内、特に "WS Core" 内のコンポーネントでの Webサービスの利用と実装について紹介する。

GT4、分散システムとWebサービス

GT4 は次のような分散システムを構築するのための一連のソフトウェア・コンポーネントである: 様々な個別のソフトウェア・エージェントがネットワーク上でメッセージ交換を介在して相互作用し、タスクを実行するシステム。時々長くて予測できないネットワーク遅延や、部分的に失敗する可能性や、並行性の問題など、特別なチャレンジに直面しているシステム[62] 。さらに、システムのコンポーネントは異なった管理ドメインの中に位置していて、その結果、分散制御とネゴシエーションの問題を引き起こすかもしれない[53]。

GT4 は、もっと具体的に言うと、分散システムを構築するためにWebサービスのメカニズムを実装する (若干の例外はあるものの) 一連のソフトウェア・コンポーネントである。Webサービスはさまざまなプラットホーム及びフレームワーク上で実行する、異なったソフトウェア・アプリケーション間で相互作用する標準手段を提供する:

Webサービスは、ネットワークを越えて相互作用可能なマシン・ツー・マシンの相互作用をサポートするようにデザインされたソフトウェア・システムである。Webサービスはマシンが処理可能なフォーマット (具体的に言うと WSDL) でインターフェースを記述する。他のシステムは (Webサービスが) SOAP メッセージで記述している方法で Webサービスと対話する。この SOAP メッセージは通常は HTTP を利用して、他のウェブ関連標準と共に、直列化したXML形式で運搬される[29]。

Webサービスは分散システムにおけるエンティティが様々な操作を実行するために交換しなければならないメッセージを標準化する。最も低いレベルで、この標準化はメッセージ運搬に使われるプロトコル (通常HTTP)、メッセージのエンコーディング (SOAP) 、およびインターフェース記述 (WSDL) と関連する。クライアントは SOAP メッセージを送付することによって Webサービスと対話する; クライアントは次に、回答として応答メッセージを受けるかもしれない。もっと高いレベルでは、別の仕様で安全なメッセージ交換、管理 (例えば、WSDM)、および発見やコレオグラフィーなど、ハイレベルの機能の規則を定義する。図2.1はこれらの異なったコンポーネントテクノロジーの1つのビューを提示する。 2.4節で特定の仕様ついて議論する。

図 2.1. Webサービス・アーキテクチャーを定義する様々な仕様の抽象的なビュー

サービス指向アプリケーションとインフラストラクチャ

ー

Webサービス・テクノロジー、特に GT4 は、サービス指向のアプリケーションおよびサービス指向のインフラストラクチャーの両方を構築するために使用することができる。しばしば物議を醸し出す、


サービス指向アーキテクチャー

9

"サービス指向"という言葉についての議論は2.5節で後述するとして、ここでは、サービス指向のアプリケーションがサービス・インターフェースによって定義された構成コンポーネント (言い換えれば、Webサービス) で構築されることに注目すしておく: 例えば、金融や生物学のデータベース、オプションの値段を決めるルーチン、または生物学の配列の分析など。 WebサービスとSOAの多くの記述が、そのようなコンポーネントのインターフェースを定義するタスクにフォーカスしており、このことを

解説するのにしばしば「株価サービス」(Webサービスの"Hello World") などの例が利用される。

分散しているコミュニティーからこのようなリクエストを多く処理するときは特に、多数の分散した

ハードウェアとソフトウェアのコンポーネントを調整・管理するという関連問題に直面する。この問題にも Webサービスを利用することができ、そこで、サービス指向インフラストラクチャーという用語を紹介する。これは、コンポーネントとアプリケーションのサービス品質目標の達成に使われる、リソース管理とプロビジョニングのメカニズムを意味する用語である。多くの GT4 の機能は、サービス指向インフラストラクチャーの構築を可能にすることに関わっている。

Webサービスの実装

クライアントの視点から見れば、Webサービスは単にネットワーク経由でアクセス可能な SOAP メッセージを処理するエンティティである。その覆いの下にある実体はもう少し複雑である。サービスの実装を簡素化するために、一般的にWebサービスの実装は以下のように分離する:

1. ホスティング環境 (またはコンテナ)。SOAP メッセージを受信する (ドメインに依存しない) ロジックであり、 SOAPメッセージを受信し、適切なコードを特定して処理を呼び出し、メッセージを処理する。また、関連する管理機能を提供する可能性もある。

2. Webサービス実装つまり (ドメイン特有の) メッセージを処理するコード。

この関心事の分離は、開発者が新しいサービスを実装する際、ドメイン特有のメッセージ処理コード

を提供するだけでよいことを意味する。

また、ホスティング環境のロジックをさらに以下のように分割することも一般的である: SOAP メッセージの転送に関わる部分(通常はHTTPを利用するので"HTTP エンジン"、もしくは"Web サーバー" -- アプリケーション・サーバーと呼ばれることもある) と、SOAP メッセージの処理に関わる部分 ("SOAP エンジン"、もしくは"SOAP プロセッサ")。図2.2はこれらの様々なコンポーネントを図解する。

図 2.2. リクエストとレスポンスのパスを示した、Webサービス実装によく出てくる機能コンポーネントのハイレベル・ピクチャー

パフォーマンス特性、サポートする Webサービスの実装言語、セキュリティー・サポートなどによって、多くの異なるコンテナが存在する。 GT4 で使われているものを以下で述べる。



10

Webサービス仕様

GT4 の基礎となる、Webサービス仕様のポインタを提供する。これらは、Webサービスのアーキテクチャーを定義するコア仕様 (XML、SOAP、WSDL); WS-Securityとセキュリティに関連するその他の仕様; そして、ステートフルなリソースの定義、命名、相互作用に使用する WS-Addressing、WSRF、 WS-Notification などを含む。また、今後のGT発展で重要になってくる可能性がある、新しい仕様についても簡潔に述べる。これらの仕様を使用し、開発しようと動機づける要件に関する重要な情報源の1つに、Open Grid Services Architectureがある。[46]

XML, SOAP, WSDL

XML は、標準的、フレキシブルな、そして拡張可能なデーター形式として Webサービスの中で広く使用されている。 XML 構文に加えて、他の重要な仕様として、XML Schema[15] とXML Namespaces[32] がある。現在のWebサービスのツールは通常テキスト・シリアライゼーションを採用しているが、バイナリー・エンコーディングも使用可能であり、しかもより高い効率を提供する可能性があるのに注意してほしい。

SOAP 1.2[14] は標準的、拡張可能で、組立可能 (composable) なフレームワークであり、サービス提供者とサービス要求者の間で XML メッセージをパッケージして、交換する仕組みを提供する。 SOAP の伝搬は、下回りのトランスポート・プロトコルに依存しないが、HTTP が最も一般的に使われる。

WSDL 1.1[38] は、Webサービスを記述するための XML 文書である。標準化されたバインディング規則は、SOAP および他のメッセージングの基本標準と共に組み合わせて、 WSDL をどのように使用するかを定義する。 3.7節で議論されたように、WSDLインターフェースをコンパイルして、メッセージの構成と通信の管理をクライアント・アプリケーションの代わりにできる、プロキシー・コー

ドを生成することができる。プロキシーはXMLメッセージ構造をアプリケーションで直接操作することができるネイティブ言語のオブジェクトに自動的にマッピングする。プロキシーによって、XMLを理解して操作しなければならないという状況から、開発者は解放される。

WS-Securityと関連仕様

WS-Security 関連の一連の仕様は、Webサービスのコンテキストにおいて、認証、認可、ポリシーの表現、トラスト・ネゴシエーションに関連する、さまざまな問題を扱う[71]。これらの仕様と他の関連仕様 (特に、Security Authorization Markup Language(SAML)[59]を含む) を複数使用して、 GT4は以下のように、メッセージ保護、認証、委譲、および認可などに取り組む。 [3]:

• TLS (トランスポート・レベル) またはWS-Securityと WS-SecureConversation (メッセージ・レベル) は、SOAPと共にメッセージ保護メカニズムとして使われる。

• X.509エンド・エンティティ証明書またはユーザー名とパスワードは、認証のクレデンシャルとして使われる。

• X.509プロキシ証明書とWS-Trustは委譲に利用される。

• SAMLアサーションは認可に利用される。

WS-Addressing、WSRF及びWS-Notification

多くの関連仕様は、サービス指向インフラストラクチャーにとって重要な、ステートフル・エンティ

ティを表現、操作できる機能を提供する。これらのステートフル・エンティティには、様々な種類の物理リソース、ソフトウェア・ライセンスのような論理的なコンポーネント、およびタスクや作業フローなど一時的なアクティビティが含まれる。

WS-Addressing[30]仕様は、 Webサービスとメッセージの位置を特定するための、トランスポートに



11

依存しないメカニズムを定義する。具体的には、この仕様は、Webサービスのエンドポイントの識別とエンドポイント識別子のエンド・ツー・エンド保護を実現するための XML要素を定義する。

WS Resource Framework (WSRF) 仕様は、Webサービスを利用して、ステートフルなリソースをモデル化してアクセスする、汎用的でオープンなフレームワークを定義する[10, 47]。このフレームワークには以下のメカニズムが含まれる : ステートのビューを記述するメカニズム (WS-ResourceProperties)、Webサービスと関連するプロパティーを通じた状態管理をサポートするメカニズム(WS-ResourceLifetime)、これらのメカニズムが、Webサービスのグループにまでどのように拡張できるのかを記述するメカニズム(WS-ServiceGroup)、障害対応のメカニズム(WS-BaseFaults)。

WS-Notification 仕様群は、それによってWebサービスがお互いの情報を散布できるような、パターン・ベースのアプローチを定義する[9,56]。このフレームワークにはベーシックな通知(WS-Notification)、トピックベースの通知(WS-Topic)、およびブローカーに介された通知 (WS-BrokeredNotification)のメカニズムが含まれる。

競合する仕様の提案によって、Webサービスの標準化分野は混乱の状態であることを特筆する。特に、マイクロソフトとその他ベンダーが最近提案したWS-Transfer [19], WS-Eventing [31], WS-Management [23]は、異なった構文を使用するが、それぞれWSRF, WS-Notification, WSDM (後に議論する) と類似する機能を定義する。将来、これらの違いが解決されることを願っている。

ほかの関連仕様

GT4 には最近の GGF で成立した FTP への GridFTP 拡張の実装[20]と GGF で開発した GGF の OGSA-DAI 仕様の DAIS 実装が含まれている。

WS-Interoperability (WS-I) 機構[24]は、異なった実装の相互運用性を促進するために、既存のWebサービス仕様をどのように使用するかを定義する、多くのプロファイルを作成した。 WS-I Basic Profileはメッセージングとサービス記述について言及する: 主としてXML、SOAP、WSDLについてである。 WS-I Basic Security Profileは基本的なセキュリティー・メカニズムについて言及する。他のプロファイルは開発中である。

OASISが開発中のWeb services distributed management (WSDM)仕様[16]は将来のGT実装において、 GTの部品を管理する手段としての役割を果たす可能性がある。

DMTFが開発中のWS-CIM仕様[8]は、将来のGT実装において、物理的なまた仮想的なリソースを表現する手段として役割を果たす可能性がある。

Global Grid ForumのOpen Grid Services Architecture(OGSA)ワーキング・グループは、将来のサービス指向インフラストラクチャーとアプリケーションに必要な機能のハイレベル記述と、この機能がどのように個々の仕様に分解されるのかを示すフレームワーク、これらを提供するドキュメントを完成させた[1]。 OGSAワーキンググループは現在、WS-Iプロファイルのように、特定のグリッド・シナリオを解決するのに使用できる技術仕様を特定する、OGSAプロファイルを定義している最中である。


サービス指向アーキテクチャー (SOA) という用語について、更にいくらか論ずる。それは、Webサービス・コミュニティで広く使われている言葉ではあるが、首尾一貫して使われているとは限らない。 1つの一般的な使用方法としては、単にWebサービス技術の使用を意味する。しかしながら、SOAを考え出した人々の意図は、むしろ分散システムの2つの異なった構築スタイルを対比するために作ったように思える。分散オブジェクトシステムとは[46]:

システム境界を跨ったリクエストを仲介したり、メソッドの引数データーを整列化/非整列化したりする、独自あるいは標準化されたメカニズムによって、オブジェクトの初期化とメソッド呼び出しのセマンティックがリモート・システムに対して公開されている分散システム。分散オブジェクト・システムが通常 (必ずではない)持



12

つ特徴として、システムのメソッドをサポートするためにかなり複雑な内部ステート

を持ち、オブジェクトがそれをメンテナンスするということや、オブジェクトとそれを使用するプログラムとの間の相互作用の粒度が細かいということや、共有実装型システムと、オブジェクトとプログラム間のインターフェースの階層に重きを置く

ということがある。

対象的に、サービス指向アーキテクチャー (SOA) は[29]:

一般的に以下のような特徴を持つ分散システム・アーキテクチャーの1形式:

• 論理的な視点: サービスは、実際のプログラム、データベース、ビジネス・プロセスなどの抽象的でロジカルなビューであり、何をするかで定義され、通常は、あるビジネス・レベルのオペレーションを実行する。

• メッセージ指向性: サービスはエージェントの特性自体ではなく、プロバイダー・エージェントとリクエスタ・エージェントの間で交換されたメッセージに関して正式に定義される。実装言語、プロセス・ストラクチャー、さらにデータベース構造などの特徴を含めたエージェントの内部の構造は、SOAにおいて故意に抽象化されている: SOAの規律によれば、サービスを実装したエージェントがどのように構成されるかは、知らなくてもよく、知る必要もない。これの主な恩恵としていわゆるレガシーシステムがある。エージェントの内部構造に関するいかなる知識をも避けることによって、メッセージを処理するコード (これにより、正式なサービス定義に従うようになる) にラッピングされた、どんなソフトウェア・コンポーネントやアプリケーションでも取り入れることができる。

• 記述指向性: サービスは、マシンで処理可能なメタデーターによって記述される。この記述はSOAの公開性をサポートする: 外に公開して、サービスの利用に重要である詳細だけが記述に含まれるべきである。サービスのセマンティックは直接か間接的にその記述で記録されるべきである。

• 粒度: サービスは、比較的大きくて複雑なメッセージと、数の少ないオペレーションを利用する傾向がある。

• ネットワーク指向性: 絶対の要求ではないが、サービスはネットワークを越えて使用される傾向がある。

• プラットホーム中立性: メッセージは、プラットホーム非依存の、標準化されたフォーマットでインターフェース経由で届けられる。 XMLはこの制約に最も適するフォーマットである。

サービス指向アーキテクチャのこれらの特徴は、分散システムで起こる以下の問題をより効果的に解

決できると主張される: レイテンシー及び基盤になるトランスポートの非信頼性による問題、呼び出し側とオブジェクトの間の共有メモリの不足、部分的な失敗シナリオで発生する問題、リモート・リソースへの同時アクセスのチャレンジ、互換性のないアップデートが参加者に行われた場合の分散システムのもろさによる問題などがある。[29、62]

分散オブジェクト・システムとサービス指向アーキテクチャの両方を築き上げるのに、一般にWebサービス技術、特にGT4を使用することができる。特定の設定で従われる特定のデザイン原則は、ターゲット環境、スケール、プラットホームの異質性、および予想された今後の発展を含む、さまざまな事柄に依存するだろう。


ドキュメント: 「Web Services Architecture」[29]はWebサービスの基礎になる概念とテクノロジーに関する良い紹介を提供する



13

論文: 「A Note on Distributed Computing」[29]はサービス指向のアーキテクチャーと分散オブジェクトシステムの区別を動機づけて説明する。。

論文: 「Grid Services for Distributed System Integration」[62](より長いバージョンは「The Physiology of the Grid」[51]) は、現在WSRFと呼ばれるものの基礎となる概念と動機づけにいて紹介する。これらに関するさらに詳細な記述は「Modeling Stateful Resources with Web Services」 [50]にある。


14

第3章 GT4 アーキテクチャー

アーキテクチャーの概要

図3.1で示されるように、GT4は一連のサービス実装 (サーバーコード) と関連クライアントライブラリの両方を含む。 GT4はWebサービス(WS)コンポーネント(左側)と非WSの部品(右側)の両方を提供する。クライアントドメインにある白いボックスはGT4サービスかGT4対応のサービスにアクセスするカスタムアプリケーション、およびサードパーティツールを意味する

すべてのGT4 WSコンポーネントがWS-I準拠のトランスポートとセキュリティーのメカニズムを利用し、その結果、互いまたと他のWSコンポーネントと相互運用できることに注意してください。さらに、WSと非WSの両方を含むすべてのGT4コンポーネントがX.509エンド・エンティティ証明書とプロキシ証明書をサポートする。したがって、クライアントは同じクレデンシャルを使って、GT4のすべてのWSと非WSコンポーネントと認証できる。

この図はすべてのGT4のコンポーネントを示したわけではない: いくつか、(例えば、様々なセキュリティーとコミュニケーションライブラリ) 後で紹介する。すべてのコンポーネントのさらに詳細について以下で述べられる。

図 3.1. GT4.0コンポーネントの概略図

事前定義済みのGT4サービス

GT4は一連の事前定義済みサービスを提供している。ここで簡潔にリストして、第4章で詳細について記述する。

9個のGT4サービスはWebサービス・インターフェースを実装する: ジョブ管理 (GRAM: 4.2節); Reliable File Transfer (RTF: 5.2節); delegation(7.3.2節); MDS-Index、MDS-TriggerとMDS-Archive(合わせて監視・発見システム、あるいはMDSと呼ぶ: ???); community authorization (CAS: 7.3.1節); OGSA-DAI data access and integration (5.4節) ; GTCP Grid TeleControl Protocol for online control of instrumentation (10.2節)。これらの中で、MDS-Archive、GTCPとOGSA-DAIはテクニカルプレビューであり、将来インターフェ


GT4 アーキテクチャー

15

ースおよび実装が変わる可能性があるかもしれないことを意味する。

これらのサービス中の二つ、GRAMとMDS-Indexはpre-WSのレガシー実装も提供された。近い将来、WS実装の実績が増えるのに従って、これらのpre-WS実装は廃止されるだろう。

さらに、以下の3つのGT4サービスのWSインターフェースはまだ提供されていない (将来提供される可能性はある) : GridFTP data transport(5.1節)、 replica location service(RLS: 5.3節)、MyProxy online credential repository(7.4.1節)。

他のライブラリは強力な認証と認可メカニズムを提供し、それに対して、eXtensible I/O(XIO)ライブラリはさまざまな基礎トランスポートプロトコル(10.1節)への便利なアクセスを提供する。SimpleCAは軽量なCAである(7.4.2節)。

GT4コマンドライン・プログラム

このドキュメントの私たちは主にグリッドとGT4のユーザービューにフォーカスするので、GT4のコマンドラインプログラムを切り口にしてGT4を見ていくのは自然である。表3.1はGT4に含まれるコマンドライン・プログラムを要約する。このドキュメントはこれらのプログラムをそれぞれ簡潔に説明する。

言うまでもなく、この表はGT4がユーザにとって利用可能な機能をすべて網羅しているわけではない。特に、クライアントAPI、ライブラリ、 GT4が提供するコンテナと関連ツールが提供する効果的な機能について含まれていない。

• クライアントAPI: Java、C、Pythonで書かれるプログラムから直接コンポーネントを呼び出しできるように、ほとんどのGT4 コンポーネントは同時にクライアントAPIを提供している。

• ライブラリとコンテナ: 一部のGT4 XX

• そのほか

表 3.1. GT4コマンドライン・プログラム。行ごとに、1セットのプログラムとこのセット中にあるプログラムの数、簡単な説明、詳細を記述するセクションへのポイン

タを述べる

コマンド # 説明 §

cas-* 14 Community authorization service 7.3.1節

globus-credential-* 2 Delegation Serviceにおけるクレデンシャルのインストールと更新

7.3.2節

myproxy-* 10 MyProxy serviceにクレデンシャルの保存及びサービスの管理

7.4.1節

grid-ca-sign 1 SimpleCAを使ってX.509証明書を生成する

7.4.2節

gsi* 3 GSI使用可能なOpenSSH及びssh、scp、sftpクライアント

7.5節

grid-* 10 X.509プロキシ証明書とgridmap filesの管理

XX

globus-url-copy 1 GridFTPクライアント 5.1節

rft* 2 Reliable file transferクライアント 5.2節

globus-rls-* 3 RLSのクライアント、管理コマンド、サーバー

5.3節



16

コマンド # 説明 §

globusrun-ws 1 GRAMクライアント 4.2節

mds-servicegroup-add 1 MDSのサービスグループにエントリーを追加

6.1節

globus-*-container 2 Globusコンテナの起動と停止 XX

wsrf-* 8 WSRFのリソース・プロパティーとやり取り

XX

wsn-* 4 WS-Notificationサブスクリプションの生成と管理

XX

GT4セキュリティー

XX.

GT4コンテナ

GT4ソースコードはグリッド・アプリケーションにとって重要な一連のWebサービス仕様の実装を含んでいる。これらの仕様の一部は標準で、あるいは将来標準になる可能性がある (例えばWSRF、WS-Notification) 。一方、他のもの (例えば、GRAM、RFT) は現時点Globus固有のものである。

これらの実装は、他のコンポーネント (Webサーバー、SOAPエンジン、他のWebサービス仕様の実装など) と結合して、多様な異なる GT4コンテナ (図3.1の白いボックスの部分) を作り出すことが可能である。ここでのコンテナとは、一連の共通特徴を持つWebサービスコンテナを意味する。GTコンテナは:

• メッセージ・トランスポート・プロトコルとしてSOAP/HTTPを実装し、すべてのコミュニケーションにトランスポート・レベルとWS-Securityのメッセージ・レベル・セキュリティーの両方を実装する;

• WS-Addressing、WSRF及びWS-Notificationの機能を実装

• Log4j[47]を使ったロギングをサポートする。それは Jakarta Commons Logging APIを実装するものである。更に、

• コンテナに配置されているサービスについての情報、バージョンや開始時間といったコンテナの特性へのアクセスを提供する、WSRF WS-Resourcesのプロパティーを定義する。

このように、すべてのGT4コンテナは以下のことが可能になる (図3.2参照)

1. ベーシックWS仕様と呼ばれる仕様だけで定義されるクライアント・インターフェースを持つサービス (カスタムWebサービス) をホストする

2. WSRFと関連メカニズムを使用するクライアント・インターフェースを持つサービスをホストする

適切なソフトウェアがインストールされてあれば、GT4 Javaコンテナは以下のこともできる

3. GT4が提供している、GRAM, MDS, RFTなどの先進的なサービスをホストする

どんなサービスが配置されているかに関係なく、アプリケーション・クライアントは以下のことがで

きる:

4. GT4コンテナのレジストリ・インターフェースを使用して、ある特定のGT4コンテナにどんなサービスがホストされているかを判断すること。また、GT4コンテナ管理インターフェースを使用



17

して、基本管理機能を実行すること。

全てのGT4コンテナのインターフェースはWS-I Basic Profileに準拠しており、設定によってはWS-I Basic Security Profileにも準拠できることを特筆したい(2.4.4節)。

図 3.2. GT4コンテナはサービスとツール (陰影付き部分) を組み込んでおり、オプションのGT4 WSRF Webサービスを含めた異なるサービスをホストすることができ、発見と管理機能もサポートする

GT4のディストリビューションは、3種類の異なったWebサービス実装言語(Java、C、およびPython)用のGT4コンテナ(図3.3)を構築するための、ソフトウェアと説明書を含んでいる。

GT4 Javaコンテナ。Javaで実装された、Webサービスに対するGT4のサポートは、GT4 の Java WS core のコードによって成っている。 GT4 の Java WS core コードは、セキュリティーと管理のためのコードをサポートするだけでなく、WSRF と WS-Notification を実装する。このコードは、SOAPエンジンとしてのApache Axisと共に、WS-addressingやWS-Securityの実装など、他の関連Apacheコンポーネントと一緒に使用されるようにデザインされている。完全なGT4 Javaコンテナを出荷するために、GT4 Java WS CoreとAxisの組合わせを、GT4で提供される軽量Javaコンテナの上でも、Tomcat のような、より多機能で複雑なサーブレット・コンテナ上でも稼動させることができる。前者のアプローチは、より簡単なインストールや管理ができ、あるサイトやリソースが他の目的のために既にTomcatを稼動しているような場合を除いて、推奨できる。また、そのようなGT4 Javaコンテナも同様に、GRAM、RFT、MDS-Index、 MDS-TriggerとMDS-Archiveといったような、Javaで実装された様々なGT4サービスをホストすることができる。

図 3.3. 4種類の異なるGT4コンテナ設定

GT4 C コンテナ。Cで書かれた、Webサービスに対するGT4のサポートは、GT4 の C WS Coreによって成っている。これはセキュリティーと管理用のサポートコードに加え、WSRFとWS-Notification を実装する。

Python Webサービス。Pythonで書かれた、Webサービスに対するGT4のサポートは、GT4 Python WS Coreによって成っている。これはセキュリティーと管理用のサポートコードに加え、WSRFと



18

WS-Notification を実装する。完全なGT4 Pythonコンテナを出荷するために、私たちはこのコードを、Zolera SOAPインフラストラクチャーやTwistedコンテナと組み合わせる。

GT4 Webサービスの配置

「配置」という用語は、特定のコンピュータにWebサービスをインストールし、実行を初期化するタスクを指す。サービスを配置しなければならない環境によっては、最初に、GT4コンテナをインストールして、構成する必要があるかもしれない。 GT4で事前に定義されたサービス(例えば、GRAM、RFT)と、その他のWebサービスの両方を、GT4コンテナの中に配置するのに使用される一般的な手法について、ここで議論する。

1つのWebサービス・コンテナが、ゼロ個以上のWebサービスをホストし、そのそれぞれがコンテナの異なる機能を利用するということがありえる。従って、コンテキストによっては、Webサービスを配置するということは以下のことを含む可能性がある:

1. すでに配置されたGT4コンテナに、Webサービスを配置する;

2. 最初に、すでに配置された非GT4コンテナに、追加のライブラリ (例えばWSRF) をロードして"GT4準拠" にし、その後でコンテナにサービスを配置する;

3. 最初に新しいGT4コンテナを配置し、その中にWebサービスを配置する; あるいは

4. GT4コンテナとWebサービスの組み合わせを、同時に配置する。

GT4のディストリビューションは通常、様々な環境においてこれらのタスクが容易にできるように、便利なパッケージを提供するだろう。これによって、ユーザーが特定のサービスを実行することができるシステムを作成するために、やむを得ず多くのインストールと構成ステップを実行しなくても済む。例えば、コンピューターにGT4 GRAM (Javaで書かれる) を配置するタスクに直面する時:

• GT4 Javaコンテナが既にインストールされていれば、直接それにGRAMサービスを配置することができる。

• サイト内にすでにTomcatがインストールされて、Globusに特化したコードがない状態であれば、 WSRF、WS-Notification、GRAMを配置する必要がある。

• ゼロから配置する場合は、GT4 JavaコンテナとGRAM Webサービスを含む完全なディストリビューションが提供される可能性もある。その場合は、単にそのディストリビューションをインストールし、構成して実行する(アプローチ#4)。

GT4 Webサービスの開発: Javaの場合

Apache Axisを使ったJavaサービスの開発と配置の、特有なメカニズムについて、少しコメントを追加する。図3.4で書かれている、主な関連ステップは以下のようになる:

1. サービス・インターフェースを定義する。サービスの抽象インターフェースを記述する、Web Service Description Language (WSDL) ファイルを作成する。

2. サービスを実装する。ここで、もしWSRFのメカニズムが使われるなら、サービス実装と関連のリソース・プロパティーを含む Javaのルーチンを開発する。

3. 配置パラメータを定義する。サービスの設定を記述するWeb Services Deployment Descriptor(WSDD)ファイルを作成する。

4. すべてをコンパイルし、GARファイルを作成する。コンパイルによりアプリケーション独自のインターフェース・ルーチンが生成され、それが、SOAPメッセージからWebサービスの引数への、もしくは逆に、Webサービスの引数からSOAPメッセージへの整列化/非整列化を取り扱う。



19

5. サービスを配置する

Borja Sotamayor氏の素晴らしいチュートリアル[73]は、これらの様々なステップに関する詳細を提供している; ここで、最初の3つの段階にかかわるものについて、それぞれ少し紹介する。

図 3.4. Axis がインターフェースを実装するのと構成を記述するのに利用する、Java Webサービスと様々なコンポーネント(陰影付き部分)。

Axisはまた、(サービスの引数がJavaの簡単な型であれば) JavaのソースコードやWSDDファイルから、直接WSDLを生成できるツールを提供している。しかしながら、サービスのコードから自動的に生成されたWSDLはしばしば言語依存もしくは実装依存の型を含むことがあり、同じサービスの他の実装と相互運用できない可能性がある。従って、GT4は、開発者にWSDLを供給するように要求する。

インターフェース: WSDL

WSDLドキュメントはWebサービスを記述し、クライアントにサービスと接続及び交信に必要な情報を提供する。具体的には、portType コンポーネントを使用してWebサービスの抽象インターフェースを定義する。そして、サービスがサポートするオペレーションと、各オペレーションにおいてサービスが送受信するメッセージのフォーマットを明記する。さらに、サービスがWSRFリソース・プロパティーに対するオペレーションを実装するなら、WSDLにリソース・プロパティーを処理するコンポーネントの定義を含める: 例については、 Sotamayor氏のチュートリアル[73]を見たれたい。

完全なWSDLドキュメントは、抽象インターフェースがどのように具体的なプロトコル・メッセージとマッピングするかを明記する、バインディング・コンポーネントを含まなければならない。 GT4は自動的にこのコンポーネントを生成する。

実装: Java

サービス実装は、様々なサービスのオペレーションのためのJavaコードを、適切に提供する。もし、サービスがWSRFのメカニズムを使用するなら、サービス実装には、リソース実装のためのコードとリソース・ホームのためのコードの両方が含まれなければならない。これも、詳細に関してはSotamayor氏のチュートリアル[73]を参照されたい。

配置記述子: WSDD



20

配置記述子ファイルは、そのWebサービスをどのように公開すべきであるかをWebサーバーに知らせる。例えば、サービスのURIを指定することにより、それを行なう。配置記述子は、WSDD (Web Service Deployment Descriptor) 形式で書かれている。


既に Globus Toolkit4 プログラマー・チュートリアル[73] 、GT4プログラムの書き方を学びたい人にとって、唯一、最も重要なテキストを挙げた。


21

第4章実行管理

実行の差し迫った時が一番、精神は集中する。

— 作者不明

すなわち、あなたは以下のことを求める:

• プログラムをネットワーク・サービスとして利用可能にすること (サイズは変化する)

• 配布すること

• リモート・コンピューター上で、実行ファイルを実行すること

• 並列プログラムを複数の分散したコンピューター上で実行すること

• 一連の疎結合のタスクを実行すること

• 計算の実行を操作すること

これらのタスクは、全て実行管理の範疇に収まる。

実行管理ツールは、リモート実行の開始、監視、管理、スケジューリング、調整と関係している。 GT4は、これらの目的のために、基礎的な仕組みとして Grid Resouce Allocation and Management (GRAM) インターフェースをサポートする。GT4 GRAM サーバーは、通常、データのステージング、プロキシー証明書の委譲、や統合された手順での計算実行の監視と管理を行うために、デリゲーション・サーバーおよびRFTサーバーとともに配置される。

関連するツールは、三つの主要な種類に分けられる。第一に、クラスタや他の LAN 上のコンピューターのために、GRAM と連携可能なスケジューラーがある (Condor [73], OpenPBS, Torque, PBSPro, SGE, LSF)。第二に、リモート・コンピューターへの異なったインターフェースを提供するシステム (OpenSSH) や、リモート・コンピューターにタスクを配備するためにGRAMを使うことにより、様々な並列プログラミングモデルを実装しているようなシステム (Condor-G [64], DAGman, MPICH-G2 [55], GriPhyN VDS, Nimrod-G [60])がある。第三に、異なったクラスタに異なったタスクを割り当てるような様々なメタスケジューラー (CSF, Maui) がある。

この章とこの章に続く章で、私たちは、表の形でGlobus と関連するツールを要約する。私たちは、表4.1に、実行管理ツールの要約をまとめている。このリストでは、イタリック体でGT4のコンポーネントを区別している。それぞれのコンポーネントの、簡単な説明に加えて、その成熟度に対するおおよその評価 ("M") を定める。この部分は、そのコンポーネントが多くのグリッドプロジェクトで使われている ("3") 、いくつかの有望なプロジェクトをもっている ("2")、それが研究段階のソフトウエアであるか、広く使われていないか、もしくはその両方である ("1")、ということを示す。"G" の列は、GT4のコンポーネントの場合、それが Core コンポーネントか (T)、寄付されたコンポーネントか (C)、ということを示し、他のコンポーネントの場合、GT4 のリリースと既に互換性を持っているか (Y)、すぐにそのようになると推測されるか (N)、ということを示す。

Globus Toolkit は、一組の Webサービスを、ローカルまたはリモート・コンピューター資源上で処理を投入したり、監視したり、キャンセルしたりすることのできるような、そのクライアントと共に提供する。このシステムは、まとめて"GRAM" もしくは、同じような機能を提供する Webサービス以前のそれと区別するため、"WS_GRAM" と呼ばれる。私たちは、ここでは、より多くの機能を提供する、Web サービスを基礎としたシステムについてのみ述べる。

GT4は、GRAMのコマンドラインクライアントと、Java/C/Python のクライアントAPIの両方を提供する。私たちは、ここでは、コマンドラインクライアントの機能について述べる。APIも本質的に同様の機能へのアクセスを提供する。


実行管理

22

GRAMは、Webサービスの管理インターフェースを構成するために WSRF と WS-Notification の仕組みをどのように使用するかについての、興味深い例でもある。それゆえ、いくらかGRAMの実装を説明することに時間を費やす。

GRAMは、将来、新興の標準を開発したり、仮想化を含む追加の資源管理機能を取り込んだりし、著しく進化するように思われる。私たちは、この作業についても、簡単に批評する。

表 4.1. Globus と関連する実行管理ツール

名称目的 M G

Grid Resource Allocation & Management service

GRAMサービスは、コンピューター上での、ジョブの投入、監視、制御をサポートする。Unix Shell (Fork)、Platform LSF、PBS、 Codor スケジューラーへのインターフェースを提供する。また他のインタフェースも開発されるだろう。MPICH-G2ジョブに対する複数ジョブ投入、ジョブ内でのプロセス調整、複数ジョブ内でのサブジョブの調整のサポートも含む。

3 T

Java CoG Kit Workflow DAG、状態、ループをサポートするKarajan ワークフロー・エンジンを使用する。実行の際には、GRAMサーバーにタスク実行を命令する。

1 C

Community Scheduler Framework

CSFは、WS-Agreement の仕様にのっとった、オープンソースのメタ・スケジューラーである。

1 C

Condor-G [18] GRAMが利用可能なリモート・コンピューター上での、ジョブの実行の管理、ジョブ監視の制御、ロギング、通知、ポリシーの強制、

フォールト・トレランスの提供そして証明書管理を行う。

3 Y

DAGman ファイル書いたり、読んだりすることで通信するタスクの、有向非

巡回グラフ (Directed acyclic graphs :DAG) の実行を管理する。Condor-G と共に動作する。

3 Y

MPICH-G2 [55] 1つか以上の分散したコンピューターをにわたる、並列メッセージ・パッシング・インターフェース (Message Passing Interface :MPI) プログラムの実行を行う

3 Y

Nimrod-G [60] パラメーター・スタディーの宣言の仕様と、分散したコンピュータ

ー上でのそれらの実行の管理。計算経済に基づいたスケジューラー

は、緩やかなリアルタイム・デッドラインを提供する。ユーザーは、コマンドラインまたはWebポータルを介して操作する。

3 Y

Ninf-G リモート・サービスにアクセスするための、GridRPC リモート・プロシージャー・コールの仕様の実装の1つ。

3 Y

GriPhyN Virtual Data System

複雑なデータ指向型のワークフローを定義し、スケジュールし、管

理するツール。ワークフローは、高レベルな仮想データ言語で定義

可能である。仮想データカタログは、現在と過去の実行を追跡するために使用される。ジョブおよびデータ配置の発見的手法を含む。DAGman/Condor-Gを実行管理に使用する。

2 Y

Condor, OpenPBS, Torque, PBSPro, Sun Grid

GSI認証を使用したアクセスが、GRAMインターフェースを通して提供されているスケジューラー。オープンソースであるCondorは、デスクトップ・システムのプールを管理することに特化している。OpenPBSとTorqueは、ポータブル・バッチ・システム(Portable Batch System :PBS)のオープンソース版である。

3 Y

Engine, Load Sharing Facility

スケジューラー。PBSProは、Altairによる商用バージョンの1つ。SGEは、オープンソースと商用バージョンのどちらも入手可能。LSFは、Platfrom による商用システム。

Maui Scheduler メタ・スケジューリングのサポートも持つ、クラスターとスーパー 3 ?


実行管理

23

名称目的 M G

コンピューター上で使用する先進的なジョブ・スケジューラー。

コンテキスト

XX

GRAM概要

どのようにして、リモート・ユーザーが、ローカル・コンピューター上でプログラムを実行できるよ

うにするか。1つの手法は、このプログラムをWebサービスとしてアクセス可能にすることである。これをするために、あなたは、あなたのプログラムを実行するあるWebサービスのオペレーションを定義し、実装するだろう。それから、例えば、ローカルもしくはリモートのコンピューター上で、"a"を入力として、"b"を結果として返すような"foo"という処理を要求するために、単純に"foo(a,b)"を呼び出すクライアントを作成するかもしれない。

この、プログラムをリモートからアクセス可能にするための単純な手法は、非常に適切であることも

多くありえる。しかしながら、この手法にはまた、いくつかの必要条件がある。それは、この単純な手法が、以下のものを扱わないということである

• 状態。実行されるであろう計算タスク (ジョブ) が、実行中に、ジョブが実行されている計算資源の状態やそのジョブが関連付けられているファイルシステムの状態に影響する入出力操作を行う可能性がある。このゆえに、きっかり1回だけ実行するという意味づけは重要である。ユーザーは何の通知もなかった場合、ジョブは終了したかもしれないが通知メッセージが失われたというケ

ースもあるため、リクエストを単純に再投入できないのである。

• ユーザーの実行プログラム。私たちは、ユーザーに実行するプログラムを提供させるように望む可能性がある。

• 入出力のステージング。実行プログラム、入力データ、出力データは、容量が大きい、リモートに存在する、異なった呼び出し間で共有されるという可能性がある。時には、これら全ての条件が重なる可能性もある。

• ストリーミング出力。ユーザーの中には、特に対話型のユーザーは、ジョブ実行と平行して出力データファイルにアクセスすることにメリットを受けるものもいる。

• 制御。ユーザーが、多くのリソースを消費するジョブを中止する機能を要求する可能性がある。

• スケジューラー。より大きな計算資源は、通常、効率性とパフォーマンス向上のために、全ての投入されたジョブの実行を最適化しながら割り当てと優先順位付けのポリシーを実行するスケジューラーの制御の元で運用される。

• 監視。データのステージングとスケジューラーによって、より複雑なジョブの状態遷移が導き出される可能性がある。ジョブは単純に、実行中、完了、失敗という状態をとるだけではなく、待機していたり、中断されていたり、データ・ステージング中であったり、もっと他の状態であったりする可能性がある。ジョブの状態を検索したり、定期的に監視したりする機能を要求するユーザ

ーも、中にはいるかもしれない。

GRAMシステムとそのクライアント・ソフトウエアは、これらの問題を扱うために開発されている。GRAMは、任意のプログラムを実行したり、信頼性の高い操作を実行したり、ステートフルな監視を実行したり、証明書を管理したり、ファイル・ステージングを行ったり、スケジューラーと対話した

りする機能が重要だとされるような状況で使用されることが意図されている。もし、これらの機能が要求されないのであれば、GRAMを使用することは適切ではない可能性がある。もしアプリケーションが程々の入力/出力データしかもっておらず、それらをステートレスな方法 (言い換えると、結果デ


実行管理

24

ータや失敗のシグナルのようなもののみが重要である方法) で操作し、何度も呼び出されるのであれば、アプリケーションを特定した形のWebサービスとして公開することを考える方が良いかもしれない。

これから見ていくように、GRAMインターフェースは、それぞれの成功したジョブ投入に対し計算ホスト上で関連付けされているジョブと似通ったライフタイムを持つステートフルなエンティティー -- ManagedJob -- を作成することにより、先進的な管理機能に対するこのニーズを満たす (事実、ライフタイムは、通常、幾分長く、それゆえ、クライアントは、それが終了した後でもジョブの状態を決めることができる) 。GRAMでの"submit"が成功すると、新しいManaged Job に対するハンドル -- すなわち、WS-Addressing のエンドポイント・リファレンス、もしくはEPRとも呼ばれる -- を返される。それから、クライアントは、このハンドルを使ってジョブのステータスを検索したり、ジョブをKillしたり、ジョブのステータスの変更やジョブの作り出した出力の通知を得るために、ジョブに対して"attach"したりする。クライアントは、このハンドルを他の同様の操作を行う権限のあるクライアントに伝えることが可能である。それが、先行する節で述べたGRAMの多くの先進的な機能を実現可能にするManaged Jobの構造である。

システム管理者の観点からも、GRAMについて述べる。ここで鍵となる概念は、GRAMはリソース・スケジューラーではなく、標準的なメッセージ・フォーマットを使用して異なったローカル・リソース・スケジューラーのセットと通信をするためのエンジンである、ということである。GT4 GRAMの実装は、単に個々のリクエストに対して、新たなUnixプロセスForkするような"Fork Scheduler"に対するインターフェースと同様に Condor, LSF, SGE そして PBS といった各ローカルスケジューラーへのインターフェースも含んでいる。システム管理者は、これらのローカルスケジューラー・インターフェースに対し、適切な設定作業を行わなければならない。最終的に、私たちは、GRAMの実装の様々な側面を述べる。これから見ていくように、GRAMの実装は、重要な機能を提供するようなモジュラー実装を成し遂げるために、他の様々なGT4のコンポーネントを利用する。

globusrun-ws コマンドライン・クライアント

これらから見ていくように、globusrun-ws コマンドは、強力なツールである。基本的なジョブの投入、監視・管理機能のみならず、ファイル・ステージングや、証明書の委譲、きっかり1回のジョブ投入、タイムアウト、メッセージのプライバシー、認可、のような洗練された機能についても、サポートしていることをこれから述べる。

基本的なジョブの投入

まず、最初の例として、私たちは、"/bin/touch" プログラムを"touched_it"という引数を付けて実行すために使用される、globusrun-ws コマンドを紹介する。

% globusrun-ws -submit -job-command /bin/touch touched_it

このコマンドは次のように構成される。まず、コマンド名を指定し、"-sbumit"フラグはそれがジョブ投入であることを示し、"-job-command"フラグは、このコマンドの残りの部分が、コマンドと、プログラム名と (この場合) プログラムの1つの引数を含んでいることを示している。エラーが無ければ、プログラムが投入され、実行される。globusrun-ws コマンドは、ジョブ状態の情報をいくつか表示し、終了する。

% globusrun-ws -submit -job-command /bin/touch touched_it Submitting job...Done. Job ID: uuid:c51fe35a-4fa3-11d9-9cfc-000874404099 Termination time: 12/17/2004 20:47 GMT Current job state: Active Current job state: CleanUp Current job state: Done Destroying job...Done.


実行管理

25

GT4 GRAMは、ジョブの投入を表現する、XMLに基づいたジョブ定義言語の仕様をもサポートしている。この言語については、後ほど詳細に検討するので、ここでは、単にこの後の例がこの言語によってどのように表現されているのかを紹介する。まず最初にファイルの内容を表示 ("cat") し、-job-description-file オプションを使用して、コマンドラインからプログラムを実行する。

% cat touch.xml <job> <executable>/bin/touch</executable> <argument>touched_it</argument> </job> % globusrun-ws -submit -job-description-file touch.xml

どこでこのプログラムが実行されるのかは、まだ指定していない。通常の場合、目標となるGRAMサーバーは、コマンドの中で指定されたファイル中に記述されているEPRにより指定される。例えば以下のようになる:

% cat gram.epr <factoryEndpoint xmlns:gram="http://www.globus.org/namespaces/2004/10/gram/job" xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/03/addressing"> <wsa:Address> https://viz-login.isi.edu:9000/wsrf/services/ManagedJobFactoryService </wsa:Address> <wsa:ReferenceProperties> <gram:ResourceID>PBS</gram:ResourceID> </wsa:ReferenceProperties> </factoryEndpoint> % globusrun-ws -submit -job-description-file touch.xml -factory-epr-file gram.epr

明らかなことだが、このようなEPRを記述するのは扱いにくい場合もあるので、指定されたGRAMサービスのURLとタイプから、自動的にEPRを構成するオプション (-factory と -factory-type)も、globusrun-ws コマンドは提供する。したがって、上の例のようにEPRを記述する代わりに、以下のように記述することも可能である。

% globusrun-ws -submit ¥ -factory https://viz-login.isi.edu:9000/wsrf/services/ManagedJobFactoryService ¥ -factory-type PBS -job-command /bin/touch touched_it

globusrun-wsコマンドは、URLとタイプからEPRを構成するための規約にしたがう。この規約は標準化されていないため、globusrun-ws コマンドは、GRAMの他の実装に対しては機能しない可能性がある。

この章の最初の二つの例では、ターゲットのGRAMサーバーを指定していなかったことを思い出してほしい。特別な指定がないときは、-factory と -factory-type のデフォルトは、それぞれ、localhost と forkである。それゆえ、最初の例は、ローカル・コンピューター上で稼動しているFork GRAMサーバーに特定のプログラムを投入する要求を行うことと同等である。

% globusrun-ws -submit -factory localhost -factory-type fork ¥ -job-command /bin/touch touched_it

投入されたジョブとのやり取り

globusrun-ws コマンドは、上記の例で使用されているデフォルトのジョブ投入モードにおいては、ジョブが投入された後も実行され続ける。この永続的なジョブとの接続は、二つの目的を満たす。第一の目的は、上記の例に見られるように、globusrun-ws コマンドが、ジョブの状態についての情報を表示することを可能にするためである。第二の目的は、globusrun-ws コマンドが、投入されたジョブに対してkillシグナルを伝達することを可能にするためである: globusrun-wsコマンドをkillすると、投入されたジョブをkillしようと試みる結果となる。

このインタラクティブ・モードは、多くの状況下で役に立つ。しかしながら、クライアントによって


実行管理

26

は、globusrun-wsコマンドがジョブを投入し直後に戻ってくるようにしたいと思うかもしれない (バッチ・モード: -batch)。ジョブがバッチ・モードで投入された場合、もしくは、インタラクティブ・モードでのジョブ投入中にネットワーク接続が失われる場合、ユーザーは、ジョブの状態を検索したいと望むかもしれない。これをサポートするためにGRAMでは、新しいジョブに対して生成される新しい ManagedJob リソースが、次なるジョブの投入時に返されるように、ユーザーが要求できるようになっている。これは、EPR が格納されるべきファイル名 -job-epr-output-file フラグを使って指定することでなされる。

% globusrun-ws -submit -job-epr-output-file mj.epr -job-command /bin/touch touched_it

このようなManagedJobのEPRを入手したクライアントは、以下のようにしてジョブの状態を問い合わせることができる:

% globusrun-ws -status -job-epr-file mj.epr

もしくは、ジョブに再接続することができる:

% globusrun-ws -monitor -job-epr-file mj.epr

もしくはジョブを停止することができる:

% globusrun-ws -monitor -job-epr-file mj.epr

ジョブの状態とライフサイクル

私たちは、ジョブの状態を参照した。??? と図4.1 に詳細化されているように、 GRAMは、ジョブの実行モデルを、最初の投入されていない状態から Done もしくは、Failedまでの一連の流れによって想定する。

表 4.2. GRAMのジョブの状態

状態説明

Unsubmitted ジョブはまだ投入されていない

StageIn ジョブが実行ファイルまたは入力ファイルのステージ・

インの完了を待っている

Pending ローカル・スケジューラーがジョブ実行をまだスケジュ

ーリングしていない

Active ジョブが実行されている

Suspended ジョブ実行が中断されている

StageOut ジョブの実行が完了している; 出力ファイルがステージ・アウト中である

CleanUp ジョブの実行とステージ・アウトが終了している; タスクのクリーンアップが行われている


実行管理

27

状態説明

Done ジョブが正常に終了している。

Failed ジョブが失敗した。

図 4.1. GRAMジョブの状態遷移図

ファイル・ステージングとその他の機能

今までの全ての例において、実行ファイルはターゲット・コンピューター上にあり、入力データは引

数として渡され、出力データは、ターゲット・コンピューター上で、ファイルに出力されている。しかしながら、実行ファイル、もしくは、その他のファイルがターゲット・コンピューターにステージ・

インする必要があったり、出力ファイルがステージ・アウトされなければならないというケースがあるだろう。ジョブの定義にファイル転送の宣言を追加する事でファイル・ステージングを指定することができる。これらの宣言は、RFTの構文にしたがっており、それによって第三者転送が可能になる。したがって、それぞれのファイル転送は、送信元URLと送信先URLを指定しなければならない。URLは、 GridFTP の URL (リモートのファイルに対して) か、ファイル URL (ローカルのファイルに対して) で指定する。例えば、ステージ・イン要求の次の例では、送信元URLは GridFTPのURL (この例では、gsiftp://job.submitting.host:2888/tmp/mySourceFile)であり、このURL は、ジョブ投入マシンのファイルシステム上でアクセス可能な送信元ドキュメント (この例では、/tmp/mySourceFile) として解決される。実行時には、リモート・マシン上でGRAMサービスにより使用される Reliable File Transfer サービスが、GridFTPを使用してリモート・ファイルを取得し、そのファイルを指定されたローカルファイルとして書き出す (この例では、file:///$expanded /my_file で、 ~/my_fileとして解決される)。

<fileStageIn> <transfer> <sourceUrl>gsiftp://submit.host:2888/tmp/mySourceFile</sourceUrl> <destinationUrl>file:///${GLOBUS_USER_HOME}/my_file</destinationUrl> </transfer> </fileStageIn>

注意

さらに、RFTの定義するQoS要求をそれぞれの転送で定義することができる。詳細については、RFTの文書を参照されたい。

${GLOBUS_USER_HOME} という変数は、GRAMサーバーが実行時に置換する以下4つの変数のうちの1つである。

• GLOBUS_USER_HOME: ローカルのアカウント/ユーザーのホームディレクトリーのパス

• GLOBUS_USER_NAME: ジョブを実行しているローカルのアカウント

• GLOBUS_SCRATCH_DIR: ユーザーが使う計算ノード間で、ファイルシステムが共有されいてる、代わりのディレクトリ名。通常、ユーザーのデフォルトHOMEディレクトリより多くのスペース


実行管理

28

を提供する。このディレクトリの値は、 ${GLOBUS_USER_HOME}の値を含んでいてもよく、この代入値で置きかえられる。

• GLOBUS_LOCATION: Globus Tookitのインストール・ディレクトリ。

私たちは、下のジョブ定義を、ジョブのステージングだけではなく、ジョブ定義言語の機能について

より広範囲に説明するために使用する。 GRAMサービスへのジョブの投入は、以下のようなアクションのシーケンスを引き起こす。

• /bin/echo 実行ファイルは、ジョブを投入したマシンから、GRAM サーバー・ホストのファイルシステムに転送される。あて先のロケーションは、GRAMサービスによって実行されるジョブの実行ユーザーのHOMEディレクトリである (<fileStageIn>参照)。

• 転送された実行ファイルは、標準出力にテスト文字列を出力するために使用される。標準出力は、ローカルファイルにリダイレクトされる (<stdout>参照)。

• 標準出力ファイルは、ジョブ投入マシンに転送される (<fileStageOut>参照)。

• ステージ・インのフェーズ中に最初に転送されたファイルは、GRAMがインストールされているシステムのファイルシステムから削除される。

<job> <executable>my_echo</executable> <directory>${GLOBUS_USER_HOME}</directory> <argument>Hello world!</argument> <stdout>${GLOBUS_USER_HOME}/stdout</stdout> <stderr>${GLOBUS_USER_HOME}/stderr</stderr> <fileStageIn> <transfer> <sourceUrl>gsiftp://submit.host:2888/bin/echo</sourceUrl> <destinationUrl>file:///${GLOBUS_USER_HOME}/my_echo</destinationUrl> </transfer> </fileStageIn> <fileStageOut> <transfer> <sourceUrl>file://${GLOBUS_USER_HOME}/stdout</sourceUrl> <destinationUrl>gsiftp://submit.host:2888/tmp/stdout</destinationUrl> </transfer> </fileStageOut> <fileCleanUp> <deletion> <file>file://${GLOBUS_USER_HOME}/my_echo</file> </deletion> </fileCleanUp> </job>

行番号を参照したより詳細な解説を以下に示す: 2. 実行ファイルは、/bin/echo である 3.作業ディレクトリは、$GLOBUS_USER_HOME 変数により特定される。 4.1つの引数として、文字列 "Hello World!" が与えられる。 5.標準出力は、${GLOBUS_USER_HOME}/stdout ファイルに記述される。 6.標準エラー出力は、$｛GLOBUS_USER_HOME}/stderr ファイルに記述される。 7-12.1つのファイル、すなわち実行ファイルがステージ・インされる。 13-18. 1つのファイル、すなわち標準出力がステージ・アウトされる。 20. 実行ファイルは、実行が終了した時に削除されるべきである。

証明書の委譲

GRAMサーバーへ投入されたジョブが、(a) GRAMを利用したジョブ投入や他のWebサービスの呼び出しのような追加のリモート操作を行う場合、(b) ステージング証明書を要求するステージング操作に従事する場合、委譲されたユーザー証明書を要求する可能性がある。 GT4は、証明書が二つの異なった方法で供給されることを認めている。第一の手法では、ユーザーは、要求された証明書をジョブ投

入要求と共に渡す。第二の、潜在的により効率的な手法は、ユーザーが、GRAMサーバーに関連付けられているDelegation サービスに証明書をアップロードしておく方法である。そうすることで、それ


実行管理

29

らの証明書は、その後に続くジョブ要求により直接的にアクセスされることが可能である。

GT4のジョブ定義ファイルとコマンドライン・ツールは、以下のような二つの使用方法をサポートしている

• クライアントは、1つもしくは両方の証明書を委譲するために、 globus-credential-delegate コマンドライン・クライアント・プログラムを、 GRAMサーバに対して使うことができる。

• このように証明書を委譲させていると、クライアントはジョブ定義の中でこのようなEPRを提供することによって、それらの証明書がその後のリクエストで使用されるであろうことを、jobCredential、stagingCredential、transferCredential といった要素を通して知らせることができる表4.4。

• もしくはその代わりに、-job-delegate と -stageing-delegate のフラグを globusrun-ws に設定して使い、証明書がある単一のジョブのために転送されるよう要求するという選択肢も、クライアントは常に選べる。

以下が、三番目の項目で言われているフラグについての説明である。

• -job-delegate: このオプションが設定されていて、かつ、ジョブ定義ファイル上でjobCredential 要素が設定されていない場合、globusrun-wsコマンドは GRAMに対して、クライアント証明書を委譲し、投入されたジョブ定義に対応した要素を伝える。

• -staging-delegate: このオプションが設定されていてかつ、ジョブ定義にステージングやクリーンアップ宣言が含まれておりかつ、ジョブ定義が必要とされる stagingCredential や transferCredential 要素を含んでいない場合、 globusrun-ws コマンドはクライアント証明書をGRAM (と、そしてRFT) に委譲し、投入されたジョブ定義に対応する要素を伝える。

globusrun-ws の主要なオプションとその他の詳細

??? に主要な globusrun-ws のオプションをリストする。 -sbumit -stream フラグは、インタラクティブ・ストリーミング・モード (-stream) を要求する。それは、状態の更新だけではなく、リモート・プログラムによって出力された標準出力を、 globusrun-ws クライアントに追加的に返すために必要とされる。

表 4.3. 主要なglobusrun-wsコマンドのオプション

オプション説明

-submit インタラクティブ・モードでジョブを投入する。つまり、globusrun-ws コマンドは、ジョブが終わったか失敗したときのみプロンプトが返り、ステータスの変更はクライアントに戻され、globusrun-ws コマンドを kill するとジョブもkillされる。

-submit -stream ジョブをインタラクティブ・ストリーミング・モードで投入する。これは、クライアントが、ジョブの標準出力をglobusrun-wsの呼び出しの標準出力と同様に扱うことができる点を除いて、インタラクティブ・モードと同様である。

-submit -batch ジョブをバッチ・モードで投入する。これは、ジョブ投入において、globusrun-wsコマンドが即座にプロンプトを返すことを意味する。

-monitor EPR 実行中のジョブに接続する。globusrn-ws -submit -batch コマンドをglobusrun-ws -monitorコマンドと組みあせて使用することは、インタラクティブ・モードでの投入、すなわち、単に globusrun-ws -submit コマンドで投入するのと同等である。


実行管理

30

オプション説明

-status EPR 指定されたEPRで参照されるジョブの、現在の状態を返す。

-kill EPR 指定されたEPRで参照されるジョブを停止する。

-validate 他の引数のついたglobusrun-ws 呼び出しの有効性を検査する。

-version globusrun-ws コマンドの実装のバージョン番号を返す。

-help 詳細なヘルプ情報を返す。

-usage 様々なコマンドオプションの使用方法情報を返す。

タイムアウト値を更新する。コンピューターやネットワークの信頼性が低い場合、リクエストや確認応答が喪失したり遅延したりする可能性がある。したがって、globusrun-ws コマンドは、GRAMサーバーへのリクエストがタイムアウト期間内に返ってこなかった場合、失敗として結果を返す。デフォルトでは、この期間は2分である。クライアントは、-http-timeout 引数を使ってその値を変更することができる。

きっかり1回のジョブ投入という意味づけをした上での、ジョブの再投入。ジョブ投入リクエストがタイムアウトした場合、クライアントは、ジョブが正常に投入されたかどうかを知ることができない。リクエストは成功しているが、確認応答が喪失されているかもしれない。これが、考慮事項となる場

合、クライアントは、ジョブに対して投入識別子を得る (もしくは与える) ことができ、タイムアウトが発生した場合には、同一の識別子を使用してジョブを再投入することができる。そうすると、GRAMは、同じジョブが一度より多くは投入されないようにする。

ライフタイム管理。 GRAMサーバーは、ジョブのライフタイムが期限切れになった後、ジョブを終了する。デフォルトでは、ジョブのライフタイムは、無限である。これはつまり、プログラムが実行を終了するか、クライアントかサーバーが、何らかの理由でジョブを明示的に終了するかした場合のみ、ジョブが終了することを意味する。クライアントは、投入時に -termination オプションを使用して、特定のライフタイムを指定することができる。

並列ジョブ。ユーザーは、globusrun-wsコマンドを使って、デフォルトの1以上のcount 属性を持ったジョブ定義をもつジョブを投入することができる。そのようなジョブ定義は、目標となるコンピューター上で作成される指定された実行ファイルの複数のコピーを要求する。

マルチジョブ。GRAMは、また、"multijob"もサポートする。すなわち、F の N 個のコピーを実行するように要求するのではなく、異なったプログラムを実行するよう要求するようなジョブ定義である:例えばF, G, H のようなプログラムである。 (それらそれぞれのリクエストは、並列ジョブではありえるが、マルチジョブではありえない。) GT4のドキュメンテーションは、この機能の使い方の詳細を提供する。

ジョブとプロセスのランデブー。 GRAMは、マルチプロセスなジョブ内でのプロセス間と、マルチジョブ内でのサブジョブ間で、同期を行うための仕組みを提供している。ジョブとして実行されるアプリケーションは、実際に、バイナリ情報、例えば、プロセス情報やサブジョブ情報を登録できる。ま

た、他の全てのプロセスやサブジョブが、自身の情報を登録し終えたときに、通知を受け取ることができる。例えば、ある並列ジョブが計算を進める前に"防壁"で同期を取る必要があるのに、ネイティブなアプリケーションのAPIがそのような同期をサポートしない場合、これが役立つ。

ジョブ定義言語の詳細

図 X のより複雑な例は、この後で議論するいくつかの追加機能を紹介している。第一に、私たちは、GRAMがサポートするジョブ定義要素のリストを表4.4に示す。3番目の列で"Y" と示されているもの


実行管理

31

は、置換をサポートする。

表 4.4. それらのcardinality (blank=[0..1], *=[0..*])であるジョブ定義要素、それらが置換をサポートするか否か、そしてそれらの定義。

要素名 C S 定義

argument * Y 実行ファイルのためのコマンドラインの引数。引数の中のスペース

やクオートは保護される。

count 実行回数。空欄もしくは、記述されていない場合、デフォルト値 = 1

directory Y ジョブマネージャがジョブ実行のために利用するデフォルトのディ

レクトリーのパス。

dryRun (未実装) "true"であった場合、ジョブマネージャは、ジョブ実行のためにジョブを投入することはせず、結果を成功したとして返す。

environment * Y ジョブマネージャによって設定されるデフォルトに追加する、ジョ

ブ実行のために定義される環境変数。

executable Y リモート・マシン上で実行する実行ファイルの名前

extensions 現在のところ、クライアントが制御しているジョブに対して、関連

付けたいクライアント固有のデータを指定するためだけに使用され

る。

Factory Endpoint このジョブ定義が投入されるべき Managed Job Factory サービスのエンドポイント。

fileCleanUp Y GridFTP互換のファイルサーバーを通して、ジョブの停止に応じて削除されるべき、ジョブに対応するローカルファイル。

fileStageIn Y ジョブ実行前に、ジョブが実行されるノードに転送されるべき

("remote URL" "local file") のペア。

fileStageOut Y ジョブ完了後、ジョブを実行しているノードからGridFTP互換サーバーへステージ・アウトすべき("local file" "remote URL")のペア。

hostCount Linuxクラスターのような、SMPコンピューターのクラスターにのみ適用される。

jobCredential Endpoint 委譲された証明書リソースを指し示すEPR。

jobType ジョブマネージャがジョブをどのように開始すべきか: mpi、single、multiple、condorのうちのいずれか。

libraryPath * Y システム固有のライブラリー・パス環境変数に追加されるパス。

maxCpuTime 単一実行ジョブに対する、最大CPU時間の明示的な設定、分単位。スケジューラーがCPU時間を設定できなかった場合、エラーが返る。


実行管理

32

要素名 C S 定義

maxMemory 単一実行ジョブに対する、最大メモリ量の明示的な設定、メガバイ

ト単位。GRAMスケジューラーがmaxMemory を設定できない場合、エラーが返される。

maxTime 単一実行ジョブの、最大 walltime もしくは CPU時間、分単位。Walltime もしくは、CPU時間が、インタフェースされているGRAMスケジューラーによって、選択される。

maxWallTime 単一実行ジョブの最大walltimeの明示的な設定、分単位。GRAMスケジューラーが、walltimeを設定できない場合、エラーが返る。

minMemory 単一実行ジョブの最小メモリの明示的な設定、メガバイト単位。

GRAMスケジューラーがminMemoryを設定できない場合、エラーが返る。

project 定義された (リモート) 資源の、スケジューラーによって定義されたジョブが配置されるプロジェクト・アカウントを示す。

queue 定義された (リモート)リソースのスケジューラーによって定義されたジョブがキューイングされるキューの名前を示す。

remoteIoUrl 設定された値 (URLベースの文字列 ) をファイルに書き、GLOBUS_REMOTE_IO_URL環境変数を通じ、その環境にそのファイルへのパスを設定する。これが、ジョブ・リスタートRSLに含まれていた場合、ジョブマネージャは、ファイルの中身を更新する。

これは、GASSを通じてファイルアクセスしようとするジョブに対して意図されているが、そのGASSサーバーのURLは、GASSサーバーがリスタートするため、変更されている。

Staging Credential Endpoint An EPR which points to the delegated credential resource used to make remote calls to RFT. RFTに対するリモート呼び出しをするために使用される、委譲された証明書リソースを指し示すEPR。

stderr and stdout Y それぞれのstderrまたはstdout 要素には、ジョブの標準エラー出力、または、標準出力が、それぞれ、保存されるであろうファイル名もしくはURLを指定する。ジョブからの標準エラー出力 (標準出力) は、ジョブ実行後に、指定されたパスもしくはURLに転送される。ローカル・パスの値は、ユーザーのホーム・ディレクトリに対する相

対パスで転送される。絶対パスの値は、"file://"がそのパスを表そうとしてる場合、そのように転送される。

stdin Y リモート・マシン上で、実行ファイルの標準入力として使用される

ファイルの名前。

GRAMクライアントAPI

GRAMサーバーのクライアント・インターフェースは単純である。図4.2で図解されているように、4つの、WS-Resourcesに対するOperationを定義するような、4つのportTypeが定義されている。ここでのWS-Resourcesは、GRAMサーバーの状態、単一ジョブの状態、Deligation Factoryに関連付けられた証明書のチェーン、そして、証明書自身をそれぞれあらわしている。それらのOperationは、WS-Resources


実行管理

33

に対する様々なWSRFや WS-NotificationのOperationと同様に、ジョブ特有の機能と証明書委譲特有の機能 (CreateManagedJob, Release, RequestSecurityToken, Refresh) の両方を含んでいる。

図 4.2. 下から順に、GRAMと関連付けられた四つのWS-Resources (網掛け) 、それらのWS-Resourcesを操作するために使われる四つのインタフェース、そして、それらのインターフェースがサポートするOperation。

より詳細に述べると、ManagedJobFactory の Managed Job Factory portType は、GRAMサーバーの状態に関する情報を扱うために使われるmanaged job factory リソースに対する、 WS-ResourceProperties の検索 Operationをサポートする (表4.5参照) 。また、createManagedJob operation を定義する。createManagedJob operationは、ジョブ定義、ジョブ・リソースの付加的な初期終了時間、そして、付加的な状態通知のサブスクリプション要求を入力として受け取る。このOperationが成功すると、ManagedJob WS-Resource の作成が行われ、新たな ManagedJob の EPR が返される。サブスクリプションが要求された場合、クライアントは、通知を受け取るためにサブスクライブされ、新しいサブスクリプションに対して第二のEPRが返される。 globusrun-ws コマンドライン・クライアントは、適切なジョブ定義を生成する (もしくは進める) 、また、インタラクティブもしくはインタラクティブ・ストリーミング・モードでのジョブ投入の場合に、サブスクリプションを要求する、といったその多くの機能を実装するためにこのOperationを使用している。

Managed Job portType (MJPT)は、ManagedJob WS-Resource に対するOperationを定義している。それは、ジョブ状態についての情報にアクセスするために、WS-ResourceProperties の検索Operationをサポートし(表4.6)、ジョブのライフタイムを管理するためのWS-ResourceLifetime ライフタイム管理Operation、そして、クライアントが、変更の通知を要求できることを可能にするための WS-BaseNotification Operationをサポートしている。それは、また、ジョブ定義のholdStateフィールドを通して、hold状態にされているジョブのholdを、リリースするために使われるrelease operatinも定義している。このOperationは、何の引数もとらず、何の結果も返さない。

ManagedJob WS-Resourceは、1つの実行ファイルかマルチジョブのいずれかを表現してもよい。それぞれの場合で、幾分異なったリソース・プロパティーが定義される。

Delegation Factory portType は、 Delegation Factory に関連付けられた証明書のチェーンについての情報を保守するために使われる Delegation Factory リソースに対する WS-ResourceProperties の検索 Operationをサポートする。

Delegation portType は、セキュリティ・トークンの WS-Resource について、 WS-ResourceLifetime の operation をサポートする。また、レフレッシュの operation を定義し、クライアントはそれを、新しい証明書をアップロードするために使うことができる。

表 4.5. Managed Job Factory リソース・プロパティ

リソース・プロパティ説明


実行管理

34


localResourceManager ローカルリソースマネージャのタイプ。Condor, Fork, LSF, Multi, PBSなど

globusLocation Globus Toolkitのサービスの実行ディレクトリであるるGlobus Toolkitのインストールディレクトリ。

hostCPUType ジョブ実行ホストのCPUアーキテクチャ (i686、x86_64、など)

hostManufacturer ホストの製造元の名前。おそらく"unknown"であろう。

hostOSName ホストのOSの名前 (Linux, Solaris, など)

hostOSVersion ホストのOSのバージョン

scratchBaseDirectory 一時的なジョブデータに使用されるために、システム管理者

が推奨するディレクトリ。

delegationFactoryEndpoint ジョブに対して証明書を委譲するために使われる、Delegation Factoryへのエンドポイントリファレンス。

stagingDelegationFactoryEndpoint ステージングのサービス (RFT) に対して、証明書を委譲するために使用される、Delegation Factory へのエンドポイントリファレンス。

condorArchitecture Condorのアーキテクチャーのラベル。 (Condorスケジューラーの場合)

condorOS Condor のOSラベル (Condorスケジュラーの場合)

GLUECE GLUEデータ (GLUEスキーマのフォーマットで記述されたデータ[18])

GLUECESummary GLUEデータの要約。

表 4.6. Managed Job のリソース・プロパティと、それらの追加の Managed Executable Job と Managed Multi Job リソースに関連付けられたリソース・プロパティ


serviceLevelAgreement single-job や multi-job の定義、もしくは RSLを含むラッパー・フィールド。 1つのサブ・フィールドのみ、非null値を持てる。

state ジョブの現在の状態。

fault fault (が起きた場合) は、ジョブが完了しなかった理由を表示する。

localUserId ジョブのオーナーの、ローカルでのユーザー・アカウント名。


実行管理

35


userSubject ジョブのオーナーの、GSI証明書のDN。

holding ジョブがhold状態にされているか否かをあらわす。

Managed Executable Job Resource only

stdoutURL 標準出力が含まれているジョブが生成したファイルに対する、

GridFTPのURL。

stderrURL 標準エラー出力が含まれているジョブが生成したファイルに対す

る、GridFTPのURL。

credentialPath 他のサービスに対して認証を行うためのジョブによって使用され

る、ユーザーのプロキシー証明書が含まれているファイルに対す

るパス (ジョブプロセスに対して相対的) 。

exitCode ジョブ・プロセスによって生成された終了コード。

Managed Multi Job Resourceのみ

subJobEndpoint マルチジョブによって作成されたサブジョブに対するエンドポイ

ントリファレンスのセット。

GRAMの設定と管理

私たちは、計算リソースに対するWeb サービス・アクセスを可能にするために、GRAMサーバーをインストールした。インストール作業は、二つの主な設定手順を含んでいる。いずれの場合でもデフォルトが定義されている。

• ローカルのスケジューラー・インターフェース。GRAMは、ジョブの開始と制御に関して、ローカルのしくみに依存する。forkベースのGRAMモードが使用される場合、特別なソフトウエアは必要とされない。CondorやSGE,PBS,そして、LSFのようなバッチ・スケジューリングの仕組みに関しては、ローカルスケジューラーが、GRAMを配備し操作するより前に、ローカルジョブ投入が可能なようにインストールされ構成されていなければならない。

• ユーザーマッピングに対する認証。GRAMは特定の要求が許されるべきか、権限付けされた要求がどのユーザー権限で実行されるべきかについて決定するAuthorization calloutに依存する。

"/O=Grid/OU=GlobusTest/OU=simpleCA-foo.bar.com/OU=bar.com/CN=John" john

GRAMはまた、認可とマッピング情報を得るために、他のソースにアクセスするように構成できる。XX章を参照のこと。

関連するソフトウエアとツール

Table XX …

DAGman, Condor-G, and GriPhyN Virtual Data System

実行するジョブがたくさんある。

それら全てを管理し、必然的に発生する失敗を管理する事は困難なことである。何が実行されている


実行管理

36

か、どこに出力されるか?

Condor-G

Nimrod-G: グリッド環境でのパラメーター研究を管理する

A particularly simple class of parallel...

XX.

MPICH-G2: グリッド環境でのメッセージ・パッシング

XX.

Ninf-G: グリッド環境でのリモート・プロシージャー・コール。

XX.

ケーススタディ

How many? What? Here or attached to earlier sections?

Execution Management Case Study 1

XX.

実行管理のケーススタディその2

XX.

GRAMの動き

私たちは、GRAMの実装について簡単に再検討する。この情報は、GRAMの設定(4.5節) の議論のバックグラウンドとして、また、GRAMがどのように機能しているのか知りたいユーザーや、WSRF/WSNベースのサービスの例としてしりたい開発者にとって有益であるべきだ。

図 4.3. GRAMの実装の構造


実行管理

37

図4.3で図解されているように、GRAMの配置の主要な部分は以下のとおりである

• GT4のコンテナ内で実行されている、一連のサービスは以下のとおりである。

• ジョブの作成、監視、管理のためのGRAM限定のサービス

• 証明書の委譲の管理に使用される、汎用的な目的のDelegation サービス。

• データ・ステージング操作を管理するために使用される、汎用的な目的のReliable File Transfer (RFT)サービス。

• GRAMへの要求を適切なローカル・スケジューラーへのリクエストにマップするために使用される、スケジューラー固有のGRAMアダプター。

• データ・ステージングのコマンドを実行するために使用される、GridFTPサーバー。

このサービス間の全体的効果に対するクライアントからの概観は、まさしく、GRAMとDelegationサービスによって定義されるインターフェースである。 4.3節で論じられたように、それらのインターフェースは、ユーザーがジョブを投入したり、監視したり、管理したりできるようにし、また、委譲された証明書をインストールし、更新できるようにする。

WS-Resource の利用の仕組み

GT4のJavaコンテナの中のWebサービスは、ジョブ ("ManagedJobs") に関連付けられた状態、委譲された証明書、進行中の転送を表すために、WS-Resouce を使用する。この表現方法によって、状態へアクセス、ライフタイムの管理、通知の実行を、 WSRFやWS-Notificationの仕組みを使って実現できるようになる。このように、既に存在している機構を再利用し、汎用的な目的に使える Delegation サービスやRFTサービスを利用することは、相対的に、GRAMの実装においてGRAM独自のコードを開発しなければならない部分が少なくなるということを意味する。

それぞれの投入されたジョブに関連付けられた状態は、単に、その現在の状態を表すために使用され

るWS-Resourceである。ジョブの引数のサイズにもよるが、数千バイトくらいのものであろう。これゆえに、GRAMは基本的に、非常に多くのジョブ投入に対応することができる。実際は、現在のJavaのホスティング環境の機能では、スケーラビリティに限界がある: 12.3節を参照。

セキュリティーの課題

入ってくるジョブの管理リクエストは、複数のレベルでのセキュリティーのチェックを必要とする。

1. WS-Security の仕組みは、リクエストと関連付けされた証明書の有効性を証明し、リクエスト元を立証するために使用される。

2. 認可は、authorization callout を介して実行される。構成に依存するが、このcalloutは、gridmap、SAMLサーバー、もしくはそのほかの仕組みに問い合わせを行うであろう。

3. 認可が成功した場合、その権限の元でジョブが実行されるべき、ローカルのユーザーIDももたらす。 Unixユーティリティーのsudoが使用されて、このユーザーIDの元でのローカルのリソース管理の仕組みが呼び出される。このようにして、サイト認可機構のアプリケーションが可能になる。

GRAMは、サービスの故障や障害のリスクが最小限になるよう、必要となる権限が最小限になるよう、デザインされてきた。GT4のJavaコンテナ上で動作しているサービスは、それらのopertaionを実行するための特別な権限を必要としない。特権を必要とするオペレーションは、専ら sudo 機能を介して実行される。

ユーザーをお互いから守るために、異なったユーザーによって投入されたジョブは、通常、分離され

たローカルのセキュリティー・コンテキストの中で実行される。例えば、ジョブ要求と認可のポリシ


実行管理

38

ーの詳細に基づいた、特定の Unix のユーザーIDの元で実行されたりする。 (このようなセキュリティー・コンテキストをオンデマンドに生成するために、動的カウント管理の仕組みが使用されること

がある: 4.9節参照。)

悪用や不具合のリスクを軽減させるためだけでなく、通常のアカウント機能を補完するために、 GRAMは、オーディットとロギングの広範な手法を使って、ジョブ投入やクリティカルなシステム操作の記録をとる。

データ操作

GRAMサービスは、GRAMと関連付けられたRFTサービスに、データ・ステージングの操作を受け渡す。この戦略によって、汎用的な目的のRFTのコードを再利用できるようになる。またこれは、ステージングを必要しないジョブの投入ならば、データ管理のコストが全くかからないで済むことを意味する。データ・ステージング要求を受け取って初めて、RFTサービスは、指定された送信元と送信先の間でGridFTPの転送を開始する。

従来のデータ・ステージング操作に加えて、GRAMはジョブ実行中の計算リソースからの出力ファイルの中身を、インクリメンタルに転送するための仕組みをサポートする。(GridFTPに組み込まれている) この仕組みによって、任意の数のファイルをこのように転送できるようになる。

実行管理の将来

XX


XX


39

第5章データ管理

データ管理ツールは、分散されたデータの場所、転送、管理に関係している。GT4は、高速で信頼性の高いデータ転送のための GridFTP、複製されたファイルの場所情報を管理するためのRLS、統合された構造化・半構造化データへのアクセスのための OGSA-DAIを含む、様々な基本的なツールを提供する。

ストレージの予約を制御する（NeST）、GridFTPに対するコマンドラインクライアントを提供する（UberFTP)、分散データへの統一したインターフェースを提供する（SRB）、そして、分散データのプロセッシングパイプラインをサポートする（DataCutter, STORM) ことにより、関連ツールがGT4のコンポーネントを拡張する。

その他の興味深いシステムとして、管理対象のストレージに対するGSI認証を使ったGridFTPアクセスを提供するような LBNL Storage Resource Manager (SRM）や、U.Michiganで開発されているGSI認証対応したNFSv4の実装であるGrifNFSが含まれる。

詳しくは GriPhyN VDS (Execution)を参照。

表 5.1. Globusと関連するデータ管理ツール

名称目的 M G

GridFTPサーバー GSI認証と高速なスループットをサポートする拡張されたFTPサーバー。UNIX のPOSIX、HPSS、GFPS、そして、Unitreeへのインターフェースが提供される。その他のものに対しても、開発可能である。

3 I 5.1

globus-url-copy GridFTPの非対話的なコマンドラインクライアント。

3 I

Replica Location Service RLSは、複製されたファイルについての情報を登録し、発見するための分散されたサービスである。

3 I

Reliable File Transfer service RFTは、GridFTPを使用した第三者転送や、複数ファイル転送

を制御し、監視する。障害時の指数的バックオフ、一連の複数ファイルの全か無かという転送、並列ストリームやTCPバッファーサイズ・チューニングの任意の利用、そして、再帰的なディレクトリ転送を特徴とする。

1 I

Lightweight Data Replicator LDRは、一連のサイトの集合へデータを複製するためのツール

である。GridFTP、RLS、そして、pyGlobusを基に構築されている。

1 P

OGSA Data Access & Integration OGSA-DAIは、RDBやXML DB、そして、半構造化されたファイ

ルを含む、データ・リソースへのアクセスやそれらの統合を行うための拡張可能なフレームワークである。

2 P

Network Storage [4] NeSTによって、GridFTPクライアントは、ディスク・スペースの予約を交渉することができ、連続した転送のためにそれを利

用できるようになる。

1 Y

UberFTP [27] GridFTPの対話的なコマンドライン・クライアント。

3 Y


データ管理

40

名称目的 M G

Storage Resource Broker [12, 13] 異機種分散データ資源に接続するための、統合されたインター

フェースを提供するクライアント・サーバー型のミドルウエ

ア。 GSI認証とGridFTP転送。

3 ?

DataCutter & STORM DataCutterは、アプリケーション特有の実行モジュールの、分散されたパイプラインを実行することで、大きなデータセット

の処理をサポートする。

2 Y ?

GridFTP

XX.

Reliable File Transferサービス

XX.

Replica Location サービス

Globus Toolkitが提供するレプリカのロケーション・サービス機能(RLS)

RLSは現在のところWebサービスのインターフェースをサポートしない。

XX

データのアクセスと統合

XX.

関連するソフトウェアとツール

XX.


XX.

データのケーススタディ1

XX

データのケーススタディ2

XX

各機能の動き

XX.



データ管理

41

「The Data Grid: Towards an Architecture for the Distributed Management and Analysis of Large Scientific Data Sets」 [26]という記事は、データ管理に関連する論題についての、やや古い入門である。

「Data Access, Integration, and Management」[37] という本の章は、ここで議論された論題についての包括的な紹介を提供している。


42

第6章監視と発見

見直しのない人生は生きる価値なし

—Socrates

監視・発見のメカニズムはサービスとリソースの設定及びステート情報を取得、配布、インデックス、

アーカイブ、処理することと関連する。場合によっては、この情報収集の目的はサービスかリソースの発見を可能にすることである。別の場合では、それはシステム状態の監視を可能にすることである。

GT4のJava、C、およびPython言語のWS CoreコンポーネントによるWSRFとWS-Notificationインタフェースのサポートは、監視と発見機能に有用なビルディング・ブロックを提供し、監視と発見に必要なプロパティの定義を可能にする上に、PullとPush モードのアクセスを可能にする。GRAMやRFTなどのGT4サービスは適切なリソースのプロパティを定義し、サービス発見と監視の基礎を提供する。他のGT4サービスはインデックス(MDS-Index)、アーカイブ (MDS-Archive)、および重要なイベントのためのデータ分析 (MDS-Trigger) に備えて、発見と監視を可能にするように設計されている。すべてのGT4コンテナがコンテナの中にサービスの発見のための内蔵のMDS-Indexサービスを取り入れている; これらのMDS-Indexサービスは、Grid全体のインデックスの構築にリンクすることができる。

関連ツールとしては、個々のエンティティを監視するものや(例えば、クラスタ監視用のGangliaとHawkeye、個々のコンポーネント監視用のNetLogger)、複数のロケーションでのテストの実施を調整するもの(Inca、Nagios)が含まれる。

参照: WebMDS (Interface)

表 6.1. Globus及び関連の監視、発見ツール

名称目的 M G

Java、CとPythonのWS Core WSRFとWS-Notification仕様を実装し、Webサービスが

リソース・プロパティの定義ができ、さらにこのプロパティにアクセスできるようになる。コンテナはローカル・インデックスを取り入れることによって、サービスの発見ができるようになる。

3 T

MDS-Index サービスからライブ監視情報を収集し、その情報に対してクエリーができるようにする。

2 T

MDS-Trigger (収集した) ライブ監視情報とルールとを比較して、障害状態を検知し、オペレータに通知する。 (例えばメールで)

2 T

MDS-Archive 監視データの履歴を保管し、そのデータに対してクエリーを可能にする。

2 T

Aggregator framework aggregator frameworkは収集サービスの構築を容易に

する。

2 T

Hawkeye Condorをベースとして使用し、個々のクラスタを監視する。GT4はGLUEスキーマ形式のステータス情報を提供するデータ・プロバイダーを含んでいる。

3 Y


監視と発見

43

名称目的 M G

Ganglia [24,43] 個々のクラスタ及びセットのクラスタを監視する。

GT4はGLUEスキーマ形式のステータス情報を提供するデータ・プロバイダーを含んでいる。

3 Y

Nagios [2] 分散システムにおけるネットワーク、コンピュータ

ー、およびサービスの監視に広く使用されたオープン

ソース・システム。

3 Y

Inca [7] 指定された間隔で一連の指定されたテストを実行す

ることによって、分散システムにおけるサービスを監

視する; また、これらのテストの結果を公開する。

2 N

NetLogger 分散システム・コンポーネントからの高頻度なデータ

を生成、収集、分析する。

3 N

MDS4

GT4の監視・発見システム (MDS4) のコンポーネントによって、分散システムにおけるサービスとリソースの監視と発見タスクを簡素化することができる。

監視とは、問題を解決する、あるいは使用をトラッキングするといった目的のために、リソースやサ

ービス(例えば、コンピュータとスケジューラ)を観測するプロセスである。ユーザーは修正アクションを取るために、ディスク・スペースが不足しているリソースを特定するのに、監視システムを使用するかもしれない。

発見とはあるタスクを成し遂げるために適切なリソースを見つけるプロセスである。例えば、ジョブを走らせる計算ホストを見つけるといったことである。このプロセスには、どのリソースが適切であるか(例えば、正しいCPUアーキテクチャー) 、そして、そのリソースのセットから適切なメンバーを選ぶ(例えば、最も短いサブミッション・キューを持つもの) 作業が含まれるかもしれない。

監視と発見のアプリケーションの両方が、複数の、そして、恐らくは分散した情報ソースから情報を

収集できる能力を必要とする。このニーズを満たすために、MDS4は登録された情報ソースから最近の状態情報を収集する、いわゆる収集サービス (aggregator services) を提供する; そして、ブラウザ・ベースのインタフェース、コマンドライン・ツール、およびユーザーからの収集した情報へのク

エリーとアクセスを可能にする、Webサービス・インタフェースを提供する。

MDS4は異なったインタフェースと振舞いを備える、3つの異なった収集サービス(共通フレームワーク上で構築されているが) を提供する: MDS-Index は情報ソースから収集した最新の値への XPath クエリーをサポートする; MDS-Triggerは収集した情報とユーザーが決めた評価基準にマッチする時に、ユーザーに指定されたアクション(メールを送るか、またはログファイルエントリーを生成するなど)を実行する; そして、MDS-Archiverは情報ソースからの情報を永続的なデータベースに格納し、ユーザーの過去情報へのクエリーを可能にする。

MDS4は、情報ソースの登録や興味がある情報の場所を見つけてアクセスするタスクを簡素化するために、XMLとWebサービスのインタフェースを大量に利用する。特に、収集サービスに集められたすべての情報をXML形式で管理し、XPathクエリー経由でクエリーすることができる(他のWebサービスのメカニズムと同様に)。

収集者と情報ソース

MDS4を理解する鍵は、収集者-情報ソースのフレームワークである。基本的なアイディアは以下の通り:


監視と発見

44

• 発見され、またはアクセスされることが必要とされる情報ソースは、明示的に収集サービスに登録される。

• 登録には期限がある : 定期的に更新されなければ、失効する(このため、収集サービスはself-cleaningである: 古くなったエントリは、登録の更新が中止された時点で自動的に消滅する)。

• 収集サービスは、情報源によって指定されたアクセスのメカニズムを用いて、最新の状態や、状態に関する情報を全ての情報源から定期的に集める。

• 収集サービスは、登録済みの情報源から得られた情報を、特有のWebサービスインターフェースを経由して、入手可能とする。

MDS4の収集サービスは、情報ソースのsoftstateな登録と、保持する情報源ソースの値の定期的なリフレッシュという点で、UDDIなどの伝統的な静的レジストリとは異なるものである。この動的な振る舞いによって、ユーザーは情報ソースに直接アクセスすることなく「最新の」情報にアクセスすること

ができ、スケーラブルな発見が可能となっている。

情報ソースと登録

情報ソースは、本質的には収集サービスが情報を取得できるどんなエンティティでも良い: 例えば、ファイル、プログラム、Web サービス、あるいは他のネットワークが有効化されたサービスである。

上記で示した通り、情報ソースは、そのデータ値へのアクセスを提供しようとしている何かの収集サ

ービスに定期的に登録されなければならない。登録作業は、Web サービス(WSServiceGroup)の Add operationを通じて行われる。2つの登録モードがサポートされている; それぞれが、関連する情報ソースへのアクセスに使われるメカニズムも定義している。

より一般的な登録モードは、任意の情報ソースからの情報取得を可能にする。このモードでは、情報

ソースはユーザーによって提供され、最新のデータを取得するために定期的に実行されるプログラム

を供給することによって登録される。このユーザープログラムは、情報をローカルに作成しても、ソ

ースに特有なプロトコルを用いてリモートの情報にアクセスしても良い。プログラムは、非XMLのデータを、適切なXML表現に変換しなければならない。

より能率の良い登録の形態が、WSRF-compliantなWebサービスに対してサポートされている。そのようなサービスは、単にステータスとステート情報をWSRFのresource propertiesとして利用可能なようにすれば良い。登録時にユーザーは、収集サービスがWSRFの"get resource property"インターフェースを用いてリソース・プロパティをpullするのか、あるいはリソース・プロパティの変更にサブスクライブして、値がWS-Notificationのsubscriptionメソッドを用いてpushされるようにするか、いずれかを指定する。

収集サービスの3形態

MDS-Indexサービスは、情報ソースから集められたデータをXMLドキュメントとして利用可能にする。より明確には、データはWSRFのリソース・プロパティとして保持される。このため:

• ユーザーは、標準的なWebサービス・インターフェース、すなわち、GT4 がC、Java、及びPythonのAPIを提供しているWSRF の get-property および WS-Notification の subscribe オペレーションを用いて情報を集めるような、独自のアプリケーションを書くことができる。

• wsrf-get-property コマンドラインツールは、XPathの表現法を用いて目的とするリソース・プロパティを指定し、取り出すために使用できる。

• WebMDSと呼ばれるツールは、MDS-Index の情報を標準的なWebブラウザーで表示させる。WebMDS は、XLST変換を用いてMDS-Index のリソース・プロパティをどのようにHTMLに変換するかを記述することによって、高度に設定可能である。GT4に含まれる標準的な変換では、オーバービュー情報が、個々の監視されているリソースの詳しい情報に下がって見ることができるハイ


監視と発見

45

パーリンクとともに、表示される。

MDS-Triggerサービスは、クライアントが、XPathクエリーと、新しい値がユーザー提供のマッチング規則に適合した場合に実行されるプログラムを登録できるWebサービスのインターフェースを定義する

MDS-Archiveサービスは、情報ソースから受け取った全ての値を永続的なストレージに保管する。クライアントのリクエストは、データの値が必要となる期間を指定可能である。

組み込みの情報ソースとMDS-Indexサービス

全てのGT4 Webサービス・コンテナは、デフォルトのMDS-Index サービスを含んでおり、そのコンテナで動作するすべてのGT4サービス(例: GRAM, CAS, RFT)は自動的に登録されている。このため、あるプラットフォーム上にインストールするとどのような場合でも、どのようなサービスが利用可能か

発見できるインデックスを保持している。

加えて、グリッドはしばしば、全ての利用可能なWS-Resourcesを追跡する必要がある。この一般的なケースに適応するため、GT4は、1つまたは複数のデフォルト・インデックスをグリッド全体のMDS-Indexに指定し、デフォルトのMDS-Indexに登録された各WS-Resourceは、グリッドのMDS-Indexにも登録されるようにする簡単な方法も提供する。

GT4はそれ自体、GT4サービスの発見と監視のためにMDS4のメカニズムを用いて、良い結果が得られるように構成されている。GT4の全てのWeb サービスは、最低限のリソース・プロパティのセット (非公式のサービス名と、サービスの開始時時間) をサポートするので、監視と発見のために、1つ以上の収集サービスに簡単に登録できる。さらに、2つのGT4 Webサービス、GRAMとRFT は、サービスに特有な情報の大きなセットをpublishする (論点となるサービスのドキュメントに書かれている通り)。最後に、GT4のディストリビューションは、GridFTPとRLSの収集サービスへの登録を可能とする情報ソース実行ファイルも含んでいる。

MDS4とMDS2の比較

MDS4は、以前のバージョンのMDS(MDS2とMDS3)に似た機能を持つが、相互運用可能ではない。重要な差としては、より強力なクエリー言語(LDAPの代わりにXpath); シンプルで、それゆえロバストな実装(より少ないコンポーネントによる); より少ないコンポーネントと、GT4 実装とのタイトな統合による、よりシンプルな)設定(実際、単純なケースでは、完全に自動化される; 拡張可能なアーキテクチャがもたらす、任意の情報ソースに対する便利なインターフェース; 情報ソースに予め設定されたスキーマを要求しないこと; 及び、XMLプロトコルを用いることによるパフォーマンスの低下が含まれる。

関連するソフトウェアとツール


Earth System Grid Monitor

例 2

各機能の動き


「Grid Information Services for Distributed Resource Sharing」[72]は、やや古くなっているがそれでもな


監視と発見

46

お、MDS4に適用されたアーキテクチャの鍵となるコンセプトに対して、良いイントロダクションを提供しています。

「A Performance Study of Monitoring and Information Services for Distributed Systems」 [39]では、グリッドの情報サービスで発生する重要なパフォーマンスの問題を紹介されており、キャッシングなどの技

術の影響の見積が示されています。


47

第7章セキュリティー

セキュリティー・ツールは、ユーザーやサービスの識別の確立(認証)、相互コミュニケーションの保護、何のアクションの実行を誰が許可されたか決定すること (認可)を実現し、同様にユーザーのクレデンシャルの管理やグループのメンバーシップ情報の保守機能を提供している。

GT4 は全く異なった WS-* 仕様と WS-* 以前の仕様の認証機能を提供する。どちらも X.509 標準のエンドエンティティ証明書とプロキシー証明書で構成され、ユーザーやサーバーのような永続的なエンティティの識別に使用され、個々に他のエンティティへの暫定的な権限委譲を提供する。

GT4のWS-Security[78]は、(a)メッセージ・レベルのセキュリティーのメカニズム、すなわちWS-Security標準とWS-SecureConversation仕様による GT4のSOAPメッセージの保護を実装し、(b)トランス・ポートレベルのセキュリティーのメカニズム、すなわちTLS(Transport-level Security)、 (c)認可フレームワークとして多様な認可スキームを提供し、これらには"grid-mapfile"アクセス制御リスト、サービスにより定義されたアクセス制御リスト、カスタム認可ヘッダー、SAMLプロトコル経由の認可サービスへのアクセス、が含まれる。 WSに準拠しないコンポーネントに対してもGT4は、認可のための機能オプションが少ないが、同様の認証、権限委譲、認可のメカニズムを提供する。

関連した様々なセキュリティー・ツールが提供するものには、X.509証明書のクレデンシャルのストレージ機能(MyProxy[3]と委譲サービス)、 GSIと他の認証メカニズム(例えば、Kerberosを使用したKX509やPKINIT, ワンタイム・パスワードを使用したMyProxy)とのマッピング機能、認可に使用される情報の保守機能 (VOMS, GUMS, PERMIS [68]) がある。同様に将来的に興味深い取り組みがUKとUSで実施されおり、Gridセキュリティーとシボリス(Shibboleth [36, 42]) が統合され、これにより大学間のディレクトリーへのアクセスが可能となる予定である。

PURSe (インターフェース)も参照のこと。

表 7.1. Globusと関連するセキュリティー・ツール

Name Purpose M GMessage-Level Security WS-Security標準とWS-SecureConversation仕様を実装し、SOAPメッセージにメ

ッセージ保護を提供する

3 T

Authorization Framework ファイル及びサービスベースのアクセス・コントロール・リスト、カスタム・

ハンドル、SAMLプロトコルを含む豊富な認可の体系を可能とする

3 T

Pre-WS A&A 非Webサービスコンポーネントのための認証、委譲、認可

3 T

Delegation Service プロキシー証明書の保管、及びその後の（認可された）プロキシー証明書の復

元、それによってWSプロトコルを用いて委譲を可能とする

T

Community Authorization Service

ユーザーに、リソースに対する細かいアクセス権を認めるアサーションを発行

する。サーバーはアサーションを認識し、強制する。CASは現在、GridFTPサーバーでサポートされている

2 T

Simple CA X509証明書を発行するための、単純化された認証局

3 T

MyProxy [76] service

SASL/PAMを通して、X509と他の認証メカニズム（ユーザー名/パスワード、ワンタイムパスワードなど）

3 T

GSI-OpenSSH GSI認証をサポートするOpenSSHのバージョン。リモート端末(SSH)、ファイルコピー(SCP)、及びFTP(SFTP)機能

3 C


セキュリティー

48

Name Purpose M GVOMS ユーザーのロールとケイパビリティのデータベース、及びVOMS対応のサービ

スに提示するためのアトリビュート証明書の取り出しを支援するクライアン

ト・インターフェース

2 Y

VOX & VOMRS

VOMSを拡張し、PURSeのような、Web登録機能を提供 2 Y

PERMIS [68] SAMLプロトコルでアクセス可能な認可サービス 2 Y

GUMS グリッド・ユーザー・マネジメント・システム、グリッドマップファイルの代

わり

KX509 & KCA KX509は、プロキシー証明書を作成して保管する「ケルベロス化された」クライアントであり、ケルベロス経由で認証されたユーザーがグリッドにアクセス

できるようになる。KCAは、ケルベロス化された認証局で、KX509をサポートするために使用される

3

PKINIT グリッドの証明書を所有するユーザーの、ケルベロスドメインへの認証を可能

とするサービス

3

Shibboleth [36] XXX

セキュリティー原則

XX.

サポートするインフラストラチャー

grid-proxy-init, etc. XX.

Webサービスにおける認証と認可

XX.

Community Authorization Service

XX.

委譲サービス

XX.

認可フレームワーク

XX.

メッセージ・レベル、トランスポート・レベルのセキュリティー

XX.

クレデンシャル・サービス

GT4はクレデンシャル管理に関して2つのコンポーネントを提供している。 MyProxyはオンラインのクレデンシャルのレポジトリーを提供し、SimpleCAはクレデンシャル生成のパッケージを提供する。 (SimpleCAはサービスではないが、クレデンシャルを生成するために導入し、実行するプログラムである)



49

MyProxy

MyProxyはオンラインのクレデンシャルのレポジトリー機能である。ぴんと来ないかも知れないが、そのコンセプト(そして実践例)は明快である。サービスであり、 X.509プロキシー証明書を格納し、パスフェーズで保護され、後で他のネットワークから取り出すことができる。MyProxyのリポジトリーにより、マシン間で秘密鍵とその証明書のコピーする際の手作業を排除する。MyProxyに格納されたクレデンシャルは、ユーザーが持つクレデンシャルがアクセスできない場合にも、アクセスすることができる。例えば、ユーザーがWebブラウザーからGrid Portalに認証要求を実施した際、もしくはジョブマネージャーがユーザーのクレデンシャルを更新したい際に、ユーザーが利用可能な状態でない場合でも可能である。

MyProxyは現在、Webサービスのインタフェースを (最終的には提供するかもしれないが) 提供していない。

XX.

New developments: OTP support.

SimpleCA

SimpleCAパッケージは単純な (証明書) 認証局を提供し、The Globus Toolkitのユーザーやサービスに対するクレデンシャルの発行のために導入して使用することができる。このパッケージはユーザーが公開鍵クレデンシャルを必要とする際、例えばGT操作のテストを実施する際に、適切な認証局にアクセス出来ない場合に利用することを想定している。

GSI-OpenSSH

GSI-OpenSSHは、OpenSSHセキュア・シェル・サーバーを更新したバージョンであり、X.509プロキシー証明書による認証と権限委譲、シングルサインオンによるリモートログイン、ファイル転送サービスを提供する。 GSI-OpenSSHは、パスワード入力無しでリモート・システムへのログインとシステム間のファイル転送を可能とし、その際には有効なプロキシー証明書を認証に使用する。 GSI-OpenSSHは、ログイン時にリモートのシステムへプロキシー証明書を転送することにより、リモートシステムで(GSI-OpenSSHコマンドを含む) プロキシー証明書要求のためのコマンドを、手作業で新しいプロキシー証明書を元のシステムで作成すること無く実行できる。

GSI-OpenSSHディストリビューションは、gsissh, gsiscp, そしてgsiftpクライアントを、X.509標準による認証と権限委譲の仕組みに何ら追加することなく、ssh(secure shell), scp(secure copy), そして sftp (secure FTP)クライアントと同等の機能を提供する。

関連するソフトウェアとツール群

必要なものがリストされているか不明であるが、全体にわたり幾つか詳細が記載されている。

Mention integration with VOMS?


XX.

The Earth System Grid Portal

XX.

2つ目の例



50

XX.

各機能の動き

Details of PKI, etc.


「Handbook of Applied Cryptography」 [42]の第8章では公開鍵暗号に特化して述べられている。

「A Security Architecture for Computational Grids」 [66]では、幾分古いが、今も尚Globusセキュティーに関して鍵となるコンセプトが紹介されている。

「Globus Toolkit Version 4 Grid Security Infrastructure: A Standards Perspective」 [52]では、GT4のセキュリティー標準に関する実装の素晴らしい紹介がある。

「Security Engineering」 [3]は直接Gridセキュリティーに関係はないが、セキュアなシステムを構築しようと考える全ての人にとっての必読書である。


51

第8章ユーザー・インターフェース

グリッド・ポータルやユーザー・インターフェースを提供するツールは、グリッドのリソースに関す

る、起動、監視、稼動管理のためのグラフィカルなユーザー・インターフェースの構成をサポートする。

（全てでは無いが）多くのこれらツールはグリッドのシステムへのアクセスをWebブラウザー経由で実現している。（全てでは無いが）多くのWebブラウザー対応のシステムは3層アーキテクチャを基本とし、中間層（第2層）のポータルサーバー（例えば、Tomcat上のuPortal やGridSphere等）においてJSR 168準拠のポートレット[22]を提供し、これにより(a)ユーザーがやりとりする第1層にあたるWebンターフェースの様々な部品の生成や(b)第3層にあたるグリッドのリソースやサービスとやりとりを実施する。

表 8.1. GT4と関連するユーザー・インターフェースを提供するツール

名前目的 E G

Java CoG Desktop Girdの"デスクトップ"インターフェースを提供するJavaアプリケーションであり、これにより例えばジョブの実行やファイルのコピーをコンピュータやストレージシステムへのドラッグ＆ドロップで個々に実現することができる。

1 Y

WebMDS XSLTを使用し、サービスが稼動しているか、アーカイブ中であるかの情報を監視するカスタム画面の生成を行う。

1 Y

Portal User Registration Service PURSeはWebベースでユーザー登録やその後のGSIクレデンシャ

ルの生成や管理を実施し、これにより大規模ユーザーのコミュニティにおいてグリッドのリソースへの容易なアクセスが可能となる。

1 Y

Open Grid Computing Environment OGCEはコンポーネント群であり、JSR 158準拠のポートレットを

含みプロキシ管理やリモートからのコマンド実行、リモートから

のファイル管理、 GPIRベースのインフォメーション・サービスを提供する。

3 Y

GridPort XX

3 ?

Sakai JSR 168準拠のシステムで分散した環境での研修や共同作業、チャットのためのツール、文章共有等を提供する。

2 ?


52

第9章パッケージと配布

表 9.1.

名称目的 M G

Grid Packaging Toolkit GPT は RPM に似たツールで、再配置可能性とmulti-flavor(例え

ば、threaded 対 non-threaded)のサポートを提供する。

2 T

NSF Middleware Initiative NMI ソフトウェアによる Globus バンドルで、一般的なユーザー・コミュニティのための、有益なグリッド・コンポーネント

と共に提供される。

3 ?

Virtual Data Toolkit NMI をベースとし、VDT はデータ中心アプリケーションのた

めの様々なツールをパッケージする。

3 ?

Rocks "Grid Roll" NSF Middleware Initiative (NMI)リリースを使用し、Rocksクラス

ターに対してGlobusの接続性を提供する。

2 N

PACman ソフトウェア・パッケージの取得、インストール、管理を透過

的に行なうことができるパッケージ・マネージャー。

2 ?

Cluster on Demand XXX


53

第10章種々の重要なツール

表 10.1.

名称目的 E G

eXtensible I/O library XIOは多様な基礎トランスポート・プロトコルへの便利なアクセスを可能にするプラグ可能な通信ライブラリである。

3 T

Grid TeleControl Protocol service GTCPはリモート装置の安全かつ信頼できる遠隔操作を可能にする

2 T

Handle System スケーラブルかつセキュアなディレクト

リ・サービス

3 Y

GT4IDE GT4用のEclipseベースのインタラクティブな開発環境 (IDE)

1 Y

eXtensible I/Oライブラリ

GT4 eXtensible I/O(XIO)ライブラリ[17]は様々なGT4コンポーネントの中、特にGridFTPに、ファイル入出力とコミュニケーション機能の実装に使用される。また、他の同様のシステムの開発者にとっても、興味深いものであろう。

XIOは、プロトコル実装がドライバーとしてカプセル化されており、マルティ・ワイヤ・プロトコルをサポートする、POSIXのような単一の API(open/close/read/write) を提供する。

GT4と一緒に配布されるXIOドライバーを、表10.2に挙げる

表 10.2. GT4に含まれるXIOドライバー

ドライバー名説明

TCP

UDP

File

HTTP

GSI

GSSAPI_FTP

Telnet

Queuing

さらに、Globus XIOはプロトコル開発者用にドライバー開発インタフェースを提供する。 XIOがエラー・ハンドリング、非同期なメッセージ配信、タイムアウト処理などのフレームワークを提供するため、開発者はインフラストラクチャーを意識せず、このインタフェースでプロトコル・コードを書くのに集中することができる。

XIOのドライバー・ベースのアプローチは、ドライバー・スタックの概念を支持することによって、コードの再利用を最大にする。 XIOドライバーをアトミックなユニットとして書いて、他のユニットの上に積み重ねることができる。このモジュール化によって、最大限の柔軟性が提供され、個々の


種々の重要なツール

54

プロトコルのデザインと評価が簡略化される。

Grid TeleControl Protocol

XX.

Handle System

Handle system[21]はCNRI(Corporation for National Research Initiatives)が開発・サポートする、スケーラブルで安全なディレクトリ・サービスである。簡単に述べると、Handle によって、階層的な名前空間の分散定義と保守、任意のキーと値の組からその名前空間の名前へのバイディング、読み出しがほとんどで、書き込みがめったにないという特性を伴うクライアント・ワークロードが可能になる。セキュリティーは、ユーザがそれら自身の名前空間の部分をコントロールできるように、うまく取り組まれている。 CNRIはルート・サーバーを運営し、他のいかなる組織も補助サーバ (subsidiary servers) を立ち上がることができる。 Handleサーバ・ソフトウェアはレプリケーションとフェイルオーバーをサポートする。様々なサーバーがクエリーを経路制御して、キャッシングを実行する。このシステムは様々な興味深いコンテキストで、大規模に配置されている。

Handle systemは最近オープンソース・ソフトウェアとしてリリースされ、そして、GT4との統合のために、多くの興味深いアイディアが開発されている。例えば、ディレクトリにおけるリソース・プロパティの記録、アドレスが変化する可能性のあるサービスの名前解決、 WS-ServiceGroup実装の基礎とするなどがあげられる。

GT4IDE


55

参考文献

[1] DMTF Common Information Model (CIM) Standards, 2004, www.dmtf.org/standards/cim .

[2] The Ganglia Project 2004 http://ganglia.sourceforge.net.

[3] Globus Toolkit Version 4 Grid Security Infrastructure: A Standards Perspective, 2004. http://www-unix.globus.org/toolkit/docs/development/4.0-drafts/security/GT4-GSIOverview.pdf.

[4] GLUE Schemas Activity and Specifications, 2004. www.cnaf.infn.it/~sergio/datatag/glue [http://www.cnaf.infn.it/~sergio/datatag/glue].

[5] Handle System, 2004. www.handle.net [http://www.handle.net].

[6] Log4j Logging Services, 2004. http://logging.apache.org/log4j.

[7] Nagios Web Site, 2004. www.nagios.org [http://www.nagios.org].

[8] OASIS Web Services Distributed Management (WSDM) Technical Committee, 2004. www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsdm [http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsdm].

[9] OASIS WS-Notification Technical Committee, 2004. www.oasisopen.org/committees/tc_home.php?wg_abbrev=wsn [http://www.oasisopen.org/committees/tc_home.php?wg_abbrev=wsn].

[10] OASIS WS Resource Framework Technical Committee, 2004. www.oasisopen.org/committees/tc_home.php?wg_abbrev=wsrf [http://www.oasisopen.org/committees/tc_home.php?wg_abbrev=wsrf].

[11] Open Grid Services Architecture Data Access and Integration (OGSA-DAI) Project. www.ogsa-dai.org.uk [http://www.ogsa-dai.org.uk].

[12] Storage Resource Broker (SRB), 2004. www.npaci.edu/DICE/SRB/ [http://www.npaci.edu/DICE/SRB/].

[13] UberFTP GridFTP-Enabled FTP Client, 2004. http://dims.ncsa.uiuc.edu/set/uberftp [http://http://dims.ncsa.uiuc.edu/set/uberftp].

[14] W3C SOAP Activity, 2002. www.w3.org/TR/SOAP [http://www.w3.org/TR/SOAP].

[15] W3C XML Schema Activity, 2001. www.w3.org/XML/Schema [http://www.w3.org/XML/Schema].

[16] Web Services Interoperability Organization, 2004. www.ws-i.org [http://www.ws-i.org].

[17] Abdelnur, A. and Hepper, S. Portlet API Specification Version 1.0. Java Community Process, JSR-000168, 2003.

[18] Abramson, D., Giddy, J. and Kotler, L., High Performance Parametric Modeling with Nimrod/G: Killer Application for the Global Grid? Proceedings of the International Parallel and Distributed Processing Symposium (IPDPS), Cancun, Mexico, 2000, 520-528.

[19] Alexander, J., Box, D., Cabrera, L.F., Chappell, D., Daniels, G., Geller, A., Janecek, R., Kaler, C., Lovering, B., Orchard, D., Schlimmer, J., Sedukhin, I. and Shewchuk, J. Web Services Transfer (WS-Transfer), 2004.

[20] Allcock, W. GridFTP: Protocol Extensions to FTP for the Grid. Global Grid ForumGFD-RP. 020,2003.

[21] Allcock, W., Bresnahan, J., Kettimuthu, R. and Link, J., The Globus eXtensible Input/Output System (XIO): A Protocol-Independent I/O System for the Grid. Joint Workshop on High-Performance Grid Computing and High-Level Parallel Programming Models in conjunction with International Parallel


参考文献

56

and Distributed Processing Symposium,2005.

[22] Anderson, R. Security Engineering. Wiley,2001.

[23] Arora, A., Geller, A., He, J., Kaler, C., McCollum, R., Milenkovic, M., Montgomery, P., Saiyed, J. and Suen, E. Web Services for Management (WS-Management), 2004. www.intel.com/technology/manage/downloads/ws_management.pdf [http://www.intel.com/technology/manage/downloads/ws_management.pdf].

[24] Atkinson, M., Chervenak, A., Kunszt, P., Narang, I., Paton, N., Pearson, D., Shoshani, A. and Watson, P. Data Access, Integration, and Management. The Grid: Blueprint for a New Computing Infrastructure, Morgan Kaufmann,2004.

[25] Baratloo, A., Karaul, M., Kedem, Z. and Wyckoff, P., Charlotte: Metacomputing on the Web. 9th International Conference on Parallel and Distributed Computing Systems, 1996.

[26] Baru, C., Moore, R., Rajasekar, A. and Wan, M., The SDSC Storage Resource Broker. 8th Annual IBM Centers for Advanced Studies Conference, Toronto, Canada, 1998.

[27] Bent, J., Venkataramani, V., LeRoy, N., Roy, A., Stanley, J., Arpaci-Dusseau, A.C., Arpaci-Dusseau, R.H. and Livny, M., Flexibility, Manageability, and Performance in a Grid Storage Appliance. 11th IEEE International Symposium on High Performance Distributed Computing,2002. IEEE Computer Society Press.

[28] Berman, F., Fox, G. and Hey, T. (eds.). Grid Computing: Making the Global Infrastructure a Reality. John Wiley & Sons,2003.

[29] Booth, D., Haas, H., McCabe, F., Newcomer, E., Champion, M., Ferris, C. and Orchard, D. Web Services Architecture. W3C, Working Draft http://www.w3.org/TR/2003/WD-ws-arch-20030808/ ,2003.

[30] Bosworth, A., Box, D., Christensen, E., Curbera, F., Ferguson, D., Frey, J., Kaler, C., Langworthy, D., Leymann, F., Lucco, S., Millet, S., Mukhi, N., Nottingham, M., Orchard, D., Shewchuk, J., Storey, T. and Weerawarana, S. Web Services Addressing (WS-Addressing). 2003.

[31] Box, D., Cabrera, L.F., Critchley, C., Curbera, F., Ferguson, D., Geller, A., Graham, S., Hull, D., Kakivaya, G., Lewis, A., Lovering, B., Mihic, M., Niblett, P., Orchard, D., Saiyed, J., Samdarshi, S., Schlimmer, J., Sedukhin, I., Shewchuk, J., Smith, B., Weerawarana, S. and Wortendyke, D. Web Services Eventing (WS-Eventing),2004. www-106.ibm.com/developerworks/webservices/library/specification/ws-eventing/ [http://www-106.ibm.com/developerworks/webservices/library/specification/ws-eventing/].

[32] Bray, T., Hollander, D., Layman, A. and Tobin, R. Namespaces in XML 1.1. W3C,2004. www.w3.org/TR/xml-names11 [http://www.w3.org/TR/xml-names11].

[33] Brecht, T., Sandhu, H., Shan, M. and Talbot, J. ParaWeb: Towards World-Wide Supercomputing. Proc. Seventh ACM SIGOPS European Workshop on System Support for Worldwide Applications, 1996.

[34] Catlett, C. In Search of Gigabit Applications. IEEE Communications Magazine (April). 42- 51. 1992.

[35] Catlett, C. and Smarr, L. Metacomputing. Communications of the ACM, 35 (6). 44-52. 1992.

[36] Chadwick, D.W. and Otenko, A., The PERMIS X.509 Role Based Privilege Management Infrastructure. 7th ACM Symposium on Access Control Models and Technologies,2002.

[37] Chervenak, A., Foster, I., Kesselman, C., Salisbury, C. and Tuecke, S. The Data Grid: Towards an Architecture for the Distributed Management and Analysis of Large Scientific Data Sets. J. Network and Computer Applications, 23 (3). 187-200.2000.

[38] Christensen, E., Curbera, F., Meredith, G. and Weerawarana., S. Web Services Description Language (WSDL) 1.1. W3C, Note 15,2001. www.w3.org/TR/wsdl [http://www.w3.org/TR/wsdl].

[39] Czajkowski, K., Fitzgerald, S., Foster, I. and Kesselman, C., Grid Information Services for Distributed Resource Sharing. 10th IEEE International Symposium on High Performance Distributed


参考文献

57

Computing,2001. IEEE Computer Society Press, 181-184.

[40] Eickermann, T. and Hommes, F. Metacomputing in a Gigabit Testbed West. Workshop on Wide Area Networks and High Performance Computing, Springer-Verlag, 1999. 119-129.

[41] Ellisman, M. and Peltier, S. Medical Data Federation: The Biomedical Informatics Research Network. The Grid: Blueprint for a New Computing Infrastructure (2nd Edition), Morgan Kaufmann,2004.

[42] Erdos, M. and Cantor, S. Shibboleth Architecture. Internet 2,2002. http://shibboleth.internet2.edu/docs/draft-internet2-shibboleth-arch-v05.pdf.

[43] Federico, D., Sacerdoti, M.J.K., Massie, M.L. and Culler, D.E., Wide Area Cluster Monitoring with Ganglia. IEEE International Conference on Cluster Computing,2003. IEEE Press.

[44] Foster, I. The Grid: Computing without Bounds. Scientific American, 288 (4). 78-85.2003.

[45] Foster, I., Alpert, E., Chervenak, A., Drach, B., Kesselman, C., Nefedova, V., Middleton, D., Shoshani, A., Sim, A. and Williams, D., The Earth System Grid II: Turning Climate Datasets Into Community Resources. Annual Meeting of the American Meteorological Society,2002.

[46] Foster, I., Berry, D., Djaoui, A., Grimshaw, A., Horn, B., Kishimoto, H., Maciel, F., Savva, A., Siebenlist, F., Subramaniam, R., Treadwell, J. and Reich, J.V. Open Grid Services Architecture V1.2004.

[47] Foster, I., Frey, J., Graham, S., Tuecke, S., Czajkowski, K., Ferguson, D., Leymann, F., Nally, M., Sedukhin, I., Snelling, D., Storey, T., Vambenepe, W. and Weerawarana, S. Modeling Stateful Resources with Web Services, www.globus.org/wsrf [http://www.globus.org/wsrf],2004.

[48] Foster, I. and Kesselman, C. Globus: A Metacomputing Infrastructure Toolkit. International Journal of Supercomputer Applications, 11 (2). 115-129. 1998.

[49] Foster, I. and Kesselman, C. (eds.). The Grid: Blueprint for a New Computing Infrastructure (2nd Edition). Morgan Kaufmann,2004.

[50] Foster, I., Kesselman, C., Nick, J. and Tuecke, S. The Physiology of the Grid: An Open Grid Services Architecture for Distributed Systems Integration, Open Grid Service Infrastructure WG, Global Grid Forum,2002.

[51] Foster, I., Kesselman, C., Nick, J.M. and Tuecke, S. Grid Services for Distributed Systems Integration. IEEE Computer, 35 (6). 37-46.2002.

[52] Foster, I., Kesselman, C., Tsudik, G. and Tuecke, S., A Security Architecture for Computational Grids. 5th ACM Conference on Computer and Communications Security, 1998. 83-91.

[53] Foster, I., Kesselman, C. and Tuecke, S. The Anatomy of the Grid: Enabling Scalable Virtual Organizations. International Journal of Supercomputer Applications, 15 (3). 200-222.2001.

[54] Foster, I. and others, The Grid2003 Production Grid: Principles and Practice. IEEE International Symposium on High Performance Distributed Computing,2004. IEEE Computer Science Press.

[55] Frey, J., Tannenbaum, T., Foster, I., Livny, M. and Tuecke, S. Condor-G: A Computation Management Agent for Multi-Institutional Grids. Cluster Computing, 5 (3). 237-246.2002.

[56] Graham, S., Niblett, P., Chappell, D., Lewis, A., Nagaratnam, N., Parikh, J., Patil, S., Samdarshi, S., Sedukhin, I., Snelling, D., Tuecke, S., Vambenepe, W. and Weihl, B. Publish-Subscribe Notification for Web Services, 2004. www-106.ibm.com/developerworks/library/ws-pubsub [http://www-106.ibm.com/developerworks/library/ws-pubsub] .

[57] Grimshaw, A., Weissman, J., West, E. and E. Lyot, J. Metasystems: An Approach Combining Parallel Processing and Heterogeneous Distributed Computing Systems. Journal of Parallel and Distributed Computing, 21 (3). 257-270. 1994.

[58] Grimshaw, A.S. and Wulf, W.A. The Legion Vision of a Worldwide Virtual Computer. Communications of the ACM, 40 (1). 39-45. 1997.


参考文献

58

[59] Hughes, J. and Maler, E. Technical Overview of the OASIS Security Assertion Markup Language (SAML) v1.1, http://www.oasisopen.org/committees/tc_home.php?wg_abbrev=security,2004.

[60] Karonis, N., Toonen, B. and Foster, I. MPICH-G2: A Grid-Enabled Implementation of the Message Passing Interface. Journal of Parallel and Distributed Computing, 63 (5). 551-563. 2003.

[61] Keahey, K., Fredian, T., Peng, Q., Schissel, D.P., Thompson, M., Foster, I., Greenwald, M. and McCune, D. Computational Grids in Action: The National Fusion Collaboratory. Future Generation Computer Systems, 18 (8). 1005-1015.2002.

[62] Kendall, S.C., Waldo, J., Wollrath, A. and Wyant, G. A Note on Distributed Computing. Sun MicrosystemsTR-94-29, 1994.

[63] Lin, A., Maas, P., Peltier, S. and Ellisman, M. Harnessing the Power of the Globus Toolkit. Cluster World, 2 (1).2004.

[64] Litzkow, M. and Livny, M. Experience with the Condor Distributed Batch System. IEEE Workshop on Experimental Distributed Systems, 1990.

[65] Litzkow, M.J., Livny, M. and Mutka, M.W. Condor - A Hunter of Idle Workstations. 8th International Conference on Distributed Computing Systems, 1988, 104-111.

[66] Menezes, A., Oorschot, P.v. and Vanstone, S. Handbook of Applied Cryptography. CRC Press, 1996.

[67] Messina, P. Distributed Supercomputing Applications. The Grid: Blueprint for a New Computing Infrastructure, Morgan Kaufmann, 1999. 55-73.

[68] Novotny, J., Tuecke, S. and Welch, V., An Online Credential Repository for the Grid: MyProxy. 10th IEEE International Symposium on High Performance Distributed Computing, San Francisco,2001. IEEE Computer Society Press.

[69] Paton, N.W., Atkinson, M.P., Dialani, V., Pearson, D., Storey, T. and Watson, P. Database Access and Integration Services on the Grid. U.K. National eScience Center,2002. www.nesc.ac.uk.

[70] Pearlman, L., Kesselman, C., Gullapalli, S., Spencer, B.F., Futrelle, J., Ricker, K., Foster, I., Hubbard, P. and Severance, C., Distributed Hybrid Earthquake Engineering Experiments: Experiences with a Ground-Shaking Grid Application. 13th IEEE International Symposium on High Performance Distributed Computing,2004.

[71] Rosenberg, J. and Remy, D. Securing Web Services with WS-Security. Sams,2004.

[72] Smallen, S., Olschanowsky, C., Ericson, K., Beckman, P. and Schopf, J.M., The Inca Test Harness and Reporting Framework. SC'2004 High Performance Computing, Networking, and Storage Conference,2004.

[73] Sotamayor, B. The Globus Toolkit 4 Programmer's Tutorial, 2005. www.casasotomayor.net/gt4-tutorial [http://www.casasotomayor.net/gt4-tutorial] .

[74] Spencer, B., Finholt, T., Foster, I., Kesselman, C., Beldica, C., Futrelle, J., Gullapalli, S., Hubbard, P., Liming, L., Marcusiu, D., Pearlman, L., Severance, C. and Yang, G., NEESgrid: A Distributed Collaboratory for Advanced Earthquake Engineering Experiment and Simulation. 13th World Conference on Earthquake Engineering, Vancouver, B.C., Canada,2004. Paper No. 1674.

[75] Vahdat, A., Belani, E., Eastham, P., Yoshikawa, C., Anderson, T., Culler, D. and Dahlin, M., WebOS: Operating System Services For Wide Area Applications. 7th IEEE International Symposium on High Performance Distributed Computing, 1998. IEEE Computer Society Press.

[76] Welch, V., Barton, T., Keahey, K. and Siebenlist, F., Attributes, Anonymity, and Access: Shibboleth and Globus Integration to Facilitate Grid Collaboration.2004.

[77] Welch, V., Siebenlist, F., Foster, I., Bresnahan, J., Czajkowski, K., Gawor, J., Kesselman, C., Meder, S., Pearlman, L. and Tuecke, S., Security for Grid Services. 12th IEEE International Symposium on High Performance Distributed Computing, 2003.


参考文献

59

[78] Zhang, X., Freschl, J.L. and Schopf, J.M., A Performance Study of Monitoring and Information Services for Distributed Systems. 12th IEEE International Symposium on High Performance Distributed Computing,2003. IEEE Computer Society Press.


参考文献

60

謝辞

GT4は多くの人々による何年もの努力の賜物であり、様々な財源からかわるがわる、そして何年にも渡り、経済的支援を受けてきた。著者の記憶の欠如により、以下から漏れてしまっている貢献者もいるかもしれない。もしあなたの名前が欠けていれば、躊躇無く知らせていただきたい。

Globus Allianceはアルゴンヌ国立研究所、シカゴ大学、南カリフォルニア情報科学大学、エジンバラ大学、スウェーデン並列コンピューターセンター、スーパーコンピューティング国立センターの個人によって構成される。これらの研究所のスタッフは、Globusの研究、デザイン、開発に対して、大きな責任を負ってきたが、全てを負ったというわけでは決してない。その他の重要な貢献者として、ウィスコンシン大学のCondorチーム、ローレンス・バークレー国立研究所のpyGlobusとNetLoggerのグループ、CERNのEU DataGrid グループ、IBMとHPのGridとWebサービスのグループ、Univaが含まれる。その他にも、多くの人々がこのソフトウェアを開発、応用、使用し、必要条件を提示することで、あるいは関連する技術仕様に従事することで貢献してくれた。この成果が価値あるものになったのは、このコミュニティの支援のおかげである。

財政支援においては、何よりもまず米国の連邦政府局、とりわけ、エネルギー省、全米科学財団、NASA および米国国防総省高等研究計画局により支援されてきた。エネルギー省のNational Collaboratoriesプログラムと、全米科学財団のMiddleware Initiative プログラムは特に支援的であった。ロスアラモス国立研究所はGridFTPの開発を支援してくれた。IBM はJava WS Coreの多くの作業を支援してくれた。Microfoft、Sun、Cisco もまた貢献してくれた。UKでは、DAIS 開発のための資金がイギリスの eScience プログラムによって提供され、一方スウェーデンではXXXによって支援された。

GT4は広く、他のオープンソース・ソフトウェアのシステム上に成り立っている。特に、Axis、Webサービスのコア、セキュリティ、 WS-Addressing といった Apache ソフトウェアは、それらの中にはGlobus Allianceのメンバーが相当な貢献をたものもあるが、それらに対するかなりの負債に感謝する。

このドキュメントは、他から、特にGlobusオンライン・ドキュンメンテーションから拝借した部分が大きい。引用することを許してくれた、それらの資料の著者に感謝する。


Globus入門 · 2019. 12. 6. · 代わりに、Globus Web の Borja Sotamayor氏の素晴らしい...

Documents

Transcript of Globus入門 · 2019. 12. 6. · 代わりに、Globus Web の Borja Sotamayor氏の素晴らしい...