JP3145236B2

JP3145236B2 - フォールトトレラントコンピューティング装置

Info

Publication number: JP3145236B2
Application number: JP26040093A
Authority: JP
Inventors: フアンイェンヌン
Original assignee: AT&T Corp
Current assignee: AT&T Corp
Priority date: 1992-09-30
Filing date: 1993-09-27
Publication date: 2001-03-12
Anticipated expiration: 2016-03-12
Also published as: EP0590866B1; DE69330239T2; EP0590866A2; JPH06202893A; CA2106280C; US5748882A; EP0590866A3; CA2106280A1; DE69330239D1

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】本発明は、一般的に、フォールト
トレラントコンピューティングに関し、特に、アプリケ
ーションプログラムのレベルでのフォールトトレラント
コンピューティングに関する。

【０００２】

【従来の技術】現在のシステムは、以前よりも障害に耐
性がなければならない。フォールトトレランス（耐障害
性）は２つの次元を有する。それは、可用性と、データ
完全性（すなわち、システムの一貫性の状態）である。
交換システムは連続的可用性を必要とする。ほとんどの
その他のシステムでも同様に、可用性およびデータ完全
性の現在のレベルを増大させる必要がある。そうしたシ
ステムにおけるフォールトトレランスは、ハードウェア
層およびオペレーティングシステム層において提供され
ることが多い。

【０００３】フォールトトレランスは、ハードウェアで
は、デュプレクス構成、三重モジュール冗長構成または
その他のハードウェア技術を使用して実現される。（例
えば、エス．ウェバー(S. Webber)、ジェイ．ベアン(J.
Beirne)「階層アーキテクチャ」、Proceedings of the
21st Fault-Tolerant Computing Symposium、第７９〜
８５ページ（１９９１年６月）参照。）フォールトトレ
ランスは、オペレーティングシステム内でも、複製ファ
イルシステム（エム．サティヤナラヤナン(M.Satyanara
yanan)「Ｃｏｄａ：分散ワークステーション環境に対す
る高可用性ファイルシステム」、IEEE Transactions on
Computers、第Ｃ−３９巻第４４７〜４５９ページ（１
９９０年４月）参照）、例外処理（エス．ケー．シュリ
ヴァスタヴァ(S. K. Shrivastava)編「高信頼性コンピ
ュータシステム(Reliable Computer Systems)」第３
章、シュプリンガー・フェアラーク（１９８５年）参
照）およびその他のシステムルーチンを使用して実現さ
れることがある。

【０００４】フォールトトレランスの第３層は、アプリ
ケーションソフトウェア内で実現される。アプリケーシ
ョン層内のフォールトトレランスは、２つの下位層で処
理できないユーザ障害およびプログラミング障害を処理
することができる。ユーザレベルの障害は、アプリケー
ションをハングさせる（動かなくする）ことがある。下
位のハードウェアおよびオペレーティングシステムはこ
のような障害を処理することができない。すなわち、こ
のような障害を検出し、障害から自動的にアプリケーシ
ョンを再起動および回復することはユーザレベルでのみ
可能である。プログラミング障害は、同じ計算をする代
替アルゴリズムを提供することによって、または、多数
決法を使用することによって、アプリケーション内で処
理されることが必要になる場合がある。こうしたソフト
ウェアフォールトトレランス機能を使用するには、下位
のハードウェアまたはオペレーティングシステムでは不
適当である。

【０００５】ソフトウェアフォールトトレランスは、下
位のハードウェアまたはオペレーティングシステムがフ
ォールトトレラントであるか否かにかかわらず、アプリ
ケーションにおいて実現される。実際には、フォールト
トレラントハードウェア上でフォールトトレランスを実
現するよりも、分散した非フォールトトレラントハード
ウェアで実行中のアプリケーションソフトウェアにおい
てフォールトトレランスを実現するほうが経済的である
こともある。これは、現在の非フォールトトレラント製
品をフォールトトレラントにする簡易な移行路でもあ
る。

【０００６】ソフトウェアフォールトトレランスの上記
の利点は周知であるが、以前は、デーモンプロセスによ
ってプロセスの活性を監視すること、クリティカルデー
タの周期的チェックポイント、メッセージ／イベントの
ログ、回復ブロック（ビー．ランデル(B. Randell)「ソ
フトウェアフォールトトレランスのシステム構造」、IE
EE Transactions on Software Engineering、第ＳＥ−
１巻第２号第２２０〜２３２ページ（１９７５年６月）
参照）、Ｎバージョンプログラミング（エー．アヴィジ
エニス(A. Avizienis)「フォールトトレラントソフトウ
ェアへのＮバージョンアプローチ」、IEEE Transaction
s on Software Engineering、第ＳＥ−１１巻第１２号
第１４９１〜１５０１ページ（１９８５年１２月）参
照）、ログおよび回復機構を有するトランザクション処
理、ホット予備プロセッサ上での二重プロセスの実行、
などのような技術を含むように各アプリケーションをプ
ログラミングすることによって、アプリケーションはフ
ォールトトレラントにされて来た。

【０００７】

【発明が解決しようとする課題】この分野に欠けてお
り、本発明によって提供されるのは、ハードウェアおよ
びオペレーティングシステムとはほとんど独立してお
り、アプリケーションプログラムによって容易に使用す
ることができるソフトウェアフォールトトレランスの要
素の標準的なセットである。

【０００８】

【課題を解決するための手段】本発明の第１の実施例
は、フォールトトレラントコンピューティング装置であ
って、コンピュータシステム内にあり、コンピュータシ
ステムで実行中の第１のユーザプロセスを指定する登録
メッセージを提供する手段と、コンピュータシステムで
実行中の少なくとも１つの他のユーザプロセスからな
り、登録メッセージに応答して第１ユーザプロセスが続
行不能であるかどうかの観測を開始し、第１ユーザプロ
セスが続行不能であると観測された場合に第１ユーザプ
ロセスを再起動するデーモンとを有する。

【０００９】本発明の第２の実施例は、フォールトトレ
ラントコンピューティング装置であって、それぞれ少な
くとも第１のユーザプロセスを含むユーザプロセスを実
行可能な複数のノードと、少なくとも１つのノードにお
いて、他のノードが故障しているかどうかを観測し、そ
のノードが故障していると観測された場合、デーモンが
属するノード上で、その故障しているノードからの第１
ユーザプロセスのうちの少なくとも１つを再起動する、
ノードにおいて実行される少なくとも１つのユーザプロ
セスからなるデーモンとを有する。

【００１０】本発明の第３の実施例は、マルチノードシ
ステムにおいてノードの故障に応答する技術と、プロセ
スの保存すべき状態を定義し、その状態が保存され復元
されたかどうかを判定する技術と、故障時に利用可能な
ようにプロセスの状態を他のノードにコピーする技術
と、ノード間でプロセスの一貫性およびノード状態情報
の一貫性を維持する技術と、故障後にプロセスを再起動
する技術とを含む。

【００１１】

【実施例】ここで説明するソフトウェアフォールトトレ
ランスのための要素の標準的なセットは、自動フォール
ト検出およびファシリティ再起動を提供するモニタと、
アプリケーションプログラムによって使用されるプログ
ラムのフォールトトレラントライブラリを含む。以下の
詳細な説明ではまずモニタ（以下では、ｗａｔｃｈｄデ
ーモンまたは単にｗａｔｃｈｄと呼ばれる）、およびフ
ォールトトレラントライブラリ（以下ではｌｉｂｆｔと
呼ばれる）の概観と、それらが協力してアプリケーショ
ンレベルのフォールトトレラントコンピューティングを
可能にする方法について説明し、次に、好ましい実施例
におけるそれらの実現の詳細について説明する。

【００１２】［単一ノードにおけるｗａｔｃｈｄおよび
ｌｉｂｆｔの概観：図１］ｗａｔｃｈｄおよびｌｉｂｆ
ｔは、プロセッサおよびメモリを含む単一のノードのみ
からなるシステムにおいて、または、ネットワークに接
続された複数のこのようなノードからなるシステムにお
いて実現可能である。この概観は、単一ノードにおける
ｗａｔｃｈｄおよびｌｉｂｆｔの説明から開始し、その
後でノードのネットワークにおけるものの説明をするこ
とにする。好ましい実施例では、ノードは、同一のオペ
レーティングシステムが動作しているワークステーショ
ンである。オペレーティングシステムとしては例えば、
ＵＮＩＸオペレーティングシステムの１つのバージョン
であるＳＵＮＯＳ４．１がある（ＵＮＩＸはＡＴ＆
Ｔの登録商標である）。ｗａｔｃｈｄは、ＵＮＩＸユー
ザプロセスを使用して実現され、ｌｉｂｆｔは、プログ
ラミング言語Ｃで書かれたプログラムのライブラリとし
て実現される。

【００１３】図１に、単一ノードにおけるアプリケーシ
ョンレベルのフォールトトレラントコンピューティング
のためのシステム１０１を示す。システム１０１は、１
以上のフォールトトレラントプロセス１０３を有する。
ノードで実行中のオペレーティングシステムの観点から
は、各フォールトトレラントプロセスはユーザプロセス
である。従って、各フォールトトレラントプロセス１０
３は揮発性メモリ１０５を有する。メモリが揮発性であ
るとは、プロセス１０３が存在しなくなるとそのメモリ
が存在しなくなることをいう。フォールトトレラントプ
ロセス１０３は揮発性メモリ（ＶＭＥＭ）１０５からの
コード１０７を実行する。コード１０７には、フォール
トトレラントアプリケーション（ＦＴＡ）コード１１１
およびｌｉｂｆｔコード１１３が含まれる。ｌｉｂｆｔ
コード１１３は、コード１１１がコンパイルされる際に
コード１１１と結合される。アプリケーションコード１
１１は、ｌｉｂｆｔコード１１３内のルーチンを起動し
て、フォールトトレラントプロセス１０３がクラッシュ
またはハングした場合の回復を可能にするさまざまな動
作を実行する。フォールトトレラントプロセス１０３が
ノードのプロセッサ上で実行中の場合は、矢印１０２で
示すようにコード１０７内の命令を実行し、同じく揮発
性メモリ１０５に格納されているデータ１０９への作用
を実行する。

【００１４】ｌｉｂｆｔコード１１３内のルーチンは、
データ専用の揮発性メモリ１０５の一部をクリティカル
メモリ（ＣＲＭＥＭ）１１５として指定することが可
能である。ｌｉｂｆｔコード１１３内の他のルーチン
は、フォールトトレラントプロセス１０３がＣＲＭＥ
Ｍ１１５内のデータを持続性メモリ１２３（一般にはフ
ァイルシステム）に書き込む（矢印１１９で示す）こと
を可能にする。これは、図１では、クリティカルメモリ
コピー（ＣＲＭＥＭＣ）１２５として現れている。こ
の操作をチェックポインティングという。プロセス１０
３がハングまたはクラッシュした後に再起動されると、
ｌｉｂｆｔコード１１３内のもう１つのルーチンによっ
て、プロセス１０３は、ＣＲＭＥＭ１１５内のデータ
を１２５のコピーから復元する（矢印１２１で示す）こ
とができる。持続性メモリ１２３はまたログファイル１
２７を含むことが可能である。ログファイル１２７は、
ｌｉｂｆｔ１１３によって提供される特殊Ｉ／Ｏリード
またはライトの結果のデータメッセージのログを含む。
これらの動作はそれぞれ矢印１３１および１２９として
示されている。プロセス１０３が再起動されると、他の
ファイルに対するＩ／Ｏの実行を開始する前にログファ
イル１２７内の全メッセージを消去する。

【００１５】クラッシュまたはハングした場合のフォー
ルトトレラントプロセス１０３の再起動は、ｗａｔｃｈ
ｄデーモン１０４によってなされる。ｗａｔｃｈｄデー
モン１０４には２つのリストが付随する。第１のリスト
はフォールトトレラントプロセス（ＦＴＰ）リスト１３
９である。これは、デーモン１０４が監視すべきノード
におけるフォールトトレラントプロセスのリストであ
る。第２のリストはフォールトトレラントグループ（Ｆ
ＴＰグループ）リスト１４１である。これは、そのグル
ープ内のいずれかのフォールトトレラントプロセス１０
３がハングまたはクラッシュした場合にすべて再起動さ
れなければならないフォールトトレラントプロセス１０
３のグループのリストである。後でさらに詳細に説明す
るように、リスト１３９におけるフォールトトレラント
プロセス１０３のエントリは、プロセス１０３がログフ
ァイル１２７とともにどのように監視されるべきかを示
す。

