JP6093320B2 - 分散処理システム - Google Patents

Description

本発明は、複数のサーバを備えた分散処理システムで扱うデータのレプリケーション技
術に関する。

近年、クラウドコンピューティングの隆盛に伴い、多量のデータの処理や保持を効率的に行うことが求められている。そこで、複数のサーバを協調動作させることにより効率的な処理を実現する分散処理技術が発展している。

分散処理を行う際には、処理対象（管理対象）のデータを、クラスタを構成する各サーバ（以下、「クラスタメンバ」または「メンバ」とも称する。）に振り分けておく必要がある。このとき、クラスタ全体での処理能力を高めるためには、各クラスタメンバが担当するデータ数（データ量）は、平均化されていることが望ましい。

代表的なデータの振り分け手法として、各データのｋｅｙをハッシュ関数にかけた値（以下、「hash(key)」と称する。）をクラスタメンバ数Ｎで割った余り、すなわち「hash(key) mod N」を番号として持つクラスタメンバにデータを振り分ける手法がある。この場合、各クラスタメンバに対して、事前に「０」から「Ｎ−１」までの番号を割り当てていることが前提となる。このような振り分け手法を用いた場合、クラスタメンバを追加すると、Ｎの値が変化して、多くのデータについて、担当するクラスタメンバが変更になるため、担当するデータの再配置が必要になる。

そこで、クラスタメンバの追加に伴い担当するクラスタメンバが変更になるデータ数を約１／Ｎに抑える手法として、コンシステント・ハッシュ法（Consistent Hashing）を用いた振り分け手法（非特許文献１参照）がある。

このコンシステント・ハッシュ法を用いたデータ振り分け手法では、クラスタメンバとデータの双方にＩＤ（IDentifier）を割り当て、データのＩＤから環状のＩＤ空間を時計回りに辿った場合に最初に出合ったクラスタメンバを、そのデータの担当とする。

また、多量のデータの管理をクラスタ構成の分散処理システムで行う場合、あるクラスタメンバに障害が発生した場合でも他のクラスタメンバで処理を継続することができるように、データの複製を保持することでデータ冗長化を実現する必要がある。これは、コンシステント・ハッシュ法によるデータ管理手法を用いた分散処理システムにおいても同様である。

図４に示すように、コンシステント・ハッシュ法では、クラスタメンバ（メンバ１〜４）及びデータ（データＡ〜Ｄ。黒丸で表示）の双方にＩＤを割り当て、データのＩＤからＩＤ空間を時計回りに辿り、最初に出会ったクラスタメンバを、そのデータの担当として決定する。
そして、担当するクラスタメンバのさらに右隣（時計回りに辿って次）のクラスタメンバに複製データを担当させる。

例えば、図４においては、データ（原本データ）Ａについては、ＩＤ空間上を時計回りに辿って最初に出会ったメンバ１が担当となり、データＡの複製データについては、ＩＤ空間上でメンバ１の右隣にあたるメンバ２が担当となる。このように、原本データ及び複製データを担当するクラスタメンバを決定することで、クラスタメンバに離脱があった場合でも、離脱したクラスタメンバが担当していたデータＡの複製データを所持しているクラスタメンバが、当該データＡを担当する新たなクラスタメンバとなることで対応することができるという利点がある。なお、複製データを複数個作成する場合には、さらに右隣のクラスタメンバに２個目の複製データを担当させるようにすることもできる。

ここで、このような手法に使用できるデータベースサーバとしては、例えば、Ｃａｓｓａｎｄｒａ（非特許文献２）等に記載されている、複数サーバが動的にクラスタに参加・離脱することが可能な分散データベースサーバが挙げられる。非特許文献２に記載の技術では、コンシステント・ハッシュ法を用いたデータの均等な分散及び高速アクセスが実現されている。また、複製データを複数のサーバに対して持たせることで、耐故障性を高めることができる。複製データを複数のサーバに対して持たせると、対故障性を高めることができる一方で、複製にかかる処理負荷、複数サーバ間における複製情報の整合性、複製情報を保持するためのデータ蓄積量の増大等を招くことから、通常は、同じ複製データを保持するサーバを複数設けることはしない。

