JP2008176708A - 情報処理装置 - Google Patents

Abstract

【課題】ファームウェアを書き込むフラッシュROMなどに物理的なビット欠陥がある場合など、新規ファームウェアレビジョンを書き込む事により、ファームウェアコードが該当ビットにより異常となった場合、遠隔地から自動でリカバリを行うシステムを提供する。
【解決手段】サーバモジュール(200,210,220)を管理するサービスプロセッサ100が、障害とそれに対応する診断プログラム101の対応表105や、スロットと挿入されているサーバモジュールの対応表104を保持することで、複数のサーバモジュールの種類に応じたリカバリ用のFDイメージを選択し、サーバモジュール上にUSBストレージとして識別されるメモリを持ったデータの送受信可能な装置201に選択したリカバリ用のFDイメージを転送し、仮想的にFDブートを行うことで自動的なリカバリ処理が可能となる。
【選択図】図１

Description

本発明は、情報処理装置に係り、特に障害発生時の診断処理に関する。

複数機器のファームウェアのアップデートを相違なく、漏れなく行う方法としては、システムを管理する装置が機器の情報を取得して、取得した情報からアップデートを行う必要があるものを選択し、選択した複数の機器のアップデートを自動で行う方法がある。

この方法の従来技術としては、特許文献１に記載の「ファームウェアファイル更新制御方法及び保守システム」がある。この従来技術は、システムを管理する装置であるオペレーションシステムのデータベースで、機器を構成する装置に関する設備情報、更新の計画情報、更新用ファームウェアファイル、及びバージョン情報などのファームウェアファイル付属情報を管理することにより、ファームウェアファイル更新時には、前記オペレーションシステムの設備情報からファームウェアファイルを更新すべき装置が自動的に選出され、更新が行われる。これにより、ファームウェアファイル更新対象装置の選出漏れがなくなり、ファームウェアファイルの更新が確実に行われる。

特開平７−２４８９１３号公報

しかしながら、上記の従来技術ではファームウェア更新中に書き込みエラーが発生した場合、遠隔地から自動でリカバリを行うことは困難であるという問題がある。ファームウェアを書き込むフラッシュＲＯＭなどに物理的なビット欠陥がある場合など、新規ファームウェアレビジョンを書き込む事により、ファームウェアコードが該当ビットにより異常となり、運用を継続させるために元のファームウェアに一旦書き戻す方法などが、リカバリ処理として行われる。

本発明は、上記の問題点を解消するためのものであり、書き込みエラーなどの障害から自動でリカバリを行う情報処理装置を提供することにある。また、複数種類のサーバモジュールが搭載された装置においても、これらアップデート、リカバリのプログラムを自動で選択し、実施する情報処理装置を提供することにある。

上記の従来技術の問題点を解決するための本発明は、サーバモジュール上にＵＳＢストレージとして識別されるメモリを持ったデータの送受信可能な装置を持ち、その装置にリカバリ用のＦＤイメージを転送し、仮想的にＦＤブートを行うことでアップデートを可能とする。また、サーバモジュールを管理するサービスプロセッサが、アップデート時の障害を検出し、リカバリ用のＦＤイメージを転送することで、自動的なリカバリ処理が可能となる。
さらに、その他の障害に対応した診断プログラム用のＦＤイメージを準備することで、同じシステムで書き込みエラー以外の装置の診断により、装置故障時の対応を自動化することが可能である。
また、サーバモジュールを管理するサービスプロセッサが、障害とそれに対応する診断プログラムの対応表や、スロットと挿入されているサーバモジュールの対応表を保持することで、複数のサーバモジュールの種類に応じた処理の自動化が可能となる。

本発明によれば、サーバモジュールに障害が発生した場合、障害に対応した診断プログラムの起動を自動化することが可能となる。また、複数のサーバモジュールから障害が発生したサーバモジュールを特定し、障害に対応した診断プログラムの起動を自動化することが可能となる。したがって、人手を介さないことで診断プログラムの選択ミスの防止や、保守時間の短縮を図ることができる。さらに、その診断結果に従い、障害が発生した装置の縮退や、オペレータへの障害情報の通知も可能となる。