【００１６】矢印１３３で示すように、デーモン１０４
は、プロセス１０３がハングまたはクラッシュしている
か否かを判定するために、フォールトトレラントリスト
１３９に指定された方法でフォールトトレラントプロセ
ッサリスト１３９に指定された各フォールトトレラント
プロセス１０３を連続的に監視する。この監視は、能動
的（すなわち、ｗａｔｃｈｄデーモン１０４がプロセス
１０３の状態を判定するためにプロセス１０３をポーリ
ングする）でも、受動的（すなわち、ｌｉｂｆｔ１１３
内には、プロセス１０３によって実行されると、デーモ
ン１０４にシグナルを送り、時間区間を指定するルーチ
ンが存在する）でもよい。デーモン１０４が、その時間
区間の終了前にそのルーチンから他のシグナルを受信し
ない場合、デーモン１０４はプロセス１０３がハングま
たはクラッシュしていると仮定する。

【００１７】デーモン１０４は、フォールトトレラント
プロセス１０３がクラッシュしていると判定した場合、
プロセス１０３、および、グループリスト１４１に指定
されているプロセス１０３を含むグループに属する他の
プロセス１０３を再起動する。再起動は以下のように実
行される。プロセスが再起動されると、クリティカルメ
モリ１１５がクリティカルメモリコピー１２５から復元
される。ログファイル１２７が存在する場合、再起動プ
ロセスはログファイル１２７内のメッセージを消去す
る。

【００１８】フォールトトレラントコンピューティング
システム１０１には、ここで言及すべきいくつかの特性
が存在する。第１に、システム１０１は、ハードウェア
またはノード上で動作するオペレーティングシステムが
何であっても変更は不要である。フォールトトレラント
プロセス１０３は通常のユーザプロセスであり、デーモ
ン１０４はユーザプロセスを使用して実現される。さら
に、ｌｉｂｆｔ、および、ｗａｔｃｈｄデーモンによっ
て実行されるコードはプログラミング言語Ｃで書かれて
おり、さまざまなオペレーティングシステムのもとで実
行するように容易に適合可能である。第２に、ｗａｔｃ
ｈｄデーモン１０４を有するノードでは、ｌｉｂｆｔ１
１３からのルーチンをプロセスによって実行されるコー
ド内に単に組み込むことによって、プロセスをフォール
トトレラントプロセス１０３とすることが可能である。
アプリケーションプログラマは、アプリケーションコー
ド内でフォールトトレラント機能を再実現する必要はな
い。第３に、システム１０１は高度の柔軟性を提供す
る。ｌｉｂｆｔ１１３内のルーチンによって、アプリケ
ーションプログラマは、アプリケーションに要求される
フォールトトレランスの量を正確にプログラムに与える
ことができる。さまざまなオプションが可能である。一
方では、単に、ｗａｔｃｈｄデーモン１０４にプロセス
を登録することができる。これによって、デーモン１０
４はプロセスを監視し、必要な場合には、プロセスのメ
モリの一部をクリティカルメモリ１１５であると宣言
し、プロセスがデーモン１０４によって再起動された後
に復元可能なようにクリティカルメモリ１１５をクリテ
ィカルメモリコピー１２５に定期的に保存することによ
って、プロセスを再起動する。他方では、再起動したプ
ロセスがメッセージを消去することができるようにログ
ファイル１２７内のクリティカルメッセージのログを作
成する。

【００１９】［１以上のノードを有するシステムにおけ
るｗａｔｃｈｄおよびｌｉｂｆｔの概観：図２］図１の
システムは、単一ノードのハードウェアまたはオペレー
ティングシステムが決して故障しない場合には完全に十
分であるが、ハードウェアまたはオペレーティングシス
テム故障の場合には役に立たない。この困難は、分散シ
ステムの自然な冗長性を利用することによって解決され
る。分散システム内のある与えられたノードが故障する
ことはあるが、システム内のすべてのまたは大部分のノ
ードが同時に故障することは極めてまれである。結果と
して、あるノード上のフォールトトレラントプロセス１
０３が他のノード上で再起動されることが可能であれ
ば、プロセス１０３は最初のノード上のハードウェアお
よびオペレーティングシステムの故障に耐性があること
になる。

【００２０】図２にこのような分散システムを示す。シ
ステム２０１は、Ａ、Ｂ、およびＣとラベルされた３つ
のノード２０３を有する。各ノードは少なくとも１つの
プロセッサおよびメモリを有するとともに、少なくとも
１つの他のノードと通信するための通信リンクを有す
る。各ノードはｗａｔｃｈｄデーモン１０４を有し、従
って、フォールトトレラントプロセス１０３をも有する
ことが可能である。図２には３つのそのようなフォール
トトレラントプロセス１０３（１０３（０）、１０３
（１）、および１０３（２））が存在する。各ノードの
デーモン１０４は、プロセス１０３にローカルな状態の
みならず、他のノード２０３の状態をも監視する。好ま
しい実施例では、監視中のデーモン１０４と、それが監
視するノード２０３との関係は、システム２０１内のノ
ード２０３がフォールト診断のための適応リング２１１
を形成するようなものである。すなわち、デーモン１０
４（Ａ）はノード２０３（Ｂ）を監視し、デーモン１０
４（Ｂ）はノード２０３（Ｃ）を監視し、デーモン１０
４（Ｃ）はノード２０３（Ａ）を監視する。デーモン１
０４がどのノード２０３を監視するかは、ノードリスト
（ＮＬ）２０５によって決定される。ノードリスト２０
５の同一コピーが各ノード内のデーモン１０４に利用可
能である。ノード２０３（ｉ）が故障すると、この事実
は監視中のデーモン１０４によって注目され、監視中の
デーモン１０４は、ノード２０３（ｉ）の損失を反映す
るようにノードリスト２０５を変更するよう、生き残っ
ているノードにメッセージを同報する。

【００２１】もちろん、ノード内のｗａｔｃｈｄデーモ
ン１０４が他のノードからのフォールトトレラントプロ
セス１０３を再起動する場合、そのプロセス１０３の状
態のコピーを有しなければならない。すなわち、システ
ム２０１におけるデーモン１０４のもう１つの機能は、
プロセス１０３の状態のコピーを維持することである。
状態はファイルに格納され、プロセスのクリティカルメ
モリコピー１２５およびログファイル１２７を含む。図
２では、プロセス状態のコピーはプロセス番号と′記号
によって指定されている。例えば、１０３（１）′は、
ノード２０３（Ａ）からのノード２０３（Ｃ）上でのプ
ロセス１０３（１）の状態を示し、コピー１０３
（０）′は、ノード２０３（Ｂ）からのノード２０３
（Ａ）上でのプロセス１０３（０）の状態を示す。図２
から分かるように、プロセス状態は、監視されているノ
ード２０３から監視中のｗａｔｃｈｄデーモン１０４の
ノード２０３へコピーされる。コピーは監視されている
ノードのデーモン１０４によって作成され、プロセス１
０３のクリティカルメモリコピー１２５またはログファ
イル１２７に大きな変化があるごとに監視中のデーモン
１０４に送られる。システム２０１では、単一のコピー
のみが作成されるため、システム２０１のリング２１１
内の隣接する２つのノードが故障しなければ再起動は可
能である。もちろん、複数のコピーを作成することが可
能である。例えば、デーモン１０４（Ａ）は、プロセス
１０３（１）の状態のコピーをデーモン１０４（Ｃ）に
与えることができる。またデーモン１０４（Ｃ）はプロ
セスの状態のコピーをデーモン１０４（Ｂ）に与えるこ
とができる。その場合、プロセス１０３（１）の再起動
を不可能にするためには、システム２０１の全ノードが
故障しなければならない。

【００２２】上記から明らかなように、各デーモン１０
４は、各フォールトトレラントプロセス１０３がシステ
ム２０１内のどこで動作中であるかを知らなければなら
ない。この情報は状態テーブル２０７に含まれ、各デー
モン１０４はそれと同一のコピーを有する。以下で詳細
に説明するように、各ｗａｔｃｈｄデーモン１０４がプ
ロセスを起動または再起動する際に他のすべてのデーモ
ン１０４へメッセージを送信し、各デーモン１０４がそ
のようなメッセージに応答してそのメッセージによって
要求されるとおりに状態テーブル２０７を更新すること
によって、状態テーブル２０７は一貫性が保持される。

【００２３】ノード２０３（ｉ）がサービスに復帰する
と、そのノード内のｗａｔｃｈｄデーモン１０４（ｉ）
は、デーモン１０４（ｉ）によって監視されているノー
ド内のデーモン１０４から状態テーブル２０７のコピー
を取得する。状態テーブル２０７は、どのノード２０３
がノード２０３（ｉ）にローカルなプロセス１０３を現
在実行中であるか、および、そのプロセスを再起動する
のに必要な状態を含むファイルを示す。デーモン１０４
（ｉ）は、そのプロセスを現在実行中のノードからファ
イルのコピーを取得し、そのコピーを使用してプロセス
を再起動する。上記のように、デーモン１０４（ｉ）
は、プロセスを再起動する際に、システム２０１内の他
のデーモン１０４にメッセージを送り、デーモン１０４
が再起動されたプロセスを実行中である場合、そのデー
モン１０４はそのプロセスの実行を中止し、プロセス１
０３が現在ノード２０３（ｉ）上で実行されていること
を示すように状態テーブル２０７を変更する。他のすべ
てのデーモン１０４は単にこのように状態テーブル２０
７を変更する。

【００２４】各デーモン１０４は、以下のアルゴリズム
に従って動作する。このアルゴリズムでは、各フォール
トトレラントプロセス１０３は識別子（ｉで示す）を有
する。さらに、プロトコルで使用される４個の補助変数
が存在する。１．ｐ_i：プロセスｉが実行されることになる基本ノー
ドの名前。この情報は状態テーブル２０７から分かる。２．ｆ_i：プロセスｉの連続故障の回数。３．ＬｏｃａｌＨｏｓｔ：ローカルホスト名。４．ＭｙＷａｒｄ：監視することになるノードの名前。５．ＭｙＯｌｄＷａｒｄ：前に監視していたノードの名
前。

【００２５】アルゴリズムのクリティカル状態ファイル
は、プロセスのクリティカルメモリコピー１２５および
ログファイル１２７を含む。このファイルは、プロセス
によって実行されるプログラムの開発者によって提供さ
れる機構によって維持される。または、ｌｉｂｆｔフォ
ールトトレラントライブラリ１１３によって提供される
機構によって維持される。

【００２６】１．／＊初期化＊／（ａ）作業ノード２０３（ランダムに選択）から状態テ
ーブル２０７を取得する；他のノード２０３が生きてい
ない場合、その状態テーブルを初期化する；（ｂ）ローカルに実行すべき各プロセスｉに対して、ｉ．状態テーブルからｐ_iを取得する；ｉｉ．ノードｐ_iからプロセスの最新の状態を取得す
る；ｉｉｉ．プロセスｉを再起動し、状態テーブルをグロー
バルに更新する；２．永久ループ：ＢＥＧＩＮ（ａ）各プロセスｉに対してループ：ＢＥＧＩＮｉ．状態テーブルからｐ_iを取得する；ｉｉ．ｐ_i＝ＬｏｃａｌＨｏｓｔである場合、Ａ．プロセスｉが生きていてハングしていない場合、ｆ_i＝０；ｃｏｎｔｉｎｕｅ；Ｂ．ｆ_iをインクリメント；Ｃ．ｆ_i＜ｍａｘ_iである場合、プロセスｉを再起動し、
状態テーブルをグローバルに更新する；ｅｌｓｅｆ_i＝ｍａｘ_iである場合、プロセスｉを回復
するよう、バックアップノードに通知する；ｅｌｓｅｆ_i＞ｍａｘ_iである場合、緊急警告メッセー
ジを印字する；ｉｉｉ．ｅｌｓｅノードＭｙＷａｒｄが故障した場
合、Ａ．ＭｙＯｌｄＷａｒｄをＭｙＷａｒｄにセットする；Ｂ．新しい監視ノードを見つけ、それにＭｙＷａｒｄを
セットする；Ｃ．ｐ_i＝ＭｙＷａｒｄである場合、／＊プロセスの
バックアップになる＊／ＭｙＷａｒｄからプロセスｉのすべてのクリティカル状
態ファイルをコピーする；Ｄ．ｅｌｓｅｐ_i＝ＭｙＯｌｄＷａｒｄである場合、
／＊プロセスの基本ノードが故障した＊／プロセスｉを再起動し、状態テーブルをグローバルに更
新する；すべてのクリティカル状態ファイルをバックア
ップにコピーする；ｉｖ．ｅｌｓｅＡ．プロセスｉがローカルに実行中である場合、そのプ
ロセスの実行を停止する；ＥＮＤ；（ｂ）イベント（時間切れまたはプロセスクラッシュ）
を待機する；ＥＮＤ；

