JP2009199213A - プロセス監視方法、情報処理装置、及びプログラム - Google Patents

Abstract

【課題】マルチプロセス機能を有する情報処理装置において、複数の被管理プロセスのヘルスチェックに要する演算処理量が１つの管理プロセスに集中することを軽減する。
【解決手段】マルチプロセス機能を有する情報処理装置１は、階層的に生成されるプロセスＰＡ、ＰＣ及びＰＧを含む複数のプロセスを並列実行する。親プロセスＰＡは、親プロセスＰＡによって生成された子プロセスＰＣのヘルスチェックを実行する。子プロセスＰＣは、子プロセスＰＣによって生成された孫プロセスＰＧのヘルスチェックを実行する。
【選択図】図５

Description

本発明は、複数のプロセスを並列的に実行するマルチプロセス機能を有する情報処理装置に関し、特にこのような情報処理装置におけるプロセス監視技術に関する。

組み込みシステム等の情報処理装置は、リアルタイム性の確保、プログラムのソフトウェア部品化による生産性向上等を実現するため、一般にマルチプロセス機能を備えている。マルチプロセス機能とは、複数のプロセスを定期的に切り替えて実行したり、あるイベントの発生に応じて実行するプロセスを切り替えたりすることによって、複数のプロセスがあたかも並列実行されているような環境を実現する機能である。マルチプロセス環境は、プロセスを実行するＣＰＵ（Central Processing Unit）と、ＣＰＵで実行されるプロセスのスケジューリングを担うオペレーティングシステムプログラム（ＯＳ：Operating System Program）等のプログラムによって実現される。

マルチプロセス機能を有する情報処理装置では、複数のプロセスの各々が正常に実行されていることを確認するためのヘルスチェックが行なわれる（例えば、特許文献１〜４を参照）。

特許文献１は、１つのプロセスが他の１つのプロセスのヘルスチェックを行なう技術を開示している。具体的に述べると、特許文献１は、ソフトウェアエミュレーション方式による仮想計算機システムを開示している。当該仮想計算機システムは、２つのエミュレーションプログラムを並列に起動し、一方のエミュレーションプログラムを現用系、他方を待機系とする。具体的には、先に起動されたエミュレーションプログラムが現用系となり、待機系エミュレーションプログラムを生成する。そして、親プロセスである現用系エミュレーションプログラム及び子プロセスである待機系エミュレーションプログラムが、お互いのヘルスチェックを行なう。子プロセスである待機系エミュレーションプログラムが現用系エミュレーションプログラムの障害発生を検知すると、現用系エミュレーションプログラムを強制終了して自身を現用系に切り替えると共に、新たなエミュレーションプログラムを生成してこれを待機系とする。

また、特許文献２〜４は、１つのプロセスが他の複数のプロセスのヘルスチェックを行う技術を開示している。このうち、特許文献２は、ＵＮＩＸ（登録商標）オペレーティングシステムにおけるプロセス監視技術を開示している。具体的には、１つのプロセス管理部が、複数のプロセスグループのヘルスチェックを行うことが開示されている。ここで、プロセスグループとは、複数のプロセスを予め分類した単位である。特許文献１は、課金処理のための複数のプロセスが属する課金グループ、呼処理のための複数のプロセスが属する呼処理グループ等、複数のプロセスを機能毎に予め分類することを開示している。

特許文献３に開示されたヘルスチェック方法は、概略以下の手順により実行される。まず、始めに、ヘルスチェックを行なう管理プロセス（特許文献３では、システムヘルスチェックプログラム）が、起点プロセスに対してチェックデータを送信する。そして、起点プロセス、中間プロセス、終点プロセスの順にプロセス間通信によって当該チェックデータの受け渡しが行なわれる。チェックデータの受け渡しが正常に行なわれると、終点プロセスからヘルスチェック要求元プロセスに対して完了通知が送信される。ヘルスチェック要求元プロセスは、終点プロセスからの完了通知の受信の有無によって、障害発生を検知する。

特許文献４は、複数のサーバ上で分散して実行される複数のプロセスが連携して特定の業務を実行するサーバシステムを開示している。当該サーバシステムに含まれる複数のサーバの各々では管理プロセスが起動され、各管理プロセスが各サーバで生成されるプロセス群のヘルスチェックを行なう。１つの管理プロセスは、自身が起動されているサーバで生成されているプロセス群のヘルスチェックを行い、プロセス障害を検出した場合には、障害発生プロセスと関連する複数のプロセスの再起動を行なうために、他のサーバ上で起動されている管理プロセスに対して関連プロセスの再起動を要求する。このように、複数のサーバの各々で起動されている管理プロセス間の連携によって、複数のサーバに跨って定義されたプロセスグループ単位でのプロセス再開を可能としている。

なお、特許文献５は、広義のヘルスチェック機能を開示しているが、汎用コンピュータに接続されてオペレータによって使用されるシステムコンソールの障害を検知するためのヘルスチェック機能を開示するのみである。具体的には、汎用サーバからシステムコンソールに対して定期的にヘルスチェックデータを送信し、これに対するシステムコンソールからの応答データを汎用コンピュータが受信することによって、システムコンソールのヘルスチェックを行なう。つまり、特許文献５は、マルチプロセス機能を有する情報処理装置において起動されているプロセスのヘルスチェックを行なう技術を何ら開示していない。
特開２００６−１７８５５２号公報 特開平８−２９７５８７号公報 特開２００４−８６５７４号公報 特開２００４−１０２４９２号公報 特開平１０−１１６２１１号公報 特開２００７−１０２３３２号公報

上述した組み込みシステムで実行されるファームウェア等には、並行処理されるプロセス数が動的に増減し、かつ、並行処理されるプロセス数が膨大になるものがある。例えば、通信機器で実行されるファームウェアの中には、ユーザのアクセス数やトランザクション数に比例してプロセス数が増加するものがある。一般的に、ファームウェアは常時稼働かつ高信頼性が要求されることが多いため、ファームウェア障害の検知のために、精度の高いプロセス監視を行なうことが求められている。