また、例えばセッション制御サーバのようにリクエストの応答時間が厳しい処理を実現する場合、リクエストの応答内容と複製データとを同期させてからリクエストの応答を返信するのでは処理時間が厳しいので、リクエストの応答は先に返信し、管理対象の複製データの作成は、リクエストの応答とは非同期に行うことで、応答時間を確保することになる。

David Karger et al., " Consistent Hash ing and Random Tre es: Distributed Caching Protocols for Relieving Hot Spots on the World Wide Web", [online], 1997, ACM, [2014年2月28日検索], インターネット<ＵＲＬ：http://dl.acm.org/citation.cfm?id=258660> Avinash Lakshman et al., "Cassandra - A Decentralized Structured Storage System" , [online], [2014年2月28日検索], インターネット<ＵＲＬ：http://www.cs.cornell.edu/projects/ladis2009/papers/lakshman-ladis2009.pdf>

しかしながら、クラスタ内における処理遅延等によって、複製データの作成に失敗しても、サーバがクライアントマシンにリクエストに対して正常に返信しているために、リクエストの再送を期待することができず、原本データと複製データとがアンマッチのままクラスタが運用されることになり、原本データを管理するサーバがダウンした場合に、データを消失してしまうおそれがある。

そこで、本発明は、前記事情に鑑みてなされたものであり、管理対象となるデータのリクエスト処理とは非同期のデータ複製処理が失敗した場合でも、データ複製処理の再実行が可能な分散処理システムを提供することを課題とする。

前記の目的を達成するために、本発明は、複数のサーバがデータを管理する分散処理システムであって、一の前記データに関して、前記複数のサーバのうちの一台のサーバが前記データの原本データを管理する原本管理サーバとなり、他のサーバのいずれかが前記データの複製データを管理する複製管理サーバとなり、一の前記データに関して前記原本管理サーバとなる前記サーバは、一の前記データに関する前記原本データが記憶されるとともに、一の前記データに関する前記原本データ及び前記複製データが前記複数のサーバのいずれによって管理されているかを示す複製管理情報が記憶される記憶部と、クライアントマシンからのリクエストを処理することによって前記記憶部に記憶された前記原本データを更新し、かかるリクエストの処理とは非同期に、更新された前記原本データを前記複製管理サーバに送信して前記複製データを作成させる処理部を備え、前記複製管理情報は、一の前記データに関して、前記サーバごとに当該サーバに記憶された一の前記データが前記原本データとしての管理であるか前記複製データとしての管理であるか複製失敗の状態であるかを示す複製状態を含み、一の前記データに関して前記原本管理サーバとなる前記サーバの前記処理部は、前記複製管理サーバによる前記複製データの作成状態を監視し、前記複製データの作成に失敗した場合に、前記複製状態を複製失敗として前記複製管理情報を更新するとともに前記複製データの作成に失敗した前記複製管理サーバを当該分散処理システムから離脱させ、前記複数のサーバのうちの他のサーバを新たな前記複製管理サーバとし、新たな前記複製管理サーバに前記複製データを作成させ、前記複製データの作成に成功した新たな前記複製管理サーバに関する前記複製管理情報を作成して前記記憶部に記憶させ、一の前記データに関して前記複製管理サーバとなる前記サーバは、一の前記データに関する前記複製データが記憶されるとともに、前記複製管理情報が記憶される記憶部と、前記複製データを前記記憶部に記憶させる処理部を備え、一の前記データに関して前記複製管理サーバとなる前記サーバの前記処理部は、前記複製データの作成中に前記原本管理サーバがダウンした場合には、作成しようとした前記複製データの中で作成済みの前記複製データを当該複製管理サーバの前記記憶部に記憶させるとともに、一の前記データに関して当該複製管理サーバが原本管理サーバとなり作成済みの前記複製データが前記原本データとなるように前記複製管理情報を更新することを特徴とする。

