(57)【要約】【課題】ハードウェア障害時にシステムが再起動するまでに要する時間を短縮することのできる情報処理装置を提供する。【解決手段】ＰＯＳＴ時間を測定し、この測定したＰＯＳＴ時間に所定のマージンを加えた時間を、次回のシステム起動時のウォッチドッグ・タイマ１２のタイムアウト時間として設定する。また、システムの起動回ごとに、メインメモリ６の容量を確認し、この確認したメモリ容量に応じたタイムアウト時間をウォッチドッグ・タイマ１２に設定する。これにより、ハードウェアの構成に合わせた過不足の少ないタイムアウト時間を設定でき、ハードウェア障害時のシステムの再起動時間を大幅に短縮できる。【選択図】図１
2005165415.tif 000002
【特許請求の範囲】
【請求項１】
電源の投入を契機に、システムの起動に先立ちハードウェアの機能テストを実行するテスト実行手段と、
前記機能テストのタイムアウトを監視して前記システムを再起動に導くタイムアウト監視手段と、
前記システムを起動させる回ごとに、前記ハードウェアの構成に係る実測値を取得し、この実測値に応じたタイムアウト時間を前記タイムアウト監視手段に設定するタイムアウト時間設定手段と
を具備することを特徴とする情報処理装置。
【請求項２】
前記タイムアウト時間設定手段は、
前記テスト実行手段による前記機能テストに要した時間を測定し、この時間測定結果に所定のマージンを加えた時間を、次回のシステム起動時の前記タイムアウト監視手段のタイムアウト時間として設定する
ことを特徴とする請求項１に記載の情報処理装置。
【請求項３】
前記ハードウェアがメインメモリを含むものであり、
前記タイムアウト時間設定手段は、
前記メインメモリの容量を確認し、このメインメモリの容量に応じたタイムアウト時間を前記タイムアウト監視手段に設定する
ことを特徴とする請求項１に記載の情報処理装置。
【請求項４】
電源の投入を契機に、システムの起動に先立ちハードウェアの機能テストを実行するステップと、
前記システムを起動させる回ごとに、前記ハードウェアの構成に係る実測値を取得するステップと、
前記取得した実測値に応じたタイムアウト時間を設定するステップと、
前記設定されたタイムアウト時間に基づいて前記機能テストのタイムアウトを監視し、タイムアウトが発生したとき、前記システムを再起動させるステップと
を具備することを特徴とするシステム起動方法。
【請求項５】
電源の投入を契機に、システムの起動に先立ちハードウェアの機能テストを実行するテスト実行手段と、
前記機能テストのタイムアウトを監視して前記システムを再起動に導くタイムアウト監視手段と、
前記システムを起動させる回ごとに、前記ハードウェアの構成に係る実測値を取得し、この実測値に応じたタイムアウト時間を前記タイムアウト監視手段に設定するタイムアウト時間設定手段として
コンピュータを機能させることを特徴とするシステム起動プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、サーバなどに用いられる情報処理装置と、この情報処理装置においてシステムをハードウェアの機能テストなどを通して起動させるシステム起動方法、およびシステム起動プログラムに関する。
【背景技術】
【０００２】
サーバなどに用いられる情報処理装置においては、電源が投入された後、オペレーティング・システムのブートに先立って、ハードウェアの機能テストのための初期診断プログラム(以下、ＰＯＳＴ：Power On Self Test)が実行される。
【０００３】
このＰＯＳＴには、ウォッチドッグ・タイマ（watchdog timer）が用いられる。ウォッチドッグ・タイマは、一定のタイムアウト時間を持っており、ＰＯＳＴの開始とともにタイマーがスタートし、ＰＯＳＴの完了を受けてタイマーがストップする。ＰＯＳＴでは、ＣＰＵ（Central Processing Unit)、メインメモリ、ディスクコントローラ、グラフィックスコントローラ、シリアル／パラレルポート、キーボードコントローラなど、マザーボード上の各デバイスに関する診断を行っており、ハードウェアの障害によってデバイスからの応答が無ければ、いずれウォッチドッグ・タイマがタイムアウトとなり、自動復旧のためにシステムの再起動が実行される（たとえば特許文献１を参照）。
【０００４】
また、ウォッチドッグ・タイマに関する別の従来の技術として、タイムアウト時間の最適時間調定モードを設け、この調定モードにおいて、タイムアウトが発生した場合のタイムアウト時間をモニタリングし、モニタリングしたタイムアウト時間が通常動作モードで使用するタイムアウト時間より長い場合には、モニタリングしたタイムアウト時間を通常動作モードで使用するタイムアウト時間として書き換えることで、接続機器などの変更に合せて、ウォッチドッグ・タイマの最適なタイムアウト時間を設定する技術がある（たとえば特許文献２を参照）。
【特許文献１】特開２００１−９２６８９号公報
【特許文献２】特開２００２−１４０２０９号公報
【発明の開示】
【発明が解決しようとする課題】
【０００５】
通常、ウォッチドッグ・タイマのタイムアウト時間は、ＰＯＳＴ時間に対して十分なマージンを加味して決められている。しかしながら、このように大きなマージンが確保されている分、ハードウェア障害時にシステムが再起動するまでに長い時間が掛かってしまうという弊害が伴っている。また、特許文献２は、ハードウェア構成に合せて最適なタイムアウト時間を設定するものであるが、これは、接続機器の追加などによって現状のタイムアウト時間では不足する場合に、その不足分を加味してタイムアウト時間を長い時間に設定する技術であり、ハードウェア障害時にシステムが再起動するまでの時間短縮を目的とする場合には不適当である。
【０００６】
本発明は、このような課題を解決するためになされたものであり、タイムアウト時間をハードウェアの構成に合わせて最適化することができ、ハードウェア障害時にシステムが再起動するまでに要する時間を短縮することのできる情報処理装置、システム起動方法、およびシステム起動プログラムを提供することを目的としている。
【課題を解決するための手段】
【０００７】
上記課題を解決するために、本発明に係る情報処理装置は、電源の投入を契機に、システムの起動に先立ちハードウェアの機能テストを実行するテスト実行手段と、機能テストのタイムアウトを監視してシステムを再起動に導くタイムアウト監視手段と、システムを起動させる回ごとに、ハードウェアの構成に係る実測値を取得し、この実測値に応じたタイムアウト時間をタイムアウト監視手段に設定するタイムアウト時間設定手段とを具備するものである。
【０００８】
より具体的には、タイムアウト時間設定手段は、テスト実行手段による機能テストに要した時間を測定し、この時間測定結果に所定のマージンを加えた時間を、次回のシステム起動時のタイムアウト監視手段のタイムアウト時間として設定するものである。
【０００９】
あるいは、タイムアウト時間設定手段は、メインメモリの容量を確認し、このメインメモリの容量に応じたタイムアウト時間をタイムアウト監視手段に設定するものであってもよい。
【００１０】
本発明は、このような構成を有することにより、タイムアウト監視手段のタイムアウト時間をハードウェアの構成に合わせて最適化することができ、ハードウェア障害時にシステムが再起動するまでに要する時間を短縮することができる。
【００１１】
特に、テスト実行手段による機能テストに要した時間に所定のマージンを加えた時間を、次回のシステム起動時のタイムアウト時間として設定することで、ハードウェアの構成に合わせた過不足の少ないタイムアウト時間を設定でき、ハードウェア障害時のシステムの再起動時間を大幅に短縮できる。
【００１２】
また、機能テストに要する時間はメモリ容量に大きく左右されるので、このメインメモリの容量に応じたタイムアウト時間を設定することによって、過不足の少ないタイムアウト時間を設定でき、ハードウェア障害時のシステムの再起動時間を大幅に短縮できる。
【発明の効果】
【００１３】
本発明の情報処理装置、システム起動方法、およびシステム起動プログラムによれば、タイムアウト監視手段のタイムアウト時間をハードウェアの構成に合わせて最適化することができ、ハードウェア障害時にシステムが再起動するまでに要する時間を短縮することができる。
【発明を実施するための最良の形態】
【００１４】
以下、図面を参照して本発明の実施の形態について説明する。
【００１５】
図１は、本発明の第一の実施形態に係る情報処理装置の構成を示すブロック図である。
【００１６】
同図に示すように、この情報処理装置１００においては、ＣＰＵ（Central Processing Unit)１、ＲＯＭ（Read Only Memory）２、フラッシュＲＯＭ３、および、たとえばＭＣＨ（Memory Controller Hub)などのメモリ接続制御部４が、ホストバス５を通じて互いに接続されている。ＲＯＭ２には、システムのブートシーケンスを含むＢＩＯＳプログラムなどが格納されている。ブートシーケンスには、ＰＯＳＴをはじめ、ＰＯＳＴに要した時間（ＰＯＳＴ時間）を計測してこの計測結果に基づいてウォッチドッグ・タイマのタイムアウト時間を最適化するための処理手順１３が含まれている。フラッシュＲＯＭ３には、上記タイムアウト時間を最適化する処理手順１３によって得られた前回のＰＯＳＴ時間の実測値１４、およびシステムＢＩＯＳの設定情報（図示せず）などが記憶される。
【００１７】
メモリ接続制御部４は、たとえば、ＣＰＵ１とメインメモリ６との情報のやりとりを制御するコントローラである。メモリ接続制御部４には、ＨＩ(Hub Interface）などの専用バス７を通じてたとえばＩＣＨ（I/O Controller Hub）などのＩ／Ｏ制御部８が接続されている。このＩ／Ｏ制御部８は、たとえばＰＣＩ（Peripheral Component Interconnect)バス、ＩＤＥ（Integrated Drive Electronics）バス、ＵＳＢ（Universal Serial Bus）バスなどの外部機器１５，１６の接続用のバス９を制御するコントローラである。
【００１８】
Ｉ／Ｏ制御部８には、ＬＰＣ（Low Pin Count）バス等の専用バス１０を通じて、たとえばＢＭＣ (Baseboard Management Controller) などの運用管理部１１が接続されている。この運用管理部１１は、たとえば、システム運用中の稼動状態の監視、温度、電圧／電流、ファンなどの異常の監視、ウォッチドッグ・タイマ（ＷＴ：Watchdog Timer）１２による障害発生時の保守（復旧）などを行う。運用管理部１１は、具体的には、ＣＰＵと、このＣＰＵに実行させるプログラムが格納されたＲＯＭと、システム運用中の監視結果を蓄積する記憶部などで構成されている。
【００１９】
この情報処理装置１００では、電源が投入されると、ＣＰＵ１は、フラッシュＲＯＭ３からシステムのブートシーケンスを含むＢＩＯＳプログラムを読み込み、このＢＩＯＳプログラムに従ってブートシーケンスを実行し、ハードディスクドライブなどの起動ドライブに格納されたオペレーティングシステムをブートする。
【００２０】
以下に、このブートシーケンスの詳細な流れを図２および図３を参照して説明する。
【００２１】
図２はＣＰＵ１の側の処理手順、図３は運用管理部１１の側の処理手順である。
【００２２】
電源が投入されると、ＣＰＵ１は、ＢＩＯＳプログラムのブートシーケンスに従って、まず、ＰＯＳＴを起動し、メモリ接続制御部４、Ｉ／Ｏ制御部８を通じて運用管理部１１にウォッチドッグ・タイマ１２の起動要求を行う。このとき、ＣＰＵ１は、ブートシーケンスに含まれる、ウォッチドッグ・タイマのタイムアウト時間を最適化する処理手順１３に従って、フラッシュＲＯＭ３から前回のＰＯＳＴ時間の実測値１４を読み込み（図２，ステップ２０１）、この前回のＰＯＳＴ時間の実測値１４に所定のマージンを加えた時間をウォッチドッグ・タイマ１２に設定すべき新たなタイムアウト時間として生成し（ステップ２０２）、この新たなタイムアウト時間をウォッチドッグ・タイマ１２の起動要求とともに運用管理部１１に通知する（ステップ２０３）。ここで、前回のＰＯＳＴ時間の実測値１４に加えるマージン時間はたとえば２０秒程度とする。もちろん、このマージン時間は適宜変更できることが好ましい。なお、ＰＯＳＴ時間の実測値１４については後で説明する。
【００２３】
一方、運用管理部１１は、ＣＰＵ１からのウォッチドッグ・タイマ１２の起動要求を受けると、これに付加されているタイムアウト時間をウォッチドッグ・タイマ１２に新たに設定した後（図３，ステップ３０１）、ウォッチドッグ・タイマ１２を起動させる（ステップ３０２）。運用管理部１１はウォッチドッグ・タイマ１２を起動後、ＣＰＵ１にこの旨を通知する（ステップ３０３）。
【００２４】
ＣＰＵ１は、運用管理部１１からのウォッチドッグ・タイマ１２の起動通知を受けると（図２，ステップ２０４）、ＰＯＳＴによる診断を起動するとともに、ＰＯＳＴ時間計測タイマーを起動してＰＯＳＴ時間の計測を開始する（ステップ２０５）。ＰＯＳＴによる各ハードウェアの診断が正常に完了したなら（ステップ２０６のＹＥＳ）、ＣＰＵ１は運用管理部１１に対してＰＯＳＴ完了を通知し（ステップ２０７）、ＰＯＳＴ時間の計測結果をフラッシュＲＯＭ３に記録する（ステップ２０８）。この診断が完了しない間（ステップ２０６のＮＯ）、ＰＯＳＴ時間の計測が継続されることになる。
【００２５】
一方、運用管理部１１は、ウォッチドッグ・タイマ１２のタイムアウトが発生する前に（図３，ステップ３０４のＮＯ）、ＣＰＵ１からＰＯＳＴ完了の通知を受けると（ステップ３０５）、ウォッチドッグ・タイマ１２をストップし（ステップ３０６）、ＣＰＵ１にこの旨を通知する（ステップ３０７）。
【００２６】
ＣＰＵ１は、この通知を受けると（図２，ステップ２０９）、ブートシーケンスの以降のステップを実行する。たとえば、起動ドライブのサーチ、起動ドライブからのマスターブートレコードのロード、起動ドライブにおける起動パーティションのサーチ、起動パーティションのブートセクターのロードなどを実行を通して、オペレーティングシステムのブートを行う（ステップ２１０）。
【００２７】
また、デバイスに障害がある場合、ＰＯＳＴ中、ＣＰＵ１はデバイスからの応答待ちの状態が続く、この応答待ちの状態が継続することによって、ウォッチドッグ・タイマ１２のタイムアウトが発生し（図３，２ステップ３０４のＹＥＳ）、運用管理部１１は、障害発生時の復旧処理として、ＣＰＵ１に対して再起動の割り込みを掛ける（ステップ３０８）。これにより、ブートシーケンスが最初から実行される。
【００２８】
このように、この実施形態では、前回のＰＯＳＴ時間の計測値に所定のマージンを加えた時間を今回のブートシーケンスにおけるウォッチドッグ・タイマ１２のタイムアウト時間として設定することで、メモリ容量や接続機器に変更が発生しない限り、ウォッチドッグ・タイマ１２のタイムアウト時間を最適化することができ、ハードウェア障害時にシステムがリブートするまでに要する時間を短縮することができる。
【００２９】
また、メモリ容量や接続機器の構成に変更が発生した場合には、フラッシュＲＯＭ３の前回のＰＯＳＴ実測時間をクリアして、構成変更用にあらかじめ用意された、マージンの大きいタイムアウト時間をウォッチドッグ・タイマ１２に自動であるいは手動により設定し、このとき実測されたＰＯＳＴ時間をフラッシュＲＯＭ３に記録し、次回から上述した手順でタイムアウト時間の最適化を行うように構成してもよい。
【００３０】
次に、本発明の第二の実施形態として、メインメモリの容量に応じたタイムアウト時間を、ウォッチドッグ・タイマ１２に設定する方式を説明する。
【００３１】
図４は、この第二の実施形態にかかる情報処理装置の構成を示すブロック図である。
【００３２】
なお、同図において、図１と同じ部分には同一の符号を付し、これら同一部分についての説明は重複を避けるために省略する。
【００３３】
ＰＯＳＴ時間はメインメモリ６のチェックに要するに時間に大きく依存しており、メインメモリ６の容量が大きいほどＰＯＳＴ時間も長くなる。そこで、フラッシュＲＯＭ３などの不揮発性記憶部に、たとえば、図５に示すように、メインメモリ６の容量とこれに対する最適なタイムアウト時間との関係を登録したテーブル２４を記憶しておく。このテーブル２４は、１Ｇのメモリ容量に対してタイムアウト時間を３５秒とし、これよりメモリ容量が１Ｇ増えるごとに１５秒ずつタイムアウト時間が長くなるようにした場合の例である。なお、メモリ容量が１Ｇと２Ｇとの間にある場合には、たとえば、いずれか近いほうの容量に対応するタイムアウト時間を採用するものとする。もちろん、これは一例に過ぎず、メモリ容量とタイムアウト時間との関係は、他の様々な条件を考慮して、最適に設定されることが望ましい。また、メモリ容量のテーブル上の区分けに関しても、より細分化してもよいことは言うまでもない。
【００３４】
ＣＰＵ１は、ブートシーケンスに含まれる、タイムアウト時間を最適化する処理手順２３にしたがって、ＰＯＳＴ中のメインメモリ６のチェックにおいて実測されたメインメモリ６の容量に対して最適なタイムアウト時間を上記テーブル２４より取得し、これをウォッチドッグ・タイマ１２のタイムアウト時間として運用管理部１１に、ウォッチドッグ・タイマ１２の起動要求とともに通知する。
【００３５】
以下に、このメインメモリ６の容量に応じたタイムアウト時間の設定を含むブートシーケンスの詳細な流れを図６を参照して説明する。
【００３６】
図６はＣＰＵ１の側の処理手順である。運用管理部１１の側の処理手順は図３と同様である。
【００３７】
電源が投入されると、ＣＰＵ１は、ＢＩＯＳプログラムのブートシーケンスに従ってＰＯＳＴを起動するとともに、そのブートシーケンスに含まれる、ウォッチドッグ・タイマのタイムアウト時間の最適化を行う処理手順２３に従って、メインメモリ６の容量をチェックする（図６，ステップ６０１）。続いて、ＣＰＵ１は、メインメモリ６の容量に対応するタイムアウト時間をフラッシュＲＯＭ３の上記テーブル２４から読み込み（ステップ６０２）、この読み込んだタイムアウト時間を付加した、ウォッチドッグ・タイマ１２の起動要求を、メモリ接続制御部４、Ｉ／Ｏ制御部８を通じて運用管理部１１に通知する（ステップ６０３）。
【００３８】
一方、運用管理部１１は、ＣＰＵ１からのウォッチドッグ・タイマ１２の起動要求を受けると、これに付加されているタイムアウト時間をウォッチドッグ・タイマ１２に設定した後（図３，ステップ３０１）、ウォッチドッグ・タイマ１２を起動させる（ステップ３０２）。運用管理部１１はウォッチドッグ・タイマ１２を起動後、ＣＰＵ１にこの旨を通知する（ステップ３０３）。
【００３９】
ＣＰＵ１は、運用管理部１１からのウォッチドッグ・タイマ１２の起動完了通知を受けると（図６，ステップ６０４）、ＰＯＳＴによる診断を開始する（ステップ６０５）。ＰＯＳＴによる診断では、たとえば、メインメモリなどのメモリチェック、各デバイスの初期化などが行われる。このメモリチェックおよび各デバイスの初期化が正常に完了したなら（ステップ６０６のＹＥＳ）、ＣＰＵ１は運用管理部１１に対してＰＯＳＴ完了を通知する（ステップ６０７）。この診断が完了しない間（ステップ６０６のＮＯ）、ＰＯＳＴ時間の計測が継続されることになる。
【００４０】
一方、運用管理部１１は、ウォッチドッグ・タイマ１２のタイムアウトが発生する前に（図３，ステップ３０４のＮＯ）、ＣＰＵ１からのＰＯＳＴ完了通知を受けると（ステップ３０５）、ウォッチドッグ・タイマ１２をストップし（ステップ３０６）、ＣＰＵ１にこれを通知する（ステップ３０７）。
【００４１】
ＣＰＵ１は、この通知を受けると（図６，ステップ６０８）、ブートシーケンスの以降のステップを実行する。たとえば、起動ドライブのサーチ、起動ドライブからのマスターブートレコードのロード、起動ドライブにおける起動パーティションのサーチ、起動パーティションのブートセクターのロードなどを実行を通して、オペレーティングシステムのブートを行う（ステップ６０９）。
【００４２】
また、デバイスに障害がある場合、ＰＯＳＴ中、ＣＰＵ１はデバイスからの初期化完了を待機した状態が続く、この状態が継続することによって、ウォッチドッグ・タイマ１２のタイムアウトが発生し（ステップ３０４のＹＥＳ）、運用管理部１１は、障害発生時の復旧処理として、ＣＰＵ１に対して再起動の割り込みを掛ける（ステップ３０８）。これにより、ブートシーケンスが最初から実行される。
【００４３】
このように、この実施形態では、ＰＯＳＴ時間がメインメモリ６の容量に大きく左右される点を鑑みて、メインメモリ６の容量に対して最適なタイムアウト時間をウォッチドッグ・タイマ１２に設定することで、ハードウェア障害時にシステムがリブートするまでに要する時間を短縮することができる。
【００４４】
なお、本発明は、上述の実施形態にのみ限定されるものではなく、本発明の要旨を逸脱しない範囲内において種々変更を加え得ることは勿論である。
【図面の簡単な説明】
【００４５】
【図１】本発明の第一の実施形態に係る情報処理装置の構成を示すブロック図である。
【図２】ブートシーケンスの流れを示すＣＰＵ側の処理手順を示すフローチャートである。
【図３】ブートシーケンス実行時の運用管理部側の処理手順を示すフローチャートである。
【図４】本発明の第二の実施形態に係る情報処理装置の構成を示すブロック図である。
【図５】メインメモリの容量とこれに対する最適なタイムアウト時間との関係を示したテーブルの構成を示す図である。
【図６】メインメモリの容量に応じたタイムアウト時間の設定を含むブートシーケンスの流れを示すフローチャートである。
【符号の説明】
【００４６】
１…ＣＰＵ、２…ＲＯＭ、３…フラッシュＲＯＭ、４…メモリ接続制御部、６…メインメモリ、８…Ｉ／Ｏ制御部、１１…運用管理部、１２…ウォッチドッグ・タイマ、１３…タイムアウト時間を最適化する処理手順、１４…前回のＰＯＳＴ時間の実測値、１００…情報処理装置。
【図１】
2005165415.tif 000003
【図２】
2005165415.tif 000004
【図３】
2005165415.tif 000005
【図４】
2005165415.tif 000006
【図５】
2005165415.tif 000007
【図６】
2005165415.tif 000008