JP6530774B2 - ハードウェア障害回復システム - Google Patents

Description

本発明は、ハードウェア障害回復に関するものであって、特に、ホットプラグのサポートがないハードウェア障害回復のメカニズムに関するものである。

コンピュータのパフォーマンスおよび処理能力は、過去数十年で大幅に、且つ安定して成長している。当然のことながら、コンピュータシステム、たとえばサーバはますます複雑になり、プロセッサ、メモリ、およびアドインカード等の、搭載する部品の数量およびタイプも増加している。多くの専門家がこれは未来の趨勢であると考えている。

しかし、ハードウェアコンポーネントの数量と複雑度の増加に伴い、コンピュータシステムは装置の故障の問題が増加している。実際、装置故障は、特に、さらに大きくさらに複雑な環境や機構（たとえば、データセンターやラックスケール機構）において、システム管理者がよく直面する問題である。不幸なことに、装置故障は強大な破壊性を有する。装置故障は、たとえばコンピューティングやネットワークサービスの周期を長くし、時に、データ損失を招く。

装置故障を修復するため、システム管理者は、通常、手動のハードウェア障害回復プロセスを実行しなければならない。このハードウェア障害回復プロセスは、システムまたはサーバの電源を切断して、故障したシステムコンポーネントを代替する工程を有する。障害回復プロセス全体の効率は低く、且つユーザーへのサービスが中断する恐れがある。さらに、ユーザー入力に依存して障害回復プロセスのある工程を完成することは、さらにシステムの障害回復を遅延させ、さらに多くのサービス中断を招く可能性がある。

本発明は、ハードウェア障害回復システムを提供する。

本発明の特徴や長所は以下に記述されるとともに、一部は記述中から明らかにされる。または、ここで開示される原理により実践されて知ることができる。本発明の追加的な特徴と長所は、装置の方法、および、請求項中で示される特別な組み合わせにより理解され、獲得される。本発明のこれら、およびその他の特徴は、以下の記述と請求項によって十分に明らかになり、または、本開示中で記述される原理の実践により知ることができる。

本文で記述される方法が用いられることにより、ホットプラグのサポートなしで、故障のシステムコンポーネントを代替することができる。特に、本文で記述される方法は、システムを再起動またはリブートしない、または代替システムコンポーネントの再配置の必要がない状況下でも、故障のシステムコンポーネントを代替することができる。システムは、故障のタイプ、および／または、代替される部品のタイプに基づいて、特定のスリープ状態に置かれる。部品が代替されるとき、特定のスリープ状態は、システムの実行を継続して、システムを再起動またはリブートしなければならないことを防ぐ。このメカニズムは、ホットプラグのサポートがない状況下で、故障した部品を代替するとともに、システム休止時間を最小化、または制限するのに効果的な方法である。

自動ハードウェア障害回復のシステム、方法、および持続性コンピュータ読み取り可能ストレージ媒体が開示される。いくつかの実施形態において、システムは、ハードウェアエラーを検出するとともに、ハードウェアエラーに関連するシステムコンポーネント（たとえば、プロセッサ、メモリ、ストレージ、電源、周辺装置等）を識別する。

システムは、スリープ状態要求を生成して、システムの操作システムをトリガーして、システムを特定のスリープ状態にする。よって、システムは、操作システムが、システムを特定のスリープ状態に置かせて、ハードウェアエラーに関連するハードウェアコンポーネントを代替する。特定のスリープ状態は、システムコンポーネントに関連するコンポーネントのタイプに基づいて決定される。たとえば、コンポーネントのタイプが周辺装置である場合（たとえば、ＰＣＩエクスプレス）、システムがディープスリープ状態に置かれて、システムを再起動せずに、周辺装置を代替する。別の例では、コンポーネントのタイプが、プロセッサ、メモリ、または電源である場合、故障したコンポーネントが代替されるとき、システムは更にディープなスリープ状態に置かれ、システムを最小リソースで運転する。スリープまたはその他の状態の任意のレベルが考慮される。

よって、コンポーネントのタイプが周辺装置であるとき、特定のスリープ状態は第一スリープ状態、すなわち、ディープスリープ状態であり、コンポーネントのタイプが、プロセッサ、メモリ、または電源ユニットであるとき、第二スリープ状態、すなわち、最深スリープ状態である。第一スリープ状態と比べて第二スリープ状態は低い電源リソース消耗、および／または長い回復遅延である。第一スリープ状態は第二スリープ状態より深いか、または両スリープ状態は同じかほぼ同じである。状態のその他の組み合わせも考慮される。

システムが特定のスリープ状態に置かれた後、システムは指示を生成し、システムコンポーネントが、システムの操作システムを再起動しない状況下で代替されることを示す。指示は、システムがシステムコンポーネントに関連するコンポーネントのタイプに対応する特定のスリープ状態にある、および／または、システムが特定の操作状態にある（たとえば、使用リソースの減少、サービス、電力、装置、操作周期、操作パラメータ等に関連する操作状態）という判断に基づいて生成される。さらに、システムが、部品の交換の準備をしているとき、指示が生成される。つまり、指示は、システムが、システムおよび／または操作システムを再起動しない状況下で特定の部品が代替される状況にあるか否かの判断に基づいて生成される。前述のように、システム再起動またはリブートされない特定の状態で、コンポーネントのタイプ（たとえば、周辺装置、プロセッサ、メモリ、ストレージデバイス、電源等）に基づいて、部品の交換が可能である。

一旦、システムが、指示に基づいてレディ状態になると、エラーに関連するハードウェアコンポーネントが代替ハードウェアコンポーネントにより代替される。代替ハードウェアコンポーネントは、部品のタイプ、技術規格のタイプ、部品を作動または配置する関連ドライバ、部品を作動させるまたは配置する関連プログラム、ハードウェアまたはシステム要求、関連配置、ブランド、モデル、バージョン等の観点において、ハードウェアコンポーネントと同じである。

システムが、システムを再起動／リブートしない、システムコンポーネントを再配置しない、関連するアプリケーションを再起動しない状況等、特定のスリープ状態にあるとき、代替システムコンポーネントが代替される。さらに、たとえば、システム、システムコンポーネント、および／または代替システムコンポーネントが、ホットプラグまたはホットスワップ技術をサポートしていなくても、システムコンポーネントは代替システムコンポーネントにより代替される。システムコンポーネントが代替システムコンポーネントにより代替された後、システムは、特定のスリープ状態から一般の操作状態に転換されるとともに、一般操作を続行する。システムは、その後、システムコンポーネントのエラーの前と同じ方法によって代替システムコンポーネントを用いる。前述のように、“スリープ”状態が記述される場合において、任意のその他のタイプの可能なシステムコンポーネントの代替状態を適用することもできる。

本発明の上述の、およびその他の長所と特徴を得る方式を記述するため、前述の簡単に描写された原理は、更に具体的に、図面で示される具体的な実施形態により説明する。これらの図面は、本発明の例を示すものであり、本発明を限定するものではないことを理解すべきである。本発明の原理は、図面の描写、および、付加された特徴と詳細の解釈によって説明される。

本発明のシステムの第一実施形態を示す図である。 本発明のシステムの第二実施形態を示す図である。 仮想環境のシステムを示す図である。 ハードウェアコンポーネントを代替するスリープ状態メカニズムを実行するシステムを示す図である。 スリープ状態表である。 ハードウェア障害回復、または交換手順の各種部品間の通信を示す図である。 仮想マシンマネージャーにより、リソースおよびＶＭｓを障害回復する故障障害回復表である。 ハードウェア障害回復工程の実行方法のフローチャートである。 システム内のハードウェアエラーを監視および識別する方法のフローチャートである。 代替システムコンポーネントの検査方法のフローチャートである。 ソフトウェア復元可能性を決定する方法のフローチャートである。

本発明の各種実施形態が以下で詳細に討論される。特定の実施が討論されるが、これは説明のためのものであると理解すべきである。当業者なら、本発明の精神を逸脱することなく、その他の部品や配置を用いることができる。

本発明の追加的な特徴や長所は以下に記述されるとともに、一部分は、記述中から明白であるか、または、開示される原理の実施により理解できる。本発明の特徴と長所は、請求項中で特別に示される手段、およびその組み合わせにより実現および取得できる。本発明の特徴、およびその他の特徴は、以下の記述と請求項からさらに完全に明白になり、または本発明で記述される原理を実施することにより理解できる。

説明を簡潔にするため、適当な状況下で、符号は異なる図面で重複使用されており、それらは対応する、または類似の部品を示すことを理解すべきである。このほか、実施形態の十分な理解を提供すべく大量の詳細が記述されている。しかし、当業者なら理解できることは、ここで記述される実施形態はこれらの特定の詳細がなくても実現できることである。その他の実施形態において、記述される相関特徴が曖昧にならないようにするため、工程や部品が詳述されていない。図面は必ずしも、寸法通り描かれておらず、且つある部分の比率は拡大されることにより、詳細と特徴をさらに説明しており、発明の実施形態の範囲を制限するものではない。

“結合”という用語は接続として定義され、直接または間接的に中間部品を通過してもよく、且つ物理的な接続に制限されない。“実質上”という用語は、基本的に、特定の部品（たとえば、要求、装置、特性、特徴、状態等）に適合するものとして、または部品を修飾するその他の語句として定義されるものであり、部品が精確である必要がない。たとえば、操作状態が機能的に所定のスリープ状態に似ている場合、操作状態は所定のスリープ状態と実質上同じであると理解されるが、所定のスリープ状態とは若干異なる。