図面に基づいて本発明の一実施例を説明する。図１は、情報処理装置のブロック構成図である。本情報処理装置は、サービスプロセッサ(以下SVPと称す)100、複数のサーバモジュール200,210,220、および双方向伝達手段300,301とで構成される。SVP100は情報処理装置全体の管理、監視を行う装置であり、複数の診断プログラム101、複数のアップデート用ファームウェア(以下、単にファームウェアと称す)102、および制御プログラム103を保持している。

診断プログラム101と、ファームウェア102は、診断プログラム起動用バッチファイル、および、ファームウェアアップデート用バッチファイルと共にFDイメージとして格納される。制御プログラム103は、障害が発生したサーバモジュールの特定を行うためのスロット情報対応表104と、障害に対応する診断プログラム101の選択を行うための診断プログラム対応表105を保持し、選択したプログラムの転送を行う。また、診断プログラムの実行結果から、装置の状態に合わせた処理を行う。

SVP100は制御プログラム103により、FDイメージを、LANなどの双方向伝達手段301によりサーバモジュールのUSBストレージ201へ転送する。USBストレージ201は、メモリを持ちデータの送受信が可能な装置である。サーバモジュールA 200のプロセッサ(以下CPUと称す)203は、USBストレージ201に格納されたFDイメージにより仮想的にFDブートを行い、診断プログラム101の起動やファームウェア102のアップデートを行う。プログラム実行後、結果を障害診断情報208としてBaseboard Management Controller(以下BMCと称す)205に格納する。診断終了後、サーバモジュールA 200のCPU203は、通常起動する場合は磁気ディスク装置(以下HDDと称す)202より通常起動処理を行う。BIOS204は、HDD202を制御するプログラムである。

BMC205は、サーバモジュールを監視する装置である。障害診断情報208の他に、発生した障害に関する発生時刻や障害の種別といった情報を格納したlog206や、各サーバモジュールを識別するためのモジュール識別情報207を格納する。以上、サーバモジュールA 200についての構成を説明したが、サーバモジュールB 210、サーバモジュールC 220も、同様の構成を有する。

次に、サーバモジュールにおける障害診断方法について説明する。障害発生後から診断結果に基づくサーバモジュール起動までのフロー図を図２に示す。サーバモジュールA 200に障害が発生すると(S400)、BMC205はlog(206)を取得する(S401)。SVP100は、LANなどの双方向伝達手段300を使用し、ポーリングを行うことでBMC205に格納された新規追加分のlog206、およびモジュール識別情報207を取得する(S402)。図３にモジュール識別情報207、及び図４にスロット情報対応表104の例を示す。BMC205で保持するモジュール識別情報207は、転送先サーバモジュールA 200を識別する情報と、モジュール種別を示す情報とする。その一例として、例えば、シリアルナンバのような各サーバモジュールを管理するための固有の値であるモジュールIDと、モジュールの種別であるType1,Type2を記録したモジュール識別情報207とした。SVP100は、サーバモジュールが差し込まれているスロットと対応するサーバモジュールA 200、B 210、C 220を特定するためにスロット情報対応表104を保持する。スロット情報対応表104は、スロット番号に対して、挿入されているサーバモジュールの属性を関連付けた表であり、スロット番号１に対して、サーバモジュールA 200のモジュール識別情報207であるモジュールID BD001、モジュール種別Type1が記録される。スロット番号２に対しては、同様に、サーバモジュールB 210のモジュールID BD002、モジュール種別Type1、スロット番号３に対しては、同様に、サーバモジュールC 220のモジュールID AC001、モジュール種別Type2が記録される。スロット情報対応表104の更新契機は、サーバモジュールの抜き差しを行う際とする。

ポーリングによる情報取得後、制御プログラム103はスロット情報対応表104と、取得したモジュール識別情報207を比較し、障害が発生したサーバモジュールが挿入されているスロットがスロット番号１であると特定する。また、log206から障害内容を解析し(S403)、SVP100で保持する診断プログラム対応表105より、発生した障害に対応する診断プログラム101のFDイメージを選択する(S404)。図５に診断プログラム対応表105の例を示す。診断プログラム対応表105は、BMC205から取得した情報を元に障害に対応した診断プログラム101を選択するための情報であり、SVP100で保持する。図５では、障害種別と、モジュールの種別Type1,Type2により、対応する診断プログラムが関連付けられている。たとえば、モジュール種別がType1のサーバモジュールで、CPUエラーが発生した場合には、CPUテストAが対応付けられ、診断プログラム101として選択されることを示している。