【００２７】［１．ノード故障およびサービスへの復帰
の例］ノード故障およびサービスへの復帰がいかに動作
するかをさらに詳細に見るため、例として、上記のノー
ド２０３（Ａ）、２０３（Ｂ）、および２０３（Ｃ）の
システムを考える。説明を簡単にするため、ｙｅａｓｔ
ｄという単一のプロセス１０３のみを考える。このプロ
セスは、ｙｅａｓｔｄ．ｓｔａというファイルにその状
態を定期的に保存し、ログファイルｙｅａｓｔｄ．ｌｏ
ｇを有すると仮定する。ノードＡはノードＢを監視し、
ノードＢはノードＣを監視し、ノードＣはノードＡを監
視する。最初に、すべてのノードは生きており、プロセ
スｙｅａｓｔｄはノードＡで実行されている。以下のシ
ナリオを考える。

【００２８】１．ノードＣがダウンする：・ノードＡは何もしない；・ノードＢはノードＡからファイルｙｅａｓｔｄ．ｓｔ
ａおよびｙｅａｓｔｄ．ｌｏｇをコピーし、ノードＡの
監視およびプロセスｙｅａｓｔｄを開始する；２．ノードＣがシステムに再結合する：・ノードＡは何もしない；・ノードＣはノードＡからファイルｙｅａｓｔｄ．ｓｔ
ａおよびｙｅａｓｔｄ．ｌｏｇをコピーし、ノードＡの
監視およびプロセスｙｅａｓｔｄを開始する；・ノードＢはノードＡの監視を停止し、ノードＣの監視
を開始する；３．ノードＡがダウンする：・ノードＣはプロセスｙｅａｓｔｄを再起動し、状態テ
ーブル２０７およびノードリスト２０５をグローバルに
更新し、ノードＢの監視を開始する；・ノードＢはノードＣからファイルｙｅａｓｔｄ．ｓｔ
ａおよびｙｅａｓｔｄ．ｌｏｇをコピーし、ノードＣの
監視およびプロセスｙｅａｓｔｄを開始する；４．ノードＡがシステムに再結合する：・ノードＡはノードＣからファイルｙｅａｓｔｄ．ｓｔ
ａおよびｙｅａｓｔｄ．ｌｏｇをコピーし、プロセスｙ
ｅａｓｔｄを再起動し、状態テーブル２０７およびノー
ドリスト２０５をグローバルに更新し、ノードＢの監視
を開始する；・ノードＣはｙｅａｓｔｄプロセスの実行を停止し、ノ
ードＢの監視を停止し、ノードＡの監視を開始する；・ノードＢはプロセスｙｅａｓｔｄの監視を停止する；５．プロセスｙｅａｓｔｄがクラッシュするがノードＡ
は生きている：・ノードＡはプロセスを再起動する；再起動が指定回数
失敗した場合、ノードＡはこのプロセスを回復するよう
ノードＣに通知する；・ノードＣは、何もしないか、または、ノードＡによっ
て要求された場合、ｙｅａｓｔｄプロセスを再起動し、
状態テーブル２０７をグローバルに更新する；・ノードＢは、何もしないか、または、プロセスがノー
ドＣによって再起動された場合、ノードＣから状態ファ
イル（ｙｅａｓｔｄ．ｓｔａおよびｙｅａｓｔｄ．ｌｏ
ｇ）をコピーし、ノードＣ上のプロセスｙｅａｓｔｄの
監視を開始する；

【００２９】各デーモン１０４は、状態テーブル２０７
を維持する。プロセスがノード上で再起動されると、そ
のノードのデーモン１０４は他のすべてのノードに更新
メッセージを送る。

【００３０】ネットワークの一時的故障が生じた場合、
または、ノード２０３がシステムに再結合した場合、プ
ロセス１０３の複数のコピーが同時に実行されている可
能性がある。いつでもプロセスの１つのアクティブコピ
ーのみが実行されていることを保証するため、各ｗａｔ
ｃｈｄデーモン１０４は、他のノード２０３上で実行さ
れることになるプロセス１０３がローカルにも実行され
ているかどうかを常にチェックしなければならない。ロ
ーカルにも実行されている場合、デーモン１０４は、プ
ロセスに終了シグナルを送ることによってノード２０３
のそのプロセス１０３の実行を停止させなければならな
い。例えば、上記の例のシナリオ４を考える。ノードＡ
が故障した後、ノードＡ上で実行されていたプロセスｙ
ｅａｓｔｄはノードＣ上で再起動される。しばらく後、
ノードＡは修復されシステムに再結合する。ノードＡ上
のｗａｔｃｈｄデーモンはフォールトトレラントプロセ
スリスト１３９を読み出し、ノードＡはプロセスｙｅａ
ｓｔｄを実行すべきであることを知る。ノードＡ上のｗ
ａｔｃｈｄデーモンはまず作業ノード（例えばノード
Ｂ）から最新の状態テーブル２０７を読み出し、プロセ
スｙｅａｓｔｄがノードＣ上で実行中であることを知
る。ｙｅａｓｔｄプロセスを実行する責任を引き継ぐた
め、ノードＡはまずノードＢからプロセスの状態ファイ
ルをコピーした後で、プロセスを再起動する。プロセス
の再起動が成功すると、ノードＡ上のｗａｔｃｈｄデー
モンは他のすべてのノードに、それらの状態テーブル２
０７を更新する更新メッセージを同報する。この更新
後、ノードＣは、ノードＡが立ち上がり、ｙｅａｓｔｄ
プロセスがノードＡ上で実行されていることを知る。従
って、ノードＣはもはやそのプロセスを実行する必要が
ない。この場合、デーモン１０４（Ｃ）は、ノード２０
３（Ｃ）で実行中のプロセス１０３に終了シグナルを送
る。プロトコルによって、ノードＡがシステムに再結合
する際にプロセスｙｅａｓｔｄを引き継ぐことに注意す
べきである。このステップがないと、すべてのプロセス
１０３は最後に故障したノード２０３上のみで最終的に
実行されることになる。

【００３１】［２．リング再構成の例］リング２１１が
（故障または修復によって）再構成される場合は、ノー
ド２０３間でクリティカル状態ファイルをコピーするこ
とが必要である。例えば、上記の例のシナリオ３を考え
る（複製度数は２であると仮定する）。ノードＡが故障
する前は、ノードＡ上のプロセスｙｅａｓｔｄはその状
態をノードＣ上にチェックポイントするが、ノードＢ上
にはしない。従って、ノードＢはプロセスｙｅａｓｔｄ
の状態を有しない。ノードＡが故障すると、ノードＣは
以前の状態でそのプロセスを再起動し、同時に、ノード
ＢはノードＣからそのプロセス（すなわちｙｅａｓｔ
ｄ）の状態ファイルをコピーする。ノードＣからノード
Ｂへの状態ファイルのコピーは、回復中のノードＣの故
障の可能性に対処するために必要である。そうでない
と、チェックポイントが確立可能となる前にノードＣも
故障した場合、ノードＢは、プロセスの状態を有しない
ため、プロセスを回復させることができない。

【００３２】［ｗａｔｃｈｄデーモン１０４の詳細］図
３に、いかにしてデーモン１０４が好ましい実施例を実
施するかを示す。図３では、実線矢印は情報の流れを、
破線矢印はプロセス間の親子関係を示す。ｗａｔｃｈｄ
デーモン１０４は、モニタ（ＭＯＮ）３０１および状態
サーバ（ＳＴＡＴＥＳＲＶＲ）３０３という２つのユ
ーザプロセスによって実現される。この設計には２つの
理由がある。

【００３３】・デーモン１０４の故障の可能性を最小に
するため、デーモン１０４は、不正確な実行の可能性が
非常に少なくなるように、十分単純な要素からなるもの
でなければならない。・デーモン１０４は、時間依存動作および非同期動作の
両方を実行することができなければならない。非同期動
作は、時間依存動作に干渉してはならない。

【００３４】モニタ３０１から説明する。モニタ３０１
は以下のことを行う。・モニタ３０１は、動作を開始すると、初期化動作を実
行する。これには、ＵＮＩＸオペレーティングシステム
のＦＯＲＫ関数を使用して状態サーバ３０３を作成する
ことが含まれる。・初期化後、モニタ３０１は以下のことを行う。１．プロセス１０３をポーリングし、それらのプロセス
がクラッシュしているかどうか判定する。２．クロック３０２を監視し、状態サーバ３０３にメッ
セージを送る時刻かどうか判定する。３．プロセス１０３が死んでいることをポーリングが示
した場合、または、時刻メッセージが送られる必要があ
る場合、状態サーバ３０３にメッセージを送る。４．状態サーバ３０３がクラッシュしている場合、モニ
タ３０１は状態サーバ３０３を再起動する。

【００３５】デーモン１０４の他のすべての動作は、状
態サーバ３０３によって実行される。特に、状態サーバ
３０３は、ポーリング以外の方法によって、監視されて
いるノード２０３が生きているかどうか、および、プロ
セス１０３がクラッシュまたはハングしているかどうか
判定し、テーブル１３９、１４１、２０５、および２０
７を維持し、プロセス状態のバックアップコピーを他の
ノードに提供する。

【００３６】モニタ３０１によって実行される動作をさ
らに詳細に説明すれば、モニタ３０１は、ＵＮＩＸオペ
レーティングシステムのｋｉｌｌシステムコールを使用
することによって、フォールトトレラントプロセス１０
３がクラッシュしているかどうかを判定する。このシス
テムコールは、シグナル０とともに使用すると、チェッ
クされるプロセスの動作に影響を与えずに、プロセスが
死んでいる場合はエラー値を返す。このポーリングは、
図３では矢印３１０で表されている。モニタ３０１は、
プロセス１０３が死んでいることを検出すると、メッセ
ージ（矢印３０５で示す）を状態サーバ３０３へ送る。
これはそのプロセスを再起動する。モニタ３０１は、い
ずれの時刻がクリティカルであるかを示す状態サーバ３
０３からのメッセージに応答して、クリティカル時刻を
記憶する。クリティカル時刻になると、モニタ３０１は
その時刻を示すメッセージを状態サーバ３０３に送る
（矢印３０５で示す）。モニタ３０１は、ＵＮＩＸオペ
レーティングシステムのＳＩＧＣＨＬＤシグナルによっ
て、状態サーバ３０３がクラッシュしていることを検出
する。このシグナルは、子プロセスが死んだ場合に親プ
ロセスが受け取るものである。

【００３７】デーモン１０４の残りの動作は状態サーバ
３０３によって実行される。状態サーバ３０３は、他の
ノード２０３内のデーモン１０４と通信し、ローカルに
動作しているフォールトトレラントプロセス１０３の状
態を矢印３０６で示すようにポーリング以外の方法によ
って監視し、矢印２０９で示すように、リング２１１内
での隣接ノード２０３の状態を監視する。状態サーバ３
０３は、次のノード２０３のデーモン１０４にメッセー
ジを送ることによってそのノードの状態を監視する。そ
のデーモン１０４が応答しない場合、その隣接ノード２
０３はダウンしていると仮定される。隣接ノード２０３
がダウンしていることが検出されると、状態サーバ３０
３は、そのノードがダウンしていることを示すメッセー
ジを他のデーモン１０４に送り、リング２１１を再構成
するのに必要な作業を自己のノード２０３内で行う。

【００３８】ローカルフォールトトレラントプロセス１
０３が死んでいるかまたはハングしているかどうか判定
するために状態サーバ３０３によって使用される方法
は、以下のことを含む。図３に示すように、モニタ３０
１が属するノード２０３上で動作しているすべてのフォ
ールトトレラントプロセス１０３（ローカルフォールト
トレラントプロセス（図３のＬＦＴＰＳ３１７））は状
態サーバ３０３の子プロセスである。その結果、これら
のプロセス１０３のうちの１つが死ぬと、状態サーバ３
０３は、ＵＮＩＸオペレーティングシステムから、子プ
ロセスのうちの１つが死んだことを示すＳＩＧＣＨＬＤ
シグナルを受け取る。

