(57)【要約】【課題】ＳＡＮ再構成の期間中のデバイスクリティカリティを求める方法及びシステムを提供する。【解決手段】ＳＡＮ接続グラフを構築して、ＳＡＮ接続グラフにおいて再構成をマッピングするステップと、影響を受けるホストシステムを突き止めるステップと、影響を受けるホストシステムのそれぞれについてデバイスクリティカリティを求めるステップとを含む、ＳＡＮ再構成オペレーションの期間中のデバイスクリティカリティを求める方法、システム、及びコンピュータプログラム。ホストシステムには、ホストシステムのデバイスクリティカリティを生成する影響解析エージェント、及び、影響解析エージェントからのデバイスクリティカリティを集約すると共に、データセンターアドミニストレータにフィードバックを提供する中央エージェントを提供することもできる。【選択図】図３
2009015826.tif 000002
【特許請求の範囲】
【請求項１】
ストレージエリアネットワークの再構成のデバイスクリティカリティを求める方法であって、
ストレージエリアネットワーク接続グラフを構築するステップと、
前記ストレージエリアネットワーク接続グラフから、再構成オペレーションによる影響を受けるホストシステムを特定するステップと、
前記影響を受ける各ホストシステムのクリティカル資源解析アルゴリズムを呼び出すステップであって、前記影響を受けるホストシステムにおける前記影響を受ける資源を求めるステップと
を含む方法。
【請求項２】
到達可能なＬＵＮの集合が、前記ストレージエリアネットワーク接続グラフへの前記再構成オペレーションのマッピングの前後で同じでない場合には、前記ホストシステムが、影響を受けるものと判断される
請求項１に記載の方法。
【請求項３】
前記クリティカル資源解析によって生成されるデバイスクリティカリティデータを、影響を受けるホストシステムからそれぞれに蓄積するステップと、
データセンターアドミニストレータ用のデバイスクリティカリティ報告を生成するステップと
をさらに含む請求項１に記載の方法。
【請求項４】
前記クリティカル資源解析は、前記データセンターの前記ホストシステムのそれぞれにデプロイされた影響解析エージェントによって実行される
請求項１に記載の方法。
【請求項５】
前記蓄積するステップは、影響解析エージェントからの結果を集約すると共に、コンソリデートされた報告を前記データセンターアドミニストレータに提供する中央エージェントによって実行される
請求項３に記載の方法。
【請求項６】
データセンターの前記ホストシステムのそれぞれについてコンポーネント階層グラフを構築するステップ
をさらに含む請求項１に記載の方法。
【請求項７】
前記コンポーネント階層グラフは、非循環有向グラフである
請求項６に記載の方法。
【請求項８】
利用属性、冗長性属性およびクリティカリティ属性またはこれらのいずれかを前記コンポーネント階層グラフに記憶するステップ
をさらに含む請求項６に記載の方法。
【請求項９】
前記ホストシステムのコンポーネント階層グラフをトラバースするステップであって、前記影響を受ける資源を求めるステップ
をさらに含む請求項１に記載の方法。
【請求項１０】
デバイスクリティカリティの結果を、成功、警告、データクリティカル、システムクリティカルまたはエラーとして分類するステップ
をさらに含む請求項１に記載の方法。
【請求項１１】
グラフィカルユーザインターフェースによって、
ＳＡＮの状態をユーザに提示するステップと、
前記ユーザに行動を推奨するステップと
をさらに含む請求項１に記載の方法。
【請求項１２】
ストレージエリアネットワークの再構成オペレーションのデバイスクリティカリティを求める装置であって、
ストレージエリアネットワーク接続グラフから、再構成オペレーションによる影響を受けるホストシステムを突き止める中央エージェントと、
前記影響を受ける各ホストシステムのクリティカル資源解析アルゴリズムを呼び出して、前記影響を受けるホストシステムにおける影響を受ける資源を求める影響解析エージェントと
を備える装置。
【請求項１３】
前記中央エージェントは、前記ストレージエリアネットワーク接続グラフを生成するＳＡＮグラフ生成ユニット
をさらに備える請求項１２に記載の装置。
【請求項１４】
前記影響解析エージェントは、前記ホストシステムのコンポーネント階層グラフを生成するように構成されている
請求項１２に記載の装置。
【請求項１５】
到達可能なＬＵＮの集合が、前記ストレージエリアネットワーク接続グラフへの前記再構成オペレーションのマッピングの前後で同じでない場合には、前記ホストシステムが、影響を受けるものと判断される
請求項１２に記載の装置。
【請求項１６】
前記影響解析エージェントは、
前記クリティカル資源アルゴリズムによって生成される影響を受ける資源のリストを記憶するストレージエレメント
をさらに備える請求項１４に記載の影響解析エージェント。
【請求項１７】
前記中央エージェントは、
影響解析エージェントからのデバイスクリティカリティデータを蓄積することと、
データセンターアドミニストレータ用のデバイスクリティカリティ報告を生成することと
をさらに含む請求項１２に記載の中央エージェント。
【請求項１８】
ストレージエリアネットワークの再構成のデバイスクリティカリティを求める装置であって、
ストレージエリアネットワーク接続グラフを構築する構築手段と、
前記ストレージエリアネットワーク接続グラフから、再構成オペレーションによる影響を受けるホストシステムを特定する特定手段と、
前記影響を受ける各ホストシステムのクリティカル資源解析アルゴリズムを呼び出す手段であって、前記影響を受けるホストシステムにおける前記影響を受ける資源を求める手段と、
グラフィカルユーザインターフェースによって、
ＳＡＮの状態をユーザに提示する手段と、
前記ユーザに行動を推奨する手段と
を備える装置。
【請求項１９】
ストレージエリアネットワークの再構成のデバイスクリティカリティを求めるコンピュータプログラムであって、
ストレージエリアネットワーク接続グラフを構築するステップと、
前記ストレージエリアネットワーク接続グラフから、再構成オペレーションによる影響を受けるホストシステムを特定するステップと、
前記影響を受ける各ホストシステムのクリティカル資源解析アルゴリズムを呼び出すステップであって、前記影響を受けるホストシステムにおける影響を受ける資源を求めるステップと
をサーバ用コンピュータに実行させるコンピュータプログラム。
【請求項２０】
到達可能なＬＵＮの集合が、前記ストレージエリアネットワーク接続グラフへの前記再構成オペレーションのマッピングの前後で同じでない場合には、前記ホストシステムが、影響を受けるものと判断される
請求項１９に記載のコンピュータプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明の実施の形態は、ＳＡＮ再構成の期間中のデバイスクリティカリティを求める方法及びシステムに関する。
【背景技術】
【０００２】
データセンターは、通常はコンピュータ及び通信機器といった大量の電子機器を収容するのに使用される設備である。データセンターの一般的なコンポーネントには、サーバ、ストレージデバイス、相互接続ケーブル、スイッチ、及びハブのようなストレージエリアネットワークコンポーネント、並びにＬＡＮケーブル及びスイッチ／ハブのようなデータネットワークエレメントが含まれ得る。ストレージエリアネットワーク（ＳＡＮ）は、コンピュータストレージデバイスをサーバにアタッチするように設計されるネットワークである。ＳＡＮによって、マシンがブロックレベルＩ／Ｏのネットワーク上のディスク、及びテープドライブ等のリモートターゲットに接続することが可能になる。
【０００３】
ストレージエリアネットワークでは、ストレージエレメントは、個々のサーバに属さない。その代わり、ストレージエレメントは、ネットワークに直接アタッチされ、ストレージは、必要な時にサーバに割り当てられる。ストレージエレメントをサーバシステムの遠隔に配置することができる。したがって、たとえサーバシステムを含むインフラストラクチャが破壊されても、データを依然として回復することができる。その上、ストレージエレメントをホストシステムと共に移動させる必要がないので、ネットワークにおけるホストシステムのリロケーションがより容易になる。加えて、ホストをその個別のロケーションで個々にアップグレードする必要がないので、ネットワークのアップグレードをより簡単にすることができる。さらにまた、或るサーバが正しく機能しない場合には、データを回復させる必要なく、新しいサーバを迅速にセットアップできると共に、ストレージエレメントの関連のあるストレージボリュームに向けることができるので、システムのダウンタイムが削減される。
【０００４】
複数のスイッチを含むデータリンクのネットワークは、サーバとＳＡＮのストレージエレメントとを接続するのに使用される。これらのコンポーネントの１つ又は２つ以上の故障の結果としてのネットワークのダウンタイムをさらに削減するために、多くの場合、冗長リンクをサーバとストレージエレメントとの間に含めて、それによって、或るリンクが正しく機能しない場合に、別のリンクを使用できると共に、中断することなくネットワークを使用できるようにする。システムを管理すると共に、十分な冗長パスが確実に存在するようにするために、管理プログラムが、多くの場合使用される。管理プログラムが、障害を解析して、ネットワークの状態を評価し、且つ入出力連続性が最適な性能で維持されることを保証する場合には、システムのダウンタイムをさらに削減することができる。
【０００５】
アドミニストレータが、データセンターを構成するコンポーネント上で保守オペレーション及び／又は再構成オペレーションを行うことは珍しいことではない。ＩＴコンソリデーション、ハードウェア、及びソフトウェアのアップグレードは、このようなオペレーションの一般的な理由の一部である。
【０００６】
ストレージエリアネットワークでは、保守オペレーションを行う前に、アドミニストレータは、可用性及び性能の点から、潜在的なシステム及び／又はアプリケーションレベルの影響を評価することに関心を持つ。保守オペレーションの影響解析は、アプリケーション管理システムのコア部分を成す。したがって、このような保守オペレーションを計画して実行する前に、アドミニストレータは、「このケーブルを除去／交換した場合に、何に影響があるのか？」、「保守作業のためにこのストレージデバイスを一時的にオフラインにした場合に、システム／アプリケーションに何が起こるのか？」、「ディスクアレイコントローラ又は筐体内のディスクが交換され／影響を受ける場合に、自身のデータセンターのどのアプリケーションが影響を受けるのか？」等の質問に対する回答を知ることに関心を持つ場合がある。
【発明の開示】
【発明が解決しようとする課題】
【０００７】
本発明は、ＳＡＮ再構成の期間中のデバイスクリティカリティを求めるための方法及びシステムを提供する。
【課題を解決するための手段】
【０００８】
本発明の一形態は、ストレージエリアネットワークの再構成のデバイスクリティカリティを求める方法であって、ストレージエリアネットワーク接続グラフを構築するステップと、前記ストレージエリアネットワーク接続グラフから、再構成オペレーションによる影響を受けるホストシステムを特定するステップと、前記影響を受ける各ホストシステムのクリティカル資源解析アルゴリズムを呼び出すステップであって、前記影響を受けるホストシステムにおける影響を受ける資源を求める、呼び出すステップと、を含む方法である。
【０００９】
次に、添付図面を参照して、本発明の実施形態を単なる例として説明することにする。
【発明を実施するための最良の形態】
【００１０】
次に、本発明の実施形態を詳細に参照することにする。これらの実施形態の例は、添付図面に示されている。本発明をこれらの実施形態との関連で説明するが、これらの実施形態は、本発明をこれらの実施形態に限定することを意図したものではないことが理解されよう。逆に、本発明は、代替形態、変更形態、及び均等物を含有するように意図されている。これらの代替形態、変更形態、及び均等物は、添付の特許請求の範囲によって規定される本発明の精神及び範囲内に含めることができる。さらに、本発明の以下の詳細な説明では、本発明の徹底した理解を提供するために、多数の具体的な詳細が述べられる。
【００１１】
クリティカル資源解析（ＣＲＡ）機能を使用すると共に、データセンターイベントをホストシステムレベルイベントにマッピングすることによって、データセンターにおけるＳＡＮ再構成オペレーションのクリティカリティ又は副作用を求める技法を説明することにする。本技法は、データセンターの各ホストにデプロイされる影響解析エージェント（ＩＡＡ）を使用する。データセンターアドミニストレータノードに設けられる中央エージェントは、データセンターにわたる影響解析エージェントのそれぞれからの結果を集約して、コンソリデートされた報告をデータセンターアドミニストレータに提供することができる。中央エージェントは、ＳＡＮ生成ユニットから構成することができる。次に、添付図面を参照して本技法をより詳細に説明することにする。
【００１２】
図１を参照すると、ネットワーク１は、複数のデータリンク３ａ、３ｂ、３ｃ、３ｄ、３ｅに接続される複数のホスト２ａ、２ｂ、２ｃと、複数のスイッチ４ａ、４ｂと、複数のストレージエレメント５ａ、５ｂ、５ｃ、及び５ｄとを備える。ホストには、サーバ２ａ、２ｂ、２ｃ、及びクライアントコンピュータが含まれ得るが、これらに限定されるものではない。データリンクには、たとえば、イーサネット（登録商標）インターフェース接続、ファイバチャネル、及びＳＣＳＩ（小規模コンピュータシステムインターフェース）インターフェースが含まれ得るが、これらに限定されるものではない。ストレージエレメントには、ディスクドライブ及び／又はディスクアレイ５ａ、５ｂ、５ｃ並びにテープドライブアレイ５ｄが含まれる。
【００１３】
或るパスのコンポーネント又はデータリンクが故障しても、別のパスを使用してホストとストレージエレメントとの間でデータを依然として交換できるように、各ホストは、少なくとも２つのパスによって各ストレージエレメントに接続される。したがって、各サーバ２ａ、２ｂ、２ｃは、データリンク３ａ、３ｂを通じてスイッチに接続する少なくとも１つのホストバスアダプタ（ＨＢＡ）６ａ〜６ｆを有する。同様に、各ストレージエレメント５ｂ又はストレージエレメントのクラスタは、データリンク３ｃ、３ｄ、３ｅに接続する少なくとも１つのコントローラ７ａ〜７ｄを有する。ＨＢＡ６ａ〜６ｆの役割は、ホストとアタッチされたデータリンクとの間のインターフェースを提供することである。これらのＨＢＡは、データを転送するのに必要なホスト処理のほとんどをオフロードする入出力処理をさらに提供することができる。コントローラ７ａ〜７ｄは、ストレージエレメントについて同様の役割を行う。スイッチと同様に、ＨＢＡ及びコントローラも、代替的なパスを提供する２つの以上のポートを有することができる。図１では、ポート６ｅが、２つのポートを有するものとして示されている。ホストとストレージエレメントとを接続するＨＢＡ６ａ〜６ｆ、データリンク３ａ〜３ｅ、スイッチ４ａ、４ｂ、及びコントローラ７ａ〜７ｄから成るネットワークは、ファブリック８として知られているものを構成する。
【００１４】
ＳＡＮの各コンポーネントは、複数のサブコンポーネント９を有する。これらのサブコンポーネント９のいずれか１つは、システムの性能に影響を与える可能性がある。たとえば、各スイッチは、１つ又は２つ以上のポート、ファン、及び／又は電源を有する場合がある。
【００１５】
各ホストシステム２ａ、２ｂ、２ｃには、ファブリックチャネル８を通じてアクセスすることができるストレージエリアが割り当てられる。ストレージエリアは、異なるストレージエレメント上に分散させることができる。ストレージエリアは、さらに、通常は複数の論理ユニット番号（ＬＵＮ）１０に分類することができる。ＬＵＮ１０のそれぞれは、ストレージエレメントの実際の一部又は仮想的な一部に対応する。たとえば、或るＬＵＮ１０は、ディスクドライブアレイ内の１つ又は２つ以上のディスクに対応することができる。
【００１６】
サーバは、ローカルエリアネットワーク（ＬＡＮ）１１において、複数のクライアントコンピュータ１２ａ、１２ｂに接続することができる。クライアントコンピュータは、ファイバチャネル等のそれ自体のデータリンクでＳＡＮに直接接続してもよく、又はＬＡＮ及びサーバを介して間接的に接続してもよい。
【００１７】
図３は、データセンターにおけるＳＡＮ再構成の期間中のデバイスクリティカリティを求めることに関与するステップを示している。一実施形態では、本技法は、ＳＡＮ再構成オペレーションにおけるホットプラグのデバイスクリティカリティを求める方法３００を実行するコンピュータ実行可能命令として実施することができる。このコンピュータ実行可能命令は、任意のタイプのコンピュータ可読媒体に記憶することができる。この任意のタイプのコンピュータ可読媒体は、磁気ディスク、ＣＤ−ＲＯＭ、光媒体、フロッピー（登録商標）ディスク、フレキシブルディスク、ハードディスク、磁気テープ、ＲＡＭ、ＲＯＭ、ＰＲＯＭ、ＥＰＲＯＭ、フラッシュＥＰＲＯＭ、又はコンピュータが読み出すことができる他の任意の媒体等である。
【００１８】
１つ又は２つ以上のコンポーネントの状態に関係したイベントの、ＳＡＮに対する影響を求めるために、ＳＡＮにおける接続を特定して解析しなければならない。コンポーネントがホスト２とＬＵＮ１０との間のパスの一部であり、且つ、このパスがそれら２つのコンポーネント間で唯一利用可能なパスである場合には、このパスの除去は、システムの性能にとってクリティカルとなる。一方、このパスが、ＳＡＮ９を通じてホストシステムからＬＵＮ１０への多数のパスのうちの１つにすぎない場合には、障害は、軽微な影響しか有しない。あらゆる代替的なパスを以下では冗長パスと呼ぶ。
【００１９】
図３のステップ３０１において、このアルゴリズムは、データセンターの情報を収集して、ＳＡＮ接続グラフ（本説明において、以降、「ＳＡＮグラフ」と呼ぶ）を構築する。グラフのエッジノードは、ディスクアレイによってエクスポートされたＬＵＮ、並びに、ホストシステム及び／又はサーバシステムのホストバスアダプタ（ＨＢＡ）ポートとすることができる。ディスクアレイ、筐体、及びコントローラは、ＳＡＮグラフのノードを論理的にグルーピングするのに使用することができ、それによって、これらのコンポーネントに影響を与える任意のオペレーションを、その論理グループのすべてのノードを「影響あり」としてマーキングするのに使用できるようにする。スイッチ、ハブ、ケーブル等のようなＳＡＮインフラストラクチャコンポーネントは、ＳＡＮグラフにおける中間ノード及び枝としてマッピングすることができる。ＳＡＮグラフを構築するアルゴリズムを、一例として、図２に関して簡潔に説明する。
【００２０】
ステップ２０１において、ＳＡＮグラフ生成ユニットが、ＳＡＮグラフを生成する命令を受け取る。これは、ユーザがＳＡＮを再構成したい時に受け取られる。いくつかの実施形態では、ＳＡＮグラフを再生成する、ＳＡＮグラフ生成ユニットへの命令は、所定の頻度で通信することができる。この所定の頻度は、ユーザによって構成可能である。
【００２１】
ＳＡＮ接続生成ユニットは、ステップ２０２において、ＳＡＮグラフが最後に生成された時以降に収集された情報から、ＳＡＮの最初のコンポーネントについての情報を取り出す。このコンポーネントについて収集された情報は、ベンダ及びモデルのデータと、たとえばワールドワイド名（ＷＷＮ）といった識別番号と、ＳＡＮグラフ生成ユニットがコンポーネントの近傍にあるものを求めることを可能にする接続情報とを含むことができる。また、ＳＡＮ接続生成ユニットは、コンポーネントについての情報がＳＡＮグラフデータベースにすでに存在するかどうか、すなわち、収集されたデータが既知のコンポーネントに関するものであるかどうか、又は、新しいコンポーネントがネットワークに追加されたかどうかをチェックすることができる。コンポーネントが新しいコンポーネントである場合には、ＳＡＮ接続生成ユニットは、ステップ２０４において、一意の識別番号をそのコンポーネントに割り当てる。識別番号を割り当てた後、そのコンポーネントを枝又は頂点として分類することができる。
【００２２】
ネットワークのコンポーネントは、頂点及び枝の２つの集合に分割することができる。頂点の集合は、ＨＢＡの集合、スイッチの集合、ストレージアレイコントローラの集合、及び論理ユニット番号の集合を含むことができる。枝の集合は、たとえばファイバチャネルケーブルといった、頂点を接続するデータリンクの集合である。２つの頂点は、１つ又は２つ以上の枝によって接続することができる。コンポーネントは、特定された後、ＳＡＮデータベースに記憶される（２０６）。
【００２３】
コンポーネントについての関連のある情報を収集した後、ＳＡＮ接続生成ユニットは、ステップ２０７において、収集されたデータが、さらなるコンポーネントについての情報を含むかどうかをチェックすることができる。追加のコンポーネントについての情報がない場合には、プロセスは、ステップ２０８において終了する。収集されたデータが、さらなるコンポーネントについての情報を含む場合には、プロセスは、ステップ２０２から繰り返される。
【００２４】
すべてのコンポーネントについての情報が追加されると、グラフは、ステップ２０８においてリンクされる。グラフをリンクすることは、すべての接続をチェックすること、ソースコンポーネントとデスティネーションコンポーネントとの間のすべてのパスを求めること、及びＧＵＩにおいて適した方法でシステムのアドミニストレータに提示されるデータを編成することを伴う。
【００２５】
次に、図５に関して、ソースコンポーネントとデスティネーションコンポーネントとの間のすべてのパスを求めるプロセスをより詳細に説明することにする。ステップ５０１において、ダミー変数ｎが０にセットされる。その後、識別番号ｖｎ、この場合はｖ０、を有する頂点の記録が、ステップ５０２において、ＳＡＮグラフデータベース３０のＳＡＮグラフから取り出される。ダミー変数ｍも、ステップ５０３において０にセットされ、ｖｍの記録が、ステップ５０４において取り出される。
【００２６】
ステップ５０５において、ｖｎとｖｍとの間に有効なアクセスパスがあるかどうかが判断される。ＳＡＮグラフの枝は、ホストからＬＵＮへの方向性を有する。アクセスパスは、ホストからＬＵＮへの方向にのみ確立することができる。したがって、たとえば、サーバ２ａと２ｃとの間のパスの確立は、誤った方向に向かう枝を伴うので、そのパスは確立されない。このステップは、対象となるパスのみを確立すること、及び、２つの頂点間のパスが１回しか確立されないことを保証する。ｖｎがｖ０に等しく、且つ、ｖｍもｖ０に等しい場合には、ステップ５０５において、利用可能である有効なパスがないことが確かめられ、したがって、ｍは、ステップ５０６において１だけ増分され、次に、ステップ５０５において、ｖ０とｖ１との間に有効なパスがあるかどうかが確かめられる。ｖ０がサーバ２ａに対応し、且つｖ１がＬＵＮ１０に対応するとき、ステップ５０５において、有効なパスがあると判断され、プロセスはステップ５０７に続く。
【００２７】
物理パス及び論理パスの双方が、頂点ｖｎ及びｖｍの対について確立される。物理パスは、コンポーネントの対の間の頂点のシーケンスである。論理パスは、枝のシーケンスである。
【００２８】
物理パスは、ステップ５０６において、頂点ｖ０と頂点ｖ１との間に確立され、そのパスにおけるそれら頂点の識別番号が、ＳＡＮグラフデータベースの高可用性（ＨＡ）マップに記憶される。サーバ２ａ及びＬＵＮ１０の場合、パスは、ＨＢＡ６ａ、スイッチ４ａ、及びコントローラ７ａを含む。
【００２９】
ステップ５０７において、ホストｖ０とＬＵＮ  ｖ１との間の代替的な物理パスがあるかどうかがチェックされる。代替的なパスがあることが確かめられた場合には、ステップ５０６が繰り返され、ＨＢＡ６ａ、スイッチ４ａ、及びコントローラ７ｂの代替的なパスが存在すると判断される。ステップ５０６及び５０７は、ノードの対の間ですべての有効なパスが見つけられるまで繰り返される。したがって、ＨＢＡ６ｂ、スイッチ４ｂ、及びコントローラ７ｂの第３の最後のパスも見つけられる。パスのすべては、それらパスのそれぞれの頂点のシーケンスと共に、ＳＡＮグラフデータベース内の物理的な高可用性（ＨＡ）マップＨＡｐ（ｖ０，ｖ１）に記憶される。
【００３０】
代替的な物理パスがそれ以上ないときは、プロセスは、ステップ５０８に続き、２つの頂点間の論理パスが確立される。上述した例では、ホスト２ａとＬＵＮ１０との間の１つの論理パスは、枝３ａ及び３ｃを含む。ステップ５０９において、代替的な論理パスがあるかどうかが判断され、代替的な論理パスがある場合には、ステップ５０８が繰り返される。上記例では、枝３ａ及び３ｄから成るパスと、枝３ｂ及び３ｅから成るパスとの２つの追加のパスが見つけられる。その後、すべてのパスは、それらパスのそれぞれの枝のシーケンスと共に、ＳＡＮグラフデータベースの論理ＨＡマップＨＡＬ（ｖ０，ｖ１）に記憶される。
【００３１】
すべての論理パスが記憶されると、ステップ５０９において、ｖ０とｖ１との間にパスがそれ以上ないと判断され、プロセスはステップ５１０に続き、ｍよりも大きな識別番号を有する頂点があるかどうかがチェックされる。そのような頂点がある場合には、ｍは、ステップ５１２において１だけ増分され、ｖ０とｖ２との間のすべてのパスについて、ステップ５０４〜５０９が繰り返される。頂点ｖ０と他のすべての頂点との間の有効なパスが確立されると、ステップ５１０において、頂点がそれ以上ないと判断され、プロセスはステップ５１１に進む。頂点がある場合には、ｎが１だけ増分され、ステップ５０２〜５１１が繰り返される。これらのステップは、システムにおける頂点のすべての対の間の有効なパスが確立され、物理ＨＡマップ及び論理ＨＡマップとして記憶されるまで繰り返される。
【００３２】
ＳＡＮグラフの各ホストシステムノードは、到達可能な複数のＬＵＮノードを保持することができ、これらのＬＵＮノードは、本説明では「到達可能ＬＵＮ集合」とも呼ばれる。
【００３３】
一実施形態によれば、図３のステップ３０２において、データセンターの各ホストシステムについてコンポーネント階層グラフ（ＣＨＧ）を構築することができる。ＣＨＧは、前方に位置するＰＣＩバスから、ホストシステム上で現在実行されているプロセスへ、ソフトウェアの要素に加えてハードウェアの要素をもマッピングするグラフである。プロセスノードは、ＣＨＧの葉、すなわち最終レベルにある。ＣＨＧの異なるレベルのノードは、ＰＣＩスロット、ＨＢＡ、ＨＢＡポート、ＬＵＮパス（ＨＢＡポートからＬＵＮへの枝とも呼ばれる）、ＬＵＮ，論理ボリューム、ボリュームグループ、ファイルシステム、及びプロセスから成ることができる。ＣＨＧの枝は、後続ノードが先行ノードを使用しており且つ／又は先行ノードに依存していることを示すことができる。したがって、先行ノードが影響を受け且つ／又は利用不能である場合には、冗長パス、すなわち代替パスが利用可能でない限り、後続ノードも利用不能である場合がある。ホストシステムの典型的なコンポーネント階層グラフを一例として図７に示す。ホストシステムのコンポーネント階層グラフは、非循環有向グラフ（ＤＡＧ）の形で表すことができる。
【００３４】
コンポーネント階層グラフは、各ノードにおいて、コンピュータシステムのコンポーネントのそれぞれに関連付けられる一定の属性を含むことができる。これらの属性は、たとえば、冗長性属性、クリティカリティ属性、又は利用属性とすることができる。冗長性属性は、特定のノードの冗長パスの個数で構成することができる。
【００３５】
ＳＡＮグラフ及びＳＡＮにおけるホストシステムのコンポーネント階層グラフは、ブート時間に準備して記憶することができる。ＳＡＮ及び／又はホストシステムの構成は頻繁に変化しないので、これによって、資源解析の時間を削減することができる。ＳＡＮの構成の変化は、ＳＡＮグラフ及び／又はＣＨＧに反映させることができる。ＳＡＮグラフ及びＣＨＧは、中央エージェントを用いて記憶することができる。
【００３６】
ＳＡＮ再構成オペレーションの期間中、ユーザは、たとえば、データセンターにおけるＳＡＮのデバイス（複数可）の追加、交換、又は除去といったオンラインホットプラグオペレーションを行いたい旨を示す。ここで、ユーザは、どのデバイス（複数可）が、試みられる再構成オペレーションに関与するのかを知っているものと仮定する。
【００３７】
図３のステップ３０３で続けて、ＳＡＮ再構成イベントは、枝及び／若しくはノードのＳＡＮグラフからの削除、並びに／又は、枝及び／若しくはノードのＳＡＮグラフへの追加にマッピングされる。ＳＡＮ再構成におけるリンク除去イベント及びポート除去イベントは、ＳＡＮグラフにおける枝の除去及びコントローラの追加／除去にマッピングすることができる。同様に、スイッチ及びディスクデバイス筐体の除去は、ノードの追加／除去オペレーションにマッピングすることができる。データセンターの観点でのＳＡＮ再構成オペレーションは、（ホストホットプラグオペレーションを通じて）サーバシステムからスイッチへのリンク、ＳＡＮスイッチ（複数可）、スイッチからディスクデバイスへのリンク、デバイスポート／コントローラ利用不能性、及びホストシステムポートから成る群からのＳＡＮのコンポーネントの１つ又は２つ以上を伴うことができる。
【００３８】
一実施形態によれば、データセンターにおけるＳＡＮ再構成オペレーションは、次の方法でホストレベルの影響にマッピングすることができる。サーバシステム又はホストシステムからスイッチへのリンクに対する影響は、ホストシステムのＨＢＡのホットプラグにマッピングすることができる。ディスクデバイスポートに対する影響、そのデバイス及び／又はディスクアレイによってエクスポートされたＬＵＮを使用する、ホストシステム上の対応する「ＬＵＮパス」は、影響を受けるとみなされる。スイッチからデバイスポートへのリンクが影響を受ける場合には、これは、デバイスポートの影響と等価であるとみなすことができ、そのリンクが接続されているデバイスポートの下のＬＵＮを使用するホストシステムは影響を受けるとみなされる。スイッチが影響を受ける場合には、そのスイッチに関連付けられた各リンクが影響を受ける場合があり、且つＳＡＮグラフにおいて、ホストシステム及びデバイスシステムに対する影響の形でマッピングすることができる。スイッチ間リンク（ＩＳＬ）を通じたＳＡＮにおける或るスイッチの他のスイッチに対する影響、並びに、ＳＡＮに接続された他のホストシステム及びデバイスに対する間接的な影響は、ノードの到達可能性の既知のグラフ理論の問題であり、或るエッジノードが、グラフのノード／枝（スイッチ／ＩＳＬ）の喪失によって別のエッジノード（ホスト／デバイス）へのパスを喪失するかどうかを判断する技法が存在する。したがって、スイッチの影響を、ＳＡＮに接続されたホストに対するＬＵＮパスレベルの影響にマッピングすることができる。
【００３９】
図３のステップ３０４に続いて、データセンターにおける影響を受けるホストが特定される。データセンターの影響を受けるホストを特定するアルゴリズムを図４に示す。ホストシステムが影響を受けると判断される場合には、ＩＡＡは、ホストシステム上でデバイスクリティカリティ解析アルゴリズムを起動する。ホストシステムにおけるデバイスクリティカリティを求めるアルゴリズムの一例を図６に示す。
【００４０】
さらにステップ３０５に続いて、デバイスクリティカリティデータが、データセンターにわたる影響を受けるすべてのホストシステムから蓄積される。中央エージェントが、すべてのホストシステムにわたるＩＡＡから受け取った結果を集約し、コンソリデートされた報告をデータセンターアドミニストレータに提供することができる。データセンターアドミニストレータは、ＳＡＮ再構成オペレーションのコンソリデートされた報告を参照することができる。
【００４１】
図４は、図３のステップ３０４のデータセンターの影響を受けるホストを判断するアルゴリズムを詳細に示している。
【００４２】
ステップ４０１において、データセンターのホストシステムのそれぞれについての到達可能なＬＵＮの集合が、ＳＡＮ再構成オペレーションの前に計算される。ＳＡＮ再構成オペレーションの前の到達可能なノードの集合は、本説明では、｛Ｒ１｝とも呼ぶ。ホストシステムの到達可能なＬＵＮの集合は、図４で説明するアルゴリズムによって得ることができる。このデータは、ホストシステムノードにおけるローカルＩＡＡエージェントを用いて記憶される。ステップ４０２において、ＩＡＡは、ＳＡＮグラフにおいてＳＡＮ再構成オペレーションをマッピングした後に、ホストシステムの到達可能なＬＵＮの集合（本説明では、｛Ｒ２｝とも呼ぶ）を計算する。ホストシステムの到達可能なＬＵＮの集合｛Ｒ２｝は、ＳＡＮ再構成オペレーションの後には、枝及び／又はアクセスパスの喪失により、｛Ｒ１｝とは異なる場合がある。
【００４３】
図４のステップ４０３に続いて、ホストシステムによって喪失されたＬＵＮの集合が計算される。ホストシステムによって喪失されたＬＵＮの集合は、ＳＡＮグラフにおけるＳＡＮ再構成オペレーションのマッピング前のホストシステムの到達可能ＬＵＮの集合｛Ｒ１｝と、ＳＡＮ再構成オペレーションのマッピング後のホストシステムの到達可能なＬＵＮの集合｛Ｒ２｝との差を計算することによって得ることができる。ホストシステムの喪失されたＬＵＮの個数は、本説明では、｛Ｒ３｝；（｜｛Ｒ３｝｜＝｜｛Ｒ１｝−｛Ｒ２｝｜）によっても表される。
【００４４】
さらにステップ４０４に続いて、ホストシステムが喪失したＬＵＮの集合｛Ｒ３｝が空である場合には、ホストシステムは、「影響なし」として宣言することができる（４０５）。ホストシステムの到達可能なＬＵＮの集合は、ＳＡＮグラフにおけるＳＡＮ再構成オペレーションのマッピングの前後で同じである、すなわち、｛Ｒ１｝＝｛Ｒ２｝であるので、その特定のホストシステムは、ＳＡＮ再構成オペレーションによる影響を受けない。
【００４５】
ホストシステムが喪失したＬＵＮの集合｛Ｒ３｝が空でない場合には、その特定のホストシステムは、「影響あり」としてマーキングされる（４０６）。ホストシステムの到達可能なＬＵＮの集合は、ＳＡＮグラフにおけるＳＡＮ再構成オペレーションのマッピングの前後で同じでないので、その特定のホストシステムは、ＳＡＮ再構成オペレーションによる影響を受ける。この影響は、ＳＡＮ再構成オペレーションのマッピングの期間中、ＳＡＮグラフからの枝及び／又はノードの除去後に、ホストシステムがそのＬＵＮ（複数可）を喪失したことによるものとすることができる。
【００４６】
ステップ４０７において、ホストシステムが「影響あり」とマーキングされている場合には、クリティカル資源解析（ＣＲＡ）アルゴリズムが呼び出されて、影響を受ける資源が求められる。ＣＲＡアルゴリズムは、ホストシステムにおける影響を受ける資源の個数を求める。ＣＲＡアルゴリズムから得られたデバイスクリティカリティ報告は、ローカルＩＡＡを用いて記憶することもできるし、中央エージェントへ直接送信することもできる。ＣＲＡアルゴリズムは、ホストシステム上でＩＡＡを用いて記憶されたコンポーネント階層グラフをトラバースして、影響を受ける資源を求めることができる。
【００４７】
一実施形態によれば、資源解析は、ホストシステムのＣＨＧをトラバースすることによって実行することができる。図６は、ＣＨＧのノードに関連付けられた冗長性属性を使用して影響を受けるノードを求めるＣＨＧトラバースアルゴリズムを示すフローチャートである。資源クリティカリティは、影響ありとしてマーキングされたノードに関連付けられる使用属性及びクリティカリティ属性をチェックすることによって得ることができる。
【００４８】
ステップ４０８に続いて、影響を受ける資源のリストが、ＣＲＡアルゴリズムから得られる。影響を受ける資源のリストは、ホストシステム上のＩＡＡによって、中央エージェントに対して利用可能にすることができる。中央エージェントは、ＩＡＡからのリストを集約して、データセンターにわたる影響を受けるすべての資源を含むコンソリデートされたリストを構築することができる。この集約は、単純に、データセンターにわたるＩＡＡのそれぞれからのリストの和集合とすることができる。集約されたリストは、ユーザの参照用にユーザに提示することができる。
【００４９】
ＳＡＮ再構成の期間中のデバイスクリティカリティを求めるアルゴリズムの擬似コード例は、次の通りである。
algorithm SAN_impact( input SAN Graph, 
input Component Hierarchy of all hosts, 
input  components added/removed in SAN,
output Impacts at data center level)
begin
Compute the reachable LUN sets {R1} for each host in the SAN graph;
Apply the impacts of SAN reconfiguration on the nodes/edges of SAN graph;
Recompute the reachable LUN sets {R2} for each host in the SAN graph;
hosts_impacted = false;
for each host hi in the SAN  do
Compute impacted LUN set {R3} = {R1} - {R2};
if {R3} is non-empty then
Compute criticality of losing LUN in {R3} using CRA on hi;          
hosts_impacted = true;
endif
endfor
if  hosts_impacted then 
Report Criticality of the operation recorded and return for 
future processing;
endif
end.
（アルゴリズム SAN_impact（入力されたＳＡＮグラフ，
入力された、すべてのホストのコンポーネント階層，
入力された、ＳＡＮにおいて追加／除去されたコンポーネント，
データセンターレベルにおける出力される影響）
begin
ＳＡＮグラフにおける各ホストの到達可能なＬＵＮの集合｛Ｒ１｝を計算する；
ＳＡＮグラフのノード／枝に対するＳＡＮ再構成の影響を適用する；
ＳＡＮグラフにおける各ホストの到達可能なＬＵＮの集合｛Ｒ２｝を再計算する；
hosts_impacted = false；
for each ＳＡＮにおけるホストｈｉ do
影響を受けるＬＵＮの集合｛Ｒ３｝＝｛Ｒ１｝−｛Ｒ２｝を計算する；
if ｛Ｒ３｝が非空である then
ｈｉ上でＣＲＡを使用して｛Ｒ３｝のＬＵＮを喪失することのクリティカリティを計算する；
hosts_impacted = true；
endif
endfor
if hosts_impacted then
記録されたオペレーションのクリティカリティを報告し、その後の処理のために返す；
endif
end.）
【００５０】
加えて、デバイスクリティカリティ報告は、解析の全体結果及び全体結果の理由も提供することができる。この実施形態では、全体結果は、成功、警告、データクリティカル、又はシステムクリティカルのいずれかである。
【００５１】
全体結果が成功である場合、これは、本技法が、影響を受ける資源を発見しなかったことを示し、ユーザには、成功メッセージが提供され、再構成オペレーションを進めることが可能にされる。
【００５２】
さらに、全体結果が警告である場合、これは、本技法が、１つ又は２つ以上の影響を受ける資源を発見したことを示している。一方、これらの影響を受ける資源には、低深刻度レベル（又は警告レベル）が割り当てられており、いずれにも、中深刻度レベル（又はデータクリティカルレベル）も高深刻度レベル（又はシステムクリティカルレベル）も割り当てられていない。ユーザには、影響を受ける資源がシステムオペレーションにとってクリティカルと考えられないことを明示する警告メッセージが提供され、再構成オペレーションを進めることが可能にされる。
【００５３】
続いて、全体結果がデータクリティカルである場合、これは、本技法が、１つ又は２つ以上の影響を受ける資源を発見したことを示している。一方、これらの影響を受ける資源の少なくとも１つには、中深刻度レベル（又はデータクリティカルレベル）が割り当てられており、いずれにも、高深刻度レベル（又はシステムクリティカルレベル）は割り当てられていない。ユーザには、システムに記憶されたデータが、おそらく又は場合によっては喪失されるが、システムはおそらくクラッシュもしないし、不健全／故障状態にも入らないことを明示するデータクリティカルメッセージが提供される。さらに、報告は、再構成による影響を受ける可能性のあるデータセンターのすべてのプロセスをリスト又は列挙することができる。次に、プロセスレベルの影響をより大きなアプリケーションレベルの影響にマッピングすることができる。
【００５４】
全体結果がシステムクリティカルである場合、これは、本技法が、１つ又は２つ以上の影響を受ける資源を発見したことを示している。一方、これらの影響を受ける資源の少なくとも１つには、高深刻度レベル（又はシステムクリティカルレベル）が割り当てられている。ユーザには、システムがクラッシュするか又は不健全／故障状態に入る可能性があることを言明するシステムクリティカルメッセージが提供される。この場合、ユーザが再構成オペレーションを進めることが阻止される。
【００５５】
本技法の上記変形形態のいずれも、適した汎用コンピュータをプログラミングすることによって実施することができる。プログラミングは、コンピュータによって読み出し可能なプログラムストレージデバイスの使用、及び、上述したオペレーションを行うコンピュータにより実行可能な命令から成るプログラムをコーディングすることを通じて達成することができる。
【００５６】
本明細書に含まれるフローチャートは、必ずしも、単一のホットプラグイベントにおける実行を表すものではなく、むしろ、いくつかの例では、複数のホットプラグオペレーションで行われる一連の協調したステップ、イベント、又はプロセスを表すことができる。加えて、本明細書のフローチャートは、図面に明示的に表されたイベント、ステップ、又はプロセスの間で、他のイベント、ステップ、又はプロセスを行うことができないことを暗に意味するものと解釈されるべきではない。
【００５７】
本発明の特定の実施形態の上記説明は、例示及び説明の目的で提示されたものである。それら説明は、網羅的であることを目的とするものでもなければ、開示した厳密な形に本発明を限定することを目的とするものでもなく、上記教示に鑑み、多くの変更及び変形が可能である。本実施形態は、本発明の原理及びその実用的な用途を最も良く説明し、それによって、他の当業者が、本発明及びさまざまな変更を有するさまざまな実施形態を、意図される特定の使用に適するように最良に利用することを可能にするために選ばれて説明されたものである。本発明の範囲は、本明細書に添付した特許請求の範囲及びその均等物によって規定されることが意図されている。
【図面の簡単な説明】
【００５８】
【図１】ＳＡＮ構成の概略図である。
【図２】ＳＡＮグラフの構築に関与するステップを示すフローチャートである。
【図３】ＳＡＮ再構成オペレーションのデバイスクリティカリティを求める方法に関与するステップを示す図である。
【図４】ＳＡＮ構成のホストレベルにおけるデバイスクリティカリティを求めることに関与するステップを示す図である。
【図５】ネットワークの論理パス及び物理パスを求めるプロセスを示す図である。
【図６】システムのホストでデバイスクリティカリティ解析を行うコンポーネント階層グラフのトラバースのフローチャートの一例を示す図である。
【図７】ＳＡＮ構成におけるホストバスアダプタのコンポーネント階層グラフの一例を示す図である。
【符号の説明】
【００５９】
１・・・ネットワーク
２ａ〜２ｃ・・・ホスト
３ａ〜３ｅ・・・データリンク
４ａ、４ｂ・・・スイッチ
５ａ〜５ｄ・・・ストレージエレメント
６ａ〜６ｆ・・・ホストバスアダプタ
７ａ〜７ｄ・・・コントローラ
８・・・ファブリック
９・・・サブコンポーネント
１０・・・論理ユニット番号
１１・・・ローカルエリアネットワーク
１２ａ、１２ｂ・・・クライアントコンピュータ
【図１】
2009015826.tif 000003
【図２】
2009015826.tif 000004
【図３】
2009015826.tif 000005
【図４】
2009015826.tif 000006
【図５】
2009015826.tif 000007
【図６】
2009015826.tif 000008
【図７】
2009015826.tif 000009
【外国語明細書】
A Method and a System to Determine Device Criticality during SAN Reconfigurations
Background of the Invention
A data center is a facility used for housing a large amount of electronic equipment, typically computers and communication equipments.  Typical components of a data center may include Servers; Storage Devices; Storage Area Network Components, like inter-connection cables, switches, hubs; and Data network elements, like LAN cables and switches/hubs.  A storage area network (SAN) is a network designed to attach computer storage devices to servers.  A SAN allows a machine to connect to remote targets such as disks and tape drives on a network for block level I/O.  
In storage area networks the storage elements do not belong to individual servers. Instead, the storage elements are directly attached to the network and storage is allocated to the servers when required.  The storage elements may be located remotely of the server systems.  Therefore, even if the infrastructure containing the server systems is destroyed, the data may still be recovered.  Moreover, the relocation of the host systems in the network is made easier because the storage elements need not be moved with the host systems.  Additionally, the upgrade of the network may be easier because the hosts do not have to be upgraded individually in their separate locations.  Yet further, if one server malfunctions the downtime of the system is reduced because a new server can quickly be set up and pointed at the relevant storage volumes in the storage elements without the need of recovering the data.
A network of data links including a plurality of switches is used to connect the servers and the storage elements in a SAN.  To further reduce the downtime of the network as a result of a failure of one or more of the components, redundant links are often included between the servers and the storage elements such that if one link malfunctions another one can be used and the network can be used without interruptions. To manage the system and ensure that there are enough redundant paths, a management program is often used.  The downtime of the system can further be reduced if the management program may analyse faults, assess the state of the network and ensure that the input/output continuity is maintained with optimal performance.
It is not uncommon for an administrator to perform maintenance and/or reconfiguration operations on the components that make up a data center.  IT consolidation, hardware and software upgrades are some of the common reasons for such operations.
In a storage area network, before performing the maintenance operations the administrator will be interested in assessing the potential system and/or application level impacts in terms of availability and performance.  The impact analysis of maintenance operation forms a core part of Application Management systems.  Hence before planning and executing such maintenance operations, the administrator may be interested in knowing the answers for questions such as - "What would be impacted if I remove/replace this cable?", "What would happen to systems/applications if I temporarily take this storage device offline for maintenance work?", "Which applications are affected in my data center if a disk array controller or a disk in a enclosure is replaced/affected?".
Brief Description of the Drawings
Embodiments of the invention will now be described by way of example only, with reference to accompanying drawings, wherein:
Figure 1 is a schematic diagram of a SAN configuration.
Figure 2 is a flow chart illustrating the steps involved in building a SAN graph.
Figure 3 illustrates steps involved in a method for determining the device criticality for a SAN reconfiguration operation.
Figure 4 illustrates steps involved in determining the device criticality at host level in a SAN configuration.
Figure 5 illustrates a process of determining the logical and physical paths in the network.
Figure 6 illustrates an example of a flow chart for traversal of component hierarchy graph for performing device criticality analysis on host of a system.
Figure 7 illustrates an example of a component hierarchy graph of a host bus adapter in a SAN configuration.
Detail Description of the Embodiments
Reference will now be made in detail to embodiments of the present invention, examples of which are illustrated in the accompanying drawings.  While the invention will be described in conjunction with these embodiments, it will be understood that they are not intended to limit the invention to these embodiments.  On the contrary, the invention is intended to cover alternatives, modifications and equivalents, which may be included within the spirit and scope of the invention as defined by the appended claims. Furthermore, in the following detailed description of the present invention, numerous specific details are set forth in order to provide a thorough understanding of the present invention.
There will be described a technique to determine the criticality or side-effects of a SAN reconfiguration operation in a data center by using Critical Resource Analysis (CRA) functionality and mapping the data center events to the host system level events.  The technique employs an Impact Analysis Agent (IAA) to be deployed on each host of the data center.  A central agent provided at a data center administrator node may aggregate the results from each of the Impact Analysis Agents across the data center and provide a consolidated report to the data center administrator.  The central agent may consist of a SAN generation unit.  The technique will now be described in more detail with reference to the enclosed drawings.
With reference to Figure 1, a network 1 comprises a plurality of hosts 2a, 2b, 2c, connected to a plurality of data links 3a, 3b, 3c, 3d, 3e, a plurality of switches 4a, 4b and a plurality of storage elements 5a, 5b, 5c and 5d. The hosts may include but are not limited to servers 2a, 2b, 2c and client computers. The data links may include but are not limited to Ethernet interfaces connections, Fibre Channels and SCSI (Small computer System Interface) interfaces, for instance. The storage elements comprise disk drives and/or disk arrays 5a, 5b, 5c and tape drive arrays 5d. 
Each host is connected to each storage element by at least two paths such that if a component or a data link in one path fails, data may still be exchanged between the host and the storage element using another path.  Each server 2a, 2b, 2c therefore has at least one host bus adapter (HBA) 6a - 6f for connecting to the switches through data links 3a, 3b.  Similarly, each storage element 5b or cluster of storage elements has at least one controller 7a-7d for connecting to the data links 3c, 3d, 3e.  The role of the HBAs 6a-6f is to provide the interface between the host and the attached data link.  They may further provide input/output processing to offload most of the host processing required for transferring data.  The controllers 7a-7d perform a similar role for the storage elements.  Like the switches, the HBAs and the controllers may also have more than one port to provide alternative paths.  In Figure 1, port 6e is shown to have two ports.  The network of HBAs 6a-6f, data-links 3a-3e, switches 4a, 4b and controllers 7a-7d that connect the hosts and the storage elements make up what is known as the fabric 8. 
Each component of the SAN has a number of subcomponents 9, any one of which may affect the performance of the system. For example, each switch may have one or more ports, fans and/or power supplies.
Each host system 2a, 2b, 2c, is allocated a storage area which may be accessed through the fabric channels 8.  The storage area may be distributed over different storage elements.  The storage area may further be typically classified into a number of Logical Unit Numbers (LUNs) 10, each of which corresponds to an actual or virtual portion of a storage element.  For example, a LUN 10 may correspond to one or more disks in a disk drive array. 
The servers may be connected in a local area network (LAN) 11 to a number of client computers 12a, 12b.  The client computers may be directly connected to the SAN with their own data links, such as fibre channels, or indirectly connected via the LAN and the servers.
Figure 3 illustrates the steps involved in determining the device criticality during SAN reconfiguration on a data center.  In an embodiment, the present technique may be implemented as computer-executable instructions for performing the method 300 for determining device criticality for hot plugging in a SAN reconfiguration operation.  The computer-executable instructions can be stored in any type of computer-readable medium, such as a magnetic disk, CD-ROM, an optical medium, a floppy disk, a flexible disk, a hard disk, a magnetic tape, a RAM, a ROM, a PROM, an EPROM, a flash-EPROM, or any other medium from which a computer can read. 
In order to determine the impact on the SAN of an event related to the state of one or more components, the connections in the SAN must be identified and analysed.  If a component is part of a path between a host 2 and a LUN 10 and the path is the only available path between the two components, the removal of the path will be  critical to the performance of the system.  However, if the path is just one of a large number of paths from host system to LUN 10 through the SAN 9, the fault has only a minor effect.  Any alternative paths are referred to hereinafter as redundant paths.
At step 301 of Figure 3, the algorithm gathers information of the data center to build a SAN connectivity graph (referred to as "SAN Graph" from hereafter in the description).    The edge nodes of the graph may be the LUNs exported by the disk arrays and the host bus adapters (HBA) ports of the hosts systems and/or server systems.  Disk arrays, enclosures and controllers may be used to logically group the nodes of SAN graph so that any operation that impacts these components may be used to mark all the nodes of the logical group as "impacted".  The SAN infrastructure components like the switches, hubs, cables etc., may be mapped as the intermediate nodes and edges in the SAN graph.  An algorithm for building SAN graph, as an example, is briefly described with respect to Figure 2.
At step 201, the SAN graph generation unit receives instructions to generate a SAN graph. This is received when the user desires to reconfigure the SAN. In some embodiments, instructions to the SAN graph generation unit to regenerate the SAN graph may be communicated with a predetermined frequency, which is configurable by the user. 
The SAN connectivity generation unit retrieves, at step 202, the information about the first component of the SAN from which information has been collected since the last time a SAN graph was generated.  The information received for the component may comprise vendor and model data, an identification number, for example a World Wide Name (WWN), and connectivity information allowing the SAN graph generation unit to determine the neighbours of the component.  The SAN connectivity generation unit also may check whether information about the component already exists in the SAN graph database, i.e. whether the collected data concerns a known component or if a new component has been added to the network.  In case of the component being a new component, the SAN connectivity generation unit at step 204, assigns a unique identification number to the component.  After assigning the identification number the component may be classified as edge or the vertex.  
The components of the network may be split into two sets, vertices and edges.  The set of vertices may include of the set of HBAs, the set of switches, the set of storage array controllers and the set of Logical Unit Numbers.  The set of edges is the set of data-links that connect the vertices, for example fiber channel cables.  Two vertices can be connected by one or more edges.  After the identification the component is stored in SAN database 206.
After gathering the relevant information about a component, the SAN connectivity generation unit may check at step 207 whether the data collected contain information about further components.  If there is no information about additional components, the process ends at step 208.  If the collected data contain information about further components, the process repeats from step 202.
When information about all components has been added, the graph is linked at step 208.  Linking the graph involves checking all the connections, determining all paths between a source component and a destination component and organising the data to be presented in a suitable way in the GUI to the administrator of the system.
The process of determining all paths between a source component and a destination component will now be described in more detail with respect to Figure 5.  At step 501, the dummy variable n is set to 0. Subsequently, the record for the vertex with identification number vn, in this case v0, is retrieved at step 502 from the SAN graph in SAN graph database 30.  Dummy variable m also set to 0 at step 503 and the record for vm is retrieved at step 504.
At step 505 it is determined if there are any valid access paths between vn and vm.  The edges in the SAN graph are directional from a host to a LUN.  An access path may only be established in the direction from a host to a LUN.  Therefore, for example, the paths between server 2a and 2c are not established, because that involves an edge going in the wrong direction.  This step insures that only paths of interest are established and that paths between two vertices are only established once.  For vn equal to v0 and vm also equal to v0, it is established at step 505 that there are no available valid paths, m is therefore increased by 1 at step 506 and it is then established at step 505 whether there are any valid paths between v0 and v1.  When v0 corresponds to server 2a and v1 corresponds to LUN 10, it is determined at step 505 that there are valid paths and the process continues to step 507.
Both the physical paths and the logical paths are established for the pair of vertices vn and vm.  A physical path is the sequence of vertices between the pair of components. A logical path is the sequence of edges. 
A physical path is established between vertex v0 and vertex v1 at step 506 and identification numbers of the vertices in that path are stored in a high availability (HA) map in the SAN graph database.  For server 2a and LUN 10, the path includes HBA 6a, switch 4a and controller 7a. 
At step 507 it is checked whether there are alternative physical paths between host v0 and LUN v1.  If it is established that there are alternative paths, step 506 is repeated and it is determined that an alternative path of HBA 6a, switch 4a and controller 7b exists.  Steps 506 and 507 are repeated until all valid paths are found between the pair of nodes.  The third and last path of HBA 6b, switch 4b and controller 7b is therefore also found.  All of the paths are stored in the physical high availability (HA) map, HAp (v0,v1), in the SAN graph database with their respective sequences of vertices. 
When there are no more alternative physical paths, the process continues to step 508 and a logical path between the two vertices is established.  In the example discussed above, one logical path between host 2a and LUN 10 includes edges 3a and 3c.  At step 509 it is determined whether there are alternative logical paths and, if there are, step 508 is repeated.  In the example above, two additional paths, consisting of edges 3a and 3d and edges 3b and 3e respectively are found. All paths are then stored in a logical HA Map HAL (v0, v1) in the SAN graph database with their respective sequences of edges. 
When all the logical paths have been stored it is determined at step 509 that there are no more paths between v0 and v1, the process continues to step 510 and it is checked whether there is a vertex with a higher identification number than m.  If there are, m is increased by 1 at step 512 and steps 504 to 509 are repeated for all paths between v0 and v2.  When the valid paths between vertex v0 and all other vertices have been established, it is determined at step 510 that there are no more vertices and the process proceeds to step 511.  If there are, n is increased by 1 and steps 502 to 511 are repeated. The steps are repeated until the valid paths between all pairs of vertices in the system have been established and stored as physical and logical HA Maps. 
Each host system node in the SAN graph may maintain a number of LUN nodes reachable, which is also referred to as the "reachable LUN set" in this description. 
According to an embodiment, a component hierarchy graph (CHG) may be built for each host system of the data center, at step 302 of Figure 3.  The CHG is a graph mapping the elements of hardware as well as software from PCI bus onwards, down to the processes currently running on the host system.  The process nodes are at the leaf or last level in CHG.  The nodes at different levels of CHG may comprise of PCI slots, HBAs, HBA ports, LUN paths (also referred as edges from HBA port to LUNs), LUNs, Logical Volumes, Volume Groups, File Systems and processes.  The edges in the CHG may indicate that the successor node is using and/or is dependent on the predecessor node.  Thus, if a predecessor node is impacted and/or unavailable, the successor may also be unavailable, unless redundancy or alternative paths are available.  A typical component hierarchy graph of a host system is depicted in Figure 7 as an example.  The component hierarchy graph for host system may be represented in the form of a directed acyclic graph (DAG).
The component hierarchy graph may include at each node certain attributes associated with each of the components of the computer system.  These attributes may be a redundancy attribute, a criticality attribute or a usage attributes, for instance.  The redundancy attribute may consist of number of redundant paths for the particular node.
The SAN graph and the component hierarchy graph of the host systems in a SAN can be prepared and stored at the boot time. Since the configuration of the SAN and/or host system does not change frequently, this may reduce the time in resource analysis.  The changes in configurations of SAN may be reflected in the SAN graph and/or CHG.  The SAN graph and CHG may be stored with central agent.
During the SAN reconfiguration operation, user indicates a desire to perform an online hot plug operation for example, adding, replacing, or removing a device(s) of a SAN in the data center.  Here, it is assumed that the user knows which device(s) will be involved in the attempted reconfiguration operation.
Continuing at step 303 of Figure 3, the SAN reconfiguration event is mapped to deletion and/or addition of edges and/or nodes into the SAN graph.  The link removal and port removal events in the SAN reconfiguration may be mapped to edge removals in the SAN graph and addition/removal of controllers.  Similarly the removal of switches and disk device enclosures may be mapped to node addition/removal operations.  The SAN reconfiguration operation in a data center perspective, may involve one or more of the components of the SAN from the group of the link from the server system to the switch, the SAN switch(es), the link from the switch to the disk device, the device port/controller unavailability, the host system port (through a Host Hot-Plug operation). 
According to an embodiment, the SAN reconfigurations operations in data center may be mapped to a host level impact in the following way.  An impact on the link from the server system or the host system to the switch may be mapped to a hot-plug of the HBA for the host system.  An impact on the disk device port, the corresponding "LUN paths" on the hosts system that use the LUNs exported by the device and/or disk-array are considered impacted.  If the link from a switch to a device port is affected, it may be considered to be equivalent to a device port impact and the host systems using that LUNs under the device port to which the link is connected would be considered impacted.  If a switch is affected, each link associated with that switch may be affected and may be mapped in the SAN graph in form of impact on host systems and device systems.  The impact of a switch on other switches in the SAN through inter-switch-links (ISLs), and indirectly on other hosts systems and devices connected to the SAN is a well known graph theory problem of reachability of nodes and techniques exist to determine if an edge node loses path to another edge node (host/device) owing to loss of a node/edge (switch/ISL) in the graph.  Thus, we can map the switch impacts to LUN path level impacts on the hosts connected to the SAN. 
Continuing to step 304 of Figure 3, the impacted hosts in the data center are identified.  The algorithm for identifying the impacted hosts of the data center is illustrated in Figure 4.  The IAA invokes the device criticality analysis algorithm on the host system if the host system is determined to be impacted.  An example of the algorithm for determining device criticality on a host system is illustrated in Figure 6. 
Further continuing to step 305 the device criticality data is accumulated from all the affected host systems across the data center.  A central agent will aggregate the results received from the IAA across all the host systems and may provide a consolidated report to the data center administrator.  The data center administrator may refer to the consolidated report for SAN reconfiguration operations.   
Figure 4 illustrates the algorithm for determining the impacted hosts in a data center of the step 304 of Figure 3 in detail.  
At step 401 the set of reachable LUNs for each of the host systems in the data center is computed before the SAN reconfiguration operation.  The set of reachable node before SAN reconfiguration operation is also referredto as {R1} in this description.  The set of reachable LUNs for a host system may be obtained by algorithm described in Figure 4.  This data is stored with local IAA agent at the host system node.  At step 402 the IAA computes the set of reachable LUNs for a host system (also referred as {R2} in this description) after mapping the SAN reconfiguration operation in the SAN graph.  The set of reachable LUNs {R2} for a host system may be different from {R1} after the SAN reconfiguration operation because of loss of an edge and/or access path.
Continuing to step 403 of Figure 4, the set of LUNs lost by the host system is computed. The set of LUNs lost by a host system may be obtained by computing the difference between the set of reachable LUNs for a host system before mapping of SAN reconfiguration operation in the SAN graph {R1} from the set of LUNs reachable for a host system after the mapping of the SAN reconfiguration operation {R2}.  The number of lost LUNs for a host system is also represented by {R3}; (|{R3}| = |{R1}-{R2}|) in this description.
Further continuing to Step 404, if the set of LUNs lost {R3} by the host system is empty then the host system may be declared as "not impacted" 405.  Since the set of reachable LUNs for a host system is same before and after i.e. {R1} = {R2}, the mapping of SAN reconfiguration operation in the SAN graph, the particular host system is not impacted by the SAN reconfiguration operation.
If the set of LUNs lost {R3} by the host system is not empty then the particular host system is marked as "impacted" 406.  Since the set of reachable LUNs for host system is not the same before and after the mapping of SAN reconfiguration operation in the SAN graph, the particular host system is impacted by the SAN reconfiguration operation. The impact may be because of the host system losing its LUN(s) after removal of edges and/or nodes from the SAN graph during the mapping of the SAN reconfiguration operation.
At step 407, if a host system is marked as "impacted", the critical resource analysis (CRA) algorithm is evoked to determine the affected resources.  The CRA algorithm determines the number of affected resources in the host system.  The device criticality report obtained from the CRA algorithm may be stored with the local IAA or sent directly to the central agent.  The CRA algorithm may traverse the component hierarchy graph stored with IAA on the host system to determine the affected resources.
According to an embodiment the resource analysis may be carried out by traversing the CHG of the host system.  Figure 6 is a flow chart depicting the CHG traversal algorithm to determine the impacted nodes using the redundancy attributes associated with the nodes of CHG.  The resource criticality may be obtained by checking the uses attribute and criticality attributes associated with the nodes marked as impacted.
Continuing to step 408, the list of affected resources is obtained from the CRA algorithm. The list of affected resources may be made available to the central agent by IAA on the host system.  The central agent may aggregate the lists from the IAA and build a consolidated list inclusive of all the affected resources across the data center.  The aggregation may be simply the union of lists from each of the IAA across the data center.  The aggregated list may be presented to the user for their reference.
Example pseudo code for the algorithm for determining the device criticality during SAN reconfigurations is as follows:
algorithm SAN_impact( input SAN Graph, 
input Component Hierarchy of all hosts, 
input  components added/removed in SAN,
output Impacts at data center level)
begin
Compute the reachable LUN sets {R1} for each host in the SAN graph;
Apply the impacts of SAN reconfiguration on the nodes/edges of SAN graph;
Recompute the reachable LUN sets {R2} for each host in the SAN graph;
hosts_impacted = false;
for each host hi in the SAN  do
Compute impacted LUN set {R3} = {R1} - {R2};
if {R3} is non-empty then
Compute criticality of losing LUN in {R3} using CRA on hi;                hosts_impacted = true;
endif
endfor
if  hosts_impacted then 
Report Criticality of the operation recorded and return for 
future processing;
endif
end.
Additionally, the device criticality report may provide an overall result of the analysis and reason for the overall result.  In this embodiment, the overall result is either success, warning, data critical, or system critical. 
If the overall result is success, this indicates that the technique found no affected resources, wherein the user is provided a success message and allowed to proceed with the reconfiguration operation.
Furthermore, if the overall result is warning, this indicates that the technique found one or more affected resources.  However, these affected resources were assigned the low severity level (or warning level) but none were assigned the medium severity level (or data critical level) or the high severity level (or system critical level).  The user is provided a warning message stating that the affected resources are not deemed critical to system operation and allowed to proceed to the reconfiguration operation. 
Continuing, if the overall result is data critical, this indicates that the technique found one or more affected resources.  However, at least one of these affected resources was assigned the medium severity level (or data critical level) but none were assigned the high severity level (or system critical level).  The user is provided a data critical message stating that probably or possibly data stored in the system will be lost but probably the system will not crash or enter an unhealthy/failed state.  Furthermore, the report may list or enumerate all the processes in the data center that may be impacted because of the reconfiguration.  The process level impacts, in turn may be mapped to a larger application level impact.
If the overall result is system critical, this indicates that the technique found one or more affected resources.  However, at least one of these affected resources was assigned the high severity level (or system critical level).  The user is provided a system critical message stating that the system may crash or enter an unhealthy/failed state.  In this case, the user will be prevented from proceeding with the reconfiguration operation. 
Any of the foregoing variations of the present technique may be implemented by programming a suitable general-purpose computer.  The programming may be accomplished through the use of a program storage device readable by the computer and encoding a program of instructions executable by the computer for performing the operations described above.  
The flow charts included herein do not necessarily represent an execution in a single hot plugging event, but rather, in some instances, may represent a sequence of coordinated steps, events, or processes occurring in plurality of hot plugging operations.  In addition, the flow charts herein should not be interpreted as implying that no other events, steps, or processes can occur between those explicitly represented in the drawings.
The foregoing descriptions of specific embodiments of the present invention have been presented for purposes of illustration and description.  They are not intended to be exhaustive or to limit the invention to the precise forms disclosed, and many modifications and variations are possible in light of the above teaching.  The embodiments were chosen and described in order to best explain the principles of the invention and its practical application, to thereby enable others skilled in the art to best utilize the invention and various embodiments with various modifications as are suited to the particular use contemplated.  It is intended that the scope of the invention be defined by the Claims appended hereto and their equivalents.
Claims
1.    A method for determining device criticality for reconfiguration of a storage area network comprising the steps of:
building a storage area network connectivity graph;
identifying the host systems affected by a reconfiguration operation from storage area network connectivity graph; and
evoking a critical resource analysis algorithm for each affected host system to determine the affected resources on the affected host systems.
2.    A method as recited in claim 1, wherein a host system is determined as affected if the set of reachable LUNs is not the same before and after mapping of a reconfiguration operation onto the storage area network connectivity graph. 
3.    A method as recited in claim 1 further comprising: accumulating device criticality data generated by the critical resource analysis in each from affected host systems and generating a device criticality report for a data center administrator.
4.    A method as recited in claim 1 wherein the critical resource analysis is carried out by an impact analysis agent deployed on each of the host systems of the data center.
5.    A method as recited in claim 3 wherein the accumulating step is carried out by a central agent for aggregating the results from impact analysis agents and providing a consolidated report to data center administrator.
6.    A method as recited in claim 1 further comprising building a component hierarchy graph for each of the host system of data center.
7.    A method as recited in claim 6 wherein the component hierarchy graph is a directed acyclic graph.
8.    A method as recited in claim 6 further comprising storing usage attributes, redundancy attributes and/or criticality attributes in the component hierarchy graph.
9.    A method as recited in claim 1 further comprising traversing the component hierarchy graph of host systems for determining affected resources.
10.    A method as recited in claim 1 further comprising classifying the result of device criticality as success, warning, data critical, system critical, or error.
11.    A method as recited in claim 1 further comprising a graphical user interface for presenting the state of the SAN to a user and for recommending actions to the user.
12.    Apparatus for determining device criticality for a reconfiguration operation of a storage area network comprising:
a central agent for locating the host systems affected by a reconfiguration operation from a storage area network connectivity graph; and
an impact analysis agent for evoking a critical resource analysis algorithm for each affected host system to determine the affected resources on the affected host systems.
13.    Apparatus as recited in claim 12 wherein the central agent further comprises a SAN graph generation unit for generating the storage area network connectivity graph.
14.    Apparatus as recited in claim 12, wherein the impact analysis agent is arranged to generate the component hierarchy graph for a host system.
15.    Apparatus as recited in claim 12 wherein a host system is determined as affected if the set of reachable LUNs is not the same before and after mapping of a reconfiguration operation onto the storage area network connectivity graph 
16.    An impact analysis agent as recited in claim 14, further comprising an storage element for storing the list of affected resources generated by the critical resource algorithm.
17.    A central agent as recited in claim 12 further comprising accumulating the device criticality data from impact analysis agents and generating a device criticality report for data center administrator.
18.    Apparatus according to claim 10 comprising a graphical user interface for presenting the state of the SAN to a user and for recommending actions to the user.
19.    A computer program product for execution by a server computer for determining device criticality for reconfiguration of a storage area network comprising the steps of:
building a storage area network connectivity graph;
identifying the host systems affected by a reconfiguration operation from storage area network connectivity graph; and
evoking a critical resource analysis algorithm for each affected host system to determine the affected resources on the affected host systems.
20.    A computer program product as recited in claim 19, wherein a host system is determined as affected if the set of reachable LUNs is not the same before and after mapping of a reconfiguration operation onto the storage area network connectivity graph.
Abstract
A method, a system and a computer program for determining device criticality during SAN reconfiguration operations comprising the steps of building the SAN connectivity graph and mapping the reconfiguration on SAN connectivity graph; locating the affected host systems; and determining the device criticality for each of the affected host systems.  The hosts systems may also be provided with impact analysis agents to generate device criticality on host systems and a central agent to aggregate the device criticality from impact analysis agent and provide feedback to data center administrator. 
Figure 3
2009015826.tif 000010
2009015826.tif 000011
2009015826.tif 000012
2009015826.tif 000013
2009015826.tif 000014
2009015826.tif 000015
2009015826.tif 000016