JP5707409B2 - 計算機 - Google Patents

Description

本発明は、計算機に関するものである。

計算機システムにおけるシステム稼働時間を長時間化するために、計算機を多重化する技術が存在している。 また、システム停止時間を最小化するための計算機として、フォールト・トレラントコンピュータ（Ｆａｕｌｔ ｔｏｌｅｒａｎｔ ｃｏｍｐｕｔｅｒ）がある（特許文献１参照）。

デュアルシステムやフォールトトレラントシステムにおいては、入出力などのプロセッサ処理ステップについて、実行の度に計算機間で互いに内容を送受信し、同期的に（すなわち並列に）同一処理を実施する「クロック同期」という技術がある。

一方、近年ではネットワークの高速化、及び計算機の汎用化に伴い、専用ハードウェアではなく、一般的なハードウェア・ネットワークを利用して複数計算機を接続する技術が発達してきた。これを用いたフォールトトレラントシステムとして、「仮想計算機同期」方式が提案されている。これは、対象となるオペレーティングシステム・アプリケーションソフトウェアを仮想計算機上で実行し、仮想計算機への入力、および、仮想計算機の動作を他の仮想計算機に転送し、当該仮想計算機上で動作を再現するものである（特許文献２参照）。

特開平８−３１４７４４号公報 ＵＳ２０１０／０１０７１５８

前述した「クロック同期」方式はプロセッサの動作ステップ毎に計算機間で動作を一致させるものであり、専用ハードウェアによるプロセッサ動作ステップの観測・制御が必要である。しかし、近年はプロセッサと周辺チップセットの統合・高集積化が顕著になるにつれ、このようなプロセッサに対する動作ステップの観測・制御は困難になってきている。

さらに、「クロック同期」方式はプロセッサの入出力の度にノード間で同期処理を行うため、プロセッサの動作クロックを上げると同期処理によるオーバーヘッドが増加するという問題がある。

一方、「仮想計算機同期」方式は計算機に対する入力を仮想計算機のプロセッサ動作ステップ単位の精度にて観測し、他の仮想計算機上で再現することで同一の動作を再現するものである。これは、入力の内容及びタイミングが同一であれば観測時・再現時の動作が同一になるという前提により成り立つ。しかし、仮想計算機が複数プロセッサを備える場合には、プロセッサ間の動作順序が観測時と再現時で異なり、入力を完全に一致させても同一の動作とならない場合がある。従って、複数プロセッサを用いる場合にこの方式は適用できない。

そこで、専用ハードウェアを用いることなく、複数プロセッサを用いて複数のタスクが並列動作しお互いに影響を及ぼしあう場合においても、低オーバーヘッドでの同期処理が可能な技術を提供する。

計算機は少なくとも一の他の計算機と接続されている。計算機が有するプロセッサは、当該プロセッサが実行しているタスクにおいて入力若しくは出力要求を処理する際に、当該計算機の識別子と、当該タスクの識別子と、当該要求のアクセス対象の識別子とを含む要求通知を他の計算機に送信すると共に、他の計算機から当該他の計算機が送信した要求通知を受信する。プロセッサは、受信した要求通知の内容をメモリに格納し、メモリに格納された要求通知の内容に基づいて、プロセッサが処理しようとしている要求と、他の計算機のプロセッサが処理しようとしている要求とを比較する。そして、比較結果に基づいて、プロセッサが処理しようとしている要求の処理の可否を決定する。

複数のタスクが並列動作しお互いに影響を及ぼすような場合において、専用ハードウェアを用いることなく、低オーバーヘッドでの同期処理を行うことが可能となる。

フォールトトレラントシステムの構成例を示す図である プロセッサがタスクを実行するフローの一例を示す図である プロセッサが入出力について同期を行うフローの一例を示す図である 入出力要求の内容の一例を示す図である 入出力要求テーブルの一例容を示す図である 入出力要求通知の内容の一例を示す図である タスクの実行可否を判定するフローの一例を示す図である 入出力要求テーブルの他の一例を示す図である 入出力要求通知の他の一例を示す図である タスクの実行可否を判定するフローの他の一例を示す図である 異常計算機ノードの検知・切り離しを実現するための基盤ソフトウェアの構成例を示す図である 計算機ノード管理処理の一例を示す図である 計算機ノード管理テーブルの一例を示す図である タスク管理テーブルの一例を示す図である プロセッサが入出力について同期を行うフローの他の一例を示す図である 入出力要求テーブルの他の一例を示す図である 入出力要求通知の内容の他の一例を示す図である リーダにおけるプロセッサが入出力について同期を行うフローの一例を示す図である フォロワにおけるプロセッサが入出力について同期を行うフローの一例を示す図である 追従可否通知の内容の一例を示す図である 追従可否テーブルの一例を示す図である

本発明の実施形態について、図を用いて詳細に説明する。まず、本発明の基本形態である第一の実施形態について述べる。その後、タスクの実行条件を緩和した第二の実施形態、計算機ノードの異常に対する対策を加えた第三の実施形態、計算機ノード間の通知によるオーバーヘッドを軽減する工夫を加えた第四の実施形態について、第一の実施形態との差異として述べる。

