JP6109662B2 - 運用管理装置、運用管理方法およびプログラム - Google Patents

Description

本発明は、システムの運用管理技術、特に、ネットワーク等の通信回線を介して接続されるシステムに対する統合運用管理および障害の可視化技術に関する。

従来の統合運用管理システムでは、監視対象となるハードウェアやソフトウェアの状態を示すデータを取得し、それらの稼働状況の管理を行う。統合運用管理システムの一例が非特許文献１に開示されている。直接監視対象としている部分だけに限らず、システムやサービス全体の稼働状況の監視を行うため、統合運用管理システムは、サービス全体の構造を表す構成情報を保持する。

構成情報は、階層構造をなす複数の構成要素の物理構成および論理構成を示す情報である。各構成要素について障害の有無および障害の程度を表す状態の情報は、構成情報に紐づけて記録される。階層構造の最下位の構成要素はそれ自身が監視対象であり、監視の結果得られた状態やイベントに基づき、その障害状態が決定される。階層構造の中間の構成要素は、下位の構成要素の障害状態から予め決められた判定ルールに基づいて、その障害状態が判定される。階層構造の最上位の構成要素は典型的にはサービスに相当する。

従来の構成情報の具体例を、図８および図９を参照して説明する。図８は、監視対象となるハードウェア単位で、割り当てられたサービスに関する構成要素を示したものである。図９は構成情報によりサービス全体の構造を図に表現したものである。

構成情報は物理構成および論理構成の情報からなる。図８および図９に示す例はサービスαとサービスβの場合であり、構成情報はサービスα、βを構成する物理構成および論理構成を示す。

図８に示すように、監視対象となる構成要素は、ＣＰＵ（Central Processing Unit）サーバＡ、Ｂと、ストレージ１、２である。ＣＰＵサーバＡは、サービスαのＶＭ（Virtual Machine）１と、サービスβの現用のＶＭ２を保持している。ＣＰＵサーバＢは、サービスβの待機用のＶＭ３を受け持っている。ストレージ１には、領域Ａにサービスαの現用のストレージが割り当てられている。ストレージ２には、領域Ｂにサービスβの待機用のストレージが割り当てられ、領域Ｃにサービスβのストレージが割り当てられている。

物理構成は監視対象となるハードウェアの物理的な構成を意味する。図８に示す例では、ＣＰＵサーバＡやストレージ１等のハードウェアが監視対象となる。論理構成は管理対象となる業務システムの論理的な構成を意味する。図９に示す構成情報では、最上位にサービスα、βが配置され、最下位にストレージ１、２およびＣＰＵサーバＡ、Ｂが配置され、その中間にＶＭ１〜ＶＭ３および領域Ａ〜領域Ｃが配置された階層構造で表現される。業務システムの１つであるサービスβに注目すると、図９では、サービスβの下位にＶＭ２とＶＭ３の仮想マシンが接続される論理構成が可視化されている。

なお、図８および図９に示す例では、説明を簡単にするために構成情報を単純化しており、実際のサービスの構成とは異なる。また、「領域」、「ＣＰＵサーバ」等の名称を用いているが、これはイメージを掴みやすくするための仮の名称である。

最下位の構成要素であるストレージ１、２およびＣＰＵサーバＡ、Ｂは監視対象であり、監視により障害状態が定まる。判定ルールは、最下位の構成要素の障害状態に基づいて、他の構成要素の障害状態を判定するためのルールである。

図８および図９に示す例において、判定ルールは次の３つであるものとする。
１．領域Ａ〜領域ＣおよびＶＭ１〜ＶＭ３は、それぞれ下位のストレージまたはＣＰＵサーバの障害状態を引き継ぐ。
２．サービスαは、ＶＭ１が障害か、または領域Ａ〜領域Ｂの５０％以上が障害の場合、障害状態と判定される。
３．サービスβは、ＶＭ２〜ＶＭ３の２つ以上が障害か、または領域Ｃが障害の場合、障害状態と判定される。

図８および図９に示す例において、ストレージ２とＣＰＵサーバＢとに障害（続行不能）が発生したとする。正確には、統合運用管理システムによる監視の結果、ストレージ２とＣＰＵサーバＢの障害状態が決定されたものとする。このとき、判定ルールにしたがって各構成要素の障害状態が判定され、その結果、図１０に示すような障害の可視化が行われる。図１０に示す星印は障害が発生して処理が続行不能であることを示し、三角印は障害が発生しているが処理が続行可能であることを示す。

