JP2023529462A - 分散ルーティングシステムにおける高可用性クラスタリーダ選出 - Google Patents

Abstract

分散ルーティングシステムが通信ネットワークにおける使用の為に提供され、前記分散ルーティングシステムが、少なくとも１つのクラスタを含み、前記少なくとも１つのクラスタが、第１の複数のクラスタ要素を含み、前記第１の複数のクラスタ要素の中から第２の複数のクラスタ要素が選択され、前記第２の複数のクラスタ要素に含まれる各クラスタ要素は、クラスタリーダ候補として動作するように構成され、前記第２の複数のクラスタ要素の１つが、一時的にクラスタリーダとして機能するように選択される。【選択図】 図４

Description

本開示は、包括的には、分散コンピューティングの分野に関し、特に分散ルータの動作に関する。

ＢＰＣＥ：バックプレーンクラスタ要素(Backplane Cluster Element)
ＣＥ：クラスタ要素(Cluster Element)
ＣＬ：クラスタリーダ(Cluster Leader)
ＣＬＣ：クラスタリーダ候補(Cluster Leader Candidate)
ＣＭ：クラスタマネージャ(Cluster Manager)
ＥＭ：要素マネージャ(Element Manager)
ＦＣＥ：転送クラスタ要素(Forwarding Cluster Element)
ＬＥ：リーダ選出(Leader Election)
コンテナ(Container)：コンテナは隔離された実行環境であり、独自のユーザ、ファイルシステム、プロセス、ライブラリ、コード、ネットワークスタック等を有する全機能設定として動作し、コンテナが実行されるシステムに関係なく、そのようなコンテナ内に含まれるソフトウェアから同一のビヘイビアを得られることを保証する。
データプレーン(Data Plane)：システムを通して一方のインタフェースから他方のインタフェースへのデータパケット／フレームの転送に関する全ての機能及びプロセスを含有する論理層。この定義は、物理ポートを介したルーティングと同様にすぐに到達できない物理ポートにデータパケットが到達することを可能にする中間バックプレーンポートを介したルーティングを含有するが、限定はされない。
制御プレーン(Control Plane)：データプレーンの管理等に使用する経路を決定する全ての機能及びプロセスに関する全てのアプリケーションを含有する論理層。この定義は、構成エンジン、ルーティングスタック、ルーティングプロトコル、スパニングツリー、Ｉｄｐ（ＩＤプロバイダ）、及びユーザ向けサービスを含有するが、限定はされない。

分散システムは、コンポーネントが異なるネットワークのコンピュータに配置されたシステムであり、互いにメッセージを送信することによりそれらの動作を通信して調整する。コンポーネントは、共通の目標を達成する為に、互いに相互作用する。分散システムの３つの重要な特徴は、コンポーネントの同時実行、グローバルクロックの欠如、及びコンポーネントの独立故障である。

分散システム内で実行されるコンピュータプログラムは、分散プログラムと呼ばれる（そして、分散プログラミングは、そのようなプログラムを書くプロセスである）。ｐｕｒｅＨＴＴＰ、ＲＰＣ状コネクタ及びメッセージキューを含むメッセージ受け渡しメカニズムの為の多くの異なる型の実装が存在する。

コンピュータクラスタは、一緒に動作する緩く又は密接に接続された１組のコンピュータであるから、多くの面において、単一のシステムとして見られる。グリッドコンピュータとは異なり、コンピュータクラスタはそれぞれ、ソフトウェアにより制御及びスケジュールされた同じタスクを実行するノードセットを有する。

クラスタのコンポーネントは通常、高速ローカルエリアネットワークを通して互いに接続され、（コンピュータがサーバとして使用されて）各ノードが、オペレーティングシステムの独自のインスタンスを実行する。ほとんどの状況で、全てのノードは、同じハードウェア及び同じオペレーティングシステムを使用するが、（例えば、オープンソースクラスタアプリケーションリソース(Open Source Cluster Application Resources)（ＯＳＣＡＲ）を使用する）いくつかのセットアップにおいて、各コンピュータに異なるオペレーティングシステムを使用してもよく、又は異なるハードウェアを使用してもよい。

クラスタは通常、単一のコンピュータよりも性能及び可用性を改善する為に展開され、通常、同様の速度又は可用性の単一のコンピュータに比べてかなり費用効率が良い。