かかる構成によると、リクエスト処理とは非同期に複製データを作成するとともに、複製データの作成に失敗した場合に、複製データの作成に失敗した複製管理サーバを当該分散処理システムから離脱させ、複数のサーバのうちの他のサーバを新たな複製管理サーバとし、新たな複製管理サーバに複製データを作成させるので、原本データと複製データとがアンマッチのまま分散処理システムが運用されることを防ぐことができる。
また、かかる構成によると、複製データの作成が全て完了する前に原本管理サーバがダウンした場合には、作成済みの複製データを原本データとして当該複製管理サーバの記憶部に記憶させるので、複製データの作成中に原本管理サーバがダウンした場合においても、データの完全消失を防ぐことができる。

前記複製管理サーバは、環状のＩＤ（IDentifier）空間に、処理対象の複数の前記データのＩＤ、及び、クラスタを構成し前記データに関するリクエストを処理する前記複数のサーバのＩＤが割り当てられ、前記ＩＤ空間において前記データのＩＤから所定方向回りに辿って最初に遭遇した前記サーバまでの間に位置する前記データを、当該サーバが前記原本管理サーバとなって前記原本データとして保持するとともに、前記クラスタ内の前記原本管理サーバ以外のサーバのいずれかが前記複製管理サーバとなって前記複製データを保持する構成であってもよい。

かかる構成によると、環状のＩＤ空間にデータ及びサーバが配置される、いわゆるコンシステント・ハッシュ法を採用した分散処理システムにおいて、原本データと複製データとがアンマッチのまま分散処理システムが運用されることを防ぐことができる。

本発明によれば、本発明によれば、分散処理システムにおいてリクエスト処理とは非同期に複製データを作成する場合においても、データの損失を効率的に防ぐことができる。

本発明の実施形態に係るクライアントマシン及び分散処理システムを模式的に示すブロック図である。 ＩＤ空間管理情報の一例を示す図である。 複製管理情報の一例を示す図である。 コンシステント・ハッシュ法のＩＤ空間において原本データ及び複製データを管理するサーバを説明するための図である。 本発明の実施形態に係る原本管理サーバの動作例を説明するためのフローチャートである。 本発明の実施形態に係る複製管理サーバの動作例を説明するためのフローチャートである。

以下、本発明の実施形態について、適宜図面を参照して説明する。同様の構成には同一の符号を付し、重複する説明を省略する。

＜分散処理システム＞
図１に示すように、本発明の実施形態に係る分散処理システム１０００は、負荷分散装置３と、クラスタ１００を構成する複数のサーバ４と、を備えている。負荷分散装置３は、インターネット等のネットワーク２を介して、複数のクライアントマシン１と接続されている。

ここで、分散処理システム１０００全体の主な動作について説明する。まず、負荷分散装置３は、クライアントマシン１からのリクエストを、ネットワーク２経由で受信する。負荷分散装置３は、受信したリクエストを、複数のサーバ４のいずれかに振り分ける。リクエストを振り分けられたサーバ４は、振り分けられたリクエストの処理を行うとともに、他の（本実施形態では、１つ）のサーバ４にデータの複製の記憶を要求する。

＜負荷分散装置＞
続いて、負荷分散装置３の構成について説明する。負荷分散装置３は、記憶部３１と、処理部３２と、入力部３３と、表示部３４と、通信部３５と、を備える。

記憶部３１は、情報を記憶する手段であり、ＲＡＭ（Random Access Memory）やＲＯＭ（Read Only Memory）等のメモリ、ＨＤＤ（Hard Disk Drive）等によって構成される。記憶部３１には、ＩＤ空間管理情報３１１と複製管理情報３１２と、が格納されている。また、記憶部３１には、処理部３２を具現化する動作プログラムなども格納されている。なお、ＩＤ空間管理情報３１１は、後記するサーバ４のＩＤ空間管理情報４１１と同一であり、複製管理情報３１２は、後記するサーバ４の複製管理情報４１２と同一である。そのため、ＩＤ空間管理情報３１１及び複製管理情報３１２に関する説明を省略する。

