JPWO2018131100A1 - 計算機システムを管理する管理システム - Google Patents

Abstract

管理システムは、第１のリソースのリソース属性に従う実性能変化情報を第２のリソースのリソース属性に従う推定性能変化情報に変換する。リソース属性は、リソースタイプ及びメトリックのうちの少なくとも１つである。実性能変化情報は、測定されたメトリック値の時系列変化を表す情報である。推定性能変化情報は、予め用意された管理情報が表す複数の変換方法のうちの、第１のリソースのリソース属性と第２のリソースのリソース属性とに対応した１以上の変換方法を用いて、その第１のリソースの実性能変化情報が変換された性能変化情報である。第１のリソースは、計算機システムのトポロジーにおいて第２のリソースに関連するリソースである。管理システムは、第２のリソースの推定性能変化情報と第２のリソースの実性能変化情報との差分に従い第１のリソースと第２のリソースとの関係性を算出する。管理システムは、第１のリソースについて算出された関係性に基づく情報である処理結果情報を表示する。

Description

本発明は、概して、複数のリソースを有する計算機システムの管理に関する。

近年、計算機システム（例えばクラウド基盤）について、「ＣＰＵ」や「メモリ」等の物理リソースを「仮想マシン」や「ボリューム」などの論理リソースの単位でユーザに割り当てて運用していることが多くなっている。ユーザリソース（例えばユーザが認識する論理リソース）とシステムリソース（例えばユーザが認識しない物理リソース）の関係が複雑となっている計算機システムの性能を監視するために、ベースライン監視等のシステム監視技術を用いて計算機システムの運用を行う技術が存在する。

この種の技術では、一般に、個々のリソースについて、性能履歴が管理される。「性能履歴」は、典型的には、メトリック値（性能値）の時系列変化である。問題リソースが発見された場合、ユーザは、その問題リソースに対応したボトルネックリソースを探す。リソースの関係が複雑化したことで、人手では、ボトルネックリソースを探すことが難しくなり、この技術の重要性が増している。「問題リソース」とは、異常（例えばメトリック値が所定の閾値を超えた）のような問題が生じているリソースである。ボトルネックリソースとは、生じている問題のボトルネック（例えば根本原因）となっているリソースである。

計算機システムは、通常、リソース属性が異なる２以上のリソースを含んでいる。本明細書において、「リソース属性」とは、リソースタイプとメトリック（性能タイプ）とのうちの少なくとも１つを意味する。このため、「リソース属性が異なる」とは、リソースタイプが異なる、及び、メトリックが異なる、のうちの少なくとも１つに該当することを意味する。

リソース属性の異なるリソースの性能変化情報（メトリック値の時系列変化）を比較しても、リソース属性の異なるリソース間の関係性（関係の度合）を特定することは難しい。なぜなら、リソース属性の異なるリソース間では、メトリックが異なっていたり、メトリックが同じでも性能変化の傾向が異なっていたりするからである。

特許文献１は、運用管理装置を開示している。その運用管理装置は、性能種目又は被管理装置を要素とし、少なくとも第１の要素に関する性能情報の時系列変化を示す第１の性能系列情報と、第２の要素に関する性能情報の時系列変化を示す第２の性能系列情報との相関関数を導出する。

特開2011-146073号公報

特許文献１では、相関関数の導出に、性能変化情報、すなわち、測定されたメトリック値（実測値）の時系列変化が必須である。このため、計算機システムを運用開始してから短時間のうちに問題リソースが発生しても、適切な相関関数を導出できる程の量の性能変化情報が蓄積されておらず、故に、その問題リソースに対応したボトルネックリソースを見つけることは困難である。この課題は、特に、問題とされるメトリック値を含んだ性能変化情報を用いて相関関数を導出する場合に大きい。なぜなら、一般に、計算機システムは常に正常であることが望ましく、故に、計算機システムの運用中に問題のメトリック値が得られることは少ないと考えられるからである。

また、一般に、計算機システムの構成変更が適宜行われるが、上述の課題は、計算機システムの構成変更についても同様に存在する。具体的には、次の通りである。すなわち、計算機システムの構成変更とは、例えば、論理リソースの追加、変更又は削除（例えば、仮想マシンの追加、変更又は削除、ボリュームの追加、変更又は削除）、物理リソースの追加、変更又は削除（例えば、物理サーバの追加、変更又は削除）、及び、リソース間の経路変更（例えば、リソース間に介在するリソースの追加、変更又は削除）である。このため、計算機システムの構成変更が行われると、新たなリソース間の関係が生じたり、同一リソース間であってもその関係性が変わったりすることがあり、結果として、リソースの性能変化の傾向が変わることがある。特許文献１では、上述したように、相関関数の導出には、リソースの性能変化情報が必要である。従って、計算機システムの構成変更は、特許文献１では計算機システムの新規の運用開始と同等であり、故に、計算機システムの構成変更についても上述の課題がある。

更に、特許文献１では、計算機システムの構成変更については、リソース間の相関関数を再導出する必要がある。なぜなら、特許文献１では、相関関数は、個々のリソース間について導出されるものであり、計算機システムの構成変更が行われると、上述したように、新たなリソース間の関係が生じたり、同一リソース間であってもその関係性が変わったりすることがあり、結果として、適切であった相関関数が不適切になり得るからである。

このような課題は、リソース間の関係性を特定する他のケース、及び、相関関数以外の変換方法が採用されるケースのうちの少なくとも１つについてあり得る。

管理システムは、複数のリソースを有する計算機システムのうちの１以上の第１のリソースの各々について、その第１のリソースのリソース属性に従う実性能変化情報を、計算機システムのうちの第２のリソースのリソース属性に従う推定性能変化情報に変換する。複数のリソースは、リソース属性が異なる２以上のリソースを含む。複数のリソースの各々について、リソース属性は、リソースタイプ及びメトリックのうちの少なくとも１つである。１以上の第１のリソースと第２のリソースの各々について、性能変化情報は、そのリソースのメトリック値の時系列変化を表す情報である。１以上の第１のリソースの各々について、その第１のリソースの実性能変化情報は、その第１のリソースについて測定されたメトリック値の時系列変化を表す情報である。１以上の第１のリソースの各々について、第２のリソースの推定性能変化情報は、予め用意された管理情報が表す複数の変換方法のうちの、その第１のリソースのリソース属性と第２のリソースのリソース属性とに対応した１以上の変換方法を用いて、その第１のリソースの実性能変化情報が変換された性能変化情報である。複数の変換方法の各々は、リソース属性に従う性能変化情報を別のリソース属性に従う性能変化情報に変換するための方法である。１以上の第１のリソースの各々は、計算機システムのトポロジーにおいて第２のリソースに関連するリソースである。管理システムは、１以上の第１のリソースの各々について、第２のリソースの推定性能変化情報と第２のリソースの実性能変化情報との差分に従いその第１のリソースと第２のリソースとの関係性を算出する。第２のリソースの実性能変化情報は、その第２のリソースについて測定されたメトリック値の時系列変化を表す情報である。管理システムは、１以上の第１のリソースの各々について算出された関係性に基づく情報である処理結果情報を表示する。処理結果情報は、１以上の第１のリソースのうちの少なくとも１つに関する情報を含む。

