JPH0895814A

JPH0895814A - ソフトウエアの更新のための装置及び方法

Info

Publication number: JPH0895814A
Application number: JP7230830A
Authority: JP
Inventors: N Dudley Fulton Iii; フルトンサードエヌ．ダッドレイ; Yennun Huang; ファンエンナン; Chandra Mohan Rao Kintala; モハンラオキンタルチャンドラ; Nicholas John Kolettis; ジョンコレティスニコラス
Original assignee: AT&T Corp
Current assignee: AT&T Corp
Priority date: 1994-09-08
Filing date: 1995-09-08
Publication date: 1996-04-12
Also published as: EP0701209A2; DE69528428D1; CA2152329C; EP0701209A3; DE69528428T2; EP0701209B1; CA2152329A1

Abstract

(57)【要約】（修正有）【目的】システムの実行を停止し、その実行を「真新し
い」状態で再始動させることにより信頼性を改善するソ
フトウエア更新技術を提供する。【構成】フォルト・トレラント・プロセス１０３は、揮
発性メモリ１０５を有し、コード１０７には、フォルト
・トレラント・アプリケーションコード１１１と、コー
ド１１１がコンパイルされた場合にコード１１１と結合
するｌｉｂｆｔコード１１３とが含まれる。アプリケー
ション・コード１１１は、ｌｉｂｆｔコード１１３のル
ーチンを援用し、フォルト・トレラント・プロセス１０
３がクラッシュまたはハングアップした場合に回復を実
行する。クラッシュまたはハングアップしてしまった場
合のフォルト・トレラント・プロセス１０３の再始動
は、ｗａｔｃｈｄデーモン１０４により行う。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、一般的にフォルト
・トレラント・コンピューティングに関し、そして特に
ソフトウェアシステムがクラッシュまたはハングアップ
することを防止するための技術に関する。

【０００２】

【発明が解決しようとする課題】ソフトウェアシステム
は、プロセスにより実行されるプログラムを組み合わせ
た部品で構成されている。以下、これらの部品をアプリ
ケーションと呼ぶ。多くのソフトウェアシステムには、
長時間実行し続けるべきアプリケーションが含まれてい
る。当然、そのようなアプリケーションは、決して機能
停止すべきものではない。しかしながら、ある程度の機
能をもったアプリケーションならば、そのアプリケーシ
ョンが常に正しく走行することを保証するのは、非常に
難しい。アプリケーションをどんなに慎重かつ念入りに
作成し、導入しても、非決定性の（入力と出力の関係や
状態推移が一意に決定できない）バグは除くことができ
ない。このようなバグは、アプリケーションを長い時間
実行するほど、顕在化する可能性が高くなる。このよう
なバグは、一時的な障害であっても、予知不可能な事態
や、後に高価につくような影響を引き起しかねない。例
えば、その障害が、到底その痕跡を残すことなく修復出
来ないほどデータベースを破壊してしまったり、（例え
ば、アロケーション、デアロケーションを繰り返すこと
により）メモリーの亀裂や膨張を引き起こし、これらが
結局はアプリケーションをクラッシュ（故障、暴走、機
能停止）してしまったり、あるいは、他のオペレーティ
ング・システムの資源を徐々に食いつぶし、結局は全体
のアプリケーションを麻痺させてしまったりといったこ
とが考えられる。

【０００３】このような一時的障害を解決するために典
型的に採用される戦略は、事実上、反応的、すなわち障
害が発生してからとる行動により構成されているのであ
る。最近まで、そのような解決手段の多くは、手作業に
よるものか、「巧妙な」プログラミングにより、それぞ
れのアプリケーション特有な形で実装されていた。最近
になって、アプリケーションの親として記述されたモジ
ュールなど、プラットホームやアプリケーションから独
立したモジュールが、いくつかのアプリケーションで、
障害が発見された後に、その一時的な障害から回復する
ために使われるようになった。

【０００４】これらのモジュール式の回復システムは、
洗練された回復方法を使用してきた。例えば、障害を起
こしたプロセスは、ロールバックが適切であると判断さ
れれば、直前のチェックポイントまでロールバックされ
る。モジュール式の回復システムで使われるより新しい
回復メカニズムは、ロールバックした後に、記録された
メッセージを再配列し、それを再実行することも含んで
いる。これについては、1993年 6月のフランス、トゥー
ルーズにおける第２３回フォルト・トレラント・コンピ
ューティング国際シンポジウム会報138 〜144 頁、Y.M.
Wang，Y.Huang，W.K.Fuchs 「分散システムにおけるソ
フトウエア・エラー・リカバリーのための順次的再試
行」（"Progressive Retry for Software Error Reco
very in Distributed Systems"）で説明されている（19
93年 6月20日の出版）。

【０００５】このような反応的フォルト・トレランス・
メカニズム（再始動、回復、ロールバック、再配列と再
実行）は、多くの場合有効に働き、長時間実行されるア
プリケーションにおいて高い可用性とデータの保全性を
保証可能とするには、常に実装すべきものである。この
メカニズムは、アプリケーションの外部で発生するだろ
う障害（例えば、テレコミュニケーションネットワーク
設備が切られた時は、アプリケーションは、回復処理に
入らなければならない。）から回復するのにも有効であ
る。

【０００６】反応的なフォルト・トレランス・メカニズ
ムは有効ではあるが、十分ではない。アプリケーション
が障害から回復できないようなバグは依然として存在
し、そういう状況下で回復を試みるのに費やす時間は、
ロスでしかない。その上、反応的なメカニズムでは、障
害を起こす状態に対しては、全く制御できない。また、
ある状態の下では十分な回復時間であっても、別の状態
の下では全く不十分ということもある。本発明に求めら
れ、本発明によって提供されることは、障害の発生を防
ぐための事前処理的な技術である。

【０００７】

【課題を解決するための手段】本発明は、あるアプリケ
ーションが障害を起こす可能性は、そのアプリケーショ
ンが走行しつづける時間の長さに従って増加するという
観察に基づいている。したがって、定期的にアプリケー
ションを停止し、真新しい内部状態で再始動すれば、障
害を防げることになる。この処置をここでは、「更新
（rejuvenation）」と呼ぶことにする。アプリケーショ
ンを更新する一つの方策は、新たに作られたプロセスは
真新しい内部状態を持っているという事実を利用するこ
とである。つまり、新たなプロセスによって実行される
よう、現在アプリケーションを実行しているプロセスを
停止し、そのアプリケーションを再始動させることによ
り、アプリケーションを更新することができるというこ
とである。

【０００８】好ましい実施例では、アプリケーションが
更新する予定であることを更新ユティリティに示すこと
によって、どんなアプリケーションでも更新することが
できる。そこでユティリティは、現在アプリケーション
を実行しているプロセスを終わらせて、新しいプロセス
でアプリケーションを再始動させる。好ましい実施例で
は、本特許出願の親出願で説明されたｗａｔｃｈｄデー
モン（注：デーモン：システムが稼働中、常にバックグ
ラウンドで実行されるプロセスで特別の機能サービスを
提供する役割を持つ）を使って、更新ユティリティは実
働化される。そこで説明したように、あるアプリケーシ
ョンをｗａｔｃｈｄに登録してあることもあり、その時
にには、ｗａｔｃｈｄがそのアプリケーションを監視し
ている。もしｗａｔｃｈｄが、現在そのアプリケーショ
ンを実行しているプロセスが動作しなくなるか、または
ハングアップしたことを検知したならば、ｗａｔｃｈｄ
は新しいプロセスでアプリケーションを再始動させる。

【０００９】ｗａｔｃｈｄをアプリケーションを更新す
るのに利用するのに好ましい実施例では、プロセスがａ
ｄｄｒｅｊｕｖシェルコマンドを実行する。命令を実行
することにより、そのアプリケーションと、そのアプリ
ケーションをいつ、どのように更新するべきかを指定し
ているメッセージをｗａｔｃｈｄに送ることになる。ｗ
ａｔｃｈｄは、アプリケーションを現在実行中であるプ
ロセスと、そのプロセスをどのように終わらせるべきか
を指定しているシェルスクリプトを作り、そのシェルス
クリプトをＵＮＩＸ（ＵＮＩＸはＸ／ＯＰＥＮの登録商
標）のｃｒｏｎ（注ｃｒｏｎ：ＵＮＩＸがマルチユー
ザー・モード状態の時に走行するプロセス。定期的なス
ケジュールに基づいてコマンドを実行する）ユティリテ
ィに登録することにより、メッセージに応答する。スク
リプトの登録では、ｗａｔｃｈｄは、更新メッセージが
指定した時刻にスクリプトが実行されるべきであること
を指定する。そこで、ｃｒｏｎは指定された時刻にスク
リプトを実行する。ｃｒｏｎが、更新するべきアプリケ
ーションを現在実行しているプロセスを停止したあと、
ｗａｔｃｈｄはプロセスが動作しなくなったことを検知
し新しいプロセスでアプリケーションを再始動させる。
それによりアプリケーションの更新を完了する。その他
の対象物および優位性については、以下に記述する詳細
な説明と図面とを参照することにより、当業者に明らか
となる。

【００１０】

【発明の実施の形態】図中の、参照番号は２つの部分に
別れていて、下２桁は、図の中での項目の番号であり、
残りの桁は、その項目が最初に出現した図の番号であ
る。したがって、参照番号２０１のつけられた項目は図
２に最初に出てくる。次に述べる「詳細な説明」では、最初に更新に関する理
論について論じ、そして本特許出願の親出願で記述した
ソフトウエア・フォルト・トレランスのための構成要素
が、どのように更新を実働化するのに用いられるかを示
す。本特許出願の親出願からのソフトウェア・フォルト
・トレランスの構成要素の記述の関連した部分が、本特
許出願に含められる。

【００１１】〔更新の理論〕次に述べる理論的な論述で
は、最初に、更新がどのように信頼性を増やすかを、一
般的に示し、そのうえで、故障の為の作業休止時間コス
トと比較した更新のコストを確定するモデルを提示す
る。そして最後に、更新させるべきアプリケーションを
どのように決定するかを示す。信頼性Ｒ_A （ｔ）をアプリケーションＡが障害を起こさない、
つまりｔ単位時間の処理の後もサービスを提供している
確率とする。すると、マルコフ過程の推測によって、Ｒ
_A （ｔ＋δｔ）は、Ａがｔ単位時間に障害を起こさない
確率Ｒ（ｔ）と、その後の区間δｔ内に障害が起きない
確率（１−λδｔ）の積に等しい。ここで、λは障害発
生率とする。よって、Ｒ_A （ｔ＋δｔ）＝Ｒ_A （ｔ）
（１−λδｔ）となる。Ｒ_A （０）＝１であるから、前
式は解を持ちＲ_A ＝ｅｘｐ（−λｔ）となる。よって、
システムの寿命は時間と故障率λについての指数分布に
従うものと仮定する。信頼性を表す一般に使われる別の
測定基準は、∫０∞Ｒ_A （ｔ）δｔで定義される平均故
障間隔（ＭＴＢＦ）である。これは、ＭＴＢＦ＝１／λ
で求められる。通常、ＭＴＢＦは経験的な方法によって
確定される。上記の指数分布の推測によれば、更新が行
われないアプリケーションＡの時刻ｔにおける信頼性
は、

【数１】である。

【００１２】ソフトウエアの更新は、前式を区分連続関
数とすることで、その信頼性分布を不連続なものにす
る。ここで、更新の周期をＴとすれば、信頼性Ａ^r は、

【数２】である。これら２つの信頼性分布（１）と（２）は図６
の実線６０１と６０２で例証されており、破線６０４と
６０５は次章で論じる２段階型の障害の動きを例証して
いる。

