JP2023114001A - 運用管理装置及び方法 - Google Patents

Abstract

【課題】有効性の高い対処案を提示し得る信頼性の高い運用管理装置及び方法を提案する。【解決手段】１又は複数の管理対象装置を含むシステム全体の運用を管理する運用管理装置及び当該運用管理装置により実行される運用管理方法であって、管理対象装置の異常を検知してから当該異常が解消するまでの間に当該管理対象装置に対して行われた一連の構成変更の内容をログから抽出して構成変更履歴として記録し、記録した構成変更履歴の内容を一般化した異常対処ルールを生成し、異常を検知した場合に、適用可能な異常対処ルールを利用して１又は複数の対処案を生成し、生成した対処案をユーザに提示するようにした。【選択図】 図１４

Description

本発明は運用管理装置及び方法に関し、１又は複数の装置の運用を管理する運用管理装置に適用して好適なものである。

従来、管理装置として、管理対象システムや装置の異常を検知したときに、その異常の対処方法を提示し得るようになされたものがある。このような管理装置として、例えば特許文献１には、問題発生時に根本原因の分析技術を利用し、各種の異常に対する対処方法を規定した汎用ルールから対象となる機器に適用した対処方法に展開させた展開ルールを作成し、作成した展開ルールに基づく対処方法の効果を予測して、複数の対処案を提案することが開示されている。

しかしながら、この特許文献１に開示された技術によると、管理装置が提示可能な対処案が汎用ルールや展開ルールに記載の障害に対する対処案のみに固定され、管理装置の運用中に新たな対処案の追加ができないという問題があった。

このような問題点について、特許文献２には、管理装置において、異常検知ルール及び対処ルールの組合せと、計算機システムとの関係を示すラベルに基づいて対処ルールを絞り込み、絞り込んだ対処ルールをその計算機システムに適用した場合のシミュレーションを実行し、シミュレーション結果に基づいて対処ルールを決定することが開示されている。このような方法により発生した異常に対する対処案を運用中に動的に提案することが可能となる。

米国特許出願公開第２０１４／００６８３４３号明細書 特願２０２０－１７５３４０

しかしながら、特許文献２に記載の技術で実行される上述のシミュレーションでは、対処ルールを実際の装置に適用する際の実際の変化をすべて予測することが難しいため、対処ルールを計算機システムに適用した際のシミュレーション結果だけに基づいて現実の装置異常に対する対処ルールの有効性確認が困難な問題があった。

本発明は以上の点を考慮してなされたもので、有効性の高い対処案を提示し得る信頼性の高い運用管理装置及び方法を提案しようとするものである。

かかる課題を解決するため本発明においては、１又は複数の管理対象装置を含むシステム全体の運用を管理する運用管理装置において、前記管理対象装置の異常を検知する異常検知部と、前記異常検知部が前記管理対象装置の前記異常を検知してから当該異常が解消するまでの間に当該管理対象装置に対して行われた一連の構成変更の内容をログから抽出して構成変更履歴として記録する構成変更抽出部と、前記構成変抽出部により記録された前記構成変更履歴の内容を一般化した異常対処ルールを生成する異常対処ルール生成部と、前記異常検知部が新たな異常を検知した場合に、適用可能な前記異常対処ルールを利用して１又は複数の対処案を生成し、生成した前記対処案をユーザに提示する対処案提示部とを設けるようにした。

また本発明においては、１又は複数の管理対象装置を含むシステム全体の運用を管理する運用管理装置により実行される運用管理方法であって、前記管理対象装置の前記異常を検知してから当該異常が解消するまでの間に当該管理対象装置に対して行われた一連の構成変更の内容をログから抽出して構成変更履歴として記録する第１のステップと、記録した前記構成変更履歴の内容を一般化した異常対処ルールを生成する第２のステップと、異常を検知した場合に、適用可能な前記異常対処ルールを利用して１又は複数の対処案を生成し、生成した前記対処案をユーザに提示する第３のステップとを設けるようにした。

本発明の運用管理装置及び方法によれば、過去の異常発生時に行われ、それによって異常が解消した一連の構成変更に基づいて今回の異常に対する対処案を生成して提示することができる。

本発明によれば、有効性の高い対処案を提示し得る信頼性の高い運用管理装置及び方法を実現できる。

本実施の形態による計算機システムの全体構成を示すブロック図である。 運用管理装置の全体構成を示すブロック図である。 管理対象管理表の構成例を示す図表である。 組織内管理装置管理表の構成例を示す図表である。 装置構成管理表の構成例を示す図表である。 稼動情報管理表の構成例を示す図表である。 ログ管理表の構成例を示す図表である。 異常判定ルール管理表の構成例を示す図表である。 構成変更履歴管理表の構成例を示す図表である。 異常対処ルール管理表の構成例を示す図表である。 構成変更操作管理表の構成例を示す図表である。 構成変更コスト管理表の構成例を示す図表である。 対処案評価関数管理表の構成例を示す図表である。 異常対処及び異常対処ルール生成処理の処理手順を示すフローチャートである。 装置情報収集処理の処理手順を示すフローチャートである。 異常検知処理の処理手順を示すフローチャートである。 異常対処ルール生成処理の処理手順を示すフローチャートである。 異常対処処理の処理手順を示すフローチャートである。 （Ａ）及び（Ｂ）は、それぞれ対処案候補の生成手法の説明に供する図及び図表である。 生成された３つの対処案候補の詳細例を示す図表である。 生成された３つの対処案候補の異常改善指標化値、所要時間指標化値及び変更コスト指標化値の一例を示す図表である。 構成変更処理の処理手順を示すフローチャートである。

以下図面について、本発明の一実施の形態を詳述する。

（１）本実施の形態による計算機システムの構成
図１において、１は全体として本実施の形態による計算機システムを示す。この計算機システム１は、複数の組織２と、これらの組織２とネットワーク３を介してそれぞれ接続された運用管理装置４とを備えて構成される。

各組織２は、それぞれ会社内又はデータセンタ等に設置された管理対象の１若しくは複数のストレージ装置５Ａの集合体、又は、管理対象の１若しくは複数のストレージ装置５Ａ及び１若しくは複数の情報機器５Ｂの集合体である。情報機器５Ｂは、サーバ装置、スイッチ機器又はＩｏＴ（Internet of Things）機器などから構成される。なお、以下においては、管理対象のストレージ装置５Ａ及び情報機器５Ｂをまとめて管理対象装置５と呼ぶものとする。

また一部の組織２には、その組織２に属する管理対象装置５を管理する組織内管理装置６が設けられている。実際上、組織内管理装置６は、所属する組織２内の各管理対象装置５から構成情報や稼動情報を定期的に収集したり、運用管理装置４からの指示に応じて、指定された管理対象装置５内にボリュームを作成し又は指定された管理対象装置５内のボリュームを削除するなどの管理業務を行う。

運用管理装置４は、計算機システム１全体の運用を管理するコンピュータ装置であり、図２に示すように、ＣＰＵ（Central Processing Unit）１０、メモリ１１、記憶装置１２、通信装置１３、入力装置１４及び表示装置１５を備えて構成される。

ＣＰＵ１０は、運用管理装置４全体の動作を制御するプロセッサである。またメモリ１１は、例えば揮発性の半導体メモリから構成され、ＣＰＵ１０のワークメモリとして利用される。さらに記憶装置１２は、例えば、ハードディスク装置やＳＳＤ（Solid State Drive）などの大容量の不揮発性の記憶装置から構成され、各種プログラムや長期間保存が必要な各種データが格納される。

運用管理装置４の起動時や必要時に必要なプログラムが記憶装置１２からメモリ１１に読み出され、メモリ１１に読み出されたプログラムをＣＰＵ１０が実行することにより、後述のような運用管理装置４全体としての各種処理が実行される。

通信装置１３は、ＮＩＣ（Network Interface Card）などから構成され、運用管理装置４がネットワーク３（図１）を介して計算機システム１内の他の装置等と通信を行う際のプロトコル制御を行う。

入力装置１４は、例えばキーボードやマウスなどから構成され、ユーザが必要な情報や指示を運用管理装置４に入力する際に利用される。また表示装置１５は、例えば液晶ディスプレイや有機ＥＬ（Electro Luminescence）ディスプレイなどから構成され、必要な画面や情報を表示するために利用される。なお、入力装置１４及び表示装置１５が一体化したタッチパネルを適用するようにしてもよい。

（２）異常時対処案提示及び実行機能
次に、本実施の形態の運用管理装置４に搭載された異常時対処案提示及び実行機能について説明する。この異常時対処案提示及び実行機能は、管理対象装置５の異常を検出してからその異常を解消するまでの間にその管理対象装置５に対して行われた対処（一連の構成変更）の内容を構成変更履歴として記録し、記録した構成変更履歴に基づいてそのとき実行された対処（一連の構成変更）の内容を一般化した異常対処ルールを生成し、その後に新たな異常が発生した場合に、適用可能な異常対処ルールを利用して１又は複数の対処案の候補（以下、これを対処案候補と呼ぶ）を生成してユーザに提示し、提示した対処案候補の中からユーザが選択した対処案候補を実行する機能である。