図１０に示すように、領域Ｂは、下位のストレージの障害状態を引き継ぐ判定ルール「１」により、障害と判定されるが、領域Ａが障害ではないため、その上位のサービスαは、判定ルール「２」により、障害とは判定されない。一方、サービスβは、ＶＭ２、領域ＣおよびＶＭ３で構成され、判定ルール「１」により領域Ｃが障害と判定されるため、判定ルール「３」によりサービスβが障害と判定される。

林憲亮，外１名，「クラウド環境における運用管理ソリューション」，ＮＴＴ技術ジャーナル，日本電信電話株式会社，２０１１年８月１日，ｖｏｌ．２３ Ｎｏ．８，ｐｐ．１９−２４

図１０において、サービスβの障害（続行不能）の原因としては、領域ＣまたはＶＭ３の障害が可能性として考えられるが、そのいずれであるかは、管理者は、図１０だけからは直ちにはわからない。判定ルールを参照すれば、実際には領域Ｃが主原因であること、すなわち領域Ｃの障害を是正すればサービスβの障害は解消されることがわかる。一方、判定ルールにたよらずに、ＶＭ３の障害を是正してもサービスβの障害が解消されないので、そのときにＶＭ３が主原因ではないことが初めてわかる。

上記の統合運用管理システムでは、構成情報に障害状態をマップして表示しているだけなので、管理者は、直感的に因果関係がわからず、障害により影響を受けるサービスとその程度を直ちに把握することができず、サービスへの影響を解消するためにはどの部分の障害を是正することが第一かを直ちに把握できないという問題がある。

本発明は上述したような技術が有する問題点を解決するためになされたものであり、個々の障害に対する影響範囲や個々のサービスの障害に対する原因部分を切り分けて表示可能にした運用管理装置、運用管理方法、およびコンピュータに実行させるためのプログラムを提供することを目的とする。

上記目的を達成するための本発明の運用管理装置は、
サービスを含む複数の構成要素の物理構成および論理構成を示す構成情報と、障害の発生した構成要素を基に他の構成要素の状態を判定するための判定ルールとを記憶する記憶部と、
表示部と、
前記構成情報に基づいて最上位に前記サービスを配置し、最下位に監視対象となる構成要素を配置し、該サービスの構成および論理を反映させたツリー構造を生成し、前記監視対象となる構成要素に障害が発生すると、前記判定ルールにしたがって前記ツリー構造における他の構成要素の障害状態を判定し、指定された構成要素を基点に障害の影響範囲または原因部分となる構成要素を特定して前記表示部に表示させる制御部と、
を有する構成である。

また、本発明の運用管理方法は、表示部を有する運用管理装置による運用管理方法であって、
サービスを含む複数の構成要素の物理構成および論理構成を示す構成情報を格納し、
前記構成情報に基づいて、最上位に前記サービスを配置し、最下位に監視対象となる構成要素を配置し、該サービスの構成および論理を反映させたツリー構造を生成し、
前記監視対象となる構成要素に障害が発生すると、判定ルールにしたがって前記ツリー構造における他の構成要素の障害状態を判定し、
指定された構成要素を基点に障害の影響範囲または原因部分となる構成要素を特定して前記表示部に表示させるものである。

さらに、本発明のプログラムは、表示部を有するコンピュータに、
サービスを含む複数の構成要素の物理構成および論理構成を示す構成情報を格納する手順と、
前記構成情報に基づいて、最上位に前記サービスを配置し、最下位に監視対象となる構成要素を配置し、該サービスの構成および論理を反映させたツリー構造を生成する手順と、
前記監視対象となる構成要素に障害が発生すると、判定ルールにしたがって前記ツリー構造における他の構成要素の障害状態を判定する手順と、
指定された構成要素を基点に障害の影響範囲または原因部分となる構成要素を特定して前記表示部に表示させる手順を実行させるものである。

本発明によれば、サービスを含む複数の構成要素のうち、障害の影響範囲または原因部分の構成要素に絞り込んで表示されるため、障害の影響範囲または原因部分の把握がし易くなり、管理者は障害発生の因果関係を直感的に直ちに把握することができるようになる。

本実施形態の運用管理装置の一構成例を示すブロック図である。 本実施形態のツリー構造の生成手順を示すフローチャートである。 図９に示した構成情報を本実施形態のツリー構造に変換した場合を示す図である。 本実施形態の運用管理装置の動作手順を示すシーケンス図である。 図１に示した構成情報障害計算部の動作手順を示すフローチャートである。 本実施形態における、障害の可視化の具体例を示す図である。 障害の影響範囲および原因部分の絞り込み表示の具体例を示す図である。 従来の構成情報を説明するための図である。 従来の構成情報によりサービス全体の構造を表した図である。 図９に示した構成要素に発生した障害の可視化の一例を示す図である。