ここで使用される“スリープ状態”というのは、増加したハードウェア遅延および／または減少した処理周期、電源状態および／または消耗、リソース使用および／または分配、アクティビティ、サービス、プロセス、メモリ、分配、計算タスク、プロセッサクロック、バスクロック等により特徴付けされるコンピューティング装置の操作状態のことである。たとえば、“スリープ状態”は、ハイバネーション状態、ハードウェアおよび／またはソフトウェア定義（たとえば、ＡＣＰＩ、ＯＳ等）スリープ状態（たとえば、状態Ｓ１、Ｓ２、Ｓ３、およびＳ４）、中間状態、またはハイブリッド状態（たとえば、ハイバネーションとスリープ状態の組み合わせ）を有する。さらに、ある状況において、コンピュータシステムが“スリープ状態”であるとき、コンピューティング装置は、少なくとも一部のコンピューティング装置のメモリ状態、および／または一つ以上のストレージまたはメモリ位置中の操作環境（物理、および／または、仮想）を保留する。

本発明は、ハードウェア障害回復システム、方法、および持続性コンピュータ読み取り可能ストレージ媒体を開示する。まず、簡単に、ハードウェア障害回復システムの例示的システムと配置を説明する。ハードウェア障害回復メカニズムの詳細な記述は、例や変化を含み、以下で記述する。これらの変化は、各種実施形態として記述される。本発明は、図１Ａおよび図１Ｂを参照する。

図１Ａおよび図１Ｂはシステムの実施形態を示す図である。本発明の技術を実施するとき、当業者なら適切な実施形態を理解することができる。当業者なら、さらにその他の可能な実施形態も容易に理解することができる。

図１Ａは、システムバスコンピュータシステム機構であるシステム１００を示す図で、システムの部品は、バス１０２を用いて互いに電気的に通信する。システム１００は、処理ユニット（ＣＰＵまたはプロセッサ）１３０、および各種システムコンポーネントをプロセッサ１３０に結合するシステムバス１０２を有し、システムコンポーネントは、メモリ１０４、たとえば読み取り専用メモリ（ＲＯＭ）１０６、およびランダムアクセスメモリ（ＲＡＭ）１０８を含む。システム１００は直接接続、近接して接続、またはプロセッサ１３０の一部として統合される高速メモリのキャッシュを有する。システム１００は、メモリ１０４、および／またはストレージデバイス１１２から、キャッシュ１２８にデータを複製して、プロセッサ１３０により素早くアクセスされる。このような方式で、キャッシュはパフォーマンスブーストを提供し、データを待つ間のプロセッサ１３０の遅延を防止する。これら、およびその他のモジュールは、プロセッサ１３０を制御する、または制御するように設定されて各種動作を実行する。別のシステムメモリ１０４も同様に使用することができる。メモリ１０４は、異なるパフォーマンス特性を有する複数の異なるタイプのメモリを有する。プロセッサ１３０は、任意の汎用目的プロセッサ、およびハードウェアモジュール、またはソフトウェアモジュール、たとえばストレージデバイス１１２中に保存される第１モジュール１１４、第２モジュール１１６、および、第３モジュール１１８を有し、プロセッサ１３０および特殊用途プロセッサを制御し、ソフトウェア指令は実際のプロセッサ設計に組み込まれる。プロセッサ１３０は、実質上、完全に独立したコンピューティングシステムであり、複数のコア、またはプロセッサ、バス、メモリコントローラ、キャッシュ等を含む。マルチコアプロセッサは対称または非対称である。

ユーザーがシステム１００と相互作用できるようにするため、入力装置１２０は、任意の数量の入力メカニズム、たとえば、スピーチのマイクロフォン、ジェスチャーやグラフィカル入力のタッチスクリーン、キーボード、マウス、動き入力、スピーチ等を表す。出力装置１２２は、従来の技術で知られる一つ、または、それ以上の数量の出力メカニズムである。ある状況下で、マルチモーダルシステムは、ユーザーが、システム１００と通信する複数のタイプの入力を提供できるようにする。通信インターフェース１２４は、通常、ユーザー入力とシステム出力を統治、および、管理することができる。任意の特定のハードウェア配置における制限がなく、よって、ハードウェアやファームウェアが開発されるとき、ここでの基本的特徴は、容易に置換されて、ハードウェア、または、ファームウェア配置を改善することができる。

ストレージデバイス１１２は不揮発性メモリであり、且つ、ハードディスク、または、その他のタイプのコンピュータ読み取り可能媒体であり、コンピュータ読み取り可能媒体は、コンピュータ、たとえば、磁気カセット、フラッシュメモリカード、固体メモリ装置、デジタル多用途ディスク、カートリッジ、ランダムアクセスメモリ（ＲＡＭ）１０８、読み取り専用メモリ（ＲＯＭ）１０６、および、それらの混合によりアクセス可能なデータデータを保存する。

ストレージデバイス１１２は、ソフトウェアモジュール１１４、１１６、１１８を有して、プロセッサ１３０を制御する。その他のハードウェア、または、ソフトウェアモジュールも含まれる。ストレージデバイス１１２は、システムバス１０２に接続される。一態様において、特定の機能を実行するハードウェアモジュールは、必要なハードウェアコンポーネント、たとえば、プロセッサ１３０、バス１０２、ディスプレイ１３６等と接続するコンピュータ読み取り可能媒体中に保存されるソフトウェアコンポーネントを有して、機能を実行する。

コントローラ１１０は、システム１００上の専門のマイクロコントローラ、または、プロセッサ、たとえば、ＢＭＣ（基板管理コントローラ）である。一部の例では、コントローラ１１０は、インテリジェントプラットフォーム管理インターフェイス（ＩＰＭＩ）の一部である。さらに、一部の例では、コントローラ１１０は、システム１００のマザーボード、または、メイン回路板に組み込まれる。コントローラ１１０は、システム管理ソフトウェアとプラットフォームハードウェア間のインターフェースを管理することができる。コントローラ１１０は、また、各種システムデバイス、および、部品（内部、および／または、外部）、たとえば、コントローラ、または、周辺装置と通信し、以下で更に記述する。

コントローラ１１０は、通知、警告、および／または、事象に特定の対応を生成するとともに、遠隔装置、または、部品と通信（たとえば、電子メールメッセージ、ネットワークメッセージ等）して、自動ハードウェア障害回復工程等の指令や命令を生成する。システム管理者は、コントローラ１１０と遠隔通信して、特定のハードウェア障害回復工程、または、操作を初期化、または、実行し、以下で更に記述する。

システム１００上の異なるタイプのセンサー（たとえば、センサー１２６）は、コントローラ１１０に、パラメータ、たとえば、冷却ファン速度、電力状態、操作システム（ＯＳ）状態、ハードウェア状態等を報告することができる。コントローラ１１０は、さらに、システムイベントログコントローラ、および／または、ストレージを有して、コントローラ１１０により受信される事象、警告、および、通知を管理、および、保存する。たとえば、コントローラ１１０、または、システムイベントログコントローラは、一つ以上の装置、および、部品から、警告、または、通知を保存するとともに、警告、または、通知をシステムイベントログストレージコンポーにネント中に保存する。

フラッシュメモリ１３２は、ストレージ、および／または、データ転送に用いられるシステム１００により用いられる電子不揮発性コンピュータストレージ媒体、または、チップである。フラッシュメモリ１３２は、電気的に消去、および／または、再プログラム化される。フラッシュメモリ１３２は、たとえば、消去可能ＰＲＯＭ（ＥＰＲＯＭ）、電気的に消去可能ＰＲＯＭ（ＥＥＰＲＯＭ）、ＲＯＭ、ＮＶＲＡＭ、または、相補型ＭＯＳ（ＣＭＯＳ）を有する。フラッシュメモリ１３２は、システム１００が起動するとき、システム１００により実行されるファームウェア１３４、および、ファームウェア１３４に指定される一組の設定を保存する。フラッシュメモリ１３２は、さらに、ファームウェア１３４により用いられる配置を保存することができる。

ファームウェア１３４は、ベーシックインプット／アウトプットシステム（ＢＩＯＳ）、または、その後継、または、等価な部品、たとえば、エクステンシブルファームウェアインターフェース（ＥＦＩ）、または、ユニファイドエクステンシブルファームウェアインタフェース（ＵＥＦＩ）を有する。システム１００が起動されるたびに、ファームウェア１３４は、シーケンスプログラムとしてロード、および、実行される。ファームウェア１３４は、一組の配置に基づいて、システム１００中に存在するハードウェアを識別、初期化、並びに、テストする。ファームウェア１３４は、システム１００上で、セルフテスト、たとえば、パワーオンセルフテスト（ＰＯＳＴ）を実行する。このセルフテストは、各種ハードウェアコンポーネント（たとえば、ハードディスクドライブ、光学読み取り装置、冷却装置、メモリモジュール、拡張カード等）の機能性をテストする。ファームウェア１３４は、メモリ１０４、ＲＯＭ１０６、ＲＡＭ１０８、および／または、ストレージデバイス１１２中の一領域をアドレス、および、割り当てて、操作システム（ＯＳ）を保存する。ファームウェア１３４は、ブートローダーおよび／または、ＯＳをロードするとともに、システム１００の制御権をＯＳに与える。

システム１００のファームウェア１３４は、どのように、ファームウェア１３４が、システム１００中で、各種ハードウェアコンポーネントを制御するかを定義するファームウェア配置を有する。ファームウェア配置は、システム内の各種ハードウェアコンポーネントが起動される順番を判断する。ファームウェア１３４は、各種異なるパラメータの設定を許可するインターフェース（たとえば、ＵＥＦＩ）を提供し、これは、ファームウェアデフォルト設定のパラメータと異なる。たとえば、ユーザー（たとえば、システム管理者）は、ファームウェア１３４を用いて、クロック、および、バス速度を指定し、どの周辺設備をシステム１００に取り付けるか指定し、監視の状態（たとえば、ファン速度、および、ＣＰＵ温度制限）を指定し、システム１００のパフォーマンス全体、および、電力使用量に影響する多種のその他のパラメータを指定する。

ファームウェア１３４は、フラッシュメモリ１３２中に保存されるように説明されているが、当業者なら理解できるように、ファームウェア１３４は、その他のメモリ、部品、たとえば、メモリ１０４、または、ＲＯＭ１０６中に保存することができる。しかし、示されるフラッシュメモリ１３２中に保存されるファームウェア１３４は説明の目的であり、これに限定しない。

