JP6033985B2 - 性能評価方法及び情報処理装置 - Google Patents

Description

本発明は、計算機システムの性能予測技術に関する。

計算機システムの設計時、または計算機システムの構成変更を実施する時には、その設計や変更後の構成が、システム利用者より求められる性能目標を満足するか評価・検証する必要がある。例えば、特許文献１には、仮想化された計算機システムについて、仮想化技術を用いることによるオーバーヘッドを考慮した性能評価モデルを生成し、計算機システムの性能評価を行う性能評価手法が記載されている。

特開２０１２−１４６０１５号公報

特許文献１によれば、ある時点のシステム構成及びシステムへの負荷に基づいた計算機システムの性能を評価することが出来る。しかし、計算機システムが稼動している状態でシステムの構成が変更される場合は、構成変更によって縮退（稼働停止）するサーバに対して構成変更時に割り振られていた処理要求が、サーバ縮退の結果、処理されなかったため他のサーバに再度割り振り直されることにより、システムの構成要素に対する負荷が一時的に増加することが考えられる。従って、評価の精度を上げるためには、構成変更に伴うシステムへの一時的な負荷の増加がシステムの性能に与える影響も考慮する必要がある。このように、たとえば構成変更が生じた際に処理要求が再送されることを考慮していなかった点で、従来の性能評価手法には改善の余地があった。

上記課題を解決するため、本発明が提供する情報処理装置の一形態は、計算機システムに含まれるサーバが稼動停止した場合の計算機システムの性能を、稼働停止時のサーバに要求されていた処理量に基づいて推定し、推定した計算機システムの性能を出力することを特徴とする。

本発明の一つの効果としては、システムの構成変更に伴う一時的な負荷の増加を考慮することで、計算機システムの性能について評価の精度を高めることが出来る。

図１は、実施例の概要図である。 図２（Ａ）は、実施例１にかかるシステム構成図を示す。 図２（Ｂ）は、実施例１にかかるシステム構成図を示す。 図３は、実施例１にかかる管理対象システムの構成例を示す。 図４は、実施例１にかかる物理システム構成情報を示す。 図５は、実施例１にかかる仮想システム構成情報を示す。 図６は、実施例１にかかるマシンスペック情報を示す。 図７は、実施例１にかかるテナントシステムの構成例を示す。 図８は、実施例１にかかるテナント構成情報を示す。 図９は、実施例１にかかるタスクスケジュール情報を示す。 図１０は、実施例１にかかるタスク管理情報を示す。 図１１は、実施例１にかかるシステム期待性能情報を示す。 図１２は、実施例１にかかるシステム性能劣化度合い情報を示す。 図１３は、実施例１にかかる処理中負荷情報を示す。 図１４は、実施例２にかかる負荷−キュー使用量対応情報を示す。 図１５は、実施例２にかかるキュー使用量−性能対応情報を示す。 図１６は、実施例２にかかる性能−キュー消化容量対応テーブルを示す。 図１７は、実施例１にかかる負荷トレンド情報を示す。 図１８は、実施例１にかかる運用ポリシー情報を示す。 図１９（Ａ）は、実施例１にかかる出力画面の表示例を示す。 図１９（Ｂ）は、実施例１にかかる出力画面の表示例を示す。 図１９（Ｃ）は、実施例１にかかる出力画面の表示例を示す。 図２０は、実施例にかかる性能見積もり処理を示すフローチャートである。 図２１は、実施例にかかる瞬間性能見積もり処理を示すフローチャートである。 図２２は、実施例にかかる運用ポリシー判定処理の詳細を示すフローチャートである。 図２３は、実施例にかかる応答時間算出処理を示すフローチャートである。 図２４は、実施例にかかるＳＰＯＦ検出処理を示すフローチャートである。

以下、各実施例における動作を実行する装置は、必要な目的のために特別に構築されてもよいし、または、一つ以上のコンピュータプログラムにより選択的に起動または再設定される一つ以上の汎用コンピュータを含んでもよい。そのようなコンピュータプログラムは、例えば、光ディスク、磁気ディスク、読出専用メモリ、ランダムアクセスメモリ、固体記憶装置（Ｓｏｌｉｄ−Ｓｔａｔｅ Ｄｅｖｉｃｅ：ＳＳＤ）およびドライブ等のコンピュータ可読記憶媒体、または電子情報の保存に適している他の任意の媒体に保存できるが、これらに限定されない。
＜実施例の概要＞
図１は、実施例を示す概略図である。

後述するように、管理サーバ２０１の備える記憶装置２１３には、管理対象の計算機システムのシステム構成を示すシステム構成情報２３１、管理対象装置において実行される処理タスクの情報を示すタスク情報２３２、計算機システムのテナントを構成する装置群の量や種類の組合せ毎に、システム全体の負荷に応じた性能の劣化度合いを格納する負荷−性能対応情報２３３、システムに要求される処理による負荷の傾向を示す負荷トレンド情報２３４、計算機システムの運用ポリシー情報２３５を格納している。システム構成情報２３１には管理対象装置のコンポーネント情報の他に、ロードバランサによるノードサーバの負荷分散状況などの情報が格納されている。

管理サーバ２０１は、ある時刻に計算機システムの構成変更が行われることを想定した、システムの性能見積もり処理を行う。性能見積もり処理部２２１が、見積もり対象時刻について、システム構成情報２３１に基づいて計算機システムのピーク性能として期待される期待性能を算出する。また、負荷トレンド情報２３４やタスク情報２３２に基づいて、その時刻に想定される負荷の下で計算機システムが発揮し得る性能値の変動の幅（性能低下量）を示す性能劣化度合いを算出する。さらに、例えば想定する構成変更が急なサーバ縮退などである場合、縮退したサーバに対する処理要求が処理されなかったため他のサーバに再度割り振り直されることにより、システムの構成要素にかかる負荷が一時的に増加することによる、計算機システムの性能劣化度合いを算出する。これらの算出した性能劣化度合いに基づいて、応答時間算出処理部２２２がシステム応答時間を算出し、閾値と比較して結果を出力する。

近年、計算機システムの運用管理にサービスレベルマネジメント（ＳＬＭ）が求められるようになった。ＳＬＭでは、ＩＴシステムの応答時間や帯域などの目標値（サービスレベルオブジェクティブ：ＳＬＯ）を、ＩＴシステム提供者と利用者の間で取り決めており、この取り決めのことをサービスレベルアグリーメント（ＳＬＡ）と呼ぶ。サーバ障害などの原因によりシステムの構成変更が起こったとしても、計算機システムが簡単にＳＬＡに違反しない構成であるかを予め評価することは、システム運用において重要である。また、ＩＴシステムの構成変更時、特にシステムの縮退を行う時、構成変更によりＳＬＡを違反しないか確認したいという要求が有る。

本実施例により、特に構成変更が生じた場合の計算機システムの性能を精度良く見積もることができる。障害発生時のシミュレーションの他、例えばクラウドデータセンタなどのように、綿密な運用スケジュールに従うのではなく動的にシステム構成に変化が起こりえる環境においても、ＶＭの縮退やボリュームのデプロイなどの構成変更を実行する前に性能の推移をシミュレートしＳＬＯと比較することで、計算機システムの運用管理者は、構成変更によるＳＬＡ違反の可能性について予め評価することが出来る。

また、例えばシステムの状況に応じて、システム構成のオートスケールなどの構成変更を実施する運用ポリシーが設定されている際に、オートスケールによる構成変更が実行される前に性能の変化をシミュレートし、ＳＬＡ違反が起こる可能性について評価して、オートスケールによる構成変更実行の妥当性を判定することができるなど、より可用性の高い計算機システムを提供することが出来るようになる。

特にクラウドサービスにおいては、クラウドベンダは、計算機システムの可用性を容易に判定できるため、管理者の負担を軽減することが出来る。一方で、クラウドサービスの利用者にとっては、より信頼性の高いクラウドシステムを利用できることが考えられる。

以下、実施例１について図面を参照しながら説明する。

図２（Ａ）および図２（Ｂ）は、本実施例のシステム構成を表す図である。

管理サーバ２０１、操作端末２０２、サーバ装置２０３、ストレージ装置２０４、ネットワーク装置２０５は、リンク２０６を介して管理用ネットワーク２０７に接続される。サーバ装置２０３とストレージ装置２０４は、リンク２０８を介してネットワーク装置２０５に接続される。リンク２０６や２０８は、有線または無線の接続方式であり、一つ以上のサブネットワークや、ＶＰＮ（仮想プライベートネットワーク）を含んでいてもよい。管理サーバ２０１、操作端末２０２、サーバ装置２０３、ストレージ装置２０４、ネットワーク装置２０５は、それぞれ異なる方式で、管理用ネットワーク２０７ないしネットワーク装置２０５と接続されても良い。また、サーバ装置２０３とストレージ装置２０４は、ネットワーク装置２０５を介さずに、有線または無線の接続方式で直接接続されていても良い。なお、管理サーバ２０１は、本実施例の処理の目的のためには必ずしもサーバ装置２０３やストレージ装置２０４と接続されていなくても良く、処理に用いる各情報を取得し格納可能な構成であれば良い。

計算機システムが備える各装置は、図２（Ａ）に例示の台数でなくて良い。また、管理サーバ２０１、操作端末２０２、サーバ装置２０３、ストレージ装置２０４、ネットワーク装置２０５は、いずれか２つ以上が、同一の筐体ないし同一の仮想マシンであっても良い。ネットワーク装置２０５は、他のネットワーク装置２０５と優先または無線の接続方式で接続されていても良い。また、ネットワーク装置２０５により提供されるネットワークが、管理用ネットワーク２０７と同一でも良い。また、リンク２０６とリンク２０８が同一であっても良いし、リンク２０６またはリンク２０８に無線接続方式と有線接続方式が混在していても良い。

ネットワーク装置２０５は、図２（Ｂ）に示す通り、ＩＰスイッチ２０５ＡとＦＣスイッチ２０５Ｂの様に複数種類のネットワーク装置から構成されていてもよく、リンク２０８が、例えばイーサネット（登録商標）とＳＡＮの様に、複数のネットワークで構成されていてもよい。操作端末２０２は、図示しないプロセッサ、メモリ、主記憶、及び入力装置２１７、出力装置２１８を含む汎用コンピュータでよい。入力装置２１７と出力装置２１８は、例えばタブレット端末の様に、同一の装置であっても良い。

