JP6644902B2 - ハイパースケール環境における近隣監視 - Google Patents

Description

本開示の実施形態は、一般的には、ノードのネットワークを監視するためのシステムおよび方法に関する。

故障したことによる問題、または、それ以外では無応答のノードによる問題を直ちに検出できるように、そのノードおよび接続の状態を管理するために、種々のネットワーク監視技術がネットワークに対して開発されている。一般的な監視方法は、ノードが、プローブまたはハートビートを、ネットワークにおける他のノードに送信することである。ノード間において能動的に監視されるリンクの数、および、それにより管理されるトラフィックの量は、ノードの数が増加するに従い、増加する。

いくつかの従来のシステムでは、全てのノードが能動的に全ての他のノードを監視するフルメッシュ監視パターンが用いられている。例えば、透過性プロセス間通信（Transparent Inter-Process Communication（ＴＩＰＣ））プロトコルのリンクが、どこでも可能なフルメッシュパターンにおいてブロードキャストベースの近隣ディスカバリプロトコルを介して確立される。これらのシステムでは、リンク上にトラフィックがないとすぐに能動的になるハートビートまたはプロービングプロトコルを用いて、リンクは個別に管理される。

フルメッシュパターンに対するリンクの数、およびそれによる管理トラフィックの量は、Ｎ×（Ｎ−１）のレートにおいてノードの数とともに増加する。ここで、Ｎは、（クラスタサイズとも称される）ネットワークにおけるノードの総数である。フルメッシュの監視方式は、数十のノードの従来のクラスタサイズでは良好に機能する。しかしながら、フルメッシュ監視方式により生じるバックグラウンド監視の負荷は、クラスタサイズが数百または数千のノードに達すると、許容できなくなる。バックグラウンド監視の負荷を削減するための１つの解決策は、リンク耐性を増すこと、すなわち、ハートビート周波数を減らすことである。しかしながら、ハートビート周波数を減らすことは、リンクまたはピアノードの不具合を、不具合イベントの１．５秒内で検出し報告すると期待されているＴＩＰＣの動作を非常に劣化させる。

別の従来の監視方式は、ノードをリングパターンに配置し、各ノードが、それ自身がリングにいる前および後に、２つの隣接ノードを監視することである。リングネットワークにおいて監視するトラフィックは、クラスタサイズＮとともに線形に増加する。しかしながら、ネットワークが２等分に分割されていて１つの区分に不具合があれば、リング監視方式は、分割の境界におけるノードの不具合を検出することはできるが、区分の内側のノードにはできない。いくつかの他の現存の監視方式が存在するが、それぞれは固有の欠点を有する。

したがって、検出時間に関して期待されるリンク管理動作と、管理により生じる許容可能なバックグランド負荷とを組み合わせたノード監視方式に対する解決策が必要となる。

１つの実施形態では、Ｎノード（Ｎ個のノード）のネットワークを監視するための方法が提供される。方法は、Ｎノードの各ノードにより実行される。方法は、Ｎノードをソートされた順序にしたがって複数のドメインに分割することであって、当該ドメインは、ノードが位置するローカルドメインと１つ以上の遠隔ドメインを含み、各遠隔ドメインは遠隔ドメインにおけるメンバーノードを監視するために指定されたドメインヘッドを有する、ことと、ローカルドメインにおける全ての他のメンバーノードと、遠隔ドメインにおけるドメインヘッドを含む、能動的に監視されているノードに、所与の周波数においてプローブを送信することと、当該プローブに応答して、能動的に監視されているノードから受信した応答に基づいて、能動的に監視されているノードのそれぞれがアップ状態かを判定すること、を含む。

別の実施形態では、Ｎノードのネットワークにおけるノードであって、Ｎノードと協調してＮノードを監視するように構成されたノードが提供される。ノードは、ノードに対して、Ｎノードをソートされた順序にしたがって複数のドメインに分割させ、ここで、当該ドメインは、ノードが位置するローカルドメインと１つ以上の遠隔ドメインを含み、各遠隔ドメインは遠隔ドメインにおけるメンバーノードを監視するために指定されたドメインヘッドを有し、ローカルドメインにおける全ての他のメンバーノードと、遠隔ドメインにおけるドメインヘッドを含む、能動的に監視されているノードに、所与の周波数においてプローブを送信させ、当該プローブに応答して、能動的に監視されているノードから受信した応答に基づいて、能動的に監視されているノードのそれぞれがアップ状態かを判定させるように構成された回路を有する。

更に別の実施形態では、Ｎノードのネットワークにおけるノードであって、Ｎノードと協調してＮノードを監視するように構成されたノードが提供される。ノードは、Ｎノードをソートされた順序にしたがって複数のドメインに分割するように構成された分割モジュールであって、当該ドメインは、ノードが位置するローカルドメインと１つ以上の遠隔ドメインを含み、各遠隔ドメインは遠隔ドメインにおけるメンバーノードを監視するために指定されたドメインヘッドを有する、モジュールと、ローカルドメインにおける全ての他のメンバーノードと、遠隔ドメインにおけるドメインヘッドを含む、能動的に監視されているノードに、所与の周波数においてプローブを送信するように構成されたプローブモジュールと、当該プローブに応答して、能動的に監視されているノードから受信した応答に基づいて、能動的に監視されているノードのそれぞれがアップ状態かを判定するように構成された判定モジュールとを有する。

別の実施形態では、Ｎノードのネットワークを監視するための方法が提供される。方法は、ノードインスタンスを実行するための処理回路およびメモリを提供するクラウドコンピューティング環境において、ノードインスタンスのインスタンス化を開始することを含む。ノードインスタンスは、Ｎノードをソートされた順序にしたがって複数のドメインに分割し、ここで当該ドメインは、ノードが位置するローカルドメインと１つ以上の遠隔ドメインを含み、各遠隔ドメインは遠隔ドメインにおけるメンバーノードを監視するために指定されたドメインヘッドを有し、ローカルドメインにおける全ての他のメンバーノードと、遠隔ドメインにおけるドメインヘッドを含む、能動的に監視されているノードに、所与の周波数においてプローブを送信し、当該プローブに応答して、能動的に監視されているノードから受信した応答に基づいて、能動的に監視されているノードのそれぞれがアップ状態かを判定するように動作する。

他の観点および特徴は、当業者が添付の図面と関連した特定の実施形態の以下の説明を検討することで、明らかになるだろう。