【００３９】さらに、状態サーバ３０３は、あるＵＮＩ
Ｘオペレーティングシステムファシリティを使用して、
フォールトトレラントプロセス１０３がハングしている
かどうか能動的に判定する。このファシリティは、他の
プロセスの指定ポートがメッセージを受け取ることがで
きない場合にビジービットをセットし、そのビジービッ
トがクリアされるとそのメッセージを送信したプロセス
に割り込みをかけるというものである。状態サーバ３０
３はこのファシリティを使用して、プロセス１０３にメ
ッセージを送り、ある時間区間待機する（この時間区間
の終点は、モニタ３０１からのメッセージによって示さ
れる）。ビジービットがこの時間区間中にクリアされな
い場合、状態サーバ３０３は、プロセス１０３がハング
していると判定する。

【００４０】最後に、状態サーバ３０３は、フォールト
トレラントプロセス１０３がｌｉｂｆｔ１１３によって
提供されるハートビート関数を実行しているときはいつ
でも、そのプロセスがモニタ３０１に送るメッセージを
監視することによって、そのプロセスがハングしている
かどうか判定することができる。この関数に送られるメ
ッセージは、プロセス１０３からの次のメッセージが到
着する前に超過してはならない時間を指定するものであ
り、その指定された時間を超過するまでに状態サーバ３
０３が次のメッセージを受信しない場合、状態サーバ３
０３はプロセス１０３がハングしていると判定する。こ
の場合も、タイミングはモニタ３０１によって実行され
る。

【００４１】好ましい実施例では、モニタ３０１または
状態サーバ３０３が、ローカルフォールトトレラントプ
ロセス１０３がハングまたはクラッシュしていると判定
した場合、状態サーバ３０３がＵＮＩＸオペレーティン
グシステムのＦＯＲＫシステムコールを使用することに
よってプロセス１０３を再起動して新しいプロセスを作
成する（矢印１３５）。この新しいプロセスは、クラッ
シュまたはハングしたプロセスと同じコードを実行し、
クラッシュまたはハングしたプロセス１０３のために存
在するクリティカルメモリコピー１２５やログファイル
１２７を使用する。再起動されたプロセス１０３が再び
クラッシュまたはハングした場合、状態サーバ３０３
は、監視中のデーモン１０４に対して、その監視中のデ
ーモン１０４のノードでプロセス１０３を再起動すべき
であることを示すメッセージをそのデーモンに送ること
ができる。もちろん、再起動されるプロセス１０３がク
リティカルメモリコピー１２５やログファイル１２７を
有する場合、そのコピーおよびログファイルをその監視
中のデーモン１０４のノードにコピーしておかなければ
ならない。

【００４２】デーモン１０４が属するノード２０３がダ
ウンし、動作を再開しつつある場合、状態サーバ３０３
は、そのノード２０３が再起動されたことを示すメッセ
ージを他のすべてのデーモン１０４に送る。同様に、状
態サーバ３０３は、他のノード２０３上にコピーを有す
るフォールトトレラントプロセス１０３が状態サーバ３
０３のノードで再起動されるときにはいつも、メッセー
ジを他のすべてのデーモン１０４に送る。さらに、プロ
セス１０３のクリティカルメモリコピー１２５またはロ
グファイル１２７のコピーが、モニタ１０３が属するノ
ードを監視するノード２０３に送られる必要がある場
合、状態サーバ３０３は、コピーされるべきデータを含
むメッセージを、監視中のノード内のデーモン１０４に
送る。

【００４３】好ましい実施例では、状態サーバ３０３
は、さらに以下のような機能を有する。・フォールトトレラントプロセス１０３によって呼び出
されるいくつかのｌｉｂｆｔ関数に応答する（矢印３０
７）。・モニタ３０１からの（矢印３０５）、他のデーモン１
０４からの（矢印３１１）、およびローカルフォールト
トレラントプロセス１０３からの（矢印３０７）メッセ
ージに応答してテーブル１３９、１４１、２０５、およ
び２０７を維持する。・ローカルフォールトトレラントプロセス１０３、およ
び、ノードがバックアップノードとして働くフォールト
トレラントプロセス１０３のプロセス状態コピー３１５
を、そのようなコピーを他のノード２０３に提供し他の
ノード２０３のコピーを受け取ることによって、維持す
る。

【００４４】これらの機能のほとんどは、フォールトト
レラントプロセステーブル１３９、フォールトトレラン
トプロセスグループテーブル１４１、ノードリスト２０
５、および状態テーブル２０７に関連する。好ましい実
施例では、これらのすべてのテーブルはファイルに維持
される。以下で、これらのテーブルについてさらに説明
する。

【００４５】［１．リスト２０５、１３９、および１４
１の詳細：図４］図４は、これらのテーブルのうちの３
つ、すなわち、ノードリスト２０５、フォールトトレラ
ントプロセス１３９、およびフォールトトレラントプロ
セスグループ１４１を示す。ノードリスト２０５から説
明すると、システム２０１内の各ノード２０３はリスト
２０５中に単一のノードリストエントリ４０１を有す
る。各ノードのエントリは、ノード２０３の名前４０３
を単に含むだけである。リスト２０５中のエントリの順
序は、リング２１１の構成を決定する。すなわち、リス
ト２０５中のエントリ４０３（ｊ）のノードのデーモン
１０４は、エントリ４０３（ｊ−１）のノード２０３を
監視し、エントリ４０３（０）のノード２０３のデーモ
ン１０４は、エントリ４０３（ｎ）のノード２０３を監
視する。

【００４６】状態サーバ３０３は、監視中のノード２０
３がダウンしていることを検出するか、または、ノード
２０３がダウンしていることを示すメッセージを他のデ
ーモン１０４から受信すると、ノードリスト２０５から
そのノードのエントリを削除する。その削除によって、
モニタ３０１が監視中であるべきノード２０３が影響を
受けると、状態サーバ３０３がそのノードの監視を開始
する。状態サーバ３０３は、デーモン１０４が動作中の
ノードがシステム２０１に再結合しつつあることを示す
メッセージをデーモン１０４から受信すると、必要に応
じてノードリスト２０５を更新し、更新によって必要と
なれば、異なるノード２０３の監視を開始する。上記の
ことから明らかなように、システム２０１内の各ノード
２０３はノードリスト２０５の同一のコピーを有する。

【００４７】次に、フォールトトレラントプロセステー
ブル１３９に移ると、デーモン１０４が属するノード上
で現在アクティブであるか、または、アクティブとなる
可能性のある各フォールトトレラントプロセス１０３
は、テーブル１３９中にエントリ（ＦＴＰＥ）４０５を
有する。各エントリは、プロセス１０３に関する以下の
情報を含む。・フォールトトレラントプロセスの名前４０７。好まし
い実施例では、これは、そのプロセスによって実行中で
あるプログラムのパス名である。・モニタ３０１が、プロセス１０３がクラッシュまたは
ハングしているかどうか判定するためにメッセージを送
るポートのポート番号４０９。・ノード２０３が生きている場合にプロセス１０３が動
作するノードの基本ノード名４１１。・プロセス１０３のクリティカルメモリコピー１２５お
よびログファイル１２７を含むファイルのリストである
クリティカルファイル４１３、ならびに、状態サーバ３
０３が、プロセス１０３がハングしていると結論するま
でに待機すべき最大時間であるタイムリミット（ＴＬ）
４１５。

【００４８】フォールトトレラントプロセスエントリ４
０５内の情報には２つの情報源がある。基本ノードがテ
ーブル１３９の属するノードであるようなプロセス１０
３のエントリ４０５の場合、この情報は、プロセス１０
３、および、クリティカルメモリコピー１２５やログフ
ァイル１２７をデーモン１０４に登録するｌｉｂｆｔ内
の関数によって提供される。このような場合、基本ノー
ド名４１１は、テーブル１３９が属するノードの名前で
ある。基本ノードが他の場所であるようなプロセス１０
３のエントリ４０５の場合は、状態サーバ３０３は、基
本ノード２０３にエントリを作成する際に、基本ノード
をバックアップすることになる１以上のノード２０３内
のｗａｔｃｈｄデーモン１０４にそのエントリの内容を
送り、関連するノード２０３内の状態サーバ３０３がそ
の情報をそのフォールトトレラントプロセステーブル１
３９に加える。１つのバックアップノードが指定されて
いる場合、そのノードのｗａｔｃｈｄデーモン１０４は
基本ノードを監視する。複数のバックアップノードが指
定されている場合、残りのバックアップノードは、その
デーモンが第１のバックアップノードを監視し、以下同
様、となる。

【００４９】フォールトトレラントグループテーブル１
４１に移ると、各エントリ４１７は、フォールトトレラ
ントプロセス名４２１、および、そのフォールトトレラ
ントプロセスが属するグループを示すグループ番号４１
９を含む。あるグループに属するプロセス１０３が再起
動されなければならない場合、そのグループ内の全プロ
セス１０３が同時に再起動される。テーブル１４１の情
報源は、テーブル１３９と同じである。ローカルフォー
ルトトレラントプロセス１０３の場合、その情報はｌｉ
ｂｆｔ関数によって提供される。他のノードからコピー
されたプロセスの場合、その情報は、バックアップされ
ているノードのデーモン１０４によって提供される。

【００５０】フォールトトレラントプロセステーブル１
３９およびフォールトトレラントグループテーブル１４
１の内容から明らかなように、システム２０１からノー
ド２０３が削除された場合またはこのようなノードがシ
ステムに復帰した場合にリング２１１が変化したときに
はいつでも、異なる非ローカルフォールトトレラントプ
ロセスに関する情報が状態サーバプロセス３０３が属す
るノード２０３に格納されなければならないような方法
で、状態サーバデーモン３０３はこれらのテーブルを更
新する。好ましい実施例では、状態サーバプロセス３０
３は、リング２１１の変化を通知されると、ノードリス
ト２０５を更新し、リング２１１の新しい構成が与えら
れるとテーブル１３９および１４１にコピーされなけれ
ばならない情報を含むメッセージをノード２０３に中継
する。テーブル１３９および１４１の内容は、もちろ
ん、ノード内で動作中のローカルフォールトトレラント
プロセス１０３、および、リング２１１内でのそのノー
ドの位置に依存して、ノード２０３ごとに異なる。

【００５１】［２．状態テーブル２０７の詳細：図５］
前記のように、システム２０１内のすべてのノードは状
態テーブル２０７の同一のコピーを有する。状態テーブ
ル２０７には、システム２０１内で動作中のすべてのフ
ォールトトレラントプロセス１０３のエントリがある。
各エントリは以下のフィールドを含む。・フィールド５０３はプロセス名である。・フィールド５０５は、プロセスが現在実行されている
ノードの名前である。・フィールド５０７は、現在のノード上のプロセスと通
信するために使用されるポート番号である。・フィールド５０９は、現在のノード上のプロセスのプ
ロセス識別子である。・フィールド５１１は、好ましい実施例が実現されるＵ
ＮＩＸオペレーティングシステムがプロセスを終了する
ことによって応答するシグナルの指定である。・フィールド５１３はプロセスのクリティカルファイル
のリストである。

【００５２】上のテーブルの情報は以下のようにして取
得される。ノード２０３が（新しいノードとして、また
は、再開動作として）システム２０１に加えられると、
状態サーバ３０３は、既に動作中のノード２０３から状
態テーブル２０７のコピーを要求するメッセージを送
る。そのコピーが返されると、状態サーバ３０３は、そ
のテーブルから自己の状態テーブル２０７を作成する。
前記のように、ノード２０３上の状態サーバ３０３は、
フォールトトレラントプロセス１０３を起動または再起
動するときはいつでも、他のすべてのデーモン１０４に
メッセージを送る。このメッセージは、プロセス名、そ
のプロセスを起動しているノードの名前、ポート番号、
プロセスｉｄ、およびクリティカルファイルのリストを
指定する。ノード２０３の状態サーバ３０３は、そのメ
ッセージを受信すると、状態テーブル２０７にそのプロ
セスのエントリを作成する。状態テーブル２０７にその
プロセスの他のエントリがある場合、状態サーバ３０３
はそのエントリを削除する。また、状態サーバ３０３
は、メッセージに指定されたプロセス１０３を現在実行
中であるかどうか判定する。プロセス１０３のフォール
トトレラントプロセステーブルエントリ４０５があっ
て、そのエントリが、他のノード２０３を基本ノード４
１１として示している場合、状態サーバ３０３はそのプ
ロセスのローカル実行を終了する。この手段によって、
２つの目的が達成される。第１に、システム２０１内の
状態テーブル２０７のすべてのコピーの一貫性が保たれ
る。第２に、フォールトトレラントプロセス１０３は、
基本ノードがダウンするか、そうでなければそのプロセ
スを実行できない場合でなければ、常に基本ノード２０
３上で実行される。

