改良された高可用性コンポーネント実装のためのシステム及び方法
本発明は、少なくとも２つのノードを有するクラスタ内で使用するための、トランスポート接続上でのセッションを介する高可用性処理のためのコンピュータシステム及び方法に関する。このシステムは、プロトコルコンポーネント、少なくとも２つのノードを有してプロトコルコンポーネントを動作させるように構成されているクラスタ、及びトランスポート接続上でクラスタのノードとのプロトコルセッションを維持するように構成されたサーバを備える。クラスタは、少なくとも２つのインスタンスがアクティブであるように前記少なくとも２つのノードのそれぞれにおいてプロトコルコンポーネントの、１つのインスタンスを維持するように構成され、サーバはプロトコルセッションを各インスタンスと同時に維持するように構成される。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、プロトコルコンポーネント、少なくとも２つのノードを有してプロトコルコンポーネントを動作させるように構成されているクラスタ、及びＴＣＰ接続などトランスポート接続上でクラスタのノードとのプロトコルセッションを維持するように構成されたサーバを備えた高可用性処理のためのシステムに関する。また、本発明はトランスポート接続上のプロトコルセッションを介した高可用性処理のための方法に関する。
【背景技術】
【０００２】
より高い可用性と低ダウンタイムを必要とする応用例が増加するにつれて、フォールトトレラントな高可用性処理システムに大きな関心が寄せられている。１つの知られている解決策はプロセッサのクラスタグループを相互接続するネットワークを必要とする（ｉｍｐｌｙ）。クラスタはハードウェア冗長の原理に基づくものであり、通常は可用性の増大のために単一のシステムとして管理される複数のノードからなる。
【０００３】
高可用性クラスタに関する最も一般的なサイズは２つのノード、例えばマスタノードとバックアップノードである。現在、コンポーネント実装が高可用性であるとベンダが主張するときには、コンポーネントが、クラスタ化された環境内で動作すること、またコンポーネントの１つのインスタンスがサーバとプロトコルセッションを維持することを意味する。一般に、マスタコンポーネントは、マスタコンポーネントが順調に機能している限りオフラインで機能するがマスタコンポーネントが故障したとき使用可能になるバックアップコンポーネントによってバックアップされる。換言すれば、現行の「高可用性」アーキテクチャはコンポーネントのいくつかのインスタンス（マスタコンポーネント、及び１つ又は複数のバックアップコンポーネント）からなるが、マスタコンポーネントとサーバの間に単一のプロトコルセッションしかない。マスタコンポーネントが故障した場合、新しいプロトコルセッションをサーバとバックアップコンポーネントの間で開く必要がある。従って、サーバはサービスの使用可能でない期間を知覚することになる。実際には、コンポーネントに対する処理負担及びコンポーネントが故障する確率は低減されない。はっきり言えば、コンポーネントをバックアップコンポーネントによって支援してもコンポーネントに対する処理負担は減少しない。コンポーネントが使用できなくなる確率はバックアップコンポーネントが有っても無くてもちょうど同じである。さらに、バックアップコンポーネントに対する処理負担は通常、マスタコンポーネントに対する処理負担に近く、その結果、この解決策の総処理負担は単一のコンポーネントの処理負担のほぼ２倍になる。
【発明の概要】
【発明が解決しようとする課題】
【０００４】
本発明の目的は、コンポーネントに対する処理負担を低減し、使用可能なリソースに対する負荷を低減するように構成可能であり、従ってコンポーネントのインスタンスのクラッシュ及び／又は障害の確率を低減する、トランスポート接続に基づく高可用性コンポーネント実装を提供することである。
【課題を解決するための手段】
【０００５】
この目的を達成するために、本発明によるシステムは、クラスタが、少なくとも２つのインスタンスがアクティブであるように前記少なくとも２つのノードのそれぞれにおいてプロトコルコンポーネントの１つのインスタンスを維持するように構成される点、またサーバが、プロトコルセッションを各インスタンスと同時に維持するように構成される点を特徴とする。さらに、従来技術の問題は本発明の方法によって解決され、この方法は、基本的に、プロトコルコンポーネントを少なくとも２つのノードにわたって分散し、同じプロトコルコンポーネントの、１つのインスタンスが各ノード上で動作すること、及び１つ又は複数のトランスポート接続上でこのプロトコルコンポーネントと少なくとも２つのプロトコルセッションを開くことによって特徴付けられる。
【０００６】
本発明のシステム及び方法は、プロトコルコンポーネントに対する処理負担を低減することによって、真の負荷平衡機構からプロトコルに対する利益をもたらすことができるという利点を有する。というのは、プロトコルコンポーネントが少なくとも２つのノードにわたって分散され、それらの少なくとも２つのプロトコルセッションが依然としてアクティブであるためそれらのノードに対するトラフィックを連続的に適切に調整することができるからである。
【０００７】
「プロトコルセッション」という用語は広い意味で解釈される必要があり、ＴＣＰ（伝送制御プロトコル）接続を介したＸＭＰＰセッションなどトランスポート接続上の任意の持続性のある接続を指すが、例えばＴＣＰ又はＳＣＴＰ（ストリーム制御伝送プロトコル）接続を介したＤｉａｍｅｔｅｒプロトコル接続をも含むことに留意されたい。原則として、プロトコルセッションを使用する、またトランスポート接続上での使用に適した任意の他のプロトコルが本発明によって想定されている。
【０００８】
有利な実施形態が従属請求項に記載されている。
【０００９】
好ましくは、このシステムは、障害のあるインスタンスとのプロトコルセッション上で送られるトラフィックを異なるアクティブなプロトコルセッションに再度割り当てるように構成される。そのようにして恒久的な可用性が確保される。
【００１０】
好ましい実施形態によれば、サーバは、所定のアルゴリズムに従ってプロトコルパケットを複数のインスタンスのそれぞれに代わりに割り当てるためのモジュールを備える。このモジュールは通常、そのプロトコルコンポーネントとのアクティブなプロトコルセッションのリストにアクセスすることができ、サーバはプロトコルパケットを、これらのパケットを所定のアルゴリズムに従って送るモジュールに送達するように構成される。ラウンドロビン法、ハッシュ法、ランダム法、固定割当て法、セッション識別子に基づく方法、前記方法のうちの１つ以上の組合せなど、多数の様々なアルゴリズムが可能であることを当業者なら理解するであろう。これらの方法は、図４を参照してさらに明らかにされることになる。
【００１１】
本発明の方法の異なる態様によれば、サーバはプロトコルコンポーネントの各インスタンスに対する処理負荷を測定し、プロトコルパケットの割当てはその処理負荷測定に基づく。そのようにして、インスタンス間で非常に効率的な負荷平衡を実施することができる。
【００１２】
添付の図面を使用し、本発明の現在好ましい非限定的な例示的実施形態を示す。以下の詳細な説明を添付の図面と併せ読めば、本発明の上記の、及び他の利点、特徴、及び目的がより明らかになり、本発明についてより良く理解されよう。
【図面の簡単な説明】
【００１３】
【図１】本発明のシステム及び方法を実施することができる典型的なコンピュータネットワークの例を示す図である。
【図２Ａ】従来技術の高可用性実装を概略的に示す図である。
【図２Ｂ】従来技術の高可用性実装を概略的に示す図である。
【図３Ａ】本発明のシステム及び方法の一実施形態を概略的に示す図である。
【図３Ｂ】本発明のシステム及び方法の一実施形態を概略的に示す図である。
【図４】本発明のシステム及び方法において使用するように構成されたＸＭＰＰサーバを概略的に表した図である。
【発明を実施するための形態】
【００１４】
図１に、多数のクライアント１、多数のサーバ２、並びに第１のサーバ及び第２のサーバ５からなるサーバクラスタ３を有する典型的なコンピュータシステムを示す。サーバクラスタ３は通常、同じマシン上で動作することができる、又は異なるマシン上に位置することができる多数のサーバインスタンス又はプロセスからなることに留意されたい。サーバクラスタのサーバインスタンスは多数のコンポーネント６、７を動作させるように構成される。
【００１５】
図２は、いわゆる高可用性ＸＭＰＰ（Ｅｘｔｅｎｓｉｂｌｅ Ｍｅｓｓａｇｉｎｇ ａｎｄ Ｐｒｅｓｅｎｃｅ Ｐｒｏｔｏｃｏｌ）コンポーネント実装を用いた、ＸＭＰＰコンポーネントベンダによって使用されている従来技術の方法を示す。ＸＭＰＰは、メッセージ及びプレゼント情報（ｐｒｅｓｅｎｔ ｉｎｆｏｒｍａｔｉｏｎ）をほぼリアルタイムで交換するためにＸＭＬエレメントをストリーミングするためのプロトコルである。ＩＥＴＦのＸＭＰＰワークグループはＪａｂｂｅｒプロトコルをＩＥＴＦによって承認されたインスタントメッセージング（ＩＭ）及びプレゼンス技術としてさらに適合させた。提供されているプロトコルは、ｈｔｔｐ：／／ｗｗｗ．ｉｅｔｆ．ｏｒｇ／ｒｆｃ／ｒｆｃ３９２０．ｔｘｔから入手可能なＲＦＣ３９２０（ＸＭＰＰコア）、及びｈｔｔｐ：／／ｗｗｗ．ｉｅｔｆ．ｏｒｇ／ｒｆｃ／ｒｆｃ３９２ｌ．ｔｘｔから入手可能なＲＦＣ３９２１（ＸＭＰＰコアに対するＩＭ及びプレゼンス拡張部）であり、これらのＲＦＣテキストは参照により本明細書に組み込む。これに加えて、ＪａｂｂｅｒコミュニティはＪａｂｂｅｒ拡張プロトコル（ＸＥＰ）を管理している。
【００１６】
ＸＭＰＰは高信頼のコンポーネントがＸＭＰＰサーバに接続することを可能にし、ＸＭＰＰサーバ及びＸＭＰＰコンポーネントは１つ以上の相互のＸＭＰＰセッションを維持する。そのようなセッションはトランスポート接続、特にＴＣＰ接続上で確立される。メッセージセッションはＴＣＰ接続を介してＸＭＬスタンザのストリームとして搬送される。
【００１７】
図２（Ａ）に示されているように、従来技術の高可用性実装は、マスタＸＭＰＰコンポーネント２１が故障した場合に引き継ぐためにバックアップＸＭＰＰコンポーネント２０を使用することにある。ＸＭＰＰコンポーネントを実行するために、ＸＭＰＰサーバ２２はマスタコンポーネント２１との単一のセッションを維持するにすぎない。バックアップＸＭＰＰコンポーネント２０はマスタコンポーネント２１が順調に機能している限りオフラインで機能する。この状況では、バックアップコンポーネントは、図２（Ｂ）に示されているように、マスタコンポーネントが使用できなくなった場合にバックアップコンポーネントが直ちに引き継ぐことができるように、必要とされる構成及び／又はリアルタイム情報全てをマスタコンポーネント２１から複製する。しかし、ＸＭＰＰセッションが存在せず、ＸＭＰＰサーバとバックアップコンポーネントの間で新しいセッションを開く必要があるため、ユーザはサービスの使用可能でない期間を知覚することになる。
【００１８】
本発明の主な着想は、バックアップコンポーネントを提供することに次いで、一方の側のサーバと他方の側のコンポーネント及びバックアップコンポーネントとの間にバックアッププロトコルセッションが提供されることである。
【００１９】
この概念の可能な実施形態が図３（Ａ）及び図３（Ｂ）に示されている。この例では、ＸＭＰＰプロトコルが使用される。しかし、図のシステム及び方法は、トランスポート接続上で、通常はＴＣＰを使用して搬送される任意の他のプロトコルで実施することもできることを当業者なら理解するであろう。ＸＭＰＰに対する代替の一例は、Ｄｉａｍｅｔｅｒである。Ｄｉａｍｅｔｅｒベースプロトコルは、ネットワークアクセス又はＩＰモビリティなどの応用例のために認証、許可、アカウンティング（ＡＡＡ）フレームワークを提供することが意図されており、ｈｔｔｐ：／／ｗｗｗ．ｉｅｔｆ．ｏｒｇ／ｒｆｃ／ｒｆｃ３５８８．ｔｘｔから入手可能なＲＦＣ３５８８に定義されている。
【００２０】
図３（Ａ）の例では、ＸＭＰＰコンポーネントが３つのノードのクラスタにわたって分散されている。各ノードには、同じＸＭＰＰコンポーネントの１つのインスタンス３１、３２、３３があり、各インスタンス３１、３２、３３はサーバ３０との単一のＸＭＰＰセッション３４、３５、３６を維持する。全てのインスタンス３１〜３３及びそれらの対応するセッション３４〜３６は同時にアクティブであり、その結果、トラフィックを全てのＸＭＰＰセッションにわたって効果的に分割することができる。換言すれば、同じＸＭＰＰコンポーネントの総処理負担を、クラスタ内でアクティブである異なるインスタンスにわたって均等に分散することができる。そのような均等分散の場合には、ｎ個のノードのクラスタの各インスタンスの処理負担がおよそｎ分の１に分割されることになる。
【００２１】
しかし、いくつかのシステムでは、不均等な分散を有することが好ましい可能性があることを当業者なら理解するであろう。これは、例えば、あるコンポーネントが別のコンポーネントより高い、使用可能な処理能力を有する場合である。可能な変形形態によれば、各コンポーネントの負荷を測定するようにサーバを構成することができ、トラフィックの分割はそのような負荷測定に基づくものとすることができよう。これについては図４を参照して下記でさらに論じる。
【００２２】
インスタンスの１つ、例えば図３（Ｂ）におけるインスタンス３が故障した場合、セッション３上で送られるトラフィックはセッション１及び／又はセッション２に自動的に再度割り当てられる。
【００２３】
クラスタ内で同時にアクティブである異なるプロトコルセッションに向かってトラフィックを割り当てること、及び障害時の自動再割当ては、サーバ内に設けられた特別なモジュールによって行うことができる。次に、フォールトトレラント（ＦＴ）モジュールとも呼ばれるそのようなプロトコルセッション割当てモジュールの一実施形態について、図４を参照して例示する。
【００２４】
この実施形態によれば、ＦＴモジュール４２はＸＭＰＰサーバ４０内で実装され、典型的にはいくつかのＴＣＰ接続の上で開かれた使用可能なＸＭＰＰセッションの間で、ＸＭＰＰコンポーネントに対して指定されたトラフィックをどのように分割するか決定する責任を担う。
【００２５】
同じコンポーネントとの１組のＸＭＰＰセッションを開いたとき、ＸＭＰＰサーバ４０は、通常はセッションＩＤで識別される確率済みＸＭＰＰセッションのリスト４１についてＦＴモジュールに通知することになる。パケットをＸＭＰＰコンポーネントに転送しなければならないとき、ＦＴモジュールはどのＸＭＰＰセッションを使用するか判断し、それに応じてパケットを送ることになる。以下のものなど、様々なアルゴリズムを使用することができる。
− 各ＸＭＰＰセッションが順に使用されるラウンドロビン法。ＦＴモジュールは最後のセッションＩＤ（又はそれに関連する変数）を覚えており、次のパケットを次のセッションＩＤによって識別される次のセッションに送る。そのようなアルゴリズムは多数のコンポーネントがあるとき有用となり、実装するのが非常に簡単であるという利点を有する。
− ハッシュ法：ＦＴモジュールは、最初に、「フロー」（例えば、「スレッドＩＤ」（があればそれ）と結合された「ｔｏ」及び「ｆｒｏｍ」属性）を識別するＸＭＰＰパケット内のいくつかのフィールドにわたってハッシュ（例えば、ＣＲＣ１６）を実施することによって鍵を選択する。各セッションＩＤには、鍵空間内の一意の領域が割り当てられる。ＦＴモジュールはこの鍵を使用し、パケットを送る必要があるセッションＩＤを決定する。そのようなアルゴリズムは専用のコンポーネントを拾い上げる必要がある場合特に適切なものとなるがより複雑である。
− ハッシュ法の、ラウンドロビン法又は任意の他の単純なアルゴリズムとの組合せ：ハッシュ法により、可能なコンポーネントのリストが返された場合には、判断するために別の方法を使用しなければならないことになり、これは例えば、ラウンドロビン法、又は下記の他の方法のうちの１つとすることができよう。
− 負荷に基づく方法：各コンポーネントに対する処理負荷に関する情報を得るように、サーバを構成することができる。次いで、パケットを負荷の最も小さいコンポーネントのセッションに送ることができよう。
− パケットを「任意の」コンポーネントにランダムに送る「ランダム」法。
− ある種のパケットが同じセッション上で常に送られる「常に同じ」法。
− 例えば最も小さい識別子を有するコンポーネントにパケットを送る、識別子に基づく方法、など。
【００２６】
本発明の原理について、特定の実施形態に関連して上述したが、この説明は、例として記載されているにすぎず、添付の特許請求の範囲によって決定される保護の範囲を限定するものとして記載されているのではないことを明確に理解されたい。
【技術分野】
【０００１】
本発明は、プロトコルコンポーネント、少なくとも２つのノードを有してプロトコルコンポーネントを動作させるように構成されているクラスタ、及びＴＣＰ接続などトランスポート接続上でクラスタのノードとのプロトコルセッションを維持するように構成されたサーバを備えた高可用性処理のためのシステムに関する。また、本発明はトランスポート接続上のプロトコルセッションを介した高可用性処理のための方法に関する。
【背景技術】
【０００２】
より高い可用性と低ダウンタイムを必要とする応用例が増加するにつれて、フォールトトレラントな高可用性処理システムに大きな関心が寄せられている。１つの知られている解決策はプロセッサのクラスタグループを相互接続するネットワークを必要とする（ｉｍｐｌｙ）。クラスタはハードウェア冗長の原理に基づくものであり、通常は可用性の増大のために単一のシステムとして管理される複数のノードからなる。
【０００３】
高可用性クラスタに関する最も一般的なサイズは２つのノード、例えばマスタノードとバックアップノードである。現在、コンポーネント実装が高可用性であるとベンダが主張するときには、コンポーネントが、クラスタ化された環境内で動作すること、またコンポーネントの１つのインスタンスがサーバとプロトコルセッションを維持することを意味する。一般に、マスタコンポーネントは、マスタコンポーネントが順調に機能している限りオフラインで機能するがマスタコンポーネントが故障したとき使用可能になるバックアップコンポーネントによってバックアップされる。換言すれば、現行の「高可用性」アーキテクチャはコンポーネントのいくつかのインスタンス（マスタコンポーネント、及び１つ又は複数のバックアップコンポーネント）からなるが、マスタコンポーネントとサーバの間に単一のプロトコルセッションしかない。マスタコンポーネントが故障した場合、新しいプロトコルセッションをサーバとバックアップコンポーネントの間で開く必要がある。従って、サーバはサービスの使用可能でない期間を知覚することになる。実際には、コンポーネントに対する処理負担及びコンポーネントが故障する確率は低減されない。はっきり言えば、コンポーネントをバックアップコンポーネントによって支援してもコンポーネントに対する処理負担は減少しない。コンポーネントが使用できなくなる確率はバックアップコンポーネントが有っても無くてもちょうど同じである。さらに、バックアップコンポーネントに対する処理負担は通常、マスタコンポーネントに対する処理負担に近く、その結果、この解決策の総処理負担は単一のコンポーネントの処理負担のほぼ２倍になる。
【発明の概要】
【発明が解決しようとする課題】
【０００４】
本発明の目的は、コンポーネントに対する処理負担を低減し、使用可能なリソースに対する負荷を低減するように構成可能であり、従ってコンポーネントのインスタンスのクラッシュ及び／又は障害の確率を低減する、トランスポート接続に基づく高可用性コンポーネント実装を提供することである。
【課題を解決するための手段】
【０００５】
この目的を達成するために、本発明によるシステムは、クラスタが、少なくとも２つのインスタンスがアクティブであるように前記少なくとも２つのノードのそれぞれにおいてプロトコルコンポーネントの１つのインスタンスを維持するように構成される点、またサーバが、プロトコルセッションを各インスタンスと同時に維持するように構成される点を特徴とする。さらに、従来技術の問題は本発明の方法によって解決され、この方法は、基本的に、プロトコルコンポーネントを少なくとも２つのノードにわたって分散し、同じプロトコルコンポーネントの、１つのインスタンスが各ノード上で動作すること、及び１つ又は複数のトランスポート接続上でこのプロトコルコンポーネントと少なくとも２つのプロトコルセッションを開くことによって特徴付けられる。
【０００６】
本発明のシステム及び方法は、プロトコルコンポーネントに対する処理負担を低減することによって、真の負荷平衡機構からプロトコルに対する利益をもたらすことができるという利点を有する。というのは、プロトコルコンポーネントが少なくとも２つのノードにわたって分散され、それらの少なくとも２つのプロトコルセッションが依然としてアクティブであるためそれらのノードに対するトラフィックを連続的に適切に調整することができるからである。
【０００７】
「プロトコルセッション」という用語は広い意味で解釈される必要があり、ＴＣＰ（伝送制御プロトコル）接続を介したＸＭＰＰセッションなどトランスポート接続上の任意の持続性のある接続を指すが、例えばＴＣＰ又はＳＣＴＰ（ストリーム制御伝送プロトコル）接続を介したＤｉａｍｅｔｅｒプロトコル接続をも含むことに留意されたい。原則として、プロトコルセッションを使用する、またトランスポート接続上での使用に適した任意の他のプロトコルが本発明によって想定されている。
【０００８】
有利な実施形態が従属請求項に記載されている。
【０００９】
好ましくは、このシステムは、障害のあるインスタンスとのプロトコルセッション上で送られるトラフィックを異なるアクティブなプロトコルセッションに再度割り当てるように構成される。そのようにして恒久的な可用性が確保される。
【００１０】
好ましい実施形態によれば、サーバは、所定のアルゴリズムに従ってプロトコルパケットを複数のインスタンスのそれぞれに代わりに割り当てるためのモジュールを備える。このモジュールは通常、そのプロトコルコンポーネントとのアクティブなプロトコルセッションのリストにアクセスすることができ、サーバはプロトコルパケットを、これらのパケットを所定のアルゴリズムに従って送るモジュールに送達するように構成される。ラウンドロビン法、ハッシュ法、ランダム法、固定割当て法、セッション識別子に基づく方法、前記方法のうちの１つ以上の組合せなど、多数の様々なアルゴリズムが可能であることを当業者なら理解するであろう。これらの方法は、図４を参照してさらに明らかにされることになる。
【００１１】
本発明の方法の異なる態様によれば、サーバはプロトコルコンポーネントの各インスタンスに対する処理負荷を測定し、プロトコルパケットの割当てはその処理負荷測定に基づく。そのようにして、インスタンス間で非常に効率的な負荷平衡を実施することができる。
【００１２】
添付の図面を使用し、本発明の現在好ましい非限定的な例示的実施形態を示す。以下の詳細な説明を添付の図面と併せ読めば、本発明の上記の、及び他の利点、特徴、及び目的がより明らかになり、本発明についてより良く理解されよう。
【図面の簡単な説明】
【００１３】
【図１】本発明のシステム及び方法を実施することができる典型的なコンピュータネットワークの例を示す図である。
【図２Ａ】従来技術の高可用性実装を概略的に示す図である。
【図２Ｂ】従来技術の高可用性実装を概略的に示す図である。
【図３Ａ】本発明のシステム及び方法の一実施形態を概略的に示す図である。
【図３Ｂ】本発明のシステム及び方法の一実施形態を概略的に示す図である。
【図４】本発明のシステム及び方法において使用するように構成されたＸＭＰＰサーバを概略的に表した図である。
【発明を実施するための形態】
【００１４】
図１に、多数のクライアント１、多数のサーバ２、並びに第１のサーバ及び第２のサーバ５からなるサーバクラスタ３を有する典型的なコンピュータシステムを示す。サーバクラスタ３は通常、同じマシン上で動作することができる、又は異なるマシン上に位置することができる多数のサーバインスタンス又はプロセスからなることに留意されたい。サーバクラスタのサーバインスタンスは多数のコンポーネント６、７を動作させるように構成される。
【００１５】
図２は、いわゆる高可用性ＸＭＰＰ（Ｅｘｔｅｎｓｉｂｌｅ Ｍｅｓｓａｇｉｎｇ ａｎｄ Ｐｒｅｓｅｎｃｅ Ｐｒｏｔｏｃｏｌ）コンポーネント実装を用いた、ＸＭＰＰコンポーネントベンダによって使用されている従来技術の方法を示す。ＸＭＰＰは、メッセージ及びプレゼント情報（ｐｒｅｓｅｎｔ ｉｎｆｏｒｍａｔｉｏｎ）をほぼリアルタイムで交換するためにＸＭＬエレメントをストリーミングするためのプロトコルである。ＩＥＴＦのＸＭＰＰワークグループはＪａｂｂｅｒプロトコルをＩＥＴＦによって承認されたインスタントメッセージング（ＩＭ）及びプレゼンス技術としてさらに適合させた。提供されているプロトコルは、ｈｔｔｐ：／／ｗｗｗ．ｉｅｔｆ．ｏｒｇ／ｒｆｃ／ｒｆｃ３９２０．ｔｘｔから入手可能なＲＦＣ３９２０（ＸＭＰＰコア）、及びｈｔｔｐ：／／ｗｗｗ．ｉｅｔｆ．ｏｒｇ／ｒｆｃ／ｒｆｃ３９２ｌ．ｔｘｔから入手可能なＲＦＣ３９２１（ＸＭＰＰコアに対するＩＭ及びプレゼンス拡張部）であり、これらのＲＦＣテキストは参照により本明細書に組み込む。これに加えて、ＪａｂｂｅｒコミュニティはＪａｂｂｅｒ拡張プロトコル（ＸＥＰ）を管理している。
【００１６】
ＸＭＰＰは高信頼のコンポーネントがＸＭＰＰサーバに接続することを可能にし、ＸＭＰＰサーバ及びＸＭＰＰコンポーネントは１つ以上の相互のＸＭＰＰセッションを維持する。そのようなセッションはトランスポート接続、特にＴＣＰ接続上で確立される。メッセージセッションはＴＣＰ接続を介してＸＭＬスタンザのストリームとして搬送される。
【００１７】
図２（Ａ）に示されているように、従来技術の高可用性実装は、マスタＸＭＰＰコンポーネント２１が故障した場合に引き継ぐためにバックアップＸＭＰＰコンポーネント２０を使用することにある。ＸＭＰＰコンポーネントを実行するために、ＸＭＰＰサーバ２２はマスタコンポーネント２１との単一のセッションを維持するにすぎない。バックアップＸＭＰＰコンポーネント２０はマスタコンポーネント２１が順調に機能している限りオフラインで機能する。この状況では、バックアップコンポーネントは、図２（Ｂ）に示されているように、マスタコンポーネントが使用できなくなった場合にバックアップコンポーネントが直ちに引き継ぐことができるように、必要とされる構成及び／又はリアルタイム情報全てをマスタコンポーネント２１から複製する。しかし、ＸＭＰＰセッションが存在せず、ＸＭＰＰサーバとバックアップコンポーネントの間で新しいセッションを開く必要があるため、ユーザはサービスの使用可能でない期間を知覚することになる。
【００１８】
本発明の主な着想は、バックアップコンポーネントを提供することに次いで、一方の側のサーバと他方の側のコンポーネント及びバックアップコンポーネントとの間にバックアッププロトコルセッションが提供されることである。
【００１９】
この概念の可能な実施形態が図３（Ａ）及び図３（Ｂ）に示されている。この例では、ＸＭＰＰプロトコルが使用される。しかし、図のシステム及び方法は、トランスポート接続上で、通常はＴＣＰを使用して搬送される任意の他のプロトコルで実施することもできることを当業者なら理解するであろう。ＸＭＰＰに対する代替の一例は、Ｄｉａｍｅｔｅｒである。Ｄｉａｍｅｔｅｒベースプロトコルは、ネットワークアクセス又はＩＰモビリティなどの応用例のために認証、許可、アカウンティング（ＡＡＡ）フレームワークを提供することが意図されており、ｈｔｔｐ：／／ｗｗｗ．ｉｅｔｆ．ｏｒｇ／ｒｆｃ／ｒｆｃ３５８８．ｔｘｔから入手可能なＲＦＣ３５８８に定義されている。
【００２０】
図３（Ａ）の例では、ＸＭＰＰコンポーネントが３つのノードのクラスタにわたって分散されている。各ノードには、同じＸＭＰＰコンポーネントの１つのインスタンス３１、３２、３３があり、各インスタンス３１、３２、３３はサーバ３０との単一のＸＭＰＰセッション３４、３５、３６を維持する。全てのインスタンス３１〜３３及びそれらの対応するセッション３４〜３６は同時にアクティブであり、その結果、トラフィックを全てのＸＭＰＰセッションにわたって効果的に分割することができる。換言すれば、同じＸＭＰＰコンポーネントの総処理負担を、クラスタ内でアクティブである異なるインスタンスにわたって均等に分散することができる。そのような均等分散の場合には、ｎ個のノードのクラスタの各インスタンスの処理負担がおよそｎ分の１に分割されることになる。
【００２１】
しかし、いくつかのシステムでは、不均等な分散を有することが好ましい可能性があることを当業者なら理解するであろう。これは、例えば、あるコンポーネントが別のコンポーネントより高い、使用可能な処理能力を有する場合である。可能な変形形態によれば、各コンポーネントの負荷を測定するようにサーバを構成することができ、トラフィックの分割はそのような負荷測定に基づくものとすることができよう。これについては図４を参照して下記でさらに論じる。
【００２２】
インスタンスの１つ、例えば図３（Ｂ）におけるインスタンス３が故障した場合、セッション３上で送られるトラフィックはセッション１及び／又はセッション２に自動的に再度割り当てられる。
【００２３】
クラスタ内で同時にアクティブである異なるプロトコルセッションに向かってトラフィックを割り当てること、及び障害時の自動再割当ては、サーバ内に設けられた特別なモジュールによって行うことができる。次に、フォールトトレラント（ＦＴ）モジュールとも呼ばれるそのようなプロトコルセッション割当てモジュールの一実施形態について、図４を参照して例示する。
【００２４】
この実施形態によれば、ＦＴモジュール４２はＸＭＰＰサーバ４０内で実装され、典型的にはいくつかのＴＣＰ接続の上で開かれた使用可能なＸＭＰＰセッションの間で、ＸＭＰＰコンポーネントに対して指定されたトラフィックをどのように分割するか決定する責任を担う。
【００２５】
同じコンポーネントとの１組のＸＭＰＰセッションを開いたとき、ＸＭＰＰサーバ４０は、通常はセッションＩＤで識別される確率済みＸＭＰＰセッションのリスト４１についてＦＴモジュールに通知することになる。パケットをＸＭＰＰコンポーネントに転送しなければならないとき、ＦＴモジュールはどのＸＭＰＰセッションを使用するか判断し、それに応じてパケットを送ることになる。以下のものなど、様々なアルゴリズムを使用することができる。
− 各ＸＭＰＰセッションが順に使用されるラウンドロビン法。ＦＴモジュールは最後のセッションＩＤ（又はそれに関連する変数）を覚えており、次のパケットを次のセッションＩＤによって識別される次のセッションに送る。そのようなアルゴリズムは多数のコンポーネントがあるとき有用となり、実装するのが非常に簡単であるという利点を有する。
− ハッシュ法：ＦＴモジュールは、最初に、「フロー」（例えば、「スレッドＩＤ」（があればそれ）と結合された「ｔｏ」及び「ｆｒｏｍ」属性）を識別するＸＭＰＰパケット内のいくつかのフィールドにわたってハッシュ（例えば、ＣＲＣ１６）を実施することによって鍵を選択する。各セッションＩＤには、鍵空間内の一意の領域が割り当てられる。ＦＴモジュールはこの鍵を使用し、パケットを送る必要があるセッションＩＤを決定する。そのようなアルゴリズムは専用のコンポーネントを拾い上げる必要がある場合特に適切なものとなるがより複雑である。
− ハッシュ法の、ラウンドロビン法又は任意の他の単純なアルゴリズムとの組合せ：ハッシュ法により、可能なコンポーネントのリストが返された場合には、判断するために別の方法を使用しなければならないことになり、これは例えば、ラウンドロビン法、又は下記の他の方法のうちの１つとすることができよう。
− 負荷に基づく方法：各コンポーネントに対する処理負荷に関する情報を得るように、サーバを構成することができる。次いで、パケットを負荷の最も小さいコンポーネントのセッションに送ることができよう。
− パケットを「任意の」コンポーネントにランダムに送る「ランダム」法。
− ある種のパケットが同じセッション上で常に送られる「常に同じ」法。
− 例えば最も小さい識別子を有するコンポーネントにパケットを送る、識別子に基づく方法、など。
【００２６】
本発明の原理について、特定の実施形態に関連して上述したが、この説明は、例として記載されているにすぎず、添付の特許請求の範囲によって決定される保護の範囲を限定するものとして記載されているのではないことを明確に理解されたい。
【特許請求の範囲】
【請求項１】
プロトコルコンポーネント、
少なくとも２つのノードを有し、前記プロトコルコンポーネントを動作させるように構成されているクラスタ、及び
トランスポート接続上で前記クラスタのノードとのプロトコルセッションを維持するように構成されたサーバ
を備えた高可用性処理のためのコンピュータシステムであって、
前記クラスタが、少なくとも２つのインスタンスがアクティブであるように前記少なくとも２つのノードのそれぞれにおいて前記プロトコルコンポーネントの、１つのインスタンスを維持するように構成されること、及び前記サーバが、プロトコルセッションを各インスタンスと同時に維持するように構成されることを特徴とするコンピュータシステム。
【請求項２】
請求項１記載のコンピュータシステムであって、さらに、
前記少なくとも２つのインスタンスのうちの障害のあるインスタンスとのプロトコルセッション上で送られるトラフィックを、前記少なくとも２つのインスタンスのうちの別のインスタンスとの維持されている異なるプロトコルセッションに再度割り当てるように構成されたことを特徴とするコンピュータシステム。
【請求項３】
請求項１記載のコンピュータシステムであって、
前記トランスポート接続上の前記プロトコルセッションが、以下のプロトコル、即ちＸＭＰＰ、Ｄｉａｍｅｔｅｒ、又はトランスポート接続上で使用するのに適した任意の他のシグナリングプロトコルのうちの１つを使用することを特徴とするコンピュータシステム。
【請求項４】
請求項１記載のコンピュータシステムであって、
前記サーバが、所定のアルゴリズムに従ってプロトコルパケットを前記複数のインスタンスのそれぞれに代わりに割り当てるためのモジュールを備えたことを特徴とするコンピュータシステム。
【請求項５】
請求項４記載のコンピュータシステムであって、
前記モジュールが、そのプロトコルコンポーネントとのアクティブなプロトコルセッションのリストにアクセスすることができること、及び前記サーバが、プロトコルパケットを前記モジュールに送達するように構成されたことを特徴とするコンピュータシステム。
【請求項６】
少なくとも２つのノードを有しプロトコルコンポーネントを動作させるように構成されているクラスタ内で使用するための、トランスポート接続上でのセッションを介する高可用性処理のための方法であって、
プロトコルコンポーネントが少なくとも２つのノードにわたって分散され、前記プロトコルコンポーネントの、１つのインスタンスが各ノード上で動作すること、及び
サーバが、１つ又は複数のトランスポート接続上でこのプロトコルコンポーネントに対して少なくとも２つのプロトコルセッションを開くことを特徴とする方法。
【請求項７】
請求項６記載の方法であって、ある決定されたアルゴリズムに基づいて、プロトコルパケットが前記少なくとも２つのプロトコルセッションに割り当てられることを特徴とする方法。
【請求項８】
請求項７記載の方法であって、前記アルゴリズムが、ラウンドロビン法、ハッシュ法、ランダム法、固定割当て法、セッション識別子に基づく方法、又は前記方法のうちの１つ以上の組合せのうちの１つであることを特徴とする方法。
【請求項９】
請求項６記載の方法であって、前記サーバが前記プロトコルコンポーネントの各インスタンスに対する処理負荷を測定し、前記プロトコルパケットの割当てが前記処理負荷測定に基づくことを特徴とする方法。
【請求項１０】
請求項６記載の方法であって、前記少なくとも２つのプロトコルセッションのうちのあるプロトコルセッション上で前記少なくとも２つのインスタンスのうちの障害のあるインスタンスに送られるプロトコルパケットが前記少なくとも２つのプロトコルセッションのうちの異なるプロトコルセッションに再度割り当てられることを特徴とする方法。
【請求項１】
プロトコルコンポーネント、
少なくとも２つのノードを有し、前記プロトコルコンポーネントを動作させるように構成されているクラスタ、及び
トランスポート接続上で前記クラスタのノードとのプロトコルセッションを維持するように構成されたサーバ
を備えた高可用性処理のためのコンピュータシステムであって、
前記クラスタが、少なくとも２つのインスタンスがアクティブであるように前記少なくとも２つのノードのそれぞれにおいて前記プロトコルコンポーネントの、１つのインスタンスを維持するように構成されること、及び前記サーバが、プロトコルセッションを各インスタンスと同時に維持するように構成されることを特徴とするコンピュータシステム。
【請求項２】
請求項１記載のコンピュータシステムであって、さらに、
前記少なくとも２つのインスタンスのうちの障害のあるインスタンスとのプロトコルセッション上で送られるトラフィックを、前記少なくとも２つのインスタンスのうちの別のインスタンスとの維持されている異なるプロトコルセッションに再度割り当てるように構成されたことを特徴とするコンピュータシステム。
【請求項３】
請求項１記載のコンピュータシステムであって、
前記トランスポート接続上の前記プロトコルセッションが、以下のプロトコル、即ちＸＭＰＰ、Ｄｉａｍｅｔｅｒ、又はトランスポート接続上で使用するのに適した任意の他のシグナリングプロトコルのうちの１つを使用することを特徴とするコンピュータシステム。
【請求項４】
請求項１記載のコンピュータシステムであって、
前記サーバが、所定のアルゴリズムに従ってプロトコルパケットを前記複数のインスタンスのそれぞれに代わりに割り当てるためのモジュールを備えたことを特徴とするコンピュータシステム。
【請求項５】
請求項４記載のコンピュータシステムであって、
前記モジュールが、そのプロトコルコンポーネントとのアクティブなプロトコルセッションのリストにアクセスすることができること、及び前記サーバが、プロトコルパケットを前記モジュールに送達するように構成されたことを特徴とするコンピュータシステム。
【請求項６】
少なくとも２つのノードを有しプロトコルコンポーネントを動作させるように構成されているクラスタ内で使用するための、トランスポート接続上でのセッションを介する高可用性処理のための方法であって、
プロトコルコンポーネントが少なくとも２つのノードにわたって分散され、前記プロトコルコンポーネントの、１つのインスタンスが各ノード上で動作すること、及び
サーバが、１つ又は複数のトランスポート接続上でこのプロトコルコンポーネントに対して少なくとも２つのプロトコルセッションを開くことを特徴とする方法。
【請求項７】
請求項６記載の方法であって、ある決定されたアルゴリズムに基づいて、プロトコルパケットが前記少なくとも２つのプロトコルセッションに割り当てられることを特徴とする方法。
【請求項８】
請求項７記載の方法であって、前記アルゴリズムが、ラウンドロビン法、ハッシュ法、ランダム法、固定割当て法、セッション識別子に基づく方法、又は前記方法のうちの１つ以上の組合せのうちの１つであることを特徴とする方法。
【請求項９】
請求項６記載の方法であって、前記サーバが前記プロトコルコンポーネントの各インスタンスに対する処理負荷を測定し、前記プロトコルパケットの割当てが前記処理負荷測定に基づくことを特徴とする方法。
【請求項１０】
請求項６記載の方法であって、前記少なくとも２つのプロトコルセッションのうちのあるプロトコルセッション上で前記少なくとも２つのインスタンスのうちの障害のあるインスタンスに送られるプロトコルパケットが前記少なくとも２つのプロトコルセッションのうちの異なるプロトコルセッションに再度割り当てられることを特徴とする方法。
【図１】
【図２Ａ】
【図２Ｂ】
【図３Ａ】
【図３Ｂ】
【図４】
【図２Ａ】
【図２Ｂ】
【図３Ａ】
【図３Ｂ】
【図４】
【公表番号】特表２０１１−５０５６１９（Ｐ２０１１−５０５６１９Ａ）
【公表日】平成２３年２月２４日（２０１１．２．２４）
【国際特許分類】
【出願番号】特願２０１０−５３５３００（Ｐ２０１０−５３５３００）
【出願日】平成２０年１１月２４日（２００８．１１．２４）
【国際出願番号】ＰＣＴ／ＥＰ２００８／０１０１６３
【国際公開番号】ＷＯ２００９／０６８３１７
【国際公開日】平成２１年６月４日（２００９．６．４）
【出願人】（３９１０３０３３２）アルカテル−ルーセント (1,149)
【Ｆターム（参考）】
【公表日】平成２３年２月２４日（２０１１．２．２４）
【国際特許分類】
【出願日】平成２０年１１月２４日（２００８．１１．２４）
【国際出願番号】ＰＣＴ／ＥＰ２００８／０１０１６３
【国際公開番号】ＷＯ２００９／０６８３１７
【国際公開日】平成２１年６月４日（２００９．６．４）
【出願人】（３９１０３０３３２）アルカテル−ルーセント (1,149)
【Ｆターム（参考）】
[ Back to top ]