JP2005512190A - ネットワーク化システムにおけるリソースの高可用性をもたらす実複合オブジェクト - Google Patents

Abstract

複数のメンバーを含む複合リソースが確立される。上記メンバーは各々が類似のサービスを提供することができる。複合リソースにおける各々のメンバーの状態を監視する調整部が設けられる。或るコンポーネントがサービスを調整部に要求する。調整部は、サービスがこのコンポーネントへ複合リソースの特定のメンバーにより提供されるよう手配する。この特定のメンバーが活性でなくなると、このコンポーネントへのサービスの提供は自動的に複合リソース内の別のメンバーによって行なわれる。複合リソースの状態は、複合リソース内の各々のメンバーの状態から独立して維持される。

Description

参照出願
本願は、コルレイン（Colrain）他を発明者とする「高可用性フレームワークで利用される単純リソースおよび複合リソースのための高速回復イベント、仮想複合オブジェクトおよび可能化／不能化属性（“Rapid Recovery Events, Virtual Composite Objects, And Enable/Disable Attributes For Simple and Composite Resources For Use In A High
Availability Framework”）」と題された、２００１年１１月３０日に出願の米国仮特許出願連続番号第６０／３３４，３４９号および、「ネットワーク化システムにおけるリソースの高可用性をもたらす仮想複合オブジェクト（“Virtual Composite Objects for Providing High Availability of Resources on Networked Systems”）」と題された、２００２年１１月１５日に出願の米国仮特許出願連続番号第６０／４２６，５８７号（代理人事件番号第５０２７７−１９６８号）の優先権の利益を主張する。上記優先権出願はここに引用により援用される。

発明の分野
この発明はネットワーク化システムのリソース管理に関する。特定的にこの発明は、ネットワーク化システムを管理するための実複合オブジェクトに関する。

発明の背景
複数のノードからなるクラスタにおいて、リソースの可用性は重要な考慮事項である。このため、クラスタ内のリソースのうちいくつかを冗長的に利用可能とすることによりクラスタの信頼性および可用性を高めている。通常、１つのノードまたはリソースが障害を起こすと、別のノードにある類似のリソースを利用できるようにするための機構が存在する。

現在のシステムではノードのリソースはスタックにされる。スタック内ではリソース間に依存性が構築される。したがって、中間の層のリソースはより低い層のリソースに対して依存性を有し、一方でアプリケーションまたはその他最上レベルのプログラムはこれより下の層のリソースに対する依存性を有することがあり得る。過去においては、障害の発生時におけるスタック内のリソース間依存性の管理が問題となっていた。

１つの解決法としては、障害が生じたノードのスタックを完全に、異なるノードにおいて復元することである。この一般的に講じられる解決法では、障害を起こしたリソースがただ１つの場合でもスタック全体を他の所で復元する。その結果、１ノードにあるリソースが障害を起こすと、障害が生じたノードに冗長のサービスを提供するシステムの能力に遅延が生じる。しばしばこの遅延は、このノードクラスタから提供されるサービスの品質および可用性が妨害されるほど長くなることがある。

過去に試みられたもう１つの解決法としては、障害が起きた際、フレームワークを用いてノード間の切換を容易にすることがあった。この種の解決法においては、クラスタ内のノード同士を相互接続するフレームワークが、障害の生じたノードのスタックを立て直す。このようなシステムでは、ノードクラスタの可用性は、フレームワークの応答性と、フ
レームワークがリソースのスタックを異なるノードで復元する能力とに依存する。

以下、添付の図面の各図を参照してこの発明を限定的でなく例示的に説明する。図中では同様の参照番号は同様の構成要素を指す。

発明の詳細な説明
ネットワーク化システムにおけるリソースの高可用性をもたらす方法および装置を記載する。以下の記載においては、この発明の完全な理解がもたらされるよう説明上多くの具体的な詳細について述べる。しかし、この発明がこれら具体的な詳細なしに実施可能であることは明らかであろう。一方で、周知の構造および装置についてはこれをブロック図の形で示すことによりこの発明を不必要に不明瞭にすることを避けている。

一般的な概観
一実施例に従うと、フレームワークにおけるリソースが、複数のメンバーを含む複合リソースを確立する。これらメンバーは各々が類似のサービスを提供することができる。フレームワークエージェントが複合リソース内の各々のメンバーの状態を監視する。或るコンポーネントがネットワークＩＰアドレスおよびリスナーなどのリソースを用いてサービスを要求する。ネットワークリスナーなどのリソースは、このサービスが複合リソースにおける１つ以上のメンバーによりこのコンポーネントに提供されるよう手配する。この特定のメンバーが活性でなくなると、このコンポーネントへのサービスの提供は自動的に複合リソース内の他のメンバーによって行なわれる。複合リソースの状態は、複合リソース内の各々のメンバーの状態から独立して維持される。

別の実施例に従うと、ノードクラスタにおいて、多数のメンバーを含む複合リソースを確立することにより、コンポーネントがフレームワークにおいて管理される。各々のメンバーは類似のサービスを提供するように動作可能である。１組の分散した論理がクラスタしたがってノードに常駐する。論理はフレームワークエージェントにより実行可能である。この論理は、上記複数のノードにおける１ノードが障害を起こしても引続き機能するように構成され得る。論理を利用する各々のメンバーの状態についての情報が収集される。各々のメンバーの状態からサービスについてサービスレベルが判断される。上記１組の分散した論理は、サービスが１つ以上のメンバーにより要求側のコンポーネントに提供されるよう手配し、これは、上記サービスのレベルが、サービスが利用不可能であることに対応するまで行なわれる。

一実施例では、上記分散した論理により、複合リソースにおける各々のメンバーは、このメンバーを始動させる、このメンバーを停止させるまたは複合リソースの状態を確認するための処置を実行することが可能となる。分散した論理が実行し得るその他の処置には、メンバーの可能化または不能化のうちいずれか状態に関する処置が含まれる。

別の実施例では、関心の向けられたイベントが高可用性フレームワークへ先回りして提供される。複数のコンポーネントが実行されるフレームワークでは、これらコンポーネントを定期的にポーリングすることにより関心の向けられたイベントの発生を検出する。さらに、１つ以上のコンポーネントについてモニタが確立される。或るコンポーネントが関心の向けられたイベントの発生を引起こした後、モニタは、フレームワークが第１のコンポーネントをポーリングするのを待つことなく、関心の向けられたイベントをフレームワークへ先回りして通信する。

別の実施例では、異なるノードに常駐するメンバーから複合リソースを確立することにより、コンポーネントがフレームワーク内で管理される。これらメンバーは各々が類似の
サービスを提供することができる。上記複数のノードのいずれかにあるメンバーを不能化するメッセージがフレームワークにより受取られ得る。メッセージが受取られるのに応答して、このメンバーは複合リソースのための候補としてもはや利用可能ではなくなる。メンバーが利用不可能であることは、メンバーがオフラインであることに対応し得る。

用語の説明
「複合リソース」とは、或る共通のサービスを提供する複数のメンバーからなる構成体である。サービスは或るメンバーの実行する１つ以上の機能に対応し得る。「均質」な複合リソースとは、機能または構造のいずれかに関しほぼ同一のメンバーを有する複合リソースに対応するものである。これに代えて、複合リソースは「不均質」の属性を有することもあり、ここではメンバーの機能または構造に差異が存在する。このように、複合リソースにおける各々のメンバーの提供するサービスは同一である必要はなく、また等価である必要すらない。

「メンバー」とは、ネットワーク化システムのノードにあるリソースであって、複合リソースにより定義される或る機能またはサービスを実行するために用いられ得るものである。メンバーの例としては、アプリケーション、アプリケーションのインスタンス、およびその他ノードの内部および外部の通信を可能にし容易にするためのリソースがある。

「フレームワーク」とは、ここで用いられる場合には、システム内の或るコンポーネントが障害を起こした際にこのコンポーネントの提供するサービスの受取側が経験する遅延を最小限にするためのソフトウェアまたはその他の論理を指す。フレームワークは異なる場所にある多数のノードにより共用され得るよう分散していることがある。

「実質的に等価」という表現は、１つの比較点（量、機能または結果）と別の比較点とが同一またはわずかだけ外れていることを意味する。２つのリソースの実行する機能が互いに対し９０％の相関を有する場合、これらのリソースは実質的に等価であるといわれる。

本願全体を通じ、「第１」、「第２」および「第３」という用語は、事項同士を区別するための識別名として用いる。これらの用語が事項の識別名として用いられている場合、これらの用語が指しているのは時間的な順番ではない。たとえば「第１のコンポーネント」という用語は、「第２のコンポーネント」とは異なるコンポーネントであるという意味であって、必ずしも第２のコンポーネントに対し時間的に最初のコンポーネントであるという意味ではない。もう１つの例として、第１のメンバーは活性なメンバーに対応し、第２のメンバーは、１つ以上の他の活性なメンバーのための予備メンバーに対応するということがあり得る。

複合リソースを用いたサービスの提供方法
図１を参照して、ノードクラスタにおいて複合リソースを用いてサービスを提供する方法を記載する。このノードクラスタは、その他の装置およびコンポーネントを含むネットワーク化システムの一部であり得る。一実施例では、複合リソースはノードクラスタに常駐するメンバーによって形成される。ノードクラスタにおける複合リソースを含むシステムの一例を図２および図３に与える。

ステップ１１０にて、ノードクラスタに常駐するメンバーから複合リソースを確立する。これらメンバー同士を互いに関連付けて、各々のメンバーが類似のサービスをこのサービスを要求するコンポーネントに提供するようにできる。これらメンバーを交換可能とすることにより、類似のサービスが上記複数のメンバーのうちいずれによっても提供可能とすることができる。メンバーの構造および機能は、複合リソースの提供しているサービス
により決定される。たとえばデータベースアプリケーションサービスは、データベースアプリケーションのインスタンスであるメンバーにより形成された複合リソースを有し得る。

一実施例では、複合リソースの提供するサービスは単一のシステムのイメージを有する。その結果、サービスを提供するのに必要な複雑さが、クライアント、ユーザまたはその他サービスを要求している実体（エンティティ）から隠れる。サービスでは、ノードクラスタに冗長の部分が組み込まれていることからもたらされる利益を要求側の実体が享受することが可能である。サービスを提供するメンバーは複合リソース内の別のメンバーへと透明に切換えられ得る。これはこれらメンバーが異なるノードに常駐している場合でも該当する。

また、複合リソースにより、メンバーがサービスの機能を提供している際にこれらメンバーをより効果的に管理することができる。たとえば、複合リソースを用いて、複合リソースの各メンバーを個々にスケジューリングする必要なしにノードクラスタ内管理の計画をすることができる。したがって、１つのメンバーまたはメンバーのノードを整備のために撤去した際に、このノードから提供されるサービスは、別のノードに常駐する別のメンバーから透明かつ自動的に提供される。

