JPWO2015063889A1 - 管理システム、プラン生成方法、およびプラン生成プログラム - Google Patents

Abstract

計算機システムで発生したイベントに対する対処策であるプランを生成する管理システムであって、前記イベントに応じてプランを生成するプラン生成手段と、前記プラン生成手段によって生成されたプランを実行した場合に、前記プランの主体と異なる他主体によって実行される他主体処理により生じる可能性がある、前記計算機システムのリソースの性能変化に関する情報を、前記プランについての性能変化評価指標として生成する指標生成手段と、を有している。

Description

本発明は、例えば、ホストコンピュータ、ネットワークスイッチ、及びストレージ装置等の監視対象装置を含む計算機システムを管理する技術に関する。

一般に計算機システムには、記憶デバイスとして、ＨＤＤ（ハードディスクドライブ）やＳＳＤ（ソリッドステートドライブ）等を用いるストレージ装置が備えられる。そして、そのストレージ装置を含む計算機システムは、ストレージエリアネットワーク（ＳＡＮ：Ｓｔｏｒａｇｅ Ａｒｅａ Ｎｅｔｗｏｒｋ）経由で、複数の上位装置（たとえばホストコンピューター）からアクセスされる。

一般に、ストレージ装置では、ＲＡＩＤ（Ｒｅｄｕｎｄａｎｔ Ａｒｒａｙ ｏｆ Ｉｎｄｅｐｅｎｄｅｎｔ（ｏｒ Ｉｎｅｘｐｅｎｓｉｖｅ） Ｄｉｓｋｓ）技術に従う高信頼化方法が採用されることで、ドライブ単体を超えた耐障害性を持つ記憶領域をストレージ装置において提供している。しかし、近年の情報化社会の進化によって、上記ＲＡＩＤによる耐障害性に基づいたシステムの可用性（サービスの継続性）でも十分でない場合が生じている。

これに対し、リモートコピーまたはリモートミラーリングと呼ばれる技術によりＨｉｇｈ Ａｖａｉｌａｂｉｌｉｔｙ構成が可能である。リモートコピーで同期させたボリュームを異なる複数のストレージ装置にて保持し、ストレーム装置の障害時にパスの切り替えによりアプリケーション処理を継続させる。

また、障害復旧に利用可能なデータ移動技術として、仮想マシン（ＶＭ）の動作環境を物理的なホスト計算機間で引き継がせるＶＭ移動、ＶＭを記憶領域間で移動させるＶＭ利用データ移動、ストレージ装置のボリューム間でＶＭなどのデータを移動させる（ボリュームマイグレーション）といった技術がある。

計算機システムの障害を原因解析により得られた復旧方法（プラン）で障害を復旧させるという手法がある。特許文献２には、汎用ルールと障害の復旧方法とを対応付けて保持しており、障害の原因イベントに基づいて復旧方法を選択する技術が開示されている。

特開平７−２４４５９７号公報 米国特許第８４２９４５３号明細書

システムが冗長化された環境では、可用性を高めるために自動的に起動される処理がある。例えば、Ｈｉｇｈ Ａｖａｉｌａｂｉｌｉｔｙ構成における第一のストレージから第二のストレージへのパス切り替え処理などがそれにあたる。

そのため、自動的に可用性を高める処理など、注目している問題への対処とは別の制御下で処理が計算機システム内で実施されることがある。しかし、上述した特許文献２に開示されたような技術では、計算機システム内で発生した問題に対する対処計画を作成しようとする際に、注目している問題への対処とは別の制御下で実施される処理の影響について考慮されていなかった。

本発明の目的は、計算機システムに発生する問題に対する対処計画の作成において、その対処とは異なる制御下で実施される処理の影響を考慮することを可能にする技術を提供することである。

課題を解決しようとするための手段

本発明の一態様による管理システムは、計算機システムで発生したイベントに対する対処策であるプランを生成する管理システムであって、前記イベントに応じてプランを生成するプラン生成手段と、前記プラン生成手段によって生成されたプランを実行した場合に、前記プランの主体と異なる他主体によって実行される他主体処理により生じる可能性がある、前記計算機システムのリソースの性能変化に関する情報を、前記プランについての性能変化評価指標として生成する指標生成手段と、を有している。

これによれば、計算機システムに発生する問題に対する対処計画の作成において、その対処とは異なる制御下で実施される処理の影響を考慮することが可能になる。

実施例に係る概略を示す図である。 実施例に係る計算機システムの一例の構成図である。 実施例に係る構成情報テーブルの一例の構成図である。 実施例に係る性能情報テーブルの一例の構成図である。 実施例に係る性能変化情報テーブルの一例の構成図である。 実施例に係るプラン情報テーブルの一例の構成図である。 実施例に係るプラン詳細情報テーブルの一例の構成図である。 実施例に係るイベント履歴情報テーブルの一例の構成図である。 実施例に係る他主体処理を加味したプラン生成処理のフローチャートである。 実施例に係る他主体が実行する処理のプランに対する影響を加味する処理のフローチャートである。 実施例に係る他主体処理の発生した場合の性能情報を見積もる処理のフローチャートである。 実施例に係る他主体処理の発生率を算出する処理のフローチャートである。 実施例に係るプラン提示処理のフローチャートである。 実施例に係るプラン提示画面の一例の構成図である。 実施例に係るプラン詳細提示画面の一例の構成図である。 実施例に係るプラン提示処理のフローチャートである。 実施例に係るプラン提示画面の一例の構成図である。

本発明の実施例について説明する。

なお、以下に説明する実施例は、請求の範囲にかかる発明を限定するものではなく、また実施例の中で説明されている諸要素及びその組み合わせの全てが発明の解決に必須であるとは限らない。また図面において複数の図を通じて同一の符号は同一の構成要素を示している。

また、以後、計算機システムを管理し、本発明の表示用情報を表示する一つ以上の計算機の集合を管理システムと呼ぶことがある。管理サーバが表示用情報を表示する場合は管理サーバが管理システムである。また、管理サーバと表示用計算機との組み合わせも管理システムである。また、管理処理の高速化や高信頼化のために複数の計算機で管理サーバと同等の処理を実現してもよく、この場合は当該複数の計算機（表示を表示用計算機が行う場合は表示用計算機も含む）が管理システムである。

なお、以後の説明では「ａａａテーブル」等の表現を用いるが、これらの表現で表される情報はテーブル等のデータ構造以外で表すこともできる。そのため、データ構造に依存しないことを示すために「ａａａテーブル」等について「ａａａ情報」と呼ぶことがある。さらに、各情報の内容を説明する際に、「識別子」、「ＩＤ」という表現を用いるが、これらはお互いに置換が可能である。

以後の説明では「プログラム」を主語として説明を行う場合があるが、プログラムは、プロセッサによって実行されることで、定められた処理をメモリ及び通信ポート（通信デバイス、管理Ｉ／Ｆ、データＩ／Ｆ）を用いながら行うものである。そのため、プロセッサを主語として説明することも可能である。また、プログラムを主語として開示された処理は、管理サーバ等の計算機、情報処理装置が行う処理ということもできる。また、プログラムの一部または全てを実行するプロセッサに代えて専用ハードウェアによって実現することもできる。また、各種プログラムは、プログラム配布サーバや計算機が読み取り可能な記憶メディアによって各計算機にインストールされてもよい。

実施例に係る計算機システムについて説明する。

図１は、本実施例の概略を示す図である。個々の構成要素の説明は後述する。

管理サーバ１０００は、冗長構成における切り替え処理など、対策案であるプランの実行とは別の制御下で動作する他主体処理の設定情報、その設定情報による他主体処理の実行履歴に関する情報、プランを実行した場合に利用されるリソースに対する他主体処理の設定情報が存在するか否かを示す情報、及びシステムの構成／性能の情報を、ストレージ装置２０００及びサーバ３０００から収集する。そして、管理サーバ１０００は、それらの情報を、他主体処理が実行された場合のＩ／Ｏの変化に関する予め保持している情報とあわせて、システム内で発生したイベントへの対処策となるプランを生成するときに、他主体処理を考慮したプランの情報を生成する。