特許文献２〜５に開示されているような、１つの管理プロセスが複数の被管理プロセスのヘルスチェックを行なう方法では、複数の被管理プロセスのヘルスチェックに要する演算処理量が１つの管理プロセスに集中するという問題がある。

このうち、特許文献３に開示された技術によれば、被管理プロセス間でのプロセス間通信によって、管理プロセスが直接的にチェックデータを送信するプロセス数を削減できる。しかしながら、管理プロセスは、多数の終点プロセスのヘルスチェックを行なうために、終点プロセス数に応じた回数だけ繰り返しチェックデータを送信する必要がある。このため、特許文献３に開示された技術では、被管理プロセスの増加に比例して管理プロセスのヘルスチェックに要する演算処理量が増大する状況に変わりは無いため、残念ながら、プロセス数の増大に適応できる十分なスケーラビリティを有するものではない。

また、特許文献４に開示された技術は、複数のサーバの各々にて管理プロセスが生成されるが、各サーバで起動されるプロセスは全て１つの管理プロセスがヘルスチェックを行なう構成である。このため、当該技術もまた、プロセス数の増大に適応できる十分なスケーラビリティを有するものではない。

なお、特許文献６は、複数の情報処理装置において、複数のプロセスを分散実行するロードバランサ型のクラスタシステムを開示している。つまり、特許文献６に開示された技術は、複数のプロセスを複数の情報処理装置で実行することにより、１つの情報処理装置にプロセス実行負荷が集中することを軽減するものである。しかしながら、特許文献６は、複数の被管理プロセスのヘルスチェックに要する演算処理量が１つの管理プロセスに集中することを軽減するための技術を何ら開示するものではない。

本発明は、上述した知見に基づいてなされたものであって、マルチプロセス機能を有する情報処理装置において、複数の被管理プロセスのヘルスチェックに要する演算処理量が１つの管理プロセスに集中することを軽減する技術の提供を目的とする。

本発明の第１の態様は、マルチプロセス機能を有する情報処理装置におけるプロセス監視方法である。当該方法は、親プロセスによって生成された子プロセスのヘルスチェックを前記親プロセスが実行するステップ（ａ）と、前記子プロセスによって生成された孫プロセスのヘルスチェックを前記子プロセスが実行するステップ（ｂ）とを含む。

本発明の第２の態様は、マルチプロセス機能を有する情報処理装置である。当該情報処理装置は、ファームウェアを記憶する記憶部と、前記ファームウェアに基づいて生成される複数のプロセスを並列的に実行する命令実行部とを備える。さらに、前記複数のプロセスは、親プロセス、前記親プロセスによって生成される子プロセス、及び前記子プロセスによって生成される孫プロセスを含み、前記親プロセスが前記子プロセスのヘルスチェックを実行し、前記子プロセスが前記孫プロセスのヘルスチェックを実行する。

本発明の第３の態様は、コンピュータにより並列的に実行される複数のプロセスを含むプログラムである。当該プログラムに含まれる前記複数のプロセスは、親プロセス、前記親プロセスによって生成される子プロセス、及び前記子プロセスによって生成される孫プロセスを含む。さらに、前記複数のプロセスは、前記親プロセスが前記子プロセスのヘルスチェックを行い、前記子プロセスが前記孫プロセスのヘルスチェックを行う階層化されたプロセス監視を前記コンピュータに実行させることを特徴とする。

上述した本発明の第１乃至第３の態様では、階層的に生成される複数の被管理プロセスの障害監視を行うに際して、子プロセスが孫プロセスのヘルスチェックを行なうため、親プロセスは子プロセスのヘルスチェックのみを行えばよい。すなわち、被管理プロセスのヘルスチェックに要する演算処理量を、被管理プロセス（つまり子プロセス）を含む複数のプロセス間（つまり親プロセス及び子プロセスの間）で分散できる。したがって、本発明の第１乃至第３の態様によれば、複数の被管理プロセス（つまり、子プロセス及び孫プロセス）のヘルスチェックに要する演算処理量が１つの管理プロセス（つまり、親プロセス）に集中することを軽減できる。

以下では、本発明を適用した具体的な実施の形態について、図面を参照しながら詳細に説明する。各図面において、同一要素には同一の符号が付されており、説明の明確化のため、必要に応じて重複説明は省略される。

＜発明の実施の形態１＞
本実施の形態にかかる情報処理装置１の構成を図１に示す。図１において、ＣＰＵ（Central Processing Unit）１０は、不揮発性記憶装置１１に保存されたファームウェア１１０を主記憶装置１２に読み出し、ファームウェア１１０に含まれる命令をデコードし、命令に応じた処理、例えば、算術演算論理演算等の演算処理や、不揮発性記憶装置１１及び主記憶装置１２に対するアクセスを実行する。また、情報処理装置１は、マルチプロセス機能を有しており、ファームウェア１１０に含まれる複数のプロセスを並列的に実行可能である。なお、情報処理装置１にマルチプロセス機能を持たせるためには、例えば、ＣＰＵ１０との連携によってマルチプロセス環境をもたらすＯＳ（不図示）を不揮発性記憶装置１１に保存しておき、ＣＰＵ１０に当該ＯＳを実行させればよい。

不揮発性記憶装置１１は、例えば、ＰＲＯＭ（Programmable Read Only Memory）、ＥＥＰＲＯＭ（electrically erasable PROM）等である。

主記憶装置１２は、不揮発性記憶装置１１から読み出されたＯＳ（不図示）及びファームウェア１１０の格納領域、並びにＯＳ（不図示）及びファームウェア１１０によって使用されるデータの格納領域として使用される。

図２は、ファームウェア１１０を実行することによって生成される複数のプロセスの階層構成を示す図である。図１において、プロセスＰＡが最上位のプロセス（以下、ルートプロセスと呼ぶ）である。