しかしながら、クラスタコンピューティング技術は、いくつかの課題を提起する。これらの課題の内の２つが際立つものであり、第１の課題は、アプリケーションの複雑性であり、第２の課題は、クラスタ要素の同調性である。

アプリケーションの複雑性は、クラスタコンピューティングの分散型の性質に起因する。例えば、適用されるアーキテクチャは、進行中のタスクがネットワーク要素間で分割されている時にネットワーク要素をどのように使用するかの問題を解決することができるものでなければならず、同時に、顧客のアプリケーション側からは、単一の論理ユニットと通信しているように見えることを保証する。

一方で、要素の同調性は、システムの内部の一体性に関連する。要素間で共有される各データユニットは、クラスタにわたる動作の一貫性を保証する為に同期されなければならない。

クラスタコンピューティングアプリケーションのそのような実装は、これらの課題を解決する為に、いくつかの方法論を使用する。第１に、作業負荷管理が様々なクラスタ要素間の効果的な負荷バランス化を可能にするように構成されたシステムにおいて、アプリケーションの複雑性は、クラスタ要素が可能な限り独立したままであることを可能にすることにより減少される。第２に、要素の同調性論理を処理し、全てのクラスタ要素を管理する為に、特定の集中型エンティティを使用することができる。そのようなクラスタ管理エンティティは、クラスタにわたる情報の差別化を可能にし、そして、情報を要素のローカルデータの一部として保存することを可能にし、その後、クラスタ動作中にその情報を利用することを可能にする。

いかなる時点においても、クラスタ内に含まれるクラスタ要素の中から１つのクラスタマネージャのみが動作中である。なぜなら、複数の有効なクラスタマネージャは、外向きクラスタ動作における非一貫性を間違いなく引き起こすからである。この欠点を防止する為に、本発明は、クラスタ内に含まれる全てのクラスタ要素の中から単一のクラスタ要素を選択させるプロセスを使用してクラスタリーダが選出され、その後、クラスタリーダがそのクラスタのリーダ要素として動作する解決策を対象とする。その後、このリーダ要素が、有効なクラスタマネージャをホストし、クラスタを動作上関連させる為に必要な全ての他のリーダ要素機能を実行する。

そのクラスタがルータである場合、これらの問題は悪化する。異なるクラスタ要素は異なる責任を有するので、クラスタ要素は一緒に動作すると、完全なルータ機能を提供する。そのようなクラスタにおけるアプリケーションコンポーネントは、それぞれ適切なクラスタ要素内に存在するデータプレーン又は制御プレーンに属すると大まかに分類することができる。したがって、ルータは、それぞれデータプレーン又は制御プレーンの一部を形成する複数のクラスタ要素から構成される。図１は、この形式のクラスタ内のデータプレーンクラスタ要素を図示し、そして、それらのクラスタ要素がどのように隣接ルータに接続されているかを示している。そのようなクラスタにおいて、制御プレーンは、信頼できる唯一の情報源として機能するただ１つのクラスタ要素上で動作しなければならないので、このクラスタ要素が制御プレーンサービスの一部としてリードするクラスタマネージャをホストすることは自然なことである。

制御プレーンクラスタ要素の障害時に、クラスタを動作したままにする為に、クラスタリーダを置き換える適切な候補とみなされるクラスタ要素のいくらかの冗長性が必要である。これらのクラスタリーダ候補（ＣＬＣ）は、ルーティング機能を悪化させることなく、シームレスなフェイルオーバを可能にするように高度に同期されなければならない。障害のあるクラスタリーダ上で実行中のままの制御プレーンサービスがないことも必要である。しかしながら、このフェイルオーバは、クラスタリーダ候補間通信問題を引き起こすべきではなく、リーダ選出プロセスは、制御プレーンの移行インスタンスを最小化する為にレジリエントであるべきである。最後に、リーダ選出プロセスは、クラスタアプリケーションにおいてよくあるクラスタリーダ損失及びクラスタリーダ障害シナリオの両方を処理する必要がある。