計算機システムの運用開始又構成変更からの時間が短くても、第１リソースの実性能変化情報を基に第２のリソースの推定性能変化情報を取得し、その推定性能変化情報と第２リソースの実性能変化情報とを基にリソース間の関係性を特定することが期待できる。

実施例に係る計算機システム及び管理システムの構成を示す。 計算機システムのトポロジー（リソーストポロジー）の一部の一例を示す。 リソーステーブルの一例を示す。 関連リソーステーブルの一例を示す。 相関関数関連テーブルの一例を示す。 相関関数定義テーブルの一例を示す。 性能テーブルの一例を示す。 ボトルネック候補表示処理のフロー及び概要を示す。 経路一覧生成処理（図８のＳ８０２）のフロー及び概要を示す。 ボトルネック判定処理（図８のＳ８０５）のフロー及び概要を示す。 リソースタイプ一覧生成処理（図１０のＳ１００１）のフロー及び概要を示す。 問題リソース性能履歴推定処理（図１０のＳ１００２）のフロー及び概要を示す。 一実施例の概要を示す。

以下の説明では、「ａｂｃテーブル」の表現にて情報を説明することがあるが、情報は、テーブル以外のデータ構成で表現されていてもよい。データ構成に依存しないことを示すために「ａｂｃテーブル」のうちの少なくとも１つを「ａｂｃ情報」と呼ぶことができる。また、以下の説明において、各テーブルの構成は一例であり、１つのテーブルは、２以上のテーブルに分割されてもよいし、２以上のテーブルの全部または一部が１つのテーブルであってもよい。

また、以下の説明では、「インターフェース部」は、１以上のインターフェースを含む。１以上のインターフェースは、１以上の同種のインターフェースデバイス（例えば１以上のＮＩＣ（Network Interface Card））であってもよいし２以上の異種のインターフェースデバイス（例えばＮＩＣとＨＢＡ（Host Bus Adapter））であってもよい。

また、以下の説明では、「記憶部」は、１以上のメモリを含む。少なくとも１つのメモリは、揮発性メモリであってもよいし不揮発性メモリであってもよい。記憶部は、主に、プロセッサ部による処理の際に使用される。

また、以下の説明では、「プロセッサ部」は、１以上のプロセッサを含む。少なくとも１つのプロセッサは、典型的には、ＣＰＵ（Central Processing Unit）のようなマイクロプロセッサである。１以上のプロセッサの各々は、シングルコアでもよいしマルチコアでもよい。プロセッサは、処理の一部または全部を行うハードウェア回路を含んでもよい。

また、以下の説明では、「プログラム」を主語として処理を説明する場合があるが、プログラムは、プロセッサ（例えばＣＰＵ（Central Processing Unit））によって実行されることで、定められた処理を、適宜に記憶部（例えばメモリ）及び／又は通信インターフェースデバイス（例えば通信ポート）等を用いながら行うため、処理の主語がプロセッサとされてもよい。プログラムを主語として説明された処理は、プロセッサあるいはそのプロセッサを有する装置が行う処理としてもよい。また、プロセッサは、処理の一部または全部を行うハードウエア回路を含んでもよい。プログラムは、プログラムソースから計算機のような装置にインストールされてもよい。プログラムソースは、例えば、プログラム配布サーバまたは計算機が読み取り可能な記録媒体（例えば非一時的な記録媒体）であってもよい。また、以下の説明において、２以上のプログラムが１つのプログラムとして実現されてもよいし、１つのプログラムが２以上のプログラムとして実現されてもよい。

また、以下の説明では、管理システムは、１以上の計算機で構成されてよい。具体的には、例えば、管理計算機が情報を表示する場合（具体的には、管理計算機が自分の表示デバイスに情報を表示する、或いは、管理計算機が表示用情報を遠隔の表示用計算機に送信する場合）、管理計算機が管理システムである。また、例えば、複数の計算機で管理計算機と同等の機能が実現されている場合は、当該複数の計算機（表示を表示用計算機が行う場合は表示用計算機を含んでよい）が、管理システムである。計算機への情報の入力や、計算機からの情報の出力は、計算機が有する入出力デバイスにより行われてよい。入出力デバイスの例としては、表示デバイス、キーボード及びポインティングデバイスが考えられるが、これらのうちの少なくとも１つに代えて又は加えて別のデバイスが採用されてよい。また、入出力デバイスの代替として、シリアルインターフェースデバイスやイーサーネットインターフェースデバイス（イーサネットは登録商標）が採用され、そのようなインターフェースデバイスに、表示デバイスとキーボード及びポインタデバイスとを有する表示用計算機が接続され、計算機が表示用情報を表示用計算機に送信したり、計算機が入力用情報を表示用計算機から受信したりすることで、情報の出力（例えば表示）及び入力が行われてよい。以下の説明では、管理サーバ５５７が管理計算機であり、管理クライアント５５５が表示用計算機である。

また、以下の説明では、「リソース」とは、計算機システムの構成要素を意味し、具体的には、計算機システムを構成する複数の装置の各々、及び、各装置が有する複数のコンポーネントの各々の総称である。装置として、物理的な装置（例えばネットワークスイッチ）もあれば論理的な装置（例えば仮想マシン）もある。同様に、コンポーネントとして、物理的なコンポーネント（例えばマイクロプロセッサ）もあれば論理的なコンポーネント（例えばＬＤＥＶ（論理ボリューム））もある。すなわち、リソースとしては、物理リソースと論理リソースとがある。物理リソースは、例えば、物理ＣＰＵ及び物理メモリ等である。論理リソースは、１以上の物理リソースの少なくとも一部が割り当てられたリソース、及び、１以上の物理リソースの少なくとも一部を使用するリソースのうちの少なくとも１つに該当するリソースである。論理リソースは、例えば、ＡＰＰ、論理ボリューム及びＶＭ（Virtual Machine）等である。

また、以下の説明では、リソースの「関連リソース」（リソースに関連するリソース）とは、リソースに直接的又は間接的にリンクしたリソースである。リソースに関連リソースが「直接的に」リンクしている場合、リソースと関連リソースの間に他のリソースが介在しない。リソースに関連リソースが「間接的に」リンクしている場合、リソースと関連リソースの間に他の１以上のリソースが介在する。リソースよりも上位の関連リソースを、「上位関連リソース」と言うことができ、リソースよりも下位の関連リソースを、「下位関連リソース」と言うことができる。また、上位関連リソースのうち、リソースに直接的にリンクしている関連リソースを「親リソース」と言うことができ、下位関連リソースのうち、リソースに直接的にリンクしている関連リソースを「子リソース」と言うことができる。なお、「上位／下位」や「親／子」の概念は、ユーザが何を管理（例えば監視）する立場であるかによって変化する場合があり、また省略されてもかまわない。例えば、関連が、サーバとストレージシステムとのＦＣ（Fibre Channel）スイッチを介した「接続関係」の場合、単に接続されているというレベルで見ればサーバとストレージシステムはどちらが上位や親かは一意に定まるものではなく、ユーザの立場によってサーバを上位と考えるか、ストレージシステムを上位と考えるか、又は上下という概念を持ち込まないかが決まってよい。反対に、関連が、包含（例えばノードがコンポーネントを含む）場合は、ノードの下位（又は子）はコンポーネントであるという概念はユーザの立場によらず共通である場合が多い。