図１に示す５つのプロセスＰＢ、ＰＣ、ＰＤ、ＰＥ及びＰＦは、ルートプロセスであるプロセスＰＡによって生成される。つまり、これら５つのプロセスＰＢ、ＰＣ、ＰＤ、ＰＥ及びＰＦは、プロセスＰＡの「子プロセス」である。

図１に示すプロセスＰＧ及びＰＨは、プロセスＰＣによって生成される。つまり、プロセスＰＧ及びＰＨは、プロセスＰＣの「子プロセス」であり、かつプロセスＰＡの「孫プロセス」である。

図１に示すプロセスＰＩ及びＰＪは、プロセスＰＥによって生成される。つまり、プロセスＰＩ及びＰＨは、プロセスＰＥの「子プロセス」であり、かつプロセスＰＡの「孫プロセス」である。

最後に、図１に示すプロセスＰＫは、プロセスＰＩによって生成される。つまり、プロセスＰＫは、プロセスＰＩの「子プロセス」であり、かつプロセスＰＡの「曾孫プロセス」である。

また、図１に破線で示したプロセスグループ２０１、２０２、３０１、４０１、及び５０１は、複数のプロセスを便宜上グループ分けしたものである。プロセスグループへのグループ化は、例えば、あるプロセスの動作に他のプロセスの動作を必要とするためにプロセス実行上の依存関係がある複数のプロセスを単位として行えばよい。また、プロセスグループへのグループ化は、使用するリソースが共通する複数のプロセス等を単位として行ってもよい。

続いて、本実施の形態におけるプロセス監視について説明する。図２のプロセスＰＡは、自身が生成した子プロセスＰＢ〜ＰＦとの間でプロセス間通信を行ない、これら子プロセスＰＢ〜ＰＦのヘルスチェックを実行する。また、図２のプロセスＰＣは、自身が生成した子プロセスＰＧ及びＰＨとの間でプロセス間通信を行ない、これら子プロセスＰＧ及びＰＨのヘルスチェックを実行する。同様に、プロセスＰＥは子プロセスであるプロセスＰＩ及びＰＪのヘルスチェックを行い、プロセスＰＩは子プロセスであるプロセスＰＫのヘルスチェックを行なう。すなわち、本実施の形態では、ルートプロセスであるプロセスＰＡが配下の子プロセス、孫プロセス、及び曾孫プロセスの全てのヘルスチェックを行なうのではなく、各々のプロセスが自身の子プロセスに対するヘルスチェックを行なうことを特徴としている。

子プロセスを生成した親プロセスは、ヘルスチェックの実行のために、ヘルスチェックテーブルを生成するとよい。ヘルスチェックテーブルは、子プロセスに関するヘルスチェックの定義情報を格納するテーブルである。図３にヘルスチェックテーブルの具体例を示す。

図３（ａ）のヘルスチェックテーブル３１は、プロセスＰＡによって生成されるヘルスチェックテーブルの具体例である。図３（ａ）の例では、子プロセスＰＢ〜ＰＦの各々について、プロセスグループ識別情報、プロセス識別情報、タイムアウト時間、シーケンス番号が管理されている。ここで、プロセスグループ識別情報とは、プロセスが属するプロセスグループを識別するための情報である。図３の例では、図２に示したプロセスグループの符号をプロセスグループ識別情報としている。プロセス識別情報は、各プロセスを識別するための情報である。図３の例では、図２に示した各プロセスの符号をプロセス識別情報としている。

図３（ａ）のタイムアウト時間は、子プロセスに対して後述するヘルスチェック要求データＤ１を送信してからこれに対する子プロセスからのヘルスチェック応答データＤ２を受信するまでの上限時間を示す。タイムアウト時間内にヘルスチェック応答データＤ２が到達しない場合、親プロセスであるプロセスＰＡは、子プロセスの障害発生と判定する。

図３（ａ）のシーケンス番号は、ヘルスチェック要求データＤ１に付与される番号である。子プロセスは、ヘルスチェック応答データＤ２に親プロセスから受信したシーケンス番号を付与して送信する。つまり、シーケンス番号は、要求データＤ１と応答データＤ２とを対応付けるために使用される。プロセスＰＡは、子プロセスにヘルスチェック要求を行なう度に、ヘルスチェックテーブル３１上のシーケンス番号を１つずつ増加させる。

一方、図３（ｂ）のヘルスチェックテーブル３２は、プロセスＰＣによって生成されるヘルスチェックテーブルの具体例である。ヘルスチェックテーブル３２は、プロセスＰＣの子プロセスＰＧ及びＰＨについて、図３（ａ）のヘルスチェックテーブル３１と同様の項目を管理している。

続いて、ヘルスチェックために親子プロセス間で送受信されるデータについて説明する。図４（ａ）〜（ｆ）は、プロセス間通信によって親子プロセス間で送受信されるヘルスチェック用データの具体例を示している。

図４（ａ）に示すヘルスチェック要求データＤ１は、ヘルスチェックの要求を行なう親プロセスから子プロセスに対して送信される。ヘルスチェック要求データＤ１は、送信先の子プロセスの識別情報が指定される「宛先フィールド」、送信元の親プロセスを示す識別情報が指定される「送信元フィールド」、ヘルスチェック要求であることを示す「データ種別フィールド」、並びに上述した「シーケンス番号フィールド」及び「タイムアウト時間フィールド」を含む。

図４（ｂ）に示すヘルスチェック応答データＤ２は、ヘルスチェック要求データＤ１を受信した子プロセスから親プロセスに対して送信される。ヘルスチェック応答データＤ２は、送信先の親プロセスの識別情報が指定される「宛先フィールド」、送信元の子プロセスを示す識別情報が指定される「送信元フィールド」、ヘルスチェック応答であることを示す「データ種別フィールド」、要求データＤ１に含まれていた「シーケンス番号フィールド」、及び「ヘルスチェック結果フィールド」を含む。ヘルスチェック結果は、ヘルスチェックの結果がＯＫであるかＮＧであるかを示す。

