JP5845298B2 - ノードおよびプログラム - Google Patents
ノードおよびプログラム Download PDFInfo
- Publication number
- JP5845298B2 JP5845298B2 JP2014040471A JP2014040471A JP5845298B2 JP 5845298 B2 JP5845298 B2 JP 5845298B2 JP 2014040471 A JP2014040471 A JP 2014040471A JP 2014040471 A JP2014040471 A JP 2014040471A JP 5845298 B2 JP5845298 B2 JP 5845298B2
- Authority
- JP
- Japan
- Prior art keywords
- data
- node
- nodes
- predetermined direction
- acquisition unit
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Images
Landscapes
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Description
本発明は、複数サーバを並べたクラスタ構成において、分散システムを構成するサーバの追加や削除が発生した際に、データを保持している可能性があるサーバを特定するノードおよびプログラムに関する。
近年、クラウドコンピューティングの隆盛に伴い、多量のデータの処理や保持を効率的に行うことが求められている。そこで、複数のサーバを協調動作させることにより効率的な処理を実現する分散処理技術が発展している。
分散処理を行う際には、クラスタを構成する各サーバ（以下、「ノード」と称する。）が担当するデータを決定する必要がある。このとき、クラスタ全体での処理能力を高めるためには、各ノードが担当するデータ数（データ量）は平均化されていることが望ましい。
代表的なデータの管理手法として、各データのｋｅｙをハッシュ関数にかけた値（以下、「ｈａｓｈ（ｋｅｙ）」と称する。）をノード数Ｎで割った余り、すなわち「ｈａｓｈ（ｋｅｙ） ｍｏｄ Ｎ」を番号として持つノードがデータを管理する手法がある。この場合、各ノードに事前に「０」から「Ｎ−１」までの番号を割り当てていることが前提となる。このような管理手法を用いた場合、ノードが追加・離脱すると、Ｎの値が変化して、多くのデータについて、そのデータの保存を担当するノードが変更になるため、担当するデータを再配置することが必要になる。
そこで、ノードの追加・離脱に伴い担当するノードが変更になるデータ数を約１／Ｎに抑える方法として、コンシステントハッシュ（Consistent Hashing）法（非特許文献１参照）を用いた管理手法がある。このコンシステントハッシュ法は、Amazon Dynamo（非特許文献１参照）等において用いられている。
このコンシステントハッシュ法を用いたデータ管理手法では、ノードとデータの双方にＩＤ（IDentifier）を割り当てる。そして、データのＩＤから閉じたＩＤ空間を時計回りに辿った場合に最初に遭遇するノードをそのデータの担当とする。ノードに対するＩＤの与え方の例としては、ＩＰアドレスをハッシュ関数にかけた値（hash（ＩＰアドレス））が挙げられる。
クラスタ構成の分散システムでは、各ノードの処理性能が等しい場合には、各ノードが担当するデータ量を等しくする、すなわち、コンシステントハッシュ法のＩＤ空間における、ノード間の距離（以下、「ノードの担当範囲」または「ハッシュＩＤ範囲」と称する。）を等しくすることが望ましい。ノード間距離を等しく設定しても、ノードの参加や離脱が発生すると偏りが生じる。その影響を分散させるために、各ノードに仮想的に複数のＩＤ（仮想ＩＤ）を持たせる手法が用いられている（非特許文献１参照）。各ノードが複数の仮想ＩＤを持つことで、仮想ＩＤ毎の担当範囲は異なっていても、大数の法則に従いノードの担当範囲は平均化される。
図１５は、複数のノードをクラスタ構成にした場合に、各ノードをコンシステントハッシュのＩＤ空間（環状のＩＤ空間）上に配置し、データを管理する手法（以下、「コンシステントハッシュ法によるデータ管理手法」と称する。）を説明するための図である（特許文献２参照）。なお、ここで、データの管理とは、各ノードが行うデータの取得や更新、データの複製を行うこと等を意味する。
図１５に示すように、コンシステントハッシュ法では、各ノードがコンシステントハッシュのＩＤ空間（以下、単に「ＩＤ空間」と称する場合がある。）にマッピングされる。そして、各ノードは、図１５に示すように、自身が担当するハッシュＩＤの範囲（「ハッシュＩＤ範囲」）を持っている。あるデータを取得する際は、データを一意に特定するｋｅｙ情報をハッシュ関数にかけ、導出されたコンシステントハッシュのＩＤ空間上の位置（図１５においては、黒丸（●）で表示）から所定の方向（図１５では時計回り）に進んで最初に遭遇するノードからデータを取得する（図１５においては、矢印（→）で表示）。例えば、図１５において、データＡについては、ＩＤ空間上を時計回りに進み最初に遭遇したノード「１」が担当となる。なお、更新時も同様にノードを特定する。
また、複製データは、ＩＤ空間上で時計回り（若しくは反時計回り）に隣のノードに作成する（冗長数が「２」の場合）。図１５では、ノード「１」においてデータＡの更新を行った場合、ノード「２」にデータＡの複製を作成する。このようにすることにより、ノード「１」が故障等の理由でクラスタから離脱しても、データへの問い合わせはデータＡの複製を持つノード「２」に振り分けられるため、ノード「２」において処理を継続することが可能となる。
次に、コンシステントハッシュ法によるデータ管理手法において、クラスタに新たなノードが参加（追加）する場合の動作について説明する。
図１６は、コンシステントハッシュのＩＤ空間上に、新たにノードが参加した場合の動作例を説明するための図である。
図１６は、コンシステントハッシュのＩＤ空間上に、新たにノードが参加した場合の動作例を説明するための図である。
図１６においては、図１５に示すノードの配置において、ノード「１」とノード「４」との間に、ノード「５」が新たに配置された例を示している。
コンシステントハッシュのＩＤ空間にノード「５」が参加した後、ノード「５」がデータを保持するハッシュＩＤ範囲に位置するデータの問い合わせがあった場合、参加直後のノード「５」はデータを持っていないため、ノード「５」の参加以前に該当データを担当していたノード「１」からデータを引き継いで処理を行う。その後、ノード「５」はノード「４」の複製データ（図１６においては、「データＤの複製」と表記。）を保持し、ノード「１」はノード「４」のハッシュＩＤ範囲のデータの複製（「データＤの複製」）を保持する必要がなくなるため、破棄を行う。また、ノード「２」は、ノード「１」のハッシュＩＤ範囲ではなくなった「データＡの複製」を保持する必要がなくたるため、破棄を行う。以降は、図１５の複製作成処理と同様に動作する。
コンシステントハッシュのＩＤ空間にノード「５」が参加した後、ノード「５」がデータを保持するハッシュＩＤ範囲に位置するデータの問い合わせがあった場合、参加直後のノード「５」はデータを持っていないため、ノード「５」の参加以前に該当データを担当していたノード「１」からデータを引き継いで処理を行う。その後、ノード「５」はノード「４」の複製データ（図１６においては、「データＤの複製」と表記。）を保持し、ノード「１」はノード「４」のハッシュＩＤ範囲のデータの複製（「データＤの複製」）を保持する必要がなくなるため、破棄を行う。また、ノード「２」は、ノード「１」のハッシュＩＤ範囲ではなくなった「データＡの複製」を保持する必要がなくたるため、破棄を行う。以降は、図１５の複製作成処理と同様に動作する。
また、ノードの参加または離脱後のＩＤ空間に従ったデータ配置への置き換えを行うデータの再配置を一度に実行すると、新たに参加したノード「５」の負荷が高くなり通常サービスに影響を及ぼす可能性がある。このため、データに対する処理が発生したタイミングや、負荷を調整しながらバックグラウンドで処理を行うことが望ましい。
クラスタ構成の分散システムでは、トラヒックや利用者数の変化に合わせて、クラスタを構成するサーバ数を調整することで、クラスタの処理能力を柔軟に変更可能であるという利点がある。
クラスタ構成の分散システムでは、トラヒックや利用者数の変化に合わせて、クラスタを構成するサーバ数を調整することで、クラスタの処理能力を柔軟に変更可能であるという利点がある。
コンシステントハッシュ法によるデータ管理手法は、クラスタを構成するノードの追加や離脱に伴うデータの移行が全データに対する一部のデータに限られるため、クラスタ構成の動的な変更（ノードの追加・離脱）が頻繁に起こるシステムに対して有効である。また、クラスタを構成するノードの障害に備えて、原本データを保持するノード以外の１つ以上のノードに対して複製データを保持させることで、耐故障性を高めている。
Giuseppe DeCandia，et al.，"Dynamo: Amazon’s Highly Available Key-value Store"， SOSP’07, October 14-17, 2007, Stevenson, Washington, USA，［online］，［平成26年2月20日検索］，インターネット<ＵＲＬ:http://www.allthingsdistributed.com/files/amazon-dynamo-sosp2007.pdf>
David karger, et al.,"Consistent Hashing and Random Trees:Distributed Caching Protocols for Relieving Hot Spots on the World Wide Web"，［online］，1997，ACM，［平成26年2月20日検索］，インターネット<ＵＲＬ:http://www.akamai.com/dl/technical_publications/ConsistenHashingandRandomTreesDistributedCachingprotocolsforrelievingHotSpotsontheworldwideweb.pdf>
ところで、クラスタを構成するノードの参加または離脱があった場合、データを探索し、クラスタを構成する他ノードから取得して処理を行う必要がある。この場合、クラスタへのノードの参加または離脱からバックグラウンドで行われるデータ再配置完了までの間、データを保持しているノードとデータへの問い合わせを受けるノードが異なる可能性がある。この際、問い合わせを受けたノードは、図１６を参照して述べたようにデータを引き継ぎ処理を行うこととなる。しかしながら、問い合わせ先が限定できない場合、クラスタを構成する全ノードに対する問い合わせが必要となり、データを取得する負荷が信号処理に影響を与えるおそれがある。また、データを保持している可能性のあるノードが特定できない場合には、全ノードに対してデータ有無を問い合わせるまでデータの有無を正確に判定することはできない。なお、動的構成変更（動的にノードが参加または離脱）が発生した場合にも、確実にデータ一貫性を担保したい場合には、上記のような問い合わせが必要になる。
このような背景を鑑みて本発明がなされたのであり、本発明は、クラスタを構成するノードの参加または離脱があった場合、全ノードに対する問い合わせを不要にしつつデータの一貫性を保持し、データを保持している可能性があるノードを効率良く探索することを可能とするノードおよびプログラムを提供することを課題とする。
プログラムを提供することを課題とする。
プログラムを提供することを課題とする。
前記した課題を解決するため、請求項１に記載の発明は、環状のＩＤ（IDentifier）空間に、処理対象の複数のデータのＩＤ、および、クラスタを構成し前記データに関するリクエストを処理する複数のノードのＩＤが、割り当てられ、前記ＩＤ空間において前記データのＩＤから所定方向回りに辿って最初に遭遇した前記ノードまでの間に位置する前記データを当該ノードが原本データとして保持するとともに、前記クラスタ内の自身以外の他のノードに前記原本データの複製である複製データを保持させる分散システムの前記ノードであって、メッセージ処理に必要なデータを保持していなかった場合、前記データを保持している可能性のあるノードを特定し、他のノードに要求してデータを取得するデータ取得部と、ノードの参加または離脱に伴い、自身が保持しているデータのうち、別のノードへと移行する、または、新たに複製データを配置するデータを特定して、当該特定したデータを再冗長化・再配置するデータ再冗長化・再配置部と、を備え、前記データ取得部は、前記原本データを持っているノードに信号を振り分けられる状況であるデータ再冗長化・再配置完了までに発生したノード参加・離脱台数の合計の値ΔＮを保持し、前記データのＫｅｙ情報をハッシュ値演算した結果であるデータＩＤを算出するととともに、算出した前記データＩＤと自身のノードＩＤの間のノード数αを算出し、前記値ΔＮと前記ノード数αの比較結果を基に、ＩＤ空間上の自身のノードＩＤから前記値ΔＮ台分のノードに対して問い合わせてデータを取得することを特徴とする。
このようにすることで、クラスタを構成するノードの参加または離脱があった場合、全ノードに対する問い合わせを不要にしつつデータの一貫性を保持し、データを保持している可能性があるノードを効率良く探索することができる。
請求項２に記載の発明は、前記データ取得部が、α＝０の場合、前記ＩＤ空間上で前記複製データが作成される方向である所定方向回りに前記値ΔＮ台分探索してデータを取得し、α≦ΔＮの場合、前記所定方向回りに前記値ΔＮ台分探索し、前記所定方向回りと逆方向にα台分探索してデータを取得し、α＞ΔＮの場合、前記所定方向回りと、当該所定方向回りと逆方向とにそれぞれ前記値ΔＮ台分探索してデータを取得することを特徴とする。
このようにすることで、クラスタを構成するノードの参加または離脱があった場合、全ノードに対する問い合わせを不要にしつつデータの一貫性を保持し、データを保持している可能性があるノードを効率良く探索することができる。
請求項３に記載の発明は、前記データ取得部が、前記所定方向回りと逆方向の前記値ΔＮ台分の問い合わせについて、自身のノードＩＤと前記データＩＤの間に存在するノードに対してのみ行うことを特徴とする。
このようにすることで、クラスタを構成するノードの参加または離脱があった場合、全ノードに対する問い合わせを不要にしつつデータの一貫性を保持し、データを保持している可能性があるノードを効率良く探索することができる。また、所定方向回りと逆方向にΔＮ台分の問い合わせについては、自身のノードＩＤとデータＩＤの間に存在するノードに対してのみ行えばよい。
請求項４に記載の発明は、前記データ取得部が、前記原本データを保持していない場合において、前記複製データの保持の有無を判定し、前記複製データを保持している場合、自身のノードＩＤのＩＤ空間上の前記所定方向回りと逆方向に前記値ΔＮ台分のノードに対して問い合わせてデータを取得することを特徴とする。
このようにすることで、原本データなしで複製データありの場合、所定方向回りと逆方向のみにΔＮ台分問い合わせればよく、問い合わせ範囲を減らすことができ、データを保持している可能性があるノードをより効率良く探索することができる。
請求項５に記載の発明は、前記データ取得部が、前記値ΔＮと前記ノード数αの比較結果を基に、α≦ΔＮの場合、前記所定方向回りと逆方向に前記α台分探索してデータを取得し、α＞ΔＮの場合、前記所定方向回りと逆方向に前記値ΔＮ台分探索してデータを取得することを特徴とする。
このようにすることで、原本データなしで複製データありの場合、所定方向回りと逆方向のみにΔＮ台分問い合わせればよく、問い合わせ範囲を減らすことができ、データを保持している可能性があるノードをより効率良く探索することができる。また、所定方向回りと逆方向にΔＮ台分の問い合わせについては、自身のノードＩＤとデータＩＤの間に存在するノードに対してのみ行えばよい。
請求項６に記載の発明は、コンピュータを請求項１ないし請求項５のいずれか１項に記載のノードとして機能させるためのプログラムとした。
これによれば、このようなプログラムを実装したコンピュータを本発明のノードとして機能させることができる。
本発明によれば、クラスタを構成するノードの参加または離脱があった場合、全ノードに対する問い合わせを不要にしつつデータの一貫性を保持し、データを保持している可能性があるノードを効率良く探索することを可能とするノードおよびプログラムを提供することができる。
（第１の実施形態）
次に、本発明を実施するための形態（以下、「本実施形態」と称する。）について説明する。
以下の説明において、複製データはコンシステントハッシュのＩＤ空間上で時計回りのノードに作成するものとする。したがって、ノード検索において、右回りとはＩＤ空間上時計回り、左周りとはＩＤ空間上反時計回りを示す。これに従い、右側とは自ノードからみてＩＤ空間上の右側を、左側とは自ノードからみてＩＤ空間上の左側を示す。なお、右側、左側を、右隣、左隣、また単に右、左と記述する場合がある。
次に、本発明を実施するための形態（以下、「本実施形態」と称する。）について説明する。
以下の説明において、複製データはコンシステントハッシュのＩＤ空間上で時計回りのノードに作成するものとする。したがって、ノード検索において、右回りとはＩＤ空間上時計回り、左周りとはＩＤ空間上反時計回りを示す。これに従い、右側とは自ノードからみてＩＤ空間上の右側を、左側とは自ノードからみてＩＤ空間上の左側を示す。なお、右側、左側を、右隣、左隣、また単に右、左と記述する場合がある。
[分散システムの全体構成]
まず、本発明の第１の実施形態に係るノード１を含む分散システム１０００の全体構成について説明する。
図１は、本発明の第１の実施形態に係るノード１を含む分散システム１０００の全体構成を示す図である。
まず、本発明の第１の実施形態に係るノード１を含む分散システム１０００の全体構成について説明する。
図１は、本発明の第１の実施形態に係るノード１を含む分散システム１０００の全体構成を示す図である。
この分散システム１０００は、各クライアント２からのメッセージを受け付けるロードバランサ３と、振り分け装置４と、クラスタを構成する複数のノード１とを含んで構成される。ロードバランサ３は、クライアント２からのメッセージを単純なラウンドロビン法等により各振り分け装置４に振り分ける。振り分け装置４は、受信したメッセージを、例えば、コンシステントハッシュ法等に基づき、各ノード１に振り分ける。各ノード１では、メッセージ処理を行い、クライアント２にサービスを提供する。
分散システム１０００のノード１は、コンシステントハッシュのＩＤ空間に、処理対象の複数のデータのＩＤ、および、クラスタを構成しデータに関するリクエストを処理する複数のノードのＩＤが、割り当てられ、ＩＤ空間においてデータのＩＤから所定方向回りに辿って最初に遭遇したノードまでの間に位置するデータを当該ノードが原本データとして保持するとともに、クラスタ内の自身以外の他のノードに原本データの複製である複製データを保持させる。
図１においては、振り分け装置４とノード１とを別装置として記載したが、同一サーバ上で別々の機能として動作させることも可能である。また、振り分け装置４も、図１に示すように、クラスタ構成をとることができる。さらに、ロードバランサ３が存在せず、クライアント２から任意の振り分け装置４にメッセージを送信することも可能である。
<処理概要>
一般に、データは他のノード（サーバ）に一定ルールに従って複製してある。ノードの参加または離脱が起きた時、原本データと複製データとの一貫性を保つために、データの移動等（再配置）が行われる。その最中に、データアクセス（問い合わせ）を受けた場合に、そのデータを保持するサーバを特定するために全ノードにデータ有無を問い合わせる事態が発生する場合があり、時間がかかったり、または、負荷が高くなってしまう。
本発明の第１の実施形態に係るノード１は、データ有無を問い合わせるサーバの範囲を限定するようにする。具体的には、最初に問い合わせを受けたノードから、高々、参加または離脱されたノードの台数ΔＮ台分左右（データおよびノードのＩＤの空間上におけるノード群の順序におけるΔＮ台分の左右）に問い合わせる。
このようにすることにより、コンシステントハッシュ法を用いたクラスタシステムにおいて、データを保有するノードを効率よく探すことが可能となる。
一般に、データは他のノード（サーバ）に一定ルールに従って複製してある。ノードの参加または離脱が起きた時、原本データと複製データとの一貫性を保つために、データの移動等（再配置）が行われる。その最中に、データアクセス（問い合わせ）を受けた場合に、そのデータを保持するサーバを特定するために全ノードにデータ有無を問い合わせる事態が発生する場合があり、時間がかかったり、または、負荷が高くなってしまう。
本発明の第１の実施形態に係るノード１は、データ有無を問い合わせるサーバの範囲を限定するようにする。具体的には、最初に問い合わせを受けたノードから、高々、参加または離脱されたノードの台数ΔＮ台分左右（データおよびノードのＩＤの空間上におけるノード群の順序におけるΔＮ台分の左右）に問い合わせる。
このようにすることにより、コンシステントハッシュ法を用いたクラスタシステムにおいて、データを保有するノードを効率よく探すことが可能となる。
<ノード>
次に、本発明の第１の実施形態に係る分散システム１０００を構成するノード１について、具体的に説明する。
図２は、本発明の第１の実施形態に係るノード１の構成例を示す機能ブロック図である。
ノード１は、図１に示したように、各振り分け装置４と通信可能に接続されるとともに、クラスタを構成する自身以外の他のノード１とも通信可能に接続される。そして、クライアント２からのメッセージを受信し、サービスを提供する。また、このノード１は、自身が原本データとして保持する情報を、後記する複製データの配置のための所定の条件を満たす他のノード１に対して送信することにより、他のノード１に複製データを保持させる。
このノード１は、図２に示すように、制御部１０と、入出力部１１と、記憶部１２とを含んで構成される。
次に、本発明の第１の実施形態に係る分散システム１０００を構成するノード１について、具体的に説明する。
図２は、本発明の第１の実施形態に係るノード１の構成例を示す機能ブロック図である。
ノード１は、図１に示したように、各振り分け装置４と通信可能に接続されるとともに、クラスタを構成する自身以外の他のノード１とも通信可能に接続される。そして、クライアント２からのメッセージを受信し、サービスを提供する。また、このノード１は、自身が原本データとして保持する情報を、後記する複製データの配置のための所定の条件を満たす他のノード１に対して送信することにより、他のノード１に複製データを保持させる。
このノード１は、図２に示すように、制御部１０と、入出力部１１と、記憶部１２とを含んで構成される。
入出力部１１は、振り分け装置４や、自身以外の他のノード１との間の情報の入出力を行う。また、この入出力部１１は、通信回線を介して情報の送受信を行う通信インタフェースと、不図示のキーボード等の入力手段やモニタ等の出力手段等との間で入出力を行う入出力インタフェースとから構成される。
制御部１０は、ノード１全体の制御を司り、ノード識別子管理部１０１、メッセージ処理部１０２、データ取得部１０３、死活監視部１０４、及びデータ再冗長化・再配置部１０５を含んで構成される。なお、この制御部１０は、例えば、記憶部１２に格納されたプログラムをＣＰＵ（Central Processing Unit）がＲＡＭ（Random Access Memory）に展開し実行することで実現される。
<ノード識別子管理部>
ノード識別子管理部１０１は、クラスタへのノードの追加や離脱が発生した際に、クラスタを構成するノードの識別子情報（コンシステントハッシュ法ではＩＤ空間上のノードの情報一覧）を更新し、ノード識別子管理テーブル１００として管理する。
なお、ノード識別子管理部１０１においてノード識別子を付与することも可能であるし、他のノードや外部システムで計算したノード識別子管理テーブルを受信して登録することも可能である。ここで、コンシステントハッシュ法で仮想ＩＤを用いる場合、ノード識別子は仮想ＩＤ毎に保持する。
ノード識別子管理部１０１は、クラスタへのノードの追加や離脱が発生した際に、クラスタを構成するノードの識別子情報（コンシステントハッシュ法ではＩＤ空間上のノードの情報一覧）を更新し、ノード識別子管理テーブル１００として管理する。
なお、ノード識別子管理部１０１においてノード識別子を付与することも可能であるし、他のノードや外部システムで計算したノード識別子管理テーブルを受信して登録することも可能である。ここで、コンシステントハッシュ法で仮想ＩＤを用いる場合、ノード識別子は仮想ＩＤ毎に保持する。
<ノード識別子管理テーブル>
図３は、本発明の第１の実施形態に係るノード識別子管理テーブル１００のデータ構成例を示す図である。図３に示すように、ノード識別子管理テーブル１００は、クラスタを構成する各ノード１のノード識別子１１０、およびサーバ名などの識別子としてのアドレスを含んで構成される。
図３は、本発明の第１の実施形態に係るノード識別子管理テーブル１００のデータ構成例を示す図である。図３に示すように、ノード識別子管理テーブル１００は、クラスタを構成する各ノード１のノード識別子１１０、およびサーバ名などの識別子としてのアドレスを含んで構成される。
このノード識別子１１０は、コンシステントハッシュ法のＩＤ空間上でのノードＩＤに対応する。また、コンシステントハッシュ法において仮想ＩＤを用いる場合には、ノード識別子１１０は、仮想ＩＤ毎に割り当てられ、ノード識別子管理テーブル１００に登録される。そして、このノード識別子管理テーブル１００では、例えば、コンシステントハッシュのＩＤ空間におけるＩＤ（または仮想ＩＤ）を昇順に並べて管理する。つまり、ノード識別子管理テーブル１００において、ノード識別子１１０（ノードＩＤ）を昇順に並べたときの自身のノード１の行の次の行のノード１が、ＩＤ空間上での右隣（時計回りに次）のノード１となる。
例えば、図３においては、コンシステントハッシュのＩＤ空間に基づくノード識別子が「３ａｂ９４６１２９」は、アドレス（例えば、ＩＰアドレス）「１９２．１６８．０．２４」に対応付けられる。
例えば、図３においては、コンシステントハッシュのＩＤ空間に基づくノード識別子が「３ａｂ９４６１２９」は、アドレス（例えば、ＩＰアドレス）「１９２．１６８．０．２４」に対応付けられる。
アドレス１２０は、クラスタを構成する各ノード１の識別子を表す。このアドレス１２０は、ノード１それぞれのアドレス（例えば、ＩＰアドレス）に対応付けられて記憶される。
なお、このノード識別子管理テーブル１００のノード識別子１１０は、特定のノード（マスタノード）のノード識別子管理部１０１が各ノード１に対して付与することもできる。また、ノード１それぞれのノード識別子管理部１０１でノード識別子を付与することも可能である。他のノードや外部システムで計算したノード識別子管理テーブル１００を受信して登録することも可能である。
さらに、このノード識別子管理テーブル１００には、処理で必要となる他の付加情報（例えば、各ノード１のクラスタへの参加日時等）を加えることも可能である。
さらに、このノード識別子管理テーブル１００には、処理で必要となる他の付加情報（例えば、各ノード１のクラスタへの参加日時等）を加えることも可能である。
<メッセージ処理部>
図２に戻り、メッセージ処理部１０２は、振り分け装置４から振り分けられたメッセージを受信し、そのメッセージの処理を実行し、処理結果をクライアント２に返信することにより、サービスを提供する。
また、メッセージ処理部１０２は、他のノード（ここではノード識別子を昇順に並べた時の次のノード＝ＩＤ空間の右隣のノード）にデータの複製を行うことでデータの冗長化を実現する。複製データを複数持つ場合には、さらに他のノード（ここではノード識別子を昇順に並べた時のさらに次のノード＝ＩＤ空間の２つ右隣のノード）にデータの複製を行う。
図２に戻り、メッセージ処理部１０２は、振り分け装置４から振り分けられたメッセージを受信し、そのメッセージの処理を実行し、処理結果をクライアント２に返信することにより、サービスを提供する。
また、メッセージ処理部１０２は、他のノード（ここではノード識別子を昇順に並べた時の次のノード＝ＩＤ空間の右隣のノード）にデータの複製を行うことでデータの冗長化を実現する。複製データを複数持つ場合には、さらに他のノード（ここではノード識別子を昇順に並べた時のさらに次のノード＝ＩＤ空間の２つ右隣のノード）にデータの複製を行う。
<データ取得部>
データ取得部１０３は、メッセージ処理に必要なデータを保持していなかった場合、データを保持している可能性のあるノードを特定し、他のノードに要求してデータを取得する。本実施形態では、データ取得部１０３は、データを保持している可能性のあるノードを特定し、問い合わせを行うノードを絞り込むことで、全ノードへの問い合わせが発生し、無駄なトラヒックの発生や処理の遅延を招くことを防ぐようにする。
データ取得部１０３は、メッセージ処理に必要なデータを保持していなかった場合、データを保持している可能性のあるノードを特定し、他のノードに要求してデータを取得する。本実施形態では、データ取得部１０３は、データを保持している可能性のあるノードを特定し、問い合わせを行うノードを絞り込むことで、全ノードへの問い合わせが発生し、無駄なトラヒックの発生や処理の遅延を招くことを防ぐようにする。
データ取得部１０３は、原本データを持っているノードに確実に信号を振り分けられる状況であるデータ再冗長化・再配置の完了までに発生したノード参加・離脱台数の合計ΔＮを求めて保持する。ここで、データ再冗長化・再配置は、ノードの参加または離脱によって一時的にデータの配置が崩れたものを再び配置し直すもので、再冗長化・再配置が完了すると、原本データを持っているノードに確実に信号を振り分けられる状況となる。また、データ取得部１０３は、データのＫｅｙ情報をハッシュ値演算した結果であるデータＩＤを算出するととともに、算出したデータＩＤと自身のノードＩＤの間のノード数αを算出し、ΔＮとノード数αの比較結果を基に、自身のノードＩＤのＩＤ空間上の左、右、または左右にΔＮ台分のノードに対して問い合わせてデータを取得する。
具体的には、データ取得部１０３は、上記ノード数α＝０の場合、ＩＤ空間上で複製データが作成される方向である所定方向回りにΔＮ台分探索してデータを取得し、α≦ΔＮの場合、所定方向回りにΔＮ台分探索し、所定方向回りと逆方向にα台分探索してデータを取得し、α＞ΔＮの場合、所定方向回りと、当該所定方向回りと逆方向とにそれぞれΔＮ台分探索してデータを取得する。ここで、図１１を参照して後記するように、後記データ取得部１０３は、原本データなしの場合、所定方向回りと逆方向のΔＮ台分の問い合わせについては、自身のノードＩＤとデータＩＤの間に存在するノードに対してのみ行う。なお、問い合わせノードの特定方法の詳細については、後記する。
<死活監視部>
死活監視部１０４は、他のノードと常に死活監視信号のやり取りを実施しており、クラスタを構成するノードの追加や離脱を検出している。死活監視部１０４は、クラスタを構成するノードの追加や離脱を検出した場合には、自ノードあるいは他ノードのノード識別子管理部１０１、あるいはノード識別子１１０を設定している外部システムに通知を行い、ノード識別子管理テーブル１００へと反映する。
死活監視部１０４は、他のノードと常に死活監視信号のやり取りを実施しており、クラスタを構成するノードの追加や離脱を検出している。死活監視部１０４は、クラスタを構成するノードの追加や離脱を検出した場合には、自ノードあるいは他ノードのノード識別子管理部１０１、あるいはノード識別子１１０を設定している外部システムに通知を行い、ノード識別子管理テーブル１００へと反映する。
<死活監視テーブル>
図４は、本発明の第１の実施形態に係る死活監視テーブル２００のデータ構成例を示す図である。
死活監視テーブル２００は、１台の物理装置を単位として作成され、監視対象となるノード１（サーバ）がリスト化されたものである。死活監視テーブル２００には、例えば、サーバ名とそれに紐付くアドレス（ＩＰアドレス）とが記憶される。
図４は、本発明の第１の実施形態に係る死活監視テーブル２００のデータ構成例を示す図である。
死活監視テーブル２００は、１台の物理装置を単位として作成され、監視対象となるノード１（サーバ）がリスト化されたものである。死活監視テーブル２００には、例えば、サーバ名とそれに紐付くアドレス（ＩＰアドレス）とが記憶される。
死活監視テーブル２００は、論理装置（仮想ノード）単位でノードが構成されるパターンを考慮して、その論理装置を構築する物理装置が少なくとも１回は監視対象となるように設定される。また、クラスタを構成するノード１に追加や離脱があった場合、ノード識別子管理テーブル１００と同期的に更新されるものとする。よって、ノード識別子管理テーブル１００のノード識別子１１０が、論理装置単位で構成された仮想ＩＤによるものではなく、物理装置単位のＩＤである場合には、死活監視テーブル２００とノード識別子管理テーブル１００とについて、同一のものを用いてもよい。また、この場合、死活監視テーブル２００を生成せず、ノード識別子管理テーブル１００を用いて、死活監視部１０４が各ノード１の死活監視を行うようにしてもよい。
<データ再冗長化・再配置部>
図２に戻り、データ再冗長化・再配置部１０５は、ノードの参加または離脱に伴い、ノード識別子管理テーブル１００を利用して、自身が保持しているデータのうち、別のノードへと移す、あるいは新たに複製データを配置するデータを特定し、ノードが通常行っている処理の負荷を考慮しながら、バックグラウンドでデータを再冗長化・再配置する。ノードの参加・ノード障害に伴う離脱の場合は、参加・離脱後にデータの再冗長化・再配置を実行する。また、保守観点によるノードの離脱の場合にはノード離脱前にデータの再冗長化・再配置を実施する。ここで、保守観点によるノードの離脱の場合、データの再冗長化・再配置が完了するまでの間はデータ取得部１０３による問い合わせノードの対象となることに注意が必要である。
なお、データ再冗長化・再配置における「再」の意味とは、ノードの参加または離脱によって一時的にデータの配置が崩れたものを再び配置し直すことを表現したものである。
図２に戻り、データ再冗長化・再配置部１０５は、ノードの参加または離脱に伴い、ノード識別子管理テーブル１００を利用して、自身が保持しているデータのうち、別のノードへと移す、あるいは新たに複製データを配置するデータを特定し、ノードが通常行っている処理の負荷を考慮しながら、バックグラウンドでデータを再冗長化・再配置する。ノードの参加・ノード障害に伴う離脱の場合は、参加・離脱後にデータの再冗長化・再配置を実行する。また、保守観点によるノードの離脱の場合にはノード離脱前にデータの再冗長化・再配置を実施する。ここで、保守観点によるノードの離脱の場合、データの再冗長化・再配置が完了するまでの間はデータ取得部１０３による問い合わせノードの対象となることに注意が必要である。
なお、データ再冗長化・再配置における「再」の意味とは、ノードの参加または離脱によって一時的にデータの配置が崩れたものを再び配置し直すことを表現したものである。
<記憶部>
図２に戻り、記憶部１２は、ハードディスクやフラッシュメモリ、ＲＡＭ等の記憶手段からなり、処理の対象となる原本データや複製データ（いずれも不図示）、前記したノード識別子管理テーブル１００（図３参照）や死活監視テーブル２００（図４参照）が記憶される。
図２に戻り、記憶部１２は、ハードディスクやフラッシュメモリ、ＲＡＭ等の記憶手段からなり、処理の対象となる原本データや複製データ（いずれも不図示）、前記したノード識別子管理テーブル１００（図３参照）や死活監視テーブル２００（図４参照）が記憶される。
以下、上述のように構成されたクラスタ構成の分散システムにおけるデータ保持サーバ特定方法について説明する。
図５乃至図９は、本実施形態における問い合わせ先ノード特定処理の具体例を説明するための図である。
図５乃至図９は、本実施形態における問い合わせ先ノード特定処理の具体例を説明するための図である。
<新たなノードが１台参加>
図５は、クラスタに新たなノードが１台参加したケースを表す図である。
図５（ａ）のケースでは、図５（ａ）の番号(1)に示すように、クラスタに新たなノードが１台参加した場合、参加したノード「◎（二重丸）」は、参加前にデータＸを保持していた右隣のノード「●（黒丸）」に問い合わせを行い、データを取得する必要がある。すなわち、図５（ａ）の符号ａに示すように、新たにクラスタに参加したノード「◎（二重丸）」は、ＩＤ空間を参加したノード数分右回りに探索してデータ取得する必要がある。
図５は、クラスタに新たなノードが１台参加したケースを表す図である。
図５（ａ）のケースでは、図５（ａ）の番号(1)に示すように、クラスタに新たなノードが１台参加した場合、参加したノード「◎（二重丸）」は、参加前にデータＸを保持していた右隣のノード「●（黒丸）」に問い合わせを行い、データを取得する必要がある。すなわち、図５（ａ）の符号ａに示すように、新たにクラスタに参加したノード「◎（二重丸）」は、ＩＤ空間を参加したノード数分右回りに探索してデータ取得する必要がある。
一方、図５（ｂ）のケースでは、経路途中で信号の到着順序が入れ違ったケースを表している。図５（ｂ）の番号(2)(3)の信号到達に示すように、信号順序の入れ替え等により信号の到着順序が入れ違うことがある。例えば、ノード参加前のノード識別子管理テーブル１００（図２参照）に基づき振り分けられた信号がノード参加前のノード識別子管理テーブル１００に基づき振り分けられた信号よりも後に到達したケースを表している。この場合、図５（ｂ）で示すように、新たに参加したノード「◎（二重丸）」が既にデータＸを移行し、処理をしている可能性があるため、図５（ｂ）の番号(3)で信号を受信したノード「●（黒丸）」は、左隣のノード「◎（二重丸）」に問い合わせを行い、データを取得する必要がある。すなわち、図５（ｂ）の符号ｂに示すように、信号を受信（(3)信号到達）したノード「●（黒丸）」は、ＩＤ空間を参加したノード数分左回りに探索してデータを取得する必要がある。
このように、ノード参加後には、信号を受信したノードは、左右に参加したノード数（ここでは１台）分の問い合わせを行い、データを取得した後に処理を行う必要がある。なお、図５（ｂ）のケースでは、信号を受信（(3)信号到達）したノード「●（黒丸）」は、複製データを保持しており処理を継続できる可能性はあるが、データの一貫性の観点から、左隣のノードに問い合わせを行い、原本データを管理する権利を取得した後に処理を行う必要がある。つまり、複製データ側を原本データより先に更新することはない。
<新たなノードが複数台参加>
図６は、クラスタに新たなノードが複数台参加したケースを表す図である。
図６（ａ）のケースでは、図６（ａ）の番号(1),(1)′,(1)″に示すように、クラスタに新たなノードが複数台参加した場合、新たにクラスタに参加し信号を受信したノード「◎（二重丸）」は、他の新たに参加したノード「◎（二重丸）」を含み３台（新たに参加したノード数）分右隣りに問い合わせを行い、ノード「◎（二重丸）」は参加前にデータＸを保持していた３台右隣のノード「●（黒丸）」からデータを取得する必要がある。すなわち、図６（ａ）の符号ａに示すように、新たにクラスタに参加したノード「◎（二重丸）」は、ＩＤ空間を参加したノード数分右回りに探索してデータ取得する必要がある。
図６は、クラスタに新たなノードが複数台参加したケースを表す図である。
図６（ａ）のケースでは、図６（ａ）の番号(1),(1)′,(1)″に示すように、クラスタに新たなノードが複数台参加した場合、新たにクラスタに参加し信号を受信したノード「◎（二重丸）」は、他の新たに参加したノード「◎（二重丸）」を含み３台（新たに参加したノード数）分右隣りに問い合わせを行い、ノード「◎（二重丸）」は参加前にデータＸを保持していた３台右隣のノード「●（黒丸）」からデータを取得する必要がある。すなわち、図６（ａ）の符号ａに示すように、新たにクラスタに参加したノード「◎（二重丸）」は、ＩＤ空間を参加したノード数分右回りに探索してデータ取得する必要がある。
一方、図６（ｂ）のケースでは、経路途中で信号の到着順序が入れ違ったケースを表している。図６（ｂ）の番号(2)の信号到達と番号(3)の信号到達とに示すように、信号順序の入れ替え等により信号の到着順序が入れ違うことがある。例えば、ノード参加前のノード識別子管理テーブル１００（図２参照）に基づき振り分けられた信号がノード参加前のノード識別子管理テーブル１００に基づき振り分けられた信号よりも後に到達したケースを表している。この場合、図６（ｂ）で示すように、新たに参加したノード「◎（二重丸）」が既にデータＸを以降して処理をしている可能性があるため、図６（ｂ）の番号(3)で信号を受信したノード「●（黒丸）」は、他の新たに参加したノード「◎（二重丸）」を含み２台（新たに参加したノード数）分左隣のノードに問い合わせを行い、データを取得する必要がある。すなわち、図６（ｂ）の符号ｂに示すように、信号を受信（(3)信号到達）したノード「●（黒丸）」は、ＩＤ空間を参加したノード数分左回りに探索してデータを取得する必要がある。
このように、ノードが複数台参加したケースにおいても、信号を受信したノードは左右に参加したノード数（図６（ａ）では３台、図６（ｂ）では２台）分の問い合わせを行いデータを取得した後に処理を行う必要がある。なお、図６（ｂ）のケースでは、信号を受信（(3)信号到達）したノード「●（黒丸）」は、複製データを保持しており処理を継続できる可能性はあるが、データの一貫性の観点から、左隣のノードに問い合わせを行い、原本データを管理する権利を取得した後に処理を行う必要がある。つまり、複製データ側を原本データより先に更新することはない。
<ノードの保守観点による離脱>
図７は、ノードの保守観点による離脱を行うケースを表す図である。図７（ａ）において、番号(1)のノードは、保守観点による離脱対象ノード「○（白破線丸）」、図７（ｂ）において、番号(1),(1)′のノードは、保守観点による離脱対象ノード「○（白破線丸）」である。なお、離脱には、保守観点による離脱のほか、故障等による離脱がある。保守観点による離脱では、離脱対象となっているノードが持つデータをすべて他のサーバ（ノード）に移行した後に当該ノードが離脱することになる。
図７は、ノードの保守観点による離脱を行うケースを表す図である。図７（ａ）において、番号(1)のノードは、保守観点による離脱対象ノード「○（白破線丸）」、図７（ｂ）において、番号(1),(1)′のノードは、保守観点による離脱対象ノード「○（白破線丸）」である。なお、離脱には、保守観点による離脱のほか、故障等による離脱がある。保守観点による離脱では、離脱対象となっているノードが持つデータをすべて他のサーバ（ノード）に移行した後に当該ノードが離脱することになる。
図７（ａ）のケースでは、図７（ａ）の番号(1),(2)に示すように、信号を受信したノード「●（黒丸）」は、左隣の離脱対象ノード「○（白破線丸）」に対してデータの問い合わせを行い、データＸを取得した後に処理を行う必要がある。すなわち、図７（ａ）の符号ａに示すように、信号を受信したノード「●（黒丸）」は、ＩＤ空間を左回りに探索してデータを取得する必要がある。
また、図７（ｂ）のケースでは、信号を受信したノード「●（黒丸）」は、図７（ｂ）の番号(1),(1)′に示すように、２台（離脱対象のノード数）分左隣のノード「○（白破線丸）」に対してデータの問い合わせを行い、データＸを取得した後に処理を行う必要がある。すなわち、図７（ｂ）の符号ｂに示すように、信号を受信したノード「●（黒丸）」は、ＩＤ空間を離脱したノード数分左回りに探索してデータを取得する必要がある。
このように、ノード離脱後には信号を受信したノードは、左隣に離脱したノード数分の問い合わせを行い、データを取得する必要がある。なお、図７（ａ）（ｂ）のケースにおいて、信号を受信（「(2)信号到達」参照）したノード「●（黒丸）」は、複製データを保持しており処理を継続できる可能性はあるが、データの一貫性の観点から、左隣のノードに問い合わせを行い、原本データを管理する権利を取得した後に処理を行う必要がある。つまり、複製データ側を原本データより先に更新することはない。
このように、ノード離脱後には信号を受信したノードは、左隣に離脱したノード数分の問い合わせを行い、データを取得する必要がある。なお、図７（ａ）（ｂ）のケースにおいて、信号を受信（「(2)信号到達」参照）したノード「●（黒丸）」は、複製データを保持しており処理を継続できる可能性はあるが、データの一貫性の観点から、左隣のノードに問い合わせを行い、原本データを管理する権利を取得した後に処理を行う必要がある。つまり、複製データ側を原本データより先に更新することはない。
<ノードの参加と離脱（保守観点）>
図８は、ノードの参加と離脱が発生したケースを表す図である。なお、この時の離脱は保守観点の離脱であったと仮定する。図８において、番号(1)のノードは、保守観点による離脱対象ノード「○（白破線丸）」である。
図８の番号(4)の信号到達および図８の番号(3)に示すように、新たにクラスタに参加し信号を受信したノード「◎（二重丸）」は、データＸを取得する必要がある。この例では、図８の符号ａに示すように、新たにクラスタに参加したノード「◎（二重丸）」は、ＩＤ空間を参加または離脱したノード数分右回りに探索してデータ取得する。
図８は、ノードの参加と離脱が発生したケースを表す図である。なお、この時の離脱は保守観点の離脱であったと仮定する。図８において、番号(1)のノードは、保守観点による離脱対象ノード「○（白破線丸）」である。
図８の番号(4)の信号到達および図８の番号(3)に示すように、新たにクラスタに参加し信号を受信したノード「◎（二重丸）」は、データＸを取得する必要がある。この例では、図８の符号ａに示すように、新たにクラスタに参加したノード「◎（二重丸）」は、ＩＤ空間を参加または離脱したノード数分右回りに探索してデータ取得する。
この場合、図８の符号ｂに示すように、データＸは、もともと離脱対象ノード「○（白破線丸）」（「(1)ノード離脱(保守観点)」参照）が保持していたが、バックグラウンドでデータを移行しているため、既にノード離脱後の配置に移行している可能性がある。つまり、データＸは、図８の破線矢印ｃに示すように、ノード離脱から新たなノードの参加までの間に、離脱対象ノードからその右隣のノードへとバックグラウンドでデータを移行（「(2)データ再配置」参照）されている可能性があり、信号受信時でデータＸが離脱対象となっているノードとその右隣のノードのどちらにあるかはわからない。この場合、バックグラウンドでデータを移行しているので、図８の離脱対象ノード「○（白破線丸）」がデータを持っているのか、その右隣のノード「●（黒丸）」にデータがあるのかが分からない。
そこで、新たにクラスタに参加したノードは、離脱しようとしているノード「○（白破線丸）」とその右隣のノード「●（黒丸）」とを含む２台（参加、離脱したノード数）分右隣に問い合わせを行いデータを取得する必要がある。このように、ノードの離脱・参加があった場合には、左右に参加・離脱したノード数分の問い合わせを行いデータを取得する必要がある。
ここで、前述したようにノードの離脱や参加に伴い、データの再冗長化・再配置が行われるため、データの問い合わせは再冗長化・再配置の完了までの期間となる。また、自身が既に原本データを保持していたケースでは、他のノードが原本データを保持していない（更新権利を持っていない）ことがわかるため、問い合わせを行わずに処理を継続できる。
ここで、前述したようにノードの離脱や参加に伴い、データの再冗長化・再配置が行われるため、データの問い合わせは再冗長化・再配置の完了までの期間となる。また、自身が既に原本データを保持していたケースでは、他のノードが原本データを保持していない（更新権利を持っていない）ことがわかるため、問い合わせを行わずに処理を継続できる。
<左側問い合わせが不要なケース>
図９は、左側問い合わせが不要なケースを表す図である。図８において、番号(1)のノードは、保守観点による離脱対象ノード「○（白破線丸）」である。
図９の番号(3)の信号到達および図９の番号(2)に示すように、新たにクラスタに参加し信号を受信したノード「◎（二重丸）」は、データのＫｅｙ情報をハッシュ値演算した結果（以降、データＩＤと呼ぶ）と参加ノードの間にノードが存在しないため、左側問い合わせは不要である。
図９は、左側問い合わせが不要なケースを表す図である。図８において、番号(1)のノードは、保守観点による離脱対象ノード「○（白破線丸）」である。
図９の番号(3)の信号到達および図９の番号(2)に示すように、新たにクラスタに参加し信号を受信したノード「◎（二重丸）」は、データのＫｅｙ情報をハッシュ値演算した結果（以降、データＩＤと呼ぶ）と参加ノードの間にノードが存在しないため、左側問い合わせは不要である。
以上をまとめると、データの問い合わせ先は、図１０に示す表１となる。
表１（データの問い合わせ先を示す表）は、「原本データ保持」および「原本データなし」について、「データ再冗長化・再配置完了前」と「データ再冗長化・再配置完了後」を表にして示したものである。なお、表１中のΔＮは、あるノードの参加または離脱に伴うデータ再冗長化・再配置開始から完了までに発生したノード参加・離脱台数の合計であり、データ取得部１０３（図２参照）で計算して記憶部１２（図２参照）に保持している。
表１（データの問い合わせ先を示す表）は、「原本データ保持」および「原本データなし」について、「データ再冗長化・再配置完了前」と「データ再冗長化・再配置完了後」を表にして示したものである。なお、表１中のΔＮは、あるノードの参加または離脱に伴うデータ再冗長化・再配置開始から完了までに発生したノード参加・離脱台数の合計であり、データ取得部１０３（図２参照）で計算して記憶部１２（図２参照）に保持している。
表１に示すように、「原本データ保持」している場合は、「データ再冗長化・再配置完了前」および「データ再冗長化・再配置完了後」のいずれの場合も問い合わせ不要である。
「原本データなし」の場合は、「データ再冗長化・再配置完了後」では問い合わせ不要であるが、「データ再冗長化・再配置完了前」では、左右にΔＮ台分問い合わせが必要である。ただし、左側の問い合わせは、自身のＩＤとデータＩＤの間に存在するノードに対してのみ実施する。「左側の問い合わせは、自身のＩＤとデータＩＤの間に存在するノードに対してのみ実施」する理由は、次の通りである。コンシステントハッシュ法では、データのＩＤから右回りに探索して最初に当たったノードＩＤを持つノードにデータを保持する。よって、データＩＤとノードＩＤの間にノードが存在しなければ、左側にデータを持っているノードは、存在することはありえないからである。
また、左側の問い合わせについては、図９に示したように、データＩＤと自身のＩＤの間にいるノードに限定して実施すればよい。
「原本データなし」の場合は、「データ再冗長化・再配置完了後」では問い合わせ不要であるが、「データ再冗長化・再配置完了前」では、左右にΔＮ台分問い合わせが必要である。ただし、左側の問い合わせは、自身のＩＤとデータＩＤの間に存在するノードに対してのみ実施する。「左側の問い合わせは、自身のＩＤとデータＩＤの間に存在するノードに対してのみ実施」する理由は、次の通りである。コンシステントハッシュ法では、データのＩＤから右回りに探索して最初に当たったノードＩＤを持つノードにデータを保持する。よって、データＩＤとノードＩＤの間にノードが存在しなければ、左側にデータを持っているノードは、存在することはありえないからである。
また、左側の問い合わせについては、図９に示したように、データＩＤと自身のＩＤの間にいるノードに限定して実施すればよい。
ここで、「データ再冗長化・再配置完了前」の「原本データなし」の場合には原本データをたどる必要があるのに対し、「データ再冗長化・再配置完了後」の「原本データなし」の場合、問い合わせ不要である理由について述べる。「データの再冗長化・再配置が完了している」とは、原本データを持っているノードに確実に信号を振り分けられる状況」である。すなわち、原本データがなければ探索してもデータが見つかることはないという状況であるので、問い合わせは不要であるとする。
<処理の流れ>
次に、本発明の第１の実施形態に係るノード１の信号受信から処理までの流れについて、図１１および前記した図５ないし図９を参照して説明する。
次に、本発明の第１の実施形態に係るノード１の信号受信から処理までの流れについて、図１１および前記した図５ないし図９を参照して説明する。
図１１は、本発明の第１の実施形態に係るノード１（データ取得部１０３）が行うクライアントからの信号受信から信号処理までの流れを示すフローチャートである。データ取得部１０３において、問い合わせ先ノードを特定する方法について説明する。
まず、メッセージ処理部１０２（図２参照）は、ノード識別子管理部１０１やメッセージ処理部１０２から、クライアントからの信号を受信する（ステップＳ１０）。
まず、データ取得部１０３は、あるノードの参加または離脱に伴うデータ再冗長化・再配置開始から完了までに発生したノード参加・離脱台数の合計ΔＮが０より大きい（ΔＮ＞０）か否かを判定する（ステップＳ１１）。
各ノードでは、常にΔＮの値を保持している。以下、再冗長化・再配置が完了している状態を安定状態と呼ぶこととする。安定状態からノードの参加または離脱１台が発生した場合に、ΔＮ＝１とする。その後、安定状態に移行する前にさらなる参加または離脱が１台発生した場合、ΔＮ＝＋１とする。上記は、参加または離脱が起こる度に繰り返すこととする。安定状態に遷移した場合には、ΔＮ＝０とする。
まず、メッセージ処理部１０２（図２参照）は、ノード識別子管理部１０１やメッセージ処理部１０２から、クライアントからの信号を受信する（ステップＳ１０）。
まず、データ取得部１０３は、あるノードの参加または離脱に伴うデータ再冗長化・再配置開始から完了までに発生したノード参加・離脱台数の合計ΔＮが０より大きい（ΔＮ＞０）か否かを判定する（ステップＳ１１）。
各ノードでは、常にΔＮの値を保持している。以下、再冗長化・再配置が完了している状態を安定状態と呼ぶこととする。安定状態からノードの参加または離脱１台が発生した場合に、ΔＮ＝１とする。その後、安定状態に移行する前にさらなる参加または離脱が１台発生した場合、ΔＮ＝＋１とする。上記は、参加または離脱が起こる度に繰り返すこととする。安定状態に遷移した場合には、ΔＮ＝０とする。
そして、この条件を満たさない場合には（ステップＳ１１→Ｎｏ）、問い合わせ先ノード特定処理を終了する（ステップＳ１９へ進む）。一方、この条件を満たす場合には（ステップＳ１１→Ｙｅｓ）、次のステップＳ１２に進む。
次に、データ取得部１０３は、原本データを保持しているか否かを判定する。原本データを保持している場合には（ステップＳ１２→Ｙｅｓ）、表１に示すように、「データ再冗長化・再配置完了前」および「データ再冗長化・再配置完了後」のいずれの場合も問い合わせ不要であるため、問い合わせ先ノード特定処理を終了する（ステップＳ１９へ進む）。
一方、原本データを保持していない場合には（ステップＳ１２→Ｎｏ）、表１に示すように、左右にΔＮ台分問い合わせが必要であるため、次のステップＳ１３以降に進む。
ここで、データ取得部１０３は、表１に示すように、左右にΔＮ台分問い合わせに際し、左側の問い合わせは、自身のノードＩＤとデータＩＤの間に存在するノードに対してのみ実施する。例えば、図９の番号(3)の信号到達および図９の番号(2)に示すように、新たにクラスタに参加し信号を受信したノード「◎（二重丸）」は、データＩＤと参加ノードの間にノードが存在しないため、左側問い合わせは不要である。
ここで、データ取得部１０３は、表１に示すように、左右にΔＮ台分問い合わせに際し、左側の問い合わせは、自身のノードＩＤとデータＩＤの間に存在するノードに対してのみ実施する。例えば、図９の番号(3)の信号到達および図９の番号(2)に示すように、新たにクラスタに参加し信号を受信したノード「◎（二重丸）」は、データＩＤと参加ノードの間にノードが存在しないため、左側問い合わせは不要である。
図１１のフローに戻って、まず、データ取得部１０３は、データのＫｅｙ情報をハッシュ値演算した結果からデータＩＤを算出する（ステップＳ１３）。
次に、データ取得部１０３は、算出したデータＩＤと自身のノードＩＤの間のノード数αを算出する（ステップＳ１４）。
次に、データ取得部１０３は、前記ノード数αとΔＮを比較する（ステップＳ１５）。
α＝０の場合、データ取得部１０３は、右にΔＮ探索してデータ取得し（ステップＳ１６）、次のステップＳ１９に進む。
α≦ΔＮの場合、データ取得部１０３は、右にΔＮ探索＋左にα探索してデータ取得し（ステップＳ１７）、次のステップＳ１９に進む。
α＞ΔＮの場合、データ取得部１０３は、左右にΔＮ探索してデータ取得し（ステップＳ１８）、次のステップＳ１９に進む。
最後に、ステップＳ１９において、メッセージ処理部１０２は、信号処理を行って問い合わせ先ノード特定処理を終了する。
以下、上記フローの実行による、問い合わせ先ノード特定処理の具体例について説明する。
次に、データ取得部１０３は、算出したデータＩＤと自身のノードＩＤの間のノード数αを算出する（ステップＳ１４）。
次に、データ取得部１０３は、前記ノード数αとΔＮを比較する（ステップＳ１５）。
α＝０の場合、データ取得部１０３は、右にΔＮ探索してデータ取得し（ステップＳ１６）、次のステップＳ１９に進む。
α≦ΔＮの場合、データ取得部１０３は、右にΔＮ探索＋左にα探索してデータ取得し（ステップＳ１７）、次のステップＳ１９に進む。
α＞ΔＮの場合、データ取得部１０３は、左右にΔＮ探索してデータ取得し（ステップＳ１８）、次のステップＳ１９に進む。
最後に、ステップＳ１９において、メッセージ処理部１０２は、信号処理を行って問い合わせ先ノード特定処理を終了する。
以下、上記フローの実行による、問い合わせ先ノード特定処理の具体例について説明する。
<例１：ノード参加>
図６（ａ）に示す例において、図６（ａ）の番号(1),(1)′,(1)″に示すように、クラスタに新たなノードが３台参加した場合、新たにクラスタに参加し信号を受信したノード「◎（二重丸）」は、他の新たに参加したノード「◎（二重丸）」を含み３台（新たに参加したノード数）分右隣りに問い合わせを行い、ノード「◎（二重丸）」は参加前にデータＸを保持していた３台右隣のノード「●（黒丸）」からデータを取得する。図６（ａ）の符号ａに示すように、新たにクラスタに参加したノード「◎（二重丸）」は、ＩＤ空間を参加したノード数ΔＮ分右回りに探索してデータ取得する（例えば、図１１のステップＳ１７における右にΔＮ探索参照）。
図６（ａ）に示す例において、図６（ａ）の番号(1),(1)′,(1)″に示すように、クラスタに新たなノードが３台参加した場合、新たにクラスタに参加し信号を受信したノード「◎（二重丸）」は、他の新たに参加したノード「◎（二重丸）」を含み３台（新たに参加したノード数）分右隣りに問い合わせを行い、ノード「◎（二重丸）」は参加前にデータＸを保持していた３台右隣のノード「●（黒丸）」からデータを取得する。図６（ａ）の符号ａに示すように、新たにクラスタに参加したノード「◎（二重丸）」は、ＩＤ空間を参加したノード数ΔＮ分右回りに探索してデータ取得する（例えば、図１１のステップＳ１７における右にΔＮ探索参照）。
図６（ｂ）に示す例において、経路途中で信号の到着順序が入れ違った場合、図６（ｂ）の番号(3)で信号を受信したノード「●（黒丸）」は、他の新たに参加したノード「◎（二重丸）」を含みノード数αが２台（新たに参加したノード数）分左隣のノードに問い合わせを行い、データを取得する。図６（ｂ）の符号ｂに示すように、信号を受信（(3)信号到達）したノード「●（黒丸）」は、ＩＤ空間を参加したノード数ΔＮ左回りに探索してデータを取得する（例えば、図１１のステップＳ１７における右にΔＮ探索参照）。
<例２：ノード離脱>
図７（ａ）に示す例において、図７（ａ）の番号(1),(2)に示すように、信号を受信したノード「●（黒丸）」は、左隣の離脱対象ノード「○（白破線丸）」に対してデータの問い合わせを行い、データＸを取得した後に処理を行う。図７（ｂ）の符号ａに示すように、信号を受信したノード「●（黒丸）」は、ＩＤ空間を左回りに探索してデータを取得する（例えば、図１１のステップＳ１８におけるΔＮ探索参照）。
図７（ａ）に示す例において、図７（ａ）の番号(1),(2)に示すように、信号を受信したノード「●（黒丸）」は、左隣の離脱対象ノード「○（白破線丸）」に対してデータの問い合わせを行い、データＸを取得した後に処理を行う。図７（ｂ）の符号ａに示すように、信号を受信したノード「●（黒丸）」は、ＩＤ空間を左回りに探索してデータを取得する（例えば、図１１のステップＳ１８におけるΔＮ探索参照）。
図７（ｂ）に示す例において、信号を受信したノード「●（黒丸）」は、図７（ｂ）の番号(1),(1)′に示すように、２台（離脱対象のノード数）分左隣のノード「○（白破線丸）」に対してデータの問い合わせを行い、データＸを取得する。図７（ｂ）の符号ｂに示すように、信号を受信したノード「●（黒丸）」は、ＩＤ空間を離脱したノード数分左回りに探索してデータを取得する（例えば、図１１のステップＳ１８におけるΔＮ探索参照）。
<例３：ノード参加・離脱>
図８に示す例において、 図８の番号(4)の信号到達および図８の番号(3)に示すように、ノードの離脱・参加があった場合には、左右に参加・離脱したノード数分の問い合わせを行いデータを取得する（例えば、図１１のステップＳ１８における左右にΔＮ探索参照）。この場合、図８の符号ａに示すように、新たにクラスタに参加したノード「◎（二重丸）」は、ＩＤ空間を参加または離脱したノード数分右回りに探索してデータ取得する。
図８に示す例において、 図８の番号(4)の信号到達および図８の番号(3)に示すように、ノードの離脱・参加があった場合には、左右に参加・離脱したノード数分の問い合わせを行いデータを取得する（例えば、図１１のステップＳ１８における左右にΔＮ探索参照）。この場合、図８の符号ａに示すように、新たにクラスタに参加したノード「◎（二重丸）」は、ＩＤ空間を参加または離脱したノード数分右回りに探索してデータ取得する。
以上説明したように、分散システム１０００のノード１は、メッセージ処理に必要なデータを保持していなかった場合、データを保持している可能性のあるノードを特定し、他のノードに要求してデータを取得するデータ取得部１０３を備える。データ取得部１０３は、原本データを持っているノードに確実に信号を振り分けられる状況であるデータ再冗長化・再配置完了までに発生したノード参加・離脱台数の合計のΔＮを求めて保持し、データのＫｅｙ情報をハッシュ値演算した結果であるデータＩＤを算出するととともに、算出したデータＩＤと自身のノードＩＤの間のノード数αを算出し、ΔＮとノード数αの比較結果を基に、自身のノードＩＤのＩＤ空間上の左、右、または左右にΔＮ台分のノードに対して問い合わせてデータを取得する。
データ取得部１０３は、図１１に示されているように、α＝０の場合、ＩＤ空間上で複製データが作成される方向である所定方向回り（本実施形態では時計回り）にΔＮ台分探索してデータを取得し、α≦ΔＮの場合、所定方向回りにΔＮ台分探索し、所定方向回りと逆方向にα台分探索してデータを取得し、α＞ΔＮの場合、所定方向回りと、当該所定方向回りと逆方向とにそれぞれΔＮ台分探索してデータを取得する。
このように、ノード１は、ノードの参加または離脱に伴うデータ再冗長化・再配置開始から完了までに発生したノード参加・離脱台数をカウントすることで、最初に問い合わせを受けたノードから、高々、増減設されたノードの台数ΔＮ台分左右（データおよびノードのＩＤの空間上におけるノード群の順序におけるΔＮ台分の左右）に問い合わせる。これにより、データ有無を問い合わせるノードの範囲を限定する、すなわち問い合わせ先を絞り込むことができる。したがって、クラスタを構成するノードの参加または離脱があった場合、全ノードに対する問い合わせを不要にしつつデータの一貫性を保持し、データを保持している可能性があるノードを効率良く探索することができる。
（第２実施形態）
次に、本発明の第２の実施形態に係るノード１Ａについて説明する。
図１２は、本発明の第２の実施形態に係るノード１Ａの構成例を示す機能ブロック図である。図２において示した第１の実施形態に係るノード１との違いは、第２の実施形態に係るノード１Ａは、第１の実施形態に係るノード１のデータ取得部１０３が、データ取得部１０３Ａに変更されていることである。その他の構成については、図１２において、図２に示した第１に実施形態に係るノード１と同一の名称と符号を付し、説明を省略する。また、分散システム１０００の全体構成も第１の実施形態における図１と同一であるので説明を省略する。
データ取得部１０３Ａは、図２のデータ取得部１０３の「原本データ保持」および「原本データなし」の判定に加え、「原本データ保持」と「原本データなし／複製データあり」と「原本データなし／複製データなし」とを判定する。
次に、本発明の第２の実施形態に係るノード１Ａについて説明する。
図１２は、本発明の第２の実施形態に係るノード１Ａの構成例を示す機能ブロック図である。図２において示した第１の実施形態に係るノード１との違いは、第２の実施形態に係るノード１Ａは、第１の実施形態に係るノード１のデータ取得部１０３が、データ取得部１０３Ａに変更されていることである。その他の構成については、図１２において、図２に示した第１に実施形態に係るノード１と同一の名称と符号を付し、説明を省略する。また、分散システム１０００の全体構成も第１の実施形態における図１と同一であるので説明を省略する。
データ取得部１０３Ａは、図２のデータ取得部１０３の「原本データ保持」および「原本データなし」の判定に加え、「原本データ保持」と「原本データなし／複製データあり」と「原本データなし／複製データなし」とを判定する。
図１３は、データの問い合わせ先を表（表２）にして示す図である。
表２は、図１０の表１に対して「原本データなし」が、さらに「原本データなし／複製データあり」と「原本データなし／複製データなし」とに分かれる。
「原本データなし／複製データあり」の場合、「データ再冗長化・再配置完了前」では、左にΔＮ台分問い合わせる。ただし、左側の問い合わせは自身のＩＤとデータＩＤの間に存在するノードに対してのみ実施する。
「原本データなし／複製データなし」の場合、「データ再冗長化・再配置完了前」では、左右にΔＮ台分問い合わせる。ただし、左側の問い合わせは自身のＩＤとデータＩＤの間に存在するノードに対してのみ実施する。なお、「原本データなし／複製データあり」および「原本データなし／複製データなし」のいずれの場合も「データ再冗長化・再配置完了後」では、問い合わせ不要である。また、左側の問い合わせが不要のケースについては、図９で説明している。
表２は、図１０の表１に対して「原本データなし」が、さらに「原本データなし／複製データあり」と「原本データなし／複製データなし」とに分かれる。
「原本データなし／複製データあり」の場合、「データ再冗長化・再配置完了前」では、左にΔＮ台分問い合わせる。ただし、左側の問い合わせは自身のＩＤとデータＩＤの間に存在するノードに対してのみ実施する。
「原本データなし／複製データなし」の場合、「データ再冗長化・再配置完了前」では、左右にΔＮ台分問い合わせる。ただし、左側の問い合わせは自身のＩＤとデータＩＤの間に存在するノードに対してのみ実施する。なお、「原本データなし／複製データあり」および「原本データなし／複製データなし」のいずれの場合も「データ再冗長化・再配置完了後」では、問い合わせ不要である。また、左側の問い合わせが不要のケースについては、図９で説明している。
表２に関して、「原本データなし／複製データあり」または「原本データなし／複製データなし」は、データ取得部１０３Ａが、システム的に下記のような判定を行う。
例えば、以下のような２例が挙げられる。
例えば、以下のような２例が挙げられる。
（１）各データに付加情報を持たせる
各データに付加情報を持ち、その中に原本／複製情報を記述しておく態様である。データ取得部１０３Ａは、この付加情報から「原本データなし／複製データあり」または「原本データなし／複製データなし」を判定することが可能である。なお、この付加情報を有するデータは、「ノード情報」あるいは「メタデータ」と呼ばれることがある。ただし、この場合には、事前に原本データ一覧や複製データ一覧などのデータ一覧を作成してから、後記図１４のフローに入る必要がある。
各データに付加情報を持ち、その中に原本／複製情報を記述しておく態様である。データ取得部１０３Ａは、この付加情報から「原本データなし／複製データあり」または「原本データなし／複製データなし」を判定することが可能である。なお、この付加情報を有するデータは、「ノード情報」あるいは「メタデータ」と呼ばれることがある。ただし、この場合には、事前に原本データ一覧や複製データ一覧などのデータ一覧を作成してから、後記図１４のフローに入る必要がある。
（２）原本データと複製データでデータの格納先ディレクトリを変える
事前にデータ格納先を原本データと複製データで別々としておく態様である。例えば、原本データは、／Ａ／Ｂ／Ｃ／original／〜に格納し、複製データは／Ａ／Ｂ／Ｃ／backup／〜に格納する。この場合、原本データと複製データでデータの格納先が異なるため、後記図１４のフロー実行のチェックの段階で原本データディレクトリ配下を先に見て、なければ続いて複製データディレクトリ配下を見ることになる。
事前にデータ格納先を原本データと複製データで別々としておく態様である。例えば、原本データは、／Ａ／Ｂ／Ｃ／original／〜に格納し、複製データは／Ａ／Ｂ／Ｃ／backup／〜に格納する。この場合、原本データと複製データでデータの格納先が異なるため、後記図１４のフロー実行のチェックの段階で原本データディレクトリ配下を先に見て、なければ続いて複製データディレクトリ配下を見ることになる。
図１４は、本発明の第２の実施形態に係るノード１Ａ（データ取得部１０３Ａ）が行うクライアントからの信号受信から処理までの流れを示すフローチャートである。図１４において、図１１に示したフローと同一の処理を行うステップには同一ステップ番号を付し、説明を省略する。
図１４において、ステップＳ１４でノード数αを算出すると、データ取得部１０３Ａは、複製データを保持しているか否かを判定する（ステップＳ２１）。
複製データを保持している場合、ステップＳ２２に進み（ステップＳ２１→Ｙｅｓ）、複製データを保持していない場合、ステップＳ１５に進む（ステップＳ２１→Ｎｏ）。
ステップＳ２２では、データ取得部１０３Ａは、前記ノード数αとΔＮを比較する。
α＝０の場合、データ取得部１０３Ａは、ステップＳ１９に進む。
α≦ΔＮの場合、データ取得部１０３Ａは、左にα探索してデータ取得し（ステップＳ２３）、次のステップＳ１９に進む。
α＞ΔＮの場合、データ取得部１０３Ａは、左にΔＮ探索してデータ取得し（ステップＳ２４）、次のステップＳ１９に進む。
図１４において、ステップＳ１４でノード数αを算出すると、データ取得部１０３Ａは、複製データを保持しているか否かを判定する（ステップＳ２１）。
複製データを保持している場合、ステップＳ２２に進み（ステップＳ２１→Ｙｅｓ）、複製データを保持していない場合、ステップＳ１５に進む（ステップＳ２１→Ｎｏ）。
ステップＳ２２では、データ取得部１０３Ａは、前記ノード数αとΔＮを比較する。
α＝０の場合、データ取得部１０３Ａは、ステップＳ１９に進む。
α≦ΔＮの場合、データ取得部１０３Ａは、左にα探索してデータ取得し（ステップＳ２３）、次のステップＳ１９に進む。
α＞ΔＮの場合、データ取得部１０３Ａは、左にΔＮ探索してデータ取得し（ステップＳ２４）、次のステップＳ１９に進む。
このように、本実施形態によれば、ノード１Ａのデータ取得部１０３Ａ（図１２参照）は、データ問い合わせ先の原本データなしの場合において、複製データの保持の有無を判定し、複製データを保持している場合、自身のノードＩＤのＩＤ空間上の所定方向回りと逆方向に値ΔＮ台分のノードに対して問い合わせてデータを取得する。具体的には、データ取得部１０３Ａは、α≦ΔＮの場合、所定方向回りと逆方向にα台分探索してデータを取得し、α＞ΔＮの場合、所定方向回りと逆方向に値ΔＮ台分探索してデータを取得する。
図１３の表２に示すように、「原本データなし／複製データあり」の場合、「データ再冗長化・再配置完了前」では、左にΔＮ台分問い合わせる。第１の実施形態の図１０の表１では、原本データ保持と原本データなしを判定していたため、原本データなしの場合は、「データ再冗長化・再配置完了前」では、左右にΔＮ台分問い合わせている。これに対し、本実施形態では、原本データなしの場合において、複製データの保持の有無を判定しているので、原本データなしで複製データありの場合、左のみにΔＮ台分問い合わせればよく、問い合わせ範囲を減らすことができる。ここで、図１３の表２に示すように、左にΔＮ台分の問い合わせについては、自身のノードＩＤとデータＩＤの間に存在するノードに対してのみ行えばよいので、右側の問い合わせを減らすことができれば、データを保持している可能性があるノードをより効率良く探索することができる。
以上、本発明の実施形態について説明したが、本発明は、ここで説明した各実施形態に限定されるものではない。
１，１Ａ ノード
２ クライアント
３ ロードバランサ
４ 振り分け装置
１０ 制御部
１１ 入出力部
１２ 記憶部
１００ ノード識別子管理テーブル
１０１ ノード識別子管理部
１０２ メッセージ処理部
１０３，１０３Ａ データ取得部
１０４ 死活監視部
１０５ データ再冗長化・再配置部
２００ 死活監視テーブル
１０００ 分散システム
２ クライアント
３ ロードバランサ
４ 振り分け装置
１０ 制御部
１１ 入出力部
１２ 記憶部
１００ ノード識別子管理テーブル
１０１ ノード識別子管理部
１０２ メッセージ処理部
１０３，１０３Ａ データ取得部
１０４ 死活監視部
１０５ データ再冗長化・再配置部
２００ 死活監視テーブル
１０００ 分散システム
Claims (6)
- 環状のＩＤ（IDentifier）空間に、処理対象の複数のデータのＩＤ、および、クラスタを構成し前記データに関するリクエストを処理する複数のノードのＩＤが、割り当てられ、前記ＩＤ空間において前記データのＩＤから所定方向回りに辿って最初に遭遇した前記ノードまでの間に位置する前記データを当該ノードが原本データとして保持するとともに、前記クラスタ内の自身以外の他のノードに前記原本データの複製である複製データを保持させる分散システムの前記ノードであって、
メッセージ処理に必要なデータを保持していなかった場合、前記データを保持している可能性のあるノードを特定し、他のノードに要求してデータを取得するデータ取得部と、
ノードの参加または離脱に伴い、自身が保持しているデータのうち、別のノードへと移行する、または、新たに複製データを配置するデータを特定して、当該特定したデータを再冗長化・再配置するデータ再冗長化・再配置部と、を備え、
前記データ取得部は、
前記原本データを持っているノードに信号を振り分けられる状況であるデータ再冗長化・再配置完了までに発生したノード参加・離脱台数の合計の値ΔＮを保持し、
前記データのＫｅｙ情報をハッシュ値演算した結果であるデータＩＤを算出するとともに、算出した前記データＩＤと自身のノードＩＤの間のノード数αを算出し、
前記値ΔＮと前記ノード数αの比較結果を基に、ＩＤ空間上の自身のノードＩＤから前記値ΔＮ台分のノードに対して問い合わせてデータを取得する
ことを特徴とするノード。 - 前記データ取得部は、
α＝０の場合、前記ＩＤ空間上で前記複製データが作成される方向である所定方向回りに前記値ΔＮ台分探索してデータを取得し、
α≦ΔＮの場合、前記所定方向回りに前記値ΔＮ台分探索し、前記所定方向回りと逆方向にα台分探索してデータを取得し、
α＞ΔＮの場合、前記所定方向回りと、当該所定方向回りと逆方向とにそれぞれ前記値ΔＮ台分探索してデータを取得すること
を特徴とする請求項１に記載のノード。 - 前記データ取得部は、
前記所定方向回りと逆方向の前記値ΔＮ台分の問い合わせについて、自身のノードＩＤと前記データＩＤの間に存在するノードに対してのみ行うこと
を特徴とする請求項１または請求項２に記載のノード。 - 前記データ取得部は、前記原本データを保持していない場合において、前記複製データの保持の有無を判定し、
前記複製データを保持している場合、自身のノードＩＤのＩＤ空間上の前記所定方向回りと逆方向に前記値ΔＮ台分のノードに対して問い合わせてデータを取得すること
を特徴とする請求項１ないし請求項３のいずれか１項に記載のノード。 - 前記データ取得部は、前記値ΔＮと前記ノード数αの比較結果を基に、
α≦ΔＮの場合、前記所定方向回りと逆方向に前記α台分探索してデータを取得し、
α＞ΔＮの場合、前記所定方向回りと逆方向に前記値ΔＮ台分探索してデータを取得すること
を特徴とする請求項４に記載のノード。 - コンピュータを請求項１ないし請求項５のいずれか１項に記載のノードとして機能させるためのプログラム。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2014040471A JP5845298B2 (ja) | 2014-03-03 | 2014-03-03 | ノードおよびプログラム |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2014040471A JP5845298B2 (ja) | 2014-03-03 | 2014-03-03 | ノードおよびプログラム |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2015165373A JP2015165373A (ja) | 2015-09-17 |
| JP5845298B2 true JP5845298B2 (ja) | 2016-01-20 |
Family
ID=54187839
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2014040471A Active JP5845298B2 (ja) | 2014-03-03 | 2014-03-03 | ノードおよびプログラム |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP5845298B2 (ja) |
-
2014
- 2014-03-03 JP JP2014040471A patent/JP5845298B2/ja active Active
Also Published As
| Publication number | Publication date |
|---|---|
| JP2015165373A (ja) | 2015-09-17 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US11288248B2 (en) | Performing file system operations in a distributed key-value store | |
| US11481139B1 (en) | Methods and systems to interface between a multi-site distributed storage system and an external mediator to efficiently process events related to continuity | |
| JP2021002369A (ja) | 索引更新パイプライン | |
| US11734248B2 (en) | Metadata routing in a distributed system | |
| US9367261B2 (en) | Computer system, data management method and data management program | |
| US10712964B2 (en) | Pre-forking replicas for efficient scaling of a distributed data storage system | |
| US20120278817A1 (en) | Event distribution pattern for use with a distributed data grid | |
| JP5969315B2 (ja) | データ移行処理システムおよびデータ移行処理方法 | |
| WO2015196692A1 (zh) | 一种云计算系统以及云计算系统的处理方法和装置 | |
| JP2014164554A (ja) | 負荷分散判定システム | |
| JP2013182575A (ja) | サーバおよびプログラム | |
| KR20130038517A (ko) | 분산된 컨테이너들을 사용하여 데이터를 관리하는 시스템 및 방법 | |
| JP5845298B2 (ja) | ノードおよびプログラム | |
| US20240176762A1 (en) | Geographically dispersed hybrid cloud cluster | |
| JP5918802B2 (ja) | ノードおよびプログラム | |
| JP5690296B2 (ja) | 負荷分散プログラムおよび負荷分散装置 | |
| JP6093320B2 (ja) | 分散処理システム | |
| JP5711771B2 (ja) | ノード離脱処理システム | |
| JP5815000B2 (ja) | ノードおよびプログラム | |
| JP6714547B2 (ja) | 負荷分散装置、負荷分散方法、および、負荷分散プログラム | |
| JP2011180658A (ja) | 分散ファイルシステムにおける冗長化方法 | |
| JP6506156B2 (ja) | ノードおよびグラビテーション抑止方法 | |
| JP6127005B2 (ja) | クラスタシステムのサーバ装置およびプログラム | |
| JP6093319B2 (ja) | クラスタシステム | |
| Xiao et al. | Applying MapReduce Framework to Peer-to-Peer Overlay Network |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20150929 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20151029 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20151117 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20151120 |
|
| R150 | Certificate of patent or registration of utility model |
Ref document number: 5845298 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 |