本実施形態の運用管理装置は、障害発生の因果関係を管理者が直感的に理解しやすいように構成情報をツリー構造に変更し、発生した障害の影響範囲または原因部分を絞り込んで表示することを特徴とする。

本実施形態の運用管理装置の構成を説明する。図１は本実施形態の運用管理装置の一構成例を示すブロック図である。

図１に示すように、本実施形態の運用管理装置１０は、障害発生の監視対象の情報処理装置である監視対象機器５０と通信可能に接続されている。

運用管理装置１０と監視対象機器５０の接続方法は、有線および無線のいずれであってもよく、または、それらの組み合わせであってもよい。また、図１では、説明を簡単にするために監視対象機器５０が１台の場合を示しているが、監視対象機器５０は複数設けられていてもよい。監視対象機器５０はネットワーク（不図示）を介して運用管理装置１０と接続されてもよく、直接に信号線を介して運用管理装置１０と接続されてもよい。

運用管理装置１０は、制御部１１と、記憶部１２と、表示部１５とを有する。記憶部１２は、イベント判定データベース（ＤＢ）２５と、構成情報ＤＢ２６と、判定ルールＤＢ２７とを有する。以下に、各構成について詳しく説明する。

イベント判定ＤＢ２５には、監視対象機器５０に発生したイベントから監視対象機器５０の状態を判定するためのルールが登録されている。例えば、監視対象機器５０に発生したイベントから、監視対象機器５０のどの構成要素に障害が発生したかを判定するためのルールが登録されている。構成情報ＤＢ２６には、監視対象機器５０がユーザに提供するサービスを含む複数の構成要素の物理構成および論理構成を示す構成情報が格納されている。判定ルールＤＢ２７には、障害が発生した構成要素を基に他の構成要素の状態を判定するための判定ルールが登録されている。

制御部１１は、監視部２１と、イベント判定部２２と、構成・障害可視化部１３とを有する。制御部１１は、プログラムにしたがって処理を実行するＣＰＵ（不図示）と、プログラムを記憶するメモリ（不図示）とを有する。ＣＰＵがプログラムにしたがって処理を実行することで、図１に示す監視部２１、イベント判定部２２および構成・障害可視化部１３が運用管理装置１０に仮想的に構成される。

監視部２１は、監視対象機器５０の状態を監視し、監視対象機器５０の状態等の情報の取得または監視対象機器５０からのトラップの受信等により、イベントの発生を検出する。

イベント判定部２２は、イベント発生を検出した旨の情報を監視部２１から受信すると、発生したイベントをイベント判定ＤＢ２５に照らし合わせ、監視対象機器５０の障害状態を判定する。

構成・障害可視化部１３は、構成情報ＤＢ２６に格納された構成情報に基づいてサービスの構成および論理を反映させたツリー構造を生成するツリー構造生成部２３と、障害が発生した構成要素を基点に判定ルールにしたがって障害の影響範囲または原因部分を抽出する構成情報障害計算部２４とを有する。

ツリー構造生成部２３によるツリー構造生成方法を詳しく説明する。本実施形態における、障害の可視化手法では、はじめに構成情報をサービスの構成・論理を反映させた情報に変更する。本実施形態で説明するツリー構造はその方法の一例である。これにより、後で詳しく説明するが、障害状態の判定ルールが単純なものとなる。

図２は本実施形態のツリー構造の生成手順を示すフローチャートである。なお、ツリー構造の生成処理は、構成情報ＤＢ２６に登録されている構成情報の更新を契機に行われてもよく、構成情報ＤＢ２６に新しい構成情報が登録されたときに行われてもよく、管理者による指示の入力を契機に行われてもよい。

ツリー構造生成部２３は、最上位にサービスを配置し、最下位に監視対象となる構成要素を配置したツリー構造に各構成要素を配置するために、構成情報をツリー構造に変換する（ステップ１０１）。このとき、ツリー構造生成部２３は、必要と判断した場合、同一の構成要素をコピーして配置する（ステップ１０２、１０３）。元の構成要素とコピーされた構成要素は、形式的には別扱いとするが、実態としては同一であり、その構成要素の状態等は１つである。ステップ１０３の処理は、例えば、複数の上位の構成要素を含む構成要素に対して行われる。図９で説明すると、「ＣＰＵサーバＡ」が２つの上位の構成要素を含む構成要素に該当する。ＣＰＵサーバＡはその上位にあるＶＭ１とＶＭ２の構成要素を含んでいる。