図４（ｃ）に示すヘルスチェック停止要求データＤ３は、プロセス終了のためにヘルスチェックの終了を要求する子プロセスから親プロセスに対して送信される。ヘルスチェック停止要求データＤ３は、送信先の親プロセスの識別情報が指定される「宛先フィールド」、送信元の子プロセスを示す識別情報が指定される「送信元フィールド」、及びヘルスチェック停止要求であることを示す「データ種別フィールド」を含む。

図４（ｄ）に示すヘルスチェック停止応答データＤ４は、ヘルスチェックを停止したことを通知するために、ヘルスチェック停止要求データＤ３を受信した親プロセスから子プロセスに対して送信される。ヘルスチェック停止要求データＤ３は、送信先の子プロセスの識別情報が指定される「宛先フィールド」、送信元の親プロセスを示す識別情報が指定される「送信元フィールド」、及びヘルスチェック停止応答であることを示す「データ種別フィールド」を含む。

図４（ｅ）に示すタイムアウト時間変更要求データＤ５は、自身の障害判定のために親プロセスが設定しているタイムアウト時間の変更を要求する子プロセスから親プロセスに対して送信される。タイムアウト時間変更要求データＤ５は、送信先の親プロセスの識別情報が指定される「宛先フィールド」、送信元の子プロセスを示す識別情報が指定される「送信元フィールド」、タイムアウト時間変更要求であることを示す「データ種別フィールド」、及び希望のタイムアウト時間示す「タイムアウト時間フィールド」を含む。

図４（ｆ）に示すタイムアウト時間変更応答データＤ６は、タイムアウト時間を変更したことを通知するために、タイムアウト時間変更要求データＤ５を受信した親プロセスから子プロセスに対して送信される。タイムアウト時間変更応答データＤ６は、送信先の子プロセスの識別情報が指定される「宛先フィールド」、送信元の親プロセスを示す識別情報が指定される「送信元フィールド」、及びタイムアウト時間変更応答であることを示す「データ種別フィールド」を含む。

続いて以下では、図５を参照して、本実施の形態におけるヘルスチェックの基本シーケンスを説明する。図５は、プロセスＰＡによるヘルスチェック周期１回分の動作を表している。なお、説明簡略化のために、図５においてプロセスＰＩ、ＰＪ及びＰＫの記載を省略するとともに、プロセスＰＥは子プロセスを有していないものとして説明する。

図５において、プロセス間通信によって、子プロセスＰＢ〜ＰＦに対してヘルスチェック要求データＤ１を送信する（Ｓ１１〜Ｓ１５）。ここで、プロセスＰＡは、周期的に子プロセスＰＢ〜ＰＦに対して要求データＤ１の送信を周期的に行えばよい。

子プロセスを有していないプロセスＰＢ並びにＰＤ〜ＰＦ（上述の通り、プロセスＰＥは説明便宜上子プロセスを有していないと仮定する）は、親プロセスＰＡからヘルスチェック要求データＤ１を受信したことに応じて、自身のヘルスチェック結果を含むヘルスチェック応答データＤ２をプロセスＰＡに対して送信する（Ｓ２１、Ｓ２３〜Ｓ２５）。

一方、子プロセスＰＧ及びＰＨを有するプロセスＰＣは、プロセスＰＡからヘルスチェック要求データＤ１を受信したことに応じて、子プロセスＰＧ及びＰＨに対してヘルスチェック要求データＤ１を送信する（Ｓ１６及びＳ１７）。

プロセスＰＧ及びＰＨは、子プロセスを有していない。このため、プロセスＰＧ及びＰＨは、親プロセスＰＣからヘルスチェック要求データＤ１を受信したことに応じて、自身のヘルスチェック結果を含むヘルスチェック応答データＤ２をプロセスＰＣに対して送信する（Ｓ２６及びＳ２７）。

プロセスＰＣは、ヘルスチェック結果ＯＫを示すヘルスチェック応答データＤ２をヘルスチェックテーブル３２に規定されたタイムアウト時間内に子プロセスＰＧ及びＰＨからの受信した場合、プロセスＰＡに対してヘルスチェック結果ＯＫを示すヘルスチェック応答データＤ２を送信する（Ｓ２２）。

なお、例えば、プロセスＰＣは、Ｓ１６におけるヘルスチェック要求データＤ１の送信時刻とＳ２６におけるヘルスチェック応答データＤ２の受信時刻との差が、ヘルスチェックテーブル３２に規定されたプロセスＰＧに対するタイムアウト時間より小さい場合に、所定のタイムアウト時間内に子プロセスＰＧからヘルスチェック応答データＤ２を受信したと判定すればよい。ここで、ヘルスチェック要求データＤ１とヘルスチェック応答データＤ２の対応付けは、上述したシーケンス番号により行えばよい。プロセスＰＨに対するヘルスチェック判定もプロセスＰＧと同様とすればよい。

続いて、新たな子プロセスが生成されてから親プロセスのヘルスチェック対象に追加されるまでの処理手順について、図６のシーケンス図を参照して説明する。図６は、プロセスＰＡが新たな子プロセスＰＬを生成し、プロセスＰＬをヘルスチェック対象に追加する処理手順を示すシーケンス図である。

ステップＳ３１では、プロセスＰＡが新たな子プロセスＰＬを生成する。次に、ステップＳ３２では、プロセスＰＡのヘルスチェック対象にプロセスＰＬを追加するため、プロセスＰＡが、ヘルスチェックテーブル３１にプロセスＰＬに関するエントリを追加する。その後、プロセスＰＡは、次のヘルスチェック周期において、ヘルスチェック要求データＤ１をプロセスＰＬに送信する（Ｓ３３）。ステップＳ３４では、ヘルスチェック要求データＤ１に応答して、自身のヘルスチェック結果を示すヘルスチェック応答データＤ２を送信する。

なお、新たに生成される子プロセスＰＬをヘルスチェック対象とする必要がない場合には、親プロセスＰＡは、プロセスＰＬをヘルスチェックテーブル３１に登録する必要はない。また、ここではプロセスＰＡが子プロセスＰＬを生成する場合について例示したが、ヘルスチェック対象となっている他のプロセスが新たな子プロセスを生成する場合の手順も同様とすればよい。図６に示したように、動的に生成される新たなプロセスをヘルスチェック対象とすることによって、動的に生成されるプロセスのヘルスチェック管理が可能になる。