管理サーバ２０１は、プロセッサ２１１、主記憶２１２、記憶装置２１３、入力装置２１４、出力装置２１５、ネットワークＩ／Ｆ（インターフェース）２１６を備え、それらが相互に通信できるように接続されている。プロセッサ２１１が、主記憶２１２に格納された性能見積もり処理部２２１、応答時間算出処理部２２２、ＳＰＯＦ（単一障害点：Ｓｉｎｇｌｅ Ｐｏｉｎｔ ｏｆ Ｆａｉｌｕｒｅ）検出部２２３を実行することで、本実施例の各処理を行う。各処理部は、プロセッサ２１１で実行される代わりに、例えば各処理を行う集積回路等のハードウェアで実現しても良い。以下、説明を簡略化するため、主記憶２１２にあるプログラムをプロセッサ２１１が実行することで実現される処理について、各処理部を処理主体として説明する。

記憶装置２１３に格納されるシステム構成情報２３１、タスク情報２３２、負荷−性能対応情報２３３、負荷トレンド情報２３４、運用ポリシー情報２３５は、例えば、一部は管理サーバ２０１の記憶装置２１３に保存し、一部はストレージ装置２０４のＤＩＳＫ２５４に保存するなどのように、それぞれ異なる記憶媒体等に保存されていても良い。各情報は、計算機システムの管理者が手作業で端末装置によって入力してもよいし、何らかのツールやユーティリティにより生成され格納されても良い。なお、記憶装置２１３は、管理サーバ２０１の外部装置Ｉ／Ｆや、ネットワークＩ／Ｆを介して接続される装置が備えるものであっても良い。主記憶２１２と記憶装置２１３は同一の装置であっても良い。入力装置２１４と出力装置２１５は同一の装置であってもよいし、これらの両方または片方が存在しなくても良い。

サーバ装置２０３は、プロセッサ２４１、メモリ２４２、ネットワークＩ／Ｆ２４３、主記憶２４４を含む汎用コンピュータで良い。サーバ装置２０３は、管理サーバ２０１の管理対象装置であり、アプリケーション等を実行する。監視エージェント２４６は、サーバ装置２０３の状態を監視し、例えば、プロセッサ２４１やメモリ２４２、ネットワークＩ／Ｆ２４３、ディスク２４４、ＨＢＡ２４５の使用率、単位時間当たりの処理リクエスト数などの情報を取得する。

図２（Ｂ）に示す代表的な実施例において、サーバ装置２０３はＨＢＡ（Ｈｏｓｔ Ｂｕｓ Ａｄａｐｅｒ）２４５を有する。例えば、サーバ装置２０３は、ディスク２４４を仮想的にローカルディスクのように利用できる。このディスク２４４はＨＢＡ２４５及びストレージ装置２０４の記憶領域によって提供される。

ストレージ装置２０４は、管理サーバ２０１の管理対象装置であり、サーバ装置２０３上で動作するアプリケーション等が使用する記憶容量を提供する。ストレージ装置２０４は、ストレージコントローラ２５１、例えばイーサネットによるＬＡＮに接続するためのネットワークＩ／Ｆ２５２、例えばファイバチャネルなどのようなＳＡＮに接続するためのＩ／Ｏポート２５３、複数のＤＩＳＫ２５４から構成されるＲＡＩＤグループ２５５を含み、これらのデバイスが相互に通信できるように接続されている。ＤＩＳＫ２５４は、ＳＳＤ、光記憶媒体など他の種類の記憶媒体でも良い。また、ＲＡＩＤグループは論理的に複数のボリューム２５６を構成していて良い。監視エージェント２５７は、ストレージ装置２０４の状態を監視し、例えば、プロセッサ２４１やメモリ２４２、ネットワークＩ／Ｆ２４３、ディスク２４４、ＨＢＡ２４５の使用率、単位時間当たりの処理リクエスト数などの、管理対象装置の性能情報を取得する。ＩＰスイッチ２０５Ａは、ＬＡＮを構成するため、または他の目的のための管理対象装置で良い。ＦＣスイッチ２０５Ｂは、ＳＡＮを構成するため、または他の目的のための管理対象装置で良い。

ネットワーク装置２０５Ａ、２０５Ｂは、それぞれ、他の装置と同様の監視エージェントを含んでいて良い。

図３は管理対象システムのシステム構成例を示す。図４、図５及び図６は、図３に例示される管理対象システムの構成情報を示す。図７は管理対象システム内に含まれるテナントシステムの構成例を示し、図８は図７に例示されるテナントシステムの構成情報を示す。

システム構成情報２３１は、図４、図５、図６及び図８に例示する情報を含んで構成される。システム構成情報２３１は、計算機システムの管理者等が手作業で入力しても良いし、例えば監視エージェントが管理対象システムを構成する装置の情報を収集して生成するなど、何らかのツールやユーティリティにより生成されても良い。

図３に例示する管理対象システムは、ルータ（Ｒｏｕｔｅｒ＿０）、スイッチ（ＳＷ＿０）のネットワーク装置とサーバ装置（Ｍａｃｈｉｎｅ＿０、Ｍａｃｈｉｎｅ＿１、Ｍａｃｈｉｎｅ＿２）、ストレージ装置（Ｓｔｏｒａｇｅ＿Ａ）から構成されている。図３では、物理的なシステム構成の中で、仮想的なシステム構成として、Ｒｏｕｔｅｒ＿０上に仮想ルータ（Ｖｉｒｔｕａｌ Ｒｏｕｔｅｒ＿０）が、ＳＷ＿０上に仮想スイッチ（Ｖｉｒｔｕａｌ ＳＷ＿０）が、Ｍａｃｈｉｎｅ＿０上に仮想サーバ（Ｖｉｒｔｕａｌ Ｍａｃｈｉｎｅ＿０、Ｖｉｒｔｕａｌ Ｍａｃｈｉｎｅ＿１）が、Ｍａｃｈｉｎｅ＿２上に仮想サーバ（Ｖｉｒｔｕａｌ Ｍａｃｈｉｎｅ＿２）が配置されており、Ｍａｃｈｉｎｅ＿０、Ｍａｃｈｉｎｅ＿１、Ｍａｃｈｉｎｅ＿２はＳＷ＿０と接続されており、ＳＷ＿０はＲｏｕｔｅｒ＿０と接続されており、Ｒｏｕｔｅｒ＿０は外部のネットワークと接続されていることを示している。Ｉｎｐｕｔはシステム外部との接続点を示しており、管理対象システムの利用者からのアクセスが入力される箇所である。図３では単純なシステム構成例を示したが、実際には、多くの装置が含まれ、システム構成上の単一障害を発生させない様に複雑なトポロジで接続し、その上にさらに多くの仮想的なシステムが構築されると考えてよい。

図４はシステム構成情報２３１の一部である、物理的なシステム構成情報である物理システム構成情報４００を示す。物理システム構成情報４００は、システムを構成する物理装置の名前を示すホスト名４０１、ホスト名４０１に示される装置が接続されている装置を示す接続先４０２、システムを構成する物理装置の種類を示すホスト種別４０３を含む。物理システム構成情報４００は、更にプロセッサ等の詳細な構成情報を保持するなど、これら以外の不図示の列を含んでいても良いし、幾つかが存在しなくても良い。

図５にシステム構成情報２３１の一部である、仮想的なシステム構成情報である仮想システム構成情報５００を示す。仮想システム構成情報５００は、システムを構成する仮想的な装置の名前を示す仮想ホスト名５０１、ホスト名に示される仮想的な装置を提供する物理装置のホスト名を示す配置５０２、システムを構成する仮想的な装置の種類を示すホスト種別５０３を含む。仮想システム構成情報５００は、例えば、仮想マシンとして割り当てられたプロセッサの情報といった更に詳細な構成情報を保持するなど、これら以外の不図示の列を含んでいても良いし、幾つかが存在しなくても良い。

図６はシステム構成情報２３１の一部である、ホストのスペックを示すマシンスペック情報６００を示す。図６に例示されるマシンスペック情報６００は、システムを構成する物理装置や仮想的な装置の種類を示すホスト種別６０１、ホスト種別で示される装置が発揮できるカタログスペックを示す性能６０２を含む。マシンスペック情報６００は、例えば、サーバ装置を構成するプロセッサの動作周波数やメモリの容量などの更に詳細なスペック情報を保持するなど、これら以外の不図示の列を含んでいても良いし、幾つかが存在しなくても良い。ここで示す性能とは、例えばストレージ装置であればＩＯＰＳ（Ｉｎｐｕｔ Ｏｕｔｐｕｔ Ｐｅｒ Ｓｅｃｏｎｄ）、サーバであればＦＬＯＰＳ（Ｆｌｏａｔｉｎｇ−ｐｏｉｎｔ Ｏｐｅｒａｔｉｏｎｓ Ｐｅｒ Ｓｅｃｏｎｄ）などの、単位時間当たりに処理可能な処理量のことであり、以下の説明では比較を簡単にするために単位時間当たりに処理可能なリクエスト数（Ｋｒｅｑｕｅｓｔ／ｓｅｃ）とする。例えばカタログに記載されている性能値を基に作成する等の手法で作成されれば良い。後述する性能劣化度合いも同様の単位であり、マシンスペック情報に示す値と性能劣化度合いに示す値は、足し引きなどの四則演算が可能である。

図７は、計算機システムを利用して構成される、１つのテナントシステムの構成例を示す。図７に例示されるテナントシステム構成は、Ｖｉｒｕａｌ Ｒｏｕｔｅｒ＿０、Ｖｉｒｕａｌ ＳＷ＿０、Ｖｉｒｔｕａｌ Ｍａｃｈｉｎｅ＿０、Ｖｉｒｔｕａｌ Ｍａｃｈｉｎｅ＿１、Ｖｉｒｔｕａｌ Ｍａｃｈｉｎｅ＿２から構成される。Ｖｉｒｔｕａｌ Ｍａｃｈｉｎｅ＿０とＶｉｒｔｕａｌ Ｍａｃｈｉｎｅ＿１、Ｖｉｒｔｕａｌ Ｍａｃｈｉｎｅ＿２はＶｉｒｕａｌ ＳＷ＿０に接続されており、Ｖｉｒｔｕａｌ ＳＷ＿０はＶｉｒｕａｌ Ｒｏｕｔｅｒ＿０に接続されており、Ｖｉｒｔｕａｌ Ｒｏｕｔｅｒ＿０はＩｎｐｕｔに接続されている。Ｉｎｐｕｔは、外部のネットワークとの接続点を示しており、テナントシステムの利用者からのアクセスが入力される箇所である。

