(57)【要約】【課題】  故障の要因によらず、故障発生時に適切に回復させることが可能なチェックチェックポイント／リスタート制御技術を提供する【解決手段】  複数のＣＰで取得したＣＰ情報を保持し、故障が再発するタイミングに応じて適切なＣＰ情報を用いてシステムを回復させる。計算機上で稼動しているプロセスを監視し当該プロセスの障害の発生を検出し、前記プロセスにおいて予め定めた前記プロセスの保全性に影響を与える事象が発生する直前のタイミングで記録した前記プロセスのメモリ状態を用いて、前記障害が発生したプロセスを再始動させる。所定の期間内に故障が再発した場合は、さらに前に記録したメモリ状態を用いて再始動させる。【選択図】図１
2008003691.tif 000002
【特許請求の範囲】
【請求項１】
計算機上で稼動しているプロセスを監視し当該プロセスの障害の発生を検出する障害検出ステップと、
前記障害検出ステップで障害の発生を検出すると、前記プロセスにおいて予め定めた前記プロセスの保全性に影響を与える事象が発生する以前の所定のタイミングで記録した前記プロセスのメモリ状態を用いて、前記障害が発生したプロセスを再始動させる再始動ステップと、を備えること
を特徴とする計算機のプロセス回復方法。
【請求項２】
請求項１記載のプロセス回復方法であって、
前記障害検出ステップは、障害の発生を検出する毎に検出した障害の種類と時刻とを記録し、
前記再始動ステップは、前回同じ障害の発生を検出した場合に再始動に用いたメモリ状態を記録した時刻から新たに検出した障害の発生時刻までの時間が再始動に用いたメモリ状態を記録した時刻から前回の障害の発生時刻までの時間より長い場合は、前回の障害発生時に用いたメモリ状態を用いて再始動を行い、短い場合は、前回の障害発生時に用いたメモリ状態より前に記録したメモリ状態を用いて再始動を行うこと
を特徴とするプロセス回復方法。
【請求項３】
請求項１記載のプロセス回復方法であって、
前記障害検出ステップは、障害の発生を検出すると、検出した障害の種類と、前記プロセスの稼動から当該障害の発生を検出するまでに発行されたシステムコール数を記録し、
前記再始動ステップは、前回同じ障害の発生を検出した場合に再始動に用いたメモリ状態を記録した時から新たに検出した障害の発生時までに発行されたシステムコール数が当該メモリ状態を記録した時から前回の障害の発生時までに発行されたシステムコール数より多い場合は、前回の障害発生時に用いたメモリ状態を用いて再始動を行い、少ない場合は、前回の障害発生時に用いたメモリ状態より前に記録したメモリ状態を用いて再始動を行うこと
を特徴とするプロセス回復方法。
【請求項４】
計算機上で稼動しているプロセスに障害が発生した場合に回復処理を行うために用いるメモリ状態記録方法であって、
プロセスが発行するシステムコール列を監視する監視ステップと、
前記監視ステップにおいて、前記プロセスの保全性に影響のある処理が行われる直前であることを示すシステムコール列が検出されると、前記検出した時刻に対応付けて当該時刻における前記プロセスのメモリ状態を記録するメモリ状態記録ステップと、
を備えるメモリ状態記録方法。
【請求項５】
請求項４記載のメモリ状態記録方法であって、
前記計算機がオフライン状態の場合は、オフライン状態からオンライン状態に移行する直前を示すシステムコール列の検出を契機に前記メモリ状態を記録し、
前記計算機がオンライン状態の場合は、ファイル更新およびセキュリティ上の脆弱性を修正するためのプログラムの追加処理のいずれかが行われる直前を示すシステムコール列の検出を契機に前記メモリ状態を記録すること
を特徴とするメモリ状態記録方法。
【請求項６】
計算機上で稼動しているプロセスにおいて発行されるシステムコールを監視し、所定のシステムコール列の発行を検出するシステムコール監視手段と、
前記システムコール監視手段が前記所定のシステムコール列を検出したタイミングで前記プロセスのメモリ状態を取得し、前記取得した時刻と対応づけて記録するとともに、前記プロセスの状態を監視し、障害を検出すると前記記録したメモリ状態を用いて前記プロセスを再始動させる記録再始動手段と、を備え、
前記所定のシステムコール列は、前記プロセスの保全性に影響を与える事象が発生する直前であることを示すシステムコール列であること
を特徴とするチェックポイントリスタートシステム。
【請求項７】
請求項６記載のチェックポイントリスタートシステムであって
前記記録再始動手段は、
障害の発生を検出する毎に検出した障害の種類と時刻とを記録し、
前回同じ障害の発生を検出した場合に再始動に用いたメモリ状態を記録した時刻から新たに検出した障害の発生時刻までの時間が再始動に用いたメモリ状態を記録した時刻から前回の障害の発生時刻までの時間より長い場合は、前回の障害発生時に用いたメモリ状態を用いて再始動を行い、短い場合は、前回の障害発生時に用いたメモリ状態より前に記録したメモリ状態を用いて再始動を行うこと
を特徴とするチェックポイントリスタートシステム。
【請求項８】
請求項６記載のチェックポイントリスタートシステムであって
前記記録再始動手段は、
障害の発生を検出すると、検出した障害の種類と、前記プロセスの稼動から当該障害の発生を検出するまでに発行されたシステムコール数を記録し、
前回同じ障害の発生を検出した場合に再始動に用いたメモリ状態を記録した時から新たに検出した障害の発生時までに発行されたシステムコール数が当該メモリ状態を記録した時から前回の障害の発生時までに発行されたシステムコール数より多い場合は、前回の障害発生時に用いたメモリ状態を用いて再始動を行い、少ない場合は、前回の障害発生時に用いたメモリ状態より前に記録したメモリ状態を用いて再始動を行うこと
を特徴とするチェックポイントリスタートシステム。
【請求項９】
複数のアプリケーションプログラム（ＡＰ）と、複数のオペレーティングシステム（ＯＳ）とが動作する仮想計算機を備える計算機システムであって、
それぞれのＯＳは、当該ＯＳ上で実行中のＡＰ（プロセス）が発行するシステムコールを監視し、所定のシステムコール列の発行を検出するシステムコール監視手段を備え、
前記仮想計算機は、
前記システムコール監視手段のいずれかが前記所定のシステムコール列を検出したタイミングで前記計算機システムの全てのメモリ状態を取得し、前記取得した時刻と対応づけて記録するとともに、前記プロセスの状態を監視し、障害を検出すると、前記障害が検出されたプロセスが稼動するＯＳ以外のＯＳから前記記録したメモリ状態を用いて前記プロセスを再始動させる記録再始動手段を備え、
前記所定のシステムコール列は、前記プロセスの保全性に影響を与える事象が発生する直前であることを示すシステムコール列であること
を特徴とする計算機システム。
【請求項１０】
計算機を、
当該計算機上で稼動しているプロセスにおいて発行されるシステムコールを監視し、前記プロセスの保全性に影響を与える事象が発生する直前であることを示すシステムコール列の発行を検出するシステムコール監視手段と、
前記システムコール監視手段が前記所定のシステムコール列を検出したタイミングで前記プロセスのメモリ状態を取得し、前記取得した時刻と対応づけて記録するとともに、前記プロセスの状態を監視し、障害を検出すると前記記録したメモリ状態を用いて前記プロセスを再始動させる記録再始動手段と、して機能させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ソフトウェア故障から計算機システムを復旧する、チェックポイント／リスタート技術に関する。特に、故障要因が攻撃や侵入である場合も含めて対処可能な技術に関する。
【背景技術】
【０００２】
計算機のソフトウェアやハードウェアに故障が発生した際、実行中のプログラム（以下、プロセスと呼ぶ。）がデータ処理を中断し，以前のプロセスの実行状態に移行し，業務を継続する計算機技術を、一般に、チェックポイント／リスタート制御方法と呼ぶ。プロセスのリスタート（再始動）とは，システムやプロセスの停止を伴う，装置のリブート（再起動）とは異なる。リスタート（再始動）とは，プロセスを停止せずに，事前に記録したメモリや入出力の状態を呼び出すことで，状態を回復するものである。この状態を記録するタイミングをチェックポイント（ＣＰ）と呼ぶ。
【０００３】
なお、本明細書では、チェックポイント（ＣＰ）において複製する情報をチェックポイント情報（ＣＰ情報）と呼び、ＣＰ情報を複製し記録媒体に記録することをＣＰ情報の取得と呼ぶ。また、ＣＰ情報を呼び出し、状態の回復を行うことを回復処理と呼ぶ。
【０００４】
ところで、故障発生の原因によっては、再始動したプロセスが再び故障する可能性が少なからず存在する。
【０００５】
チェックポイント／リスタート制御では、ソフトウェア故障が回復するまで、ＣＰ情報を利用し再始動を試みる。ただし、試行回数は、予め設定した最大値を越えない。または、予め設定した時間内で試行を繰り返す（例えば、特許文献１参照。）。
【０００６】
なお、通常のチェックポイント／リスタート制御の回復手順では、複数のＣＰでＣＰ情報を取得した場合も、直前に取得したＣＰ情報（最新のＣＰ情報）を用いて、再始動を試みる（例えば、特許文献２参照）。
【０００７】
その他、故障回復処理の手法としては、故障が発生した入力データを処理せずに、次のデータから処理を継続する手法もある（例えば、特許文献３参照）。
【０００８】
【特許文献１】特許第３０７２０４８号
【特許文献２】特許第３１３５７１４号
【特許文献３】特開平５−２３３３４１号公報
【発明の開示】
【発明が解決しようとする課題】
【０００９】
一般に、サーバ装置の障害対策として、保全作業を実施する必要がある。保全作業とは、例えば、セキュリティパッチの適用、構成定義ファイルの更新など、システムの保全性に関わる作業である。具体的な作業内容は、ディスク上のプログラムやファイルの交換である。特に、無停止運用のサーバ装置においては、サーバのデータ処理を一時中断し、メモリ上のプロセスやデータの内容を変更した後に、業務を再開する操作が含まれる、場合がある。
【００１０】
サーバ装置において、プロセスがデータを紛失する、データが改ざんされる、などの脅威を想定し、事前に解決手段を提供し、障害の発生を回避するのが、保全作業を実施する目的である。しかし、システムが大規模となり、複数のプログラムが密接にかつ複雑に絡み合った情況では、計算機の構成やプログラムの内容を変更する操作の結果や影響は、完全には把握しきれないのが現状である。そのため、実行中のプロセスの状態が不安定となり、故障が発生する可能性もある。
【００１１】
故障の種類として、例えば、プロセスが新規の業務を受け付けない、プロセスが異常停止する、プロセスが規定外の処理を実行する、等がある。これらの故障の要因として、（Ｘ）偶然（例えば処理集中による資源の枯渇）、（Ｙ）事故（例えば保全作業自体の不具合）、（Ｚ）攻撃（例えばウィルスの混入）、の各脅威が想定される。
【００１２】
一般に、計算機システムの運用方針や回復手順は、システムの目標や故障の要因に応じて複数存在する。例えば、処理再開と故障解析という目標に対して、それぞれ回復手順は異なる。運用方針の例をあげると、故障の要因が脅威Ｘと脅威Ｙとのいずれかと推測できる場合は、処理再開を優先すべきである。他方、故障の要因が脅威Ｚである場合は、故障要因の排除を優先すべきである。さらに、排除できない場合に業務を中止することもある。
【００１３】
いずれの場合も、最終目標は、業務の再開並びにシステムの復旧であるが、要因が特定できれば、適切な回復手順を選択できる。チェックポイント／リスタート制御を行う場合も、故障発生の要因が脅威Ｘと脅威Ｙとのいずれかである場合は、業務再開を優先したＣＰ情報を用いた回復処理を行い、脅威Ｚによるものである場合は、故障の要因を排除可能なＣＰ情報を用いて回復処理を行うべきである。
【００１４】
しかし、故障の要因を脅威Ｘと推量したにも係わらず、実際は脅威Ｚであった場合は、再開時期を徒に早めることで、システムの安全性や業務の信頼性を損ねる。逆に、脅威Ｚと推量したにも係わらず、実際は脅威Ｘであった場合は、停止期間を際限なく延長すると、経済的な損失が増える。
【００１５】
一般に、無停止サーバでは、故障が発生した場合、可能なかぎり短時間（秒単位）において回復することが望まれる。一方、故障要因を解析した後に復旧手順を選択することが理想である。しかし、故障要因の解析作業は、多くの場合、専門家による人手の作業であり、長時間（時間、日単位）を要する。従って、無停止サーバでの要求には対応できない。このため、現実には、故障の種類や時刻について記録した後に、ＣＰ情報を用いて回復するといった運用がなされている。回復処理の実行結果を踏まえて、故障の要因を推測（故障が再発したので脅威Ｘ、しないので故障Ｙなど）し、適宜、回復処理の内容や手順を調整する。
【００１６】
ところで、脅威Ｚ特有の現象として、タイムラグ（時間差）があること、すなわち、システムに故障要因が絡んだ時点故障が顕在化する時点が、時間的に連続ではなく、期間を隔てていることが挙げられる。ウィルスによる故障を例にとると、ウィルスがシステムに混入する時点と、混入したウィルスが活性化し、業務が停止となる時点とではタイムラグがある。そのため、ウィルス混入後にＣＰ情報を取得する可能性が少なからずあり、その場合に、従来技術のチェックポイント制御を適用すると、故障発生直前に取得したウィルス混入後のＣＰ情報を用いて回復処理を行うこととなる。故障の要因（ウィルス）は排除されておらず、再び障害が発生し、業務が停止する可能性が高い。
【００１７】
本発明は、このような事情に鑑みなされたもので、故障の要因が不明確な場合であっても、システムを安全に回復し、業務を迅速に再開する、目的に適ったチェックチェックポイント／リスタート制御技術を提供することを目的とする。
【課題を解決するための手段】
【００１８】
複数のＣＰで取得したＣＰ情報を保持し、故障が再発するタイミングに応じて適切なＣＰ情報を用いてシステムを回復させる。
【００１９】
具体的には、計算機上で稼動しているプロセスを監視し当該プロセスの障害の発生を検出する障害検出ステップと、前記障害検出ステップで障害の発生を検出すると、前記プロセスにおいて予め定めた前記プロセスの保全性に影響を与える事象が発生する直前のタイミングで記録した前記プロセスのメモリ状態を用いて、前記障害が発生したプロセスを再始動させる再始動ステップと、を備えることを特徴とする計算機のプロセス回復方法を提供する。
【発明の効果】
【００２０】
本発明によれば、故障の要因が不明確な場合であっても、システムを安全に回復し、業務を迅速に再開する、目的に適ったチェックチェックポイント／リスタート制御技術を提供することができる。
【発明を実施するための最良の形態】
【００２１】
本発明を適用した実施形態を以下に示す。なお、チェックポイント／リスタートの実現手段として，システム構成によって，リスタート時に障害プロセスのメモリを更新するもの、もしくは，障害プロセスとは別に待機プロセスを活性化するもの，の２種類の手段がある。以下の実施形態では，後述するように，攻撃による障害発生も含めているので，とくに断らない限り，後者の待機プロセスを活性化する手段とする。
【００２２】
＜＜第一の実施形態＞＞
本実施形態の情報処理装置５００の構成図を図１に示す。本図に示すように、本実施形態の情報処理装置５００は、マルチプロセッサ５０１と、メモリ５０９と、ストレージ５０６と、ネットワークインタフェース５０７と、入出力インタフェース５０８と、を備える。また、メモリ５０９は、揮発性メモリ（ＤＲＡＭ）５０４と、相変化メモリ（ＰＲＡＭ）５０５と、ストレージ（ＨＤＤ）５０６とを備える。ここでは、マルチプロセッサ５０１は、プロセッサ５０２と５０３との２つを備えるものとする。ただし、プロセッサは１台以上のＣＰＵであればよく、その数は問わない。
【００２３】
ＨＤＤ５０６は、オペレーティングシステムやアプリケーションプログラムなどのソフトウェアをファイルとして記憶する二次記憶である。
【００２４】
ＤＲＡＭ５０４は、オペレーティングシステムやアプリケーションプログラムなどのソフトウェアやデータを記憶する一次記憶である。
【００２５】
マルチプロセッサ５０１は、ＨＤＤ５０６に記憶されているソフトウェアをＤＲＡＭ５０４にロードして実行することにより、後述する各機能を実現する。またマルチプロセッサ５０１は、処理の途中に生成したデータを一時的にＤＲＡＭ５０４に記憶する。
【００２６】
ＰＲＡＭ５０５は、チェックポイント／リスタートで使用するデータを保持する。チェックポイント／リスタートで使用するデータは、各チェックポイントにおいて、再始動するために必要な情報として保持されるプロセスのメモリ状態である。以下、各チェックポイントにおける、保持されるプロセスのメモリ状態のデータをチェックポイント情報（ＣＰ情報）と呼ぶ。また、チェックポイント取得時刻をＣＰｔと表した場合、その時刻ＣＰｔにおいて取得したＣＰ情報をＣＰｔ情報と呼ぶ。なお、ＰＲＡＭ５０５は、改ざん困難な不揮発性メモリであれば、相変化メモリＰＲＡＭ５０５でなくてもよい。
【００２７】
入出力インタフェース５０８は、管理者あるいは監視者からの要求の入力をマルチプロセッサ５０１に伝達し、逆に、マルチプロセッサ５０１で処理した結果を出力する、入出力装置、例えば、キーボード、マウス、ディスプレイ等のデバイスと接続する。
【００２８】
ネットワークインタフェース５０７は、外部の計算機やシステムと接続するネットワークカードである。
【００２９】
本実施形態のマルチプロセッサ５０１がプログラムを実行することにより実現する機能構成を図２に示す。本図に示すように、本実施形態の計算機システム５００は、オペレーティングシステム（ＯＳ）１０１０と、ＯＳ１０１０上で稼動するアプリケーションプログラム（ＡＰ）１０００と、ライブラリ１０２０と、を備える。
【００３０】
本実施形態では、マルチプロセッサ５０１がプログラムを実行することにより、システムコールハンドラ１０１１と、システムコールサービスルーチン１０１２とに加え、システムコール監視処理部１０１４と、チェックポイント／リスタート処理部１０１３と、ライブラリチェックポイント／リスタート処理部（Ｌチェックポイント／リスタート処理部）１０２３と、ライブラリ関数監視処理部１０２４と、を実現する。また、ストレージＨＤＤ５０６には、発行されるシステムコールまたは関数を、その発行順に記録する発行履歴１０１５と、チェックポイント情報を取得する特定のシステムコール、関数、および、システムコール列を記録するコールリスト１０１６と、発行されるライブラリ関数をその発行順に記録するライブラリ発行履歴（Ｌ発行履歴）１０２５と、チェックポイント情報を取得する特定のライブラリ関数を記録するライブラリ関数リスト（Ｌコールリスト）１０２６とが記録される。
【００３１】
なお、図２に示す例では、ライブラリ１０２０とＯＳ１０１０とにそれぞれシステムコール監視部１０１４とライブラリ関数監視部１０２４とが存在し、それぞれが専用のチェックポイント／リスタート機能と連携して動作する。このように図２に示す例は、監視部とチェックポイント／リスタート機能とがライブラリ１０２０とＯＳ１０１０とに別れ、システムで二組存在するものであるが、いずれか一方の組だけが存在するよう構成してもよい。
【００３２】
マルチプロセッサ５０１が実行する監視対象のプロセス１００１が発行するシステムコール、および、関数は、上述のように発行順に発行履歴１０１５に記録される。ライブラリコールについても同様にＬ発行履歴１０２５に記録される。このため、以下においては、システムコールの場合を例にあげて説明する。
【００３３】
また、コールリスト１０１６には、予め定めたシステムコール列、システムコール、関数が記憶される。
【００３４】
システムコール監視処理部１０１４は、プロセス１００１が発行するシステムコールおよび関数を監視し、所定のシステムコール列、システムコールおよび関数（以後、システムコール列と総称する。）が発行されたことを検出するとチェックポイント／リスタート処理部１０１３に通知する。具体的には、プロセス１００１が発行し、発行履歴１０１５に記録されるシステムコール列をコールリスト１０１６に記録されているシステムコール列と照合し、合致した場合、チェックポイント／リスタート処理部１０１３に通知する。
【００３５】
チェックポイント／リスタート処理部１０１３は、システムコール監視処理部１０１４から合致したとの通知を受けると、その時刻およびその時点のメモリ状態をそれぞれ時刻ＣＰ、ＣＰ情報としてＰＲＡＭ５０５に記録する。
【００３６】
また、チェックポイント／リスタート処理部１０１３は、故障が発生した際、ＰＲＡＭ５０５に記録したＣＰ情報を用いて、回復処理を行う。
【００３７】
以下、システムコール監視処理部１０１４およびチェックポイント／リスタート処理部１０１３の処理の詳細を説明する。
【００３８】
まず、システムコール監視処理部１０１４が監視するシステムコール列を、情報処理装置５００がオンライン状態の場合とオフライン状態の場合とに分けて説明する。ここでは、情報処理装置５００がＵＤＰサーバの場合を例にあげて説明する。オンライン状態では、ＵＤＰサーバである情報処理装置５００は、複数のＵＤＰクライアントと情報を送受信し、処理を行う。
【００３９】
図３は、情報処理装置５００（ＵＤＰサーバ）のサーバプロセス１００１が初期化処理を実行する際、データ通信に発行する代表的なシステムコール列を説明するフローである。以下では，情報処理装置５００はハードウェアであり，プロセス１００１はサーバソフトウェアが稼動しているソフトウェアとする。
【００４０】
（ａ）  ＵＤＰサーバプロセス（情報処理装置５００）側
ＵＤＰサーバプロセスは、ｓｏｃｋｅｔシステムコールを用いて、それぞれのクライアントとの通信路を区別するために、それぞれエンドポイント（ソケット）を作成する（ｓ７０１）。
【００４１】
次に、ＵＤＰサーバは、ｂｉｎｄシステムコールを用いて、作成したソケットに名前をつける（ｓ７０２）。
【００４２】
そして、ＵＤＰサーバは、ｓｅｌｅｃｔシステムコールを用いて、複数のソケットを監視し、クライアントからのデータ送信を待つ（ｓ７０３）。
【００４３】
クライアントからの送信があると、ＵＤＰサーバは、ｒｅｃｖｆｒｏｍシステムコールを用いて、ソケットを介して要求データを受信する（ｓ７０４）。
【００４４】
そして、ＵＤＰサーバは、ｓｅｎｄｔｏシステムコールを用いて、ソケットを介して応答データを送信する（ｓ７０５）。その後、クライアントからの入力を待つ状態に戻る（ｓ７０３）。
【００４５】
（ｂ）ＵＤＰクライアント側
ＵＤＰクライアントは、ｓｏｃｋｅｔシステムコールを用いて、特定のＵＤＰサーバとの通信を目的としたエンドポイント（ソケット）を作成する（ｓ７１１）
ＵＤＰクライアントは、ｓｅｎｄｔｏシステムコールを用いて、ソケットを介して要求データをＵＤＰサーバに送信する（ｓ７１２）
ＵＤＰクライアントは、ｒｅｃｖｆｒｏｍシステムコールを用いて、ソケットを介して応答データをＵＤＰサーバから受信する（ｓ７１３）。
【００４６】
ＵＤＰクライアントは、ＵＤＰサーバとの間で行う処理が完了するまで、ｓ７１２とｓ７１３とを繰り返し、処理が完了すると、ｃｌｏｓｅシステムコールを行い、プロセスを終了する（ｓ７１４）。
【００４７】
本実施形態では、プロセス１００１の状態が大きく変化する直前のメモリ状態をＣＰ情報として記録する。本実施形態においては、情報処理装置５００がＵＤＰサーバの場合、上述のＵＤＰサーバにおける典型的なシステムコールのシーケンスに着目し、ＣＰ情報取得タイミングを決定する。以下においてシステムの状態が大きく変化する直前を判断可能なシステムコール列をシステムの保全性に影響するシステムコール列と呼ぶ。
【００４８】
まず、システムの保全性に影響を与えるシステムコール列として、オフライン状態からオンライン状態に変わる直前の状態を検出可能なシステムコール列がある。プロセス１００１開始時は、ＵＤＰサーバでは、…、ｓｏｃｋｅｔ、ｓｏｃｋｅｔ、ｂｉｎｄ、ｂｉｎｄ、ｓｅｌｅｃｔ、ｒｅｃｖｆｒｏｍ、…の順序でシステムコールが発行される。上述のようにｒｅｃｖｆｒｏｍシステムコールが発行されたときは、ソケットを介してＵＤＰクライアントから要求データを受信した状態、すなわち、オンラインでの使用が開始された状態である。ｓｏｃｋｅｔ、ｓｏｃｋｅｔ、ｂｉｎｄ、ｂｉｎｄ、の順にシステムコールが発行され、続いてｓｅｌｅｃｔシステムが発行されたタイミングが、オンライン状態となる直前のメモリ状態といえる。このタイミングでＣＰ情報を取得することにより、オンライン使用直前のメモリ状態をＣＰ情報として保存することができる。なお、オンライン直前のメモリ状態として取得するＣＰ情報を、ＣＰ０情報と呼ぶ。また、その時刻をＣＰ０とする。
【００４９】
本実施形態では、ＣＰ０情報を取得するタイミングとして、コールリスト１０１６にシステムコール列Ｓ０（ホワイトリスト）ｓｏｃｋｅｔ、ｓｏｃｋｅｔ、ｂｉｎｄ、ｂｉｎｄ、ｓｅｌｅｃｔを予め記録しておく。システムコール監視処理部１０１４は、ｓｏｃｋｅｔ、ｓｏｃｋｅｔ、ｂｉｎｄ、ｂｉｎｄ、の順にシステムコールが発行され、続いてｓｅｌｅｃｔが発行されると、ＣＰ情報を取得するようチェックポイント／リスタート処理部１０１３に通知する。チェックポイント／リスタート処理部１０１３は、通知を受けると、その時点のメモリ状態をＣＰ０情報としてＰＲＡＭ５０５に記録するとともに、その時刻ＣＰ０をＣＰ０情報に対応づけて記録する。
【００５０】
一方、発行されたシステムコール列がその他のものの場合、例えば、…、ｓｏｃｋｅｔ、ｓｏｃｋｅｔ、ｂｉｎｄ、ｂｉｎｄ、ｒｅｃｖｆｒｏｍ、…の場合は、予めＨＤＤ５０６にシステムコール列Ｓ０として記録されたシステムコール列と異なるため、メモリ状態を取得しない。
【００５１】
次に、オンライン状態でシステムの保全性に影響を与えるシステムコール列について説明する。オンライン状態でシステムの保全性に影響を与える作業としては、ファイルの更新、セキュリティパッチ処理がある。
【００５２】
図４は、情報処理装置５００がオンライン状態においてファイル更新という保守作業が行われる場合を説明するための図である。
【００５３】
通常時は、図４に示すように、情報処理装置５００（ＵＤＰサーバ）は、ｒｅｃｖｆｒｏｍ（Ｓ８０１）とｓｅｎｄｔｏ（ｓ８０２）とを繰り返して処理を進める。すなわち、発行されるシステムコール列は
填、ｒｅｃｖｆｒｏｍ、ｓｅｎｄｔｏ、ｒｅｃｖｆｏｒｍ、ｓｅｎｄｔｏ、ｒｅｃｖｆｒｏｍ、…
である。
【００５４】
保守のためにファイル更新が行われる場合は、遠隔より入力されたデータによって、プログラムの動作を変え、バイナリファイルや定義ファイルを更新する。この時、ファイルに書き込むため、ｗｒｉｔｅシステムコールが発行される。この場合は、ｒｅｃｖｆｒｏｍ（Ｓ８０３）、ｗｒｉｔｅ（ｓ８０４）、ｓｅｎｄｔｏ（ｓ８０５）の順にシステムコールが発行され、処理が進められる。すなわち、発行されるシステムコール列は
…、ｒｅｃｖｆｒｏｍ、ｓｅｎｄｔｏ、ｒｅｃｖｆｏｒｍ、ｗｒｉｔｅ、ｓｅｎｄｔｏ、ｒｅｃｖｆｒｏｍ、…
となる。
【００５５】
ｗｒｉｔｅシステムコールによって、ファイルが書き換えられるため、ｗｒｉｔｅシステムコールが保全性を変更するシステムコールにあたる。従って、システムの保全性に影響を与える処理が行われる直前のメモリ状態を保存するためには、ｗｒｉｔｅシステムコールが発行された後であって、システムコールサブルーチン１０１２において処理が実行される前にＣＰ情報を取得する。
【００５６】
すなわち、システムコール監視処理部１０１４は、ｗｒｉｔｅシステムコールが発行されたことを検出すると、その旨を、チェックポイント／リスタート処理部１０１３に通知する。チェックポイント／リスタート処理部１０１３は、通知を受けるとその時点のＣＰ情報および時刻を示すＣＰを対応づけてＰＲＡＭ５０５に記録する。
【００５７】
以上では、ＯＳ１０１０のシステムコール監視部１０１４により実現する場合を例にあげて説明した。プロセス１００１は、ＡＰ１０００より呼び出されるソフトウェアであればよい。ＡＰ１０００とＯＳ１０１０との間に存在するライブラリ１０２０（複数のアプリケーションで共通に利用する関数を集めたソフトウェア）のライブラリ監視処理部１０２４でライブラリ関数を監視し、実現する場合も同様である。以下、ライブラリ関数監視部１０２４により実現する場合を説明する。
【００５８】
図５は、情報処理装置５００がオンライン状態においてセキュリティパッチ処理が行われる場合を説明するための図である。
【００５９】
セキュリティパッチ処理は、多数存在する。たとえば、プロセス１００１における、規定の保守手順として，保全性を向上させるソフトウェアモジュールを含むライブラリが存在するプロセス１００１の内容を修正または機能を追加した後に、ライブラリをアンロードするものがある。
【００６０】
ここでは、ライブラリは、ネットワーク５０７から送られ、ストレージＨＤＤ５０６において、ファイルとして一旦保管されるものとする。
【００６１】
セキュリティパッチ処理を行う場合の手順は以下のとおりである。
【００６２】
セキュリティパッチ処理を行う指示を受け取ると、情報処理装置５００は、ｄｌｏｐｅｎ関数を用いて、保守用のソフトウェアを内蔵するライブラリを動的にロードする（ｓ９０１）。
【００６３】
プロセス１００１は、ｄｌｓｙｍ関数を用いて、ｓ９０１でロードしたライブラリから保守用の関数を取得する（ｓ９０２）。
【００６４】
保守用の関数を呼び出し、メモリ上のプロセスに対してパッチをあてる。ここでは、パッチプログラムの書き込みにｍｍａｐシステムコールを利用する（ｓ９０３）。
【００６５】
ｄｌｃｌｏｓｅ関数を用いて、ライブラリをアンロードする。
【００６６】
従って、ここでは、関数およびシステムコールは以下の順に発行される。
…、ｄｌｏｐｅｎ、ｄｌｓｙｍ、…、ｍｍａｐ、…、ｄｌｃｏｓｅ、…
ライブラリを動的にロードすることにより、メモリの状態が変化する。従って、プロセス１００１がｄｌｏｐｅｎ関数を発行し、ライブラリ内部で処理を実行する前のメモリ状態を、ＣＰ情報として保存する。
【００６７】
すなわち、ライブラリ関数監視処理部１０２４はｄｌｏｐｅｎ関数が発行されたことを検出すると、その旨を、Ｌチェックポイント／リスタート処理部１０２３に通知する。Ｌチェックポイント／リスタート処理部１０２３は、通知を受けるとその時点のＣＰ情報および時刻を示すＣＰを対応づけてＰＲＡＭ５０５に記録する。
【００６８】
以上、保全性を変更するシステムコールあるいは関数が発行された場合に、ＯＳもしくはライブラリにおいて，ＣＰ情報を取得する具体的な手順を説明した。このように、本実施形態では、プロセスの保全性の維持に着目してＣＰ情報を自動的に取得する。
【００６９】
ここで、監視する対象のシステムコール列について、オフライン状態とオンライン状態とを分けている理由について説明する。
【００７０】
図３で説明したオフライン状態では、初期化処理、例えば、定義ファイルの読み込みなど、定常状態に至るまでの処理手順は厳密に定まっている。そのために、アプリケーション毎にプロセス１００１が発行するシステムコール列は一意に定まる可能性が高い。このため、特定のシステムコール列Ｓ０を予め記録しておき、実際に発行されているシステムコール列と照合し、ＣＰ０情報取得タイミングを決定することが可能である。
【００７１】
しかし、図４および図５で説明したオンライン状態では、サーバプログラムは、クライアントプログラムからの要求に応じて、異なる処理を実行する。それに応じて、システムコール列は一意に定まらず、変化する傾向がある。従って、複雑な業務を実現するアプリケーションプログラムでは、多種類のシステムコール列が存在し，たとえば、保守作業に限定した特定のシステムコール列を検出することは難しい。特定のシステムコールレ地を検出するためには、たとえば、アプリケーションプログラムの動作やプロセスの状態を管理し、システムコールの引数について、業務にあわせて内容を確認する、などの確認処理を必要とする。
【００７２】
しかし、システムコール列の引数について全てのパターンを事前に抽出できるとは限らず、確認処理は煩雑となる。たとえば、数十から数百程度のつながるシステムコールの発行を履歴として記録し、その一方で，対応するシステムコール列について、正常状態、異常状態、監視要の状態、例外処理，保守作業などの区別をつけたリスト、たとえば、数十から数千を準備する必要がある。また、システムコールが発行される度に、上述の確認処理を実行することは、業務本来のデータ処理を遅延することになる。
【００７３】
オンライン状態であっても、システムコール列の監視が望ましい。しかし、上述のようにアプリケーションプログラムの特性によっては、システムコールの正当性について確認するのに、処理時間を要する。このため、本来のデータ処理に遅延が発生する恐れが有る。したがって、システムコール単独の監視に留めておいた方が望ましいといえる。
【００７４】
そこで、オンライン状態において、ある程度検出の精度を保ちつつ、実時間で確認するために、システムコール列ではなく、特定のシステムコールまたは関数が発行された場合にＣＰ情報を取得する。
【００７５】
すなわち、オフラインではシステムコール列（システムコールの発行順序）を厳密に監視し、オンラインでは、特定のシステムコールまたは関数が発行されるかどうかを監視する。
【００７６】
次に、本実施形態のチェックポイント／リスタート処理部１０１３が再始動を行う場合、故障要因を区分し、その後の処理を決定するために導入する再故障寿命Ｔと再発故障間隔Ｔ'とについて説明する。
【００７７】
故障が発生した場合、チェックポイント／リスタート処理部１０１３は、故障が発生した時刻を記録するとともに、所定のＣＰｉ情報を用いて再始動し、回復処理を行う。
【００７８】
第１回目の故障が発生した時刻をｔ１とする。回復処理に用いたＣＰｉ情報を取得した時刻ＣＰｉから、故障が発生した時刻ｔ１までの時間を、再度故障が発生する予測時刻としてＣＰｉ情報の再故障寿命Ｔと呼ぶ。また、回復処理に用いたＣＰｉ情報を取得した時刻ＣＰｉから、回復処理後、再度故障が発生した時刻ｔ２までの時間を、実際に故障が再発した時刻としてＣＰｉ情報の再発故障間隔Ｔ'と呼ぶ。再故障寿命Ｔと再発故障間隔Ｔ'  は、それぞれ、チェックポイント／リスタート処理部１０１３が故障発生毎に算出する。
【００７９】
チェックポイント／リスタート処理部１０１３は、１回目の故障が発生すると、最近のＣＰ情報を用いて回復処理を行う。次のＣＰ情報を取得する前に２回目の同じ故障が発生した場合、チェックポイント／リスタート処理部１０１３は、回復処理に用いたＣＰ情報の再故障寿命Ｔと再発故障間隔Ｔ'とを比較し、再故障寿命Ｔが再発故障間隔Ｔ'より短い場合は、３回目の同じ故障が発生した場合であっても、同じＣＰ情報を用いて回復処理を続ける。
【００８０】
一方、２回目の同じ故障が発生した際、再発故障間隔Ｔ'が再故障寿命Ｔ以下の場合、チェックポイント／リスタート処理部１０１３は、先に回復処理に用いた最新のＣＰ情報の１回前に保存したＣＰ情報を用いて回復処理を行う。
【００８１】
次のＣＰ情報を取得する前に３回目の同じ故障が発生した場合、チェックポイント／リスタート処理部１０１３は、同様に回復処理に用いたＣＰ情報の再故障寿命Ｔと再発故障時間間隔Ｔ'とを比較し、Ｔ＜Ｔ'の場合、同じＣＰ情報を用いて回復処理を行う。一方Ｔ≧Ｔ'の場合は、さらに１回前に記録したＣＰ情報を用いて回復処理を行う。
【００８２】
なお、ＣＰ情報を呼び出して状態を回復することを再始動と呼ぶと定義している。本実施形態の場合、複数のＣＰ情報を保持しているため、再度故障が発生した場合、先の再始動時と同じＣＰ情報を用いる場合と、別のＣＰ情報を用いる場合とがある。ここでは、同じＣＰ情報を用いて回復処理を行うことを再試行と呼び、新たなＣＰ情報を用いて回復処理を行うことを再始動と呼び、区別する。
【００８３】
以上のように、本実施形態では、チェックポイント／リスタート処理部１０１３は、新たなＣＰ情報を取得する前に同じ故障が再発した場合、再故障寿命Ｔと再発故障間隔Ｔ'  とを比較し、Ｔ＜Ｔ'の場合再試行を行い、Ｔ≧Ｔ'の場合は、先に再始動を行ったＣＰ情報の１回前に記録したＣＰ情報を用いて再始動を行う。
【００８４】
なお、上記おいては、最も近い時点で記録したＣＰ情報が故障発生時の状態に最も近いため、故障発生時に１回前のＣＰ情報を、再故障時には、さらに１回前のＣＰ情報を用いる場合を例にあげて説明したが、用いるＣＰ情報はこれに限られない。予め定めた分だけ遡ったＣＰ情報を用いるよう構成してもよい。
【００８５】
なお、本実施形態では、故障が発生する毎に、チェックポイント／リスタート処理部１０１３が情報処理装置５００のＯＳ１０１０或いはプロセス１００１が発行するエラーコードをＰＲＡＭ５０５等のメモリに時刻とともに記録しておく。この記録を用いて、チェックポイント／リスタート処理部１０１３は、２回目以降の故障について、同じ故障の再発であるか、異なる故障の発生かを判断する。
【００８６】
次に、図６を用いて、チェックポイント／リスタート処理部１０１３が再試行または再始動を行う処理について、具体例をあげて説明する。
【００８７】
図６は、ＣＰ情報の再故障寿命ＴとＣＰ情報の再発故障間隔Ｔ'との関係によって、チェックポイント／リスタート処理部１０１３が再試行または再始動を行う様子を説明するための図である。
【００８８】
なお、本図において、オフライン状態においてオンライン状態の直前に取得するＣＰ情報をＣＰ０情報、その時刻をＣＰ０と呼び、オンライン状態でＣＰ情報を取得するタイミングを、時刻順にＣＰ１、ＣＰ２、…ＣＰｎ−１、ＣＰｎ、ＣＰｎ＋１と呼び、それぞれの時刻に対応づけてＰＲＡＭ５０５に記録されるＣＰ情報を、それぞれ、ＣＰ１情報、ＣＰ２情報、…、ＣＰｎ−１情報、ＣＰｎ情報、ＣＰｎ＋１情報と呼ぶ。また、以下、同じ故障は同じ文字で表し、何回目の故障であるかをダッシュで示す。図において、Ｐ'、Ｐ''は、再始動、再試行開始点を示す。
【００８９】
図６（ａ）は、ＣＰｎ情報の再故障寿命ＴｎとＣＰｎ情報の再発故障間隔Ｔｎ'との関係がＴｎ＜Ｔｎ'であり、ＣＰｎ情報を用いて再試行する場合の例である。偶発による故障は、このような発生パターンとなる可能性が高い。これは従来方式での手順に相当する。
【００９０】
ＣＰｎ時点でＣＰｎ情報を記録した後、次のＣＰｎ＋１情報を記録する前の時刻ｔｘに１回目の故障Ｘが発生すると、直前に記録したＣＰｎ情報を用いて再始動を行う。詳しくは、故障Ｘが発生すると、チェックポイント／リスタート処理部１０１３が、直前に記録したＣＰｎ情報を再始動のために使用するＣＰｎ情報と決定し、ＣＰｎ情報を用いて再始動を行う。
【００９１】
ＣＰｎの再故障寿命Ｔｎは直前のＣＰｎ情報を取得した時刻ＣＰｎから故障Ｘ発生時ｔｘまでの時間である。一方、回復処理を行った後、次のＣＰ情報であるＣＰｎ＋１情報を取得する時刻ＣＰｎ＋１前に再度故障Ｘ'（２回目の故障Ｘ'）が発生した場合、ＣＰｎの再故障間隔Ｔｎ'は、ＣＰｎ情報を用いて再始動後、実際に再度故障Ｘ'が発生するまでの時間ｔｘ'である。
【００９２】
ここでは、ＣＰｎの再故障間隔Ｔｎ'がＣＰｎの再故障寿命Ｔｎより長く、Ｔｎ＜Ｔｎ'  であるため、チェックポイント／リスタート処理部１０１３は、ＣＰｎ情報を用いて再試行を行う。
【００９３】
なお、このとき、故障Ｘ''発生時前にＣＰｎ＋１情報を取得していた場合は、故障Ｘ''発生時はＣＰｎ＋１情報を用いて回復処理を行う。
【００９４】
図６（ｂ）は、ＣＰｎ情報の再故障寿命ＴｎとＣＰｎ情報の再発故障間隔Ｔｎ'との関係がＴｎ≧Ｔｎ'であり、ＣＰｎ情報の１回前に記録したＣＰｎ−１情報を用いて再始動を行うと、ＣＰｎ−１情報の再故障寿命Ｔｎ−１とＣＰｎ−１情報の再発故障間隔Ｔｎ−１'との関係はＴｎ−１＜Ｔｎ−１'となり、その後は、ＣＰｎ−１を用いて再試行を繰り返す場合の例である。事故による故障は、このような発生パターンとなる可能性が高い。
【００９５】
ＣＰｎ時点でＣＰｎ情報を取得した後、次のＣＰｎ＋１情報を取得する前に１回目の故障Ｙが発生すると、チェックポイント／リスタート処理部１０１３は、図６（ａ）で説明した手順で直前に記録したＣＰｎ情報を用いて再始動を行う。ＣＰｎの再故障寿命Ｔｎは、直前のＣＰ情報を取得したＣＰｎから故障Ｙ発生時ｔｙまでの時間であり、再故障間隔Ｔｎ'は、ＣＰｎ情報を用いて再始動後、２回目の故障Ｙ'が発生するまでの時間ｔｙ'である。ここでは、Ｔｎ≧Ｔｎ'である。
【００９６】
ＣＰｎ−１の再故障寿命Ｔｎ−１はＣＰｎ−１情報を取得した時刻ＣＰｎ−１から故障Ｙ発生時ｔｘまでの時間である。一方、回復処理を行った後、次のＣＰ情報であるＣＰｎ＋１情報を取得する時刻ＣＰｎ＋１前に再度故障Ｙ''（３回目の故障Ｙ''）が発生した場合、ＣＰｎ−１の再故障間隔Ｔｎ−１'は、ＣＰｎ−１情報を用いて再始動後、実際に再度故障Ｙ''が発生するまでの時間ｔｙ''である。ここでは、Ｔｎ−１＜Ｔｎ−１'であるため、チェックポイント／リスタート処理部１０１３は、ＣＰｎ−１情報を用いて再試行を行う。
【００９７】
図６（ｃ）は、ＣＰ情報の再故障寿命ＴとＣＰ情報の再発故障間隔Ｔ'との関係がＴ≧Ｔ'であることが繰り返される場合の例である。同一の故障が発生する毎に更に１回前に記録したＣＰ情報を用いて再始動を行う。最終的にはネットワークに接続する直前のメモリ状態を記録したＣＰ０情報を用いて再始動を行う。例えば、ウィルスによる攻撃により発生した故障の場合、ウィルスが取り込まれた時点と故障が発症する時点との間にタイムラグがあることが多い。このような場合は、図６（ｃ）に示すような故障発生パターンとなる可能性が高い。
【００９８】
ＣＰｎ時点でＣＰｎ情報を取得した後、次のＣＰｎ＋１情報を取得する前に１回目の故障Ｚが発生すると、チェックポイント／リスタート処理部１０１３は、図６（ａ）で説明した手順で直前に記録したＣＰｎ情報を用いて再始動を行う。ＣＰｎの再故障寿命Ｔｎは、直前のＣＰ情報を取得したＣＰｎから故障Ｚ発生時ｔｚまでの時間であり、再故障間隔Ｔｎ'は、ＣＰｎ情報を用いて再始動後、２回目の故障Ｚ'が発生するまでの時間ｔｚ'である。ここでは、Ｔｎ≧Ｔｎ'である。
【００９９】
ＣＰｎ−１の再故障寿命Ｔｎ−１はＣＰｎ−１情報を取得した時刻ＣＰｎ−１から故障Ｚ発生時ｔｚまでの時間である。一方、回復処理を行った後、次のＣＰ情報であるＣＰｎ＋１情報を取得する時刻ＣＰｎ＋１前に再度故障Ｚ''（３回目の故障Ｚ''）が発生した場合、ＣＰｎ−１の再発故障間隔Ｔｎ−１'は、ＣＰｎ−１情報を用いて再始動後、実際に再度故障Ｚ''が発生するまでの時間ｔｚ''である。ここでも、Ｔｎ−１≧Ｔｎ−１'であるため、チェックポイント／リスタート処理部１０１３は、更に１回前に記録したＣＰｎー２情報に戻る。
【０１００】
チェックポイント／リスタート処理部１０１３は、故障発生毎に再故障寿命Ｔと再発故障間隔Ｔ'を計算し、比較し、Ｔ≧Ｔ'である限り、更に１回前のＣＰ情報を用いて再始動を行うことを、用いるＣＰ情報がＣＰ０情報となるまで繰り返す。
【０１０１】
なお、図６（ｃ）のケースにおいて、故障が再発する度に１つずつ遡ってＣＰ情報を用いて再始動しているが、本構成に限られない。例えば、最初の故障時にＣＰｎ情報を用いて再始動した後、故障が再発した場合、ＣＰ０情報を用いて再始動するよう構成するなど、ＣＰ０情報を用いる前に順次遡って用いるＣＰ情報の回数を予め定めておいてもよい。
【０１０２】
次に、上記チェックポイント／リスタート処理部１０１３が故障発生毎に記録する時刻について説明する。情報処理装置５００が単一のサービス、単一のプロセスで実行されている場合は、問題とならないが、複数のサービス、複数のプロセスが並行して実行されている場合、処理時間が計測中のプロセス１００１以外のプロセス等に影響を受けることがある。
【０１０３】
一般にシステムの時間として用いられるものには、経過時間４０１、ユーザ時間４０２、システム時間４０６がある。図７は、これらの経過時間４０１、ユーザ時間４０２、システム時間４０６の３種類の時間についてモデルを用いて説明するための図である。各ＣＰｎ情報取得時に、これらの時間がＣＰｎとしてＰＲＡＭ５０５に記録される。
【０１０４】
なお、経過時間４０１は、情報処理装置５００を外部から見た場合の時間に相当する。ユーザ時間４０２は、プロセス１００１がユーザモード（ＯＳ１０１０の一部として機能分類されている保護されたサブシステムとアプリケーションプログラム１０００とが動作する状態。）で動作した時間であり、システム時間４０６は、プロセス１００１がカーネルモード（スケジューラ，メモリ管理，プロセス管理などのプリミティブなＯＳ機能のみが動作する状態。）で動作した時間である。
【０１０５】
また、本図において累積回数４０５、４０７は、システムコールの発行回数の累積値のことである。マルチプロセッサ５０１での時刻計測は、必ずしも正確とはいえない場合があるため、システムコールの発行回数の累積値（システムコールの累積回数４０５、４０７）を利用することがより簡便に正確な処理を行うことができる場合がある。これらは後述する第２の実施形態で用いる。第２の実施形態では、システムコールの累積回数４０５、４０７を用いて故障時の回復処理手順を決定する。
【０１０６】
再故障寿命Ｔと再発故障間隔Ｔ'との算出にいずれの時間を用いるかは、攻撃の型に応じて使い分けることが望ましい。例えば、無限ループを実行し、ＣＰＵの実行時間を浪費する型の攻撃であれば、ユーザ時間４０２を用いる。タイムアウトとなる入出力を行うシステムコールの発行を繰り返すことで、ＣＰＵの実行時間を浪費する型の攻撃であれば、システム時間を、それぞれ選択することで攻撃にあわせた精度の高い時間測定が可能となる。
【０１０７】
次に、本実施形態のチェックポイント／リスタート処理部１０１３が、所定のプロセス１００１を監視しながらＣＰ情報を取得し、故障が発生した場合に取得したＣＰ情報を用いて回復処理を行う処理フローについて説明する。
【０１０８】
図８は、チェックポイント／リスタート処理部１０１３がシステムコール監視処理部１０１４からの通知に基づいてＣＰ情報を取得するＣＰ情報取得処理の処理フローである。
【０１０９】
本実施形態では、オンライン状態でＰＲＡＭ５０５に保存するＣＰ情報の最大保存数を世代数ｍと呼ぶ。ＣＰ０情報以外のＣＰ情報は、新規に世代数ｍを越えて新規に取得した場合、古いものから順に削除される。例えば、世代数ｍを２と設定した場合、最新のものとその１回前の計２回分のＣＰ情報を保存する。なお、保存するＣＰ情報の数の決め方は本方法に限られない。例えば、保存先のＰＲＡＭ５０５の最大容量まで記録し、その後は古いものから順に上書きすることにより消去するよう構成してもよい。
【０１１０】
また、オンライン状態でＣＰ情報を取得した回数を累計数ｎと呼ぶ。以下、累計数ｎを用いて、ＣＰ情報を取得する時刻をＣＰｎ、ＣＰｎにおいて取得したＣＰ情報をＣＰｎ情報と表す。
【０１１１】
チェックポイント／リスタート処理部１０１３は、プロセス１００１が処理を開始すると、予め管理者等により設定されたＣＰを保存する世代数ｍを参照する（ｓ６０１）。
【０１１２】
チェックポイント／リスタート処理部１０１３は、保存するＣＰ情報数をカウントするカウンタをｎ（累計数と呼ぶ）とし、累計数ｎに初期値０を設定する（ｓ６０２）。
【０１１３】
システムコール監視処理部１０１４は、プロセス１００１が発行するシステムコール列Ｓを監視する（Ｓ６０３）。システム監視処理部１０１４は、情報処理装置５００がオフライン状態の場合、システムコール列Ｓ０の発行の有無を監視する。監視中にコールリスト１０１６に保存されているシステムコール列Ｓ０が発生したことを検出すると（ｓ６０４）、システムコール監視処理部１０１４はチェックポイント／リスタート処理部１０１３に検出を通知する。通知を受けたチェックポイント／リスタート処理部１０１３は、通知を受けた時刻をＣＰ０とし、ＣＰ０時点のプロセス１００１のメモリ状態をＤＲＡＭ５０４上で複製することによりＣＰ情報を取得し、ＣＰ０情報とする（ｓ６０５）。
【０１１４】
チェックポイント／リスタート処理部１０１３は、時刻ＣＰ０を時刻ｔ０とし、Ｓ６０４で取得したＣＰ０情報をＤＲＡＭ５０４からＰＲＡＭ５０５に転送し、時刻ＣＰ０と対応づけてＣＰ０情報をＰＲＡＭ５０５に記録する（ｓ６０６）。
【０１１５】
情報処理装置５００がネットワークインタフェース５０７を介して他の装置やシステムと接続されたことを検出すると（ｓ６０７）、システムコール監視処理部１０１４は、プロセス１００１のシステムコール列Ｓの監視をオンライン状態の監視に切り替える。
【０１１６】
オンライン状態になると、システムコール監視処理部１０１４は、引き続きプロセス１００１が発行するシステムコール列Ｓを監視する（ｓ６０８）。ここでは、システムコール監視処理部１０１４は、上述のｗｒｉｔｅシステムコールまたは関数ｄｌｏｐｅｎの発行の有無を監視する。なお、オンライン状態になると、チェックポイント／リスタート処理部１０１３は故障の発生を監視する。そして、故障を検出した場合（ｓ６０９）は、後述する図９のＣＰ回復処理を行う。
【０１１７】
システムコール監視処理部１０１４が、システムコール列Ｓ監視中にオンライン状態における予め定めたシステムコールまたは関数を検出するとチェックポイント／リスタート処理部１０１３に通知する（ｓ６１０）。
【０１１８】
チェックポイント／リスタート処理部１０１３は、累計数ｎを１インクリメントし（ｓ６１１）、そして、検出時刻ＣＰｎと、ＣＰｎ時点のメモリの状態をＣＰｎ情報としてｓ６０５と同様に取得する（ｓ６１２）。
【０１１９】
次に、チェックポイント／リスタート処理部１０１３は、累計数ｎと世代数ｍとを比較する（ｓ６１３）。累計数ｎが世代数より大きい場合、既に世代数ｍ分ＰＲＡＭ５０５に記録されている。この場合、最も古いＣＰ情報（ここでは、ＣＰｎ−ｍ情報）をＰＲＡＭ５０５から削除してから新たに取得したＣＰｎ情報をＰＲＡＭ５０５を記録する（ｓ６１４、ｓ６１５）。
【０１２０】
具体的には、Ｓ６１３における比較の結果、累計数ｎが世代数ｍより大きい場合、ＰＲＡＭ５０５における最も古いＣＰ情報であるＣＰｎ−ｍ情報をＰＲＡＭ５０５から削除する。その後、新たに取得したＣＰｎ情報をＰＲＡＭ５０５に記録する。一方、ｓ６１３における比較の結果、累計数ｎが世代数ｍ以下の場合、Ｓ６１４の処理は行わず、新たに取得したＣＰｎ情報をＰＲＡＭ５０５に記録する（ｓ６１４、ｓ６１５）。
【０１２１】
その後、システムコール監視処理部１０１４がシステムコール列の監視を行う状態に戻る（ｓ６０８）。
【０１２２】
次に、図８に示すＣＰ情報取得処理において、チェックポイント／リスタート処理部１０１３が故障を検出した際のＣＰ回復処理について説明する。図９は、ＣＰ回復処理の処理フローである。
【０１２３】
チェックポイント／リスタート処理部１０１３は、故障を検出すると、故障発生時刻（故障を検出した時刻）ｔｘをＰＲＡＭ５０５に記録する（ｓ１０１）。そして、情報処理装置５００をオフラインにする（回線切断処理）（ｓ１０２）。
【０１２４】
また、チェックポイント／リスタート処理部１０１３は、その時点の累計数ｎをカウンタｉに代入する（ｓ１０３）。そして、ＣＰｉ情報がＰＲＡＭ５０５に記録されているか否かを判別する（ｓ１０４）。
【０１２５】
ｓ１０４で記録されていない場合は、後述するｓ１１３に処理を進める。
【０１２６】
一方、ｓ１０４で記録されている場合、チェックポイント／リスタート処理部１０１３は、ＣＰｉ情報に対応づけて記録されているＣＰｉ情報を取得した時刻ＣＰｉと先に記録した故障時刻ｔｘとを用いて再故障寿命Ｔｉを算出して代入する（Ｔｉ＝ｔｘ−ＣＰｉ）（ｓ１０５）。
【０１２７】
そして、チェックポイント／リスタート処理部１０１３は、ＣＰｉ情報を用いて回復処理を行う（ｓ１０６）。
【０１２８】
回復処理を行い、オンライン状態になると（ｓ１０７）、チェックポイント／リスタート処理部１０１３は、故障の発生の監視を続ける（ｓ１０８）。なお、ここで、チェックポイント／リスタート処理部１０１３が故障を検出する前にシステムコール監視処理部１０１４がシステムコール列Ｓを検出すると、図８のステップｓ６１１に戻る。
【０１２９】
一方、システムコール監視処理部１０１４がシステムコール列Ｓを検出する前にチェックポイント／リスタート処理部１０１３が、先に検出した故障と同じ故障を検出すると（ｓ１０８）、故障を検出した時刻ｔｘ'記録する（ｓ１０９）。そして、オフライン（回線切断）所栄を行う（ｓ１１０）。
【０１３０】
そして、チェックポイント／リスタート処理部１０１３は、時刻ｔｘ'および、時刻ＣＰｉを用いて、再発故障間隔Ｔｉ'を算出する（Ｔｉ'＝ｔｘ'−ＣＰｉ）（ｓ１１１）。
【０１３１】
そして、チェックポイント／リスタート処理部１０１３は、再故障寿命Ｔｉと再発故障間隔Ｔｉ'  とを比較する（ｓ１１２）。
【０１３２】
再故障寿命Ｔｉの期間が過ぎてから故障が再発した場合、すなわち、再故障寿命Ｔｉが再発故障間隔Ｔｉ'以上（Ｔｉ≧ＴＩ'）の場合、ステップＳ１０６に戻り、同じＣＰｉ情報を用いて回復処理を行う（再試行）。
【０１３３】
一方、再故障寿命Ｔｉ前に故障が発生した場合、すなわち、再故障寿命Ｔｉが再発故障間隔Ｔｉ'より短い（Ｔｉ＜Ｔｉ'）場合、カウンタｉを１デクリメントし（ｓ１１３）、カウンタｉが負の値か否かを判別し（ｓ１１４）、負の値であれば、チェックポイント／リスタート処理部１０１３は、業務（プロセス１００１）を停止させる（ｓ１１５）。
【０１３４】
一方、カウンタｉが負の値でなければ（ｓ１１４）、ステップＳ１０５に戻り、１回前に記録したＣＰｉ情報を用いて回復処理を行う（再始動：ＣＰ情報の後退）。
【０１３５】
以上、本実施形態のチェックポイント／リスタート処理部１０１３によるＣＰ回復処理について説明した。
【０１３６】
本実施形態では、上述のように、プロセスを始動させたＣＰ情報を取得した時刻（ＣＰ）から故障するまでの時間を計測し、再故障寿命として設定する。故障発生後、所定のＣＰ情報を用いて、プロセスを再始動させる。そして、その再始動時に用いたＣＰ情報を取得した時刻から再び故障するまでの時間を計測し、再発故障間隔とする。再故障寿命と再発故障間隔とを比較し、再発故障間隔より再故障寿命が長いプロセスの場合、１回前に取得したＣＰ情報を用いてプロセスを再始動させる。このとき、再始動に用いたＣＰ情報を取得した時刻から最初の故障までの経過時間をもとに再故障寿命を再設定する。なお、プロセスの実時間の代わりに、プロセスのユーザ時間を利用する。あるいは、プロセスのシステム時間を利用することもできる。
【０１３７】
本実施形態では、回復処理（再始動、再試行）に用いるＣＰ情報を、予め定めたシステムコール列検出時に自動的に取得する。すなわち、ＡＰの埋め込みやオペレータの操作ではなく、ＯＳ自体が、ＣＰ情報を取得する。
【０１３８】
具体的には、本実施形態の情報処理装置は、システムコールを監視する手段と、当該手段から呼び出される、監視対象のプロセスの保全性を変更する、システムコールの一覧表を参照する手段を備える。また、オンラインプロセスのＣＰ情報を取得する手段と、任意のＣＰ情報を用いてプロセスを再始動する手段と、を備える。さらに、ＣＰ情報を取得する手段から呼び出されるファイルを複製する手段と、プロセスを再始動する手段から呼び出されるファイルを復元する手段とを備える。
【０１３９】
保全性を変更するシステムコールは具体的には、オンラインからオフラインへ切り替わるシステムコール、監視対象のプロセスに関連するファイルを更新するシステムコール、監視対象のプロセスにセキュリティパッチを適用するシステムコールなどである。従って、本実施形態によれば、本構成により、無人運用（かつ無停止運用）システムにおいて、必要十分なＣＰ情報を取得することができる。
【０１４０】
本実施形態によれば、オンライン途中だけでなくオンライン直前のＣＰ情報を取得する。このため、安全な状態に回復できるＣＰ情報を少なくとも一つ確保することができる。
【０１４１】
本実施形態によれば、所定のシステムコール列の検出を契機にＣＰ情報を取得するよう構成しているため、必要十分なＣＰ情報を自動的に取得し保持することができる。従って、無制限にＣＰ情報を保持することにより記録容量の無駄遣いを防ぎ、回復処理を行うために効果的なＣＰ情報を効率的に保持することができる。
【０１４２】
また、本実施形態によれば、再故障寿命という概念を導入したため、故障が再発した時間と再故障寿命を比較することにより、適切なＣＰ情報を選択して回復処理を行うことができる。すなわち、最初の故障発生直後に故障の原因（脅威の種類）を明確に判別を行うことなく、故障の再発という現象に基づいて、順次最適なＣＰ情報を選択し、回復処理を行うことができる。
【０１４３】
すなわち、複数の取得した必要十分なＣＰ情報を用いて、故障解析の有無によらずに、故障発生時に適切な回復手順を選択可能なチェックポイント／リスタート制御技術を提供することができる。
【０１４４】
また、本実施形態によれば、チェックポイント／リスタート処理部１０１３にチェックポイント／リスタート処理部１０１３にＣＰ情報を取得する、再始動を行うといった契機となる指示を行う機能であるシステムコール監視手段をチェックポイント／リスタート処理部１０１３と同様にＯＳ内に備えている。このため、ＯＳ外で実行されるアプリケーションであるプロセス１００１からＣＰ情報取得等の指示を受ける場合に比べ、不正コード侵入の影響をうけにくい。すなわち、プロセス１００１から指示を受ける場合、プロセス１００１に不正コード挿入されると、ＣＰ情報の取得を回避する、無制限に実行するなど操作を受け易い。しかし、本実施形態の構成では、そのような不安はない。
【０１４５】
以上により、本実施形態によれば、メモリを効率的に利用し、故障発生の状況に応じて適切な回復処理を行うことが可能なチェックポイント／リスタート技術を提供できる。
【０１４６】
＜＜第二の実施形態＞＞
次に、本発明を適用した第二の実施形態について説明する。第一の実施形態では、いずれのＣＰ情報を用いて回復処理を行うかを決定するために、故障時刻、ＣＰ情報取得時刻から算出した再故障寿命Ｔという概念を導入している。しかし、本実施形態では、時間を導入するかわりに、システムコールの発行回数を計測する。
【０１４７】
本実施形態の情報処理装置５００の機能構成、ハードウェア構成は、基本的に第一の実施形態と同様である。以下、本実施形態の第一の実施形態と異なる構成を説明する。
【０１４８】
本実施形態では、チェックポイント／リスタート処理部１０１３の代わりにチェックポイント／リスタート処理部１０１３−２を備える。チェックポイント／リスタート処理部１０１３−２は、ＣＰ０情報を取得後、その後のシステムコールの発行数をカウントする。そして、ＣＰ情報を取得する毎に、そのＣＰｉ情報を取得した時点ＣＰｉの時刻の代わりにシステムコールの累積発行数ＳＣｉを、ＣＰｉ情報に対応づけてＰＲＡＭ５０５に記録する。同様に、チェックポイント／リスタート処理部１０１３は、故障が発生した際も、発生時刻ｔｘの代わりにその時点までのシステムコールの累積発行数ＳＣｘを記録する。
【０１４９】
すなわち、ＣＰ情報取得処理において、本実施形態では、ＣＰ情報を取得した時点の時刻の記録は行わない。一方、システムコール監視時において、システムコールの発行回数をカウントする。さらに、故障が発生した場合は、故障時時刻ｔｘの記録ではなく、故障時のシステムコールの累積発行数ＳＣｘを記録する。
【０１５０】
なお、本実施形態では、再故障寿命Ｔは、故障発生時のシステムコールの累積発行数ＳＣｘから最近のＣＰ情報（ＣＰｉ情報）取得時のシステムコールの累積発行数ＳＣｉを減算したものと定義する（Ｔｉ＝ＳＣｘ−ＳＣｉ）。
【０１５１】
図１０は、本実施形態のＣＰ回復処理の処理フローである。
【０１５２】
チェックポイント／リスタート処理部１０１３−２は、故障を検出すると、その時点の累積システムコール（ＳＣ）数ＳＣｘをＰＲＡＭ５０５に記録する（ｓ３０１）。そして、情報処理装置５００をオフラインにする（回線切断処理）（ｓ３０２）。
【０１５３】
チェックポイント／リスタート処理部１０１３ー２は、その時点の累計数ｎをカウンタｉに代入する（ｓ３０３）。そして、ＣＰｉ情報がＰＲＡＭ５０５に記録されているか否かを判別する（ｓ３０４）。
【０１５４】
ｓ３０４で記録されていない場合は、後述するｓ３１４に処理を進める。
一方、ｓ３１４で記録されている場合は、チェックポイント／リスタート処理部１０１３−２は、ＣＰｉ情報に対応づけて記録されているＣＰｉ情報を取得した時点の累積システムコール数ＳＣｉと先に記録した故障を検出した時点のＳＣｘとを用いて再故障寿命Ｔｉを算出してカウンタＣに代入する（Ｃ＝Ｔｉ＝ＳＣｘ−ＳＣｉ）（ｓ３０５）。
【０１５５】
そして、チェックポイント／リスタート処理部１０１３−２は、ＣＰｉ情報を用いて回復処理を行う（ｓ３０６）。
【０１５６】
回復処理を行い、オンライン状態になると（ｓ３０７）、まず、チェックポイント／リスタート処理部１０１３−２は、ＣＰ情報取得フラグをたてる。ここで、ＣＰ情報取得フラグは本実施形態独特の構成であり、チェックポイント／リスタート処理部１０１３−２は、このフラグが立っている間は、システムコール列Ｓが検出されたとしても、ＣＰ情報を取得しないよう構成されている。
【０１５７】
そして、チェックポイント／リスタート処理部１０１３−２は故障の発生の監視を続ける（ｓ３０８）。ここでは、システムコールが発行される度に故障の発生の有無を判別する。
【０１５８】
故障を検出しなかった場合、チェックポイント／リスタート処理部１０１３−２は、カウンタＣを１デクリメントする（ｓ３０９）。このとき、システムコールの累積発行数ＳＣは通常どおり１インクリメントする。そして、カウンタＣが０か否かを判別し（ｓ３１０）、０でなければ、ｓ３０８に戻り、システムコール発行毎に故障の発生の有無の検出を続ける。
【０１５９】
本実施形態では、システムコールの発行数で再発故障寿命を定義しているため、カウンタＣが０になった時点で、再発故障寿命Ｔｉになったものといえる。ｓ３１０でカウンタが０の場合、チェックポイント／リスタート処理部１０１３−２は、ＣＰ情報取得フラグをおろす（ｓ３１１）。これ以降、チェックポイント／リスタート処理部１０１３−２が故障を検出する前にシステムコール監視処理部１０１４がシステムコール列Ｓを検出すると、図８のステップｓ６１１に戻る。本構成により、本実施形態では、再発故障寿命Ｔｉの間は、ＣＰ情報を取得しないよう構成する。
【０１６０】
そして、故障の監視を続ける（ｓ３１１）。同じ故障が再発した場合、再発故障寿命Ｔｉを超えた時期に故障が再発したことになるため、再試行を行うため、Ｓ３０６に戻る。故障の発生を検出しない間は、システムコール列Ｓを検出するまで、監視を続ける。
【０１６１】
一方、ｓ３０８において、チェックポイント／リスタート処理部１０１３−２が、先に検出した故障と同じ故障を検出すると、再発故障寿命Ｔｉの間に故障が再発したことになるため、情報処理装置５００をオフラインにし（ｓ３１３）、カウンタを１デクリメント（ｉ＝ｉ−１）し（ｓ３１４）、ｉが０以上の間は、ｓ３０５に戻り、処理を続ける（再始動；使用するＣＰ情報の後退）。一方、ｉをデクリメントした結果マイナスになった場合は、チェックポイント／リスタート処理部１０１３−２は、業務（プロセス１００１）を停止する（ｓ３１６）。
【０１６２】
ｓ３０４で記録されていない場合は、後述するｓ３１４に処理を進める。一方、ｓ３０４で記録されている場合は、チェックポイント／リスタート処理部１０１３−２は、システムコール数をカウントするために導入したシステムコールカウンタＣに、故障発生時のシステムコールの累積発行数ＳＣｘと最も新しいＣＰ情報（ＣＰｉ情報）を取得した時点でのシステムコールの累積発行数ＳＣｉとから再故障寿命Ｔｉを算出して代入する（Ｓ３０５）。
【０１６３】
また、チェックポイント／リスタート処理部１０１３−２は、ＣＰｉ情報を用いて回復処理を行う（Ｓ３０６）。なお、本実施形態では、ＣＰ情報取得停止フラグを導入する。ＣＰ情報取得停止フラグが立っている間は、たとえ予め定めたシステムコール列を検出した場合であっても、ＣＰ情報を取得しない。オフラインここで、ＣＰ情報取得停止フラグを立てる
以上説明したように、本実施形態によれば、故障発生後の処理を決定するために、時刻ではなくシステムコールの発行回数を用いている。従って、第一の実施形態で得られる効果に加え、処理を簡単な減算カウンタで実現することができ、システムの構成を簡易なものとすることができる。
【０１６４】
また、本実施形態によれば、カウンタＣを利用して、再故障寿命を越えない限り（カウンタＣが０となるまで）、たとえば、連続故障が発生する可能性が少ないシステムでは、ＣＰ情報を取得しないようにシステムを構成することができる。一方、再故障寿命期間を超えた場合、所定のシステムコールが発行されたら、ＣＰ情報を取得するという通常の処理に戻る。すなわち、図６（ａ）ではＣＰｋ（図１０では、ＣＰｎ＋１）を取得する。このように、ＣＰ情報の取得に関しても、再故障寿命を考慮し、判断することが可能となる。
【０１６５】
なお、以上の各実施形態においては、その機能構成は、図２に示すものを例に挙げて説明したが、これに限られない。例えば、図１１に示す構成であってもよい。
【０１６６】
図１１に示す構成は、情報処理装置５００に計算機装置の仮想化技術（ｈｙｐｅｒｖｉｓｏｒ）を適用したものである。
【０１６７】
図１１において、情報処理装置５００は、業務系システムと監視系システムとを備える。業務系システムは、アプリケーションプログラム１０００とその代替１１００、オペレーティングシステム１０１０とその代替１１１０、を備える。監視系システムは、監視プロセス１２００と、オペレーティングシステム１２１０とを備える。アプリケーションプログラム１０００とその代替１１００と監視プロセス１２００、および、オペレーティングシステム１０１０とその代替１１１０とオペレーティングシステム１２１０とは、仮想計算機１１５０で結合する。チェックポイント／リスタート処理部１０１３は仮想計算機１１５０が備える。この場合、チェックポイント／リスタート処理部１０１３は、オペレーティングシステムからも隠蔽されるので、より安全性が高まる。
【０１６８】
本図において、アプリケーションプログラム１０００およびその代替１１００は、被対象プロセス１００１に関連するバイナリプログラム１００２および設定ファイル１００３を含む。仮想化技術を用いることにより、個々のバイナリプログラム１００２や設定ファイル１００３を含めて保管することが容易となる。このため、本構成によれば、メモリだけではなく、プログラムや設定ファイルについても複製する。本構成によれば、保全作業自体を推測し、プロセスに関連するファイルをバックアップすることになる。このため、保全作業自体に偽装した攻撃に対抗し、再始動に必要なファイルを保護することができる。
【０１６９】
監視プロセス１２００は、システムコール監視処理部１０１４とＣＰ情報を取得するシステムコール列を記録するコールリスト１０１６とを個々のオペレーティングシステム１０１０に登録する。オペレーティングシステム１０１０は、コールリスト１０１６に記録されているシステムコール列を検出した場合に、仮想マシン仮想計算機１１５０が備えるチェックポイント／リスタート処理部１０１３に要求を出して、アプリケーションプログラム１０００とオペレーティングシステム１０１０と含む計算機環境の全てをＣＰ情報として複製する。また、アプリケーションプログラム１０００あるいはオペレーティングシステム１０１０で障害が発生した場合には再始動の指示を代替のアプリケーションプログラム１１００とオペレーティングシステム１１１０とから実施する。
【０１７０】
アプリケーションプログラム１０００の監視対象プロセス１００１の故障に対し、監視プロセス１２００は、間接的に監視することになる。このような構成にすることにより、システム間の独立性を保つことができ、業務系システムから監視系システムにウィルス等の侵入が発生しにくくなる。また、逆に監視系システムが業務系システムに影響を及ぼしにくくなる。さらに、本図においては、監視対象プロセス１００１の数（アプリケーションプログラム１０００）が１の場合を例に挙げて説明している。しかし、監視対象プロセス１００１の数はこれに限られない。監視対象プロセス１００１の数が数十から数百と多数存在し、その一方で監視プロセスが一つである場合、本図に示すようにアプリケーションプログラム１０００の監視対象プロセス１００１の故障に対し、監視プロセス１２００は、間接的に監視する構成とすると、監視系システムが、システム全体の処理を進める上でのボトルネックとなる可能性が低くなる。
【０１７１】
以上説明したように、本実施形態によれば、所定のシステムコール発行時にＣＰ情報を取得する。従って、定期的にＣＰ情報を取得する場合に比べて、安全性が高く、必要十分なＣＰ情報を取得することができる。このため、保全業務において、意味のある時点から回復できる可能性が高い。
【図面の簡単な説明】
【０１７２】
【図１】第一の実施形態の情報処理装置の構成図である。
【図２】第一の実施形態の情報処理装置の機能構成図である。
【図３】第一の実施形態の情報処理装置がオフライン状態で発行するシステムコール列を説明するための図である。
【図４】第一の実施形態の情報処理装置がオンライン状態で発行するシステムコール列を説明するための図である。
【図５】第一の実施形態の情報処理装置がオフライン状態で発行するシステムコール列を説明するための図である。
【図６】第一の実施形態の再試行および再始動を説明するための図である。
【図７】第一の実施形態の時間の種類を説明するための図である。
【図８】第一の実施形態のＣＰ情報取得処理の処理フローである。
【図９】第一の実施形態のＣＰ回復処理の処理フローである。
【図１０】第二の実施形態のＣＰ回復処理の処理フローである。
【図１１】情報処理装置の別の機能構成図である。
【符号の説明】
【０１７３】
５００：情報処理装置、５０１：マルチプロセッサ、５０２：プロセッサ、５０３：プロセッサ、５０４：揮発性メモリＤＲＡＭ、５０５：相変化メモリＰＲＡＭ、５０６：ストレージＨＤＤ、５０７：ネットワークインタフェース、５０８：入出力インタフェース、１０００：アプリケーションプログラム、１００１：監視対象プロセス、１０１０：オペレーティングシステム、１０１１：システムコールハンドラ、１０１２：システムコールサービスルーチン、１０１３：チェックポイント／リスタート処理部１０１３、１０１４：システムコール監視処理部、１０１５：発行履歴、１０１６：コールリスト
【図１】
2008003691.tif 000003
【図２】
2008003691.tif 000004
【図３】
2008003691.tif 000005
【図４】
2008003691.tif 000006
【図５】
2008003691.tif 000007
【図６】
2008003691.tif 000008
【図７】
2008003691.tif 000009
【図８】
2008003691.tif 000010
【図９】
2008003691.tif 000011
【図１０】
2008003691.tif 000012
【図１１】
2008003691.tif 000013