JP6293683B2 - 計算機システム及び計算機システムの性能障害の対処方法 - Google Patents

Description

本発明は、クラウドサービスの管理に関する。

インターネットを介して、計算機リソース、及び計算機リソース上で動作するサービスを提供し、利用に応じて利用者に課金する、クラウドと呼ばれるサービスの提供形態が普及している。

当初、クラウドは、インターネット経由でアクセスするため安定した性能を提供することが難しいことから、例えば、バックアップのような要求される性能が比較的低い用途で利用されていた。しかし、近年、クラウド上でオンラインビジネスを稼動させるケースも多く、クラウドに対して性能の安定性が求められている。

これを実現する技術の一つに、クラウド上の仮想計算機の負荷状況に応じて、当該仮想計算機を自動的にスケーリングする機能が知られている。例えば、クラウドを用いて提供されるＷｅｂ三階層システムでは、フロントエンド側のＷｅｂサーバに対して前述した技術を適用される。Ｗｅｂサーバに対応する仮想計算機数を増減させることによって、Ｗｅｂ三階層システムの負荷バランスを維持している。

システム全体の性能を維持するためには、Ｗｅｂサーバに対するスケーリングに伴って、バックエンド側のＤＢサーバも増強させる必要がある。ＤＢサーバの性能障害に対する対応方法については、例えば、特許文献１等にＤＢサーバのボトルネックの原因を分析する技術が存在する。

特許文献１には、ＤＢサーバの性能を管理してボトルネックの分析を行うこと、分析結果に応じてサーバリソースのリサイズを行うこと等が記載されている。

米国特許第７５２６５０８号明細書

従来のＤＢサーバの障害対応技術では、管理計算機等が、ＤＢサーバの性能劣化を検知し、性能劣化の原因を分析することによって、ＣＰＵのリソース不足、又はＩ／Ｏレイテンシの不足等のボトルネック箇所を特定し、不足しているリソース量を算出する。

クラウド環境においては、サービスの契約内容に応じて、障害に対する対処時間を優先する対処法、又は、コストを優先する対処法等を選択する必要がある。

しかし、従来技術では、サービスの契約内容を考慮してどの対処法を優先的に実行するか、また、クラウドの構成を考慮して各対処法を実行できるか否かを判定することができないため、クラウドにおけるシステムの性能を保証するための適切なＤＢサーバの障害に対応できないという課題がある。そのため、クラウド環境におけるＤＢサーバのスケールアップ技術が求められている。

本願において開示される発明の代表的な一例を示せば以下の通りである。すなわち、複数の計算機を備える計算機システムであって、前記複数の計算機は、前記計算機システムを管理する少なくとも一つの第１の計算機、及びユーザの業務に使用する業務システムを構築するための計算機リソースを提供する複数の第２の計算機を含み、前記少なくとも一つの第１の計算機は、第１のプロセッサ、前記第１のプロセッサに接続される第１のメモリ、及び前記第１のプロセッサに接続される第１のインタフェースを有し、前記複数の第２の計算機の各々は、第２のプロセッサ、前記第２のプロセッサに接続される第２のメモリ、前記第２のプロセッサに接続される第２のインタフェース、及び記憶装置を有し、前記業務システムは、スケールアウト処理を実行することによって処理性能を変更できる少なくとも一つの第１の業務計算機、及びスケールアップ処理を実行することによって処理性能を変更できる複数の業務計算機を含み、前記少なくとも一つの第１の計算機は、前記計算機システム上に構築された複数の業務システムの各々のサービス要件を管理するサービス要件管理情報と、前記業務計算機の性能劣化が検知された場合、計算機リソースの種別毎の性能劣化を改善するための制御方法である対処法を管理する対処法管理情報と、を保持し、複数の対処法の集合であり、性能劣化が検知された前記業務計算機に対して前記対処法を実行できるか否かを判定する順番を含む対処手順管理情報を生成する対処手順生成部を有し、前記サービス要件は、前記業務システムに含まれる前記複数の業務計算機の各々の性能保証の条件、前記業務システムに含まれる前記複数の業務計算機の各々の運用の条件、及び、前記業務システムの課金体系の条件に関する情報を含み、前記対処法管理情報に含まれる複数の対処法の各々は、前記対処法に対応する処理におけるコスト情報と対応付けられて管理され、前記対処手順生成部は、前記対処手順管理情報を生成する対象の業務システムを選択し、前記対象の業務システムに含まれる前記複数の業務計算機の中から処理対象の業務計算機を選択し、前記処理対象の業務計算機における対象の計算機リソースを選択し、前記サービス要件管理情報に基づいて、前記対処法管理情報に含まれる前記複数の対処法の中から、前記対象の業務システムの前記サービス要件に合致する複数の対処法を選択し、前記選択された複数の対処法が実行可能か否かを判定する判定順番を決定することによって、前記対処手順管理情報を生成することを特徴とする。

本発明によれば、対処手順生成部は、業務計算機（ＤＢサーバ）の性能劣化に対応するための対処手順管理情報を、業務システム（テナント）のサービス要件に基づいて生成することができる。これによって、サービス要件を満たし、かつ、効率的な業務計算機の障害復旧を実現できる。

上記した以外の課題、構成及び効果は、以下の実施例の説明により明らかにされる。

実施例１のクラウドサービスを実現するシステムの構成例を示す説明図である。 実施例１のクラウドシステムの構成例を示す説明図である。 実施例１のクラウド管理計算機のハードウェア構成及びソフトウェア構成の一例を説明するブロック図である。 実施例１の基盤管理計算機のハードウェア構成及びソフトウェア構成の一例を説明するブロック図である。 実施例１のクラウドユーザがポリシを入力する場合にポータルを介して表示される入力画面の一例を示す説明図である。 実施例１のサービス要件管理情報の一例を示す説明図である。 実施例１のポリシ管理情報の一例を示す説明図である。 実施例１のＤＢ障害対処法管理情報の一例を示す説明図である。 実施例１のクラウド基盤構成情報の一例を示す説明図である。 実施例１の計算機リソース割当情報の一例を示す説明図である。 実施例１のサーバリソース使用状態情報の一例を示す説明図である。 実施例１のストレージリソース使用状態情報の一例を示す説明図である。 実施例１のストレージ構成情報の一例を示す説明図である。 実施例１の対処手順管理情報の一例を示す説明図である。 実施例１の対処手順管理情報の一例を示す説明図である。 実施例１のクラウド管理計算機が実行する処理の一例を説明するフローチャートである。 実施例１のクラウド管理計算機が実行する対処手順生成処理（Ａ）の一例を説明するフローチャートである。 実施例１のクラウド管理計算機が実行する対処手順生成処理（Ｂ）の一例を説明するフローチャートである。 実施例１の対処手順生成処理（Ｂ）を実行することによって生成された対処手順管理情報の一例を示す説明図である。 実施例１のクラウド管理計算機が対処手順管理情報にしたがって実行する処理の一例を説明するフローチャートである。 実施例１のクラウド管理計算機が対処手順管理情報にしたがって実行する処理の一例を説明するフローチャートである。 実施例１のクラウド管理計算機が対処手順管理情報にしたがって実行する処理の一例を説明するフローチャートである。 実施例１のクラウド管理計算機が対処手順管理情報にしたがって実行する処理の一例を説明するフローチャートである。 実施例１のクラウド管理計算機が対処手順管理情報にしたがって実行する処理の一例を説明するフローチャートである。 実施例１のクラウド管理計算機が対処手順管理情報にしたがって実行する処理の一例を説明するフローチャートである。 実施例２の対処手順管理情報の一例を示す説明図である。 実施例２のクラウド管理計算機が対処手順管理情報にしたがって実行する処理の一例を説明するフローチャートである。 実施例２のクラウド管理計算機が対処手順管理情報にしたがって実行する処理の一例を説明するフローチャートである。 実施例２のクラウド管理計算機が対処手順管理情報にしたがって実行する処理の一例を説明するフローチャートである。 実施例２のクラウド管理計算機が対処手順管理情報にしたがって実行する処理の一例を説明するフローチャートである。

以下に図面を参照しながら本発明の実施例を説明する。

図１は、実施例１のクラウドサービスを実現するシステムの構成例を示す説明図である。

実施例１では、クラウドシステム９０及びポータル３０からシステムが構成される。クラウドシステム９０及びポータル３０は、ネットワーク４０を介して接続される。なお、ネットワーク４０は、インターネット等が考えられるが、ネットワークの種別に限定されない。また、クラウドシステム９０及びポータル３０の接続方式は、無線又は有線のいずれであってもよい。

クラウドシステム９０は、クラウドユーザ１０の業務システムであるテナント５０が構築されるシステムである。図１では、クラウドユーザ１０が使用するテナント５０の一例として、ロードバランサ６０、Ｗｅｂサーバ７０、及びＤＢサーバ８０を含むＷｅｂ三階層システムを示す。なお、クラウドサービスでは、一般的に、ロードバランサ６０、Ｗｅｂサーバ７０、及びＤＢサーバ８０は、後述する仮想計算機６００を用いて実現される。

クラウドシステム９０には、各クラウドユーザ１０のテナント５０が共存するため、各テナント５０に対応した運用が求められる。例えば、各テナント５０のサービスレベルの異なる場合、サービスレベルに応じたテナント５０の運用が求められる。

ポータル３０は、クラウドユーザ１０に提供されるユーザインタフェースである。クラウドユーザ１０は、ポータル３０を介して、サービスの申し込み、サービス内容の確認、又は、テナント５０におけるリソースの監視等を行う。

実施例１では、クラウドユーザ１０が利用料金を支払って、ネットワーク４０を経由してクラウドシステム９０が提供する計算機リソースを利用するクラウドサービスを想定する。また、実施例１では、ＤＢサーバ８０の性能劣化の原因がＣＰＵリソースの不足である場合に実行される処理を説明する。

図２は、実施例１のクラウドシステム９０の構成例を示す説明図である。

クラウドシステム９０は、クラウド管理計算機１００、基盤管理計算機２００、ホスト計算機５００、ネットワーク接続装置４００、ストレージ装置３００、及び課金計算機８００から構成される。各装置は、管理用ネットワーク７００を介してクラウド管理計算機１００と接続する。

クラウド管理計算機１００は、クラウドユーザ１０に提供するクラウドサービスを管理する。クラウド管理計算機１００のハードウェア構成及びソフトウェア構成は、図３を用いて後述する。基盤管理計算機２００は、ホスト計算機５００、ネットワーク接続装置４００及びストレージ装置３００から構成されるクラウド基盤の計算機リソースを管理する。例えば、基盤管理計算機２００は、クラウドシステム９０の監視、計算機リソースの割当、及び障害処理等を行う。課金計算機８００は、クラウドユーザ１０の利用状況に応じて、利用料金を算出する。

クラウド管理者２０は、クラウド管理計算機１００又は基盤管理計算機２００を用いてクラウドシステム９０を管理する。

ホスト計算機５００は、テナント５０に割り当てる計算機リソースを提供する。なお、ホスト計算機５００は、図示しないＣＰＵ、メモリ、Ｉ／Ｏデバイス及び記憶媒体を備える。実施例１では、複数のホスト計算機５００を用いてクラスタ９００が構成される。

ホスト計算機５００は、仮想化機能を有する。仮想化機能は例えばハイパバイザ等を用いて実現できる。ホスト計算機５００は、仮想化機能を用いて一つ以上の仮想計算機６００を生成し、また、管理する。

仮想計算機６００では、ゲストＯＳ６２０が稼働する。また、ゲストＯＳ６２０上では、アプリケーションとしてＤＢ６１０が実行される。なお、本実施例は、ゲストＯＳ６２０上で実行されるアプリケーションの種別に限定されない。

仮想計算機６００は、仮想ＣＰＵ、仮想メモリ等を有する。ゲストＯＳ６２０又はＤＢ６１０がアクセスするデータは、仮想ディスク６３０に格納される。また、一つのホスト計算機５００には、ストレージ装置３００によって提供されるボリューム６４０が割り当てられる。ホスト計算機５００は、当該ボリューム６４０の一部の記憶領域を仮想ディスク６３０として各仮想計算機６００に割り当てる。

ボリューム６４０は、ホスト計算機５００が備えるＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）等の記憶媒体を用いて実現してもよいし、後述するストレージ装置３００の論理記憶領域３１０を用いて実現してもよい。

ネットワーク接続装置４００は、ホスト計算機５００及びストレージ装置３００を接続する。ホスト計算機５００及びストレージ装置３００を接続するネットワークは、例えば、ＳＡＮ又はＬＡＮ等が考えられるがこれらに限定されない。

ストレージ装置３００は、仮想計算機６００が使用する記憶領域を提供する。ストレージ装置３００は、図示しない、コントローラ、ディスクインタフェース、及び複数の記憶媒体を備える。

実施例１のストレージ装置３００は、シン・プロビジョニング機能を備え、複数の記憶媒体の各々の記憶領域を仮想的なストレージプール３２０として管理し、また、ストレージプール３２０の一部の記憶領域を用いて論理記憶領域３１０を生成する。また、ストレージ装置３００は、論理記憶領域３１０をボリューム６４０等を実現する記憶領域としてホスト計算機５００に提供する。

実施例１では、クラスタ９００単位でストレージ装置３００が提供する記憶領域を共有することによって、クラスタ９００内のホスト計算機５００間で仮想計算機６００の配置を最適化が可能となる。

実施例１では、クラウド管理計算機１００及び基盤管理計算機２００をそれぞれ別々の計算機として記載しているが、一つの計算機を用いてクラウド管理計算機１００及び基盤管理計算機２００を実現してもよい。

図３は、実施例１のクラウド管理計算機１００のハードウェア構成及びソフトウェア構成の一例を説明するブロック図である。

クラウド管理計算機１００は、ハードウェア構成として、演算処理装置１８０、プログラムメモリ１０００、データ入出力用キャッシュメモリ１６０、記憶媒体１７０、管理用通信インタフェース１１０、入力用インタフェース１２０、及び出力用インタフェース１２５を備える。クラウド管理計算機１００の各構成はバス１９０を介して互いに接続される。

演算処理装置１８０は、ＣＰＵ等の各種演算を行う装置である。演算処理装置１８０が、プログラムメモリ１０００に格納されるプログラムを実行することによって、クラウド管理計算機１００が備える機能を実現することができる。以下の説明では、プログラムを主体にして処理を説明する場合、演算処理装置１８０によって当該プログラムが実行されていることを示す。

プログラムメモリ１０００は、演算処理装置１８０が実行する各種プログラム及び各種プログラムが使用する情報を格納する。プログラムメモリ１０００は、磁気記憶装置又は揮発性半導体メモリ等が考えられるがこれに限定されない。プログラムメモリ１０００に格納される各種プログラム及び情報については後述する。

データ入出力用キャッシュメモリ１６０は、クラウド管理計算機１００に書き込まれるデータ又はクラウド管理計算機１００から読み出されるデータを一時的に格納する。

記憶媒体１７０は、オペレーティングシステム及びアプリケーション等の各種プログラム及び情報を格納する。プログラムメモリ１０００に格納される各種プログラム及び情報は、記憶媒体１７０に格納されてもよい。この場合、演算処理装置１８０が、記憶媒体１７０から各種プログラム及び情報を読み出し、プログラムメモリ１０００にロードする。

管理用通信インタフェース１１０は、管理用ネットワーク７００を介してクラウドシステム９０内の装置と接続し、管理情報を入出力するためのインタフェースである。入力用インタフェース１２０は、クラウド管理者２０が情報を入力するためのインタフェースである。出力用インタフェース１２５は、クラウド管理者２０に情報を出力するためのインタフェースである。

入力用インタフェース１２０は、例えば、キーボード及びマウス等が考えられる。また、出力用インタフェース１２５は、例えば、汎用ディスプレイ等が考えられる。

ここで、プログラムメモリ１０００に格納される各種プログラム及び情報について説明する。