また、以下の説明では、「ノード」は、リソーストポロジー（木構造）における要素としてのリソースである。また、以下の説明では、「エッジ」は、ノード間のリンクである。従って、例えば、３つのリソースが直列になっている場合、ノードは３つであり、エッジは２つである。

また、以下の説明では、リソースの識別情報として、名前が使用されるが、名前に代えて又は加えて他種の識別情報が使用されてもよい。

また、以下の説明では、同種の要素を区別しないで説明する場合には、参照符号を使用し、同種の要素を区別して説明する場合は、要素の識別情報としての名前を使用することがある。

図１３は、一実施例の概要を示す。

複数の相関関数が予め用意されている。相関関数は、リソースのリソース属性に従う性能履歴を別のリソースのリソース属性に従う性能履歴に変換するための変換方法の一例である。「性能履歴」は、性能変化情報の一例であり、メトリック値の時系列変化を表すメトリック値履歴である。本実施例では、「リソース属性」は、リソースタイプ及びメトリックである。

相関関数は、個々のリソース間についてではなく、リソース属性間について用意される。このため、事前に用意されるべき相関関数の数（後述の相関関数関連テーブルの情報量）を抑えることができ、また、汎用性が高い。例えば、リソース間として、ＶＭ（仮想マシン）とポート間があるが、全てのＶＭのリソース属性が同一であり且つ全てのポートのリソース属性が同一であるとする。この場合、ＶＭの数及びポートの数が多い程、リソース間の数も多いが、リソース属性間の数は常に１である。また、ＶＭとポートの少なくとも１つが追加、変更又は削除となると、リソース間も追加、変更又は削除となるが、リソース属性間は変わらず、故に、相関関数の追加、変更又は削除も不要でよい。

リソースのリソース属性に従うノウハウ（例えば、設計情報や運用ナレッジ）に基づいて、相関関数を事前に定義しておくことができる。計算機システムの運用開始又は構成変更からの経過時間が短くても（各リソースの実性能履歴の量が少なくても）、適切な相関関数が存在し、故に、関連リソースのリソース属性と問題リソースのリソース属性に対応した１以上の相関関数を用いて、関連リソースの実性能履歴を問題リソースの推定性能履歴に変換することができる。そして、問題リソースの推定性能履歴と、問題リソースの実性能履歴とを用いて、関連リソースと問題リソースの関係性（相関係数）を算出することができる。これは、特に、本実施例のように、第２リソースの一例として、問題リソースが採用され、第１リソースの一例として、問題リソースの関連リソースが採用される場合に大きいと考えられる。なぜなら、問題のあるメトリック値（例えばしきい値を超えたメトリック値）が測定される頻度は、正常なメトリック値が測定される頻度に比べて小さいが、本実施例では、上述したように、リソース属性に従うノウハウに基づいて相関関数を事前に用意しておくことができるため、計算機システムの運用開始又は構成変更からの経過時間が短いうちに問題リソースが検出されても、その問題リソースの関連リソースがボトルネック候補であるか否かを正確に判定することが期待できる。

以下、本実施例を詳細に説明する。

図１は、一実施例に係る計算機システム及び管理システムの構成を示す。

計算機システム１００は、１以上のホスト５５３と、１以上のホスト５５３に接続された１以上のストレージシステム５５１とを含む。ストレージシステム５５１には、例えば、通信ネットワーク５２１（例えばＳＡＮ（Storage Area Network）又はＬＡＮ（Local Area Network））を介してホスト５５３が接続される。

ストレージシステム５５１は、物理記憶デバイス群５６３と、物理記憶デバイス群５６３に接続されたコントローラ５６１とを有する。

物理記憶デバイス群５６３は、１以上のＰＧ（Parity Group）を有する。ＰＧは、ＲＡＩＤ（Redundant Array of Independent (or Inexpensive) Disks）グループと呼ぶこともある。ＰＧは、複数の物理記憶デバイスで構成されており、所定のＲＡＩＤレベルに従いデータを記憶する。物理記憶デバイスは、例えば、ＨＤＤ（Hard Disk Drive）或いはＳＳＤ（Solid State Drive）である。

ストレージシステム５５１は、複数の論理ボリュームを有する。論理ボリュームとしては、ＰＧに基づく実体的な論理ボリューム（実ボリューム）５６５もあれば、シンプロビジョニング或いはストレージ仮想化技術に従う仮想的な論理ボリューム（仮想ボリューム）５６７もある。１つのストレージシステム５５１が必ずしも複数種類の論理ボリュームを有さないでよい。例えば、ストレージシステム５５１は、論理ボリュームとして、実ボリューム５６５のみを有してもよい。シンプロビジョニングに従う仮想ボリュームにはプールから記憶領域が割り当てられる。プールは、１以上の物理記憶デバイス（例えばＰＧ）に基づく記憶領域群であり、例えば、１以上の論理ボリュームの集合でよい。プールは、シンプロビジョニングに従う仮想ボリュームに割り当てられる記憶領域を有するプールに代えて、オリジナルの論理ボリュームとそのスナップショットとの差分が格納されるプールでもよい。

コントローラ５６１は、複数のデバイス、例えば、ポート、ＭＰＢ（１又は複数のマイクロプロセッサ（ＭＰ）を有するブレード（回路基板））及びキャッシュメモリを有している。例えば、ポートが、ホスト５５３からＩ／Ｏ（Input/Output）コマンド（ライトコマンド又はリードコマンド）を受信し、ＭＰＢが有するＭＰが、そのＩ／Ｏコマンドに従うデータのＩ／Ｏを制御する。具体的には、例えば、ＭＰは、受信したＩ／ＯコマンドからＩ／Ｏ先の論理ボリュームを特定し、特定した論理ボリュームに対してデータのＩ／Ｏを行う。論理ボリュームに対してＩ／Ｏされるデータは、一時的に、キャッシュメモリに格納される。

ホスト５５３は、物理マシン（物理計算機）でも仮想マシン（ＶＭ）でもよい。ホスト５５３で、１以上のアプリケーションプログラム（ＡＰＰ）５５２が実行される。ＡＰＰ５５２が実行されることにより、論理ボリュームを指定したＩ／Ｏコマンドがホスト５５３からストレージシステム５５１に送信する。

以上のように、計算機システム１００は、階層的な複数のリソースを有する。複数のリソースは、具体的には、ＡＰＰ５５２、ホスト５５３、ストレージシステム５５１、コントローラ５６１、ポート、ＭＰＢ、キャッシュメモリ、論理ボリューム及びＰＧ等のうちの２つのリソースタイプ以上のリソースを含む。同じレイヤの複数のリソースがグループ化されることでそのレイヤのリソースより上位レイヤのリソースが定義されてもよい。「リソース」は、ＡＰＰや論理ボリュームのような実体的なリソース（論理リソースと物理リソースのいずれでもよい）と、複数の実体的なリソースのグループである仮想的なリソースとがあってよい。