処理部３２は、記憶部３１に格納された情報に基づいて演算処理を行う手段であり、例えばＣＰＵ（Central Processing Unit）によって構成される。処理部３２は、クラスタ１００へのサーバ４の離脱等によりＩＤ空間管理情報３１１を更新し、更新された最新のＩＤ空間管理情報３１１をすべてのサーバ４に送信する。

また、処理部３２は、ＩＤ空間管理情報３１１に基づいて、通信部３５が受信したクライアントマシン１からのリクエストを複数のサーバ４のどれに振り分けるかについて決定する。

入力部３３は、サーバ４の管理者が情報を入力する手段であり、例えば、キーボード、マウス等によって実現される。

表示部３４は、情報を表示する手段であり、例えば、ＬＣＤ（Liquid Crystal Display）によって実現される。

通信部３５は、外部装置との通信に用いられる通信インタフェースである。

＜サーバ＞
続いて、サーバ４の構成について説明する。サーバ４は、負荷分散装置３によって振り分けられたクライアントマシン１からのリクエストを処理するコンピュータ装置である。なお、前記したように、コンシステント・ハッシュ法では、管理対象の複数のデータ、及び、データを管理しクラスタ１００を構成する複数のサーバ４、が環状のＩＤ空間に割り振られ、それぞれのサーバ４が、ＩＤ空間において自身から反時計回り（所定方向回り）に次のサーバ４までの間に位置するデータ（原本データ）を記憶して管理する原本管理サーバとして機能するとともに、当該次のサーバ４から反時計回り（所定方向回り）にさらに次のサーバ４までの間に位置するデータの複製（複製データ）を記憶して管理する複製管理サーバとして機能することを前提とする。

サーバ４は、記憶部４１と、処理部４２と、通信部４３と、を備える。

記憶部４１は、情報を記憶する手段であり、ＲＡＭやＲＯＭ等のメモリ、ＨＤＤ等によって構成される。記憶部４１には、当該サーバ４に対応する原本データ及び複製データが格納されているとともに、負荷分散装置３から受信したＩＤ空間管理情報３１１及び複製管理情報３１２が、それぞれＩＤ空間管理情報４１１及び複製管理情報４１２として格納されている。なお、記憶部４１には、処理部４２を具現化する動作プログラム等も格納されている。

処理部４２は、記憶部４１に格納された情報に基づいて演算処理を行う手段であり、例えばＣＰＵによって構成される。処理部４２は、負荷分散装置３によって振り分けられたクライアントマシン１からのリクエストを処理する。すなわち、処理部４２は、リクエストに対応するデータ（原本データ）を記憶部４１内において更新する。

処理部４２は、さらに、ＩＤ空間管理情報４１１を参照してＩＤ空間における自身から所定方向回りに次のサーバ４に当該リクエストの処理に用いたデータの複製の記憶を要求する。ここで、処理部４２は、記憶部４１に記憶された原本データのうち、リクエストによって更新された原本データのみの複製の記憶を要求する構成であってもよく、全ての原本データの複製の記憶を要求する構成であってもよい。また、複製管理サーバの処理部４２は、複製データを作成して（すなわち、原本管理サーバの処理部４２から送信されたデータを受信して複製データとし）、作成した複製データを複製管理サーバの記憶部４１に記憶させる。

なお、処理部４２は、レスポンスタイムを短くするために、次のサーバ４におけるデータの複製の記憶が完了する前に、クライアントマシン１からのリクエストに対して返信し、データの複製を、リクエストの処理とは非同期に行うものとする。また、処理部４２は、かかるリクエストの処理及びデータの複製に応じて複製管理情報４１２を更新したり、複製管理情報４１２の更新結果を他のサーバ４及び負荷分散装置３に送信したりすることができる。

通信部４３は、外部装置との通信に用いられる通信インタフェースである。なお、サーバ４は、入力部や表示部を備えていてもよい。

