JP2020027615A - サーバハードウェア障害の分析及びリカバリ - Google Patents

Abstract

【課題】データセンタシステムで発生する障害イベントを自動的に管理する方法及びシステムを提供する。【解決手段】方法は、ハードウェア障害イベントに対応するハードウェア障害イベント分析を収集する工程を含む。ハードウェア障害イベント分析は、ハードウェア障害イベントを被るサーバデバイスのレポートとして構成されている。また、方法は、サーバデバイスのレポートから受信した統計データを処理する工程を含む。さらに、方法は、評価された統計データに基づいてハードウェアリカバリを実行する工程を含む。【選択図】図３

Description

本発明は、概して、データセンタで発生する障害イベントを管理するための自動管理システム及び方法に関する。

情報ベースの経済の需要の増大に応じて、データセンタ及び情報技術ネットワークが世界中で急増し続けている。この展開は、地理的に異なるコンピューティングリソースを互いにリンクさせる広範囲に分散したコンピュータネットワークや、電力、冷却及びコンピューティングインフラストラクチャを様々なアプリケーションに提供するデータセンタ等のように様々な形態で行われてきた。

一般的なデータセンタは、電力、冷却及び外部通信設備への接続を必要とする複数の機器ラックを有する。現代のデータセンタやネットワークルームでは、これらの設備で用いられるコンピューティング装置の密度の増加により、これらに関連する電力システムに負担がかかる。このコンピューティング装置は動作中に熱を発生するので、これらの設備の冷却システムにも負担がかかる。

よって、効率的なデータセンタ操作及び管理ツールが必要とされている。データセンターを管理するための従来の方法の殆どは、以前の操作記録に依存している。一般的なデータセンタ操作及び管理ツールでは、データセンタの障害は、手動で管理されている。この場合、障害イベントの発生を予測することが困難である。また、以前に発生したことのない新たなタイプの障害イベントに対して予防的な対策及び予測を行うことも困難である。

以下は、本発明の技術の基本的な理解を提供するための１つ以上の実施形態の簡単な概要である。この概要は、本技術の全ての企図された実施形態の広範な概要ではない。全ての例のキー又は重要な要素を特定することも、本発明の技術の何れか又は全ての態様の範囲を表現することも意図していない。この唯一の目的は、以下のより詳細な説明の前置きとして、１つ以上の例のいくつかの概念を簡略化された形式で提示することである。

データセンタシステムで発生する障害イベントを自動的に管理する方法及びシステムを提供する。本方法は、ハードウェア障害イベントに対応するハードウェア障害イベント分析を収集する工程を含む。ハードウェア障害イベント分析は、ハードウェア障害イベントを被るサーバデバイスのレポートとして構成されている。また、本方法は、サーバデバイスのレポートから受信した統計データを処理する工程を含む。さらに、本方法は、評価された統計データに基づいてハードウェアリカバリを実行する工程を含む。

本発明のいくつかの実施形態では、ハードウェア障害イベント分析を収集する工程は、ハードウェア障害イベント検出システムをサーバデバイスのベースボード管理コントローラ（ＢＭＣ）ファームウェア内に記憶する工程を含む。また、本方法は、ハードウェア障害イベントの原因を識別する工程と、ハードウェア障害イベントが修復可能又は修復不可能なエラーの何れの結果であるかを判別する工程と、を含むことができる。本発明のいくつかの実施形態では、ハードウェア障害イベントの原因は、ＢＩＯＳサービスルーチンによって決定される。さらに、本方法は、ハードウェア障害イベントを識別する工程を含むことができる。いくつかの実施形態では、ハードウェア障害イベントを識別する工程は、障害位置、障害カテゴリ、障害タイプ、及び／又は、障害重大度（fault severity）のうち少なくとも１つを識別する工程を含むことができる。さらにまた、本方法は、ハードウェア障害イベントの識別の通知をＢＭＣから受信する工程を含むことができる。本発明のいくつかの実施形態では、レポートは、ハードウェア障害イベントレポートと、デバイスレポートと、を含む。本発明のいくつかの実施形態では、レポート内のデータオブジェクトを表現するために、人間が読めるテキストを使用する言語非依存のオープンデータフォーマットを受信することができる。また、本方法は、レポートの分析コンポーネントにおいて、データの中心傾向分析（central tendency analysis）を実行する工程を含むことができる。

