JP4637842B2 - クラスタ化されたコンピューティングシステムにおける高速なアプリケーション通知 - Google Patents

Description

発明の分野
この発明は、概して、クラスタ化されたコンピューティングシステムに関し、より特定的には、イベントを用いて、クラスタ化されたシステムにおける状態の変更を高速通知するための技術に関する。

発明の背景
クラスタ化されたコンピューティングシステム
クラスタ化されたコンピューティングシステムは、１組のクライアントアプリケーションに処理を与える相互接続された計算要素の集まりである。計算要素の各々はノードと称される。ノードは、他のコンピュータに相互接続されたコンピュータ、または、グリッド状に他のサーバブレードに相互接続されたサーバブレードであり得る。クラスタ化されたコンピューティングシステムにおけるノードのグループは、記憶装置への共用アクセスを有し（たとえば、１組のディスクドライブまたは不揮発性記憶装置へのディスクアクセスを共有し）、相互接続を介して接続されているが、この明細書においては作業クラスタと称される。

クラスタ化されたコンピューティングシステムは、クラスタ化されたサーバのホストとなるよう用いられる。サーバは、統合されたソフトウェア構成要素と、メモリ、ノード、および、プロセッサ上で統合されたソフトウェア構成要素を実行するためのノード上のプロセスなどの計算リソースの割当との組合せであり、このソフトウェアと計算リソースとの組合せはサーバのクライアントとして特定の種類の機能を提供するために設けられる。サーバの例としてデータベースサーバが挙げられる。データベース管理の機能の中でも特に、データベースサーバは、データベースへのアクセスを求めるクライアントによる要求を処理して、特定のデータベースへのアクセスを制御しかつ容易にする。

クラスタ化されたコンピューティングシステムにおける複数のノードからのリソースは、サーバのソフトウェアを実行させるために割当てられてもよい。サーバに対する特定のノードのリソースの各々の割当は、この明細書中では「サーバインスタンス」またはインスタンスと称される。データベースサーバはクラスタ化されてもよく、この場合、サーバインスタンスは総称してクラスタと呼ばれ得る。データベースサーバの各インスタンスは同じデータベースへのアクセスを容易にするが、ここでは、データの完全性がグローバルロックマネージャによって管理される。

サービスレベルに従ってアプリケーションを管理するためのサービスレベル
サービスはデータベース作業負荷管理についての特徴であり、サービスレベルに従って作業を管理するために、データベースにおいて実行される作業の領域を分割する。リソースは、サービスレベルおよび優先順位に応じてサービスに割当てられる。サービスは、要求に応じてリソース容量を効率的に届けるよう測定および管理される。ソースハイアベイラビリティサービスレベルは、クラスタの冗長な部分の信頼性を用いる。

サービスは、作業負荷を管理するための論理的抽象化である。サービスを用いて、データベースクラスタにおいて実行される作業を相互にばらばらのクラスに分割し得る。各サービスは、共通の属性、サービスレベルしきい値および優先順位を有する論理的なビジネス機能、たとえば作業負荷、を表し得る。サービスのグループ化は、呼出されるべきアプ
リケーション機能を含み得る作業の属性、アプリケーション機能についての実行の優先順位、管理されるべきジョブクラス、または、ジョブクラスのアプリケーション機能において用いられるデータ範囲に基づいてなされる。たとえば、電子ビジネススイート（an electronic-business suite）は、総勘定元帳、受取勘定、受注などの各々の責任についてのサービスを規定し得る。サービスは、競合するアプリケーションを管理するために単一のシステム画像を提供し、各々の作業負荷を単独で１つの単位として管理することを可能にする。サービスは、グリッド状の１つのクラスタまたは複数のクラスタにおける複数のサーバインスタンスにわたり得、単一のサーバインスタンスは複数のサービスをサポートし得る。

中間層およびクライアント／サーバアプリケーションは、たとえば、接続の一部としてサービスを特定することによってサービスを用いることができる。たとえば、アプリケーションサーバデータソースはサービスに経路指定されるよう設定され得る。加えて、サーバサイドの作業は、作業負荷定義の一環としてサービス名を設定する。たとえば、ジョブクラスが用いるサービスは、そのジョブクラスが作成されると規定され、実行中にジョブがジョブクラスに割当てられ、ジョブクラスがサービス内で実行される。

データベースセッション
クライアントがデータベースクラスタ上のデータベースサーバと対話するために、当該クライアントのためにセッションが確立される。データベースセッションなどのセッションは、データベースインスタンスなどのサーバへの、クライアントのために確立された特定の接続であり、これを通じて、クライアントが一連の要求（たとえば、データベースステートメントの実行の要求）を発行する。データベースインスタンス上で確立された各々のデータベースセッションについては、データベースセッションの現在の状態を反映するセッション状態データが維持される。このような情報は、たとえば、セッションが確立されているクライアントのアイデンティティ、クライアントが用いるサービス、データベースセッション内でソフトウェアを実行するプロセスによって生成される一時的な変数値を含む。アプリケーションは、接続プールから接続を「借り」、セッションが終了すると接続を当該プールに戻し得る。一般に、セッションはデータベースとともに作業を実行する媒体である。各セッションはそれ自体のデータベースプロセスを有し得るか、またはデータベースプロセスを共有し得る。後者は多重化と称される。

