JP2013509626A - 仮想コンピューティング環境における障害管理のための方法、システム、およびコンピュータ・プログラム - Google Patents

Abstract

【課題】仮想コンピューティング環境における障害管理のための方法およびシステムを提供する。
【解決手段】システムは、仮想コンピューティング環境における仮想マシンおよびホスト・デバイスからの障害イベントのモニタと、仮想コンピューティング環境における状況イベントのモニタであって、状況イベントは仮想マシン名およびホスト・デバイス名を言い表すものである、モニタとを含む。普遍的な障害コンポーネントは、障害イベントが仮想マシンとホスト・デバイスの両方に影響を与えているかどうかを判別し、相関コンポーネントは、仮想マシンおよびホスト・デバイスに関する障害イベントを同じ問題に関するものとして相関させる。ある問題に相関付けられたホスト・マシン障害イベントはルート・イベントとしてマーク付けされ、ある問題に相関付けられた仮想マシン障害イベントはルート・イベントへのリンクを備えた症状としてマーク付けされる。
【選択図】 図１

Description

本発明は、障害管理の分野に関する。具体的に言えば、本発明は仮想コンピューティング環境における障害管理に関する。

オペレーティング・システムを仮想環境で動作させることは一般的である。これらを使用して、様々なサービスを実装するアプリケーションが実行される。各仮想マシン（ＶＭ）は物理コンピュータを直接再現するが、物理ホスト・マシン上のハイパーバイザの下で実行される。ホスト・マシンはいくつかのＶＭをホストすることができる。ホスト・マシンの使用率を最大にし、耐障害性を上昇させるために、ＶＭはしばしばホスト・マシンのクラスタ上で実行される。１つのマシンが障害を起こした場合、ＶＭはクラスタ内の他のホスト・マシン上で実行するために移動または移行することができる。

障害は、ＶＭ上でも物理マシン上と同様に発生する可能性がある。障害管理システムを使用して、これらの問題を検出および監視し、オペレータに報告して、迅速な解決を可能にすることができる。たとえばＩＢＭ（Ｒ）のＴｉｖｏｌｉ（Ｒ）Ｎｅｔｃｏｏｌ（Ｒ）は、障害イベントを含む多くの異なるネットワーク・データ・ソースから企業規模のイベント情報を収集する、サービス・レベル管理システムである（ＩＢＭ、Ｔｉｖｏｌｉ、およびＮｅｔｃｏｏｌは、世界中の多くの管轄権で登録された、インターナショナル・ビジネス・マシーンズ・コーポレーションの商標である）。

仮想環境では、障害は、ＶＭを実行中のホスト・ハイパーバイザ・システム上の障害によって引き起こされる可能性がある。多くのＶＭが単一のホストによって実行されている場合、結果として、潜在的に、ＶＭ自体での障害によるものでない大量の障害が報告されることになる。これは、オペレータが迅速に対処および解決するには、厄介で時間のかかるものである可能性がある。さらに、たとえハイパーバイザの障害監視が実装されている場合であっても、この（しばしばそれほど重症でない）根本原因である障害は、大量のＶＭ障害イベントの中で見失われ、オペレータが見過ごしてしまう可能性がある。

加えて、ＶＭ上のいくつかの障害を解決する１つの方法は、それらを異なる物理ホスト・マシンに移動させることである。これによって、いくつかの問題はすぐに解決されるが、これらＶＭ上で実行されている従来の障害監視システムは、この状況の変化を更新して問題を解決するために、速度が低下する可能性がある。

したがって当分野では、前述の問題に対処することが求められている。

本発明の第一の態様によれば、仮想コンピューティング環境において仮想マシンおよびホスト・デバイスからの障害イベントを監視すること、仮想コンピューティング環境において状況イベントを監視することであって、状況イベントは仮想マシン名およびホスト・デバイス名を言い表すものである、監視すること、障害イベントが仮想マシンとホスト・デバイスの両方に影響を与えているかどうかを判別すること、ならびに、仮想マシンおよびホスト・デバイスに関する障害イベントを同じ問題に関するものとして相関させること、を含む、仮想コンピューティング環境における障害管理のための方法が提供される。

方法は、仮想マシン状況テーブルを維持すること、ならびに、仮想マシン名およびホスト名のマッピングを維持することを、含むことができる。

方法は、障害イベントを障害イベント・テーブルに挿入することを含むこともできる。問題に相関付けられたホスト・マシンの障害イベントは、障害イベント・テーブルにおいてルート・イベントとしてマーク付けすることができる。問題に相関付けられた仮想マシンの障害イベントは、障害イベント・テーブルにおける症状（symptom）および障害イベント・テーブルに追加されたルート・イベントへのリンクとしてマーク付けすることができる。

仮想マシンが新しいホスト・マシンへと移動された場合、仮想マシンに関するすべての障害イベントを障害イベント・テーブル内に配置し、重症度を軽減することができる。加えて、ルート・リンクを除去することができる。

状況イベントは、プローブ（probe）のイベント警告の供給元である監視システムによって監視されること、ならびに、仮想マシンおよびホスト・デバイスとホスト障害イベントとの間の関係の指示を含むことが可能である。

仮想マシン内の障害イベントは、仮想マシン上で実行中のプローブによって供給することが可能であり、ホスト・マシン内の障害イベントは、ホスト・マシン上で実行中のプローブによって供給することが可能である。

ホスト・マシン内の障害イベントは、プローブのイベント警告の供給元である監視システムによって監視されることが可能である。