本実施形態の技術を用いることで、例えば、他主体処理である冗長構成における切り替え処理を考慮してプランを導出することが可能となる。システムにおいて、冗長構成が組まれていることは一般的である。そのような冗長構成は一般的なシステムにおける運用管理作業のコスト低減にもつながる。

しかし、冗長構成が採られている場合、通常運用で動作している現用系が壊れなければ、待機系のリソースは利用されないため、リソースの有効活用が阻害されるとも言える。これに対して、本実施形態による技術を利用することで、可用性を重視したために利用していなかった待機系のリソースについて、それを利用した場合にどの程度のリスクがあるかを含めてユーザ（管理者）に提示することも可能となる。ユーザが、そのリスクとリソースの有効活用とを比較考量して、リソースを利用するか否かを判断できるようになり、リソースの有効活用につながる。

図２は、実施例に係る計算機システムの一例の構成図である。本実施例に係る計算機システムは、１台以上の管理サーバ１０００（図２では管理サーバＡ）、１台以上のストレージ装置２０００（図２ではストレージ装置Ａ）、及び１台以上のサーバ３０００（図２ではサーバＡ）を備える。サーバ３０００及びストレージ装置２０００は、ＳＡＮ（Ｓｔｏｒａｇｅ Ａｒｅａ Ｎｅｔｗｏｒｋ）４０００を介して互いに接続される。ＳＡＮの具体例としてファイバチャネルがある。管理サーバ１０００、ストレージ装置２０００、サーバ３０００は、管理用ネットワーク５０００を介して互いに接続される。

管理サーバ１０００は、メモリ１１００、通信デバイス１２００、プロセッサ１３００、出力デバイス１４００、入力デバイス１５００、および記憶デバイス１６００を備え、これらは内部バス１７００を介して互いに接続される。

メモリ１１００は、他主体処理考慮型プラン生成プログラム１１１０、他主体処理考慮型プラン提示プログラム１１２０、他主体処理発生率算出プログラム１１３０、及び構成情報テーブル１１４０、性能情報テーブル１１５０、性能変化情報テーブル１１６０、プラン情報テーブル１１７０、プラン詳細情報テーブル１１８０、イベント履歴情報テーブル１１９０を格納する。

他主体処理考慮型プラン生成プログラム１１１０は、計算機システムで発生するイベントに応じて、その対処策であるプランを生成するプラン生成プログラムである。

他主体処理発生率算出プログラム１１３０は、他主体処理考慮型プラン生成プログラム１１１０によって生成されたプランを実行した場合に、そのプランを実行する主体の制御下で動作する処理を把握していない他の主体（以下「他主体」ともいう）によって実行される処理（以下「他主体処理」ともいう）により生じる可能性がある、計算機システムのリソースの性能変化に関する情報を、そのプランについての性能変化評価指標として生成する指標生成プログラムである。リソースの例として、計算機システムに用いられているディスクドライブ、通信インタフェース、記憶装置などがある。リソースの性能変化に関する情報の具体例が他主体処理発生率である。なお、ここでは必ずしもプランを実行する主体と他主体とが物理的に異なる計算機上に存在することを意味してはおらず、プランを実行する主体と他主体とが物理的に同一の計算機上に存在してもよい。

本実施例によれば、計算機システムに発生する問題に対する対処計画のプラン評価において、その対処とは異なる制御下で実施される可能性のある処理によるリソースの変化の影響を考慮することが可能になる。

他主体処理考慮型プラン提示プログラム１１２０は、例えば、他主体処理考慮型プラン生成プログラム１１１０によって生成されたプランと、他主体処理発生率算出プログラム１１３０によって生成された性能変化評価指標（他主体処理発生率）とを提示する。提示は、例えばディスプレイ画面への表示である。これによれば、計算機システムを管理する管理者は、管理システム１０によって提示されたプランを実行するか否かを、リソースの性能変化の可能性を考慮して判断することが可能となる。

また、他主体処理考慮型プラン提示プログラム１１２０は、性能変化評価指標を、プラン実行に関する他の効果指標と共に提示することにしてもよい。これによれば、管理者は、リソースの性能変化の可能性を含む効果指標から総合的にプランを評価することができる。

上述した他主体処理は、例えば、装置障害あるいは性能変動によって実行される、クラスタにおける冗長パスの切り替え処理、クラスタにおける冗長パス間での負荷分散処理、データ移動処理、のいずれかひとつ、あるいは複数、あるいは全部であってもよい。これによれば、装置障害や性能変動によってクラスタの冗長パスの切り替えが生じた場合に生じるリソースの性能変化を考慮して、プランを評価することができる。

また、上述した性能変化評価指標は、計算機システムに含まれるリソースについて、リソースの性能が変化する可能性を示す情報と、当該性能の変化量を示す情報とを含む。これによれば、管理者は、リソースの性能変化の可能性とその変化量とを考慮して、プランを評価することができる。

また、他主体処理発生率算出プログラム１１３０は、上述したリソースの性能の変化量を、読み出し処理と書き込み処理のそれぞれについて算出することにしてもよい。これによれば、読み出し処理と書き込み処理とで性能変化が異なる場合に、それぞれの変化を考慮してプランを評価することができる。

また、他主体処理発生率算出プログラム１１３０は、リソースの性能の変化量を、他主体処理のタイプとリソースのタイプとに応じて、それぞれに算出することにしてもよい。これによれば、どの他主体処理による影響の可能性があるか、どのリソースへの影響の可能性があるかを考慮してプランを評価することができる。

また、上述したリソースの性能が変化する可能性を示す情報が、計算機システムにおいて収集されたイベント発生の履歴情報に基づいて算出されるイベントの発生頻度に関する情報であってもよい。これによれば、イベントの発生頻度を考慮してプランを評価することができる。

あるいは、リソースの性能が変化する可能性を示す情報が、計算機システムのハードウェア構成と計算機システムにおいて収集された障害履歴情報とに基づいて算出されるハードウェア障害の発生頻度に関する情報であってもよい。これによれば、ハードウェア構成とハードウェア障害の発生頻度を考慮してプランを評価することができる。

また、上述したハードウェア障害の発生頻度というのは、計算機システムのハードウェア構成から算出される故障間隔時間と、障害履歴情報から算出される故障間隔時間と、を用いて算出される値であってもよい。これによれば、ハードウェア構成から想定される故障間隔時間と、過去に実際に発生したハードウェア障害の故障間隔時間とに基づく指標から、プランを評価することができる。

上述した障害履歴情報は、例えば、交替パスソフトウェアが発行するパス障害メッセージと、計算機システム内で発生するイベント情報とから生成されるものである。
また、他主体処理考慮型プラン提示プログラム１１２０は、他主体処理考慮型プラン生成プログラム１１１０によって生成されたプラン（以下「第１のプラン」という）が、他主体処理により性能変化が生じるリソースに影響するならば、他主体処理により性能変化が生じるリソースに影響しないプラン（以下「第２のプラン」という）について、第１のプランの実行後に第２のプランを実行できるか否か判定し、実行できるならば、第１のプランおよび第２のプランの実行を含む一連のプラン（スケジュールプラン）を提示することにしてもよい。これによれば、他主体処理で性能変化するリソースへの影響がある第１のプランを提示するとき、そのリソースへの影響を解消できる第２のプランがあれば、それも含めたスケジュールを提示するので、リソースへの影響とその解消ができるかどうかを考慮してプランの評価を行うことができる。