Ｐａｘｏｓ又はＲａｆｔ等の一般的である決定性コンセンサス－アルゴリズムは、分散ルータアプリケーションにおいて制限を有する。そのような環境で複製状態マシンアプローチをとる場合、クラスタリーダ候補間の制御プレーンスタックの同期が必要である。ルータアプリケーションにおいて同期が必要であるデータの潜在的な量は、待機時間問題を引き起こし、クラスタリーダ候補の相互接続を飽和させる。さらに、クラスタリーダ候補の数が増加すると問題は悪化し、クラスタリーダ候補間通信オーバヘッドの二次増大をもたらす。ここでの他の限定は、共通のＰａｘｏｓ状実装とは異なり、全てのクラスタ要素の小さいサブセットであるクラスタリーダ候補のみがそのようなアプローチに参加し、これらの選択された少数のクラスタ要素に障害が発生した場合の不安定性のリスクを増加することに起因する。さらに、ほとんどのクラスタ要素がクラスタリーダ候補ではない場合、選出アルゴリズムがこの事実を活用して信頼性を増加する利点がある。最後に、単純に作用的観点から、Ｐａｘｏｓ状アプローチは、この特定の設計への全ての制御プレーンアプリケーションの特別な適合も必要とし、タスクは、主としてソフトウェア定義ソリューションにおいて独自の課題となりえる。

従来技術のアプローチの限界を鑑み、分散ルータシステムにおける高可用性クラスタリーダの適切な選択を保証する新たな解決策が必要である。

本開示は、添付の特許請求の範囲を参照することによって要約することができる。

本開示の目的は、分散ルータシステムにおける高可用性クラスタリーダの適切な選択を可能にする通信ネットワークにおける使用の為の新規の方法及びソフトウェアを提供することである。

本開示の他の目的は、分散ルータシステムにおける使用の為の新規の方法及びソフトウェアを提供することであり、分散ルータシステムは、クラスタリーダ候補（ＣＬＣ）上で実行されるクラスタマネージャ（ＣＭ）と、全てのクラスタ要素（ＣＥ）上で実行される要素マネージャ（ＥＭ）と、を含み、要素マネージャの信頼性が信頼できる高可用性リーダ選出（ＬＥ）を可能にし、同様に、分散ルータにおいて、外向けの動作に影響を与えることなく、制御プレーンサービスのシームレスな軽量の移行を可能にする。

本開示の他の目的は、以下の説明から明らかになる。

本発明の第１の実施形態によれば、通信ネットワークにおける使用の為の分散ルーティングシステムであって、前記分散ルーティングシステムが、少なくとも１つのクラスタを含み、前記少なくとも１つのクラスタが、第１の複数のクラスタ要素を含み、前記第１の複数のクラスタ要素の中から第２の複数のクラスタ要素が選択され（即ち、第２の複数のクラスタ要素は第１の複数のクラスタ要素のサブセットであり）、前記第２の複数のクラスタ要素に含まれる各クラスタ要素は、クラスタリーダ候補（ＣＬＣ）として動作するように構成され、前記第２の複数のクラスタ要素の１つが、一時的にクラスタリーダ（ＣＬ）として機能するように選択される分散ルーティングシステムが提供される。

本明細書及び特許請求の範囲で使用する「クラスタ」という用語は、一緒に動作する緩く又は密接に接続された１組のコンピューティングエンティティを示す為に使用され、それにより、多くの面において、クラスタは単一のシステムとして見られる。コンピュータクラスタはそれぞれ、ソフトウェアにより制御及びスケジュールされた同じタスクを実行するノードセットを有する。

本明細書及び特許請求の範囲で使用する「クラスタリーダ選出」という用語又はその変形は、複数の要素（ノード）間で分散されたいくつかのタスクのオーガナイザとして、同様のエンティティのクラスタに属する単一のエンティティ（又はプロセス）を指定する分散システムにおいて実行されるプロセスに関する。タスクが開始される前に、全てのネットワークノードはいずれもどのノードがタスクの「リーダ」（又はコーディネータ）として機能するか知らず、又は、現在のコーディネータと通信することができない。リーダ選出アルゴリズムが実行された後、ネットワーク中の各ノードが、特定の唯一のノードをタスクリーダとして認識する。

本明細書及び特許請求の範囲で使用する「クラスタリーダ候補」という用語は、リーダ選出（ＬＥ）ネゴシエーションプロセス中にクラスタマネージャソフトウェアを実行する物理ノードに関し、もしクラスタリーダとして動作すべきであるノードとして選択されたら、他の制御プレーンコンポーネントも動作させる。