続いて、ヘルスチェック対象とされているプロセスの終了に伴うヘルスチェック停止手順の具体例について説明する。図７のシーケンス図は、プロセスＰＥの終了時に、親プロセスＰＡのヘルスチェック対象からプロセスＰＥを除外する際の処理手順を示している。

ステップＳ４１では、プロセスＰＥがプロセスＰＡに対してヘルスチェック停止要求データＤ３を送信する。ステップＳ４２では、ヘルスチェック停止要求データＤ３を受信したプロセスＰＡが、ヘルスチェックテーブル３１からプロセスＰＥのエントリを削除する。ステップＳ４３では、プロセスＰＡがプロセスＰＥに対してヘルスチェック停止応答データＤ４を送信する。ステップＳ４４では、ヘルスチェック停止応答データＤ４を受信したプロセスＰＥが、プロセス終了する。ステップＳ４５では、プロセスＰＡが、プロセスＰＥの子孫プロセス、すなわち図１に示したプロセスＰＩ、ＰＪ及びＰＫを終了させる。

図７に示したように、子プロセスＰＥが停止する前に、親プロセスＰＡに対してヘルスチェック停止要求データＤ３を送信しておくことによって、プロセスＰＡが、プロセスＰＥからのヘルスチェック結果ＯＫを示すヘルスチェック応答データＤ２が得られないために、プロセスＰＥのヘルスチェック結果がＮＧと判定することがなくなる。つまり、図７の処理手順によって、動的に削除されるプロセスのヘルスチェック管理が可能になる。

続いて、タイムアウト時間の変更手順の具体例について説明する。図８のシーケンス図は、プロセスＰＣが管理しているプロセスＰＧのタイムアウト時間の変更手順を示している。

ステップＳ５１では、プロセスＰＧが、プロセスＰＣに対してタイムアウト時間変更要求データＤ５を送信する。ステップＳ５２では、タイムアウト時間変更要求データＤ５を受信したプロセスＰＣが、プロセスＰＧのタイムアウト時間変更に伴って、親プロセスＰＡによって管理されている自身のタイムアウト時間の変更が必要か否かを判定する。具体的には、プロセスＰＣは、プロセスＰＡにより管理されている自身のタイムアウト時間を、子プロセスＰＧ及びＰＨのタイムアウト時間と、ヘルスチェック要求データＤ１及び応答データＤ２の送受信に要する処理時間の合計と比較して、自身のタイムアウト時間が処理に必要十分な長さであるか否かを判定すればよい。

プロセスＰＣは、自身のタイムアウト時間の変更が必要で有ると判定した場合、プロセスＰＡに対してタイムアウト時間変更要求データＤ５を送信する（Ｓ５３）。ステップＳ５４では、プロセスＰＡが、ヘルスチェックテーブル３１に記録されたプロセスＣのタイムアウト時間を、ステップＳ５３にて受信したタイムアウト時間変更要求データＤ５のタイムアウト時間フィールドに指定された値に変更する。ステップＳ５５では、プロセスＰＡが、プロセスＰＣに対してタイムアウト時間変更応答データＤ６を送信する。

ステップＳ５６において、プロセスＰＣは、ヘルスチェックテーブル３２に記録されたプロセスＰＧのタイムアウト時間を、ステップＳ５１で受信したタイムアウト時間変更要求データＤ５のタイムアウト時間フィールドに指定された値に変更する。最後に、ステップＳ５７では、プロセスＰＣが、プロセスＰＧに対してタイムアウト時間変更応答データＤ６を送信する。

図８に示した手順によって、子プロセス数の増減等によってヘルスチェック対象プロセスの負荷が変動した場合に、当該ヘルスチェック対象プロセスに対するタイムアウト時間を動的に変更することがきる。つまり、図８の処理手順によって、動的に負荷が変動するプロセスのヘルスチェック管理が可能になる。

続いて以下では、ヘルスチェック対象プロセスが障害状態に陥った場合の当該プロセスの再開手順について詳しく説明する。図９及び１０は、プロセスＰＣがヘルスチェックＮＧとなり障害状態と判定された場合のプロセス再開手順の具体例を示すシーケンス図である。図９は、プロセス再開手順の前半を示し、図１０は、プロセス再開手順の後半を示している。なお、図９及び図１０では、上述した図５と同様に、プロセスＰＩ、ＰＪ及びＰＫの表示を省略している。

図９のステップＳ６１では、プロセスＰＡがプロセスＰＣの障害を検知する。プロセスＰＡがプロセスＰＣのプロセス障害を検知するのは、プロセスＰＣから受信したヘルスチェック応答データＤ２に示されているヘルスチェック結果がＮＧである場合、又は、プロセスＰＣからのヘルスチェック応答データＤ２が所定のタイムアウト時間内に受信できない場合である。なお、図７のＳ４１に示したように、プロセスＰＣがプロセスＰＡに対してヘルスチェック停止要求データＤ３を送った後に、プロセスＰＣから受信したヘルスチェック応答データＤ２に示されるヘルスチェック結果がＮＧである場合、又はヘルスチェック応答データＤ２が受信できない場合には、プロセスＰＡはプロセスＰＣの障害と判定しない。

ステップＳ６２では、プロセスＰＡが、プロセスＰＣ、並びにプロセスＰＣと同じプロセスグループ２０１に属するプロセスＰＢ及びＰＤを自身のヘルスチェックテーブル３１から削除する。