図７では、単純なテナントシステム構成を示したが、実際には、さらに多くの装置がテナントシステムを構成し、テナントシステム構成上の単一障害点を発生させない様に複雑なトポロジで接続され、テナントシステムが構成されると考えてよい。また、図７には一つのテナントシステムのシステム構成のみを示したが、実際には、異なるテナントシステム構成を持つ複数のテナントシステムが管理対象システムを構成すると考えてよい。

図８は、テナントシステム構成情報を示す。図８に例示されるテナントシステム構成情報８００は、テナントシステムを構成する装置名を示すホスト名８０１、ホストの接続先を示す接続先８０２、ホストのテナントシステム上の役割を示すホスト種別８０３を含む。これら以外の不図示の列を含んでいても良い。管理対象システムが複数のテナントシステムを含む場合、テナントシステム毎に、図８に例示する構成情報を保持すると良い。テナントシステム構成情報８００は、例えば構成管理用のプログラムなどを用いて作成されても良いし、運用管理者等が手作業で作成しても良い。

タスク情報２３２は、図９と図１０に例示される情報を含んで構成される。図１０はタスクの内容に関する詳細情報を示すタスク管理情報１０００を示す。図９は管理対象システムまたは管理対象システムに含まれるテナントシステムにおいて実行が予定されるタスクのスケジュール情報を示すタスクスケジュール情報９００である。

図１０に例示されるタスク管理情報１０００は、情報を識別するためのタスクＩＤ１００１、タスクの処理内容を示す処理内容１００２、タスクの実行開始から実行完了までにかかると見込まれる時間を示す実行所要時間１００３、タスクの実行によりシステムに与える負荷を示す操作負荷１００４、操作対象となる物理的または仮想的な装置のホスト種別を示すホスト種別１００５を含む。タスク管理情報１０００は、計算機システムの管理者が手作業で入力しても良いし、例えば実際にシステムを監視しつつタスクを複数回実行して統計的に所要時間やシステムに与える負荷を算出するなど、何らかのツールやユーティリティにより生成されても良い。

タスク管理情報１０００に格納される情報は、例えば、タスクＩＤがＴ０３とＴ０４のように同じ処理内容であっても、高負荷かつ短時間で終わるＴ０３と、低負荷だが長い処理時間を必要とするＴ０４のように、異なる特徴をもつタスク毎に保持すると良い。ここで、操作負荷とは、例えば単位時間あたりのリクエスト数（Ｋｒｅｑｕｅｓｔ／ｓｅｃ）のことで、例えば図３と図７に示すＩｎｐｕｔからのアクセスなど、外部のネットワークからのアクセスにより管理対象システムまたはテナントシステムに与えられる負荷と加算出来る値である。操作負荷は、例えば、実際にタスクを実行してシステムの処理性能劣化の度合いを計測し、性能劣化の度合いから、後述のシステム性能劣化度合い情報１２００を用いて、性能劣化の度合いと対応する負荷を算出するなどの手段により予め求めて、格納することが出来る。

図９に例示されるタスクスケジュール情報９００は、情報を識別するためのスケジュールＩＤ９０１、タスク管理情報のエントリとの対応関係を示すタスクＩＤ９０２、タスクの処理対象の構成要素を示す操作対象９０３、タスクの実行が予定される日時を示す実行予定日時９０４を含む。タスクスケジュール情報９００は、計算機システムの管理者が手作業で入力しても良いし、例えば管理サーバが不図示の管理情報に基づいて自動でタスクの実行予定を算出するなど、何らかのツールやユーティリティにより生成されても良い。また、テナントシステムごとに本テーブルが作成されていてよい。

負荷−性能対応情報２３３は、図１１、図１２、および図１３に例示される情報から構成される。図１１はシステム構成と構成毎の期待性能を示すシステム期待性能情報１１００を示す。図１２はシステム負荷と性能劣化度合いの対応を示すシステム性能劣化度合い情報１２００を示す。図１３は、システム負荷と各ホストで処理中の処理量との対応を示す処理中負荷情報１３００を示す。負荷−性能対応情報２３３は、例えば当該システム構成で発揮可能なピーク性能を負荷テストにより計測する等の手段で算出し、計算機システムの管理者が手作業で入力しても良いし、何らかのツールやユーティリティにより生成されても良い。性能見積もりに用いられる範囲の数値が格納されていればよい。また、例えば読み書き比率やリクエスト辺りのデータサイズなどのトランザクション（ここでトランザクションとは負荷の一例である）の特徴によりシステムが発揮可能なピーク性能が異なる場合に、負荷の特徴毎に異なる負荷−性能対応情報２３３を保持していて良い。図７に例示したテナントシステム構成は、構成ＩＤがＣ０４の行に該当する。

図１１に例示されるシステム期待性能情報１１００は、システム構成の識別子である構成ＩＤ１１０１と、システムを構成する装置群を示す構成内容１１０２、当該システム構成において発揮されることが期待されるピーク性能を示す期待性能１１０３を含む。ここで示す性能とは、マシンスペック情報６００の性能６０２と同様に、例えばストレージではＩＯＰＳ、サーバであればＦＬＯＰＳ等のような、単位時間当たりにシステムで処理可能な処理量のことであり、ここでは単位時間当たりにシステムで処理できるリクエスト数（Ｋｒｅｑｕｅｓｔ／ｓｅｃ）のことを示す。なお、システム期待性能情報１１００は、構成ＩＤとひもづけたシステムの構成内容を示す情報としても用いる。

図１２に例示されるシステム性能劣化度合い情報１２００は、外部のネットワークから管理対象システムまたはテナントシステムへの処理要求である負荷がかかっているときのシステム構成毎の性能劣化度合いを示す。外部からシステムに対してかかっている負荷の大きさを示す負荷１２０１と、負荷１２０１がかかっているとき実際に発揮し得る性能値の変動の幅を示す性能劣化度合い１２０２を含む。ここで負荷とは、例えばストレージであればボリュームへのＩ／Ｏ要求、ＷｅｂサーバであればＷｅｂページへのアクセス要求量、ＡＰサーバであれば、サーバを利用する業務のデータ処理要求量などのような、単位時間あたりにシステムに要求される処理量（Ｋｒｅｑｕｅｓｔ／ｓｅｃ）のことである。また、性能劣化度合いはマシンスペック情報６００の性能６０２やシステム期待性能情報１１００の期待性能１１０３と同様の単位（Ｋｒｅｑｕｅｓｔ／ｓｅｃ）であり、例えば負荷テストなどで性能劣化の程度を実際に計測する等の手法で求めることができる。システムに期待されるピーク性能を示す期待性能１１０３から、システム性能の変動の幅である性能劣化度合い１２０２を引き、システムが発揮しうる性能の最悪値を算出するという計算が可能である。

図１３に例示される処理中負荷情報１３００は、外部から負荷がかかっているときの各装置における処理中の負荷量を示す。外部から管理対象システムまたはテナントシステムへの処理要求である負荷を示す負荷１３０１と、システムに負荷１３０１がかかっているとき各装置において処理中である負荷の量を示す処理負荷１３０２とを含む。システム構成毎に各装置で処理される負荷が異なるため、システム構成ＩＤ１３０３毎に情報を保持している。ここで示す負荷１３０１と処理負荷１３０２はシステム性能劣化度合い情報１２００の負荷１２０１と同様の単位である。

図１７は、外部のネットワークから管理対象システムまたはテナントシステムへの処理要求である負荷情報の傾向を示す負荷トレンド情報２３４の一例を示す。図１７に例示する負荷トレンド情報２３４は、日時１７０１と、日時１７０１にシステムにかかる負荷の大きさを示す負荷１７０２を含む。管理サーバ２０１は、過去の負荷情報から算出された１日の各時間帯における負荷の平均値を、負荷トレンド情報２３４に予め格納している。図１７では例として各日の５秒おきのトレンドを示しているが、週ごとや月ごとであってもよく、時間帯の区切りもこれに限られない。算出した平均値を基に、システム管理者による調整した値の入力を受け付けて、負荷トレンド情報２３４に格納してもよい。また、例えば過去１ヶ月の負荷情報を基に生成された負荷トレンド情報と過去半年の負荷情報を基に生成された負荷トレンド情報などの様に、傾向算出のための情報取得の期間毎に、複数の負荷トレンドを保有していてもよい。

図１８は、運用ポリシー情報２３５の内容を示す。運用ポリシー情報２３５は、例えばテナントが利用するシステムの状況に応じて、ユーザ操作の入力を受け付けることなく自動的にシステム構成を変更するためのポリシーを格納する。運用ポリシーの識別子であるポリシーＩＤ、ポリシーにより実行されるタスクの実行内容を示す自動実行内容１８０２と、運用ポリシーにより実行されるタスクの識別子を示すタスクＩＤ１８０３、とを含み、運用ポリシーの実行条件を示す条件、例えば条件１８０４、条件１８０５、条件１８０６などを少なくとも１つ以上含む。

図１９（Ａ）、図１９（Ｂ）、図１９（Ｃ）は、本実施例の性能見積もり処理の結果を、出力装置２１５または出力装置２１８に出力する画面（以下、出力画面）の表示内容を例示する図である。横軸が時刻を示しており、性能見積もり処理を実施した対象期間が表示されていれば良い。

図１９（Ａ）の縦軸は性能であり、性能見積もり処理２２１により算出したシステム性能を用いる。性能の単位はシステム期待性能情報１１００のシステム期待性能１１０３等と同様に、単位時間当たりにシステムが処理できるリクエスト数である。図１９（Ａ）は、例えば性能を帯域で表される場合の一例であり、構成変更に伴うシステムの期待性能の推移を実線で、そのときのタスクと負荷トレンドによる性能の劣化範囲を点描で示された領域で、構成変更時に構成変更箇所で未完了であった処理についての再リクエスト分の負荷増大による性能の悪化範囲を、ひし形の背景パターンで表示される領域で示している。これらの性能の予測結果と、ＳＬＯなどの閾値をあわせて表示する。これらの性能予測範囲は、区別して表示しなくてもよく、例えば予測される最悪値、または平均値のみなど、予測範囲の一部だけを示しても良い。