プログラムメモリ１０００は、プログラムとして、サービス管理プログラム１０１０、ポリシ管理プログラム１０１１、対処法管理プログラム１０１２、ＤＢ対処手順生成プログラム１０１３、ＤＢ障害対策判定プログラム１０１４、課金管理プログラム１０１５、及び構成管理プログラム２０１２を格納する。また、プログラムメモリ１０００は、情報として、サービス要件管理情報１００１、ポリシ管理情報１００２、ＤＢ障害対処法管理情報１００３、対処手順管理情報１００４、クラウド基盤構成情報２００１、計算機リソース割当情報２００２、サーバリソース使用状態情報２００３、及びストレージリソース使用状態情報２００４を格納する。

サービス管理プログラム１０１０は、各クラウドユーザ１０に提供されるサービス内容を管理するためのプログラムである。ポリシ管理プログラム１０１１は、対処法及び対処手順を選択する場合に使用されるポリシを管理するためのプログラムである。

対処法管理プログラム１０１２は、ＤＢサーバ８０の障害に対する各対処法、及び各対処法の特徴を管理するためのプログラムである。ＤＢ対処手順生成プログラム１０１３は、サービス要件、ポリシ、及び対処法の特徴に基づいて、対処手順を生成するためのプログラムである。ＤＢ対処手順生成プログラム１０１３によって生成された対処手順は、対処手順管理情報１００４として管理される。

ここで、対処法とは、ＤＢサーバ８０の性能障害の原因に応じて、当該性能障害を改善するために行われるＤＢサーバ８０の各種設定変更、及び構成変更等の制御方法を示す。また、対処手順とは、複数の対処法の集合であって、各対処法が適用できるか否かを判定する順番（判定順番）が決定されたものを示す。

ＤＢ障害対策判定プログラム１０１４は、テナント５０のリソース確保方法及び計算機リソースの空き状態等に基づいて、ＤＢ対処手順生成プログラム１０１３によって生成された対処手順に含まれる各対処法が実行可能か否か判定するためのプログラムである。課金管理プログラム１０１５は、クラウドシステム９０を用いてクラウドサービスを提供するクラウドプロバイダに対して、クラウドユーザ１０が支払う料金を管理するためのプログラムである。構成管理プログラム２０１２については、図４を用いて説明する。

なお、各種情報の詳細は、各種図面を用いて後述する。具体的には、サービス要件管理情報１００１については図６、ポリシ管理情報１００２については図７、ＤＢ障害対処法管理情報１００３については図８、対処手順管理情報１００４については図１４Ａ及び図１４Ｂ、クラウド基盤構成情報２００１については図９、計算機リソース割当情報２００２については図１０、サーバリソース使用状態情報２００３については図１１、ストレージリソース使用状態情報２００４については図１２を用いて後述する。

なお、課金計算機８００もクラウド管理計算機１００と同一のハードウェア構成であるものとする。課金計算機８００のプログラムメモリ１０００には、利用料金を算出する課金プログラム、及び利用料金を算出するための情報等が格納される。

図４は、実施例１の基盤管理計算機２００のハードウェア構成及びソフトウェア構成の一例を説明するブロック図である。基盤管理計算機２００はクラウドシステムの監視、リソース割当、障害対応を行うものである。

基盤管理計算機２００は、ハードウェア構成として、演算処理装置２８０、プログラムメモリ２０００、データ入出力用キャッシュメモリ２６０、記憶媒体２７０、管理用通信インタフェース２１０、入力用インタフェース２２０、及び出力用インタフェース２２５を備える。基盤管理計算機２００の各構成はバス２９０を介して互いに接続される。

なお、演算処理装置２８０、プログラムメモリ２０００、データ入出力用キャッシュメモリ２６０、記憶媒体２７０、管理用通信インタフェース２１０、入力用インタフェース２２０、及び出力用インタフェース２２５は、それぞれ、演算処理装置１８０、プログラムメモリ１０００、データ入出力用キャッシュメモリ１６０、記憶媒体１７０、管理用通信インタフェース１１０、入力用インタフェース１２０、及び出力用インタフェース１２５と同一のものであるため説明を省略する。

なお、以下の説明では、プログラムを主体にして処理を説明する場合、演算処理装置２８０によって当該プログラムが実行されていることを示す。

プログラムメモリ２０００は、プログラムとして、ＤＢ障害検知プログラム２０１０、ＤＢボトルネック分析プログラム２０１１、構成管理プログラム２０１２、ＤＢ障害復旧プログラム２０１３、及びリソース監視プログラム２０１４を格納する。また、プログラムメモリ２０００は、情報として、クラウド基盤構成情報２００１、計算機リソース割当情報２００２、サーバリソース使用状態情報２００３、ストレージリソース使用状態情報２００４、及びストレージ構成情報２００５を格納する。

ＤＢ障害検知プログラム２０１０は、ＤＢサーバ８０の障害を検知し、クラウド管理者２０及びクラウド管理計算機１００に障害の発生を通知するためのプログラムである。ＤＢボトルネック分析プログラム２０１１は、障害が発生したＤＢサーバ８０のボトルネックを分析するためのプログラムである。ＤＢボトルネック分析プログラム２０１１は、例えば、ＣＰＵリソースの不足、又はＩ／Ｏレイテンシ不足等の性能劣化の原因（ボトルネック）を特定し、特定された原因をクラウド管理者２０及びクラウド管理計算機１００に通知する。

構成管理プログラム２０１２は、クラウドシステム９０の構成に変更があった場合に、クラウドシステム９０に関する情報を取得し、取得された情報を管理するためのプログラムである。ＤＢ障害復旧プログラム２０１３は、対処法に基づいて計算機リソースの追加等の構成変更処理を実行するためのプログラムである。リソース監視プログラム２０１４は、クラウドシステム９０における基盤の性能、及び各計算機リソースのリソース量等の稼働情報を取得するためのプログラムである。

クラウド基盤構成情報２００１、計算機リソース割当情報２００２、サーバリソース使用状態情報２００３、及びストレージリソース使用状態情報２００４は、クラウド管理計算機１００が保持する情報と同一のものである。ストレージ構成情報２００５の詳細については、図１３を用いて後述する。

図５は、実施例１のクラウドユーザ１０がポリシを入力する場合にポータル３０を介して表示される入力画面の一例を示す説明図である。

図５に示す入力画面は、性能保証オプションを適用しているクラウドユーザ１０に対して提供される。クラウドユーザ１０は、当該入力画面を用いて、ＤＢ障害に対する対処手順の生成ポリシを設定する。具体的には、クラウドユーザ１０は、対象の仮想計算機６００を選択し、対象の仮想計算機６００の性能障害に対するポリシを指定する。なお、対象の仮想計算機６００は、ＤＢサーバ８０を実現する仮想計算機６００であるものとする。

クラウドユーザ１０は、対象の仮想計算機６００として、テナント５０内の全仮想計算機６００を選択してもよいし、また、個々の仮想計算機６００を選択してもよい。また、クラウドユーザ１０は、対象の仮想計算機６００に対して、「物理サーバの移行なし」、「無停止」、「処理時間重視」等のポリシを指定できる。

なお、当該入力画面を用いたポリシの入力が行われない場合、予めクラウド管理計算機１００に設定されたデフォルトのポリシに基づいて、対処手順が生成される。

図６は、実施例１のサービス要件管理情報１００１の一例を示す説明図である。

サービス要件管理情報１００１は、テナント５０のサービス契約内容、及びＤＢサーバ８０を実現する仮想計算機６００上で稼働する業務情報等を含む各テナント５０のサービス要件を管理するための情報である。サービス要件管理情報１００１は、テナント識別子１００１１、仮想計算機識別子１００１２、及びサービス要件１００１３を含む。

テナント識別子１００１１は、テナント５０の識別情報を格納する。仮想計算機識別子１００１２は、テナント５０に含まれる仮想計算機６００のうち、ＤＢサーバ８０に対応する仮想計算機６００の識別情報を格納する。

サービス要件１００１３は、テナント５０の管理情報及びクラウドサービスの利用開始時に契約されたサービス要件を格納するカラムである。サービス要件１００１３は、さらに、性能保証オプション１００１４、割当保証項目１００１５、無停止運用１００１６、課金１００１７を含む。

性能保証オプション１００１４は、仮想計算機６００に対して設定された性能保証に関するオプション情報を格納するカラムであり、適用状態１００１４１及び対象１００１４２を含む。

適用状態１００１４１が「あり」の場合、性能保証オプションが申し込まれていることを示し、適用状態１００１４１が「なし」の場合、性能保証オプションが申し込まれていないことを示す。対象１００１４２は、性能を保証する対象を示す。対象１００１４２が「ＶＭ」の場合、テナント５０における性能の劣化が発生時に、仮想計算機６００に対して後述する対処手順が適用される。

割当保証項目１００１５は、計算機リソースの割当てにおいて保証が必要な計算機リソースに関する情報を格納するカラムであり、リソース割当１００１５１及びハードウェア指定１００１５２を含む。

リソース割当１００１５１は、保証が必要な計算機リソースを示すリソース割当１００１５１、及び保証すべき計算機リソースの設定値である保証値１００１５４を含む。対象１００１５３が「ＣＰＵ」かつ保証値１００１５４が「上限値：４ＧＨｚ」の場合、割り当てられるＣＰＵの周波数の上限値が４ＧＨｚであることを示す。対象１００１５３が「ＣＰＵ」かつ保証値１００１５４が「割当値：１ＧＨｚ」の場合、必ず、ＣＰＵの周波数として１ＧＨｚ割り当てられることを示す。なお、特に計算機リソースの割当ての保証が設定されていない仮想計算機６００については、対象１００１５３に「なし」、保証値１００１５４には「Ｎｕｌｌ」が格納される。

ハードウェア指定１００１５２は、サーバ占有のように、ハードウェア単位で性能保証が指定されているか否かを示す情報を格納する。なお、特にハードウェア単位の性能保証の指定がされていない場合、ハードウェア指定１００１５２には「なし」が格納される。

無停止運用１００１６は、仮想計算機６００について無停止運用の必要があるか否かを示す情報を格納する。無停止運用１００１６が「要」の場合、無停止運用が必要であることを示し、無停止運用１００１６が「不要」の場合、無停止運用が必要でないことを示す。

課金１００１７は、テナント５０の利用料金に関する情報を格納するカラムであり、体系１００１７１及び当月支払予定額１００１７２を含む。課金１００１７に設定される値は、クラウド管理計算機１００が課金計算機８００と連携することによって取得される。

体系１００１７１は、利用料金の体系に関する情報を格納する。例えば、体系１００１７１が「定額」の場合、テナント５０を利用するクラウドユーザ１０は定額の利用料金を支払う契約をしていることを示す。また、体系１００１７１が「従量課金」の場合、テナント５０を利用するクラウドユーザ１０は、計算機リソースの割当量に応じて利用料金を支払う契約をしていることを示す。

なお、本実施例では、利用料金の体系が「定額」の場合、全ての対処法が対象となり、利用料金の体系が「従量課金」の場合、原則、追加料金が発生しない対処法のみが対象となるものとする。すなわち、「定額」は利用料金が「従量課金」より高いが、追加料金が発生することなく、テナント５０の性能保証に対応できる。一方、「従量課金」は利用料金が低いが、テナント５０の性能保証には追加料金が発生する。

当月支払予定額１００１７２は、クラウドユーザ１０がクラウドサービスを提供するクラウドプロバイダに支払う利用料金を格納する。

図７は、実施例１のポリシ管理情報１００２の一例を示す説明図である。

ポリシ管理情報１００２は、後述する対処手順を生成する際に使用されるポリシを管理するための情報である。ポリシ管理情報１００２は、テナント識別子１００２１、仮想計算機識別子１００２２、及びポリシ１００２３を含む。

テナント識別子１００２１及び仮想計算機識別子１００２２は、テナント識別子１００１１及び仮想計算機識別子１００１２と同一のものである。

ポリシ１００２３は、クラウドユーザ１０によって各仮想計算機６００に対して設定されたポリシを格納する。クラウドユーザ１０は、図５に示すような入力画面を用いてポリシを設定する。なお、仮想計算機６００に対して特にポリシが設定されていない場合、ポリシ１００２３には「Ｎｕｌｌ」が格納される。

図８は、実施例１のＤＢ障害対処法管理情報１００３の一例を示す説明図である。

ＤＢ障害対処法管理情報１００３は、ＤＢサーバ８０の障害発生時の対処法及び各対処法の特徴を管理するための情報である。ＤＢ障害対処法管理情報１００３は、ボトルネック箇所１００３１、対処法１００３２、及び特徴１００３３を含む。

ボトルネック箇所１００３１は、ボトルネックとして特定された計算機リソースの種別を格納する。対処法１００３２は、性能劣化を解消するための具体的な対処法を格納する。実施例１では、ＤＢ障害対処法管理情報１００３において、ボトルネックの種別、すなわち、計算機リソースの種別毎に複数の対処法が管理される。

特徴１００３３は、対処法の特徴に関する情報を格納するカラムであり、無停止１００３４、影響１００３５、平均処理時間１００３６、物理サーバ移行１００３７、及び追加料金１００３８を含む。

無停止１００３４は、対処法に対応する処理が実行された場合に仮想計算機６００を再起動することなくサービスを継続できるか否かを示す情報を格納する。実施例１では、無停止１００３４が「該当」の場合、仮想計算機６００を再起動することなくサービスを継続できることを示し、無停止１００３４が「非該当」の場合、仮想計算機６００を再起動する必要があり、サービスが中断することを示す。

影響１００３５は、対処法に対応する処理が実行された場合、ホスト計算機５００又は仮想計算機６００に与える影響の大きさを示す情報を格納する。平均処理時間１００３６は、対処法に対応する処理が完了するまでの平均処理時間を格納する。

なお、影響１００３５及び平均処理時間１００３６には、各対処法の相対的な重みを格納してもよい。この場合、クラウド管理計算機１００は、性能の劣化が検知された仮想計算機６００が特定された場合、重み及びデータ量等から値を算出する。

物理サーバ移行１００３７は、対処法に対応する処理を実行する場合に、仮想計算機６００を、現在稼働しているホスト計算機５００から他のホスト計算機５００に移行させる必要があるか否かを示す情報を格納する。物理サーバ移行１００３７が「あり」の場合、ホスト計算機５００間で仮想計算機６００を移行させる必要があることを示し、物理サーバ移行１００３７が「なし」の場合、ホスト計算機５００間で仮想計算機６００を移行させる必要がないことを示す。

追加料金１００３８は、課金体系毎に、対処法に対応する処理が実行された場合に追加料金が発生するか否かを示す情報を格納する。具体的には、追加料金１００３８は、定額１００３８１及び従量課金１００３８２を含む。定額１００３８１は、課金体系が定額の場合に追加料金が発生するか否かを示す情報を格納し、従量課金１００３８２は、課金体系が従量課金の場合に追加料金が発生するか否かを示す情報を格納する。

なお、定額１００３８１及び従量課金１００３８２には、料金そのものが格納されてもよい。

特徴１００３３に含まれるカラムのうち、無停止１００３４、影響１００３５、平均処理時間１００３６、及び物理サーバ移行１００３７は、対処法に対応する処理に関する処理コストを表し、追加料金１００３８はテナント５０の利用コストを表す。

なお、クラウド管理計算機１００は、使用率のトレンドと突き合わせて、対処法が実行された後に、再度、性能劣化が発生する時期を算出し、当該時期を特徴１００３３として管理してもよい。これによって、例えば、対処法の実行頻度を減らしたい場合、クラウド管理計算機１００は、性能劣化の発生時期が遅い対処法を優先的に選択できる。

図９は、実施例１のクラウド基盤構成情報２００１の一例を示す説明図である。

クラウド基盤構成情報２００１は、ホスト計算機５００上で稼働する仮想計算機６００に割り当てられるＣＰＵ、メモリ等の情報、及び仮想計算機６００が利用可能な記憶領域に関する情報を管理するための情報である。具体的には、クラウド基盤構成情報２００１は、仮想計算機識別子２００１１、物理計算機識別子２００１２、サーバリソース２００１３、及びストレージ２００１４を含む。

