JP5079080B2 - ストレージ・エリア・ネットワーク内の障害に対応するデータを収集する方法及びコンピュータ・プログラム - Google Patents

Description

【技術分野】
【０００１】
本願は一般に、改良されたデータ処理システム及び方法に関するものである。より具体的には、本願は、ホスト・システムとストレージ・システムとの間のイン・バンド問題ログ・データ収集システム及び方法を対象とする。
【背景技術】
【０００２】
ストレージ・エリア・ネットワーク（ＳＡＮ）は、ストレージ・ディスクのネットワークである。典型的な大企業における実装では、ＳＡＮは複数のサーバをストレージ・システムの中央プールに接続する。ＳＡＮでは、それぞれ固有のディスクを有する数百ものサーバを管理する場合と比較して、システム管理が改善される。会社のすべてのストレージを単一のリソースとして扱うことにより、ディスクのメンテナンス及び日常的なバックアップをより容易にスケジューリング及び制御することが可能となる。ＳＡＮならびに他のネットワーク・データ処理システムは、アプリケーション、データベース・アプリケーション、ファイル・システム、ホスト・サーバ・システム、ネットワーク・インフラストラクチャ、ストレージ・システムのような複数のレイヤを含む。
【０００３】
現代のＳＡＮ環境では、ＳＡＮ環境が非常に複雑となる傾向にあり、したがって障害のデバッグも非常に困難となる可能性がある。典型的には、ＳＡＮ環境で障害を検出し問題の根本原因を特定するコンポーネントは、障害を経験するコンポーネントとは異なるものとなる。その結果、障害の原因となる問題は、障害が検出された後に解決される場合が多く、また、外部計測機能及びＳＡＮ環境内の各コンポーネントのカスタマイズを利用して解決されることが多い。そのため、データ収集を実施して障害の原因を特定できるようにするために、通常は検出された障害の原因となる状況の「再検査（ｒｅｔｅｓｔ）」、即ち、障害の原因となるＳＡＮ環境の各条件を再現する必要が生じる。そのような再現には、障害の判定された時点に関連する情報についてログ・データ構造をスキャンし、その後様々なログに由来する情報の相関付けを行って、障害発生後に障害時点のシステム状態の実態を把握しようとする試みが含まれる可能性がある。
【発明の概要】
【発明が解決しようとする課題】
【０００４】
障害検出及びデータ収集は、典型的には障害を経験するコンポーネントとは別個のコンポーネントによって実行されるので、複雑なＳＡＮ環境における複数のコンポーネントからのデータ収集では多くの場合、より低速なインターフェースを介した通信及びアクティベーションのレイテンシにより、障害のデバッグに役立つ可能性がある重要情報が見逃される恐れがある。そのため、ＳＡＮ環境の様々なレイヤに所在する遠隔のホスト・システム、スイッチ、又は他のストレージ・デバイスのデータが利用可能でないか、あるいはそのようなデータが収集されても障害の原因となるエラー状態の発生から長時間経過しているということが頻繁に生じる。例えば、ＳＡＮ要素のいくつかのコンポーネント、例えばホスト・バス・アダプタ（ＨＢＡ）・バッファにはごく少量のデータ、例えば一時に数フレームのデータしか記憶されず、障害検出及びデータ収集に使用されるメカニズムの遅延による障害の発生後、かなりの時間が経過するまで障害が検出されず、データ収集が実行されない場合、それらのデータは迅速に上書きされ失われる可能性がある。その結果、既知のＳＡＮ環境のログ能力にも限りがあるため、いくつかの情報が途中で失われることになる。
【課題を解決するための手段】
【０００５】
例示的な一実施形態では、データ処理システム内の障害に対応するデータを収集する方法が提供される。前記方法は、複数のデータ処理システムを備えるネットワーク内に所在するデータ処理システムのコンポーネントの障害状態に関する障害通知を受信するステップを含むことができる。前記方法は更に、イン・バンド状態保存コマンドに応答して前記ネットワーク内の前記複数のデータ処理システムにおいて生成される状態保存データを前記複数のデータ処理システムから受信するステップを含むことができる。前記状態保存データは、前記コンポーネントの前記障害状態の解決時に使用するために出力することができ、前記イン・バンド状態保存コマンドは、前記複数のデータ処理システム内の第１のデータ処理システムと、少なくとも１つの第２のデータ処理システムとの間のデータ・チャネルを介して発行されるコマンドとすることができる。
【０００６】
前記第１のデータ処理システムは、例えばストレージ・システムとすることができ、前記少なくとも１つの第２のデータ処理システムは、例えば少なくとも１つのホスト・システムとすることができる。前記イン・バンド状態保存コマンドは、前記障害状態が前記ストレージ・システム内のストレージ・デバイスの障害であることに応答して、前記ストレージ・システムのストレージ・コントローラから前記少なくとも１つのホスト・システムに送信することができる。前記イン・バンド状態保存コマンドは、複数の各ホスト・システムとの間のデータ・チャネルを確立する、前記ストレージ・システムのマルチ・ホスト・システム・インターフェースを介して前記複数のホスト・システムに対して発行することができる。前記状態保存データは、前記複数の各ホスト・システムによって収集することができ、前記マルチ・ホスト・システム・インターフェースによって確立された前記データ・チャネルを介して前記ストレージ・コントローラに提供することができる。前記複数の各ホスト・システムによって収集された前記状態保存データは、前記ストレージ・システムからの状態保存データと共に、検出された前記障害状態と関連付けられる単一のデータ・パッケージにパッケージングすることができる。
【０００７】
他の例示的な実施形態では、コンピュータに読み込み可能なプログラムを有するコンピュータ使用可能な媒体を備えるコンピュータ・プログラム製品が提供される。前記コンピュータに読み込み可能なプログラムは、それ自体がコンピューティング・デバイス上で実行されたときに、前記方法の例示的な各実施形態に概要が示される様々な処理及びそれらの組合せを前記コンピューティング・デバイスに実行させる。
【０００８】
また別の例示的な実施形態では、システムが提供される。前記システムは、少なくとも１つのホスト・システムと、前記少なくとも１つのホスト・システムと結合されるストレージ・システムとを備えることができる。前記少なくとも１つのホスト・システム又は前記ストレージ・システムあるいはその両方は、前記方法の例示的な各実施形態に概要が示される様々な処理及びそれらの組合せを実行することができる。
【０００９】
本発明の上記及び他の特徴及び利点は、本発明の例示的な諸実施形態に関する以下の詳細な説明に記載されており、この説明を読めばそれらの特徴及び利点が当業者には明らかとなるだろう。
【００１０】
以下では単なる例示として、本発明の好ましい一実施形態について添付図面を参照しながら説明する。
【図面の簡単な説明】
【００１１】
【図１】例示的な諸実施形態の各態様が実施され得るストレージ・エリア・ネットワークを示す図である。
【図２】例示的な諸実施形態の各態様が実施され得る例示的なデータ処理システムのブロック図である。
【図３】ホスト・アプリケーション障害に応答して実行される例示的な諸実施形態に係る基本動作コンポーネントの動作例を示す例示的なブロック図である。
【図４】ストレージ・システム内のストレージ・デバイスの障害に応答して実行される例示的な諸実施形態に係る基本動作コンポーネントの動作例を示す例示的なブロック図である。
【図５】例示的な一実施形態に係るホスト・アプリケーション障害に応答してデータ収集を実行する例示的な処理の概要を示すフローチャートである。
【図６】例示的な一実施形態に係るストレージ・デバイス障害に応答してデータ収集を実行する例示的な処理の概要を示すフローチャートである。
【発明を実施するための形態】
【００１２】
例示的な諸実施形態は、ホスト・システムとストレージ・システムとの間のイン・バンド問題ログ・データを収集するシステム及び方法を提供する。例示的な諸実施形態に係るシステム及び方法は、ストレージ・エリア・ネットワーク（ＳＡＮ）等の分散データ処理環境で実施することができる。そこで、例示的な諸実施形態に係る基本動作コンポーネントの理解を与える文脈として、以下では、例示的な諸実施形態の例示的な諸態様が実施され得る例示的なデータ処理環境及び例示的なデータ処理デバイスについて、図１及び図２を参照して説明する。図３は、例示的な諸実施形態の各メカニズムによってデータが収集され得るストレージ・エリア・ネットワークの複数のレイヤの一例として示される。
【００１３】
ここで添付図面、特に図１及び図２を参照すると、本発明の諸態様が実施され得るデータ処理環境が例示されている。図１及び図２は単なる例示にすぎず、本発明の諸態様又は諸実施形態が実施され得る環境を限定することを主張するものではなく、そのように暗示することも意図しているわけではないことを理解していただきたい。図示の環境には、本発明の趣旨及び範囲から逸脱しない限り様々な変更を施すことができる。
【００１４】
ここで添付図面を参照すると、図１には、例示的な諸実施形態の各態様が実施され得るストレージ・エリア・ネットワークが図示されている。ストレージ・エリア・ネットワーク（ＳＡＮ）１００は、ＳＡＮ １００内のルーティング・インフラストラクチャを集中的に提供する相互接続スイッチの組合せであるＳＡＮファブリック１０２を含む。
【００１５】
図示の例において、ホスト１１０は、ストレージ・システム又はデバイス１２０と共にＳＡＮファブリック１０２に接続されている。ホスト１１０は、例えばパーソナル・コンピュータ、ネットワーク・コンピュータ、サーバ等であってよい。図示の例において、ホスト１１０は、ＳＡＮファブリック内の経路を通ってストレージ・システム／デバイス１２０にアクセスする。ＳＡＮ １００は、図示されていない追加的なホスト又は他のストレージ・デバイスあるいはその両方を含むことができる。図１は一例であり、本発明のアーキテクチャ上の限定を示すものではない。
【００１６】
ＳＡＮファブリック１０２は、ＳＡＮ １００内で互いに接続される様々なデバイスとコンピュータとの間の通信リンクを提供するのに使用される媒体である。ＳＡＮファブリック１０２は、有線、無線、通信リンク、光ファイバ・ケーブル等の接続を含むことができる。一実施形態において、ＳＡＮファブリック１０２は、伝送制御プロトコル／インターネット・プロトコル（ＴＣＰ／ＩＰ）・プロトコル・スイートを使用して互いに通信するネットワーク及びゲートウェイの集合とすることができる。言うまでもなく、ＳＡＮファブリック１０２は、例えばファイバ・チャネル、イーサネット（Ｒ）、シリアル・アタッチド小型コンピュータ・システム・インターフェース（シリアル・アタッチドＳＣＳＩ又はＳＡＳ）等、いくつかの様々なタイプのネットワークを含むように実装することもできる。実際、現在の多くのＳＡＮではデータ転送にファイバ・チャネルが使用され、管理情報の通信にイーサネットが使用されている。
【００１７】
上述のとおり、図１は本発明の様々な実施形態のアーキテクチャ上の限定ではなく一例として示されるものであり、したがって、図１に示される具体的な各要素も本発明の例示的な諸実施形態が実施され得る環境を限定するものと解釈すべきではない。
【００１８】
次に図２を参照すると、例示的な諸実施形態の各態様が実施され得る例示的なデータ処理システムのブロック図が示されている。データ処理システム２００は、本発明の例示的な諸実施形態に関する処理を実行するコンピュータ使用可能なコード又は命令が配置され得る図１のホスト１１０のようなコンピュータの一例である。
【００１９】
図示の例において、データ処理システム２００は、ノース・ブリッジ及びメモリ・コントローラ・ハブ（ＮＢ／ＭＣＨ）２０２と、サウス・ブリッジ及び入力／出力（Ｉ／Ｏ）コントローラ・ハブ（ＳＢ／ＩＣＨ）２０４とを含むハブ・アーキテクチャを利用している。処理ユニット２０６、メイン・メモリ２０８、及びグラフィックス・プロセッサ２１０は、ＮＢ／ＭＣＨ ２０２に接続されている。グラフィックス・プロセッサ２１０は、高速グラフィックス・ポート（ＡＧＰ）を介してＮＢ／ＭＣＨ ２０２に接続することができる。
【００２０】
図示の例において、ローカル・エリア・ネットワーク（ＬＡＮ）アダプタ２１２は、ＳＢ／ＩＣＨ ２０４に接続されている。オーディオ・アダプタ２１６、キーボード及びマウス・アダプタ２２０、モデム２２２、読み取り専用メモリ（ＲＯＭ）２２４、ユニバーサル・シリアル・バス（ＵＳＢ）ポート及び他の通信ポート２３２、ならびにＰＣＩ／ＰＣＩｅデバイス２３４は、バス２３８を介してＳＢ／ＩＣＨ ２０４に接続されており、ハード・ディスク・ドライブ（ＨＤＤ）２２６及びＣＤ‐ＲＯＭドライブ２３０は、バス２４０を介してＳＢ／ＩＣＨ ２０４に接続されている。ＰＣＩ／ＰＣＩｅデバイスとしては、例えばイーサネット（Ｒ）アダプタ、アドイン・カード、及びノート型コンピュータ用ＰＣカード等を挙げることができる。ＰＣＩはカード・バス・コントローラを使用するが、ＰＣＩｅはこれを使用しない。ＲＯＭ ２２４は、例えばフラッシュ・バイナリ入力／出力システム（ＢＩＯＳ）等であってもよい。
【００２１】
ＨＤＤ ２２６及びＣＤ‐ＲＯＭドライブ２３０は、バス２４０を介してＳＢ／ＩＣＨ ２０４に接続されている。ＨＤＤ ２２６及びＣＤ‐ＲＯＭドライブ２３０は、例えば統合ドライブ・エレクトロニクス（ＩＤＥ）やシリアル・アドバンスト・テクノロジー・アタッチメント（ＳＡＴＡ）・インターフェース等を使用することができる。スーパーＩ／Ｏ（ＳＩＯ）デバイス２３６は、ＳＢ／ＩＣＨ ２０４に接続することができる。
【００２２】
オペレーティング・システムは、処理ユニット２０６上で実行される。上記オペレーティング・システムは、図２のデータ処理システム２００内の様々なコンポーネントの制御を調整し実行する。クライアントとしてのオペレーティング・システムは、Ｍｉｃｒｏｓｏｆｔ（Ｒ）Ｗｉｎｄｏｗｓ（Ｒ）ＸＰのような市販のオペレーティング・システムであってもよい（「Ｍｉｃｒｏｓｏｆｔ」及び「Ｗｉｎｄｏｗｓ」は、マイクロソフト・コーポレーションの米国その他の国、又はその両方における商標である）。Ｊａｖａ（ＴＭ）プログラミング・システムのようなオブジェクト指向プログラミング・システムは、上記オペレーティング・システムと連動させることができ、データ処理システム２００上で実行されているＪａｖａ（ＴＭ）プログラム又はアプリケーションから当該オペレーティング・システムをコールするものである（「Ｊａｖａ」は、サン・マイクロシステムズの米国その他の国、又はその両方における商標である）。
【００２３】
サーバとしてのデータ処理システム２００は、例えば拡張対話式エグゼクティブ（Ａｄｖａｎｃｅｄ Ｉｎｔｅｒａｃｔｉｖｅ Ｅｘｅｃｕｔｉｖｅ：ＡＩＸ（Ｒ））オペレーティング・システム又はＬＩＮＵＸ（Ｒ）オペレーティング・システムを実行するＩＢＭ（Ｒ）ｅＳｅｒｖｅｒ（ＴＭ）ｐＳｅｒｉｅｓ（Ｒ）コンピュータ・システムであってもよい（「ｅＳｅｒｖｅｒ」、「ｐＳｅｒｉｅｓ」、及び「ＡＩＸ」は、インターナショナル・ビジネス・マシーンズ・コーポレーションの米国その他の国、又はその両方における商標であり、「Ｌｉｎｕｘ」は、Ｌｉｎｕｓ Ｔｏｒｖａｌｄｓ氏の米国その他の国、又はその両方における商標である）。データ処理システム２００は、複数のプロセッサを処理ユニット２０６内に含む対称型マルチプロセッサ（ＳＭＰ）システムであってもよい。別法として、シングル・プロセッサ・システムを採用することもできる。
【００２４】
上記オペレーティング・システム、オブジェクト指向プログラミング・システム、及びアプリケーション又はプログラムに関する命令は、ＨＤＤ ２２６のようなストレージ・デバイス上に配置され、処理ユニット２０６による実行のためにメイン・メモリ２０８にロードすることができる。本発明の例示的な諸実施形態の各処理は、例えばメイン・メモリ２０８やＲＯＭ ２２４等のメモリ内に配置されても、１つ又は複数の周辺デバイス２２６及び２３０内に配置されてもよい、コンピュータ使用可能なプログラム・コードを使用して処理ユニット２０６によって実行することができる。
【００２５】
バス・システムは、図２に示されるバス２３８やバス２４０のような１つ又は複数のバスから構成することができる。言うまでもなく、上記バス・システムは、通信ファブリック又はアーキテクチャであって、当該ファブリック又はアーキテクチャに取り付けられた様々なコンポーネント又はデバイス間でデータ転送を行う任意のタイプの通信ファブリック又はアーキテクチャを使用して実装することができる。図２のモデム２２２やネットワーク・アダプタ２１２のような通信ユニットは、データの送受信に使用される１つ又は複数のデバイスを含むことができる。メモリは、例えば図２のＮＢ／ＭＣＨ ２０２内で見受けられるようなメイン・メモリ２０８、ＲＯＭ ２２４、キャッシュ等であってもよい。
【００２６】
図１及び図２のハードウェアは実装形態に応じて変更され得ることが当業者には理解されるだろう。図１及び図２に示されるハードウェアに加えて又はその代わりに、フラッシュ・メモリや同等の不揮発性メモリ、あるいは光ディスク・ドライブ等、他の内部ハードウェア又は周辺デバイスを使用することもできる。また、本発明の例示的な諸実施形態の各処理は、本発明の趣旨及び範囲から逸脱しない限り、前述のＳＭＰシステム以外のマルチプロセッサ・データ処理システムにも適用することができる。
【００２７】
更に、データ処理システム２００は、クライアント・コンピューティング・デバイス、サーバ・コンピューティング・デバイス、タブレット・コンピュータ、ラップトップ・コンピュータ、電話又は他の通信デバイス、携帯情報端末（ＰＤＡ）等を含めたいくつかの異なるデータ処理システムのうちの任意の形をとることができる。いくつかの実例において、データ処理システム２００は、オペレーティング・システム・ファイル又はユーザ生成データあるいはその両方を記憶する不揮発性メモリを提供するフラッシュ・メモリが組み込まれた携帯型コンピューティング・デバイスであってもよい。データ処理システム２００は事実上、アーキテクチャ上の限定を伴わない既知の又は将来開発される任意のデータ処理システムとすることができる。
【００２８】
再び図１を参照すると、ＳＡＮ １００内のコンポーネントの障害が発生した場合は、典型的にはその障害を経験しているコンポーネントの外部に所在するＳＡＮ １００のコンポーネントが障害を検出し、デバッグ用のデータ収集を開始しなければならない。その結果、デバッグ用に収集されるデータは障害の原因となるエラー状態の発生から長時間経過してから収集される場合が多く、また、ＳＡＮコンポーネントのログ能力の制約により、いくつかの情報がレイテンシ期間中に失われる恐れもある。
【００２９】
例示的な諸実施形態は、ホスト・アプリケーションの障害発生時に、ホスト１１０のようなホスト・システムがホスト・システム１１０とストレージ・システム１２０の両方に対する「状態保存（ｓｔａｔｅ ｓａｖｅ）」処理を開始することが可能となるメカニズムを提供する。更に、例示的な諸実施形態は、ストレージ・システム１２０のようなストレージ・システム内のストレージ・デバイスの障害が検出されたことに応答して、ストレージ・システム１２０が複数のホスト・システムであることもあるホスト・システム１１０とストレージ・システム１２０の両方に対する「状態保存」処理を開始することが可能となるメカニズムを提供する。
【００３０】
以下ではいくつかの処理を実行するホスト・システム１１０及びストレージ・システム１２０の特定の要素に関して例示的な諸実施形態の説明を行うが、これらは単に本発明の可能な実施形態を例示するものにすぎず、また、本明細書に記載の処理を実行することが可能な要素を限定することを主張するものではなく、そのように暗示することも意図しているわけではないことを理解していただきたい。それ故、例えばストレージ・システム１２０のストレージ・コントローラによる処理は、ホスト・システム１１０上で実行されるドライバでも同様に実行することができ、逆もまた同様に実行することができる。更に、後で例示的な諸実施形態に関して概要が示される様々な処理を実行する、ホスト・システム又はストレージ・システムに由来する別個のデバイスを提供することもできる。本明細書を読めば当業者には容易に理解されるように、例示的な諸実施形態には本発明の趣旨及び範囲を逸脱しない限り他の修正を施すことが可能である。
【００３１】
また、例示的な諸実施形態は、ストレージ・システムと１つ又は複数のホスト・システムとの間のストレージ・エリア・ネットワーク（ＳＡＮ）における状態保存処理に関して説明されているが、各実施形態及び本発明はそのように限定されるものではないことを理解していただきたい。むしろ、例示的な諸実施形態の各メカニズムは、例えば障害発生時に状態保存処理が望まれるサーバ・システム、クライアント・デバイス、ワークステーション等のデータ処理システム又はデバイスあるいはその両方から構成される任意のネットワークと共に利用することが可能である。それ故、本発明はホスト・システム及びストレージ・システム内の状態保存処理に限定されるものではなく、本発明の趣旨及び範囲には他の環境も含まれるものと見なされる。
【００３２】
例示的な諸実施形態では、「状態保存」処理、即ちすべてのレジスタのうちの１つ又は複数をログ・ファイルにダンプする処理は、イン・バンド・コマンドを用いて開始される。イン・バンド・コマンドとは、通信プロトコル・インフラストラクチャ内で主要コード・パス（ｐｒｉｍｅ ｃｏｄｅ ｐａｔｈ）の一部として生成され、障害時点とほぼ同時にすべてのコンポーネントのポイント・イン・タイム・フリーズ（ｐｏｉｎｔ‐ｉｎ‐ｔｉｍｅ ｆｒｅｅｚｅ）をもたらすコマンドを指す。これらのコマンドは、ホスト・システム及びストレージ・システムに対して、既知のシステムの場合のように障害検出後しばらく経ってからデータ収集が実行され得る外部コンポーネントを利用するのではなく、当初の障害時点でデータ収集を実行するよう指示するものである。このデータ収集は、障害発生後ほぼ即時に又はほぼ実時間でＳＡＮ内の複数のコンポーネントにわたって実行することができる。その結果、データ収集を実行する時間フレームが可能な限り実際の障害に近付くため、「状態保存」処理で収集され得る障害時点の実際の状態に関連するデータ量が最大化される。
【００３３】
例示的な一実施形態では、エラー又は障害に応答して、例えばストレージ・システム１２０等のストレージ・システム内の状態保存処理を直接コマンドを利用して促すファシリティが、ホスト・システム１１０、ホスト・アプリケーション、サーバ・システム等に提供される。例示的な一実施形態において、ホスト・システム１１０は、ホスト・システム・ログと連動する特定の時点でストレージ・システム１２０にデバッグ用の１組の状態保存データを収集させるアプリケーション・プログラム・インターフェース（ＡＰＩ）を含む。
【００３４】
例示的な諸実施形態に係る本ＡＰＩは、例えばフェイルオーバ・ドライバ又はホスト・バス・アダプタ（ＨＢＡ）あるいはその両方に含めることができる。そのため、本ＡＰＩは、エラー又は障害の初期検出時に利用可能なデータ量を増加させることによって当該エラー又は障害後の初期データ・キャプチャが最大化されるように、主要コード・パスに提供することができる。本ＡＰＩは、ストレージ・システム１２０に状態保存処理を要求するコマンドの交換機能を提供する。ストレージ・システム１２０は、通信チャネルＡＰＩ、例えばイーサネット又はファイバ・チャネルＡＰＩを利用してコマンドを受信し処理する。
【００３５】
ストレージ・システム１２０に含まれるロジックは、ストレージ・システム１２０が状態保存コマンドで過飽和状態に陥るのを回避するために、状態保存処理が所定の期間内に既に実行されているかどうかを判定する頻度機能を含むことができる。ホスト・システム１１０上では、ストレージ・システム１２０又はストレージ・システム１２０内のストレージ・デバイス（単数又は複数）が行った状態保存処理の詳細と、収集された状態保存データ・ファイルの名前とを有するホスト・ログを生成することができる。
【００３６】
例示的な諸実施形態は更に、ストレージ障害デバッグ用のデータ収集アクティビティ中にホスト・システム１１０によって例えばストレージ・システム１２０等のストレージ・システムとの通信に使用されるデータ・チャネルを利用して、ホスト側ログ及びデータの要求及び転送を行うデータ収集用ファシリティも提供する。例示的な諸実施形態に係るシステム及び方法は、フェイルオーバ・ドライバを利用してホスト・システム・ログ、フェイルオーバ・ドライバ・ログ、ホスト構成データ、ファームウェア／ソフトウェア・レベル、及び基本構成データを収集し、当該データをストレージ・システム１２０に転送する。その後、ストレージ・システム１２０は、問題の判定及び障害状態の解決のために、ホスト・システム・データをそれ自体の状態保存データの一部としてパッケージングすることができる。
【００３７】
フェイルオーバ・ドライバ内のＡＰＩは、ストレージ・システムから送信されるデータ収集ストレージ・コマンドを認識することができ、例えばホスト・システム・ログやフェイルオーバ・ドライバ・ログ等のホスト側状態保存データ・セットを独自に一時ディレクトリのアーカイブ・ファイルに収集することが可能となる。その後、フェイルオーバ・ドライバ内のＡＰＩはストレージ・デバイスと交渉して、データ・チャネルのオープン及びアーカイブ・ファイルの転送を求めることができる。
【００３８】
ストレージ・システム１２０のデータ収集を支援するために、複数のホスト・システム１１０のホスト・フェイルオーバ・ドライバに対するコマンドと相互作用することが可能なマルチ・ホスト・インターフェース・システムが含まれている。このマルチ・ホスト・インターフェース・システムは、データ要求を処理し、ホスト・システム１１０からデータを転送するためのデータ・チャネルをオープンするものである。ストレージ・システム１２０は、記憶媒体上、例えばハード・ディスク上の一時記憶位置を作成して、場合によっては複数のホスト・システム１１０に由来する状態保存データを一時的に記憶することができ、その後すべてのストレージ・システム状態データをホスト・システム状態データと共にパッケージングすることができる。マルチ・ホスト・インターフェース・システムは更に、収集されたホスト・システム及びストレージ・システム状態データ・パッケージをストレージ・システム障害のデバッグ時に使用するためにクライアント・システムに転送するファシリティも提供する。
【００３９】
それ故、上述のとおり、既知の障害データ収集方法よりも優れた例示的な諸実施形態の利点の１つは、各実施形態で実施されるデータ収集が当初の障害時点で実行される点にある。例示的な諸実施形態では、障害を検出しデータ収集を実行するために、障害に関与するコンポーネントの外部に所在するＳＡＮ内のコンポーネントを使用するのではなく、ホスト・システムとストレージ・システムとの間の通信経路内に各メカニズムが提供される。これらのメカニズムは、例えばホスト・バス・アダプタ（ＨＢＡ）・バッファのようなごく短期間のトレース（ｔｒａｃｅ）だけが残るレジスタ等のコンポーネントを含めたシステム・コンポーネントからデータが収集されるときに、すべてのコンポーネントにおいてホスト・システム又はストレージ・システムあるいはその両方を強制的に休止させる。それ故、例示的な諸実施形態に係る各メカニズムは、障害発生時に短期間のトレース情報を直ちに収集することができるような形でデータ収集を実行する。
【００４０】
図３は、ホスト・アプリケーションの障害に応答して実行される基本動作コンポーネントの動作例を示す例示的なブロック図である。図３に示される各動作コンポーネントは、ハードウェアの形で実装することもソフトウェアの形で実装することもでき、ハードウェアとソフトウェアの任意の組合せの形で実装することもできることを理解していただきたい。好ましい一実施形態において、各動作コンポーネントは、１つ又は複数のプロセッサによって実行されるソフトウェア命令として実装される。
【００４１】
図３に示されるように、ストレージ・エリア・ネットワーク（ＳＡＮ）３００は、複数のホスト・システム３１０〜３３０ならびに複数のストレージ・システム３４０、３９２、及び３９４から構成され得る。説明の便宜上、図３には１つのストレージ・システム、即ちストレージ・システム３４０だけが詳細に示されている。
【００４２】
図３に示されるように、ストレージ・システム３４０は、複数のストレージ・デバイス３４２〜３４８と、ストレージ・コントローラ３５０と、ストレージ・コントローラ３５０内に設けられるマルチ・ホスト・インターフェース３６０とを含む。ストレージ・システム３４０のストレージ・コントローラ３５０は更に、例えばホスト・システム３１０〜３３０から状態保存コマンドを受信するイーサネット又はファイバ・チャネルＡＰＩとして提供され得るアプリケーション・プログラム・インターフェース（ＡＰＩ）３７０も含むことができる。ストレージ・デバイス３４２〜３４８のうちの１つ又は複数では、ストレージ・システム３４０、及びホスト・システム３１０〜３３０のうちの１つ又は複数から収集される状態保存データを記憶するための状態保存データ構造が提供される。
【００４３】
ホスト・システム３１０〜３３０は、ホスト・バス・アダプタ（ＨＢＡ）・ドライバ３１４、３２４、３３４と、フェイルオーバ・ドライバ３１２、３２２、３３２とを含む。ＨＢＡドライバ３１４、３２４、３３４、及びフェイルオーバ・ドライバ３１２、３２２、３３２は、マイクロコードの形で提供され、ストレージ・システム３４０内のストレージ・デバイス３４２〜３４８における状態保存処理の実行を要求するコマンドの交換を可能にするＡＰＩを含む。例えば、フェイルオーバ・ドライバ３１２、３２２、及び３３２は、ストレージ・デバイス３４２〜３４８と通信して状態保存処理を開始するよう命令する「状態保存取得（ｔａｋｅ ａ ｓｔａｔｅ ｓａｖｅ）」コマンドを各ストレージ・デバイスに引き渡すＡＰＩ／ＣＩＭＯＭを有することができる。
【００４４】
動作において、ホスト・システム３１０〜３３０は、ストレージ・システム３４０内のストレージ・デバイス３４２〜３４８にアクセスすることが可能な様々なアプリケーションを実行する。アプリケーションの実行中は、アプリケーション・インスタンス内で障害が発生する可能性があり、その結果、障害を引き起こしたエラー原因をデバッグする際、又はその他の方法でエラー原因を特定する際に使用されるホスト・システム３１０〜３３０及びストレージ・システム３４０の状態に関するデータを収集する必要が生じる。フェイルオーバ・ドライバ３１２、３２２、及び３３２のマイクロコードＡＰＩは、アプリケーションの障害を検出し、データ収集を実行するＨＢＡドライバ３１４、３２４、及び３３４に対して状態保存コマンドを発行する機能を提供する。
【００４５】
典型的なシステムでは、障害が検出されるとその旨がホスト・システム・ログにレポートされるが、ホスト・システムが障害データを得るまでに典型的には数分又は数時間のタイム・ラグが存在する。例示的な諸実施形態の各メカニズムを用いると、障害検出後ほぼ即時に状態保存が実行される。これにより、根本的原因を分析するための最大限のデータが収集される確率が高まる。
【００４６】
ＨＢＡドライバ３１４、３２４、及び３３４のマイクロコードＡＰＩは、１つ又は複数のスイッチやルータ等を備えるデータ・ネットワークやＳＡＮファブリック、例えば図１のＳＡＮファブリック１０２等の転送媒体（ｔｒａｎｓｐｏｒｔ ｍｅｄｉａ）３９０を介して、状態保存コマンドをストレージ・システム３４０に対して発行する機能を提供する。そのような状態保存コマンドは、ＨＢＡドライバ３１４、３２４、及び３３４から既存のイーサネット又はファイバ・チャネル・データ・チャネルを介してストレージ・システム３４０に直接送信される「イン・バンド」コマンドである。「イン・バンド」という用語は、データ・チャネルと同一の経路内でコマンドを送ることができる能力を指す。既知のシステムは、アウト・オブ・バンド（ｏｕｔ‐ｏｆ‐ｂａｎｄ）方法を使用する。即ち、エラーはファイバ・チャネル・アダプタ・チャネルにおいて検出され、データ収集コマンドは、当該データ・チャネルの外部のイーサネット・コマンド経路、即ちファイバ・チャネル・アダプタ・チャネルによって送られる。このため、冗長経路及び追加的な接続の保守が必要となり、それに伴うレイテンシも発生する。
【００４７】
既知のシステムにおいて、エラー・ログは、手動スクリプトを使用してイベント・トリガ・スイッチによってコード単位（ｉｎ ｃｏｄｅ）で受動的に監視される。その結果、かなりのレイテンシが導入される。本明細書に記載の例示的な諸実施形態では、印刷出力及び応答に数秒かかる可能性がある受動的なエラー・ログ監視を間接的に経由することなく、エラー検出と同時に活性化されるようなロジックが、エラー経路の一部となるドライバ・スタック内に提供される。
【００４８】
それ故、例えばフェイルオーバ・ドライバ３１２によってホスト・システム３１０内のアプリケーション・インスタンス３１８の障害が検出された場合、フェイルオーバ・ドライバ３１２は、ホスト・システム３１０とストレージ・システム３４０との間のデータ・チャネルを介してＨＢＡドライバ３１４に状態保存処理コマンドを直ちに送信する。この状態保存処理コマンドは、ＨＢＡドライバ３１４にホスト・システム３１０内の処理を直ちに休止させ、様々なホスト・システム状態データ、例えばホスト・システム・ログ、フェイルオーバ・ドライバ・ログ、ホスト構成データ、ファームウェア／ソフトウェア・レベル、基本構成データ、ＨＢＡレジスタ情報、アプリケーション・ログ情報等のデータ収集を実行させる。このような休止は本質的に、ホスト・システム３１０にそれ自体の現在の状態を短時間、例えば数ミリ秒維持させるものであるが、その間にレジスタ及びインフライト（ｉｎ‐ｆｌｉｇｈｔ）・ログ情報を記憶することが可能となる。この短い休止時間間隔の間に何らかの処理が試行された場合は、「ビジー（ｂｕｓｙ）」応答を返すことができ、後で再試行を行うことができる。
【００４９】
この処理はホスト・システム３１０内の障害発生後ほぼ即時に実行され、その障害を経験しているホスト・システム３１０内で開始されるので、データ収集では、フェイルオーバ・ドライバ３１２の存在により、典型的には一時に数フレームのデータしか記憶せず、したがって迅速に上書きされる可能性があるＨＢＡバッファのようにごく短期間のトレースだけが残るホスト・システム３１０内のデバイスからもデータを収集することが可能となる。既知のシステムでは外部デバイスを利用して障害が検出されデータ収集が開始され、それに起因するレイテンシが発生するため、そのような短期間のトレース・データは、データ収集が実行されるまでに失われる恐れがある。
【００５０】
フェイルオーバ・ドライバ３１２から状態保存コマンドが受信されたことに応答してデータ収集を開始することに加えて、ＨＢＡドライバ３１４は更に、転送媒体３９０を介してストレージ・システム３４０に状態保存コマンドを送信する。ストレージ・システム３４０に送信される状態保存コマンドは、依然として動作状態にある、ホスト・システム３１０とストレージ・システム３４０との間の既存のイーサネット／ファイバ・チャネル接続を介して送信される直接コマンドである。ストレージ・システム３４０に送信される状態保存コマンドは、ホスト・システム３１０内に設けられたイーサネット／ファイバ・チャネル要素から送信され、ストレージ・システム３４０側のイーサネット／ファイバ・チャネル要素によって受信される「イン・バンド」コマンドである。
【００５１】
ストレージ・システム３４０は、状態保存コマンドをストレージ・コントローラ３５０内のイーサネット／ファイバ・チャネルＡＰＩ ３７０において受信する。イーサネット／ファイバ・チャネルＡＰＩ ３７０は、状態保存コマンドを処理してストレージ・システム３４０でのデータ収集を実行する。この処理の一環として、イーサネット／ファイバ・チャネルＡＰＩ ３７０は、頻度判定を実行してホスト・システム３１０からの状態保存コマンドが所定の期間内に既に処理されているかどうかを判定することができる。このようにして、イーサネット／ファイバ・チャネルＡＰＩ ３７０は、ストレージ・デバイス３４２〜３４８のうちの１つ又は複数が状態保存要求で過飽和状態に陥るのを回避する。ストレージ・システム３４０からの状態保存コマンドが所定の期間内にイーサネット／ファイバ・チャネルＡＰＩ ３７０によって事前に受信されている場合は、障害の検出に応答して別の状態保存処理を実行することができない。
【００５２】
イーサネット／ファイバ・チャネルＡＰＩ ３７０は、状態保存コマンドを送信したホスト・システム３１０に関連するストレージ・デバイス３４２〜３４８を特定し、その後特定されたホスト・システム３１０に関連するストレージ・デバイス３４２〜３４８のうちの１つ又は複数の休止、あるいはポイント・イン・タイム・フリーズを開始することができる。この場合も、休止又はポイント・イン・タイム・フリーズは、ストレージ・デバイス３４２〜３４８の状態をキャプチャすることができるようにストレージ・デバイス３４２〜３４８のアクティビティを短時間（数ミリ秒）休止させ、例えば各デバイスは「ビジー」応答を返す。休止期間が終了するとすべてのアクティビティが再試行される。
【００５３】
ホスト・システム３１０に関連するストレージ・デバイス３４２〜３４８が休止されると、イーサネット／ファイバ・チャネルＡＰＩ ３７０は、特定されたストレージ・デバイス３４２〜３４８のうちの１つ又は複数に関する状態保存処理、例えばレジスタ値のダンプを開始し、それによって別のストレージ・デバイス、例えばストレージ・デバイス３４８の一時記憶位置、あるいは別個の一時ストレージ・デバイス（図示せず）の一時記憶位置にストレージ・システム・ログ・ファイルを生成することができる。このようにして、ホスト・システム３１０内の障害時点とほぼ同時に、ホスト・システム３１０に関連するストレージ・デバイス３４２〜３４８のうちの１つ又は複数のレジスタ値を後の障害原因のデバッグで使用するために保存しておくことができる。
【００５４】
イーサネット／ファイバ・チャネルＡＰＩ ３７０は、ストレージ・システム状態保存ログ・データ構造と、ストレージ・システム３４０によって作成された状態保存ログ・データ構造の名前とに関して、どのストレージ・デバイス３４２〜３４８（単数又は複数）からデータが収集されたかに関する詳細をホスト・システム３１０に報告することができる。これらの情報は、データ収集の位置及び情報がそれぞれのホスト・ログ・データ構造でユーザに知らされるように、ホスト・システム３１０に報告することができる。このようにして、障害発生の追加的なインジケーション（ｉｎｄｉｃａｔｉｏｎ）がユーザに提示され、その障害に関連するデータがストレージ・システム上のどこにあるかを示すインジケーションも提示することが可能となる。これらの情報を使用して、障害時間ならびにそれ自体の一部としてどのデータ・ファイルを収集すべきかを示すプロブレム・チケット（ｐｒｏｂｌｅｍ ｔｉｃｋｅｔ）を生成することができる。このプロブレム・チケットもアプリケーションのデバッグに役立つ可能性がある。
【００５５】
そのため、フェイルオーバ・ドライバ３１２からの状態保存コマンドに応答してＨＢＡドライバ３１４によってホスト・システム３１０から収集された状態保存データと共に、データ収集元となる１つ又は複数のストレージ・デバイス３４２〜３４８を特定する情報をホスト・ログ・データ構造に記憶することができる。このようにして、障害デバッグを実行するときにホスト・ログ・データ構造を使用してストレージ・システムの状態保存ログ・データ構造にアクセスすることができる。その後、このホスト・ログ・データ構造は、既知の又は将来開発される障害デバッグ方法に従って実行される障害デバッグで使用するために、転送媒体３９０等を介してクライアント・デバイス３９５に送信することができる。
【００５６】
別法として、ストレージ・システム３４０からそれ自体の状態保存ログ・データ構造に関する情報が返されたことに応答して、ホスト・システム３１０は、それ自体のログ・データ構造を、ストレージ・システム３４０の状態保存ログ・データ構造と共にパッケージングするためにストレージ・システム３４０に送信することができる。その結果得られたパッケージは、例えば転送媒体３９０を介してクライアント・デバイス３９５に送信して後の障害デバッグ等で使用するために、ストレージ・システム３４０内のストレージ・デバイス、例えばストレージ・デバイス３４８に記憶しておくことができる。
【００５７】
それ故、図３に概要が示される上記の処理及びメカニズムを用いれば、ホスト・システム３１０上のアプリケーション・インスタンス３１８の障害が発生した場合も、ホスト・システム３１０内の障害検出後ほぼ即時にデータ収集を実行することができる。その結果、データ損失が経験される可能性は低くなる。更に、状態保存コマンドはイーサネット／ファイバ・チャネル・メカニズムの直接コマンドを利用してストレージ・システム３４０に送信されるため、状態保存コマンドの送信で経験されるレイテンシは最小限に抑えられ、また、ホスト・システム３１０に関連するストレージ・デバイス３４２〜３４８のうち、障害を経験した１つ又は複数のストレージ・デバイスをホスト・システム３１０内の障害検出後ほぼ即時に休止させることができる。その後、それらの１つ又は複数のストレージ・デバイス３４２〜３４８に対して状態保存処理を実行することができる。
【００５８】
このようにして、最大限の状態データを収集することができ、それらの状態データは、ホスト・システム３１０内で検出された障害の特定のポイント・イン・タイムと既に相関付けられているログ・データ構造にコンパイルすることができる。これらのログ・データ構造は、障害に直接関係する情報で構成される単一のパッケージが提供されるように一緒にパッケージングすることができる。パッケージングされたデータはその時点で、ホスト・システム３１０内で検出された障害のポイント・イン・タイムに関連するデータであることが保証されるので、障害の一時点に対応するエントリを特定するために、既知のシステムで実行されるようにログ・ファイルをスキャンする必要はない。
【００５９】
図４は、ストレージ・システム内のストレージ・デバイスの障害に応答して実行される例示的な諸実施形態に係る基本動作コンポーネントの動作例を示す例示的なブロック図である。図４に示される各コンポーネントは、図３に示されるのと本質的に同じである。ただし、図４の処理は、ストレージ・システム３４０内のストレージ・デバイス３４２〜３４８の障害がストレージ・システム３４０によって検出されたことに応答して実行される。ＳＡＮ ３００内では、障害が発生し得る場所に応じて図３と図４の両方に示される処理を実行することができることを理解していただきたい。
【００６０】
図４に示されるように、ＳＡＮ ３００の通常動作中のある時点で、ストレージ・システム３４０内のストレージ・デバイス、例えばストレージ・デバイス３４２の障害が発生する可能性があるそのような障害の例としては、ストレージ・コントローラの再起動、経路又は接続損失、複数のドライブ障害、データ・アクセスを妨げる過渡的なコード・ハング／バグ等を挙げることができる。
【００６１】
ストレージ・システム３４０及びそのストレージ・デバイス３４２〜３４８を管理するストレージ・コントローラ３５０は、いくつかの異なる手法のいずれかによってこのストレージ・デバイス３４２の障害を検出することができる。例えば、ストレージ・コントローラ３５０は、ストレージ・デバイス３４２のピング（ｐｉｎｇ）を実行して応答が受信されるかどうか判定することができる。障害の検出にはハートビート信号ベースのメカニズムを利用することもできる。ストレージ・デバイスからの通信が所定の期間内に受信されなかったときを検出するタイムアウト・メカニズムを利用することもできる。本発明の趣旨及び範囲から逸脱しない限り、ストレージ・デバイス３４２の障害検出には既知の又は将来開発される任意のメカニズムを利用することができる。
【００６２】
ストレージ・デバイス３４２の障害が検出されたことに応答して、例えばストレージ・コントローラ３５０は、それ自体の内部ロジックに従って、それ自体のマルチ・ホスト・インターフェース３６０を介してホスト・システム３１０〜３３０に対して状態保存コマンドを発行する。マルチ・ホスト・インターフェース３６０は、ホスト・システム３１０〜３３０からストレージ・システム３４０にホスト状態保存データを送信するためのデータ・チャネルがホスト・システム３１０〜３３０との間でまだ確立されていない場合は、そのデータ・チャネルを確立することができる。当業界では、上記のようなイーサネット／ファイバ・チャネルを利用したデータ・チャネルの確立が一般に知られている。
【００６３】
マルチ・ホスト・インターフェース３６０は、確立されたデータ・チャネルを介して、それぞれの状態の休止又はポイント・イン・タイム・フリーズを実行し、状態保存処理を実行するよう要求するイン・バンド状態保存コマンドをホスト・システム３１０〜３３０に送信する。一方、ストレージ・コントローラ３５０は、障害を起こしたストレージ・デバイス３４２に関するストレージ・システム３４０内の状態保存処理を開始する。即ち、ストレージ・コントローラ３５０は、ストレージ・デバイス３４２〜３４８を休止させ、又はそれらのポイント・イン・タイム・フリーズを実行し、ストレージ・デバイス３４２に関連する状態レジスタのダンプを実行し、エラー状態に関するデータを収集し、ラップするログ等があればそれらも収集する。これらの情報は、障害を起こしていない別のストレージ・デバイス上、例えばストレージ・デバイス３４８上等、ストレージ・システム３４０内の確立された位置に記憶される状態保存データ構造に収集される。このようなストレージ・システム状態保存データの収集は、ストレージ・デバイス３４２の障害検出後ほぼ即時にストレージ・コントローラ３５０によって実行される。
【００６４】
ホスト・システム３１０〜３３０では、例えばホスト・システム３１０を例にとると、ストレージ・コントローラ３５０のマルチ・ホスト・インターフェース３６０によって発行される状態保存コマンドは、ＨＢＡドライバ３１４によって受信され、フェイルオーバ・ドライバ３１２に提供される。フェイルオーバ・ドライバ３１２は、その状態保存コマンドを認識し、ＨＢＡドライバ３１４に対して内部状態保存コマンドを発行する。その後、ＨＢＡドライバ３１４は、ホスト・システム３１０の処理を休止させ、ホスト・システム３１０の各コンポーネントに対して、基本構成情報、ＨＢＡレジスタ情報、フェイルオーバ・ドライバ・ログ情報、アプリケーション・ログ情報等の収集コマンドを内部的に発行する。これらの情報は、ホスト・システム３１０内に記憶されるホスト状態保存ログ・データ構造にコンパイルされる。
【００６５】
その後、このホスト状態保存ログ・データ構造は、確立されたデータ・チャネルを介してホスト・システム３１０からストレージ・コントローラ３５０に転送される。このホスト状態保存ログ・データ構造は、ストレージ・システム状態保存ログ・データ構造と共に、ストレージ・デバイス３４２の障害のポイント・イン・タイムに関するすべての状態保存情報を含む１つのパッケージにパッケージングされる。後のある時点で、ストレージ・コントローラ３５０は、その状態保存情報パッケージをストレージ・デバイス３４２の障害原因を分離する障害デバッグ処理の実行時に使用するために、転送媒体３９０を介してクライアント・デバイス３９５に送信することができる。
【００６６】
この処理は、各ホスト・システム３１０〜３３０からストレージ・コントローラ３５０にホスト・システム状態保存ログ・データ構造を提供することにより、各ホスト・システムにおいて実行することができることを理解していただきたい。ストレージ・コントローラ３５０は、すべてのホスト・システム状態保存ログ・データ構造をストレージ・システムの状態保存ログ・データ構造と一緒にして、１つのパッケージにパッケージングすることができる。その結果、ストレージ・デバイス３４２の障害のポイント・イン・タイムに関連することが保証された状態保存ログ・データの単一のパッケージが生成される。それ故、例示的な諸実施形態の各メカニズムを利用して障害デバッグを実行する場合は、障害に対応する各時点のログを外部デバイスによってスキャンする必要がなくなる。
【００６７】
例示的な諸実施形態の例示的な動作を更に説明するために、ここでは、ホスト・システムからデータベースへのアクセスに問題が生じ、その結果Ｉ／Ｏエラーがエラー・ログの形で生成される実行環境の一般的な状況を仮定する。ストレージ・システム３４０には障害が発生したことを示すどのようなインジケーションも与えられない。例示的な諸実施形態を用いると、障害は、アプリケーション・インスタンス３１８、フェイルオーバ・ドライバ３１２、ＨＢＡドライバ３１４、及びイーサネット／ファイバ・チャネルＡＰＩ ３７０を介してストレージ・システム３４０に通信される。フェイルオーバ・ドライバ３１２は、ストレージ・システム３４０に障害が発生したことを知らせる信号フレームを送信することができる。その後、ストレージ・システム３４０は、データ収集応答を開始することができる。ホスト・フェイルオーバ・ドライバ３１２及びＨＢＡドライバ３１４は、ホスト・システム３１０上のホスト・ログ、フェイルオーバ・ドライバ・ログ、ＨＢＡドライバ・ログ等を収集し、それらを適切なタイム・スタンプを有するログ・ファイルと共に適切なディレクトリに記憶する。ストレージ・システム３４０は、レジスタ値、すべてのホスト・システム３１０〜３３０に関するデバイス固有情報、エラー状態、及びラップするログがあればそれらも状態保存データ・ファイルに収集する状態保存処理を強制実行（ｆｏｒｃｅ）する。次に、ストレージ・システム３４０は、ストレージ・デバイス上に一時記憶スペースを作成し、その一時記憶スペースにホスト・システム３１０〜３３０からの記憶済みログ・ファイルを転送する。その後、すべてのログ・ファイルは、それぞれのソース、タイム・スタンプ、及びシステム詳細を示すログと共に１つのファイルにアーカイブされる。
【００６８】
図５及び図６は、例示的な一実施形態に従ってＳＡＮコンポーネント障害に関連するデータ収集を実行する例示的な処理を示すフローチャートである。フローチャートに示される各ブロック及びブロックの組合せは、コンピュータ・プログラム命令によって体現され得ることが理解されるだろう。これらのコンピュータ・プログラム命令は、プロセッサ又は他のプログラマブル・データ処理装置に提供することができ、それにより、各命令を当該プロセッサ又は他のプログラマブル・データ処理装置上で実行してフローチャート内の１つ又は複数のブロックで指定される機能を実現する手段が提供されるマシンを生成することが可能となる。これらのコンピュータ・プログラム命令は、プロセッサ又は他のプログラマブル・データ処理装置を特定の形で機能させることができるコンピュータに読み込み可能なメモリ又は記憶媒体に記憶することもでき、それにより、当該コンピュータに読み込み可能なメモリ又は記憶媒体に記憶された各命令によってフローチャート内の１つ又は複数のブロックで指定される機能が実現される製品を生成することが可能となる。
【００６９】
したがって、フローチャート内の各ブロックは、指定された機能を実行する手段の組合せと、指定された機能を実行するステップの組合せと、指定された機能を実行するプログラム命令手段とをサポートする。フローチャート内の各ブロック及びブロックの組合せは、指定された機能又はステップを実行する専用ハードウェア・ベース・コンピュータ・システムによって、あるいは専用ハードウェアとコンピュータ命令との組合せによって実行することができることも理解されるだろう。
【００７０】
更に、各フローチャートは、例示的な諸実施形態の範囲内で実行される処理の論証用に提示されるものである。各フローチャートは特定の処理に関する限定、より具体的には処理の順序に関する限定を主張するものではなく、そのように暗示することも意図しているわけではない。各フローチャートの処理は具体的な実装に合わせて修正することができる。
【００７１】
図５は、ホスト・アプリケーション障害に応答してデータ収集を実行する、例示的な一実施形態に係る例示的な処理の概要を示すフローチャートである。図５に示されるように、本処理は、フェイルオーバ・ドライバがアプリケーション・インスタンスの障害を検出することから開始する（ステップ５１０）。次に、フェイルオーバ・ドライバは、ホスト・バス・アダプタ（ＨＢＡ）・ドライバに状態保存コマンドを送信し（ステップ５２０）、ホスト・システム内の状態保存処理を開始する（ステップ５３０）。ホスト・システム内の状態保存処理の一環として、フェイルオーバ・ドライバ又はＨＢＡドライバあるいはその両方は、様々なホスト・システム・コンポーネントに対してそれらのデータを収集するためのコマンドを送信し、その後、各データはホスト・システム状態保存ログ・データ構造に記憶される（ステップ５４０）。
【００７２】
ＨＢＡドライバは、ストレージ・システムに状態保存コマンドを送信する（ステップ５５０）。ストレージ・システムは、ＨＢＡドライバから状態保存コマンドを受信し、当該状態保存コマンドの送信元となるホスト・システムに対応するストレージ・デバイスを判定する（ステップ５６０）。次に、ストレージ・システムは、特定されたストレージ・デバイスに関する状態保存処理を実行し（ステップ５７０）、収集された状態情報をストレージ・システム状態保存ログ・データ構造に記憶する（ステップ５８０）。次に、ストレージ・システムは、影響を受けているストレージ・デバイスと、作成されたストレージ・システム状態保存ログ・データ構造とを示す応答をホスト・システムに返す（ステップ５９０）。
【００７３】
その後、ホスト・システムは、ホスト・システム状態保存ログ・データ構造をストレージ・システムに送信することができ（ステップ５９２）、ストレージ・システムはそこで、当該ホスト・システム状態保存ログ・データ構造をストレージ・システム状態保存ログ・データ構造と共に単一の状態保存ログ・パッケージにパッケージングする（ステップ５９４）。その後、当該状態保存ログ・パッケージを障害デバッグの実行時に使用するためにクライアント・デバイスに提供することができる（ステップ５９６）。その後処理は終了する。
【００７４】
図６は、ストレージ・デバイス障害に応答してデータ収集を実行する、例示的な一実施形態に係る例示的な処理の概要を示すフローチャートである。図６に示されるように、本処理は、ストレージ・コントローラがストレージ・デバイスの障害を検出することから開始する（ステップ６１０）。次に、ストレージ・コントローラは、それ自体の通信先となる各ホスト・システムとの間のデータ・チャネルを確立し（ステップ６２０）、各ホスト・システムに状態保存コマンドを送信する（ステップ６３０）。更に、ストレージ・コントローラは、ストレージ・システム内の状態保存処理を開始する（ステップ６４０）。ストレージ・システム内の状態保存処理の一環として、ストレージ・コントローラは、様々なストレージ・システム・コンポーネントに対してそれらのデータを収集するためのコマンドを送信し、その後、各データはストレージ・システム状態保存ログ・データ構造に記憶される（ステップ６５０）。
【００７５】
各ホスト・システムは、ストレージ・コントローラから状態保存コマンドを受信し、ホスト・システム内の状態保存情報を記憶するためのデータ構造を生成する（ステップ６６０）。次に、ホスト・システムは、状態保存処理を実行し（ステップ６７０）、収集された状態情報をホスト・システム状態保存ログ・データ構造に記憶する（ステップ６８０）。その後、ホスト・システムは、ホスト・システム状態保存ログ・データ構造をストレージ・システムに送信し（ステップ６９０）、ストレージ・システムはそこで、当該ホスト・システム状態保存ログ・データ構造をストレージ・システム状態保存ログ・データ構造と共に単一の状態保存ログ・パッケージにパッケージングする（ステップ６９４）。その後、当該状態保存ログ・パッケージを障害デバッグの実行時に使用するためにクライアント・デバイスに提供することができる（ステップ６９６）。その後処理は終了する。
【００７６】
このように、例示的な諸実施形態は、ホスト・システム上又はストレージ・システム内のストレージ・デバイス上のアプリケーション障害が発生した場合の即時データ収集を容易にするメカニズムがホスト・システムとストレージ・システムのそれぞれに提供されるシステム及び方法を提供する。データ収集は障害発生後ほぼ即時に実行されるので、収集されるデータ量が最大化される。また、例示的な諸実施形態の各メカニズムによれば、非常に過渡的なデータ、即ち小さいトレース・データ・ストレージを有するコンポーネントに記憶されているデータもキャプチャされる。更に、障害の検出に応答してホスト・システムとストレージ・システムの両方から収集される状態情報を一緒にパッケージングしてデバッグ用に提供することができる。その結果、パッケージに記憶されているデータは障害時点のＳＡＮの状態に関連することが保証されるため、特定の障害に関連する情報を特定するための詳細なログ・ファイル・スキャンの実行が最小限に抑えられる。
【００７８】
上述のとおり、例示的な諸実施形態は、いくつかの処理を実行するホスト・システム及びストレージ・システムの特定の要素に関して説明されているが、これらは単に本発明の可能な実施形態を例示するものにすぎず、また、本明細書に記載の処理を実行することが可能な要素を限定することを主張するものではなく、そのように暗示することも意図しているわけではないことを理解していただきたい。それ故、例えば上記のストレージ・システムのストレージ・コントローラによる処理は、ホスト・システム上で実行されるドライバでも同様に実行することができ、逆もまた同様に実行することができる。更に、前述の例示的な諸実施形態に関して概要を示した様々な処理を実行する、ホスト・システム又はストレージ・システムに由来する別個のデバイスを提供することもできる。上記の説明を読めば当業者には容易に理解されるように、例示的な諸実施形態には本発明の趣旨及び範囲を逸脱しない限り他の修正を施すことが可能である。
【００７９】
また、例示的な諸実施形態は、ストレージ・システムと１つ又は複数のホスト・システムとの間の状態保存処理に関して説明されているが、各実施形態及び本発明はそのように限定されるものではない。むしろ、例示的な諸実施形態の各メカニズムは、障害発生時に状態保存処理が望まれるデータ処理システムで構成される任意のネットワークと共に利用することが可能である。それ故、本発明はホスト・システム及びストレージ・システム内の状態保存処理に限定されるものではなく、本発明の趣旨及び範囲には他の環境も含まれるものと見なされる。
【００８０】
例示的な諸実施形態は全体としてハードウェアの実施形態の形をとることも、全体としてソフトウェアの実施形態の形をとることもでき、ハードウェア要素とソフトウェア要素の両方を含む実施形態とすることもできることを理解していただきたい。例示的な一実施形態において、例示的な各実施形態に係るメカニズムは、必ずしもそれだけに限定されるわけではないが、ファームウェア、常駐ソフトウェア、マイクロコード等を含むソフトウェアで実施される。
【００８１】
更に、例示的な諸実施形態は、コンピュータ又は任意の命令実行システムによって、あるいはそれらに関連して使用されるプログラム・コードを備えるコンピュータ使用可能な又はコンピュータに読み込み可能な媒体からアクセスできる、コンピュータ・プログラム製品の形をとることもできる。本明細書では、コンピュータ使用可能な又はコンピュータに読み込み可能な媒体は、上記命令実行システム、装置、又はデバイスによって、あるいはそれらに関連して使用される上記プログラムを、収容し記憶し通信し伝搬し又は移送することができる任意の装置であってよい。
【００８２】
上記媒体は、電子系媒体、磁気系媒体、光学系媒体、電磁気系媒体、赤外線系媒体、又は半導体系媒体（あるいは装置又はデバイス）あるいは伝搬媒体であってもよい。コンピュータに読み込み可能な媒体の例としては、半導体又は固体メモリ、磁気テープ、着脱自在のコンピュータ・ディスケット、ランダム・アクセス・メモリ（ＲＡＭ）、読み取り専用メモリ（ＲＯＭ）、固定磁気ディスク、及び光ディスクが挙げられる。光ディスクの現行例としては、コンパクト・ディスク読み取り専用メモリ（ＣＤ‐ＲＯＭ）、コンパクト・ディスク読み出し／書き込み（ＣＤ‐Ｒ／Ｗ）、及びＤＶＤが挙げられる。
【００８３】
プログラム・コードを記憶し又は実行しあるいはその両方を行うのに適したデータ処理システムは、システム・バスを介してメモリ要素に直接又は間接的に連結される少なくとも１つのプロセッサを含む。上記メモリ要素は、上記プログラム・コードの実際の実行中に利用されるローカル・メモリ、バルク・ストレージ・デバイス、及び実行中にバルク・ストレージ・デバイスからコードを検索しなければならない回数を少なくするために、少なくともいくつかのプログラム・コードを一時的に記憶するキャッシュ・メモリを含むことができる。
【００８４】
入力／出力、即ちＩ／Ｏデバイス（必ずしもそれだけに限定されるわけではないが、キーボード、ディスプレイ、ポインティング・デバイス等を含む）は、上記システムに直接連結することも、Ｉ／Ｏコントローラを介して連結することもできる。介在する私設ネットワーク又は公共ネットワークを通して他のデータ処理システムあるいは遠隔プリンタ又はストレージ・デバイスに、上記データ処理システムが連結できるようにするために、上記システムにネットワーク・アダプタを連結することもできる。モデム、ケーブル・モデム及びイーサネット・カードは、現時点で使用可能なタイプのネットワーク・アダプタのほんのいくつかにすぎない。
【００８５】
本発明の記載は例示及び説明のために提示しているものであって、本発明の実施形態を余すところのないものとし、又は開示の形態に限定することは、本出願人の意図するところではない。当業者には多くの修正、変更が可能なことは明白であろう。