ハイアベイラビリティ
ある変化がクラスタ化されたコンピューティングシステム内で起こると、ハイアベイラビリティが低減し、クライアントアプリケーションが時間を浪費することとなる。このような変化は、概して、「ダウン」の変化、「アップ」の変化または「リスタートなし」の変化と分類され得る。ダウンの変化は、サービス、サーバインスタンスまたはノードマシン（概して「構成要素」）が終了するかまたは「ダウンする」と起こる。アップの変化は、サービス、サーバインスタンスまたはノードが初期化するかまたは「アップする」と起こる。「リスタートなし」の変化は、サービス、インスタンスまたはノードがもはや始動し得ない場合に起こる。いくつかの変化は、既存のセッションと、現在用いられていないが既に作成され、サービス、インスタンスまたはノードに関連付けられる接続とに影響を及ぼす可能性がある。

アプリケーションは、クラスタ化されたシステムの状態が変化すると、セッションを介してクラスタ化されたシステムと対話する際にかなりの量の時間およびリソースを浪費する。特に、クラスタ化されたデータベースのクライアントアプリケーションは、クラスタ化されたシステムの状態が変化すると時間およびリソースを浪費する。たとえば、セッションが用いているノードまたはサーバインスタンスが「ダウンする」と、アプリケーションは長期間にわたって中断されない可能性がある。具体的には、ノードまたはネットワー
クがセッションソケットを閉じることができなかった場合、アプリケーションはローカルなＴＣＰ／ＩＰスタックからのＴＣＰ／ＩＰタイムアウトエラーを待つ。別の例については、作業は、新しいサービス、ノードまたはインスタンスが利用可能になる、すなわち「アップする」と、サービスをサポートするすべてのインスタンスにわたって分散されないかもしれない。すなわち、サービス、ノードまたはインスタンスが利用可能になると、当該サービス、ノードまたはインスタンスと接続しないことで時間が浪費される。時間およびリソースが浪費されるもう１つの例として、クライアントが、再度アップしないかまたはリスタートしなかった構成要素との通信を再試行し続ける例が挙げられる。

概して、従来のシステムは、ノードがダウンすると極めて不良に動作する。アプリケーションセッションは最大２時間まで待ってから中断され得る。概して、従来のシステムは、障害のあるシステムエンティティがリストアされるとき、リストアされたエンティティ（すなわち、アップしたエンティティ）に作業を割当てる際に不良に機能する。こうして、従来のシステムは、このようなシステムが提供し得る可用性や、場合によってはサービス時間を低減させる。さらに従来のシステムでは、障害のある構成要素を修復またはリストアした後、従来のコールド・フェイルオーバーシステムが、典型的には、クラスタにおける構成要素のコンプリメントにわたって負荷バランシングを提供するのではなく、作業負荷全体のフォールバックをリストアされたエンティティに提供する。

実行時間中、セッションは、典型的には、それぞれのデータベースサーバインスタンスに関する４つの状態のうちの１つの状態にある。セッションは、（１）インスタンスに能動的に接続し、すなわち、インスタンスでセッションを確立し、（２）コマンドをインスタンスに能動的に発行し、たとえばＳＱＬステートメントを発行し、（３）発行されたＳＱＬステートメントに対する応答を待って受動的にブロックされ、（４）前の要求、たとえばＳＱＬステートメントを処理し得る。状態（１）は他の状態とは異なる。というのも、クライアントがＴＣＰ／ＩＰスタックに入っているからである。他の状態では、クライアントはＴＣＰ／ＩＰスタックの内部にある。

サーバのクライアントは、クラスタ化されたシステムの状態が変化すると、セッションを介してクラスタ化されたシステムと対話する際に時間およびリソースを著しく浪費する。特に、クラスタ化されたデータベースのクライアントアプリケーションは、データベースクラスタの状態が変化すると時間とリソースとを浪費する。たとえば、作業は、新しいサービス、ノードまたはインスタンスが利用可能になる、すなわち「アップする」と、サービスをサポートするすべてのインスタンスにわたって分散されなくてもよい。つまり、ノードまたはインスタンス上のサービスが利用可能になると、当該ノードまたはインスタンスと接続しないことで時間が浪費される。時間およびリソースが浪費されるもう１つの例として、クライアントが、再度アップしない（すなわち、デッドノードと通信している）かまたはまだリスタートしていない構成要素との通信を再試行し続ける例が挙げられる。たとえば、セッションが用いているノードまたはサーバインスタンスが「ダウンする」と、アプリケーションは長期間にわたって（たとえば、２時間が典型的である）中断されないかもしれない。具体的には、ノードまたはネットワークがセッションソケットを閉じることができなかった場合、アプリケーションは、ローカルなＴＣＰ／ＩＰスタックからのＴＣＰ／ＩＰタイムアウトエラーを待つ。

