IBM®
本文へジャンプ
    Japan [変更]    ご利用条件
 
 
検索範囲検索:    
    ホーム    製品    サービス & ソリューション    サポート & ダウンロード    マイアカウント    
skip to main content

developerWorks Japan  >  Grid computing  >

グリッドの展望: 全体は、部分の合計よりも大きい

グリッド・コンピューティングを構成する部品を、どのように統合すべきでしょうか。

developerWorks
ページオプション

JavaScript を要するドキュメントオプションは表示されません

原文はこちら

原文はこちら


レベル: 初級

Matt Haynos (mph@us.ibm.com), Program Director, Grid Technology and Strategy, IBM

2005年 9月 06日

技術的な観点からグリッドを構成しているものを見ると、グリッドの概念をある視点からとらえることができます。この記事では、グリッド・コンピューティングを技術的な観点から明確にすることを目指し、その背後にあるテクノロジーに対する全体論的な見方を提供します。

ベンダーやアナリストらはこれまで、グリッド・コンピューティングについて把握したり定義をしようと多大な努力を重ねてきました。実際、グリッド的と称する製品は枚挙にいとまがありません。プラスの ROIや競争上の優位性を獲得した組織にとっては、グリッド・コンピューティングの正確な理解や定義にこだわったり、立ち止まったりすることはないでしょう。

しかし、グリッドに取組みはじめたばかりの組織や、グリッドが自分たちに役に立つかもしれないと考えている組織にとっては、しっかりした概念を理解することは有益です。幸いなことに、より技術的な観点からグリッドを眺めれば、その理解はより容易になります。ビットやバイトが支配する技術分野ではしばしばこのことが当てはまりますが、グリッドを巡る大げさな宣伝(hype)に対し、このような文脈から理解して、ある種の視点を持つことは特に有益です。

グリッドを理解するための鍵

グリッドが何かということが誤解されやすいのは、「グリッド・ソリューション環境をかたちづくるには連携して機能すべき数多くのテクノロジーが必要である」という単純な理由によります。グリッド・コンピューティングでは、複数の機能分野にまたがるさまざまな能力の相互動作が行われます。これは、グリッド・ベンダーのさまざまなマーケティング・メッセージを理解しにくいものにし、時にはグリッドが他のイニシアチブ (ユーティリティー・コンピューティングなど) と頻繁に混同される原因ともなります。

重要なのは、全体像を捉えることです。グリッド・ソリューションのすべてのコンポーネントを最初からインストールしたり構築したりする必要はありません。小規模なグリッドを導入して経験を積み、その価値を現実のものにしてから、テクノロジーを逐次追加していけば、グリッド・インフラストラクチャーの高度化と能力全体を拡張していくことができます。

このような理由から、グリッドの継続的拡張には、標準が重要な役割を果たします。標準はさまざまなコンポーネント間の相互運用性を確保し、ベンダーに、より高いレベルの価値をもつ実装を提供することに集中させます。グリッドが本来持つ、グリッド・ソリューション・フレームワーク全体に適用される標準がなければ、ユーザーは、モジュラー的な調整されたやり方でグリッド環境に段階的に機能を追加することはできません。グリッドや Web サービスに関する標準が成熟し続ける中、組織がこういった標準の位置付けや、組織が採用を検討するさまざまなベンダーの戦略を把握することは、極めて重要です。

このことは一見容易に思われるかもしれませんが、甘い見通しは禁物です。然るべき情報をベンダーに要求し、現時点での標準の実装と進化し続ける標準へのコミットへの適切なバランスを定めてください。このバランスを調整できなければ、柔軟性を減らし、将来にわたって最も優れた能力を統合していく選択肢を狭めることになります。

このシリーズの以前の記事である「グリッドの展望: グリッド・インフラストラクチャー内での自動化の効果的な使用」では、グリッド・テクノロジーと、プロビジョニングやオーケストレーションといった自動化テクノロジーとの間に存在する、必然的な共生関係を検討しました。今回の記事では少し視点を広げて、グリッド・コンピューティングを技術的な観点から明確にすることを目標に、その背後にあるテクノロジーを全体論的に眺めてみることにします。




上に戻る


グリッド・コンピューティングに対する全体論的な視座

動的プロビジョニングとそのジョブ・スケジューリングに対する関係は、需要と供給の観点からグリッド・コンピューティングを理解する上での重要な概念です。この概念は、ハイレベルで捉えたときに、グリッドとは一体何かについての適切な見方を示しています: すなわち、アプリケーションやユーザーからのリクエストに合わせてリソースのマッチングと最適化をすることを意味します。リクエストは、作業の要求(たとえば、「このジョブを実行してください」) であったり、情報の要求 (「この情報がほしい」) であったりします。リクエストの送信元は、ユーザーのこともありますし、アプリケーションからのプログラム的なものである場合もあります。