いくつかの実施形態では、中心傾向分析は、ハードウェア障害イベントに関連するオペレーティングシステム及びソフトウェアサービスのリスクを分析する工程と、サーバデバイスの保護の方向性を分析する工程と、ハードウェア障害イベントの傾向及びハードウェア障害イベントの影響を予測する工程と、を含む。いくつかの実施形態では、本方法は、ハードウェア障害イベントを測定する工程と、予測性分析プロセスによってリスク評価を生成して、ハードウェア障害イベントの診断証明（certificate of diagnosis）を生成する工程と、をさらに含むことができる。本発明のいくつかの実施形態では、ハードウェアリカバリを実行する工程は、サーバデバイスのリカバリポリシーを検査する工程を含むことができる。また、本方法は、リカバリメカニズムをスケジューリングする工程を含むことができる。いくつかの実施形態では、リカバリメカニズムは、リカバリポリシーに基づいて、即時修復又は遅延修復の何れかにスケジュールされる。さらに、本方法は、サーバデバイスの性能欠陥についてハードウェア障害イベントを監視する工程を含む。

データセンタシステムで発生するハードウェア障害イベントを自動的に管理するシステムも提供される。本システムは、ラックサーバを含み、各ラックサーバは、サーバデバイスを含む。また、システムは、サーバデバイスに接続されたデータセンタ管理システムを含む。データセンタ管理システムは、ハードウェア障害イベントに対応するハードウェア障害イベント分析を収集するように構成されている。ハードウェア障害イベント分析は、ハードウェア障害イベントを被るサーバデバイスのレポートとして構成されている。また、データセンタ管理システムは、サーバデバイスのレポートから受信した統計データを処理し、評価された統計データに基づいてハードウェアリカバリを実行するように構成されている。

本開示のさらなる特徴及び利点は、以下の説明に記載され及びその説明から部分的に明らかになり、又は、本明細書に開示された原理の実施によって理解することができる。本開示の特徴及び利点は、添付の特許請求の範囲において特に指摘された機器や組み合わせによって実現し、得ることができる。本開示のこれら及び他の特徴は、以下の説明及び添付の特許請求の範囲から十分に明らかになり、又は、本明細書に記載された原理の実施によって理解することができる。

本発明によれば、新たなタイプの障害イベントに対して予防的な対策及び予測が可能になる。

上記の開示内容と、その利点及び特徴と、を得ることができる方法を説明するために、添付の図面に示された特定の例を参照することによって、上記の原理のより詳細な説明が与えられるであろう。これらの図面は、本開示の例示的な態様のみを示すものであり、よって、本発明の範囲を限定するものとみなされるべきではない。以下の図面を用いることにより、これらの原理が、さらなる詳細と共に記載及び説明される。

従来のデータセンタシステム１００を示す図である。 本発明の一実施形態による、例示的なデータセンタシステム２００を示す図である。 本発明の一実施形態による、データセンタシステム２００で発生する障害イベントを自動的に管理するプロセス３００のフローチャートである。 本発明の一実施形態による、ハードウェア障害イベント分析を収集するプロセス４００のフローチャートである。 本発明の一実施形態による、統計データを処理及び評価するプロセス５００のフローチャートである。 本発明の一実施形態による、統計データを処理及び評価するプロセス５００のフローチャートである。 本発明の一実施形態による、ハードウェアリカバリのプロセス６００のフローチャートである。

添付の図面を参照しながら本発明を説明する。図面全体を通して、類似又は同等の要素を示すために同様の符号が用いられている。図面は、一定の縮尺で描かれておらず、単に本発明を説明するために提供されている。本発明のいくつかの態様は、例示的な用途を参照して以下に説明される。本発明の十分な理解を提供するために、多くの特定の詳細、関係及び方法が説明されていることを理解されたい。しかしながら、当業者であれば、本発明が１つ以上の具体的な詳細無しに又は他の方法を用いて実施可能であることを容易に認識するであろう。他の例では、本発明を曖昧にすることを避けるために、周知の構造又は動作を詳細に示していない。いくつかの工程は、異なる順序で及び／又は他の工程若しくはイベントと同時に起こり得るので、本発明は、例示された工程又はイベントの順序によって限定されない。さらに、本発明による方法を実施するために、例示された全ての工程又はイベントが必要とされているわけではない。

上述したように、一般的なデータセンタの操作及び管理ツールでは、データセンタの障害が手動で管理されている。この場合、障害イベントの発生を予測することが困難である。さらに、これまでに発生したことのない新たなタイプの障害イベントについて予防的な対策及び予測を行うことも困難である。本発明は、データセンタで発生する障害イベントを自動的に管理するシステム及び対応する方法を提供する。本発明のシステム及び方法は、サーバハードウェア障害分析を実行し、リカバリメカニズムを提供することができる。リカバリメカニズムは、サーバのダウンタイムを減らし、ソフトウェアが、ハードウェア障害イベントの影響を受けるのを軽減し、交換が不要となるように構成されている。また、リカバリメカニズムは、製造者による修復やリカバリを必要とせずに、サーバハードウェアの障害イベントの根本的な原因の診断をスケジュールすることができる。