シナリオ（１）は、常に利用可能である仮想ＩＰアドレスを用いることによって多少とも解決され得る。これは、クライアントがＴＣＰ／ＩＰスタックの外側にあるからである。こうして、ノードがダウンすると、ＩＰアドレスが異なるノードにフェイルオーバーする。しかしながら、ノードが再度アップすると、システム状態の変化に対処する類似の解決策は存在しない。概して、セッションが状態（２）、（３）または（４）にある場合、非常の多くの問題が生じる。セッションが状態（３）にあるときアプリケーションおよび
／またはセッションが問題の解決を待たなければならない場合、非常に多くの時間が浪費される。さらに悪いことに、アプリケーションが状態（３）にあると、ほぼ９０％の時間が浪費される。加えて、接続プールクライアントを用いると、デッド接続をアプリケーションに与えることによって時間が浪費される。

概して、従来のシステムは、障害があるかまたは終了したシステムエンティティがリストアされた場合、リストアされたエンティティに作業を割当てる際に不良に機能する。こうして、従来のシステムは、このようなシステムが提供し得る可用性や、場合によってはサービス時間を低減させる。さらに従来のシステムを用いると、障害のある構成要素を修復またはリストアした後、従来のコールド・フェイルオーバーシステムは、典型的には、クラスタにおける構成要素のコンプリメントにわたって負荷バランシングを提供するのではなく、リストアされたエンティティに作業負荷全体のフォールバックを提供する。さらに、コールド・フェイルオーバー、スタンバイなどのために構成されるノードが１つしかない場合、システムには冗長性がなくなる。このようなシステムは、接続されたすべてのアプリケーションがすべてのリソースを利用することのできる「アクティブ／パッシブ」なシステムと称される。

上述に基づくと、クラスタ化されたコンピューティングシステムにおけるシステム状態の変化への対処には改善の余地がある。

この発明の実施例は、添付の図面の図において限定のためではなく例示のために示されており、同様の参照番号は同様の要素を指す。

発明の実施例の詳細な説明
実施例の機能概要
クラスタ化されたコンピューティングシステムへの変更を高速通知するための技術が説明される。この場合、アプリケーションを高速で回復させ、クラスタ化されたシステムとのセッションのバランスを高速で取り直すことを可能にするために、システム状態の変化についていくつかのイベントが発行される。このようなクラスタ化されたコンピューティングシステムの一例には、複数のノードマシン上で実行され、複数のクライアントアプリケーションからの要求に応答してデータベースからの共有データにアクセスしかつこれを操作するよう構成された、データベースサーバの複数のインスタンスを含むデータベースクラスタが挙げられる。

サービスに関連付けられるリソースが状態の変化を被ると、通知イベントが、さまざまな加入者に使用されるよう直ちにイベントに発行される。たとえば、通知イベントは、サービスがインスタンス上で利用可能になったり、サービスがインスタンス上で利用不可能になったりするたびに発行される。通知イベントは、サービスと、当該サービスをサポートするたとえば特定のインスタンス、インスタンス、ノードまたはデータベースクラスタなどのリソースとについての状態変更に対して発生する。１つ以上のインスタンスによって提供されるサービスが開始すると、サービスに従属するアプリケーションを開始するのに用いられ得る通知イベント（ＵＰ）が発行される。１つ以上のインスタンスによって提供されるサービスが終了し、同様にインスタンスまたはノードが終了すると、通知イベント（ＤＯＷＮ）が発行されて、従属アプリケーションを停止させる。サービスがその障害しきい値を超えたために管理クラスタウェアがもはやサービスを管理できない場合、通知イベント（ＮＯＴ＿ＲＥＳＴＡＲＴＩＮＧ）が発行されて、サービスを再試行するアプリケーションを中断する。一実施例においては、ＮＯＴ＿ＲＥＳＴＡＲＴＩＮＧイベントは
、災害サービスへの切換を開始する。

クラスタに接続されると、固有の署名（すなわちロケータ）が、関連するセッションのために生成され、接続の一部としてハンドルに記録される。一実施例においては、署名はサービス識別子、ノード識別子、データベース固有名およびインスタンス識別子を含み、その各々はセッションに関連付けられる。データベースクラスタの文脈においては、通知イベントは、状態の変化によって影響を受ける特定のセッション、すなわち、影響を受けたセッションの署名、を加入者が識別することを可能にする情報を含む。いくつかのタイプのイベントについては、影響を受けたセッションを識別するのに用いられる情報は、状態変更に関連付けられるサービスおよびデータベースの識別を含む。他のタイプのイベントについては、影響を受けたセッションを識別するのに用いられる情報は、さらに、状態変更に関連付けられるインスタンスおよびノードの識別を含む。影響を受けたセッションは、イベントペイロードに含まれる署名に適合する署名を含むセッションである。