本発明の第２の態様によれば、仮想コンピューティング環境における障害管理のためのコンピュータ・ソフトウェア製品が提供され、この製品は、コンピュータ実行可能命令を備えるプログラムが格納されたコンピュータを備え、この命令は、コンピュータによって読み取りが実行された場合に、仮想コンピューティング環境において仮想マシンおよびホスト・デバイスからの障害イベントを監視するステップと、仮想コンピューティング環境において状況イベントを監視するステップであって、状況イベントは仮想マシン名およびホスト・デバイス名を言い表すものである、監視するステップと、障害イベントが仮想マシンとホスト・デバイスの両方に影響を与えているかどうかを判別するステップと、仮想マシンおよびホスト・デバイスに関する障害イベントを同じ問題に関するものとして相関させるステップと、を実行する、コンピュータ読み取り可能ストレージ・メディアを備える。

本発明の第３の態様によれば、プロセッサと、仮想コンピューティング環境における仮想マシンおよびホスト・デバイスからの障害イベントのモニタと、仮想コンピューティング環境における状況イベントのモニタであって、状況イベントは仮想マシン名およびホスト・デバイス名を言い表すものである、モニタと、障害イベントが仮想マシンとホスト・デバイスの両方に影響を与えているかどうかを判別するための正規化コンポーネントと、仮想マシンおよびホスト・デバイスに関する障害イベントを同じ問題に関するものとして相関させるための相関コンポーネントと、を備える、仮想コンピューティング環境における障害管理のためのシステムが提供される。

システムは、仮想マシン状況テーブルと、仮想マシン名およびホスト・デバイス名のマッピングとを含むことができる。

システムは、仮想マシンまたはホスト・デバイスに関する障害イベントのリストを維持するための障害イベント・テーブルをさらに含むこともできる。システムは、問題に相関付けられたホスト・マシンの障害イベントに関する障害イベント・テーブル内のルート・イベント・マーカを含むことができる。システムは、問題に相関付けられた仮想マシンの障害イベントに関する障害イベント・テーブル内の症状マーカと、障害イベント・テーブル内のルート・イベントへのリンクを含むこともできる。

システムは、障害解決（faultresolution）コンポーネントを含むことが可能であり、仮想マシンが新しいホスト・マシンに移動された場合、解決コンポーネントは仮想マシンに関するすべての障害イベントを障害イベント・テーブル内に配置し、イベントの重症度を軽減する。

状況イベントに関するモニタは、仮想環境クラスタ制御センタから状況イベントを取得することが可能であり、障害管理システムにイベント警告を供給することが可能である。

障害イベントに関するモニタは、仮想マシン上で実行中のプローブとすることが可能であり、障害イベントに関するモニタは、ホスト・マシン上で実行中のプローブとすることが可能である。

ホスト・マシン内の障害イベントに関するモニタは、仮想環境クラスタ制御センタから障害イベントを取得することが可能であり、障害管理システムにイベント警告を供給することが可能である。プローブはリモート・マシン上で実行可能であり、ネットワークを介してホスト・マシンを監視することが可能である。

第４の態様から見ると、本発明は、コンピュータ読み取り可能メディア上に格納され、デジタル・コンピュータの内部メモリにロード可能な、当該プログラムがコンピュータ上で実行された場合、本発明の諸ステップを実行するためのソフトウェア・コード部分を備える、コンピュータ・プログラムを提供する。

次に、本発明について、以下の図面に示された好ましい実施形態を参照しながら、単なる例として説明する。

本発明に従ったシステムの好ましい実施形態を示すブロック図である。 本発明の好ましい実施形態に従ったシステムのオブジェクト・サーバを示すブロック図である。 本発明の好ましい実施形態が内部に実装可能な、コンピュータ・システムを示すブロック図である。 本発明の好ましい実施形態に従った方法を示す流れ図である。 本発明の好ましい実施形態に従った方法を示す流れ図である。

図を簡単に見やすくするために、図面に示される要素は必ずしも縮尺通りに図示されているとは限らない。たとえばいくつかの要素の寸法は、見やすくするために、他の要素に対して拡大されている可能性がある。さらに、適切であるとみなされる場合、参照番号は、対応するかまたは類似の特徴を示すために、図面間で反復される可能性がある。

以下の詳細な説明では、本発明を完全に理解するために、多数の特定の細部が示される。しかしながら、当業者であれば、本発明がこれらの特定の細部なしでも実施可能であることを理解されよう。他の例では、本発明を不明瞭にしないように、周知の方法、手順、およびコンポーネントについては詳細に説明されていない。

障害イベントがハイパーバイザおよびＶＭの両方から集められ、正規化されて、障害管理システムに供給される、方法およびシステムについて説明される。各ＶＭがどのホスト・マシン上で実行中であるかを示すデータも、ハイパーバイザから集められる。この情報は、以下のアクションを実行するために使用される。

１．障害イベントの相関。ホスト・マシンまたはハイパーバイザ（ホスト・イベントと呼ばれる）および同じ初期問題に関する仮想マシン（ＶＭイベントと呼ばれる）によって生成される、障害イベントが識別される。ＶＭ上にエラーを発生させているホスト・イベントの重症度が増加し、根本原因としてマーク付けされる。ＶＭからの対応するエラーの重症度が減少し、症状イベントとしてマーク付けされ、イベント内のフィールドは根本原因イベントを指示するように設定される。これによってオペレータは、症状イベントを除去し、重症度の高い根本原因イベントをかなり迅速に識別できるようになる。問題はより速く解決可能となり、これによってすべての症状ＶＭイベントが解決されることになる。オペレータが特定の症状イベントに注目している場合、根本原因を迅速に識別することも可能である。