このような異常時対処案提示及び実行機能を実現するための手段として、運用管理装置４の記憶装置１２には、管理対象管理表２０、組織内管理装置管理表２１、装置構成管理表２２、稼動情報管理表２３、ログ管理表２４、異常判定ルール管理表２５、構成変更履歴管理表２６、異常対処ルール管理表２７、構成変更操作管理表２８、構成変更コスト管理表２９及び対処案評価関数管理表３０が格納されている。また運用管理装置４のメモリ１１には、装置情報収集プログラム３１、異常検知プログラム３２、対処案提示プログラム３３、構成変更抽出プログラム３６、異常対処ルール生成プログラム３７、構成変更実行プログラム３４及びログ収集プログラム３５が格納されている。

管理対象管理表２０は、運用管理装置４や各組織２の組織内管理装置６が管理する計算機システム１内のすべて管理対象装置５が予め登録されたテーブルであり、図３に示すように、管理装置ＩＤ欄２０Ａ、装置ＩＤ欄２０Ｂ、装置モデル欄２０Ｃ及び組織ＩＤ欄２０Ｄを備えて構成される。管理対象管理表２０では、１つのレコード（行）が１つの管理対象装置５に対応する。

そして装置ＩＤ欄２０Ｂには、対応する管理対象装置５に付与されたその管理対象装置５に固有の識別子（装置ＩＤ）が格納され、装置モデル欄２０Ｃには、その管理対象装置５のモデル名が格納される。また組織ＩＤ欄２０Ｄには、その管理対象装置５が所属する組織２の識別子（組織ＩＤ）が格納され、管理システムＩＤ欄２０Ａには、その管理対象装置５の運用を管理する運用管理装置４又は組織内管理装置６の識別子（管理装置ＩＤ）が格納される。

従って、図３の例の場合、「装置１」という装置ＩＤが付与された管理対象装置５は「Mode 1」という装置モデルの装置であり、「１」という組織２に所属し、「運用管理装置」という管理装置ＩＤが付与された管理装置（運用管理装置４又は組織内管理装置６）に管理されていることが示されている。

また組織内管理装置管理表２１は、計算機システム１内に存在する各組織内管理装置６を管理するために利用されるテーブルであり、これらの組織内管理装置６にアクセスするために必要な情報が格納される。具体的に、組織内管理装置管理表２１は、図４に示すように、管理装置ＩＤ欄２１Ａ、接続エンドポイント欄２１Ｂ及び認証情報欄２１Ｃを備えて構成される。組織内管理装置管理表２１では、１つのレコード（行）が計算機システム１内に存在する１つの組織内管理装置６に対応する。

そして管理装置ＩＤ欄２１Ａには、対応する組織内管理装置６に付与されたその組織内管理装置６に固有の識別子（管理装置ＩＤ）が格納される。また接続エンドポイント欄２１Ｃには、その組織内管理装置６のネットワーク３（図１）上のアドレスが格納され、認証情報欄２１Ｃには、その組織内管理装置６が運用管理装置４を識別するためのアクセストークン等の認証情報が格納される。

従って、図４の例の場合、例えば「１」という管理装置ＩＤが付与されたレコードは、「組織内管理装置１」という組織内管理装置６のアドレスが「https://endpoint1.example」であり、その組織内管理装置６における運用管理装置４の認証情報が「UPYx%HzfQNX@Lm^#J9rL3*bD&B6ZBEy42^vwcf6n$@tzGXLRPx」であることが示されている。

装置構成管理表２２は、運用管理装置４が各管理対象装置５から直接的に又は対応する組織内管理装置６を介して間接的に取得した各管理対象装置５の構成情報を管理するために利用されるテーブルであり、図５に示すように、装置ＩＤ欄２２Ａ、リソース種別欄２２Ｂ、リソースＩＤ欄２２Ｃ、関連リソース欄２２Ｄ、スペック欄２２Ｅ及び容量コスト欄２２Ｆを備えて構成される。

そして装置構成管理表２２には、計算機システム１内の各管理対象装置５にそれぞれ対応させて装置ＩＤ欄２２Ａが設けられており、これらの装置ＩＤ欄２２Ａ内にそれぞれ対応する管理対象装置５の装置ＩＤが格納される。

また装置構成管理表２２には、各管理対象装置５がそれぞれ備えるＣＰＵ、プール、ボリューム及びＮＩＣなどの各種リソースのリソース種別にそれぞれ対応させてリソース種別欄２２Ｂが設けられており、これらのリソース種別欄２２Ｂ内に、それぞれ対応するリソース種別の名称が格納される。

さらに各リソース種別欄２２Ｂにそれぞれ対応するリソースＩＤ欄２２Ｃは、対応する管理対象装置５が備える対応するリソース種別の各リソースにそれぞれ対応させて区分（例えば、ＣＰＵが２つある場合には２つに区分され、ＣＰＵが３つある場合には３つに区分）されており、これら区分されたリソースＩＤ欄２２Ｃ内に、対応するリソースに付与されたそのリソースに固有の識別子（リソースＩＤ）が格納される。

また関連リソース欄２２Ｄは、各リソースＩＤ欄２２Ｃにそれぞれ対応させて設けられ、対応するリソースＩＤ欄２２ＣにリソースＩＤが格納されたリソースと関連するすべてのリソースのリソースＩＤがそれぞれ格納される。例えば、リソース種別が「プール」である場合、その「プール」に含まれるすべてのボリュームの識別子（ボリュームＩＤ）が関連リソース欄２２Ｄに格納され、逆にリソース種別が「ボリューム」である場合には、その「ボリューム」を含むプールのプールＩＤが関連リソース欄２２Ｄに格納される。

さらにスペック欄２２Ｅ及び容量コスト欄２２Ｆは、対応する管理対象装置５の各リソースＩＤ欄２２Ｃにそれぞれ対応付けて設けられる。そしてスペック欄２２Ｅには、対応するリソースＩＤ欄２２ＣにリソースＩＤが格納されたリソースのスペックが格納され、容量コスト欄２２Ｆには、そのリソースが記憶領域又は記憶装置である場合に、単位容量（１ＧＢ）当たりのコストが格納される。

従って、図５の例の場合、例えば「装置１」という装置ＩＤが付与された管理対象装置５の「Pool1」という「プール」の関連リソースは「Volume1」、「Volume2」及び「Volume3」であり（つまり「Pool1」に「Volume1」、「Volume2」及び「Volume3」という３つのボリュームを含んでおり）、かかる「プール」の容量は「1TB」で容量コストが「$1/GB」であることが示されている。

稼動情報管理表２３は、運用管理装置４が各管理対象装置５から直接的に又は組織内管理装置６を介して間接的に取得した各管理対象装置５の稼動情報を管理するために利用されるテーブルであり、図６に示すように、装置ＩＤ欄２３Ａ、リソース種別欄２３Ｂ、リソースＩＤ欄２３Ｃ、メトリック欄２３Ｄ、日時欄２３Ｅ及び数値欄２３Ｆを備えて構成される。

そして稼動情報管理表２３には、計算機システム１内の各管理対象装置５にそれぞれ対応させて装置ＩＤ欄２２Ａが設けられており、これら装置ＩＤ欄２３Ａ内にそれぞれ対応する管理対象装置５の装置ＩＤが格納される。

また稼動情報管理表２３には、各管理対象装置５がそれぞれ備えるＣＰＵ、プール、ボリューム及びＮＩＣなどの各種リソースのリソース種別にそれぞれ対応させてリソース種別欄２３Ｂが設けられており、これらのリソース種別欄２３Ｂ内にそれぞれ対応するリソース種別の名称が格納される。

さらに各リソース種別欄２３Ｂにそれぞれ対応するリソースＩＤ欄２３Ｃは、対応する管理対象装置５が備える対応するリソース種別の各リソースにそれぞれ対応させて区分されており、これら区分されたリソースＩＤ欄２３Ｃ内に、対応するリソースのリソースＩＤが格納される。

またメトリック欄２３Ｄは、各リソースＩＤ欄２３Ｃにそれぞれ対応させて設けられている。そして、これらのメトリック欄２３Ｄには、対応するリソースのメトリックの種別が格納される。また日時欄２３Ｅ及び数値欄２３Ｆは、対応する管理対象装置５の対応するメトリックを取得した日時にそれぞれ対応させて設けられる。そして、日時欄２３Ｅには、対応する管理対象装置５や組織内管理装置６からその管理対象装置５の対応するメトリックを取得した日時が格納され、数値欄２３Ｆには、その日時に取得した対応するメトリックの値が格納される。

従って、図６の例の場合、例えば「装置１」という装置ＩＤが付与された管理対象装置５の「ＣＰＵ１」という「ＣＰＵ」の「ＣＰＵ利用率」は、「2021/09/26 10:00:00」の時点では「40％」、「2021/09/26 10:05:00」の時点では「30％」であったことが示されている。

ログ管理表２４は、管理対象装置５に対して行われた構成変更に関するログのログ情報を保持しておくために利用されるテーブルであり、図７に示すように、日時欄２４Ａ、管理装置ＩＤ欄２４Ｂ、構成変更種別欄２４Ｃ及び変更詳細欄２４Ｄを備えて構成される。ログ管理表２４では、１つのレコード（行）が管理対象装置５に対して行われた１つの構成変更に対応する。