結果として、アプリケーションおよびセッションは、関連するリソースが状態を変えると直ちに通知される。これらの技術を用いると、通知イベントを用いることにより、前にこの明細書中に記載された従来のシステムに関する問題を克服することができる。

動作環境
図１は、実施例が実現され得る動作環境を示すブロック図である。ａ〜ｎの要素識別子、たとえばクライアント１０２ａ〜１０２ｎ、サービス１０６ａ〜１０６ｎ、インスタンス１０８ａ〜１０８ｎおよびノード１１０ａ〜１１０ｎの使用は、同じ数のこのような構成要素が必要とされることを意味するわけではない。すなわち、ｎはそれぞれの構成要素に対して必ずしも等しいわけではない。むしろ、このような識別子は、複数の同様の構成要素に関連して一般的な意味で用いられる。

クラスタ化された計算環境
１つ以上のクライアント１０２ａ〜１０２ｎは、共用データベース１１２に接続されるサーバクラスタ１０４（「サーバ」）に通信可能に連結される。サーバ１０４は、インスタンスが実行されるサーバインスタンス１０８ａ〜１０８ｎおよびノード１１０ａ〜１１０ｎのクラスタと総称される。他の構成要素はまた、通知サービスデーモン１１８およびイベントハンドラ１２０などのサーバ１０４の一部と見なされてもよい。しかしながら、上述の構成要素が構成される実際のアーキテクチャは、実現例ごとに異なる可能性がある。クライアント１０２ａ〜１０２ｎは、たとえばネットワークを介してクライアントとサーバ１０４との間のアプリケーションサーバまたは他の何らかのミドルウェア構成要素に相互接続されたコンピュータによって実現されるアプリケーションであり得る。加えて、１つのサーバインスタンスは別のサーバインスタンスのクライアントであり得る。クライアント１０２ａ〜１０２ｎのいずれかまたはすべてが、この明細書中に記載されるように、発行されたイベントの加入者として動作し得る。

データベースクラスタの文脈においては、データベース１１２はデータおよびメタデータを含み、これらデータおよびメタデータは、ノード１１０ａ〜１１０ｎに通信可能に連結される１組のハードディスクなどの永続メモリ機構に記憶され、当該ノード１１０ａ〜１１０ｎの各々は１つ以上のインスタンス１０８ａ〜１０８ｎのホストになることができ、当該インスタンス１０８ａ〜１０８ｎの各々は１つ以上のサービスのうち少なくとも一部のホストとなる。このようなデータおよびメタデータは、たとえば、リレーショナルデータベース構造、多次元データベース構造、またはリレーショナルデータベース構造と多次元データベース構造との組合せに従って、論理的にデータベース１１２に記憶され得る。ノード１１０ａ〜１００ｎは、従来のコンピュータシステム、たとえば図３に示されるコンピュータシステム３００として実現され得る。

記載されるように、データベースサーバは、統合されたソフトウェア構成要素と、プロセッサ上で統合されたソフトウェア構成要素を実行するための（メモリおよびプロセスなどの）計算リソースの割当との組合せであり、このソフトウェアと計算リソースとの組合せを用いて、データベース１１２などの特定のデータベースを管理する。データベース管理の機能の中でも特に、データベースサーバは、典型的には、データベース１１２へのアクセスを求めるクライアントからの要求を処理することによってデータベース１１２へのアクセスを容易にする。インスタンス１０８ａ〜１０８ｎは、それぞれのノード１１０ａ〜１１０ｎとともにサービス１０６ａ〜１０６ｎのホストとなる。

サービス１０６
この明細書中に先に述べられたように、サービスは、概して、作業負荷を管理するための論理的抽象化である。この発明の実施例の文脈により特定的には、サービス、たとえばサービス１０６ａ〜１０６ｎは名前とドメインとを有し、関連する目標、サービスレベル、優先順位およびハイアベイラビリティの属性を有し得る。サービスの一環として実行される作業は、たとえば、ＣＰＵ処理時間、揮発性メモリへのデータの記憶およびそれへのアクセス、永続ストレージ（すなわちディスク空間）からの読出および／それへの書込、ならびにネットワークまたはバスの帯域幅の使用を含め、コンピュータリソースのいかなる使用または費用をも含む。

一実施例においては、サービスは、セッション中にデータベースサーバによって実行される作業であり、典型的には、特定のデータベースへのアクセスを必要とするクエリを処理および／または計算するよう実行される作業を含む。この明細書中で用いられるクエリという語は、ＳＱＬなどのデータベース言語に準拠するステートメントを指し、データを追加するか削除するかまたは変更し、テーブル、オブジェクトビューおよび実行可能なルーチンなどのデータベースオブジェクトを作成しかつ変更する動作を特定するステートメントを含む。クラスタ化されたコンピューティングシステムを含むシステムは多くのサービスをサポートし得る。