【００１３】作業休止時間と作業休止時間コスト：図７
および図８アプリケーションのパフォーマンス（つまり、そのサー
ビス能力）は、更新の間は、当然損なわれる。そこで、
更新の間の作業休止時間コストは更新（の実施）を決定
するにあったって計算に入れなければならない。更新は
スケジュールされた作業休止時間を含んでいるので、そ
の作業休止時間コストは、障害による予期せぬ作業休止
時間コストよりかなり小さいことが期待される。作業休
止時間コストを計算するため、まず最初に、図７に示さ
れる更新を行わないアプリケーションＡの確率状態遷移
を見る。

【００１４】あるアプリケーションが始動したとき、図
６の破線６０４で示されるそのベース寿命間隔に対応す
る期間は極めて頑強な状態Ｓ₀ にとどまっており、その
後、破線６０５に示される通常の障害発生率の状態Ｓ_N
に入る。これは、我々の経験によれば、十分にテストさ
れたソフトウエアシステムは障害が発生し得る状態（多
くの場合、あるプログラムが、その境界線状態に達する
か、そのリソースの一部を漏らすまでには間がある）に
達するまで暫くは、「健康な」状態に止まるからであ
る。このように、ソフトウエアシステムにおいては、図
７における状態Ｓ０から状態Ｓ_N そして状態Ｓ_N から状
態Ｓ_F への遷移によって、また、図６の破線６０４と６
０５によって示されるように障害は２段階の行動であ
る。状態Ｓ₀から状態Ｓ_F へ推移する確率は、他の確率
に比べて無視できるものと仮定する。前章で説明したよ
うに、Ａは確率的平均λでＳ_N からＳ_F に移る。修復後
は、Ｓ_f からＳ₀ に戻る。アプリケーションＡの修復時
間もまた、定数ｒ₁ の指数分布であると仮定する。既
に、図７にてＡが平均的確率ｒ₁ でＳ₀ からＳ_N に移動
することを示した。現実的には、ｒ₂ ＞＞λ、つまりア
プリケーションは２段階の障害行動の最初の段階の移行
は、障害の第２段階よりも速やかに行われる。このよう
な、状態Ｓ₀ から始まる２段階の障害行動では、等式１
のＲ_A （ｔ）は、図６の破線６０４と６０５で示される
ように双曲線関数であるべきである。しかし、ｒ₂ ＞＞
λゆえ、指数分布は良い近似である。

【００１５】これらの仮定の下に、等式ｐ₀ ＋ｐ_n ＋ｐ
_f ＝１，ｐ_n ・λ＝ｐ₀ ・ｒ₂ ，ｐ_f ・ｒ₁ ＝ｐ_n ・λ
を解くと（ここで、ｐ₀ 、ｐ_n 、ｐ_f はシステムが状態
Ｓ₀、S_N 、Ｓ_F にある確率を表す）、そのシステムの定
常使用不可係数、Ｐ_f が、１／（１＋（ｒ₁ ／λ）＋
（ｒ₁ ／ｒ₂ ））に等しいことが導かれる。そこで、Ｌ
単位時間間隔におけるＡの総作業休止時間の期待値は、

【数３】となる。Ｃ_f をＡの予定していない作業休止時間の単位
当たりの平均コストとすると、Ｌ単位時間間隔における
Ａの総作業休止時間コストの期待値は、

【数４】となる。

【００１６】ここで、図８に示す更新を伴うアプリケー
ションＡの確率状態遷移図８０１を考えよう。図８で
は、Ｓ_R は、更新された状態その他は、前述のとおりで
ある。更新率ｒ₄ と更新実施後の修復率ｒ₃ もまた、指
数分布に従うと仮定する。アプリケーションがｔ単位時
間経過毎に更新がなされるとすると、ｒ₄ は１／ｔに等
しい。この更新処理を伴うＡのモデルから生成される確
率方程式を解くと、各確率状態に対して以下の式を得
る。

【数５】

【数６】

【数７】

【数８】

【００１７】Ｌ単位時間間隔における更新を伴うＡの総
作業休止時間の期待値は、

【数９】となる。前述の場合に同じくＣ_f を予定していない作業
休止時間の平均コストとし、Ｃ_r を更新処理中の平均コ
ストとすれば、Ｌ単位時間間隔におけるＡの総作業休止
時間コストの期待値は、

【数１０】となる。更新処理を実行しなければｒ₄ ＝０であるか
ら、数式３と５においては、

【数１１】また、数式４と６においては、

【数１２】となることにより、これを証明できる。アプリケーショ
ンが最も遊休状態にある時間に更新を実行すれば、ｒ₃
＞ｒ₁ かつＣ_f ＞＞Ｃ_r であり、それゆえ、数式６で計
算された更新を伴うＡの総作業休止時間の期待値は、数
式４で計算された更新を伴わないＡの総作業休止時間の
期待値よりも低いだろう。このような更新の境界値につ
いては、次章で議論する。

【００１８】更新の境界値更新率ｒ₄ が変化したとき、作業休止時間と作業休止時
間コストがどう変化するのか考えよう。ｐ_f およびｐ_r
にその値を代入することにより、数式９は、

【数１３】と書ける。ｒ₄ が変化したときの作業休止時間の振る舞
いを調べるため、上記の等式をｒ₄ に関して微分する必
要がある。等式９の分子と分母がｒ₄ について１次関数
であることに注意する。そこで、作業休止時間関数を微
分して、

【数１４】を得る。上記の導関数の分母がいつも正で、そして分子
の符号がｒ₄ から独立した式、［ｒ₁ （１＋（ｒ₂ ／
λ））−ｒ₃ ］によって決定されることに注目すると、
興味深い。これは、ｒ₄ が変化したときに作業休止時間
が増加するか減少するかは、完全にλ、ｒ₁ 、ｒ₂ およ
びｒ₃ の値によって決まることを意味している。ｒ₃ が
ｒ₁ （１＋（ｒ₂ ／λ））よりも大きいとき、導関数は
負となり、ｒ４の値が変わるときに作業中止時間が常に
減少することを意味している。

【００１９】同様に、ｒ₃ がｒ１［１＋（ｒ₂ ／λ）］
よりも小さいとき、導関数は正となり、ｒ₄ の値が変わ
るときに作業中止時間が常に増加することを意味してい
る。ここで、更新率ｒ₄ が変化したときの作業休止時間
コストの振る舞いを決定するため、数式６を調べる。数
式６の関数Ｃｏｓｔ_A ^r をｒ₄ に関して微分して、

【数１５】を得る。ここでもまた、上記の導関数の分母がいつも正
で、そして分子の符号はｒ₄ から独立した式［ｃ_r −ｃ
_f ｛λ（ｒ₂ ＋ｒ₃ ）／（λ（ｒ₁ ＋ｒ₂ ）＋ｒ₁
ｒ₂）｝］によって決定される。これは、ｒ₄ が変化し
たときに総作業休止時間コストの期待値が増加するか減
少するかは、完全にＣ_r 、Ｃ_f 、λ、ｒ₁ 、ｒ₂ および
ｒ₃ の値によって決まることを意味している。

【００２０】これにより、非常に興味深い情報が得られ
る。あるアプリケーションに更新を行うべきか否かを決
定するのは、それによって更新が行われる更新率ｒ₄ に
よるのではなく、モデル中の他のパラメータによるので
ある。例えば、あるアプリケーションの更新と障害コス
トＣ_r とＣ_f は条件式ｃ_r ＜ｃ_f ［λ（ｒ₂ ＋ｒ₃ ）／
（λ（ｒ₁ ＋ｒ₂ ）＋ｒ₁ ｒ₂ ］（以下、条件式Ｐとす
る）が満たされるようなものであるかもしれない。その
場合、ｒ₄ に関してそのコスト関数の傾きは負であり、
ｒ₄ が増加するとき、総作業休止時間コストの期待値が
減少することを意味する。これは、そのアプリケーショ
ンが更新によって利益を得ることを意味する。このケー
スでは、ｒ₄ が増加するとき総コストは減少しつづける
ことが与えられているので、いつでも、条件式Ｐが満た
されるかぎり、できるだけ多く更新を行う方が良いこと
になる。同様に、更新コストＣ_r がｃ_f ［λ（ｒ₂ ＋ｒ
₃）／（λ（ｒ₁ ＋ｒ₂ ）＋ｒ₁ ｒ₂ ］より大である場
合を考える。仮に、このアプリケーションに更新を実施
すると、更新率ｒ₄ が増加するとき総コストは増加す
る。これは、このアプリケーションが更新によって全く
利益を得ないことを意味する。

【００２１】上記の議論は、ある境界となる効果が存在
することを表している。ｒ₄ ＝０のとき、更新はなく、
その作業休止時間とコストの値は、先に示した様に計算
できる。ｒ₄ が増加したとき、作業休止時間が増加する
か減少するかは、完全に条件式ｒ₃ ＜ｒ₁ （１＋（ｒ₂
／λ））が満たされるか否かにかかっている。同様に、
ｒ₄ が増加したとき、作業休止時間によって生じるコス
トが増加するか減少するかは、完全に条件式Ｐが満たさ
れるか否かにかかっている。どちらの条件もｒ₄とは、
独立している。作業休止時間およびコストの関数は、こ
れらの条件が保持される限り、増加または減少し続け
る。

【００２２】更新機能の例更新機能は、ＡＴ＆Ｔ長距離ネットワークを介し、且つ
ＲＢＯＣ（Regional Bell Operating Companies ）の数
社で現在展開されているＢＩＬＬＤＡＴＳＩＩコレクタ
ー、請求発行データ収集システム（ＢＩＬＬＤＡＴＳＩ
Ｉは、ＡＴ＆Ｔ社の登録商標）で実施されてきた。この
システムにおける更新の間隔は、保守的に、フィールド
設置（installation）ごとに１週間で設定され、テスト
中のシステムのために確立された基準の寿命に近づく。
更新機能付のＢＩＬＬＤＡＴＳＩＩコレクターのフィー
ルドオペレーションが２年を超えたあと、セクション１
で記述した寿命に影響を与える種類の障害が今までにひ
とつも起こらなかった。これは、ＢＩＬＬＤＡＴＳＩＩ
コレクターシステムは、この２年の間、何であっても障
害がなかったと言うわけではない。それらのすべての障
害の原因分析（ＲＣＡ：root cause analysis ）は、そ
の障害が、更新される構成要素に係わるものでないこと
を示した。

【００２３】ｗａｔｃｈｄを用いる更新のインプリメン
テーションＢＩＬＬＤＡＴＳＩＩにおける更新のインプリメンテー
ションは、そのシステムにとって特有のものである。好
ましい実施例では、いかなるユーザーレベルのアプリケ
ーションにも更新を適用できるようにソフトウエアのフ
ォルト・トレランスのためにもともと開発された構成要
素のセットが用いられる。これらの構成要素の次の説明
は、本特許出願の親出願からのものである。ソフトウエ
アのフォルト・トレランスのための構成要素の標準セッ
トは、自動フォルト検出を与えるためのモニタと、どの
ようにアプリケーション状態がセーブされ回復されるべ
きかを決定するためいかなるアプリケーション・プログ
ラムによっても使用されうるプログラムの再始動機能お
よびフォルト・トレラント・ライブラリとを含む。次の
説明は、モニタ（ここでは、ｗａｔｃｈｄデーモンまた
は単にｗａｔｃｈｄと呼ぶ）と、フォルト・トレラント
・ライブラリ（ここでは、ｌｉｂｆｔと呼ぶ）と、共同
してアプリケーションレベルのフォルト・トレラント・
コンピューティングを許容する方法の概要を示し、ま
た、それらのインプリメンテーションの詳細を示す。

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

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