ステップＳ６３において、プロセスＰＡは、プロセスＰＣの障害を検知したこと、これに応じてプロセスＰＣが属するプロセスグループ２０１内のプロセス群ＰＢ、ＰＣ及びＰＤを再起動させることを、外部に通知する。外部への通知は、例えば、システムログを残すことにより行なえばよい。また、外部への通知は、保守者が目視により確認できるＬＥＤ（不図示）を情報処理装置１に設けておき、当該ＬＥＤを点灯させることによって行ってもよい。また、外部への通知は、情報処理装置１とネットワークを介して通信可能に接続された他の装置に対してＳＮＭＰ（Simple Network Management Protocol）トラップを送ることにより行ってもよい。なお、このタイミングでは、プロセスＰＣが障害状態であるために正常に外部に障害発生を通知することができない可能性がある。しかしながら、万一、この後に説明するプロセスＰＢ〜ＰＤの強制終了及び再生成に失敗した場合、障害の範囲が広がってしまうおそれがある。このため、このタイミングで通知することによって、できる限り多くの障害情報を残せるという利点がある。

ステップＳ６４〜Ｓ６６では、プロセスＰＡが、プロセスグループ２０１に属するプロセスＰＢ〜ＰＤを強制的に終了させる。さらに、ステップＳ６７及びＳ６８では、終了させた子プロセスＰＢ〜ＰＤの子孫プロセス、具体的にはプロセスＰＧ及びＰＨを強制的に終了させる。

図１０のシーケンスは、図９の手順後に行なわれるプロセス再起動手順の具体例である。図１０のステップＳ７１〜７３では、プロセスＰＡが、子プロセスＰＢ〜ＰＤを再起動する。ステップＳ７４では、プロセスＰＡが、再起動させた子プロセスＰＢ〜ＰＤのエントリを自身のヘルスチェックテーブル３１に追加する。

ステップＳ７５及び７６では、再起動されたプロセスＰＣが、子プロセスＰＧ及びＰＨを再起動する。ステップＳ７７では、プロセスＰＣが、再起動させた子プロセスＰＧ及びＰＨのエントリを自身のヘルスチェックテーブル３２に追加する。

ステップＳ７８において、プロセスＰＡは、ステップＳ７４でのヘルスチェックテーブル更新が完了し、プロセスＰＢ〜ＰＤの再起動が完了したことに応じて、プロセス障害が復旧したことを外部に通知する。

図９及び１０に示したプロセス再開手順、すなわち親プロセスが子プロセスを再起動させる処理手順は、複数のプロセスが同時に障害になった場合に特に利点が大きい。例えば、図１に示したプロセスＰＣ及びＰＫが同時に障害になった場合を考える。この場合、プロセスグループ２０１に属するプロセスＰＣを再起動させるのは、プロセスＰＡである。一方、プロセスグループ５０１に属するプロセスＰＫを再起動させるのは、プロセスＰＩである。つまり、同時に障害に陥った２つのプロセスの再起動処理を別々のプロセスが行うことになる。

つまり、親プロセスが子プロセスの障害を監視するとともに、プロセス障害時のプロセス再起動を親プロセスが実行する上述の手順は、プロセスの障害監視や再起動を１つの管理プロセス（例えば、プロセスＰＡ）が行う場合に比べて、１つのプロセス（例えばプロセスＰＡ）に対してプロセス管理の負荷が集中することを回避できる。また、プロセス障害のために強制終了された子プロセスの再起動を親プロセスが担うことによって、１つの管理プロセス（例えば、プロセスＰＡ）が集中的にプロセス再起動を実行する場合に比べて、プロセス再起動に要する時間が減少することが期待できる。このため、並行して実行されるプロセス数が非常に多いファームウェアのプロセス障害監視、プロセス再起動方式として、図９及び図１０に示した手順は特に有益である。

上述した本実施の形態にかかる情報処理装置１は、以下に述べる第１及び第２の効果を奏する。第１に、本実施の形態では、親プロセスが子プロセスのヘルスチェックを行なうため、ヘルスチェック処理の負荷が階層的に生成される複数のプロセス間で分散されるという効果がある。

この第１の効果によって、例えばルートプロセスＰＡ等の特定のプロセスへのヘルスチェック処理負荷の集中を避けられる。このため、あるヘルスチェック対象プロセスのヘルスチェック間隔を短くして当該ヘルスチェック対象プロセスに対する精度の高い状態監視を行なうことも容易となる。

例えば、プロセスＰＤのヘルスチェック間隔を短くして詳細な監視を行なう場合、親プロセスＰＡの負荷が増大する。しかしながら、プロセスＰＡは、孫プロセスＰＧ及びＰＨに対するヘルスチェック処理を直接的に行っておらず、その分の負荷がプロセスＰＣに分散されている。このため、親プロセスＰＡは、プロセスＰＤの詳細監視による負荷の増大を許容できる可能性が高まる。これは、情報処理装置１が、並行して実行されるプロセス数が膨大なファームウェアを実行する場合に、ヘルスチェック間隔を短くして詳細なプロセス監視を行なうことを可能にする。

また第２に、本実施の形態では、障害発生後のプロセス再開時に、親プロセスが子プロセスの再起動を行なうため、プロセス再起動処理の負荷が階層的に生成される複数のプロセス間で分散されるという効果がある。

プロセス障害の発生時には、本実施の形態でも述べたようなプロセスグループ単位でのプロセス再起動が有効である。プロセスグループに含まれる複数のプロセスの再起動を常に１つの管理プロセス（例えば、プロセスＰＡ）が行なうのでは、負荷集中のために全てのプロセスの再起動までに要する時間が増大することが懸念される。本実施の形態は、プロセス再起動に要する負荷を複数のプロセス間で分散できるため、全プロセスの再起動の完了までに要する時間を縮小させることが期待できる。

＜発明の実施の形態２＞
本実施の形態と上述した実施の形態１との相違点は、図２に示したルートプロセスＰＡの監視を行なうために、プロセスＰＡの機能を２つのプロセスＰＰ及びＰＱに分ける点である。

なお、本実施の形態にかかる情報処理装置の構成、ヘルスチェック手順、プロセス生成に伴うヘルスチェック開始手順、プロセス終了に伴うヘルスチェック停止手順、タイムアウト時間の変更手順、プロセス再開の手順等は、上述した発明の実施の形態１と同様とすれば良いため、ここでは重複説明を省略する。

