JP6091376B2 - クラスタシステムおよびＳｐｌｉｔ−ＢｒａｉｎＳｙｎｄｒｏｍｅ検出方法 - Google Patents
クラスタシステムおよびＳｐｌｉｔ−ＢｒａｉｎＳｙｎｄｒｏｍｅ検出方法 Download PDFInfo
- Publication number
- JP6091376B2 JP6091376B2 JP2013167405A JP2013167405A JP6091376B2 JP 6091376 B2 JP6091376 B2 JP 6091376B2 JP 2013167405 A JP2013167405 A JP 2013167405A JP 2013167405 A JP2013167405 A JP 2013167405A JP 6091376 B2 JP6091376 B2 JP 6091376B2
- Authority
- JP
- Japan
- Prior art keywords
- node
- cluster
- proposal
- privileged
- nodes
- 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
- Hardware Redundancy (AREA)
- Debugging And Monitoring (AREA)
Description
本発明は、分散システムにおいて、経路障害等に起因して発生するSplit-Brain Syndromeを検出し解消するクラスタシステムおよびSplit-Brain Syndrome検出方法に関する。
近年、クラウドコンピューティングの隆盛に伴い、多量なデータの処理や管理を効率的に行うことが求められている。そこで、複数のサーバを協調動作させることにより効率的な処理を実現する、分散処理技術が発展している。
分散処理を行う際に、分散システム（以降、クラスタと称す）を構成するサーバ（以降、ノードと呼ぶ）間で協調動作を行う場合がある。例えば、高可用性の求められるシステムにおいては、あるノードに障害が発生した場合にも他のノードで処理を継続できるように複製データを他のノードで保持する（データ冗長化）といった協調動作を行う例が挙げられる。このような協調動作を実施するためには、クラスタを構成するノードの情報（ＩＰアドレス等）をクラスタに参加している全てのノードで把握している必要が生じる。ノードの管理を行う一つの手法として、ノードとは独立に管理サーバを設ける方法が挙げられる。しかし、独立に管理サーバを設ける方法は、この管理サーバがシステム全体の単一障害点（ＳＰＯＦ：Single Point of Failure）となってしまうという問題点がある。
分散処理を行う際に、分散システム（以降、クラスタと称す）を構成するサーバ（以降、ノードと呼ぶ）間で協調動作を行う場合がある。例えば、高可用性の求められるシステムにおいては、あるノードに障害が発生した場合にも他のノードで処理を継続できるように複製データを他のノードで保持する（データ冗長化）といった協調動作を行う例が挙げられる。このような協調動作を実施するためには、クラスタを構成するノードの情報（ＩＰアドレス等）をクラスタに参加している全てのノードで把握している必要が生じる。ノードの管理を行う一つの手法として、ノードとは独立に管理サーバを設ける方法が挙げられる。しかし、独立に管理サーバを設ける方法は、この管理サーバがシステム全体の単一障害点（ＳＰＯＦ：Single Point of Failure）となってしまうという問題点がある。
そこで、クラスタを構成するノードの中から１台を、ノードを管理する特権を持つノード（以降、特権ノードと称す）として選出するノード管理方法が挙げられる。ここで、全ノードは、事前に特権ノードを選出するための同一の規則を知っており、特権ノードに障害が生じた際には残りのノードのうち１台が特権を引き継ぐこととする。このようにクラスタ内に閉じてノード管理を行うことで、特権ノードが単一障害点となることはない。なお、ノード障害発生時には、特権ノード（特権ノードの障害時には次に特権ノードとなるノード）へと通知され、管理されているノードの情報が更新され、残りの全ノードに通知されるものとする。
上記仕組みにより、システム内に単一障害点を作らずにノード管理を行うことができる。ところが、ノードが独自に状況を判断（障害検出や特権ノードの選出）することにより、クラスタが複数に分断したまま、双方が動作し続ける、Split-Brain Syndromeが生じる可能性がある。
図９は、Split-Brain Syndromeの例を示す図である。
図９（ａ）に示すように、クラスタを構成するサーバ群であるノードＡ〜Ｅを相互接続して１台のサーバのように動作させるクラスタシステムにおいて、ノードＡ，ＢとノードＣ〜Ｅとを繋ぐ経路が、経路故障したとする。図９（ａ）では、ノードＡ，ＢとノードＣ〜Ｅとを繋ぐ経路に、経路故障したことを示す×印が付されている。また、クラスタのノードＡに当該クラスタの特権ノードであることを示す王冠印が付されている。図９（ａ）の場合、経路故障によってクラスタを構成するノードＡ，ＢとノードＣ〜Ｅとに分断され、ノードＡ，ＢからはノードＣ〜Ｅが故障したように見え、またノードＣ〜ＥからはノードＡ，Ｂが故障したように見える。
図９（ａ）に示すように、クラスタを構成するサーバ群であるノードＡ〜Ｅを相互接続して１台のサーバのように動作させるクラスタシステムにおいて、ノードＡ，ＢとノードＣ〜Ｅとを繋ぐ経路が、経路故障したとする。図９（ａ）では、ノードＡ，ＢとノードＣ〜Ｅとを繋ぐ経路に、経路故障したことを示す×印が付されている。また、クラスタのノードＡに当該クラスタの特権ノードであることを示す王冠印が付されている。図９（ａ）の場合、経路故障によってクラスタを構成するノードＡ，ＢとノードＣ〜Ｅとに分断され、ノードＡ，ＢからはノードＣ〜Ｅが故障したように見え、またノードＣ〜ＥからはノードＡ，Ｂが故障したように見える。
クラスタシステムには、障害が発生した場合もクラスタを動的に再構成してサービスを維持する対障害機構が備わっており、図９（ｂ）に示すように、双方のクラスタで特権ノード（ここではノードＡとノードＣ）が選出され、動作する。図９（ｂ）では、一方のクラスタのノードＡに当該クラスタの特権ノードであることを示す王冠印が付され、他方のクラスタのノードＣに当該クラスタの特権ノードであることを示す王冠印が付されている。このような状況がSplit-Brain Syndrome発生の一例である。
Split-Brain Syndromeが発生すると、データの一貫性の破綻やサービスの停止等の問題を招く可能性がある。例えば、クラスタ外からのサービスへのアクセスが不能な状態に陥ったり、複数のノードのデータベースへの書き込みが競合し、データベースを破壊したり一貫性を喪失するなど、さまざまな致命的現象を引き起こす可能性がある。
一方、複数のデータ管理装置の中からマスタ（特権ノード）を１台選定する手法、または、データ管理装置の保持するデータの状態を同じに揃える手法として、分散調停プロトコルがある。分散調停プロトコルとして、例えば、データベースやファイルシステムに用いられるPaxosアルゴリズムが知られている（非特許文献１参照）。
Lamport, L. "The part-time parliament," ACM Transactions on Computer Systems 16, 2 (1998), pp.133-169.
Gray, C., Cheriton, D. "Leases: An efficient fault-tolerant mechanism for distributed file cache consistency," In Proceedings of the 12th ACM Symposium on Operating Systems Principles (1989), pp. 202-210.
上記で述べたように、クラスタ内部でノード管理を行うモデルでは、Split-Brain Syndromeによりデータの一貫性の破綻やサービスの停止等の問題を引き起こすケースが存在する。商用の高可用クラスタの中には、Split-Brain Syndromeを防ぐために、事前にクラスタが生存するための定足数（例えば過半数）を設定し、共有ディスクに投票を行うことで生存するノードを決定する手法が挙げられる。
しかしながら、事前に定足数を決定するためにはクラスタを構成するノードの台数は固定である必要があり、分散システムの利点の一つであるノードの参加や離脱を利用してクラスタの処理能力を柔軟に変更する仕組みを活かすことができない。また、共有ディスクにアクセスできない場合には、Split-Brain Syndromeが回避できない、すなわち共有ディスクが単一障害点（ＳＰＯＦ）となる、等の問題が生じる。
このような背景を鑑みて本発明がなされたのであり、本発明は、経路障害等によりクラスタが複数クラスタに分断された場合に、Split-Brain Syndromeの発生を検出し解消することができるクラスタシステムおよびSplit-Brain Syndrome検出方法を提供することを課題とする。
前記した課題を解決するため、複数のノードにより構成されるクラスタを備え、前記クラスタを構成する複数のノードの中からノードを管理する特権を持つ特権ノードを選出するクラスタシステムであって、前記ノードは、ノード識別子が記憶されるノード管理情報と死活を監視する対象のノードをリストアップした死活監視情報とを記憶する記憶部と、前記クラスタへのノードの追加や離脱が発生した際に、前記クラスタを構成するノード識別子を更新し、前記ノード管理情報に記憶するノード管理部と、前記死活監視情報に基づき、指定されたノードと死活監視信号をやり取りして、前記クラスタを構成するノードの障害を検出する死活監視部と、アルゴリズムが完結するまでの一連の流れでのみ１つの提案で合意が取れることを保証する多数決プロトコルであるPaxosアルゴリズムを適用して、Master Leaseで用いるリース期間が途切れないようにリース期間更新間隔を設定して、自身の提案しか通らないように特権ノードである権利期間を確保し、かつ、Proposerが前記Paxosアルゴリズムの一連の流れが完結する前に連続して提案できる回数を２回以上とすることにより、自身が前記ノード管理情報を更新できる前記特権ノードであることを提案し合意を得るとともに、一度提案が受理されなかった場合に次の提案をするまでの時間である提案間隔を前記リース期間とする、特権ノード選出部と、前記提案が２回以上Rejectされた場合、または自身の所属するクラスタの過半数から応答を集められなかった場合、Split-Brain Syndromeが発生したと判定するクラスタ離脱指示部と、を備えることを特徴とする。
また、請求項５に記載の発明は、複数のノードにより構成されるクラスタを備え、前記クラスタを構成する複数のノードの中からノードを管理する特権を持つ特権ノードを選出するクラスタシステムのSplit-Brain Syndrome検出方法であって、前記ノードは、ノード識別子が記憶されるノード管理情報と死活を監視する対象のノードをリストアップした死活監視情報とを記憶しており、前記クラスタへのノードの追加や離脱が発生した際に、前記クラスタを構成するノード識別子を更新し、前記ノード管理情報に記憶するステップと、前記死活監視情報に基づき、指定されたノードと死活監視信号をやり取りして、前記クラスタを構成するノードの障害を検出するステップと、アルゴリズムが完結するまでの一連の流れでのみ１つの提案で合意が取れることを保証する多数決プロトコルであるPaxosアルゴリズムを適用して、Master Leaseで用いるリース期間が途切れないようにリース期間更新間隔を設定して、自身の提案しか通らないように特権ノードである権利期間を確保し、かつ、Proposerが前記Paxosアルゴリズムの一連の流れが完結する前に連続して提案できる回数を２回以上とすることにより、自身が前記ノード管理情報を更新できる前記特権ノードであることを提案し合意を得るとともに、一度提案が受理されなかった場合に次の提案をするまでの時間である提案間隔を前記リース期間とするステップと、前記提案が２回以上Rejectされた場合、または自身の所属するクラスタの過半数から応答を集められなかった場合、Split-Brain Syndromeが発生したと判定するステップと、を実行することを特徴とするクラスタシステムのSplit-Brain Syndrome検出方法とした。
このようにすることで、単一障害点（ＳＰＯＦ）を作らないためにクラスタを構成するノード管理をクラスタ内で実行する分散システムにおいて、経路障害等によりクラスタが複数クラスタに分断された場合に、Split-Brain Syndromeの発生を検出することができる。また、単一障害点となる外部のノード管理システムを利用せずにSplit-brain Syndromeを回避することができる。
また、請求項２に記載の発明は、複数のノードにより構成されるクラスタを備え、前記クラスタを構成する複数のノードの中からノードを管理する特権を持つ特権ノードを選出するクラスタシステムであって、前記ノードは、ノード識別子が記憶されるノード管理情報と死活を監視する対象のノードをリストアップした死活監視情報とを記憶する記憶部と、前記クラスタへのノードの追加や離脱が発生した際に、前記クラスタを構成するノード識別子を更新し、前記ノード管理情報に記憶するノード管理部と、前記死活監視情報に基づき、指定されたノードと死活監視信号をやり取りして、前記クラスタを構成するノードの障害を検出する死活監視部と、アルゴリズムが完結するまでの一連の流れでのみ１つの提案で合意が取れることを保証する多数決プロトコルであるPaxosアルゴリズムを適用して、Master Leaseで用いるリース期間が途切れないようにリース期間更新間隔を設定して、自身の提案しか通らないように特権ノードである権利期間を確保し、かつ、Proposerが前記Paxosアルゴリズムの一連の流れが完結する前に連続して提案できる回数を２回以上とすることにより、自身が前記ノード管理情報を更新できる前記特権ノードであることを提案し合意を得るとともに、前記死活監視部からノード離脱情報を受信し、自身が特権ノードか否かを判定し、自身が特権ノードでない場合に、前記特権ノードのリース期間中が経過したときには、前記クラスタにおいて定められた特権ノード選出の所定の条件に基づき、自身が特権ノード候補であるとする、特権ノード選出部と、前記提案が２回以上Rejectされた場合、または自身の所属するクラスタの過半数から応答を集められなかった場合、Split-Brain Syndromeが発生したと判定するクラスタ離脱指示部と、を備えることを特徴とする。
また、請求項６に記載の発明は、複数のノードにより構成されるクラスタを備え、前記クラスタを構成する複数のノードの中からノードを管理する特権を持つ特権ノードを選出するクラスタシステムのSplit-Brain Syndrome検出方法であって、前記ノードは、ノード識別子が記憶されるノード管理情報と死活を監視する対象のノードをリストアップした死活監視情報とを記憶しており、前記クラスタへのノードの追加や離脱が発生した際に、前記クラスタを構成するノード識別子を更新し、前記ノード管理情報に記憶するステップと、前記死活監視情報に基づき、指定されたノードと死活監視信号をやり取りして、前記クラスタを構成するノードの障害を検出するステップと、アルゴリズムが完結するまでの一連の流れでのみ１つの提案で合意が取れることを保証する多数決プロトコルであるPaxosアルゴリズムを適用して、Master Leaseで用いるリース期間が途切れないようにリース期間更新間隔を設定して、自身の提案しか通らないように特権ノードである権利期間を確保し、かつ、Proposerが前記Paxosアルゴリズムの一連の流れが完結する前に連続して提案できる回数を２回以上とすることにより、自身が前記ノード管理情報を更新できる前記特権ノードであることを提案し合意を得るとともに、ノード離脱情報を受信し、自身が特権ノードか否かを判定し、自身が特権ノードでない場合に、前記特権ノードのリース期間中が経過したときには、前記クラスタにおいて定められた特権ノード選出の所定の条件に基づき、自身が特権ノード候補であるとするステップと、前記提案が２回以上Rejectされた場合、または自身の所属するクラスタの過半数から応答を集められなかった場合、Split-Brain Syndromeが発生したと判定するステップと、を実行することを特徴とするクラスタシステムのSplit-Brain Syndrome検出方法とした。
このようにすることで、単一障害点（ＳＰＯＦ）を作らないためにクラスタを構成するノード管理をクラスタ内で実行する分散システムにおいて、経路障害等によりクラスタが複数クラスタに分断された場合に、Split-Brain Syndromeの発生を検出することができる。また、単一障害点となる外部のノード管理システムを利用せずにSplit-brain Syndromeを回避することができる。
さらに、リース期間経過後に特権ノード候補を選出することで、特権ノード候補を所定の条件に基づき選出することができる。
また、請求項２に記載の発明は、複数のノードにより構成されるクラスタを備え、前記クラスタを構成する複数のノードの中からノードを管理する特権を持つ特権ノードを選出するクラスタシステムであって、前記ノードは、ノード識別子が記憶されるノード管理情報と死活を監視する対象のノードをリストアップした死活監視情報とを記憶する記憶部と、前記クラスタへのノードの追加や離脱が発生した際に、前記クラスタを構成するノード識別子を更新し、前記ノード管理情報に記憶するノード管理部と、前記死活監視情報に基づき、指定されたノードと死活監視信号をやり取りして、前記クラスタを構成するノードの障害を検出する死活監視部と、アルゴリズムが完結するまでの一連の流れでのみ１つの提案で合意が取れることを保証する多数決プロトコルであるPaxosアルゴリズムを適用して、Master Leaseで用いるリース期間が途切れないようにリース期間更新間隔を設定して、自身の提案しか通らないように特権ノードである権利期間を確保し、かつ、Proposerが前記Paxosアルゴリズムの一連の流れが完結する前に連続して提案できる回数を２回以上とすることにより、自身が前記ノード管理情報を更新できる前記特権ノードであることを提案し合意を得るとともに、前記死活監視部からノード離脱情報を受信し、自身が特権ノードか否かを判定し、自身が特権ノードでない場合に、前記特権ノードのリース期間中が経過したときには、前記クラスタにおいて定められた特権ノード選出の所定の条件に基づき、自身が特権ノード候補であるとする、特権ノード選出部と、前記提案が２回以上Rejectされた場合、または自身の所属するクラスタの過半数から応答を集められなかった場合、Split-Brain Syndromeが発生したと判定するクラスタ離脱指示部と、を備えることを特徴とする。
また、請求項６に記載の発明は、複数のノードにより構成されるクラスタを備え、前記クラスタを構成する複数のノードの中からノードを管理する特権を持つ特権ノードを選出するクラスタシステムのSplit-Brain Syndrome検出方法であって、前記ノードは、ノード識別子が記憶されるノード管理情報と死活を監視する対象のノードをリストアップした死活監視情報とを記憶しており、前記クラスタへのノードの追加や離脱が発生した際に、前記クラスタを構成するノード識別子を更新し、前記ノード管理情報に記憶するステップと、前記死活監視情報に基づき、指定されたノードと死活監視信号をやり取りして、前記クラスタを構成するノードの障害を検出するステップと、アルゴリズムが完結するまでの一連の流れでのみ１つの提案で合意が取れることを保証する多数決プロトコルであるPaxosアルゴリズムを適用して、Master Leaseで用いるリース期間が途切れないようにリース期間更新間隔を設定して、自身の提案しか通らないように特権ノードである権利期間を確保し、かつ、Proposerが前記Paxosアルゴリズムの一連の流れが完結する前に連続して提案できる回数を２回以上とすることにより、自身が前記ノード管理情報を更新できる前記特権ノードであることを提案し合意を得るとともに、ノード離脱情報を受信し、自身が特権ノードか否かを判定し、自身が特権ノードでない場合に、前記特権ノードのリース期間中が経過したときには、前記クラスタにおいて定められた特権ノード選出の所定の条件に基づき、自身が特権ノード候補であるとするステップと、前記提案が２回以上Rejectされた場合、または自身の所属するクラスタの過半数から応答を集められなかった場合、Split-Brain Syndromeが発生したと判定するステップと、を実行することを特徴とするクラスタシステムのSplit-Brain Syndrome検出方法とした。
このようにすることで、単一障害点（ＳＰＯＦ）を作らないためにクラスタを構成するノード管理をクラスタ内で実行する分散システムにおいて、経路障害等によりクラスタが複数クラスタに分断された場合に、Split-Brain Syndromeの発生を検出することができる。また、単一障害点となる外部のノード管理システムを利用せずにSplit-brain Syndromeを回避することができる。
さらに、リース期間経過後に特権ノード候補を選出することで、特権ノード候補を所定の条件に基づき選出することができる。
また、請求項３に記載の発明は、前記クラスタ離脱指示部は、前記提案が２回以上Rejectされた場合、または自身の所属するクラスタの過半数から応答を集められなかった場合、自身の所属するクラスタの各ノードに対し、前記クラスタからの離脱指示を行い、前記クラスタからの離脱指示を受け取ったノードは当該クラスタから離脱することで、Split-Brain Syndromeを解消させることを特徴とする。
このような構成によれば、Split-Brain Syndromeの発生を検出した場合、自身および離脱指示を受け取ったノードは該当クラスタから離脱することができ、Split-Brain Syndromeを解消することができる。
また、請求項４に記載の発明は、前記特権ノード選出部が、前記特権ノードであることを提案し合意を得る処理において、前記提案の回数をカウントしており、前記提案の提案者を選定するためのPrepareリクエストを、前記特権ノード以外の自身の所属するクラスタのノードを示すAcceptorそれぞれに送信し、過半数の前記AcceptorからPromise応答を受信し、かつ、Rejectを受信していない場合、前記提案の提案内容に合意を得るためのAcceptリクエストを前記Acceptorそれぞれに送信し、過半数の前記AcceptorからＡＣＫ応答を受信し、かつ、Rejectを受信していない場合、前記Paxosアルゴリズムの一連の流れが完結したと判定し、前記ノード管理情報の更新を行うとともに、前記Acceptorそれぞれへの更新情報の配信を行う、一方、前記Prepareリクエストの送信後、所定時間経過またはRejectを受信した場合、若しくは、前記Acceptリクエストの送信後、所定時間経過またはRejectを受信した場合において、前記提案の回数が１回のときは、前記Paxosアルゴリズムの一連の流れが完結していないと判定して所定提案間隔待機し、前記Prepareリクエストから再度処理を実行し、前記Prepareリクエストの送信後、前記所定時間経過またはRejectを受信した場合、若しくは、前記Acceptリクエストの送信後、前記所定時間経過またはRejectを受信した場合において、前記提案の回数が２回以上のときは、前記Paxosアルゴリズムの一連の流れが完結したと判定し、前記クラスタ離脱指示部は、前記特権ノード選出部が、前記所定時間経過またはRejectを受信した場合に、前記提案の回数が２回以上であるとしたときに、前記Split-Brain Syndromeが発生したと判定することを特徴とする。
このような構成によれば、提案の回数が１回のときは、Paxosアルゴリズムの一連の流れは完結していないと判定し、所定提案間隔待機してPrepareリクエストから再度処理を実行し、提案の回数が２回以上のときは、所定時間経過またはRejectを受信した場合に、Paxosアルゴリズムの一連の流れが完結したと判定することで、Split-Brain Syndromeの発生を検出することができる。
本発明によれば、経路障害等によりクラスタが複数クラスタに分断された場合に、Split-Brain Syndromeの発生を検出し解消することができる。
以下、図面を参照して本発明を実施するための形態（以下、「本実施形態」という）におけるクラスタシステム等について説明する。
（本実施形態の概要）
本発明は、分散システムにおいて、特権ノードを選出するためにPaxosアルゴリズム（非特許文献１参照）を導入し、そのPaxosアルゴリズムに対し、Master Lease（非特許文献２参照）を適用し、さらに独自にパラメータ（特に提案回数、提案間隔）を設定する。これにより、経路障害等によりクラスタが複数クラスタに分断された場合であっても、自身がノード管理テーブルを更新できる特権ノードであることを提案し合意を得ることができる。つまり、Split-Brain Syndromeの発生を検出し解消することができる。
（本実施形態の概要）
本発明は、分散システムにおいて、特権ノードを選出するためにPaxosアルゴリズム（非特許文献１参照）を導入し、そのPaxosアルゴリズムに対し、Master Lease（非特許文献２参照）を適用し、さらに独自にパラメータ（特に提案回数、提案間隔）を設定する。これにより、経路障害等によりクラスタが複数クラスタに分断された場合であっても、自身がノード管理テーブルを更新できる特権ノードであることを提案し合意を得ることができる。つまり、Split-Brain Syndromeの発生を検出し解消することができる。
（実施形態）
[分散システムの構成]
図１は、本実施形態に係るクラスタを含む分散システムの構成例を示す図である。
図１に示すように、分散システム１００は、クラスタ１０を構成する複数のノード１と、ネットワーク２０と、各クライアント３０とを含んで構成される。
ノード１は、クラスタ１０を構成する、コンピュータ等の物理装置である。また、ノード１は、仮想マシン等の論理装置であってもよい。なお、図１では、ノード１は、物理サーバイメージで表している。ノード１は、クライアント３０から送信されるメッセージを受信して処理を実行し、クライアント３０に応答情報（サービス情報）を返信することによって、サービスを提供する機能を有する。
[分散システムの構成]
図１は、本実施形態に係るクラスタを含む分散システムの構成例を示す図である。
図１に示すように、分散システム１００は、クラスタ１０を構成する複数のノード１と、ネットワーク２０と、各クライアント３０とを含んで構成される。
ノード１は、クラスタ１０を構成する、コンピュータ等の物理装置である。また、ノード１は、仮想マシン等の論理装置であってもよい。なお、図１では、ノード１は、物理サーバイメージで表している。ノード１は、クライアント３０から送信されるメッセージを受信して処理を実行し、クライアント３０に応答情報（サービス情報）を返信することによって、サービスを提供する機能を有する。
クラスタ１０を構成するノード１が連携して動作を行うために、ノード１間で一貫性が必要とされるデータ（管理情報）に基づいて、各ノード１がデータの処理および保持を行っている。例えば、一貫性が必要とされるデータ（管理情報）には、クラスタ１０を構成するノード１群の情報等がある。具体的には、一貫性が必要とされるデータ（管理情報）には、ノード識別子が記憶されるノード管理テーブル（後記）や、死活を監視（alive monitoring）する対象のノードをリストアップした死活監視テーブル（後記）がある。
クライアント３０は、ユーザがネットワークサービスを享受するために、サービスへのメッセージ（入力情報等）をクラスタ１０に送信したり、クラスタ１０から当該メッセージに対応する応報情報（サービス情報）を受信して表示したりする機能を有する。クライアント３０は、不図示の入出力部、制御部、記憶部等を持っている。
クライアント３０からのメッセージは、ネットワーク２０を介してクラスタ１０を構成する何れかのノード１に送信される。各ノード１は、メッセージ処理を行い、クライアント３０にサービスを提供する。
なお、クライアント３０からノード１へ直接メッセージを送信せず、クライアント３０とノード１の間にロードバランサ等を設置してメッセージをノード１に振り分けてもよい。このロードバランサ（不図示）は、クライアント３０から送信されるメッセージを、単純なラウンドロビン法等により振り分ける機能を有する。
クライアント３０からのメッセージは、ネットワーク２０を介してクラスタ１０を構成する何れかのノード１に送信される。各ノード１は、メッセージ処理を行い、クライアント３０にサービスを提供する。
なお、クライアント３０からノード１へ直接メッセージを送信せず、クライアント３０とノード１の間にロードバランサ等を設置してメッセージをノード１に振り分けてもよい。このロードバランサ（不図示）は、クライアント３０から送信されるメッセージを、単純なラウンドロビン法等により振り分ける機能を有する。
[ノード]
次に、ノード１の機能例について、図２を用いて説明する（適宜、図１参照）。
図２は、ノード１の機能例を示す図である。
図２に示すように、ノード１は、処理部１１、記憶部１２および通信部１３を備える。
処理部１１は、図示しないＣＰＵ（Central Processing Unit）およびメインメモリで構成され、記憶部１２に記憶されているプログラムをメインメモリに展開して、ノード管理部１１１、メッセージ処理部１１２、死活監視部１１３、特権ノード選出部１１４、およびクラスタ離脱指示部１１５を機能として実現する。
記憶部１２は、メモリやハードディスク等で構成され、ノード管理テーブル（ノード管理情報）１２１、死活監視テーブル（死活監視情報）１２２およびデータ記憶部１２３を有する。データ記憶部１２３は、ノード１が管理するデータ等、およびPaxosアルゴリズムの提案番号ｂ，提案内容Ｖを記憶する。
通信部１３は、メッセージや応答情報を送受信するための通信インタフェースである。
次に、ノード１の機能例について、図２を用いて説明する（適宜、図１参照）。
図２は、ノード１の機能例を示す図である。
図２に示すように、ノード１は、処理部１１、記憶部１２および通信部１３を備える。
処理部１１は、図示しないＣＰＵ（Central Processing Unit）およびメインメモリで構成され、記憶部１２に記憶されているプログラムをメインメモリに展開して、ノード管理部１１１、メッセージ処理部１１２、死活監視部１１３、特権ノード選出部１１４、およびクラスタ離脱指示部１１５を機能として実現する。
記憶部１２は、メモリやハードディスク等で構成され、ノード管理テーブル（ノード管理情報）１２１、死活監視テーブル（死活監視情報）１２２およびデータ記憶部１２３を有する。データ記憶部１２３は、ノード１が管理するデータ等、およびPaxosアルゴリズムの提案番号ｂ，提案内容Ｖを記憶する。
通信部１３は、メッセージや応答情報を送受信するための通信インタフェースである。
<ノード管理部１１１>
ノード管理部１１１は、クラスタ１０へのノード１の追加や離脱が発生した際に、クラスタ１０を構成するノード１の情報を更新し、ノード管理テーブル１２１として管理する。ここで、「ノードの情報の更新」とは、自身が特権ノードの場合には、死活監視部１１３から通知されるノード１の障害情報（後述）や追加ノード１からのノード参加情報等に基づき、ノード管理テーブル１２１（図３参照）を更新し、その情報を残りの全ノード１に配信することを指す。また、自身が特権ノード以外のノード１の場合には、特権ノードから配信されるノード１の更新情報をノード管理テーブル１２１に反映することを指す。
ノード情報には、各ノード１の少なくともクラスタ１０を構成するノード１を一意に識別するもの（例えば、クラスタ１０を構成するノード１が同一サブネット内であればＩＰ（Internet Protocol）アドレス）と必要に応じて付属情報（例えば、クラスタ参加時刻等）が含まれる。
ノード管理部１１１は、クラスタ１０へのノード１の追加や離脱が発生した際に、クラスタ１０を構成するノード１の情報を更新し、ノード管理テーブル１２１として管理する。ここで、「ノードの情報の更新」とは、自身が特権ノードの場合には、死活監視部１１３から通知されるノード１の障害情報（後述）や追加ノード１からのノード参加情報等に基づき、ノード管理テーブル１２１（図３参照）を更新し、その情報を残りの全ノード１に配信することを指す。また、自身が特権ノード以外のノード１の場合には、特権ノードから配信されるノード１の更新情報をノード管理テーブル１２１に反映することを指す。
ノード情報には、各ノード１の少なくともクラスタ１０を構成するノード１を一意に識別するもの（例えば、クラスタ１０を構成するノード１が同一サブネット内であればＩＰ（Internet Protocol）アドレス）と必要に応じて付属情報（例えば、クラスタ参加時刻等）が含まれる。
<ノード管理テーブル１２１>
次に、ノード管理テーブル１２１の一例について、図３を用いて説明する（適宜、図２参照）。
図３は、ノード管理テーブル１２１の一例を示す図である。
ノード管理テーブル１２１は、記憶部１２に記憶され、ＩＰアドレス（ノード識別子）１３１および必要に応じて付属情報としてクラスタ参加時刻１３２を関連付けて記憶している。
ＩＰアドレス１３１は、ノード１を識別するように付与されるものであって、例えばコンシステントハッシュ（Consistent Hashing）法の管理（振り分け）手法で用いるＩＤ空間のＩＤまたは仮想ＩＤと一意に対応しているものであってもよい。
クラスタ参加時刻１３２は、ノード１のクラスタ参加時刻を記憶する。
次に、ノード管理テーブル１２１の一例について、図３を用いて説明する（適宜、図２参照）。
図３は、ノード管理テーブル１２１の一例を示す図である。
ノード管理テーブル１２１は、記憶部１２に記憶され、ＩＰアドレス（ノード識別子）１３１および必要に応じて付属情報としてクラスタ参加時刻１３２を関連付けて記憶している。
ＩＰアドレス１３１は、ノード１を識別するように付与されるものであって、例えばコンシステントハッシュ（Consistent Hashing）法の管理（振り分け）手法で用いるＩＤ空間のＩＤまたは仮想ＩＤと一意に対応しているものであってもよい。
クラスタ参加時刻１３２は、ノード１のクラスタ参加時刻を記憶する。
<メッセージ処理部１１２>
図２に戻って、メッセージ処理部１１２は、受信したメッセージの処理を実行し処理結果をクライアントに返すことにより、サービスを提供する。この時、上述の例で示したように他のノード１に複製データを配置するようなシステムでは、ノード管理テーブル１２１を参照して事前に設定された規則（例えば、ノード管理テーブル１２１の自身の下の行のノード）に基づき複製先を特定し、データの複製を配置するような協調動作を行うこともある。
図２に戻って、メッセージ処理部１１２は、受信したメッセージの処理を実行し処理結果をクライアントに返すことにより、サービスを提供する。この時、上述の例で示したように他のノード１に複製データを配置するようなシステムでは、ノード管理テーブル１２１を参照して事前に設定された規則（例えば、ノード管理テーブル１２１の自身の下の行のノード）に基づき複製先を特定し、データの複製を配置するような協調動作を行うこともある。
<死活監視部１１３>
死活監視部１１３は、死活監視テーブル１２２を参照して、指定されたノード（例えば、自身の次の行のノード）と常に死活監視信号のやり取りを行い、クラスタ１０を構成するノード１の障害を検出する。ノード１の障害を検出した場合、死活監視部１１３は、自身が特権ノードの場合はノード管理部１１１に、自身が特権ノード以外の場合には特権ノードに通知を行う。死活監視部１１３は、クラスタ１０を構成するノード１の追加や離脱があった場合、ノード管理テーブル１２１の更新に同期して死活監視テーブル１２２を更新する。
死活監視部１１３は、死活監視テーブル１２２を参照して、指定されたノード（例えば、自身の次の行のノード）と常に死活監視信号のやり取りを行い、クラスタ１０を構成するノード１の障害を検出する。ノード１の障害を検出した場合、死活監視部１１３は、自身が特権ノードの場合はノード管理部１１１に、自身が特権ノード以外の場合には特権ノードに通知を行う。死活監視部１１３は、クラスタ１０を構成するノード１の追加や離脱があった場合、ノード管理テーブル１２１の更新に同期して死活監視テーブル１２２を更新する。
<特権ノード選出部１１４>
特権ノード選出部１１４は、アルゴリズムが完結するまでの一連の流れでのみ１つの提案で合意が取れることを保証する多数決プロトコルであるPaxosアルゴリズムを適用して、Master Leaseで用いるリース期間Ｔが途切れないようにリース期間更新間隔を設定して、自身の提案しか通らないように特権ノードである権利期間を確保して特権ノードを選出する。また、特権ノード選出部１１４は、PaxosアルゴリズムにおけるProposerがPaxosアルゴリズムの一連の流れが完結する前に連続して提案できる回数を２回以上とする。
特権ノード選出部１１４は、アルゴリズムが完結するまでの一連の流れでのみ１つの提案で合意が取れることを保証する多数決プロトコルであるPaxosアルゴリズムを適用して、Master Leaseで用いるリース期間Ｔが途切れないようにリース期間更新間隔を設定して、自身の提案しか通らないように特権ノードである権利期間を確保して特権ノードを選出する。また、特権ノード選出部１１４は、PaxosアルゴリズムにおけるProposerがPaxosアルゴリズムの一連の流れが完結する前に連続して提案できる回数を２回以上とする。
特権ノード選出部１１４は、死活監視部１１３と連動して、すなわち、死活監視部１１３からのトリガにより連動して起動する。特権ノード選出部１１４は、死活監視部１１３によりあるメンバ（ノード）に障害が発生していることが分かったらその段階で動作を開始することになる。特権ノード選出部１１４は、ノード管理テーブル１２１を更新するために、一回Paxosアルゴリズムを実行するので、この段階で死活監視部１１３により発見（検出）された情報と連動させる。なお、特権ノード選出部１１４は、死活監視部１１３と連動して動くものであればよく、死活監視部１１３に含まれる構成でもよい。
<死活監視テーブル１２２>
次に、死活監視テーブル１２２の設定例について、図４を用いて説明する。
図４は、死活監視テーブル１２２の設定例を示す図である。
死活監視テーブル１２２は、１台の物理装置を単位として作成され、監視対象のノードをリストアップしたものである。死活監視テーブル１２２は、監視対象のノードのＩＰアドレスを記憶している。
死活監視テーブル１２２は、論理装置単位でノードが構成されるパターンを考慮して、物理メンバ単位に少なくとも１回選択されるようにする。すなわち、物理メンバ単位に少なくとも１回は選択されることで、死活監視がされていないメンバ（ノード）は存在しないようにしている。
次に、死活監視テーブル１２２の設定例について、図４を用いて説明する。
図４は、死活監視テーブル１２２の設定例を示す図である。
死活監視テーブル１２２は、１台の物理装置を単位として作成され、監視対象のノードをリストアップしたものである。死活監視テーブル１２２は、監視対象のノードのＩＰアドレスを記憶している。
死活監視テーブル１２２は、論理装置単位でノードが構成されるパターンを考慮して、物理メンバ単位に少なくとも１回選択されるようにする。すなわち、物理メンバ単位に少なくとも１回は選択されることで、死活監視がされていないメンバ（ノード）は存在しないようにしている。
また、死活監視テーブル１２２は、クラスタ１０（図１参照）を構成するノード１の追加や離脱があった場合、ノード管理テーブル１２１と同期的に更新されるものとする。ここで、例えば、ノード管理テーブル１２１には登録されているが死活監視テーブル１２２には登録されていないメンバ（ノード）があると、当該ノードは監視されないことになる。この状態を避けるため、ノード等の変更によりノード管理テーブル１２１が更新されると、必ず死活監視テーブル１２２についても更新されるように同期をとっている。
なお、ノード管理テーブル１２１と死活監視テーブル１２２とは、異なるものを用いてもよい場合がある。例えば、１台のサーバに対して仮想的にいくつものＩＤがあるような場合には、同じノードに対して複数のノードから監視を行うことになるので、この場合には物理ノードだけを抜き出したような死活監視テーブル１２２を用意しておくことが好ましい。
<クラスタ離脱指示部１１５>
クラスタ離脱指示部１１５は、２回連続で提案がRejectされた場合、または過半数から応答を集められなかった場合、Split-Brain Syndromeが発生したと判定する。
クラスタ離脱指示部１１５は、２回連続で自身が特権ノードである旨の提案がRejectされた場合、または過半数から応答を集められなかった場合、自身の所属するクラスタ１０の全ノードに対し、クラスタ１０からの離脱指示を行い、クラスタ１０からの離脱指示を受け取ったノードは当該クラスタ１０から離脱することで、Split-Brain Syndromeを解消させる。なお、上記において、分断した他方のクラスタには指示が届かないため、あくまでも分断した一クラスタに対する離脱指示である。
また、クラスタ離脱指示部１１５は、Split-Brain Syndromeの発生を検出した場合、Split-brain Syndrome発生したことを示す警報情報をアラームとして出力するものでもよい。この警報情報により、Split-Brain Syndromeの発生を管理者に気付かせることができる。
クラスタ離脱指示部１１５は、２回連続で提案がRejectされた場合、または過半数から応答を集められなかった場合、Split-Brain Syndromeが発生したと判定する。
クラスタ離脱指示部１１５は、２回連続で自身が特権ノードである旨の提案がRejectされた場合、または過半数から応答を集められなかった場合、自身の所属するクラスタ１０の全ノードに対し、クラスタ１０からの離脱指示を行い、クラスタ１０からの離脱指示を受け取ったノードは当該クラスタ１０から離脱することで、Split-Brain Syndromeを解消させる。なお、上記において、分断した他方のクラスタには指示が届かないため、あくまでも分断した一クラスタに対する離脱指示である。
また、クラスタ離脱指示部１１５は、Split-Brain Syndromeの発生を検出した場合、Split-brain Syndrome発生したことを示す警報情報をアラームとして出力するものでもよい。この警報情報により、Split-Brain Syndromeの発生を管理者に気付かせることができる。
<特権ノード>
特権ノードは、所定の規則に則り、一意に決定される。具体的には、特権ノードは、ノード管理テーブル１２１または死活監視テーブル１２２内の一番上の行のノードから順に、若しくはクラスタ参加時刻が最も古いノードから順にといった規則に従い、一意に決定される。同様に、次に特権ノードとなるノード候補についても、上記所定の規則に則り、一意に決定される。
特権ノードは、所定の規則に則り、一意に決定される。具体的には、特権ノードは、ノード管理テーブル１２１または死活監視テーブル１２２内の一番上の行のノードから順に、若しくはクラスタ参加時刻が最も古いノードから順にといった規則に従い、一意に決定される。同様に、次に特権ノードとなるノード候補についても、上記所定の規則に則り、一意に決定される。
例えば、特権ノードに障害が発生した際には、テーブル内の二行目のノード、または、クラスタ参加時刻が二番目に古いノード、というように次の候補が新しい特権ノードとなる権利を持つ。全メンバ（ノード）は、同一の死活監視テーブル１２２やノード管理テーブル１２１を持つため、次の特権メンバ候補は一意に特定することができる。
以下、上述のように構成されたクラスタシステムの原理説明と動作について説明する。
（原理説明）
本発明の特徴については、以下の通りである。
本発明は、クラスタシステムにおいて、Split-Brain Syndrome（ノードの障害等によりシステムが分断され、クラスタが複数に分断したまま、双方が動作し続ける状況）を検出する方法を提供する。
（原理説明）
本発明の特徴については、以下の通りである。
本発明は、クラスタシステムにおいて、Split-Brain Syndrome（ノードの障害等によりシステムが分断され、クラスタが複数に分断したまま、双方が動作し続ける状況）を検出する方法を提供する。
（１）クラスタごとに１台、特権ノード（代表ノード）を存在させ、いずれかのノードの離脱を契機に特権ノードを再選出するPaxosアルゴリズム（非特許文献１参照）を導入する。
（２）そのPaxosアルゴリズム中の第１フェーズのリクエスト権に、Master Lease（非特許文献２参照）を適用し、さらに独自にパラメータ（特に提案回数、提案間隔）を設定することにより、同時に１台のノードしか特権ノードとして動作する権利を提案させないようにする（詳細は後記）。以降、本方式または本Paxosアルゴリズムと呼ぶ。
（３）本Paxosアルゴリズムにおける提案回数を２回以上とし、２回連続で提案が拒否された場合、または過半数から応答を集められなかった場合、Split-Brain Syndromeが発生していたと判定する。
本Paxosアルゴリズムを実行するため、本実施形態では、ノード１のデータ記憶部１２３（図２参照）に、Paxosアルゴリズムの提案番号ｂ，提案内容Ｖを記憶している。
本Paxosアルゴリズムを実行するため、本実施形態では、ノード１のデータ記憶部１２３（図２参照）に、Paxosアルゴリズムの提案番号ｂ，提案内容Ｖを記憶している。
（４）特権ノード選出の動作
特権ノード選出の動作は、ノードが離脱したことの察知、すなわち、あるノードがノード離脱情報を受信することから開始する。ノード離脱情報を受信するのは、すべてのノードではなく、特権ノードまたは特権ノードが離脱した場合には、次に特権ノードとなるノード候補である。
特権ノードのノード離脱を検出したノードまたはあるノードの離脱を検出し特権ノードにノード離脱情報を送付したが失敗したノードは、次に特権ノードとなるノード候補にノード離脱情報を送付する。この場合、数回のリトライ等、ある規則に従い送付先を変更することができる。
特権ノード選出の動作は、ノードが離脱したことの察知、すなわち、あるノードがノード離脱情報を受信することから開始する。ノード離脱情報を受信するのは、すべてのノードではなく、特権ノードまたは特権ノードが離脱した場合には、次に特権ノードとなるノード候補である。
特権ノードのノード離脱を検出したノードまたはあるノードの離脱を検出し特権ノードにノード離脱情報を送付したが失敗したノードは、次に特権ノードとなるノード候補にノード離脱情報を送付する。この場合、数回のリトライ等、ある規則に従い送付先を変更することができる。
（Split-Brain Syndrome発生検出方法）
次に、Split-Brain Syndromeを検出し解消する機能について述べる。まず、Split-brain Syndromeの発生について述べ、次いで一般的なPaxosアルゴリズムおよびMaster Leaseについて説明し、最後に本方式について説明する。
次に、Split-Brain Syndromeを検出し解消する機能について述べる。まず、Split-brain Syndromeの発生について述べ、次いで一般的なPaxosアルゴリズムおよびMaster Leaseについて説明し、最後に本方式について説明する。
[Split-brain Syndromeの発生]
前記図９に示すように、経路障害等で１つのクラスタが複数のクラスタに分断されると、各クラスタ内で他方のクラスタのノードからの死活監視信号の応答がなくなる。そして、特権ノードの存在しない（特権ノードと分断された）クラスタでは新たな特権ノードが選出され、双方のクラスタで特権ノードがノード管理テーブル１２１の更新を行うことでSplit-Brain Syndrineとなる場合が考えられる。
前記図９に示すように、経路障害等で１つのクラスタが複数のクラスタに分断されると、各クラスタ内で他方のクラスタのノードからの死活監視信号の応答がなくなる。そして、特権ノードの存在しない（特権ノードと分断された）クラスタでは新たな特権ノードが選出され、双方のクラスタで特権ノードがノード管理テーブル１２１の更新を行うことでSplit-Brain Syndrineとなる場合が考えられる。
[Paxosアルゴリズム]
一般的に、Paxosアルゴリズム（非特許文献１参照）とは、分散環境において、信頼性の低いプロセスの集合（本実施形態における複数ノードの集合で構成されるクラスタ）が１つの値に関する合意をとるためのアルゴリズムである。Paxosアルゴリズムは、同時に半数までの障害発生の場合であれば、分散システムを構成するノード数が変動する、また各ノードの処理時間が保証できない場合でも、分散システム内で必ず１つの提案で合意が取れるまたは何も合意されない、ということを保証することが可能である。
ただし、Paxosアルゴリズムは、アルゴリズムが完結するまでの一連の流れでのみ１つの提案で合意が取れるまたは何も合意されない、ということを保証するものであり、提案が連続して合意に至るケースもある。
そのような問題を補うために、本方式では、Master Lease（後記）をあわせて利用する。またPaxosアルゴリズムとMaster Leaseに関する独自のパラメータの設定を行う。
一般的に、Paxosアルゴリズム（非特許文献１参照）とは、分散環境において、信頼性の低いプロセスの集合（本実施形態における複数ノードの集合で構成されるクラスタ）が１つの値に関する合意をとるためのアルゴリズムである。Paxosアルゴリズムは、同時に半数までの障害発生の場合であれば、分散システムを構成するノード数が変動する、また各ノードの処理時間が保証できない場合でも、分散システム内で必ず１つの提案で合意が取れるまたは何も合意されない、ということを保証することが可能である。
ただし、Paxosアルゴリズムは、アルゴリズムが完結するまでの一連の流れでのみ１つの提案で合意が取れるまたは何も合意されない、ということを保証するものであり、提案が連続して合意に至るケースもある。
そのような問題を補うために、本方式では、Master Lease（後記）をあわせて利用する。またPaxosアルゴリズムとMaster Leaseに関する独自のパラメータの設定を行う。
[Master Lease]
Master Lease（非特許文献２参照）は、所定のリース期間Ｔを設定するものである。ここではMaster Leaseは、特権ノードである権利（本実施形態では、ノード管理テーブル１２１を更新する権利、またPaxosにおける提案を行う権利）を一定期間確保する。
Master Lease（非特許文献２参照）は、所定のリース期間Ｔを設定するものである。ここではMaster Leaseは、特権ノードである権利（本実施形態では、ノード管理テーブル１２１を更新する権利、またPaxosにおける提案を行う権利）を一定期間確保する。
[本方式]
本方式は、Paxosアルゴリズムを適用する場合において、第一フェーズのリクエストを行う権利があるかどうかを判断する方法として、MasterLeaseのリース期間中かどうかを利用し、さらに独自にパラメータ（特に提案回数、提案間隔）を設定することにより、同時に１台のノードしか特権ノードを提案させないようにする。
本方式は、Paxosアルゴリズムを適用する場合において、第一フェーズのリクエストを行う権利があるかどうかを判断する方法として、MasterLeaseのリース期間中かどうかを利用し、さらに独自にパラメータ（特に提案回数、提案間隔）を設定することにより、同時に１台のノードしか特権ノードを提案させないようにする。
本方式で用いるMaster Leaseは、特権を持っているノードが他のノードに対して、ある時間は自身が特権ノードであることを保障させる。換言すれば、本方式で用いるMaster Leaseは、特権ノードの期間が切れるまでは、他のノードは自分が提案を始めることをしないことを保障させる。このように本方式は、Paxosアルゴリズムに、Master Leaseを導入し、特権ノードである権利（ノード管理テーブル１２１を更新する権利、またPaxosにおける提案を行う権利）を一定時間確保し、その時間を更新していくことで、特権ノードである権利期間が途切れないように更新を掛け続ける。
また、本方式は、本Paxosアルゴリズムにおける提案回数を２回以上とし、２回連続で提案が拒否された場合、または過半数から応答を集められなかった場合、Split-Brain Syndromeが発生していたと判定する。
本実施形態では、「Split-Brain Syndromeの発生の可能性の検出」を、「Split-Brain Syndromeの検出」と呼んでいる。本実施形態によれば、Split-Brain Syndromeが発生していれば、Split-Brain Syndrome発生を必ず検出できる。しかし、Split-Brain Syndromeの発生の可能性がある場合（実際にはSplit-Brain Syndromeが発生していない場合も含む）であってもSplit-Brain Syndromeの検出と判定する。具体例として、データセンタ単位での障害などにより、過半数のサーバが同時に障害で離脱した場合や、３つ以上のクラスタに分断し、全てのクラスタが元のノード数の過半数を満たさないケースが挙げられる。このように、Split-Brain Syndrome発生の可能性のある場合についても、Split-Brain Syndrome発生の検出と判定することで、Split-Brain Syndrome発生をより確実に解消することができる。その結果、データの一貫性を担保してシステムの信頼性向上を図ることができる。
[本実施形態の動作説明]
本実施形態について、より詳細に説明する。本方式によれば、分散システム１００（図１参照）において、経路障害等に起因して発生するSplit-brain Syndromeの発生の可能性を検出することができる。なお、以下の一連の処理は、死活監視部１１３（図２参照。以下同様）に連動する特権ノード選出部１１４、およびクラスタ離脱指示部１１５により実現される。
本実施形態について、より詳細に説明する。本方式によれば、分散システム１００（図１参照）において、経路障害等に起因して発生するSplit-brain Syndromeの発生の可能性を検出することができる。なお、以下の一連の処理は、死活監視部１１３（図２参照。以下同様）に連動する特権ノード選出部１１４、およびクラスタ離脱指示部１１５により実現される。
本実施形態では、特権ノードとして障害発生ノードをノード管理テーブル１２１から削除する処理を実行する前に、本方式を利用して特権ノードとして動作する（すなわち、ノード管理テーブル１２１の更新を行う）権利を持つことをクラスタ内で合意することとする。特権ノードの合意とノード管理テーブル１２１の更新は大きく分けて３つのフェーズで実行される。
<第一フェーズ（Prepare phase）>
第一フェーズ（Prepare phase）は、提案内容を提案できる提案者を選定する。
第一フェーズ（Prepare phase）では、Paxosアルゴリズム（非特許文献１参照）に準拠するように、特権ノードあるいは特権ノード候補のノード（以降、Proposer（提案者：提案ノード）と呼ぶ）は、ノード１（後記図５参照）の離脱を通知された場合、残りのノード１（以降、Acceptor（受理ノード）と呼ぶ）に対して、提案番号付きのPrepareリクエストを送信する。上記残りのノードとは、ノード管理テーブル１２１に存在する全ノードであり、仮にあるノード１の離脱通知を受けたことによるノード管理テーブル１２１の更新の場合でもそのノード１を含むものである。
第一フェーズ（Prepare phase）は、提案内容を提案できる提案者を選定する。
第一フェーズ（Prepare phase）では、Paxosアルゴリズム（非特許文献１参照）に準拠するように、特権ノードあるいは特権ノード候補のノード（以降、Proposer（提案者：提案ノード）と呼ぶ）は、ノード１（後記図５参照）の離脱を通知された場合、残りのノード１（以降、Acceptor（受理ノード）と呼ぶ）に対して、提案番号付きのPrepareリクエストを送信する。上記残りのノードとは、ノード管理テーブル１２１に存在する全ノードであり、仮にあるノード１の離脱通知を受けたことによるノード管理テーブル１２１の更新の場合でもそのノード１を含むものである。
Acceptorは、受理している最大の提案番号より大きな提案番号のPrepareリクエストを受けた場合、その大きな提案番号より小さな提案番号は拒否することを約束し、Promise応答を返す。例えば、あるノード（Acceptor「Ａ」）がいままでに受理していた最大の提案番号が「５」番だった場合、それより大きな提案番号（例えば「１０」番）がくればそれより大きな提案番号を受けているので受理する。以降、「９」番以下の提案番号の提案を受けても受理しない。因みに、他のノードは、Acceptor「Ａ」が提案番号「１０」番を受理したことをAcceptor「Ａ」からのPromise応答を受けて知っているので、Acceptor「Ａ」に対し提案番号「１０」番より小さい提案番号の提案を送信することはない。
Acceptorは、小さな提案番号のPrepareリクエストを受けた場合は、Reject応答を返す。Acceptorは、Prepareリクエストを受けた時点で他の小さな提案番号ｂを持つ提案を受理し、かつPaxosアルゴリズムの一連の流れが完結していない場合、その提案番号ｂと提案内容ＶをPromise応答と共に返す。なお、第一フェーズでは、提案番号ｂのみをPromise応答と共に返すAcceptorもあり得る（提案を受けているかどうかで処理が分岐する）。
例えば、上記の例の場合において、あるAcceptor「Ａ」から提案番号「５」番を最大の提案番号として受理して、他のノードにPromise応答を返しているとする。ここで、別のメンバ（Acceptor「Ｂ」）から提案番号「８」番のPrepareリクエストを受けた場合、Acceptor「Ｂ」は、Acceptor「Ａ」からの提案番号「５」番より大きい提案番号「８」番であるため受理する。受理はするものの、Acceptor「Ｂ」は、既に受理している提案番号「５」番と提案内容ＶをPromise応答と共に返すようにする。なお、第一フェーズでは、提案は行わず、提案番号の予約をするのみとなる。
なお、一連の流れが完結していない場合とは、提案を受けている途中、すなわち以下に説明する第三フェーズ（Commit phase）に移行していない状態をいう。
なお、一連の流れが完結していない場合とは、提案を受けている途中、すなわち以下に説明する第三フェーズ（Commit phase）に移行していない状態をいう。
Proposerは、過半数のAcceptorからPromise応答を受信した場合、次のフェーズ（第二フェーズ）に進む。Proposerは、一定時間待って過半数からのPromise応答を集めることができない（タイムアウト内に過半数からのPromise応答を集めることができない）かつRejectもされない場合、またはReject応答を１つでも受け取った場合、再度提案を行う。
本方式では、あるProposerがPaxosアルゴリズムの一連の流れが完結する前に連続して提案できる回数を２回とする。なお、２回までとする理由については後述する。２回連続で提案がRejectされた場合、自身の所属するクラスタ１０（図１参照）の全ノード１に対し、クラスタ１０からの離脱指示を行い、クラスタ１０からの離脱指示を受け取ったノード１はクラスタ１０から離脱する。例えば、図９に示すように、経路障害等により複数クラスタとなっていた場合、自身の属するクラスタは全メンバが離脱するが、他方のクラスタには離脱指示が届かないため影響はない。すなわち、分断した場合に自身に属するクラスタ１０のノードだけを離脱させる（分断前の元のノードまでは離脱させない）。
ここで、離脱したノードが、復活する場合には、障害等が取り除かれた後に、新規ノードとして設定されることを前提とする。このため、離脱したノードが、不完全な状態で復活することはない。
Proposerが、過半数のノードからPromise応答を受信した場合、第二フェーズ（Vote phase）に移行する（後記図５のステップＳ３参照）。
なお、一般的に、Paxosアルゴリズムでは、新たなPaxosアルゴリズムの実行にあたり、提案しようとするノードが前回完結したPaxosアルゴリズムのProposerであった場合には、第一フェーズを省略し、後記する第二および第三フェーズのみを実行することが認められている。
Proposerが、過半数のノードからPromise応答を受信した場合、第二フェーズ（Vote phase）に移行する（後記図５のステップＳ３参照）。
なお、一般的に、Paxosアルゴリズムでは、新たなPaxosアルゴリズムの実行にあたり、提案しようとするノードが前回完結したPaxosアルゴリズムのProposerであった場合には、第一フェーズを省略し、後記する第二および第三フェーズのみを実行することが認められている。
<第二フェーズ（Vote phase）>
第二フェーズ（Vote phase）は、提案者が提案内容を提案するフェーズである。
第二フェーズ（Vote phase）では、Paxosアルゴリズム（非特許文献１参照）に準拠するように、Proposerは、過半数のAcceptorからPromise応答を受信した時点でAcceptリクエストをAcceptorに送信する。Acceptリクエストには、提案番号ｂと提案内容Ｖが含まれ、提案番号ｂは第一フェーズで利用した提案番号ｂを採用する。つまり、第二フェーズにおける提案番号ｂは、自身が第一フェーズ（Prepare phase）で提案してPromise応答を受けた提案番号である。他のAcceptorから見れば、その約束した提案番号ｂから提案が来たので第二フェーズでAcceptリクエストを受けることになる。提案内容Ｖは、第一フェーズのPromise応答内で提案番号ｂと提案内容Ｖを受理していた場合には、その中から最も大きな提案番号ｂを持つ提案を、受理していない場合は任意の内容を採用する。ここでは、提案内容Ｖとは、あるノードが特権ノードとして、ノードの離脱に伴うノード管理テーブル１２１の更新を行うという提案である。
第二フェーズ（Vote phase）は、提案者が提案内容を提案するフェーズである。
第二フェーズ（Vote phase）では、Paxosアルゴリズム（非特許文献１参照）に準拠するように、Proposerは、過半数のAcceptorからPromise応答を受信した時点でAcceptリクエストをAcceptorに送信する。Acceptリクエストには、提案番号ｂと提案内容Ｖが含まれ、提案番号ｂは第一フェーズで利用した提案番号ｂを採用する。つまり、第二フェーズにおける提案番号ｂは、自身が第一フェーズ（Prepare phase）で提案してPromise応答を受けた提案番号である。他のAcceptorから見れば、その約束した提案番号ｂから提案が来たので第二フェーズでAcceptリクエストを受けることになる。提案内容Ｖは、第一フェーズのPromise応答内で提案番号ｂと提案内容Ｖを受理していた場合には、その中から最も大きな提案番号ｂを持つ提案を、受理していない場合は任意の内容を採用する。ここでは、提案内容Ｖとは、あるノードが特権ノードとして、ノードの離脱に伴うノード管理テーブル１２１の更新を行うという提案である。
ところで、Paxosアルゴリズム（非特許文献１参照）では、Proposerは、必ず一番大きな提案番号ｂを付された提案内容Ｖを提案しなければならない。本方式では、Paxosアルゴリズム（非特許文献１参照）にMaster Leaseを導入した新規な分散合意形成アルゴリズムを用いているので、Proposerは、１つしか出現しない。しかし一般的なPaxosアルゴリズム（非特許文献１参照）では、Proposerは、同時に複数出現する可能性がある。このため、複数のProposerから同時にAcceptリクエストを受けることがあり、このような場合のため、Paxosアルゴリズム（非特許文献１参照）では、Proposerは、複数の提案の中から、自身の提案でなくても一番大きい提案番号ｂの提案を選ばなくてはならない。そのため、Proposerは、提案番号ｂと提案内容Ｖが含まれるAcceptリクエストをAcceptorに送信するようにしている。
本実施形態において、Acceptorは、提案番号ｂが第一フェーズで受理している提案番号ｂ以上の値を持つAcceptリクエストを受けた場合、その提案を受理し特権ノードあるいは特権ノード候補のノード（Paxosアルゴリズム（非特許文献１参照）ではLearnerと呼び、本方式ではProposerのノードがLearnerとしての役割を兼任している）にＡＣＫを返す。Acceptorは、提案番号ｂが第一フェーズで受理している提案番号ｂ未満の値を持つAcceptリクエストを受けた場合、Reject応答を返す。
Learner（ここではProposer）は、過半数のAcceptorからＡＣＫを受信した場合、次のフェーズ（第三フェーズ）に進む。一定時間待って過半数からのＡＣＫを集めることができない（タイムアウト内に過半数からのＡＣＫを集めることができない）かつRejectもされない場合、Proposerとして再度Prepareから開始する。Reject応答を１つでも受け取った場合もProposerとして再度提案を行う。
上記再度提案について説明する。すなわち、Proposerは、Reject応答を受け取った時点で、他のノードの中で全く別の特権ノードからの提案を受けているノードが存在することが分かる。この提案を受けている、すなわち自身からの提案を受けないという応答が来ているので、Proposerとしてもう一度最初から再度提案を行う。一般的なPaxosアルゴリズムでは、上記再度提案の回数（Paxosアルゴリズムの一連の流れが完結する前に連続して提案できる回数）に取り決めはなく何度でも再度提案は可能である。これに対して、本方式では、上記提案回数を２回以上（最適には２回）、とすることを特徴とする。
本方式では、あるProposerがPaxosアルゴリズムの一連の流れが完結する前に連続して提案できる回数を２回とする（提案回数を２回以上とする理由については、後記する）。２回連続で提案がRejectされた場合、または過半数から応答を集められなかった場合、自身の所属するクラスタの全ノードに対し、クラスタからの離脱指示を行い、クラスタからの離脱指示を受け取ったノードはクラスタから離脱する。
ここで、Proposerが、過半数のノードからＡＣＫを受信した場合、第三フェーズ（Commit phase）に移行する（後記図５のステップＳ７参照）。
ここで、Proposerが、過半数のノードからＡＣＫを受信した場合、第三フェーズ（Commit phase）に移行する（後記図５のステップＳ７参照）。
<第三フェーズ（Commit phase）>
第三フェーズ（Commit phase）は、更新情報（Commit）を通知する。
第三フェーズ（Commit phase）では、Learnerは、過半数のAcceptorからＡＣＫを受信した時点で提案が合意に至ったことを認識する。すなわち、この段階で特権ノードとしてのノード管理テーブル１２１を更新する権利を得ることとなる。そして、ノード管理テーブル１２１を更新して離脱したノードを除くAcceptorに対し、更新したノード管理テーブル１２１または更新したノードの情報を配信する。ノード管理テーブル１２１をそのまま送信すると配信負荷が大きくなるため、ノード管理テーブル１２１の送信に代えて、更新したノードの情報（差分情報）を配信するようにしてもよい。
Acceptorは、ノード管理テーブル１２１の更新情報を受信した場合、ＡＣＫを返す。
第三フェーズ（Commit phase）は、更新情報（Commit）を通知する。
第三フェーズ（Commit phase）では、Learnerは、過半数のAcceptorからＡＣＫを受信した時点で提案が合意に至ったことを認識する。すなわち、この段階で特権ノードとしてのノード管理テーブル１２１を更新する権利を得ることとなる。そして、ノード管理テーブル１２１を更新して離脱したノードを除くAcceptorに対し、更新したノード管理テーブル１２１または更新したノードの情報を配信する。ノード管理テーブル１２１をそのまま送信すると配信負荷が大きくなるため、ノード管理テーブル１２１の送信に代えて、更新したノードの情報（差分情報）を配信するようにしてもよい。
Acceptorは、ノード管理テーブル１２１の更新情報を受信した場合、ＡＣＫを返す。
[特権ノード選出の流れ]
以上で述べた特権ノード選出の流れについて、図５を参照して説明する。
図５は、本実施形態に係るクラスタシステムの特権ノード選出の流れを説明するシーケンス図である。
まず、特権ノードあるいは特権ノード候補のノード１（「Proposer」）は、ノードの離脱を通知された場合、ノード管理テーブル１２１（図２参照）に存在する全ノード１（「Acceptor」）に対して、提案番号付きのPrepareリクエストを送信する（ステップＳ１）。
以上で述べた特権ノード選出の流れについて、図５を参照して説明する。
図５は、本実施形態に係るクラスタシステムの特権ノード選出の流れを説明するシーケンス図である。
まず、特権ノードあるいは特権ノード候補のノード１（「Proposer」）は、ノードの離脱を通知された場合、ノード管理テーブル１２１（図２参照）に存在する全ノード１（「Acceptor」）に対して、提案番号付きのPrepareリクエストを送信する（ステップＳ１）。
Acceptorは、受理している最大の提案番号ｂ以上の提案番号ｂのPrepareリクエストを受けた場合、その提案番号ｂ未満の提案番号ｂは拒否することを約束し、その提案番号ｂと提案内容ＶをPromise応答と共に返す（ステップＳ２）。なお、上述したように、提案内容ＶをPromise応答と共に返すケースには、既に第二フェーズまで実行している別提案を受けていた場合がある。また、Acceptorは、受理している最大の提案番号ｂより小さな提案番号ｂのPrepareリクエストを受けた場合は、Reject応答を返す（ステップＳ２）。
以上は第一フェーズ（Prepare phase）における処理である。
以上は第一フェーズ（Prepare phase）における処理である。
次に、Proposerは、過半数のノードからPromiseが返っていることを確認する（ステップＳ３）。Proposerが、過半数のAcceptorからPromise応答を受信した場合、第二フェーズ（Vote phase）に移行する。
Proposerは、過半数のAcceptorからPromise応答を受信した時点でAcceptリクエストをAcceptorに送信する（ステップＳ４）。Acceptリクエストには、提案番号ｂと提案内容Ｖが含まれ、提案番号ｂは第一フェーズで利用した番号を採用する（Paxosアルゴリズム（非特許文献１参照）に準拠）。なお、提案内容Ｖは、第一フェーズのPromise応答内で提案番号ｂと提案内容Ｖを受理していた場合には、その中から最も大きな提案番号ｂを持つ提案を、受理していない場合は任意の内容を採用する。
Proposerは、過半数のAcceptorからPromise応答を受信した時点でAcceptリクエストをAcceptorに送信する（ステップＳ４）。Acceptリクエストには、提案番号ｂと提案内容Ｖが含まれ、提案番号ｂは第一フェーズで利用した番号を採用する（Paxosアルゴリズム（非特許文献１参照）に準拠）。なお、提案内容Ｖは、第一フェーズのPromise応答内で提案番号ｂと提案内容Ｖを受理していた場合には、その中から最も大きな提案番号ｂを持つ提案を、受理していない場合は任意の内容を採用する。
Acceptorは、提案番号ｂが第一フェーズで受理している提案番号ｂ以上の値を持つAcceptリクエストを受けた場合、その提案を受理し特権ノードあるいは特権ノード候補のノード（Proposer、ここではLearner）にＡＣＫを返す（ステップＳ５）。Acceptorは、提案番号ｂが第一フェーズで受理している提案番号ｂ未満の値を持つAcceptリクエストを受けた場合、Reject応答を返す。
次に、Proposerは、過半数のAcceptorからＡＣＫを受信した場合、第三フェーズ（Commit phase）に移行する。
ここではProposerは、Learnerとして既に動作中である（ステップＳ６）。
Proposer（ここではLearner）は、過半数のノードからＡＣＫが返っていることを確認する（ステップＳ７）。
なお、Proposer（Learner）は、一定時間待って過半数からのＡＣＫを集めることができないかつRejectもされない場合、Proposerとして再度Prepareから開始する。Reject応答を１つでも受け取った場合もProposerとして再度提案を行う。
ここではProposerは、Learnerとして既に動作中である（ステップＳ６）。
Proposer（ここではLearner）は、過半数のノードからＡＣＫが返っていることを確認する（ステップＳ７）。
なお、Proposer（Learner）は、一定時間待って過半数からのＡＣＫを集めることができないかつRejectもされない場合、Proposerとして再度Prepareから開始する。Reject応答を１つでも受け取った場合もProposerとして再度提案を行う。
ここで本方式では、あるProposerがPaxosアルゴリズムの一連の流れが完結する前に連続して提案できる回数を２回とする。２回連続で提案がRejectされた場合、または過半数から応答を集められなかった場合、自身の所属するクラスタの全ノードに対し、クラスタからの離脱指示を行い、クラスタからの離脱指示を受け取ったメンバはクラスタから離脱する。
次に、Proposer（Learner）は、過半数のAcceptorからＡＣＫを受信した時点で提案が合意に至ったことを認識する。すなわち、この段階で特権ノードとしてのノード管理テーブル１２１を更新する権利を得ることとなる。そして、ノード管理テーブル１２１を更新して離脱したノードを除くAcceptorに更新したノード管理テーブル１２１または更新したノードの情報を配信する（ステップＳ８）。
Acceptorは、ノード管理テーブル１２１の更新情報を受信した場合、ＡＣＫを返す（図示省略）。
Acceptorは、ノード管理テーブル１２１の更新情報を受信した場合、ＡＣＫを返す（図示省略）。
上記の処理により、同時に複数の特権ノードがノード管理テーブル１２１を更新することを防ぐことが可能である。すなわち、経路障害等が発生し複数のクラスタに分断した場合に、互いにノード離脱処理を行い複数クラスタのまま処理が継続することはない。例えば、１０台のサーバリソースでクラスタを構成しており、経路障害により６台、４台に分かれた場合、４台となったクラスタでは過半数メンバからのPromise応答を得ることはできないため、２回提案を行った後に４台のノードが離脱することとなり、６台構成のクラスタのみが残ることとなる。また、例えば３台、３台、４台の３つのクラスタに分かれた場合、全てのクラスタで過半数メンバからのPromise応答を得ることはできないため、２回提案を行った後に全てのノードがクラスタから離脱することとなる。この場合、一からクラスタを再構築する必要は生じるものの、データの一貫性破綻という問題は起こらない。
[論理的な分断の発生例]
次に、設定ミスやソフトウェアバグ等による論理的な分断により、一部のノードが双方のクラスタに属するように分断した論理的な分断の発生例について説明する。
図６は、論理的な分断の発生例を説明する図である。
図６に示すように、設定ミスやソフトウェアバグ等による論理的な分断により、クラスタ１０Ａを構成するノード１ａ〜１ｆと、クラスタ１０Ｂを構成するノード１ｅ〜１ｊとにシステムが分断された場合を例に採る。ノード１ｅ，１ｆは、両方のクラスタ１０Ａ，１０Ｂに論理的に属している。このような論理的な分断が発生すると、クラスタが複数に分断したまま、双方が動作し続ける状況が発生する。図６では、クラスタ１０Ａのノード１ａが既存の特権ノードを、またクラスタ１０Ｂのノード１ｊが新しい特権ノードであることを示し、それぞれ王冠印が付されている。
次に、設定ミスやソフトウェアバグ等による論理的な分断により、一部のノードが双方のクラスタに属するように分断した論理的な分断の発生例について説明する。
図６は、論理的な分断の発生例を説明する図である。
図６に示すように、設定ミスやソフトウェアバグ等による論理的な分断により、クラスタ１０Ａを構成するノード１ａ〜１ｆと、クラスタ１０Ｂを構成するノード１ｅ〜１ｊとにシステムが分断された場合を例に採る。ノード１ｅ，１ｆは、両方のクラスタ１０Ａ，１０Ｂに論理的に属している。このような論理的な分断が発生すると、クラスタが複数に分断したまま、双方が動作し続ける状況が発生する。図６では、クラスタ１０Ａのノード１ａが既存の特権ノードを、またクラスタ１０Ｂのノード１ｊが新しい特権ノードであることを示し、それぞれ王冠印が付されている。
この場合、両方のクラスタ１０Ａ，１０Ｂに属する２台のノード１ｅ，１ｆは、双方の特権ノードまたは特権ノード候補からの提案を受ける可能性がある。同時に提案が届いた場合には、Paxosアルゴリズム（非特許文献１参照）に基づき処理が進むため、同時に複数の提案が通ることはない。しかし、片方のクラスタで一連のPaxosアルゴリズムが完了（ノード管理テーブル１２１の更新までが完了）した段階で他方のクラスタでは２回のRejectがされておらず、その後他方のクラスタの特権ノードまたは特権ノード候補から提案が行われると、その提案は受理される可能性がある。
図６を参照して具体的に説明する。クラスタ１０ＡでPaxosアルゴリズム（非特許文献１参照）を実行して、Proposerの提案が通った場合、通常はクラスタ１０Ａが残り、かつクラスタ１０Ｂは潰れてほしいにもかかわらず、クラスタ１０Ａとクラスタ１０Ｂのいずれにも論理的に所属するノード１ｅ，１ｆが存在する。しかし、クラスタ１０ＡのPaxosアルゴリズム（非特許文献１参照）は終了しているので、今度はクラスタ１０ＢのPaxosアルゴリズム（非特許文献１参照）による提案を受けることになる。この場合、ノード１ｅ，１ｆは両方のクラスタ１０Ａ，１０Ｂから、両方の提案を受けることとなり、動作不能になる場合がある。
これを避けるため、本実施形態では、PaxosアルゴリズムにMaster Leaseのリース期間Ｔを適用して、上記クラスタ１０Ｂの提案が始まるタイミングを制御する。すなわち、クラスタ１０ＡでPaxosが完了していない場合においても、クラスタ１０Ｂの新特権ノードでクラスタ１０Ａ側の特権ノードのリース期間が切れればクラスタ１０Ｂ側でも提案は開始される。しかし、その間にもノード１ｅ，１ｆはクラスタ１０Ａ側の特権ノードからリース期間の更新を受けているため、クラスタ１０Ｂ側の提案には必ずRejectすることとなりシステム全体として問題が生じないことになる。このように、 Master Leaseは、提案開始タイミングの制御（他ノードのリース期間中は自身が特権メンバとはならない）と複数特権ノードからの提案を同時に受理することを防ぐ（Paxos完了からノード管理テーブル更新までの間に他の特権ノードからのPaxosを受理することを防ぐ）役割を有する。
[Master Leaseによる実装上の特徴]
Master Leaseは、特権ノードである権利（本実施形態では、ノード管理テーブル１２１を更新する権利、またPaxosにおける提案を行う権利）を一定期間確保し、その時間を更新する仕組みである。特権ノードは、一定期間（以降、リース期間Ｔと呼ぶ）自身が特権ノードとしての権利を持つことを他ノードに対して提案する。特権ノードは、リース期間Ｔが途切れることがないように、一定間隔で他ノードに対してリース期間Ｔの更新リクエストを投げる。特権ノードは、リース期間Ｔの更新リクエストを投げる前にリース期間Ｔのカウントを開始する。また、残りのノードは、それぞれリース期間Ｔの更新リクエストを受理してＡＣＫを返す前にリース期間Ｔのカウントを開始する。残りのノード（PaxosアルゴリズムのAcceptor）は、リース期間Ｔのカウント中には自身がProposerとして新たな提案を行わないこと、および他のProposerからの提案をRejectすることを保障する。換言すれば、他のProposerからの提案を通ることがなくすためにリース期間Ｔが重なり合うように更新するものである。
なお、ノード離脱処理を実施する際には、リース期間Ｔの更新とは別にPaxosアルゴリズムによる合意を得てから処理を実施する必要がある。
Master Leaseは、特権ノードである権利（本実施形態では、ノード管理テーブル１２１を更新する権利、またPaxosにおける提案を行う権利）を一定期間確保し、その時間を更新する仕組みである。特権ノードは、一定期間（以降、リース期間Ｔと呼ぶ）自身が特権ノードとしての権利を持つことを他ノードに対して提案する。特権ノードは、リース期間Ｔが途切れることがないように、一定間隔で他ノードに対してリース期間Ｔの更新リクエストを投げる。特権ノードは、リース期間Ｔの更新リクエストを投げる前にリース期間Ｔのカウントを開始する。また、残りのノードは、それぞれリース期間Ｔの更新リクエストを受理してＡＣＫを返す前にリース期間Ｔのカウントを開始する。残りのノード（PaxosアルゴリズムのAcceptor）は、リース期間Ｔのカウント中には自身がProposerとして新たな提案を行わないこと、および他のProposerからの提案をRejectすることを保障する。換言すれば、他のProposerからの提案を通ることがなくすためにリース期間Ｔが重なり合うように更新するものである。
なお、ノード離脱処理を実施する際には、リース期間Ｔの更新とは別にPaxosアルゴリズムによる合意を得てから処理を実施する必要がある。
[リース期間Ｔ獲得の流れ]
次に、リース期間Ｔを獲得するまでの流れについて、図７を参照して説明する。
図７は、本実施形態に係るクラスタシステムのリース期間Ｔを獲得するまでの流れを示すシーケンス図である。
まず、Proposerは、図７の☆印に示すようにリース期間Ｔの計時を開始し（ステップＳ１１）、図７の太実線に示すようにリース期間Ｔを計時する（ステップＳ１２）。なお、図７の☆印は、各ノード１でリース期間Ｔの計時し始めたことを表している。また、符号ｅは、各ノード１で計時されたリース期間Ｔの終了を表している。ここで、Proposerとしては、自身が提案した時点でリース期間Ｔの計時を開始しておく。Proposerは、各Acceptorよりも早くリース期間Ｔの計時を開始することで、自身のリース期間Ｔが最も早く終了することになる（図７のProposerの符号ｅ参照）。また、Proposerは、ノード管理テーブル１２１（図２参照）に存在する全ノード１（「Acceptor」）に対して、リースの更新を通知する（ステップＳ１３）。
次に、リース期間Ｔを獲得するまでの流れについて、図７を参照して説明する。
図７は、本実施形態に係るクラスタシステムのリース期間Ｔを獲得するまでの流れを示すシーケンス図である。
まず、Proposerは、図７の☆印に示すようにリース期間Ｔの計時を開始し（ステップＳ１１）、図７の太実線に示すようにリース期間Ｔを計時する（ステップＳ１２）。なお、図７の☆印は、各ノード１でリース期間Ｔの計時し始めたことを表している。また、符号ｅは、各ノード１で計時されたリース期間Ｔの終了を表している。ここで、Proposerとしては、自身が提案した時点でリース期間Ｔの計時を開始しておく。Proposerは、各Acceptorよりも早くリース期間Ｔの計時を開始することで、自身のリース期間Ｔが最も早く終了することになる（図７のProposerの符号ｅ参照）。また、Proposerは、ノード管理テーブル１２１（図２参照）に存在する全ノード１（「Acceptor」）に対して、リースの更新を通知する（ステップＳ１３）。
リース期間Ｔの更新を受信した各Acceptorは、図７の☆印に示すようにリース期間Ｔの計時を開始し（ステップＳ１４，Ｓ１６，Ｓ１８）、図７の太実線に示すようにリース期間Ｔを計時する（ステップＳ１５，Ｓ１７，Ｓ１９）。また、各Acceptorは、リース期間ＴにおいてProposerにＡＣＫを返す（ステップＳ２０）。これにより、リース期間Ｔは、自身がProposerとして提案しないこと、他のProposerから提案を受けても必ずRejectすることを約束することになる。
次に、Proposerは、過半数のノードからＡＣＫが返ったタイミング（ステップＳ２１）からリース期間Ｔの計時終了（図７の太実線参照）までが、確実に自身の提案しか通らないことをProposerが認識できる期間となる。本実施形態では、Paxosアルゴリズムに、特権ノードの権利を一定期間確保するMaster Leaseを用いることで、確実に自分の提案しか通らないことをProposerが認識できる期間が途切れないようにリース期間更新間隔を設定する。
[リース期間Ｔの適用例]
Master Leaseを利用することにより、図６のケースでは、新しい特権ノード候補（図６のクラスタ１０Ｂのノード１ｊ参照）は、既存特権ノード（図６のクラスタ１０Ａのノード１ａ参照）のリース期間Ｔがタイムアウトするまで特権ノードとしてノード管理テーブル１２１の更新処理を実行することを提案することができない。その間にも既存特権ノード（図６のクラスタ１０Ａのノード１ａ参照）は、双方のクラスタ１０Ａ，１０Ｂに組み込まれている２台のノードに対してリース期間Ｔの更新を続けるため、新しい特権ノード候補（図６のクラスタ１０Ｂのノード１ｊ参照）がリース期間Ｔのタイムアウト後に提案を実行しても受理することはない。すなわち、新しい特権ノード候補（図６のクラスタ１０Ｂのノード１ｊ参照）は、２回提案を実施した後に自身が所属するクラスタを構成するノードの離脱処理を行うこととなり、２つのクラスタ１０Ａ，１０Ｂでノード管理テーブル１２１更新処理が並行で実行されることを防ぐことが可能である。なお、２つのクラスタ１０Ａ，１０Ｂに跨がって存在する２台のノード１ｅ，１ｆは離脱をしないようにガードする。このガードは、例えば下記の動作である。図６のクラスタ１０Ａでは、ノード管理テーブル１２１の更新が実行されている（すなわちノード１ｅ，１ｆのリストに載っていない）ものとする。この場合、リストに載っていないノード（すなわちノード１ｇ，１ｈ，１ｉ，１ｊ）からの要求を拒否することでガードを行う。
Master Leaseを利用することにより、図６のケースでは、新しい特権ノード候補（図６のクラスタ１０Ｂのノード１ｊ参照）は、既存特権ノード（図６のクラスタ１０Ａのノード１ａ参照）のリース期間Ｔがタイムアウトするまで特権ノードとしてノード管理テーブル１２１の更新処理を実行することを提案することができない。その間にも既存特権ノード（図６のクラスタ１０Ａのノード１ａ参照）は、双方のクラスタ１０Ａ，１０Ｂに組み込まれている２台のノードに対してリース期間Ｔの更新を続けるため、新しい特権ノード候補（図６のクラスタ１０Ｂのノード１ｊ参照）がリース期間Ｔのタイムアウト後に提案を実行しても受理することはない。すなわち、新しい特権ノード候補（図６のクラスタ１０Ｂのノード１ｊ参照）は、２回提案を実施した後に自身が所属するクラスタを構成するノードの離脱処理を行うこととなり、２つのクラスタ１０Ａ，１０Ｂでノード管理テーブル１２１更新処理が並行で実行されることを防ぐことが可能である。なお、２つのクラスタ１０Ａ，１０Ｂに跨がって存在する２台のノード１ｅ，１ｆは離脱をしないようにガードする。このガードは、例えば下記の動作である。図６のクラスタ１０Ａでは、ノード管理テーブル１２１の更新が実行されている（すなわちノード１ｅ，１ｆのリストに載っていない）ものとする。この場合、リストに載っていないノード（すなわちノード１ｇ，１ｈ，１ｉ，１ｊ）からの要求を拒否することでガードを行う。
[PaxosアルゴリズムおよびMaster Leaseで使用する各パラメータの設定指針]
以下、PaxosアルゴリズムおよびMaster Leaseで使用する各パラメータの設定指針について述べる。
以下、PaxosアルゴリズムおよびMaster Leaseで使用する各パラメータの設定指針について述べる。
<リース期間Ｔ>
リース期間Ｔが短いと更新処理が多くなるため望ましくない。しかし、リース期間Ｔが長くても特権ノードの故障時に新しい特権ノードを選出するまでの期間が長くなる。よって、死活監視による障害検出時間とシステムのサービス条件（例えば、所定プロトコルによる信号の再送期間等）を考慮して適切な値を設定する必要がある。
リース期間Ｔが短いと更新処理が多くなるため望ましくない。しかし、リース期間Ｔが長くても特権ノードの故障時に新しい特権ノードを選出するまでの期間が長くなる。よって、死活監視による障害検出時間とシステムのサービス条件（例えば、所定プロトコルによる信号の再送期間等）を考慮して適切な値を設定する必要がある。
<リース期間更新間隔>
リース期間更新間隔は、リース期間Ｔの更新を繰り返し行う際の、その繰り返し間隔である。換言すれば、リース期間更新間隔は、リース期間Ｔの計時を開始する起点となる信号を各ノードに対して送信する間隔である。リース期間更新間隔は、過半数のノードからリース期間Ｔの更新リクエストに対するＡＣＫが返ってくる時間の期待値とリース期間Ｔを基に設定する。例えば、リース期間更新間隔は、上記期待値に所定の係数を乗じた数値を、リース期間Ｔから減算することによって設定する。すなわち、自身のリース期間Ｔが終わるまでに確実に、過半数のノードからリース期間Ｔの更新リクエストに対するＡＣＫが返ってくるようにリース期間更新間隔を設定する。
リース期間更新間隔は、リース期間Ｔの更新を繰り返し行う際の、その繰り返し間隔である。換言すれば、リース期間更新間隔は、リース期間Ｔの計時を開始する起点となる信号を各ノードに対して送信する間隔である。リース期間更新間隔は、過半数のノードからリース期間Ｔの更新リクエストに対するＡＣＫが返ってくる時間の期待値とリース期間Ｔを基に設定する。例えば、リース期間更新間隔は、上記期待値に所定の係数を乗じた数値を、リース期間Ｔから減算することによって設定する。すなわち、自身のリース期間Ｔが終わるまでに確実に、過半数のノードからリース期間Ｔの更新リクエストに対するＡＣＫが返ってくるようにリース期間更新間隔を設定する。
<最大提案回数>
最大提案回数は、２回以上（最適には２回）とする。提案回数を、２回以上とする理由について説明する。各ノードのリース期間Ｔのカウント開始タイミングはわからないため、提案回数を１回とした場合、特権ノード故障時に新しい特権ノード候補がリース期間Ｔのタイムアウトを待って提案したにも関わらず、他のメンバではリース期間Ｔが完了しておらず提案が受理されない可能性がある。したがって、最大提案回数は２回以上にしなければならない。次に、最大提案回数は２回が最適である理由について説明する。
前提として、提案回数が、２回以上であれば、Paxosアルゴリズム（非特許文献１参照）としては一連の処理として実行することができることが挙げられる。その上で、本発明者らは、最大提案回数２回が最適であることを見出した。
最大提案回数は、２回以上（最適には２回）とする。提案回数を、２回以上とする理由について説明する。各ノードのリース期間Ｔのカウント開始タイミングはわからないため、提案回数を１回とした場合、特権ノード故障時に新しい特権ノード候補がリース期間Ｔのタイムアウトを待って提案したにも関わらず、他のメンバではリース期間Ｔが完了しておらず提案が受理されない可能性がある。したがって、最大提案回数は２回以上にしなければならない。次に、最大提案回数は２回が最適である理由について説明する。
前提として、提案回数が、２回以上であれば、Paxosアルゴリズム（非特許文献１参照）としては一連の処理として実行することができることが挙げられる。その上で、本発明者らは、最大提案回数２回が最適であることを見出した。
まず、最大提案回数が１回の場合の不具合について述べる。自身が他のメンバ（ノード）のリース期間Ｔ中であるとすると、仮に特権ノードに障害が発生して、新しい特権ノードに切り替わる場合に、新しい特権ノードは提案をする。その時に、自身はリース期間Ｔが切れたので提案を投げる。しかしながら、この場合必ずしも他のメンバ（ノード）のリース期間Ｔが切れていることは保障できないので、最大提案回数１回にすると、単に特権ノードが１台故障しただけなのにシステムが全滅する虞がある。したがって、最大提案回数を２回以上にする必要がある。
また、最大提案回数を３回以上とすると、仮にネットワーク分断が発生していた場合に、ネットワーク分断が解消されて一方のクラスタが残るまでの時間が無駄に経過してしまうことになる。すなわち、最大提案回数が３回以上の場合、時間が経過するだけとなる。なお、最大提案回数を３回以上としたとしてもそれで故障が解消される保障はなく信頼性が向上するものではない。以上のことから、最大提案回数２回を最適な提案回数であるとした。
<提案間隔>
提案間隔△ｄは、一度提案が受理されなかった場合に次の提案をするまでの時間を指す。２回連続で提案が失敗する可能性を排除するためには、△ｄ＝Ｔとする。
なお、上記リース期間、リース期間更新間隔、最大提案回数、および提案間隔の各値は、システム上一意の値として、システム初期化時に各ノードの特権ノード選出部１１４に設定される。
提案間隔△ｄは、一度提案が受理されなかった場合に次の提案をするまでの時間を指す。２回連続で提案が失敗する可能性を排除するためには、△ｄ＝Ｔとする。
なお、上記リース期間、リース期間更新間隔、最大提案回数、および提案間隔の各値は、システム上一意の値として、システム初期化時に各ノードの特権ノード選出部１１４に設定される。
<提案番号>
提案番号ｂは、ｂ ｍｏｄ Ｎ＝ｋを満たす値とし、提案する度に大きな値を選択していく。なお、ｋはノード管理テーブル１２１の行数−１の値とする。また、Ｎはクラスタを構成するノード数である。新しく特権ノード候補となったノードは、既存の特権ノードがノード管理テーブル１２１の更新のために使用した提案番号ｂより大きく、ｂ ｍｏｄ Ｎ＝ｋを満たす数値の中から最少のものを選択して提案を開始する。
なお、提案番号ｂは、提案する側ノード、提案される側ノード各々のデータ記憶部１２３（図２参照）に記憶されている。
提案番号ｂは、ｂ ｍｏｄ Ｎ＝ｋを満たす値とし、提案する度に大きな値を選択していく。なお、ｋはノード管理テーブル１２１の行数−１の値とする。また、Ｎはクラスタを構成するノード数である。新しく特権ノード候補となったノードは、既存の特権ノードがノード管理テーブル１２１の更新のために使用した提案番号ｂより大きく、ｂ ｍｏｄ Ｎ＝ｋを満たす数値の中から最少のものを選択して提案を開始する。
なお、提案番号ｂは、提案する側ノード、提案される側ノード各々のデータ記憶部１２３（図２参照）に記憶されている。
[ノード離脱情報を受信してからノード管理テーブル更新、またはクラスタからの離脱までの流れ]
次に、特権ノードまたは特権ノード候補がノード離脱情報を受信してからノード管理テーブル１２１更新、またはクラスタからの離脱までの流れを、図８を参照して説明する。
次に、特権ノードまたは特権ノード候補がノード離脱情報を受信してからノード管理テーブル１２１更新、またはクラスタからの離脱までの流れを、図８を参照して説明する。
図８は、ノード離脱情報を受信してからノード管理テーブル１２１更新、またはクラスタからの離脱までの流れを示すフローチャートである。
まず、ステップＳ３１において、特権ノード選出部１１４（図２参照）は、死活監視部１１３（図２参照）からノード離脱情報を受信する。
ステップＳ３２において、特権ノード選出部１１４は、自身が特権ノードか否かを判定する。自身が特権ノードの場合には（ステップＳ３２→Ｙｅｓ）、ステップＳ３５に進む。
まず、ステップＳ３１において、特権ノード選出部１１４（図２参照）は、死活監視部１１３（図２参照）からノード離脱情報を受信する。
ステップＳ３２において、特権ノード選出部１１４は、自身が特権ノードか否かを判定する。自身が特権ノードの場合には（ステップＳ３２→Ｙｅｓ）、ステップＳ３５に進む。
自身が特権ノードでない場合（ステップＳ３２→Ｎｏ）、ステップＳ３３で特権ノード選出部１１４は、特権ノードのリース期間中か否かを判定する。特権ノードのリース期間中の場合は（ステップＳ３３→Ｙｅｓ）、ステップＳ３４で所定時間待機してステップＳ３３に戻る。上記ステップＳ３３で特権ノードのリース期間中が経過した場合には（ステップＳ３３→Ｎｏ）、特権ノード選出部１１４は、自身が特権ノード候補であると判定してステップＳ３５に進む。
ステップＳ３５において、特権ノード選出部１１４は、提案回数カウントをインクリメント（提案回数カウント＋１）する。なお、提案回数カウントの初期値は「０」である。
ステップＳ３６において、特権ノード選出部１１４は、提案番号付きのPrepareリクエストを行う。
上記ステップＳ３６までが第一フェーズ（Prepare phase）（図５参照）に対応している。
ステップＳ３６において、特権ノード選出部１１４は、提案番号付きのPrepareリクエストを行う。
上記ステップＳ３６までが第一フェーズ（Prepare phase）（図５参照）に対応している。
ステップＳ３７において、特権ノード選出部１１４は、(1)過半数ノードのPromise応答を受信したか、または(2)所定時間経過したか否かを判定する。
所定時間経過した場合（タイムアウトの場合）には（ステップＳ３７の(2)）、ステップＳ４５に進み、過半数ノードのPromise応答を受信した場合には（ステップＳ３７の(1)）、ステップＳ３８に進む。
ステップＳ３８において、特権ノード選出部１１４は、Rejectを受信したか否かを判定する。Rejectを受信した場合は（ステップＳ３８→Ｙｅｓ）、ステップＳ４５に進み、Rejectを受信していない場合は（ステップＳ３８→Ｎｏ）、ステップＳ３９に進む。
ステップＳ３９において、特権ノード選出部１１４は、AcceptリクエストをAcceptorに送信する。
所定時間経過した場合（タイムアウトの場合）には（ステップＳ３７の(2)）、ステップＳ４５に進み、過半数ノードのPromise応答を受信した場合には（ステップＳ３７の(1)）、ステップＳ３８に進む。
ステップＳ３８において、特権ノード選出部１１４は、Rejectを受信したか否かを判定する。Rejectを受信した場合は（ステップＳ３８→Ｙｅｓ）、ステップＳ４５に進み、Rejectを受信していない場合は（ステップＳ３８→Ｎｏ）、ステップＳ３９に進む。
ステップＳ３９において、特権ノード選出部１１４は、AcceptリクエストをAcceptorに送信する。
このように、特権ノードまたは特権ノード候補のノード１（図２参照）の特権ノード選出部１１４は、過半数のノードからのPromise応答を受信し（ステップＳ３７の(1)）、かつRejectを受信していない場合（ステップＳ３８→Ｎｏ）には、各ノード（Acceptor）にAcceptリクエストし（ステップＳ３９）、過半数のノード（Acceptor）からのＡＣＫを応答を待つ。
上記ステップＳ３７ないしステップＳ３９までが第二フェーズ（Vote phase）（図５参照）に対応し、ステップＳ４０以降の処理が第三フェーズ（Commit phase）（図５参照）に対応している。
上記ステップＳ３７ないしステップＳ３９までが第二フェーズ（Vote phase）（図５参照）に対応し、ステップＳ４０以降の処理が第三フェーズ（Commit phase）（図５参照）に対応している。
ステップＳ４０において、特権ノード選出部１１４は、(1)過半数ノードのＡＣＫ応答を受信したか、または(2)所定時間経過したか否かを判定する。
所定時間経過した場合には（ステップＳ４０の(2)）、ステップＳ４６に進み、過半数ノードのＡＣＫ応答を受信した場合には（ステップＳ４０の(1)）、ステップＳ４１に進む。
ステップＳ４１において、特権ノード選出部１１４は、Rejectを受信したか否かを判定する。Rejectを受信した場合は（ステップＳ４１→Ｙｅｓ）、ステップＳ４６に進み、Rejectを受信していない場合は（ステップＳ４１→Ｎｏ）、ステップＳ４２に進む。
ステップＳ４２において、特権ノード選出部１１４は、ノード情報テーブル情報の更新を行う。
ステップＳ４３において、特権ノード選出部１１４は、他ノードへの更新情報の配信を行う。そして、ステップＳ４４で特権ノード選出部１１４は、配信完了通知を受信して本フローを終了する。
所定時間経過した場合には（ステップＳ４０の(2)）、ステップＳ４６に進み、過半数ノードのＡＣＫ応答を受信した場合には（ステップＳ４０の(1)）、ステップＳ４１に進む。
ステップＳ４１において、特権ノード選出部１１４は、Rejectを受信したか否かを判定する。Rejectを受信した場合は（ステップＳ４１→Ｙｅｓ）、ステップＳ４６に進み、Rejectを受信していない場合は（ステップＳ４１→Ｎｏ）、ステップＳ４２に進む。
ステップＳ４２において、特権ノード選出部１１４は、ノード情報テーブル情報の更新を行う。
ステップＳ４３において、特権ノード選出部１１４は、他ノードへの更新情報の配信を行う。そして、ステップＳ４４で特権ノード選出部１１４は、配信完了通知を受信して本フローを終了する。
以上、ステップＳ３１ないしステップＳ４４の処理は、特権ノードまたは特権ノード候補がノード離脱情報を受信してからノード管理テーブル情報の更新（ステップＳ４２）、他ノードへの更新情報の配信（ステップＳ４３）、および配信完了通知の受信（ステップＳ４４）を行うまでの、本Paxosアルゴリズムの通常フローを表している。本実施形態では、Paxosアルゴリズムの一連の流れが完結する前に連続して提案できる最大提案回数を２回以上とし、これによりSplit-Brain Syndromeの発生の可能性を検出している。以下のステップでは、Split-Brain Syndromeの発生の検出とクラスタからの離脱までのフローを示す。
図８のフローに戻って、上記ステップＳ３７で所定時間経過した場合（タイムアウトの場合）（ステップＳ３７の(2)）、または上記ステップＳ３８でReject受信した場合は（ステップＳ３８→Ｙｅｓ）、ステップＳ４５に進む。
ステップＳ４５において、特権ノード選出部１１４は、提案回数が２回以上（提案回数≧２回）か否かを判定する。提案回数が２回以上の場合は（ステップＳ４５→Ｙｅｓ）、ステップＳ４７に進み、提案回数が２回未満の場合は（ステップＳ４５→Ｎｏ）、ステップＳ４９に進む。
また、上記ステップＳ４０で所定時間経過した場合（ステップＳ４０の(2)）、または上記ステップＳ４１でReject受信した場合は（ステップＳ４１→Ｙｅｓ）、ステップＳ４６に進む。
ステップＳ４５において、特権ノード選出部１１４は、提案回数が２回以上（提案回数≧２回）か否かを判定する。提案回数が２回以上の場合は（ステップＳ４５→Ｙｅｓ）、ステップＳ４７に進み、提案回数が２回未満の場合は（ステップＳ４５→Ｎｏ）、ステップＳ４９に進む。
また、上記ステップＳ４０で所定時間経過した場合（ステップＳ４０の(2)）、または上記ステップＳ４１でReject受信した場合は（ステップＳ４１→Ｙｅｓ）、ステップＳ４６に進む。
ステップＳ４６において、特権ノード選出部１１４は、提案回数が２回以上（提案回数≧２回）か否かを判定する。提案回数が２回以上の場合は（ステップＳ４６→Ｙｅｓ）、ステップＳ４７に進み、提案回数が２回未満の場合は（ステップＳ４６→Ｎｏ）、ステップＳ４９に進む。
ステップＳ４９において、特権ノード選出部１１４は、ステップＳ４９で所定時間（提案間隔△ｄ）待機してステップＳ３５に戻る。提案間隔△ｄは、一度提案が受理されなかった場合に次の提案をするまでの時間であり、２回連続で提案が失敗する可能性を排除するために△ｄ＝Ｔとする。
ここで、ステップＳ４９に進むケースは、第一フェーズ（Prepare phase）または第二フェーズ（Vote phase）において、過半数ノードのPromise応答またはＡＣＫを受信するまでに所定時間が経過した場合か、またはReject受信した場合である。しかし、前記提案回数が１回の場合の処理であるため、本Paxosアルゴリズムの一連の流れは完結していないと判定して、所定提案間隔待機後（ステップＳ４９）、上記ステップＳ３５に戻って上記処理を繰り返す。
上記ステップＳ４５または上記ステップＳ４６で、提案回数が２回以上の場合は（ステップＳ４５→Ｙｅｓ，ステップＳ４５→Ｙｅｓ）、２回連続で提案がRejectされるか、前記所定時間が経過した場合であり、Split-Brain Syndromeの発生の可能性がある。本実施形態では、この場合をクラスタ離脱指示部１１５（図２参照）がSplit-Brain Syndromeの発生の検出と判定する。
ステップＳ４７において、クラスタ離脱指示部１１５は、自身の所属するクラスタの全ノードに対し、当該クラスタからの離脱指示を行う。離脱指示を受け取ったノードは、当該クラスタから離脱することで、Split-Brain Syndromeを解消させることができる。
そして、ステップＳ４８において、クラスタ離脱指示部１１５は、自身もクラスタを離脱して本フローを終了する。また、ステップＳ４８において、クラスタ離脱指示部１１５は、Split-Brain Syndromeの発生の警報情報を出力し、管理者に気付かせるようにしてもよい。
そして、ステップＳ４８において、クラスタ離脱指示部１１５は、自身もクラスタを離脱して本フローを終了する。また、ステップＳ４８において、クラスタ離脱指示部１１５は、Split-Brain Syndromeの発生の警報情報を出力し、管理者に気付かせるようにしてもよい。
以上説明したように、クラスタ１０を構成する複数のノード１（図１および図２参照）は、アルゴリズムが完結するまでの一連の流れでのみ１つの提案で合意が取れることを保証する多数決プロトコルであるPaxosアルゴリズムを適用して、Master Leaseで用いるリース期間Ｔが途切れないようにリース期間更新間隔を設定して、自身の提案しか通らないように特権ノードである権利期間を確保し、かつ、ProposerがPaxosアルゴリズムの一連の流れが完結する前に連続して提案できる回数を２回以上とすることにより、自身がノード管理テーブル１２１を更新できる特権ノードであることを提案し合意を得る、特権ノード選出部１１４と、２回連続で提案がRejectされた場合または過半数から応答を集められなかった場合、Split-Brain Syndromeが発生したと判定するクラスタ離脱指示部１１５と、を備える。クラスタ離脱指示部１１５は、２回連続で提案がRejectされた場合、自身の所属するクラスタの全ノードに対し、前記クラスタからの離脱指示を行い、前記クラスタからの離脱指示を受け取ったノードは当該クラスタから離脱することで、Split-Brain Syndromeを解消させる。また、２回連続で提案がRejectされた場合、Split-Brain Syndromeの発生の警報情報を出力する。
この構成により、単一障害点（ＳＰＯＦ）を作らないためにクラスタを構成するノード管理をクラスタ内で実行する分散システムにおいて、経路障害等によりクラスタが複数クラスタに分断された場合であっても、自身がノード管理テーブルを更新できる特権ノードであることを提案し合意を得ることができ、Split-Brain Syndromeの発生を検出し解消することができる。
また、Split-Brain Syndromeの発生を検出した場合、自身および離脱指示を受け取ったノードは該当クラスタから離脱することができ、Split-Brain Syndromeを解消することができる。また、Split-brain Syndromeの発生の警報情報を出力することができる。
また、単一障害点となる外部のノード管理システムを利用せずにSplit-brain Syndromeを回避することができる。
また、単一障害点となる外部のノード管理システムを利用せずにSplit-brain Syndromeを回避することができる。
１ ノード
１０，１０Ａ，１０Ｂ クラスタ
１１ 処理部
１２ 記憶部
１３ 通信部
２０ ネットワーク
３０ クライアント
１００ 分散システム
１１１ ノード管理部
１１２ メッセージ処理部
１１３ 死活監視部
１１４ 特権ノード選出部
１１５ クラスタ離脱指示部
１２１ ノード管理テーブル（ノード管理情報）
１２２ 死活監視テーブル（死活監視情報）
１２３ データ記憶部
Ｔ リース期間
ｂ 提案番号
Ｖ 提案内容
１０，１０Ａ，１０Ｂ クラスタ
１１ 処理部
１２ 記憶部
１３ 通信部
２０ ネットワーク
３０ クライアント
１００ 分散システム
１１１ ノード管理部
１１２ メッセージ処理部
１１３ 死活監視部
１１４ 特権ノード選出部
１１５ クラスタ離脱指示部
１２１ ノード管理テーブル（ノード管理情報）
１２２ 死活監視テーブル（死活監視情報）
１２３ データ記憶部
Ｔ リース期間
ｂ 提案番号
Ｖ 提案内容
Claims (6)
- 複数のノードにより構成されるクラスタを備え、前記クラスタを構成する複数のノードの中からノードを管理する特権を持つ特権ノードを選出するクラスタシステムであって、
前記ノードは、
ノード識別子が記憶されるノード管理情報と死活を監視する対象のノードをリストアップした死活監視情報とを記憶する記憶部と、
前記クラスタへのノードの追加や離脱が発生した際に、前記クラスタを構成するノード識別子を更新し、前記ノード管理情報に記憶するノード管理部と、
前記死活監視情報に基づき、指定されたノードと死活監視信号をやり取りして、前記クラスタを構成するノードの障害を検出する死活監視部と、
アルゴリズムが完結するまでの一連の流れでのみ１つの提案で合意が取れることを保証する多数決プロトコルであるPaxosアルゴリズムを適用して、
Master Leaseで用いるリース期間が途切れないようにリース期間更新間隔を設定して、自身の提案しか通らないように特権ノードである権利期間を確保し、かつ、
Proposerが前記Paxosアルゴリズムの一連の流れが完結する前に連続して提案できる回数を２回以上とすることにより、自身が前記ノード管理情報を更新できる前記特権ノードであることを提案し合意を得るとともに、
一度提案が受理されなかった場合に次の提案をするまでの時間である提案間隔を前記リース期間とする、特権ノード選出部と、
前記提案が２回以上Rejectされた場合、または自身の所属するクラスタの過半数から応答を集められなかった場合、Split-Brain Syndromeが発生したと判定するクラスタ離脱指示部と、
を備えることを特徴とするクラスタシステム。 - 複数のノードにより構成されるクラスタを備え、前記クラスタを構成する複数のノードの中からノードを管理する特権を持つ特権ノードを選出するクラスタシステムであって、
前記ノードは、
ノード識別子が記憶されるノード管理情報と死活を監視する対象のノードをリストアップした死活監視情報とを記憶する記憶部と、
前記クラスタへのノードの追加や離脱が発生した際に、前記クラスタを構成するノード識別子を更新し、前記ノード管理情報に記憶するノード管理部と、
前記死活監視情報に基づき、指定されたノードと死活監視信号をやり取りして、前記クラスタを構成するノードの障害を検出する死活監視部と、
アルゴリズムが完結するまでの一連の流れでのみ１つの提案で合意が取れることを保証する多数決プロトコルであるPaxosアルゴリズムを適用して、
Master Leaseで用いるリース期間が途切れないようにリース期間更新間隔を設定して、自身の提案しか通らないように特権ノードである権利期間を確保し、かつ、
Proposerが前記Paxosアルゴリズムの一連の流れが完結する前に連続して提案できる回数を２回以上とすることにより、自身が前記ノード管理情報を更新できる前記特権ノードであることを提案し合意を得るとともに、
前記死活監視部からノード離脱情報を受信し、
自身が特権ノードか否かを判定し、自身が特権ノードでない場合に、前記特権ノードのリース期間中が経過したときには、前記クラスタにおいて定められた特権ノード選出の所定の条件に基づき、自身が特権ノード候補であるとする、特権ノード選出部と、
前記提案が２回以上Rejectされた場合、または自身の所属するクラスタの過半数から応答を集められなかった場合、Split-Brain Syndromeが発生したと判定するクラスタ離脱指示部と、
を備えることを特徴とするクラスタシステム。 - 前記クラスタ離脱指示部は、前記提案が２回以上Rejectされた場合、または自身の所属するクラスタの過半数から応答を集められなかった場合、自身の所属するクラスタの各ノードに対し、前記クラスタからの離脱指示を行い、前記クラスタからの離脱指示を受け取ったノードは当該クラスタから離脱することで、Split-Brain Syndromeを解消させることを特徴とする請求項２に記載のクラスタシステム。
- 前記特権ノード選出部は、
前記特権ノードであることを提案し合意を得る処理において、前記提案の回数をカウントしており、
前記提案の提案者を選定するためのPrepareリクエストを、前記特権ノード以外の自身の所属するクラスタのノードを示すAcceptorそれぞれに送信し、過半数の前記AcceptorからPromise応答を受信し、かつ、Rejectを受信していない場合、前記提案の提案内容に合意を得るためのAcceptリクエストを前記Acceptorそれぞれに送信し、
過半数の前記AcceptorからＡＣＫ応答を受信し、かつ、Rejectを受信していない場合、前記Paxosアルゴリズムの一連の流れが完結したと判定し、前記ノード管理情報の更新を行うとともに、前記Acceptorそれぞれへの更新情報の配信を行う、一方、
前記Prepareリクエストの送信後、所定時間経過またはRejectを受信した場合、若しくは、前記Acceptリクエストの送信後、所定時間経過またはRejectを受信した場合において、前記提案の回数が１回のときは、前記Paxosアルゴリズムの一連の流れが完結していないと判定して所定提案間隔待機し、前記Prepareリクエストから再度処理を実行し、
前記Prepareリクエストの送信後、前記所定時間経過またはRejectを受信した場合、若しくは、前記Acceptリクエストの送信後、前記所定時間経過またはRejectを受信した場合において、前記提案の回数が２回以上のときは、前記Paxosアルゴリズムの一連の流れが完結したと判定し、
前記クラスタ離脱指示部は、
前記特権ノード選出部が、前記所定時間経過またはRejectを受信した場合に、前記提案の回数が２回以上であるとしたときに、前記Split-Brain Syndromeが発生したと判定すること
を特徴とする請求項２または請求項３に記載のクラスタシステム。 - 複数のノードにより構成されるクラスタを備え、前記クラスタを構成する複数のノードの中からノードを管理する特権を持つ特権ノードを選出するクラスタシステムのSplit-Brain Syndrome検出方法であって、
前記ノードは、
ノード識別子が記憶されるノード管理情報と死活を監視する対象のノードをリストアップした死活監視情報とを記憶しており、
前記クラスタへのノードの追加や離脱が発生した際に、前記クラスタを構成するノード識別子を更新し、前記ノード管理情報に記憶するステップと、
前記死活監視情報に基づき、指定されたノードと死活監視信号をやり取りして、前記クラスタを構成するノードの障害を検出するステップと、
アルゴリズムが完結するまでの一連の流れでのみ１つの提案で合意が取れることを保証する多数決プロトコルであるPaxosアルゴリズムを適用して、
Master Leaseで用いるリース期間が途切れないようにリース期間更新間隔を設定して、自身の提案しか通らないように特権ノードである権利期間を確保し、かつ、
Proposerが前記Paxosアルゴリズムの一連の流れが完結する前に連続して提案できる回数を２回以上とすることにより、自身が前記ノード管理情報を更新できる前記特権ノードであることを提案し合意を得るとともに、
一度提案が受理されなかった場合に次の提案をするまでの時間である提案間隔を前記リース期間とするステップと、
前記提案が２回以上Rejectされた場合、または自身の所属するクラスタの過半数から応答を集められなかった場合、Split-Brain Syndromeが発生したと判定するステップと、
を実行することを特徴とするクラスタシステムのSplit-Brain Syndrome検出方法。 - 複数のノードにより構成されるクラスタを備え、前記クラスタを構成する複数のノードの中からノードを管理する特権を持つ特権ノードを選出するクラスタシステムのSplit-Brain Syndrome検出方法であって、
前記ノードは、
ノード識別子が記憶されるノード管理情報と死活を監視する対象のノードをリストアップした死活監視情報とを記憶しており、
前記クラスタへのノードの追加や離脱が発生した際に、前記クラスタを構成するノード識別子を更新し、前記ノード管理情報に記憶するステップと、
前記死活監視情報に基づき、指定されたノードと死活監視信号をやり取りして、前記クラスタを構成するノードの障害を検出するステップと、
アルゴリズムが完結するまでの一連の流れでのみ１つの提案で合意が取れることを保証する多数決プロトコルであるPaxosアルゴリズムを適用して、
Master Leaseで用いるリース期間が途切れないようにリース期間更新間隔を設定して、自身の提案しか通らないように特権ノードである権利期間を確保し、かつ、
Proposerが前記Paxosアルゴリズムの一連の流れが完結する前に連続して提案できる回数を２回以上とすることにより、自身が前記ノード管理情報を更新できる前記特権ノードであることを提案し合意を得るとともに、
ノード離脱情報を受信し、
自身が特権ノードか否かを判定し、自身が特権ノードでない場合に、前記特権ノードのリース期間中が経過したときには、前記クラスタにおいて定められた特権ノード選出の所定の条件に基づき、自身が特権ノード候補であるとするステップと、
前記提案が２回以上Rejectされた場合、または自身の所属するクラスタの過半数から応答を集められなかった場合、Split-Brain Syndromeが発生したと判定するステップと、
を実行することを特徴とするクラスタシステムのSplit-Brain Syndrome検出方法。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2013167405A JP6091376B2 (ja) | 2013-08-12 | 2013-08-12 | クラスタシステムおよびＳｐｌｉｔ−ＢｒａｉｎＳｙｎｄｒｏｍｅ検出方法 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2013167405A JP6091376B2 (ja) | 2013-08-12 | 2013-08-12 | クラスタシステムおよびＳｐｌｉｔ−ＢｒａｉｎＳｙｎｄｒｏｍｅ検出方法 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2015036834A JP2015036834A (ja) | 2015-02-23 |
| JP6091376B2 true JP6091376B2 (ja) | 2017-03-08 |
Family
ID=52687320
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2013167405A Active JP6091376B2 (ja) | 2013-08-12 | 2013-08-12 | クラスタシステムおよびＳｐｌｉｔ−ＢｒａｉｎＳｙｎｄｒｏｍｅ検出方法 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP6091376B2 (ja) |
Families Citing this family (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN106155780B (zh) | 2015-04-02 | 2020-01-31 | 阿里巴巴集团控股有限公司 | 一种基于时间的节点选举方法及装置 |
| WO2016181462A1 (ja) * | 2015-05-11 | 2016-11-17 | 株式会社日立製作所 | 情報処理システムおよびクラスタ管理方法 |
| US9858011B2 (en) | 2015-12-16 | 2018-01-02 | International Business Machines Corporation | Repopulating failed replicas through modified consensus recovery |
| CN109240840B (zh) * | 2017-07-11 | 2022-04-19 | 阿里巴巴集团控股有限公司 | 集群系统的容灾方法、装置和机器可读介质 |
Family Cites Families (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP5016696B2 (ja) * | 2010-03-05 | 2012-09-05 | 日本電信電話株式会社 | 高可用性システム、サーバ、高可用性維持方法及びプログラム |
| US8595546B2 (en) * | 2011-10-28 | 2013-11-26 | Zettaset, Inc. | Split brain resistant failover in high availability clusters |
-
2013
- 2013-08-12 JP JP2013167405A patent/JP6091376B2/ja active Active
Also Published As
| Publication number | Publication date |
|---|---|
| JP2015036834A (ja) | 2015-02-23 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US11894972B2 (en) | System and method for data replication using a single master failover protocol | |
| US11899684B2 (en) | System and method for maintaining a master replica for reads and writes in a data store | |
| US9201742B2 (en) | Method and system of self-managing nodes of a distributed database cluster with a consensus algorithm | |
| US10944637B2 (en) | System and/or method for maintaining highly-available, consistent, partition-tolerant clusters using client voters | |
| Botelho et al. | On the design of practical fault-tolerant SDN controllers | |
| US8055735B2 (en) | Method and system for forming a cluster of networked nodes | |
| US9984140B1 (en) | Lease based leader election system | |
| JP6382454B2 (ja) | 分散ストレージ及びレプリケーションシステム、並びに方法 | |
| US8719225B1 (en) | System and method for log conflict detection and resolution in a data store | |
| EP1617331B1 (en) | Efficient changing of replica sets in distributed fault-tolerant computing system | |
| CN113646749B (zh) | Iot分区管理和负载平衡 | |
| JP2005209201A (ja) | 高可用性クラスタにおけるノード管理 | |
| JPWO2006095427A1 (ja) | サーバシステム、サーバ装置およびその方法 | |
| JP6091376B2 (ja) | クラスタシステムおよびＳｐｌｉｔ−ＢｒａｉｎＳｙｎｄｒｏｍｅ検出方法 | |
| CN106302569B (zh) | 处理虚拟机集群的方法和计算机系统 | |
| CN107153660A (zh) | 分布式数据库系统的故障检测处理方法及其系统 | |
| CN109189854B (zh) | 提供持续业务的方法及节点设备 | |
| US10305987B2 (en) | Method to syncrhonize VSAN node status in VSAN cluster | |
| JP2009217504A (ja) | 計算機システム、計算機制御方法及び計算機制御プログラム | |
| Stanik et al. | Failover pattern with a self-healing mechanism for high availability cloud solutions | |
| JP5480046B2 (ja) | 分散トランザクション処理システム、装置、方法およびプログラム | |
| JP4167238B2 (ja) | サーバシステム、サーバ装置およびその方法 | |
| CN110266795A (zh) | 一种基于Openstack平台控制方法 | |
| JP6093320B2 (ja) | 分散処理システム | |
| Ma et al. | A pipelined Single-Phase Paxos Extension without lease |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20150317 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20150515 |
|
| A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20151208 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20170207 |
|
| R150 | Certificate of patent or registration of utility model |
Ref document number: 6091376 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 |