JP5745077B2 - 根本原因を解析する管理計算機及び方法 - Google Patents

根本原因を解析する管理計算機及び方法 Download PDF

Info

Publication number
JP5745077B2
JP5745077B2 JP2013535648A JP2013535648A JP5745077B2 JP 5745077 B2 JP5745077 B2 JP 5745077B2 JP 2013535648 A JP2013535648 A JP 2013535648A JP 2013535648 A JP2013535648 A JP 2013535648A JP 5745077 B2 JP5745077 B2 JP 5745077B2
Authority
JP
Japan
Prior art keywords
event
causality
management
propagation model
information
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Fee Related
Application number
JP2013535648A
Other languages
English (en)
Other versions
JPWO2013046287A1 (ja
Inventor
崇之 永井
崇之 永井
名倉　正剛
正剛 名倉
菅内　公徳
公徳 菅内
黒田　沢希
沢希 黒田
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Hitachi Ltd
Original Assignee
Hitachi Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Hitachi Ltd filed Critical Hitachi Ltd
Publication of JPWO2013046287A1 publication Critical patent/JPWO2013046287A1/ja
Application granted granted Critical
Publication of JP5745077B2 publication Critical patent/JP5745077B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/02—Standardisation; Integration
    • H04L41/0213—Standardised network management protocols, e.g. simple network management protocol [SNMP]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0706—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment
    • G06F11/0709—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment in a distributed system consisting of a plurality of standalone computer nodes, e.g. clusters, client-server systems
    • G—PHYSICS
    • G05—CONTROLLING; REGULATING
    • G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B23/00—Testing or monitoring of control systems or parts thereof
    • G05B23/02—Electric testing or monitoring
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/079—Root cause analysis, i.e. error or fault diagnosis
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06N—COMPUTING ARRANGEMENTS BASED ON SPECIFIC COMPUTATIONAL MODELS
    • G06N5/00—Computing arrangements using knowledge-based models
    • G06N5/02—Knowledge representation; Symbolic representation
    • G06N5/022—Knowledge engineering; Knowledge acquisition
    • G06N5/025—Extracting rules from data

Description

本発明は、計算機システム管理するプログラムに関する。
特許文献１には、計算機システムの管理対象コンポーネントで発生した問題の原因を決定する管理サーバが開示されている。より具体的には特許文献１の管理プログラムは、管理対象装置における各種障害をイベント化し、イベントＤＢに情報を蓄積する。また、この管理プログラムは、管理対象装置において発生した複数の障害イベントの因果関係を解析するための解析エンジンを持っている。
解析エンジンは、管理対象装置のインベントリ情報を持つ構成ＤＢにアクセスして、Ｉ／Ｏ系路上のパス上にある管理対象装置内のコンポーネントを１グループとして認識する。なお、管理対象装置内又は管理対象装置に跨る複数の当該装置または装置内のコンポーネント間の関係をトポロジと呼ぶ。そして、この解析エンジンは前記トポロジに対し、事前に定められた条件文と解析結果からなる障害伝播モデル（ＩＦ−ＴＨＥＮ形式ルール）を適用して因果律行列を構築する。
因果律行列には、他装置における障害の原因である原因イベントと、それによって引き起こされている関連イベント群が含まれる。具体的には、障害伝播モデルのＴＨＥＮ部に障害の根本原因として記載されているイベントが原因イベント、ＩＦ部に記載されているイベントのうち原因イベント以外のものが関連イベントである。
米国特許７１０７１８５号公報
特許文献１公開の技術では、管理対象の全ての装置及び全ての障害伝播モデルに基づいて、イベント解析前に因果律行列を作成する。そのため、大規模又は多数の障害伝播モデルが必要な複雑な計算機システムを解析する際の因果律行列のサイズが大きくなり、管理計算機の記憶資源（例えば、メモリ又は／及び二次記憶装置）を大量に消費していた。
以上の課題を解決するため、計算機システムを管理する管理計算機は、記憶資源にトポロジと、イベント伝播モデルと、一つ以上の因果律を含む因果律情報と、を格納し、管理計算機がイベントを解析又は検知した契機で、解析対象イベントに対応する所定の因果律が作成済みか否か判断し、未作成の場合はトポロジとイベント伝播モデルとに基づいて前記所定の因果律を作成する。なお、因果律情報の一例が上記因果律行列である。
上記手段によれば、より少ない管理計算機の記憶資源でより大規模又は多数の障害伝播モデルが必要な複雑な計算機システムを解析することができる。
計算機システムの物理構成例を示す図である。 ホストコンピュータの詳細な構成例を示す図である。 ストレージ装置の詳細な構成例を示す図である。 管理サーバの詳細な構成例を示す図である。 ＩＰスイッチの詳細な構成例を示す図である。 ホストコンピュータが含む論理ボリューム管理表の構成例を示す図である。 ホストコンピュータが含む論理ボリューム管理表の構成例を示す図である。 ホストコンピュータが含む論理ボリューム管理表の構成例を示す図である。 ストレージ装置が含むボリューム管理表の構成例を示す図である。 ストレージ装置が含むｉＳＣＳＩターゲット管理表の構成例を示す図である。 ストレージ装置が含むｉＳＣＳＩターゲット管理表の構成例を示す図である。 ストレージ装置が含むＩ／Ｏポート管理表の構成例を示す図である。 ストレージ装置が含むＲＡＩＤグループ管理表の構成例を示す図である。 ストレージ装置が含むディスク管理表の構成例を示す図である。 管理サーバが含むイベント管理表の構成例を示す図である。 管理サーバが含むイベント伝播モデルの構成例を示す図である。 管理サーバが含むイベント伝播モデルの構成例を示す図である。 管理サーバが含む因果律行列の構成例を示す図である。 管理サーバが含む因果律行列の構成例を示す図である。 管理サーバが含む因果律行列の構成例を示す図である。 管理サーバが含む因果律行列の構成例を示す図である。 管理サーバが含む因果律行列の構成例を示す図である。 管理サーバが含むトポロジ生成方式の構成例を示す図である。 管理サーバが含むトポロジ生成方式の構成例を示す図である。 管理サーバが実行する装置情報取得処理の全体フロー例を示すフローチャートである。 管理プログラムの論理的構成例を示した図である。 管理サーバが含む展開対象イベント伝播モデル管理表の構成例を示す図である。 管理サーバが実行するイベント確認処理の全体フロー例を示すフローチャートである。 管理サーバが実行するイベント伝播モデルオンデマンド展開処理の全体フロー例を示すフローチャートである。 管理サーバが実行するイベント伝播モデル再展開処理の全体フロー例を示すフローチャートである。 管理サーバが含む展開済イベント管理表の構成例を示す図である。 管理サーバが含む展開済起点コンポーネント管理表の構成例を示す図である。 実施例２において管理サーバが実行するイベント伝播モデルオンデマンド展開処理の全体フロー例を示すフローチャートである。 実施例２において管理サーバが実行するイベント伝播モデルオンデマンド展開処理の全体フロー例を示すフローチャートである。 実施例３において管理サーバが含むイベント伝播モデル管理表の構成例を示す図である。 実施例３において管理サーバが実行するイベント伝播モデルオンデマンド展開処理の全体フロー例を示すフローチャートである。 実施例の概要を説明した模式図である。 実施例３において管理サーバが実行するイベント伝播モデル再展開処理の全体フロー例を示すフローチャートである。 計算機システムの別な物理構成例を示す図である。
以下、図面を参照して、実施例を説明する。なお、以後の説明では「ａａａテーブル」、「ａａａリスト」、「ａａａＤＢ」、「ａａａキュー」、「ａａａ行列」等の表現にて実施例の情報を説明するが、これら情報は必ずしもテーブル、リスト、ＤＢ、キュー、行列、等のデータ構造以外で表現されていてもよい。そのため、データ構造に依存しないことを示すために「ａａａテーブル」、「ａａａリスト」、「ａａａＤＢ」、「ａａａキュー」、「ａａａリポジトリ」、「ａａａ行列」等について「ａａａ情報」と呼ぶことがある。さらに、各情報の内容を説明する際に、「識別情報」、「識別子」、「名」、「名前」、「ＩＤ」という表現を用いるが、これらについてはお互いに置換が可能である。さらに、データ内容を示すために「情報」という表現を用いているが、他の表現形式であってもよい。なお、実施例の説明において「リポジトリ」という用語を用いるが、「情報」と同じ意味である。
以後の説明では「プログラム」を主語として説明を行う場合があるが、プログラムはプロセッサによって実行されることで定められた処理をメモリ及び通信ポート（通信制御装置）を用いながら行うため、プロセッサを主語とした説明としてもよい。また、プログラムを主語として開示された処理は管理サーバ又はストレージシステム等の計算機、情報処理装置が行う処理としてもよい。また、プログラムの一部または全ては専用ハードウェアによって実現されてもよい。また、各種プログラムはプログラム配布サーバ（各種プログラムのインストールイメージを記憶する記憶資源と、配布処理を実施するＣＰＵとから構成）や記憶メディアによって各計算機にインストールされてもよい。
図２７は実施例１の概要を示した図である。管理サーバ３００００は、複数の管理対象装置１００００を管理する計算機である。管理対象装置の種別としては例えば、ホストコンピュータ、ＩＰスイッチやルータ等のネットワーク装置、あるいはＮＡＳやストレージ装置等がある。なお、管理対象装置が含むデバイス等の論理的又は物理的な構成物をコンポーネントと呼ぶ。コンポーネントの例としてはポート、プロセッサ、記憶資源、記憶デバイス、プログラム、仮想マシン、ストレージ装置内部で定義される論理ボリューム、ＲＡＩＤグループ等がある。なお、管理対象装置とコンポーネントを区別せずに扱う場合は管理オブジェクトと呼ぶ。
管理サーバ３００００は、これら管理対象装置の構成情報、障害又は性能を示す情報等の装置情報を取得し、取得した装置情報に基づいて、管理対象装置の管理情報（例えば構成情報、障害発生の有無、性能値等）を表示する。
なお、いくつかの管理対象装置は何かしらのネットワークサービス（例えば、ｉＳＣＳＩやファイル共有サービス、ＤＮＳ、その他Ｗｅｂサービス）のサーバであり、又他のいくつかの管理対象装置はクライアントとしてこれらサーバが提供するネットワークサービスを利用する。この場合、サーバである管理対象装置（サーバ）でサービス提供に関係する問題（例えば管理オブジェクトの障害や性能障害等）が発生すると当該サービスを利用しているクライアント管理対象装置（クライアント装置と呼ぶことがある）でも管理オブジェクトに関する問題が発生する。
なお、以後の説明では管理オブジェクトで発生した問題を管理サーバで示す情報をイベントと呼ぶ。また、「イベントの検知」とは「問題の発生を検知し、イベント情報を作成すること」を意味する。なお、「イベントの発生」は「問題の発生」と同じ意味である。
管理サーバ３００００は、ある管理対象装置で発生した問題の原因が別な管理対象装置で発生した問題であることを解析し、表示することができる。そのために管理サーバ３００００は以下の情報を格納し、解析に用いる。
＊ 構成情報。管理対象装置の構成（インベントリとも呼ばれる）を示す情報を格納する。なお、構成情報には管理対象装置が含むコンポーネントや、コンポーネント同士の対応関係といった管理オブジェクト間の対応関係が含まれる。また、構成情報には、クライアント装置に関して、ネットワークサービスを受けるためのサーバ装置（またはサーバ装置のコンポーネント）の識別情報が含まれる。例えば、後述するｉＳＣＳＩプロトコルによるボリューム提供がネットワークサービスであれば、識別情報としてｉＳＣＳＩターゲット名とＬＵＮを指定し、ストレージ装置が提供するボリュームにアクセスする。その他、Ｗｅｂであれば、識別情報としてＷｅｂサーバの名前を含むＵＲＬを指定し、Ｗｅｂページにアクセスする。
なお、構成情報にはサーバ装置に関して、アクセス元となるクライアント装置に関する識別情報を含む場合もある。このような管理対象装置内又は複数の管理対象装置に跨る複数の管理オブジェクト間の関係をトポロジと呼ぶ。
＊ 一つ以上のイベント伝播モデルの情報（以後、単にイベント伝播モデルと呼ぶ）。本情報は、一つ以上の観測種別ペアと原因種別ペアが含まれる。より詳細としては以下である。
原因種別ペア：管理オブジェクトの種別（管理オブジェクト原因種別と呼ぶことがある）と、イベントの種別（イベント原因種別）のペアである。イベント原因種別は、管理オブジェクト原因種別で定められる種別の管理オブジェクトで発生する可能性のあるイベントの種別である。
観測種別ペア：管理オブジェクトの種別（管理オブジェクト観測種別と呼ぶことがある）と、イベントの種別（イベント観測種別）のペアである。イベント観測種別は、管理オブジェクト観測種別で定められる種別の管理オブジェクトで発生する可能性のあるイベントの種別である。観測種別ペアは、原因種別ペアで定められるイベントが発生した場合に、合わせて発生するイベントの種別を示す。
なお、あるイベント伝播モデルに含まれる観測種別ペアのイベントを全て検知した場合に、対応する原因種別ペアのイベント発生が原因であるほうがより好ましいが、必須ではない。
管理サーバ３００００による解析処理は、より具体的にはイベント伝播モデルとトポロジに基づいて因果律を因果律情報に作成し、その上でイベントの解析を行う。なお、因果律とは、第１の管理オブジェクトで第１のイベントが発生した場合は、第２の管理オブジェクトで発生した第２のイベントが発生することを示す情報である。なお、第１のイベントが原因であると断定できる条件が、第１のイベントに関連した全ての第２イベントを検知すること、であるほうが望ましい。ただしこれは必須ではない。因果律情報は上記内容を示すことが出来れば、因果律行列の形式であってもよく、又は関係を示すポインタ情報を駆使して第１のイベントと第２のイベントとの関係を示したデータ構造であってもよい。
管理サーバ３００００は、オンデマンドで因果律を作成する。つまり、管理サーバ３００００は検知したが未解析である所定のイベントに対応する因果律が因果律情報に作成済みか否か判断し、未作成の場合は所定のイベントが関係するトポロジと、所定のイベントが関係するイベント伝播モデルと、を用いて因果律を作成し、そして所定のイベントの解析を行う。
イベント解析の例としては以下が考えられる。
＊ 検知したあるイベント１の原因となるイベント２を特定する。この特定処理は因果律情報を参照することで可能である。なお、管理サーバ（または後述する管理システム）は自身の表示デバイスにイベント１の情報と共に、イベント２が原因で当該イベントが発生した旨のメッセージを表示してもよい。
＊ 検知したあるイベント３を原因として発生する（またはする可能性がある）イベント４を求める。この特定処理は因果律情報を参照することで可能である。なお、管理サーバ（または後述する管理システム）は自身の表示デバイスに、イベント４がイベント３の発生が原因で発生する（またはする可能性がある）旨のメッセージを表示してもよい。
管理サーバ３００００は、イベントを検知した後に、検知イベントと関係する所定の因果律が因果律情報に作成済みか判断し、作成されていない場合は（１）検知イベントを観測種別ペア又は原因種別ペアに含むイベント伝播モデルと、（２）検知イベントが発生したコンポーネントと関係するトポロジと、に基づいて所定の因果律を因果律情報に作成する（後ほどの説明では因果律を展開するとも言う）。なお、このようなイベント検知を契機とした因果律の展開をオンデマンド展開と呼ぶ。オンデマンド展開によって大規模な計算機システムや複雑な計算機システムを対象にしたイベント解析でも因果律情報のサイズをより少なくできる。
管理サーバ３００００が管理対象装置の構成変更、追加、又は削除を検知した場合、いずれかのトポロジが更新、追加、又は削除される場合がある。管理サーバ３００００は更新又は削除されたトポロジに基づいて作成された因果律を因果律情報から削除する。その後、更新されたトポロジに関連する因果律についてはオンデマンド展開で作成される。なお、追加されたトポロジについては前述のオンデマンド展開で因果律を作成する。
解析開始から長時間経過すると、様々な管理オブジェクトから様々な種別のイベントを検知する傾向にある。この場合、因果律情報のサイズがオンデマンド展開によって大きくなる。そのため、管理サーバ３００００は、イベントに有効期間を与え、有効期間を過ぎたイベントは解析対象から外し、そして有効期間を過ぎたイベントに関係する因果律を因果律情報から削除してもよい。このようにすることで因果律情報のサイズを少なくすることが出来る。
図２７の例では、コンポーネント１（種別ａ）で発生するイベントＡ１（種別Ａ）の原因がコンポーネント２（種別ｂ）で発生するイベントＢ２（種別Ｂ）であるイベントコリレーション１が作成済みの状況で、コンポーネント３（種別ａ）でイベントＡ３（種別Ａ）を実際に検知した場合の概要を示している。なお、イベントコリレーション１は過去にイベントＡ１を検知したときを契機に、トポロジ１とイベント伝播モデル１に基づいて過去にオンデマンド作成したものである。この状況では、コンポーネント３（種別ａ）で発生するイベントＡ３（種別Ａ）の原因がコンポーネント２（種別ｂ）で発生するイベントＢ２（種別Ｂ）であるイベントコリレーション２を、トポロジ２とイベント伝播モデル１に基づいてオンデマンドに作成する。
なお、上記因果律の削除契機としては例えば以下があるが、他の契機であってもよい。
＊ 管理プログラムが管理対象装置の構成変更を検知したとき。
＊ 所定のインターバルに基づいた繰り返し処理として、削除を実行。
なお、オンデマンド展開はイベント解析時に因果律を作成するため、解析時の負荷が増大する。そのため、特定のイベント伝播モデル、又は特定の管理オブジェクトについては事前に因果律を展開してもよい。なお、事前に因果律を展開する場合を事前展開と呼ぶ。事前の例としては例えば、（１）管理プログラムが起動し、イベントを検知する前、又は（２）管理プログラムが管理対象装置の構成変更を検知し、その後最初のイベントを検知する前、が考えられる。ただし、事前とはイベント検知より前であれば他のタイミングでもよい。事前展開対象とするイベント伝播モデル又は管理オブジェクトの特定方法としては、（１）これらの識別子を事前にユーザに設定してもらう方法、（２）管理オブジェクトの種別を条件として特定する、又は（３）イベント伝播モデルに含まれる管理オブジェクトの種別又はイベント種別を条件として特定する、といった例が考えられるが他の方法でもよい。
因果律作成済み判断又は因果律展開の際、イベント伝播モデルの個々をアクセスしてイベントとの関係性を判断しているとモデル数に比例して時間がかかる。そのため、管理サーバ３００００は、管理オブジェクトの種別とそこで発生するイベントの種別のペアから、当該ペアを原因種別ペア又は観測種別ペアに含むイベント伝播モデルのＩＤを特定可能なデータ構造を事前に作成し、判断に参照してもよい。
以上が本実施例の概要である。以後の記載では以下の場合を例示するが、本発明はこれに限定されないことはいうまでもない。
＊ ネットワークサービス：ｉＳＣＳＩプロトコルによるストレージアクセス。クライアント装置がホストコンピュータで、サーバ装置がストレージ装置。
＊ 因果律情報：因果律行列。
＊ 管理対象装置： ホストコンピュータ、ＩＰスイッチ、ストレージ装置。
＊ 管理オブジェクト：コンポーネント。
＊ コンポーネント：ｉＳＣＳＩターゲット、ボリューム、ＲＡＩＤグループ、ディスク、ホストコンピュータのドライブ名。
＊ 因果律の削除契機： 構成変更の検知。
図１から図５は計算機システムの構成および計算機システムに接続される装置の構成を示し、図６から図１５は各装置に具備される管理情報を示す。
図１は、計算機システムの物理的構成を示す図である。当該計算機システムは、ストレージ装置２００００と、ホストコンピュータ１００００と、管理サーバ３００００と、ＷＥＢブラウザ起動サーバ３５０００と、ＩＰスイッチ４００００と、を有し、それらが、ネットワーク４５０００によって接続される構成となっている。
ホストコンピュータ１００００乃至１００１０は、例えば、それらに接続された、図示しないクライアントコンピュータからファイルのＩ／Ｏ要求を受信し、それに基づいてストレージ装置２００００乃至２００１０へのアクセスを実現する。また、管理サーバ（管理計算機）３００００は、当該計算機システム全体の運用を管理するものである。
ＷＥＢブラウザ起動サーバ３５０００は、ネットワーク４５０００を介して、管理サーバ３００００のＧＵＩ表示処理モジュール３２３００と通信し、ＷＥＢブラウザ上に各種情報を表示する計算機である。ユーザはＷＥＢブラウザ起動サーバ上のＷＥＢブラウザに表示された情報を参照することで、計算機システム内の装置を管理する。ただし、管理サーバ３００００と、ＷＥＢブラウザ起動サーバ３５０００は１台のサーバから構成されていてもよい。
また、図２９に示すように計算機システム上に管理サーバ３００００が複数台存在し、ストレージ装置２００００、ホストコンピュータ１００００、管理サーバ３００００といった管理対象装置を分担して管理してもよい。
図２は、実施例によるホストコンピュータ１００００の詳細な内部構成例を示す図である。ホストコンピュータ１００００は、ネットワーク４５０００に接続するためのポート１１０００と、プロセッサ１２０００と、メモリ１３０００（ディスク装置を含んでも良い）と、を有し、これらは内部バス等の回路を介して相互に接続される構成となっている。
メモリ１３０００には、業務アプリケーション１３１００と、オペレーティングシステム１３２００と、論理ボリューム管理表１３３００と、が格納される。
業務アプリケーション１３１００は、オペレーティングシステム１３２００から提供された記憶領域を使用し、当該記憶領域に対しデータ入出力（以下、Ｉ／Ｏと表記）を行う。
オペレーティングシステム１３２００は、ネットワーク４５０００を介してホストコンピュータ１００００に接続されたストレージ装置２００００乃至２００１０上の論理ボリュームを記憶領域として業務アプリケーション１３１００に認識させるための処理を実行する。
ポート１１０００は、ストレージ装置２００００とｉＳＣＳＩにより通信を行うためのＩ／Ｏポートと、管理サーバ３００００がホストコンピュータ内の管理情報を取得するための管理ポートを含む単一のポートとして図２で表現されているが、ｉＳＣＳＩにより通信を行うためのＩ／Ｏポートと管理ポートに分かれていてもよい。
図３は、実施例によるストレージ装置２００００の詳細な内部構成例を示す図である。ストレージ装置２００１０も同様の構成を有している。
ストレージ装置２００００は、ネットワーク４５０００を介してホストコンピュータ１００００に接続するためのＩ／Ｏポート２１０００及び２１０１０と、ネットワーク４５０００を介して管理サーバ３００００に接続するための管理ポート２１１００と、各種管理情報を格納するための管理メモリ２３０００と、データを格納するためのＲＡＩＤグループ２４０００乃至２４０１０と、データや管理メモリ内の管理情報を制御するためのコントローラ２５０００及び２５０１０と、を有し、これらが内部バス等の回路を介して相互に接続される構成となっている。なお、ＲＡＩＤグループ２４０００乃至２４０１０の接続とは、より正確にはＲＡＩＤグループ２４０００乃至２４０１０を構成する記憶デバイスが他の構成物と接続されていることを指す。
管理メモリ２３０００には、ストレージ装置の管理プログラム２３１００と、ボリューム管理表２３２００と、ｉＳＣＳＩターゲット管理表２３３００と、Ｉ／Ｏポート管理表２３４００と、ＲＡＩＤグループ管理表２３５００と、ディスク管理表２３６００と、が格納される。管理プログラムは管理ポート２１１００を経由して管理サーバ３００００と通信し、管理サーバに対しストレージ装置２００００の構成情報を提供する。
ＲＡＩＤグループ２４０００乃至２４０１０は、それぞれ、１つまたは複数の磁気ディスク２４２００、２４２１０、２４２２０、及び２４２３０によって構成されている。複数の磁気ディスクによって構成されている場合、それらの磁気ディスクはＲＡＩＤ構成を組んでいてもよい。また、ＲＡＩＤグループ２４０００乃至２４０１０は、論理的に複数のボリューム２４１００乃至２４１１０に分割されている。
なお、論理ボリューム２４１００及び２４１１０は、１つ以上の磁気ディスクの記憶領域を用いて構成されるのであれば、ＲＡＩＤ構成を編成しなくてもよい。さらに、論理ボリュームに対応する記憶領域を提供するのであれば、磁気ディスクの代わりとしてフラッシュメモリなど他の記憶媒体を用いた記憶デバイスでも良いものとする。
コントローラ２５０００及び２５０１０は、その内部に、ストレージ装置２００００内の制御を行うプロセッサや、ホストコンピュータ１００００との間でやりとりするデータを一時的に記憶するキャッシュメモリを持っている。そして、それぞれのコントローラは、Ｉ／ＯポートとＲＡＩＤグループの間に介在し、両者の間でデータの受け渡しを行う。
なお、ストレージ装置２００００は、何れかのホストコンピュータに対して論理ボリュームを提供し、アクセス要求（Ｉ／Ｏ要求を指す）を受信し、受信したアクセス要求に応じて記憶デバイスへの読み書きを行うストレージコントローラと、記憶領域を提供する前述の記憶デバイスを含めば、図３及び上記説明以外の構成でもよく、例えば、ストレージコントローラと記憶領域を提供する記憶デバイスが別な筐体に格納されていてもよい。即ち、図３の例では管理メモリ２３０００と、コントローラ２５０００及び２５１１０と、がストレージコントローラであってもよい。また、本明細書ではストレージコントローラと記憶デバイスが同じ筐体に存在する場合または別な筐体を含む表現として、ストレージ装置をストレージシステムと呼び変えても良い。
図４及び図１７は、実施例による管理サーバ３００００の詳細な内部構成例を示す図である。管理サーバ３００００は、ネットワーク４５０００に接続するための管理ポート３１０００と、プロセッサ３１１００と、記憶資源３３０００と、後述する処理結果を出力するためのディスプレイ装置等の出力デバイス３１２００と、ストレージ管理者が指示を入力するためのキーボード等の入力デバイス３１３００とを有し、これらが内部バス等の回路を介して相互に接続される構成となっている。なお、記憶資源３３０００は、半導体メモリ又は記憶デバイス、又はこれらを混在させた記憶資源である。
記憶資源３３０００には管理プログラム３２０００が格納される。図１７のように管理プログラム３２０００は、プログラム制御モジュール３２１００と、装置情報取得モジュール３２２００と、ＧＵＩ表示処理モジュール３２３００と、イベント解析処理モジュール３２４００と、イベント伝播モデル展開モジュール３２５００と、を含む。なお、各モジュールは、メモリ３２０００のプログラムモジュールとして提供されているが、ハードウェアモジュールとして提供されるものであっても良い。また、管理プログラム３２０００は各モジュールの処理を実現できるのであれば、モジュールによって構成されなくてもよい。言い方を変えれば、以下の説明における各モジュールについての説明は管理プログラム３２０００に関する説明と置き換えてもよいということである。
記憶資源３３０００はさらに、イベント管理表３３１００と、イベント伝播モデルリポジトリ３３２００と、因果律行列３３３００と、トポロジ生成方式リポジトリ３３４００と、構成ＤＢ３３５００と、展開対象イベント伝播モデル管理表３３６００と、展開済イベント管理表３３７００と、展開済起点コンポーネント管理表３３８００と、イベント伝播モデル管理表３３９００と、が格納されている。構成ＤＢ３３５００には構成情報が格納される。
構成情報の例としては、装置情報取得モジュール３２２００が管理対象の各ホストコンピュータから収集してきた論理ボリューム管理表１３３００の各項目と、管理対象の各ストレージから収集してきたボリューム管理表２３２００の各項目と、ｉＳＣＳＩターゲット管理表２３３００各項目と、Ｉ／Ｏポート管理表２３４００各項目と、ＲＡＩＤグループ管理表２３５００各項目と、ディスク管理表２３６００各項目である。なお、構成ＤＢには管理対象装置の全ての表、または表中の全ての項目を格納しなくてもよい。また、構成ＤＢが格納する各項目のデータ表現形式・データ構造は、管理対象装置と同じでなくてもよい。また、管理プログラム３２０００が管理対象装置からこれら各項目を受信する場合、管理対象装置のデータ構造やデータ表現形式で受信してもよい。
装置情報取得モジュール３２２００は、管理下の管理対象装置に定期的又は繰り返しアクセスし、管理対象装置内の各コンポーネントの状態を取得する。イベント解析処理モジュール３２４００は、因果律行列３３３００を参照し、装置情報取得モジュール３２２００が取得した管理対象装置の異常状態の根本原因を解析する。
ＧＵＩ表示処理モジュール３２３００は、入力デバイス３１３００を介した管理者からの要求に応じ、取得した構成管理情報を、出力デバイス３１２００を介して表示する。なお、入力デバイスと出力デバイスは別々なデバイスでもよく、一つ以上のまとまったデバイスでもよい。
なお、管理サーバ（管理計算機）は、例えば、入出力デバイスとして、ディスプレイとキーボードとポインタデバイス等を有しているが、これ以外の装置であってもよい。また、入出力デバイスの代替としてシリアルインターフェースやイーサーネットインターフェースを用い、当該インターフェースにディスプレイ又はキーボード又はポインタデバイスを有する表示用計算機（例えば、ＷＥＢブラウザ起動サーバ３５０００）を接続し、表示用情報を表示用計算機に送信したり、入力用情報を表示用計算機から受信することで、表示用計算機で表示を行ったり、入力を受け付けることで入出力デバイスでの入力及び表示を代替してもよい。
本明細書では、計算機システム（情報処理システム）を管理し、表示用情報を表示する一つ以上の計算機の集合を管理システムと呼ぶことがある。管理サーバが表示用情報を表示する場合は、管理サーバが管理システムであり、また、管理サーバと表示用計算機（例えば図１のＷＥＢブラウザ起動サーバ３５０００）の組み合わせも管理システムである。また、管理処理の高速化や高信頼化のために複数の計算機で管理サーバと同等の処理を実現してもよく、この場合は当該複数の計算機（表示を表示用計算機が行う場合は表示用計算機も含め）が管理システムである。
図５にＩＰスイッチ４００００の詳細な構成を示す。ＩＰスイッチ４００００は、プロセッサ４１０００と、各種管理情報を保持するためのメモリ４２０００と、ネットワーク４５０００、４５０１０を介してホストコンピュータ１００００に接続するためのＩ／Ｏポート４３０００、４３０１０と、ネットワーク４５０００に接続するための管理ポート４４０００を有し、これらは内部バス等の回路を介して相互に接続される。
なお、メモリ４２０００は、半導体メモリの代わりとしてその一部もしくは全部が磁気ディスクなど他の記憶媒体であっても良いものとする。
図６Ａ、Ｂ及びＣは、ホストコンピュータ１００００の具備する論理ボリューム管理表１３３００の構成例を示す図である。
論理ボリューム管理表１３３００は、ホストコンピュータ内で各論理ボリュームの識別子となるドライブ名を登録するフィールド１３３１０と、論理ボリュームの実体が存在するストレージ装置との通信の際に用いるホストコンピュータ上のＩ／Ｏポート１１０００の識別子となるｉＳＣＳＩイニシエータ名を登録するフィールド１３３２０と、論理ボリュームの実体が存在するストレージ装置との通信の際に用いるストレージ装置上のＩ／Ｏポート２１０００の識別子となる接続先ｉＳＣＳＩターゲットを登録するフィールド１３３３０と、ストレージ装置において論理ボリュームの識別子となるＬＵＮ ＩＤを登録するフィールド１３３４０と、を構成項目として含んでいる。
図６Ａには、ホストコンピュータの具備する論理ボリューム管理表の具体的な値の一例を示している。つまり、ホストコンピュータ上で（Ｅ：）というドライブ名で示される論理ボリュームは、ｃｏｍ．ｈｉｔａｃｈｉ．ｓｖ１というｉＳＣＳＩイニシエータ名で示されるホストコンピュータ上のポートと、ｃｏｍ．ｈｉｔａｃｈｉ．ｓｔｏ１というｉＳＣＳＩターゲット名で示されるストレージ装置上のポートを介してストレージ装置と接続しており、０というＬＵＮ ＩＤをストレージ装置上で持つ。
図７は、ストレージ装置２００００の具備するボリューム管理表２３２００を示す図である。
ボリューム管理表２３２００は、ストレージ装置内で各ボリュームの識別子となるボリュームＩＤを登録するフィールド２３２１０と、各ボリュームの容量を登録するフィールド２３２２０と、各ボリュームが所属するＲＡＩＤグループの識別子となるＲＡＩＤグループＩＤを登録するフィールド２３２３０と、各ボリュームが所属するｉＳＣＳＩターゲットの識別子となるターゲットＩＤを登録するフィールド２３２４０と、各ボリュームのｉＳＣＳＩターゲット内での識別子となるＬＵＮ ＩＤを登録するフィールド２３２５０と、を構成項目として含んでいる。
図７には、ストレージ装置の具備するボリューム管理表の具体的な値の一例を示している。つまり、ストレージ装置上のボリュームＶＯＬ１は２０ＧＢの記憶領域を持ち、ＲＧ１というＲＡＩＤグループＩＤで示されるＲＡＩＤグループに属し、ＴＧ１というｉＳＣＳＩターゲットＩＤで示されるｉＳＣＳＩターゲットに属し、０というＬＵＮ ＩＤを持つ。
図８Ａ及び図８Ｂは、ストレージ装置２００００の具備するｉＳＣＳＩターゲット管理表２３３００を示す図である。
ｉＳＣＳＩターゲット管理表２３３００は、ストレージ装置内でｉＳＣＳＩターゲットの識別子となるターゲットＩＤを登録するフィールド２３３１０と、各ｉＳＣＳＩターゲットが持つｉＳＣＳＩターゲット名を登録するフィールド２３３２０と、各ｉＳＣＳＩターゲットに属するボリュームに対しアクセスが許可されたホストコンピュータ上のポートの識別子となるｉＳＣＳＩイニシエータ名を登録するフィールド２３３３０と、を構成項目として含んでいる。
図８Ａには、ストレージ装置の具備するｉＳＣＳＩターゲット管理表の具体的な値の一例を示している。つまり、ストレージ装置上のｉＳＣＳＩターゲットＨＧ１は、ｃｏｍ．ｈｉｔａｃｈｉ．ｓｔｏ１でというｉＳＣＳＩターゲット名を持ち、ｉＳＣＳＩイニシエータ名がｃｏｍ．ｈｉｔａｃｈｉ．ｓｖ１もしくはｃｏｍ．ｈｉｔａｃｈｉ．ｓｖ１１であるホストコンピュータ上のポートからのアクセスを許可している。
図９は、ストレージ装置２００００の具備するＩ／Ｏポート管理表２３４００の構成を示す図である。
Ｉ／Ｏポート管理表２３４００は、ストレージ装置内で各ポートの識別子となるポートＩＤを登録するフィールド２３４１０と、ポートのネットワーク４５０００上での識別子となるＭＡＣアドレスを登録するためのフィールド２３４２０と、を構成項目として含んでいる。
図９には、ストレージ装置の具備するＩ／Ｏポート管理表の具体的な値の一例を示している。つまり、ストレージ装置上のポートＰＯＲＴ１は、ＴＧ１，ＴＧ２というｉＳＣＳＩターゲットＩＤで示されるｉＳＣＳＩターゲットによって使用されている。
図１０は、ストレージ装置２００００の具備するＲＡＩＤグループ管理表２３５００の構成を示す図である。
ＲＡＩＤグループ管理表２３５００は、ストレージ装置内で各ＲＡＩＤグループの識別子となるＲＡＩＤグループＩＤを登録するフィールド２３５１０と、ＲＡＩＤグループのＲＡＩＤレベルを登録するフィールド２３５２０と、各ＲＡＩＤグループの容量を登録するフィールド２３５４０から構成されている。
図１０には、ストレージ装置の具備するＲＡＩＤグループ管理表の具体的な値の一例を示している。つまり、ストレージ装置上のＲＡＩＤグループＲＧ１は、ＲＡＩＤレベルがＲＡＩＤ１で容量は１００ＧＢである。
図１１は、ストレージ装置２００００の具備するディスク管理表２３６００の構成を示す図である。
ディスク管理表２３６００は、ストレージ装置内で各ディスクの識別子となるディスクＩＤを登録するフィールド２３６１０と、ディスクのディスク種別を登録するフィールド２３６２０と、から構成されている。
図１１には、ストレージ装置の具備するディスク管理表の具体的な値の一例を示している。つまり、ストレージ装置上のディスクＤＩＳＫ１は、ディスク種別がＦＣディスクである。
図１２は、管理サーバ３００００が有するイベント管理表３３１００の構成例を示す図である。
イベント管理表３３１００は、イベント自身の識別子となるイベントＩＤを登録するフィールド３３１１０と、取得した構成情報の変化といったイベントの発生した装置の識別子となる装置ＩＤを登録するフィールド３３１２０と、イベントの発生した装置内の部位の識別子を登録するフィールド３３１３０と、発生したイベントの種別を登録するフィールド３３１４０と、イベントが後述するイベント伝播モデル展開モジュール３２５００によって処理済みかどうかを登録するフィールド３３１５０と、イベントが発生した日時を登録するフィールド３３１６０と、イベントが後述するイベント伝播モデル展開モジュール３２５００による処理の対象（又は管理プログラムによる原因解析対象）となる期間を登録するフィールド３３１７０と、を構成項目として含んでいる。
例えば、図１２の第１行目（１つ目のエントリ）からは、管理サーバ３００００が、ホストコンピュータＨＯＳＴ１の、（Ｅ：）で示される論理ボリュームにおける状態異常を検知し、そのイベントＩＤはＥＶ１であることが分かる。
図１３Ａ及び図１３Ｂは、管理サーバ３００００が有するイベント伝播モデルリポジトリ３３２００内のイベント伝播モデルの構成例を示す図である。障害解析において根本原因を特定するためのイベント伝播モデルは、ある障害の結果発生することが予想されるイベントの組み合わせと、その根本原因を"ＩＦ−ＴＨＥＮ"形式で記載するものとなっている。なお、イベント伝播モデルは図１３Ａ及び図１３Ｂに挙げられたものに限られず、さらに多くのルールがあっても構わない。当然ながら、イベント伝播モデルリポジトリ３３２００には複数のイベント伝播モデルを含んでも良い。
イベント伝播モデルは、イベント伝播モデルの識別子となるモデルＩＤを登録するフィールド３３２１０と、"ＩＦ−ＴＨＥＮ"形式で記載したイベント伝播モデルのＩＦ部に相当する観測イベント種別を登録するフィールド３３２２０と、"ＩＦ−ＴＨＥＮ"形式で記載したイベント伝播モデルのＴＨＥＮ部に相当する原因イベント種別を登録するためのフィールド３３２３０と、を構成項目として含んでいる。結論部のステータスが正常になれば、条件部の問題も解決しているという関係にあるものである。
図１３Ａには、管理サーバが有するイベント伝播モデルの具体的な値の一例を示している。つまり、モデルＩＤがＲｕｌｅ１で示されるイベント伝播モデルにおいては、観測イベント種別としてホストコンピュータ上の論理ボリュームの状態異常と、ストレージ装置上のボリュームの状態異常を検知したとき、ストレージ装置のボリュームの故障が原因と結論付ける。
なお、図１３Ｂに示すように、観測イベントとして「ストレージ装置のボリュームの故障」という、他のイベント伝播モデルにおいて結論として位置づけられているイベント種別を持っていてもよい。
図１４Ａ乃至Ｅは、管理サーバ３００００の具備する因果律行列３３３００の構成を示す図である。
因果律行列３３３００は、以下の情報を含む。
＊ 展開の際使用したイベント伝播モデルリポジトリ３３２００の識別子となるイベント伝播モデルＩＤを登録するフィールド３３３１０。
＊ 管理サーバの装置情報取得モジュール３２２００が検知するイベントを特定する情報（図中では管理オブジェクトの識別子（つまり装置ＩＤとコンポーネントＩＤ）とイベントの種別）を登録するフィールド３３３２０。
＊ 前記イベントを検知した際、イベント解析処理モジュール３２４００が障害の原因として結論付ける原因イベントを登録するための情報（図中では管理オブジェクトの識別子（つまり装置ＩＤとコンポーネントＩＤ）とイベントの種別）を登録するフィールド３３３３０。
＊ イベント伝播モデルリポジトリ３３２００に"ＩＦ−ＴＨＥＮ"形式で記載したイベント伝播モデルに基づき、どのイベントを受信した際何を根本原因と位置づけるかという対応関係（つまり因果律）を登録するためのフィールド３３３４０。
図１４Ａには、管理サーバの具備する因果律行列の具体的な値の一例を示している。つまり、ストレージ装置ＳＹＳ１のボリューム（ＶＯＬ１）の状態異常と、ホストＨＯＳＴ１の論理ボリューム（Ｅ：）の状態異常というイベントを装置情報取得モジュールが検知したとき、イベント解析処理モジュールは、ストレージ装置ＳＹＳ１のボリューム（ＶＯＬ１）の故障が根本原因であると結論付ける。
なお、因果律行列は後述するように因果律の追加、削除をより効率的に行うため、動的に行列のサイズを変更できるデータ構造であってもよい。例えば、所定の行数又は列数毎にサブ行列化して、それらをポインタやインデックスで関係付けて仮想的な行列を見せる等が考えられる。また、因果律行列は記憶資源の連続領域を用いて行列構造を生成してもよい。
図１５Ａ及び図１５Ｂは、管理サーバ３００００が有するトポロジ生成方式リポジトリ３３４００内のトポロジ生成方式情報（省略してトポロジ生成方式と呼ぶことがある）の構成例を示す図である。
トポロジ生成方式は、前記管理サーバが管理対象装置から取得した構成情報に基づき、監視対象となる複数の装置間での接続関係（トポロジ）を生成するための手段を定義した情報である。トポロジ生成方式は、トポロジの識別子となるトポロジＩＤを登録するフィールド３３４１０と、トポロジを生成する際の起点となる管理対象装置内のコンポーネント種別を登録するフィールド３３４２０と、トポロジを生成する際の終点となるコンポーネント種別を登録するフィールド３３４３０と、前記起点コンポーネント−終点コンポーネント間のトポロジ生成の際に経由する必要のあるコンポーネント種別を登録するフィールド３３４４０と、前記起点コンポーネント−終点コンポーネント間のトポロジ生成方法を登録するフィールド３３４５０と、を構成項目として含んでいる。
図１５Ａ及び図１５Ｂには、管理サーバの具備するトポロジ生成方式の具体的な値の一例を示している。つまり、ストレージ装置のボリュームを起点とし、ホストコンピュータの論理ボリュームを終点とするトポロジは、論理ボリュームのｉＳＣＳＩイニシエータ名が、ｉＳＣＳＩターゲットの接続許可ｉＳＣＳＩイニシエータと等しく、かつボリューム内のｉＳＣＳＩターゲットＩＤが、ｉＳＣＳＩターゲット内のＩＤと等しい組み合わせを検索することにより取得可能である。
図１６に、管理サーバ３００００の装置情報取得モジュール３２２００が実施する装置情報取得処理のフローチャートを示す。
プログラム制御モジュール３２１００は、プログラムの起動時、もしくは前回の装置情報取得処理から一定時間経過するたびに、装置情報取得モジュール３２２００に対し、装置情報取得処理を実行するよう指示する。なお、当該実行指示を繰り返し出す場合は厳密に一定期間毎である必要は無く、繰り返しさえしていればよい。また。装置から取得する情報には装置の構成情報、状態情報、性能情報が含まれるが、これらの情報をそれぞれ異なるタイミングで取得してもよい。
装置情報取得モジュール３２２００は、一つ以上の管理対象装置の各々に対し、以下の一連の処理を繰り返す（ステップ６１０１０）。
装置情報取得モジュール３２２００は、管理対象装置に対して装置の構成情報、状態情報、又は性能情報を送信するよう指示する（ステップ６１０２０）。
装置からの応答があれば（ステップ６１０３０）、装置情報取得モジュール３２２００は、取得した構成情報を構成ＤＢ３３５００に格納された過去の構成情報と比較する（ステップ６１０４０）。なお、装置から指示に対する応答がなかった場合、装置情報取得処理を終了する。
取得した構成管理情報を構成ＤＢに格納された過去の構成情報と比較した結果、異なる項目が見つかった場合（ステップ６１０５０）、装置情報取得モジュール３２２００は、差分のあった項目をイベント化し、イベント管理表３３１００を更新する（ステップ６１０６０）。
次に、装置情報取得モジュール３２２００は、状態情報、性能情報を取得した際に検知した状態異常および性能異常をイベント化し、イベント管理表３３１００を更新する（ステップ６１０７０）。その上で、装置情報取得モジュール３２２００は、取得した構成情報を構成ＤＢ３３５００に格納する（ステップ６１０８０）。
以上が、装置情報取得モジュール３２２００が実施する構成管理情報取得処理である。なお、因果律の展開又は削除を行うモジュールへの構成変更の通知（又はモジュールの実行開始）は、必ずしもイベントを通じて行う必要はない。また、状態情報に基づいたイベント化とは、コンポーネントの状態が正常以外の状態に変化したときに変化先の状態に対応したイベント（情報）を生成することが一例である。また、性能情報に基づいたイベント化とは、所定の評価基準（閾値等）によって正常ではない性能値となった場合にイベント（情報）を生成することが一例である。
次に、管理サーバ３００００が具備する展開対象イベント伝播モデル管理表３３６００を図１８に、管理サーバ３００００が実行する処理方式を図１９、図２０及び図２１に示す。
図１８は、管理サーバ３００００の具備する展開対象イベント伝播モデル管理表３３６００の構成例を示す図である。
展開対象イベント伝播モデル管理表３３６００は、取得した構成変更イベントの発生した装置の種別を登録するフィールド３３６１０と、前記イベントの発生した装置内のコンポーネントの種別を登録するフィールド３３６２０と、前記イベントの種別を登録するフィールド３３６３０と、イベントが後述するイベント解析処理モジュール３２５００によって処理される際、どのイベント伝播モデルが展開対象となるかを登録するフィールド３３６４０と、を構成項目として含んでいる。
図１８には、管理サーバの具備する展開対象イベント伝播モデル管理表の具体的な値の一例を示している。つまり、ホストコンピュータにおける論理ボリュームの状態異常というイベントが発生した場合、Ｒｕｌｅ１を再展開する必要がある。
図１９に、管理サーバ３００００のイベント解析処理モジュール３２４００が実施する、イベント確認処理のフローチャートを示す。なお、管理サーバ３００００の装置情報取得モジュール３２２００は、図１６に示す装置情報取得処理を管理対象装置に対して実施した後、イベント解析処理モジュール３２４００に対し、イベント確認処理を行なうよう指示する。
イベント解析処理モジュール３２４００は、イベント管理表３３１００を参照し、イベント管理表に定義された構成変更イベントに対し、ループ内の処理を繰り返す（ステップ６４０１０）。イベント解析処理モジュール３２４００は、イベント管理表に定義されたイベントの処理済みフラグがＮｏであるかどうかを確認する（ステップ６４０２０）。イベントの処理済みフラグがＮｏである、すなわち未処理イベントである場合、ステップ６４０３０乃至６４０６０の処理を行う。
イベント解析処理モジュール３２４００は、イベント管理表に定義されたイベントの処理済みフラグをＹｅｓに変更する（ステップ６４０３０）。次にイベント解析処理モジュール３２４００は、イベント管理表に定義されたイベントが構成変更イベントかどうかを確認する（ステップ６４０４０）。イベント管理表に定義されたイベントが構成変更イベントである場合、図２１に示すイベント伝播モデル再展開処理を実行する。
次にイベント解析処理モジュール３２４００は、イベント管理表に定義されたイベントが状態異常、または性能異常イベント（構成変更イベント以外）かどうかを確認する（ステップ６４０５０）。イベント管理表に定義されたイベントが状態異常、もしくは性能異常イベント（構成変更イベント以外）である場合、イベント伝播モデル展開モジュール３２５００に対し、当該イベントを指定して図２０に示すイベント伝播モデルオンデマンド展開処理を実行するよう指示する。
イベント伝播モデルオンデマンド展開処理が終了すると、イベント解析処理モジュール３２４００は、イベント管理表のイベント有効期間を設定する（ステップ６４０６０）。イベント有効期間は、イベントの発生した時刻に、予め定められた一定の時間を加えて算出される。ただしイベント有効期間は他の式で算出されてもよい。
以上が、イベント解析処理モジュール３２４００が実施するイベント確認処理である。
なお、イベント管理表に複数の状態異常、もしくは性能異常イベントが存在する場合、同時に複数のイベントについてイベント伝播モデルオンデマンド展開処理を実行するようイベント伝播モデル展開モジュールに指示してもよい。
図２０に、管理サーバ３００００のイベント伝播モデル展開モジュール３２５００が実施するイベント伝播モデルオンデマンド展開処理のフローチャートを示す。
イベント伝播モデル展開モジュール３２５００は、展開対象イベント伝播モデル管理表３３６００を参照し、処理起動時に指定されたイベント（つまり、未処理であったイベントの一つ）に対応したイベント伝播モデルの一覧を取得する（ステップ６５０１０）。
次に、イベント伝播モデル展開モジュール３２５００は、前記取得したイベント伝播モデルに対し、ステップ６５０３０乃至６５０９０の処理を繰り返す（ステップ６５０２０）。なお、展開対象イベント伝播モデル管理表３３６００にイベントが登録されていない場合は、以下の処理を行わずにイベント伝播モデルオンデマンド展開処理を終了する。
イベント伝播モデル展開モジュール３２５００は、トポロジ生成方式リポジトリ３３４００を参照し、イベント伝播モデルに対応したトポロジ生成方式をトポロジ生成方式リポジトリ３３４００より取得する（ステップ６５０３０）。該当するトポロジ生成方式がトポロジ生成方式リポジトリにない場合は、以下の処理を行わない。
該当するトポロジ生成方式がトポロジ生成方式リポジトリにあれば（ステップ６５０４０）、イベント伝播モデル展開モジュール３２５００は、取得したトポロジ生成方式を元に構成ＤＢ３３５００からトポロジを取得する（ステップ６５０５０）。イベント伝播モデル展開モジュール３２５００は、取得したトポロジに基づいてイベント伝播モデルを展開し（ステップ６５０６０）、展開結果が因果律行列３３３００に既にあるかどうかを確認する（ステップ６５０７０）。展開結果が因果律行列３３３００に既にある場合、以下の処理は行わない。
展開結果が因果律行列に存在しない場合、イベント伝播モデル展開モジュール３２５００は、因果律行列３３３００の列として追加する（ステップ６５０８０）。次に、イベント伝播モデル展開モジュール３２５００は、展開結果の結論イベントと、処理起動時に指定されたイベント以外の条件イベントについて、図２０に示すイベント伝播モデルオンデマンド展開処理を実施する（ステップ６５０９０）。
以上が、イベント伝播モデル展開モジュール３２５００が実施するイベント伝播モデルオンデマンド展開処理である。なお、構成ＤＢ以外の情報にトポロジを別途格納している場合はそのような情報を参照して上記処理を行っても良い。
図２１に、管理サーバ３００００のイベント伝播モデル展開モジュール３２５００が実施するイベント伝播モデル再展開処理のフローチャートを示す。
イベント伝播モデル展開モジュール３２５００は、因果律行列３３３００を全て削除する（ステップ６６０１０）。次に、イベント種別が構成変更であるイベントについて、イベント処理済みフラグをＹｅｓに変更する（ステップ６６０２０）。
次に、イベント伝播モデル展開モジュール３２５００は、イベント管理表３３１００を参照し、イベント管理表の未処理イベントに対し、ループ内の処理を繰り返す（ステップ６６０３０）。
イベント伝播モデル展開モジュール３２５００は、該当するイベントの種別は状態異常、もしくは性能異常（つまり構成変更以外）かどうかを確認する（ステップ６６０４０）。次に、該当するイベントのイベント有効期間が満了しているかどうかを確認する（ステップ６６０５０）。満了していない場合、当該イベントを指定してイベント伝播モデルオンデマンド展開処理６５０００を実施する（ステップ６６０６０）。
以上が、イベント伝播モデル展開モジュール３２５００が実施するイベント伝播モデル再展開処理である。なお、本フローでは一度全ての因果律を削除し、有効期間内のイベントについて再度因果律を作成しているが、ステップ６６０１０で構成変更に関係した因果律だけ削除してもよい。
以下に、図６乃至１３の情報の内容に対応する計算機システムを例として、実施例１の処理がどのように因果律行列を作成するかを示す。なお、処理開始当初のｉＳＣＳＩターゲット管理表は図８Ａに示すとおりであるものとする。
プログラム制御モジュールは、管理者からの指示もしくはタイマーによるスケジュール設定によって応じて、装置情報取得モジュールに対し、装置情報取得処理を実行するよう指示する。装置情報取得モジュールは、管理対象装置に順にログインし、装置に対し装置の構成情報、状態情報、性能情報を送信するよう指示する。
上記の処理が終了した後、装置情報取得モジュールは、取得した状態情報、性能情報を参照し、イベント管理表を更新する。ここでは、図１２のイベント管理表の１行目に示す通り、ホストコンピュータＨＯＳＴ１の、（Ｅ：）で示される論理ボリュームにおける状態異常を検知したケースを想定する。
イベント解析処理モジュールは、上記イベントが未処理イベントであることを確認すると、イベント伝播モデル展開モジュールに対し、展開対象イベント伝播モデル管理表を参照して当該イベントを指定してイベント伝播モデルオンデマンド展開処理を実行するよう指示する。
イベント伝播モデル展開モジュールは、イベントに対応したイベント伝播モデルの一覧を取得する。例えば、図１８に示す展開対象イベント伝播モデル管理表を参照すると、ホストコンピュータにおける論理ボリュームの状態異常というイベントが発生した場合、Ｒｕｌｅ１を展開する必要があることが分かる。
図１３Ａに示すイベント伝播モデルＲｕｌｅ１は、観測イベントとして"ホストコンピュータの論理ボリュームの状態異常"と、"ストレージ装置のボリュームの状態異常"が定義されている。図１５Ａに示すトポロジ生成方式を参照すると、ストレージ装置のＩ／Ｏポートを起点とし、ホストコンピュータの論理ボリュームを終点とするトポロジ生成方式ＴＰ１が定義されている。そこで、このトポロジ生成方式を利用してトポロジを取得する。
図７の示すボリューム管理表（に相当する管理サーバが格納した構成ＤＢ内の項目）を参照し、ストレージ装置ＳＹＳ１のボリュームＶＯＬ１に着目すると、そのターゲットＩＤはＴＧ１となっている。次に、図８Ａに示すｉＳＣＳＩターゲット管理表（に相当する管理サーバが格納した構成ＤＢ内の項目）を参照し、ｉＳＣＳＩターゲットＩＤがＴＧ１となっているものを探し、その接続許可ｉＳＣＳＩイニシエータ名を見ると"ｃｏｍ．ｈｉｔａｃｈｉ．ｓｖ１"もしくは"ｃｏｍ．ｈｉｔａｃｈｉ．ｓｖ１１"となっている。
次に、図６Ａに示すＩ／Ｏポート管理表（に相当する管理サーバが格納した構成ＤＢ内の項目）を参照し、ｉＳＣＳＩイニシエータ名が"ｃｏｍ．ｈｉｔａｃｈｉ．ｓｖ１"もしくは"ｃｏｍ．ｈｉｔａｃｈｉ．ｓｖ１１"となっている論理ボリュームを検索する。その結果検索されたホストコンピュータＨＯＳＴ１の論理ボリューム（Ｅ：）と（Ｆ：）のうち、ＬＵＮＩＤがストレージ装置ＳＹＳ１のボリュームＶＯＬ１のＬＵＮＩＤと等しいものを探す。以上の結果、ホストコンピュータの論理ボリュームとストレージ装置のボリュームを含むトポロジの一つとして、ホストコンピュータＨＯＳＴ１の論理ボリューム（Ｅ：）と、ストレージ装置ＳＹＳ１のボリュームＶＯＬ１の組み合わせが存在する。
そこで、観測イベントとして"ホストコンピュータＨＯＳＴ１の論理ボリューム（Ｅ：）の状態異常"と、"ストレージ装置ＳＹＳ１のボリュームＶＯＬ１の状態異常"を検知した際、根本原因として"ストレージ装置ＳＹＳ１のボリュームＶＯＬ１の故障"を結論付けるパターンが展開結果（つまり展開すべき因果律）となる。この展開結果が因果律行列に存在しない場合、展開結果を因果律行列の列として追加する。
上記の処理が終了した後、展開結果の結論イベントと、入力イベント以外の条件イベントについて、図２０に示すイベント伝播モデルオンデマンド展開処理を実施する。上記の展開結果の場合、"ストレージ装置ＳＹＳ１のボリュームＶＯＬ１の故障"というイベントについて、図１８に示す展開対象イベント伝播モデル管理表を参照すると、Ｒｕｌｅ２を再展開する必要があることが分かる。そこで、"ストレージ装置ＳＹＳ１のボリュームＶＯＬ１の故障"というイベントを起点として、Ｒｕｌｅ２について再度展開を行う。
以上の処理により、イベント伝播モデルＲｕｌｅ１およびＲｕｌｅ２に関する因果律行列が作成され、それぞれ図１４Ｃおよび図１４Ｄの状態となる。
一方、装置情報取得モジュールは、構成ＤＢに格納された過去の構成情報と、管理対象装置より取得した構成情報を参照し、イベント管理表を更新する。ここでは、図１２のイベント管理表の２行目に示す通り、ストレージ装置ＳＹＳ１の、ＴＧ１で示されるｉＳＣＳＩターゲットにおける接続許可ｉＳＣＳＩイニシエータの変更を検知したケースを想定する。なお、変更後のｉＳＣＳＩターゲット管理表を図８Ｂに示す。
次に、イベント解析処理モジュールは、イベント管理表に定義されたイベントの処理済みフラグをＹｅｓに変更する。次にイベント解析処理モジュールは、イベント管理表に定義されたイベントが構成変更イベントかどうかを確認する。イベント管理表に定義されたイベントが構成変更イベントである場合、イベント伝播モデル再展開処理を実行する。
イベント伝播モデル展開モジュールは、因果律行列を全て削除し、イベント種別が構成変更であるイベントについて、イベント処理済みフラグをＹｅｓに変更する。次に、イベント伝播モデル展開モジュールは、イベント管理表を参照し、イベントの種別が状態異常、性能異常であり、かつイベント有効期間が満了していないイベントについて、イベント伝播モデルオンデマンド展開処理を実施する。
例えば、図１２のイベント管理表の１行目には、"ホストコンピュータＨＯＳＴ１の、（Ｅ：）で示される論理ボリュームにおける状態異常"というイベントが定義されており、イベント処理済みフラグをＹｅｓで、イベント有効期間は"２０１０−０１−０１ １５：３０：００"と定義されている。そこで、イベント伝播モデル展開モジュールは、上記イベントを起点にイベント伝播モデルオンデマンド展開を行う。すなわち、イベント伝播モデルＲｕｌｅ１を展開し、因果律行列に追加する。展開の方法は、イベント伝播モデルオンデマンド展開処理の説明にて述べた方法と同じである。
以上の処理により、イベント伝播モデルＲｕｌｅ１に関する因果律行列が更新され、図１４Ｃから図１４Ｅの状態となる。
実施例２では、管理プログラムのイベント伝播モデル展開モジュール３２５００が実施する、別なイベント伝播モデルオンデマンド展開処理について説明する。
実施例１においては、同時に複数のイベントについてイベント伝播モデルオンデマンド展開処理を実行するようイベント伝播モデル展開モジュールに指示する。ＩＴシステムにおいては、１つの障害が多数の装置に波及し、同時に多数の異常イベントが管理プログラムによって検知される。しかし、同じ根本原因を持つ異常イベントについて、イベント伝播モデルオンデマンド展開処理を並列に処理すると、同じトポロジを複数同時に構成ＤＢより取得することとなり、処理上の無駄が多く処理時間が長くなる。
上記の課題を解決するため、実施例２では管理サーバ３００００におけるイベント伝播モデルオンデマンド展開処理を変更する。変更後の管理サーバ３００００が具備する展開済イベント管理表３３７００を図２２に、展開済起点コンポーネント管理表３３８００を図２３に、管理サーバ３００００が実行する処理を図２４Ａ及び図２４Ｂに示す。なお、その他は実施例１と同様である。
図２２は、実施例２において管理サーバ３００００の記憶資源に格納された展開済イベント管理表３３７００の構成例を示す図である。
展開済イベント管理表３３７００は、展開済イベントの発生した装置の識別子となる装置ＩＤを登録するフィールド３３７１０と、イベントの発生した装置内の部位の識別子を登録するフィールド３３７２０と、前記イベントの種別を登録するフィールド３３７３０と、前記イベントを契機とした展開処理の進行状況を登録するフィールド３３７４０と、を構成項目として含んでいる。
図２２には、管理サーバの具備する展開済イベント管理表の具体的な値の一例を示している。つまり、ホストコンピュータＨＯＳＴ１における論理ボリューム（Ｅ：）の状態異常というイベントを契機とした展開処理は既に完了していることを示している。
図２３は、実施例２において管理サーバ３００００の記憶資源に格納された展開済起点コンポーネント管理表３３８００の構成例を示す図である。
展開済起点コンポーネント管理表３３８００は、展開済起点コンポーネントの存在する装置の識別子となる装置ＩＤを登録するフィールド３３８１０と、起点コンポーネントの識別子を登録するフィールド３３８２０と、前記コンポーネントを起点に展開を行ったイベント伝播モデルのＩＤを登録するフィールド３３８３０と、前記イベントを契機とした展開処理の進行状況を登録するフィールド３３８４０と、を構成項目として含んでいる。
図２３には、管理サーバの具備する展開済起点コンポーネント管理表の具体的な値の一例を示している。つまり、ストレージ装置ＳＹＳ１におけるボリュームＶＯＬ１というコンポーネントを起点としたＲｕｌｅ１の展開処理は既に完了していることを示している。
本実施例において管理サーバ３００００が実行するイベント伝播モデルオンデマンド展開処理の処理方式を図２４Ａ及び図２４Ｂに示す。なお、管理サーバ３００００が実行するその他の処理は、実施例１と変わらない。
図２４Ａ及び図２４Ｂに、実施例２における、管理サーバ３００００のイベント伝播モデル展開モジュール３２５００が実施するイベント伝播モデルオンデマンド展開処理のフローチャートを示す。先ずは図２４Ａの処理から説明を始める。
イベント伝播モデル展開モジュール３２５００は、展開済イベント管理表３３７００を参照し、処理起動時に指定されたイベントが存在するかどうか検索する（ステップ６７０１０）。イベントが存在し、そのステータスが「展開済」の場合は、何もせず処理を終了する。イベントが存在し、そのステータスが「展開中」の場合は、一定時間待機した後に処理を再試行する。展開済イベント管理表３３７００にイベントが存在しない場合は、以下に示す処理を実施する（ステップ６７０２０）。
イベント伝播モデル展開モジュール３２５００は、展開済イベント管理表３３７００にイベントを追加し、イベントのステータスを「展開中」に変更する（ステップ６７０３０）。次に、展開対象イベント伝播モデル管理表３３６００を参照し、発生したイベントに対応したイベント伝播モデルの一覧を取得する（ステップ６７０４０）。
次に、イベント伝播モデル展開モジュール３２５００は、前記取得したイベント伝播モデルに対し、図２４Ｂに記載のステップ６７０６０乃至ステップ６７１４０の処理を繰り返す（ステップ６７０５０）。なお、展開対象イベント伝播モデル管理表３３６００にイベントが登録されていない場合は、以下の処理を行わずにイベント伝播モデルオンデマンド展開処理を終了する。
以下、図２４Ｂの説明である。
イベント伝播モデル展開モジュール３２５００は、トポロジ生成方式リポジトリ３３４００を参照し、イベント伝播モデルに対応したトポロジ生成方式をトポロジ生成方式リポジトリ３３４００より取得する（ステップ６７０６０）。該当するトポロジ生成方式がトポロジ生成方式リポジトリ３３４００にない場合は、以下の処理を行わない。
該当するトポロジ生成方式がトポロジ生成方式リポジトリにあれば（ステップ６７０７０）、イベント伝播モデル展開モジュール３２５００は、取得したトポロジ生成方式を元に、イベントの発生したコンポーネントに対応する起点コンポーネント取得する（ステップ６７０８０）。
次に、イベント伝播モデル展開モジュール３２５００は、展開済起点コンポーネント管理表３３８００を参照し、起点コンポーネントが存在するかどうか検索する（ステップ６７０１０）。起点コンポーネントが存在し、そのステータスが「展開済」の場合は、何もせず処理を終了する。起点コンポーネントが存在し、そのステータスが「展開中」の場合は、一定時間待機した後に処理を再試行する。展開済起点コンポーネント管理表３３８００に起点コンポーネントが存在しない場合は、以下に示す処理を実施する（ステップ６７０９０）。
イベント伝播モデル展開モジュール３２５００は、展開済起点コンポーネント管理表３３８００に起点コンポーネントを追加し、起点コンポーネントのステータスを「展開中」に変更する（ステップ６７１００）。
イベント伝播モデル展開モジュール３２５００は、取得した生成方式リポジトリを元に構成ＤＢ３３５００からトポロジを取得し、取得したトポロジに基づいてイベント伝播モデルを展開する（ステップ６７１１０）。そして展開結果を、因果律行列３３３００の列として追加する（ステップ６７１２０）。次に、展開済起点コンポーネント管理表３３８００を参照し、起点コンポーネントのステータスを「展開済」に変更する（ステップ６７１３０）。
次に、展開結果の結論イベントと、処理起動時に指定されたイベント以外の条件イベントについて、ルールオンデマンド展開処理を繰り返し実施する（ステップ６７１４０）。
ここまでが図２４Ｂの説明である。再び図２４Ａに戻り説明する。
イベント伝播モデルに対する処理が終了した時点で、展開済イベント管理表３３７００を参照し、発生したイベントのステータスを「展開済」に変更する（ステップ６７１５０）。
以下に、図６乃至１３の情報の内容に対応する計算機システムを例として、実施例２の処理がどのように因果律行列を作成するかを示す。
プログラム制御モジュールは、管理者からの指示もしくはタイマーによるスケジュール設定によって応じて、装置情報取得モジュールに対し、装置情報取得処理を実行するよう指示する。装置情報取得モジュールは、管理対象装置に順にログインし、管理対象装置に対し装置の構成情報、状態情報、性能情報を送信するよう指示する。
上記の処理が終了した後、装置情報取得モジュールは、取得した状態情報、性能情報を参照し、イベント管理表を更新する。ここでは、図１２のイベント管理表の４行目に示す通り、ストレージ装置ＳＹＳ１の、ＤＩＳＫ１で示されるディスクにおける状態異常を検知したケースを想定する。
イベント解析処理モジュールは、展開対象イベント伝播モデル管理表を参照し、上記イベントが未処理イベントであることを確認すると、イベント伝播モデル展開モジュールに対し、当該イベントを指定してイベント伝播モデルオンデマンド展開処理を実行するよう指示する。
イベント伝播モデル展開モジュールは、展開済イベント管理表を参照し、処理起動時に指定されたイベントが存在するかどうか検索する。展開済イベント管理表にイベントが存在しない場合、展開済イベント管理表にイベントを追加し、イベントのステータスを「展開中」に変更する。
次にイベント伝播モデル展開モジュールは、イベントに対応したイベント伝播モデルの一覧を取得する。例えば、図１８に示す展開対象イベント伝播モデル管理表を参照すると、ストレージ装置におけるディスクの状態異常というイベントが発生した場合、Ｒｕｌｅ２を展開する必要があることが分かる。
図１３Ｂに示すイベント伝播モデルＲｕｌｅ２は、観測イベントとして"ストレージ装置のボリュームの故障"、"ストレージ装置のＲＡＩＤグループの状態異常"、"ストレージ装置のディスクの状態異常"が定義されている。図１５Ｂに示すトポロジ生成方式を参照すると、ストレージ装置のＲＡＩＤグループを起点とし、ストレージ装置のボリュームとストレージ装置のディスクを終点とするトポロジ生成方式ＴＰ２が定義されている。そこで、このトポロジ生成方式を利用してトポロジを取得する。
図１０に示すＲＡＩＤグループ管理表（に相当する構成ＤＢの項目）を参照し、ストレージ装置ＳＹＳ１のディスクＤＩＳＫ１に着目すると、それに対応するＲＡＩＤグループはＲＧ１となっている。よって、ストレージ装置ＳＹＳ１のディスクＤＩＳＫ１に対応する起点となるストレージ装置のＲＡＩＤグループはＲＧ１であることが分かる。次に、図２４に示す展開済起点コンポーネント管理表を参照し、ストレージ装置ＳＹＳ１のＲＡＩＤグループＲＧ１が登録されているかどうかを検索し、登録されていなければステータスを「展開中」として新たに登録する。
次に、図７に示すボリューム管理表（に相当する構成ＤＢの項目）を参照し、ＲＡＩＤグループＩＤがＲＧ１となっているボリュームを検索する。その結果検索されたストレージ装置ＳＹＳ１のボリュームＶＯＬ１とＶＯＬ２が存在することが分かる。以上の結果、ストレージ装置のボリュームとＲＡＩＤグループとディスクを含むトポロジとして、ストレージ装置ＳＹＳ１のディスクＤＩＳＫ１と、ＲＡＩＤグループＲＧ１と、ボリュームＶＯＬ１の組み合わせが存在する。
そこで、観測イベントとして"ストレージ装置ＳＹＳ１のディスクＤＩＳＫ１の状態異常"と、"ストレージ装置ＳＹＳ１のＲＡＩＤグループＲＧ１の状態異常"と、"ストレージ装置ＳＹＳ１のボリュームＶＯＬ１の故障"を検知した際、根本原因として"ストレージ装置ＳＹＳ１のディスクＤＩＳＫ１の故障"を結論付けるパターンが展開結果となる。この展開結果を因果律行列の列として追加する。
上記の処理が終了した後、展開結果の結論イベントと、入力イベント以外の条件イベントについて、ルールオンデマンド展開処理実施する。上記の展開結果の場合、"ストレージ装置ＳＹＳ１のボリュームＶＯＬ１の故障"というイベントについて、図１８に示す展開対象イベント伝播モデル管理表を参照すると、Ｒｕｌｅ１を再展開する必要があることが分かる。そこで、Ｒｕｌｅ１について再度展開を行う。
以上の処理により、イベント伝播モデルＲｕｌｅ１およびＲｕｌｅ２に関する因果律行列が作成され、それぞれ図１４Ｃおよび図１４Ｄの状態となる。
この後、管理プログラムが"ストレージ装置ＳＹＳ１のディスクＤＩＳＫ１における状態異常"というイベントを再度検知し、イベント解析処理モジュールからイベント伝播モデル展開モジュールに対し、当該イベントを指定してイベント伝播モデルオンデマンド展開処理を実行するよう指示した場合、イベント伝播モデル展開モジュールは展開済イベント管理表を参照し、処理起動時に指定されたイベントが存在するかどうかを検索する。展開済イベント管理表にイベントが存在し、イベントのステータスは「展開済」であるため、以降の処理を行わずにイベント伝播モデルオンデマンド展開処理を終了する。
あるいは、管理プログラムが"ストレージ装置ＳＹＳ１のディスクＤＩＳＫ２における状態異常"というイベントを検知し、イベント解析処理モジュールからイベント伝播モデル展開モジュールに対し、当該イベントを指定してイベント伝播モデルオンデマンド展開処理を実行するよう指示した場合、イベント伝播モデル展開モジュールは展開済イベント管理表を参照し、処理起動時に指定されたイベントが存在するかどうかを検索する。展開済イベント管理表にイベントが存在しないため、イベント伝播モデル展開モジュールは展開対象イベント伝播モデル管理表を参照し、イベント伝播モデルＲｕｌｅ２を展開する必要があると判断する。
図１３Ｂに示すイベント伝播モデルＲｕｌｅ２は、観測イベントとして"ストレージ装置のボリュームの故障"、"ストレージ装置のＲＡＩＤグループの状態異常"、"ストレージ装置のディスクの状態異常"が定義されている。図１５Ｂに示すトポロジ生成方式を参照すると、ストレージ装置のＲＡＩＤグループを起点とし、ストレージ装置のボリュームとストレージ装置のディスクを終点とするトポロジ生成方式ＴＰ２が定義されている。そこで、このトポロジ生成方式を利用してトポロジを取得する。
図１０に示すＲＡＩＤグループ管理表（に相当する構成ＤＢの項目）を参照し、ストレージ装置ＳＹＳ１のディスクＤＩＳＫ２に着目すると、それに対応するＲＡＩＤグループはＲＧ１となっている。よって、ストレージ装置ＳＹＳ１のディスクＤＩＳＫ２に対応する起点となるストレージ装置のＲＡＩＤグループはＲＧ１であることが分かる。次に、図２３に示す展開済起点コンポーネント管理表を参照すると、ストレージ装置ＳＹＳ１のＲＡＩＤグループＲＧ１が存在し、起点コンポーネントのステータスは「展開済」であるため、以降の処理を行わずにイベント伝播モデルオンデマンド展開処理を終了する。
なお、図２９に示すように、計算機システム上に管理サーバ３００００が複数台存在し、ストレージ装置２００００、ホストコンピュータ１００００、管理サーバ３００００といった管理対象装置を分担して管理している場合、管理サーバ３００００のイベント伝播モデル展開モジュール３２５００は、展開済イベント管理表３３７００に処理起動時に指定されたイベントが存在しない場合は、他の管理サーバ上の展開済イベント管理表を参照し、当該イベントが存在するかどうかを検索する。当該イベントが存在する場合、その管理サーバ上の因果律行列３３３００から、当該イベントに関連する行および列を収集し、自身の因果律行列にコピーする。
以上が、本実施例におけるイベント伝播モデルオンデマンド展開処理である。
以上本実施例によれば、管理プログラムは、イベント伝播モデルを展開する前に、検知したイベントおよび展開しようとするイベント伝播モデルに対応する結論コンポーネントを検索し、各結論コンポーネントのうち既にルール展開を完了したもの、あるいは展開中であるものについて記録することにより、同じイベント伝播モデルから同じ因果律行列を繰り返し生成することを抑止する。
その結果として、大規模システムを対象とし、オンデマンド展開方式を採用する解析エンジンにおいて、同じ障害原因を持つ多数の障害を同時に受信した場合においても、イベント伝播モデルに基づく因果律行列の展開作業を効率化でき、管理サーバにかかる処理負荷を軽減しつつ適切に因果律行列の展開処理を実行できる。
実施例３では、管理プログラムのイベント伝播モデル展開モジュール３２５００が実施する、イベント伝播モデル展開処理について説明する。
実施例１においては、管理プログラムが装置から異常イベントを受信してからイベント伝播モデルオンデマンド展開処理を実行し、それが終了した後に障害解析を実施する。従って、イベントを受信してから障害解析を開始するまでの時間が、従来の事前展開方式に比べて長いという課題が存在する。一方、例えばストレージ内の物理的なコンポーネント（ポート、ディスクなど）にのみ関するイベント伝播モデルの場合、展開する際に取得するトポロジが変化する頻度は非常に低いため、従来の事前展開方式を採用しても構成変更により再展開を強いられる可能性は非常に低く、イベント受信後に障害解析をより迅速に開始するには、事前展開方式を採用する方が望ましい。
このような課題を解決するため、実施例３では管理サーバ３００００におけるイベント伝播モデルオンデマンド展開処理およびイベント伝播モデル再展開処理を変更する。実施例３の管理サーバ３００００が具備するイベント伝播モデル管理表３３９００を図２５に、管理サーバ３００００が実行する処理フローを図２６乃至図２８に示す。なお、管理サーバ３００００のその他の情報及びフローは実施例１又は２と同じである。
図２５は、実施例３において管理サーバ３００００の具備するイベント伝播モデル管理表３３９００の構成例を示す図である。
イベント伝播モデル管理表３３９００は、イベント伝播モデルの識別子となるイベント伝播モデルＩＤを登録するフィールド３３９１０と、前記イベント伝播モデルの展開に用いる方式を登録するフィールド３３９２０と、を構成項目として含んでいる。
図２５には、管理サーバの具備するイベント伝播モデル管理表の具体的な値の一例を示している。つまり、イベント伝播モデルＩＤがＲｕｌｅ１で示されるイベント伝播モデルについては、事前展開方式によって展開することを示している。
本実施例において管理サーバ３００００が実行するイベント伝播モデルオンデマンド展開処理の処理方式を図２６に示す。なお、管理サーバ３００００が実行するその他の処理は、実施例１と変わらない。
図２６に、実施例３における、管理サーバ３００００のイベント伝播モデル展開モジュール３２５００が実施するイベント伝播モデルオンデマンド展開処理のフローチャートを示す。実施例１の図２０で説明したフローと異なる点はステップ６５０２１及びステップ６５０２２が追加されたことである。以下、追加された部分のみ説明する。
イベント伝播モデル展開モジュール３２５００はイベント伝播モデル管理表３３９００を参照し、イベント伝播モデルの展開方式を取得する（ステップ６５０２１）。展開方式が「オンデマンド展開」であった場合（ステップ６５０２２）、ステップ６５０３０を実行する。
図２８に、実施例３における、管理サーバ３００００のイベント伝播モデル展開モジュール３２５００が実施するイベント伝播モデル展開処理のフローチャートを示す。なお、処理は実施例１で説明した図２１の処理のステップ６６０２０とステップ６６０３０との間で実行される。
イベント伝播モデル展開モジュール３２５００は、イベント伝播モデルリポジトリ３３２００に定義された全てのイベント伝播モデルに対し、ステップ６３０２２乃至６３０６０の処理を繰り返す（ステップ６３０２０）。
イベント伝播モデル展開モジュール３２５００は、イベント伝播モデル管理表３３９００を参照し、イベント伝播モデルの展開方式を取得する（ステップ６３０２１）。展開方式が「事前展開」であった場合（ステップ６３０２２）、以下の処理を実行する。
イベント伝播モデル展開モジュール３２５００は、トポロジ生成方式リポジトリ３３４００を参照し、イベント伝播モデルに対応したトポロジ生成方式をトポロジ生成方式リポジトリ３３４００より取得する（ステップ６３０３０）。
該当するトポロジ生成方式がトポロジ生成方式リポジトリにあれば（ステップ６３０４０）、イベント伝播モデル展開モジュール３２５００は、取得したトポロジ生成方式を元に構成ＤＢ３３５００からトポロジを取得し（ステップ６３０５０）、取得したトポロジを用いてイベント伝播モデルを展開し、因果律行列３３３００に追加する（ステップ６３０６０）。
以上が、イベント伝播モデル展開モジュール３２５００が実施するイベント伝播モデル展開処理である。
なお、本実施例ではイベント伝播モデル毎にオンデマンド展開方式と事前展開方式のどちらを用いるかを定義していたが、例えば管理対象装置ごとに前記の定義をしても構わない。即ち、障害発生後即座に根本原因を求めたい重要な装置については事前展開方式を、その他の装置についてはオンデマンド展開方式を採用するというように使い分けることができる。
以上本実施例によれば、管理プログラムのイベント伝播モデル管理表に登録されたポリシーに基づき、個々のイベント伝播モデルについて、実施例１で述べたオンデマンド展開方式と、事前展開方式のどちらを用いるかを選択することができる。結果として、イベント伝播モデルの性質や、解析作業のリアルタイム性をどの程度求めるかによって両方式を使い分けることができる。
１００００：サーバ、２００００：ストレージ装置、３００００：管理サーバ、４００００：IPスイッチ、４５０００：ネットワーク

Claims (18)

  1. 管理プログラムを格納した記憶資源と、
    前記管理プログラムを実行するプロセッサと、
    を含む、複数の管理対象計算機を管理する管理計算機であって、
    前記記憶資源は、
    （１）前記複数の管理対象計算機又は前記複数の管理計算機が含む複数のコンポーネントである複数の管理オブジェクトに関し、前記複数の管理オブジェクト同士の関係を示すトポロジと、
    （２）イベント種別及びイベントが発生する管理オブジェクトの種別によって定義される、イベントと当該イベント発生原因となる原因イベントとの組の情報を含むイベント伝播モデルと、
    （３）一つ以上の因果律を含む因果律情報と、
    を格納し、
    前記因果律とは、種別が種別１である第１の管理オブジェクトで発生する、種別が種別Ａである第１のイベントが原因で、種別が種別２である第２の管理オブジェクトで種別が種別Ｂである第２のイベントが発生すること、を示し、
    前記管理プログラムは、前記プロセッサに、
    （Ａ）所定の管理オブジェクトで発生した問題に関するイベントを検知させ、
    （Ｂ）前記検知イベントの解析に用いる第１の因果律が前記因果律情報に生成済みか判断させ、
    （Ｃ）（Ｂ）で未生成と判断した場合、前記トポロジと前記イベント伝播モデルに基づいて前記第１の因果律を前記因果律情報に生成するオンデマンド展開をさせ、
    （Ｄ）前記第１の因果律を用いて、前記検知イベントを解析させる、
    ことを特徴とした管理計算機。
  2. 請求項１記載の管理計算機であって、
    前記管理プログラムは、前記プロセッサに、
    前記検知イベント以外の、解析した前記第１の因果律に含まれるイベントの解析に用いる第２の因果律が、前記因果律情報に生成済みか判断させ、未生成と判断した場合、前記第２の因果律に関してオンデマンド展開をさせる、
    ことを特徴とした管理計算機。
  3. 請求項１または請求項２に記載の管理計算機であって、
    前記記憶資源は、
    （４）前記イベント伝播モデルに対応する因果律の作成を事前に実行するか否かを示す、イベント伝播モデル管理情報、
    を格納し、
    前記管理計算機がイベントを検知する前に、前記管理プログラムは、前記プロセッサに、
    （Ｅ）前記イベント伝播モデル管理情報に基づいて、前記因果律を事前に作成するか否か判断させる、
    ことを特徴とした管理計算機。
  4. 請求項１乃至請求項３のいずれか１つに記載の管理計算機であって、
    前記記憶資源は、
    （５）前記管理オブジェクトに対応する因果律の作成を事前に実行するか否かを示す事前展開可否情報、
    を格納し、
    前記管理計算機がイベントを検知する前に、前記管理プログラムは、前記プロセッサに、
    （Ｆ）前記事前展開可否情報に基づいて、前記所定の管理オブジェクトに対応する前記因果律を事前に作成させるか否か判断させる、
    ことを特徴とした管理計算機。
  5. 請求項１乃至請求項４のいずれか１つに記載の管理計算機であって、
    前記記憶資源は、
    （６）前記検知イベントに関する解析有効期間、
    を格納し、
    前記解析有効期間後に、前記管理プログラムは、前記プロセッサに、
    （Ｇ）前記検知イベントに対応する前記第１の因果律を前記因果律情報から削除させる、
    ことを特徴とした管理計算機。
  6. 請求項１乃至請求項５のいずれか１つに記載の管理計算機であって、
    前記管理プログラムは、前記プロセッサに、
    （Ｈ）前記第１の因果律が示す原因イベントと同じ原因を持つ他の因果律のオンデマンド展開を、前記第１の因果律に関するオンデマンド展開中は抑止させる、
    ことを特徴とした管理計算機。
  7. 複数の管理対象計算機を管理する記憶資源を含む管理計算機によるイベント解析方法であって、
    前記記憶資源に、
    （１）前記複数の管理対象計算機又は前記複数の管理計算機が含む複数のコンポーネントである複数の管理オブジェクトに関し、前記複数の管理オブジェクト同士の関係を示すトポロジと、
    （２）イベント種別及びイベントが発生する管理オブジェクトの種別によって定義される、イベントと当該イベント発生原因となる原因イベントとの組の情報を含むイベント伝播モデルと、
    （３）一つ以上の因果律を含む因果律情報と、
    を格納し、
    前記因果律とは、種別が種別１である第１の管理オブジェクトで発生する、種別が種別Ａである第１のイベントが原因で、種別が種別２である第２の管理オブジェクトで種別が種別Ｂである第２のイベントが発生すること、を示し、
    （Ａ）所定の管理オブジェクトで発生した問題に関するイベントを検知し、
    （Ｂ）前記検知イベントの解析に用いる第１の因果律が前記因果律情報に生成済みか判断し、
    （Ｃ）（Ｂ）で未生成と判断した場合、前記トポロジと前記イベント伝播モデルに基づいて前記第１の因果律を前記因果律情報に生成するオンデマンド展開し、
    （Ｄ）前記第１の因果律を用いて、前記検知イベントを解析する、
    ことを特徴とした方法。
  8. 請求項７記載のイベント解析方法であって、
    前記検知イベント以外の、解析した前記第１の因果律に含まれるイベントの解析に用いる第２の因果律が、前記因果律情報に生成済みか判断し、未生成と判断した場合、前記第２の因果律に関してオンデマンド展開する、
    ことを特徴とした方法。
  9. 請求項７または請求項８に記載のイベント解析方法であって、
    前記記憶資源に、
    （４）前記イベント伝播モデルに対応する因果律の作成を事前に実行するか否かを示す、イベント伝播モデル管理情報、
    を格納し、
    （Ｅ）前記管理計算機がイベントを検知する前に、前記イベント伝播モデル管理情報に基づいて、前記因果律を事前に作成させるか否か判断する、
    ことを特徴とした方法。
  10. 請求項７乃至請求項９のいずれか１つに記載のイベント解析方法であって、
    前記記憶資源に、
    （５）前記管理オブジェクトに対応する因果律の作成を事前に実行するか否かを示す事前展開可否情報、
    を格納し、
    （Ｆ）前記管理計算機がイベントを検知する前に、前記事前展開可否情報に基づいて、前記所定の管理オブジェクトに対応する前記因果律を事前に作成させるか否か判断する、
    ことを特徴とした方法。
  11. 請求項７乃至請求項１０のいずれか１つに記載のイベント解析方法であって、
    前記記憶資源に、
    （６）前記検知イベントに関する解析有効期間、
    を格納し、
    （Ｇ）前記解析有効期間後に、前記検知イベントに対応する前記第１の因果律を前記因果律情報から削除する、
    ことを特徴とした方法。
  12. 請求項７乃至請求項１１のいずれか１つに記載のイベント解析方法であって、
    （Ｈ）前記第１の因果律が示す原因イベントと同じ原因を持つ他の因果律のオンデマンド展開を、前記第１の因果律に関するオンデマンド展開中は抑止する、
    ことを特徴とした方法。
  13. 複数の管理対象計算機と、
    前記複数の管理対象計算機を管理し、記憶資源を有する管理計算機と、
    を有する計算機システムであって、
    前記記憶資源は、
    （１）前記複数の管理対象計算機又は前記複数の管理計算機が含む複数のコンポーネントである複数の管理オブジェクトに関し、前記複数の管理オブジェクト同士の関係を示すトポロジと、
    （２）イベント種別及びイベントが発生する管理オブジェクトの種別によって定義される、イベントと当該イベント発生原因となる原因イベントとの組の情報を含むイベント伝播モデルと、
    （３）一つ以上の因果律を含む因果律情報と、
    を格納し、
    前記因果律とは、種別が種別１である第１の管理オブジェクトで発生する、種別が種別Ａである第１のイベントが原因で、種別が種別２である第２の管理オブジェクトで種別が種別Ｂである第２のイベントが発生すること、を示し、
    前記管理計算機は、
    （Ａ）所定の管理オブジェクトで発生した問題に関するイベントを検知し、
    （Ｂ）前記検知イベントの解析に用いる第１の因果律が前記因果律情報に生成済みか判断し、
    （Ｃ）（Ｂ）で未生成と判断した場合、前記トポロジと前記イベント伝播モデルに基づいて前記第１の因果律を前記因果律情報に生成するオンデマンド展開し、
    （Ｄ）前記第１の因果律を用いて、前記検知イベントを解析する、
    ことを特徴とした計算機システム。
  14. 請求項１３記載の計算機システムであって、
    前記管理計算機は、
    前記検知イベント以外の、解析した前記第１の因果律に含まれるイベントの解析に用いる第２の因果律が、前記因果律情報に生成済みか判断し、未生成と判断した場合、前記第２の因果律に関してオンデマンド展開する、
    ことを特徴とした計算機システム。
  15. 請求項１３または請求項１４に記載の計算機システムであって、
    前記記憶資源は、
    （４）前記イベント伝播モデルに対応する因果律の作成を事前に実行するか否かを示す、イベント伝播モデル管理情報、
    を格納し、
    前記管理計算機がイベントを検知する前に、前記管理計算機は、
    （Ｅ）前記イベント伝播モデル管理情報に基づいて、前記因果律を事前に作成するか否か判断する、
    ことを特徴とした計算機システム。
  16. 請求項１３乃至請求項１５のいずれか１つに記載の計算機システムであって、
    前記記憶資源は、
    （５）前記管理オブジェクトに対応する因果律の作成を事前に実行するか否かを示す事前展開可否情報、
    を格納し、
    前記管理計算機がイベントを検知する前に、前記管理計算機は、
    （Ｆ）前記事前展開可否情報に基づいて、前記所定の管理オブジェクトに対応する前記因果律を事前に作成させるか否か判断する、
    ことを特徴とした計算機システム。
  17. 請求項１３乃至請求項１６のいずれか１つに記載の計算機システムであって、
    前記記憶資源は、
    （６）前記検知イベントに関する解析有効期間、
    を格納し、
    前記解析有効期間後に、前記管理計算機は、
    （Ｇ）前記検知イベントに対応する前記第１の因果律を前記因果律情報から削除する、
    ことを特徴とした計算機システム。
  18. 請求項１３乃至請求項１７のいずれか１つに記載の計算機システムであって、
    前記管理計算機は、
    （Ｈ）前記第１の因果律が示す原因イベントと同じ原因を持つ他の因果律のオンデマンド展開を、前記第１の因果律に関するオンデマンド展開中は抑止する、
    ことを特徴とした計算機システム。
JP2013535648A 2011-09-26 2011-09-26 根本原因を解析する管理計算機及び方法 Expired - Fee Related JP5745077B2 (ja)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2011/071800 WO2013046287A1 (ja) 2011-09-26 2011-09-26 根本原因を解析する管理計算機及び方法

Related Child Applications (1)

Application Number Title Priority Date Filing Date
JP2015091251A Division JP5938495B2 (ja) 2015-04-28 2015-04-28 根本原因を解析する管理計算機、方法及び計算機システム

Publications (2)

Publication Number Publication Date
JPWO2013046287A1 JPWO2013046287A1 (ja) 2015-03-26
JP5745077B2 true JP5745077B2 (ja) 2015-07-08

Family

ID=47912501

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2013535648A Expired - Fee Related JP5745077B2 (ja) 2011-09-26 2011-09-26 根本原因を解析する管理計算機及び方法

Country Status (5)

Country Link
US (2) US9021077B2 (ja)
EP (1) EP2674865A4 (ja)
JP (1) JP5745077B2 (ja)
CN (1) CN103477325A (ja)
WO (1) WO2013046287A1 (ja)

Families Citing this family (58)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9736065B2 (en) 2011-06-24 2017-08-15 Cisco Technology, Inc. Level of hierarchy in MST for traffic localization and load balancing
US8908698B2 (en) 2012-01-13 2014-12-09 Cisco Technology, Inc. System and method for managing site-to-site VPNs of a cloud managed network
US20150149606A1 (en) * 2012-05-15 2015-05-28 Telefonaktiebolaget L M Ericsson (Publ) Managed object manipulation
US9043439B2 (en) 2013-03-14 2015-05-26 Cisco Technology, Inc. Method for streaming packet captures from network access devices to a cloud server over HTTP
US10169122B2 (en) * 2013-04-29 2019-01-01 Moogsoft, Inc. Methods for decomposing events from managed infrastructures
US20160004584A1 (en) * 2013-08-09 2016-01-07 Hitachi, Ltd. Method and computer system to allocate actual memory area from storage pool to virtual volume
US10979295B2 (en) 2014-01-21 2021-04-13 Micro Focus Llc Automatically discovering topology of an information technology (IT) infrastructure
US10122605B2 (en) * 2014-07-09 2018-11-06 Cisco Technology, Inc Annotation of network activity through different phases of execution
WO2016013056A1 (ja) * 2014-07-22 2016-01-28 株式会社日立製作所 計算機システムを管理する方法
US9825878B2 (en) 2014-09-26 2017-11-21 Cisco Technology, Inc. Distributed application framework for prioritizing network traffic using application priority awareness
US10050862B2 (en) 2015-02-09 2018-08-14 Cisco Technology, Inc. Distributed application framework that uses network and application awareness for placing data
US10708342B2 (en) 2015-02-27 2020-07-07 Cisco Technology, Inc. Dynamic troubleshooting workspaces for cloud and network management systems
US10476982B2 (en) 2015-05-15 2019-11-12 Cisco Technology, Inc. Multi-datacenter message queue
US10034201B2 (en) 2015-07-09 2018-07-24 Cisco Technology, Inc. Stateless load-balancing across multiple tunnels
US11005682B2 (en) 2015-10-06 2021-05-11 Cisco Technology, Inc. Policy-driven switch overlay bypass in a hybrid cloud network environment
US10462136B2 (en) 2015-10-13 2019-10-29 Cisco Technology, Inc. Hybrid cloud security groups
US10523657B2 (en) 2015-11-16 2019-12-31 Cisco Technology, Inc. Endpoint privacy preservation with cloud conferencing
US10205677B2 (en) 2015-11-24 2019-02-12 Cisco Technology, Inc. Cloud resource placement optimization and migration execution in federated clouds
US10084703B2 (en) 2015-12-04 2018-09-25 Cisco Technology, Inc. Infrastructure-exclusive service forwarding
US10367914B2 (en) 2016-01-12 2019-07-30 Cisco Technology, Inc. Attaching service level agreements to application containers and enabling service assurance
US10129177B2 (en) 2016-05-23 2018-11-13 Cisco Technology, Inc. Inter-cloud broker for hybrid cloud networks
US10659283B2 (en) 2016-07-08 2020-05-19 Cisco Technology, Inc. Reducing ARP/ND flooding in cloud environment
US10432532B2 (en) 2016-07-12 2019-10-01 Cisco Technology, Inc. Dynamically pinning micro-service to uplink port
US10263898B2 (en) 2016-07-20 2019-04-16 Cisco Technology, Inc. System and method for implementing universal cloud classification (UCC) as a service (UCCaaS)
US10382597B2 (en) 2016-07-20 2019-08-13 Cisco Technology, Inc. System and method for transport-layer level identification and isolation of container traffic
US10567344B2 (en) 2016-08-23 2020-02-18 Cisco Technology, Inc. Automatic firewall configuration based on aggregated cloud managed information
US10402289B2 (en) * 2016-09-07 2019-09-03 Nec Corporation Fine-grained causal anomaly inference for complex system fault diagnosis
TWI608365B (zh) * 2016-09-23 2017-12-11 財團法人工業技術研究院 擾動源追溯方法
US10523592B2 (en) 2016-10-10 2019-12-31 Cisco Technology, Inc. Orchestration system for migrating user data and services based on user information
US11044162B2 (en) 2016-12-06 2021-06-22 Cisco Technology, Inc. Orchestration of cloud and fog interactions
US10326817B2 (en) 2016-12-20 2019-06-18 Cisco Technology, Inc. System and method for quality-aware recording in large scale collaborate clouds
US10334029B2 (en) 2017-01-10 2019-06-25 Cisco Technology, Inc. Forming neighborhood groups from disperse cloud providers
US10552191B2 (en) 2017-01-26 2020-02-04 Cisco Technology, Inc. Distributed hybrid cloud orchestration model
US10320683B2 (en) 2017-01-30 2019-06-11 Cisco Technology, Inc. Reliable load-balancer using segment routing and real-time application monitoring
US10671571B2 (en) 2017-01-31 2020-06-02 Cisco Technology, Inc. Fast network performance in containerized environments for network function virtualization
US10417079B2 (en) * 2017-03-30 2019-09-17 Ca, Inc. Fault tolerant root cause analysis system
US11005731B2 (en) 2017-04-05 2021-05-11 Cisco Technology, Inc. Estimating model parameters for automatic deployment of scalable micro services
US10439877B2 (en) 2017-06-26 2019-10-08 Cisco Technology, Inc. Systems and methods for enabling wide area multicast domain name system
US10382274B2 (en) 2017-06-26 2019-08-13 Cisco Technology, Inc. System and method for wide area zero-configuration network auto configuration
US10892940B2 (en) 2017-07-21 2021-01-12 Cisco Technology, Inc. Scalable statistics and analytics mechanisms in cloud networking
US10425288B2 (en) 2017-07-21 2019-09-24 Cisco Technology, Inc. Container telemetry in data center environments with blade servers and switches
US10601693B2 (en) 2017-07-24 2020-03-24 Cisco Technology, Inc. System and method for providing scalable flow monitoring in a data center fabric
US10541866B2 (en) 2017-07-25 2020-01-21 Cisco Technology, Inc. Detecting and resolving multicast traffic performance issues
US11481362B2 (en) 2017-11-13 2022-10-25 Cisco Technology, Inc. Using persistent memory to enable restartability of bulk load transactions in cloud databases
US10705882B2 (en) 2017-12-21 2020-07-07 Cisco Technology, Inc. System and method for resource placement across clouds for data intensive workloads
US11595474B2 (en) 2017-12-28 2023-02-28 Cisco Technology, Inc. Accelerating data replication using multicast and non-volatile memory enabled nodes
US10511534B2 (en) 2018-04-06 2019-12-17 Cisco Technology, Inc. Stateless distributed load-balancing
US10728361B2 (en) 2018-05-29 2020-07-28 Cisco Technology, Inc. System for association of customer information across subscribers
US10904322B2 (en) 2018-06-15 2021-01-26 Cisco Technology, Inc. Systems and methods for scaling down cloud-based servers handling secure connections
US10764266B2 (en) 2018-06-19 2020-09-01 Cisco Technology, Inc. Distributed authentication and authorization for rapid scaling of containerized services
US11019083B2 (en) 2018-06-20 2021-05-25 Cisco Technology, Inc. System for coordinating distributed website analysis
US10819571B2 (en) 2018-06-29 2020-10-27 Cisco Technology, Inc. Network traffic optimization using in-situ notification system
US10904342B2 (en) 2018-07-30 2021-01-26 Cisco Technology, Inc. Container networking using communication tunnels
CN110543164A (zh) * 2019-08-26 2019-12-06 中国第一汽车股份有限公司 自动驾驶控制器的测试系统、方法及上位机
US11157347B2 (en) * 2019-12-02 2021-10-26 EMC IP Holding Company LLC Detection of resource bottlenecks in user devices using artificial intelligence and causal graphs
US11418395B2 (en) * 2020-01-08 2022-08-16 Servicenow, Inc. Systems and methods for an enhanced framework for a distributed computing system
US11226858B1 (en) 2020-12-24 2022-01-18 Salesforce.Com, Inc. Root cause analysis of logs generated by execution of a system
CN114879899A (zh) * 2021-02-05 2022-08-09 伊姆西Ip控股有限责任公司 用于生成存储系统的配置信息的方法、设备和程序产品

Family Cites Families (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5528516A (en) * 1994-05-25 1996-06-18 System Management Arts, Inc. Apparatus and method for event correlation and problem reporting
US7107185B1 (en) * 1994-05-25 2006-09-12 Emc Corporation Apparatus and method for event correlation and problem reporting
US7043661B2 (en) 2000-10-19 2006-05-09 Tti-Team Telecom International Ltd. Topology-based reasoning apparatus for root-cause analysis of network faults
JP2004126641A (ja) * 2002-09-30 2004-04-22 Toshiba Corp 因果関係モデル生成方法、因果関係モデル生成装置、原因推定方法、原因推定装置およびデータ構造
JP4862446B2 (ja) * 2006-03-22 2012-01-25 日本電気株式会社 障害原因推定システム、方法、及び、プログラム
US8037471B2 (en) * 2006-11-16 2011-10-11 International Business Machines Corporation Systems and methods for constructing relationship specifications from component interactions
JP5115023B2 (ja) * 2007-05-11 2013-01-09 富士ゼロックス株式会社 障害診断装置、方法及びプログラム
US8112378B2 (en) * 2008-06-17 2012-02-07 Hitachi, Ltd. Methods and systems for performing root cause analysis
WO2010062435A1 (en) * 2008-09-04 2010-06-03 Telcordia Technologies, Inc. Computing diagnostic explanations of network faults from monitoring data
EP2397947A4 (en) * 2009-04-23 2015-04-15 Hitachi Ltd COMPUTER FOR INDICATING EVENT-PRODUCING EXPERIMENTS IN A COMPUTER SYSTEM WITH MULTIPLE NODE DEVICES
EP2455863A4 (en) * 2009-07-16 2013-03-27 Hitachi Ltd MANAGEMENT SYSTEM FOR PROVIDING INFORMATION DESCRIBING A RECOVERY METHOD CORRESPONDING TO A FUNDAMENTAL CAUSE OF FAILURE
JP5419746B2 (ja) * 2010-02-23 2014-02-19 株式会社日立製作所 管理装置及び管理プログラム

Also Published As

Publication number Publication date
WO2013046287A1 (ja) 2013-04-04
US20150248319A1 (en) 2015-09-03
JPWO2013046287A1 (ja) 2015-03-26
CN103477325A (zh) 2013-12-25
EP2674865A4 (en) 2016-06-01
EP2674865A1 (en) 2013-12-18
US9294338B2 (en) 2016-03-22
US9021077B2 (en) 2015-04-28
US20130080624A1 (en) 2013-03-28

Similar Documents

Publication Publication Date Title
JP5745077B2 (ja) 根本原因を解析する管理計算機及び方法
JP5670598B2 (ja) コンピュータプログラムおよび管理計算機
CN107431643B (zh) 用于监测存储集群元件的方法和装置
JP5684946B2 (ja) イベントの根本原因の解析を支援する方法及びシステム
JP5468067B2 (ja) 複数のノード装置を含んだ計算機システムでのイベントの発生原因を特定する計算機
US9912535B2 (en) System and method of performing high availability configuration and validation of virtual desktop infrastructure (VDI)
WO2012053104A1 (ja) 管理システム、及び管理方法
JP5657475B2 (ja) 運用管理装置、及び方法
US20120084317A1 (en) Complex event processing apparatus and complex event processing method
JP4598065B2 (ja) 監視シミュレーション装置，方法およびそのプログラム
JP2009519523A (ja) 仮想データ・センタ複合体内のターゲット仮想オペレーティング・システムのパフォーマンスをモニタするための方法、システム、およびコンピュータ・プログラム
US10949401B2 (en) Data replication in site recovery environment
US20050210465A1 (en) Management system of difference data among servers and control method of information processing apparatus
JP6009089B2 (ja) 計算機システムを管理する管理システム及びその管理方法
JP2017135653A (ja) 試験装置、ネットワークシステム、及び試験方法
US9021078B2 (en) Management method and management system
JP5938495B2 (ja) 根本原因を解析する管理計算機、方法及び計算機システム
US20120254406A1 (en) Computer system management method and management apparatus
WO2015019488A1 (ja) 管理システム及びその管理システムによるイベント解析方法
JP2015114952A (ja) ネットワークシステム、監視制御装置およびソフトウェア検証方法
US8533331B1 (en) Method and apparatus for preventing concurrency violation among resources
WO2013103008A1 (ja) 事象の原因を特定する情報システム、コンピュータ及び方法
JP2015056082A (ja) 障害情報収集装置、障害情報収集方法、及び、障害情報収集プログラム
WO2017017707A1 (ja) 情報処理装置、エラー処理方法およびエラー処理プログラム
JP2018116446A (ja) 試験装置、試験システム、試験方法およびプログラム

Legal Events

Date Code Title Description
TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20150407

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20150430

R150 Certificate of patent or registration of utility model

Ref document number: 5745077

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

LAPS Cancellation because of no payment of annual fees