図１は、従来のデータセンタシステム１００を示す図である。データセンタシステム１００は、数千のラックサーバ１０２を含むことができる。また、データセンタシステム１００は、ラックサーバ１０２から受信したエラーを監視するオンサイト管理者１０４を含むことができる。特に、管理者１０４は、データセンタ管理システム１１３のユーザインタフェースを介して、ラックサーバ１０２に記憶されている複数の電子部品からエラーを受信することができる。電子部品は、サーバデバイスを含むことができる。例示的なサーバデバイス１１０が本明細書で示されている。サーバデバイス１１０に関連するエラーは、ストレージエラー１１、ＣＰＵエラー１３、メモリエラー１４、電源エラー１２、又は、入力／出力エラー１５を含むことができる。これらのエラーは例示を目的としたものであり、網羅的なエラーのリストにすることを意図していない。場合によっては、ラックサーバ１０２から管理者１０４への連続的な報告（レポート）において数千ものハードウェアエラーが生成される可能性がある。

データセンタシステム１００は、リモート位置に存在する顧客１０８を含むことができる。顧客１０８は、ネットワーク１０６を介してラックサーバ１０２にアクセスすることができる。ネットワーク１０６は、顧客１０８をラックサーバ１０２に接続するように構成されたＬＡＮ（local area network）又はＷＡＮ（wide-area network）とすることができる。多くの場合、欠陥のあるハードウェア（例えば、サーバデバイス１１０）は、ラックサーバ１０２のパフォーマンスに直接影響を及ぼし得る。その結果、顧客１０８が体験するラックサーバ１０２のパフォーマンスが、直接影響を受ける。その結果、管理者１０４は、ラックサーバ１０２内のハードウェア障害イベントを可能な限り早く解決する任務を負う。管理者１０４がサービスできない、又は、サーバデバイス１１０のハードウェア障害イベントを修復できない場合、サーバデバイス１１０は、製造者１１２に送られて修理又は交換される。この目的のために、製造者１１２は、ラックサーバ１０２及び管理者１０４から離れている。製造者１１２によるサーバデバイス１１０上のサービスは、通常、数日、数週間又は数か月を要する場合がある。よって、ハードウェア障害イベントを解決するために単に管理者を採用するという従来のアプローチは、理想的な解決手段ではない。

通常、データセンタ管理システム１１３は、検証段階中に９８％のハードウェア障害イベントを検出し、ハードウェア及びファームウェア設計を改善することによって障害を排除することができる。残りの１％のハードウェア障害イベントは、ハードウェアの経年劣化の結果である。よって、このタイプのハードウェア障害イベントは、通常、予測不能であり、検出が困難である。ハードウェア障害イベントは、データセンタ管理システム１１３の安定した信頼性、可用性及び実用性（ＲＡＳ）機能を介して検出及び報告可能である。データセンタ管理システム１１３の信頼性機能は、ハードウェア障害イベントを回避、検出及びリカバリすることができる。データセンタ管理システム１１３の可用性機能は、ハードウェア障害イベントを軽減し、関連するソフトウェアのダウンタイムを短縮するように構成されている。データセンタ管理システム１１３の実用性機能は、問題が発生した場合にシステムを診断するように構成されている。

サーバの残り１％のハードウェア障害イベントはそれほど予測可能ではない。実際、これらのハードウェア障害イベントは、通常、新しく、未発見である。その結果、ハードウェア設計者は、ハードウェア障害イベントを考慮してシミュレーションを実行していない。これらの予期できないハードウェア障害イベントは、サーバデバイス１１０をクラッシュさせ、又は、関連するオペレーティングシステムのインテグリティを損なう可能性がある。結局、ハードウェア障害イベントは、かなりのダウンタイムを必要とし、トラブルシューティング分析リカバリを実行する方法が存在しない場合には、顧客１０８に深刻な影響を及ぼす可能性がある。

図２は、例示的なデータセンタシステム２００を示す図である。データセンタシステム２００は、有用な報告（レポート）を管理者に提供し、データセンタにおける障害及び実現可能なリカバリメカニズムを予測することができる。これにより、管理者は、サーバに関連する問題を軽減し、サーバダウンタイムを短縮し、サーバのサービスを維持することができる。データセンタシステム２００は、数千のラックサーバ２０２を含むことができる。また、データセンタシステム２００は、ラックサーバ２０２から受信したエラーを監視するオンサイト管理者２０４を含むことができる。特に、管理者２０４は、データセンタ管理システム２１３のユーザインタフェースを介して、ラックサーバ２０２に記憶されたいくつかの電子部品からエラーを受信することができる。電子コンポーネントは、サーバデバイスを含むことができる。例示的なサーバデバイス２１０が本明細書に示されている。サーバデバイス２１０は、計算サーバ、ストレージサーバ又はネットワークスイッチサーバを含むことができる。サーバデバイス２１０のハードウェア障害イベントに関連するエラーは、ストレージエラー２１、ＣＰＵエラー２３、メモリエラー２４、電源エラー２２、又は、入力／出力エラー２５を含むことができる。これらのエラーは例示を目的としたものであり、網羅的なエラーのリストにすることを意図していない。場合によっては、ラックサーバ２０２から管理者への連続的な報告（レポート）において数千ものハードウェアエラーが生成される可能性がある。