サービスは、１つ以上のデータベースサーバインスタンスによって提供され得る。こうして、複数のサーバインスタンスが一緒に作用して、サービスをクライアントに提供し得る。図１においては、インスタンス１０８ａによって提供されるサービス１０６ａ（たとえば、ＦＩＮ）が破線の括弧で示され、インスタンス１０８ａおよび１０８ｂによって提供されるサービス１０６ｂ（たとえば、ＰＡＹ）が示され、インスタンス１０８ａ〜１０８ｎによって提供されるサービス１０６ｎが示される。

概して、この明細書中で説明される技術はサービス中心のものであり、サーバ１０４内に発生するイベントは、当該イベントによって影響を被るサービスに基づいて識別および／または特徴付けされ得る。通知イベントのペイロードが以下に説明される。

通知システム
概して、デーモンは、バックグラウンドで実行し、かつ予め規定された時間に、またはあるイベントに応答して特定の動作を実行するプロセスである。概して、イベントはアクションまたはオカレンスであり、プロセスによってそのポスティングが検出される。通知サービスデーモン１１８は、インスタンス１０６ａ〜１０６ｎのクラスタを管理するよう構成されるクラスタウェアなどのサーバ１０４からシステム状態変更情報を受取るプロセスである。このような状態変更情報は、たとえば、サービス、インスタンスおよびノードのアップまたはダウンイベント情報を含み得る。サーバ１０４は、この明細書中に記載されるように、クラスタ内で状態が変化するとイベントをポスティングする。

通知サービスデーモン１１８はイベントハンドラ１２０に対する発行元と加入者との関係を有し、これにより、サーバ１０４からデーモン１１８が受信したシステム状態変更情報が通知イベントとしてイベントハンドラ１２０に伝送される。概して、イベントハンドラは、イベントに応答して実行されるプログラムステートメントを含む機能または方法である。デーモン１１８からのイベント情報の受信に応答して、イベントハンドラ１２０は、この明細書中に記載されるイベントタイプおよび属性を少なくとも伝える。図１において、単一のイベントハンドラ１２０がすべての加入者に役立つものとして図示される。しかしながら、異なるイベントハンドラが異なる加入者に関連付けられてもよい。このようなイベントのさまざまな加入者によって通知イベントの処理が実現される態様は重要ではなく、実現例ごとに異なる可能性がある。

サーバ１０４から通知サービスデーモン１１８ならびに通知サービスデーモン１１８からイベントハンドラ１２０へのイベント情報の伝送は「帯域外」である。この文脈においては、帯域外とは、セッション通信経路がイベントのためにブロックされる可能性があるのでこのような伝送が当該経路を通じて行なわれないことを意味する。たとえば、帯域外通知は、クラスタを管理するクラスタウェアの一部ではないゲートウェイプロセスを通じて非同期的に発行され得る。非限定的な例として、通知サービスデーモン１１８はオラクル（Oracle）通知システム（ＯＮＳ）ＡＰＩを用いてもよく、これはメッセージ機構であり、Java （登録商標）2 Platform, Enterprise Edition（Ｊ２ＥＥ）に基づいたアプリケーション構成要素がメッセージを作成、送信、受信および読出すことを可能にする。

「加入者」は、それぞれのさまざまな目的で通知イベントをサブスクライブしかつこれに応答し得るさまざまなエンティティを表わす。加入者の非限定的な例には、クライアント１０２ａ〜１０２ｎ、接続プールマネージャ、中間層アプリケーション、バッチジョブ、コールアウト、ページングおよびアラート機構、ハイアベイラビリティログなどが含まれる。

通知イベント
所与のサービスの状態が変化すると、すなわち、所与のサービスの作業の実行に関与するクラスタリソースの状態が変化すると、新しい状態が、通知イベントを介して、関係する加入者に通知される。アプリケーションはこの通知を用いて、たとえば、前の結果の処理を停止させ、接続プールセッションをクリーンアップし、障害の発生後に接続プールのバランスを取るために、障害のある構成要素が修復される際に、障害を極めて高速に検出できるようにする。たとえば、サービスがインスタンスにおいて開始すると、イベントを用いて、当該インスタンス上で実行される作業を直ちにトリガし得る。サービスがインスタンスにおいて終了すると、当該イベントを用いることにより、そのインスタンスにおけるサービスを用いてアプリケーションを中断し得る。

さまざまなクライアント加入者による通知イベントの使用により、たとえば、障害の発生後および中断の前にＴＣＰタイムアウトまたはクライアントにおける最終結果の無駄な処理を待つクライアントがなくされる。このような通知がないと、ノードが障害を起こしてソケットが閉じられない場合、Ｉ／Ｏ待機（読出または書込）の際にブロックされるセッションがいずれも、タイムアウトの間に数分から数時間にかけて待つこととなり、最終結果を処理するセッションは、次のデータが要求されるまで中断を受信しないだろう。

通知イベントペイロード
一実施例においては、通知イベントは、イベントタイプおよびイベント特性の識別を含む。表１は、この発明の実施例に従った通知イベントに関連するパラメータを示す。