２．ＶＭ移行後の障害解決。ハードウェア関連障害は、仮想マシンを新しい物理ホスト・マシンへ移動させることによって解決可能である。ＶＭが新しい物理ホストに移行された場合、このクラスのすべての障害の重症度が軽減される。ＶＭ上のモニタが、障害がクリアされた旨の情報を受信すると、ＶＭイベントは通常通り解決およびクリアされることになる。このように実行することの利点は、重症度の高い障害イベントのオペレータの表示がかなり迅速にクリアされるため、いずれかのより重要な問題に集中できることである。

図１を参照すると、仮想コンピューティング環境における障害イベントに対処するための障害管理サーバ１１０を含むシステム１００が提供される。

仮想コンピューティング環境は、１つまたは複数の仮想マシン１２１〜１２６を含み、そのそれぞれが、ハードウェア・リソースを直接およびトランスペアレントに割り振る仮想マシン・モニタまたはハイパーバイザ１４１、１４２であるソフトウェア・レイヤを有する、ホスト・マシン・オペレーティング・システム１３１、１３２またはコンピュータ・ハードウェア上で実行している。複数のオペレーティング・システムが単一の物理コンピュータ上で同時に実行可能であり、互いにハードウェア・リソースを共有することができる。中央プロセッサ、メモリ、オペレーティング・システム、およびネットワーク・デバイスを含む、マシン全体をカプセル化することによって、仮想マシン１２１〜１２６は、すべての標準的なオペレーティング・システム、アプリケーション、およびデバイス・ドライバに完全に適合可能である。

ホスト・マシンの使用率を最大にし、耐障害性を上昇させるために、ＶＭ１２１〜１２６はホスト・マシン１３１、１３２のクラスタ１３０上で実行される。一方のホスト・マシン１３１、１３２に障害が発生すると、ＶＭは、クラスタ１３０内の他方のホスト・マシン１３１、１３２上で実行するように移動（または移行）可能である。

ＶＭ１２１〜１２６は、基礎となるハードウェアの障害または問題（ＶＭハードウェア障害と呼ばれる）によって引き起こされたＶＭ障害１６１について障害管理サーバ１１０に報告するための、プローブ供給１６０を提供するために、プローブを実行する。ホスト・マシン１３１、１３２は、ホスト・ハードウェア障害１７１について障害管理サーバ１１０に報告するための、プローブ供給１７０を提供するためにも、プローブ（これらがホスト・マシンによってサポートされている場合）を実行することができる。

プローブという用語は、ＶＭまたはホスト・マシンなどのイベント・ソースに接続され、イベント・データを検出および獲得し、このイベント・データを警告として障害管理サーバ１１０へ転送する、プログラムに使用される。プローブは、規則ファイル内に指定された論理を使用して、イベント要素を操作した後、これらを障害管理サーバ１１０の警告状況テーブル内の警告フィールドに変換することができる。各プローブは、特定のソースからイベント・データを獲得するように設計される。プローブは、ネットワーク・デバイスをリモートにまたは直接監視するための、監視デバイスまたはエージェントとも呼ぶことができる。

たとえば、ＶＭ１２１〜１２６およびホスト・マシン１３１、１３２は、Ｌｉｎｕｘ（Ｒ）ベースの場合、標準ＩＢＭ ＯＭＮＩｂｕｓプローブ１６０を実行するか、または、ＩＢＭ ＯＭＮＩｂｕｓをサポートするプラットフォーム上で実行することが可能である（Ｌｉｎｕｘは、米国、他の諸外国、またはその両方における、Ｌｉｎｕｓ Ｔｏｒｖａｌｄｓの登録商標である）。

代替の配置構成では、プローブはリモート・マシン上で実行され、ネットワーク・プロトコルまたはリモート・マウントを介してハイパーバイザ・マシン１３１、１３２を監視することができる。

クラスタ１３０は、制御センタ１３３を介して制御され、必要に応じて、ホスト・マシン１３１、１３２間でＶＭ１２１〜１２６を移行することになる。制御センタ１３３は、クラスタ１３０上のＶＭ１２１〜１２６上で実行可能である。

ＡＰＩを介して制御センタ１３３と対話し、状況イベント１８１を監視システム１５０に報告する、エージェント１５１を有する、監視システム１５０が提供される。プローブまたはモニタを使用して、これらのイベントが障害管理サーバ１１０へと供給１８０される。状況イベント１８１は、どのＶＭ１２１〜１２６がどのホスト・マシン１３１、１３２上にあるかを追跡し、ホスト障害１７１も報告する。

代替の配置構成では、オプションでエージェント１５１を、制御センタ１３３を介さずにハイパーバイザ１４１、１４２に直接接続することができるが、これはホスト・マシン１３１、１３２全体に障害が発生した場合、堅固性に欠ける。

ホスト１３１、１３２上のホスト・ハードウェア障害１７１は、状況イベント１８１内で制御センタ１３３を介して監視システム１５０へと報告され、その後、状況イベント１８１の報告に使用されるプローブ供給１８０を介して、障害管理サーバ１１０へと報告される。

加えて、ホスト・マシン１３１、１３２がプローブをサポートしている場合、ホスト・ハードウェア障害１７１は障害管理システム１１０に直接供給することができる。ハードウェア障害１７１がプローブを介して障害管理システムに直接供給１７０できる場合（このオプションは、図１内に破線で示されている）、プローブを使用して、ホスト・マシン１３１、１３２からより豊富な潜在的エラーのセットを直接集めることができる。