‐‐‐‐第一の実施形態‐‐‐‐
図１は、本実施形態のフォールトトレラントシステム１の構成図である。フォールトトレラントシステム１は２台以上の計算機ノード１０とＶｏｔｅｒ２から構成される。図１において計算機ノードは１０−Ａ、１０−Ｂ、１０−Ｃの３台が存在するが、本発明は計算機ノード１０が３台の場合に限らない。フォールトトレラントシステム１はＶｏｔｅｒ２を介してフォールトトレラントシステム１外部の１台以上の端末３との入出力を行う。Ｖｏｔｅｒ２は少なくとも端末３からの入力を各計算機ノード１０に分配する機能と、端末３への出力について各計算機ノード１０からの出力を受け取り、端末３へ転送する機能を備える。端末３への転送に際しては、Ｖｏｔｅｒ２は各計算機ノード１０から取得した出力について多数決等の方法により妥当性のあるものを選択し、これを転送する。Ｖｏｔｅｒ２が複数個存在して多重構成をとっていてもよく、また、各計算機ノード１０の機能として実装されていてもよい。

各計算機ノード１０は少なくともメモリ１１、１つ以上のプロセッサ１２、ノード間通信インタフェース１５を備える。フォールトトレラントシステム１内の計算機ノード１０は、ノード間通信インタフェース１５を介して互いに接続されている。

この他、計算機ノード１０は、計算機ノード内の記憶装置１３、外部通信インタフェース１４を備えていてもよい。また、ノード間通信インタフェース１５が外部通信インタフェース１４の機能を兼ねてもよい。ただし、記憶装置１３、外部通信インタフェース１４の有無はフォールトトレラントシステム内の全計算機ノード１０で同一である。

メモリ１１は、少なくともアプリケーションソフトウェア２０と基盤ソフトウェア３０を保持する。アプリケーション２０は、一つ以上のタスク２１から構成される。アプリケーションソフトウェア２０を構成するタスク２１は、フォールトトレラントシステム１を構成する全計算機ノード１０で同一である。基盤ソフトウェア３０は複数のタスク２１を実行することのできるマルチタスク実行可能なオペレーティングシステムであり、少なくともスケジューラ３１、入出力要求検出処理３２、入出力判定処理３３、入出力実行処理３４、ノード間通信処理３５、入出力要求テーブル３６、要求受付処理３８を備える。この他、基盤ソフトウェア３０はタスク間共有記憶３７を備えていてもよい。

図２は、アプリケーションソフトウェア２０内タスク２１と基盤ソフトウェア３０内スケジューラ３１に基づくプロセッサ１２の動作を示したものである。

まず、プロセッサ１２がスケジューラ３１の処理を実行し、一つ以上のタスク２１の中から実行すべきものを一つ選択する（Ｓ１１）。プロセッサ１２は、このタスク２１の実行を開始する（Ｓ１２）。プロセッサ１２はタスク２１として記載された処理の一部を順に実行する（Ｓ１３）。タスク２１内の処理には、メモリの確保・解放、入出力処理など、基盤ソフトウェア３０の機能を呼び出すものもある。このような処理の実体は基盤ソフトウェア３０内に存在するため、タスク２１内では単に要求受付処理３８にある特定機能に対する要求発行として記載される。このようにタスク２１内の処理が基盤ソフトウェア３０への要求であった場合（Ｓ１４）、当該要求に対応する処理が直ちに完了するものでない場合（Ｓ１５）は、プロセッサ１２は再びスケジューラ３１の処理を実行して他のタスク２１を選択・実行する。処理が基盤ソフトウェア３０への要求でない場合、あるいは要求に対応する基盤ソフトウェア３０内の処理が直ちに完了した場合でも、実行中タスク２１が最優先でなくなった場合（Ｓ１６）に、プロセッサ１２は再びスケジューラ３１の処理を実行して他のタスク２１を選択・実行する。ここで述べた実行中タスク２１が最優先でなくなった場合とは、例えば実行中タスク２１の連続実行時間が一定以上となった場合、または、より高優先度の別タスク２１の実行が可能となった場合である。実行中タスク２１が最優先である場合は、タスク２１の処理の続きを実行する（Ｓ１３）。これらの動作は、プロセッサ１２が計算機ノード１０内に複数存在する場合は各プロセッサ１２が各々実行する。各プロセッサ１２の動作は原則として独立である。

本フォールトトレラントシステム１では計算機ノード１０間でクロック同期を行わないため、各計算機ノード１０間で、各プロセッサ１２の動作を完全に一致させることができない。例えば、プロセッサ内キャッシュ動作の差異による動作タイミングのずれ、基盤ソフトウェア３０の内部状態の差異による基盤ソフトウェア３０の動作不一致が考えられる。一方、フォールトトレラントシステム１を実現するにあたって、アプリケーションソフトウェア２０に関する計算機ノード１０間の致命的な動作不一致は許容されない。致命的な動作不一致とは、例えば計算機ノード１０内間で、各タスク２１内にある条件判定にて計算機ノード１０間で異なる結果となり別々の処理が実行されること、または計算機ノード１０同士でアプリケーションソフトウェア２０に関する出力が異なることである。これを防止するため、本発明ではＶｏｔｅｒ２による外部入力データの各計算機ノード１０への配信の他に、以降で述べる構成・動作を採用する。

