レベル: 初級 Robert Vrablik (vrablik@us.ibm.com), Senior Strategist/Solution Architect for Grid Computing, IBM
Richard Strysniewicz (strysniewicz@us.ibm.com), Senior Software Engineer, IBM Global Services
Chris Reech (reech@us.ibm.com), Senior Technical Staff Member, IBM Global Services Technology Center
Dennis Spexet, IT Architect, IBM
2004年 11月 09日 この 3 回シリーズのパート 2 では、高速解析グリッド環境 (AAGE) のインフラストラクチャー・コンポーネントがどのように結び付き、どのように連携して、幅広いアプリケーション要件をサポートする仮想システム環境を構築および提供するのかについて、詳しく説明します。パート 1 では、グリッド・コンピューティングによって解決される問題と、グリッド・ソリューションの実装から得られるビジネス上の利点について説明しました。パート 3 では、実際の実装例を紹介します。
幅広いアプリケーション要件をサポートする仮想システム環境を構築して提供するために、AAGE インフラストラクチャー・コンポーネントはどのように結び付き、連携するのでしょうか。グリッド・インプリメンテーションの基本的な例を見てみましょう。
図 1. ログインとアクセスを簡略化するための、ユーザー・ポータルの基本的なグリッド・インプリメンテーション
この例では、ユーザー・ポータルを設置することにより、複数のナレッジ・ワーカーが共通の場所から簡単にログインしたり、アプリケーションにアクセスしたりできるようにしています。Data synapse が管理するプロセッシング・グリッドのノード集合上では、SAS アプリケーションが実行されています。アプリケーション・ポータルは、Data synapse インターフェースを使用して Data synapse にジョブの実行を依頼します。Data synapse は、あらかじめ定義されている Data synapse エンジンの集合を通して管理します。
Data synapse が管理する環境には、業務上の優先順位に基づいてポリシーが設定されており、各ビジネス・ユニットにどれだけのシステム資源量を割り当てるかは、このポリシーに応じて決定されます。IBM DB2® Information Integrator は、データ・フェデレーション技法を応用して、分散データ・ソースの集合からアプリケーションの入力データ・ファイルを構築します。
Avaki Data Grid テクノロジーは、分散した出力データへのアクセスを提供します。このテクノロジーを使用すると、分散したコンピューター資源にデータ・ファイルが関連付けられたままの状態でも、その出力結果を 1 つのファイルとしてユーザー・コミュニティーに表示できるからです。
グリッド・テクノロジーを初めて導入する企業や団体の場合は、このような基本的実装から始めることをおすすめします。
この例では、複数のビジネス・ユニットが 1 つのコンピューター資源の集合を共有しています。各ビジネス・ユニットはグリッドにアプリケーション要求を送信します。グリッドから実行サービスを受ける必要のあるビジネス・ユニットが 1 つしかない場合は、グリッド内のすべての資源がそのユニットのアプリケーション実行に割り当てられます。
逆に、複数のビジネス・ユニットがグリッドからアプリケーション・サービスを受ける必要がある場合は、各ビジネス・ユニットの消費資源量をポリシーが制御します (1 つのビジネス・ユニットがグリッド内の全資源を占有することがないように、ビジネス・ユニットごとに最低資源量を設定することが可能です)。これによりビジネス・ユニットは、システム資源を独自に管理する場合よりも多くのコンピューティング資源に、オンデマンドでアクセスできるようになります。
さらに、情報技術を共通プールから管理できるので、資源使用率が上がり、事業の ROI が向上するとともに、システム資源の管理が簡略化されます。
このようにして、グリッド・テクノロジーはアプリケーションの実行を高速化し、企業内でのシステム資源の使用状況を最適化します。
それでも、まだ足りない
ビジネス・オペレーションの成長を促し、IT 資源の需要拡大に柔軟に対応するには、グリッド・テクノロジー機能のさらなる活用が必要です。ビジネス・ユニットのクラスターへのグリッド配備はその筆頭例です (前の例を参照してください)。
部門のグリッドを結び付けて、1 つの仮想化システム資源の集合として機能させると、スケール・メリットが目に見えて増大します。これを実現するには、インフラストラクチャーに次のような属性が必要です。
- テクノロジーに対応しながら独自のアプリケーションを収容できる柔軟性
- 企業の共有データへのアクセシビリティ
- アプリケーション・ユーザー・インターフェース (またはユーザー・ポータル) の共通性
- グリッドのシステム資源のプロビジョニング可能性 (ビジネス・ユニットの優先順位とサービス・レベル・アグリーメントの施行状況に準拠)
- システム資源の調整可能性 (ビジネス・ユニットや買収企業の増加に応じてグリッドを追加、削除、変更)
次のセクション (および図 2) では、この拡張シナリオに応じて新しいテクノロジーを追加する方法を説明します。
仮想化グリッド
IBM Grid Toolbox グリッド・サービスは、グリッド・インフラストラクチャーを仮想化するために実装されます。これにより、個別のアプリケーションのサポート用として、グリッド・コンポーネントを簡単に追加または変更できるようになります。また、タイプの異なる交換可能なグリッド・マネージャーをグリッド内に共存させることも可能になります。
動的プロビジョニング
IBM Tivoli® Intelligent Orchestrator はグリッド資源のプロビジョニングを行います。これは、ワークロード要求の変更に対応して、サービス・レベル・アグリーメントに基づいたサービスをアプリケーションに提供します。
グリッド・マネージャー
グリッド・マネージャーは、資源間でワークロードのバランスを取ります。
情報フェデレーション
DB2 Information Integrator は、データベース、XML、フラット・ファイルなどの複数のデータ・ソースから、リレーショナル入力データを統合します。
ファイルおよびストレージ・システムの仮想化
SAN ファイル・システムでは、異機種混合ファイル・システムに格納されているデータへの共通アクセスが提供されます。また、異機種混合のストレージ・デバイス間で最適なファイル配置を行う SAN ボリューム・コントローラーも利用できます。
ユーザー・ポータル
ポータル Web アプリケーションと WebSphere® Application Server は、ジョブの認証、実行依頼、管理を行うための単一インターフェースを提供することにより、ユーザー・インターフェースを仮想化します。
図 2. 拡張シナリオの管理用として AAGE に追加される新テクノロジー
ユーザー・ポータル
ユーザー・ポータルは WebSphere Application Server 上で実行される Web アプリケーションであり、ユーザーをグリッド・インフラストラクチャーから分離するために設計されたものです。ジョブの実行サーバーやデータの常駐場所について、ユーザーが把握する必要はありません。ユーザー・ポータルは、すべての SAN 接続ストレージに対して SAN ファイル・システムの単一ネーム・スペースを提供します。また、SAN に接続されていないノード上にストレージが存在する場合は、SAN ファイル・システムと Avaki を組み合わせたネーム・スペースを提供します。
ユーザー・ポータルは、証明書ベースのセキュリティー・システムを使用してユーザーを認証する単一ポイントです。ポータルにログオンして認証されたユーザーは、自分の「証明書」にアクセスします。この証明書がグリッドで受け渡しされ、基礎となるマシン上で実行されるその後のアクションについて、ユーザーに許可を与えます。
ユーザー・ポータルは、ジョブの実行依頼や管理を行う単一インターフェースです。ユーザーが複数のアプリケーションを使用する場合でも、実行依頼や管理は単一のポータルから行います。これにより、アプリケーション、例えばジョブの実行依頼や結果表示などがシンプルになります。ISV が開発したアプリケーションには、独自のインターフェースが使われている場合があります。ユーザー・ポータルは、これらのアプリケーションのリンクにも使用されます。
グリッド・マネージャー
ほとんどのグリッドの実装では、単一ベンダー、オープン・ソース、独自開発のいずれかのグリッド・ミドルウェアを使用して構築されます。そのため、そのグリッド上で実行されるすべてのアプリケーションに、使用ミドルウェアとの互換性が必要です。グリッド・コンピューティングの発展に伴い、さまざまな異機種混合ミドルウェア・インプリメンテーションを共存させていく必要性はますます高まるでしょう。このことは、オープン・スタンダードに基づいてグリッド・インプリメンテーションを構築する必要性の根拠となります。
この環境は、IBM Grid Toolbox V3 for Multiplatforms を使用して、複数の異機種混合グリッド・マネージャーに単一のアプリケーション・ポータルを接続できるように設計されています。グリッド・コンピューティングの最終目標は、多様な組み合わせの資源をマルチプラットフォーム環境で共有している接続システムの集合から、自己管理型の強力な仮想コンピューターを作り上げることです。このようなシステムおよび接続形態がグリッドなのです。
これを実現するには、グリッド・コンピューティングのための共通標準を使用して、セキュアで堅固なインフラストラクチャーを構築する必要があります。Open Grid Services Infrastructure (OGSI) などの標準は、グローバル・グリッド・フォーラムによって開発され、さまざまな製品に実装されています。IBM Grid Toolbox V3 for Multiplatforms は Open Grid Services Architecture (OGSA) に基づいており、OGSI 標準を実装しています。IBM では、この標準の策定に積極的に取り組んでおり、その一環として、他の関係団体と共同で Web Services Resource Framework (WS-RF) および Web Services Notification を発表しました。これらは、OGSI 標準を拡張するための提案です。このテクノロジーは、製品実装が使用可能になった段階で AAGE プロジェクトに統合される予定です。
Toolbox には次のものが含まれています。
- グリッド・サービスで他のグリッド参加者と共有できるホスティング環境
- グリッド・サービスやグリッド・ホスティング環境を管理、運営するためのツール・セット (Web ベースのインターフェースである Grid Services Manager を含みます)
- 新しいグリッド・サービスやグリッド・アプリケーションを作成、配備するための一連の API および開発ツール
これらの仮想化サービスを使用すると、この環境のコンポーネントが OGSI 準拠インターフェースによってグリッド・マネージャーから分離されます。この環境は、オープン・スタンダードに基づくグリッド・サービスを使用して異機種混合グリッド・ミドルウェアをサポートできるように設計されています。
グリッド上で実行されるアプリケーションでは、このインターフェースを通じて、ミドルウェアを動的に選択できます。どのグリッド・マネージャーがアプリケーションの実行に関与するかについて、ユーザーが把握する必要はありません。ユーザーに求められるのは、グリッド対応アプリケーションを入手し、そのコンポーネントを構成、配備することだけです。グリッド・サービスを実装すれば、データ・センター管理者は、現在実行中のアプリケーションに与える影響を最小限に抑えながら、グリッド・マネージャーのインスタンスを柔軟に追加したり削除したりできるようになります。
最初は Data synapse インターフェースを使用してこの環境は実装されますが、いずれは別のアプリケーションの追加も可能になります。別のグリッド・マネージャーからのサポートが必要なアプリケーションの場合は、グリッド・マネージャーのインスタンスごとに OGSI インターフェースを開発しなければなりません。
オープン・スタンダードを実装すれば、グリッド・システム内で製品をより動的に実行できます。そのため、グリッド・ミドルウェアのベンダーは、オープン・スタンダードの実装に向けて動き始めています。しかし残念ながら、システム資源を管理ドメインに追加したり削除したりする作業は、完全に動的というわけではありません。ほとんどのグリッド・インフラストラクチャー管理者は、静的に定義された資源を管理ドメイン内に保有しています。資源の追加や削除は可能ですが、それには通常、手操作による介入が必要です。
複数のグリッド・マネージャー・ドメインに対してシステム資源を動的にプロビジョニングするテクノロジーがあります。このテクノロジーを使用すると、サービス・レベル・アグリーメント・ポリシーへの準拠が容易になります。ここでは、このようなテクノロジーがサンプル環境でどのように利用されるかについて説明します。
オーケストレーションおよびプロビジョニング
企業にとって最大の課題の 1 つは、「オンデマンド・ビジネスに対応するには IT インフラストラクチャーを変えなければならない」ということです。これは技術的な問題ではありません。むしろ、組織のポリシーに関わる問題です。
企業内の部署はそれぞれ独自に情報技術を導入しているため、資源を他のユーザーと共有することには消極的です。このような姿勢には、多くの理由があります。
- 企業内の力関係
- 予算
- 自分たちの資源が他部署に「所有」されると資源にアクセスできなくなる、という懸念
- データのセキュリティー
しかし、このような消極的姿勢を変えるのは不可能ではありません。企業内の各部署でシステム資源を共有しながら、資源へのオンデマンド・アクセス権も維持するテクノロジーが存在するからです。
ユーザー・コミュニティーは、システム資源の物理的所有権を求めるのではなく、アクセス可能な資源量やアクセス時刻を定めたポリシーに従います。このポリシーは、業務上の優先順位、例えばサービス・レベル・アグリーメント (SLA) などに基づいています。
Tivoli Provisioning Manager を含む IBM Tivoli Intelligent Orchestrator は、ワークロード要求の変化と、ポリシーで定義された制約に従って、企業内のシステム資源を割り振ります。システム資源の最小量と最大量はいずれもポリシーで定義されているため、使用可能なシステム資源を 1 つのビジネス・ユニットが全部消費してしまうことはありません。さらに、システム資源のプロビジョニングは日付、時刻、イベントに基づいて行われます。
このグリッド・インプリメンテーションでは、ポリシーは Tivoli Intelligent Orchestrator に定義されています。Tivoli Intelligent Orchestrator は、グリッド内で資源を共有する各アプリケーション領域 (ビジネス・ユニット) に設定された SLA を、どのように管理するかを決定します。Tivoli Intelligent Orchestrator は、それぞれのグリッド管理ドメインから資源消費情報を受け取ります。この消費情報を使用して、各ビジネス・エリアの SLA が満たされているかどうかが判断されます。SLA が満たされていない場合、Tivoli Intelligent Orchestrator は Tivoli Provisioning Manager と連携してポリシーを確認し、SLA を達成するための資源の増減、つまり特定の組織に与える資源を増やすべきか減らすべきかについて判断します。より多くのシステム資源を消費する権利がいずれかの組織に与えられた場合、Tivoli Provisioning Manager は、そのシステム資源を必要とするグリッド管理ドメインに、より多くのシステム資源をプロビジョニングします。この資源は、グリッド環境外にある資源の「プール」から取得される場合もあれば、他のグリッド・マネージャー・ドメインから再プロビジョニングされる場合もあります (ポリシーやシステム資源の可用性に依存します)。
資源消費情報の受け取りは Tivoli Intelligent Orchestrator ServerDriver クラスを戦術的に実装することで行われます。このクラスは、グリッド・マネージャーのワークロードに基づいて、CPU 使用率の計算値を返します、このカスタム実装は、Tivoli Intelligent Orchestrator とグリッド・マネージャーの間の OGSI 準拠インターフェースを使用して構築されたものです。標準ドライバーは SNMP インターフェースを使用します。
Tivoli は、Tivoli Intelligent Orchestrator V2.0 の一部である Objective Analyzer という戦略的ソリューションを開発しています。このソリューションは、グリッド・コンピューティングを実現し、グリッド環境に対するプロビジョニング/オーケストレーション機能を使用可能にします。このソリューションを使用すると、複数の資源消費アルゴリズムが有効になり、複数のグリッド・マネージャーとの統合が実現します。サンプル用の実装は、この戦略的な Tivoli ソリューションをより戦術的なソリューションで補うように設計されています。
図 3. 2 つの組織間で共有される資源のオーケストレーションとプロビジョニングをサポートする構成
この構成では、組織 A にはプラチナ (最高) のプロビジョニング優先度と 2 つ以上の資源が与えられています。組織 B には、ゴールド (やや低位) のプロビジョニング優先度と 3 つ以上の資源が割り当てられています。この企業には 8 つの資源があり、Linux 資源用と Windows 資源用の 2 つの共有プールに分けられています。グリッド・マネージャーには X と Y の 2 つがあり、企業内で静的に構成されている 2 種類のミドルウェアを表しています。この例の「静的」とは、グリッド・マネージャーがプロビジョニングされないことを意味します。
図 4. 2 つの同時アプリケーションをサポートするようにプロビジョニングされた、ある時点のコンピューター資源の図
この例では、組織はそれぞれ異なるアプリケーションを実行しています。各アプリケーションの実行は、そのアプリケーションで必要とされるタイプのグリッド・マネージャーによって管理されています。それぞれのグリッド・マネージャーは、プロビジョニングされた資源全体でアプリケーション・タスクを実行します。組織 A のプロビジョニング優先度は組織 B より高いため、組織 A のほうに多くの資源がプロビジョニングされています。組織 B には、ポリシーの定義に基づいて、最小数の資源がプロビジョニングされています。
SAN ファイル・システム
SAN ファイル・システムは、IBM のストレージ仮想化戦略における主要プラットフォームの 1 つです。その中核的な機能は、ストレージ・エリア・ネットワーク (SAN) 用に設計された共通ファイル・システムを提供することです。SAN ファイル・システムはさまざまなディスク・サブシステムからストレージを集約し、共有ファイル・システムとして、接続サーバーに提供します。図 5 に示すように、SANファイル・システム には、ネットワーク内の単一の中央制御ポイント (ファイルとデータを管理するポイント) を提供する機能が含まれています。
図 5. SAN ファイル・システムで提供される、ネットワーク内の単一の中央制御ポイント (ファイルおよびデータの管理用)
SAN ファイル・システムの基本設計では、データとメタデータの処理が分割されています。図 5 に示すように、SAN ファイル・システム・クライアントは LAN および SAN に接続されています。SAN ファイル・システムへのアクセスが行われると、専用のメタデータ・サーバーがクライアントと TCP/IP で通信し、メタデータを処理します。ただし、データ自体は直接 SAN 経由でアクセスされます。
SAN ファイル・システムは、製品としては、一対の IBM xSeries® サーバーにソフトウェア・ベース・ソリューションとしてインストールされた形で提供されます。この開発とテストに使用されている SAN ファイル・システムは、SuSE Linux Enterprise Server 8 を実行する 2 台の xSeries サーバーから構成された基本レベル構成です。各サーバーは 3-GHz Xeon デュアル・プロセッサー、4 GB の RAM、二重化ファイバー・チャネル・ポート、および 4 つの 10/100/1000 MB/sec Ethernet ポートから構成されています。
この方法でのファイル・システム・データの処理には、次のような利点があります。
- パフォーマンスの向上 : アプリケーションのグリッド化で計算処理能力が上がることに加え、I/O パフォーマンスも向上します。
- 共有ストレージ使用中のパフォーマンス (ファイバー速度、ストライピングなど) は、ローカル・ディスク・アクセスに匹敵するか、それ以上になります。
- 要求されるサービス品質に応じてデータが配置されます (高速アクセスが必要なデータは高速ハードウェアに格納されます)。
- ストレージ資源の使用率の向上 : データを複数コピーする必要がなくなります。
- 柔軟な構成 : ストレージ・ハードウェアとサーバー・ハードウェアが直接連結されないので、ハードウェアの異機種混合が可能です。ストレージとサーバーはそれぞれ独立してアップグレードできます。構成を調整して、パフォーマンス、フォールト・トレランス、可用性などの新要件や要件変更をサポートすることもできます。ストレージは非常にスケーラブルで、大規模グリッドのニーズに合わせて拡大することも可能です。
- 管理コストの削減 : ポリシー・ベースの管理や異機種混合ストレージ資源の集中管理が可能です。
- ユーザーおよびアプリケーションから透過的 : 異機種混合デバイスをグループ化して、単一のファイル・システムであるかのように実行できます。
もう 1 つの特徴は Avaki Data Grid です。この環境では、複数の管理ドメインにデータ・アクセス・サービスを提供するために使用されます。Avaki はフェデレーテッド・データ共有モデル、グローバル・ネーム・スペース、および一連の Data Grid Access Server を使用します。Data Grid Access Server は、NFS プロトコルをサポートし、クライアント・マシンにマウントするものです。Avaki はデータ・グリッドをクライアントのファイル・システム階層に効率的にマップします。
Avaki ソフトウェアは選択されたノードの集合にインストールされ、そのノードの 1 つが SAN ファイル・システムにアクセスします。SAN ファイル・システムの一部が Avaki データ・グリッドに「エクスポート」されると、Avaki Data Grid Access Server のノードがそれを利用できるようになります。
Avaki Data Grid Access Server のノードは NFS サーバーとして機能し、他の NFS サーバーと同様に、NFS クライアントによってマウントされます。SAN ファイル・システム上のデータは、この方法で Avaki データ・グリッドにエクスポートされ、複数の管理ドメイン内のクライアント (従来の SAN 接続機能を持たないクライアントなど) によって使用されます。これにより、それまで独立していたストレージ資源から全社的なグリッドを構築できるようになります。
SAN 接続プラットフォームと Avaki 経由でデータにアクセスするプラットフォームの間には、パフォーマンスに差があります。しかし、Avaki を使用するマシンでデータ集中型ジョブを実行しないようにすれば、ジョブ全体の実行速度が落ちることはありません。
データ・フェデレーションとライセンス使用監視
データ・フェデレーションはこのアーキテクチャーのオプション機能です。環境を使用可能にするために必須というわけではありません。データ・フェデレーションのコンポーネントをこの環境に追加または削除すれば、特定のアプリケーション要件をサポートできます。
例えば、データ・フェデレーションで複数の異機種混合データ・ソースからアプリケーションの入力データを集め、データを下準備することもできます。その場合は、データの取得や単一の入力データ・セットの作成に、DB2 Information Integrator が使用されます。
もう 1 つの例は、アプリケーション実行中に複数の異機種混合データ・ソースに動的にアクセスする場合です。この場合、DB2 Information Integrator はより動的に使用され、アプリケーション内の単一の SQL ステートメントが、複数のデータ・ソースに、最適化された方法で動的にアクセスします。
ライセンス使用の監視は、このアーキテクチャーのもう 1 つのオプション・コンポーネントです。このコンポーネントは、お客様の要件に応じて、追加したり削除したりできます。このコンポーネントは、「エンタープライズ・グリッド内でソフトウェア・ライセンスの使用状況を監視することが望ましく、かつ必要である」という信念の基に、当初の開発テスト環境に含まれていました。
開発中およびテスト中には、シンプルなアプローチが使用されていました。このアプローチでは、多様な組織からのジョブが環境内で実行されるときに、Tivoli License Manager がアプリケーション・ソフトウェア・ライセンスを監視します。管理者は、Tivoli License Manager の既存のレポート・インターフェースを使用して、アプリケーション・ソフトウェア・ライセンスの使用状況を時間経過に沿って表示できます。
ソフトウェア・ライセンス交付のシナリオは、ソフトウェア・ベンダーのライセンス交付スキームに大きく依存するため、この記事では詳しくは取り上げません。ただし、これがグリッド・インプリメンテーションの重要課題であるということは認識しておいてください。この課題には、新しいインプリメンテーションの計画初期段階で取り組まなければなりません。
セキュリティー・モデル
このシステムでは、ユーザーが Web ポータルや基礎的資源にアクセスできるように、証明書ベースのセキュリティー・モデルが提供されます。
認証局は、グリッド環境のメンバーであるホストおよび各グリッド・ユーザーに対して、署名付きの識別証明書を発行します。Verisign や RSA Security などを含め、どの認証局もアクセス可能です。現在のところ、このプロジェクトには IBM Grid Toolbox に付属する SimpleCA が使用される予定です。
「ログイン (Login)」ページには、テキスト入力フィールドである「ユーザー名 (Username)」と「パスワード (Password)」、および「ログイン (Login)」ボタンがあります。ポータルにログインするには、ユーザー名とパスワードを入力し、「ログイン (Login)」を選択します。ユーザーのログインが許可されると、Web アプリケーションが LoginServlet サーブレット Java クラスを呼び出します。このクラスは、Java のユーザー認証と情報クラスを動的にロードして呼び出し、ユーザー ID とパスワードを認証します。現在のデフォルトのユーザー認証および情報クラスは、DB2 Data Source から共有の Grid Information リポジトリーにアクセスし、Globus ユーティリティー・クラスを使用して、証明書、キー、プロキシーを操作します。
サーブレットと JSP が相互に通信できるように、サーブレットが UserInfoBean を作成します。この UserInfoBean は、Web アプリケーションのセッションを通じて維持されます。先に述べた認証クラスが動的にロードされると、サーブレットがこの認証クラスを設定します。次に、サーブレットはユーザー名とパスワードを認証クラスに渡し、妥当性をチェックします。ここで認証に成功した場合、サーブレットはユーザー情報 (ユーザーのロール、アプリケーション、結果ディレクトリーなど) を読み取ります。このユーザー情報が、Web アプリケーションのその後の段階で使用されます。
ユーザー認証および情報クラスに加えて、LoginServlet は、Web アプリケーション内の他のサーブレットが使用するアプリケーション情報クラスとバックエンド・クラスも動的にロードします。
ユーザーがログオンすると、Proxy JSP が呼び出されます。Proxy JSP は、以前作成された UserInfoBean にアクセスし、情報を抽出して、認証結果をチェックします。認証に失敗した場合は、ユーザーに通知され、10 秒後に自動的に Login JSP に戻ります。認証に成功した場合は、プライベート・キーのパスフレーズ、現在のプロキシーの強度 (ビット数)、現在のプロキシーのライフタイム (秒数)、および 2 つのボタン (「新しいプロキシーの生成 (Generate new proxy)」と「既存プロキシーの使用 (Use existing proxy)」) が表示されます。
新しいプロキシーを生成するには、現在のプロキシーのプライベート・キー・パスフレーズ、強度、およびライフタイムを入力し、「新しいプロキシーの生成 (Generate new proxy)」を選択します。ユーザーの既存のプロキシーを使用するには、「既存プロキシーの使用 (Use existing proxy)」を選択するだけです。入力すると、Web アプリケーションによって ProxyServlet サーブレットが呼び出されます。選択されたボタンに応じて、サーブレットは、提供されたパラメーターから新しいプロキシーを生成するか、特に処理をせずに次の JSP に切り替えます。
まとめ
この記事では、高速解析グリッド環境 (AAGE) のインフラストラクチャー・コンポーネントがどのように結び付き、どのように連携して、幅広いアプリケーション要件をサポートする仮想システム環境を構築および提供するのかについて、詳しく説明しました。3 回シリーズの最後の記事では、実際の実装例を紹介します。
参考文献
著者について  | | | Robert Vrablik は、グリッド・コンピューティングに関する上級戦略担当者兼ソリューション・アーキテクト (IBM Systems and Technology Group 所属) です。彼は、戦略担当者として IBM の製品ポートフォリオ内で機能を統合するための要件を識別し、IBM のグリッド・コンピューティング・イニシアチブをサポートしています。また、IBM の統合化チームと協力し、将来のグリッド・インダストリー・オファリング・ソリューションのためのプロトタイプを設計しています。以前は IBM Consulting Group において、ビジネスと IT の統合、およびデータウェアハウスの設計と実装を専門とする Business and Information Technology Transformation 担当コンサルタントとして勤務していました。さらに、アプリケーション・プログラマー兼アナリストとして数年間、スタンドアロンのミニコンピューター用ビジネス・アプリケーションの開発や大規模システムの事業保険アプリケーションの開発に携わってきました。 |
| | | Richard Strysniewicz は IBM グローバル・サービスの上級ソフトウェア技術者で、IBM Web ベースのリアルタイム分散システムの開発において、14 年を超える経験を持っています。また、IBM グローバル・サービス Grid Computing Initiative チームのメンバーでもあり、リファレンス・アーキテクチャー、リファレンス・インプリメンテーション、グリッド・ミドルウェアの評価、お客様エンゲージメントのサポート、研修や営業のための内外プレゼンテーションなど、数多くの活動に参加しています。 |
| | | Chris Reech は IBM グローバル・サービス Technology Center の 上級技術スタッフ・メンバーであり、IBM グローバル・サービス World Wide Grid Strategy チームにも参加しています。最近の業務の中心は、グリッド・テクノロジーを商用化し、石油、金融サービス、設計および製造、ライフサイエンスのお客様やパートナー向けのビジネス・ソリューションにそのテクノロジーを応用することです。また、彼は IBM グローバル・サービス Universal Management Infrastructure におけるグリッド・テクノロジーの応用を先導しています。これは、共有可能な標準化環境で「従量課金」制のオンデマンド・ビジネスを実現する、IBM の配布管理テクノロジーです。彼は、IBM の戦略的アウトソーシングやコンサルティング、および米国の民間/軍事組織のためのリアルタイムな分散コンピューティング環境において、16 年を超える経験を持っています。さらに、Web ポータルとオンデマンド・グリッド・コンピューティング・テクノロジーに関する特許を IBM で複数取得しているほか、ルイジアナ大学ラファイエット校で情報工学の学士号を取得しています。 |
| | | Dennis Spexet は IBM グローバル・サービスの IT アーキテクトで、過去 10 年間、さまざま技術分野に携わってきました。最近の業務の中心は、ストレージ・エリア・ネットワークを開発し、グリッド・コンピューティング環境と統合することです。彼は、ミシガン大学アナーバー校で数学の修士号を取得しています。 |
記事の評価
| 