添付の図面を参照して、例示のみの目的で実施形態を説明する。
図１Ａは、１つの実施形態に従う３つの異なるノードの例示的なネットワークビューを示す。 図１Ｂは、１つの実施形態に従う３つの異なるノードの例示的なネットワークビューを示す。 図１Ｃは、１つの実施形態に従う３つの異なるノードの例示的なネットワークビューを示す。 図２Ａは、１つの実施形態に従うドメイン記録の例を示す。 図２Ｂは、１つの実施形態に従う強化型のドメイン記録の例を示す。 図３は、１つの実施形態に従う、１つのネットワークにおけるノードを複数のドメインに分割するための方法を示すフロー図である。 図４Ａは、１つの実施形態に従う、２つのノードが異なるネットワークビューを有する例を示す。 図４Ｂは、１つの実施形態に従う、２つのノードが異なるネットワークビューを有する例を示す。 図５Ａは、１つの実施形態に従う、新しいノードがネットワークに追加されるシナリオを示す。 図５Ｂは、１つの実施形態に従う例示的なドメインイベントを示す。 図５Ｃは、１つの実施形態に従うドメインイベントの応答を示す。 図６Ａは、１つの実施形態に従う、ノードが２つのセットのプローブを送信する例を示す。 図６Ｂは、１つの実施形態に従う、ノードが２つのセットのプローブを送信する例を示す。 図６Ｃは、１つの実施形態に従う、ノードが２つのセットのプローブを送信する例を示す。 図６Ｄは、１つの実施形態に従う、ノードが２つのセットのプローブを送信する例を示す。 図７は、１つの実施形態に従う、１２ノードのネットワークにおける能動的に監視されるリンクを示す。 図８は、１つの実施形態に従う、３レベルのハイパースケール監視方式を示す。 図９は、１つの実施形態に従う、フルメッシュの監視、２レベルの監視および３レベルの監視を比較した表である。 図１０は、１つの実施形態に従う、Ｎノードのネットワークを監視するための方法を示すフロー図である。 図１１Ａは、１つの実施形態に従うネットワークノードのブロック図である。 図１１Ｂは、１つの実施形態に従う別のネットワークノードのブロック図である。 図１２は、１つの実施形態に従うクラウドコンピューティング環境の構造上の概観である。

以下、添付の図面に基づいて番号を付けた特定の要素を参照することができる。以下の議論は、本質的に例示的であるとみなされるべきであり、当業者が理解するように、要素を同等の機能要素で置き換えることによって変更することができる、以下に記載される実施の詳細によって限定されると見なされるべきではない。

ハイパースケール方式に従ってネットワーク内のノードを監視するためのシステム、装置、および方法がここに提供される。ハイパースケール方式は、高速の検出時間と、管理によって生じる許容可能なバックグラウンド負荷とを組み合わせる。つまり、クラスタのサイズが大きくなるとバックグラウンドの負荷が適度に大きくなる。ネットワークにおける各ノードに対して、すべてのノードが他の全てのノードに接続される可能性があるため、他の全てのノードは隣接ノードである。しかしながら、これらの接続の全てが、ハイパースケール方式に従って能動的に監視されるわけではない。ここで使用される「ノード」の用語は、物理的なノードまたは仮想的なノードであり得る。複数の仮想的なノードは、同じ物理的なホスト上に配置され得る。１つの実施形態では、ネットワークにおける各ノードは、そのネットワークビューにおける全てのノードを、ネットワークにおける全ての他のノードと同じソーティングアルゴリズムを用いて、順序付けリストにソートする。ソートされた順序に従い、各ノードは、管理のためにノードを複数のドメインに分割する。管理は階層的であり、各ノードは能動的にそれ自身のドメイン（ローカルドメイン）を監視し、遠隔ドメインを監視するために、いくつかのドメインヘッドを指定する。なお、「ローカル」および「遠隔」という用語は、ノード間のソートされたリストにおける論知的な距離を示し、ノード間の物理的な距離を示すものではない。各ノードは、そのローカルドメインにおけるメンバーノードのドメイン記録を維持する。ドメイン記録は、ローカルドメインにおけるメンバーノードの識別情報に関して、より具体的には、これらのメンバーノードの総数および識別情報（例えばアドレス）に関して、そのローカルドメインについてのノードの知識を記録する。１つの実施形態では、各ノードは、プローブまたはハートビートをこれらのノードに送信することにより、そのローカルドメインメンバーとドメインヘッドを能動的に監視する。各ノードに対して、そのノードのために「能動的に監視される（されている）ノード」という用語は、ノードのローカルドメインにおける他の全てのメンバーノード、およびそのノードによって監視されているノードの遠隔ドメインにおけるノードによって指定されたドメインヘッドを示す。プローブに対する応答は、プローブ受信側がアップ状態（動作中）であることを示し、そうでない場合、プローブ受信側はダウン状態（すなわち、非動作中）であることを示す。

ハイパースケール方式によれば、各ノードは、それ自身のネットワークビューを維持し、すなわち、ネットワークにおけるノードの総数およびネットワークにおけるノードの識別情報（例えばアドレス）に関してネットワークについてのその知識を維持する。ネットワークにおけるノードのネットワークビューは調整されないことから、異なるノードは、異なるネットワークビューを維持する。

図１Ａ〜図１Ｃは、１つの実施形態に従う、ハイパースケールドメイン監視方式の例を示す。図１Ａは、ノード１のネットワークビューを示す。ノード１のネットワークビューにおいて全ノード数Ｎ＝１２が存在する。ノード１は、順序付けリストに１２ノードをソートする。例えば、１２ノードは、順序付けリスト内の１番のノードであるノード１から昇順にソートされる。１２ノードの全ては、ノードの同じ表現セット（例えば、数値表現）上で同じソーティングアルゴリズムを使用してソート動作を実行する。ネットワークにおける任意のノードに対する数値表現は、ノードの数値識別子（ネットワークアドレス等）、当該数値識別子のハッシュ値、または当該数値識別子のマッピングされた値であり得る。いくつかの実施形態では、ソーティングは、ノードの英数字表現または非数値表現上で実行され得る。ハッシュ値またはマッピングされた値がソーティングに対して使用される場合、全てのノードは、同じハッシュアルゴリズムまたは同じマッピング関数（機能）を使用する。ソーティングの後、順序付きリストは更に、円形リストに配置され、順序付きリスト内の最後のノードは、順序付けリスト内の最初のノードの直前に順序付けされる。１２ノードはそして、ローカルドメインと１つ以上の遠隔ドメインを含む、いくつかのドメインに分割される。

１つの実施形態では、ノード１は、予め定義された式、例えば、（^２√Ｎ）の上限（ceil（天井（関数）））に従って、ＮからローカルドメインのサイズＭを計算する。代わりの実施形態では、ドメインサイズＭは、別の式により構成または計算され得る。ネットワークにおける全てのノードは、同じ式を用いてドメインサイズを計算する。

Ｎ＝１２の例では、Ｍ＝ceil（^２√Ｎ）＝４となる。したがって、ノード１に対するローカルドメインサイズは４となる。ローカルドメインの外にあるノードは、１つ以上の遠隔ドメインを形成する。図１Ａの例において、ノード１のローカルドメイン（Ｄ_１）は、ノード１、ノード２、ノード３、およびノード４を含み、これらは、ローカルドメインＤ_１のメンバーノードと称される。遠隔ドメイン（Ｄ_２）は、ノード５、ノード６、ノード７およびノード８を含み、遠隔ドメイン（Ｄ_３）は、ノード９、ノード１０、ノード１１およびノード１２を含む。各遠隔ドメインにおける１つのノードは、ドメインヘッド、例えばそのドメインの第１のノードとして指定される。図１Ａの例では、ノード５はＤ_２のドメインヘッドであり、ノード９はＤ_３のドメインヘッドである。ノード１は、ドメインヘッドに依存し、遠隔ドメインにおけるノードを監視する。したがって、各ノードがＮノードのサブセットを能動的に監視するのみであるが、Ｎノードは協調して全てのＮノードを監視する。ドメインの構造についての詳細は、図３を参照して後述する。