そして日時欄２４Ａには、対応する構成変更を開始した日時が格納される。また管理装置ＩＤ欄２４Ｂには、異常が発生した管理対象装置５を管理する管理装置（運用管理装置４又は組織内管理装置６）の管理装置ＩＤが格納され、変更種別欄２４Ｃには、対応する異常に対して実行された構成変更の種別（構成変更種別）が格納される。さらに変更詳細欄２４Ｄには、対応する構成変更が行われた管理対象装置５と、その管理対象装置５内の構成変更が行われた箇所となどの情報が変更詳細として格納される。

従って、図７の例の場合、例えば「運用管理装置」が管理する「装置１」という管理対象装置５について、その管理対象装置５の「Drive1」というハードディスク装置やＳＳＤなどの記憶装置が提供する記憶領域から「Parity Group5」というパリティグループを新たに作成する「Parity Group作成」という構成変更種別の構成変更が「2020/08/07 10:15:00」に行われたことが示されている。

また図７では、その後、その管理対象装置５（「装置１」）について、「Volume3」というボリュームを、上述のように新たに作成した「Parity Group5」というパリティグループに移動させる「VolumeをParity Group間で移動」という構成変更種別の構成変更が「2020/08/07 10:30:00」に行われたことが示されている。

異常判定ルール管理表２５は、計算機システム１内の各管理対象装置５が異常であるか否かを判定するための予め定められた各種ルール（以下、これらを異常判定ルールと呼ぶ）が登録されたテーブルであり、図８に示すように、ルールＩＤ欄２５Ａ、異常個所欄２５Ｂ、異常判定ルール欄２５Ｃ及び異常レベル欄２５Ｄを備えて構成される。異常判定ルール管理表２５では、１つのレコード（行）が１つの異常判定ルールに対応する。

そしてルールＩＤ欄２５Ａには、対応する異常判定ルールに対して付与されたその異常判定ルールに固有の識別子（ルールＩＤ）が格納され、異常個所欄２５Ｂには、その異常判定ルールにより異常の有無の判定対象となる管理対象装置５内の箇所が格納される。

また異常判定ルール欄２５Ｃには、対応する異常判定ルールが格納され、異常レベル欄２５Ｄには、その異常判定ルールにより対応箇所が異常と判定された場合におけるその対応箇所の異常の度合（以下、これを異常レベルと呼ぶ）が格納される。なお異常レベルとしては、その対応箇所に重大な異常がある「Critical」と、警告程度の異常がある「Warning」となどがある。

従って、図８の例の場合、例えば「１」というルールＩＤが付与された異常判定ルールは、「ＣＰＵ平均利用率＞90％（ＣＰＵの平均利用率が90％よりも大きい）」場合に「ＣＰＵ」に「Critical」レベルの異常が発生していると判断できることが示されている。

構成変更履歴管理表２６は、計算機システム１内で発生した異常に対する対処として過去に行われた構成変更をログ管理表２４（図７）から抽出して保持するために利用されるテーブルであり、図９に示すように、ＩＤ欄２６Ａ、装置ＩＤ欄２６Ｂ、装置モデル欄２６Ｃ、異常判定ルール欄２６Ｄ、異常箇所欄２６Ｅ、日時欄２６Ｆ、管理装置ＩＤ欄２６Ｇ、操作種別欄２６Ｈ、操作対象欄２６Ｉを備えて構成される。構成変更履歴管理表２６では、１つのレコード（行）が、過去に発生した異常に対する対処として行われた一連の構成変更の履歴（以下、これを構成変更履歴と呼ぶ）に対応する。

そしてＩＤ欄２６Ａには、ログ管理表２４（図７）から抽出された対応する構成変更履歴に対して構成変更履歴管理表２６において付与されたその構成変更履歴に固有の識別子が格納される。また装置ＩＤ欄２６Ｂには、対応する構成変更が行われた管理対象装置５の装置ＩＤが格納され、装置モデル欄２６Ｃには、その管理対象装置５の装置モデルの名称が格納される。

異常判定ルール欄２６Ｄには、そのとき異常と判定するのに利用された異常判定ルールが格納され、異常箇所欄２６Ｅには、その異常判定ルールにより異常と判定された対応する管理対象装置５の異常箇所が格納される。また日時欄２６Ｆには、対応する構成変更が開始された日時が格納され、管理装置ＩＤ欄２６Ｇには、その構成変更の操作を行った管理装置（運用管理装置４又は組織内管理装置６）の管理装置ＩＤが格納される。

さらに操作種別欄２６Ｈには、その構成変更の操作種別が格納される。この種の操作種別としては、ボリュームを同一ストレージ装置内の他のプールに移動したり、他のストレージ装置に移動する「Volume Migration」や、データを圧縮すると共に重複するデータを排除する「圧縮・重複排除」、ドライブを追加することにより特定のプールの容量を増加させる「プール拡張（ドライブ追加）」、あるボリュームにポートを割り当てる「Port割当て」、及び、パリティグループを追加する「Parity Group追加」などがある。

操作対象欄２６Ｉは、変更元対象欄２６ＩＡ及び変更先対象欄２６ＩＢに区分されている。そして変更元対象欄２６ＩＡには、構成変更の変更元に関する情報が格納され、変更先対象欄２６ＩＢには、構成変更の変更先に関する情報が格納される。例えば、操作種別が「Volume Migration」の場合、変更元対象欄２６ＩＡには、移動元のボリュームのボリュームＩＤ及びそのボリュームが対応付けられたプールのプールＩＤが格納され、変更先対象欄２６ＩＢには、移動先として作成されたボリュームが対応付けられたプールのプールＩＤが格納される。

従って、図９の例の場合、例えば「１」というＩＤが付与された構成変更履歴は、「Model1」という装置モデルの「装置１」という管理対象装置５の「Pool1」に「Pool利用率＞80％」という異常判定ルールに合致する異常が検知され、この異常に対して、「2021/09/01 10:00:00」に「運用管理装置」が「Pool1」と対応付けられた「Volume1」に格納されたデータを、同一ストレージ装置５Ａ内の「Pool2」というプールに対応付けられたボリュームを作成してそのボリュームに移行させる「Volume Migration」という操作を行うことにより対処したことが示されている。

異常対処ルール管理表２７は、構成変更履歴管理表２６に格納された各構成変更履歴の内容（構成変更の内容）を一般化したものを異常対処ルールとして管理するために利用されるテーブルであり、図１０に示すように、ＩＤ欄２７Ａ、装置モデル欄２７Ｂ、異常判定ルール欄２７Ｃ、異常箇所欄２７Ｄ、管理装置種別欄２７Ｅ、操作種別欄２７Ｆ及び変更対象欄２７Ｇを備えて構成される。異常対処ルール管理表２７では、１つのレコード（行）が、１つの異常対処ルールに対応する。

そしてＩＤ欄２７Ａには、異常対処ルール管理表２７において対応する異常対処ルールに付与されたその異常対処ルールに固有の識別子（異常対処ルールＩＤ）が格納され、装置モデル欄２７Ｂには、対応する構成変更が行われた管理対象装置５の装置モデルが格納される。

また異常判定ルール欄２７Ｃには、かかる管理対象装置５の異常を検知した際に利用された異常判定ルールが格納され、異常箇所欄２７Ｄには、その異常判定ルールによりその異常が検知された対応する管理対象装置５の箇所（異常箇所）が格納される。

さらに操作種別欄２７Ｆには、かかる異常を解消するために行われた構成変更の操作種別が格納され、管理装置ＩＤ欄２７Ｅには、その操作種別の操作を行った管理装置（運用管理装置４又は組織内管理装置６）の種別（運用管理装置又は組織内管理装置）が格納される。

変更対象欄２７Ｇは、変更元対象欄２７ＧＡ及び変更先対象欄２７ＧＢに区分されている。そして変更元対象欄２７ＧＡには、対応する構成変更において変更元となったリソースを一般化した情報が格納され、変更先対象欄２７ＧＢには、その構成変更において変更先となったリソースを一般化した情報が格納される。

従って、図１０の例の場合、例えば「１」というＩＤが付与された異常対処ルールは、「Model1」という装置モデルの装置の「特定のPool」に「Pool利用率＞80%」という異常判定ルールに合致する異常が検知され、この異常に対する対処として、「運用管理装置」の操作のもとに、「特定のPoolにあるVolume」を「特定のPool以外のPool」に移動させる「Volume Migration」を実行することでその異常が解消したという異常対処ルールであることが示されている。

構成変更操作管理表２８は、予め定義された構成変更種別ごとの構成変更操作の内容（変更対象及び変更所要時間と、変更元及び変更先の選定基準など）が登録されたテーブルであり、図１１に示すように、操作ＩＤ欄２８Ａ、管理装置種別欄２８Ｂ、構成変更種別欄２８Ｃ、変更対象欄２８Ｄ、変更所要時間欄２８Ｅ及び選定基準欄２８Ｆを備えて構成される。構成変更操作管理表２８では、１つのレコード（行）が１つの構成変更種別の構成変更を行うための具体的な構成変更操作に対応する。

そして操作ＩＤ欄２８Ａには、構成変更操作管理表２８において対応する構成変更操作に対して付与された識別子（操作ＩＤ）が格納され、管理装置ＩＤ欄２８Ｂには、その構成変更操作を行うべき管理装置（運用管理装置４又は組織内管理装置６）の管理装置種別が格納される。また構成変更種別欄２８Ｃには、対応する構成変更種別の名称が格納される。