管理システムは、管理サーバ５５７と、管理サーバ５５７に接続された１以上の管理クライアント５５５とを含む。管理サーバ５５７には、通信ネットワーク（例えばＬＡＮ、ＷＡＮ（World Area Network）又はインターネット）５２１を介して、管理クライアント５５５が接続される。

管理クライアント５５５は、入力デバイス５０１、表示デバイス５０２、記憶デバイス（例えばメモリ）５０５、通信インターフェースデバイス（以下、Ｉ／Ｆ）５０７、及び、それらに接続されたプロセッサ（例えばＣＰＵ（Central Processing Unit））５０３を有する。入力デバイス５０１は、例えば、ポインティングデバイス及びキーボードである。表示デバイス５０２は、例えば、情報が表示される物理画面を有するデバイスである。入力デバイス５０１及び表示デバイス５０２が一体となったタッチスクリーンが採用されてもよい。Ｉ／Ｆ５０７は、通信ネットワーク５２１に接続され、Ｉ／Ｆ５０７を介して、管理クライアント５５５は管理サーバ５５７と通信することができる。なお、通信ネットワーク５２１と、ホスト５５３とストレージシステム５５１と、を接続するネットワークとは一部または全てが共通であってもよい。

記憶部５０５は、例えば、主記憶デバイス及び補助記憶デバイスのうちの少なくとも主記憶デバイス（典型的にはメモリ）を有する。記憶部５０５は、プロセッサ５０３で実行されるコンピュータプログラム、及び、プロセッサ５０３に使用される情報を記憶することができる。具体的には、例えば、記憶部５０５は、Ｗｅｂブラウザ５１１、及び、管理クライアントプログラム５１３を記憶する。管理クライアントプログラム５１３は、ＲＩＡ（Rich Internet Application）でよい。具体的には、例えば、管理クライアントプログラムは、プログラムファイルであり、管理サーバ５５７（或いは他の計算機）からダウンロードされ、記憶部５０５に記憶されてよい。

管理サーバ５５７は、記憶部５３５、Ｉ／Ｆ５３７、及び、それらに接続されたプロセッサ（例えばＣＰＵ（Central Processing Unit））５３３を有する。プロセッサ５３３は、プロセッサ部の一例である。Ｉ／Ｆ５３７は、通信ネットワーク５２１に接続され、Ｉ／Ｆ５３７を介して、管理サーバ５５７は管理クライアント５５５と通信することができる。管理サーバ５５７は、Ｉ／Ｆ５３７を介して、ユーザ操作に従う指示を受信したり、レイアウト領域に表示オブジェクトを描画したりすることができる。このため、Ｉ／Ｆ５３７は、Ｉ／Ｏインターフェースデバイスの一例である。なお、ここで言う「レイアウト領域」とは、表示オブジェクトが描画され得る領域である。レイアウト領域の全部又は一部の範囲が、Ｗｅｂブラウザ５１１（又は管理クライアントプログラム５１３）によって表示されるフレーム（例えばウィンドウ）での表示範囲である。表示オブジェクトが描画されたレイアウト領域の、上記フレーム内における表示イメージ（表示オブジェクトを含む）を、表示画面又はＧＵＩ画面と言うことができる。レイアウト領域に描画されたオブジェクトのうち、表示範囲に重なるオブジェクトが、表示デバイス５０２の物理画面上に表示される。このため、レイアウト領域にオブジェクトを描画することは、実質的に、オブジェクトを表示することの一例である。

記憶部５３５は、例えば、主記憶デバイス及び補助記憶デバイスのうちの少なくとも主記憶デバイス（典型的にはメモリ）を有する。記憶部５３５は、プロセッサ５３３で実行されるコンピュータプログラム、及び、プロセッサ５３３に使用される情報を記憶することができる。具体的には、例えば、記憶部５３５は、管理サーバプログラム５４１及び管理テーブル群５４３を記憶する。管理テーブル群５４３は、計算機システムが有する複数のリソースの階層関係（構成情報）や、各リソースの障害情報等を含む。管理テーブル群５４３の少なくとも一部の情報は、管理サーバプログラム５４１により収集されてもよいし、情報を保有する他の管理システムにアクセスすることで取得してもよい。管理サーバプログラム５４１は、ユーザ操作に従う指示を管理クライアント５５５から受信したり、レイアウト領域に描画される情報を管理クライアント５５５に送信したりする。

管理サーバプログラム５４１と、Ｗｅｂブラウザ５１１（またはクライアントのＲＩＡ実行環境）と、管理クライアントプログラム５１３と、の連携処理によって、ユーザ操作に応じたＧＵＩ画面表示が実現される。管理サーバプログラム５４１が、画面を作成し、作成した画面の表示用情報を管理クライアントプログラム５１３に提供し、管理クライアントプログラム５１３が、その表示用情報を基に画面を表示してもよいし、画面作成処理の一部（例えば描画処理）が管理サーバプログラム５４１から管理クライアントプログラム５１３にオフロードされてもよい。連携の例としては以下がある。説明の簡略化のために、本実施例において（連携例２）が採用される場合を説明するが、連携例１にも適用可能であることは言うまでもない。
（連携例１）管理サーバプログラム５４１が、管理テーブル群５４３が有する情報の少なくとも一部を、Ｗｅｂブラウザ５１１（又は管理クライアントプログラム５１３）に送信し、それを、Ｗｅｂブラウザ５１１（又は管理クライアントプログラム５１３）が一時情報として記憶部５０５に格納する。Ｗｅｂブラウザ５１１（又は管理クライアントプログラム５１３）が、ユーザ操作に従う指示と一時情報とを基に、レイアウト領域に表示オブジェクトを描画する（例えば、表示オブジェクトを新規描画、拡大又は縮小する）。
（連携例２）管理サーバプログラム５４１が、表示画面に対するユーザ操作に従う指示をＷｅｂブラウザ５１１（又は管理クライアントプログラム５１３）から受け、その指示と管理テーブル群５４３とを基に表示オブジェクトの表示用情報を作成し、その表示用情報を送信する。Ｗｅｂブラウザ５１１（又は管理クライアントプログラム５１３）は、表示用情報を受信し、その表示用情報に従い表示オブジェクトをレイアウト領域に描画する。つまり、端的に言えば、管理サーバプログラム５４１が、レイアウト領域に表示オブジェクトを描画する。Ｗｅｂブラウザ５１１（又は管理クライアントプログラム５１３）は、ＧＵＩ画面に対するユーザ操作がされたら、そのユーザ操作に従う指示を管理サーバプログラム５４１に送信する。

以下、冗長な説明を避けるために、表示の制御は管理サーバプログラム５４１（表示制御プログラム１３０）により行われるとする。

図２は、計算機システム１００のトポロジー（リソーストポロジー）の一部の一例を示す。