図１Ａにおいて矢印で示すように、ノード１は、ドメインヘッド（例えばノード５およびノード９）、並びに、そのローカルドメインにおける他のメンバーノード（例えばノード２、ノード３およびノード４）を監視する。ノード１により能動的に監視されているノードは、予め決定された周波数において、ノード１からプローブを受信する。予め決定された周波数またはその逆数（プローブ間隔と呼ばれる）は、設定可能な値であってもよい。例えば、プローブ間隔は、数秒、数ミリ秒、またはマイクロ秒であり得る（３７５ミリ秒等）。能動的に監視されているノードがプローブに応答した場合、応答は、能動的に監視されているノードはアップ状態であることを確認する。ノード１が能動的に監視されているノードから応答を受信しなかった場合、それは、能動的に監視されているノードがダウン状態であることをノード１に示す。図１Ａの点線矢印により示されるように、遠隔ドメインにおけるドメインヘッドにより監視されているノードは、それらのドメインヘッドからプローブを受信する。

ネットワークにおける各ノードは、ノード１と同じ監視動作を実行する。図１Ｂは、ノード１と同じソーティングアルゴリズムを実行することにより１２ノードを順序付けリストにソートするノード２のネットワークビューを示す。ノード２はまた、ローカルドメインのサイズＭを計算し、Ｍに従ってローカルドメインを形成し、その後、残りのノードを遠隔ノードに分割する。図１Ｂは、ノード２の遠隔ドメイン（Ｄ_１）がノード２、ノード３、ノード４、およびノード５を含み、遠隔ドメイン（Ｄ_２）がノード６、ノード７、ノード８、およびノード９を含み、別の遠隔ドメイン（Ｄ_３）がノード１０、ノード１１、ノード１２およびノード１を含むことを表している。各遠隔ドメインにおける１つのノードは、ドメインヘッドとして指定される。図１Ｂの例では、ノード６はＤ_２のドメインヘッドであり、ノード１０はＤ_３のドメインヘッドである。ノード２は、ドメインヘッドに依存し、遠隔ドメインにおけるノードを監視する。ノード１と同様に、ノード２は、ドメインヘッド（例えばノード６およびノード１０）、並びに、そのローカルドメインにおける他のメンバーノード（例えばノード３、ノード４、およびノード５）を監視する。これらのノードにプローブを送信することにより、ノード２は、これらのノードのそれぞれがアップ状態かダウン状態かを判定することができる。

図１Ｃは、ノード１とノード２と同じ、ソーティング、ドメインサイズの決定、ドメイン分割およびドメインヘッドの指定を行うノード３のネットワークビューを示す。ノード３に対する３つのドメインは、ノード３、ノード４、ノード５およびノード６を含むローカルドメイン（Ｄ_１）、ドメインヘッドであるノード７と、ノード８、ノード９およびノード１０を含む遠隔ドメイン（Ｄ_２）、ドメインヘッドであるノード１１と、ノード１２、ノード１、およびノード２を含む別の遠隔ドメイン（Ｄ_３）を含む。ノード３は、ドメインヘッドに依存し、遠隔ドメインにおけるノードを監視する。ノード１およびノード２と同様、ノード３は、両方のドメインヘッド（例えばノード７およびノード１１）、並びに、そのローカルドメインにおける他のメンバーノード（例えばノード４、ノード５およびノード６）を監視する。これらのノードへプローブを送信することにより、ノード３は、これらのノードのそれぞれがアップ状態かダウン状態かを判定することができる。

したがって、ネットワークにおける各ノードは、ローカルドメインと１つ以上の遠隔ドメインを有する。各ノードは、いくつかの他のノードによりドメインヘッドとして指定されるが、どのノードがドメインヘッドとして指定されているかを知らないし、知る必要はない。

図１Ａから１Ｃの例では、ＮはＭで割ることが可能であるが、一般的に、Ｎは、Ｍで割ることが可能であることが必須ではない、あらゆる整数とすることができる。ローカルドメインは、Ｍノードを含む。しかしながら、遠隔ドメインは、あらゆる数のノードを有し得る。それは、Ｍより小さく、Ｍより大きい可能性がある。詳細は、図３を参照して説明する。

図２Ａは、１つの実施形態に従うドメイン記録２１０の例を示す。この例では、ネットワークにおける全てのノードは、Ｎ＝１２とＭ＝４を有する同じネットワークビューを有すると仮定する。各ノードは、そのローカルメモリにおいて、そのドメインのドメイン記録２１０を維持して記憶する。各ノードのとなりに四角のブロックで示すような各ドメイン記録２１０は、そのローカルドメインの全てのメンバーノードの識別子を含む。あるいは、ドメイン記録２１０は、それ自体を除いたローカルドメイン内の全てのメンバーノードの識別子を含み得る。別の実施形態では、各ノードのドメイン記録２１０は、ノードのローカルドメインの全てのメンバーノードの識別子に加えて、アップ／ダウン状態を格納し得る。各ドメイン記録２１０におけるノードは、ドメイン記録２１０を維持するノードによりソートされた順序付けリストに従って、順序付けされる。

図２Ｂは、代替の実施形態に従う拡張（enhanced）ドメイン記録２２０の例を示す。拡張ドメイン記録２２０は、そのローカルドメインにおける各メンバーノードに対して、ノードの識別子、そのアップ／ダウン状態、発生（generation）識別子を含む。発生識別子は、ノードのローカルドメインの変更（例えば、ノードのアップ／ダウン状態またはノードの追加／削除）毎にインクリメントされる。１つの実施形態では、発生識別子はステッピング番号であり、別の実施形態では、発生識別子は、その値が最大に達したときにゼロにリセットするラウンドステッピング番号である。１つの実施形態では、発生識別子は、１６ビットの整数により実装され得る。図２Ｂにおける拡張ドメイン記録２２０の例は、ノード１において維持され格納される。図２Ｂに示されていないが、ネットワークにおける各ノードは、この代替的な実施形態に従って、そのローカルドメインの拡張ドメイン記録を維持し格納し得る。

発生識別子の使用は、少なくとも２つの目的を有する。第１の目的は、ドメイン更新を最適化することである。拡張ドメイン記録を受信したノードは、送信側のローカルドメインに関して何らかの変化があるか、すなわち、重い演算となり得る、受信側のノードがドメインヘッドの完全な再割り当て、および／または、ノードのソートされたリストの再計算を行う必要があるか否かを迅速に判定することができる。第２の目的は、他のノードのドメイン更新に合わせることである。１つの実施形態では、ノードがネットワークに接続された後、ノードは、そのドメインヘッドからのみ、拡張ドメイン記録を受信する。したがって、非ドメインヘッドのローカルドメインのノードのビューが遅れをとり得る（すなわち、古くなる）というリスクが存在する。ドメインヘッドが、そのローカルドメインの全てのメンバーノード（それ自体を含む）の発生識別子を送信することによって、受信側のノードは、これらのメンバーノードのいずれかに対して遅れているかを知り得る。遅れた場合、受信側のノードはそのノードに確認プローブを発行し、その最新のドメイン記録を取得する。