ＩＤ空間管理情報４１１は、管理対象のデータについて、所定のハッシュ値変換によって算出されたＩＤを用いて、そのデータを担当するサーバ４を管理するための情報である。ＩＤは、環状のＩＤ空間における位置を示す固有の値であり、サーバ４が管理を担当するデータの領域を特定するために格納され、ＩＤの値の大きさでソートされている。

図２に示す例では、第１行目は、ＩＰアドレスが「192.168.0.3」のサーバ４に対して、ＩＤ「9245D30E」が割り当てられており、かかるサーバ４が、ＩＤが「00000000」〜「9245D30E」の領域に属するデータを担当する（すなわち、当該領域の原本データを記憶して管理する）ことを示している。
また、第２行目は、ＩＰアドレスが「192.168.2.15」のサーバ４が、１つ前の行のＩＤの値に１をプラスした識別子からその行のＩＤまでの値の識別子に属するデータを担当することを示している。

複製管理情報４１２は、各管理対象のデータ毎に作成され、データの複製の状況を管理するための情報である。図３に示すように、複製管理情報４１２は、原本データが記憶されるサーバ４のＩＰアドレスと、複製データが記憶されるＩＰアドレスと、のそれぞれについて、複製状態及び複製版数が関連付けられている。例えば、複製状態が「０」であれば、該当するサーバ４が当該データの原本データを管理していることを示し、複製状態が「１」であれば、該当するサーバ４が当該データの複製データを管理していることを示す。また、データの複製は、クライアントマシン１からのリクエストとは非同期に行われるので、追加差分を随時複製するため、原本データを管理するサーバ４の処理部４２は、原本データ作成時に、原本データに関する複製版数を更新しておき、複製データ作成の成功時に複製データに関する複製版数を更新することで、複製状況を更新可能とする。また、原本データを管理するサーバ４の処理部４２は、複製に失敗した場合に、複製状態を「２」と更新することで、複製の失敗の有無を管理することができる。また、サーバ４の処理部４２は、クラスタ１００からの離脱等によるＩＤ空間管理情報４１１の更新があって、原本データを保持しているサーバ４のＩＰアドレスが削除された場合には、ＩＤ空間管理情報４１１及び複製管理情報４１２から当該ＩＰアドレスを削除し、複製管理情報４１２に、次に複製管理サーバとなる候補であるサーバ４のＩＰアドレスを追加する。また、サーバ４の処理部４２は、複製管理情報４１２において、クラスタ１００から離脱したサーバ４が保持していた原本データの複製データを保持するサーバ（複製管理サーバ）４のＩＰアドレスの複製状態を「２」から「０」に更新し、かかるサーバ４を複製管理サーバから原本管理サーバに昇格させる。

＜原本管理サーバの動作例＞
続いて、図４に示すＩＤ空間を例にとり、あるデータＡを原本データとして管理する原本管理サーバ（メンバ１）であるサーバ４による処理について説明する。

図５に示すように、ステップＳ１において、原本管理サーバ（メンバ１）の処理部４２は、クライアントマシン１からのリクエストを、負荷分散装置３から受信したか否かを判定する。ステップＳ１でＹｅｓの場合は、本フローはステップＳ２に進み、ステップＳ１でＮｏの場合は、本フローはステップＳ１に戻る。

ステップＳ２において、原本管理サーバ（メンバ１）の処理部４２は、受信したリクエストに対するデータ処理を行う。詳細には、処理部４２は、受信したリクエストに基づいて、記憶部４１に記憶された原本データを更新し、リクエストを送信したクライアントマシン１に対して、リクエストに対する返信を行う。

ステップＳ３において、原本管理サーバ（メンバ１）の処理部４２は、クライアントマシン１からのリクエストとは非同期に、記憶部４１のＩＤ空間管理情報４１１を参照して、ＩＤ空間における時計回りに隣のサーバ４にデータの複製の記憶を要求する。詳細には、処理部４２は、記憶部４１に記憶された原本データを、複製データ管理サーバ（メンバ２）である隣のサーバ（メンバ２）４へ送信する。複製管理サーバ（メンバ２）であるサーバ４の処理部４２は、原本データを受信すると、受信した原本データを複製データとして記憶部４１に記憶させる。

