JP2007529066A - アフィニティ管理のための方法およびシステム - Google Patents

Abstract

複数のアドレッシング・エンティティ（３１１−３１５）が、アドレッシング・エンティティ内のグループ・アフィニティを保持しながら、複数のサービス・プロバイダ（３０１−３０４）全体にわたって平衡されると必要がある分散コンピュータ・システムにおけるアフィニティ管理のための方法およびシステムが提供される。複数のアドレッシング・エンティティの各々についての識別子が提供され、アフィニティを有するアドレッシング・エンティティのグループの各メンバについての識別子は、同じグループ識別子である。サービスのインスタンスを提供するために、アドレッシング・エンティティによりアドレスされるために利用可能な複数のサービス・プロバイダのリストが提供される。サービス・プロバイダへのアドレッシング・エンティティの配分は、アルゴリズムにより管理される。このアルゴリズムは、標準整数を得るためにアドレッシング・エンティティの識別子にハッシュ関数を適用する（２０５）ステップと、標準整数をサービス・プロバイダの数で割って（２０６）法を得るステップと、この法を参照してサービス・プロバイダを選ぶ（２０７）ステップとを含む。アドレッシング・エンティティは、選ばれたサービス・プロバイダにより提供されるサービスのインスタンス（３０６）に送られる。

Description

本発明はアフィニティ管理の分野に関する。特に、本発明は、メッセージング・システムを含む分散コンピュータ・システムにおけるアフィニティ管理に関する。

アフィニティ管理は、複数のエンティティが同様なやり方で取り扱われることを要求する状況において必要とされる。そのようなアフィニティの１つの例は、分散コンピュータ・システムにおけるＷｅｂＳｐｈｅｒｅ ＭＱ（ＷｅｂＳｐｈｅｒｅおよびＭＱは、インターナショナル・ビジネス・マシーンズ・コーポレーションの商標である）メッセージング環境において用いられることがある。メッセージのグループが送信されるとき、すべてのメンバが到着するまでグループのメンバが全く配信されない場合がある。しかしながら、グループの各メンバがそれぞれ別のキュー・マネージャに配信されれば、キュー・マネージャは、このキュー・マネージャがグループのすべてのメンバを見るまで配信しないので、結果として、グループ・メンバは決して配信されないことになる。この場合、そのグループのメンバは、それらすべてが同じキュー・マネージャに送られることを確実にするために、アフィニティを用いて取り扱われる必要がある。

アフィニティが要求される別の例は、質問および応答の形で２つのアプリケーション間を流れる一連のメッセージに依拠する２つのアプリケーションがあるか場合である。すべての応答が同じキュー・マネージャに送り返されることが重要となろう。作業負荷管理ルーチンがメッセージを、正しいキューのコピーを偶然ホストするどのようなキュー・マネージャにも送らないことが重要である。同様に、メッセージが順次処理されることを必要とするアプリケーション、例えば、順次取得されなければならないメッセージのバッチを送るファイル転送アプリケーションまたはデータ・ベース複製アプリケーションが考えられる。

クラスタ化キュー・マネージャにおいて、メッセージは、適切なキューのインスタンスをホストするどのようなキュー・マネージャにルーティングされても良い。アプリケーションを検査して、関連するメッセージを交換する必要性の如くのメッセージ・アフィニティを有するものがあるか否かを調べなければならない。もしメッセージが異なるキュー・マネージャにルーティングされると、メッセージ・アフィニティを用いたアプリケーションのロジックは混乱してしまうであろう。

メッセージング・システムにおけるアフィニティ管理は、アプリケーションがキューを開くやり方（例えば、ＭＱＯＰＥＮコール時のＢＩＮＤ＿ＯＮ＿ＯＰＥＮオプション）を変更することにより、対応できる。しかしながら、これには、アプリケーションがメッセージ・アフィニティの問題を理解していることを前提にするという不利な点がある。

本発明の１つの実施形態がＷｅｂＳｐｈｅｒｅ ＭＱ（ＩＢＭ社の登録商標）メッセージング・システムに即して説明される。特に、クラスタ化キュー・マネージャの環境下で説明される。しかしながら、本発明は、多くの関連するクライアント・アプリケーションが、あるウェブ・サービスの同じインスタンスを用いることを要求する、Ｗｅｂ Ｓｅｒｖｉｃｅｓのような、他の分散計算システムにも広範囲に適用可能である。別の例は、ＷｅｂＳｐｈｅｒｅ（ＩＢＭ社の登録商標）Ｅｄｇｅ Ｓｅｒｖｅｒシステムである。