さまざまな種類のサービスを提供する複合リソースが確立され得る。サービスの種類の例には、データベースサービス、機能サービス、データ依存サービス、接続前サービスが含まれる。データベースサービスとは、データベースサーバのインスタンスの実行により行なわれる機能に対応するものであり得る。機能サービスとは、データベースアプリケーションの実行の際に一まとめにされる特定の機能を指し得る。データ依存サービスとは、セッションをサービスおよびリソースへルーティングするプロセスを指す。特定のセッションが特定のリソースの利用を宣言し、データ依存サービスがこのセッションを、これがサービスを受取ることのできる場所へとルーティングすることがあり得る。接続前サービスは、障害の場合に他のサービスをサポートするアプリケーションおよびその他のリソースに対応する。

一実施例に従うと、ユーザは複合リソースの確立に必要な命令および／またはデータを入力する。複合リソースの形成はユーザの所望のサービスに基づき得る。たとえばユーザが入力するのは、サービスが受取られるべき好ましい場所に対応するインスタンスの一覧であり得る。ユーザはまた、支援のためにサービスが提供されるべき他の場所において追加のインスタンスを指定することができる。この例では、複合リソースは、サービスを提供するのに用いるコンポーネントのインスタンスによって形成され、こうして各々のインスタンスが複合リソースのメンバーとなる。

ステップ１２０にて、複合リソース内のメンバーの１つからサービスが要求側コンポーネントに提供される。要求側コンポーネントは、これらメンバーが常駐するノードの外部にあるクライアント端末であり得る。これに代えて、要求側コンポーネントはノードの１つに常駐してサービスを要求し実行することもできる。これに従い一実施例では、類似のリソースを提供することになるメンバーの選択は要求側コンポーネントの場所に基づき得る。この場所は、中間の層のアプリケーションまたはクライアント端末に対して透明であり得る。

ステップ１３０にて、サービスを提供するメンバーがサービスを提供できなくなったことが検出される。これはさまざまな状況に対応し得る。まず、このメンバーのノードの障害によってこのメンバーが障害を起こすことがあり得る。これに代わって、このメンバー自体が障害を起こし、一方でノードは依然として機能していることがあり得る。別の例と
して、ノードとメンバーとがともに整備計画のために停止されることもあり得る。

ステップ１４０にて、複合リソースは自分自身を再評価することにより、その状態とその各メンバーの状態とを判断する。この判断には、複合リソース内の別のメンバーがサービスを提供するために利用可能であるかどうかの判断が含まれ得る。したがって一実施例では、この判断のためには、この複合リソースを形成する少なくとも１つの他のメンバーが活性または動作していると識別されることが必要である。これに加えて、上記他のメンバーが利用可能またはその他でサービスを提供可能であるかどうかの判断が行なわれ得る。

これに代えて、ステップ１４０にて、サービスを提供していたメンバーが障害を起こした際に複合リソースの特定の濃度（cardinality）が満足されたかどうかについて判断することもある。１つの一般的な事例では、ノードクラスタにある１メンバーの濃度が「１」であると仮定されるが、実施例によってはより高い濃度が指定されることもある。たとえば濃度が「３」である場合があり、この場合、複合リソースが活きている（alive）と考えられるためには、この複合リソースのメンバー３つが活きていなければならない。

ステップ１４０にて複合リソースを形成する別のメンバーがサービスを提供可能であると判断された場合、ステップ１５０にて要求側コンポーネントがこのメンバーからサービスを受取る。一実施例では、１ユーザに提供されているサービスの遷移は、ユーザにとって透明な新たな場所から継続することになる。サービスが、このサービスを提供する１つ以上の他のメンバーへ移転される前に、ユーザがサービスの中断を受取ることがあり得る。これに代えて、サービスを提供するメンバーが障害を起こした際、他の活性なメンバー間でサービスを移転してユーザが連続的なサービスを受取るようにする。このような実施例では、複合リソースのメンバー同士はその性質上均質であり得る。その結果、要求側コンポーネントに提供されるサービスは中断されない。これに加え、サービスが提供されているノードにある他のコンポーネントがサービスに依存することもある。メンバー間で遷移がなされる際にこれらコンポーネントの性能が受ける影響は顕著なものではない。したがって、図１に記載したような実施例により、複合リソースのメンバー間で遷移がなされる際に遅延が生じることなくサービスを連続的に提供することができる。

複合リソースが不均質なメンバーから形成される場合、各々のメンバーの提供するサービスの品質または性質は異なり得る。しかし、複合リソースのサービスを規定する共通の機能は連続的に提供され、かつ可能な限り透明に提供される。

ステップ１４０にて、複合リソースを形成するメンバーでサービスを提供できるものが他にないと判断された場合、ステップ１６０にて、この複合リソースが提供するサービスは停止される。一実施例では、複合リソースが利用可能とされるのは、或る数の、または指定されたいくつかのメンバーが再始動できる場合のみである。

複合リソースを利用するためのシステム
図２は、複数のノードからなるクラスタにおいて実複合リソースを確立し利用するための基本的なシステムを例示する。この複合リソースは、ノードクラスタの内部または外部のいずれかに常駐し得る他のコンポーネントにサービスを提供する。図２に示すような実施例では、複合リソースはクラスタ内のノードのうち少なくとも１つに対し物理的な依存性を有し、この点で複合リソースは「実（real）」と言われる。図３に示すような他の実施例では、複合リソースはいかなる個々のノードに対しても物理的な依存性を有さず、この点で複合リソースは「仮想（virtual）」のものである。

一実施例では、システム２００は第１のノード２１０と、第２のノード２２０と、第３
のノード２３０とを含む。第１のノード２１０は第１のリソース２１２と、第１のメンバー２１４と、第１のコンポーネント２１６とを含む。第２のノード２２０は第２のリソース２２２と、第２のメンバー２２４と、第２のコンポーネント２２６とを含む。同様に、第３のノード２３０は第３のリソース２３２と、第３のメンバー２３４と、第３のコンポーネント２２６とを含む。第１のメンバー２１４、第２のメンバー２２４および第３のメンバー２３４は実複合リソース２４０を形成するように確立され得る。

第１のノード２１０、第２のノード２２０および第３のノード２３０の各々にはフレームワーク２６０が存在する。フレームワーク２６０を異なるノードに常駐する区画の形で例示するが、一実施例ではフレームワーク２６０はノードすべてに存在する単一の論理的実体を形成する。フレームワーク２６０は、各々のノードにおいてフレームワークエージェント２６６の形で存在することができ、これはローカルなノードにあるリソースのための機能を実行する。フレームワーク２６０は、障害を起こしたノードのアプリケーションおよびリソースを他のノードにおいて再びスタック化する機能を含み得る。一実施例では、フレームワーク２６０は、複合リソース２４０を確立してサービスを他のコンポーネントに提供するためのコードを実行する。レジストリ２６２は、フレームワーク２６０および／または調整部２５０により利用され、複合リソース２４０の各メンバーについての状態情報を格納することができる。この状態情報は、複合リソース２４０内のメンバーが活性か非活性かを示すことができる。レジストリ２６２はフレームワーク２６０の一部であり得るが、またはこれに代えてレジストリがフレームワークの外部に常駐することもある。

実複合リソース
図２に示すようなシステムでは、複合リソース２４０は「実」であると考えられるが、それは複合リソースがフレームワーク２６０によって、システム内のノードのうち１つにおいて直接動作しかつこれに依存していると見なされるからである。フレームワーク２６０が複合リソース２４０の場所として見なす特定のノードは任意であり、複合リソース２４０の動作の進行に伴い何度も変わり得る。したがってノード２１０，２２０，２３０は、特定の瞬間にそのいずれもが複合リソース２４０を含んでいると見なされ得るという点で互いに等しい。

図２では、複合リソース２４０がノードのうち１つにおいて存在すると見なされる態様を調整部２５０によって例示してある。一実施例で調整部２５０は実際には、フレームワーク２６０において実行されて複合リソース２４０を評価するコードである。調整部２５０は実際、ノードすべてにわたって分散したフレームワークエージェントおよびリソースの表現であり得る。しかし、複合リソースにより実行されることになる機能に対応する命令をフレームワーク２６０が実行するとき、これら機能（および複合リソース２４０）は１つのノードにおいて実行されていると見なされる。

このように、「実」複合リソース２４０はノードから独立しており、複合リソースが依存する特定のノードは任意に決定でき、変更可能である。ある特定の時刻にて、複合リソース２４０が常駐する所であると見なされたノードが障害を起こすと、この複合リソースは別のノードにおいて透明に再始動される。複合リソース２４０のメンバーはなお複合リソース２４０の外側で機能するよう動作可能であり、サービスには変更が生じない。複合リソース２４０は動作中のメンバーに基づいて再始動および再評価される。

本願の目的のために、調整部２５０はフレームワークリソース、たとえばフレームワークエージェント２６６を参照し、これは実行されるとフレームワーク内のすべてのリソースについての調整活動をする。後でより詳細に説明するように、これらの機能としては、メンバーによるサービスの提供を開始する、メンバーによるサービスの提供を停止する、
複合リソース２４０を回復する、および、障害を起こしたメンバーの特定の複合リソースジョブを複合リソース２４０における他のメンバーへと再配置するなどが挙げられる。たとえばサービスをコンポーネント２０５に提供しているメンバーが障害を起こした際、調整活動により、他のメンバーの１つ（またはそれ以上）が同じサービスをこのコンポーネントに提供するよう手配される。

図２では、「実」複合リソース２４０が、そのメンバーの常駐するクラスタノードの１つに依存し得る点を説明するために、調整部２５０を１つのノードに常駐するものとして示す。調整部２５０のノードは、フレームワーク２６０により複合リソース２４０が常駐していると見なされるノードに対応すると仮定され得る。上述のように、複合リソース２４０が常駐していると見なされる特定のノードは任意に選択され変更可能である。したがって、調整部２５０の位置がノード同士の重要性の異なりを示していると見なすべきではない。

フレームワーク２６０が複合リソース２４０をノードの１つに物理的に存在するものとして扱い得る理由として、フレームワーク自体の既存の制約がある。この制約のため、場合によりフレームワーク２６０は、複合リソース２４０の実行する機能を任意の１つの特定のノードと関連していないと見なすことができなくなることがある。そこで、調整部２５０がその場所を１つのノードに有するとして示してある図２の実施例では、フレームワーク２６０についてあり得るこのような制約を勘案する。図２に示すような実施例が複合リソース２４０のサービスを連続的に提供することに関し効果的であるのは、フレームワーク２６０により複合リソースが特定のインスタンスに常駐すると見なされる特定のノードが障害を起こしていない場合である。このような障害が起こると、複合リソース２４０は回復の必要があり得る。回復のプロセスは、複合リソース２４０を再始動するステップと、この複合リソースを再評価してその個々のメンバーの状態を判断するステップとを含み得る。しかしほとんどの場合、複合リソース２４０についてのメンバーを提供するノードは多数ある。ノードすべてが複合リソース２４０の常駐する所であると見なされ得るため、１つのノードが障害を起こして複合リソース２４０を停止させてしまうということが起こるのは稀である。