産業利用性の高い環境で最も一般的かつ広範囲に使用されているハイパーバイザは、ＶＭｗａｒｅ ＥＳＸである（ＶＭｗａｒｅおよびＥＳＸは、ＶＭｗａｒｅ，Ｉｎｃの商標である）。ある実施形態例では、ＶＭｗａｒｅ ＥＳＸハイパーバイザ・クラスタを使用する監視システムは、仮想インフラストラクチャのためのＶＭｗａｒｅ用エージェント（ＶＭｗａｒｅ ＶＩエージェント）を備えた、ＩＢＭ Ｔｉｖｏｌｉモニタ（ＩＴＭ）の形で使用することができる。障害管理サーバは、ＶＭｗａｒｅ ＶＩエージェントからイベントを供給するためのイベント統合機能（ＥＩＦ／Ｅｖｅｎｔ Ｉｎｔｅｇｒａｔｉｏｎ Ｆａｃｉｌｉｔｙ）プローブを使用するＩＢＭ Ｎｅｔｃｏｏｌ／ＯＭＮＩｂｕｓシステムのオブジェクト・サーバ（ＯｂｊｅｃｔＳｅｒｖｅｒ）とすることができる。

ＶＭのハードウェア障害は、ＩＢＭ ＯＭＮＩｂｕｓプローブを使用して報告される。ＶＭｗａｒｅ ＥＳＸハイパーバイザはＬｉｎｕｘベースであるため、標準ＩＢＭ ＯＭＮＩｂｕｓプローブを実行することができる。ホスト上のハードウェア障害も、ＥＳＸ制御センタを介してＩＴＭに報告され、その後、ＥＩＦプローブを介してＯｂｊｅｃｔＳｅｒｖｅｒに報告される。

ＩＢＭ ｐＨＹＰＥ、Ｍｉｃｒｏｓｏｆｔ（Ｒ） ＨｙｐｅｒＶ（ＴＭ）（ＭｉｃｒｏｓｏｆｔおよびＨｙｐｅｒＶは、米国、他の諸外国、またはその両方における、マイクロソフト・コーポレーションの商標である）、Ｌｉｎｕｘ上のＫｅｒｎｅｌベースの仮想マシン、ｚ／ＶＭ（Ｒ）（ｚ／ＶＭは、世界中の多くの管轄権で登録された、インターナショナル・ビジネス・マシーンズ・コーポレーションの登録商標である）、およびその他を含む、他のハイパーバイザが使用可能である。

監視エージェント１５１は、そのＳＤＫ ＡＰＩを介して制御センタ１３３に接続され、以下の状況イベント１８１を生成することができる。各状況は発生時に立ち上げられ、適用されなくなるとクリアされる。

可用性
・ホスト・マシン・サーバの状況には到達不可能である。
中央処理装置（ＣＰＵ）
・ＶＭＫｅｒｎｅｌはロードされない。
・ＣＰＵ使用率は非常に高い。
・ＣＰＵ使用率は低い。
・ＣＰＵはオーバロードである。
ディスク
・ファイルシステムはほぼ満杯である。
・ディスク読み取りアクティビティは多い。
・ディスク書き込みアクティビティは多い。
メモリ
・コンソールＯＳ（ＣＯＳ）用の使用可能空きメモリの量は少ない。
・ホスト・マシン・サーバ用の使用可能空きメモリの量は少ない。
ネットワーク
・ネットワーク送信アクティビティは多い。
・ネットワーク受信アクティビティは多い。
仮想マシン
・仮想マシンの電源はオフである。
・仮想マシンはスタック状態である。
・仮想マシンは未知の状態である。
・仮想マシンは一時停止状態である。

「ホスト・マシン・サーバの状況には到達不可能である」という例外はあるが、これら状況はそれぞれＶＭサーバ名およびＶＭ名属性を有する。これは、ハードウェア・サーバ名と、制御センタ・ソフトウェア内に構成されたＶＭの名前とに対応する。これは通常、仮想マシンのホスト名に対応することになる。

図２を参照すると、ブロック図は障害管理サーバ１１０を示している。障害管理サーバ１１０は、障害イベント相関コンポーネント２１０と障害解決コンポーネント２２０とを含む。加えて、障害管理サーバ１１０は、ＶＭ状況テーブル２３０と、ハードウェア障害に関する警告状況テーブル２４０と呼ばれる障害イベントのテーブルとを含む。

障害イベント相関コンポーネント２１０は、同じ初期問題に関するホストまたはハイパーバイザおよび仮想マシンによって生成された、障害イベントを識別する。ＶＭ上にエラーを発生させているホスト・イベントは重症度が増加し、根本原因としてマーク付けされる。ＶＭからの対応するエラーは重症度が減少し、症状イベントとしてマーク付けされ、イベント内のフィールドは根本原因イベントを指示するように設定される。

障害解決コンポーネント２２０は、ＶＭ移行後に障害を解決する。ハードウェア関連障害は、仮想マシンを新しい物理ホスト・マシンに移動することによって解決することができる。ＶＭが新しい物理ホストに移行された場合、このクラスのすべての障害の重症度が軽減される。ＶＭ上のモニタが、障害がクリアされた旨の情報を受信すると、ＶＭイベントは通常通り解決およびクリアされることになる。

ＶＭ状況テーブル２３０は、ＶＭホスト名およびＶＭサーバ・ホスト名とＶＭ状況とを含む。

障害管理サーバ１１０の状況テーブル２３０の実施形態例は、４つの列を含む。

上記に列挙されたあらゆる状況イベント（「ホスト・マシンの状況には到達不可能である」とは別に）について、プローブ供給は、障害管理サーバ１１０のＶＭ状況テーブル２３０にＶＭサーバ名およびＶＭ名属性を送信することになる。

第１のトリガ２３１は、プローブ供給からのＶＭ状況を更新するために、ＶＭ状況テーブルに関連付けられる。ＶＭ状況テーブル２３０の第１のトリガ２３１は、テーブル内のデータが変更されないままである場合、アクションを起こすことはない。たとえば「仮想マシンの電源はオフである」、「仮想マシンはスタック状態である」、または「仮想マシンは一時停止状態である」が真となった場合、アクティブ列の値は０になり、そうでない場合は１になる。