変更対象欄２８Ｄは、変更元対象欄２８ＤＡ及び変更先対象欄２８ＤＢに区分されており、変更元対象欄２８ＤＡに、対応する構成変更種別の構成変更を行う際の変更元の対象（以下、これを変更元対象と呼ぶ）が格納され、変更先対象欄２８ＤＢに変更先の対象（以下、これを変更先対象と呼ぶ）が格納される。

さらに変更所要時間欄２８Ｅには、対応する構成変更種別の構成変更に要する一般的な時間が格納され、選定基準欄２８Ｆには、変更元対象や変更先対象の選定基準が格納される。なお、選定基準については、必ずしも事前に定義しておく必要はなく、運用中の更新や操作履歴等に応じて動的に作成又は更新するようにしてもよい。

従って、図１１の例の場合、例えば「１」という操作ＩＤが付与された構成変更操作は、「運用管理装置」の制御の下に行われる「Volume Migration」という構成変更種別の構成変更に関する操作であり、「Volume Migration」は、対象となる「Volume」が対応付けられた「Pool」を移動させる操作を行う構成変更で（対象が「Volume」、移動元及び移動先が「Pool」）、所要時間は「Volume容量」に応じて「2mins/GB」程度であり、「容量が大きい」Volumeを対象Volume、「利用率が高い」Poolを移動元のPool、「利用率が低い」Poolを移動先のPoolとすべきことが定義されていることが示されている。

構成変更コスト管理表２９は、構成変更種別ごとの構成変更に要するコスト（以下、これを変更コストと呼ぶ）が予め登録されたテーブルであり、図１２に示すように、管理装置種別欄２９Ａ、構成変更種別欄２９Ｂ及び変更コスト欄２９Ｃを備えて構成される。構成変更コスト管理表２９では、１つのレコード（行）が１つの構成変更種別に対応する。

そして構成変更種別欄２９Ｂには、対応する構成変更種別の名称が格納され、管理装置種別欄２９Ａには、その構成変更種別の構成変更操作を行う管理装置（運用管理装置４又は組織内管理装置６）の名称が格納される。また変更コスト欄２９Ｃには、対応する変更種別の構成変更を行う際に要するコスト（変更コスト）を算出するための演算式が格納される。

従って、図１２の例の場合、「Volume Migration」は、運用管理装置４の制御のもとに行われ、変更コストが移動元及び移動先間でのビット単価（１ビットのデータを記憶するために要するコスト）の差分と、移動対象のボリュームの容量との乗算結果として算出できると定義されていることが示されている。

対処案評価関数管理表３０は、異常対処ルール管理表２７に登録されている同一又は類似の異常対処ルールを利用して生成された今回の異常に対する対処案候補を評価するための各種評価関数が格納されたテーブルである。

本実施の形態の場合、対処案候補の評価は、その対処案候補の対処を実行した場合における異常の改善率（以下、これを異常改善率と呼ぶ）と、その対処案候補の対処を実行するのに要する時間（以下、これを所要時間と呼ぶ）と、その対処案候補の対処を実行するのに要する変更コストとの３つの評価基準に基づいて行う。

異常改善率は、シミュレーションにより算出し、所要時間は、構成変更操作管理表２８（図１１）の対応する変更所要時間欄２８Ｅ（図１１）に格納された所要時間を利用して算出する。また変更コストは、構成変更コスト管理表２９（図１２）の対応する変更コスト欄２９Ｃ（図１２）に格納された演算式を利用して算出する。

そして本実施の形態においては、算出したこれら異常改善率、所要時間及び変更コストの値をそれぞれ－１～０又は０～１の範囲の値にそれぞれ指標化し、指標化したこれら異常改善率、所要時間及び変更コストの値を利用して各対処案候補を評価し、これら対処案候補と共にその評価結果をユーザに提示する。

対処案評価関数管理表３０は、このように異常改善率、所要時間及び変更コストの値を指標化するための演算式がそれぞれ評価関数として予め格納されたテーブルであり、図１３に示すように、評価基準欄３０Ａ及び評価関数欄３０Ｂを備えて構成される。対処案評価関数管理表３０では、１つのレコード（行）が１つの評価基準（異常改善率、所要時間又は変更コスト）に対応する。

そして評価基準欄３０Ａには、対応する評価基準の名称が格納され、評価関数欄３０Ｂには、その評価基準を算出するための評価関数が格納される。

従って、図１３の例の場合、異常改善率の評価関数は、次式

であり、所要時間の評価関数は、次式

であり、変更コストの評価関数は、次式

であることが示されている。

一方、装置情報収集プログラム３１は、各管理対象装置５の構成情報及び稼動情報を直接的又はその管理対象装置５と同じ組織２内の組織内管理装置６を介して間接的に収集する機能を有するプログラムである。装置情報収集プログラム３１は、収集した各管理対象装置５の構成情報を装置構成管理表２２（図５）に格納すると共に、収集した各管理対象装置５の稼動情報を稼動情報管理表２３（図６）に格納する。

また異常検知プログラム３２は、稼動情報管理表２３に格納された各管理対象装置５の稼動情報と、異常判定ルール管理表２５（図８）に格納された異常判定ルールとに基づいて各管理対象装置５に発生した異常を検知する機能を有するプログラムである。異常検知プログラム３２は、いずれかの管理対象装置５の異常を検知した場合、その旨を対処案提示プログラム３３に通知する。

対処案提示プログラム３３は、今回の異常に対する幾つかの対処案候補を生成してユーザに提示する機能を有するプログラムである。実際上、対処案提示プログラム３３は、異常検知プログラム３２が検知した異常に適用可能な異常対処ルールを異常対処ルール管理表２７（図１０）上で検索し、かかる検索により検出した異常対処ルールに基づいて、今回の異常に対する１又は複数の対処案候補を生成する。また対処案提示プログラム３３は、生成した対処案候補を今回の異常に対する対処案としてユーザに提示する。

この際、対処案提示プログラム３３は、各対処案候補について、その対処案候補の対処を実行したときの異常改善率、所要時間及び変更コストをシミュレーション等により算出する。そして対処案提示プログラム３３は、算出した各対処案候補の異常改善率、所要時間及び変更コストに基づいて各対処案候補を順位付けし、各対処案候補をその順位と共にユーザに提示する。

構成変更実行プログラム３４は、対処案提示プログラム３３が提示した対処案候補のうちのユーザにより選択された対処案候補を実行するようにして、異常が発生した管理対象装置５の構成を変更する構成変更処理を実行する機能を有するプログラムである。構成変更実行プログラム３４は、実行した構成変更処理の内容をログ管理表２４（図７）に記録すると共に、実行した構成変更処理の内容に応じて装置構成管理表２２を更新する。

またログ収集プログラム３５は、構成変更実行プログラム３４がログ管理表２４に記録できない構成変更（例えば、その組織内管理装置６をユーザが操作するなどしてその組織内管理装置６が所属する組織２内の各管理対象装置５に対して行われた構成変更）に関するログのログ情報を各組織内管理装置６からそれぞれ収集する機能を有するプログラムである。ログ収集プログラム３５は、収集したログ情報をログ管理表２４に格納する。

構成変更抽出プログラム３６は、構成変更操作管理表２８（図１１）を参照して、異常の発生からその解消までの間にその異常を解消するために当該異常が発生した管理対象装置５に対して行われた構成変更に関するログのログ情報をログ管理表２４から抽出する機能を有するプログラムである。構成変更抽出プログラム３６は、抽出したログ情報に含まれる各種情報及びその他必要な情報を構成変更履歴として構成変更履歴管理表２６（図９）に記録する。

異常対処ルール生成プログラム３７は、構成変更履歴管理表２６に格納された各構成変更履歴の内容を一般化した異常対処ルールを生成して異常対処ルール管理表２７（図１０）に記録する機能を有するプログラムである。上述のように対処案提示プログラム３３は、この異常対処ルール管理表２７に記録された異常対処ルールに基づいて、今回の異常に対する幾つかの対処案候補を生成する。

（３）異常時対処機能に関連して実行される各種処理
次に、かかる異常時対処機能に関連して運用管理装置４において実行される一連の処理（以下、これを異常対処及び異常対処ルール生成処理と呼ぶ）の内容について説明する。なお、以下においては、各種処理の処理主体を「プログラム」として説明するが、実際上は、そのプログラムに基づいて運用管理装置４のＣＰＵ１０（図２）がその処理を実行することは言うまでもない。

（３－１）異常対処及び異常対処ルール生成処理の流れ
図１４は、かかる異常対処及び異常対処ルール生成処理の流れを示す。この異常対処及び異常対処ルール生成処理は、運用管理装置４の電源が投入されると開始され、まず、装置情報収集プログラム３１（図２）が、計算機システム１内に存在するすべての管理対象装置５の構成情報及び稼動情報を直接的又は間接的にそれぞれ収集し、収集した構成情報及び稼動情報を装置構成管理表２２（図５）や稼動情報管理表２３（図６）に記録する装置情報収集処理を実行する（Ｓ１）。

次いで、異常検知プログラム３２（図２）が、稼動情報管理表２３に格納された各管理対象装置５の稼動情報と、異常判定ルール管理表２５（図８）に格納された各異常判定ルールとに基づいていずれかの管理対象装置５に発生した異常を検知する異常検知処理を実行する（Ｓ２）。