仮想計算機識別子２００１１は、仮想計算機識別子１００１２と同一のものである。物理計算機識別子２００１２は、仮想計算機６００が稼働するホスト計算機５００の識別情報を格納する。

サーバリソース２００１３は、仮想計算機６００の計算機リソースと、ホスト計算機５００が有する計算機リソースとの対応関係に関する情報を格納するカラムである。サーバリソース２００１３は、ＣＰＵ２００１３１及びメモリ２００１３２を含む。

ＣＰＵ２００１３１は、さらに、仮想及び物理の二つのカラムを含む。ＣＰＵ２００１３１の仮想のカラムは、仮想計算機６００が有する仮想ＣＰＵの識別情報を格納し、ＣＰＵ２００１３１の物理のカラムは、仮想ＣＰＵにＣＰＵリソースを割り当てる物理ＣＰＵの識別情報を格納する。なお、一つの仮想ＣＰＵに二つ以上の物理ＣＰＵが割り当てられてもよいし、複数の仮想ＣＰＵが一つの物理ＣＰＵを共有するように割り当てられてもよい。

メモリ２００１３２は、さらに、仮想及び物理の二つのカラムを含む。メモリ２００１３２の仮想のカラムは、仮想計算機６００が有する仮想メモリの識別情報を格納し、メモリ２００１３２の物理のカラムは、仮想メモリにリソースを割り当てる物理メモリの識別情報を格納する。

ストレージ２００１４は、ストレージ装置３００によって提供され、かつ、ホスト計算機５００が利用可能な記憶領域に関する情報を格納するカラムであり、仮想ディスク識別子２００１４１及びボリューム識別子２００１４２を含む。

仮想ディスク識別子２００１４１は、仮想ディスク６３０の識別情報を格納する。ボリューム識別子２００１４２は、仮想ディスク６３０に記憶領域を提供するボリューム６４０の識別情報を格納する。

図１０は、実施例１の計算機リソース割当情報２００２の一例を示す説明図である。

計算機リソース割当情報２００２は、ホスト計算機５００上で稼働する仮想計算機６００に割り当てられる計算機リソースの確保形態、及び使用量に関する情報、並びに、複数の仮想計算機６００を用いたＨＡ構成を管理するための情報である。具体的には、計算機リソース割当情報２００２は、物理計算機識別子２００２１、仮想計算機識別子２００２２、割当２００２３、及びＨＡ構成状態２００２４を含む。

物理計算機識別子２００２１は、物理計算機識別子２００１２と同一のものである。また、仮想計算機識別子２００２２は、仮想計算機識別子１００１２と同一のものである。なお、仮想計算機識別子２００２２には、物理計算機識別子２００２１に対応するホスト計算機５００上で稼働する仮想計算機６００の識別情報が格納される。

割当２００２３は、仮想計算機６００に割り当てられる計算機リソースに関する情報を格納するカラムであり、計算機リソース種別２００２３１、確保形態２００２３２、及び実使用量２００２３３を含む。

計算機リソース種別２００２３１は、計算機リソースの種別に関する情報を格納する。確保形態２００２３２は、サービスの契約内容又はサービスの運用によって決定される確保形態に関する情報を格納する。実使用量２００２３３は、実際に使用されている計算機リソース量を格納する。

ＨＡ構成状態２００２４は、ＨＡが構成されているか否かを示す情報を格納する。ＨＡ構成状態２００２４が「あり」の場合、ＨＡが構成されていることを示し、ＨＡ構成状態２００２４が「なし」の場合、ＨＡが構成されていないことを示す。

図１１は、実施例１のサーバリソース使用状態情報２００３の一例を示す説明図である。

サーバリソース使用状態情報２００３は、ホスト計算機５００におけるＣＰＵ、メモリ等の計算機リソースの使用状態及び空き容量を管理するための情報である。具体的には、サーバリソース使用状態情報２００３は、クラスタ識別子２００３１、物理計算機識別子２００３２、及びサーバリソース使用状態２００３３を含む。

クラスタ識別子２００３１は、クラスタ９００の識別情報を格納する。物理計算機識別子２００３２は、物理計算機識別子２００１２と同一のものであり、クラスタ９００に含まれるホスト計算機５００の識別情報を格納する。

サーバリソース使用状態２００３３は、ホスト計算機５００が備える計算機リソースに関する情報を格納するカラムであり、計算機リソース２００３３１、使用量２００３３２、及び空き容量２００３３３を含む。

計算機リソース２００３３１は、ホスト計算機５００が備える計算機リソースの識別情報を格納する。使用量２００３３２は、実際に使用されている計算機リソース量の値を格納する。空き容量２００３３３は、使用されていない計算機リソース量の値を格納する。

なお、使用量２００３３２及び空き容量２００３３３には、リソース監視プログラム２０１４によって取得された値が格納される。

図１２は、実施例１のストレージリソース使用状態情報２００４の一例を示す説明図である。

ストレージリソース使用状態情報２００４は、論理記憶領域３１０及びストレージプール３２０の容量及びＩＯＰＳ等を管理するための情報である。具体的には、ストレージリソース使用状態情報２００４は、ボリューム識別子２００４１、論理記憶領域２００４２、及びストレージプール２００４３を含む。

ボリューム識別子２００４１は、ボリューム識別子２００１４２と同一のものである。

論理記憶領域２００４２は、ボリューム６４０に対応付けられる論理記憶領域３１０に関する情報を格納するカラムであり、論理記憶領域識別子２００４２１、容量２００４２２、及びＩＯＰＳ２００４２３を含む。

論理記憶領域識別子２００４２１は、論理記憶領域識別子２００１３３と同一のものであり、ボリューム６４０に対応付けられる論理記憶領域３１０の識別情報を格納する。

容量２００４２２は、論理記憶領域３１０の記憶容量に関する情報を格納するカラムであり、使用率２００４２２１及び空き容量２００４２２２を含む。使用率２００４２２１は、論理記憶領域３１０の記憶容量の使用率を示す値を格納する。空き容量２００４２２２は、論理記憶領域３１０の記憶容量の空き容量を示す値を格納する。

ＩＯＰＳ２００４２３は、論理記憶領域３１０のＩＯＰＳを示す値を格納する。

ストレージプール２００４３は、論理記憶領域３１０が属するストレージプール３２０に関する情報を格納するカラムであり、プール識別子２００４３１、容量２００４３２、及びＩＯＰＳ２００４３３を含む。

プール識別子２００４３１は、プール識別子２００１３４と同一のものであり、論理記憶領域識別子２００４２１に対応する論理記憶領域３１０が属するストレージプール３２０の識別情報を格納する。

容量２００４３２は、ストレージプール３２０の記憶容量に関する情報を格納するカラムであり、使用率２００４３２１及び空き容量２００４３２２を含む。使用率２００４３２１は、ストレージプール３２０の記憶容量の使用率を示す値を格納する。空き容量２００４３２２は、ストレージプール３２０の記憶容量の空き容量を示す値を格納する。

ＩＯＰＳ２００４３３は、ストレージプール３２０のＩＯＰＳを示す値を格納する。

なお、容量２００４２２、ＩＯＰＳ２００４２３、容量２００４３２及びＩＯＰＳ２００４３３には、リソース監視プログラム２０１４によって取得された値が格納される。

図１３は、実施例１のストレージ構成情報２００５の一例を示す説明図である。

ストレージ構成情報２００５は、ストレージプール３２０の構成を管理するための情報である。具体的には、ストレージ構成情報２００５は、プール識別子２００５１、容量２００５２、ＲＡＩＤグループ２００５３、記憶媒体２００５４、及びスペアディスク２００５５を含む。

プール識別子２００５１は、プール識別子２００１３４と同一のものであり、ストレージプール３２０の識別情報を格納する。容量２００５２は、ストレージプール３２０の全記憶容量を示す値を格納する。

ＲＡＩＤグループ２００５３は、ストレージプール３２０を構成するＲＡＩＤグループに関する情報を格納するカラムであり、ＲＡＩＤグループ識別子２００５３１、容量２００５３２、及び限界ＩＯＰＳ２００５３３を含む。

ＲＡＩＤグループ識別子２００５３１は、ＲＡＩＤグループの識別情報を格納する。容量２００５３２は、ＲＡＩＤグループの全記憶容量を示す値を格納する。限界ＩＯＰＳ２００５３３は、ＲＡＩＤグループが処理できるＩ／Ｏ、すなわち、ＩＯＰＳの最大値を格納する。

記憶媒体２００５４は、ＲＡＩＤグループを構成する記憶媒体の識別情報を格納する。スペアディスク２００５５は、ストレージプール３２０に追加可能な記憶媒体の識別情報を格納する。なお、スペアディスク２００５５にはＲＡＩＤグループの識別情報が格納されてもよい。

図１４Ａ及び図１４Ｂは、実施例１の対処手順管理情報１００４の一例を示す説明図である。

対処手順管理情報１００４は、仮想計算機６００に適用する対処手順を管理するための情報である。具体的には、対処手順管理情報１００４は、メタデータ１００４１及び対処手順１００４２から構成される。

メタデータ１００４１は、対処手順管理情報１００４の属性を示す情報を格納する。実施例１では、メタデータ１００４１には、対象の仮想計算機６００の識別情報、及び計算機リソースの種別情報を含む。対処手順１００４２は、具体的な対処手順が格納される。

図１４Ａ及び図１４Ｂは、課金形態が「定額」及び計算機リソースの種別が「ＣＰＵ」であり、仮想計算機６００の識別情報が「ＶＭ０５」である仮想計算機６００に適用される対処手順を示す。なお、「ＶＭ０５」に対応する仮想計算機６００は、サービス要件管理情報１００１のハードウェア指定１００１５２が「サーバ指定」であり、ポリシ管理情報１００２が「Ｎｕｌｌ」であるものとする。

図１４Ａの対処手順管理情報１００４の場合、対処手順１００４２に設定された判定順番にしたがって、仮想計算機６００に各対処法が実行できるか否かが判定される。一方、図１４Ｂの対処手順管理情報１００４の場合、仮想計算機６００にはいずれの対処法も実行されない。

なお、対処手順管理情報１００４には、メタデータ１００４１が含まれなくてもよい。例えば、ＤＢサーバ８０の性能劣化を契機に対処手順管理情報１００４が生成される場合、適用する対処手順管理情報１００４を特定するための情報が必要ない。

図１５は、実施例１のクラウド管理計算機１００が実行する処理の一例を説明するフローチャートである。

以下で説明する処理は、クラウド管理計算機１００のＤＢ対処手順生成プログラム１０１３が、ＤＢ障害検知プログラム２０１０からＤＢサーバ８０の障害を検知した旨の通知を受信した場合に開始してもよいし、また、周期的に実行してもよい。

ここでは、周期的に実行するものとする。この場合、クラウド管理計算機１００は、当該仮想計算機６００に対してボトルネックの種別毎にステップＳ１０３からステップＳ１０９までの処理を繰り返し実行する。なお、ＤＢ障害検知プログラム２０１０がＤＢサーバ８０の障害を検知した旨の通知の受信を契機に処理を開始する場合、クラウド管理計算機１００は、ＤＢボトルネック分析プログラム２０１１からボトルネックに関する情報を受信する。

サービス管理プログラム１０１０は、サービス要件管理情報１００１を参照する（ステップＳ１０１）。なお、サービス要件管理情報１００１は定期的に更新されているため、最新の状態となっている。

ＤＢ対処手順生成プログラム１０１３は、テナント５０のループ処理を開始する（ステップＳ１０２）。実施例１では、クラウドシステム９０に存在する全てのテナント５０についてステップＳ１０３からステップＳ１１４までの処理を繰り返し実行する。なお、障害が発生したＤＢサーバ８０を含むテナント５０のみを対象としてもよい。ここでは、サービス要件管理情報１００１のエントリ順にテナント５０が選択されるものとする。

ＤＢ対処手順生成プログラム１０１３は、サービス要件管理情報１００１を参照して、対象のテナント５０に含まれる仮想計算機６００の中に、性能保証オプションが設定される仮想計算機６００が存在するか否かを判定する（ステップＳ１０３）。具体的には、以下のような処理が実行される。

ＤＢ対処手順生成プログラム１０１３は、テナント識別子１００１１が対象のテナント５０の識別情報と一致するエントリを検索する。ＤＢ対処手順生成プログラム１０１３は、検索されたエントリの適用状態１００１４１を参照して、「あり」が格納される仮想計算機６００が存在するか否かを判定する。

以下の説明では、性能保証オプションが設定される仮想計算機６００を対象の仮想計算機６００とも記載する。

対象のテナント５０に含まれる仮想計算機６００の中に、対象の仮想計算機６００が存在しない場合（ステップＳ１０３がＮｏ）、ＤＢ対処手順生成プログラム１０１３は、対処手順管理情報１００４の生成が不要であると判定し、ステップＳ１１４に進む。

対象のテナント５０に含まれる仮想計算機６００の中に、対象の仮想計算機６００が存在する場合（ステップＳ１０３がＹｅｓ）、ＤＢ対処手順生成プログラム１０１３は、対象の仮想計算機６００のループ処理を開始する（ステップＳ１０４）。具体的には、ＤＢ対処手順生成プログラム１０１３は、対象の仮想計算機６００の中から一つの対象の仮想計算機６００を選択する。選択された仮想計算機６００に対してステップＳ１０５からステップＳ１１３までの処理が繰り返し実行される。

ＤＢ対処手順生成プログラム１０１３は、選択された対象の仮想計算機６００について計算機リソースのループ処理を開始する（ステップＳ１０５）。具体的には、ＤＢ対処手順生成プログラム１０１３は、サービス要件管理情報１００１の選択された仮想計算機６００の行を参照し、対象１００１５３に設定される計算機リソースの中から一つの計算機リソースを選択する。選択された計算機リソースに対してステップＳ１０６からステップＳ１１２までの処理が繰り返し実行される。

ＤＢ対処手順生成プログラム１０１３は、選択された対象の仮想計算機６００の課金体系が従量課金であるか否かを判定する（ステップＳ１０６）。

具体的には、ＤＢ対処手順生成プログラム１０１３は、ステップＳ１０４において選択された仮想計算機６００の行の体系１００１７１が「従量課金」であるか否かを判定する。

対象の仮想計算機６００の課金体系が従量課金であると判定された場合（ステップＳ１０６がＹｅｓ）、ＤＢ対処手順生成プログラム１０１３は、対象のテナント５０を利用するクラウドユーザ１０に対して追加料金の発生を了承するか否かの問合せを行う（ステップＳ１０７）。ＤＢ対処手順生成プログラム１０１３は、クラウドユーザ１０からの応答を受信するまで、次の処理を待ち続ける。

当該問合せは、ポータル３０を介してクラウドユーザ１０に通知される。クラウドユーザ１０は、ポータル３０を介して、当該通知に対する応答をクラウド管理計算機１００に送信する。

ＤＢ対処手順生成プログラム１０１３は、クラウドユーザ１０からの応答に基づいて、追加料金の発生が了承されたか否かを判定する（ステップＳ１０８）。

追加料金の発生が了承された場合（ステップＳ１０８がＹｅｓ）、ＤＢ対処手順生成プログラム１０１３は、ステップＳ１０８に進む。

追加料金の発生が了承されていない場合（ステップＳ１０８がＮｏ）、ＤＢ対処手順生成プログラム１０１３は、対処手順生成処理（Ａ）を実行し（ステップＳ１０９）、生成された対処手順管理情報１００４を出力する（ステップＳ１１１）。対処手順生成処理（Ａ）の詳細は、図１６を用いて後述する。

対象の仮想計算機６００の課金体系が従量課金でないと判定された場合（ステップＳ１０６がＮｏ）、又は、追加料金の発生が了承された場合（ステップＳ１０８がＹｅｓ）、ＤＢ対処手順生成プログラム１０１３は、対処手順生成処理（Ｂ）を実行し（ステップＳ１１０）、生成された対処手順管理情報１００４を出力する（ステップＳ１１１）。対処手順生成処理（Ｂ）の詳細は、図１７を用いて後述する。