ステップＳ４において、原本管理サーバ（メンバ１）の処理部４２は、クライアントマシン１からのリクエストとは非同期に、複製管理サーバ（メンバ２）からのデータの複製の完了通知（レスポンス）を監視する。

複製管理サーバ（メンバ２）においてデータの複製が正常に完了しない場合（ステップＳ４でＮｏ）は、原本管理サーバ（メンバ１）の処理部４２は、記憶部４１に記憶されたＩＤ空間管理情報４１１を参照して、ＩＤ空間における時計回りにさらに次のサーバ（メンバ３）４を新たな複製管理サーバとし、当該複製管理サーバに対して複製データの作成を要求する。

すなわち、図２において、ＩＰアドレスが「192.168.2.15」のサーバ４が、データＡにとっての複製管理サーバとして正常に応答しない場合は、次のＩＰアドレスが「192.168.8.5」のサーバ４が、データＡにとっての新たな複製管理サーバに該当することとなる。

なお、ステップＳ４において、複製データの作成が正常に完了しない場合の判断として、複製管理サーバの処理部４２が複製失敗通知を送信し、原本管理サーバの処理部４２が複製失敗通知を受信した場合、原本管理サーバの処理部４２が一定時間内に正常な完了通知を受信することができなかった場合等も同様に扱うことができる。

また、ステップＳ４において、原本管理サーバの処理部４２が複製失敗通知を受信した場合には、当該処理部４２が、差分の更新に失敗したリトライとして原本データ全体を再送する場合がある。この場合には、処理部４２は、原本データ全体を複製管理サーバへ再送するのと同時に、ステップＳ５を実行して次の複製管理サーバ候補に対する複製データの作成を要求することによって、早期に冗長性を保つことができる。

ステップＳ６において、原本管理サーバの処理部４２が複製データ作成の完了通知を受信すると（ステップＳ６でＹｅｓ）、ステップＳ７において、原本管理サーバの処理部４２は、元の複製管理サーバをクラスタ１００から離脱させる。詳細には、原本管理サーバの処理部４２は、ＩＤ空間管理情報４１１を参照して、元の複製管理サーバのクラスタ１００からの離脱を管理サーバに要求する。管理サーバは、自身のＩＤ空間管理情報４１１から、元の複製管理サーバに関する情報を削除し、このように更新されたＩＤ空間管理情報４１１を、他のサーバ４及び負荷分散装置３に送信する。ＩＤ空間管理情報４１１を受信したサーバ４の処理部４２及び負荷分散装置３の処理部３２は、受信したＩＤ空間管理情報を用いて自身の記憶部４１，３１内のＩＤ空間管理情報４１１，３１１を更新し、これによって、元のＩＤ複製管理サーバのクラスタ１００からの離脱が完了する。ここで、管理サーバは、クラスタ１００を構成するサーバ４の中から、ＩＤ空間管理情報４１１を更新可能なサーバ４として予め指定されたものである。なお、各原本管理サーバが当該管理サーバとして機能する構成であってもよい。

また、ステップＳ６において、新たな複製管理サーバ（メンバ３）においてデータの複製が正常に完了しない場合（ステップＳ６でＮｏ）は、原本管理サーバ（メンバ１）の処理部４２は、記憶部４１に記憶されたＩＤ空間管理情報４１１を参照して、ＩＤ空間における時計回りにさらに次のサーバ（メンバ４）４を新たな複製管理サーバとし、当該複製管理サーバに対して複製データの作成を要求する（ステップＳ５）。

ステップＳ６において、図２の例では、管理サーバは、ＩＰアドレス「192.168.2.15」の行をＩＤ空間管理情報４１１から削除する。なお、管理サーバは、複製データの作成の完了通知を待たずに、元の複製管理サーバのクラスタ１００からの離脱を開始してもよい。この場合には、離脱した元の複製管理サーバに記憶された複製データの原本データ化は行われないことになる。