図１１に、本実施の形態にかかる情報処理装置において生成されるプロセス群の階層構成を示す。プロセスＰＰ及びＰＱは、互いに相手のプロセスを監視し、相手のプロセスに障害が発生した場合にこれを再起動させる。これにより、プロセスＰＡの負荷がプロセスＰＰ及びＰＱに分散されることになり、負荷分散の観点でさらに効果的である。また、図２ではプロセスＰＡに障害が発生した場合に障害復旧が困難であるが、本実施の形態では、プロセスＰＰ及びプロセスＰＱの両方に障害が発生しない限り、プロセス障害を復旧することが。

＜発明の実施の形態３＞
上述した発明の実施の形態１では、例えば、プロセスＰＣは、ルートプロセスＰＡからのヘルスチェック要求データＤ１を受信したことに応じて子プロセスＰＧ及びＰＨに対するヘルスチェックを行い、子プロセスに対するヘルスチェックが全て正常である場合に、ルートプロセスＰＡにヘルスチェックＯＫを示すヘルスチェック応答データＤ２を送信するものとして説明した。しかしながら、このように、階層化された各々のプロセスによるヘルスチェックの実行に依存関係をもたせた方式は、本発明の一例に過ぎない。例えば、プロセスＰＣによる子プロセスＰＧ及びＰＨの監視をルートプロセスＰＡから一層独立させてもよい。

例えば、プロセスＰＣがプロセスＰＧの障害を検知した場合に、プロセスＰＣがプロセスＰＧ及びＰＨを強制的に終了させ、これらを再起動してもよい。また、プロセスＰＣは、プロセスＰＡからのヘルスチェック要求データＤ１に対する応答を、自身のヘルスチェック結果に応じて返答すればよい。

このような実施形態によれば、プロセスＰＣがプロセスＰＡへのヘルスチェック応答データＤ２の送信を行なわないこと、又はヘルスチェックＮＧを示すヘルスチェック応答データＤ２を送信することによって生じるプロセスＰＡによるプロセスＰＢ〜ＰＤ並びにＰＧ及びＰＨの強制終了を待つこと無く、プロセスＰＣによってプロセスＰＧ及びＰＨを再起動させることができる。図１２に、プロセスＰＧの障害を検知したプロセスＣによるプロセスＰＧ及びＰＨの再開手順の具体例を示す。

図１２のステップＳ８１では、プロセスＰＣがプロセスＰＧの障害を検知する。ステップＳ８２では、プロセスＰＣが、プロセスＰＧ、及びプロセスＰＧと同じプロセスグループ３０１に属するプロセスＰＨを自身のヘルスチェックテーブル３２から削除する。ステップＳ８３では、プロセスＰＣが、プロセスＰＧの障害を検知したこと、これに応じてプロセスＰＧが属するプロセスグループ３０１内のプロセス群ＰＧ及びＰＨを再起動させることを、外部に通知する。

ステップＳ８４及びＳ８５では、プロセスＰＣが、プロセスグループ３０１に属するプロセスＰＧ及びＰＨを強制的に終了させる。ステップＳ８６及びＳ８７では、プロセスＰＣが、プロセスＰＧ及びＰＨを再起動する。ステップＳ８８では、プロセスＰＣが、再起動させた子プロセスＰＧ及びＰＨのエントリを自身のヘルスチェックテーブル３２に追加する。最後に、ステップＳ８９において、プロセスＰＣは、プロセス障害が復旧したことを外部に通知する。

＜その他の実施の形態＞
上述した発明の実施の形態１では、プロセス障害の発生に起因して複数のプロセスを再起動する場合に、親プロセスが子プロセスの再起動を担うことによって、プロセス再起動に要する負荷をプロセス間で分散する例を示した。しかしながら、プロセス障害の発生に起因する複数のプロセスの再起動を１つの管理プロセス（例えばプロセスＰＡ）が集中的に行ってもよい。このような実施形態によっても、少なくともヘルスチェックに要する負荷をプロセス間で分散できるため、上述した第１の効果を奏することができる。

また、発明の実施の形態１では、プロセス障害時に、プロセスグループ単位でプロセスを強制的に終了し、これらを再起動するものとして説明した。しかしながら、プロセスグループ単位での再起動を行わずに、障害の発生したプロセスだけに限定して再起動してもよいし、複数のプロセス全体を再起動させてもよい。このような実施形態によっても、ヘルスチェックに要する負荷をプロセス間で分散できるため、上述した第１の効果を奏することができる。

また、プロセス障害発生の外部への通知は必ずしも行わなくてもよい。このような実施形態によっても、上述した第１及び第２の効果を奏することができる。

さらに、本発明は上述した実施の形態のみに限定されるものではなく、既に述べた本発明の要旨を逸脱しない範囲において種々の変更が可能であることは勿論である。

発明の実施の形態１にかかる情報処理装置の構成図である。 発明の実施の形態１にかかる情報処理装置で実行されるプロセスの階層構成を示す図である。 プロセスＰＡ及びプロセスＰＣの各々によって生成されるヘルスチェックテーブルの一例を示す図である。 プロセス間通信によりプロセス間で送受信されるヘルスチェックに関するデータのデータ構造の具体例を示す図である。 上位プロセスにより実行される下位プロセスのヘルスチェックの手順を示すシーケンス図である。 新たなプロセスの生成が行なわれる場合のヘルスチェック開始手順を示すシーケンス図である。 プロセス終了時のヘルスチェック停止手順を示すシーケンス図である。 ヘルスチェックに関するタイムアウト時間の変更手順を示すシーケンス図である。 プロセス障害発生時のプロセス再開手順を示すシーケンス図である。 プロセス障害発生時のプロセス再開手順を示すシーケンス図である。 発明の実施の形態２にかかる情報処理装置で実行されるプロセスの階層構成を示す図である。 発明の実施の形態３にかかるプロセス障害発生時のプロセス再開手順を示すシーケンス図である。

符号の説明