この後、異常検知プログラム３２が、これまでに検知したいずれかの異常が解消したか否かを判断する（Ｓ３）。そして、この判断で否定結果が得られた場合には、処理がステップＳ５に進む。

これに対して、ステップＳ３で肯定結果が得られた場合には、異常対処ルール生成プログラム３７（図２）が、解消した異常に関し、その異常が発生してから解消するまでにその異常を解消するために対応する管理対象装置５に対して行われた一連の構成変更を一般化したものを、その異常に対する異常対処ルールとして生成して異常対処ルール管理表２７（図１０）に格納する異常対処ルール生成処理を実行する（Ｓ４）。

続いて、異常検知プログラム３２が、ステップＳ２の異常検知処理で異常を検知したか否かを判断する（Ｓ５）。そして、この判断で否定結果が得られた場合には、処理がステップＳ１に戻り、この後ステップＳ１以降が上述と同様に繰り返し処理される。

これに対して、ステップＳ５の判断で肯定結果が得られた場合には、異常対処ルール管理表２７に格納された異常対処ルールに基づいて、ステップＳ２で検知した異常に対する１又は複数の対処案候補を生成してユーザに提示し、提示した対処案候補の中からユーザが選択した対処案候補に基づく対処処理を実行する一連の異常対処処理が対処案提示プログラム３３及び構成変更実行プログラム３４により実行される（Ｓ６）。この後、処理がステップＳ１に戻り、これ以降、ステップＳ１以降の処理が上述と同様に繰り返される。

（３－１－２）装置情報収集処理
図１５は、図１４について上述した異常対処及び異常対処ルール生成処理のステップＳ１において装置情報収集プログラム３１により実行される装置情報収集処理の具体的な処理内容を示す。この装置情報収集処理は、異常対処及び異常対処ルール生成処理のステップＳ２に処理が進むと開始され、まず、装置情報収集プログラム３１（図２）が、管理対象管理表２０（図３）から管理対象装置５の一覧を取得する（Ｓ１０）。

続いて、装置情報収集プログラム３１は、ステップＳ１０で取得した一覧に含まれる各管理対象装置５から直接的に又は対応する組織内管理装置６（図１）を介して間接的にその管理対象装置５の構成情報及び稼動情報をそれぞれ取得する（Ｓ１１）。

そして装置情報収集プログラム３１は、取得した各管理対象装置５の構成情報を装置構成管理表２２（図５）に記録すると共に、取得した各管理対象装置５の稼動情報を稼動情報管理表２３（図６）にそれぞれ記録し（Ｓ１２）、この後、異常検知プログラム３２（図２）を呼び出した後に（Ｓ１３）、この装置情報収集処理を終了する。

（３－１－３）異常検知処理
図１６は、上述の装置情報収集処理のステップＳ１３で装置情報収集プログラム３１により呼び出された異常検知プログラム３２により異常対処及び異常対処ルール生成処理のステップＳ２において実行される異常検知処理の具体的な処理内容を示す。

異常検知プログラム３２は、装置情報収集プログラム３１により呼び出されるとこの異常検知処理を開始し、まず、管理対象管理表２０（図３）から管理対象装置５の一覧を取得する（Ｓ２０）。

続いて、異常検知プログラム３２は、稼動情報管理表２３から各管理対象装置５の稼動情報をそれぞれ取得し（Ｓ２１）、さらに異常判定ルール管理表２５（図６）からすべての異常判定ルールを取得する（Ｓ２２）。

次いで、異常検知プログラム３２は、ステップＳ２１で取得した各管理対象装置５の稼動情報と、ステップＳ２２で取得した各異常判定ルールとに基づいて、異常が発生している管理対象装置５及びその異常をすべて検出する（Ｓ２３）。

具体的に、異常検知プログラム３２は、ステップＳ２２で取得した異常判定ルールの中から１つの未処理の異常判定ルールを選択し、その異常判定ルールと各管理対象装置５の稼動情報とを順次比較することにより、その異常判定ルールに基づいて異常が発生していると判定可能な管理対象装置５があるか否かを順次判断する。そして、この判断により異常が発生していると判定可能な管理対象装置５と、その異常とをすべて抽出する。

また異常検知プログラム３２は、残りの他の異常判定ルールについても、同様にしてその異常判定ルールに基づいて異常が発生していると判定可能な管理対象装置５があるか否かを判断する。そして、この判断により異常が発生していると判定された管理対象装置５と、その異常とをすべて抽出する。

そして異常検知プログラム３２は、各異常判定ルール及び各管理対象装置５のすべての組合せについて異常の有無の判定を完了し終えると、この異常検知処理を終了する。

（３－１－４）異常対処ルール生成処理
図１７は、図１４について上述した異常対処及び異常対処ルール生成処理のステップＳ４で実行される異常対処ルール生成処理の具体的な処理内容を示す。

異常対処及び異常対処ルール生成処理のステップＳ３で肯定結果が得られると、この異常対処ルール生成処理が開始され、まず、異常検知プログラム３２が、異常対処及び異常対処ルール生成処理のステップＳ３で解消を検知した異常に関する情報を異常情報として構成変更抽出プログラム３６（図２）に通知する（Ｓ３０）。

具体的に、異常検知プログラム３２は、その異常が発生した日時と、その異常が発生した管理対象装置５の装置ＩＤと、その管理対象装置５を管理している管理装置（運用管理装置４又は組織内管理装置６）の管理装置ＩＤと、その異常を検出した際に利用した異常判定ルールと、異常が発生した箇所（異常箇所）となどの情報を異常情報として構成変更抽出プログラム３６に通知する。

続いて、構成変更抽出プログラム３６が、構成変更操作管理表２８（図１１）を参照して、異常情報が通知された異常が発生してからその異常が解消されるまでの間にその異常を解消するために対応する管理対象装置５に対して行われたすべての構成変更に関するログをログ管理表２４（図７）から抽出する（Ｓ３１）。例えば、構成変更抽出プログラム３６は、異常が検知された時刻から異常が解消された時刻までのログを抽出する。

また、他の手法として、構成変更抽出プログラム３６に、各異常判定ルールに対して、その異常判定ルールにより検出される異常に対して通常実行される対処（一連の構成変更）を対応付けた図示しない異常判定ルール－対処対応表を持たせる方法も考えられる。例えば、「Parity Group利用率＞80％」という異常判定ルールにより検出される異常については、その異常を解消するため、新たなパリティグループを追加する「Parity Group追加」という構成変更と、異常が検出されたパリティグループのボリュームを新たなパリティグループに移動させる「VolumeをParity Groupに移動」という構成変更とが順番に行われる（図７参照）。このため、かかる異常判定ルール－対処対応表では、「Parity Group利用率＞80％」という異常判定ルールに対して「Parity Group追加」及び「VolumeをParity Groupに移動」という構成変更からなる対処が対応付けられている。

なお、例えば、プール利用率が閾値よりも高いという異常に対しては、そのプールに対応付けられているボリュームを他のプールに移動させるボリュームマイグレーション（「Volume Migration」）する対処と、そのプール内のデータを重複排除及び圧縮する対処（「重複排除＆圧縮」）と、そのプールの容量を追加する対処（「プール拡張」）とがある。このため異常判定ルール－対処対応表では、１つの異常判定ルールに対して複数の対処（一連の構成変更）が対応付けられている場合があり、例えば、「Pool利用率＞80%」という異常判定ルールに対しては、「Volume Migration」、「重複排除＆圧縮」及び「プール拡張」という３つの対処が対応付けられている。

かくして、この場合に構成変更抽出プログラム３６は、ステップＳ３２において、ステップＳ３１で異常検知プログラム３２から通知された異常情報に含まれる異常発生の日時と、その異常を検知する際に利用した異常判定ルールとに基づき、まず、異常の発生日時で検索範囲を決定（異常発生日時以降の範囲に決定）し、この後、異常判定ルール－対処対応表を参照して、決定した検索範囲内のログであって、かかる異常情報に含まれる異常判定ルールに対応付けられた対処（一連の構成変更）と合致するすべての構成変更にそれぞれ対応するログを抽出するようにして、必要なすべてのログをログ管理表２４から抽出する。

次いで、構成変更抽出プログラム３６は、抽出したこれらのログの情報と、ステップＳ３１で異常検知プログラム３２から通知された異常情報とに基づいて、その異常情報に対応する異常の構成変更履歴を生成し、生成した構成変更履歴を構成変更履歴管理表２６に格納する（Ｓ３２）。また構成変更抽出プログラム３６は、構成変更履歴管理表２６を更新した旨を、ステップＳ３１で受領した異常情報と共に異常対処ルール生成プログラム３７に通知する（Ｓ３３）。

異常対処ルール生成プログラム３７は、かかる通知を受領すると、異常情報に含まれる異常が発生した管理対象装置５の構成情報を装置構成管理表２２（図５）から取得する（Ｓ３４）。