このような作業、情報、資源のマッチングと最適化を、動的なコンピューティング・システム内で行うことは、実際には容易なことではありません。業界では、これを達成するために、より高度なアルゴリズムや技術を開発し続けています。幸いなのは、オペレーションズ・リサーチの分野における永年の研究と経験を援用することができることです(製造ラインの最適化はその好例です)。

しかし、グリッドはこれだけではありません。「需要と供給」という比喩は「資源を仮想化/抽象化する能力」を表したものであり、この仮想化が、グリッド・コンピューティングの基本となる概念なのです。グリッドを正しく理解するには、この基本概念を理解する必要があります。図 1 は、グリッド・コンピューティングのコンポーネントを示しています。


図 1. グリッド・コンピューティングのコンポーネント
図 1. グリッド・コンピューティングのコンポーネント

資源は、物理的なものと論理的なものがあります。システムやストレージの仮想化では、物理的な資源 (コンピューターとストレージ) を論理的なエンティティーにマップします。

仮想化では、単一資源から複数資源へのマッピングも、複数資源から単一資源へのマッピングも可能です。どちらの方向も仮想化です。例えば、Xen や VMware といったシステム仮想化製品は、単一のマシンを複数のエンティティーにパーティショニングします。一方、IBM の SAN ボリューム・コントローラなどのストレージ仮想化製品は、複数のディスク・ストレージ・システムのキャパシティーを単一のストレージ・プールに統合して中央から管理できます。このように、両方の方向が考えられるわけです。

さらに、グリッドと考えるべきものの中心は、単なるシステムやストレージの仮想化ではなく、本当はワークロードと情報の仮想化です。ワークロードと情報の仮想化が共に働くことが、システムとストレージの仮想化という概念を広げていくのです。これが、グリッドを技術的観点から理解する上での柱となります。これについては、後に詳しく説明します。

前述のように、ワークロードと情報の仮想化は、IBM Tivoli® Provisioning Manager や Opsware Inc の Opsware といったプロビジョニング・テクノロジーと連動して機能します。つまり、プロビジョニングはグリッド・コンピューティングにとって不可欠なのです。また、グリッドとは資源そのものに関わる (資源の活用や仮想化) ものですから、共通の資源モデルや資源管理はグリッドの中核をなすものです。

要約すれば、グリッドを四つの機能(能力)分野の相互動作と見なすことができるでしょう。すなわち、

  • ワークロードの仮想化
  • 情報の仮想化
  • 資源管理/資源の共通化された表現方法
  • プロビジョニングとオーケストレーション

これら 四つのカテゴリー、それぞれの特性、および相互のやりとりが、技術的観点からのグリッドの定義となります。それでは次に、各カテゴリーがどのようなものかを把握するため、詳細に進みましょう。

さらに資源の定義と管理がグリッドにとって果たす重要な役割についても説明します。読者の皆さんは今、セキュリティーやアクセス (例えばポータル) といった他のテクノロジーの役割もお考えになったかもしれません。これらの分野は重要で、その重要性を否定するつもりはないのですが、これらの分野はグリッド・コンピューティングの特徴を定義しようとするものとは考えらません。それらは、多くの分散コンピューティング・ソリューションに含まれており、グリッドの技術的な理解のための基礎的な、あるいはグリッドに特有の特徴ではないからです。




上に戻る


共通の資源モデルと資源管理

以前の記事で、「グリッドは、資源とは何かという考え方を拡張しつつある」ということを指摘しました。従来、資源といえばマイクロプロセッサーやストレージのようなものとして認識されてきました。当時はそれだけシンプルだったのです。しかし、資源の活用に重点を置くグリッドに関わる業界や一般の(IT)業界により、このシンプルな概念は拡張され、ソフトウェア・ライセンスやネットワーク・デバイス (VLAN など) も含まれるようになりました。つまり、資源 -- その定義と管理 -- は、グリッド・コンピューティングとは何に関するものかということについての基本的要素なのです。

「グリッドでは、作業の実行や情報に対する要求は、複数の異なった種類の資源にまたがって処理されるのがごく普通のことである」ということを思い起こしてください。そうすれば、資源がどのように見えるかに関する共通のとらえ方を持つことの重要性がお分かりになると思います。グリッド内のあらゆる資源がそれぞれの特性と機能を別々の方法で表現するとしたら、それらのそれぞれと相互にやりとりすることなど、悪夢ですから。