さらに、ツリー構造生成部２３は、必要と判断した場合、中間階層の構成要素であるサブ構成要素を新たに導入する（ステップ１０４、１０５）。新たに導入されるサブ構成要素は、サービスの構成・論理を反映させるために必要十分であるように適宜選択される。その後、ツリー構造生成部２３は完成したツリー構造を表示部１５に表示させる（ステップ１０６）。なお、図２に示すステップ１０２、１０４の判定処理については、具体例を用いて、後で詳しく説明する。

続いて、上記のツリー構造の生成時における「構成情報の変更」について説明する。

本実施形態の運用管理方法のポイントの１つは、障害の因果関係をより把握しやすいように構成情報を変更することである。

ステップ１０４、１０５における処理では、「新たに導入されるサブ構成要素は、サービスの構成・論理を反映させるために必要十分であるように、適宜選択される」と説明している。サービスの構成・論理の反映を直接行うためには、それらに対する知識が必要である。このため、構成情報の変更は、管理者により手動で行われることが基本と想定される。このとき、判定ルールの分解・変更もまた、管理者により手動で行われることが考えられる。

しかし、構成情報の変更にあたって、サービスの構成・論理に対する知識を直接に反映しなくてもよい方法が考えられる。すなわち、判定ルールを単純なものに分解し、その分解に従って必要なサブ構成要素を導入することで、結果として構成情報の変更を行う方法である。このような方法を用いれば、サービスの構成・論理に対する知識を直接用いる必要がなく、判定ルールの分解という操作だけで構成情報の変更を行うことができる。つまり、構成情報の変更を管理者による手動ではなく、コンピュータに処理させる自動化も可能となる。

判定ルールの分解においては、多段論理式の各段に対する分解、あるいはその類似の手法を用いることができ、これはよく知られた単純なアルゴリズムで容易に実現可能である。例えば、元の判定ルールに式 = A and (B or (C and D))が含まれている場合、この論理式は、中間階層であるａ，ｂを導入することにより、以下のような単純な論理のみからなる構成に、容易に変更できる。
式 = A and a，a = B or b，b = C and D
なお、本実施形態における、構成情報の変更には、サブ構成要素の導入に関すること以外にもツリー構造に変更するという操作が存在するが、これも単純なアルゴリズムを用いて自動化することは容易である。具体的には、複数の上位の構成要素を含む構成要素がある場合、当該構成要素およびその下位の構成要素のコピーを作って、これらを分離する。この操作を必要なだけ繰り返すことにより、ツリー構造に展開できることは自明である。

次に、図２に示したツリー構造生成手順におけるステップ１０２、１０４の処理を、具体例を用いて説明する。図３は、図９に示した構成情報を本実施形態のツリー構造に変換した場合を示す図である。

構成情報をツリー構造に変換する際、図２に示したステップ１０２において、ツリー構造生成部２３は、図９に示す構成情報を参照し、各構成要素の上下の接続を調べる。ここでは、領域Ａ〜領域Ｃ、ＶＭ１〜ＶＭ３のそれぞれについて、下位に接続される構成要素に注目する。図９から、領域Ｂと領域Ｃはストレージ２に接続され、ＶＭ１とＶＭ２はＣＰＵサーバＡに接続されていることがわかる。ツリー構造生成部２３は、ストレージ２が上位の領域Ｂと領域Ｃを含んでいると判定すると、ストレージ２をコピーし、２つのストレージ２のそれぞれを領域Ｂと領域Ｃのそれぞれの下位に配置する。また、ツリー構造生成部２３は、ＣＰＵサーバＡが上位のＶＭ１とＶＭ２を含んでいると判定すると、ＣＰＵサーバＡをコピーし、２つのＣＰＵサーバＡのそれぞれをＶＭ１とＶＭ２のそれぞれの下位に配置する。その結果、図３に示すように、構成要素となるＣＰＵサーバＡとストレージ２に対してコピーが作成され、それぞれ最下位に配置される。

また、図２に示したステップ１０４において、ツリー構造生成部２３は、サービスの構成および論理にしたがって、サービスの構成要素を細分化可能か否かを判定し、可能と判断すれば、ステップ１０５でサブ構成要素を追加する。