本発明は、アドレッシング・エンティティのグループにより、そのグループの各メンバが、あるサービスの同じインスタンスに向けられるように、アフィニティが保たれねばならないどの状況においても適用可能である。ＷｅｂＳｐｈｅｒｅ ＭＱ（ＩＢＭ社の登録商標）の環境において、メッセージのグループはアフィニティを保持でき、すべてが同じキュー・マネージャに送られ得る。

アドレッシング・エンティティによるトランザクションの宛先の履歴を維持しても良く、そうすると、アドレッシング・エンティティ間にアフィニティがあれば、同じ宛先が確実に選ばれ得る。しかしながら、大量トランザクション・システムにおいては、すべてのトランザクションがどこに送られたかを示すそのような履歴を保持することが常に実際的または効率的であるというわけではない。

本発明の第１の局面によれば、分散コンピュータ・システムにおけるアフィニティ管理のための方法が提供され、この方法は、複数のアドレッシング・エンティティの各々についての識別子を提供するステップであって、アフィニティを有するアドレッシング・エンティティのグループの各メンバについての識別子は同じグループ識別子であるステップと、サービスのインスタンスを提供するために、アドレッシング・エンティティによりアドレスされるために利用可能なサービス・プロバイダの数を決定するステップと、標準整数を得るためにアドレッシング・エンティティの識別子にハッシュ関数を適用し、標準整数をサービス・プロバイダの数で割って法（ｍｏｄｕｌｕｓ）を得、この法を参照してサービス・プロバイダを選び、アドレッシング・エンティティを選ばれたサービス・プロバイダにより提供されるサービスのインスタンスに送るやり方に従ってサービス・プロバイダへのアドレッシング・エンティティの配分を管理するステップとを含む。

サービス・プロバイダの数を決定するステップは周期的に実行されても良く、サービス・プロバイダの数は、ある期間内で一定となる。サービス・プロバイダが動的であり、ある期間の間に参加または離脱しても、サービス・プロバイダの数は一定に保たれる。

上記方法は、法値により参照される、利用可能なサービス・プロバイダのインデックスを提供するステップを含んでも良い。例えば、６つの利用可能なサービス・プロバイダについて、法値は０〜５であり、各法値は、これらのサービス・プロバイダの１つについてのインデックスを提供できる。

選ばれたサービス・プロバイダが利用できなければ、アドレッシング・エンティティは、予め決められた順序で次のサービス・プロバイダに送られても良い。あるサービス・プロバイダが機能しなくなれば、前に配信されたアドレッシング・エンティティを取得するためのプロセスが作動されても良い。あるサービス・プロバイダが機能しなくなった場合、そのサービス・プロバイダは、代わりのサービス・プロバイダ中にグループ・アフィニティを有するアドレッシング・エンティティまったくないことを確認した後、復旧されても良い。また、あるサービス・プロバイダが機能しなった場合に、そのサービス・プロバイダに送られたアドレッシング・エンティティを再頒布しても良い。

１つの実施形態において、分散計算システムは、アドレッシング・エンティティがメッセージであり、サービス・プロバイダが１つ以上のクラスタ・キューのインスタンスをホストするクラスタ化キュー・マネージャであるメッセージング・システムであっても良く、グループ識別子は、汎用一意識別子（ＵＵＩＤ）の形であっても良い。

別の実施形態において、アドレッシング・エンティティはクライアント・アプリケーションとすることができ、サービス・プロバイダは、サービスのインスタンスをホストするＷｅｂ Ｓｅｒｖｉｃｅｓとすることができる。

本発明の第２の局面によれば、分散コンピュータ・システムにおけるアフィニティ管理のためのシステムが提供され、このシステムは、各々が識別子を有する複数のアドレッシング・エンティティであって、アフィニティを有するアドレッシング・エンティティのグループの各メンバについての識別子が同じグループ識別子である複数のアドレッシング・エンティティと、サービスのインスタンスを提供するために、アドレッシング・エンティティによりアドレスされるために利用可能な複数のサービス・プロバイダのリストと、標準整数を得るためにアドレッシング・エンティティの識別子にハッシュ関数を適用するステップ、標準整数をリスト中のサービス・プロバイダの数で割って法を得るステップ、およびこの法を参照してサービス・プロバイダを選ぶステップを有するアルゴリズムを用いてサービス・プロバイダへのアドレッシング・エンティティの配分を管理するための手段と、選ばれたサービス・プロバイダにより提供されるサービスのインスタンスにアドレッシング・エンティティを送るための手段とを含む。