構成情報テーブル１１４０は、サーバ３０００から、サーバ３０００が使用している論理ボリュームを構成するディスクプールまでのＩ／Ｏ（入出力）経路上に存在する装置及びデバイスを示す情報、すなわちＩ／Ｏ経路上の装置及びデバイスの接続関係を示す情報と、当該接続関係に対する他主体処理の設定を示す情報と、他主体処理における当該Ｉ／Ｏ経路のＡｃｔｉｖｅあるいはＳｔａｎｄｂｙといった役割と、他主体処理の設定におけるリソース占有の有無に関する情報とを格納する。これらの情報を以下「構成情報」という。

性能情報テーブル１１５０は、ＳＡＮ４０００に接続された監視対象の各装置、及び監視対象の装置内の各デバイス（監視対象デバイス）についての性能情報を格納する。性能変化情報テーブル１１６０は、他主体処理の設定内容を示す情報と、他主体処理が実行されることによって、どのように性能が変化するかの情報を格納する。プラン情報テーブル１１７０は、システムで問題が発生した場合などに実施する対策処理の情報を格納する。プラン詳細情報テーブル１１８０は、プラン情報テーブル１１７０に格納された対策処理の情報の詳細を格納する。イベント履歴情報テーブル１１９０は、計算機システム内のどのデバイスにいつイベントが発生し、いつ復旧したかに関する情報を格納する。

通信デバイス１２００は、管理用ネットワーク５０００に接続するためのデバイスである。プロセッサ１３００は、メモリ１１００上に展開されているプログラムを実行する。出力デバイス１４００は、管理サーバ１０００が実行した処理の結果、例えば、他主体処理考慮型プラン提示プログラム１１２０の実行結果等を出力するデバイス、例えばディスプレイ等である。入力デバイス１５００は、管理者が管理サーバ１０００に指示を入力するためのデバイス、例えばキーボード等である。記憶デバイス１６００は、情報を格納するＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）、ＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）等である。

図２に示す例では、各種プログラム及びテーブルは、メモリ１１００に格納されているが、記憶デバイス１６００または他の記憶媒体（図示しない）に格納されても良い。この場合、プロセッサ１３００は、プログラム実行時にメモリ１１００上に対象のプログラムを読みだし、読みだしたプログラムを実行する。また、ストレージ装置２０００のメモリ２１００またはサーバ３０００のメモリ３１００に、前述のプログラム及びテーブルが格納され、ストレージ装置２０００またはサーバ３０００が、格納されたプログラムを実行しても良い。また、他のサーバ３０００またはスイッチ（図示しない）等の他の装置が、前述のプログラム及びテーブルを格納し、格納したプログラムを実行しても良い。

管理サーバ１０００は、管理用ネットワーク５０００を通して、サーバ３０００上で動作するプログラムと通信できる。

ストレージ装置２０００は、メモリ２１００、論理ボリューム提供部２２００、ディスクＩ／Ｆコントローラ２３００、管理Ｉ／Ｆ２４００、プロセッサ２５００、及びディスクＩ／Ｆ２６００を備え、これらは内部バス等の通信路２７００を介して接続される。

メモリ２１００は、ディスクキャッシュ２１１０を有する。また、メモリ２１００は、構成性能情報収集プログラム２１２０を格納する。ディスクキャッシュ２１１０は、情報を一時格納するための記憶領域である。構成性能情報収集プログラム２１２０は、ストレージ装置２０００の管理情報及び性能情報等を管理サーバ１０００との間で送受信するためのプログラムである。

論理ボリューム提供部２２００は、１以上の物理ディスク（図示しない）の記憶領域によって構成されるディスクプール２２２０を備え、ディスクプール２２２０の記憶領域を論理的に分割し、当該論理的に分割された記憶領域を論理ボリューム２２１０として提供する。これによって、当該ストレージ装置２０００外の装置から論理ボリューム２２１０に対するアクセスを可能としている。なお、ディスクプールにはディスクプール番号が付され、論理ボリューム２２１０には論理ボリューム番号が付される。これによって、ストレージ装置２０００は、ディスクプール２２２０及び論理ボリューム２２１０をそれぞれ一意に識別することができる。

図２に示す例では、１つのディスクプール２２２０（ＰＯＯＬ１）が論理的に分割され、１つの論理ボリューム２２１０（ＬＶ１）がストレージ装置２０００外の装置（例えば、サーバ３０００）に提供される。ディスクＩ／Ｆコントローラ２３００は、論理ボリューム提供部２２００に接続するためのインタフェースデバイスである。

管理Ｉ／Ｆ２４００は管理用ネットワーク５０００に接続するためのインタフェースデバイスである。プロセッサ２５００は、メモリ２１００上に展開されたプログラムを実行する。ディスクＩ／Ｆ２６００は、ＳＡＮ４０００に接続するためのインタフェースデバイスである。

図２に示す例では、ストレージ装置２０００は、ディスクＩ／Ｆ（Ｐ１）を備える。図２に示す例では、構成性能情報収集プログラム２１２０は、メモリ２１００に格納されているが、他の記憶装置（図示しない）または、他の記憶媒体（図示しない）に格納されても良い。この場合、プロセッサ２５００は、処理実行時にメモリ２１００上に構成性能情報収集プログラム２１２０を読みだし、読みだした構成性能情報収集プログラム２１２０を実行する。

また、管理サーバ１０００のメモリ１１００に構成性能情報収集プログラム２１２０が格納され、管理サーバ１０００が、その格納された構成性能情報収集プログラム２１２０を実行しても良い。また、他のストレージ装置２０００が、構成性能情報収集プログラム２１２０を格納し、格納した構成性能情報収集プログラム２１２０を実行しても良い。また、論理ボリューム提供部２２００は、１つのディスクプール２２２０の全記憶領域を１つの論理ボリューム２２１０として作成しても良い。また、論理ボリューム提供部２２００は、物理ディスク以外の記憶媒体、例えばフラッシュメモリ等の記憶領域によりディスクプール２２２０を作成しても良い。

サーバ３０００は、メモリ３１００、データＩ／Ｆ３２００、プロセッサ３３００、及び管理Ｉ／Ｆ３４００を備え、これらは内部バス等の通信路３５００を介して互いに接続される。

メモリ３１００は、構成情報収集プログラム３１１０、業務プログラム３１２０、ボリューム管理プログラム３１３０、およびパス管理プログラム３１４０を格納する。

構成性能情報収集プログラム３１１０は、サーバ３０００の管理情報、性能情報等を管理サーバ１０００との間で送受信するためのプログラムである業務プログラム３１２０は、３０００が実行する業務を実現するためのプログラムであり、例えば、ＤＢＭＳ（Ｄａｔａ Ｂａｓｅ Ｍａｎａｇｅｍｅｎｔ Ｓｙｓｔｅｍ）やファイルシステム等である。ボリューム管理プログラム３１３０は、ストレージ装置２０００によって提供される論理ボリューム２２１０をサーバ３０００に割り当てるためのプログラムである。サーバ３０００は、ストレージ装置２０００から提供された論理ボリューム２２１０を用いて、各種業務を実行する。パス管理プログラム３１４０は、サーバ３０００と論理ボリューム２２１０の間のパスの状態を管理し、ボリュームまでのパスの異常を検出した場合には、パスの切り替え処理等をおこなうプログラムである。

図２に示す例では、各種プログラムはメモリ３１００上に格納されているが、他の記憶装置（図示しない）に格納されていても良い。この場合、プロセッサ３３００は、処理実行時にメモリ３１００上の対象のプログラムを読みだし、読みだしたプログラムを実行する。

図２に示す例では、サーバＡとストレージ装置Ａとは、ＳＡＮ４０００を介して互いに接続される。ストレージ装置２０００と物理サーバであるサーバ３０００との間の接続は、ファイバチャネルを介して直接接続されるものに限定されず、１台以上のファイバチャネルスイッチ等のネットワーク機器を介して接続されても良い。また、ストレージ装置２０００とサーバ３０００との間の接続は、データ通信用のネットワークであれば良く、ＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）ネットワークでも良い。

図３は、実施例に係る構成情報テーブルの一例の構成図である。