１ 情報処理装置
１０ ＣＰＵ（Central Processing Unit）
１１ 不揮発性記憶装置
１１０ ファームウェア
１２ 主記憶装置
３１、３２ ヘルスチェックテーブル
２０１、２０２、３０１、４０１、５０１ プロセスグループ
ＰＡ、ＰＢ、ＰＣ、ＰＤ、ＰＥ、ＰＦ、ＰＧ、ＰＨ、ＰＩ、ＰＪ、ＰＫ プロセス

Claims (15)

1. マルチプロセス機能を有する情報処理装置におけるプロセス監視方法であって、
   親プロセスによって生成された子プロセスのヘルスチェックを前記親プロセスが実行するステップ（ａ）と、
   前記子プロセスによって生成された孫プロセスのヘルスチェックを前記子プロセスが実行するステップ（ｂ）と、
   を備えるプロセス監視方法。
2. 前記ステップ（ｂ）において、前記子プロセスは、監視対象とされた複数の前記孫プロセスのヘルスチェックを行なう、
   請求項１に記載のプロセス監視方法。
3. 前記ステップ（ｂ）において、前記子プロセスは、前記親プロセスからのヘルスチェック要求を受信したことに応じて、前記孫プロセスに対してヘルスチェック要求を送信するとともに、前記ヘルスチェック要求に応答して前記孫プロセスから正常応答が受信された場合に、前記親プロセスに対して正常応答を送信する、
   請求項１又は２に記載のプロセス監視方法。
4. 前記ステップ（ｂ）において、前記子プロセスは、前記親プロセスからのヘルスチェック要求を受信したことに応じて、複数の前記孫プロセスに対してヘルスチェック要求を送信する、請求項３に記載のプロセス監視方法。
5. 前記親プロセスは、前記子プロセスからの前記正常応答が得られない場合に、前記子プロセス及び前記孫プロセスを強制的に終了させる、
   請求項２乃至４のいずれか１項に記載のプロセス監視方法。
6. 前記親プロセスは、前記子プロセスからの前記正常応答が得られない場合に、前記子プロセスを再生成し、
   再生成された前記子プロセスは、前記孫プロセスを再生成する、
   請求項２乃至４のいずれか１項に記載のプロセス監視方法。
7. 前記ステップ（ａ）において、前記親プロセスは、予め定められた第１のタイムアウト時間内に前記子プロセスから前記正常応答が得られるか否かによって、前記子プロセスの障害発生を検知し、
   前記ステップ（ｂ）において、前記子プロセスは、予め定められた第２のタイムアウト時間内に前記孫プロセスから前記正常応答が得られるか否かによって、前記孫プロセスの障害発生を検知し、
   前記ステップ（ｂ）において、前記子プロセスは、前記孫プロセスからの前記第２のタイムアウト時間の変更要求を受信したことに応じて、前記第１のタイムアウト時間の変更の要否を判定するとともに、変更必要と判定した場合に、前記親プロセスに前記第１のタイムアウト時間の変更要求を送信する、
   請求項１乃至６のいずれか１項に記載のプロセス監視方法。
8. マルチプロセス機能を有する情報処理装置であって、
   ファームウェアを記憶する記憶部と、
   前記ファームウェアに基づいて生成される複数のプロセスを並列的に実行する命令実行部とを備え、
   前記複数のプロセスは、親プロセス、前記親プロセスによって生成される子プロセス、及び前記子プロセスによって生成される孫プロセスを含み、前記親プロセスが前記子プロセスのヘルスチェックを実行し、前記子プロセスが前記孫プロセスのヘルスチェックを実行する、情報処理装置。
9. 前記子プロセスは、監視対象とされた複数の前記孫プロセスのヘルスチェックを行なう、
   請求項８に記載の情報処理装置。
10. 前記子プロセスは、前記親プロセスからのヘルスチェック要求を受信したことに応じて、前記孫プロセスに対してヘルスチェック要求を送信するとともに、前記ヘルスチェック要求に応答して前記孫プロセスから正常応答が受信された場合に、前記親プロセスに対して正常応答を送信する、
    請求項８又は９に記載の情報処理装置。
11. 前記子プロセスは、前記親プロセスからのヘルスチェック要求を受信したことに応じて、複数の前記孫プロセスに対してヘルスチェック要求を送信する、請求項１０に記載の情報処理装置。
12. 前記親プロセスは、前記子プロセスからの前記正常応答が得られない場合に、前記子プロセス及び前記孫プロセスを強制的に終了させる、
    請求項１０又は１１に記載の情報処理装置。
13. 前記親プロセスは、前記子プロセスからの前記正常応答が得られない場合に、前記子プロセスを再生成し、
    再生成された前記子プロセスは、前記孫プロセスを再生成する、
    請求項１０乃至１２のいずれか１項に記載の情報処理装置。
14. 前記親プロセスは、予め定められた第１のタイムアウト時間内に前記子プロセスから前記正常応答が得られるか否かによって、前記子プロセスの障害発生を検知し、
    前記子プロセスは、予め定められた第２のタイムアウト時間内に前記孫プロセスから前記正常応答が得られるか否かによって、前記孫プロセスの障害発生を検知し、
    前記子プロセスは、前記孫プロセスからの前記第２のタイムアウト時間の変更要求を受信したことに応じて、前記第１のタイムアウト時間の変更の要否を判定するとともに、変更必要と判定した場合に、前記親プロセスに前記第１のタイムアウト時間の変更要求を送信する、
    請求項８乃至１３のいずれか１項に記載の情報処理装置。
15. コンピュータにより並列的に実行される複数のプロセスを含むプログラムであって、
    前記複数のプロセスは、親プロセス、前記親プロセスによって生成される子プロセス、及び前記子プロセスによって生成される孫プロセスを含み、
    前記複数のプロセスは、前記親プロセスが前記子プロセスのヘルスチェックを行い、前記子プロセスが前記孫プロセスのヘルスチェックを行う階層化されたプロセス監視を前記コンピュータに実行させることを特徴とする、プログラム。

Images