図９を参照すると、サービスαは「領域Ａと領域Ｂ」を含む構成要素と「ＶＭ１」を含む構成要素に細分化することが可能であることがわかる。ツリー構成生成部２３または管理者は、サービスαについて、「領域Ａと領域Ｂ」を含むサブ構成要素（ストレージサブシステムαと称する）を追加し、「ＶＭ１」を含むサブ構成要素（ＣＰＵサブシステムαと称する）を追加している。サービスβについても、ツリー構造生成部２３または管理者は、サービスαと同様に判定を行ってサブ構成要素を追加する。その結果、図３に示すように、サービス毎に「ＣＰＵサブシステム」および「ストレージサブシステム」というサブ構成要素がツリー構造に導入される。

図９に示した構成情報では、最上位のサービスα、βから中間階層のＶＭ１〜ＶＭ３までの論理構成と、ＣＰＵサーバＡおよびストレージ１等の物理構成との接続をマップして表示しているに過ぎない。これに対して、図３に示すツリー構造では、サービスα、βのそれぞれにＣＰＵサブシステムとストレージサブシステムのサブ構成要素を定義し、それぞれのサブ構成要素における論理と構成が一目でわかるように可視化されている。

図１に示す構成情報障害計算部２４は、監視対象機器５０の障害状態の判定結果をイベント判定部２２から受信すると、構成情報ＤＢ２６および判定ルールＤＢ２７を参照し、判定ルールにしたがって各構成要素の障害状態を論理式の計算により判定し、障害状態の判定結果を含むツリー構造を表示部１５に表示させる。また、構成情報障害計算部２４は、指定された構成要素を基点として、対応する影響範囲・原因部分を絞り込んで表示部１５に表示させる。基点となる構成要素の指定は、例えば、管理者の入力によって行われる。影響範囲および原因部分の絞り込み表示については、後で具体例を用いて詳しく説明する。

ここで、障害判定に用いられる判定ルールについて説明する。本実施形態では、サブ構成要素の導入により、判定ルールが、以下のように変更されている。
１．サービスβは、ＣＰＵサブシステムβまたはストレージサブシステムβが障害の場合、障害状態と判定される。
２．ＣＰＵサブシステムβは、ＶＭ２〜ＶＭ３の２つ以上が障害の場合、障害状態と判定される。
３．ストレージサブシステムβは、領域Ｃが障害の場合、障害状態と判定される。
４．サービスα、ＣＰＵサブシステムα、ストレージサブシステムαに関しても、図３に示すツリー構造に基づいて、１〜３と同様にルールが決められている。

本実施形態では、サービスの構成および論理にしたがってサブ構成要素を中間階層に追加することで、サービスの構成要素の単位が従来よりも細分化されている。そのため、本実施形態の判定ルールでは、従来に比べて判定ルールが単純化されている。

本実施形態の判定ルールの内容について、さらに詳しく説明する。

管理者による理解を容易かつ直感的に可能にするためにも、また、「構成情報の変更」の自動化を容易にするためにも、個々の判定ルールは単純なものである必要がある。すなわち、論理式で言えば一段のＡＮＤまたはＯＲのみ（リテラルの否定はあり）、あるいは判定オペレーションで言えば一種類であることが望ましい。

具体的な判定ルールとしては、例えば、以下のようなものが考えられる。
・最も重大な障害状態を伝搬させる（ＯＲ）
・子の構成要素が「全て障害」ならば障害とする（ＡＮＤ）
・子の構成要素のうち「障害状態のものがＸ％以上／を超える」であれば障害（「Ｘ」および「以上／を超える」を予め指定）
・子の構成要素のうち「障害状態のものがＸ個以上／を超える」であれば障害（「Ｘ」および「以上／を超える」を予め指定）
なお、これらの条件は反転（障害状態のもの⇔障害状態でないもの）させてもよい。

上記のような適用可能な判定ルールの限定を行っても、必要に応じて構成情報を変更し中間階層を置くことにより、全体としての判定ルールの表現能力に著しい制約が加わることはない。例えば、論理式を例に取れば、任意の論理式は多段論理式として表すことができ、多段論理式は中間変数を導入することにより一段の論理式の組として表すことが可能なことはよく知られている。「構成情報の変更」の説明のところで、その一例を説明している。

図１に示す表示部１５は、構成情報障害計算部２４によって求められた各構成要素の障害状態を予め作成されたツリー構造に表示する、または、障害の影響範囲・原因部分を絞り込んで表示する。図１には、表示部１５がツリー構造の表示を意味する「構成情報に基づく可視化」と、「影響範囲・原因部分の絞り込み表示」を行う様子を模式的に示す。

次に、本実施形態の運用管理装置１０の動作手順を説明する。ここでは、ツリー構造生成部２３によってツリー構造が予め作成されているものとする。