構成情報テーブル１１４０は、サーバ３０００から当該サーバ３０００に提供された論理ボリューム２２１０を構成するディスクプールまでのＩ／Ｏ経路に関する情報と、当該Ｉ／Ｏ経路の接続関係に対する他主体処理の設定を示す情報、他主体処理の設定における当該Ｉ／Ｏ経路の役割、そして他主体処理の設定におけるリソース占有有無情報から構成される。

構成情報テーブル１１４０は、サーバ４０１、ＶＭ４０２、ドライブ４０３、サーバデータＩ／Ｆ４０４、ストレージ４０５、ストレージデータＩ／Ｆ４０６、論理ボリューム４０７、及びディスクプール４０８、他主体処理設定４０９、他主体処理での役割４１０、リソース占有４１１のフィールドを含む。サーバ４０１には、サーバ３０００を一意に識別するための識別子が格納される。ＶＭ４０２には、サーバ４０１上で動作するＶＭを一意に識別するための識別子が格納される。ドライブ４０３には、サーバ３０００のマウントポイントをサーバ内で一意に識別するための識別子が格納される。サーバデータＩ／Ｆ４０４には、サーバ３０００が、論理ボリューム４０７の識別子によって示される論理ボリューム２２１０にアクセスする際に利用されるサーバ３０００のデータＩ／Ｆ３２００（以下「サーバデータＩ／Ｆ」という場合がある）を一意に識別するための識別子が格納される。ストレージ４０５には、サーバ３０００のアクセス先となるストレージ装置２０００を一意に識別するための識別子が格納される。ストレージデータＩ／Ｆ４０６には、サーバ３０００が、論理ボリューム４０７の識別子によって示される論理ボリューム２２１０にアクセスする際に利用される、ストレージ装置２０００のデータＩ／Ｆ２６００（以下「ストレージデータＩ／Ｆ」という場合がある）を一意に識別するための識別子が格納される。論理ボリューム４０７には、論理ボリューム２２１０を一意に識別するための識別子が格納される。ディスクプール４０８には、論理ボリューム４０７の識別子によって示される論理ボリューム２２１０が作成されているディスクプール２２２０を一意に識別するための識別子が格納される。４０１〜４０８のカラムには、計算機システムから収集した情報を追加すれば良く、一般的などのような手段によっても良い。

他主体処理設定４０９には、４０１から４０８までのカラムによって示されるＩ／Ｏ経路上に設定されている自動実行の他主体処理を一意に識別するための識別子が格納される。他主体処理での役割４１０には、他主体処理設定４０９の設定における、当該Ｉ／Ｏ経路の役割を示す。ここで、役割とは、例えば、クラスタ構成における「Ａｃｔｉｖｅ」パス、か「Ｓｔａｎｄｂｙ」パスかなどのことを指す。４０８〜４１０のカラムにはパス管理プログラム３１４０等の持つ管理情報に基づきエントリが追加される。リソース占有４１１には、他主体処理が設定されている構成のリソースが占有されるかどうかを示す情報が格納される。例では、カラムの値が「占有」の場合、他主体処理が設定されている構成のリソースは占有されて他の処理からは利用できず、カラムの値が「非占有」の場合、他主体処理が設定されている構成のリソースは占有されておらず、他の処理から利用できる。４１１のカラムは例えば、管理者が登録する等して追加されるがこれに限定されない。

ここで、本実施例に係る構成情報テーブル１１４０は、アクセス経路上に存在する装置及びデバイスとして、サーバ３０００、ストレージ装置２０００等があるという情報を含んでいるが、これに限定されない。例えば、構成情報テーブル１１４０は、スイッチ、スイッチのデータＩ／Ｆ等の情報を含んでもよく、また、所定業務用のサーバ３０００上の業務プログラム（ＤＢＭＳ等）の情報、ＶＭのスナップショットを保存するスナップショットボリュームや、クローンを保存するクローンボリューム等を関連付けて格納してもよい。また、構成情報テーブル１１４０は、構成管理操作の履歴情報を保持していてもよく、ｓｙｓｌｏｇ（シスログ）サーバ等と連携して、システム動作を表す詳細なログ情報を保持していてもよい。

図４は、実施例に係る性能情報テーブルの一例の構成図である。

性能情報テーブル１１５０には、計算機システムを構成する装置または装置内のデバイスに関する性能情報、例えば、各ストレージ装置２０００における論理ボリューム２２１０、ディスクプール２２２０等に関する性能情報が格納される。性能情報テーブル１１５０にエントリを追加する手段は、一般的など、どのような手段によっても良い。

性能情報テーブル１１５０は、装置ＩＤ１１５１、デバイスＩＤ１１５２、メトリック１１５３、機器ＯＳ１１５４、性能値１１５５、アラート実行閾値１１５６、閾値種別１１５７、及びＳｔａｔｕｓ１１５８のフィールドを含む。

装置ＩＤ１１５１には、装置を一意に特定する識別子（装置ＩＤ）が格納される。デバイスＩＤ１１５２には、性能情報の取得対象となるデバイスを一意に識別するための識別子（デバイスＩＤ）が格納される。メトリック１１５３には、ＣＰＵ使用率、記憶装置に対する単位時間（例えば、１秒）あたりのＩ／Ｏ回数（ＩＯＰＳ）、リクエストに対するレスポンスの時間等の、性能情報の種類を示す情報が格納される。機器ＯＳ１１５４には、装置ＩＤ１１５１に示された装置ＩＤに対応する装置上で動作するＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）の種別を示すデータが格納される。性能値１１５５には、デバイスＩＤ１１５２によって示されたデバイスの、メトリック１１５３によって示された種類の性能情報の値が、デバイスを含む装置から取得されて格納される。アラート実行閾値１１５６には、管理対象の性能値の正常範囲の上限もしくは下限等の閾値（以下「アラート実行閾値」という）が、ユーザから指定されて格納される。閾値種別１１５７には、アラート実行閾値が正常値の上限であるのか下限であるのかを示すデータが格納される。Ｓｔａｔｕｓ１１５８には、性能値１１５５が正常値であるか異常値であるかを示すデータが格納される。

ここで、図４に示す性能情報テーブル１１５０では、任意の１つの装置の任意の１つのデバイスの任意の１つのメトリックに性能値が１つだけ対応しているが、性能情報テーブル１１５０の各情報を、各装置が保持する情報を取得した時刻と共に格納するようにし、取得した時刻に対応する複数の時点の性能値を履歴情報として保持してもよい。デバイスＩＤ１１５２に示されたデバイスＩＤによって示される、性能情報の取得対象のデバイスとして、ストレージデータＩ／Ｆ、論理ボリューム２２１０、ディスクプール２２２０、ＶＭ（図示しない）をあげたが、これらに限定されず、サーバデータＩ／Ｆや物理ディスク、スイッチやスイッチのポート等でもよい。

また、メトリックの一例として、ＣＰＵ使用率、ＩＯＰＳ、リクエストに対するレスポンスの時間等を示したが、Ｉ／Ｏビジー率、転送レート、スループット、データベース管理ソフトのバッファヒット率や挿入・更新・削除レコード数、Ｗｅｂサーバのレスポンスの時間、ファイルシステムやディスクの空き容量や利用率、入出力データ量、利用時刻、ネットワークインタフェースのエラー回数、バッファのオーバーフロー、及びフレームのエラー等の他の性能指標が用いられてもよい。

また、アラート実行閾値１１５６に格納するアラート実行閾値として、ユーザによって指定された閾値ではなく、例えば、性能情報の履歴情報の平均値等を利用し、ベースライン値との差分値によるアラートを通知する契機となる閾値が採用されてもよい。

図５は、実施例に係る性能変化情報テーブルの一例の構成図である。性能変化情報テーブル１１６０には、システムにおける自動実行処理の設定情報、及び当該処理によってどのように性能が変化するかを示す情報が格納される。本実施例で、性能変化情報テーブル１１６０の情報はあらかじめ他主体処理タイプとリソースタイプ毎に、設定されているものとするが、これに限定されない。

