(57)【要約】      （修正有）【課題】コンピュータシステムにおけるデバイスのクリティカリティを求める方法を提供する。【解決手段】方法はコンピュータ構成情報を使用してコンポーネント階層グラフを構築するステップと、コンポーネント階層グラフのノードを冗長性属性でラベリングするステップと、コンポーネント階層グラフをトラバースするステップと、コンポーネント階層グラフ内の冗長性属性を検査することによって、デバイスがアクセスパスを喪失するか否かを判断するステップとを含む。さらに、複数の深刻度レベルのうちの１つが、所定の基準に基づいて、特定された各被影響資源に割り当てられる。深刻度レベルには、低深刻度レベル、中深刻度レベル、及び高深刻度レベルが含まれる。各深刻度レベルは、特定された被影響資源の機能が利用不能になった場合のコンピュータシステムへの影響の程度を表す。【選択図】図３
2009048610.tif 000002
【特許請求の範囲】
【請求項１】
コンピュータシステムにおけるデバイスのクリティカリティを求める方法であって、
コンピュータ構成情報を使用してコンポーネント階層グラフを構築するステップと、
前記コンポーネント階層グラフのノードを冗長性属性でラベリングするステップと、
前記コンポーネント階層グラフをトラバースするステップと、
前記コンポーネント階層グラフ内の前記冗長性属性を検査することによって、前記デバイスがアクセスパスを喪失するか否かを判断するステップと
を含む方法。
【請求項２】
前記コンポーネント階層グラフは、前記システム内の論理構成体（logical construct）に関連付けられるノードを備える
請求項１に記載の方法。
【請求項３】
前記論理構成体は、論理ボリューム、ボリュームグループ、ファイルシステム、及びプロセスのうちの少なくとも１つを含む
請求項２に記載の方法。
【請求項４】
前記デバイスの前記クリティカリティに基づいて、該デバイスのオンラインホットプラグオペレーションを行うか否かを判断すること
をさらに含む請求項１に記載の方法。
【請求項５】
前記コンポーネント階層グラフは、非循環有向グラフ（directed acyclic graph）である
請求項１に記載の方法。
【請求項６】
前記デバイスは、周辺コンポーネントインターフェース仕様及びＰＣＩ−Ｘ仕様のうちの一方と互換性を有する
請求項１に記載の方法。
【請求項７】
前記コンポーネント階層グラフのノードは、利用属性を含む
請求項１に記載の方法。
【請求項８】
クリティカリティ属性が、前記コンポーネント階層グラフのノードに関連付けられる
請求項１に記載の方法。
【請求項９】
前記コンポーネント階層グラフは、前記コンピュータシステムのブート時間に構築される
請求項１に記載の方法。
【請求項１０】
前記コンポーネント階層グラフは、ユーザ空間及びカーネル空間の両方又はいずれか一方から取得される
請求項９に記載の方法。
【請求項１１】
あらゆる特定された被影響資源及び対応する深刻度レベルを含む資源解析情報に基づいて、オンラインホットプラグオペレーションを行うか否かを判断すること
をさらに含む請求項１に記載の方法。
【請求項１２】
前記オンラインカードオペレーションを行うか否かを前記判断することは、
前記特定された被影響資源のいずれにも前記中深刻度レベルが割り当てられていない場合で、該特定された被影響資源のいずれにも前記高深刻度レベルが割り当てられていない場合に、前記オンラインカードオペレーションを行うことを可能にすることと、
前記特定された被影響資源のいずれにも前記高深刻度レベルが割り当てられていない場合で、前記特定された被影響資源のうちの少なくとも１つに前記中深刻度レベルが割り当てられている場合に、ユーザからの許可を受け取ると、前記オンラインカードオペレーションを行うことを可能にすることと、
前記特定された被影響資源のうちの少なくとも１つに前記高深刻度レベルが割り当てられている場合に、前記オンラインカードオペレーションが行われることを阻止することと
を含む
請求項９に記載の方法。
【請求項１３】
前記被影響資源が前記資源解析を開始する前に機能していない場合に、前記資源解析を実行することなく、オンラインホットプラグオペレーションを行うこと
をさらに含む請求項１に記載の方法。
【請求項１４】
そのすべてのアクセスパスを喪失する前記デバイスの利用が、ユーザレベルプロセスに影響を与える場合には、アプリケーションレベルのクリティカリティ及びユーザアプリケーションのデータへのアクセスの喪失の両方又はいずれか一方を報告すること
をさらに含む請求項１２に記載の方法。
【請求項１５】
コンポーネント階層を表す非循環有向グラフデータ構造と、
前記コンポーネント階層をトラバースしてデバイスのクリティカリティを求める制御機構と
を備え、
前記コンポーネント階層グラフのノードは、冗長性属性でラベリングされている
コンピュータシステム。
【請求項１６】
前記コンポーネント階層グラフデータ構造は、該システム内の論理構成体に関連付けられるノードを備える
請求項１５に記載のコンピュータシステム。
【請求項１７】
前記コンポーネント階層のノードは、利用属性を含む
請求項１５に記載のコンピュータシステム。
【請求項１８】
前記デバイスの前記クリティカリティに基づいて、前記デバイスのオンラインホットプラグオペレーションを行うか否かを判断すること
をさらに含む請求項１５に記載のコンピュータシステム。
【請求項１９】
「クリティカリティ」属性が、前記コンポーネント階層グラフのノードに関連付けられる
請求項１５に記載のコンピュータシステム。
【請求項２０】
ホットプラグオペレーションの場合にコンピュータシステムにおけるデバイスのクリティカリティを求めるためのコンピュータプログラムであって、
コンピュータ構成情報を使用してコンポーネント階層グラフを構築することと、
前記コンポーネント階層グラフのノードを冗長性属性でラベリングすることと、
前記コンポーネント階層グラフをトラバースすることと、
前記コンポーネント階層グラフ内の前記冗長性属性を検査することによって、前記デバイスがアクセスパスを喪失するか否かを判断することと
を含むコンピュータプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、コンピュータ構成におけるホットプラグのデバイスのクリティカリティを求める方法及びシステムに関する。
【背景技術】
【０００２】
コンピュータサーバは、様々な用途に利用されている。インターネットを使用した商業者の仕入れ取引を実行するサーバシステム等のシステムは、通例、高可用性設計を有する。このような高可用性システムは、常に動作していると共に利用可能であるように設計される。したがって、たとえばメンテナンス、アップグレード、システムクラッシュ、トラブルシューティング等の何らかの理由でこれらのシステムの電源を切断してリブートする必要性は、可能な限り回避されなければならない。通常、これらのシステムは、複数の拡張スロットを有し、カードがそのスロットに結合される。マスストレージデバイス及びネットワークアダプタは、このようなカードを介して接続できるコンポーネントの例である。一般に、ケーブルを介して１つ又は複数のさらなるデバイスをカードに結合することができる。
【０００３】
高可用性を維持するために、オンラインカードオペレーション機能が、高可用性コンピュータシステム内に統合されている。オンラインホットプラグオペレーション機能は、ユーザ及びシステム管理者又はこれらのいずれか（ユーザ及び／又はシステム管理者）が、これらのシステムの電源を切断してリブートすることなくオンラインホットプラグオペレーションを実行することを可能にする。オンラインカードオペレーションの例には、カードをスロットに結合することによってシステムにカードを追加すること、スロットに結合されている既存のカードを別のカードと交換すること、及びシステムの実行中にスロットからカードを結合解除することによってシステムからカードを取り外すことが含まれる。これらのオンラインホットプラグオペレーションには、一般に、カードの追加、交換、又は取り外しが可能になる前に、カード用の特定のドライバを一時停止すること、及び、対象となるスロット（複数可）への電力を遮断することが必要とされる。一般に、スロット電力制御及びドライバは、これらのオンラインカードオペレーションを容易にすることができる。システムによっては、数個のスロット電源ドメインが構成され、各スロット電源ドメインのスロットは、共通の電源ラインを共有する。オンラインカードオペレーションが、或るスロット電源ドメインのいずれかのスロットで実行される場合、そのスロット電源ドメインのすべてのスロットが、電力を失うおそれがあり、オンラインカードオペレーションを実行する複雑度が増大する。
【０００４】
このようなオンラインホットプラグオペレーションの前に、通常、資源解析がコンピュータシステム上で行われる。この資源解析は、カードの筐体全体がコンピュータシステムの実行中にコンピュータシステムから取り外される場合等、数群のカードが単一のオペレーションでオフラインにされる場合にも有用な場合がある。また、資源解析は、「クリティカル資源解析」（critical resource analysis）（ＣＲＡ）と呼ばれる場合がある。ＣＲＡは、カード（複数可）の追加、交換、又は取り外しのような、試みられる任意のオンラインホットプラグオペレーション例に関与する任意のカードに関連付けられる各スロットの電源を切断することの影響を解析して報告することができる。これは、システムの被影響資源を特定することを必要する場合がある。従来、特定された被影響資源には、低深刻度レベル又は警告レベル、及び、高深刻度レベル又はクリティカルレベルが割り当てられる。特定された被影響資源が、システムオペレーションに必須である場合には、それらの資源にはクリティカルレベルが割り当てられる。これは、スロット（複数可）の電源が切断されて、そのスロットに結合されているカード（複数可）の機能が利用不能になった場合に、システムがクラッシュする可能性があるか、又は危険／故障状態に入る可能性があることを示している。特定された被影響資源にクリティカルレベルが割り当てられている場合には、システムが実行し続けて所望のシステム可用性レベルを維持するように、ユーザは、一般に、オンラインカードオペレーションを実行することを阻止される。特定された被影響資源が「システムオペレーションに必須」であるか否かを判断する方法は、システムが異なると変化する場合がある。特定された被影響資源がシステムオペレーションに必須でない場合には、それらの資源には、警告レベルが割り当てられる。これは、スロット（複数可）の電源が切断されて、そのスロットに結合されているカード（複数可）の機能が利用不能になった場合に、システムがクラッシュする可能性もなければ、危険／故障状態に入る可能性もないことを示している。
【０００５】
一般に、ＣＲＡは、カード及び／又はスロット、並びに、それに関連付けられる資源／デバイスが、システムオペレーションに必須であるか否かを結論付けるために一連のチェックを行う。ＣＲＡ機能は、システムの実行を維持し、不注意なリブートを回避すると共に、システムが危険状態になることを阻止することを目的としている。
【発明の開示】
【課題を解決するための手段】
【０００６】
本発明にかかる方法は、コンピュータシステムにおけるデバイスのクリティカリティを求める方法であって、コンピュータ構成情報を使用してコンポーネント階層グラフを構築するステップと、前記コンポーネント階層グラフのノードを冗長性属性でラベリングするステップと、前記コンポーネント階層グラフをトラバースするステップと、前記コンポーネント階層グラフ内の前記冗長性属性を検査することによって、前記デバイスがアクセスパスを喪失するか否かを判断するステップとを含む。
【０００７】
ここで、添付の図面を参照して、本発明の実施の形態を例示としてのみ説明する。
【発明を実施するための最良の形態】
【０００８】
次に、本発明の実施形態を詳細に参照する。これらの実施形態の例は、添付の図面に示されている。本発明をこれらの実施形態との関連で説明するが、実施形態は、本発明をこれらの実施形態に限定することを目的とするものではないことが理解されよう。逆に、本発明は、代替形態、変更形態、及び均等物をカバーすることを目的としている。これらの代替形態、変更形態、及び均等物は、添付の特許請求の範囲によって画定される本発明の精神及び範囲内に含めることができる。さらに、本発明の以下の詳細な説明では、本発明の徹底した理解を提供するために、多数の具体的な詳細が述べられる。
【０００９】
被影響デバイスへの複数存在し得るパスを含めて、コンポーネント階層を非循環有向グラフ（directed acyclic graph: ＤＡＧ）で表すことによって、コンピュータ構成におけるホットプラグオペレーションに関するデバイスのクリティカリティを求める方法、システム、及びコンピュータプログラムが説明される。
本説明の以下の部分において、「資源解析」及び「デバイスのクリティカリティ解析」という用語は、交換可能に使用される。
【００１０】
図１は、簡単な高可用性コンピュータ構成の一例を示している。この高可用性コンピュータ構成は、コンピュータシステム１００から構成することができる。コンピュータシステム１００は、周辺デバイスディスクｄｓｋ１  １０４及びｄｓｋ２  １０５にこのコンピュータシステム１００を接続するための３つのホストバスアダプタＨＢＡ１  １０１、ＨＢＡ２  １０２、及びＨＢＡ３  １０３を備えることができる。周辺デバイスディスクは、ホストバスアダプタによってアクセスされるメモリディスクデバイス又は一群のメモリディスクデバイスとすることができる。上記コンピュータシステムは、ディスクミラーリングを管理するためのソフトウェア、たとえばボリュームマネージャ、及び、ミラードデバイス１０６も備えることができる。このようなコンピュータシステムは、コンピューティング環境の要件に応じて、任意の個数のホストバスアダプタから構成することができる。同様に、周辺デバイスｄｓｋ１  １０４及びｄｓｋ２  １０５は、単一のデバイスディスク及び／又は一群のデバイスディスクを備えることができる。或るコンピュータにおける周辺デバイスｄｓｋ１  １０４及びｄｓｋ２  １０５を、たとえば、周辺コンポーネント相互接続（ＰＣＩ）バスを介してマザーボードに接続することができる。
【００１１】
一例として、図１のホストバスアダプタ（ＨＢＡ１）１０１がホットプラグされる場合（交換オペレーション又は削除オペレーションのいずれか）において、ディスクデバイスが、重要なデータを記憶するためにシステムのプロセスによって使用中であるか、又は、システムのオペレーティングシステム（ＯＳ）によって使用されているときは、従来のＣＲＡ計算は、そのオペレーションにクリティカルのフラグを立てる。しかしながら、ディスクデバイス１０４には、冗長アクセスパスによってＨＢＡ２  １０２を通じてアクセス可能であり続けるため、このオペレーションを許可することができる。さらに、ホットプラグオペレーションが、ホストバスアダプタＨＢＡ１  １０１及びＨＢＡ２  １０２に関して要求された場合には、ＣＲＡ計算は、ディスクデバイス１０４及び１０５が影響を受けることを検出すべきである。しかしながら、ディスクデバイス１０４及び１０５は、ソフトウェア、この場合はボリュームマネージャによってミラーリングされているため、ＣＲＡは、これを検出して、性能劣化及びミラーリングの喪失の可能性があることを「警告」としてユーザに報告し、ディスクデバイスの喪失がコンピュータシステムの故障をもたらす可能性がないため、ホットプラグオペレーションを許可すべきである。
【００１２】
以下では時にＤＡＧと略される非循環有向グラフは、有向閉路を有しない有向グラフである。ＤＡＧでは、任意の所与の頂点ｖに関して、ｖで開始してｖで終了する非空の有向パス（non empty directed path）はない。非循環有向グラフは、頂点がそれ自身へのパスを有することが意味をなさない場合があるモデルにおいて現れる。たとえば、枝（edge）ｕ→ｖが、頂点ｖが頂点ｕの一部であることを示す場合に、このようなパスは、頂点ｕが、それ自身の一部であることを示し、これは、起こり得ない可能性がある。
【００１３】
非循環有向グラフは、その頂点に関する半順序関係に対応しうる。ＤＡＧの所与の２つの頂点ｕ及びｖに関して、頂点ｕから頂点ｖへの有向パスがグラフに存在するときに、ｕ→ｖは、まさに半順序関係にある。一方、多くの異なる非循環有向グラフは、このようにして同じ半順序関係を表すことができる。ＤＡＧでは、ソースは、入力する枝を有しない頂点である。同様に、シンク（sink）は、出力する枝を有しない頂点である。有限ＤＡＧは、少なくとも１つのソース及び少なくとも１つのシンクを有する。ＤＡＧの長さは、最も長い有向パスの長さ（枝の個数）である。非循環有向グラフの一般的な構造を図６に示す。
【００１４】
図１に示すようなコンピュータ構成では、デバイスディスク１０４等のデバイスには、ホストバスアダプタが２つ以上の規定されたパスを通じてアクセスすることができる。たとえば、図１では、デバイスディスク１０４には、２つの異なるホストバスアダプタＨＢＡ１  １０１及びＨＢＡ２  １０２が２つのパスを通じてアクセスすることができる。ここで、本説明では、複数のアクセスパスを有するこのようなデバイスは、冗長の程度としてパスの個数を用いて冗長であるとラベリングされる。これらのデバイスパス、すなわち、デバイスをホストバスアダプタに接続するパスは、コンポーネント階層グラフの枝の形で表すことができる。一例として、コンポーネント階層グラフの形による、より複雑なコンピュータシステムのコンポーネント階層を図２に示す。
【００１５】
コンポーネント階層グラフとして図２に示すコンピュータ構成は、３つのホストバスアダプタ（ｈ１、ｈ２、及びｈ３）並びにこれらのホストバスアダプタに接続される７つのディスクデバイス（ｄ１、ｄ２、ｄ３、ｄ４、ｄ５、ｄ６、及びｄ７）から成る。ディスクデバイスは、１０個のデバイスパスＰ１、Ｐ２、Ｐ３、Ｐ４、Ｐ５、Ｐ６、Ｐ７、Ｐ８、Ｐ９、及びＰ１０を介してホストバスアダプタに接続されている。たとえば、ディスクデバイスｄ１は、２つのパスＰ１及びＰ２を通じてホストバスアダプタに接続されている。同様に、ディスクデバイスｄ３は、パスＰ４及びＰ５を通じて接続されている、したがって、コンポーネント階層グラフにおけるディスクデバイスｄ１及びｄ３に対応するノードは、冗長ノードである。したがって、コンポーネント階層グラフにおいて、デバイスディスクｄ１及びｄ３に対応するノードは、冗長性の程度として２を有する付属した冗長性属性を保持する。デバイスには、ホストバスアダプタが、それらのデバイスを接続するデバイスパスのうちのいずれかを通じてアクセスすることができる。本説明の以下の部分で、ノードと共に属性をより詳細に説明する。
【００１６】
コンピュータシステムのコンポーネント階層グラフは、コンピュータ構成のハードウェアレイヤを超えて拡張され得、システムのソフトウェアレイヤによって使用される論理構成体も含むことができる。コンピュータ構成のソフトウェアレイヤは、ソフトウェアボリュームマネージャ、論理ディスクデバイス、ボリュームグループ、ファイルシステム、及びプロセス等の論理構成体を使用することができる。これらの論理構成体をコンポーネント階層グラフに含めることによって、資源解析アルゴリズムの効率を増大させることができる。これらの論理構成体に対応するコンポーネント階層グラフのノードを本明細書ではソフトウェアノードと呼ぶ。
【００１７】
コンピュータシステムのコンポーネント階層は、ブート時間において構築され得、オペレーティングシステムによって記憶され得る。コンピュータシステムでは、構成があまり頻繁に変化する可能性はないため、コンポーネント階層グラフも、あまり頻繁に変化しない。コンピュータ構成の構成が変化する場合、これらの変化を反映するようにコンポーネント階層グラフを変更することができる。コンピュータシステムの完全なコンポーネント階層は、ユーザ空間又はカーネル空間のいずれからもアクセス可能とされ得る。コンピュータ構成におけるデバイスの、ボリュームマネージャ及びファイルシステムとの関連付けは、頻繁に変化しないため、コンピュータ階層のノードのバインディングは、新規のボリュームグループ又はファイルシステムマウントポイントが作成又は変更されるたびに生じる。ブートプロセスの期間中、システムファームウェアは、各デバイスのＰＣＩ構成空間を調べて、システム資源を割り当てることができる。
【００１８】
コンポーネント階層グラフは、コンピュータシステムのコンポーネントのそれぞれに関連付けられる一定の属性を各ノードに含むことができる。これら一定の属性は、デバイスへのアクセスパスの個数、デバイスがたとえばブートデバイス又はクォーラムディスクであるか否か、又は後述するようなデバイスのクリティカリティを求める際に有用となり得る他の情報等である。
【００１９】
冗長リンクを有するコンポーネント階層グラフのノードは、現在アクティブな冗長リンクの個数と共に「REDUNDANCY」（冗長性）属性を保持する。初めに、コンポーネント階層のノードのそれぞれは、「NON-REDUNDANT」（非冗長）とマーキングされ、コンポーネント階層グラフを構築する時に非冗長性を示す。図２を参照して、「ｄ５」とラベリングされたノードは、「NON-REDUNDANT」ノードであるのに対して、「ｄ３」は、（論理ユニット番号（ＬＵＮ）パス「ｐ４」及び「ｐ５」による）「２」の冗長性を有する「REDUNDANT」（冗長）ノードである。さらに、（ＶＧ０１の状況における）ノードｌｖｏｌ３は、ディスク「ｄ３」と「ｄ４」との間のデータのミラーリングによって、「REDUNDANT」ノードである。さらに、「REDUNDANCY」属性を有するコンポーネント階層の各ノードは、その下で現在アクティブである、子のカウントを得ることができる。
【００２０】
コンポーネント階層グラフでは、異なるソフトウェアノードは、それらのノードに関連付けられる冗長性属性も有することができる。このような冗長性属性の使用は、「論理ボリューム」に特に有用であると予想される。その理由は、「論理ボリューム」が、現代のサーバシステムでは、ミラーリングによってソフトウェア冗長性を生み出すことができる最も可能性のある論理構成体であることである。しかしながら、他の同様の論理構成体又は他の匹敵する論理構成体への本技法の適用が排除されるものではない。アプリケーションレベルにおける冗長性は、たとえば、「プロセス」がデバイス／ディスクの故障に対処できる場合に存在し得る。このような場合に、デバイスのクリティカリティを求める方法は、そのアプリケーション／プロセスが使用しているデバイスのうちの１つの喪失を許容できるものと結論付けることができる。この場合、２つのデバイスを使用しているプロセスは、コンポーネント階層グラフにおいて「REDUNDANT」ノードによって表される。
【００２１】
冗長性属性と共に、提案された技法は、コンポーネント階層グラフのすべてのソフトウェアノードにクリティカリティ属性を関連付けることもできる。コンポーネント階層グラフのノードのクリティカリティ属性は、アルゴリズムの機能を改善すると共に、アプリケーションレベルのクリティカリティ解析をハンドリングするためのアルゴリズムを拡張可能にすることができる。また、クリティカリティ属性は、たとえば、クラスタ構成におけるコンピュータシステムにわたるクリティカリティを求めるのに役立つことができる。一例として、ブートデバイスがクリティカリティである場合、ブートプロセスソフトウェアノードが、その先行ノードとしてブートデバイスを有するコンポーネント階層グラフに作成される。同様に、ダンプデバイスに直接書き込みを行うように構成されるダンプの場合には、「ダンプ」とラベリングされたソフトウェアノードは、その先行ノードとして当該ソフトウェアノードがダンプするのに使用するデバイス（複数可）と共に作成される。ダンプが論理ボリューム上で構成される場合、コンポーネント階層にすでにある「ｌｖｏｌ」ノードが、ダンプノードの先行ノードになる。この階層におけるブートプロセスノードは、その「クリティカリティ」属性として「システム機能に関してクリティカル」（critical for the system functioning）を保持することができる。同様に、「ダンプ」ソフトウェアノードは、「クリティカリティ」属性の適切な値を保持することができる。
【００２２】
図３は、コンピュータシステムの１つ又は複数のデバイス上でホットプラグオペレーションのデバイスのクリティカリティ解析を行う方法３００を示すフローチャートである。一実施形態では、本技法は、方法３００を実行するためのコンピュータ実行可能命令として実施することができる。このコンピュータ実行可能命令は、任意のタイプのコンピュータ可読媒体に記憶することができる。この任意のタイプのコンピュータ可読媒体は、磁気ディスク、ＣＤ−ＲＯＭ、光媒体、フロッピー（登録商標）ディスク、フレキシブルディスク、ハードディスク、磁気テープ、ＲＡＭ、ＲＯＭ、ＰＲＯＭ、ＥＰＲＯＭ、フラッシュＥＰＲＯＭ、又はコンピュータが読み出すことができる他の任意の媒体等である。
【００２３】
図３のステップ３０１において、本技法は、システム構成情報を収集する。一般に、システム構成情報は、様々なタイプの構成情報を含む。一実施形態では、システム構成情報は、論理ボリューム構成、ファイルシステム構成、プロセス構成、スワップデバイス構成、及びダンプデバイス構成を含む。ステップ３０１において収集されたシステム構成は、ステップ３０２において、所与のコンピュータシステムのコンポーネント階層グラフを構築するのに使用され得る。システムがブートされるときに、コンピュータシステムのコンポーネント階層グラフも構築して記憶され得る。
【００２４】
図３のステップ３０３において、ユーザは、たとえば、カード（複数可）の追加、交換、又は取り外しといったオンラインホットプラグオペレーションを行いたい旨を示す。ここで、ユーザは、どのデバイス（複数可）が、試みられるオンラインホットプラグオペレーションに関与するのかを知っているものと仮定する。オンラインホットプラグオペレーションには、対象となるデバイス（複数可）に関連付けられるハードウェアデバイスに対するドライバを一時停止すること、及びデバイスが結合されている対応するスロットの電源を切断することが必要とされる。一方、たとえば、対応するスロットがスロット電源ドメインにある場合には、そのスロット電源ドメイン内の他のスロットである電源ラインを共有するいくつかのスロットも電源が切断される。したがって、これらのスロットの電源も切断されることから、これらのスロットに結合されているデバイスも、試みられるオンラインホットプラグオペレーションに関与する。
【００２５】
ユーザは、コンピュータシステム１００の適切なユーザインターフェースを使用して、オンラインホットプラグオペレーションを行いたい旨を示すことができる。代替的には、ユーザは、スロットのアテンションボタンを押下して、ホットプラグイベントをトリガすることもできる。これによって、オンラインホットプラグオペレーションユニットがアクティブ化されて、オンラインホットプラグオペレーションを行うためにシステム１００が準備される。オンラインホットプラグオペレーションを行うためにシステム１００を準備する際に、資源解析アルゴリズムが起動され、デバイスのクリティカリティ機能へのアクセス性を提供する。
【００２６】
説明の目的で、システム１００のいくつかのデバイスは、試みられるオンラインホットプラグオペレーションに関与するか、又は、そのオペレーションによる影響を受けるものと仮定する。
【００２７】
ステップ３０５において、コンポーネント階層グラフは、各被影響ハードウェアデバイス３０４から開始してトラバースされる。ここで、各被影響ハードウェアデバイスは、試みられるオンラインホットプラグオペレーションに関与するか、又はそのオペレーションによる影響を受けるデバイスのいずれかに対応する。複数の被影響ハードウェアデバイスが同じカードに対応する場合があることが理解されよう。コンポーネント階層グラフのトラバースは、コンポーネント階層グラフの被影響ノードに基づいて、いずれかの構成されている資源（システム構成情報から特定可能）が影響を受けるか否かを判断する手法を使用する。コンポーネント階層グラフのトラバースのアルゴリズム４００を図４に詳細に示す。
【００２８】
ステップ３０６において、このアルゴリズムは、ステップ３０５からの情報に基づいて、デバイスのクリティカリティ報告を生成することができる。図５は、ステップ３０６をより詳細に説明している。デバイスのクリティカリティ情報は、ステップ３０５において特定された被影響資源のうちの１つ又は複数のリストを含む。一般に、資源を被影響資源として特定する理由は、解析情報に含まれる。被影響資源には、所定の基準に基づいて深刻度レベルを割り当てることができる。この深刻度レベルには、上述したように、低深刻度レベル、中深刻度レベル、及び高深刻度レベルが含まれる。ユーザからの許可が必要な場合に、デバイスのクリティカリティ報告は、解析結果を任意の適した方法で提示して、オンラインカードオペレーションの遂行を許可するか否かを決定することをユーザに可能にするための十分な情報をユーザに提供することができる。
【００２９】
ステップ３０７に続いて、このアルゴリズムは、特定された被影響ハードウェアデバイスが機能していないかを判断することができる。被影響ハードウェアデバイスが機能していない場合には、ホットプラグのためのユーザ許可を得る必要はない。その理由は、これらの被影響ハードウェアデバイスが、それらの機能をシステム１００に提供しておらず、しかも、システム１００は正常に動作し続けるために、これらの被影響ハードウェアデバイスがシステムオペレーションに必須ではあり得ないためである。したがって、方法３００は、ステップ３１０に進み、ステップ３１０において、ユーザは、オンラインホットプラグオペレーションを進めることを可能にされる。被影響ハードウェアデバイスのいずれかが機能している場合には、このアルゴリズムはステップ３０８に進む。
【００３０】
図４は、本技法の一実施形態による図２のコンポーネント階層グラフのトラバースを示すフローチャート３０４を示している。詳細には、図４は、図３のステップ３０４をより詳細に説明している。
【００３１】
ステップ４０１において、コンポーネント階層グラフのＰＣＩデバイスノードは、「初期影響あり」（initially impacted）としてマーキングされる。コンポーネント階層グラフのＰＣＩデバイスノードに「初期影響あり」としてマーキングした後、このアルゴリズムは、初期影響を受けるレベルから開始してグラフをトラバースする（４０２）。
【００３２】
ステップ４０３に続いて、このアルゴリズムは、考慮対象ノードが、そのノードに関連付けられる「冗長性」（redundancy）属性を有するか否かを判断する。考慮対象ノードが「非冗長」（non-redundant）とマーキングされている場合には、このアルゴリズムは、ステップ４０４に進み、考慮対象ノードの先行ノードのいずれかが、「影響あり」（impacted）とマーキングされているか否かを判断する。考慮対象ノードの先行ノードのいずれも、「影響あり」とマーキングされていない場合には、考慮対象ノードは、「影響なし」（not impacted）としてマーキングされる。考慮対象ノードの先行ノードのいずれかが「影響あり」とマーキングされている場合には、検討対象ノードは、「影響あり」としてマーキングされる（４０６）。
【００３３】
さらにステップ４０５に続いて、検討対象ノードが「冗長」としてマーキングされており、且つ、検討対象ノードの先行ノードのそれぞれが「影響あり」としてマーキングされている場合には、検討対象ノードも、「影響あり」としてマーキングされる（４０６）。
【００３４】
図４のステップ４０７において、検討対象ノードの先行ノードのうちの少なくとも１つが「影響あり」としてマーキングされているかどうか。先行ノードのいずれも「影響あり」としてマーキングされていない場合には、検討対象ノードは、ステップ４０８において「影響なし」としてマーキングされ、そうでない場合には、アルゴリズムは、図４のステップ４０９に進む。
【００３５】
ステップ４０９に続いて、検討対象ノードの先行ノードのうちの少なくとも１つが、「影響あり」としてマーキングされている場合には、このアルゴリズムは、検討対象ノードに関して冗長性の喪失の警告を生成する。このアルゴリズムは、図４のステップ４０９において、性能の損失（loss of performance）の警告も生成することができる。
【００３６】
図４のステップ４１０にさらに続いて、このアルゴリズムは、検討対象ノードが、コンポーネント階層グラフのプロセスレベルノードに対応するノードを表すか否かをチェックする。ノードがプロセスレベルノードでない場合には、このアルゴリズムは、ステップ４０３に進み、コンポーネント階層グラフの次のレベルを解析する。このサイクルは、このアルゴリズムが、コンポーネント階層グラフの最下位レベルの、プロセスレベルノードに対応するノードに達するまで繰り返され、コンポーネント階層グラフの完全なトラバースが保証される。
【００３７】
コンピュータシステムのホットプラグオペレーションの影響を計算するための図４のコンポーネント階層グラフをトラバースするためのアルゴリズムの擬似コードを以下に与える。
ホットプラグオペレーションの一部であるプラットフォーム階層のすべてのＰＣＩデバイスノードを「初期影響あり」としてマーキングする；
for each「初期影響あり」レベルからプロセスレベルへのツリーのレベル do
if ノードのタイプが「NON-REDUNDANT」である then
if 自身の先行ノード（すなわち、自身の先行レベルから自身に接続されているノード）のいずれか（ANY of）が「影響あり」である then
自身を「影響あり」とマーキングする；
else /* ノードは「REDUNDANCY」ノードである */
if すべての自身の先行ノードが「影響有り」とマーキングされている then
自身を「影響有り」とマーキングする；
endif
if 自身の先行ノードのうちの少なくとも１つが「影響有り」とマーキングされている then
冗長性／動作の喪失の警告を生成する
（ただし、このノードは「影響有り」としてマーキングされない）；
endif
endif
endfor
【００３８】
加えて、クリティカリティ報告は、解析の全結果も提供することができる。一実施形態では、全体の結果は、成功、警告、データクリティカル、システムクリティカル、又はエラーとすることができる。
【００３９】
全体の結果が成功である場合、これは、この技法が、被影響資源を発見しなかったことを示し、ユーザには、成功メッセージが提供され、オンラインホットプラグオペレーションを進めることが可能にされる。
【００４０】
さらに、全体の結果が警告である場合、これは、この技法が、１つ又は複数の被影響資源を発見したことを示している。一方、これらの被影響資源には、低深刻度レベル（又は警告レベル）が割り当てられており、いずれにも、中深刻度レベル（又はデータクリティカルレベル）も高深刻度レベル（又はシステムクリティカルレベル）も割り当てられていない。ユーザには、被影響資源がシステムオペレーションにとってクリティカルと考えられないことを明示する警告メッセージが提供され、オンラインカードオペレーションを進めることが可能にされる。
【００４１】
続いて、全体の結果がデータクリティカルである場合、これは、この技法が、１つ又は複数の被影響資源を発見したことを示している。一方、これらの被影響資源のうちの少なくとも１つには、中深刻度レベル（又はデータクリティカルレベル）が割り当てられているが、いずれにも、高深刻度レベル及び／又はシステムクリティカルレベルは割り当てられていない。システム１００に記憶されているデータがおそらく又は場合によっては喪失されるが、システム１００はおそらくクラッシュもしないし危険／故障状態にも入らないということを明示するデータクリティカルメッセージが、ユーザに提供される。一方、オンラインホットプラグオペレーションに進む前に、ユーザからの許可を取得することができる。
【００４２】
全体の結果がシステムクリティカルである場合、これは、この技法が、１つ又は複数の被影響資源を発見したことを示している。一方、これらの被影響資源のうちの少なくとも１つには、高深刻度レベル及び／又はシステムクリティカルレベルが割り当てられている。ユーザには、システム１００がダウンに至る可能性があることを明示するシステムクリティカルメッセージが提供される。したがって、ユーザは、システム１００が危険／故障状態に確実に入らないようにするためにシステム１００をシャットダウンしてリブートした方がよい。この場合、ユーザがオンラインカードオペレーションを進めることを阻止することができる。
【００４３】
図３のステップ３０７から続けて、オンラインホットプラグオペレーションユニットは、コンポーネント階層グラフのトラバースからの結果に基づいて進む。
【００４４】
さらに、ステップ３０８において、全体の結果がデータクリティカルである場合には、オンラインホットプラグオペレーションユニットは、オンラインカードオペレーションを進めるユーザからの許可を取得する。
【００４５】
続いて、ステップ３０９において、オンラインカードオペレーションユニットは、デバイスのクリティカリティ報告からの解析及びユーザ入力に基づいて、オンラインカードオペレーション（たとえば、カード（複数可）の追加、交換、又は取り外し）を行うか否かを判断する。さらに、デバイスのクリティカリティ報告の全体の結果がデータクリティカルである場合には、オンラインホットプラグオペレーションユニットは、ユーザがオンラインカードオペレーションを進める許可を提供したか否かを判断する。
【００４６】
全体の結果が、成功又は冗長性の喪失である場合には、オンラインホットプラグオペレーションユニットは、オンラインホットプラグオペレーションの遂行を促進する。加えて、全体の結果がデバイスの喪失であり、ユーザがオンラインカードオペレーションを進める許可を提供していた場合には、オンラインカードオペレーションユニットは、オンラインカードオペレーションの遂行を促進する。さらに、すべての被影響ハードウェアデバイスが（ステップ３０７で判断されるように）機能していない場合には、オンラインカードオペレーションユニットは、ステップ３１０において、オンラインカードオペレーションの遂行を促進する。
【００４７】
一方、全体の結果が、システムクリティカル又はエラーである場合には、オンラインカードオペレーションユニットは、ステップ３１１において、オンラインカードオペレーションの遂行を進めない。さらに、（ステップ３０８において）全体の結果がデータクリティカルであり、且つ、ユーザが、オンラインカードオペレーションを進める許可を提供していなかった場合には、オンラインカードオペレーションユニットは、ステップ３１１において、オンラインカードオペレーションの実行を進めない。
【００４８】
図５は、本発明の一実施形態による図３の高度化されたデバイスのクリティカリティ報告の生成を示すフローチャートを示している。詳細には、図５は、図３のステップ３０６をより詳細に説明している。
【００４９】
ステップ５１０において、被影響資源の作成されたリストが受け取られる。これらのリストは、（図３の、および図４でより詳細に説明された）ステップ３０６においてコンポーネント階層グラフをトラバースすることによって作成されたリストを含む。
【００５０】
続いて、ステップ５２０において、深刻度レベルが、所定の基準に基づいて、特定された各被影響資源に割り当てられる。深刻度レベルは、特定された被影響資源の機能が利用不能になった場合のシステム１００への影響の程度を表す。一実施形態では、深刻度レベルは、警告レベル、データクリティカルレベル、又はシステムクリティカルレベルである。所定の基準の選択は、解析結果の精度に影響を与える可能性がある。
【００５１】
次に、本発明の一実施形態において深刻度レベルを割り当てるための一組の基準を説明する。システムのタイプが異なれば、深刻度レベルの割り当ては異なる場合があることが理解されよう。
【００５２】
一実施形態によれば、使用されていない被影響論理ボリューム、被影響ディスクを有するが被影響論理ボリュームを有しない被影響ボリュームグループ、及び、少なくとも１つの代替的な影響を受けないハードウェアの識別子を有する被影響論理ボリュームには、警告レベルが割り当てられる。この少なくとも１つの代替的な影響を受けないハードウェアは、動作しており且つ利用可能なものである。
【００５３】
一般に、ローカルに設置された被影響ファイルシステム（たとえば、動作しており且つ利用可能な少なくとも１つの代替的な影響を受けないハードウェアデバイスを有しない被影響論理ボリュームに設置された被影響ファイルシステム、又は、被影響ディスクに設置された被影響ファイルシステム）には、データクリティカルレベルが割り当てられる。一方、少なくとも１つの代替的な影響を受けないハードウェアデバイスを有する被影響論理ボリューム上で見つけられる被影響ファイルシステムには、警告レベルが割り当てられる。この影響を受けないハードウェアデバイスは、動作していると共に利用可能なものである。加えて、システムクリティカルレベルは、次の被影響ファイルシステム、すなわち、/、/stand、/usr、/etc、及びＦＳスワップに割り当てられる。/が喪失された場合には、/usr/sbinに入って、カードの電源を再び投入することができなくなる。/standが喪失された場合には、カーネルレジストリサービスを続けることができなくなる。/usrが喪失された場合には、カードの電源を再び投入することができなくなる。/etcが喪失された場合には、オンラインカードオペレーションユニットは、syslogに書き込むことができないため、故障する。ＦＳスワップが喪失された場合には、カーネルをスワップアウトすることができ、カーネルがそれ自身をスワップインして戻ることができない場合には、カーネルは混乱する。
【００５４】
被影響プロセスには、データクリティカルレベルを割り当てることができる。さらに、被影響スワップデバイスには、システムクリティカルレベルを割り当てることもできる。スワップデバイスの喪失は、オペレーティングシステムが、もはや利用可能でない定義されたロケーション上の情報をスワップしようとする場合に壊滅的になる可能性がある。
【００５５】
被影響ダンプデバイスには、警告レベルを割り当てることができる。ダンプデバイスは、システムオペレーションにはクリティカルではないが、トラブルシューティングする場合のユーザには重要となる場合がある。
【００５６】
開示される技法は、その機能がシステムにクリティカルであるプロセス名のリストを作成することによって、「クリティカリティ」の概念をアプリケーションレベルにまで拡張するのに使用することができる。これらのプロセスのすべてのプロセスインスタンスは、コンポーネント階層において「クリティカル」としてタグ付けすることができる。
【００５７】
図５を再び参照して、ステップ５３０において、デバイスのクリティカリティ報告が生成される。このデバイスのクリティカリティ報告は、特定された各資源及び対応する各深刻度レベルを含むことができる。さらに、このデバイスのクリティカリティ報告は、正確さと、可読性と、ユーザからの許可が必要な場合にオンラインカードオペレーションの遂行を許可するか否かを決定することをユーザに可能にするための十分な情報をユーザに提供することとを強調することができるため、ユーザフレンドリーである。
【００５８】
本技法の上記変形形態のいずれも、適した汎用コンピュータをプログラミングすることによって実施することができる。プログラミングは、コンピュータによって読み出し可能なプログラムストレージデバイスの使用、及び、上述したオペレーションを行うためのコンピュータによって実行可能な命令から成るプログラムをコーディングすることを通じて行うことができる。
【００５９】
本明細書に含まれるフローチャートは、必ずしも、単一のホットプラグイベントにおける実行を表すものではなく、むしろ、いくつかの例では、複数のホットプラグオペレーションで行われる一連の協調されたステップ、イベント、又はプロセスを表すことができる。加えて、本明細書のフローチャートは、図面に明示的に表されるイベント、ステップ、又はプロセスの間で、他のイベント、ステップ、又はプロセスを行うことができないことを暗に意味するものとして解釈されるべきではない。
【００６０】
本発明の特定の実施形態の上記説明は、例示及び説明の目的で提示されたものである。それらの説明は、網羅的であることを目的とするものでもなければ、開示される正確な形に本発明を限定することを目的とするものでもなく、また上記教示に鑑み、多くの変更形態及び変形形態が可能である。実施形態は、本発明の原理及びその実用的な応用を最も良く説明し、それによって、他の当業者が、本発明及びさまざまな変更形態を有するさまざまな実施形態を、検討される特定の使用に適するように最も良く利用することを可能にするために、選ばれて説明されたものである。本発明の範囲は、本明細書に添付した特許請求の範囲及びその均等物によって画定されることが意図されている。
【図面の簡単な説明】
【００６１】
【図１】高可用性コンピュータシステム構成のハードウェアコンポーネント及びソフトウェアコンポーネントを示す図である。
【図２】ハードウェアコンポーネント及びソフトウェアコンポーネントを含むことができるコンポーネント階層グラフの一例を示す図である。
【図３】システムのうちの１つ又は複数のデバイス上でデバイスのクリティカリティ解析を行う方法を示すフローチャートである。
【図４】コンポーネント階層グラフのトラバースのアルゴリズムを示すフローチャートである。
【図５】図３のデバイスのクリティカリティ報告の生成を示すフローチャートである。
【図６】非循環有向グラフの一例を示す図である。
【符号の説明】
【００６２】
１００・・・コンピュータシステム
１０１，１０２，１０３・・・ホストバスアダプタ
１０４，１０５・・・周辺デバイスディスク
１０６・・・ミラードデバイス
【図１】
2009048610.tif 000003
【図２】
2009048610.tif 000004
【図３】
2009048610.tif 000005
【図４】
2009048610.tif 000006
【図５】
2009048610.tif 000007
【図６】
2009048610.tif 000008
【外国語明細書】
Method and System to Determine Device Criticality for Hot-plugging in Computer Configurations
Background of the Invention
Computer servers are utilized in a variety of applications.  Systems, such as server systems executing purchase transactions for an Internet-based merchant, usually have a high-availability design.  Such high availability systems are designed to be running and available at all times.  Thus, the need for powering down and rebooting these systems for any reason for example maintenance, upgrades, system crashes, troubleshooting, etc., has to be avoided as much as possible.  Typically, these systems have a plurality of expansion slots, wherein a card is coupled to the slot.  Mass storage devices and network adapters are examples of components that may be connected via such cards.  Generally, one or more further devices may be coupled to the card via cables. 
To maintain high-availability, online card operation capability has been integrated into high availability computer systems.  The online hot plug operation capability enables a user and/or a system administrator to perform online hot plug operations without powering down and rebooting these systems.  Examples of online card operations include adding a card to the system by coupling it to a slot, replacing an existing card that is coupled to a slot with another card, and removing a card from the system by uncoupling it from a slot while the system is running.  These online hot plug operations generally require that particular drivers for the card be suspended and that the power to the slot(s) of interest be shut-off before a card can be added, replaced, or removed.  Generally, slot power control and drivers may facilitate these online card operations.  In some systems, several slot power domains are configured, wherein slots in each slot power domain share a common power line.  If an online card operation is performed on any slot in a slot power domain, then all the slots in the slot power domain may lose power, increasing the complexity of performing the online card operation. 
Before such an online hot plug operation, typically a resource analysis is performed on the computer systems.  The resource analysis may also be useful when groups of cards are taken offline in a single operation such as when an entire chassis of cards is removed from the computer system while the system is running.  The resource analysis may also be referred to as a "critical resource analysis" (CRA).  The CRA may analyze and report the impact of powering down each slot associated with any card that is involved in any attempted online hot plug operation example, adding, replacing, or removing card(s).  This may require identifying affected resources of the system.  Conventionally, the identified affected resources are assigned a low severity level or warning level and a high severity level or critical level.  If the identified affected resources are essential for system operation, they are assigned the critical level.  This indicates that if the slot(s) is powered down causing the unavailability of the functionality of the card(s) coupled to it, the system likely will crash or enter an unhealthy/failed state.  The user is generally prevented from performing the online card operation if an identified affected resource is assigned the critical level so that the system keeps running to maintain the desired system availability level.  The manner of determination of whether an identified affected resource is "essential for system operation" may vary among different systems.  If the identified affected resources are not essential for system operation, they are assigned the warning level.  This indicates that if the slot(s) is powered down causing the unavailability of the functionality of the card(s) coupled to it, the system likely will not crash or enter an unhealthy/failed state. 
In general, CRA performs a series of checks to conclude if the card and/or slot and the resources/devices associated with it are essential to system operation.  The CRA functionality is intended to keep the system running and avoid inadvertent reboots as well as prevent the system from getting into an unhealthy state.
Brief Description of Drawings
Embodiments of the invention will now be described by way of example only, with reference to accompanying drawings, wherein:
Figure 1 illustrates hardware and software components in a high availability computer system configuration.
Figure 2 illustrates an example of component hierarchy graph which may include hardware and software components.
Figure 3 is a flow chart showing a method of performing device criticality analysis on one or more devices of a system.
Figure 4 is a flow chart showing algorithm for traversal of component hierarchy graph.
Figure 5 is a flow chart showing generation of the device criticality report of Figure 3.
Figure 6 illustrates an example of a directed acyclic graph.
Detailed Description of Embodiments of Invention
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 method, a system and a computer program for determining device criticality with respect to a hot-plugging operation in a computer configuration by representing a component hierarchy, including potentially multiple paths to affected devices, with a directed acyclic graph (DAG).
In the following part of the description terms "resource analysis" and "device criticality analysis" will be used interchangeably.
Figure 1 illustrates an example of a simple high availability computer configuration.  The highly available computer configuration may consist of a computer system 100 that may comprise three host bus adapters HBA1 101, HBA2 102 and HBA3 103 to connect it to peripheral device disks dsk1 104 and dsk2 105.  The peripheral device disks may be a memory disk device or a group of memory disk devices being accessed by the host bus adapters.  The said computer system also may comprise software for managing disk mirroring for example volume manager, mirrored device 106.  Such computer system may consist of any number of host bus adapters depending on the requirements of the computing environment.  Similarly, the peripheral devices dsk1 104 and dsk2 105 may comprise a single device disk and/or a group of device disks.  The peripheral devices dsk1 104 and dsk2 105 in a computer may be connected to a motherboard via a Peripheral Component Interconnect (PCI) bus, for instance.
As an example if the Host Bus Adapter (HBA1) 101 in Figure 1 is getting hot-plugged (either a replace or delete operation), the conventional CRA computation would have flagged the operation critical if the disk device were under use by either a process in the system or used by the system's Operating System (OS) to store important data.  However, since the disk device 104 continues to be accessible through HBA2 102 because of redundant access paths, the operation may be permitted.  Further, if the hot-plug operation were requested for host bus adapter HBA1 101 and HBA2 102, the CRA computation should detect that the disk device 104 and 105 would be impacted.  However, since the disk devices 104 and 105 are mirrored by software, volume manager in this case, CRA should detect this and report that there is likely performance degradation and loss of mirroring as a "warning" to the user and permit the hot plug operation as loss of disk device may not result in failure of the computer system. 
A directed acyclic graph, which will in the following sometimes be abbreviated to DAG, is a directed graph with no directed cycles.  In a DAG, for any given vertex v, there is no non empty directed path starting and ending on v.  Directed acyclic graphs appear in models where it may not make sense for a vertex to have a path to itself; for example if an edge u -->v indicates that vertex v is a part of vertex u, such path would indicate that vertex u is a part of itself, which may be improbable.
The directed acyclic graph may correspond to a partial order on its vertices.  For two given vertices u and v of a DAG; u --> v is in the partial order exactly when there is a directed path from vertex u to vertex v in the graph.  However many different directed acyclic graphs may represent the same partial order in this way.  In a DAG a source is a vertex with no incoming edges.  Similarly a sink is a vertex with no outgoing edges.  A finite DAG has at least one source and at least one sink.  The length of a DAG is the length (number of edges) of a longest directed path.  A typical structure of a directed acyclic graph is illustrated in Figure 6.
In a computer configuration such as that illustrated in Figure 1, a device such as device disk 104 may be accessed by host bus adapters through more than one defined path.  For example in Figure 1 device disk 104 may be accessed by two different host bus adapters HBA1 101 and HBA2 102 through two paths.  Here in this description such devices with multiple access paths are labeled as redundant with the number of paths as the degree of redundancy.  These device paths i.e. the paths through which devices are connected to the host bus adapters, may be represented in form of edges of the component hierarchy graph.  A component hierarchy of a more complex computer system, in form of component hierarchy graph is illustrated in Figure 2 as an example.  
The computer configuration illustrated in Figure 2 by way of component hierarchy graph comprises of three host bus adapters (h1, h2 and h3) and seven disk devices (d1, d2, d3, d4, d5, d6 and d7) connected to the host bus adapters.  The disk devices are connected to the host bus adapters via ten device paths P1, P2, P3, P4, P5, P6, P7, P8, P9 and P10.  For example the disk device d1 is connected to host bus adapters through two paths P1 and P2.  Similarly disk device d3 is connected through paths P4 and P5.  Hence the nodes corresponding to disk devices d1 and d3 in the component hierarchy graph are redundant nodes.  Hence in component hierarchy graph the nodes corresponding to device disks d1 and d3 will carry an attached redundancy attribute with degree of redundancy as two.  The devices may be accessed by the host bus adapters through any of the device paths through which they are connected.  The attributes with the nodes are described in greater detail in following part of this description.
The component hierarchy graph of a computer system may be extended beyond the hardware layer of the computer configurations and may also include logical constructs used by the software layers in the system.  The software layers of a computer configuration may use logical constructs such as software volume managers, logical disk device, volume groups, file systems and processes.  Inclusion of these logical constructs in the component hierarchy graph may increase the efficiency of the resource analysis algorithm. The nodes of the component hierarchy graph that correspond to these logical constructs will be referred to herein as software nodes.
The component hierarchy of a computer system may be built at the boot time and stored by the operating system.  Since in a computer system the configuration may not change very frequently, the component hierarchy graph also will not change very frequently.  In the case of changes in the configuration of the computer configuration, the component hierarchy graph may be modified to reflect the changes.  The complete component hierarchy of the computer system may be made accessible either from user space or kernel space.  Since the association of devices in a computer configuration with volume manager, and file system does not change frequently, the binding of the nodes of the component hierarchy happens whenever a new volume group or file system mount point is created or modified.  During the boot process, the system firmware may examine the PCI configuration space of each device and allocate the system resources.  
The component hierarchy graph may include at each node certain attributes associated with each of the components of the computer system, such as the number of access paths to a device, whether or not the device is a boot device or quorum disk, for instance, or other information that may be useful in determining device criticality as described below.
The nodes in the component hierarchy graph which have redundant links would carry a "REDUNDANCY" attribute along with the number of currently active redundant links.  Initially each of the nodes in the component hierarchy is marked "NON-REDUNDANT", indicative of non-redundancy at the time of building the component hierarchy graph.  With reference to Figure 2, the node labeled "d5" is a "NON-REDUNDANT" node whereas, "d3" is a "REDUNDANT" node with redundancy of "2" (owing to logical unit number (LUN) paths "p4" and "p5").  Further, the node lvol3 (in the context of VG01) is a "REDUNDANT" node, owing to the mirroring of data between the disks "d3" and "d4".  Further, each node in the component hierarchy with "REDUNDANCY" attribute may get a count of children that are currently active below it.  
In the component hierarchy graph, different software nodes may also have a  redundancy attribute associated with them.  The use of such a redundancy attribute is expected to be particularly useful for "Logical Volumes" since this is the most likely logical construct which can create software redundancy, due to mirroring, in modern server systems.  However, application of the technique to other similar or comparable logical constructs is not excluded. Redundancy at application level, for example, may exist where a "process" may be able to deal with device/disk failure.  In such cases, the method for determining device criticality, may conclude that the loss of one of the devices that the application/process is using is acceptable.  In this case, the process that is using two devices would be represented by a "REDUNDANT" node in the component hierarchy graph. 
Along with the redundancy attributes, the proposed technique may also associate a criticality attribute with all software nodes in the component hierarchy graph.  The criticality attribute at the nodes of the component hierarchy graph may improve the functioning of the algorithm and may make algorithm extensible for handling application level criticality analysis.  The criticality attribute may also help in determining the criticality across computer systems for example, in a cluster configuration.  As an example, if a boot device is critical, a boot process software node would be created in the component hierarchy graph with the boot device as its predecessor node.  Similarly, for the case of dump configured to write directly to dump devices, a software node labeled "dump" would be created with the device(s) it uses to dump as its predecessors.  If the dump is configured over a logical volume, the "lvol" node, already in the component hierarchy, will be the dump node's predecessor.  The boot process node in the hierarchy may carry "critical for the system functioning" as its "criticality" attribute.  Similarly, the "dump" software node may carry a suitable value of the "criticality" attribute.
Figure 3 is a flow chart illustrating a method 300 of performing device criticality analysis for a hot plugging operation on one or more devices of a computer system.  In an embodiment, the present technique may be implemented as computer-executable instructions for performing the method 300.  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. 
At step 301 of Figure 3, the technique gathers the system configuration information.  Generally, the system configuration information includes different types of configuration information.  In an embodiment, the system configuration information includes logical volume configuration, file system configuration, process configuration, swap device configuration, and dump device configuration.  The system configuration gathered in step 301 may be used in step 302 to build the component hierarchy graph for the given computer system.  The component hierarchy graph of the computer system may also be built and stored when the system is booted.
At Step 303 of Figure 3, the user indicates a desire to perform an online hot plug operation for example, adding, replacing, or removing a card(s).  Here, it is assumed that the user knows which device(s) will be involved in the attempted online hot plug operation.  The online hot plug operation requires suspending drivers to the hardware devices associated with the device(s) of interest and powering down the corresponding slot to which the device is coupled.  However, if the corresponding slot is in a slot power domain for example, several slots sharing a power line, the other slots in the slot power domain will also be powered down.  Hence, the devices coupled to these slots also will be involved in the attempted online hot plug operation since these slots are also being powered down.
The user may use a suitable user interface of the computer system 100 to indicate the desire to perform the online hot plug operation.  Alternatively, the user may press the attention button of the slot to trigger a hot plug event.  This activates the online hot plug operation unit to prepare the system 100 for performing the online hot plug operation.  In preparing the system 100 for performing the online hot plug operation, the resource analysis algorithm is invoked, providing accessibility to the device criticality functionality. 
For explanation purposes, it will be assumed that several devices of the system 100 are involved in or affected by the attempted online hot plug operation. 
At Step 305, the component hierarchy graph is traversed starting from each affected hardware device 304, wherein each affected hardware devices correspond to any of the devices involved in or affected by the attempted online hot plug operation.  It will be understood that multiple affected hardware devices may correspond to the same card.  The traversing of component hierarchy graph uses the approach of determining if any configured resource (identifiable from the system configuration information) is affected based on the affected nodes of the component hierarchy graph.  The algorithm for traversal of component hierarchy graph 400 is illustrated in detail in Figure 4 .
At Step 306, the algorithm may generate a device criticality report based on the information from Step 305.  Figure 5 describes Step 306 in greater detail.  The device criticality information includes one or more lists of affected resources identified in Step 305. Generally, the reason for identifying a resource as an affected resource is included in the analysis information.  The affected resource may be assigned a severity level based on predetermined criteria.  The severity levels include a low severity level, a medium severity level, and a high severity level, as described above.  The device criticality report may present the analysis results in any suitable manner to provide sufficient information to the user to allow the user to decide whether to permit performance of the online card operation if permission from the user is necessary. 
Continuing at Step 307, the algorithm may determine whether the identified affected hardware devices are nonfunctional.  If the affected hardware devices are nonfunctional, there is no need to get user permission for hot plugging since these affected hardware devices cannot be essential to system operation because these affected hardware devices are not providing their functionality to the system 100 and yet the system 100 continues to operate normally.  Thus, the method 300 proceeds to Step 310, where the user is allowed to proceed with the online hot plug operation.  If any of the affected hardware devices are functional, the algorithm proceeds to Step 308. 
Figure 4 illustrates a flow chart 304 showing traversing of the component hierarchy graph of Figure 2 in accordance with an embodiment of the present technique.  In particular, Figure 4 describes the Step 304 of Figure 3 in greater detail.
At Step 401, PCI device nodes of the component hierarchy graph are marked as "initially impacted".  After marking the PCI devices nodes of the component hierarchy graph as "initially impacted" the algorithm traverses the graph starting from the initially impacted level 402.  
Continuing to step 403 the algorithm determines if the node under consideration has a "redundancy" attribute associated with it.  In case of the node under consideration is marked "non-redundant" the algorithm proceeds to step 404 to determine if any of the predecessor nodes of the node under consideration is marked "impacted".  If none of the predecessor nodes of the node under consideration is marked "impacted" then the node under consideration is marked as "not impacted".  If any of the predecessor nodes of the node under consideration is marked "impacted" then the node under investigation is marked as "impacted" 406.
Further continuing to step 405, if the node under investigation is mark as "redundant" and each of the predecessor nodes of the node under investigation are marked as "impacted" then the node under investigation is also marked as "impacted" 406.
At step 407 of Figure 4, if at least one of the predecessor nodes of the node under investigation is marked as "impacted".  In case of none of the predecessor nodes being marked as "impacted" then the node under investigation is marked as "not impacted" at step 408, else algorithm proceeds to step 409 of Figure 4.
Continuing to step 409, if at least one of the predecessor node of the node under investigation is marked as "impacted" then the algorithm generate a warning of loss of redundancy for the node under investigation.  The algorithm can also generate a warning of loss of performance at step 409 of Figure 4.
Further continuing to step 410 of Figure 4, the algorithm checks the node under investigation represents a node corresponding to process level node in the component hierarchy graph.  If the node is not a process level node then the algorithm goes to step 403 analyzing the next level in component hierarchy graph.  The cycle is repeated till the algorithm reaches the nodes corresponding to the process level node which is lowest level in the component hierarchy graph, ensuring the complete traversal of the component hierarchy graph.
The pseudo code of the algorithm for traversing of the component hierarchy graph of Figure 4 to compute the impact of a tot-plug operation in a computer system is given below:
Mark all PCI device nodes in the platform hierarchy that are part of Hot-Plug 
operation as "initially impacted";
for each level in the tree from the "initially impacted" 
level to the Process level do
if the type of node is "NON-REDUNDANT" then
if ANY of my predecessor nodes (i.e., nodes connected to me 
from my previous level) is "impacted" then
mark me "impacted";
else /* it is a "REDUNDANCY" node */
if all of my predecessor nodes are marked "impacted" then
mark me "impacted";
endif
if at least one of my predecessor nodes is marked "impacted" then
generate a warning of loss of redundancy/performance
(but this node will not be marked as "impacted");
endif
endif
endfor
Additionally, the criticality report may provide an overall result of the analysis.  In an embodiment, the overall result may be success, warning, data critical, system critical or error. 
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 to the online hot plug 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 online card 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 and/or system critical level.  The user is provided a data critical message stating that probably or possibly data stored in the system 100 will be lost but probably the system 100 will not crash or enter an unhealthy/failed state. However, permission from the user may be obtained before proceeding to the online hot plug operation.  
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 and/or system critical level.  The user is provided a system critical message stating that the system 100 is likely to be brought down. Hence, the user might as well shut down the system 100 and reboot to ensure the system 100 does not enter an unhealthy/failed state. In this case, the user can be prevented from proceeding with the online card operation. 
Starting with Step 307 of Figure 3, the online hot plug operation unit proceeds based on the results from the traversal of component hierarchy graph. 
Furthermore, at Step 308, if the overall result is data critical, the online hot plug operation unit obtains permission from the user to proceed with the online card operation. 
Continuing, at Step 309, the online card operation unit determines whether to perform the online card operation (e.g., adding, replacing, or removing card(s)) based on the analysis from the device criticality report and the user input.  Moreover, if the overall result in the device criticality report is data critical, the online hot plug operation unit determines whether the user has provided permission to proceed with the online card operation. 
If the overall result is success or loss of redundancy, the online hot plug operation unit facilitates the performance of the online hot plug operation.  Additionally, if the overall result is loss of device the user has provided permission to proceed with the online card operation, the online card operation unit facilitates the performance of the online card operation. Moreover, if all the affected hardware devices are nonfunctional (as determined at Step 307), the online card operation unit facilitates the performance of the online card operation, at Step 310. 
However, if the overall result is system critical or error, the online card operation unit does not proceed with performance of the online card operation, at Step 311. Moreover, if the overall result is data critical and the user has not provided permission to proceed with the online card operation (at Step 308), the online card operation unit does not proceed with performance of the online card operation, at Step 311.
Figure 5 illustrates a flow chart showing generation of the enhanced device criticality report of Figure 3 in accordance with an embodiment of the present invention.  In particular, Figure 5 describes the Step 306 of Figure 3 in greater detail.
At Step 510, the created lists of affected resources are received. The lists include the list created by traversing the component hierarchy graph at Step 306 (of Figure 3 and described in greater detail in Figure 4). 
Continuing, at Step 520, a severity level is assigned to each identified affected resource based on predetermined criteria, wherein the severity level represents degree of impact to the system 100 if functionality of the identified affected resource became unavailable.  In an embodiment, the severity level is a warning level, a data critical level, or a system critical level. Selection of the predetermined criteria can affect the accuracy of the analysis results. 
There will now be described a set of criteria for assigning the severity levels in an embodiment of the present invention. It will be understood that the assignment of severity levels may be different for different types of systems. 
According to an embodiment, affected logical volumes that are not being used, affected volume groups having affected disks but no affected logical volumes, and affected logical volumes having at least one alternate unaffected hardware identifier, which is operating and available, are assigned the warning level. 
Generally, affected file systems that are locally mounted (e.g., mounted on affected logical volumes which do not have at least one alternate unaffected hardware device that is operating and available, or mounted on an affected disk) are assigned the data critical level.  However, affected file systems that are found on affected logical volumes having at least one alternate unaffected hardware device, which is operating and available, are assigned the warning level.  Additionally, the system critical level is assigned to the following affected file systems: /, /stand, /usr, /etc, and FS swap. If / was lost, then there will not be the ability to get into /usr/sbin to power the card back on.  If /stand was lost, the kernel registry service will be unable to continue. If /usr was lost, then there will not be the ability to power the card back on.  If /etc was lost, the online card operation unit will fail because it cannot write to syslog.  If FS swap was lost, the kernel can be swapped out and will panic if it cannot swap itself back in. 
The affected processes may be assigned the data critical level.  Furthermore, the affected swap devices may also be assigned the system critical level.  Loss of a swap device could be catastrophic if the operating system tries to swap information on a defined location no longer available. 
The affected dump devices may be assigned the warning level. A dump device is not critical to system operation but may be important to a user for troubleshooting. 
The disclosed technique may be used to extend the concept of "criticality" to application level by creating a list of process names, whose functioning is critical to the system.  All the process instances of these processes may be tagged as "critical" in the component hierarchy.  
Referring again to Figure 5, at Step 530 the device criticality report is generated.  The device criticality report may include each identified resource and corresponding severity level. Moreover, the device criticality report is user-friendly as it may emphasize accuracy, readability, and providing sufficient information to the user to allow the user to decide whether to permit performance of the online card operation if permission from the user is necessary.
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 of determining device criticality in a computer system comprising the steps of: 
building a component hierarchy graph using computer configuration information;
labeling the nodes of component hierarchy graph with a redundancy attribute;
traversing the component hierarchy graph; 
determining whether the device loses an access path by inspecting the redundancy attributes within the component hierarchy graph.  
2.    A method as recited in claim 1 wherein the component hierarchy graph comprises nodes associated with logical constructs within the system.
3.    A method as claimed in claim 2 wherein the logical constructs comprise at least one of logical volumes, volume groups, file systems and processes.
4.    A method as recited in claim 1 further comprising: determining whether to perform an online hot plugging operation for the device based on the criticality of the device.
5.    A method as claimed in claim 1 wherein the component hierarchy graph is a directed acyclic graph.
6.    The method as recited in claim 1 wherein the device is compatible with one of a Peripheral Component Interface specification and a PCI-X specification.
7.    The method as recited in claim 1 wherein nodes of the component hierarchy graph contains usage attributes.
8.    The method as recited in claim 1 wherein a criticality attribute is associated with nodes of the component hierarchy graph.
9.    The method as recited in claim 1 wherein the component hierarchy graph is built at boot time of the computer system.
10.    The method as recited in claim 9 wherein the component hierarchy graph is obtained from user space and/or kernel space.
11.    The method as recited in claim 1 further comprising: determining whether to perform an online hot plugging operation based on resource analysis information including any identified affected resource and corresponding severity level.
12.     The method as recited in claim 9 wherein said determining whether to perform said online card operation comprises: if none of said identified affected resources is assigned said medium severity level and if none of said identified affected resources is assigned said high severity level, allowing said online card operation to be performed; if none of said identified affected resources is assigned said high severity level and if at least one of said identified affected resources is assigned said medium severity level, allowing said online card operation to be performed upon receiving permission from a user; and if at least one of said identified affected resources is assigned said high severity level, preventing said online card operation from being performed.
13.    The method as recited in claim 1 further comprising: if said affected resources are nonfunctional before initiating said resource analysis, performing an online hot plug operation without executing said resource analysis. 
14.     The method as claimed in claim 12 wherein, if the usage of the devices that lose all their access paths impacts user level processes, reporting an application level criticality and/or loss of access to data for user applications.
15.    A computer system comprising a directed acyclic graph data structure representing a component hierarchy; and a control arrangement for traversing the component hierarchy to determining device criticality, wherein the nodes of the component hierarchy graph are labeled with a redundancy attribute.
16.    The computer system as claimed in claim 15, wherein the component hierarchy graph data structure comprises nodes associated with logical constructs within the system.
17.    The computer system as claimed in claim 15 wherein the nodes in the component hierarchy contains usage attributes.
18.    The computer system as claimed in claim 15 further comprising: determining whether to perform an online hot plugging operation for the device based on the criticality of the device.
19.    The computer system as claimed in claim 15 wherein "criticality" attribute is associated with nodes of the component hierarchy graph.
20.    A computer program for determining device criticality in a computer system in case of a hot plugging operation, said program comprising: 
building a component hierarchy graph using computer configuration information;
leveling the nodes of component hierarchy graph with redundancy attribute;
traversing the component hierarchy graph; 
determining whether the device loses an access path by inspecting the redundancy attributes within the component hierarchy graph.
Abstract
The invention relates to a method for determining device criticality in a computer system comprising the steps of building a component hierarchy graph using computer configuration information; labeling the nodes of component hierarchy graph with redundancy attribute; traversing the component hierarchy graph; and determining whether the device loses an access path by inspecting the redundancy attributes within the component hierarchy graph.  Furthermore, one of a plurality of severity levels is assigned to each identified affected resource based on predetermined criteria. The severity levels include a low severity level, a medium severity level, and a high severity level. Each severity level represents degree of impact to the computer system if functionality of the identified affected resource became unavailable.
Figure 3
2009048610.tif 000009
2009048610.tif 000010
2009048610.tif 000011
2009048610.tif 000012
2009048610.tif 000013
2009048610.tif 000014