以下に詳細に説明するように、図２Ａのドメイン記録の送信は、イベント駆動型である。すなわち、ノードのアップ／ダウン状態やノードの追加／削除などのドメインイベントが発生したときに送信される。反対に、図２Ｂの拡張ドメイン記録の送信は、時間駆動型である。すなわち、ドメインイベントがあるかどうかに関係なく、周期的なプローブとプローブの応答の一部として送信される。１つの実施形態では、送信側のノードの拡張ドメイン記録は、それが送信する全てのプローブおよびプローブ応答にアタッチされる。

図３は、１つの実施形態に従う、ネットワークにおけるノードを複数のドメインに分割するための方法３００を示すフロー図である。方法３００は、ネットワークにおける各ノードにより実行される。明確性のために、方法３００を、方法３００を実行するノード（「自ノード（セルフノード）」と称する）の観点から説明する。方法は、ステップ３１０において、自ノードがそのローカルドメインを設定することから開始する。ローカルドメインは、自ノードと、自ノードの順序付けリストにおいて、自ノードに続く（Ｍ−１）個のノードから開始する。ステップ３２０では、自ノードは、順序付けリストにおけるローカルドメインノードの終わりの後に来る第１の動作ノードであるドメインヘッドを指定する。ノード１が自ノードである図１Ａの例を参照すると、ノード５がアップ状態であれば、ノード５がドメインヘッドとして指定される。ノード５がダウン状態であれば、ノード１は、方法３００の以降のステップにおいて説明するように、次の動作ノード（例えばノード６）をドメインヘッドとして指定し、ノード６の報告されたドメイン記録を遠隔ドメインとして適用する。ノード５がアップ状態になれば、ノード１は、ノード５を新しいドメインヘッドとして再指定し、ノード５の報告されたドメイン記録を新しい遠隔ドメインとして適用する。

なお、ネットワークにおける全ての他のノードのドメイン記録は、自ノードに先に報告されている。したがって、どのノードがドメインヘッドとして指定されたかに関係なく、自ノードは、対応するドメイン記録を適用し遠隔ドメインを設定することができる。報告されたドメイン記録は、ドメインヘッドのローカルドメインにおけるメンバーノードを識別する。通常は、自ノードのローカルドメインとドメインヘッドのローカルドメインは同じサイズ（Ｍ）を有する。なぜならば、サイズは通常同じ式を用いて同じＮから計算されるからである。しかしながら、いくつかのシナリオでは、自ノードとドメインヘッドは、異なるネットワークビューを有し得る。すなわち、それらはネットワークにおいて異なる数のノードが見え得る。ステップ３３０では、自ノードは、報告されたドメイン記録がネットワークビューと一致するか、すなわち、ドメイン記録があらゆる余分なノード（すなわち、自ノードのネットワークビューにおいて存在しないノード）またはあらゆる不明のノード（すなわち、自ノードの順序付けリストに存在するが報告されたドメイン記録では不明のノード）を含むか、を判定する。自ノードは、順序付けリストにおけるノードを、報告されたドメイン記録におけるノードと比較することにより、決定を行う。ステップ３２０で指定されたドメインヘッドから開始し、ソートされた順序に従ってそのドメインヘッドに続く各ノードを比較する。比較は、最初の不一致または自ノード（報告されたドメイン記録に自ノードが含まれている場合）のどちらか早い方で終了する。

報告されたドメイン記録が自ノードのネットワークビューと一致する場合、ステップ３４０において、自ノードは、報告されたドメイン記録における全てのノードを含む遠隔ドメインを設定する。報告されたドメイン記録が自ノードを含む場合、遠隔ドメインは自ノードの前に直ちに停止する。遠隔ドメインは、対応するドメインヘッドにより監視される。

報告されたドメイン記録が自ノードのネットワークビューと一致しない場合、ステップ３５０において、自ノードは、最初の不整合ノードの直前で切り捨てられた報告されたドメイン記録を用いて遠隔ドメインを設定する。ドメインの切り捨ての例を、図４Ａと図４Ｂに示し、後述する。

ステップ３６０では、ドメインに配置されていない、自ノードのネットワークビューにおけるノードが更に存在する場合、方法３００はステップ３２０へ戻り、前のドメインの終了後に来る次の動作ノードがドメインヘッドとして指定される。方法３００は、ネットワークビューにおける全てのノードがドメインに配置され、ステップ３７０で終了するまで継続する。

図４Ａは、１つの実施形態に従う、自ノードにより受信されたドメイン記録が余分なノードを有する例を示す。この例では、ノード上に示す数により示すように、ノードは、昇順でかつ非連続な順序でソートされている。本例における自ノードはノード１であり、Ｎ_１＝９およびＭ_１＝３のネットワークビューを有する。ノード２３のネットワークビューに存在するノード５、ノード７７、およびノード７８は、ノード１には見えない（すなわち、ノード１のネットワークビューには存在しない）。ノード１がこれらのノードが見えない１つの最も一般的な理由は、ノード１がノード２３より遅く（例えば、１秒の何分の１）開始し、それにより、これらの３つのノードを検出する時間を有さなかったことである。別の理由は、ノード１と３つのノードとの間の検出を禁止するネットワークまたはスイッチの問題であり得る。更に別の理由は、ネットワークの構成であり得る。例えば、ネットワークは、２つの仮想ローカルエリアネットワーク（ＶＬＡＮ）またはサブネットを含むように構成されてもよく、ノード５、ノード７７、およびノード７８を除く全てのノードが一方に接続され、ノード１を除く全てのノードが他方に接続される。別の理由は、ネットワークがフルメッシュネットワークとして設定されないことであり得る。例えば、ネットワークは、スターネットワークまたはデュアルスターネットワークとして設定され得る。

ノード１はまず、３つのノード（ノード１、ノード４、およびノード１１）を含むローカルドメインを設定する。ノード１のネットワークビューにおいて、ノード１１に続くノードはノード２３である。ノード２３が動作中であると仮定すると、ノード１はノード２３をドメインヘッドとして指定する。ノード２３は、Ｎ_２３＝１２およびＭ_２３＝４のネットワークビューを有する。ノード２３のドメイン記録は、ＤＲ_２３＝｛ノード２３、ノード３４、ノード４０、ノード７７｝であり、それはノード１に報告される。ローカルドメインを設定した後、ノード１は、ＤＲ_２３をその順序付けリストと比較し、ノード７７を（ノード１のネットワークビューにいない）第１の不整合ノードとして識別する。したがって、ノード１は、ＤＲ_２３を用いて遠隔ドメインを設定するが、第１の不整合ノードであるノード７７の直前である、４１０におけるノードのリストを切り捨てる。結果として、遠隔ドメインは、ドメインヘッドであるノード２３を伴う｛ノード２３、ノード３４、ノード４０｝を含む。同様に、ノード１は、次の動作ノード（例えばノード８６）を、次の遠隔ドメインに対するドメインヘッドとして指定し、｛ノード８６、ノード９２、ノード９４｝として次の遠隔ドメインを設定する。ノード１のドメインは実線で囲まれ、ノード２３のローカルドメインは破線で囲まれる。ノード１がノード２３から受信したドメイン記録（ＤＲ_２３）は、例えば、ノード追加またはノード削除といったノード１のネットワークビューに対する変化があった場合に、後の整合の目的のためにノード１において維持される。