図３は、プロセッサ１２があるタスク２１−ａの処理として入出力処理を実行する際の、タスク２１−ａ及び基盤ソフトウェア３０、の動作を示したものである。ここで述べる入出力とは、例えばタスク間共有記憶３７または記憶装置１３内の特定領域に対する読み書き、外部通信インタフェース１４を用いたＦＴシステム１外部の装置との送受信である。タスク２１における入出力処理は、要求受付処理３８に対する入出力要求４０の発行として記述される（Ｓ２０）。図４に示す通り、入出力要求４０には少なくとも入出力対象及び必要に応じて対象内のアドレス等の情報を含む入出力対象情報４１、入出力要求４０において要求する入出力種別４２、入出力を行うデータのサイズ４３、さらに、入出力要求４０が出力に関するものである場合のみ、出力データ４４を含む。

プロセッサ１２はこの入出力要求４０を入出力要求検出処理３２にて検出し（Ｓ２１）、入出力要求情報５５を入出力要求テーブル３６に登録する（Ｓ２２）。入出力要求テーブル３６は計算機ノード１０内で共通であり、同じ計算機ノード１０内の各プロセッサ１２は同一の入出力要求テーブル３６を更新・参照する。図５に示す通り、入出力要求テーブル３６は少なくとも入出力対象識別子５１、計算機ノード識別子５２、タスク識別子５３、シーケンス番号５４を含む。入出力対象識別子５１は入出力対象情報４１に記載され得る入出力対象部位・インタフェースとそれらの上のアドレスについて、一度にアクセスの対象となり得る単位毎に、入出力対象情報４１から一意に定まる符号を付与したものである。例えば、ある入出力対象識別子５１はタスク間共有記憶３７の特定領域を表し、また、ある入出力対象識別子５１は外部通信インタフェース１４のうちの一つを表す。シーケンス番号５４は、当該計算機１０上にて入出力要求テーブル３６に登録される入出力要求情報５５に対して、同一の入出力対象識別子５１を持つ入出力要求情報５５毎に割り当てられるシーケンス番号である。異なる入出力対象識別子５１に関する入出力要求情報５５であればそれらのシーケンス番号５４は無関係である。

また、プロセッサ１２は、ノード間通信処理３５にて、図６に示す入出力要求通知５０を他計算機ノード１０に送信するようノード間通信インタフェース１５に指示する（Ｓ２３）。ノード間通信インタフェースは、入出力要求通知５０をフォールトトレラントシステム１内の全計算機ノード１０に送信する。また、プロセッサ１２はノード間通信処理３５にて他計算機ノード１０からの入出力要求通知５０を受信し、これに基づき入出力要求テーブル３６を更新する（Ｓ２４）。ノード間通信処理３５による入出力通知５０の受信および入出力要求テーブル３６の更新は、計算機ノード１０内の特定のプロセッサ１２が、タスク１２とは非同期に行ってもよい。

プロセッサ１２は入出力判定処理３３にて入出力実行条件の成否判定を行い（Ｓ２５）、未成立である限り入出力の実行を保留する（Ｓ２６）。この間、プロセッサ１２は他のタスクの実行を行ってもよい。

入出力実行条件の成否判定方式としては様々なものが考えられるため、ここでは一種類について記載し、その他の方式については第二移行の実施形態として各々記載する。本実施形態では、フォールトトレラントシステム１内で計算機ノード識別子Ａ、Ｂ、Ｃを持つ、計算機ノード１０−Ａ、１０−Ｂ、１０−Ｃの３台が同期して動作する場合を例に説明する。

各計算機ノード１０が相互に入出力要求通知５０を伝達し、入出力要求テーブル３６を更新することは既に述べた。これに基づき、プロセッサ１２が自身の計算機ノード１０内の入出力要求テーブル３６を参照しながら、図７に示すフローを実行することでタスクの実行可否を判定する。

まず、判定対象となるタスクＴの入出力要求が全計算機ノードで実行待ちであるか、すなわち入出力要求テーブル３６に、当該タスクＴのタスク識別子５３と同一のタスク識別子５３を備えた入出力要求情報５５が、全計算機ノード識別子５２について現れているか判定する（Ｓ３１）。この条件を満たしていない場合、例えば図５におけるタスク識別子Ｔ２のタスクは、当該入出力要求を実行できない計算機ノードがあるため計算機ノード１０−Ａ、計算機ノード１０−Ｃ上では勿論、計算機ノード１０−Ｂにおいても実行条件不成立とする（Ｓ３５）。タスクＴの入出力要求が全計算機ノード上で実行待ちである場合、次に同じ入出力対象Ｒについて、フォールトトレラントシステム内の他の計算機ノード１０においてＴと同様に入出力実行待ちである他のタスクＴ’が存在するか、すなわち入出力要求テーブル３６内に、入出力対象識別子５１が同一でありタスク識別子５３が異なる入出力要求情報５５が現れているか判定する（Ｓ３２）。先に述べたＴ’が存在しない場合、当該入出力要求は入出力対象Ｒについて全計算機ノード１０上で唯一実行可能なものであるため、当該タスクＴは実行条件成立となる（Ｓ３４）。