本明細書及び特許請求の範囲で使用する「クラスタマネージャ」という用語は、クラスタリーダ候補上、即ち、リーダ選出（ＬＥ）プロセスに参加するクラスタ内の指定ノード上で実行されるプロセスに関する。

本明細書及び特許請求の範囲で使用する「クラスタリーダ」という用語は、「動作中の」クラスタマネージャだけでなく、制御プレーンスタックの残りも含む、選出されたクラスタリーダ候補ノードに関する。

現在選出されているクラスタリーダがいても、「動作中の」クラスタマネージャ（クラスタリーダ）を継続的に監視する為に、クラスタマネージャプロセスは他のクラスタリーダ候補上でまだ実行されるべきである。この方法により、これらの他のクラスタリーダ候補は、現在選出されているクラスタリーダに障害が発生した時に反応することができる。

他の実施形態によると、前記分散ルーティングシステムがさらに、前記少なくとも１つのクラスタ内のルーティング動作を管理するように構成された管理ソフトウェアを含み、前記管理ソフトウェアが、クラスタマネージャ及び異なるクラスタ要素のマネージャに記憶される複数のフラグメントに分割される。

さらに他の実施形態では、前記複数のフラグメントに属する各フラグメントが、各々の通信コンテナ内に含有される。

さらに他の実施形態によると、前記分散ルーティングシステムがさらに、１つ以上のクラスタ要素のマネージャ（好ましくは全てのオンラインのクラスタ要素のマネージャ）により提供されたレポートから情報を得るように構成された（例えば、クラスタリーダ候補（ＣＬＣ）に関連する）少なくとも１つのプロセッサを含み、前記情報が、前記１つ以上のクラスタ要素のマネージャのそれぞれから得られた情報に基づいて、前記クラスタリーダ候補として選択される資格のある前記第２の複数のクラスタ要素とどのクラスタ要素のマネージャが関連しているかに関するものである。

他の実施形態によると、前記レポートは、前記分散ルーティングシステムにおける変更の発生時に、及び／又は要求に応じて生成される。

さらに他の実施形態では、前記レポートは、クラスタマネージャに達する接続の論理状態に関するレポートと、前記クラスタマネージャへ前記接続に沿って送信されたメッセージの前記クラスタマネージャにより作成された確認応答に関するレポートと、の２つの別個の型の１つに属する。

他の実施形態によると、前記レポートが決定的でないと判断された場合、前記少なくとも１つのプロセッサはさらに、前記クラスタリーダが選択される期間内にメッセージの転送を開始し、１つ以上の中間クラスタ要素のマネージャにより前記メッセージの転送が実行され、前記メッセージのそれぞれが、前記メッセージを受信するクラスタマスタからのクラスタの可視性の情報を受信する為の要求に関連付けられる。

他の実施形態によると、前記少なくとも１つのプロセッサはさらに、前記クラスタリーダが選択される前記期間を複数のクエリ期間に分割するように構成され、前記複数のクエリ期間の長さが、前記クラスタリーダ候補の相互接続性能によって設定される。

さらに他の実施形態では、前記少なくとも１つのプロセッサはさらに、クエリ期間の終わりのクラスタ状態を受け入れるか、又は、前のクエリ期間中に受信した情報が不十分である場合に他のクエリ期間を開始するように構成される。

本開示の他の側面によると、通信ネットワーク内で動作する分散ルーティングシステムにおけるクラスタリーダとして機能するクラスタ要素を選択する方法であって、前記分散ルーティングシステムが、少なくとも１つのクラスタを含み、前記少なくとも１つのクラスタが、第１の複数のクラスタ要素を含み、前記第１の複数のクラスタ要素の中から第２の複数のクラスタ要素が選択され、前記方法が、
１つ以上のクラスタ要素のマネージャにより生成されたレポートから得られた情報を提供し、前記情報が、前記１つ以上のクラスタ要素のマネージャのそれぞれから得られた情報に基づいて、前記クラスタに属するどのクラスタ要素のマネージャがクラスタリーダ候補として選択される資格があるか（即ち、第２の複数のクラスタ要素に属する資格があるか）に関し、
クラスタリーダの選択が実行される期間内にメッセージを開始し、これらのメッセージのそれぞれは、前記メッセージのそれぞれを受信する全てのクラスタ要素のマネージャからのクラスタの可視性の情報を受信する為の要求に関連付けられ、
前記クラスタリーダとして機能するクラスタリーダ候補のそれぞれの適格性に関する前記メッセージに対して受信した応答に基づいて、これらのクラスタリーダ候補の中から前記クラスタリーダを選択する、ことを含む方法を提供する。

