トップ :: G 物理学 :: G06 計算;計数

【発明の名称】 計算機のプロセス回復方法、チェックポイントリスタートシステム
【発明者】 【氏名】道明 誠一

【氏名】櫻庭 健年

【要約】 【課題】

【構成】
【特許請求の範囲】
【請求項1】
計算機上で稼動しているプロセスを監視し当該プロセスの障害の発生を検出する障害検出ステップと、
前記障害検出ステップで障害の発生を検出すると、前記プロセスにおいて予め定めた前記プロセスの保全性に影響を与える事象が発生する以前の所定のタイミングで記録した前記プロセスのメモリ状態を用いて、前記障害が発生したプロセスを再始動させる再始動ステップと、を備えること
を特徴とする計算機のプロセス回復方法。
【請求項2】
請求項1記載のプロセス回復方法であって、
前記障害検出ステップは、障害の発生を検出する毎に検出した障害の種類と時刻とを記録し、
前記再始動ステップは、前回同じ障害の発生を検出した場合に再始動に用いたメモリ状態を記録した時刻から新たに検出した障害の発生時刻までの時間が再始動に用いたメモリ状態を記録した時刻から前回の障害の発生時刻までの時間より長い場合は、前回の障害発生時に用いたメモリ状態を用いて再始動を行い、短い場合は、前回の障害発生時に用いたメモリ状態より前に記録したメモリ状態を用いて再始動を行うこと
を特徴とするプロセス回復方法。
【請求項3】
請求項1記載のプロセス回復方法であって、
前記障害検出ステップは、障害の発生を検出すると、検出した障害の種類と、前記プロセスの稼動から当該障害の発生を検出するまでに発行されたシステムコール数を記録し、
前記再始動ステップは、前回同じ障害の発生を検出した場合に再始動に用いたメモリ状態を記録した時から新たに検出した障害の発生時までに発行されたシステムコール数が当該メモリ状態を記録した時から前回の障害の発生時までに発行されたシステムコール数より多い場合は、前回の障害発生時に用いたメモリ状態を用いて再始動を行い、少ない場合は、前回の障害発生時に用いたメモリ状態より前に記録したメモリ状態を用いて再始動を行うこと
を特徴とするプロセス回復方法。
【請求項4】
計算機上で稼動しているプロセスに障害が発生した場合に回復処理を行うために用いるメモリ状態記録方法であって、
プロセスが発行するシステムコール列を監視する監視ステップと、
前記監視ステップにおいて、前記プロセスの保全性に影響のある処理が行われる直前であることを示すシステムコール列が検出されると、前記検出した時刻に対応付けて当該時刻における前記プロセスのメモリ状態を記録するメモリ状態記録ステップと、
を備えるメモリ状態記録方法。
【請求項5】
請求項4記載のメモリ状態記録方法であって、
前記計算機がオフライン状態の場合は、オフライン状態からオンライン状態に移行する直前を示すシステムコール列の検出を契機に前記メモリ状態を記録し、
前記計算機がオンライン状態の場合は、ファイル更新およびセキュリティ上の脆弱性を修正するためのプログラムの追加処理のいずれかが行われる直前を示すシステムコール列の検出を契機に前記メモリ状態を記録すること
を特徴とするメモリ状態記録方法。
【請求項6】
計算機上で稼動しているプロセスにおいて発行されるシステムコールを監視し、所定のシステムコール列の発行を検出するシステムコール監視手段と、
前記システムコール監視手段が前記所定のシステムコール列を検出したタイミングで前記プロセスのメモリ状態を取得し、前記取得した時刻と対応づけて記録するとともに、前記プロセスの状態を監視し、障害を検出すると前記記録したメモリ状態を用いて前記プロセスを再始動させる記録再始動手段と、を備え、
前記所定のシステムコール列は、前記プロセスの保全性に影響を与える事象が発生する直前であることを示すシステムコール列であること
を特徴とするチェックポイントリスタートシステム。
【請求項7】
請求項6記載のチェックポイントリスタートシステムであって
前記記録再始動手段は、
障害の発生を検出する毎に検出した障害の種類と時刻とを記録し、
前回同じ障害の発生を検出した場合に再始動に用いたメモリ状態を記録した時刻から新たに検出した障害の発生時刻までの時間が再始動に用いたメモリ状態を記録した時刻から前回の障害の発生時刻までの時間より長い場合は、前回の障害発生時に用いたメモリ状態を用いて再始動を行い、短い場合は、前回の障害発生時に用いたメモリ状態より前に記録したメモリ状態を用いて再始動を行うこと
を特徴とするチェックポイントリスタートシステム。
【請求項8】
請求項6記載のチェックポイントリスタートシステムであって
前記記録再始動手段は、
障害の発生を検出すると、検出した障害の種類と、前記プロセスの稼動から当該障害の発生を検出するまでに発行されたシステムコール数を記録し、
前回同じ障害の発生を検出した場合に再始動に用いたメモリ状態を記録した時から新たに検出した障害の発生時までに発行されたシステムコール数が当該メモリ状態を記録した時から前回の障害の発生時までに発行されたシステムコール数より多い場合は、前回の障害発生時に用いたメモリ状態を用いて再始動を行い、少ない場合は、前回の障害発生時に用いたメモリ状態より前に記録したメモリ状態を用いて再始動を行うこと
を特徴とするチェックポイントリスタートシステム。
【請求項9】
複数のアプリケーションプログラム(AP)と、複数のオペレーティングシステム(OS)とが動作する仮想計算機を備える計算機システムであって、
それぞれのOSは、当該OS上で実行中のAP(プロセス)が発行するシステムコールを監視し、所定のシステムコール列の発行を検出するシステムコール監視手段を備え、
前記仮想計算機は、
前記システムコール監視手段のいずれかが前記所定のシステムコール列を検出したタイミングで前記計算機システムの全てのメモリ状態を取得し、前記取得した時刻と対応づけて記録するとともに、前記プロセスの状態を監視し、障害を検出すると、前記障害が検出されたプロセスが稼動するOS以外のOSから前記記録したメモリ状態を用いて前記プロセスを再始動させる記録再始動手段を備え、
前記所定のシステムコール列は、前記プロセスの保全性に影響を与える事象が発生する直前であることを示すシステムコール列であること
を特徴とする計算機システム。
【請求項10】
計算機を、
当該計算機上で稼動しているプロセスにおいて発行されるシステムコールを監視し、前記プロセスの保全性に影響を与える事象が発生する直前であることを示すシステムコール列の発行を検出するシステムコール監視手段と、
前記システムコール監視手段が前記所定のシステムコール列を検出したタイミングで前記プロセスのメモリ状態を取得し、前記取得した時刻と対応づけて記録するとともに、前記プロセスの状態を監視し、障害を検出すると前記記録したメモリ状態を用いて前記プロセスを再始動させる記録再始動手段と、して機能させるためのプログラム。
【発明の詳細な説明】【技術分野】
【0001】
本発明は、ソフトウェア故障から計算機システムを復旧する、チェックポイント/リスタート技術に関する。特に、故障要因が攻撃や侵入である場合も含めて対処可能な技術に関する。
【背景技術】
【0002】
計算機のソフトウェアやハードウェアに故障が発生した際、実行中のプログラム(以下、プロセスと呼ぶ。)がデータ処理を中断し,以前のプロセスの実行状態に移行し,業務を継続する計算機技術を、一般に、チェックポイント/リスタート制御方法と呼ぶ。プロセスのリスタート(再始動)とは,システムやプロセスの停止を伴う,装置のリブート(再起動)とは異なる。リスタート(再始動)とは,プロセスを停止せずに,事前に記録したメモリや入出力の状態を呼び出すことで,状態を回復するものである。この状態を記録するタイミングをチェックポイント(CP)と呼ぶ。
【0003】
なお、本明細書では、チェックポイント(CP)において複製する情報をチェックポイント情報(CP情報)と呼び、CP情報を複製し記録媒体に記録することをCP情報の取得と呼ぶ。また、CP情報を呼び出し、状態の回復を行うことを回復処理と呼ぶ。
【0004】
ところで、故障発生の原因によっては、再始動したプロセスが再び故障する可能性が少なからず存在する。
【0005】
チェックポイント/リスタート制御では、ソフトウェア故障が回復するまで、CP情報を利用し再始動を試みる。ただし、試行回数は、予め設定した最大値を越えない。または、予め設定した時間内で試行を繰り返す(例えば、特許文献1参照。)。
【0006】
なお、通常のチェックポイント/リスタート制御の回復手順では、複数のCPでCP情報を取得した場合も、直前に取得したCP情報(最新のCP情報)を用いて、再始動を試みる(例えば、特許文献2参照)。
【0007】
その他、故障回復処理の手法としては、故障が発生した入力データを処理せずに、次のデータから処理を継続する手法もある(例えば、特許文献3参照)。
【0008】
【特許文献1】特許第3072048号
【特許文献2】特許第3135714号
【特許文献3】特開平5−233341号公報
【発明の開示】
【発明が解決しようとする課題】
【0009】
一般に、サーバ装置の障害対策として、保全作業を実施する必要がある。保全作業とは、例えば、セキュリティパッチの適用、構成定義ファイルの更新など、システムの保全性に関わる作業である。具体的な作業内容は、ディスク上のプログラムやファイルの交換である。特に、無停止運用のサーバ装置においては、サーバのデータ処理を一時中断し、メモリ上のプロセスやデータの内容を変更した後に、業務を再開する操作が含まれる、場合がある。
【0010】
サーバ装置において、プロセスがデータを紛失する、データが改ざんされる、などの脅威を想定し、事前に解決手段を提供し、障害の発生を回避するのが、保全作業を実施する目的である。しかし、システムが大規模となり、複数のプログラムが密接にかつ複雑に絡み合った情況では、計算機の構成やプログラムの内容を変更する操作の結果や影響は、完全には把握しきれないのが現状である。そのため、実行中のプロセスの状態が不安定となり、故障が発生する可能性もある。
【0011】
故障の種類として、例えば、プロセスが新規の業務を受け付けない、プロセスが異常停止する、プロセスが規定外の処理を実行する、等がある。これらの故障の要因として、(X)偶然(例えば処理集中による資源の枯渇)、(Y)事故(例えば保全作業自体の不具合)、(Z)攻撃(例えばウィルスの混入)、の各脅威が想定される。
【0012】
一般に、計算機システムの運用方針や回復手順は、システムの目標や故障の要因に応じて複数存在する。例えば、処理再開と故障解析という目標に対して、それぞれ回復手順は異なる。運用方針の例をあげると、故障の要因が脅威Xと脅威Yとのいずれかと推測できる場合は、処理再開を優先すべきである。他方、故障の要因が脅威Zである場合は、故障要因の排除を優先すべきである。さらに、排除できない場合に業務を中止することもある。
【0013】
いずれの場合も、最終目標は、業務の再開並びにシステムの復旧であるが、要因が特定できれば、適切な回復手順を選択できる。チェックポイント/リスタート制御を行う場合も、故障発生の要因が脅威Xと脅威Yとのいずれかである場合は、業務再開を優先したCP情報を用いた回復処理を行い、脅威Zによるものである場合は、故障の要因を排除可能なCP情報を用いて回復処理を行うべきである。
【0014】
しかし、故障の要因を脅威Xと推量したにも係わらず、実際は脅威Zであった場合は、再開時期を徒に早めることで、システムの安全性や業務の信頼性を損ねる。逆に、脅威Zと推量したにも係わらず、実際は脅威Xであった場合は、停止期間を際限なく延長すると、経済的な損失が増える。
【0015】
一般に、無停止サーバでは、故障が発生した場合、可能なかぎり短時間(秒単位)において回復することが望まれる。一方、故障要因を解析した後に復旧手順を選択することが理想である。しかし、故障要因の解析作業は、多くの場合、専門家による人手の作業であり、長時間(時間、日単位)を要する。従って、無停止サーバでの要求には対応できない。このため、現実には、故障の種類や時刻について記録した後に、CP情報を用いて回復するといった運用がなされている。回復処理の実行結果を踏まえて、故障の要因を推測(故障が再発したので脅威X、しないので故障Yなど)し、適宜、回復処理の内容や手順を調整する。
【0016】
ところで、脅威Z特有の現象として、タイムラグ(時間差)があること、すなわち、システムに故障要因が絡んだ時点故障が顕在化する時点が、時間的に連続ではなく、期間を隔てていることが挙げられる。ウィルスによる故障を例にとると、ウィルスがシステムに混入する時点と、混入したウィルスが活性化し、業務が停止となる時点とではタイムラグがある。そのため、ウィルス混入後にCP情報を取得する可能性が少なからずあり、その場合に、従来技術のチェックポイント制御を適用すると、故障発生直前に取得したウィルス混入後のCP情報を用いて回復処理を行うこととなる。故障の要因(ウィルス)は排除されておらず、再び障害が発生し、業務が停止する可能性が高い。
【0017】
本発明は、このような事情に鑑みなされたもので、故障の要因が不明確な場合であっても、システムを安全に回復し、業務を迅速に再開する、目的に適ったチェックチェックポイント/リスタート制御技術を提供することを目的とする。
【課題を解決するための手段】
【0018】
複数のCPで取得したCP情報を保持し、故障が再発するタイミングに応じて適切なCP情報を用いてシステムを回復させる。
【0019】
具体的には、計算機上で稼動しているプロセスを監視し当該プロセスの障害の発生を検出する障害検出ステップと、前記障害検出ステップで障害の発生を検出すると、前記プロセスにおいて予め定めた前記プロセスの保全性に影響を与える事象が発生する直前のタイミングで記録した前記プロセスのメモリ状態を用いて、前記障害が発生したプロセスを再始動させる再始動ステップと、を備えることを特徴とする計算機のプロセス回復方法を提供する。
【発明の効果】
【0020】
本発明によれば、故障の要因が不明確な場合であっても、システムを安全に回復し、業務を迅速に再開する、目的に適ったチェックチェックポイント/リスタート制御技術を提供することができる。
【発明を実施するための最良の形態】
【0021】
本発明を適用した実施形態を以下に示す。なお、チェックポイント/リスタートの実現手段として,システム構成によって,リスタート時に障害プロセスのメモリを更新するもの、もしくは,障害プロセスとは別に待機プロセスを活性化するもの,の2種類の手段がある。以下の実施形態では,後述するように,攻撃による障害発生も含めているので,とくに断らない限り,後者の待機プロセスを活性化する手段とする。
【0022】
<<第一の実施形態>>
本実施形態の情報処理装置500の構成図を図1に示す。本図に示すように、本実施形態の情報処理装置500は、マルチプロセッサ501と、メモリ509と、ストレージ506と、ネットワークインタフェース507と、入出力インタフェース508と、を備える。また、メモリ509は、揮発性メモリ(DRAM)504と、相変化メモリ(PRAM)505と、ストレージ(HDD)506とを備える。ここでは、マルチプロセッサ501は、プロセッサ502と503との2つを備えるものとする。ただし、プロセッサは1台以上のCPUであればよく、その数は問わない。
【0023】
HDD506は、オペレーティングシステムやアプリケーションプログラムなどのソフトウェアをファイルとして記憶する二次記憶である。
【0024】
DRAM504は、オペレーティングシステムやアプリケーションプログラムなどのソフトウェアやデータを記憶する一次記憶である。
【0025】
マルチプロセッサ501は、HDD506に記憶されているソフトウェアをDRAM504にロードして実行することにより、後述する各機能を実現する。またマルチプロセッサ501は、処理の途中に生成したデータを一時的にDRAM504に記憶する。
【0026】
PRAM505は、チェックポイント/リスタートで使用するデータを保持する。チェックポイント/リスタートで使用するデータは、各チェックポイントにおいて、再始動するために必要な情報として保持されるプロセスのメモリ状態である。以下、各チェックポイントにおける、保持されるプロセスのメモリ状態のデータをチェックポイント情報(CP情報)と呼ぶ。また、チェックポイント取得時刻をCPtと表した場合、その時刻CPtにおいて取得したCP情報をCPt情報と呼ぶ。なお、PRAM505は、改ざん困難な不揮発性メモリであれば、相変化メモリPRAM505でなくてもよい。
【0027】
入出力インタフェース508は、管理者あるいは監視者からの要求の入力をマルチプロセッサ501に伝達し、逆に、マルチプロセッサ501で処理した結果を出力する、入出力装置、例えば、キーボード、マウス、ディスプレイ等のデバイスと接続する。
【0028】
ネットワークインタフェース507は、外部の計算機やシステムと接続するネットワークカードである。
【0029】
本実施形態のマルチプロセッサ501がプログラムを実行することにより実現する機能構成を図2に示す。本図に示すように、本実施形態の計算機システム500は、オペレーティングシステム(OS)1010と、OS1010上で稼動するアプリケーションプログラム(AP)1000と、ライブラリ1020と、を備える。
【0030】
本実施形態では、マルチプロセッサ501がプログラムを実行することにより、システムコールハンドラ1011と、システムコールサービスルーチン1012とに加え、システムコール監視処理部1014と、チェックポイント/リスタート処理部1013と、ライブラリチェックポイント/リスタート処理部(Lチェックポイント/リスタート処理部)1023と、ライブラリ関数監視処理部1024と、を実現する。また、ストレージHDD506には、発行されるシステムコールまたは関数を、その発行順に記録する発行履歴1015と、チェックポイント情報を取得する特定のシステムコール、関数、および、システムコール列を記録するコールリスト1016と、発行されるライブラリ関数をその発行順に記録するライブラリ発行履歴(L発行履歴)1025と、チェックポイント情報を取得する特定のライブラリ関数を記録するライブラリ関数リスト(Lコールリスト)1026とが記録される。
【0031】
なお、図2に示す例では、ライブラリ1020とOS1010とにそれぞれシステムコール監視部1014とライブラリ関数監視部1024とが存在し、それぞれが専用のチェックポイント/リスタート機能と連携して動作する。このように図2に示す例は、監視部とチェックポイント/リスタート機能とがライブラリ1020とOS1010とに別れ、システムで二組存在するものであるが、いずれか一方の組だけが存在するよう構成してもよい。
【0032】
マルチプロセッサ501が実行する監視対象のプロセス1001が発行するシステムコール、および、関数は、上述のように発行順に発行履歴1015に記録される。ライブラリコールについても同様にL発行履歴1025に記録される。このため、以下においては、システムコールの場合を例にあげて説明する。
【0033】
また、コールリスト1016には、予め定めたシステムコール列、システムコール、関数が記憶される。
【0034】
システムコール監視処理部1014は、プロセス1001が発行するシステムコールおよび関数を監視し、所定のシステムコール列、システムコールおよび関数(以後、システムコール列と総称する。)が発行されたことを検出するとチェックポイント/リスタート処理部1013に通知する。具体的には、プロセス1001が発行し、発行履歴1015に記録されるシステムコール列をコールリスト1016に記録されているシステムコール列と照合し、合致した場合、チェックポイント/リスタート処理部1013に通知する。
【0035】
チェックポイント/リスタート処理部1013は、システムコール監視処理部1014から合致したとの通知を受けると、その時刻およびその時点のメモリ状態をそれぞれ時刻CP、CP情報としてPRAM505に記録する。
【0036】
また、チェックポイント/リスタート処理部1013は、故障が発生した際、PRAM505に記録したCP情報を用いて、回復処理を行う。
【0037】
以下、システムコール監視処理部1014およびチェックポイント/リスタート処理部1013の処理の詳細を説明する。
【0038】
まず、システムコール監視処理部1014が監視するシステムコール列を、情報処理装置500がオンライン状態の場合とオフライン状態の場合とに分けて説明する。ここでは、情報処理装置500がUDPサーバの場合を例にあげて説明する。オンライン状態では、UDPサーバである情報処理装置500は、複数のUDPクライアントと情報を送受信し、処理を行う。
【0039】
図3は、情報処理装置500(UDPサーバ)のサーバプロセス1001が初期化処理を実行する際、データ通信に発行する代表的なシステムコール列を説明するフローである。以下では,情報処理装置500はハードウェアであり,プロセス1001はサーバソフトウェアが稼動しているソフトウェアとする。
【0040】
(a) UDPサーバプロセス(情報処理装置500)側
UDPサーバプロセスは、socketシステムコールを用いて、それぞれのクライアントとの通信路を区別するために、それぞれエンドポイント(ソケット)を作成する(s701)。
【0041】
次に、UDPサーバは、bindシステムコールを用いて、作成したソケットに名前をつける(s702)。
【0042】
そして、UDPサーバは、selectシステムコールを用いて、複数のソケットを監視し、クライアントからのデータ送信を待つ(s703)。
【0043】
クライアントからの送信があると、UDPサーバは、recvfromシステムコールを用いて、ソケットを介して要求データを受信する(s704)。
【0044】
そして、UDPサーバは、sendtoシステムコールを用いて、ソケットを介して応答データを送信する(s705)。その後、クライアントからの入力を待つ状態に戻る(s703)。
【0045】
(b)UDPクライアント側
UDPクライアントは、socketシステムコールを用いて、特定のUDPサーバとの通信を目的としたエンドポイント(ソケット)を作成する(s711)
UDPクライアントは、sendtoシステムコールを用いて、ソケットを介して要求データをUDPサーバに送信する(s712)
UDPクライアントは、recvfromシステムコールを用いて、ソケットを介して応答データをUDPサーバから受信する(s713)。
【0046】
UDPクライアントは、UDPサーバとの間で行う処理が完了するまで、s712とs713とを繰り返し、処理が完了すると、closeシステムコールを行い、プロセスを終了する(s714)。
【0047】
本実施形態では、プロセス1001の状態が大きく変化する直前のメモリ状態をCP情報として記録する。本実施形態においては、情報処理装置500がUDPサーバの場合、上述のUDPサーバにおける典型的なシステムコールのシーケンスに着目し、CP情報取得タイミングを決定する。以下においてシステムの状態が大きく変化する直前を判断可能なシステムコール列をシステムの保全性に影響するシステムコール列と呼ぶ。
【0048】
まず、システムの保全性に影響を与えるシステムコール列として、オフライン状態からオンライン状態に変わる直前の状態を検出可能なシステムコール列がある。プロセス1001開始時は、UDPサーバでは、…、socket、socket、bind、bind、select、recvfrom、…の順序でシステムコールが発行される。上述のようにrecvfromシステムコールが発行されたときは、ソケットを介してUDPクライアントから要求データを受信した状態、すなわち、オンラインでの使用が開始された状態である。socket、socket、bind、bind、の順にシステムコールが発行され、続いてselectシステムが発行されたタイミングが、オンライン状態となる直前のメモリ状態といえる。このタイミングでCP情報を取得することにより、オンライン使用直前のメモリ状態をCP情報として保存することができる。なお、オンライン直前のメモリ状態として取得するCP情報を、CP0情報と呼ぶ。また、その時刻をCP0とする。
【0049】
本実施形態では、CP0情報を取得するタイミングとして、コールリスト1016にシステムコール列S0(ホワイトリスト)socket、socket、bind、bind、selectを予め記録しておく。システムコール監視処理部1014は、socket、socket、bind、bind、の順にシステムコールが発行され、続いてselectが発行されると、CP情報を取得するようチェックポイント/リスタート処理部1013に通知する。チェックポイント/リスタート処理部1013は、通知を受けると、その時点のメモリ状態をCP0情報としてPRAM505に記録するとともに、その時刻CP0をCP0情報に対応づけて記録する。
【0050】
一方、発行されたシステムコール列がその他のものの場合、例えば、…、socket、socket、bind、bind、recvfrom、…の場合は、予めHDD506にシステムコール列S0として記録されたシステムコール列と異なるため、メモリ状態を取得しない。
【0051】
次に、オンライン状態でシステムの保全性に影響を与えるシステムコール列について説明する。オンライン状態でシステムの保全性に影響を与える作業としては、ファイルの更新、セキュリティパッチ処理がある。
【0052】
図4は、情報処理装置500がオンライン状態においてファイル更新という保守作業が行われる場合を説明するための図である。
【0053】
通常時は、図4に示すように、情報処理装置500(UDPサーバ)は、recvfrom(S801)とsendto(s802)とを繰り返して処理を進める。すなわち、発行されるシステムコール列は
填、recvfrom、sendto、recvform、sendto、recvfrom、…
である。
【0054】
保守のためにファイル更新が行われる場合は、遠隔より入力されたデータによって、プログラムの動作を変え、バイナリファイルや定義ファイルを更新する。この時、ファイルに書き込むため、writeシステムコールが発行される。この場合は、recvfrom(S803)、write(s804)、sendto(s805)の順にシステムコールが発行され、処理が進められる。すなわち、発行されるシステムコール列は
…、recvfrom、sendto、recvform、write、sendto、recvfrom、…
となる。
【0055】
writeシステムコールによって、ファイルが書き換えられるため、writeシステムコールが保全性を変更するシステムコールにあたる。従って、システムの保全性に影響を与える処理が行われる直前のメモリ状態を保存するためには、writeシステムコールが発行された後であって、システムコールサブルーチン1012において処理が実行される前にCP情報を取得する。
【0056】
すなわち、システムコール監視処理部1014は、writeシステムコールが発行されたことを検出すると、その旨を、チェックポイント/リスタート処理部1013に通知する。チェックポイント/リスタート処理部1013は、通知を受けるとその時点のCP情報および時刻を示すCPを対応づけてPRAM505に記録する。
【0057】
以上では、OS1010のシステムコール監視部1014により実現する場合を例にあげて説明した。プロセス1001は、AP1000より呼び出されるソフトウェアであればよい。AP1000とOS1010との間に存在するライブラリ1020(複数のアプリケーションで共通に利用する関数を集めたソフトウェア)のライブラリ監視処理部1024でライブラリ関数を監視し、実現する場合も同様である。以下、ライブラリ関数監視部1024により実現する場合を説明する。
【0058】
図5は、情報処理装置500がオンライン状態においてセキュリティパッチ処理が行われる場合を説明するための図である。
【0059】
セキュリティパッチ処理は、多数存在する。たとえば、プロセス1001における、規定の保守手順として,保全性を向上させるソフトウェアモジュールを含むライブラリが存在するプロセス1001の内容を修正または機能を追加した後に、ライブラリをアンロードするものがある。
【0060】
ここでは、ライブラリは、ネットワーク507から送られ、ストレージHDD506において、ファイルとして一旦保管されるものとする。
【0061】
セキュリティパッチ処理を行う場合の手順は以下のとおりである。
【0062】
セキュリティパッチ処理を行う指示を受け取ると、情報処理装置500は、dlopen関数を用いて、保守用のソフトウェアを内蔵するライブラリを動的にロードする(s901)。
【0063】
プロセス1001は、dlsym関数を用いて、s901でロードしたライブラリから保守用の関数を取得する(s902)。
【0064】
保守用の関数を呼び出し、メモリ上のプロセスに対してパッチをあてる。ここでは、パッチプログラムの書き込みにmmapシステムコールを利用する(s903)。
【0065】
dlclose関数を用いて、ライブラリをアンロードする。
【0066】
従って、ここでは、関数およびシステムコールは以下の順に発行される。
…、dlopen、dlsym、…、mmap、…、dlcose、…
ライブラリを動的にロードすることにより、メモリの状態が変化する。従って、プロセス1001がdlopen関数を発行し、ライブラリ内部で処理を実行する前のメモリ状態を、CP情報として保存する。
【0067】
すなわち、ライブラリ関数監視処理部1024はdlopen関数が発行されたことを検出すると、その旨を、Lチェックポイント/リスタート処理部1023に通知する。Lチェックポイント/リスタート処理部1023は、通知を受けるとその時点のCP情報および時刻を示すCPを対応づけてPRAM505に記録する。
【0068】
以上、保全性を変更するシステムコールあるいは関数が発行された場合に、OSもしくはライブラリにおいて,CP情報を取得する具体的な手順を説明した。このように、本実施形態では、プロセスの保全性の維持に着目してCP情報を自動的に取得する。
【0069】
ここで、監視する対象のシステムコール列について、オフライン状態とオンライン状態とを分けている理由について説明する。
【0070】
図3で説明したオフライン状態では、初期化処理、例えば、定義ファイルの読み込みなど、定常状態に至るまでの処理手順は厳密に定まっている。そのために、アプリケーション毎にプロセス1001が発行するシステムコール列は一意に定まる可能性が高い。このため、特定のシステムコール列S0を予め記録しておき、実際に発行されているシステムコール列と照合し、CP0情報取得タイミングを決定することが可能である。
【0071】
しかし、図4および図5で説明したオンライン状態では、サーバプログラムは、クライアントプログラムからの要求に応じて、異なる処理を実行する。それに応じて、システムコール列は一意に定まらず、変化する傾向がある。従って、複雑な業務を実現するアプリケーションプログラムでは、多種類のシステムコール列が存在し,たとえば、保守作業に限定した特定のシステムコール列を検出することは難しい。特定のシステムコールレ地を検出するためには、たとえば、アプリケーションプログラムの動作やプロセスの状態を管理し、システムコールの引数について、業務にあわせて内容を確認する、などの確認処理を必要とする。
【0072】
しかし、システムコール列の引数について全てのパターンを事前に抽出できるとは限らず、確認処理は煩雑となる。たとえば、数十から数百程度のつながるシステムコールの発行を履歴として記録し、その一方で,対応するシステムコール列について、正常状態、異常状態、監視要の状態、例外処理,保守作業などの区別をつけたリスト、たとえば、数十から数千を準備する必要がある。また、システムコールが発行される度に、上述の確認処理を実行することは、業務本来のデータ処理を遅延することになる。
【0073】
オンライン状態であっても、システムコール列の監視が望ましい。しかし、上述のようにアプリケーションプログラムの特性によっては、システムコールの正当性について確認するのに、処理時間を要する。このため、本来のデータ処理に遅延が発生する恐れが有る。したがって、システムコール単独の監視に留めておいた方が望ましいといえる。
【0074】
そこで、オンライン状態において、ある程度検出の精度を保ちつつ、実時間で確認するために、システムコール列ではなく、特定のシステムコールまたは関数が発行された場合にCP情報を取得する。
【0075】
すなわち、オフラインではシステムコール列(システムコールの発行順序)を厳密に監視し、オンラインでは、特定のシステムコールまたは関数が発行されるかどうかを監視する。
【0076】
次に、本実施形態のチェックポイント/リスタート処理部1013が再始動を行う場合、故障要因を区分し、その後の処理を決定するために導入する再故障寿命Tと再発故障間隔T'とについて説明する。
【0077】
故障が発生した場合、チェックポイント/リスタート処理部1013は、故障が発生した時刻を記録するとともに、所定のCPi情報を用いて再始動し、回復処理を行う。
【0078】
第1回目の故障が発生した時刻をt1とする。回復処理に用いたCPi情報を取得した時刻CPiから、故障が発生した時刻t1までの時間を、再度故障が発生する予測時刻としてCPi情報の再故障寿命Tと呼ぶ。また、回復処理に用いたCPi情報を取得した時刻CPiから、回復処理後、再度故障が発生した時刻t2までの時間を、実際に故障が再発した時刻としてCPi情報の再発故障間隔T'と呼ぶ。再故障寿命Tと再発故障間隔T' は、それぞれ、チェックポイント/リスタート処理部1013が故障発生毎に算出する。
【0079】
チェックポイント/リスタート処理部1013は、1回目の故障が発生すると、最近のCP情報を用いて回復処理を行う。次のCP情報を取得する前に2回目の同じ故障が発生した場合、チェックポイント/リスタート処理部1013は、回復処理に用いたCP情報の再故障寿命Tと再発故障間隔T'とを比較し、再故障寿命Tが再発故障間隔T'より短い場合は、3回目の同じ故障が発生した場合であっても、同じCP情報を用いて回復処理を続ける。
【0080】
一方、2回目の同じ故障が発生した際、再発故障間隔T'が再故障寿命T以下の場合、チェックポイント/リスタート処理部1013は、先に回復処理に用いた最新のCP情報の1回前に保存したCP情報を用いて回復処理を行う。
【0081】
次のCP情報を取得する前に3回目の同じ故障が発生した場合、チェックポイント/リスタート処理部1013は、同様に回復処理に用いたCP情報の再故障寿命Tと再発故障時間間隔T'とを比較し、T<T'の場合、同じCP情報を用いて回復処理を行う。一方T≧T'の場合は、さらに1回前に記録したCP情報を用いて回復処理を行う。
【0082】
なお、CP情報を呼び出して状態を回復することを再始動と呼ぶと定義している。本実施形態の場合、複数のCP情報を保持しているため、再度故障が発生した場合、先の再始動時と同じCP情報を用いる場合と、別のCP情報を用いる場合とがある。ここでは、同じCP情報を用いて回復処理を行うことを再試行と呼び、新たなCP情報を用いて回復処理を行うことを再始動と呼び、区別する。
【0083】
以上のように、本実施形態では、チェックポイント/リスタート処理部1013は、新たなCP情報を取得する前に同じ故障が再発した場合、再故障寿命Tと再発故障間隔T' とを比較し、T<T'の場合再試行を行い、T≧T'の場合は、先に再始動を行ったCP情報の1回前に記録したCP情報を用いて再始動を行う。
【0084】
なお、上記おいては、最も近い時点で記録したCP情報が故障発生時の状態に最も近いため、故障発生時に1回前のCP情報を、再故障時には、さらに1回前のCP情報を用いる場合を例にあげて説明したが、用いるCP情報はこれに限られない。予め定めた分だけ遡ったCP情報を用いるよう構成してもよい。
【0085】
なお、本実施形態では、故障が発生する毎に、チェックポイント/リスタート処理部1013が情報処理装置500のOS1010或いはプロセス1001が発行するエラーコードをPRAM505等のメモリに時刻とともに記録しておく。この記録を用いて、チェックポイント/リスタート処理部1013は、2回目以降の故障について、同じ故障の再発であるか、異なる故障の発生かを判断する。
【0086】
次に、図6を用いて、チェックポイント/リスタート処理部1013が再試行または再始動を行う処理について、具体例をあげて説明する。
【0087】
図6は、CP情報の再故障寿命TとCP情報の再発故障間隔T'との関係によって、チェックポイント/リスタート処理部1013が再試行または再始動を行う様子を説明するための図である。
【0088】
なお、本図において、オフライン状態においてオンライン状態の直前に取得するCP情報をCP0情報、その時刻をCP0と呼び、オンライン状態でCP情報を取得するタイミングを、時刻順にCP1、CP2、…CPn−1、CPn、CPn+1と呼び、それぞれの時刻に対応づけてPRAM505に記録されるCP情報を、それぞれ、CP1情報、CP2情報、…、CPn−1情報、CPn情報、CPn+1情報と呼ぶ。また、以下、同じ故障は同じ文字で表し、何回目の故障であるかをダッシュで示す。図において、P'、P''は、再始動、再試行開始点を示す。
【0089】
図6(a)は、CPn情報の再故障寿命TnとCPn情報の再発故障間隔Tn'との関係がTn<Tn'であり、CPn情報を用いて再試行する場合の例である。偶発による故障は、このような発生パターンとなる可能性が高い。これは従来方式での手順に相当する。
【0090】
CPn時点でCPn情報を記録した後、次のCPn+1情報を記録する前の時刻txに1回目の故障Xが発生すると、直前に記録したCPn情報を用いて再始動を行う。詳しくは、故障Xが発生すると、チェックポイント/リスタート処理部1013が、直前に記録したCPn情報を再始動のために使用するCPn情報と決定し、CPn情報を用いて再始動を行う。
【0091】
CPnの再故障寿命Tnは直前のCPn情報を取得した時刻CPnから故障X発生時txまでの時間である。一方、回復処理を行った後、次のCP情報であるCPn+1情報を取得する時刻CPn+1前に再度故障X'(2回目の故障X')が発生した場合、CPnの再故障間隔Tn'は、CPn情報を用いて再始動後、実際に再度故障X'が発生するまでの時間tx'である。
【0092】
ここでは、CPnの再故障間隔Tn'がCPnの再故障寿命Tnより長く、Tn<Tn' であるため、チェックポイント/リスタート処理部1013は、CPn情報を用いて再試行を行う。
【0093】
なお、このとき、故障X''発生時前にCPn+1情報を取得していた場合は、故障X''発生時はCPn+1情報を用いて回復処理を行う。
【0094】
図6(b)は、CPn情報の再故障寿命TnとCPn情報の再発故障間隔Tn'との関係がTn≧Tn'であり、CPn情報の1回前に記録したCPn−1情報を用いて再始動を行うと、CPn−1情報の再故障寿命Tn−1とCPn−1情報の再発故障間隔Tn−1'との関係はTn−1<Tn−1'となり、その後は、CPn−1を用いて再試行を繰り返す場合の例である。事故による故障は、このような発生パターンとなる可能性が高い。
【0095】
CPn時点でCPn情報を取得した後、次のCPn+1情報を取得する前に1回目の故障Yが発生すると、チェックポイント/リスタート処理部1013は、図6(a)で説明した手順で直前に記録したCPn情報を用いて再始動を行う。CPnの再故障寿命Tnは、直前のCP情報を取得したCPnから故障Y発生時tyまでの時間であり、再故障間隔Tn'は、CPn情報を用いて再始動後、2回目の故障Y'が発生するまでの時間ty'である。ここでは、Tn≧Tn'である。
【0096】
CPn−1の再故障寿命Tn−1はCPn−1情報を取得した時刻CPn−1から故障Y発生時txまでの時間である。一方、回復処理を行った後、次のCP情報であるCPn+1情報を取得する時刻CPn+1前に再度故障Y''(3回目の故障Y'')が発生した場合、CPn−1の再故障間隔Tn−1'は、CPn−1情報を用いて再始動後、実際に再度故障Y''が発生するまでの時間ty''である。ここでは、Tn−1<Tn−1'であるため、チェックポイント/リスタート処理部1013は、CPn−1情報を用いて再試行を行う。
【0097】
図6(c)は、CP情報の再故障寿命TとCP情報の再発故障間隔T'との関係がT≧T'であることが繰り返される場合の例である。同一の故障が発生する毎に更に1回前に記録したCP情報を用いて再始動を行う。最終的にはネットワークに接続する直前のメモリ状態を記録したCP0情報を用いて再始動を行う。例えば、ウィルスによる攻撃により発生した故障の場合、ウィルスが取り込まれた時点と故障が発症する時点との間にタイムラグがあることが多い。このような場合は、図6(c)に示すような故障発生パターンとなる可能性が高い。
【0098】
CPn時点でCPn情報を取得した後、次のCPn+1情報を取得する前に1回目の故障Zが発生すると、チェックポイント/リスタート処理部1013は、図6(a)で説明した手順で直前に記録したCPn情報を用いて再始動を行う。CPnの再故障寿命Tnは、直前のCP情報を取得したCPnから故障Z発生時tzまでの時間であり、再故障間隔Tn'は、CPn情報を用いて再始動後、2回目の故障Z'が発生するまでの時間tz'である。ここでは、Tn≧Tn'である。
【0099】
CPn−1の再故障寿命Tn−1はCPn−1情報を取得した時刻CPn−1から故障Z発生時tzまでの時間である。一方、回復処理を行った後、次のCP情報であるCPn+1情報を取得する時刻CPn+1前に再度故障Z''(3回目の故障Z'')が発生した場合、CPn−1の再発故障間隔Tn−1'は、CPn−1情報を用いて再始動後、実際に再度故障Z''が発生するまでの時間tz''である。ここでも、Tn−1≧Tn−1'であるため、チェックポイント/リスタート処理部1013は、更に1回前に記録したCPnー2情報に戻る。
【0100】
チェックポイント/リスタート処理部1013は、故障発生毎に再故障寿命Tと再発故障間隔T'を計算し、比較し、T≧T'である限り、更に1回前のCP情報を用いて再始動を行うことを、用いるCP情報がCP0情報となるまで繰り返す。
【0101】
なお、図6(c)のケースにおいて、故障が再発する度に1つずつ遡ってCP情報を用いて再始動しているが、本構成に限られない。例えば、最初の故障時にCPn情報を用いて再始動した後、故障が再発した場合、CP0情報を用いて再始動するよう構成するなど、CP0情報を用いる前に順次遡って用いるCP情報の回数を予め定めておいてもよい。
【0102】
次に、上記チェックポイント/リスタート処理部1013が故障発生毎に記録する時刻について説明する。情報処理装置500が単一のサービス、単一のプロセスで実行されている場合は、問題とならないが、複数のサービス、複数のプロセスが並行して実行されている場合、処理時間が計測中のプロセス1001以外のプロセス等に影響を受けることがある。
【0103】
一般にシステムの時間として用いられるものには、経過時間401、ユーザ時間402、システム時間406がある。図7は、これらの経過時間401、ユーザ時間402、システム時間406の3種類の時間についてモデルを用いて説明するための図である。各CPn情報取得時に、これらの時間がCPnとしてPRAM505に記録される。
【0104】
なお、経過時間401は、情報処理装置500を外部から見た場合の時間に相当する。ユーザ時間402は、プロセス1001がユーザモード(OS1010の一部として機能分類されている保護されたサブシステムとアプリケーションプログラム1000とが動作する状態。)で動作した時間であり、システム時間406は、プロセス1001がカーネルモード(スケジューラ,メモリ管理,プロセス管理などのプリミティブなOS機能のみが動作する状態。)で動作した時間である。
【0105】
また、本図において累積回数405、407は、システムコールの発行回数の累積値のことである。マルチプロセッサ501での時刻計測は、必ずしも正確とはいえない場合があるため、システムコールの発行回数の累積値(システムコールの累積回数405、407)を利用することがより簡便に正確な処理を行うことができる場合がある。これらは後述する第2の実施形態で用いる。第2の実施形態では、システムコールの累積回数405、407を用いて故障時の回復処理手順を決定する。
【0106】
再故障寿命Tと再発故障間隔T'との算出にいずれの時間を用いるかは、攻撃の型に応じて使い分けることが望ましい。例えば、無限ループを実行し、CPUの実行時間を浪費する型の攻撃であれば、ユーザ時間402を用いる。タイムアウトとなる入出力を行うシステムコールの発行を繰り返すことで、CPUの実行時間を浪費する型の攻撃であれば、システム時間を、それぞれ選択することで攻撃にあわせた精度の高い時間測定が可能となる。
【0107】
次に、本実施形態のチェックポイント/リスタート処理部1013が、所定のプロセス1001を監視しながらCP情報を取得し、故障が発生した場合に取得したCP情報を用いて回復処理を行う処理フローについて説明する。
【0108】
図8は、チェックポイント/リスタート処理部1013がシステムコール監視処理部1014からの通知に基づいてCP情報を取得するCP情報取得処理の処理フローである。
【0109】
本実施形態では、オンライン状態でPRAM505に保存するCP情報の最大保存数を世代数mと呼ぶ。CP0情報以外のCP情報は、新規に世代数mを越えて新規に取得した場合、古いものから順に削除される。例えば、世代数mを2と設定した場合、最新のものとその1回前の計2回分のCP情報を保存する。なお、保存するCP情報の数の決め方は本方法に限られない。例えば、保存先のPRAM505の最大容量まで記録し、その後は古いものから順に上書きすることにより消去するよう構成してもよい。
【0110】
また、オンライン状態でCP情報を取得した回数を累計数nと呼ぶ。以下、累計数nを用いて、CP情報を取得する時刻をCPn、CPnにおいて取得したCP情報をCPn情報と表す。
【0111】
チェックポイント/リスタート処理部1013は、プロセス1001が処理を開始すると、予め管理者等により設定されたCPを保存する世代数mを参照する(s601)。
【0112】
チェックポイント/リスタート処理部1013は、保存するCP情報数をカウントするカウンタをn(累計数と呼ぶ)とし、累計数nに初期値0を設定する(s602)。
【0113】
システムコール監視処理部1014は、プロセス1001が発行するシステムコール列Sを監視する(S603)。システム監視処理部1014は、情報処理装置500がオフライン状態の場合、システムコール列S0の発行の有無を監視する。監視中にコールリスト1016に保存されているシステムコール列S0が発生したことを検出すると(s604)、システムコール監視処理部1014はチェックポイント/リスタート処理部1013に検出を通知する。通知を受けたチェックポイント/リスタート処理部1013は、通知を受けた時刻をCP0とし、CP0時点のプロセス1001のメモリ状態をDRAM504上で複製することによりCP情報を取得し、CP0情報とする(s605)。
【0114】
チェックポイント/リスタート処理部1013は、時刻CP0を時刻t0とし、S604で取得したCP0情報をDRAM504からPRAM505に転送し、時刻CP0と対応づけてCP0情報をPRAM505に記録する(s606)。
【0115】
情報処理装置500がネットワークインタフェース507を介して他の装置やシステムと接続されたことを検出すると(s607)、システムコール監視処理部1014は、プロセス1001のシステムコール列Sの監視をオンライン状態の監視に切り替える。
【0116】
オンライン状態になると、システムコール監視処理部1014は、引き続きプロセス1001が発行するシステムコール列Sを監視する(s608)。ここでは、システムコール監視処理部1014は、上述のwriteシステムコールまたは関数dlopenの発行の有無を監視する。なお、オンライン状態になると、チェックポイント/リスタート処理部1013は故障の発生を監視する。そして、故障を検出した場合(s609)は、後述する図9のCP回復処理を行う。
【0117】
システムコール監視処理部1014が、システムコール列S監視中にオンライン状態における予め定めたシステムコールまたは関数を検出するとチェックポイント/リスタート処理部1013に通知する(s610)。
【0118】
チェックポイント/リスタート処理部1013は、累計数nを1インクリメントし(s611)、そして、検出時刻CPnと、CPn時点のメモリの状態をCPn情報としてs605と同様に取得する(s612)。
【0119】
次に、チェックポイント/リスタート処理部1013は、累計数nと世代数mとを比較する(s613)。累計数nが世代数より大きい場合、既に世代数m分PRAM505に記録されている。この場合、最も古いCP情報(ここでは、CPn−m情報)をPRAM505から削除してから新たに取得したCPn情報をPRAM505を記録する(s614、s615)。
【0120】
具体的には、S613における比較の結果、累計数nが世代数mより大きい場合、PRAM505における最も古いCP情報であるCPn−m情報をPRAM505から削除する。その後、新たに取得したCPn情報をPRAM505に記録する。一方、s613における比較の結果、累計数nが世代数m以下の場合、S614の処理は行わず、新たに取得したCPn情報をPRAM505に記録する(s614、s615)。
【0121】
その後、システムコール監視処理部1014がシステムコール列の監視を行う状態に戻る(s608)。
【0122】
次に、図8に示すCP情報取得処理において、チェックポイント/リスタート処理部1013が故障を検出した際のCP回復処理について説明する。図9は、CP回復処理の処理フローである。
【0123】
チェックポイント/リスタート処理部1013は、故障を検出すると、故障発生時刻(故障を検出した時刻)txをPRAM505に記録する(s101)。そして、情報処理装置500をオフラインにする(回線切断処理)(s102)。
【0124】
また、チェックポイント/リスタート処理部1013は、その時点の累計数nをカウンタiに代入する(s103)。そして、CPi情報がPRAM505に記録されているか否かを判別する(s104)。
【0125】
s104で記録されていない場合は、後述するs113に処理を進める。
【0126】
一方、s104で記録されている場合、チェックポイント/リスタート処理部1013は、CPi情報に対応づけて記録されているCPi情報を取得した時刻CPiと先に記録した故障時刻txとを用いて再故障寿命Tiを算出して代入する(Ti=tx−CPi)(s105)。
【0127】
そして、チェックポイント/リスタート処理部1013は、CPi情報を用いて回復処理を行う(s106)。
【0128】
回復処理を行い、オンライン状態になると(s107)、チェックポイント/リスタート処理部1013は、故障の発生の監視を続ける(s108)。なお、ここで、チェックポイント/リスタート処理部1013が故障を検出する前にシステムコール監視処理部1014がシステムコール列Sを検出すると、図8のステップs611に戻る。
【0129】
一方、システムコール監視処理部1014がシステムコール列Sを検出する前にチェックポイント/リスタート処理部1013が、先に検出した故障と同じ故障を検出すると(s108)、故障を検出した時刻tx'記録する(s109)。そして、オフライン(回線切断)所栄を行う(s110)。
【0130】
そして、チェックポイント/リスタート処理部1013は、時刻tx'および、時刻CPiを用いて、再発故障間隔Ti'を算出する(Ti'=tx'−CPi)(s111)。
【0131】
そして、チェックポイント/リスタート処理部1013は、再故障寿命Tiと再発故障間隔Ti' とを比較する(s112)。
【0132】
再故障寿命Tiの期間が過ぎてから故障が再発した場合、すなわち、再故障寿命Tiが再発故障間隔Ti'以上(Ti≧TI')の場合、ステップS106に戻り、同じCPi情報を用いて回復処理を行う(再試行)。
【0133】
一方、再故障寿命Ti前に故障が発生した場合、すなわち、再故障寿命Tiが再発故障間隔Ti'より短い(Ti<Ti')場合、カウンタiを1デクリメントし(s113)、カウンタiが負の値か否かを判別し(s114)、負の値であれば、チェックポイント/リスタート処理部1013は、業務(プロセス1001)を停止させる(s115)。
【0134】
一方、カウンタiが負の値でなければ(s114)、ステップS105に戻り、1回前に記録したCPi情報を用いて回復処理を行う(再始動:CP情報の後退)。
【0135】
以上、本実施形態のチェックポイント/リスタート処理部1013によるCP回復処理について説明した。
【0136】
本実施形態では、上述のように、プロセスを始動させたCP情報を取得した時刻(CP)から故障するまでの時間を計測し、再故障寿命として設定する。故障発生後、所定のCP情報を用いて、プロセスを再始動させる。そして、その再始動時に用いたCP情報を取得した時刻から再び故障するまでの時間を計測し、再発故障間隔とする。再故障寿命と再発故障間隔とを比較し、再発故障間隔より再故障寿命が長いプロセスの場合、1回前に取得したCP情報を用いてプロセスを再始動させる。このとき、再始動に用いたCP情報を取得した時刻から最初の故障までの経過時間をもとに再故障寿命を再設定する。なお、プロセスの実時間の代わりに、プロセスのユーザ時間を利用する。あるいは、プロセスのシステム時間を利用することもできる。
【0137】
本実施形態では、回復処理(再始動、再試行)に用いるCP情報を、予め定めたシステムコール列検出時に自動的に取得する。すなわち、APの埋め込みやオペレータの操作ではなく、OS自体が、CP情報を取得する。
【0138】
具体的には、本実施形態の情報処理装置は、システムコールを監視する手段と、当該手段から呼び出される、監視対象のプロセスの保全性を変更する、システムコールの一覧表を参照する手段を備える。また、オンラインプロセスのCP情報を取得する手段と、任意のCP情報を用いてプロセスを再始動する手段と、を備える。さらに、CP情報を取得する手段から呼び出されるファイルを複製する手段と、プロセスを再始動する手段から呼び出されるファイルを復元する手段とを備える。
【0139】
保全性を変更するシステムコールは具体的には、オンラインからオフラインへ切り替わるシステムコール、監視対象のプロセスに関連するファイルを更新するシステムコール、監視対象のプロセスにセキュリティパッチを適用するシステムコールなどである。従って、本実施形態によれば、本構成により、無人運用(かつ無停止運用)システムにおいて、必要十分なCP情報を取得することができる。
【0140】
本実施形態によれば、オンライン途中だけでなくオンライン直前のCP情報を取得する。このため、安全な状態に回復できるCP情報を少なくとも一つ確保することができる。
【0141】
本実施形態によれば、所定のシステムコール列の検出を契機にCP情報を取得するよう構成しているため、必要十分なCP情報を自動的に取得し保持することができる。従って、無制限にCP情報を保持することにより記録容量の無駄遣いを防ぎ、回復処理を行うために効果的なCP情報を効率的に保持することができる。
【0142】
また、本実施形態によれば、再故障寿命という概念を導入したため、故障が再発した時間と再故障寿命を比較することにより、適切なCP情報を選択して回復処理を行うことができる。すなわち、最初の故障発生直後に故障の原因(脅威の種類)を明確に判別を行うことなく、故障の再発という現象に基づいて、順次最適なCP情報を選択し、回復処理を行うことができる。
【0143】
すなわち、複数の取得した必要十分なCP情報を用いて、故障解析の有無によらずに、故障発生時に適切な回復手順を選択可能なチェックポイント/リスタート制御技術を提供することができる。
【0144】
また、本実施形態によれば、チェックポイント/リスタート処理部1013にチェックポイント/リスタート処理部1013にCP情報を取得する、再始動を行うといった契機となる指示を行う機能であるシステムコール監視手段をチェックポイント/リスタート処理部1013と同様にOS内に備えている。このため、OS外で実行されるアプリケーションであるプロセス1001からCP情報取得等の指示を受ける場合に比べ、不正コード侵入の影響をうけにくい。すなわち、プロセス1001から指示を受ける場合、プロセス1001に不正コード挿入されると、CP情報の取得を回避する、無制限に実行するなど操作を受け易い。しかし、本実施形態の構成では、そのような不安はない。
【0145】
以上により、本実施形態によれば、メモリを効率的に利用し、故障発生の状況に応じて適切な回復処理を行うことが可能なチェックポイント/リスタート技術を提供できる。
【0146】
<<第二の実施形態>>
次に、本発明を適用した第二の実施形態について説明する。第一の実施形態では、いずれのCP情報を用いて回復処理を行うかを決定するために、故障時刻、CP情報取得時刻から算出した再故障寿命Tという概念を導入している。しかし、本実施形態では、時間を導入するかわりに、システムコールの発行回数を計測する。
【0147】
本実施形態の情報処理装置500の機能構成、ハードウェア構成は、基本的に第一の実施形態と同様である。以下、本実施形態の第一の実施形態と異なる構成を説明する。
【0148】
本実施形態では、チェックポイント/リスタート処理部1013の代わりにチェックポイント/リスタート処理部1013−2を備える。チェックポイント/リスタート処理部1013−2は、CP0情報を取得後、その後のシステムコールの発行数をカウントする。そして、CP情報を取得する毎に、そのCPi情報を取得した時点CPiの時刻の代わりにシステムコールの累積発行数SCiを、CPi情報に対応づけてPRAM505に記録する。同様に、チェックポイント/リスタート処理部1013は、故障が発生した際も、発生時刻txの代わりにその時点までのシステムコールの累積発行数SCxを記録する。
【0149】
すなわち、CP情報取得処理において、本実施形態では、CP情報を取得した時点の時刻の記録は行わない。一方、システムコール監視時において、システムコールの発行回数をカウントする。さらに、故障が発生した場合は、故障時時刻txの記録ではなく、故障時のシステムコールの累積発行数SCxを記録する。
【0150】
なお、本実施形態では、再故障寿命Tは、故障発生時のシステムコールの累積発行数SCxから最近のCP情報(CPi情報)取得時のシステムコールの累積発行数SCiを減算したものと定義する(Ti=SCx−SCi)。
【0151】
図10は、本実施形態のCP回復処理の処理フローである。
【0152】
チェックポイント/リスタート処理部1013−2は、故障を検出すると、その時点の累積システムコール(SC)数SCxをPRAM505に記録する(s301)。そして、情報処理装置500をオフラインにする(回線切断処理)(s302)。
【0153】
チェックポイント/リスタート処理部1013ー2は、その時点の累計数nをカウンタiに代入する(s303)。そして、CPi情報がPRAM505に記録されているか否かを判別する(s304)。
【0154】
s304で記録されていない場合は、後述するs314に処理を進める。
一方、s314で記録されている場合は、チェックポイント/リスタート処理部1013−2は、CPi情報に対応づけて記録されているCPi情報を取得した時点の累積システムコール数SCiと先に記録した故障を検出した時点のSCxとを用いて再故障寿命Tiを算出してカウンタCに代入する(C=Ti=SCx−SCi)(s305)。
【0155】
そして、チェックポイント/リスタート処理部1013−2は、CPi情報を用いて回復処理を行う(s306)。
【0156】
回復処理を行い、オンライン状態になると(s307)、まず、チェックポイント/リスタート処理部1013−2は、CP情報取得フラグをたてる。ここで、CP情報取得フラグは本実施形態独特の構成であり、チェックポイント/リスタート処理部1013−2は、このフラグが立っている間は、システムコール列Sが検出されたとしても、CP情報を取得しないよう構成されている。
【0157】
そして、チェックポイント/リスタート処理部1013−2は故障の発生の監視を続ける(s308)。ここでは、システムコールが発行される度に故障の発生の有無を判別する。
【0158】
故障を検出しなかった場合、チェックポイント/リスタート処理部1013−2は、カウンタCを1デクリメントする(s309)。このとき、システムコールの累積発行数SCは通常どおり1インクリメントする。そして、カウンタCが0か否かを判別し(s310)、0でなければ、s308に戻り、システムコール発行毎に故障の発生の有無の検出を続ける。
【0159】
本実施形態では、システムコールの発行数で再発故障寿命を定義しているため、カウンタCが0になった時点で、再発故障寿命Tiになったものといえる。s310でカウンタが0の場合、チェックポイント/リスタート処理部1013−2は、CP情報取得フラグをおろす(s311)。これ以降、チェックポイント/リスタート処理部1013−2が故障を検出する前にシステムコール監視処理部1014がシステムコール列Sを検出すると、図8のステップs611に戻る。本構成により、本実施形態では、再発故障寿命Tiの間は、CP情報を取得しないよう構成する。
【0160】
そして、故障の監視を続ける(s311)。同じ故障が再発した場合、再発故障寿命Tiを超えた時期に故障が再発したことになるため、再試行を行うため、S306に戻る。故障の発生を検出しない間は、システムコール列Sを検出するまで、監視を続ける。
【0161】
一方、s308において、チェックポイント/リスタート処理部1013−2が、先に検出した故障と同じ故障を検出すると、再発故障寿命Tiの間に故障が再発したことになるため、情報処理装置500をオフラインにし(s313)、カウンタを1デクリメント(i=i−1)し(s314)、iが0以上の間は、s305に戻り、処理を続ける(再始動;使用するCP情報の後退)。一方、iをデクリメントした結果マイナスになった場合は、チェックポイント/リスタート処理部1013−2は、業務(プロセス1001)を停止する(s316)。
【0162】
s304で記録されていない場合は、後述するs314に処理を進める。一方、s304で記録されている場合は、チェックポイント/リスタート処理部1013−2は、システムコール数をカウントするために導入したシステムコールカウンタCに、故障発生時のシステムコールの累積発行数SCxと最も新しいCP情報(CPi情報)を取得した時点でのシステムコールの累積発行数SCiとから再故障寿命Tiを算出して代入する(S305)。
【0163】
また、チェックポイント/リスタート処理部1013−2は、CPi情報を用いて回復処理を行う(S306)。なお、本実施形態では、CP情報取得停止フラグを導入する。CP情報取得停止フラグが立っている間は、たとえ予め定めたシステムコール列を検出した場合であっても、CP情報を取得しない。オフラインここで、CP情報取得停止フラグを立てる
以上説明したように、本実施形態によれば、故障発生後の処理を決定するために、時刻ではなくシステムコールの発行回数を用いている。従って、第一の実施形態で得られる効果に加え、処理を簡単な減算カウンタで実現することができ、システムの構成を簡易なものとすることができる。
【0164】
また、本実施形態によれば、カウンタCを利用して、再故障寿命を越えない限り(カウンタCが0となるまで)、たとえば、連続故障が発生する可能性が少ないシステムでは、CP情報を取得しないようにシステムを構成することができる。一方、再故障寿命期間を超えた場合、所定のシステムコールが発行されたら、CP情報を取得するという通常の処理に戻る。すなわち、図6(a)ではCPk(図10では、CPn+1)を取得する。このように、CP情報の取得に関しても、再故障寿命を考慮し、判断することが可能となる。
【0165】
なお、以上の各実施形態においては、その機能構成は、図2に示すものを例に挙げて説明したが、これに限られない。例えば、図11に示す構成であってもよい。
【0166】
図11に示す構成は、情報処理装置500に計算機装置の仮想化技術(hypervisor)を適用したものである。
【0167】
図11において、情報処理装置500は、業務系システムと監視系システムとを備える。業務系システムは、アプリケーションプログラム1000とその代替1100、オペレーティングシステム1010とその代替1110、を備える。監視系システムは、監視プロセス1200と、オペレーティングシステム1210とを備える。アプリケーションプログラム1000とその代替1100と監視プロセス1200、および、オペレーティングシステム1010とその代替1110とオペレーティングシステム1210とは、仮想計算機1150で結合する。チェックポイント/リスタート処理部1013は仮想計算機1150が備える。この場合、チェックポイント/リスタート処理部1013は、オペレーティングシステムからも隠蔽されるので、より安全性が高まる。
【0168】
本図において、アプリケーションプログラム1000およびその代替1100は、被対象プロセス1001に関連するバイナリプログラム1002および設定ファイル1003を含む。仮想化技術を用いることにより、個々のバイナリプログラム1002や設定ファイル1003を含めて保管することが容易となる。このため、本構成によれば、メモリだけではなく、プログラムや設定ファイルについても複製する。本構成によれば、保全作業自体を推測し、プロセスに関連するファイルをバックアップすることになる。このため、保全作業自体に偽装した攻撃に対抗し、再始動に必要なファイルを保護することができる。
【0169】
監視プロセス1200は、システムコール監視処理部1014とCP情報を取得するシステムコール列を記録するコールリスト1016とを個々のオペレーティングシステム1010に登録する。オペレーティングシステム1010は、コールリスト1016に記録されているシステムコール列を検出した場合に、仮想マシン仮想計算機1150が備えるチェックポイント/リスタート処理部1013に要求を出して、アプリケーションプログラム1000とオペレーティングシステム1010と含む計算機環境の全てをCP情報として複製する。また、アプリケーションプログラム1000あるいはオペレーティングシステム1010で障害が発生した場合には再始動の指示を代替のアプリケーションプログラム1100とオペレーティングシステム1110とから実施する。
【0170】
アプリケーションプログラム1000の監視対象プロセス1001の故障に対し、監視プロセス1200は、間接的に監視することになる。このような構成にすることにより、システム間の独立性を保つことができ、業務系システムから監視系システムにウィルス等の侵入が発生しにくくなる。また、逆に監視系システムが業務系システムに影響を及ぼしにくくなる。さらに、本図においては、監視対象プロセス1001の数(アプリケーションプログラム1000)が1の場合を例に挙げて説明している。しかし、監視対象プロセス1001の数はこれに限られない。監視対象プロセス1001の数が数十から数百と多数存在し、その一方で監視プロセスが一つである場合、本図に示すようにアプリケーションプログラム1000の監視対象プロセス1001の故障に対し、監視プロセス1200は、間接的に監視する構成とすると、監視系システムが、システム全体の処理を進める上でのボトルネックとなる可能性が低くなる。
【0171】
以上説明したように、本実施形態によれば、所定のシステムコール発行時にCP情報を取得する。従って、定期的にCP情報を取得する場合に比べて、安全性が高く、必要十分なCP情報を取得することができる。このため、保全業務において、意味のある時点から回復できる可能性が高い。
【図面の簡単な説明】
【0172】
【図1】第一の実施形態の情報処理装置の構成図である。
【図2】第一の実施形態の情報処理装置の機能構成図である。
【図3】第一の実施形態の情報処理装置がオフライン状態で発行するシステムコール列を説明するための図である。
【図4】第一の実施形態の情報処理装置がオンライン状態で発行するシステムコール列を説明するための図である。
【図5】第一の実施形態の情報処理装置がオフライン状態で発行するシステムコール列を説明するための図である。
【図6】第一の実施形態の再試行および再始動を説明するための図である。
【図7】第一の実施形態の時間の種類を説明するための図である。
【図8】第一の実施形態のCP情報取得処理の処理フローである。
【図9】第一の実施形態のCP回復処理の処理フローである。
【図10】第二の実施形態のCP回復処理の処理フローである。
【図11】情報処理装置の別の機能構成図である。
【符号の説明】
【0173】
500:情報処理装置、501:マルチプロセッサ、502:プロセッサ、503:プロセッサ、504:揮発性メモリDRAM、505:相変化メモリPRAM、506:ストレージHDD、507:ネットワークインタフェース、508:入出力インタフェース、1000:アプリケーションプログラム、1001:監視対象プロセス、1010:オペレーティングシステム、1011:システムコールハンドラ、1012:システムコールサービスルーチン、1013:チェックポイント/リスタート処理部1013、1014:システムコール監視処理部、1015:発行履歴、1016:コールリスト
【出願人】 【識別番号】000005108
【氏名又は名称】株式会社日立製作所
【出願日】 平成18年6月20日(2006.6.20)
【代理人】 【識別番号】110000198
【氏名又は名称】特許業務法人湘洋内外特許事務所


【公開番号】 特開2008−3691(P2008−3691A)
【公開日】 平成20年1月10日(2008.1.10)
【出願番号】 特願2006−170146(P2006−170146)