また、データセンタシステム２００は、リモート位置に存在する顧客２０８を含むことができる。顧客２０８は、ネットワーク２０６を介してラックサーバ２０２にアクセスすることができる。ネットワーク２０６は、顧客２０８をラックサーバ２０２に接続するように構成されたＬＡＮ（local area network）又はＷＡＮ（wide-area network）とすることができる。管理者２０４がサービスできない、又は、サーバデバイス２１０のハードウェア障害イベントを修復できない場合、ＩＴエンジニア２１２は、サーバデバイス２１０にサービスすることができる。

図３は、データセンタシステム２００で発生した障害イベントを自動的に管理するプロセス３００のフローチャートである。プロセス３００の以下の説明は、図２のデータセンタシステム２００のコンポーネントを参照して詳細に述べられる。プロセス３００は、工程３０１で開始し、データセンタ管理システム２１３がハードウェア障害イベント分析を収集する。これは、図４を参照して詳細に説明する。工程３０２において、データセンタ管理システム２１３は、ハードウェア障害イベント分析に関連する統計データを処理し、評価する。これは、図５Ａ及び図５Ｂを参照して詳細に説明する。最後に、工程３０３において、データセンタ管理システム２１３は、ハードウェアリカバリを実行する。これは、図６を参照して詳細に説明する。

図４は、ハードウェア障害イベント分析を収集するプロセス４００のフローチャートである。プロセス４００の以下の説明は、図２のデータセンタシステム２００のコンポーネントを参照して詳細に述べられる。プロセス４００は、工程４０１で開始し、ハードウェア障害イベント検出システムが、ベースボード管理コントローラ（ＢＭＣ）ファームウェアに記憶される。ラックサーバ２０２内の各サーバデバイス（例えば、サーバデバイス２１０）は、ＢＭＣファームウェアをインストールすることができる。ＢＭＣファームウェアは、データセンタ管理システム２１３と接続するように構成されてもよい。別の実施形態では、ハードウェア障害イベント検出システムは、ユニファイドエクステンシブルファームウェアインタフェース（ＵＥＦＩ）、ベーシックインプット／アウトプットシステム（ＢＩＯＳ）、ラックマネージャ（ＲＭ）ソフトウェア、又は、データセンタ管理システム２１３内にインストールされてもよい。

工程４０２において、ハードウェア障害イベントの原因が識別される。ハードウェア障害イベントは、修復可能又は修復不可能の何れかであるハードウェアエラーの結果とすることができる。ハードウェアの修復不可能なエラーは、ソフトウェアリカバリ可能エラー又は壊滅的なエラーの２つのカテゴリに分類することができる。ソフトウェアリカバリ可能エラーは、サーバデバイス２１０内の少なくともいくつかのデータが破損していることを示す。その結果、このデータをリカバリすることができない。しかし、このタイプのエラーが発生しても、オペレーティングシステムはまだ有効であり、システムをリセットしたり、進行中の別のプロセスを妨げることなく、ソフトウェアをリカバリすることができる。一方、壊滅的なエラーは、プロセッサがマイクロ命令を実行することができないことを示す。また、壊滅的エラーは、システムのリセットを必要とし、進行中の別のプロセスを妨げる。これらのエラーは、システムのリセットを必要とするが、修復可能なエラーに分類される。対照的に、修復可能なエラーは、ハードウェアメカニズム（例えば、巡回冗長検査（ＣＲＣ）等）によって修復可能なエラーデータを意味する。いくつかの実施形態では、修正可能なエラーは、システムリセットを必要としない。

いくつかの実施形態では、ハードウェア障害イベントは、ＢＩＯＳサービスルーチンによって認識され得る。いくつかの実施形態では、ＢＩＯＳサービスルーチンは、システム管理割り込み（ＳＭＩ）信号トリガを実行することができる。工程４０３において、ハードウェア障害イベントの識別を決定することができる。エラートリガは、ハードウェア信号（例えば、ＳＭＩ、ＳＣＩ、ＮＭＩ、ＳＭＢｕｓアラート又はＣＡＴＥＲＲ割り込み等）によって実行することができる。例えば、障害の位置、カテゴリ、障害のタイプ、重大度、識別を記録し、ＢＭＣの恒久的なストレージに転送することができる。いくつかの実施形態では、ハードウェア障害イベントの識別は、既存のインタフェース（例えば、システム管理バス（ＳＭＢｕｓ）、プラットフォーム環境制御インタフェース（ＰＥＣＩ）又はＪＴＡＧ（Joint Test Action Group）等）を介して決定することができる。これらのバス又はインタフェースの各々は、ハードウェアコンポーネントとＢＭＣとの間の通信メカニズムを提供する。工程４０４において、ＢＭＣは、ＵＥＦＩ、ＢＩＯＳ、ＲＭソフトウェア又はデータセンタ管理システム２１３に通知することができる。