対象のテナント５０に含まれる仮想計算機６００の中に、対象の仮想計算機６００が存在しない場合（ステップＳ１０３がＮｏ）、又はステップＳ１１１の処理の後、ＤＢ対処手順生成プログラム１０１３は、選択された対象の仮想計算機６００の全ての計算機リソースについて処理が完了したか否かを判定する（ステップＳ１１２）。

選択された対象の仮想計算機６００の全ての計算機リソースについて処理が完了していないと判定された場合（ステップＳ１１２がＮｏ）、ＤＢ対処手順生成プログラム１０１３は、次の計算機リソースを選択し、同様の処理（ステップＳ１０６からステップＳ１１２）を実行する。

選択された対象の仮想計算機６００の全ての計算機リソースについて処理が完了したと判定された場合（ステップＳ１１２がＹｅｓ）、ＤＢ対処手順生成プログラム１０１３は、全ての対象の仮想計算機６００について処理が完了したか否かを判定する（ステップＳ１１３）。

全ての対象の仮想計算機６００について処理が完了していないと判定された場合（ステップＳ１１３がＮｏ）、ＤＢ対処手順生成プログラム１０１３は、次の対象の仮想計算機６００を選択し、同様の処理（ステップＳ１０５からステップＳ１１３）を実行する。

全ての対象の仮想計算機６００について処理が完了したと判定された場合（ステップＳ１１３がＹｅｓ）、ＤＢ対処手順生成プログラム１０１３は、全てのテナント５０について処理が完了したか否かを判定する（ステップＳ１１４）。

全てのテナント５０について処理が完了していないと判定された場合（ステップＳ１１４がＮｏ）、ＤＢ対処手順生成プログラム１０１３は、次にテナント５０を選択し、同様の処理（ステップＳ１０３からステップＳ１１４）を実行する。

全てのテナント５０について処理が完了したと判定された場合（ステップＳ１１４がＹｅｓ）、ＤＢ対処手順生成プログラム１０１３は、基盤管理計算機２００に生成された対処手順管理情報１００４を通知し（ステップＳ１１５）、処理を終了する。

なお、ＤＢ対処手順生成プログラム１０１３は、対処手順管理情報１００４を基盤管理計算機２００に通知しなくてもよい。例えば、クラウド管理計算機１００は、ＤＢサーバ８０の障害発生時に、メタデータ１００４１に基づいて複数の対処手順管理情報１００４の中から一つの対処手順管理情報１００４を選択し、選択された対処手順管理情報１００４を基盤管理計算機２００に通知する。

なお、ＤＢサーバ８０の障害を検知した旨の通知を受信した場合に処理を開始する場合、テナント５０、仮想計算機６００及び計算機リソースのループ処理は省略できる。これは、対処手順管理情報１００４を生成する対象が特定されているためである。

図１６は、実施例１のクラウド管理計算機１００が実行する対処手順生成処理（Ａ）の一例を説明するフローチャートである。

ＤＢ対処手順生成プログラム１０１３は、サービス要件管理情報１００１及び計算機リソース割当情報２００２から、対象の仮想計算機６００に関連する値を取得する（ステップＳ２０１）。具体的には、以下のような処理が実行される。

ＤＢ対処手順生成プログラム１０１３は、少なくとも対象の仮想計算機６００の識別情報、及びボトルネックの種別に基づいてサービス要件管理情報１００１及び計算機リソース割当情報２００２を参照する。

ＤＢ対処手順生成プログラム１０１３は、サービス要件管理情報１００１の仮想計算機識別子１００１２が対象の仮想計算機６００の識別情報と一致し、かつ、対象１００１５３がボトルネックの種別と一致する行を検索する。ＤＢ対処手順生成プログラム１０１３は、検索されたエントリの保証値１００１５４に格納される値を取得する。

ＤＢ対処手順生成プログラム１０１３は、計算機リソース割当情報２００２の仮想計算機識別子２００２２が対象の仮想計算機６００の識別情報と一致し、かつ、計算機リソース種別２００２３１がボトルネックの種別と一致する行を検索する。ＤＢ対処手順生成プログラム１０１３は、検索された行の確保形態２００２３２及び実使用量２００２３３の値を取得する。以上がステップＳ２０１の処理の説明である。

次に、ＤＢ対処手順生成プログラム１０１３は、サービス要件管理情報１００１及び計算機リソース割当情報２００２から取得された値に基づいて、対象の仮想計算機６００に保証値分の計算機リソースが割り当てられているか否かを判定する（ステップＳ２０２）。

例えば、仮想計算機識別子１００１２が「ＶＭ０１」、対象１００１５３が「ＣＰＵ」の場合、保証値１００１５４は「上限値：４ＧＢ」である。一方、仮想計算機識別子２００２２が「ＶＭ０１」、計算機リソース種別２００２３１が「ＣＰＵ」の場合、確保形態２００２３２は「１ＧＨｚ−４ＧＨｚ」、実使用量２００２３３は「４ＧＨｚ」である。したがって、この場合、ＤＢ対処手順生成プログラム１０１３は、対象の仮想計算機６００に保証値分の計算機リソースが割り当てられていると判定する。

対象の仮想計算機６００に保証値分の計算機リソースが割り当てられていると判定された場合（ステップＳ２０２がＹｅｓ）、ＤＢ対処手順生成プログラム１０１３は、対処手順の生成が不要であると判定し、処理を終了する。これは、対象の仮想計算機６００の性能を向上させるためには、保証値以上の計算機リソースを確保する必要があり、追加料金が発生する。そのため、追加料金を発生させない対処法が存在しないためである。

対象の仮想計算機６００に保証値分の計算機リソースが割り当てられていないと判定された場合（ステップＳ２０２がＮｏ）、ＤＢ対処手順生成プログラム１０１３は、ＤＢ障害対処法管理情報１００３から、追加料金が発生しない対処法を選択する（ステップＳ２０３）。具体的には、以下のような処理が実行される。

ＤＢ対処手順生成プログラム１０１３は、ボトルネック箇所１００３１がボトルネックの種別と一致するエントリを検索し、検索されたエントリの追加料金１００３８のカラムを参照する。

対象の仮想計算機６００の体系１００１７１が「定額」の場合、ＤＢ対処手順生成プログラム１０１３は、定額１００３８１に「なし」が設定されている対処法を選択する。また、対象の仮想計算機６００の体系１００１７１が「従量課金」の場合、ＤＢ対処手順生成プログラム１０１３は、従量課金１００３８２に「なし」が設定されている対処法を選択する。以上がステップＳ２０３の処理の説明である。

次に、ＤＢ対処手順生成プログラム１０１３は、選択された対処法の中から、対象の仮想計算機６００に対する性能保証及び運用の内容に合致する対処法を抽出する（ステップＳ２０４）。

例えば、ＤＢ対処手順生成プログラム１０１３は、サービス要件管理情報１００１の仮想計算機識別子１００１２が対象の仮想計算機６００に一致する行を検索する。検索された行の無停止運用１００１６が「要」の場合、ＤＢ対処手順生成プログラム１０１３は、ＤＢサーバ８０に対応する仮想計算機６００の再起動が必要ない対処法を抽出する。なお、前述した処理は一例であって、ハードウェアの占有等の情報に基づいて対処法が抽出されてもよい。

ステップＳ２０３及びステップＳ２０４は、サービス要件に合致する対処法を選択するための処理である。対処手順生成処理（Ａ）では、追加料金が発生しないことが条件となっているため、ステップＳ２０３の判定処理が実行される。

次に、ＤＢ対処手順生成プログラム１０１３は、ポリシ管理情報１００２を参照して、対象の仮想計算機６００にポリシが設定されているか否かを判定する（ステップＳ２０５）。

具体的には、ＤＢ対処手順生成プログラム１０１３は、仮想計算機識別子１００２２が対象の仮想計算機６００の識別情報と一致する行を検索する。該当する行が存在しない場合、ＤＢ対処手順生成プログラム１０１３は、対象の仮想計算機６００にポリシが設定されていないと判定する。また、該当する行が存在し、かつ、当該行のポリシ１００２３が「Ｎｕｌｌ」の場合にも、ＤＢ対処手順生成プログラム１０１３は、対象の仮想計算機６００にポリシが設定されていないと判定する。

対象の仮想計算機６００にポリシが設定されていると判定された場合（ステップＳ２０５がＹｅｓ）、ＤＢ対処手順生成プログラム１０１３は、設定されたポリシにしたがって、抽出された対処法を並び替えることによって、対処手順管理情報１００４を生成する（ステップＳ２０６）。その後、ＤＢ対処手順生成プログラム１０１３は、処理を終了する。

例えば、ポリシ１００２３が「処理時間優先」の場合、ＤＢ対処手順生成プログラム１０１３は、平均処理時間１００３６が小さい順に抽出された対処法を並び替える。これによって、対処手順管理情報１００４の対処手順１００４２が生成される。ＤＢ対処手順生成プログラム１０１３は、さらに、ステップＳ１０４及びステップＳ１０５において選択された仮想計算機６００及び計算機リソースの識別情報からメタデータ１００４１を生成する。

対象の仮想計算機６００にポリシが設定されていないと判定された場合（ステップＳ２０５がＮｏ）、ＤＢ対処手順生成プログラム１０１３は、平均処理時間及びホスト計算機５００に対する負荷等に基づいて、抽出された対処法を並び替える（ステップＳ２０７）。その後、ＤＢ対処手順生成プログラム１０１３は、ステップＳ２０７に進む。例えば、以下のような処理が実行される。

ＤＢ対処手順生成プログラム１０１３は、まず、平均処理時間１００３６が小さい順に抽出された対処法を並び替える。平均処理時間１００３６が同一の対処法が存在する場合、ＤＢ対処手順生成プログラム１０１３は、影響１００３５を参照して、ホスト計算機５００に負荷が小さい順に平均処理時間１００３６が同一の対処法を並び替える。

ＤＢ対処手順生成プログラム１０１３は、抽出された対処法を並び替えた後、並び替えられた対処法の最後に融通処理を追加することによって対処手順管理情報１００４を生成する（ステップＳ２０８）。その後、ＤＢ対処手順生成プログラム１０１３は、処理を終了する。対処手順管理情報１００４の生成方法はステップＳ２０６の処理と同一であるため説明を省略する。

なお、ステップＳ２０８の処理は省略してもよい。この場合、ステップＳ２０７において、対処手順管理情報１００４が生成される。

ここで、融通処理とは、対象の仮想計算機６００が稼働するホスト計算機５００上で稼働する他の仮想計算機６００に割り当てられている計算機リソースを流用する処理である。なお、ホスト計算機５００上で稼働する他の仮想計算機６００は、全ての仮想計算機６００が対象となるわけではなく、性能保証オプション１００１４の適用状態１００１４１が「なし」であるものが対象となる。

図１６の処理によって、図１４Ａに示すような対処手順管理情報１００４が生成される。ＤＢ対処手順生成プログラム１０１３は、ステップＳ２０４において、ホスト計算機５００間の移行がない対処法が抽出され、ステップＳ２０５において、平均処理時間が短い順に並び替えることによって、図１４Ａに示すような対処手順管理情報１００４を生成する。

図１７は、実施例１のクラウド管理計算機１００が実行する対処手順生成処理（Ｂ）の一例を説明するフローチャートである。

ＤＢ対処手順生成プログラム１０１３は、ＤＢ障害対処法管理情報１００３から、対象の仮想計算機６００に対する性能保証及び運用の内容に合致する対処法を選択する（ステップＳ３０１）。例えば、以下のような処理が実行される。

ＤＢ対処手順生成プログラム１０１３は、サービス要件管理情報１００１の仮想計算機識別子１００１２が対象の仮想計算機６００に一致する行を検索する。検索された行の無停止運用１００１６が「要」の場合、ＤＢ対処手順生成プログラム１０１３は、ＤＢサーバ８０に対応する仮想計算機６００の再起動が必要ない対処法を選択する。なお、前述した処理は一例であって、ハードウェアの占有等の情報に基づいて契約内容に合致する対処法が選択されてもよい。

ステップＳ３０１は、サービス要件に合致する対処法を選択するための処理である。対処手順生成処理（Ｂ）では、追加料金が発生しないことが条件となっていないため、ステップＳ２０３のような判定処理は実行されない。

次に、ＤＢ対処手順生成プログラム１０１３は、ポリシ管理情報１００２を参照して、対象の仮想計算機６００にポリシが設定されているか否かを判定する（ステップＳ３０２）。ステップＳ３０２の処理は、ステップＳ２０５の処理と同一である。

対象の仮想計算機６００にポリシが設定されていると判定された場合（ステップＳ３０２がＹｅｓ）、ＤＢ対処手順生成プログラム１０１３は、ＤＢ対処手順生成プログラム１０１３は、設定されたポリシにしたがって、選択された対処法を並び替えることによって、対処手順管理情報１００４を生成する（ステップＳ３０３）。その後、ＤＢ対処手順生成プログラム１０１３は、処理を終了する。ステップＳ３０３の処理は、ステップＳ２０６の処理と同一である。

対象の仮想計算機６００にポリシが設定されていないと判定された場合（ステップＳ３０２がＮｏ）、ＤＢ対処手順生成プログラム１０１３は、平均処理時間及びホスト計算機５００に対する負荷等に基づいて、選択された対処法を並び替える（ステップＳ３０４）。ステップＳ３０４の処理は、ステップＳ２０７の処理と同一である。

ＤＢ対処手順生成プログラム１０１３は、選択された対処法を並び替えた後、並び替えられた対処法の最後に融通処理を追加することによって対処手順管理情報１００４を生成する（ステップＳ３０５）。その後、ＤＢ対処手順生成プログラム１０１３は、処理を終了する。ステップＳ３０５の処理は、ステップＳ２０８の処理と同一である。

図１８は、実施例１の対処手順生成処理（Ｂ）を実行することによって生成された対処手順管理情報１００４の一例を示す説明図である。

図１８は、課金体系が「従量」及び計算機リソースの種別が「ＣＰＵ」であり、仮想計算機６００の識別情報が「ＶＭ０２」である仮想計算機６００に適用される対処手順を示す。なお、「ＶＭ０２」に対応する仮想計算機６００は、サービス要件管理情報１００１の無停止運用１００１６が「要」であり、ポリシ管理情報１００２が「Ｎｕｌｌ」である。また、対処手順１００４２は、仮想計算機６００の再起動が発生しない対処法を平均処理時間が短い順に並べられた対処手順を示す。

以下、図１９から図２３を用いて、対処手順に従った処理について説明する。

図１９から図２３は、実施例１のクラウド管理計算機１００が対処手順管理情報１００４にしたがって実行する処理の一例を説明するフローチャートである。

クラウド管理計算機１００は、ＤＢボトルネック分析プログラム２０１１から、性能保証オプションが設定された仮想計算機６００のＣＰＵのリソース不足を検知した旨が通知された場合、仮想計算機６００の識別情報及び計算機リソースの種別に基づいてメタデータ１００４１を参照し、対処手順管理情報１００４を選択する。クラウド管理計算機１００は、選択された対処手順管理情報１００４にしたがって、図１９から図２３を用いて説明する対処法を実行する。

なお、ＤＢボトルネック分析プログラム２０１１は、仮想計算機６００の性能劣化を検知した場合、ボトルネックの種別を特定し、また、不足している計算機リソースのリソース量を算出する。ＤＢボトルネック分析プログラム２０１１は、仮想計算機６００の識別情報、ボトルネックの種別、及び不足しているリソース量を含む通知をクラウド管理計算機１００に送信する。

なお、以下の説明では、性能が劣化したＤＢサーバ８０に対応する仮想計算機６００をターゲット仮想計算機６００とも記載する。

まず、図１９に示す処理について説明する。図１９は、ボトルネック箇所１００３１が「ＣＰＵ」かつ対処法１００３２が「シェア値変更」である対処法に対応する処理を示す。

クラウド管理計算機１００のＤＢ障害対策判定プログラム１０１４が、対処手順管理情報１００４に基づいて、「シェア値の変更ができるか否かの判定」に対応する対処法が呼び出された場合に、以下で説明する処理を開始する。