【００２６】ｌｉｂｆｔコード１１３におけるルーチン
によれば、クリティカルメモリ（ＣＲＭＥＭ）１１５
としてデータにささげられる揮発性メモリ１０５の一部
を部分指定できる。矢印１１９により示されるようにｌ
ｉｂｆｔコード１１３における他のルーチンは、フォル
ト・トレラント・プロセス１０３に、図１にクリティカ
ル・メモリ・コピー（ＣＲＭＥＭＣ）１２５として示
されている持続性メモリ１２３へＣＲＭＥＭ１１５の
データを書き込ませる。このオペレーションは、「チェ
ックポインティング」と呼ばれている。ハングアップま
たはクラッシュしたあとプロセス１０３が再始動される
場合、（矢印１２１によって示されるように）ｌｉｂｆ
ｔコード１１３における別のルーチンは、プロセス１０
３に、それぞれ矢印１１９および１２１により示される
ように１２５におけるコピーからＣＲＭＥＭＣ１１５
内のデータを回復させる。持続性メモリ１２３はまた、
ログファイル１２７を含んでもよい。ログファイル１２
７は、ｌｉｂｆｔ１１３により与えられる特別なＩ／Ｏ
読み込み書き取りオペレーションからの結果データのロ
グを含む。これらのオペレーションは、それぞれ矢印１
３１および１２９として示される。プロセス１１３が再
始動されるとき、他のファイル上のＩ／Ｏを実行し始め
る前にログファイル１２７におけるメッセージのすべて
を使い果たす。

【００２７】クラッシュまたはハングアップしてしまっ
た場合のフォルト・トレラント・プロセス１０３の再始
動は、ｗａｔｃｈｄデーモン１０４により行われる。ｗ
ａｔｃｈｄデーモン１０４は、次の２つのリスト：デー
モンがモニタするためのノード内のフォルト・トレラン
ト・プロセスを列挙しているフォルト・トレラント・プ
ロセス（ＦＴＰ）リスト１３９と、グループ内のいずれ
かのフォルト・トレラント・プロセス１０３がハングア
ップまたはクラッシュした場合に再始動されなければな
らないフォルト・トレラント・プロセスのグループを列
挙しているフォルト・トレラントグループ（ＦＴＰグル
ープ）リスト１４１とに関連している。後にさらに詳し
く説明するように、リスト１３９内のフォルト・トレラ
ント・プロセス１０３の入力は、いずれのログファイル
１２７のみならずプロセス１０３がいかにしてモニタさ
れるかを示す。

【００２８】デーモン１０４は、フォルト・トレラント
・リスト１３９で指定された方法でフォルト・トレラン
ト・リスト１３９で指定されたフォルト・トレラント・
プロセス１０３をそれぞれモニタし、矢印１３３が示す
ようにプロセス１０３がハングアップまたはクラッシュ
したか否かを決定する。モニタリングは、能動であって
も、すなわち、ｗａｔｃｈｄデーモン１０４は、プロセ
ス１０３をポーリングし、その状態を決定しても、受動
であっても、すなわち、プロセス１０３により実行され
る場合デーモン１０４に信号を送信し、時間的間隔を指
定するｌｉｂｆｔ１１３内のルーチンがあってもよい。
デーモン１０４がその間隔の最後に至る前にルーチンか
ら別の信号を受けない場合は、デーモン１０４は、プロ
セス１０３は、ハングアップもしくはクラッシュしたも
のと仮定する。

【００２９】デーモン１０４がフォルト・トレラント・
プロセス１０３がクラッシュしたものと決定した場合、
デーモン１０４は、プロセス１０３と、グループリスト
１４１に特定されるプロセス１０３を含むいずれのグル
ープに属するいかなる他のプロセス１０３とを再始動さ
せる。再始動プロセスは、次の通り：プロセスが再始動
された後、クリティカルメモリ１１５はいずれも、クリ
ティカル・メモリ・コピー１２５から回復される。ログ
ファイル１２７が存在する場合は、再始動プロセスは、
ログファイル１２７内のメッセージを使い尽くす。

【００３０】フォルト・トレラント・コンピューティン
グ１０１のシステムには、次の記載すべき特徴がある。
まず、システム１０１は、システムが作動するところの
ノードのハードウエアまたはオペーレーティングシステ
ムが何であれ修正を必要としない。フォルト・トレラン
ト・プロセス１０３は、通常のユーザープロセスであ
り、ｗａｔｃｈｄデーモン１０４は、ユーザープロセス
を用いて実行される。さらに、ｌｉｂｆｔおよびｗａｔ
ｃｈｄデーモンにより実行されるコードは、Ｃ言語で書
かれ、さまざまなオペレーティングシステム下で走行す
るよう容易に適合される。第二に、ｗａｔｃｈｄデーモ
ン１０４を有するノードにおいては、プロセスにより実
行されるコードにｌｉｂｆｔ１１３からのルーチンを取
り込むことにより、いかなるプロセスも容易にフォルト
・トレラント・プロセス１０３に成りえる。アプリケー
ション・プログラマーがアプリケーション・コードにお
いてフォルト・トレラント機能を引き続き再度インプリ
メンテーションする必要はもはやない。第三に、システ
ム１０１は、高い汎用性を提供する。ｌｉｂｆｔ１１３
におけるルーチンを用いると、アプリケーション・プロ
グラマーは、そのプログラマーのアプリケーションに要
するフォルト・トレランスの量を正確に有するプログラ
ムを提供できる。オプションは、ｗａｔｃｈｄデーモン
１０４をともなうプロセスを単に位置決め（resisterin
g ）することに及び、このため、必要であれば、プロセ
スのメモリの一部がクリティカルメモリ１１５であると
宣言し、クリティカル・メモリ・コピー１２５にクリテ
ィカルメモリ１１５を定期的にセーブすることによりプ
ロセスを監視し、再始動させることができ、このためプ
ロセスがログファイル１２７におけるクリティカルメッ
セージのログを作成するためにデーモン１０４によって
再始動されたあと回復され、再始動されたプロセスは、
メッセージを使い尽くすことができる。

【００３１】複数のノードを有するシステム内のｗａｔ
ｃｈｄおよびｌｉｂｆｔの概略：図２単一のノードのハ
ードウエアまたはオペレーティングシステムが決して故
障しない場合には、図１に示されたシステムは妥当であ
るが、ハードウエアまたはオペレーティングシステムが
故障した場合には役に立たない。この問題は、分散型シ
ステム特有の冗長度の利点を使用することにより解決さ
れるはずである。分散型システムに与えられたノードが
故障しても、システム内のすべてのまたはほとんどのノ
ードが同時に故障することは非常に稀である。したがっ
て、ひとつのノード上のフォルト・トレラント・プロセ
ス１０３が別のノード上で再始動されうる場合、プロセ
ス１０３は、最初のノード上のハードウエアおよびオペ
レーティングシステムのフォルトに対して耐性を有する
こととなる。

【００３２】図２は、そのような分散型システムを示
す。システム２０１は、それぞれＡ、ＢおよびＣでラベ
ル付けされた３つのノード２０３を有する。ノードはそ
れぞれ、他のノードのうちの少なくとも一つと接続する
ためのコミュニケーションリンクのみならず、少なくと
も一つのプロセッサとメモリとを有する。ノードはそれ
ぞれ、ｗａｔｃｈｄデーモン１０４を有し、したがって
フォルト・トレラント・プロセス１０３をも有する。図
２には３つのフォルト・トレラント・プロセス１０３：
１０３（０）、１０３（１）および１０３（２）が存在
している。各ノードのデーモン１０４は、そのためのプ
ロセスの現状だけでなく、他のノード２０３の現状をも
モニタする。好ましい実施例では、ｗａｔｃｈｄデーモ
ン１０４とそれが監視するノード２０３との関係は、シ
ステム２０１内のノード２０３がフォルト診断のための
適応リング２１１を形成するほどのものである。このよ
うにして、デーモン１０４（Ａ）は、ノード２０３
（Ｂ）を監視し、デーモン１０４（Ｂ）は、ノード２０
３（Ｃ）を監視し、デーモン１０４（Ｃ）は、ノード２
０３（Ａ）を監視する。デーモン１０４がどのノード２
０３を監視するかは、ノードリスト（ＮＬ）２０５によ
り決定される。ノードリスト２０５の等しいコピーは、
各ノード内のデーモン１０４に利用される。ノード２０
３（ｉ）が故障した場合、その事実は、ｗａｔｃｈｄデ
ーモン１０４により示され、ｗａｔｃｈｄデーモン１０
４は、残存しているノードにメッセージを伝達し、ノー
ドリスト２０５を修正して、ノード２０３（ｉ）のロス
を反映する。

【００３３】もちろん、ノード内のｗａｔｃｈｄデーモ
ン１０４が別のノードからのフォルト・トレラント１０
３を再始動させるものである場合、そのプロセス１０３
の状態のコピーを有さなければならない。このようにし
て、システム２０１内のデーモン１０４の別の機能は、
プロセッサ１０３の状態のコピーを保持することであ
る。その状態は、ファイル内に記憶され、クリティカル
メモリ１２５のいずれのコピーおよびそのプロセスのた
めのいずれのログファイル１２７をも含む。プロセス状
態のコピーは、プロセス番号と、ノード２０３（Ｃ）上
のノード２０３（Ａ）からのプロセス１０３（１）の状
態の１０３（１）’および、ノード２０３（Ａ）上のノ
ード２０３（Ｂ）からのプロセス１０３（０）の状態の
コピー１０３（０）’で示されたような「’」マークに
よって図２に示されている。図２に見られるように、プ
ロセス状態は、監視されるノード２０３からｗａｔｃｈ
ｄデーモン１０４のノード２０３にコピーされる。コピ
ーは、デーモン１０４により監視されるノード内に作成
され、ウオッチング・デーモン１２４ヘ随時送られ、ク
リティカル・メモリ・コピー１２５またはプロセス１０
３のためのログファイル１２７においてかなりの変更が
存在する。システム２０１では、単に単一のコピーが作
成され、それゆえシステム２０１のリング２１１内の２
つの隣り合うノードが故障しない限り再始動が可能であ
る。たとえば、デーモン１０４（Ａ）は、デーモン１０
４（Ｃ）へプロセス１０３（１）の状態のコピーを供給
することができ、次にデーモン１０４（Ｃ）は、デーモ
ン１０４（Ｂ）へプロセスの状態のコピーを供給でき、
またこの場合、プロセス１０３（１）を再始動不能とす
るためにはシステムのすべてのノードが故障しなければ
ならない。

【００３４】前述の説明から明らかなように、各デーモ
ン１０４は、各フォルト・トレラント１０３が、システ
ム２０１のどこで走行しているかを知らなければならな
い。この情報は、ステータス・テーブル２０７に含ま
れ、この各デーモン１０４は、まったく同じコピーを有
する。後述するように、ステータス意テーブル２０７
は、他のすべてのｗａｔｃｈｄデーモン１０４に対して
始動または再始動させるときメッセージを送るｗａｔｃ
ｈｄデーモンをそれぞれ有し、また、メッセージにより
要求されるようにステータス・テーブル２０７をアップ
デートすることによりそのようなメッセージに対応する
デーモン１０４をそれぞれ有することにより一貫されて
いる。

【００３５】ノード２０３（ｉ）が使用状態に戻ると
き、そのノード内のｗａｔｃｈｄデーモン１０４（ｉ）
は、デーモン１０４により監視されるノード内でデーモ
ン１０４からステータス・テーブル２０７のコピーを入
手する。ステータス・テーブル２０７は、ノード２０３
（ｉ）とそれらのプロセスを再始動するために必要な状
態を含むファイルとへ局所的なプロセス１０３をどのノ
ード２０３が現在実行しているかを示す。デーモン１０
４（ｉ）は、現在プロセスを実行しているノードからフ
ァイルのコピーを入手し、コピーを使用するプロセスを
再始動させる。上述したように、デーモン１０４（ｉ）
がプロセスを再始動させるとき、システム２０１内の他
のデーモン１０４にメッセージを送る。そして、デーモ
ン１０４が再始動されたプロセスを走行させている場
合、そのデーモン１０４は、プロセスの走行を中止し、
プロセス１０３が現在ノード２０３（ｉ）上で走行して
いることを示すようにステータス・テーブル２０７を修
正する。他のすべてのデーモン１０４は、ちょうど示さ
れたようにそれらのステータス・テーブル２０７を修正
するだけである。

