JP3708891B2 - フォールトトレラントシステムにおけるプロセスペア実行制御方法、プロセスペア実行制御プログラム、及びフォールトトレラントシステム - Google Patents
フォールトトレラントシステムにおけるプロセスペア実行制御方法、プロセスペア実行制御プログラム、及びフォールトトレラントシステム Download PDFInfo
- Publication number
- JP3708891B2 JP3708891B2 JP2002084321A JP2002084321A JP3708891B2 JP 3708891 B2 JP3708891 B2 JP 3708891B2 JP 2002084321 A JP2002084321 A JP 2002084321A JP 2002084321 A JP2002084321 A JP 2002084321A JP 3708891 B2 JP3708891 B2 JP 3708891B2
- Authority
- JP
- Japan
- Prior art keywords
- backup
- backup process
- state
- pair
- primary
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Landscapes
- Retry When Errors Occur (AREA)
- Hardware Redundancy (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明は、プロセスを実行している計算機に障害が発生した場合でも、他の計算機を利用して当該プロセスを継続して実行することを可能にするフォールトトレラント技術に係り、特にその技術をＣＡＤやシミュレーション等の科学技術計算プログラムに適用する場合に好適な、フォールトトレラントシステムにおけるプロセスペア実行制御方法、プロセスペア実行制御プログラム、及びフォールトトレラントシステムに関する。
【０００２】
【従来の技術】
プロセスを実行している計算機に障害が発生した場合でも、他の計算機を利用して当該プロセスを継続して実行することを可能にするフォールトトレラント技術の代表的な手法としてプロセスペア方式が知られている。
【０００３】
プロセスペア方式とは、プロセスをプライマリプロセスとバックアッププロセスの２つで構成し、両プロセスを異なる計算機上に配置する手法である。従来、このプロセスペア方式には以下に述べる第１及び第２の方式が存在する。
【０００４】
（１）第１の方式
第１の方式は、文献「”The Process Group Approach to Reliable Distributed Computing,” K.Birman, Technical Report, Computer Science Department, Cornel University, July 1991」（以下、第１の文献と称する）に記載されている。
【０００５】
この第１の文献では、プロセスペアはプロセスグループと呼ばれ、２個以上のプロセスによる処理の多重化を行っている。ここではプロセス数を２個に限定したプロセスペア方式の一形態として、第１の方式と称するものとする。
【０００６】
図９は第１の方式を説明するための図である。
図９に示されるように、第１の方式では、１つのプロセスはプライマリプロセスとバックアッププロセスからなるプロセスペア９１として構成される。プロセスペア９１が他のプロセスペア９２と通信を行う際には、プロセスペア間通信９３〜９６等が行われる。プロセスペア間通信では、送信側プライマリプロセスと送信側バックアッププロセスから、受信側プライマリプロセスと受信側バックアッププロセスに、メッセージを一貫性を保った状態で送受信する機能を提供する。
【０００７】
なお、メッセージを一貫性を保った状態で送受信するという意味は、プライマリプロセスとバックアッププロセスが共に、メッセージを１つのみ送信または受信するということである。逆に言えば、プライマリプロセスのみメッセージを受信して、バックアッププロセスがメッセージを受信していない等の状態にならないことを示す。
【０００８】
第１の方式では、図９中のｆａｕｌｔ１、或いはｆａｕｌｔ２で示される時点で、プライマリプロセスが実行されている計算機に障害が発生しても、他の計算機で実行されているバックアッププロセスが処理を継続し、プライマリプロセスの役割を代替する。これにより、プロセスペア９１としては処理を継続することができる。
【０００９】
図９に示した第１の方式では、全く同じ処理を２つのプロセス（プライマリプロセス及びバックアッププロセス）で実行するため、ＣＰＵリソースを２倍必要とする。
【００１０】
（２）第２の方式
第２の方式は、文献「”フォールト・トレラント・システム”、グレイ他著、渡辺榮一編訳、マグロウヒル出版」（以下、第２の文献と称する）に記載されている。この第２の文献では、プロセスペアは、そのままプロセスペアと呼ばれている。
【００１１】
図１０は第２の方式を説明するための図である。
図１０に示されるように、第２の方式では、１つのプロセスはプライマリプロセスとバックアッププロセスからなるプロセスペア１０１として構成される。プロセスペア１０１が他のプロセスペア１０２と通信を行う際には、プロセスペア間通信が行われる。
【００１２】
プロセスペア間通信では、送信側プライマリプロセスと送信側バックアッププロセスから、受信側プライマリプロセスと受信側バックアッププロセスに、メッセージを一貫性を保った状態で送受信する機能を提供する。
【００１３】
上記第１の方式では、バックアッププロセスも、プライマリプロセスと同じ処理を実行している。しかし、第２の方式では、バックアッププロセスは、プロセスとしては存在するが実際の処理は実行しないで、チェックポイント採取時（ｃｋｐ１，ｃｋｐ２，ｃｋｐ３，ｃｋｐ４）に、プライマリプロセスの状態をバックアッププロセスにコピーする。
【００１４】
第２の方式では、図１０中のｆａｕｌｔ１、或いはｆａｕｌｔ２で示される時点で、プライマリプロセスが実行されている計算機に障害が発生した場合、他の計算機上のバックアッププロセスが、各々ｒｅｓｔａｒｔ１、或いはｒｅｓｔａｒｔ２で示される最後に採取されたチェックポイントの時点から処理を再開し、プライマリプロセスの役割を代替する。このため、プロセスペアとしては処理を継続することができる。
【００１５】
第２の方式では、上記第１の方式とは異なって、全く同じ処理をプライマリプロセス及びバックアッププロセスの２つのプロセスで実行するわけではない。このため第２の方式では、ＣＰＵリソースを２倍必要とするということはない。
【００１６】
【発明が解決しようとする課題】
上記した、プロセスペア方式と呼ばれる従来のフォールトトレラント技術、例えば第１の方式では、プライマリプロセスが実行されている計算機に障害が発生しても、他の計算機で実行されているバックアッププロセスが処理を継続し、プライマリプロセスの役割を代替することで、プロセスペアとしては処理を継続することができる。ところが、第１の方式では、全く同じ処理を２つのプロセス（プライマリプロセス及びバックアッププロセス）で実行するため、ＣＰＵリソースを２倍必要とするという問題がある。
【００１７】
これに対し、上記第２の方式では、第１の方式とは異なって、全く同じ処理を２つのプロセスで実行するわけではなく、したがってＣＰＵリソースを２倍必要とせずに済む。ところが第２の方式には、以下に述べる別の問題がある。
【００１８】
まず、第２の方式では、実際には実行していないバックアッププロセス、つまりプライマリプロセス側で障害が発生しない限り定常的に停止状態にあるバックアッププロセスを、チェックポイント採取時から再開するために、プライマリプロセスの状態をバックアッププロセスにコピーする。アドレス空間やコンテクストは、これで問題ない。
【００１９】
しかしながら第２の方式は、バックアッププロセスが定常的に停止状態にあることから、単にプライマリプロセスの状態をバックアッププロセスにコピーするだけでは、システムコールの実行によって、ＯＳ（オペレーティングシステム）から受けているサービスの状態を復元できない。このＯＳから受けているサービスの状態とは、例えば、どのファイルを、どのディスクリプタでオープンしているか、そのシークポインタ等の状態である。そこで、第２の方式では、このようなＯＳから受けているサービスの状態を、保存・復元できるような機能を持った独自のＯＳを採用している。
【００２０】
このため、第２の方式では、産業界で広く利用されているオープンシステムを利用することができず、全てのアプリケーションを独自に開発する必要があり、生産性が低くなるという問題がある。
【００２１】
本発明は上記事情を考慮してなされたものでその目的は、障害発生時にも処理を継続することを可能としながら、ＣＰＵリソースを２倍必要とせずに済み、且つオープンシステムを利用できるフォールトトレラントシステムにおけるプロセスペア実行制御方法、プロセスペア実行制御プログラム、及びフォールトトレラントシステムを提供することにある。
【００２２】
【課題を解決するための手段】
本発明の１つの観点によれば、障害発生時にも処理を継続することが可能な、プライマリプロセスとバックアッププロセスから構成されるプロセスペアが実行されるフォールトトレラントシステムにおけるプロセスペア実行制御方法が提供される。このプロセスペア実行制御方法は、プロセスペアの起動時にはプライマリプロセス及びバックアッププロセスを共に実行状態にするステップと、チェックポイント採取時期が到来する毎に、プライマリプロセスの状態をバックアッププロセスにコピーするステップと、チェックポイント採取時にバックアッププロセスが実行状態にあるならば、当該バックアッププロセスを停止状態にするステップと、プロセスペアからシステムコールが発行された場合に、バックアッププロセスが停止状態にあるならば、当該バックアッププロセスを最も最近に採取されたチェックポイント（最後のチェックポイント）から再開させて実行状態にするステップとから構成される。
【００２３】
本発明の第１の観点に係るプロセスペア実行制御方法においては、プログラム（プロセスペア）の起動直後の期間は、プライマリプロセス及びバックアッププロセスが共に実行状態となって動作する。このため両プロセスは、ＯＳからのサービス提供を受けている状態となる。その後は、最初のチェックポイント採取時期の到来によりバックアッププロセスが停止状態となり、バックアッププロセス側でのＣＰＵリソースの消費が抑えられる。また、バックアッププロセスが停止状態にあるときにシステムコールが発行されると、バックアッププロセスは最後のチェックポイントから処理を再開する。つまり、バックアッププロセスも実行状態となって動作し、プライマリプロセス及びバックアッププロセスは再びＯＳからのサービス提供を受けている状態となる。
【００２４】
このように、本発明の第１の観点に係るプロセスペア実行制御方法において、バックアッププロセスは、従来の技術の欄で述べた第２の方式と異なって、プログラムの起動直後の期間と、その後バックアッププロセスが停止状態にあるときにシステムコールが発行された場合には実行状態となる。一方、プライマリプロセスは上記第２の方式と同様に、障害が発生しない限りはプログラムが終了するまで実行状態にある。つまり、第１の観点に係るプロセスペア実行制御方法では、従来の技術の欄で述べた第１の方式と異なって、プライマリプロセス及びバックアッププロセスが全く同じ処理を常に実行するわけでもなく、また第２の方式と異なって、バックアッププロセスが定常的に停止状態にあるわけでもなく、両プロセスが共に実行状態にある期間が存在する。この期間中、両プロセスはＯＳからのサービス提供を受けている状態となる。
【００２５】
このため、本発明の第１の観点に係るプロセスペア実行制御方法においては、上記第２の方式のように、ＯＳから受けているサービスの状態を、保存・復元できるような機能を持った独自のＯＳを採用する必要がなく、産業界で広く利用されているオープンシステムを利用することが可能となる。また、バックアッププロセスが停止状態にある期間が存在するため、ＣＰＵリソースを２倍必要とせずに済む。また、本発明の第１の観点に係るプロセスペア実行制御方法は、以下の理由により、ＣＡＤやシミュレーション等の科学技術計算プログラムに特に適している。即ち、この種の科学技術計算プログラムでは、最初にシステムコールの発行を伴う入力データの読み出し等を行い、その後はシステムコールを発行せずに、ＣＰＵ演算を繰り返すことが多く、しかもＣＰＵ演算が行われる期間は、システムコールの発行を伴う期間に比べて著しく長い。このため、上記第１の観点に係るプロセスペア実行制御方法において、プログラムの起動直後と、それ以降はシステムコールの発行を伴う期間だけプライマリプロセス及びバックアッププロセスを共に実行状態にし、それ以外の長時間行われるＣＰＵ演算の期間はバックアッププロセスを停止状態にすることにより、ＣＰＵリソースがバックアッププロセスの実行に用いられる時間を大幅に短縮すると共に、汎用的なＯＳを使用しても当該ＯＳから受けているサービスの状態を保存・復元するのを可能とする。
【００２６】
ここで、プライマリプロセス側での障害発生時に、バックアッププロセスが停止状態にあるならば、当該バックアッププロセスを最も最近に採取されたチェックポイントから再開させて実行状態にするステップを追加するならば、たとえバックアッププロセスが停止状態にある期間にプライマリプロセス側で障害が発生しても、バックアッププロセスにより処理を継続することが可能となる。
【００２７】
また、バックアッププロセスを停止状態から実行状態に切り換えることが必要となる直前のタイミング、例えばプライマリプロセスからシステムコールが発行される直前のタイミングにチェックポイント採取時期（第１のチェックポイント採取時期）を設定するステップを追加するならば、その後プライマリプロセスから実際にシステムコールが発行されてバックアッププロセスを再開した場合に、その再開後の処理に要する時間を短縮できる。
【００２８】
また、バックアッププロセスを実行状態に維持しておく必要がなくなる直後のタイミングにチェックポイント採取時期（第２のチェックポイント採取時期）を設定するステップを追加するならば、バックアッププロセスが実行状態にある期間を必要最小限に抑えて、バックアッププロセスの実行に必要なＣＰＵリソースが余分に使用されるのを防ぐことができる。
【００２９】
また、上記第１のチェックポイント採取時期から次の上記第２のチェックポイント採取時期のまでの期間を除く、バックアッププロセスが停止状態にある期間、予め定められた時間間隔でチェックポイント採取時期（第３のチェックポイント採取時期）を設定するステップを追加するなら、プライマリプロセス及びバックアッププロセスが共に実行状態にある期間にチェックポイント採取動作が行われて、その都度バックアッププロセスが停止されて、その後のプライマリプロセスでのシステムコールにより当該バックアッププロセスが最後のチェックポイントから再開されるという、処理を遅延させる無駄な動作が発生するのを防止できる。これにより、処理効率の向上と、チェックポイントの効率的な採取とが可能となる。
【００３０】
なお、以上のプロセスペア実行制御方法に係る本発明は、当該方法を構成する各ステップを計算機に実行させるためのプログラム（プロセスペア実行制御プログラム）に係る発明としても、当該方法を実行するフォールトトレラントシステムに係る発明としても成立する。
【００３１】
【発明の実施の形態】
以下、本発明の実施の形態につき図面を参照して説明する。
【００３２】
図１は本発明の一実施形態に係るフォールトトレラントシステムの構成を示すブロック図である。
図１において、計算機１ａ及び１ｂは、ネットワーク２により相互接続されている。計算機１ａ（の図示せぬ記憶装置）上にはプライマリプロセス１１が配置され、計算機１ｂ上（の図示せぬ記憶装置）にはバックアッププロセス１２が配置されている。つまり計算機１ａ及び１ｂの組により、障害発生時にも処理を継続することが可能な、プライマリプロセス１１とバックアッププロセス１２から構成されるプロセスペア１３が実現されている。
【００３３】
計算機１ａ及び１ｂは、いずれも、プロセスペア間通信部１４、チェックポイント採取部１５、プロセスリスタート部１６、バックアッププロセス実行状態制御部１７、バックアッププロセス実行状態管理部１８、及びプロセス発行システムコール検知部１９の各機能要素を有している。これら各部１４〜１９は、プライマリプロセス１１またはバックアッププロセス１２から利用される関数プログラム等を格納したライブラリ２０によって実現される。
【００３４】
図２は、上記プライマリプロセス１１及びバックアッププロセス１２から構成されるプロセスペア１３と、上記ライブラリ２０により実現される上記各部１４〜１９との関係を示す機能ブロック構成図である。
【００３５】
プロセスペア間通信部１４は、計算機１ａ及び１ｂ上のプライマリプロセス１１及びバックアッププロセス１２から構成されるプロセスペア１３と他のプロセスペアとの間の通信を行う。プロセスペア間通信部１４は、プライマリプロセス１１及びバックアッププロセス１２が共に生存（存在）している場合、両プロセスを調停して、１つのメッセージのみを他のプロセスペアに送る。逆に他のプロセスペアからメッセージが送られてきた場合、プロセスペア間通信部１４は、プライマリプロセス１１とバックアッププロセス１２が共に生存している場合には、当該メッセージを両プロセスに送る。
【００３６】
チェックポイント採取部１５は、チェックポイント採取時期が到来すると起動される。ここでは、チェックポイント採取部１５は、プライマリプロセス１１からのシステムコールによるチェックポイント採取のための指示（チェックポイント採取指示）Ａ、またはタイマＴＭからの定期的な割り込み（チェックポイント採取割り込み）Ｂにより起動される。チェックポイント採取部１５は、バックアッププロセス実行状態管理部１８によって管理されているプライマリプロセス１１の状態から、当該プライマリプロセス１１が生存していることが判別される場合に、当該プライマリプロセス１１に指示Ｃを出して当該プライマリプロセス１１の状態の読み出しＤを行い、バックアッププロセス１２へのコピーＥを実行するチェックポイント採取動作を行う機能を有する。なお、ここでいうプロセスの状態とは、アドレス空間とコンテクストのことである。
【００３７】
チェックポイント採取部１５はまた、バックアッププロセス実行状態管理部１８を利用してバックアッププロセス１２の状態（実行状態または停止状態）を調べ、実行状態ならば、バックアッププロセス実行状態制御部１７にバックアッププロセス１２の実行を停止させる指示Ｆを出す。
【００３８】
プロセスリスタート部１６は、プライマリプロセス１１を実行している計算機の障害を検知した場合に、バックアッププロセス実行状態管理部１７を利用してバックアッププロセス１２の状態を調べ、停止状態ならば、バックアッププロセス実行状態制御部１７に対してバックアッププロセス１２の実行を開始させる指示Ｈを出す。
【００３９】
バックアッププロセス実行状態制御部１７は、プライマリプロセス１１及びバックアッププロセス１２から構成されるプロセスペア１３の起動時（プログラムの実行開始時）に、当該プライマリプロセス１１及びバックアッププロセス１２を共に実行状態として、バックアッププロセス実行状態管理部１８に登録する機能を有する。バックアッププロセス実行状態制御部１７はまた、チェックポイント採取部１５からの指示Ｆを受けて、バックアッププロセス１２を停止させ、その状態を停止状態として、バックアッププロセス実行状態管理部１８に登録する機能を有する。バックアッププロセス実行状態制御部１７はまた、プロセスリスタート部１６からの指示Ｈまたはプロセス発行システムコール検知部１９からの後述する指示Ｇを受けて、バックアッププロセス１２を実行させ、その状態を実行状態として、バックアッププロセス実行状態管理部１８に登録する機能をも有する。
【００４０】
バックアッププロセス実行状態管理部１８は、バックアッププロセス１２の状態を保持・管理する。
【００４１】
プロセス発行システムコール検知部１９は、プロセスペア１３（を構成するプライマリプロセス１１またはバックアッププロセス１２）がシステムコールを実行（発行）したことを検知する。またプロセス発行システムコール検知部１９は、プライマリプロセス１１がシステムコールを実行したことを検知した場合、バックアッププロセス実行状態管理部１８を利用してバックアッププロセス１２の状態を調べる。プロセス発行システムコール検知部１９は、バックアッププロセス１２が停止状態ならば、バックアッププロセス実行状態制御部１７に対してバックアッププロセス１２の実行を開始させる指示Ｇを出す。
【００４２】
計算機１ａ及び計算機１ｂ上の、それぞれプロセスペア間通信部１４同士、チェックポイント採取部１５同士、プロセスリスタート部１６同士、バックアッププロセス実行状態制御部１７同士、バックアッププロセス実行状態管理部１８同士、そしてプロセス発行システムコール検知部１９同士は、互いにネットワーク２を介して通信をすことで、あたかも１つであるかのように動作する。
【００４３】
図３は状態遷移図であり、同図（ａ）はプライマリプロセス１１の取り得る状態を示す状態遷移図、同図（ｂ）はバックアッププロセス１２の取り得る状態を示す状態遷移図である。
【００４４】
まずプライマリプロセス１１は、図３（ａ）に示すように、停止状態及び実行状態のいずれかの状態を取る。プライマリプロセス１１は、プログラム実行開始ａ１と共に停止状態から実行状態に遷移する。プライマリプロセス１１は、プログラム実行終了ａ２となるまで、実行状態を保つ。
【００４５】
次にバックアッププロセス１２も、図３（ｂ）に示すように、停止状態及び実行状態のいずれかの状態を取る。バックアッププロセス１２は、プログラム実行開始ｂ１と共に停止状態から実行状態に遷移する。バックアッププロセス１２は、実行状態において、チェックポイント採取ｂ２が実行されると、停止状態に遷移する。また、バックアッププロセス１２は、停止状態において、プライマリプロセス１１でのシステムコール発行ｂ３が行われると、実行状態に遷移する。
【００４６】
次に、本実施形態の動作を、図４乃至図８を適宜参照して説明する。なお、図４はプロセスペア１３を構成するプライマリプロセス１１及びバックアッププロセス１２の全体の動作を説明するためのタイミングチャート、図５はチェックポイント採取部１５の動作を説明するためのフローチャート、図６はプロセスリスタート部１６の動作を説明するためのフローチャート、図７はプロセス発行システムコール検知部１９の動作を説明するためのフローチャート、図８はプライマリプロセス１１及びバックアッププロセス１２の状態とチェックポイント採取時期との関係を説明するためのタイミングチャートである。
【００４７】
まず、プロセス開始直後、つまりプログラム実行開始ａ１，ｂ１直後は、計算機１ａ上のプライマリプロセス１１及び計算機１ｂ上のバックアッププロセス１２は、図３に示すように共に停止状態から実行状態に遷移する。
【００４８】
今、プライマリプロセス１１及びバックアッププロセス１２が実行状態にあるときに、例えば図４中のｃｋｐ１の時点で、プライマリプロセス１１からチェックポイント採取部１５にチェックポイント採取のシステムコールＡが発行されたものとする。
【００４９】
この場合、チェックポイント採取部１５は起動され、バックアッププロセス実行状態管理部１８に対して、当該管理部１８により管理されているプライマリプロセス１１及びバックアッププロセス１２の状態を問い合わせ、両プロセスが共に生存しているか否かを判定する（ステップＳ１）。もし、プライマリプロセス１１及びバックアッププロセス１２の少なくとも一方が生存していないならば、チェックポイント採取部１５はそのまま動作を終了する。
【００５０】
これに対し、プライマリプロセス１１及びバックアッププロセス１２が共に生存しているならば、チェックポイント採取部１５はプライマリプロセス１１に指示Ｃを出して当該プライマリプロセス１１の状態を読み出す動作Ｄを実行し、読み出した状態をバックアッププロセス１２にコピーする動作Ｅを実行する（ステップＳ２）。
【００５１】
チェックポイント採取部１５は、ステップＳ２の処理（チェックポイント採取動作）を実行すると、バックアッププロセス実行状態管理部１８に対してバックアッププロセス１２の状態を問い合わせ、当該バックアッププロセス１２が実行状態にあるか否かを判定する（ステップＳ３）。もし、バックアッププロセス１２が停止状態にあるなら、チェックポイント採取部１５はそのまま動作を終了する。これに対し、バックアッププロセス１２が実行状態にあるならば、チェックポイント採取部１５はバックアッププロセス実行状態制御部１７に対して指示Ｆを出すことで、当該バックアッププロセス１２を実行状態から停止状態に遷移させる（ステップＳ４）。このバックアッププロセス１２の新たな状態（停止状態）は、バックアッププロセス実行状態制御部１７によりバックアッププロセス実行状態管理部１８に登録される。
【００５２】
図４の例では、ｃｋｐ１の後も、例えばタイマＴＭからの定期的な割り込みＢのタイミングで決まるｃｋｐ２，ｃｋｐ３，ｃｋｐ４の時点で、チェックポイントが採られる。このとき、バックアッププロセス１２は、上記の説明から明らかなように停止状態のままである。
【００５３】
その後、例えばプライマリプロセス１１での処理に伴う出力データの書き出し等のために、当該プライマリプロセス１１が図４に示す送信（ｓｅｎｄ）処理４１を行うものとする。この送信（ｓｅｎｄ）処理４１はシステムコールであるものとする。この場合、プロセス発行システムコール検知部１９は、上記システムコール（送信処理）を検知する。するとプロセス発行システムコール検知部１９は、バックアッププロセス実行状態管理部１８に対してプライマリプロセス１１及びバックアッププロセス１２の状態を問い合わせ、両プロセスが共に生存しているか否かを判定する（ステップＳ２１）。もし、プライマリプロセス１１及びバックアッププロセス１２の少なくとも一方が生存していないならば、プロセス発行システムコール検知部１９はそのまま動作を終了する。
【００５４】
これに対し、プライマリプロセス１１及びバックアッププロセス１２が共に生存しているならば、プロセス発行システムコール検知部１９はバックアッププロセス実行状態管理部１８を用いてバックアッププロセス１２が実行状態にあるか否かを判定する（ステップＳ２２）。
【００５５】
もし、バックアッププロセス１２が実行状態にないならば、つまりバックアッププロセス１２が停止状態にあるならば、プロセス発行システムコール検知部１９はバックアッププロセス実行状態制御部１７に対して指示Ｇを出して当該バックアッププロセス１２を実行状態に遷移させ、その時点を基準に、最後（最も最近）に採ったチェックポイントから当該バックアッププロセス１２をリスタートさせる（ステップＳ２３）。図４の例では、送信（ｓｅｎｄ）処理４１のタイミングからみて、最後に採られたチェックポイントはｃｋｐ４である。この場合、バックアッププロセス１２はチェックポイントｃｋｐ４から処理を再開する。
【００５６】
プロセス発行システムコール検知部１９は、バックアッププロセス１２が停止状態にある場合（ステップＳ２２のＮＯ）には、上述のように当該バックアッププロセス１２を実行状態にしてリスタートさせた後（ステップＳ２３）に、ステップＳ２４に進む。またプロセス発行システムコール検知部１９は、バックアッププロセス１２が既に実行状態にある場合には（ステップＳ２２のＹＥＳ）、そのままステップＳ２４に進む。プロセス発行システムコール検知部１９は、ステップＳ２４において、プライマリプロセス１１とバックアッププロセス１２とを同期させて動作を終了する。つまりバックアッププロセス１２は、リスタート後に送信（ｓｅｎｄ）処理４１を行ったところで、プロセスペア間通信部１４によって同期させられる。
【００５７】
次に、プライマリプロセス１１を実行している計算機１ａに障害が発生し、当該プライマリプロセス１１が停止したものとする。また、この計算機１ａの障害が図４中のｆａｕｌｔ１の時点で発生したものとする。この計算機１ａの障害はプロセスリスタート部１６により検出される。
【００５８】
プロセスリスタート部１６は、計算機の障害を検知した場合、その障害発生計算機がバックアッププロセス１２側の計算機であるか否かを判定する（ステップＳ１１）。もし、バックアッププロセス１２側の計算機、つまり計算機１ｂでの障害発生の場合には、計算機１ａ上のプライマリプロセス１１は実行可能であることから、プロセスリスタート部１６はそのまま動作を終了する。
【００５９】
これに対し、プライマリプロセス１１側の計算機、つまり計算機１ａでの障害発生の場合は、プロセスリスタート部１６はバックアッププロセス実行状態管理部１８に対してバックアッププロセス１２の状態を問い合わせ、当該バックアッププロセス１２が生存していて且つ停止状態にあるか否かを判定する（ステップＳ１２，Ｓ１３）。もし、バックアッププロセス１２が生存していない場合、或いは生存していても実行状態にある場合には、プロセスリスタート部１６はそのまま動作を終了する。
【００６０】
これに対し、バックアッププロセス１２が生存していて且つ停止状態にある場合には、プロセスリスタート部１６はバックアッププロセス実行状態制御部１７に対して指示Ｈを出して当該バックアッププロセス１２を実行状態に遷移させ、その時点、つまりｆａｕｌｔ１の時点を基準に、最後に採ったチェックポイント（ここでは、図４から明らかなようにｃｋｐ２）から当該バックアッププロセス１２をリスタートさせる（ステップＳ１４）。これによりバックアッププロセス１２は、図４の例では、ｒｅｓｔａｒｔ１の時点であるチェックポイントｃｋｐ２から処理を再開する。
【００６１】
一般にＣＡＤやシミュレーション等の科学技術計算プログラムでは、最初にシステムコールの発行を伴う入力データの読み出し等を行い、その後はシステムコールを発行せずに、ＣＰＵ演算を繰り返すことが多い。そして長時間のＣＰＵ演算が終わった最後に、システムコールの発行を伴う出力データの書き出し等が行われる。このシステムコールの発行を伴う期間だけ、バックアッププロセス１２も実行状態とするならば、システムコールを発行せずに、ＣＰＵ演算を繰り返す期間、プライマリプロセス１１だけを実行させても、ＯＳから受けているサービスの状態を保存・復元するのに独自のＯＳを採用する必要がなく、産業界で広く利用されているオープンシステムを利用することができる。
【００６２】
ここで、図１のフォールトトレラントシステムを、上述の科学技術計算プログラムの実行に適用するものとする。この場合、例えば図８に示すように、科学技術計算プログラムの起動直後、つまりプライマリプロセス１１及びバックアッププロセス１２から構成されるプロセスペア１３の起動直後、入力データ読み出し８１等でシステムコールを発行する最初の期間は、プライマリプロセス１１及びバックアッププロセス１２は共に動作して、ＯＳからのサービス提供を受けている状態（実行状態）となる。
【００６３】
その後の長時間のＣＰＵ演算の間は、最初のチェックポイントｃｋｐ１の時点以降、先のチェックポイント採取部１５の動作から明らかなように、バックアッププロセス１２は停止状態となる。このため、長時間のＣＰＵ演算の間、バックアッププロセス１２側では科学技術計算プログラムの実行のためにＣＰＵリソースを消費しない。そして最後に出力データの書き出し８２等でシステムコールを発行する間は、再びプライマリプロセス１１及びバックアッププロセス１２が共に動作して、ＯＳからのサービス提供を受けている状態になる。
【００６４】
さて、本実施形態では、プロセス発行システムコール検知部１９がプライマリプロセス１１でのシステムコールの発行を検知して、最後に採ったチェックポイントから自動的にバックアッププロセス１２を再開させ、システムコールを処理させている。この場合、もし最後にチェックポイントを採ってから長時間が経過していると、再開後の処理に時間がかかる。
【００６５】
そこで本実施形態では、プログラム中で明示的にチェックポイント採取を指示し、最後にチェックポイントを採った後長時間が経過してから、システムコールが実行されるのを防ぐようにしている。図８の例では、チェックポイントｃｋｐ５及びｃｋｐ１０が、これに相当し、プライマリプロセス１１からのシステムコールによる指示Ａにより、チェックポイント採取部１５に対して指定される。一方、図８中のチェックポイントｃｋｐ１，ｃｋｐ２，ｃｋｐ３，ｃｋｐ４及びｃｋｐ７，ｃｋｐ８，ｃｋｐ９は、バックアッププロセス１２が停止状態にある期間、タイマＴＭからの定期的な割り込みＢによって指定される。
【００６６】
ところで、既に説明したように、バックアッププロセス１２が実行状態にある期間に、チェックポイントの採取時期が到来すると、当該バックアッププロセス１２は停止状態となる。この状態でシステムコールが実行されると、その時点を基準に最後に採ったチェックポイントからバックアッププロセス１２を再開させる必要がある。このため、システムコールを繰り返す必要のある期間に、チェックポイントの採取時期が到来するのは処理効率の点で好ましくない。
【００６７】
そこで、チェックポイント採取部１５がタイマＴＭからの定期的な割り込みＢにより起動される期間を、バックアッププロセス１２が停止状態にある期間に限定し、バックアッププロセス１２が実行状態にある期間における当該割り込みＢは、チェックポイント採取部１５にて無視（無効扱い）される構成とするとよい。また、プライマリプロセス１１からのシステムコールによるチェックポイント採取の指示Ａは、チェックポイント採取部１５にて常に有効として処理される構成とする。
【００６８】
更に、システムコールを繰り返す必要のある期間の終了直後、つまりバックアッププロセス１２を実行状態に維持しておく必要がなくなる直後でも、プログラム中で明示的にチェックポイント採取を指示するとよい。このようにすると、システムコールを繰り返す必要のある期間の終了直後にバックアッププロセス１２は停止状態となり、以降タイマＴＭからの定期的な割り込みＢによるチェックポイント採取の指示が可能となる。この結果、効率よくチェックポイントを採るようにすることができる。図８の例では、ｃｋｐ６が、システムコールを繰り返す必要のある期間の終了直後となるように、プログラム中で明示的に指示されたチェックポイントである。
【００６９】
また、同様に、バックアッププロセス１２を実行状態にすることを、プログラム中で明示することもできる。
【００７０】
このように本実施形態においては、障害発生時における処理の継続を可能としながら、（１）ＣＰＵリソースを２倍使うことなく、（２）オープンシステムに適用可能な、プロセスペア方式によるフォールトトレラントシステムが実現できる。
【００７１】
上記実施形態では、プロセスペア１３を構成するプライマリプロセス１１及びバックアッププロセス１２を、それぞれ異なる計算機１ａ及び１ｂ上で動作させている。しかし、プログラム上の障害だけを考慮すればよいフォールトトレラントシステムでは、プライマリプロセス１１及びバックアッププロセス１２を同一計算機上で動作させるようにしてもよい。但し、プライマリプロセス１１及びバックアッププロセス１２が動作する唯一の計算機自体の障害が発生した場合には、処理を継続することはできない。
【００７２】
なお、本発明は、上記実施形態に限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で種々に変形することが可能である。更に、上記実施形態には種々の段階の発明が含まれており、開示される複数の構成要件における適宜な組み合わせにより種々の発明が抽出され得る。例えば、実施形態に示される全構成要件から幾つかの構成要件が削除されても、発明が解決しようとする課題の欄で述べた課題が解決でき、発明の効果の欄で述べられている効果が得られる場合には、この構成要件が削除された構成が発明として抽出され得る。
【００７３】
【発明の効果】
以上詳述したように本発明によれば、バックアッププロセスを、プログラムの起動直後の期間と、その後当該バックアッププロセスが停止状態にあるときにシステムコールが発行された場合に実行状態にする一方、チェックポイント採取時に当該バックアッププロセスが実行状態にあるならば、当該バックアッププロセスを停止状態にするようにしたので、障害発生時にも処理を継続することを可能としながら、ＣＰＵリソースを２倍必要とせずに済み、しかも独自のＯＳを採用することなくＯＳから受けているサービスの状態を保存・復元できるため、オープンシステムを利用できる。
【図面の簡単な説明】
【図１】本発明の一実施形態に係るフォールトトレラントシステムの構成を示すブロック図。
【図２】図１中のプライマリプロセス１１及びバックアッププロセス１２から構成されるプロセスペア１３と、ライブラリ２０により実現される各機能要素との関係を示す機能ブロック構成図。
【図３】プライマリプロセス１１及びバックアッププロセス１２の取り得る状態を示す状態遷移図。
【図４】同実施形態におけるプロセスペア１３を構成するプライマリプロセス１１及びバックアッププロセス１２の全体の動作を説明するためのタイミングチャート。
【図５】同実施形態におけるチェックポイント採取部１５の動作を説明するためのフローチャート。
【図６】同実施形態におけるプロセスリスタート部１６の動作を説明するためのフローチャート。
【図７】同実施形態におけるプロセス発行システムコール検知部１９の動作を説明するためのフローチャート。
【図８】同実施形態におけるプライマリプロセス１１及びバックアッププロセス１２の状態とチェックポイント採取時期との関係を説明するためのタイミングチャート。
【図９】従来のプロセスペアの第１の方式を説明するための図。
【図１０】従来のプロセスペアの第２の方式を説明するための図。
【符号の説明】
１ａ，１ｂ…計算機
２…ネットワーク
１１…プライマリプロセス
１２…バックアッププロセス
１３…プロセスペア
１４…プロセスペア間通信部
１５…チェックポイント採取部
１６…プロセスリスタート部
１７…バックアッププロセス実行状態制御部
１８…バックアッププロセス実行状態管理部
１９…プロセス発行システムコール検知部
２０…ライブラリ
【発明の属する技術分野】
本発明は、プロセスを実行している計算機に障害が発生した場合でも、他の計算機を利用して当該プロセスを継続して実行することを可能にするフォールトトレラント技術に係り、特にその技術をＣＡＤやシミュレーション等の科学技術計算プログラムに適用する場合に好適な、フォールトトレラントシステムにおけるプロセスペア実行制御方法、プロセスペア実行制御プログラム、及びフォールトトレラントシステムに関する。
【０００２】
【従来の技術】
プロセスを実行している計算機に障害が発生した場合でも、他の計算機を利用して当該プロセスを継続して実行することを可能にするフォールトトレラント技術の代表的な手法としてプロセスペア方式が知られている。
【０００３】
プロセスペア方式とは、プロセスをプライマリプロセスとバックアッププロセスの２つで構成し、両プロセスを異なる計算機上に配置する手法である。従来、このプロセスペア方式には以下に述べる第１及び第２の方式が存在する。
【０００４】
（１）第１の方式
第１の方式は、文献「”The Process Group Approach to Reliable Distributed Computing,” K.Birman, Technical Report, Computer Science Department, Cornel University, July 1991」（以下、第１の文献と称する）に記載されている。
【０００５】
この第１の文献では、プロセスペアはプロセスグループと呼ばれ、２個以上のプロセスによる処理の多重化を行っている。ここではプロセス数を２個に限定したプロセスペア方式の一形態として、第１の方式と称するものとする。
【０００６】
図９は第１の方式を説明するための図である。
図９に示されるように、第１の方式では、１つのプロセスはプライマリプロセスとバックアッププロセスからなるプロセスペア９１として構成される。プロセスペア９１が他のプロセスペア９２と通信を行う際には、プロセスペア間通信９３〜９６等が行われる。プロセスペア間通信では、送信側プライマリプロセスと送信側バックアッププロセスから、受信側プライマリプロセスと受信側バックアッププロセスに、メッセージを一貫性を保った状態で送受信する機能を提供する。
【０００７】
なお、メッセージを一貫性を保った状態で送受信するという意味は、プライマリプロセスとバックアッププロセスが共に、メッセージを１つのみ送信または受信するということである。逆に言えば、プライマリプロセスのみメッセージを受信して、バックアッププロセスがメッセージを受信していない等の状態にならないことを示す。
【０００８】
第１の方式では、図９中のｆａｕｌｔ１、或いはｆａｕｌｔ２で示される時点で、プライマリプロセスが実行されている計算機に障害が発生しても、他の計算機で実行されているバックアッププロセスが処理を継続し、プライマリプロセスの役割を代替する。これにより、プロセスペア９１としては処理を継続することができる。
【０００９】
図９に示した第１の方式では、全く同じ処理を２つのプロセス（プライマリプロセス及びバックアッププロセス）で実行するため、ＣＰＵリソースを２倍必要とする。
【００１０】
（２）第２の方式
第２の方式は、文献「”フォールト・トレラント・システム”、グレイ他著、渡辺榮一編訳、マグロウヒル出版」（以下、第２の文献と称する）に記載されている。この第２の文献では、プロセスペアは、そのままプロセスペアと呼ばれている。
【００１１】
図１０は第２の方式を説明するための図である。
図１０に示されるように、第２の方式では、１つのプロセスはプライマリプロセスとバックアッププロセスからなるプロセスペア１０１として構成される。プロセスペア１０１が他のプロセスペア１０２と通信を行う際には、プロセスペア間通信が行われる。
【００１２】
プロセスペア間通信では、送信側プライマリプロセスと送信側バックアッププロセスから、受信側プライマリプロセスと受信側バックアッププロセスに、メッセージを一貫性を保った状態で送受信する機能を提供する。
【００１３】
上記第１の方式では、バックアッププロセスも、プライマリプロセスと同じ処理を実行している。しかし、第２の方式では、バックアッププロセスは、プロセスとしては存在するが実際の処理は実行しないで、チェックポイント採取時（ｃｋｐ１，ｃｋｐ２，ｃｋｐ３，ｃｋｐ４）に、プライマリプロセスの状態をバックアッププロセスにコピーする。
【００１４】
第２の方式では、図１０中のｆａｕｌｔ１、或いはｆａｕｌｔ２で示される時点で、プライマリプロセスが実行されている計算機に障害が発生した場合、他の計算機上のバックアッププロセスが、各々ｒｅｓｔａｒｔ１、或いはｒｅｓｔａｒｔ２で示される最後に採取されたチェックポイントの時点から処理を再開し、プライマリプロセスの役割を代替する。このため、プロセスペアとしては処理を継続することができる。
【００１５】
第２の方式では、上記第１の方式とは異なって、全く同じ処理をプライマリプロセス及びバックアッププロセスの２つのプロセスで実行するわけではない。このため第２の方式では、ＣＰＵリソースを２倍必要とするということはない。
【００１６】
【発明が解決しようとする課題】
上記した、プロセスペア方式と呼ばれる従来のフォールトトレラント技術、例えば第１の方式では、プライマリプロセスが実行されている計算機に障害が発生しても、他の計算機で実行されているバックアッププロセスが処理を継続し、プライマリプロセスの役割を代替することで、プロセスペアとしては処理を継続することができる。ところが、第１の方式では、全く同じ処理を２つのプロセス（プライマリプロセス及びバックアッププロセス）で実行するため、ＣＰＵリソースを２倍必要とするという問題がある。
【００１７】
これに対し、上記第２の方式では、第１の方式とは異なって、全く同じ処理を２つのプロセスで実行するわけではなく、したがってＣＰＵリソースを２倍必要とせずに済む。ところが第２の方式には、以下に述べる別の問題がある。
【００１８】
まず、第２の方式では、実際には実行していないバックアッププロセス、つまりプライマリプロセス側で障害が発生しない限り定常的に停止状態にあるバックアッププロセスを、チェックポイント採取時から再開するために、プライマリプロセスの状態をバックアッププロセスにコピーする。アドレス空間やコンテクストは、これで問題ない。
【００１９】
しかしながら第２の方式は、バックアッププロセスが定常的に停止状態にあることから、単にプライマリプロセスの状態をバックアッププロセスにコピーするだけでは、システムコールの実行によって、ＯＳ（オペレーティングシステム）から受けているサービスの状態を復元できない。このＯＳから受けているサービスの状態とは、例えば、どのファイルを、どのディスクリプタでオープンしているか、そのシークポインタ等の状態である。そこで、第２の方式では、このようなＯＳから受けているサービスの状態を、保存・復元できるような機能を持った独自のＯＳを採用している。
【００２０】
このため、第２の方式では、産業界で広く利用されているオープンシステムを利用することができず、全てのアプリケーションを独自に開発する必要があり、生産性が低くなるという問題がある。
【００２１】
本発明は上記事情を考慮してなされたものでその目的は、障害発生時にも処理を継続することを可能としながら、ＣＰＵリソースを２倍必要とせずに済み、且つオープンシステムを利用できるフォールトトレラントシステムにおけるプロセスペア実行制御方法、プロセスペア実行制御プログラム、及びフォールトトレラントシステムを提供することにある。
【００２２】
【課題を解決するための手段】
本発明の１つの観点によれば、障害発生時にも処理を継続することが可能な、プライマリプロセスとバックアッププロセスから構成されるプロセスペアが実行されるフォールトトレラントシステムにおけるプロセスペア実行制御方法が提供される。このプロセスペア実行制御方法は、プロセスペアの起動時にはプライマリプロセス及びバックアッププロセスを共に実行状態にするステップと、チェックポイント採取時期が到来する毎に、プライマリプロセスの状態をバックアッププロセスにコピーするステップと、チェックポイント採取時にバックアッププロセスが実行状態にあるならば、当該バックアッププロセスを停止状態にするステップと、プロセスペアからシステムコールが発行された場合に、バックアッププロセスが停止状態にあるならば、当該バックアッププロセスを最も最近に採取されたチェックポイント（最後のチェックポイント）から再開させて実行状態にするステップとから構成される。
【００２３】
本発明の第１の観点に係るプロセスペア実行制御方法においては、プログラム（プロセスペア）の起動直後の期間は、プライマリプロセス及びバックアッププロセスが共に実行状態となって動作する。このため両プロセスは、ＯＳからのサービス提供を受けている状態となる。その後は、最初のチェックポイント採取時期の到来によりバックアッププロセスが停止状態となり、バックアッププロセス側でのＣＰＵリソースの消費が抑えられる。また、バックアッププロセスが停止状態にあるときにシステムコールが発行されると、バックアッププロセスは最後のチェックポイントから処理を再開する。つまり、バックアッププロセスも実行状態となって動作し、プライマリプロセス及びバックアッププロセスは再びＯＳからのサービス提供を受けている状態となる。
【００２４】
このように、本発明の第１の観点に係るプロセスペア実行制御方法において、バックアッププロセスは、従来の技術の欄で述べた第２の方式と異なって、プログラムの起動直後の期間と、その後バックアッププロセスが停止状態にあるときにシステムコールが発行された場合には実行状態となる。一方、プライマリプロセスは上記第２の方式と同様に、障害が発生しない限りはプログラムが終了するまで実行状態にある。つまり、第１の観点に係るプロセスペア実行制御方法では、従来の技術の欄で述べた第１の方式と異なって、プライマリプロセス及びバックアッププロセスが全く同じ処理を常に実行するわけでもなく、また第２の方式と異なって、バックアッププロセスが定常的に停止状態にあるわけでもなく、両プロセスが共に実行状態にある期間が存在する。この期間中、両プロセスはＯＳからのサービス提供を受けている状態となる。
【００２５】
このため、本発明の第１の観点に係るプロセスペア実行制御方法においては、上記第２の方式のように、ＯＳから受けているサービスの状態を、保存・復元できるような機能を持った独自のＯＳを採用する必要がなく、産業界で広く利用されているオープンシステムを利用することが可能となる。また、バックアッププロセスが停止状態にある期間が存在するため、ＣＰＵリソースを２倍必要とせずに済む。また、本発明の第１の観点に係るプロセスペア実行制御方法は、以下の理由により、ＣＡＤやシミュレーション等の科学技術計算プログラムに特に適している。即ち、この種の科学技術計算プログラムでは、最初にシステムコールの発行を伴う入力データの読み出し等を行い、その後はシステムコールを発行せずに、ＣＰＵ演算を繰り返すことが多く、しかもＣＰＵ演算が行われる期間は、システムコールの発行を伴う期間に比べて著しく長い。このため、上記第１の観点に係るプロセスペア実行制御方法において、プログラムの起動直後と、それ以降はシステムコールの発行を伴う期間だけプライマリプロセス及びバックアッププロセスを共に実行状態にし、それ以外の長時間行われるＣＰＵ演算の期間はバックアッププロセスを停止状態にすることにより、ＣＰＵリソースがバックアッププロセスの実行に用いられる時間を大幅に短縮すると共に、汎用的なＯＳを使用しても当該ＯＳから受けているサービスの状態を保存・復元するのを可能とする。
【００２６】
ここで、プライマリプロセス側での障害発生時に、バックアッププロセスが停止状態にあるならば、当該バックアッププロセスを最も最近に採取されたチェックポイントから再開させて実行状態にするステップを追加するならば、たとえバックアッププロセスが停止状態にある期間にプライマリプロセス側で障害が発生しても、バックアッププロセスにより処理を継続することが可能となる。
【００２７】
また、バックアッププロセスを停止状態から実行状態に切り換えることが必要となる直前のタイミング、例えばプライマリプロセスからシステムコールが発行される直前のタイミングにチェックポイント採取時期（第１のチェックポイント採取時期）を設定するステップを追加するならば、その後プライマリプロセスから実際にシステムコールが発行されてバックアッププロセスを再開した場合に、その再開後の処理に要する時間を短縮できる。
【００２８】
また、バックアッププロセスを実行状態に維持しておく必要がなくなる直後のタイミングにチェックポイント採取時期（第２のチェックポイント採取時期）を設定するステップを追加するならば、バックアッププロセスが実行状態にある期間を必要最小限に抑えて、バックアッププロセスの実行に必要なＣＰＵリソースが余分に使用されるのを防ぐことができる。
【００２９】
また、上記第１のチェックポイント採取時期から次の上記第２のチェックポイント採取時期のまでの期間を除く、バックアッププロセスが停止状態にある期間、予め定められた時間間隔でチェックポイント採取時期（第３のチェックポイント採取時期）を設定するステップを追加するなら、プライマリプロセス及びバックアッププロセスが共に実行状態にある期間にチェックポイント採取動作が行われて、その都度バックアッププロセスが停止されて、その後のプライマリプロセスでのシステムコールにより当該バックアッププロセスが最後のチェックポイントから再開されるという、処理を遅延させる無駄な動作が発生するのを防止できる。これにより、処理効率の向上と、チェックポイントの効率的な採取とが可能となる。
【００３０】
なお、以上のプロセスペア実行制御方法に係る本発明は、当該方法を構成する各ステップを計算機に実行させるためのプログラム（プロセスペア実行制御プログラム）に係る発明としても、当該方法を実行するフォールトトレラントシステムに係る発明としても成立する。
【００３１】
【発明の実施の形態】
以下、本発明の実施の形態につき図面を参照して説明する。
【００３２】
図１は本発明の一実施形態に係るフォールトトレラントシステムの構成を示すブロック図である。
図１において、計算機１ａ及び１ｂは、ネットワーク２により相互接続されている。計算機１ａ（の図示せぬ記憶装置）上にはプライマリプロセス１１が配置され、計算機１ｂ上（の図示せぬ記憶装置）にはバックアッププロセス１２が配置されている。つまり計算機１ａ及び１ｂの組により、障害発生時にも処理を継続することが可能な、プライマリプロセス１１とバックアッププロセス１２から構成されるプロセスペア１３が実現されている。
【００３３】
計算機１ａ及び１ｂは、いずれも、プロセスペア間通信部１４、チェックポイント採取部１５、プロセスリスタート部１６、バックアッププロセス実行状態制御部１７、バックアッププロセス実行状態管理部１８、及びプロセス発行システムコール検知部１９の各機能要素を有している。これら各部１４〜１９は、プライマリプロセス１１またはバックアッププロセス１２から利用される関数プログラム等を格納したライブラリ２０によって実現される。
【００３４】
図２は、上記プライマリプロセス１１及びバックアッププロセス１２から構成されるプロセスペア１３と、上記ライブラリ２０により実現される上記各部１４〜１９との関係を示す機能ブロック構成図である。
【００３５】
プロセスペア間通信部１４は、計算機１ａ及び１ｂ上のプライマリプロセス１１及びバックアッププロセス１２から構成されるプロセスペア１３と他のプロセスペアとの間の通信を行う。プロセスペア間通信部１４は、プライマリプロセス１１及びバックアッププロセス１２が共に生存（存在）している場合、両プロセスを調停して、１つのメッセージのみを他のプロセスペアに送る。逆に他のプロセスペアからメッセージが送られてきた場合、プロセスペア間通信部１４は、プライマリプロセス１１とバックアッププロセス１２が共に生存している場合には、当該メッセージを両プロセスに送る。
【００３６】
チェックポイント採取部１５は、チェックポイント採取時期が到来すると起動される。ここでは、チェックポイント採取部１５は、プライマリプロセス１１からのシステムコールによるチェックポイント採取のための指示（チェックポイント採取指示）Ａ、またはタイマＴＭからの定期的な割り込み（チェックポイント採取割り込み）Ｂにより起動される。チェックポイント採取部１５は、バックアッププロセス実行状態管理部１８によって管理されているプライマリプロセス１１の状態から、当該プライマリプロセス１１が生存していることが判別される場合に、当該プライマリプロセス１１に指示Ｃを出して当該プライマリプロセス１１の状態の読み出しＤを行い、バックアッププロセス１２へのコピーＥを実行するチェックポイント採取動作を行う機能を有する。なお、ここでいうプロセスの状態とは、アドレス空間とコンテクストのことである。
【００３７】
チェックポイント採取部１５はまた、バックアッププロセス実行状態管理部１８を利用してバックアッププロセス１２の状態（実行状態または停止状態）を調べ、実行状態ならば、バックアッププロセス実行状態制御部１７にバックアッププロセス１２の実行を停止させる指示Ｆを出す。
【００３８】
プロセスリスタート部１６は、プライマリプロセス１１を実行している計算機の障害を検知した場合に、バックアッププロセス実行状態管理部１７を利用してバックアッププロセス１２の状態を調べ、停止状態ならば、バックアッププロセス実行状態制御部１７に対してバックアッププロセス１２の実行を開始させる指示Ｈを出す。
【００３９】
バックアッププロセス実行状態制御部１７は、プライマリプロセス１１及びバックアッププロセス１２から構成されるプロセスペア１３の起動時（プログラムの実行開始時）に、当該プライマリプロセス１１及びバックアッププロセス１２を共に実行状態として、バックアッププロセス実行状態管理部１８に登録する機能を有する。バックアッププロセス実行状態制御部１７はまた、チェックポイント採取部１５からの指示Ｆを受けて、バックアッププロセス１２を停止させ、その状態を停止状態として、バックアッププロセス実行状態管理部１８に登録する機能を有する。バックアッププロセス実行状態制御部１７はまた、プロセスリスタート部１６からの指示Ｈまたはプロセス発行システムコール検知部１９からの後述する指示Ｇを受けて、バックアッププロセス１２を実行させ、その状態を実行状態として、バックアッププロセス実行状態管理部１８に登録する機能をも有する。
【００４０】
バックアッププロセス実行状態管理部１８は、バックアッププロセス１２の状態を保持・管理する。
【００４１】
プロセス発行システムコール検知部１９は、プロセスペア１３（を構成するプライマリプロセス１１またはバックアッププロセス１２）がシステムコールを実行（発行）したことを検知する。またプロセス発行システムコール検知部１９は、プライマリプロセス１１がシステムコールを実行したことを検知した場合、バックアッププロセス実行状態管理部１８を利用してバックアッププロセス１２の状態を調べる。プロセス発行システムコール検知部１９は、バックアッププロセス１２が停止状態ならば、バックアッププロセス実行状態制御部１７に対してバックアッププロセス１２の実行を開始させる指示Ｇを出す。
【００４２】
計算機１ａ及び計算機１ｂ上の、それぞれプロセスペア間通信部１４同士、チェックポイント採取部１５同士、プロセスリスタート部１６同士、バックアッププロセス実行状態制御部１７同士、バックアッププロセス実行状態管理部１８同士、そしてプロセス発行システムコール検知部１９同士は、互いにネットワーク２を介して通信をすことで、あたかも１つであるかのように動作する。
【００４３】
図３は状態遷移図であり、同図（ａ）はプライマリプロセス１１の取り得る状態を示す状態遷移図、同図（ｂ）はバックアッププロセス１２の取り得る状態を示す状態遷移図である。
【００４４】
まずプライマリプロセス１１は、図３（ａ）に示すように、停止状態及び実行状態のいずれかの状態を取る。プライマリプロセス１１は、プログラム実行開始ａ１と共に停止状態から実行状態に遷移する。プライマリプロセス１１は、プログラム実行終了ａ２となるまで、実行状態を保つ。
【００４５】
次にバックアッププロセス１２も、図３（ｂ）に示すように、停止状態及び実行状態のいずれかの状態を取る。バックアッププロセス１２は、プログラム実行開始ｂ１と共に停止状態から実行状態に遷移する。バックアッププロセス１２は、実行状態において、チェックポイント採取ｂ２が実行されると、停止状態に遷移する。また、バックアッププロセス１２は、停止状態において、プライマリプロセス１１でのシステムコール発行ｂ３が行われると、実行状態に遷移する。
【００４６】
次に、本実施形態の動作を、図４乃至図８を適宜参照して説明する。なお、図４はプロセスペア１３を構成するプライマリプロセス１１及びバックアッププロセス１２の全体の動作を説明するためのタイミングチャート、図５はチェックポイント採取部１５の動作を説明するためのフローチャート、図６はプロセスリスタート部１６の動作を説明するためのフローチャート、図７はプロセス発行システムコール検知部１９の動作を説明するためのフローチャート、図８はプライマリプロセス１１及びバックアッププロセス１２の状態とチェックポイント採取時期との関係を説明するためのタイミングチャートである。
【００４７】
まず、プロセス開始直後、つまりプログラム実行開始ａ１，ｂ１直後は、計算機１ａ上のプライマリプロセス１１及び計算機１ｂ上のバックアッププロセス１２は、図３に示すように共に停止状態から実行状態に遷移する。
【００４８】
今、プライマリプロセス１１及びバックアッププロセス１２が実行状態にあるときに、例えば図４中のｃｋｐ１の時点で、プライマリプロセス１１からチェックポイント採取部１５にチェックポイント採取のシステムコールＡが発行されたものとする。
【００４９】
この場合、チェックポイント採取部１５は起動され、バックアッププロセス実行状態管理部１８に対して、当該管理部１８により管理されているプライマリプロセス１１及びバックアッププロセス１２の状態を問い合わせ、両プロセスが共に生存しているか否かを判定する（ステップＳ１）。もし、プライマリプロセス１１及びバックアッププロセス１２の少なくとも一方が生存していないならば、チェックポイント採取部１５はそのまま動作を終了する。
【００５０】
これに対し、プライマリプロセス１１及びバックアッププロセス１２が共に生存しているならば、チェックポイント採取部１５はプライマリプロセス１１に指示Ｃを出して当該プライマリプロセス１１の状態を読み出す動作Ｄを実行し、読み出した状態をバックアッププロセス１２にコピーする動作Ｅを実行する（ステップＳ２）。
【００５１】
チェックポイント採取部１５は、ステップＳ２の処理（チェックポイント採取動作）を実行すると、バックアッププロセス実行状態管理部１８に対してバックアッププロセス１２の状態を問い合わせ、当該バックアッププロセス１２が実行状態にあるか否かを判定する（ステップＳ３）。もし、バックアッププロセス１２が停止状態にあるなら、チェックポイント採取部１５はそのまま動作を終了する。これに対し、バックアッププロセス１２が実行状態にあるならば、チェックポイント採取部１５はバックアッププロセス実行状態制御部１７に対して指示Ｆを出すことで、当該バックアッププロセス１２を実行状態から停止状態に遷移させる（ステップＳ４）。このバックアッププロセス１２の新たな状態（停止状態）は、バックアッププロセス実行状態制御部１７によりバックアッププロセス実行状態管理部１８に登録される。
【００５２】
図４の例では、ｃｋｐ１の後も、例えばタイマＴＭからの定期的な割り込みＢのタイミングで決まるｃｋｐ２，ｃｋｐ３，ｃｋｐ４の時点で、チェックポイントが採られる。このとき、バックアッププロセス１２は、上記の説明から明らかなように停止状態のままである。
【００５３】
その後、例えばプライマリプロセス１１での処理に伴う出力データの書き出し等のために、当該プライマリプロセス１１が図４に示す送信（ｓｅｎｄ）処理４１を行うものとする。この送信（ｓｅｎｄ）処理４１はシステムコールであるものとする。この場合、プロセス発行システムコール検知部１９は、上記システムコール（送信処理）を検知する。するとプロセス発行システムコール検知部１９は、バックアッププロセス実行状態管理部１８に対してプライマリプロセス１１及びバックアッププロセス１２の状態を問い合わせ、両プロセスが共に生存しているか否かを判定する（ステップＳ２１）。もし、プライマリプロセス１１及びバックアッププロセス１２の少なくとも一方が生存していないならば、プロセス発行システムコール検知部１９はそのまま動作を終了する。
【００５４】
これに対し、プライマリプロセス１１及びバックアッププロセス１２が共に生存しているならば、プロセス発行システムコール検知部１９はバックアッププロセス実行状態管理部１８を用いてバックアッププロセス１２が実行状態にあるか否かを判定する（ステップＳ２２）。
【００５５】
もし、バックアッププロセス１２が実行状態にないならば、つまりバックアッププロセス１２が停止状態にあるならば、プロセス発行システムコール検知部１９はバックアッププロセス実行状態制御部１７に対して指示Ｇを出して当該バックアッププロセス１２を実行状態に遷移させ、その時点を基準に、最後（最も最近）に採ったチェックポイントから当該バックアッププロセス１２をリスタートさせる（ステップＳ２３）。図４の例では、送信（ｓｅｎｄ）処理４１のタイミングからみて、最後に採られたチェックポイントはｃｋｐ４である。この場合、バックアッププロセス１２はチェックポイントｃｋｐ４から処理を再開する。
【００５６】
プロセス発行システムコール検知部１９は、バックアッププロセス１２が停止状態にある場合（ステップＳ２２のＮＯ）には、上述のように当該バックアッププロセス１２を実行状態にしてリスタートさせた後（ステップＳ２３）に、ステップＳ２４に進む。またプロセス発行システムコール検知部１９は、バックアッププロセス１２が既に実行状態にある場合には（ステップＳ２２のＹＥＳ）、そのままステップＳ２４に進む。プロセス発行システムコール検知部１９は、ステップＳ２４において、プライマリプロセス１１とバックアッププロセス１２とを同期させて動作を終了する。つまりバックアッププロセス１２は、リスタート後に送信（ｓｅｎｄ）処理４１を行ったところで、プロセスペア間通信部１４によって同期させられる。
【００５７】
次に、プライマリプロセス１１を実行している計算機１ａに障害が発生し、当該プライマリプロセス１１が停止したものとする。また、この計算機１ａの障害が図４中のｆａｕｌｔ１の時点で発生したものとする。この計算機１ａの障害はプロセスリスタート部１６により検出される。
【００５８】
プロセスリスタート部１６は、計算機の障害を検知した場合、その障害発生計算機がバックアッププロセス１２側の計算機であるか否かを判定する（ステップＳ１１）。もし、バックアッププロセス１２側の計算機、つまり計算機１ｂでの障害発生の場合には、計算機１ａ上のプライマリプロセス１１は実行可能であることから、プロセスリスタート部１６はそのまま動作を終了する。
【００５９】
これに対し、プライマリプロセス１１側の計算機、つまり計算機１ａでの障害発生の場合は、プロセスリスタート部１６はバックアッププロセス実行状態管理部１８に対してバックアッププロセス１２の状態を問い合わせ、当該バックアッププロセス１２が生存していて且つ停止状態にあるか否かを判定する（ステップＳ１２，Ｓ１３）。もし、バックアッププロセス１２が生存していない場合、或いは生存していても実行状態にある場合には、プロセスリスタート部１６はそのまま動作を終了する。
【００６０】
これに対し、バックアッププロセス１２が生存していて且つ停止状態にある場合には、プロセスリスタート部１６はバックアッププロセス実行状態制御部１７に対して指示Ｈを出して当該バックアッププロセス１２を実行状態に遷移させ、その時点、つまりｆａｕｌｔ１の時点を基準に、最後に採ったチェックポイント（ここでは、図４から明らかなようにｃｋｐ２）から当該バックアッププロセス１２をリスタートさせる（ステップＳ１４）。これによりバックアッププロセス１２は、図４の例では、ｒｅｓｔａｒｔ１の時点であるチェックポイントｃｋｐ２から処理を再開する。
【００６１】
一般にＣＡＤやシミュレーション等の科学技術計算プログラムでは、最初にシステムコールの発行を伴う入力データの読み出し等を行い、その後はシステムコールを発行せずに、ＣＰＵ演算を繰り返すことが多い。そして長時間のＣＰＵ演算が終わった最後に、システムコールの発行を伴う出力データの書き出し等が行われる。このシステムコールの発行を伴う期間だけ、バックアッププロセス１２も実行状態とするならば、システムコールを発行せずに、ＣＰＵ演算を繰り返す期間、プライマリプロセス１１だけを実行させても、ＯＳから受けているサービスの状態を保存・復元するのに独自のＯＳを採用する必要がなく、産業界で広く利用されているオープンシステムを利用することができる。
【００６２】
ここで、図１のフォールトトレラントシステムを、上述の科学技術計算プログラムの実行に適用するものとする。この場合、例えば図８に示すように、科学技術計算プログラムの起動直後、つまりプライマリプロセス１１及びバックアッププロセス１２から構成されるプロセスペア１３の起動直後、入力データ読み出し８１等でシステムコールを発行する最初の期間は、プライマリプロセス１１及びバックアッププロセス１２は共に動作して、ＯＳからのサービス提供を受けている状態（実行状態）となる。
【００６３】
その後の長時間のＣＰＵ演算の間は、最初のチェックポイントｃｋｐ１の時点以降、先のチェックポイント採取部１５の動作から明らかなように、バックアッププロセス１２は停止状態となる。このため、長時間のＣＰＵ演算の間、バックアッププロセス１２側では科学技術計算プログラムの実行のためにＣＰＵリソースを消費しない。そして最後に出力データの書き出し８２等でシステムコールを発行する間は、再びプライマリプロセス１１及びバックアッププロセス１２が共に動作して、ＯＳからのサービス提供を受けている状態になる。
【００６４】
さて、本実施形態では、プロセス発行システムコール検知部１９がプライマリプロセス１１でのシステムコールの発行を検知して、最後に採ったチェックポイントから自動的にバックアッププロセス１２を再開させ、システムコールを処理させている。この場合、もし最後にチェックポイントを採ってから長時間が経過していると、再開後の処理に時間がかかる。
【００６５】
そこで本実施形態では、プログラム中で明示的にチェックポイント採取を指示し、最後にチェックポイントを採った後長時間が経過してから、システムコールが実行されるのを防ぐようにしている。図８の例では、チェックポイントｃｋｐ５及びｃｋｐ１０が、これに相当し、プライマリプロセス１１からのシステムコールによる指示Ａにより、チェックポイント採取部１５に対して指定される。一方、図８中のチェックポイントｃｋｐ１，ｃｋｐ２，ｃｋｐ３，ｃｋｐ４及びｃｋｐ７，ｃｋｐ８，ｃｋｐ９は、バックアッププロセス１２が停止状態にある期間、タイマＴＭからの定期的な割り込みＢによって指定される。
【００６６】
ところで、既に説明したように、バックアッププロセス１２が実行状態にある期間に、チェックポイントの採取時期が到来すると、当該バックアッププロセス１２は停止状態となる。この状態でシステムコールが実行されると、その時点を基準に最後に採ったチェックポイントからバックアッププロセス１２を再開させる必要がある。このため、システムコールを繰り返す必要のある期間に、チェックポイントの採取時期が到来するのは処理効率の点で好ましくない。
【００６７】
そこで、チェックポイント採取部１５がタイマＴＭからの定期的な割り込みＢにより起動される期間を、バックアッププロセス１２が停止状態にある期間に限定し、バックアッププロセス１２が実行状態にある期間における当該割り込みＢは、チェックポイント採取部１５にて無視（無効扱い）される構成とするとよい。また、プライマリプロセス１１からのシステムコールによるチェックポイント採取の指示Ａは、チェックポイント採取部１５にて常に有効として処理される構成とする。
【００６８】
更に、システムコールを繰り返す必要のある期間の終了直後、つまりバックアッププロセス１２を実行状態に維持しておく必要がなくなる直後でも、プログラム中で明示的にチェックポイント採取を指示するとよい。このようにすると、システムコールを繰り返す必要のある期間の終了直後にバックアッププロセス１２は停止状態となり、以降タイマＴＭからの定期的な割り込みＢによるチェックポイント採取の指示が可能となる。この結果、効率よくチェックポイントを採るようにすることができる。図８の例では、ｃｋｐ６が、システムコールを繰り返す必要のある期間の終了直後となるように、プログラム中で明示的に指示されたチェックポイントである。
【００６９】
また、同様に、バックアッププロセス１２を実行状態にすることを、プログラム中で明示することもできる。
【００７０】
このように本実施形態においては、障害発生時における処理の継続を可能としながら、（１）ＣＰＵリソースを２倍使うことなく、（２）オープンシステムに適用可能な、プロセスペア方式によるフォールトトレラントシステムが実現できる。
【００７１】
上記実施形態では、プロセスペア１３を構成するプライマリプロセス１１及びバックアッププロセス１２を、それぞれ異なる計算機１ａ及び１ｂ上で動作させている。しかし、プログラム上の障害だけを考慮すればよいフォールトトレラントシステムでは、プライマリプロセス１１及びバックアッププロセス１２を同一計算機上で動作させるようにしてもよい。但し、プライマリプロセス１１及びバックアッププロセス１２が動作する唯一の計算機自体の障害が発生した場合には、処理を継続することはできない。
【００７２】
なお、本発明は、上記実施形態に限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で種々に変形することが可能である。更に、上記実施形態には種々の段階の発明が含まれており、開示される複数の構成要件における適宜な組み合わせにより種々の発明が抽出され得る。例えば、実施形態に示される全構成要件から幾つかの構成要件が削除されても、発明が解決しようとする課題の欄で述べた課題が解決でき、発明の効果の欄で述べられている効果が得られる場合には、この構成要件が削除された構成が発明として抽出され得る。
【００７３】
【発明の効果】
以上詳述したように本発明によれば、バックアッププロセスを、プログラムの起動直後の期間と、その後当該バックアッププロセスが停止状態にあるときにシステムコールが発行された場合に実行状態にする一方、チェックポイント採取時に当該バックアッププロセスが実行状態にあるならば、当該バックアッププロセスを停止状態にするようにしたので、障害発生時にも処理を継続することを可能としながら、ＣＰＵリソースを２倍必要とせずに済み、しかも独自のＯＳを採用することなくＯＳから受けているサービスの状態を保存・復元できるため、オープンシステムを利用できる。
【図面の簡単な説明】
【図１】本発明の一実施形態に係るフォールトトレラントシステムの構成を示すブロック図。
【図２】図１中のプライマリプロセス１１及びバックアッププロセス１２から構成されるプロセスペア１３と、ライブラリ２０により実現される各機能要素との関係を示す機能ブロック構成図。
【図３】プライマリプロセス１１及びバックアッププロセス１２の取り得る状態を示す状態遷移図。
【図４】同実施形態におけるプロセスペア１３を構成するプライマリプロセス１１及びバックアッププロセス１２の全体の動作を説明するためのタイミングチャート。
【図５】同実施形態におけるチェックポイント採取部１５の動作を説明するためのフローチャート。
【図６】同実施形態におけるプロセスリスタート部１６の動作を説明するためのフローチャート。
【図７】同実施形態におけるプロセス発行システムコール検知部１９の動作を説明するためのフローチャート。
【図８】同実施形態におけるプライマリプロセス１１及びバックアッププロセス１２の状態とチェックポイント採取時期との関係を説明するためのタイミングチャート。
【図９】従来のプロセスペアの第１の方式を説明するための図。
【図１０】従来のプロセスペアの第２の方式を説明するための図。
【符号の説明】
１ａ，１ｂ…計算機
２…ネットワーク
１１…プライマリプロセス
１２…バックアッププロセス
１３…プロセスペア
１４…プロセスペア間通信部
１５…チェックポイント採取部
１６…プロセスリスタート部
１７…バックアッププロセス実行状態制御部
１８…バックアッププロセス実行状態管理部
１９…プロセス発行システムコール検知部
２０…ライブラリ
Claims (9)
- 障害発生時にも処理を継続することが可能な、プライマリプロセスとバックアッププロセスから構成されるプロセスペアが実行されるフォールトトレラントシステムにおけるプロセスペア実行制御方法であって、
前記プロセスペアの起動時には前記プライマリプロセス及び前記バックアッププロセスを共に実行状態にするステップと、
チェックポイント採取時期が到来する毎に、前記プライマリプロセスの状態を前記バックアッププロセスにコピーするチェックポイント採取動作を実行するステップと、
前記チェックポイント採取動作の実行後に前記バックアッププロセスが実行状態にあるかを判定し、実行状態にあるならば、当該バックアッププロセスを停止状態にするステップと、
前記プロセスペアからシステムコールが発行された場合に、前記バックアッププロセスが停止状態にあるならば、当該バックアッププロセスを最も最近に採取されたチェックポイントから再開させて実行状態にするステップと
を具備することを特徴とするフォールトトレラントシステムにおけるプロセスペア実行制御方法。 - 前記プライマリプロセス側での障害発生時に、前記バックアッププロセスが停止状態にあるならば、当該バックアッププロセスを最も最近に採取されたチェックポイントから再開させて実行状態にするステップを更に具備することを特徴とする請求項１記載のフォールトトレラントシステムにおけるプロセスペア実行制御方法。
- 前記プライマリプロセスからシステムコールが発行される直前のタイミングにチェックポイント採取時期を設定するステップを更に具備することを特徴とする請求項１記載のフォールトトレラントシステムにおけるプロセスペア実行制御方法。
- 前記プライマリプロセスからシステムコールを繰り返す期間の終了直後のタイミングにチェックポイント採取時期を設定するステップを更に具備することを特徴とする請求項３記載のフォールトトレラントシステムにおけるプロセスペア実行制御方法。
- 前記プライマリプロセスからシステムコールが発行される直前のタイミングに第１のチェックポイント採取時期を設定するステップと、
前記プライマリプロセスからシステムコールを繰り返す期間の終了直後のタイミングに第２のチェックポイント採取時期を設定するステップと、
前記第１のチェックポイント採取時期から次の前記第２のチェックポイント採取時期のまでの期間を除く、前記バックアッププロセスが停止状態にある期間、予め定められた時間間隔で第３のチェックポイント採取時期を設定するステップと
を更に具備することを特徴とする請求項１記載のフォールトトレラントシステムにおけるプロセスペア実行制御方法。 - 障害発生時にも処理を継続することが可能な、プライマリプロセスとバックアッププロセスから構成されるプロセスペアが実行されるフォールトトレラントシステム向けのプロセスペア実行制御プログラムであって、
計算機に、
前記プロセスペアの起動時に前記プライマリプロセス及び前記バックアッププロセスを共に実行状態にするステップと、
チェックポイント採取時期が到来する毎に、前記プライマリプロセスの状態を前記バックアッププロセスにコピーするステップと、
チェックポイント採取時に前記バックアッププロセスが実行状態にあるならば、当該プライマリプロセスを停止状態にするステップと、
前記プロセスペアからシステムコールが発行された場合に、前記バックアッププロセスが停止状態にあるならば、当該バックアッププロセスを最も最近に採取されたチェックポイントから再開させて実行状態にするステップと
を実行させるためのプロセスペア実行制御プログラム。 - 障害発生時にも処理を継続することが可能な、プライマリプロセスとバックアッププロセスから構成されるプロセスペアを実行するフォールトトレラントシステムにおいて、
前記プロセスペアと他のプロセスペアとの間の通信を行うプロセスペア間通信手段と、
前記バックアッププロセスの実行状態を制御するバックアッププロセス実行状態制御手段であって、前記プロセスペアの起動時には前記プライマリプロセス及び前記バックアッププロセスを共に実行状態にするバックアッププロセス実行状態制御手段と、
チェックポイント採取時期が到来する毎に、前記プライマリプロセスの状態を前記バックアッププロセスにコピーすることでチェックポイントを採取するチェックポイント採取手段であって、チェックポイント採取時に前記バックアッププロセスが実行状態にあるならば、当該バックアッププロセスを前記バックアッププロセス実行状態制御手段により停止状態にさせるチェックポイント採取手段と、
前記プロセスペアの発行するシステムコールを検知するプロセス発行システムコール検知手段であって、前記システムコールを検知した場合、前記バックアッププロセスが停止状態にあるならば、当該バックアッププロセスを最も最近に採取されたチェックポイントから前記バックアッププロセス実行状態制御手段により再開させて実行状態にさせるプロセス発行システムコール検知手段と
を具備することを特徴とするフォールトトレラントシステム。 - 前記プライマリプロセス側での障害発生時に、前記バックアッププロセスが停止状態にあるならば、当該バックアッププロセスを最も最近に採取されたチェックポイントから前記バックアッププロセス実行状態制御手段により再開させて実行状態にするプロセスリスタート手段を更に具備することを特徴とする請求項７記載のフォールトトレラントシステム。
- 前記バックアッププロセスの実行状態を管理するバックアッププロセス実行状態管理手段を更に具備し、
前記チェックポイント採取手段、前記プロセス発行システムコール検知手段及び前記プロセスリスタート手段は、前記バックアッププロセスの状態を前記バックアッププロセス実行状態管理手段に問い合わせることで判別することを特徴とする請求項８記載のフォールトトレラントシステム。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2002084321A JP3708891B2 (ja) | 2002-03-25 | 2002-03-25 | フォールトトレラントシステムにおけるプロセスペア実行制御方法、プロセスペア実行制御プログラム、及びフォールトトレラントシステム |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2002084321A JP3708891B2 (ja) | 2002-03-25 | 2002-03-25 | フォールトトレラントシステムにおけるプロセスペア実行制御方法、プロセスペア実行制御プログラム、及びフォールトトレラントシステム |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2003280939A JP2003280939A (ja) | 2003-10-03 |
| JP3708891B2 true JP3708891B2 (ja) | 2005-10-19 |
Family
ID=29231731
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2002084321A Expired - Fee Related JP3708891B2 (ja) | 2002-03-25 | 2002-03-25 | フォールトトレラントシステムにおけるプロセスペア実行制御方法、プロセスペア実行制御プログラム、及びフォールトトレラントシステム |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP3708891B2 (ja) |
Families Citing this family (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US8346996B2 (en) * | 2008-10-29 | 2013-01-01 | Nec Corporation | Information processing system |
| KR101237746B1 (ko) | 2010-10-22 | 2013-02-28 | 매크로임팩트 주식회사 | 데이터 백업 장치 및 방법 |
| CN112860491B (zh) * | 2021-03-17 | 2023-05-02 | 深圳市腾讯信息技术有限公司 | 一种数据冷备系统及方法 |
-
2002
- 2002-03-25 JP JP2002084321A patent/JP3708891B2/ja not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| JP2003280939A (ja) | 2003-10-03 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN109558215B (zh) | 虚拟机的备份方法、恢复方法、装置及备份服务器集群 | |
| US5907673A (en) | Checkpointing computer system having duplicated files for executing process and method for managing the duplicated files for restoring the process | |
| US8127174B1 (en) | Method and apparatus for performing transparent in-memory checkpointing | |
| US7844856B1 (en) | Methods and apparatus for bottleneck processing in a continuous data protection system having journaling | |
| JP2011060055A (ja) | 仮想計算機システム、仮想マシンの復旧処理方法及びそのプログラム | |
| US9335998B2 (en) | Multi-core processor system, monitoring control method, and computer product | |
| KR101835458B1 (ko) | 데이터 처리 시스템의 재기동 방법, 시스템 및 컴퓨터 판독가능 저장 매체 | |
| JP5243851B2 (ja) | データをバックアップする方法 | |
| JP5183542B2 (ja) | 計算機システム及び設定管理方法 | |
| JP2012221321A (ja) | フォールトトレラント計算機システム、フォールトトレラント計算機システムの制御方法、及びフォールトトレラント計算機システムの制御プログラム | |
| JP2006004147A (ja) | ディザスタリカバリシステム、プログラム及びデータベースのリカバリ方法 | |
| CN106354563B (zh) | 用于3d重建的分布式计算系统以及3d重建方法 | |
| JP4141875B2 (ja) | リカバリ処理方法及びその実施システム並びにその処理プログラム | |
| WO2015043155A1 (zh) | 一种基于命令集的网元备份与恢复方法及装置 | |
| WO2023185802A1 (zh) | 数据处理方法及装置 | |
| JP2009080705A (ja) | 仮想計算機システム及び同システムにおける仮想計算機復元方法 | |
| CN114281508A (zh) | 一种数据批流融合离线计算方法 | |
| JP3708891B2 (ja) | フォールトトレラントシステムにおけるプロセスペア実行制御方法、プロセスペア実行制御プログラム、及びフォールトトレラントシステム | |
| JP4095139B2 (ja) | コンピュータシステムおよびファイル管理方法 | |
| JP5672521B2 (ja) | コンピュータシステム、およびそのチェックポイントリスタート方法 | |
| JP2004046658A (ja) | データ転送方法 | |
| JP3122371B2 (ja) | 計算機システム | |
| Tsai et al. | FVMM: Fast VM Migration for Virtualization-based Fault Tolerance Using Templates | |
| JP5317182B2 (ja) | Ｐｏｓ端末、モジュールアップデート方法およびモジュールアップデートプログラム | |
| WO2014147707A1 (ja) | 情報処理装置、情報処理方法、及び情報処理プログラム |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20040820 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20050412 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20050527 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20050802 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20050804 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20090812 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100812 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100812 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110812 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120812 Year of fee payment: 7 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120812 Year of fee payment: 7 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130812 Year of fee payment: 8 |
|
| LAPS | Cancellation because of no payment of annual fees |