Ｔ’が存在する場合、計算機ノード１０毎にＴとＴ’の実行順序が異なると計算機ノード１０間の動作不一致となるため、計算機ノード１０間で動作順序を一致させる必要がある。このため、条件に当てはまる全Ｔ’について、各計算機ノード１０毎にＴとＴ’のいずれが先に入出力要求テーブル３６に現れたかを判定する。すなわち、同一の入出力対象識別子５１、同一の計算機ノード識別子５２を持つ複数の入出力要求情報５５について、Ｔの入出力要求情報５５とＴ’の入出力情報５６のシーケンス番号５４の大小を比較する。特定計算機ノードについてＴ’の入出力要求情報が現れていない場合、Ｔのシーケンス番号５４がＴ’のものよりも小さいものとして扱う。以降、本実施形態、及び、他の実施形態において、入出力要求テーブル３６におけるタスク２１の出現順の判定は、同様にシーケンス番号の比較によって行う。もし任意のＴ’について、Ｔ’がＴより先に出現している計算機ノード１０の数が多い、すなわち入出力要求テーブル３６内で（Ｔのシーケンス番号５４）＞（Ｔ’のシーケンス番号５４）となっている計算機ノード１０の数が、（Ｔのシーケンス番号５４）＜（Ｔ’のシーケンス番号５４）となっている計算機ノード１０の数よりも多い場合、Ｔ’はＴより優先して実行すべきものとする。この場合、Ｔより優先して実行すべきタスクＴ’が存在するため、Ｔは実行条件不成立となる（Ｓ３５）。例えば、図５におけるタスク識別子Ｔ３のタスクの実行条件判定を行う場合、計算機ノードＡ、計算機ノードＣにてタスク識別子Ｔ４のタスクがタスク識別子Ｔ３のタスクより先に現れているため、Ｔ３の実行条件は不成立である。逆に、上記条件を満たすタスクＴ’が存在しない場合、タスクＴは実行条件成立となる（Ｓ３４）。例えば、図５におけるタスク識別子Ｔ４のタスクは実行条件成立となる。尚、異なる判定結果となる計算機ノード１０が判定結果毎に同数の場合は、例えば特定の計算機ノード１０が含まれる集合を多数派として扱うなどの方法で多数派が一意に定まるよう判定条件を設ける。この、計算機ノード数が同数となった場合の判定基準は、本発明に現れる計算機ノード数を比較する判定処理全てについても同様である。

条件が成立した場合、入出力実行処理３４にて入出力処理を実行する（Ｓ２７）。入出力実行処理３４は、タスク間共有記憶３７や記憶装置１３内の特定の領域に対する読み書きや、外部通信インタフェース１４に対する送信要求または受信内容の取得要求である。入出力実行処理３４は別のプロセッサ１２に対して実行を依頼してもよく、また、完了までの間他のタスク２１を実行してもよい。

以上で述べた方式により、全計算機ノード１０において、計算機１０外部または他のタスク２１への影響を及ぼす入出力処理を計算機ノード間で同期して実行することができる。

‐‐‐‐第二の実施形態‐‐‐‐
第二の実施形態として、図７に示したフローによるタスクの実行条件を緩和し、より効率的なタスク実行を行う構成について述べる。本方式では、図５、図６に示した入出力要求テーブル３６、入出力要求通知５０の代わりに各々図８、図９に示したものを、図７に示したフローの代わりに図１０に示したものを用いる。

本実施形態では、入出力要求テーブル３６、入出力要求通知５０に状態変化有無情報５６を含む。状態変化有無情報５６は、当該入出力要求を実行した場合に状態変化が発生するか否かを示す情報である。例えば、記憶装置１３やタスク間共有記憶３７からの読み込み要求は状態変化が発生せず、書き込み要求は状態変化が発生する。また、外部通信インタフェース１４に対する送受信要求は、送信は勿論のこと、受信に関しても外部通信インタフェース１４の内部バッファの状態が変化する場合などは状態変化有とする。状態変化情報５６は、図３のフロー中の入出力要求情報登録（Ｓ２２）、入出力要求通知送信指示（Ｓ２３）の際に、入出力要求４０内の入出力対象情報４１と入出力種別４２に基づき設定する。