図１９（Ｂ）と図１９（Ｃ）は応答時間の推移を示しており、予測されるシステム応答時間の最悪の値が表示されている。この性能の予測結果と、例えばＳＬＯなどの閾値をあわせて表示する。図１９（Ｂ）と図１９（Ｃ）の縦軸は応答時間であり、応答時間算出処理により算出したシステムの応答時間を表示する。図１９（Ｂ）に例示する出力画面例は、システムの構成変更により応答時間が瞬間的に増大するが、その後は応答時間が収束して閾値よりも低い値に応答時間が落ち着くことを示している。一方、図１９（Ｃ）に例示する出力画面例は、構成変更によりシステムの応答時間が、例えばシステムのタイムアウト時間よりも遅くなるなど、閾値を超えて悪化し、それにより応答時間が自然には回復しなくなる可能性があることを警告している。

出力画面にはグラフ表示とともに、たとえばシミュレーションの情報として、どのＶＭがいつ縮退する場合を想定したかなど、構成変更に関する情報を表示してもよい。さらに図１９（Ｂ）においてはＳＬＯの超過が推定される時間、また図１９（Ｃ）の場合は現状のシステム構成では構成変更に耐えられない旨のアラートを表示してもよい。また、後述のように構成変更タスクの自動実行ポリシーが満たされたことを契機として当該タスクによる構成変更に関して性能見積もり処理を行った場合は、グラフ表示を当該タスクが実行された場合の想定結果として、システムの状況及び当該タスクを自動実行予定である旨とともに表示してよい。

図２０、図２１、図２２は、管理サーバ２０１の性能見積もり処理部２２１の処理内容を示すフローチャートの一例である。図２０に例示する性能見積もり処理フローが図２１に例示する瞬間性能見積もり処理フローを再帰的に呼び出すことでシステム性能の変化の推移を算出する。また、図２１に例示する瞬間性能見積もり処理フローは図２２に例示する運用ポリシー判定処理フローを呼び出し、運用ポリシーによりタスクが自動実行される可能性があるか否かを判定し、タスクが実行される可能性がある場合は当該タスクの負荷による性能劣化の度合いを算出する。

図２０は、性能見積もり処理部２２１がある期間のシステム性能の推移をシミュレーションする性能見積もり処理を示すフローチャートである。性能見積もりを行う対象期間について、任意の時間間隔ごとに、ある時点（以降、「見積もり対象時刻」という）のシステムの性能を見積もる瞬間性能見積もり処理を行う。その時点までの構成変更の有無を考慮して見積もり対象時刻のシステム構成を特定し、期待性能を算出する。また、システム内で実行が予定されるタスクや、外部からシステムにかかっている負荷によって起こりうるシステム性能の変動の幅を、システム性能劣化度合いとして算出する。さらに、想定する構成変更が、例えばＶＭ縮退など、システムを縮退させる構成変更である場合は、縮退する構成要素において未完了状態であった処理の再リクエストによるシステムへの負荷によってさらに生じうる、性能劣化の範囲を算出する。また、構成変更によるシステム性能の変化の結果、例えばオートスケールなどのタスクを自動実行する運用ポリシーの条件を満たす可能性があるか否かを判定し、可能性があると判断した場合は、自動実行タスクによる構成変更や処理負荷の影響を考慮した性能値を算出する。これらの、各対象時刻についてそれぞれ算出した性能に関する情報を、システム性能の変化の推移として出力する。性能の変化の推移と併せて、例えばＳＬＯなどの閾値を出力してもよい。

性能見積もり処理は、例えば計算機システム管理者が構成変更を計画する際に、管理対象システムの中から構成変更を想定するテナントシステムを選択し、当該テナントシステムについて性能見積もり処理を行うなど、計算機システム管理者の指示を受け付けて実行されても良い。また、例えば構成変更を実行するタスクの自動実行ポリシーが、システム性能やシステム負荷などの実行条件と共に設定されている管理システムにおいて、タスクが自動実行される前に性能見積もりを行い実行条件が満たされているか判定するなど、何らかのツールやユーティリティにより実行されても良い。

性能見積もり処理部２２１は、Ｓ２００１で、
１）性能見積もり処理を実施する対象システムの構成ＩＤ１１０１、
２）性能見積もり処理を行う対象期間、
３）瞬間性能見積もりの見積もり対象時刻の時間間隔、
４）構成変更を想定する管理対象ホスト名（ホスト名４０１または仮想ホスト名５０１）、
５）構成変更の想定時刻、
６）想定する構成変更の内容に対応するタスクＩＤ１００１、
を、入力情報として取得する。ここで取得する情報は、それぞれ入力装置２１４または入力装置２１６を用いてシステム管理者からの入力を受け付けても良いし、何らかのツールやユーティリティにより入力されても良い。たとえば、１）はシステム管理者が対象システムのテナント構成情報８００を確認するなどして、対象システムの構成を把握し、該当する構成ＩＤ１１０１を入力することとしても良い。

また、タスクの自動実行前に性能見積もり処理を行う構成の場合は、Ｓ２００１はたとえば以下の処理となる。

あるテナントシステム等が構成変更タスクの自動実行ポリシーに合致する状況になったことを契機として、不図示のツールやユーティリティが、１）自動実行タスクにより構成変更を実施する予定のシステムの構成ＩＤ１１０１と、４）構成変更の対象となるホスト名、５）構成変更の予定時刻、６）自動実行予定のタスクのタスクＩＤを、性能見積もり処理部２２１に通知する。構成変更の予定時刻は、自動実行されるまでに一定の猶予期間が設けられており、ポリシーに合致する状況となってから一定時間後の実行が予定される構成であることが考えられる。また、２)対象期間（長さ）、及び３）時間間隔は、性能見積もり処理部２２１が予め定められた値を備えていて良い。
また、計画外の構成変更を想定して見積もりを行うのではなく、既にタスクスケジュール情報９００に格納されているタスクの処理による影響を見積もりたい場合には、４）−６）の情報を受け付けなくてよい。あるいは、スケジューリング済みの特定のタスクの実行前後のシミュレーションを行う場合は、スケジュールＩＤ９０１をユーザが選択して、入力を受け付けることとしてもよい。また、ユーザにはタスクＩＤやスケジュールＩＤではなくそれに対応する情報を入力、選択させて、入力に対応するＩＤ等を参照する処理を行ってよい。

対象期間を期間の長さとして受け付ける場合は、入力された構成変更の想定時刻（または選択されたタスクの実行日時９０４）から対象期間の半分の時間を差し引くなどの手段により、対象期間の開始時刻を算出して良い。また、具体的な開始・終了時刻の指定を受け付ける構成であっても良い。

システム構成情報２３１の物理システム構成情報４００または仮想システム構成情報５００を参照して、取得した管理対象ホスト名に該当する装置のホスト種別を取得する。また、タスクスケジュール情報９００を参照して、対象期間中に実行している（実行中、または実行を開始する）予定のスケジュール情報を取得する。タスク管理情報１０００を参照し、入力されたタスクＩＤ１００１及び取得したスケジュール済みのタスクＩＤ９０２に対応する、各情報１００２−１００５を取得する。

Ｓ２００２では見積もり対象時刻について瞬間性能見積もり処理を実施し、
１）対象時刻のシステム構成における期待性能、
２）システム負荷、システムで実行されるタスク、及び構成変更の影響によるシステム性能の変動の幅である性能劣化の度合い、
３）構成変更が縮退方向であった場合に、未完了状態の処理の再リクエスト負荷による性能劣化の度合い、
４）運用ポリシーに基づき自動実行されるタスクの影響による性能劣化の度合い
を算出する。瞬間性能見積もり処理の詳細については、図２１を用いて後述する。

Ｓ２００３では、Ｓ２００１で受信した対象期間全体の各見積もり対象時刻について見積もり処理を実行したかを判定する。対象期間の瞬間性能見積もり処理を完了した場合はＳ２００４に進み、そうではない場合Ｓ２００２を再度実行する。Ｓ２００３からＳ２００２に戻る際は、前回の見積もり対象時刻にＳ２００１で取得した３）時間間隔を足し合わせた値を、次の見積もり対象時刻とする。

Ｓ２００４では、算出した計算機システムの性能と、ＳＬＡまたはＳＬＯなどの閾値を比較する。システム性能が下回ってはいけない閾値を超えた場合はＳ２００５に進む。算出した結果がＳＬＡやＳＬＯを違反しない場合は、対象期間の瞬間性能見積もりの値をシステム性能の変化の推移として出力し、性能見積もり処理フローを終了する。

Ｓ２００５では、算出結果に閾値を超える値が含まれる場合に、各時刻の瞬間性能と閾値を比較する。例えば、瞬間性能が閾値を超えた結果の数とＳ２００１で取得した時間間隔とを掛け合わせるなどの手段により、システム性能が閾値を超えている時間を算出し、算出したシステム性能の変化の推移とともにシステム性能が閾値を超えている時間を出力して性能見積もり処理を終了する。

性能見積もり処理は、これら以外の不図示の処理を含んでいても良い。各ステップにおいて算出された値は、例えばメモリに格納するまたはファイルに出力するなどの形式で出力されれば良い。

図２１は、瞬間性能見積もり処理Ｓ２００２の詳細を示すフローチャートである。瞬間性能見積もり処理は、これら以外の不図示の処理を含んでいても良いし、例えばＳ２１０６など幾つかのステップが実施されなくても良い。

Ｓ２１０１では、見積もり対象時刻を、Ｓ２００１で取得した構成変更の想定時刻、及びタスクスケジュール情報９００に格納されている各構成変更の予定時刻と比較し、見積もり対象時刻が構成変更よりも前か（以降、「構成変更前」という）、見積もり対象時刻が構成変更完了後なのか（以降、「構成変更後」という）を、判定する。タスクＩＤ１００１の示す処理内容１００２が、例えばＶＭデプロイなどの様に、システムを拡張する構成変更の場合は、構成変更の実行予定時刻から実行所要時間１００３が経過した時刻以降を構成変更後とみなす。処理内容１００２が、例えばＶＭ縮退など、システムを縮退させる構成変更の場合は、構成変更の実行予定時刻以降を構成変更後とみなす。また、処理内容１００２がいずれでもない場合は、構成変更が実行される時刻以後を構成変更後とみなす。いずれの場合においても、構成変更が実行される時刻から、実行所要時間が経過するまでの期間は実行中として、構成変更による操作負荷１００４がシステムにかかり続けると考えてよい。

