JP2009223582A - 情報処理装置、情報処理装置の制御方法および制御プログラム - Google Patents
情報処理装置、情報処理装置の制御方法および制御プログラム Download PDFInfo
- Publication number
- JP2009223582A JP2009223582A JP2008066784A JP2008066784A JP2009223582A JP 2009223582 A JP2009223582 A JP 2009223582A JP 2008066784 A JP2008066784 A JP 2008066784A JP 2008066784 A JP2008066784 A JP 2008066784A JP 2009223582 A JP2009223582 A JP 2009223582A
- Authority
- JP
- Japan
- Prior art keywords
- failure
- information
- processing apparatus
- information processing
- storage unit
- 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.)
- Pending
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
- G06F11/0766—Error or fault reporting or storing
- G06F11/0775—Content or structure details of the error report, e.g. specific table structure, specific error fields
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
- G06F11/0706—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment
- G06F11/0748—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment in a remote unit communicating with a single-box computer node experiencing an error/fault
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
- G06F11/0766—Error or fault reporting or storing
- G06F11/0787—Storage of error reports, e.g. persistent data storage, storage using memory protection
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
- G06F11/079—Root cause analysis, i.e. error or fault diagnosis
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/14—Error detection or correction of the data by redundancy in operation
- G06F11/1402—Saving, restoring, recovering or retrying
- G06F11/1415—Saving, restoring, recovering or retrying at system level
- G06F11/1441—Resetting or repowering
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/16—Error detection or correction of the data by redundancy in hardware
- G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
- G06F11/2015—Redundant power supplies
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- General Engineering & Computer Science (AREA)
- Quality & Reliability (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Computer Hardware Design (AREA)
- Debugging And Monitoring (AREA)
Abstract
【課題】不揮発性の記憶部と揮発性の記憶部とを有する情報処理装置において、揮発性の記憶部の障害情報を復元することを課題とする。
【解決手段】情報処理装置は、情報処理装置の電源が遮断された場合においても、情報処理装置に実装されているハードウェア資源において発生した障害要因を保持する第１の記憶部と、当該障害要因とは異なる障害状態を保持し、情報処理装置の電源が遮断された場合に、障害状態が保持されない第２の記憶部とを有し、サービスプロセッサの電源が起動された場合に、ハードウェア資源の構成情報と故障要因とに基づいて故障状態を復元するとともに、第１の記憶部と第２の記憶部との整合性を検査して、不整合が検出された場合に、障害が発生した旨を接続される管理サーバ装置などに通知する。
【選択図】 図２
【解決手段】情報処理装置は、情報処理装置の電源が遮断された場合においても、情報処理装置に実装されているハードウェア資源において発生した障害要因を保持する第１の記憶部と、当該障害要因とは異なる障害状態を保持し、情報処理装置の電源が遮断された場合に、障害状態が保持されない第２の記憶部とを有し、サービスプロセッサの電源が起動された場合に、ハードウェア資源の構成情報と故障要因とに基づいて故障状態を復元するとともに、第１の記憶部と第２の記憶部との整合性を検査して、不整合が検出された場合に、障害が発生した旨を接続される管理サーバ装置などに通知する。
【選択図】 図２
Description
この発明は、複数のハードウェア資源を有するとともに、第１の電源により動作する情報処理装置およびその制御方法ならびに制御プログラムに関する。
従来より、複数のハードウェア資源と、ＣＰＵ（Central Processing Unit）や限られた領域のメモリなどを有して当該ハードウェア資源を管理するサービスプロセッサと、当該サービスプロセッサ上で動作するファームウェアとから構成される情報処理装置が多く利用されている。この情報処理装置は、当該情報処理装置上のハードウェア資源を監視して、当該ハードウェア資源に障害が発生した場合に、障害情報を管理サーバに対して通知する。また、情報処理装置は、サービスプロセッサ上での故障状態を表示する機能と、ハードウェア資源のパーティショニングや部品の活***換メニューなどの管理ツール機能と、ログデータの保存を行なう領域とが搭載されていないために、接続される管理サーバ装置のサーバ管理者によって、ＧＵＩ（Graphical User Interface）またはコマンドラインなどを用いて上記した故障状態や領域などが管理されている（非特許文献１〜３参照）。
ここで、上記した情報処理装置において、特に、ハードウェア資源の障害情報を管理サーバに通知する際の処理を、図１９を用いて説明する。図１９に示すように、情報処理装置は、当該情報処理装置を管理する管理サーバに接続されており、ハードウェア資源と、当該ハードウェア資源の故障状態を監視するサービスプロセッサと、故障が発生したハードウェア資源の故障要因が格納される不揮発性のハードウェアであるＤＢ１と、故障が発生したハードウェア資源の故障状態が格納される揮発性のハードウェアであるＤＢ２と、故障情報復元および通知のための処理を行なう解析プログラム／ハード監視ソフトと、ｅｖｅｎｔ配信ソフトと、エラー管理ソフトと、通報ソフトとを有する。ここで用いられる不揮発性のハードウェアであるＤＢ１は、ＮＶＲＡＭやＨＤＤなどのハードウェアにより構成され、情報処理装置本体の電源が切断された場合でも故障情報を保持する。また、揮発性のハードウェアであるＤＢ２は、ＤＲＡＭやＳＲＡＭなどのハードウェアにより構成され、ＤＢ１とは異なり、情報処理装置本体の電源が切断された場合に故障情報を消失して、情報処理装置本体が再起動された場合に故障情報を保持する。
なお、ＤＢ１とＤＢ２との２つのＤＢから構成される理由は、より多くの記憶領域を必要とするＤＢ１にｂｉｔ単価が安い不揮発性記憶装置を利用し、当該ＤＢ１よりも少ない記憶領域を必要とするＤＢ２にｂｉｔ単価が高い揮発性記憶装置を利用して、サービスプロセッサのハードウェアにかかるコストを削減するためである。
具体的に説明すると、情報処理装置は、サービスプロセッサにより監視が行なわれており（図１９の（１）参照）、当該サービスプロセッサを構成する機能が全て利用可能な状態にある。このような状態において、解析プログラム／ハード監視ソフトは、ハードウェア資源において故障が発生すると、割り込みまたはポーリング監視（ｐｏｌｌｉｎｇ）によって故障情報の通知を受け付けて（図１９の（２）参照）、故障が発生したハードウェア資源の物理位置と故障要因とをＤＢ１に格納し（図１９の（３）参照）、故障通知イベントの送信依頼をｅｖｅｎｔ配信ソフトに対して行なう（図１９の（４）参照）。
この解析プログラム／ハード監視ソフトがｅｖｅｎｔ配信ソフトに対して渡す情報は、図２０に示すように、１２８ｂｙｔｅ固定のバイナリデータとなっており、発生時刻、検出元、故障コンポーネント名および故障要因文字列のフォーマットから構成される。また、各フォーマットの内容および故障コンポーネント名は、図２１に示すような内容となる。なお、図２０は、従来技術に係るハード監視ソフトがｅｖｅｎｔ配信ソフトに渡す情報の例を示す図であり、図２１は、従来技術に係るハード監視ソフトがｅｖｅｎｔ配信ソフトに渡す情報の内容を示す図である。
そして、解析プログラム／ハード監視ソフトにより故障通知イベントの送信依頼を受け付けたｅｖｅｎｔ配信ソフトは、当該故障通知イベントをエラー管理ソフトに対して通知する（図１９の（５）参照）。このｅｖｅｎｔ配信ソフトがエラー管理ソフトに対して渡す情報は、図２２に示すように、１２８ｂｙｔｅ固定のバイナリデータとなっており、発生時刻、検出元、故障コンポーネント名および故障要因文字列のフォーマットから構成される。また、各フォーマットの内容および故障コンポーネント名の内容は、図２３に示すような内容となる。なお、図２２は、従来技術に係るｅｖｅｎｔ配信ソフトがエラー管理ソフトに渡す情報の例を示す図であり、図２３は、従来技術に係るｅｖｅｎｔ配信ソフトがエラー管理ソフトに渡す情報の内容を示す図である。
続いて、エラー管理ソフトは、ｅｖｅｎｔ配信ソフトから故障通知イベントを受け付けると、故障要因が格納されているＤＢ１を参照して、当該故障要因からハードウェア資源の故障状態を導出する（図１９の（６）参照）。その後、エラー管理ソフトは、ＤＢ１の故障要因から導出されたハードウェア資源の故障状態をＤＢ２に格納し（図１９の（７）参照）、通報ソフトに対して故障情報を通知する（図１９の（８）参照）。このエラー管理ソフトが通報ソフトに対して渡す情報は、図２４に示すように、１２８ｂｙｔｅ固定のバイナリデータとなっており、発生時刻、検出元、故障コンポーネント名および故障要因文字列から構成される。また、各フォーマットの内容および故障コンポーネント名の内容は、図２５に示すような内容となる。なお、図２４は、従来技術に係るエラー管理ソフトが通報ソフトに渡す情報の例を示す図であり、図２５は、従来技術に係るエラー管理ソフトが通報ソフトに渡す情報の内容を示す図である。
そして、通報ソフトは、情報処理装置を管理する管理サーバに対して故障情報を通知する（図１９の（９）参照）。その後、システム管理者は、情報処理装置により通知された故障情報を管理サーバにおいて確認し、当該情報処理装置の設定や状態などを把握して保守作業を行なう。なお、図１９は、従来技術に係る情報処理装置による故障情報通知処理を説明するための図である。
また、最近では、ＣＰＵの処理速度向上や記憶装置の低価格化などによって、管理サーバを必要としないサービスプロセッサが搭載された情報処理装置が提供されつつある。この情報処理装置は、上記した管理サーバの機能を情報処理装置に搭載するために、ソフトウェアの数および当該ソフトウェアを動作させるためのハードウェアの数が増加するとともに、マルチタスクなどの機能を備えたＯＳ（Operating System）が必要となる。
"システム監視機構（ＳＣＦ：System Control Facility）"、［online］、［平成１９年１２月１９日検索］、インターネット＜http://primeserver.fujitsu.com/primepower/technology/reliance/monitor/＞
"ハイエンドサーバ管理コンソール（ＳＭＣ：System Management Console）"、［online］、［平成１９年１２月１９日検索］、インターネット＜http://primeserver.fujitsu.com/primepower/products/lineup/pp2500/point.html＞
"Sun Enterprise 10000 SSP 3.5 User Guide"、［online］、［平成１９年１２月１９日検索］、インターネット＜http://dlc.sun.com/pdf/816-3624-10/816-3624-10.pdf＞
しかしながら、上記した従来の技術は、不揮発性の記憶部と揮発性の記憶部とを有する情報処理装置において、揮発性の記憶部の障害情報を復元することができないという課題があった。
具体的に、非特許文献１〜３における情報処理装置は、故障要因が格納されるＤＢ１から故障状態が格納されるＤＢ２に障害情報を復元するまでに、サービスプロセッサ上のソフトウェアまたはハードウェア要因による障害が発生した場合に、サービスプロセッサがハングアップまたは再起動するので、障害情報の復元処理が中断されてしまい、不揮発性の記憶部の障害情報に基づいて、揮発性の記憶部の障害情報を復元することができない。
また、管理サーバを必要としないサービスプロセッサが搭載された情報処理装置は、複数の機能追加により、サービスプロセッサが障害情報を検出してから通報ソフトに障害情報を通知するまでに、複数のソフトウェアコンポーネントや記憶領域などを通過するので、故障情報を喪失してしまう危険性が高くなる。また、情報処理装置は、ＯＳの高度化による並列タスクの増加により故障情報を喪失してしまう危険性が高くなる。この結果、不揮発性の記憶部の障害情報に基づいて、揮発性の記憶部の障害情報を復元することができない。なお、故障情報の喪失を防止するための解決方法としては、サービスプロセッサを複数搭載することで一定の効果が得られるが、当該複数のサービスプロセッサを搭載するためのコストがかかってしまい、さらに、複数のサービスプロセッサを搭載し、ソフトバグによって障害情報復元処理が中断された場合には、障害情報喪失を防止するための根本的な解決とはならない。
そこで、この発明は、上述した従来技術の課題を解決するためになされたものであり、不揮発性の記憶部と揮発性の記憶部とを有する情報処理装置において、揮発性の記憶部の障害情報を復元することが可能である情報処理装置を提供することを目的とする。
上述した課題を解決し、目的を達成するため、本願の開示する情報処理装置は、複数のハードウェア資源を有するとともに、第１の電源により動作する情報処理装置において、前記第１の電源が遮断された場合においても、前記ハードウェア資源において発生した障害に関する第１の障害情報を保持する第１の記憶部と、前記第１の障害情報とは異なる第２の障害情報を保持するとともに、前記第１の電源が遮断された場合に、前記第２の障害情報が保持されない第２の記憶部と、前記情報処理装置に実装されている前記複数のハードウェア資源の構成情報を取得するハードウェア監視部と、前記構成情報と前記第１の記憶部に格納された第１の障害情報に基づいて、前記第２の記憶部に保持する第２の障害情報を復元する障害情報管理部として機能するシステム制御装置を有することを要件とする。
本願の開示する情報処理装置によれば、不揮発性の記憶部と揮発性の記憶部とを有する情報処理装置において、揮発性の記憶部の障害情報を復元することが可能であるという効果を奏する。
以下に添付図面を参照して、この発明に係る情報処理装置の実施例を詳細に説明する。なお、以下では、本発明に係る情報処理装置の概要および特徴、情報処理装置の構成および処理の流れを順に説明し、最後に本実施例による効果を説明する。
［概要および特徴］
最初に、図１を用いて、実施例１に係る情報処理装置の概要および特徴を説明する。図１は、実施例１に係る情報処理装置の概要および特徴を示す図である。
最初に、図１を用いて、実施例１に係る情報処理装置の概要および特徴を説明する。図１は、実施例１に係る情報処理装置の概要および特徴を示す図である。
この情報処理装置は、当該情報処理装置を管理する管理サーバと接続されており、情報処理装置本体の運用や異常監視などを行なうサービスプロセッサと、ＳｙｓｔｅｍＢｏａｒｄ、Ｉ／ＯＢｏａｒｄ、ＣＰＵＭｏｄｕｌｅなどから構成されるハードウェア資源とを有する。また、サービスプロセッサは、ＤＢ１およびＤＢ２を用いて障害情報の復元や通知などの処理を行なう解析プログラム、エラー管理ソフト、ハード監視ソフト、ｅｖｅｎｔ配信ソフトおよび通報ソフトから構成される。
このような構成において、情報処理装置は、複数のハードウェア資源を有するとともに、第１の電源により動作することを概要とするものであり、特に、不揮発性の記憶部と揮発性の記憶部とを有する情報処理装置において、揮発性の記憶部の障害情報を復元することが可能である点を主たる特徴とする。
この主たる特徴について具体的に説明すると、情報処理装置は、第１の電源が遮断された場合においても、ハードウェア資源において発生した障害に関する第１の障害情報を保持する第１の記憶部としてのＤＢ１と、第１の障害情報とは異なる第２の障害情報を保持するとともに、第１の電源が遮断された場合に、第２の障害情報が保持されない第２の記憶部としてのＤＢ２とを有する。
例えば、情報処理装置は、故障が発生したハードウェア資源の故障要因が格納される不揮発性のハードウェアであり、情報処理装置本体の電源が切断された場合でも故障情報を保持するＤＢ１を有する。また、例えば、情報処理装置は、ＤＢ１の情報に基づいて故障が発生したハードウェア資源の故障状態が格納される揮発性のハードウェアであり、ＤＢ１とは異なり、情報処理装置本体の電源が切断された場合に故障情報を消失し、情報処理装置本体が再起動された場合に故障情報を保持するＤＢ２を有する。
このような状態において、情報処理装置は、当該情報処理装置に実装されている複数のハードウェア資源の構成情報を取得し、取得された構成情報と第１の記憶部に格納された第１の障害情報に基づいて、第２の記憶部に保持する第２の障害情報を復元する。
具体的に例を挙げると、情報処理装置は、当該情報処理装置に実装されているＳｙｓｔｅｍＢｏａｒｄ、Ｉ／ＯＢｏａｒｄまたはＣＰＵＭｏｄｕｌｅなどの複数のハードウェア資源の構成情報を取得する。そして、情報処理装置は、例えば、情報処理装置の電源が投入された場合に、取得された構成情報と、当該構成情報に対応し、ＤＢ１に保持されるハードウェア資源の物理位置や故障要因などの障害情報とに基づいて、ＤＢ２に保持されるハードウェア資源の物理位置や故障状態などの障害情報を復元する。
このようなことから、実施例１に係る複数のハードウェア資源を有するとともに、第１の電源により動作する情報処理装置は、情報処理装置に実装されている複数のハードウェア資源の構成情報を取得し、取得された構成情報とＤＢ１に格納された障害情報とに基づいて、ＤＢ２に保持する障害情報を復元することができる結果、不揮発性の記憶部と揮発性の記憶部とを有する情報処理装置において、揮発性の記憶部の障害情報を復元することが可能である。
つまり、情報処理装置は、サービスプロセッサの起動時においても、故障状態を退避するための領域を必要とせず、少ない資源で故障状態を復元することができる結果、不揮発性の記憶部と揮発性の記憶部とを有する情報処理装置において、揮発性の記憶部の障害情報を復元することが可能である。
［実施例１に係る情報処理装置の構成］
次に、図２を用いて、実施例１に係る情報処理装置の構成を説明する。図２は、実施例１に係る情報処理装置の構成を示す図である。
次に、図２を用いて、実施例１に係る情報処理装置の構成を説明する。図２は、実施例１に係る情報処理装置の構成を示す図である。
図２に示すように、情報処理装置１０は、ハードウェア資源１１と、サービスプロセッサ２０とから構成され、当該情報処理装置１０や複数のサーバ装置などの状態を維持および管理する管理サーバ１と接続されており、当該情報処理装置１０の常駐電源が投入された場合に起動する。
ハードウェア資源１１は、情報処理装置１０の主機能を担う部品が搭載されたＳｙｓｔｅｍＢｏａｒｄ、情報処理装置１０と当該情報処理装置１０に接続される装置との入出力ポートの役割を担うＩ／ＯＢｏａｒｄ、および、プログラムの実行や演算処理などを行なうＣＰＵＭｏｄｕｌｅなどの複数のハードウェア資源から構成される。
サービスプロセッサ２０は、ＤＢ１、ＤＢ２、メモリ２１ｃ、ハード監視ソフト２２ａ、エラー管理ソフト２２ｂ、ｅｖｅｎｔ配信ソフト２２ｃ、解析プログラム２２ｄおよび通報ソフト２２ｅから構成され、情報処理装置１０の運用や異常監視などを行なう。また、サービスプロセッサ２０は、情報処理装置１０の常駐電源が投入された場合に起動する。そして、サービスプロセッサ２０は、情報処理装置１０の常駐電源とは異なる電源を有しており、当該サービスプロセッサ２０に異常が発生した場合に自動的に再起動する。
ＤＢ１は、第１の電源が遮断された場合においても、ハードウェア資源において発生した障害に関する第１の障害情報を保持する。そして、ＤＢ１に保持される第１の障害情報は、障害が発生したハードウェア資源を識別する識別情報と、障害が発生したハードウェア資源における障害要因を有する。
例えば、ＤＢ１は、情報処理装置の電源が遮断された場合においても、ハードウェア資源１１において発生した障害に関する障害情報を保持する。そして、ＤＢ１に保持される障害情報は、図３に示すように、障害が発生したハードウェア資源１１「ＣＰＵＭｏｄｕｌｅ」を識別する識別情報と、障害が発生したハードウェア資源１１「ＣＰＵＭｏｄｕｌｅ」における障害要因「ＣＯＲＥ＃０ ｅｒｒｏｒ」とを有する。なお、図３は、実施例１に係るＤＢ１に保持されるＣＰＵＭｏｄｕｌｅの障害情報のデータフォーマット例である。
また、例えば、ＤＢ１に保持される障害情報は、図４に示すように、障害が発生したハードウェア資源「ＳｙｓｔｅｍＢｏａｒｄ」を識別する識別情報と、障害が発生したハードウェア資源「ＳｙｓｔｅｍＢｏａｒｄ」における障害要因「ＳＣ＃０ ｅｒｒｏｒ」とを有する。また、図４に示したＳＣ（System Controller）は、ＳｙｓｔｅｍＢｏａｒｄ上に１個以上搭載され、ＣＰＵ、メモリ、Ｉ／Ｏなどを接続する役割を担う。また、図４に示したＭＣ（Memory Controller）は、ＳｙｓｔｅｍＢｏａｒｄ上に１個以上搭載され、ＤＩＭＭを制御する役割を担う。また、ＩＯＢＣ（I／O Board Controller）は、ＰＣＩバスとＳＣとを接続する役割を担う。なお、図４は、実施例１に係るＤＢ１に保持されるＳｙｓｔｅｍＢｏａｒｄの障害情報のデータフォーマット例である。
また、例えば、ＤＢ１に保持される障害情報は、図５に示すように、障害が発生したハードウェア資源「Ｉ／ＯＢｏａｒｄ」を識別する識別情報と、障害が発生したハードウェア資源「Ｉ／ＯＢｏａｒｄ」における障害要因「ＩＯＢＣ＃０ ｅｒｒｏｒ」とを有する。なお、図５は、実施例１に係るＤＢ１に保持されるＩ／ＯＢｏａｒｄの障害情報のデータフォーマット例である。
ＤＢ２は、第１の障害情報とは異なる第２の障害情報を保持するとともに、第１の電源が遮断された場合に、第２の障害情報が保持されない。そして、ＤＢ２に保持される障害情報は、障害が発生したハードウェア資源を識別する識別情報と、障害が発生したハードウェア資源における障害の程度に関する情報を有する。
例えば、ＤＢ２は、ＤＢ１に保持される障害情報とは異なる障害情報を保持するとともに、情報処理装置の電源が遮断された場合に、当該障害情報が保持されない。このＤＢ２に保持される障害情報は、図６に示すように、障害が発生したハードウェア資源１１「ＣＰＵＭｏｄｕｌｅ」を識別する識別情報と、障害が発生したハードウェア資源１１「ＣＰＵＭｏｄｕｌｅ」における障害の程度に関する情報「Ａｌａｒｍ」とを有する。なお、図６は、実施例１に係るＤＢ２に保持されるＣＰＵＭｏｄｕｌｅの障害情報のデータフォーマット例である。
メモリ２１ｃは、ハードウェア資源１１の実装情報を保持している。例えば、メモリ２１ｃは、ハードウェア資源１１である情報処理装置１０の主機能を担う部品が搭載された「ＳｙｓｔｅｍＢｏａｒｄ」、情報処理装置１０と当該情報処理装置１０に接続される装置との入出力ポートの役割を担う「Ｉ／ＯＢｏａｒｄ」、プログラムの実行や演算処理などを行なう「ＣＰＵＭｏｄｕｌｅ」などの実装情報を保持している。
ハード監視ソフト２２ａは、情報処理装置１０に実装されている複数のハードウェア資源１１の構成情報を取得する。具体的に例を挙げると、ハード監視ソフト２２ａは、情報処理装置１０の電源が投入された場合、または、サービスプロセッサ２０が再起動された場合に、情報処理装置１０に実装されている複数のハードウェア資源１１「ＳｙｓｔｅｍＢｏａｒｄ」、「Ｉ／ＯＢｏａｒｄ」、「ＣＰＵＭｏｄｕｌｅ」などの実装情報をメモリ２１ｃから取得する。また、ハード監視ソフト２２ａは、情報処理装置１０の電源やファンなどのハードウェアの故障を解析して、当該電源やファンなどの故障位置と故障要因とを特定し、ＤＢ１に格納する。また、ハード監視ソフト２２ａは、エラー管理ソフト２２ｂのライブラリを呼び出して、実装されているハードウェア資源１１の単位でＤＢ２に保持される障害情報の復元を依頼する。
エラー管理ソフト２２ｂは、構成情報とＤＢ１に保持された障害情報に基づいて、ＤＢ２に保持する障害情報を復元する。また、エラー管理ソフト２２ｂは、ＤＢ１に保持された障害情報とＤＢ２に保持された障害情報間の整合性を検査する。
上記した例で具体的に例を挙げると、エラー管理ソフト２２ｂは、ハード監視ソフト２２ａによりＤＢ２に保持される障害情報の復元を依頼されると、ＤＢ１に保持されたハードウェア資源１１の故障情報に対応したＤＢ２の領域を参照して、故障状態の有無を検査する。そして、エラー管理ソフト２２ｂは、ＤＢ１を参照して、現状の故障要因を取得する。
ここで、エラー管理ソフト２２ｂにより行なわれる故障要因の検査は、ＤＢ１（図３参照）の領域にｂｉｔが立っているか否かを参照する。例えば、ＣＰＵＭｏｄｕｌｅにおいて、Ｌ２ｃａｃｈｅのＷＡＹ＃０故障が発生した場合には、図７に示すように、ＤＢ１のｂｉｔ１９領域に「１」が立っている。また、例えば、ＣＰＵＭｏｄｕｌｅにおいて、Ｌ２ｃａｃｈｅのＷＡＹ＃０故障およびＬ２ｃａｃｈｅのＷＡＹ＃１故障が発生した場合には、図８に示すように、ＤＢ１のｂｉｔ１８領域およびｂｉｔ１９領域に「１」が立っている。なお、図７は、実施例１に係るＣＰＵＭｏｄｕｌｅにおいて、Ｌ２ｃａｃｈｅのＷＡＹ＃０故障が発生した場合のＤＢ１の例を示す図であり、図８は、実施例１に係るＣＰＵＭｏｄｕｌｅにおいて、Ｌ２ｃａｃｈｅのＷＡＹ＃０故障およびＬ２ｃａｃｈｅのＷＡＹ＃１故障が発生した場合のＤＢ１の例を示す図である。
続いて、エラー管理ソフト２２ｂは、ＤＢ２を参照して、現状の故障状態を取得する。ここで、エラー管理ソフト２２ｂにより行なわれる故障状態の取得は、ＤＢ１（図３参照）の領域を参照して故障状態を取得する。例えば、エラー管理ソフト２２ｂは、ＣＰＵＭｏｄｕｌｅにおいて、Ｌ２ｃａｃｈｅの一部が故障した場合に（図７参照）、図９に示すように、ＤＢ１のｂｉｔ６領域に「１」が立っているので、当該ｂｉｔ６領域に保持される故障状態である「Ｗａｒｎｉｎｇ」を取得する。なお、図９は、実施例１に係るＣＰＵＭｏｄｕｌｅにおいて、Ｌ２ｃａｃｈｅの一部が故障した場合のＤＢ２の例を示す図である。
その後、エラー管理ソフト２２ｂは、取得された故障要因と故障状態とを用いて、図１０に示すように、ＤＢ１とＤＢ２との整合性検査を行なう。そして、エラー管理ソフト２２ｂは、整合性検査によりＤＢ１とＤＢ２とが不整合であると判定された場合に、ＤＢ１の障害情報に基づいてＤＢ２の障害情報を復元する。
ここで、ＤＢ１とＤＢ２との整合性検査内容（図１０に示した項番１〜項番１２）を説明する。図１０は、実施例１に係るＤＢ１とＤＢ２との整合性検査内容を説明するための図である。また、揮発性であるＤＢ２の故障状態は、情報処理装置１０の電源が投入されてサービスプロセッサ２０が起動された場合に、全て「０」に初期化される。また、故障状態は、より重大度が高い状態としてレベルの高い方から、「Ａｌａｒｍ（完全故障）」、「Ｗａｒｎｉｎｇ（部分故障）」、「Ｎｏｒｍａｌ（正常）」とする。また、以下の整合性検査内容の説明においては、ハードウェアＣＰＵ＃０の場合を例に挙げて説明する。なお、故障状態の判定ロジックは、エラー管理ソフト２２ｂにおいてハードコーディングされている。
（項番１）
項番１では、サービスプロセッサ２０の起動契機が情報処理装置１０の電源投入によるものであり、ＤＢ１の故障要因がない状態である。このような状態において、エラー管理ソフト２２ｂは、サービスプロセッサ２０が起動されると、ＤＢ１のｂｉｔ領域から故障要因を取得する。そして、エラー管理ソフト２２ｂは、取得された故障要因が存在しないために、ＤＢ２に書き込む（復元する）故障状態を「Ｎｏｒｍａｌ」と仮判定する。続いて、エラー管理ソフト２２ｂは、ＤＢ２からＣＰＵ＃０の故障状態「Ｎｏｒｍａｌ」を取得し、取得された故障状態「Ｎｏｒｍａｌ」と仮判定された故障状態「Ｎｏｒｍａｌ」とを比較する。
項番１では、サービスプロセッサ２０の起動契機が情報処理装置１０の電源投入によるものであり、ＤＢ１の故障要因がない状態である。このような状態において、エラー管理ソフト２２ｂは、サービスプロセッサ２０が起動されると、ＤＢ１のｂｉｔ領域から故障要因を取得する。そして、エラー管理ソフト２２ｂは、取得された故障要因が存在しないために、ＤＢ２に書き込む（復元する）故障状態を「Ｎｏｒｍａｌ」と仮判定する。続いて、エラー管理ソフト２２ｂは、ＤＢ２からＣＰＵ＃０の故障状態「Ｎｏｒｍａｌ」を取得し、取得された故障状態「Ｎｏｒｍａｌ」と仮判定された故障状態「Ｎｏｒｍａｌ」とを比較する。
その後、エラー管理ソフト２２ｂは、故障状態の比較の結果、ＤＢ１とＤＢ２との故障状態に差分がないので、仮判定された故障状態「Ｎｏｒｍａｌ」をＤＢ２に書き込む（復元する）ことなく処理を終了する。
（項番２）
項番２では、サービスプロセッサ２０の起動契機が再起動によるものであり、ＤＢ１の故障要因がない状態である。このような状態において、エラー管理ソフト２２ｂは、サービスプロセッサ２０が再起動されると、ＤＢ１のｂｉｔ領域から故障要因を取得する。そして、エラー管理ソフト２２ｂは、取得された故障要因が存在しないために、ＤＢ２に書き込む（復元する）故障状態を「Ｎｏｒｍａｌ」と仮判定する。続いて、エラー管理ソフト２２ｂは、ＤＢ２からＣＰＵ＃０の故障状態「Ｎｏｒｍａｌ」を取得し、取得された故障状態「Ｎｏｒｍａｌ」と仮判定された故障状態「Ｎｏｒｍａｌ」とを比較する。
項番２では、サービスプロセッサ２０の起動契機が再起動によるものであり、ＤＢ１の故障要因がない状態である。このような状態において、エラー管理ソフト２２ｂは、サービスプロセッサ２０が再起動されると、ＤＢ１のｂｉｔ領域から故障要因を取得する。そして、エラー管理ソフト２２ｂは、取得された故障要因が存在しないために、ＤＢ２に書き込む（復元する）故障状態を「Ｎｏｒｍａｌ」と仮判定する。続いて、エラー管理ソフト２２ｂは、ＤＢ２からＣＰＵ＃０の故障状態「Ｎｏｒｍａｌ」を取得し、取得された故障状態「Ｎｏｒｍａｌ」と仮判定された故障状態「Ｎｏｒｍａｌ」とを比較する。
その後、エラー管理ソフト２２ｂは、故障状態の比較の結果、ＤＢ１とＤＢ２との故障状態に差分がないので、仮判定された故障状態「Ｎｏｒｍａｌ」をＤＢ２に書き込む（復元する）ことなく処理を終了する。
（項番３）
項番３では、サービスプロセッサ２０の起動契機が再起動によるものであり、ＤＢ１の故障要因がない状態である。このような状態において、エラー管理ソフト２２ｂは、サービスプロセッサ２０が再起動されると、ＤＢ１のｂｉｔ領域から故障要因を取得する。そして、エラー管理ソフト２２ｂは、取得された故障要因が存在しないために、ＤＢ２に書き込む（復元する）故障状態を「Ｎｏｒｍａｌ」と仮判定する。続いて、エラー管理ソフト２２ｂは、ＤＢ２からＣＰＵ＃０の故障状態「Ｗａｒｎｉｎｇ」を取得し、取得された故障状態「Ｗａｒｎｉｎｇ」と仮判定された故障状態「Ｎｏｒｍａｌ」とを比較する。
項番３では、サービスプロセッサ２０の起動契機が再起動によるものであり、ＤＢ１の故障要因がない状態である。このような状態において、エラー管理ソフト２２ｂは、サービスプロセッサ２０が再起動されると、ＤＢ１のｂｉｔ領域から故障要因を取得する。そして、エラー管理ソフト２２ｂは、取得された故障要因が存在しないために、ＤＢ２に書き込む（復元する）故障状態を「Ｎｏｒｍａｌ」と仮判定する。続いて、エラー管理ソフト２２ｂは、ＤＢ２からＣＰＵ＃０の故障状態「Ｗａｒｎｉｎｇ」を取得し、取得された故障状態「Ｗａｒｎｉｎｇ」と仮判定された故障状態「Ｎｏｒｍａｌ」とを比較する。
その後、エラー管理ソフト２２ｂは、故障状態の比較の結果、ＤＢ１とＤＢ２との故障状態に差分があるが、ＤＢ１から仮判定された故障状態「Ｎｏｒｍａｌ」とＤＢ２から取得された故障状態「Ｗａｒｎｉｎｇ」とのうち、より重大度が高い状態をハードウェアＣＰＵ＃０の状態とするので、仮判定された故障状態「Ｎｏｒｍａｌ」をＤＢ２に書き込む（復元する）ことなく処理を終了する。つまり、ＤＢ１の故障状態を示すＤＢ２の内容は、再起動前の故障状態である「Ｗａｒｎｉｎｇ」が保持される。
（項番４）
項番４では、サービスプロセッサ２０の起動契機が再起動によるものであり、ＤＢ１の故障要因がない状態である。このような状態において、エラー管理ソフト２２ｂは、サービスプロセッサ２０が再起動されると、ＤＢ１のｂｉｔ領域から故障要因を取得する。そして、エラー管理ソフト２２ｂは、取得された故障要因が存在しないために、ＤＢ２に書き込む（復元する）故障状態を「Ｎｏｒｍａｌ」と仮判定する。続いて、エラー管理ソフト２２ｂは、ＤＢ２からＣＰＵ＃０の故障状態「Ａｌａｒｍ」を取得し、取得された故障状態「Ａｌａｒｍ」と仮判定された故障状態「Ｎｏｒｍａｌ」とを比較する。
項番４では、サービスプロセッサ２０の起動契機が再起動によるものであり、ＤＢ１の故障要因がない状態である。このような状態において、エラー管理ソフト２２ｂは、サービスプロセッサ２０が再起動されると、ＤＢ１のｂｉｔ領域から故障要因を取得する。そして、エラー管理ソフト２２ｂは、取得された故障要因が存在しないために、ＤＢ２に書き込む（復元する）故障状態を「Ｎｏｒｍａｌ」と仮判定する。続いて、エラー管理ソフト２２ｂは、ＤＢ２からＣＰＵ＃０の故障状態「Ａｌａｒｍ」を取得し、取得された故障状態「Ａｌａｒｍ」と仮判定された故障状態「Ｎｏｒｍａｌ」とを比較する。
その後、エラー管理ソフト２２ｂは、故障状態の比較の結果、ＤＢ１とＤＢ２との故障状態に差分があるが、ＤＢ１から仮判定された故障状態「Ｎｏｒｍａｌ」とＤＢ２から取得された故障状態「Ａｌａｒｍ」とのうち、より重大度が高い状態をハードウェアＣＰＵ＃０の状態とするので、仮判定された故障状態「Ｎｏｒｍａｌ」をＤＢ２に書き込む（復元する）ことなく処理を終了する。つまり、ＤＢ１の故障状態を示すＤＢ２の内容は、再起動前の故障状態である「Ａｌａｒｍ」が保持される。
（項番５）
項番５では、サービスプロセッサ２０の起動契機が情報処理装置１０の電源投入によるものであり、ＤＢ１の故障要因が部分故障を示す「Ｗａｒｉｎｇ要因」となる状態である。このような状態において、エラー管理ソフト２２ｂは、サービスプロセッサ２０が起動されると、ＤＢ１のｂｉｔ領域から故障要因を取得する。そして、エラー管理ソフト２２ｂは、取得された故障要因として、ＣＰＵ＃０領域「ＣＯＲＥ＃１ ＴＬＢ Ｂｕｆｆｅｒ ｅｒｒｏｒ（ｂｉｔ２８）」に「１」が立っている場合に、ＤＢ２に書き込む（復元する）故障状態を「Ｗａｒｎｉｎｇ」と仮判定する。続いて、エラー管理ソフト２２ｂは、ＤＢ２からＣＰＵ＃０の故障状態「Ｎｏｒｍａｌ」を取得し、取得された故障状態「Ｎｏｒｍａｌ」と仮判定された故障状態「Ｗａｒｎｉｎｇ」とを比較する。
項番５では、サービスプロセッサ２０の起動契機が情報処理装置１０の電源投入によるものであり、ＤＢ１の故障要因が部分故障を示す「Ｗａｒｉｎｇ要因」となる状態である。このような状態において、エラー管理ソフト２２ｂは、サービスプロセッサ２０が起動されると、ＤＢ１のｂｉｔ領域から故障要因を取得する。そして、エラー管理ソフト２２ｂは、取得された故障要因として、ＣＰＵ＃０領域「ＣＯＲＥ＃１ ＴＬＢ Ｂｕｆｆｅｒ ｅｒｒｏｒ（ｂｉｔ２８）」に「１」が立っている場合に、ＤＢ２に書き込む（復元する）故障状態を「Ｗａｒｎｉｎｇ」と仮判定する。続いて、エラー管理ソフト２２ｂは、ＤＢ２からＣＰＵ＃０の故障状態「Ｎｏｒｍａｌ」を取得し、取得された故障状態「Ｎｏｒｍａｌ」と仮判定された故障状態「Ｗａｒｎｉｎｇ」とを比較する。
その後、エラー管理ソフト２２ｂは、故障状態の比較の結果、ＤＢ１とＤＢ２との故障状態に差分があり、さらに、ＤＢ１から仮判定された故障状態「Ｗａｒｎｉｎｇ」の方が重大度が高い状態であるので、仮判定された故障状態「Ｗａｒｎｉｎｇ」をＤＢ２に書き込んで（復元して）処理を終了する。つまり、ＤＢ１の故障状態を示すＤＢ２の内容は、ＤＢ１の故障要因に基づいて復元された故障状態である「Ｗａｒｎｉｎｇ」が保持される。
ここで、エラー管理ソフト２２ｂは、サービスプロセッサ２０の起動によってＤＢ２が全て「０」に初期化されているために、イベントのロストによる不整合であるか、または、ＤＢ２の初期化による不整合であるかを判定することができない。しかしながら、エラー管理ソフト２２ｂは、イベントのロストによる不整合ではなく、ＤＢ２の初期化による不整合であることを優先するとともに、後述するｅｖｅｎｔ配信ソフト２２ｃや通報ソフト２２ｅなどへの通知がサービスプロセッサ２０の起動前に行なわれていることとして判定する結果、ｅｖｅｎｔ配信ソフト２２ｃに不整合検出イベントを通知することはない。
（項番６）
項番６では、サービスプロセッサ２０の起動契機が再起動によるものであり、ＤＢ１の故障要因が部分故障を示す「Ｗａｒｎｉｎｇ要因」となる状態である。このような状態において、エラー管理ソフト２２ｂは、サービスプロセッサ２０が再起動されると、ＤＢ１のｂｉｔ領域から故障要因を取得する。そして、エラー管理ソフト２２ｂは、取得された故障要因として、ＣＰＵ＃０領域「ＣＯＲＥ＃１ ＴＬＢ Ｂｕｆｆｅｒ ｅｒｒｏｒ（ｂｉｔ２８）」に「１」が立っている場合に、ＤＢ２に書き込む（復元する）故障状態を「Ｗａｒｎｉｎｇ」と仮判定する。続いて、エラー管理ソフト２２ｂは、ＤＢ２からＣＰＵ＃０の故障状態「Ｎｏｒｍａｌ」を取得し、取得された故障状態「Ｎｏｒｍａｌ」と仮判定された故障状態「Ｗａｒｎｉｎｇ」とを比較する。
項番６では、サービスプロセッサ２０の起動契機が再起動によるものであり、ＤＢ１の故障要因が部分故障を示す「Ｗａｒｎｉｎｇ要因」となる状態である。このような状態において、エラー管理ソフト２２ｂは、サービスプロセッサ２０が再起動されると、ＤＢ１のｂｉｔ領域から故障要因を取得する。そして、エラー管理ソフト２２ｂは、取得された故障要因として、ＣＰＵ＃０領域「ＣＯＲＥ＃１ ＴＬＢ Ｂｕｆｆｅｒ ｅｒｒｏｒ（ｂｉｔ２８）」に「１」が立っている場合に、ＤＢ２に書き込む（復元する）故障状態を「Ｗａｒｎｉｎｇ」と仮判定する。続いて、エラー管理ソフト２２ｂは、ＤＢ２からＣＰＵ＃０の故障状態「Ｎｏｒｍａｌ」を取得し、取得された故障状態「Ｎｏｒｍａｌ」と仮判定された故障状態「Ｗａｒｎｉｎｇ」とを比較する。
その後、エラー管理ソフト２２ｂは、故障状態の比較の結果、ＤＢ１とＤＢ２との故障状態に差分があり、さらに、ＤＢ１から仮判定された故障状態「Ｗａｒｎｉｎｇ」の方が重大度が高い状態であるので、仮判定された故障状態「Ｗａｒｎｉｎｇ」をＤＢ２に書き込む（復元する）。つまり、ＤＢ１の故障状態を示すＤＢ２の内容は、ＤＢ１の故障要因に基づいて復元された故障状態である「Ｗａｒｎｉｎｇ」が保持される。
そして、エラー管理ソフト２２ｂは、イベントが途中でロストした可能性があると判定して、後述するｅｖｅｎｔ配信ソフト２２ｃに対して不整合検出イベントを通知する。つまり、エラー管理ソフト２２ｂは、サービスプロセッサ２０の再起動によりＤＢ２の故障状態が再起動前の故障状態であるはずにもかかわらず、ＤＢ１とＤＢ２とで不整合が発生しているので、イベントが途中でロストした可能性があると判定する。
このエラー管理ソフト２２ｂがｅｖｅｎｔ配信ソフト２２ｃに対して渡す情報は、図１１に示すように、１２８ｂｙｔｅ固定のバイナリデータとなっており、ハード監視ソフト２２ａまたは解析プログラム２２ｄにより異常検出された時刻を示す「発生時刻」、サービスプロセッサ２０再起動前のＤＢ２の状態を示す「旧状態」、不整合検出後のＤＢ２の状態を示す「新状態」、不整合が検出されたコンポーネント識別子を示す「検出元」、故障位置を表す文字列を示す「故障コンポーネント名」および不整合検出を表す固定文字列を示す「故障要因文字列」から構成される。また、各フォーマットの内容および故障コンポーネント名の内容は、図１２に示すような内容となる。なお、図１１は、実施例１に係るエラー管理ソフト２２ｂがｅｖｅｎｔ配信ソフト２２ｃに渡す情報の例を示す図であり、図１２は、実施例１に係るエラー管理ソフト２２ｂがｅｖｅｎｔ配信ソフト２２ｃに渡す情報の内容を示す図である。
（項番７）
項番７では、サービスプロセッサ２０の起動契機が再起動によるものであり、ＤＢ１の故障要因が部分故障を示す「Ｗａｒｎｉｎｇ要因」となる状態である。このような状態において、エラー管理ソフト２２ｂは、サービスプロセッサ２０が再起動されると、ＤＢ１のｂｉｔ領域から故障要因を取得する。そして、エラー管理ソフト２２ｂは、取得された故障要因として、ＣＰＵ＃０領域「ＣＯＲＥ＃１ ＴＬＢ Ｂｕｆｆｅｒ ｅｒｒｏｒ（ｂｉｔ２８）」に「１」が立っている場合に、ＤＢ２に書き込む（復元する）故障状態を「Ｗａｒｎｉｎｇ」と仮判定する。続いて、エラー管理ソフト２２ｂは、ＤＢ２からＣＰＵ＃０の故障状態「Ｗａｒｎｉｎｇ」を取得し、取得された故障状態「Ｗａｒｎｉｎｇ」と仮判定された故障状態「Ｗａｒｎｉｎｇ」とを比較する。
項番７では、サービスプロセッサ２０の起動契機が再起動によるものであり、ＤＢ１の故障要因が部分故障を示す「Ｗａｒｎｉｎｇ要因」となる状態である。このような状態において、エラー管理ソフト２２ｂは、サービスプロセッサ２０が再起動されると、ＤＢ１のｂｉｔ領域から故障要因を取得する。そして、エラー管理ソフト２２ｂは、取得された故障要因として、ＣＰＵ＃０領域「ＣＯＲＥ＃１ ＴＬＢ Ｂｕｆｆｅｒ ｅｒｒｏｒ（ｂｉｔ２８）」に「１」が立っている場合に、ＤＢ２に書き込む（復元する）故障状態を「Ｗａｒｎｉｎｇ」と仮判定する。続いて、エラー管理ソフト２２ｂは、ＤＢ２からＣＰＵ＃０の故障状態「Ｗａｒｎｉｎｇ」を取得し、取得された故障状態「Ｗａｒｎｉｎｇ」と仮判定された故障状態「Ｗａｒｎｉｎｇ」とを比較する。
その後、エラー管理ソフト２２ｂは、故障状態の比較の結果、ＤＢ１とＤＢ２との故障状態に差分がないので、仮判定された故障状態「Ｗａｒｎｉｎｇ」をＤＢ２に書き込む（復元する）ことなく処理を終了する。
（項番８）
項番８では、サービスプロセッサ２０の起動契機が再起動によるものであり、ＤＢ１の故障要因が部分故障を示す「Ｗａｒｎｉｎｇ要因」となる状態である。このような状態において、エラー管理ソフト２２ｂは、サービスプロセッサ２０が再起動されると、ＤＢ１のｂｉｔ領域から故障要因を取得する。そして、エラー管理ソフト２２ｂは、取得された故障要因として、ＣＰＵ＃０領域「ＣＯＲＥ＃１ ＴＬＢ Ｂｕｆｆｅｒ ｅｒｒｏｒ（ｂｉｔ２８）」に「１」が立っている場合に、ＤＢ２に書き込む（復元する）故障状態を「Ｗａｒｎｉｎｇ」と仮判定する。続いて、エラー管理ソフト２２ｂは、ＤＢ２からＣＰＵ＃０の故障状態「Ａｌａｒｍ」を取得し、取得された故障状態「Ａｌａｒｍ」と仮判定された故障状態「Ｗａｒｎｉｎｇ」とを比較する。
項番８では、サービスプロセッサ２０の起動契機が再起動によるものであり、ＤＢ１の故障要因が部分故障を示す「Ｗａｒｎｉｎｇ要因」となる状態である。このような状態において、エラー管理ソフト２２ｂは、サービスプロセッサ２０が再起動されると、ＤＢ１のｂｉｔ領域から故障要因を取得する。そして、エラー管理ソフト２２ｂは、取得された故障要因として、ＣＰＵ＃０領域「ＣＯＲＥ＃１ ＴＬＢ Ｂｕｆｆｅｒ ｅｒｒｏｒ（ｂｉｔ２８）」に「１」が立っている場合に、ＤＢ２に書き込む（復元する）故障状態を「Ｗａｒｎｉｎｇ」と仮判定する。続いて、エラー管理ソフト２２ｂは、ＤＢ２からＣＰＵ＃０の故障状態「Ａｌａｒｍ」を取得し、取得された故障状態「Ａｌａｒｍ」と仮判定された故障状態「Ｗａｒｎｉｎｇ」とを比較する。
その後、エラー管理ソフト２２ｂは、故障状態の比較の結果、ＤＢ１とＤＢ２との故障状態に差分があるが、ＤＢ１から仮判定された故障状態「Ｗａｒｎｉｎｇ」とＤＢ２から取得された故障状態「Ａｌａｒｍ」とのうち、より重大度が高い状態をハードウェアＣＰＵ＃０の状態とするので、仮判定された故障状態「Ｗａｒｎｉｎｇ」をＤＢ２に書き込む（復元する）ことなく処理を終了する。つまり、ＤＢ１の故障状態を示すＤＢ２の内容は、再起動前の故障状態である「Ａｌａｒｍ」が保持される。
（項番９）
項番９では、サービスプロセッサ２０の起動契機が情報処理装置１０の電源投入によるものであり、ＤＢ１の故障要因が完全故障を示す「Ａｌａｒｍ要因」となる状態である。このような状態において、エラー管理ソフト２２ｂは、サービスプロセッサ２０が起動されると、ＤＢ１のｂｉｔ領域から故障要因を取得する。そして、エラー管理ソフト２２ｂは、取得された故障要因として、ＣＰＵ＃０領域「ＣＯＲＥ＃０ ｅｒｒｏｒ（ｂｉｔ３１）」および「ＣＯＲＥ＃１ ｅｒｒｏｒ（ｂｉｔ３０）」に「１」が立っている場合に、ＣＰＵ＃０のＣＯＲＥが全て故障しているので、ＤＢ２に書き込む（復元する）故障状態を「Ａｌａｒｍ」と仮判定する。続いて、エラー管理ソフト２２ｂは、ＤＢ２からＣＰＵ＃０の故障状態「Ｎｏｒｍａｌ」を取得し、取得された故障状態「Ｎｏｒｍａｌ」と仮判定された故障状態「Ａｌａｒｍ」とを比較する。
項番９では、サービスプロセッサ２０の起動契機が情報処理装置１０の電源投入によるものであり、ＤＢ１の故障要因が完全故障を示す「Ａｌａｒｍ要因」となる状態である。このような状態において、エラー管理ソフト２２ｂは、サービスプロセッサ２０が起動されると、ＤＢ１のｂｉｔ領域から故障要因を取得する。そして、エラー管理ソフト２２ｂは、取得された故障要因として、ＣＰＵ＃０領域「ＣＯＲＥ＃０ ｅｒｒｏｒ（ｂｉｔ３１）」および「ＣＯＲＥ＃１ ｅｒｒｏｒ（ｂｉｔ３０）」に「１」が立っている場合に、ＣＰＵ＃０のＣＯＲＥが全て故障しているので、ＤＢ２に書き込む（復元する）故障状態を「Ａｌａｒｍ」と仮判定する。続いて、エラー管理ソフト２２ｂは、ＤＢ２からＣＰＵ＃０の故障状態「Ｎｏｒｍａｌ」を取得し、取得された故障状態「Ｎｏｒｍａｌ」と仮判定された故障状態「Ａｌａｒｍ」とを比較する。
その後、エラー管理ソフト２２ｂは、故障状態の比較の結果、ＤＢ１とＤＢ２との故障状態に差分があり、さらに、ＤＢ１から仮判定された故障状態「Ａｌａｒｍ」の方が重大度が高い状態であるので、仮判定された故障状態「Ａｌａｒｍ」をＤＢ２に書き込んで（復元して）処理を終了する。つまり、ＤＢ１の故障状態を示すＤＢ２の内容は、ＤＢ１の故障要因に基づいて復元された故障状態である「Ａｌａｒｍ」が保持される。
ここで、エラー管理ソフト２２ｂは、サービスプロセッサ２０の起動によってＤＢ２が全て「０」に初期化されているために、イベントのロストによる不整合であるか、または、ＤＢ２の初期化による不整合であるかを判定することができない。しかしながら、エラー管理ソフト２２ｂは、イベントのロストによる不整合ではなく、ＤＢ２の初期化による不整合であることを優先するとともに、後述するｅｖｅｎｔ配信ソフト２２ｃや通報ソフト２２ｅなどへの通知がサービスプロセッサ２０の起動前に行なわれていることとして判定する結果、ｅｖｅｎｔ配信ソフト２２ｃに不整合検出イベントを通知することはない。
（項番１０）
項番１０では、サービスプロセッサ２０の起動契機が再起動によるものであり、ＤＢ１の故障要因が完全故障を示す「Ａｌａｒｍ要因」となる状態である。このような状態において、エラー管理ソフト２２ｂは、サービスプロセッサ２０が再起動されると、ＤＢ１のｂｉｔ領域から故障要因を取得する。そして、エラー管理ソフト２２ｂは、取得された故障要因として、ＣＰＵ＃０領域「ＣＯＲＥ＃０ ｅｒｒｏｒ（ｂｉｔ３１）」および「ＣＯＲＥ＃１ ｅｒｒｏｒ（ｂｉｔ３０）」に「１」が立っている場合に、ＣＰＵ＃０のＣＯＲＥが全て故障しているので、ＤＢ２に書き込む（復元する）故障状態を「Ａｌａｒｍ」と仮判定する。続いて、エラー管理ソフト２２ｂは、ＤＢ２からＣＰＵ＃０の故障状態「Ｎｏｒｍａｌ」を取得し、取得された「Ｎｏｒｍａｌ」と仮判定された故障状態「Ａｌａｒｍ」とを比較する。
項番１０では、サービスプロセッサ２０の起動契機が再起動によるものであり、ＤＢ１の故障要因が完全故障を示す「Ａｌａｒｍ要因」となる状態である。このような状態において、エラー管理ソフト２２ｂは、サービスプロセッサ２０が再起動されると、ＤＢ１のｂｉｔ領域から故障要因を取得する。そして、エラー管理ソフト２２ｂは、取得された故障要因として、ＣＰＵ＃０領域「ＣＯＲＥ＃０ ｅｒｒｏｒ（ｂｉｔ３１）」および「ＣＯＲＥ＃１ ｅｒｒｏｒ（ｂｉｔ３０）」に「１」が立っている場合に、ＣＰＵ＃０のＣＯＲＥが全て故障しているので、ＤＢ２に書き込む（復元する）故障状態を「Ａｌａｒｍ」と仮判定する。続いて、エラー管理ソフト２２ｂは、ＤＢ２からＣＰＵ＃０の故障状態「Ｎｏｒｍａｌ」を取得し、取得された「Ｎｏｒｍａｌ」と仮判定された故障状態「Ａｌａｒｍ」とを比較する。
その後、エラー管理ソフト２２ｂは、故障状態の比較の結果、ＤＢ１とＤＢ２との故障状態に差分があり、さらに、ＤＢ１から仮判定された故障状態「Ａｌａｒｍ」の方が重大度が高い状態であるので、仮判定された故障状態「Ａｌａｒｍ」をＤＢ２に書き込む（復元する）。つまり、ＤＢ１の故障状態を示すＤＢ２の内容は、ＤＢ１の故障要因に基づいて復元された故障状態である「Ａｌａｒｍ」が保持される。
そして、エラー管理ソフト２２ｂは、イベントが途中でロストした可能性があると判定して、後述するｅｖｅｎｔ配信ソフト２２ｃに対して不整合検出イベントを通知する。つまり、エラー管理ソフト２２ｂは、サービスプロセッサ２０の再起動によりＤＢ２の故障状態が再起動前の故障状態であるはずにもかかわらず、ＤＢ１とＤＢ２とで不整合が発生しているので、イベントが途中でロストした可能性があると判定する。
このエラー管理ソフト２２ｂがｅｖｅｎｔ配信ソフト２２ｃに対して渡す情報は、図１１に示すように、１２８ｂｙｔｅ固定のバイナリデータとなっており、ハード監視ソフト２２ａまたは解析プログラム２２ｄにより異常検出された時刻を示す「発生時刻」、サービスプロセッサ２０再起動前のＤＢ２の状態を示す「旧状態」、不整合検出後のＤＢ２の状態を示す「新状態」、不整合が検出されたコンポーネント識別子を示す「検出元」、故障位置を表す文字列を示す「故障コンポーネント名」および不整合検出を表す固定文字列を示す「故障要因文字列」から構成される。また、各フォーマットの内容および故障コンポーネント名の内容は、図１２に示すような内容となる。
（項番１１）
項番１１では、サービスプロセッサ２０の起動契機が再起動によるものであり、ＤＢ１の故障要因が完全故障を示す「Ａｌａｒｍ要因」となる状態である。このような状態において、エラー管理ソフト２２ｂは、サービスプロセッサ２０が再起動されると、ＤＢ１のｂｉｔ領域から故障要因を取得する。そして、エラー管理ソフト２２ｂは、取得された故障要因として、ＣＰＵ＃０領域「ＣＯＲＥ＃０ ｅｒｒｏｒ（ｂｉｔ３１）」および「ＣＯＲＥ＃１ ｅｒｒｏｒ（ｂｉｔ３０）」に「１」が立っている場合に、ＣＰＵ＃０のＣＯＲＥが全て故障しているので、ＤＢ２に書き込む（復元する）故障状態を「Ａｌａｒｍ」と仮判定する。続いて、エラー管理ソフト２２ｂは、ＤＢ２からＣＰＵ＃０の故障状態「Ｗａｒｎｉｎｇ」を取得し、取得された「Ｗａｒｎｉｎｇ」と仮判定された故障状態「Ａｌａｒｍ」とを比較する。
項番１１では、サービスプロセッサ２０の起動契機が再起動によるものであり、ＤＢ１の故障要因が完全故障を示す「Ａｌａｒｍ要因」となる状態である。このような状態において、エラー管理ソフト２２ｂは、サービスプロセッサ２０が再起動されると、ＤＢ１のｂｉｔ領域から故障要因を取得する。そして、エラー管理ソフト２２ｂは、取得された故障要因として、ＣＰＵ＃０領域「ＣＯＲＥ＃０ ｅｒｒｏｒ（ｂｉｔ３１）」および「ＣＯＲＥ＃１ ｅｒｒｏｒ（ｂｉｔ３０）」に「１」が立っている場合に、ＣＰＵ＃０のＣＯＲＥが全て故障しているので、ＤＢ２に書き込む（復元する）故障状態を「Ａｌａｒｍ」と仮判定する。続いて、エラー管理ソフト２２ｂは、ＤＢ２からＣＰＵ＃０の故障状態「Ｗａｒｎｉｎｇ」を取得し、取得された「Ｗａｒｎｉｎｇ」と仮判定された故障状態「Ａｌａｒｍ」とを比較する。
その後、エラー管理ソフト２２ｂは、故障状態の比較の結果、ＤＢ１とＤＢ２との故障状態に差分があり、さらに、ＤＢ１から仮判定された故障状態「Ａｌａｒｍ」の方が重大度が高い状態であるので、仮判定された故障状態「Ａｌａｒｍ」をＤＢ２に書き込む（復元する）。つまり、ＤＢ１の故障状態を示すＤＢ２の内容は、ＤＢ１の故障要因に基づいて復元された故障状態である「Ａｌａｒｍ」が保持される。
そして、エラー管理ソフト２２ｂは、イベントが途中でロストした可能性があると判定して、後述するｅｖｅｎｔ配信ソフト２２ｃに対して不整合検出イベントを通知する。つまり、エラー管理ソフト２２ｂは、サービスプロセッサ２０の再起動によりＤＢ２の故障状態が再起動前の故障状態であるはずにもかかわらず、ＤＢ１とＤＢ２とで不整合が発生しているので、イベントが途中でロストした可能性があると判定する。
このエラー管理ソフト２２ｂがｅｖｅｎｔ配信ソフト２２ｃに対して渡す情報は、図１１に示すように、１２８ｂｙｔｅ固定のバイナリデータとなっており、ハード監視ソフト２２ａまたは解析プログラム２２ｄにより異常検出された時刻を示す「発生時刻」、サービスプロセッサ２０再起動前のＤＢ２の状態を示す「旧状態」、不整合検出後のＤＢ２の状態を示す「新状態」、不整合が検出されたコンポーネント識別子を示す「検出元」、故障位置を表す文字列を示す「故障コンポーネント名」および不整合検出を表す固定文字列を示す「故障要因文字列」から構成される。また、各フォーマットの内容および故障コンポーネント名の内容は、図１２に示すような内容となる。
（項番１２）
項番１２では、サービスプロセッサ２０の起動契機が再起動によるものであり、ＤＢ１の故障要因が完全故障を示す「Ａｌａｒｍ要因」となる状態である。このような状態において、エラー管理ソフト２２ｂは、サービスプロセッサ２０が再起動されると、ＤＢ１のｂｉｔ領域から故障要因を取得する。そして、エラー管理ソフト２２ｂは、取得された故障要因として、ＣＰＵ＃０領域「ＣＯＲＥ＃０ ｅｒｒｏｒ（ｂｉｔ３１）」および「ＣＯＲＥ＃１ ｅｒｒｏｒ（ｂｉｔ３０）」に「１」が立っている場合に、ＣＰＵ＃０のＣＯＲＥが全て故障しているので、ＤＢ２に書き込む（復元する）故障状態を「Ａｌａｒｍ」と仮判定する。続いて、エラー管理ソフト２２ｂは、ＤＢ２からＣＰＵ＃０の故障状態「Ａｌａｒｍ」を取得し、取得された「Ａｌａｒｍ」と仮判定された故障状態「Ａｌａｒｍ」とを比較する。
項番１２では、サービスプロセッサ２０の起動契機が再起動によるものであり、ＤＢ１の故障要因が完全故障を示す「Ａｌａｒｍ要因」となる状態である。このような状態において、エラー管理ソフト２２ｂは、サービスプロセッサ２０が再起動されると、ＤＢ１のｂｉｔ領域から故障要因を取得する。そして、エラー管理ソフト２２ｂは、取得された故障要因として、ＣＰＵ＃０領域「ＣＯＲＥ＃０ ｅｒｒｏｒ（ｂｉｔ３１）」および「ＣＯＲＥ＃１ ｅｒｒｏｒ（ｂｉｔ３０）」に「１」が立っている場合に、ＣＰＵ＃０のＣＯＲＥが全て故障しているので、ＤＢ２に書き込む（復元する）故障状態を「Ａｌａｒｍ」と仮判定する。続いて、エラー管理ソフト２２ｂは、ＤＢ２からＣＰＵ＃０の故障状態「Ａｌａｒｍ」を取得し、取得された「Ａｌａｒｍ」と仮判定された故障状態「Ａｌａｒｍ」とを比較する。
その後、エラー管理ソフト２２ｂは、故障状態の比較の結果、ＤＢ１とＤＢ２との故障状態に差分がないので、仮判定された故障状態「Ａｌａｒｍ」をＤＢ２に書き込む（復元する）ことなく処理を終了する。
次に、ｅｖｅｎｔ配信ソフト２２ｃの機能について説明する。ｅｖｅｎｔ配信ソフト２２ｃは、エラー管理ソフト２２ｂにより通知された不整合検出イベントをキューイングする。上記した例で具体的に例を挙げると、ｅｖｅｎｔ配信ソフト２２ｃは、エラー管理ソフト２２ｂにより不整合検出されて通知された不整合検出イベントを、所定の領域にキューとしてためていく。
解析プログラム２２ｄは、ハードウェア資源１１からのエラー通知（障害通知）を受信する。上記した例で具体的に例を挙げると、解析プログラム２２ｄは、ｅｖｅｎｔ配信ソフト２２ｃにより不整合検出イベントがキューイングされると、起動するとともに、ハードウェア資源１１からのエラー通知（障害通知）を受信できる状態に遷移する。
通報ソフト２２ｅは、エラー管理ソフト２２ｂにより通知された不整合検出イベントを受信して、管理サーバ１に対して通知する。上記した例で具体的に例を挙げると、通報ソフト２２ｅは、ｅｖｅｎｔ配信ソフト２２ｃによりキューイングされて、エラー管理ソフト２２ｂにより通知された不整合検出イベントを受信する。そして、通報ソフト２２ｅは、受信された不整合検出イベントから通報用フォーマット文字列を生成して、ＭａｉｌまたはＳＮＭＰなどを用いて管理サーバ１に対して故障情報を通知する。
この通報ソフト２２ｅがエラー管理ソフト２２ｂから受信する情報は、図１３に示すように、１２８ｂｙｔｅ固定のバイナリデータとなっており、ハード監視ソフト２２ａまたは解析プログラム２２ｄにより異常検出された時刻を示す「発生時刻」、サービスプロセッサ２０再起動前のＤＢ２の状態を示す「旧状態」、不整合検出後のＤＢ２の状態を示す「新状態」、不整合が検出されたコンポーネント識別子を示す「検出元」、故障位置を表す文字列を示す「故障コンポーネント名」および不整合検出の表す固定文字列を示す「故障要因文字列」から構成される。また、各フォーマットの内容および故障コンポーネント名の内容は、図１４に示すような内容となる。なお、図１３は、実施例１に係る通報ソフト２２ｅがエラー管理ソフト２２ｂから受信する情報の例を示す図であり、図１４は、実施例１に係る通報ソフト２２ｅがエラー管理ソフト２２ｂから受信する情報の内容を示す図である。
また、この通報ソフト２２ｅが生成する通報用フォーマット文字列は、図１５および図１６に示すように、異常検出された時刻を示す発生時刻「２００７／Ｄｅｃ／３１ ２３：５９：３０」、異常検出されたハードウェア資源１１を示すハードウェア資源「ＣＰＵ＃０」、不整合イベント検出を表す固定文字列を示す故障要因文字列「Ｃｏｍｐｏｎｅｎｔ ｓｔａｔｕｓ ｍｉｓｍａｔｃｈｅｄ」、サービスプロセッサ２０再起動前と不整合イベント検出後とのＤＢ２の状態を示す「（Ｗａｒｎｉｎｇ→Ａｌａｒｍ）」から構成される。なお、図１５は、実施例１に係る通報ソフト２２ｅが生成する通報用フォーマット文字列の例を示す図であり、図１６は、実施例１に係る通報ソフト２２ｅが生成する通報用フォーマット文字列の内容を示す図である。
［実施例１に係る情報処理装置による処理］
次に、図１７を用いて、実施例１に係る情報処理装置１０による故障情報通知処理を説明する。図１７は、実施例１に係る情報処理装置１０による故障情報通知処理を説明するためのフローチャートである。
次に、図１７を用いて、実施例１に係る情報処理装置１０による故障情報通知処理を説明する。図１７は、実施例１に係る情報処理装置１０による故障情報通知処理を説明するためのフローチャートである。
図１７に示すように、情報処理装置１０は、サービスプロセッサが起動されると（ステップＳ１０１）、エラー管理ソフト２２ｂが起動されて（ステップＳ１０２成功）、ハード監視ソフト２２ａにより復元依頼があるか否かを判定する（ステップＳ１０３）。そして、情報処理装置１０は、ハード監視ソフト２２ａにより復元依頼があった場合に（ステップＳ１０３有り）、故障要因が保持されるＤＢ１と、故障状態が保持されるＤＢ２を読み込む（ステップＳ１０４成功、ステップＳ１０５成功）。
続いて、情報処理装置１０は、故障要因が保持されるＤＢ１から復元するＤＢ２の故障状態を仮判定して（ステップＳ１０６成功）、仮判定された故障状態とＤＢ１の状態とを比較する（ステップＳ１０７）。その後、情報処理装置１０は、ＤＢ１とＤＢ２との故障情報において不整合を検出すると（ステップＳ１０８送信必要）、当該不整合に基づいて不整合イベントを生成し（ステップＳ１０９成功）、ｅｖｅｎｔ配信ソフト２２ｃに対して不整合イベントの送信依頼を通知する（ステップＳ１１０）。
そして、情報処理装置１０は、ハード監視ソフト２２ａにより復元依頼がない場合に（ステップＳ１０３無し）、ｉｎｉｔプロセスなどによるエラー管理ソフト２２ｂの停止依頼があるか否かの判定を行なう（ステップＳ１１１）。続いて、情報処理装置１０は、ｉｎｉｔプロセスなどによるエラー管理ソフト２２ｂの停止依頼がない場合に（ステップＳ１１１無し）、ｅｖｅｎｔ配信ソフト２２ｃによる不整合イベントを受信する（ステップＳ１１２）。
その後、情報処理装置１０は、故障要因が保持されるＤＢ１を読み込み（ステップＳ１１３成功）、故障状態が保持されるＤＢ２の書き込み（復元する）位置を算出して（ステップＳ１１４成功）、ＤＢ１に保持される故障要因に基づいて、ＤＢ２に保持される故障状態を算出する（ステップＳ１１５成功）。そして、情報処理装置１０は、算出された故障状態をＤＢ２に書き込んで（復元して）（ステップＳ１１６成功）、通報ソフト２２ｅに対して障害情報通知イベントの送信依頼を通知する（ステップＳ１１７）。続いて、情報処理装置１０は、ｉｎｉｔプロセスなどによるエラー管理ソフト２２ｂの停止依頼があった場合に（ステップＳ１１１有り）、エラー管理ソフト２２ｂを停止する（ステップＳ１１８）。なお、障害情報通知イベントの送信依頼を通知された通報ソフト２２ｅは、接続される管理サーバ１に対して障害情報を通知する。
［実施例１による効果］
このようにして、実施例１によれば、情報処理装置１０は、複数のハードウェア資源を有するとともに、第１の電源により動作する場合に、第１の電源が遮断された場合においても、ハードウェア資源において発生した障害に関する第１の障害情報を保持する第１の記憶部と、第１の障害情報とは異なる第２の障害情報を保持するとともに、第１の電源が遮断された場合に、第２の障害情報が保持されない第２の記憶部とを有し、情報処理装置に実装されている複数のハードウェア資源の構成情報を取得し、構成情報と第１の記憶部に格納された第１の障害情報に基づいて、第２の記憶部に保持する第２の障害情報を復元し、第１の障害情報と第２の障害情報間の整合性を検査し、第１の障害情報と第２の障害情報間において不整合が検出された場合には、障害が発生した旨を通知するので、不揮発性の記憶部と揮発性の記憶部とを有する情報処理装置において、揮発性の記憶部の障害情報を復元することが可能である。つまり、情報処理装置１０は、サービスプロセッサ２０が起動された場合に、保持されるハードウェア資源の故障要因に基づいて、故障状態を復元することができる結果、故障状態を退避するための領域を必要とすることなく、少ない資源で故障状態を復元することが可能である。また、情報処理装置１０は、故障状態を復元することができる結果、故障状態を喪失することなく、接続される管理サーバ１などに通知することが可能である。
このようにして、実施例１によれば、情報処理装置１０は、複数のハードウェア資源を有するとともに、第１の電源により動作する場合に、第１の電源が遮断された場合においても、ハードウェア資源において発生した障害に関する第１の障害情報を保持する第１の記憶部と、第１の障害情報とは異なる第２の障害情報を保持するとともに、第１の電源が遮断された場合に、第２の障害情報が保持されない第２の記憶部とを有し、情報処理装置に実装されている複数のハードウェア資源の構成情報を取得し、構成情報と第１の記憶部に格納された第１の障害情報に基づいて、第２の記憶部に保持する第２の障害情報を復元し、第１の障害情報と第２の障害情報間の整合性を検査し、第１の障害情報と第２の障害情報間において不整合が検出された場合には、障害が発生した旨を通知するので、不揮発性の記憶部と揮発性の記憶部とを有する情報処理装置において、揮発性の記憶部の障害情報を復元することが可能である。つまり、情報処理装置１０は、サービスプロセッサ２０が起動された場合に、保持されるハードウェア資源の故障要因に基づいて、故障状態を復元することができる結果、故障状態を退避するための領域を必要とすることなく、少ない資源で故障状態を復元することが可能である。また、情報処理装置１０は、故障状態を復元することができる結果、故障状態を喪失することなく、接続される管理サーバ１などに通知することが可能である。
例えば、情報処理装置１０は、当該情報処理装置１０の電源が遮断された場合においても故障要因が保持される不揮発性のＤＢ１と、当該ＤＢ１とは異なる故障状態を保持し、当該情報処理装置１０の電源が遮断された場合に故障状態が保持されない揮発性のＤＢ２とを有し、サービスプロセッサ２０が起動された場合に、ＤＢ１に保持される故障要因からＤＢ２に保持される故障状態を復元するとともに、ＤＢ１およびＤＢ２間の整合性を検査し、不整合が検出されると、不整合検出イベントを接続される管理サーバ１などに通知する。この結果、不揮発性の記憶部と揮発性の記憶部とを有する情報処理装置において、揮発性の記憶部の障害情報を復元することが可能である。
さて、これまで本発明の実施例について説明したが、本発明は上述した実施例以外にも
種々の異なる形態にて実施されてよいものである。そこで、（１）情報処理装置の構成、（２）プログラムにおいて異なる実施例を説明する。
種々の異なる形態にて実施されてよいものである。そこで、（１）情報処理装置の構成、（２）プログラムにおいて異なる実施例を説明する。
（１）情報処理装置の構成
また、上記文書中や図面中で示した処理手順、制御手順、具体的名称、各種のデータやパラメタを含む情報（例えば、図２に示したような「ＤＢ１」、「ＤＢ２」が記憶している項目や数値など）については、特記する場合を除いて任意に変更することができる。また、上記実施例１では、障害情報の復元および障害情報の整合性検査を行なう情報処理装置を説明したが、本発明はこれに限定されるものではなく、障害情報の復元を行なう情報処理装置、または、障害情報の整合性検査を行なう情報処理装置として実施することとしてもよい。
また、上記文書中や図面中で示した処理手順、制御手順、具体的名称、各種のデータやパラメタを含む情報（例えば、図２に示したような「ＤＢ１」、「ＤＢ２」が記憶している項目や数値など）については、特記する場合を除いて任意に変更することができる。また、上記実施例１では、障害情報の復元および障害情報の整合性検査を行なう情報処理装置を説明したが、本発明はこれに限定されるものではなく、障害情報の復元を行なう情報処理装置、または、障害情報の整合性検査を行なう情報処理装置として実施することとしてもよい。
また、図示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散・統合の具体的形態は図示のものに限られず、例えば、エラー管理ソフト２２ｂと通報ソフト２２ｅとを、障害情報の復元および整合性の検査を行なうとともに、不整合が検出された場合に障害が発生した旨を通知するエラー管理／通報ソフトとして統合するなど、その全部または一部を、各種の負担や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。さらに、各装置にて行われる各処理機能は、その全部または任意の一部が、ＣＰＵおよび当該ＣＰＵにて解析実行されるプログラムにて実現され、あるいは、ワイヤードロジックによるハードウェアとして実現され得る。
（２）プログラム
ところで、上記の実施例では、ハードウェアロジックによって各種の処理を実現する場合を説明したが、本発明はこれに限定されるものではなく、あらかじめ用意されたプログラムをコンピュータで実行することによって実現するようにしてもよい。そこで、以下では、図１８を用いて、上記の実施例に示した情報処理装置と同様の機能を有する制御プログラムを実行するコンピュータの一例を説明する。図１８は、制御プログラムを実行するコンピュータを示す図である。
ところで、上記の実施例では、ハードウェアロジックによって各種の処理を実現する場合を説明したが、本発明はこれに限定されるものではなく、あらかじめ用意されたプログラムをコンピュータで実行することによって実現するようにしてもよい。そこで、以下では、図１８を用いて、上記の実施例に示した情報処理装置と同様の機能を有する制御プログラムを実行するコンピュータの一例を説明する。図１８は、制御プログラムを実行するコンピュータを示す図である。
図１８に示すように、情報処理装置としてのコンピュータ１１０は、ＨＤＤ１３０、ＣＰＵ１４０、ＲＯＭ１５０およびＲＡＭ１６０をバス１８０などで接続して構成される。
ＲＯＭ１５０には、上記の実施例１に示した情報処理装置１０と同様の機能を発揮する制御プログラム、つまり、図１８に示すように構成情報取得プログラム１５０ａと、障害情報復元プログラム１５０ｂと、整合性検査プログラム１５０ｃと、障害通知プログラム１５０ｄとが、あらかじめ記憶されている。なお、これらのプログラム１５０ａ〜プログラム１５０ｄについては、図２に示した情報処理装置１０の各構成要素と同様、適宜統合または、分散してもよい。
そして、ＣＰＵ１４０がこれらのプログラム１５０ａ〜プログラム１５０ｄをＲＯＭ１５０から読み出して実行することで、図１８に示すように、プログラム１５０ａ〜プログラム１５０ｄは、構成情報取得プロセス１４０ａと、障害情報復元プロセス１４０ｂと、整合性検査プロセス１４０ｃと、障害通知プロセス１４０ｄとして機能するようになる。なお、プロセス１４０ａ〜プロセス１４０ｄは、図２に示した、ハード監視ソフト２２ａと、エラー管理ソフト２２ｂと、通報ソフト２２ｅとに対応する。
そして、ＣＰＵ１４０はＨＤＤ１３０に記録された第１障害情報データ１３０ａと、第２障害情報データ１３０ｂとに基づいて制御プログラムを実行する。
なお、上記した各プログラム１５０ａ〜プログラム１５０ｄについては、必ずしも最初からＲＯＭ１５０に記憶させておく必要はなく、例えば、コンピュータ１１０に挿入されるコンピュータ読み取り可能なフレキシブルディスク（ＦＤ）、ＣＤ−ＲＯＭ、ＤＶＤディスク、光磁気ディスク、ＩＣカードなどの「可搬用の物理媒体」、またはコンピュータ１１０の内外に備えられるＨＤＤなどの「固定用の物理媒体」、さらには公衆回線、インターネット、ＬＡＮ、ＷＡＮなどを介してコンピュータ１１０に接続される「他のコンピュータ（またはサーバ）」などに各プログラムを記憶させておき、コンピュータ１１０がこれから各プログラムを読み出して実行するようにしてもよい。
以上の実施例１および２を含む実施形態に関し、更に以下の付記を開示する。
（付記１）複数のハードウェア資源を有するとともに、第１の電源により動作する情報処理装置において、
前記第１の電源が遮断された場合においても、前記ハードウェア資源において発生した障害に関する第１の障害情報を保持する第１の記憶部と、
前記第１の障害情報とは異なる第２の障害情報を保持するとともに、前記第１の電源が遮断された場合に、前記第２の障害情報が保持されない第２の記憶部と、
前記情報処理装置に実装されている前記複数のハードウェア資源の構成情報を取得するハードウェア監視部と、前記構成情報と前記第１の記憶部に格納された第１の障害情報に基づいて、前記第２の記憶部に保持する第２の障害情報を復元する障害情報管理部として機能するシステム制御装置を有することを特徴とする情報処理装置。
前記第１の電源が遮断された場合においても、前記ハードウェア資源において発生した障害に関する第１の障害情報を保持する第１の記憶部と、
前記第１の障害情報とは異なる第２の障害情報を保持するとともに、前記第１の電源が遮断された場合に、前記第２の障害情報が保持されない第２の記憶部と、
前記情報処理装置に実装されている前記複数のハードウェア資源の構成情報を取得するハードウェア監視部と、前記構成情報と前記第１の記憶部に格納された第１の障害情報に基づいて、前記第２の記憶部に保持する第２の障害情報を復元する障害情報管理部として機能するシステム制御装置を有することを特徴とする情報処理装置。
（付記２）前記情報処理装置はさらに、
前記システム制御装置に、電力を供給する第２の電源を有し、
前記第２の電源は、前記第１の電源が遮断されている場合においても、前記システム制御装置に対して電力を供給し続けることを特徴とする付記１記載の情報処理装置。
前記システム制御装置に、電力を供給する第２の電源を有し、
前記第２の電源は、前記第１の電源が遮断されている場合においても、前記システム制御装置に対して電力を供給し続けることを特徴とする付記１記載の情報処理装置。
（付記３）前記障害情報管理部は、
前記第１の電源が投入された場合に、前記構成情報と前記第１の記憶部に格納された第１の障害情報に基づいて、前記第２の記憶部に保持する第２の障害情報を復元することを特徴とする付記１又は２記載の情報処理装置。
前記第１の電源が投入された場合に、前記構成情報と前記第１の記憶部に格納された第１の障害情報に基づいて、前記第２の記憶部に保持する第２の障害情報を復元することを特徴とする付記１又は２記載の情報処理装置。
（付記４）前記第１の障害情報は、
前記障害が発生したハードウェア資源を識別する識別情報と、
前記障害が発生したハードウェア資源における障害要因を有することを特徴とする付記１乃至３のいずれかに記載の情報処理装置。
前記障害が発生したハードウェア資源を識別する識別情報と、
前記障害が発生したハードウェア資源における障害要因を有することを特徴とする付記１乃至３のいずれかに記載の情報処理装置。
（付記５）前記第２の障害情報は、
前記障害が発生したハードウェア資源を識別する識別情報と、
前記障害が発生したハードウェア資源における障害の程度に関する情報を有することを特徴とする付記１乃至４のいずれかに記載の情報処理装置。
前記障害が発生したハードウェア資源を識別する識別情報と、
前記障害が発生したハードウェア資源における障害の程度に関する情報を有することを特徴とする付記１乃至４のいずれかに記載の情報処理装置。
（付記６）複数のハードウェア資源を有するとともに、第１の電源により動作する情報処理装置において、
前記第１の電源が遮断された場合においても、前記ハードウェア資源において発生した障害に関する第１の障害情報を保持する第１の記憶部と、
前記第１の障害情報とは異なる第２の障害情報を保持するとともに、前記第１の電源が遮断された場合に、前記第２の障害情報が保持されない第２の記憶部と、
前記第１の障害情報と前記第２の障害情報間の整合性を検査する障害情報管理部と、前記第１の障害情報と前記第２の障害情報間において不整合が検出された場合には、障害が発生した旨を通知する障害通知部として機能するシステム制御装置を有することを特徴とする情報処理装置。
前記第１の電源が遮断された場合においても、前記ハードウェア資源において発生した障害に関する第１の障害情報を保持する第１の記憶部と、
前記第１の障害情報とは異なる第２の障害情報を保持するとともに、前記第１の電源が遮断された場合に、前記第２の障害情報が保持されない第２の記憶部と、
前記第１の障害情報と前記第２の障害情報間の整合性を検査する障害情報管理部と、前記第１の障害情報と前記第２の障害情報間において不整合が検出された場合には、障害が発生した旨を通知する障害通知部として機能するシステム制御装置を有することを特徴とする情報処理装置。
（付記７）前記情報処理装置はさらに、
前記システム制御装置に、電力を供給する第２の電源を有し、
前記第２の電源は、前記第１の電源が遮断されている場合においても、前記システム制御装置に対して電力を供給し続けることを特徴とする付記６記載の情報処理装置。
前記システム制御装置に、電力を供給する第２の電源を有し、
前記第２の電源は、前記第１の電源が遮断されている場合においても、前記システム制御装置に対して電力を供給し続けることを特徴とする付記６記載の情報処理装置。
（付記８）前記障害情報管理部は、
前記第１の電源が投入された場合に、前記構成情報と前記第１の記憶部に格納された第１の障害情報に基づいて、前記第２の記憶部に保持する第２の障害情報を復元することを特徴とする付記６又は７記載の情報処理装置。
前記第１の電源が投入された場合に、前記構成情報と前記第１の記憶部に格納された第１の障害情報に基づいて、前記第２の記憶部に保持する第２の障害情報を復元することを特徴とする付記６又は７記載の情報処理装置。
（付記９）前記第１の障害情報は、
前記障害が発生したハードウェア資源を識別する識別情報と、
前記障害が発生したハードウェア資源における障害要因を有することを特徴とする付記６乃至８のいずれかに記載の情報処理装置。
前記障害が発生したハードウェア資源を識別する識別情報と、
前記障害が発生したハードウェア資源における障害要因を有することを特徴とする付記６乃至８のいずれかに記載の情報処理装置。
（付記１０）前記第２の障害情報は、
前記障害が発生したハードウェア資源を識別する識別情報と、
前記障害が発生したハードウェア資源における障害の程度に関する情報を有することを特徴とする付記６乃至９のいずれかに記載の情報処理装置。
前記障害が発生したハードウェア資源を識別する識別情報と、
前記障害が発生したハードウェア資源における障害の程度に関する情報を有することを特徴とする付記６乃至９のいずれかに記載の情報処理装置。
（付記１１）複数のハードウェア資源と前記複数のハードウェア資源を制御するシステム制御装置を有するとともに、第１の電源により動作する情報処理装置の制御方法において、
前記システム制御装置が、前記ハードウェア資源において発生した障害に関する第１の障害情報を、第１の記憶部に保持するステップと、
前記システム制御装置が、前記第１の障害情報とは異なる第２の障害情報を、第２の記憶部に保持するステップと、
前記第１の電源を遮断するステップと、
前記第１の電源を投入するステップと、
前記システム制御装置が、前記情報処理装置に実装されている前記複数のハードウェア資源の構成情報を取得するステップと、
前記システム制御装置が、前記構成情報と前記第１の記憶部に格納された第１の障害情報に基づいて、前記第２の記憶部に保持する第２の障害情報を復元するステップを有することを特徴とする制御方法。
前記システム制御装置が、前記ハードウェア資源において発生した障害に関する第１の障害情報を、第１の記憶部に保持するステップと、
前記システム制御装置が、前記第１の障害情報とは異なる第２の障害情報を、第２の記憶部に保持するステップと、
前記第１の電源を遮断するステップと、
前記第１の電源を投入するステップと、
前記システム制御装置が、前記情報処理装置に実装されている前記複数のハードウェア資源の構成情報を取得するステップと、
前記システム制御装置が、前記構成情報と前記第１の記憶部に格納された第１の障害情報に基づいて、前記第２の記憶部に保持する第２の障害情報を復元するステップを有することを特徴とする制御方法。
（付記１２）複数のハードウェア資源と前記複数のハードウェア資源を制御するシステム制御装置を有するとともに、第１の電源により動作する情報処理装置の制御方法において、
前記システム制御装置が、前記ハードウェア資源において発生した障害に関する第１の障害情報を、第１の記憶部に保持するステップと、
前記システム制御装置が、前記第１の障害情報とは異なる第２の障害情報を、第２の記憶部に保持するステップと、
前記第１の電源を遮断するステップと、
前記第１の電源を投入するステップと、
前記システム制御装置が、前記情報処理装置に実装されている前記複数のハードウェア資源の構成情報を取得するステップと、
前記第１の障害情報と前記第２の障害情報間において不整合が検出された場合には、前記システム制御装置が、障害が発生した旨を通知するステップを有することを特徴とする制御方法。
前記システム制御装置が、前記ハードウェア資源において発生した障害に関する第１の障害情報を、第１の記憶部に保持するステップと、
前記システム制御装置が、前記第１の障害情報とは異なる第２の障害情報を、第２の記憶部に保持するステップと、
前記第１の電源を遮断するステップと、
前記第１の電源を投入するステップと、
前記システム制御装置が、前記情報処理装置に実装されている前記複数のハードウェア資源の構成情報を取得するステップと、
前記第１の障害情報と前記第２の障害情報間において不整合が検出された場合には、前記システム制御装置が、障害が発生した旨を通知するステップを有することを特徴とする制御方法。
（付記１３）複数のハードウェア資源と前記複数のハードウェア資源を制御するシステム制御装置を有するとともに、第１の電源により動作する情報処理装置の制御プログラムにおいて、
前記システム制御装置に、
前記システム制御装置が、前記ハードウェア資源において発生した障害に関する第１の障害情報を、第１の記憶部に保持するステップと、
前記システム制御装置が、前記第１の障害情報とは異なる第２の障害情報を、第２の記憶部に保持するステップと、
前記第１の電源が遮断された後、前記第１の電源投入された場合に、前記システム制御装置が、前記情報処理装置に実装されている前記複数のハードウェア資源の構成情報を取得するステップと、
前記システム制御装置が、前記構成情報と前記第１の記憶部に格納された第１の障害情報に基づいて、前記第２の記憶部に保持する第２の障害情報を復元するステップを実行させることを特徴とする制御プログラム。
前記システム制御装置に、
前記システム制御装置が、前記ハードウェア資源において発生した障害に関する第１の障害情報を、第１の記憶部に保持するステップと、
前記システム制御装置が、前記第１の障害情報とは異なる第２の障害情報を、第２の記憶部に保持するステップと、
前記第１の電源が遮断された後、前記第１の電源投入された場合に、前記システム制御装置が、前記情報処理装置に実装されている前記複数のハードウェア資源の構成情報を取得するステップと、
前記システム制御装置が、前記構成情報と前記第１の記憶部に格納された第１の障害情報に基づいて、前記第２の記憶部に保持する第２の障害情報を復元するステップを実行させることを特徴とする制御プログラム。
（付記１４）複数のハードウェア資源と前記複数のハードウェア資源を制御するシステム制御装置を有するとともに、第１の電源により動作する情報処理装置の制御プログラムにおいて、
前記システム制御装置に、
前記システム制御装置が、前記ハードウェア資源において発生した障害に関する第１の障害情報を、第１の記憶部に保持するステップと、
前記システム制御装置が、前記第１の障害情報とは異なる第２の障害情報を、第２の記憶部に保持するステップと、
前記第１の電源が遮断された後、前記第１の電源投入された場合に、前記システム制御装置が、前記情報処理装置に実装されている前記複数のハードウェア資源の構成情報を取得するステップと、
前記第１の障害情報と前記第２の障害情報間において不整合が検出された場合には、前記システム制御装置が、障害が発生した旨を通知するステップを実行させることを特徴とする制御プログラム。
前記システム制御装置に、
前記システム制御装置が、前記ハードウェア資源において発生した障害に関する第１の障害情報を、第１の記憶部に保持するステップと、
前記システム制御装置が、前記第１の障害情報とは異なる第２の障害情報を、第２の記憶部に保持するステップと、
前記第１の電源が遮断された後、前記第１の電源投入された場合に、前記システム制御装置が、前記情報処理装置に実装されている前記複数のハードウェア資源の構成情報を取得するステップと、
前記第１の障害情報と前記第２の障害情報間において不整合が検出された場合には、前記システム制御装置が、障害が発生した旨を通知するステップを実行させることを特徴とする制御プログラム。
１ 管理サーバ
１０ 情報処理装置
１１ ハードウェア資源
２０ サービスプロセッサ
２１ａ ＤＢ１
２１ｂ ＤＢ２
２１ｃ メモリ
２２ａ ハード監視ソフト
２２ｂ エラー管理ソフト
２２ｃ ｅｖｅｎｔ配信ソフト
２２ｄ 解析プログラム
２２ｅ 通報ソフト
１０ 情報処理装置
１１ ハードウェア資源
２０ サービスプロセッサ
２１ａ ＤＢ１
２１ｂ ＤＢ２
２１ｃ メモリ
２２ａ ハード監視ソフト
２２ｂ エラー管理ソフト
２２ｃ ｅｖｅｎｔ配信ソフト
２２ｄ 解析プログラム
２２ｅ 通報ソフト
Claims (8)
- 複数のハードウェア資源を有するとともに、第１の電源により動作する情報処理装置において、
前記第１の電源が遮断された場合においても、前記ハードウェア資源において発生した障害に関する第１の障害情報を保持する第１の記憶部と、
前記第１の障害情報とは異なる第２の障害情報を保持するとともに、前記第１の電源が遮断された場合に、前記第２の障害情報が保持されない第２の記憶部と、
前記情報処理装置に実装されている前記複数のハードウェア資源の構成情報を取得するハードウェア監視部と、前記構成情報と前記第１の記憶部に格納された第１の障害情報に基づいて、前記第２の記憶部に保持する第２の障害情報を復元する障害情報管理部として機能するシステム制御装置を有することを特徴とする情報処理装置。 - 前記情報処理装置はさらに、
前記システム制御装置に、電力を供給する第２の電源を有し、
前記第２の電源は、前記第１の電源が遮断されている場合においても、前記システム制御装置に対して電力を供給し続けることを特徴とする請求項１記載の情報処理装置。 - 前記障害情報管理部は、
前記第１の電源が投入された場合に、前記構成情報と前記第１の記憶部に格納された第１の障害情報に基づいて、前記第２の記憶部に保持する第２の障害情報を復元することを特徴とする請求項１又は２記載の情報処理装置。 - 前記第１の障害情報は、
前記障害が発生したハードウェア資源を識別する識別情報と、
前記障害が発生したハードウェア資源における障害要因を有することを特徴とする請求項１乃至３のいずれかに記載の情報処理装置。 - 前記第２の障害情報は、
前記障害が発生したハードウェア資源を識別する識別情報と、
前記障害が発生したハードウェア資源における障害の程度に関する情報を有することを特徴とする請求項１乃至４のいずれかに記載の情報処理装置。 - 複数のハードウェア資源を有するとともに、第１の電源により動作する情報処理装置において、
前記第１の電源が遮断された場合においても、前記ハードウェア資源において発生した障害に関する第１の障害情報を保持する第１の記憶部と、
前記第１の障害情報とは異なる第２の障害情報を保持するとともに、前記第１の電源が遮断された場合に、前記第２の障害情報が保持されない第２の記憶部と、
前記第１の障害情報と前記第２の障害情報間の整合性を検査する障害情報管理部と、前記第１の障害情報と前記第２の障害情報間において不整合が検出された場合には、障害が発生した旨を通知する障害通知部として機能するシステム制御装置を有することを特徴とする情報処理装置。 - 複数のハードウェア資源と前記複数のハードウェア資源を制御するシステム制御装置を有するとともに、第１の電源により動作する情報処理装置の制御方法において、
前記システム制御装置が、前記ハードウェア資源において発生した障害に関する第１の障害情報を、第１の記憶部に保持するステップと、
前記システム制御装置が、前記第１の障害情報とは異なる第２の障害情報を、第２の記憶部に保持するステップと、
前記第１の電源を遮断するステップと、
前記第１の電源を投入するステップと、
前記システム制御装置が、前記情報処理装置に実装されている前記複数のハードウェア資源の構成情報を取得するステップと、
前記システム制御装置が、前記構成情報と前記第１の記憶部に格納された第１の障害情報に基づいて、前記第２の記憶部に保持する第２の障害情報を復元するステップを有することを特徴とする制御方法。 - 複数のハードウェア資源と前記複数のハードウェア資源を制御するシステム制御装置を有するとともに、第１の電源により動作する情報処理装置の制御方法において、
前記システム制御装置が、前記ハードウェア資源において発生した障害に関する第１の障害情報を、第１の記憶部に保持するステップと、
前記システム制御装置が、前記第１の障害情報とは異なる第２の障害情報を、第２の記憶部に保持するステップと、
前記第１の電源を遮断するステップと、
前記第１の電源を投入するステップと、
前記システム制御装置が、前記情報処理装置に実装されている前記複数のハードウェア資源の構成情報を取得するステップと、
前記第１の障害情報と前記第２の障害情報間において不整合が検出された場合には、前記システム制御装置が、障害が発生した旨を通知するステップを有することを特徴とする制御方法。
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2008066784A JP2009223582A (ja) | 2008-03-14 | 2008-03-14 | 情報処理装置、情報処理装置の制御方法および制御プログラム |
| US12/402,942 US8065569B2 (en) | 2008-03-14 | 2009-03-12 | Information processing apparatus, information processing apparatus control method and control program |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2008066784A JP2009223582A (ja) | 2008-03-14 | 2008-03-14 | 情報処理装置、情報処理装置の制御方法および制御プログラム |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| JP2009223582A true JP2009223582A (ja) | 2009-10-01 |
Family
ID=41064305
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2008066784A Pending JP2009223582A (ja) | 2008-03-14 | 2008-03-14 | 情報処理装置、情報処理装置の制御方法および制御プログラム |
Country Status (2)
| Country | Link |
|---|---|
| US (1) | US8065569B2 (ja) |
| JP (1) | JP2009223582A (ja) |
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2013152706A (ja) * | 2011-12-26 | 2013-08-08 | Ricoh Co Ltd | 情報処理装置、情報処理方法、及びプログラム |
| JPWO2014006728A1 (ja) * | 2012-07-05 | 2016-06-02 | 富士通株式会社 | 処理装置、処理システム、及びプログラム |
Families Citing this family (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US10157110B2 (en) * | 2012-09-24 | 2018-12-18 | Nec Corporation | Distributed system, server computer, distributed management server, and failure prevention method |
| CN105700996A (zh) * | 2014-11-27 | 2016-06-22 | 迈普通信技术股份有限公司 | 一种日志的输出方法及装置 |
| CN105446863B (zh) * | 2015-11-23 | 2018-02-23 | 上海兆芯集成电路有限公司 | 具有记录能力的电子装置与电路状态记录方法 |
| US10146610B2 (en) * | 2017-04-03 | 2018-12-04 | Dell Products, L.P. | Agentless remediation and recovery |
Family Cites Families (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5317752A (en) * | 1989-12-22 | 1994-05-31 | Tandem Computers Incorporated | Fault-tolerant computer system with auto-restart after power-fall |
| US7089339B2 (en) * | 2001-03-16 | 2006-08-08 | National Semiconductor Corporation | Sharing of functions between an embedded controller and a host processor |
| JP4345334B2 (ja) * | 2003-03-28 | 2009-10-14 | 日本電気株式会社 | 耐障害計算機システム、プログラム並列実行方法およびプログラム |
-
2008
- 2008-03-14 JP JP2008066784A patent/JP2009223582A/ja active Pending
-
2009
- 2009-03-12 US US12/402,942 patent/US8065569B2/en not_active Expired - Fee Related
Cited By (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2013152706A (ja) * | 2011-12-26 | 2013-08-08 | Ricoh Co Ltd | 情報処理装置、情報処理方法、及びプログラム |
| JPWO2014006728A1 (ja) * | 2012-07-05 | 2016-06-02 | 富士通株式会社 | 処理装置、処理システム、及びプログラム |
| US9772914B2 (en) | 2012-07-05 | 2017-09-26 | Fujitsu Limited | Processing apparatus, process system, and non-transitory computer-readable recording medium |
Also Published As
| Publication number | Publication date |
|---|---|
| US20090235112A1 (en) | 2009-09-17 |
| US8065569B2 (en) | 2011-11-22 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US9335998B2 (en) | Multi-core processor system, monitoring control method, and computer product | |
| US8219851B2 (en) | System RAS protection for UMA style memory | |
| US8914488B2 (en) | Method and system for monitoring a monitoring-target process | |
| US20180322016A1 (en) | System and method to capture stored data following system crash | |
| US20100228960A1 (en) | Virtual memory over baseboard management controller | |
| US20170147422A1 (en) | External software fault detection system for distributed multi-cpu architecture | |
| US7624309B2 (en) | Automated client recovery and service ticketing | |
| AU2020285262B2 (en) | Error recovery method and apparatus | |
| US10275330B2 (en) | Computer readable non-transitory recording medium storing pseudo failure generation program, generation method, and generation apparatus | |
| KR101581608B1 (ko) | 프로세서 시스템 | |
| JP2009223582A (ja) | 情報処理装置、情報処理装置の制御方法および制御プログラム | |
| WO2018095107A1 (zh) | 一种bios程序的异常处理方法及装置 | |
| US10102088B2 (en) | Cluster system, server device, cluster system management method, and computer-readable recording medium | |
| JP2010224847A (ja) | 計算機システム及び設定管理方法 | |
| US20150046748A1 (en) | Information processing device and virtual machine control method | |
| US8990630B2 (en) | Server having memory dump function and memory dump acquisition method | |
| TWI518680B (zh) | 維護電腦系統之檔案系統的方法 | |
| US9411666B2 (en) | Anticipatory protection of critical jobs in a computing system | |
| US9195529B2 (en) | Information processing apparatus and activation method | |
| US20220100766A1 (en) | Platform and service disruption avoidance using deployment metadata | |
| US8533331B1 (en) | Method and apparatus for preventing concurrency violation among resources | |
| JP5832408B2 (ja) | 仮想計算機システム及びその制御方法 | |
| US11953985B1 (en) | Dial-home and template based automatic recovery of virtual machine guest operating system | |
| GB2559967A (en) | Method for a computer system and computer system | |
| JP2017151511A (ja) | 情報処理装置、動作ログ取得方法および動作ログ取得プログラム |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20101018 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20111222 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20120724 |
|
| A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20121204 |