本実施形態において、入出力実行条件の判定方式として図１０のフローを用いる。全計算機ノード１０が入出力要求の実行待ちになるのを待たない点、状態変化を伴わない入出力要求同士の実行順序を入れ替える点において第一の実施形態と異なる。まず、判定対象となるタスクＴの入出力要求が過半数の計算機ノードで実行待ちであるか、すなわち入出力要求テーブル３６に、当該タスクＴのタスク識別子５３と同一のタスク識別子５３を備えた入出力要求情報５５が、過半数の計算機ノード識別子５２について現れているか判定する（Ｓ４１）。次に、同一入出力対象について実行待ちである他のタスクＴ’が存在するか判定する点は第一の実施形態と同様である（Ｓ４２）。Ｔ’が存在する場合、第一の実施形態と同様にＴとＴ’のいずれが入出力要求テーブル３６に現れたか、シーケンス番号５４に基づき判定する（Ｓ４３）。ただし、ある計算機ノード１０についてＴが現れていない場合、Ｔ’の出現有無に関わらずＴ’が先に出現したものとして扱う。この判定にてＴが最優先となった場合は第一の実施形態と同様にタスクＴの実行条件成立と判定する。例えば、図８の入出力要求テーブル３６において、入出力対象識別子Ｒ３の入出力対象についてタスク識別子Ｔ５のタスクは第一の実施形態では計算機ノード１０−Ｂにて入出力要求が発生していないため実行条件未成立だが、本実施形態では実行条件成立となる。他のタスクＴ’が最優先となった場合には、第一の実施形態と異なり、ＴとＴ’の状態変化有無５６を参照し、それらのタスクによる入出力要求が状態変化を伴うか判定する（Ｓ４６）。全て状態変化無である場合はＴの実行条件が成立と判定する（Ｓ４４）。例えば、図８の入出力要求テーブル３６において、入出力対象識別子Ｒ３の入出力対象についてタスク識別子Ｔ６のタスクはＳ４４の条件を満たすため実行条件成立となる。Ｔが状態変化を伴う場合、またはＴ’のいずれかが状態変化を伴う場合はＴの実行条件不成立と判定する（Ｓ４５）。例えば、入出力対象識別子Ｒ２の入出力対象についてタスク識別子Ｔ３のタスクは状態変化を伴うためＳ４４の条件を満たさず、従って実行条件未成立である。

以上で述べた通り、第二の実施形態では、少数の計算機ノード１０上にて特定タスクの動作が遅れた場合や、状態変化を伴わない入出力要求が多数発生した場合に、第一の実施形態に比べてタスクの実行を遅延なく行うことができる。

‐‐‐‐第三の実施形態‐‐‐‐
第三の実施形態では第一の実施形態に対して、フォールトトレラントシステム１を構成する計算機ノード１０の一部に異常が発生した場合に、これを検知して切り離すことができる方式を実現する。この方式では、図１の基盤ソフトウェア３０を図１１に示すもので置き換え、基盤ソフトウェア３０に図１２に示すノード管理処理６１、図１３に示すノード管理テーブル６２、図１４に示すタスク管理テーブル６４を追加し、図７のフローに代わり図１５のフロー、図５、図６に示した入出力要求テーブル３６、入出力要求通知５０の代わりに図１６、図１７に示したものを用いる。

この方式では、計算機ノード１０間のハートビートによる生存監視、入出力要求情報５５の比較照合によるタスク動作不一致の検出、入出力要求情報にタスク時間見積情報を付与することによるタスク動作タイムアウトの検知を実現する。本実施形態は簡単のため第一の実施形態に対する拡張として記述するが、第二の実施形態との複合も可能である。

第三の実施形態では、基盤ソフトウェア３０は新たにノード管理処理６１、ノード管理テーブル６２、タスク管理テーブル６４を備える。ノード管理処理６１は、少なくともノード間通信処理３５に対して生存監視パケットの送信を指示する計算機ノード管理情報送信処理７１と、基盤ソフトウェア３０内の任意の処理に基づき定期的にノード間通信処理３５に対して生存監視パケットの受信を指示する計算機ノード管理情報受信処理７２、一定時間生存監視パケットの受信が無かった場合に送信元の計算機ノード１０について異常状態と判定する計算機ノード異常判定処理７３を備える。計算機ノード管理情報送信処理７１、計算機ノード管理情報受信処理７２、計算機ノード異常判定処理７３は、各計算機ノード１０上の任意のプロセッサ１２が定期的に実行する。また、ノード管理処理６１は、計算機ノード異常判定処理７３やその他基盤ソフトウェア３０で検出した異常に基づき、ノード管理テーブル６２に反映する他計算機ノード切り離し処理７４、他計算機ノード１０に対する切り離し実行通知の送信をノード間通信インタフェース１５に指示するとともにノード管理テーブル６２への反映を行う自計算機ノード切り離し処理７５、タスク管理テーブル６４と入出力要求テーブル３６を照合しタスクの異常を検知するタスク異常検知処理７６、を備える。

ノード管理テーブル６２は、フォールトトレラントシステム１内の全計算機ノード１０について同期動作中であるか否かを示すものである。ノード管理テーブル６２は図１３に示す通り、少なくとも計算機ノード識別子５２と同期状態情報６３を含む。入出力判定処理３３とノード間通信処理３５では、同期状態情報６３に同期状態と記載されている計算機ノード１０に関してのみ通信・入出力判定の対象とする。また、ノード管理処理６１による他計算機ノード切り離し処理７４は、ノード管理テーブル６２内の対象計算機ノード１０に対応するノード識別子５２の項について、同期状態情報６３を非同期状態に書き換えるものである。

タスク管理テーブル６４は、計算機ノード１０上での各タスク２１に関して、各々前回の入出力要求後に行った処理の量を表すものである。タスク管理テーブル６４は図１４に示す通り、少なくともタスク識別子５２の他、プロセッサ消費時間情報６５と要求完了待ち実時間６６と要求完了待ち最大時間６７を備える。これらは各々、プロセッサ１２があるタスク２１について前回の入出力要求後の処理に費やした時間の合計、あるタスク２１について要求完了待ちＳ１５により動作を保留した時間の合計、要求完了待ちＳ１５発生時に、対象となる要求の種類毎の、要求の完了までに要する時間の最大見積値の合計である。プロセッサ１２は、スケジューラ３１、及び、要求受付処理３８の実行時に、前者においてはタスクが動作した時間をプロセッサ消費時間情報６５に加算し、後者においては要求の実行に要した時間を要求完了待ち実時間６６に加算、要求の内容に応じた最大見積時間を要求完了待ち最大時間６７に加算する。また、タスク管理テーブル６４は、各計算機ノード１０上でタスクの動作が一致していたか照合するための情報である、タスク動作情報６８を備えていてもよい。