システム１００は一つ以上のセンサー１２６を有する。一つ以上のセンサー１２６は、たとえば、一つ以上の温度センサー、サーマルセンサー、酸素センサー、化学センサー、ノイズセンサー、ヒートセンサー、電流センサー、電圧検出器、気流センサー、流量センサー、赤外線放射温度計、熱流束センサー、温度計、高温計等を有する。一つ以上のセンサー１２６は、たとえば、バス１０２により、プロセッサ、キャッシュ１２８、フラッシュメモリ１３２、通信インターフェース１２４、メモリ１０４、ＲＯＭ１０６、ＲＡＭ１０８、コントローラ１１０、および、ストレージデバイス１１２と通信する。一つ以上のセンサー１２６は、また、一つ以上の異なる手段、たとえば、アイスクエアドシー（Ｉ２Ｃ）、汎用並列出力（ＧＰＯ）等により、システム内のその他の部品と通信する。

図１Ｂは、記述方法、または、操作を実行するチップセット機構を有し、グラフィカルユーザーインターフェース（ＧＵＩ）を生成、ならびに、表示するのに用いられるコンピュータシステム１５０を示す図である。コンピュータシステム１５０は、コンピュータハードウェア、ソフトウェア、および、ファームウェアを有し、本発明の技術を実行する。システム１５０は、プロセッサ１６０を有し、任意の数量の物理的、および／または、論理的に異なるリソースを表し、ソフトウェア、ファームウェア、および、識別された計算を実行するハードウェアを実行することができる。プロセッサ１６０は、プロセッサ１６０からの入出力を制御することができるチップセット１５２と通信する。この例において、チップセット１５２は、情報を出力装置１６４、たとえば、ディスプレイに出力するとともに、ストレージデバイス１６６（磁気媒体、固体媒体を有する）と情報を読み書きする。チップセット１５２も、ＲＡＭ１６８とデータをやり取りする。各種ユーザーインターフェース装置１５６と相互作用するブリッジ１５４が提供されて、チップセット１５２と相互作用する。このようなユーザーインターフェース装置１５６は、キーボード、マイクロフォン、タッチ検出、および、処理回路、ポインティングデバイス（マウス等）を有する。一般に、システム１５０への入力は、任意の各種ソース、機器生成、および／または、使用者の生成による入力である。

チップセット１５２も、異なる物理インターフェースを有する一つ以上の通信インターフェース１５８と相互作用する。このような通信インターフェースは、有線、および、無線のローカルエリアネットワーク、広域帯域幅ネットワーク、および、パーソナルエリアネットワークのインターフェースを有する。本発明におけるＧＵＩを生成、表示、および、使用する方法のいくつかの応用は、物理インターフェースにより、または、ストレージデバイス１６６、または、ＲＡＭ１６８中に保存されるデータを分析するプロセッサ１６０によって、機器自身により生成された順序付けられたデータセットを受信する工程を有する。さらに、機器は、ユーザーインターフェース装置１５６により、ユーザーからの入力を受信するとともに、適当な機能を実行し、たとえば、プロセッサ１６０を用いて、これらの入力を解釈することによりブラウズ機能を実行する。

さらに、チップセット１５２は、電源が起動するとき、コンピュータシステム１５０により実行されるファームウェア１６２と通信することができる。ファームウェア１６２は、一組のファームウェア配置に基づいて、コンピュータシステム１５０中に存在するハードウェアを認識、初期化、および、テストすることができる。ファームウェア１６２は、システム１５０で、セルフテスト、たとえば、ＰＯＳＴを実行する。セルフテストは、各種ハードウェアコンポーネント１５２〜１６８の機能をテストすることができる。ファームウェア１６２は、メモリ１６８中の一領域をアドレス、および、割り当てて、ＯＳを保存する。ファームウェア１６２は、ブートローダー、および／または、ＯＳをロードするともに、システム１５０の制御権をＯＳに与える。一部の例では、ファームウェア１６２は、ハードウェアコンポーネント１５２〜１６０、および、１６４〜１６８と通信する。ここで、ファームウェア１６２は、チップセット１５２、および／または、一つ以上のその他の部品により、ハードウェアコンポーネント１５２〜１６０、および、１６４〜１６８と通信する。一部の例では、ファームウェア１６２は、ハードウェアコンポーネント１５２〜１６０、および、１６４〜１６８と直接通信することができる。

理解できることは、例示的システム１００、および、１５０は、二個以上のプロセッサ（たとえば、１３０、１６０）を有する、または、ネットワークにより接続されるコンピューティング装置の一群、または、クラスタであり、良い処理能力を提供する。

説明をわかりやすくするため、ある実施形態において、本発明の技術は、独立した機能ブロックを含み、機能ブロックは、装置、装置の部品、ソフトウェア、または、ハードウェアとソフトウェアの組み合わせで具体化される方法中の工程やルーティンを有する。

いくつかの実施形態において、コンピュータ可読ストレージデバイス、媒体、および、メモリは、ビットストリーム等を含むケーブルや無線信号を有する。しかし、言及されるとき、持続性コンピュータ読み取り可能ストレージ媒体は、エネルギー、キャリア信号、電磁波、および、信号自身等の媒体を明確に排除する。

上記の例における方法は、コンピュータ実行可能命令を用いて実施され、コンピュータ実行可能命令は、コンピュータ読み取り可能媒体から保存される、または、利用可能である。このような指令は、たとえば、指令、および、データは、汎用目的コンピュータ、特殊用途コンピュータ、または、特殊用途処理装置を配置して、ある機能、または、機能の群を実行する。用いられるコンピュータリソースの一部は、ネットワークによりアクセス可能である。コンピュータ実行可能命令は、たとえば、バイナリー、中間フォーマット指令、たとえば、アセンブリ言語、ファームウェア、または、ソースコードである。コンピュータ読み取り可能媒体の例は、指令、使用した情報、および／または、方法の期間中に生成された情報の保存に用いられ、コンピュータ読み取り可能媒体は、記述される例に従って、磁気、または、光学ディスク、フラッシュメモリ、ＵＳＢデバイスを有し、磁気、または、光学ディスク、フラッシュメモリ、ＵＳＢデバイスは、不揮発性メモリ、ネットワークストレージデバイス等に提供される。

これらの開示における方法を実施する装置は、ハードウェア、ファームウェア、および／または、ソフトウェアを有し、任意の各種フォームファクタを利用する。このようなフォームファクタの一般的な例は、ラップトップ、スマートフォン、スモールフォームファクタパーソナルコンピュータ、ＰＤＡ、ラックマウント型装置、スタンドアロン装置等を有する。ここで記述される機能性は、さらに、周辺装置、または、アドインカードで具体化される。さらなる例として、このような機能性は、単一装置で実行される異なるチップ、または、異なるプロセス間において、回路基板上で実行されてもよい。

このような指令を伝達する指令、媒体、それらを実行するコンピューティングリソース、および、このようなコンピューティングリソースをサポートするその他の構造は、ここで記述される機能を提供する手段である。

図１Ｃは、仮想環境１７０のシステムを示す図である。仮想環境１７０は、仮想マシンマネージャー（ＶＭＭ）１７２を有して、バーチャルマシン（ＶＭｓ）１７４を管理する。ＶＭＭ１７２は、ユーザーが、ＶＭｓ１７４を創造、編集、開始、および、停止できるようにする。ＶＭＭ１７２は、さらに、その他の機能性を有効にして、ＶＭｓ１７４を管理する。たとえば、ＶＭＭ１７２は、ユーザー、または、システム管理者が、各ＶＭｓ１７４のコンソールを表示、および、制御、ＶＭｓ１７４のパフォーマンスと利用統計の調査、全ての作動中のＶＭｓ１７４、および、ホスト１７６、および、それらの個別の統計の調査、ＶＭエラーおよび故障を識別、作業負荷の移動等ができるようにする。

ＶＭＭ１７２も、ユーザーが、ＶＭｓ１７４の仮想化ホスト１７６を配置、および、管理、リソースプール１７８を管理、および、配置ネットワーク、または、データセンター１８０中のネットワーク形成を行えるようにする。ＶＭＭ１７２は、ユーザーが、ＶＭｓ１７４を配置、ＶＭｓ、または、作業負荷を移動、および、ＶＭｓ１７４、ホスト１７６、リソースプール１７８等を管理、および、配置することができるようにする。

ホスト１７６は、それぞれ、一つ以上のＶＭｓ１７４を有する。さらに、ホスト１７６は、個別のハイパーバイザを有し、ＶＭｓ１７４を作動させる。ホスト１７６は、ソフトウェア環境をホスト１７６に提供するホスト操作システムを作動させ、各ＶＭｓ１７４は、ソフトウェア環境をＶＭｓ１７４に提供するゲスト操作システムを作動させる。

ＶＭｓ１７４が配置されて、ＶＭｓ１７４により用いられるハードウェアリソースを含むリソースプール１７８を用いて、個別の仮想のハードウェアリソースを生成して、ＶＭｓ１７４と個別の作業負荷をサポートする。リソースプール１７８は、各種タイプのハードウェアリソース、たとえば、プロセッサ、メモリ、ストレージデバイス、ネットワークインターフェース、グラフィック処理ユニット、入力装置、出力装置等を有する。ハードウェアリソースは、ホスト１７６上のリソースになる。しかし、ハードウェアリソースは、また、データセンター１８０中にその他のリソースを有する。たとえば、ラックスケール機構に基づいたデータセンターにおいて、リソースプール１７８は、かならずしもホスト１７６の一部ではないリソースのプールを有し、および、ホスト１７６と結合する能力があるが、電気的にホスト１７６と結合しないリソースを有する。