【００３６】デーモン１０４はそれぞれ、次のアルゴリ
ズムにしたがって作動する。アルゴリズムでは、フォル
ト・トレラント・プロセス１０３はそれぞれ、（ｉで示
される）識別子を有する。加えて、プロトコル内で使用
される４つの補助変数がある。１．ｐｉ：プロセスｉが走行すると思われるところの主
要ノードの名称；この情報は、ステータス・テーブル２
０７から得られる。２．ｆｉ：プロセスｉの連続する故障の数。３．ＬｏｃａｌＨｏｓｔ：ローカルホストの名称。４．ＭｙＷａｒｄ：私が監視しようと思うノードの名
称。５．ＭｙＯｌｄＷａｒｄ：私がすでに監視したノードの
名称。アルゴリズムのクリティカル状態ファイルは、クリティ
カル・メモリ・コピー１２５とプロセスのためのログフ
ァイル１２７を含む。プロセスにより実行されるプログ
ラムの開発者により供給されたメカニズムによりこれら
ファイルは保持されることが可能であり、ｌｉｂｆｔフ
ォルト・トレラントライブラリ１１３により供給された
メカニズムにより保持されてもよい。

【００３７】１．/ ^* 初期化^* / （ａ）作動中のノード２ー３から（任意に選択）ステー
タス・テーブル２０５および２０７を得る；有効な他の
ノード２０３がない場合は、ステータス・テーブルを初
期化する；（ｂ）局所的に走行すべきプロセスｉそれぞれにつき、ｉ．ステータス・テーブルからｐｉを得る；ｉｉ．ノードｐｉからプロセスの最も最近の状態を得
る；。ｉｉｉ．プロセスを再始動させ、ステータス・テーブル
を全体的にアップデートする；２．ループ永久的：開始（ａ）プロセスｉそれぞれについてループ；開始ｉ．ステータス・テーブルからｐｉを得る；ｉｉ．ｐｉ＝ＬｏｃａｌＨｏｓｔであればＡ．プロセスｉが有効であり、ハングアップしていない
場合、ｆｉ＝０；継続する；Ｂ．増分ｆｉ；Ｃ．ｆｉ＜ｍａｘであれば、プロセスｉを再始動させ、
ステータス・テーブルを全体的にアップデートする；も
しくは、ｆｉ＝ｍａｘであれば、プロセスｉを回復する
ためバックアップノードを知らせる；もしくは、ｆｉ＞
ｍａｘであれば、緊急忠告メッセージをプリントアウト
する；ｉｉｉ．もしくは、ノードＭｙＷａｒｄがちょうど故障
した場合、Ａ．ＭｙＯｌｄＷａｒｄをＭｙＷａｒｄにセットする；Ｂ．私の新しいワードを見つけ、ＭｙＷａｒｄを私の新
しいワードにセットする；Ｃ．ｐｉ＝ＭｙＷａｒｄであれば、/ ^* わたしはプロセ
スのバックアップとなる^* /ＭｙＷａｒｄからのプロセ
スｉのクリティカル状態ファイルすべてをコピーする；Ｄ．もしくは、ｐｉ＝ＭｙＯｌｄＷａｒｄであれば、/
^* プロセスのための主要ノードがちょうど故障^* /プロ
セスｉを再始動させ、ステータス・テーブルを全体的に
アップデートする；クリティカル状態ファイルをすべて
私のバックアップにコピーする；ｉｖ．もしくは、Ａ．プロセスｉが局所的に走行している場合、プロセス
の走行を中止する；終了；（ｂ）事故（時間切れ、または、プロセスクラッシュ）
のためウエイトする；終了；

【００３８】ノード故障および使用状態への復帰の例どのようにしてノードが故障し、使用状態に復帰するか
をさらに詳しく示すために、ノード２０３（Ａ）と２０
３（Ｂ）と２０３（Ｃ）とを有する前のシステムを一例
として考慮する。説明を簡素化するため、ｙｅａｓｔｄ
と称される単一のプロセス１０３にのみついて考える。
プロセスは、ｙｅａｓｔｄ．ｓｔａと称されたファイル
上にその状態を定期的に保存し、ログファイルｙｅａｓ
ｔｄ．ｌｏｇを有するものと仮定する。ノードＡは、ノ
ードＢを監視し、ノードＢは、ノードＣを監視し、ノー
ドＣは、ノードＡを監視する。まず、これらすべてのノ
ードは、有効であり、プロセスｙｅａｓｔｄは、ノード
Ａ上で走行している。では、次のシナリオで考えてみよ
う。１．ノードＣがダウン： ●ノードＡは、なにもしない； ●ノードＢは、ノードＡからファイルｙｅａｓｔｄ．ｓ
ｔａとｙｅａｓｔｄ．ｌｏｇとをコピーし、ウオッチン
グ・ノードＡとプロセスｙｅａｓｔｄとを始動させる；２．ノードＣがシステムに再度加わる： ●ノードＡは、なにもしない； ●ノードＣは、ノードＡからファイルｙｅａｓｔｄ．ｓ
ｔａとｙｅａｓｔｄ．ｌｏｇとをコピーし、ウオッチン
グ・ノードＡとプロセスｙｅａｓｔｄとを始動させる； ●ノードＢは、ウオッチング・ノードＡを停止し、ウオ
ッチング・ノードＣを開始する；３．ノードＡがダウン： ●ノードＣは、プロセスｙｅａｓｔｄを再始動させ、ス
テータス・テーブル２０７およびノードリスト２０５を
全体的にアップデートし、ウオッチング・ノードＢを始
動させる； ●ノードＢは、ノードＣからファイルｙｅａｓｔｄ．ｓ
ｔａとｙｅａｓｔｄ．ｌｏｇとをコピーし、ウオッチン
グ・ノードＣとプロセスｙｅａｓｔｄとを始動させる；４．ノードＡがシステムに再度加わる： ●ノードＡは、ノードＣからファイルｙｅａｓｔｄ．ｓ
ｔａとｙｅａｓｔｄ．ｌｏｇとをコピーし、ステータス
・テーブル２０７およびノードリスト２０５を全体的に
アップデートし、ウオッチング・ノードＢを始動させ
る； ●ノードＣは、ｙｅａｓｔｄプロセスを停止し、ウオッ
チング・ノードＢを停止し、ウオッチング・ノードＡを
始動させる； ●ノードＢは、ウオッチング・プロセスｙｅａｓｔｄを
停止する；５．ｙｅａｓｔｄプロセスがクラッシュ、ノードＡのみ
有効 ●ノードＡは、プロセスを再始動させる；再始動が特定
の回数失敗した場合、ノードＡは、ノードＣにプロセス
を回復するよう知らせる； ●ノードＣは、何もしないか、または、ノードＡにより
指示された場合にｙｅａｓｔｄプロセスを再始動させ、
ステータス・テーブル２０７を全体的にアップデートす
る； ●ノードＢは、何もしないか、または、プロセスがノー
ドＣにより再始動された場合にノードＣ上でウオッチン
グ・プロセスｙｅａｓｔｄを始動させる。デーモン１０
４はそれぞれ、ステータス・テーブル２０７を保持す
る。プロセスがあるノード上で再始動される場合、その
ノードのデーモン１０４は、すべての他のノードにアッ
プデートメッセージを送る。

【００３９】なお、ネットワーク・トランジエントの故
障が起こった場合や、ノード２０３がシステムを再度加
える場合、プロセス１０３の１つ以上のコピーが同時に
走行することができる。プロセスのたったひとつの有効
なコピーがどの時点でも走行していることを確実にする
ために、ｗａｔｃｈｄデーモン１０４はそれぞれ、いく
つかの別のノード１０３上で走行すると思われるプロセ
ス１０３も局所的に走行しているかを定期的に確認す
る。もし、そうであれば、デーモン１０４は、プロセス
に終了信号を送ることにより、プロセス１０３を走行さ
せることからそのノード１０３を停止しなければならな
い。たとえば、前述の例でのシナリオ４を考えて見よ
う。ノードＡが故障したあと、ノードＡ上で走行してい
たプロセスｙｅａｓｔｄは、ノードＣ上で再始動され
る。その後、ノードＡは、修復され、システムに再度加
わる。ノードＡの上のｗａｔｃｈｄデーモンは、フォル
ト・トレラント・プロセス・リスト１３９を読み込み、
ノードＡがプロセスｙｅａｓｔｄを走行すべきであるこ
とを知る。まず、作動中ノードから最も最近のステータ
ス・テーブルを読み込み、プロセスｙｅａｓｔｄが現在
ノードＣで走行していることを見つける。ｙｅａｓｔｄ
プロセスを走行させるる応答性を引き継ぐため、ノード
Ａは、まず、ノードＢからプロセスの状態ファイルをコ
ピーし、そしてプロセスを再始動させる。プロセスが首
尾良く再始動された場合、ノードＡ上のｗａｔｃｈｄデ
ーモンは、それらのステータス・テーブル２０７をアッ
プデートするために他のすべてのノードにアップデート
メッセージを広める。アップデート後、ノードＣは、ノ
ードＡが上げられ、ｙｅａｓｔｄプロセスがノードＡ上
で走行していたことを見つける。ゆえに、ノードＣは、
もはやプロセスを走行させなければならない。この場
合、デーモン１０４（Ｃ）は、ノード２０３（Ｃ）で走
行するプロセス１０３に終了信号を送る。なお、プロト
コルは、ノードＡが、システムに再度加わるときに、プ
ロセスｙｅａｓｔｄを引き継ぐようにする。このステッ
プは、ロードのバランシングのために必要である。この
ステップなしでは、すべてのプロセス１０３が、遂に
は、最後に故障するノード２０３上でのみ走行してしま
う。

【００４０】リング変形（reconfiguration ）の例リング２１１が（故障または修復により）変形される際
は常に、ノード２０３間のクリティカル状態をコピーす
る必要がある。上述の例でのシナリオ３（複製の度合を
２とする）を考えて見よう。ノードＡが故障する前に、
ノードＡ上のプロセスｙｅａｓｔｄは、ノードＢにでは
なく、ノードＣにその状態をチェックポイントする。し
たがって、ノードＢは、プロセスｙｅａｓｔｄの状態を
持たない。ノードＡが故障した際、ノードＣは、その前
の状態とともにプロセスを再始動させ、同時に、ノード
Ｂは、ノードＣからそのプロセス（すなわちｙｅａｓｔ
ｄ）の状態ファイルをコピーする。ノードＣからノード
Ｂへの状態ファイルのコピーは、回復におけるノードＣ
の故障の可能性を処理するために必要出ある。いぞれに
せよ、チェックポイントが確立される前にノードＣが再
度故障した場合は、ノードＢは、プロセスの状態を持た
ないためプロセスを回復できない。

【００４１】ｗａｔｃｈｄデーモンの詳細図３は、いかにしてデーモン１０４が好ましい実施例で
実現されるのかを示している。図３において、実線の矢
印は、情報のフローを示し、点線の矢印は、プロセス間
の親子関係を示す。ｗａｔｃｈｄデーモン１０４は、２
つのユーザープロセス：モニタ（ＭＯＮ）３０１と状態
サーバー（ＳＴＡＴＥＳＲＶＲ）３０３とによって実
施される。この設計には２つの理由がある。 ●デーモン１０４が故障する可能性を最小限にするた
め、不正確な実行が極めてありえないように十分に単純
な構成要素を含まなければならない、また、 ●デーモン１０４は、時間依存式と非同期式の両方のオ
ペレーションを実行できなければならない。非同期式の
オペレーションが時間依存式のオペレーションを妨げる
ことは許容されない。モニタ３０１で開始する場合、モ
ニタ３０１は、以下に述べることを行う： ●モニタ３０１が走行を開始するとき、状態サーバー３
０３を作り出すため、ＵＮＩＸオペレーティングシステ
ムのＦＯＲＫ機能を用いることを含む初期化オペレーシ
ョンを実行する； ●初期化後、モニタ３０１は、以下に列挙することを行
う：１．クラッシュしたか否かを決定するためプロセス１０
３をポーリングする；２．状態サーバー３０３にメッセージを送る時間か否か
を決定するためにクロック３０２を監視する；３．ポーリングが、プロセス１０３が停止したことを、
もしくは、タイムメッセージが送られる必要があるとき
を示す場合、状態サーバー３０３にメッセージを送る；４．状態サーバー３０３がクラッシュした場合、モニタ
３０１は、状態サーバー３０３を再始動させる。