サービス・プロバイダのリストは周期的に更新されても良く、リスト上のサービス・プロバイダの数は、ある期間内で一定となる。リスト中に示されるサービス・プロバイダを作業負荷マネージャに知らせるための機構が提供されても良い。このシステムは、サービス・プロバイダのインデックスを、法値により参照されるリストに含めることができる。

選ばれたサービス・プロバイダが利用できなければ、作業負荷マネージャは、アドレッシング・エンティティを、予め決められた順序で次のサービス・プロバイダに送ることができる。あるサービス・プロバイダが機能しなくなれば、前に配信されたアドレッシング・エンティティを取得するための手段が提供されても良い。あるサービス・プロバイダが機能しなくなれば、その機能しなくなったサービス・プロバイダが復旧される前に、代わりのサービス・プロバイダ中にグループ・アフィニティを有するアドレッシング・エンティティがまったくないことを確実にするための手段が提供され得る。あるサービス・プロバイダが機能しなくなった場合、そのサービス・プロバイダに送られたアドレッシング・エンティティを再頒布するための手段が提供されても良い。

１つの実施形態において、分散計算システムは、アドレッシング・エンティティがメッセージであり、サービス・プロバイダが１つ以上のクラスタ・キューのインスタンスをホストするクラスタ化キュー・マネージャであるメッセージング・システムであっても良い。グループ識別子は、汎用一意識別子（ＵＵＩＤ）の形であっても良い。

別の実施形態において、アドレッシング・エンティティはクライアント・アプリケーションとすることができ、サービス・プロバイダは、サービスのインスタンスをホストするＷｅｂ Ｓｅｒｖｉｃｅｓとすることができる。

本発明の第３の局面によれば、複数のアドレッシング・エンティティの各々についての識別子を提供するステップであって、アフィニティを有するアドレッシング・エンティティのグループの各メンバについての識別子が同じグループ識別子であるステップと、サービスのインスタンスを提供するために、アドレッシング・エンティティによりアドレスされるために利用可能なサービス・プロバイダの数を決定するステップと、標準整数を得るためにアドレッシング・エンティティの識別子にハッシュ関数を適用し、標準整数をサービス・プロバイダの数で割って法を得、この法を参照してサービス・プロバイダを選び、アドレッシング・エンティティを選ばれたサービス・プロバイダにより提供されるサービスのインスタンスに送る方法によりサービス・プロバイダへのアドレッシング・エンティティの配分を管理するステップとを実行するためのコンピュータ可読プログラム・コード手段を含むコンピュータ可読記憶媒体上に格納されたコンピュータ・プログラム製品が提供される。

本発明の実施形態を、単なる例示として、添付図面に関連して説明する。

図１は、分散計算システム１００の概略図を示す。このシステム１００は、本願に記載されるアフィニティ管理方法により提供することの可能なアフィニティ管理が必要とされる構成を概括的に例示するために用いられる。これは、広範な種々のアーキテクチャに適用できる。ＷｅｂＳｐｈｅｒｅ ＭＱ（ＩＢＭ社の登録商標）メッセージング・システムの形の１つの実施形態を説明する。

分散計算システム１００中の複数のアドレッシング・エンティティ１０２は、同じサービスを提供する複数のサービス・プロバイダ１０４にアドレスできる。システム１００における通信は、通信インフラストラクチャを提供する１つ以上のネットワーク１０６を介する。

用語「アドレッシング・エンティティ」は、サービス・プロバイダ１０４にアドレスするどのような手段も含む一般用語として用いられる。例えば、アドレッシング・エンティティは、クライアント・アプリケーションであっても良く、またはメッセージング・システムにおけるメッセージであっても良い。

複数のアドレッシング・エンティティ１０２は、グループ１０８を形成するために何らかのやり方で関連付けられることができ、そのグループのメンバはアフィニティを有している。グループ１０８のメンバは、利用可能なサービス・プロバイダ１０４からのサービスの同じインスタンスにアドレスすることにより、それらのアフィニティを保持しなければならない。