図５Ａ及び図５Ｂは、統計データを処理及び評価するプロセス５００のフローチャートである。プロセス５００の以下の説明は、図２のデータセンタシステム２００のコンポーネントを参照して詳細に述べられる。ハードウェア障害イベントは、大量の様々なデータを含む場合がある。ハードウェア障害イベントに関連するデータを評価するために、データセンタ管理システム２１３は、複数の場所からデータを収集し、当該データを処理し、当該データに基づいてサーバデバイス２１０の処理及びリカバリ段階を開始するように構成されている。プロセス５００は、工程５０２で開始し、ハードウェア障害イベントデータ及びその関連データが収集される。ハードウェア障害イベントデータは、サーバ毎のレポート５５０として構成されてもよい。図５Ａ及び図５Ｂに示すように、計算サーバ、ストレージサーバ又はネットワークスイッチサーバ毎の個別のレポート５５０が存在する。サーバデバイス毎のレポート５５０は、ハードウェア障害イベントレポート５５１と、デバイスレポート５５２と、を含むことができる。デバイスレポート５５２は、サーバデバイス２１０に関するものであることから、様々なデータを含むことができる。例えば、デバイスレポート５５２は、サーバデバイス２１０のファームウェアバージョン５５５と、サーバデバイス２１０のプラットフォーム構成５５６と、サーバデバイス２１０のカスタム設定５５４と、サーバデバイス２１０の使用モデル５５３と、を含むことができる。当業者であれば、デバイスレポート５５２内のデータのリストが一例として提供されており、網羅的であることを意図していないことが理解できるであろう。

プロセスは、工程５０３において、デバイスレポート５５２からの関連情報が収集され、集積される。計算サーバ、ストレージサーバ又はネットワークスイッチサーバのレポート５５０の例は、表１を参照して以下のように示される。

表１に示すように、サーバデバイス２１０毎の特定の測定基準を提供することができる。表１において、サーバデバイス２１０は、計算サーバ、ストレージサーバ又はネットワークスイッチサーバを含むことができる。サーバデバイス２１０毎の例示的な測定基準は、データ収集（Data Collection）と、製品エラーフォーマット（Product Error Format）と、を含むことができる。これは、エラーのカテゴリー（Category）と、時間（Time）と、タイプ（Type）と、重大度（Severity）と、位置（Location）と、識別（Identity）と、を含むことができる。例えば、計算サーバのＣＰＵメモリにエラーが存在する場合がある。本明細書では、ＣＰＵメモリエラーの時間と、タイプと、重大度と、位置と、識別と、を提供することができる。各サーバデバイス２１０の他の測定基準は、ファームウェアバージョンと、構成と、カスタム設定と、使用情報と、を含むことができる。

サーバデバイス２１０は、ＢＭＣを有することができる。サーバデバイス２１０用のＢＭＣは、ハードウェア障害イベント及びそれに関連する生データの収集のためのストレージを提供することができる。サーバデバイス２１０のＢＭＣは、管理者２０４の便宜のために人間が読めるテキストを使用する、言語非依存のオープンデータフォーマットを送ることができる。

レポート５５０内の統計データは、サーバタイプ毎のデータの統計的評価を生成するために使用することができる。この統計的評価は、評価特徴５６１と、分析特徴５６２と、を含むことができる。工程５０４において、データセンタ管理システム２１３は、評価特徴５６１内のデータの統計的評価を呼び出すことができる。評価特徴５６１は、ハードウェア障害イベントに関連するエンティティ、ハードウェア障害イベントの重大度、層、及び、ハードウェア障害イベントに関連する関係データを含むことができる。また、評価特徴５６１は、ハードウェア障害分類を含むことができる。ハードウェア障害イベントは、冗長性、方向性、リカバリ可能性、又は、緊急性に分類することができる。最後に、評価特徴５６１は、ハードウェア障害イベントの量、ハードウェア障害イベントの重大度、ハードウェア障害イベントの位置、ハードウェア障害イベントのカテゴリ、プラットフォーム構成、カスタム設定、使用モデル、及び、ハードウェア障害イベントのタイプスタンプを含むことができる。当業者であれば、評価特徴５６１に対して多くの属性を提供することができ、本明細書に列挙された属性が例示を目的としており網羅的であることを意図していないことを理解できるであろう。