また異常対処ルール生成プログラム３７は、ステップＳ３４で取得した構成情報に基づいて、ステップＳ３２で構成変更履歴管理表２６に格納した構成変更履歴のレコードにおける異常箇所欄２６Ｅに格納された異常箇所と、操作対象欄２６Ｉに格納された変更元対象や変更先対象との関係性を抽出する（Ｓ３５）。なお、ここでの「関係性」とは、かかる異常箇所と、かかる変更元対象や変更先対象との間の接続関係（例えばボリューム及びポート間の接続関係）や、親子関係（例えばプール及びボリューム間の親子関係）、関連性（例えばプール及びパリティグループ間の関連性）、及び、変更先対象が新しいリソースであるかといった情報を含む。

続いて、異常対処ルール生成プログラム３７は、ステップＳ３２で構成変更履歴管理表２６に記録した構成変更履歴のうち、装置モデル、異常判定ルール、異常箇所、管理装置ＩＤ及び操作種別の各情報を、それぞれ異常対処ルール管理表２７（図１０）の装置モデル欄２７Ｂ、異常判定ルール欄２７Ｃ、異常箇所欄２７Ｄ、管理装置種別欄２７Ｅ及び操作種別欄２７Ｆに格納すると共に、ステップＳ３５で取得した異常箇所と変更元対象との関係性を変更元対象欄２７ＧＡに格納し、さらに異常箇所と変更先対象との関係性を変更先対象欄２７ＧＢに格納する（Ｓ３６）。これにより、ステップＳ３２で構成変更履歴管理表２６に記録した構成変更履歴に対応する異常対処ルールが異常対処ルール管理表２７に格納され、この後、この異常対処ルール生成処理が終了する。

（３－１－５）異常対処処理
図１８は、図１４について上述した異常対処及び異常対処ルール生成処理のステップＳ６において実行される異常対処処理の具体的な処理内容を示す。この異常対処処理は、異常対処及び異常対処ルール生成処理のステップＳ６に処理が進むと開始され、まず、異常検知プログラム３２が、異常対処及び異常対処ルール生成処理のステップＳ２の異常検知処理で検知したすべての異常を対処案提示プログラム３３（図２）に通知する（Ｓ４０）。

続いて、対処案提示プログラム３３が、異常検知プログラム３２から通知された異常ごとに、その異常の対処案として適用可能な異常対処ルールを異常対処ルール管理表２７（図１１）上で検索する（Ｓ４１）。なお、ここでの「適用可能な異常対処ルール」とは、その異常が検出された管理対象装置５と装置モデルが一致し、さらに異常箇所及びその異常箇所の異常抽出に利用された異常判定ルールが一致する異常対処ルールを指す。

次いで、対処案提示プログラム３３は、ステップＳ４１の検索で適用可能な異常対処ルールを検出できたか否かを判断する（Ｓ４２）。そして対処案提示プログラム３３は、この判断で否定結果を得ると、異常を検出したが、その異常の対処案候補を提示できない旨のメッセージを表示装置１５（図２）に表示し（Ｓ５０）、この後、この異常対処処理を終了する。

これに対して、対処案提示プログラム３３は、ステップＳ４２の判断で肯定結果を得ると、装置構成管理表２２（図４）を参照して、ステップＳ４１で検出した各異常対処ルールをそれぞれ今回の異常に適用するに際して操作対象となる変更元対象及び変更先対象をそれぞれ選定することにより、対処案候補をそれぞれ生成する（Ｓ４３）。

例えば、ステップＳ４０で異常検知プログラム３２から対処案提示プログラム３３に通知された異常の内容が、図１９（Ａ）に示すように、「Pool利用率＞80％」という異常判定ルールに合致し、異常箇所が「Pool1」、該当装置（異常が検知された管理対象装置５）が「装置１」であり、ステップＳ４１で対処案提示プログラム３３が異常対処ルール管理表２７から検出した異常対処ルールが、図１９（Ｂ）に示すように、異常対処ルール管理表２７において「１」という異常対処ルールＩＤが付与された異常対処ルールであったものとする。

この場合、対処案提示プログラム３３は、図１９（Ｂ）の異常対処ルール管理表２７の変更対象欄２８Ｇに格納された変更元対象及び変更先対象と、装置構成管理表２２（図５）に格納された該当する管理対象装置５（ここでは「装置１」）のリース構成とに基づいて、該当する「変更元対象」のリソースを検索する。図１９（Ｂ）及び図５の例では、この検索により「Pool1」に対応付けられた「Volume1」、「Volume2」、「Volume3」が検出される。また対処案提示プログラム３３は、該当する「変更先対象」のリソースも併せて検索する。ここでは、この検索により「Pool2」及び「Pool3」が検出されたものとする。

そして対処案提示プログラム３３は、上述の検索により該当する「変更元対象」のリソースを複数検出した場合には、事前に定義されている構成変更操作管理表２８（図１１）の選定基準欄２８Ｆ（図１１）に格納された選定基準に従って「変更元対象」を選定する。例えば、図１１のように「Volume Migration」という変更種別における対象Volumeの選定基準が「Volume容量が大きい」であり、図５のように「装置１」という管理対象装置５における「Volume1」の容量が「10GB」、「Volume2」の容量が「20GB」、「Volume3」の容量が「30GB」である場合には、容量が一番大きい「Volume3」が「変更元対象」として選定される。

また対処案提示プログラム３３は、上述の検索により該当する「変更先対象」のリソースを複数検出した場合には、事前に定義されている構成変更操作管理表２８の選定基準に従って「変更元対象」を選定する。例えば、図１１のように「Volume Migration」という変更種別における移動先の選定基準が「Pool利用率が低い」であり、仮に「装置１」の「Pool2」というプールの利用率が「10％」、「Pool3」というプールの容量が「30％」である場合には、一番利用率が低い「Pool2」が「変更先対象」として選定される。従って、この場合には、図２０において「１」という対処案候補ＩＤが付与された対処案候補（操作種別が「Volume Migration」、変更元対象の移動元が「Pool1」、対象が「Pool1にあるVolume3」で、移動先が「Pool2」）が生成される。

なお図２０は、同じ装置モデルの管理対象装置５について、同じ装置モデルの同じ異常判定ルールに基づいて検知された同じ異常箇所の異常を、データの重複排除及び圧縮（「重複排除＆圧縮」）を行うことにより解消した異常対処ルールや、プール容量の拡張（「プール拡張」）により解消した異常対処ルールがあり、これらに基づいて「２」という対処案候補ＩＤの対処案候補や、「３」という対処案候補ＩＤの対処案候補も生成された場合の例を示している。

図１８の説明に戻って、対処案提示プログラム３３は、ステップＳ４３においてすべての対処案候補を生成後、生成した対処案候補ごとに、その対処案候補に従った構成変更を行った場合におけるシミュレーションを実行し、その構成変更を行った場合の異常改善率をそれぞれ算出する（Ｓ４４）。

なお、ここでの「異常改善率」とは、今回の異常が合致した異常判定ルールにおける対象となるリソースの次式

で算出される状態（利用率等）の改善率を示す。例えば、今回の異常が「Pool利用率＞80％」という異常判定ルールに合致していたためにその異常が検知された場合であって、異常検知時におけるPool利用率が82％、対処案候補の構成変更を行ったときのPool利用率のシミュレーション結果が41％であったときには、次式

のように異常改善率が0.5と算出される。

続いて、対処案提示プログラム３３は、ステップＳ４４で算出した各対処案候補の異常改善率に基づいて、これら対処案候補の中に実行可能な対処案候補が含まれているか否かを判断する（Ｓ４５）。「実施可能」か否かの判断は、異常改善率に基づいて行うことができ、例えば、すべての対処案候補のシミュレーション結果が予め設定された閾値未満であった場合などには、実行可能な対処案候補が含まれていないと判断することができる。

そして対処案提示プログラム３３は、このステップＳ４５の判断で否定結果を得ると（つまり実行可能な対処案候補がなかった場合には）、異常を検出したが、その異常の対処案候補を提示できない旨のメッセージを表示装置１５（図２）に表示し（Ｓ５０）、この後、この異常対処処理を終了する。

これに対して、対処案提示プログラム３３は、ステップＳ４５で肯定結果を得ると、実行可能と判断した各対処案候補について、その対処案候補の構成変更を行うために必要な所要時間及び変更コストをそれぞれ算出する（Ｓ４６）。具体的に、対処案提示プログラム３３は、所要時間については、構成変更操作管理表２８（図１１）の対応する変更所要時間欄２８Ｅ（図１１）に格納された変更所要時間を参照して算出し、変更コストについては、構成変更コスト管理表２９（図１２）の対応する変更コスト欄２９Ｃ（図１２）に格納された変更コストを参照して算出する。

例えば、ステップＳ４５で実行可能と判断された対処案候補が図２０のような３種類であり、Volume3の容量が30GBである場合、対処案提示プログラム３３は、図２０において対処案候補ＩＤが「１」の対処案候補については、構成変更操作管理表２８における構成変更種別欄２８Ｃ（図１１）に格納された変更種別が「Volume Migration」であるレコードの変更所要時間欄２８Ｅに格納された単位容量当たりの所要時間を利用して、次式

により所要時間を60分と算出する。

また対処案提示プログラム３３は、かかる対処案候補の変更コストについては、構成変更コスト管理表２９（図１２）における構成変更種別欄２９Ｂ（図１２）に格納された構成変更種別が「Volume Migration」であるレコードの変更コスト欄２９Ｃ（図１２）に格納された演算式（ビット単価の差分×ボリューム容量）を利用して、例えばPool1の単価が$1/GB、Pool2の単価が$1.5/GBである場合、次式