本開示のこの側面の他の実施形態によると、前記レポートは、前記分散ルーティングシステムにおける変更の発生時に、及び／又は要求に応じて生成される。

さらに他の実施形態では、前記レポートは、クラスタマネージャに達する接続の論理状態に属するレポートと、前記クラスタリーダへ前記接続に沿って送信されたメッセージの前記クラスタリーダによる確認応答に関するレポートと、の２つの別個の型の１つに属する。

さらに他の実施形態によると、前記レポートが決定的でない場合、前記方法がさらに、前記クラスタリーダが選択される期間内にメッセージを開始することを含み、１つ以上の中間クラスタ要素のマネージャにより前記メッセージの転送が実行され、前記メッセージのそれぞれが、前記メッセージを受信するクラスタマスタからのクラスタの可視性の情報を受信する為の要求に関連付けられる。

他の実施形態によると、前記方法がさらに、前記クラスタリーダが選択される前記期間を複数のクエリ期間に分割することを含み、前記複数のクエリ期間の長さが、前記クラスタリーダ候補の相互接続性能によって設定される。

さらに他の実施形態では、前記方法がさらに、クエリ期間の終わりのクラスタ状態を受け入れるか、又は、前のクエリ期間中に受信した情報が不十分である場合に他のクエリ期間を開始するかを決定することを含む。

本明細書に組み込まれ、本明細書の一部を構成する添付の図面は、本開示のいくつかの実施形態を示し、以下の説明と共に、本明細書に開示されるこれらの実施形態の原理を説明するために使用される。

分散ルータのトラフィック伝送相互接続を示す図である。 分散ルータの内部制御トラフィック伝送相互接続を示す図である。 本発明の実施形態による、様々な要素マスタ及びクラスタマネージャ並びにその接続性を含むシステムアーキテクチャを示す図である。 本開示による実施形態を実行する方法を例示する図である。

以下の詳細な説明における特定の詳細及び値の一部は、本開示の特定の例を示している。但し、この説明は、例示的なものであり、本発明の範囲を限定することを意図するものではない。特許請求される方法及び装置は、当該技術分野で公知の他の手法によって実現できることは、当業者にとって明らかである。更に、ここに記述した実施形態は、異なるステップを含むが、その全てが本発明の全ての実施形態において必要とされるわけではない。本発明の範囲は、添付の特許請求の範囲を参照することにより要約される。

本発明は、高可用性クラスタリーダを選択することを保証する新規の部分的同期アプローチを提供することを目的とし、それにより、通信要素のクラスタにより実行される必要がある動作を容易にすることができる。

本開示の基礎原理の１つは、制御プレーン管理プロトコルにおいて利用可能なタイムアウトの使用である。通常、時間制限は、ピアの状態に悪影響を及ぼすことなく、クラスタリーダ候補（ＣＬＣ）間の制御プレーンサービスの完全な分解及び起動を可能にするのに十分な程ゆるい。物理インタフェース上でネゴシエートされている待ち時間の少ないプロトコルは、クラスタマネージャ（ＣＭ）が選出されたクラスタリーダ（ＣＬ）で動作可能になるまで、転送クラスタ要素（ＦＣＥ）により処理されることが好ましい。その結果、顧客向けビヘイビアが、新しいクラスタリーダへの制御プレーンサービスの移行による影響を受けないままになる。

不参加のクラスタ要素に依存することにより、本開示の提案されている解決策は、ビザンチン障害に対してレジリエントになることを意図する。クラスタ要素が特定のクラスタリーダ候補が利用不可能なクラスタリーダ候補であると誤ってレポートしても、他のクラスタリーダ候補は、他のクラスタ要素のレポートに依存して誤ったレポートを回避することができる。一方、クラスタ要素が利用不可なクラスタリーダ候補であると誤ってレポートした場合、クラスタリーダ候補がそのクラスタリーダ候補を通して通信を試みることによりレポートされたクラスタリーダ候補の本当の状態を知ることができる。