工程５０５において、データセンタ管理システム２１３は、分析特徴５６２内のデータの中心傾向分析を実行する。中心傾向分析は、修復不可能なエラー（致命的でない（non-fatal））に焦点を当てている。致命的ではない修復不可能なエラーは、ソフトウェアの再起動又はハードウェアの再トランザクションによってリカバリ可能であるが、サーバのパフォーマンスに影響を与える可能性がある。中心傾向分析は、修復不可能なエラーの位置を識別する工程と、接続されたデバイスの数を判別する工程と、を含む。また、中心傾向分析は、ハードウェアコンポーネントからのエラーレポートを識別し、トランザクションが代替のデバイスに再転送され得るかどうかを識別する工程を含む。この時点で、障害のあるハードウェアを交換するために構成された全ての冗長なコンポーネントをリストすることができる。ソフトウェアサービスを代替の仮想マシンに移行することができるか否かを決定する。エラー履歴、比率及び使用モデルが検査される。さらに、ハードウェア障害イベントのエラータイプ、ハードウェア障害イベントのリスト量、及び、このハードウェア障害イベントからの影響が決定される。データセンタ管理システム２１３は、オペレーティングシステム、及び、ハードウェア障害イベントに関連するソフトウェアサービスのリスクを分析することができる。また、データセンタ管理システム２１３は、サーバデバイス２１０の保護の方向性を分析することができる。さらに、データセンタ管理システム２１３は、障害イベントの傾向、及び、ハードウェア障害イベントの影響を予測することができる。データセンタ管理システム２１３は、統計的なハードウェア障害イベントデータを関連するデータと共に処理して、ハードウェア障害イベントデータを特有のパターンで理解することができる。さらにまた、データセンタ管理システム２１３は、ハードウェア障害イベントを測定し、予測性分析プロセスを介してリスク評価を生成するように構成されている。

工程５０４及び工程５０５におけるデータセンタ管理システム２１３による評価に基づいて、工程５０６において、データセンタ管理システム２１３は、ハードウェア障害イベントの診断証明を生成することができる。例示的な診断証明を以下の表２に提供する。

表２に示すように、診断証明は、理解（Understanding）コンポーネント、視覚的（Visualizing）コンポーネント、及び、予測性分析（Predictive analytics）コンポーネントを有するソフトウェアサービスを含むことができる。理解コンポーネントは、ハードウェア障害イベントの根本的（Root）な原因を判別することができる。いくつかの実施形態では、ハードウェア障害イベントの根本的な原因は、ハードウェア障害イベントのエンティティ、ハードウェア障害イベントの重大度、ハードウェア障害イベントの原因、ハードウェア障害イベントのシナリオ、及び、ハードウェア障害イベントの関係を含むことができる。また、理解コンポーネントは、ハードウェア障害イベントの属性（Attribute）コンポーネントを含むことができる。属性コンポーネントは、ハードウェア障害イベントコンポーネントの冗長性、ハードウェア障害イベントの方向性、ハードウェア障害イベントのリカバリ可能プロセス、及び、ハードウェア障害イベントの緊急度を含むことができる。これらの測定基準の各々の記述も診断証明に記載されている。

視覚的コンポーネントは、ハードウェア障害イベントの数量測定基準を提供することができる。数量測定基準は、ハードウェア障害イベントの重大度の数量、ハードウェア障害イベントの数量、ハードウェア障害イベントの位置の数量、ハードウェア製品の数量、ハードウェア障害イベント毎のハードウェア障害イベント構成の数量、ハードウェア障害イベント毎のソフトウェア構成の数量、及び、ハードウェア障害イベントの比率と間隔を含むことができる。これらの測定基準の各々の説明も診断証明に記載されている。単純なハードウェア障害イベントは、実際の根本的な原因を示すことができないので、関連する条件を有するエラー履歴の数量が計算される。どのような関係が各コンポーネント間の障害を引き起こしたのかを判別するための決定が行われる。障害が特定のプラットフォーム構成、コンポーネント、ファームウェアバージョン又は使用モードの何れに由来するのかについて識別される。

予測性分析コンポーネントは、リスク評価分析を実行することができる。リスク評価分析は、ハードウェア障害イベントの傾向、保護の方向性、オペレーティングシステムのリスク、ハードウェア障害イベントの問題（affliction）、及び、ハードウェアのペイン（pain）を含むことができる。これらの測定基準の各々の記述も診断証明に記載されている。

図６は、ハードウェアリカバリのプロセス６００を説明するフローチャートである。図２のデータセンタシステム２００のコンポーネントを参照して、プロセス６００を詳細に説明する。データセンタ管理システム２１３は、数千ものハードウェア障害イベントデータをマイニング及び分析した後に、修復要素（例えば、クラウドサービスリカバリが実行可能かどうか、及び、ハードウェア障害イベントの当面の危険性等）を決定するように構成されている。さらに、データセンタ管理システム２１３は、予測性分析を用いて潜在的なリスクを予測して、ソフトウェアパフォーマンスに対するハードウェア障害イベントの影響を軽減する。いくつかの実施形態において、サーバデバイス２１０上のマザーボードのハードウェア設計は、主要なコンポーネントの冗長回路を有することができる。その結果、サーバ２１０のマザーボードは、サーバが、１つの故障したコンポーネントの操作を正常なコンポーネントに移動させるのを可能にする予備のエンティティを提供することができる。不可避のハードウェア障害イベントが発生した場合、オプションの回路は、サーバの使用規模を縮小することができる。