また、ステップＳ４でＹｅｓの場合、及び、ステップＳ６でＹｅｓの場合には、原本管理サーバの処理部４２は、対応する複製管理情報４１２を更新し、更新結果を複製管理情報４１２の更新結果を他のサーバ４及び負荷分散装置３に送信する。

＜複製管理サーバの動作例＞
続いて、図４に示すＩＤ空間を例にとり、あるデータＡの複製データを管理する複製管理サーバ（メンバ２）であるサーバ４による処理について説明する。

図６に示すように、ステップＳ１１において、複製管理サーバ（メンバ２）の処理部４１は、原本管理サーバ（メンバ１）から複製データの作成を要求されると、複製データを作成する、すなわち、複製管理サーバ（メンバ２）の処理部４２は、原本管理サーバ（メンバ１）が原本データを送信すると、送信された原本データを受信し、受信した原本データを複製データとして記憶部４１に記憶させる。

複製データの作成が成功した場合（ステップＳ１２でＹｅｓ）には、ステップＳ１３において、複製管理サーバ（メンバ２）の処理部４２は、複製データの作成の完了通知を原本管理サーバ（メンバ１）へ送信する。

また、複製データの作成が失敗した場合（ステップＳ１２でＮｏ）であって、かつ、失敗の理由が複製データの作成中に原本管理サーバ（メンバ１）がダウンしたことではない場合（ステップＳ１４でＮｏ）には、ステップＳ１５において、複製管理サーバ（メンバ２）の処理部４１は、複製データの作成の失敗通知を原本管理サーバ（メンバ１）へ送信する。

また、複製データの作成が失敗した場合（ステップＳ１２でＮｏ）であって、かつ、失敗の理由が複製データの作成中に原本管理サーバ（メンバ１）がダウンしたことである場合（ステップＳ１４でＹｅｓ）には、ステップＳ１６において、複製管理サーバ（メンバ２）の処理部４１は、作成しようとした複製データのうち、作成済みの複製データを原本データとして記憶部４１に記憶させる（すなわち、原本管理サーバがダウンする前に送信されて受信に成功したデータを記憶部４１に記憶させ、当該データの複製管理情報４１２の複製状態を「０」に設定する）ことにより、データＡの完全消失を防ぐ。この場合には、前記したステップＳ７における複製管理サーバの離脱は、実施されない。ここで、複製管理サーバが原本管理サーバのダウンを検知する手法としては、複製管理サーバ及び原本管理サーバが相互間でハートビート信号を送受信してお互いに監視してダウンを検知する手法等、任意の公知の手法が採用可能である。また、複製管理サーバから原本管理サーバに昇格したサーバ４は、前記した元の複製管理サーバのクラスタ１００からの離脱と同様の手法によって、元の原本管理サーバをクラスタ１００から離脱させることができる。

また、ステップＳ１３の実行後、及び、ステップＳ１６の実行後において、複製管理サーバの処理部４２は、対応する複製管理情報４１２を更新し、更新結果を複製管理情報４１２の更新結果を他のサーバ４及び負荷分散装置３に送信する。

本発明の実施形態に係る分散処理システム１０００は、リクエスト処理とは非同期に複製データを作成するとともに、複製データの作成に失敗した場合に、複製データの作成に失敗した複製管理サーバを当該分散処理システム１０００から離脱させ、クラスタ１００を構成する複数のサーバ４のうちの他のサーバ４を新たな複製管理サーバとし、新たな複製管理サーバに複製データを作成させるので、原本データと複製データとがアンマッチのままクラスタ１００が運用されることを防ぐことができる。したがって、分散処理システム１０００は、リクエスト処理とは非同期に複製データを作成する場合においても、データの損失を効率的に防ぐことができる。
また、分散処理システム１０００は、複製データの作成が全て完了する前に原本管理サーバがダウンした場合には、作成済みの複製データを原本データとして当該複製管理サーバの記憶部４１に記憶させるので、複製データの作成中に原本管理サーバがダウンした場合においても、データの完全消失を防ぐことができる。