リソースプール１７８は、同じタイプの複数のリソース、および／または、余剰の追加リソースを有する。たとえば、リソースプール１７８は、追加プロセッサ、メモリ、電源、ファン、ストレージデバイス、周辺装置等を有する。この方式で、特定のＶＭにより用いられるメモリなどのリソースが重大なエラーを有する場合、メモリは、リソースプール１７８中の追加メモリにより代替されて、エラーを快速に修復する。

図２は、ハードウェアコンポーネントを代替するスリープ状態メカニズムを実行するシステム２００を示す図である。スリープ状態メカニズムは、ＡＣＰＩ（先進形態と電源インターフェース）電源管理に基づく。たとえば、システム２００は、ＡＣＰＩを用いて、システム２００を特定のスリーピング状態に置き、よって、ユーザーは、故障したコンポーネントを代替することができ、システム２００を再起動、または、リブートしなくてもよい。一旦、ユーザーが、故障したコンポーネントを代替すると、システム２００は、特定のスリープ状態から作業状態に転換することができ、一つ以上のアプリケーションをリブート、再配置、または、配置転換する必要がない。

たとえば、ハードディスクデバイス２０２は、作業状態（Ｓ０）２２０で作動する。Ｓ０（２２０）は、正常な操作状態を表す。システム２００が、たとえば、検出されたハードウェアエラーや故障に基づいて、ハードウェアコンポーネントの代替が必要であると判断する場合、システム２００は、スリープモード転換２１６を実行して、システム２００をスリープ状態にする。スリープ状態は、一つ以上の要因、たとえば、代替される装置のタイプ、エラー、または、故障等の深刻度に基づく。スリープ状態は、スリープ状態Ｓ３（２１４）とスリープ状態Ｓ４（２１２）を有する。

スリープ状態Ｓ３（２１４）はディープスリープ状態であり、システム２００は、低電源リソース消耗で作動する。さらに、Ｓ３（２１４）が転換して作業状態Ｓ０（２２０）に戻るとき、長いウェイクアップ遅延を有する。一方、スリープ状態Ｓ４（２１２）は最深スリープ状態であり、システム２００は、最低電力消耗で作動する。Ｓ４（２１２）は、最深レベルのスリープ状態であり、Ｓ４（２１２）スリープ状態のウェイクアップ遅延は、全各種スリープ状態の最長遅延である。

前述の通り、システム２００は、一つ以上の前述の要因に基づいて、作業状態Ｓ０（２２０）から、スリープ状態Ｓ３（２１４）、Ｓ４（２１２）、または、任意のその他のスリープ状態に転換する。たとえば、ハードウェアエラー、または、故障が周辺装置２０４（たとえば、ＰＣＩエクスプレス）に関連する場合、システム２００は、Ｓ３（２１４）スリープ状態に転換する。システム２００がＳ３（２１４）スリープ状態であるとき、ユーザーは、代替周辺装置で、周辺装置２０４を代替することができる。一旦、周辺装置２０４が代替されると、システム２００は、ウェイクアップ転換２１８を実行して、作業状態Ｓ０（２２０）をレジュームする。

ハードウェアエラー、または、故障が、メモリ２０６、プロセッサ２０８、電源ユニット２１０に関連する場合、システム２００は、最深スリープ状態であるＳ４（２１２）スリープ状態に転換する。システム２００がＳ４（２１２）スリープ状態にあるとき、ユーザーは、部品交換によって、故障のメモリ２０６、プロセッサ２０８、または、電源ユニット２１０を代替する。一旦、メモリ２０６、プロセッサ２０８、または、電源ユニット２１０が代替されると、システム２００は、ウェイクアップ転換２１８を実行して、作業状態 Ｓ０（２２０）をレジュームする。注意すべきことは、特定のスリープ状態、または、その他のタイプの状態は、軽度のスリープ／その他のタイプの状態、または、深い状態／その他のタイプの状態間で変化する。

いくつかの配置において、部品交換は、代替されたコンポーネントと同じである。たとえば、代替プロセッサは、代替されるプロセッサ（たとえば、プロセッサ２０８）と同じである（たとえば、同じモデル、ブランド等）。これは、代替が引き起こす任意のリソース衝突を防止することができる。さらに、システム２００は、ここで記述されるハードウェア代替メカニズムを用いて、通常、ホットスワップ、または、ホットプラグハードウェア障害回復メカニズムに用いられるホットプラグ設計の回路、または、ハードウェア、ファームウェア、および／または、ドライバがない状況下で、ハードウェアコンポーネントを代替することができる。交換装置は、交換されると完全に同じではないが、機能は同じである。一態様において、システムが転換する状態のタイプは、部品交換が同じか、または、単に互換性があるかどうかに基づく。

当業者なら理解できるように、ハードウェア代替のスリープ状態メカニズムは、図２よりもさらに多い、または、さらに少ないスリープ状態で実施される。実際、図２中のスリープ状態（Ｓ０、Ｓ３、Ｓ４）は説明をはっきりとさせるためのものであり、これに限定されない。別のタイプの状態も、各種段階で適用される。このほか、本発明は、図２中で示される部品の他に、その他の部品と装置も、本発明の原則に従って代替される。実際、図２の特定の部品、または、装置（たとえば、周辺装置２０４、メモリ２０６、プロセッサ２０８、および、電源ユニット２１０）は、説明を簡潔にするためのものであり、これに制限するものではない。

図３は、スリープ状態表３００である。スリープ状態表３００は、故障記述３０２のカラム、実行する障害回復スリープ状態３０４のカラム、および、障害回復スリープ状態３０４で定義される特定のスリープ状態に関連する遅延レジューム３０６を有する。

故障記述３０２は、故障、または、エラーの位置、または、ソースを定義する。たとえば、故障記述３０２は、位置、または、ソースを、プロセッサ３０８、メモリ３１０、電源３１２、周辺装置３１４、ストレージデバイス３１６、または、ファン３１８として定義する。

障害回復スリープ状態３０４は、故障記述３０２中の対応装置にマップされる特定のスリープ状態を定義することができる。たとえば、プロセッサ３０８、メモリ３１０、電源３１２は、Ｓ４（３２０）スリープ状態にマップされる。周辺装置３１４とストレージデバイス３１６は、それぞれ、Ｓ３（３２２）スリープ状態にマップされる。ファン３１８はＳ１（３２４）スリープ状態にマップされる。

Ｓ４（３２０）スリープ状態は最低電源リソース消耗を有する。Ｓ３（３２２）スリープ状態は次の最低電源リソース消耗を有し、Ｓ１（３２４）スリープ状態は最高電源リソース消耗を有する。これらのスリープ状態はそれぞれ、個別の遅延期間を有して、作業状態、または、正常な操作状態をレジュームする。

遅延レジューム３０６は、スリープ状態から作業状態、または、正常な操作状態をレジュームする対応する遅延を指示する。たとえば、Ｓ１（３２４）スリープ状態は長い遅延３３０を有し、Ｓ３（３２２）スリープ状は長い遅延３２８を有し、Ｓ４（３２０）スリープ状態は最長遅延３２６を有する。対応する遅延３２６〜３３０は、少なくとも一部が、個別のスリープ状態の個別の電源リソース消耗設定に基づく。たとえば、低い電源リソース消耗は、通常、作業状態をレジュームする遅延を長くする。

スリープ状態表３００は、特定のスリープ状態に対応する各種リソース、または、故障を有し、ハードウェア代替操作中に使用する。スリープ状態表３００中の各種リソース、または、故障、スリープ状態、および、遅延は説明をはっきりとする目的であり、これに限定されない。したがって、各種変化が異なる実施形態に提供され、全てがここで検討される。

図４は、ハードウェア障害回復、または、交換手順の各種装置間の通信４００を示す図である。コントローラ１１０は、ハードウェアコンポーネント４０４（たとえば、メモリ１０４、ＲＡＭ１０８、ストレージデバイス１１２、入力装置１２０、出力装置１２２、通信インターフェース１２４、センサー１２６、プロセッサ１３０、電源ユニット、ファン等）の状態を監視４１０する。たとえば、コントローラ１１０は、ハードウェアコンポーネント４０４に関連するエラー、または、故障の回数、エラー、または、故障の重大性、エラー、または、故障のタイプ、エラー、または、故障の復元可能性、エラー、または、故障の因果関係、エラー、または、故障のパフォーマンス結果、エラー、または、故障の位置等を監視することができる。コントローラ１１０は、ＡＣ電源段階４２４期間で、ハードウェアコンポーネント４０４を監視することができる。

システムは、ＡＣ電源段階４２４からＤＣ電源段階４２６に転換するとともに、システム上でファームウェア１３４により実行されるパワーオンセルフテスト（ＰＯＳＴ）４２８を開始し、前述の図１Ａ、および、図１Ｂを参照する。

ＰＯＳＴ４２８開始後、ファームウェア１３４は、スレショルド計数を有するＲＡＳ（信頼性、利用可能性、および、支援性）特徴４１２を有効にする。ＲＡＳ特徴４１２は、特定のハードウェアコンポーネントのエラー、または、故障を識別するとともに、エラー、または、故障の計数を保存する。計数が用いられて、ハードウェアコンポーネント代替が必要かどうか判断する。たとえば、部品のエラー、または、故障のスレショルド数は、代替をトリガーする。スレショルドは、さらに、一つ以上の要因、たとえば、部品のタイプ、エラー、または、故障のタイプ（たとえば、永久性、一時性、一過性、断続性、重大性、駆動的、衝突等）、エラー、または、故障の頻度、エラー、または、故障の重大性等に基づいて変化する。

ハードウェアコンポーネント４０４は、ハードウェアコンポーネント４０４によって引き起こされるエラー４１４をファームウェア１３４に報告する。ハードウェアコンポーネント４０４は、割り込みサービスルーチン、たとえば、ＵＥＦＩ（ユニファイドエクステンシブルファームウェアインターフェース）ＳＭＩ（システムマネジメントモード）により、エラーを報告する。ファームウェア１３４は、その後、エラー４１６をコントローラ１１０に報告する。コントローラ１１０は、コントローラ１１０に関連するシステムイベントログ中のエラーを保存する。コントローラ１１０は、さらに、エラーをシステム管理者、または、サーバに報告する。たとえば、コントローラ１１０は、帯域幅（ＯＯＢ）メッセージをシステム管理者に送信して、エラーを報告する。