用語「サービス・プロバイダ」１０４も、一般的な意味で用いられる。複数のサービス・プロバイダ１０４は、これらの複数のサービス・プロバイダ１０４のどれもがアドレッシング・エンティティ１０２により、等しく選ばれ得るように、同じサービスのインスタンスをアドレッシング・エンティティ１０２に提供する。以下で説明されるメッセージング・システムの実施形態において、サービス・プロバイダ１０４はキュー・マネージャであり、複数のキュー・マネージャは、メッセージがアドレスされるキューのインスタンスをホストし得る。Ｗｅｂ Ｓｅｒｖｉｃｅｓ環境において、複数のサービス・プロバイダ１０４は各々、クライアント・アプリケーションによりアドレスされるサービスのインスタンスをホストし得る。

本明細書に記載されるアフィニティ管理の方法において、特定の時にどのサービス・プロバイダがグループ頒布に関与しているかが最初に決定される。すなわち、アドレッシング・エンティティにより等しく選ばれ得て、サービスを実行する、サービス・プロバイダである。関与しているサービス・プロバイダのリストは、例えばリストが改訂される時まで、ある期間にわたって一定である。その期間は、規則的に更新される期間であってもよく、またはその期間は、例えば、利用可能であり続けるリスト上のサービス・プロバイダの数によって決定される不規則な期間であってもよい。

リストが決定された後に、あるサービス・プロバイダが利用可能になっても、そのサービス・プロバイダは、そのリストが改訂されるまでリストに追加されない。同様に、あるサービス・プロバイダがリスト中に示されるが、利用可能でなくなっても、そのサービス・プロバイダは、リストが改訂されるまでリスト上に残る。以下で説明されるフェイルオーバ機構は、もはや利用できないサービス・プロバイダにアドレッシング・エンティティが送られるような場合に用いられる。

サービス・プロバイダのリストに基づき、その期間のリスト上のサービス・プロバイダの数が数えられる。この数は、その期間に各アドレッシング・エンティティに対するサービス・プロバイダを選ぶための選択または調和（バランシング）アルゴリズムにおいて用いられる。数０〜ｎにより参照されるサービス・プロバイダのインデックスが設定され、ここで、ｎは、リスト上のサービス・プロバイダの数である。

選択アルゴリズムは、アドレッシング・エンティティがサービス・プロバイダへアドレスすることを要求する場合に用いられる。アドレッシング・エンティティは識別子を有しており、この識別子は、名前、ＩＤ参照、汎用一意識別子（ＵＵＩＤ）等であり得る。ある１つのアフィニティを保持する必要のある複数のアドレッシング・エンティティから構成されるグループのメンバは、同じグループ識別子を有している。識別子は、標準整数を得るために、いずれかの適切なハッシュ演算によりハッシュされる。

標準整数は、現期間についてのリストから計数されたサービス・プロバイダの数ｎで割られて、法が得られる。この法は、アドレッシング・エンティティがどのサービス・プロバイダにアドレスすべきかを決定するためにインデックスを参照するために用いられる。

アフィニティ・グループのメンバであるアドレッシング・エンティティが同じ識別子、例えば、グループＩＤを有しているので、そのグループの各メンバは同じサービス・プロバイダに送られる。アドレッシング・エンティティが異なる識別子を有していれば、それらのエンティティは、選択アルゴリズムの結果に応じて、そのサービス・プロバイダのうちの何れかに送られる。その結果、アドレッシング・エンティティが、リスト中にある関与するサービス・プロバイダに満遍なく行きわたるようになる。

図２は、上記の方法を例示する流れ図である。第１のステップ２０１において、関与するサービス・プロバイダのリストが生成される。サービス・プロバイダの数ｎに基づく除数が決定される（２０２）。各法値についてサービス・プロバイダのインデックスが生成される（２０３）。

アドレッシング・エンティティが処理される（２０４）。標準整数を得るために、アドレッシング・エンティティの識別子のハッシュが実行される（２０５）。法を得るために、標準整数が除数ｎで割られる（２０６）。得られた法値について、サービス・プロバイダのインデックスが検索される（２０７）。アドレッシング・エンティティは、法に基づいてインデックス中で識別されたサービス・プロバイダに対して送られる（２０８）。

次に、処理待ちの別のアドレッシング・エンティティがあるかどうかが決定され（２０９）、もしあれば、この方法内のループ２１０が次のアドレッシング・エンティティについて実行される。アドレッシング・エンティティがもはやなければ、このプロセスは、処理されるべき次のアドレッシング・エンティティに備えて待機させられる（２１１）。