Ｓ２１０２では、Ｓ２１０１の判定結果、負荷−性能対応情報２３２、及びシステム構成情報２３１を用いて、見積もり対象時刻に想定されているシステム構成の期待性能を算出する。見積もり対象時刻が各タスクの構成変更前か後かを考慮して見積もり対象時刻のシステム構成を特定し、システム期待性能情報１１００の該当する構成ＩＤ１１０１に対応する期待性能１１０３を、対象時刻の期待性能として取得する。構成変更後の場合、システム構成ＩＤは、当該変更がシステムの縮退処理であれば、構成変更前のシステム構成ＩＤが示す構成内容１１０２から構成変更対象装置のホスト種別を差し引いた構成内容を示す構成ＩＤとなる。当該変更がシステムの拡大処理の場合は、対象装置を加えた構成内容を示す構成ＩＤが構成変更後のシステム構成に該当し、これら以外の処理の場合は構成変更前と同じ構成ＩＤを構成変更後のシステムの構成ＩＤとする。タスクが縮退方向の構成変更処理であるかどうかは、タスクＩＤごとに不図示のフラグが付されており、フラグにより判別できるとして良い。

Ｓ２１０３では、タスク情報２３２、負荷−性能対応情報２３３、負荷トレンド情報２３４を用いて、システム負荷とタスクの実行による負荷と構成変更の負荷によるシステムの性能劣化の度合いを算出する。システム負荷とは、性能見積もり対象システムに対して外部のネットワーク等を介してなされる業務処理、データへのアクセスなどの処理要求のことであり、負荷トレンド情報２３４を参照して、見積もり対象時刻の負荷１７０２を取得することで求める。タスクの実行による負荷とは、タスクの操作処理がシステムに与える負荷のことであり、タスクスケジュール情報９００の実行日時９０４からタスク管理情報１０００の実行所要時間１００３が経過するまでの期間に、見積もり対象時刻が該当する場合に、操作負荷１００４をタスクの実行による負荷として取得する。なお、同時に複数のタスクが実行されている場合などは、複数のタスクの操作負荷１００４の総計をタスクの実行による負荷として扱う。

構成変更の負荷とは、想定する構成変更を実現する処理がシステムへかける負荷のことであり、見積もり対象時刻が、当該構成変更の実行中である場合に、構成変更のタスクＩＤ１００１が示す操作負荷１００４を構成変更による負荷として扱う。システム負荷と各タスクの実行による負荷と構成変更による負荷の総和を、システムにかかる総負荷（後述の再リクエストによる負荷を除く）として扱って良い。

システム性能劣化度合い情報１２００を参照して、算出したシステムの総負荷が相当する負荷１２０１に対応する性能劣化度合いのうち、見積もり対象時刻のシステムの構成ＩＤに対応する性能劣化度合い１２０２を、システム性能劣化度合いとして算出する。

Ｓ２１０４では、負荷−性能対応情報２３３を用いて、構成変更による縮退箇所で未完了状態の処理の再リクエストによる負荷を算出する。本処理ステップにより、急な縮退により発生した未完了状態の処理のリクエストが、他の構成要素に再送されると想定した時にかかるシステムの負荷を求めることができる。本処理ステップは、見積もり対象時刻が、縮退処理となる構成変更後である場合に実行される。

Ｓ２１０４では、処理中負荷情報１３００を参照して、Ｓ２１０３で算出したシステムの総負荷が相当する負荷１３０１に対応する処理負荷１３０２より、見積もり対象時刻の構成ＩＤ（構成変更実行前のシステム構成）及び構成変更対象装置のホスト種別４０３または５０３に対応する処理負荷１３０２を、縮退箇所で未完了状態の処理の再リクエストによる負荷として取得する。負荷１３０１の値は、処理中負荷情報１３００に格納されている中から総負荷の値に一番近いものを選択すればよい。

Ｓ２１０４は、性能見積もり処理２２１の中で構成変更による縮退の直後に一度実行されればよく、不図示の設定情報を保持しておき、ループの２度目以降は実行されない設定としても良い。また、例えば３回まで実行するなどのように、回数を指定するなどの設定でも良い。複数の対象時刻について実行する場合は、縮退後から前回のループ処理までの見積もり対象時刻について算出したシステムの瞬間性能値に基づいて、縮退直後の未完了処理として算出したうちの既に処理された量を算出し、未完了処理の残量について以降の処理を行う。前回までの時刻の瞬間性能値は最悪値を用いればよい。

Ｓ２１０５では、負荷−性能対応情報２３３を用いて、縮退箇所で未完了状態であった処理の再リクエストによる性能劣化の度合いを算出する。このステップは、Ｓ２１０４が実行された場合のみ実行されれば良い。Ｓ２１０３で算出したシステムの総負荷と、Ｓ２１０４で算出した未完了状態の処理の再リクエストによる負荷を足し合わせた値をシステム瞬間負荷とする。システム性能劣化度合い情報１２００を参照して、システム瞬間負荷に相当する負荷１２０１に対応する性能劣化度合い１２０２より、Ｓ２１０２で算出した構成変更後のシステム構成ＩＤに対応する性能劣化度合いを取得し、取得した性能劣化度合いからＳ２１０３で算出したシステム性能劣化度合いを差し引いた値を、縮退箇所で未完了状態であった処理の再リクエストの負荷によるシステムの性能劣化の度合として算出する。

Ｓ２１０６では、システムの状況が変化した等で、運用ポリシー情報２３５の条件が満たされた結果として自動実行されるタスクの影響によるシステム性能劣化の度合いを算出する。Ｓ２１０１〜Ｓ２１０５で算出したシステムの期待性能から、システムの総負荷によるシステム性能劣化の度合いと、未完了状態である処理の再リクエストの負荷による性能劣化の度合いとを差し引いた値を、システム性能の想定内の最悪値として算出する。算出結果と運用ポリシーの条件を比較して、条件を満たす運用ポリシーが存在する場合は、ポリシーによりタスクが自動実行される可能性があると判断し、当該タスクの影響によるシステム性能劣化の度合いを算出する。図２２を用いて本ステップの詳細を説明する。

以上の瞬間性能見積もり処理により算出された結果は、例えばメモリに格納する、ファイルに出力するなどの形式で出力されれば良い。

図２２は、Ｓ２１０６の運用ポリシー判定処理の詳細を示すフローチャートである。本処理フローでは、運用ポリシーに基づき自動実行されるタスクの負荷や構成変更を考慮した性能見積もりを実施する。システムの状況改善のために自動実行による構成変更が行われたにも関わらず、その構成変更そのものによる負荷がかかることにより、性能がさらに悪化する可能性がある。性能見積もりの際に、運用ポリシーに基づく自動実行も考慮して算出することにより、そのポリシーの妥当性についても予め評価することができる。たとえば自動実行の結果ＳＬＡを満たせなくなる場合、そのようなポリシーは妥当でない可能性があることが分かる。

瞬間性能見積もり対象時刻において、運用ポリシー情報２３５の条件１１８０３などの条件が満たされた結果自動実行されるタスクの操作負荷１００４によるシステム性能劣化の度合いを算出する。運用ポリシー判定処理はこれら以外の不図示の処理を含んでいても良い。ここでタスクが自動実行されるとは、予め定められた運用ポリシーの条件に合致したことを契機として、管理者等によるユーザ操作の受付を要件とせずに実行されることを指す。

Ｓ２２０１では運用ポリシー情報２３５に格納されている運用ポリシーに対して、運用ポリシーの条件１８０４、１８０５などの条件が全て満たされているか否かを判定する。条件の全てが満たされなければタスクの自動実行はされないとして良い。計算機システムの性能への影響の算出にあたっては、対象期間において初めて運用ポリシーの条件を満たしてから、当該ポリシーにより自動実行されるタスクを実行完了するまでの期間（初めて運用ポリシーの条件を満たした時刻から、実行されるタスクの実行所要時間１００３が経過するまでの期間）を当該タスクの実行期間と見做す。当該タスクの実行期間の間は、当該タスクの操作負荷１００４がシステムに余剰にかかる。当該タスクの実行期間以後は、例えば以後１０分間の間は同一のタスクは自動実行しないなどのように、一定期間の間同一の運用ポリシーは有効としないという不図示の設定情報が保持されていれば、その内容に従って特定の運用ポリシーに関しては運用ポリシー判定処理での判定対象から外すなどの例外処理をしてもよい。この例外処理により、同一の運用ポリシーにより何度も同一の構成変更を実施するといった不具合を解消するなどの効果がある。Ｓ２２０１の判定ですべての条件が満たされている運用ポリシーがないと判定された場合、運用ポリシー判定処理フローは終了し、いずれかの運用ポリシーの条件が全て満たされている場合は、Ｓ２２０２に進む。

Ｓ２２０２では、Ｓ２１０２と同様にシステム構成に基づくシステムの期待性能を算出する。運用ポリシーに基づき自動実行されるタスクが、構成変更を行いかつシステムを縮退させる処理であった場合、タスクの実行期間及びタスクの実行終了以後は、タスク実行前のシステム構成からタスクにより縮退する構成要素を差し引いたシステム構成の構成ＩＤ１１０１の期待性能１１０３を取得する。運用ポリシーにより実行されるタスクがシステムに構成変更を加え、かつシステムを拡張させる処理であった場合、タスクの実行期間中はタスク実行前のシステム構成の期待性能を取得し、タスクの実行期間以後であればシステム構成ＩＤの指し示すシステム構成にタスクにより追加される構成要素を足したシステム構成の構成ＩＤ１１０１の期待性能１１０３を取得する。