図４は本実施形態の運用管理装置の動作手順を示すシーケンス図である。図５は構成情報障害計算部の動作手順を示すフローチャートである。図６および図７は、障害の可視化の具体例を示す図である。

監視部２１は監視対象機器５０の状態を監視する。監視対象機器５０でイベントが発生すると（ステップ２０１）、監視部２１は、監視対象機器５０の状態を示す情報の取得または監視対象機器５０からのトラップの受信により、イベントの発生を検出する（ステップ２０２）。イベント判定部２２は、イベント発生を検出した旨の情報を監視部２１から受信すると、イベント判定ＤＢ２５を参照し、発生したイベントから監視対象機器５０の障害状態を判定する（ステップ２０３）。

構成情報障害計算部２４は、監視対象機器５０の障害状態の判定結果をイベント判定部２２から受信すると、各構成要素の障害状態を判定する（ステップ２０４）。ステップ２０４において、構成情報障害計算部２４は、図５に示すように、イベント発生を管理者に通知するための警告メッセージ等を表示部１５に表示させ（ステップ３０１）、続いて、各構成要素の障害状態の判定結果を表示部１５が表示しているツリー構造に表示させる（ステップ３０２）。これにより、図４のステップ２０５において、表示部１５は、障害の発生した構成要素を他の構成要素とは異なるように表示したツリー構造を表示する。

図６は図４のステップ２０５で表示されたツリー構造の一例を示す図であり、図３に示したツリー構造に障害の有無などが表示されている。図６では、障害が発生して処理が続行不能な構成要素およびサービスに星印を表示し、障害が発生しているが処理が続行可能な構成要素およびサービスに三角印を表示し、障害の有無とその程度をマップ表示している。

図６において、サービスβの障害（続行不能）の原因が、ストレージサブシステムβであり、その元をさらに辿れば領域Ｃの障害であり、ＣＰＵサブシステムβ（その下位に障害が発生しているＶＭ３）ではないことが、直ちにわかる。このとき、サービスβの障害状態の判定ルールも単純になっているため、より直感的な因果関係の理解に寄与している。本実施形態の障害の可視化方法では、論理のネストが分解されているからである。具体的に説明すると、「サービスβはＣＰＵサブシステムβまたはストレージサブシステムβが障害の場合、障害状態」という一段の論理と、「ＣＰＵサブシステムβは、ＶＭ２〜ＶＭ３の２つ以上が障害の場合、障害状態と判定（ストレージサブシステムβに関しても同様）」といった論理とに分解されている。この例では説明のため、ある程度構成とルールを単純化しているが、より複雑な構成とルールを考えた場合、判定ルールの単純化がより直感的な因果関係の理解に寄与することは容易に想定できる。

図１０に示した、障害の可視化では、構成情報に障害状態をマップして表示しているだけなので、管理者は、直感的に因果関係がわからず、障害により影響を受けるサービスとその程度の把握を直ちに行うことができない。その原因として、従来の構成情報では、障害判定対象の粒度が荒く、サービスから見た際の障害による影響の度合いの把握が困難であることが考えられる。図９を参照して説明すると、サービスβにおいては「ＶＭが冗長化されているが、領域は冗長化されていない」という構成と論理が、構成情報に十分に反映されていない。このことは、サービスβの障害状態の判定ルールが複雑になっていることからもわかる。すなわち、「“冗長構成のＶＭの２つ以上が障害”および“非冗長構成の領域が障害”のうち、いずれかが成立した場合に障害」という論理のネストになっていた。

これに対して、本実施形態では、構成情報をツリー構造で表現できるものに限定し、必要に応じて中間階層を導入して構成情報を変更して、サービスの構成および論理にしたがって障害の原因部分の単位を細分化することで、従来に比べて、障害判定対象の粒度が細かくなる。これにより、障害状態の判定ルールが単純なものとなり、上述したように、障害判定の論理のネストが分解されるので、障害の因果関係を直感的に理解しやすくなる。

しかし、複数の障害やイベントが同時に発生した場合、個々の障害に対する影響範囲や、個々のサービスの障害に対する原因部分の切り分けを管理者が一目でできないことがある。

具体的には、図６において、管理者がストレージ２の障害の影響範囲を一目で判断することは困難である。ストレージ２の障害の影響範囲は、領域Ｃからストレージサブシステムβを経由してサービスβに到達するパスと、領域Ｂからストレージサブシステムαまで到達するパスとがある。図中でパスを辿ることで影響範囲を確認できるが、ストレージ２が複数個所にあるため、これを一目で判断することは困難である。図６に示す例では説明のために構成を単純化しているが、より複雑な構成であった場合、図中でパスを辿ることが容易ではないことが想像できる。