「サービス」イベントタイプは、サービス全体がダウンする、すなわち、サービスが当該サービスをサポートするすべてのインスタンス上でダウンするとトリガされる。「サービス＿メンバ（service_member）」イベントタイプは、サービスが特定のインスタンス上でダウンするとトリガされる。「データベース」イベントタイプは、データベース全体がダウンする、すなわちデータベースを管理するすべてのインスタンスがダウンするとトリガされる。「ノード」イベントタイプは、ノードマシンがダウンし、その結果、そのノード上で実行するインスタンスがいかなるサービスをもサポートできない場合にトリガされる。「ノード名」は、管理クラスタウェアによって分かっているノードの名前である。たとえば、サービスメンバが支持インスタンスの障害時に別のインスタンスにフェイルオーバーし、障害のある構成要素が修復されるような場合、ＤＯＷＮイベントの後にしばしばＵＰイベントが続く。

各々のイベントタイプに対するイベントペイロードがイベント特性の各々を含む必要はない。表２は、この発明の実施例に従った、各イベントタイプについてのイベントペイロードに含まれる特性を示す。

実施例に従うと、イベントは、この明細書中に記載される（イベントにプログラマチック・インターフェイスを提供する）通知システムと、サーバサイドのコールアウトと、コール・インターフェイス・コールバックとに発行され得る。

システム状態変更シナリオのいくつかの例が以下に続く。

インスタンスが障害を起こすと、いくつかの通知イベントが発行される。すなわち、（１）イベントタイプ＝インスタンスであり、インスタンスがダウンしていることを通知するもの、（２）イベントタイプ＝サービス＿メンバであり、サービスがその特定のインスタンスにおいてダウンしていることを通知する、終了したインスタンス上で実行していた各サービスのためのもの、である。加えて、サービスが別の支持インスタンス（すなわち、サービスをサポートするのにバックアップインスタンスとして利用可能なインスタンス）上でリスタートする場合、イベントタイプ＝サービス＿メンバの状態でイベントが発行されて、サービスが特定のインスタンス上で新たに利用可能であることが通知される。終了したインスタンスが修復され、再度アップする場合、通知イベントが、利用可能な支持インスタンスのなかった（すなわち、サービスをサポートするバックアップインスタンスのない）各サービスのために発行され得る。すなわち、（１）イベントタイプ＝インスタンスであり、以前に終了したインスタンスがアップしていることを通知するもの、および、（２）イベントタイプ＝サービス＿メンバであり、サービスが以前に終了したインスタンス上でアップしていることを通知するもの、である。

前のシナリオについての通知イベントの各々が「インスタンス」または「サービス＿メンバ」タイプであるので、表２は、特性がすべてイベントペイロードに含まれていることを示す。データベースがus.acme.comなどのデータベースドメインで構成される場合、ドメイン名条件（qualification）が、イベント特性におけるデータベースおよびサービスの名前として現われると予想される。たとえば、データベースが、databaseX.us.acme.comであり、サービスが、serviceY.us.acme.comである。加えて、ＵＰイベントに応じた濃度（cardinality）を用いることにより、作業が再分散されて、バランスの取れた態様で利用可能なリソースを用いることができる。

サービスをサポートするインスタンスがすべてダウンすると、すなわちサービス全体がダウンすると、いくつかの通知イベントが発行される。すなわち、（１）サービスをサポートする各インスタンスについて、イベントタイプ＝サービス＿メンバである状態でイベントがトリガされて、サービスがそれぞれのインスタンス上でダウンしていることが通知され、（２）イベントタイプ＝サービスである状態でイベントがトリガされて、サービス全体がダウンしていることが通知され、（３）サービスをサポートする各インスタンスについて、イベントタイプ＝インスタンスである状態でイベントがトリガされて、そのそれぞれのインスタンスがダウンしていることが通知される。同様に、終了したインスタンスがリスタートすると、同様のイベントがＵＰ状態でトリガされて、サービスがそれぞれのインスタンス上でアップしていることと、サービス全体がアップしていることと、インスタンスがアップしていることとが通知される。

「サービス」タイプのイベントについて、表２は、インスタンス名、ノード名および濃度特性が、このタイプのイベントに対するイベントペイロードから除外され得ることを示す。これは、定義によれば、「サービス」タイプのイベントが、サービス全体がアップまたはダウンしていること、すなわち、サービスが当該サービスをサポートするすべてのインスタンスおよび関連するノード上でアップまたはダウンしていることを意味するからである。この場合、所与のサービスに対する支持インスタンスおよびノードはマッピングされ、どこにおいても利用可能となる。したがって、インスタンス、ノードおよび濃度の特性は、このようなイベントに応答するのに不必要である。同様に、「データベース」タイ
プのイベントについて、表２は、インスタンス名およびノード名の特性が、このタイプのイベントに対するイベントペイロードから除外され得ることを示す。これは、定義によれば、データベースタイプのイベントが、データベース全体がアップまたはダウンしていること、すなわち、データベースにおけるすべてのインスタンスおよびノードがアップまたはダウンしていることを意味するからである。この場合、データベースクラスタの構成はどこにおいても利用可能である。