Ｓ２２０３では、システム性能劣化度合い情報１２００を参照して、Ｓ２２０２で判断したシステム構成における、負荷に応じた性能劣化度合い１２０２を取得する。運用ポリシーの実行期間中であれば、前述のシステムの総負荷と運用ポリシーにより実行されるタスクによる操作負荷１００５を足し合わせた負荷量を、運用ポリシーの実行期間終了後であれば、前述のシステム総負荷を、負荷１２０１として用いれば良い。

Ｓ２２０４では、運用ポリシーにより実行されるタスクが縮退方向の処理であった場合に、Ｓ２１０４と同様の手法により、タスクにより縮退する装置で未完了状態となるリクエストの処理量を算出する。

Ｓ２２０５では、Ｓ２２０４で算出した未完了状態である処理の再リクエスト負荷による性能劣化の度合いを、Ｓ２１０５と同様の手法により算出する。

運用ポリシー判定処理により算出された、システムの期待性能、負荷による性能劣化の度合い、未完了状態である処理の再リクエスト負荷による性能劣化の度合いは、例えばＳ２１０２、Ｓ２１０３、Ｓ２１０５で算出された値を上書き保存する等の手法で更新することで出力されればよい。

以上の性能見積もり処理の具体例を説明する。例えば、図７に例示する構成ＩＤがＣ０４のテナントシステムについて、２０１３年１０月３０日８時００分００秒に、Ｖｉｒｔｕａｌ Ｍａｃｈｉｎｅ＿２の縮退というタスクＩＤがＴ０５の構成変更を実行することを想定した場合に、構成変更を実行する前後１分間を対象期間とし、見積もり対象時刻を５秒間隔で、システム性能の変化の推移をシミュレーションするなどの情報の入力を受け付ける。ここで、仮想システム構成情報５００を参照してＶｉｒｔｕａｌ Ｍａｃｈｉｎｅ＿２のホスト種別がＶＭ＿Ｂであることを取得する（Ｓ２００１）。

２０１３年１０月３０日７時５９分００秒から２０１３年１０月３０日８時０１分００秒まで５秒間隔のテナントシステムの瞬間性能を算出する（Ｓ２００２）。

２０１３年１０月３０日８時００分００秒を対象時刻とする瞬間性能見積もり処理の例を説明すると、Ｓ２１０１では、まず瞬間性能見積もり対象時刻が構成変更の予定時刻であり、想定するタスクのタスクＩＤ Ｔ０５と対応する処理内容１００２のＶＭ縮退が、縮退方向の構成変更であるため、構成変更後のシステム構成を取得する。システム期待性能情報１１００を参照して、構成変更前のシステム構成ＩＤ Ｃ０４の構成から、縮退されるＶｉｒｔｕａｌ Ｍａｃｈｉｎｅ＿２のホスト種別であるＶＭ＿Ｂが差し引かれたシステム構成の構成内容１１０２を検索し、Ｃ０１を選択する。

Ｓ２１０２では、システム期待性能情報１１００から、Ｃ０１のシステムにおける期待性能２．０[ＫＲｅｑｕｅｓｔ／ｓｅｃ]を取得する。

Ｓ２１０３では、まず負荷トレンド情報２３４から、２０１３年１０月３０日８時００分００秒におけるシステムへの負荷は、１．３[ＫＲｅｑｕｅｓｔ／ｓｅｃ]であることを取得する。さらに、タスク情報２３２から２０１３年１０月３０日８時００分００秒に実行中のタスクがあるかを調べる。スケジュールＩＤ Ｓ０１のタスクの実行日時９０４が２０１３年１０月３０日７時００分００秒であり、タスクＩＤ０４のタスクの実行所要時間１００３は２時間であるため、２０１３年１０月３０日８時００分００秒は当該タスクが実行中であり、システムに対して操作負荷１００４の０．２[ＫＲｅｑｕｅｓｔ／ｓｅｃ]相当の負荷をかけている。また、想定される構成変更の処理による負荷は、タスク管理情報１０００から、タスクＩＤＴ０５の操作負荷１００４の０．１[ＫＲｅｑｕｅｓｔ／ｓｅｃ]相当であることが分かる。算出したシステム負荷とタスクの実行による負荷と構成変更の負荷を足し合わせて、構成変更を実行する瞬間にシステムにかかっているシステム総負荷は１．６[ＫＲｅｑｕｅｓｔ]相当であると算出する。次に、システム性能劣化度合い情報１２００から、システムへの負荷が１．６[ＫＲｅｑｕｅｓｔ]であるときのＣ０１のシステムにおける性能劣化度合いは１．０[ＫＲｅｑｕｅｓｔ／ｓｅｃ]であることを算出する。

Ｓ２１０４では、想定される構成変更がＶＭの縮退であることから、縮退箇所で未完了状態であるリクエストの処理量を算出する。縮退箇所のＶｉｒｔｕａｌ Ｍａｃｈｉｎｅ＿２のホスト種別はＶＭ＿Ｂであるため、処理中負荷情報１３００を参照して、構成変更前のシステム構成であるＣ０４のシステムの総負荷が１．６[ＫＲｅｑｕｅｓｔ]の時に、ＶＭ＿Ｂで処理中の負荷量０．８[ＫＲｅｑｕｅｓｔ]を取得する。

Ｓ２１０５では、縮退箇所で未完了状態である処理の再リクエストによる性能劣化の度合いを算出する。構成変更が実行される瞬間のシステムの総負荷１．６[ＫＲｅｑｕｅｓｔ]と縮退箇所で未完了状態である処理である０．８[ＫＲｅｑｕｅｓｔ]を足し合わせて、システムの瞬間負荷が２．４[ＫＲｅｑｕｅｓｔ]であると算出する。システム性能劣化度合い情報１２００から、算出したシステムの瞬間負荷２．４[ＫＲｅｑｕｅｓｔ]がかかっているときの、システム構成Ｃ０１のシステムの性能劣化の度合いは１．８[ＫＲｅｑｕｅｓｔ／ｓｅｃ]であることを取得し、Ｓ２１０５で算出した性能劣化度合い１．８[ＫＲｅｑｕｅｓｔ／ｓｅｃ]からＳ２１０３で算出したシステムの性能劣化度合い１．０[ＫＲｅｑｕｅｓｔ／ｓｅｃ]を差し引くことで、縮退箇所で未完了状態である処理の再リクエストによる性能劣化の度合いは０．８[ＫＲｅｑｕｅｓｔ／ｓｅｃ]と算出する。

Ｓ２１０６の運用ポリシー判定処理の具体例を説明する。運用ポリシー２３５のポリシーＩＤがＰ０１のポリシーは、条件を３つ備えている。テナント構成情報８００から、構成変更後にテナントを構成するＷｅｂサーバはＶｉｒｔｕａｌ Ｍａｃｈｉｎｅ＿０とＶｉｒｔｕａｌ Ｍａｃｈｉｎｅ＿１の２台になることが分かり、条件１８０５に該当する。仮想システム構成情報５００を参照すると、Ｖｉｒｔｕａｌ Ｍａｃｈｉｎｅ＿０とＶｉｒｔｕａｌ Ｍａｃｈｉｎｅ＿１のホスト種別はＶＭ＿Ａである。処理中負荷情報１３００より、システムの瞬間負荷２．４[ＫＲｅｑｕｅｓｔ]がかかっているとき、システム構成ＩＤがＣ０１のＶＭ＿Ａでの処理中負荷は１．０[ＫＲｅｑｕｅｓｔ]であることが分かり、条件１８０４を満たす。運用ポリシーＰ０１により実行されるタスクのタスクＩＤはＴ０１である。タスク管理情報１０００を参照すると、Ｔ０１によりデプロイされる装置のホスト種別はＶＭ＿Ａである。物理システム構成情報４００を参照して、Ｍａｃｈｉｎｅ＿０のホスト種別はＳｅｒｖｅｒ＿Ａであり、仮想システム構成情報５００を参照するとＭａｃｈｉｎｅ＿０にはＶＭ＿Ａが２台存在する。マシンスペック情報６００から、Ｓｅｒｖｅｒ＿Ａの性能は４．０［Ｋｒｅｑｕｅｓｔ／ｓｅｃ］であり、ＶＭ＿Ａの性能は２．０［Ｋｒｅｑｕｅｓｔ／ｓｅｃ］であるため、Ｓｅｒｖｅｒ＿Ａには、ＶＭ＿Ａをデプロイさせるだけの空き容量があり、条件１８０６を満たす。以上より、ポリシーＩＤＰ０１に基づいてタスクＴ０１が自動実行されるため、Ｓ２２０１はＹｅｓである。

Ｓ２２０２では、システムの期待性能を算出する。運用ポリシーに基づき自動実行されるタスクはＶＭデプロイであるため、システムの期待性能はＳ２１０５までの処理で算出したシステム構成であるＣ０１の構成の期待性能を算出する。システム期待性能情報１１００から、Ｃ０１のシステムでのシステム期待性能は２．０［Ｋｒｅｑｕｅｓｔ／ｓｅｃ］であるとわかる。

Ｓ２２０３では、システムにかかっている負荷による性能劣化の度合いを算出する。運用ポリシーに基づき自動実行されるタスクの処理負荷は、タスク管理情報１０００よりＴ０１の操作負荷である０．１［Ｋｒｅｑｕｅｓｔ／ｓｅｃ］である。運用ポリシーに基づき自動実行されるタスクの処理負荷とＳ２１０５までの処理で算出したシステムの瞬間の総負荷を足すと１．７［Ｋｒｅｑｕｅｓｔ］である。システム性能劣化度合い情報１２００より、瞬間に１．７［Ｋｒｅｑｕｅｓｔ］の負荷がかかっているときのＣ０１構成におけるシステム性能劣化度合いは０．８５［Ｋｒｅｑｕｅｓｔ／ｓｅｃ］である。

Ｓ２２０４では、縮退箇所で未完了状態のリクエストの処理量を算出する。運用ポリシーにより実行されるタスクはＶＭのデプロイであり、新たに未完了状態の処理量は増えず、Ｓ２１０５で算出した縮退箇所で未完了状態の処理量０．８［Ｋｒｅｑｕｅｓｔ］を用いる。