小さいサイズの低頻度メッセージの使用を通して、提案されている解決策は、低い相互接続オーバヘッドを課すことを目的とする。上述の寛容なタイムアウトが、大量データ記憶同期の必要性を回避し、それにより、低オーバヘッドのクラスタリーダ候補間通信プロトコルを容易にする。

最後に、クラスタマネージャ及び要素ローカルアプリケーションマネージャ間でリーダ選出（ＬＥ）論理を分割することにより、リーダ選出論理に影響を与えることなく、マイクロサービスを追加及び除去することができる。適切なコンテナ内にそれぞれが含有された要素マネージャ及びクラスタマネージャ間の論理ソフトウェアの分割は、ビザンチン障害の回避を保証し、同時に、クラスタリーダサービス及びリーダ選出論理の分離を保証する。

図２には、そのような相互接続の信頼性を提供するクラスタ要素のメッシュ接続の例が示されている。

スイッチ要素の冗長性を有することにより、個別のスイッチ障害の間も相互接続の可用性が維持される。さらに、これらのスイッチ要素にクエリを行うことにより、リンク層探索プロトコル(Link Layer Discovery Protocol)（ＬＬＤＰ）の隣接性に依存する可視性レポートを生成することができる。

クラスタマネージャが選出されたクラスタリーダ（ＣＬ）のＩＤをネゴシエートする為にクラスタリーダ候補上で特に動作している間、クラスタマネージャはその為に、全てのクラスタ要素上で動作しているクラスタ要素のマネージャを使用する。その後、リーダ選出プロセスはこの点において構成に依存しないので、制御プレーンスタック等のアプリケーション層の構成を自由に変更することができる。

図３は、要素マネージャ及びクラスタマネージャの関係の性質をさらに明確にする為に使用されている。図３には、これらのエンティティの位置及び関係が示されており、クラスタ要素上の他のアプリケーションと一緒に実行することを可能にする為にコンテナ化された環境を強調している。

図４は、本開示の実施形態による通信ネットワーク内で動作する分散ルーティングシステムにおけるクラスタリーダとして機能するクラスタリーダ候補を選択する方法を例示している。

まず、１つ以上のクラスタ要素のマネージャにより生成されたレポートから得られた情報を提供する（ステップ４１０）。この情報は、どのクラスタリーダ候補、即ちどのクラスタマネージャがレポートした要素マネージャに接続されているか、又は、どのクラスタマネージャが各要素マネージャから「可視」であるか、特定のクラスタリーダ候補－要素マネージャがクラスタリーダになる資格があるかどうか、そして、既知であればクラスタリーダのＩＤに関する。クラスタマネージャ（ＣＭ）への要素マネージャ（ＥＭ）によるこれらのレポートのプロビジョニングは、クラスタ要素における特定の変更の発生時に、又は要求に応じて作用されることが好ましい。したがって、クラスタ要素のクラスタマネージャの可視性は常に最新である。

本開示の実施形態によると、可視性レポートを提供する要求は、２つの異なる型、即ち論理要求及び即時要求に分類できる。前者の要求は、クラスタマネージャへの接続の論理状態に依存し、後者の要求は、特定の接続に沿って送信された要求であり、これらの要求に基づいて生成されたレポートは、目標のクラスタマネージャが各メッセージの受信を確認したかどうかである。

次のステップは、クラスタリーダの選択が実行される期間内にメッセージを開始する（ステップ４２０）ことに関する。これらのメッセージのそれぞれは、各メッセージを受信したクラスタリーダ候補からのクラスタの可視性の情報を受信する為の要求に関連付けられる。受信したレポートが決定的でない場合、リーダ選出中にクラスタリーダ候補間のタリー要求を使用することができる。ここで使用される「タリー」という用語は、何かを継続的にカウントすることに関し、この場合、特定のクラスタマネージャが現在動作中であると確認することができた要素マネージャの数であり、そして、代理でクラスタリーダ候補をクラスタリーダ（ＣＬ）にする。

メッセージは中間要素マネージャを通して検出されたそれぞれのクラスタマネージャに送信され、クラスタマネージャの応答に対して他のクラスタ要素の要求が事前になされていない場合、クラスタリーダのＩＤの為の要素マネージャの投票のタリーを含むクラスタの可視性を要求する。

