レベル: 初級 Travis Van (travis.van@gmail.com), PR Chair, Globus Consortium
2005年 4月 05日 Travis Van は先頃、Univa の CEO である Steve Tuecke 氏と会見しました。Univa は、企業に対してオープン・ソースの Globus Toolkit に関する技術サービスおよびサポートを提供する新会社です。Tuecke 氏は、IBM developerWorks の読者にとって興味深い見解の一端を披露してくれました。その内容は、グリッド・デベロッパーのための技術的アドバイスから、グリッドの用途を e-サイエンスから企業の領域へと広げる際に生じる特有の問題点に関する広範なテーマに至るまでの、多岐にわたっています。
バックグラウンド
1996 年、アルゴンヌ国立研究所 (ANL) と南カリフォルニア大学 Information Sciences Institute の科学者たちは Globus Project を立ち上げました。その重点目標は、コラボレーションによる科学計算アプリケーションで膨大なデータ量を必要とする問題を扱う場合に、より効果的なインターネット・インフラストラクチャーの利用を支援する方法を確立することでした。Steve Tuecke 氏は当時、ANL の分散型システム研究室で主任ソフトウェア・アーキテクトを務めていましたが、このプロジェクトの発足に立ち合うとともに、Globus Toolkit の主任アーキテクトに任命されました。連邦政府機関および IBM や Microsoft Research などの民間企業からの資金提供を基盤に 9 年間の活動を経た現在では、Globus Toolkit は、既に e-サイエンスにおけるグリッド実装の華々しい成功実績を残しているだけでなく、企業 IT におけるグリッド用のオープン・ソース・ビルディング・ブロックとして、IBM のグリッド戦略における重要な役割を果たしています。
インタビュー
developerWorks:グリッドを構築する前にデベロッパーが最初に考慮に入れる必要のある基本概念には、どのようなものがあるのでしょうか。いくつか挙げていただけますか。
Tuecke:グリッドの構築に関しては、互いに独立した 2 つの課題があります。最初の課題は、多様なアプリケーションとワークロードの処理が可能な共通のインフラストラクチャーを適切に配置する必要性についての検討です。グリッド環境において必要となる基本的なインフラストラクチャー・プロビジョニング機能の一部は、
Globus Resource Allocation Manager (GRAM) および GridFTP のサービスによって提供されます。そのため、多様なワークロードを処理させたいマシン上に Globus GRAM および GridFTP のサービスをインストールすることが、初期の作業手順の 1 つとなります。
そこから今度は、作業対象とするアプリケーションの種類に注目して、どのアプリケーションがグリッド環境に最適であるかを判定する必要があります。ここで私が強調したいのは、デベロッパーはグリッド・アプリケーションとグリッド・インフラストラクチャーとを切り離して考える必要があるということです。Globus Toolkit の目的は、1 つのアプリケーションを取り上げてそれを単純にグリッド・アプリケーションに変えることではありません。種類の異なる複数のアプリケーションをサポートするための共通のインフラストラクチャーを提供することが、その目的です。
企業がグリッド環境用として開発または評価の対象としている一般的なアプリケーションの種類には、以下のような例を挙げることができます。
- 容易に並列化することが可能なアプリケーション -- 例えば金融サービス業界では、リスク分析アプリケーション実行用のグリッド・インフラストラクチャーで多大な成功を収めています。この種のアプリケーションは、通信要件がそれほど多くなく、また、各種ノードと基盤となるデータベースとの間におけるトランザクション上の厳密な一貫性に依存することがないので、グリッド上で非常に有効に機能します。
- データ主導のワークフローを有するアプリケーション -- 複数ソースからのデータ抽出、データ移動、データ変換、データ連結、データ分析、および関係者への結果配布といった複数のステップを必要とするアプリケーションで利用した場合、グリッドは非常に有効に機能します。企業環境においては、ビジネス・インテリジェンスおよびデータウェアハウジングのベンダーからグリッドに熱い注目が集まっています。これは、これらのベンダーのビジネスのすべてが、多数のシステムおよびデータベースにわたって分散している大量のデータを処理することに関連しているからです。
- レガシー・アプリケーション -- 企業は、あらかじめ分散グリッド・インフラストラクチャー上で動作するよう修正された新しいグリッド・アプリケーションを実行する以外に、既存のアプリケーションを分散グリッド・インフラストラクチャー上で動作させることにも関心を抱いています。特定のアプリケーションを特定の IT 資源のセットに縛り付けるのではなく、アプリケーションとインフラストラクチャーとのより柔軟な結び付きが望まれているのです。そうすることによって、アプリケーションの複数インスタンスの管理やフェイルオーバーの処理などが容易にできるからです。
developerWorks:現在グリッド環境で良好な実績を上げているアプリケーションの具体例をいくつか挙げていただけますか。
Tuecke:一例としては、SAP がデベロッパー向けに毎年開催しているコンファレンス TechEd で、昨年同社が実演したアプリケーションが挙げられます。SAP では、「アプリケーション主導のインフラストラクチャー・プロビジョニング」とでも呼べる仕組みの基盤として Globus Toolkit を使用する方法を実演して見せました。別の表現をすると、SAP は、同社の一連のアプリケーションを Globus GRAM サービスを使用するよう修正し、特定の SAP アプリケーションのワークロード需要の変化に応じて、SAP アプリケーション・ソフトウェアが稼働するサーバーを動的に追加したり削除したりするようにしたのです。これによって、複数の SAP アプリケーションが相互間および企業内の他のアプリケーションとの間で、共通のグリッド・インフラストラクチャーを共有することが可能となります。SAP では、同社の多数のアプリケーションがこの方式で Globus Toolkit を使用できるようにしました。具体的には、SAP Advanced Planner and Optimizer、SAP Internet Pricing and Configurator、およびワークフォース管理アプリケーションの一部が Globus Toolkit 対応になっています。
その他の例としては、高スループットのワークロード・マネージャーである
Condor-G を使用する多数の科学計算アプリケーションが挙げられます。Condor では、ジョブのセットを管理して、Condor プールに登録されているマシン上にスケジュールします。Condor-G では、グリッド・インフラストラクチャーの各所に配置されているコンピューター上で Condor サービスを起動する手段として Globus GRAM サービスを使用することにより、必要に応じて Condor プールのサイズを動的に増減することが可能です。これらの Condor サービスは自分自身を Condor プールに接続するので、それによってジョブのスケジューリングに使用できるプールのサイズが増大します。このようにして、Globus GRAM を起動手段として使用することによって、基礎となるグリッド・インフラストラクチャーの上に、この仮想 Condor プールを構築するのです。Condor-G による Globus の使用方法は、SAP による方法とほぼ同じです。この場合も、変動するワークロードを処理するためにオンデマンドでサーバーをプロビジョニングする手段として Globus GRAM を使用するというのが基本的な考え方です。何千個にも及ぶ可能性のある独立したジョブで構成される高スループットのアプリケーションを使用している場合、Condor-G のようなワークロード・マネージャーがあれば、この種のアプリケーションをシステム内で効率的に移動して、妥当な時間内にジョブを完了させることができます。Condor については、最近、Hartford Life (保険会社) でのプロジェクトの成功に関する興味深い記事が公表されています。
Nimrod/G と呼ばれる、オーストラリアで生まれたプロジェクトもあります。これは、多数のジョブを管理するという点で、ある意味では Condor に似たプロジェクトです。しかし、Nimrod/G には特にパラメーター・スタディーの実行に非常に適しているという特長があります。パラメーター・スタディーとは、広い範囲にわたって入力パラメーターを変化させながら単一のプログラムを何回も繰り返して実行しなくてはならないジョブのことです。Nimrod/G は、アプリケーション・テンプレートに対してパラメーター化を定義した上で Globus を使用してグリッド・インフラストラクチャー内の適切なリソース・セット上でジョブを実行するために適したシステムと言えます。
さまざまな科学計算アプリケーションで使用されている GriPhyN プロジェクトの Chimera ソフトウェアは、複雑なデータ主導の分析ワークフローの定義および実行を可能にします。例えば、多くの物理のアプリケーションでは、生データの複雑な処理が必要となります。その生データが分散した複数のソースに由来している場合は、変換および分析の手順を何回も施さなくてはならず、また、他のデータとの連結や比較なども行う必要があります。Chimera では、これらのデータ主導のワークフローを抽象的に記述するグラフを定義できる上、グリッド・インフラストラクチャー上で Globus を使用して、実際のデータに対してそれらのワークフローを実行できます。
developerWorks: 例えば、私がグリッド向けのアプリケーションを作成することを検討していて、新たなセキュリティー上の影響について懸念しているとします。グリッドにおけるソフトウェア・セキュリティー上の新たな課題には、どのようなものがあるのでしょうか。
Tuecke: 1 つのグリッド・インフラストラクチャーを複数のグリッド・アプリケーションで共有する場合、アプリケーション間の分離状態を維持するための、セキュリティー上の新たな問題が生じます。このことは、アプリケーション同士を互いに干渉させることなく多様なアプリケーションをホストするというグリッド・インフラストラクチャーの要点に関係しています。グリッド・インフラストラクチャーを定義する際には、アプリケーション間の適度な分離状態を維持しつつ、物事がグリッド・アプリケーションにとって複雑になり過ぎないようにするために多大な労力を割く必要があります。Globus ではこれが非常にうまくいったために、成功につながりました。私たちは、プロジェクトの初日からセキュリティーの件については非常に真剣に取り組んでいました。この立場は、クラスターのようなしっかりと制御された環境内でプロジェクトを開始する場合に多くの人が取る立場とは正反対のものでした。制御された環境では、「セキュリティーの件については後から対処する」という立場が取られるのが普通なのです。
1 つのクラスター上または単一のドメイン内部で開発されたアプリケーションは通常、マルチドメイン・セキュリティー環境または複数のアプリケーションが資源を奪い合う設定での実行には対応していません。Globus では、実行時にアプリケーション間に必須の隔絶状態を作り出すとともに、アプリケーションが作業の後始末をするためのメカニズムを提供することによって、この問題に対処しました。
Globus で取り扱うセキュリティー・パズルに不可欠なピースとして挙げられるのが、それぞれのドメインが他のドメインに関する知識をあらかじめ必要とすることなく、複数ドメインにわたって分散している各種のアプリケーション・コンポーネントが互いに安全に対話できるようにすることです。セキュリティー環境を動的に構築するというこの考え方は、私たちが Globus で開拓した領域です。例えば、私があるジョブをどこかで実行する場合、セキュリティー証明書持っていく (つまり、そのジョブにセキュリティー証明書を委譲する) 必要があります。こうすることによって、基盤となるインフラストラクチャーに関してほとんど何も仮定せずに、そのジョブと私が開始した他のジョブとの対話が可能となります。これは、何らかの信頼関係、またはあるマシンと別のマシンがグリッド内でともに使用されることになるという事前の知識が必要となるということではありません。そうではなく、私が 1 台のマシン上であるジョブを実行し、さらにその対話相手となるマシン上で別のジョブを実行する場合、既存のセキュリティー関係の上層に重ねる形で、私自身のセキュリティー・ドメインを動的に作り出すのです。このセキュリティー・ドメインにより、両マシン上のジョブが互いに安全に対話できるだけのセキュリティー・コンテキストが実現されます。
ここで指摘しておく必要があるのは、商用グリッドがまだ企業間の境界を越える段階には達していないということです。現在最もよく見られるのは企業内部のグリッド環境であり、この環境での境界は部門間や地域間ということになります。したがって、現在私たちが考えがちなグリッドの性質は、完全に信頼できないコンピューティング環境でグリッドを稼働させようとしている場合とは異なります。
developerWorks: 最近の Globus Toolkit のセキュリティー標準規格に関連した取り組みの中で、この話の流れの中で指摘するのに値するものはありますか。
Tuecke: ありますとも。2004 年の半ばに、私たちは Internet Engineering Task Force (IETF) において、x.509 プロキシー証明書を定義する RFC 3820 を完成しました。この機能は、これまで常に Globus の根底にありました。すなわち、リモートのコンピューター上で何かを実行する必要がある場合、それ以前に実行させている他のものとの対話を可能にするプロキシー証明書をどのように持たせるかという問題があります。例えば、私があるジョブを実行し、そのジョブでリモートの GridFTP サーバーと対話して私のデータの一部を処理対象として取得する必要がある場合、そのジョブは GridFTP サービスの認証を受けて私が所有するデータの読み取り権限を有することを証明できることが必要となります。プロキシー証明書は、この問題に対する解決策の重要な部分を占めます。
Globus のスタッフは、それ以外にも、Security Assertion Markup Language (SAML)、Extensible Access Control Markup Language (XACML)、WS-Security といったセキュリティー関係の多くの標準規格に積極的に取り組んできました。また、Globus Toolkit には、早くからセキュリティー標準規格を採用し支持してきたという実績もあります。例えば、Globus Toolkit V3 は、Web サービス・セキュリティーの標準的アプローチを定義する WS-Security 仕様 (当時はドラフト段階) の最初のオープン・ソース・インプリメンテーションを採用しました。
developerWorks: オープン・ソース・グリッドの特質は、どのような点で独自仕様のものよりもセキュリティーに役立つのでしょうか。
Tuecke: セキュリティーは、絶対に自社独自のアプローチを案出しようと考えてはいけない領域です。当然のことながら、セキュリティーのコミュニティーは、セキュリティー関係の新しいアルゴリズムやプロトコルの開発に関わっている人々に疑いの目を向けます。既存のセキュリティー標準規格がグリッドのセキュリティー要件の一部を満たしていないのは確かなことですが、可能な場合にはなるべく、x.509 や Kerberos といった既存のプロトコルを拡張した方がよいのです (例えば、プロキシー証明書は標準の x.509 証明書を元に少々の変更を加えたものです)。最善のセキュリティー・サービスは、裏でどのような処理が行われているのかが疑われるブラック・ボックスによってではなく、誰もが検証可能なオープン・ソース・インプリメンテーションによって実現されるものです。そのため、Globus Toolkit は、OpenSSL のような幅広く使用されているオープン・ソースのセキュリティー・ソフトウェアをベースにしています。
developerWorks: Liberty Alliance のような ID 管理の取り組みについてはいかがでしょうか。この領域で何かグリッドと関連することはありますか。
Tuecke: 間接的ですが、あります。
Globus Toolkit V4
で、私たちは SAML および XACML の標準規格の初期段階でのサポートをある程度行いました。これらの標準規格は、ID 管理および権限付与の基盤を提供するものですが、同時に Liberty Alliance の基盤でもあります。確かに Liberty Alliance はこの領域においていくつかの興味深いものを提供していますが、この領域はまだ、真の (つまり広く採用される) 標準規格が目指すべき内容について淘汰を繰り返している段階にあると、私は考えています。明らかなことは、SAML がフェデレーテッド ID 管理において重要な役割を演じることになるということです。しかし、SAML は単にアサーションを行うための手段に過ぎないので、SAML を使用する方法はこの他にも多数あります。Liberty Alliance では、SAML の使用方法として、プライバシーを保護しながら複数の組織にわたって ID を確立することとしています。また、高等教育の現場から (Internet2 の取り組みの一環として) 生まれた Shibboleth と呼ばれる別のプロジェクトでは、SAML を別の方法で大学間におけるフェデレーテッド ID 管理用に使用しています。それにより、例えば、学生が別の大学のライブラリーにアクセスすることが可能となります。要点をまとめると、フェデレーテッド ID 管理および権限付与に関連する標準規格については、興味深い活動が数多くあり、一部には新たな合意が形成されている部分もあることは確かですが、先の道のりはまだ長いということです。
developerWorks: それでは、グリッドに関するネットワーク固有の考慮事項についてはいかがでしょうか。より広範なグリッド環境のポリシーへの参加につながるネットワーク・ポリシーを有することについてはどう考えておられますか。
Tuecke: 現在、ネットワークに対する態度としては、必要以上に容量を供給しておき、接続について心配しなくてもいいようにしておくというのが一般的な傾向です。しかし、これはこちら側だけの見方にすぎません。ネットワーク側から見ると考慮すべき事項が 2 つあります。それは、接続性とパフォーマンスに関する問題です。
現在市場に出ているグリッド (分散コンピューティング) ソフトウェアの大部分では、IP レベルで完全な接続性が確立されていることが前提となっています。つまり、2 つのものが対話する必要がある場合には、IP を介していつでも対話可能であると仮定されているわけです。しかし、多くのグリッド環境では、この前提は正しくありません。多くの場合は両者間にファイアウォールや NAT が存在し、パケットの往来を妨害します。グリッドの将来にとって非常に重要なのは、これらのファイアウォールや NAT を取り除くということではなく、こういった要素をグリッドの管理対象であるコンポーネントに変換し、アプリケーションのニーズに基づいて動的に構成したり再構成したりすることを可能にすることであると私たちは確信しています。2 つのジョブ同士を対話させる必要があるにもかかわらず、その両者間にファイアウォールが存在する場合、ファイアウォールと交渉してその 2 つのジョブ同士が (おそらく一定の期間に限って) 対話できるようにしなければなりません。
グリッドがネットワークに及ぼすもう 1 つの影響は、パフォーマンスに関するものです。インターネットおよび IP ネットワークは、少ないトラフィックの多数のフローを非常に太いパイプへと集約する処理を的確に行うよう設計されてきました。つまり、例えば、ネットワークのバックボーン内部の複数の 10GBを超える リンク上で数千ビット単位の Web トラフィックを共有するといった用途向けに設計されてきた、ということです。
一方、IP ネットワークがあまり得意としていないのは、高帯域幅のトラフィックを持続すること (例えば、単一の目的専用として掛け値なしに 10GB/s 以上の帯域幅を維持する必要があるケース) です。
この領域では、Globus は GridFTP に関連するその活動の中で、太いネットワーク・パイプ上で大量のデータを信頼性と安全性に優れた方法で移動することを可能にする技術に関してリーダーの役割を果たしてきました。この種の帯域幅の維持しようとする際に出てくる課題の 1 つとして挙げられるのが、ネットワーク端末にどのようなタイプの、高いデータ転送速度を維持する能力を有するマシンを配置すればよいかということです。答えは、本当のハイエンド・ボックスを購入するか、クラスターに注目し、クラスターの複数のノードを集約することによって希望するパフォーマンスを手に入れるかです。つまり、1 台の高性能コンピューターで 20 GB/s の送信を行う代わりに、それぞれが 1GB/s の送信能力を有するノードが 20 個あればよいというわけです。しかし、1 台のマシンではなく 20 個のノードを使用してデータ転送を管理するためには、より洗練されたプロトコルとソフトウェアが必要となります。この課題は、GridFTP と Globus Toolkit V4 を実装することによって対処できます。
developerWorks: インテリジェンスは、グリッド・インフラストラクチャー、アプリケーション、ネットワークの間のどこにあるのでしょうか。また、その他のものを認識して適宜プロビジョニングを行う責任を持つのはどの要素でしょうか。
Tuecke: インテリジェンスの多くは、インフラストラクチャーの上のワークロード・マネージャー・レベルで管理する必要があります。例えば、データ主導のタスク・グラフを使用するワークロード・マネージャーは、転送を要するデータ、その転送先、帯域幅、期限、および目的 (例 : 大規模な分析の実行) などの実行中の処理に関する知識を持っています。そのワークロード・マネージャーにより、インフラストラクチャーの各コンポーネントに対して要件を (サービス・レベル・アグリーメントのニゴシエーションの形で) 伝えていく必要があると私たちは考えています。アプリケーションのプロビジョニングについては、エンドツーエンドの要件として考える必要があります。つまり、ワークロード・マネージャーが一連のデータをある場所から別の場所に移動する必要がある場合、そのワークロード・マネージャーは、末端の各システムとその間に介在するネットワークと交渉して、データ転送目的でそれらすべてを配列するための同意を得る必要があります。
developerWorks: GlobusWORLD で、参加者の 1 人が、グリッドの話の流れの中ではときおり「データ」と「ストレージ」という用語が明確に区別されずに使用されることがあると指摘していました。グリッド環境にストレージを組み入れることに関して特に課題になるのはどのようなことでしょうか。
Tuecke: 私は、「ストレージ」、「ファイル」、「データベース」の 3 つを明確に区別した方がよいと思います。ただし、「データ」という用語は、「ファイル」と「データベース」の両方を合わせたものの意味として使用されることはあります。「ストレージ」という用語は、ブロック管理の結果や論理装置を意味し、それらを特定のマシン・セットに結び付ける文脈で使用される傾向があります。SAN やファイル・システムを思い浮かべればわかりやすいでしょう。「ファイル」は情報の塊を意味する傾向がありますが、その格納方法はさまざまであり、ファイル・システム内やデータベース内に格納されるだけでなく、プログラムによって直接生成されたり使用されたりする場合もあります。「データベース」は、構造化された特定の形式の情報を意味する傾向があり、多くの場合はその情報に対するトランザクション上の機能が付随しています。これらのものはそれぞれ、グリッドとの関係において異なる問題を抱えています。
この 3 者のうち、Globus が伝統的に主な関心の対象としてきたのがファイルです。つまり、複雑な分散環境における、ファイルの転送、複製、位置特定、およびそれ以外の管理の方法について検討がなされてきました。データ主導のワークロード・マネージャーが必要とする類のファイル管理では、必ずしもデータ (つまりファイル) の移動が必要となるわけではありません。GridFTP は大量のファイル指向のデータをあちこち移動するのに適していますが、ワークロード・マネージャーでは、その代わりに計算の方をデータ側に移動する選択も可能です。
ストレージ・システムは、通常はファイルおよびデータベースのデータを入れる器の役割を果たします。将来的には、各種アプリケーション向けのエンドツーエンドのサービス品質を維持するために、ストレージ・システムに対するワークロード・マネージャーによる管理の必要性が増大していくものと思われます。例えば、ワークロード・マネージャーが 2 つのストレージ・システム間でデータを転送する必要がある場合、理想を言えば、そのワークロード・マネージャーには、両ストレージ・システムと交渉してスペースと帯域幅を確保する能力が必要となります。
developerWorks: グリッドのデベロッパーは、どのようなプログラム言語を使用したらよいでしょうか。
Tuecke: その件については各自の選択に任せるというのが、Globus の見解です。その人にとって最も使いやすく、対象となる問題に最適なものであれば、どのような言語を使用してもかまいません。
ここで、グリッド・アプリケーションとグリッド・インフラストラクチャーとを切り離して考えるという話題に戻って考えてみましょう。どのような環境にインフラストラクチャーが実装されていても、問題ではありません。アプリケーション・レベルでの必要事項に適した言語を選択することが重要です。私たちがこれまで Globus Toolkit に Web サービス機能を組み入れることに力を入れてきたのも、その理由の一部は、GRAM に代表される Globus のインフラストラクチャー・サービスを利用することで、グリッド・アプリケーションがどのような言語で書かれていたとしても、グリッド・アプリケーション間の通信をより容易に行うことが可能になるからです。
パフォーマンス主導の要件があるとか、低レベルのハードウェア・リソースと非常に密接にインターフェースする必要があるといった状況がある場合、通常は C 言語を選択するとよいでしょう。より高レベルのサービスを構築しているのであれば、Java?™ および J2EE のプラットフォームがその目的に適していると思われます。さらに、Globus には優れた Python インターフェースが組み込まれているので、スクリプト記述やプロトタイプ開発の用途が優先されるのであれば、Python がその使用目的に適しているかもしれません。
結局のところ、Globus 対応のインフラストラクチャー内部の任意の資源と対話することは、外部のあらゆる Web サービスと対話することとまったく違いはありません。標準的なプロトコルを使用する限り、対象となるタスクに最適なものであれば、どのようなプログラミング言語で書いたアプリケーションでも実装できるのです。
developerWorks: IBM が Linuxに寄せる関心を踏まえた上で、グリッドにとって望ましい Linux 独自の特性に関してどのようなことが言えるでしょうか。
Tuecke: 私は IBM の立場で発言することはできませんが、IBM が Linux を注視していることは明らかでしょう。ただし、IBM はそれと同時に、AIX、Linux on pSeries、z/OSといったその他多くのプラットフォームにも注意を払っており、その点は私たちも同様です。ここでの重要なメッセージは、Globus Toolkit はプラットフォームに左右されないということです。グリッドとは、大きな異機種混合環境に組み入れることができる、共通インフラストラクチャーおよび共通プロトコルを提供することです。ここでいいたいのは、グリッドはたった 1 つのプラットフォームに縛られるものではないということです。
developerWorks: それでは、メインフレームがグリッド環境に参加する方策はあるのでしょうか。
Tuecke: もちろん、あります。企業における多くの重要なデータおよびアプリケーションは、メインフレームに置かれています。約 3 年半前、Globus と IBM は共同作業を開始しましたが、そのとき IBM 側の責任者だったのが、生粋のメインフレーム専門家で後に IBM の e-ビジネス・オンデマンド担当 CTO になった Jeff Nick 氏でした。私たちが彼に出会った当時、彼は Web サービスを使用してメインフレームをより広範な分散環境に組み入れる方法を探していました。メインフレームはそのシステム内部では非常に質の高いサービス制御機能を有していますが、孤立したままでは次第にやっていけなくなってきたため、Linux や Windows が稼働するサーバーやそれ以外のあらゆる種類の要素と連動せざるを得なくなっています。Nick 氏が当時直面していた問題は、私たちが Globus で取り組んでいたグリッドの問題と根本的には同じものでした。すなわち、メインフレームとその他のサーバーとをカバーする必要のある各種アプリケーションについてエンドツーエンドのサービス品質を維持するために、分散環境全体を 1 つに連結する方法が問題だったのです。
 |
Globus Consortium
HP, IBM, Intel, and Sun Microsystems recently announced the formation of The Globus Consortium, a new industry group dedicated to advancing the development and adoption of the Globus Toolkit in commercial settings.
|
|
参考文献
著者について | 
| | Travis Van is a tech PR flack in Silicon Valley focusing on emerging technologies.
|
記事の評価
| 