処理されるべきアドレッシング・エンティティがメッセージであるような、メッセージング環境において、ステップ２０４は、メッセージの到着によりトリガされ、ステップ２０５からステップ２０８がそのメッセージについて実行される。従って、ループ２１０は必要とされない。

この方法は、アドレッシング・エンティティのグループが、同じ識別子を有するアフィニティ・グループのメンバによってアフィニティを保持することを可能にし、従って同じサービス・プロバイダに送られることを可能にする。

利用できないサービス・プロバイダにアドレッシング・エンティティが送られる場合をを扱うために、フェイルオーバ機構が提供される。あるサービス・プロバイダが利用できなければ、アドレッシング・エンティティは、フェイルオーバ・リスト中の次のサービス・プロバイダに送られる。このように、利用できないサービス・プロバイダに送られるすべてのアドレッシング・エンティティは、同じフォールバック・サービス・プロバイダに送られ、それによってアドレッシング・エンティティのグループのアフィニティを保持する。

あるサービス・プロバイダが機能しなくなれば、そのアドレッシング・エンティティを返送して、再処理およびアフィニティを受け持つサービス・プロバイダに転送する必要があろう。そして、利用可能なリソース全体の中で、アフィニティをまったく有しないアドレッシング・エンティティを負荷バランシングする。

ＷｅｂＳｐｈｅｒｅ ＭＱ（ＩＢＭ社の登録商標）メッセージング・システムの環境における１つの実施形態を説明する。１つのネットワーク内の異なるコンピュータまたはノード上で走っているアプリケーションは、メッセージおよびキューイングを用いて通信することができる。メッセージングおよびキューイングによる通信は、複数のアプリケーションが、それらをリンクするためのプライベートな専用の論理接続を持つことなく、ネットワークを介して通信できるようにする。通信は、メッセージをメッセージ・キュー上に載せ、メッセージをメッセージ・キューから取り込むことにより行われる。

ネットワーク中の各ノードは、１つのキュー・マネージャを有している。これらのキュー・マネージャは、アプリケーションにより呼び出されるメッセージ・キュー・インタフェースを介してアプリケーションに接続する。メッセージ・キュー・インタフェースは、多くの異なるオペレーティングシステムおよびプラットホームをサポートする。

分散キューイング・システムにおいて、キュー・マネージャは独立であり、分散キューイングを用いて通信する。メッセージを別のキュー・マネージャに送る１つのキュー・マネージャは、伝送キュー、リモート・キュー・マネージャへのチャネルおよびキュー・マネージャがメッセージを送ろうとするすべてのキューについてのリモート・キュー定義を定義していなければならない。

複数のキュー・マネージャが１つのクラスタにグループ化される場合、それらのキュー・マネージャは、それらがホストするキューを、そのクラスタ中のすべての他のキュー・マネージャにとり利用可能にできる。どのキュー・マネージャも、各宛先についての明示的なチャンネル定義、リモート・キュー定義、または伝送キューの必要なしにメッセージを同じグループ中のどの他のキュー・マネージャにも送ることができる。１つのクラスタ中のすべてのキュー・マネージャは、単一の伝送キューを有しており、この伝送キューからキュー・マネージャはクラスタ中のどの他のキュー・マネージャにもメッセージを伝送できる。１つのクラスタ中の各キュー・マネージャは、その上でメッセージを受信する１つのクラスタ受信器チャネル、およびキュー・マネージャが自己導入およびそのクラスタについて学習するクラスタ送信器チャネルのみを定義する必要がある。

図３は、メッセージング・システム中のキュー・マネージャのクラスタ３００を示す。４つのキュー・マネージャＱＭ１ ３０１、ＱＭ２ ３０２、ＱＭ３ ３０３およびＱＭ４ ３０４が示してある。これらのキュー・マネージャの各々は、１つ以上のアプリケーション３１１、３１２、３１３、３１４、３１５の応対をする。

各キュー・マネージャは、そのキュー・マネージャにより応対されるアプリケーションのみがアクセス可能なローカル・キュー３０５を有することができる。クラスタ中の各キュー・マネージャは、クラスタ・キュー３０６も有することができる。クラスタ・キュー３０６には、クラスタ中のどの他のキュー・マネージャもアクセス可能である。キュー・マネージャのうちの１つ以上は、そのクラスタ中のキュー・マネージャについての情報のリポジトリ３０７をホストすることもできる。

