(57)【特許請求の範囲】
【請求項１】
管理計算機を用いた計算機システムの管理方法であって、
前記管理計算機は、
前記計算機システム内の複数のリソースのうち過去の期間の前記計算機システムの性能低下の原因であるボトルネックリソースに対し、前記期間の前記ボトルネックリソースの負荷の時系列データであるボトルネック負荷データを取得し、
前記複数のリソースのうち前記ボトルネックリソースの負荷に影響を与える関連リソースに対し、前記期間の前記関連リソースの負荷の時系列データである関連負荷データを取得し、
前記ボトルネック負荷データに基づいてボトルネック負荷範囲を算出し、前記ボトルネック負荷データ内の全ての値が前記ボトルネック負荷範囲内である場合、前記ボトルネック負荷データの傾向が安定的であると判定し、
前記ボトルネック負荷データの傾向が安定的であると判定された場合、前記計算機システムの操作に必要なパラメータの決定の方針を示す複数の対策方針候補の中から、前記性能低下を解消するための対策方針を選択し、
前記対策方針と前記関連負荷データの傾向とに基づいて、夫々が前記計算機システムの操作を示す複数の対策手段候補の中から、前記性能低下を解消するための対策手段を選択し、
前記対策方針に基づいて、前記対策手段のパラメータを決定する、
管理方法。
【請求項２】
前記管理計算機は、前記ボトルネック負荷データの傾向が安定的であると判定された場合、前記ボトルネック負荷データの傾向の判定の結果に基づいて、前記対策方針を選択する、
請求項１に記載の管理方法。
【請求項３】
前記管理計算機は、前記ボトルネック負荷データの傾向が安定的であると判定された場合、前記期間の全体に亘って前記ボトルネックリソースの負荷を低下させる対策方針候補を、前記対策方針として選択する、
請求項２に記載の管理方法。
【請求項４】
前記管理計算機は、前記ボトルネック負荷データの傾向が安定的でないと判定された場合、前記期間内の前記ボトルネックリソースの負荷のピーク値を低下させる対策方針候補を、前記対策方針として選択する、
請求項３に記載の管理方法。
【請求項５】
前記管理計算機は、
前記複数のリソースのうち前記ボトルネックリソースに影響を与える複数の関連リソースに対し、複数の関連負荷データを夫々取得し、
各関連負荷データに基づいて関連負荷範囲を算出し、各関連負荷データ内の全ての値が、対応する関連負荷範囲内である場合、対応する関連負荷データの傾向が安定的であると判定し、
前記対応する関連負荷データの傾向が安定的であると判定された場合、前記複数の関連負荷データの傾向の判定の結果に基づいて前記対策手段を選択する、
請求項４に記載の管理方法。
【請求項６】
前記複数の対策手段候補の中の第１対策手段候補は、前記ボトルネックリソース内の前記関連リソースを前記計算機システム内で前記ボトルネックリソースと同種の別のリソースへ移動させることを示し、
前記管理計算機は、前記ボトルネック負荷データの傾向が安定的であると判定され、且つ、前記複数の関連負荷データのうち、安定的であると判定された関連負荷データの数が、安定的でないと判定された関連負荷データの数よりも少ない場合、前記複数の対策手段候補の中から前記第１対策手段候補以外の対策手段候補を、前記対策手段として選択する、
請求項５に記載の管理方法。
【請求項７】
前記複数の対策手段候補の中の第２対策手段候補は、前記関連リソースの負荷を削減することを示し、
前記管理計算機は、前記ボトルネック負荷データの傾向が安定的でないと判定され、且つ前記複数の関連負荷データのうち、安定的であると判定された関連負荷データの数が、安定的でないと判定された関連負荷データの数よりも少ない場合、前記複数の対策手段候補の中から前記第２対策手段候補以外の対策手段候補を、前記対策手段として選択する、
請求項６に記載の管理方法。
【請求項８】
前記ボトルネックリソースがプールであり、前記関連リソースがＶＭ（virtual machine）である場合、前記第１対策手段候補は、前記ＶＭのデータを別のプールへ移動させることである、
請求項７に記載の管理方法。
【請求項９】
前記ボトルネックリソースが前記プールであり、前記関連リソースが前記ＶＭである場合、前記第２対策手段候補は、前記ＶＭのＩ／Ｏ量を制限することである、
請求項８に記載の管理方法。
【請求項１０】
前記管理計算機は、
前記関連負荷データの傾向毎に、前記対策方針と前記関連負荷データの傾向とに基づいて、対応する関連リソースを用いる前記対策手段を選択することで、複数の対策手段を決定し、
前記関連負荷データの傾向毎に、前記対策方針に基づいて、対応する対策手段のパラメータを決定する、
請求項５に記載の管理方法。
【請求項１１】
前記管理計算機は、前記決定された対策手段と前記決定されたパラメータとを、表示装置に表示させる、
請求項１に記載の管理方法。
【請求項１２】
メモリと、
前記メモリおよび計算機システムに接続されるプロセッサと、
を備え、
前記プロセッサは、
前記計算機システム内の複数のリソースのうち過去の期間の前記計算機システムの性能低下の原因であるボトルネックリソースに対し、前記期間の前記ボトルネックリソースの負荷の時系列データであるボトルネック負荷データを取得し、
前記複数のリソースのうち前記ボトルネックリソースの負荷に影響を与える関連リソースに対し、前記期間の前記関連リソースの負荷の時系列データである関連負荷データを取得し、
前記ボトルネック負荷データに基づいてボトルネック負荷範囲を算出し、前記ボトルネック負荷データ内の全ての値が前記ボトルネック負荷範囲内である場合、前記ボトルネック負荷データの傾向が安定的であると判定し、
前記ボトルネック負荷データの傾向が安定的であると判定された場合、前記計算機システムの操作に必要なパラメータの決定の方針を示す複数の対策方針候補の中から、前記性能低下を解消するための対策方針を選択し、
前記対策方針と前記関連負荷データの傾向とに基づいて、夫々が前記計算機システムの操作を示す複数の対策手段候補の中から、前記性能低下を解消するための対策手段を選択し、
前記対策方針に基づいて、前記対策手段のパラメータを決定する、
管理計算機。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、管理方法に関する。
【背景技術】
【０００２】
計算機システムの運用管理においては、サーバやストレージシステムといったシステム構成要素の性能を監視し、性能低下が検知された場合には性能が自然と回復したか否かに限らず、将来的に性能低下が再発しないように構成変更等の対策を講じる必要がある。しかしながら、実施し得る構成変更手段と構成変更手段のパラメータとの組み合わせは大量である。そのため、管理者負担軽減のためには性能低下再現を抑止する対策案を提案する支援が重要である。【０００３】
特許文献１によれば、ストレージシステム内の論理ボリュームに対するＩ／Ｏ量が変化して所定の要求性能を満たさなくなった場合に、要求性能を満たさなくなった時点の構成情報、性能情報、及び容量消費傾向を基に、将来時点で論理ボリュームの要求性能を満たす状態とする構成変更案を生成し、最も適切な構成変更案を表示することができる。また、将来の構成変更予定の情報を基に、将来のストレージシステムの消費容量と構成変化を予測し、構成変更実施予定時刻において実施することができる構成変更案のみを表示することができる。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】国際公開第２０１４／０７３０４５号
【発明の概要】
【発明が解決しようとする課題】
【０００５】
上述の特許文献１は、論理ボリュームの所定の要求性能を満たさなくなった時点、及び構成変更に要する時間を加味した構成変更終了時点の、構成情報と性能情報を基に、要求性能を満たすことができる構成変更案を生成する。【０００６】
しかしながら、変化が緩やかな容量消費傾向に比べて性能はアプリケーションのワークロードに応じて刻々と大きく変化する。そのため、特許文献１に基づき特定時点のみの情報を用いて生成した対策案では、性能低下時の負荷が再度発生した場合に、着目した時点に関しては性能低下再発が抑止されたとしても、それ以外の時点では適切な性能改善効果が見込めず性能低下が発生する可能性がある。【０００７】
一方で、前述の通り性能は刻々と変化するため、性能低下再現を防ぎたい複数の過去時点について、特許文献１に基づき対策案を生成したとしても、着目する時点によって生成される対策案が異なる可能性がある。全ての時点について適切な対策案を生成しようとすると、膨大な計算時間が必要になる。
【課題を解決するための手段】
【０００８】
上記課題を解決するために、本発明の一態様である管理方法は、計算機システム内の複数のリソースのうち過去の期間の前記計算機システムの性能低下の原因であるボトルネックリソースに対し、前記期間の前記ボトルネックリソースの負荷の時系列データであるボトルネック負荷データを取得し、前記複数のリソースのうち前記ボトルネックリソースの負荷に影響を与える関連リソースに対し、前記期間の前記関連リソースの負荷の時系列データである関連負荷データを取得し、前記ボトルネック負荷データの傾向に基づいて、前記計算機システムの操作に必要なパラメータの決定の方針を示す複数の対策方針候補の中から、前記性能低下のための対策方針を選択し、前記対策方針と前記関連負荷データの傾向とに基づいて、夫々が前記計算機システムの操作を示す複数の対策手段候補の中から、前記性能低下のための対策手段を選択し、前記対策方針に基づいて、前記対策手段のパラメータを決定する、ことを備える。
【発明の効果】
【０００９】
期間に亘って適切な対策案を、迅速に生成することができる。
【図面の簡単な説明】
【００１０】
【図１】実施例１に係る管理計算機の動作の概要を示す。
【図２】実施例１に係る計算機システムのハードウェア構成を示す。
【図３】実施例１に係る管理計算機のハードウェア構成を示す。
【図４】実施例１に係る計算機システムの論理構成を示す。
【図５】ＶＭ管理テーブル１１０１を示す。
【図６】ホスト管理テーブル１１０２を示す。
【図７】ストレージボリューム管理テーブル１１０３を示す。
【図８】しきい値管理テーブル１１０４を示す。
【図９】性能管理テーブル１１０５を示す。
【図１０】対策手段管理テーブル１１０６を示す。
【図１１】メトリック管理テーブル１１０７を示す。
【図１２】対策手段適用管理テーブル１１０８を示す。
【図１３】選択手段保持テーブル１１０９を示す。
【図１４】性能監視処理のフローチャートである。
【図１５】対策案生成処理のフローチャートである。
【図１６】Ｓｃｒｉｐｔ１のフローチャートである。
【図１７】Ｓｃｒｉｐｔ２のフローチャートである。
【図１８】Ｓｃｒｉｐｔ３のフローチャートである。
【図１９】Ｓｃｒｉｐｔ４のフローチャートである。
【図２０】対策方針判断処理（Ｓ２０２０）を示すフローチャートである。
【図２１】対策手段選択処理（Ｓ２０３０）を示すフローチャートである。
【図２２】実施例２に係る対策手段選択処理（Ｓ２０３０）を示すフローチャートである。
【図２３】実施例２に係る対策手段組み合わせ生成処理を示すフローチャートである。
【発明を実施するための形態】
【００１１】
幾つかの実施例について、図面を参照して説明する。なお、以下に説明する実施例は請求の範囲にかかる発明を限定するものではなく、また実施例の中で説明されている諸要素及びその組み合わせの全てが発明の解決手段に必須であるとは限らない。
【００１２】
なお、以下の説明では、「ａａａテーブル」の表現にて各種情報を説明することがあるが、各種情報は、テーブル以外のデータ構造で表現されていても良い。データ構造に依存しないことを示すために「ａａａテーブル」を「ａａａ情報」と呼ぶことができる。さらに、テーブル内の各列の値からなる情報要素を欄またはエントリと呼び、「ａａａテーブル」のエントリを、説明のために、「ａａａテーブルエントリ」と称する。
【００１３】
また、以下の説明では、単に管理計算機及びサーバを主語として処理を説明する場合があるが、これら処理は、計算機が備える制御デバイスが有するプロセッサ（例えば、ＣＰＵ（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ））によって、実行されていることを示す。同様に、単にストレージ装置を主語として処理を説明する場合には、ストレージ装置が備えるコントローラが実行していることを示す。また、上記制御デバイス及びコントローラのうちの少なくとも１つは、プロセッサそれ自体であっても良いし、制御デバイス又はコントローラが行う処理の一部又は全部を行うハードウェア回路を含んでも良い。
【００１４】
プログラムは、プログラムソースから各計算機或いはストレージ装置にインストールされても良い。プログラムソースは、例えば、プログラム配布サーバ又は記憶メディアであっても良い。
【００１５】
以降の説明においては、構成変更操作（例えばＶＭを移動する、オーナー権を変更する）や設定変更操作（例えばＩ／Ｏ量に上限を設定する）などの操作のことを対策手段と記載し、対策手段を実施する際に入力する必要がある設定値のことをパラメータと記載する。また、対策手段とパラメータの組み合わせのことを対策案やプランと記載する。
【実施例１】
【００１６】
（１−１）本実施例の形態の概要【００１７】
図１は、実施例１に係る管理計算機の動作の概要を示す。【００１８】
この図は、計算機システム１０における性能低下対策案の生成指示方法の例と、性能低下対策案の提示例、及び対策案生成の流れを示す。【００１９】
管理計算機１００は、計算機システム１０と、表示装置４００とに接続される。計算機システム１０は、サーバ２００と、ストレージ装置３００とを含む。また、サーバ２００ではＶＭ７００が稼動していてもよい。これらの詳細は後述する。表示装置４００は、入力装置を含んでいてもよいし、端末装置であってもよい。計算機システムは、サーバ２００とストレージ装置３００の何れか一つであってもよいし、ＶＭとボリュームを提供する一つの計算機であってもよい。【００２０】
本実施例の概要を示すための一例として、図１ではストレージ装置３００内のボリューム１に関して、性能低下が発生し要求性能を下回る状態が発生した場合を示している。以下、本実施例における処理の流れを説明する。【００２１】
まず、管理計算機１００が計算機システムの性能低下を検知すると、管理者に対してアラートを発行する。アラートを受領すると管理者は、過去の任意期間を指定期間として指定して、指定期間の負荷が再度発生しても性能低下が再発しないことを目的とする対策案の生成を開始する。指定期間の指定の方法は例えば、表示装置４００に表示された画面に、指定期間の開始時刻と終了時刻を入力する方法でも良いし、負荷変化を示すグラフ上の点をポイントする、グラフ上の時刻を表す線分を移動させるなどの方法であっても良い。【００２２】
また、管理計算機１００が、性能低下を検知した場合に、指定期間を設定し、自動的に対策案の生成を開始してもよい。【００２３】
管理計算機１００は、対策方針判断モジュールと、対策手段選択モジュールと、対策案生成モジュールとを含む。管理計算機１００が、表示装置４００から指定期間を指定され性能低下への対策を指示されると、対策方針判断モジュールは、性能低下が発生した計算機システムの構成要素（以降、構成要素のことをリソースと呼び、特に性能低下の原因であるリソースをボトルネックリソースと呼ぶ）の指定期間における負荷情報を参照し、負荷の傾向である負荷傾向を分析する。そして、対策方針判断モジュールは、分析結果を元に、ボトルネックリソースの性能低下が再現したと仮定した場合に、その性能低下を効率的に解消することができる対策案の生成方針（以降、簡単のために対策方針と記載する）を決定する。この図の例において、ボトルネックリソースは、ストレージ装置３００のボリューム１であり、ボトルネックリソースの負荷は、稼働率で表される。【００２４】
次に、対策手段選択モジュールは、ボトルネックリソースの負荷を増加させている原因である（ボトルネックリソースの負荷に影響を与える）、計算機システムの構成要素（以降、簡単のために関連リソースと呼ぶ）の指定期間における負荷情報を参照し、各関連リソースの負荷傾向を分析する。そして、その分析結果を元に、先に決定した対策方針の下で、性能低下の解消の効果がある対策手段のみを選択する。この図の例において、関連リソースは、サーバ２００のＶＭ１、ＶＭ２であり、関連リソースの負荷は、Ｉ／Ｏ量で表される。【００２５】
その後、対策案生成モジュールは、先に決定した対策手段のパラメータの計算方法を決定する。そして、決定した計算方法に基づいてパラメータ（対策手段の設定値）を決定する。【００２６】
この図の例において、対策方針判断モジュールは、ボトルネックリソース負荷傾向に基づいて、対策方針として、各時点の負荷を均一に押し下げることを選択する。対策手段選択モジュールは、対策方針と関連リソース負荷傾向とに基づいて、対策手段として、ストレージ側Ｉ／Ｏ量制限を選択する。対策案生成モジュールは、制限するＩ／Ｏ量を決定する。【００２７】
管理計算機１００は、決定した対策案を表示装置４００に表示させる。表示方法は、例えば対策手段（Method）とそのパラメータ（Detail）を、テキストで表示する方法であっても良い。また、表示される内容は、対策手段とパラメータ以外の要素、例えば対策案の概要などの付加情報を含んでもよく、複数の対策案を表示してもよい。【００２８】
また、対策案は、表示装置４００に表示されるのみではなく、ファイルなどの電子データとして保存されてもよい。【００２９】
（１−２）計算機システムのハードウェア構成【００３０】
図２は、実施例１に係る計算機システムのハードウェア構成を示す。【００３１】
サーバ２００が例えばＬＡＮ（Ｌｏｃａｌ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）などの第１の通信ネットワーク５００を介して、管理計算機１００、ストレージ装置３００、表示装置４００に接続されている。また、サーバ２００は例えばＳＡＮ（Ｓｔｏｒａｇｅ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）などの第２の通信ネットワーク６００を介してストレージ装置３００と接続されている。なお、第１の通信ネットワーク５００と第２の通信ネットワーク６００は一体に形成されていてもよい。【００３２】
管理計算機１００は、例えばＮＩＣ（Ｎｅｔｗｏｒｋ  Ｉｎｔｅｒｆａｃｅ  Ｃａｒｄ）などのＩ／Ｆ１３０を含む。詳細は図３の説明として後述する。【００３３】
サーバ２００は、プロセッサ２１０と、記憶資源２２０と、管理Ｉ／Ｆ（以下、Ｍ−Ｉ／Ｆと記載）２３０と、通信Ｉ／Ｆ（以下、Ｃ−Ｉ／Ｆと記載）２４０を含んで構成される物理計算機である。【００３４】
Ｍ−Ｉ／Ｆ２３０は第１のプロトコルで通信するための通信インタフェース装置であり、例えばＮＩＣである。Ｃ−Ｉ／Ｆ２４０は第２のプロトコルで通信するためのインタフェース装置であり、例えばＨＢＡ（Ｈｏｓｔ  Ｂｕｓ  Ａｄａｐｔｅｒ）である。【００３５】
記憶資源２２０は例えばメモリであり、ＨＤＤ（Ｈａｒｄ  Ｄｉｓｋ  Ｄｒｉｖｅ）などの補助記憶装置を含んでも良い。記憶資源２２０は、例えばＯＳ（Ｏｐｅｒａｔｉｎｇ  Ｓｙｓｔｅｍ）や業務アプリケーションなどのアプリケーション・プログラムを記憶し、プロセッサ２１０がそのアプリケーション・プログラムやＯＳを実行する。【００３６】
ストレージ装置３００は、記憶デバイス群３６０と、記憶デバイス群３６０に接続されたコントローラ３９０とを有する。記憶デバイス群３６０は１以上の記憶デバイスから構成される。記憶デバイスは、例えばＳＳＤ（Ｓｏｌｉｄ  Ｓｔａｔｅ  Ｄｒｉｖｅ）であり、ＨＤＤや、ＦｅＲＡＭといったその他の不揮発性メモリであってもよい。このように、ストレージ装置３００は性能の異なる複数の記憶デバイスが混在していてもよい。なお、記憶デバイス群３６０はストレージ装置３００の外部から提供されるものであってもよい。【００３７】
コントローラ３９０は、メモリ３２０と、Ｍ−Ｉ／Ｆ３３０と、Ｃ−Ｉ／Ｆ３４０と、デバイスＩ／Ｆ（Ｄ−Ｉ／Ｆ）３５０と、キャッシュメモリ３８０と、それらに接続されたプロセッサ３１０を有する。【００３８】
Ｄ−Ｉ／Ｆ３５０は第３のプロトコルで記憶デバイスと通信するための通信インタフェース装置である。Ｄ−Ｉ／Ｆ３５０は、記憶デバイスの種類毎に有していてもよい。【００３９】
メモリ３２０は、プロセッサ３１０で実行されるコンピュータプログラムや、種々の情報を記憶する。また、キャッシュメモリ３８０は、サーバ２００から受けたライトコマンドに従うデータや、サーバ２００から受けたリードコマンドに応答して、記憶デバイスから読み出されたデータが一時格納される。なお、メモリ３２０とキャッシュメモリ３８０は一体の装置であってもよい。【００４０】
表示装置４００は、例えばディスプレイとキーボードとポインタデバイス等の入出力デバイスを含む装置であるが、これ以外のデバイスであってもよい。また、入出力デバイスの代替としてシリアルインタフェースやイーサーネットインタフェースを入出力デバイスとし、当該インタフェースにディスプレイ又はキーボード又はポインタデバイスを有する表示用計算機を接続し、表示用情報を表示用計算機に送信したり、入力用情報を表示用計算機から受信することで、表示用計算機で表示を行ったり、入力を受け付けることで入出力デバイスでの入力及び表示を代替してもよい。また、表示装置４００は、管理計算機１００や、サーバ２００と一体として形成してもよい。【００４１】
以上が、実施例１に係る計算機システムのハードウェア構成である。なお、処理の高速化や信頼性向上のために、管理計算機１００、サーバ２００、ストレージ装置３００は複数接続されていてもよい。【００４２】
図３は、実施例１に係る管理計算機のハードウェア構成を示す。【００４３】
管理計算機１００は、記憶資源１１０と、通信インタフェース（Ｉ／Ｆ）１３０と、それらに接続されたプロセッサ１２０を含んで構成される。【００４４】
記憶資源１１０は、例えばメモリであり、ＨＤＤ等の補助記憶装置を含んでも良い。記憶資源１１０は、種々の情報と、プロセッサ１２０によって実行されるプログラムを記憶する。具体的には、情報として、ＶＭ管理テーブル１１０１、ホスト管理テーブル１１０２、ストレージボリューム管理テーブル１１０３、しきい値管理テーブル１１０４、性能管理テーブル１１０５、対策手段管理テーブル１１０６、メトリック管理テーブル１１０７、対策手段適用管理テーブル１１０８、選択手段保持テーブル１１０９が記憶され、プログラムとして、監視プログラム１１２１、対策案生成プログラム１１２２、対策方針判断プログラム１１２３、対策手段選択プログラム１１２４、パラメータ計算スクリプト群１１３が記憶される。【００４５】
（１−３）計算機システムの論理構成【００４６】
図４は、実施例１に係る計算機システムの論理構成を示す。【００４７】
ストレージ装置３００は、複数のボリューム３７０を有する。ボリュームは例えば後述する論理ボリューム、仮想ボリューム、ダイナミック仮想ボリュームであってもよい。【００４８】
論理ボリュームは記憶デバイスの物理記憶領域（物理ページと呼ぶ）から構成されたボリュームである。ストレージ装置３００の内部において、複数の記憶デバイスをＲＡＩＤ（Ｒｅｄｕｎｄａｎｔ  Ａｒｒａｙｓ  ｏｆ  Ｉｎｄｅｐｅｎｄｅｎｔ  Ｄｉｓｋｓ）技術でまとめた記憶デバイスのグループをＲＡＩＤグループと呼ぶ（図示せず）。論理ボリュームは、ＲＡＩＤグループの一部物理領域を切り出し、計算機から論理的に１つの記憶資源としてアクセス可能としたＬＵ（Ｌｏｇｉｃａｌ  Ｕｎｉｔ）である。【００４９】
仮想ボリュームは、ストレージ装置３００のシンプロビジョニング機構により実現される仮想的なボリュームである。シンプロビジョニング機構は、複数の論理ボリュームの論理的な記憶領域（論理ページと呼ぶ）からプールを構成する（図示せず）。そして、シンプロビジョニング機構は、仮想ボリュームに対するサーバ２００からのＩ／Ｏを受領したときに、プールから論理ページを仮想ボリュームに割り当てる。これにより、シンプロビジョニング機構は、必要に応じて仮想ボリュームの容量を拡張することができる。【００５０】
ダイナミック仮想ボリュームは、仮想ボリュームに対するＩ／Ｏ量の変化などに対応して、論理ページに対応する物理ページをＩ／Ｏ性能や信頼性の異なる別の記憶デバイスの物理ページに動的に変更することができる仮想ボリュームである。【００５１】
サーバ２００はストレージ装置３００へアクセスする計算機の一例である。サーバ２００はアプリケーション・プログラムを実行することができるＯＳや、ＶＭ７００を論理的に生成して実行することができるハイパバイザ８００を有していてもよい。ハイパバイザ８００は一度に複数のＶＭ８００を制御することができる。夫々のＶＭ８００は、あたかもスタンドアローンの物理計算機のようにアプリケーション・プログラムを実行することができる。【００５２】
ボリューム３７０は、サーバ２００やＶＭ７００のいずれか１つに対して提供される。例えば、汎用的なＯＳを有するサーバ２００に対して提供されたボリューム３７０は、ＯＳから一つの記憶資源として認識される。ハイパバイザ８００を有するサーバ２００に対して提供されたボリューム３７０は、データストアとして認識され、複数のＶＭ７００のデータが格納される。ハイパバイザ８００は、データストアに格納したＶＭのデータを、プロセッサ２１０で実行することでＶＭ７００を提供する。そのため、ＶＭ７００上で設定変更が行われると、ボリューム３７０に対してＩ／Ｏが発生する。また、ボリューム３７０がＶＭ７００に直接に提供されてもよい。その場合、ボリューム３７０はＶＭ７００上から一つの記憶資源として認識される。【００５３】
なお、ハイパバイザ８００は、複数のボリューム３７０を用いてＶＭ７００を構成してもよい。この場合は、ＶＭ７００の制御情報や、ＯＳイメージや、スナップショットなどの各情報が夫々別のボリューム３７０に格納される。【００５４】
ハイパバイザ８００は、あるサーバ２００上で稼動しているＶＭ７００を別のサーバ２００に対して移動する、ＶＭマイグレーションの機能を有していてもよい。また、あるＶＭ７００のデータを別のボリューム３７０に移動させる、ＶＭストレージマイグレーションの機能を有していてもよい。【００５５】
（１−４）各種テーブルの内容【００５６】
図５は、ＶＭ管理テーブル１１０１を示す。【００５７】
ＶＭ管理テーブル１１０１は、ＶＭ７００の各種情報を格納する。ＶＭ管理テーブル１１０１によって、ＶＭ７００を稼動させるサーバ２００およびＶＭ７００のデータを格納するデータストア、ＶＭ７００の各種設定情報、ＶＭ７００の移動先として選択可能なサーバやデータストアの情報などが分かる。管理計算機１００は、定期的にサーバ２００と通信し、サーバ２００で稼動する各ＶＭ７００の各種情報を取得し、ＶＭ管理テーブル１１０１に格納する。【００５８】
具体的にＶＭ管理テーブル１１０１は、ＶＭ毎のエントリに以下の情報を有する。ＶＭＩＤ１１０１０は、当該ＶＭを識別するためのＩＤである。サーバＩＤ１１０１１は、当該ＶＭが稼動しているサーバ２００を識別するためのＩＤである。データストア名１１０１２は、当該ＶＭのデータが格納されているデータストアの名前である。ＣＰＵコア数１１０１３は、当該ＶＭに割り当てられているＣＰＵのコア数である。メモリ量１１０１４は、当該ＶＭが使用可能なメモリ量の最大値である。なお、ＣＰＵコア数１１０１３とメモリ量１１０１４はＶＭ７００の設定値の一例である。ＶＭ管理テーブル１１０１は他の設定値を含んでもよい。【００５９】
移動可能サーバＩＤ１１０１５は、当該ＶＭの移動先となることができるサーバ２００のＩＤである。当該ＶＭの移動先となることができるサーバ２００が無い場合は、“―”が格納される。【００６０】
移動可能データストア名１１０１６は、当該ＶＭのデータの移動先となることができるデータストアの名前である。当該ＶＭのデータの移動先となることができるデータストアが無い場合は、“―”が格納される。【００６１】
図６は、ホスト管理テーブル１１０２を示す。【００６２】
ホスト管理テーブル１１０２は、ストレージ装置３００にアクセスする計算機の各種情報を格納する。ホスト管理テーブル１１０２によって、各計算機が物理計算機かＶＭか、汎用のＯＳが稼動しているかハイパバイザが稼動しているか、の判別ができる。また、サーバ２００の各種構成情報や設定情報が分かる。管理計算機１００は、定期的にサーバ２００やＶＭ７００と通信し、各種情報を取得してホスト管理テーブル１１０２に格納する。【００６３】
具体的にホスト管理テーブル１１０２は、計算機毎のエントリに以下の情報を有する。サーバＩＤ１１０２０は、当該計算機を識別するためのＩＤである。仮想化フラグ１１０２１は、当該計算機がサーバ２００の場合には“Ｎｏ”が格納され、ＶＭ７００の場合は“Ｙｅｓ”が格納される。ＶＭＩＤ１１０２２は、当該計算機がＶＭの場合にＶＭＩＤ１１０１０を格納する。当該計算機がＶＭで無い場合は、“―”が格納される。ＯＳ種類１１０２３は、当該計算機に適用されているＯＳの種類を格納する。当該計算機でハイパバイザが稼動している場合は、値として“ハイパバイザ”が格納される。また、当該計算機で汎用ＯＳが稼動している場合は、ＯＳの種類が判別できる値が格納される。例えば、ＯＳ名が格納される。【００６４】
ＣＰＵコア数１１０２４は、当該計算機がサーバ２００の場合はプロセッサ２１０のコア数が格納され、当該計算機がＶＭ７００の場合は割り当てられているコア数１１０１３の値が格納される。メモリ量１１０２５は、当該計算機がサーバ２００の場合は記憶資源２２０のうちメモリの容量が格納され、計算機がＶＭ７００の場合は割り当てられているメモリ量１１０１４の値が格納される。なお、ＣＰＵコア数１１０２４とメモリ量１１０２５は計算機の設定値の一例である。ホスト管理テーブル１１０２はその他の情報、例えばクラスタリングの構成情報や、電源管理の設定など他の設定値を含んでもよい。ボリュームＩＤ１１０２６は、当該計算機に対して提供されているボリュームの識別ＩＤが格納される。【００６５】
図７は、ストレージボリューム管理テーブル１１０３を示す。【００６６】
ストレージボリューム管理テーブル１１０３は、ストレージ装置３００が提供するボリューム３７０の各種情報を格納する。ストレージボリューム管理テーブル１１０３によって、ストレージ装置３００内部におけるボリューム３７０の構成情報と設定情報とが分かる。例えば、ボリューム３７０とＲＡＩＤグループやプールの関連が分かる。また、ボリューム３７０に対して発行されるＩ／Ｏを制御するためのＣＰＵの割り当て設定などが分かる。さらに、ストレージボリューム管理テーブル１１０３によって、ボリューム３７０の提供を受ける計算機が分かる。管理計算機１００は定期的にサーバ２００、ストレージ装置３００と通信し、ボリューム３７０の各種情報を取得し、ストレージボリューム管理テーブル１１０３に格納する。【００６７】
具体的にはストレージボリューム管理テーブル１１０３は、ボリューム毎のエントリに、以下の情報を有する。ストレージＩＤ１１０３０は、当該ボリュームを有するストレージ装置３００を識別するためのＩＤである。ボリュームＩＤ１１０３１は、当該ボリュームを識別するためのＩＤである。ＲＡＩＤグループＩＤ１１０３２は、当該ボリュームが論理ボリュームである場合に、当該ボリュームが所属するＲＡＩＤグループを識別するためのＩＤである。当該ボリュームが論理ボリュームで無い場合は、“―”の値が格納される。プールＩＤ１１０３３は、当該ボリュームが仮想ボリュームである場合に、当該ボリュームが所属するプールを識別するためのＩＤである。当該ボリュームが仮想ボリュームで無い場合は、“―”の値が格納される。【００６８】
担当ＣＰＵＩＤ１１０３４は、当該ボリュームへのＩ／Ｏ処理や、当該ボリュームに関連するレプリケーションなどのその他のストレージ内部処理を担当するプロセッサ３１０を識別するためのＩＤである。キャッシュメモリＩＤ１１０３５は、当該ボリュームへのＩ／Ｏ処理や、当該ボリュームに関連するレプリケーションなどのその他のデータ処理を担当するキャッシュメモリ３８０を識別するためのＩＤである。キャッシュメモリ容量１１０３６は、当該ボリュームへのＩ／Ｏ処理や、当該ボリュームに関連するレプリケーションなどのその他のデータ処理においてキャッシュとして利用することができる最大容量である。例えば、ストレージ装置３００は、キャッシュメモリ３８０の領域を論理的に分割し、ボリューム３７０毎に利用可能な領域を割り当てる機能を有していてもよい。キャッシュメモリ３８０の領域が論理的に分割されている場合は、キャッシュメモリ容量１１０３６には、当該ボリュームが利用することができるキャッシュメモリ領域の容量が格納され、当該ボリュームのキャッシュメモリ領域への割当状態が変更された場合などにキャッシュメモリ容量１１０３６の値が変更される。なお、担当ＣＰＵＩＤ１１０３４、キャッシュメモリＩＤ１１０３５、キャッシュメモリ容量１１０３６は、当該ボリュームの設定情報の一部である。ストレージボリューム管理テーブル１１０３は、その他の情報、例えばボリューム３７０のレプリケーションに関する設定や、ダイナミック仮想ボリュームの場合には論理ページが配置される記憶デバイスなどの設定を含んでいてもよい。【００６９】
割当サーバＩＤ１１０３７は、当該ボリュームの提供を受けるサーバ２００またはＶＭ７００を識別するＩＤである。データストア名１１０３８は、当該ボリュームがハイパバイザを有するサーバ２００に提供されている場合に、ハイパバイザ上で当該ボリュームに設定されているデータストアの名前である。【００７０】
図８は、しきい値管理テーブル１１０４を示す。【００７１】
しきい値管理テーブル１１０４は、計算機システムを構成する各構成要素について、解消するべき性能低下が発生したと判断するためのしきい値を保持する。しきい値管理テーブル１１０４は、しきい値として警告しきい値と絶対しきい値の２種類のしきい値を保持する。絶対しきい値は、ＳＬＡ（Ｓｅｒｖｉｃｅ  Ｌｅｖｅｌ  Ａｇｒｅｅｍｅｎｔ）を守るために、維持する必要のあるしきい値である。警告しきい値は、特定のリソースの特定の性能メトリックが絶対しきい値に近づかないようにするためのしきい値であり、絶対しきい値よりも程度の低い値が設定される。性能メトリックは、リソースの負荷を示す値であり、計算機システムにより記録される。【００７２】
具体的にはしきい値管理テーブル１１０４は、リソース毎のエントリに以下の値を有する。リソースＩＤ１１０４０は、計算機システムを構成する構成要素であるリソースを識別するＩＤである。計算機システムは、構成要素として、サーバ２００や、ストレージ装置３００や、ネットワークスイッチなど計算機システムを構成する物理構成要素の内部物理構成要素、例えばストレージ装置３００内部のＲＡＩＤグループなどを含んでもよい。また、計算機システムは、ＶＭ７００など、性能メトリックを有する論理的な構成要素を含んでもよい。リソース種別１１０４１は、当該リソースの種別を示す。例えば、ストレージ装置３００の内部のプールであれば“Ｓｔｏｒａｇｅ．Ｐｏｏｌ”の値が格納される。性能メトリック種別１１０４２は、しきい値が設定される性能メトリックの種別を表す。例えば、単位時間当たりに利用されている時間の割合を示す“稼働率”や、単位時間当たりのＩ／Ｏ回数を表す“ＩＯＰＳ”の値が格納される。警告しきい値１１０４３は、警告しきい値の値が格納される。警告しきい値１１０４３には、絶対しきい値１１０４４以下の値が格納される。絶対しきい値１１０４４は、ＳＬＡやＳＬＯ（Ｓｅｒｖｉｃｅ  Ｌｅｖｅｌ  Ｏｂｊｅｃｔｉｖｅ）から算出されたしきい値が格納される。警告しきい値超過許容時間１１０４５は、警告しきい値１１０４３を超過することが許容される時間が格納される。【００７３】
図９は、性能管理テーブル１１０５を示す。【００７４】
性能管理テーブル１１０５は、計算機システムから取得される、各リソースの性能メトリックの時系列データである性能データを保持する。ここでの性能管理テーブル１１０５の例は、ストレージ装置３００内部のプールに関する性能データを保持する。なお、管理計算機１００は、リソース種別毎に、同様の構造の性能管理テーブルを格納していてもよい。この図は、それらの一例として記載するものである。性能管理テーブル１１０５によって、過去の特定時刻における各リソースの性能データが分かる。管理計算機１００は、定期的に監視プログラム１１２１を実行し、取得した性能データを性能管理テーブル１１０５に保存する。【００７５】
具体的には性能管理テーブル１１０５は、リソース毎、時刻毎のエントリに、以下の情報を有する。リソースＩＤ１１０５０は、当該リソースを識別するためのＩＤである。時刻１１０５１は、当該リソースの性能データ内の一つの値を取得した時刻である。稼働率１１０５２は、当該時刻における当該リソース（図９においてはプール）の稼働率である。ＩＯＰＳ１１０５３は、当該時刻における当該リソース（図９においてはプール）のＩＯＰＳである。稼働率１１０５２とＩＯＰＳ１１０５３は、性能メトリックの一例である。これらの値は、リソース種別によって、取得することができる性能メトリックに代えられていてもよいし、性能管理テーブル１１０５に含まれる性能メトリックの種類は２個に限らない。【００７６】
図１０は、対策手段管理テーブル１１０６を示す。【００７７】
対策手段管理テーブル１１０６は、ボトルネックリソースの種別と、しきい値を違反している性能メトリックの種別毎に性能メトリックを改善することができる対策手段を保持する。対策手段管理テーブル１１０６によって、性能低下発生時に有効な対策手段を判別することができ、さらに対策手段のパラメータとなるリソースであるパラメータリソースの種別と、組み合わせることができる対策手段を判別することができる。【００７８】
具体的には対策手段管理テーブル１１０６は、対策手段毎のエントリに、以下の情報を有する。ボトルネックリソース種別１１０６０は、当該対策手段の対象のボトルネックリソースの種別である。しきい値管理テーブル１１０４のリソース種別１１０４１と同様の値を格納することができる。ボトルネック性能メトリック種別１１０６１は、しきい値を違反している性能メトリックの種別である。しきい値管理テーブル１１０４の性能メトリック種別１１０４２と同様の値を格納することができる。対策手段１１０６２は、ボトルネックリソース種別１１０６０に関して、ボトルネック性能メトリック種別１１０６１の性能データを改善することができる当該対策手段である。例えば、“ＶＭストレージマイグレーション”や“Ｉ／Ｏ量上限制御”など、対策手段を特定することができる値が格納される。パラメータリソース種別１１０６３は、当該対策手段がパラメータとするリソースの種別である。例えば、値が“ＶＭ”であればＶＭを対象とした対策手段であることを示し、値が“Ｓｔｏｒａｇｅ．Ｖｏｌｕｍｅ”であればストレージ装置３００内部のボリューム３７０を対象とした対策手段であることを示す。組み合わせ可能対策手段１１０６４は、当該対策手段と同時に実施することができる別の対策手段を示す。【００７９】
図１１は、メトリック管理テーブル１１０７を示す。【００８０】
メトリック管理テーブル１１０７は、ボトルネックリソースの性能メトリックに関連して値が変化する、別のリソースの性能メトリック種別が格納される。【００８１】
具体的にはメトリック管理テーブル１１０７は、性能メトリックの組み合わせ毎のエントリに、以下の情報を有する。ボトルネックリソース種別１１０７０は、性能低下の原因であるボトルネックリソースの種別を示す。ボトルネック性能メトリック種別１１０７１は、しきい値を違反しているボトルネックリソースの性能メトリックの種別を示す。パラメータリソース種別１１０７２は、ボトルネックリソース種別１１０７０のボトルネック性能メトリック種別１１０７１に関連するリソースの種別である。パラメータ性能メトリック種別１１０７３は、ボトルネック性能メトリック種別１１０７１に関連している性能メトリックの種別である。【００８２】
この図に示す一例は、ＶＭ７００やボリューム３７０のＩＯＰＳが増加した結果、ストレージ装置３００の内部のプールの稼働率が上昇している（悪化している）ことを示している。【００８３】
図１２は、対策手段適用管理テーブル１１０８を示す。【００８４】
対策手段適用管理テーブル１１０８によって、ボトルネックリソースや関連リソースの負荷傾向に基づき対策手段が有効か、無効かを判断することができる。【００８５】
具体的には対策手段適用管理テーブル１１０８は、対策手段毎のエントリに以下の情報を有する。ボトルネックリソース種別１１０８０は、性能低下の原因であるボトルネックリソースの種別を示す。性能メトリック種別１１０８１は、しきい値を違反しているボトルネックリソースの性能メトリックの種別を示す。対策手段１１０８２は、ＶＭストレージマイグレーションなどの対策手段を表す値が格納される。【００８６】
対策方針１１０８３は、ボトルネックリソースの性能低下を解消するための当該対策手段のパラメータ決定の方針を示す。例えば、指定期間内の各時点の性能データの値を平均的に低下させる方針（この図中には“平均下げ”と記載）や、指定期間内においてピーク値となる時点の性能データの値を優先的に低下させる方針（この図中には“ピーク下げ”と記載）などが格納される。なお、上記２つの方針以外の方針が記載されてもよい。【００８７】
関連リソース傾向１１０８４は、ボトルネックリソースに関連する関連リソースについて、指定期間における負荷傾向を示す。負荷傾向は、複数のパタンの一つで表される。例えば、指定期間において複数の時点間の性能データの変動幅が小さい（この図中には“安定”と記載）や、特定の時点の性能データの値のみが大きい（この図中には“不安定”と記載）などのパタンを示す値が格納される。なお。上記２つのパタン以外の傾向を表す値が格納されてもよい。【００８８】
適用可否１１０８５は、ボトルネックリソース種別１１０８０のリソース種別に対し、関連リソースの負荷傾向が関連リソース傾向１１０８４のパタンである場合において、対策手段１１０８２を対策方針１１０８３で適用することが概して有効か、無効かを示す。有効である場合には“Ｙｅｓ”が格納され、無効の場合には“Ｎｏ”が格納される。適用可否１１０８５が“Ｎｏ”の場合には、ボトルネックリソースと関連リソースの負荷傾向を鑑みると当該対策手段を実施したとしても、性能改善の効果が得られる可能性が低いことを示している。【００８９】
優先度１１０８６は、ボトルネックリソース種別１１０８０のリソース種別に対し、関連リソースの負荷傾向が関連リソース傾向１１０８４のパタンである場合において、各対策手段を用いる対策案の優先順位を示す。例えば優先度が１である対策案は、優先度が２である対策案に比べ、優先的に実施すべきであることを示す。優先度１１０８６は、例えば各リソースの性能に対する影響の度合いや、信頼性への影響の度合いなどによって決定されてよい。【００９０】
スクリプトＩＤ１１０８７は、対策手段１１０８２のパラメータを計算する方法を記載したスクリプトを識別するＩＤである。スクリプトの具体的な例は後述する。【００９１】
図１３は、選択手段保持テーブル１１０９を示す。【００９２】
選択手段保持テーブル１１０９は、対策手段選択プログラム１１２４によって決定された対策手段と、対策手段のパラメータ候補となるリソースであるパラメータ候補リソースとを保持する。パラメータ候補リソースは、ボトルネックリソースに対する関連リソースの少なくとも一部である。【００９３】
具体的には選択手段保持テーブル１１０９は、プラン毎のエントリに、以下の情報を有する。プランは、対策手段とパラメータ候補リソースの組を示す。プランＩＤ１１０９０は、指定期間、ボトルネックリソース、性能メトリックに対するプランを識別するＩＤである。指定期間、ボトルネックリソース、性能メトリックに対して複数の対策手段が取り得る場合、１つのプランに対して、各々の対策手段のパラメータ候補リソースと、対策手段を組み合わせる場合の各対策手段の適用優先度が格納される。【００９４】
ボトルネックリソース種別１１０９１は、性能低下の原因であるボトルネックリソースの種別を示す。ボトルネックリソースＩＤ１１０９２は、性能低下の原因であるボトルネックリソースの識別ＩＤである。性能メトリック種別１１０９３は、しきい値を違反しているボトルネックリソースの性能メトリックの種別を示す。指定期間１１０９４は、対策案の生成を指定された指定期間である。対策方針１１０９５は、ボトルネックリソースの性能低下を解消するための対策手段のパラメータ決定の方針を示す。対策方針１１０９５には、対策方針１１０８３と同様の値が格納される。関連リソース傾向１１０９６は、ボトルネックリソースに関連するリソースの負荷傾向のパタンを示す。関連リソース傾向１１０９６には、関連リソース傾向１１０８４と同様の値が格納される。対策手段１１０９７は、ＶＭストレージマイグレーションなど、対策手段を表す値が格納される。対策手段１１０９７には、対策手段１１０８２と同様の値が格納される。同一のプランＩＤ１１０９０に対応する複数の対策手段１１０９７を組み合わせて対策案を生成する場合に、優先度１１０９８は、各対策手段の適用順序を示す。パラメータ候補リソース１１０９９は、対策手段１１０９７のパラメータ候補リソースを識別するＩＤが格納される。“Ａｌｌ”の場合は、対策手段１１０９７のパラメータとしてとり得るすべてのリソースが候補であることを意味する。【００９５】
（１−５）各装置の動作の詳細【００９６】
次に、管理計算機１００の性能監視処理について説明する。性能監視処理は、管理計算機１００に記憶されている監視プログラム１１２１を、プロセッサ１２０で実行する事によって実施される処理である。【００９７】
図１４は、性能監視処理のフローチャートである。【００９８】
性能監視処理は定期的に実行されても良いし、ユーザからの指示によって実行されてもよい。本実施例の性能監視処理は、予め設定された監視間隔で定期的に実行される。性能監視処理は、計算機システムを構成する各種構成要素から性能データを取得し、しきい値管理テーブル１１０４に登録されたしきい値情報に照らして性能対策の実施が必要か否かを判断する。もしも、性能対策が必要な場合、性能監視処理は、対策案生成プログラム１１２２を実行する。【００９９】
本実施例において、性能対策が必要と判断するケースとしては、警告しきい値を超過してから一定時間が経過した場合と、次回の性能監視処理実行後に対策案を生成すると絶対しきい値を超過する可能性が高い場合との２ケースについて説明する。【０１００】
まず、監視プログラム１１２１は、ＶＭ管理テーブル１１０１や、ホスト管理テーブル１１０２や、ストレージボリューム管理テーブル１１０３など、計算機システムを構成するリソースの構成情報を管理するテーブルを参照し、管理下にあるリソース毎に現在時刻の性能データを取得して、性能管理テーブル１１０５に格納する（Ｓ１０００、Ｓ１０１０）。監視プログラム１１２１は、各リソースに対してＳ１０００〜Ｓ１１１０の処理を行う。【０１０１】
次に、監視プログラム１１２１は、しきい値管理テーブル１１０４を参照し、リソースの種別とリソースＩＤを元に、性能メトリック種別１１４２毎の警告しきい値１１０４３と、絶対しきい値１１０４４と、警告しきい値超過許容時間１１０４５とを取得する（Ｓ１０２０）。もしも、警告しきい値１１０４３が設定されていない場合、監視プログラム１１２１は、以降の性能違反チェックのための処理を行う必要が無いため、Ｓ１０００に戻り、次のリソースについて処理を実施する（Ｓ１０３０）。【０１０２】
もしも、警告しきい値１１０４３が設定されていれば、監視プログラム１１２１は、Ｓ１０１０で取得した現在時刻の性能データと警告しきい値１１０４３を比較し、警告しきい値１１０４３を違反していなければ、Ｓ１０００に戻り次のリソースについて処理を実施する（Ｓ１０４０）。【０１０３】
Ｓ１０４０の比較の結果、警告しきい値１１０４３を違反している場合、監視プログラム１１２１は、次回に性能監視処理を実行するまで警告しきい値１１０４３を超過していたとしても、許容されるか否かを判断する。そのために、監視プログラム１１２１は、まずしきい値管理テーブル１１０４より、警告しきい値超過許容時間１１０４５を取得する（Ｓ１０５０）。次に、監視プログラム１１２１は、対策案の生成予想時間を見積もる（Ｓ１０６０）。その方法としては、例えば当該リソースに対し、同種類で同数の関連リソースに基づいて生成された対策案について、過去の対策案生成時間を記憶し、それを対策案生成予想時間として用いるなどの方法がある。【０１０４】
次に、監視プログラム１１２１は、Ｓ１０６０で見積もった対策案生成予想時間と監視プログラム１１２１の実行間隔を足した値よりも、警告しきい値超過許容時間１１０４５の方が大きいか、小さいかを計算する（Ｓ１０７０）。警告しきい値超過時間１１０４５の方が小さい場合（Ｓ１０７０の結果がＹｅｓの場合）、監視プログラム１１２１は、仮に次回監視プログラム１１２１実行時まで常に警告しきい値を超過していると警告しきい値超過許容時間１１０４５を超過してしまうことを意味している。そのため、監視プログラム１１２１は、当該リソースの当該性能メトリックにおいて、性能異常が発生していると判断する（Ｓ１０８０）。【０１０５】
Ｓ１０７０の結果がＮｏの場合、次に監視プログラム１１２１は、当該リソースに絶対しきい値１１０４４が設定されているか、否かを判断する（Ｓ１０９０）。絶対しきい値が設定されている場合（Ｙｅｓ）、監視プログラム１１２１は、当該リソースの過去の負荷傾向を基に将来の性能変化を見積もり、絶対しきい値に到達する予想時間を計算する（Ｓ１１００）。将来の性能変化を予想する方法としては、例えば過去の一定期間の性能データに関して最小二乗法を用いて性能変化の近似式を計算し、将来も過去のトレンドが持続すると仮定して近似式より絶対しきい値１１０４４に到達する時刻を計算する方法などを用いてよい。【０１０６】
次に、監視プログラム１１２１は、Ｓ１０６０で見積もった対策案生成予想時間と監視プログラム１１２１の実行間隔を足した値よりも、Ｓ１１００で見積もった絶対しきい値到達予想時間の方が大きいか、小さいかを計算する（Ｓ１１００）。絶対しきい値到達予想時間の方が小さい場合（Ｓ１１１０の結果がＮｏの場合）、監視プログラム１１２１は、次回監視プログラム１１２１実行時までに絶対しきい値１１０４４を超過してしまう可能性が高いことを意味している。そのため、監視プログラム１１２１は、当該リソースの当該性能メトリックにおいて、性能異常が発生していると判断する（Ｓ１０８０）。【０１０７】
Ｓ１０９０の判断の結果がＮｏの場合と、Ｓ１１１０の判断の結果がＹｅｓの場合、本実施例において監視プログラム１１２１は、性能異常が発生していないと判断する。なお、本実施例では警告しきい値を超過してから一定時間が経過した場合と、次回の性能監視処理実行後に対策案を生成した場合とでは、絶対しきい値を超過する可能性が高い場合の２ケースに該当する場合に性能異常が発生していると判断した。しかしながら、監視プログラム１１２１は、それ以外のケース、例えば過去一定回数以上しきい値違反を発生しているケースに該当する場合に性能異常が発生していると判断してもよい。本実施例で挙げた２ケース以外のケースを考慮する場合、監視プログラム１１２１は、Ｓ１０９０の判断の結果がＮｏの場合と、Ｓ１１１０の判断の結果がＹｅｓの場合とに、さらに性能異常を判断する処理を追加して実行していてもよい。【０１０８】
Ｓ１０００からＳ１１１０までの処理を全てのリソースに関して行った結果、性能異常が発生していない場合には対策案を生成する必要が無いため、監視プログラム１１２１は終了する（Ｓ１１２０）。【０１０９】
１以上のリソースについて性能異常が発生していた場合（Ｓ１１２０の結果がＹｅｓの場合）は、監視プログラム１１２１は、以降の処理を行い、対策案生成プログラム１１２２を実行する。【０１１０】
計算機システムを構成する各リソースは互いに関連しているため、特定のリソースの性能低下が原因となって、二次的に性能が低下しているリソースが存在している可能性がある。そのため、監視プログラム１１２１は、Ｓ１１３０にて各リソースの性能低下が、別のリソースの性能変化に起因するかを判断し、最終的な原因であるボトルネックリソースと性能メトリックを抽出する。この原因分析の方法としては、例えばＲＣＡ（Ｒｏｏｔ  Ｃａｕｓｅ  Ａｎａｌｙｓｉｓ）の公開技術を用いてよい。【０１１１】
次に監視プログラム１１２１は、Ｓ１１３０で抽出したボトルネックリソースの性能メトリックについて、性能異常と判定されたリソースのうち警告しきい値を超過した最も早い時刻を開始時刻とし、現在時刻を終了時刻とし、開始時刻から終了時刻までを指定期間として指定して対策案生成プログラム１１２２を実行し、指定期間に対する対策案を生成する。そして、生成した対策案とともにアラートを表示装置４００に表示する。【０１１２】
監視間隔および指定期間が長いほど、対策案の精度が向上するが、しきい値を超過する可能性が高くなる。この性能監視処理によれば、ボトルネックリソースの性能メトリックがしきい値を超過することを防ぐと共に、対策案の精度を向上させることができる。【０１１３】
この性能監視処理によれば、管理計算機１００は、定期的にリソースの負荷を監視し、負荷が警告しきい値を超過する時間が警告しきい値超過許容時間を超えないように、且つ負荷が絶対しきい値を超えないように、指定期間を設定し、指定期間に対する対策案を生成することができる。【０１１４】
次に、管理計算機１００の対策案生成処理について説明する。対策案生成処理は、管理計算機１００に記憶されている対策案生成プログラム１１２２を、プロセッサ１２０で実行する事によって実施される処理である。【０１１５】
図１５は、対策案生成処理のフローチャートである。【０１１６】
対策案生成処理はユーザからの指示によって実行されてもよいし、性能異常を検知した場合に対策案生成プログラム１１２２によって実行されてもよい。【０１１７】
対策案生成プログラム１１２２は、まずボトルネックリソースの種別、ボトルネックリソースの識別ＩＤ、対策案を生成する指定期間、警告しきい値１１０４３を違反している性能メトリックの種別を受信する（Ｓ２０００）。上記の情報は、表示装置４００よりユーザから指定されていてもよいし、監視プログラム１１２１から指定されていてもよい。なお、これらは本実施例における一例であって、他のプログラムによって対策案生成プログラム１１２２が呼び出されることを制限するものではない。【０１１８】
次に、対策案生成プログラム１１２２は、対策方針判断処理を実施する（Ｓ２０２０）。対策方針判断処理は、指定期間におけるボトルネックリソースの負荷傾向を分析し、性能低下の問題に関して効率的に、精度のよい対策案を生成するための対策方針を求める処理である。具体的なフローチャートについては後述する。【０１１９】
次に、対策案生成プログラム１１２２は、対策手段選択処理を実施する（Ｓ２０３０）。対策手段選択処理は、ボトルネックリソースに関連する関連リソース群について、指定期間における負荷傾向を分析し、対応方針に対して適切な対策手段を選択する処理である。具体的なフローチャートについては後述する。【０１２０】
対策案生成プログラム１１２２は、対策手段選択処理の結果を選択手段保持テーブル１１０９より取得する（Ｓ２０４０）。このとき、ボトルネックリソースの性能低下を解消する対策手段は複数存在する可能性があるため、選択手段保持テーブル１１０９には複数の対策案（プラン）が指定されたボトルネックリソース、性能メトリック、指定期間に対応するプランが複数個保持されている可能性がある。そのため、対策案生成プログラム１１２２は、以降の処理（Ｓ２０７０からＳ２１１０）を各プランについて実施する。【０１２１】
なお、プラン１１０９０は、複数の対策手段の組み合わせである可能性がある。その場合では対策案生成プログラム１１２２は、プラン１１０９０を構成する各対策手段１１０９７について優先度１１０９８を参照し、優先度が高い対策手段１１０９７の順番に以降の処理（Ｓ２０７０からＳ２１１０）を実施する。【０１２２】
まず、対策案生成プログラム１１２２は、Ｓ２０７０において選択手段保持テーブル１１０９から対策手段１１０９７を選択し、対応する対策方針１１０９５と、関連リソース傾向１１０９６と、パラメータ候補リソース１１０９９とを取得する。【０１２３】
次にＳ２０８０において、対策案生成プログラム１１２２は、Ｓ２０７０で取得した情報を基に対策手段適用管理テーブル１１０８を参照し、対策手段のパラメータを計算する方法を記載したスクリプトＩＤ１１０８７を取得する。【０１２４】
対策案生成プログラム１１２２は、Ｓ２０９０において、Ｓ２０８０で取得したスクリプトＩＤ１０８７に対応するスクリプトを、記憶資源１１０に記憶されたパラメータ計算スクリプト群１１３の中から特定する。そして、対策案生成プログラム１１２２は、Ｓ２０７０で取得したパラメータ候補リソースと、特定されたスクリプトとを用いて、パラメータを計算する。【０１２５】
対策案生成プログラム１１２２は、スクリプトで計算した対策案を実施した場合について、ボトルネックリソースのしきい値違反を起こした性能メトリックの値の変化を見積もる（Ｓ２１００）。この見積もり方法は、Ｓ１１００の見積もり方法と同様であってもよいし、Ｓ１１００によって見積もられた結果に対策案を適用することで見積もってもよい。もしも、見積もりの結果、指定期間内の全時点について警告しきい値１１０４３を違反しない状態となるならば（Ｓ２１１０の結果がＹｅｓ）、より優先度１１０９８の低い対策手段を実施する必要は無いため、対策案生成プログラム１１２２は、次のプラン１１０９０について対策案生成の処理（Ｓ２０７０からＳ２１１０）を開始する。もしも、Ｓ２１１０の結果がＮｏならば、対策案生成プログラム１１２２は、より優先度１１０９８の低い対策手段について対策案生成の処理（Ｓ２０７０からＳ２１１０）を実施する。【０１２６】
その後、対策案生成プログラム１１２２は、生成した対策手段をプラン毎に表示装置４００に表示する（Ｓ２１２０）。表示の方法としては、例えばＸＭＬなど定型的な形式で表現されてもよい。例えば、その場合には表示装置４００に表示するのみならず、ファイルなどの形式で電子的に保存されてもよい。【０１２７】
また、管理計算機１００は、生成した対策案を実施した場合の見積もりをグラフとして表現し、対策案とともに表示装置４００に提示させてもよい。これにより、対策案実行による変化を直感的に把握することが可能となる。【０１２８】
また、生成された対策案は、対策手段に対応するＣＬＩの形式で表現されていてもよい。なお、それに伴い本実施例においては対策手段およびパラメータ以外の内容を表示することを限定するものではない。例えば、対策案は、対策案の内容が含まれているならばプログラムの形式で表現されていてもよい。【０１２９】
この対策案生成処理によれば、管理計算機１００は、適切なスクリプトを用いてパラメータを決定することができ、指定期間に対する対策案を生成することができる。【０１３０】
本実施例におけるスクリプトは、Ｓｃｒｉｐｔ１からＳｃｒｉｐｔ４である。Ｓｃｒｉｐｔ１からＳｃｒｉｐｔ４は、ストレージ装置３００内のプールの稼働率が上昇したことが性能問題の原因である場合に、プールの稼働率を警告しきい値１１０４３まで低下させる対策案を生成するためのスクリプトである。ここでのパラメータ候補リソースは、ＶＭである。特にＳｃｒｉｐｔ１とＳｃｒｉｐｔ２は、ＶＭストレージマイグレーションのパラメータを計算するための計算方法を記載したスクリプトである。Ｓｃｒｉｐｔ３とＳｃｒｉｐｔ４は、ボリュームのＩ／Ｏ量上限を制限するストレージ設定変更について、パラメータを計算するための計算方法を記載したスクリプトである。【０１３１】
図１６は、Ｓｃｒｉｐｔ１のフローチャートである。【０１３２】
Ｓｃｒｉｐｔ１は、ＶＭストレージマイグレーションを行うＶＭ７００と、移動先のデータストアとを決定する。具体的には、Ｓｃｒｉｐｔ１は、指定期間におけるボトルネックリソースの平均稼働率を警告しきい値１１０４３よりも小さい値に低下させることができるＶＭ７００の組み合わせのうち、ＶＭ７００のデータを移動させた場合の、各プールまたはＲＡＩＤグループの、指定期間における平均稼働率が最小となる組み合わせを求める。これは、例えば整数計画問題としてモデル化し、公知の整数計画問題ソルバなどを用いて計算してもよい。これが可能な理由は、対策方針判断処理によって、性能低下解消の効果を維持しつつ、最適化問題をより簡単な問題に変換できているためである。また、それでもリソース数が大きく、最適解が現実的な時間で生成できない場合には、例えば前掲の整数計画問題を線形緩和し、公知のアルゴリズムを用いて近似解を求めてもよい。【０１３３】
複数のＶＭの負荷の合計により、プールの稼働率が指定期間に亘ってしきい値を超える場合、Ｓｃｒｉｐｔ１を用いることにより、特定のリソースに負荷が集中しないようにＶＭを移動させることができる。【０１３４】
図１７は、Ｓｃｒｉｐｔ２のフローチャートである。【０１３５】
Ｓｃｒｉｐｔ２は、ＶＭストレージマイグレーションを行うＶＭ７００と、移動先のデータストアとを決定する。具体的には、Ｓｃｒｉｐｔ２は、指定期間におけるボトルネックリソースの最大稼働率を警告しきい値１１０４３よりも小さい値に低下させることができるＶＭ７００の組み合わせのうち、ＶＭ７００のデータを移動させた後の各プールまたはＲＡＩＤグループの、指定期間における最大稼働率が最小となる組み合わせを求める。これは、例えば整数計画問題としてモデル化し、公知の整数計画問題ソルバなどを用いて計算してもよい。これが可能な理由は、対策方針判断処理によって、性能低下解消の効果を維持しつつ、最適化問題をより簡単な問題に変換できているためである。また、それでもリソース数が大きく、最適解が現実的な時間で生成できない場合には、例えば前掲の整数計画問題を線形緩和し、公知のアルゴリズムを用いて近似解を求めてもよい。【０１３６】
指定期間のうち、特定の時点でプールの稼働率がしきい値を超える場合、Ｓｃｒｉｐｔ２によれば、移動先リソースのピーク値を最小にするようにＶＭを移動させることができる。【０１３７】
図１８は、Ｓｃｒｉｐｔ３のフローチャートである。【０１３８】
Ｓｃｒｉｐｔ３は、ボトルネックリソースに負荷をかけているボリューム３７０に対するＩ／Ｏの上限値を決定する。Ｓｃｒｉｐｔ３は、まずボトルネックリソース（ストレージ装置３００内のプール）について、その稼働率が警告しきい値１１０４３以下となるための、プールのＩＯＰＳ値上限を計算する（Ｓ１１３３０）。【０１３９】
実際にはサーバ２００やＶＭ７００がＩ／Ｏを発行する対象は、ボリューム３７０であり、プールに対して発行されるＩ／Ｏ量は、当該プールから生成されたボリューム３７０に対して発行されるＩ／Ｏ量の合計である。そのため、Ｓｃｒｉｐｔ３は、各ボリューム３７０のＩＯＰＳ合計が、Ｓ１１３３０で計算したプールのＩＯＰＳ上限と等しくなるように各ボリューム３７０のＩＯＰＳ上限値を決定する。その際、例えば指定期間における各ボリューム３７０の平均ＩＯＰＳを計算し、その比率に従ってプールのＩＯＰＳ上限を分配することで、各ボリューム３７０のＩＯＰＳ上限値を計算する。【０１４０】
ボリュームの負荷が指定期間に亘って安定しており、プールの稼働率が指定期間に亘ってしきい値を超える場合、Ｓｃｒｉｐｔ３によれば、指定期間に亘ってボリュームの負荷を抑えるように、各ボリューム３７０のＩＯＰＳ上限値を決定することができる。【０１４１】
図１９は、Ｓｃｒｉｐｔ４のフローチャートである。【０１４２】
Ｓｃｒｉｐｔ４は、ボトルネックリソースに負荷をかけているボリューム３７０に対するＩ／Ｏの上限値を決定する。Ｓｃｒｉｐｔ４では、Ｓ１１３３０と同処理でボトルネックリソースであるプールのＩＯＰＳ値上限を計算する（Ｓ１１３４０）。【０１４３】
次に、対策案生成プログラム１１２２は、ボトルネックリソースであるプールに関連するボリューム３７０に対し、Ｓ１１３４０で計算したＩＯＰＳ値を上限値として設定する（Ｓ１１３４１）。【０１４４】
指定期間のうち特定の時点でボリュームの負荷が高くなることで、プールの稼働率がしきい値を超える場合、Ｓｃｒｉｐｔ４によれば、特定のボリュームの負荷を抑えるように、ＩＯＰＳ上限値を決定することができる。【０１４５】
なお、上記のスクリプトは一例であって、ボトルネックリソースや、性能メトリックや、対策手段や、対策方針によって上記以外のスクリプトが含まれていてもよい。また、本実施例においてはフローチャートの形式で表現したが、処理内容や処理順序が表現できる他の形式、例えばＸＭＬ（Ｅｘｔｅｎｓｉｂｌｅ  Ｍａｒｋｕｐ  Ｌａｎｇｕａｇｅ）の形式で表現されていてもよい。また、管理計算機１００は、ファイルなどの電子媒体に含まれるＸＭＬデータを動的に記憶資源に読み込む機能を有していてもよい。【０１４６】
図２０は、対策方針判断処理（Ｓ２０２０）を示すフローチャートである。【０１４７】
対策方針判断処理は、対策方針判断プログラム１１２３をプロセッサ１２０で実行することで、実行される。【０１４８】
まず、対策方針判断プログラム１１２３は、ボトルネックリソースの種別と、ボトルネックリソースのＩＤと、指定期間と、警告しきい値１１０４３を違反している性能メトリックの種別とを、受信する（Ｓ３０００）。【０１４９】
次に、対策方針判断プログラム１１２３は、ボトルネックリソースに対応する性能管理テーブル１１０５を参照し、指定されたボトルネックリソースＩＤと、性能メトリック種別と、指定期間に含まれる各時点の性能データとを取得する（Ｓ３０１０）。【０１５０】
次に、対策方針判断プログラム１１２３は、Ｓ３０１０で取得した、ボトルネックリソースの性能データの傾向を、複数のパタンに分類する。本実施例においては、分類の一例として、各時点における性能データの値にばらつきが少ない場合を“安定的”パタンとし、逆に特定の時点における性能データの値が他の時点の性能データの値と比較して大きく外れている場合を“不安定的”パタンとする、２パタンに分類する場合を説明する。【０１５１】
対策方針判断プログラム１１２３は、Ｓ３０１０で取得した性能データが安定的パタンか不安定的パタンかを判別するために、指定期間に亘る性能データの平均値とボトルネック負荷偏差しきい値を計算する。例えば、対策方針判断プログラム１１２３は、指定期間に亘る性能データの標準偏差を算出し、標準偏差に、予め設定された係数を乗ずることで、ボトルネック負荷偏差しきい値を算出する。そして、対策方針判断プログラム１１２３は、各時点の性能データの値に関して、平均値に対する性能データの値の偏差がボトルネック負荷偏差しきい値以上となる時点があるか否かを判断する（Ｓ３０２０、Ｓ３０３０）。対策方針判断プログラム１１２３は、Ｓ３０３０の結果が、Ｙｅｓの場合、不安定的パタンであると判断し、Ｎｏの場合、安定的パタンであると判断する。なお、Ｓ３０３０で用いた標準偏差を用いる計算方法は外れ値を求める方法の一例であり、他の外れ値検出方法を用いてもよい。【０１５２】
そして、Ｓ３０３０の結果、不安定的パタンに分類された場合には、指定期間において特定の時点において大きくしきい値違反を起こしていることで性能異常が発生している可能性が高いと考えられるため、対策方針判断プログラム１１２３は、指定期間においてピーク値を取る時点の性能データの値を優先的に改善する対策方針を採ると決定する（Ｓ３０４０）。以降の説明においては本方針を“ピーク下げ”と記載する。【０１５３】
一方で、Ｓ３０４０の結果、安定的パタンに分類された場合には、指定期間において定常的にしきい値違反を起こしている可能性が高いと考えられるため、対策方針判断プログラム１１２３は、指定期間において各時点の性能データの値を均一に改善する対策方針を採ると決定する（Ｓ３０５０）。以降の説明においては本方針を“平均下げ”と記載する。【０１５４】
この対策方針判断処理によれば、ボトルネックリソースの負荷の傾向が安定的であるか不安定的であるかを判定し、その判定結果に基づいて適切な対策方針を決定することができる。【０１５５】
図２１は、対策手段選択処理（Ｓ２０３０）を示すフローチャートである。【０１５６】
対策手段選択処理は、対策手段選択プログラム１１２４をプロセッサ１２０で実行することで、実行される。【０１５７】
まず、対策手段選択プログラム１１２４は、ボトルネックリソースの種別と、ボトルネックリソースのＩＤと、指定期間と、警告しきい値１１０４３を違反している性能メトリック種別と、対策方針とを、受信する（Ｓ４０００）。【０１５８】
次に対策手段選択プログラム１１２４は、指定されたボトルネックリソース種別の性能メトリックについて、性能データを改善する効果のある対策手段を抽出する（Ｓ４０１０）。具体的には、対策手段選択プログラム１１２４は、対策手段管理テーブル１１０６を参照し、Ｓ４０００で受信したボトルネックリソース種別１１０６０と、警告しきい値違反を起こしているボトルネック性能メトリック種別１１０６１に対応する対策手段１１０６２と、パラメータリソース種別１１０６３と、組み合わせ可能対策手段１１０６４とを、抽出する。【０１５９】
ここでボトルネックリソースに対して複数の対策手段１１０６２が適用できる可能性がある。また、各対策手段によってパラメータリソース種別が異なることから、対策手段選択プログラム１１２４は、以降の処理（Ｓ４０３０からＳ４１２０）を対策手段毎に実行する。【０１６０】
対策手段選択プログラム１１２４は、Ｓ４０３０において、Ｓ４０１０で取得した対策手段のパラメータリソース種別について、ＶＭ管理テーブル１１０１、ホスト管理テーブル１１０２、ストレージボリューム管理テーブル１１０３などの構成情報を管理する各種テーブルから、該当するリソースの情報を抽出する（Ｓ４０３０）。例えば、ボトルネックリソースがストレージ装置３００内部のプールであった場合、対策手段としてＶＭストレージマイグレーションとＩ／Ｏ量上限制御の２つの対策手段１１０６２がとり得ることを示している。そして、ＶＭストレージマイグレーションを実行するためにはパラメータとしてＶＭ７００を設定する必要があり、Ｉ／Ｏ量上限制御を実行するためにはパラメータとしてボリューム３７０を設定する必要があることを示している。【０１６１】
ここで、該当するパラメータリソース種別の関連リソースの情報が、各種構成情報を管理するテーブルに存在しない場合（Ｓ４０４０の結果がＮｏの場合）、対策手段選択プログラム１１２４は、対策案を生成することができないため、Ｓ４０２０に戻り次の対策手段について同様の処理を実施する。【０１６２】
Ｓ４０４０の結果がＹｅｓの場合、対策手段選択プログラム１１２４は、以降の処理によって各関連リソースの負荷傾向をパタンに分類する。まずは、対策手段選択プログラム１１２４は、関連リソースにおいて着目する性能メトリックを特定するために、メトリック管理テーブル１１０７を参照し、ボトルネックリソース種別１１０７０とボトルネック性能メトリック種別１１０７１とパラメータリソース種別１１０７２とに対応する、パラメータ性能メトリック種別１１０７３を抽出する（Ｓ４０５０）。例えばストレージ装置３００内のプールの性能メトリックである稼働率は、ＶＭ７００の性能メトリックであるＩＯＰＳ、または、ボリューム３７０の性能メトリックであるＩＯＰＳに関連していることを示している。【０１６３】
次に、対策手段選択プログラム１１２４は、関連リソース毎に負荷傾向を分析する。本実施例においては、対策方針判断プログラム１１２３と同様、各関連リソースを安定的パタンと不安定的パタンに分類する場合について説明する。具体的には、対策手段選択プログラム１１２４は、関連リソース毎にＳ４０７０とＳ４０８０の処理を行う。【０１６４】
対策手段選択プログラム１１２４は、Ｓ４０７０において性能管理テーブル１１０５を参照し、指定期間における関連リソースのパラメータ性能メトリック種別１１０７３の性能データを抽出する。そして、Ｓ４０８０において、Ｓ４０７０で抽出した性能データについて外れ値判定を行うことで、関連リソースが安定的パタンであるか否かを判定する。ここで実施する処理は、Ｓ３０２０と同様でもよい（Ｓ４０８０）。例えば、対策手段選択プログラム１１２４は、指定期間に亘る性能データの平均値と関連負荷偏差しきい値とを計算し、平均値に対する性能データの値の偏差が関連負荷偏差しきい値以上となる時点があるか否かを判断する。関連負荷偏差しきい値は例えば、標準偏差に、予め設定された係数を乗じた値である。【０１６５】
Ｓ４０３０で抽出したすべての関連リソースをパタンに分類した後、対策手段選択プログラム１１２４は、安定的パタンに分類された関連リソースの数が、不安定的パタンに分類された関連リソースの数より多いか否かを判断する（Ｓ４０９０）。その結果がＹｅｓの場合であれば、対策手段選択プログラム１１２４は、指定されたボトルネックリソースに対して当該対策手段のパラメータとなる関連リソース群は安定的パタンであると判断する（Ｓ４１１０）。逆にＮｏの場合であれば、対策手段選択プログラム１１２４は、関連リソース群は不安定的パタンであると判断する（Ｓ４１００）。【０１６６】
次に、対策手段選択プログラム１１２４は、Ｓ４０００で受信した対策方針と、Ｓ４１００またはＳ４１１０で判断した関連リソースのパタンとをつき合わせ、当該対策手段がボトルネックリソースの性能低下を解消する効果があるか否かを判断する。具体的には、対策手段選択プログラム１１２４は、対策手段適用管理テーブル１１０８を参照し、ボトルネックリソース種別１１０８０と、性能メトリック種別１１０８１と、対策手段１１０８２と、対策方針１１０８３と、関連リソース傾向１１０８４に合致する適用可否１１０８５の値を取得する。対策手段選択プログラム１１２４は、その結果が、Ｙｅｓであれば、当該対策手段は有効であると判断し、Ｎｏであれば当該対策手段は有効でないと判断する（Ｓ４１２０）。【０１６７】
例えば、対策方針１１０８３が平均下げかつ、関連リソース傾向１１０８４が不安定的パタンである場合では、各関連リソースが夫々異なる時点において負荷が高まっているために、各関連リソースを集合すると指定期間を通して安定した負荷傾向に見えていると考えられる。そのため、このとき対策手段１１０８２がＶＭストレージマイグレーションである場合では、特定のＶＭ７００のデータを異なるプールに移動させたとしても、ＶＭ７００の負荷が高まるタイミングで移動先のプールにおいて警告しきい値違反を起こす可能性が高い。よって、適用可否１１０８５はＮｏと判断される。【０１６８】
また、対策方針１１０８３がピーク下げかつ、関連リソース傾向１１０８４が不安定的パタンである場合、各関連リソースが同じ時点において負荷が高まっており、各関連リソースを集合すると特定の時点で大きくボトルネックリソースの負荷が高まる状態となっていると考えられる。そのため、このとき対策手段１１０８２がＩ／Ｏ量上限制御である場合、各ボリューム３７０に対して同様にＩ／Ｏ量制限をかける必要があり、ピーク時点において各ボリューム３７０を用いるアプリケーションに対して大きな影響を発生させてしまう。よって、適用可否はＮｏと判断される。【０１６９】
この対策手段選択処理によれば、関連リソースの負荷の傾向が安定的であるか不安定的であるかを判定し、その判定結果と対策方針とに基づいて適切な対策手段を決定することができる。【０１７０】
以上で説明したように、本実施例によれば、管理計算機１００は、指定期間におけるボトルネックリソースの負荷変化の傾向に対応した対策案の生成方針を決定することができる。【０１７１】
また、本実施例によれば、管理計算機１００は、関連リソース群の特徴を表現する１つの負荷傾向のパタンを判断することができる。それにより、管理計算機１００は、パラメータ計算の計算量が増大してしまう対策手段や、副作用が大きくなるためにアプリケーションに対する影響が大きくなる対策手段を除外することができる。【０１７２】
また、管理計算機１００は、ボトルネックリソースの負荷傾向から導出される対策方針に基づき、対策手段のパラメータを計算することで、性能低下を解消するために必要なだけのパラメータを最小限の計算で求めることが可能となる。
【実施例２】
【０１７３】
（２−１）本実施例の形態の概要【０１７４】
本実施例においては、ボトルネックリソースの関連リソースをパタン毎に分類し、そのパタンに適用可能な対策手段を導出することによって、複数の対策手段を組み合わせた対策案を導出可能となる。これにより、実施例２において、管理計算機１００は、複数のパタンの関連リソースが混在していた場合であっても、パラメータ計算の計算量を削減しつつ、アプリケーションや各ＶＭに対する副作用が小さい対策案を生成することが可能となる。【０１７５】
実施例２に係る計算機システムの構成や、計算機システムで管理される情報は実施例１で説明した計算機システムと同様のため、図示は省略する。また、実施例２に係る計算機システムで実行されるプログラムのうち、対策手段選択プログラム１１２４以外のプログラムの動作は、実施例１で説明したものと同様である。そのため、以下では、対策手段選択プログラム１１２４の動作のうち、実施例１で説明したものと異なる点を中心に説明する。【０１７６】
（２−２）各装置動作の詳細【０１７７】
図２２は、実施例２に係る対策手段選択処理（Ｓ２０３０）を示すフローチャートである。【０１７８】
まず、対策手段選択プログラム１１２４は、実施例１のＳ４０１０までの処理を行う。その後、対策手段選択プログラム１１２４は、対策手段毎に、実施例１のＳ４０３０からＳ４０５０までと同様の処理を行う。さらに、対策手段選択プログラム１１２４は、その後、関連リソース毎に、実施例１のＳ４０７０からＳ４０８０までと同様の処理を行う。【０１７９】
その後、本実施例において、対策手段選択プログラム１１２４は、Ｓ４０８０の外れ値判定の結果、当該関連リソースが安定的パタンであるか不安定的パタンであるかを判別する。本実施例においては、実施例１（Ｓ３０２０、Ｓ４０８０）と同様の方法で外れ値を判定すると想定する（Ｓ５０００）。Ｓ５０００の結果がＹｅｓであれば、対策手段選択プログラム１１２４は、当該関連リソースが安定的パタンであると判断し、当該関連リソースを安定的パタンの関連リソース群のひとつとして記憶資源に記憶する（Ｓ５０１０）。一方で、Ｓ５０００の結果がＮｏであれば、対策手段選択プログラム１１２４は、当該関連リソースは不安定的パタンであると判断し、対策手段選択プログラム１１２４は当該関連リソースを不安定的パタンの関連リソース群のひとつとして記憶資源に記憶する（Ｓ５０２０）。【０１８０】
対策手段選択プログラム１１２４は、Ｓ５０２０までの処理を各関連リソースに対して実施すると、次にＳ５０１０、Ｓ５０２０で分類した各パタンに対応する関連リソース群のうち、含まれる関連リソースの数が最も多いリソース群を選択する（Ｓ５０３０）。【０１８１】
そして、対策手段選択プログラム１１２４は、Ｓ５０３０で選択した関連リソース群の傾向に対して、当該対策手段がボトルネックリソースの性能低下を解消する効果があるか否かを、対策手段適用管理テーブル１１０８を参照して判断する（Ｓ５０４０）。判断の内容や、具体例はＳ４１２０と同様である。【０１８２】
Ｓ５０４０で判断した結果がＹｅｓの場合、当該対策手段はボトルネックリソースの性能低下の問題に関連するリソースのうち、最も多数の関連リソースに対して適用することができる対策手段である。そのため、対策手段を組み合わせる場合に、当該対策手段が最もボトルネックリソースの性能低下を解消する効果が大きいと考えられる。よって、対策手段選択プログラム１１２４は、当該対策手段を最も高い優先度（優先度１）の対策手段として記憶資源に記憶し、後述する対策手段組み合わせ生成処理に利用する（Ｓ５０６０）。【０１８３】
Ｓ５０５０で判断した結果がＮｏの場合、当該対策手段はボトルネックリソースの関連リソースのうち、最も多数の関連リソースに対して適用することができない対策手段である。そのため、対策手段選択プログラム１１２４は、当該対策手段を他の対策手段と組み合わせても性能低下の問題を解消することができないと判断し、当該対策手段に対する処理を終了する。【０１８４】
次に対策手段選択プログラム１１２４は、対策組み合わせ生成処理により、最多数の関連リソース群以外の関連リソース群のパタンを基に、当該対策手段と組み合わせる他の対策手段を判断する（Ｓ５０７０）。対策組み合わせ生成処理の詳細は後述する。【０１８５】
最後に、Ｓ５０６０で選択した対策手段と、Ｓ５０８０で決定した対策手段を選択手段保持テーブル１１０９に登録する。対策手段１１０９７登録時には、対応する優先度１１０９８としてＳ５０６０で選択した優先度か、対策手段組み合わせ生成処理で選択した優先度を共に設定する。また、対策手段１１０９７の登録時には、対応するパラメータ候補リソース１１０９９として対策手段に対応する関連リソース群に含まれる関連リソースを設定する。【０１８６】
図２３は、実施例２に係る対策手段組み合わせ生成処理を示すフローチャートである。【０１８７】
対策手段組み合わせ生成処理は、対策手段選択プログラム１１２４から呼び出されるサブプログラムである。【０１８８】
対策手段組み合わせ生成処理は、まずボトルネックリソースの種別およびＩＤと、警告しきい値違反を起こしている性能メトリック種別と、対策方針と、選択済みの対策手段と、Ｓ５０１０またはＳ５０２０で分類された関連リソース群とを受信する（Ｓ６０００）。【０１８９】
その後、対策手段組み合わせ生成処理は、Ｓ６０００で受信した関連リソース群のうち、リソース数最多の関連リソース群を除いた関連リソース群を、リソース数が多い順に選択し、以降の処理を行う（Ｓ６０１０）。【０１９０】
まず、対策手段組み合わせ生成処理は、対策手段管理テーブル１１０６を参照し、Ｓ６０００で受信した対策手段と、Ｓ６０４０で選択済みの対策手段のすべての対策手段とに対して、組み合わせ可能対策手段１１０６４を取得し、取得されたすべての組み合わせ可能対策手段１１０６４に共通して含まれる対策手段を抽出する（Ｓ６０２０）。【０１９１】
さらに対策手段組み合わせ生成処理は、Ｓ６０００で受信したボトルネックリソース種別１１０８０と、性能メトリック種別１１０８１と、対策方針１１０８３と、Ｓ６０１０で選択された関連リソース群の関連リソース傾向１１０８４とを用いて、Ｓ６０２０で抽出された対策手段毎に、対策手段適用管理テーブル１１０８を参照し、性能低下を解消するために効果のある対策手段を抽出する（Ｓ６０３０）。【０１９２】
次に、対策手段組み合わせ生成処理は、Ｓ６０３０で抽出した各対策手段と、以前のＳ６０４０の処理により生成された対策手段の組み合わせとを掛け合わせて、組み合わせを生成し、生成した組み合わせを新たに記憶する（Ｓ６０４０）。【０１９３】
もしも、Ｓ６０１０からＳ６０４０までの処理をすべての関連リソース群について実施したならば、対策手段組み合わせ生成処理は処理を終了し、生成した対策手段の組み合わせを処理の呼び出し元に返却する。そうでないならば、対策手段組み合わせ生成処理は、Ｓ６０１０に処理を移し、次にリソース数の多い関連リソース群についてＳ６０２０からＳ６０４０までの処理を行う。【０１９４】
もし、期間内の全ての時点で性能低下を防ぐように、大量の構成変更手段や構成変更手段のパラメータの組み合わせの中から適切な対策案を生成しようとすると、現実的な計算時間で表示することができない。以上に述べた各実施例によれば、対策手段の候補を限定し、その上で対策手段のパラメータ計算の計算量を削減することができる。これにより、過去の期間に関して、負荷が再現した場合に性能低下が再現しない対策案を効率的に生成し、表示することができる。【０１９５】
過去の期間は、指定期間等に対応する。ボトルネック負荷データは、ボトルネックリソースの性能データ等に対応する。関連負荷データは、関連リソースの性能データ等に対応する。ボトルネック負荷範囲は、ボトルネックリソースの性能データの平均値に対する偏差がボトルネック負荷偏差しきい値以下である範囲等に対応する。関連負荷範囲は、関連リソースの性能データの平均値に対する偏差が関連負荷偏差しきい値以下である範囲等に対応する。複数の対策方針候補は、対策方針１１０８３に示された値等に対応する。複数の対策手段候補は、対策手段１１０６２に示された値等に対応する。複数の判定結果は、関連リソース傾向１１０８４に示された値等に対応する。【０１９６】
以上、本発明の実施形態を説明したが、これは本発明の説明のための例示であって、本発明の範囲を上記構成に限定する趣旨ではない。本発明は、他の種々の形態でも実施する事が可能である。
【符号の説明】
【０１９７】
１０…計算機システム、  １００…管理計算機、  １１０…記憶資源、  １２０…プロセッサ、  ２００…サーバ、  ２１０…プロセッサ、  ２２０…記憶資源、  ３００…ストレージ装置、  ３１０…プロセッサ、  ３２０…メモリ、  ３６０…記憶デバイス群、  ３７０…ボリューム、  ３８０…キャッシュメモリ、  ３９０…コントローラ、  ４００…表示装置、  ５００…通信ネットワーク、  ６００…通信ネットワーク、  ７００…ＶＭ、  ８００…ハイパバイザ
【図１】
0006752889.tif 000002
【図２】
0006752889.tif 000003
【図３】
0006752889.tif 000004
【図４】
0006752889.tif 000005
【図５】
0006752889.tif 000006
【図６】
0006752889.tif 000007
【図７】
0006752889.tif 000008
【図８】
0006752889.tif 000009
【図９】
0006752889.tif 000010
【図１０】
0006752889.tif 000011
【図１１】
0006752889.tif 000012
【図１２】
0006752889.tif 000013
【図１３】
0006752889.tif 000014
【図１４】
0006752889.tif 000015
【図１５】
0006752889.tif 000016
【図１６】
0006752889.tif 000017
【図１７】
0006752889.tif 000018
【図１８】
0006752889.tif 000019
【図１９】
0006752889.tif 000020
【図２０】
0006752889.tif 000021
【図２１】
0006752889.tif 000022
【図２２】
0006752889.tif 000023
【図２３】
0006752889.tif 000024