ＤＢ障害対策判定プログラム１０１４は、基盤管理計算機２００から、ＤＢボトルネック分析プログラム２０１１によって算出された不足しているＣＰＵのリソース量を取得する（ステップＳ４０１）。なお、当該対処法を実行する前に、不足しているＣＰＵのリソース量が取得されている場合には、ステップＳ４０１の処理を省略することができる。

ＤＢ障害対策判定プログラム１０１４は、サービス要件管理情報１００１及び計算機リソース割当情報２００２を参照して、ターゲット仮想計算機６００のシェア値を変更できるか否かを判定する（ステップＳ４０２）。具体的には、以下のような処理が実行される。なお、シェア値は、ホスト計算機５００のハイパバイザ等が管理する複数の仮想計算機６００に対する計算機リソースの配分率を決定するための値である。

ＤＢ障害対策判定プログラム１０１４は、サービス要件管理情報１００１を参照して、仮想計算機識別子１００１２がターゲット仮想計算機６００の識別情報と一致し、かつ、対象１００１５３が「ＣＰＵ」である行を検索する。ＤＢ障害対策判定プログラム１０１４は、検索された行の保証値１００１５４に格納される値を取得する。

ＤＢ障害対策判定プログラム１０１４は、計算機リソース割当情報２００２を参照して、仮想計算機識別子２００２２がターゲット仮想計算機６００の識別情報と一致し、かつ、計算機リソース種別２００２３１が「ＣＰＵ１」である行を検索する。ＤＢ障害対策判定プログラム１０１４は、検索された行の確保形態２００２３２に格納される値を取得する。

ＤＢ障害対策判定プログラム１０１４は、保証値１００１５４及び確保形態２００２３２から取得された値に基づいて、ターゲット仮想計算機６００のシェア値を変更できるか否かを判定する。

例えば、確保形態２００２３２に、シェア値に基づくリソースの割り当てが設定されている場合、ＤＢ障害対策判定プログラム１０１４はターゲット仮想計算機６００のシェア値を変更できると判定する。また、ターゲット仮想計算機６００のシェア値を変更した時に、当該ターゲット仮想計算機６００と同一の計算機リソースを共有する他の仮想計算機６００に割り当てられる計算機リソースが保証値１００１５４より小さくならない場合、ＤＢ障害対策判定プログラム１０１４はターゲット仮想計算機６００のシェア値を変更できると判定する。以上がステップＳ４０２の処理の説明である。

ターゲット仮想計算機６００のシェア値を変更できないと判定された場合（ステップＳ４０２がＮｏ）、ＤＢ障害対策判定プログラム１０１４は、対処手順管理情報１００４を参照して、次の対処法が存在するか否かを判定する（ステップＳ４０３）。

次の対処法が存在すると判定された場合（ステップＳ４０３がＹｅｓ）、ＤＢ障害対策判定プログラム１０１４は、次の対処法に対応する処理を開始する。次の対処法が存在しないと判定された場合（ステップＳ４０３がＮｏ）、ＤＢ障害対策判定プログラム１０１４は、処理結果をクラウドユーザ１０に通知する（ステップＳ４１２）。その後、ＤＢ障害対策判定プログラム１０１４は、処理を終了する。例えば、適切な対処法が存在しない旨が通知される。なお、処理結果の通知方法は、例えば、ポータル３０を介して行うことが考えられる。

ステップＳ４０２において、ターゲット仮想計算機６００のシェア値を変更できると判定された場合（ステップＳ４０２がＹｅｓ）、ＤＢ障害対策判定プログラム１０１４は、計算機リソース割当情報２００２を参照して、ターゲット仮想計算機６００と同一のホスト計算機５００上で稼働する他の仮想計算機６００を検索する（ステップＳ４０４）。すなわち、ターゲット仮想計算機６００と計算機リソースを共有する他の仮想計算機６００が検索される。具体的には、以下のような処理が実行される。

ＤＢ障害対策判定プログラム１０１４は、計算機リソース割当情報２００２を参照して、仮想計算機識別子２００２２がターゲット仮想計算機６００の識別情報と一致する行を検索する。ＤＢ障害対策判定プログラム１０１４は、検索された行を含むエントリに基づいてターゲット仮想計算機６００が稼働するホスト計算機５００を特定する。

ＤＢ障害対策判定プログラム１０１４は、特定されたホスト計算機５００のエントリに基づいて、ターゲット仮想計算機６００と計算機リソースを共有する他の仮想計算機６００を特定する。以上がステップＳ４０４の処理の説明である。

ＤＢ障害対策判定プログラム１０１４は、検索された他の仮想計算機６００に余剰に割り当てられている計算機リソースを算出する（ステップＳ４０５）。具体的には、以下のような処理が実行される。

ＤＢ障害対策判定プログラム１０１４は、サービス要件管理情報１００１を参照して、他の仮想計算機６００に対応する行の対象１００１５３が「ＣＰＵ」である保証値１００１５４の値を取得する。また、ＤＢ障害対策判定プログラム１０１４は、計算機リソース割当情報２００２の他の仮想計算機６００に対応する計算機リソース種別２００２３１が「ＣＰＵ１」の実使用量２００２３３の値を取得する。

ＤＢ障害対策判定プログラム１０１４は、ターゲット仮想計算機６００と計算機リソースを共有する他の仮想計算機６００のうち、下式（１）を満たす他の仮想計算機６００を検索する。すなわち、余剰に計算機リソースが割り当てられている他の仮想計算機６００が検索される。

さらに、ＤＢ障害対策判定プログラム１０１４は、下式（２）に基づいて、検索された他の仮想計算機６００の余剰な計算機リソース量を算出する。

以上がステップＳ４０５の処理の説明である。

ＤＢ障害対策判定プログラム１０１４は、検索された他の仮想計算機６００に余剰に割り当てられた計算機リソースを用いて、不足している計算機リソースを確保できるか否かを判定する（ステップＳ４０６）。具体的には、ＤＢ障害対策判定プログラム１０１４は、式（２）に基づいて算出された値が不足しているＣＰＵのリソース量以上であるか否かを判定する。

不足している計算機リソースを確保できないと判定された場合（ステップＳ４０６がＮｏ）、ＤＢ障害対策判定プログラム１０１４は、ステップＳ４０３に進む。

不足している計算機リソースを確保できると判定された場合（ステップＳ４０６がＹｅｓ）、ＤＢ障害対策判定プログラム１０１４は、ターゲット仮想計算機６００のシェア値を変更する（ステップＳ４０７）。

例えば、ＤＢ障害対策判定プログラム１０１４が、基盤管理計算機２００のＤＢ障害復旧プログラム２０１３にターゲット仮想計算機６００及び他の仮想計算機６００のシェア値の変更を指示する。ＤＢ障害復旧プログラム２０１３は、当該指示にしたがって、ターゲット仮想計算機６００及び他の仮想計算機６００のシェア値を変更する。

ＤＢ障害対策判定プログラム１０１４は、ＤＢ障害対処法管理情報１００３に基づいて、シェア値の変更によって追加料金が発生するか否かを判定する（ステップＳ４０８）。具体的には、以下のような処理が実行される。

ＤＢ障害対策判定プログラム１０１４は、対処法が「シェア値変更」である対処法に関する課金発生の有無を課金管理プログラム１０１５に問い合わせる。なお、当該問合せには対処手順管理情報１００４のメタデータ１００４１が含まれる。

課金管理プログラム１０１５は、ＤＢ障害対処法管理情報１００３を参照して、ボトルネック箇所１００３１が「ＣＰＵ」かつ対処法１００３２が「シェア値変更」である行を検索する。課金管理プログラム１０１５は、メタデータ１００４１に基づいて、検索された行の追加料金１００３８から定額１００３８１又は従量課金１００３８２のいずれかの値を取得する。課金管理プログラム１０１５は、取得された値をＤＢ障害対策判定プログラム１０１４に応答する。

応答に含まれる値が「なし」の場合、ＤＢ障害対策判定プログラム１０１４はシェア値を変更しても追加料金が発生しないと判定する。一方、応答に含まれる値が「あり」の場合、ＤＢ障害対策判定プログラム１０１４は、シェア値を変更することによって追加料金が発生すると判定する。以上がステップＳ４０８の処理の説明である。

シェア値を変更しても追加料金が発生しないと判定された場合（ステップＳ４０８がＮｏ）、ＤＢ障害対策判定プログラム１０１４は、処理結果をクラウドユーザ１０に通知する（ステップＳ４１２）。その後、ＤＢ障害対策判定プログラム１０１４は、処理を終了する。例えば、シェア値を変更する対処法が実行された旨が通知される。

シェア値を変更することによって追加料金が発生すると判定された場合（ステップＳ４０８がＹｅｓ）、ＤＢ障害対策判定プログラム１０１４は、課金計算機８００に、追加料金の発生を通知する（ステップＳ４０９）。当該通知には、ターゲット仮想計算機６００の識別情報、変更されたシェア値等の対処法に関する情報が含まれる。ＤＢ障害対策判定プログラム１０１４は、課金計算機８００から応答があるまで待ち続ける。

なお、課金計算機８００は、クラウド管理計算機１００からの通知を受信した場合、当該通知に含まれる情報に基づいて追加料金を算出し、算出された追加料金をクラウド管理計算機１００に通知する。なお、追加料金を算出する方法は、公知のものであり、また、本実施例とは直接関係しないため説明を省略する。

ＤＢ障害対策判定プログラム１０１４は、課金計算機８００から追加料金の通知を受信した場合（ステップＳ４１０）、サービス要件管理情報１００１を更新する（ステップＳ４１１）。

具体的には、ＤＢ障害対策判定プログラム１０１４は、サービス要件管理情報１００１を参照し、仮想計算機識別子１００１２がターゲット仮想計算機６００の識別情報と一致する行を検索する。ＤＢ障害対策判定プログラム１０１４は、通知された追加料金に基づいて、検索された行の課金１００１７を更新する。

ＤＢ障害対策判定プログラム１０１４は、処理結果をクラウドユーザ１０に通知する（ステップＳ４１２）。その後、ＤＢ障害対策判定プログラム１０１４は、処理を終了する。例えば、シェア値を変更する対処法が実行された旨、及び追加料金が通知される。

次に、図２０に示す処理について説明する。図２０は、ボトルネック箇所１００３１が「ＣＰＵ」かつ対処法１００３２が「上限値変更」である対処法に対応する処理を示す。

ＤＢ障害対策判定プログラム１０１４は、基盤管理計算機２００から、ＤＢボトルネック分析プログラム２０１１によって算出された不足しているＣＰＵのリソース量を取得する（ステップＳ５０１）。

ＤＢ障害対策判定プログラム１０１４は、サービス要件管理情報１００１及び計算機リソース割当情報２００２を参照して、ターゲット仮想計算機６００の上限値を変更できるか否かを判定する（ステップＳ５０２）。

ステップＳ５０２の処理はステップＳ４０２の処理と同様の処理である。すなわち、ＤＢ障害対策判定プログラム１０１４は、保証値１００１５４及び確保形態２００２３２から取得された値に基づいて、ターゲット仮想計算機６００の上限値を変更できるか否かを判定する。

ターゲット仮想計算機６００の上限値を変更できないと判定された場合（ステップＳ５０２がＮｏ）、ＤＢ障害対策判定プログラム１０１４は、対処手順管理情報１００４を参照して、次の対処法が存在するか否かを判定する（ステップＳ５０３）。

次の対処法が存在すると判定された場合（ステップＳ５０３がＹｅｓ）、ＤＢ障害対策判定プログラム１０１４は、次の対処法に対応する処理を開始する。次の対処法が存在しないと判定された場合（ステップＳ５０３がＮｏ）、ＤＢ障害対策判定プログラム１０１４は、処理結果をクラウドユーザ１０に通知する（ステップＳ５１２）。その後、ＤＢ障害対策判定プログラム１０１４は、処理を終了する。ステップＳ５１２の処理はステップＳ４１２の処理と同一である。

ステップＳ５０２において、ターゲット仮想計算機６００の上限値を変更できると判定された場合（ステップＳ５０２がＹｅｓ）、ＤＢ障害対策判定プログラム１０１４は、計算機リソース割当情報２００２を参照して、ターゲット仮想計算機６００と同一のホスト計算機５００上で稼働する他の仮想計算機６００を検索する（ステップＳ５０４）。ステップＳ５０４の処理はステップＳ４０４の処理と同一である。

ＤＢ障害対策判定プログラム１０１４は、検索された他の仮想計算機６００に余剰に割り当てられている計算機リソースを算出する（ステップＳ５０５）。ステップＳ５０５の処理はステップＳ４０５の処理と同一である。

ＤＢ障害対策判定プログラム１０１４は、検索された他の仮想計算機６００に余剰に割り当てられた計算機リソースを用いて、不足している計算機リソースを確保できるか否かを判定する（ステップＳ５０６）。ステップＳ５０６の処理はステップＳ４０６の処理と同一である。

不足している計算機リソースを確保できないと判定された場合（ステップＳ５０６がＮｏ）、ＤＢ障害対策判定プログラム１０１４は、ステップＳ５０３に進む。

不足している計算機リソースを確保できると判定された場合（ステップＳ５０６がＹｅｓ）、ＤＢ障害対策判定プログラム１０１４は、ターゲット仮想計算機６００の上限値を変更する（ステップＳ５０７）。ステップＳ５０７の処理はステップＳ４０７の処理と同一である。

ＤＢ障害対策判定プログラム１０１４は、ＤＢ障害対処法管理情報１００３に基づいて、上限値の変更によって追加料金が発生するか否かを判定する（ステップＳ５０８）。ステップＳ５０８の処理はステップＳ４０８の処理と同一である。

上限値を変更しても追加料金が発生しないと判定された場合（ステップＳ５０８がＮｏ）、ＤＢ障害対策判定プログラム１０１４は、処理結果をクラウドユーザ１０に通知する（ステップＳ５１２）。その後、ＤＢ障害対策判定プログラム１０１４は、処理を終了する。

上限値を変更することによって追加料金が発生すると判定された場合（ステップＳ５０８がＹｅｓ）、ＤＢ障害対策判定プログラム１０１４は、課金計算機８００に、追加料金の発生を通知する（ステップＳ５０９）。ステップＳ５０９の処理はステップＳ４０９の処理と同一である。

ＤＢ障害対策判定プログラム１０１４は、課金計算機８００から追加料金の通知を受信した場合（ステップＳ５１０）、サービス要件管理情報１００１を更新する（ステップＳ５１１）。ＤＢ障害対策判定プログラム１０１４は、処理結果をクラウドユーザ１０に通知する（ステップＳ５１２）。ステップＳ５１０、ステップＳ５１１及びステップＳ５１２の処理は、ステップＳ４１０、ステップＳ４１１及びステップＳ４１２の処理と同一である。

次に、図２１Ａ及び図２１Ｂに示す処理について説明する。図２１Ａ及び図２１Ｂは、ボトルネック箇所１００３１が「ＣＰＵ」かつ対処法１００３２が「対象ＶＭとリソースを共有するＶＭを他のサーバへ移行」である対処法に対応する処理を示す。

ＤＢ障害対策判定プログラム１０１４は、基盤管理計算機２００から、ＤＢボトルネック分析プログラム２０１１によって算出された不足しているＣＰＵのリソース量を取得する（ステップＳ６０１）。

ＤＢ障害対策判定プログラム１０１４は、計算機リソース割当情報２００２を参照して、ターゲット仮想計算機６００と同一のホスト計算機５００上で稼働する他の仮想計算機６００を検索する（ステップＳ６０２）。ステップＳ６０２の処理はステップＳ４０４の処理と同一である。

ＤＢ障害対策判定プログラム１０１４は、検索された他の仮想計算機６００の中に、他の仮想計算機６００が現在稼働しているホスト計算機５００から他のホスト計算機５００に移行可能な他の仮想計算機６００が存在するか否かを判定する（ステップＳ６０３）。