他主体処理タイプ１１６１には、システムにおいて自動実行が設定されている他主体処理のタイプを示す情報が格納される。他主体処理タイプの例として、クラスタの冗長パス切り替え、冗長パス間での負荷分散処理、データ移動などがある。リソースタイプ１１６２には、他主体処理タイプ１１６１の設定において利用されるリソースのタイプを示す情報が格納される。設定１１６３には、他主体処理タイプ１１６１の設定における役割を示す情報が格納される。性能情報１１６４には、設定１１６３における役割を持つ場合に、他主体処理の実行により性能情報がどのようになるかを示す値が格納される。例えば、他主体処理設定がクラスタである場合、リソースタイプがディスクＩ／Ｆで設定が「Ａｃｔｉｖｅ」の場合、「Ａｌｌ」によって全てのＩ／Ｏが当該ディスクＩ／Ｆを経由していることを表す。リソースタイプがディスクＩ／Ｆで、設定（役割）が「Ｓｔａｎｄｂｙ」の場合、「０」によってＩ／Ｏは全く当該ディスクＩ／Ｆを経由しないことを表している。また、リソースタイプが論理ボリュームで設定が「Ｓｔａｎｄｂｙ」の場合、「ｗｒｉｔｅ ｏｎｌｙ」によって、書き込みＩ／Ｏのみが当該ボリュームを経由することを表している。これにより、クラスタ構成でＳｔａｎｄｂｙからＡｃｔｉｖｅになると、ディスクＩ／Ｆについては、Ａｃｔｉｖｅ側を経由していたＩ／Ｏが全てＳｔａｎｄｂｙ側を経由するようにＩ／Ｏ量が変化し、論理ボリュームについては、Ａｃｔｉｖｅ側を経由していた読み出しＩ／Ｏ分がＳｔａｎｄｂｙ側を経由するようにＩ／Ｏ量が変化することが分かる。

図６は、実施例に係るプラン情報テーブルの一例の構成図である。プラン情報テーブル１１７０には、システム内で性能劣化等の問題があった場合の対処策（プラン）のリストが格納される。本テーブルに情報を格納する方法はどのような手段であっても良い。図６はプランがＶＭ利用データ移動の例を示す。プランＩＤ１１７１には、プランを一意に識別するための識別子を格納する。プラン対象の移動対象１１７２には、移動対象となるＶＭを一意に識別するための識別子を格納し、移動元ストレージ１１７３にはＶＭのデータが格納されているストレージを、移動元プール１１７４にはＶＭのデータが格納されているプールを、移動元ボリューム１１７５にはＶＭのデータが格納されているボリュームを、それぞれ一意に識別するための識別子を格納する。

移動先ストレージ１１７６にはＶＭのデータが格納されているストレージを、移動先プール１１７７にはＶＭのデータが格納されているプールを、移動先ボリューム１１７８にはＶＭのデータが格納されているボリュームを、それぞれ一意に識別するための識別子を格納する。本実施例では、ＶＭ利用データ移動のプランの場合を記載しているが、その他の対処策、例えば、ＰＯＯＬへのディスク追加や、ＶＭ移動等でも良い。

図７は、実施例に係るプラン詳細情報テーブルの一例の構成図である。プラン詳細情報テーブル１１８０は、プランＩＤ１１８２には、プランを一意に識別するための識別子を格納する。リソースＩＤ１１８３には、リソースを一意に識別するための識別子を格納する。プラン実行後（ＩＯＰＳ）１１８４には、プランが発生したと仮定した場合に、どの程度の性能になりそうかを見積もった情報を格納する。他主体処理タイプ１１８５には、当該プランにおいて利用するリソースに対して、自動実行設定されている処理のタイプを示す情報が格納される。他主体処理が発生した場合の性能（ＩＯＰＳ）１１８６には、他主体処理が発生したと仮定した場合に、どの程度の性能になりそうかを見積もった情報を格納する。閾値超過フラグ１１８７には、ここで、全てのリソースに対して他主体処理が設定されていない場合であっても、プランにおいて関係するリソースについては、全て見積もりを実施することとしているが、これに限定されない。

図８は、実施例に係るイベント履歴情報テーブルの一例の構成図である。イベント履歴情報テーブル１１９０には、計算機システム内のどのデバイスにどのようなイベントが発生したかを示す情報を管理する。

イベント履歴情報テーブル１１９０は、イベントＩＤ１１９１、発生時刻１１９２、装置ＩＤ１１９３、リソースタイプ１１９４、リソースＩＤ１１９５、発生事象１１９６、影響波及範囲１１９７、回復時刻１１９８のフィールドを含む。イベントＩＤ１１９１には、イベント自身の識別子であるイベントＩＤが格納される。発生時刻１１９２には、イベントが発生した日時を示すデータが格納される。装置ＩＤ１１９３には、イベントが発生した装置の識別子が格納される。リソースタイプ１１９４には、イベントが発生したリソースの種別が格納される。リソースＩＤ１１９５には、イベントが発生したリソースの識別子が格納される。発生事象１１９６には、発生したイベントの内容を示す情報が格納される。影響波及範囲１１９７には、当該イベントに伴って発生したイベントのリソースの種別が格納される。ここで影響波及範囲を出すために、同時刻に発生したイベントを全て、当該イベントに伴って発生したとする、あるいは一般にＲＣＡ（Ｒｏｏｔ Ｃａｕｓｅ Ａｎａｌｙｓｉｓ）と呼ばれる方法等の持つイベント間の関連情報を利用する等しても良く、どのような手段であっても良い。回復時刻１１９８は、当該イベントの発生事象が回復した時刻を示す。ここで、回復時刻には、イベントが発生しなくなったか時刻、あるいは当該リソースＩＤ１１９５で示されるリソースから情報を取得でき、取得情報が閾値超過していないことを確認できた時刻等が格納される。

次に、管理サーバ１０００が実行する各処理について説明する。図９は、他主体処理を加味したプラン生成処理のフローチャートである。本処理は、管理サーバ１０００のプロセッサ１３００がメモリ１１００上に展開された他主体処理考慮型プラン生成プログラム１１１０を実行することによって、実現される。

まず、他主体処理考慮型プラン生成プログラム１１１０は、プラン生成処理を実施する（ステップ３００１）。ステップ３００１は問題に対するプランを生成することができればよく、どのような方法によっても良い。プラン生成処理の結果生成されるプランの情報は、プラン情報テーブル１１７０、及びプラン詳細情報テーブル１１８０に格納され、その一例は、図６のプラン情報テーブル１１７０、及び図７のプラン詳細情報テーブル１１８０のプランＩＤ１１８２、リソースＩＤ１１８３、性能１１８４に示した通りである。

次に、他主体処理考慮型プラン生成プログラム１１１０は、プランに対する他主体処理の影響を加味する処理を実行し（ステップ３００２）、続いて、プラン提示処理を実行し（ステップ３００３）、処理を終了する。

図１０は、プランに対する他主体が実行する処理の影響を加味する処理のフローチャートである。本処理は、管理サーバ１０００のプロセッサ１３００がメモリ１１００上に展開された他主体処理考慮型プラン生成プログラム１１１０を実行することによって、実行される。

まず、他主体処理考慮型プラン生成プログラム１１１０は、図３の構成情報テーブル１１４０を参照し、システム内で設定されている他主体処理の情報を取得する（ステップ３００２１）。本実施例では、サーバＡ上の業務に対して、ストレージ装置Ａの論理ボリュームＬＶ１と、ストレージ装置Ｂの論理ボリュームＬＶ２とでクラスタ構成が組まれている情報を取得する。

次に、プラン実行で利用するリソースと、プランを実行する主体と異なる他主体が実行する処理で利用するリソースをそれぞれ取得する（ステップ３００２２）。具体的にこの処理では、まずプラン詳細情報テーブル１１８０のリソースＩＤ１１８３を取得し、構成情報テーブル１１４０のエントリのうち、他主体処理設定４０９に値が格納されているエントリの各カラムのリソースをプラン実行に関連するリソースとして取得する。