複合リソース２４０はフレームワーク２６０の制約を勘案するとともに、そのメンバーの性能および利用しやすさを向上させる多くの機能を提供する。たとえば、複合リソース２４０内で動作するメンバーは、自動化されたフレームワーク動作および透明な負荷共有トポロジーを提供する。その他複合リソース２４０の結果として提供され得るサービスとしては、複合リソースが供給され得る多数のクライアントのための接続および実行時の作業負荷管理がある。複合リソースではさらに、追加の能力をオンデマンドで提供することが容易となる。たとえば複合リソース２４０の濃度は、複合リソースにより実行される作業量に対するいくつかの前提条件に応じて自動的に増加され得る。複合リソースにより実行され得る作業が取引可能にされることもある。

調整部
上述のように、調整部２５０は、調整活動を行なうフレームワークリソースおよびエージェントを表わすものである。一実施例では、調整部２５０はまた、複合リソース２４０のメンバーのリソースを含むことができ、これはこのような調整活動をフレームワークリソースの代わりにまたはこれに追加して行なう。一実施例では、調整活動には、複合リソース２４０の個々のメンバーを始動すること、個々のメンバーを停止すること、および複合リソース２４０の個々のメンバーを回復することが含まれる。複合リソースが回復される態様は予め定められたプロトコルに従うことができる。このプロトコルにより、たとえば複合リソース２４０のサービスの再始動、および複合リソースメンバーの状態の再評価がなされる。

一実施例で、負荷管理ソフトウェアは、サービスを要求している実体に複合リソース２４０の特定のメンバーがサービスを提供するよう手配する。サービスを提供しているメンバーがサービスの提供をやめる（メンバーまたはノードが障害を起こす）と、調整部２５０は複合リソース２４０内の別のメンバーがサービスをこの実体に提供するよう手配する。複合リソース内のすべての活性なメンバーは実行時に作業負荷を共有し、障害を起こしたメンバーからサービスを受取っていたコンポーネントのために回復時および修理時に作業負荷を改めて釣り合わせる。

複合リソースの或るメンバーが停止または障害を起こすたびに複合リソースの再評価がなされる。複合リソース２４０のメンバーは引続き、この複合リソースが再評価されるまでこの複合リソースの外側で動作する。複合リソース２４０を回復するための機能は、フレームワーク２６０のリソースおよび／またはフレームワークエージェント２６６により実行される。複合リソース２４０の回復は、個々のメンバー、特定のフレームワークリソース、および／または、その他調整活動を実行するために用いられるリソースの組の一部をなさないリソースにより実行される。

一実施例では、調整部２５０は、１つのノードに常駐する要求側コンポーネントにサービスが提供されるよう手配する。これに代えて、要求側コンポーネントがクライアントコンポーネント２０５などの外部コンポーネントに対応することもあり得る。フレームワークエージェント２６６により実行される調整活動は、複合リソース２４０が利用可能である限り活性である。調整部２５０を設けるのに用いられるリソースは、管理者が複合リソース２４０およびそのメンバー２１４，２２４，２３４と対話するためのインターフェイスを設けるためにもまた用いられ得る。

システム動作の一例として、第１のコンポーネント２１６は複合リソース２４０の提供するサービスを要求する。第１のコンポーネント２１６からの要求は、調整部２５０により表わされるリソースに対して行なわれ得る。調整部２５０は第１のメンバー２１４がサービスを提供するよう手配する。第１のコンポーネント２１６は第１のノード２１０に常駐するので、調整部２５０はこのサービスが第１のメンバー２１４によって第１のコンポーネント２１６に提供されるよう手配し得るが、コンポーネント２１６へのサービスの提供は、その他複合リソースを形成するどのメンバーから行なわれてもよい。サービスを提供するには、第１のメンバー２１４は第１のリソース２１２の利用に依存し得る。たとえば第１のリソース２１２は、他のコンピュータまたはデータベースと通信するための或るインターフェイスまたは下層のアプリケーションに対応し得る。

一実施例に従うと、図１に示したシステムにおいて、複合リソース２４０の或るメンバーがサービスの提供をやめたときにおけるサービスの可用性がもたらされる。第１のメンバー２１４が障害を起こすと、複合リソース２４０の別のメンバーが第１のメンバーと類似の態様でサービスを提供することができる。第１のコンポーネント２１６は、透明に、サービスの受取りにおいて意識されるほどの中断なしに切換わってこの別のメンバーからサービスを受取ることができる。この別のメンバーにより提供されるサービスの品質レベルは類似または等価のレベルとされ得る。したがって、第１のメンバー２１４が障害を起こした場合、調整部２５０は第２のメンバー２２４がサービスをコンポーネント２１６に提供するよう自動的に手配することができる。

１メンバーから別のメンバーへサービスが切換わることを結果として引起こす障害は、ノード全体の障害によるものである場合がある。また、障害がメンバーの障害に限定されノードは依然として機能していることもある。さらに、ノードのリソースが障害を起こし複合リソース２４０が作動できなくなることもある。

図２に示すような例では、図示する障害の種類は第１のメンバー２１４のみの障害であり、ノード２１０および第１のリソース２１２は依然として動作している。障害の検出に応答して調整部２５０は、当該のサービスが第２のノード２２０の第２のメンバー２２４から第１のコンポーネント２１６に提供されるよう自動的に手配する。この切換は透明に行なわれ、すなわちサービスの受取側はサービスが新たな場所から提供されていることを意識しない。しかし、受取側のコンポーネントが中断を受取ることもあり得る。この中断は低レベルのネットワーク活動でのものとされ得るので、ユーザへの中断の影響は透明である。

一実施例では、第２のメンバー２２４は第２のリソース２２２を用いてサービスを提供し、この第２のリソースは第１のリソース２１２と類似の機能を提供する。このような実施例では、メンバー２２４と第２のリソース２２２との間にはローカルな依存性があり得る。しかし依存性がグローバルなものであることもあり、この場合、メンバー２２４があるノードと、第２のリソース２２２の機能を提供するノードとは別々のものである。

サービス依存のリソースの管理
一実施例では、第１のコンポーネント２１６は複合リソース２４０の提供するサービスに依存する。第１のコンポーネント２１６は「弱く依存する」アプリケーションである場合があり、この場合、始動のためには複合リソース２４０のサービスが必要であるが、その後のこれの実行にはサービスは必要でない。その結果、第１のコンポーネント２１６は、第１のコンポーネント２１６を始動させる要求が受取られるたびに複合リソース２４０からサービスを要求し得る。

別の例では、サービスを要求しているコンポーネントはクライアントコンポーネント２０５であり、これはメンバーが常駐するノードの外部にある。この例では、第１のコンポーネント２１６は、複合リソース２４０の提供するサービスに依存するアプリケーションに対応し得る。クライアントコンポーネント２０５は、第１のコンポーネント２１６の提供する機能とともにサービスの利用を必要とし得る。

第１のノード２１０でのメンバーに障害があり、かつ第１のコンポーネント２１６が複合リソース２４０のサービスに依存する場合、第１のコンポーネント２１６は停止されるかまたは他で非活性にされ得る。コンポーネント２０５へのサービスの提供は、その他サービスが供給されるどのノードから行なわれてもよい。たとえばサービスが既に第２のメンバー２２４から利用可能であることがあり、この場合調整部２５０は、第１のメンバー２１４からサービスを受取っていた特定のコンポーネントへ第２のメンバーがサービスを提供するよう手配することができる。したがって、複合リソース２４０のサービスは第２のノード２２０の第２のメンバー２２４からコンポーネント２０５へ提供され得る。実際、複合リソース２４０の一部として第１のメンバー２１４により実行されるジョブのすべてを、第１のメンバー２１４の障害発生時に他のメンバーに対し等しく分散させることができる。コンポーネント２０５にサービスを提供する際には、第２のメンバー２２４は第１のリソース２１２または第２のリソース２２２のいずれを用いてもよい。第２のコンポーネント２２６がクライアントコンポーネント２０５により必要とされており、かつ第２のコンポーネント２２６がサービスに依存している場合、第２のコンポーネント２２６が実行されるのは、サービスが第２のメンバー２２４において始動された後である。

第１のコンポーネント２１６が第１のメンバー２１４に弱く依存しているか、または第１のコンポーネントが第１のメンバー２１４から独立している場合、第１のコンポーネント２１６は第１のメンバーの障害発生時に第１のノード２１０において動作しているよう維持され得る。第１のリソース２１２は第１のメンバー２１４に依存していないため、こ
れはメンバーの障害発生時でもなお第１のノード２１０にある他のアプリケーションまたはコンポーネントで利用されるように動作していることもできる。

障害が第１のノード２１０全体の障害である場合、第１のメンバー２１４の行なっていた作業は複合リソース２４０内の他の活性なメンバー間で共有される。クライアントコンポーネント２０５のためのサービスが第１のノードの障害発生後でも引続き提供され得るように、クライアントコンポーネント２０５に対して、第２のノード２２０にある第２のメンバー２２４にサービスを提供させる。第２のメンバー２２４は第２のリソース２２２を用いてサービスを提供する。第２のコンポーネント２２６が必要とされる場合、これもまた、コンポーネント２０５にサービスを提供するのに用いられる作業の実行を始めることができる。第２のノード２２０での必要に応じて他のリソースを始動することもできる。これら他のリソースが始動される順序は、第２のノード２２０内のリソース間で確立される依存性に基づいて決定され、これには複合リソース２４０と第２のノード内の他のリソースとの間の依存性も含まれる。

第２のノード２２０または第２のメンバー２２４において２つ目の障害が発生した場合には、負荷管理ソフトウェアは、第２のメンバーの行なっていた作業が、複合リソース２４０における他の活性なメンバーに分散されるよう手配する。図２に示す例では、第１のメンバー２１４および第２のメンバー２２４の行なう作業すべては、これらメンバーの障害発生時に第３のノード２３０の第３のメンバー２３４により実行され得る。一実施例では、複合リソース２４０におけるいずれか１つのメンバーの障害によって複合リソースの再評価が引起こされる。この再評価は、調整部２５０により表わされるリソースによって行なわれることもあれば、またはフレームワーク２６０にある他のリソースによることも、もしくは複合リソース２４０のメンバーによることもある。複合リソース２４０全体が障害を起こした場合、複合リソース２４０の回復を開始することができる。一実施例でこれは、サービスを提供するためになお活きているメンバーが他にない場合に対応する。別の実施例では、複合リソースについて最小濃度を指定し、そして活性なメンバーの数がこの濃度を満足させている限り複合リソースは動作していると見なされる。

一実施例では、複合リソース２４０の回復を開始するには、各々のメンバー２１４，２２４，２３４が停止されていることの検証が必要な場合がある。これに対し、複合リソースを形成する各々のメンバー２１４，２２４，２３４の始動が複合リソース２４０の回復の開始に必要な場合もある。これに代えて、複合リソース２４０の回復の開始には、複合リソース２４０についての指定された濃度が、始動したメンバーの数によって満足されていることの検証が必要であることもある。メンバーの始動はメンバーそれ自体によることも、または複合リソース２４０に関連付けられた別のリソースからの或る処置を介することもある。一実施例に従うと、メンバーは互いに対し独立に回復し、１つ以上のメンバーが障害を起こしかつ／または回復するたびに複合リソースが再評価される。この複合体は回復を必要としない（これが動作する物理ノードが故障しない限り）。