【００４２】モニタ１０４の他のすべてのオペレーショ
ンは、状態サーバー３０３により実行される。特に、状
態サーバー３０３は、監視されるノード２０９が有効で
あるか否か、および、プロセス１０３がクラッシュまた
はハングアップしたか否かをポーリング以外の方法で決
定し、テーブル１３９、１４１、２０５、および２０７
を保持し、他のノードへプロセス状態のバックアップコ
ピーを供給する。より詳しくモニタ３０１により実行さ
れたオペレーションで引き続くと、信号０で使用された
場合、チェックされているプロセスの動作に影響を及ぼ
さないが、プロセスが停止された場合エラー値を戻すＵ
ＮＩＸオペレーティングシステムのキル・システム・コ
ールを使用することによりフォルト・トレラント・プロ
セス１０３がクラッシュしたか否かを決定するため、モ
ニタ３０１はポーリングを行う。ポーリングは、図３に
示されている。モニタ３０１がプロセス１０３が停止さ
れたことを検出した場合、プロセスを再始動する状態サ
ーバー３０３にメッセージ（矢印３０５で示される）を
送る。モニタ３０１は、時間がかなりであることを示す
状態サーバー３０３からのメッセージに応じてかなりの
時間を見失わないようにする。かなりの時間が生じたと
き、モニタ３０１は、その時間を示すメッセージを状態
サーバー３０３（矢印３０５により示される）に送る。
モニタ３０１は、プロセスの親がその子供が停止したと
きに受けるＵＮＩＸオペレーティングシステムのＳＩＧ
ＣＨＬＤ信号によって状態サーバー３０３がクラッシュ
したことを検出する。

【００４３】デーモン１０４の残りのオペレーション
は、状態サーバー３０３によって実行される。状態サー
バー３０３は、矢印３１１で示されたように、他のノー
ド２０３内のデーモン１０４と通信し、矢印３０６で示
されたように、ポーリング以外の方法で局所的に走行し
ているフォルト・トレラント・プロセス１０３の状況、
および、矢印２０９で示されたように、リング２１１内
の次のノード２０３の状況をモニタする。状態サーバー
３０３は、そのノードのデーモン１０４にメッセージを
送付することにより次のノード２０３の状況をモニタす
る。デーモン１０４が反応しなかった場合は、次のノー
ド２０３は、ダウンすると予測される。次のノード２０
３がダウンすることを検出すると、状態サーバー３０３
は、そのノードがダウンすることを示すメッセージを他
のデーモン１０４に送り、そのノード２０３内でリング
２１１を変形するため必要な作業を行う。局所的フォル
ト・トレラント・プロセス１０３が停止したかハングア
ップしたかを決定するために状態サーバー３０３により
用いられる方法は、次のことを含む。図３に示されたよ
うに、モニタ１０４が属するノード２０３上で作動する
すべてのフォルト・トレラント・プロセス１０３（局所
的フォルト・トレラント・プロセス（図３では、ＬＦＴ
ＰＳ））は、状態サーバー３０３の子供である。したが
って、そららのプロセス１０３のうちのひとつが停止し
た場合、状態サーバー３０３は、その子供のひとつが停
止したことを示すＵＮＩＸオペレーティングシステムか
らのＳＩＧＣＨＩＬＤ信号を受ける。

【００４４】状態サーバー３０３は、さらに、ＵＮＩＸ
オペレーティングシステム・メカニズムを用いることに
より、フォルト・トレラント・プロセス１０３がハング
アップしたか否かを積極的に決定する。別のプロセスの
特定されたポートがメッセージを受け入れることができ
ないときにビジービットをセットし、そのビジービット
が取り除かれたときにメッセージを送るプロセスを遮断
する。状態サーバー３０３は、プロセスにメッセージを
送り、その後、時間的間隔（時間的間隔の終わりは、モ
ニタ３０１からのメッセージにより示される）をウエイ
トする。ビジービットがその時間的間隔の間に取り除か
れない場合は、状態サーバー３０３は、プロセス１０３
がハングアップしたことを決定する。最後に、状態サー
バー３０３は、ｌｉｂｆｔ１１３により供給されるハー
トビート機能を実行するときは常に、プロセスがモニタ
３０１に送るメッセージをウエイトすることにより、フ
ォルト・トレラント・プロセス１０３がハングアップし
たか否かを決定することができる。その機能に送られた
メッセージは、プロセス１０３からの次のメッセージが
到着する前に、超えられてはならない間隔を特定し、状
態サーバー３０１が特定された間隔が尽きる時間までに
次のメッセージを受け取らなかった場合、状態サーバー
３０３は、プロセス１０３がハングアップしたことを決
定する。また、そのタイミングは、モニタ３０１により
実行される。

【００４５】好ましい実施例においては、モニタ３０１
と状態サーバー３０３のどちらかが、局所的フォルト・
トレラント・プロセス１０３がハングアップまたはクラ
ッシュしたことを決定した場合、状態サーバー３０３
は、ＵＮＩＸオペレーティングシステムのＦＯＲＫシス
テムコールを用いることによってプロセス１０３を再始
動させて、クラッシュしたまたはハングアップしたプロ
セスと同様のコードを実行する新たなプロセスを作り出
し、クラッシュしたまたはハングアップしたプロセス１
０３のために存在するするクリティカル・メモリ・コピ
ー１２５および／またはログファイル１２７を用いる
（矢印１３５）。再始動されたプロセス１０３が再度ク
ラッシュまたはハングアップした場合、状態サーバー３
０３は、ウオッチング・デーモン１０４にメッセージを
送り、ウオッチング・デーモン１０４のノード内のプロ
セス１０３を再始動すべきであることを示してもよい。
もちろん、再始動されるべきプロセス１０３がクリティ
カル・メモリ・コピー１０５および／またはログファイ
ル１２７を有する場合、コピーおよびログファイルは、
ウオッチング・デーモン１０４のノードにコピーされた
はずである。

【００４６】デーモン１０４が属するノード２０３がダ
ウンし、オペレーションを回復している場合、状態サー
バー３０３は、ノード２０３がダウンしたことを示す他
のデーモン１０４のすべてに対してメッセージを送り、
同時に、状態サーバー３０３は、別のノード２０３上に
コピーを有するフォルト・トレラント・プロセス１０４
が状態サーバー３０３のノード内で再始動されるときは
常に他のデーモンのすべてにメッセージを送る。加え
て、プロセス１０３のクリティカル・メモリ・コピー１
２５またはログファイル１２７のコピーが、モニタ１０
３が属するノードを監視するノード２０３に送られる必
要があるときは常に、状態サーバー３０３は、ウオッチ
ング・ノード内のデーモン１０４にコピーされるべきデ
ータを含むメッセージを送る。好ましい実施例では、状
態サーバー３０３は、次の追加の機能を有する。 ●フォルト・トレラント・プロセス１０３により援用さ
れるあるｌｉｂｆｔ機能に応答する（矢印３０７）； ●モニタ３０１から（矢印３０５）、他のデーモン１０
４から（矢印３１１）、および、局所的フォルト・トレ
ラント・プロセス１０３から（矢印３０７）のメッセー
ジに応じてテーブル１３９、１４１、２０５および２０
７を保持する； ●局所的フォルト・トレラント・プロセス１０３と、。
他のノード２０３のためのそのようなコピーを提供し他
のノード２０３のためのコピーを受け取ることによりバ
ックアップノードとして（矢印３１３）ノードが機能す
るところのフォルト・トレラント・プロセス１０３との
プロセス状態コピー３１５を保持する。これらの機能の
ほとんどは、フォルト・トレラント・プロセス・テーブ
ル１３９と、フォルト・トレラント・プロセス・グルー
プ・テーブル１４１と、ノードリスト２０５と、ステー
タス・テーブル２０７とを含む。好ましい実施例では、
これらのテーブルのすべては、ファイル内に保持され
る。以下、これらのテーブルを詳しく考える。

【００４７】リスト２０７、１３９、および１４１の詳
細：図４図４は、これらのテーブルのうち３つ：ノードリスト２
０７とフォルト・トレラント・プロセス１３９とフォル
ト・トレラント・プロセス・グループ１４１とを示す。
ノードリスト２０７について始めると、システム２０１
におけるノード２０３はそれぞれ、リスト２０７内に単
独のノードリスト・エントリ４０１を有し、ノードのエ
ントリはそれぞれ、単にノード２０３の名称４０３を含
む。リスト２０７の順番は、リング２１１の形状を決定
し、すなわち、リスト２０７内のエントリ４０３（ｊ）
を伴う与えられたノードのためのデーモン１０４は、エ
ントリ４０３（ｊー１）を伴うノード２０３を監視し、
エントリ４０３（０）を伴うノード２０３のためのデー
モンは、エントリ４０３（ｎ）を伴うノード２０３を監
視する。

【００４８】状態サーバー３０３は、監視しているノー
ド２０３がダウンしたことを検出するか、または、ノー
ド２０３がダウンしたことを示す別のデーモン１０４か
らのメッセージを受け取るとき、状態サーバー３０３
は、ノードリスト２０５からノードのためのエントリを
取り除き、この取り除きがモニタ３０１が監視すべきノ
ード２０３に影響を及ぼす場合、状態サーバー３０３
は、そのノードの監視を開始する。状態サーバー３０３
は、デーモン１０４が走行しているところのノード２０
３がシステム２０１に再度加わっていることを示すデー
モン１０４からのメッセージを受けるとき、要求された
ようにノードリスト２０５をアップデートし、アップデ
ートにより必要とされる場合、異なるノード２０３の監
視を開始する。前述の説明より明白なように、システム
２０１内のノード２０３それぞれは、ノードリスト２０
５と等しいコピーを有する。

【００４９】フォルト・トレラント・プロセス・テーブ
ル１３９で引き続くと、デーモン１０４が属するノード
上で現在有効であるもしくは有効となるであろうフォル
ト・トレラント・プロセス１０３はそれぞれ、テーブル
１３９内にエントリ（ＦＴＰＥ）４０５を有する。エン
トリはそれぞれ、プロセス１０３についての次の情報を
含む： ●フォルト・トレラント・プロセスの名称４０７；好ま
しい実施例では、これは、プロセスによって実行される
プログラムのためのパスネームである。 ●プロセス１０３がクラッシュもしくはハングアップし
たか否かを決定するためモニタ３０１がメッセージをお
くるべきポートのポート番号４０９； ●ノード２０３が終了（up）の場合、プロセス１０３が
走行すべきところのノード２０３の最初のノードの名称
４１１； ●プロセス１０３のためのクリティカル・メモリ・コピ
ー１２５とログファイル１２７とを含むファイルのリス
ト、クリティカル・ファイル４１３；および、状態サー
バー３０３がプロセス１０３がハングアップしたという
結論に達する前に待つべき最大時間であるタイムリミッ
ト（ＴＬ）４１５。