具体的には、ＤＢ障害対策判定プログラム１０１４は、計算機リソースの不足が起因する性能劣化が発生しておらず、かつ、サービス要件管理情報１００１のハードウェア指定１００１５２が「なし」である仮想計算機６００が存在するか否かを判定する。前述した条件を満たす仮想計算機６００が存在する場合、現在稼働しているホスト計算機５００から他のホスト計算機５００に移行可能な他の仮想計算機６００が存在すると判定される。

現在稼働しているホスト計算機５００から他のホスト計算機５００に移行可能な他の仮想計算機６００が存在しないと判定された場合（ステップＳ６０３がＮｏ）、ＤＢ障害対策判定プログラム１０１４は、対処手順管理情報１００４を参照して、次の対処法が存在するか否かを判定する（ステップＳ６０４）。ステップＳ６０４の処理はステップＳ４０３の処理と同一である。

次の対処法が存在すると判定された場合（ステップＳ６０４がＹｅｓ）、ＤＢ障害対策判定プログラム１０１４は、次の対処法に対応する処理を開始する。次の対処法が存在しないと判定された場合（ステップＳ６０４がＮｏ）、ＤＢ障害対策判定プログラム１０１４は、処理結果をクラウドユーザ１０に通知する（ステップＳ６１３）。その後、ＤＢ障害対策判定プログラム１０１４は、処理を終了する。ステップＳ６１３の処理はステップＳ４１２の処理と同一である。

ステップＳ６０３において、現在稼働しているホスト計算機５００から他のホスト計算機５００に移行可能な他の仮想計算機６００が存在すると判定された場合（ステップＳ６０３がＹｅｓ）、ＤＢ障害対策判定プログラム１０１４は、移行可能な仮想計算機６００に割り当てられている計算機リソースを算出する（ステップＳ６０５）。

例えば、ＤＢ障害対策判定プログラム１０１４は、計算機リソース割当情報２００２を参照し、仮想計算機識別子２００２２が移行可能な仮想計算機６００の識別情報と一致する行を検索する。ＤＢ障害対策判定プログラム１０１４は、検索された行の確保形態２００２３２の値を、移行可能な仮想計算機６００に割り当てられている計算機リソースとして算出する。なお、実使用量２００２３３、保証値１００１５４等を用いて算出された値であってもよい。

ＤＢ障害対策判定プログラム１０１４は、算出された計算機リソースを用いて、不足している計算機リソースを確保できるか否かを判定する（ステップＳ６０６）。ステップＳ６０６の処理はステップＳ４０６の処理と同一である。

なお、移行可能な仮想計算機６００のうち、ステップＳ６０６の判定条件を満たす仮想計算機６００が複数存在する場合、ＤＢ障害対策判定プログラム１０１４は、算出された計算機リソースが最も小さい仮想計算機６００を移行させる仮想計算機６００として選択するものとする。

不足している計算機リソースを確保できないと判定された場合（ステップＳ６０６がＮｏ）、ＤＢ障害対策判定プログラム１０１４は、ステップＳ６０４に進む。

不足している計算機リソースを確保できると判定された場合（ステップＳ６０６がＹｅｓ）、ＤＢ障害対策判定プログラム１０１４は、移行可能な仮想計算機６００に必要な計算機リソースを確保できるホスト計算機５００が存在するか否かを判定する（ステップＳ６０７）。例えば、以下のような処理が実行される。

ＤＢ障害対策判定プログラム１０１４は、計算機リソース割当情報２００２を参照して、仮想計算機識別子２００２２がステップＳ６０７の判定条件を満たす仮想計算機６００の識別情報と一致する行を検索する。検索された行を含むエントリが移行させる仮想計算機６００が稼働するホスト計算機５００である。

ＤＢ障害対策判定プログラム１０１４は、サーバリソース使用状態情報２００３を参照して、物理計算機識別子２００３２が前述したホスト計算機５００の識別情報と一致する行を検索する。これによって、ＤＢ障害対策判定プログラム１０１４は、前述したホスト計算機５００を含むクラスタ９００を特定できる。

ＤＢ障害対策判定プログラム１０１４は、サービス要件管理情報１００１及びサーバリソース使用状態情報２００３等を参照して、特定されたホスト計算機５００の中から、占有的に使用されているホスト計算機５００を除外する。

さらに、ＤＢ障害対策判定プログラム１０１４は、サーバリソース使用状態情報２００３の空き容量２００３３３等を参照して、残りのホスト計算機５００の中から、移行させる仮想計算機６００に割り当てる計算機リソース分の空きリソースを有するホスト計算機５００を検索する。以上がステップＳ６０７の処理の一例である。

移行可能な仮想計算機６００に必要な計算機リソースを確保できるホスト計算機５００が存在しないと判定された場合（ステップＳ６０７がＮｏ）、ＤＢ障害対策判定プログラム１０１４は、ステップＳ６０４に進む。

移行可能な仮想計算機６００に必要な計算機リソースを確保できるホスト計算機５００が存在すると判定された場合（ステップＳ６０７がＹｅｓ）、ＤＢ障害対策判定プログラム１０１４は、移行先のホスト計算機５００を決定し（ステップＳ６０８）、決定されたホスト計算機５００へステップＳ６０６の判定条件を満たす仮想計算機６００を移行する（ステップＳ６０９）。

例えば、ＤＢ障害対策判定プログラム１０１４が、基盤管理計算機２００のＤＢ障害復旧プログラム２０１３に仮想計算機６００の移行を指示する。ＤＢ障害復旧プログラム２０１３は、当該指示にしたがって、ステップＳ６０６の判定条件を満たす仮想計算機６００を決定されたホスト計算機５００に移行する。なお、ホスト計算機５００間の仮想計算機６００の移行処理は公知のものであるため説明を省略する。

なお、ステップＳ６０８において、移行先の候補となるホスト計算機５００が複数存在する場合、空きリソース量が多いホスト計算機５００が優先的に選択されるものとする。

ステップＳ６１０、ステップＳ６１１、ステップＳ６１２、ステップＳ６１３及びステップＳ６１４の処理は、ステップＳ４０８、ステップＳ４０９、及びステップＳ４１０、ステップＳ４１１及びステップＳ４１２の処理と同一である。

次に、図２２に示す処理について説明する。図２２は、ボトルネック箇所１００３１が「ＣＰＵ」かつ対処法１００３２が「対象ＶＭを他のサーバへ移行」である対処法に対応する処理を示す。

ＤＢ障害対策判定プログラム１０１４は、基盤管理計算機２００から、ＤＢボトルネック分析プログラム２０１１によって算出された不足しているＣＰＵのリソース量を取得する（ステップＳ７０１）。

ＤＢ障害対策判定プログラム１０１４は、ターゲット仮想計算機６００に必要な計算機リソースを確保できるホスト計算機５００が存在するか否かを判定する（ステップＳ７０２）。ステップＳ７０２の処理はステップＳ６０７の処理と同様の処理である。ステップＳ７０２では、移行する仮想計算機６００がターゲット仮想計算機６００である点がステップＳ６０７の処理と異なる。

ターゲット仮想計算機６００に必要な計算機リソースを確保できるホスト計算機５００が存在しないと判定された場合（ステップＳ７０２がＮｏ）、ＤＢ障害対策判定プログラム１０１４は、対処手順管理情報１００４を参照して、次の対処法が存在するか否かを判定する（ステップＳ７０３）。ステップＳ７０３の処理はステップＳ４０３の処理と同一である。

次の対処法が存在すると判定された場合（ステップＳ７０３がＹｅｓ）、ＤＢ障害対策判定プログラム１０１４は、次の対処法に対応する処理を開始する。次の対処法が存在しないと判定された場合（ステップＳ７０３がＮｏ）、ＤＢ障害対策判定プログラム１０１４は、処理結果をクラウドユーザ１０に通知する（ステップＳ７１０）。その後、ＤＢ障害対策判定プログラム１０１４は、処理を終了する。ステップＳ７１０の処理はステップＳ４１２の処理と同一である。

ステップＳ７０２において、ターゲット仮想計算機６００に必要な計算機リソースを確保できるホスト計算機５００が存在すると判定された場合（ステップＳ７０２がＹｅｓ）、ＤＢ障害対策判定プログラム１０１４は、移行先のホスト計算機５００を決定し（ステップＳ７０４）、決定されたホスト計算機５００へターゲット仮想計算機６００を移行する（ステップＳ７０５）。ステップＳ７０４の処理はステップＳ６０８の処理と同一である。また、ステップＳ７０５の処理はステップＳ６０９の処理と同様の処理である。ステップＳ７０５では、移行する仮想計算機６００がターゲット仮想計算機６００である点がステップＳ６０９の処理と異なる。

ステップＳ７０６、ステップＳ７０７、ステップＳ７０８、ステップＳ７０９及びステップＳ７１０の処理は、ステップＳ４０８、ステップＳ４０９、ステップＳ４１０、ステップＳ４１１及びステップＳ４１２の処理と同一である。

次に、図２３に示す処理について説明する。図２３は、融通処理を示す。

ＤＢ障害対策判定プログラム１０１４は、基盤管理計算機２００から、ＤＢボトルネック分析プログラム２０１１によって算出された不足しているＣＰＵのリソース量を取得する（ステップＳ８０１）。

ＤＢ障害対策判定プログラム１０１４は、計算機リソース割当情報２００２を参照して、ターゲット仮想計算機６００と同一のホスト計算機５００上で稼働する他の仮想計算機６００を検索する（ステップＳ８０２）。すなわち、ターゲット仮想計算機６００と計算機リソースを共有する他の仮想計算機６００が検索される。ステップＳ８０２の処理はステップＳ４０４の処理と同一である。

ＤＢ障害対策判定プログラム１０１４は、サービス要件管理情報１００１に基づいて、ターゲット仮想計算機６００と計算機リソースを共有する仮想計算機６００の中に、性能保証オプションが設定されていない仮想計算機６００が存在するか否かを判定する（ステップＳ８０３）。

具体的には、ＤＢ障害対策判定プログラム１０１４は、ターゲット仮想計算機６００と計算機リソースを共有する仮想計算機６００の行の適用状態１００１４１を参照し、適用状態１００１４１が「なし」である仮想計算機６００が存在するか否かを判定する。

性能保証オプションが設定されていない仮想計算機６００が存在しないと判定された場合（ステップＳ８０３がＮｏ）、ＤＢ障害対策判定プログラム１０１４は、対処手順管理情報１００４を参照して、次の対処法が存在するか否かを判定する（ステップＳ８０４）。ステップＳ８０４の処理はステップＳ４０３の処理と同一である。

次の対処法が存在すると判定された場合（ステップＳ８０４がＹｅｓ）、ＤＢ障害対策判定プログラム１０１４は、次の対処法に対応する処理を開始する。次の対処法が存在しないと判定された場合（ステップＳ８０４がＮｏ）、ＤＢ障害対策判定プログラム１０１４は、処理結果をクラウドユーザ１０に通知する（ステップＳ８１１）。その後、ＤＢ障害対策判定プログラム１０１４は、処理を終了する。ステップＳ８１１の処理はステップＳ４１２の処理と同一である。

性能保証オプションが設定されていない仮想計算機６００が存在すると判定された場合（ステップＳ８０３がＹｅｓ）、ＤＢ障害対策判定プログラム１０１４は、性能保証オプションが設定されていない仮想計算機６００を用いて不足している計算機リソースを確保できるか否かを判定する（ステップＳ８０５）。

例えば、ＤＢ障害対策判定プログラム１０１４は、性能保証オプションが設定されていない仮想計算機６００に割り当てられているＣＰＵのリソース量が、不足しているＣＰＵのリソース量以上になるか否かを判定する。

性能保証オプションが設定されていない仮想計算機６００を用いて不足している計算機リソースを確保できないと判定された場合（ステップＳ８０５がＮｏ）、ＤＢ障害対策判定プログラム１０１４は、ステップＳ８０４に進む。

性能保証オプションが設定されていない仮想計算機６００を用いて、不足している計算機リソースを確保できると判定された場合（ステップＳ８０５がＹｅｓ）、ＤＢ障害対策判定プログラム１０１４は、当該仮想計算機６００の計算機リソースをターゲット仮想計算機６００の計算機リソースとして流用する（ステップＳ８０６）。

例えば、ＤＢ障害対策判定プログラム１０１４は、性能保証オプションが設定されていない仮想計算機６００の計算機リソースの流用を基盤管理計算機２００のＤＢ障害復旧プログラム２０１３に指示する。ＤＢ障害復旧プログラム２０１３は、当該指示にしたがって、性能保証オプションが設定されていない仮想計算機６００の計算機リソースをターゲット仮想計算機６００の計算機リソースとして流用する。

ＤＢ障害対策判定プログラム１０１４は、ＤＢ障害対処法管理情報１００３に基づいて、性能保証オプションが設定されていない仮想計算機６００の計算機リソースを流用することによって料金の変更が発生するか否かを判定する（ステップＳ８０７）。

ステップＳ８０７では、ターゲット仮想計算機６００に対する追加料金の発生の有無だけではなく、計算機リソースが流用された仮想計算機６００に対する減額料金の発生の有無も対象となる。なお、処理の内容はステップＳ４０８と同様であるため説明を省略する。

性能保証オプションが設定されていない仮想計算機６００の計算機リソースを流用しても料金の変更が発生しない場合（ステップＳ８０７がＮｏ）、ＤＢ障害対策判定プログラム１０１４は、処理結果をクラウドユーザ１０に通知する（ステップＳ８１１）。その後、ＤＢ障害対策判定プログラム１０１４は、処理を終了する。ステップＳ８１１の処理はステップＳ４１２の処理と同一である。

性能保証オプションが設定されていない仮想計算機６００の計算機リソースを流用することによって料金の変更が発生すると判定された場合（ステップＳ８０７がＹｅｓ）、ＤＢ障害対策判定プログラム１０１４は、課金計算機８００に、料金の変更の発生を通知する（ステップＳ８１２）。当該通知には、ターゲット仮想計算機６００の識別情報、性能保証オプションが設定されていない仮想計算機６００の識別情報、流用された計算機リソース量等の対処法に関する情報が含まれる。ＤＢ障害対策判定プログラム１０１４は、課金計算機８００から応答があるまで待ち続ける。

このとき、課金計算機８００は、ターゲット仮想計算機６００に対する追加料金及び計算機リソースが流用された仮想計算機６００に対する減額料金を算出する。課金計算機８００は、算出された料金を含む課金情報の通知をクラウド管理計算機１００に送信する。

ＤＢ障害対策判定プログラム１０１４は、課金計算機８００から課金情報の通知を受信した場合（ステップＳ８０９）、サービス要件管理情報１００１を更新する（ステップＳ８１０）。ステップＳ８０９の処理はステップＳ４１０の処理と同一である。また、ステップＳ８１０の処理はステップＳ４１１の処理と同様である。ステップＳ８１０では、ターゲット仮想計算機６００に対する追加料金及び計算機リソースが流用された仮想計算機６００に対する減額料金がサービス要件管理情報１００１に反映される点がステップＳ４１１の処理と異なる。

ＤＢ障害対策判定プログラム１０１４は、処理結果をクラウドユーザ１０に通知する（ステップＳ８１１）。その後、ＤＢ障害対策判定プログラム１０１４は、処理を終了する。例えば、性能保証オプションが設定されていない仮想計算機６００の計算機リソースを流用した旨、追加料金及び減額料金が通知される。

実施例２では、ＤＢサーバ８０の性能劣化の原因がＩＯ不足である点が実施例１と異なる。以下、実施例１との差異を中心に実施例２について説明する。

実施例２のシステム構成は実施例１と同一であるため説明を省略する。また、実施例２のクラウド管理計算機１００及び基盤管理計算機２００のハードウェア構成及びソフトウェア構成は実施例１と同一であるため説明を省略する。また、実施例２のクラウド管理計算機１００及び基盤管理計算機２００が管理する情報は実施例１と同一であるため説明を省略する。また、実施例２のクラウド管理計算機１００のＤＢ対処手順生成プログラム１０１３が実行する処理は実施例１と同一であるため説明を省略する。

