JP4475818B2

JP4475818B2 - 漸進変化を伴うオブジェクトハッシング

Info

Publication number: JP4475818B2
Application number: JP2000590054A
Authority: JP
Inventors: クロッツ，ボリス; バンフォード，ロジャー・ジェイ; フィッシャー，ジェフリー; マーチャンダニー，ラビ
Original assignee: オラクル・インターナショナル・コーポレイション
Priority date: 1998-12-21
Filing date: 1999-12-06
Publication date: 2010-06-09
Anticipated expiration: 2019-12-06
Also published as: WO2000038062A1; EP1055172B1; EP1830262B1; AU770875B2; EP1055172A1; US6363396B1; DE69937946T2; HK1104861A1; EP1830262A1; CA2320307C; CA2320307A1; AU2475900A; DE69939133D1; JP2002533809A; DE69937946D1

Description

【０００１】
【発明の分野】
この発明はコンピュータシステムに関し、より特定的には、コンピュータシステム内の資源を支配するための技術に関する。
【０００２】
【発明の背景】
データベースサーバは、トランザクションを実行する間も資源を利用する。たとえ資源がデータベースサーバ間で共有可能であったとしても、多くの資源はある種の態様では任意の所与の時間で２つ以上のプロセスによってアクセス不可能であることがある。たとえば、記憶媒体のデータブロックまたは記憶媒体上に記憶されるテーブルなどの資源は、ある態様では（たとえば読出）複数のプロセスによって同時的にアクセス可能であるが、他の態様では（たとえば書込）一度に１個のプロセスによってしかアクセスされ得ない。したがって、資源へのアクセスを制御するメカニズムが開発されてきた。
【０００３】
そのようなメカニズムの１つをロックと呼ぶ。ロックは、特定のプロセスが資源に関してある種の権利を与えられたことを示すデータ構造である。ロックには多くのタイプがある。多くのプロセスによって同じ資源上で共有可能であるタイプのロックもあれば、他のロックが同じ資源上に与えられることを防ぐタイプのロックもある。
【０００４】
資源に対するロックを与える責任を担う存在をロックマネージャと呼ぶ。単一ノードのデータシステムでは、ロックマネージャは典型的には、ノード上の１つ以上のプロセスからなるものである。マルチプロセッシングマシンまたはローカルエリアネットワークなどの、複数ノードのシステムでは、ロックマネージャは、多数のノードに分散したプロセスを含むであろう。２つ以上のノード上に存在する構成要素を含むロックマネージャを分散ロックマネージャと呼ぶ。
【０００５】
図１は、複数ノードのコンピュータシステム１００のブロック図である。各ノードは、そこにデータベースサーバおよび分散ロック管理システム１３２の一部を備えている。具体的には、例示のシステムは、３つのノード１０２、１１２および１２２を含み、その上に、それぞれデータベースサーバ１０４、１１４および１２４と、それぞれロックマネージャユニット１０６、１１６および１２６とが存在する。データベースサーバ１０４、１１４および１２４は、同じデータベース１２０へのアクセスを有する。データベース１２０は、データの複数ブロックを含むディスク１１８上に存在する。一般的に、ディスク１１８は１つ以上の永続的記憶装置を表わし、これはノード１０２、１１２および１２２を含むマシンを含むがこれに限定されるものではない、任意の数のマシン上にあってもよい。
【０００６】
通信メカニズムによって、ノード１０２、１１２および１２２上のプロセスは相互にかつデータベース１２０の一部を含むディスクと通信可能である。ノードとディスク１１８との間の特定の通信メカニズムは、システム１００の性質によって異なる。たとえば、ノード１０２、１１２および１２２がネットワーク上のワークステーションに対応する場合、通信メカニズムは、ノード１０２、１１２および１２２がマルチプロセッシングマシン内のメモリおよびプロセッサのクラスタに対応する場合とは異なるであろう。
【０００７】
データベースサーバ１０４、１１４および１２４のいずれかが他のデータベースサーバと共有される資源にアクセス可能となる前に、これは資源の適切なロックを分散ロック管理システム１３２から獲得しなければならない。そのような資源は、たとえば、データベース１２０からのデータが格納されているディスク１１８の１つ以上のブロックであってもよい。
【０００８】
ロック管理システム１３２は、データベースサーバ１０４、１１４および１２４によって保持される、データベースサーバが共有する資源に対するロックを示すデータ構造を記憶する。もしあるデータベースサーバが資源のロックを有している一方で別のデータベースサーバがその資源へのロックを要求すれば、分散ロック管理システム１３２は、要求されたロックが許可されたロックと一致しているかどうかを決定しなければならない。もし要求されたロックが許可されたロックと一致していなければ、要求者は、許可されたロックを保持しているデータベースサーバが許可されたロックを解放するまで、待たなければならない。
【０００９】
あるアプローチに従うと、ロック管理システム１３２は、ロック管理システム１３２によって管理されるいずれの資源についても１つのマスタ資源オブジェクトを維持し、かつ、データベースサーバを含む各ノードごとに１つのロックマネージャユニットを含む。特定の資源のマスタ資源オブジェクトはとりわけ、特定の資源について許可されたまたは要求されたすべてのロックの表示を記憶する。各資源に対するマスタ資源オブジェクトは、ロックマネージャユニット１０６、１１６および１２６の１つ内にのみ存在する。
【００１０】
ロックマネージャユニットが存在するノードを、資源の「マスタノード」（または単に「マスタ」）と呼び、そのマスタ資源オブジェクトはロックマネージャユニットによって管理される。したがって、資源Ｒ１のマスタ資源オブジェクトがロックマネージャユニット１０６によって管理されれば、ノード１０２が資源Ｒ１のマスタとなる。
【００１１】
典型的なシステムでは、ハッシュ関数を採用して、所与の資源のマスタノードとして働く特定のノードを選択する。具体的には、ハッシュ関数を資源名に適用して値を生成する。同じ値にハッシュされる資源名はすべて、同じ「バケット」に属する。次に、所与のバケットにその名前が属するすべての資源のマスタとなるよう、各ノードが割当てられる。
【００１２】
たとえば、システム１００は３つのノードを含み、したがって、値０、１および２を生成する３バケットハッシュ関数を採用するであろう。各バケットは３つのノードの１つに関連付けられる。システム１００での特定の資源のマスタとしての役割を果たすノードは、資源の名前にハッシュ関数を適用することによって決定される。値０に関連付けられるバケットにハッシュされる名前を有する資源はすべて、ノード１０２上で支配される。値１に関連付けられるバケットにハッシュされる名前を有する資源はすべて、ノード１１２上で支配される。値２に関連付けられるバケットにハッシュされる名前を有する資源はすべて、ノード１２２上で支配される。
【００１３】
ノード上のプロセスが資源にアクセスしたいとき、ハッシュ関数が資源の名前に適用されて資源のマスタを決定し、ロック要求がその資源のマスタノードに送信される。資源のマスタノード上のロックマネージャは、関連付けられた資源のロックの割当および割当解除を制御する。
【００１４】
資源のマスタノードが、別のノード上で稼動するプロセスに、資源のロックを許可すると、その別のノードがそのプロセスが保持する資源のロックについての情報を維持する。資源に関心のある（すなわち、そのロックを保持する）非マスタノードによって維持されるロック情報は、マスタノードに障害が発生した場合、復旧の間に、利用可能である。ローカルプロセスによって保持される、資源のロックを追跡するために、資源のマスタでないノードによって使用されるデータ構造を、シャドー資源オブジェクトと呼ぶ。いずれのマスタ資源オブジェクトについても、最大Ｎ−１個のシャドー資源オブジェクトが存在し得る（Ｎはシステム内のノードの数に等しい）。というのも、すべての非マスタノード上のプロセスが、同じ資源に対して非排他的ロックを同時に保持することが可能であるからである。
【００１５】
あるノードから別のノードへとロック資源のマスタを変更することを、ロック資源を「リマスタする」と言う。資源をリマスタするプロセスは、典型的には、資源のマスタ資源オブジェクトを新しいマスタ上に再構築することを伴う。資源がリマスタされている間、一般的には資源は利用不可能である。
【００１６】
任意の時点で、資源を支配する責任は、特定の組のノード間で分散される。ノードのその組が変わるとき、「エポック変更」が起こると言う。
【００１７】
さまざまな事象によって、リマスタリング動作を実行することが望まれるかまたは必要となることがある。たとえば、ノードに障害が発生するかまたはこれがシャットダウンすると、これらのノードによって現在支配されている資源の支配権は、他のノードに移動されなければならない。同様に、新しいノードがシステムに加えられると、資源のいくつかの支配権を新しく加えられたノードに移動して、資源管理に関連するロードをすべてのノード間で均一に分散することが望ましいであろう。
【００１８】
資源名ハッシュを用いて資源をノードに割当てる場合、エポック変更に応答して資源をリマスタすると、典型的には、ハッシュ関数を変更し、さらに、新しいハッシュ関数によって生成される資源からマスタへの対応付に基づいて支配権責任を再分散する必要がある。具体的には、システムがＮ個のノードからなる場合、Ｎバケットハッシュ関数（Ｎ個の値を生成するハッシュ関数）を用いてマスタノード割当を実行する。（ノードの付加、除去または障害によって）Ｎが変わると、ハッシュ関数も変更されなければならない。資源からマスタへの対応付のための新しいハッシュ関数が選択された後、マスタ資源オブジェクトはその新しいマスタに移動されなければならない。任意の所与の資源の新しいマスタは、新しいハッシュ関数を資源の名前に適用することによって決定される。
【００１９】
残念ながら、新しいハッシュ関数の採用に応答して起こるリマスタリングによって、システム内の資源をいずれも、リマスタリングしなければならない可能性がある。したがって、システム全体が、リマスタリングが完了するまで、実際上利用不可能となることがある。これは、システム構成の変更が比較的小さいものであったとしても当てはまる。たとえば、もし５１番目のノードが５０ノードのシステムに加えられるならば、システム内のすべての資源が５１個のノード間でのロードバランスをとるよう選択された新しいハッシュ関数によって、新しいマスタに割当てられる可能性がある。同様に、５０ノード上での１つのノードに障害が発生したときにも、大規模なリマスタリング動作が起こることがある。
【００２０】
前記に基づいて、複数ノードのシステムでのエポック変更に関連するリマスタリングオーバーヘッドを低減するリマスタリング技術を提供することが明らかに望まれる。さらに、新しいノードがシステムに加えられたときにもノードがシステムから取除かれたときにも、比較的バランスのとれたロード分散がエポック変更後にも維持されることを可能にするリマスタリング技術を提供することが望まれる。リマスタリング動作の持続時間の間、システム全体を実際上利用不可能にしないようなリマスタリング技術を提供することも望まれる。
【００２１】
【発明の概要】
典型的には再構成の間もたらされるオーバーヘッドおよびシステムの利用不可能性を低減するよう、エポック変更後に複数ノードのシステムを再構成するための方法およびシステムが提供される。この発明のある局面に従うと、資源からマスタへの対応付は、資源からバケットへのハッシュ関数と、バケットからノードへのハッシュ関数とを組合せることによって確立される。
【００２２】
この発明のある局面に従うと、資源からバケットへのハッシュ関数はエポック変更に応答して変更されないが、バケットからノードへのハッシュ関数はエポック変更に応答して変更する。したがって、資源からバケットへのハッシュ関数は「静的」であるが、バケットからノードへのハッシュ関数は「動的」である。
【００２３】
好ましくは、動的なバケットからノードへのハッシュ関数は、システム内の新しい数のノード間でロードバランスをとるよう、エポック変更後に調整される。さらに、バケットからノードへの割当に対する変更は、リマスタされなければならない資源の数を最小限にするよう行なわれる。
【００２４】
この発明の別の局面に従うと、資源のうちエポック変更の間にそのマスタを失ったもののみが、初期再構成の間に新しいマスタを割当てられる。ロードバランスは、システムが利用可能になった後に、資源を移動することによって徐々に達成される。一旦資源の古いマスタが要求された資源のマスタ資源オブジェクトを転送すると、これはアクセス要求を資源の新しいマスタに転送する。加えて、ノードの計画されたシャットダウンを見込んで、資源をノードから移動するための技術が開示される。
【００２５】
この発明は、同じ参照番号が同様の要素を指す添付の図面の図中に例として示されるが、これに限定されるものではない。
【００２６】
【好ましい実施例の詳細な説明】
複数ノードのシステムでの資源を管理するための方法および装置を記載する。以下の説明では、説明のため、この発明を完全に理解するために、多くの具体的詳細が述べられる。しかしながら、この発明はこれらの具体的な詳細なしに実施され得ることが当業者には明らかである。他の例では、この発明を不要にわかりにくくすることを避けるため、周知の構造および装置がブロック図で示される。
【００２７】
ハードウェア概要
図２は、この発明の実施例が実現可能であるコンピュータシステム２００を示すブロック図である。コンピュータシステム２００は、情報を受け渡しするためのバス２０２または他の通信メカニズムと、バス２０２に結合され情報を処理するためのプロセッサ２０４とを含む。コンピュータシステム２００はまた、ランダムアクセスメモリ（ＲＡＭ）または他のダイナミック記憶装置などの主メモリ２０６を含み、これはバス２０２に結合されプロセッサ２０４によって実行されるべき命令および情報を記憶する。主メモリ２０６はまた、プロセッサ２０４によって実行されるべき命令の実行の間、一時的変数または他の中間情報を記憶するために使用され得る。コンピュータシステム２００は、リードオンリメモリ（ＲＯＭ）２０８または他の静的記憶装置をさらに含み、これはバス２０２に結合され静的情報およびプロセッサ２０４のための命令を記憶する。磁気ディスクまたは光学ディスクなどの記憶装置２１０が設けられこれはバス２０２に結合され情報および命令を記憶する。
【００２８】
コンピュータシステム２００は、バス２０２を介して陰極線管（ＣＲＴ）などのディスプレイ２１２に結合されてもよく、これはコンピュータユーザに情報を表示する。英数字および他のキーを含む入力デバイス２１４は、バス２０２に結合されプロセッサ２０４に情報およびコマンド選択を与える。ユーザ入力デバイスの別のタイプは、マウス、トラックボールまたはカーソル方向キーなどのカーソルコントロール２１６であって、これは方向情報およびコマンド選択をプロセッサ２０４に与え、かつ、ディスプレイ２１２上のカーソルの動きを制御する。この入力デバイスは典型的には、第１の軸（たとえばｘ）および第２の軸（たとえばｙ）の、２軸での２自由度を有し、これによってデバイスは画面での位置を特定することが可能となる。
【００２９】
この発明は、複数ノードのシステムでの資源を管理するコンピュータシステム２００の使用に関する。この発明のある実施例に従うと、資源管理は、プロセッサ２０４が主メモリ２０６に含まれる１つ以上の命令の１つ以上のシーケンスを実行することに応答して、コンピュータシステム２００によって与えられる。そのような命令は、記憶装置２１０などの、別のコンピュータ読出可能媒体から主メモリ２０６に読出されてもよい。主メモリ２０６内に含まれる命令のシーケンスを実行することによって、プロセッサ２０４はここに記載するプロセスステップを実行する。代替の実施例では、ハードワイア回路をソフトウェア命令の代わりにまたはこれと組合せて使用してこの発明を実現してもよい。したがって、この発明の実施例は、ハードウェア回路およびソフトウェアの特定の組合せに限定されない。
【００３０】
ここに用いる「コンピュータ読出可能媒体」という言葉は、プロセッサ２０４に命令を与えて実行させることに関与する任意の媒体を指す。そのような媒体は、不揮発性媒体、揮発性媒体および伝送媒体を含むがこれに限定されるものではない、多くの形態を取ってもよい。不揮発性媒体は、たとえば、記憶装置２１０などの、光学ディスクまたは磁気ディスクを含む。揮発性媒体は、主メモリ２０６などの、ダイナミックメモリを含む。伝送媒体は、バス２０２を含むワイアを含む、同軸ケーブル、銅線および光ファイバを含む。伝送媒体はまた、電波および赤外データ通信の間生成されるものなど、音波または光波の形態を取ってもよい。
【００３１】
コンピュータ読出可能媒体の通常の形態は、たとえば、フロッピー、フレキシブルディスク、ハードディスク、磁気テープ、またはその他の磁気媒体、ＣＤ−ＲＯＭ、その他の光学媒体、パンチカード、紙テープ、孔のパターンを備えるその他の物理的媒体、ＲＡＭ、ＰＲＯＭおよびＥＰＲＯＭ、ＦＬＡＳＨ−ＥＰＲＯＭ、その他のメモリチップまたはカートリッジ、以下に記載する搬送波、またはコンピュータが読出可能なその他の媒体の形態を含む。
【００３２】
コンピュータ読出可能媒体のさまざまな形態は、１つ以上の命令の１つ以上のシーケンスをプロセッサ２０４に搬送して実行することにかかわり得る。たとえば、命令は最初に、遠隔コンピュータの磁気ディスク上に担持されてもよい。遠隔コンピュータは、命令をそのダイナミックメモリにロードし、モデムを使用して電話線を介して命令を送信することができる。コンピュータシステム２００にローカルなモデムは、電話線上のデータを受信し、赤外送信器を使用してデータを赤外信号に変換することができる。赤外検出器は赤外信号で搬送されるデータを受信可能であり、適切な回路がデータをバス２０２上に与えることができる。バス２０２は、データを主メモリ２０６に搬送し、プロセッサ２０４はそこから命令を取出し実行する。主メモリ２０６によって受取られた命令は、プロセッサ２０４によって実行される前またはその後に、記憶装置２１０上にオプションとして記憶されてもよい。
【００３３】
コンピュータシステム２００はまた、バス２０２に結合される通信インターフェイス２１８を含む。通信インターフェイス２１８は、双方向のデータ通信を与え、これはネットワークリンク２２０に結合し、ネットワークリンクはローカルネットワーク２２２に接続される。たとえば、通信インターフェイス２１８は、統合サービスデジタル網（ＩＳＤＮ）カードまたはモデムであってもよく対応するタイプの電話線にデータ通信接続を与える。別の例として、通信インターフェイス２１８は、互換性のあるＬＡＮにデータ通信接続を与えるローカルエリアネットワーク（ＬＡＮ）カードであってもよい。ワイアレスリンクが実現されてもよい。いかなるそのような実現化例でも、通信インターフェイス２１８は、さまざまなタイプの情報を表わすデジタルデータストリームを搬送する電気信号、電磁波信号または光学信号を送信し受信する。
【００３４】
ネットワークリンク２２０は、典型的には、１つ以上のネットワークを介して他のデータデバイスにデータ通信を与える。たとえば、ネットワークリンク２２０は、ローカルネットワーク２２２を介してホストコンピュータ２２４またはインターネットサービスプロバイダ（ＩＳＰ）２２６によって動作するデータ装置に接続してもよい。ＩＳＰ２２６は、現在通常「インターネット」２２８と呼ばれるワールドワイドパケットデータ通信ネットワークを介して、データ通信サービスを提供する。ローカルネットワーク２２２とインターネット２２８とはどちらも、デジタルデータストリームを搬送する電気信号、電磁波信号または光学信号を使用する。さまざまなネットワークを通る信号と、ネットワークリンク２２０上および通信インターネット２１８を通る信号とは、デジタルデータをコンピュータシステム２００へかつそこから搬送するものであるが、情報を転送する搬送波の例示的形態である。
【００３５】
コンピュータシステム２００は、ネットワーク、ネットワークリンク２２０および通信インターフェイス２１８を介して、プログラムコードを含め、メッセージを送信しデータを受信することが可能である。インターネットの例では、サーバ２３０は、インターネット２２８、ＩＳＰ２２６、ローカルネットワーク２２２および通信インターフェイス２１８を介して、アプリケーションプログラムのために要求されたコードを伝送可能である。
【００３６】
受信されたコードは、受信されたときにプロセッサ２０４によって実行されてもよいし、かつ／または記憶装置２１０または他の不揮発性装置に記憶されて後に実行されてもよい。このようにして、コンピュータシステム２００は、搬送波の形でアプリケーションコードを獲得可能である。
【００３７】
機能的な概要
Ｍバケットハッシュ関数を用いてＮ個ノードのシステムでのＬ数の資源について資源からマスタへの対応付を確立するための技術をここに記載する。Ｍは、Ｎよりも大きいがＬよりも小さい。実際には、ＬはＭよりも大きい３から４のオーダの大きさであり、ＭはＮよりも大きい１または２のオーダの大きさである。たとえば、１０００バケットハッシュ関数を用いて、６ノードシステムでの１００万個の資源について資源からバケットへの対応付を確立することができる。バケットの数はノードの数よりも大きいので、各ノードは、第２のバケットからノードへのハッシュ関数を用いて１つ以上のバケットを割当てられる。
【００３８】
この発明のある局面に従うと、ハッシュバケットに資源を対応付けるために用いられるハッシュ関数は、エポック変更に応答して変更されない。名前からバケットへのハッシュ関数と異なって、バケットからノードへのハッシュ関数はエポック変更に応答して変わる。したがって、資源からバケットへのハッシュ関数は「静的」であり、一方、バケットからノードへのハッシュ関数は「動的」である。
【００３９】
好ましくは、動的なバケットからノードへのハッシュ関数は、システムでの新しい数のノード間でロードバランスをとるよう、エポック変更後に調整される。好ましくは、バケットからノードへの割当の変更は、リマスタされなければならない資源の数を最小限にするようにして行なわれる。
【００４０】
ある実施例に従うと、バケットからノードへのハッシュは、バケット範囲からノードへの対応付情報を用いて実行され、この情報はどのバケット範囲がどのノードに対応するかを示すよう維持される。エポック変更に応答して、バケット範囲からノードへの対応付情報は、１組の再対応付規則に基づいて修正される。再対応付規則は、ロードを均等に分散し、かつ、リマスタされなければならない資源の数を最小限にしようとする。
【００４１】
バケットの数は資源の数よりも小さく、バケット範囲の数はバケットの数よりも小さいので、バケット範囲からノードへの対応付情報は典型的には、資源が個別にノードに対応付けられた場合必要であろう情報の量よりもかなり少なくてすむ。
【００４２】
例示的システム
図３を参照して、これは、この発明の実施例に従ってバケット範囲をノードに対応付ける複数ノードのシステムを例示するブロック図である。このシステムは、ハッシュ関数３０２を用いて、資源名３００を１０００個のハッシュバケット３０４に対応付ける。システムは、どのハッシュバケットがどのノードに対応するかを示す、バケット範囲からノードへの対応付情報３１８を維持する。このバケット範囲からノードへの対応付情報３１８は、第２のハッシュ関数として動作し、比較的大きい数のバケットをより小さい数のノードに対応付ける。バケットがノードに対応付けられると、そのバケットにハッシュされる資源名を有する資源は、そのノードで支配される。
【００４３】
図３に示す実施例では、２つのノード３０６および３０８がある。バケット範囲１〜５００はノード３０６に対応付けられ、バケット範囲５０１〜１０００はノード３０８に対応付けられる。したがって、ノード３０６は、バケット１〜５００に名前がハッシュされるすべての資源のマスタであり、ノード３０８は、バケット５０１〜１０００に名前がハッシュされるすべての資源のマスタである。
【００４４】
図４は、エポック変更が起きた後の、図３に示すシステムを例示するブロック図である。この例では、エポック変更は、新しいノード４０２がシステムに導入されてノードの数が３個に増えたために起きた。資源からバケット関数３０２への変更はエポック変更に応答してなされない。したがって、ハッシュバケットの数は同じままであり、すべての資源名が同じバケットにハッシュされ続けれている。
【００４５】
しかしながら、３つのノード間での資源のマスタリング責任をより均等に分散するために、バケット範囲からノードへの対応付情報３１８に修正が加えられる。具体的には、ノード３０６に対応付けられるバケット範囲は、１〜５００から１〜３３３に変更される。同様に、ノード３０８に対応付けられるバケット範囲は、５０１〜１０００から５０１〜８３３に変更される。残りのバケット範囲（３３４〜５００と８３４〜１００）はこのため、新しいノード４０２に対応付けられる。
【００４６】
新しいノード４０２に名前が対応付けられるバケットにハッシュされる資源のすべては、新しいノードでリマスタされなければならない。しかしながら、先行技術のリマスタリング技術と異なって、新しく導入されたノードに対応付けられない資源は、一般的には、その現在のマスタで支配され続ける。この例では、バケット１〜３３３にハッシュされる資源はすべて、ノード３０６で支配され続け、バケット５０１〜８３３にハッシュされる資源はすべて、ノード３０８で支配され続けた。したがって、リマスタに関連するオーバーヘッドは、これらの資源については全く起きない。さらに、これらの資源はリマスタされないので、これらの資源は、資源のリマスタに関連する利用不可能の期間を被ることがない。
【００４７】
バケット範囲からノードへの対応付調整
上記のとおり、バケット範囲からノードへの対応付は、（１）新しい組のノードの間でマスタリング負担を均等に分散し、かつ、（２）リマスタされる資源の数を低減するようにして、エポック変更に応答して調整される。さまざまな対応付調整技術を用いてこれらの目的を達成することができる。以下の説明では、具体的な技術を詳細に記載する。しかしながら、この発明は、特定の対応付調整技術に限定されるものではない。
【００４８】
この発明のある実施例に従うと、システムが使用する対応付調整技術は、確定的である。したがって、任意の特定の初期バケットからノードへの対応付および任意の特定のシステム構成変更が与えられれば、対応付調整規則によって、バケットからノードへの対応付は１回の修正ですむ。対応付調整規則の確定的な組を用いることによって、システム内のどのノードも、他のノードとの不必要な連係メッセージなしに、リマスタリング動作においてその役割に対する責任を果たすことができる。
【００４９】
説明のために、以下の記載では、システム内に存在するすべてのノードが資源の支配に等しく関与することが望ましいと仮定する。しかしながら、ノードすべてが関与するわけでなくかつ／またはノードが異なったレベルで関与するようなシステム（たとえば、あるノードが、別のノードで支配される資源の半数を支配することが望ましいようなシステム）に合わせて適合するよう、バケット割当技術を調整してもよい。
【００５０】
均等バケットアプローチ
均等バケットアプローチに従うと、システム内のノードはいずれも、エポック変更後にシステムに属するノードの数を示すメッセージを送信される。各ノードは、ハッシュ関数によって生成されるバケットの総数がわかっているので、バケットが既存のノード間で均等に分散されるためには、いくつのバケットをノードのいずれもが持たなければならないかを計算することができる（「ターゲットバケット数」）。
【００５１】
エポック変更後にシステム内に存在するノードは、以下の２つのカテゴリのうちの１つに属する。すなわち、現在割当てられている範囲がターゲットバケット数より大きい数のバケットに及ぶノード（「過剰ノード」）と、現在割当てられている範囲がターゲットバケット数より少ない数のバケットに及ぶノード（「不足ノード」）とである。均等バケットアプローチに従うと、過剰ノードは、その範囲がターゲットバケット数にのみ及ぶまで、その範囲を削減する。一方で、不足ノードは、過剰ノードが行なった範囲削減によって「より合わされて」いないままのバケットまで及ぶよう、その範囲を増大させる（またはさらなる範囲を割当てる）。この範囲の増大は、不足ノードの範囲がターゲットバケット数の数のバケットに及ぶようになるよう、不足ノード間で分散される。
【００５２】
たとえば、図４は、エポック変更が起きた後の図３のシステムを示す。エポック変更の際、第３のノード４０２が２ノードシステムに加えられた。均等バケットアプローチを用いると、例示のシステム変更後のバケットのターゲット数は、１０００／３＝３３３．３となる。エポック変更後当初、ノード３０６に割当てられた範囲は５００個の資源を含み、ノード３０８に割当てられた範囲は５００個の資源を含み、ノード４０２に割当てられた範囲は資源を全く含まない（ノード４０２には範囲がまだ割当てられていない）。したがって、ノード３０６および３０８は過剰ノードであり、ノード４０２は不足ノードである。
【００５３】
過剰ノード３０６および３０８は、これに割当てられた範囲を減らし、その結果その範囲はバケットのターゲット数（３３３）に削減される。例示の例では、ノード３０６に割当てられた範囲は、１〜５００から１〜３３３に削減され、ノード３０８に割当てられた範囲は５０１〜１０００から５０１〜８３３に削減される。過剰ノードがこの範囲削減を経た後、範囲３３４〜５００および８３４〜１０００に属するバケットはもはや、いかなるノードにも割当てられていないので、「より合わされたバケットプール」に属するようになる。
【００５４】
不足ノードには、より合わされたバケットプールに属するバケットを含む範囲が割当てられ、これによって、割当てられたバケットのその数はバケットのターゲット数に増える。この例では不足ノード４０２にのみ、より合わされたバケットプールに属する範囲のすべて（この場合では、範囲３３４〜５００および範囲８３４〜１０００）が割当てられる。エポック変更後のバケット範囲再割当に応答して、バケット範囲からノードへの対応付情報３１８は修正される。図４に示すバケット範囲からノードへの対応付情報３１８は、均等バケットアプローチに従って範囲が調整された後に、バケット範囲割当を反映する。
【００５５】
ある実施例に従うと、過剰ノードは、範囲割当の総数を削減するよう、より合わされたバケットプールに解放するべき範囲を選択する。たとえば、ノード３０８がより合わされたバケットプールにバケットを解放しようとする時点で、ノード３０６が既に、より合わされたバケットプールに範囲２２４〜５００を解放していたとする。範囲８３４〜１０００をより合わされたバケットプールに解放する代わりに、ノード３０８は、より合わされたバケットプールに既にある範囲に連続する範囲を選択してもよい。この例では、ノード３０８は、範囲５００〜６６６を解放するよう決定してもよい。範囲５００〜６６６を解放した後、ノード３０８には範囲６６７〜１０００が残され、より合わされたバケットプールは、単一の範囲３３４〜６６６を含む。
【００５６】
この例では、より合わされたバケットプールに含まれる単一の範囲を、不足ノード４０２に割当てるだけでよい。しかしながら、不足ノードが既に、これに割当てられている１つ以上のバケット範囲を有する場合、可能であれば、不足ノードは、その現在割当てられている範囲と連続する範囲を、より合わされたバケットプールから選択する。たとえば、ノード４０２がシステムから取除かれると仮定する。これによって、ノードの数が３から再び２に減るというエポック変更が起きる。ノード４０２には範囲３３４〜６６６が割当てられていたとすると、この範囲がより合わされたバケットプールに与えられるであろう。残りのノード３０６および３０８は、その現在の範囲が含むのは３３３個のバケットのみであり新しいターゲットバケット数は１０００／２＝５００となるので、このどちらも不足ノードとなるであろう。
【００５７】
その範囲をターゲットバケット数に増大させるために、ノード３０６は、より合わされたバケットプールから範囲３３４〜５００を取る。この範囲が選択されるのは、これがノード３０６に現在割当てられている範囲１〜３３３と連続するからである。次に、ノード３０８は、より合わされたバケットプールから残りの範囲５０１〜６６６を取る。これらの範囲調整の結果、ノード３０６および３０８に関連付けられる範囲はそれぞれ、再び、１〜５００および５０１〜１０００となる。
【００５８】
ノードベクトルアプローチ
バケット再割当に対する均等バケットアプローチの代替を、ここでは、ノードベクトルアプローチと呼ぶ。ノードベクトルアプローチに従うと、Ｍ長ベクトルが維持される。Ｍは、資源からバケットへのハッシュ関数のハッシュバケットの数である。ノードベクトルへの各エントリは、ハッシュバケットに対応し、ノード識別子を記憶する。ベクトルエントリのノード識別子によって識別されるノードが、ベクトルエントリに関連付けられるバケットに名前がハッシュされるすべての資源のマスタとしての役割を果たす。たとえば、ベクトルをＭＡＳＴＥＲ（）と名付けるとする。ノードＮ１の識別子がＭＡＳＴＥＲ（５）に記憶されているとすれば、バケット５にハッシュされる資源はすべて、ノードＮ１上で支配される。
【００５９】
ノードベクトルＭＡＳＴＥＲ（）は、およそ等しい数のエントリをノードの各々に割当てることによって初期的に配置される。この割当を実行する簡単な方法は、第１のベクトルエントリに始まって、各ノードごとにＸ個のノード識別子を記憶することである。Ｘは、ノードの数で除算されるハッシュバケットの数に等しい。たとえば、１００個のハッシュバケットおよび１０個のノードがあるとすれば、第１のノードでの識別子は、ベクトルエントリ１〜１０に記憶され、第２のノードの識別子は、ベクトルエントリ１１〜２０に記憶され、等々である。
【００６０】
エポック変更後、第２のノードベクトルＮＥＷＭＡＳＴＥＲ（）が生成される。加えて、ターゲットバケット数が、エポック変更後のシステムでのノードの数に基づいて上述のとおり計算される。ＮＥＷＭＡＳＴＥＲ（）ベクトルは、初期的に、以下の２つの条件を満たすＭＡＳＴＥＲ（）ベクトルの各エントリに記憶される識別子をＮＥＷＭＡＳＴＥＲ（）にコピーすることによって配置される。この条件とは、（１）識別子がシステム内になおもあるノードについてのものであることと、（２）ノードに既に割当てられているエントリの数がターゲットバケット数よりも少ないこととである。ＮＥＷＭＡＳＴＥＲ（）のこの初期配置の後、ＭＡＳＴＥＲ（ｉ）＝ＮＥＷＭＡＳＴＥＲ（ｉ）などの、値ｉにハッシュされる資源はすべて、即座に利用可能となるであろう。この次に、ＮＥＷＭＡＳＴＥＲ（）への残っている割当てられていないエントリは、Ｘがターゲットバケット数である、各ノードのＸ個の識別子の合計を記憶するようにして、ノード識別子に割当てられる。
【００６１】
ＮＥＷＭＡＳＴＥＲ（）へのエントリがすべて配置された後、ＭＡＳＴＥＲ（ｉ）＜＞ＮＥＷＭＡＳＴＥＲ（ｉ）である値ｉにハッシュされる資源はすべて、リマスタされなければならない。このリマスタリング動作の間、ＭＡＳＴＥＲ（ｉ）＝Ｎａ、ＮＥＷＭＡＳＴＥＲ（ｉ）＝Ｎｂとなるよう、各ノードＮａは、バケットｉにハッシュされる資源のマスタ資源オブジェクトを別のノードＮｂに転送する。加えて、ＭＡＳＴＥＲ（ｉ）＝エポック変更の間失われたノードの識別子、ＮＥＷＭＡＳＴＥＲ（ｉ）＝Ｎａとなるよう、各ノードＮａは、バケットｉにハッシュされる資源のマスタ資源オブジェクトを再構築する。
【００６２】
遅延されたロードバランス
理想的な場合には、資源の支配に関連するロードは、再構成後のシステムでのノード間で均等に分散される。さらに、再構成の間、ロードを均等に分散するのに必要な最小限の数の資源のみが移動される。しかしながら、ロードの均等なバランスをとるために必要な最小限の数の資源をリマスタするとしても、再構成プロセスは、かなりの量のオーバーヘッドを伴い、不当に長い時間期間の間、システムの一部を利用不可能にしてしまう可能性がある。
【００６３】
この発明のある局面に従うと、再構成動作の持続時間は、リマスタして所望のロードバランスを達成する必要があるすべての資源より少ない資源を初期的にリマスタすることによって、低減される。したがって、エポック変更後に起きる初期再構成は、均等にロードのバランスがとれていない。代わりに、初期再構成が行なわれ、システムが一般的に利用可能となった後に、過剰ノードから不足ノードへとバケットを徐々に再割当して、これによって資源を「移動」して、やがてより均等に分散されたロードバランスが達成される。
【００６４】
リマスタリング動作には、ロストマスタリマスタリングと転送マスタリマスタリングとの、２つの一般的なタイプがある。ロストマスタリマスタリングが必要とされるのは、エポック変更の間エポック変更前のそのマスタがシステムから取除かれた資源についてである。資源のロストマスタリマスタリングは、一般的には、既存のノードで資源のマスタ資源オブジェクトを再構築することを伴う。
【００６５】
一方、転送マスタリマスタリングが行なわれるのは、エポック変更前のそのマスタがエポック変更後もシステム内に存在し続ける資源についてである。マスタ資源オブジェクトはエポック変更の間に失われていないため、転送マスタリマスタリングは、資源のマスタ資源オブジェクトが再構築されることを必要としない。
【００６６】
ある実施例に従うと、資源のうちロストマスタリマスタリングを経なければならないもののみが、エポック変更後初期的にリマスタされる。具体的には、エポック変更に応答してバケットからノードへのハッシュ関数を修正して、エポック変更中に失われたノードに対応付けられるバケットのみを初期的に再割当する。好ましくは、現在マスタリングロードが最も低いエポック変更後のノードにこれらのバケットを対応付けるようにして、バケットからノードへのハッシュ関数は修正される。これらのバケットが再割当されたノードは、典型的には、エポック変更中にシステムに新しく加えられたいかなるノードをも含む。
【００６７】
必要なロストマスタリマスタリングのすべてが実行された後、システムはユーザに利用可能となる。システムが利用可能となった後に、さらなる資源を過剰ノードから不足ノードに徐々に移動させてよりバランスのとれたロード分散を達成する。さらに、転送マスタリマスタリング動作は、初期エポック変更後再構成の後に行なわれるものであるが、これはシステムが再び利用不可能とならないようにして行なわれる。
【００６８】
図５を参照すると、これは、この発明の実施例に従ってエポック変更後資源をリマスタするステップを例示するフローチャートである。ステップ５０２で、エポック変更が起きる。ステップ５０４で、エポック変更中に失われたノードに割当てられたバケット（「マスタレスバケット」）を支配するよう不足ノードが選択される。ある実施例に従うと、割当てられたバケットの数が最小である、エポック変更後システムの１つ以上のノードが選択される。典型的には、選択されたバケットは、エポック変更中にシステムに加えられたいかなるノードも含むであろう。
【００６９】
ステップ５０６で、バケットからノードへの対応付が修正され、マスタレスバケットに、ステップ５０４で選択されたノードが割当てられる。ステップ５０８で、ロストマスタリマスタリングが実行される。具体的には、再対応付されたバケットにハッシュされる名前を有する資源のマスタ資源オブジェクトが、その新しいマスタノード上で再構築される。たとえば、資源名Ｒ１が、ノードＮ１に再対応付されたバケットＢ１にハッシュされるならば、Ｒ１のマスタ資源オブジェクトはＮ１上で再構築される。
【００７０】
ステップ５０４、５０６および５０８は、この発明の実施例に従ってエポック変更後に実行された初期再構成を構成する。ステップ５１０〜５１８は、再構成後資源移動に関わるステップを例示し、これは、エポック変更後に存在するノード間でのより均等なロードバランスのために、初期再構成後に行なわれる。多くの過剰ノードが、再構成後資源移動に同時的に関与し得る。さらに、そのような再構成後移動は、徐々に起こればよく、初期再構成後に直ちに始まるかまたは起きる必要はない。
【００７１】
ステップ５１０で、過剰ノードは不足ノードを選択し、これに、過剰ノードに現在属しているバケットの１つ以上が再割当されるようになる。説明のために、単一の「ターゲット」バケットが、選択された不足ノードに再割当されるものと仮定する。ステップ５１２で、過剰ノードは、バケット転送メッセージを、選択された不足ノードに送信して、ターゲットバケットが不足ノードに再割当されることを不足ノードに知らせる。ステップ５１４で、過剰ノードは、選択された不足ノードに、ターゲットバケットに属する資源のマスタノードオブジェクト情報を送信する。
【００７２】
ステップ５１６で、不足ノードは、システム内の他のノードに、不足バケットがターゲットバケットの新しいマスタとなったことを示すメッセージをブロードキャストする。ステップ５１８で、ノードは、そのバケットからノードへの対応付を更新し、ターゲットバケットがメッセージを送信した不足ノードに割当てられたことを示すことによって応答する。
【００７３】
重要なことには、再構成後資源移動が行なわれている間にもシステムは利用可能なままであり得る。ある実施例に従うと、移動されている資源へのアクセスを要求するプロセスさえも実行し続けることが可能である。たとえば、ノードＮ１上のプロセスがノードＮ２からノードＮ３へと移動されつつある資源を要求すると仮定する。資源名は、バケットからノードへの対応付に従えばＮ３であるが依然としてＮ２になおも割当てられているバケットにハッシュされる。したがって、プロセスはアクセス要求をＮ２に送信する。もしＮ２が当該資源のマスタ資源オブジェクトをまだ転送していなければ、Ｎ２は通常どおり要求をサービスし得る。もしＮ２がマスタ資源オブジェクトをＮ３に既に転送していれば、Ｎ２は要求をＮ３に転送する。資源のマスタ資源オブジェクトがＮ３にまだ到着していなかったとしても、要求は、マスタ資源オブジェクトの後にＮ３に到着するであろう。なぜなら、Ｎ２からのデータは、これがＮ２から送信されるのと同じ順でＮ３に到着するからである。マスタ資源オブジェクトと要求とのどちらもがＮ３に到着すると、Ｎ３は要求をサービスし得る。
【００７４】
この発明のある局面に従うと、資源を別のノードに転送しているノード（上記の例ではＮ２）は、それが転送しているマスタ資源オブジェクトの自己のバージョンを引続き維持可能である。転送ノードで維持されるマスタ資源オブジェクトのバージョンは、バックアップとして機能する。したがって、もしマスタ資源オブジェクトがそこに転送されつつあるノードに障害が発生しても、バックアップマスタ資源オブジェクトを使用して資源へのアクセスを制御することが可能である。受信ノードが、それが新しいマスタであるということをブロードキャストするまで、転送ノード上にバックアップマスタ資源オブジェクトを維持することに関連するオーバーヘッドは低減されるが、これはすべてのアクセス要求がいずれにせよ転送ノードに到着し（かつこれによって転送される）ことによるものである。受信ノードが、それが新しいマスタであるということをブロードキャストした後、転送ノードは、バックアップマスタ資源オブジェクトの維持を停止してもよいし、マスタ資源オブジェクトを維持し続けてもよい。もし転送ノードがマスタ資源オブジェクトのバックアップバージョンを維持し続ければ、これは、新しいマスタノードが、正確にバックアップを維持する目的で古いマスタノードにアクセス要求を転送することに関連するさらなるオーバーヘッドを招くことになる。
【００７５】
ある実施例に従うと、バケットに関連付けられるマスタ資源オブジェクトがノード間で移動されている間にエポック変更が起きると、そのバケットはマスタレスバケットとして扱われる。したがって、バケットにマスタが再割当され、エポック変更後の初期再構成の間、マスタ資源オブジェクトは再構築される。
【００７６】
計画されたシャットダウン
この発明のある実施例に従うと、あるノードがエポック変更中にシャットダウンする予定とわかっているとき、図５に示すステップ５１０〜５１８がエポック変更前に行なわれる。たとえば、ノードＮ２がシャットダウンする予定とわかれば、ノードＮ２は、Ｎ２に現在割当てられているバケットに関連付けられたマスタ資源オブジェクトを、シャットダウンされない予定の１つ以上の他のノードに転送する。
【００７７】
このプロセスの間、もしＮ２が、マスタ資源オブジェクトが既に転送されている資源に関連付けられるアクセス要求を受信すれば、Ｎ２はその要求を適切なノードに転送する。Ｎ２は、先にＮ２に割当てられていたバケットのすべてに関連付けられるマスタ資源オブジェクトを転送した後、Ｎ２は、すべての受信ノードがその新しいバケット割当を示すメッセージをブロードキャストするのを待つ。すべてのブロードキャストメッセージが送信された後、Ｎ２はもはやいかなるバケットをも割当てられていないので、Ｎ２はシャットダウンしてもよい。この状況下でのＮ２のシャットダウンは、ロストマスタリマスタリングに関連するオーバーヘッドを招くことはない。
【００７８】
前記の明細書においては、この発明はその特定の実施例を参照して記載された。しかしながら、この発明のより広い精神および範囲から逸脱することなしに、これにさまざまな変形および変更をなし得ることは明らかであろう。したがって、この明細書および図面は、限定的なものではなく例示的なものとみなされるべきである。
【図面の簡単な説明】
【図１】分散ロックマネージャを有する複数ノードのシステムのブロック図である。
【図２】この発明の実施例が実施可能であるコンピュータシステムのブロック図である。
【図３】この発明の実施例を採用して複数ノードのシステム内で資源がどこに支配されるべきかを決定するシステムを例示するブロック図である。
【図４】エポック変更後の図３に示すシステムのブロック図である。
【図５】この発明の実施例に従うエポック変更後のシステムを再構成するステップを例示するフローチャートである。