【００５０】フォルト・トレラント・プロセス・エント
リ４０５内には、２つの情報源がある。その最初のノー
ドがテーブル１３９が属するノードであるプロセス１０
３のエントリ４０５の場合、情報は、プロセス１０３と
デーモン１０４を有するいかなるクリティカル・メモリ
・コピーおよび／またはログファイル１２７とを登録す
るｌｉｂｆｔ内の機能により提供される。このような場
合、最初のノード４１１は、テーブル１３９が属するノ
ードの名称を含む。その最初のノード２０３が他の所に
あるプロセス１０３のエントリ４０５の場合は、状態サ
ーバー３０３が最初のノード２０３内にエントリを作る
場合、最初のノードをバックアップするためのひとつ以
上のノード２０３内にｗａｔｃｈｄデーモン１０４にエ
ントリの内容を送り、関連したノード２０３内の状態サ
ーバー３０３がそれらのフォルト・トレラント・プロセ
ス・テーブル１３９へその情報を加える。特定されたひ
とつのバックアップノードが存在する場合は、そのｗａ
ｔｃｈｄデーモン１０４が最初のノードを監視するノー
ドとなり、また、複数のバックアップノードが存在する
場合は、そのデーモン１０４が第１のバックアップノー
ドなどを監視するノードとなる。

【００５１】フォルト・トレラント・グループ・テーブ
ル１４１について述べると、エントリ４１７はそれぞ
れ、フォルト・トレラント・プロセス４２１の名称と、
そのフォルト・トレラント・プロセスが属するグループ
を示すグループ番号４１９とを含む。あるグループに属
するあるプロセス１０３が再始動されなければならない
場合、そのグループのすべてのプロセス１０３は同時に
再始動される。テーブル１４１の情報源は、テーブル１
３９の情報源と同じであり、局所的フォルト・トレラン
ト・プロセス１０３の場合、情報は、ｌｉｂｆｔ機能に
より得られ、他のノードからコピーされたものについ
て、その情報は、バックアップされているノードごとに
デーモン１０４により得られる。フォルト・トレラント
・プロセス・テーブル１３９およびフォルト・トレラン
ト・グループ・テーブル１４１の内容から明らかなよう
に、異なる非局所的フォルト・トレラント・プロセスに
ついての情報が状態サーバープロセス３０３が属するノ
ード２０３に格納されるべき方法で、システム２０１か
らのノード２０３の除去またはシステムへのそのような
ノードの再設置がリング２１１を変更するごとに状態サ
ーバーデーモン３０３はそれらのテーブルをアップデー
トする。好ましい実施例では、状態サーバープロセス３
０３がリング２１１の変更を知らされるとき、状態サー
バープロセス３０３は、ノードリスト２０５をアップデ
ートし、リング２１１の新しい形状が与えられるとテー
ブル１３９および１４１にコピーされるべき情報を含む
ノード２０３にメッセージを中継ぎして伝える。テーブ
ル１３９および１４１の内容は、もちろん、与えられた
ノードで走行する局所的フォルト・トレラント・プロセ
ス１０３と与えられたノードのリング２１１内の位置と
によって、ノード２０３へのノード２０３とは相違す
る。

【００５２】ステータス・テーブル２０７の詳細：図５前述したように、システム２０１内のすべてのノード
は、ステータス・テーブル２０７と同じコピーを有す
る。システム２０１で走行するすべてのフォルト・トレ
ラント・プロセス１０３のためのステータス・テーブル
２０７内にエントリが存在する。各エントリは、次のフ
ィールドを含む： ●フィールド５０３には、プロセスの名称が含まれてい
る； ●フィールド５０５には、プロセスが現在実行している
ところのノード２０３の名称が含まれている； ●フィールド５０７には、現在のノード上のプロセスと
連通するために用いられるポート番号が含まれている； ●フィールド５０９には、現在のノード上のプロセスの
ためのプロセス識別子が含まれている； ●フィールド５１１には、信号の詳細が含まれている。
この信号は、好ましい実施例が実施されるＵＮＩＸオペ
レーティングシステムが、プロセスを終了することによ
りこの信号に応答するものである； ●フィールド５１３は、プロセスのためのクリティカル
・ファイルのリストである。

【００５３】上記テーブル内の情報は、次の方法により
得られる：ノード２０３が（新しいノードであるためや
回復オペレーションであるために）システムに加えられ
た場合、状態サーバー３０３は、すでに走行中のノード
２０３からステータス・テーブル２０７のコピーのため
問うメッセージを送る。コピーが戻った場合、状態サー
バー３０３は、テーブルからそれのステータス・テーブ
ル２０７を作る。すでに述べたように、どのノード上の
状態サーバー３０３がフォルト・トレラント・プロセス
１０３を始動または再始動する時はいつも、すべての他
のデーモン１０４にメッセージを送る。そのメッセージ
は、プロセス名と、プロセスを始動しているノードの名
称と、ポート番号と、プロセスＩＤと、クリティカル・
ファイルのリストとを特定する。与えられたノード２０
３内の状態サーバー３０３がメッセージを受けたとき、
ステータス・テーブル２０７内のプロセスのためのエン
トリを作る。ステータス・テーブル２０７内のプロセス
のための別のエントリが存在する場合は、状態サーバー
３０３は、そのエントリを削除する。状態サーバー３０
３はまた、メッセージで特定されたプロセス１０３を現
在走行させているか否かを決定する。プロセス１０３の
ためのフォルト・トレラント・プロセス・テーブルエン
トリ４０５が存在し、そのエントリが別のノード１０３
を最初のノード４１１として示す場合、状態サーバー３
０３は、プロセスの局所的実行を終了する。この手段に
より、２つの結果が得られる：まず、システム２０１内
のステータス・テーブル２０７のすべてのコピーが終始
一貫され、次に、フォルト・トレラント・プロセス１０
３が、最初のノードが停止またはいずれにせよプロセス
を走行できない限り、常にその最初のノード２０３で走
行するようになる。

【００５４】テーブル１３９、１４１、２０５および２
０７の腐敗（Corruption）防止好ましい実施例では、状態サーバー３０３がテーブルを
照会するごとに、腐敗のために得るデータをチェック
し、腐敗の証拠が見つかった場合は、状態サーバー３０
３は、別のノード２０３からステータス・テーブル２０
５およびノードリストの新しいコピーを取り出し、それ
らのテーブルからすべてのテーブル１３９、１４１、２
０５および２０７のすべてを再構築する。同様に、状態
サーバー３０３がテーブルをアップデートまたは置換す
るときはいつも、テーブルをアップデートまたは置換
し、その後腐敗のチェックをする。もし何かが見つかっ
た場合は、テーブルの新しいコピーが取り出され、上述
したように作られる。フォルト・トレラント・システム１０１および２０１の
オペレーションフォルト・トレラント・システム１０１および２０１
は、好ましい実施例ではＵＮＩＸオペレーティングシス
テムのシェルプロセスによって実行されるコマンドによ
り、またｌｉｂｆｔ１１３ルーチンにより制御される。
システム１０１および２０１のオペレーションがコマン
ドおよびｌｉｂｆｔルーチンの説明によって以下に開示
される。

【００５５】ｗａｔｃｈｄデーモン１０４のためのコマ
ンドノード上のｗａｔｃｈｄデーモン１０４を始動させるた
めに、ｗａｔｃｈｄ［ｎ］を用いる。ここでｎ（複製の度合）は、デーモン１０４
が走行するところのノード２０３上を走行するプロセス
の状態コピー３１５を有するノード２０３の合計数であ
る。複製の省略時の度合は２である。このｎが大きくな
ればなるほど、プロセスは頑丈となる。たとえば、ｎが
２の場合、プロセスは、２つのノードが同時に故障した
場合、回復不能となる。一方、ｎが２の場合、２つのノ
ードが同時に故障した場合についても常に回復可能であ
る。しかしながら、ｎが大きくなればなるほど、オペレ
ーションのチェックポイントのための諸経費がかかる。
長い寿命と短い停止時間をともなう実際上のシステムに
おいては、システムの有用性の点で、複製の度合は２が
最適である。Ｙ．ＨｕａｎｇおよびＰ．Ｊａｌｏｔｅ
「最初のサイトアプローチの反応時間分析におけるフォ
ルト・トレランスの効果（Effect of Fault tolerance
on Response Time-Analysis of Primary Site Approac
h）」コンピュータに関するＩＥＥＥ会報４１（４）：
４２０−４２８、１９９２年４月、参照。

【００５６】ノードから他のノードへフォルト・トレラ
ント・プロセスを移動するために、ｍｏｖｅｐｒｏｃ
〈ｐｒｏｃ〉〈ｎｏｄｅ〉を用いる。ここにおける、
〈ｎｏｄｅ〉は宛先ノードである。なお、ステータス・
テーブル２０７から見つけることができるのでソースノ
ードは必要ない。このコマンドの目的は、ロードの釣り
合いである。より軽くロードされたノードにプロセスが
移動させられるようにし、プロセスの反応時間を改善す
る。もちろん、プロセスが移動させられた場合、フォル
ト・トレラント・プロセス・テーブル１３９および関連
するノード内のフォルト・トレラント・グループ・テー
ブル１４１は、したがってアップデートされ、移動され
たプロセスは、新しいノード内で実行し始めた場合、シ
ステム内のステータス・テーブル２０７は、以前記述し
たようにアップデートされる。

【００５７】システム内のフォルト・トレラント・プロ
セスをオンラインで加えるまたは削除するために、ａｄ
ｄｗａｔｃｈ〈ｎａｍｅｏｒｐｉｄ〉〈ｐａｔｈ〉
〈ｐｏｒｔ〉〈ｎｏｄｅ〉〈ｔｉｍｅ〉［〈ｆｉｌｅ
ｓ〉］ｄｅｌｗａｔｃｈ〈ｎａｍｅ〉を用いる。ここに
おける〈ｎｏｄｅ〉はプロセスが〈ｎａｍｅ〉が走行し
ている最初のノードである。〈ｎｏｄｅ〉は、局所的機
械名のためのキーワードである、ノードのシステム名ま
たは名称ｌｏｃａｌである。〈ｐｏｒｔ〉は、プロセス
が使用しているソケットポート番号である（ソケットが
なければ０）。〈ｐａｔｈ〉は、プロセス〈ｎａｍｅ〉
または〈ｐｉｄ〉のバイナリを見つけることのできる全
経路を意味する。この情報は、論点（argument）〈ｆｉ
ｌｅｓ〉がプロセス状態コピー３１５を含むファイルの
リストである場合に必要とされる。たとえば、プロセス
ｙｄは、マシンｇｒｙｐｈｏｎ上で走行している。ｗａ
ｔｃｈｄデーモンにプロセスを監視させるために、ａｄ
ｄｗａｔｃｈｙｄ／ｕｓｒ／ｌｏｃａｌ／ｂｉｎ／ｙ
ｄ０ｇｒｙｐｈｏｎ０また、これらのコマンドの実行は、テーブル１３９、１
４１および２０７に変更をもたらす。システム内のノー
ドをオンラインで追加または削除するために、ａｄｄｎｏｄｅ〈ｎｏｄｅ〉ｄｅｌｎｏｄｅ〈ｎｏｄｅ〉これらのコマンドに応じて、すべてのデーモン１０４
は、それらのノードリスト２０５を変更し、リング２１
１の形状に直接影響を受けるこれらデーモンは、プロセ
ス状態コピー３１５を移動し、フォルト・トレラント・
プロセス・テーブル１３９およびフォルト・トレラント
・グループ・テーブル１４１を形状により要求されたよ
うに変更する。ノード２０３の削除の場合は、そのノー
ド上を走行するプロセス１０３のためのエントリをステ
ータスリスト２０７から取り除く。

【００５８】ｗａｔｃｈｄデーモン１０４を管理するた
めのｌｉｂｆｔ機能ｌｉｂｆｔ１１３は、ｗａｔｃｈｄデーモン１０４を管
理するための数多くの機能を含む。それらには、デーモ
ン１０４を有するプロセス１０３を登録するための機能
と、プロセス１０３からデーモン１０４に心拍信号（he
artbeat signal）を提供する機能と、プロセス状態コピ
ー３１５を操作する機能とがある。デーモン１０４を有するプロセス１０３を登録機能ｒｅｇｗａｔｃｈは、デーモン１０４を有するプロ
セス１０３を登録する。登録後、デーモン１０４は、監
視するプロセス１０３を始動させる。＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝ｉｎｔｒｅｇｗａｔｃｈ（ｐｒｏｃ，ｐｏｒｔ，ｔｉｍｅ）ｃｈａｒ＊ｐｒｏｃ；ｉｎｔｐｏｒｔ；ｉｎｔｔｉｍｅ；＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