複数のレイヤとして、例えば、上位レイヤから順に、Server、SAN及びStorageがある。レイヤ「Server」に属するリソースは、「VM」、「HV」及び「DS」である。「VM」は、仮想マシンである。「HV」は、１又は複数の仮想マシンを制御しホストで実行されるハイパバイザである。HV（例えばHV4）に含まれるリソースの一例として、CPUとDISK（物理記憶デバイスの一例）がある。「DS」は、ハイパバイザから記憶デバイスとして認識されるデータストアである。レイヤ「SAN」に属するリソースは、「FC-Switch」（ＳＡＮにおけるＦＣ（Fibre Channel）スイッチ）である。レイヤ「Storage」に属するリソースは、「Storage」（ストレージシステム）である。Storage（例えばStorage2）に含まれるリソースの一例として、ストレージシステムにおける複数のコンポーネント、例えば、「Port」、「LDEV」、「MP」、「Pool」、「PG」及び「Cache」がある。「Port」は、ＦＣスイッチに接続されVMからＩ／Ｏコマンドを受け付ける通信ポートである。「LDEV」は、論理ボリューム（実ボリューム又は仮想ボリューム）である。「MP」は、マイクロプロセッサである。「Pool」は、仮想ボリュームにシンプロビジョニングに従い割り当てられる実領域を含んだ記憶領域である。「PG」は、パリティグループである。「Cache」は、論理ボリュームに入出力されるデータが一時的に格納されるキャッシュメモリである。

図２に示したようなトポロジー構成は、管理テーブル群５４３が表す構成情報から特定される構成である。１又は複数のリソースタイプが１つのレイヤに属してもよい。同一リソースタイプの２以上のリソースにより１つのグループが構成されてもよく、その場合、１つのリソースタイプについて異なる複数のグループが存在し、グループ毎に、そのリソースタイプの１以上のリソースが存在してもよい。つまり、「レイヤ」は、異なるリソースタイプの集約であり、「グループ」は、同一リソースタイプでの異なるリソースの集約である。レイヤ及びグループのうちの少なくとも一方がユーザにより定義されてもよい。

以下、図３〜図７を参照して、管理テーブル群５４３に含まれるテーブルの一例を説明する。

図３は、リソーステーブルの一例を示す。

リソーステーブル４００は、リソースに関する情報を有する。リソーステーブル４００は、例えば、リソース毎にレコードを有する。各レコードが、リソース名（リソースの名前）及びリソースタイプ名（リソースタイプの名前）といった情報を保持する。

図４は、関連リソーステーブルの一例を示す。

関連リソーステーブル５００は、リソース同士の関連を表す。例えば、関連リソーステーブル５００は、リソース毎にレコード有し、各レコードは、リソース名及び子リソース名（リソースの子リソースの名前）といった情報を保持する。管理サーバプログラム５４１は、選択されたリソースのリソース名を用いて、関連リソーステーブル５００から、選択されたリソースの関連リソースを特定できる。例えば、管理サーバプログラム５４１は、選択されたリソースのリソース名を有するレコードを基点に関連リソーステーブル５００から特定されるレコードから、下位関連リソースを特定できる。また、管理サーバプログラム５４１は、選択されたリソースのリソース名を子リソース名として有するレコードを基点に関連リソーステーブル５００から特定されるレコードから、上位関連リソースを特定できる。関連リソーステーブル５００の各レコードは、子リソース名に代えて又は加えて親リソース名を保持してもよい。

図５は、相関関数関連テーブルの一例を示す。

相関関数関連テーブル５５０は、相関関数毎にその相関関数の変換元（変換前）のリソース属性と変換先（変換後）のリソース属性とに関する情報を保持する。例えば、相関関数関連テーブル５５０は、相関関数毎にレコードを有し、各レコードは、関数名（相関関数の名前）、変換元属性（変換元のリソース属性を表す情報）及び変換先属性（変換先のリソース属性を表す情報）といった情報を保持する。変換元属性は、変換元リソースタイプ名（変換元のリソースタイプの名前）及び変換元メトリック名（変換元のメトリックの名前）である。変換先属性は、変換先リソースタイプ名（変換先のリソースタイプの名前）及び変換先メトリック名（変換先のメトリックの名前）である。

図６は、相関関数定義テーブルの一例を示す。

相関関数定義テーブル６００は、相関関数毎にその相関関数の定義に関する情報を有する。相関関数定義テーブル６００は、例えば、相関関数毎にレコードを有する。各レコードが、関数名及び関数詳細（例えば、相関関数それ自体とその相関関数で使用される変数）といった情報を保持する。

図７は、性能テーブルの一例を示す。

性能テーブルは、リソースについて収集されたメトリックデータを有するテーブルである。性能テーブルの各レコードは、１件のメトリックデータに含まれる情報を有する。具体的には、例えば、各レコードは、リソース名（収集されたメトリック値に対応したリソースの名前）、メトリック名（収集されたメトリック値のメトリックの名前）、時刻（メトリック値の収集時刻）、及び、メトリック値といった情報を保持する。時刻は、年月日時分秒で表現されているが、表現はそれに限られない。

計算機システム１００における複数のリソースの各々のメトリックデータを収集する処理と、収集されたメトリックデータの少なくとも一部の情報を含んだレコードを性能テーブル７００に追加する処理は、管理サーバプログラム５４１により行われてよい。なお、本実施例において、メトリックとリソースタイプは１：１又は多：１で対応する。すなわち、１つのリソースタイプにつき、メトリックは１又は複数存在するが、１つのメトリックが複数のリソースタイプに対応することはない。しかし、本発明はそれに限定されず、例えば、１つのメトリックタイプが複数のリソースタイプに対応していてもよい。

以上の図３〜図７に示したテーブルを含む管理テーブル群５４３を基に、問題リソースとそれの関連リソース間の相関係数（関係性の一例）の算出及び表示を行うことができる。

以下、本実施例で行われる処理の一例を説明する。

図８は、ボトルネック候補表示処理のフロー及び概要を示す。この処理は、例えば、問題リソースが管理サーバプログラム５４１により検出された場合に開始される。

Ｓ８０１で、管理サーバプログラム５４１が、経路一覧生成処理（図９）を実行する。経路一覧は、問題リソースに関わるリソースペア（リソース名と子リソース名との組）の一覧である。図２に例示したリソーストポロジーにおいて、図８に例示するように、問題リソースが“ＶＭ２１”であるとすると、経路一覧に含まれるリソース名は、図８に例示する通り（すなわち、“ＨＶ４”、“ＤＳ３”等）である。なお、紙面の都合上、経路一覧からは、リソース“ＬＤＥＶ１５”〜“ＬＤＥＶ１８”の各々よりも下位の関連リソースのリソース名は省略されているが、“Ｐｏｏｌ３１”、“ＰＧ５８”及び“ＭＰ４”のような下位関連リソース名も、経路一覧に含まれる。

Ｓ８０２で、管理サーバプログラム５４１が、Ｓ８０１で生成した経路一覧から、全ての子リソース名を取得し、取得された子リソース名から重複した子リソース名があればそれを排除する。残った子リソース名の一覧が、関連リソース一覧である。図８の説明において、関連リソース一覧を構成する子リソース名を「関連リソース名」と言い、「関連リソース名」が表すリソースを「関連リソース」と言う。

Ｓ８０３で、管理サーバプログラム５４１が、内部変数として、“ボトルネック候補一覧”を設定する。これにより、ボトルネック候補表示処理において、ボトルネック候補一覧が生成されるようになる。

関連リソース一覧に対応した全ての関連リソースについて、Ｓ８０４及びＳ８０５が実行される。以下、Ｓ８０４及びＳ８０５の説明において、１つの関連リソースを例に取る（図８の説明において「対象関連リソース」と言う）。