【００５３】［３．テーブル１３９、１４１、２０５、
および２０７の破壊の回避］好ましい実施例では、状態
サーバ３０３は、テーブルを照会するごとに、取得した
データの破壊をチェックする。破壊の証拠が発見された
場合、状態サーバ３０３は他のノード２０３から状態テ
ーブル２０７およびノードリスト２０５の新しいコピー
を取得し、これらのテーブルからすべてのテーブル１３
９、１４１、２０５、および２０７を再構成する。同様
に、状態サーバ３０３は、テーブルを更新または置換す
るときはいつでも、テーブルを更新または置換してから
破壊をチェックする。何か発見された場合、テーブルの
新しいコピーを取得するか、または、上記と同様とな
る。

【００５４】［フォールトトレラントシステム１０１お
よび２０１の動作］フォールトトレラントシステム１０
１および２０１は、好ましい実施例では、ＵＮＩＸオペ
レーティングシステムのシェルプロセスによって実行さ
れるコマンドによって、および、ｌｉｂｆｔ１１３ルー
チンによって、制御される。以下で、システム１０１お
よび２０１の動作を、コマンドおよびｌｉｂｆｔルーチ
ンの説明を通して開示する。

【００５５】［１．ｗａｔｃｈｄデーモン１０４のコマ
ンド］ノード上でｗａｔｃｈｄデーモン１０４を起動す
るには、ｗａｔｃｈｄ［ｎ］を使用する。ただし、ｎ（複製度数）は、デーモン１０
４が動作中のノード２０３上で動作しているプロセスの
状態コピー３１５を有するノード２０３の総数である。
デフォルトの複製度数は２である。ｎが大きくなると、
プロセスはより強固になる。例えば、ｎが２である場
合、２個のノードが同時に故障するとプロセスは回復で
きない。ところが、ｎが３であれば、２つの同時故障が
あってもプロセスは常に回復可能である。しかし、ｎが
大きくなると、チェックポイント動作のオーバヘッドが
多くなる。長い予想寿命および短いダウン時間をもつ実
際的なシステムでは、システムの可用性に関しては最適
の複製度数は２であることが示されている。（ワイ．フ
アン(Y. Huang)、ピー．ジャロート(P. Jalote)、「応
答時間に関するフォールトトレランスの効果−基本サイ
トアプローチの解析」IEEE Transactions on Computer
s、第４１巻第４号第４２０〜４２８ページ（１９９２
年４月）参照。）

【００５６】あるノードから他のノードへフォールトト
レラントプロセスを移動するには、ｍｏｖｅｐｒｏｃ＜ｐｒｏｃ＞＜ｎｏｄｅ＞を使用する。ただし、＜ｎｏｄｅ＞は宛先ノードであ
る。ソースノードは、状態テーブル２０７から見つけら
れるため不要であることに注意すべきである。このコマ
ンドの目的は負荷均衡である。これによって、プロセス
はより軽負荷のノードに移動され、プロセスの応答時間
が改善される。もちろん、プロセスが移動される場合、
関連するノードのフォールトトレラントプロセステーブ
ル１３９およびフォールトトレラントグループテーブル
１４１もそれに従って更新され、移動されたプロセスが
新しいノードで実行を開始されると、システム内の状態
テーブル２０７は前記のように更新される。

【００５７】システム内のフォールトトレラントプロセ
スをオンライン付加または削除するには、ａｄｄｗａｔｃｈ＜ｎａｍｅまたはｐｉｄ＞＜ｐａ
ｔｈ＞＜ｐｏｒｔ＞＜ｎｏｄｅ＞＜ｔｉｍｅ＞
［＜ｆｉｌｅｓ＞］ｄｅｌｗａｔｃｈ＜ｎａｍｅ＞を使用する。ただし、＜ｎｏｄｅ＞はプロセス＜ｎａｍ
ｅ＞が動作中の基本ノードである。＜ｎｏｄｅ＞はノー
ドのシステム名またはｌｏｃａｌという名前である。後
者は、ローカルマシン名を表すキーワードである。＜ｐ
ｏｒｔ＞はプロセスが使用中のソケットポート番号であ
る（ソケットがない場合は０）。＜ｐａｔｈ＞は、プロ
セス＜ｎａｍｅ＞または＜ｐｉｄ＞のバイナリが発見さ
れる場所へのフルパスを与える。この情報は、引数＜ｆ
ｉｌｅｓ＞がプロセス状態コピー３１５を含むファイル
のリストである場合に必要となる。例えば、プロセスｙ
ｄがマシンｇｒｙｐｈｏｎ上で動作中であるとする。ｗ
ａｔｃｈｄデーモンにこのプロセスを監視させるために
は、ａｄｄｗａｔｃｈｙｄ／ｕｓｒ／ｌｏｃａｌ／ｂｉ
ｎ／ｙｄ０ｇｒｙｐｈｏｎ０を使用することができる。また、これらのコマンドの実
行によって、テーブル１３９、１４１、および２０７が
変更される。

【００５８】システムにノードをオンライン付加または
削除するには、ａｄｄｎｏｄｅ＜ｎｏｄｅ＞ｄｅｌｎｏｄｅ＜ｎｏｄｅ＞を使用する。これらのコマンドに応答して、すべてのデ
ーモン１０４はそのノードリスト２０５を修正し、リン
グ２１１の再構成によって直接影響を受けるデーモン
は、プロセス状態コピー３１５を転送し、フォールトト
レラントプロセステーブル１３９およびフォールトトレ
ラントグループテーブル１４１を、この再構成によって
要求されるように修正する。ノード２０３の削除の場
合、このノード上で動作しているプロセス１０３のエン
トリは状態リスト２０７から削除される。

【００５９】［２．システム１０１および２０１で使用
されるｌｉｂｆｔ１１３関数］システム１０１および２
０１で使用されるｌｉｂｆｔ１１３関数の以下の説明
は、まず、チェックポイントおよび回復動作で使用する
関数、続いて、ｗａｔｃｈｄデーモン１０４との対話の
ために使用される関数、そして最後に、フォールトトレ
ラントソケット機構を提供する状態テーブル２０７にリ
ストされたプロセスポートを使用する関数の順で行う。

【００６０】チェックポイントは、ｌｉｂｆｔにおける
回復のための基本技術である。プログラムは、安全状態
にあるときに、その状態を安定な記憶域にチェックポイ
ントする。後で、プログラムの実行中に予想しない状態
が生じた場合、システムはその安全状態を復元し、エラ
ーから回復することができる。

【００６１】従来のフォールトトレラントシステムで
は、チェックポイントは一般に、プロセスのアドレス空
間内のすべてのデータを安定記憶域に保存していた。チ
ェックポイント効率を改善するため、ｌｉｂｆｔは、ユ
ーザがクリティカルデータ構造体およびクリティカル変
数を指定することができる機構を提供している。チェッ
クポイントが必要なとき、これらのクリティカルデータ
のみが保存される。

【００６２】［３．クリティカルデータの指定］単純な
型の変数は、関数ｃｒｉｔｉｃａｌ（）を使用すること
によってクリティカルであると宣言することができる。

【００６３】［３．１クリティカル変数を宣言する関
数］

【表１】

【００６４】関数ｃｒｉｔｉｃａｌ（）および関数ｔ＿
ｃｒｉｔｉｃａｌ（）は、引数ａｄｄｒによってポイン
タ参照される記憶域を、クリティカルメモリ１１５の一
部であリ、従って、チェックポイント動作が実行される
場合にクリティカルメモリコピー１２５にコピーされる
べきである記憶域として識別する。これら２つの関数の
引数は、ポインタ（変数をポインタ参照する）と整数
（そのポインタによってポインタ参照される変数のサイ
ズ）の０個以上の対からなる。引数リストは、対をなさ
ない０で終了する。関数ｔ＿ｃｒｉｔｉｃａｌ（）は、
プロセス内のスレッドのためにクリティカル変数を登録
する。ｔｈｒｅａｄｉｄは、０から＿ＦＴＭＡＸＴＨＲ
ＥＡＤ（ｌｉｂｆｔｉｎｔ．ｈで定義されるパラメー
タ）までの値をとる整数である。関数ｃｒｉｔｉｃａｌ
（．．．）は関数ｔ＿ｃｒｉｔｉｃａｌ（０，．．．）
と等価である。

【００６５】関数ｕｎｃｒｉｔｉｃａｌ（）は、指定さ
れた記憶域をクリティカルメモリ１１５から削除する。
この関数の引数は、もはやクリティカルメモリ１１５の
一部ではなく、従ってもはやチェックポイント動作によ
ってコピーされるものではない変数のアドレスのリスト
からなる。この場合も、最後の引数は対をなさない０で
なければならない。関数ｔ＿ｕｎｃｒｉｔｉｃａｌ（）
は、プロセス１０３内のスレッドのクリティカルメモリ
１１５から記憶域を削除する。

【００６６】関数ａｌｌ＿ｃｒｉｔｉｃａｌ（）は、プ
ロセス１０３のすべての変数をクリティカルメモリ１１
５に入れる。同様に、関数ａｌｌ＿ｕｎｃｒｉｔｉｃａ
ｌ（）は、クリティカルメモリ１１５からプロセス１０
３のすべての変数を削除する。

【００６７】関数ｓａｖｅ＿ａｌｌ＿ｇｌｏｂａｌ（）
は、プロセス１０３のすべてのグローバル変数を保存す
るために使用される。この関数は、ｇｌｂｇｅｎと呼ば
れるツールによって実現されている。このツールは、周
知のｃｉａプログラム解析ツールによって生成されるｃ
データベースからグローバルデータのリストを作成す
る。

【００６８】［３．２クリティカルメモリを管理する
関数］ｌｉｂｆｔはまた、メモリ１０５の領域を、クリ
ティカルメモリ１１５に属するものとして指定し、クリ
ティカルメモリ１１５に属する領域の一部の割り当てお
よび解放を行う関数を提供する。その関数は以下のとお
りである。

【表２】

【００６９】関数ｆｔ＿ｓｔａｒｔ（）は、仮想メモリ
１０５の一部を、クリティカルアドレス空間１１５に属
するものとして指定するために使用される。指定される
メモリのサイズは、パラメータｓｉｚｅによって与えら
れる。ｓｉｚｅが負の場合、デフォルトサイズの６４ｋ
バイトが与えられる。最初に指定したサイズが十分でな
い場合、クリティカルメモリ１１５のサイズは必要に応
じて自動的に増加される。クリティカルメモリ１１５か
ら空間を取得するには、関数ｆｔｍａｌｌｏｃ（）、ｆ
ｔｃａｌｌｏｃ（）またはｆｔｒｅａｌｌｏｃ（）を使
用する。これらの使用法は、ＵＮＩＸオペレーティング
システム関数のｍａｌｌｏｃ（）、ｃａｌｌｏｃ（）お
よびｒｅａｌｌｏｃ（）と同一である。空間をクリティ
カルメモリ１１５に返すには、関数ｆｔｆｒｅｅ（）を
使用する。その使用法は、ＵＮＩＸオペレーティングシ
ステム関数のｆｒｅｅ（）と同一である。

【００７０】［４．チェックポイントおよび回復関数］
フォールトトレラントプロセス１０３によって実行され
ているプログラムは、クリティカルメモリ１１５をクリ
ティカルメモリコピー１２５にコピーするためにｌｉｂ
ｆｔ関数であるｃｈｅｃｋｐｏｉｎｔ（）関数を使用
し、クリティカルメモリ１１５の内容をクリティカルメ
モリコピー１２５から復元するためにｒｅｃｏｖｅ
ｒ（）関数を使用する。

【００７１】［４．１概要］

【表３】

【００７２】好ましい実施例では、クリティカルメモリ
コピー１２５は、ファイルに維持されるか、または、永
続性の仮想メモリ１０５の一部に維持される。整数ｆｌ
ａｇは、どのオプションが使用されるかを示す。関数ｔ
＿ｃｈｅｃｋｐｏｉｎｔ（）が実行されると、全クリテ
ィカルメモリ１１５はクリティカルメモリコピー１２５
にコピーされる。チェックポイントが成功すると、関数
ｔ＿ｃｈｅｃｋｐｏｉｎｔ（）は１を返し、そうでない
場合は−１を返す。関数ｔ＿ｒｅｃｏｖｅｒ（）が実行
されると、全クリティカルメモリ１１５はクリティカル
メモリコピー１２５から回復される。回復が成功する
と、関数ｒｅｃｏｖｅｒ（）は１を返し、そうでない場
合は−１を返す。