【００５９】この機能は、３つのパラメータ：プロセス
名であるｐｒｏｃと、プロセスがプロセッサ間連絡のた
めに用いるポート番号であるｐｏｒｔと、最大タイムア
ウトを規定するためのｔｉｍｅとを取る。この機能の実
行により、これらのパラメータを用いる状態サーバー３
０３にメッセージを送って、フォルト・トレラント・プ
ロセス１３９内およびプロセス１０３のためのステータ
ス・テーブル２０７内にエントリを作り、他のデーモン
１０４にメッセージを送ることにより、それらのデーモ
ンは、それらのステータス・テーブル２０７をアップデ
ートすることができる。パラメータは、プロセス１０３
のためのフォルト・トレラント・プロセス・リスト・エ
ントリ４０５内のフィールド４０７、４０９および４１
５のために用いられる。ｗａｔｃｈｄデーモンには、プ
ロセス１０３がハングアップしたか否かを検出する必要
がない場合、ｔｉｍｅ＝０とすることができる。心拍信
号をｗａｔｃｈｄデーモンに送る

【００６０】前述したように、状態サーバー３０３は、
プロセス１０３から「心拍」信号を聞くことができる。
そのような信号は、ｌｉｂｆｔ機能ｈｂｅａｔ（）によ
り生成される。機能ｈｂｅａｔ（）は、論点として整数
値を取る。この値は、状態サーバー３０３がプロセス３
０３からの心拍信号を待つべき最大間隔を特定する。状
態サーバー３０３がその間隔内で心拍信号を受け取らな
かった場合は、状態サーバー３０３は、プロセスがハン
グアップしていると考え、それを再始動させる。

【００６１】更新のインプリメンテーションの詳細：図
９および図１０好ましい実施例における更新のインプリメンテーション
は、アプリケーションを現在実行しているプロセスを終
了させることと、次のプロセス上でアプリケーションの
実行を再始動させることにより、アプリケーションのた
めの真新しい内部状態を生成する。これを行うために
は、インプリメンテーションは、ｗａｔｃｈｄデーモン
１０４と、ＵＮＩＸオペレーティングシステムのほとん
どにあるｃｒｏｎデーモンとを使用する。Ｓｔｅｐｈｅ
ｎＧ．Ｋｏｃｈａｎ氏およびＰａｔｒｉｃｋＨ．Ｗ
ｏｏｄ氏による「ＵＮＩＸシステムの研究（Exploring
theUNIX System ）」ＨａｙｄｅｎＢｏｏｋｓ、インデ
ィアナポリス、１９８７年、２７７〜２７８ページまた
はＵＮＩＸオペレーティングシステムの書類の一部であ
るｍａｎページにおいて詳しく述べられているように、
ｃｒｏｎは、ユーザーにより決められた時間にユーザー
のためにシェルスクリプトを行う。その実行は、一度で
もまたは繰り返されてもよい。

【００６２】図１０は、インプリメンテーションの外観
図である。デーモン１０４を用いるアプリケーションを
更新するには（図１参照）、どのプロセスが更新を実行
されるか、どのようにして又いつ更新が行われるかを特
定するためにａｄｄｒｅｊｕｖシェルを用いる。ａｄｄ
ｒｅｊｕｖは、複数のプロセス１００３のためのシェル
により実行される。この実行の結果、プロセス１００３
は、プロセス間の連絡（ＩＰＣ）、ａｄｄｒｅｊｕｖメ
ッセージ１００５をｗａｔｃｈｄデーモンのプロセスの
うちのひとつに送る。好ましい実施例では、メッセージ
を受け取るプロセスは状態サーバー３０３である。ｗａ
ｔｃｈｄデーモン１０４は、スクリプトがｃｒｏｎデー
モン１００７に実行されるべき時間とともにシェルスク
リプトを提供する。ｃｒｏｎデーモン１００７がシェル
スクリプトを実行するとき、終了信号１００９をアプリ
ケーションプロセス１０１１に送信する。アプリケーシ
ョンプロセス１０１１も終了信号１００９もシェルスク
リプト９０１で特定されている。上述のｗａｔｃｈｄデ
ーモンの説明で詳しく述べたように、アプリケーション
プロセス１０１１は、状態サーバープロセス３０３の子
供であり、ゆえに、状態サーバー３０３は、アプリケー
ションプロセス１０１１が終了したときにＳＩＧＣＨＬ
Ｄ信号１０１３を受信する。状態サーバー３０３は、監
視しているプロセスがアプリケーションを新たなプロセ
ス１０１１’を生み出すことにより停止および再始動し
た時に行う通りに反応する。新たなプロセス１０１１が
アプリケーションを実行し始めたとき、ｗａｔｃｈｄお
よびｌｉｂｆｔの説明で前述したようにセーブしたクリ
ティカルメモリを用い、ログされたメッセージを消費す
る。

【００６３】さらに詳しくは、ａｄｄｒｅｊｕｖ１００
２のシンタックスは、ａｄｄｒｅｊｕｖ＜ａｐｐ＿ｎａ
ｍｅ＞＜ｃｍｄ｜ｓｉｇｎａｌ：［ｅｌａｐｓｅｄｔｉ
ｍｅ］＞＜ｓｉｇｎａｌ：［ｅｌａｓｅｄｔｉｍｅ］＞
＜ｔｉｍｅ＞である。＜ａｐｐ＿ｎａｍｅ＞は、更新を
実行されるアプリケーションの名称である。＜ｃｍｄ｜
ｓｉｇｎａｌ＞は、アプリケーションを現在実行してい
るプロセスを終了するために用いるコマンドまたはオペ
レーティングシステム信号番号である。このコマンド
は、１プロセスまたはプロセスのグループを停止できる
シェルスクリプトと成りうる。コマンド名の代わりに整
数が得られる場合、その整数は、信号番号として考えら
れ、ｗａｔｃｈｄは、更新の時にプロセスに信号を送
る。［ｅｌａｓｅｄｔｉｍｅ］パラメータは、特定され
た信号が送られる時間と、次の信号が送られる時間との
間を経過する時間を特定する任意のパラメータである。
好ましい実施例では、省略時の経過時間は、１５秒であ
る。第３の論点は、＜ｓｉｇｎａｌ＞である。この信号
は、第１の＜ｃｍｄ｜ｓｉｇｎａｌ＞が実行されたの
ち、プロセス［ｅｌａｓｅｄｔｉｍｅ］に送信される。
この遅れは、このアプリケーションのプロセスがその状
態を真新しくし、終了するよう力が加えられる前にそれ
自身で終了することを許容する。もちろん、ｌｉｂｆｔ
ルーチンは、アプリケーションが再始動されるときに必
要となるであろう状態を確保するために用いられる。プ
ロセスが確実に終了されるために、ＳＩＧＫＩＬＬ信号
が、第２の信号＜ｓｉｇｎａｌ＞がプロセスに送信され
たあとにプロセス［ｅｌａｓｅｄｔｉｍｅ］に送信され
る。＜ｔｉｍｅ＞は、更新が行われる時間である。この
時間は、独立的に特定されても、または現在の時刻に関
連して特定されてもよい。＜ｔｉｍｅ＞のシンタックス
は、ＵＮＩＸオペレーティングシステムのａｔシェルコ
マンドに用いられたタイムフィールドとまったく同じで
ある。

【００６４】ａｄｄｒｅｊｕｖの使用例は、次の通り：
ａｄｄｒｅｊｕｖａａ１５：３０３：２０ｎｏ
ｗ＋１ｍｉｎｕｔｅこれは、ａａと名付けられたアプリケーションを現在実
行するプロセスに信号１５（ＳＩＧＴＥＲＭ）が送信さ
れることを特定しており、この信号は、それを受信する
プロセスが終了することを示すものであり、３０秒後
に、信号３（ＳＩＧＱＵＩＴ）が送られ、この信号は、
プロセスが中止および停止することを示すものであり、
また２０秒後に信号９（ＳＩＧＫＩＬＬ）が送られ、こ
の信号は、プロセスがプロセス自身で終了しなかった場
合にプロセスを停止する。最後の論点ｎｏｗ＋１ｍｉ
ｎｕｔｅは、第１の信号がａａを現在実行しているプロ
セスに今から１分で送られることを示す。ａｄｄｒｅｊ
ｕｖにより送信されたＩＰＣを受信すると、デーモン１
０４は、フォルト・トレラント・プロセス・テーブル１
３９をチェックし、ａｄｄｒｅｊｕｖコマンドで特定さ
れたアプリケーションのためのエントリ４０５が存在す
るか否かを確認し、もし存在した場合は、エントリ４０
５のフィールド４０７内にａａが現われる。エントリ４
０５がない場合は、デーモン１０４は、単に、ａｄｄｒ
ｅｊｕｖを実行したプロセスに対する事実を示すメッセ
ージを送り返す、また他の実施例では、デーモン１０４
が特定されたプロセスをフォルト・トレラント・プロセ
ス・テーブル１０３に加えてもよい。そのようなエント
リ４０５が存在する場合、デーモン１０４は、ａｄｄｒ
ｅｊｕｖおよびエントリ４０５のための論点における情
報を使用し、ａｄｄｒｅｊｕｖコマンドで特定されたア
プリケーションを現在実行しているプロセスをどのよう
に又いつ終了させるかを特定するシェルスクリプト９０
１を構築する。

【００６５】図９は、そのようなシェルスクリプト９０
１の一例である。スクリプト９０１がシェルによって実
行された場合、９０３でラベル付けされたスクリプトの
第１の２つのラインは、シェルにより使用されるプリン
タへ引用符（引用文）および日付により示されたメッセ
ージを出力する。次のライン９０４は、更新が行われて
いることを示すｗａｔｃｈｄ状態サーバープロセス３０
３（プロセス識別子（ＰＩＤ）２６０４で示されてい
る）に信号を送信する。状態サーバープロセス３０３
は、終了されたプロセスに応答し始める前にある時間間
隔待つことにより信号に応答する。この待ち（ウエイ
ト）は、共に終了されなければならないグループ内のす
べてのプロセスがｗａｔｃｈｄデーモン１０４がアプリ
ケーションの実行を再始動し始める前に終了されること
を保証する。次のライン９０５は、ａｄｄｒｅｊｕｖの
第２の論点で特定されたＳＩＧＴＥＲＭ信号をアプリケ
ーションａａを現在実行しているプロセスに送信する。
ここで、そのプロセスは、プロセス識別子（ＰＩＤ）２
６１３を有しており、これは、ｗａｔｃｈｄデーモン１
０４がアプリケーションａａのためにステータス・テー
ブル２０７内のステータス・テーブル・エントリ５０１
内のフィールド５０９から得るものである。次のライン
９０７は、シェルスクリプト９０１を実行するプロセス
に第２の論点で特定された時間である３０秒間休止させ
る。そして、ライン９１１では、第３の論点で特定され
たように、信号３はプロセス２６１３に送信される。ラ
イン９１３では、シェルスクリプト９０１を実行するプ
ロセスがまた、第３の論点で特定された２０秒間休止す
る。その後、再度、ＳＩＧＫＩＬＬ信号９をプロセス２
６１３に送信し、実際に停止したことを確認する。そし
て、シェルスクリプト９０１を実行するプロセスにより
さらに１５秒の休止が存在する。次に、ａｄｄｒｅｊｕ
ｖコマンドは、上述した論点とともに実行される。第４
の論点で特定された次の更新のための時間は、オリジナ
ルのａｄｄｒｅｊｕｖコマンドに特定されているのと同
じである。最後に、メッセージは、更新が終了したこと
を示してプリントされる。