幸いなことに、そういった状況にはなっていません。「共通情報モデル (CIM)」と称される業界標準が、Distributed Management Task Force (DMTF) の主導により具体化しつつあるからです。CIM 標準には次のように述べられています。「CIM は、システム・ネットワーク・アプリケーションおよびサービスに関する管理情報の共通の定義を提供し、ベンダーの拡張を許容する。CIM の共通定義があれば、ベンダーは、多彩なセマンティックを持つ管理情報をネットワークを通じて、システム間で交換できる。」

また、CIM と違った角度から定義された標準として「Web Services Distributed Management (WSDM)」と呼ばれるものもあり、これはOASIS 内で策定作業が進められています。仮にCIM を下位の情報のモデルだと言うならば、WSDM は資源管理方式の定義と言えるでしょう。WSDM は 2 つの主な仕様、すなわち Management Using Web Services (MUWS) と Management of Web Services から構成されますが、その詳細については、ここでは触れません。

資源に関して、最後にもう 1 点説明します。グリッド・システムでは、柔軟性の向上を考慮しながら資源を表現する必要があります。グリッド内にあるコンポーネントによって使用される下位の資源モデルには、使用される資源の定義を変更したり新たな種類の資源を定義したりできるような抽象性が求められます。グリッド・ソフトウェアは、一貫した方法で (そのために CIM が活用されます)、資源の定義や種類に依存することなく資源を扱う必要があります。今日このようなことを想像することは困難かもしれませんが、将来新たな種類の IT 資源が登場し、それに対する定義と対応が必要となることは想像していただけるでしょう。




上に戻る


プロビジョニングとオーケストレーション

広範な資源を必要な場所に必要な時に動的にプロビジョニングする機能は、グリッドに不可欠な能力です。この能力は、Tivoli Intelligent Orchestrator や Cassatt Collage といったインテリジェントなプロビジョニング・システムによって提供されます。この詳細はこのシリーズの以前の記事で議論しましたから、ここでは、グリッドと私たちが考えるものが持つ必要な能力の定義として動的プロビジョニングを取り上げる以上の詳細には立ち入りません。今後の記事では、真のオートノミック資源管理を実現する段階的アプローチについて概説します。




上に戻る


ワークロードの仮想化

多くの人にとって、グリッドは「大規模な分散環境でワークロードを加速、管理する能力」と考えられています。これはしばしばコンピューティング・グリッドと呼ばれています。幅広い資源を活用して(多くの場合は並行処理によって)大幅にワークロードを加速した企業の事例が、頻繁に報道されています。このような事例は重要でグリッドへの関心を高めることになりましたが、より重要な検討事項があります。

1 つは、ワークロードをインテリジェントに管理することです。ジョブの実行には、並行処理よりも多くのことが含まれます。アプリケーション (またはアプリケーション・セット) を並列化せずとも利点を得ることはできます。より高いレベルを目指すには、すべてのワークロードをインテリジェントな方法で管理する必要があります。これを、ワークロードの仮想化と呼びます。

ワークロードの仮想化とは、ワークロードを仮想化し、動的な IT インフラストラクチャー上で細かく分割したり、移動したりできるようにする能力のことです。その中核は、動的なスケジューリング、作業の資源へのルーティング、作業のキャパシティーへのルーティングに関わっています。

これは、ワークロードとその実行に用いられるインフラストラクチャーとの間で事前に想定されるあらゆる依存関係を分離することを意味します。動的プロビジョニングが「動的」なのは、実行環境の構成を管理する責任を担っているからです(供給側)。また、動的なスケジューリングとワークロードの仮想化は、適切な資源を用いて適切なときにインテリジェントにワークロードを実行するという役割を担っています (需要側)。スケジューラーの開始後にワークロードを移動しなければならない可能性もあります。IBM の Enterprise Workload Manager のようなワークロード・マネージャーはこの構図から必要とされます、なぜなら、ワークロード・マネージャーはスケジューラーがジョブを開始させた後に必要に応じてワークロードを移動させる責任を持つからです。しかし、最初にジョブをスタートさせたり配置するのは、ジョブ・スケジューラーの役割です。