仮想複合リソース
図３はもう１つの実施例であって、システム３００が、サービスを提供するための仮想複合リソースを含むように構成されるものを示す。図２に示した実複合リソースと同様、複数のノードからなるクラスタの内部または外部に常駐する実体に対して仮想複合リソース３４０がサービスを提供するシステムを記載する。仮想複合リソースの１つの特徴は、どの１ノードに対する物理的依存性もないことである。むしろ仮想複合リソースは、複合リソースが１つのノードにおいて物理的な場所を有するフレームワークまたはその他のコンポーネントからの処理なしに論理またはソフトウェアの形でさまざまなノードに対して等しくプロセスを分散させる。プロセスを分散させたことにより、クラスタ内のノードのうちいずれか１つが障害を起こしてもプロセスは依然として実行可能である。このように
、仮想複合リソースが用いられる実施例では、実複合リソースの物理的制約への対処がなされるとともに、同じ基本的な機能および特徴が提供される。

一実施例では、システムは第１のノード３１０と、第２のノード３２０と、第３のノード３３０（第ｎのノードを表わす）とを含む。第１のノード３１０は第１のリソース３１２と、第１のメンバー３１４と、第１のコンポーネント３１６とを含む。第２のノード３２０は第２のリソース３２２と、第２のメンバー３２４と、第２のコンポーネント３２６とを含む。同様に、第３のノード３３０は第３のリソース３３２と、第３のメンバー３３４と、第３のコンポーネント３２６とを含む。第１のメンバー３１４、第２のメンバー３２４および第３のメンバー３３４は仮想複合リソース３４０を形成する。

第１のノード３１０、第２のノード３２０および第３のノード３３０の各々にはフレームワークエージェント３６６が常駐する。フレームワークエージェント３６６はフレームワーク３６０と通信する。レジストリ３６２がフレームワーク３６０に設けられる。レジストリ３６２はフレームワークエージェント３６６にとってアクセス可能である。フレームワークエージェント３６６のため、フレームワーク３６０は、複合リソース３４０のメンバーが常駐するノードにわたる単一の論理的実体であると見なすことが可能となる。

仮想複合体
図３において、調整活動を行なうための論理は、フレームワーク３６０に常駐する仮想複合体管理部（ＶＣ）３５０により示される。ＶＣ３５０は、複合リソース３４０の管理および／または調整の活動を行なうためのプロセス、リソースおよび論理の単なる一表現である。ＶＣ３５０はフレームワーク３６０に常駐するように示してあるが、ＶＣを実行するために用いられるコードがノードに常駐することもあり得る。一実施例では、ＶＣ３５０はフレームワーク３６０上で実行可能であるが、またはフレームワークエージェント３６２により等しくすべてのノードによって実行可能であることもある。さらに、フレームワーク３６０によって、仮想複合リソース３４０はどの１つのノードに位置しているとも見なされず、このため仮想複合リソース３４０をノードから独立に動作させることができる。しかしＶＣ３５０は実際には、フレームワーク３６０、フレームワークエージェント３６６および／または複合リソースメンバーによって実行されるコードを含み得る。クラスタ内の１ノードが障害を起こしても、ＶＣ３５０を含むリソースにより実行される活動および機能には影響がない。

ＶＣ３５０を含むリソースにより実行される機能にはメンバー機能の支援または管理が含まれる。メンバー機能にはメンバーの障害後の再始動が含まれ得る。ＶＣ３５０はまた、複合リソースをそのメンバーの状態に基づき再評価することができる。メンバーの１つの障害発生に応答してこの再評価を行なうことができる。複合リソース３４０のメンバーが障害を起こすと、ＶＣ３５０は複合リソース３４０の回復をトリガできる。ＶＣ３５０はまた、１つのメンバーの実行する作業またはジョブを複合リソース３４０における１つ以上の他のメンバーへ再配置することができる。

一実施例で、ＶＣ３５０は、メンバー３１４，３２４，３３４および対応するノード３１０，３２０，３３０についての状態情報を収集するためのコードを実行する。メンバー３１４，３２４，３３４のうち１つについての状態が変化すると、ＶＣ３５０は状態情報を収集し得る。この状態情報は、メンバー３１４，３２４，３３４のいずれかが活きているかどうか、またはこれらメンバーのうち特定の１つが障害のためサービスの提供をやめたかどうかを示すことができる。状態情報の収集は、フレームワーク３６０の内部または外部に位置し得るレジストリ３６２によって行われ得る。ＶＣ３５０はフレームワーク３６０においてすべてのノードから実行可能であるため、ノードの障害がノードに起因するかメンバーに起因するかにかかわらず、ＶＣは複合リソース３４０の特定のメンバーの障
害から隔離されている。

複合リソース３４０はユーザの入力によりシステム上で利用されるように構成され得る。管理者またはその他のユーザからの入力は、複合リソース３４０についての構成情報を特定し得る。構成データを用いて、複合リソース３４０を確立するための先在するプロセスをフレームワーク３６０が含む場合に複合リソース３４０を宣言し、かつこの複合リソースのためのＶＣを実行することができる。その結果、一実施例では、管理者は構成データを入力することにより複合リソース３４０を確立し管理することができ、コードを入力する必要はない。

複合リソース３４０およびＶＣ３５０の動作は、実複合リソース２４０について図２に示したものと類似する。相違点としては、図２では、調整部２５０の常駐するノードが障害を起こした場合には複合リソース２４０が不能化されることがある。図３で示すシステムでは、クラスタ内でどの１ノードあるいはいくつかのノードが障害を起こしても複合リソース３４０は不能化されない。その結果、仮想複合リソース３４０はより信頼性が高い。

複合リソース３４０のサービスへの要求がなされると、ＶＣ３５０は、メンバー３１４，３２４，３３４のうち１つが要求側コンポーネントにサービスを提供するよう手配する。こうして、図３に示すように、第１のコンポーネント３１６がサービスを要求するのに応答して、ＶＣ３５０は第１のメンバー３１４がサービスを提供するよう手配する。第１のメンバー３１４が障害を起こすと、ＶＣ３５０は第２のメンバー３２４がサービスを提供するよう手配する。複合リソース３４０がサービスを提供するためにリソース３１２，３２２，３３２のうち１つに依存する場合、ＶＣ３５０は、第２のメンバーが第１のリソース３１２または第２のリソース３２２のいずれを利用するように定めてもよい。

ノードに障害があった場合、ＶＣ３５０により表わされるリソースは、第２のノード３２０にある第２のメンバー３２４からサービスが提供されるよう手配する。ノードまたはメンバーに障害が発生した場合、クライアントなどの外部コンポーネント３０５はサービスを第２のメンバー３２４から受取ることができる。たとえば第１のコンポーネント３１６が複合リソース３４０に依存しかつ第１のメンバー３１４が障害を起こした場合、第１のコンポーネントへのサービスの提供は第２のメンバー３２４により行なうことができる。これに代えて、第１のノード３１０にある第１のコンポーネント３１６の提供する機能を、第２のノード３２０にある第２のコンポーネント３２６に取って換わらせることもできる。

複合リソース３４０によれば、複合リソースを形成する個々のメンバーの構成および利用を単純化するモデルを使用することが容易となる。より具体的には、複合リソース３４０の提供する分散論理により、ユーザが複合リソースを利用し構成できるようにする際に「匿名性」および「濃度」の概念を用いることが容易となる。匿名性および濃度についてはともに後でより詳細に説明する。匿名性および濃度の概念を仮想複合リソース３４０との関連で説明するが、これらの概念は図２に示す実複合リソースでも実現可能である。しかしこれらの概念は仮想複合リソース３４０において容易にされる。というのもそのメンバーは、メンバー間でサービスを調整するためにどの特定のノードにも依存しないため、可用性をもたらすことを目的としてすべてのノードを等しく扱うことができるからである。これらノードで動作するメンバーを識別するには、これらと複合リソース３４０との関連および、当該のメンバーの常駐するノードの特定のアドレスまたは識別情報を用いればよい。個々のメンバー識別を必要とせずにユーザまたは管理者が複合リソースを全体としてアドレス指定できるようにするために、匿名性および濃度はともに都合がよい。

匿名性
一実施例に従うと、匿名性を達成するために、複合リソース（「実」または「仮想」）のサービスを用いるコンポーネントがこの複合リソース内の個々のメンバーの正確な身元を知る必要なしにこれらリソースを利用できることとする。匿名性により、システムのユーザまたは管理者が複合リソース３４０のメンバーを管理することがより容易となる。匿名性は仮想複合モデルにおいてさらに増強されるが、それはメンバー３１４，３２４，３３４が、少なくともユーザまたは管理者に対しては一意の識別名を有する必要がないからである。またメンバー３１４，３２４，３３４が個々にアドレス指定可能である必要はない。たとえば管理者は、複合リソース３４０についての特定の構成を実現しようとする場合、各々のノードに個々にアドレス指定する必要がない。

一実施例に従うと、ユーザまたは管理者は、仮想複合リソース３４０のメンバーを複合リソースと関連付けることにより識別する。たとえば複合リソース３４０を構成するための命令が特定のサービスを指定することがあり得る。サービスを提供する特定のメンバーに命令を与えるにはこれで十分であろう。これはより伝統的な、複合リソース３４０のメンバーを含む各々のアプリケーションを一意の識別情報およびアドレスにより管理するやり方とは対照的である。

匿名性を達成するには、アプリケーションまたはインスタンスなどのリソースを「ローカル」なリソースとして宣言することがあり得る。「ローカル」なリソースを或る組に属させて、このリソースの識別を、この組の名前とローカルなリソースの常駐するノードの識別情報とによって行なうことができる。たとえばリソースの組をアプリケーションの多数のインスタンスに対応させ、これらインスタンスをアプリケーション名により識別することがあり得る。

数多くのメンバーが存在するシステムでは、メンバーを管理する管理者の作業は大きな労力を要するものとなるが、それは管理者はメンバーを管理するために各々のメンバーの識別情報およびアドレスを指定する必要があるからである。しかし匿名性により、管理者はアプリケーションを管理するために、（個々のメンバーの代わりに）複合リソースと、関心の向けられたメンバーが常駐するノードとを指定すればよい。

一実施例では、フレームワーク３６０はマッピング論理を含むように構成され得る。このマッピング論理は、一意のノード識別情報およびアドレス情報を、複合リソース３４０と、この複合リソースを支援するノードのアドレスとにマッピングするものである。これにより管理者が複合リソース３４０のメンバーを管理する態様が単純化される。

このように、図３に示すようなシステムでは、ローカルなリソースが単一の識別情報により規定可能であり、かつクラスタ全体にわたり、複合リソース３４０を形成するノードのうちいくつかまたはそのすべてで埋込み可能である。このように、メンバーを個々に作動させ、構成し、またはその他で管理するには、複合リソース３４０とメンバーの常駐するノードとを識別するだけでよくなる。この解決法は、現在のノードクラスタ内のリソース管理とは対照的である。後者の場合、各々のリソースは、それ自身の一意の識別情報ならびに、そのノードおよびその下部構造の識別情報および／またはアドレスによって識別される。

