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
【課題】不揮発性の記憶部と揮発性の記憶部とを有する情報処理装置において、揮発性の記憶部の障害情報を復元することを課題とする。
【解決手段】情報処理装置は、情報処理装置の電源が遮断された場合においても、情報処理装置に実装されているハードウェア資源において発生した障害要因を保持する第1の記憶部と、当該障害要因とは異なる障害状態を保持し、情報処理装置の電源が遮断された場合に、障害状態が保持されない第2の記憶部とを有し、サービスプロセッサの電源が起動された場合に、ハードウェア資源の構成情報と故障要因とに基づいて故障状態を復元するとともに、第1の記憶部と第2の記憶部との整合性を検査して、不整合が検出された場合に、障害が発生した旨を接続される管理サーバ装置などに通知する。
【選択図】 図2
【解決手段】情報処理装置は、情報処理装置の電源が遮断された場合においても、情報処理装置に実装されているハードウェア資源において発生した障害要因を保持する第1の記憶部と、当該障害要因とは異なる障害状態を保持し、情報処理装置の電源が遮断された場合に、障害状態が保持されない第2の記憶部とを有し、サービスプロセッサの電源が起動された場合に、ハードウェア資源の構成情報と故障要因とに基づいて故障状態を復元するとともに、第1の記憶部と第2の記憶部との整合性を検査して、不整合が検出された場合に、障害が発生した旨を接続される管理サーバ装置などに通知する。
【選択図】 図2
Description
この発明は、複数のハードウェア資源を有するとともに、第1の電源により動作する情報処理装置およびその制御方法ならびに制御プログラムに関する。
従来より、複数のハードウェア資源と、CPU(Central Processing Unit)や限られた領域のメモリなどを有して当該ハードウェア資源を管理するサービスプロセッサと、当該サービスプロセッサ上で動作するファームウェアとから構成される情報処理装置が多く利用されている。この情報処理装置は、当該情報処理装置上のハードウェア資源を監視して、当該ハードウェア資源に障害が発生した場合に、障害情報を管理サーバに対して通知する。また、情報処理装置は、サービスプロセッサ上での故障状態を表示する機能と、ハードウェア資源のパーティショニングや部品の活***換メニューなどの管理ツール機能と、ログデータの保存を行なう領域とが搭載されていないために、接続される管理サーバ装置のサーバ管理者によって、GUI(Graphical User Interface)またはコマンドラインなどを用いて上記した故障状態や領域などが管理されている(非特許文献1〜3参照)。
ここで、上記した情報処理装置において、特に、ハードウェア資源の障害情報を管理サーバに通知する際の処理を、図19を用いて説明する。図19に示すように、情報処理装置は、当該情報処理装置を管理する管理サーバに接続されており、ハードウェア資源と、当該ハードウェア資源の故障状態を監視するサービスプロセッサと、故障が発生したハードウェア資源の故障要因が格納される不揮発性のハードウェアであるDB1と、故障が発生したハードウェア資源の故障状態が格納される揮発性のハードウェアであるDB2と、故障情報復元および通知のための処理を行なう解析プログラム/ハード監視ソフトと、event配信ソフトと、エラー管理ソフトと、通報ソフトとを有する。ここで用いられる不揮発性のハードウェアであるDB1は、NVRAMやHDDなどのハードウェアにより構成され、情報処理装置本体の電源が切断された場合でも故障情報を保持する。また、揮発性のハードウェアであるDB2は、DRAMやSRAMなどのハードウェアにより構成され、DB1とは異なり、情報処理装置本体の電源が切断された場合に故障情報を消失して、情報処理装置本体が再起動された場合に故障情報を保持する。
なお、DB1とDB2との2つのDBから構成される理由は、より多くの記憶領域を必要とするDB1にbit単価が安い不揮発性記憶装置を利用し、当該DB1よりも少ない記憶領域を必要とするDB2にbit単価が高い揮発性記憶装置を利用して、サービスプロセッサのハードウェアにかかるコストを削減するためである。
具体的に説明すると、情報処理装置は、サービスプロセッサにより監視が行なわれており(図19の(1)参照)、当該サービスプロセッサを構成する機能が全て利用可能な状態にある。このような状態において、解析プログラム/ハード監視ソフトは、ハードウェア資源において故障が発生すると、割り込みまたはポーリング監視(polling)によって故障情報の通知を受け付けて(図19の(2)参照)、故障が発生したハードウェア資源の物理位置と故障要因とをDB1に格納し(図19の(3)参照)、故障通知イベントの送信依頼をevent配信ソフトに対して行なう(図19の(4)参照)。
この解析プログラム/ハード監視ソフトがevent配信ソフトに対して渡す情報は、図20に示すように、128byte固定のバイナリデータとなっており、発生時刻、検出元、故障コンポーネント名および故障要因文字列のフォーマットから構成される。また、各フォーマットの内容および故障コンポーネント名は、図21に示すような内容となる。なお、図20は、従来技術に係るハード監視ソフトがevent配信ソフトに渡す情報の例を示す図であり、図21は、従来技術に係るハード監視ソフトがevent配信ソフトに渡す情報の内容を示す図である。
そして、解析プログラム/ハード監視ソフトにより故障通知イベントの送信依頼を受け付けたevent配信ソフトは、当該故障通知イベントをエラー管理ソフトに対して通知する(図19の(5)参照)。このevent配信ソフトがエラー管理ソフトに対して渡す情報は、図22に示すように、128byte固定のバイナリデータとなっており、発生時刻、検出元、故障コンポーネント名および故障要因文字列のフォーマットから構成される。また、各フォーマットの内容および故障コンポーネント名の内容は、図23に示すような内容となる。なお、図22は、従来技術に係るevent配信ソフトがエラー管理ソフトに渡す情報の例を示す図であり、図23は、従来技術に係るevent配信ソフトがエラー管理ソフトに渡す情報の内容を示す図である。
続いて、エラー管理ソフトは、event配信ソフトから故障通知イベントを受け付けると、故障要因が格納されているDB1を参照して、当該故障要因からハードウェア資源の故障状態を導出する(図19の(6)参照)。その後、エラー管理ソフトは、DB1の故障要因から導出されたハードウェア資源の故障状態をDB2に格納し(図19の(7)参照)、通報ソフトに対して故障情報を通知する(図19の(8)参照)。このエラー管理ソフトが通報ソフトに対して渡す情報は、図24に示すように、128byte固定のバイナリデータとなっており、発生時刻、検出元、故障コンポーネント名および故障要因文字列から構成される。また、各フォーマットの内容および故障コンポーネント名の内容は、図25に示すような内容となる。なお、図24は、従来技術に係るエラー管理ソフトが通報ソフトに渡す情報の例を示す図であり、図25は、従来技術に係るエラー管理ソフトが通報ソフトに渡す情報の内容を示す図である。
そして、通報ソフトは、情報処理装置を管理する管理サーバに対して故障情報を通知する(図19の(9)参照)。その後、システム管理者は、情報処理装置により通知された故障情報を管理サーバにおいて確認し、当該情報処理装置の設定や状態などを把握して保守作業を行なう。なお、図19は、従来技術に係る情報処理装置による故障情報通知処理を説明するための図である。
また、最近では、CPUの処理速度向上や記憶装置の低価格化などによって、管理サーバを必要としないサービスプロセッサが搭載された情報処理装置が提供されつつある。この情報処理装置は、上記した管理サーバの機能を情報処理装置に搭載するために、ソフトウェアの数および当該ソフトウェアを動作させるためのハードウェアの数が増加するとともに、マルチタスクなどの機能を備えたOS(Operating System)が必要となる。
"システム監視機構(SCF:System Control Facility)"、[online]、[平成19年12月19日検索]、インターネット<http://primeserver.fujitsu.com/primepower/technology/reliance/monitor/>
"ハイエンドサーバ管理コンソール(SMC:System Management Console)"、[online]、[平成19年12月19日検索]、インターネット<http://primeserver.fujitsu.com/primepower/products/lineup/pp2500/point.html>
"Sun Enterprise 10000 SSP 3.5 User Guide"、[online]、[平成19年12月19日検索]、インターネット<http://dlc.sun.com/pdf/816-3624-10/816-3624-10.pdf>
しかしながら、上記した従来の技術は、不揮発性の記憶部と揮発性の記憶部とを有する情報処理装置において、揮発性の記憶部の障害情報を復元することができないという課題があった。
具体的に、非特許文献1〜3における情報処理装置は、故障要因が格納されるDB1から故障状態が格納されるDB2に障害情報を復元するまでに、サービスプロセッサ上のソフトウェアまたはハードウェア要因による障害が発生した場合に、サービスプロセッサがハングアップまたは再起動するので、障害情報の復元処理が中断されてしまい、不揮発性の記憶部の障害情報に基づいて、揮発性の記憶部の障害情報を復元することができない。
また、管理サーバを必要としないサービスプロセッサが搭載された情報処理装置は、複数の機能追加により、サービスプロセッサが障害情報を検出してから通報ソフトに障害情報を通知するまでに、複数のソフトウェアコンポーネントや記憶領域などを通過するので、故障情報を喪失してしまう危険性が高くなる。また、情報処理装置は、OSの高度化による並列タスクの増加により故障情報を喪失してしまう危険性が高くなる。この結果、不揮発性の記憶部の障害情報に基づいて、揮発性の記憶部の障害情報を復元することができない。なお、故障情報の喪失を防止するための解決方法としては、サービスプロセッサを複数搭載することで一定の効果が得られるが、当該複数のサービスプロセッサを搭載するためのコストがかかってしまい、さらに、複数のサービスプロセッサを搭載し、ソフトバグによって障害情報復元処理が中断された場合には、障害情報喪失を防止するための根本的な解決とはならない。
そこで、この発明は、上述した従来技術の課題を解決するためになされたものであり、不揮発性の記憶部と揮発性の記憶部とを有する情報処理装置において、揮発性の記憶部の障害情報を復元することが可能である情報処理装置を提供することを目的とする。
上述した課題を解決し、目的を達成するため、本願の開示する情報処理装置は、複数のハードウェア資源を有するとともに、第1の電源により動作する情報処理装置において、前記第1の電源が遮断された場合においても、前記ハードウェア資源において発生した障害に関する第1の障害情報を保持する第1の記憶部と、前記第1の障害情報とは異なる第2の障害情報を保持するとともに、前記第1の電源が遮断された場合に、前記第2の障害情報が保持されない第2の記憶部と、前記情報処理装置に実装されている前記複数のハードウェア資源の構成情報を取得するハードウェア監視部と、前記構成情報と前記第1の記憶部に格納された第1の障害情報に基づいて、前記第2の記憶部に保持する第2の障害情報を復元する障害情報管理部として機能するシステム制御装置を有することを要件とする。
本願の開示する情報処理装置によれば、不揮発性の記憶部と揮発性の記憶部とを有する情報処理装置において、揮発性の記憶部の障害情報を復元することが可能であるという効果を奏する。
以下に添付図面を参照して、この発明に係る情報処理装置の実施例を詳細に説明する。なお、以下では、本発明に係る情報処理装置の概要および特徴、情報処理装置の構成および処理の流れを順に説明し、最後に本実施例による効果を説明する。
[概要および特徴]
最初に、図1を用いて、実施例1に係る情報処理装置の概要および特徴を説明する。図1は、実施例1に係る情報処理装置の概要および特徴を示す図である。
最初に、図1を用いて、実施例1に係る情報処理装置の概要および特徴を説明する。図1は、実施例1に係る情報処理装置の概要および特徴を示す図である。
この情報処理装置は、当該情報処理装置を管理する管理サーバと接続されており、情報処理装置本体の運用や異常監視などを行なうサービスプロセッサと、SystemBoard、I/OBoard、CPUModuleなどから構成されるハードウェア資源とを有する。また、サービスプロセッサは、DB1およびDB2を用いて障害情報の復元や通知などの処理を行なう解析プログラム、エラー管理ソフト、ハード監視ソフト、event配信ソフトおよび通報ソフトから構成される。
このような構成において、情報処理装置は、複数のハードウェア資源を有するとともに、第1の電源により動作することを概要とするものであり、特に、不揮発性の記憶部と揮発性の記憶部とを有する情報処理装置において、揮発性の記憶部の障害情報を復元することが可能である点を主たる特徴とする。
この主たる特徴について具体的に説明すると、情報処理装置は、第1の電源が遮断された場合においても、ハードウェア資源において発生した障害に関する第1の障害情報を保持する第1の記憶部としてのDB1と、第1の障害情報とは異なる第2の障害情報を保持するとともに、第1の電源が遮断された場合に、第2の障害情報が保持されない第2の記憶部としてのDB2とを有する。
例えば、情報処理装置は、故障が発生したハードウェア資源の故障要因が格納される不揮発性のハードウェアであり、情報処理装置本体の電源が切断された場合でも故障情報を保持するDB1を有する。また、例えば、情報処理装置は、DB1の情報に基づいて故障が発生したハードウェア資源の故障状態が格納される揮発性のハードウェアであり、DB1とは異なり、情報処理装置本体の電源が切断された場合に故障情報を消失し、情報処理装置本体が再起動された場合に故障情報を保持するDB2を有する。
このような状態において、情報処理装置は、当該情報処理装置に実装されている複数のハードウェア資源の構成情報を取得し、取得された構成情報と第1の記憶部に格納された第1の障害情報に基づいて、第2の記憶部に保持する第2の障害情報を復元する。
具体的に例を挙げると、情報処理装置は、当該情報処理装置に実装されているSystemBoard、I/OBoardまたはCPUModuleなどの複数のハードウェア資源の構成情報を取得する。そして、情報処理装置は、例えば、情報処理装置の電源が投入された場合に、取得された構成情報と、当該構成情報に対応し、DB1に保持されるハードウェア資源の物理位置や故障要因などの障害情報とに基づいて、DB2に保持されるハードウェア資源の物理位置や故障状態などの障害情報を復元する。
このようなことから、実施例1に係る複数のハードウェア資源を有するとともに、第1の電源により動作する情報処理装置は、情報処理装置に実装されている複数のハードウェア資源の構成情報を取得し、取得された構成情報とDB1に格納された障害情報とに基づいて、DB2に保持する障害情報を復元することができる結果、不揮発性の記憶部と揮発性の記憶部とを有する情報処理装置において、揮発性の記憶部の障害情報を復元することが可能である。
つまり、情報処理装置は、サービスプロセッサの起動時においても、故障状態を退避するための領域を必要とせず、少ない資源で故障状態を復元することができる結果、不揮発性の記憶部と揮発性の記憶部とを有する情報処理装置において、揮発性の記憶部の障害情報を復元することが可能である。
[実施例1に係る情報処理装置の構成]
次に、図2を用いて、実施例1に係る情報処理装置の構成を説明する。図2は、実施例1に係る情報処理装置の構成を示す図である。
次に、図2を用いて、実施例1に係る情報処理装置の構成を説明する。図2は、実施例1に係る情報処理装置の構成を示す図である。
図2に示すように、情報処理装置10は、ハードウェア資源11と、サービスプロセッサ20とから構成され、当該情報処理装置10や複数のサーバ装置などの状態を維持および管理する管理サーバ1と接続されており、当該情報処理装置10の常駐電源が投入された場合に起動する。
ハードウェア資源11は、情報処理装置10の主機能を担う部品が搭載されたSystemBoard、情報処理装置10と当該情報処理装置10に接続される装置との入出力ポートの役割を担うI/OBoard、および、プログラムの実行や演算処理などを行なうCPUModuleなどの複数のハードウェア資源から構成される。
サービスプロセッサ20は、DB1、DB2、メモリ21c、ハード監視ソフト22a、エラー管理ソフト22b、event配信ソフト22c、解析プログラム22dおよび通報ソフト22eから構成され、情報処理装置10の運用や異常監視などを行なう。また、サービスプロセッサ20は、情報処理装置10の常駐電源が投入された場合に起動する。そして、サービスプロセッサ20は、情報処理装置10の常駐電源とは異なる電源を有しており、当該サービスプロセッサ20に異常が発生した場合に自動的に再起動する。
DB1は、第1の電源が遮断された場合においても、ハードウェア資源において発生した障害に関する第1の障害情報を保持する。そして、DB1に保持される第1の障害情報は、障害が発生したハードウェア資源を識別する識別情報と、障害が発生したハードウェア資源における障害要因を有する。
例えば、DB1は、情報処理装置の電源が遮断された場合においても、ハードウェア資源11において発生した障害に関する障害情報を保持する。そして、DB1に保持される障害情報は、図3に示すように、障害が発生したハードウェア資源11「CPUModule」を識別する識別情報と、障害が発生したハードウェア資源11「CPUModule」における障害要因「CORE#0 error」とを有する。なお、図3は、実施例1に係るDB1に保持されるCPUModuleの障害情報のデータフォーマット例である。
また、例えば、DB1に保持される障害情報は、図4に示すように、障害が発生したハードウェア資源「SystemBoard」を識別する識別情報と、障害が発生したハードウェア資源「SystemBoard」における障害要因「SC#0 error」とを有する。また、図4に示したSC(System Controller)は、SystemBoard上に1個以上搭載され、CPU、メモリ、I/Oなどを接続する役割を担う。また、図4に示したMC(Memory Controller)は、SystemBoard上に1個以上搭載され、DIMMを制御する役割を担う。また、IOBC(I/O Board Controller)は、PCIバスとSCとを接続する役割を担う。なお、図4は、実施例1に係るDB1に保持されるSystemBoardの障害情報のデータフォーマット例である。
また、例えば、DB1に保持される障害情報は、図5に示すように、障害が発生したハードウェア資源「I/OBoard」を識別する識別情報と、障害が発生したハードウェア資源「I/OBoard」における障害要因「IOBC#0 error」とを有する。なお、図5は、実施例1に係るDB1に保持されるI/OBoardの障害情報のデータフォーマット例である。
DB2は、第1の障害情報とは異なる第2の障害情報を保持するとともに、第1の電源が遮断された場合に、第2の障害情報が保持されない。そして、DB2に保持される障害情報は、障害が発生したハードウェア資源を識別する識別情報と、障害が発生したハードウェア資源における障害の程度に関する情報を有する。
例えば、DB2は、DB1に保持される障害情報とは異なる障害情報を保持するとともに、情報処理装置の電源が遮断された場合に、当該障害情報が保持されない。このDB2に保持される障害情報は、図6に示すように、障害が発生したハードウェア資源11「CPUModule」を識別する識別情報と、障害が発生したハードウェア資源11「CPUModule」における障害の程度に関する情報「Alarm」とを有する。なお、図6は、実施例1に係るDB2に保持されるCPUModuleの障害情報のデータフォーマット例である。
メモリ21cは、ハードウェア資源11の実装情報を保持している。例えば、メモリ21cは、ハードウェア資源11である情報処理装置10の主機能を担う部品が搭載された「SystemBoard」、情報処理装置10と当該情報処理装置10に接続される装置との入出力ポートの役割を担う「I/OBoard」、プログラムの実行や演算処理などを行なう「CPUModule」などの実装情報を保持している。
ハード監視ソフト22aは、情報処理装置10に実装されている複数のハードウェア資源11の構成情報を取得する。具体的に例を挙げると、ハード監視ソフト22aは、情報処理装置10の電源が投入された場合、または、サービスプロセッサ20が再起動された場合に、情報処理装置10に実装されている複数のハードウェア資源11「SystemBoard」、「I/OBoard」、「CPUModule」などの実装情報をメモリ21cから取得する。また、ハード監視ソフト22aは、情報処理装置10の電源やファンなどのハードウェアの故障を解析して、当該電源やファンなどの故障位置と故障要因とを特定し、DB1に格納する。また、ハード監視ソフト22aは、エラー管理ソフト22bのライブラリを呼び出して、実装されているハードウェア資源11の単位でDB2に保持される障害情報の復元を依頼する。
エラー管理ソフト22bは、構成情報とDB1に保持された障害情報に基づいて、DB2に保持する障害情報を復元する。また、エラー管理ソフト22bは、DB1に保持された障害情報とDB2に保持された障害情報間の整合性を検査する。
上記した例で具体的に例を挙げると、エラー管理ソフト22bは、ハード監視ソフト22aによりDB2に保持される障害情報の復元を依頼されると、DB1に保持されたハードウェア資源11の故障情報に対応したDB2の領域を参照して、故障状態の有無を検査する。そして、エラー管理ソフト22bは、DB1を参照して、現状の故障要因を取得する。
ここで、エラー管理ソフト22bにより行なわれる故障要因の検査は、DB1(図3参照)の領域にbitが立っているか否かを参照する。例えば、CPUModuleにおいて、L2cacheのWAY#0故障が発生した場合には、図7に示すように、DB1のbit19領域に「1」が立っている。また、例えば、CPUModuleにおいて、L2cacheのWAY#0故障およびL2cacheのWAY#1故障が発生した場合には、図8に示すように、DB1のbit18領域およびbit19領域に「1」が立っている。なお、図7は、実施例1に係るCPUModuleにおいて、L2cacheのWAY#0故障が発生した場合のDB1の例を示す図であり、図8は、実施例1に係るCPUModuleにおいて、L2cacheのWAY#0故障およびL2cacheのWAY#1故障が発生した場合のDB1の例を示す図である。
続いて、エラー管理ソフト22bは、DB2を参照して、現状の故障状態を取得する。ここで、エラー管理ソフト22bにより行なわれる故障状態の取得は、DB1(図3参照)の領域を参照して故障状態を取得する。例えば、エラー管理ソフト22bは、CPUModuleにおいて、L2cacheの一部が故障した場合に(図7参照)、図9に示すように、DB1のbit6領域に「1」が立っているので、当該bit6領域に保持される故障状態である「Warning」を取得する。なお、図9は、実施例1に係るCPUModuleにおいて、L2cacheの一部が故障した場合のDB2の例を示す図である。
その後、エラー管理ソフト22bは、取得された故障要因と故障状態とを用いて、図10に示すように、DB1とDB2との整合性検査を行なう。そして、エラー管理ソフト22bは、整合性検査によりDB1とDB2とが不整合であると判定された場合に、DB1の障害情報に基づいてDB2の障害情報を復元する。
ここで、DB1とDB2との整合性検査内容(図10に示した項番1〜項番12)を説明する。図10は、実施例1に係るDB1とDB2との整合性検査内容を説明するための図である。また、揮発性であるDB2の故障状態は、情報処理装置10の電源が投入されてサービスプロセッサ20が起動された場合に、全て「0」に初期化される。また、故障状態は、より重大度が高い状態としてレベルの高い方から、「Alarm(完全故障)」、「Warning(部分故障)」、「Normal(正常)」とする。また、以下の整合性検査内容の説明においては、ハードウェアCPU#0の場合を例に挙げて説明する。なお、故障状態の判定ロジックは、エラー管理ソフト22bにおいてハードコーディングされている。
(項番1)
項番1では、サービスプロセッサ20の起動契機が情報処理装置10の電源投入によるものであり、DB1の故障要因がない状態である。このような状態において、エラー管理ソフト22bは、サービスプロセッサ20が起動されると、DB1のbit領域から故障要因を取得する。そして、エラー管理ソフト22bは、取得された故障要因が存在しないために、DB2に書き込む(復元する)故障状態を「Normal」と仮判定する。続いて、エラー管理ソフト22bは、DB2からCPU#0の故障状態「Normal」を取得し、取得された故障状態「Normal」と仮判定された故障状態「Normal」とを比較する。
項番1では、サービスプロセッサ20の起動契機が情報処理装置10の電源投入によるものであり、DB1の故障要因がない状態である。このような状態において、エラー管理ソフト22bは、サービスプロセッサ20が起動されると、DB1のbit領域から故障要因を取得する。そして、エラー管理ソフト22bは、取得された故障要因が存在しないために、DB2に書き込む(復元する)故障状態を「Normal」と仮判定する。続いて、エラー管理ソフト22bは、DB2からCPU#0の故障状態「Normal」を取得し、取得された故障状態「Normal」と仮判定された故障状態「Normal」とを比較する。
その後、エラー管理ソフト22bは、故障状態の比較の結果、DB1とDB2との故障状態に差分がないので、仮判定された故障状態「Normal」をDB2に書き込む(復元する)ことなく処理を終了する。
(項番2)
項番2では、サービスプロセッサ20の起動契機が再起動によるものであり、DB1の故障要因がない状態である。このような状態において、エラー管理ソフト22bは、サービスプロセッサ20が再起動されると、DB1のbit領域から故障要因を取得する。そして、エラー管理ソフト22bは、取得された故障要因が存在しないために、DB2に書き込む(復元する)故障状態を「Normal」と仮判定する。続いて、エラー管理ソフト22bは、DB2からCPU#0の故障状態「Normal」を取得し、取得された故障状態「Normal」と仮判定された故障状態「Normal」とを比較する。
項番2では、サービスプロセッサ20の起動契機が再起動によるものであり、DB1の故障要因がない状態である。このような状態において、エラー管理ソフト22bは、サービスプロセッサ20が再起動されると、DB1のbit領域から故障要因を取得する。そして、エラー管理ソフト22bは、取得された故障要因が存在しないために、DB2に書き込む(復元する)故障状態を「Normal」と仮判定する。続いて、エラー管理ソフト22bは、DB2からCPU#0の故障状態「Normal」を取得し、取得された故障状態「Normal」と仮判定された故障状態「Normal」とを比較する。
その後、エラー管理ソフト22bは、故障状態の比較の結果、DB1とDB2との故障状態に差分がないので、仮判定された故障状態「Normal」をDB2に書き込む(復元する)ことなく処理を終了する。
(項番3)
項番3では、サービスプロセッサ20の起動契機が再起動によるものであり、DB1の故障要因がない状態である。このような状態において、エラー管理ソフト22bは、サービスプロセッサ20が再起動されると、DB1のbit領域から故障要因を取得する。そして、エラー管理ソフト22bは、取得された故障要因が存在しないために、DB2に書き込む(復元する)故障状態を「Normal」と仮判定する。続いて、エラー管理ソフト22bは、DB2からCPU#0の故障状態「Warning」を取得し、取得された故障状態「Warning」と仮判定された故障状態「Normal」とを比較する。
項番3では、サービスプロセッサ20の起動契機が再起動によるものであり、DB1の故障要因がない状態である。このような状態において、エラー管理ソフト22bは、サービスプロセッサ20が再起動されると、DB1のbit領域から故障要因を取得する。そして、エラー管理ソフト22bは、取得された故障要因が存在しないために、DB2に書き込む(復元する)故障状態を「Normal」と仮判定する。続いて、エラー管理ソフト22bは、DB2からCPU#0の故障状態「Warning」を取得し、取得された故障状態「Warning」と仮判定された故障状態「Normal」とを比較する。
その後、エラー管理ソフト22bは、故障状態の比較の結果、DB1とDB2との故障状態に差分があるが、DB1から仮判定された故障状態「Normal」とDB2から取得された故障状態「Warning」とのうち、より重大度が高い状態をハードウェアCPU#0の状態とするので、仮判定された故障状態「Normal」をDB2に書き込む(復元する)ことなく処理を終了する。つまり、DB1の故障状態を示すDB2の内容は、再起動前の故障状態である「Warning」が保持される。
(項番4)
項番4では、サービスプロセッサ20の起動契機が再起動によるものであり、DB1の故障要因がない状態である。このような状態において、エラー管理ソフト22bは、サービスプロセッサ20が再起動されると、DB1のbit領域から故障要因を取得する。そして、エラー管理ソフト22bは、取得された故障要因が存在しないために、DB2に書き込む(復元する)故障状態を「Normal」と仮判定する。続いて、エラー管理ソフト22bは、DB2からCPU#0の故障状態「Alarm」を取得し、取得された故障状態「Alarm」と仮判定された故障状態「Normal」とを比較する。
項番4では、サービスプロセッサ20の起動契機が再起動によるものであり、DB1の故障要因がない状態である。このような状態において、エラー管理ソフト22bは、サービスプロセッサ20が再起動されると、DB1のbit領域から故障要因を取得する。そして、エラー管理ソフト22bは、取得された故障要因が存在しないために、DB2に書き込む(復元する)故障状態を「Normal」と仮判定する。続いて、エラー管理ソフト22bは、DB2からCPU#0の故障状態「Alarm」を取得し、取得された故障状態「Alarm」と仮判定された故障状態「Normal」とを比較する。
その後、エラー管理ソフト22bは、故障状態の比較の結果、DB1とDB2との故障状態に差分があるが、DB1から仮判定された故障状態「Normal」とDB2から取得された故障状態「Alarm」とのうち、より重大度が高い状態をハードウェアCPU#0の状態とするので、仮判定された故障状態「Normal」をDB2に書き込む(復元する)ことなく処理を終了する。つまり、DB1の故障状態を示すDB2の内容は、再起動前の故障状態である「Alarm」が保持される。
(項番5)
項番5では、サービスプロセッサ20の起動契機が情報処理装置10の電源投入によるものであり、DB1の故障要因が部分故障を示す「Waring要因」となる状態である。このような状態において、エラー管理ソフト22bは、サービスプロセッサ20が起動されると、DB1のbit領域から故障要因を取得する。そして、エラー管理ソフト22bは、取得された故障要因として、CPU#0領域「CORE#1 TLB Buffer error(bit28)」に「1」が立っている場合に、DB2に書き込む(復元する)故障状態を「Warning」と仮判定する。続いて、エラー管理ソフト22bは、DB2からCPU#0の故障状態「Normal」を取得し、取得された故障状態「Normal」と仮判定された故障状態「Warning」とを比較する。
項番5では、サービスプロセッサ20の起動契機が情報処理装置10の電源投入によるものであり、DB1の故障要因が部分故障を示す「Waring要因」となる状態である。このような状態において、エラー管理ソフト22bは、サービスプロセッサ20が起動されると、DB1のbit領域から故障要因を取得する。そして、エラー管理ソフト22bは、取得された故障要因として、CPU#0領域「CORE#1 TLB Buffer error(bit28)」に「1」が立っている場合に、DB2に書き込む(復元する)故障状態を「Warning」と仮判定する。続いて、エラー管理ソフト22bは、DB2からCPU#0の故障状態「Normal」を取得し、取得された故障状態「Normal」と仮判定された故障状態「Warning」とを比較する。
その後、エラー管理ソフト22bは、故障状態の比較の結果、DB1とDB2との故障状態に差分があり、さらに、DB1から仮判定された故障状態「Warning」の方が重大度が高い状態であるので、仮判定された故障状態「Warning」をDB2に書き込んで(復元して)処理を終了する。つまり、DB1の故障状態を示すDB2の内容は、DB1の故障要因に基づいて復元された故障状態である「Warning」が保持される。
ここで、エラー管理ソフト22bは、サービスプロセッサ20の起動によってDB2が全て「0」に初期化されているために、イベントのロストによる不整合であるか、または、DB2の初期化による不整合であるかを判定することができない。しかしながら、エラー管理ソフト22bは、イベントのロストによる不整合ではなく、DB2の初期化による不整合であることを優先するとともに、後述するevent配信ソフト22cや通報ソフト22eなどへの通知がサービスプロセッサ20の起動前に行なわれていることとして判定する結果、event配信ソフト22cに不整合検出イベントを通知することはない。
(項番6)
項番6では、サービスプロセッサ20の起動契機が再起動によるものであり、DB1の故障要因が部分故障を示す「Warning要因」となる状態である。このような状態において、エラー管理ソフト22bは、サービスプロセッサ20が再起動されると、DB1のbit領域から故障要因を取得する。そして、エラー管理ソフト22bは、取得された故障要因として、CPU#0領域「CORE#1 TLB Buffer error(bit28)」に「1」が立っている場合に、DB2に書き込む(復元する)故障状態を「Warning」と仮判定する。続いて、エラー管理ソフト22bは、DB2からCPU#0の故障状態「Normal」を取得し、取得された故障状態「Normal」と仮判定された故障状態「Warning」とを比較する。
項番6では、サービスプロセッサ20の起動契機が再起動によるものであり、DB1の故障要因が部分故障を示す「Warning要因」となる状態である。このような状態において、エラー管理ソフト22bは、サービスプロセッサ20が再起動されると、DB1のbit領域から故障要因を取得する。そして、エラー管理ソフト22bは、取得された故障要因として、CPU#0領域「CORE#1 TLB Buffer error(bit28)」に「1」が立っている場合に、DB2に書き込む(復元する)故障状態を「Warning」と仮判定する。続いて、エラー管理ソフト22bは、DB2からCPU#0の故障状態「Normal」を取得し、取得された故障状態「Normal」と仮判定された故障状態「Warning」とを比較する。
その後、エラー管理ソフト22bは、故障状態の比較の結果、DB1とDB2との故障状態に差分があり、さらに、DB1から仮判定された故障状態「Warning」の方が重大度が高い状態であるので、仮判定された故障状態「Warning」をDB2に書き込む(復元する)。つまり、DB1の故障状態を示すDB2の内容は、DB1の故障要因に基づいて復元された故障状態である「Warning」が保持される。
そして、エラー管理ソフト22bは、イベントが途中でロストした可能性があると判定して、後述するevent配信ソフト22cに対して不整合検出イベントを通知する。つまり、エラー管理ソフト22bは、サービスプロセッサ20の再起動によりDB2の故障状態が再起動前の故障状態であるはずにもかかわらず、DB1とDB2とで不整合が発生しているので、イベントが途中でロストした可能性があると判定する。
このエラー管理ソフト22bがevent配信ソフト22cに対して渡す情報は、図11に示すように、128byte固定のバイナリデータとなっており、ハード監視ソフト22aまたは解析プログラム22dにより異常検出された時刻を示す「発生時刻」、サービスプロセッサ20再起動前のDB2の状態を示す「旧状態」、不整合検出後のDB2の状態を示す「新状態」、不整合が検出されたコンポーネント識別子を示す「検出元」、故障位置を表す文字列を示す「故障コンポーネント名」および不整合検出を表す固定文字列を示す「故障要因文字列」から構成される。また、各フォーマットの内容および故障コンポーネント名の内容は、図12に示すような内容となる。なお、図11は、実施例1に係るエラー管理ソフト22bがevent配信ソフト22cに渡す情報の例を示す図であり、図12は、実施例1に係るエラー管理ソフト22bがevent配信ソフト22cに渡す情報の内容を示す図である。
(項番7)
項番7では、サービスプロセッサ20の起動契機が再起動によるものであり、DB1の故障要因が部分故障を示す「Warning要因」となる状態である。このような状態において、エラー管理ソフト22bは、サービスプロセッサ20が再起動されると、DB1のbit領域から故障要因を取得する。そして、エラー管理ソフト22bは、取得された故障要因として、CPU#0領域「CORE#1 TLB Buffer error(bit28)」に「1」が立っている場合に、DB2に書き込む(復元する)故障状態を「Warning」と仮判定する。続いて、エラー管理ソフト22bは、DB2からCPU#0の故障状態「Warning」を取得し、取得された故障状態「Warning」と仮判定された故障状態「Warning」とを比較する。
項番7では、サービスプロセッサ20の起動契機が再起動によるものであり、DB1の故障要因が部分故障を示す「Warning要因」となる状態である。このような状態において、エラー管理ソフト22bは、サービスプロセッサ20が再起動されると、DB1のbit領域から故障要因を取得する。そして、エラー管理ソフト22bは、取得された故障要因として、CPU#0領域「CORE#1 TLB Buffer error(bit28)」に「1」が立っている場合に、DB2に書き込む(復元する)故障状態を「Warning」と仮判定する。続いて、エラー管理ソフト22bは、DB2からCPU#0の故障状態「Warning」を取得し、取得された故障状態「Warning」と仮判定された故障状態「Warning」とを比較する。
その後、エラー管理ソフト22bは、故障状態の比較の結果、DB1とDB2との故障状態に差分がないので、仮判定された故障状態「Warning」をDB2に書き込む(復元する)ことなく処理を終了する。
(項番8)
項番8では、サービスプロセッサ20の起動契機が再起動によるものであり、DB1の故障要因が部分故障を示す「Warning要因」となる状態である。このような状態において、エラー管理ソフト22bは、サービスプロセッサ20が再起動されると、DB1のbit領域から故障要因を取得する。そして、エラー管理ソフト22bは、取得された故障要因として、CPU#0領域「CORE#1 TLB Buffer error(bit28)」に「1」が立っている場合に、DB2に書き込む(復元する)故障状態を「Warning」と仮判定する。続いて、エラー管理ソフト22bは、DB2からCPU#0の故障状態「Alarm」を取得し、取得された故障状態「Alarm」と仮判定された故障状態「Warning」とを比較する。
項番8では、サービスプロセッサ20の起動契機が再起動によるものであり、DB1の故障要因が部分故障を示す「Warning要因」となる状態である。このような状態において、エラー管理ソフト22bは、サービスプロセッサ20が再起動されると、DB1のbit領域から故障要因を取得する。そして、エラー管理ソフト22bは、取得された故障要因として、CPU#0領域「CORE#1 TLB Buffer error(bit28)」に「1」が立っている場合に、DB2に書き込む(復元する)故障状態を「Warning」と仮判定する。続いて、エラー管理ソフト22bは、DB2からCPU#0の故障状態「Alarm」を取得し、取得された故障状態「Alarm」と仮判定された故障状態「Warning」とを比較する。
その後、エラー管理ソフト22bは、故障状態の比較の結果、DB1とDB2との故障状態に差分があるが、DB1から仮判定された故障状態「Warning」とDB2から取得された故障状態「Alarm」とのうち、より重大度が高い状態をハードウェアCPU#0の状態とするので、仮判定された故障状態「Warning」をDB2に書き込む(復元する)ことなく処理を終了する。つまり、DB1の故障状態を示すDB2の内容は、再起動前の故障状態である「Alarm」が保持される。
(項番9)
項番9では、サービスプロセッサ20の起動契機が情報処理装置10の電源投入によるものであり、DB1の故障要因が完全故障を示す「Alarm要因」となる状態である。このような状態において、エラー管理ソフト22bは、サービスプロセッサ20が起動されると、DB1のbit領域から故障要因を取得する。そして、エラー管理ソフト22bは、取得された故障要因として、CPU#0領域「CORE#0 error(bit31)」および「CORE#1 error(bit30)」に「1」が立っている場合に、CPU#0のCOREが全て故障しているので、DB2に書き込む(復元する)故障状態を「Alarm」と仮判定する。続いて、エラー管理ソフト22bは、DB2からCPU#0の故障状態「Normal」を取得し、取得された故障状態「Normal」と仮判定された故障状態「Alarm」とを比較する。
項番9では、サービスプロセッサ20の起動契機が情報処理装置10の電源投入によるものであり、DB1の故障要因が完全故障を示す「Alarm要因」となる状態である。このような状態において、エラー管理ソフト22bは、サービスプロセッサ20が起動されると、DB1のbit領域から故障要因を取得する。そして、エラー管理ソフト22bは、取得された故障要因として、CPU#0領域「CORE#0 error(bit31)」および「CORE#1 error(bit30)」に「1」が立っている場合に、CPU#0のCOREが全て故障しているので、DB2に書き込む(復元する)故障状態を「Alarm」と仮判定する。続いて、エラー管理ソフト22bは、DB2からCPU#0の故障状態「Normal」を取得し、取得された故障状態「Normal」と仮判定された故障状態「Alarm」とを比較する。
その後、エラー管理ソフト22bは、故障状態の比較の結果、DB1とDB2との故障状態に差分があり、さらに、DB1から仮判定された故障状態「Alarm」の方が重大度が高い状態であるので、仮判定された故障状態「Alarm」をDB2に書き込んで(復元して)処理を終了する。つまり、DB1の故障状態を示すDB2の内容は、DB1の故障要因に基づいて復元された故障状態である「Alarm」が保持される。
ここで、エラー管理ソフト22bは、サービスプロセッサ20の起動によってDB2が全て「0」に初期化されているために、イベントのロストによる不整合であるか、または、DB2の初期化による不整合であるかを判定することができない。しかしながら、エラー管理ソフト22bは、イベントのロストによる不整合ではなく、DB2の初期化による不整合であることを優先するとともに、後述するevent配信ソフト22cや通報ソフト22eなどへの通知がサービスプロセッサ20の起動前に行なわれていることとして判定する結果、event配信ソフト22cに不整合検出イベントを通知することはない。
(項番10)
項番10では、サービスプロセッサ20の起動契機が再起動によるものであり、DB1の故障要因が完全故障を示す「Alarm要因」となる状態である。このような状態において、エラー管理ソフト22bは、サービスプロセッサ20が再起動されると、DB1のbit領域から故障要因を取得する。そして、エラー管理ソフト22bは、取得された故障要因として、CPU#0領域「CORE#0 error(bit31)」および「CORE#1 error(bit30)」に「1」が立っている場合に、CPU#0のCOREが全て故障しているので、DB2に書き込む(復元する)故障状態を「Alarm」と仮判定する。続いて、エラー管理ソフト22bは、DB2からCPU#0の故障状態「Normal」を取得し、取得された「Normal」と仮判定された故障状態「Alarm」とを比較する。
項番10では、サービスプロセッサ20の起動契機が再起動によるものであり、DB1の故障要因が完全故障を示す「Alarm要因」となる状態である。このような状態において、エラー管理ソフト22bは、サービスプロセッサ20が再起動されると、DB1のbit領域から故障要因を取得する。そして、エラー管理ソフト22bは、取得された故障要因として、CPU#0領域「CORE#0 error(bit31)」および「CORE#1 error(bit30)」に「1」が立っている場合に、CPU#0のCOREが全て故障しているので、DB2に書き込む(復元する)故障状態を「Alarm」と仮判定する。続いて、エラー管理ソフト22bは、DB2からCPU#0の故障状態「Normal」を取得し、取得された「Normal」と仮判定された故障状態「Alarm」とを比較する。
その後、エラー管理ソフト22bは、故障状態の比較の結果、DB1とDB2との故障状態に差分があり、さらに、DB1から仮判定された故障状態「Alarm」の方が重大度が高い状態であるので、仮判定された故障状態「Alarm」をDB2に書き込む(復元する)。つまり、DB1の故障状態を示すDB2の内容は、DB1の故障要因に基づいて復元された故障状態である「Alarm」が保持される。
そして、エラー管理ソフト22bは、イベントが途中でロストした可能性があると判定して、後述するevent配信ソフト22cに対して不整合検出イベントを通知する。つまり、エラー管理ソフト22bは、サービスプロセッサ20の再起動によりDB2の故障状態が再起動前の故障状態であるはずにもかかわらず、DB1とDB2とで不整合が発生しているので、イベントが途中でロストした可能性があると判定する。
このエラー管理ソフト22bがevent配信ソフト22cに対して渡す情報は、図11に示すように、128byte固定のバイナリデータとなっており、ハード監視ソフト22aまたは解析プログラム22dにより異常検出された時刻を示す「発生時刻」、サービスプロセッサ20再起動前のDB2の状態を示す「旧状態」、不整合検出後のDB2の状態を示す「新状態」、不整合が検出されたコンポーネント識別子を示す「検出元」、故障位置を表す文字列を示す「故障コンポーネント名」および不整合検出を表す固定文字列を示す「故障要因文字列」から構成される。また、各フォーマットの内容および故障コンポーネント名の内容は、図12に示すような内容となる。
(項番11)
項番11では、サービスプロセッサ20の起動契機が再起動によるものであり、DB1の故障要因が完全故障を示す「Alarm要因」となる状態である。このような状態において、エラー管理ソフト22bは、サービスプロセッサ20が再起動されると、DB1のbit領域から故障要因を取得する。そして、エラー管理ソフト22bは、取得された故障要因として、CPU#0領域「CORE#0 error(bit31)」および「CORE#1 error(bit30)」に「1」が立っている場合に、CPU#0のCOREが全て故障しているので、DB2に書き込む(復元する)故障状態を「Alarm」と仮判定する。続いて、エラー管理ソフト22bは、DB2からCPU#0の故障状態「Warning」を取得し、取得された「Warning」と仮判定された故障状態「Alarm」とを比較する。
項番11では、サービスプロセッサ20の起動契機が再起動によるものであり、DB1の故障要因が完全故障を示す「Alarm要因」となる状態である。このような状態において、エラー管理ソフト22bは、サービスプロセッサ20が再起動されると、DB1のbit領域から故障要因を取得する。そして、エラー管理ソフト22bは、取得された故障要因として、CPU#0領域「CORE#0 error(bit31)」および「CORE#1 error(bit30)」に「1」が立っている場合に、CPU#0のCOREが全て故障しているので、DB2に書き込む(復元する)故障状態を「Alarm」と仮判定する。続いて、エラー管理ソフト22bは、DB2からCPU#0の故障状態「Warning」を取得し、取得された「Warning」と仮判定された故障状態「Alarm」とを比較する。
その後、エラー管理ソフト22bは、故障状態の比較の結果、DB1とDB2との故障状態に差分があり、さらに、DB1から仮判定された故障状態「Alarm」の方が重大度が高い状態であるので、仮判定された故障状態「Alarm」をDB2に書き込む(復元する)。つまり、DB1の故障状態を示すDB2の内容は、DB1の故障要因に基づいて復元された故障状態である「Alarm」が保持される。
そして、エラー管理ソフト22bは、イベントが途中でロストした可能性があると判定して、後述するevent配信ソフト22cに対して不整合検出イベントを通知する。つまり、エラー管理ソフト22bは、サービスプロセッサ20の再起動によりDB2の故障状態が再起動前の故障状態であるはずにもかかわらず、DB1とDB2とで不整合が発生しているので、イベントが途中でロストした可能性があると判定する。
このエラー管理ソフト22bがevent配信ソフト22cに対して渡す情報は、図11に示すように、128byte固定のバイナリデータとなっており、ハード監視ソフト22aまたは解析プログラム22dにより異常検出された時刻を示す「発生時刻」、サービスプロセッサ20再起動前のDB2の状態を示す「旧状態」、不整合検出後のDB2の状態を示す「新状態」、不整合が検出されたコンポーネント識別子を示す「検出元」、故障位置を表す文字列を示す「故障コンポーネント名」および不整合検出を表す固定文字列を示す「故障要因文字列」から構成される。また、各フォーマットの内容および故障コンポーネント名の内容は、図12に示すような内容となる。
(項番12)
項番12では、サービスプロセッサ20の起動契機が再起動によるものであり、DB1の故障要因が完全故障を示す「Alarm要因」となる状態である。このような状態において、エラー管理ソフト22bは、サービスプロセッサ20が再起動されると、DB1のbit領域から故障要因を取得する。そして、エラー管理ソフト22bは、取得された故障要因として、CPU#0領域「CORE#0 error(bit31)」および「CORE#1 error(bit30)」に「1」が立っている場合に、CPU#0のCOREが全て故障しているので、DB2に書き込む(復元する)故障状態を「Alarm」と仮判定する。続いて、エラー管理ソフト22bは、DB2からCPU#0の故障状態「Alarm」を取得し、取得された「Alarm」と仮判定された故障状態「Alarm」とを比較する。
項番12では、サービスプロセッサ20の起動契機が再起動によるものであり、DB1の故障要因が完全故障を示す「Alarm要因」となる状態である。このような状態において、エラー管理ソフト22bは、サービスプロセッサ20が再起動されると、DB1のbit領域から故障要因を取得する。そして、エラー管理ソフト22bは、取得された故障要因として、CPU#0領域「CORE#0 error(bit31)」および「CORE#1 error(bit30)」に「1」が立っている場合に、CPU#0のCOREが全て故障しているので、DB2に書き込む(復元する)故障状態を「Alarm」と仮判定する。続いて、エラー管理ソフト22bは、DB2からCPU#0の故障状態「Alarm」を取得し、取得された「Alarm」と仮判定された故障状態「Alarm」とを比較する。
その後、エラー管理ソフト22bは、故障状態の比較の結果、DB1とDB2との故障状態に差分がないので、仮判定された故障状態「Alarm」をDB2に書き込む(復元する)ことなく処理を終了する。
次に、event配信ソフト22cの機能について説明する。event配信ソフト22cは、エラー管理ソフト22bにより通知された不整合検出イベントをキューイングする。上記した例で具体的に例を挙げると、event配信ソフト22cは、エラー管理ソフト22bにより不整合検出されて通知された不整合検出イベントを、所定の領域にキューとしてためていく。
解析プログラム22dは、ハードウェア資源11からのエラー通知(障害通知)を受信する。上記した例で具体的に例を挙げると、解析プログラム22dは、event配信ソフト22cにより不整合検出イベントがキューイングされると、起動するとともに、ハードウェア資源11からのエラー通知(障害通知)を受信できる状態に遷移する。
通報ソフト22eは、エラー管理ソフト22bにより通知された不整合検出イベントを受信して、管理サーバ1に対して通知する。上記した例で具体的に例を挙げると、通報ソフト22eは、event配信ソフト22cによりキューイングされて、エラー管理ソフト22bにより通知された不整合検出イベントを受信する。そして、通報ソフト22eは、受信された不整合検出イベントから通報用フォーマット文字列を生成して、MailまたはSNMPなどを用いて管理サーバ1に対して故障情報を通知する。
この通報ソフト22eがエラー管理ソフト22bから受信する情報は、図13に示すように、128byte固定のバイナリデータとなっており、ハード監視ソフト22aまたは解析プログラム22dにより異常検出された時刻を示す「発生時刻」、サービスプロセッサ20再起動前のDB2の状態を示す「旧状態」、不整合検出後のDB2の状態を示す「新状態」、不整合が検出されたコンポーネント識別子を示す「検出元」、故障位置を表す文字列を示す「故障コンポーネント名」および不整合検出の表す固定文字列を示す「故障要因文字列」から構成される。また、各フォーマットの内容および故障コンポーネント名の内容は、図14に示すような内容となる。なお、図13は、実施例1に係る通報ソフト22eがエラー管理ソフト22bから受信する情報の例を示す図であり、図14は、実施例1に係る通報ソフト22eがエラー管理ソフト22bから受信する情報の内容を示す図である。
また、この通報ソフト22eが生成する通報用フォーマット文字列は、図15および図16に示すように、異常検出された時刻を示す発生時刻「2007/Dec/31 23:59:30」、異常検出されたハードウェア資源11を示すハードウェア資源「CPU#0」、不整合イベント検出を表す固定文字列を示す故障要因文字列「Component status mismatched」、サービスプロセッサ20再起動前と不整合イベント検出後とのDB2の状態を示す「(Warning→Alarm)」から構成される。なお、図15は、実施例1に係る通報ソフト22eが生成する通報用フォーマット文字列の例を示す図であり、図16は、実施例1に係る通報ソフト22eが生成する通報用フォーマット文字列の内容を示す図である。
[実施例1に係る情報処理装置による処理]
次に、図17を用いて、実施例1に係る情報処理装置10による故障情報通知処理を説明する。図17は、実施例1に係る情報処理装置10による故障情報通知処理を説明するためのフローチャートである。
次に、図17を用いて、実施例1に係る情報処理装置10による故障情報通知処理を説明する。図17は、実施例1に係る情報処理装置10による故障情報通知処理を説明するためのフローチャートである。
図17に示すように、情報処理装置10は、サービスプロセッサが起動されると(ステップS101)、エラー管理ソフト22bが起動されて(ステップS102成功)、ハード監視ソフト22aにより復元依頼があるか否かを判定する(ステップS103)。そして、情報処理装置10は、ハード監視ソフト22aにより復元依頼があった場合に(ステップS103有り)、故障要因が保持されるDB1と、故障状態が保持されるDB2を読み込む(ステップS104成功、ステップS105成功)。
続いて、情報処理装置10は、故障要因が保持されるDB1から復元するDB2の故障状態を仮判定して(ステップS106成功)、仮判定された故障状態とDB1の状態とを比較する(ステップS107)。その後、情報処理装置10は、DB1とDB2との故障情報において不整合を検出すると(ステップS108送信必要)、当該不整合に基づいて不整合イベントを生成し(ステップS109成功)、event配信ソフト22cに対して不整合イベントの送信依頼を通知する(ステップS110)。
そして、情報処理装置10は、ハード監視ソフト22aにより復元依頼がない場合に(ステップS103無し)、initプロセスなどによるエラー管理ソフト22bの停止依頼があるか否かの判定を行なう(ステップS111)。続いて、情報処理装置10は、initプロセスなどによるエラー管理ソフト22bの停止依頼がない場合に(ステップS111無し)、event配信ソフト22cによる不整合イベントを受信する(ステップS112)。
その後、情報処理装置10は、故障要因が保持されるDB1を読み込み(ステップS113成功)、故障状態が保持されるDB2の書き込み(復元する)位置を算出して(ステップS114成功)、DB1に保持される故障要因に基づいて、DB2に保持される故障状態を算出する(ステップS115成功)。そして、情報処理装置10は、算出された故障状態をDB2に書き込んで(復元して)(ステップS116成功)、通報ソフト22eに対して障害情報通知イベントの送信依頼を通知する(ステップS117)。続いて、情報処理装置10は、initプロセスなどによるエラー管理ソフト22bの停止依頼があった場合に(ステップS111有り)、エラー管理ソフト22bを停止する(ステップS118)。なお、障害情報通知イベントの送信依頼を通知された通報ソフト22eは、接続される管理サーバ1に対して障害情報を通知する。
[実施例1による効果]
このようにして、実施例1によれば、情報処理装置10は、複数のハードウェア資源を有するとともに、第1の電源により動作する場合に、第1の電源が遮断された場合においても、ハードウェア資源において発生した障害に関する第1の障害情報を保持する第1の記憶部と、第1の障害情報とは異なる第2の障害情報を保持するとともに、第1の電源が遮断された場合に、第2の障害情報が保持されない第2の記憶部とを有し、情報処理装置に実装されている複数のハードウェア資源の構成情報を取得し、構成情報と第1の記憶部に格納された第1の障害情報に基づいて、第2の記憶部に保持する第2の障害情報を復元し、第1の障害情報と第2の障害情報間の整合性を検査し、第1の障害情報と第2の障害情報間において不整合が検出された場合には、障害が発生した旨を通知するので、不揮発性の記憶部と揮発性の記憶部とを有する情報処理装置において、揮発性の記憶部の障害情報を復元することが可能である。つまり、情報処理装置10は、サービスプロセッサ20が起動された場合に、保持されるハードウェア資源の故障要因に基づいて、故障状態を復元することができる結果、故障状態を退避するための領域を必要とすることなく、少ない資源で故障状態を復元することが可能である。また、情報処理装置10は、故障状態を復元することができる結果、故障状態を喪失することなく、接続される管理サーバ1などに通知することが可能である。
このようにして、実施例1によれば、情報処理装置10は、複数のハードウェア資源を有するとともに、第1の電源により動作する場合に、第1の電源が遮断された場合においても、ハードウェア資源において発生した障害に関する第1の障害情報を保持する第1の記憶部と、第1の障害情報とは異なる第2の障害情報を保持するとともに、第1の電源が遮断された場合に、第2の障害情報が保持されない第2の記憶部とを有し、情報処理装置に実装されている複数のハードウェア資源の構成情報を取得し、構成情報と第1の記憶部に格納された第1の障害情報に基づいて、第2の記憶部に保持する第2の障害情報を復元し、第1の障害情報と第2の障害情報間の整合性を検査し、第1の障害情報と第2の障害情報間において不整合が検出された場合には、障害が発生した旨を通知するので、不揮発性の記憶部と揮発性の記憶部とを有する情報処理装置において、揮発性の記憶部の障害情報を復元することが可能である。つまり、情報処理装置10は、サービスプロセッサ20が起動された場合に、保持されるハードウェア資源の故障要因に基づいて、故障状態を復元することができる結果、故障状態を退避するための領域を必要とすることなく、少ない資源で故障状態を復元することが可能である。また、情報処理装置10は、故障状態を復元することができる結果、故障状態を喪失することなく、接続される管理サーバ1などに通知することが可能である。
例えば、情報処理装置10は、当該情報処理装置10の電源が遮断された場合においても故障要因が保持される不揮発性のDB1と、当該DB1とは異なる故障状態を保持し、当該情報処理装置10の電源が遮断された場合に故障状態が保持されない揮発性のDB2とを有し、サービスプロセッサ20が起動された場合に、DB1に保持される故障要因からDB2に保持される故障状態を復元するとともに、DB1およびDB2間の整合性を検査し、不整合が検出されると、不整合検出イベントを接続される管理サーバ1などに通知する。この結果、不揮発性の記憶部と揮発性の記憶部とを有する情報処理装置において、揮発性の記憶部の障害情報を復元することが可能である。
さて、これまで本発明の実施例について説明したが、本発明は上述した実施例以外にも
種々の異なる形態にて実施されてよいものである。そこで、(1)情報処理装置の構成、(2)プログラムにおいて異なる実施例を説明する。
種々の異なる形態にて実施されてよいものである。そこで、(1)情報処理装置の構成、(2)プログラムにおいて異なる実施例を説明する。
(1)情報処理装置の構成
また、上記文書中や図面中で示した処理手順、制御手順、具体的名称、各種のデータやパラメタを含む情報(例えば、図2に示したような「DB1」、「DB2」が記憶している項目や数値など)については、特記する場合を除いて任意に変更することができる。また、上記実施例1では、障害情報の復元および障害情報の整合性検査を行なう情報処理装置を説明したが、本発明はこれに限定されるものではなく、障害情報の復元を行なう情報処理装置、または、障害情報の整合性検査を行なう情報処理装置として実施することとしてもよい。
また、上記文書中や図面中で示した処理手順、制御手順、具体的名称、各種のデータやパラメタを含む情報(例えば、図2に示したような「DB1」、「DB2」が記憶している項目や数値など)については、特記する場合を除いて任意に変更することができる。また、上記実施例1では、障害情報の復元および障害情報の整合性検査を行なう情報処理装置を説明したが、本発明はこれに限定されるものではなく、障害情報の復元を行なう情報処理装置、または、障害情報の整合性検査を行なう情報処理装置として実施することとしてもよい。
また、図示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散・統合の具体的形態は図示のものに限られず、例えば、エラー管理ソフト22bと通報ソフト22eとを、障害情報の復元および整合性の検査を行なうとともに、不整合が検出された場合に障害が発生した旨を通知するエラー管理/通報ソフトとして統合するなど、その全部または一部を、各種の負担や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。さらに、各装置にて行われる各処理機能は、その全部または任意の一部が、CPUおよび当該CPUにて解析実行されるプログラムにて実現され、あるいは、ワイヤードロジックによるハードウェアとして実現され得る。
(2)プログラム
ところで、上記の実施例では、ハードウェアロジックによって各種の処理を実現する場合を説明したが、本発明はこれに限定されるものではなく、あらかじめ用意されたプログラムをコンピュータで実行することによって実現するようにしてもよい。そこで、以下では、図18を用いて、上記の実施例に示した情報処理装置と同様の機能を有する制御プログラムを実行するコンピュータの一例を説明する。図18は、制御プログラムを実行するコンピュータを示す図である。
ところで、上記の実施例では、ハードウェアロジックによって各種の処理を実現する場合を説明したが、本発明はこれに限定されるものではなく、あらかじめ用意されたプログラムをコンピュータで実行することによって実現するようにしてもよい。そこで、以下では、図18を用いて、上記の実施例に示した情報処理装置と同様の機能を有する制御プログラムを実行するコンピュータの一例を説明する。図18は、制御プログラムを実行するコンピュータを示す図である。
図18に示すように、情報処理装置としてのコンピュータ110は、HDD130、CPU140、ROM150およびRAM160をバス180などで接続して構成される。
ROM150には、上記の実施例1に示した情報処理装置10と同様の機能を発揮する制御プログラム、つまり、図18に示すように構成情報取得プログラム150aと、障害情報復元プログラム150bと、整合性検査プログラム150cと、障害通知プログラム150dとが、あらかじめ記憶されている。なお、これらのプログラム150a〜プログラム150dについては、図2に示した情報処理装置10の各構成要素と同様、適宜統合または、分散してもよい。
そして、CPU140がこれらのプログラム150a〜プログラム150dをROM150から読み出して実行することで、図18に示すように、プログラム150a〜プログラム150dは、構成情報取得プロセス140aと、障害情報復元プロセス140bと、整合性検査プロセス140cと、障害通知プロセス140dとして機能するようになる。なお、プロセス140a〜プロセス140dは、図2に示した、ハード監視ソフト22aと、エラー管理ソフト22bと、通報ソフト22eとに対応する。
そして、CPU140はHDD130に記録された第1障害情報データ130aと、第2障害情報データ130bとに基づいて制御プログラムを実行する。
なお、上記した各プログラム150a〜プログラム150dについては、必ずしも最初からROM150に記憶させておく必要はなく、例えば、コンピュータ110に挿入されるコンピュータ読み取り可能なフレキシブルディスク(FD)、CD−ROM、DVDディスク、光磁気ディスク、ICカードなどの「可搬用の物理媒体」、またはコンピュータ110の内外に備えられるHDDなどの「固定用の物理媒体」、さらには公衆回線、インターネット、LAN、WANなどを介してコンピュータ110に接続される「他のコンピュータ(またはサーバ)」などに各プログラムを記憶させておき、コンピュータ110がこれから各プログラムを読み出して実行するようにしてもよい。
以上の実施例1および2を含む実施形態に関し、更に以下の付記を開示する。
(付記1)複数のハードウェア資源を有するとともに、第1の電源により動作する情報処理装置において、
前記第1の電源が遮断された場合においても、前記ハードウェア資源において発生した障害に関する第1の障害情報を保持する第1の記憶部と、
前記第1の障害情報とは異なる第2の障害情報を保持するとともに、前記第1の電源が遮断された場合に、前記第2の障害情報が保持されない第2の記憶部と、
前記情報処理装置に実装されている前記複数のハードウェア資源の構成情報を取得するハードウェア監視部と、前記構成情報と前記第1の記憶部に格納された第1の障害情報に基づいて、前記第2の記憶部に保持する第2の障害情報を復元する障害情報管理部として機能するシステム制御装置を有することを特徴とする情報処理装置。
前記第1の電源が遮断された場合においても、前記ハードウェア資源において発生した障害に関する第1の障害情報を保持する第1の記憶部と、
前記第1の障害情報とは異なる第2の障害情報を保持するとともに、前記第1の電源が遮断された場合に、前記第2の障害情報が保持されない第2の記憶部と、
前記情報処理装置に実装されている前記複数のハードウェア資源の構成情報を取得するハードウェア監視部と、前記構成情報と前記第1の記憶部に格納された第1の障害情報に基づいて、前記第2の記憶部に保持する第2の障害情報を復元する障害情報管理部として機能するシステム制御装置を有することを特徴とする情報処理装置。
(付記2)前記情報処理装置はさらに、
前記システム制御装置に、電力を供給する第2の電源を有し、
前記第2の電源は、前記第1の電源が遮断されている場合においても、前記システム制御装置に対して電力を供給し続けることを特徴とする付記1記載の情報処理装置。
前記システム制御装置に、電力を供給する第2の電源を有し、
前記第2の電源は、前記第1の電源が遮断されている場合においても、前記システム制御装置に対して電力を供給し続けることを特徴とする付記1記載の情報処理装置。
(付記3)前記障害情報管理部は、
前記第1の電源が投入された場合に、前記構成情報と前記第1の記憶部に格納された第1の障害情報に基づいて、前記第2の記憶部に保持する第2の障害情報を復元することを特徴とする付記1又は2記載の情報処理装置。
前記第1の電源が投入された場合に、前記構成情報と前記第1の記憶部に格納された第1の障害情報に基づいて、前記第2の記憶部に保持する第2の障害情報を復元することを特徴とする付記1又は2記載の情報処理装置。
(付記4)前記第1の障害情報は、
前記障害が発生したハードウェア資源を識別する識別情報と、
前記障害が発生したハードウェア資源における障害要因を有することを特徴とする付記1乃至3のいずれかに記載の情報処理装置。
前記障害が発生したハードウェア資源を識別する識別情報と、
前記障害が発生したハードウェア資源における障害要因を有することを特徴とする付記1乃至3のいずれかに記載の情報処理装置。
(付記5)前記第2の障害情報は、
前記障害が発生したハードウェア資源を識別する識別情報と、
前記障害が発生したハードウェア資源における障害の程度に関する情報を有することを特徴とする付記1乃至4のいずれかに記載の情報処理装置。
前記障害が発生したハードウェア資源を識別する識別情報と、
前記障害が発生したハードウェア資源における障害の程度に関する情報を有することを特徴とする付記1乃至4のいずれかに記載の情報処理装置。
(付記6)複数のハードウェア資源を有するとともに、第1の電源により動作する情報処理装置において、
前記第1の電源が遮断された場合においても、前記ハードウェア資源において発生した障害に関する第1の障害情報を保持する第1の記憶部と、
前記第1の障害情報とは異なる第2の障害情報を保持するとともに、前記第1の電源が遮断された場合に、前記第2の障害情報が保持されない第2の記憶部と、
前記第1の障害情報と前記第2の障害情報間の整合性を検査する障害情報管理部と、前記第1の障害情報と前記第2の障害情報間において不整合が検出された場合には、障害が発生した旨を通知する障害通知部として機能するシステム制御装置を有することを特徴とする情報処理装置。
前記第1の電源が遮断された場合においても、前記ハードウェア資源において発生した障害に関する第1の障害情報を保持する第1の記憶部と、
前記第1の障害情報とは異なる第2の障害情報を保持するとともに、前記第1の電源が遮断された場合に、前記第2の障害情報が保持されない第2の記憶部と、
前記第1の障害情報と前記第2の障害情報間の整合性を検査する障害情報管理部と、前記第1の障害情報と前記第2の障害情報間において不整合が検出された場合には、障害が発生した旨を通知する障害通知部として機能するシステム制御装置を有することを特徴とする情報処理装置。
(付記7)前記情報処理装置はさらに、
前記システム制御装置に、電力を供給する第2の電源を有し、
前記第2の電源は、前記第1の電源が遮断されている場合においても、前記システム制御装置に対して電力を供給し続けることを特徴とする付記6記載の情報処理装置。
前記システム制御装置に、電力を供給する第2の電源を有し、
前記第2の電源は、前記第1の電源が遮断されている場合においても、前記システム制御装置に対して電力を供給し続けることを特徴とする付記6記載の情報処理装置。
(付記8)前記障害情報管理部は、
前記第1の電源が投入された場合に、前記構成情報と前記第1の記憶部に格納された第1の障害情報に基づいて、前記第2の記憶部に保持する第2の障害情報を復元することを特徴とする付記6又は7記載の情報処理装置。
前記第1の電源が投入された場合に、前記構成情報と前記第1の記憶部に格納された第1の障害情報に基づいて、前記第2の記憶部に保持する第2の障害情報を復元することを特徴とする付記6又は7記載の情報処理装置。
(付記9)前記第1の障害情報は、
前記障害が発生したハードウェア資源を識別する識別情報と、
前記障害が発生したハードウェア資源における障害要因を有することを特徴とする付記6乃至8のいずれかに記載の情報処理装置。
前記障害が発生したハードウェア資源を識別する識別情報と、
前記障害が発生したハードウェア資源における障害要因を有することを特徴とする付記6乃至8のいずれかに記載の情報処理装置。
(付記10)前記第2の障害情報は、
前記障害が発生したハードウェア資源を識別する識別情報と、
前記障害が発生したハードウェア資源における障害の程度に関する情報を有することを特徴とする付記6乃至9のいずれかに記載の情報処理装置。
前記障害が発生したハードウェア資源を識別する識別情報と、
前記障害が発生したハードウェア資源における障害の程度に関する情報を有することを特徴とする付記6乃至9のいずれかに記載の情報処理装置。
(付記11)複数のハードウェア資源と前記複数のハードウェア資源を制御するシステム制御装置を有するとともに、第1の電源により動作する情報処理装置の制御方法において、
前記システム制御装置が、前記ハードウェア資源において発生した障害に関する第1の障害情報を、第1の記憶部に保持するステップと、
前記システム制御装置が、前記第1の障害情報とは異なる第2の障害情報を、第2の記憶部に保持するステップと、
前記第1の電源を遮断するステップと、
前記第1の電源を投入するステップと、
前記システム制御装置が、前記情報処理装置に実装されている前記複数のハードウェア資源の構成情報を取得するステップと、
前記システム制御装置が、前記構成情報と前記第1の記憶部に格納された第1の障害情報に基づいて、前記第2の記憶部に保持する第2の障害情報を復元するステップを有することを特徴とする制御方法。
前記システム制御装置が、前記ハードウェア資源において発生した障害に関する第1の障害情報を、第1の記憶部に保持するステップと、
前記システム制御装置が、前記第1の障害情報とは異なる第2の障害情報を、第2の記憶部に保持するステップと、
前記第1の電源を遮断するステップと、
前記第1の電源を投入するステップと、
前記システム制御装置が、前記情報処理装置に実装されている前記複数のハードウェア資源の構成情報を取得するステップと、
前記システム制御装置が、前記構成情報と前記第1の記憶部に格納された第1の障害情報に基づいて、前記第2の記憶部に保持する第2の障害情報を復元するステップを有することを特徴とする制御方法。
(付記12)複数のハードウェア資源と前記複数のハードウェア資源を制御するシステム制御装置を有するとともに、第1の電源により動作する情報処理装置の制御方法において、
前記システム制御装置が、前記ハードウェア資源において発生した障害に関する第1の障害情報を、第1の記憶部に保持するステップと、
前記システム制御装置が、前記第1の障害情報とは異なる第2の障害情報を、第2の記憶部に保持するステップと、
前記第1の電源を遮断するステップと、
前記第1の電源を投入するステップと、
前記システム制御装置が、前記情報処理装置に実装されている前記複数のハードウェア資源の構成情報を取得するステップと、
前記第1の障害情報と前記第2の障害情報間において不整合が検出された場合には、前記システム制御装置が、障害が発生した旨を通知するステップを有することを特徴とする制御方法。
前記システム制御装置が、前記ハードウェア資源において発生した障害に関する第1の障害情報を、第1の記憶部に保持するステップと、
前記システム制御装置が、前記第1の障害情報とは異なる第2の障害情報を、第2の記憶部に保持するステップと、
前記第1の電源を遮断するステップと、
前記第1の電源を投入するステップと、
前記システム制御装置が、前記情報処理装置に実装されている前記複数のハードウェア資源の構成情報を取得するステップと、
前記第1の障害情報と前記第2の障害情報間において不整合が検出された場合には、前記システム制御装置が、障害が発生した旨を通知するステップを有することを特徴とする制御方法。
(付記13)複数のハードウェア資源と前記複数のハードウェア資源を制御するシステム制御装置を有するとともに、第1の電源により動作する情報処理装置の制御プログラムにおいて、
前記システム制御装置に、
前記システム制御装置が、前記ハードウェア資源において発生した障害に関する第1の障害情報を、第1の記憶部に保持するステップと、
前記システム制御装置が、前記第1の障害情報とは異なる第2の障害情報を、第2の記憶部に保持するステップと、
前記第1の電源が遮断された後、前記第1の電源投入された場合に、前記システム制御装置が、前記情報処理装置に実装されている前記複数のハードウェア資源の構成情報を取得するステップと、
前記システム制御装置が、前記構成情報と前記第1の記憶部に格納された第1の障害情報に基づいて、前記第2の記憶部に保持する第2の障害情報を復元するステップを実行させることを特徴とする制御プログラム。
前記システム制御装置に、
前記システム制御装置が、前記ハードウェア資源において発生した障害に関する第1の障害情報を、第1の記憶部に保持するステップと、
前記システム制御装置が、前記第1の障害情報とは異なる第2の障害情報を、第2の記憶部に保持するステップと、
前記第1の電源が遮断された後、前記第1の電源投入された場合に、前記システム制御装置が、前記情報処理装置に実装されている前記複数のハードウェア資源の構成情報を取得するステップと、
前記システム制御装置が、前記構成情報と前記第1の記憶部に格納された第1の障害情報に基づいて、前記第2の記憶部に保持する第2の障害情報を復元するステップを実行させることを特徴とする制御プログラム。
(付記14)複数のハードウェア資源と前記複数のハードウェア資源を制御するシステム制御装置を有するとともに、第1の電源により動作する情報処理装置の制御プログラムにおいて、
前記システム制御装置に、
前記システム制御装置が、前記ハードウェア資源において発生した障害に関する第1の障害情報を、第1の記憶部に保持するステップと、
前記システム制御装置が、前記第1の障害情報とは異なる第2の障害情報を、第2の記憶部に保持するステップと、
前記第1の電源が遮断された後、前記第1の電源投入された場合に、前記システム制御装置が、前記情報処理装置に実装されている前記複数のハードウェア資源の構成情報を取得するステップと、
前記第1の障害情報と前記第2の障害情報間において不整合が検出された場合には、前記システム制御装置が、障害が発生した旨を通知するステップを実行させることを特徴とする制御プログラム。
前記システム制御装置に、
前記システム制御装置が、前記ハードウェア資源において発生した障害に関する第1の障害情報を、第1の記憶部に保持するステップと、
前記システム制御装置が、前記第1の障害情報とは異なる第2の障害情報を、第2の記憶部に保持するステップと、
前記第1の電源が遮断された後、前記第1の電源投入された場合に、前記システム制御装置が、前記情報処理装置に実装されている前記複数のハードウェア資源の構成情報を取得するステップと、
前記第1の障害情報と前記第2の障害情報間において不整合が検出された場合には、前記システム制御装置が、障害が発生した旨を通知するステップを実行させることを特徴とする制御プログラム。
1 管理サーバ
10 情報処理装置
11 ハードウェア資源
20 サービスプロセッサ
21a DB1
21b DB2
21c メモリ
22a ハード監視ソフト
22b エラー管理ソフト
22c event配信ソフト
22d 解析プログラム
22e 通報ソフト
10 情報処理装置
11 ハードウェア資源
20 サービスプロセッサ
21a DB1
21b DB2
21c メモリ
22a ハード監視ソフト
22b エラー管理ソフト
22c event配信ソフト
22d 解析プログラム
22e 通報ソフト
Claims (8)
- 複数のハードウェア資源を有するとともに、第1の電源により動作する情報処理装置において、
前記第1の電源が遮断された場合においても、前記ハードウェア資源において発生した障害に関する第1の障害情報を保持する第1の記憶部と、
前記第1の障害情報とは異なる第2の障害情報を保持するとともに、前記第1の電源が遮断された場合に、前記第2の障害情報が保持されない第2の記憶部と、
前記情報処理装置に実装されている前記複数のハードウェア資源の構成情報を取得するハードウェア監視部と、前記構成情報と前記第1の記憶部に格納された第1の障害情報に基づいて、前記第2の記憶部に保持する第2の障害情報を復元する障害情報管理部として機能するシステム制御装置を有することを特徴とする情報処理装置。 - 前記情報処理装置はさらに、
前記システム制御装置に、電力を供給する第2の電源を有し、
前記第2の電源は、前記第1の電源が遮断されている場合においても、前記システム制御装置に対して電力を供給し続けることを特徴とする請求項1記載の情報処理装置。 - 前記障害情報管理部は、
前記第1の電源が投入された場合に、前記構成情報と前記第1の記憶部に格納された第1の障害情報に基づいて、前記第2の記憶部に保持する第2の障害情報を復元することを特徴とする請求項1又は2記載の情報処理装置。 - 前記第1の障害情報は、
前記障害が発生したハードウェア資源を識別する識別情報と、
前記障害が発生したハードウェア資源における障害要因を有することを特徴とする請求項1乃至3のいずれかに記載の情報処理装置。 - 前記第2の障害情報は、
前記障害が発生したハードウェア資源を識別する識別情報と、
前記障害が発生したハードウェア資源における障害の程度に関する情報を有することを特徴とする請求項1乃至4のいずれかに記載の情報処理装置。 - 複数のハードウェア資源を有するとともに、第1の電源により動作する情報処理装置において、
前記第1の電源が遮断された場合においても、前記ハードウェア資源において発生した障害に関する第1の障害情報を保持する第1の記憶部と、
前記第1の障害情報とは異なる第2の障害情報を保持するとともに、前記第1の電源が遮断された場合に、前記第2の障害情報が保持されない第2の記憶部と、
前記第1の障害情報と前記第2の障害情報間の整合性を検査する障害情報管理部と、前記第1の障害情報と前記第2の障害情報間において不整合が検出された場合には、障害が発生した旨を通知する障害通知部として機能するシステム制御装置を有することを特徴とする情報処理装置。 - 複数のハードウェア資源と前記複数のハードウェア資源を制御するシステム制御装置を有するとともに、第1の電源により動作する情報処理装置の制御方法において、
前記システム制御装置が、前記ハードウェア資源において発生した障害に関する第1の障害情報を、第1の記憶部に保持するステップと、
前記システム制御装置が、前記第1の障害情報とは異なる第2の障害情報を、第2の記憶部に保持するステップと、
前記第1の電源を遮断するステップと、
前記第1の電源を投入するステップと、
前記システム制御装置が、前記情報処理装置に実装されている前記複数のハードウェア資源の構成情報を取得するステップと、
前記システム制御装置が、前記構成情報と前記第1の記憶部に格納された第1の障害情報に基づいて、前記第2の記憶部に保持する第2の障害情報を復元するステップを有することを特徴とする制御方法。 - 複数のハードウェア資源と前記複数のハードウェア資源を制御するシステム制御装置を有するとともに、第1の電源により動作する情報処理装置の制御方法において、
前記システム制御装置が、前記ハードウェア資源において発生した障害に関する第1の障害情報を、第1の記憶部に保持するステップと、
前記システム制御装置が、前記第1の障害情報とは異なる第2の障害情報を、第2の記憶部に保持するステップと、
前記第1の電源を遮断するステップと、
前記第1の電源を投入するステップと、
前記システム制御装置が、前記情報処理装置に実装されている前記複数のハードウェア資源の構成情報を取得するステップと、
前記第1の障害情報と前記第2の障害情報間において不整合が検出された場合には、前記システム制御装置が、障害が発生した旨を通知するステップを有することを特徴とする制御方法。
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 |