仮想化あるいはスケール・アウト・アーキテクチャーは人々の関心を集め続けていますが、それにつれて、スケジューラーは、個々のシステムに存在するものから、ミドルウェアとしての位置づけを得て、次いでネットワーク内に存在するものへとその場所を移動してきました。あまり意識されることはないものの、PC オペレーティング・システム (多くの人にとってはMicrosoft® Windows®) のスケジューラーは PC の中枢で、極めて重要な要素です。しかし普段はそれを目にしたり、その存在を意識したりすることはありません。

スケジューラーの役割は、作業をバックグラウンドで実行し、確実に完了させ、しかもユーザーが使っているPCの応答性を確保することです。この点を理解していただくと、ワークロードの仮想化と動的スケジューリングがグリッド・コンピューティングにとってどれほど重要かをご理解いただけることでしょう。




上に戻る


情報の仮想化

ワークロードの仮想化に比べると、グリッド環境における情報の仮想化は非常に先進的な考え方です。分散グリッド環境では、統一性のある一貫した方法でデータを参照、アクセス、管理できるようにすることが、コラボレーションの改善とそれから導かれる生産性の向上の鍵となる原動力となります。

グリッドは、企業間のデータの統合に向けて機能を進歩させています。コンピューティング・グリッドと対比して、データ・グリッドについてもしばしば言及されますが、ある意味では、この 2つを分離してしまったら全く意味はありません。真の利点は、情報の普遍性(ユビキティー)という概念とワークロードの仮想化をシームレスに結合することができたときに得られるのです。これは簡単ではありませんが、実現できるものです。

情報の仮想化とは、企業全体からデータを取得し、変換し、連合(フェデレーション)し、、サービス品質要件をユーザーやアプリケーションに適合させることです。グリッド全体にわたって、ユーザーやデータが(ファイルまたはバイト・ストリームのような)望む形式で、しかもあたかもそれがローカルのデータであるかのように(勿論、しかも安全に)、情報にアクセスできるのです。

このようなデータの局所性は重要な要素です。あらゆるデータがローカルにあるわけではありませんが、私たちはローカルでないデータをも「ローカルにあるかのように」見なしたいのです。このため、業界ではアプリケーション間キャッシングや広域ファイル・システムといったインテリジェントなデータ管理テクノロジーによってこれを推進しようとしています。

このようなデータに対する見方を支えるさまざまな技術や機能には、ストレージの仮想化、ファイル・ベースの仮想化、さらにはWebSphere® Information Integrator などの製品が提供するデータの仮想化などがあります。これらのもともとは別々だった世界が 1 つに集結し始めているということは興味深い傾向です。リレーショナル・データベースなどのデータの形式とそのアクセス・プロトコル (SQL など) との固定された関係を考えてみてください。また、その関係をサポートするインフラストラクチャーへの投資について検討してみてください。リレーショナル・データベースに格納されている情報には SQL や XQL 以外のアクセス・プロトコルでアクセスできないというのはなぜなのでしょう、ミドルウェアが相違点を覆い隠してくれるべきではないでしょうか。なぜ、アプリケーションやユーザーが、アクセスする情報の構造を認識していなければならないのでしょうか。




上に戻る


まとめ

この記事では、グリッド・コンピューティングの構成要素を「仮想化」と「4つの分野の統合」という観点から概説しました。4つの分野とは、ワークロードの仮想化、情報の仮想化、資源の定義と管理、およびインテリジェントなプロビジョニングです。

この 4 分野の機能 (能力)分野を調和のとれた方法で組み合わせることが、グリッドの考え方を定義します。組織は、さまざまな製品の中から最適なものを選択し、グリッド・インフラストラクチャーを継続的に組み上げていくことができます。

このシナリオでは、統合を実現していき、選択の柔軟性を得るために標準が不可欠です。代替選択肢としては、WebSphere Extended Deployment などの統合プラットフォームを購入するという方法があります。この製品には、この記事で取り上げたテクノロジーと能力の多くが搭載されています。



参考文献



著者について

author

Matt Haynos is a program director on the IBM Grid Technology and Strategy team, based in Somers, N.Y. He has various responsibilities on the team covering a broad range of initiatives related to building the IBM grid computing business. He has held a variety of technical and managerial positions within IBM in the application development, program direction, and business development areas. He holds a bachelor's degree in computer science/applied mathematics and cognitive science from the University of Rochester, and a master's degree in computer science from the University of Vermont. He lives with his wife and two sons in Connecticut.




記事の評価


サイト改善のため、ご意見をお寄せください。こちらのフォームからお願いいたします。



はいいいえわからない
 


 


54321
大変素晴らしい不充分・不完全である
 


上に戻る


    日本IBMについて プライバシー お問い合わせ