濃度
一実施例に従うと、濃度とは複合リソースにおける活性なメンバーの数を指す。複合リソースのメンバー同士の重要性が異ならない場合、複合リソースにより提供されるサービスについての或るレベルを特定するには、複合リソースの濃度だけで十分である。

別の実施例では、濃度はいくつかの性能基準によって測られ得る。たとえば濃度は、仮想複合リソース３４０の提供するサービス時間に対応することがあり得る。

一実施例では、濃度は、最低限のサービスレベルが複合リソースにより提供されているかどうかを判断するために用いられる。たとえば管理者は、活きているメンバーの数が「１」またはその他の数と等しいまたはこれを上回る限り複合リソースが活きているとみなされると指定することができる。

別の実施例では、濃度は複合リソース３４０の構成の際に用いられ得る。たとえば管理者は、複合リソース３４０を構成するために、指定の数のメンバーにおいて実現されることになる構成情報を指定することがあり得る。

別の例では、濃度は複合リソース３４０の提供するサービスを拡張するために用いられる。濃度の指定を増大させることにより、複合リソース３４０が実行する作業を増大させることができる。管理者は濃度の指定を用いる際、サービスを提供する特定のメンバーまたはノードについての情報を指定する必要がない。このように、濃度と匿名性とは互いを容易にすることができる。

サービスレベルに基づく複合リソースメンバーの管理
図４は、サービスレベルに基づく複合リソースの複数のコンポーネントを管理する方法を示す。図４に示す方法は、図２または図３に示したようなシステムで実現可能である。しかし説明上、この方法の各ステップについて説明する際には図３における要素を参照する。

ステップ４１０にて、ノード３１０，３２０，３３０にそれぞれ常駐するメンバー３１４，３２４，３３４を用いて複合リソース３４０を確立する。複合リソース３４０を形成するメンバーは各々が類似のサービスを提供することができる。複合リソース３４０は均質である、すなわち各々のメンバー３１４，３２４，３３４が実質的に等価のサービスを提供することがあり得る。これに代えて、複合リソース３４０が不均質であり、すなわち、サービスの品質またはサービスを実行する態様における差異に対応し得る不均質な属性を有することもあり得る。

ステップ４２０にて、管理者の入力したデータにより複合リソース３４０を構成する。一実施例では、この構成は複合リソース３４０についてのサービスレベルを指定し得る。具体的には、この構成データは、複合リソース３４０の濃度、サービス時間により測られる全体的なサービスレベル、またはスループットにより測られる全体的なサービスレベルなどの特徴を指定することができる。さらにまた、構成データは、複合リソース３４０およびそのメンバー３１４，３２４，３３４を作動または回復させる態様についての他の情報を指定することもある。たとえば構成データが指定し得るものとしては、複合リソース３４０がどのリソースを必要とするか、さらにはどのコンポーネントが複合リソース３４０を必要とするかに関して存在すると仮定される（弱いおよび強い）依存性がある。

ステップ４３０にて、複合リソース３４０のメンバー３１４，３２４，３３４の各々から状態情報を収集する。このステップを行なうには、複合リソース３４０についての確認処置を実行すればよい。状態情報の収集は、ＶＣ３５０を形成する論理要素またはプロセスによってなされ得る。たとえば各々のノードがＶＣ３５０の一部としての論理を含む場合がある。この論理は、この特定のノードにあるメンバーについての状態情報を収集することができる。この状態情報はレジストリ３６２に格納され得る。一実施例では、状態情報は、或る特定のメンバーが活きているか、または動作をやめたかに対応する。状態情報はまた、特定のメンバーの状態の変化に応答して収集されることもある。

ステップ４４０にて、複合リソース３４０のサービスレベルを、複合リソース３４０が非活性であることに対応する指定されたレベルと比較するための判断がなされる。一実施例では、この指定のレベルは管理者によって指定される。たとえばサービスレベルは特定ユーザの濃度に対応することがあり、この場合作動しているメンバーの数はこの濃度と等しいまたはこれを上回る必要がある。別の例として、サービスレベルは、複合リソース３４０により実行され得る最高のサービス品質の割合または比に対応することもある。

ステップ４４０にて複合リソース３４０が利用可能であると判断された場合、ステップ４５０にて、ＶＣ３５０は、複合リソース３４０内のメンバーのうち１つ以上によりサービスが要求側コンポーネントへ提供されるよう手配する。サービスが提供されるのは、サービスのレベルが、サービスが利用可能でないことに対応すると判断されるまでである。サービスが指定のレベルを上回っている限り、ＶＣ３５０は、メンバー３１４，３２４，３３４のうち少なくとも１つが要求側コンポーネントに複合リソース３４０のサービスを提供することを確実にする。サービスを提供するよう手配されているメンバーが障害を起こした場合、ＶＣ３５０は、活性である別のメンバーがサービスを要求側コンポーネントに提供するよう手配できる。上述のように、メンバー間の遷移は継ぎ目なく行なわれ得るので、メンバー間の切換は要求側コンポーネントの視点からは判別不可能である。

ステップ４４０にて複合リソース３４０が利用可能でないと判断された場合、複合リソース３４０はオフラインになる。そして、メンバーを再始動させて複合リソース３４０の再評価を引起こすことができる。このように複合リソース３４０は、存在するメンバーの機能として存在することになる。これに代えて、複合リソース３４０を拡張して、複合リソース３４０を利用可能にするであろう追加のサービスを提供することもできる。たとえば複合リソースの濃度を拡張させることがあり得る。たとえば複合リソースが１組の非活性なメンバーを確立し、これら非活性なメンバーを複合リソース３４０における活性なメンバーのための予備ノードとすることがあり得る。複合リソース３４０のサービスを拡張する場合、ＶＣ３５０のリソースは予備または非活性なメンバーから１つ以上のメンバーを活性化する。

関心の向けられたイベントの監視
図５は、関心の向けられたフレームワークイベントを即座に検出し、先回りしてこれと通信するように構成されたシステムを例示する。図５に示すようなシステムは図２および図３に示したシステムで実現可能である。図３の各要素を参照するが、これは図５に示す実施例を実施するための例示のコンポーネントを説明することを意図したものである。

システム５００は、ノード５３０において実行されるアプリケーションインスタンス５１０を含む。ノード５３０はフレームワークエージェント５４０を含み、これらフレームワークエージェントは、ノードからなるクラスタが共有するフレームワークと通信する。一実施例に従うと、アプリケーションインスタンス５１０と連結されて、イベントの発生直後に関心の向けられたイベントを検出するモニタ５２０が設けられる。モニタ５２０は、関心の向けられたイベント５２４が発生するとイベント通知５２２を通信する。フレームワークエージェント５４０は予め定められた間隔でアプリケーションインスタンス５１０に対してポーリング動作５２６を実行し、これによりアプリケーションインスタンスの状態を判断する。関心の向けられたイベント５２４はアプリケーションインスタンス５１０の状態を変化させることがあるため、その場合、イベントが発生するのに伴い、モニタ５２０はフレームワークエージェント５４０に対し、これがポーリングを通じ他でも入手したであろう同じ情報を提供することになる。したがって、ポーリング動作５２６とモニタ５２０との行なう機能は重なり合うことがあり得る。この冗長性によりシステム５００の信頼性が確保される。ノード５３０の動作中に、モニタ５２０がアプリケーションイン
スタンス５１０について信頼できるものであるとわかることがあるが、この場合、ポーリングをイベントシステムおよびアプリケーションレベルのモニタに完全に取って換わらせることができる。そうでなければ、ポーリングおよび監視をともに用いて、関心の向けられたイベントの検出を高速かつ信頼できるものにすることができる。

一実施例では、関心の向けられたイベントはフレームワーク５４０の利用する状態をカバーする。これに従い、イベントは以下の（ｉ）から（ｖ）に対応し得る。すなわち、（ｉ）アプリケーションインスタンス５１０が始動するとき、（ｉｉ）アプリケーションインスタンス５１０が別のノードへ再配置されるとき、（ｉｉｉ）アプリケーションインスタンス５１０が停止されるが障害は起こしていないとき、（ｉｖ）アプリケーションインスタンス５１０が停止されかつ障害を起こしたとき、および（ｖ）アプリケーションインスタンスが動作していると確認されるとき、である。これらイベントのうち１つが検出されれば、フレームワークエージェント３６２が開始されて或る処置を実行することができる。この処置はさらにＶＣ３５０をトリガして、その活動、たとえば確認の開始または回復の開始のうち１つを実行させることができる。

図３に示す構成では、モニタ５２０はメンバー３１４，３２４，３３４の各々について確立される。モニタ５２０は、たとえば、別のコンポーネントからの要求に応答して第１のメンバー３１４が複合リソース３４０のサービスを提供することをやめるまたはやめようとしているときを検出する。モニタ５２０から送られたイベント通知５２２は障害をフレームワーク３６０に通信する。通信が与えられるのに応答して、フレームワーク３６０に常駐するＶＣ３５０は、複合リソース３４０の第２のメンバー３２４がサービスを提供するよう手配する。

どのメンバーがサービスを提供するかの選択は、ＶＣ３５０の一部として実行されるフレームワークエージェント５４０により実行され得る。メンバーに障害が生じた場合に、或る特定のジョブについてどのメンバーがサービスを提供するかの選択は回復ポリシーに従って決定される。各々のメンバーの状態は、このメンバーが別のコンポーネントのために始動した（そのため利用不可能である）のか、障害を起こしたのか、停止されているが障害は起こしていないのか、活きていると確認されているのか、または再配置されているのかどうかに基づき得る。

これに代えて、状態情報のうちいくらかまたはそのすべてをフレームワーク５４０のポーリング機能５２６によって入手することもできる。モニタ５２０が常に信頼できるとは限らない。たとえばモニタ５２０がメンバー５１０またはノードとともに障害を起こすことがあり得る。このような場合には、ポーリング機能を実行するフレームワーク５４０が信頼できるバックアップを提供し得る。

可能化／不能化機能
複合リソースのメンバーが受ける障害には計画的なものと非計画的なものとがある。計画的な障害としてはたとえば整備のために実行されるものがある。非計画的な障害が起こり得るのは、或るメンバーが障害を起こしたときか、またはこれが別の障害を起こしたリソースに依存するときである。このような場合、このメンバーをシステムから外してしまうことが有益である。図２および図３に示すシステムでは、このメンバーをフレームワークの制御から外すことが有益である。このことは、メンバーは障害を起こしたら自動的に再始動可能であるべきではないことを意味する。むしろこのメンバーは、このメンバーまたはこれが依存するリソースを修理する修正処置がとられるまで不能化されたままであるのがよい。

図６は、メンバーの障害発生時に複合リソースを管理するための基本的な技術を例示す
る。図７は、ノードが不能化された後に複合リソースを管理するための別の技術を例示する。ここでの記載には図３における番号を参照するが、これは記載の技術で用いられる例示のコンポーネントを説明することを目的としたものである。