Ｓ８０４で、管理サーバプログラム５４１が、経路一覧を参照し、問題リソースを始点とし関連リソースを終点とした経路を特定する。

Ｓ８０５で、管理サーバプログラム５４１が、Ｓ８０４で特定された経路についてボトルネック判定処理（図１０）を実行する。この処理において、ボトルネック候補一覧が更新される。

関連リソース一覧に対応した全ての関連リソースについて、Ｓ８０４及びＳ８０５が実行された場合、ボトルネック候補一覧が完成している。

Ｓ８０６で、管理サーバプログラム５４１が、完成しているボトルネック候補一覧を表示する。ボトルネック候補一覧は、問題リソース“ＶＭ２１”の関連リソースのうち、算出された相関係数（関係性の一例）が所定値以上である関連リソースに関する情報（例えばリソース名及び相関係数）の一覧を、問題リソースのボトルネック候補リソースの一覧として含む。

図９は、経路一覧生成処理（図８のＳ８０２）のフロー及び概要を示す。

Ｓ９０１で、管理サーバプログラム５４１が、内部変数として、“経路一覧”を設定する。これにより、経路一覧生成処理において、経路一覧が生成されるようになる。

Ｓ９０２で、管理サーバプログラム５４１が、内部変数として、“リソース名”を設定する。

Ｓ９０３で、管理サーバプログラム５４１が、“リソース名”に、初期値として、問題リソースのリソース名“ＶＭ２１”を代入する。

問題リソースのリソース名をキーに直接的に又は間接的に関連リソーステーブルから取得される全ての子リソース名について、Ｓ９０４及びＳ９０５が実行される。以下、Ｓ９０４及びＳ９０５の説明において、１つの子リソース名を例に取る（図９の説明において「対象子リソース名」と言う）。

Ｓ９０４で、管理サーバプログラム５４１が、対象子リソース名とそれに対応したリソース名とのペアを、経路一覧に登録する。

Ｓ９０５で、管理サーバプログラム５４１が、内部変数“リソース名”に、対象子リソース名を代入する。

問題リソースのリソース名をキーに直接的に又は間接的に関連リソーステーブルから取得される全ての子リソース名について、Ｓ９０４及びＳ９０５が実行された場合、経路一覧が完成している。

図１０は、ボトルネック判定処理（図８のＳ８０５）のフロー及び概要を示す。なお、図１０の説明では、１つの経路（問題リソース“ＶＭ２１”を一端とし１つの関連リソース“Ｐｏｒｔ３”を他端とする経路）を例に取る。図１０〜図１２の説明において、その１つの経路を、「対象経路」と言い、対象経路の一端にある関連リソースを「対象関連リソース」と言う。

Ｓ１００１で、管理サーバプログラム５４１が、リソースタイプ一覧生成処理（図１１）を実行する。リソースタイプ一覧とは、対象経路上のリソース毎に、リソース名とリソースタイプ名とを含む。

対象関連リソースの全てのメトリックについて、Ｓ１００２〜Ｓ１００６が実行される。以下、Ｓ１００２〜Ｓ１００６の説明において、１つのメトリック（図１０及び図１２の説明において「対象メトリック」と言う）を例に取る。

Ｓ１００２で、管理サーバプログラム５４１が、問題リソース性能履歴推定処理（図１２）を実行する。つまり、管理サーバプログラム５４１が、対象関連リソースの対象メトリックについての実性能履歴を、問題リソースの推定性能履歴に変換する。

Ｓ１００３で、管理サーバプログラム５４１が、問題リソースのリソース名、メトリック名、及び期間をキーに、性能テーブルから、問題リソースの実性能履歴を取得する。

Ｓ１００４で、管理サーバプログラム５４１が、問題リソースの推定性能履歴（Ｓ１００２で取得された性能履歴）と問題リソースの実性能履歴（Ｓ１００３で取得された性能履歴）の相関係数を算出する。

Ｓ１００５で、管理サーバプログラム５４１が、Ｓ１００４で算出された相関係数がしきい値以上か否かを判定する。

Ｓ１００５の判定結果が真の場合（Ｓ１００５：Ｙｅｓ）、Ｓ１００６で、管理サーバプログラム５４１が、対象関連リソースのリソース名と、Ｓ１００４で算出された相関係数とを、ボトルネック候補一覧に登録する。ボトルネック候補一覧は、図８のＳ８０６で表示されるが、そのボトルネック候補一覧に含まれる関連リソース名（及び相関係数）は相関係数を基に絞り込まれる。これにより、表示されたボトルネック候補一覧の視認性を向上できる。

対象関連リソースの全てのメトリックについて、Ｓ１００２〜Ｓ１００６が実行された場合、対象関連リソースについて、ボトルネック候補一覧の更新が完了している。

図１１は、リソースタイプ一覧生成処理（図１０のＳ１００１）のフロー及び概要を示す。

Ｓ１１０１で、管理サーバプログラム５４１が、内部変数として、“リソースタイプ一覧”を設定する。これにより、リソースタイプ一覧生成処理において、リソースタイプ一覧が生成されるようになる。

対象経路上の全てのリソースについて、Ｓ１１０２及びＳ１１０３が実行される。以下、Ｓ１１０２及びＳ１１０３の説明において、１つのリソースを例に取る（図１１の説明において「対象リソース」と言う）。

Ｓ１１０２で、管理サーバプログラム５４１が、対象リソースのリソース名をキーに、リソーステーブルからリソースタイプ名を取得する。

Ｓ１１０３で、管理サーバプログラム５４１が、対象リソースのリソース名と、Ｓ１１０２で取得されたリソースタイプ名とを、リソースタイプ一覧に設定する。

対象経路上の全てのリソースについて、Ｓ１１０２及びＳ１１０３が実行された場合、対象経路について、リソースタイプ一覧が完成している。

図１２は、問題リソース性能履歴推定処理（図１０のＳ１００２）のフロー及び概要を示す。

Ｓ１２０１で、管理サーバプログラム５４１が、内部変数として、“推定履歴”を設定する。これにより、問題リソース性能履歴推定処理において、問題リソースの推定性能履歴が生成されるようになる。

Ｓ１２０２で、管理サーバプログラム５４１が、性能テーブルから、対象関連リソースのメトリック名及び期間をキーに、対象関連リソースの実性能履歴を取得する。

Ｓ１２０３で、管理サーバプログラム５４１が、内部変数“推定履歴”に、初期値として、対象関連リソースの実性能履歴を代入する。

対象関連リソースから問題リソースまでの経路である対象経路における全てのエッジについて、Ｓ１２０４〜Ｓ１２０７が実行される。なお、エッジは、対象関連リソース側から問題リソース側へと順次に選択される。以下、１つのエッジを例に取る（図１２の説明において「対象エッジ」と言う）。

Ｓ１２０４で、管理サーバプログラム５４１が、変換元リソース及び変換先リソースの各々について、リソース名をキーに、リソースタイプ一覧から、リソースタイプ名を取得する。ここで、「変換元リソース」は、対象エッジの両端のリソースのうちの対象関連リソース側のリソースである。「変換先リソース」は、対象エッジの両端のリソースのうちの問題リソース側のリソースである。