Ｓ２２０５では、縮退箇所で未完了状態である処理の再リクエストによる性能劣化の度合いを算出する。Ｓ２２０２で算出したシステムの総負荷１．７［Ｋｒｅｑｕｅｓｔ］と、Ｓ２２０３で算出した縮退箇所で未完了状態の処理量０．８［Ｋｒｅｑｕｅｓｔ］から、システムの瞬間負荷は２．５［Ｋｒｅｑｕｅｓｔ］である。システム性能劣化度合い情報１２００より、システムにかかっている瞬間負荷が２．５［Ｋｒｅｑｕｅｓｔ］のとき、Ｃ０１の構成のシステムでの性能劣化度合は１．９［Ｋｒｅｑｕｅｓｔ／ｓｅｃ］である。Ｓ２２０５で算出した性能劣化度合１．９［Ｋｒｅｑｕｅｓｔ／ｓｅｃ］から、Ｓ２２０３で算出した性能劣化度合０．８５［Ｋｒｅｑｕｅｓｔ／ｓｅｃ］を差し引くことで、運用ポリシーに基づきタスクが自動実行された場合、縮退箇所で未完了状態である処理の再リクエストによる性能劣化の度合いは１．０５［Ｋｒｅｑｕｅｓｔ／ｓｅｃ］と算出できる。

これらの処理により、運用ポリシーにより実行されるタスクの負荷を考慮した性能劣化の度合いが算出できる。また、システムの期待性能から、システムにかかっている負荷による性能劣化の度合いと縮退箇所で未完了状態の処理の再アクセスによる性能劣化の度合いを差し引くことにより、システムの性能の最悪値を０．１[ＫＲｅｑｕｅｓｔ／ｓｅｃ]と算出できる。

Ｓ２００３では、性能見積もり期間が終了したか否かを判定する。Ｓ２００２の瞬間性性能見積もりの対象時刻は２０１３年１０月３０日８時００分００秒であった、見積もり期間は２０１３年１０月３０日８時０１分００秒までであるため、Ｎｏと判定され、次の瞬間性能見積もり処理を２０１３年１０月３０日８時００分０５秒を対象時刻としてＳ２００２を実行する。

Ｓ２００４では、Ｓ２００３までの処理で算出したシステム性能の変化の推移が、閾値を超えていないかを判定する。閾値としてシステム性能は常に０．３[ＫＲｅｑｕｅｓｔ／ｓｅｃ]を維持することがＳＬＡとして定められている場合、構成変更が実行される瞬間のシステム性能の最悪値が０．１[ＫＲｅｑｕｅｓｔ／ｓｅｃ]であることから、閾値を超えてしまうと判断する。

Ｓ２００５では、算出した瞬間性能の最悪値が閾値を下回る回数を、違反回数としてカウントし、違反回数と瞬間性能見積もりを実施する間隔である５秒を乗算して、システム性能がＳＬＡ違反している時間を算出する。

なお本実施例は、仮にサーバ障害が起こってサーバがダウンしシステムが縮退した場合を想定したシステム性能の見積もりについても適用可能である。その場合は、Ｓ２００１で障害発生を想定するホストと障害発生想定時刻を受け付けて、上記と同様の処理を行えば良い。

以上の処理により、テナントの構成について、構成変更を想定した場合の性能評価を行うことができる。ＳＬＯなどの閾値を超える場合は、どの程度の時間超過するのかもあわせて把握することができ、現状の構成で障害が起きた場合のテナントの可用性や、実施予定のテナントの構成変更の妥当性を評価することができる。また、システムの動的な状況に応じた構成変更の自動実行について運用ポリシーが設定されている場合は、その構成変更の負荷も考慮して性能を見積もることにより、当該運用ポリシーについても、妥当性を評価することができる。

図２３は、本実施例における応答時間算出処理部２２２による処理の一例を示すフローチャートである。応答時間変更処理は、これら以外の不図示のステップを含んでいてもいいし、幾つかが存在しなくても良い。

まずＳ２３０１にて、性能見積もり処理において算出した性能値に基づき、見積もり対象期間の各対象時刻における、処理要求に対する応答時間を算出する。具体的には、例えば、瞬間性能見積もり処理で算出した単位時間当たりのリクエスト処理数である性能値の逆数によって、リクエストあたりの期待応答時間を算出しても良いし、不図示の性能見積もり処理で算出した性能値と応答時間の対応表を保持して算出しても良い。ここで性能値は、算出した性能劣化度合いを考慮した最悪値を用いても良いし、期待性能と最悪値の平均の値を算出して瞬間性能値として用いても良い。

Ｓ２３０２は、例えば不図示のリクエストのタイムアウト時間の設定を保存している場合に、処理リクエストに対するシステム応答時間がタイムアウト時間を超えるか否かを判定する処理である。システム応答時間がリクエストのタイムアウト時間を超える場合は（Ｙｅｓ）Ｓ２３０３に進み、システム応答時間がリクエストのタイムアウト時間を超えない場合（Ｎｏ）Ｓ２３０４に進む。

Ｓ２３０３は、例えばリクエストがタイムアウト期間を過ぎても処理されない場合は、同一の処理要求についての再リクエストが自動的に送信されるというポリシー設定がされているシステムにおいて、システム応答時間がリクエストのタイムアウト時間を超えた場合に行う処理である。一度タイムアウト時間を超えてしまうと、再リクエストが繰り返されることにより、システムへの負荷が増大し続け、システムの処理能力を超えて、状況を改善しない限り応答時間が悪化し続けることが考えられる。そのため、システム応答時間がタイムアウト時間を超えた以降の時刻における応答時間を、Ｓ２３０１で算出した値から、不定値または、算出されたシステム応答時間の最大値に置き換えることにより、システム応答時間がタイムアウト時間以下に回復しない予測を示す出力を行う。これにより、図１９（Ｃ）のようにシステム構成変更が応答時間に重大な影響を与えることをシステムの利用者に示すことができる。Ｓ２３０３実行後は、算出したシステム応答時間を出力し、応答時間算出処理を終了する。

Ｓ２３０４は、例えば不図示のＳＬＯ情報としてシステムが発揮すべき応答時間の目標値を保持している場合に、ＳＬＯによって定められた応答時間の目標値と、算出したシステム応答時間を比較し、システム応答時間が目標値を超える（目標を達成できない値である）か否かを判定する処理である。システム応答時間が目標値を超えている場合（Ｙｅｓ）Ｓ２３０５に進み、システム応答時間が目標値を超えていない場合（Ｎｏ）算出した応答時間を出力して応答時間算出処理を終了する。

Ｓ２３０５では、システム応答時間が目標値を超えている場合に、システム応答時間が目標値を超えている時間を超過時間として算出する。超過時間は、例えば、算出した応答時間と閾値とをグラフに描画し、応答時間と閾値の交点から求めるなどの手法により算出する。Ｓ２３０５の実行後は、算出したシステム応答時間と超過時間を出力し、応答時間算出処理を終了する。

応答時間算出処理により算出された結果は、例えば、メモリに格納する、ファイルに保存する、ＧＵＩに表示するなどの形式で出力されればよい。

図２４は、本実施例におけるシステムの単一障害点の有無を検出するＳＰＯＦ検出処理を示すフローチャートである。ＳＰＯＦ検出処理は、これら以外の不図示のステップを含んでいてもいいし、幾つかが存在しなくても良い。

ＳＰＯＦ検出処理は、テナントシステムまたはＩＴシステム全体における性能面でのＳＰＯＦを検出する処理である。例えば、図３に例示するシステム構成において実現される図７に例示されるようなテナントシステム構成において、テナント構成情報８００の種別８０３がＷｅｂサーバであるＶｉｒｔｕａｌ＿Ｍａｃｈｉｎｅ＿０が縮退し、テナントシステムを構成するホストの種別８０３がＷｅｂサーバであるホストが２台になった構成で性能見積もり処理を実施した時に、不図示のＳＬＯ情報に定められる応答時間や単位時間あたりに処理できるリクエスト量である性能の目標値を違反するか否かを判定するなどの処理を、各コンポーネントについて実施し、性能面でのＳＰＯＦが存在するか否かを判定するものである。

Ｓ２４０１では、負荷トレンド情報２３４の負荷１７０２のうち、例えば、直近一ヶ月間での最大の値を求め、システム負荷を算出する。

Ｓ２４０２では、例えば、ＳＰＯＦ検出処理をテナントシステムに対して実行する場合はテナント構成情報８００に記載されているホストを昇順に選択するなどして、縮退すると仮定するテナントシステムのホストを選択する。

Ｓ２４０３では、Ｓ２４０１で算出した値とＳ２４０２で選択したホストを縮退させる操作の負荷の足し合わせた結果をシステム負荷とする。また、Ｓ２４０２で選択したホストを縮退させる操作を実行される構成変更として、Ｓ２４０２で選択したホストを縮退させるシステムにおける縮退前の構成を構成変更前として、Ｓ２４０２で選択したホストを縮退させるシステムにおける縮退後の構成を構成変更後として扱い、性能見積もり処理フローを実行する。この処理により、Ｓ２４０２で選択したホストが縮退した時刻において、システムの期待性能から、システム負荷による性能劣化度合いと未完了処理の再アクセスによる性能劣化の度合いを引いて算出したシステムの最悪性能値が、閾値を超えている場合、Ｓ２４０２で選択したホストはシステム性能面での単一障害点として、出力する。

Ｓ２４０４では、システムの単一障害点の有無を検出するシステムの全てのホストにおいて、Ｓ２４０３の処理を実行したか否かを判定する。全てのホストにおいてＳ２４０３の処理を実行完了した場合は、Ｓ２４０３で算出した単一障害点箇所をファイルまたはＧＵＩ等に出力して、ＳＰＯＦ検出処理を終了する。全てのホストにおいてＳ２４０３の処理を実行していない場合は、Ｓ２４０２の処理を再度実行する。

実施例１における負荷−性能対応情報２３３を用いた瞬間性能見積もり処理は、計算機システムの構成変更が起こる時点で構成変更箇所にかかっている負荷の量を、未完了状態の処理量と近似した。実施例２では、処理のキュー等を考慮することで、構成変更時に未完了である処理量の近似の精度を上げる。

図１４、図１５、図１６は、負荷−性能対応情報２３３の変形例である。実施例２における負荷−性能対応情報２３３を用いた場合は、計算機システムで処理されるユーザからのリクエストがキューイングされるような場合を考慮して、急な縮退に伴う未完了状態の処理量をより精度良く算出することができる。