他の実施形態では、手順を呼び出すことができる。たとえば、仮想マシンに関連付けられたホストが変更された場合、ＶＭ＿Ｈｏｓｔ＿Ｃｈａｎｇｅ手順が呼び出される。ＶＭエントリの状態がアクティブから非アクティブに変更された場合、ＶＭ＿Ｄｏｗｎ手順が呼び出される。ＶＭエントリの状態が非アクティブからアクティブに変更された場合、ＶＭ＿Ｒｅｓｔｏｒｅｄ手順が呼び出される。構成ファイルは、手順ではなくこれらのアクション実行するために他のトリガ・セットを呼び出す信号を使用することができる。

ＶＭ状況テーブル２３０は、ＶＭ状況エントリを削除するために関連付けられた第２の一時トリガ２３２を含む。これは、状況テーブル２３０から未使用のエントリをクリアし、１日に１回実行することができる。各状況エントリがチェックされ、所与の期間中（たとえば２週間）変更がなかった場合、エントリは削除される。このトリガの目的は、一時仮想イメージが定期的に作成および破棄されている場合、ＶＭ状況テーブルが増大するのを防ぐことである。

ＶＭの状況は、監視エージェントからの状況イベント１８１によって最新の状態に維持される。

情報は、異なる状況がＶＭ状況テーブル２３０に同じ情報を提供可能なように複製される。これは、状況イベントが見逃されるというあり得ないことが発生した場合に、さらに高い耐障害性を提供するために実行される。

クラスタ（ＶＭｗａｒｅエージェント、ＥＩＦプローブ、およびＯｂｊｅｃｔＳｅｒｖｅｒ）の監視は、いずれのＶＭが開始されるよりも前に実行されるものとする。これにより、ＶＭ状況テーブル２３０が正しく読み込まれることが保証される。監視が開始された時点で、ＶＭがすでにクラスタ上で実行中である場合、これらは一時停止され、中断されていないサービスが必要な場合、ＶＭ状況テーブル２３０またはＶＭｏｔｉｏｎｅｄを他のホストに読み込むために再開されるものとする。

プローブ規則ファイル２６０は、他のプローブによって生成された同様のエラー・イベントに適合する正規化されたフォーマットへの状況イベントのマッピングを実行し、エラー・イベントおよび前述のエラー状況に関する解決を挿入するために使用可能な、正規化コンポーネント２６１を含む。イベント生成コンポーネント２６２は、警告状況テーブル２４０ならびにＶＭ状況テーブル２３０内にイベントを挿入するために、規則ファイル２６０内で使用される。

障害イベント相関コンポーネント２１０は、ハードウェア・エラー・イベントを相関させる。仮想マシンとハイパーバイザとの間でハードウェア・エラーを相関させる機能が必要である。これらのハードウェア・エラー１６１、１７１は、ＶＭ上で実行中のプローブによって、ならびに、ハイパーバイザあるいはホスト・マシンまたはその両方で実行中であるかまたはこれらと通信中のプローブまたはエージェントによって、集められる。

ＶＭｗａｒｅ用の構成例の場合、障害イベントはＩＴＭ ＶＩ ＶＭｗａｒｅエージェントを介してリモートに集められる。

ハイパーバイザおよびその上で実行中のＶＭの両方に影響を与えるハードウェア障害１１６１、１７１のグループは、ごくわずかである。典型的な例は、高ＣＰＵ使用、メモリ障害、または共有デバイス障害である。ハードウェア・イベントの有効なタイプのみが処理されることになる。これらは、プローブ規則ファイル２７０内の普遍的障害を識別する正規化コンポーネント２７１によって、分類および正規化される。ＩＴＭ ＶＭｗａｒｅイベントの場合、これは、ＥＩＦプローブ規則ファイル２６０内で実行されることになる。

エラー・イベントは、警告状況テーブル２４０内に挿入されると、たとえば２０秒ごとなどの一定の間隔で実行される、一時相関トリガ２４１を使用して相関されることになる。

ホストおよびＶＭイベントが相関されると、この関係を示すように修正する必要がある。一実施形態では、ＶＭイベント２４２は「症状」イベント２４３としてマーク付けされ、ホスト・イベント２４４は「ルート」イベント２４５としてマーク付けされる。その後、症状イベントはルート・イベントを指示することになる。

ＶＭが完全に障害を起こした場合、さらに多くのエラー・イベントの根本原因となる可能性もある。手順を使用する実施形態では、ＶＭ＿ＤｏｗｎおよびＶＭ＿Ｒｅｓｔｏｒｅｄの手順を使用して、これらタイプのエラーに関するルート・リンクを導入することができる。たとえば、ＶＭ上で実行中のプローブに障害が発生し、心拍が受信されなくなったためにエラーを生成する可能性がある。このエラーに関する詳細および概要はＶＭ＿Ｄｏｗｎ手順によって更新され、ＶＭ＿Ｒｅｓｔｏｒｅｄ手順は、この情報を再度更新し、エラー・イベントの重症度を軽減させること、あるいはルート・リンクを導入すること、またはその両方を実行する。しかしながら、エラーは、プローブが再度実行されている場合にのみ、クリアされる。

障害解決コンポーネント２２０は、ハードウェア・エラー・イベントを解決する。ＶＭが移行された場合、これがＶＭ状況テーブル２３０を更新する。この手順は、ＶＭホスト名に関連付けられたすべてのハードウェア・エラー・イベントのスキャンを実行し、それらがもはや重要な問題でない旨を示すように、それらの重症度を減少させる。ルート・リンクが物理ホスト・イベントに導入されている場合、これは除去される。