続いて、プランと、他主体処理とでリソースの共用があるか否かを、ステップ３００２２で取得したリソースの重複の有無によって判定する（ステップ３００２３）。ステップ３００２３の判定の結果、リソースの共用が無い場合は処理を終了する。ステップ３００２３の判定の結果、リソースの共用がある場合は、構成情報テーブル１１４０のリソース占有４１１カラムの情報を参照し、リソースを共有する他主体処理が、リソースを占有するか否かを判定する（ステップ３００２４）。他主体処理がリソースを占有する場合は、処理を終了する。他主体処理がリソースを占有しない場合は、他主体処理が発生したと仮定した場合の性能情報の見積もりを実施する（ステップ３００２５）。見積もりの結果と条件を比較し（ステップ３００２６）、性能が条件を満たさない場合、プランを実行した場合に要件を満たさない可能性の高いプランであるとして、図７のプラン詳細情報テーブルの閾値超過フラグ１１８７を、閾値超過を表す状態に変更し（ステップ３００２７）、当該他主体処理の発生率を算出する（ステップ３００２８）。ここでは、閾値超過を表す状態の一例として、閾値超過フラグ１１８７に「Ｙｅｓ」を格納している。性能が条件を満たす場合、フラグをたてずに、当該他主体処理の発生率を算出する（ステップ３００２８）。他主体処理の発生率は、その他主体処理によるリソースの性能が変化する可能性を表している。なお、他主体処理が起動するイベントの発生率もリソースの性能が変化する可能性を表すので、イベント発生履歴情報（イベント履歴情報テーブル１１９０）に基づいて算出されるイベントの発生率（発生頻度）を用いることにしてもよい。

ここで、条件として、例えば性能情報テーブル１１５０に示したアラート実行閾値１１５６などを用いることができる。実行閾値の値は、管理者によって事前に設定された値でも良く、また、システムの過去の平均性能履歴の１．２倍の値を設定するなどして値を算出するなどしても良く、また、システムに要求されるＳＬＡ（Ｓｅｒｖｉｃｅ Ｌｅｖｅｌ Ａｇｒｅｅｍｅｎｔ）などから一定の値を設定しても良く、その方法は問わない。また、本実施例では、性能及び性能要件をプランの判断材料として利用したが、性能以外の指標、例えば容量や信頼性などをプランの判断材料として利用しても良い。

最後に、プラン情報テーブル１１７０及びプラン詳細情報テーブル１１８０の情報を更新する（ステップ３００２９）。

図１１は、他主体処理が発生した場合の性能情報の見積もりを実施する処理のフローチャートである。本処理は、図１０に示したステップ３００２５の詳細を示し、管理サーバ１０００のプロセッサ１３００がメモリ１１００上に展開された他主体処理考慮型プラン生成プログラム１１１０を実行することによって、実行される。この処理により他主体処理による性能の変化量が得られる。

まず、図９のステップ３００１において実施した性能見積もり結果の性能情報を参照する（ステップ２５１）。

次に、図５の性能変化情報テーブル１１６０を参照し、処理が発生した場合に性能がどのように変化するかに関する情報を取得する（ステップ２５２）。

例えば、図５に示した例の場合、他主体処理タイプがクラスタでリソースタイプがディスクＩ／Ｆの場合、ＡｃｔｉｖｅのディスクＩ／ＦにすべてのＩ／Ｏが送られ、他主体処理タイプがクラスタでリソースタイプが論理ボリュームの場合、ＡｃｔｉｖｅのボリュームにすべてのＩ／Ｏが送られ、Ｓｔａｎｄｂｙの論理ボリュームに書き込みのＩ／Ｏが送られることがわかる。そして、取得した情報に基づいて、他主体処理が発生した場合に性能見積もりに変化が発生するかどうかを判定する（ステップ２５３）。

性能見積もりに変化がない場合は、処理を終了する。変化がある場合は、図４の性能情報テーブル１１５０から、他主体処理により利用されるリソースの性能情報を取得する（ステップ２５４）。処理が発生した場合に性能見積もりに発生する変化分、例えば、論理ボリュームの読み出しのＩ／Ｏ（図示しない）を性能値として取得する。続いて、ステップ２５１で取得した見積もり結果の情報とあわせて、他主体処理が発生したと仮定した場合の見積もり値を算出する（ステップ２５５）。ここで、算出する値は、他主体処理がＡｃｔｉｖｅ−Ｓｔａｎｄｂｙ構成のクラスタのような切り替え処理の場合は、性能の変化量が見積もり値となり、負荷分散構成（Ａｃｔｉｖｅ−Ａｃｔｉｖｅ構成）の場合は、性能の変化幅が見積もり値となる。見積もり方法としては、例えば、性能値として、性能情報テーブル１１５０から移動対象ボリューム、移動元プール、及び移動先プールの単位時間当たりのＩ／Ｏ量を取得し、移動対象ボリュームの単位時間当たりのＩ／Ｏ量の値を、移動元プールの単位時間当たりのＩ／Ｏ量から減算し、移動先プールの単位時間当たりのＩ／Ｏ量に加算して、ボリュームマイグレーション実行後の移動元プール及び移動先プールのＩ／Ｏ量を予測するなどしても良い。ここでは、単位時間のＩ／Ｏ量の値を性能値として利用したが、Ｉ／Ｏのレスポンスタイムなどを用いても良い。

図１２は、他主体処理の発生率を算出する処理のフローチャートである。本処理は、図１０に示したステップ３００２８の詳細を示し、管理サーバ１０００のプロセッサ１３００がメモリ１１００上に展開された他主体処理発生率算出プログラム１１３０を実行することによって、開始される。

まず、他主体処理発生率算出プログラム１１３０は、イベント履歴情報テーブル１１９０から他主体処理で利用するリソースの障害履歴情報を取得する。この際、図１０のステップ３００２２で取得したリソースの情報を利用して、障害履歴情報を取得し（ステップ２８１）、複数の履歴情報が存在するか否かを判定する（ステップ２８２）。複数の履歴情報が存在する場合は、当該履歴情報を用いて、処理の発生率を算出する（ステップ２８３）。ここで、同種の影響波及範囲１１９７を持つ履歴情報のみを発生率の算出に利用しても良い。

処理の発生率の求め方としては、例えば、基準値としてＨＷ部品の仕様から算出した故障発生率＜１÷ＭＴＢＦ（Ｍｅａｎ Ｔｉｍｅ Ｂｅｔｗｅｅｎ Ｆａｉｌｕｒｅ）＞を利用し、その基準値と、過去の履歴から算出されたＭＴＢＦ値（履歴値）との両方を用いる等すれば良いが、これに限定されるものではない。基準値と履歴値の両方を用いて処理の発生率を求める方法として、例えば＜１÷（（ＭＴＢＦ（基準値）＋ＭＴＢＦ（履歴値））／２）＞などがある。また、障害履歴が含まれている共有リソースが複数存在する場合、複数のリソースの稼働率を考慮して求めてもよい。たとえば、１−＜１−１／ＭＴＢＦ（第一のリソース）＞×＜１−１／ＭＴＢＦ（第二のリソース）＞などによって、複数リソース分の情報を考慮した故障率を算出することができる。ここで、発生率として、故障率を利用したが、稼働停止率、すなわち＜１−（ＭＴＢＦ／ＭＴＴＲ（Ｍｅａｎ Ｔｉｍｅ Ｔｏ Ｒｅｐａｉｒ）＋ＭＴＢＦ）＞などを用いても良い。