リーダ選出（ＬＥ）期間は、好ましくは複数のクエリ期間に分割され、複数のクエリ期間の長さが、クラスタリーダ候補の相互接続性能によって設定され、そして、論理又は即時の可視性クエリのタイムアウトとして機能する制御プレーンのルーティングプロトコル耐性に対して、最後に、クラスタ状態が認証されるか、拒絶される。後者の場合、タリーが発行され、又は、受信した情報が不十分である場合に他のクエリ期間が開始される。

最後に、クラスタリーダとして機能するクラスタリーダ候補のそれぞれの適格性に関するこれらのメッセージに対して受信した応答に基づいて、これらのクラスタリーダ候補の中からクラスタリーダを選択する（ステップ４３０）。クラスタ要素がアプローチしたクラスタマネージャのほとんどからタリー応答を受信した場合にタリーが完了し、その後、全ての到達可能な要素マネージャと共に新しいリーダのＩＤが知らされる。単一のクラスタリーダ候補が他の全てのクラスタリーダ候補よりも多い数のタリー応答を受信するべきではなく、タリー終了が要求されたクラスタマネージャに送信されてクラスタマネージャを新たなタリー要求から解放し、新たなタリーを開始する試みの前にランダムなタイムアウトが課される。任意で、２つ（以上）のクラスタリーダ候補間で同点である場合を解決する為に事前に決定された基準を選択することもできる。例えば、そのような同点の場合、同数のタリー応答を受信した２つ（以上）のクラスタリーダ候補間でより低いＩＤナンバーを有するノードであるクラスタリーダ候補が選択される。

ここで使用されている「ＩＤナンバー」という用語は、クラスタ内に含まれているノードは、レポートを作成しているレポータと可視性レポートを互いに関連付けする為に、本開示のコンテキストで使用される、何らかのＩＤを有する必要があることに関する。しかし、上述のように、クラスタリーダになる為に２つ以上のクラスタリーダ候補により受信された投票が同数である場合にタイブレーカとして使用することもできる。通常、比較可能でありユニークであること以外は識別子の要件はない。

本発明は、単なる例として提供され、本発明の範囲を限定することを意図していない実施形態の詳細な説明を使用して、説明されている。記載されている実施形態は異なる構成を含み、全ての構成が本発明の全ての実施形態において必要であるわけではない。本発明のいくつかの実施形態は、いくつかの構成のみ、又は構成の可能な組み合わせを使用するものである。記載されている本発明の実施形態の変形、及び記載の実施形態に示されている構成の異なる組み合わせを含む本発明の実施形態は、当業者には自明である。本発明の範囲は、以下の特許請求の範囲によってのみ限定されるものである。

Claims (15)