【００７３】一般に、ユーザが、クリティカルメモリコ
ピー１２５がファイル上に確保されるように指定した場
合、ｌｉｂｆｔは実行時にそのファイルに名前を提供す
る。しかし、ユーザが、固有の名前を、関数ｆｔ＿ｓｔ
ａｒｔ（）またはｓｅｔｓｔａｆｉｌｅ（）に対する引
数として与えることもできる。ｔｈｒｅａｄｉｄパラメ
ータは、ｔ＿ｃｈｅｃｋｐｏｉｎｔおよびｔ＿ｒｅｃｏ
ｖｅｒにおいて、各スレッドに対してクリティカルメモ
リ１１５をチェックポイントし回復するために使用され
る。これは、チェックポイントファイルの履歴を保持す
る必要がある場合、または、マルチスレッド環境でチェ
ックポイント機構を使用する場合に有用である。マルチ
スレッドを使用しない場合、ｔｈｒｅａｄｉｄには値０
を入れなければならない。関数ｒｍｃｈｅｃｋｐｏｉｎ
ｔ（）はチェックポイントファイルを削除する。これ
は、チェックポイント機構がセマフォとして使用される
場合に有用である。

【００７４】関数ｃｈｅｃｋｐｏｉｎｔ（ｆｌａｇ）は
ｔ＿ｃｈｅｃｋｐｏｉｎｔ（０，ｆｌａｇ）と等価であ
る。同様に、関数ｒｅｃｏｖｅｒ（ｆｌａｇ）はｔ＿ｒ
ｅｃｏｖｅｒ（０，ｆｌａｇ）と等価である。関数ｃｒ
ｉｔｉｃａｌｓｉｚｅ（）は、スレッドに対してチェッ
クポイントされたクリティカルデータのサイズを返す。
これはｔｈｒｅａｄｉｄをパラメータとしてとる。チェ
ックポイントされたクリティカルデータがない場合、こ
の関数は０を返す。

【００７５】関数ｆｔｄｕｐ（）は、データがクリティ
カルメモリ１１５からクリティカルメモリコピー１２５
へチェックポイントされるときはいつでも、クリティカ
ルメモリコピー１２５がバックアップノード２０３にコ
ピーされるべきことを指定するメッセージがプロセス１
０３から状態サーバ３０３へ送られるよう指定する。ｆ
ｔｄｕｐ（）関数がチェックポイントの前に呼び出され
ない場合、バックアップノード２０３へのコピーは行わ
れない。

【００７６】［４．２例］以下の例は、ｃｈｅｃｋｐ
ｏｉｎｔ（）関数およびｒｅｃｏｖｅｒ（）関数がｓｏ
ｒｔ関数においていかにして使用されるかを示す。

【００７７】

【表４】ｓｏｒｔｅｄ（）は、引数リスト中の配列がソートされ
ている場合に１を返す関数である。

【００７７】入力はソートされていない配列である。３
つのソートサブルーチン（ｓｕｐｅｒｓｏｒｔ（）、ｑ
ｕｉｃｋｓｏｒｔ（）およびｂｕｂｂｌｅｓｏｒ
ｔ（））がこの関数から呼び出されている。サブルーチ
ンを呼び出す前に、プログラムはｃｒｉｔｉｃａｌ関数
を使用して、入力配列の記憶域をクリティカルメモリ１
１５として確保してから、クリティカルメモリ１２５か
らクリティカルメモリコピー１２５へ未ソート配列をチ
ェックポイントする。次に、ｓｕｐｅｒｓｏｒｔ（）が
まず呼び出される。その終了時に、配列が検査される。
ソートされていれば、関数は正常復帰する。そうでない
場合、未ソート配列がクリティカルメモリコピー１２５
から復元され、ｑｕｉｃｋｓｏｒｔ（）が呼び出され
る。ｑｕｉｃｋｓｏｒｔ（）の結果が再び検査される。
結果が正しくない場合、配列が復元され、ｂｕｂｂｌｅ
ｓｏｒｔ（）が呼び出される。いずれのサブルーチンも
正しい答えを出さない場合、プログラムはエラーととも
に終了する。

【００７８】［４．３自動メッセージロギング］前記
のように、フォールトトレラントプロセス１０３のプロ
セス状態はログファイル１２７を有することができる。
好ましい実施例において、ログファイル１２７を設定し
使用するためのｌｉｂｆｔ関数は以下のとおりである。

【表５】

【００７９】ログファイル関数は、ｆｎａｍｅによって
指定されるファイルを、プロセス１０３のログファイル
１２７として確保する。プログラムが、ログファイル１
２７上で読み出しているデータを記録したい場合、プロ
グラムはｆｔｒｅａｄ関数を使用する。この関数の使用
法は、プログラムによって読み出される全データがログ
ファイル上にもロギングされることを除いては、ＵＮＩ
Ｘオペレーティングシステムのｒｅａｄ関数と同一であ
る。ｆｔｒｅａｄによって作成されるログエントリは、
データおよびファイル記述子を含む。プログラムが回復
状態にある場合、プログラムは、ファイル記述子によっ
て指定されるファイルからの読み出しを開始する前に、
ログファイルからファイル記述子のエントリのデータを
読み出す。ログファイルは、ｃｈｅｃｋｐｏｉｎｔ（）
関数が実行されるたびに切り捨てられる。関数ｆｔｗｒ
ｉｔｅ（）は、ｆｔｗｒｉｔｅ関数を実行中のプロセス
１０３が回復モードにある場合には何も書き出さないこ
とを除いては、通常のＵＮＩＸオペレーティングシステ
ムのｗｒｉｔｅ関数と同様である。このようにして、ｆ
ｔｗｒｉｔｅ関数は、プロセス１０３の回復中には、既
に実行したｗｒｉｔｅが重複しないようにする。

【００８０】ｆｔｒｅａｄ（）関数、ｆｔｗｒｉｔ
ｅ（）関数およびｃｈｅｃｋｐｏｉｎｔ（）関数を組み
合わせると、定期的チェックポイントおよびデータ無損
失の効率的なフォールトトレラントプログラムを実現す
ることができる。本節で後で例を示す。

【００８１】［５．ｗａｔｃｈｄデーモン１０４を管理
するｌｉｂｆｔ関数］ｌｉｂｆｔ１１３は、ｗａｔｃｈ
ｄデーモン１０４を管理するいくつかの関数を含む。そ
の中には、プロセス１０３をデーモン１０４に登録する
関数、プロセス１０３からデーモン１０４へハートビー
トシグナルを送る関数、および、プロセス状態コピー３
１５を操作する関数がある。

【００８２】［５．１プロセス１０３のデーモン１０
４への登録］関数ｒｅｇｗａｔｃｈはプロセス１０３を
デーモン１０４に登録する。登録後、デーモン１０４は
プロセス１０３の監視を開始する。

【表６】

【００８３】この関数は３個のパラメータをとる。ｐｒ
ｏｃはプロセス名である。ｐｏｒｔはプロセスがプロセ
ス間通信のために使用するポート番号である（プロセス
がポートを使用しない場合は０）。ｔｉｍｅは最大タイ
ムアウトを定義するものである。この関数の実行によっ
て状態サーバ３０３にメッセージが送られる。状態サー
バ３０３は、これらのパラメータを使用して、フォール
トトレラントプロセスリスト１３９および状態テーブル
２０７中にプロセス１０３のエントリを作成し、他のデ
ーモン１０４が自己の状態テーブル２０７を更新するこ
とができるように他のデーモンにメッセージを送る。こ
れらのパラメータは、プロセス１０３に対するフォール
トトレラントプロセスリストエントリ４０５のフィール
ド４０７、４０９、および４１５に使用される。ｗａｔ
ｃｈｄデーモンが、プロセス１０３がハングしたかどう
か検出する必要がない場合、ｔｉｍｅ＝０とすることが
できる。

【００８４】［５．２ｗａｔｃｈｄデーモンへのハー
トビートシグナルの送信］前記のように、状態サーバ３
０３はプロセス１０３からの「ハートビート」シグナル
を受け取ることができる。このシグナルはｌｉｂｆｔ関
数ｈｂｅａｔ（）によって生成される。関数ｈｂｅａｔ
（）は引数として整数値をとる。その値は、状態サーバ
３０３がプロセス１０３からのハートビートシグナルを
待機すべき最大時間区間を指定する。状態サーバ３０３
がこの区間内にハートビートシグナルを受信しない場
合、状態サーバ３０３はプロセス１０３がハングしたと
考え、そのプロセスを再起動する。

【００８５】［５．３ｗａｔｃｈｄデーモン１０４か
らの情報の取得］ｌｉｂｆｔ１１３は、プロセス１０３
がデーモン１０４から情報を取得することを可能にする
多くの関数を含む。その関数は以下のとおりである。

【表７】

【００８６】関数ｇｅｔｓｖｒｌｏｃ（）は、ｓｖｒ＿
ｎａｍｅという名前のプロセス１０３が現在動作中のノ
ード２０３を返す。プロセス１０３がどのノード上でも
実行中でない場合、この関数はＮＵＬＬポインタを返
す。

【００８７】プロセスは、通常状態と回復状態という２
つの状態を有する。プロセスがｗａｔｃｈｄデーモン１
０４によって再起動されると、デーモン１０４は、プロ
セス１０３が回復状態にあることを示す値をセットす
る。このプロセスは、ｒｅｃｏｖｅｒ関数の実行が成功
するまでは回復状態のままである。実行を完了すると、
ｒｅｃｏｖｅｒ関数は、回復状態を示す値を通常状態を
示すようにセットするメッセージをデーモン１０４に送
る。関数ｉｎ＿ｒｅｃｏｖｅｒｙ（）によって、プロセ
ス１０３は、通常状態にあるかまたは回復状態にあるか
を判定することができる。この関数はデーモン１０４に
メッセージを送り、デーモン１０４は、プロセス１０３
の状態を示すことによって応答する。

【００８８】関数ｃｏｐｙｔｏｂｋｐ（）は、ファイル
またはディレクトリをバックアップノード２０３に自動
的にコピーするように状態サーバ３０３にメッセージを
送る。引数がディレクトリである場合、そのディレクト
リの下のすべてのファイル（ディレクトリを含む）がバ
ックアップノードにコピーされる。この関数は、プロセ
ス１０３が、基本マシンとバックアップマシンの間で複
製されたファイルまたはディレクトリの一貫性を維持し
なければならないときに有用である。ｗａｔｃｈｄデー
モン１０４は、ノードリストテーブル２０５に定義され
たリング２１１の構成から、プロセス１０３のバックア
ップマシンがどこにあるかを決定するため、バックアッ
プマシン名は不要であることに注意すべきである。

【００８９】同様に、関数ｃｏｐｙｆｒｏｍｐｒｉｍａ
ｒｙ（）は、フォールトトレラントプロセステーブル１
３９中のプロセス１０３のエントリに指定された基本ノ
ード２０３からローカルノード２０３にファイル（また
はディレクトリ）をコピーするために使用される。この
コピーは、関係するノード２０３内の状態サーバプロセ
ス３０３によって行われる。同様に、関数ｆａｓｔｃｏ
ｐｙｓ（）は、ノードｍａｃｈｉｎｅｎａｍｅからロー
カルノード２０３にファイル（またはディレクトリ）を
コピーする。両方の関数とも、コピーが成功した場合に
０を返し、そうでない場合は−１を返す。

【００９０】プロセス１０３が第１のノード２０３上で
動作中であり、第２のノード２０３上で再起動されなけ
ればならない場合、プロセスは、第２ノード上で再起動
可能になる前に第１ノード２０３上で終了されなければ
ならない。終了シグナルは第１ノード２０３内のｗａｔ
ｃｈｄデーモン１０４によって送られる。終了シグナル
を送るために、デーモン１０４は、プロセス１０３がど
のような終了シグナルを期待しているかを知らなければ
ならない。関数ｆｔｔｅｒｍｓｉｇ（）によって、プロ
セス１０３は、どのようなシグナルを期待しているかを
宣言することができる。例えば、プロセスが終了の際に
はシグナルＳＩＧＵＳＲ１を受け取りたい場合、プログ
ラムの最初で文ｆｔｔｅｒｍｓｉｇ（ＳＩＧＵＳＲ１）
を使用すればよい。この場合、ｗａｔｃｈｄデーモン１
０４はそのプロセスを終了するためにそのプロセスにシ
グナルＳＩＧＵＳＲ１を送る。終了シグナルが宣言され
ていない場合、デフォルト終了シグナルＳＩＧＴＥＲＭ
が送られる。

【００９１】［５．４フォールトトレラントソケット
機構］ｗａｔｃｈｄデーモン１０４がフォールトトレラ
ントプロセス１０３と通信するために使用するポート
は、フォールトトレラントプロセス１０３へのフォール
トトレラントソケット接続を確立するためにも使用する
ことができる。以下のｌｉｂｆｔ関数は、フォールトト
レラントプロセス１０３のポートをこの目的に適合させ
る。