ハードウェアコンポーネント４０４は、さらに、エラー４１８をＯＳ４０２に報告する。いくつかの実施形態において、ハードウェアコンポーネント４０４は、ＡＣＰＩ（先進形態、および、パワーインターフェース）ハードウェアエラーソース表（ＨＥＳＴ）により、エラーをＯＳ４０２に送信する。

コントローラ１１０は、さらに、スリープ状態要求４２０をＯＳ４０２に発信する。コントローラ１１０は、ＲＥＳＴ（ｒｅｐｒｅｓｅｎｔａｔｉｏｎａｌ ｓｔａｔｅ ｔｒａｎｓｆｅｒ）機構、たとえば、ＲＥＳＴｆｕｌ ＡＰＩに基づいて、一サービスにより、スリープ状態要求をＯＳ４０２に送信する。スリープ状態要求は、特定のスリープ状態、たとえば、前述の図３に示されるＳ３、または、Ｓ４を指定する。特定のスリープ状態は、エラー、または、故障の特定の位置に基づく。たとえば、主要ハードウェアコンポーネント（たとえば、プロセッサ、メモリ、電源等）に起因するエラー、または、故障において、特定のスリープ状態は、深いスリープ状態（つまり、低電源リソース消耗のスリープ状態）である。一方、周辺装置、アドオン、または、補助部品（たとえば、ＰＣＩｅカード）に起因するエラー、または、故障において、スリープ状態は深くない（すなわち、低電源リソース消耗であるが、最低電源リソース消耗ではないスリープ状態）。

ＯＳ４０２がスリープ状態要求を受信するとき、システムが仮想環境（たとえば、図１Ｃ中に記述される仮想環境１７０）と関連する場合、仮想マシンマネージャー（ＶＭＭ）に通知する。ＯＳ４０２は、また、スリープ状態に入る前、一つ以上のアプリケーション、および、ドライバ、たとえば、エラー、および／または、故障したコンポーネントに関連するアプリケーションとドライバとドライバを停止する。ＯＳ４０２は、その後、スリープ状態要求に基づいて、システムをスタンバイ４３０（すなわち、スリープ状態）にする。スタンバイ状態は、前述のように、特定のスリープ状態に従う。

スタンバイ４３０状態の期間中、ユーザー、または、システム管理者は、故障したコンポーネントを部品交換で代替する。ユーザー、または、システム管理者は、ＯＳ４０２を再起動、または、リブートすることなく、故障したコンポーネントを代替する。衝突を防止するため、部品交換は、代替される故障したコンポーネントと同じである。

故障したコンポーネントが代替された後、コントローラ１１０は、ウェイクアップ要求４２２をＯＳ４０２に発信する。ウェイクアップ要求は、ＯＳ４０２をトリガーして、スタンバイ状態４３０から作業状態に転換する（たとえば、図２に示されるＳ０）。コントローラ１１０は、ＲＥＳＴｆｕｌ ＡＰＩにより、ウェイクアップ要求を発信する。

ＯＳ４０２は、ウェイクアップ要求を受信するとともに、作動、または、正常な操作状態に転換する。システムが仮想環境（たとえば、図１Ｃに記述される仮想環境１７０）と関連する場合、ＯＳ４０２は、さらに、ＶＭＭに通知する。さらに、スタンバイ状態４３０からレジュームした後、ＯＳ４０２は、任意の停止したアプリケーション、または、ドライバを再起動する。

各種装置間の通信４００は、異なるタイプのサービス、および／または、インターフェースに基づく。たとえば、ファームウェア１３４は、ハードウェアインターフェース４３４により、ハードウェアコンポーネント４０４と通信し、たとえば、ＵＥＦＩ ＢＩＯＳは、ＰＣＩエクスプレス拡張コンフィグレーション空間フラットメモリ−マップアクセスメカニズムにより、ＰＣＩｅレジスタを読み取り、ＣＰＵ ＭＳＲ指令により、ＣＰＵ ＩＡ３２_Ｍｃｉ_Ｓｔａｔｕｓを読み取る。同様に、ハードウェアコンポーネント４０４は、ハードウェアインターフェース１３４により、操作システム（ＯＳ）４０２と通信する。さらに、コントローラ１１０は、ＩＰＭＩ（インテリジェントプラットフォーム管理インターフェース）、または、ＲＥＳＴ（ｒｅｐｒｅｓｅｎｔａｔｉｏｎａｌ ｓｔａｔｅ ｔｒａｎｓｆｅｒ）に基づいたサービス、たとえば、ＲＥＳＴｆｕｌにより、ファームウェア１３４と通信する。最後に、コントローラ１１０は、ＲＥＳＴ機構に基づいたサービス、たとえば、ＲＥＳＴｆｕｌ ＡＰＩにより、ＯＳ４０２と通信する。

図５は、仮想マシンマネージャー（ＶＭＭ）１７２により、リソースとＶＭｓを回復させる故障修復表５００である。表５００は、特徴カラム５０２、記述カラム５０４、および、優先格付けカラム５０６を有する。表５００は、故障検出特徴５０８、緩和計画５１０、および、ＶＭバックアップ、および、回復特徴５１２を指定する。

故障検出特徴５０８は工程５１４を有し、この工程は、ＯＳからエラー通知を得るとともに、故障の重大性、位置と数量を識別する工程を含む。ＶＭＭ１７２はここで、ＡＣＰＩハードウェアエラーソース表を読み取って、特定のエラー、および／または、エラー詳細を識別する。さらに、故障検出特徴５０８は、高優先度５２０として割り当てられる。

緩和計画５１０は工程５１６を有し、工程は、故障のリソースをリソースプールから隔離する、新しいリソースをＶＭに再度割り当てるとともに、ＶＭを閉鎖して、異なるサーバに転換する工程を有する。緩和計画５１０は高優先度５２０に割り当てられる。

ＶＭバックアップ、および、回復特徴５１２は工程５１８を有し、工程は、ＶＭデータをバックアップして、データ損失を防止し、サーバ、または、システムの調子が良くなった後（たとえば、障害回復後）、ＶＭデータを修復する工程を有する。ＶＭバックアップ、および、回復特徴５１２は、任意優先度５２２が割り当てられる。

表５００中の各領域、および、部品は説明を明確にする目的のための例示であり、これに限定されない。本発明は、その他の領域、部品、詳細も考慮される。

いくつかの基本システムコンポーネントとコンセプトの開示後、本発明は、続いて、図６〜図９に示される例示方法の実施形態に進む。説明を明確にするため、方法は、図１Ａに示されるシステム１００は各種工程を実行する。ここでまとめられる工程は例であり、且つ、任意の組み合わせで実施され、ある工程の削除、増加、または、修正を含む。

図６は、ハードウェア障害回復メカニズムを実行する方法６００を示す図である。工程６０２において、システム１００は、システム１００に関連するハードウェアエラーを検出する。システム１００は、コントローラ１１０によりエラーを検出する。たとえば、コントローラ１１０は、システム１００のハードウェアコンポーネント（メモリ１０５、ＲＡＭ１０８、ストレージデバイス１１２、入力装置１２０、出力装置１２２、通信インターフェース１２４、プロセッサ１３０、ファン（図示しない）、電源（図示しない）等の状態を監視することができる。

システム１００は、ハードウェアエラーに関連する誤り件数を判断する。たとえば、システム１００は、ハードウェアエラー発生の回数を判断する。システム１００は、さらに、誤り件数がエラースレショルドを超えるか否か判断する。エラースレショルドは、エラーの所定回数、または、計数（たとえば、Ｎ回のエラー）、エラーの頻度（たとえば、Ｙ時間周期中、Ｎ回のエラー発生）、ハードウェアエラーに関する回復期間（たとえば、Ｎ時間単位を費やして、ハードウェアエラーから修復）等に基づく。さらに、システム１００は、さらに、ハードウェアエラーの重大性を判断する。たとえば、システム１００は、エラーが重大である、または、修復できないエラーであるか、ハードウェアエラーがデータ損失を生じるか、ハードウェアエラーが中断するか（たとえば、システムコンポーネント、システム１００、および／または、サービスの中断）等を判断する。

工程６０４において、システム１００は、ハードウェアエラーに関連するシステムコンポーネントを識別する。システム１００は、ハードウェアエラーのソース、または、位置を識別する。たとえば、システム１００は、エラーがプロセッサ１３０からのものか判断する。システムコンポーネントは、たとえば、プロセッサ、メモリ、電源ユニット、ストレージデバイス、ファン、周辺装置（たとえば、ＰＣＩ、ＰＣＩｅ等）、アドインカード（ａｄｄ−ｏｎ ｃａｒｄ）等である。

工程６０６において、システム１００は、要求を生成して、システム１００の操作システムをトリガーし、システム１００を特定の操作状態 （たとえば、スリープ状態、冬眠状態等）にする。システム１００は、たとえば、コントローラ１１０により要求を生成する。さらに、コントローラ１１０は、要求を操作システムに送信して、システム１００を特定の操作状態にする。

要求は、ハードウェアエラーの重大性、誤り件数、または、ハードウェアエラーに関する任意のその他の特徴、または、統計値に基づいて生成される。たとえば、要求は、ハードウェアエラーが重大なエラーである、および／または、誤り件数がエラースレショルドを超えるという判断に基づいて生成される。

特定の操作状態は、エラーに関するシステムコンポーネントのコンポーネントのタイプに基づいて決定される。たとえば、特定の操作状態は、エラーに関連するシステムコンポーネント（たとえば、周辺装置、プロセッサ、メモリ、電源、ファン、ディスクドライブ等）の識別に基づいて決定される。