任意のキュー・マネージャ３０１、３０２、３０３、３０４においてメッセージをクラスタ・キュー３０６上に置くために、アプリケーション３１１は、ＭＱＰＵＴコールを用いる。ローカル・キュー・マネージャ３０１上のクラスタ・キュー３０６からメッセージを取得するために、アプリケーション３１１は、ＭＱＧＥＴコールを用いる。

クラスタ３００に送られたメッセージは、作業負荷を均衡させる頒布キュー・マネージャ中の作業負荷マネージャにより、利用可能なキュー・マネージャ３０１、３０２、３０３、３０４中のクラスタ・キュー３０６のインスタンスの各々に分散される。

ＷｅｂＳｐｈｅｒｅ ＭＱ（ＩＢＭ社の登録商標）メッセージング・システムでは、すべてが到着するまでグループのメンバがまったく配信されないように、メッセージのグループを送ることができる。これは、すべてのメッセージが１つのクラスタ中の同じキュー・マネージャに送られることを必要とするグループの例である。そのグループ中のメッセージが異なるキュー・マネージャに送られる場合には、どのキュー・マネージャも、すべてのメッセージが到着したことを認識しないので、それらのメッセージは配信されない。ある特定のグループに属するメッセージが、そのクラスタ中の同じキュー・マネージャに対するアフィニティを有することを保証する必要がある。しかしながら、非グループ化メッセージは影響されてはならず、そのため１つのクラスタ中のキュー・マネージャの中で作業負荷バランスが保たれる。

グループ・メンバはそれ自体、２４バイトの汎用一意識別子（ＵＵＩＤ）として明示されるグループＩＤにより識別される。グループの各メンバは、一連番号も有しており、グループの最終メンバはそれ自身をそのようなものとして識別する。

説明された方法において、クラスタ中の配分キュー・マネージャにおける作業負荷マネージャは、メッセージがどのキュー・マネージャのクラスタ・キューに送られるかを決定するためにバランシング・アルゴリズムを実行する。バランシング・アルゴリズムは、１つのグループのメンバがそのクラスタ中の同じキュー・マネージャに確実に送られるようにすることによりグループ・メンバ・アフィニティを保つ。

バランシング・アルゴリズムは、標準整数を得るために、グループＩＤに対してハッシュ関数を実行する。標準整数の法は、キュー・マネージャの数で割って目標キュー・マネージャのインデックスを決定することにより得られる。

配分キュー・マネージャにグループ配分に関与するクラスタ・キューを知らせるために、構成ファイルまたは他の機構の形のリストが用いられる。このリストは、バランシング・アルゴリズムにおいて用いられる法を得るための除数を決定する。この除数は、キュー・マネージャの数であり、それゆえ、メッセージが送られ得るクラスタ・キューのインスタンスの数である。このリストは、クラスタに出入りするキューにかかわらず、変化せず、バランシング・アルゴリズムが正しいキューに一貫してアドレスできるようにする。

これにより、状態の保持または履歴をチェックするための大きいオーバヘッドを招くことなく、配分キュー・マネージャが、同じメッセージのグループのすべてのメンバを同じキュー・マネージャに送ることが可能になる。

キュー・マネージャのクラスタは、キュー・マネージャがいつでも参加または離脱できるように、動的である。除数がキュー・マネージャの現在の数に基づくものであったら、平衡アルゴリズムはエラーになる傾向があるであろう。従って、平衡アルゴリズムには、選ぶべきキュー・マネージャのリストが与えられ、このリストは、静的であり、キュー・マネージャの選択においてバランシング・アルゴリズムが一貫していられるようにする。

加えて、キュー・マネージャはドミノ式で倒れる。例えば、図３に示されるようにクラスタ中に４つのキュー・マネージャがあれば、これらのキュー・マネージャは、予め決められた順序：ＱＭ１、ＱＭ２、ＱＭ３、ＱＭ４を有する。１つのキュー・マネージャＱＭ１が機能しなくなれば、そのメッセージは作業負荷マネージャに送り返される。キュー・マネージャＱＭ１がバランシング・アルゴリズムにより選ばれて、しかも利用できなければ、並んでいる次のキュー・マネージャ、すなわちＱＭ２が選ばれる。