Claims (4)

1. 複数のホスト・システム及び少なくとも１つのストレージ・システムから構成されるストレージ・エリア・ネットワーク内の障害に対応するデータを収集する方法であって、
   （ａ）前記ストレージ・システム内のストレージ・デバイスの障害状態に関する障害通知を受信するステップと、
   （ｂ）前記ストレージ・システムのマルチ・ホスト・システム・インターフェースを介して、前記複数のホスト・システムのうちの各ホスト・システムとの間の別個のデータ・チャネルを確立するステップと、
   （ｃ）前記マルチ・ホスト・システム・インターフェースによって確立された前記データ・チャネルを介して、イン・バンド状態保存コマンドを前記ストレージ・システムのストレージ・コントローラから前記各ホスト・システムにそれぞれ送信するステップと、
   （ｄ）前記ストレージ・システム内の状態保存処理を要求することにより、前記ストレージ・システム用の状態保存データを生成するステップと、
   （ｅ）前記各ホスト・システムがそれぞれのホスト・バス・アダプタ（ＨＢＡ）ドライバにおいて前記イン・バンド状態保存コマンドを受信し且つ当該受信されたイン・バンド状態保存コマンドをそれぞれのフェイルオーバ・ドライバに提供したことに応答して、当該各ホスト・システム用の状態保存データを収集し且つ当該収集された当該各ホスト・システム用の状態保存データを前記マルチ・ホスト・システム・インターフェースによって確立された前記データ・チャネルを介して、前記ストレージ・コントローラに送信するステップと、
   （ｆ）前記各ホスト・システムによって収集された当該各ホスト・システム用の前記状態保存データを、前記ストレージ・システムからの状態保存データと共に、検出された前記障害状態と関連付けられる単一の状態保存データ・パッケージにパッケージングするステップと、
   （ｇ）前記状態保存データ・パッケージを前記ストレージ・デバイスの前記障害状態の解決時に使用するために出力するステップとを含む、方法。
2. 前記イン・バンド状態保存コマンドを受信したことに応答して、前記各ホスト・システムは、それぞれの処理を休止させ、当該各ホスト・システムのコンポーネントの状態を保持し、当該各ホスト・システムの前記コンポーネントの状態情報を記憶することによって当該各ホスト・システム内の状態保存処理を開始する、請求項１に記載の方法。
3. 前記出力するステップ（ｇ）は、前記状態保存データ・パッケージを前記各ホスト・システム又は前記ストレージ・システムとは異なる障害デバッグ用のデータ処理システムに出力するステップを含む、請求項１に記載の方法。
4. コンピュータ・システムにロードされたときに、請求項１乃至３のいずれか一項に記載の方法に係るすべてのステップを前記コンピュータ・システムに実行させるコンピュータ・プログラム・コードを備えるコンピュータ・プログラム。

Images