図６を参照すると、ステップ６１０にて、ノード３１０，３２０，３３０からなるクラスタにある複数のメンバー３１４，３２４，３３４から複合リソースを確立する。説明上、第１のメンバー３１４が最初にサービスを提供すると仮定する。

ステップ６２０にて、第１のメンバー３１４がサービスの提供をやめたという判断がなされる。この判断はたとえばフレームワークエージェント５４０により行なわれ、モニタ５２０を介し、またはポーリング機能を通じて第１のメンバー５１０と相談することによってなされ得る。

ステップ６３０にて、このメンバーを不能化してこのメンバーでの整備機能を実行する。この整備機能は手動であることも自動的であることもある。第１のノードが不能化される場合、第１のメンバー３１４は再始動できない。第１のメンバー３１４はこの後で可能化されるまで不能化され非活性であり続ける。換言すると、第１のメンバー３１４の不能化は持続的なものである。このため、このメンバーが不能化され第１のノードが撤去された場合、第１のノードを再始動しても第１のメンバー３１４の再始動が自動的に引起こされるわけではない。

メンバーまたはそのノードの不能化が計画的な整備の一部のこともある。したがって或るメンバーの障害がノードの不能化をトリガするとは限らない。一実施例では、障害が生じてもメンバーの不能化は引起こされない。むしろ、不能化は計画的な処置であって、ノードにおける大規模な修理および計画的な作業のために用いられるものである。

図７の方法を参照すると、ステップ７１０にて第１のメンバー３１４を再始動させる要求が受取られる。この要求が受取られるのは、第１のメンバー３１４が複合リソース３４０のサービスの実行をやめた後である。

ステップ７２０にて、特定のメンバーが可能化されているかまたは不能化されているかについての判断が行なわれる。状態の検索はレジストリ３６２からなされることも、またはフレームワーク３６０に連結された別のメモリコンポーネントからなされることもある。こうしてレジストリ３６２は、メンバー３１４がサービスの提供をやめる直前に可能化または不能化されたことを記録することができる。

ステップ７２０で第１のメンバー３１４が不能化されていると判断された場合、ステップ７３０にて第１のメンバー３１４は再始動されない。これは第１のメンバー３１４が計画的な整備を受けているときに起こり得る。一実施例では、これがＶＣ３５０をトリガし、これによりＶＣ３５０は、複合リソース３４０内のメンバーのうち別の１つからサービスが要求側コンポーネントへ提供されるよう手配することができる。

ステップ７２０で第１のメンバー３１４が可能化されていると判断された場合、ステップ７４０にて第１のメンバー３１４を自動的に再始動する試みがなされる。第１のメンバーが再始動され得る場合、第１のメンバーは複合リソース３４０に再び参加することができる。

図７に示すように、複合リソースの各メンバーの可能化／不能化の状態は持続的でかつ、このメンバーを再始動させる試みがなされるかどうかを決定するものとされ得る。このメンバーを不能化してこれが立上げプロセスの間に自動的に再始動されないようにするこ
とができる。

不能化／可能化状態を複合リソースへと拡張させることもできる。複合リソースを全体として不能化することでメンバーすべてが不能化することがあり得る。これに代えて複合リソースを可能化することもあり、これは不能化されていないメンバーすべての可能化を引起こすことになる。したがって、個々のメンバーの不能化は複合リソースの可能化に優先する。その結果、障害を起こしたメンバーは複合リソース全体を不能化することなく管理され得る。

ハードウェア概観
図８は、この発明の一実施例が実現され得るコンピュータシステム８００を示すブロック図である。コンピュータシステム８００は、バス８０２またはその他情報を通信するための通信機構と、バス８０２に結合され情報を処理するプロセッサ８０４とを備える。コンピュータシステム８００はさらにランダムアクセスメモリ（ＲＡＭ）またはその他の動的記憶装置などの主メモリ８０６を備え、これはバス８０２に結合されて、プロセッサ８０４が実行する命令および情報を記憶する。主メモリ８０６はまた、プロセッサ８０４が命令を実行している間に一時的な変数またはその他の中間情報を蓄積するためにも用いられる。コンピュータシステム８００はさらに、バス８０２に結合されてプロセッサ８０４のための静的情報および命令を記憶する読出専用メモリ（ＲＯＭ）８０８またはその他の静的記憶装置を備える。バス８０２に結合されて情報および命令を記憶するための磁気ディスクまたは光ディスクなどの記憶装置８１０が設けられる。

コンピュータシステム８００はバス８０２を介して、情報をコンピュータユーザに対して表示するための陰極線管（ＣＲＴ）などの表示装置８１２に結合され得る。英数字式キーおよびその他のキーを含む入力装置８１４がバス８０２に結合されて情報およびコマンド選択をプロセッサ８０４に通信する。別の種類のユーザ入力装置として、マウス、トラックボールまたはカーソルキーなどのカーソル操作装置８１６があり、これにより方向情報およびコマンド選択をプロセッサ８０４に通信し、ディスプレイ８１２におけるカーソルの動きを制御する。一般的にこの入力装置は、第１の軸（たとえばｘ）および第２の軸（たとえばｙ）の２本の軸上における２自由度を有し、これにより入力装置は或る平面上の位置を指定することができる。

この発明は、コンピュータシステム８００を使用してここに記載された技術を実現することに関する。この発明の一実施例に従うと、プロセッサ８０４が、主メモリ８０６に入っている１つ以上の命令からなる１つ以上のシーケンスを実行するのに応答して、ここに記載された技術がコンピュータシステム８００により実行される。このような命令は別のコンピュータ読取可能な媒体、たとえば記憶装置８１０から主メモリ８０６に読込まれ得る。主メモリ８０６に入っている命令シーケンスが実行されるのに伴い、プロセッサ８０４においてここに記載されたプロセスステップが実行される。これに代わる実施例では、ソフトウェアによる命令に代えて、またはこれと組合せて、ハードウェア回路を用いてこの発明を実現することもある。したがってこの発明の実施例は、ハードウェア回路およびソフトウェアのいかなる特定の組合せにも限定されない。

ここで用いる「コンピュータ読取可能な記憶媒体」という用語は、命令をプロセッサ８０４が実行できるようここに供給することに関与するあらゆる媒体を指す。このような媒体は多くの形態をとることができ、これには不揮発性媒体、揮発性媒体および伝送媒体が含まれるがこれに限定されない。不揮発性媒体にはたとえば、記憶装置８１０などの光ディスクまたは磁気ディスクが含まれる。揮発性媒体には主メモリ８０６などの動的記憶装置が含まれる。伝送媒体には同軸ケーブル、銅線および光ファイバが含まれ、これにはバス８０２を構成するワイヤが含まれる。伝送媒体はまた音波または光波の形態をとること
もでき、これにはたとえば電波通信および赤外線データ通信の際に生成されるものなどがある。

コンピュータ読取可能な記憶媒体の一般的な形態にはたとえば、フロッピー（登録商標）ディスク、フレキシブルディスク、ハードディスク、磁気テープ、またはその他任意の磁気媒体、ＣＤ−ＲＯＭ、その他任意の光媒体、パンチカード、紙テープ、その他任意の孔パターンによる物理的媒体、ＲＡＭ、ＰＲＯＭ、ＥＰＲＯＭ、ＦＬＡＳＨ−ＥＰＲＯＭ、その他任意のメモリチップまたはカートリッジ、後に記載する搬送波、またはその他コンピュータが読出可能な任意の媒体が含まれる。

１つ以上の命令からなる１つ以上のシーケンスを、プロセッサ８０４が実行できるようここへ伝達することには、さまざまな形態のコンピュータ読取可能な記憶媒体が関与し得る。たとえば、命令はまず遠隔コンピュータの磁気ディスクに収められ得る。この遠隔コンピュータは命令を自分の動的メモリにロードして、モデムを用いて電話回線経由でこれら命令を送信し得る。コンピュータシステム８００に対してローカルなモデムが電話回線上のデータを受信し、赤外線送信機を用いてこのデータを赤外線信号に変換し得る。赤外線信号で搬送されたデータは赤外線検出器で受信され、適当な回路がこのデータをバス８０２に出力することになる。バス８０２はデータを主メモリ８０６へと伝達し、ここからプロセッサ８０４は命令を検索および実行する。任意には、主メモリ８０６が受取った命令は、プロセッサ８０４による実行前または実行後に記憶装置８１０に記憶される。

コンピュータシステム８００はさらに、バス８０２に結合された通信インターフェイス８１８を含む。通信インターフェイス８１８は、ローカルネットワーク８２２に接続されたネットワークリンク８２０に対する２方向データ通信結合を行なうものである。たとえば通信インターフェイス８１８として統合デジタル通信サービス網（ＩＳＤＮ）カードまたはモデムを用いることができ、これにより対応する種類の電話回線に対するデータ通信接続を行なう。別の例として、通信インターフェイス８１８はローカルエリアネットワーク（ＬＡＮ）カードを用いてもよく、これにより対応するＬＡＮに対するデータ通信接続を行なう。無線リンクもまた実現可能である。このような実現例のいずれにおいても、通信インターフェイス８１８は、さまざまな種類の情報を表わすデジタルデータの流れを搬送する電気信号、電磁信号または光信号を送受信する。

一般的にネットワークリンク８２０は、１つ以上のネットワーク経由で他のデータ装置に対するデータ通信を可能にする。たとえばネットワークリンク８２０はローカルネットワーク８２２経由で、ホストコンピュータ８２４、または、インターネットサービスプロバイダ（ＩＳＰ）８２６の稼動させるデータ装置に対する接続を行なうことができる。そしてこのＩＳＰ８２６は、現在一般的に「インターネット」と称される全世界規模パケットデータ通信網８２８を通じてデータ通信サービスを提供する。ローカルネットワーク８２２およびインターネット８２８ではともに、デジタルデータの流れを搬送する電気信号、電磁信号または光信号を使用される。このようにさまざまなネットワークを経由する信号や、デジタルデータをコンピュータシステム８００に入出力するネットワークリンク８２０上および通信インターフェイス８１８経由の信号は、情報を運ぶ搬送波の形態の例である。

コンピュータシステム８００は、ネットワーク、ネットワークリンク８２０および通信インターフェイス８１８を通じてメッセージを送信し、プログラムコードを含むデータを受信することができる。インターネットの例では、サーバ８３０は或るアプリケーションプログラムについての要求されたコードを、インターネット８２８、ＩＳＰ８２６、ローカルネットワーク８２２、そして通信インターフェイス８１８経由で送信することがあり得る。

こうして受信されたコードは、受信されるとプロセッサ８０４により実行され、かつ／または記憶装置８１０もしくはその他の不揮発性記憶装置内で、後で実行されるように蓄積され得る。このようにコンピュータシステム８００は搬送波の形でアプリケーションコードを入手し得る。

以上の明細書においては、この発明をその特定の実施例を参照して記載した。しかし、この発明のより広い意味および範囲から逸脱することなく、さまざまな変形および変更がこの発明で可能であることが明らかであろう。したがってこの明細書および図面は、限定としてでなく例示的な意味で考えられるべきである。

