JP3720919B2

JP3720919B2 - コンピュータ・システムのシャットダウンを効率的に管理する方法及び装置

Info

Publication number: JP3720919B2
Application number: JP19314696A
Authority: JP
Inventors: ランダル・クレイグ・スワンバーグ; マイケル・ステファン・ウィリアムス
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 1995-09-29
Filing date: 1996-07-23
Publication date: 2005-11-30
Anticipated expiration: 2016-07-23
Also published as: US5699502A; JPH09167099A

Description

【０００１】
【発明の属する技術分野】
本発明は、コンピュータ・システムの障害処理に係り、特にハードウェア障害に応答してコンピュータ・システムのシャットダウンを効率的に管理する方法及び装置に係る。
【０００２】
【従来の技術】
ますます複雑になる現在のコンピュータ・システムの設計に関して、重要なアーキテクチャの側面として、誤動作をどのように処理するかという課題がある。誤動作は無数にあり、冷却装置の障害から電源障害等まで様々であり、総称的に「イベント」と呼ばれる。
【０００３】
こうしたイベントがハードウェアで検出されると、データの損失、システムへのダメージ、その他、こうした望ましくないイベントにかかわる問題を防ぐあるいは最小限にするために、適切な動作（以下「対障害動作」とも称する）あるいは処置を取る必要がある。このような動作もイベントと同じように無数にあり得、様々であり、複雑であり、更に機能的に検出されたイベントと、そのイベントに関連したハードウェア・システムに依存する。イベントによってトリガされるこうした適切な動作の代表例として、システムのユーザに対する検出状態の警告とシステムの自動シャットダウンがある。これら所望の動作には更に、例えばトランザクションが完了する前に障害が起こった場合等のように、データの整合性とファイル・システムの保護が含まれる。
【０００４】
ハードウェアの誤動作を効率的に処理できるシステムを設計する際の従来のアプローチは、まず、これら様々なイベントを検出するメカニズムをハードウェア内に準備することである。これら検出イベントの指標（インディケータ）が次にソフトウェアに、具体的にはオペレーティング・システムに伝えられ処理される。オペレーティング・システムは、イベント・インディケータを受信して処理し、検出イベントに合わせて調整された一連の適切な対応動作を形成する。
【０００５】
このようなシステムの開発の初期段階では、前記のアプローチはうまくいくように思われた。これは主にコンピュータそれ自体が比較的シンプルだったからである。検出イベントは、それにより生じる所望の動作と同様に数が限られ、その相互関係も複雑さも限定されたものであることが多かった。例えば、ある単純なシステムにより、冷却ファンの障害だけが検出され、その結果、オペレーティング・システムによって即時パワーオフ・ルーチンの実行が起動されるだけである。
【０００６】
しかし、その後コンピュータ・テクノロジが発達するにつれ、ハードウェア・システムは、検出すべきイベント障害の数とタイプについても、またそれによって生じ、オペレーティング・システムによってトリガすべき動作についても、かなり複雑になっている。
【０００７】
例えばあるメーカーは、これまでは数種類のローエンド・コンピュータからなるかなり限られたハードウェア製品群を扱うだけだったが、同じメーカが現在では様々なハードウェアを組み合わせた製品を扱っていると考えられる。これらの製品は比較的シンプルなデスクトップのクライアントＰＣやワークステーションから、複数のＣＰＵ、ラック及び複数のディスク・ドライブ、アダプタ・ボード、その他の周辺装置等を収めるキャビネットを含む、かなり複雑な総合サーバ・システムまでと幅広く、それぞれに専用の電源や冷却装置の障害点が関係する。
【０００８】
前記のように、障害サポートの必要なハードウェア・システムの数が増え、より複雑になった結果、検出すべき様々なイベントの絶対数が付随的に増加するだけでなく、複数のハードウェア・プラットフォームをサポートする１つのオペレーティング・システムでこれらのイベントから適切な動作を決定する問題もまた複雑になっている。
【０００９】
業界は障害処理装置を簡素化する必要性に呼応して、人工知能やエキスパート・システムの技術でこの状況に対応しようとした。こうしたシステムの場合、デバイス・エラーの障害処理に人工知能エンジンが用いられた。これは基本的には、イベント、アラーム等についての学習を、また後には障害を解決するために何が必要かの適応型あるいはインテリジェント型の確認を伴う。
【００１０】
これら従来技術の試行により、様々なイベントやアラームを解釈するタスクは簡素化されたが、それでも取るべき適切な対応動作を決定するためになおオペレーティング・システム処理が必要という大きな欠点があった。従って、このようなシステムは、基本的には「イベント」通知システムにとどまった。ますます複雑になるハードウェア・システムやその組み合わせに関係した適切な対障害動作を決定するという組み合わせの問題とタスクはある程度までは簡素化されたが、これらのイベントを処理し、適切な動作を形成するため、オペレーティング・システム自体に負担がかかることには変わりがなかった。先に述べた理由から、オペレーティング・システムのデベロッパにかかるこの負担は、現在のコンピュータ・システムでは、ハードウェア・システム及び関連するイベントの非常に大きな組み合わせの処理に関して急速に管理不能になっている。
【００１１】
問題の複雑さを強調するために２、３例を挙げる。あるレジスタのフラグ・ビットによりハードウェアのある特定の部分に関して、冷却ファンに障害が起こったことが示される。その場合、その特定のハードウェアに対して適切な動作は、電源の供給を即座に停止することであろう。しかし、この同じビットが別のハードウェアでは、冗長な電源を持つ装置内の電源の障害に対応する。この例では、電源の供給を即座に停止することは不適切なだけではなく望ましくないことでもある。従来のシステムの場合、適切な動作を選択し実行するために、どの動作が適切かを明らかにするタスクでは、イベント・フラグ自体の検出ばかりでなく、イベントがそこから生じたハードウェア・システムを判定することも必要になる。前記のタスクは従来のシステムではオペレーティング・システムに委ねられていた。
【００１２】
このようなイベントと、あるオペレーティング・システムがサポートするシステムの数が多くなると、オペレーティング・システムそれ自体で適切な動作を形成する機能を提供し維持する問題も大きくなった。新しいイベント（これはまた特定の対障害動作を要する）をもたらすハードウェアの変更が新たに行われる毎に、オペレーティング・システムそれ自体をこれに対処するために変更する必要があると想定された。「過去から受け継がれた」複数のハードウェア・プラットフォーム及び新たに追加されたハードウェアをサポートするために必要な単一のオペレーティング・システムを（経済的な理由から）維持する負担から、そのようなオペレーティング・システムを維持するコストと複雑さが生じ、これは多くの場合、管理不能になり現実的ではなくなる。
【００１３】
オペレーティング・システムのベンダが、検出すべきイベントとそれにより生じる動作の急激な増加にうまく対応できた場合でも、このような適切な動作の決定がオペレーティング・システムに委ねられると、また新たな問題が生じた。
【００１４】
例えばオペレーティング・システムに、独自のものすなわち「付加価値」を提供しようとするＯＥＭ（Original Equipment Manufacturer）が増加し、必要な新しい動作をもたらすハードウェアの追加や変更にオペレーティング・システムが対応できるようにする負担をＯＥＭも負うことになった。ハードウェアに対する付加価値によるが、こうしたＯＥＭは、例えば本来のオペレーティング・システム・ベンダによって選択されたものとは異なる動作群や動作のタイプを必要とする。しかしこのようなメーカは、あるイベント群がある場合、これら新しいイベントに対して適切な動作を決定するための新しいオペレーティング・システム・カーネル・コードを開発しテストする能力あるいはリソースを持たないかもしれない。
【００１５】
ＯＥＭは、従って、このような付加価値ハードウェアの変更内容を提供しながらも、元のシステム動作（本来のオペレーティング・システム・ベンダによって定義されたもの）に必要な新しい変更内容を経済的に、効率よく実現できるようにする、比較的シンプルな方法を渇望することになろう。しかし、先に述べた通り、現在のシステム（検出イベントの関数として適切な動作を選択する責任がオペレーティング・システムに組み込まれたもの）では、オペレーティング・システムをそのように変更するのは複雑な作業になるため、これは不可能になり、実際問題としてＯＥＭがこうしたカスタム動作を提供することは実質的に不可能であった。
【００１６】
前記のことからすぐ明らかになることは、ハードウェア・システムがそれによって機能するオペレーティング・システムを維持する負担を軽減できる、コンピュータによる障害管理装置が求められるということである。また、ハードウェア・システムが変更されて複雑になるとき、イベントとそれによって生じる動作の追加に簡単に対応でき、よってハードウェアの設計の幅が広がる改良されたシステムが求められる。
【００１７】
【発明が解決しようとする課題】
本発明の目的は、障害管理装置の適切なイベント駆動動作を選択することに関係した決定を、オペレーティング・システムの設計者や維持者にではなく、ハードウェア設計者に委ねることである。ただし、かかるハードウェア設計者は、これらのイベント及び指示すべき必要な動作について最も知識があることを前提とする。
【００１８】
本発明の他の目的は、オペレーティング・システムのモジュール性とオブジェクト指向性が高まり、よって障害イベント群から適切な動作を決定する等のハードウェア固有の機能に対する依存性が少なくなるように、オペレーティング・システムの移植性を高めることである。
【００１９】
【課題を解決するための手段】
コンピュータ・システムにおいて、障害状態を指示しこれに対応するハードウェア内の複数のイベントのうち少なくとも１つを検出するハードウェア・サブシステムが提供される。かかるイベントには、電力損失、１次または２次の冷却ファンの障害、熱障害等の検出が含まれる。
【００２０】
ハードウェア・システムは更に、かかる検出イベントの関数としてまたこれに対応して、システムに適した対応動作を決定する手段を含む。かかる動作としては、例えば冷却や電源の問題が深刻ではないときにはこれをただシステム・オペレータに警告するためのものがある。この他の動作には１０分経過後にコンピュータ・システムのシャットダウンを自動的に行う（ハードウェア・サブシステムによって重大な冷却の問題と解釈されたイベントに応答して）、例えば２０秒等、比較的短い時間でシャットダウンを行う（かなり重大な冷却の問題と解釈されたイベントに応答して）。あるいは電力損失等の重大状態が発生した場合には即時にパワーダウンを行うことが含まれる。
【００２１】
必要且つ適切なかかる対応動作（検出イベントによって駆動される）がハードウェア・システムによって決定されると、コンピュータ・システムのオペレーティング・システムに必要な対応動作を示すメッセージが伝えられる。
【００２２】
オペレーティング・システムによるこのメッセージの受信に応答して、その後、オペレーティング・システムにより対応するサブルーチンが実行され、必要な対応動作（即時パワーダウンかどうかにかかわらず）または他の予め選択された動作の１つが実行される。
【００２３】
ハードウェア・サブシステムからの指定された動作は、望ましくはオペレーティング・システムによって実行される複数の応答動作になる。例えば、あるイベントの検出の結果、ハードウェア・サブシステムによってオペレーティング・システムに伝えられた所望の２０秒シャットダウン動作に応答して、所望動作は実際に、プロセス終了トランザクション全ての完了とディスクへの格納を含めた動作のサブセットになり、その後、電源系統のシャットダウンを開始すると共に、電源の復帰（その場合はディスクのアクティビティが再開される）等がモニタされる。
【００２４】
本発明の重要な特徴は新しいイベントを認識し、ハードウェアによって検出されたかかるイベントにどの動作が必要で適切かを判断するようにオペレーティング・システム自体を変更する必要がなくなることである。従って、本発明の好適な実施例では、ハードウェア・システムが単にイベント（電力損失、ファン障害等）をオペレーティング・システムに通知するのではなく、ハードウェア・システムやハードウェア・サブシステムが逆に、所望の動作（ユーザへの警告、１０分遅いシステムのシャットダウン、即時パワーダウン等）をオペレーティング・システムに通知する。
【００２５】
本発明の開示内容に従って、（イベントの指示を与えるのではなく）所望の動作の指示をオペレーティング・システムに与えるこの手段により、オペレーティング・システムはイベントを認識し、適切な動作を決定する責任からも自由になる。このようにして、オペレーティング・システム・ソフトウェアそれ自体の変更やテストを必要とせずに、新しいハードウェアと障害状態をサポートすることができる。新しいハードウェア・イベントはそれぞれ、すでにオペレーティング・システムには既知の所望の動作の１つとしてオペレーティング・システムに再び提示されるだけである。
【００２６】
【発明の実施の形態】
図１は、本発明を実現した代表的コンピュータ・システム１００のハイレベル・ブロック図を示す。コンピュータ・システム１００は、IBM PowerPC（商標） 601、Intel（商標） Pentiumマイクロプロセッサ等を含み、処理キャッシュ１５、ＲＡＭ（ランダム・アクセス・メモリ）１４、ＲＯＭ（読出し専用メモリ）１６、ＮＶＲＡＭ（不揮発性ＲＡＭ）３２、その他、Ｉ／Ｏアダプタ１８によって制御されるＤＡＳＤ２０等の適切な記憶装置に格納されたデータとコードを処理するマスタＣＰＵ（中央処理装置）１０を含む。この他にもテープ、ＣＤ−ＲＯＭ、ＷＯＲＭドライブなど様々な記憶媒体を採用できる。必要に応じてデータやコンピュータ・プロセス命令を格納するため取り外し可能な記憶媒体を用意することもできる。
【００２７】
好適な実施例では、ＡＩＸ（商標）オペレーティング・システム（ＯＰＳＹＳ）５２を実行するIBM RISC System/6000（商標）が図１のコンピュータ・システム１００を含む。ただし当業者にはわかるように、他のハードウェア・プラットフォーム、オペレーティング・システムも本発明を実現するのに利用できる。
【００２８】
ユーザは、各種Ｉ／Ｏデバイス（ユーザ・インタフェース・アダプタ２２によって制御される周知のユーザ用制御装置やインタフェース等）を通してコンピュータ・システム１００と通信する。ディスプレイ３８はキーボード２４、ポインティング・デバイス２６、及びスピーカ２８によりユーザがコンピュータ・システムの動作を指示できるとき、ユーザに情報を表示する。必要ならこのコンピュータと、ネットワーク３５に接続された他の処理装置との通信を制御するために従来型の通信アダプタ３４を追加できる。ディスプレイ・アダプタ３６は、従来の方法でビジュアル・ディスプレイ３８に表示されるようユーザとコンピュータ・システム１００との通信を制御する。またこのシステムの各種サブアセンブリと構成要素を相互接続して、各種サブコンポーネント間でデータ、アドレス、制御の各信号を転送できるようにするバス構造が、これも従来の方法で用意される。
【００２９】
図１のコンピュータ・システム１００は更に、電源４０と、ファン１、２（４２、４４）等の何らかの冷却機構を含む。本発明の特徴は、個数、タイプ、機能に関して様々な構成要素を含む多様な構成のシステム１００を実現することである。これら様々なシステムはまた、それぞれキャビネット・システム５８、ラック・システム６８として示したキャビネットやラック内に収容する等、全体の物理的形式も異なってよい。またシステム１００が様々な形式で実現される場合でも、通常は先に述べたサブアセンブリや構成要素を含むことには変わりない。
【００３０】
従って、例えばキャビネット・システム５８を見ると、これには電源６０、ＲＡＭ、ＲＯＭ、ＤＡＳＤ、ＮＶＲＡＭ等の記憶デバイス６２、ＣＰＵボード６４及びファン６６が含まれ、その他、ブロック６７に一括して示したような構成要素が必要に応じて追加される。
【００３１】
同様に、ラック・システム６８は、電源７０、７２、ファン７４、ディスク・ドライブ等の形の記憶デバイス７６、プロセッサ・ボード７８、その他の構成要素７９を含む。こうしたサブアセンブリや構成要素も、最初に述べたシステム１００の構成要素と同様に各種サブコンポーネントを相互接続し、必要なデータ、アドレス、制御の各信号を提供するバス構造１２を含む。
【００３２】
図１のハードウェアは実際には、専用のプロセッサやメモリを追加できる複数のサブシステムからなる。これは一般的には例えばＣＰＵ８１とＲＯＭ８０を含むＩ／Ｏアダプタ・カード１８で示されるものであるが、包括的な意味では専用のプロセッサとメモリを含むコンピュータ・システム１００のどのサブシステムをも表すものである。このような、マスタＣＰＵ１０やＣＰＵ８１のものの他に追加されるサブシステムやプロセッサの例として、サービス・プロセッサ・サブシステム８５の「立ち上げ」（bringup）マイクロプロセッサ８３がある。立ち上げマイクロプロセッサは、システム１００を初期ブート時に立ち上げるタスクを実行する。また各種の障害状態とイベントをモニタし、適切な動作コードを決定してオペレーティング・システム５２と通信を行う。これについては後に詳しく説明する。
【００３３】
本発明の開示内容に従って、このような追加されたＣＰＵ８１と関連メモリ８０の１機能は、システム１００の各サブシステムの各種動作状態をモニタし、システム１００が対応すべき「イベント」を検出することである。図１で、信号ライン４６、４８、５０はそれぞれ電源４０とＣＰＵ８１、第１ファン４２とＣＰＵ８１、及び第２ファン４４とＣＰＵ８１の間に示してある。これら信号ライン４６、４８、５０はシステム１００のサブシステムに関連した各種イベントが、これら追加ＣＰＵ８１（Ｉ／Ｏアダプタ１８上のＣＰＵとは限らず、例えばモニタ用サブアセンブリの電源に関連したＣＰＵも）によって検出できることを概念的に示すためだけのものである。具体的には、システム１００の動作中、電源４０、または６０、７０、７２（キャビネット及びラック・システム５８、６８に対する）に障害が起こる可能性がある。動作が許容レベルを超えるか完全に故障するかである。電源サブシステムは、対応ＣＰＵ８１に伝えられるこの障害状態すなわちイベントを示すイベント信号４６を出力するようになっている。
【００３４】
同様にシステム１００は、ファン４２、４４、６６、７４等の誤動作によって示されるような冷却の問題が生じる可能性がある。これらのイベントは電源のイベントと同様に、対応ＣＰＵ８１（ここでも便宜上、Ｉ／ＯアダプタのＣＰＵ８１として示す）に伝えられる対応するイベント信号４８、５０によって表される。
【００３５】
従来のシステムに従うと、これらイベント４６、４８、５０がＣＰＵ８１によって検出されると、イベントはシステム１００の格納レジスタに格納されるだけであった。次にレジスタに格納されたイベントに応じて適切な対応動作を選り分けるのはＣＰＵ１０と関連オペレーティング・システム５２の責任であった。一例として、ＣＰＵ８１が致命的な電源４０の障害イベントをライン４６で検出した場合は、このイベントから指示される適切な動作（すなわちバックアップ用のバッテリ電源への切り替えを行う等）は何かを決定するのはオペレーティング・システム５２とＣＰＵ１０の責任であった。
【００３６】
同様にＣＰＵ８１によって検出され、対応レジスタに格納されたイベント信号４８または５０に応答して、ＣＰＵ１０とオペレーティング・システム５２は、かかるイベント（例えば第１ファン４２の障害を示す）を認識したことに応答して、適切な対応動作を実行するようになっていた。これは例えばファンが故障したことをオペレータに示すためディスプレイ・アダプタ３８に表示されるメッセージの形であった。ファン４４等の追加ファンにより冗長性が与えられているので短時間には他の操作は指示されなかった。一方、ＣＰＵ８１によって検出されたイベント信号４８、５０により、両方のファン４２、４４が故障したことが示された場合、別の動作、例えば熱過負荷状態が生じる前にシステムのシャットダウンを行う等が指示されるようになっていた。
【００３７】
ただし、ここでも従来のシステムでは、対応する格納レジスタに格納されたこれらのイベント信号の検出に応答して、適切な対応動作それ自体を行うのはＣＰＵ１０とオペレーティング・システム５２の責任であった。
【００３８】
従来のこのアプローチによって生じた問題として、オペレーティング・システム５２はしばしば経済的な理由から、多数の異なるサブシステムと対応イベントを有する様々なハードウェア・システム１００をサポートするようになっている。具体的には、例えばこのような１つのハードウェア・システムでは、前記の格納レジスタのある特定の位置にビットまたはフラグがあると、これはファン４２の障害を示す。これはまた、前記のようなオペレータへの警告等、装置の特別な対応動作を示す。
【００３９】
しかし、このようなシステムの別の例（１００）では、この同じビットが前記の電源４０の障害を反映する。これ自体はまたファン障害のものとは全く異なるシステム１００からの応答の必要性を示す。従来のシステムでは、あるイベントを検出する必要があるだけでなく、それによって指示される適切な対応動作を決定する必要もある。この例の場合、格納レジスタにある同じビットが全く異なる２つのイベントと対応して実行すべき、全く異なる２つの動作を表すとすると、格納レジスタ・ビットを正しく「デコード」する、例えば必要な、適切な対応動作はどれかを決定するために、どのタイプのハードウェア・システム１００が動作しているかを検出する必要性はオペレーティング・システム５２に帰属していた。
【００４０】
これは、ここですぐわかることであるが、オペレーティング・システム５２が常に実行すべき適切な動作を、もちろんそれがサポートすることを求められるハードウェア構成要素の集まりに依存して決定するために、オペレーティング・システム５２を常時変更しテストすることを要する。その結果、実際上、基本的には、結果的に複数のオペレーティング・システムになるものを設計し運用／維持しなければならなくなる。これは、これらのイベントを生成する異なるハードウェア・システムそれぞれに対応するよう、オペレーティング・システムが形成するイベント駆動型の動作をマップするためにオペレーティング・システムを変更する必要性から生じる。
【００４１】
本発明の特徴は上述の問題に呼応して、イベントに対する適切な対応動作のこの決定をハードウェア・システムやそのサブシステムそれ自体に肩代わりさせることである。この方法では、ＣＰＵ１０とオペレーティング・システム５２に伝えられるのは対応動作を要するイベント自体ではない。所望の動作自体（オペレーティング・システムに既知で且つオペレーティング・システムが実行可能な、予め選択された所望動作のリストから選択されたもの）のインディケータが伝えられる。この方法では、ハードウェア・システム１００の構成が何らかの形で変更されたとき（追加、削除、ハードウェア・サブシステムの変更等）、従来技術とは異なり、これら変更内容をＣＰＵとオペレーティング・システム５２に伝える必要はない（またオペレーティング・システム５２にすでに具体化された既存の動作ストラテジを変更する際のそれらの重要性もない）。逆にハードウェア・システム１００と関連サブシステム自体は検出されたイベント状態に応じて、オペレーティング・システムに既知の所望の対応動作を予め決定する責任を負う。イベントではなく所望の動作だけがＣＰＵ１０とオペレーティング・システム５２に集められる。
【００４２】
これは、本発明のシステムより得られる大きなメリットによる。すなわち様々なハードウェア・プラットフォームに対して複数のオペレーティング・システムを維持する必要をなくすことである。これにより基本的には１つのオペレーティング・システムで複数のハードウェア構成をサポートでき、オペレーティング・システムを継続的に変更しテストして、様々なハードウェア構成に応じて変化するイベントに対する正しい対応動作を提供する必要はない。
【００４３】
図１に示したバス１２の部分１３は、このイベントと動作の相互作用を概念的に示している。特に上述のように、ハードウェア・サブシステムとそのＣＰＵにより検出されたイベント１１により、予め選択された動作群から選択された所望の動作１７がＣＰＵによって選択される。矢印１９は、この所望の動作１７がバス１２を通してマスタＣＰＵ１０に伝えられることを示す。マスタＣＰＵ１０はこれに応答して、オペレーティング・システム５２と共に指示された動作１７に対してどのコールが必要かを決定し、動作１７を実行するルーチンを実行する（５４）。矢印１９、５４は、ＣＰＵ１０とオペレーティング・システム５２がハードウェア・サブシステムから所望の動作１７を知らされること、またこれに応答して、ＣＰＵ１０とオペレーティング・システム５２がバス１２に対応信号を生成すること（矢印５４で示す）を示す。これらの信号により、システム１００で所望の動作が実行される（システムのシャットダウン、バッテリ・バックアップの起動、ユーザやシステム管理者に対するディスプレイ３８へのメッセージ表示、ディスク動作の保留等）。イベント１１は実際には、後述するサービス／プロセッサ・ブロック等、各種のサブシステムとその対応ＣＰＵによって検出されること、またそれらが検出するイベント１１の関数として動作信号１７を生成するのはこれらサブシステムであること、またこの動作信号１７はサブシステムからマスタＣＰＵ１０に伝えられ、マスタＣＰＵ１０はオペレーティング・システム５２と共に、動作信号に応答して対応サブルーチンを実行する（５４）ものであることに注意されたい。
【００４４】
説明をわかりやすくするため、一般的な目的からは基本的にはディスク制御装置であるＩ／Ｏアダプタが制御装置として選択されているのは、サービス・プロセッサの機能とイベント検出を概念的に包括的に示すためであるが、この個別機能は、図１に示した別の機能ボックス、サービス・プロセッサ・サブアセンブリ８５によって示す方がわかりやすいかもしれない。このサブアセンブリは、実際に立ち上げマイクロプロセッサ８３を含むもので、基本的にこれはシステムを立ち上げ、適切な動作コードを決定してオペレーティング・システムに送るタスクを実行するサービス・プロセッサである。従って、電源４０、ファン４２、４４等から検出されたイベントは、実際にサービス・プロセッサ・サブアセンブリ８５に送られるように示してある。サブアセンブリ８５へのこれら入力は立ち上げマイクロプロセッサ８３によって処理される。これによりシステムは出力８７を提供し、これはライン４６、４８、５０上のイベントの所望動作を表す信号への変換を表すと認識することができる。この動作信号８７は次に、好適には対応するステータス・レジスタ８９に送られる。電源警告割込みの検出により実際にマスタＣＰＵ１０によって読出されるのはこのステータス・レジスタ８９である。次にＣＰＵ１０とオペレーティング・システム５２は、ステータス・レジスタ８９に格納されたこの動作信号に応答して、システム内で所望動作を実行するのに必要なサブルーチンを実行する（５４）。
【００４５】
図２は、本発明に従った図１のシステム１００のソフトウェア制御のフローチャートを示す。概念上、分割線１１１は、それより上の機能はハードウェア・システムとサブシステム自体及びその関連のＣＰＵとメモリによって実行されること、また下の機能はオペレーティング・システム・ソフトウェア５２とＣＰＵ１０の機能で実行されることを示すためのものである。
【００４６】
まず本発明の動作で、システム１００はシステム内で適切な対応動作を要するイベントが発生したことを検出する（ブロック１０２）。このようなイベントの例としてはファン４２の故障等、冷却の問題を示すイベント信号４８に関連したありふれたイベント等である。このイベントが起こると、これはサブシステムのＣＰＵ８１によって、４６、４８、５０等のイベント信号として検出され、対応する記憶装置にログされる（ブロック１０４）。各イベントには、オペレーティング・システム５２には既知の対応動作が関連づけられる。対応動作はイベントと、それを起こしたハードウェアにより異なる。
【００４７】
所定所望の動作と、検出イベントの関数として動作を１つ選択するストラテジのこのリストは、ＲＯＭ／ＲＡＭ８０等のサブシステム内に予め格納される。サブシステムＣＰＵ８１は次に、格納されたイベントの指標（４６、４８、５０）にアクセスし、また実行されると必要な所望動作が決定される前もって格納されたコードとデータにアクセスする。従って、この所望動作の指標が生成される。例えばＣＰＵ８１はこれら格納され検出されたイベントを所望の動作パターンに変換する（ブロック１０６）。所望動作のこのインディケータは次に、ＲＡＭ８０等の格納レジスタに格納される（図２のブロック１０８）。次にＣＰＵ８１によってオペレーティング・システム５２に割込みが伝えられる（ブロック１１０）。オペレーティング・システムはこれにより、ハードウェア・サブシステムが、オペレーティング・システム５２による応答を要するイベントを検出したことと、所望動作のインディケータは既知の格納レジスタ位置でオペレーティング・システム５２に与えられるという指標を受取る。
【００４８】
ブロック１１０に示したこの割込みの処理に応答して、オペレーティング・システム５２は、ブロック１０８に関連した機能の実行後に、レジスタに格納された対応する所望動作モードの指標にアクセスする。代表的な動作例としては、所望動作がディスプレイ画面３８でのユーザに対する警告（重要ではない冷却の問題（イベント）が生じたが、冷却ファンは冗長なのですぐにシステムをシャットダウンする必要はないことを示す）だけであることをオペレーティング・システムに示す、格納レジスタのビットまたはフラグのセットがある。オペレーティング・システムは、その割込みの処理とオペレーティング・システムに既知で且つオペレーティング・システムが実行を期待される所定所望の動作のインディケータにアクセスしたことに応答して、次にサブルーチン１１６を実行し、動作を実行する。オペレーティング・システムによるサブルーチン１１６のこの実行ステップはブロック１１４に示してある。
【００４９】
図３は、ブロック１１０で伝えられる割込みのオペレーティング／システムによる処理に応答して、オペレーティング・システム５２とＣＰＵ１０によって実行できる代表的な動作サブルーチンのハイレベル・ブロック図である。オペレーティング・システムは、所望動作モードのインディケータへアクセス（１１２）した後、所望動作のインディケータによって指示されるサブルーチン１１６を実行する（１１４）。具体的には、１１６でサブルーチンが起動され、指示された動作がログされる（１１８）。例えば、条件がディスプレイ画面３８でユーザまたはオペレータに伝えられ格納される。次に、サブルーチンで、所望のイベントと動作がユーザにレポートされたことの確認が行われ（１２０）、オペレーティング・システム５２がノーマル処理を再開する（１２２）。
【００５０】
オペレーティング・システム５２は、この動作が必要なことを示すハードウェア・システムまたはサブシステムからのインディケータに応答して、所定所望の動作のサブルーチン１１６を実行できることは容易に理解できよう。従って、どのイベントを検出するか、またどのイベントまたはイベントの組み合わせによりオペレーティング・システム５２に伝えられる、（オペレーティング・システムがこれら検出イベントに応答して実現することを期待される所定動作の）インディケータをトリガするかを決定するのは、完全にハードウェア・システムとサブシステムの設計者の制御下にある。従って本発明は、特定のイベントまたはイベントの組み合わせ、あるいはまたオペレーティング・システムによってトリガされる対応動作に限定されるものではない。本発明は、予め選択された所望動作、サブルーチン及び特定のハードウェア・システムやサブシステムの設計者によって適切と考えられるものとしてそれらをトリガする対応イベントのリストに制限を加えるものではない。ここで特筆すべき特徴は、オペレーティング・システムそれ自体に伝えられそれによってアクセスされるのは、これら所望のサブルーチンや動作のインディケータであって、その元のイベントそれ自体ではないということである。
【００５１】
本発明は、特定の所定動作群に限定されるものではなく、これらの動作は、システム１００自体の特定の構成要素と設計によって決定されることに注意されたい。例えば、このようなシステム１００の特定の構成要素は、あるイベントを検出すると、冷却問題や電源の問題をユーザまたは管理者に対して警告することを保証するだけである。また別のイベントやイベントの組み合わせ（複数のファンのうち１つの障害等）が検出されると、所望の動作が保証され、ここでシステム１００は１０分後にシャットダウンされ、重大な冷却問題が生じたという警告がユーザに出される。これにより生じた時間でシステムはディスク動作等を余裕をもって終了させる。また他のイベント条件群がハードウェアによって検出されると（全ファンの障害等）、システム１００の場合、２０分以内のシャットダウンという別の動作が保証され、非常に重大な冷却問題を示すエラー・メッセージが出される。更にまた別に検出されたイベント群では、例えば致命的な電源障害の場合のように即時パワーダウン条件がある所望動作が保証される。
【００５２】
ある特定のイベント群によって指示されるこのような所望動作の場合、かかる所望動作それぞれに動作コードが前もって選択されること、またマスタＣＰＵプロセッサ１０によって動作するオペレーティング・システム５２によって伝えられこれによって操作されるのは、動作コードの原因になるイベントではなく結果の動作コードであることは、本発明の重要な特徴である。
【図面の簡単な説明】
【図１】本発明の障害管理サブシステムを含むコンピュータ・システムのブロック図である。
【図２】図１のコンピュータ・システムの障害管理サブシステムの動作を示すフローチャートである。
【図３】図１に示した本発明の障害管理サブシステムの動作の側面を示す詳細なフローチャートである。
【符号の説明】
１０マスタＣＰＵ
１１イベント
１３バス部分
１７動作信号
３８ディスプレイ
４０電源
４２、４４ファン
４６、４８、５０信号ライン
５２オペレーティング・システム
５４対応サブルーチンの実行
８０ＲＯＭ／ＲＡＭ
８１ＣＰＵ
８３立ち上げマイクロプロセッサ
８５サービス・プロセッサ・サブアセンブリ
８７動作信号
８９ステータス・レジスタ
１１６サブルーチン