診断プログラム101の選択後、制御プログラム103は、起動用バッチファイルと診断プログラム101によりFDイメージを作成し、障害が発生したサーバモジュールのUSBストレージ201にFDイメージを転送する(S405)。FDイメージ転送後、Power Off/Onにより、USBストレージ201に格納されたFDイメージから仮想的にFDブートを行い(S406)、CPU203は診断プログラム101を実行する(S407)。診断終了後、診断結果を障害診断情報208としてBMC205に格納する(S408)。その後、SVP100はポーリングを行いBMC205に格納された新規追加分の障害診断情報208を取得する(S409)。取得した障害診断情報208から制御プログラム103は、サーバモジュールA 200が稼動可能か否かを判定する(S410)。稼動可能な場合、その処理の一例として、制御プログラム103がBMC205に障害が発生したCPUの縮退を指示し、BMC205はその装置の縮退を行う(S411)。その後、HDD202より通常の起動処理を行い(S412)、サーバモジュールA 200を起動する(S413)。また、稼動不可能な場合は、例えばメールなどでオペレータに障害の通知を行う(S414)。なお、メモリエラーの場合も同様にメモリの縮退を行う。

次に、ファームウェア更新方法について説明する。図６は、サーバモジュールA 200、およびB 210、C 220でのファームウェア更新成功時のフロー図である。サーバモジュールA 200及びサーバモジュールB 210は、同一種類 Type1のモジュールであり、同一のファームウェアイメージ１が使用可能である。またサーバモジュールC 220については、Type2用のファームウェアイメージ２を使用可能である。まず、オペレータはアップデート用のファームェア１、ファームェア２を、ファームウェア102としてSVP100に格納する(S500)。SVP100は各サーバモジュール(200,210,220)に対してポーリングを行い、BMC205に格納されたモジュール識別情報207を取得する(S501)。取得したモジュール識別情報207より、制御プログラム103は、サーバモジュールごとに対応したアップデート用のファームウェア102のFDイメージを選択し、それぞれのUSBストレージ201に転送する(S502)。たとえば、サーバモジュールA 200、B 210に対しては、モジュール識別情報がType1であるため、ファームウェアイメージ１が選択される。サーバモジュールC 220に対しては、モジュール識別情報がType2であるため、ファームウェアイメージ２が選択される。FDイメージ転送後、Power Off/Onにより、USBストレージ201に格納されたFDイメージから仮想的にFDブートを行い(S503)、ファームウェアアップデートを行う(S504)。

アップデート終了後、結果をlog206としてBMC205に格納する(S506)。その後、SVP100はポーリングを行いBMC205に格納された新規追加分のlog206を取得する(S507)。取得したlog206から制御プログラム103はファームウェアアップデートの成功を判別し(S508)、通常起動する(S509,S510)。図６では、サーバモジュール３台を例として説明したが、さらに複数のサーバモジュールが挿入されている場合でも同様の処理を行い、自動的にファームウェアのアップデートが可能である。

次に、ファームウェアのアップデートに失敗した場合について説明する。例として、サーバモジュールA 200でファームウェアの書き込みエラーが発生したものとする。ファームウェアの書き込みエラーが発生した場合は、図２で説明した障害発生後の処理と同様の処理でリカバリを行うことが可能である。ファームウェアアップデート失敗時のフロー図を図７に示す。

ファームウェアアップデート後のlog取得までの処理は上に説明した図６と同様である(S600〜S607)。BMC205は、アップデートの失敗を検出し、log206に記録する。BMC205によるファームウェアアップデートの障害検出方法は、所定時間内にシステムが起動しないタイムアウトなどの方法を用いても良い。取得したlog206を元に、制御プログラム103は発生した障害の解析を行い(S608)、送信先スロットと診断プログラム101の選択を行う(S609)。送信先スロットは図４を例にすると、スロット１となる。診断プログラム101は、図５を例にすると、サーバモジュールの種別がType1に対応したリカバリAとなる。リカバリは、例えばアップデート前のファームウェアの書き込みなどを行う。リカバリAのFDイメージ転送後、USBストレージ201に格納されたFDイメージから仮想的にFDブートを行い(S610)、リカバリを実行する(S611)。リカバリ終了後の処理は図２と同様で、成功の場合は通常起動、失敗の場合はオペレータに通知を行う。