前述の通り、特定の操作状態は、コンポーネントのタイプに基づいて変化する。たとえば、コンポーネントのタイプが周辺装置であるとき、特定の操作状態は第一スリープ状態であり（たとえば、Ｓ３ ２１４）、および、コンポーネントのタイプがプロセッサ、メモリ、または、電源ユニットであるとき、第二スリープ状態（たとえば、Ｓ４ ２１２）である。この例において、第一スリープ状態と比べて、第二スリープ状態は、低電源リソース消耗であり、および／または、長いレジューム遅延を有する。

操作システムは、要求を受信するとともに、システム１００を特定の操作状態にする。操作システムは、さらに、システムコンポーネントに関連する任意のドライバ、および／または、アプリケーションを停止する。

工程６０８において、システム１００が特定の操作状態に置かれた後、システム１００は、システムコンポーネントが代替されるという指示を生成する（たとえば、コントローラ１１０により）ことができる。指示は、システム１００の操作システムを再起動せず、ドライバ、または、ソフトウェアをインストールせず、システムコンポーネントを再配置せず、システム１００をシャットダウンしない状況下で、システムコンポーネントが代替されることを示す。

指示は、システム１００が特定の操作状態であるかどうかの決定に基づいて生成される。前述の通り、特定の操作状態は、コンポーネントのタイプに関連する操作状態に対応する、および／または、システム１００をシャットダウン、または、再起動しない状況下で、システムコンポーネントを代替するのに適する。

工程６１０において、システムコンポーネントは、代替システムコンポーネントに代替される。工程６１２において、一旦、システムコンポーネントが代替されると、システム１００は、代替システムコンポーネントにより、操作を再開することができる。システム１００は、操作の作業状態、または、一般状態にしたがって、操作を再開することができる。システム１００は、最小、または、制限された中断で、代替システムコンポーネントを用いて、一般操作をレジュームする。

一部の例では、作動、または、正常な操作状態をレジュームする前、システム１００は、代替システムコンポーネントが、システムコンポーネントにとって、互換性がある代替であるか確認する。たとえば、システム１００は、システムコンポーネントと代替システムコンポーネントに関連するハードウェア情報を収集するとともに、ハードウェア情報を比較して、二個の部品のハードウェア情報がマッチするか、または、実質上類似するか判断する。システム１００は、さらに、代替システムコンポーネントが、システムコンポーネントと同じ、または、ほぼ同じであるか判断する。

さらに、代替システムコンポーネントが、互換性があると判断するとき、システム１００は、代替システムコンポーネントが、システムコンポーネントと同じタイプであるか、同じハードウェア配置を有するか、同じファームウェア、および／または、ソフトウェアドライバを用いるか、同じリソース要求を有するか等を判断することができる。システム１００は、互換性決定に基づいて、指示を生成する。たとえば、システム１００は、指示を生成し、代替システムコンポーネントが、互換性があるか、ないかを示す。

代替システムコンポーネントが、互換性がある場合、システム１００は、代替を終了するとともに、操作をレジュームする。このほか、代替システムコンポーネントが、互換性がない場合、システム１００は、代替を拒絶する、または、警告を発する。

システム１００が仮想環境（たとえば、ＶＭｓ等を有する）の一部である場合、システム１００は、ＶＭ作業負荷を、代替メカニズムの一部として修復、または、転移させる。たとえば、システム１００は、代替システムコンポーネントがすでに代替され、および、システム１００がレジューム済み、または、一般、または、運転操作をレジュームする準備ができた後、ＶＭ作業負荷を停止させるとともに、システム１００上で、ＶＭ作業負荷を修復する。

システム１００が、ホットプラグハードウェア、回路、ドライバ、設計等を有さない場合でも、システム１００は、方法６００の任意の工程を実行して、システムコンポーネントを代替する。たとえば、たとえ、システム１００、システムコンポーネント、および／または、代替システムコンポーネントが、ホットプラグ操作をサポートしなくても、記述されるシステム１００は、代替システムコンポーネントで、システムコンポーネントを代替する。

図７は、システム内で、ハードウェアエラーを監視、および、識別する方法７００のフローチャートである。工程７０２において、システム１００は、システム１００上で、ハードウェアエラーを識別、および、分析することができる。ハードウェアエラーは、システム上のシステムコンポーネントに関連するエラー、または、故障である。さらに、システム１００は、ハードウェアコンポーネントを監視して、エラー発生時、ハードウェアエラーを検出する。さらに、システム１００は、エラーの状態、エラーの重大性（たとえば、重大である、重大でない、破壊性、永久性、一時性等）、エラーの位置（たとえば、ソースコンポーネント、または、ドライバ）、誤り件数（たとえば、エラー数）等を判断する。

工程７０４において、システム１００は、エラーが、エラースレショルドを超えるか否か判断する。エラーがスレショルドを超えない場合システム１００は工程７０２に戻る。一方、エラーがスレショルドを超過する場合、工程７０６において、システムは、エラーのソースをチェックする。

工程７０８において、システム１００は、エラーが、プロセッサ、メモリ、または、電源からなのか判断する。工程７１０において、システム１００は、その後、スリープ状態Ｓ４要求を送信して、システム１００をＳ４スリープ状態にする。Ｓ４スリープ状態は、最低電源リソース消耗により特徴付けられる最深スリープ状態である。

工程７１２において、システム１００は、エラーが、周辺装置からのものか判断する。エラーが周辺装置からのものであるとき、工程７１４において、システム１００は、スリープ状態Ｓ３要求を送信して、システム１００をＳ３スリープ状態にする。Ｓ３スリープ状態は、低電源リソース消耗のディープスリープ状態である。

工程７１６において、システム１００は、システム１００の電源状態を監視して、システム１００が、工程７１０、または、７１４で、スリープ状態要求に対応して、予期通り、スリープ状態に入ったことを確認する。

工程７１８において、システムは、システム１００が、スリープ状態になったか判断する。システムが、スリープ状態に入っていない場合、システム１００は、工程７１６に戻って、電源状態を監視する。反対に、システム１００がすでにスリープ状態になっている場合、工程７２０において、システム１００は、その後、システム１００が、エラーに関連するシステムコンポーネントのハードウェア代替の準備ができているという通知を生成する。一旦、システム１００が、このような工程の準備をすると、ユーザーは、システムコンポーネントを代替する。

図８は、方法７００後にインストールされる代替システムコンポーネントを検査する方法８００のフローチャートである。工程８０２において、システム１００は、ハードウェア代替がすでに完了していることを示す指示を獲得する。このとき、システムコンポーネントは代替システムコンポーネントで代替されている。

工程８０４において、システム１００は、再起動状態、および、エラーの原因をチェックする。再起動状態がＳ３、且つ、エラーの原因が周辺装置である場合、工程８０６において、システム１００は、その後、部品交換のハードウェアコンポーネント情報（たとえば、コンポーネントのタイプ、コンポーネントバージョン、コンポーネント要求、コンポーネントドライバ、コンポーネント識別子等）を分析する。

一方、再開状態がＳ４、且つ、エラーの原因がプロセッサ、メモリ、または、電源である場合、工程８１０において、システム１００は、ＤＣ電源が起動し、且つ、スリープ状態Ｓ４レジューム工程を初期化することを確認する。工程８１２において、システム１００は、さらに、代替装置のハードウェアコンポーネント情報を分析する。

工程８０６、または、工程８１２において、ハードウェアコンポーネント情報を分析した後、工程８０８において、システム１００は、ハードウェアコンポーネント情報を検査する。たとえば、コントローラ１１０は、代替システムコンポーネントに関連するハードウェア詳細を再調査する。

工程８１４において、システム１００は、代替システムコンポーネントが、交換手順に対し互換性があるか否か判断する。たとえば、システム１００は、代替システムコンポーネントが、代替されるシステムコンポーネントと同じであるか否か判断する。代替システムコンポーネントが同じである場合、システム１００は、代替システムコンポーネントは互換性があると判断する。いくつかの実施形態において、代替されるシステムコンポーネントと同じソフトウェア（たとえば、ドライバ）、配置、および／またはシステム要求を有する場合、システム１００は、さらに、代替システムコンポーネントは互換性があると判断する。

工程８２０において、代替システムコンポーネントが、互換性がある場合、システム１００は、代替操作をレジュームするとともに、ＯＳが代替を完了できるようにする。

または、代替システムコンポーネントが、互換性がなく、且つ、工程８０４において、再起動状態がＳ３であり、且つ、エラーの原因が周辺装置である場合、工程８１６において、システム１００はＳ３レジューム工程を拒絶する。一方、代替システムコンポーネントが、互換性がなく、且つ、工程８０４において、再起動状態はＳ４であり、エラーの原因は、プロセッサ、メモリ、または、電源である場合、工程８１８において、システム１００は、ＤＣ電源をオフにするとともに、レジュームＳ４工程を拒絶する。

図９は、ソフトウェア復元可能性を決定する方法９００のフローチャートである。工程９０２において、システム１００は、ＲＡＳ（信頼性、利用可能性、および、支援性）ＳＭＩ（システムマネジメントモード）処理ルーティンを作動させる。ＳＭＩは、ＵＥＦＩ ＢＩＯＳにより初期化されて、任意の種類のサーバハードウェアエラーの発生を扱い、情報を収集、および／または、ＯＳ、および／または、コントローラ（たとえば、ＢＭＣ）の事象として記録する。工程９０４において、その後、システム１００はエラーの原因を識別する。

工程９０６において、システム１００はマシンチェックステータスを実行する。たとえば、システム１００は、ＩＡ３２_Ｍｃｉ_Ｓｔａｔｕｓを検査する。マシンチェックステータスが無効である場合、工程９０８において、システム１００は、その他のエラーをチェックする。工程９１８において、システム１００は、その後、任意のエラーを報告するシステムイベントログを送信する。システム１００は、システムイベントログを、コントローラ１１０、および／または、ＡＣＰＩ ＨＥＳＴ（ハードウェアエラーソース表）に送信する。