このドミノ・フェイルオーバ法は、すべての前に配信されたグループ・メンバを取得するためのプロセスと共に可能にされる。回復されたキュー・マネージャの再設定は同様な制御で行われる必要がある。

いったんあるキュー・マネージャが機能しなくなったと確認されると、そのキュー・マネージャは、別のキュー・マネージャ中で待機しているグループに属するどのようなメッセージもないことが保証されることなしには復旧され得ない。

また、あるキュー・マネージャが機能しなくなったと新たに検出されれば、メッセージは、そのキュー・マネージャが閉じられたこと、およびすでに配信されたメッセージが再配分されることを知らされるまで、通常のＷｅｂＳｐｈｅｒｅ ＭＱ（ＩＢＭ社の登録商標）システムのやり方での伝送のために格納されなければならない。

このように、機能しなくなったキュー・マネージャの作業負荷は、アフィニティを受け持ちかつ利用可能なリソース全体にわたりアフィニティを持たないメッセージを平衡させつつ、回復させ得る。

図３に示される例には、４つの利用可能なキュー・マネージャがある。キュー・マネージャ、従ってクラスタ・キューの利用可能なインスタンスのリストがインデックスとしてコンパイルされ、各キュー・マネージャは、以下のインデックス数を有する：
ＱＭ１＝０、
ＱＭ２＝１、
ＱＭ３＝２、
ＱＭ４＝３。

リスト中には４つのキュー・マネージャがあるので、平衡アルゴリズムにおいて使用するための除数は４である。これは、リストが改訂されて新しい除数が決定されるまで一定のままである。

この例において、グループ識別子を有するいくつかのメッセージのグループがある。グループ識別子は、例示の目的のため固有名詞として選ばれた。実際には、グループ識別子は、例えば、２４バイトＵＵＩＤの形のグループＩＤであり得る。

この例におけるハッシュ関数は、連続した数をアルファベットの文字に割り当て、これらの数を合算して標準整数を得る。

以下の表は、グループ名に対するハッシュ関数の演算を示す。

「ＨＡＭＰＳＨＩＲＥ」の識別子を有するグループのメンバについて平衡アルゴリズムによって得られるインデックス数は「１」である。従って、このグループのメンバはＱＭ２に送られる。以下の表は、各グループのメンバの宛先を示す。

このように、アフィニティを有するグループのメンバは、キュー・マネージャ全体にわたり作業負荷を平衡しつつ、同じキュー・マネージャに送られる。

本発明は一般に、コンピュータまたは同様なデバイスを制御するための１組のプログラム命令を含むコンピュータ・プログラム製品として実施される。これらの命令は、システムにあらかじめロードされたり、ＣＤ−ＲＯＭのような記憶媒体に記録されて供給されたり、あるいはインターネットのようなネットワークまたは移動電話網上でのダウンロードで利用可能にされ得る。

本発明の範囲を逸脱することなく、上記のことに対する改良および変更がなされ得る。

本発明による分散計算システムのブロック図である。 本発明による方法の流れ図である。 クラスタ化キュー・マネージャを有する本発明の実施形態によるメッセージング・システムのブロック図である。

Claims (18)