実施例２では、対処手順管理情報１００４の内容及び対処法が実施例１と異なる。図２４は、実施例２の対処手順管理情報１００４の一例を示す説明図である。

対処手順管理情報１００４のデータ構造は実施例１と同一である。実施例２の対処手順管理情報１００４は、対処手順管理情報１００４の内容が実施例１と異なる。

ＩＯが不足する原因には、ＨＤＤ等の記憶媒体のＩＯＰＳ処理能力の不足に起因するケースと、メモリ容量が不足していることによって記憶媒体へのスワップによるＩＯ増加が起因するケースとがある。そのため、ＩＯ不足に対応するための一連の対処法は、ホスト計算機５００側及びストレージ装置３００側にまたがった処理となる。

具体的には、対処法では、ホスト計算機５００側の機能で実現可能な処理が優先的に行われ、ホスト計算機５００に対する処理だけでは対応できない場合、ストレージ装置３００側の処理にて対応する。

ボトルネックの原因がＣＰＵリソースの不足である場合と同様に、メモリ及び記憶媒体のそれぞれの対処手順については、図１５、図１６及び図１７に示すように追加料金の発生の有無及びクラウドユーザ１０が入力したポリシに基づいて決定される。

図２５Ａ、図２５Ｂ、図２５Ｃ及び図２５Ｄは、実施例２のクラウド管理計算機１００が対処手順管理情報１００４にしたがって実行する処理の一例を説明するフローチャートである。

メモリのリソース量の不足に起因するＩＯ不足については、ＣＰＵのリソース量の不足と同様の対処法にて対応することができるため、ここでは、メモリ容量が十分にあり、かつ、性能劣化の原因が記憶媒体のＩＯＰＳ処理能力の不足であるケースを想定する。すなわち、図２４に示すメモリ容量が不足しているか否かの判定結果がＮｏに分岐した場合の対処法について説明する。

なお、不足しているＩＯリソース量はすでに取得されているものとする。さらに、追加料金に関連する処理は実施例１と同一であるため省略している。

図２５Ａは、対処法１００３２が「ホスト計算機のディスクＩＯの優先度更新」である対処法に対応する処理を示す。

ＤＢ障害対策判定プログラム１０１４は、サービス要件管理情報１００１を参照して、仮想計算機６００の仮想ディスク６３０に記憶領域を提供するボリューム６４０のディスクＩＯの優先度を更新できるか否かを判定する（ステップＳ９０１）。すなわち、シェア値が変更できるか否かが判定される。なお、ステップＳ９０１の判定方法は、ステップＳ４０２と同一の方法である。

ボリューム６４０のディスクＩＯの優先度を更新できないと判定された場合（ステップＳ９０１がＮｏ）、ＤＢ障害対策判定プログラム１０１４は、対処手順管理情報１００４を参照して、次の対処法が存在するか否かを判定する（ステップＳ９０２）。ステップＳ９０２の処理はステップＳ４０３の処理と同一である。

次の対処法が存在すると判定された場合（ステップＳ９０２がＹｅｓ）、ＤＢ障害対策判定プログラム１０１４は、次の対処法に対応する処理を開始する。次の対処法が存在しないと判定された場合（ステップＳ９０２がＮｏ）、ＤＢ障害対策判定プログラム１０１４は、処理を終了する。

ステップＳ９０１において、ボリューム６４０のディスクＩＯの優先度を更新できると判定された場合（ステップＳ９０１がＹｅｓ）、ＤＢ障害対策判定プログラム１０１４は、サービス要件管理情報１００１、クラウド基盤構成情報２００１、計算機リソース割当情報２００２、及びストレージリソース使用状態情報２００４を参照し、ボリューム６４０を共有する他の仮想計算機６００のＩＯＰＳの割当量を保証値まで下げることによって、不足している計算機リソースを確保できるか否かを判定する（ステップＳ９０３）。具体的には、以下のような処理が実行される。

ＤＢ障害対策判定プログラム１０１４は、クラウド基盤構成情報２００１を参照して、仮想計算機識別子２００１１がターゲット仮想計算機６００の識別情報と一致する行を検索する。ＤＢ障害対策判定プログラム１０１４は、検索された行のボリューム識別子２００１４２に格納される値を取得する。

ＤＢ障害対策判定プログラム１０１４は、ボリューム識別子２０１４２３が取得された値と一致する行を検索する。検索された行の仮想計算機識別子２００１１の値を取得する。ターゲット仮想計算機６００以外の識別情報に対応する仮想計算機６００が、当該ターゲット仮想計算機６００と同一のボリューム６４０を共有する仮想計算機６００となる。

なお、以下の説明では、ターゲット仮想計算機６００と同一のボリューム６４０を共有する仮想計算機６００を共有仮想計算機６００とも記載する。

ＤＢ障害対策判定プログラム１０１４は、サービス要件管理情報１００１を参照して、仮想計算機識別子１００１２がターゲット仮想計算機６００の識別情報と一致し、かつ、対象１００１５３が「ディスク」である行を検索する。また、ＤＢ障害対策判定プログラム１０１４は、仮想計算機識別子１００１２が共有仮想計算機６００の識別情報と一致し、かつ、対象１００１５３が「ディスク」である行を検索する。ＤＢ障害対策判定プログラム１０１４は、検索された行の保証値１００１５４に格納される値を取得する。

ＤＢ障害対策判定プログラム１０１４は、計算機リソース割当情報２００２を参照して、仮想計算機識別子２００２２がターゲット仮想計算機６００の識別情報と一致し、かつ、計算機リソース種別２００２３１が「ディスク」である行を検索する。また、ＤＢ障害対策判定プログラム１０１４は、仮想計算機識別子２００２２が共有仮想計算機６００の識別情報と一致し、かつ、計算機リソース種別２００２３１が「ディスク」である行を検索する。ＤＢ障害対策判定プログラム１０１４は、検索された行の確保形態２００２３２に格納される値を取得する。

ＤＢ障害対策判定プログラム１０１４は、ターゲット仮想計算機６００の保証値１００１５４及び確保形態２００２３２から取得された値、並びに、共有仮想計算機６００の保証値１００１５４及び確保形態２００２３２から取得された値に基づいて、共有仮想計算機６００のＩＯＰＳの割当量を保証値まで下げることによって、不足している計算機リソースを確保できるか否かを判定する。以上がステップＳ９０３の処理の説明である。

不足している計算機リソースを確保できないと判定された場合（ステップＳ９０３がＮｏ）、ＤＢ障害対策判定プログラム１０１４は、ステップＳ９０２に進む。

不足している計算機リソースを確保できると判定された場合（ステップＳ９０３がＹｅｓ）、ＤＢ障害対策判定プログラム１０１４は、ターゲット仮想計算機６００のシェア値を更新することによって、不足している計算機リソースを確保する（ステップＳ９０４）。その後、ＤＢ障害対策判定プログラム１０１４は、処理を終了する。

図２５Ｂは、対処法１００３２が「他のＶＭのボリュームを移行」である対処法に対応する処理を示す。

ここで、「他のＶＭのボリュームを移行」とは、仮想計算機６００のイメージデータが格納されるボリューム６４０を他のボリューム６４０にコピーすることを意味する。

ＤＢ障害対策判定プログラム１０１４は、サービス要件管理情報１００１のハードウェア指定１００１５２を参照して、ディスクを共有する他の仮想計算機６００を他のボリュームに移行できるか否かを判定する（ステップＳ９１１）。

ディスクを共有する他の仮想計算機６００を他のボリュームに移行できないと判定された場合（ステップＳ９１１がＮｏ）、ＤＢ障害対策判定プログラム１０１４は、対処手順管理情報１００４を参照して、次の対処法が存在するか否かを判定する（ステップＳ９１２）。ステップＳ９１２の処理はステップＳ４０３の処理と同一である。

次の対処法が存在すると判定された場合（ステップＳ９１２がＹｅｓ）、ＤＢ障害対策判定プログラム１０１４は、次の対処法に対する処理を開始する。次の対処法が存在しないと判定された場合（ステップＳ９１２がＮｏ）、ＤＢ障害対策判定プログラム１０１４は、処理を終了する。

ディスクを共有する他の仮想計算機６００を他のボリュームに移行できると判定された場合（ステップＳ９１１がＹｅｓ）、ＤＢ障害対策判定プログラム１０１４は、計算機リソース割当情報２００２、ストレージリソース使用状態情報２００４及びストレージ構成情報２００５を参照して、ターゲット仮想計算機６００とディスクを共有する他の仮想計算機６００のうち、ディスク指定のない仮想計算機６００に対するＩＯＰＳの合計値が不足しているＩＯリソース量以上であるか否かを判定する（ステップＳ９１３）。

ディスク指定のない仮想計算機６００に対するＩＯＰＳの合計値が不足しているＩＯリソース量より小さい場合（ステップＳ９１３がＮｏ）、ＤＢ障害対策判定プログラム１０１４は、ステップＳ９１２に進む。

ディスク指定のない仮想計算機６００に対するＩＯＰＳの合計が不足しているＩＯリソース量以上である場合（ステップＳ９１３がＹｅｓ）、ＤＢ障害対策判定プログラム１０１４は、ストレージリソース使用状態情報２００４及びストレージ構成情報２００５を参照して、ディスク指定がない仮想計算機６００に必要な計算機リソースを有するストレージ装置３００を確保できるか否か判定する（ステップＳ９１４）。

条件を満たすストレージ装置３００を確保できないと判定された場合（ステップＳ９１４がＮｏ）、ＤＢ障害対策判定プログラム１０１４は、ステップＳ９１２に進む。

条件を満たすストレージ装置３００を確保できると判定された場合（ステップＳ９１４がＹｅｓ）、ＤＢ障害対策判定プログラム１０１４は、ステップＳ９１３において選択された他の仮想計算機６００を、条件を満たすストレージ装置３００に移行する（ステップＳ９１８）。その後、ＤＢ障害対策判定プログラム１０１４は、処理を終了する。なお、移行先のストレージ装置３００が複数存在する場合、ＤＢ障害対策判定プログラム１０１４は、ＩＯＰＳの空きが多いものを優先的に選択するものとする。

図２５Ｃは、対処法１００３２が「論理記憶領域の増強」である対処法に対応する処理を示す。

ＤＢ障害対策判定プログラム１０１４は、ストレージ構成情報２００５を参照して、スペアディスクの有無を確認して、論理記憶領域３１０を増強できるか否かを判定する（ステップＳ９２１）。

論理記憶領域の増強ができないと判定された場合（ステップＳ９２１がＮｏ）、ＤＢ障害対策判定プログラム１０１４は、対処手順管理情報１００４を参照して、次の対処法が存在するか否かを判定する（ステップＳ９２２）。ステップＳ９２２の処理はステップＳ４０３の処理と同一である。

次の対処法が存在すると判定された場合（ステップＳ９２２がＹｅｓ）、ＤＢ障害対策判定プログラム１０１４は、次の対処法に対応する処理を開始する。次の対処法が存在しないと判定された場合（ステップＳ９２２がＮｏ）、ＤＢ障害対策判定プログラム１０１４は、処理を終了する。

ステップＳ９２１において、論理記憶領域の増強ができると判定された場合（ステップＳ９２１がＹｅｓ）、ＤＢ障害対策判定プログラム１０１４は、ストレージプール３２０にディスクを追加する（ステップＳ９２３）。その後、ＤＢ障害対策判定プログラム１０１４は、処理を終了する。

図２５Ｄは、対処法１００３２が「ＩＯＰＳの融通」である対処法に対応する処理を示す。

ＤＢ障害対策判定プログラム１０１４は、ターゲット仮想計算機６００とディスクを共有する他の仮想計算機６００を検索する（ステップＳ９３１）。さらに、ＤＢ障害対策判定プログラム１０１４は、サービス要件管理情報１００１を参照して、検索された仮想計算機６００の中に、性能保証オプションが設定されていない仮想計算機６００が存在するか否かを判定する（ステップＳ９３２）。

条件を満たす他の仮想計算機６００が存在しないと判定された場合（ステップＳ９３２がＮｏ）、ＤＢ障害対策判定プログラム１０１４は、対処手順管理情報１００４を参照して、次の対処法が存在するか否かを判定する（ステップＳ９３３）。ステップＳ９３３の処理はステップＳ４０３の処理と同一である。

次の対処法が存在すると判定された場合（ステップＳ９３３がＹｅｓ）、ＤＢ障害対策判定プログラム１０１４は、次の対処法に対応する処理を開始する。次の対処法が存在しないと判定された場合（ステップＳ９３３がＮｏ）、ＤＢ障害対策判定プログラム１０１４は、処理を終了する。

ステップＳ９３２において、条件を満たす他の仮想計算機６００が存在すると判定された場合（ステップＳ９３２がＹｅｓ）、ＤＢ障害対策判定プログラム１０１４は、当該仮想計算機６００が使用しているディスクのＩＯＰＳが不足しているＩＯリソース量以上であるか否かを判定する（ステップＳ９３４）。

他の仮想計算機６００が使用しているディスクのＩＯＰＳが不足しているＩＯリソース量より小さいと判定された場合（ステップＳ９３４がＮｏ）、ＤＢ障害対策判定プログラム１０１４は、ロードバランサ６０に対して、フロントエンド側の流量を制限する旨の要求を送信する（ステップＳ９３５）。その後、ＤＢ障害対策判定プログラム１０１４は、処理を終了する。

他の仮想計算機６００が使用しているディスクのＩＯＰＳが不足しているＩＯリソース量以上であると判定された場合（ステップＳ９３４がＹｅｓ）、ＤＢ障害対策判定プログラム１０１４は、例えば、ボリューム６４０のＩＯＰＳシェア値の変更機能を用いて、性能保証オプションが設定されていない他の仮想計算機６００のＩＯＰＳをターゲット仮想計算機６００に流用する（ステップＳ９３６）。その後、ＤＢ障害対策判定プログラム１０１４は、処理を終了する。

なお、ステップＳ９３６の処理を実行した後、ターゲット仮想計算機６００へのアクセス数が減りディスクに対する負荷が減少した場合、ＤＢ障害対策判定プログラム１０１４は、通常のシェア値に設定を戻す。

以上で説明したように、クラウド管理計算機１００は、テナント５０のサービスの契約内容に基づいて、ＤＢサーバ８０の障害に対応するための対処法を選択し、また、ポリシ等に基づいて選択された対処法の判定順番を決定することができる。すなわち、適切な対処手順管理情報１００４が生成される。

また、クラウド管理計算機１００は、対処手順管理情報１００４と、サービス要件管理情報１００１及び計算機リソース割当情報２００２等の他のテナント５０の情報とに基づいて対処法を実行することによって、他のテナント５０への影響を抑えつつ、障害が発生したＤＢサーバ８０を含むテナント５０の性能を保証できる。

なお、ＤＢサーバ８０とは仮想計算機６００を用いて実現していたが、一つのホスト計算機５００を用いて実現してもよい。この場合、ＤＢ障害対処法管理情報１００３には、ホスト計算機５００に対する対処法が格納される。

なお、本発明は上記した実施例に限定されるものではなく、様々な変形例が含まれる。また、例えば、上記した実施例は本発明を分かりやすく説明するために構成を詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。また、各実施例の構成の一部について、他の構成に追加、削除、置換することが可能である。

また、上記の各構成、機能、処理部、処理手段等は、それらの一部又は全部を、例えば集積回路で設計する等によりハードウェアで実現してもよい。また、本発明は、実施例の機能を実現するソフトウェアのプログラムコードによっても実現できる。この場合、プログラムコードを記録した記憶媒体をコンピュータに提供し、そのコンピュータが備えるＣＰＵが記憶媒体に格納されたプログラムコードを読み出す。この場合、記憶媒体から読み出されたプログラムコード自体が前述した実施例の機能を実現することになり、そのプログラムコード自体、及びそれを記憶した記憶媒体は本発明を構成することになる。このようなプログラムコードを供給するための記憶媒体としては、例えば、フレキシブルディスク、ＣＤ−ＲＯＭ、ＤＶＤ−ＲＯＭ、ハードディスク、ＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）、光ディスク、光磁気ディスク、ＣＤ−Ｒ、磁気テープ、不揮発性のメモリカード、ＲＯＭなどが用いられる。