工程９０６において、マシンチェックステータスが有効である場合、工程９１０において、システム１００は通知を生成する。通知は、エラーを識別、および、修正を要求することができる。たとえば、通知は、一エラーが発生したこと、および、ソフトウェア補正動作が必要であることを示す。

工程９１２において、システムは、障害回復工程に対応する新しいシステムイベントログフォーマットを生成する。工程９１４において、システム１００は、障害回復が、ファームウェア（たとえば、ファームウェア１３４）により実行されるか判断する。

障害回復が、ファームウェアにより実行されない場合、システム１００は工程９１８に進み、システムイベントログを送信する。一方、障害回復が、ファームウェアにより実行される場合、工程９１６において、システム１００は、ファームウェア障害回復（たとえば、ＵＥＦＩリカバリー）を実行する。工程９１８において、システム１００は、その後、たとえば、コントローラ１１０、および／または、ＡＣＰＩ ＨＥＳＴにより、システムイベントログを送信する。

説明を明確にするため、いくつかの実施形態において、本発明の技術は、独立した機能ブロックを有するものとして表示され、機能ブロックは、ソフトウェア、または、ハードウェアとソフトウェアの組み合わせで具体化される方法中の装置、装置部品、工程、または、ルーティンを有する。

いくつかの実施形態において、コンピュータ可読ストレージデバイス、媒体、および、メモリは、ビットストリーム等を含むケーブル、または、無線信号を有する。しかし、言及されるとき、持続性コンピュータ読み取り可能ストレージ媒体は、明確に、媒体、例えば、エネルギー、キャリア信号、電磁波、および、信号自身を除外する。

上述の例における方法は、コンピュータ読み取り可能媒体に保存された、または、その他の方式で、コンピュータ読み取り可能媒体から得られるコンピュータ実行可能命令を用いて実現される。このような指令は、たとえば、汎用目的コンピュータ、特殊用途コンピュータ、または、特殊用途処理装置に、ある機能、または、機能の群を実行させる、または、その他の方式で、汎用目的コンピュータ、特殊用途コンピュータ、または、特殊用途処理装置を配置して、ある機能、または、機能の群を実行する指令、および、データを有する。用いられるコンピュータリソースの一部はネットワークによりアクセス可能である。コンピュータ実行可能命令は、たとえば、バイナリー、中間形式命令、たとえば、アセンブリ言語、ファームウェア、または、ソースコードである。コンピュータ読み取り可能媒体の例は、指令、使用される情報、および／または、記述される例にしたがって、方法の期間中に生成される情報を保存するのに用いられ、コンピュータ読み取り可能媒体は、磁気、または、光学ディスク、フラッシュメモリ、不揮発性メモリを有するＵＳＢ装置、ネットワークストレージデバイス等を有する。

これらの開示における方法を実施する装置は、ハードウェア、ファームウェア、および／または、ソフトウェアを有し、任意の各種フォームファクタを利用する。このようなフォームファクタの一般的な例は、ラップトップ、スマートフォン、スモールフォームファクタパーソナルコンピュータ、ＰＤＡ、ラックマウント型装置、スタンドアロン装置等を有する。ここで記述される機能性は、さらに、周辺装置、または、アドインカードで具体化される。さらなる例として、このような機能性は、単一装置で実行される異なるチップ、または、異なるプロセス間において、回路基板上で実行されてもよい。

このような指令を伝達する指令、媒体、それらを実行するコンピューティングリソース、および、このようなコンピューティングリソースをサポートするその他の構造は、ここで記述される機能を提供する手段である。

各種例およびその他の情報が用いられて、請求項範囲内の態様を説明しているが、請求項範囲は、このような例中の特定の特徴や配置に限定されず、当業者はこれらの例を利用して、多種多様の実施方案を導き出すことができる。さらに、ある主題は、構造上の特徴、および／または、方法工程の実施形態に対し記述しているが、請求項で定義される主題は、必ずしも、これらの記述される特徴や動作に制限されないことが理解できる。たとえば、このような機能性は、異なる装置に配置される、または、本発明で開示される装置と異なるその他の装置上で実行される。記述される特徴や工程は、請求項のシステム、および、方法の装置の例として明らかにされる。

請求項で示される一組中の"少なくとも一つ"の範囲は、その組中の一個の装置、または、その組中の複数の装置を含む。有形のコンピュータ読み取り可能ストレージ媒体、コンピュータ可読ストレージデバイス、または、コンピュータ可読メモリデバイスは、明確に、ある媒体、たとえば一時波（ｔｒａｎｓｉｔｏｒｙ ｗａｖｅｓ）、エネルギー、キャリア信号、電磁波、および、信号自身を除外する。

本発明では好ましい実施形態を前述の通り開示したが、これらは決して本発明に限定するものではなく、当該技術を熟知する者なら誰でも、本発明の精神と領域を脱しない範囲内で各種の変動や潤色を加えることができ、従って本発明の保護範囲は、特許請求の範囲で指定した内容を基準とする。

１００… システム
１０２… バス
１０４… メモリ
１０６… 読み取り専用メモリ
１０８… ランダムアクセスメモリ
１１０… コントローラ
１１２… ストレージデバイス
１１４… 第１モジュール
１１６… 第２モジュール
１１８… 第３モジュール
１２０… 入力装置
１２２… 出力装置
１２４… 通信インターフェース
１２６… センサー
１２８… キャッシュ
１３０… プロセッサ
１３２… フラッシュメモリ
１３４… ファームウェア
１３６… ディスプレイ
１５０… コンピュータシステム
１５２… チップセット
１５４… ブリッジ
１５６… ユーザーインターフェース装置
１５８… 通信インターフェース
１６０… プロセッサ
１６２… ファームウェア
１６４… 出力装置
１６６… ストレージデバイス
１６８… ランダムアクセスメモリ
１７０… 仮想環境
１７２… 仮想マシンマネージャー（ＶＭＭ）
１７４… バーチャルマシン
１７６… ホスト
１７８… リソースプール
１８０… データセンター
２００… システム
２０２… ハードディスクデバイス
２０４… 周辺装置
２０６… メモリ
２０８… プロセッサ
２１０… 電源ユニット
２１２… スリープ状態Ｓ４
２１４… スリープ状態Ｓ３
２１６… スリープモード転換
２１８… ウェイクアップ転換
２２０… 作業状態Ｓ０
３００… スリープ状態表
３０２… 故障記述
３０４… 障害回復スリープ状態
３０６… 遅延レジューム
３０８… プロセッサ
３１０… メモリ
３１２… 電源
３１４… 周辺装置
３１６… ストレージデバイス
３１８… ファン
３２０… スリープ状態Ｓ４
３２２… スリープ状態Ｓ３
３２４… スリープ状態Ｓ１
３２６… スリープ状態Ｓ４の遅延
３２８… スリープ状態Ｓ３の遅延
３３０… スリープ状態Ｓ１の遅延
４００… 通信
４０２… 作業システム
４０４… ハードウェアコンポーネント
４１０… ハードウェアの状態の監視
４１２… ＲＡＳ特徴
４１４… エラー報告
４１６… エラー報告
４１８… エラー報告
４２０… スリープ状態要求
４２２… ウェイクアップ要求
４２４… ＡＣ電源段階
４２６… ＤＣ電源段階
４２８… パワーオンセルフテスト（ＰＯＳＴ）
４３０… スタンバイ
４３２… レジューム
４３４… ハードウェアインターフェース
４３６… ＲＥＳＴｆｕｌ、ＩＰＭＩ
４３８… ＲＥＳＴｆｕｌ ＡＰＩ
５００… 故障修復表
５０２… 特徴カラム
５０４… 記述カラム
５０６… 優先格付けカラム
５０８… 故障検出
５１０… 緩和計画（例えば、運転時間の延長）
５１２… 回復特徴
５１４… ＯＳからエラー通知を得る、故障の重大性、位置と数量を識別する工程
５１６… 故障のリソースをリソースプールから隔離する、新しいリソースをＶＭに再度割り当てるとともに、ＶＭを閉鎖して、異なるサーバに転換する工程
５１８… ＶＭデータをバックアップして、データ損失を防止し、サーバ、または、システムの調子が良くなった後（たとえば、障害回復後）、ＶＭデータを修復する工程
５２０… 高優先度
５２２… 任意優先度
６０２〜６１２、７０２〜７２０、８０２〜８２０、９０２〜９１８… 工程

Claims (10)

1. 方法であって、
   システムに関連するハードウェアエラーを検出する工程と、
   前記ハードウェアエラーに関連するシステムコンポーネントを識別する工程と、
   前記システムの操作システムをトリガーして、前記システムを特定のスリープ状態に置くように、基板管理コントローラによりスリープ状態要求を生成する工程であって、前記システムコンポーネントに関連するコンポーネントのタイプに基づいて、前記特定のスリープ状態が決定され、前記特定のスリープ状態は、前記コンポーネントのタイプが周辺装置であるとき、第一スリープ状態であり、前記コンポーネントのタイプが、プロセッサ、メモリ、または、電源ユニットの一つであるとき、第二スリープ状態である工程と、
   前記システムが前記特定のスリープ状態になった後、前記システムの前記操作システムを再起動せずに、前記システムコンポーネントを代替する指示であって、前記システムが、前記システムコンポーネントに関連する前記コンポーネントのタイプに対応する前記特定のスリープ状態である決定に基づいて生成される指示を生成する工程と、
   を有することを特徴とする方法。