1. 分散コンピュータ・システム（１００）におけるアフィニティ管理のための方法であって、複数のアドレッシング・エンティティ（３１１−３１５）の各々についての識別子を提供するステップであって、アフィニティを有するアドレッシング・エンティティのグループの各メンバについての前記識別子は同じグループ識別子であるステップと、サービスのインスタンスを提供するために、アドレッシング・エンティティによりアドレスされるために利用可能なサービス・プロバイダ（３０１−３０４）の数を決定するステップと、標準整数を得るためにアドレッシング・エンティティの前記識別子にハッシュ関数を適用し（２０５）、前記標準整数をサービス・プロバイダの前記数で割って（２０６）法を得、前記法を参照してサービス・プロバイダを選び（２０７）、前記アドレッシング・エンティティを前記選ばれたサービス・プロバイダにより提供される前記サービスの前記インスタンスに送る（２０８）やり方によりサービス・プロバイダへのアドレッシング・エンティティの配分を管理するステップと、を含む方法。
2. サービス・プロバイダの前記数を決定する前記ステップは周期的に実行され、サービス・プロバイダの前記数は、ある期間内で一定である請求項１に記載の方法。
3. 前記方法は、法値により参照される前記利用可能なサービス・プロバイダのインデックスを提供するステップ（２０３）を含む請求項１または請求項２に記載の方法。
4. 選ばれたサービス・プロバイダが利用できなければ、前記アドレッシング・エンティティは、予め決められた順序で次のサービス・プロバイダに送られる請求項１〜３のいずれか１項に記載の方法。
5. あるサービス・プロバイダが機能しなくなれば、前に配信されたアドレッシング・エンティティを取得するためのプロセスが作動させられる先行請求項のいずれか１項に記載の方法。
6. あるサービス・プロバイダが機能しなくなれば、該サービス・プロバイダは、代わりのサービス・プロバイダ中にグループ・アフィニティを有するアドレッシング・エンティティまったくないことが保証された後に復旧され得る先行請求項のいずれか１項に記載の方法。
7. あるサービス・プロバイダが機能しなくなれば、該サービス・プロバイダに送られたアドレッシング・エンティティが再配分される先行請求項のいずれか１項に記載の方法。
8. 前記分散計算システムはメッセージング・システムであり、前記アドレッシング・エンティティはメッセージであり、前記サービス・プロバイダは、１つ以上のクラスタ・キューのインスタンスをホストするクラスタ化キュー・マネージャである先行請求項のいずれか１項に記載の方法。
9. 分散コンピュータ・システムにおけるアフィニティ管理のためのシステムであって、各々が識別子を有する複数のアドレッシング・エンティティ（３１１−３１５）であって、アフィニティを有するアドレッシング・エンティティのグループの各メンバについての識別子が同じグループ識別子である複数のアドレッシング・エンティティと、サービスのインスタンスを提供するために、アドレッシング・エンティティによりアドレスされるために利用可能な複数のサービス・プロバイダ（３０１−３０４）のリストと、標準整数を得るためにアドレッシング・エンティティの前記識別子にハッシュ関数を適用する（２０５）ステップ、前記標準整数を前記リスト中のサービス・プロバイダの前記数で割って（２０６）法を得るステップ、および前記法を参照してサービス・プロバイダを選ぶ（２０７）ステップを有するアルゴリズムを用いてサービス・プロバイダへのアドレッシング・エンティティの配分を管理するための手段と、前記選ばれたサービス・プロバイダにより提供される前記サービスの前記インスタンスに前記アドレッシング・エンティティを送る（２０８）ための手段と、を含むシステム。
10. サービス・プロバイダの前記リストは周期的に更新され、該リスト上のサービス・プロバイダの前記数は、ある期間内で一定である請求項９に記載のシステム。
11. 前記リスト中に示される前記サービス・プロバイダを作業負荷マネージャに知らせるための機構が提供される請求項９または請求項１０に記載のシステム。
12. 前記システムは、法値により参照される前記リスト中のサービス・プロバイダのインデックスを含む請求項９〜１１のいずれか１項に記載のシステム。
13. 選ばれたサービス・プロバイダが利用できなければ、作業負荷マネージャが前記アドレッシング・エンティティを予め決められた順序で前記次のサービス・プロバイダに送る請求項９〜１２のいずれか１項に記載のシステム。
14. あるサービス・プロバイダが機能しなくなれば、前に配信されたアドレッシング・エンティティを取得するための手段が提供される請求項９〜１３のいずれか１項に記載のシステム。
15. あるサービス・プロバイダが機能しなくなれば、該機能しなくなったサービス・プロバイダが復旧される前に、代わりのサービス・プロバイダ中にグループ・アフィニティを有するアドレッシング・エンティティがまったくないことを保証するための手段が提供される請求項９〜１４のいずれか１項に記載のシステム。
16. あるサービス・プロバイダが機能しなくなれば、前記サービス・プロバイダに送られたアドレッシング・エンティティを再配分するための手段が提供される請求項９〜１５のいずれか１項に記載のシステム。
17. 前記分散計算システムはメッセージング・システムであり、前記アドレッシング・エンティティはメッセージであり、前記サービス・プロバイダは、１つ以上のクラスタ・キューのインスタンスをホストするクラスタ化キュー・マネージャである請求項９〜１６のいずれか１項に記載のシステム。
18. デジタル・コンピュータの内部メモリにロード可能なコンピュータ・プログラム製品であって、該製品がコンピュータ上で走らされる時に、請求項１〜１０に記載の前記発明を実行するためのソフトウェア・コード部分を含むコンピュータ・プログラム製品。

Images