ノードが障害を起こすと、イベントタイプ＝ノードであるイベントがトリガされて、ノードがダウンしていることが通知される。一実施例においては、他のイベントはトリガされない、すなわち、サービス、サービス＿メンバまたはインスタンスタイプのイベントは、インスタンスおよびサービスへのノードの利用可能なマッピングのために不要となる。ノードイベントはクラスタの具体化を含んでおり、これにより、重複イベントの重複処理をなくすことが容易になる。表２はサービス名、データベース名、インスタンス名および濃度特性が、このタイプのイベントに対するイベントペイロードから除外され得ることを示す。何らかの理由で、特定のノードはリスタートできない場合、イベントタイプ＝ノードおよび状態ＮＯＴ＿ＲＥＳＴＡＲＴＩＮＧであるイベントがトリガされて、介入が必要であることを示す。

イベント処理
概して、所与の加入者は、セッション接続が確立されると記録されるセッション位置情報とイベントペイロードにおける情報を適合させることにより、システム状態変更によって影響を被り、所与の加入者に関連付けられる１つ以上のセッションを識別することによって通知イベントに応答する。セッション位置情報（すなわち、セッション署名）は、セッションの位置、たとえばサービス、データベース、インスタンス、ノードおよびデータベースがセッションに関連付けられているもの、を識別する。同様の「イベント」署名がイベントペイロードの一部として与えられるが、これは、セッションの確立時に記録された１つ以上のセッションの署名と正確に適合されて、システム状態変更によって影響を被るセッションを決定し得る。

セッション位置情報が記録される態様は実現例ごとに異なっていてもよい。非限定的な例については、セッション位置情報がさまざまな加入者にとってアクセス可能な「掲示板」機構にポスティングされ得るか、または、当該セッション位置情報が索引付きテーブルまたはハッシュテーブルに記憶され得る。さまざまな加入者が通知イベントに応答して実行し得る詳細なアクションはこの説明の範囲の外にある。

たとえば、接続プールマネージャは、クラスタにおけるリソースへの状態変更に応答して発行される通知イベントの１つの起こり得る加入者またはクライアントとして記載される。接続プールマネージャは、サーバ１０４（図１）との、セッションのための接続のために接続プールおよび要求を管理するソフトウェア構成要素である。接続プールマネージャが、たとえばサーバ１０４のインスタンス１０８ａ〜１０８ｎにわたる接続プールからの接続を再分散させるためにさまざまなタイプの通知イベントに応答し得る態様が、「クラスタ化されたコンピューティングシステムにおけるイベントに応答した接続の高速な再編成（“Fast Reorganization of Connections In Response To An Event In a Clustered Computing System”）」と題された米国特許出願第１０／ＸＸＸ，ＸＸＸ号（番号第５０２７７−２３３５）に詳細に記載される。

たとえば、接続プールマネージャは、各々のサービスのために、物理的な位置、すなわちインスタンス、ノード、データベースへの接続のマッピングを維持する。こうして、クライアント−サーバセッションおよびバッチセッションを含む各セッションの位置が固有に識別される。接続が確立されると常に、接続プールマネージャがその接続についての位
置を記録する。これらのデータは、システム状態変更通知イベントが受信されるたびに、接続プールを高速で再分散させるのに用いられる。イベントに応じた接続の高速な再分散は、セッション要求が受信されるときに使用する準備のできている接続をプールが備えることを確実にすることによって、クラスタにおける作業の実行時間の分散に役立つ。

他の非限定的な例については、（１）サーバサイドのコールアウトに応答して、ジョブおよびバッチプロセスが、何らかの理由でサービスが停止すると止められ得、サービスが始まると直ちに開始／再開され得、（２）コールアウトが、ページングおよび電子メール警報機構のために用いられ得、（３）コールアウトが、ハイアベイラビリティ・アップタイム記録のために用いられ得る。この場合、アップタイムおよびダウンタイムは、「計画された」（たとえば、ユーザによって開始される）または「計画されない」（たとえば障害によって開始される）などのシステム変更についての理由とともに、分散され得る。

実現機構
この明細書中に記載されるように、クラスタ化されたコンピューティングシステムにおける高速なアプリケーション通知のための技術はさまざまな方法で実現可能であり、この発明はいかなる特定の実現例にも限定されない。その方策は、システムもしくは装置に組込まれ得るかまたはスタンドアロン機構として実現され得る。さらに、当該方策は、コンピュータソフトウェア、ハードウェアまたはその組合せで実現され得る。

図２は、この発明の実施例が実現され得るハイアベイラビリティ（ＨＡ）システムを概略的に示すブロック図である。図示されたＨＡシステム２００の「層」は、クラスタサービスノードメンバシップモジュール、内部イベントシステム、ならびに、外部イベントシステムに通信可能に連結されるサービス、データベースおよびインスタンスを含むＨＡフレームワークを含む。