ノードクラスタにおいて複合リソースを用いてサービスを提供する方法を示す図である。 複数のノードからなるクラスタにおいて実複合リソースを確立し利用する基本的なシステムを例示する図である。 複数のノードからなるクラスタにおいて仮想複合リソースを確立し利用する別の基本的なシステムを示す図である。 複合リソースにおける複数のメンバーをサービスレベルに基づき管理する方法を示す図である。 関心の向けられたイベントを即座に検出するように構成されたシステムを例示する図である。 メンバーの障害発生時に複合リソースを管理する基本的な技術を例示する図である。 ノードの不能化の後に複合リソースを利用する別の技術を示す図である。 この発明の一実施例が実現され得るコンピュータシステムを例示するブロック図である。

Claims (56)

1. フレームワークから複数のコンポーネントを管理する方法であって、
   複数のメンバーを含む複合リソースを確立するステップを含み、前記複数の前記メンバーにおける各々のメンバーは類似のサービスを提供することができ、前記方法はさらに、
   フレームワークリソースを用いて前記複合リソース内の各々のメンバーの状態を監視するステップと、
   前記類似のサービスを要求するコンポーネントに前記フレームワークリソースから前記サービスを要求させるステップと、
   前記サービスを前記コンポーネントに提供するステップとを含み、前記提供するステップは、
   前記サービスが前記複合リソース内の特定のメンバーにより前記コンポーネントへ提供されるよう前記フレームワークリソースにより手配し、さらに、
   前記特定のメンバーが活性でなくなったときに、別のメンバーにより既に提供されている前記サービスを自動的に利用し、かつ／または、前記サービスが前記複数のメンバーのうちの別のメンバーにより前記コンポーネントに提供されることを引起こすことによって行なわれ、前記方法はさらに、
   前記複合リソース内の各々のメンバーの状態から独立に前記複合リソースの状態を維持するステップを含む、方法。
2. 前記複数のメンバーは、１組の活性なメンバーおよび１組の非活性なメンバーを含み、前記１組の活性なメンバーにおけるメンバーは、前記１組の非活性なメンバーにおけるメンバーが用いる態様とは異なる態様で前記類似のサービスを提供する、請求項１に記載の方法。
3. 前記複数のメンバーにおけるメンバーのうちの１つ以上が活性でなくなることに応答して前記複合リソースを評価するステップをさらに含む、請求項１に記載の方法。
4. ユーザ定義の基準に基づいて前記フレームワークリソースを介し前記複合リソースを構成するステップをさらに含む、請求項１に記載の方法。
5. 前記フレームワークリソースを用いて前記複合リソースを停止するステップをさらに含み、こうして前記複数のメンバーにおける各々のメンバーが停止される、請求項１に記載の方法。
6. 前記１組の活性なメンバーのうちのメンバーが常駐するノードから別のノードへ前記複合リソースのソースを再配置するステップをさらに含み、前記別のノードには、前記ソースを再配置するステップの実行直前に前記１組の非活性なメンバーのうちのメンバーが常駐し、前記複数の非活性なメンバーのうちの少なくとも１つ以上は前記第１の複数のメンバーの１つでもない、請求項１に記載の方法。
7. 前記フレームワークリソースから前記複合リソースの性能特性を測定するステップをさらに含む、請求項１に記載の方法。
8. 管理者が調整部に命令して前記フレームワークリソースを介し前記複合リソースにおいて１つ以上の動作を実行させることを可能にするためのインターフェイスを設けるステップをさらに含む、請求項１に記載の方法。
9. 前記複数のメンバーのうちのどれが前記類似のサービスを提供するかにかかわらず、１つ以上のリソースが前記類似のサービスに依存することを可能にするステップをさらに含
   む、請求項１に記載の方法。
10. 前記複合リソースを確立するステップは、前記複数のメンバーの各々が前記メンバーのノードにある１組のリソースとともに利用されることを可能にするステップを含み、前記メンバーのノードにある前記１組のリソースは前記サービスを提供するために前記メンバーにより必要とされる、請求項１に記載の方法。
11. 前記サービスを前記コンポーネントに提供するステップは、
    前記サービスが前記複合リソースのうちの第１のメンバーにより前記第１のメンバーのノードから前記コンポーネントに提供されるよう手配するステップと、
    前記第１のメンバーが障害を起こしたときに、前記複数のメンバーのうちの第２のメンバーにより前記サービスが前記第２のメンバーのノードから前記コンポーネントに提供されることを引起こすステップとを含み、前記第２のメンバーのノードは前記第１のメンバーのノードとは異なり、
    前記第１のメンバーの障害に先立ち、前記方法はさらに、前記第２のメンバーのノードにある１組のリソースを用いて前記第２のメンバーが前記サービスを前記コンポーネントに提供することを可能にするステップを含み、前記第２のメンバーのノードにある前記１組のリソースは、前記サービスを提供するために前記第２のメンバーにより必要とされる、請求項１に記載の方法。
12. 前記サービスを前記コンポーネントに提供するステップは、前記複数のノードにより共有されるデータソースからのデータの読出および前記データソースへのデータの書込のうち少なくとも１つを実行するステップを含む、請求項１に記載の方法。
13. 前記第１のメンバーが障害を起こしているが前記第１のメンバーのノードはまだ機能していることを検出するステップをさらに含み、前記サービスが第２のメンバーにより前記コンポーネントに提供されることを引起こすステップは、前記第１のメンバーのノードにある前記１つ以上の他のリソースが機能している間に行なわれる、請求項１１に記載の方法。
14. 前記第１のメンバーが障害を起こしたことを検出した後に前記第１のメンバーを自動的に再始動するステップをさらに含む、請求項１３に記載の方法。
15. 前記サービスが第２のメンバーにより前記コンポーネントに提供されることを自動的に引起こすステップは、前記第１のメンバーの回復を試みている間に実行される、請求項１３に記載の方法。
16. 前記複合リソースを確立するステップは、データベースアプリケーションの複数のインスタンスが複数のノードにおいて実行されることを可能にするステップを含む、請求項１に記載の方法。
17. 前記複合リソースが、前記複数のノードにおけるノードの１つに少なくとも部分的に常駐するように見えるように、前記フレームワークから前記複合リソースを実行するステップをさらに含む、請求項１に記載の方法。
18. 前記複数のノードにより共有されるフレームワークにおいて前記調整部を実行するステップをさらに含む、請求項１に記載の方法。
19. 第１のノードにおいてアプリケーションを実行するステップをさらに含み、前記アプリケーションは前記複合リソースに依存する、請求項１に記載の方法。
20. 前記複数のメンバーのうちの第１のメンバーから前記アプリケーションに前記サービスを提供するステップをさらに含み、前記第１のメンバーは前記第１のノードに常駐し、前記第１のメンバーが前記サービスの提供をやめることに応答して、前記方法はさらに前記アプリケーションの実行を終了させるステップを含む、請求項１９に記載の方法。
21. 前記複数のメンバーのうちの第１のメンバーから前記アプリケーションに前記サービスを提供するステップをさらに含み、前記第１のメンバーは前記第１のノードに常駐し、前記第１のメンバーが前記サービスを提供しなくなることに応答して、前記方法はさらに、第２のノードに常駐する前記複数のメンバーのうちの第２のメンバーから、前記第１のノードにおいて実行される前記アプリケーションに前記サービスを提供するステップを含む、請求項２０に記載の方法。
22. さらに、
    前記複合リソースが機能している間に前記複合リソースの一部としてメンバーを加入させるステップと、
    前記第１のメンバーが前記複合リソースのメンバーとして加入させることに応答して、前記複合リソースが作動していることを前記メンバーに保証させることを引起こすステップとを含む、請求項１に記載の方法。
23. 複数のコンポーネントを管理する方法であって、
    第１の複数のメンバーを含む第１の複合リソースを確立するステップを含み、前記第１の複数のメンバーは複数のノードに常駐し、前記第１の複数のメンバーの各々はサービスを同等に提供するよう活性であり、前記方法はさらに、
    第２の複数のメンバーを確立するステップを含み、前記第２の複数のメンバーは前記複数のノードに常駐し、前記第２の複数のメンバーの各々は、活性化されると前記サービスを同等に提供することができ、前記方法はさらに、
    前記第１の複数のメンバーにおけるメンバーが、前記サービスを要求する第１のコンポーネントに前記サービスを提供するよう手配するステップを含み、前記第１のメンバーは前記複数のノードのうちの第１のノードに常駐し、前記方法はさらに、
    前記第１の複数のメンバーにおけるメンバーのうちの１つ以上が非活性になることに応答して、
    前記第１の複数のメンバーにおけるメンバーのうちの１つ以上が非活性になることに応答して前記第２の複数のメンバーのうちの第２のメンバーを活性化するステップ、および、前記第１の複数のメンバーまたは前記第２の複数のメンバーのうちの一方にある活性な第２のメンバーを用いて前記サービスを自動的に提供するステップ
    を実行するステップとを含む、方法。
24. 前記複合リソースの状態は、複合リソース内の活性な各々のメンバーの状態から独立して維持される、請求項２３に記載の方法。
25. 前記第１の複数のメンバーのうちの１つにある活性な第２のメンバーを用いて前記サービスを自動的に提供するステップは、前記複合リソースのサービスを活性的に提供するメンバーの濃度を維持するステップを含む、請求項２３に記載の方法。
26. 前記第２の複数のメンバーにおける多数のメンバーを活性化して前記サービスを提供させることにより前記濃度を拡張するステップをさらに含む、請求項２４に記載の方法。
27. 前記第１の複数のメンバーのうちの第１のメンバーが前記第１のサービスを提供するよう手配するステップは、前記第１の複数のメンバーおよび前記第２の複数のメンバーによ
    り共有されるフレームワークのリソースを用いて行なわれる、請求項２２に記載の方法。
28. フレームワークリソースを介し、前記第１の複数のメンバーおよび前記第２の複数のメンバーについての状態情報を維持するステップをさらに含む、請求項２６に記載の方法。
29. 複数のコンポーネントを管理するための１つ以上の命令シーケンスを担うコンピュータ読取可能な記憶媒体であって、１つ以上のプロセッサによる前記１つ以上の命令シーケンスの実行は、前記１つ以上のプロセッサに、
    複数のメンバーを含む複合リソースを確立するステップを実行させ、前記複数の前記メンバーにおける各々のメンバーは類似のサービスを提供することができ、前記１つ以上のプロセッサにさらに、
    調整部において前記複合リソース内の各々のメンバーの状態を監視するステップと、
    前記類似のサービスを必要とするコンポーネントに前記サービスを前記調整部に要求させるステップと、
    前記サービスを前記コンポーネントに提供するステップとを実行させ、前記提供するステップは、
    前記調整部により、前記サービスが前記複合リソース内の特定のメンバーにより前記コンポーネントへ提供されるよう手配し、さらに、
    前記特定のメンバーが活性でなくなったときに、別のメンバーにより既に提供されている前記サービスを自動的に利用し、かつ／または、前記サービスが前記複数のメンバーのうちの別のメンバーにより前記コンポーネントに提供されることを引起こすことによって行なわれ、前記１つ以上のプロセッサにさらに、
    前記複合リソース内の各々のメンバーの状態から独立して前記複合リソースの状態を維持するステップを実行させる、コンピュータ読取可能な記憶媒体。
