JP2017091248A - ノードおよびグラビテーション抑止方法 - Google Patents
ノードおよびグラビテーション抑止方法 Download PDFInfo
- Publication number
- JP2017091248A JP2017091248A JP2015221115A JP2015221115A JP2017091248A JP 2017091248 A JP2017091248 A JP 2017091248A JP 2015221115 A JP2015221115 A JP 2015221115A JP 2015221115 A JP2015221115 A JP 2015221115A JP 2017091248 A JP2017091248 A JP 2017091248A
- Authority
- JP
- Japan
- Prior art keywords
- node
- data
- space
- replication
- management 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.)
- Granted
Links
Images
Landscapes
- Computer And Data Communications (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
【課題】分散処理システムを構成するノードの減設時において、グラビテーション（原本移管）の発生を抑止し、システムの冗長度の復旧までの時間を短縮する。
【解決手段】分散処理システムを構成する各ノード１は、ＩＤ空間上における各ノード１の担当領域を示す振り分けＩＤ情報（振り分けＩＤテーブル２００）を記憶する記憶部３０と、ＩＤ空間上において自身の担当領域に位置する原本データを格納するノード１から、ＩＤ空間上で時計回りに最初に位置するノードおよび反時計回りに最初に位置するノードを、原本データの複製データを配置するノードに決定し、原本データの複製データを決定したノードに記憶させるレプリケーションデータ管理部１４とを備える。
【選択図】図３
【解決手段】分散処理システムを構成する各ノード１は、ＩＤ空間上における各ノード１の担当領域を示す振り分けＩＤ情報（振り分けＩＤテーブル２００）を記憶する記憶部３０と、ＩＤ空間上において自身の担当領域に位置する原本データを格納するノード１から、ＩＤ空間上で時計回りに最初に位置するノードおよび反時計回りに最初に位置するノードを、原本データの複製データを配置するノードに決定し、原本データの複製データを決定したノードに記憶させるレプリケーションデータ管理部１４とを備える。
【選択図】図３
Description
本発明は、ネットワーク上に分散配置されるノードをクラスタ化してデータを格納する分散処理システムにおいて、ノード減設時に原本データの複製を抑止する、ノードおよびグラビテーション抑止方法に関する。
近年、クラウドコンピューティングの隆盛に伴い、多量のデータの処理や保持を効率的に行うことが求められている。そこで、複数のサーバを協調動作させることにより効率的な処理を実現する分散処理技術が発展している。
分散処理を行う際には、クラスタ構成からなる分散処理システムを構成する各サーバ（以下、「ノード」と称する。）が担当するデータを決定する必要がある。このとき、分散処理システム全体での処理能力を高めるためには、各ノードが担当するデータ数は平均化されていることが望ましい。
代表的なデータの管理手法として、各データのｋｅｙをハッシュ関数にかけた値（以下、「ｈａｓｈ（ｋｅｙ）」と称する。）をノード数Ｎで割った余り、即ち「ｈａｓｈ（ｋｅｙ） ｍｏｄ Ｎ」を番号として持つノードがデータを管理する手法がある。この場合、各ノードに事前に「０」から「Ｎ−１」までの番号を割り当てていることが前提となる。このような管理手法を用いた場合、ノードの追加・離脱が発生すると、Ｎの値が変化して、多くのデータについて、そのデータの保存を担当するノードが変更になるため、担当するデータを再配置することが必要になる。
そこで、ノードの追加・離脱に伴い担当するノードが変更になるデータ数を約１／Ｎに抑える方法として、コンシステント・ハッシュ（Consistent Hashing）法（非特許文献１参照）を用いたデータ管理手法がある。このコンシステント・ハッシュ法は、Amazon Dynamo（非特許文献２参照）等において用いられている。
このコンシステント・ハッシュ法を用いたデータ管理手法では、ノードとデータの双方にＩＤ（IDentifier）を割り当てる。そして、データのＩＤから閉じたＩＤ空間を時計回りに辿った場合に最初に当たったノードをそのデータの担当とする。ノードに対するＩＤの与え方の例としては、ＩＰアドレスをハッシュ関数にかけた値（ｈａｓｈ（ＩＰアドレス））が挙げられる。
クラスタ構成の分散処理システムでは、各ノードの処理性能が等しい場合には、各ノードが担当するデータ量を等しくする、即ち、コンシステント・ハッシュ法のＩＤ空間（以下、単に「ＩＤ空間」と称する場合がある。）におけるノード間の距離（以下、「ノードの担当領域」と称する。）を等しくすることが望ましい。この点を実現するため、各ノードに仮想的に複数のＩＤを持たせる手法が用いられている（非特許文献３参照）。各ノードが複数の仮想ＩＤを持つことで、仮想ＩＤ毎の担当領域の大きさは異なっていても、大数の法則に従いノード毎の担当領域の大きさは平均化される。
David Karger, et al.,"Consistent Hashing and Random Trees:Distributed Caching Protocols for Relieving Hot Spots on the World Wide Web"，［online］，1997，ACM，［平成27年10月21日検索］，インターネット<ＵＲＬ:http://www.akamai.com/dl/technical_publications/ConsistenHashingandRandomTreesDistributedCachingprotocolsforrelievingHotSpotsontheworldwideweb.pdf>
Giuseppe DeCandia，et al.，"Dynamo: Amazon’s Highly Available Key-value Store"， SOSP’07, October 14-17, 2007, Stevenson, Washington, USA，［online］，［平成27年10月21日検索］，インターネット<ＵＲＬ:http://www.allthingsdistributed.com/files/amazon-dynamo-sosp2007.pdf>
入江 道生、他４名、「コンシステント・ハッシュ法におけるデータの複製を意識した負荷分散手法」、社団法人電子情報通信学会、2010年10月、信学技報、IN2010-77、P.69-74
このコンシステント・ハッシュ法を用いた分散システムにおいては、コンシステント・ハッシュのＩＤ空間上での時計回り探索により、各ノードの担当領域が決定される。よって、冗長度を保つためには、あるデータ（原本データ）の複製データを、ＩＤ空間上において時計回りで次に位置するノードに順次配置する。そして、あるノードが、何らかの事由で減設された場合には、減設ノードのＩＤ空間上で時計回りに位置するノードに担当領域の移譲が行われる。
しかしながら、ＩＤ空間上において減設ノードの時計回りで次のノードに単純に担当領域を移譲すると、そのノードの負荷が急増するため、減設ノードの時計回りに次のノードと、減設ノードの反時計回りに次のノードとで、担当領域を分割（２分割）し、減設ノードの時計回りに次のノードの負荷を軽減し、負荷分散する処理が行われる。このとき、減設ノードの担当領域を引き継ぐ反時計回りで次のノードは、必ずグラビテーション（原本移管）が発生し、システム全体として冗長度を回復するまでに時間がかかるという問題があった。ここで、グラビテーション（原本移管）とは、他ノードの複製データを用いて減設ノードが担当していた原本データの復旧を図る処理をいう。
図１０は、上記の課題を説明するための図である。
図１０（ａ）に示すように、原本データ「Ｇ１」「Ｇ２」がＩＤ空間上においてノード「Ｄ」の担当領域に配置され、その複製データ「ｇ１」「ｇ２」がＩＤ空間上で時計回りに次のノードであるノード「Ｅ」と、さらにその次のノード（次々ノード）であるノード「Ａ」に配置されているものとする。この場合において、ノード「Ｄ」が減設された場合を考える。
図１０（ａ）に示すように、原本データ「Ｇ１」「Ｇ２」がＩＤ空間上においてノード「Ｄ」の担当領域に配置され、その複製データ「ｇ１」「ｇ２」がＩＤ空間上で時計回りに次のノードであるノード「Ｅ」と、さらにその次のノード（次々ノード）であるノード「Ａ」に配置されているものとする。この場合において、ノード「Ｄ」が減設された場合を考える。
図１０（ａ）に示す場合において、ノード「Ｄ」が減設すると、ノード「Ｄ」のＩＤ空間上での担当領域は、原則として、時計回りに次のノードであるノード「Ｅ」に引き継がれる。しかしながら、そのままではノード「Ｅ」の負荷が増大してしまうため、ここでは、ノード「Ｃ」の担当領域を増大させるようにＩＤ空間上で時計回り方向にノード「Ｃ」のＩＤを移動することにより、過度にノード「Ｅ」の負荷が増大しないような負荷分散処理を実行する。
ここで、図１０（ｂ）に示すように、減設されたノード「Ｄ」が保持していた原本データ「Ｇ１」については、ノード「Ｅ」が複製データ「ｇ１」を保持しているため、その複製データを原本データに昇格させるだけでよい。なお、ノード「Ｅ」は、複製データ「ｇ１」を原本データ「Ｇ１」に昇格させた後で、レプリケーション（データの一貫性を保つためのデータ複製処理）を実行する。
一方、減設されたノード「Ｄ」が保持していた原本データ「Ｇ２」については、ノード「Ｃ」が複製データ「ｇ２」を保持していないため、その複製データ「ｇ２」を保持する例えばノード「Ｅ」からのグラビテーション（原本移管）を行う。これにより、ノード「Ｃ」は、原本データを保持することができる。なお、ノード「Ｃ」は、グラビテーションの終了後に、レプリケーションを実行する。
一方、減設されたノード「Ｄ」が保持していた原本データ「Ｇ２」については、ノード「Ｃ」が複製データ「ｇ２」を保持していないため、その複製データ「ｇ２」を保持する例えばノード「Ｅ」からのグラビテーション（原本移管）を行う。これにより、ノード「Ｃ」は、原本データを保持することができる。なお、ノード「Ｃ」は、グラビテーションの終了後に、レプリケーションを実行する。
つまり、減設ノードの反時計回りに位置するノードが、減設ノードの担当領域を引き継ぐ場合には、原本データを保持していないため、必ずグラビテーション（原本移管）が発生する。これにより、複製データを原本昇格させる場合に比べて、グラビテーションにより原本を復旧させるため時間がかかるという問題があった。
このような背景を鑑みて本発明がなされたのであり、本発明は、分散処理システムを構成するノードの減設時において、グラビテーション（原本移管）の発生を抑止し、システムの冗長度の復旧までの時間を短縮することができる、ノードおよびグラビテーション抑止方法を提供することを課題とする。
前記した課題を解決するため、請求項１に記載の発明は、クラスタを構成する複数のノードそれぞれに、コンシステント・ハッシュ法によりデータを振り分けて処理させる分散処理システムの前記ノードであって、ＩＤ空間上における各ノードの担当領域を示す振り分けＩＤ情報を記憶する記憶部と、前記ＩＤ空間上において自身の前記担当領域に位置する原本データを格納するノードから、前記ＩＤ空間上で時計回りに最初に位置するノードおよび反時計回りに最初に位置するノードを、前記原本データの複製データを配置するノードに決定し、前記原本データの複製データを前記決定したノードに記憶させるレプリケーションデータ管理部と、を備えることを特徴とするノードとした。
また、請求項３に記載の発明は、クラスタを構成する複数のノードそれぞれに、コンシステント・ハッシュ法によりデータを振り分けて処理させる分散処理システムの前記ノードのグラビテーション抑止方法であって、前記ノードが、ＩＤ空間上における各ノードの担当領域を示す振り分けＩＤ情報を記憶部に記憶しており、前記ＩＤ空間上において自身の前記担当領域に位置する原本データを格納するノードから、前記ＩＤ空間上で時計回りに最初に位置するノードおよび反時計回りに最初に位置するノードを、前記原本データの複製データを配置するノードに決定し、前記原本データの複製データを前記決定したノードに記憶させるステップを実行することを特徴とするグラビテーション抑止方法とした。
このようにすることで、分散処理システムを構成するノードは、自身の担当領域に位置する原本データの複製データの配置先を、ＩＤ空間上において自身のノードから時計回りに最初に位置するノードおよび反時計回りに最初に位置するノードに決定し、複製データを記憶させることができる。
よって、ノード減設時において、減設ノードの担当領域を引き継ぐノードには必ず複製データが配置されていることになるため、グラビテーション（原本移管）を抑止し、システムの冗長度回復までの時間を短縮することができる。
よって、ノード減設時において、減設ノードの担当領域を引き継ぐノードには必ず複製データが配置されていることになるため、グラビテーション（原本移管）を抑止し、システムの冗長度回復までの時間を短縮することができる。
請求項２に記載の発明は、前記振り分けＩＤ情報の更新情報を受信した場合に、前記レプリケーションデータ管理部は、受信した更新情報の前記振り分けＩＤ情報で示される自身のノードの前記ＩＤ空間上の担当領域において前記複製データとして記憶しているデータを前記原本データに昇格させることを特徴とする請求項１に記載のノードとした。
このようにすることで、ノードは、ＩＤ空間上での自身の担当領域が更新され、それまで複製データとして保持していたデータが自身の担当領域に含まれるデータに変更された場合に、その複製データを原本データに昇格させることができる。
よって、ノードは、複製データを原本データに昇格し、即時にレプリケーションを実行することが可能となる。
よって、ノードは、複製データを原本データに昇格し、即時にレプリケーションを実行することが可能となる。
本発明によれば、分散処理システムを構成するノードの減設時において、グラビテーション（原本移管）の発生を抑止し、システムの冗長度の復旧までの時間を短縮する、ノードおよびグラビテーション抑止方法を提供することができる。
＜全体構成＞
まず、本発明を実施するための形態（以下、「本実施形態」と称する。）に係るノード１を含む分散処理システム１０００について説明する。
図１は、本実施形態に係るノード１を含む分散処理システム１０００の全体構成を示す図である。
まず、本発明を実施するための形態（以下、「本実施形態」と称する。）に係るノード１を含む分散処理システム１０００について説明する。
図１は、本実施形態に係るノード１を含む分散処理システム１０００の全体構成を示す図である。
この分散処理システム１０００は、複数のノード１から構成される。各ノード１は、コンピュータなどの物理装置や仮想マシンなどの論理装置である。ロードバランサ３は、クライアント２から受信したメッセージを、単純なラウンドロビン等により振り分けて各ノード１に送信する。そして、ノード１の振り分け部１２は、クライアント２からのメッセージを、例えば、コンシステント・ハッシュ法等に基づき、メッセージを担当するノード１に振り分ける。メッセージを担当するノード１では、信号処理部１３において、信号処理を行い、クライアント２にサービスを提供する。
なお、ロードバランサ３が存在せず、クライアント２から任意のノード１（振り分け部１２）にメッセージを送信することも可能である。また、振り分け部１２と信号処理部１３とは、同じノード１上に同時に存在してもよいし、別々のノード１上に存在してもよい。
＜ノード＞
次に、分散処理システム１０００を構成するノード１について、具体的に説明する。
次に、分散処理システム１０００を構成するノード１について、具体的に説明する。
≪概要≫
まず、本実施形態に係るノード１の処理の概要を説明する。
本実施形態に係るノード１は、前記したように、分散処理システム１０００を構成するノードの減設時において、グラビテーション（原本移管）が発生しないようにするため、自身が保持する原本データの複製データを、従来技術のように、ＩＤ空間上で時計回り方向に位置するノードだけでなく、ＩＤ空間上で反時計回り方向に位置するノードにも配置する。このようにすることにより、減設ノードの担当領域が、減設ノードの時計回り側のノードと、減設ノードの反時計回り側のノードとで、分割された場合においても、グラビテーションの発生を抑止することができる。
まず、本実施形態に係るノード１の処理の概要を説明する。
本実施形態に係るノード１は、前記したように、分散処理システム１０００を構成するノードの減設時において、グラビテーション（原本移管）が発生しないようにするため、自身が保持する原本データの複製データを、従来技術のように、ＩＤ空間上で時計回り方向に位置するノードだけでなく、ＩＤ空間上で反時計回り方向に位置するノードにも配置する。このようにすることにより、減設ノードの担当領域が、減設ノードの時計回り側のノードと、減設ノードの反時計回り側のノードとで、分割された場合においても、グラビテーションの発生を抑止することができる。
具体的には、図２（ａ）に示すように、原本データ「Ｇ１」「Ｇ２」がＩＤ空間上においてノード「Ｄ」の担当領域に配置される場合において、その複製データ「ｇ１」「ｇ２」を、ＩＤ空間上で時計回り側の次の（最初の）ノードであるノード「Ｅ」と、ＩＤ空間上で反時計回り側の次の（最初の）ノードであるノード「Ｃ」とに配置する。
図２（ａ）に示す場合において、ノード「Ｄ」が減設すると、ノード「Ｄ」の担当領域は、負荷分散処理が実行されることにより分割され、ノード「Ｅ」とノード「Ｃ」とが担当することとなる。
ここで、図２（ｂ）に示すように、減設されたノード「Ｄ」が保持していた原本データ「Ｇ１」については、ノード「Ｅ」が複製データを保持しているため、その複製データを原本データに昇格させるだけでよい。なお、ノード「Ｅ」は、複製データを原本データに昇格させた後で、レプリケーション（データの一貫性を保つためのデータ複製処理）を実行する。ノード「Ｅ」は、ＩＤ空間上で時計回り方向に位置するノード「Ａ」と、ＩＤ空間上で反時計回り方向に位置するノード「Ｃ」に、複製データを送信するレプリケーションを実行する。
また、減設されたノード「Ｄ」が保持していた原本データ「Ｇ２」についても、本実施形態においては、ノード「Ｃ」が複製データを保持しているため、その複製データを原本データに昇格させるだけでよい。つまり、図１０（ｂ）で示したような、グラビテーション（原本移管）は発生しない。なお、ノード「Ｃ」は、複製データを原本データに昇格させた後で、レプリケーションを実行する。ノード「Ｃ」は、ＩＤ空間上で時計回り方向に位置するノード「Ｅ」と、ＩＤ空間上で反時計回り方向に位置するノード「Ｂ」に、複製データを送信するレプリケーションを実行する。
上記のようにすることにより、本実施形態に係るノード１は、分散処理システム１０００を構成するノード１の減設時において、グラビテーション（原本移管）の発生を抑止し、システムの冗長度の復旧までの時間を短縮することができる。また、冗長度回復の際に、グラビテーション（原本移管）が発生しないため、データ転送のトラフィックの増加や、ＣＰＵ（Central Processing Unit）使用率の増加を防ぐことができる。
≪ノードの構成≫
次に、本実施形態に係る分散処理システム１０００を構成するノード１について、具体的に説明する。なお、本実施形態に係るノード１は、分散処理システム１０００の複数のノード１のうち、後記するノード識別子管理テーブル１００（図４参照）および振り分けＩＤテーブル２００（図５参照）を管理する特権ノードとなる場合と、特権ノードからノード識別子管理テーブル１００および振り分けＩＤテーブル２００の情報を受け取り自身のノード識別子管理テーブル１００および振り分けＩＤテーブル２００を更新する非特権ノードとなる場合とが存在する。なお、特権ノードが行う処理等については、後記する。
次に、本実施形態に係る分散処理システム１０００を構成するノード１について、具体的に説明する。なお、本実施形態に係るノード１は、分散処理システム１０００の複数のノード１のうち、後記するノード識別子管理テーブル１００（図４参照）および振り分けＩＤテーブル２００（図５参照）を管理する特権ノードとなる場合と、特権ノードからノード識別子管理テーブル１００および振り分けＩＤテーブル２００の情報を受け取り自身のノード識別子管理テーブル１００および振り分けＩＤテーブル２００を更新する非特権ノードとなる場合とが存在する。なお、特権ノードが行う処理等については、後記する。
ノード１は、図１に示したように、ロードバランサ３と通信可能に接続されるともに、クラスタを構成する自身以外の他のノード１と通信可能に接続される。また、このノード１は、ロードバランサ３を介してクライアント２からメッセージを受け取ると、そのメッセージを、担当するノード１（自身を含む）に振り分け、そのメッセージの信号処理を実行する。また、特権ノードとなるノード１は、分散処理システム１０００に属するノード１の減設・増設に関する情報を受信し、既存の負荷分散処理（負荷分散ロジック）に基づき、ＩＤ空間上において対象となるノード１のノードＩＤを変更（具体的には、後記する振り分けＩＤテーブル２００を更新）して、負荷の偏りの低減を実現する。また、特権ノードから変更された振り分けＩＤテーブル２００を受信した各ノード１は、新たに自身が原本データを保持することとなったデータについて、複製データを原本データに昇格させる処理を実行するとともに、複製データを送信するレプリケーションを実行する。
図３は、本実施形態に係るノード１の構成例を示す機能ブロック図である。
図３に示すように、ノード１は、制御部１０と、入出力部２０と、記憶部３０とを含んで構成される。
図３に示すように、ノード１は、制御部１０と、入出力部２０と、記憶部３０とを含んで構成される。
入出力部２０は、ロードバランサ３や、自身以外の他のノード１との間の情報の入出力を行う。また、この入出力部２０は、通信回線を介して情報の送受信を行う通信インタフェース（図示省略）と、キーボード等の入力手段やモニタ等の出力手段等との間で入出力を行う入出力インタフェース（図示省略）とから構成される。
記憶部３０は、ハードディスクやフラッシュメモリ、ＲＡＭ（Random Access Memory）等の記憶手段からなり、処理の対象となるデータ３００や、ノード識別子管理テーブル１００（図４参照）、振り分けＩＤテーブル（振り分けＩＤ情報）２００（図５参照）等が記憶される。なお、この記憶部３０に記憶される各情報についての詳細は後記する。
制御部１０は、ノード１全体の制御を司り、ノード識別子管理部１１、振り分け部１２、信号処理部１３、レプリケーションデータ管理部１４を含んで構成される。なお、この制御部１０は、例えば、記憶部３０に格納されたプログラムをＣＰＵ（図示省略）がＲＡＭ（図示省略）に展開し実行することで実現される。
ノード識別子管理部１１は、分散処理システム１０００においてクラスタを構成する各ノード１のノード情報（ＩＰアドレス等）および各ノード１が担当するＩＤ空間を管理する。
具体的には、ノード識別子管理部１１は、自身が属する分散処理システム１０００へのノードの離脱（減設）や追加（増設）が発生した場合に、その情報を外部から受信し、分散処理システム１０００を構成するノード１の識別情報等が記憶されたノード識別子管理テーブル１００（図４）を更新する。
具体的には、ノード識別子管理部１１は、自身が属する分散処理システム１０００へのノードの離脱（減設）や追加（増設）が発生した場合に、その情報を外部から受信し、分散処理システム１０００を構成するノード１の識別情報等が記憶されたノード識別子管理テーブル１００（図４）を更新する。
図４は、本実施形態に係るノード識別子管理テーブル１００のデータ構成例を示す図である。
図４に示すように、ノード識別子管理テーブル１００には、分散処理システム１０００を構成する各ノード１のノード識別子１０１とアドレス１０２（例えば、ＩＰアドレス）とが対応付けられて格納される。
図４に示すように、ノード識別子管理テーブル１００には、分散処理システム１０００を構成する各ノード１のノード識別子１０１とアドレス１０２（例えば、ＩＰアドレス）とが対応付けられて格納される。
このノード識別子１０１は、例えば、当該分散処理システム１０００内において予め設定される特定のノード（例えば、ノード識別子１０１の昇順に設定）のノード識別子管理部１１で付与され、当該分散処理システム１０００内の各ノード１に配信される。なお、このノード識別子１０１は、コンシステント・ハッシュのＩＤ空間において仮想ＩＤを用いる場合、仮想ＩＤ毎に付与される。
また、ノード識別子管理部１１は、ノード１の減設・増設についての情報を受信した場合に、既存の負荷分散処理を実行し、当該分散処理システム１０００内の各ノード１の負荷ができるだけ分散されるように、各ノード１のＩＤ空間上の担当領域を変更する。
具体的には、ノード識別子管理部１１は、既存のノード１が減設した場合には、例えば、その減設ノードのＩＤ空間上において時計回りで次のノード１と、減設ノードのＩＤ空間上において反時計回りで次のノードとで、担当領域を２分割するように、減設ノードの反時計回りで次のノードの担当領域を変更する。
また、ノード識別子管理部１１は、新たなノード１を増設した場合には、例えば、既存の各ノード１のＩＤ空間上の担当領域の大きさを検索し、担当領域が最も大きいノード１の担当領域を２分割するＩＤ空間上の位置に、新たなノード１を配置する。
ノード識別子管理部１１は、既存の負荷分散処理を実行することにより得られたノードＩＤの変更情報に基づき、ノード識別子管理テーブル１００を更新（ノード１の減設・増設を反映）し、さらに、ノード１のＩＤ空間上での担当領域を変更するため、振り分けＩＤテーブル２００（図５）を更新する。
具体的には、ノード識別子管理部１１は、既存のノード１が減設した場合には、例えば、その減設ノードのＩＤ空間上において時計回りで次のノード１と、減設ノードのＩＤ空間上において反時計回りで次のノードとで、担当領域を２分割するように、減設ノードの反時計回りで次のノードの担当領域を変更する。
また、ノード識別子管理部１１は、新たなノード１を増設した場合には、例えば、既存の各ノード１のＩＤ空間上の担当領域の大きさを検索し、担当領域が最も大きいノード１の担当領域を２分割するＩＤ空間上の位置に、新たなノード１を配置する。
ノード識別子管理部１１は、既存の負荷分散処理を実行することにより得られたノードＩＤの変更情報に基づき、ノード識別子管理テーブル１００を更新（ノード１の減設・増設を反映）し、さらに、ノード１のＩＤ空間上での担当領域を変更するため、振り分けＩＤテーブル２００（図５）を更新する。
図５は、本実施形態に係る振り分けＩＤテーブル（振り分けＩＤ情報）２００のデータ構成例を示す図である。
図５に示すように、振り分けＩＤテーブル２００には、ノード識別子２０１に対応付けて、そのノード１が担当するＩＤ空間２０２（担当領域）が格納される。このノード識別子２０１は、図４のノード識別子１０１と同様の情報である。図５に示す例では、ＩＤ空間の全ＩＤ数が「０」〜「９９９」の１０００であり、例えば、ノード識別子２０１が「Ａ」のノード１が、担当するＩＤ空間２０２として「０〜１９９」について担当することを示している。また、この振り分けＩＤテーブル２００において、ノード識別子２０１が「Ａ」のノード１（ノード「Ａ」）のＩＤ空間上のノードＩＤは、「１９９」であり、以下同様に、ノード「Ｂ」のＩＤ空間上でのノードＩＤは「３９９」であり、ノード「Ｃ」のＩＤ空間上でのノードＩＤは「５９９」であり、ノード「Ｄ」のＩＤ空間上でのノードＩＤは「７９９」であり、ノード「Ｅ」のＩＤ空間上でのノードＩＤは「９９９」である。そして、ノード識別子管理部１１は、振り分けＩＤテーブル２００において、各ノード１のノードＩＤを昇順にソートし、連続したＩＤ空間２０２として管理する。
図５に示すように、振り分けＩＤテーブル２００には、ノード識別子２０１に対応付けて、そのノード１が担当するＩＤ空間２０２（担当領域）が格納される。このノード識別子２０１は、図４のノード識別子１０１と同様の情報である。図５に示す例では、ＩＤ空間の全ＩＤ数が「０」〜「９９９」の１０００であり、例えば、ノード識別子２０１が「Ａ」のノード１が、担当するＩＤ空間２０２として「０〜１９９」について担当することを示している。また、この振り分けＩＤテーブル２００において、ノード識別子２０１が「Ａ」のノード１（ノード「Ａ」）のＩＤ空間上のノードＩＤは、「１９９」であり、以下同様に、ノード「Ｂ」のＩＤ空間上でのノードＩＤは「３９９」であり、ノード「Ｃ」のＩＤ空間上でのノードＩＤは「５９９」であり、ノード「Ｄ」のＩＤ空間上でのノードＩＤは「７９９」であり、ノード「Ｅ」のＩＤ空間上でのノードＩＤは「９９９」である。そして、ノード識別子管理部１１は、振り分けＩＤテーブル２００において、各ノード１のノードＩＤを昇順にソートし、連続したＩＤ空間２０２として管理する。
なお、本実施形態においては、閉じたＩＤ空間上において各ＩＤを時計回りに配置し、データのＩＤから時計回りに辿った場合に最初に当たったノードをそのデータの担当として説明する。しかしながら、ＩＤ空間上において各ＩＤを反時計回りに配置し、データのＩＤから反時計回りに辿った場合に最初に当たったノードをそのデータの担当とするように構成してもよい。つまり、所定の方向回りにＩＤ空間上におけるＩＤを設定することができる。
分散処理システム１０００内の特権ノードのノード識別子管理部１１は、各ノード１に対して、最新のノード識別子管理テーブル１００および振り分けＩＤテーブル２００を送信する。これにより、各ノード１のノード識別子管理部１１は、ノード識別子管理テーブル１００および振り分けＩＤテーブル２００を常に最新の状態に更新して保持する。このようにすることにより、分散処理システム１０００内の各ノード１には、同一のノード識別子管理テーブル１００および振り分けＩＤテーブル２００が保持される。
また、特権ノードは、例えば、このノード識別子管理テーブル１００（図４）の一番上の行のノード１から順に、特権ノードとなるように設定される。ノード１が新たに特権ノードになった場合、自身が特権ノードであることを示す情報を、各ノード１等に送信する。そして、特権ノードは、クラスタ内のノード１について、ＩＤ空間上での配置変更（ノードＩＤの変更等）があった場合に、自身の振り分けＩＤテーブル２００を更新し、その更新情報を、各ノード１に配信する。
図３に戻り、振り分け部１２は、ロードバランサ３等を介してクライアント２から受信したメッセージ内の情報（「振り分けキー」）をもとに「ｈａｓｈ（ｋｅｙ）」を算出し、振り分けＩＤテーブル２００を参照して、そのメッセージの処理を担当するノード１を特定する。そして、振り分け部１２は、特定したノード１のアドレスの情報を、ノード識別子管理テーブル１００を参照して取得し、特定したノード１へメッセージの振り分け（送信）を行う。
信号処理部１３は、自身のノード１が担当するデータに関するメッセージの信号処理を実行する。
この信号処理部１３は、信号処理後に送付するメッセージに、例えば、ＳＩＰ（Session Initiation Protocol）においては「Call-id」をもとに算出したハッシュ値を振り分けキーとして埋め込む（ＳＩＰにおいては、例えばTo/FromヘッダのTagに記載する。）ようにしてもよい。これにより、振り分け部１２がそのメッセージの後続呼を受信した場合に、振り分けキーとして埋め込まれたハッシュ値を用いて、ノード識別子管理テーブル１００（図４）を参照し、その後続呼を担当するノード１を特定することができる。
この信号処理部１３は、信号処理後に送付するメッセージに、例えば、ＳＩＰ（Session Initiation Protocol）においては「Call-id」をもとに算出したハッシュ値を振り分けキーとして埋め込む（ＳＩＰにおいては、例えばTo/FromヘッダのTagに記載する。）ようにしてもよい。これにより、振り分け部１２がそのメッセージの後続呼を受信した場合に、振り分けキーとして埋め込まれたハッシュ値を用いて、ノード識別子管理テーブル１００（図４）を参照し、その後続呼を担当するノード１を特定することができる。
レプリケーションデータ管理部１４は、特権ノードから振り分けＩＤテーブル２００の更新情報を受信した場合に、更新された振り分けＩＤテーブル２００において示される自身の担当領域を抽出し、当該担当領域のデータを複製データとして保持している場合に、原本データに昇格する処理を実行する。そして、複製データから新たに昇格した原本データについて、複製データを送信する他のノード１を決定し、その決定したノード１に対してレプリケーションを実行する。このとき、レプリケーションデータ管理部１４は、冗長度が「３」以上（つまり、原本データが「１」、複製データが「２」以上）の場合において、ＩＤ空間上で時計回り側に次の（最初の）ノードと、反時計回り側に次の（最初の）ノードとを、必ず複製データを送信するノード１（配信先ノード）として含めた上で決定する。なお、レプリケーションデータ管理部１４は、新たにデータが追加され、自身が原本データとして保持する場合においても、複製データを送信する他のノード１を同様に決定し、その決定したノード１に対してレプリケーションを実行する。
具体的は、レプリケーションデータ管理部１４は、以下に示す処理を実行する。
具体的は、レプリケーションデータ管理部１４は、以下に示す処理を実行する。
レプリケーションデータ管理部１４は、特権ノードから振り分けＩＤテーブル２００（図５）の更新情報を受信した場合に、記憶部３０内のデータ３００に格納されるデータ属性情報３１０（図６）を参照して、自身の担当領域となっているＩＤ空間に位置するデータの中から、複製データとして保持しているデータを抽出し、原本データに昇格させる。
図６は、本実施形態に係るデータ属性情報３１０のデータ構成例を示す図である。
図６に示すように、データ属性情報３１０には、データ番号３１１に対応付けて、そのデータのデータ識別子（ハッシュ値）３１２、レプリカフラグ３１３、データへのアクセス（ポインタ）３１４が格納される。
図６に示すように、データ属性情報３１０には、データ番号３１１に対応付けて、そのデータのデータ識別子（ハッシュ値）３１２、レプリカフラグ３１３、データへのアクセス（ポインタ）３１４が格納される。
データ番号３１１は、当該データを保持するノード１において固有なデータの識別番号であり、「０」、「１」、・・・等が格納される。なお、図６においては、「０」〜「ｎ−１」のｎ個のデータが格納される例を示している。
データ識別子（ハッシュ値）３１２は、各データをＩＤ空間上において一意に特定するための識別子であり、ここでは、ＩＤ空間上に配置されるそのデータのハッシュ値が格納される。
データ識別子（ハッシュ値）３１２は、各データをＩＤ空間上において一意に特定するための識別子であり、ここでは、ＩＤ空間上に配置されるそのデータのハッシュ値が格納される。
レプリカフラグ３１３は、ノード１が保持するデータが、原本データであるか、または、複製データであるか、を識別するためのフラグである。レプリカフラグ３１３が「０」の場合は、そのデータを原本データとして保持していることを示す。また、レプリカフラグ３１３が「１」の場合は、そのデータを複製データとして保持していることを示す。
データへのアクセス（ポインタ）３１４は、当該データの実体を記憶している記憶部３０（ハードディスク等）の位置情報を示す。
このデータ属性情報３１０には、新たなデータを保存する度に、１行（１レコード）の情報がレプリケーションデータ管理部１４により格納される。
データへのアクセス（ポインタ）３１４は、当該データの実体を記憶している記憶部３０（ハードディスク等）の位置情報を示す。
このデータ属性情報３１０には、新たなデータを保存する度に、１行（１レコード）の情報がレプリケーションデータ管理部１４により格納される。
レプリケーションデータ管理部１４は、特権ノードから振り分けＩＤテーブル２００（図５）の更新情報を受信した場合に、そのノード１自身のＩＤ空間上の担当領域の情報を取得し、データ属性情報３１０のデータ識別子（ハッシュ値）３１２を参照して、その担当領域に含まれるデータを抽出する。そして、レプリケーションデータ管理部１４は、抽出したデータの中から、レプリカフラグ３１３が「１」（複製データ）であるデータを検索し、その検索した結果得られたデータ（複製データ）を、原本データに昇格させる。具体的には、レプリケーションデータ管理部１４は、そのデータのレプリカフラグ３１３を「１」から「０」に変更する（図６の符号α参照）。
また、レプリケーションデータ管理部１４は、新たな原本データを格納した場合（上記の原本昇格した原本データも含む）、その原本データの複製データを格納するノード１（複製データの配置先ノード）を決定する。このとき、レプリケーションデータ管理部１４は、冗長度が「３」以上の場合において、ＩＤ空間上で時計回り側に次のノードと、反時計回り側に次のノードとを、複製データを送信するノード１として含めた上で決定する。このレプリケーションデータ管理部１４による、複製データの配置先ノード決定処理についての詳細は後記する。
なお、レプリケーションデータ管理部１４は、冗長度が「２」の場合には、原則として自身の時計回りで次のノード１に複製データを格納するように決定する。また、冗長度が「４」以上の場合においては、ＩＤ空間上で時計回り側に次のノードと、反時計回り側に次のノードとを、複製データを送信するノード１として決定した後、時計回りにその次のノード１から複製ノードを順次格納するか、反時計回りにその次のノード１から複製ノードを順次格納するか、他のノード１の中からランダムに選んだノード１に複製ノードを格納するか等のロジックを予め設定しておく。レプリケーションデータ管理部１４は、複製データを格納することを決定したノード１に対してレプリケーションを実行する。
なお、レプリケーションデータ管理部１４は、冗長度が「２」の場合には、原則として自身の時計回りで次のノード１に複製データを格納するように決定する。また、冗長度が「４」以上の場合においては、ＩＤ空間上で時計回り側に次のノードと、反時計回り側に次のノードとを、複製データを送信するノード１として決定した後、時計回りにその次のノード１から複製ノードを順次格納するか、反時計回りにその次のノード１から複製ノードを順次格納するか、他のノード１の中からランダムに選んだノード１に複製ノードを格納するか等のロジックを予め設定しておく。レプリケーションデータ管理部１４は、複製データを格納することを決定したノード１に対してレプリケーションを実行する。
＜処理の流れ＞
次に、本実施形態に係るノード１が実行する、グラビテーション抑止方法に基づく処理の流れについて説明する。
図７は、本実施形態に係るノード１が実行するグラビテーションを抑止する処理の流れを示すフローチャートである。
次に、本実施形態に係るノード１が実行する、グラビテーション抑止方法に基づく処理の流れについて説明する。
図７は、本実施形態に係るノード１が実行するグラビテーションを抑止する処理の流れを示すフローチャートである。
まず、特権ノードが、分散処理システム１０００を構成するノード１のうちのいずれかのノード１が減設されたことを示す情報を取得する（ステップＳ１）。ここでノード１（特権ノード）のノード識別子管理部１１は、分散処理システム１０００の管理装置から特定ノードの減設指示を受信したり、各ノード１の死活監視を行い特定のノード１が減設したことを検知したりすることにより、ノード１の減設（減設ノード）を認識することができる。
続いて、特権ノードのノード識別子管理部１１は、減設ノードをノード識別子管理テーブル１００（図４）から削除する更新を実行する。
また、ノード識別子管理部１１は、既存の負荷分散処理を実行し、各ノード１の負荷ができるだけ分散されるように、各ノード１のＩＤ空間上の担当領域を変更する。例えば、ノード識別子管理部１１は、その減設ノードのＩＤ空間上において時計回りで次のノード１と、減設ノードのＩＤ空間上において反時計回りで次のノードとで、減設ノードの担当領域を２分割するように、減設ノードの反時計回りで次のノードの担当領域を変更する。具体的には、ノード識別子管理部１１は、振り分けＩＤテーブル２００（図５）において、減設ノードのレコードを削除した上で、減設ノードの反時計回りで次のノードのＩＤ空間と、減設ノードの時計回りで次のノードのＩＤ空間とを更新する（ステップＳ２）。
そして、特権ノードのノード識別子管理部１１は、更新したノード識別子管理テーブル１００（図４）および更新した振り分けＩＤテーブル２００（図５）を、更新情報として分散処理システム１０００内の各ノード１に送信する（ステップＳ３）。
また、ノード識別子管理部１１は、既存の負荷分散処理を実行し、各ノード１の負荷ができるだけ分散されるように、各ノード１のＩＤ空間上の担当領域を変更する。例えば、ノード識別子管理部１１は、その減設ノードのＩＤ空間上において時計回りで次のノード１と、減設ノードのＩＤ空間上において反時計回りで次のノードとで、減設ノードの担当領域を２分割するように、減設ノードの反時計回りで次のノードの担当領域を変更する。具体的には、ノード識別子管理部１１は、振り分けＩＤテーブル２００（図５）において、減設ノードのレコードを削除した上で、減設ノードの反時計回りで次のノードのＩＤ空間と、減設ノードの時計回りで次のノードのＩＤ空間とを更新する（ステップＳ２）。
そして、特権ノードのノード識別子管理部１１は、更新したノード識別子管理テーブル１００（図４）および更新した振り分けＩＤテーブル２００（図５）を、更新情報として分散処理システム１０００内の各ノード１に送信する（ステップＳ３）。
続いて、各ノード１のノード識別子管理部１１は、受信した更新情報（ノード識別子管理テーブル１００および振り分けＩＤテーブル２００）を用いて、自身の記憶部３０に記憶されたノード識別子管理テーブル１００および振り分けＩＤテーブル２００を更新する（ステップＳ４）。
次に、各ノード１のレプリケーションデータ管理部１４は、更新された振り分けＩＤテーブル２００において示される自身の担当領域を抽出し、当該担当領域のデータについて、複製データとして保持しているか否かを判定する（ステップＳ５）。
ここで、レプリケーションデータ管理部１４は、自身の担当領域のデータについて、複製データとして保持しているデータがなければ（ステップＳ５→Ｎｏ）、つまり、全て原本データとして保持している場合には、処理を終了する。一方、レプリケーションデータ管理部１４は、自身の担当領域のデータについて、一つでも複製データとして保持しているデータがあれば（ステップＳ５→Ｙｅｓ）、次のステップＳ６に進む。
ここで、レプリケーションデータ管理部１４は、自身の担当領域のデータについて、複製データとして保持しているデータがなければ（ステップＳ５→Ｎｏ）、つまり、全て原本データとして保持している場合には、処理を終了する。一方、レプリケーションデータ管理部１４は、自身の担当領域のデータについて、一つでも複製データとして保持しているデータがあれば（ステップＳ５→Ｙｅｓ）、次のステップＳ６に進む。
ステップＳ６において、レプリケーションデータ管理部１４は、ステップＳ５において保持していると判定した複製データを、原本データに昇格させる処理を実行する。具体的には、レプリケーションデータ管理部１４は、図６に示すデータ属性情報３１０に示させるレプリカフラグ３１３を「１」から「０」に変更する。
続いて、レプリケーションデータ管理部１４は、複製データの配置先ノード決定処理を実行する（ステップＳ７）。このレプリケーションデータ管理部１４による、複製データの配置先ノード決定処理により、ＩＤ空間上において、時計回り側に次のノードと、反時計回り側に次のノードとを含めた配置先ノードが決定される。なお、この複製データの配置先ノード決定処理の詳細は、後記する。
続いて、レプリケーションデータ管理部１４は、ステップＳ７において、決定した複製データの配置先となるノード１に対して、レプリケーションを実行する（ステップＳ８）。そして、グラビテーションを抑止する処理を終了する。
≪配置先ノード決定処理≫
次に、図７のステップＳ７において実行される、複製データの配置先ノード決定処理について、図８および図９を参照して説明する。
図８は、本実施形態に係るノード１のレプリケーションデータ管理部１４が実行する複製データの配置先ノード決定処理の流れを示すフローチャートである。図９は、複製データの配置先ノード決定処理の具体例を説明するための図である。なお、この処理は、各ノード１のＩＤ空間上に、原本データが新たに配置された場合にも、同様の処理を実行する。また、図９においては、冗長度が「４」であるとして説明する。
次に、図７のステップＳ７において実行される、複製データの配置先ノード決定処理について、図８および図９を参照して説明する。
図８は、本実施形態に係るノード１のレプリケーションデータ管理部１４が実行する複製データの配置先ノード決定処理の流れを示すフローチャートである。図９は、複製データの配置先ノード決定処理の具体例を説明するための図である。なお、この処理は、各ノード１のＩＤ空間上に、原本データが新たに配置された場合にも、同様の処理を実行する。また、図９においては、冗長度が「４」であるとして説明する。
図８に示すように、まず、ノード１のレプリケーションデータ管理部１４は、原本データが新たに追加されたか否かを判定する（ステップＳ１０）。ここで、レプリケーションデータ管理部１４は、データ３００内のデータ属性情報３１０（図６）を監視し、原本昇格があった場合、つまり、レプリカフラグ３１３が「１」から「０」に変更されたことや、新たな、原本データがレコードとして追加されたことを検出することにより、原本データが新たに追加されたか否かを判定する。
次に、レプリケーションデータ管理部１４は、データ属性情報３１０（図６）を参照し、追加されるデータ（原本データ）のデータ識別子（ハッシュ値）３１２を抽出する。そして、レプリケーションデータ管理部１４は、そのデータがＩＤ空間上において属するノード１を振り分けＩＤテーブル２００（図５）を参照して決定し、その「ノード番号」を算出し、「１」を減算する（ステップＳ１１）。
ここで、ノード番号とは、各ノード１に割り振られる一意の番号であり、例えば、振り分けＩＤテーブル２００（図５）の各ノード１のノード識別子２０１の昇順に、「０」〜「総ノード数−１」の値が設定される。図９に示す例では、各ノード１に、ノード番号が「０」〜「４」の値で設定されている。なお、総ノード数は５である。
図８においては、ステップＳ１１に示すように、追加されるデータ（原本データ）のデータ識別子を［ｉ］とし、データ［ｉ］が属するノード番号「Ｎ」から「１」を減算した値を「ｓｔａｒｔ」として設定する。
例えば、図９では、原本データが属するノード１のノード番号が「０」であり、ｓｔａｒｔ＝０−１＝−１となる例を示している。
ここで、ノード番号とは、各ノード１に割り振られる一意の番号であり、例えば、振り分けＩＤテーブル２００（図５）の各ノード１のノード識別子２０１の昇順に、「０」〜「総ノード数−１」の値が設定される。図９に示す例では、各ノード１に、ノード番号が「０」〜「４」の値で設定されている。なお、総ノード数は５である。
図８においては、ステップＳ１１に示すように、追加されるデータ（原本データ）のデータ識別子を［ｉ］とし、データ［ｉ］が属するノード番号「Ｎ」から「１」を減算した値を「ｓｔａｒｔ」として設定する。
例えば、図９では、原本データが属するノード１のノード番号が「０」であり、ｓｔａｒｔ＝０−１＝−１となる例を示している。
続いて、ステップＳ１２において、冗長度を示す変数として「ｊ」を導入し、初期値としてｊ＝０とする。そして、ｊ＜冗長度（ここでは「４」）の条件を満たすようにして、ステップＳ１６までの処理を繰り返す。つまり、以下に示すように、ｊ＝０，１，２，３として以下の処理を実行する。
〔ｊ＝０〕の場合
ステップＳ１３において、レプリケーションデータ管理部１４は、次の式（１）を計算する。
ｄｓｔ＝ｓｔａｒｔ ＋ ｊ ・・・式（１）
ここでは、ｓｔａｒｔ＝−１であり、ｊ＝０であるので、式（１）は、
ｄｓｔ＝−１＋０＝−１
となる。
ステップＳ１３において、レプリケーションデータ管理部１４は、次の式（１）を計算する。
ｄｓｔ＝ｓｔａｒｔ ＋ ｊ ・・・式（１）
ここでは、ｓｔａｒｔ＝−１であり、ｊ＝０であるので、式（１）は、
ｄｓｔ＝−１＋０＝−１
となる。
次に、ステップＳ１４において、レプリケーションデータ管理部１４は、「ｊ」が「１」であるか否かを判定する。そして、レプリケーションデータ管理部１４は、「ｊ」が「１」であれば、ステップＳ１２に戻る。一方、「ｊ」が「１」でなければ、次のステップＳ１５へ進む。
ここでは、レプリケーションデータ管理部１４は、ｊ＝０であるので、「ｊ」が「１」でなく（ステップＳ１４→Ｎｏ）、ステップＳ１５に進む。
ここでは、レプリケーションデータ管理部１４は、ｊ＝０であるので、「ｊ」が「１」でなく（ステップＳ１４→Ｎｏ）、ステップＳ１５に進む。
続いて、ステップＳ１５において、レプリケーションデータ管理部１４は、次の式（２）を計算する。
ｄｓｔ ｍｏｄ 総ノード数 ・・・式（２）
そして、式（２）の計算結果で示されるノード番号のノード１を、複製データの配置先として決定する。
ここでは、図９に示すようにｊ＝０の場合に、「−１ ｍｏｄ ５ ＝ ４」となり、ノード番号「４」のノード１を、複製データの配置先として決定する。そして、ステップＳ１６において、ｊ＝０の処理を終了し、ステップＳ１２に戻る。
ｄｓｔ ｍｏｄ 総ノード数 ・・・式（２）
そして、式（２）の計算結果で示されるノード番号のノード１を、複製データの配置先として決定する。
ここでは、図９に示すようにｊ＝０の場合に、「−１ ｍｏｄ ５ ＝ ４」となり、ノード番号「４」のノード１を、複製データの配置先として決定する。そして、ステップＳ１６において、ｊ＝０の処理を終了し、ステップＳ１２に戻る。
〔ｊ＝１〕の場合
ステップＳ１２において、レプリケーションデータ管理部１４は、「ｊ」に１を加え、ｊ＝１とする。
ステップＳ１２において、レプリケーションデータ管理部１４は、「ｊ」に１を加え、ｊ＝１とする。
そして、ステップＳ１３において、レプリケーションデータ管理部１４は、式（１）を計算する。
ここでは、ｓｔａｒｔ＝−１であり、ｊ＝１であるので、式（１）は、
ｄｓｔ＝−１＋１＝０
となる。
ここでは、ｓｔａｒｔ＝−１であり、ｊ＝１であるので、式（１）は、
ｄｓｔ＝−１＋１＝０
となる。
次に、ステップＳ１４において、レプリケーションデータ管理部１４は、「ｊ」が「１」であるか否かを判定する。
ここでは、レプリケーションデータ管理部１４は、ｊ＝１であるので（ステップＳ１４→Ｙｅｓ）、ステップＳ１６に進み、ｊ＝１の処理を終了し、ステップＳ１２に戻る。
つまり、このｊ＝１であることの条件により、原本データが格納されるノード１（図９においては、ノード番号「０」のノード１）には、複製データを配置しないこととなる。
ここでは、レプリケーションデータ管理部１４は、ｊ＝１であるので（ステップＳ１４→Ｙｅｓ）、ステップＳ１６に進み、ｊ＝１の処理を終了し、ステップＳ１２に戻る。
つまり、このｊ＝１であることの条件により、原本データが格納されるノード１（図９においては、ノード番号「０」のノード１）には、複製データを配置しないこととなる。
〔ｊ＝２〕の場合
ステップＳ１２において、レプリケーションデータ管理部１４は、「ｊ」に１を加え、ｊ＝２とする。
ステップＳ１２において、レプリケーションデータ管理部１４は、「ｊ」に１を加え、ｊ＝２とする。
そして、ステップＳ１３において、レプリケーションデータ管理部１４は、式（１）を計算する。
ここでは、ｓｔａｒｔ＝−１であり、ｊ＝２であるので、式（１）は、
ｄｓｔ＝−１＋２＝１
となる。
ここでは、ｓｔａｒｔ＝−１であり、ｊ＝２であるので、式（１）は、
ｄｓｔ＝−１＋２＝１
となる。
次に、ステップＳ１４において、レプリケーションデータ管理部１４は、「ｊ」が「１」であるか否かを判定する。
ここでは、レプリケーションデータ管理部１４は、ｊ＝２であるので（ステップＳ１４→Ｎｏ）、次のステップＳ１５に進む。
ここでは、レプリケーションデータ管理部１４は、ｊ＝２であるので（ステップＳ１４→Ｎｏ）、次のステップＳ１５に進む。
続いて、ステップＳ１５において、レプリケーションデータ管理部１４は、式（２）を計算する。
ここでは、図９に示すようにｊ＝２の場合に、「１ ｍｏｄ ５ ＝ １」となり、ノード番号「１」のノード１を、複製データの配置先として決定する。そして、ステップＳ１６において、ｊ＝２の処理を終了し、ステップＳ１２に戻る。
ここでは、図９に示すようにｊ＝２の場合に、「１ ｍｏｄ ５ ＝ １」となり、ノード番号「１」のノード１を、複製データの配置先として決定する。そして、ステップＳ１６において、ｊ＝２の処理を終了し、ステップＳ１２に戻る。
〔ｊ＝３〕の場合
ステップＳ１２において、レプリケーションデータ管理部１４は、「ｊ」に１を加え、ｊ＝３とする。
ステップＳ１２において、レプリケーションデータ管理部１４は、「ｊ」に１を加え、ｊ＝３とする。
そして、ステップＳ１３において、レプリケーションデータ管理部１４は、式（１）を計算する。
ここでは、ｓｔａｒｔ＝−１であり、ｊ＝３であるので、式（１）は、
ｄｓｔ＝−１＋３＝２
となる。
ここでは、ｓｔａｒｔ＝−１であり、ｊ＝３であるので、式（１）は、
ｄｓｔ＝−１＋３＝２
となる。
次に、ステップＳ１４において、レプリケーションデータ管理部１４は、「ｊ」が「１」であるか否かを判定する。
ここでは、レプリケーションデータ管理部１４は、ｊ＝３であるので（ステップＳ１４→Ｎｏ）、次のステップＳ１５に進む。
ここでは、レプリケーションデータ管理部１４は、ｊ＝３であるので（ステップＳ１４→Ｎｏ）、次のステップＳ１５に進む。
続いて、ステップＳ１５において、レプリケーションデータ管理部１４は、式（２）を計算する。
ここでは、図９に示すようにｊ＝３の場合に、「２ ｍｏｄ ５ ＝ ２」となり、ノード番号「２」のノード１を、複製データの配置先として決定する。
そして、ｊ＜冗長度（ここでは「４」）の条件の処理が終了したため（ステップＳ１６）、レプリケーションデータ管理部１４は、配置先ノード決定処理を終了する。この処理により、図９においては、原本データを保持するノード番号「０」のノード１が、ノード番号「４」「１」「２」のノード１を、複製データの配置先ノードとして決定する。
ここでは、図９に示すようにｊ＝３の場合に、「２ ｍｏｄ ５ ＝ ２」となり、ノード番号「２」のノード１を、複製データの配置先として決定する。
そして、ｊ＜冗長度（ここでは「４」）の条件の処理が終了したため（ステップＳ１６）、レプリケーションデータ管理部１４は、配置先ノード決定処理を終了する。この処理により、図９においては、原本データを保持するノード番号「０」のノード１が、ノード番号「４」「１」「２」のノード１を、複製データの配置先ノードとして決定する。
このようにすることにより、レプリケーションデータ管理部１４は、冗長度が「３」以上の場合、新たな原本データを保持するノード１において、ＩＤ空間上で時計回り側に次のノードと、反時計回り側に次のノードとを、必ず複製データを送信するノード１として含めた上で配置先ノードを決定することができる。
以上説明したように、本実施形態に係るノード１およびグラビテーション抑止方法によれば、分散処理システム１０００を構成するノード１の減設時において、グラビテーション（原本移管）の発生を抑止し、システムの冗長度の復旧までの時間を短縮することができる。また、冗長度回復の際に、グラビテーション（原本移管）が発生しないため、データ転送のトラフィックの増加や、ＣＰＵ使用率の増加を防ぐことができる。
１ ノード
２ クライアント
３ ロードバランサ
１０ 制御部
１１ ノード識別子管理部
１２ 振り分け部
１３ 信号処理部
１４ レプリケーションデータ管理部
２０ 入出力部
３０ 記憶部
１００ ノード識別子管理テーブル
２００ 振り分けＩＤテーブル（振り分けＩＤ情報）
３００ データ
３１０ データ属性情報
１０００ 分散処理システム
２ クライアント
３ ロードバランサ
１０ 制御部
１１ ノード識別子管理部
１２ 振り分け部
１３ 信号処理部
１４ レプリケーションデータ管理部
２０ 入出力部
３０ 記憶部
１００ ノード識別子管理テーブル
２００ 振り分けＩＤテーブル（振り分けＩＤ情報）
３００ データ
３１０ データ属性情報
１０００ 分散処理システム
Claims (3)
- クラスタを構成する複数のノードそれぞれに、コンシステント・ハッシュ法によりデータを振り分けて処理させる分散処理システムの前記ノードであって、
ＩＤ空間上における各ノードの担当領域を示す振り分けＩＤ情報を記憶する記憶部と、
前記ＩＤ空間上において自身の前記担当領域に位置する原本データを格納するノードから、前記ＩＤ空間上で時計回りに最初に位置するノードおよび反時計回りに最初に位置するノードを、前記原本データの複製データを配置するノードに決定し、前記原本データの複製データを前記決定したノードに記憶させるレプリケーションデータ管理部と、
を備えることを特徴とするノード。 - 前記振り分けＩＤ情報の更新情報を受信した場合に、前記レプリケーションデータ管理部は、受信した更新情報の前記振り分けＩＤ情報で示される自身のノードの前記ＩＤ空間上の担当領域において前記複製データとして記憶しているデータを前記原本データに昇格させること
を特徴とする請求項１に記載のノード。 - クラスタを構成する複数のノードそれぞれに、コンシステント・ハッシュ法によりデータを振り分けて処理させる分散処理システムの前記ノードのグラビテーション抑止方法であって、
前記ノードは、
ＩＤ空間上における各ノードの担当領域を示す振り分けＩＤ情報を記憶部に記憶しており、
前記ＩＤ空間上において自身の前記担当領域に位置する原本データを格納するノードから、前記ＩＤ空間上で時計回りに最初に位置するノードおよび反時計回りに最初に位置するノードを、前記原本データの複製データを配置するノードに決定し、前記原本データの複製データを前記決定したノードに記憶させるステップを
実行することを特徴とするグラビテーション抑止方法。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2015221115A JP6506156B2 (ja) | 2015-11-11 | 2015-11-11 | ノードおよびグラビテーション抑止方法 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2015221115A JP6506156B2 (ja) | 2015-11-11 | 2015-11-11 | ノードおよびグラビテーション抑止方法 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2017091248A true JP2017091248A (ja) | 2017-05-25 |
| JP6506156B2 JP6506156B2 (ja) | 2019-04-24 |
Family
ID=58771563
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2015221115A Active JP6506156B2 (ja) | 2015-11-11 | 2015-11-11 | ノードおよびグラビテーション抑止方法 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP6506156B2 (ja) |
Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2012174020A (ja) * | 2011-02-22 | 2012-09-10 | Kddi Corp | 分散データベースの制御方法 |
| WO2013153646A1 (ja) * | 2012-04-12 | 2013-10-17 | 株式会社日立製作所 | 計算機システム、データ配置管理方法及びプログラム |
-
2015
- 2015-11-11 JP JP2015221115A patent/JP6506156B2/ja active Active
Patent Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2012174020A (ja) * | 2011-02-22 | 2012-09-10 | Kddi Corp | 分散データベースの制御方法 |
| WO2013153646A1 (ja) * | 2012-04-12 | 2013-10-17 | 株式会社日立製作所 | 計算機システム、データ配置管理方法及びプログラム |
Also Published As
| Publication number | Publication date |
|---|---|
| JP6506156B2 (ja) | 2019-04-24 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN109492049B (zh) | 用于区块链网络的数据处理、区块生成及同步方法 | |
| JP5969315B2 (ja) | データ移行処理システムおよびデータ移行処理方法 | |
| CN102833273A (zh) | 临时故障时的数据修复方法及分布式缓存系统 | |
| JP6059558B2 (ja) | 負荷分散判定システム | |
| JP6025679B2 (ja) | 分散データベースシステム | |
| JP2016099969A (ja) | 情報処理装置、データ保存システム、及びデータ保存方法 | |
| JP5945252B2 (ja) | 分散処理システム | |
| US10122789B1 (en) | Log information transmission integrity | |
| JP5918802B2 (ja) | ノードおよびプログラム | |
| US20240176762A1 (en) | Geographically dispersed hybrid cloud cluster | |
| JP2017091248A (ja) | ノードおよびグラビテーション抑止方法 | |
| JP5956364B2 (ja) | クラスタシステム | |
| JP5711771B2 (ja) | ノード離脱処理システム | |
| JP5690296B2 (ja) | 負荷分散プログラムおよび負荷分散装置 | |
| JP6564349B2 (ja) | 保守減設システム、ノードおよび保守減設方法 | |
| JP5658621B2 (ja) | 信号振分複製先決定システム、信号振分複製先決定方法およびプログラム | |
| JP6714547B2 (ja) | 負荷分散装置、負荷分散方法、および、負荷分散プログラム | |
| JP6473425B2 (ja) | ノードおよびデータ配置方法 | |
| JP6093320B2 (ja) | 分散処理システム | |
| JP5711772B2 (ja) | クラスタシステム | |
| JP2014032530A (ja) | 分散処理システムおよび分散処理方法 | |
| JP6197872B2 (ja) | データ処理システム、データ処理方法およびデータ処理プログラム | |
| JP5815000B2 (ja) | ノードおよびプログラム | |
| JP2013182553A (ja) | 管理装置およびプログラム | |
| JP5845298B2 (ja) | ノードおよびプログラム |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20171221 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20180831 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20180911 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20181025 |
|
| 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: 20190326 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20190328 |
|
| R150 | Certificate of patent or registration of utility model |
Ref document number: 6506156 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 |