また、図６に示す例では、ストレージ２とＣＰＵサーバＢの、複数の構成要素に障害が発生しており、それらが同時に表示されているため、管理者は、表示部１５に表示されるツリー構造において、上記の「辿る」という行為をすることなしに、これらの切り分けを行うことができない。

この問題を解決するため、本実施形態では、指定された構成要素を基点として、それに対応する影響範囲または原因部分を絞り込んで表示する手段を提供する。

図５に示すステップ３０３において、構成情報障害計算部２４は、管理者から構成要素を指定する旨の指示が入力されると、指定された構成要素を基点として、対応する影響範囲または原因部分を絞り込んで表示部１５に表示させる。これにより、図４のステップ２０６において、表示部１５が影響範囲および原因部分の絞り込み表示を行う。なお、影響範囲および原因部分のうち、表示対象をいずれか一方とするか、両方とするか、管理者が指定してもよく、予め設定されていてもよい。

構成情報障害計算部２４は、管理者に指定された構成要素について、障害の影響範囲を調べる場合、指定された構成要素を基点にして上位の構成要素を辿り、障害の原因部分を調べる場合には、指定された構成要素を基点にして下位の構成要素を辿る。そして、構成情報障害計算部２４は、辿った経路にある構成要素から、基点となる構成要素と同等以上の障害状態である構成要素のみをピックアップする。辿った先の構成要素が基点となる構成要素よりも軽微な障害状態である場合はピックアップせず、それ以上辿らない。なお、障害状態はその程度の情報が予め定義されており、構成情報に、構成要素毎にその情報が添付されている。

ただし、コピーした構成要素の障害は、元の構成要素と同一のものとして扱う。図６に示す例では、ストレージ２（ｆｏｒサービスα）とストレージ２（ｆｏｒサービスβ）の障害状態は区別されず同一のものとして扱う。これらの影響範囲および原因部分の特定方法に関するルールも、判定ルールに予め規定されている。

図７（ａ）は、図６においてストレージ２を基点として、それに対応する影響範囲を表示させた場合を示す。図７（ｂ）は、図６においてサービスβを基点として、それに対応する原因部分を表示させた場合を示す。

図７（ａ）および図７（ｂ）を参照すると、指定された構成要素に対する影響範囲および原因部分が絞り込んで表示されていることがわかる。図７（ａ）は、ストレージ２→ストレージサブシステムβ→領域Ｃおよび領域Ｂが影響範囲であることを示す。図７（ｂ）は、サービスβ→ストレージサブシステムβ→領域Ｃ→ストレージ２が原因部分であることを示す。この場合、着目した構成要素に関係しない障害、例えば、サービスβに対するＣＰＵサーバＢはフィルタアウトされる。このようにして、障害の影響範囲および原因部分が運用管理装置１０によって特定され、表示される。また、管理者は、図６に示したツリー構造において「辿る」といった行為をすることなしに、これらの切り分けを行うことができる。これにより、複数の障害・イベントが同時に発生している場合でも、管理者は、個々の障害に対する影響範囲や、個々のサービスの障害に対する原因部分の切り分けが一目でできるようになる。

なお、影響範囲・原因部分の絞り込み表示について、図７では、対象となる構成要素を箇条書きにリスト表示により提示する方法を示しているが、この方法は一例であり、絞り込んだ表示ができれば、表現方法はリスト表示に限定されない。

例えば、図６と同様にマップ表示するが、絞り込み対象の構成要素だけハイライトし、他の構成要素をグレーアウトする表現方法や、絞り込み対象の構成要素だけ切り出し表示する表現方法であってもよい。このように、ツリー構造に絞り込み対象の構成要素を表示する場合、管理者は、管理対象の業務システム全体に対して、発生した障害の影響範囲や原因部分がどの程度あるかを把握できるメリットがある。

また、基点となる構成要素が管理者によって指定される場合で説明したが、構成要素の指定は、例えば、重要な構成要素などを対象に予めプログラムに設定されていてもよい。

本実施形態によれば、サービスを含む複数の構成要素のうち、障害の影響範囲または原因部分の構成要素に絞り込んで表示されるため、障害の影響範囲または原因部分の把握がし易くなり、管理者は障害発生の因果関係を直感的に直ちに把握することができるようになる。その結果、管理者は、どのサービスが障害によりどの程度の影響を受けているかを把握し、そのようなサービスへの影響を解消するためにはどの部分の障害を是正することが第一かを把握することが可能となる。