Claims

複数ノードのシステムでのノードに対する資源を支配するためのコンピュータで実行される方法であって、前記コンピュータが以下のステップを実行し、前記以下のステップは、
１組の資源の中の各資源について、
第１のハッシュ関数を用いて特定のバケットに資源を対応付けるステップと、
第２のハッシュ関数を用いて特定のノードに特定のバケットを対応付けるステップと、
前記資源のマスタとなるよう前記特定のノードを選択するステップとによって資源を支配するノードを選択するステップと、
前記第１のハッシュ関数を変更することなしに前記第２のハッシュ関数を変更することによってエポック変更に応答するステップとを含み、
前記エポック変更に応答するステップでは、前記エポック変更後に初期再構成を実行し、前記初期再構成は、エポック変更後に存在するノードにエポック変更中に取除かれたノードに対応付けられた１組のバケットを再対応付するステップを含み、さらに、前記以下のステップは、
前記初期再構成を実行した後、
複数ノードのシステムを、要求の受信および処理が可能にするステップと、
複数ノードのシステムで要求の受信および処理が可能である一方で、不足ノードに割当てられたバケットの数がターゲットバケット数に等しくなるまで過剰ノードに現在対応付けられている１つ以上のバケットを不足ノードに移動するステップとを実行するステップとを含み、
エポック変更は、複数ノードのシステムにおけるノードの数の変更であり、
不足ノードは、現在割当てられている範囲がターゲットバケット数より少ない数のバケットに及ぶ複数ノードのシステムにおけるノードであり、
過剰ノードは、現在割当てられている範囲がターゲットバケット数より大きい数のバケットに及ぶ複数ノードのシステムにおけるノードであり、
ターゲットバケット数は、バケットを複数ノードのシステムにおけるノード間で均等に分散するために複数ノードのシステムにおける各ノードが持たなければならないバケットの数である、方法。
エポック変更前に、第１の数のノードを用いて前記資源の組からの資源を支配し、
エポック変更後に、第２の数のノードを用いて前記資源の組からの資源を支配し、
前記方法は前記第１のハッシュ関数を用いてある数のバケットに資源をハッシュするステップを含み、前記ある数のバケットは前記第１の数および前記第２の数のどちらよりも大きい、請求項１に記載の方法。
前記第２のハッシュ関数はバケットからノードへの対応付情報を用いて実現され、
前記第２のハッシュ関数を変更するステップは、前記バケットからノードへの対応付情報のうち１つ以上のバケットからノードへの対応付を変更するステップを含む、請求項１に記載の方法。
複数個のノードの各ノードがバケットからノードへの対応付情報のローカルコピーを維持し、
前記バケットからノードへの対応付情報のうち１つ以上のバケットからノードへの対応付を変更するステップは、前記複数個のノードの各々で並列に実行される、請求項３に記載の方法。
前記１つ以上のバケットからノードへの対応付を変更するステップは、エポック変更前のバケットからノードへの対応付およびいくつのノードがエポック変更後に資源を支配するよう利用可能であるかに基づいて確定結果を生成する１組の規則を適用することによって実行される、請求項４に記載の方法。
１つ以上のバケットからノードへの対応付を変更するステップは、
いくつのバケットが前記第１のハッシュ関数に関連付けられるかおよびいくつのノードがエポック変更後に資源を支配するよう利用可能であるかに基づいてターゲットバケット数を決定するステップと、
もし特定のノードがエポック変更後に資源を支配するよう利用可能であれば、エポック変更後に、
もしターゲットバケット数よりも多いバケットがエポック変更前に特定のノードに対応付けられていたならば、バケットからノードへの情報を修正してエポック変更前に特定のノードに対応付けられていた１つ以上のバケットを異なったノードに対応付けるステップと、
もしターゲットバケット数より少ないバケットがエポック変更前に特定のノードに対応付けられていたならば、バケットからノードへの情報を修正してエポック変更前に異なったノードに対応付けられていた１つ以上のバケットを特定のノードに対応付けるステップとを実行するステップとを含む、請求項３に記載の方法。
移動するステップは、
過剰ノードが前記１つ以上のバケットに対応付けられる資源を支配するために必要な資源情報を不足ノードに送信するステップと、
過剰ノードが資源情報を送信し始めた後、前記資源に関する要求を過剰ノードにおいて受信するステップと、
前記資源情報を送信した後に、過剰ノードが前記要求を前記不足ノードに転送するステップとを含む、請求項１に記載の方法。
不足ノードは、前記不足ノードが前記１つ以上のバケットに対応付けられる前記資源のマスタであることを示すメッセージをノードの組にブロードキャストするステップと、
前記ノードの組のノードは、前記第２のハッシュ関数を変更して前記１つ以上のバケットを前記不足ノードに対応付けることによって前記メッセージに応答するステップとを含む、請求項７に記載の方法。
複数ノードのシステムでのノードに対する資源を支配するためのプログラムを担持するコンピュータ読出可能媒体であって、前記プログラムは、コンピュータに以下のステップを実行させ、前記以下のステップは、
１組の資源の中の各資源について、
第１のハッシュ関数を用いて特定のバケットに資源を対応付けるステップと、
第２のハッシュ関数を用いて特定のノードに特定のバケットを対応付けるステップと、
前記資源のマスタとなるよう前記特定のノードを選択するステップとによって資源を支配するノードを選択するステップと、
前記第１のハッシュ関数を変更することなしに前記第２のハッシュ関数を変更することによってエポック変更に応答するステップとを実行する命令を含み、
前記エポック変更に応答するステップでは、前記エポック変更後に初期再構成を実行し、前記初期再構成は、エポック変更後に存在するノードにエポック変更中に取除かれたノードに対応付けられた１組のバケットを再対応付するステップを含み、さらに、
前記初期再構成を実行した後、
複数ノードのシステムを、要求の受信および処理が可能にするステップと、
複数ノードのシステムで要求の受信および処理が可能である一方で、不足ノードに割当てられたバケットの数がターゲットバケット数に等しくなるまで過剰ノードに現在対応付けられている１つ以上のバケットを不足ノードに移動するステップとを実行するステップを含み、
エポック変更は、複数ノードのシステムにおけるノードの数の変更であり、
不足ノードは、現在割当てられている範囲がターゲットバケット数より少ない数のバケットに及ぶ複数ノードのシステムにおけるノードであり、
過剰ノードは、現在割当てられている範囲がターゲットバケット数より大きい数のバケットに及ぶ複数ノードのシステムにおけるノードであり、
ターゲットバケット数は、バケットを複数ノードのシステムにおけるノード間で均等に分散するために複数ノードのシステムにおける各ノードが持たなければならないバケットの数である、コンピュータ読出可能媒体。
エポック変更前に、第１の数のノードを用いて前記資源の組からの資源を支配し、
エポック変更後に、第２の数のノードを用いて前記資源の組からの資源を支配し、
コンピュータ読出可能媒体は、前記第１のハッシュ関数を用いてある数のバケットに資源をハッシュするステップを実行する命令を含み、前記ある数のバケットは前記第１の数および前記第２の数のどちらよりも大きい、請求項９に記載のコンピュータ読出可能媒体。
前記第２のハッシュ関数はバケットからノードへの対応付情報を用いて実現され、
前記第２のハッシュ関数を変更するステップは、前記バケットからノードへの対応付情報のうち１つ以上のバケットからノードへの対応付を変更するステップを含む、請求項９に記載のコンピュータ読出可能媒体。
複数個のノードの各ノードがバケットからノードへの対応付情報のローカルコピーを維持し、
前記バケットからノードへの対応付情報のうち１つ以上のバケットからノードへの対応付を変更するステップは、前記複数個のノードの各々で並列に実行される、請求項１１に記載のコンピュータ読出可能媒体。
前記１つ以上のバケットからノードへの対応付を変更するステップは、エポック変更前のバケットからノードへの対応付およびいくつのノードがエポック変更後に資源を支配するよう利用可能であるかに基づいて確定結果を生成する１組の規則を適用することによって実行される、請求項１２に記載のコンピュータ読出可能媒体。
１つ以上のバケットからノードへの対応付を変更するステップは、
いくつのバケットが前記第１のハッシュ関数に関連付けられるかおよびいくつのノードがエポック変更後に資源を支配するよう利用可能であるかに基づいてターゲットバケット数を決定するステップと、
もし特定のノードがエポック変更後に資源を支配するよう利用可能であれば、エポック変更後に、
もしターゲットバケット数よりも多いバケットがエポック変更前に特定のノードに対応付けられていたならば、バケットからノードへの情報を修正してエポック変更前に特定のノードに対応付けられていた１つ以上のバケットを異なったノードに対応付けるステップと、
もしターゲットバケット数より少ないバケットがエポック変更前に特定のノードに対応付けられていたならば、バケットからノードへの情報を修正してエポック変更前に異なったノードに対応付けられていた１つ以上のバケットを特定のノードに対応付けるステップとを実行するステップとを含む、請求項１１に記載のコンピュータ読出可能媒体。
移動するステップは、
過剰ノードが前記１つ以上のバケットに対応付けられる資源を支配するために必要な資源情報を不足ノードに送信するステップと、
過剰ノードが資源情報を送信し始めた後、前記資源に関する要求を過剰ノードにおいて受信するステップと、
前記資源情報を送信した後に、過剰ノードが前記要求を前記不足ノードに転送するステップとを含む、請求項９に記載のコンピュータ読出可能媒体。
不足ノードは、前記不足ノードが前記１つ以上のバケットに対応付けられる前記資源のマスタであることを示すメッセージをノードの組にブロードキャストするステップと、
前記ノードの組のノードは、前記第２のハッシュ関数を変更して前記１つ以上のバケットを前記不足ノードに対応付けることによって前記メッセージに応答するステップとを実行する命令をさらに含む、請求項１５に記載のコンピュータ読出可能媒体。