(57)【要約】【課題】  分散Ｗｅｂサービスのコンテキストにおけるオートノミック・フェイルオーバを管理するように構成されたシステム、方法、および装置を提供することにある。【解決手段】  オートノミック・フェイルオーバのために構成されたグリッド・コーディネータは、サービス・グリッド内の複数のグリッド・ホストに通信可能にリンクされたモニターを含むことができる。メトリックス・ストアは、モニターに結合し、グリッド・ホスト内の個々のサービス・インスタンスに関するサービス・メトリックスを保管するように構成することができる。最適化ロジックは、障害のあるグリッド・ホスト内の１組のサービス・インスタンスに関して保管されたメトリックスと提案された交換グリッド・ホストに関して決定されたプラットフォーム・メトリックスとの間の最良適合を計算するようにプログラミングすることができる。最後に、フェイルオーバ・プロセッサは、最適化ロジック内で計算された最良適合により障害のあるグリッド・ホスト内の１組のサービス・インスタンスを交換するために提案された交換グリッド・ホスト内で新しい１組のサービス・インスタンスを作成するためにモニターおよび最適化ロジックに結合され、グリッド・ホストに通信可能にリンクすることができる。【選択図】  図１
2007500908.tif 000002
【特許請求の範囲】
【請求項１】
ノード内のサービス・インスタンスに関するメトリックスを収集するステップと、前記ノード内の障害を検出するステップと、前記障害を検出したときに、１組の交換ノードを突き止め、前記交換ノードのそれぞれに関するプラットフォーム・メトリックスを決定するステップと、収集された前記メトリックスおよび前記プラットフォーム・メトリックスに基づいて前記交換ノードのうちの最適に選択されたノードにおいて新しい交換サービス・インスタンスを作成するステップとを有する、オートノミック・フェイルオーバのための方法。
【請求項２】
前記メトリックスが、グリッド・ホスト内で消費されるリソース、好ましいオペレーティング・システム・プラットフォーム、グリッド・ホスト内で必要な最小リソース、グリッド・ホスト内での消費のために使用可能な好ましいリソースからなるグループから選択された少なくとも１つのメトリックを有する、請求項１に記載の方法。
【請求項３】
前記メトリックスが、パフォーマンス単位当たりのコスト、リソース消費単位当たりのコスト、パフォーマンス単位当たりの収益、およびリソース消費単位当たりの収益からなるグループから選択された少なくとも１つのメトリックをさらに有する、請求項２に記載の方法。
【請求項４】
前記作成ステップが、新しい交換サービス・インスタンスを作成するための最適交換ノードを識別するために、収集された前記メトリックスと前記プラットフォーム・メトリックスとの間で最良適合分析を実行するステップと、識別された前記最適交換ノードで新しい交換サービス・インスタンスを作成するステップとを有する、請求項１に記載の方法。
【請求項５】
前記作成ステップが、最適交換ノード内の既存のサービス・インスタンスに関するメトリックスをさらに収集するステップと、前記最適交換ノードに関して収集された前記メトリックスおよびさらに収集された前記メトリックスの両方と前記プラットフォーム・メトリックスとの間で最良適合分析を実行するステップと、前記既存のサービス・インスタンスの一部分と共存するために前記最適交換ノード内で１組の新しい交換サービス・インスタンスを作成するステップであって、前記１組の新しい交換サービス・インスタンスと前記既存のサービス・インスタンスの前記一部分が前記最適交換ノード内で最適に結合されるように計算されるステップと、前記既存のサービス・インスタンスのうちの他のインスタンスを他の交換ノードに変位し、残りの１組の新しい交換サービス・インスタンスを前記他の交換ノード内で作成するステップとを有する、請求項１に記載の方法。
【請求項６】
前記作成ステップが、最適交換ノード内の既存のサービス・インスタンスに関するメトリックスをさらに収集するステップと、パフォーマンス単位当たりのコスト、リソース消費単位当たりのコスト、パフォーマンス単位当たりの収益、およびリソース消費単位当たりの収益からなるグループから選択された少なくとも１つのメトリックを加重しながら、前記最適交換ノードに関して収集された前記メトリックスおよびさらに収集された前記メトリックスの両方と前記プラットフォーム・メトリックスとの間で最良適合分析を実行するステップと、前記既存のサービス・インスタンスの一部分と共存するために前記最適交換ノード内で１組の新しい交換サービス・インスタンスを作成するステップであって、前記１組の新しい交換サービス・インスタンスと前記既存のサービス・インスタンスの前記一部分が加重された前記少なくとも１つのメトリックにより前記最適交換ノード内で最適に結合されるように計算されるステップと、前記既存のサービス・インスタンスのうちの他のインスタンスを他の交換ノードに変位し、残りの１組の新しい交換サービス・インスタンスを前記他の交換ノード内で作成するステップとを有する、請求項３に記載の方法。
【請求項７】
サービス・グリッド内の複数のグリッド・ホストに通信可能にリンクされたモニターと、前記モニターに結合され、前記グリッド・ホスト内の個々のサービス・インスタンスに関するサービス・メトリックスを保管するように構成されたメトリックス・ストアと、障害のあるグリッド・ホスト内の１組のサービス・インスタンスに関して保管されたメトリックスと提案された交換グリッド・ホストに関して決定されたプラットフォーム・メトリックスとの間の最良適合を計算するようにプログラミングされた最適化ロジックと、前記最適化ロジック内で計算された前記最良適合により前記障害のあるグリッド・ホスト内の前記１組のサービス・インスタンスを交換するために前記提案された交換グリッド・ホスト内で新しい１組のサービス・インスタンスを作成するために前記モニターおよび前記最適化ロジックに結合され、前記グリッド・ホストに通信可能にリンクされたフェイルオーバ・プロセッサとを有するグリッド・コーディネータ。
【請求項８】
前記モニターが前記グリッド・ホスト内に配置された複数の連携モニター・プロセスを有し、前記連携モニター・プロセスのそれぞれが、対応するグリッド・ホストの状態を前記フェイルオーバ・プロセッサに報告するための構成を有する、請求項７に記載のグリッド・コーディネータ。
【請求項９】
オートノミック・フェイルオーバを管理するためのコンピュータ・プログラムがそこに保管されているマシン可読ストレージにおいて、前記コンピュータ・プログラムが、ノード内のサービス・インスタンスに関するメトリックスを収集するステップと、前記ノード内の障害を検出するステップと、前記障害を検出したときに、１組の交換ノードを突き止め、前記交換ノードのそれぞれに関するプラットフォーム・メトリックスを決定するステップと、収集された前記メトリックスおよび前記プラットフォーム・メトリックスに基づいて前記交換ノードのうちの最適に選択されたノードにおいて新しい交換サービス・インスタンスを作成するステップとを前記マシンに実行させるための複数命令のルーチン・セットを有するマシン可読ストレージ。
【請求項１０】
プログラムがコンピュータ上で実行されたときに請求項１ないし６のいずれかに記載の方法を実行するように適合されたプログラム・コード手段を有するコンピュータ・プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、Ｗｅｂサービスを含む分散コンピューティングの分野に関し、詳細には、分散Ｗｅｂサービスのコンテキストにおけるオートノミック・フェイルオーバの管理に関する。
【背景技術】
【０００２】
Ｗｅｂサービスは、分散コンピューティングの最先端を表し、ワールド・ワイド・ウェブによるコンポーネントベースのアプリケーションの急速な発展をサポートするための真に普遍的なモデルを開発するための基礎と見なされている。Ｗｅｂサービスは、サービス指向でコンポーネントベースのアプリケーション・アーキテクチャを記述する多量の新生規格を含むものとして当技術分野では知られている。具体的には、Ｗｅｂサービスは、別個の機能を意味論的にカプセル化する疎結合で再使用可能なソフトウェア・コンポーネントであり、標準のインターネット・プロトコルにより分散され、プログラマブルにアクセス可能である。
【０００３】
概念的には、Ｗｅｂサービスは、プロセス内の別個のタスクがバリュー・ネット（value net）全域にわたって広く分散されるモデルを表している。とりわけ、多くの業界専門家は、サービス指向のＷｅｂサービス・イニシアチブをインターネットの次の発展フェーズであると考えている。概して、Ｗｅｂサービスは、Ｗｅｂサービス記述言語（ＷＳＤＬ：Web services definition language）などのインターフェースによって定義することができ、このインターフェースにより実現することができるが、その実現例がＷｅｂサービス・インターフェースに適合する限り、実現例の詳細はほとんど重要ではない。対応するインターフェースによりＷｅｂサービスが実現されると、その実現例は、当技術分野で周知の通り、Ｕｎｉｖｅｒｓａｌ  Ｄｅｓｃｒｉｐｔｉｏｎ，  Ｄｉｓｃｏｖｅｒｙ  ａｎｄ  Ｉｎｔｅｇｒａｔｉｏｎ（ＵＤＤＩ）などのＷｅｂサービス・レジストリに登録することができる。登録すると、Ｗｅｂサービスは、たとえば、シンプル・オブジェクト・アクセス・プロトコル（ＳＯＡＰ）を含む任意のサポート・メッセージング・プロトコルの使用によりサービス要求側からアクセスすることができる。
【０００４】
Ｗｅｂサービスをサポートするサービス指向のアプリケーション環境では、あるアプリケーションの目標を満たすために高信頼サービスを突き止め、その高信頼サービスをリアルタイムで動的に統合することは問題があると分かっている。レジストリ、ディレクトリ、およびディスカバリ・プロトコル（discovery protocol）はサービス検出およびサービス間相互接続ロジックを実現するための基本構造を提供するが、レジストリ、ディレクトリ、およびディスカバリ・プロトコルのみでは分散相互運用性に適していない。むしろ、統一アプリケーションの構成におけるＷｅｂサービスの分散を容易にするために、より構造化され形式化されたメカニズムが必要である可能性がある。
【０００５】
とりわけ、Ｏｐｅｎ  Ｇｒｉｄ  Ｓｅｒｖｉｃｅｓ  Ａｒｃｈｉｔｅｃｔｕｒｅ（ＯＧＳＡ）によるグリッド・メカニズムの生理学（physiology）は、本来はレジストリ、ディレクトリ、およびディスカバリ・プロトコルの排他使用では可能にならないようなやり方で分散システム全域で以下で「グリッド・サービス」と呼ばれるＷｅｂサービスのディスカバリならびにバインディングのいずれにおいてもプロトコルを提供することができる。２００１年にＩｎｔｌ  Ｊ．  Ｓｕｐｅｒｃｏｍｐｕｔｅｒ  Ａｐｐｌｉｃａｔｉｏｎｓより発行されたＩａｎ  Ｆｏｓｔｅｒ、Ｃａｒｌ  Ｋｅｓｓｅｌｍａｎ、およびＳｔｅｖｅｎ  Ｔｕｅｃｋｅによる「Ｔｈｅ  Ａｎａｔｏｍｙ  ｏｆ  ｔｈｅ  Ｇｒｉｄ」ならびに２００２年６月２２日にＧｌｏｂｕｓ．ｏｒｇより発行されたＩａｎ  Ｆｏｓｔｅｒ、Ｃａｒｌ  Ｋｅｓｓｅｌｍａｎ、Ｊｅｆｆｒｅｙ  Ｍ．  Ｎｉｃｋ、およびＳｔｅｖｅｎ  Ｔｕｅｃｋｅによる「Ｔｈｅ  Ｐｈｙｓｉｏｌｏｇｙ  ｏｆ  ｔｈｅ  Ｇｒｉｄ」の両方に記載されている通り、グリッド・メカニズムは、クライアントに要求することによりグリッド・サービス・インスタンスを作成し、命名し、発見することができる分散コンピューティング・インフラストラクチャを提供することができる。
【０００６】
グリッド・サービスは、拡張リソース共用およびスケジューリング・サポート、精巧な分散アプリケーションによって一般に必要とされる持続する状態のサポート、ならびにエンタープライズ間コラボレーションのサポートを提供することにより、単なるＷｅｂサービスを拡張する。その上、Ｗｅｂサービスは永続的サービスのディスカバリおよび呼出しに対処するが、グリッド・サービスは、動的に作成し破壊することができる一時的サービス・インスタンスをサポートする。グリッド・サービスを使用することの顕著な恩恵としては、コンピューティング・リソースの使用効率が高まったことによる情報技術の所有権のコストの低減と、様々なコンピューティング・コンポーネントの統合しやすさの改善を含むことができる。したがって、グリッド・メカニズム、特に、ＯＧＳＡに適合するグリッド・メカニズムは、組織ドメイン全域でも、分散システム統合の基礎を提供できるサービス指向アーキテクチャを実現することができる。
【０００７】
サービス・グリッド内で、サービス提供インフラストラクチャは、グリッド・サービスなどの分散サービスの実行をホストとして処理するための処理リソースを提供することができる。サービス提供インフラストラクチャは、サーバ・コンピューティング・デバイスと、直接付加ストレージ、ネットワーク付加ストレージ、ストレージ・エリア・ネットワークを含むストレージ・システムと、処理および通信帯域幅などを含む、１組のリソースを含むことができる。サービス提供インフラストラクチャ内で処理される個々のトランザクションは、これらのリソースの異なる組合せを消費する可能性がある。
【０００８】
とりわけ、ＯＧＳＡは、サービス・グリッド内の１つまたは複数の変動位置にサービス・インスタンスを配備することができるアーキテクチャを定義する。これに対応して、特定のサービスのインスタンスにアクセスするためのクライアント要求は、その要求に関する特定のサービスの最適インスタンスであると見なされるものに経路指定することができる。そのために、個々のサービス・インスタンスは、最適化基準に基づいて戦略的にサービス・グリッド内の異なるノードに複製することができる。この最適化基準は概して、特定のリソースにアクセスできるノード、他の重要なサービス・インスタンスと同じ場所に配置されているサービス・インスタンスを有するノード、特定のクライアントに関する局所性などになる可能性がある。
【非特許文献１】２００１年にＩｎｔｌ  Ｊ．  Ｓｕｐｅｒｃｏｍｐｕｔｅｒ  Ａｐｐｌｉｃａｔｉｏｎｓより発行されたＩａｎ  Ｆｏｓｔｅｒ、Ｃａｒｌ  Ｋｅｓｓｅｌｍａｎ、およびＳｔｅｖｅｎ  Ｔｕｅｃｋｅによる「Ｔｈｅ  Ａｎａｔｏｍｙ  ｏｆ  ｔｈｅ  Ｇｒｉｄ」
【非特許文献２】２００２年６月２２日にＧｌｏｂｕｓ．ｏｒｇより発行されたＩａｎ  Ｆｏｓｔｅｒ、Ｃａｒｌ  Ｋｅｓｓｅｌｍａｎ、Ｊｅｆｆｒｅｙ  Ｍ．  Ｎｉｃｋ、およびＳｔｅｖｅｎ  Ｔｕｅｃｋｅによる「Ｔｈｅ  Ｐｈｙｓｉｏｌｏｇｙ  ｏｆ  ｔｈｅ  Ｇｒｉｄ」
【非特許文献３】２００２年１月２９日にＧｌｏｂｕｓ  Ｔｕｔｏｒｉａｌ，  Ａｒｇｏｎｎｅ  Ｎａｔｉｏｎａｌ  Ｌａｂｏｒａｔｏｒｙより発行されたグローバス・プロジェクトの「Ｇｌｏｂｕｓ  Ｔｏｏｌｋｉｔ  Ｆｕｔｕｒｅｓ：    Ａｎ  Ｏｐｅｎ  Ｇｒｉｄ  Ｓｅｒｖｉｃｅｓ  Ａｒｃｈｉｔｅｃｔｕｒｅ」
【発明の開示】
【発明が解決しようとする課題】
【０００９】
どんな理由でもサービス・グリッド内のサービス・インスタンスまたはサービス・インスタンスをホストとして処理するノードに障害が発生すると、フェイルオーバ戦略がサービス・グリッドの動作の重要なアスペクトになる可能性がある。これに関して、サービス・グリッド内のノードまたはサービス・インスタンスで障害が検出された場合、障害のあるノード内のサービス・インスタンス内のサービス機能にアクセスするための後続要求が所望のサービスの他のインスタンスに対してサービス・グリッド内の他の場所に再経路指定されることは、避けられない可能性がある。重要なことに、このような再経路指定は、サービス・グリッドの仮想組織アスペクトを妨げないように透過的に行わなければならない。それにもかかわらず、フェイルオーバ再経路指定は当技術分野で知られているが、サービス・グリッド内の障害のあるサービス・インスタンスの再配備にはほとんど注意が払われていなかった。
【００１０】
好ましくは、本発明は、Ｗｅｂサービスとグリッド・サービス（特にグリッド・サービス・フェイルオーバ）とを含む分散コンピューティングに関する。
【課題を解決するための手段】
【００１１】
本発明は、好ましい一実施形態により、分散Ｗｅｂサービスのコンテキストにおけるオートノミック・フェイルオーバを管理するように構成されたシステム、方法、および装置である。
【００１２】
一態様によれば、ノード内のサービス・インスタンスに関するメトリックスを収集するステップと、前記ノード内の障害を検出するステップと、前記障害を検出したときに、１組の交換ノードを突き止め、前記交換ノードのそれぞれに関するプラットフォーム・メトリックスを決定するステップと、収集された前記メトリックスおよび前記プラットフォーム・メトリックスに基づいて前記交換ノードのうちの最適に選択されたノードにおいて新しい交換サービス・インスタンスを作成するステップとを有するオートノミック・フェイルオーバのための方法が提供される。
【００１３】
これに関して、好ましい一実施形態により、新しい交換サービス・インスタンスを作成するための最適交換ノードを識別するために、収集されたメトリックスとプラットフォーム・メトリックスとの間で最良適合分析（best-fit analysis）が実行される。次に、このような新しい交換インスタンスは好ましくは、識別された最適交換ノードで作成される。
【００１４】
情況によっては、新たに作成された交換サービス・インスタンスのいずれについても結果的にパフォーマンスの低下をもたらす可能性がないように、単一交換ノードが新たに作成された交換サービス・インスタンスをホストとして処理できるようになると考えられている。しかし、他の多くの情況では、新しいサービス・インスタンスと既存のサービス・インスタンスとのより複雑な再配置が複数の交換ノードにわたって必要になる。これに関して、作成ステップは、好ましい一実施形態により、最適交換ノード内の既存のサービス・インスタンスに関するメトリックスをさらに収集するステップを含む。最良適合分析は好ましくは、最適交換ノードに関して収集されたメトリックスおよびさらに収集されたメトリックスの両方とプラットフォーム・メトリックスとの間で実行される。その後、１組の新しい交換サービス・インスタンスは好ましくは、既存のサービス・インスタンスの一部分と共存するために最適交換ノード内で作成され、１組の新しい交換サービス・インスタンスと既存のサービス・インスタンスの一部分は最適交換ノード内で最適に結合されるように計算される。比較により、既存のサービス・インスタンスのうちの他のインスタンスは好ましくは他の交換ノードに変位され、残りの１組の新しい交換サービス・インスタンスは好ましくは他の交換ノード内で作成される。
【００１５】
好ましい一実施形態により、メトリックスは、グリッド・ホスト内で消費されるリソース、好ましいオペレーティング・システム・プラットフォーム、グリッド・ホスト内で必要な最小リソース、グリッド・ホスト内での消費のために使用可能な好ましいリソースからなるグループから選択された少なくとも１つのメトリックを含むことができる。
【００１６】
さらに、本発明のさらに他の好ましい一実施形態では、メトリックスは、パフォーマンス単位当たりのコスト、リソース消費単位当たりのコスト、パフォーマンス単位当たりの収益、およびリソース消費単位当たりの収益からなるグループから選択された少なくとも１つの追加メトリックを含む。したがって、パフォーマンス単位当たりのコスト、リソース消費単位当たりのコスト、パフォーマンス単位当たりの収益、およびリソース消費単位当たりの収益からなるグループから選択された少なくとも１つのメトリックを加重しながら、好ましい一実施形態により、最適交換ノードに関して収集されたメトリックスおよびさらに収集されたメトリックスの両方とプラットフォーム・メトリックスとの間で最良適合分析を実行することができる。
【００１７】
好ましい一実施形態により、収集されたメトリックスおよび前記プラットフォーム・メトリックスに基づいて交換ノードのうちの最適に選択されたノードにおいて新しい交換サービス・インスタンスを作成するステップは、最適交換ノード内の既存のサービス・インスタンスに関するメトリックスをさらに収集するステップと、前記最適交換ノードに関して収集された前記メトリックスおよびさらに収集された前記メトリックスの両方と前記プラットフォーム・メトリックスとの間で最良適合分析を実行するステップと、前記既存のサービス・インスタンスの一部分と共存するために前記最適交換ノード内で１組の新しい交換サービス・インスタンスを作成するステップであって、前記１組の新しい交換サービス・インスタンスと前記既存のサービス・インスタンスの前記一部分が前記最適交換ノード内で最適に結合されるように計算されるステップと、前記既存のサービス・インスタンスのうちの他のインスタンスを他の交換ノードに変位し、残りの１組の新しい交換サービス・インスタンスを前記他の交換ノード内で作成するステップとを有する。
【００１８】
好ましい一実施形態により、収集されたメトリックスおよび前記プラットフォーム・メトリックスに基づいて交換ノードのうちの最適に選択されたノードにおいて新しい交換サービス・インスタンスを作成するステップは、最適交換ノード内の既存のサービス・インスタンスに関するメトリックスをさらに収集するステップと、パフォーマンス単位当たりのコスト、リソース消費単位当たりのコスト、パフォーマンス単位当たりの収益、およびリソース消費単位当たりの収益からなるグループから選択された少なくとも１つのメトリックを加重しながら、前記最適交換ノードに関して収集された前記メトリックスおよびさらに収集された前記メトリックスの両方と前記プラットフォーム・メトリックスとの間で最良適合分析を実行するステップと、前記既存のサービス・インスタンスの一部分と共存するために前記最適交換ノード内で１組の新しい交換サービス・インスタンスを作成するステップであって、前記１組の新しい交換サービス・インスタンスと前記既存のサービス・インスタンスの前記一部分が加重された前記少なくとも１つのメトリックにより前記最適交換ノード内で最適に結合されるように計算されるステップと、前記既存のサービス・インスタンスのうちの他のインスタンスを他の交換ノードに変位し、残りの１組の新しい交換サービス・インスタンスを前記他の交換ノード内で作成するステップとを有する。
【００１９】
他の態様によれば、本発明は、サービス・グリッド内の複数のグリッド・ホストに通信可能にリンクされたモニターと、前記モニターに結合され、前記グリッド・ホスト内の個々のサービス・インスタンスに関するサービス・メトリックスを保管するように構成されたメトリックス・ストアと、障害のあるグリッド・ホスト内の１組のサービス・インスタンスに関して保管されたメトリックスと提案された交換グリッド・ホストに関して決定されたプラットフォーム・メトリックスとの間の最良適合を計算するようにプログラミングされた最適化ロジックと、前記最適化ロジック内で計算された前記最良適合により前記障害のあるグリッド・ホスト内の前記１組のサービス・インスタンスを交換するために前記提案された交換グリッド・ホスト内で新しい１組のサービス・インスタンスを作成するために前記モニターおよび前記最適化ロジックに結合され、前記グリッド・ホストに通信可能にリンクされたフェイルオーバ・プロセッサとを有するグリッド・コーディネータ（grid coordinator）を提供する。
【００２０】
好ましくは、モニターは、前記グリッド・ホスト内に配置された複数の連携モニター・プロセスを有し、連携モニター・プロセスのそれぞれは、対応するグリッド・ホストの状態を前記フェイルオーバ・プロセッサに報告するための構成を有する。
【００２１】
好ましくは、サービス・メトリックスは、グリッド・ホスト内で消費されるリソース、好ましいオペレーティング・システム・プラットフォーム、グリッド・ホスト内で必要な最小リソース、グリッド・ホスト内での消費のために使用可能な好ましいリソースからなるグループから選択された少なくとも１つのメトリックを有する。好ましくは、サービス・メトリックスは、パフォーマンス単位当たりのコスト、リソース消費単位当たりのコスト、パフォーマンス単位当たりの収益、およびリソース消費単位当たりの収益からなるグループから選択された少なくとも１つのメトリックをさらに有する。
【００２２】
他の態様によれば、オートノミック・フェイルオーバを管理するためのコンピュータ・プログラムがそこに保管されているマシン可読ストレージにおいて、そのコンピュータ・プログラムが、ノード内のサービス・インスタンスに関するメトリックスを収集するステップと、前記ノード内の障害を検出するステップと、前記障害を検出したときに、１組の交換ノードを突き止め、前記交換ノードのそれぞれに関するプラットフォーム・メトリックスを決定するステップと、収集された前記メトリックスおよび前記プラットフォーム・メトリックスに基づいて前記交換ノードのうちの最適に選択されたノードにおいて新しい交換サービス・インスタンスを作成するステップとをマシンに実行させるための複数命令のルーチン・セットを有する、マシン可読ストレージが提供される。
【００２３】
好ましくは、前記メトリックスは、グリッド・ホスト内で消費されるリソース、好ましいオペレーティング・システム・プラットフォーム、グリッド・ホスト内で必要な最小リソース、グリッド・ホスト内での消費のために使用可能な好ましいリソースからなるグループから選択された少なくとも１つのメトリックを有する。
【００２４】
好ましくは、メトリックスは、パフォーマンス単位当たりのコスト、リソース消費単位当たりのコスト、パフォーマンス単位当たりの収益、およびリソース消費単位当たりの収益からなるグループから選択された少なくとも１つのメトリックをさらに有する。
【００２５】
好ましくは、作成ステップは、新しい交換サービス・インスタンスを作成するための最適交換ノードを識別するために、収集された前記メトリックスと前記プラットフォーム・メトリックスとの間で最良適合分析を実行するステップと、識別された前記最適交換ノードで新しい交換サービス・インスタンスを作成するステップとを有する。
【００２６】
好ましくは、作成ステップは、最適交換ノード内の既存のサービス・インスタンスに関するメトリックスをさらに収集するステップと、前記最適交換ノードに関して収集された前記メトリックスおよびさらに収集された前記メトリックスの両方と前記プラットフォーム・メトリックスとの間で最良適合分析を実行するステップと、前記既存のサービス・インスタンスの一部分と共存するために前記最適交換ノード内で１組の新しい交換サービス・インスタンスを作成するステップであって、前記１組の新しい交換サービス・インスタンスと前記既存のサービス・インスタンスの前記一部分が前記最適交換ノード内で最適に結合されるように計算されるステップと、前記既存のサービス・インスタンスのうちの他のインスタンスを他の交換ノードに変位し、残りの１組の新しい交換サービス・インスタンスを前記他の交換ノード内で作成するステップとを有する。
【００２７】
好ましい一実施形態では、作成ステップは、最適交換ノード内の既存のサービス・インスタンスに関するメトリックスをさらに収集するステップと、パフォーマンス単位当たりのコスト、リソース消費単位当たりのコスト、パフォーマンス単位当たりの収益、およびリソース消費単位当たりの収益からなるグループから選択された少なくとも１つのメトリックを加重しながら、前記最適交換ノードに関して収集された前記メトリックスおよびさらに収集された前記メトリックスの両方と前記プラットフォーム・メトリックスとの間で最良適合分析を実行するステップと、前記既存のサービス・インスタンスの一部分と共存するために前記最適交換ノード内で１組の新しい交換サービス・インスタンスを作成するステップであって、前記１組の新しい交換サービス・インスタンスと前記既存のサービス・インスタンスの前記一部分が加重された前記少なくとも１つのメトリックにより前記最適交換ノード内で最適に結合されるように計算されるステップと、前記既存のサービス・インスタンスのうちの他のインスタンスを他の交換ノードに変位し、残りの１組の新しい交換サービス・インスタンスを前記他の交換ノード内で作成するステップとを有する。
【００２８】
他の態様によれば、プログラムがコンピュータ上で実行されたときに以下の方法ステップを実行するように適合されたプログラム・コード手段を有するコンピュータ・プログラムにおいて、その方法ステップが、ノード内のサービス・インスタンスに関するメトリックスを収集するステップと、前記ノード内の障害を検出するステップと、前記障害を検出したときに、１組の交換ノードを突き止め、前記交換ノードのそれぞれに関するプラットフォーム・メトリックスを決定するステップと、収集された前記メトリックスおよび前記プラットフォーム・メトリックスに基づいて前記交換ノードのうちの最適に選択されたノードにおいて新しい交換サービス・インスタンスを作成するステップとを有するコンピュータ・プログラムが提供される。
【００２９】
好ましくは、ノード内のサービス・インスタンスに関するメトリックスを収集するための手段と、前記ノード内の障害を検出するための手段と、前記障害を検出したことに応答して、１組の交換ノードを突き止め、前記交換ノードのそれぞれに関するプラットフォーム・メトリックスを決定するための手段と、収集された前記メトリックスおよび前記プラットフォーム・メトリックスに基づいて前記交換ノードのうちの最適に選択されたノードにおいて新しい交換サービス・インスタンスを作成するための手段とを有する、オートノミック・フェイルオーバのための装置も提供される。
【００３０】
次に、添付図面に関連して、一例としてのみ、本発明の好ましい諸実施形態について説明する。
【発明を実施するための最良の形態】
【００３１】
好ましい一実施形態により、Ｗｅｂサービスまたはグリッド・サービス・ホスティング・インフラストラクチャなどのサービス・インフラストラクチャ内でオートノミック・フェイルオーバを管理するための方法およびシステムが開示される。具体的にグリッド・サービス・ホスティング・インフラストラクチャに関しては、好ましくは障害が発生したグリッド・ホスティング・ノードが検出され、好ましくは障害のあるノードでホストとして処理される対応する１組のグリッド・サービスが決定される。対応する１組内の各サービスごとに、コンピューティング要件、コンピューティング・パフォーマンス、およびコスト／収益特性を決定することができる。その上、好ましくは対応する１組内のグリッド・サービスの新しいインスタンスに対処できる既存のグリッド・サービス・ホスト・ノードが識別される。対応する１組内のすべてのサービスに対処できるホスト・ノードを識別できる場合、好ましくはその１組内のサービスは識別されたホスト・ノードでインスタンス化される。そうではない場合、１つまたは複数のホスト・ノード内のサービスの配置は好ましくは、決定されたコンピューティング要件、パフォーマンス、およびコスト／収益特性のうちの１つまたは複数により最適化される。
【００３２】
これに関して、各サービス・インスタンスは好ましくは、コンピューティング要件、パフォーマンス・メトリックス、およびコスト／収益特性に関してモニターされる。一例として、コンピューティング要件は、オペレーティング・システム要件およびハードウェア・リソース要件を含むことができる。パフォーマンス・メトリックスは、比較により、サービス・インスタンスの動作の過程で消費される通信帯域幅、プロセッサ、メモリまたはディスク・ストレージなどのリソース消費メトリックスを含むことができる。最後に、コスト／収益特性は、たとえば、消費されるリソース当たりのコストと消費されるリソース当たりの収益の両方を含むことができる。いずれのケースでも、メトリックスは好ましくは、各サービスの動作中に動的にロギングされる。したがって、メトリックスは時間の経過につれて変化することが予想される。
【００３３】
ノード障害を検出したことに応答して、好ましくは高優先順位サービスは、障害のあるノード内で前のレベルを満たすかまたはそれを超えるリソース消費レベルをこのような高優先順位サービスが享受できるノード内に配置される。しかし、限定リソース・コンテキストでは、それぞれの前のリソース消費レベルで障害のあるノード内のすべてのサービスの新しいインスタンスに対処するために十分なリソースが交換ノードに欠けている場合、以前、障害のあるノードのケースであったものよりかなり少ないリソースを低優先順位サービスに割り振ることができる。この情況を回避するため、その１組内のサービスのアンバンドルの結果として発生するパフォーマンス上の影響が低優先順位サービス用の交換ノード内の低リソース・レベルを割り振ることによるパフォーマンス上の影響より重くない場合、好ましくは複数の交換ノードを使用してサービスの新しいインスタンスをホストとして処理する。
【００３４】
いずれにしても、本発明はＷｅｂサービスの分散セットのコンテキストでまたはグリッド・サービス・インフラストラクチャのより特定のケースで実現することができるが、本発明の好ましい一実施形態では、本明細書に記載する通り、グリッド・サービス・インフラストラクチャはオートノミック・フェイルオーバのために構成される。そのために、図１は、本発明の好ましい一実施形態によりオートノミック・フェイルオーバのために構成されたサービス・グリッドの概略図である。当業者には明らかになるように、サービス・グリッドは、コンピュータ通信ネットワーク１１０、たとえば、インターネットの全域でグリッド方式で互いに通信可能にリンクされた１つまたは複数のグリッド・ホスト１２０Ａ、１２０Ｂとともに構成されたＷｅｂサービス・グリッドにすることができる。個々の要求側クライアント１００は、グリッド・ホスト１２０Ａ、１２０Ｂのうちの１つまたは複数からＷｅｂサービスへのアクセスを要求することができる。具体的には、当技術分野で周知の通り、それぞれのグリッド・ホスト１２０Ａ、１２０Ｂ内に存在するグリッド・サービス１３０Ａ、１３０Ｂと要求側クライアント１００との間でＳＯＡＰエンコード・メッセージを経路指定することができる。
【００３５】
特に、クライアント１００は、グリッド・コーディネータ１５０から同様に要求することにより、個々のＷｅｂサービスへのアクセスを要求することができる。より具体的には、ＳＯＡＰエンコード・メッセージはメッセージ・ルータ１４０で受信することができ、そのメッセージは既知の１組のグリッド・コーディネータ１５０（１つのみ図示する）のうちの１つに選択的に経路指定することができる。受信した各メッセージごとに、グリッド・コーディネータ１５０は好ましくは、既知のグリッド・ホスト１２０Ａ、１２０Ｂ内でホストとして処理される既知のグリッド・サービス１３０Ａ、１３０Ｂのサービス・レジストリ１９０を調べることにより、サービス・グリッド内の要求されたＷｅｂサービスの所望のインスタンスを突き止める。その後、グリッド・サービス・コーディネータ１５０内の要求経路指定ロジック１６０は好ましくは、グリッド・ホスト１２０Ａ、１２０Ｂのそれぞれのグリッド・サービス１３０Ａ、１３０Ｂのうちの選択されたサービスに要求を経路指定する。
【００３６】
当業者であれば、グリッド・ホスト１２０Ａ、１２０Ｂは集中方式でサーバ・コンピューティング・デバイス内にまたは分散方式で複数のサーバ・コンピューティング・デバイスの全域に配置できることを認識するであろう。グリッド・ホスト１２０Ａ、１２０Ｂは、コンピューティング・デバイスなどの物理ホストまたは物理ホスト内の仮想マシンあるいはプロセスなどの仮想ホストを含むことができる。いずれのケースでも概して、グリッド・ホスト１２０Ａ、１２０Ｂのそれぞれは、そこでＷｅｂサービスをインスタンス化し、維持し、破壊することができるホスト・ノードと見なすことができる。
【００３７】
重要なことに、グリッド・サービス・コーディネータ１５０は好ましくは、ＯＧＳＡによって定義され、たとえば、２００２年１月２９日にＧｌｏｂｕｓ  Ｔｕｔｏｒｉａｌ，  Ａｒｇｏｎｎｅ  Ｎａｔｉｏｎａｌ  Ｌａｂｏｒａｔｏｒｙより発行されたグローバス・プロジェクトの「Ｇｌｏｂｕｓ  Ｔｏｏｌｋｉｔ  Ｆｕｔｕｒｅｓ：    Ａｎ  Ｏｐｅｎ  Ｇｒｉｄ  Ｓｅｒｖｉｃｅｓ  Ａｒｃｈｉｔｅｃｔｕｒｅ」により指定されたものなどのグリッド・サービス・インターフェースを実現する。当技術分野で周知の通り、ＯＧＳＡ準拠グリッド・サービス・インターフェースは、以下のインターフェースおよび動作を含むことができる。
１．Ｗｅｂサービス作成（ファクトリ）
２．グローバル・ネーミング（グリッド・サービス・ハンドル）および参照（グリッド・サービス参照）
３．ライフタイム管理
４．登録およびディスカバリ
５．許可
６．通知
７．並行性
８．管理の容易性
【００３８】
それに関して、グリッド・サービス・コーディネータ１５０は好ましくは、「ファクトリ作成サービス（Factory Create Service）」を使用して新しいアプリケーション・コンテナまたは既存のアプリケーション・コンテナ内に選択されたＷｅｂサービスのインスタンスをクローン作成することができるファクトリ・インターフェースを含む。
【００３９】
重大なことに、グリッド・サービス・コーディネータ１５０は、好ましい一実施形態により、リモート・グリッド・ホスト１２０Ａ、１２０Ｂのうちの１つまたは複数の全域で要求されたＷｅｂサービスのグリッド・サービス・インスタンス１３０Ａ、１３０Ｂのインスタンス化を要求することができる。その結果として、指定のＷｅｂサービスで処理するためのサービス要求を受信したことに応答して、その指定のＷｅｂサービスの任意の特定のインスタンスにかかわらず、グリッド・サービス・コーディネータ１５０内の要求経路指定ロジック１６０は好ましくは、任意の数の経路指定基準によりサービス要求を処理するためにグリッド・ホスト１２０Ａ、１２０Ｂ内のサービス・インスタンス１３０Ａ、１３０Ｂのうちの特定のインスタンスを選択する。
【００４０】
本発明の好ましい一実施形態により、フェイルオーバ・ロジック１７０および最適化メトリックス１８０のストアの両方は、全体的にまたは関連付けにより、グリッド・コーディネータ１５０とともに含まれる。最適化メトリックス１８０は、個々のサービス・インスタンス１３０Ａ、１３０Ｂの動作に関連する様々な静的および動的パラメータならびに測定値のリストを含むことができる。これに関して、最適化メトリックス１８０は好ましくは、グリッド・ホスト１２０Ａ、１２０Ｂ内で消費されるリソースの測定値、好ましいオペレーティング・システム・プラットフォーム、必要な最小リソース、および必要な好ましいリソースを含む。その上、最適化メトリックス１８０は好ましくは、個々のサービス・インスタンス１３０Ａ、１３０Ｂごとに、パフォーマンス単位当たりのコスト、リソース消費単位当たりのコスト、パフォーマンス単位当たりの収益、およびリソース消費単位当たりの収益を指定する。とりわけ、最適化メトリックス１８０のストアに含まれるデータは好ましくは、個々のサービス・インスタンス１３０Ａ、１３０Ｂに関するパフォーマンス・データを収集する最適化メトリックス１８０のストアに結合されたモニター（図示せず）の動作により規則正しく更新される。
【００４１】
この情況が発生すると、フェイルオーバ・ロジック１７０は好ましくは、１つまたは複数のサービス・インスタンスが存在するグリッド・ホスト１２０Ａ、１２０Ｂのうちの障害のあるホストを検出することができる。障害のあるグリッド・ホストを認識すると、フェイルオーバ・ロジック１７０は好ましくは、１つまたは複数の交換グリッド・ホストを突き止める。交換グリッド・ホストは、障害のあるグリッド・ホスト内のすべてのサービス・インスタンスに対処できるグリッド・ホストを含むことができる。逆に、交換グリッド・ホストは、すでにサービス・インスタンスをホストとして処理しており、障害のあるグリッド・ホスト内のサービス・インスタンスの使用のために現在割り振られているすべてのホスト・リソースより少ないリソースを有するグリッド・ホストを含むことができる。ほぼ同一または同一の交換グリッド・ホストを識別できる場合、障害のあるグリッド・ホスト内に存在するサービス・インスタンスの新しいインスタンスは好ましくは、識別された交換ホスト内に作成される。そうではない場合、障害のあるグリッド・ホスト内に存在するサービス・インスタンスの新しいインスタンスを最適に配置するために、フェイルオーバ最適化のためのプロセスを実行することができる。
【００４２】
図２は、図１のサービス・グリッド内のフェイルオーバ最適化のための本発明の好ましい一実施形態によるプロセスのブロック図である。本発明の配置により、グリッド・コーディネータ２１５は、選択されたノード２１０Ｘ、２１０Ｙ、２１０Ｚ内で動作する個々のサービス・インスタンス２６０Ａ、２６０Ｂ、２６０Ｃの動作をモニターすることができる。個々のサービス・インスタンス２６０Ａ、２６０Ｂ、２６０Ｃをモニターする過程で、サービス・メトリックス２３０は好ましくは、サービス・インスタンス２６０Ａ、２６０Ｂ、２６０Ｃのうちの個々のインスタンスごとにロギングされる。より具体的には、サービス・インスタンス２６０Ａ、２６０Ｂ、２６０Ｃのうちの各インスタンスは好ましくは、コンピューティング要件、パフォーマンス・メトリックス、およびコスト／収益特性についてモニターされる。一例として、コンピューティング要件は、オペレーティング・システム要件およびハードウェア・リソース要件を含むことができる。パフォーマンス・メトリックスは、比較により、サービス・インスタンスの動作の過程で消費される通信帯域幅、プロセッサ、メモリまたはディスク・ストレージなどのリソース消費メトリックスを含むことができる。最後に、コスト／収益特性は、たとえば、消費されるリソース当たりのコストと消費されるリソース当たりの収益の両方を含むことができる。
【００４３】
特定のモニター対象ノード、たとえば、サービス・インスタンス２６０Ａ、２６０Ｃが存在するノード２１０Ｙで障害を検出すると、最適化ロジック２２０は好ましくは、以下のプロセスによりフェイルオーバを試みる。まず、好ましくは１つまたは複数の交換ノード２４０Ａ、２４０Ｂが識別される。好ましくは、それぞれの交換ノード２４０Ａ、２４０Ｂについて、個々のプラットフォーム・メトリックス２５０Ａ、２５０Ｂが決定される。個々のプラットフォーム・メトリックス２５０Ａ、２５０Ｂは、たとえば、プロセッサ・タイプ、オペレーティング・システム・タイプ、メモリおよびストレージ量などのコンピューティング構成データを含むことができる。個々のプラットフォーム・メトリックス２５０Ａ、２５０Ｂは、少し例を挙げれば、消費されるコンピューティング・リソース、ホストとして処理されるサービス・インスタンスの数およびＩＤなど、交換ノード２５０Ａ、２５０Ｂの動的に指定された状態をさらに含むことができる。
【００４４】
図２の例示的なケースでは、最適化ロジック２２０は最初に、好ましい一実施形態により、障害のあるノード２１０Ｙ内でホストとして処理されたサービス２６０Ａ、２６０Ｃが障害のあるノード２１０Ｙ内で前に達成されていたパフォーマンス・レベルで動作し続けることができるように、そのサービス２６０Ａ、２６０Ｃが識別された交換ノード２４０Ａ、２４０Ｂのうちの１つで全体的に再インスタンス化できるかどうかを判定することができる。これに関して、単純なケースとして、交換ノード２４０Ａが障害のあるノード２１０Ｙ内で前に達成されていたパフォーマンスのレベルでサービス２６０Ａ、２６０Ｃの新しいインスタンスに対処できるコンピューティング・リソースを含むものであると判定された場合、サービス２６０Ａ、２６０Ｃの新しいインスタンスは好ましくは交換ノード２４０Ａ内に配置される。
【００４５】
対照的に、交換ノード２４０Ａ、２４０Ｂのいずれも、障害のあるノード２１０Ｙ内で前に達成されていたパフォーマンスのレベルでサービス２６０Ａ、２６０Ｃの新しいインスタンスに対処できない場合、サービス２６０Ａ、２６０Ｃの新しいインスタンスは好ましくは、サービス２６０Ａ、２６０Ｃのインスタンスに関するサービス・メトリックス２３０に基づいて最適な方式で交換ノード２４０Ａ、２４０Ｂのうちの１つまたは複数の全域に配置される。より具体的には、サービス２６０Ａ、２６０Ｃの新しいインスタンスは好ましくは交換ノード２４０Ａ、２４０Ｂの両方の全域に配置されるので、いずれか一方の交換ノード２４０Ａ、２４０Ｂがサービス２６０Ａ、２６０Ｃの新しいインスタンスの両方に対処する必要はない。代わって、サービス２６０Ａ、２６０Ｃのインスタンスのうちのいずれか１つについて最も互換性のあるプラットフォームを識別するために、サービス２６０Ａ、２６０Ｃのインスタンスに関するサービス・メトリックス２３０は好ましくはプラットフォーム・メトリックス２５０Ａ、２５０Ｂと突き合わされる。たとえば、好ましいオペレーティング・システムはこれに関して決定力のあるものになりうる。
【００４６】
本発明の好ましい一実施形態では、サービス２６０Ａ、２６０Ｃの各インスタンスについて、コスト／パフォーマンス比および収益／パフォーマンス比が決定される。このようにして、より高い収益／パフォーマンス比およびより低いコスト／パフォーマンス比を享受するサービス２６０Ａ、２６０Ｃのインスタンスが交換ノード内でより高いパフォーマンスを達成する可能性が高くなり、より低い収益／パフォーマンス比およびより高いコスト／パフォーマンス比を有するサービス２６０Ａ、２６０Ｃのインスタンスがサービス２６０Ａ、２６０Ｃの前者のインスタンスに負ける可能性を最適化するように、サービス２６０Ａ、２６０Ｃの新しいインスタンスの配置は交換ノード２４０Ａ、２４０Ｂのうちの１つまたは複数内に配置することができる。上記の計算を支援するために、サービス・メトリックス２３０およびプラットフォーム・メトリックス２５０Ａ、２５０Ｂに最良適合分析を適用することができる。
【００４７】
図３は、図１のサービス・グリッド内でオートノミック・フェイルオーバを管理するための本発明の好ましい一実施形態によるプロセスを示す流れ図である。ブロック３１０から始まり、好ましくはグリッド・コーディネータ内でノード障害が検出される。ブロック３２０では、好ましくは障害のあるノード内に存在する各サービス・インスタンスが識別される。ブロック３３０では、好ましくは１つまたは複数の交換ノードがさらに識別される。ブロック３４０では、好ましくは障害のあるノード内のサービス・インスタンスのそれぞれについてロギングされたメトリックスが検索される。代わって、障害のあるノード内でホストとして処理されたサービスの各インスタンスごとに、そのサービスの任意の１つのインスタンスにおける変則的なイベントを平滑化するために、そのサービスに関する他のノードの全域で複数のインスタンスについてロギングされたメトリックスを検索することができる。いずれのケースでも、識別された交換ノードのそれぞれに関するプラットフォーム・メトリックスがブロック３５０で識別される。
【００４８】
判断ブロック３６０では、好ましくは、障害のあるノードで前に経験したパフォーマンスに基づいて、識別された交換ノードのいずれかがパフォーマンスの低下を必要とせずにサービスの新しいインスタンスに対処できるかどうかが判定される。そうである場合、ブロック３８０では、好ましくは、パフォーマンスの低下を必要とせずにサービスの新しいインスタンスに対処できる識別された交換ノード内にサービスの新しいインスタンスが配置される。そうではない場合、ブロック３７０では、好ましくは最適サービス配置分析が実行される。詳細には、好ましくは各サービスに関するメトリックスが検索され、各潜在的交換ノードに関するメトリックスと比較される。
【００４９】
好ましくは、どの交換ノードでサービスの新しいインスタンスを作成すべきかを判定するために、最良適合分析が適用される。とりわけ、他の要素より特定の要素を強調するために、たとえば、リソース消費率当たりの収益が好ましいオペレーティング・システムより重要になるように、サービス・メトリックスの種々の要素を加重することができる。結果として、新しいサービス・インスタンスのうちの１つまたは複数を害するほど交換ノード内に新しいサービス・インスタンスの全体を作成する可能性もあれば、またはいずれか１つの新しいサービス・インスタンスでパフォーマンスがまったく低下しないことを保証するために新しいサービス・インスタンスの全体を複数の交換ノードにわたってフラグメント化する可能性もある。最後に、既存のサービス・インスタンスのうちのいずれか１つが交換ノード内の新しいサービスの配置により変位された状態になる可能性があることが予見できる場合、交換ノードの１つまたは複数の内部の既存のサービス・インスタンスにブロック３７０の分析を拡張することができる。
【００５０】
本発明は、ハードウェア、ソフトウェア、またはハードウェアとソフトウェアの組合せで実現することができる。本発明の方法およびシステムの実現例は、１つのコンピュータ・システム内で集中方式でまたは種々の要素が複数の相互接続コンピュータ・システム間に分散される分散方式で実現することができる。本明細書に記載された方法を実行するために適合された任意の種類のコンピュータ・システムまたはその他の装置は、本明細書に記載された諸機能を実行するために適している。ハードウェアとソフトウェアの典型的な組合せは、ロードされ実行されたときに、本明細書に記載された方法を実行するようにコンピュータ・システムを制御するコンピュータ・プログラムを備えた汎用コンピュータ・システムにすることができるであろう。また、本発明は、本明細書に記載された方法の実現を可能にするすべての特徴を有し、コンピュータ・システムにロードされたときにこれらの方法を実行することができるコンピュータ・プログラムでも実施することができる。
【００５１】
このコンテキストにおけるコンピュータ・プログラムまたはアプリケーションは、直接またはａ）他の言語、コード、または表記への変換およびｂ）異なる具体的形式での複製のうちのいずれか一方または両方の後、情報処理機能を有するシステムに特定の機能を実行させるための１組の命令を任意の言語、コード、または表記で表した任意の表現を意味する。重大なことに、本発明は、その精神または本質的属性から逸脱せずに他の具体的な形式で実施することができ、したがって、本発明の範囲を示すものとして、上記の明細ではなく特許請求の範囲を参照しなければならない。
【図面の簡単な説明】
【００５２】
【図１】本発明の好ましい一実施形態によりオートノミック・フェイルオーバのために構成されたサービス・グリッドの概略図である。
【図２】図１のサービス・グリッド内のフェイルオーバ最適化のための本発明の好ましい一実施形態によるプロセスのブロック図である。
【図３】図１のサービス・グリッド内でオートノミック・フェイルオーバを管理するための本発明の好ましい一実施形態によるプロセスを示す流れ図である。
【図１】
2007500908.tif 000003
【図２】
2007500908.tif 000004
【図３】
2007500908.tif 000005
【手続補正書】
【提出日】平成17年3月9日(2005.3.9)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
ノード内のサービス・インスタンスに関する第１のメトリックスを収集するステップと、
前記ノード内の障害を検出するステップと、
前記障害を検出したときに、１組の交換ノードを突き止め、前記交換ノードのそれぞれに関するプラットフォーム・メトリックスを決定するステップと、
収集された前記メトリックスおよび前記プラットフォーム・メトリックスに基づいて前記交換ノードのうちの最適に選択されたノードにおいて新しい交換サービス・インスタンスを作成するステップとを有する、オートノミック・フェイルオーバのための方法において、
前記作成ステップが、
最適交換ノード内の既存のサービス・インスタンスに関するメトリックスをさらに収集するステップと、
前記最適交換ノードに関して収集された前記メトリックスおよびさらに収集された前記メトリックスの両方と前記プラットフォーム・メトリックスとの間で最良適合分析を実行するステップであって、前記最良適合分析が、前記障害のあるノードからの１つまたは複数のサービス・インスタンスに対処するために１つまたは複数の既存のサービス・インスタンスを１つまたは複数の他の交換ノードに変位するかどうかを判定するためのものであるステップとを有する方法。
【請求項２】
前記第１のメトリックスが、グリッド・ホスト内で消費されるリソース、オペレーティング・システム・プラットフォーム、グリッド・ホスト内で必要な最小リソース、グリッド・ホスト内での消費のために使用可能なリソースからなるグループから選択された少なくとも１つのメトリックを有する、請求項１に記載の方法。
【請求項３】
前記第１のメトリックスが、パフォーマンス単位当たりのコスト、リソース消費単位当たりのコスト、パフォーマンス単位当たりの収益、およびリソース消費単位当たりの収益からなるグループから選択された少なくとも１つのメトリックをさらに有する、請求項２に記載の方法。
【請求項４】
前記作成ステップが、
前記既存のサービス・インスタンスの一部分と共存するために前記最適交換ノード内で１組の新しい交換サービス・インスタンスを作成するステップであって、前記１組の新しい交換サービス・インスタンスと前記既存のサービス・インスタンスの前記一部分が前記最適交換ノード内で最適に結合されるように計算されるステップと、
前記既存のサービス・インスタンスのうちの他のインスタンスを他の交換ノードに変位し、残りの１組の新しい交換サービス・インスタンスを前記他の交換ノード内で作成するステップとをさらに有する、請求項１に記載の方法。
【請求項５】
前記実行ステップが、パフォーマンス単位当たりのコスト、リソース消費単位当たりのコスト、パフォーマンス単位当たりの収益、およびリソース消費単位当たりの収益からなるグループから選択された少なくとも１つのメトリックを加重しながら実行され、
前記作成ステップが、
前記既存のサービス・インスタンスの一部分と共存するために前記最適交換ノード内で１組の新しい交換サービス・インスタンスを作成するステップであって、前記１組の新しい交換サービス・インスタンスと前記既存のサービス・インスタンスの前記一部分が加重された前記少なくとも１つのメトリックにより前記最適交換ノード内で最適に結合されるように計算されるステップと、
前記既存のサービス・インスタンスのうちの他のインスタンスを他の交換ノードに変位し、残りの１組の新しい交換サービス・インスタンスを前記他の交換ノード内で作成するステップとをさらに有する、請求項３に記載の方法。
【請求項６】
ノード内のサービス・インスタンスに関する第１のメトリックスを収集するための手段と、
前記ノード内の障害を検出するための手段と、
前記障害を検出したことに応答して、１組の交換ノードを突き止め、前記交換ノードのそれぞれに関するプラットフォーム・メトリックスを決定するための手段と、
収集された前記メトリックスおよび前記プラットフォーム・メトリックスに基づいて前記交換ノードのうちの最適に選択されたノードにおいて新しい交換サービス・インスタンスを作成するための手段とを有する、オートノミック・フェイルオーバのための装置において、
前記作成手段が、
最適交換ノード内の既存のサービス・インスタンスに関するメトリックスをさらに収集するための手段と、
前記最適交換ノードに関して収集された前記メトリックスおよびさらに収集された前記メトリックスの両方と前記プラットフォーム・メトリックスとの間で最良適合分析を実行するための手段であって、前記最良適合分析が、前記障害のあるノードからの１つまたは複数のサービス・インスタンスに対処するために１つまたは複数の既存のサービス・インスタンスを１つまたは複数の他の交換ノードに変位するかどうかを判定するためのものである手段とを有する装置。
【請求項７】
前記検出手段が前記ノード内に配置された複数の連携モニター・プロセスを有し、前記連携モニター・プロセスのそれぞれが、対応するノード・ホストの状態を前記突き止め手段に報告するための構成を有する、請求項６に記載の装置。
【請求項８】
前記第１のメトリックスが、グリッド・ホスト内で消費されるリソース、オペレーティング・システム・プラットフォーム、グリッド・ホスト内で必要な最小リソース、グリッド・ホスト内での消費のために使用可能なリソースからなるグループから選択された少なくとも１つのメトリックを有する、請求項６に記載の装置。
【請求項９】
前記第１のメトリックスが、パフォーマンス単位当たりのコスト、リソース消費単位当たりのコスト、パフォーマンス単位当たりの収益、およびリソース消費単位当たりの収益からなるグループから選択された少なくとも１つのメトリックをさらに有する、請求項８に記載の装置。
【請求項１０】
オートノミック・フェイルオーバを管理するためのコンピュータ・プログラムが保管されているマシン可読ストレージであって、
前記コンピュータ・プログラムが、ノード内のサービス・インスタンスに関する第１のメトリックスを収集するステップと、前記ノード内の障害を検出するステップと、前記障害を検出したときに、１組の交換ノードを突き止め、前記交換ノードのそれぞれに関するプラットフォーム・メトリックスを決定するステップと、収集された前記メトリックスおよび前記プラットフォーム・メトリックスに基づいて前記交換ノードのうちの最適に選択されたノードにおいて新しい交換サービス・インスタンスを作成するステップとを前記マシンに実行させるための複数命令のルーチン・セットを有し、
前記作成ステップが、
最適交換ノード内の既存のサービス・インスタンスに関するメトリックスをさらに収集するステップと、
前記最適交換ノードに関して収集された前記メトリックスおよびさらに収集された前記メトリックスの両方と前記プラットフォーム・メトリックスとの間で最良適合分析を実行するステップであって、前記最良適合分析が、前記障害のあるノードからの１つまたは複数のサービス・インスタンスに対処するために１つまたは複数の既存のサービス・インスタンスを１つまたは複数の他の交換ノードに変位するかどうかを判定するためのものであるステップとを有する、マシン可読ストレージ。
【請求項１１】
前記第１のメトリックスが、グリッド・ホスト内で消費されるリソース、オペレーティング・システム・プラットフォーム、グリッド・ホスト内で必要な最小リソース、グリッド・ホスト内での消費のために使用可能なリソースからなるグループから選択された少なくとも１つのメトリックを有する、請求項１０に記載のマシン可読ストレージ。
【請求項１２】
前記第１のメトリックスが、パフォーマンス単位当たりのコスト、リソース消費単位当たりのコスト、パフォーマンス単位当たりの収益、およびリソース消費単位当たりの収益からなるグループから選択された少なくとも１つのメトリックをさらに有する、請求項１１に記載のマシン可読ストレージ。
【請求項１３】
前記作成ステップが、
前記既存のサービス・インスタンスの一部分と共存するために前記最適交換ノード内で１組の新しい交換サービス・インスタンスを作成するステップであって、前記１組の新しい交換サービス・インスタンスと前記既存のサービス・インスタンスの前記一部分が前記最適交換ノード内で最適に結合されるように計算されるステップと、
前記既存のサービス・インスタンスのうちの他のインスタンスを他の交換ノードに変位し、残りの１組の新しい交換サービス・インスタンスを前記他の交換ノード内で作成するステップとを有する、請求項１０に記載のマシン可読ストレージ。
【請求項１４】
前記実行ステップが、パフォーマンス単位当たりのコスト、リソース消費単位当たりのコスト、パフォーマンス単位当たりの収益、およびリソース消費単位当たりの収益からなるグループから選択された少なくとも１つのメトリックを加重しながら実行され、
前記コンピュータ・プログラムが、
前記既存のサービス・インスタンスの一部分と共存するために前記最適交換ノード内で１組の新しい交換サービス・インスタンスを作成するステップであって、前記１組の新しい交換サービス・インスタンスと前記既存のサービス・インスタンスの前記一部分が加重された前記少なくとも１つのメトリックにより前記最適交換ノード内で最適に結合されるように計算されるステップと、
前記既存のサービス・インスタンスのうちの他のインスタンスを他の交換ノードに変位し、残りの１組の新しい交換サービス・インスタンスを前記他の交換ノード内で作成するステップとを前記マシンにさらに実行させるための複数命令のルーチン・セットを有する、請求項１２に記載のマシン可読ストレージ。
【国際調査報告】
2007500908.tif 000006
2007500908.tif 000007
2007500908.tif 000008