以上の説明のとおり、従来のシステムでは障害発生後、logからオペレータが障害の内容を解析し、手動で診断プログラムを起動していたが、上記本発明の実施例によれば、サーバモジュールを管理するサービスプロセッサが障害の内容を解析し、自動で診断プログラムを起動することができる。このように、障害診断を自動化することで、診断プログラムの選択ミスの防止や、保守時間を短縮できるという効果が得られる。さらに、その診断結果に従い、障害が発生した装置の縮退や、オペレータへ障害情報の通知も行うことができる。

また、従来のPXE方式などでBIOSのアップデートを行う場合は、Non Bootブロック(アップデート時に書き換えるエリア)まで起動する必要がある。そのため、BIOSアップデートに失敗した場合に動作できなくなってしまう。しかし、上記本発明の実施例による障害診断処理では、Bootブロック(アップデート時に書き換えない固定のエリア。Bootに最低限必要な基本的な処理を格納)までの起動でよく、それ以後はFDイメージに処理を書き込んでおけばよいため、BIOSアップデートに失敗した場合のリカバリが可能である。また、障害が発生した場合、障害やサーバモジュールに対応した診断プログラムをFDイメージとして準備しておけば障害の診断にも応用可能である。

本発明の実施例による情報処理装置のブロック構成図である。 障害発生後から診断結果に基づくサーバモジュール起動までのフロー図である。 モジュール識別情報を示す図である。 スロット情報対応表である。 モジュールの種別、障害種別による診断プログラム対応表である。 ファームウェアアップデート成功時のフロー図である。 ファームウェアアップデート失敗時のフロー図である。

符号の説明

100…SVP、101…診断プログラム(FDイメージ)、102…ファームウェア(FDイメージ)、
103…制御プログラム、104…スロット情報対応表、105…診断プログラム対応表、
200…サーバモジュールA、201…USBストレージ、202…HDD、203…CPU、204…BIOS、205…BMC、206…log、207…モジュール識別情報、208…障害診断情報、
210…サーバモジュールB、220…サーバモジュールC、300…双方向伝達手段(SVP-BMC)、
301…双方向伝達手段(SVP-USBストレージ)。

Claims (4)

1. プロセッサと、ＵＳＢストレージと、障害検出手段とを有するサーバモジュールと、
   複数の診断プログラムと、複数のアップデート用ファームウェアを保持するサービスプロセッサと、を有し、
   前記サービスプロセッサは、前記障害検出手段が障害を検出した場合、前記サーバモジュールから障害情報を取得して障害内容を解析し、解析した結果に基づいて前記複数の診断プログラムの中から障害に対応した診断プログラムを選択して前記ＵＳＢストレージに送信し、
   前記プロセッサは、前記ＵＳＢストレージに格納された診断プログラムを実行し、
   前記サービスプロセッサは、前記診断プログラム実行後の診断情報を取得して、前記サーバモジュールに障害発生部位の縮退を指示することを特徴とする情報処理装置。
2. 前記診断プログラムはＦＤイメージにて送信され、前記ＵＳＢストレージに格納された後、起動されることを特徴とする請求項１記載の情報処理装置。
3. 前記サービスプロセッサは、前記アップデート用ファームウェアを前記サーバモジュールに送信した後、前記アップデート用ファームウェアのアップデートが失敗したことを認識した場合、前記複数の診断プログラムの中からリカバリに使用する診断プログラムを選択して前記ＵＳＢストレージに送信し、
   前記プロセッサは、前記ＵＳＢストレージに格納されたリカバリ用の診断プログラムを実行し、
   前記サービスプロセッサは、前記リカバリが成功したことを認識した場合、前記サーバモジュールに起動を指示することを特徴とする請求項１記載の情報処理装置。
4. 前記サーバモジュールを複数個有し、前記サービスプロセッサは、前記複数個のサーバモジュールのいずれかから障害情報を取得した場合、障害情報に含まれるサーバモジュールの識別情報から障害が発生したサーバモジュールを特定することを特徴とする請求項１記載の情報処理装置。

Images