Ｓ１２０５で、管理サーバプログラム５４１が、変換元リソースタイプ名（変換元リソースのリソースタイプ名）、変換元メトリック名（変換元リソースのメトリック名）、変換先リソースタイプ名（変換先リソースのリソースタイプ名）及び変換先メトリック名（変換先リソースのメトリック名）をキーに、推定に使用する相関関数の関数名を相関関数関連テーブル５５０より取得する。

Ｓ１２０６で、管理サーバプログラム５４１が、取得した関数名をキーに、相関関数定義テーブル６００から相関関数を取得し、内部変数“推定履歴”に代入されている性能履歴を、その取得した相関関数を用いて、別の性能履歴に変換する。

Ｓ１２０７で、管理サーバプログラム５４１が、変換後の推定履歴（Ｓ１２０６での別の性能履歴）を、内部変数“推定履歴”に代入する。

対象経路から、対象関連リソース側から問題リソース側へと順次にエッジが選択され、選択されたエッジについて、Ｓ１２０４〜Ｓ１２０７が実行される。これにより、例えば図１２に例示するように、対象経路が４つのエッジを含む場合、４回の性能履歴変換、すなわち、（１）対象関連リソース“Ｐｏｒｔ３”の実性能履歴からその親リソース“ＦＣ Ｓｗｉｔｃｈ４”の推定性能履歴への変換、（２）リソース“ＦＣ Ｓｗｉｔｃｈ４”の推定性能履歴からその親リソース“ＤＳ３”の推定性能履歴への変換、（３）リソース“ＤＳ３”の推定性能履歴からその親リソース“ＨＶ４”の推定性能履歴への変換、及び、（４）リソース“ＨＶ４”の推定性能履歴からその親リソース（問題リソース）“ＶＭ２１”の推定性能履歴への変換、が実行される。全てのエッジについてＳ１２０４〜Ｓ１２０７が行われた場合の内部変数“推定履歴”に設定されている性能履歴が、問題リソースの推定性能履歴である。

一変形例では、対象経路におけるエッジの数に関わらず、性能履歴変換は１回、すなわち、対象関連リソースの実性能履歴から問題リソースの推定性能履歴に直接的に変換されてもよい。しかし、本実施例のように、対象関連リソース側から問題リソース側へと、エッジの選択と、選択されたエッジについて性能履歴変換とを、順次に行っていくことで、次の効果を期待できる。すなわち、リソース属性（リソースタイプ及びメトリック）の全ての組合せについて相関関数を用意すること無しに（すなわち、リソース属性間に介在する１以上のリソース属性の各々を考慮すること無しに）、言い換えれば、相関関数関連テーブル５５０の情報量を抑えつつ、問題リソースの性能推定履歴の正確性を高めることが期待できる。

以上、一実施例を説明したが、これは本発明の説明のための例示であって、本発明の範囲をこの実施例にのみ限定する趣旨ではない。本発明は、他の種々の形態でも実施することが可能である。例えば、本発明は、問題リソースのボトルネック候補リソースを特定するケースに限らず、リソース間の関係性を特定する他のケースにも適用できる。また、例えば、本発明は、相関関数以外の変換方法が採用されるケースにも適用できる。

１００：計算機システム ５５５：管理クライアント ５５７：管理サーバ

Claims (15)

1. 複数の変換方法を表す情報を含んだ管理情報の少なくとも一部を記憶する１以上のメモリを含んだ記憶部と、
   前記記憶部に接続された１以上のプロセッサであるプロセッサ部と
   を有し、
   前記プロセッサ部が、
   （Ａ）複数のリソースを有する計算機システムのうちの１以上の第１のリソースの各々について、その第１のリソースのリソース属性に従う実性能変化情報を、前記計算機システムのうちの第２のリソースのリソース属性に従う推定性能変化情報に変換する変換処理を実行し、
   前記複数のリソースは、リソース属性が異なる２以上のリソースを含み、
   前記複数のリソースの各々について、リソース属性は、リソースタイプ及びメトリックのうちの少なくとも１つであり、
   前記１以上の第１のリソースと前記第２のリソースの各々について、性能変化情報は、そのリソースのメトリック値の時系列変化を表す情報であり、
   前記１以上の第１のリソースの各々について、その第１のリソースの実性能変化情報は、その第１のリソースについて測定されたメトリック値の時系列変化を表す情報であり、
   前記１以上の第１のリソースの各々について、前記第２のリソースの推定性能変化情報は、その第１のリソースのリソース属性と前記第２のリソースのリソース属性とに対応した１以上の変換方法を用いてその第１のリソースの実性能変化情報が変換された性能変化情報であり、
   前記複数の変換方法の各々は、リソース属性に従う性能変化情報を別のリソース属性に従う性能変化情報に変換するための方法であり、
   前記１以上の第１のリソースの各々は、前記計算機システムのトポロジーにおいて前記第２のリソースに関連するリソースであり、
   （Ｂ）前記１以上の第１のリソースの各々について、前記第２のリソースの推定性能変化情報と前記第２のリソースの実性能変化情報との差分に従いその第１のリソースと前記第２のリソースとの関係性を算出し、
   前記第２のリソースの実性能変化情報は、その第２のリソースについて測定されたメトリック値の時系列変化を表す情報であり、
   （Ｃ）前記１以上の第１のリソースの各々について算出された関係性に基づく情報である処理結果情報を表示し、
   前記処理結果情報は、前記１以上の第１のリソースのうちの少なくとも１つに関する情報を含む、
   管理システム。
2. 前記１以上の第１のリソースの少なくとも１つについて、その第１のリソースと前記第２のリソースとの間に１以上のリソースである１以上の中間リソースが存在する場合、前記変換処理は、その第１のリソースから前記第２のリソースにかけてリソース間で性能変換情報の変換を順次に行っていく処理である順次変換処理である、
   請求項１記載の管理システム。
3. 前記１以上の第１のリソースの少なくとも１つについての前記順次変換処理において、前記プロセッサ部は、
   （ａ１）性能変化情報の変換が未だのエッジである未処理エッジがその第１のリソースと前記第２のリソース間にあるか否かを判断し、
   （ａ２）（ａ１）の判断結果が真の場合、最も第１のリソース寄りの未処理エッジについて、変換元リソース属性と変換先リソース属性とに対応した変換方法を用いて、その変換元リソース属性に従う性能変化情報をその変換先リソース属性に従う推定性能変化情報に変換し、（ａ１）に戻り、
   当該未処理エッジについて、変換元リソース属性は、当該未処理エッジについての変換元リソースのリソース属性であり、
   当該未処理エッジについて、変換先リソース属性は、当該未処理エッジについての変換先リソースのリソース属性であり、
   当該未処理エッジについて、変換元リソースは、当該未処理エッジの両端のリソースのうちの、当該第１のリソース側のリソースであり、
   当該未処理エッジについて、変換先リソースは、当該未処理エッジの両端のリソースのうちの、前記第２のリソース側のリソースであり、
   （ａ３）（ａ１）の判断結果が偽の場合、当該順次変換処理を終了する、
   請求項２記載の管理システム。