プロセス６００は、工程６０１で開始し、データセンタ管理システム２１３は、ハードウェア障害イベントの影響を受けるサーバデバイス２１０のリカバリポリシーを検査する。リカバリポリシーは、ハードウェア障害イベントのタイプに対して固有のものにすることができる。表３は、例示的なハードウェア障害イベントと、そのリカバリ方法とを示す。

表３に示すように、レポートは、ハードウェア障害イベントの位置、ハードウェア障害イベントのタイプ、リカバリ方法、及び、ハードウェア障害イベントに関連するソフトウェアを含む。データセンタ管理システム２１３は、サーバデバイス２１０からハードウェア障害イベントレポートを受信し、統計的なデータ処理及び評価を開始する。プロセス６００は、工程６０２に進み、リカバリメカニズムを直ちに実行すべきか否かを決定する。リカバリメカニズムを直ちに実行しないと決定した場合、プロセス６００は、工程６０３に進む。工程６０３において、データセンタ管理システム２１３は、リカバリプロセスのダウンタイムをスケジュールし、リカバリプロセス中に必要なハードウェア及びソフトウェアの交換をリストする。そして、プロセス６００は、工程６０４及び工程６０５に進み、データセンタ管理システム２１３は、スケジュールされたダウンタイムをデータセンタサービスエンジニアに通知する。デザインチームのためにレッスンと学習のセッション（lesson-and-learn session）をスケジュールすることができる。技術的なフィードバックは、将来のプラットフォームハードウェア設計を改善し、必要な保護回路を追加し、トラブルシューティングのソフトウェアアルゴリズムを調整することができる。

リカバリメカニズムを直ちに実行すべきであると決定した場合、プロセス６００は、工程６０６に進む。工程６０６において、データセンタ管理システム２１３は、サーバデバイス６５０のリカバリポリシー６５１を生成する。管理者２０４（図２に示す）は、個々のリカバリポリシー６５１を生成し、これを実行して、ハードウェア障害イベントによるクラウドサービス及びパフォーマンスの影響を軽減することができる。例示的なリカバリポリシー６５１を図６に示す。次に、プロセス６００は、工程６０７に進み、ハードウェア障害イベントが、サーバデバイス６５０のパフォーマンスにおけるさらなる傾向又は欠陥について監視される。

本発明の特定の実施形態を示し説明してきたが、より広い観点において本発明から逸脱することなく変更及び修正を加えることができることが当業者には明らかであろう。したがって、添付の特許請求の範囲における目的は、本発明の真の趣旨及び範囲に含まれる全ての変更及び修正を網羅することである。上記の説明及び添付の図面に記載された事項は、例示としてのみ提供され、限定するものとして提供されない。本発明の実際の範囲は、先行技術に基づいてこれらの適切な観点から見たときに、添付の特許請求の範囲において定義されていることを意図している。

本明細書で使用される用語は、特定の実施形態を説明することのみを目的としており、本発明を限定することを意図するものではない。本明細書で使用される場合、「一」、「１つの」、「この」等の単数形は、文脈が明らかにそうでないことを示さない限り、複数形も含むことを意図している。さらに、「有する」、「含む」又はこれらの変形は、詳細な説明及び／又は特許請求の範囲において使用される限りにおいて、「備える」という用語と同様の方法で包括的であることを意味している。

別に定義されない限り、本明細書で用いられる全ての用語（技術的及び科学的用語を含む）は、本発明が属する技術分野の当業者によって通常理解されるものと同じ意味を有する。さらに、一般的に使用される辞書で定義されているような用語は、関連技術の文脈におけるそれらの意味と一致する意味を有すると解釈されるべきであり、明確に定義されない限り、理想的又は過度に形式的な意味で解釈されない。

１００…従来のデータセンタシステム
１０２…ラックサーバ
１０４，２０４…オンサイト管理者
１０６，２０６…ネットワーク
１０８，２０８…顧客
１１０，２１０…サーバデバイス
１１２…製造者
１１３，２１３…データセンタ管理システム
１１，２１…ストレージエラー
１２，２２…電源エラー
１３，２３…ＣＰＵエラー
１４，２４…メモリエラー
１５，２５…入力／出力エラー
２００…データセンタシステム
２０２…ラックサーバ
２１２…ＩＴエンジニア
３００，４００，５００，６００…方法

Claims (10)