本実施形態では、タスク２１にて入出力要求が発生した場合に、プロセッサ１２が図１５に示すフローを実行する。本フローは図３に示した第一の実施形態のフローと類似するため、差異のみ説明する。まず、入出力要求情報の登録（Ｓ２２）、入出力要求通知送信指示（Ｓ２３）の際に、タスク管理テーブル６４内のタスク２１−ａに関するプロセッサ消費時間６５、要求完了待ち実時間６６、要求完了待ち最大時間６７を参照してこれを各々入出力要求テーブル３６（図１６）内、入出力要求通知５０（図１７）内に含める。また、プロセッサ１２は入出力要求照合（Ｓ５１）において、当該タスクに関する自計算機ノード１０の入出力要求情報５５と他計算機ノード１０の入出力情報５５を比較する。同一のタスク識別子５３を持ち、計算機ノード識別子５２が自計算機ノードと異なる入出力要求情報５５、すなわち、他の計算機ノード上で同一タスク１２が行った入出力要求に関する情報について、少なくとも入出力対象識別子５１が一致しているか判定する。入出力対象識別子５１以外にも、例えば第二の実施形態にて入出力要求情報５５に含めた状態変化有無情報５６など、計算機ノード１０間でタスク１２が同様の動作を行ったか判断するために有用な情報があれば、それらも一致判定の対象としてよい。また、入出力要求通知５０、入出力要求テーブル３６に、図４に示した入出力４０中の入出力対象情報４１、入出力種別４２、入出力サイズ４３、出力データ４４そのもの、または出力データ４４のハッシュ値などの情報を入出力要求通知にタスク動作情報６８として含め、一致判定の対象としてもよい。本判定にて不一致が発生した場合、タスク動作情報が一致する計算機ノード１０の集合毎に、当該集合に属する計算機ノード１０の個数を比較し、多数派となる集合を選出する。もし自計算機ノード１０が多数派集合に属していない場合は、ノード管理処理６１の自計算機ノード切り離し処理７５を実行する。

ノード管理処理６１は、入出力要求テーブル３６、タスク管理テーブル６４に基づく自計算機ノード１０上のタスク２１に関するタスク異常検知処理７６を備える。ここでの異常検知とは、あるタスク２１について他の計算機ノード１０に比べて自計算機ノード１０で動作が遅れている、または停止している場合にこれを検知することである。タスク異常検知処理７６は、計算機ノード１０上の任意のプロセッサ１２が実行する。まず、タスク管理テーブル６４上で、他計算機ノード１０に関してのみ現れている入出力要求情報５５について、タスク管理テーブル６４上の対応するタスクに関する情報と比較する。すなわち、条件を満たす入出力要求情報５５内のタスク識別子５３と同一のタスク識別子５３を持つタスクについて、入出力要求テーブル３６からプロセッサ消費時間６５、要求完了待ち実時間６６、要求完了待ち最大時間６７を取得して、タスク管理テーブル６４上の情報と比較する。比較の結果、自計算機ノード上のタスク２１のプロセッサ消費時間６５が他全ての計算機ノード１０でのプロセッサ消費時間６５より一定以上大きい場合、自計算機ノード上のタスク２１の要求完了待ち実時間６６が他全ての計算機ノード１０上の要求完了待ち最大時間６７より一定以上大きい場合に、当該タスク２１にて異常発生と判断する。異常発生と判断した場合、自計算機ノード切り離し処理７５を行う。

以上で述べた通り、第三の実施形態では、特定の計算機ノード１０が動作を停止した場合、特定の計算機ノード１０上にて他計算機ノード１０とのタスク動作の不一致が発生した場合、他計算機ノード１０に対してタスクの動作が遅れた場合に、当該計算機ノード１０をフォールトトレラントシステム１から切り離して動作を続行することができる。

‐‐‐‐第四の実施形態‐‐‐‐
第四の実施形態では、入出力実行処理３４における入出力処理開始から入出力実行までの時間が長い場合に、この時間を利用して計算機ノード１０間の同期をとることで入出力時のオーバーヘッドを軽減するものである。この動作について、図１８、図１９のフロー図、図２０、図２１の通信内容、及び、データ形式を用いて説明する。

本実施形態では、フォールトトレラントシステム１を構成する計算機ノード１０のうち一台をリーダ、その他をフォロワとする。リーダは独自の判断にて入出力を行い、フォロワは原則としてリーダと同一の順番にて入出力を行うものとする。ただし、フォロワの多数がリーダに追従不能と判断した場合は、このことをリーダに伝達することでリーダをフォールトトレラントシステム１から切り離し、残りの計算機ノード１０にて処理を継続する。このため、基盤ソフトウェア３０は少なくとも第一の実施形態の構成に加え、第三の実施形態で述べたノード管理テーブル６２、図２１に示す追従可否テーブル９０を備えるものとする。

