JP6100135B2 - フォールトトレラントシステム及びフォールトトレラントシステム制御方法 - Google Patents

フォールトトレラントシステム及びフォールトトレラントシステム制御方法 Download PDF

Info

Publication number
JP6100135B2
JP6100135B2 JP2013199614A JP2013199614A JP6100135B2 JP 6100135 B2 JP6100135 B2 JP 6100135B2 JP 2013199614 A JP2013199614 A JP 2013199614A JP 2013199614 A JP2013199614 A JP 2013199614A JP 6100135 B2 JP6100135 B2 JP 6100135B2
Authority
JP
Japan
Prior art keywords
computer
message
processing
node
processing content
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.)
Expired - Fee Related
Application number
JP2013199614A
Other languages
English (en)
Other versions
JP2015064833A (ja
Inventor
拓 下沢
拓 下沢
雅徳 吉田
雅徳 吉田
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Hitachi Ltd
Original Assignee
Hitachi Ltd
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Hitachi Ltd filed Critical Hitachi Ltd
Priority to JP2013199614A priority Critical patent/JP6100135B2/ja
Priority to PCT/JP2014/069305 priority patent/WO2015045589A1/ja
Publication of JP2015064833A publication Critical patent/JP2015064833A/ja
Application granted granted Critical
Publication of JP6100135B2 publication Critical patent/JP6100135B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/18—Error detection or correction of the data by redundancy in hardware using passive fault-masking of the redundant circuits
    • G06F11/187—Voting techniques
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/1675—Temporal synchronisation or re-synchronisation of redundant processing components
    • G06F11/1683—Temporal synchronisation or re-synchronisation of redundant processing components at instruction level
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/18—Error detection or correction of the data by redundancy in hardware using passive fault-masking of the redundant circuits
    • G06F11/182—Error detection or correction of the data by redundancy in hardware using passive fault-masking of the redundant circuits based on mutual exchange of the output between redundant processing components

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Quality & Reliability (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Hardware Redundancy (AREA)

Description

本発明は、フォールトトレラントシステム及びフォールトトレラントシステム制御方法に関するものであり、具体的には、アーキテクチャや基盤ソフトウェア等が互いに異なる複数の計算機ノードで構成されたフォールトトレラントシステムにおいて、計算機ノード間の性能差やばらつきによる全体性能の影響を低減し、またこうした影響に起因する過度な障害判定を防止することにより、システムにおける可用性向上を可能とする技術に関する。
ミッションクリティカルなコンピュータシステムにおいて、所定の冗長性を持たせることで高い可用性を確保するフォールトトレランスの概念が導入されている。そうした概念に対応する技術としては、該当システムを複数の計算機から構成し、同期動作する各計算機の出力信号を多数決チェックにて比較、監視して、不具合のある計算機をシステムから切り離すといったものが提案されている。例えば、ユーザが「インタフェースと対話して、モニタされる変数、すなわち多数決される変数と、多数決が行われるブレークポイントと、多数決および回復パラメータなどの情報と」を指定し、「指定されたブレークポイントで相異なるコピーによって生成されたユーザ指定変数のうちの１つ以上の値を比較することによって、コピーのうちの１つにフォールトが検出される」といった従来技術（特許文献１参照）がある。
特許第３６２４１１９号公報
ところで、同じハードウェアで同じ基盤ソフトウェアを使用する複数の計算機ノードで構成したフォールトトレラントシステム（以下、同種ＦＴシステムという）であっても、各計算機ノードにて同じタスクを実行した場合の実行時間は、計算機ノード間でばらつきを生じる。このばらつきは、中央演算装置のアーキテクチャ、性能、基盤ソフトウェアの種類の一つあるいは複数が異なる計算機ノードを組み合わせたフォールトトレラントシステム（以下、異種ＦＴシステムという）において、計算機ノード間の性能差に由来し更に顕著なものとなる傾向にある。
あるプログラムを実行するのにかかる時間は、計算機ノードにおけるハードウェアの性能だけでなく様々な外的要因により変化するため、一般に予測が困難である。このため、同種ＦＴシステムおよび異種ＦＴシステムのいずれの場合においても、この計算機ノード間の実行時間の差を許容し、かつ、無応答あるいは大幅な処理遅延の事象に基づく障害ノードの判定とその排除を、可用性を損なわずに行う必要がある。
一方、従来技術においては、出力間で多数決を行うにあたり、ある時点での変数内容の比較を行う際に、同期的に各コピー（計算機ノード）から変数内容を収集し比較するために、必ず全ノードが該当時点で同期する必要がある。このことは、各コピーの実行時間のばらつきを該当時点で吸収する必要があるため、全体の処理効率低下を招くことにつながりかねない。また、そのようなばらつきを許容する障害判定時間の設定も、実行時間の予測困難性により困難である。
そこで本発明の目的は、アーキテクチャや基盤ソフトウェア等が互いに異なる複数の計算機ノードで構成されたフォールトトレラントシステムにおいて、計算機ノード間の性能差やばらつきによる全体性能の影響を低減し、またこうした影響に起因する過度な障害判定を防止することにより、システムにおける可用性向上を可能とする技術を提供することにある。
上記課題を解決する本発明のフォールトトレラントシステムは、多数決冗長構成を形成する複数の計算機各々において、当該計算機の内部で動作するプログラムからその処理内容を取得するタスク通信部と、前記多数決冗長構成を形成するいずれかの他計算機より、前記他計算機で動作するプログラムの処理内容を示す所定メッセージを受信し、前記所定メッセージが示す処理内容と前記タスク通信部が得ている前記処理内容との一致判定の結果に応じ、前記他計算機に追従可否のメッセージを返信するメッセージ処理部とを備えており、前記他計算機となった計算機のメッセージ処理部は、当該他計算機のタスク通信部が得ている処理内容に応じて、前記追従可否のメッセージの受信待ち対象とする、当該他計算機以外の計算機の数を変更する処理を更に実行するものである、ことを特徴とする。
上記課題を解決する本発明のフォールトトレラントシステム制御方法は、多数決冗長構成を形成する複数の計算機各々において、当該計算機の内部で動作するプログラムからその処理内容を取得する処理と、前記多数決冗長構成を形成するいずれかの他計算機より、前記他計算機で動作するプログラムの処理内容を示す所定メッセージを受信し、前記所定メッセージが示す処理内容と前記処理で得ている前記処理内容との一致判定の結果に応じ、前記他計算機に追従可否のメッセージを返信する処理とを実行し、更に、前記他計算機においては、当該他計算機で動作するプログラムから得ている処理内容に応じて、前記追従可否のメッセージの受信待ち対象とする、当該他計算機以外の計算機の数を変更する処理を更に実行する、ことを特徴とする。
本発明によれば、アーキテクチャや基盤ソフトウェア等が互いに異なる複数の計算機ノードで構成されたフォールトトレラントシステムにおいて、計算機ノード間の性能差やばらつきによる全体性能の影響を低減し、またこうした影響に起因する過度な障害判定を防止することにより、システムにおける可用性が向上する。
第１の実施形態に係るフォールトトレラントシステムの構成例を示す図である。 第１の実施形態に係るフォールトトレラントシステムを構成する複数の計算機ノード間の関係例を示す図である。 第１の実施形態に係るフォールトトレラントシステムを構成する計算機ノードが保持する承認メッセージリストの構成例を示す図である。 第１の実施形態に係るフォールトトレラントシステムを構成する計算機ノードが保持する通知メッセージリストの構成例を示す図である。 第１の実施形態に係るフォールトトレラントシステムを構成する計算機ノードが保持するメッセージ種類テーブルの構成例を示す図である。 第１の実施形態に係るフォールトトレラントシステムを構成する複数の計算機ノード間で授受されるデータの構造例を示す図である。 第１の実施形態に係るフォールトトレラントシステムにおける計算機ノードの各処理部の動作フロー例を示す図である。 第１の実施形態に係るフォールトトレラントシステムにおけるリーダーノードのメッセージ処理部での動作フロー例１を示す図である。 第１の実施形態に係るフォールトトレラントシステムにおけるリーダーノードのメッセージ処理部での動作フロー例２を示す図である。 第１の実施形態に係るフォールトトレラントシステムにおけるフォロワーノードのメッセージ処理部での動作フロー例を示す図である。 第２の実施形態におけるフォールトトレラントシステムのフォロワーノードのメッセージ処理部での動作フロー例１を示す図である。 第２の実施形態におけるフォールトトレラントシステムのフォロワーノードのメッセージ処理部での動作フロー例２を示す図である。 第３の実施形態におけるフォールトトレラントシステムのリーダーノードのメッセージ処理部での動作フロー例を示す図である。 第４の実施形態におけるフォールトトレラントシステムのリーダーノードのメッセージ処理部での動作フロー例を示す図である。
−−−第１の実施形態−−−
以下に本発明における第１の実施形態について図面を用いて詳細に説明する。第１の実施形態のフォールトトレラントシステムにおいては、多数決冗長構成におけるリーダーたる計算機およびフォロワーたる各計算機で、同一のタスクを実行する。リーダーはタスクの処理状体が含まれた通知メッセージをフォロワーに対して逐次送信し、フォロワーはそれに対して、リーダー同様に処理可能であるかどうかを承認／否認のメッセージ（追従可否のメッセージ）としてリーダーに応答する。この場合、リーダーはフォロワーからの応答すなわち上述のメッセージの内容、受信タイミングおよびメッセージの種類によって、該当タスクに関して多数決冗長構成に対応した動作（例：メッセージ待ち受け）の継続に関して判断する。
図１は、第１の実施形態に係るフォールトトレラントシステムの構成例を示す図である。図１に示すフォールトトレラントシステム１は、アーキテクチャや基盤ソフトウェア等が互いに異なる複数の計算機ノードで構成されたフォールトトレラントシステムにおいて、計算機ノード間の性能差やばらつきによる全体性能の影響を低減し、またこうした影響に起因する過度な障害判定を防止することにより、システムにおける可用性を向上させるコンピュータシステムである。
当該フォールトトレラントシステム１は、複数の計算機ノード１１０で構成される。図１のフォールトトレラントシステム１においては、計算機ノード１１０として３台の計算機ノード１１０Ａ、１１０Ｂ、１１０Ｃでシステム構成した例を示している。勿論、フォールトトレラントシステム１を構成する計算機ノード数は「３」台である場合に限定されず、例えば「２」台や「４」台以上であってもよい。
多数決冗長構成に対応したフォールトトレラントシステム１においては、計算機ノード１１０のうち１台をリーダーノードとし、残りの計算機ノード１１０をフォロワーノードとする。リーダーノードとフォロワーノードの役割は、計算機ノード１１０の中で固定的である必要はない。例えば、あるタスク毎、すなわち当該タスクに関する上述の通知メッセージごとに、一番最初にその通知メッセージを送信した計算機ノード１１０をリーダーノードとするなどといったアルゴリズムを用いて、それぞれの役割を交代してもよい。ただし、フォールトトレラントシステム１の動作中の任意の時点において、リーダーノードは、高々一つが存在する。リーダーノードが存在しない場合、もしくは、リーダーノードに何らかの障害が発生して処理を停止しリーダーノードが存在しなくなった場合、フォールトトレラントシステム１は処理を中断し、フォロワーノードの中から、一つの計算機ノード１１０をリーダーノードとして選ぶこととなる。こうした多数決冗長構成を成す計算機ノード中からリーダーノードを選択する処理技術については既存のものを採用してよい。なお、第１の実施形態においては、３台の計算機ノード１１０のうち、計算機ノード１１０Ａをリーダーとし、計算機ノード１１０Ｂ及び計算機ノード１１０Ｃをフォロワーとしている。
また、各計算機ノード１１０のハードウェア構成は以下の如くとなる。計算機ノード１１０は、主記憶装置１２１と１つ以上の中央演算装置１２０、外部通信インタフェース１２２、およびノード間通信インタフェース１２３を備える。このうち外部通信インタフェース１２２は、１台以上の端末１０２と外部ネットワーク１１１を介し接続されている。また、ノード間通信インタフェース１２３は、他の計算機ノード１１０とノード間ネットワーク１１２を介し接続されている。これらのネットワーク１１１、１１２は、例えばイーサネット（登録商標）規格やＩｎｆｉｎｉｂａｎｄ規格に準拠して構成されたネットワークである。
また、計算機ノード１１０における主記憶装置１２１は、データの読み込み及び書き込みが可能な揮発性記憶装置であり、中央演算装置１２０からアクセスされる。この主記憶装置１２１は、例えばＤＲＡＭ（Ｄｙｎａｍｉｃ Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）等で構成されるものである。
また、計算機ノード１１０における中央演算装置１２０は、汎用プロセッサであり、補助記憶装置１２４等から、基本ソフトウェア１３０、フォールトトレラントミドルウェア（以下、ＦＴミドルウェア）１３１、及びアプリケーション１３２等のプログラムを読み出して主記憶装置１２１に展開し、該当プログラムを実行する。中央演算装置１２０の採用するアーキテクチャや、その処理速度は、複数ある計算機ノード１１０で同一のものでなくてもよい。また、各計算機ノード１１０は２つ以上の中央演算装置１２０を備えていてもよい。
また、計算機ノード１１０における補助記憶装置１２４は、永続的な不揮発性記憶装置であり、基本ソフトウェア１３０、ＦＴミドルウェア１３１、アプリケーション１３２等のプログラムに加えて、これらプログラムから読み書きされるデータ等が格納される。補助記憶装置１２４は、例えばハードディスク、フラッシュメモリなどにより構成される。
また、計算機ノード１１０における外部通信インタフェース１２２は、計算機ノード１１０が端末１０２と通信を行うためのインタフェースである。一方、ノード間通信インタフェース１２３は、計算機ノード１１０同士で通信を行うためのインタフェースである。なお、外部通信インタフェース１２２及びノード間通信インタフェース１２３は、個別の装置である必要はなく、一つの通信インタフェースが外部通信インタフェース１２２及びノード間通信インタフェース１２３を兼ねていてもよい。外部通信インタフェース１２２及びノード間通信インタフェース１２３は、それぞれ外部ネットワーク１１１及びノード間ネットワーク１１２の種類に応じた通信インタフェース等で構成される。
また、主記憶装置１２１に保持されるアプリケーション１３２は、ＦＴシステム１が提供する機能を実現するためのプログラムである。アプリケーション１３２は、一つ以上のタスク１３３から構成される。ＦＴシステム１においては、複数の計算機ノード１１０で同じアプリケーション１３２が実行される。なおこの時、アプリケーション１３２は、実行される計算機ノード１１０のアーキテクチャや基盤ソフトウェア等の差異に応じた差異をもっていてもよい。すなわち、アプリケーション１３２およびそのタスク１３３を構成する、中央演算装置１２０のための命令群は、計算機ノード１１０間において同一である必要はない。
また、主記憶装置１２１に保持される基本ソフトウェア１３０は、マルチタスク処理が可能なオペレーティングシステムであり、複数のタスク１３３およびＦＴミドルウェア１３１を並列に実行することができる。この基本ソフトウェア１３０は、ＦＴミドルウェア１３１に対して、補助記憶装置１２４に対するアクセス、外部通信インタフェース１２２及びノード間通信インタフェース１２３に対するデータ送受信の機能、主記憶装置１２１の一部分の占有領域の確保および解放等の機能を提供する。
また、主記憶装置１２１に保持されるＦＴミドルウェア１３１は、ＦＴシステム１においてフォールトトレラント機能を実現するためのプログラムである。ＦＴミドルウェア１３１は、上述のアプリケーション１３２に対して、補助記憶装置１２４に対するアクセス、外部通信インタフェース１２２に対するデータ送受信、主記憶装置１２１の一部分に対する排他処理の機能等を提供する。これらの機能について、ＦＴミドルウェア１３１は、基本ソフトウェア１３０等の提供する機能を用いて実現する。なお、ＦＴミドルウェア１３１は、独立したプログラムであっても、アプリケーション１３２に組み込まれて一体となる形であっても、あるいは、基本ソフトウェア１３０に組み込まれて一体となる形であってもよい。また、アプリケーション１３２、ＦＴミドルウェア１３１、基本ソフトウェア１３０の３つは、単一のプログラムが兼ねていてもよい。
こうしたＦＴミドルウェア１３１は、タスク通信部１４０、ノード間通信部１４１、およびメッセージ処理部１４２を備えている。これらタスク通信部１４０、ノード間通信部１４１、メッセージ処理部１４２は、各計算機ノード１１０の中央演算装置１２０がＦＴミドルウェア１３１を実行することで実装される機能と言える。
このうちタスク通信部１４０は、タスク１３３からの処理の要求を受け取り、その要求をメッセージ処理部１４２に対して伝達する。一方、メッセージ処理部１４２は、他の計算機ノード１１０との同期をとった上で要求された処理を実行し、その結果をタスク通信部１４０に対して伝達する。メッセージ処理部１４２から上述の結果を得たタスク通信部１４０は、該当結果をタスク１３３に対して伝える。
メッセージ処理部１４２が他の計算機ノード１１０との通信を行う際には、ノード間通信部１４１に対し、ノード間通信インタフェース１２３を経由したデータ送信を要求する。一方、ノード間通信部１４１はノード間通信インタフェース１２３から受信したデータをメッセージ処理部１４２に伝達する。こうした、タスク１３３とタスク通信部１４０、タスク通信部１４０とメッセージ処理部１４２、メッセージ処理部１４２とノード間通信部１４１の各間の伝達の手段としては、任意のものを採用できる。例えば、上述の伝達手段として、関数呼び出しとその返り値や、ソケットやパイプといった基本ソフトウェア１３０の提供する通信手段等を用いることができる。
また、ノード間通信部１４１は、ノード間通信インタフェース１２３からデータを受信すると、その内容をメッセージ処理部１４２に伝達する。また、メッセージ処理部１４２から、他の計算機ノード１１０に対してのデータ送信の要求を受けると、その内容を指定された計算機ノード１１０に対して、ノード間通信インタフェース１２３を用いた送信を行う。
ＦＴミドルウェア１３１では、前述した処理部１４０、１４１、１４２の他に、承認メッセージリスト１５０、通知メッセージリスト１５１、およびメッセージ種類テーブル１５２を備える。これらの保持するデータ及びその役割については後述する。なお、メッセージ種類テーブル１５２は、処理において必ずしも必要なものではない。これについても後述する。
続いて、ＦＴシステム１を構成する各計算機ノード１１０の間の関係について説明する。図２は、第１の実施形態に係るＦＴシステム１を構成する複数の計算機ノード間の関係例を示す図であり、ＦＴシステム１がフォールトトレラント機能を実現するために必要な各部分の関係例について示した図である。ＦＴシステム１の実現するフォールトトレラント機能は、半数未満の計算機ノード１１０のハードウェアあるいはソフトウェアの障害が発生しても、タスク１３３の機能を継続して提供できる機能である。
そのために、先に説明したように、複数の計算機ノード１１０において同じタスク１３３を動作させる。タスク１３３が外部からの入力あるいは外部への出力を行う時、あるいは、複数のスレッドの動作順序を決定する時など、動作を計算機ノード１１０間で一致化させなければならない処理（以下、「動作一致化点」と呼ぶ）において、計算機ノード１１０間でメッセージをやりとりして、全ての計算機ノード１１０でタスク１３３が同一の挙動を示すようにする。
このために、各タスク１３３は、各動作一致化点において、ＦＴミドルウェア１３１を呼び出し、その処理の実行を要求する。一方、ＦＴミドルウェア１３１は、その内容を他の計算機ノード１１０のタスク１３３の要求と比較し、過半数の計算機ノード１１０に関して同一であれば、それを実際に実行する。これにより、計算機ノード１１０の半数未満が、ハードウェア障害やソフトウェア障害によって無応答、応答遅延、あるいは、異常応答を行った場合でも、他の計算機ノード１１０の結果により、タスク１３３の動作を継続することができる。
本実施形態では、上述したように、動作一致化点において計算機ノード１１０間で合意形成の効率化のために、計算機ノード１１０を、役割別にリーダーノード１１０Ａとフォロワーノード１１０Ｂ、１１０Ｃの二種に分けるものとする。動作一致化点において、リーダーノード１１０Ａが、その動作を決定し、フォロワーノード１１０Ｂ、１１０Ｃに対して、その処理要求に対する動作内容を通知メッセージ２０１により通知する。フォロワーノード１１０Ｂ、１１０Ｃは、自身のタスク１３３からの処理要求と照合し、この動作内容に追従可能、すなわちリーダーノード１１０Ａと同じ挙動を実現することが可能であれば承認メッセージ２０２、不可能であれば否認メッセージ２０３をリーダーノード１１０Ａに返答する。リーダーノード１１０Ａは、承認メッセージ２０２を多数決における賛成票、否認メッセージ２０３を反対票として扱い、過半数が承認メッセージ２０２を受け取った時には、これを実際に実行する。このような多数決冗長構成に伴うリーダーノード１１０Ａ、フォロワーノード１１０Ｂ、１１０Ｃの基本的な挙動に関しては従来と同様である。
続いて、ＦＴミドルウェア１３１内の構造であるタスク通信部１４０、メッセージ処理部１４２、ノード間通信部１４１の動作と、その際に使用されるデータ構造である承認メッセージリスト１５０、通知メッセージリスト１５１、およびメッセージ種類テーブル１５２について述べる。
図３、図４、図５は、承認メッセージリスト１５０、通知メッセージリスト１５１、およびメッセージ種類テーブル１５２の内部構造の一例をそれぞれ示した図である。このうち、承認メッセージリスト１５０及び通知メッセージリスト１５１は、メッセージ処理部１４２によって下記のように使用される。メッセージ処理部１４２は、タスク通信部１４０から処理要求を受け取ったとき、当該計算機ノード１１０がリーダーノードであれば、これを他の計算機ノードすなわちフォロワーノードに対して伝達する。メッセージ処理部１４２は、フォロワーノードからの承認メッセージや否認メッセージの受信の有無を管理するために、承認メッセージリスト１５０に承認メッセージ、否認メッセージの受信履歴を記録する。他方、フォロワーノードでは、リーダーノードからの通知メッセージの受信の有無を管理するために、通知メッセージ２０１のリストである通知メッセージリスト１５１を使用する。
承認メッセージリスト１５０は、通知参照３００、承認ノード集合３０１、及び、否認ノード集合３０２などの各値を各行として持つテーブルである。通知参照３００は、その行の管理するところの通知メッセージ２０１への参照（参照は、識別子によるもの、メモリ番地によるもの、あるいは、参照先のコピーによるものなど任意の方法でよい。以下同様）用の情報で通知メッセージ２０１の識別情報となる。また、承認ノード集合３０１は、通知メッセージ２０１に対して承認メッセージ２０２を返答したフォロワーノードたる計算機ノード１１０の集合を表す。同様に、否認ノード集合３０２は、通知メッセージ２０１に対して否認メッセージ２０３を返答したフォロワーノードたる計算機ノード１１０の集合を表す。
また、通知メッセージリスト１５１は、リーダーノードから送付されていて、かつ、承認メッセージ２０２もしくは否認メッセージ２０３を返答していない０個以上の通知メッセージ２０１をリストとして持つ。
次に、タスク通信部１４０とメッセージ処理部１４２への処理の要求及びその結果の伝達に用いられるデータ構造について述べる。以下では、「処理要求」とはこのタスク通信部１４０からメッセージ処理部１４２に対して、タスクからの処理要求を伝達するデータ構造を指し、「処理結果」とはメッセージ処理部１４２からタスク通信部１４０に対して、処理要求に対する処理の結果（処理内容）を伝達するデータ構造を指す。処理要求の内部構造の一例としては、要求種別と、それに応じた要求パラメータがある。他方、処理結果の内部構造の一例としては、対応している処理要求への処理要求参照と、処理の結果を表す値である処理結果値がある。なお、タスク通信部１４０とメッセージ処理部１４２の間の伝達方式により、参照する処理が一意に特定できるのであれば、処理要求参照を省略することができる。
処理要求において、要求種別は、タスク１３３のＦＴミドルウェア１３１に対する要求の種別を示し、例えば、補助記憶装置１２４からの読み込みや補助記憶装置１２４への書き込み、外部通信インタフェース１２２からのデータ受信、あるいはデータ送信、主記憶装置１２１の一部領域に対する排他処理といったものである。一方、要求パラメータは、それぞれ要求種別により意味を異とする値であり、またその数も要求種別に応じて異なる。要求種別が「補助記憶装置１２４からの読み込み」であった場合を一例とすれば、補助記憶装置１２４上のファイル名、ファイル上の位置、読み込んだ値を格納する主記憶装置１２１の位置、読み込むバイト数等が、要求パラメータに含まれる。
また処理結果は、タスク通信部１４０からメッセージ処理部１４２に対してそれまでに通知された処理要求の処理結果を、メッセージ処理部１４２からタスク通信部１４０に通知するために使用される。処理結果値は、処理要求参照により参照される処理要求の要求種別により意味を異とする値であり、またその数も要求種別に応じて異なる。なお、この処理結果値は、要求に対する結果を全て表現する必要はない。たとえば外部通信インタフェース１２２からデータを受信し指定した主記憶装置１２１へのコピーといった副作用を持つ処理要求であれば、メッセージ処理部１４２は、指定したデータ内容の主記憶装置１２１へのコピー処理を行った上で、処理結果をタスク通信部１４０に通知する。このような場合において、受信したデータのサイズのみを処理結果値として返し、受信データそのものの情報は、処理結果値には陽に含めないということができる。
図６にて、リーダーノードとフォロワーノードの間で、処理要求の伝達を行う際に用いられる通知メッセージ２０１及び、それに対する応答である承認メッセージ２０２と否認メッセージ２０３ のデータ構造の一例を示す。ここで通知メッセージ２０１は、伝達するリクエストへの参照値であり、処理要求の種別を規定した処理要求４００をもつ。処理要求への参照値に加えて、あるいはそれに代えて、後述するフォロワーノードにおける内容比較のために十分な内容、すなわちその処理要求について挙動が同一であると判定するのに十分な情報を含む任意の付随データ４０６を含んでいてもよい。
また、承認メッセージ２０２及び否認メッセージ２０３は、対応するリーダーノードから送付された通知メッセージ２０１を参照するための値である通知参照３００を持つ。なお、通知メッセージ２０１を一意に識別できるのであれば、処理要求の参照で代用することもできる。
続いて図５に示すメッセージ種類テーブル１５２について述べる。メッセージ処理部１４２は、後述するように各処理要求に対して、メッセージ同期種類を判定する。メッセージ同期種類は、例えば「同期」、「準同期」のいずれかであり、その処理要求に対するメッセージの応答あるいは到着に対して、メッセージ処理部１４２がいつ次の処理に進むかの処理を規定するものである。例えば、リーダーノードにおけるメッセージ処理部１４２は、そのメッセージ同期種類が「同期」である処理要求に対しては、現在ＦＴシステム１で正常に動作している全ての計算機ノード１１０からの応答を待ってから次の処理に進み、「準同期」であるメッセージに対しては、現在ＦＴシステム１で正常に動作している計算機ノード１１０の半数の承認メッセージ２０２を待ってから次の処理に進む、といった動作を行う。この判断の方法の一例として、メッセージ種類テーブル１５２を用いた方法がある。 このメッセージ種類テーブル１５２は、上述した処理要求について、その要求種別３０３からメッセージ同期種類３０４を判断するものである。メッセージ種類テーブル１５２は、要求種別３０３とメッセージ同期種類３０４などの各値を各行として持つテーブルである。各行は、要求種別３０３をもつ処理要求、および、それを処理要求参照としてもつ通知メッセージ２０１のメッセージ待ちの挙動の種類が、メッセージ同期種類３０４であることを意味する。なお、メッセージ同期種類の判定は、この方法に限定されない。例えば、メッセージ種類テーブル１５２が存在しない場合であっても、計算機ノード１１０がメッセージにそのメッセージを一意に識別する連番を振り、ある倍数の番号のメッセージを「同期」とし、それ以外を「準同期」とするといった方法をとることもできる。
続いて、ＦＴシステム１を構成する各計算機ノード１１０Ａ、１１０Ｂ、１１０Ｃの動作と連携について説明する。図７は第１の実施形態に係るＦＴシステム１における計算機ノード１１０の各処理部の動作フロー例を示す図である。この図においては、リーダーノードとして計算機ノード１１０Ａ、フォロワーノードとして計算機ノード１１０Ｂの動作を示している。この他のフォロワーノード１１０Ｃについては、計算機ノード１１０Ｂと同様の動作を行うので説明を省略している。
まず、リーダーノードたる計算機ノード１１０Ａの動作について述べる。計算機ノード１１０Ａのタスク通信部１４０は、アプリケーション１３２から要求を受け（５１０）、これを処理要求４００の形でメッセージ処理部１４２に伝達する（５１１）。メッセージ処理部１４２は、この処理要求４００に応じて必要であれば適宜処理を行い、その処理要求４００等を含む通知メッセージ２０１を、ノード間通信部１４１に依頼してフォロワーノードに対して送信する（５１２）。
次に計算機ノード１１０Ａのメッセージ処理部１４２は、タスク通信部１４０から受けた上述の処理要求４００について、メッセージ同期種類を判断する（５１３）。メッセージ処理部１４２は、ステップ５１３で判断したメッセージ同期種類に応じた、フォロワーノードたる計算機ノード１１０Ｂ、１１０Ｃからの承認メッセージ２０２あるいは否認メッセージ２０３の応答待ちを行う（５１４）。この時、計算機ノード１１０Ａのメッセージ処理部１４２は、すべてのフォロワーノードからの応答について受信待ち（メッセージ同期種類＝「同期」）、半数のフォロワーノードからの承認メッセージ２０２について受信待ち（メッセージ同期種類＝「準同期」）といった、メッセージ同期種類に応じた待機を行う。こうした応答待ちの後、メッセージ処理部１４２は、各フォロワーノードより得た該当タスクの処理結果に関して多数決処理を行い、タスク通信部１４０に対して、最終的に一致した結果を処理結果として伝達する（５１５）。タスク通信部１４０は、この結果をアプリケーション１３２に通知する（５１６）。
他方、フォロワーノードたる計算機ノード１１０Ｂの動作について説明する。なお、フォロワーノードである計算機ノード１１０Ｂのタスク通信部１４０の動作は、リーダーノードたる計算機ノード１１０Ａの場合と同様であるので説明を省略する。フォロワーノードたる計算機ノード１１０Ｂのメッセージ処理部１４２は、リーダーノードたる計算機ノード１１０Ａからの通知メッセージ２０１を待つ（５１７）。リーダーノードから通知メッセージ２０１が送信されてきた場合、計算機ノード１１０Ｂのメッセージ処理部１４２は、リーダーノードから受信した通知メッセージ２０１と、自身のタスク通信部１４０でタスク１３３から受けている処理要求の内容とを比較し、リーダーノードの挙動に追従可能（すなわち同じタスクについて処理を同期的に実行可能）かどうかを判断し、追従可能であれば承認メッセージ２０２を、追従不可であれば否認メッセージ２０３をノード間通信部１４１経由でリーダーノードに送信する（５１９）。
以下では、図７の点線で囲んだフローについて、その詳細を述べる。リーダーノードのメッセージ処理部１４２のフロー（５０１）について図８及び図９で、フォロワーノードのメッセージ処理部１４２のフロー（５０２）について図１０でそれぞれ述べる。
図８、図９は第１の実施形態に係るフォールトトレラントシステムにおけるリーダーノードのメッセージ処理部での動作フロー例１、２を示す図であり、具体的には、リーダーノードのメッセージ処理部１４２が、タスク通信部１４０から処理要求を受け、この処理要求に対応する処理を行い、その結果をタスク通信部１４０に返す処理の一例を示したフローチャートである。
この場合、リーダーノードのメッセージ処理部１４２は、まずタスク通信部１４０から処理要求を受け取る（６００）と、外部に影響がある場合、すなわち、外部通信インタフェース１２２からの送信などの場合を除いて、この処理要求に対応する処理を行う（６０１）。このときメッセージ処理部１４２は、必要であれば要求付随データ（図６の付随データ４０６に対応）を生成する。メッセージ処理部１４２は、これをもとに、受信した処理要求を参照する通知メッセージ２０１を生成し、要求付随データがあればそれを加え、全フォロワーノード（計算機ノード１１０Ｂ及び計算機ノード１１０Ｃ）に対してノード間通信部１４１を介して送信する（６０２）。
次にメッセージ処理部１４２は、ＦＴミドルウェア１３１における承認メッセージリスト１５０に、該当通知メッセージ２０１に対応する、すなわち通知参照３００として当該通知メッセージ２０１を含む行を追加する（６０３）。次にメッセージ処理部１４２は、ステップ６００で受けた処理要求について、メッセージ同期種類を判定する（６０４）。
ステップ６０４において、メッセージ処理部１４２は、例えばＦＴミドルウェア１３１におけるメッセージ種類テーブル１５２に対し、上述の処理要求の情報を照合することにより、メッセージ種類テーブル１５２の各レコードのうち、要求種別４００の値が、ステップ６００で受けた処理要求（例：sync,Network_Send,Network_Recv,Lock_Acquire）の値にマッチした行を特定し、該当処理要求のメッセージ同期種類３０４を判断する。但し、既に上述したように、メッセージ同期種類を判断する手法は、メッセージ種類テーブル１５２を用いたこの方法に限定されず、メッセージ同期種類を一つに決定できる方法であればいずれのものも採用できる。
上述のステップ６０４の結果、ステップ６００で受けた処理要求のメッセージ同期種類が「同期」であったとする（６０４：同期）。このとき、リーダーノードのメッセージ処理部１４２は、その時点で動作している全てのフォロワーノードからの応答を、該当処理要求に関する動作の継続に必要とする。すなわちリーダーノードのメッセージ処理部１４２は、全フォロワーノード（計算機ノード１１０Ｂ及び計算機ノード１１０Ｃ）からの承認メッセージ２０２あるいは否認メッセージ２０３を待つ（６０５）。
その後、メッセージ処理部１４２は、承認メッセージ２０２の受信をノード間通信部１４１から通知された（以下、簡単に「受信した」とする）場合（６０６：Ａｃｋ）、承認メッセージリスト１５０の当該行（該当処理要求に関する通知メッセージ２０１に関してステップ６０３で追加した行）において、承認ノード集合３０１に、送信元の計算機ノード１１０（すなわち該当通知メッセージ２０１に対して承認メッセージ２０２を返答したフォロワーノード）の識別情報を追加する（６０７）。
他方、メッセージ処理部１４２は、否認メッセージ２０３をフォロワーノードから受信した場合（６０６：Ｎａｃｋ）、同様に、承認メッセージリスト１５０の当該行において、否認ノード集合３０２に、送信元の計算機ノード１１０（すなわち該当通知メッセージ２０１に対して否認メッセージ２０２を返答したフォロワーノード）の識別情報を追加する（６０８）。
リーダーノードのメッセージ処理部１４２は、全てのフォロワーノードが承認メッセージリスト１５０における承認ノード集合３０１あるいは否認ノード集合３０２のいずれかに入るまで、これを繰り返す（６０９）。これにより、リーダーノードのメッセージ処理部１４２は、該当メッセージ２０１に対応する処理要求を実行する時点まで、すべてのフォロワーノードのタスク１３３が到達したことを確認できる。
ステップ６０９において、全てのフォロワーノードが承認メッセージリスト１５０における承認ノード集合３０１あるいは否認ノード集合３０２のいずれかに入ったと判定したならば（６０９：Ｙｅｓ）、リーダーノードのメッセージ処理部１４２は、同タスクに関する各計算機ノードでの実行結果について、多数決の原理に従って、処理を継続するかどうか判定する（６１０）。承認メッセージ２０２を送信した計算機ノードが否認メッセージより多数、ないしは否認メッセージと同数である場合（６１０：Ｙｅｓ）、リーダーノードのメッセージ処理部１４２は、否認メッセージ２０３を送信したノードを停止させる。これは、リーダーノード自身は当然この通知メッセージ２０１の内容に同意しているためで、承認メッセージ２０２を送信したフォロワーノードと否認メッセージ２０３を送信したフォロワーノードが同数であれば、過半数のノードが同意していることになる。承認メッセージ２０２を送信したノードが多数である場合に、まだ処理要求に対応する処理を実行していない場合には、この時点においては過半数の計算機ノードの同意が得られているため、リーダーノードはこれを実行する（６１１）。最後に、リーダーノードのメッセージ処理部１４２は、ステップ６１１の処理結果を生成して（６１２）、それをタスク通信部１４０に伝達し（６１３）、タスク通信部１４０からの次の処理要求を待つ処理（６００）に戻る。
他方、否認メッセージ２０３を送信したノードのほうが多数である場合には（６１０：Ｎｏ）、リーダーノード自身に障害が発生したとみなせるので、リーダーノードのメッセージ処理部１４２は当該リーダーノード自身の動作を停止するなどの障害時の処理を実行する（６１４）。
一方、上述のステップ６０４の結果、メッセージ同期種類が「準同期」であったとする（６０４：準同期）。このとき、リーダーノードは、その時点で動作しているフォロワーノードのうち過半数からの応答を、該当タスクに関する動作の継続に必要とする。動作は、承認メッセージ２０２や否認メッセージ２０３の受信に関しては、前段の場合と同様であるが（６１６，６１７，６１８，６２０）、条件が異なり、フォロワーノードの半数以上が承認ノード集合３０１に加わるか、全てのフォロワーノードが承認ノード集合３０１あるいは否認ノード集合３０２のいずれかに入るまでこれを繰り返す（６１９）。リーダノード自身は、この決断に当然同意しているので、フォロワーノードの半数以上が承認メッセージ２０２を送信したということは、過半数のノードが応答したということになる。その後の多数決結果の判定処理（６１０）以降の処理は、前段の場合と同様である。なお、リーダーノードが処理を進めた後も、残りのフォロワーノードは、承認メッセージ２０２あるいは否認メッセージ２０３を送信する可能性がある。このために、リーダーノードのメッセージ処理部１４２は、これらを受け取った場合に、該当する承認ノード集合３０１あるいは否認ノード集合３０２に加わる操作を随時行う。否認メッセージ２０３を受信した場合には、これが少数派であることがわかるので、ただちにそのノードを停止させる。
上述した内容は、全てのフォロワーノードが正しく応答をした場合であるが、背景で述べたように、計算機ノード１１０や、ノード間ネットワーク１１２、ノード間通信インタフェース１２３での障害発生等により、フォロワーノードが無応答となる場合、あるいは、応答が著しく遅延する場合がある。この状況下では、上述のフローのうち、メッセージ同期種類が「同期」（６０４：同期）であった際の、リーダーノードのメッセージ処理部１４２が行う受信待ち（６０５）の処理に影響が及ぶ。
ステップ６０２での通知メッセージ２０１の送信時刻から所定時間（以下、タイムアウト時間とする）が経過した場合（６０６：タイムアウト）、リーダーノードのメッセージ処理部１４２は、その時刻までに承認メッセージ２０２もしくは否認メッセージ２０３を送らなかったフォロワーノードで障害が発生したとみなす。そして、リーダーノードのメッセージ処理部１４２は、多数決結果の判定判定（６１０）の処理にうつる。このとき、障害が発生したとみなされたフォロワーノードは、否認ノード集合３０２にあるとみなしてもよいし（６２１）、計算機ノードの全数から取り除いて判断してもよい。
上述のタイムアウト時間としては、最も単純な例では定数値が想定できる。或いは、例えば計算機ノード１１０が、任意のアルゴリズムによってタイムアウト時間を決定するとしてもよい。例えば、上述の通知メッセージ２０１に応じて所定処理を実行する時間を所定アルゴリズムで予測して、フォロワーノードからの承認／否認のいずれかのメッセージの到達期待時間を特定し、これをタイムアウト時間と算出するなどしてもよい。定数を用いた場合であっても、全メッセージのうちメッセージ同期種類が「同期」のものについてのみ、タイムアウト時間を用いた障害判定が行われるため、過半数の計算機ノードが大きな遅延なく動作している場合には、半数未満の、すなわち少数派の計算機ノードで一時的な遅れがあっても、それを吸収することができる。
また、メッセージ同期種類３０４が「同期」となる処理要求の要求パラメータに、実行制約時間を加え、これを基準にタイムアウト時間を定めることもできる。これは、タイムアウト時間を明示的にアプリケーションから制御することで、例えば周期的に実行されるタスクの周期時間というようなアプリケーションの特性に応じた障害判定を行うことが可能になるメリットがある。
メッセージ同期種類３０４が「同期」となる処理要求は、例えば、既知の時間制約のもと一定の時間間隔をおいて同じプログラムを繰り返し実行するタスク（「周期タスク」）での、繰り返し実行する領域の開始点を示す要求であるとか、未知のタイミングで到達する外部からのメッセージ受信、つまり、外部通信インタフェース１２２からのデータ受信の要求などである。メッセージ同期種類３０４が「同期」である二つの連続したメッセージについて、それらに対応する処理要求を発行するタスク１３３の実行箇所への早い方の到達時刻から、遅い方の到達時刻の時間についての時間制約（以下「時間制約」という）が明確である場合に、その時間制約を、いずれかの処理要求の要求パラメータに加える。
この時間制約を用いたステップ６０５におけるタイムアウト処理は、下記の通りになる。リーダーノードのメッセージ処理部１４２は、直前のメッセージ同期種類３０４が「同期」である処理要求の受信時刻から、その要求パラメータに含まれる時間制約、もしくは、現に処理している処理要求の要求パラメータに含まれる時間制約（どちらを用いるかは実装に依存する）だけ経った場合に、タイムアウトとみなす。これ以外のメッセージ同期種類３０４についても、あるいは、フォロワーノードについても、例えば、直前のメッセージ同期種類３０４が「同期」である処理要求の受信時刻から、その要求パラメータに含まれる時間制約を、あるいは、その時間制約を適当な割合で按分した時間をタイムアウト時間として用いることができる。
なお、後述するが、メッセージ種類が「非同期」の時の受信待ちにおいては、別の方法で決められたタイムアウト時間を用いて、障害判定を行ってもよいし、タイムアウトを用いないということもできる。後者では、過半数のノードが応答をしない場合にはリーダーノードはフォロワーノードからの承認／否認メッセージを無限に待つことになるが、そもそも過半数のノードが無応答である場合には、ＦＴシステム１として動作を継続できない状態であって、停止させられるべき状態であり、可用性の点ではこれを大きく損なうものではない。
続いて、フォロワーノードのメッセージ処理部１４２における処理について説明する。図１０は第１の実施形態に係るＦＴシステム１におけるフォロワーノードのメッセージ処理部１４２での動作フロー例を示す図であり、具体的には、フォロワーノードのメッセージ処理部１４２が、タスク通信部１４０から処理要求を受けて対応する処理を行い、その結果をタスク通信部１４０に返す処理の一例を示したフローチャートである。
この場合、フォロワーノードのメッセージ処理部１４２は、まず当該フォロワーノードにおけるタスク通信部１４０からの処理要求、またはノード間通信部１４１からのメッセージを待つ（７００）。ここで、フォロワーノードのメッセージ処理部１４２は、タスク通信部１４０から処理要求を受け取った場合（７０１：Ｙｅｓ）、通知メッセージリスト１５１を確認し、タスク通信部１４０から受けた処理要求に対応する通知メッセージ２０１がリーダーから到着しているかどうか確認する（７０２）。
リーダーノードから対応する通知メッセージ２０１が到着している場合（７０２：Ｙｅｓ）、フォロワーノードのメッセージ処理部１４２は、通知メッセージ２０１の参照する処理要求を、タスク通信部１４０から受け取った処理要求と比較する（７０３）。ここでの比較処理は、タスク通信部１４０から得た処理要求と通知メッセージ２０１が含んでいた処理要求の互いの識別情報や付随データ等の一致判定など、二つの処理要求に応じた処理の結果が同一であると判定するのに十分な処理であればよい。
このステップ７０３の結果、通知メッセージ２０１の参照する処理要求と、タスク通信部１４０から受け取った処理要求が同一であると判定したならば（７０３：ＹＥＳ）、フォロワーノードのメッセージ処理部１４２は、リーダーノードに対する承認メッセージ２０２の送信をノード間通信部１４１を通じて行う（７０４）。
また、フォロワーノードのメッセージ処理部１４２は、該当通知メッセージ２０１をもとに、必要であれば対応する所定処理を実行して（７０５）、処理結果を生成し（７０６）、これをタスク通信部１４０に対して伝達する（７０７）。
他方、上述のステップ７０３の結果、通知メッセージ２０１の参照する処理要求と、タスク通信部１４０から受け取った処理要求が同一でないと判定したならば（７０３：Ｎｏ）、フォロワーノードのメッセージ処理部１４２は、リーダーノードに対する否認メッセージ２０３の送信をノード間通信部１４１を通じて行う（７０８）。なお、このときフォロワーの立場からはリーダーノードの挙動が異常とみなせるので、フォロワーノードのメッセージ処理部１４２は、リーダーノードの再選出等の提案を他の計算機ノード各々に行うなど、障害発生時の処理を行う（７１１）。
上述のステップ７０１にてタスク通信部１４０からの処理要求を受け取った時点で、リーダーノードからの処理要求が到着していない場合（７０２：Ｎｏ）、フォロワーノードのメッセージ処理部１４２は、リーダーノードからの処理要求の到着を待つこととなる（７０９）。リーダーノードからの処理要求を受信した場合（７１０：Ｎｏ）、フォロワーノードのメッセージ処理部１４２は、リーダーノードからの処理要求が既に通知メッセージリスト１５１に存在していた場合（７０２：Ｙｅｓ）と同じ処理に進む。
他方、リーダーノードの場合と同様に、フォロワーノードにおいて、リーダーノードもしくはノード間通信インタフェース１２３の障害等により、リーダーノードからの通知メッセージ２０１が著しく遅延するか、あるいは、これを受信できないことがある。このため、フォロワーノードのメッセージ処理部１４２は、ステップ７０９の待ちにおいて、処理要求の受信時刻からある時間（以下、タイムアウト時間という）が経過しても、リーダーノードから相当する通知メッセージ２０１を受信しなかった時は、リーダーノードあるいはそのノード間通信インタフェース１２３において障害が発生したとみなす（７１０：Ｙｅｓ）。そして、ステップ７０３で、通知メッセージ２０１の参照する処理要求と、タスク通信部１４０から受け取った処理要求とが同一でないと判定された場合と同様に、リーダーノードの再選出提案などの障害発生時の処理を行う（７１１）。
なお、ステップ７０１において、フォロワーノードのメッセージ処理部１４２が、ノード間通信部１４１から通知メッセージ２０１を受け取った場合（７０１：Ｎｏ）、当該通知メッセージ２０１に対応する処理要求は、タスク通信部１４０から未だ受信していないため、後の処理のために、該当通知メッセージ２０１の情報を通知メッセージリスト１５１に格納する（７１２）。その後、フォロワーノードのメッセージ処理部１４２は、処理要求もしくは通知メッセージ２０１の受信待ち（７００）の処理に戻る。
以上の第１の実施形態を採用することで、多数決冗長構成を成すリーダーノードとフォロワーノードの動作を同一に保ちつつ、リーダーノードでのタイムアウト判定（フォロワーノードからの承認／否認メッセージの受信待ち期限の判定）を同期メッセージに関するもののみに減らすことにより、少数のフォロワーノードの一時的な処理や伝送の遅延を許容することができる。
また、メッセージ種類テーブル１５２を使用したメッセージ同期種類の判定を行うことによって、例えば、同期を行うための同期要求を発行するＡＰＩをタスク通信部１４０が提供することにより、アプリケーション１３２が同期するタイミングを制御できるようになり、アプリケーション１３２の特性に一致したタイムアウト判定の制御を実現することができる。
なお、以上の説明では、タスク１３３が単一の場合を述べたが、複数ある場合も同様である。ただし、タスク通信部１４０およびメッセージ処理部１４２の処理は、タスクごとにスレッド化を行うなどの並列化を行うか、あるいは、入出力待ちの多重化処理を加えることによって、一つのタスク１３３に対する処理要求の処理によって、他のタスク１３３が滞らないようにする必要がある。
また、タスク通信部１４０からの処理要求の受け取りとノード間通信部１４１からの通知メッセージ２０１の受け取りを単一の流れとして記述したが、効率化のために複数のスレッド等を用いることによって、それぞれを並列的に実行しても構わない。
−−−第２の実施形態−−−
計算機ノードのメッセージ処理部１４２が要求リストを用いて処理を行う形態も想定できる。この要求リストとは、メッセージ処理部１４２が、他の計算機ノードから通知メッセージ２０１を受け取った際に、それに対して承認メッセージ２０２を返すか否認メッセージ２０３を返すかを選択するためのテーブルである。そのため要求リストは、返信するメッセージを承認／否認メッセージのいずれにするか判断するための十分なデータ、例えば、処理要求や要求付随データの各値を持つ。
こうした形態を第２の実施例として説明する。なお、第２の実施形態におけるＦＴシステム１は図１と同様の構成である。第２の実施形態におけるフォロワーノードの挙動は、図１１に示すフローに沿ったものとなる。これ以外の動作と構成は、第１の実施形態と同様であるため、重複箇所の説明については省略する。
図１１、図１２は第２の実施形態におけるフォールトトレラントシステムのフォロワーノードのメッセージ処理部での動作フロー例１、例２を示す図である。ここでの第１の実施形態との大きな違いは、タスク通信部１４０で得た処理要求に対する処理を、リーダーノードからの通知メッセージ２０１の到着を待たずに進行させる点となる。
第２の実施形態におけるフォロワーノードのメッセージ処理部１４２は、タスク通信部１４０からの処理要求、またはノード間通信部１４１からの通知メッセージの伝達を待つ（８００）。例えば、タスク通信部１４０から処理要求を受け取った場合（８０１：Ｙｅｓ）、フォロワーノードのメッセージ処理部１４２は、通知メッセージリスト１５１を確認し、対応する通知メッセージ２０１がリーダーノードから到着しているかどうか確認する（８０２）。
ステップ８０２の結果、タスク通信部１４０から得た処理要求に対応する通知メッセージ２０１が既に到着していると判定した場合（８０２：Ｙｅｓ）、フォロワーノードのメッセージ処理部１４２は、第１の実施形態と同様の処理を実行する（８０３〜８１０）。該当処理は第１の実施形態と同様であるので説明は省略する。
他方、ステップ８０２の結果、タスク通信部１４０から得た処理要求に対応する通知メッセージ２０１が到着していないと判定した場合（８０２：Ｎｏ）、フォロワーノードのメッセージ処理部１４２は、該当処理要求に対応する処理を行う（８０６）。ただし、外部通信インタフェース１２２からの送信などの、外部に対して影響を与える処理の場合には、実際にはその処理を行わずに、その想定される結果のみ計算する。また、フォロワーノードのメッセージ処理部１４２は、上述した要求リストに対して、処理要求に関する情報と、その処理の結果などを含む要求付随データを付け加える（８０７）。こうしてレコードが生成された要求リストは、図６に示した通知メッセージ２０１の処理要求４００および付随データ４０６と同様形式のデータを含むレコードの集合体となる。
フォロワーノードのメッセージ処理部１４２は、上述のステップ８０６の結果から処理結果を生成し（８０９）、当該処理結果をタスク通信部１４０に伝達する（８１０）。その後、フォロワーノードのメッセージ処理部１４２は、タスク通信部１４０とノード間通信部１４１からの伝達待ちに戻る（８００）。
一方、ステップ８００において、ノード間通信部１４１から通知メッセージ２０１を受け取った場合（８０１：Ｎｏ）、フォロワーノードのメッセージ処理部１４２は、要求リストを確認し、通知メッセージ２０１のもつ処理要求参照に対応する処理要求があるかどうか確認する（８１１）。この確認処理の結果、ノード間通信部１４１から受け取った通知メッセージ２０１に対応する処理要求が、要求リスト中に存在すると判定した場合（８１１：Ｙｅｓ）、フォロワーノードのメッセージ処理部１４２は、タスク通信部１４０から得た通知メッセージ２０１と、要求リストに含まれていた該当処理要求とを比較する （８１２）。この比較の処理は、図１０のステップ７０３に関して上述したものと同様である。
こうした比較処理の結果、通知メッセージ２０１の参照する処理要求と、タスク通信部１４０から受け取った処理要求とが同一であるとみなされた場合（８１２：Ｙｅｓ）、フォロワーノードのメッセージ処理部１４２は、承認メッセージ２０２をリーダーノードに送信する（８１３）。他方、通知メッセージ２０１の参照する処理要求と、タスク通信部１４０から受け取った処理要求とが同一でなかったとみなされた場合（８１２：ＮＯ）、フォロワーノードのメッセージ処理部１４２は、否認メッセージ２０３をリーダーノードに送信し（８１４）、リーダーノードに関する障害時処理を行う（８１５）。なお、上述のステップ８１１において、対応する処理要求が要求リスト中に無かった場合、フォロワーノードのメッセージ処理部１４２は、該当通知メッセージ２０１の情報を通知メッセージリスト１５１に追加する（８１６）。
以上の処理により、フォロワーノードは、リーダーノードからの通知メッセージを待つことなく、タスクに関する処理を各々進めることができるため、処理時間の遅延を短縮することができる。ただし、この場合のフォロワーノードは、リーダーノードでの結果を使わずに処理を進めるため、処理内容の相違が発生する確率が高くなる。そのためフォロワーノードは、一部の処理については、リーダーノードからの通知メッセージを待ち、その他の処理については、待たずに進めるといった、本実施例の部分的な適用も可能である。こうした部分的な適用をする際のフォロワーノードにおける判断には、メッセージ同期種類を用いることもできる。例えば、メッセージ同期種類が「同期」あるいは「準同期」のものについてはリーダーノードからの通知メッセージを待ち、次の実施例で述べるメッセージ同期種類が「非同期」の場合については、リーダーノードからの通知メッセージを待たないとするアルゴリズムである。
−−−第３の実施形態−−−
上述の第１および第２の実施形態では、メッセージ同期種類が「同期」、「準同期」のいずれかの場合について選択的に処理を行う例を示した。ここでは、これら同機種類に加えて、メッセージ同期種類が「非同期」の場合についても想定した例を示すものとする。図１３は第３の実施形態におけるＦＴシステム１のリーダーノードのメッセージ処理部１４２での動作フロー例を示す図であり、図８のフローに対する差分のみを示したフローチャートである。従って、第１の実施例と同様の構成と処理については説明を省略する。
ここで、リーダーノードのメッセージ処理部１４２は、タスク通信部１４０からの処理要求の伝達、もしくはノード間通信部１４１からの通知メッセージ２０１の受信を待つ（１０００）。待機中、タスク通信部１４０から処理要求を受け取った場合（１００１：Ｙｅｓ）、リーダーノードのメッセージ処理部１４２は、図８のフローにおけるステップ６０１〜６０３を同様に実行した後、メッセージ同期種類を判定する（１００２）。メッセージ同期種類が「同期」であった場合及び「準同期」であった場合の処理は、第１の実施形態で示した場合と同様である。
他方、メッセージ同期種類が「非同期」であった場合（１００２：非同期）、リーダーノードのメッセージ処理部１４２は、フォロワーノードからの承認／否認メッセージを待つことなく、図８のフローにおけるステップ６１１に進む。なお、十分な数の承認／否認メッセージをフォロワーノードから既に受信していた場合、リーダーノードのメッセージ処理部１４２は、この時点で「準同期」の場合と同様に多数決処理（図８のステップ６１０）を行なってもよい。他方、多数決処理をしない場合は、タスク通信部１４０に対して結果を返した後に多数決処理を行う必要があるが、その場合、ノード間通信部１４１から通知メッセージ２０１を受信した場合（１００１：Ｎｏ）に実行する。
リーダーノードのメッセージ処理部１４２は、ノード間通信部１４１から通知メッセージ２０１を受信したとき（１００１：Ｎｏ）、それが承認メッセージ２０２であれば（１００３：Ａｃｋ）、それに対応する承認メッセージリスト１５０の行の承認ノード集合３０１に、その送信元のフォロワーノードの情報を加える（１００４）。他方、否認メッセージ２０３であれば（１００３：Ｎａｃｋ）、リーダーノードのメッセージ処理部１４２は、否認ノード集合３０２に送信元のフォロワーノードの情報を加える（１００５）。この行に関して、承認ノード集合３０１あるいは否認ノード集合３０２にまだ入っていないフォロワーノードが存在する場合（１００６：Ｎｏ）、リーダーノードのメッセージ処理部１４２は受信待ちに戻る（１０００）。すべてのフォロワーノードから承認／否認メッセージを受信した場合（１００６：Ｙｅｓ）、リーダーノードのメッセージ処理部１４２は、多数決処理にうつる。この時、否認メッセージ２０３が多数の場合（１００７：Ｎｏ）、リーダーノードのメッセージ処理部１４２は、当該リーダーノードに関する障害時処理を行う。
他方、承認メッセージ２０２が多数の場合（１００７：Ｙｅｓ）、リーダーノードのメッセージ処理部１４２は、承認メッセージリスト１５０の当該行の削除などを行い（１００９）、受信待ち（１０００）に戻る。この時、リーダーノードのメッセージ処理部１４２は、必要に応じて否認メッセージ２０３を送ったフォロワーノードを停止させる処理等を行なってもよい。
また、十分な数の承認／否認メッセージをフォロワーノードから既に受信していた場合、リーダーノードのメッセージ処理部１４２は、ステップ１００６から多数決処理（１００７）へ処理を移すとしてもよい。
以上の実施形態により、第１の実施形態の場合と比べて、リーダーノードがフォロワーノードからの承認／否認メッセージを待つ回数を低減することができるため、個々の計算機ノードの遅れをより効率的かつ適切に許容することが可能になる。
−−−第４の実施形態−−−
ここでは、メッセージ同期種類が「同期」、「非同期」の２種である場合について想定した例を示すものとする。図１４は第４の実施形態におけるＦＴシステム１のリーダーノードのメッセージ処理部１４２での動作フロー例を示す図であり、図８のフローに対する差分のみを示したフローチャートである。従って、第１の実施例と同様の構成と処理については説明を省略する。また、第３の実施形態と同様の構成と処理についても説明を省略する。
ここで、リーダーノードのメッセージ処理部１４２は、タスク通信部１４０からの処理要求の伝達、もしくはノード間通信部１４１からの通知メッセージ２０１の受信を待つ（１１００）。待機中、タスク通信部１４０から処理要求を受け取った場合（１１０１：Ｙｅｓ）、リーダーノードのメッセージ処理部１４２は、図８のフローにおけるステップ６０１〜６０３を同様に実行した後、メッセージ同期種類を判定する（１１０２）。メッセージ同期種類が「同期」であった場合の処理は、第１の実施形態で示した場合と同様である（図８のフローにおけるステップ６０５へ）。
他方、メッセージ同期種類が「非同期」であった場合（１１０２：非同期）、リーダーノードのメッセージ処理部１４２は、フォロワーノードからの承認／否認メッセージを待つことなく、図８のフローにおけるステップ６１１に進む。なお、十分な数の承認／否認メッセージをフォロワーノードから既に受信していた場合、リーダーノードのメッセージ処理部１４２は、この時点で「準同期」の場合と同様に多数決処理（図８のステップ６１０）を行なってもよい。他方、多数決処理をしない場合は、タスク通信部１４０に対して結果を返した後に多数決処理を行う必要があるが、その場合、ノード間通信部１４１から通知メッセージ２０１を受信した場合（１１０１：Ｎｏ）に実行する。また、ステップ１１０１において、ノード間通信部１４１から通知メッセージ２０１を受信したとき（１００１：Ｎｏ）、以降の処理（１１０３〜１１０９）については、第３の実施形態と同様である。
以上の実施形態により、第１の実施形態の場合と比べて、リーダーノードがフォロワーノードからの承認／否認メッセージを待つ回数を低減することができるため、個々の計算機ノードの遅れをより効率的かつ適切に許容することが可能になる。
以上、本発明を実施するための最良の形態などについて具体的に説明したが、本発明はこれに限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能である。
こうした本実施形態によれば、フォールトトレラントシステムにおいて、計算機ノード間の同期のためのメッセージを分類し、その種類に応じて、一部のメッセージでのみ多数決投票の結果を待ち、そうでない場合には非同期的に実行するといった多数決投票の挙動変更を実行して、計算機ノード間での処理の待ち合わせ回数を低減し、以って計算機ノード間での性能ばらつきの影響を相対的に抑制可能となる。そうした効果は、システム全体における処理の遅延や効率低下を軽減できることにもつながる。また、障害判定を行うにあたり、アプリケーションの制約から明確である時間を障害判定の基準として用い、かつ、その基準点とメッセージ種類を一致させることにより、性能差を許容しつつ、過度な障害判定による可用性の低減を防止することも出来る。
したがって、アーキテクチャや基盤ソフトウェア等が互いに異なる複数の計算機ノードで構成されたフォールトトレラントシステムにおいて、計算機ノード間の性能差やばらつきによる全体性能の影響を低減し、またこうした影響に起因する過度な障害判定を防止することにより、システムにおける可用性が向上可能となる。
本明細書の記載により、少なくとも次のことが明らかにされる。すなわち、フォールトトレラントシステムにおいて、前記他計算機となった計算機のメッセージ処理部は、当該他計算機のタスク通信部が得ている処理内容を所定基準に照合し、該当処理内容が同期または準同期のいずれかに対応したものであるか判定し、前記処理内容が同期に対応するものであった場合、当該他計算機以外の計算機の全てを対象として、前記追従可否のメッセージの受信待ちを実行し、前記処理内容が準同期に対応するものであった場合、当該他計算機以外の計算機のうち少なくとも半数以上の計算機を対象として、前記追従可否のメッセージの受信待ちを実行するものである、としてもよい。
こうして、各計算機が並行して実行すべき同一タスクの種類、すなわち同期、準同期の必要性有無に応じて、フォールトトレラントシステムにおけるリーダーたる計算機での、該当タスクに関する追従可否のメッセージ受信を待ち受けるべきフォロワー計算機の数をコントロールする。これにより、上述のメッセージを待ち受けるべき時間を必要性に応じて選択的に増減して、計算機間の性能差やばらつきによる上述のメッセージの到着時間差を適宜吸収し、ひいては過度な障害判定の防止や、システムにおける可用性向上が可能となる。
また、フォールトトレラントシステムにおいて、前記他計算機となった計算機のメッセージ処理部は、当該他計算機のタスク通信部が得ている処理内容を所定基準に照合し、該当処理内容が同期、準同期、および非同期のいずれかに対応したものであるか判定し、前記処理内容が同期に対応するものであった場合、当該他計算機以外の計算機の全てを対象として、前記追従可否のメッセージの受信待ちを実行し、前記処理内容が準同期に対応するものであった場合、当該他計算機以外の計算機のうち少なくとも半数以上の計算機を対象として、前記追従可否のメッセージの受信待ちを実行し、前記処理内容が非同期に対応するものであった場合、当該他計算機以外の計算機からの前記追従可否のメッセージの受信待ちを実行しないものである、としてもよい。
こうして、各計算機が並行して実行すべき同一タスクの種類、すなわち同期、準同期、非同期の必要性有無に応じて、フォールトトレラントシステムにおけるリーダーたる計算機での、該当タスクに関する追従可否のメッセージ受信を待ち受けるべきフォロワー計算機の数をコントロールする。これにより、上述のメッセージを待ち受けるべき時間を必要性に応じて選択的に増減して、計算機間の性能差やばらつきによる上述のメッセージの到着時間差を適宜吸収し、ひいては過度な障害判定の防止や、システムにおける可用性向上が可能となる。特に、該当タスクが各計算機間で非同期で処理されるものである場合、リーダーたる計算機において、フォロワー計算機からの上述のメッセージの受信待ちが不要となり、障害判定に要する各計算機の使用リソースを効率化し、ひいてはシステムにおける更なる可用性向上が可能となる。
また、フォールトトレラントシステムにおいて、前記他計算機となった計算機のメッセージ処理部は、当該他計算機のタスク通信部が得ている処理内容を所定基準に照合し、該当処理内容が同期または非同期のいずれかに対応したものであるか判定し、前記処理内容が同期に対応するものであった場合、当該他計算機以外の計算機の全てを対象として、前記追従可否のメッセージの受信待ちを実行し、前記処理内容が非同期に対応するものであった場合、当該他計算機以外の計算機からの前記追従可否のメッセージの受信待ちを実行しないものである、としてもよい。
こうして、各計算機が並行して実行すべき同一タスクの種類、すなわち同期、非同期の必要性有無に応じて、フォールトトレラントシステムにおけるリーダーたる計算機での、該当タスクに関する追従可否のメッセージ受信を待ち受けるべきフォロワー計算機の数をコントロールする。これにより、上述のメッセージを待ち受けるべき時間を必要性に応じて選択的に増減して、計算機間の性能差やばらつきによる上述のメッセージの到着時間差を適宜吸収し、ひいては過度な障害判定の防止や、システムにおける可用性向上が可能となる。特に、該当タスクが各計算機間で非同期で処理されるものである場合、リーダーたる計算機において、フォロワー計算機からの上述のメッセージの受信待ちが不要となり、障害判定に要する各計算機の使用リソースを効率化し、ひいてはシステムにおける更なる可用性向上が可能となる。
また、フォールトトレラント制御方法において、前記他計算機となった計算機のメッセージ処理部が、当該他計算機のタスク通信部が得ている処理内容を所定基準に照合し、該当処理内容が同期または準同期のいずれかに対応したものであるか判定し、前記処理内容が同期に対応するものであった場合、当該他計算機以外の計算機の全てを対象として、前記追従可否のメッセージの受信待ちを実行し、前記処理内容が準同期に対応するものであった場合、当該他計算機以外の計算機のうち少なくとも半数以上の計算機を対象として、前記追従可否のメッセージの受信待ちを実行する、としてもよい。
こうして、各計算機が並行して実行すべき同一タスクの種類、すなわち同期、準同期の必要性有無に応じて、フォールトトレラントシステムにおけるリーダーたる計算機での、該当タスクに関する追従可否のメッセージ受信を待ち受けるべきフォロワー計算機の数をコントロールする。これにより、上述のメッセージを待ち受けるべき時間を必要性に応じて選択的に増減して、計算機間の性能差やばらつきによる上述のメッセージの到着時間差を適宜吸収し、ひいては過度な障害判定の防止や、システムにおける可用性向上が可能となる。
また、フォールトトレラント制御方法において、前記他計算機となった計算機のメッセージ処理部が、当該他計算機のタスク通信部が得ている処理内容を所定基準に照合し、該当処理内容が同期、準同期、および非同期のいずれかに対応したものであるか判定し、前記処理内容が同期に対応するものであった場合、当該他計算機以外の計算機の全てを対象として、前記追従可否のメッセージの受信待ちを実行し、前記処理内容が準同期に対応するものであった場合、当該他計算機以外の計算機のうち少なくとも半数以上の計算機を対象として、前記追従可否のメッセージの受信待ちを実行し、前記処理内容が非同期に対応するものであった場合、当該他計算機以外の計算機からの前記追従可否のメッセージの受信待ちを実行しない、としてもよい。
こうして、各計算機が並行して実行すべき同一タスクの種類、すなわち同期、準同期、非同期の必要性有無に応じて、フォールトトレラントシステムにおけるリーダーたる計算機での、該当タスクに関する追従可否のメッセージ受信を待ち受けるべきフォロワー計算機の数をコントロールする。これにより、上述のメッセージを待ち受けるべき時間を必要性に応じて選択的に増減して、計算機間の性能差やばらつきによる上述のメッセージの到着時間差を適宜吸収し、ひいては過度な障害判定の防止や、システムにおける可用性向上が可能となる。特に、該当タスクが各計算機間で非同期で処理されるものである場合、リーダーたる計算機において、フォロワー計算機からの上述のメッセージの受信待ちが不要となり、障害判定に要する各計算機の使用リソースを効率化し、ひいてはシステムにおける更なる可用性向上が可能となる。
また、フォールトトレラント制御方法において、前記他計算機となった計算機のメッセージ処理部が、当該他計算機のタスク通信部が得ている処理内容を所定基準に照合し、該当処理内容が同期または非同期のいずれかに対応したものであるか判定し、前記処理内容が同期に対応するものであった場合、当該他計算機以外の計算機の全てを対象として、前記追従可否のメッセージの受信待ちを実行し、前記処理内容が非同期に対応するものであった場合、当該他計算機以外の計算機からの前記追従可否のメッセージの受信待ちを実行しない、としてもよい。
こうして、各計算機が並行して実行すべき同一タスクの種類、すなわち同期、非同期の必要性有無に応じて、フォールトトレラントシステムにおけるリーダーたる計算機での、該当タスクに関する追従可否のメッセージ受信を待ち受けるべきフォロワー計算機の数をコントロールする。これにより、上述のメッセージを待ち受けるべき時間を必要性に応じて選択的に増減して、計算機間の性能差やばらつきによる上述のメッセージの到着時間差を適宜吸収し、ひいては過度な障害判定の防止や、システムにおける可用性向上が可能となる。特に、該当タスクが各計算機間で非同期で処理されるものである場合、リーダーたる計算機において、フォロワー計算機からの上述のメッセージの受信待ちが不要となり、障害判定に要する各計算機の使用リソースを効率化し、ひいてはシステムにおける更なる可用性向上が可能となる。
１ フォールトトレラントシステム
１０２ 端末
１１０ 計算機ノード（計算機）
１１０Ａ リーダーノード
１１０Ｂ、１１０Ｃ フォロワーノード
１１１ 外部ネットワーク
１１２ ノード間ネットワーク
１２０ 中央演算装置
１２１ 主記憶装置
１２２ 外部通信インタフェース
１２３ ノード間通信インタフェース
１２４ 補助記憶装置
１３０ 基本ソフトウェア
１３１ ＦＴミドルウェア
１３２ アプリケーション
１３３ タスク
１４０ タスク通信部
１４１ ノード間通信部
１４２ メッセージ処理部
１５０ 承認メッセージリスト
１５１ 通知メッセージリスト
１５２ メッセージ種類テーブル

Claims (8)

  1. 多数決冗長構成を形成する複数の計算機各々において、
    当該計算機の内部で動作するプログラムからその処理内容を取得するタスク通信部と、
    前記多数決冗長構成を形成するいずれかの他計算機より、前記他計算機で動作するプログラムの処理内容を示す所定メッセージを受信し、前記所定メッセージが示す処理内容と前記タスク通信部が得ている前記処理内容との一致判定の結果に応じ、前記他計算機に追従可否のメッセージを返信するメッセージ処理部とを備えており、
    前記他計算機となった計算機のメッセージ処理部は、当該他計算機のタスク通信部が得ている処理内容に応じて、前記追従可否のメッセージの受信待ち対象とする、当該他計算機以外の計算機の数を変更する処理を更に実行するものである、
    ことを特徴とするフォールトトレラントシステム。
  2. 前記他計算機となった計算機のメッセージ処理部は、
    当該他計算機のタスク通信部が得ている処理内容を所定基準に照合し、該当処理内容が同期または準同期のいずれかに対応したものであるか判定し、前記処理内容が同期に対応するものであった場合、当該他計算機以外の計算機の全てを対象として、前記追従可否のメッセージの受信待ちを実行し、前記処理内容が準同期に対応するものであった場合、当該他計算機以外の計算機のうち少なくとも半数以上の計算機を対象として、前記追従可否のメッセージの受信待ちを実行するものである、
    ことを特徴とする請求項１に記載のフォールトトレラントシステム。
  3. 前記他計算機となった計算機のメッセージ処理部は、
    当該他計算機のタスク通信部が得ている処理内容を所定基準に照合し、該当処理内容が同期、準同期、および非同期のいずれかに対応したものであるか判定し、前記処理内容が同期に対応するものであった場合、当該他計算機以外の計算機の全てを対象として、前記追従可否のメッセージの受信待ちを実行し、前記処理内容が準同期に対応するものであった場合、当該他計算機以外の計算機のうち少なくとも半数以上の計算機を対象として、前記追従可否のメッセージの受信待ちを実行し、前記処理内容が非同期に対応するものであった場合、当該他計算機以外の計算機からの前記追従可否のメッセージの受信待ちを実行しないものである、
    ことを特徴とする請求項１に記載のフォールトトレラントシステム。
  4. 前記他計算機となった計算機のメッセージ処理部は、
    当該他計算機のタスク通信部が得ている処理内容を所定基準に照合し、該当処理内容が同期または非同期のいずれかに対応したものであるか判定し、前記処理内容が同期に対応するものであった場合、当該他計算機以外の計算機の全てを対象として、前記追従可否のメッセージの受信待ちを実行し、前記処理内容が非同期に対応するものであった場合、当該他計算機以外の計算機からの前記追従可否のメッセージの受信待ちを実行しないものである、
    ことを特徴とする請求項１に記載のフォールトトレラントシステム。
  5. 多数決冗長構成を形成する複数の計算機各々において、
    当該計算機の内部で動作するプログラムからその処理内容を取得する処理と、
    前記多数決冗長構成を形成するいずれかの他計算機より、前記他計算機で動作するプログラムの処理内容を示す所定メッセージを受信し、前記所定メッセージが示す処理内容と前記処理で得ている前記処理内容との一致判定の結果に応じ、前記他計算機に追従可否のメッセージを返信する処理とを実行し、
    更に、前記他計算機においては、当該他計算機で動作するプログラムから得ている処理内容に応じて、前記追従可否のメッセージの受信待ち対象とする、当該他計算機以外の計算機の数を変更する処理を更に実行する、
    ことを特徴とするフォールトトレラントシステム制御方法。
  6. 前記他計算機となった計算機のメッセージ処理部が、
    当該他計算機のタスク通信部が得ている処理内容を所定基準に照合し、該当処理内容が同期または準同期のいずれかに対応したものであるか判定し、前記処理内容が同期に対応するものであった場合、当該他計算機以外の計算機の全てを対象として、前記追従可否のメッセージの受信待ちを実行し、前記処理内容が準同期に対応するものであった場合、当該他計算機以外の計算機のうち少なくとも半数以上の計算機を対象として、前記追従可否のメッセージの受信待ちを実行する、
    ことを特徴とする請求項５に記載のフォールトトレラントシステム制御方法。
  7. 前記他計算機となった計算機のメッセージ処理部が、
    当該他計算機のタスク通信部が得ている処理内容を所定基準に照合し、該当処理内容が同期、準同期、および非同期のいずれかに対応したものであるか判定し、前記処理内容が同期に対応するものであった場合、当該他計算機以外の計算機の全てを対象として、前記追従可否のメッセージの受信待ちを実行し、前記処理内容が準同期に対応するものであった場合、当該他計算機以外の計算機のうち少なくとも半数以上の計算機を対象として、前記追従可否のメッセージの受信待ちを実行し、前記処理内容が非同期に対応するものであった場合、当該他計算機以外の計算機からの前記追従可否のメッセージの受信待ちを実行しない、
    ことを特徴とする請求項５に記載のフォールトトレラントシステム制御方法。
  8. 前記他計算機となった計算機のメッセージ処理部が、
    当該他計算機のタスク通信部が得ている処理内容を所定基準に照合し、該当処理内容が同期または非同期のいずれかに対応したものであるか判定し、前記処理内容が同期に対応するものであった場合、当該他計算機以外の計算機の全てを対象として、前記追従可否のメッセージの受信待ちを実行し、前記処理内容が非同期に対応するものであった場合、当該他計算機以外の計算機からの前記追従可否のメッセージの受信待ちを実行しない、
    ことを特徴とする請求項５に記載のフォールトトレラントシステム制御方法。
JP2013199614A 2013-09-26 2013-09-26 フォールトトレラントシステム及びフォールトトレラントシステム制御方法 Expired - Fee Related JP6100135B2 (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
JP2013199614A JP6100135B2 (ja) 2013-09-26 2013-09-26 フォールトトレラントシステム及びフォールトトレラントシステム制御方法
PCT/JP2014/069305 WO2015045589A1 (ja) 2013-09-26 2014-07-22 フォールトトレラントシステム及びフォールトトレラントシステム制御方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2013199614A JP6100135B2 (ja) 2013-09-26 2013-09-26 フォールトトレラントシステム及びフォールトトレラントシステム制御方法

Publications (2)

Publication Number Publication Date
JP2015064833A JP2015064833A (ja) 2015-04-09
JP6100135B2 true JP6100135B2 (ja) 2017-03-22

Family

ID=52742746

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2013199614A Expired - Fee Related JP6100135B2 (ja) 2013-09-26 2013-09-26 フォールトトレラントシステム及びフォールトトレラントシステム制御方法

Country Status (2)

Country Link
JP (1) JP6100135B2 (ja)
WO (1) WO2015045589A1 (ja)

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4342083A (en) * 1980-02-05 1982-07-27 The Bendix Corporation Communication system for a multiple-computer system
JP4457581B2 (ja) * 2003-05-28 2010-04-28 日本電気株式会社 耐障害システム、プログラム並列実行方法、耐障害システムの障害検出装置およびプログラム
WO2012032572A1 (ja) * 2010-09-08 2012-03-15 株式会社日立製作所 計算機
US9942107B2 (en) * 2010-10-25 2018-04-10 Hitachi, Ltd. Computer system including plural computer nodes synchronized with each other
JP5416863B2 (ja) * 2011-03-23 2014-02-12 株式会社日立製作所 計算機システム、データ処理方法、及びデータ処理プログラム

Also Published As

Publication number Publication date
JP2015064833A (ja) 2015-04-09
WO2015045589A1 (ja) 2015-04-02

Similar Documents

Publication Publication Date Title
US20220239602A1 (en) Scalable leadership election in a multi-processing computing environment
US9934242B2 (en) Replication of data between mirrored data sites
CN107832138B (zh) 一种扁平化的高可用namenode模型的实现方法
US8117156B2 (en) Replication for common availability substrate
JP6353086B2 (ja) マルチアイテムトランザクションサポートを有するマルチデータベースログ
WO2016070375A1 (zh) 一种分布式存储复制***和方法
US7865763B2 (en) Data replication method
CN111368002A (zh) 一种数据处理方法、***、计算机设备和存储介质
US9917884B2 (en) File transmission method, apparatus, and distributed cluster file system
JP6225262B2 (ja) 分散データグリッドにおいてデータを同期させるためにパーティションレベルジャーナリングをサポートするためのシステムおよび方法
JP5548829B2 (ja) 計算機システム、データ管理方法及びデータ管理プログラム
CN105069152B (zh) 数据处理方法及装置
CN109739435B (zh) 文件存储和更新方法及装置
EP4213038A1 (en) Data processing method and apparatus based on distributed storage, device, and medium
WO2020024615A1 (zh) 一种共识流程恢复方法及相关节点
CN113010496A (zh) 一种数据迁移方法、装置、设备和存储介质
CN115794499B (zh) 一种用于分布式块存储集群间双活复制数据的方法和***
CN112052230A (zh) 多机房数据同步方法、计算设备及存储介质
WO2022238345A1 (en) Data synchronization in edge computing networks
JP4612714B2 (ja) データ処理方法、クラスタシステム、及びデータ処理プログラム
CN109347906B (zh) 一种数据传输方法、装置、与服务器
WO2015196692A1 (zh) 一种云计算***以及云计算***的处理方法和装置
JP5707409B2 (ja) 計算機
JP6100135B2 (ja) フォールトトレラントシステム及びフォールトトレラントシステム制御方法
Lin et al. An optimized multi-Paxos protocol with centralized failover mechanism for cloud storage applications

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20160405

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20161101

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20161212

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: 20170131

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20170222

R150 Certificate of patent or registration of utility model

Ref document number: 6100135

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

LAPS Cancellation because of no payment of annual fees