1. データセンタシステムで発生するハードウェア障害イベントを自動的に管理する方法であって、
   前記ハードウェア障害イベントに対応するハードウェア障害イベント分析を収集する工程であって、前記ハードウェア障害イベント分析は、前記ハードウェア障害イベントを被るサーバデバイスのレポートとして構成されている、工程と、
   前記サーバデバイスのレポートから受信した統計データを処理する工程と、
   処理された統計データに基づいてハードウェアリカバリを実行する工程と、
   を含むことを特徴とする方法。
2. 前記ハードウェア障害イベント分析を収集する工程は、ハードウェア障害イベント検出プロセスを、前記サーバデバイスのベースボード管理コントローラ（ＢＭＣ）ファームウェアに記憶する工程を含み、前記レポートは、ハードウェア障害イベントレポートと、デバイスレポートと、を含む、ことを特徴とする請求項１に記載の方法。
3. 前記ハードウェア障害イベントの原因を識別する工程と、前記ハードウェア障害イベントが修復可能又は修復不可能なエラーの何れかの結果であるかを判別する工程であって、前記ハードウェア障害イベントの原因がＢＩＯＳサービスルーチンによって決定される、工程と、
   前記ハードウェア障害イベントを識別する工程であって、障害位置、障害カテゴリ、障害タイプ、及び、障害重大度のうち少なくとも１つを識別する、工程と、
   前記ハードウェア障害イベントの識別の通知をＢＭＣから受信する工程と、
   前記レポート内のデータオブジェクトを表現するために、人間が読めるテキストを使用する言語非依存のオープンデータフォーマットを受信する工程と、
   を含むことを特徴とする請求項１に記載の方法。
4. 前記レポートの分析コンポーネントにおいて、データの中心傾向分析を実行する工程を含み、
   前記中心傾向分析は、
   前記ハードウェア障害イベントに関連するオペレーティングシステム及びソフトウェアサービスのリスクを分析する工程と、
   前記サーバデバイスの保護の方向性を分析する工程と、
   前記ハードウェア障害イベントの傾向及び前記ハードウェア障害イベントの影響を予測する工程と、を含む、
   ことを特徴とする請求項１に記載の方法。
5. 前記ハードウェア障害イベントを測定する工程と、予測性分析プロセスによってリスク評価を生成して、前記ハードウェア障害イベントの診断証明を生成する工程と、を含むことを特徴とする請求項１に記載の方法。
6. 前記ハードウェアリカバリを実行する工程は、前記サーバデバイスのリカバリポリシーを検査する工程と、リカバリメカニズムをスケジューリングする工程であって、前記リカバリメカニズムは、前記リカバリポリシーに基づいて、即時的な修復又は遅延の修復の何れかにスケジュールされる、工程と、
   前記サーバデバイスの性能欠陥についてハードウェア障害イベントを監視する工程と、
   を含むことを特徴とする請求項１に記載の方法。
7. データセンタシステムで発生するハードウェア障害イベントを自動的に管理するシステムであって、
   それぞれサーバデバイスを有する複数のラックサーバと、
   前記サーバデバイスに接続されたデータセンタ管理システムと、を備え、
   前記データセンタ管理システムは、
   前記ハードウェア障害イベントに対応するハードウェア障害イベント分析を収集する工程であって、前記ハードウェア障害イベント分析は、前記ハードウェア障害イベントを被る前記サーバデバイスのレポートとして構成されている、工程と、
   前記サーバデバイスのレポートから受信した統計データを処理する工程と、
   評価された統計データに基づいてハードウェアリカバリを実行する工程と、
   を行うように構成されている、
   ことを特徴とするシステム。
8. 前記ハードウェア障害イベント分析を収集する工程は、ハードウェア障害イベント検出システムを、前記サーバデバイスのベースボード管理コントローラ（ＢＭＣ）ファームウェアに記憶する工程を含み、前記レポートは、ハードウェア障害イベントレポートと、デバイスレポートと、を含む、ことを特徴とする請求項７に記載のシステム。
9. 前記データセンタ管理システムは、前記ハードウェア障害イベントの原因を識別する工程と、前記ハードウェア障害イベントが修復可能又は修復不可能なエラーの何れかの結果であるかを判別する工程と、を行うように構成されている、ことを特徴とする請求項７に記載のシステム。
10. 前記データセンタ管理システムは、
    前記ハードウェア障害を識別する工程であって、障害位置、障害カテゴリ、障害タイプ、及び、障害重大度のうち少なくとも１つを識別する、工程と、
    前記ハードウェア障害イベントの識別の通知をＢＭＣから受信する工程と、
    前記レポート内のデータオブジェクトを表現するために、人間が読めるテキストを使用する言語非依存のオープンデータフォーマットを受信する工程と、
    を行うように構成されている、
    ことを特徴とする請求項７に記載のシステム。

Images