これらのハードウェア・エラー・イベントは、状況イベントに対するスーパーセットとなる。ハイパーバイザおよびＶＭの両方に影響を与えるエラー・イベントは、すでに重症度がほぼ軽減されているはずであり、除去を必要とする何らかの形のルート・リンクを有することになる。その重症度を軽減させる必要のある未相関イベントが存在する可能性もある。最終的に、ディスク・スペースが少ないなどのいくつかのハードウェア・エラー・イベントは、ＶＭの移行によって解決されないため、変更されずに残されることになる。

提案されたソリューションは、ＶＭホスト名対ハイパーバイザ・ホスト名マッピング・テーブル２８０に依拠する。

このテーブル２８０は、いくつかのトリガ内で検索される。主キーはＶＭホスト名となり、これを使用してテーブルが検索され、有効なハッシュ・テーブル・ルックアップが障害管理サーバによって使用されることになる。最高の処理オーバヘッドは、ＶＭ対物理ホスト相関トリガ２４１である。これは、警告状況テーブル２４０のトラバース回数を最低に維持するものでなければならない。しかしながら、ハイパーバイザ・ホストがダウンした場合、潜在的に大量のＶＭが異なるホストに移行される可能性がある。

同様に、多くのＶＭを実行中のハイパーバイザ上でハードウェア・エラーが発生した場合、潜在的に大量のハードウェア・エラー・イベントが受信される可能性がある。

図３を参照すると、本発明の好ましい諸実施形態の諸態様を実装するための例示的システムは、メモリ要素に直接、またはバス・システム３０３を介して間接的に結合された、少なくとも１つのプロセッサ３０１を含む、プログラム・コードの格納あるいは実行またはその両方を行うのに好適な、データ処理システム３００を含む。メモリ要素は、プログラム・コードの実際の実行中に、大容量ストレージと、実行中に大容量ストレージからコードを取り出さなければならない回数を減らすために少なくともいくつかのプログラム・コードの一時ストレージを提供するキャッシュ・メモリとを使用する、ローカル・メモリを含むことができる。メモリ要素は、読取り専用メモリ（ＲＯＭ）３０４およびランダム・アクセス・メモリ（ＲＡＭ）３０５の形の、システム・メモリ３０２を含むことができる。基本入力／出力システム（ＢＩＯＳ）３０６は、ＲＯＭ３０４内に格納可能である。システム・ソフトウェア３０７は、オペレーティング・システム・ソフトウェア３０８を含み、ＲＡＭ３０５に格納することができる。ソフトウェア・アプリケーション３１０もＲＡＭ３０５に格納することができる。

システム３００は、磁気ハード・ディスク・ドライブなどの１次ストレージ手段３１１と、磁気ディスク・ドライブおよび光ディスク・ドライブなどの２次ストレージ手段３１２とを含むこともできる。ドライブおよびそれらの関連付けられたコンピュータ読み取り可能メディアは、コンピュータ実行可能命令、データ構造、プログラム・モジュール、およびシステム３００に関する他のデータの、不揮発性ストレージを提供する。ソフトウェア・アプリケーションは、１次および２次のストレージ手段３１１、３１２、ならびにシステム・メモリ３０２上に格納することができる。

コンピューティング・システム３００は、ネットワーク・アダプタ３１６を介した１つまたは複数のリモート・コンピュータへの論理接続を使用して、ネットワーク化環境内で動作可能である。

入力／出力デバイス３１３は、直接、または介在Ｉ／Ｏコントローラを介して、システムに結合可能である。ユーザは、キーボード、ポインティング・デバイス、または他の入力デバイス（たとえば、マイクロフォン、ジョイ・スティック、ゲーム・パッド、衛星放送用パラボラアンテナ、スキャナなど）などの入力デバイスを介して、コマンドおよび情報をシステム３００に入力することができる。出力デバイスは、スピーカ、プリンタなどを含むことができる。ディスプレイ・デバイス３１４も、ビデオ・アダプタ３１５などのインターフェースを介してシステム・バス３０３に接続される。

図４を参照すると、流れ図４００は説明された方法を示す。状況イベントが受信され（４０１）、正規化される（４０２）。これと並行して、ＶＭプローブ・イベント（加えて、サポートされている場合はホスト・プローブ・イベント）が受信され（４０３）、正規化される（４０４）。正規化されたイベントは、障害イベントとして警告状況テーブルに挿入される（４０５）。

ＶＭおよびホスト・マッピング情報が状況イベントから抽出され（４０６）、ＶＭ状況テーブルが更新される（４０７）。

ＶＭ対ホスト・マッピングが変更されたかどうかが判別される（４０８）。変更されていない場合、入力時間のみが更新される（４０９）。変更されている場合、入力時間が更新され、移動されたＶＭに関する警告状況テーブル内のすべてのハードウェア障害が見つけられる（４１０）。

ＶＭに関する任意の好適なハードウェア障害が存在するかどうかが判別される（４１１）。存在しない場合、方法は終了する（４１２）。存在する場合、ＶＭ障害の重症度が軽減され（４１３）、症状分類があれば除去される。ホストの根本原因障害へのリンクがあれば、破棄される。その後、方法は終了する（４１４）。

図５を参照すると、流れ図５００は、一定の間隔で実行される障害の相関方法を示す。

第１に、ＶＭ相関候補である障害が識別される（５０１）。これは、以下の点を満たす警告状況テーブル内のすべての障害を見つけることによって実行される。
・根本原因または症状として分類されていない。
・まだ解決されていない。
・ＶＭ状況テーブル内のＶＭホスト名のうちの１つと一致するホスト名を有する。
・ホスト問題によって引き起こされる可能性のあるタイプである。