図４Ａにおいて、ノード７７の代わりに別のノード（例えばノード８６）がノード１に見えない場合、ＤＲ_２３は、ノード１のネットワークビューと一致し得る。この場合、ノード１はＤＲ_２３を用いて、ドメインヘッドであるノード２３を伴う｛ノード２３、ノード３４、ノード４０、ノード７７｝として遠隔ドメインを構成する。したがって、この場合は、遠隔ドメインのサイズは４に等しく、それはＭ_１＝３より大きい。次の遠隔ドメインは、ドメインヘッドであるノード９２を伴う｛ノード９２、ノード９４｝となり得る。

図４Ｂは、１つの実施形態に従う、自ノードにより受信されたドメイン記録が不明のノードを有する例を示す。本例では、自ノードはノード２３である。図４Ｂに示される全てのノードは、ノード２３のネットワークビューにおけるものである。ローカルドメインサイズＭ_２３＝４にしたがって、ノード２３はまず、４つのノード｛ノード２３、ノード３４、ノード４０、ノード７７｝を含むそのローカルドメインを設定する。ノード２３は、｛ノード７８、ノード８６、ノード９２、ノード９４｝を含む第１の遠隔ドメインに対するドメインヘッドとして、ノード７８を指定する。ノード２３はそして、次のドメインヘッドとしてノード１を指定し、ノード１のドメイン記録ＤＲ_１＝｛ノード１、ノード４、ノード１１｝に基づいて第２の遠隔ドメインを設定する。ＤＲ_１とノード２３のネットワークビューの間の第１の不適合のノードは、ノード５であり、ＤＲ_１からなくなっている。したがって、ノード２３は、ノード５を失う前にＤＲ_１におけるノードを直ちに切り捨て、｛ノード１、ノード４｝を含む第２の遠隔ドメインを形成する。残りのノード｛ノード５、ノード１１｝は、第３の遠隔ドメインを形成する。ノード２３のドメインは破線で囲まれ、ノード１のローカルドメインは実線で囲まれる。ノード２３がノード１から受信したドメイン記録（ＤＲ_１）は、例えば、ノード追加またはノード削除といったノード２３のネットワークビューに対する変化があった場合に、後の整合の目的のためにノード２３において維持される。

図４Ａと図４Ｂで説明した余分なノードと不明なノードのシナリオは、異なるノードからみられるように、一般的には遷移する。しかしながら、異なるネットワークビューが不変である場合であっても、ネットワークにおけるノードを監視する目的で、上述の動作は機能する。

代替的な実施形態では、図３、図４Ａおよび図４Ｂに関連して上述した「ドメイン記録」は、「拡張ドメイン記録」により置き換えられ得る。したがって、「報告されたドメイン記録」は、１つのノードから別のノードへ報告される、図２Ａに示される例のような、ドメイン記録であり得る。代替的に、「報告されたドメイン記録」は、１つのノードから別のノードへ報告される、図２Ｂに示される例のような、拡張ドメイン記録であり得る。ドメインを形成するためにノードを分割する上述の動作は、「ドメイン記録」または「拡張ドメイン記録」のいずれかが使用される場合に同じ手法で実行することができる。

図５Ａは、１つの実施形態に従う、新しいノードがネットワークに追加されるシナリオを示す。新しいノード（例えばノード６）がネットワークに追加された場合、先に存在している全てのノードは、近隣ディスカバリメカニズムを介して、新しいノードを発見し、当該新しいノードへのリンクを確立し得る。図１Ａから図１Ｃに関連する説明から、これらのリンクは全てが能動的に監視されない、またはされない可能性があることが理解されるだろう。ノード（例えばノード９）がネットワークにおいてノード６の存在を検出し、それへのリンクを確立した場合、ノード９は、確立されたリンクを介して、例えばユニキャストを介して、そのドメイン記録または拡張ドメイン記録を送信する。ドメイン記録または拡張ドメイン記録を送信することにより、ノード９は、ノード９がそのドメイン記録に記載されたドメインにおける全てのメンバーノードのドメインヘッドであることを、ノード６に通信する。同様に、ネットワークにおける全ての他のノードは、ノード６が受信した情報に従ってそのネットワークビューを設定することができるように、それらのドメイン記録または拡張ドメイン記録をノード６に送信する。ネットワークへの新しいノードの追加により、ネットワークにおけるノードの総数（Ｎ）は変化する。したがって、新しいノードを検出したことに応じて、現存のノードのそれぞれは、そのノードのリストを再ソートし、必要であれば、そのローカルドメインのメンバーシップ、その遠隔ドメインのメンバーシップ、および／または遠隔ドメインにおけるドメインヘッドに対する調整を行うために、ドメインサイズ（Ｍ）を再計算する。新しいノードは、ローカルドメインまたは遠隔ドメインのいずれかに属し得る。

図５Ｂは、１つの実施形態に従う例示的なドメインイベントを示す。ノード（例えばノード９）がそのローカルドメインにおけるそのメンバーノードの１つに変化が生じたことを検出した場合、ノードは、ドメインイベントとして当該変更を、ネットワークにおける全ての他のノードへブロードキャストする。変更は、ノードの追加、ノードの削除、またはノードのダウン状態であり得る。ノードの追加またはノードの削除のイベントのケースでは、ノード９は、ノードの追加またはノードの削除に応答してドメインビューを更新した後に、その更新したドメイン記録を、ネットワークにおける全ての他のノードへブロードキャストする。ノードのアップ状態またはノードのダウン状態のイベントのケースでは、ノード９は、アップ／ダウンしたノードの識別情報（例えば識別子）のみをブロードキャストし得る。図５Ｂの例では、ノード９は、ノード１１がダウン状態であることを、ネットワークにおける全ての他のノードへブロードキャストする。