図１４は、テナントシステムに負荷がかかっているときの各ホストにおけるキューの使用量の対応関係を示す、負荷−キュー使用量対応情報１４００である。負荷−キュー使用量対応情報１４００は、負荷１４０１とキュー使用量１４０２を含む。ここで負荷とは、実施例１と同様にシステムへのリクエスト数である。キュー使用量とは単位時間あたりに各サーバのキューに貯まる処理量のことであり、キューに貯まっているリクエスト数のことである。キュー使用量１４０２は、システムを構成する装置毎に保持すると良い。

図１５は、図７に示すテナントシステムにおいて、キューの使用量とその時点のシステムの性能劣化の度合いの対応をホスト毎に示す、キュー使用量−性能対応情報１５００である。キュー使用量と性能対応テーブル１５００は、各ホストのキュー使用量を示すキュー使用量１５０１と、当該装置がネックになっているときのシステムの性能劣化の度合いを示す性能劣化の度合い１５０２を含む。性能劣化度合い１５０２は、システムを構成する装置毎に保持すると良い。ここで、キュー使用量は負荷とキュー対応テーブル１４００のキュー使用量１４０２と同様に各装置のキューに貯まっているリクエスト数である。性能劣化度合いとは、システム性能劣化度合い情報１２００の性能劣化度合い１２０２と同様に負荷がかかっているときのシステム性能の変動の幅の値である。

図１６は、図７に示すテナントシステムにおいて、システム性能を発揮する時に各ホストで消化されるキューの使用量の対応関係を示す、性能とホストのキュー消化容量対応テーブル１６００である。性能とホストのキュー消化容量対応テーブル１６００は、システム性能を示す性能１６０１と、キュー消化容量１６０２を含む。キュー消化容量１６０２はシステムを構成する装置毎に保持すると良い。ここで、キュー消化容量とは、単位時間あたりに各装置で処理できるキューに貯まっているリクエスト数のことである。従って、負荷とキュー使用量対応テーブルの負荷１４０１がかかっているときのキュー使用量１４０２よりも、負荷１４０１がかかっているときのシステム性能１６０１に対応するキュー消化容量１６０２が少ない場合、各装置のキューに貯まっている処理の総量は増加していく。

図１４、図１５、図１６に例示する負荷−性能対応情報２３３は、例えば、計算機システムの運用中に監視して得られた実測値の統計処理によって算出した値を格納する等のように、計算機システムの管理者が手作業で入力してもよし、何らかのツールやユーティリティにより生成されても良い。例えば読み書き比率などの負荷の特徴により、負荷とキュー使用量の対応関係や、キュー使用量と性能の対応関係、性能とホストのキュー消化容量の対応関係が変動することが一般的に知られているため、負荷−性能対応情報２３３は、負荷の特徴ごとに保持していても良いし、負荷の特徴により負荷−性能対応情報２３３の値を調整する何らかのツールやユーティリティを保持していても良い。

実施例２における以上の負荷−性能対応情報２３３を用いた瞬間性能見積もり処理のＳ２１０３、Ｓ２１０４、Ｓ２１０５、Ｓ２１０６は、実施例１における瞬間性能見積もり処理と異なる処理をする。その他の処理は実施例１と同様で良い。

実施例２におけるＳ２１０３では、タスク情報２３２、負荷−性能対応情報２３３、負荷トレンド情報２３４を用いて、システムにかかっている負荷による性能劣化の範囲を算出する。具体的には、まず実施例１におけるＳ２１０３と同様の手法でシステム負荷の算出を行う。次に負荷−性能対応情報２３３の負荷１９０１と算出したシステム負荷を比較し、キュー使用量１４０２を取得する。負荷−性能対応情報２３３のキュー使用量１５０１と取得したキュー使用量を比較してシステムを構成する各ホストの性能劣化度合い１５０２を取得する。次に、取得した各ホストにおける性能劣化度合い１５０２の中で最も性能劣化度合いの大きい値を算出し、算出した性能劣化度合いをシステムの性能劣化度合いとして、最も性能劣化度合いの大きいホストをネック箇所として、例えばメモリに保存するか、またはファイルに保存する等の手法で出力する。

実施例２におけるＳ２１０４では、負荷−性能対応情報２３３を用いて、構成変更による縮退箇所で未完了状態の処理を算出する。Ｓ２１０３で算出したシステム負荷およびＳ２１０１で取得した操作対象のホスト種別に対応する、キュー使用量１４０２を取得する。取得したキュー使用量１４０２を構成変更箇所で未完了状態の処理量として扱い、例えばメモリに保存する、またはファイルに保存する等の手法で出力する。実施例２におけるＳ２１０４は実施例１におけるＳ２１０４と同様の条件下の場合に実行されれば良い。

実施例２におけるＳ２１０５では、負荷−性能対応情報２３３を用いて、縮退箇所で未完了状態であった処理の再リクエストによる性能劣化の度合いを算出する。このステップは、Ｓ２１０４が実行された場合に実行する。処理の具体例を説明する。まず、Ｓ２１０３で算出したシステム負荷とＳ２１０４で取得した未完了状態の処理とを足した負荷の量を算出し、算出した負荷に対応する各ホストのキュー使用量１４０２を取得する。取得した各ホストのキュー使用量とテーブル１５００から各ホストの性能劣化度合いを取得し、取得した各ホストの性能劣化度合いの中で最も大きな値を、未完了処理の再アクセスによる負荷がかかった場合のシステムの性能劣化度合いとして扱う。Ｓ２１０５で算出したシステムの性能劣化度合いと、Ｓ２１０３で算出した性能劣化度合いの差分を、未完了処理の再アクセスの影響による性能劣化度合いとして算出し、例えばメモリに保存する、またはファイルに保存する等の手法で出力する。

実施例２におけるＳ２１０６についても、実施例１の処理にＳ２１０３−Ｓ２１０５と同様の変更を加えて実行する。

以上の通り、実施例において提供する管理計算機によれば、構成変更に伴う一時的な負荷の増大を考慮することで、構成変更がシステム性能に与える影響について評価の精度を高めることが出来る。

なお、実施例におけるシステム構成情報２３１は、簡略化のため装置単位でのシステム構成しか示していないが、例えば、ストレージ装置内のストレージコントローラ、DISK、I/Oポートの数や性能などの情報を保存しても良い。ストレージ装置内のコンポーネントの構成変更などに対しても、実施例が提供する性能見積もり処理を適用することが可能である。

２０１：管理サーバ ２０３：サーバ装置 ２０４：ストレージ装置 ２２１：性能見積もり処理部 ２２２：応答時間算出処理部 ２２３：ＳＰＯＦ検出処理部

Claims (9)

1. 計算機システムに含まれるサーバが稼動停止した場合の前記計算機システムの性能を、稼働停止時の前記サーバに要求されていた処理量に基づいて推定し、
   前記推定した前記計算機システムの性能を出力する
   制御部を備える、情報処理装置。
2. 前記制御部は、
   前記稼働停止時の前記サーバに要求されていた処理量を、前記サーバによって処理されなかった要求の再送を、前記サーバの稼働停止後に前記計算機システムに含まれる他のサーバが受け付けることにより増加する前記計算機システムの負荷量として算出することにより、前記計算機システムの性能を推定する
   請求項１記載の情報処理装置。
3. 前記制御部は、
   システム構成及び負荷に応じた前記計算機システムの性能低下量を示す、負荷性能対応情報を参照可能であり、
   前記算出した計算機システムの負荷量及び前記サーバの稼働停止後の前記計算機システムの構成に対応する性能低下量を、前記負荷性能対応情報より取得して、前記計算機システムの性能を見積もる
   請求項２記載の情報処理装置。
4. 前記制御部は、さらに
   前記計算機システムの構成を示す構成情報と、
   前記計算機システムに対する処理要求による負荷を示す負荷情報と、を参照可能であり、
   前記稼働停止時における前記計算機システムに対する処理要求による負荷を算出し、
   前記構成情報より、前記稼働停止時の前記計算機システムの構成を取得し、
   前記処理要求による負荷及び前記計算機システムの構成に基づいて、前記サーバへの処理要求量を算出する
   請求項３記載の情報処理装置。
5. 前記制御部は、
   前記計算機システムの構成を示す構成情報と、
   構成に応じた前記計算機システムの期待性能を示す期待性能情報と、
   システム構成と負荷に応じた前記計算機システムの性能低下量を示す負荷性能対応情報と、を参照可能であり、
   前記サーバの稼働停止時刻及び、前記計算機システムの性能評価を行う評価対象期間の入力を受け付けると、
   前記評価対象期間の所定の単位時間ごとの評価対象時刻における構成に応じた前記計算機システムの期待性能を取得し、
   前記稼働停止時刻における、前記サーバに要求されていた処理量を算出し、
   算出した前記サーバに要求されていた処理量と前記負荷性能対応情報とに基づき、前記サーバの稼働停止による前記計算機システムの性能低下量を算出し、
   少なくとも、各評価対象時刻における、前記期待性能及び前記性能低下量を、前記計算機システムの性能見積もり情報として出力する
   請求項１記載の情報処理装置。
6. 前記制御部は、
   前記性能見積もり情報に基づき、各評価対象時刻の前記計算機システムへの処理要求に対する応答時間を算出し、
   前記評価対象期間における前記応答時間を出力する
   請求項５記載の情報処理装置。
7. 前記制御部は、
   前記評価対象期間において、前記応答時間が、予め定められた閾値を超えるか否か判定し、
   前記閾値を超える場合は、超過する時間を算出し、
   算出した前記超過する時間を、前記応答時間とあわせて出力する
   請求項６記載の情報処理装置。
8. 前記計算機システムには、処理要求についてのタイムアウト時間と、前記処理要求がタイムアウトした場合に同一の処理要求を再度送信される再リクエストポリシとが設定されており、
   前記制御部は、
   前記評価対象期間における応答時間について、前記タイムアウト時間を超えるか否か判定し、
   前記タイムアウト時間を超える場合は、再リクエストの影響で応答時間が増大する可能性があることを示す情報を出力する
   請求項７記載の情報処理装置。
9. 計算機システムに含まれるサーバが稼動停止した場合の前記計算機システムの性能を、稼働停止時の前記サーバに要求されていた処理量に基づいて推定し、
   前記推定した前記計算機システムの性能を出力する
   性能評価方法。

Images