任意の好適な障害が見つかったかどうかが判別される（５０２）。見つからない場合、方法は終了する（５０３）。こうした障害が見つかった場合、ＶＭ相関候補内の各障害について、ＶＭ状況テーブル内のホスト・サーバ名をルック・アップする（５０４）。ホスト・サーバ名のセットとしてすべてのホスト・サーバ名をまとめて集める（５０５）。

次に、ホスト相関候補である障害が識別される（５０６）。これは、以下の点を満たす警告状況テーブル内のすべての障害を見つけることによって実行される。
・症状として分類されていない。
・まだ解決されていない。
・ステップ５０５のホスト・サーバ名のセット内に、ホスト名を有する。
・ホスト問題を引き起こす可能性のあるタイプである。

任意の好適な障害が見つかったかどうかが判別される（５０７）。見つからない場合、方法は終了する（５０８）。こうした障害が見つかった場合、ＶＭ相関候補内の各障害について、ホスト相関候補内のホスト障害をルック・アップする（５０９）。

エラー・タイプが一致するかどうかが判別される（５１０）。一致しない場合、方法は終了する（５１１）。一致した場合、相関されたＶＭとホスト障害とのペアが存在する（５１２）。

ＶＭ障害が症状としてマーク付けされ（５１３）、「ローカル・ルート・オブジェクト」フィールドはホスト障害を指示し、障害の重症度が低減される。ホスト障害は根本原因としてマーク付けされ（５１４）、その重症度が上がる。

複数のＶＭ障害が単一のホスト根本原因障害を指示することが可能であることに留意されたい。

障害管理システムは、ネットワークを介して顧客へのサービスとして提供することができる。

本発明は、完全にハードウェア実施形態、完全にソフトウェア実施形態、または、ハードウェアとソフトウェアの両方の要素を含む実施形態の形を取ることができる。好ましい実施形態では、本発明は、ファームウェア、常駐ソフトウェア、マイクロコードなどを含むがこれらに限定されない、ソフトウェア内で実装される。

本発明は、コンピュータまたは任意の命令実行システムによって、またはそれらに関連して使用するためのプログラム・コードを提供する、コンピュータ使用可能またはコンピュータ読み取り可能メディアからアクセス可能な、コンピュータ・プログラム製品の形を取ることができる。これを説明するために、コンピュータ使用可能またはコンピュータ読み取り可能メディアは、命令実行システム、装置、またはデバイスによって、あるいはそれらに関連して使用するためのプログラムを、包含、格納、通信、伝搬、または移送することが可能な、任意の装置とすることができる。

メディアは、電子、磁気、光、電磁、赤外線、または半導体システム（あるいは装置またはデバイス）、あるいは伝搬メディアとすることができる。コンピュータ読み取り可能メディアの例は、半導体またはソリッド・ステート・メモリ、磁気テープ、取り外し可能コンピュータ・ディスケット、ランダム・アクセス・メモリ（ＲＡＭ）、読取り専用メモリ（ＲＯＭ）、剛性磁気ディスク、および光ディスクを含む。光ディスクの現行例は、コンパクト・ディスク読み取り専用メモリ（ＣＤ−ＲＯＭ）、コンパクト・ディスク読み取り／書き込み（ＣＤ−Ｒ／Ｗ）、およびＤＶＤを含む。

本発明の範囲を逸脱することなく、前述の内容に改良および修正を行うことができる。

Claims (24)

1. 仮想コンピューティング環境において仮想マシン（１２１〜１２６）およびホスト・デバイス（１３１、１３２）からの障害イベント（４０１、４０３）を監視すること、
   前記仮想コンピューティング環境において状況イベント（４０１）を監視することであって、前記（４０１）状況イベントは仮想マシン名およびホスト・デバイス名を言い表すものである、監視すること、
   障害イベントが仮想マシン（１２１〜１２６）とホスト・デバイス（１３１、１３２）の両方に影響を与えているかどうかを判別すること（５０１〜５１２）、
   仮想マシン（１２１〜１２６）およびホスト・デバイス（１３１、１３２）に関する障害イベントを同じ問題に関するものとして相関させること（５１２）、
   を含む、仮想コンピューティング環境における障害管理のための方法。
2. 仮想マシン状況テーブル（２３０）を維持すること（４０７）、および
   仮想マシン名およびホスト名のマッピング（２５０）を維持すること、
   を含む、請求項１に記載の方法。
3. 障害イベントを障害イベント・テーブル（２４０）に挿入すること（４０５）
   を含む、請求項１または２に記載の方法。