【表８】

【００９２】関数ｆｔｃｏｎｎｅｃｔ（）は、クライア
ントプロセスを、フォールトトレラントプロセス１０３
であるサーバプロセスに接続する。この関数はまず、ｗ
ａｔｃｈｄデーモン１０４に問い合わせて、状態テーブ
ル２０７からプロセス１０３のポート番号を取得してか
ら、クライアントプロセスをプロセス１０３に接続す
る。ｆｔｃｏｎｎｅｃｔ（）の使用法は、ＵＮＩＸオペ
レーティングシステムのｃｏｎｎｅｃｔ（）関数と同一
である。関数ｆｔｂｉｎｄ（）は、名前のないソケット
に名前を割り当てる。この関数は、デーモン１０４にメ
ッセージを送り、状態テーブル２０７からプロセス１０
３のポート番号を取得した後、ＵＮＩＸオペレーティン
グシステム関数を使用してその名前をデーモン１０４に
よって返されたポート番号に結合する。この関数の使用
法はｂｉｎｄ（）関数と同一である。関数ｆｔｓｅｎｄ
（）は、プロセス１０３の状態テーブルエントリ５０１
のポート番号に対応するソケットにメッセージを送る。
送信が失敗した場合、この関数はソケットを自動的に再
接続し、メッセージを再送信する。この関数の使用法は
ＵＮＩＸオペレーティングシステム関数ｓｅｎｄ（）と
同一である。

【００９３】関数ｇｅｔｓｖｒｂｙｐｏｒｔ（）は、ソ
ケット通信にポート番号ｐｏｒｔ＿ｎｏを使用するプロ
セス１０３が現在動作中であるノードを返す。このポー
ト番号を使用しているプロセスがない場合、関数はＮＵ
ＬＬ値を返す。関数ｇｅｔｓｖｒｐｏｒｔ（）は、プロ
セスの状態テーブルエントリ５０１のポート番号を返
す。ｗａｔｃｈｄデーモン１０４がそのプロセスのポー
ト番号を発見できない場合、この関数は−１を返す。

【００９４】［５．５例］以下の例は、フォールトト
レラントプロセス１０３において動作し、チェックポイ
ントおよび回復にｌｉｂｆｔを使用するサーバプログラ
ムを示す。このサーバプログラムは、クライアントから
入力を読み込み、スタックのトップにその数をプッシュ
する。スタックは連結リストとして実現される。

【表９】

【００９５】上の例のクリティカルデータはスタックお
よびスタックのトップへのポインタ（ｐＨｅａｄ）であ
る。このポインタは、ｃｒｉｔｉｃａｌ（＆ｐＨｅａ
ｄ，ｓｉｚｅｏｆ（ｐＨｅａｄ），０）の関数呼出によ
ってクリティカルメモリ１１５に入れられる。スタック
をクリティカルメモリ１１５に入れるためには、プログ
ラムはｆｔ＿ｓｔａｒｔを使用してクリティカルメモリ
１１５の領域を宣言し、ｆｔｍａｌｌｏｃを使用してそ
こから割り当てなければならない。

【００９６】ｆｔｄｕｐ（）の実行によって、すべての
チェックポイントされたデータは、リング２１１の現在
の構成によって決定されるバックアップノード２０３に
送られる。関数ｉｎ＿ｒｅｃｏｖｅｒｙ（）は、プログ
ラムがデーモンｗａｔｃｈｄによって再起動されると１
を返す。これは、関数ｒｅｃｏｖｅｒ（）が実行されて
すべてのロギングされたデータが消去されるまでは１の
ままである。その後では、関数ｉｎ＿ｒｅｃｏｖｅｒｙ
（）は常に０を返す。プログラムは、２００メッセージ
ごとにチェックポイントを実行する。すべての着信メッ
セージは、ｅｘａｍｐｌｅ．ｌｏｇと呼ぶファイルにロ
ギングされる。プログラムが回復モードにある場合、デ
ータは、ファイル記述子ｓからではなくロギングされた
ファイルから読み出される。プログラムは、関数ｆｔｔ
ｅｒｍｓｉｇ（ＳＩＧＴＥＲＭ）を使用することによっ
て、ＳＩＧＴＥＲＭを終了シグナルとして定義する。ハ
ートビートシグナルをｗａｔｃｈｄデーモンに送るため
に、関数ｈｂｅａｔ（）が使用される。

【００９７】［ｗａｔｃｈｄおよびｌｉｂｆｔを使用し
て、プログラムをフォールトトレラントにする］サーバ
プログラムを、フォールトトレラントプロセス１０３に
よって実行可能なように変換する一般的な方法は以下の
とおりである。１．適当な場所にｃｈｅｃｋｐｏｉｎｔ（）およびｒｅ
ｃｏｖｅｒ（）を挿入する。２．クリティカル変数およびクリティカルデータ構造体
を定義する。３．クリティカルメモリ割り当て用に、ｍａｌｌｏ
ｃ（）をｆｔｍａｌｌｏｃ（）に、ｒｅａｌｌｏｃ（）
をｆｔｒｅａｌｌｏｃ（）に、ｆｒｅｅ（）をｆｔｆｒ
ｅｅ（）に変更する。４．サーバプログラムをｌｉｂｆｔとともにコンパイル
およびリンクする。

【００９８】以上の手順は、Ｙｅａｓｔサーバプログラ
ムを変換するために使用された。Ｙｅａｓｔ（「さらに
もう１つのイベント−アクション指定ツール」(Yet ano
therEvent-Action Specification Tool)）は、頻繁に実
行されるソフトウェア開発作業を自動化するためのサー
ビスを提供するツールであり、ディ．エス．ローゼンブ
ラム(D. S. Rosenblum)、ビー．クリシュナマーシー(B.
Krishnamurthy)「ソフトウェア設定管理のイベントベ
ースのモデル」、Proceedings of the 3rd Internation
al Workshop on Software Configuration Management、
第９４〜９７ページ、ＡＣＭプレス（１９９１年６月）
に記載されている。これは、ユーザからイベント−アク
ション指定を受け取り、指定されたイベントパターンの
発生を認識すると指定されたアクションを自動的に呼び
出す。

【００９９】Ｙｅａｓｔツールは、クライアントがイベ
ント−アクション指定を提示および操作し、ｙｅａｓｔ
ｄというサーバプロセスが指定照合および管理を実行す
るというクライアント−サーバモデルに基づく。サーバ
とクライアントの間の通信は、ＢＳＤのｓｏｃｋｅｔ機
構に基づく。これは、サーバが所定のホストに存在し、
周知のポートで要求を待機するものである。ｙｅａｓｔ
ｄの最初の実現はフォールトトレラントではなく、サー
バが動作中のノードが故障すると、ｙｅａｓｔｄは、ネ
ットワーク内に作業中の他のノードがあっても、もはや
サービスを提供することができない。故障したノードが
修復されると、ｙｅａｓｔｄは初期状態から再起動され
ることができるだけである。故障前に提示されたイベン
ト指定は失われる。

【０１００】ｙｅａｓｔｄプロセスをフォールトトレラ
ントにするため、上記の手順を使用して、ｙｅａｓｔｄ
プログラムをｆｔｙｅａｓｔｄプログラムに変換した。
Ｙｅａｓｔはかなり複雑なシステムである。これは２０
個以上のソースファイルと、４万行以上のＣコードを有
する。最初のステップは、ｃｈｅｃｋｐｏｉｎｔ（）お
よびｒｅｃｏｖｅｒ（）関数を挿入する正しい位置を識
別することであった。ソースプログラムを通読すること
により、サーバがアイドルになる位置をすぐに識別し
た。ｃｈｅｃｋｐｏｉｎｔ（）関数およびｒｅｃｏｖｅ
ｒ（）関数をその場所に挿入した。次のステップは、す
べてのクリティカルデータ構造体およびクリティカル変
数を見つけ出すことであった。はじめは、プログラムの
内部データ構造体に関してほとんど未知であったため、
このステップはより困難であった。注意深くソースプロ
グラムをトレースし、約２５個のクリティカル変数を識
別した。これらの変数は、ｃｒｉｔｉｃａｌ（）関数を
使用することによってクリティカルであると宣言され
た。次のステップは、クリティカルデータ構造体のメモ
リ空間の割り当ておよび解放の際のｍａｌｌｏｃ（）を
ｆｔｍａｌｌｏｃ（）に、および、ｆｒｅｅ（）をｆｔ
ｆｒｅｅ（）に変更することであった。これは、メイク
ファイル中でｍａｌｌｏｃ＝ｆｔｍａｌｌｏｃおよびｆ
ｒｅｅ＝ｆｔｆｒｅｅと定義することによってなされ
た。クリティカルデータのためにクリティカルメモリ空
間を作成するために、サーバプログラムの最初にｆｔ＿
ｓｔａｒｔ（）関数を挿入した。最後に、この新しいソ
ースプログラムをｌｉｂｆｔライブラリとともにコンパ
イルおよびリンクした。

【０１０１】完了後、ソースコードに追加された新しい
行の総数は約４０であった。全手順は約４日間を要し
た。その時間のほとんどは、デバッグおよびテストに費
やされた。開始時にソースプログラムの十分な知識があ
れば変換はずっと早かったであろう。この新しいサーバ
ｆｔｙｅａｓｔｄは、システム内のノード故障に耐える
ことができ、サービスの提供を継続することが示され
た。

【０１０２】ｆｔｙｅａｓｔｄサーバの最初のプロトタ
イプでは、チェックポイントは、システム内の内部状態
変化があるところにはいつも挿入された。なんらかの最
適チェックポイント頻度に従ってサーバをチェックポイ
ントすれば、チェックポイントオーバヘッドは短縮する
ことができる。システムを解析し、最適チェックポイン
ト頻度を導出する方法は、上掲のイェンヌン・フアン(Y
ennun Huang)の論文にある。サーバの状態を回復するた
めに、バックアップノード上にメッセージログを保持す
ることができる。基本−コピー障害が発生した場合、こ
のメッセージログがバックアップノード（新しい基本ノ
ード）によって実行され、サーバの状態が再生成され
る。

【０１０３】この詳細な説明に記載した実施例は、本発
明を実施するのに、発明者によって知られている現在最
善のものであるが、本実施例の多くの変形が可能である
ことは当業者には明らかである。例えば、他の実施例の
ｌｉｂｆｔは、より多い、または、より少ない関数を含
むことが可能であり、それらの関数は、本実施例とは異
なる意味を有することも可能である。さらに、ｗａｔｃ
ｈｄは異なるアーキテクチャを有することが可能であ
り、ノードおよびプロセスの状態を記録するために異な
るテーブルを使用することが可能である。さらに、リン
グ２１１以外のデーモンおよびノードの構成も使用可能
であり、ノード内のテーブルの一貫性を保持するために
他のプロトコルを使用することも可能である。

【０１０４】

【発明の効果】［結論］以上の詳細な説明は、当業者に対して、特殊な
フォールトトレラントハードウェアやフォールトトレラ
ントオペレーティングシステムを必要とせずに、通常の
ユーザプロセスおよびフォールトトレラント関数のライ
ブラリを使用して実現されるデーモンに基づいたフォー
ルトトレラントコンピューティングシステムをいかにし
て構築することができるかを開示するものである。ここ
で開示した技術は、特殊ハードウェアやオペレーティン
グシステムを含むものよりも安価であるのみならず、従
来は知られていない一定の柔軟性をアプリケーションプ
ログラマに与えるものである。さらに、複数のノードを
持つシステムで使用した場合、これらの技術は、特殊ハ
ードウェアやオペレーティングシステムによって提供さ
れるのとしばしば同程度であるフォールトトレランスを
提供する。

【図面の簡単な説明】

【図１】単一のノードにおける本発明のソフトウェアフ
ォールトトレランスのシステムの概略図である。

【図２】複数のノードにおける本発明のソフトウェアフ
ォールトトレランスのシステムの概略図である。

【図３】本発明の好ましい実施例の図である。

【図４】好ましい実施例で使用されるテーブルの図であ
る。

【図５】好ましい実施例で使用されるテーブルの図であ
る。

【符号の説明】