【００６６】ａｄｄｒｅｊｕｖコマンドは、シェルスク
リプト９０１に含まれているので、ｗａｔｃｈデーモン
１０４は、プロセス１０１１’上のアプリケーションを
再始動させるだけでなく、ｃｒｏｎデーモン１１０７か
らのａｄｄｒｅｊｕｖメッセージ１００５’を受信し、
ｗａｔｃｈｄデーモンがプロセス１０１１’を特定する
スクリプト９０１’（図示せず）を供給することにより
上述したようにｃｒｏｎデーモン１１０７に応答し、ｃ
ｒｏｎデーモン１１０７は、上述したようにスクリプト
９０１’を実行する。このメカニズムの結果、ａｄｄｒ
ｅｊｕｖコマンドで特定されたアプリケーションは、定
期的に更新される。例えのスクリプト９０１は、１分走
行したあとアプリケーションａａを更新するようにす
る。どのアプリケーションにも利用可能となるような方
法でアプリケーション更新を実施するのにｗａｔｃｈデ
ーモン１０４を使用することには利点が数多くある。ま
ず、ｗａｔｃｈデーモン１０４がユーザープロセスを作
り上げ、そのようにしてハードウエアまたはオペレーテ
ィングシステムを修正することなく、いかなるシステム
上でも走行することができるということである。さら
に、アプリケーションがｌｉｂｆｔライブラリ・ルーチ
ンを使用する場合、更新されたプロセスに求められる真
新しい内部状態の種類が、正確に画定される。

【００６７】しかしながら、他のインプリメンテーショ
ンも可能である。一般的に、更新は、アプリケーション
の実行が「真新しい」内部状態で再始動されるようにす
る技法によって成し遂げられてもよい。たとえば、更新
は、アプリケーションを実行しているプロセスを一時停
止し、プロセスの現在の内部状態を真新しい内部状態と
取り替え、プロセスを復活させることにより成し遂げら
れる。さらに、コンピュータシステム上で実行するアプ
リケーションに一般的に利用可能な更新を行う別の方法
がある。たとえば、オペレーティングシステムは、ＵＮ
ＩＸオペレーティングシステムが現在ｃｏｒｎを提供す
るのと同様のやり方で更新のユーティリティを提供する
こともできる。そのようなアプリケーションでは、ａｄ
ｄｒｅｊｕｖに応答された何であっても、更新を実行さ
れるアプリケーションの更新ユーティリティに知らせ、
そのユーティリティは、更新を行う。そのようなアプリ
ケーションは、更新システムの構成要素間の連絡に、プ
ロセス間連絡やシェルスクリプト以外の方法を用いても
よい。

【００６８】結論上述の詳細な説明は、アプリケーションの故障の可能性
を減らすためにいかにして更新が用いられ、与えられた
アプリケーションが更新により利益を得るかどうかをい
かにして決定するかを、ソフトウエア・フォルト・トレ
ランスにおける当業者に開示した。この詳細な説明は、
さらに、本特許出願の親出願で開示されたソフトウエア
・フォルトレランスを提供するためのシステムが、いか
にして、どのアプリケーションにも利用可能な更新を行
うように用いられるかをも開示した。上記で指摘したよ
うに、他の方法がそのような有用性を提供するために用
いられることも可能であり、また、他のインプリメンテ
ーションが親出願のシステム内で可能であることは、当
業者であれば容易に理解できるであろう。上述のすべて
において、詳細な説明は、すべて具体的かつ例証的およ
び非限定的なものとしてみなされるべきものであり、こ
こで開示された発明の範囲は、特許法により許される最
大範囲を持つものとして添付の特許請求の範囲によって
のみ決定されるべきものである。

【００６９】

【発明の効果】以上の説明から明らかな通り、本発明に
よれば、新たなプロセスによって実行されるよう、現在
アプリケーションを実行しているプロセスを停止し、そ
のアプリケーションを再始動させることにより、アプリ
ケーションを更新させることができ、また本発明による
更新は、どんなアプリケーションにも適用できる。

【図面の簡単な説明】

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

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

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

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

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

【図６】更新を行う場合と行わない場合のアプリケーシ
ョンの信頼性を示す説明図である。

【図７】更新が行われていないアプリケーションの状態
遷移図である。

【図８】更新が行われているアプリケーションの状態遷
移図である。

【図９】好ましい実施例で採用されるシェルスクリプト
の説明図である。

【図１０】好ましい実施例の処理を示す説明図である。

【符号の説明】

１０１システム１０３フォルト・トレラント・プロセス１０４ｗａｔｃｈｄデーモン１０５揮発性メモリ（ＶＭＥＭ）１１１フォルト・トレラント・アプリケーション（Ｆ
ＴＡ）コード１１３ｌｉｂｆｔコード１１３１１５クリティカルメモリ（ＣＲＭＥＭ）１２３持続性メモリ１２７ログファイル１３９フォルト・トレラント・プロセス（ＦＴＰ）リ
スト２０３ノード２０７ステータス・テーブル

───────────────────────────────────────────────────── フロントページの続き (72)発明者エンナンファンアメリカ合衆国 08807 ニュージャーシィ，ブリッジウォーター，リンバーガードライヴ 33 (72)発明者チャンドラモハンラオキンタルアメリカ合衆国 07059 ニュージャーシィ，ウォーレン，マウンテンアヴェニュー 29 (72)発明者ニコラスジョンコレティスアメリカ合衆国 08520 ニュージャーシィ，ハイツタウン，ガーデンヴューテラスナンバー18 51

Claims

【特許請求の範囲】

【請求項１】コンピュータシステム内で実行するアプ
リケーションの故障の発生を減少させるための装置にお
いて、コンピュータシステム内で実行されているプロセスに一
般的に使用可能であり、アプリケーションのうちのひと
つのアプリケーションが更新を行われるべきであること
を示す更新表示を提供するための手段と、更新表示に応答するコンピュータシステム内の手段で、
アプリケーションの実行を停止し、実行を停止する前の
アプリケーションの内部状態とは異なる内部状態で実行
を再開することによりアプリケーションを更新する手段
とからなることを特徴とする装置。
【請求項２】前記更新表示は、アプリケーションが更
新を行われるべき時間を示す時間表示を含み、前記更新表示に応答する手段は、前記時間表示により示
された時間にアプリケーションの実行の停止を開始する
ことを特徴とする請求項１に記載の装置。
【請求項３】前記更新表示に応答する手段は、アプリ
ケーションを定期的に更新することを特徴とする請求項
１に記載の装置。
【請求項４】前記更新表示は、ある時間の間隔を示す
時間表示を含み、前記更新表示に応答する手段は、前記
時間表示により特定された時間の間隔を用いてアプリケ
ーションを定期的に更新することを特徴とする請求項１
に記載の装置。
【請求項５】前記装置は、アプリケーションにより使
用可能で、前記異なる内部状態を特定するための手段を
さらに有し、前記更新表示に応答する手段は、特定された内部状態で
実行を再開することを特徴とする請求項１に記載の装
置。
【請求項６】前記更新表示は、ひとつ又はそれ以上の
オペレーションを示すコマンドを含み、前記更新表示に応答する手段は、アプリケーションの実
行を停止するときオペレーションを実行することを特徴
とする請求項１に記載の装置。
【請求項７】前記更新表示は、どのように実行が停止
されるかを示した停止方法表示を含み、前記更新表示に応答する手段は、まず、前記停止方法表
示により特定されたように実行を停止し、そのうえに、
実行を完全に停止することを特徴とする請求項１に記載
の装置。
【請求項８】前記コンピュータシステムは、アプリケ
ーションを実行するための複数のプロセスを供給する手
段を含み、アプリケーションは、第１のプロセスで実行しており、アプリケーションを更新する手段は、第１のプロセスを
終了し、第２のプロセスで実行を再始動させることによ
り更新を行うことを特徴とする請求項１に記載の装置。
【請求項９】アプリケーションを更新する手段は、終了表示を提供し、前記第１のプロセスの終了を検知す
ると、前記第２のプロセスで実行を再始動させることに
よりそれに応答することにより更新表示に応答する第３
のプロセスと、前記第１のプロセスを終了することにより前記終了表示
に応答する第４のプロセスとを有することを特徴とする
請求項８に記載の装置。
【請求項１０】前記装置は、アプリケーションにより
使用可能で、前記異なる内部状態を特定するための手段
を有し、前記第３のプロセスは、特定された異なる内部状態を用
いて前記第２のプロセスで実行を再始動させることを特
徴とする請求項９に記載の装置。
【請求項１１】前記第３のプロセスは、ハングアップ
および／またはクラッシュしたプロセスを再始動するた
めのデーモン・プロセスであり、前記第４のプロセスは、特定された時間でオペレーショ
ン指定で特定されたオペレーションを実行するためのオ
ペレーティング・システム・ユーティリティであり、前記第４のプロセスに前記特定された時間を提供し、さ
らに、オペレーション指定として終了指定を提供するこ
とを特徴とする請求項１０に記載の装置。
【請求項１２】前記異なる内部状態を特定するための
手段は、アプリケーションに使用可能なそのライブラリ
内のルーチンであることを特徴とする請求項１０に記載
の装置。
【請求項１３】前記更新表示は、ひとつ又はそれ以上
のオペレーションを表示するコマンドを含み、前記第３のプロセスは、前記終了表示内のコマンドを含
み、前記第４のプロセスは、前記第１のプロセスを終了する
とき、前記コマンドにより表示されるオペレーションを
実行することを特徴とする請求項９に記載の装置。
【請求項１４】前記更新表示は、どのように実行が終
了されるかを示した終了方法表示を含み、前記第３のプロセスは、前記終了表示内に前記終了方法
表示を含み、前記第４のプロセスは、まず、終了方法表示により特定
されたように実行を終了し、そのうえに、完全に実行を
終了することを特徴とする請求項９に記載の装置。
【請求項１５】前記更新表示は、アプリケーションが
更新を行われるべき時間を示す時間表示を含み、前記第３のプロセスは、前記終了表示内に時間表示によ
り示される時間を含み、前記第４のプロセスは、前記終了表示に示された時間で
終了表示に応答を開始することを特徴とする請求項９に
記載の装置。
【請求項１６】前記更新表示内の前記時間表示は、時
間の間隔を示し、前記第４のプロセスは、前記終了表示に示された時間の
間隔で、終了表示に定期的に応答することを特徴とする
請求項１５に記載の装置。
【請求項１７】前記時間表示は、更新表示が提供され
る時間に関する時間を示し、前記第３のプロセスは、終了表示における更新表示を含
み、前記第４のプロセスは、前記第１のプロセスの実行を終
了したあと、更新表示を提供し、これによりアプリケーションは、定期的に更新が行われ
ることを特徴とする請求項１５に記載の装置。
【請求項１８】コンピュータシステム内で実行される
方法であり、コンピュータシステム内で実行するアプリ
ケーションの故障の発生を減少させる方法において、前記コンピュータシステム上で実行するいかなるプロセ
スにおいて、アプリケーションが実行されるべきことを
示すコンピュータシステム内の更新表示を提供する工程
と、アプリケーションの実行を停止し、実行の停止前のアプ
リケーションの内部状態とは異なる内部状態で実行を再
開することにより前記更新表示に応答してアプリケーシ
ョンを更新する工程とからなることを特徴とする方法。
【請求項１９】前記コンピュータシステムは、アプリ
ケーションを実行するための複数のプロセスを提供し、アプリケーションを更新する工程は、アプリケーションが実行する第１のプロセスを終了する
工程と、第２のプロセスで実行を再始動させる工程とを含むこと
を特徴とする請求項１８に記載の方法。
【請求項２０】前記方法は、第３のプロセスにおいて、終了表示を提供することによ
り前記更新表示に応答する工程と、第４のプロセスにおいて、前記第１のプロセスを終了す
る工程を実行することによって終了表示に応答する工程
と、前記第３のプロセスにおいて、前記第１のプロセスの終
了を検出し、前記第２のプロセスで実行を再始動させる
工程を実行することによりそれに応答する工程とをさら
に有することを特徴とする請求項１８に記載の方法。