により$15と算出する。

一方、対処案提示プログラム３３は、図２０において対処案候補ＩＤが「２」の対処案候補については、Volume1に格納されたデータが30GB（つまりVolume1に空きがない状態）であるものとして、構成変更操作管理表２８（図１１）における構成変更種別欄２８Ｃ（図１１）に格納された構成変更種別が「圧縮・重複排除」である操作ＩＤが「５」のレコードの変更所要時間欄２８Ｅに格納された単位データ量当たりの所要時間を利用して、次式

により所要時間を30分と算出する。

また対処案提示プログラム３３は、かかる対処案候補の変更コストについては、構成変更コスト管理表２９における構成変更種別欄２９Ｂに格納された構成変更種別が「圧縮・重複排除」であるレコードの変更コスト欄２９Ｃに格納された演算式（ビット単価×データ減少容量）を利用して、重複排除及び圧縮処理によるVolume1のデータ減少容量を10GBとして、次式

により$-10と算出する。

さらに対処案提示プログラム３３は、図２０において対処案候補ＩＤが「３」の対処案候補については、Pool1を100GB拡張するものとして、構成変更操作管理表２８における構成変更種別欄２８Ｃに格納された構成変更種別が「プール拡張（ドライブ追加）」である操作ＩＤが「６」のレコードの変更所要時間欄２８Ｅに格納された単位追加容量当たりの所要時間を利用して、次式

により所要時間を100分と算出する。

また対処案提示プログラム３３は、かかる対処案候補の変更コストについては、構成変更コスト管理表２９における構成変更種別欄２９Ｂに格納された構成変更種別が「プール拡張（ドライブ追加）」であるレコードの変更コスト欄２９Ｃに格納された演算式（ビット単価×追加する容量）を利用して、次式

により$100と算出する。

次いで、対処案提示プログラム３３は、上述のようにして算出した各対処案候補の異常改善率、所要時間及び更新コストをそれぞれ利用してこれら対処案候補の評価値をそれぞれ算出し、算出した対処案候補ごとの評価値に基づいてこれら対処案候補を順位付けした上で、各対処案候補の異常改善率、所要時間及び変更コストを表示装置１５（図２）に一覧表示する（Ｓ４７）。

具体的に、対処案提示プログラム３３は、まず、異常改善率、所要時間及び変更コストにそれぞれ対応させて対処案評価関数管理表３０に格納された各評価関数を用いてこれら異常改善率、所要時間及び変更コストを指標化する。

例えば、対処案提示プログラム３３は、対処案候補ＩＤが「１」の対処案候補の異常改善率については、上述した（１）式を用いて、次式

のように、その対処案候補の「異常改善率」として「50」、「異常改善率の最小値」として３つの対処案候補の異常改善率のうちの最小値である「25」、「異常改善率の最大値」として３つの対処案候補の異常改善率のうちの最大値である「50」をそれぞれ代入することにより、その異常改善率を指標化した異常改善率指標化値を算出する。また対処案提示プログラム３３は、対処案候補ＩＤが「２」の対処案候補及び対処案候補ＩＤが「３」の対処案候補についても同様にして異常改善率指標化値をそれぞれ算出する。

また対処案提示プログラム３３は、対処案候補ＩＤが「１」の対処案候補の所要時間については、上述した（２）式を用いて、次式

のように、その対処案候補の「所要時間」として「60」、「所要時間の最小値」として３つの対処案候補の所要時間のうちの最小値である「30」、「所要時間の最大値」として３つの対処案候補の所要時間のうちの最大値である「100」をそれぞれ代入することにより、その所要時間を指標化した所要時間指標化値を算出する。また対処案提示プログラム３３は、対処案候補ＩＤが「２」の対処案候補及び対処案候補ＩＤが「３」の対処案候補についても同様にして所要時間指標化値をそれぞれ算出する。

さらに対処案提示プログラム３３は、対処案候補ＩＤが「１」の対処案候補の変更コストについては、上述した（３）式を用いて、次式

のように、その対処案候補の「変更コスト」として「15」、「変更コストの最小値」として３つの対処案候補の変更コストのうちの最小値である「-10」、「変更コストの最大値」として３つの対処案候補の変更コストのうちの最大値である「100」をそれぞれ代入することにより、その変更コストを指標化した変更コスト指標化値を算出する。また対処案提示プログラム３３は、対処案候補ＩＤが「２」の対処案候補及び対処案候補ＩＤが「３」の対処案候補についても同様にして変更コスト指標化値をそれぞれ算出する。

次に、対処案提示プログラム３３は、異常改善率指標化値、所要時間指標化値及び変更コスト指標化値に対してそれぞれ予め設定された重みをそれぞれａ１、ａ２、ａ３として、次式

のようにして各対処案候補の評価値をそれぞれ算出し、算出した対処案候補ごとの評価値に基づいてこれら対処案候補を順位付けする。なお、重みａ１、ａ２、ａ３は、後から変更することもできるものとする。

例えば、ａ１、ａ２及びａ３をそれぞれ0.5、0.3、0.3とし、各対処案候補の異常改善率指標化値、所要時間指標化値及び変更コスト指標化値がそれぞれ図２１に示すような数値であったものとすると、対処案候補ＩＤが「１」の対処案候補の評価値は、次式

のように0.3056…であり、対処案候補ＩＤが「２」の対処案候補の評価値は、次式

のように0.25であり、対処案候補ＩＤが「３」の対処案候補の評価値は、次式

のように－0.6として算出される。

従って、この例の場合、対処案候補ＩＤが「１」の対処案候補の順位が最も高く、次に対処案候補ＩＤが「２」の対処案候補、その次に対処案候補ＩＤが「３」の対処案候補といった順番で順位付けが行われることになる。かくして対処案提示プログラム３３は、このようにして順位付けした各対処案候補の異常改善率、所要時間及び変更コストを順位通りの順番で表示装置１５（図２）に一覧表示する。

続いて、対処案提示プログラム３３は、かかる一覧表示された対処案候補の中からユーザが１つの対処案候補を今回の異常に対する対処として選択すると、その対処案候補（以下、これをユーザ選択対処案候補と呼ぶ）を構成変更処理の実行指示と共に構成変更実行プログラム３４に通知する（Ｓ４８）。ただし、対処案候補において操作対象となる管理対象装置５がいずれかの組織内管理装置６により管理されている場合には、対処案提示プログラム３３は、ユーザ選択対処案候補及び構成変更処理の実行指示をその組織内管理装置６に送信する。

なお、ユーザが所望する対処案候補を選択する際、その対処案候補が２つ以上の操作からなる場合には、これらのすべての操作を実行するか、そのうちの一部の操作のみを実行するかをユーザが選択できるようにしてもよい。このようにすることによって、図１７のステップＳ３１で構成変更抽出プログラム３６が抽出したログに不要なログが含まれていた場合に、そのログに基づいて実行されるおそれがある不要な操作の実行を抑止することができる。

そして、かかるユーザ選択対処案候補及び構成変更処理の実行指示を受領した構成変更実行プログラム３４又は組織内管理装置６は、対処案提示プログラム３３から通知されたユーザ選択対処案候補に従った構成変更を実行する（Ｓ４９）。以上により、この異常対処処理が終了する。

なお上述の異常対処処理のステップＳ４８においてユーザ選択対処案候補及び構成変更処理の実行指示を受領した構成変更実行プログラム３４又は組織内管理装置６の処理（以下、これを構成変更処理と呼ぶ）の流れを図２２に示す。

構成変更実行プログラム３４又は組織内管理装置６は、対処案提示プログラム３３から構成変更処理の実行指示及びユーザ選択対処案候補が与えられると、この図２２に示す構成変更処理を開始し、まず、対処案提示プログラム３３から通知されたユーザ選択対処案候補に従った構成変更処理を実行する（Ｓ６０）。

続いて、構成変更実行プログラム３４は、実行した構成変更処理の内容を表すログを生成し、生成したログをログ管理表２４（図７）に記録する（Ｓ６１）。また構成変更実行プログラム３４は、対応する管理対象装置５の構成変更後の構成に応じて装置構成管理表２２（図５）を更新し（Ｓ６２）、この後、この構成変更処理を終了する。

（４）本実施の形態の効果
以上のように本実施の形態の計算機システム１では、管理対象装置５の異常を検知してから当該異常が解消するまでの間に当該管理対象装置５に対して行われた一連の構成変更のログをログ管理表２４から抽出して構成変更履歴として構成変更履歴管理表２６に記録し、記録した構成変更履歴の内容を一般化した異常対処ルールを生成し、新たな異常を検知した場合に、適用可能な異常対処ルールを利用して１又は複数の対処案候補を生成し、生成した対処案候補をユーザに提示する。

従って、本実施の形態によれば、過去の異常発生時に行われ、それによって異常が解消した一連の構成変更に基づいて今回の異常に対する対処案を生成して提示することができるため、有効性の高い対処案を提示し得る信頼性の高い運用管理装置４を実現することができる。

（５）他の実施の形態
なお上述の実施の形態においては、本実施の形態による異常時対処案提示及び実行機能を１つのコンピュータ装置（運用管理装置４）に搭載するようにした場合について述べたが、本発明はこれに限らず、異常時対処案提示及び実行機能の一部又は全部を分散コンピューティングシステムを構成する複数のコンピュータ装置に分散して搭載するようにしてもよい。