続いて、ステップ２８２の判定において、複数の履歴情報が含まれていない場合は、障害履歴情報テーブルから、他主体処理で利用するリソースと同じリソースタイプ１１９４の障害履歴情報を取得し（ステップ２８４）、複数の履歴情報が存在するか否かを判定する（ステップ２８５）。複数の履歴情報が存在する場合は、収集した履歴情報から発生率を算出し（ステップ２８６）、処理を終了する。複数の履歴情報が存在しない場合は、基準値を発生率として設定する（ステップ２８７）。

障害発生履歴テーブルの発生時刻１１９２、装置ＩＤ１１９３、リソースタイプ１１９４、リソースＩＤ１１９５、発生事象１１９６、回復時刻１１９８については、パス管理プログラム３１４０が発行するパス障害メッセージ、及びストレージ装置２０００が発行するＳＩＭ（Ｓｅｒｖｉｃｅ Ｉｎｆｏｒｍａｔｉｏｎ Ｍｅｓｓａｇｅ）の情報を取得して、管理サーバ１０００の他主体処理考慮型プラン生成プログラム１１１０が取得した値を設定する。また、影響波及範囲１１９７については、一定時刻内に発生したイベントを全て、当該イベントに伴って発生したとして、各イベントのリソースタイプの情報を参照して設定する。障害発生履歴テーブルへの値の設定方法について、これに限定されるものではない。

図１３は、プラン提示処理のフローチャートである。本処理は、図９に示したステップ３００３の詳細であり、管理サーバ１０００のプロセッサ１３００がメモリ１１００上に展開された他主体処理考慮型プラン提示プログラム１１２０を実行することによって、開始される。

まず、ステップ３１で図６のプラン情報テーブル１１７０、及び図７のプラン詳細情報テーブル１１８０に格納したプラン情報を取得する（ステップ３１）。次に、取得したプラン詳細情報テーブル１１８０の情報のうち、他主体処理タイプカラムにエントリがあるかどうかを判定し（ステップ３２）、エントリが存在しない場合、ステップ３４の処理に進む。エントリが存在する場合、プラン性能の信頼度を算出し（ステップ３３）、当該情報、他主体処理が発生した場合の性能１１８６、および閾値超過フラグ１１８７も含めてプランの情報を画面に表示し（ステップ３４）、処理を終了する。

ここで、プラン性能の信頼度は、図１２のフロー３００２８で求めた発生率に基づき算出される。例えば、他主体処理の発生率が０％以上、０．１％未満であれば、信頼度を「Ｈｉｇｈ」に設定し、０．１％以上、１％未満であれば、信頼度を「Ｍｉｄｄｌｅ」に設定し、１％以上であれば、信頼度を「Ｌｏｗ」に設定するなど、他主体処理の発生率に基づき複数レベルの信頼度を設定すればよい。

図１４は、実施例に係るプラン提示画面の一例の構成図である。プラン提示画面９０００は、計算機システムにおいて問題が発生した場合に、管理者が対策を実施する際に参照する情報を表示した画面である。具体的には、プラン提示画面９０００に、問題に対する対策として取り得るプランのリストを示す表示領域９００１と、各プランを実行したと仮定した場合の見積もり性能を正規化した情報を示す表示領域９００２と、プランの見積もりがどの程度変動しにくいかを表す、見積もり性能の信頼度の情報を示す表示領域９００３と、プランの見積もり性能が変動する要因となり得る影響事象の情報を示す表示領域９００４と、プランの詳細を表示する操作のためのプラン詳細ボタン９００５と、プランを実行する操作のためのプラン実行ボタン９００６が表示されている。

表示領域９００１には、プランの情報として、例えば、プランの内容を示す情報、プランを実行するのにかかるコスト、プランの実行に要する時間（すなわち、障害が残り続ける時間であり、「ダウンタイム」ともいう）、プランを実行した場合の見積もり性能情報（「性能ランク」と呼ぶこともある）などが表示される。加えて、性能の信頼度を示す情報と、見積もり性能情報に影響を与える契機となる事象を示す情報が含まれている。

表示領域９００２に示すプランを実行したと仮定した場合の性能情報としては、例えば、図９に示したプラン生成処理のステップ３００１で見積もられ、図７に示したプラン情報テーブル１１７０のプラン対象に格納されたプラン実行した場合の性能の見積もり値、例えば、プラン詳細情報テーブル１１８０のプランを実行した場合の性能１１８４の値が利用される。本実施例では、ＩＯＰＳの見積もり値を性能の優劣に応じて分類し、星型のマークの数によって表現しているが、これ以外の表現、例えば、Ｉ／Ｏのレスポンスタイムの見積もり値が表示されてもよいし、そのほかの性能の見積もり値が表示されてもよい。また、複数の指標の性能の見積もり値が表示されてもよい。

ここで、候補となる複数のプランの表示順序を、プランを実行したと仮定した場合の見積もり値の良いものから順番に並べたり、実行に要する時間の短いものから順番に並べたりする等、プランの特徴に基づいて並べ替えを行えるようにしてもよい。

性能の信頼度（表示領域９００３）として、他主体処理によって影響を受けるか否かの情報を提示する。本実施例では、影響を受ける、すなわち信頼度の低いものを「×Ｌｏｗ」とし、影響を受けない、すなわち信頼度の高いものを「○Ｈｉｇｈ」と示したが、これに限定されるものでなく、どの程度の影響を受けるか、例えばＩＯＰＳの変化量などによって、より多段階の判定指標を表示しても良い。

影響事象（表示領域９００４）として、他主体処理の設定タイプを示す情報を提示する。他主体処理の設定に影響を与えないプランの場合は「−」としてしたが、これに限定されるものではない。

図１５は、実施例に係るプラン詳細提示画面の一例の構成図である。

プラン詳細提示画面９１００は、計算機システムにおいて問題が発生した場合に、管理者が対策を実施する際に参照する情報として、プランの詳細を表示する際に選択され、プラン詳細９００５が押下された場合に、プランについての詳細を表す情報を示す画面である。

具体的には、プランの実行によって影響を受けるリソースを示す表示領域９１０１と、プランの実行が行われる前の性能、すなわち現時点での性能を示す表示領域９１０２と、プランを実行したと仮定した場合の見積もり性能を示す表示領域９１０３と、影響が発生する他主体処理のタイプを示す表示領域９１０４と、他主体処理の発生確率を示す表示領域９１０５と、他主体処理が実行されたと仮定した場合の見積もり性能を示す表示領域９１０６を提示する。

なお、例えば、表示領域９００１において、プラン実行前の性能値及びプラン実行後の性能値の予測値がトレンド情報としてグラフ形式で表示されてもよい。

図１４、図１５は、プラン表示画面の一例であり、プラン実行にかかるコスト、プラン実行に要する時間以外のプランの特徴を表す情報、例えば、プランに関係するリソースを利用している業務であってプラン実行時に影響が波及する可能性のある業務の一覧等が、表示領域９００１にあわせて表示されてもよく、更に他の表示態様が採用されてもよい。

図１６は、プラン提示処理の変形例のフローチャートである。図１３に示したプラン提示処理のうち、３１〜３４については、図１３のものと同一の処理のため、説明を省略する。

ステップ３５では、システム内で実行予定のタスクのスケジュール情報を取得する。ここで、スケジュール情報については、あるプランを実行した後に他のプランを実行するというようにスケジュール化された一連のプランを示す情報であり、管理者の手入力あるいは管理サーバ１０００上のプログラムによって生成され、システム内で保持される（図示しない）。次に、スケジュールされているタスクを実行した場合の性能見積もりを実施する。ここで、見積もりは、プランの見積もりと同様の方法により実行することとする（ステップ３６）。続いて、ステップ３７では、スケジュールされているタスクを実行した場合の性能見積もりに基づき、プラン生成処理を実施する。本処理は、図９に示したステップ３００１の処理と同様のため説明を省略する。

例えば、迅速に実行可能な暫定的な最初のプランが、他主体処理により性能変化が生じるリソースに影響するならば、他主体処理により性能変化が生じるリソースに影響しない次のプランを後刻に実行するというようなスケジュールプランをスケジュール情報として予めシステム内に保持しておくことが考えられる。そして、最初のプランを実行した後に次のプランを実行できるか否か判定し、実行できるならば、そのようなスケジュールプランを提示すればよい。