本実施形態において、基盤ソフトウェア３０内における入出力要求検出から入出力処理実行までのフローはリーダにおいては図１８、フォロワにおいては図１９の通りである。この間、リーダとフォロワの間では、リーダから全フォロワへの入出力要求通知(図１８、１９フロー中Ｃ１)の送信、各フォロワからリーダ及び他フォロワへの追従可否通知（図１８、１９フロー中Ｃ２）の送信の順に通信が行われる。まず、リーダの動作について図１８を用いて説明する。

リーダにおいて、プロセッサ１２が入出力要求検出処理３２にて入出力要求を検出し（Ｓ２２）、自身の入出力要求テーブル３６に登録（Ｓ２２）するまでは第一、第二の実施形態と同様である。次に、ノード間通信処理３５にて入出力要求通知の送信指示を行う（Ｓ６３、Ｃ１）。入出力を開始（Ｓ６９）したリーダの計算機ノード１０上では、並行してノード間通信処理３５にて、フォロワからの追従可否通知８０を受信するようノード間通信インタフェース１５に指示する。追従可否通知８０を受信した（Ｃ２）場合、図２１に示す追従可否テーブル９０に登録する。そして、追従可否テーブル９０においてリーダ及び追従可能な計算機ノード１０の数、すなわち「追従可能」とした追従可否通知８０を受信した数＋１が過半数になるか、あるいは追従不可能な計算機ノード１０の数が過半数となるまで、入出力処理の実処理直前にてタスク２１の動作を保留する。ここで、入出力処理の実処理とは、例えばタスク間共有記憶３７や記憶装置１３について内容が書き変わる処理、または、共有メモリ３７や記憶装置１３の内容を転写する処理、ノード間通信インタフェース１５に対するデータ取得・データ送信実行処理など、他タスク２１や装置外部への影響が発生する処理である。追従可能または不可能な計算機ノード１０の数が一定数を超えた場合、いずれが過半数であるか判定し（Ｓ７１）、リーダ及び追従可否通知８０にて追従可能とした計算機ノード１０の数が多い場合は入出力の実処理を実行する（Ｓ７６）。追従可否通知８０にて追従不可能とした計算機ノード１０の数の方が大きい場合、第三の実施形態と同様に同期離脱を行う（Ｓ７７）。

次に、フォロワの動作について図１９を用いて説明する。リーダの場合と同様、プロセッサ１２が入出力要求検出処理３２にて入出力要求を検出し（Ｓ２２）、自身の入出力要求テーブル３６に登録（Ｓ２２）する。この後に、リーダからの入出力要求通知を受信（Ｃ１）するようノード間通信処理３５に指示する（Ｓ６４）。次に、入出力判定処理３３にて、入出力開始条件が成立しているか判定を行う（Ｓ６５）。ここで入出力開始条件は、当該タスク２１についてリーダから入出力要求通知が届いている、すなわち、入出力要求テーブル３６に同一のタスク識別子５３、リーダの計算機ノード識別子５２を持つ入出力要求情報５５があるか否かである。入出力開始条件を満たしている場合、リーダ及び他のフォロワに対して図２０に示す追従可否通知８０にて追従可能である旨通知する（Ｃ２）ようノード間通信インタフェース１５に対して指示を行い（Ｓ６８）、入出力を開始する（Ｓ６９）。入出力開始条件が未成立の場合、フォロワとしてリーダの入出力に追従可能か否かの判定を行う（Ｓ６６）。例えば追従可能である場合とは、当該入出力要求の実行が一定時間以上遅延されていない場合である。この場合は、他タスクを実行した後に（Ｓ６７）、入出力要求通知受信指示（Ｓ６４）を経て再び入出力開始条件の判定を行う（Ｓ６５）。入出力を開始（Ｓ６９）した計算機ノード１０上では、並行してノード間通信処理３５にて、他フォロワからの追従可否通知８０を受信する（Ｃ２）ようノード間通信インタフェース１５に指示する。追従可否通知８０を受信した場合、図２１に示す追従可否テーブル９０に登録する。そして、追従可否テーブル９０におけるリーダ及び追従可能な計算機ノード１０の数、すなわち「追従可能」とした追従可否通知８０を受信した数＋２が過半数になるか、あるいは追従不可能な計算機ノード１０の数が過半数となるまで、リーダの場合と同様入出力処理の実処理直前にてタスク２１の動作を保留する。追従可能または不可能な計算機ノード１０の数が一定数を超えた場合、いずれが過半数であるか判定し（Ｓ７１）、リーダ及び追従可否通知８０にて追従可能とした計算機ノード１０の数が多い場合は入出力の実処理を実行する（Ｓ７６）。追従可否通知８０にて追従不可能とした計算機ノード１０の数の方が大きい場合はリーダ及びこれに追従可能と判定した計算機ノード１０は第三の実施形態と同様に同期離脱を行う（Ｓ７７）。