図５Ｃは、１つの実施形態に従うドメインイベントの応答を示す。各ノードは、ネットワークにおける他のノードからドメインイベントを受信するように準備する。ノードが所与のノード（例えばノード１１）についてのノードダウンのイベントを受信した場合、ノードは、当該所与のノードがダウン状態であることを確認するためにその所与のノードへ１つ以上の確認プローブを送信する。これは、ノードＸがノードＹ通信可能でない場合であっても、ノードＺはノードＹと通信可能でないことを意味しないからである。１つの実施形態では、送信される確認プローブの数は予め決定された数であり得る。確認プローブの送信は、送信側のノードが所与のノードから応答を受信するまで、または、ダウン状態である同じ所与のノードに関して別の送信元から第２のノードのダウンイベントを受信するまで、継続する。例えば、第１のノードダウンイベントは、ノード１１がダウン状態であることを通知するノード９からのものであり、第２のノードダウンイベントは、ノード１１がダウン状態であることも通知するノード１０からのものであってもよい。第２のノードダウンイベントを受信すると、送信側のノードはプロービングを停止し、所与のノードへのリンクを無条件に解放する（すなわち、ノードがダウン状態であることを確認する（またはしない）ための確認プロービングを更に待たずに）。送信側のノードはまた、予め決められた数の確認プローブを送信し、当該所与のノードからの応答を受信しなかった後に、プロービングを停止し、所与のノードへのリンクを無条件に解放してもよい。図５Ｃの例に示すように、ネットワークにおいてアップ状態にある１１ノード全ては、ノード９からノードダウンイベントを受信したことを受けて、ノード１１へ確認プローブを送信する。

ノードがダウン状態となったととき、アップ状態からダウン状態へ状態は変化するが、ネットワークには存在し続ける。しかしながら、ダウン状態のノードは、他のノードを監視するドメインヘッドとして機能することはできない。したがって、ノードが、そのドメインヘッドの１つがダウン状態であることを検出した場合、ノードは、その遠隔ドメインにおける全てのメンバーノードの確認プロービングを開始する。例えば、ノード３がノード１１をＤ_３（図１Ｃ）に対するドメインヘッドとして指定した場合、ノード３は、ノード１１がダウン状態であることを決定したときに、ノード１２、ノード１、およびノード２へ確認プローブを送信する。もし、Ｄ_３におけるこれらのメンバーノードの１つ以上がアップ状態である場合は、ノード３は、アップ状態であるＤ_３における次のノード（例えばノード１２）へ、Ｄ_３のドメインヘッドを移動させる。ノード１１が再びアップ状態となった場合、ノード３は、Ｄ_３のドメインヘッドをノード１１へ戻し得る。

ドメインイベントの別の例は、ノードアップイベントである。図５Ｂを再び参照すると、ノード９がノード１１がアップ状態であると検出した場合、ノード９は、ノード１１がアップ状態であることを、ネットワークにおける全ての他のノードへブロードキャストする。「ノードアップ」は、いくつかの他のメカニズムを用いて他のノードにより発見され得るが、ノードがその状態をダウン状態からアップ状態へ変更する場合のいくつかのケースにおいて、それは、ネットワークにおける、いくつかのみであって全てではない他のノードへの動作可能な接続を有することができる。例えば、ノード１は、ノード１１と動作可能な接続を有し、ノード１１がアップ状態であることについて知り得るが、ノード９は、ノード１１との動作可能な接続を確立することに失敗し得る。しかし、ノードアップイベントがノード９により報告された場合、それは、ノード９がノード１１との動作可能な接続を有することを示す。したがって、ノード１は、そのドメインヘッドであるノード９に依存して、ノード１１の状態を更新することができる。

前述したように、ドメインイベントは、ノードがアップ状態、ダウン状態、追加され、または削除された場合に、ネットワークにおける全てのノードへブロードキャストされ得る。ノードの状態の「アップ」または「ダウン」は、状態変化であり、ネットワークに存在するノードの総数への影響はない。したがって、ノードがアップ／ダウン状態を変更する場合、ネットワークにおける他のノードは、ノードを再ソートせず、ローカルドメインのサイズを再計算しない。しかしながら、例えば、アップ／ダウン状態が変更されたノードがドメインヘッドであった場合、ノードのアップ／ダウン状態の変更は、例えば、ドメインヘッドの割り当ておよび遠隔ドメインのメンバーシップに影響を与えうる。したがって、各ノードは、ドメインヘッドを再割り当てするか、および／または、遠隔ドメインを変更するかを、決定する必要がある。ノードが追加され、または、削除された場合、ネットワークにおけるノードの総数は変化する。したがって、「ノード追加」または「ノード削除」のイベントが発生した場合、各ノードは、ノードを再ソートし、ドメインサイズを再計算する。各ノードはまた、現在のドメインヘッドが削除され得るため、または、ドメインの境界が変更され得るため、そのドメインヘッドの１つ以上を再指定し得る。

なお、図５Ｂと図５Ｃに関連して上述した動作は、ドメイン記録の使用に特有のものである。拡張ドメイン記録を使用する実施形態では、ノードのアップ／ダウン、およびノードの追加／削除イベントは、ノード間でプローブとプローブ応答がユニキャストを介して交換される場合に、報告される。送信側のノードは、その拡張ドメイン記録を、すべてのプローブ、および、送信するプローブ応答に加える。したがって、プローブまたはプローブ応答は、あらゆる数（ゼロからあらゆる正の整数）のドメインイベントを含み得る。

図６Ａ〜図６Ｄは、１つの実施形態に従う、２つのセットのプローブが各ノードから送信される例を示す。自ノードからの第１のプローブのセットは、能動的に監視されている全てのノードへ送信される。例としてノード１を用いると、ノード１は実線で示されるような第１のセットのプローブを、その能動的に監視されているノード（例えば、ノード２、ノード３、ノード４、ノード５、およびノード９）へ、第１の周波数で送信する。第１の周波数は、図１Ａに関連して上述した、予め決定された周波数である。

第２のセットのプローブは、ドメインヘッドを除く、遠隔ドメインにおける全てのノードへ、自ノードから送信される。第２のセットのプローブの受信はまた、「非ドメインヘッドノード」と称される。なお、各ノードは、ネットワークにおけるＮノードのサブセット（この例では５ノード）を能動的に監視するのみであるが、各ノードは、５ノードより多くのノードとの接続を有し得る。例えば、いくつかの実施形態では、各ノードは、ネットワークにおける他の（Ｎ−１）ノードの全てと接続することができ、対応する接続を介してこれらのノードのいずれかに対してトラフィックを送信することを望むことができる。ノードは、そのドメインヘッドに依存し、対応する遠隔ドメインにおける非ドメインヘッドのノードがアップ状態かを報告する。しかしながら、接続性は遷移的でない可能性がある。すなわち、ドメインヘッド（ノードＸ）がノードＹと通信することができる場合であっても、ノードＺもノードＹと通信できることを意味するものではない。そのようなシナリオは、通常のネットワーク動作ではほとんど起こり得ないが、「最後の手段」の障害発見メカニズムとして、各ノードは、ドメインヘッドにより検出可能でない接続障害を検出するために、低頻度でプローブの第２のセットを送信する。