Claims

１つ以上のハードウェア・サブシステム、マスタ・プロセッサ、オペレーティング・システム及びハードウェア障害の異なる１つと対応するイベント群に対して、前記イベント群の１つのイベントに対応し、前記オペレーティング・システムにとって既知で且つ前記１つのイベントに対応し、前記オペレーティング・システムによって実行可能な対障害動作が定義されたリストを格納する記憶装置を備えるコンピュータ・システム内のハードウェア障害に応答して前記コンピュータ・システムのシャットダウンを効率的に管理する方法であって、
（ａ）前記コンピュータ・システムにおける前記イベント群の１つの発生を前記ハードウェア・サブシステムによって検出するステップと、
（ｂ）前記検出されたイベント群のうちの１つに対応する障害動作を前記リストを照会し、前記複数の対障害動作のうち当該検出されたイベント群に対応する１つの対障害動作に対応するインディケータを前記ハードウェア・サブシステムによって選択するステップと、
（ｃ）前記選択に応答して、前記対応する１つの対障害動作を示す前記インディケータを前記オペレーティング・システムに通信するステップと、
（ｄ）前記通信に応答して、前記オペレーティング・システムによって前記対応する１つの対障害動作を実行するステップと、
を含む、前記方法。
前記対障害動作はユーザに対する警告と、前記コンピュータ・システムのシャットダウンを起こす異なるルーチンの実行とを含む、請求項１記載の方法。
前記ルーチンは、それぞれ異なる時間長の間に前記コンピュータ・システムをシャットダウンする、請求項２記載の方法。
１つ以上のハードウェア・サブシステム、マスタ・プロセッサ及びオペレーティング・システムで構成されるコンピュータ・システム内のハードウェア障害に応答して前記コンピュータ・システムのシャットダウンを効率的に管理する装置であって、
（ａ）前記ハードウェア障害の異なる１つと対応するイベント群に対して、前記イベント群の１つのイベントに対応し、前記オペレーティング・システムにとって既知で且つ前記１つのイベントに対応し、前記オペレーティング・システムによって実行可能な対障害動作が定義されたリストと、
（ｂ）前記コンピュータ・システムにおける前記イベント群の１つの発生を前記ハードウェア・サブシステムによって検出する手段と、
（ｃ）前記検出されたイベント群のうちの１つに対応する障害動作を前記リストを照会し、前記複数の対障害動作のうち当該検出されたイベント群に対応する１つの対障害動作に対応するインディケータを前記ハードウェア・サブシステムによって選択する手段と、
（ｄ）前記選択に応答して、前記対応する１つの対障害動作を示す前記インディケータを前記オペレーティング・システムに通信する手段と、
（ｅ）前記通信に応答して、前記オペレーティング・システムによって前記対応する１つの対障害動作を実行する手段と、
を備える、前記装置。
前記対障害動作はユーザに対する警告と、前記コンピュータ・システムのシャットダウンを起こす異なるルーチンを実行させる、請求項４記載の装置。
前記ルーチンは、それぞれ異なる時間長の間に前記コンピュータ・システムをシャットダウンする、請求項５記載の装置。