また上述の実施の形態においては、管理対象装置５がストレージ装置５Ａ等である場合について述べたが、本発明はこれに限らず、管理対象装置５がこの他の装置である場合においても本発明を広く適用することができる。

さらに上述の実施の形態においては、組織内管理装置６が設けられた組織２に所属する各管理対象装置５の構成変更に関するログ情報をその組織内管理装置６から収集するログ収集プログラム３５を設けるようにした場合について述べたが、本発明はこれに限らず、各組織内管理装置６が、それぞれ保持するかかるログ情報を定期的に運用管理装置４に送信するようにしてもよい。このようにしても実施の形態の場合と同様に、運用管理装置４のみでは実行できない構成変更操作を含む対処案を生成しユーザに提示することができる。

さらに上述の実施の形態においては、対処案提示プログラム３３が各対処案候補の異常改善率、所要時間及び更新コストをそれぞれ算出し、算出したこれら異常改善率、所要時間及び更新コストに基づいて対処案候補を順位付けしてユーザに提示するようにした場合について述べたが、本発明はこれに限らず、これら異常改善率、所要時間及び更新コストのうちの少なくとも１つに基づいて対処案候補を順位付けするようにしてもよい。

本発明は、１又は複数の管理対象装置を含む計算機システム全体の運用を管理する運用管理装置に広く適用することができる。

１……計算機システム、２……組織、４……運用管理装置、５……管理対象装置、６……組織内管理装置、１０……ＣＰＵ、２０……管理対象管理表、２１……組織内管理装置管理表、２２……装置構成管理表、２３……稼動情報管理表、２４……ログ管理表、２５……異常判定ルール管理表、２６……構成変更履歴管理表、２７……異常対処ルール管理表、２８……構成変更操作管理表、２９……構成変更コスト管理表、３０……対処案評価関数管理表、３１……装置情報収集プログラム、３２……異常検知プログラム、３３……対処案提案プログラム、３４……構成変更実行プログラム、３５……ログ収集プログラム、３６……構成変更抽出プログラム、３７……異常対処ルール生成プログラム。

Claims (12)

1. １又は複数の管理対象装置を含むシステム全体の運用を管理する運用管理装置において、
   前記管理対象装置の異常を検知する異常検知部と、
   前記異常検知部が前記管理対象装置の前記異常を検知してから当該異常が解消するまでの間に当該管理対象装置に対して行われた一連の構成変更の内容をログから抽出して構成変更履歴として記録する構成変更抽出部と、
   前記構成変抽出部により記録された前記構成変更履歴の内容を一般化した異常対処ルールを生成する異常対処ルール生成部と、
   前記異常検知部が新たな異常を検知した場合に、適用可能な前記異常対処ルールを利用して１又は複数の対処案を生成し、生成した前記対処案をユーザに提示する対処案提示部と
   を備えることを特徴とする運用管理装置。
2. 一部の前記管理対象装置を管理する管理装置から当該管理対象装置に対して行われた構成変更のログを収集するログ収集部をさらに備え、
   前記構成変更抽出部は、
   前記管理装置が管理する前記管理対象装置の異常を検知してから当該異常が解消するまでの間に当該異常を解消するために当該管理対象装置に対して行われた一連の構成変更の内容を、前記ログ収集部により収集された前記ログを含むすべての前記ログから抽出して前記構成変更履歴として記録する
   ことを特徴とする請求項１に記載の運用管理装置。
3. 前記構成変更抽出部は、
   前記異常検知部が前記管理対象装置の前記異常を検知してから当該異常が解消するまでの間に当該管理対象装置に対して行われた一連の構成変更の内容のログとして、前記異常が検知された時刻から当該異常が解消された時刻までのすべてのログを抽出する
   ことを特徴とする請求項１に記載の運用管理装置。
4. 前記異常検知部は、
   前記管理対象装置が異常であるか否かを判定するための予め定められた複数の異常判定ルールと、各前記管理対象装置の稼働状態とをそれぞれ比較するようにして前記管理対象装置に発生した異常を検出し、
   前記構成変更抽出部は、
   各前記異常判定ルールに対して、当該異常判定ルールにより検出される各前記異常に対してそれぞれ通常実行される対処を管理し、
   前記異常が発生した日時に基づいて前記異常の発生日時で検索範囲を決定し、決定した検索範囲内の前記ログとして記録された前記構成変更であって、当該異常を検出する際に利用した前記異常判定ルールに対応付けられた対処と合致するすべての前記構成変更を抽出するようにして、前記一連の構成変更の内容を抽出する
   ことを特徴とする請求項１に記載の運用管理装置。
5. 前記異常検知部は、
   前記管理対象装置が異常であるか否かを判定するための予め定められた複数の異常判定ルールと、各前記管理対象装置の稼働状態とをそれぞれ比較するようにして前記管理対象装置に発生した異常を検出し、
   前記異常対処ルール生成部は、
   前記異常が発生した異常箇所と、当該異常に対して行われた前記構成変更における変更元及び変更先との間の関連性を抽出し、抽出した前記関連性と、当該異常箇所と、当該異常が発生した前記管理対象装置の装置モデルと、当該異常を検出する際に利用した前記異常判定ルールとに基づいて前記異常対処ルールを生成する
   ことを特徴とする請求項１に記載の運用管理装置。
6. 対処案提示部は、
   生成した各前記対処案の対処を実行したときの異常改善率、所要時間及び変更コストのうちの少なくとも１つを算出し、算出した前記異常改善率、前記所要時間及び又は前記変更コストに基づいて各前記対処案を順位付けして前記ユーザに提示する
   ことを特徴とする請求項１に記載の運用管理装置。
7. １又は複数の管理対象装置を含むシステム全体の運用を管理する運用管理装置により実行される運用管理方法であって、
   前記管理対象装置の前記異常を検知してから当該異常が解消するまでの間に当該管理対象装置に対して行われた一連の構成変更の内容をログから抽出して構成変更履歴として記録する第１のステップと、
   記録した前記構成変更履歴の内容を一般化した異常対処ルールを生成する第２のステップと、
   異常を検知した場合に、適用可能な前記異常対処ルールを利用して１又は複数の対処案を生成し、生成した前記対処案をユーザに提示する第３のステップと
   を備えることを特徴とする運用管理方法。
8. 前記運用管理装置は、
   一部の前記管理対象装置を管理する管理装置から当該管理対象装置に対して行われた構成変更のログを収集し、
   前記第１のステップでは、
   前記管理装置が管理する前記管理対象装置の異常を検知してから当該異常が解消するまでの間に当該異常を解消するために当該管理対象装置に対して行われた一連の構成変更の内容を、前記ログ収集部により収集された前記ログを含むすべての前記ログから抽出して前記構成変更履歴として記録する
   ことを特徴とする請求項７に記載の運用管理方法。
9. 前記第１のステップにおいて、前記運用管理装置は、
   前記異常検知部が前記管理対象装置の前記異常を検知してから当該異常が解消するまでの間に当該管理対象装置に対して行われた一連の構成変更の内容のログとして、前記異常が検知された時刻から当該異常が解消された時刻までのすべてのログを抽出する
   ことを特徴とする請求項７に記載の運用管理方法。
10. 前記運用管理装置は、
    前記管理対象装置が異常であるか否かを判定するための予め定められた複数の異常判定ルールと、各前記管理対象装置の稼働状態とをそれぞれ比較するようにして前記管理対象装置に発生した異常を検出し、
    前記第１のステップにおいて、前記運用管理装置は、
    各前記異常判定ルールに対して、当該異常判定ルールにより検出される各前記異常に対してそれぞれ通常実行される対処を管理し、
    前記異常が発生した日時に基づいて前記異常の発生日時で検索範囲を決定し、決定した検索範囲内の前記ログとして記録された前記構成変更であって、当該異常を検出する際に利用した前記異常判定ルールに対応付けられた対処と合致するすべての前記構成変更を抽出するようにして、前記一連の構成変更の内容を抽出する
    ことを特徴とする請求項７に記載の運用管理方法。
11. 前記運用管理装置は、
    前記管理対象装置が異常であるか否かを判定するための予め定められた複数の異常判定ルールと、各前記管理対象装置の稼働状態とをそれぞれ比較するようにして前記管理対象装置に発生した異常を検出し、
    前記第２のステップにおいて、前記運用管理装置は、
    前記異常が発生した異常箇所と、当該異常に対して行われた前記構成変更における変更元及び変更先との間の関連性を抽出し、抽出した前記関連性と、当該異常箇所と、当該異常が発生した前記管理対象装置の装置モデルと、当該異常を検出する際に利用した前記異常判定ルールとに基づいて前記異常対処ルールを生成する
    ことを特徴とする請求項７に記載の運用管理方法。
12. 前記第３のステップにおいて、前記運用管理装置は、
    生成した各前記対処案の対処を実行したときの異常改善率、所要時間及び変更コストのうちの少なくとも１つを算出し、算出した前記異常改善率、前記所要時間及び又は前記変更コストに基づいて各前記対処案を順位付けして前記ユーザに提示する
    ことを特徴とする請求項７に記載の運用管理方法。
    

Images