図６Ａを参照すると、ノード１はドメインヘッド５に依存し、Ｄ_２におけるノードを監視する。ノード５はノード６と通信することができるが、ノード１もノード６を通信することができることは保証されない。したがって、ノード１は、図６Ａから図６Ｄにおいて破線で示すような、プローブの第２のセットを、ノード毎に第２の周波数で非ドメインヘッドのノードへ送信する。すなわち、これらのノードのそれぞれは、第２の周波数でプローブされる。第２の周波数は、第１の周波数より低い。例えば、２桁または３桁低い、または、この追加のプロービングによって引き起こされるバックグラウンドの監視の負荷を最小にするために、第１の周波数よりも十分に低い任意の周波数である。プローブの第２のセットは、各遠隔ドメインにおける非ドメインヘッドのノードに、ラウンドロビンで、または、当業者により既知の他の方法で、送信され得る。図６Ａ〜図６Ｄは、Ｄ_２における非ドメインヘッドのノードのラウンドロビンプロービングを示す。破線で示すように、プロービングは、図６Ａから始まり、次に図６Ｂから図６Ｃおよび図６Ｄに続き、次に図６Ｂから繰り返され、以下同様である。他の非ドメインヘッドのノード、例えば、Ｄ_３におけるノード１０、ノード１１、およびノード１２は、Ｄ_２における非ドメインヘッドのノードと並行にラウンドロビンでプローブされる。代替的な実施形態では、全ての非ドメインヘッドのノードは、一度に１つのドメイン、順次にラウンドロビンでプローブされてもよい。しかしながら、この代替的な実施形態に対する障害検出時間は、より大きなクラスタサイズ（例えば、数百または数千のノードがある場合）に対して過度なものとなり得る。更に別の実施形態では、ノードは、別のノードへトラフィックを送信し、確認応答を受信しない場合に、接続の問題を知ることとなる。

図７は、１つの実施形態に従う、Ｎノード（例えばＮ＝１２）のネットワークにおける全ての能動的に監視されるリンクを示す。ドメインサイズＭがceil（^２√Ｎ）に等しい場合、Ｎノードのネットワークにおいて能動的に監視されているリンクの総数は、Ｔ＝Ｎ×（（Ｍ−１）＋（（Ｎ／Ｍ）−１））に等しくなる。Ｎ＝１２、Ｔ＝６０の場合。全てのノードが能動的に全ての他のノードを監視する従来のフルメッシュ監視方法では、能動的に監視するリンクの全体の数は、Ｔ_ｆｍ＝Ｎ×（Ｎ−１）となる。Ｎ＝１２の場合、Ｔの２倍より大きいＴ_ｆｍ＝１３２となる。したがって、バックグランド監視負荷において著しい削減が達成される。

図８は、１つの実施形態に従う、３レベルのハイパースケール監視方式を示す。この例では、Ｎ＝６４、Ｍ＝^３√Ｎ＝４である。この例では、ドメインは、６４ノードの３レベルの階層を形成する。各第１レベルのドメイン（例えば、左端の最初の４つのノード）は、４つのノードを含み、各第２レベルのドメインは、４つの第１レベルのドメインを含み、各第３レベルは、４つの第２レベルのドメインを含む。ノード１（一番左）に対しては、破線円８１０におけるリンクを介して、第１レベルのドメインにおける３つの（Ｍ−１＝３）の隣接のものを能動的に監視する。ノード１はまた、破線円８２０におけるリンクを介して第２レベルにおける３つのノード（Ｍ−１＝３）と、破線円８３０におけるリンクを介して、第３レベルにおける別の３つのノード（（Ｎ／Ｍ^２）−１＝３）を監視する。各ノードに対しては、（Ｍ−１）＋（Ｍ−１）＋（（Ｎ／Ｍ^２）−１）＝９の能動的に監視されるリンクが存在する。従って、３レベル監視方法に対しては、全体Ｎ×（（Ｍ−１）＋（Ｍ−１）＋（（Ｎ／Ｍ^２）−１））＝５７６の能動的に監視されるリンクが存在する。

図９は、ノード毎に能動的に監視されるリンクの数と、フルメッシュ監視方式、２レベル監視方式、３レベル監視方式に対して能動的に監視されるリンクの総数を示す表９００である。表９００から、能動的に監視されるリンクの数に比例する、ハイパースケール監視方式のバックグランド監視負荷は、Ｎが増加する場合に、フルメッシュ監視方式と比較して、低い増加率を有することが分かる。更に、表９００は、３レベル監視方式が、Ｎが増加する場合に、２レベル監視方式より低い増加率を有することを表している。

２レベル監視方式および３レベル監視方式を上述に説明したが、ハイパースケール監視方式は、３より高いレベルに拡張することができることが理解できる。一般的に、Ｋレベルの方式（Ｋは２以上の整数）に対しては、Ｍはceil（^Ｋ√Ｎ）として計算することができる。ドメインは、ＮノードのＫレベルの階層を形成する。各第１レベルのドメインはノードで構成され、各第２レベルのドメインは第１レベルのドメインで構成され、各第Ｋレベルのドメインは、第（Ｋ−１）レベルのドメインで構成される。能動的に監視されるリンクの総数、およびバックグランド監視負荷は、より高いレベルのハイパースケール方式で削減することができる。しかしながら、方式の複雑性も、高いレベルでは増加する。

図１０は、１つの実施形態に従う、Ｎノードのネットワークを監視するための方法１０００を示すフロー図である。方法１０００は、Ｎノードの各ノードにより実行される。したがって、以下において「ノード」という用語は、ネットワークにおける各ノードを指す。方法１０００は、Ｎノードをソートされた順序に従ってドメインに分割するステップ１０１０で開始する。ドメインは、ノードが配置されるローカルドメインと、１つ以上の遠隔ドメインを含む。各遠隔ドメインは、遠隔ドメインにおけるメンバーノードを監視するために指定されたドメインヘッドを有する。ステップ１０２０では、ノードは、ローカルドメインにおける全ての他のメンバーノードと遠隔ドメインにおけるドメインヘッドとを含む、能動的に監視されているノードに、所与の周波数においてプローブを送信する。ステップ１０３０では、ノードは、プローブに応答して受信した応答に基づいて、能動的に監視されているノードのそれぞれがアップ状態かを判定する。

ＴＩＰＣプロトコルに従って動作するネットワークにおいては、上述したハイパースケールノード監視方式が使用される。しかしながら、ハイパースケールノード監視方式は、送信制御プロトコル（ＴＰＣ）または他のプロトコルといった、異なるプロトコルに従って動作するネットワークにおいても使用することができる。

図１１Ａは、１つの実施形態に従うネットワークノード１００１のブロック図である。１つの実施形態では、ネットワークノード１００１は、オペレータネットワークまたはデータセンタにおけるサーバであり得る。ネットワークノード１００１は、処理回路１００２、メモリまたは命令レポジトリ１００４、およびインタフェース回路１００６を有する。インタフェース回路１００６は、少なくとも１つの入力ポートと少なくとも１つの出力ポートを含むことができる。メモリ１００４は、処理回路１００２によって実行可能な命令を含み、それにより、ネットワークノード１００１は、図１０の方法１０００を含む、ここに記載された種々の実施形態を実行するように動作可能である。