30. 前記複数のメンバーは第１のメンバーおよび第２のメンバーを含み、前記第１のメンバーは、前記第２のメンバーが前記類似のサービスを提供するために用いる態様とは異なる態様で前記類似のサービスを提供する、請求項２９に記載のコンピュータ読取可能な記憶媒体。
31. 前記複数のメンバーにおける各々のメンバーが活性でなくなったときに前記複合リソースの回復を開始させるための命令をさらに含む、請求項２９に記載のコンピュータ読取可能な記憶媒体。
32. ユーザ定義の基準に基づいて前記調整部を介し前記複合リソースを構成するための命令をさらに含む、請求項２９に記載のコンピュータ読取可能な記憶媒体。
33. 前記調整部を用いて前記複合リソースを停止するための命令をさらに含み、こうして前記複数のメンバーにおける各々のメンバーは前記類似のサービスを提供することができなくなる、請求項２９に記載のコンピュータ読取可能な記憶媒体。
34. 前記第１の複数のメンバーが常駐する第１の複数のノードから、第２の複数のメンバーが常駐する第２の複数のノードへ前記複合リソースを再配置するための命令をさらに含み、前記第２の複数のメンバーのうちの少なくとも１つ以上は前記第１の複数のメンバーの１つでもない、請求項２９に記載のコンピュータ読取可能な記憶媒体。
35. 前記調整部から前記複合リソースの性能特性を測定するための命令をさらに含む、請求項２９に記載のコンピュータ読取可能な記憶媒体。
36. 管理者が前記調整部に命令して前記調整部を介し前記複合リソースにおいて１つ以上の
    動作を実行させることを可能にするためのインターフェイスを設けるための命令をさらに含む、請求項２９に記載のコンピュータ読取可能な記憶媒体。
37. 前記複数のメンバーのうちのどれが前記類似のサービスを提供するかにかかわらず、１つ以上のリソースが前記類似のサービスに依存することを可能にするための命令をさらに含む、請求項２９に記載のコンピュータ読取可能な記憶媒体。
38. 前記複合リソースを確立するための命令は、前記複数のメンバーの各々が前記メンバーのノードにある１組のリソースとともに利用されることを可能にするための命令を含み、前記メンバーのノードにある前記１組のリソースは前記サービスを提供するために前記メンバーにより必要とされる、請求項２９に記載のコンピュータ読取可能な記憶媒体。
39. 前記サービスを前記コンポーネントに提供するための命令は、
    前記サービスが前記複合リソース内の第１のメンバーにより前記第１のメンバーのノードから前記コンポーネントに提供されるよう手配するステップと、
    前記第１のメンバーが活性でなくなったときに、前記サービスが前記複数のメンバーにおける第２のメンバーにより前記第２のメンバーのノードから前記コンポーネントに提供されることを引起こすステップとを実行するための命令を含み、前記第２のメンバーのノードは前記第１のメンバーのノードとは異なり、
    前記第１のメンバーが活性でなくなる前に、前記コンピュータ読取可能な記憶媒体はさらに、前記第２のメンバーのノードにある１組のリソースを用いて前記第２のメンバーが前記サービスを前記コンポーネントに提供することを可能にするステップを含み、前記第２のメンバーのノードにある前記１組のリソースは、前記サービスを提供するために前記第２のメンバーにより必要とされる、請求項２９に記載のコンピュータ読取可能な記憶媒体。
40. 前記サービスを前記コンポーネントに提供するための命令は、前記複数のノードにより共有されるデータソースからのデータの読出および前記データソースへのデータの書込のうち少なくとも１つを実行するための命令を含む、請求項２９に記載のコンピュータ読取可能な記憶媒体。
41. 前記第１のメンバーが障害を起こしたが前記第１のメンバーのノードはまだ機能していることを検出するための命令をさらに含み、前記サービスが第２のメンバーにより前記コンポーネントに提供されることを引起こすための命令は、前記第１のメンバーのノードにある前記１つ以上の他のリソースが機能している間に実行される、請求項３９に記載のコンピュータ読取可能な記憶媒体。
42. 前記サービスが第２のメンバーにより前記コンポーネントに提供されることを自動的に引起こすステップを実行するための命令は、前記第１のメンバーの回復を試みる間に前記ステップが実行されるための命令を含む、請求項４１に記載のコンピュータ読取可能な記憶媒体。
43. 前記複合リソースを確立するための命令は、データベースアプリケーションの複数のインスタンスが複数のノードにおいて実行されることを可能にするための命令を含む、請求項２９に記載のコンピュータ読取可能な記憶媒体。
44. 前記複数のノードのうち１つにおいて前記調整部を実行するための命令をさらに含む、請求項２９に記載のコンピュータ読取可能な記憶媒体。
45. 前記複数のノードの共有するフレームワークにおいて前記調整部を実行するための命令
    をさらに含む、請求項２９に記載のコンピュータ読取可能な記憶媒体。
46. 前記第１のノードにおいてアプリケーションを実行するステップを行なうための命令をさらに含み、前記アプリケーションは前記複合リソースに依存する、請求項２９に記載のコンピュータ読取可能な記憶媒体。
47. 前記サービスを前記複数のメンバーにおける第１のメンバーから前記アプリケーションに提供するための命令をさらに含み、前記第１のメンバーは前記第１のノードに常駐し、前記第１のメンバーが前記サービスを提供しなくなることに応答して、前記コンピュータ読取可能な記憶媒体はさらに、前記アプリケーションの実行を終了させるための命令を含む、請求項４６に記載のコンピュータ読取可能な記憶媒体。
48. 前記サービスを前記複数のメンバーのうちの第１のメンバーから前記アプリケーションに提供するための命令をさらに含み、前記第１のメンバーは前記第１のノードに常駐し、前記第１のメンバーが前記サービスを提供しなくなることに応答して、前記コンピュータ読取可能な記憶媒体はさらに、前記複数のメンバーのうちの、第２のノードに常駐する第２のメンバーから、前記第１のノードにおいて実行される前記アプリケーションに前記サービスを提供するための命令を含む、請求項４７に記載のコンピュータ読取可能な記憶媒体。
49. 前記コンピュータ読取可能な記憶媒体はさらに、
    前記複合リソースが機能している間に前記複合リソースの一部としてメンバーを開始するステップと、
    前記第１のメンバーが前記複合リソースのメンバーとして開始されることに応答して、前記複合リソースが機能していることを前記メンバーに保証させるステップとを実行するための命令を含む、請求項２９に記載のコンピュータ読取可能な記憶媒体。
50. 複数のコンポーネントを管理するための１つ以上の命令シーケンスを担うコンピュータ読取可能な記憶媒体であって、１つ以上のプロセッサによる前記１つ以上の命令シーケンスの実行は、前記１つ以上のプロセッサに、
    第１の複数のメンバーを含む第１の複合リソースを確立するステップを実行させ、前記第１の複数のメンバーは複数のノードに常駐し、前記第１の複数のメンバーの各々は第１のサービスを同等に提供することができ、前記１つ以上のプロセッサにさらに、
    第２の複数のメンバーを含む第２の複合リソースを確立するステップを実行させ、前記第２の複数のメンバーは前記複数のノードに常駐し、前記第２の複数のメンバーの各々は第２のサービスを同等に提供することができ、前記１つ以上のプロセッサにさらに、
    前記第１の複数のメンバーのうち第１のメンバーが、前記第１のサービスを要求する第１のコンポーネントに前記第１のサービスを提供するよう手配するステップを実行させ、前記第１のメンバーは前記複数のノードのうちの第１のノードに常駐し、前記１つ以上のプロセッサにさらに、
    前記第２の複数のメンバーのうちの第２のメンバーが、前記第２のサービスを要求する第２のコンポーネントに前記第２のサービスを提供するよう手配するステップを実行させ、前記第２のメンバーは前記第１のノードに常駐し、前記１つ以上のプロセッサにさらに、
    前記第１のメンバーが活性でなくなったときに、前記第１の複数のメンバーのうちの第３のメンバーを用いて前記第１のサービスを自動的に提供するステップを実行させ、前記第３のメンバーは、前記第１のノードとは異なる第２のノードに常駐し、前記１つ以上のプロセッサにさらに、
    前記第１の複数のメンバーのうちの前記第１のメンバーが活性でなくなることから独立して前記第１のノードから前記第２のサービスを提供するステップを実行させる、コンピ
    ュータ読取可能な記憶媒体。
51. 前記第１の複数のメンバーのうちの前記第１のメンバーが活性でなくなることから独立して前記第２のサービスを提供するための命令は、前記第１のメンバーが活性でなくなった後に連続的に前記第２のサービスを提供するための命令を含む、請求項５０に記載のコンピュータ読取可能な記憶媒体。
52. さらに、
    前記第１のメンバーが第１の組の１つ以上のリソースを用いて前記第１のサービスを提供することを可能にするステップを実行するための命令をさらに含み、前記第１の組の１つ以上のリソースは、前記第１のサービスを提供するために前記第１のメンバーにより必要とされ、前記第１の組のリソースは前記第１のノードに常駐し、前記コンピュータ読取可能な記憶媒体はさらに、
    前記第２のメンバーが第２の組の１つ以上のリソースを用いて前記第２のサービスを提供することを可能にするステップを実行するための命令をさらに含み、前記第２の組のリソースは、前記第２のサービスを提供するために前記第２のメンバーにより必要とされ、前記第２の組のリソースは前記第１のノードに常駐し、かつ、前記第１の組のリソースと重なる少なくとも１つのリソースを有する、請求項５０に記載のコンピュータ読取可能な記憶媒体。
53. 前記第１のノードから前記第２のサービスを提供するための命令は、前記第１のメンバーが活性でなくなったことを検出した直後に前記第２のサービスを提供することにおいて、前記第２の組のリソースが前記第２のメンバーで利用されるように機能しているよう維持するための命令を含む、請求項５２に記載のコンピュータ読取可能な記憶媒体。
54. 前記第１の複数のメンバーのうちの第１のメンバーが前記第１のサービスを提供するよう手配するための命令は、第１の調整部を用い前記第１のサービスを調整することで前記第１のメンバーを割当てて前記第１のサービスを前記第１のコンポーネントに提供するための命令を含む、請求項５０に記載のコンピュータ読取可能な記憶媒体。
55. 前記第１の複数のメンバーのうちの第２のメンバーが前記第２のサービスを提供するよう手配するための命令は、第２の調整部を用い前記第２のサービスを調整することで前記第２のメンバーを割当てて前記第２のサービスを前記第２のコンポーネントに提供するための命令を含む、請求項５４に記載のコンピュータ読取可能な記憶媒体。
56. 前記第１の調整部および前記第２の調整部を介し、前記第１の複数のメンバーおよび前記第２の複数のメンバーについての状態情報を維持するための命令をさらに含む、請求項５５に記載のコンピュータ読取可能な記憶媒体。

Images