ＨＡシステム２００は、リソース、すなわちサービス、データベースおよびインスタンスのためのアクションの開始および終了を実行する。開始アクションはＵＰイベントをポスティングし、停止アクションはＤＯＷＮイベントをポスティングする。ＨＡシステム２００は、リソースがもはや実行できない場合、ＮＯＴ＿ＲＥＳＴＡＲＴＩＮＧイベントをポスティングする。

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

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

この発明は、この明細書に記載された技術を実現するためにコンピュータシステム３００を用いることに関する。この発明の一実施例によると、これらの技術は、メインメモリ３０６に含まれる１つ以上の命令からなる１つ以上のシーケンスをプロセッサ３０４が実行することに応答して、コンピュータシステム３００により実行される。このような命令は、別のコンピュータ読取可能な媒体、たとえば記憶装置３１０等からメインメモリ３０６内に読出すことができる。メインメモリ３０６に含まれる命令のシーケンスを実行することにより、プロセッサ３０４はこの明細書に記載された処理ステップを実行する。代替的な実施例では、ソフトウェア命令の代わりに、またはソフトウェア命令と組合せてハードワイヤード回路を用いて、この発明を実現し得る。したがって、この発明の実施例は、ハードウェア回路およびソフトウェアの任意の特定の組合せに限定されない。

この明細書で用いられる「コンピュータ読取可能な媒体」という用語は、プロセッサ３０４に対する実行のために命令を提供することにかかわる任意の媒体を指す。このような媒体は、不揮発性媒体、揮発性媒体および伝送媒体を含む多くの形態をとり得るが、これらに限定されない。不揮発性媒体には、たとえば記憶装置３１０等の光学または磁気ディスクが含まれる。揮発性媒体には、メインメモリ３０６等の動的メモリが含まれる。伝送媒体には、同軸ケーブル、銅線および光ファイバが含まれ、バス３０２を有するワイヤが含まれる。伝送媒体はまた、電波および赤外線データ通信中に生成されるような音波または光波の形をとり得る。

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

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

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

ネットワークリンク３２０は、典型的には、１つ以上のネットワーク経由で他のデータ装置に対するデータ通信をもたらす。たとえば、ネットワークリンク３２０は、ローカルネットワーク３２２経由でホストコンピュータ３２４、またはインターネットサービスプロバイダ（ＩＳＰ）３２６が作動させるデータ装置に接続をもたらし得る。さらに、ＩＳＰ３２６は、現在一般に「インターネット」３２８と称されるワールドワイドパケットデータ通信網を介してデータ通信サービスを提供する。ローカルネットワーク３２２およびインターネット３２８はともに、デジタルデータストリームを搬送する電気的、電磁的または光学的信号を用いる。さまざまなネットワークを経由する信号と、コンピュータシステム３００との間でデジタルデータをやり取りする通信インターフェイス３１８を経由する、ネットワークリンク３２０上の信号とは、情報を運ぶ搬送波の例示的形態である。

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

受信されたコードは、受信されたときにプロセッサ３０４によって実行され得、および／または後の実行のために記憶装置３１０もしくは他の不揮発性記憶装置に格納され得る。このようにして、コンピュータシステム３００は搬送波の形でアプリケーションコードを得ることができる。

展開例および代替例
この発明の代替的な実施例は、上述の説明全体にわたって、実施例の文脈の最適な理解を容易にする個所に記載される。さらに、この発明は、その特定の実施例に関連して記載されてきた。しかしながら、この発明のより広範な精神および範囲から逸脱することなくさまざまな変形および変更がなされ得ることが明らかとなるだろう。たとえば、この発明の実施例は、サーバの文脈においてこの明細書中に記載されるが、記載された技術は、システム接続が割振られるかまたは割当てられる、計算クラスタまたは計算グリッドとして構成されるシステムなどのいかなるクラスタ化されたコンピューティングシステムにも適用可能である。したがって、明細書および図面は、これに応じて、限定的な意味ではなく例示の意味であるとみなされるべきである。

加えて、この説明においては、あるプロセスステップは特定の順序で述べられており、アルファベットおよび英数字の表示を用いることにより、あるステップが識別され得る。この説明において具体的に述べられない限り、この発明の実施例は、このようなステップを実行する特定の順序に必ずしも限定されるわけではない。特に、この表示は、単にステップを便宜的に識別するのに用いられるだけであり、このようなステップを実行する特定の順序を特定するかまたは必要とすることを意図するものではない。

実施例が実現され得る動作環境を示すブロック図である。 この発明の実施例が実現され得るハイアベイラビリティ（ＨＡ）システムを概略的に示すブロック図である。 この発明の実施例が実現され得るコンピュータシステムを示すブロック図である。

Claims (28)

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. 状態変更についての前記情報において識別される前記リソースは、（ａ）サービス、（ｂ）前記インスタンスの特定のインスタンス上で実行されているサービスメンバ、（ｃ）前記データベースクラスタ、（ｄ）前記インスタンスのうちの１つ、および（ｅ）前記ノードのうちの１つからなる群のうちの少なくとも１つに関連付けられる、請求項２６に記載のシステム。

Images