4. 問題に相関付けられたホスト・マシンの障害イベントが、前記障害イベント・テーブル（２４０）においてルート・イベントとしてマーク付けされる（５１４）、請求項３に記載の方法。
5. 問題に相関付けられた仮想マシンの障害イベントは、前記障害イベント・テーブルにおける症状および前記障害イベント・テーブルに追加された前記ルート・イベントへのリンクとしてマーク付けされる、請求項３または４に記載の方法。
6. 仮想マシン（１２１〜１２６）が新しいホスト・マシン（１３１、１３２）へと移動された場合、前記仮想マシン（１２１〜１２６）に関するすべての障害イベントを前記障害イベント・テーブル内に配置し、重症度を軽減する（４１３）、前記請求項のいずれか一項に記載の方法。
7. ルート・リンクが除去される（４１３）、請求項６に記載の方法。
8. 前記状況イベント（１８１）は、プローブのイベント警告（１８０）の供給元である監視システム（１５０）によって監視され、仮想マシン（１２１〜１２６）およびホスト・デバイス（１３１、１３２）とホスト障害イベント（１７１）との間の関係の指示を含む、前記請求項のいずれか一項に記載の方法。
9. 前記仮想マシン内の前記障害イベント（１６１）は、前記仮想マシン（１２１〜１２６）上で実行中のプローブ（１６０）によって供給される、前記請求項のいずれか一項に記載の方法。
10. 前記ホスト・マシン（１７１）内の前記障害イベントは、前記ホスト・マシン（１３１、１３２）上で実行中のプローブ（１７０）によって供給される、前記請求項のいずれか一項に記載の方法。
11. 前記ホスト・マシン（１７１）内の前記障害イベントは、プローブのイベント警告（１８０）の供給元である監視システム（１５０）によって監視される、前記請求項のいずれか一項に記載の方法。
12. 仮想コンピューティング環境における障害管理のためのコンピュータ・ソフトウェア製品が提供され、前記製品は、コンピュータ実行可能命令を備えるプログラムが格納されたコンピュータを備え、命令は、コンピュータによって読み取りが実行された場合に、
    仮想コンピューティング環境において仮想マシン（１２１〜１２６）およびホスト・デバイス（１３１、１３２）からの障害イベント（４０１、４０３）を監視するステップと、
    前記仮想コンピューティング環境において状況イベント（４０１）を監視するステップであって、前記状況イベント（４０１）は仮想マシン名およびホスト・デバイス名を言い表すものである、監視するステップと、
    障害イベントが仮想マシン（１２１〜１２６）とホスト・デバイス（１３１、１３２）の両方に影響を与えているかどうかを判別するステップ（５０１〜５１２）と、
    仮想マシン（１２１〜１２６）およびホスト・デバイス（１３１、１３２）に関する障害イベントを同じ問題に関するものとして相関させるステップ（５１２）と、
    を実行する、コンピュータ読み取り可能ストレージ・メディアを備える、コンピュータ・ソフトウェア製品。
13. プロセッサと、
    仮想コンピューティング環境における仮想マシン（１２１〜１２６）およびホスト・デバイス（１３１、１３２）からの障害イベント（１６１、１７１）のモニタ（１６０、１７０）と、
    前記仮想コンピューティング環境における状況イベント（１８１）のモニタ（１５０）であって、前記状況イベント（１８１）は仮想マシン名およびホスト・デバイス名を言い表すものである、モニタと、
    障害イベント（１６１、１７１）が仮想マシン（１２１〜１２６）とホスト・デバイス（１３１、１３２）の両方に影響を与えているかどうかを判別するための正規化コンポーネント（２７１、２６１）と、
    仮想マシンおよびホスト・デバイスに関する障害イベント（１６１、１７１）を同じ問題に関するものとして相関させるための相関コンポーネント（２１０）と、
    を備える、仮想コンピューティング環境における障害管理のためのシステム。
14. 仮想マシン状況テーブル（２３０）と、仮想マシン名およびホスト・デバイス名のマッピング（２５０）と
    を含む、請求項１３に記載のシステム。
15. 仮想マシン（１２１〜１２６）またはホスト・デバイス（１３１、１３２）に関する障害イベントのリストを維持するための障害イベント・テーブル（２４０）
    を含む、請求項１３または１４に記載のシステム。
16. 問題に相関付けられたホスト・マシンの障害イベントに関する前記障害イベント・テーブル（２４０）内のルート・イベント・マーカ（２４３）を含む、請求項１５に記載のシステム。
17. 問題に相関付けられた仮想マシンの障害イベントに関する前記障害イベント・テーブル（２４０）内の症状マーカ（２４５）と、前記障害イベント・テーブル（２４０）内の前記ルート・イベントへのリンク（２４６）とを含む、請求項１５または１６に記載のシステム。
18. 障害解決コンポーネント（２２０）を含み、仮想マシン（１２１〜１２６）が新しいホスト・マシン（１３１、１３２）に移動された場合、前記解決コンポーネント（２２０）は前記仮想マシンに関するすべての障害イベントを前記障害イベント・テーブル（２４０）内に配置し、前記イベントの重症度を軽減する、請求項１３から１８のいずれか一項に記載のシステム。
19. 状況イベント（１８１）に関する前記モニタ（１５０）は、仮想環境クラスタ制御センタ（１３３）から前記状況イベントを取得し、前記障害管理システム（１１０）にイベント警告（１８０）を供給する、請求項１３から１９のいずれか一項に記載のシステム。
20. 障害イベントに関する前記モニタは、前記仮想マシン（１２１〜１２６）上で実行中のプローブ（１６０）である、請求項１３から２０のいずれか一項に記載のシステム。
21. 障害イベントに関する前記モニタは、前記ホスト・マシン（１３１、１３２）上で実行中のプローブ（１７０）である、請求項１３から２１のいずれか一項に記載のシステム。
22. 前記ホスト・マシン（１３１、１３２）内の障害イベント（１７１）に関する前記モニタ（１５０）は、仮想環境クラスタ制御センタ（１３３）から前記障害イベント（１７１）を取得し、前記障害管理システム（１１０）にイベント警告（１８０）を供給する、請求項１３から２２のいずれか一項に記載のシステム。
23. 前記プローブ（１７０）はリモート・マシン上で実行され、ネットワークを介して前記ホスト・マシン（１３１、１３２）を監視する、請求項２１に記載のシステム。
24. コンピュータ読み取り可能メディア上に格納され、デジタル・コンピュータの内部メモリにロード可能な、コンピュータ・プログラムであって、コンピュータ上で実行された場合、請求項１から１１のいずれか一項の方法を実行するためのソフトウェア・コード部分を備える、コンピュータ・プログラム。

Images