なお、本実施形態における、構成情報に基づくツリー構造の表示方法、および障害の影響範囲または原因部分の可視化方法を実行するための手順を記述したプログラムをコンピュータにインストールし、コンピュータに本発明の運用管理方法を実行させてもよい。

１０ 運用管理装置
１１ 制御部
１２ 記憶部
１３ 構成・障害可視化部
１５ 表示部

Claims (7)

1. サービスを含む複数の構成要素の物理構成および論理構成を示す構成情報と、障害の発生した構成要素を基に他の構成要素の状態を判定するための判定ルールとを記憶する記憶部と、
   表示部と、
   前記構成情報に基づいて最上位に前記サービスを配置し、最下位に監視対象となる構成要素を配置し、該サービスの構成および論理を反映させたツリー構造を生成し、前記ツリー構造を生成する際、前記サービスの構成要素が、構成要素の種別ごとに細分化可能であるか否かを判定し、構成要素の種別ごとに細分化可能であると判定した場合には、前記サービスと、細分化された各種別の構成要素との間の中間階層に、各種別に応じたサブ構成要素を種別を示す情報として追加し、前記監視対象となる構成要素に障害が発生すると、前記判定ルールにしたがって前記ツリー構造における他の構成要素の障害状態を判定し、指定された構成要素を基点に障害の影響範囲または原因部分となる構成要素を特定して前記表示部に表示させる制御部と、
   を有する運用管理装置。
2. 請求項１記載の運用管理装置において、
   前記制御部は、
   前記ツリー構造を生成する際、複数の上位の構成要素を含む構成要素があると、該構成要素および該構成要素の下位にある構成要素を複製して配置する、運用管理装置。
3. 請求項２記載の運用管理装置において、
   前記判定ルールは、前記サービスの障害の有無は該サービスの下位のサブ構成要素の障害の有無によって判定され、前記サブ構成要素の障害の有無は該サブ構成要素の下位の構成要素について予め決められた障害判定のルールにしたがって判定されることを含む、運用管理装置。
4. 請求項１から３のいずれか１項記載の運用管理装置において、
   前記制御部は、前記表示部にツリー構造を表示させ、該ツリー構造において、前記影響範囲または前記原因部分となる構成要素を他の構成要素とは異なるように前記表示部に表示させる、運用管理装置。
5. 請求項１から３のいずれか１項記載の運用管理装置において、
   前記制御部は、前記影響範囲または前記原因部分となる構成要素のリストを前記表示部に表示させる、運用管理装置。
6. 表示部を有する運用管理装置による運用管理方法であって、
   サービスを含む複数の構成要素の物理構成および論理構成を示す構成情報を格納し、
   前記構成情報に基づいて、最上位に前記サービスを配置し、最下位に監視対象となる構成要素を配置し、該サービスの構成および論理を反映させたツリー構造を生成し、前記ツリー構造を生成する際、前記サービスの構成要素が、構成要素の種別ごとに細分化可能であるか否かを判定し、構成要素の種別ごとに細分化可能であると判定した場合には、前記サービスと、細分化された各種別の構成要素との間の中間階層に、各種別に応じたサブ構成要素を種別を示す情報として追加し、
   前記監視対象となる構成要素に障害が発生すると、判定ルールにしたがって前記ツリー構造における他の構成要素の障害状態を判定し、
   指定された構成要素を基点に障害の影響範囲または原因部分となる構成要素を特定して前記表示部に表示させる、運用管理方法。
7. 表示部を有するコンピュータに、
   サービスを含む複数の構成要素の物理構成および論理構成を示す構成情報を格納する手順と、
   前記構成情報に基づいて、最上位に前記サービスを配置し、最下位に監視対象となる構成要素を配置し、該サービスの構成および論理を反映させたツリー構造を生成し、前記ツリー構造を生成する際、前記サービスの構成要素が、構成要素の種別ごとに細分化可能であるか否かを判定し、構成要素の種別ごとに細分化可能であると判定した場合には、前記サービスと、細分化された各種別の構成要素との間の中間階層に、各種別に応じたサブ構成要素を種別を示す情報として追加する手順と、
   前記監視対象となる構成要素に障害が発生すると、判定ルールにしたがって前記ツリー構造における他の構成要素の障害状態を判定する手順と、
   指定された構成要素を基点に障害の影響範囲または原因部分となる構成要素を特定して前記表示部に表示させる手順を実行させるためのプログラム。

Images