2. さらに、
   前記ハードウェアエラーの重大性、前記ハードウェアエラーの誤り件数、および、前記ハードウェアエラーの位置の少なくとも一つを判断する工程であって、前記重大性が、前記ハードウェアエラーが修復できない、または、前記誤り件数がスレショルドを超えることを示すとき、前記スリープ状態要求が生成され、前記特定のスリープ状態が、前記ハードウェアエラーの前記位置に基づく工程と、
   前記システムコンポーネントに関連するハードウェア情報を収集して、前記システムコンポーネントのハードウェア配置を判断する工程と、
   前記システムコンポーネントの前記ハードウェア配置が、代替システムコンポーネントの対応するハードウェア配置と符合するか判断する工程と、
   前記システムの前記操作システムを再起動しない、前記システムで作動する前記システムコンポーネントと関連するアプリケーションを再配置しない、または、前記システムコンポーネントに関連する前記システム内のハードウェア設定を再設定せずに、前記システムコンポーネントを、代替システムコンポーネントで代替する工程と、
   サービス割り込みによって、前記システムコンポーネントにより送信されるエラー報告に基づいて、システムファームウェアコンポーネント上の前記基板管理コントローラにより、前記ハードウェアエラーの通知を受信する工程と、を有し、
   前記システムコンポーネントは、周辺装置、第二プロセッサ、第二メモリ、または、第二電源ユニットの少なくとも一つを有し、前記周辺装置は、ストレージコンポーネント、周辺装置相互接続コンポーネント、ＰＣＩエクスプレスコンポーネント、および、ファンの一つを有し、前記第二スリープ状態は、前記第一スリープ状態より低い電源リソース消耗、および、前記第一スリープ状態より長いレジューム遅延を生じ、
   前記システムはホットプラグ設計に基づかず、前記システムにホットアドコンポーネントまたはホットリムーブコンポーネントを使用せずに、前記システムコンポーネントの代替を実行する、
   ことを特徴とする請求項１に記載の方法。
3. さらに、
   前記システムコンポーネントが部品交換で代替された後、前記部品交換が、互換性がある代替であるか否か判断する工程であって、前記互換性がある代替であるか否かを、前記システムコンポーネントと同じタイプか否か、前記システムコンポーネントと同じハードウェア配置であるか否か、前記システムコンポーネントと同じファームウェアまたはソフトウェアドライバ互換性であるか否か、および前記システムコンポーネントと同じリソース要求であるか否かを判断することによって判断する工程を有することを特徴とする請求項１に記載の方法。
4. さらに、
   前記システムコンポーネントが、代替システムコンポーネントで代替されたことを検出する工程と、
   前記代替システムコンポーネントが、互換性があるか否か判断する工程と、を有し、前記判断する工程は、
   ハードウェアコンポーネント情報を分析する工程と、
   前記代替システムコンポーネントが、前記システムコンポーネントと同じコンポーネントであるか判断する工程であって、前記システムコンポーネントと同じコンポーネントである場合、前記代替システムコンポーネントは互換性があり、前記システムコンポーネントと同じコンポーネントではない場合、前記システムコンポーネントは互換性がない工程とによって判断し、
   前記代替システムコンポーネントが、互換性があるとき、前記代替システムコンポーネントで、前記システムコンポーネントを代替することを可能にし、
   前記代替システムコンポーネントが、互換性がないとき、前記代替システムコンポーネントで、前記システムコンポーネントを代替することを拒絶することを特徴とする請求項１に記載の方法。
5. 前記システムは仮想マシンマネージャーを有し、
   前記方法は、さらに、
   前記ハードウェアエラーが、前記仮想マシンマネージャーに関連する一つ以上のバーチャルマシンにより用いられるリソースに影響するか判断する工程と、
   前記仮想マシンマネージャーに関連するリソースのプールから、前記リソースを隔離する工程と、
   新しいリソースを、前記一つ以上のバーチャルマシンに再度割り当てる工程と、を有することを特徴とする請求項１に記載の方法。
6. システムであって、
   プロセッサ、および、
   指令をその中に保存したコンピュータ可読ストレージ媒体を有し、
   前記指令が前記プロセッサにより実施されるとき、前記プロセッサが実行する操作は、
   前記システムに関連するハードウェアエラーを検出する工程と、
   前記ハードウェアエラーに関連するシステムコンポーネントを識別する工程と、
   前記システムの操作システムをトリガーして、前記システムを特定のスリープ状態に置くように、スリープ状態要求を生成する工程であって、前記システムコンポーネントに関連するコンポーネントのタイプに基づいて、前記特定のスリープ状態が決定され、前記特定のスリープ状態は、前記コンポーネントのタイプが周辺装置であるとき、第一スリープ状態であり、前記コンポーネントのタイプがプロセッサ、メモリ、または、電源ユニットの一つであるとき、第二スリープ状態である工程と、
   前記システムが前記特定のスリープ状態に置かれた後、前記システムの前記操作システムを再起動せずに、前記システムコンポーネントを代替する指示であって、前記システムが、前記システムコンポーネントに関連する前記コンポーネントのタイプに対応する前記特定のスリープ状態である決定に基づいて生成される指示を生成する工程と、
   を有することを特徴とするシステム。
7. 前記操作は、さらに、
   前記ハードウェアエラーの重大性、前記ハードウェアエラーの誤り件数、および、前記ハードウェアエラーの位置の少なくとも一つを判断する工程であって、前記重大性が、前記ハードウェアエラーが修復できない、または、前記誤り件数がスレショルドを超えることを示すとき、前記スリープ状態要求が生成され、前記特定のスリープ状態は、前記ハードウェアエラーの前記位置に基づく工程と、
   前記システムコンポーネントに関連するハードウェア情報を収集して、前記システムコンポーネントのハードウェア配置を判断する工程と、
   前記システムコンポーネントの前記ハードウェア配置が、代替システムコンポーネントの対応するハードウェア配置に符合するか判断する工程と、
   前記システムコンポーネントが部品交換で代替された後、前記部品交換が、前記システムコンポーネントにとって互換性がある代替か否か判断するとともに、前記部品交換が互換性がある代替であると判断されるとき、前記システムコンポーネントが前記部品交換で代替されるようにする工程であって、前記互換性がある代替であるか否かを、前記システムコンポーネントと同じタイプのシステムコンポーネントであるか否か、前記システムコンポーネントと同じハードウェア配置であるか否か、前記システムコンポーネントと同じファームウェアまたはソフトウェアドライバ互換性であるか否か、前記システムコンポーネントと同じリソース要求であるか否かを判断することによって判断する工程と、を有し、
   前記第二スリープ状態は、前記第一スリープ状態より低い電力リソース消耗、および、前記第一スリープ状態より長いレジューム遅延を生じることを特徴とする請求項６に記載のシステム。
8. 前記操作は、さらに、
   前記システムコンポーネントが、代替システムコンポーネントで代替されたか否か検出する工程と、
   前記代替システムコンポーネントが、互換性があるか否か判断する工程と、を有し、前記判断する工程は、
   ハードウェアコンポーネント情報を分析する工程と、
   前記代替システムコンポーネントが、前記システムコンポーネントと同じコンポーネントであるか否か判断する工程であって、前記システムコンポーネントと同じコンポーネントである場合、前記代替システムコンポーネントは互換性があり、前記システムコンポーネントと同じコンポーネントではない場合、前記システムコンポーネントは互換性がない工程とによって判断し、
   前記代替システムコンポーネントが、互換性があるとき、前記代替システムコンポーネントで、前記システムコンポーネントを代替することを可能にし、
   前記代替システムコンポーネントが、互換性がないとき、前記代替システムコンポーネントで、前記システムコンポーネントを代替することを拒絶することを特徴とする請求項６に記載のシステム。
9. 指令をその中に保存したコンピュータ可読ストレージデバイスであって、
   前記指令がプロセッサにより実行されるとき、前記プロセッサが実行する操作は、
   システムに関連するハードウェアエラーを検出する工程と、
   前記ハードウェアエラーに関連するシステムコンポーネントを識別する工程と、
   前記システムの操作システムをトリガーして、前記システムを特定のスリープ状態に置くように、スリープ状態要求を生成する工程であって、前記システムコンポーネントに関連するコンポーネントのタイプに基づいて、前記特定のスリープ状態が決定され、前記特定のスリープ状態は、前記コンポーネントのタイプが周辺装置であるとき、第一スリープ状態であり、前記コンポーネントのタイプが、プロセッサ、メモリ、または、電源ユニットの一つであるとき、第二スリープ状態である工程と、
   前記システムが、前記特定のスリープ状態になった後、前記システムの前記操作システムを再起動せずに、前記システムコンポーネントを代替する指示であって、前記システムが、前記システムコンポーネントに関連する前記コンポーネントのタイプに対応する前記特定のスリープ状態である決定に基づいて生成される指示を生成する工程と、
   を有し、
   前記第二スリープ状態が、前記第一スリープ状態より低い電源リソース消耗、および、前記第一スリープ状態より長いレジューム遅延を生じることを特徴とするコンピュータ可読ストレージデバイス。
10. 前記操作は、さらに、
    前記ハードウェアエラーの重大性、前記ハードウェアエラーの誤り件数、および、前記ハードウェアエラーの位置の少なくとも一つを判断する工程であって、前記重大性が、前記ハードウェアエラーが修復できない、または、前記誤り件数がスレショルドを超えることを示すとき、前記スリープ状態要求が生成され、前記特定のスリープ状態が、前記ハードウェアエラーの前記位置に基づく工程と、
    前記システムコンポーネントに関連するハードウェア情報を収集して、前記システムコンポーネントのハードウェア配置を判断する工程と、
    前記システムコンポーネントの前記ハードウェア配置が、代替システムコンポーネントの対応するハードウェア配置と符合するか否か判断する工程と、を有し、
    前記システムコンポーネントは、周辺装置、第二プロセッサ、第二メモリ、または、第二電源ユニットの少なくとも一つを有し、前記周辺装置は、ストレージコンポーネント、周辺装置相互接続コンポーネント、ＰＣＩエクスプレスコンポーネント、および、ファンの一つを有することを特徴とする請求項９のコンピュータ可読ストレージデバイス。

Images