また、本実施例に記載の機能を実現するプログラムコードは、例えば、アセンブラ、Ｃ／Ｃ＋＋、ｐｅｒｌ、Ｓｈｅｌｌ、ＰＨＰ、Ｊａｖａ（登録商標）等の広範囲のプログラム又はスクリプト言語で実装できる。

さらに、実施例の機能を実現するソフトウェアのプログラムコードを、ネットワークを介して配信することによって、それをコンピュータのハードディスクやメモリ等の記憶手段又はＣＤ−ＲＷ、ＣＤ−Ｒ等の記憶媒体に格納し、コンピュータが備えるＣＰＵが当該記憶手段や当該記憶媒体に格納されたプログラムコードを読み出して実行するようにしてもよい。

上述の実施例において、制御線や情報線は、説明上必要と考えられるものを示しており、製品上必ずしも全ての制御線や情報線を示しているとは限らない。全ての構成が相互に接続されていてもよい。

１０ クラウドユーザ
２０ クラウド管理者
３０ ポータル
４０ ネットワーク
５０ テナント
６０ ロードバランサ
７０ Ｗｅｂサーバ
８０ ＤＢサーバ
９０ クラウドシステム
１００ クラウド管理計算機
２００ 基盤管理計算機
３００ ストレージ装置
３１０ 論理記憶領域
３２０ ストレージプール
４００ ネットワーク接続装置
５００ ホスト計算機
６００ 仮想計算機
６１０ ＤＢ
６２０ ゲストＯＳ
６３０ ボリューム
７００ 管理用ネットワーク
８００ 課金計算機
９００ クラスタ
１０００ プログラムメモリ
１００１ サービス要件管理情報
１００２ ポリシ管理情報
１００３ ＤＢ障害対処法管理情報
１００４ 対処手順管理情報
１０１０ サービス管理プログラム
１０１１ ポリシ管理プログラム
１０１２ 対処法管理プログラム
１０１３ ＤＢ対処手順生成プログラム
１０１４ ＤＢ障害対策判定プログラム
１０１５ 課金管理プログラム
２０００ プログラムメモリ
２００１ クラウド基盤構成情報
２００２ 計算機リソース割当情報
２００３ サーバリソース使用状態情報
２００４ ストレージリソース使用状態情報
２００５ ストレージ構成情報
２０１０ ＤＢ障害検知プログラム
２０１１ ＤＢボトルネック分析プログラム
２０１２ 構成管理プログラム
２０１３ ＤＢ障害復旧プログラム
２０１４ リソース監視プログラム

Claims (14)

1. 複数の計算機を備える計算機システムであって、
   前記複数の計算機は、前記計算機システムを管理する少なくとも一つの第１の計算機、及びユーザの業務に使用する業務システムを構築するための計算機リソースを提供する複数の第２の計算機を含み、
   前記少なくとも一つの第１の計算機は、第１のプロセッサ、前記第１のプロセッサに接続される第１のメモリ、及び前記第１のプロセッサに接続される第１のインタフェースを有し、
   前記複数の第２の計算機の各々は、第２のプロセッサ、前記第２のプロセッサに接続される第２のメモリ、前記第２のプロセッサに接続される第２のインタフェース、及び記憶装置を有し、
   前記業務システムは、複数の業務計算機を含み、
   前記少なくとも一つの第１の計算機は、
   前記計算機システム上に構築された複数の業務システムの各々のサービス要件を管理するサービス要件管理情報と、前記業務計算機の性能劣化が検知された場合、計算機リソースの種別毎の性能劣化を改善するための制御方法である対処法を管理する対処法管理情報と、を保持し、
   複数の対処法の集合であり、性能劣化が検知された前記業務計算機に対して前記対処法を実行できるか否かを判定する順番を含む対処手順管理情報を生成する対処手順生成部を有し、
   前記サービス要件は、前記業務システムに含まれる前記複数の業務計算機の各々の性能保証の条件、前記業務システムに含まれる前記複数の業務計算機の各々の運用の条件、及び、前記業務システムの課金体系の条件に関する情報を含み、
   前記対処法管理情報に含まれる複数の対処法の各々は、前記対処法に対応する処理におけるコスト情報と対応付けられて管理され、
   前記対処手順生成部は、
   前記対処手順管理情報を生成する対象の業務システムを選択し、
   前記対象の業務システムに含まれる前記複数の業務計算機の中から処理対象の業務計算機を選択し、
   前記処理対象の業務計算機における対象の計算機リソースを選択し、
   前記サービス要件管理情報に基づいて、前記対処法管理情報に含まれる前記複数の対処法の中から、前記対象の業務システムの前記サービス要件に合致する複数の対処法を選択し、
   前記選択された複数の対処法が実行可能か否かを判定する判定順番を決定することによって、前記対処手順管理情報を生成することを特徴とする計算機システム。
2. 請求項１に記載の計算機システムであって、
   前記少なくとも一つの第１の計算機は、
   前記複数の業務システムの各々に対する計算機リソースの割当状態を管理する計算機リソース割当情報、及び複数の対処手順管理情報を保持し、
   前記対処手順管理情報にしたがって、前記対処法に対応する処理を実行する障害対策判定部を有し、
   前記障害対策判定部は、
   任意の業務計算機の性能劣化が検知された場合、性能劣化が検知された前記業務計算機の識別情報及び性能劣化の原因となる前記計算機リソースの種別に基づいて、前記複数の対処手順管理情報の中から適用する前記対処手順管理情報を選択し、
   前記選択された対処手順管理情報の前記判定順番にしたがって前記対処法を一つ選択し、
   前記サービス要件管理情報及び前記計算機リソースの割当情報を参照して、前記性能劣化が検知された業務計算機を含む業務システム以外の業務システムの前記サービス要件及び前記計算機リソースの割当状態に基づいて、前記性能劣化が検知された業務計算機に対して前記選択された対処法を実行できるか否かを判定し、
   前記性能劣化が検知された業務計算機に前記選択された対処法を実行できると判定した場合、前記選択された対処法を実行することを特徴とする計算機システム。
3. 請求項２に記載の計算機システムであって、
   前記複数の第２の計算機の各々は、前記計算機リソースを論理的に分割することによって生成された仮想計算機を管理する仮想化部を有し、
   第１の業務計算機及び業務計算機は前記仮想計算機を用いて実現され、
   前記計算機リソース割当情報は、前記複数の第２の計算機の各々で稼働する複数の仮想計算機に対する計算機リソースの割り当てに関する情報を含み、
   前記対処手順生成部は、
   前記対象の業務システムの課金体系が追加料金の発生が許容されていない課金体系であるか否かを判定し、
   前記対象の業務システムの課金体系が追加料金の発生が許容されていない課金体系であると判定された場合、前記対処法管理情報を参照して、追加料金が発生しない前記複数の対処法を選択し、さらに、前記選択された複数の対処法の中から前記処理対象の業務計算機の性能保証の条件及び運用の条件を満たす複数の対処法を選択し、
   前記対象の業務システムの課金体系が追加料金の発生が許容されている課金体系であると判定された場合、前記対処法管理情報を参照して、前記処理対象の業務計算機の性能保証の条件及び運用の条件を満たす複数の対処法を選択することを特徴とする計算機システム。
4. 請求項３に記載の計算機システムであって、
   前記対処手順生成部は、
   前記対処法管理情報を参照して、処理負荷が低い順又は処理時間が短い順に前記選択された複数の対処法の前記判定順番を決定し、
   性能劣化が許容されている業務計算機に割り当てられた計算機リソースを流用する対処法を前記決定された判定順番の最後に追加することによって、前記対処手順管理情報を生成することを特徴とする計算機システム。
5. 請求項３に記載の計算機システムであって、
   前記少なくとも一つの第１の計算機は、前記複数の業務システムの各々の前記判定順番を決定するためのポリシ管理情報を保持し、
   前記対処手順生成部は、
   前記ポリシ管理情報を参照して、前記選択された複数の対処法の前記判定順番を決定することを特徴とする計算機システム。
6. 請求項３に記載の計算機システムであって、
   前記仮想化部は、当該仮想化部が管理する複数の仮想計算機に対する前記計算機リソースの配分率を決定するためのシェア値を設定し、
   前記複数の対処法は、前記シェア値の変更処理、前記第２の計算機間における前記仮想計算機の移行処理、及び前記計算機リソースの追加を含むことを特徴とする計算機システム。
7. 請求項３に記載の計算機システムであって、
   前記計算機システムは、前記業務システムのユーザの利用料金を算出する課金部を有する計算機を備え、
   前記障害対策判定部は、
   前記選択された対処法を実行することによって利用料金に変更があるか否かを判定し、
   前記選択された対処法を実行することによって利用料金に変更があると判定された場合、前記選択された対処法の処理結果を含む通知を前記課金部に送信することを特徴とする計算機システム。
8. 複数の計算機を備える計算機システムの性能障害の対処方法であって、
   前記複数の計算機は、前記計算機システムを管理する少なくとも一つの第１の計算機、及びユーザの業務に使用する業務システムを構築するための計算機リソースを提供する複数の第２の計算機を含み、
   前記少なくとも一つの第１の計算機は、第１のプロセッサ、前記第１のプロセッサに接続される第１のメモリ、及び前記第１のプロセッサに接続される第１のインタフェースを有し、
   前記複数の第２の計算機の各々は、第２のプロセッサ、前記第２のプロセッサに接続される第２のメモリ、前記第２のプロセッサに接続される第２のインタフェース、及び記憶装置を有し、
   前記業務システムは、複数の業務計算機を含み、
   前記少なくとも一つの第１の計算機は、
   前記計算機システム上に構築された複数の業務システムの各々のサービス要件を管理するサービス要件管理情報と、前記業務計算機の性能劣化が検知された場合、計算機リソースの種別毎の性能劣化を改善するための制御方法である対処法を管理する対処法管理情報と、を保持し、
   複数の対処法の集合であり、性能劣化が検知された前記業務計算機に対して前記対処法を実行できるか否かを判定する順番を含む対処手順管理情報を生成する対処手順生成部を有し、
   前記サービス要件は、前記業務システムに含まれる前記複数の業務計算機の各々の性能保証の条件、前記業務システムに含まれる前記複数の業務計算機の各々の運用の条件、及び、前記業務システムの課金体系の条件に関する情報を含み、
   前記対処法管理情報に含まれる複数の対処法の各々は、前記対処法に対応する処理におけるコスト情報と対応付けられて管理され、
   前記計算機システムの性能障害の対処方法は、
   前記対処手順生成部が、前記対処手順管理情報を生成する対象の業務システムを選択する第１のステップと、
   前記対処手順生成部が、前記対象の業務システムに含まれる前記複数の業務計算機の中から処理対象の業務計算機を選択する第２のステップと、
   前記対処手順生成部が、前記処理対象の業務計算機における対象の計算機リソースを選択する第３のステップと、
   前記対処手順生成部が、前記サービス要件管理情報に基づいて、前記対処法管理情報に含まれる前記複数の対処法の中から、前記対象の業務システムの前記サービス要件に合致する複数の対処法を選択する第４のステップと、
   前記対処手順生成部が、前記選択された複数の対処法が実行可能か否かを判定する判定順番を決定することによって、前記対処手順管理情報を生成する第５のステップと、を含むことを特徴とする計算機システムの性能障害の対処方法。
9. 請求項８に記載の計算機システムの性能障害の対処方法であって、
   前記少なくとも一つの第１の計算機は、
   前記複数の業務システムの各々に対する計算機リソースの割当状態を管理する計算機リソース割当情報、及び複数の対処手順管理情報を保持し、
   前記対処手順管理情報にしたがって、前記対処法に対応する処理を実行する障害対策判定部を有し、
   前記計算機システムの性能障害の対処方法は、
   前記障害対策判定部が、任意の業務計算機の性能劣化が検知された場合、性能劣化が検知された前記業務計算機の識別情報及び性能劣化の原因となる計算機リソースの種別に基づいて、前記複数の対処手順管理情報の中から適用する前記対処手順管理情報を選択するステップと、
   前記障害対策判定部が、前記選択された対処手順管理情報の前記判定順番にしたがって前記対処法を一つ選択するステップと、
   前記障害対策判定部が、前記サービス要件管理情報及び前記計算機リソースの割当情報を参照して、前記性能劣化が検知された業務計算機を含む業務システム以外の業務システムの前記サービス要件及び前記計算機リソースの割当状態に基づいて、前記性能劣化が検知された業務計算機に対して前記選択された対処法を実行できるか否かを判定するステップと、
   前記障害対策判定部が、前記性能劣化が検知された業務計算機に前記選択された対処法を実行できると判定した場合、前記選択された対処法を実行するステップと、を含むことを特徴とする計算機システムの性能障害の対処方法。
10. 請求項９に記載の計算機システムの性能障害の対処方法であって、
    前記複数の第２の計算機の各々は、前記計算機リソースを論理的に分割することによって生成された仮想計算機を管理する仮想化部を有し、
    第１の業務計算機及び業務計算機は前記仮想計算機を用いて実現され、
    前記計算機リソース割当情報は、前記複数の第２の計算機の各々で稼働する複数の仮想計算機に対する計算機リソースの割り当てに関する情報を含み、
    前記第４のステップは、
    前記対象の業務システムの課金体系が追加料金の発生が許容されていない課金体系であるか否かを判定するステップと、
    前記対象の業務システムの課金体系が追加料金の発生が許容されていない課金体系であると判定された場合、前記対処法管理情報を参照して、追加料金が発生しない前記複数の対処法を選択し、さらに、前記選択された複数の対処法の中から前記処理対象の業務計算機の性能保証の条件及び運用の条件を満たす複数の対処法を選択するステップと、
    前記対象の業務システムの課金体系が追加料金の発生が許容されている課金体系であると判定された場合、前記対処法管理情報を参照して、前記処理対象の業務計算機の性能保証の条件及び運用の条件を満たす複数の対処法を選択するステップと、を含むことを特徴とする計算機システムの性能障害の対処方法。
11. 請求項１０に記載の計算機システムの性能障害の対処方法であって、
    前記第５のステップは、
    前記対処法管理情報を参照して、処理負荷が低い順又は処理時間が短い順に前記選択された複数の対処法の前記判定順番を決定するステップと、
    性能劣化が許容されている業務計算機に割り当てられた計算機リソースを流用する対処法を前記決定された判定順番の最後に追加することによって、前記対処手順管理情報を生成するステップと、を含むことを特徴とする計算機システムの性能障害の対処方法。
12. 請求項１０に記載の計算機システムの性能障害の対処方法であって、
    前記少なくとも一つの第１の計算機は、前記複数の業務システムの各々の前記判定順番を決定するためのポリシ管理情報を保持し、
    前記第５のステップは、前記ポリシ管理情報を参照して、前記選択された複数の対処法の前記判定順番を決定するステップを含むことを特徴とする計算機システムの性能障害の対処方法。
13. 請求項１０に記載の計算機システムの性能障害の対処方法であって、
    前記仮想化部は、当該仮想化部が管理する複数の仮想計算機に対する前記計算機リソースの配分率を決定するためのシェア値を設定し、
    前記複数の対処法は、前記シェア値の変更処理、前記第２の計算機間における前記仮想計算機の移行処理、及び前記計算機リソースの追加を含むことを特徴とする計算機システムの性能障害の対処方法。
14. 請求項１０に記載の計算機システムの性能障害の対処方法であって、
    前記計算機システムは、前記業務システムのユーザの利用料金を算出する課金部を有する計算機を備え、
    前記計算機システムの性能障害の対処方法は、
    前記障害対策判定部が、前記選択された対処法を実行することによって利用料金に変更があるか否かを判定するステップと、
    前記障害対策判定部が、前記選択された対処法を実行することによって利用料金に変更があると判定された場合、前記選択された対処法の処理結果を含む通知を前記課金部に送信するステップと、を含むことを特徴とする計算機システムの性能障害の対処方法。

Images