図１７は、変形例におけるプラン提示画面の一例である。プラン提示画面９０００の表示領域９００１〜９００４は図１４と、表示領域９１０６は図１５とそれぞれ同一の内容のため、説明を省略する。図１７の例では、ＰＯＯＬ３からＰＯＯＬ２へのＶＭ１のデータ移動プランＳｔｅｐ（１）だけでなく、図１６に示したフローのステップ３７において生成されたプランの情報を元に、ＰＯＯＬ２からＰＯＯＬ６へのＶＭ１のデータ移動プランＳｔｅｐ（２）も提示し、一連のスケジュールプランを提示している。加えて、Ｓｔｅｐ（１）からＳｔｅｐ（２）と続くスケジュールプランをガントチャートとして表すことで、管理者の判断を容易にしている。この際、プランの実行に要する時間を、合わせて提示することで、実行にかかる時間を、実行をするか否かの判断材料として提示している。

プラン実行にかかる時間については、例えば、データ移動のプランの場合、管理サーバ１０００は、移動元及び移動先のそれぞれの記憶デバイスのメディア種別とＲＡＩＤレベルとの組み合わせごとに、単位時間（例えば１秒）当たりにどの程度の容量のデータを移動できるかを示すデータをあらかじめ保持しておき、移動する容量に応じて算出してもよい。ここで、管理サーバ１０００は、実環境における利用状況に応じて、移動にかかる時間が変動することを考慮し、過去の履歴情報を利用して、単位時間当たりの移動可能容量を算出し、あらかじめ保持している情報を、履歴情報を利用して補正してもよい。例えば、あらかじめ保持している情報と履歴情報との平均をとるなどが考えられる。ここで、求め方の一例を示したが、上記方法に限定されず、他の求め方が採用されてもよい。

本実施例では、他主体処理として、クラスタ構成におけるパス切り替えの処理を主に取り上げたが、その他の例として、例えば、ＶＭのホスト間で自動的にロードバランシングや、ストレージの負荷分散構成（Ａｃｔｉｖｅ−Ａｃｔｉｖｅ構成）の場合にも同様に適用できる。

システム内で発生したイベントへの対処策を生成する際に、対処策となるプランを実行した場合の構成で利用するリソースに関連する、他主体処理によって、プランを実行した場合の構成で利用するリソースの性能が変化する可能性を示す情報と、その性能の変化量を、プラン実行の効果指標として算出し、提示することで、冗長構成における切り替え処理など、プランの実行とは別の制御下で動作する他主体処理を考慮してプランを導出することが可能となる。

なお、本発明は、以上説明した実施例に限定されるものでなく、その趣旨を逸脱しない範囲で種々変更可能であることはいうまでもない。

１０００…管理サーバ、１１００…メモリ、１２００…通信デバイス、１３００…プロセッサ、１４００…出力デバイス、１５００…入力デバイス、１６００…記憶デバイス、１７００…内部バス、２０００…ストレージ装置、２１００…メモリ、２１１０…ディスクキャッシュ、２２００…論理ボリューム提供部、２２１０…論理ボリューム、２２２０…ディスクプール、２３００…ディスクＩ／Ｆコントローラ、２４００…管理Ｉ／Ｆ、２５００…プロセッサ、２６００…データＩ／Ｆ、２７００…通信路、３０００…サーバ、３１００…メモリ、３２００…データＩ／Ｆ、３３００…プロセッサ、３４００…管理Ｉ／Ｆ、３５００…通信路、４０００…ＳＡＮ、４０１…サーバ、４０２…ＶＭ、４０３…ドライブ、４０４…サーバデータＩ／Ｆ、４０５…ストレージ、４０６…ストレージデータＩ／Ｆ、５０００…管理用ネットワーク

Claims (14)

1. 計算機システムで発生したイベントに対する対処策であるプランを生成する管理システムであって、
   前記イベントに応じてプランを生成するプラン生成手段と、
   前記プラン生成手段によって生成されたプランを実行した場合に、前記プランの主体と異なる他主体によって実行される他主体処理により生じる可能性がある、前記計算機システムのリソースの性能変化に関する情報を、前記プランについての性能変化評価指標として生成する指標生成手段と、
   を有する、管理システム。
2. 前記プラン生成手段によって生成されたプランと、前記指標生成手段によって生成された性能変化評価指標とを提示するプラン提示手段を更に有する、
   請求項１に記載の管理システム。
3. 前記プラン提示手段は、前記性能変化評価指標を、前記プラン実行に関する他の効果指標と共に提示する、
   請求項２に記載の管理システム。
4. 前記他主体処理は、
   装置障害あるいは性能変動によって実行される、
   クラスタにおける冗長パスの切り替え処理、
   クラスタにおける冗長パス間での負荷分散処理、
   データ移動処理、の少なくとも一つを含む、
   請求項１に記載の管理システム。
5. 前記性能変化評価指標は、前記計算機システムに含まれるリソースについて、前記リソースの性能が変化する可能性を示す情報と、当該性能の変化量を示す情報とを含む、
   請求項１に記載の管理システム。
6. 前記リソースの性能の変化量は、読み出し処理と書き込み処理のそれぞれについて算出される、
   請求項５に記載の管理システム。
7. 前記リソースの性能の変化量は、前記他主体処理のタイプと前記リソースのタイプとに応じて、それぞれに算出される、
   請求項５に記載の管理システム。
8. 前記リソースの性能が変化する可能性を示す情報は、前記計算機システムにおいて収集されたイベント発生の履歴情報に基づいて算出されるイベントの発生頻度に関する情報である、
   請求項５に記載の管理システム。
9. 前記リソースの性能が変化する可能性を示す情報は、前記計算機システムのハードウェア構成と前記計算機システムにおいて収集された障害履歴情報とに基づいて算出されるハードウェア障害の発生頻度に関する情報である、
   請求項５に記載の管理システム。
10. 前記ハードウェア障害の発生頻度は、前記計算機システムのハードウェア構成から算出される故障間隔時間と、前記障害履歴情報から算出される故障間隔時間と、を用いて算出される、
    請求項９に記載の管理システム。
11. 前記障害履歴情報は、交替パスソフトウェアが発行するパス障害メッセージと、前記計算機システム内で発生するイベント情報とから生成される、
    請求項９に記載の管理システム。
12. 前記プラン提示手段は、前記プラン生成手段によって生成された第１のプランが、前記他主体処理により性能変化が生じるリソースに影響するならば、前記他主体処理により性能変化が生じるリソースに影響しない第２のプランについて、前記第１のプランの実行後に前記第２のプランを実行できるか否か判定し、実行できるならば、前記第１のプランおよび前記第２のプランの実行を含むスケジュールプランを提示する、
    請求項２に記載の管理システム。
13. 計算機システムで発生したイベントに対する対処策であるプランを生成するプラン生成方法であって、
    プラン生成手段が、前記イベントに応じてプランを生成し、
    指標生成手段が、前記プラン生成手段によって作成されたプランを実行した場合に、前記プランの主体と異なる他主体によって実行される他主体処理により生じる可能性がある、前記計算機システムのリソースの性能変化に関する情報を、前記プランについての性能変化評価指標として生成する、プラン生成方法。
14. 計算機システムで発生したイベントに対する対処策であるプランをコンピュータに生成させるためのプラン生成プログラムであって、
    前記イベントに応じてプランを生成する手順と、
    前記プラン生成手段によって作成されたプランを実行した場合に、前記プランの主体と異なる他主体によって実行される他主体処理により生じる可能性がある、前記計算機システムのリソースの性能変化に関する情報を、前記プランについての性能変化評価指標として生成する手順とをコンピュータに実行させるためのプラン生成プログラム。
    
    

Images