フォロワがリーダの入出力に追従不可能と判断した場合（Ｓ６６）、ノード間通信処理３５にてノードリーダ及び他のフォロワに対する「追従不可能」とした追従可否通知８０の送信（Ｃ２）を、ノード間通信インタフェース１５に指示する。この後、入出力を開始（Ｓ６９）するフローの場合と同様に、他フォロワからの追従可否通知８０を受信する（Ｃ２）ようノード間通信インタフェース１５に指示する。追従可否テーブル９０中で追従可能とした計算機ノード１０の数・追従不可能とした計算機ノード１０の数が一定以上となるまで処理を保留し、一定以上となった場合に追従可能・追従不可能な計算機ノード１０の数を比較する（Ｓ７４）点は、Ｓ７１と同様である。自身を含めた追従不可能な計算機ノード１０の数が少ない場合は自計算機ノード切り離し処理を行い（Ｓ７７）、追従不可能な計算機ノード１０が多数の場合はそれらの計算機ノード１０にてリーダの再選出を行う（Ｓ７５）。リーダの再選出は、例えば全計算機ノード１０につけられている通し番号が、当該計算機ノード１０の中で最も小さいものを選択する、などの方法にて行う。リーダ再選出後、新リーダは図１８のフローのＳ６３から、フォロワは、Ｓ６４の入出力要求通知受信処理から動作を再開する。

以上で述べた通り、第四の実施形態では、フォールトトレラントシステム１を構成する計算機ノード１０のうち１台をリーダとし残りをフォロワとすること、リーダはフォロワの応答を待つことなく入出力を開始し、入出力処理が外部、または、他タスクに影響を与える直前までの時間にフォロワの回答を確認することで、入出力の際のオーバーヘッドを軽減できる。

以上、第一から第四の実施形態を用いて説明した。第一の実施形態は、複数のタスクが並列動作しお互いに影響を及ぼすような場合において、専用ハードウェアを用いることなく、低オーバーヘッドでの同期処理を行うことが可能なフォールトトレラントシステムの基本方式を実現したものである。第二の実施形態は、第一の実施形態に対して、タスク間の依存関係による実行待ちを軽減するものである。第三の実施形態は、第一の実施形態に対して、計算機ノードやその上のタスクの異常を検知して正常な計算機ノードのみにて動作を継続するための仕組みを追加したものである。第四の実施形態は、第一の実施形態に対して、特定計算機ノードに特権を与えることにより処理の照合待ちを軽減し、オーバーヘッドを軽減するよう方式を工夫したものである。

１ フォールトトレラントシステム
２ Ｖｏｔｅｒ
３ 端末
１０ 計算機ノード
１１ メモリ
１２ プロセッサ
１３ 記憶装置
１４ 外部通信インタフェース
１５ ノード間通信インタフェース
２０ アプリケーション
２１ タスク
３０ 基盤ソフトウェア
３１ スケジューラ
３６ 入出力要求テーブル
３７ タスク間共有記憶
４０ 入出力要求
５１ 入出力対象識別子
５２ 計算機ノード識別子
５３ タスク識別子
５４ シーケンス番号
６２ 計算機ノード管理テーブル
６４ タスク管理テーブル
８０ 追従可否通知
９０ 追従可否テーブル

Claims (4)

1. 少なくとも一の他の計算機と通信可能に接続された計算機であって、
   プロセッサ、メモリ、前記他の計算機と通信するためのインタフェース部とを有しており、
   前記プロセッサは、
   当該プロセッサが実行しようとしているタスクにおいて入力若しくは出力の要求を処理する際に、
   当該計算機の識別子と、当該タスクの識別子と、当該要求のアクセス対象の識別子とを含む要求通知を前記他の計算機に送信し、
   前記他の計算機から当該他の計算機が送信した要求通知を受信し、
   受信した前記要求通知の内容を前記メモリに格納し、
   少なくとも１台以上の計算機にて、当該プロセッサが処理しようとしている要求と、前記他の計算機のプロセッサが処理しようとしている要求とを比較する際に、前記他の計算機全てから当該プロセッサが実行しようとしているタスクの識別子と同じタスクの識別子を受信したかを判定し、
   更に、前記プロセッサが処理しようとしている前記要求と同じアクセス対象をアクセスしようとする他の要求が存在する場合に、当該計算機上にて当該他の要求が前記要求より後に発生した要求であるか否かを判定し、
   当該計算機がリーダ計算機である場合には、前記他の計算機から追従可否通知を受信し、
   前記プロセッサは過半数の前記他の計算機から追従可を示す追従可否通知を受信した場合に、当該プロセッサが処理しようとしている要求を処理することを特徴とする計算機。
2. 請求項１に記載の計算機であって、
   当該計算機がフォロワ計算機である場合には、前記リーダ計算機から受信した要求通知に基づいて、 当該プロセッサが処理しようとしている要求の処理の可否を決定する
   ことを特徴とする計算機。
3. 請求項２に記載の計算機であって、
   前記フォロワ計算機はさらに、前記リーダ計算機への追従可否通知を前記他の計算機に送信し、
   前記プロセッサは前記他の計算機から受信した追従可否通知を参照して、所定の数以上の計算機から追従可を示す追従可否通知を受信している場合に、前記リーダ計算機を引き続きリーダ計算機とすることを特徴とする計算機。
4. 請求項３に記載の計算機であって、
   前記フォロワ計算機は、
   前記所定の数より少ない計算機から追従可を示す追従可否要求を受信している場合に、前記リーダ計算機とは異なる計算機を新たなリーダ計算機とする
   ことを特徴とする計算機。

Images