図１１Ｂは、複数のモジュールを含む例示的なネットワークノード１１００のブロック図である。１つの実施形態では、ネットワークノード１１００は、オペレータネットワークまたはデータセンタにおけるサーバであり得る。ネットワークノード１１００は、ソートされた順序に従ってＮノードをドメインに分割するように構成された、または動作する、分割モジュール１１１０を含む。ドメインは、ノードが配置されるローカルドメインと、１つ以上の遠隔ドメインを含む。各遠隔ドメインは、該遠隔ドメインにおけるメンバーノードを監視するために指定されたドメインヘッドを有する。ネットワークノード１１００はまた、ローカルドメインにおける全ての他のメンバーノードと遠隔ドメインにおけるドメインヘッドとを含む、能動的に監視されているノードへ、所与の周波数においてプローブを送信するように構成され、または動作する、プローブモジュール１１２０と、プローブに応答して受信された応答に基づいて、能動的に監視されているノードがアップ状態かを判定するように構成され、または動作する、判定モジュール１１３０を有する。ネットワークノード１１００は、ここに説明したような種々の実施形態を実行するように構成することができる。

図１２は、クラウドコンピューティングエンティティの階層を含むクラウドコンピューティング環境１２００の構造的概要である。クラウドコンピューティング環境１２００は、ネットワーク１２３５を介して接続される異なる地理的サイトにおいて、いくつかの異なるデータセンタ（ＤＣ）を含むことができる。各データセンタ１２３０のサイトは、いくつかのラック１２２０を有し、各ラック１２２０はいくつかのサーバ１２１０を有することができる。代替的な実施形態では、クラウドコンピューティング環境は、任意の数のデータセンタ、ラック、およびサーバを有してよいことが理解される。サーバ１２１０のセットは、リソース１２４０をホストするために選択され得る。１つの実施形態では、サーバ１２１０は、ホスティングエンティティ、および、それらのホストされるエンティティをホストするための実行環境を提供する。ここで、ホスティングエンティティはサービスプロバイダであってもよく、また、ホストされるエンティティは、サービスプロバイダにより提供されるサービスであってもよい。ホスティングエンティティの例は、（コンテナをホストし得る）仮想マシン、および（含まれるコンポーネントをホストし得る）コンテナ等がある。コンテナは、それ自身の中で他のコンポーネントを含むことが出来るソフトウェアコンポーネントである。同じオペレーティングシステム（ＯＳ）のインスタンスは、複数のコンテナを共有することができ、各コンテナは、それに含まれるコンポーネントに対して独立した実行環境を提供する。ＶＭとは対照的に、コンテナ、およびそれらに含まれるコンポーネントは、同じホストＯＳインスタンスを共有するため、オーバーヘッドが少なくなる。

更に、サーバ１２１０とそのリソース１２４０の詳細を、１つの実施形態に従って、図１２の点線円１２１５内に示す。クラウドコンピューティング環境１２００は、既製の（off-the-shelf（ＣＯＴＳ））プロセッサとすることが可能な１つ以上のプロセッサ１２６０のセット、専用の特定用途向け集積回路（ＡＳＩＣ）または、デジタルまたはアナログハードウェアコンポーネントまたは特定用途のプロセッサを含むあらゆる他の種類の処理回路、および、およびネットワークインタフェースカードとしても知られるネットワークインタフェースコントローラ１２７０（ＮＩＣ）、ならびに非一時的プロセッサ１２６０によって実行可能なソフトウェアおよび／または命令がそこに格納された機械可読記憶媒体１２９０を含む。

動作中、プロセッサ１２６０は、ハイパーバイザ１２５０およびハイパーバイザ１２５０によって実行される１つ以上のＶＮ１２４１、１２４２をインスタンス化するためにソフトウェアを実行するハイパーバイザ１２５０とＶＭ１２４１、１２４２は、仮想リソースであり、この実施形態では、ノードインスタンスを実行し得る。１つの実施形態では、ノードインスタンスは、ここに説明したような種々の実施形態を実行するために、ハイパーバイザ１２５０上で実行するＶＭ１２４１、１２４２の１つ以上において実装され得る。１つの実施形態では、ノードインスタンスは、図１０の方法１０００を含む、ここに説明したような種々の実施形態を実行するネットワークノードとしてインスタンス化され得る。

実施形態では、ノードインスタンスのインスタンス化は、ユーザ１３００により、または、異なる方法でマシンにより、開始することができる。例えば、ユーザ１３００は、ノードインスタンスのインスタンス化を開始するために、ユーザインタフェースを介して、例えばボタンをクリックすることにより、コマンドを入力することができる。あるいは、ユーザ１３００は、コマンドラインまたは別の同様のインタフェース上でコマンドをタイプすることができる。そうでなければ、ユーザ１３００は、ノードインスタンスのインスタンス化を開始するために、ユーザインタフェースを介して、または電子メール、メッセージング、または電話を介してネットワークまたはクラウド管理者に命令を提供することができる。

実施形態は、機械可読媒体（コンピュータ可読媒体とも呼ばれる非一時的機械可読記憶媒体１２９０、プロセッサ可読媒体、またはコンピュータ可読プログラムコードが組み込まれたコンピュータ使用可能媒体）に格納されたソフトウェア製品として表すことができる。非一時的機械可読媒体１２９０は、ディスケット、コンパクトディスク読み取り専用メモリ（ＣＤ−ＲＯＭ）、ハードディスクまたは固体のようなデジタル多用途ディスク読み取り専用メモリ（ＤＶＤ−ＲＯＭ）メモリ装置（揮発性または不揮発性）を含む磁気、光または電気記憶媒体、状態ドライブ、または類似の記憶機構を含む、任意の適切な有形媒体であってもよい。機械可読媒体は、命令、コードシーケンス、構成情報、または、実行されるとプロセッサに実施形態に従う方法のステップを実行させる他のデータ、の種々のセットを含み得る。当業者であれば、記載された実施形態を実施するために必要な他の命令および動作も、機械可読媒体に格納することができることを理解するであろう。機械可読媒体から実行されるソフトウェアは、記載されたタスクを実行するために回路とインタフェースすることができる。

上記の実施形態は単なる例示であることが意図されている。添付の特許請求の範囲によってのみ規定される範囲から逸脱することなく、当業者によって特定の実施形態に変更、修正および変形が行われてもよい。

Claims (39)

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. Ｎ個のノードのネットワークを監視するための方法であって、前記Ｎ個のノードの各ノードにより前記方法は実行され、前記方法は、
    クラウドコンピューティング環境においてノードインスタンスのインスタンス化を開始することであって、前記環境は、前記ノードインスタンスを動作させるために処理回路とメモリを提供し、前記ノードインスタンスは、
    前記Ｎ個のノードをソートされた順序にしたがって複数のドメインに分割し、ここで、前記ドメインは、前記ノードが位置するローカルドメインと１つ以上の遠隔ドメインを含み、各遠隔ドメインは前記遠隔ドメインにおけるメンバーノードを監視するために指定されたドメインヘッドを有し、
    前記ローカルドメインにおける全ての他のメンバーノードと前記遠隔ドメインにおけるドメインヘッドを含む能動的に監視されているノードへ、所与の周波数においてプローブを送信し、
    前記プローブに応答して前記能動的に監視されているノードから受信した応答に基づいて、前記能動的に監視されているノードのそれぞれがアップ状態かを判定するように動作する、方法。