１０１フォールトトレラントコンピューティングシス
テム１０３フォールトトレラントプロセス１０４ｗａｔｃｈｄデーモン１０５揮発性メモリ（ＶＭＥＭ）１０７コード１０９データ１１１フォールトトレラントアプリケーション（ＦＴ
Ａ）コード１１３ｌｉｂｆｔコード１１５クリティカルメモリ（ＣＲＭＥＭ）１２３持続性メモリ１２５クリティカルメモリコピー（ＣＲＭＥＭＣ）１２７ログファイル１３９フォールトトレラントプロセス（ＦＴＰ）リス
ト１４１フォールトトレラントグループ（ＦＴＰグルー
プ）リスト２０１分散システム２０３ノード２０５ノードリスト（ＮＬ）２０７状態テーブル２１１適応リング３０１モニタ（ＭＯＮ）３０３状態サーバ（ＳＴＡＴＥＳＲＶＲ）３１５プロセス状態コピー３１７ローカルフォールトトレラントプロセス（ＬＦ
ＴＰＳ）４０１ノードリストエントリ４０３ノード名４０５フォールトトレラントプロセスエントリ（ＦＴ
ＰＥ）４０７フォールトトレラントプロセス名４０９ポート番号４１１基本ノード名４１３クリティカルファイル４１５タイムリミット４１７フォールトトレラントグループエントリ４１９グループ番号４２１フォールトトレラントプロセス名

───────────────────────────────────────────────────── フロントページの続き (56)参考文献特開平１−197859（ＪＰ，Ａ) 電子情報通信学会技術研究報告社団法人電子情報通信学会 1990／11／21 Ｖｏｌ．90 Ｎｏ．326 ｐ．25−30 (58)調査した分野(Int.Cl.⁷，ＤＢ名) G06F 11/14 - 11/20 G06F 11/30 - 11/34 G06F 15/16 - 15/177

Claims

(57)【特許請求の範囲】

【請求項１】コンピュータシステムで使用されるフォ
ールトトレラントコンピューティング装置において、該
装置は、前記コンピュータシステム内のプロセッサ上で実行中の
プロセスの状態を観測し、該プロセスが実行継続不能で
あると観測されるときに該プロセスを再起動するモニタ
と、複数のフォールトトレラントライブラリルーチンとを有
し、前記複数のフォールトトレラントライブラリルーチンの
うちの１つ以上の特定のフォールトトレラントライブラ
リルーチンは、前記プロセスから呼出し可能であり、該
呼出しにより、複数のフォールトトレランスの程度のう
ちの対応する１つの程度のフォールトトレランスが前記
プロセスに与えられ、前記モニタによる観測が該特定の
フォールトトレラントライブラリルーチンに従って実行
されることを特徴とするフォールトトレラントコンピュ
ーティング装置。
【請求項２】前記特定のフォールトトレラントライブ
ラリルーチンの実行は、前記プロセスによる該ルーチン
の呼出しに応じて行われることを特徴とする請求項１に
記載の装置。
【請求項３】前記特定のフォールトトレラントライブ
ラリルーチンは、前記プロセスによって使用されるクリ
ティカルメモリを定義し保存するルーチンと、前記プロ
セスが再起動されるときに該クリティカルメモリを復元
するルーチンとを含むことを特徴とする請求項１に記載
の装置。
【請求項４】前記特定のフォールトトレラントライブ
ラリルーチンは、前記プロセスが再起動されるときに反
復される前記プロセスの読出し動作のログファイルを定
義し維持するルーチンを含むことを特徴とする請求項１
に記載の装置。
【請求項５】前記特定のフォールトトレラントライブ
ラリルーチンは、前記プロセスを前記モニタに登録する
ルーチンを含むことを特徴とする請求項１に記載の装
置。
【請求項６】前記特定のフォールトトレラントライブ
ラリルーチンは、実行時に前記モニタにシグナルを送る
ルーチンを含み、前記モニタは、所定時間内に前記シグナルを受信しない
場合、前記プロセスは継続不能であると判定することを
特徴とする請求項１に記載の装置。
【請求項７】前記シグナルを送るルーチンは、さら
に、次のシグナルに対する所定時間を示す値を送ること
を特徴とする請求項６に記載の装置。
【請求項８】ユーザレベルプロセスを実行する少なく
とも１つのプロセッサと、前記少なくとも１つのプロセッサ上で実行される第１ユ
ーザレベルプロセスと、前記少なくとも１つのプロセッサ上で実行されるユーザ
レベルデーモンプロセスと、前記第１ユーザレベルプロセスを指定する登録メッセー
ジを前記ユーザレベルデーモンプロセスに送る登録メッ
セージ送信手段とを有する、フォールトトレラントコン
ピューティングのためのコンピュータシステムにおい
て、前記ユーザレベルデーモンプロセスは、前記登録メッセ
ージに応答して、前記第１ユーザレベルプロセスが実行
継続不能であるかどうかを判定するために前記第１ユー
ザレベルプロセスの観測を開始し、前記第１ユーザレベ
ルプロセスが実行継続不能であると観測されるときに前
記第１ユーザレベルプロセスを再起動することを特徴と
する、フォールトトレラントコンピューティングのため
のコンピュータシステム。
【請求項９】前記第１ユーザレベルプロセスからそれ
ぞれ実行可能な複数のフォールトトレラントライブラリ
ルーチンをさらに有することを特徴とする請求項８に記
載のコンピュータシステム。
【請求項１０】前記複数のフォールトトレラントライ
ブラリルーチンは、前記第１ユーザレベルプロセスによ
って使用されるメモリを定義し、保存し、復元するルー
チンを含むことを特徴とする請求項９に記載のコンピュ
ータシステム。
【請求項１１】前記複数のフォールトトレラントライ
ブラリルーチンは、前記第１ユーザレベルプロセスが再
起動されるときに反復される前記第１ユーザレベルプロ
セスの読出し動作のログファイルを定義し維持するルー
チンを含むことを特徴とする請求項９に記載のコンピュ
ータシステム。
【請求項１２】前記登録メッセージ送信手段は、フォ
ールトトレラントライブラリルーチンを含むことを特徴
とする請求項９に記載のコンピュータシステム。
【請求項１３】前記複数のフォールトトレラントライ
ブラリルーチンは、実行時に前記ユーザレベルデーモン
プロセスにシグナルを送るルーチンを含み、前記ユーザレベルデーモンプロセスは、所定時間内に前
記シグナルを受信しない場合、前記第１ユーザレベルプ
ロセスは継続不能であると判定することを特徴とする請
求項９に記載のコンピュータシステム。
【請求項１４】前記シグナルを送るルーチンは、さら
に、次のシグナルに対する所定時間を示す値を送ること
を特徴とする請求項１３に記載のコンピュータシステ
ム。
【請求項１５】前記コンピュータシステムは、前記第
１ユーザレベルプロセスが属するユーザレベルプロセス
グループを指定するフォールトトレラントグループテー
ブルをさらに有し、前記ユーザレベルデーモンプロセスは、前記フォールト
トレラントグループテーブルに従って、前記ユーザレベ
ルデーモンプロセスが前記第１ユーザレベルプロセスを
再起動するのと同時に前記フォールトトレラントグルー
プテーブルで指定される各ユーザレベルプロセスを再起
動することを特徴とする請求項８に記載のコンピュータ
システム。
【請求項１６】前記ユーザレベルデーモンプロセス
は、ポーリングを使用して前記第１ユーザレベルプロセスが
実行継続不能であるかどうかを判定する第１デーモンプ
ロセスと、前記第１ユーザレベルプロセスが実行継続不能であると
前記第１デーモンプロセスが判定したときに前記第１ユ
ーザレベルプロセスを再起動する第２デーモンプロセス
とを有することを特徴とする請求項８に記載のコンピュ
ータシステム。
【請求項１７】複数のノードを有する、フォールトト
レラントコンピューティングのための分散コンピュータ
システムにおいて、各ノードは、ユーザレベルプロセスを実行する少なくとも１つのプロ
セッサと、前記少なくとも１つのプロセッサ上で実行されるユーザ
レベルデーモンプロセスと、ユーザレベルプロセスを指定する登録メッセージを前記
ユーザレベルデーモンプロセスに送る登録メッセージ送
信手段とを有し、前記ユーザレベルデーモンプロセスは、前記登録メッセ
ージに応答して、指定されたユーザレベルプロセスが実
行継続不能であるかどうかを判定するために前記指定さ
れたユーザレベルプロセスの観測を開始し、前記指定さ
れたユーザレベルプロセスが実行継続不能であると観測
されるときに前記指定されたユーザレベルプロセスを再
起動し、前記複数のノードのうちの第１ノードで実行される第１
ユーザレベルデーモンプロセスは、さらに、前記複数の
ノードのうちの第２ノードが動作中であるかどうかを観
測することを特徴とする、フォールトトレラントコンピ
ューティングのための分散コンピュータシステム。
【請求項１８】前記第２ノードは、第１ユーザレベル
プロセスを実行し、前記第１ユーザレベルデーモンプロセスは、前記第２ノ
ードの障害に応答して、前記第１ノード上で、前記第１
ユーザレベルプロセスと等価なプロセスの実行を開始す
ることを特徴とする請求項１７に記載の分散コンピュー
タシステム。
【請求項１９】前記第２ノード上で実行される第２ユ
ーザレベルデーモンプロセスが、前記第１ユーザレベル
プロセスから前記第１ユーザレベルデーモンプロセスに
プロセス状態情報をコピーし、前記第１ユーザレベルデーモンプロセスは、前記第１ユ
ーザレベルプロセスと等価なプロセスの実行を開始する
際に前記プロセス状態情報を使用することを特徴とする
請求項１８に記載の分散コンピュータシステム。
【請求項２０】各ノードは、実行時にユーザレベルプロセス状態情報を保存する第１
フォールトトレラントライブラリルーチンを含む、前記
ユーザレベルプロセスにより実行可能なコンピュータプ
ログラムコードをさらに有することを特徴とする請求項
１９に記載の分散コンピュータシステム。
【請求項２１】各ノード内のユーザレベルデーモンプ
ロセスは、第１ユーザレベルプロセスが対応する基本ノード上で実
行され、該第１ユーザレベルプロセスと等価な第２ユー
ザレベルプロセスが該基本ノード以外のノード上で実行
されていると、前記ユーザレベルデーモンプロセスが判
定した場合に、該第２ユーザレベルプロセスを削除する
手段をさらに有することを特徴とする請求項１７に記載
の分散コンピュータシステム。
【請求項２２】各ノードが１つのユーザレベルデーモ
ンプロセスによって観測されるとともに、各ユーザレベ
ルデーモンプロセスが１つのノードを観測するように、
前記複数のノードは設定されていることを特徴とする請
求項１７、１８または２１に記載の分散コンピュータシ
ステム。
【請求項２３】各ユーザレベルデーモンプロセスは、
該ユーザレベルデーモンプロセスによって観測されるノ
ードが故障したときに前記設定を維持する手段をさらに
有することを特徴とする請求項２２に記載の分散コンピ
ュータシステム。
【請求項２４】ユーザレベルプロセスを実行する少な
くとも１つのプロセッサを有するフォールトトレラント
コンピュータシステムの動作方法において、該方法は、プロセッサ上で実行されているユーザレベルプロセスを
指定する登録メッセージをユーザレベルデーモンプロセ
スに送る登録メッセージ送信ステップを有し、前記ユーザレベルデーモンプロセスは、前記登録メッセ
ージに応答して、指定されたユーザレベルプロセスが実行継続不能である
かどうかを判定するために該指定されたユーザレベルプ
ロセスをモニタするステップと、前記指定されたユーザレベルプロセスが実行継続不能で
ある場合に前記指定されたユーザレベルプロセスを再起
動するステップとを実行することを特徴とする、フォー
ルトトレラントコンピュータシステムの動作方法。
【請求項２５】前記登録メッセージ送信ステップは、
フォールトトレラントライブラリルーチンを実行するス
テップを含むことを特徴とする請求項２４に記載の方
法。
【請求項２６】前記指定されたユーザレベルプロセス
は、前記ユーザレベルデーモンプロセスにシグナルを送
るステップを実行し、前記モニタするステップは、所定時間内に前記シグナルを受信しない場合、前記指定
されたユーザレベルプロセスは継続不能であると判定す
るステップを含むことを特徴とする請求項２４に記載の
方法。
【請求項２７】前記フォールトトレラントコンピュー
タシステムは、前記指定されたユーザレベルプロセスが
属するユーザレベルプロセスグループを指定するフォー
ルトトレラントグループテーブルをさらに有し、前記ユ
ーザレベルデーモンプロセスは、前記フォールトトレラ
ントグループテーブルに従って、前記ユーザレベルデーモンプロセスが前記指定されたユ
ーザレベルプロセスを再起動するのと同時に前記フォー
ルトトレラントグループテーブルで指定される各ユーザ
レベルプロセスを再起動するステップを実行することを
特徴とする請求項２４に記載の方法。