JPH08110895A - 分散システムに使用されるノード装置及び記憶装置並びに分散システムにおける資源管理用サーバの復旧方法 - Google Patents

分散システムに使用されるノード装置及び記憶装置並びに分散システムにおける資源管理用サーバの復旧方法

Info

Publication number
JPH08110895A
JPH08110895A JP7048902A JP4890295A JPH08110895A JP H08110895 A JPH08110895 A JP H08110895A JP 7048902 A JP7048902 A JP 7048902A JP 4890295 A JP4890295 A JP 4890295A JP H08110895 A JPH08110895 A JP H08110895A
Authority
JP
Japan
Prior art keywords
server
client
information
distributed system
token
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
JP7048902A
Other languages
English (en)
Other versions
JP3504763B2 (ja
Inventor
Takeo Murakami
岳生 村上
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Fujitsu Ltd
Original Assignee
Fujitsu Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Fujitsu Ltd filed Critical Fujitsu Ltd
Priority to JP04890295A priority Critical patent/JP3504763B2/ja
Priority to US08/518,395 priority patent/US5845082A/en
Publication of JPH08110895A publication Critical patent/JPH08110895A/ja
Application granted granted Critical
Publication of JP3504763B2 publication Critical patent/JP3504763B2/ja
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
    • G06F11/202—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant
    • G06F11/2046—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant where the redundant components share persistent storage
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
    • G06F11/202—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant
    • G06F11/2023—Failover techniques
    • G06F11/2028—Failover techniques eliminating a faulty processor or activating a spare
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
    • G06F11/202—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant
    • G06F11/2035—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant without idle spare hardware
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
    • G06F11/2097—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements maintaining the standby controller/processing unit updated

Abstract

(57)【要約】 【目的】 本発明は、サーバの負荷が軽減できるととも
にサーバのメモリ領域が有効に活用できる、分散システ
ムに使用されるノード装置及び記憶装置並びに分散シス
テムにおける資源管理用サーバの復旧方法を提供するこ
とを目的とする。 【構成】 クライアントＣ１〜Ｃ３及び資源管理用サー
バＳの両方または一方を有する複数のノード装置２〜４
をそなえるとともに、チェックポイントを記憶する記憶
装置５をそなえ、ノード装置２〜４と記憶装置５とがネ
ットワーク６を介して接続された分散システム１に使用
され、少なくともクライアントを有するノード装置２〜
４において、ノード装置４のクラッシュ時に、サーバＳ
がクライアントＣ１〜Ｃ３を介し資源に関する情報を収
集して、復旧を行なえるように、通常運用時に、クライ
アントＣ１〜Ｃ３側で資源に関するチェックポイントを
取って、このチェックポイントを記憶装置５に記憶させ
る手段を設けるように構成する。

Description

【発明の詳細な説明】
【０００１】（目次） 産業上の利用分野 従来の技術 発明が解決しようとする課題 課題を解決するための手段及び作用 実施例 （Ａ）第１実施例の説明（図１〜図１６） （Ｂ）第２実施例の説明（図１７〜図３３） 発明の効果
【０００２】
【産業上の利用分野】本発明は、分散システム及び同分
散システムにおける資源管理用サーバの復旧方法に関す
る。近年、ビジネス分野において高性能かつ高信頼な計
算機システムが要求されており、複数のプロセッサをそ
なえた、並列・分散型の計算機システムの普及が進んで
いる。
【０００３】そして、この並列・分散システムでは、一
部のプロセッサが故障しても残りのプロセッサで処理を
継続することが可能であるが、利用者からはこの故障を
隠蔽するようにソフトウェアを構築する必要がある。
【０００４】
【従来の技術】従来の並列・分散システムにおいては、
同一のサービスを提供するプロセスを２つの異なるノー
ド上に用意し、一方を現用プロセス、もう一方を待機プ
ロセスとする手法（切替え及び引継ぎ方式）が広く用い
られている。そして、この並列・分散システムでは、現
用プロセスが稼働しているプロセッサ（以下、現用サー
バという）が故障した場合に、待機プロセスを実行する
プロセッサ（以下、待機サーバという）がサービスを引
き継ぎ、サービスの利用者からノードの故障を隠蔽する
ことで、システムの信頼性を向上させることができる。
【０００５】また、分散システム上で複数のノード上の
プロセスがサーバ・クライアントモデルに基づいて動作
するソフトウェアシステムにおいて、現用サーバが稼働
しているノードが故障した場合、現用サーバがクライア
ントに渡した資源が、プロセスの引継ぎ後も使用可能な
様に、待機サーバが資源管理情報を再構築して、サーバ
の引継ぎを行なう。
【０００６】このため、この分散システムでは、通常運
用時に、現用サーバがクライアントに対して資源を発行
する毎にその内容（以下、チェックポイントという）を
安定記憶（不揮発性の記憶装置）に記録しておき、現用
サーバのクラッシュ（故障）によるプロセスの引継ぎ時
に、待機サーバが、この安定記憶に記録されているチェ
ックポイントを読み出して資源管理情報を再構築するこ
とで、サーバの復旧を行なうようになっている。
【０００７】また、従来の分散システムでは、資源を複
数のノードで共用するために、トークン（あるいは、ロ
ック）と呼ばれる機構が広く用いられている。ここで、
このトークンとは、複数のクライアントがサーバの資源
を同時に使用することを防ぐために、資源を使用できる
クライアントを限定する使用権のようなものである。つ
まり、クライアントがサーバの管理する資源を使用した
い場合、クライアントは、まず、このトークンの獲得を
要求し、このトークンの獲得に成功するとサーバの管理
しているファイルなどの資源を使用して仕事を行ない、
その後、資源の使用が終わった時点でクライアントがサ
ーバへトークンを返却することにより、サーバの管理す
る同じ資源を複数のクライアントが同時に使用すること
を防ぐようになっているのである。
【０００８】
【発明が解決しようとする課題】しかしながら、このよ
うな従来の並列・分散システムでは、サーバがクライア
ントに対して資源を発行する毎に、そのチェックポイン
トを安定記憶に記録するので、安定記憶へデータを書き
込むコストが主記憶に比べて大きくなり、システムの通
常運用時の性能が低下するという課題がある。
【０００９】また、現用サーバと同時に一部のクライア
ントもノードのクラッシュによって機能しなくなった場
合、待機サーバはクラッシュしたクライアントのみが使
用していた資源も再構築するため、故障によるサーバの
引継ぎ後に、待機サーバが無駄なメモリ領域を確保して
メモリを浪費してしまうという課題もある。さらに、ト
ークンを獲得して所有しているクライアントが、サーバ
と同時にクラッシュしてしまった場合や、サーバ／クラ
イアント間でトークンの授受を行なっている最中に、シ
ステムの一部（ノード）がクラッシュした場合には、こ
のトークンが失われてしまい、この結果、システムがク
ラッシュから復旧してもトークンに対応したサーバの管
理する資源が使用できなくなるという課題がある。
【００１０】また、ノードがクラッシュする直前までト
ークンを所有することによりサーバの管理する資源を使
用していたクライアントの処理結果がサーバに反映され
ず、ノードがクラッシュする前後において、サーバの管
理する資源の情報に矛盾が生じてしまうという課題もあ
る。本発明は、このような課題に鑑み創案されたもの
で、サーバ・クライアントモデルに基づいて動作する分
散システムにおいて、通常運用時には、サーバが取得す
るチェックポイントを削減することでサーバの負荷を軽
減し、故障による現用サーバから待機用サーバへの引継
ぎ時には、必要な資源情報のみ待機用サーバにより構築
することでサーバのメモリ領域を有効に活用できるよう
にした、分散システムに使用されるノード装置及び記憶
装置並びに分散システムにおける資源管理用サーバの復
旧方法を提供することを目的とする。
【００１１】また、サーバの引継ぎ時にクライアントか
らトークンに関する情報を収集することによって、ノー
ドのクラッシュなどによるトークンの紛失を検出し、サ
ーバの引継ぎによる復旧後もサーバの管理するトークン
に対応した資源情報の一貫性を保つことができるように
した、分散システムに使用されるノード装置及び記憶装
置並びに分散システムにおける資源管理用サーバの復旧
方法を提供することを目的とする。
【００１２】
【課題を解決するための手段】このため、本発明の分散
システムに使用されるノード装置及び分散システムにお
ける資源管理用サーバの復旧方法では、まず、分散シス
テムが、クライアント及び資源管理用サーバの両方また
は一方を有するノード装置を複数そなえるとともに、資
源管理情報をもったチェックポイントを記憶する記憶装
置をそなえ、これら複数のノード装置と前記の記憶装置
とがネットワークを介して接続されて構成され、上記の
クライアント及びサーバがサーバ・クライアントモデル
に基づいて動作するようになっている。
【００１３】そして、この分散システムに使用されるノ
ード装置に関しては、上記複数のノード装置のいずれか
のノード装置のクラッシュ時に、分散システムに存在す
るサーバ同じく分散システムに存在するクライアントを
介し資源に関する情報を収集して、復旧を行なえるよう
に、通常運用時に、上記のノード装置に設けられたクラ
イアント側で資源に関するチェックポイントを取って、
このチェックポイントを記憶装置に記憶させる手段が設
けられる（以上、請求項１，１４）。
【００１４】従って、本発明の分散システムに使用され
る記憶装置には、上述の複数のノード装置のいずれかの
ノード装置のクラッシュ時に、分散システムに存在する
サーバが同じく分散システムに存在するクライアントを
介し資源に関する情報を収集して、復旧を行なえるよう
に、通常運用時に、クライアント側で取られた資源に関
するチェックポイントを受け取って、このチェックポイ
ントを記憶するチェックポイント記憶手段が設けられる
（請求項１２）。
【００１５】また、本発明の分散システムに使用される
ノード装置及び分散システムにおける資源管理用サーバ
の復旧方法では、まず、分散システムが、クライアント
及び資源管理用サーバの両方または一方を有するノード
装置を複数そなえるとともに、資源管理情報をもったチ
ェックポイントを記憶する記憶装置をそなえ、且つ、該
資源管理用サーバに関し、現用と待機用とが異なったノ
ード装置に分散して設けられ、更にこれら複数のノード
装置と上述の記憶装置とがネットワークを介して接続さ
れて構成されており、上記のクライアント及びサーバが
サーバ・クライアントモデルに基づいて動作するように
なっている。
【００１６】そして、この分散システムに使用されるノ
ード装置に関しては、現用のサーバが存在するノード装
置のクラッシュ時に、他のノードに存在する待機用のサ
ーバが、クライアントにサーバが管理している資源に関
する情報を問い合わせることにより、情報を収集し、こ
の収集した情報に基づいて待機用サーバの内部状態を再
構築して、サーバの復旧を行なえるように、通常運用時
に、ノード装置に設けられたクライアント側で資源に関
するチェックポイントを取って、このチェックポイント
を記憶装置に記憶させる手段が設けられる（以上、請求
項２，１５）。
【００１７】さらに、本発明の分散システムに使用され
るノード装置及び分散システムにおける資源管理用サー
バの復旧方法では、分散システムが、クライアント及び
資源管理用サーバの両方または一方を有するノードを複
数そなえるとともに、資源管理情報をもったチェックポ
イントを記憶する記憶装置をそなえ、且つ、該クライア
ント及び該資源管理用サーバのそれぞれに関し、現用と
待機用とが異なったノードに分散して設けられ、更に該
複数のノードと該記憶装置とがネットワークを介して接
続されて構成されており、上記のクライアント及びサー
バがサーバ・クライアントモデルに基づいて動作するよ
うになっている。
【００１８】そして、この分散システムに使用されるノ
ード装置に関しては、待機用のクライアントを他のノー
ドにもったクライアント及び現用のサーバが存在するノ
ードのクラッシュ時に、分散システムに存在する待機用
のクライアントが記憶装置からクラッシュしたノード装
置に存在したクライアントに関するチェックポイントを
読み込んで、サーバの資源に関する状態を復旧した時点
で、その旨を待機用のサーバに通知し、待機用のサーバ
側では、復旧中のクライアントから復旧した旨の通知を
受けると、待機用のサーバが、分散システムに存在する
クライアントにサーバが管理している資源に関する情報
を問い合わせることにより、情報を収集し、この収集し
た情報に基づいて待機用のサーバの内部状態を再構築し
て、サーバの復旧を行なえるように、通常運用時に、ノ
ード装置に設けられたクライアント側で資源に関するチ
ェックポイントを取って、このチェックポイントを記憶
装置に記憶させる手段が設けられる（以上、請求項３，
１６）。
【００１９】また、本発明の分散システムに使用される
ノード装置及び分散システムにおける資源管理用サーバ
の復旧方法では、サーバによる復旧中は、クライアント
同士でサーバが管理している資源に関する情報の受渡し
を禁止する手段を設けてもよく（請求項４，１７）、サ
ーバクラッシュ毎に更新されるインカーネーション番号
をクライアント間での情報の受渡し時に同時に送信する
手段を設けてもよい（請求項５，１８）。
【００２０】さらに、本発明の分散システムに使用され
るノード装置及び分散システムにおける資源管理用サー
バの復旧方法では、クライアント及び資源管理用サーバ
の両方または一方を有するノード装置を複数そなえると
ともに、資源管理情報をもったチェックポイントを記憶
する記憶装置をそなえ、これら複数のノード装置と前記
の記憶装置とがネットワークを介して接続され、上記の
クライアント及びサーバがサーバ・クライアントモデル
に基づいて動作するようになっている。
【００２１】ここで、分散システムに使用されるノード
装置には、上述の複数のノード装置のいずれかのノード
装置のクラッシュ時に、分散システムに存在するサーバ
が同じく分散システムに存在するクライアントを介しサ
ーバ側で管理する資源の使用を該クライアントに許可す
るためのトークンに関する情報を収集し、この収集した
トークンに関する情報に基づいてサーバ側で自己が管理
するトークンの情報を再構築して、復旧を行なえるよう
に、通常運用時に、ノード装置に設けられたクライアン
ト側でこのトークンに関するチェックポイントを取る手
段が設けられる（以上、請求項６，１９）。
【００２２】また、本発明の分散システムに使用される
ノード装置及び分散システムにおける資源管理用サーバ
の復旧方法では、クライアント及び資源管理用サーバの
両方または一方を有するノードを複数そなえるととも
に、資源管理情報をもったチェックポイントを記憶する
記憶装置をそなえ、且つ、この資源管理用サーバに関
し、現用と待機用とが異なったノードに分散して設けら
れ、更にこれら複数のノードと前記の記憶装置とがネッ
トワークを介して接続され、上記のクライアント及びサ
ーバがサーバ・クライアントモデルに基づいて動作する
ようになっている。
【００２３】そして、この場合、この分散システムに使
用されるノード装置には、現用のサーバが存在するノー
ドのクラッシュ時に、他のノードに存在する待機用のサ
ーバが、サーバ側で管理している資源の使用を分散シス
テムに存在するクライアントに許可するためのトークン
を所有しているクライアントのみに該トークンに関する
情報を問い合わせることにより、情報を収集し、この収
集したトークンに関する情報に基づいて待機用のサーバ
の内部状態を再構築して、サーバの復旧を行なえるよう
に、通常運用時に、ノード装置に設けられたクライアン
ト側でトークンに関するチェックポイントを取ることに
より、このトークンを所有しているクライアントのリス
トを記憶装置に記憶させる手段が設けられる（以上、請
求項７，１８）。
【００２４】従って、本発明の分散システムに使用され
る記憶装置には、現用のサーバが存在するノードのクラ
ッシュ時に、他のノードに存在する待機用のサーバが、
サーバ側で管理している資源の使用を分散システムに存
在するクライアントに許可するためのトークンを所有し
ているクライアントのみに該トークンに関する情報を問
い合わせることにより、情報を収集し、この収集したト
ークンに関する情報に基づいて待機用のサーバの内部状
態を再構築して、サーバの復旧を行なえるように、通常
運用時に、クライアント側でトークンに関するチェック
ポイントを取ることにより得られるトークンを所有して
いるクライアントのリストを受け取って、クライアント
のリストを記憶するクライアントリスト記憶手段が設け
られる（請求項１３）。
【００２５】ここで、上述の分散システムに使用される
ノード装置には、サーバによる復旧の際、サーバがトー
クンを所有し、且つ、クラッシュしていないクライアン
トのみに、記憶装置に記憶されたクライアントのリスト
を基にトークンを所有しているクライアントがクラッシ
ュしているか否かを判定する故障管理用サーバを設ける
こともできる（請求項８，２１）。
【００２６】さらに、上述の分散システムに使用される
ノード装置には、通常運用時に行なう処理とは別に、サ
ーバからのトークンに関する情報の問い合わせに応答す
るための専用の処理を行なう手段を設けることもできる
（請求項９，２２）。また、上述の分散システムに使用
されるノード装置には、サーバによる復旧の際、トーク
ンに関する情報をクライアントに問い合わせたのち、所
定の時間が経過してもこのクライアントからこの問い合
わせに対する応答がなくトークンに関する情報を収集す
ることができない場合に応答のあったクライアントのみ
からトークンに関する情報を収集するように、所定の時
間を設定するタイマ手段を設けることもできる（請求項
１０，２３）。
【００２７】さらに、上述の分散システムに使用される
ノード装置には、サーバによる復旧の際、サーバが、自
己が管理するトークンに対応する資源情報を最新の資源
情報に更新するように、サーバ側で管理する資源に関す
る情報と、過去にトークンを所有することによりこの資
源を使用していたクライアント側で管理する資源に関す
る情報との新旧を比較する手段を設けることもできる
（請求項１１，２４）。
【００２８】
【作用】上述の構成により、本発明の分散システム及び
同分散システムにおける資源管理用サーバの復旧方法で
は、通常運用時に、サーバ側で自己が管理する資源に関
するチェックポイントを取る代わりに、クライアント側
で資源に関するチェックポイントを取ることにより、チ
ェックポイントを該記憶装置に記憶しておき、その後、
ノード装置のクラッシュ時に、サーバがクライアントを
介し資源に関する情報を収集して、復旧を行なう（請求
項１，１２，１４）。
【００２９】また、資源管理用サーバに関し、現用と待
機用とが異なったノードに分散して設けられている場合
は、通常運用時に、現用のサーバ側で自己が管理する資
源に関するチェックポイントを取る代わりに、クライア
ント側で資源に関するチェックポイントを取ることによ
り、このチェックポイントを記憶装置に記憶しておき、
その後、現用のサーバが存在するノード装置のクラッシ
ュ時に、他のノード装置に存在する待機用のサーバが、
クライアントにサーバが管理している資源に関する情報
を問い合わせることにより、情報を収集し、この収集し
た情報に基づいて待機用サーバの内部状態を再構築し
て、サーバの復旧を行なう（請求項２，１５）。
【００３０】さらに、本発明の分散システム及び同分散
システムにおける資源管理用サーバの復旧方法では、通
常運用時に、現用のサーバ側で自己が管理する資源に関
するチェックポイントを取る代わりに、クライアント側
で資源に関するチェックポイントを取ることにより、チ
ェックポイントを該記憶装置に記憶しておき、その後、
待機用のクライアントを他のノードにもったクライアン
ト及び現用のサーバが存在するノードのクラッシュ時に
は、まず、待機用のクライアントが記憶装置からクラッ
シュしたノードに存在したクライアントに関するチェッ
クポイントを読み込む。
【００３１】そして、サーバの資源に関する状態を復旧
した時点で、その旨を待機用のサーバに通知し、つい
で、待機用のサーバ側では、復旧中のクライアントから
復旧した旨の通知を受けると、待機用のサーバが、クラ
イアントにサーバが管理している資源に関する情報を問
い合わせることにより、情報を収集し、この収集した情
報に基づいて待機用サーバの内部状態を再構築して、サ
ーバの復旧を行なう（以上、請求項３，１６）。
【００３２】なお、上述のような、サーバによる復旧中
は、クライアント同士でサーバが管理している資源に関
する情報の受渡しを禁止して、サーバの復旧中に資源の
内容が変更されないようにしており（請求項４，１
７）、さらに、サーバクラッシュ毎に更新されるインカ
ーネーション番号をクライアント間での情報の受渡し時
に同時に送信することによっても、サーバクラッシュ前
にクライアント間で授受されようとしていたインカーネ
ーション番号の更新されていない資源に関する情報を検
出して、サーバの復旧中に資源の内容が変更されないよ
うにしている（請求項５，１８）。
【００３３】さらに、本発明の分散システムにおける資
源管理用サーバの復旧方法では、通常運用時に、サーバ
側で自己が管理する資源の使用を分散システムに存在す
るクライアントに許可するためのトークンに関するチェ
ックポイントを取る代わりに、クライアント側でトーク
ンに関するチェックポイントを取っておき、その後、ノ
ード装置のクラッシュ時に、サーバがクライアントから
トークンに関する情報を収集し、この収集した情報に基
づいてサーバ側で自己が管理するトークンの情報を再構
築して、復旧を行なう（請求項６，１３，１９）。
【００３４】また、資源管理用サーバに関し、現用と待
機用とが異なったノードに分散して設けられる場合は、
上述と同様に、通常運用時に、トークンを所有している
クライアントのリストを記憶装置に記憶しておき、その
後、現用のサーバが存在するノード装置のクラッシュ時
に、他のノード装置に存在する待機用のサーバが、記憶
装置に記憶されたトークンを所有しているクライアント
のリストに基づき、トークンを所有しているクライアン
トのみに、このトークンに関する情報を問い合わせるこ
とにより、情報を収集し、この収集した情報に基づいて
待機用サーバ側で自己が管理するトークンの情報を再構
築して、サーバの復旧を行なう（請求項７，２０）。
【００３５】さらに、このとき、資源管理用サーバが存
在するノード装置と異なるノード装置に故障管理用のサ
ーバを設ければ、資源管理用サーバが存在するノード装
置のクラッシュ時に、故障管理用のサーバが、記憶装置
に記憶されたトークンを所有しているクライアントのリ
ストを読み込み、トークンを所有しているクライアント
がクラッシュしているか否かを判定し、この判定に基づ
いて待機用のサーバが、トークンを所有し、且つ、クラ
ッシュしていないクライアントのみに、トークンに関す
る情報を問い合わせることができる（請求項８，２
１）。
【００３６】また、上述のような、サーバによる復旧の
際、サーバからのトークンに関する情報の問い合わせを
受けたクライアントは、通常運用時に行なう処理とは別
に、この問い合わせに応答するための専用の処理を行な
うこともできる（請求項９，２２）。さらに、このよう
なサーバによる復旧の際、クライアントにトークンに関
する情報を問い合わせた後、所定の時間を経過してもク
ライアントからこの問い合わせに対する応答がなくトー
クンに関する情報を収集することができない場合には、
応答があったクライアントのみからトークンに関する情
報を収集する（請求項１０，２３）。
【００３７】また、サーバによる復旧の際、トークンを
所有しているクライアントにトークンに関する情報を問
い合わせることにより情報を収集した後は、サーバ側で
のトークンに対応する資源に関する情報と、過去にトー
クンを所有することによりサーバ側で管理する資源を使
用していたクライアント側でのこの資源に関する情報と
の新旧を比較し、この比較結果に基づいて、サーバ側で
管理するトークンに対応する資源に関する情報を、最新
の情報に更新する（請求項１１，２４）。
【００３８】
【実施例】以下、本発明の実施例について、図面を参照
しながら説明する。 （Ａ）第１実施例の説明 （Ａ−１）第１実施例の基本的な説明 図１は本発明の第１実施例の基本説明にかかる分散シス
テムの構成を示すブロック図であり、この図１におい
て、１は分散システム、２，３及び４はいずれもノード
（ノード装置）、５は安定記憶（不揮発性の記憶装
置）、６はネットワークである。さらに、ノード２の内
部には、クライアントＣ１が設けられており、ノード３
の内部には、クライアントＣ２及びクライアントＣ３が
設けられている。また、ノード４の内部には、サーバＳ
が設けられている。
【００３９】そして、この図１に示すように、この分散
システム１は、クライアントＣ１を有するノード２と、
クライアントＣ２，Ｃ３を有するノード３、及び資源管
理用サーバとしてのサーバＳを有するノード４をそなえ
るとともに、ファイルなどの資源に関する情報の内容
（チェックポイント）を記憶する安定記憶５をそなえ、
さらに、これらのノード２，ノード３及びノード４と安
定記憶５とがネットワーク６を介して接続され、各クラ
イアントＣ１，Ｃ２，Ｃ３及びサーバＳは、サーバ・ク
ライアントモデルに基づいて動作するようになってい
る。
【００４０】そして、この分散システム１では、通常運
用時に、サーバＳ側で自己が管理する資源に関するチェ
ックポイントを取る代わりに、各クライアントＣ１，Ｃ
２，Ｃ３側でこの資源に関するチェックポイントを取る
ことにより、このチェックポイントを安定記憶５に記憶
しておくことができるようになっている。ここで、上述
の処理について、図２に示すシーケンス図（ステップＡ
１〜Ａ５）を参照しながら、以下に詳述する。なお、ノ
ード２上にはクライアントＣ１のプロセスが、ノード３
上にはクライアントＣ２，Ｃ３のプロセスが、ノード４
上にはサーバＳのプロセスがそれぞれ動作している。
【００４１】まず、各クライアントＣ１，Ｃ２，Ｃ３
は、図１中の実線の矢印で示す経路をとって、サーバＳ
にサーバＳが管理している資源に対する処理要求をネッ
トワーク６を介して送り（ステップＡ１）、この処理要
求を受けたサーバＳでは、自己が管理する資源の操作
（資源の生成あるいは解放など）を行ない（ステップＡ
２）、この処理結果を処理要求を送ってきた各クライア
ントＣ１，Ｃ２，Ｃ３に送り返す（ステップＡ３）。
【００４２】そして、サーバＳからの処理結果を受けた
各クライアントＣ１，Ｃ２，Ｃ３は、この処理結果を記
録し（ステップＡ４）、図１中の点線の矢印で示す経路
をとって、チェックポイントを安定記憶５に送り、安定
記憶５がこのチェックポイントを記憶する（ステップＡ
５）。つまり、上述の分散システム１では、通常運用時
に、サーバＳ側で自己が管理する資源に関するチェック
ポイントを取る代わりに、各クライアントＣ１，Ｃ２，
Ｃ３側でこの資源に関するチェックポイントを取ること
により、このチェックポイントを安定記憶５に記憶して
おくのである。
【００４３】そして、上述のようにチェックポイントを
安定記憶５に記憶させた後に、例えばノード２上にサー
バ（図示略）が存在しているとして、このノード２が故
障（クラッシュ）した場合を考えると、この場合は、ノ
ード４上のサーバＳが、直接安定記憶５に記憶されたチ
ェックポイントを読み込んで資源に関する情報を収集す
るのではなく、クラッシュしたノード２のクライアント
Ｃ１以外のクライアント、すなわちノード３のクライア
ントＣ２あるいはクライアントＣ３を介して資源に関す
る情報を収集して、ノード２上の上記サーバの復旧を行
なう。
【００４４】以上のように、資源管理用のサーバＳのプ
ロセスでは自分が管理する資源に関するチェックポイン
トを取らず、資源を使用するクライアントＣ１，Ｃ２，
Ｃ３側のプロセスでチェックポイントを取るので、多数
のクライアントからの要求を処理する必要のあるサーバ
の負荷を大幅に軽減でき、これによりサーバがクラッシ
ュした場合でもサーバの復旧が高速に行なうことができ
るようになる。
【００４５】また、サーバの負荷を増大させることな
く、フォールトトレラントなシステム（故障が生じても
停止することなく動作を続行することができるシステ
ム）を構築することもできるようになる。次に、図３も
本発明の第１実施例の基本説明にかかる分散システムの
構成を示すブロック図であるが、この図３に示すよう
に、この分散システム１は、図１に示した分散システム
と同様に、クライアントＣ１を有するノード２と、クラ
イアントＣ２，Ｃ３を有するノード３、及びファイルな
どの資源を管理する資源管理用の現用サーバＳｐを有す
るノード４をそなえるとともに、資源管理情報のチェッ
クポイントを記憶する安定記憶（記憶装置）５をそなえ
ており、且つ、現用サーバＳｐの待機用のサーバとして
の待機サーバＳｂが、現用サーバＳｐを有するノード４
と異なるノード２に設けられている。
【００４６】なお、この図３に示す分散システム１にお
いても、ノード２，ノード３及びノード４と安定記憶５
とがネットワーク６を介して接続され、各クライアント
Ｃ１，Ｃ２，Ｃ３及び各サーバＳｐ，Ｓｂがサーバ・ク
ライアントモデルに基づいて動作するようになってい
る。そして、この分散システム１においても、通常運用
時には、図２にて前述した処理（ステップＡ１〜Ａ５）
と同様の処理が行なわれる。
【００４７】すなわち、サーバＳｐが自己が管理する資
源に関するチェックポイントを取る代わりに、各クライ
アントＣ１，Ｃ２，Ｃ３がこの資源に関するチェックポ
イントを取り、このチェックポイントを安定記憶５に記
憶しておく。ここで、上述のように資源に関するチェッ
クポイントを安定記憶５に記憶させた後、現用サーバＳ
ｐが存在するノード４がクラッシュした場合のサーバの
復旧方法について、図４に示すシーケンス図（ステップ
Ｂ１〜Ｂ３）を参照しながら、以下に詳述する。
【００４８】今、この分散システム１において、処理を
行なっている現用サーバＳｐが存在するノード４がクラ
ッシュすると、まず、待機サーバＳｂが、図３中の実線
の矢印で示す経路をとって、自分（待機サーバＳｂ）と
関係のある全てのプロセス（各クライアントＣ１，Ｃ２
及びＣ３上で動作しているプロセス）に対して資源に関
する問い合わせを発行し（ステップＢ１）、この問い合
わせを受けた各クライアントＣ１，Ｃ２及びＣ３では、
それぞれ自己が保持している資源の情報を調べる（ステ
ップＢ２）。
【００４９】そして、各クライアントＣ１，Ｃ２及びＣ
３は、同じく図３中の実線の矢印で示す経路をとって、
各自が保持している資源情報を待機サーバＳｂに送り、
待機サーバＳｂでは、この資源情報を収集して、資源管
理のための内部状態を再構築することにより（ステップ
Ｂ３）、現用サーバＳｐのプロセスを引継いでサーバの
復旧を行なう。
【００５０】つまり、現用サーバＳｐが存在するノード
４のクラッシュ時には、他のノード２に存在する待機サ
ーバＳｂが、各クライアントＣ１，Ｃ２及びＣ３に、資
源に関する情報を問い合わせることにより、情報を収集
し、この収集した情報に基づいて待機サーバＳｂの内部
状態を再構築して、サーバ（現用サーバＳｐ）の復旧を
行なうのである。
【００５１】以上のように、ノード４のクラッシュによ
り現用サーバＳｐが機能しなくなった場合、待機サーバ
Ｓｂが、故障していない各クライアントＣ１，Ｃ２及び
Ｃ３に対して問い合わせを行ない、その問い合わせの結
果に基づいてシステム全体として矛盾がないように待機
サーバＳｂの内部状態を再構築するので、クラッシュし
たノード４上でのみ保持されていた資源に関する情報を
新たに再構築することがなく、これによりサーバの資源
管理用のメモリ領域を大幅に削減することができる。
【００５２】また、通常運用時には、現用サーバＳｐ
は、上述のように、資源に関するチェックポイントを取
る必要がないので、現用サーバＳｐの負荷を軽減させつ
つ現用サーバＳｐのフォールトトレラント化を実現する
ことができ、さらに、現用サーバＳｐから待機サーバＳ
ｂへの処理の引継ぎ時に、待機サーバＳｂが安定記憶５
からチェックポイントを読み出すコストがかからないの
で、システムがノードのクラッシュなどの障害から高速
に回復できる。
【００５３】次に、図５も本発明の第１実施例の基本説
明にかかる分散システムの構成を示すブロック図であ
り、この図５に示す分散システム１においても、ノード
２，ノード３，ノード４と安定記憶５とがネットワーク
６を介して接続されている。そしてノード２の内部に
は、待機サーバＳｂ及びクライアントＣ１が設けられて
おり、ノード３の内部には、待機クライアントＣ２ｂ及
びクライアントＣ３が設けられている。また、ノード４
の内部には、現用サーバＳｐ及び現用クライアントＣ２
ｐが設けられている。
【００５４】ここで、クライアントＣ１，Ｃ３，待機ク
ライアントＣ２ｂ，現用クライアントＣ２ｐ，待機サー
バＳｂ及び現用サーバＳｐは、サーバ・クライアントモ
デルに基づいて動作するようになっており、通常運用時
には、図２にて前述したステップＡ１〜Ａ５と同様の処
理が行なわれる。すなわち、この分散システム１の通常
運用時においても、現用サーバＳｐが自己が管理する資
源に関するチェックポイントを取る代わりに、クライア
ントＣ１Ｃ３及び現用クライアントＣ２ｐが資源に関す
るチェックポイントを取ることにより、このチェックポ
イントを安定記憶５に記憶しておく。
【００５５】そして、上述のように、通常運用時に、資
源に関するチェックポイントを安定記憶５に記憶させて
おいた後、例えば、ノード４がクラッシュした場合、こ
の図５に示す分散システム１では、待機クライアントＣ
２ｂがクラッシュした現用サーバＳｐの資源に関する状
態を復旧し、その旨を待機サーバＳｂに通知してから待
機サーバＳｂが資源情報を収集し、サーバの復旧を行な
う。
【００５６】ここで、上述の処理について、図６に示す
シーケンス図（ステップＤ１〜Ｄ３）を参照しながら、
以下に詳述する。まず、現用サーバＳｐ及び現用クライ
アントＣ２ｐが存在するノード４がクラッシュすると、
待機クライアントＣ２ｂが、図５中の点線の矢印で示す
経路をとって、安定記憶５からクラッシュしたノード４
に存在した現用クライアントＣ２ｐに関するチェックポ
イントを読み込み（ステップＤ１）、クラッシュしたノ
ード４の現用サーバＳｐの資源に関する状態を復旧し、
この復旧が終了した時点で、チェックポイントの読み込
み完了を、図５中の実線で示す経路をとって、待機サー
バＳｂに通知する（ステップＤ２）。
【００５７】そして、待機サーバＳｂは、このチェック
ポイントの読み込み完了通知を受けた時点で、資源情報
の回復処理を開始する（ステップＤ３）。ここで、この
ステップＤ３における資源情報の回復処理は、図４にて
前述したステップＢ１〜Ｂ３と同様の処理が行なわれ
る。すなわち、待機サーバＳｂが、クライアントＣ１，
Ｃ３及び待機クライアントＣ２ｂに、サーバが管理して
いる資源に関する情報を問い合わせることにより、情報
を収集し、この収集した情報に基づいて待機サーバＳｂ
の内部状態を再構築し、以後、待機サーバＳｂが現用サ
ーバＳｐのプロセスを引き継ぐことで、サーバの復旧を
行なう。
【００５８】つまり、この図５に示す分散システム１で
は、待機用のクライアントである待機クライアントＣ２
ｂをもった現用クライアントＣ２ｐ及び現用サーバＳｐ
が存在するノード４のクラッシュ時には、まず、待機ク
ライアントＣ２ｂが安定記憶５からクラッシュしたノー
ド４に存在した現用クライアントＣ２ｐに関するチェッ
クポイントを読み込んで、現用サーバＳｐの資源に関す
る状態を復旧した時点で、その旨を待機サーバＳｂに通
知し、ついで、待機サーバＳｂ側では、復旧中の待機ク
ライアントＣ２ｂから復旧した旨の通知を受けると、待
機サーバＳｂが、クライアントＣ１，Ｃ３及び待機クラ
イアントＣ２ｂにサーバが管理している資源に関する情
報を問い合わせることにより、情報を収集し、この収集
した情報に基づいて待機サーバＳｂの内部状態を再構築
して、サーバの復旧を行なうのである。
【００５９】以上のように、現用サーバＳｐ及び現用ク
ライアントＣ２ｐが存在するノード４がクラッシュした
場合の復旧処理のフェーズ（段階）を、待機クライアン
トＣ２ｂが安定記憶５からチェックポイントを読み込む
フェーズ、待機サーバＳｂと待機クライアントＣ２ｂと
がプロセス間で連携して資源管理情報を再構築するフェ
ーズという２つのフェーズに明確に分けることにより、
資源管理情報を再構築する際に、クライアントＣ１，Ｃ
３及び待機クライアントＣ２ｂに対する問い合わせメッ
セージの遅延時間を削減することができるので、資源管
理用サーバの復旧処理を効率良く行なうことができる。
【００６０】また、図１，図３及び図５にて前述した分
散システム１では、上述のようにサーバＳあるいは待機
サーバＳｂが復旧処理（リカバリ）を行なっている場合
に、クライアントＣ１，Ｃ２，Ｃ３及び待機クライアン
トＣ２ｂ間でサーバの管理している資源に関する情報の
受渡しを行なうことを禁止することができる。この場合
の処理について、図７及び図８に示すシーケンス図（ス
テップＤ１〜Ｄ５）を参照しながら、以下に詳述する。
なお、説明の便宜上、上述のクライアントＣ１，Ｃ２，
Ｃ３、待機クライアントＣ２ｂ及び待機サーバＳｂを、
この場合に限り、単にクライアント及びサーバという。
【００６１】まず、サーバのリカバリが行なわれている
場合、サーバはクライアントに資源情報に関する問い合
わせメッセージを送り（ステップＤ１）、このメッセー
ジを受け取ったクライアントでは、サーバから受け取っ
た資源（資源情報）をロックする（ステップＤ２）。そ
して、クライアントは自分が保持している資源情報の内
容を調べ（ステップＤ３）、資源情報をサーバに送り返
し（ステップＤ４）、サーバではこの資源情報に基づい
て資源管理のための内部状態を再構築し（ステップＤ
５）、サーバのリカバリ処理を終了する（ステップＤ
６）。
【００６２】さらに、サーバはクライアントに対してリ
カバリの終了を通知し（ステップＤ７）、クライアント
では、このリカバリ終了の通知を受け取ると、サーバの
資源をアンロック（解放）し（ステップＤ８）、クライ
アント同士の資源の受渡しを許可する。このように、サ
ーバによるリカバリの際、サーバが資源情報を問い合わ
せた後はクライアント間での資源の受渡しが停止（禁
止）されるため、サーバの問い合わせた情報がサーバの
リカバリ中に変化することはないので、サーバは収集し
た情報に基づいて内部状態を再構築するだけで、分散シ
ステム全体として矛盾のない資源管理情報を再構築する
ことができるようになる。
【００６３】なお、図１，図３及び図５に示した分散シ
ステム１では、上述のように、サーバＳあるいは待機サ
ーバＳｂがクラッシュした場合、サーバのクラッシュ毎
に更新されるインカーネーション (incarnation)番号
が、各クライアントＣ１，Ｃ２，Ｃ３及び待機クライア
ントＣ２ｂの間での資源情報の受渡し時に同時に送信さ
れるようになっており、待機サーバＳｂでは、このイン
カーネーション番号が保持され、ノードのクラッシュに
よるサーバの引継ぎが起こる毎に、このインカーネーシ
ョン番号がインクリメントされ、クライアントＣ１，Ｃ
２でもこのインカーネーション番号が記憶される。
【００６４】そして、図９及び図１０に示すように、ま
ず、待機サーバＳｂは、クライアントＣ１へ資源情報を
問い合わせる際に、このインカーネーション番号“ｉ＋
１”（ｉは０，１，２，・・・）を同時に送信し（ステ
ップＥ１）、クライアントＣ１は、資源の受渡しを行な
うメッセージにこのインカーネーション番号を付加して
待機サーバＳｂに送信する（ステップＥ２）。
【００６５】さらに、待機サーバＳｂは、クライアント
Ｃ２へ資源情報を問い合わせる際にも、インカーネーシ
ョン番号“ｉ＋１”を同時に送信し（ステップＥ３）、
クライアントＣ２は、資源の受渡しを行なうメッセージ
にこのインカーネション番号“ｉ＋１”を付加して待機
サーバＳｂに送信する（ステップＥ４）。さて、ここ
で、ノードのクラッシュが発生して待機サーバＳｂにサ
ーバの引継ぎ（復旧）を行なう以前に、資源情報の受渡
しを要求するメッセージｍ＜ｉ＞がクライアントＣ２に
送信されていた場合、クライアントＣ２は、このメッセ
ージｍ＜ｉ＞を受信すると（ステップＥ５）、自分が記
憶しているインカーネーション番号“ｉ＋１”（図１０
中では＜ｉ２＞）とメッセージｍ＜ｉ＞に付加されたイ
ンカーネーション番号“ｉ”（図１０中では＜ｉ１＞）
とを比較する（ステップＥ６）。
【００６６】そして、この比較の結果、それぞれのイン
カーネーション番号が一致すれば、クライアントＣ２
は、このメッセージｍ＜ｉ＞を正常に受け付けるが、
今、“ｉ＋１”≠“ｉ”（＜ｉ２＞≠＜ｉ１＞）のよう
に、クライアントＣ２が記憶しているインカーネーショ
ン番号とメッセージｍ＜ｉ＞に付加されたインカーネー
ション番号が異なるので、クライアントＣ２はこのメッ
セージｍ＜ｉ＞を破棄する（ステップＥ７）。
【００６７】つまり、サーバの復旧中に、このサーバの
復旧が開始される以前に資源情報の受渡しを要求するメ
ッセージが送信されていた場合に、このメッセージを破
棄することにより、サーバの復旧中にクライアントの資
源情報が変更されてしまうことを防いでいるのである。
このように、資源情報の受渡しを行なうメッセージにイ
ンカーネーション番号を付加することにより、待機サー
バＳｂが、クライアントＣ１あるいはクライアントＣ２
に資源情報を問い合わせた時点で、送信済み、かつ未受
信のメッセージｍ＜ｉ＞を検出することができ、このメ
ッセージを無効にすることで、待機サーバＳｂは、資源
情報の問い合わせ時にクライアントＣ１及びＣ２から収
集した情報のみを基にして、一貫性のある資源管理情報
を構築することができる。
【００６８】（Ａ−２）第１実施例の具体的な説明 図１１は本発明の第１実施例の具体的な説明にかかる分
散システムの構成を示す図であり、この図１１に示すよ
うに、分散システム１は、ノード２〜４の複数のノード
（分散システムに使用されるノード装置）をそなえると
ともに、資源管理情報をもったチェックポイントを記憶
する安定記憶（記憶装置）５をそなえ、さらに、これら
複数のノード２，３，４と安定記憶５とがネットワーク
６を介して接続されている。
【００６９】そして、各ノード２〜４には、図示しない
ＣＰＵ、主記憶、２次記憶が設けられており、ネットワ
ーク６を介して互いに他のノードとアクセスすることが
できるようになっている。また、安定記憶５は、各ノー
ド２〜４からネットワーク６を介してアクセスすること
ができる不揮発性の記憶装置であり、本実施例では、ど
のノードが故障してもその内容は破壊されないものとす
る。なお、この安定記憶５は、ソフトウェア，ハードウ
ェアのどちらでも構成でき、ソフトウェアで構成する場
合はノード２〜４上に置くこともできる。
【００７０】さらに、この分散システム１において、ノ
ード２上には、プロセスマネージャーＰＭ２（クライア
ント）と、現用ファイルマネージャーＦＭｐ（現用のサ
ーバ）、及び現用ストリームマネージャー（現用のクラ
イアント）ＳｔＭｐとが設けられている。また、ノード
３上には、プロセスマネージャー（クライアント）ＰＭ
３及び待機ファイルマネージャー（待機用のサーバ）Ｆ
Ｍｂとが設けられており、ノード４上には、アプリケー
ションプログラムＰ，プロセスマネージャー（クライア
ント）ＰＭ４及び待機ストリームマネージャー（待機用
のクライアント）ＳｔＭｂとが設けられている。
【００７１】そして、各ノード２，３，４上にはオペレ
ーティングシステム（ＯＳ）が動作しており、このＯＳ
は機能毎に分割された複数のプロセスの集合として実現
されている。ここで、各プロセスマネージャーＰＭ２，
ＰＭ３，ＰＭ４は、上述のように各ノード２，３，４に
存在し、ノード４上のアプリケーションプログラムＰか
らの要求を受け付けるものであり、現用ファイルマネー
ジャーＦＭｐ及び待機ファイルマネージャーＦＭｂは、
ファイル管理を行なうものであり、現用ストリームマネ
ージャーＳｔＭｐ及び待機ストリームマネージャーＳｔ
Ｍｂは、ストリームを管理するものである。
【００７２】そして、この分散システム１では、通常運
用時に、図２にて前述したステップＡ１〜Ａ５と同様の
処理が行なわれる。すなわち、サーバである現用ファイ
ルマネージャーＦＭｐで自己が管理する資源に関するチ
ェックポイントを取る代わりに、クライアントである各
プロセスマネージャーＰＭ２，ＰＭ３，ＰＭ４と現用ス
トリームマネージャーＳｔＭｐ及び待機ストリームマネ
ージャーＳｔＭｂでこの資源に関するチェックポイント
を取ることにより、このチェックポイントが安定記憶５
に記憶される。
【００７３】さらに、上述のようにチェックポイントが
安定記憶５に記憶された後、図１２に示すように、例え
ば、ノード２がクラッシュすると、現用ファイルマネー
ジャーＦＭｐが機能しなくなるため、待機ファイルマネ
ージャーＦＭｂが現用ファイルマネージャーＦＭｐのプ
ロセスを引き継いで、サーバである現用ファイルマネー
ジャーＦＭｐのリカバリが行なわれる。
【００７４】ここで、このリカバリ処理について、具体
的に、図１５に示すシーケンス図（ステップＧ１〜ステ
ップＧ１０）を参照しながら、以下に説明する。まず、
ノード２がクラッシュすると、ノード３上の待機ファイ
ルマネージャーＦＭｂと、ノード４上の待機ストリーム
マネージャーＳｔＭｂがプロセスの引継ぎを開始し（ス
テップＧ１）、図１２中の点線で示す経路をとって、そ
れぞれ安定記憶５からチェックポイントを読み込む（ス
テップＧ２）。
【００７５】つまり、安定記憶５からクラッシュしたノ
ード１に存在した現用ファイルマネージャーＦＭｐ及び
現用ストリームマネージャーＳｔＭｐに関するチェック
ポイントを読み込むことで、資源に関する状態を復旧す
る（以下、ここまでのプロセスを前半のフェーズとい
う）。そして、待機ストリームマネージャーＳｔＭｂは
自分のチェックポイントの読み込みが完了すると、その
旨を待機ファイルマネージャーＦＭｂに通知する（ステ
ップＧ３）。
【００７６】一方、待機ファイルマネージャーＦＭｂで
は、自己のチェックポイントの読み込みが終了すると、
待機ストリームマネージャーＳｔＭｂから前半のフェー
ズの完了通知が届くまで、次のプロセスを実行せずにそ
のまま待機する。そして、図１３中の実線で示す経路か
ら、待機ファイルマネージャーＦＭｂが、待機ストリー
ムマネージャーＳｔＭｂから前半のフェーズの完了通知
（チェックポイントの読み込み完了通知）を受けると、
待機ファイルマネージャーＦＭｂは、図１４中の実線で
示す経路をとって、故障していないノード３上のプロセ
スマネージャーＰＭ３，ノード４上のプロセスマネージ
ャーＰＭ４及び待機ストリームマネージャーＳｔＭｂ
（以下、単に各クライアントということがある）に対し
て、自分が管理している資源に関する問い合わせを行う
（ステップＧ４）。
【００７７】そして、待機ファイルマネージャーＦＭｂ
からの問い合わせを受けた、プロセスマネージャーＰＭ
３，プロセスマネージャーＰＭ４及び待機ストリームマ
ネージャーＳｔＭｂは、それぞれ自分が保持している資
源をロックする（ステップＧ５）。すなわち、待機ファ
イルマネージャーＦＭｂによる現用ファイルマネージャ
ーＦＭｐの復旧中は、クライアント同士で待機ファイル
マネージャーＦＭｂが管理している資源に関する情報の
受渡しを禁止するのである。
【００７８】続いて、各クライアントは、自分が保持し
ている資源の内容を調べ（ステップＧ６）、資源情報を
待機ファイルマネージャーＦＭｂに送り返す（ステップ
Ｇ７）。さらに、待機ファイルマネージャーＦＭｂは、
同じく図１４中の実線で示す経路をとって、プロセスマ
ネージャーＰＭ３，プロセスマネージャーＰＭ４及び待
機ストリームマネージャーＳｔＭｂから送られてきた資
源情報を収集し、この情報を基に資源管理情報の再構築
して（ステップＧ８）、現用ファイルマネージャーＦＭ
ｐの復旧を行なう。
【００７９】そして、この処理が終了すると、待機ファ
イルマネージャーＦＭｂは、各クライアントにリカバリ
終了を通知し（ステップＧ９）、このリカバリ終了通知
を受けた各クライアントでは、ステップＧ５でロックし
ていた資源をアンロック（解放）し（ステップＧ１
０）、その後のクライアント間での資源の受渡しを許可
する。
【００８０】これにより、ノード４上のアプリケーショ
ンプログラムＰは、例えば、ファイルなどの資源の使用
中にノード１がクラッシュ（故障）しても、全く影響な
くプログラムの実行を継続することが可能になる。な
お、この図１５に示すシーケンス図には図示していない
が、待機サーバＦＭｂと各クライアントとの間における
資源情報の受渡しでは、本発明の基本的な実施例の説明
において前述したように、資源情報の受渡しメッセージ
にインカーネーション番号を付加して送信することで、
リカバリ処理中に資源の内容が変更されないようにして
いる。
【００８１】また、図１６は、上述の本実施例における
資源が、例えば、ファイルの場合の資源情報（ファイル
テーブル）の具体例を示す図であり、ファイルを利用す
るクライアントでは、現用ファイルマネージャーＦＭｐ
あるいは待機ファイルマネージャーＦＭｂ（いずれもサ
ーバ）からファイルｉｄを受け取ると、この図１６に示
すようなファイルテーブルＦＴにエントリを追加し、そ
の内容が安定記憶５にも記録されるようになっている。
【００８２】以上のように、上述の分散システム１にお
いては、現用のサーバである現用ファイルマネージャー
ＦＭｐの通常運用時のプロセスでは、自分が管理する資
源に関するチェックポイントを取らず、資源を使用する
各クライアント側のプロセスでチェックポイントを取る
ので、多数のクライアントからの要求を処理する必要の
あるサーバの負荷を大幅に軽減でき、これによりサーバ
の負荷を増大させることなく、フォールトトレラントな
システムを構築することができる。
【００８３】また、例えば、ノード２のクラッシュによ
り現用ファイルマネージャーＦＭｐの復旧が必要な場
合、待機ファイルマネージャーＦＭｂが、故障していな
い各クライアントに対して問い合わせを行ない、その問
い合わせの結果に基づいてシステム全体として矛盾がな
いように待機ファイルマネージャーＦＭｂの内部状態を
再構築するので、ノード２がクラッシュしたために機能
しなくなってしまった現用ストリームマネージャーＳｔ
Ｍｐのみが保持していた資源に関する情報を新たに再構
築することがなく、これにより資源管理用のメモリ領域
を大幅に削減することができる。
【００８４】さらに、現用ファイルマネージャーＦＭｐ
及び現用ストリームマネージャーＳｔＭｐが存在するノ
ード２がクラッシュした場合の復旧処理のフェーズを、
待機ファイルマネージャーＦＭｂ及び待機ストリームマ
ネージャーＳｔＭｂが安定記憶５からチェックポイント
を読み込むフェーズ（上述のステップＧ１〜ステップＧ
３に相当する）、待機ファイルマネージャーＦＭｂと各
クライアントとがプロセス間で連携して資源管理情報を
再構築するフェーズ（上述のステップＧ４〜ステップＧ
８に相当する）という２つのフェーズに明確に分けるこ
とにより、資源管理情報を再構築する際に、各クライア
ントに対する問い合わせメッセージの遅延時間を減らす
ことができ、これにより現用ファイルマネージャーＦＭ
ｐ（サーバ）の復旧処理を効率良く行なうことができ
る。
【００８５】また、待機ファイルマネージャーＦＭｂが
資源情報を問い合わせた後は、待機ストリームマネージ
ャーＳｔＭｂが安定記憶５からチェックポイントを読み
込み、チェックポイントの読み込み完了を待機ファイル
マネージャーＦＭｂに通知するまで、資源の受渡しを禁
止するので、待機ファイルマネージャーＦＭｂが問い合
わせた情報が、現用ファイルマネージャーＦＭｐのリカ
バリ中に変更されてしまうことがなく、待機ファイルマ
ネージャーＦＭｂは収集した情報に基づいて分散システ
ム全体として矛盾のない資源管理情報を再構築すること
ができる。
【００８６】従って、現用ファイルマネージャーＦＭｐ
（サーバ）の復旧を、分散システム全体として矛盾なく
行なうことができるようになる。さらに、資源情報の受
渡しを行なうメッセージにインカーネーション番号を付
加することにより、待機ファイルマネージャーＦＭｂ
が、各クライアントに資源情報を問い合わせた時点で、
送信済み、かつ未受信のメッセージを検出することがで
き、このメッセージを無効にすることで、待機ファイル
マネージャーＦＭｂは、資源情報の問い合わせ時に各ク
ライアントから収集した情報のみを基にして、一貫性の
ある資源管理情報を構築することができる。
【００８７】（Ｂ）第２実施例の説明 （Ｂ−１）第２実施例の基本的な説明 図１７は本発明の第２実施例の基本説明にかかる分散シ
ステムにおける動作概念を説明するための図で、この図
１７において、Ｃ１〜Ｃ３はそれぞれ分散システムに使
用されるノード（ノード装置：図示略）に存在するクラ
イアント、Ｓは同じく分散システムに使用されるノード
に存在しファイルなどの資源を管理する資源管理用のサ
ーバである。
【００８８】そして、本実施例でも、第１実施例と同様
に、これらのサーバＳ，クライアントＣ１〜Ｃ３が、サ
ーバ・クライアントモデルに基づいて動作するようにな
っている。なお、ｄ１，ｄ２，・・・，ｄ８，・・はサ
ーバＳ側で管理されるファイルなどの資源の識別情報
（ｉｄ）で、この図１７においては、例えば、サーバＳ
側で管理している資源のうち“ｄ１”，“ｄ２”，“ｄ
３”という“ｉｄ”をもった３つの資源がクライアント
Ｃ１で使用され、同様に、“ｄ４”，“ｄ５”という
“ｉｄ”をもったの２つの資源がクライアントＣ２で使
用され、“ｄ６”，“ｄ８”という“ｉｄ”をもった２
つの資源がクライアントＣ３で使用されることを表して
いる。
【００８９】そして、これらのサーバＳ，各クライアン
トＣ１〜Ｃ３が存在する上述の分散システムでは、通常
運用時に、サーバＳで管理している資源の使用をクライ
アントＣ１〜Ｃ３のいずれかに許可するためのトークン
に関するチェックポイントを、サーバＳ側で取らずに各
クライアントＣ１〜Ｃ３側で取っておく。そして、例え
ば、第１実施例と同様に、それまでプロセスを実行して
いたサーバＳとは異なるサーバが存在するノード（図示
略）がクラッシュしてサーバの機能が停止してしまう
と、本実施例でも、このサーバの復旧がサーバＳによっ
て行なわれる。
【００９０】以下、このサーバＳによる復旧処理につい
て、図１８に示すシーケンス図（ステップＨ１〜ステッ
プＨ４）を参照しながら詳述する。まず、本実施例で
は、例えば、サーバＳがトークンに関する情報（サーバ
Ｓの管理している資源をどのクライアント又はサーバが
使用していたかの情報）の問い合わせを各クライアント
Ｃ１〜Ｃ３に発行し（ステップＨ１）、この問い合わせ
を受けた各クライアントＣ１〜Ｃ３は、各自で保持して
いるトークンに関する情報（以下、トークン情報という
ことがある）を調べる（ステップＨ２）。
【００９１】例えば、クライアントＣ１では、通常運用
時に、トークンに関するチェックポイントを取っておい
たことにより、サーバＳからトークンを受け取る（所有
する）ことにより使用したことのあるファイルなどの資
源情報（ｉｄ：ｄ１〜ｄ３）を持っているので、トーク
ンを所有することによって使用していた資源がどの資源
であったかなどが調べられて、その情報がサーバへ送ら
れる（ステップＨ３）。
【００９２】つまり、各クライアントＣ１，Ｃ２，Ｃ
３，・・・は、サーバＳ側で管理されている資源のうち
のどの資源をどのクライアントが使用していたのかがサ
ーバＳ側で分かるように、トークン情報を調べるのであ
る。そして、サーバＳでは、各クライアントＣ１，Ｃ
２，Ｃ３，・・・から送られてきたトークン情報を収集
して、これを基にトークン情報を再構築し、図１９に示
すようなトークン（ｔｏｋｅｎ）情報テーブルを作成し
てサーバの復旧を終える（ステップＨ４）。なお、この
図１９に示すトークン情報テーブルでは、サーバＳがト
ークンの所有者となっている資源を“ｈ”として表して
いる。また、サーバＳ，クライアントＣ１，Ｃ２，Ｃ３
・・・のいずれも使用していない資源については、基本
的に、サーバＳがトークンの所有者となる。
【００９３】以上のように、分散システムの通常運用時
に、トークンに関するチェックポイントを、サーバＳ側
で取らずに各クライアントＣ１，Ｃ２，Ｃ３・・・側で
取っておき、サーバの復旧時に、各クライアントＣ１，
Ｃ２，Ｃ３・・・へ問い合わせることにより、トークン
情報を収集してトークン情報を再構築するので、サーバ
のクラッシュなどによって、トークンが失われた場合で
も、各クライアントＣ１，Ｃ２，Ｃ３・・・から情報を
収集してトークンを再生成することができ、これにより
サーバのクラッシュ後もトークンに対応する資源を継続
して使用することができるようになる。
【００９４】さて、ここで上述のようにトークン情報を
各クライアントＣ１，Ｃ２，Ｃ３・・・に問い合わせて
収集する場合、分散システムに存在する全てのクライア
ントに問い合わせると、サーバ／クライアント間での通
信量が膨大になってしまい、そのコストも増加してしま
う。そこで、本実施例では、トークン情報の問い合わせ
を発行するクライアントをある程度限定するようにす
る。
【００９５】この場合は、まず通常運用時に、図２０に
示すように、例えば、サーバＳがクライアントＣ１から
“ｄ１”という“ｉｄ”をもった資源に対するトークン
の獲得要求"gettoken(d1)"を受けて、サーバＳがその資
源に対応するトークンをクライアントＣ１に渡す際、安
定記憶（不揮発性の記憶装置）５にトークンを配付した
このクライアントＣ１の識別情報“ｃ１”を記憶させて
おく。他のクライアントＣ２，Ｃ３，・・・についても
同様で、サーバＳはトークンを渡したクライアントの識
別情報を、順次、安定記憶５に記憶させてゆく。
【００９６】つまり、これにより、安定記憶５にはトー
クンを所有しているクライアントのリストが、順次、記
憶されてゆくのである。なお、安定記憶５は、第１実施
例にて前述したものと同様のもので、この場合も、サー
バが存在するノードがクラッシュした場合でも内容が保
持される領域である。そして、例えば、サーバＳが存在
するノードがクラッシュした場合は、異なるノードに存
在する待機用のサーバＳ（説明の便宜上、図２０ではサ
ーバと待機用のサーバには同一符号を付している）が、
この安定記憶５に記憶されたクライアントのリストを読
み込んで、このリストを基に、トークンを所有している
クライアントのみに、トークン情報の問い合わせを発行
することができるようになる。
【００９７】以下、この処理について、図２１のシーケ
ンス図（ステップＪ１〜ステップＪ３）を参照しながら
詳述する。まず、通常運用時に、サーバＳがクライアン
トＣ１から識別情報“ｉｄ”が“ｄ１”であるファイル
などの資源を使用する際に送られてくるトークン獲得要
求を受け取ると（ステップＪ１）、サーバＳは、トーク
ンをクライアントＣ１に渡す際に、安定記憶５にトーク
ンを渡したクライアントＣ１のＩＤ（識別情報）などの
情報“ｃ１”を記録しておく（ステップＪ２，Ｊ３）。
【００９８】そして、それまでプロセスを実行していた
サーバＳが存在するノードがクラッシュしてしまい、待
機用のサーバＳによってサーバＳの復旧を行なう場合、
まず、待機用のサーバＳは、安定記憶５から通常運用時
に記憶されたクライアントのリストを読み込み、このリ
スト中のクライアントのみにトークンに対する問い合わ
せを出す。
【００９９】このように、通常運用時に、サーバＳがク
ライアントＣ１，Ｃ２，Ｃ３・・・にトークンを渡す毎
に、クライアントのＩＤなどの情報を安定記憶５に記憶
させてゆくことにより、トークンを所有しているクライ
アントのリストを記録させておくので、サーバＳによる
サーバの復旧時に、トークンに関与した必要最小限のク
ライアントを特定して、そのクライアントのみにトーク
ン情報の問い合わせを出すことができるようになる。
【０１００】従って、サーバＳが全ての分散システムに
存在する全てのクライアントに対して問い合わせを発行
してトークン情報を収集する必要がなくなるので、この
トークン情報収集の際の通信量の増加などに伴うコスト
を最小限に抑えることができ、これによりサーバによる
復旧の際の処理性能を大幅に向上させることができるよ
うになる。
【０１０１】次に、本実施例における分散システムで
は、図２２に示すように、復旧を行なうサーバＳが存在
するノード（ノード装置：図示略）とは異なるノードに
故障管理サーバＳｃが存在しており、上述のようにして
サーバＳにより読み出されクライアントのリスト(clien
t list) が、この故障管理サーバＳｃに渡されるように
なっている。
【０１０２】ここで、この故障管理サーバＳｃは、分散
システムに存在するサーバＳを含む全てのサーバ（図示
略）の状態を管理しており、例えば、サーバＳによって
読み出されたクライアントのリストを受け取ると、この
クライアントのリスト中のどのクライアントがクラッシ
ュしているかを判別して、クラッシュしていないクライ
アントのリスト(active client list)のみをサーバＳへ
回答するものである。
【０１０３】従って、この場合は、サーバＳによる復旧
の際、図２３に示すように、まず、サーバＳが安定記憶
５からトークンを所有しているクライアントのリストを
読み込んで（ステップＪ４）、このクライアントのリス
トを故障管理サーバＳｃに渡して、このリスト中のクラ
イアントのうち、どのクライアントがクラッシュしてお
り、どのクライアントがクラッシュしていないかという
クライアントの状態を故障管理サーバＳｃに問い合わせ
る（ステップＪ５）。
【０１０４】そして、故障管理サーバＳｃでは、この問
い合わせを受けると、受け取ったクライアントのリスト
中のどのクライアントがクラッシュしているかを判別
し、クラッシュしていないクライアントのリストのみを
サーバＳに回答する（ステップＪ６）。例えば、図２２
においては、サーバＳが安定記憶５から読み込んだトー
クンを所有しているクライアントのＩＤが“ｃ１〜ｃ
４”で、このリストを故障管理サーバＳｃに渡して故障
管理サーバＳｃでこのリスト中のクライアントが故障し
ているか否かを判別した結果、クラッシュしていないク
ライアントのＩＤ“ｃ１”，“ｃ３”，“ｃ４”のみが
サーバＳに回答される様子を表している。
【０１０５】そして、サーバＳは、故障管理サーバＳｃ
から受け取った、トークンを所有し、且つ、クラッシュ
していないクライアント（図２２では、ＩＤが“ｃ
１”，“ｃ３”，“ｃ４”であるクライアント）のみ
に、トークン情報の問い合わせを発行する（ステップＪ
７）。さらに、この問い合わせを受けたクライアントで
は、自己が所有しているトークン情報を調べてサーバＳ
に回答し（ステップＪ８）、サーバＳでは、このクライ
アントからのトークン情報を収集し、トークン情報を再
構築して、サーバの復旧が行なわれる（ステップＪ
９）。
【０１０６】このように、サーバＳによる復旧の際、分
散システムに存在するクライアントにトークン情報の問
い合わせを出す前に、故障管理サーバＳｃでクライアン
トの状態を判別することにより、問い合わせを出すクラ
イアントをクラッシュしていないクライアントのみに絞
り込むことが可能なるので、トークン情報収集の際のコ
ストをより確実に抑えることができ、これによりサーバ
Ｓによる復旧の際の処理性能をさらに大幅に向上させる
ことができるようになる。
【０１０７】さて、ここで、通常、分散システムにおい
ては、あるサーバが別のサーバに対してはクライアント
になることもあるので、プロセス間で複雑な呼出し関係
が生じる可能性がある。従って、上述のように、トーク
ン情報の問い合わせについても多数のクライアントに対
して発行されることになるが、クライアントが他の処理
を実行中である場合は、このトークン情報の問い合わせ
を即座に受け付けることができず、サーバＳがクライア
ントからの応答を待たなければならない。
【０１０８】そして、このような待ち関係が複雑に絡み
合うと、分散システム全体がデッドロックとなり、永遠
に処理が進まなくなってしまう危険性が生じてくる。そ
こで、本実施例では、分散システムに使用されるノード
（ノード装置）に存在するクライアントに、図２４に示
すように、通常運用時に行なうスレッド（処理過程）８
とは別に、サーバＳからのトークン情報の問い合わせに
応答するための専用のスレッド７を用意する。
【０１０９】これにより、上述のようなサーバＳによる
復旧の際、サーバＳからトークン情報の問い合わせを受
けたクライアントは、この問い合わせに対して即座に応
答することができるようになる。従って、サーバＳによ
る復旧の際、サーバＳが多数のクライアントに対してト
ークン情報の問い合わせを発行する場合でも、プロセス
間で複雑な呼出し関係が生じることによってサーバＳが
クライアントからの応答待ちで停止するようなことはな
く、これによりサーバＳによる復旧中に分散システムが
デッドロックに陥ることを回避することができる。
【０１１０】さて、このように、クライアントにトーク
ン情報の問い合わせに応答するための専用のスレッドを
用意しておけば、前述のように、サーバＳがトークン情
報の問い合わせをクライアントに発行すると、この問い
合わせを受けたクライアントがクラッシュしていなけれ
ば、即座に、この問い合わせに対する応答が返ってくる
はずであるが、図２２及び図２３にて前述したように故
障管理サーバＳｃによってトークンを所有しているクラ
イアントの状態を判別しても、判別の後で、そのクライ
アントが故障してしまった場合は、このクライアントか
らは応答が返ってこない。
【０１１１】そこで、本実施例では、図２５に示すよう
に、分散システムに使用されるノードに存在するサーバ
Ｓに、例えば各クライアントＣ１〜Ｃ３にトークン情報
の問い合わせを出したのち所定の時間を設定しておく機
能（手段）を持たせ、この所定の時間内に、問い合わせ
を出したクライアントＣ１〜Ｃ３のうち応答が返ってこ
ないクライアント（本実施例では、クライアントＣ１）
は故障したものとみなし、応答の返ってきたクライアン
トＣ２，Ｃ３からのトークン情報のみを基に、サーバＳ
側でのトークン情報を再構築するようにする。
【０１１２】すなわち、この場合は、図２６のシーケン
ス図（ステップＫ１〜ステップＫ９）に示すように、ま
ず、サーバＳが安定記憶５からトークンを所有している
クライアントＣ１〜Ｃ３のリストを読み出し（ステップ
Ｋ１）、このリストを故障管理サーバＳｃに渡してクラ
イアントＣ１〜Ｃ３の状態を問い合わせる（ステップＫ
２）。
【０１１３】そして、故障管理サーバＳｃでは、受け取
ったリストを基にクライアントＣ１〜Ｃ３の状態を判別
し（ステップＫ３）、故障していないクライアントＣ１
〜Ｃ３のリストをサーバＳへ回答する（ステップＫ
４）。ここで、このような故障管理サーバＳｃによるク
ライアントの状態の判別の後、例えば、クライアントＣ
１が存在するノードのクラッシュなどによりクライアン
トＣ１が故障してしまったとする（ステップＫ５）。
【０１１４】ところが、この時点で、サーバＳは故障管
理サーバＳｃから受け取ったリストを基に各クライアン
トＣ１〜Ｃ３が故障していないと判断するので、各クラ
イアントＣ１〜Ｃ３にトークン情報の問い合わせを発行
するとともに、ある所定の時間だけタイマを設定してお
く（ステップＫ６）。そして、クライアントＣ２，Ｃ３
は、この問い合わせを受けると、自己が保持しているト
ークン情報を調べて（ステップＫ７）、その情報をサー
バＳに回答するが（ステップＫ８）、故障してしまった
クライアントＣ１からは問い合わせに対する応答が返っ
てこない。
【０１１５】サーバＳは、上述のステップＫ６にて設定
したタイマの所定時間が過ぎてもクライアントＣ１から
トークン情報の問い合わせに対する応答が返ってこなけ
れば、クライアントＣ１は故障したものとみなし、応答
が返ってきたクライアントＣ２，Ｃ３のトークン情報の
みを収集して、トークン情報を再構築する（ステップＫ
９）。
【０１１６】従って、サーバＳによる復旧中に、分散シ
ステムに存在するクライアントがノードのクラッシュな
どにより故障してしまった場合でも、故障していないク
ライアントのトークンに関する情報を基にサーバＳ側で
のトークン情報を再構築して、正常にサーバの復旧処理
を行なうことができるようになる。さてここで、通常、
各クライアントＣ１〜Ｃ３は、トークンを獲得すること
によりサーバＳが管理するファイルなどの資源を使用し
て仕事をする際、トークンに対応する資源の属性など
（資源がファイルの場合は、そのファイルのファイルサ
イズなど）を更新し、仕事が終わってサーバＳへトーク
ンを返却する際に、更新した資源の属性をサーバへ反映
させるようにしている。
【０１１７】例えば、図２７に示すように、クライアン
トＣ１がトークンを獲得することにより、サーバＳ側に
おいて識別情報（ｉｄ）が“ｄ１”（資源の属性：“Ｘ
４”，資源の使用を終えた時刻：“ｔ４”）の資源を使
用し、その後、仕事を終えてトークンをサーバＳに返却
すると、クライアントＣ１では、この資源の属性を“Ｘ
１”，トークンを返却して資源の使用を終えた時刻を
“ｔ１”に更新する。なお、他のクライアントＣ２，Ｃ
３についても同様で、サーバＳ側で管理している資源を
使用し、仕事を終えると、それぞれ資源の属性を“Ｘ
２”，“Ｘ３”、資源の使用を終えた時刻を“ｔ２”，
“ｔ３”に更新する。
【０１１８】ところが、ここで、トークンの受渡し中に
ノードのクラッシュなどによりシステムの一部が故障
し、トークンが紛失した場合、各クライアントＣ１〜Ｃ
３が更新した属性も失われる可能性がある。そこで、本
実施例では、サーバＳによるサーバの復旧中に、各クラ
イアントＣ１〜Ｃ３からトークン情報を収集した結果、
トークンが紛失していることが分かった場合、サーバＳ
側でのトークンに対応する資源に関する情報に、分散シ
ステムに存在するクライアント側での最新の資源情報を
反映させる。
【０１１９】すなわち、図２８に示すように、例えば、
サーバＳがトークン情報を収集した結果、識別情報（ｉ
ｄ）が“ｄ１”に対応するトークンが紛失していること
が分かった場合、サーバＳは、まず故障していないクラ
イアントＣ１に識別情報“ｄ１”に対応する資源に関す
る情報を問い合わせ（ステップＬ１）、クライアントＣ
１は、“ｄ１”に対応する資源の属性“Ｘ１”とこの属
性が更新された時刻“ｔ１”とをサーバＳに回答する
（ステップＬ２）。
【０１２０】同様に、サーバＳはクライアントＣ２に識
別情報“ｄ１”に対応する資源に関する情報を問い合わ
せ（ステップＬ３）、クライアントＣ２は、この問い合
わせに対して、自己での識別情報“ｄ１”に対応する資
源の属性“Ｘ２”とこの属性が更新された時刻“ｔ２”
とをサーバＳに回答し（ステップＬ４）、さらにサーバ
ＳはクライアントＣ３にも識別情報“ｄ１”に対応する
資源に関する情報を問い合わせ（ステップＬ５）、クラ
イアントＣ３は、この問い合わせに対して、自己での識
別情報“ｄ１”に対応する資源の属性“Ｘ３”とこの属
性が更新された時刻“ｔ３”とをサーバＳに回答する
（ステップＬ６）。
【０１２１】このように、サーバＳが各クライアントＣ
１〜Ｃ３から識別情報“ｄ１”に対応する資源に関する
情報を収集すると、サーバＳは、サーバＳ側が識別情報
“ｄ１”に対応する資源を使用した時刻“ｔ４”と、各
クライアントＣ１〜Ｃ３から収集した識別情報“ｄ１”
に対応する同じ資源の更新時刻“ｔ１”，“ｔ２”，
“ｔ３”との新旧をそれぞれ比較し、最も新しい更新時
刻をもったクライアントでの資源情報をサーバＳ側の識
別情報“ｄ１”に対応する資源情報に書き込んで更新す
る（ステップＬ７）。
【０１２２】従って、ノードのクラッシュなどによりト
ークンが紛失してしまった場合でも、クライアントＣ１
〜Ｃ３に残っている資源の属性などの情報を収集するこ
とによって最新の情報をサーバＳに反映することができ
るようになる。 （Ｂ−２）第２実施例の具体的な説明 図２９は本発明の第２実施例の具体説明にかかる分散シ
ステムの構成を示すブロック図であるが、この図２９に
示すように、本実施例でも、第１実施例と同様に、分散
システム１は、ノード２〜４という複数のノード（分散
システムに使用されるノード装置）をそなえるととも
に、資源管理情報をもったチェックポイントを記憶する
安定記憶（記憶装置）５をそなえ、さらに、これら複数
のノード２〜４と安定記憶５とがネットワーク６を介し
て接続されている。
【０１２３】そして、各ノード２〜４には、図示しない
ＣＰＵ、主記憶、２次記憶が設けられており、ネットワ
ーク６を介してメッセージを交換できるようになってい
る。また、安定記憶５は、各ノード２〜４からネットワ
ーク６を介してアクセスすることができる不揮発性の記
憶装置で、本実施例でも、この安定記憶５は、どのノー
ドが故障してもその内容は破壊されないものとする。な
お、この安定記憶５はソフトウェア，ハードウェアのど
ちらでも構成でき、ソフトウェアで構成する場合はノー
ド２〜４上に置くこともできる。
【０１２４】さらに、この分散システム１において、ノ
ード２上には、プロセスマネージャー（クライアント）
ＰＭ２と、現用ファイルマネージャー（現用のサーバ）
ＦＭｐとが設けられている。また、ノード３上には、プ
ロセスマネージャー（クライアント）ＰＭ３及び待機フ
ァイルマネージャー（待機用のサーバ）ＦＭｂとが設け
られており、ノード４上には、プロセスマネージャー
（クライアント）ＰＭ４及び故障管理サーバＦＴＭとが
設けられている。
【０１２５】そして、各ノード２，３，４上にはオペレ
ーティングシステム（ＯＳ）が動作しており、このＯＳ
は機能毎に分割された複数のプロセスの集合として実現
されている。ここで、各プロセスマネージャーＰＭ２，
ＰＭ３，ＰＭ４は、上述のように各ノード２，３，４に
存在し、例えば、第１実施例と同様に、ノード４上に存
在するアプリケーションプログラム（図示略）からの要
求を受け付けるものであり、現用ファイルマネージャー
ＦＭｐ及び待機ファイルマネージャーＦＭｂは、ファイ
ル（資源）の管理を行なうものであり、故障管理サーバ
ＦＴＭは、第２実施例の基本的な説明にて前述したよう
に、分散システムに存在するサーバ（現用ファイルマネ
ージャーＦＭｐ，待機ファイルマネージャーＦＭｂ）の
状態を管理しており、サーバによる復旧の際、例えば、
安定記憶５から読み出されたクライアント（例えば、Ｐ
Ｍ２〜４）のリストを受け取ると、そのリスト中のどの
クライアントがクラッシュしているかを判別して、クラ
ッシュしていないクライアントのリストのみをサーバへ
回答するものである。
【０１２６】以下、本実施例では、ノード２がクラッシ
ュした場合のサーバ（現用ファイルマネージャーＦＭ
ｐ）のリカバリ（復旧）処理について図３０及び図３１
を参照しながら詳述する。まず、ノード２がクラッシュ
すると、ノード３上の待機ファイルマネージャーＦＭｂ
が引継ぎを開始し（ステップＳ１）、安定記憶５からチ
ェックポイントを読み込む（ステップＳ２）。
【０１２７】ここで、このチェックポイントには、図２
０にて前述したように、現用ファイルマネージャーＦＭ
ｐがトークンを配付したクライアントのリストやファイ
ルに関するファイル情報などが含まれており、待機ファ
イルマネージャーＦＭｂは、このように安定記憶５から
チェックポイントを読み込むことで、例えば、クライア
ントのリストとしてプロセスマネージャーＰＭ２，ＰＭ
３，ＰＭ４のＩＤなどの識別情報を取得する。
【０１２８】さらに、待機ファイルマネージャーＦＭｂ
は、このクライアントのリストをノード４上の故障管理
サーバＦＴＭへ送って、プロセスマネージャーＰＭ２，
ＰＭ３，ＰＭ４の状態（クラッシュしているか否か）を
判定するよう要求し（ステップＳ３）、故障管理サーバ
ＦＴＭでは、受け取ったリスト中のプロセスマネージャ
ーＰＭ２，ＰＭ３，ＰＭ４の状態を判別し、故障してい
ないプロセスマネージャーのみを抜き出して待機ファイ
ルマネージャーＦＭｂに回答する。
【０１２９】ここで、この場合は、ノード２上のプロセ
スマネージャーＰＭ２がノード２のクラッシュにより機
能しなくなっているので、これを除いたプロセスマネー
ジャーＰＭ３，ＰＭ４のみをクライアントのリストとし
て待機ファイルマネージャーＦＭｂに回答する（ステッ
プＳ４，Ｓ５）。そして、待機ファイルマネージャーＦ
Ｍｂは、この故障管理サーバＦＴＭからの回答を基に、
プロセスマネージャーＰＭ３，ＰＭ４に対してファイル
（トークンも含む）に関する情報を問い合わせ、この問
い合わせを受けた各プロセスマネージャーＰＭ３，ＰＭ
４は、自身が保持しているトークン情報，ファイルの属
性などのファイル情報を調べてそれぞれサーバである待
機ファイルマネージャーＦＭｂに調べた情報を回答する
（ステップＳ６〜ステップＳ８）。なお、このとき、各
プロセスマネージャーＰＭ３，ＰＭ４では、図２４にて
前述したように、通常運用時の処理とは別に、待機ファ
イルマネージャーＦＭｂからの問い合わせに応答するた
めの専用の処理を行なうことにより回答を行なってい
る。
【０１３０】その後、待機ファイルマネージャーＦＭｂ
は、各プロセスマネージャーＰＭ３，ＰＭ４から回答さ
れたトークン情報やファイルの属性などの情報を基に、
自身が管理するファイル情報を再構築する（ステップＳ
９）。なお、このとき、図２５にて前述したように、例
えばプロセスマネージャーＰＭ３が新たに故障してしま
って、プロセスマネージャーＰＭ３からの回答が所定の
時間を経過しても得られない場合、待機ファイルマネー
ジャーＦＭｂは、プロセスマネージャーＰＭ４から回答
された情報のみを基にして自身が管理するファイル情報
を再構築するようになる。
【０１３１】そして、図３２（ａ）は上述のように待機
ファイルマネージャーＦＭｂが安定記憶５から読み込ん
だファイル情報の一例を示す図であり、図３２（ｂ）は
ノード３上のプロセスマネージャーＰＭ３が保持してい
るファイル情報の一例を示す図であり、図３２（ｃ）は
ノード４上のプロセスマネージャーＰＭ４が保持してい
るファイル情報の一例を示す図であるが、これらの図３
２（ａ）〜（ｃ）に示すように、具体的に、ファイルに
関する情報は、"file id"," トークン","filesize","
時刻印" からなっている。
【０１３２】ここで、"file id" はファイルの種別など
を識別するための識別情報であり、" トークン" はトー
クンを所有しているか否かを表す情報（トークンを所有
している場合は“ｈ”で表記している）であり、" 時刻
印" はそのファイルが更新された時刻を表す情報で、こ
の場合は、ファイルが更新された日付（年月日）が記録
されるようになっている。なお、このときファイルｉｄ
(file id) が“ｄ２”，“ｄ４”，“ｄ５”の各ファイ
ルについてはトークンの所有者がいないので、サーバで
ある待機ファイルマネージャーＦＭｂがトークンの所有
者となっている。
【０１３３】さてここで、図３２（ｂ），図３２（ｃ）
に示すように、例えば、プロセスマネージャーＰＭ３，
ＰＭ４では、ファイルｉｄが“ｄ２”，“ｄ５”のファ
イルに対応したトークンを所有していないので、トーク
ンが紛失してしまっていることがわかる。このため、待
機ファイルマネージャーＦＭｂは、プロセスマネージャ
ーＰＭ３，ＰＭ４から回答されたファイル情報のそれぞ
れの時刻印を比較し、新しい時刻印をもった方の属
性（"file size" ）を優先してサーバに反映するととも
に、トークンの所有者を自身（待機ファイルマネージャ
ーＦＭｂ）に設定する。
【０１３４】例えば、ファイルｉｄ（file id ）が“ｄ
５”のファイルの場合、プロセスマネージャーＰＭ４側
でのファイル情報の時刻印(94.8.17) の方が、待機ファ
イルマネージャーＦＭｂ側での時刻印(94.7.30) より新
しいので、プロセスマネージャーＰＭ４の持っている最
新のファイル情報（属性）"file size(s5')"を、待機フ
ァイルマネージャーＦＭｂ側のファイル情報に反映させ
て更新するのである。
【０１３５】この結果、最終的に待機ファイルマネージ
ャーＦＭｂ側でのファイル情報は、図３３に示すように
再構築され、ノード２のクラッシュにより機能しなくな
ってしまった現用ファイルマネージャーＦＭｐのプロセ
スが待機ファイルマネージャーＦＭｂに引き継がれてサ
ーバの復旧処理が終了する。このように、上述の分散シ
ステムにおけるサーバの復旧処理によれば、ノード２が
クラッシュするなどして分散システム１の一部が故障し
た場合でも、待機用のサーバ（待機ファイルマネージャ
ーＦＭｂ）により、トークン情報を収集して、サーバの
トークン情報を再構築して復旧させることができるの
で、分散システム１全体として矛盾のない状態で処理を
継続することが可能になる。
【０１３６】
【発明の効果】以上詳述したように、本発明の分散シス
テムに使用されるノード装置及び記憶装置並びに分散シ
ステムにおける資源管理用サーバの復旧方法によれば、
通常運用時に、サーバ側で自己が管理する資源に関する
チェックポイントを取る代わりに、クライアント側で資
源に関するチェックポイントを取ることにより、チェッ
クポイントを記憶装置に記憶しておき、その後、ノード
のクラッシュ時に、サーバがクライアントを介し資源に
関する情報を収集して、復旧を行なうので、多数のクラ
イアントからの要求を処理する必要のあるサーバの負荷
を大幅に削減でき、これによりサーバの復旧処理を高速
に行なうことができるとともに、サーバの負荷を増大さ
せることなくフォールトトレラントな分散システムを構
築することができるという効果がある（請求項１，１
２，１４）。
【０１３７】また、本発明の分散システムに使用される
ノード装置及び分散システムにおける資源管理用サーバ
の復旧方法によれば、通常運用時に、クライアント側で
現用のサーバが管理する資源に関するチェックポイント
を取ることにより、チェックポイントを記憶装置に記憶
しておき、その後、現用のサーバが存在するノードのク
ラッシュ時に、他のノードに存在する待機用のサーバ
が、クライアントにサーバが管理している資源に関する
情報を問い合わせることにより、情報を収集し、この収
集した情報に基づいて待機用サーバの内部状態を再構築
して、サーバの復旧を行なうので、多数のクライアント
からの要求を処理する必要のあるサーバの負荷を大幅に
削減でき、これによりサーバの復旧処理を高速に行なう
ことができるとともに、分散システムの性能が大幅に向
上するという効果がある。さらに、現用のサーバから待
機用のサーバへのプロセスの引継ぎ時に、サーバが記憶
装置からチェックポイントを読みだすコストがかからな
いため、サーバの復旧処理を高速に行なうことができる
という効果もある。また、故障したクライアントにしか
保持されていなかった資源を新たに再構築せずに済むの
で、記憶装置内の使用するメモリ領域を大幅に削減で
き、サーバのメモリ領域を有効に活用できるという効果
もある（請求項２，１５）。
【０１３８】さらに、本発明の分散システムに使用され
るノード装置及び分散システムにおける資源管理用サー
バの復旧方法によれば、通常運用時に、クライアント側
で現用のサーバ側で管理する資源に関するチェックポイ
ントを取ることにより、チェックポイントを記憶装置に
記憶しておき、その後、待機用のクライアントを他のノ
ードにもったクライアント及び現用のサーバが存在する
ノードのクラッシュ時には、まず、待機用のクライアン
トが記憶装置からクラッシュしたノードに存在したクラ
イアントに関するチェックポイントを読み込んで、サー
バの資源に関する状態を復旧した時点で、その旨を待機
用のサーバに通知し、ついで、待機用のサーバ側では、
復旧中のクライアントから復旧した旨の通知を受ける
と、待機用のサーバが、クライアントにサーバが管理し
ている資源に関する情報を問い合わせることにより、情
報を収集し、この収集した情報に基づいて待機用サーバ
の内部状態を再構築して、サーバの復旧を行なうので、
復旧の各プロセスを記憶装置からチェックポイントを読
み込むプロセスと、クライアント間で連携して資源管理
情報を再構築するプロセスとを明確に分けることがで
き、これにより資源管理情報を再構築する場合の各プロ
セスに対する問い合わせメッセージの遅延時間を大幅に
削減でき、分散システム全体で効率の良い復旧処理を行
なうことができるという効果がある（請求項３，１
６）。
【０１３９】また、本発明の分散システムに使用される
ノード装置及び分散システムにおける資源管理用サーバ
の復旧方法によれば、サーバによる復旧中は、クライア
ント同士でサーバが管理している資源に関する情報の受
渡しを禁止することができるので、サーバの復旧中に資
源管理情報が変更されてしまうようなことがなく、これ
によりサーバは収集した情報からシステム全体として矛
盾のない資源管理情報を再構築してシステムを高速に復
旧することができるという効果がある（請求項４，１
７）。
【０１４０】さらに、本発明の分散システムに使用され
るノード装置及び分散システムにおける資源管理用サー
バの復旧方法によれば、サーバクラッシュ毎に更新され
るインカーネーション番号をクライアント間での情報の
受渡し時に同時に送信することができるので、サーバが
クライアントに資源情報を問い合わせた時点で、クライ
アントに送信済かつクライアントで未受信のメッセージ
を検出することができ、この検出したメッセージを無効
にすることにより、サーバは、資源情報問い合わせ時に
クライアントから収集した情報のみをもとにして、一貫
性のある資源管理情報を構築してシステムを高速に復旧
することができるという効果がある（請求項５，１
８）。
【０１４１】また、本発明の分散システムに使用される
ノード装置及び記憶装置並びに分散システムにおける資
源管理用サーバの復旧方法によれば、通常運用時に、サ
ーバ側で管理する資源の使用を分散システムに存在する
クライアントに許可するためのトークンに関するチェッ
クポイントを、クライアント側で取っておき、その後、
ノード装置のクラッシュ時に、サーバがクライアントか
らトークンに関する情報を収集し、この収集した情報に
基づいてサーバ側で自己が管理するトークンの情報を再
構築して、復旧を行なうので、サーバのクラッシュなど
によって、トークンが失われた場合でも、クライアント
から情報を収集してトークンを再生成することができ、
これによりサーバのクラッシュ後もトークンに対応する
資源を継続して使用することができるようになる（請求
項６，１３，１９）。
【０１４２】また、資源管理用サーバに関し、現用と待
機用とが異なったノードに分散して設けられる場合は、
現用のサーバが存在するノード装置のクラッシュ時に、
他のノード装置に存在する待機用のサーバが、トークン
を所有しているクライアントのみにトークンに関する情
報を問い合わせることにより、情報を収集し、この収集
した情報に基づいて待機用サーバ側で自己が管理するト
ークンの情報を再構築して、サーバの復旧を行なうの
で、サーバＳによるサーバの復旧時に、トークンに関与
した必要最小限のクライアントを特定することが可能に
なる。従って、サーバが分散システムに存在する全ての
クライアントに対して問い合わせを発行してトークン情
報を収集する必要がなくなるので、このトークン情報収
集のコストを最小限に抑えることができ、これによりサ
ーバによる復旧の際の処理性能を大幅に向上させること
ができるようになる（請求項７，２０）。
【０１４３】さらに、このとき、資源管理用サーバが存
在するノード装置と異なるノード装置に故障管理用のサ
ーバを設ければ、資源管理用サーバが存在するノード装
置のクラッシュ時に、故障管理用のサーバがトークンを
所有しているクライアントがクラッシュしているか否か
を判定し、この判定に基づいて待機用のサーバが、トー
クンを所有し、且つ、クラッシュしていないクライアン
トのみに、トークンに関する情報を問い合わせることが
できるので、トークンに関する情報を収集する際のコス
トをより確実に抑えることができ、これによりサーバに
よる復旧の際の処理性能をさらに大幅に向上させること
ができるようになる。（請求項８，２１）。
【０１４４】また、上述のような、サーバによる復旧の
際、サーバからのトークンに関する情報の問い合わせを
受けたクライアントは、通常運用時に行なう処理とは別
に、この問い合わせに応答するための専用の処理を行な
うので、上述のようなサーバによる復旧の際、サーバか
らトークンに関する情報の問い合わせを受けたクライア
ントは、この問い合わせに対して即座に応答することが
できるようになる。従って、サーバが多数のクライアン
トに対してトークンに関する情報の問い合わせを発行す
る場合でも、サーバがクライアントからの応答待ちで停
止するようなことはないので、サーバによる復旧中に処
理が進まないといったデッドロックを回避することがで
きる（請求項９，２２）。
【０１４５】さらに、このようなサーバによる復旧の
際、クライアントにトークンに関する情報を問い合わせ
た後、所定の時間を経過してもクライアントからこの問
い合わせに対する応答がなくトークンに関する情報を収
集することができない場合には、応答があったクライア
ントのみからトークンに関する情報を収集するので、サ
ーバによる復旧中に、分散システムに存在するクライア
ントがノードのクラッシュなどにより故障してしまった
場合でも、クラッシュしていないクライアントからのト
ークンに関する情報を基に、サーバ側のトークンに関す
る情報を再構築して、正常にサーバの復旧処理を行なう
ことができるようになる（請求項１０，２３）。
【０１４６】また、サーバによる復旧の際、トークンを
所有しているクライアントにトークンに関する情報を問
い合わせることにより情報を収集した後は、サーバ側で
のトークンに対応する資源に関する情報と、過去にトー
クンを所有することによりサーバ側で管理する資源を使
用していたクライアント側での資源に関する情報との新
旧を比較し、この比較結果に基づいて、サーバ側で管理
するトークンに対応する資源に関する情報を、最新の情
報に更新するので、トークンが紛失してしまった場合で
も、分散システムに存在するクライアントに残っている
トークンに対応した資源に関する情報を収集することに
よって最新の情報をサーバに反映することができるよう
になる（請求項１１，２４）。
【図面の簡単な説明】
【図１】本発明の第１実施例の基本説明にかかる分散シ
ステムの構成を示すブロック図である。
【図２】本発明の第１実施例の基本説明にかかる分散シ
ステムにおける資源管理用サーバの復旧方法を説明する
ためのシーケンス図である。
【図３】本発明の第１実施例の基本説明にかかる分散シ
ステムの構成を示すブロック図である。
【図４】本発明の第１実施例の基本説明にかかる分散シ
ステムにおける資源管理用サーバの復旧方法を説明する
ためのシーケンス図である。
【図５】本発明の第１実施例の基本説明にかかる分散シ
ステムの構成を示すブロック図である。
【図６】本発明の第１実施例の基本説明にかかる分散シ
ステムにおける資源管理用サーバの復旧方法を説明する
ためのシーケンス図である。
【図７】本発明の第１実施例の基本説明にかかる分散シ
ステムにおいてクライアント同士での情報の受渡しを禁
止する場合の処理を説明するためのシーケンス図であ
る。
【図８】本発明の第１実施例の基本説明にかかる分散シ
ステムにおいてクライアント同士での情報の受渡しを禁
止する場合の処理を説明するためのシーケンス図であ
る。
【図９】本発明の第１実施例の基本説明にかかる分散シ
ステムにおいてインカーネーション番号をクライアント
間での情報の受渡し時に同時に送信する場合の処理を説
明するためのシーケンス図である。
【図１０】本発明の第１実施例の基本説明にかかる分散
システムにおいてインカーネーション番号をクライアン
ト間での情報の受渡し時に同時に送信する場合の処理を
説明するためのシーケンス図である。
【図１１】本発明の第１実施例の具体的な説明にかかる
分散システムの構成を示すブロック図である。
【図１２】本発明の第１実施例の具体的な説明にかかる
分散システムの構成を示すブロック図である。
【図１３】本発明の第１実施例の具体的な説明にかかる
分散システムの構成を示すブロック図である。
【図１４】本発明の第１実施例の具体的な説明にかかる
分散システムの構成を示すブロック図である。
【図１５】本発明の第１実施例の具体的な説明にかかる
分散システムにおける資源管理用サーバの復旧方法を説
明するためのシーケンス図である。
【図１６】本発明の第１実施例にかかる資源がファイル
である場合のファイルテーブルの一例を示す図である。
【図１７】本発明の第２実施例の基本説明にかかる分散
システムにおける動作概念を説明するための図である。
【図１８】本発明の第２実施例の基本説明にかかる分散
システムにおけるトークンに関する情報の収集処理を説
明するためのシーケンス図である。
【図１９】本発明の第２実施例の基本説明にかかる分散
システムにおける収集されたトークン情報の一例を示す
図である。
【図２０】本発明の第２実施例の基本説明にかかる分散
システムにおける動作概念を説明するための図である。
【図２１】本発明の第２実施例の基本説明にかかる分散
システムにおけるクライアントのリストを記憶装置に記
憶させる処理を説明するためのシーケンス図である。
【図２２】本発明の第２実施例の基本説明にかかる分散
システムにおける動作概念を説明するための図である。
【図２３】本発明の第２実施例の基本説明にかかる分散
システムに故障管理サーバが存在する場合の処理を説明
するためのシーケンス図である。
【図２４】本発明の第２実施例の基本説明にかかる分散
システムにおける動作概念を説明するための図である。
【図２５】本発明の第２実施例の基本説明にかかる分散
システムにおける動作概念を説明するための図である。
【図２６】本発明の第２実施例の基本説明にかかる分散
システムにおける故障していないクライアントのみから
トークンに関する情報を収集する処理を説明するための
シーケンス図である。
【図２７】本発明の第２実施例の基本説明にかかる分散
システムにおけるサーバとクライアントでの資源情報の
一例を示す図である。
【図２８】本発明の第２実施例の基本説明にかかる分散
システムにおけるサーバ側のトークンに対応する資源情
報を最新の情報に更新する処理を説明するためのシーケ
ンス図である。
【図２９】本発明の第２実施例の具体的な説明にかかる
分散システムの構成を示すブロック図である。
【図３０】本発明の第２実施例の具体的な説明にかかる
分散システムにおけるサーバの復旧処理を説明するため
の図である。
【図３１】本発明の第２実施例の具体的な説明にかかる
分散システムにおけるサーバの復旧処理を説明するため
のシーケンス図である。
【図３２】（ａ）〜（ｃ）はそれぞれ本発明の第２実施
例の具体的な説明にかかる分散システムにおけるサーバ
の復旧処理を説明するためのファイル情報の一例を示す
図である。
【図３３】本発明の第２実施例の具体的な説明にかかる
分散システムにおけるサーバの復旧処理により再構築さ
れたファイル情報の一例を示す図である。
【符号の説明】
１ 分散システム ２，３，４ ノード ５ 安定記憶 ６ ネットワーク ７，８ スレッド Ｓ サーバ Ｓｐ 現用サーバ Ｓｂ 待機サーバ Ｃ１，Ｃ２，Ｃ３ クライアント Ｃ２ｐ 現用クライアント Ｃ２ｂ 待機クライアント Ｐ アプリケーションプログラム ＰＭ２，ＰＭ３，ＰＭ４ プロセスマネージャー（クラ
イアント） ＦＭｐ 現用ファイルマネージャー（現用のサーバ） ＦＭｂ 待機ファイルマネージャー（待機用のサーバ） ＳｔＭｐ 現用ストリームマネージャー（現用のクライ
アント） ＳｔＭｂ 待機ストリームマネージャー（待機用のクラ
イアント） ＦＴ ファイルテーブル Ｓｃ，ＦＴＭ 故障管理サーバ

Claims (24)

    【特許請求の範囲】
  1. 【請求項１】 クライアント及び資源管理用サーバの両
    方または一方を有するノード装置を複数そなえるととも
    に、資源管理情報をもったチェックポイントを記憶する
    記憶装置をそなえ、該複数のノード装置と該記憶装置と
    がネットワークを介して接続され、且つ、上記のクライ
    アント及びサーバがサーバ・クライアントモデルに基づ
    いて動作する分散システムに使用され、少なくともクラ
    イアントを有するノード装置において、 上記複数のノード装置のいずれかのノード装置のクラッ
    シュ時に、該分散システムに存在するサーバが同じく該
    分散システムに存在するクライアントを介し資源に関す
    る情報を収集して、復旧を行なえるように、通常運用時
    に、該ノード装置に設けられた該クライアント側で該資
    源に関するチェックポイントを取って、該チェックポイ
    ントを該記憶装置に記憶させる手段が設けられたことを
    特徴とする、分散システムに使用されるノード装置。
  2. 【請求項２】 クライアント及び資源管理用サーバの両
    方または一方を有するノード装置を複数そなえるととも
    に、資源管理情報をもったチェックポイントを記憶する
    記憶装置をそなえ、且つ、該資源管理用サーバに関し、
    現用と待機用とが異なったノード装置に分散して設けら
    れ、更に該複数のノード装置と該記憶装置とがネットワ
    ークを介して接続され、且つ、上記のクライアント及び
    サーバがサーバ・クライアントモデルに基づいて動作す
    る分散システムに使用され、少なくともクライアントを
    有するノード装置において、 該現用のサーバが存在する他のノード装置のクラッシュ
    時に、該待機用のサーバが該分散システムに存在するク
    ライアントにサーバが管理している資源に関する情報を
    問い合わせることにより、情報を収集し、この収集した
    該資源に関する情報に基づいて該待機用サーバの内部状
    態を再構築して、サーバの復旧を行なえるように、通常
    運用時に、該ノード装置に設けられた該クライアント側
    で該資源に関するチェックポイントを取って、該チェッ
    クポイントを該記憶装置に記憶させる手段が設けられた
    ことを特徴とする、分散システムに使用されるノード装
    置。
  3. 【請求項３】 クライアント及び資源管理用サーバの両
    方または一方を有するノード装置を複数そなえるととも
    に、資源管理情報をもったチェックポイントを記憶する
    記憶装置をそなえ、且つ、該クライアント及び該資源管
    理用サーバのそれぞれに関し、現用と待機用とが異なっ
    たノード装置に分散して設けられ、更に該複数のノード
    装置と該記憶装置とがネットワークを介して接続され、
    且つ、上記のクライアント及びサーバがサーバ・クライ
    アントモデルに基づいて動作する分散システムに使用さ
    れ、少なくともクライアントを有するノード装置におい
    て、 該待機用のクライアントを他のノード装置にもったクラ
    イアント及び該現用のサーバが存在するノード装置のク
    ラッシュ時に、該分散システムに存在する該待機用のク
    ライアントが該記憶装置からクラッシュしたノード装置
    に存在したクライアントに関するチェックポイントを読
    み込んで、サーバの資源に関する状態を復旧した時点
    で、その旨を該待機用のサーバに通知し、該待機用のサ
    ーバ側では、復旧中のクライアントから復旧した旨の通
    知を受けると、該待機用のサーバが、該分散システムに
    存在するクライアントにサーバが管理している資源に関
    する情報を問い合わせることにより、情報を収集し、こ
    の収集した情報に基づいて該待機用サーバの内部状態を
    再構築して、サーバの復旧を行なえるように、通常運用
    時に、該ノード装置に設けられた該クライアント側で該
    資源に関するチェックポイントを取って、該チェックポ
    イントを該記憶装置に記憶しておく手段が設けられたこ
    とを、特徴とする、分散システムに使用されるノード装
    置。
  4. 【請求項４】 該サーバによる復旧中に、クライアント
    同士でサーバが管理している資源に関する情報の受渡し
    を禁止する手段が設けられたことを特徴とする請求項１
    〜請求項３のいずれかに記載の分散システムに使用され
    るノード装置。
  5. 【請求項５】 サーバクラッシュ毎に更新されるインカ
    ーネーション番号をクライアント間での情報の受渡し時
    に同時に送信する手段が設けられたことを特徴とする請
    求項１〜請求項４のいずれかに記載の分散システムに使
    用されるノード装置。
  6. 【請求項６】 クライアント及び資源管理用サーバの両
    方または一方を有するノード装置を複数そなえるととも
    に、資源管理情報をもったチェックポイントを記憶する
    記憶装置をそなえ、該複数のノード装置と該記憶装置と
    がネットワークを介して接続され、且つ、上記のクライ
    アント及びサーバがサーバ・クライアントモデルに基づ
    いて動作する分散システムに使用され、少なくともクラ
    イアントを有するノード装置において、 上記複数のノード装置のいずれかのノード装置のクラッ
    シュ時に、該分散システムに存在するサーバが同じく該
    分散システムに存在するクライアントを介しサーバ側で
    管理する資源の使用を該クライアントに許可するための
    トークンに関する情報を収集して、復旧を行なえるよう
    に、通常運用時に、該ノード装置に設けられた該クライ
    アント側で該トークンに関するチェックポイントを取る
    手段が設けられたことを特徴とする、分散システムに使
    用されるノード装置。
  7. 【請求項７】 クライアント及び資源管理用サーバの両
    方または一方を有するノード装置を複数そなえるととも
    に、資源管理情報をもったチェックポイントを記憶する
    記憶装置をそなえ、且つ、該資源管理用サーバに関し、
    現用と待機用とが異なったノード装置に分散して設けら
    れ、更に該複数のノード装置と該記憶装置とがネットワ
    ークを介して接続され、且つ、上記のクライアント及び
    サーバがサーバ・クライアントモデルに基づいて動作す
    る分散システムに使用され、少なくともクライアントを
    有するノード装置において、 該現用のサーバが存在するノード装置のクラッシュ時
    に、他のノード装置に存在する該待機用のサーバが、サ
    ーバ側で管理する資源の使用を該分散システムに存在す
    るクライアントに許可するためのトークンを所有してい
    るクライアントのみに該トークンに関する情報を問い合
    わせることにより、情報を収集し、この収集した該トー
    クンに関する情報に基づいて該待機用のサーバの内部状
    態を再構築して、サーバの復旧を行なえるように、通常
    運用時に、該トークンを所有させたクライアントのリス
    トを該記憶装置に記憶させる手段が設けられたことを特
    徴とする、分散システムに使用されるノード装置。
  8. 【請求項８】 該サーバによる復旧の際、該サーバが該
    トークンを所有し、且つ、クラッシュしていないクライ
    アントのみに該トークンに関する情報を問い合わせるよ
    うに、該記憶装置に記憶された上記クライアントのリス
    トを基に該トークンを所有しているクライアントがクラ
    ッシュしているか否かを判定する故障管理用サーバが設
    けられたことを特徴とする請求項６又は請求項７記載の
    分散システムに使用されるノード装置。
  9. 【請求項９】 通常運用時に行なう処理とは別に、該サ
    ーバからの該トークンに関する情報の問い合わせに応答
    するための専用の処理を行なう手段が設けられたことを
    特徴とする請求項６又は請求項７に記載の分散システム
    に使用されるノード装置。
  10. 【請求項１０】 該サーバによる復旧の際、該サーバ
    が、該トークンに関する情報を分散システムに存在する
    クライアントに問い合わせたのち、所定の時間が経過し
    ても該クライアントからこの問い合わせに対する応答が
    なく該トークンに関する情報を収集することができない
    場合に応答のあったクライアントのみから該トークンに
    関する情報を収集するように、所定の時間を設定するタ
    イマ手段が設けられたことを特徴とする請求項６又は請
    求項７記載の分散システムに使用されるノード装置。
  11. 【請求項１１】 該サーバによる復旧の際、該サーバ
    が、自己が管理する該トークンに対応する資源情報を最
    新の資源情報に更新するように、該サーバ側で管理する
    資源に関する情報と、過去に該トークンを所有すること
    により該資源を使用していたクライアント側で管理する
    該資源に関する情報との新旧を比較する手段が設けられ
    たことを特徴とする請求項６又は請求項７記載の分散シ
    ステムに使用されるノード装置。
  12. 【請求項１２】 クライアント及び資源管理用サーバの
    両方または一方を有するノード装置を複数そなえるとと
    もに、資源管理情報をもったチェックポイントを記憶す
    る記憶装置をそなえ、該複数のノード装置と該記憶装置
    とがネットワークを介して接続され、且つ、上記のクラ
    イアント及びサーバがサーバ・クライアントモデルに基
    づいて動作する分散システムに使用される記憶装置にお
    いて、上記複数のノード装置のいずれかのノード装置の
    クラッシュ時に、該分散システムに存在するサーバが同
    じく該分散システムに存在するクライアントを介し資源
    に関する情報を収集して、復旧を行なえるように、通常
    運用時に、該クライアント側で取られた該資源に関する
    チェックポイントを受け取って、該チェックポイントを
    記憶するチェックポイント記憶手段が設けられたことを
    特徴とする、分散システムに使用される記憶装置。
  13. 【請求項１３】 クライアント及び資源管理用サーバの
    両方または一方を有するノード装置を複数そなえるとと
    もに、資源管理情報をもったチェックポイントを記憶す
    る記憶装置をそなえ、且つ、該資源管理用サーバに関
    し、現用と待機用とが異なったノード装置に分散して設
    けられ、更に該複数のノード装置と該記憶装置とがネッ
    トワークを介して接続され、且つ、上記のクライアント
    及びサーバがサーバ・クライアントモデルに基づいて動
    作する分散システムに使用される記憶装置において、 該現用のサーバが存在するノード装置のクラッシュ時
    に、他のノード装置に存在する該待機用のサーバが、サ
    ーバ側で管理している資源の使用を該分散システムに存
    在するクライアントに許可するためのトークンを所有し
    ているクライアントのみに該トークンに関する情報を問
    い合わせることにより、情報を収集し、この収集した該
    トークンに関する情報に基づいて該待機用の内部状態を
    再構築して、サーバの復旧を行なえるように、通常運用
    時に、該トークンを所有しているクライアントのリスト
    を受け取って、該クライアントのリストを記憶するクラ
    イアントリスト記憶手段が設けられたことを特徴とす
    る、分散システムに使用される記憶装置。
  14. 【請求項１４】 クライアント及び資源管理用サーバの
    両方または一方を有するノード装置を複数そなえるとと
    もに、資源管理情報をもったチェックポイントを記憶す
    る記憶装置をそなえ、該複数のノード装置と該記憶装置
    とがネットワークを介して接続された分散システムであ
    って、上記のクライアント及びサーバがサーバ・クライ
    アントモデルに基づいて動作するものにおいて、 通常運用時に、該サーバ側で自己が管理する資源に関す
    るチェックポイントを取る代わりに、該クライアント側
    で該資源に関するチェックポイントを取ることにより、
    該チェックポイントを該記憶装置に記憶しておき、 その後、ノード装置のクラッシュ時に、サーバがクライ
    アントを介し資源に関する情報を収集して、復旧を行な
    うことを特徴とする、分散システムにおける資源管理用
    サーバの復旧方法。
  15. 【請求項１５】 クライアント及び資源管理用サーバの
    両方または一方を有するノード装置を複数そなえるとと
    もに、資源管理情報をもったチェックポイントを記憶す
    る記憶装置をそなえ、且つ、該資源管理用サーバに関
    し、現用と待機用とが異なったノード装置に分散して設
    けられ、更に該複数のノード装置と該記憶装置とがネッ
    トワークを介して接続された分散システムであって、上
    記のクライアント及びサーバがサーバ・クライアントモ
    デルに基づいて動作するものにおいて、 通常運用時に、現用のサーバ側で自己が管理する資源に
    関するチェックポイントを取る代わりに、該クライアン
    ト側で該資源に関するチェックポイントを取ることによ
    り、該チェックポイントを該記憶装置に記憶しておき、 その後、該現用のサーバが存在するノード装置のクラッ
    シュ時に、他のノード装置に存在する待機用のサーバ
    が、クライアントにサーバが管理している資源に関する
    情報を問い合わせることにより、情報を収集し、この収
    集した情報に基づいて該待機用サーバの内部状態を再構
    築して、サーバの復旧を行なうことを特徴とする、分散
    システムにおける資源管理用サーバの復旧方法。
  16. 【請求項１６】 クライアント及び資源管理用サーバの
    両方または一方を有するノード装置を複数そなえるとと
    もに、資源管理情報をもったチェックポイントを記憶す
    る記憶装置をそなえ、且つ、該クライアント及び該資源
    管理用サーバのそれぞれに関し、現用と待機用とが異な
    ったノード装置に分散して設けられ、更に該複数のノー
    ド装置と該記憶装置とがネットワークを介して接続され
    た分散システムであって、上記のクライアント及びサー
    バがサーバ・クライアントモデルに基づいて動作するも
    のにおいて、 通常運用時に、現用のサーバ側で自己が管理する資源に
    関するチェックポイントを取る代わりに、該クライアン
    ト側で該資源に関するチェックポイントを取ることによ
    り、該チェックポイントを該記憶装置に記憶しておき、 その後、待機用のクライアントを他のノード装置にもっ
    たクライアント及び該現用のサーバが存在するノード装
    置のクラッシュ時には、 まず、該待機用のクライアントが該記憶装置からクラッ
    シュしたノード装置に存在したクライアントに関するチ
    ェックポイントを読み込んで、サーバの資源に関する状
    態を復旧した時点で、その旨を待機用のサーバに通知
    し、 ついで、該待機用のサーバ側では、復旧中のクライアン
    トから復旧した旨の通知を受けると、該待機用のサーバ
    が、クライアントにサーバが管理している資源に関する
    情報を問い合わせることにより、情報を収集し、この収
    集した情報に基づいて該待機用サーバの内部状態を再構
    築して、サーバの復旧を行なうことを特徴とする、分散
    システムにおける資源管理用サーバの復旧方法。
  17. 【請求項１７】 該サーバによる復旧中は、クライアン
    ト同士でサーバが管理している資源に関する情報の受渡
    しを禁止することを特徴とする請求項１４〜請求項１６
    のいずれかに記載の分散システムにおける資源管理用サ
    ーバの復旧方法。
  18. 【請求項１８】 サーバクラッシュ毎に更新されるイン
    カーネーション番号をクライアント間での情報の受渡し
    時に同時に送信することを特徴とする請求項１４〜請求
    項１６のいずれかに記載の分散システムにおける資源管
    理用サーバの復旧方法。
  19. 【請求項１９】 クライアント及び資源管理用サーバの
    両方または一方を有するノード装置を複数そなえるとと
    もに、資源管理情報をもったチェックポイントを記憶す
    る記憶装置をそなえ、該複数のノード装置と該記憶装置
    とがネットワークを介して接続された分散システムであ
    って、上記のクライアント及びサーバがサーバ・クライ
    アントモデルに基づいて動作するものにおいて、 通常運用時に、サーバ側で管理する資源の使用をクライ
    アントに許可するためのトークンに関するチェックポイ
    ントを取る代わりに、該クライアント側で該トークンに
    関するチェックポイントを取っておき、 その後、ノード装置のクラッシュ時に、サーバがクライ
    アントを介し該トークンに関する情報を収集して、復旧
    を行なうことを特徴とする、分散システムにおける資源
    管理用サーバの復旧方法。
  20. 【請求項２０】 クライアント及び資源管理用サーバの
    両方または一方を有するノード装置を複数そなえるとと
    もに、資源管理情報をもったチェックポイントを記憶す
    る記憶装置をそなえ、且つ、該資源管理用サーバに関
    し、現用と待機用とが異なったノード装置に分散して設
    けられ、更に該複数のノード装置と該記憶装置とがネッ
    トワークを介して接続された分散システムであって、上
    記のクライアント及びサーバがサーバ・クライアントモ
    デルに基づいて動作するものにおいて、 通常運用時に、現用のサーバ側で管理する資源の使用を
    クライアントに許可するためのトークンに関するチェッ
    クポイントを取る代わりに、該クライアント側で該トー
    クンに関するチェックポイントを取っておくとともに、
    該トークンを所有しているクライアントのリストを該記
    憶装置に記憶しておき、 その後、該現用のサーバが存在するノード装置のクラッ
    シュ時に、他のノード装置に存在する待機用のサーバ
    が、該記憶装置に記憶された上記クライアントのリスト
    に基づき該トークンを所有しているクライアントのみに
    該トークンに関する情報を問い合わせることにより、情
    報を収集し、この収集した情報に基づいて該待機用のサ
    ーバの内部状態をを再構築して、サーバの復旧を行なう
    ことを特徴とする、分散システムにおける資源管理用サ
    ーバの復旧方法。
  21. 【請求項２１】 該資源管理用サーバが存在するノード
    装置と異なるノード装置に故障管理用のサーバを設け、
    該資源管理用サーバが存在するノード装置のクラッシュ
    時に、該故障管理用のサーバが、該記憶装置に記憶され
    た上記クライアントのリストを基に該トークンを所有し
    ているクライアントがクラッシュしているか否かを判定
    し、この判定に基づいて該待機用のサーバが、該トーク
    ンを所有し、且つ、クラッシュしていないクライアント
    のみに該トークンに関する情報を問い合わせることを特
    徴とする請求項１９又は請求項２０記載の分散システム
    における資源管理用サーバの復旧方法。
  22. 【請求項２２】 該サーバによる復旧の際、該サーバか
    らの該トークンに関する情報の問い合わせを受けたクラ
    イアントが、通常運用時に行なう処理とは別に、この問
    い合わせに応答するための専用の処理を行なうことを特
    徴とする請求項１９又は請求項２０記載の分散システム
    における資源管理用サーバの復旧方法。
  23. 【請求項２３】 該サーバによる復旧の際、クライアン
    トに該トークンに関する情報を問い合わせた後、所定の
    時間を経過しても該クライアントからこの問い合わせに
    対する応答がなく該トークンに関する情報を収集するこ
    とができない場合には、応答があったクライアントのみ
    から該トークンに関する情報を収集することを特徴とす
    る請求項１９又は請求項２０記載の分散システムにおけ
    る資源管理用サーバの復旧方法。
  24. 【請求項２４】 該サーバによる復旧の際、該トークン
    を所有しているクライアントに該トークンに関する情報
    を問い合わせることにより情報を収集した後、該サーバ
    が管理する資源に関する情報と、過去に該トークンを所
    有することにより該資源を使用していたクライアント側
    での該資源に関する情報との新旧を比較し、この比較結
    果に基づき、該サーバ側で管理する該トークンに対応す
    る資源に関する情報を最新の情報に更新することを特徴
    とする請求項１９又は請求項２０記載の分散システムに
    おける資源管理用サーバの復旧方法。
JP04890295A 1994-08-19 1995-03-08 分散システムに使用されるクライアント，サーバ及び記憶装置並びに分散システムにおける資源管理用サーバの復旧方法 Expired - Fee Related JP3504763B2 (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
JP04890295A JP3504763B2 (ja) 1994-08-19 1995-03-08 分散システムに使用されるクライアント，サーバ及び記憶装置並びに分散システムにおける資源管理用サーバの復旧方法
US08/518,395 US5845082A (en) 1994-08-19 1995-08-15 Distributed system having an improved method and apparatus for checkpoint taking

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
JP6-195335 1994-08-19
JP19533594 1994-08-19
JP04890295A JP3504763B2 (ja) 1994-08-19 1995-03-08 分散システムに使用されるクライアント，サーバ及び記憶装置並びに分散システムにおける資源管理用サーバの復旧方法

Publications (2)

Publication Number Publication Date
JPH08110895A true JPH08110895A (ja) 1996-04-30
JP3504763B2 JP3504763B2 (ja) 2004-03-08

Family

ID=26389247

Family Applications (1)

Application Number Title Priority Date Filing Date
JP04890295A Expired - Fee Related JP3504763B2 (ja) 1994-08-19 1995-03-08 分散システムに使用されるクライアント，サーバ及び記憶装置並びに分散システムにおける資源管理用サーバの復旧方法

Country Status (2)

Country Link
US (1) US5845082A (ja)
JP (1) JP3504763B2 (ja)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR100358105B1 (ko) * 1999-12-24 2002-10-25 한국전자통신연구원 서버의 과부하 상태를 감안한 분산 공간 분석 시스템 및그 방법
JP2008226177A (ja) * 2007-03-15 2008-09-25 Fujitsu Ltd 分散処理プログラム、システムおよび方法

Families Citing this family (31)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6185702B1 (en) * 1997-01-24 2001-02-06 Kabushiki Kaisha Toshiba Method and system for process state management using checkpoints
JP3253883B2 (ja) * 1997-01-31 2002-02-04 株式会社東芝 プロセスリスタート方法及びプロセス監視装置
US6138251A (en) * 1997-06-30 2000-10-24 Sun Microsystems, Inc. Method and system for reliable remote object reference management
US6058424A (en) * 1997-11-17 2000-05-02 International Business Machines Corporation System and method for transferring a session from one application server to another without losing existing resources
JPH11203254A (ja) * 1998-01-14 1999-07-30 Nec Corp 共有プロセス制御装置及びプログラムを記録した機械読み取り可能な記録媒体
US6026414A (en) * 1998-03-05 2000-02-15 International Business Machines Corporation System including a proxy client to backup files in a distributed computing environment
US6195695B1 (en) * 1998-10-27 2001-02-27 International Business Machines Corporation Data processing system and method for recovering from system crashes
US7703131B1 (en) * 2000-03-01 2010-04-20 Microsoft Corporation Secured distributed impersonation
US6950820B2 (en) * 2001-02-23 2005-09-27 International Business Machines Corporation Maintaining consistency of a global resource in a distributed peer process environment
US7191357B2 (en) * 2002-03-29 2007-03-13 Panasas, Inc. Hybrid quorum/primary-backup fault-tolerance model
US7007047B2 (en) * 2002-03-29 2006-02-28 Panasas, Inc. Internally consistent file system image in distributed object-based data storage
US7010576B2 (en) * 2002-05-30 2006-03-07 International Business Machines Corporation Efficient method of globalization and synchronization of distributed resources in distributed peer data processing environments
US7121456B2 (en) * 2002-09-13 2006-10-17 Visa U.S.A. Inc. Method and system for managing token image replacement
US8051172B2 (en) * 2002-09-30 2011-11-01 Sampson Scott E Methods for managing the exchange of communication tokens
JP4271967B2 (ja) * 2003-03-10 2009-06-03 株式会社日立製作所 分散ファイルシステム及び分散ファイルシステムの運用方法
US20050086568A1 (en) * 2003-09-18 2005-04-21 Goul Kenneth M. System and method of fault detection and recovery in commercial process flow
US9213609B2 (en) * 2003-12-16 2015-12-15 Hewlett-Packard Development Company, L.P. Persistent memory device for backup process checkpoint states
US20050216552A1 (en) * 2004-03-24 2005-09-29 Samuel Fineberg Communication-link-attached persistent memory system
US7499970B2 (en) * 2004-11-12 2009-03-03 International Business Machines Corporation Method and system for supervisor partitioning of client resources
US7392433B2 (en) * 2005-01-25 2008-06-24 International Business Machines Corporation Method and system for deciding when to checkpoint an application based on risk analysis
US7478278B2 (en) * 2005-04-14 2009-01-13 International Business Machines Corporation Template based parallel checkpointing in a massively parallel computer system
US7840969B2 (en) * 2006-04-28 2010-11-23 Netapp, Inc. System and method for management of jobs in a cluster environment
US7818610B2 (en) * 2007-09-27 2010-10-19 Microsoft Corporation Rapid crash recovery for flash storage
US8250088B2 (en) 2007-10-05 2012-08-21 Imation Corp. Methods for controlling remote archiving systems
US7933991B2 (en) * 2007-10-25 2011-04-26 International Business Machines Corporation Preservation of file locks during checkpoint and restart of a mobile software partition
US8305706B2 (en) 2008-07-11 2012-11-06 Imation Corp. Disk library system including array of removable disk cartridges and movable connector system
US8347304B2 (en) * 2009-02-26 2013-01-01 Lsi Corporation Resource allocation failure recovery module of a disk driver
US8473577B2 (en) * 2010-10-13 2013-06-25 Google Inc. Continuous application execution between multiple devices
US8713362B2 (en) 2010-12-01 2014-04-29 International Business Machines Corporation Obviation of recovery of data store consistency for application I/O errors
US8694821B2 (en) 2010-12-03 2014-04-08 International Business Machines Corporation Generation of standby images of applications
US10841148B2 (en) 2015-12-13 2020-11-17 Microsoft Technology Licensing, Llc. Disaster recovery of cloud resources

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4751702A (en) * 1986-02-10 1988-06-14 International Business Machines Corporation Improving availability of a restartable staged storage data base system that uses logging facilities
US4823261A (en) * 1986-11-24 1989-04-18 International Business Machines Corp. Multiprocessor system for updating status information through flip-flopping read version and write version of checkpoint data
US5454099A (en) * 1989-07-25 1995-09-26 International Business Machines Corporation CPU implemented method for backing up modified data sets in non-volatile store for recovery in the event of CPU failure
GB2246218B (en) * 1990-07-18 1994-02-09 Stc Plc Distributed data processing systems
US5129080A (en) * 1990-10-17 1992-07-07 International Business Machines Corporation Method and system increasing the operational availability of a system of computer programs operating in a distributed system of computers
US5668986A (en) * 1991-10-02 1997-09-16 International Business Machines Corporation Method and apparatus for handling data storage requests in a distributed data base environment
US5499367A (en) * 1991-11-15 1996-03-12 Oracle Corporation System for database integrity with multiple logs assigned to client subsets
US5590277A (en) * 1994-06-22 1996-12-31 Lucent Technologies Inc. Progressive retry method and apparatus for software failure recovery in multi-process message-passing applications
US5608865A (en) * 1995-03-14 1997-03-04 Network Integrity, Inc. Stand-in Computer file server providing fast recovery from computer file server failures

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR100358105B1 (ko) * 1999-12-24 2002-10-25 한국전자통신연구원 서버의 과부하 상태를 감안한 분산 공간 분석 시스템 및그 방법
JP2008226177A (ja) * 2007-03-15 2008-09-25 Fujitsu Ltd 分散処理プログラム、システムおよび方法
US8677363B2 (en) 2007-03-15 2014-03-18 Fujitsu Limited Method for managing, tracking and distributing job programs for processing to a plurality of execution computers

Also Published As

Publication number Publication date
JP3504763B2 (ja) 2004-03-08
US5845082A (en) 1998-12-01

Similar Documents

Publication Publication Date Title
JP3504763B2 (ja) 分散システムに使用されるクライアント，サーバ及び記憶装置並びに分散システムにおける資源管理用サーバの復旧方法
US7730489B1 (en) Horizontally scalable and reliable distributed transaction management in a clustered application server environment
US10360113B2 (en) Transaction recovery in a transaction processing computer system employing multiple transaction managers
US7103586B2 (en) Collision avoidance in database replication systems
US5201044A (en) Data processing method for file status recovery includes providing a log file of atomic transactions that may span both volatile and non volatile memory
KR101993432B1 (ko) 2-단계 커미트 호출들의 엄격한 순서화에 근거하여 트랜잭션 복구를 지원하는 시스템들 및 방법들
Mohan et al. Method for distributed transaction commit and recovery using byzantine agreement within clusters of processors
JPH06318164A (ja) 分布トランザクションを実行する方法および装置
JP2001518663A (ja) 高度に利用可能なクラスタ構成データベース
CN108958984B (zh) 基于ceph的双活同步在线热备方法
US20230110826A1 (en) Log execution method and apparatus, computer device and storage medium
CN110830582B (zh) 一种基于服务器集群选主方法和装置
US11522966B2 (en) Methods, devices and systems for non-disruptive upgrades to a replicated state machine in a distributed computing environment
US6948093B2 (en) Data processing arrangement and method
US6848037B2 (en) Data processing arrangement and method
US6192443B1 (en) Apparatus for fencing a member of a group of processes in a distributed processing environment
Little et al. Object replication in Arjuna
US6205510B1 (en) Method for fencing a member of a group of processes in a distributed processing environment
JPH07244604A (ja) データベースオンライン復旧方法および装置
Zhou et al. A system for managing remote procedure call transactions
Rusinkiewicz et al. RDS: a primitive for the maintenance of replicated data objects
Devarakonda et al. Server recovery using naturally replicated state: a case study
JPH08263350A (ja) 情報管理システム及び方法
CZ9904221A3 (cs) Způsob a systém pro obnovu v rozděleném databázovém systému bez sdílených prostředků pomocí virtuálních sdílených disků

Legal Events

Date Code Title Description
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20031202

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20031211

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20071219

Year of fee payment: 4

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20081219

Year of fee payment: 5

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20091219

Year of fee payment: 6

LAPS Cancellation because of no payment of annual fees