(57)【要約】      （修正有）【課題】クラスタシステム内で一貫性が必要とされるデータの不整合を検出し回復する。【解決手段】クラスタシステムを構成するノード１０は、死活監視部１１３が死活監視信号と共に、一貫性が必要とされるデータを受信する。また、ノード識別子管理部１１１が、自身のデータと受信したデータとを比較し、双方のデータ間に不整合を検出する。そして、ノード識別子管理部１１１は、自身のデータを特権メンバのノードに送信する。特権メンバのノードのノード識別子管理部１１１は、自身のデータと受信したデータとを比較して、不整合を検出した場合、自身のデータを、不整合のデータを有するノードに送信する。そして、特権メンバのノードのデータを受信したノードのノード識別子管理部１１１は、受信したデータで自身のデータを更新（上書き）し、不整合を回復する。【選択図】図２
2014146153.tif 000002
【特許請求の範囲】
【請求項１】
複数のノードで構成されるクラスタシステムであって、
前記ノードは、
複数の前記ノード間で一貫性が必要とされるデータが記憶される記憶部と、
死活監視対象の前記ノードに、死活監視情報と共に前記データを送信する死活監視部と、
前記死活監視情報と共に受信した前記データと自身の前記記憶部の前記データとを比較し、不整合を検出するノード識別子管理部と、
を備えることを特徴とするクラスタシステム。
【請求項２】
複数のノードで構成されるクラスタシステムであって、
前記ノードは、
複数の前記ノード間で一貫性が必要とされるデータが記憶される記憶部と、
死活監視対象の前記ノードに送信した死活監視情報に対して返信される応答情報と共に前記データを受信する死活監視部と、
前記応答情報と共に受信した前記データと自身の前記記憶部の前記データとを比較し、不整合を検出するノード識別子管理部と、
を備えることを特徴とするクラスタシステム。
【請求項３】
前記ノード識別子管理部は、
不整合を検出した場合、前記記憶部に記憶している自身の前記データを、前記データを照合する前記ノードに送信する
ことを特徴とする請求項１または請求項２に記載のクラスタシステム。
【請求項４】
前記ノード識別子管理部は、
不整合を検出した場合、前記記憶部に記憶している自身の前記データおよび受信した前記データを、前記データを照合する前記ノードに送信する
ことを特徴とする請求項１または請求項２に記載のクラスタシステム。
【請求項５】
前記データを照合する前記ノードのノード識別子管理部は、
送信されてきた前記データと前記記憶部に記憶している自身の前記データとの間に不整合を検出した場合、不整合とされた前記データを記憶している前記ノードに、自身の前記データを送信し、
前記データを照合する前記ノードから送信されてきた前記データを受信した前記ノードのノード識別子管理部は、
自身の前記記憶部の前記データを、前記データを照合する前記ノードから受信した前記データで更新する
ことを特徴とする請求項３または請求項４に記載のクラスタシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、複数のノードで構成されたクラスタシステム（クラスタ構成の分散システム）内で、各ノード間で一貫性が必要とされるデータ（例えば、管理情報）の不整合を検出し回復する技術に関する。
【背景技術】
【０００２】
近年、複数のコンピュータ（ノード）を協調動作させて全体で１台のコンピュータであるかのように振舞うクラスタシステムが、クラウドコンピューティングに利用されている。
【０００３】
クラスタシステムは、多量なデータの処理や保持を効率的に実行することができる。データ管理手法の一例として、処理対象のデータに含まれるkeyをハッシュ関数に適用してハッシュ値（hash(key)と表記）を算出し、そのハッシュ値をノード（サーバ）数Ｎで割った余り、すなわち、hash(key) mod Ｎを算出し、その算出した数値（番号）に関連付けられたノードが当該データを処理または保持する技術が開示されている。ただし、ノードの番号は、０〜（Ｎ−１）のいずれかが割り当てられているものとする。このデータ管理手法では、ノードを追加または離脱すると、Ｎの値が変化するため、データの処理や保持を担当するノードが変更になる。言い換えると、ノードの追加または離脱後に、クラスタシステム内で、担当のノードが変更になった多量のデータを再配置しなければならないという問題が発生する。
【０００４】
再配置によって影響を受けるデータ量を低減するために、コンシステント・ハッシュ法（非特許文献１参照）を用いたデータ管理手法が開示され、実際に運用されている（非特許文献２参照）。コンシステント・ハッシュ法は、ＩＤ空間で用いられるＩＤをノードに割り当てるとともに、前記ＩＤ空間内の値（すなわちＩＤ）を算出するハッシュ関数によってデータのハッシュ値を算出する。なお、ＩＤ空間は、例えば、ＩＤが０〜Ｍであった場合には、０からＭまで昇順に円上に並べ、Ｍの次が再び０から始まって巡回するように構成されている。そして、例えば、データのハッシュ値から前記ＩＤ空間を一方向に辿って最初に到達するノードが、当該データの処理や保持を担当するように決める。ここで、一方向とは、ＩＤ空間のＩＤが円上に配置されている状態において、例えば、ＩＤが昇順方向（時計回りの方向）を意味している。
【０００５】
また、クラスタシステムにおいて、各ノードのデータ処理性能が等しい場合、各ノードが担当するデータ量は等しいことが望ましい。すなわち、コンシステント・ハッシュ法のＩＤ空間において、ノードのＩＤ間の距離（担当領域）が等しいことが望ましい。そのために、１つのノードに複数の仮想的なＩＤ（以降、仮想ＩＤと称す）を割り当てる手法が開示されている（非特許文献１参照）。この手法では、ノードそれぞれが複数の仮想ＩＤを持つことで、仮想ＩＤ毎の担当領域が異なっていても、大数の法則に従って、各ノードの担当領域を平均化することができる。
【先行技術文献】
【非特許文献】
【０００６】
【非特許文献１】David Karger、外５名、“Consistent Hashing and Random Trees: Distributed Caching Protocols for Relieving Hot Spots on the World Wide Web”、［online］、［２０１３年１月１０日検索］、インターネット＜URL：http://www.akamai.com/dl/technical_publications/ConsistenHashingandRandomTreesDistributedCachingprotocolsforrelievingHotSpotsontheworldwideweb.pdf＞
【非特許文献２】Giuseppe DeCandia、外８名、“Dynamo: Amazon’s Highly Available Key-value Store”、［online］、［２０１３年１月１０日検索］、インターネット＜URL：http://www.allthingsdistributed.com/files/amazon-dynamo-sosp2007.pdf＞
【発明の概要】
【発明が解決しようとする課題】
【０００７】
クラスタシステムは、クラスタを構成するノードの追加および離脱に対応するために、ノード間で一貫性が必要とされるデータ（管理情報）に基づいて、データの処理および保持を行っている。例えば、一貫性が必要とされるデータ（管理情報）には、クラスタを構成するノード群の情報や、それにデータのノード配置を加えた情報等がある。具体的には、一貫性が必要とされるデータ（管理情報）には、ノード識別子とＩＰ（Internet Protocol）アドレスとを関連付けたノード識別子管理テーブルや、死活を監視する対象のノードをリストアップした死活監視テーブルがある。
【０００８】
ノード識別子管理テーブルは、前記ＩＤ空間のＩＤまたは仮想ＩＤと一意に対応付けたノード識別子と、ノードが通信を行うために用いられるＩＰアドレスとを関連付けたものである。また、死活監視テーブルは、どのノードの死活を監視するのかについて、監視対象のノードをリストアップしたものであって、監視対象のノードのＩＰアドレスを格納したものである。
【０００９】
クラスタシステムにおいて、ノードの追加が行われた場合や、ノードが故障して離脱した場合には、システムの構成が変更になる。その構成変更に伴って、すべてのノードにおいて、ノード識別子管理テーブルや死活監視テーブルは更新される必要がある。しかしながら、すべてのノードでのノード識別子管理テーブルや死活監視テーブルの更新が完了する前 に、新たにノードの追加や離脱（故障）が発生した場合に、一貫性が必要とされるデータ（管理情報）がノード間で不整合を生じるという問題が発生する。
【００１０】
そこで、本発明は、クラスタシステム内で一貫性が必要とされるデータの不整合を検出し回復することを課題とする。
【課題を解決するための手段】
【００１１】
本発明は、複数のノードで構成されるクラスタシステムであって、前記ノードが、複数の前記ノード間で一貫性が必要とされるデータが記憶される記憶部と、死活監視対象の前記ノードに、死活監視情報と共に前記データを送信する死活監視部と、前記死活監視情報と共に受信した前記データと自身の前記記憶部の前記データとを比較し、不整合を検出するノード識別子管理部と、を備えることを特徴とする。
【００１２】
また、前記クラスタシステムは、前記ノードが、複数の前記ノード間で一貫性が必要とされるデータが記憶される記憶部と、死活監視対象の前記ノードに送信した死活監視情報に対して返信される応答情報と共に前記データを受信する死活監視部と、前記応答情報と共に受信した前記データと自身の前記記憶部の前記データとを比較し、不整合を検出するノード識別子管理部と、を備えることを特徴とする。
【００１３】
このような構成によれば、クラスタシステムは、クラスタシステム内で一貫性が必要とされるデータの不整合を検出することができる。また、クラスタシステムは、もともと使用している死活監視信号と共に一貫性が必要とされるデータを送信することができるので、不整合を検出するためだけの送信手段を別に備える必要がない。また、クラスタシステムは、一貫性が必要とされるデータだけを送信する必要がないため、通信コストの増加を抑制することができる。
【００１４】
前記ノード識別子管理部は、不整合を検出した場合、前記記憶部に記憶している自身の前記データを、前記データを照合する前記ノードに送信することを特徴とする。
【００１５】
前記ノード識別子管理部は、不整合を検出した場合、前記記憶部に記憶している自身の前記データおよび受信した前記データを、前記データを照合する前記ノードに送信することを特徴とする。
【００１６】
このような構成によれば、クラスタシステムは、データを照合するノードを設けることによって、不整合が検出されたデータを、そのデータを照合するノードに送信し、全ノードに対して共通のデータに揃えることができる。つまり、クラスタシステム内で一貫性が必要とされるデータの不整合を回復することができる。
【００１７】
前記データを照合する前記ノードのノード識別子管理部は、送信されてきた前記データと前記記憶部に記憶している自身の前記データとの間に不整合を検出した場合、不整合とされた前記データを記憶している前記ノードに、自身の前記データを送信し、前記データを照合する前記ノードから送信されてきた前記データを受信した前記ノードのノード識別子管理部は、自身の前記記憶部の前記データを、前記データを照合する前記ノードから受信した前記データで更新することを特徴とする。
【００１８】
このような構成によれば、クラスタシステムは、クラスタシステム内で一貫性が必要とされるデータの不整合を回復することができる。
【発明の効果】
【００１９】
本発明によれば、クラスタシステム内で一貫性が必要とされるデータの不整合を検出し回復することができる。
【図面の簡単な説明】
【００２０】
【図１】クラスタシステムを含むネットワークサービスシステムの構成例を示す図である。
【図２】ノードの機能例を示す図である。
【図３】ノード識別子管理テーブルの一例を示す図である。
【図４】死活監視テーブルの一例を示す図である。
【図５】不整合を検出し回復する処理例を示す図であり、（ａ）は不整合を検出する場合を表し、（ｂ）は不整合を回復する場合を表す。
【図６】不整合を検出し回復する第１変形例の処理例を示す図であり、（ａ）は不整合を検出する場合を表し、（ｂ）は不整合を回復する場合を表す。
【図７】不整合を検出し回復する第２変形例の処理例を示す図であり、（ａ）は不整合を検出する場合を表し、（ｂ）は不整合を回復する場合を表す。
【図８】ノード間でノード識別子管理テーブルが不整合となる場合の一例を示す図であり、（ａ）は離脱するノードを通知する処理を表し、（ｂ）はノード識別子管理テーブルを配信する処理を表し、（ｃ）は新たに離脱するノードを通知する処理を表し、（ｄ）はノード識別子管理テーブルを配信する処理を表す。
【発明を実施するための形態】
【００２１】
本発明を実施するための形態（以降、「本実施形態」と称す。）について、適宜図面を参照しながら詳細に説明する。本実施形態では、複数のノードで構成されるクラスタシステム内で一貫性が必要とされるデータの一例として、ノード識別子管理テーブル（図３参照）に焦点を当てて説明をする。
【００２２】
はじめに、ノード識別子管理テーブルが不整合となる場合について、図８を用いて説明する。なお、説明を分かりやすくするために、クラスタシステムが、コンシステント・ハッシュ法を用いてデータ管理を行っているものとする。
【００２３】
図８（ａ）〜（ｄ）は、前記ＩＤ空間内に、６つのノード「１」〜「６」（黒丸印）のＩＤが配置されているケースを表している。また、図８（ａ）〜（ｄ）中の四角は、ノード識別子管理テーブルを表している。なお、クラスタシステム内のノード「１」〜「６」それぞれは、時計回りに隣のノード「２」〜「６」，「１」の死活監視を行うケースで説明する。つまり、図８（ａ）に示すように、ノード「４」は、ノード「５」の死活監視を行うものとする。
【００２４】
いま、図８（ａ）に示すように、ノード「４」は、ノード「５」の死活監視を行って、ノード「５」が故障したことを検出する。図８（ａ）では、ノード「５」の位置に、故障したことを示す×印が付されている。そして、ノード「４」は、ノード「５」が故障して離脱したことを特権メンバのノード「１」に通知する（図８（ａ）では、「離脱ノードの通知」と表記）。
【００２５】
ここで、特権メンバのノード「１」は、クラスタシステム内で一意に決められるものとする。例えば、特権メンバのノード「１」は、ノードに割り当てられた前記ＩＤ空間内のＩＤの昇順に選出される等のようにして、決められる。特権メンバのノード「１」は、離脱ノードの通知を受信したとき、自身が管理しているノード識別子管理テーブルを更新し、その更新したノード識別子管理テーブルをクラスタシステム内の自身以外のノードに配信する処理を実行する。
【００２６】
図８（ｂ）では、特権メンバのノード「１」は、自身のノード識別子管理テーブルを更新し（図８（ｂ）中では、「５：離脱」と表記）、更新したノード識別子管理テーブルを他のノード「２」〜「４」，「６」に送信しようとする（図８（ｂ）中では、実線および破線で表記）。この際、ノード識別子管理テーブルをそのまま送信すると配信負荷が大きくなるため、特権メンバのノード「１」は、差分情報のみを配信する。差分情報とは、ここでは、ノード「５」が離脱したことである。
【００２７】
そして、特権メンバのノード「１」が、ノード識別子管理テーブルの差分情報を送信している途中で、故障したものとする。その結果、ノード「４」，「６」それぞれは、差分情報を受信し（図８（ｂ）中の実線矢印）、自身のノード識別子管理テーブルにノード「５」の離脱を反映して更新する（図８（ｂ）中では、「５：離脱」と表記）。しかし、ノード「２」，「３」それぞれは、差分情報を受信していない（図８（ｂ）中の破線矢印）。したがって、ノード「４」，「６」とノード「２」，「３」との間で、ノード識別子管理テーブルに不整合が発生する。
【００２８】
次に、図８（ｃ）では、ノード「６」は、ノード「１」の死活監視を行って、ノード「１」に故障が発生したことを検出する。図８（ｃ）では、ノード「１」の位置に、故障したことを示す×印が付されている。そして、ノード「６」は、ノード「１」が故障して離脱したことを特権メンバのノード「２」に通知する（図８（ｃ）では、「離脱ノードの通知」と表記）。
【００２９】
図８（ｃ）では、特権メンバとしてノード「２」が新たに選出されている。ノード「６」は、旧特権メンバのノード「１」が故障していることを既に検出しているため、ノード「１」の次に大きいＩＤのノード「２」を選出する（図８（ｃ）では、「新選出」と表記）。各ノード「１」〜「６」が特権メンバの新選出を行うきっかけは、離脱ノードの通知を特権メンバのノードに送信しても当該特権メンバのノードから応答情報が戻ってこなかった場合、または、新選出された特権メンバのノードから差分情報を受信した場合、である。また、ノード「２」は、離脱ノードの通知を受信したとき、自身が特権メンバのノードに選出されていることを認識する。
【００３０】
図８（ｄ）では、特権メンバのノード「２」は、自身のノード識別子管理テーブルを更新する（図８（ｄ）では、「１：離脱」と表記）。そして、特権メンバのノード「２」は、更新したノード識別子管理テーブルの差分情報を他のノード「３」，「４」，「６」に送信する。その結果、ノード「２」，「３」のノード識別子管理テーブルは、ノード「１」の離脱が反映されたものとなる（図８（ｄ）では、「１：離脱」と表記）。また、ノード「４」，「６」のノード識別子管理テーブルは、ノード「１」，「５」の離脱が反映されたものとなる（図８（ｄ）では、「１：離脱、５：離脱」と表記）。したがって、ノード「２」，「３」とノード「４」，「６」との間で、ノード識別子管理テーブルに不整合が発生する。
【００３１】
（前提条件）
ここで、本実施形態のクラスタシステムの前提条件について説明する。
（１）クラスタシステムを構成するノードが相互に死活監視を実行する。具体的には、図８（ａ）（ｃ）に例示したように、クラスタシステム内のノード「１」〜「６」それぞれは、時計回りに隣のノード「２」〜「６」，「１」の死活監視を行う。このことによって、クラスタシステムのノード数が増加しても、１つのノードが死活を監視する対象ノードの数が増加しない。そのため、クラスタシステムは、システム全体の性能の低下を防ぐことができる。それに対して、クラスタシステムを構成するノード間で、Ｎ台のノードそれぞれが自身以外のＮ−１台に対して死活監視を行う場合には、クラスタシステムを構成するノードの台数Ｎの増大に依存して、死活監視のための負荷が大きくなる。したがって、クラスタシステム全体の性能が落ちることを防ぐためには、一台のノードが死活監視を行うノード数を限定することが望ましい。
【００３２】
（２）各ノードは、死活監視によって故障しているノードを発見した場合には、離脱ノードの通知を特権メンバのノードまたは不図示の外部システムに送信する。特権メンバのノードまたは外部システムは、離脱ノードの通知を受信した場合、自身のノード識別子管理テーブル（一貫性が必要とされるデータ）を更新する。また、特権メンバのノードまたは外部システムは、保守契機で意図的にノードの追加や離脱を行う際にも、ノード識別子管理テーブルを更新する。ここで、外部システムとは、各ノードとは別に設けられた、ノード識別子管理テーブルを更新する装置である。
【００３３】
（３）特権メンバのノードまたは外部システムは、更新したノード識別子管理テーブルを送信する際に、差分情報だけを送信する。これは、ノード識別子管理テーブルをそのまま送信すると配信負荷が大きくなるのを防ぐためである。
【００３４】
（４）クラスタシステムでは、処理に用いるデータの複製を保持することで冗長管理する場合、データの複製先は、ノード識別子管理テーブルに基づいて決定される。したがって、ノード識別子管理テーブルが更新された場合には、データの複製先も更新される。なお、クラスタシステムに要求されている信頼性に合わせて、データの複製先の数を増加するようにしてもよい。
【００３５】
（ネットワークサービスシステム）
次に、ネットワークサービスシステム２００の構成例について、図１を用いて説明する。
ネットワークサービスシステム２００は、ノード（サーバ）１０によって構築されるクラスタシステム１００、振り分け装置２０、ロードバランサ３０およびクライアント端末４０によって構成される。
クライアント端末４０は、ユーザがネットワークサービスを享受するために、サービスへのメッセージ（入力情報等）をクラスタシステム１００に送信したり、クラスタシステム１００から当該メッセージに対応する応報情報（サービス情報）を受信して表示したりする機能を有する。
【００３６】
ロードバランサ３０は、クライアント端末４０から送信されるメッセージを、単純なラウンドロビン法等により振り分け装置２０に振り分ける機能を有する。
振り分け装置２０は、クライアント端末４０から送信されるメッセージを、各ノード１０に振り分ける機能を有する。メッセージの振り分けには、例えば、コンシステント・ハッシュ法を用いることができる。
ノード１０は、クラスタシステム１００を構成する、コンピュータ等の物理装置や仮想マシン等の論理装置である。ノード１０は、クライアント端末４０から送信されるメッセージを受信して処理を実行し、クライアント端末４０に応答情報（サービス情報）を返信することによって、サービスを提供する機能を有する。
【００３７】
クライアント端末４０とロードバランサ３０との間は、第１ネットワーク５０で通信可能に接続される。ロードバランサ３０と振り分け装置２０との間は、第２ネットワーク５１で通信可能に接続される。また、振り分け装置２０とノード１０との間は、第３ネットワーク５２で通信可能に接続される。
なお、図１では振り分け装置２０とノード１０とを別々に記載したが、同一サーバ上で別々の機能として動作させることも可能である。また、振り分け装置２０をクラスタ構成にすることも可能である。さらに、ロードバランサ３０が存在せず、クライアント端末４０から任意の振り分け装置２０にメッセージが直接送信されるような構成にしても構わない。
【００３８】
（ノード）
次に、ノード１０の機能例について、図２を用いて説明する（適宜、図１参照）。ノード１０は、処理部１１、記憶部１２および通信部１３を備える。
処理部１１は、図示しないＣＰＵ（Central Processing Unit）およびメインメモリで構成され、記憶部１２に記憶されているアプリケーションプログラムをメインメモリに展開して、ノード識別子管理部１１１、メッセージ処理部１１２および死活監視部１１３を機能として実現する。
【００３９】
特権メンバのノード１０のノード識別子管理部１１１は、クラスタシステム１００にノード１０が追加された場合、追加されたノード１０を識別するノード識別子を、記憶部１２のノード識別子管理テーブル１２１（図３参照）に追加する更新を実行する。なお、ノード識別子は、ＩＤ空間上のノード１０のＩＤや仮想ＩＤに対応して一意に付与される。また、特権メンバのノード１０のノード識別子管理部１１１は、ノード１０から離脱ノードの通知を受信した場合、その離脱したノード１０のノード識別子を、記憶部１２のノード識別子管理テーブル１２１（図３参照）から削除する更新を行う。そして、特権メンバのノード１０のノード識別子管理部１１１は、更新したノード識別子管理テーブル１２１の差分情報を自身以外のノード１０に送信する。
【００４０】
また、ノード識別子管理部１１１は、死活監視信号と共に送信されてきたノード識別子管理テーブル１２１と、自身のノード識別子管理テーブル１２１とを比較し、不整合を検出する。そして、ノード識別子管理部１１１は、不整合を検出した場合、ノード識別子管理テーブル１２１を特権メンバのノード１０に送信する。また、ノード識別子管理部１１１は、特権メンバのノード１０からノード識別子管理テーブル１２１に係る情報を受信した場合、自身のノード識別子管理テーブル１２１を更新（上書き）する。なお、ノード識別子管理部１１１の不整合の検出および回復（更新）に関する処理の詳細については後記する。
【００４１】
ここで、ノード識別子管理テーブル１２１の一例について、図３を用いて説明する（適宜、図２参照）。
ノード識別子管理テーブル１２１（複数ノード間で一貫性が必要とされるデータ）は、記憶部１２に記憶され、ノード識別子１３１およびアドレス１３２を関連付けて記憶している。
ノード識別子１３１は、ノード１０を識別するように付与されるものであって、ＩＤ空間のＩＤまたは仮想ＩＤと一意に対応している。
アドレス１３２は、ノード１０の通信先を表す。
ノード１０が追加された場合には、当該ノード１０のノード識別子１３１およびアドレス１３２の行が追加される。また、ノード１０が離脱した場合には、当該ノード１０のノード識別子１３１およびアドレス１３２の行が削除される。
【００４２】
なお、特権メンバのノード１０は、どのノード１０からみても一意に選出される必要がある。したがって、特権メンバのノード１０は、例えば、ノード識別子管理テーブル１２１の何行目のノード識別子１３１のノード１０を特権メンバとするといった決め方によって、決定されればよい。
【００４３】
図２に戻って、メッセージ処理部１１２は、振り分け装置２０から振り分けられたメッセージを処理し、処理結果をクライアント端末４０に返信する。また、メッセージ処理部１１２は、他のノード１０（例えば、ノード識別子１３１を昇順に並べた時に、前記ＩＤ空間の１つ先のノード１０）をデータ複製先として、複製データを記憶する。さらに、複製データを複数保持する場合には、メッセージ処理部１１２は、前記他のノード１０とは別のノード１０（例えば、ノード識別子１３１を昇順に並べた時に、ＩＤ空間の２つ先のノード１０）にも複製データを記憶する。このようにすることによって、クラスタシステム１００は、データの冗長化を実現することができる。また、メッセージ処理部１１２は、処理するデータが見つからない場合には、ノード識別子管理デーブル１２１に基づいてデータ複製先から複製データを取得し、データ処理（サービス）を継続することができる。
【００４４】
死活監視部１１３は、死活監視テーブル１２２を参照して、死活を監視する対象のノード１０を抽出し、当該ノード１０に死活監視信号（死活監視情報）を送信する。そして、死活監視部１１３は、死活監視信号に対応する応答情報を受信しなかった場合、当該ノード１０の故障を検出する。故障を検出した場合、死活監視部１１３は、特権メンバのノード１０（または外部システム）に離脱ノードの通知を送信する。死活監視部１１３は、クラスタシステム１００を構成するノード１０の追加や離脱があった場合、ノード識別子管理テーブル１２１の更新に同期して死活監視テーブル１２２を更新する。
【００４５】
また、死活監視部１１３は、死活監視信号と共に、ノード識別子管理テーブル１２１を、死活監視対象のノード１０に送信する処理を実行する。この処理の詳細については、後記する。
【００４６】
ここで、死活監視テーブル１２２の一例について、図４を用いて説明する。
図４の左の図は、ＩＤ空間を表し、図中の丸印は、仮想ＩＤを表している。黒丸印「●」は、各物理装置にとって、それが担当する１または複数の仮想ＩＤのうち最も小さい値の仮想ＩＤを表し、数字は、ＩＤ空間のＩＤを表している。ここでは、物理装置は６台からなる。
【００４７】
そして、図４の右の図は、左図の黒丸印の仮想ＩＤに対応する死活監視テーブル１２２の一例を表している。つまり、死活監視テーブル１２２は、１台の物理装置を単位として作成される。なお、死活監視テーブル１２２は、少なくとも死活監視対象のアドレスを記憶している。
【００４８】
図２に戻って、記憶部１２は、メモリやハードディスク等で構成され、前記したノード識別子管理テーブル１２１、死活監視テーブル１２２および前記したアプリケーションプログラムを記憶している。
通信部１３は、第３ネットワーク５２を介してメッセージや応答情報を送受信するためのインタフェースである。
【００４９】
（不整合の検出処理および回復処理の流れ）
次に、クラスタシステム１００内で一貫性が必要とされるデータに不整合が生じた場合に、不整合を検出し回復する処理の流れについて、図５を用いて説明する（適宜、図２参照）。なお、一貫性が必要とされるデータの一例として、ノード識別子管理テーブル１２１に不整合が生じた場合について示す。図５（ａ）は不整合を検出する場合を表し、（ｂ）は不整合を回復する場合を表している。
【００５０】
図５（ａ）（ｂ）では、黒丸印は、ＩＤ空間内のノード１０を表し、図５中の数字はＩＤ空間のＩＤを表している。また、図５中の「Ａ」「Ｂ」は、ノード識別子管理テーブル１２１の内容またはバージョンを表しているものとする。
【００５１】
（１）不整合の検出
例えば、図５（ａ）に示すように、ノード「４」の死活監視部１１３は、死活監視信号と共に自身のノード識別子管理テーブル「Ａ」を、死活監視対象のノード「５」に送信する（Ｓ５１）。ノード「５」のノード識別子管理部１１１は、受信したノード識別子管理テーブル「Ａ」と自身のノード識別子管理テーブル「Ｂ」とを比較し、不整合が有るか無いかを判定する（Ｓ５２：「不整合検出」）。なお、死活監視信号と共に送信するノード識別子管理テーブル１２１は、テーブル全体であってもよいが、ノード識別子管理テーブル１２１の整合性を確認できるデータに変換してあっても構わない。例えば、変換したデータは、ノード識別子管理テーブル１２１をハッシュ関数で変換したハッシュ値であっても構わない。整合性の確認は、所定の周期（一定周期を含む）で行われる。例えば、整合性の確認のために行うノード識別子管理テーブル１２１の送信は、死活監視と同じ周期で実行しても、死活監視を複数回実行する間に１回実行しても構わない。
【００５２】
ノード「５」のノード識別子管理部１１１は、不整合を検出した場合、自身のノード識別子管理テーブル「Ｂ」を、特権メンバのノード「１」に送信する（Ｓ５３）。
【００５３】
（２）不整合の回復
特権メンバのノード「１」のノード識別子管理部１１１は、自身のノード識別子管理テーブル「Ａ」と、受信したノード識別子管理テーブル「Ｂ」とを比較し、不整合が有るか無いかを判定する（Ｓ５４：「照合」）。つまり、特権メンバのノード「１」は、ノード識別子管理テーブル１２１を照合する機能を有している。そして、特権メンバのノード「１」のノード識別子管理部１１１は、不整合を検出した場合、図５（ｂ）に示すように、ノード識別子管理テーブル「Ｂ」を送信してきたノード「５」に、自身のノード識別子管理テーブル「Ａ」を送信する（Ｓ５５）。ノード「５」のノード識別子管理部１１１は、特権メンバのノード「１」から受信したノード識別子管理テーブル「Ａ」に基づいて、自身のノード識別子管理テーブル「Ｂ」を「Ａ」に更新（上書き）する（Ｓ５６：「不整合回復」）。このことにより、不整合が回復する。なお、特権メンバのノード「１」がノード「５」に送信する情報は、図５（ｂ）中ではノード識別子管理テーブル１２１全体であるように表しているが、相違する情報だけであっても構わない。
【００５４】
（第１変形例）
図５では、死活監視信号と共にノード識別子管理テーブルを受信したノード「５」が不整合の有無を判定するように説明した。それに対して、第１変形例では、死活監視信号に対して返信された応答情報と共にノード識別子管理テーブルを受信したノード「４」が不整合の有無を判定する場合について、図６を用いて説明する。
【００５５】
（１）不整合の検出
図６（ａ）に示すように、ノード「４」の死活監視部１１３は、死活監視信号を、死活監視対象のノード「５」に送信する（Ｓ６１）。ノード「５」の死活監視部１１３は、受信した死活監視信号に対して返信する応答情報と共に自身のノード識別子管理テーブル「Ａ」を、ノード「４」に送信する（Ｓ６２）。なお、応答情報と共に送信するノード識別子管理テーブル１２１は、テーブル全体であってもよいが、ノード識別子管理テーブル１２１の整合性を確認できるデータに変換してあっても構わない。例えば、変換したデータは、ノード識別子管理テーブル１２１をハッシュ関数で変換したハッシュ値であっても構わない。ノード「４」のノード識別子管理部１１１は、受信したノード識別子管理テーブル「Ａ」と自身のノード識別子管理テーブル「Ｂ」とを比較し、不整合が有るか無いかを判定する（Ｓ６３：「不整合検出」）。整合性の確認は、所定の周期（一定周期を含む）で行われる。例えば、整合性の確認のために行うノード識別子管理テーブル１２１の送信は、死活監視と同じ周期で実行しても、死活監視を複数回実行する間に１回実行しても構わない。
【００５６】
ノード「４」のノード識別子管理部１１１は、不整合を検出した場合、自身のノード識別子管理テーブル「Ｂ」を、特権メンバのノード「１」に送信する（Ｓ６４）。
【００５７】
（２）不整合の回復
特権メンバのノード「１」のノード識別子管理部１１１は、自身のノード識別子管理テーブル「Ａ」と、受信したノード識別子管理テーブル「Ｂ」とを比較し、不整合が有るか無いかを判定する（Ｓ６５：「照合」）。そして、特権メンバのノード「１」のノード識別子管理部１１１は、不整合を検出した場合、図６（ｂ）に示すように、ノード識別子管理テーブル「Ｂ」を送信してきたノード「４」に、自身のノード識別子管理テーブル「Ａ」を送信する（Ｓ６６）。ノード「４」のノード識別子管理部１１１は、特権メンバのノード「１」から受信したノード識別子管理テーブル「Ａ」に基づいて、自身のノード識別子管理テーブル「Ｂ」を「Ａ」に更新（上書き）する（Ｓ６７：「不整合回復」）。このことにより、不整合が回復する。なお、特権メンバのノード「１」がノード「４」に送信する情報は、図６（ｂ）中ではノード識別子管理テーブル１２１全体であるように表しているが、相違する情報だけであっても構わない。
【００５８】
（第２変形例）
図５では、不整合を検出したノード「５」が自身のノード識別子管理テーブル１２１を特権メンバのノード「１」に送信するように説明した。それに対して、第２変形例では、自身のノード識別子管理テーブル１２１だけでなく、ノード「４」のノード識別子管理テーブル１２１も送信する場合について、図７を用いて説明する。
【００５９】
（１）不整合の検出
図７（ａ）に示すように、ノード「４」の死活監視部１１３は、死活監視信号と共に自身のノード識別子管理テーブル「Ｂ」の情報を、死活監視対象のノード「５」に送信する（Ｓ７１）。ノード「５」のノード識別子管理部１１１は、受信したノード識別子管理テーブル「Ｂ」と自身のノード識別子管理テーブル「Ａ」とを比較し、不整合が有るか無いかを判定する（Ｓ７２：「不整合検出」）。なお、死活監視信号と共に送信するノード識別子管理テーブル１２１は、テーブル全体であってもよいが、ノード識別子管理テーブル１２１の整合性を確認できるデータに変換してあっても構わない。例えば、変換したデータは、ノード識別子管理テーブル１２１をハッシュ関数で変換したハッシュ値であっても構わない。整合性の確認は、所定の周期（一定周期を含む）で行われる。例えば、整合性の確認のために行うノード識別子管理テーブル１２１の送信は、死活監視と同じ周期で実行しても、死活監視を複数回実行する間に１回実行しても構わない。
【００６０】
ノード「５」のノード識別子管理部１１１は、不整合を検出した場合、自身のノード識別子管理テーブル「Ａ」およびノード「４」のノード識別子管理テーブル「Ｂ」を、特権メンバのノード「１」に送信する（Ｓ７３）。
【００６１】
（２）不整合の回復
特権メンバのノード「１」のノード識別子管理部１１１は、自身のノード識別子管理テーブル「Ａ」と、受信したノード識別子管理テーブル「Ａ」および「Ｂ」とを比較し、不整合が有るか無いかを判定する（Ｓ７４：「照合」）。そして、特権メンバのノード「１」のノード識別子管理部１１１は、不整合を検出した場合、図７（ｂ）に示すように、ノード識別子管理テーブル「Ｂ」を備えるノード「４」に、自身のノード識別子管理テーブル「Ａ」を送信する（Ｓ７５）。ノード「４」のノード識別子管理部１１１は、特権メンバのノード「１」から受信したノード識別子管理テーブル「Ａ」に基づいて、自身のノード識別子管理テーブル「Ｂ」を「Ａ」に更新（上書き）する（Ｓ７６：「不整合回復」）。このことにより、不整合が回復する。なお、特権メンバのノード「１」がノード「４」に送信する情報は、図７（ｂ）中ではノード識別子管理テーブル１２１全体であるように表しているが、相違する情報だけであっても構わない。
【００６２】
以上、本実施形態および変形例のクラスタシステム１００は、クラスタシステム１００を構成するノード１０の追加や離脱の影響を受けることなくデータ処理を継続するために、クラスタシステム１００内で一貫性が必要とされるデータの不整合を検出し、回復することができる。具体的には、ノード１０は、死活監視信号と共に、一貫性が必要とされるデータを受信して、自身のデータと比較し、双方のデータ間に不整合を検出する。そして、ノード１０は、不整合を検出した場合、一貫性が必要とされるデータを特権メンバのノード１０に送信する。特権メンバのノード１０は、自身のデータと受信したデータとを比較して、不整合を検出した場合、自身のデータを、不整合のデータを記憶しているノード１０に送信する。そして、特権メンバのノード１０からデータを受信したノード１０は、受信したデータで自身のデータを更新（上書き）し、不整合を回復する。
【００６３】
このようにして、クラスタシステム１００は、クラスタシステム１００内で一貫性が必要とされるデータの不整合を検出し回復することができる。また、本実施形態および変形例のクラスタシステム１００は、もともと使用している死活監視信号と共に一貫性が必要とされるデータを送信するので、不整合を検出するためだけの送信手段を別に備える必要がなく、一貫性が必要とされるデータだけを送信する必要がないため、通信コストの増加を抑制することができる。
【００６４】
なお、第２変形例では、死活監視信号を受信したノード「５」が、ノード「４」「５」のノード識別子管理テーブル１２１を特権メンバのノード「１」に送信するケースを説明した。それに対して、第１変形例の場合と同様に、死活監視信号に対して返信される応答情報と共にノード識別子管理テーブルを受信したノード「４」が不整合の有無を判定し、不整合を検出した場合、ノード「４」「５」のノード識別子管理テーブル１２１を特権メンバのノード「１」に送信するようにしてもよい。
【００６５】
また、図７（ａ）では、ノード「４」のノード識別子管理テーブル１２１が「Ｂ」で、ノード「５」のノード識別子管理テーブル１２１が「Ａ」の場合で説明したが、仮に、ノード「５」のノード識別子管理テーブル１２１が「Ｃ」であった場合について説明する。
この場合には、特権メンバのノード「１」は、ノード「４」および「５」の双方に、自身のノード識別子管理テーブル「Ａ」を送信する。言い換えると、特権メンバのノード「１」は、不整合となったノード識別子管理テーブル１２１を記憶しているノード「４」および「５」に、自身のノード識別子管理テーブル１２１（または相違する情報）を送信する。
【００６６】
また、図５〜７では、特権メンバのノード１０が、不整合を検出したノード１０から、ノード識別子管理テーブル１２１を受信して、不整合を検出した場合、自身のノード識別子管理テーブル１２１を送信するように説明した。それに対して、特権メンバのノード１０の代わりに、不図示の外部システムが特権メンバのノード１０と同様の処理を実行しても構わない。
また、特権メンバのノード１０は、死活監視テーブル１２２の１行目のノード１０にするといった決め方によって、決定しても構わない。このようにすることにより、物理装置単位で、特権メンバを決定することができる。
【符号の説明】
【００６７】
１０  ノード
１１  処理部
１２  記憶部
１３  通信部
２０  振り分け装置
３０  ロードバランサ
４０  クライアント端末
１１１  ノード識別子管理部
１１２  メッセージ処理部
１１３  死活監視部
１２１  ノード識別子管理テーブル（一貫性が必要とされるデータ）
１２２  死活監視テーブル
１３１  ノード識別子
１３２  アドレス
【図１】
2014146153.tif 000003
【図２】
2014146153.tif 000004
【図３】
2014146153.tif 000005
【図４】
2014146153.tif 000006
【図５】
2014146153.tif 000007
【図６】
2014146153.tif 000008
【図７】
2014146153.tif 000009
【図８】
2014146153.tif 000010