(57)【要約】【課題】１つの管理機構が複数の処理機構に対して障害対処処理を行う情報処理装置において、管理機構の処理負担を軽減して障害対処処理の遅延を抑制する。【解決手段】複数の処理機構１と、当該複数の処理機構のうちの少なくとも１つで障害が発生したときに、当該障害が発生した処理機構に対して障害対処処理を行う管理機構３を備えた情報処理装置に、複数の処理機構のそれぞれに対応した複数の個別監視機構２を設ける。そして、個別監視機構２が、対応する処理機構１の稼働状態に基づき、当該処理機構が正常に稼動しているか否かを判定する。一方、管理機構３は、いずれかの個別監視機構２において当該個別監視機構２に対応する処理機構１が正常に稼動していないと判定されたときに、当該判定結果に基づき、当該判定をした個別監視機構２に対応する処理機構に１に対して障害対処処理を行う。【選択図】  図１
2011181064.tif 000002
【特許請求の範囲】
【請求項１】
複数の処理機構と、
前記複数の処理機構のそれぞれに対して設けられ、対応する処理機構の稼働状態を監視し、前記対応する処理機構が正常に稼動しているか否かを判定して、前記対応する処理機構についての判定結果を外部に通知する複数の個別監視機構と、
前記複数の個別監視機構と接続され、対応する処理機構が正常に稼動していないといずれかの個別監視機構から通知を受けたときに、当該通知をした個別監視機構に対応する処理機構に対して障害対処処理を行う管理機構と、
を有する情報処理装置。
【請求項２】
前記個別監視機構の夫々は、対応する処理機構が正常に稼動していないと判定したときにのみ、前記管理機構に判定結果を通知する請求項１記載の情報処理装置。
【請求項３】
前記処理機構は、所定の監視周期が経過する前に、対応する個別監視機構が参照可能な記憶領域に、前記記憶領域に記憶されている稼動情報とは異なる新たな稼動情報を設定し、
前記個別監視機構は、前記監視周期ごとに前記記憶領域を参照し、当該記憶領域に設定された稼働情報が前回の参照時と一致するときに、対応する処理機構が正常に稼働していないと判定することを特徴とする請求項１又は２に記載の情報処理装置。
【請求項４】
前記処理機構は、前記処理機構の現在の処理フェーズを示す情報を稼動情報として前記記憶領域に設定することを特徴とする請求項３記載の情報処理装置。
【請求項５】
前記監視周期は、前記処理機構の現在の処理フェーズの処理に要する時間以上の周期であることを特徴とする請求項４記載の情報処理装置。
【請求項６】
前記処理機構は、前記監視周期を前記記憶領域に設定し、
前記個別監視機構は、前記記憶領域に設定された前記監視周期に基づいて、前記処理機構が正常に稼動しているか否かを判定することを特徴とする請求項３〜５のいずれか１つに記載の情報処理装置。
【請求項７】
前記個別監視機構は、前記記憶領域に特定値以外の周期が監視周期として設定されたときに、対応する処理機構の監視処理を開始する一方、前記記憶領域に前記特定値が監視周期として設定されたときに、対応する処理機構の監視処理を終了することを特徴とする請求項６記載の情報処理装置。
【請求項８】
前記管理機構は、情報処理装置に含まれるいずれかの処理機構に対する電源供給が遮断された状態を検出したときに、電源供給が遮断された処理機構を監視する個別監視機構における監視処理を終了させることを特徴とする請求項１〜７のいずれか１つに記載の情報処理装置。
【請求項９】
複数の処理機構のそれぞれに対して設けられた個別監視機構が、対応する処理機構の稼働状態を監視し、前記対応する処理機構が正常に稼動しているか否かを判定して、前記対応する処理機構についての判定結果を外部に通知し、
前記複数の個別監視機構と接続され、いずれかの前記個別監視機構の判定結果に基づいて動作する管理機構が、前記個別監視機構において当該個別監視機構に対応する処理機構が正常に稼動していないといずれかの個別監視機構から通知を受けたときに、当該通知をした個別監視機構に対応する処理機構に対して障害対処処理を行うことを特徴とする情報処理方法。
【請求項１０】
前記個別監視機構の夫々は、対応する処理機構が正常に稼動していないと判定したときにのみ、前記管理機構に判定結果を通知することを特徴とする請求項９記載の情報処理方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、情報処理装置における障害発生を監視する技術に関する。
【背景技術】
【０００２】
情報処理装置における処理の信頼性を向上させるため、プログラムを実行する処理機構における障害の発生を監視し、障害対処処理を行う技術が一般的に採用されている。
かかる監視を行う方法として、監視対象となる処理機構にウォッチドッグタイマを搭載する方法が用いられており、例えば、次のような方法がある。すなわち、ウォッチドッグタイマがタイムアウトし障害を検出すると、オペレーティングシステム（以下、ＯＳ（Operating System）という）に対して障害発生が通知される。このとき、ＯＳが障害に対処をすることができない状態であれば、ハードウェア情報の収集を行うサービスプロセッサに対して障害発生が通知される。また、別の方法として、ウォッチドッグタイマを複数の処理機構にそれぞれ設け、１つのウォッチドッグタイマがタイムアウトしたときに、そのウォッチドッグタイマが、他の処理機構に対して障害発生の通知を行う方法もある。
【０００３】
しかし、このように処理機構に搭載されたウォッチドッグタイマは通常、ハードウェア障害については検出可能であるものの、ソフトウェアに起因する障害の検出や情報収集を行うには十分な機能を備えていない。このため、さらに別の方法として、処理機構から独立した別個の管理機構が、処理機構の稼動状態の監視や障害対処処理を行う方法が提案されている。かかる方法の一例では、処理機構が、自身の稼働状態を所定周期ごとに監視処理の起動、停止等を制御するコマンドとともに当該管理機構に通知する。一方、管理機構は、通知された稼動状態及びコマンドに基づき、処理機構において障害が発生しているか否かの判定をし、障害が発生していることを検出したときには、障害対処処理を行う。
【０００４】
また、システムの稼働状態を監視する関連技術として、監視対象装置が、ＬＡＮ（Local Area Network）を介して接続された監視装置の指示に従って自己監視を行う技術が提案されている。当該技術では、監視装置が、監視対象装置に対し、必要に応じて監視処理を停止又は再開させるコマンドを送信する。
【０００５】
ここで、近年では、複数の処理機構を備えた情報処理装置が普及しており、また、１台の情報処理装置の処理機構の数は増加傾向にある。かかる複数の処理機構を備えた情報処理装置の場合、１つの管理機構が、複数の処理機構の稼動状態を一括して監視して障害の有無を判定し、障害が発生した処理機構に対して障害対処処理を行う方法が一般的に採用されている。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開平１−１１６７３９号公報
【特許文献２】特開平１−１３４６３７号公報
【特許文献３】特開平１１−８５５６９号公報
【特許文献４】特開２００４−２５４０８８号公報
【発明の概要】
【発明が解決しようとする課題】
【０００７】
しかしながら、処理効率の向上の観点から処理機構が多数となった場合、１つの管理機構が複数の処理機構の夫々の稼働状態に基づき、各処理機構について障害発生の有無の判定を行うと、管理機構における処理負荷が大きくなる。その結果、管理機構の処理に支障が生じ、障害対処処理を適切に行うことが困難となる。
以上のような問題点に鑑み、開示の技術は、１つの管理機構が複数の処理機構に対して障害対処処理を行う情報処理装置において、管理機構の処理負担を軽減して障害対処処理の遅延を防ぐことを目的とする。
【課題を解決するための手段】
【０００８】
開示の技術では、複数の処理機構と、当該複数の処理機構のうちの少なくとも１つで障害が発生したときに、当該障害が発生した処理機構に対して障害対処処理を行う管理機構を備えた情報処理装置に、複数の処理機構のそれぞれに対応した複数の個別監視機構を設ける。そして、個別監視機構が、対応する処理機構の稼働状態に基づき、当該処理機構が正常に稼動しているか否かを判定する。一方、管理機構は、少なくとも１つの個別監視機構において当該個別監視機構に対応する処理機構が正常に稼動していないと判定されたときに、当該判定結果に基づき、当該判定をした個別監視機構に対応する処理機構に対して障害対処処理を行う。
【発明の効果】
【０００９】
開示の技術によれば、１つの管理機構が複数の処理機構に対して障害対処処理を行う情報処理装置において、管理機構の処理負担を軽減して障害対処処理の遅延を防ぐことができる。
【図面の簡単な説明】
【００１０】
【図１】情報処理装置の一例のブロック図である。
【図２】情報処理装置のハードウェア構成の一例の説明図である。
【図３】メインプロセッサのレジスタの一例の説明図であり、（Ａ）は第１チェックレジスタ、（Ｂ）はタイマレジスタ、（Ｃ）はタイマレジスタのＩＮＴＥＲＶＡＬフィールドに設定される監視周期の具体例を示す。
【図４】サービスプロセッサのレジスタの一例の説明図である。
【図５】メインプロセッサのＣＰＵにおける処理の一例を示すフローチャートである。
【図６】メインプロセッサの第１コントローラにおける処理の一例を示すフローチャートである。
【図７】サービスプロセッサにおける処理の一例を示すフローチャートである。
【図８】処理フェーズを特定可能なフェーズコードの具体例である。
【図９】メインプロセッサのＣＰＵにおける処理の一例を示すフローチャートである。
【図１０】サービスプロセッサにおける処理の一例を示すフローチャートである。
【発明を実施するための形態】
【００１１】
≪第１実施例≫
図１は、情報処理装置の一例の概略を示す説明図である。本情報処理装置は、内部に複数の処理機構１（ノード）を有する。「ノード」とは、処理機構上で動作するソフトウェアを指す用語として用いられることもあるが、以下ではソフトウェアが動作する処理機構などの「装置」と「ノード」とを同義のものとして扱うこととする。各処理機構１では、ＯＳが動作し、プログラム処理を行う。
また、本情報処理装置は、各処理機構１の夫々に対して設けられ、対応する処理機構１の稼働状態を監視し、処理機構１の稼働状態に基づいて対応する処理機構１における障害発生の有無を判定する複数の個別監視機構２を有する。さらに、本情報処理装置は、いずれかの処理機構１で障害が発生したときに、その処理機構１に対して障害対処処理を行う管理機構３を有する。障害対処処理とは、例えば、障害の原因となった情報の収集や解析を行ったり、リモート制御で処理機構１を障害から復旧させたりする処理を指す。
【００１２】
個別監視機構２の夫々は、所定の監視周期ごとに、対応する処理機構１の稼働状態を監視する。そして、個別監視機構２は、対応する処理機構１の稼動状態監視の結果に基づいて、処理機構１に障害が発生しているか否かを判定し、対応する処理機構１に障害が発生していると判定したときにのみ、管理機構３に通知する。すなわち、管理機構３は、自らは処理機構１の稼動情報に基づいた障害の発生有無の判定は行わず、個別監視機構２から判定結果を示す情報、具体的には障害発生を示す判定結果情報を得るのみである。そして、管理機構３は、いずれかの個別監視機構２から障害発生の判定結果の通知を受けたときに、その個別監視機構２に対応する処理機構１に対する障害対処処理を行う。
【００１３】
次に、かかる情報処理装置について、ハードウェア構成の具体例を用いて詳述する。図２は、本情報処理装置のハードウェア構成の一例を示す。本情報処理装置は、複数のメインプロセッサ１０と、本情報処理装置に組み込まれている各装置（各メインプロセッサ１０の他、例えば、電源ユニット、冷却機器等）を一括管理し、各装置の監視やリモート制御を行うサービスプロセッサ２０とを有する。各メインプロセッサ１０とサービスプロセッサ２０とは、制御バス３０を介して接続されている。
【００１４】
各々のメインプロセッサ１０は、１つ以上のＣＰＵ（Central Processing Unit）１０Ａ、ＲＡＭ（Random Access Memory）１０Ｂ、第１コントローラ１０Ｃ及びＲＯＭ１０Ｆを有する。第１コントローラ１０Ｃは、第１チェックレジスタ１０Ｄ、タイマレジスタ１０Ｅ及びタイマ機構１０Ｆを有する。メインプロセッサ１０は一例として、上記の各要素が搭載された一枚のボードを想定することも出来る。
【００１５】
ＣＰＵ１０Ａは、前掲の図１における処理機構１として機能し、ＯＳを動作させ、ＲＡＭ１０Ｂに格納された各種プログラムを実行する。なお、１つのメインプロセッサ１０に複数のＣＰＵ１０Ａが設けられ、１つのＯＳを複数のＣＰＵ１０Ａで動作させている場合には、同一のＯＳを動作させている複数のＣＰＵ１０Ａ全体が１つの処理機構１として機能すると見なすこともできる。
【００１６】
第１コントローラ１０Ｃは、例えばＦＰＧＡ（Field Programmable Gate Array）や論理回路であり、メインプロセッサ１０に含まれる各装置の制御を行う。また、第１コントローラ１０Ｃは、前掲の図１の個別監視機構２として機能し、ＣＰＵ１０Ａの稼働状態を監視して、稼動状態の監視結果に基づいて、ＣＰＵ１０Ａに障害が発生しているか否かを判定する。そして第１コントローラ１０Ｃは、ＣＰＵ１０Ａに障害が発生していると判定したときに、サービスプロセッサ２０に障害発生を通知する。
【００１７】
第１チェックレジスタ１０Ｄ及びタイマレジスタ１０Ｅは、第１コントローラ１０ＣがＣＰＵ１０Ａの稼働状態の監視のために用いるレジスタ（記憶領域）であり、ＣＰＵ１０Ａの稼動状態の監視処理に必要な情報が設定される。また、タイマ機構１０Ｆは、第１コントローラ１０ＣがＣＰＵ１０Ａの稼働状態を監視する監視周期の経過を検出する。さらに、ＲＯＭ１０Ｇには、第１コントローラ１０Ｃで動作する制御用や監視用のプログラムが格納されている。なお、メインプロセッサ１０の各構成要素は、図２に示すようにシステムバス１０Ｈで接続されている。
【００１８】
一方、サービスプロセッサ２０は、前掲の図１の管理機構３として機能し、ＭＰＵ（Micro Processing Unit）２０Ａ、ＲＡＭ２０Ｂ、第２コントローラ２０Ｃ及びＲＯＭ２０Ｅを有する。第２コントローラ２０Ｃは、その内部に複数の第２チェックレジスタ２０Ｄを有する。
ＭＰＵ２０Ａは、ＲＡＭ２０Ｂに格納されたファームウェアの処理を行う。ＭＰＵ２０Ａは、ファームウェアの処理を行うことで、前掲の管理機構３の機能のうち、障害対処処理を行う機能を実現する。
【００１９】
第２コントローラ２０Ｃは、例えばＦＰＧＡや論理回路であり、主としてサービスプロセッサ２０に含まれる各装置の制御を行う。また、第２コントローラ２０Ｃは、複数のメインプロセッサ１０の第１コントローラ１０Ｃから、ＣＰＵ１０Ａで障害が発生していることを示す通知を受信する。第１コントローラ１０Ｃからの通知は、換言すれば、サービスプロセッサ２０で動作するファームウェアに対する割込み制御指示である。このとき、第２コントローラ２０Ｃは、ＭＰＵ２０Ａにおいて処理中のファームウェアに対し、割込み制御を行う。一方、ＭＰＵ２０Ａにおいて処理中のファームウェアは、第２コントローラ２０Ｃからの割込み制御を受け、障害発生の通知を行った第１コントローラ１０Ｃに対応するＣＰＵ１０Ａに対し障害対処処理を行う。
【００２０】
第２チェックレジスタ２０Ｄは、メインプロセッサ１０の第１コントローラ１０Ｃからの指示により書き込みが行われるレジスタであり、少なくとも障害発生通知に用いられる。また、ＲＯＭ２０Ｅには、第２コントローラ２０Ｃで動作する制御用や監視用のプログラムが格納されている。なお、サービスプロセッサ２０の各構成要素は、図２に示すようにシステムバス２０Ｆで接続されている。
【００２１】
次に、メインプロセッサ１０の第１チェックレジスタ１０Ｄ及びタイマレジスタ１０Ｅ、並びにサービスプロセッサ２０の第２チェックレジスタ２０Ｄについて説明する。
第１チェックレジスタ１０Ｄ及びタイマレジスタ１０Ｅは、第１コントローラ１０Ｃ及びＣＰＵ１０Ａの両方からアクセス可能なレジスタである。
図３（Ａ）は、第１チェックレジスタ１０Ｄの構造の一例を示す。第１チェックレジスタ１０Ｄは全体で８ビットのサイズを有し、サイズが１ビットのＡＬＩＶＥＩＮＴフィールド及びサイズが７ビットのＤＡＴＡフィールドを含む。ＡＬＩＶＥＩＮＴフィールドは、メインプロセッサ１０からサービスプロセッサ２０への割込みが発生したことを示す情報を保持する領域であり、第１コントローラ１０ＣがＣＰＵ１０Ａにおける障害発生を検出したときに、その値が変更される。また、ＤＡＴＡフィールドは、ＣＰＵ１０Ａにより稼動情報が設定される領域である。稼動情報の詳細については後述する。
【００２２】
図３（Ｂ）は、タイマレジスタ１０Ｅの構造の一例を示す。タイマレジスタ１０Ｅは、全体で８ビットのサイズを有し、サイズが１ビットのＲＥＳＥＲＶＥＤフィールド及びサイズが７ビットのＩＮＴＥＲＶＡＬフィールドを含む。ＲＥＳＥＲＶＥＤフィールドは予備領域であり、本実施例では使用されない。ＩＮＴＥＲＶＡＬフィールドは、第１コントローラ１０ＣがＣＰＵ１０Ａの稼働状態を監視する監視周期が設定される領域である。なお、図３（Ｃ）は、ＩＮＴＥＲＶＡＬフィールドに設定される値の具体例であり、監視周期を示す監視周期コードを示す。例えば、監視周期コード「００００００１」は、監視周期が３０秒間隔であることを示す。第１コントローラ１０Ｃは、タイマレジスタ１０ＥのＩＮＴＥＲＶＡＬフィールドに設定された監視周期コードに基づいて、ＣＰＵ１０Ａの監視周期を決定する。そして、当該監視周期が経過したとき、すなわち、タイマがタイムアウトしたときに、タイマ割込みとして監視処理を実行する。
【００２３】
一方、サービスプロセッサ２０の第２チェックレジスタ２０Ｄは、サービスプロセッサ２０に接続されるメインプロセッサ１０の数に対応した数だけ設けられている。そして、この第２チェックレジスタ２０Ｄは、いずれかのメインプロセッサ１０の第１コントローラ１０ＣによりＣＰＵ１０Ａに障害が発生したと通知されたときに、障害発生を通知した第１コントローラ１０Ｃ内の第１チェックレジスタ１０Ｄが保持するデータが制御バス３０を介してコピーされるものである。第２チェックレジスタ２０Ｄは、第１チェックレジスタ１０Ｄと同様、図４に示すように、夫々、全体で８ビットのサイズを有し、サイズが１ビットのＡＬＩＶＥＩＮＴフィールド（７ビット）及びサイズが７ビットのＤＡＴＡフィールド（０〜６ビット）を含む。
【００２４】
次に、メインプロセッサ１０のＣＰＵ１０Ａで実行される処理の一例について、図５に示すフローチャートを用いて説明する。なお、以下の説明において、ＣＰＵ１０Ａが行うこととして記述している処理は、すなわち、ＣＰＵ１０Ａで実行されるＯＳ又はプログラムの機能により実現される処理である。
【００２５】
ステップ１（図５ではＳ１と表記している。以下同様）では、ＣＰＵ１０Ａが、タイマレジスタ１０ＥのＩＮＴＥＲＶＡＬフィールドに、第１コントローラ１０ＣがＣＰＵ１０Ａの監視処理を行う監視周期を設定する。この監視処理とは、図６のフローチャートで示す処理を指す。第１コントローラ１０Ｃに監視処理を実行させる場合、ＣＰＵ１０Ａはステップ１で、「０（ゼロ）」以外の値を監視周期としてＩＮＴＥＲＶＡＬフィールドに設定する。「０」は「特定値」の一例である。
【００２６】
ステップ２では、ＣＰＵ１０Ａが、第１チェックレジスタ１０ＤのＤＡＴＡフィールドに、新たな稼動情報を設定する。
ここで、新たな稼動情報とは、すでにＤＡＴＡフィールドに設定されていた情報と異なる情報であれば何でもよい。また、稼動情報自体も任意の情報でよい。換言すれば、ここでは、少なくともＣＰＵ１０Ａが正常稼動していてＤＡＴＡフィールドの値を書き換えることができたということが示されればよい。仮にＣＰＵ１０Ａに障害が発生した場合、ＣＰＵ１０ＡはＤＡＴＡフィールドに新たな稼動情報を書き込むことが出来ない可能性がある。逆に言えば、ＤＡＴＡフィールドに設定された稼動情報が前回設定された稼動情報と異なっていない場合には、ＣＰＵ１０Ａに障害が発生したと推測することが可能となる。
【００２７】
また、ステップ２でＣＰＵ１０Ａは、新たな稼動情報を設定する前にすでにＤＡＴＡフィールドに設定されていた稼動情報、すなわち、ＣＰＵ１０Ａが前回ＤＡＴＡフィールドに設定した稼動情報を、別の記憶領域（図２において図示省略）に退避させておく。
ステップ３では、ＣＰＵ１０Ａが、所定時間が経過した否かを判定する。この所定時間は、少なくとも第１コントローラ１０Ｃにおける監視処理の監視周期よりも短い時間とする。所定時間が経過していれば、ステップ４に進み（Ｙｅｓ）、所定時間が経過していなければ、ステップ３の処理を繰り返す（Ｎｏ）。なお、ステップ３における所定時間が第１コントローラ１０Ｃにおける監視処理の監視周期よりも短い時間であるため、ＣＰＵ１０Ａは、監視周期が経過する前に、次の新たな稼働情報の設定を行うこととなる。
【００２８】
ステップ４では、ＣＰＵ１０Ａが、第１コントローラ１０Ｃによる監視を終了させるか否かを判定する。監視を終了させるときには、ステップ５に進み（Ｙｅｓ）、監視を続行させるときには、ステップ２に戻る（Ｎｏ）。
ステップ５では、ＣＰＵ１０Ａが、タイマレジスタ１０Ｅの監視時間に「０（ゼロ）」（特定値）を設定する。
【００２９】
次に、メインプロセッサ１０の第１コントローラ１０Ｃで実行される処理の一例について、図６に示すフローチャートを用いて説明する。この処理は、第１コントローラ１０Ｃが、ＣＰＵ１０Ａにより「０」以外の監視周期がＩＮＴＥＲＶＡＬフィールドに設定されたことを条件として開始する。
【００３０】
ステップ１１では、第１コントローラ１０Ｃが、タイマレジスタ１０ＥのＩＮＴＥＲＶＡＬフィールドを参照し、「０」以外の監視周期が設定されているか否かを判定する。「０」以外の監視周期が設定されていれば、ステップ１２に進み（Ｙｅｓ）、「０」以外の監視周期が設定されていなければ、そのまま待機し、再度ステップ１１の処理を繰り返す（Ｎｏ）。
【００３１】
ステップ１２では、第１コントローラ１０Ｃが、ＣＰＵ１０Ａの稼働状態の監視処理を開始する。
ステップ１３では、第１コントローラ１０Ｃが、タイマレジスタ１０ＥのＩＮＴＥＲＶＡＬフィールドを参照し、「０」が設定されているか否かを判定する。「０」が設定されていれば、ステップ１８に進み（Ｙｅｓ）、「０」が設定されていなければ、ステップ１４に進む（Ｎｏ）。
【００３２】
ステップ１４では、第１コントローラ１０Ｃが、タイマレジスタ１０ＥのＩＮＴＥＲＶＡＬフィールドに設定された監視周期が経過したか否か、すなわち、タイマ機構１０Ｆで監視周期のタイムアウトが発生したか否かを判定する。そして、監視周期が経過していれば、ステップ１５に進み（Ｙｅｓ）、監視周期が経過していなければ、ステップ１３に戻る（Ｎｏ）。
【００３３】
ステップ１５では、第１コントローラ１０Ｃが、第１チェックレジスタ１０ＤのＤＡＴＡフィールドに設定された稼動情報を参照する。
ステップ１６では、第１コントローラ１０Ｃが、第１チェックレジスタ１０ＤのＤＡＴＡフィールドに設定された稼動情報と、前回ＤＡＴＡフィールドを参照した時の稼動情報とを比較する。前回参照時の稼動情報は、図５で示したＣＰＵ１０Ａの処理で別の記憶領域に退避されているので（ステップ２参照）、第１コントローラ１０Ｃは当該別の記憶領域を参照する。なお、ＣＰＵ１０Ａが正常に動作していれば、図５で示したＣＰＵ１０Ａの処理により、第１チェックレジスタ１０ＤのＤＡＴＡフィールドには、監視周期よりも短い時間ごとに新たな稼働情報が設定されていることになる。第１コントローラ１０Ｃは、第１チェックレジスタ１０ＤのＤＡＴＡフィールドに設定された稼動情報と、前回ＤＡＴＡフィールドを参照した時の稼動情報とが一致しているか否かを判定する。両者が一致していれば、ステップ１７に進み（Ｙｅｓ）、両者が一致していなければ、ステップ１３に戻る（Ｎｏ）。
【００３４】
ステップ１７では、第１コントローラ１０Ｃは、ＣＰＵ１０Ａに障害が発生したと判断する。この場合、第１コントローラ１０Ｃが、第２コントローラ２０Ｃに対し、ＣＰＵ１０Ａにおいて障害が発生したことを通知する。具体的には、第１コントローラ１０Ｃが、第１チェックレジスタ１０ＤのＡＬＩＶＥＩＮＴフィールドの値を、障害が発生したことを示す値へと変更する。例えば、通常時のＡＬＩＶＥＩＮＴフィールドの値を「０」とする場合、第１コントローラ１０ＣはＡＬＩＶＥＩＮＴフィールドの値を「１」に変更する。さらに、第１コントローラ１０Ｃは、制御バス３０を介して、第２コントローラ２０Ｃへ第１チェックレジスタ１０Ｄのデータを伝送する。第２コントローラ２０Ｃは、第１コントローラ１０Ｃから転送されたデータを、第２チェックレジスタ２０Ｄにコピーする。これにより、第２チェックレジスタ２０ＤのＡＬＩＶＥＩＮＴフィールドの値が、ＣＰＵ１０Ａで障害が発生したことを示す値へと変更され、第２コントローラ２０Ｃは、第２チェックレジスタ２０Ｄを参照することによって、メインプロセッサ１０のＣＰＵ１０Ａの処理において障害が発生したことを識別することができる。
【００３５】
なお、このとき、第１コントローラ１０Ｃは、少なくとも自身が搭載されたメインプロセッサ１０を特定可能な情報、すなわち、サービスプロセッサ２０側でどのメインプロセッサ１０で障害が発生したかを特定可能な情報も、併せて第２コントローラ２０Ｃに対して通知する。また、メインプロセッサ１０が複数のＣＰＵ１０Ａを備えている場合には、第１コントローラ１０Ｃから第２コントローラ２０Ｃに対して、さらに、障害が発生したＣＰＵ１０Ａを特定可能な情報も併せて通知してもよい。
【００３６】
一方、ステップ１６でＮｏと判定された場合、第１コントローラ１０ＣはＣＰＵ１０Ａに障害は発生していないと判断する。この場合、第１コントローラ１０Ｃは、第２コントローラ２０Ｃに対して特に通知を発しない。
ステップ１８では、第１コントローラ１０Ｃが、ＣＰＵ１０Ａの監視処理を終了する。
次に、サービスプロセッサ２０で実行される処理の一例について、図７に示すフローチャートを用いて説明する。この処理は、メインプロセッサ１０の第１コントローラ１０Ｃから障害発生通知がなされたときに実行される。なお、以下の説明において、ＭＰＵ２０Ａが行うこととして記述している処理は、ＭＰＵ２０Ａが処理するファームウェアの機能により実現される処理である。
【００３７】
ステップ２１は、サービスプロセッサ２０の第２コントローラ２０Ｃが、ＭＰＵ２０Ａで処理中のファームウェアに対し、ＡＬＩＶＥＩＮＴ割込み制御を行う。
ステップ２２は、ＭＰＵ２０Ａが、第２コントローラ２０Ｃからの割り込みに応じて、障害が発生したメインプロセッサ１０のＣＰＵ１０Ａに対する障害対処処理を行う。具体的にはＭＰＵ２０Ａは、メインプロセッサ１０から障害に関連する情報を収集してエラーログを生成したり、メインプロセッサ１０から収集した情報から障害原因を特定し、リモート制御で障害からのＣＰＵ１０Ａの復旧処理を行ったりする。例えば、ＭＰＵ２０Ａは、リモート制御によりＣＰＵ１０Ａに対して次のような処理を行うことができる。ＭＰＵ２０Ａは、第２コントローラ２０Ｃから割込み制御がなされたときには、メインプロセッサ１０のＣＰＵ１０Ａで動作するＯＳに対して復旧指示を行う。そして、ＭＰＵ２０Ａは、ＣＰＵ１０Ａで動作するＯＳが復旧指示を受け付けない状態のとき、すなわち、復旧指示をしてもＣＰＵ１０Ａの処理が正常動作に戻らず、個別監視機構から再び割込み制御がなされたときには、ＣＰＵ１０Ａの処理を強制的にリセットし、ＣＰＵ１０Ａの再起動を行う。ＭＰＵ２０Ａは、このように段階を分けて対処処理を行い、障害レベルに応じた適切な障害対処処理を行うことが可能である。
【００３８】
かかる情報処理装置によれば、メインプロセッサ１０に夫々設けられ、個別監視機構２として機能する第１コントローラ１０Ｃが、監視周期ごとに、処理機構１として機能するＣＰＵ１０Ａの稼働状態を監視する。そして、第１コントローラ１０Ｃは、ＣＰＵ１０Ａの稼動状態に基づいてＣＰＵ１０Ａに障害が発生しているか否かを判定する。ここで、第１コントローラ１０Ｃは、ＣＰＵ１０Ａに障害が発生していると判定したときにのみ、管理機構３として機能するサービスプロセッサ２０に通知を行う。このため、本情報処理装置は、メインプロセッサ１０の夫々からサービスプロセッサ２０に直接稼動状態を通知し、ＣＰＵに障害が発生しているか否かをサービスプロセッサ２０が判定する場合に比べ、次のような作用効果を奏する。すなわち、本情報処理装置では、各メインプロセッサ１０のＣＰＵ１０Ａの稼動状態に基づいて障害発生の有無を判定する処理を第１コントローラ１０Ｃが負担するため、サービスプロセッサ２０で障害発生の判定を行う必要がなく、サービスプロセッサ２０における処理量が減少する。さらに、ＣＰＵ１０Ａが正常稼動しているときには、メインプロセッサ１０からサービスプロセッサ２０に通知がなされないことから、サービスプロセッサ２０に対する通信量を減少させることができる。これらの結果、メインプロセッサ１０の数が多数である場合においても、サービスプロセッサ２０における処理負荷が軽減され、また、通信のトラフィック集中が回避される。したがって、サービスプロセッサ２０による障害対処処理の遅延を防ぐことが可能となる。また、サービスプロセッサ２０は、上述のように、メインプロセッサ１０のみならず、情報処理装置の他の装置の管理も行っているが、これらの管理に伴う処理の遅延も防ぐことができる。
【００３９】
なお、上記実施例では、対応するＣＰＵ１０Ａに障害が発生していると第１コントローラ１０Ｃにより判定されたときにのみ、メインプロセッサ１０からサービスプロセッサ２０に対して通知（第２チェックレジスタ２０Ｄへのデータコピー）を行っている。しかしながら、変形例として、例えば、第１コントローラ１０Ｃは、対応するＣＰＵ１０Ａに障害が発生していると判定したとき及び対応するＣＰＵ１０Ａには障害が発生していないと判定したときの両方において、その判定結果をサービスプロセッサ２０に通知してもよい。このようにした場合、上記実施例のように障害発生時のみ第１コントローラ１０がサービスプロセッサ２０に通知を行う方法に比べると、サービスプロセッサ２０に対する通信
量は多い。しかし、このようにしても、サービスプロセッサ２０側では、少なくとも、第１コントローラ１０Ｃによる判定結果のみを取得して処理を行うことができる。すなわち、複数のメインプロセッサ１０のＣＰＵ１０Ａの稼動状態を監視し、ＣＰＵ１０Ａに障害が発生したか否かを判定する処理を、サービスプロセッサ２０側で行う必要がない。したがって、その分だけサービスプロセッサ２０の処理負荷を軽減し、障害対処処理の遅延を防ぐことが可能である。また、例えば、サービスプロセッサ２０側から第１コントローラ１０にアクセスして判定結果を確認する方式を採用したとしても、同様に、少なくともサービスプロセッサ２０で障害発生有無の判定処理を行う必要がない分については、処理負荷の軽減を図ることができる。
【００４０】
さらに、上記実施例では、第１コントローラ１０Ｃが、第１チェックレジスタ１０ＤのＤＡＴＡフィールドの変化を監視して、ＣＰＵ１０Ａにおける障害発生の有無を判定している。しかし、このようにレジスタを用いる方法に限らず、少なくとも第１コントローラ１０ＣでＣＰＵ１０Ａの稼働状態を確認でき、障害発生の有無の判定処理を負担することができれば、サービスプロセッサ２０の処理負荷の軽減を図ることが可能である。
【００４１】
また、上記実施例では、ＣＰＵ１０Ａの処理により、タイマレジスタ１０Ｅに任意の監視周期を設定することができる。一方、タイマレジスタ１０Ｅには、ＣＰＵ１０Ａの処理に関わらず、予め監視周期を設定しておいてもよい。
さらに、上記実施例では、ＣＰＵ１０Ａがタイマレジスタ１０Ｅに「０」以外の監視周期を設定することで、第１コントローラ１０Ｃが監視処理を開始する一方、ＣＰＵ１０Ａがタイマレジスタ１０Ｅに「０」を設定することで、第１コントローラ１０Ｃが監視処理を終了させている。こうすることで、ＣＰＵ１０Ａは、タイマレジスタ１０Ｅを用いるだけで、第１コントローラ１０Ｃの監視処理の開始及び終了の制御を行うことができる。しかし、かかる方法に限らず、例えば、ＣＰＵ１０Ａが第１コントローラ１０Ｃを制御する指示（コマンド）を送信しても、第１コントローラ１０Ｃの監視処理を制御することは可能である。
【００４２】
なお、上記ハードウェア構成の例では、メインプロセッサ１０に含まれる各装置の制御を行う第１コントローラ１０Ｃに、さらに、タイマ機構及びレジスタを用いてＣＰＵ１０Ａの障害発生の有無を判定させ、個別監視機構２としての機能を実現させている。このようにすることで、個別監視機構２の機能を実現する物理的なハードウェアをさらに追加する必要がない。しかし、かかる構成に限らず、メインプロセッサ１０に障害発生の有無を判定する装置を別途設けても、サービスプロセッサ２０の処理負担を軽減することは当然に可能である。
【００４３】
≪第２実施例≫
次に、第１実施例の変形例として、メインプロセッサ１０からサービスプロセッサ２０に対し、障害が発生したときのＣＰＵ１０Ａにおける処理フェーズを通知する第２実施例について説明する。なお、第１実施例と重複する内容については、説明を省略する。
ＣＰＵ１０Ａは、適宜異なる処理フェーズの処理を実行している。第２実施例では、障害発生時にＣＰＵ１０Ａが実行していた処理フェーズをサービスプロセッサ２０に通知することにより、サービスプロセッサ２０で収集した情報に基づいて、障害発生時のＣＰＵ１０Ａの状態をより容易に判別可能としている。
【００４４】
図８は、第２実施例において、メインプロセッサ１０で実行される処理を示す。
ステップ３１では、ＣＰＵ１０Ａが、タイマレジスタ１０ＥのＩＮＴＥＲＶＡＬフィールドに、第１コントローラ１０ＣがＣＰＵ１０Ａの監視処理を行う監視周期を設定する。ＣＰＵ１０Ａは、監視周期として、ＣＰＵ１０Ａの現在の処理フェーズの処理に要する時間以上の周期を設定する。これは、次の理由による。
【００４５】
すなわち、ＣＰＵ１０Ａは監視周期が経過する前にＤＡＴＡフィールドを新たな値で書き換える必要があり、かつ、第２実施例では、次のステップ３２でＤＡＴＡフィールドに現在の処理フェーズを設定する。ここで、第１コントローラ１０Ｃは、ＤＡＴＡフィールドに設定された処理内容が監視前後で異なっているか否かを、監視周期ごとにＤＡＴＡフィールドを参照することで判別している。このため、第１コントローラ１０Ｃが適切にＣＰＵ１０Ａの障害発生有無を判別するためには、少なくとも監視周期が経過する前に、言い換えれば個別監視機構がＤＡＴＡフィールドを参照する前に、ＣＰＵ１０ＡがＤＡＴＡフィールドに設定する処理フェーズが変化している必要がある。ある時点で実行している処理フェーズの処理に要する時間以上の周期をＣＰＵ１０ＡがＤＡＴＡフィールドに設定することで、ＣＰＵ１０Ａが正常に動作している状況では、第１コントローラ１０ＣによるＤＡＴＡフィールド参照時には、ＣＰＵ１０Ａがある処理フェーズの処理を完了し、次の処理フェーズの処理をすでに開始していることが期待できる。その結果、ＣＰＵ１０ＡがＤＡＴＡフィールドに設定する処理フェーズを、第１コントローラ１０ＣによるＤＡＴＡフィールドの参照前後で異なるものとすることが可能となる。
【００４６】
ステップ３２では、ＣＰＵ１０Ａが、第１チェックレジスタ１０ＤのＤＡＴＡフィールドに、新たな稼動情報として、現在のＣＰＵ１０Ａによる処理フェーズを特定可能な情報であるフェーズコードを設定する。なお、図９は、フェーズコード及び対応する処理フェーズの具体例である。図９は特に、情報処理装置の起動時にＣＰＵ１０Ａが実行する初期診断の各処理フェーズを示している。
【００４７】
ステップ３３では、ＣＰＵ１０Ａが、処理フェーズの移行が発生したか否かを判定する。処理フェーズの移行が発生していれば、ステップ３４に進み（Ｙｅｓ），処理フェーズの移行が発生していなければ、そのまま待機し、再度ステップ３３の処理を繰り返す（Ｎｏ）。
ステップ３４では、ＣＰＵ１０Ａが、監視周期の設定を変更するか否かを判定する。ここで、監視周期を変更する場合とは、例えば、ＣＰＵ１０Ａにおける処理が進行して次の処理フェーズとなり、次の処理フェーズに要する時間が前の処理フェーズに要する時間と異なる場合が該当する。監視周期を変更するときには、ステップ３５に進み（Ｙｅｓ）、監視周期を変更しない場合には、ステップ３６に進む（Ｎｏ）。
【００４８】
ステップ３５では、ＣＰＵ１０Ａが、タイマレジスタ１０ＥのＩＮＴＥＲＶＡＬフィールドに、第１コントローラ１０ＣがＣＰＵ１０Ａの監視処理を行う監視周期を再設定（変更）する。ＣＰＵ１０Ａは、ステップ３１と同様、監視周期として、ＣＰＵ１０Ａの現在の処理フェーズの処理に要する時間以上の周期を設定する。
ステップ３６及びステップ３７は、ステップ４及びステップ５と同様であるため、説明を省略する。
【００４９】
なお、第１コントローラ１０Ｃの処理は、図６に示した処理と第１実施例の処理と同様であるが、第２実施例では、ステップ１４において、第１チェックレジスタ１０ＤのＤＡＴＡフィールドに稼動情報としてフェーズコードが設定されている。そして、第１チェックレジスタ１０Ｄのデータが、フェーズコードも含めて第２チェックレジスタ２０Ｄにコピーされる。このため、第２コントローラ２０Ｃは、第１コントローラ１０Ｃからコピーされたデータを参照することで、障害発生時におけるＣＰＵ１０Ａが実行していた処理の処理フェーズを特定することができる。
【００５０】
ここで、第２実施例の処理について、ＣＰＵ１０Ａにおける初期診断の処理フェーズ（図９）及び監視周期（図３（Ｃ））の具体例を示して説明する。ＣＰＵ１０Ａは、初期診断の処理フェーズの進行に応じて、第１チェックレジスタ１０ＤのＤＡＴＡフィールドに
、フェーズコードを「０１」から順に設定し、初期診断終了時には「７ｆ」を設定する。
例えば、ある監視時における処理フェーズがＣＰＵ動作確認テスト（フェーズコード：０３）である場合、ＣＰＵ１０Ａは、第１チェックレジスタ１０ＤのＤＡＴＡフィールドに、フェーズコード０３を設定する。また、ＣＰＵ１０Ａは、タイマレジスタ１０ＥのＩＮＴＥＲＶＡＬフィールドに、ＣＰＵ動作確認テストの処理に要する時間以上の時間に対応する監視時間コードを設定する。例えば、ＣＰＵ動作確認テストに要する処理時間が３０秒の場合、ＣＰＵ１０Ａはタイマレジスタ１０ＥのＩＮＴＥＲＶＡＬフィールドに、監視時間コード００００００１を設定する。そして、ＣＰＵ１０Ａが正常に動作しており、ＣＰＵ１０Ａの処理が次のフェーズであるＲＡＭ初期化（フェーズコード：０４）に移行した場合、ＣＰＵ１０Ａは、ＩＮＴＥＲＶＡＬフィールドに設定された監視周期が経過する前に、第１チェックレジスタ１０ＤのＤＡＴＡフィールドに、移行したＲＡＭ初期化処理に対応するフェーズコード０４を設定する。
【００５１】
一方、第１コントローラ１０Ｃは、前回の監視処理から監視周期３０秒が経過したとき、第１チェックレジスタ１０ＤのＤＡＴＡフィールドを参照する。フェーズコードが０３から０４に変化していることを第１コントローラ１０Ｃが確認した場合、第１コントローラ１０ＣはＣＰＵ１０Ａの監視を続行する。この場合、第１コントローラ１０Ｃは、サービスプロセッサ２０に対し、特に通知を行わない。
【００５２】
一方、図９の例において、ＣＰＵ１０Ａの処理に異常が発生し、ＣＰＵ１０Ａにおける処理フェーズがＣＰＵ動作確認テストから次の処理フェーズに移行しない場合、第１チェックレジスタ１０ＤのＤＡＴＡフィールドは、監視周期３０秒が経過しても、フェーズコード０３のままである。このため、ＤＡＴＡフィールドを参照した第１コントローラ１０Ｃは、ＣＰＵ１０Ａに異常が発生していることを検出する。この場合、第１チェックレジスタ１０ＤのＤＡＴＡフィールドにはフェーズコード０３が設定されているため、ＤＡＴＡフィールドのデータを第２チェックレジスタ２０Ｄにコピーすることで、サービスプロセッサ２０は、第２チェックレジスタ２０Ｄを参照して障害発生時のＣＰＵ１０Ａの処理フェーズに対応したフェーズコードを識別することができる。
【００５３】
このように、第２実施例においては、サービスプロセッサ２０では、第２チェックレジスタ２０Ｄに設定されたフェーズコードから、障害発生時におけるメインプロセッサ１０のＣＰＵ１０Ａの処理フェーズを特定することができる。そして、このように処理フェーズを特定することにより、サービスプロセッサ２０では、障害内容の診断等を的確に行うことができ、迅速な復旧処理につながる。
【００５４】
また、通常、処理フェーズによって処理に要する時間が異なるが、第２実施例では、ＣＰＵ１０Ａが処理フェーズに応じて監視周期を変更することができるため、このように処理フェーズの変化を監視する監視処理においても正常に障害発生の有無を判定することができる。なお、このように第１コントローラ１０Ｃにおける監視周期をＣＰＵ１０Ａ側で変更する処理は、ＤＡＴＡフィールドに処理フェーズを設定する場合に限らなくても適用可能である。
【００５５】
≪第３実施例≫
次に、第１実施例及び第２実施例におけるさらなる変形例として、サービスプロセッサ２０がメインプロセッサ１０における監視処理を停止させる処理を行う第３実施例について説明する。
【００５６】
第１実施例及び第２実施例では、メインプロセッサ１０において、ＣＰＵ１０Ａが、第１コントローラ１０Ｃによる監視処理を終了させていた。しかし、情報処理装置に対する電源供給が遮断された場合、メインプロセッサ１０の第１コントローラ１０Ｃやサービスプロセッサ２０等の管理系装置が継続して動作する一方で、ＣＰＵ１０Ａの動作が先に停
止する特定の状態が生じ得る。情報処理装置に対する電源供給が遮断される例としては、停電が発生したり、情報処理装置のリブートや電源切断が行われたりした場合がある。この場合、ＣＰＵ１０Ａの動作は、自装置の監視処理を終了させる間もなく停止してしまう。このため、ＣＰＵ１０Ａの動作が停止している一方で、第１コントローラ１０Ｃによる監視処理が継続することとなる。ここで、このように情報処理装置の電源供給が遮断された場合には、原則として情報処理装置の全てのＣＰＵ１０Ａの動作が停止することとなる。すると、次のような問題が生じる。すなわち、情報処理装置の全てのＣＰＵ１０Ａは、監視周期が経過しても、第１チェックレジスタ１０ＤのＤＡＴＡフィールドに新たな稼働情報を設定することができない。このため、全てのＣＰＵ１０Ａに対応する第１コントローラ１０Ｃが、監視周期が経過したときに、ＣＰＵ１０Ａに障害が発生したと判断し、サービスプロセッサ２０に対して障害発生通知を行うこととなる。そうすると、サービスプロセッサ２０に対する通信のトラフィックが集中するとともに、サービスプロセッサ２０の処理負荷が増大してしまう。
また、特に、ユーザが意図的に情報処理装置のリブートや電源切断等を行った場合等には、ＣＰＵ１０Ａの動作が停止しても、本来、障害発生として検出する必要がない。しかし、このような場合であっても、第１コントローラ１０Ｃにおいて障害発生が検出され、障害発生通知が行われることとなる。
【００５７】
したがって、第３実施例では、情報処理装置に対する電源供給が遮断された場合に、サービスプロセッサ２０側から、第１コントローラ１０Ｃにおける監視処理を終了させるようにする。なお、サービスプロセッサ２０は、前述したように情報処理装置の電源ユニットの管理を行う機能を有しているため、情報処理装置に対する電源供給が遮断された状態を検出することができる。第１実施例及び第２実施例と重複する内容については、説明を省略する。
【００５８】
図１０は、第３実施例において、サービスプロセッサ２０で実行される処理の一例を示す。
ステップ４１では、第２コントローラ２０Ｃが、情報処理装置に対する電源供給が遮断された状態を検出する。
ステップ４２では、第２コントローラ２０Ｃが、第１コントローラ１０Ｃのタイマレジスタ１０Ｅの監視時間に「０（ゼロ）」（特定値）を設定する。
このサービスプロセッサ２０におけるステップ２２の処理が行われると、メインプロセッサ１０の第１コントローラ１０Ｃは、タイマレジスタに「０（ゼロ）」が設定されていることを検出し（図６のステップ１３  Ｙｅｓ）、監視処理を終了する（図６のステップ１８）。
【００５９】
かかる第３実施例におけるサービスプロセッサ２０の処理によれば、情報処理装置における電源供給が遮断されることによりＣＰＵ１０Ａの動作が停止した場合に、サービスプロセッサ２０から、第１コントローラ１０Ｃの監視処理を停止させることができる。このため、サービスプロセッサ２０に対する通信のトラフィックの集中や、サービスプロセッサ２０の処理負荷の増大を回避することができる。また、特に、ユーザが意図的に情報処理装置のリブートや電源切断等を行った場合等に、不必要な監視処理及び障害対処処理が発生することを回避することもできる。
【００６０】
なお、ＣＰＵ１０Ａが第１コントローラ１０Ｃの監視処理を制御する場合と同様、サービスプロセッサ２０が第１コントローラ１０Ｃの監視処理を停止させる方法は、タイマレジスタ１０Ｅに特定値を設定する方法に限らず、他の制御方法であってもよい。
【符号の説明】
【００６１】
１  処理機構
２  個別監視機構
３  管理機構
１０  メインプロセッサ
１０Ａ  ＣＰＵ
１０Ｂ  ＲＡＭ
１０Ｃ  第１コントローラ
１０Ｄ  第１チェックレジスタ
１０Ｅ  タイマレジスタ
１０Ｆ  ＲＯＭ
２０  サービスプロセッサ
２０Ａ  ＭＰＵ
２０Ｂ  ＲＡＭ
２０Ｃ  第２コントローラ
２０Ｄ  第２チェックレジスタ
２０Ｅ  ＲＯＭ
【図１】
2011181064.tif 000003
【図２】
2011181064.tif 000004
【図３】
2011181064.tif 000005
【図４】
2011181064.tif 000006
【図５】
2011181064.tif 000007
【図６】
2011181064.tif 000008
【図７】
2011181064.tif 000009
【図８】
2011181064.tif 000010
【図９】
2011181064.tif 000011
【図１０】
2011181064.tif 000012