1. 通信ネットワークにおける使用の為の分散ルーティングシステムであって、前記分散ルーティングシステムが、少なくとも１つのクラスタを含み、前記少なくとも１つのクラスタが、第１の複数のクラスタ要素を含み、前記第１の複数のクラスタ要素の中から第２の複数のクラスタ要素が選択され、前記第２の複数のクラスタ要素に含まれる各クラスタ要素は、クラスタリーダ候補として動作するように構成され、前記第２の複数のクラスタ要素の１つが、一時的にクラスタリーダとして機能するように選択されることを特徴とする分散ルーティングシステム。
2. さらに、前記少なくとも１つのクラスタ内のルーティング動作を管理するように構成された管理ソフトウェアを含み、前記管理ソフトウェアが、クラスタマネージャ及び異なるクラスタ要素のマネージャに記憶される複数のフラグメントに分割されることを特徴とする請求項１に記載の分散ルーティングシステム。
3. 前記複数のフラグメントに属する各フラグメントが、各々の通信コンテナ内に含有されることを特徴とする請求項２に記載の分散ルーティングシステム。
4. さらに、１つ以上のクラスタ要素のマネージャにより提供されたレポートから情報を得るように構成された少なくとも１つのプロセッサを含み、前記情報が、前記１つ以上のクラスタ要素のマネージャのそれぞれから得られた情報に基づいて、前記クラスタリーダ候補として選択される資格のある前記第２の複数のクラスタ要素とどのクラスタ要素のマネージャが関連しているかに関することを特徴とする請求項１に記載の分散ルーティングシステム。
5. 前記レポートは、前記分散ルーティングシステムにおける変更の発生時に、及び／又は要求に応じて生成されることを特徴とする請求項４に記載の分散ルーティングシステム。
6. 前記レポートは、クラスタマネージャに達する接続の論理状態に関するレポートと、前記クラスタリーダへ前記接続に沿って送信されたメッセージの前記クラスタリーダにより作成された確認応答に関するレポートと、の２つの別個の型の１つに属することを特徴とする請求項４に記載の分散ルーティングシステム。
7. 前記レポートが決定的でない場合、前記少なくとも１つのプロセッサはさらに、前記クラスタリーダが選択される期間内にメッセージの転送を開始し、１つ以上の中間クラスタ要素のマネージャにより前記メッセージの転送が実行され、前記メッセージのそれぞれが、前記メッセージのそれぞれを受信するクラスタマネージャからのクラスタの可視性の情報を受信する為の要求に関連付けられることを特徴とする請求項４に記載の分散ルーティングシステム。
8. 前記少なくとも１つのプロセッサはさらに、前記クラスタリーダが選択される前記期間を複数のクエリ期間に分割するように構成され、前記複数のクエリ期間の長さが、前記クラスタリーダ候補の相互接続性能によって設定されることを特徴とする請求項７に記載の分散ルーティングシステム。
9. 前記少なくとも１つのプロセッサはさらに、クエリ期間の終わりのクラスタ状態を受け入れるか、又は、前のクエリ期間中に受信した情報が不十分である場合に他のクエリ期間を開始するように構成されることを特徴とする請求項８に記載の分散ルーティングシステム。
10. 通信ネットワーク内で動作する分散ルーティングシステムにおけるクラスタリーダとして機能するクラスタ要素を選択する方法であって、前記分散ルーティングシステムが、少なくとも１つのクラスタを含み、前記少なくとも１つのクラスタが、第１の複数のクラスタ要素を含み、前記第１の複数のクラスタ要素の中から第２の複数のクラスタ要素が選択され、前記方法が、
    １つ以上のクラスタ要素のマネージャにより生成されたレポートから得られた情報を提供し、前記情報が、前記１つ以上のクラスタ要素のマネージャのそれぞれから得られた情報に基づいて、前記クラスタに属するどのクラスタ要素のマネージャがクラスタリーダ候補として選択される資格があるかに関し、
    クラスタリーダの選択が実行される期間内にメッセージを開始し、これらのメッセージのそれぞれは、前記メッセージのそれぞれを受信する全てのクラスタ要素のマネージャからのクラスタの可視性の情報を受信する為の要求に関連付けられ、
    前記クラスタリーダとして機能する前記クラスタリーダ候補のそれぞれの適格性に関する前記メッセージに対して受信した応答に基づいて、これらのクラスタリーダ候補の中から前記クラスタリーダを選択する、
    ことを含むことを特徴とする方法。
11. 前記レポートは、前記分散ルーティングシステムにおける変更の発生時に、及び／又は要求に応じて生成されることを特徴とする請求項１０に記載の方法。
12. 前記レポートは、クラスタマネージャに達する接続の論理状態に関するレポートと、前記クラスタリーダへ前記接続に沿って送信されたメッセージの前記クラスタリーダにより作成された確認応答に関するレポートと、の２つの別個の型の１つに属することを特徴とする請求項１０に記載の方法。
13. 前記レポートが決定的でない場合、前記方法がさらに、前記クラスタリーダが選択される期間内にメッセージの転送を開始することを含み、１つ以上の中間クラスタ要素のマネージャにより前記メッセージの転送が実行され、前記メッセージのそれぞれが、前記メッセージを受信するクラスタマネージャからのクラスタの可視性の情報を受信する為の要求に関連付けられることを特徴とする請求項１０に記載の方法。
14. 前記方法がさらに、前記クラスタリーダが選択される前記期間を複数のクエリ期間に分割することを含み、前記複数のクエリ期間の長さが、前記クラスタリーダ候補の相互接続性能によって設定されることを特徴とする請求項１０に記載の方法。
15. 前記方法がさらに、クエリ期間の終わりのクラスタ状態を受け入れるか、又は、前のクエリ期間中に受信した情報が不十分である場合に他のクエリ期間を開始するかを決定することを含むことを特徴とする請求項１０に記載の方法。

Images