以上、本発明の実施形態について説明したが、本発明は前記実施形態に限定されず、本発明の要旨を逸脱しない範囲で適宜変更可能である。例えば、本発明の分散処理システムは、コンシステント・ハッシュ法を用いるシステムに限定されず、原本管理サーバが保持する原本データを他のサーバ（複製管理サーバ）に複製データとして保持させるシステム全般に適用可能である。また、前記実施形態では、冗長度が２（すなわち、１つのデータに対して原本管理サーバが１つで複製管理サーバが１つ）のケースを例にとって説明したが、本発明は、冗長度が３以上（すなわち、１つのデータに対して原本管理サーバが１つで複製管理サーバが２つ以上）の分散処理システムにも適用可能である。

１００ クラスタ
１０００ 分散処理システム
４ サーバ（原本管理サーバ、複製管理サーバ）
４１ 記憶部
４１１ ＩＤ空間管理情報
４１２ 複製管理情報
４２ 処理部

Claims (2)

1. 複数のサーバがデータを管理する分散処理システムであって、
   一の前記データに関して、
   前記複数のサーバのうちの一台のサーバが前記データの原本データを管理する原本管理サーバとなり、他のサーバのいずれかが前記データの複製データを管理する複製管理サーバとなり、
   一の前記データに関して前記原本管理サーバとなる前記サーバは、
   一の前記データに関する前記原本データが記憶されるとともに、一の前記データに関する前記原本データ及び前記複製データが前記複数のサーバのいずれによって管理されているかを示す複製管理情報が記憶される記憶部と、
   クライアントマシンからのリクエストを処理することによって前記記憶部に記憶された前記原本データを更新し、かかるリクエストの処理とは非同期に、更新された前記原本データを前記複製管理サーバに送信して前記複製データを作成させる処理部を備え、
   前記複製管理情報は、一の前記データに関して、前記サーバごとに当該サーバに記憶された一の前記データが前記原本データとしての管理であるか前記複製データとしての管理であるか複製失敗の状態であるかを示す複製状態を含み、
   一の前記データに関して前記原本管理サーバとなる前記サーバの前記処理部は、前記複製管理サーバによる前記複製データの作成状態を監視し、前記複製データの作成に失敗した場合に、前記複製状態を複製失敗として前記複製管理情報を更新するとともに前記複製データの作成に失敗した前記複製管理サーバを当該分散処理システムから離脱させ、前記複数のサーバのうちの他のサーバを新たな前記複製管理サーバとし、新たな前記複製管理サーバに前記複製データを作成させ、前記複製データの作成に成功した新たな前記複製管理サーバに関する前記複製管理情報を作成して前記記憶部に記憶させ、
   一の前記データに関して前記複製管理サーバとなる前記サーバは、
   一の前記データに関する前記複製データが記憶されるとともに、前記複製管理情報が記憶される記憶部と、
   前記複製データを前記記憶部に記憶させる処理部を備え、
   一の前記データに関して前記複製管理サーバとなる前記サーバの前記処理部は、前記複製データの作成中に前記原本管理サーバがダウンした場合には、作成しようとした前記複製データの中で作成済みの前記複製データを当該複製管理サーバの前記記憶部に記憶させるとともに、一の前記データに関して当該複製管理サーバが原本管理サーバとなり作成済みの前記複製データが前記原本データとなるように前記複製管理情報を更新する
   ことを特徴とする分散処理システム。
2. 環状のＩＤ（IDentifier）空間に、処理対象の複数の前記データのＩＤ、及び、クラスタを構成し前記データに関するリクエストを処理する前記複数のサーバのＩＤが割り当てられ、前記ＩＤ空間において前記データのＩＤから所定方向回りに辿って最初に遭遇した前記サーバまでの間に位置する前記データを、当該サーバが前記原本管理サーバとなって前記原本データとして保持するとともに、前記クラスタ内の前記原本管理サーバ以外のサーバのいずれかが前記複製管理サーバとなって前記複製データを保持する
   ことを特徴とする請求項１に記載の分散処理システム。

Images