4. 前記処理結果情報に関し、前記１以上の第１のリソースの少なくとも１つは、算出された関係性が所定値以上である第１のリソースである、
   請求項１記載の管理システム。
5. 前記第２のリソースは、問題が生じているリソースである問題リソースであり、
   前記１以上の第１のリソースの少なくとも１つは、前記問題リソースのボトルネックの候補である、
   請求項４記載の管理システム。
6. 前記第２のリソースは、問題が生じているリソースである問題リソースである、
   請求項１記載の管理システム。
7. 前記複数の変換方法のうちの少なくとも１つは、相関関数を含み、
   前記１以上の第１のリソースの各々について、算出された関係性は、相関係数である、
   請求項１記載の管理システム。
8. （Ａ）複数のリソースを有する計算機システムのうちの１以上の第１のリソースの各々について、その第１のリソースのリソース属性に従う実性能変化情報を、前記計算機システムのうちの第２のリソースのリソース属性に従う推定性能変化情報に変換する変換処理を実
   前記複数のリソースは、リソース属性が異なる２以上のリソースを含み、
   前記複数のリソースの各々について、リソース属性は、リソースタイプ及びメトリックのうちの少なくとも１つであり、
   前記１以上の第１のリソースと前記第２のリソースの各々について、性能変化情報は、そのリソースのメトリック値の時系列変化を表す情報であり、
   前記１以上の第１のリソースの各々について、その第１のリソースの実性能変化情報は、その第１のリソースについて測定されたメトリック値の時系列変化を表す情報であり、
   前記１以上の第１のリソースの各々について、前記第２のリソースの推定性能変化情報は、予め用意された管理情報が表す複数の変換方法のうちの、その第１のリソースのリソース属性と前記第２のリソースのリソース属性とに対応した１以上の変換方法を用いて、その第１のリソースの実性能変化情報が変換された性能変化情報であり、
   前記複数の変換方法の各々は、リソース属性に従う性能変化情報を別のリソース属性に従う性能変化情報に変換するための方法であり、
   前記１以上の第１のリソースの各々は、前記計算機システムのトポロジーにおいて前記第２のリソースに関連するリソースであり、
   （Ｂ）前記１以上の第１のリソースの各々について、前記第２のリソースの推定性能変化情報と前記第２のリソースの実性能変化情報との差分に従いその第１のリソースと前記第２のリソースとの関係性を算出し、
   前記第２のリソースの実性能変化情報は、その第２のリソースについて測定されたメトリック値の時系列変化を表す情報であり、
   （Ｃ）前記１以上の第１のリソースの各々について算出された関係性に基づく情報である処理結果情報を表示し、
   前記処理結果情報は、前記１以上の第１のリソースのうちの少なくとも１つに関する情報を含む、
   をコンピュータに実行させるためのコンピュータプログラムを記録した記録媒体。
9. 前記１以上の第１のリソースの少なくとも１つについて、その第１のリソースと前記第２のリソースとの間に１以上のリソースである１以上の中間リソースが存在する場合、前記変換処理は、その第１のリソースから前記第２のリソースにかけてリソース間で性能変換情報の変換を順次に行っていく処理である順次変換処理である、
   請求項８記載のコンピュータプログラム。
10. 前記１以上の第１のリソースの少なくとも１つについての前記順次変換処理において、
    （ａ１）性能変化情報の変換が未だのエッジである未処理エッジがその第１のリソースと前記第２のリソース間にあるか否かを判断し、
    （ａ２）（ａ１）の判断結果が真の場合、最も第１のリソース寄りの未処理エッジについて、変換元リソース属性と変換先リソース属性とに対応した変換方法を用いて、その変換元リソース属性に従う性能変化情報をその変換先リソース属性に従う推定性能変化情報に変換し、（ａ１）に戻り、
    当該未処理エッジについて、変換元リソース属性は、当該未処理エッジについての変換元リソースのリソース属性であり、
    当該未処理エッジについて、変換先リソース属性は、当該未処理エッジについての変換先リソースのリソース属性であり、
    当該未処理エッジについて、変換元リソースは、当該未処理エッジの両端のリソースのうちの、当該第１のリソース側のリソースであり、
    当該未処理エッジについて、変換先リソースは、当該未処理エッジの両端のリソースのうちの、前記第２のリソース側のリソースであり、
    （ａ３）（ａ１）の判断結果が偽の場合、当該順次変換処理を終了する、
    請求項９記載のコンピュータプログラム。
11. 前記処理結果情報に関し、前記１以上の第１のリソースの少なくとも１つは、算出された関係性が所定値以上である第１のリソースである、
    請求項８記載のコンピュータプログラム。
12. 前記第２のリソースは、問題が生じているリソースである問題リソースであり、
    前記１以上の第１のリソースの少なくとも１つは、前記問題リソースのボトルネックの候補である、
    請求項１１記載のコンピュータプログラム。
13. 前記第２のリソースは、問題が生じているリソースである問題リソースである、
    請求項８記載のコンピュータプログラム。
14. 前記複数の変換方法のうちの少なくとも１つは、相関関数を含み、
    前記１以上の第１のリソースの各々について、算出された関係性は、相関係数である、
    請求項８記載のコンピュータプログラム。
15. （Ａ）複数のリソースを有する計算機システムのうちの１以上の第１のリソースの各々について、その第１のリソースのリソース属性に従う実性能変化情報を、前記計算機システムのうちの第２のリソースのリソース属性に従う推定性能変化情報に変換する変換処理を実
    前記複数のリソースは、リソース属性が異なる２以上のリソースを含み、
    前記複数のリソースの各々について、リソース属性は、リソースタイプ及びメトリックのうちの少なくとも１つであり、
    前記１以上の第１のリソースと前記第２のリソースの各々について、性能変化情報は、そのリソースのメトリック値の時系列変化を表す情報であり、
    前記１以上の第１のリソースの各々について、その第１のリソースの実性能変化情報は、その第１のリソースについて測定されたメトリック値の時系列変化を表す情報であり、
    前記１以上の第１のリソースの各々について、前記第２のリソースの推定性能変化情報は、予め用意された管理情報が表す複数の変換方法のうちの、その第１のリソースのリソース属性と前記第２のリソースのリソース属性とに対応した１以上の変換方法を用いて、その第１のリソースの実性能変化情報が変換された性能変化情報であり、
    前記複数の変換方法の各々は、リソース属性に従う性能変化情報を別のリソース属性に従う性能変化情報に変換するための方法であり、
    前記１以上の第１のリソースの各々は、前記計算機システムのトポロジーにおいて前記第２のリソースに関連するリソースであり、
    （Ｂ）前記１以上の第１のリソースの各々について、前記第２のリソースの推定性能変化情報と前記第２のリソースの実性能変化情報との差分に従いその第１のリソースと前記第２のリソースとの関係性を算出し、
    前記第２のリソースの実性能変化情報は、その第２のリソースについて測定されたメトリック値の時系列変化を表す情報であり、
    （Ｃ）前記１以上の第１のリソースの各々について算出された関係性に基づく情報である処理結果情報を表示し、
    前記処理結果情報は、前記１以上の第１のリソースのうちの少なくとも１つに関する情報を含む、
    方法。