JP5525654B2 - リソース管理方法および管理サーバ - Google Patents

Description

本発明は、ネットワーク上のリソースを有効に活用することができるリソース管理方法および管理サーバに関する。

近年、大規模なクラウド技術や、異なるサーバ間でのリソースを組み合わせることのできるバスアーキテクチャ、Ｉ／Ｏ（Input/Output）デバイス割り当てをサーバ間で切り替えることができるＩ／Ｏスイッチ拡張装置を導入したリソース群が増加傾向にある。

また、クラウド技術の普及により、利用者または管理者の不特定化が進んでおり、不特定または未知数のハードウェアが不定期に増減する。このため、リソース群の配置管理をいかに行うかが重要となっている。リソース群の配置管理は、リソース群維持に要するコスト削減や、ユーザに提供するサーバの性能向上に多大に関係する。

リソース群の配置管理として、仮想計算機システムにおける演算に基づく方法が開示されている（例えば、特許文献１参照）。仮想計算機システムは、計算機の物理資源（リソース）を共有してアプリケーションを実行する複数の仮想装置と、複数の仮想装置を管理する仮想化手段と、仮想化手段を制御する管理手段とを有し、複数の仮想装置と管理手段との間で資源供給情報（例えば、資源割当量）および資源要求情報を交換しながら、第１の最適化演算と第２の最適化演算とを実行することにより、物理資源の動的な資源割り当てを行う。

ＷＯ２００８／１３２９２４号公報

変動が生じるリソース群を対象とする場合、特許文献１に開示された演算に基づく方法でリソース配置の改善を行うと、演算に必要なパラメータ（例えば、リソースの種類や設定条件）の調査前後、およびそれらを用いた演算前後でのパラメータの不一致により、信頼できる改善された配置情報を管理者に提供できないことがある。

また、変動が生じないリソース群においても、演算によるリソース配置の改善は、把握できていないデバイスの周辺状況（温度または湿度、接続されているデバイス、故障、距離、通信量など）の影響により組み合わせたときに期待通りの性能が出ないことがある。

このため、要求する性能を可能にするリソース群の配置を、演算方法をよらないで、事前準備をしないで、改善のための必要時間にできるだけ制約されないで、入手可能な情報で随時行う仕組みも管理対象のリソース群にとっては必要となると考える。

本発明は、前記の課題を解決するための発明であって、ネットワーク上のリソースを有効に活用することができるリソース管理方法および管理サーバを提供することを目的とする。

前記目的を達成するため、本発明のリソース管理方法は、ネットワークに複数のサーバが接続された計算機システムにおいて、管理サーバが、該ネットワークで確保できたリソースを組み合わせて試行用サーバ（例えば、試行用物理サーバ１００ｂ、試行用仮想サーバ１３０ｂ）を形成し、該試行用サーバが所定条件を満たす場合に、該ネットワークのサーバとして適用するリソース管理方法である。

管理サーバは、ネットワークで確保できたリソースに対し、試行用サーバが適用された際の適用情報の実績として抽出確率が登録されたリソース情報（例えば、リソース情報テーブル２１１）と、試行用サーバを採用するか否かの所定条件であるジョブを管理するジョブ管理情報（例えば、ジョブ管理テーブル２１５）とを記憶部に記憶している。また、管理サーバは、リソース情報の各リソースに対し、抽出確率が乱数生成部で発生させた乱数確率以上であれば、試行用のリソースとして選定し、選定されたリソースを組み合わせて試行用サーバを形成し、前記形成された試行用サーバを用いて前記ジョブを実行し、実行の結果がよければ、試行用サーバを該ネットワークのサーバとして適用することを特徴とする。

本発明によれば、ネットワーク上のリソースを有効に活用することができる。

本発明に係るネットワークシステムを示す全体構成図である。 管理サーバの構成を示す詳細図である。 仮想サーバ、試行用仮想サーバを適用した物理サーバの構成を示す詳細図である。 図３に示す仮想サーバ、試行用仮想サーバを適用した物理サーバとディスク装置との関係を示す詳細図である。 物理サーバ、試行用物理サーバの構成を示す詳細図である。 試行用物理サーバ、試行用仮想サーバが試行による改善で採用された際のリソースの再配置の関係を示す説明図である。 リソース情報テーブルの一例および使用率グラフを示す説明図であり、（ａ）はリソース情報テーブルの一例を示す図であり、（ｂ）は、リソース情報テーブルの使用率グラフの例を示す図である。 改善リソース情報テーブルの一例を示す説明図である。 履歴テーブルの一例を示す説明図である。 サーバの関係テーブルの一例を示す説明図である。 ジョブ管理テーブルの一例を示す説明図である。 改善指定とジョブとの関係テーブルの一例を示す説明図である。 ジョブ結果管理テーブルの一例を示す説明図である。 改善記録テーブルの一例を示す説明図である。 情報収集部の処理を示すフローチャートである。 リソース配置改善部の処理を示すフローチャートである。 リソース確保・試行改善部の処理を示すフローチャートである。 試行改善部の処理を示すフローチャートである。 改善配置適用部の処理を示すフローチャートである。 比較情報取得部の処理を示すフローチャートである。 サーバの関係情報取得部の処理を示すフローチャートである。 リソース情報取得部の処理を示すフローチャートである。 仮想割り当て情報取得部の処理を示すフローチャートである。 サーバ群生成部の処理を示すフローチャートである。

以下、本発明の実施形態について図面を用いて詳細に説明する。
図１は、本発明に係るネットワークシステムを示す全体構成図である。図１に示すように、ネットワークシステムは、管理サーバ２００と、１以上の物理サーバ１００と、Ｉ／Ｏスイッチ拡張装置１６０、バス接続制御装置１５０とがネットワークスイッチ１４０を介して接続されている。物理サーバ１００には、Ｉ／Ｏスイッチ拡張装置１６０、Ｉ／Ｏデバイス１７０を介して、ディスクボリューム１９０を有するストレージ装置１８０が接続されている。なお、物理サーバ１００には、仮想サーバ１３０を提供する仮想化機構部１３１を有する物理サーバも含まれる。

管理サーバ２００は、ネットワークシステムにおけるリソース群を有効に活用する上で、リソース配置の改善を行う制御の中心である。リソース群とは、リソースの総称であり、サーバを構成する構成品（例えば、プロセッサ、メモリ、ＨＤＤ、ＦＣ（Fibre Channel）、ＬＡＮなど）の組み合わせを意味する。

本実施形態に係る管理サーバ２００は、ネットワーク上のリソースの情報を、物理サーバ１００から収集し、割り当て済みでないリソース群の未使用のリソースを組み合わせて、試行用サーバ（試行用物理サーバ１００ｂ、試行用仮想サーバ１３０ｂ）を形成し、試行用サーバが所定条件を満たす場合に、該ネットワーク上のサーバとして適用する。なお、試行用サーバというときは、試行用物理サーバ１００ｂ、試行用仮想サーバ１３０ｂを含む一般的表現である。

管理サーバ２００は、ネットワーク上で確保できたリソースに対し、試行用サーバが適用された際の適用情報の実績として抽出確率Ｅｐ（Extraction probability）が登録されたリソース情報テーブル２１１（図７参照）と、試行用サーバを採用するか否かの所定条件であるジョブを管理するジョブ管理テーブル２１５（図１１参照）とをメモリ２０１（記憶部）（図２参照）に記憶している。また、管理サーバ２００は、リソース情報テーブル２１１（図７参照）の各リソースに対し、抽出確率Ｅｐが乱数生成部２２１（図２参照）で発生させた乱数確率Ｒｐ（Random numbers probability）以上であれば、リソースとして選定し、選定されたリソースを組み合わせて試行用サーバを形成し、形成された試行用サーバを用いて所定のジョブを実行し、実行の結果がよければ、試行用サーバを該ネットワーク上のサーバとして適用することができる。

図１に戻り、バス接続制御装置１５０は、例えば、物理サーバ１００間（例えば、サーバブレード間）のＳＭＰ（Symmetric Multi Processor）接続による性能拡張の手法を実行する。ＳＭＰ接続とは、複数のサーバブレードをひとつに結合し、より高性能なサーバを作る性能拡張の手法である。バス接続制御装置１５０は、管理サーバ２００からの指示で、メモリ１０１、プロセッサ１０２を物理サーバ１００（物理サーバ１００ａ，試行用物理サーバ１００ｂ，仮想サーバ用の物理サーバ１００ｃ）に割り当てる。

図２は、管理サーバの構成を示す詳細図である。管理サーバ２００は、メモリ２０１（記憶部）、プロセッサ２０２（処理部）、ユーザＩ／Ｆ２０３、ネットワークＩ／Ｆ２０４、ディスクＩ／Ｆ２０５から構成されている。

メモリ２０１には、リソース配置改善部２０６（図１６参照）、情報収集部２１０（図１５参照）を有しており、各種テーブル類には、リソース情報テーブル２１１（図７参照）、改善リソース情報テーブル２１２（図８参照）、履歴テーブル２１３（図９参照）、サーバの関係テーブル２１４（図１０参照）、ジョブ管理テーブル２１５（図１０参照）、ジョブ結果管理テーブル２１６（図１２参照）、改善記録テーブル２１７（図１３参照）、および改善指定とジョブとの関係テーブル２１８（図１４参照）から構成される。

リソース配置改善部２０６は、乱数生成部２２１、リソース確保・試行改善部２０７（図１７参照）、改善配置適用部２０９（図１９参照）を有し、リソース確保・試行改善部２０７には、サーバ群生成部２２０（図２４参照）を含む試行改善部２０８（図１８参照）を有する。

ユーザＩ／Ｆ２０３は、メモリ２０１内の各テーブルをユーザ定義のもと更新する際にユーザの要求を管理サーバ２００へ入力するためのＩ／Ｆである。ネットワークＩ／Ｆ２０４は、各サーバとネットワークを接続するＩ／Ｆである。ディスクＩ／Ｆ２０５は、各サーバとディスクボリューム１９０（図１参照）を接続するＩ／Ｆである。

リソース配置改善部２０６は、試行による方法、演算による方法によりリソースの配置改善をすることができる。試行による方法では、新規・改善・保守・増設・削減・故障特定などの試行方法によりリソースの抽出確率Ｅｐを設定したのち、リソース確保・試行改善部２０７を呼び出す。リソース確保・試行改善部２０７において、ネットワークに接続されたサーバ群から、各リソースの使用率を可能な範囲で調査し、試行用リソースを確保し、試行改善部２０８を呼び出す。試行改善部２０８では、確保できたリソースで試行用サーバを形成してジョブを実行するとともに現用のサーバでも実行し、ジョブ結果を現用のサーバと試行用サーバで比較し、サーバ群の改善確認をする。その結果をもって改善記録の成否を更新し、改善配置適用部２０９が、改善していれば生成された試行用サーバまたは試行用仮想サーバを適用する。

乱数生成部２２１は、乱数の生成部であり、生成された乱数確率Ｒｐ（乱数値）はリソースを選択する際に、リソース情報テーブル２１１（図７参照）の抽出確率Ｅｐと比較するために用いられる。乱数値は、例えば、最小値と最大値を与え、その間で乱数を発生させるとよい。リソース情報テーブル２１１（図７参照）の各リソースには、抽出確率Ｅｐが格納されており、どのリソースの抽出確率Ｅｐも０％にはならないように設定されている。各リソースの抽出確率Ｅｐが、乱数生成部２２１で発生させた乱数値以上であれば、そのリソースは試行用のリソースとして採用される。乱数生成部２２１によりリソースごとに毎回乱数を発生させることが本願発明の特徴でもある。

具体的に説明すると、第１のリソースの抽出確率Ｅｐが３７．５とすると、最小値０、最大値９９として整数値の乱数を発生させると乱数値１２を得たとする。すると、１２≦３７．５となり、対象となるリソースは採用される。次の第２のリソースの抽出確率Ｅｐが１２．５とすると、先に発生させた乱数値１２．５で比較するのではなく、毎回乱数を発生させる。第２のリソースのための乱数値が１４であるとすると、１４＞１２．５となり、第２のリソースは採用されない。

なお、リソースの抽出確率Ｅｐは、初期値は５０％で試行が行われ、試行が行われるたびにリソース配置改善部２０６内の抽出確率Ｅｐの変更（図１６、ステップＳ１２０６〜ステップＳ１２０９参考）により更新され、０％＜抽出確率Ｅｐ≦１００％の間の値になる。

従来技術として、管理者が設定した条件を満たすリソースを選択しサーバを作成する方法に対し、本実施形態の方法では、未割り当てのリソースを無作為に抽出してサーバを作成し、作成されたサーバの性能をジョブによって評価している。このため、従来考えられなかったリソースの組み合わせができる可能性が多分にある。同様に、従来技術のひとつである演算による選択の場合にも、リソース選択について偶然性が入る余地はないが、本実施形態では、多分にリソース選択に偶然性が入る可能性がある。この点が本願発明の特徴のひとつとなっている。なお、無作為抽出の方法を実現する手段のひとつとして、乱数生成部２２１で発生した確率を用いているが、これに限定されるわけではない。

図３は、仮想サーバ、試行用仮想サーバを適用した物理サーバの構成を示す詳細図である。図４は、図３に示す仮想サーバ、試行用仮想サーバを適用した物理サーバとディスク装置との関係を示す詳細図である。物理サーバ１００ｃ（１００）は、メモリ１０１、プロセッサ１０２、ユーザＩ／Ｆ１０３、ネットワークＩ／Ｆ１０４、ディスクＩ／Ｆ１０５から構成されている。

メモリ１０１内には、仮想割り当て情報取得部３１３（図２３参照）を有する仮想化機構部１３１を有し、仮想化機構部１３１は、複数の仮想サーバ１３０（現用の仮想サーバ１３０ａ、ネットワーク上のサーバとして適用するか否かを試行するための試行用仮想サーバ１３０ｂが含まれる。）を有している。メモリ１０１のＯＳ（Operating System）３０１内には、比較情報取得部３１０（図２０参照）、サーバの関係情報取得部３１１（図２１参照）、リソース情報取得部３１２（図２３参照）を有する。

また、物理サーバ１００ｃには、複数のディスクボリューム１９０からなるストレージ装置１８０（図１参照）が接続されている。ディスクボリューム１９０には、仮想Ｉ／Ｏデバイス１７１（図４参照）を介して、複数の仮想ディスク１９１を有している。なお、ストレージ装置１８０（図１参照）は、サーバ内蔵型でもファイバーチャネルなどを介した外部装置でもよい。

仮想化機構部１３１は、管理サーバ２００のリソース配置改善部２０６（図２参照）からの指示で、プロセッサ１０２、メモリ１０１、仮想ディスク１９１、仮想Ｉ／Ｏデバイス１７１を仮想サーバ１３０ａ、試行用仮想サーバ１３０ｂに割り当てる。仮想サーバ１３０ａは、管理サーバ２００のリソース配置改善部２０６（図２参照）によって、仮想化機構部１３１の設定が変更されることにより、割り当てられているリソースが変更される。

試行用仮想サーバ１３０ｂは、管理サーバ２００の試行改善部２０８（図２参照）により、現用の仮想サーバ１３０ａと比較するために、リソース情報テーブル２１１（図７参照）の抽出確率Ｅｐに従って用意される仮想サーバである。

図５は、物理サーバ、試行用物理サーバの構成を示す詳細図である。図５には、図１で示した現用の物理サーバ１００a、ネットワーク上のサーバとして適用するか否かを試行するための試行用物理サーバ１００ｂの構成を示す。メモリ１０１のＯＳ３０１内には、比較情報取得部３１０（図２０参照）、サーバの関係情報取得部３１１（図２１参照）、リソース情報取得部３１２（図２３参照）を有する。

図６は、試行用物理サーバ、試行用仮想サーバが試行による改善で採用された際のリソースの再配置の関係を示す説明図である。図２を適宜参照して説明する。管理サーバ２００の情報収集部２１０（図１５参照）が未割り当てリソース群・割り当て済みリソース群の未使用部１０８を取得する。リソース配置改善部２０６が未割り当てリソース群・割り当て済みリソース群の未使用部１０８上に試行用物理サーバ１００ｂ、未割り当て仮想リソース群１０９上に試行用仮想サーバ１３０ｂを作成する。作成された試行用物理サーバ１００ｂと現用の物理サーバ１００ａとを性能比較し、同様に、作成された試行用仮想サーバ１３０ｂと現用の仮想サーバ１３０aとを性能比較する。そして、リソース配置改善部２０６が、作成された試行用物理サーバ１００ｂ、試行用仮想サーバ１３０ｂが採用と判定した場合、改善配置適用部２０９が割り当て済みリソース群の使用部１０６へ試行用物理サーバ１００ｂ、割り当て済み仮想リソース群１０７へ試行用仮想サーバ１３０ｂとそれらに割り当てられているリソースを移動し、現用の物理サーバ１００aと仮想サーバ１３０ａとそれらに割り当てられているリソースを、未割り当てリソース群・割り当て済みリソースの未使用部１０８に移動し、リソース配置の改善が行われる。

図６を用いて、本願の特徴を説明する。例えば、図６に示す現用の物理サーバ１００ａ、仮想サーバ１３０ａは、管理者が設定した条件を満たすリソースを選択し作成したサーバであるのに対し、試行用物理サーバ１００ｂ、試行用仮想サーバ１３０ｂは、無作為抽出によりリソースを選択しサーバを作成したサーバである。このため、試行用物理サーバ１００ｂは、ＣＰＵ（Central Processing Unit、プロセッサ）が２ＧＨｚを３個採用した構成であるが、現用の物理サーバ１００ａのＣＰＵが３ＧＨｚを２個採用した構成より、性能が向上することが偶然わかったことになる。このように、従来技術では、想定されるリソースの組み合わせで、所望する性能がでないことが多分にあるが、本実施形態では、管理者が予想していないリソースの組み合わせが実現できる。

次に、各種テーブルについて説明する。
図７は、リソース情報テーブルの一例および使用率グラフを示す説明図である。図７（ａ）はリソース情報テーブル２１１の一例を示し、図７（ｂ）は、リソース情報テーブル２１１の使用率グラフ７０７の例を示す。図７（ａ）に示すリソース情報テーブル２１１は、管理サーバ２００が保持しており、情報収集部２１０が収集した情報、ユーザＩ／Ｆ２０３からの入力情報を元に更新される。リソース情報テーブル２１１は、リソース名７０１、種類７０２、仮想関係７０３、論理・固有値設定７０４、物理位置７０５、割当状態７０６、使用率グラフ７０７、故障有無７０８、試行情報７０９、および抽出確率Ｅｐ（７１０）を含んで構成される。

具体的に説明すると、リソース名７０１が「ＦＣ１」の場合、種類７０２にはファイバチャネルデバイスであることを表す「ＦＣ」が格納される。仮想関係７０３には、仮想ＦＣデバイスの「仮想ＦＣ２」を提供している親デバイスである情報が格納される。論理・固有値設定７０４には外部ストレージの割り当てなどに使用する「ＷＷＮ（World Wide Name）情報」が格納される。物理位置７０５には「ＦＣ１」が搭載されている機器情報の「Ｉ／Ｏ拡張装置１」が格納される。割当状態７０６には現在割り当てられている「Ｓｒｖ１」、使用率グラフ７０７には過去の時間での使用率（ＦＣの場合は帯域）を記録した「Ｇｒａｐｈ１」、故障有無７０８にはユーザ指定や故障特定の試行によりこれまで故障と判断されなかったことを表す「無」、試行情報７０９には最後にそのリソースが対象になった試行の種類である「増設」（同じ改善ＩＤでの試行で重複した調査を防ぐために、その試行の何番目の調査対象リソースであったかを記録する回数が括弧内に記録される。）、抽出確率Ｅｐ（７１０）にはＦＣ１が各試行で割り当て可能リソースになっている時に、サーバ群生成部２２０で作成するサーバへの割り当てに使用される確率を表す。

抽出確率Ｅｐ（７１０）は、すでに説明したとおり、初期値は５０％が設定され、試行が行われる度にリソース配置改善部２０６内の抽出確率Ｅｐの変更の処理により更新される。抽出確率Ｅｐは、０％より大きい値から１００％の間の値になり、サーバ群生成部２２０でリソース使用の有無を決める確率である。

図７（ｂ）に示す使用率グラフは、例えば、ＣＰＵの使用率を示すグラフであり、時間経過に応じて使用率が変化していることを示している。

本実施形態では、サーバ群生成部２２０で作成するサーバへの割り当てに使用される確率とは、具体的には、リソース情報テーブル２１１にあるリソースに対し、抽出確率Ｅｐ（７１０）と、乱数生成部２２１で発生させた確率とを比較し、抽出確率Ｅｐが乱数生成部２２１で発生させた確率以上であれば、作成するサーバへ該当リソースを適用することを意味する。

図８は、改善リソース情報テーブルの一例を示す説明図である。改善リソース情報テーブル２１２は、管理サーバ２００が保持しており、リソース確保・試行改善部２０７（図２参照）が採用した試行用物理サーバ１００ｂ、試行用仮想サーバ１３０ｂの情報を元に更新される。改善リソース情報テーブル２１２は、リソース名８０１、種類８０２、仮想関係８０３、論理・固有値設定８０４、物理位置８０５、割当状態８０６、および故障有無８０８を含んで構成される。

図８に示すリソース名８０１、種類８０２、仮想関係８０３、論理・固有値設定８０４、物理位置８０５、割当状態８０６、および故障有無８０８は、図７に示すリソース名７０１、種類７０２、仮想関係７０３、論理・固有値設定７０４、物理位置７０５、割当状態７０６、および故障有無７０８に対応するものである。

図９は、履歴テーブルの一例を示す説明図である。履歴テーブル２１３は、情報収集部２１０（図２参照）がリソース情報を更新した日時であるリソース情報更新日時９０１、変更リソース数９０２、変更関係数９０３を含んで構成される。変更リソース数９０２は、リソース情報テーブル２１１が変更された頻度であり、変更関係数９０３は、サーバの関係テーブル２１４（図１０参照）が変更された頻度である。

リソース配置改善部２０６は、図１６のステップＳ１２０１の改善方法収集の処理で、履歴テーブル２１３を参照し、変更頻度が多い場合は試行によるリソース配置改善へ、頻度が少ない場合は演算によるリソース配置改善に改善方法を選択する際の参考にするとよい。

図１０は、サーバの関係テーブルの一例を示す説明図である。適宜図３、図５を参照して説明する。サーバの関係テーブル２１４は、情報収集部２１０が収集した情報、すなわち、サーバの関係情報取得部３１１、リソース情報取得部３１２、および仮想割り当て情報取得部３１３から得た情報、または、ユーザＩ／Ｆ２０３から入力された情報を元に作成される。サーバの関係テーブル２１４は、各サーバのサーバ名１００１、リソースを共用しているサーバを示すリソース共用１００２、相互通信をしているサーバを示す相互通信１００３、起動時間が同じようなサーバを示す起動時間１００４を含んで構成される。具体的には、サーバ名「Ｓｒｖ１」の場合、「Ｓｒｖ２」のサーバとリソースを共用し、「Ｓｒｖ３」のサーバと相互通信し、「Ｓｒｖ６」のサーバとほぼ同じような起動時間であることがわかる。

図１１は、ジョブ管理テーブルの一例を示す説明図である。ジョブ管理テーブル２１５は、試行改善部２０８（図２参照）が運用中の各サーバの比較を行うときに用いるジョブ内容のテーブルである。ジョブ管理テーブル２１５は、ジョブＩＤ１１０１、ジョブ内容１１０２、比較値１１０３、および比較に用いる判断方法１１０４を含んで構成される。

具体的に説明すると、ジョブ１の場合、ジョブＡを実行し、問題なく実行できれば採用」となる。ジョブ２の場合、ジョブＢを実行し、時間測定し、比較値である５秒よりも実行にかかる時間が短ければ採用となる。ジョブ３の場合、データ保存を実行し、保存できれば採用となる。ジョブ４の場合、ジョブＣを実行し、関係あるサーバ群全てで問題なく実行できれば採用となる。ジョブ５の場合、ＰＩＮＧなどの通信試験をし、関係あるサーバ群全てと通信できれば採用となる。ジョブ６の場合、アプリケーションプログラムを実行し、特定のアプリケーションプログラムがエラーなく動作できれば採用となる。ジョブ７の場合、メモリ負荷のジョブを実行し、負荷結果１よりも良い結果が記録されると採用となる。

図１２は、改善指定とジョブとの関係テーブルの一例を示す説明図である。改善指定とジョブとの関係テーブル２１８は、リソース配置改善する際に指定する改善指定１２０１とジョブＩＤ１２０２とを含んで構成される。図１２に示すジョブＩＤ１２０２と図１１に示すジョブＩＤ１１０１とは対応している。改善指定１２０１は、管理者が管理端末（図示していない）を介して指定すると、管理サーバ２００は、試行用物理サーバ１００ｂ、試行用仮想サーバ１３０ｂに対して、改善指定１２０１に対応するジョブＩＤ１２０２の実行をする。また、管理サーバ２００は、比較対象の現用の物理サーバ１００ａ、現用の仮想サーバ１３０ａに対しても同様に、改善指定１２０１に対応するジョブＩＤ１２０２の実行をする。すなわち、管理サーバ２００の試行改善部２０８が比較情報取得部３１０に対して指定し、その実行結果を取得することになる。

具体的には、「新規」が指定されるとジョブ１を実行し、図１１のジョブ管理テーブル２１５を参照して問題なく実行できるか否かが判断される。「改善」が指定されるとジョブ２を実行し、図１１のジョブ管理テーブル２１５を参照して、比較値よりも実行にかかる時間が短縮できるか否かを判断する。

図１３は、ジョブ結果管理テーブルの一例を示す説明図である。ジョブ結果管理テーブル２１６は、管理サーバ２００の試行改善部２０８が収集した情報によって更新され、比較情報取得部３１０が各改善ＩＤでのジョブを実行したリソースの組み合わせ、ジョブ、ジョブ結果履歴を保持する。ジョブ結果管理テーブル２１６は、改善ＩＤ１３０１、サーバ群１３０２、リソース１（１３０３）、リソース２（１３０４）、リソース３（１３０５）、リソース４（１３０６）、ジョブＩＤ１３０７、およびジョブ結果１３０８を含んで構成される。

具体的に説明すると、Ｔｅｓｔ１の場合、「Ｓｒｖ３」のサーバは、ＣＰＵ１、Ｍｅｍ１、ＨＤＤ１、ＬＡＮ１のリソースの組み合わせで構成されており、ジョブ３およびジョブ６が実行され、実行結果として、アプリケーション動作が成功していることがわかる。Ｔｅｓｔ２の場合、「ＶＳｒｖ２」の仮想サーバは、ＶＣＰＵ２、Ｖｍｅｍ２、ＶＨＤＤ２、ＶＦＣ２のリソースの組み合わせで構成されており、ジョブ２を実行したが時間切れなどで実行できなかったことがわかる。

図１４は、改善記録テーブルの一例を示す説明図である。改善記録テーブル２１７は、試行改善部２０８が試行による改善を行った際に、改善記録をするテーブルである。改善記録テーブル２１７は、改善ＩＤ１４０１、試行の種類を決める改善指定１４０２、管理対象のサーバ・リソース群全体の改善目標を格納する採用構成１４０３、情報収集ポリシー１４０４、改善の対象となるサーバ群１４０５、サーバ群の関係１４０６、成否１４０７、試行による改善を打ち切る目安の時間や繰り返し回数などの試行の超過判断１４０８、および試行の繰り返しの回数１４０９を含んで構成される。

具体的に説明すると、リソース配置改善部２０６が図１６のステップＳ１２０２における改善記録更新の処理で改善ＩＤ１４０１である「Ｔｅｓｔ１」が生成される。そののち、ステップＳ１２０１において選択情報収集の処理で、ユーザ（管理者も含む。）が、試行による改善として「保守」および「Ｓｒｖ３」で指定されていると、改善指定１４０２には「保守，Ｓｒｖ３」が格納される。改善指定１４０２の情報により、改善指定とジョブとの関係テーブル２１８（図１２参照）から、試行改善部２０８が、図１８のステップＳ１４０３において、比較情報取得部３１０の呼び出しの処理を行うと、比較情報取得部３１０に実行させるジョブが決まる。

採用構成１４０３は、ユーザ指定により「リソース最小」が格納される。採用構成１４０３の情報は、サーバ群生成部２２０が作成したサーバ群の中で、試行改善部２０８が図１８のステップＳ１４０４において現用のサーバと比較の処理で、改善したサーバが複数見つかった場合に選定のために使用される。

情報収集ポリシー１４０４は、ユーザからの指定（例えば、「定期」）で格納される。情報収集ポリシー１４０４は、情報収集部２１０が、次に、ステップＳ１１０１（図１５参照）において情報取得ポリシー設定の処理を行うとき自動設定してもよい。この場合、改善記録テーブル２１７の成否１４０７に「成功」がある改善のときに採用されていたポリシーを情報収集ポリシー１４０４の列から得て、採用する際に用いることが好ましい。

サーバ群１４０５には、改善指定１４０２でサーバの指定があった場合、サーバの関係テーブル２１４（図１０参照）から関係のあるサーバを格納し、リソースの指定があった場合、リソース情報テーブル２１１からそのリソースの割り当てられているサーバを特定してサーバの関係テーブル２１４から関係のあるサーバを格納する。図１４のＴｅｓｔ１の場合は、サーバの関係テーブル２１４の「Ｓｒｖ３」の行で関係が記載されている「Ｓｒｖ１，Ｓｒｖ２」が「Ｓｒｖ３」と共に格納される。

サーバ群１４０５の情報は、各部のサイジングや改善結果取得までの収束時間を早めるためなど、全体を通して使用される。改善配置の移行が失敗した場合などで、移行対象をサーバの関係テーブル２１４の情報を元に削っていく場合、サーバ群１４０５のサーバが削減される。

サーバ群の関係１４０６は、サーバ群１４０５にサーバを格納したときに参照したサーバの関係テーブル２１４の関係項目を記録する。図１４のＴｅｓｔ１の場合、サーバの関係テーブル２１４の「Ｓｒｖ３」の行に値が入っていた「相互通信」と「起動時間」が格納されている。

成否１４０７は、リソース配置改善部２０６が図１６のステップＳ１２１４の改善記録の成否更新の処理によって、この改善ＩＤ１４０１での改善が成功したか、失敗したかの情報が格納される。Ｔｅｓｔ１の場合は、超過判断１４０８の時間を越えてしまったため、試行改善部２０８が図１８のステップＳ１４０６の制限時間・回数の処理にて、「時間切れ（所要時間１０７ｈ）」と格納される。

超過判断１４０８は、ユーザ指定、デフォルト値の時間、または、回数が格納される。Ｔｅｓｔ１の場合、１００ｈ（１００時間）と設定されており、改善配置が１００ｈを超えても見つけられなかったため、試行改善部２０８の図１８のステップＳ１４０６の制限時間・回数の処理で時間切れと判断され、成否１４０７が「時間切れ」で更新されている。

さらに具体的に説明すると、図１４に示すＴｅｓｔ１の場合、管理サーバ２００は、「Ｓｒｖ３」の「保守」の試行を「定期」的に実行している。管理サーバ２００は、リソース群の組み合わせでサーバ群１４０５にある試行用物理サーバ「Ｓｒｖ１」，「Ｓｒｖ２」，「Ｓｒｖ３」を形成し、ジョブ３のデータ保存を試行しているが、保存できない結果となっていることがわかる。ただし、試行用物理サーバ１００ｂの群を現用の物理サーバ１００ａの群に移行する際、リソース不足があった場合、改善配置適用部２０９のステップＳ１５０６（図１９参照）で、移行対象とするサーバを減らし移行を実施する。詳細については後記する。

Ｔｅｓｔ２の場合、管理サーバ２００は、「ＶＳｒｖ１」の「改善」の試行を「監視」で実行している。管理サーバ２００は、リソース群の組合せでサーバ群１４０５にある実用の仮想サーバ「ＶＳｒｖ１」，「ＶＳｒｖ２」を形成し、ジョブ２のジョブＢ実行による時間測定を試行しているが、改善できていないことがわかる。なお、採用構成１４０３として「リソース集約」が指定されて、改善できるリソース配置が複数みつかった場合、物理位置が同じ場所のリソースが多く割り当てられている構成を採用することを意味する。

Ｔｅｓｔ３の場合、管理サーバ２００は、試行用物理サーバ「Ｓｒｖ５」を形成し、ジョブ４のジョブＣを実行し、成功していることがわかる。

Ｔｅｓｔ４の場合、管理サーバ２００は、試行用物理サーバの３台を形成し、ジョブ１のジョブＡを実行し、成功していることがわかる。

次に各処理フローについて説明する。
図１５は、情報収集部の処理を示すフローチャートである。適宜図２、図３、図５を参照して説明する。情報収集部２１０は、各サーバに配置したサーバの関係情報取得部３１１、リソース情報取得部３１２、および仮想割り当て情報取得部３１３からリソースの情報を収集する。管理サーバ２００が管理していないサーバの場合には、サーバの関係情報取得部３１１、リソース情報取得部３１２、および仮想割り当て情報取得部３１３を配置する処理をする。なお、所定のステップの処理（例えば、ステップＳ１１０２、ステップＳ１１０６）は、所要時間の許す限り行うものとし、規定、またはユーザ指定の時間に達した場合は、処理を切り上げ次の処理に進む。

情報収集部２１０は、ユーザＩ／Ｆ２０３からの入力値から、または、改善記録テーブル２１７（図１４参照）の成否列にある結果が成功する傾向にある情報収集ポリシー１４０４により、情報取得のためのポリシー（例えば、定期的に行うか、監視によって行うか）を設定する（ステップＳ１１０１）。設定されたポリシーに基づき、サーバの関係情報取得部３１１、リソース情報取得部３１２、および仮想割り当て情報取得部３１３がリソースの情報を収集する。

情報収集部２１０は、サーバを検出する（ステップＳ１１０２）。リソース情報取得部３１２とサーバの関係情報取得部３１１とが未適用、あるいは、情報取得ポリシーの更新が行われていないサーバを検出する。また、仮想サーバを適用するサーバに対しては、仮想割り当て情報取得部３１３が未適用の物理サーバ１００ｃ（図３参照）を検出する。

情報収集部２１０は、ステップＳ１１０２で検出したサーバに対し、各情報取得部を配置する（ステップＳ１１０３）。具体的には、情報収集部２１０が検出したサーバに、サーバの関係情報取得部３１１、リソース情報取得部３１２、および必要なら仮想割り当て情報取得部３１３を、ステップＳ１１０１における設定を反映して、プッシュインストールする。なお、プッシュインストールとは、管理サーバ２００がネットワーク上の対象とするサーバを遠隔操作して必要なソフトウェアなどをインストールすることをいう。

情報収集部２１０は、ステップＳ１１０１で設定されたポリシーを判断し（ステップＳ１１０４）、リソース監視の場合（ステップＳ１１０４、監視検出）、ステップＳ１１０６へ、定期的に行う設定の場合（ステップＳ１１０４、定期検出）、ステップＳ１１０５に進む。

ステップＳ１１０５において、情報収集部２１０は定期取得する。情報収集部２１０は、リソース情報取得部３１２、サーバの関係情報取得部３１１、および仮想割り当て情報取得部３１３から定期的に送られてくる情報を受ける。

ステップＳ１１０６において、情報収集部２１０は取得部からの応答待ちをする。情報収集部２１０は、リソース情報取得部３１２、サーバの関係情報取得部３１１、および仮想割り当て情報取得部３１３から随時送られてくる情報を受ける。

情報収集部２１０は、ステップＳ１１０５、ステップＳ１１０６で取得した情報を元に、リソース情報テーブル２１１（図７参照）およびサーバの関係テーブル２１４（図１０参照）を更新する（ステップＳ１１０７）。

情報収集部２１０は、履歴テーブル２１３（図９参照）を更新する（ステップＳ１１０８）。情報収集部２１０は、ステップＳ１１０７において更新した日時と、いくつのリソースの情報が更新されたかを、履歴テーブル２１３に記録し、ステップＳ１１０１に戻る。

図１６は、リソース配置改善部の処理を示すフローチャートである。図１６は、リソース配置改善部２０６の処理の詳細を表している。リソース配置改善部２０６は、改善指示を受けると、改善方法を収集する（ステップＳ１２０１）。具体的には、リソース配置改善部２０６は、履歴テーブル２１３（図９参照）のリソース情報更新日時９０１、変更リソース数９０２、変更サーバの変更関係数９０３を確認する。また、リソース情報テーブル２１１（図７参照）の使用率グラフから全リソースの運用が止められる期間の有無を調査する。ユーザＩ／Ｆ２０３から改善方法に指定があるか確認する。

リソース配置改善部２０６は、改善記録を更新する（ステップＳ１２０２）。リソース配置改善部２０６は、改善記録テーブル２１７（図１４参照）に新規の改善ＩＤの行を作成し、ステップＳ１２０１で確認した改善指定（例えば、演算か試行か）、採用基準（採用構成１４０３に対応）を格納する。ステップＳ１２０１で変更リソース数９０２（図９参照）が規定値以下、または、全リソースの運用停止期間が有る場合で、かつ、ユーザから指定がなければ改善指定に演算を格納する。

図１６においては、改善指定において試行の場合、新規・改善・保守・増設・削減・故障特定に限定して説明する。また、ユーザが対象サーバを指定した場合はサーバ名も含む。採用基準については、ユーザの指定によりリソース最小（もっとも使用リソースが少なくなる構成を目指す）、リソース集約（各サーバの割り当てリソースの物理位置が近くなる構成を目指す）、リソース分散（各サーバの割り当てリソースの物理位置が広く分布する構成を目指す）などが格納される。なお、新規とは改善ではなく、新しいサーバをユーザの要求にしたがって構築する場合を指す。

リソース配置改善部２０６は、改善方法を判別する（ステップＳ１２０３）。リソース配置改善部２０６は、改善記録テーブル２１７（図１４参照）を参照して、ステップＳ１２０２で作成した改善ＩＤの改善指定１４０２に従い、演算であれば（ステップＳ１２０３、演算）、ステップＳ１２０４へ進み、試行であれば（ステップＳ１２０３、試行）、ステップＳ１２０５へ進む。

ステップＳ１２０４において、リソース配置改善部２０６は、公知例（国際公開番号ＷＯ２００８−１３２９２４）などに従って演算による最適化改善処理を行う。改善後の演算結果とリソース配置情報で、改善記録テーブル２１７（図１４参照）・改善リソース情報テーブル２１２（図８参照）を更新する。

具体的には、管理サーバ２００は、アプリケーションやデバイスの性能、設定といった情報を効用関数のパラメータとして扱い、リソースの配置改善が見られる傾向にしたがって、関数の調整と、解の導出を繰り返し、計算によって最適なパラメータ値(最適な配置情報も含む)を求める。そして、パラメータの把握が容易なリソース群に対しては、改善されたリソース配置を導出し、リソース配置を導出ができた場合、その情報を元にリソース配置を行うため、改善リソース情報テーブル２１２（図８参照）を更新する。また、改善記録テーブル２１７（図１４参照）は、次回の改善時に改善方法(演算か試行か)を選択する際に使用される情報であるので、管理サーバ２００は、演算による改善の成否を改善記録テーブル２１７（図１４参照）に記録する。

ステップＳ１２０５において、リソース配置改善部２０６は、試行内容である新規・改善・保守・増設・削減・故障特定を判別し、次のステップ（ステップＳ１２０６〜Ｓ１２０９）へ進む。次のステップは、リソース情報テーブル２１１（図７参照）の抽出確率Ｅｐを調整する分岐処理である。

ステップＳ１２０６において、新規／改善／サーバ指定の場合、抽出確率Ｅｐを変更する処理（１）が実行される。リソース情報テーブル２１１（図７参照）の使用率グラフから使用率に応じて同テーブル内の抽出確率Ｅｐを今回の改善ＩＤの試行の間、次のように変更する。

割り当てリソースの片寄を行いたい場合は、使用率の高いリソースの抽出確率Ｅｐを上げ、使用率の低いリソースの抽出確率Ｅｐを下げる。分散させたい場合は逆にする。また、改善記録テーブル２１７（図１４参照）の成否１４０７の列に成功情報があり、今回の改善ＩＤのサーバ群列・群のサーバの関係列の内容と類似（同じサーバ数、同じサーバの関係など）している改善ＩＤの所要時間・所用回数が小さい試行が有った場合、そのサーバ群の使用しているリソースを、リソース情報テーブル２１１（図７参照）で特定して、リソースの抽出確率Ｅｐを上げ、収束が早くなる工夫を行うとよい。そして、ステップＳ１２１０に進む。

なお、リソース情報テーブル２１１（図７参照）の試行情報７０９の列にある括弧書きの数値は、同じ改善ＩＤでの試行で重複した調査を防ぐために、その試行の何番目の調査対象リソースであったかを記録する回数である。

ステップＳ１２０７において、保守の場合、抽出確率Ｅｐを変更する処理（２）が実行される。リソース配置改善部２０６は、リソース情報テーブル２１１（図７参照）から特定されたユーザ指定の保守サーバ内のリソースについて、リソース情報テーブル２１１の試行情報７０９の列の値を「保守」に変更する。また、「保守」となったリソースの抽出確率Ｅｐを下げ、それ以外のリソースの抽出確率Ｅｐは上げる。そして、ステップＳ１２１２に進む。

ステップＳ１２０８において、増設／削減（増減）の場合、抽出確率Ｅｐを変更する処理（３）が実行される。リソース配置改善部２０６は、無作為、あるいは、事前にユーザに指定されたリソースについて、リソース情報テーブル２１１（図７参照）の試行情報７０９の列を「増設（＃）」「削減（＃）」に変更する。なお、括弧内の番号（＃）は、全リソースに対して調査を行ったか判別するために使用される。増設となっているリソースは抽出確率Ｅｐを上げ、それ以外のリソースの抽出確率Ｅｐは下げる。削減となっているリソースは抽出確率Ｅｐを下げ、それ以外のリソースの抽出確率Ｅｐは上げる。そして、ステップＳ１２１２に進む。

ステップＳ１２０９において、故障特定の場合、抽出確率Ｅｐを変更する処理（４）が実行される。リソース配置改善部２０６は、事前のユーザ入力、管理ソフトウェアから受け取った障害情報、または、前回の故障特定の試行においてステップＳ１２１６において、リソース情報テーブル２１１（図７参照）の故障有無７０８の列が「有」にされたリソースと同じ物理位置のリソースの試行情報を「故障（＃）」とし、リソースの抽出確率Ｅｐを上げ、その他のリソースについては抽出確率Ｅｐを下げる。特に選択に用いる情報が無ければ無作為にリソースを選択し、そのリソースを含む同じ物理位置のリソースの試行情報を「故障（＃）」とし、リソースの抽出確率Ｅｐを上げる。そして、ステップＳ１２１２に進む。

ステップＳ１２１０において、リソース配置改善部２０６は、試行が新規か改善かサーバ指定かを判別し、新規であれば（ステップＳ１２１１，新規）、改善記録テーブル２１７（図１４参照）を、デフォルト値、ユーザ入力値で作成し（ステップＳ１２１１）、ステップＳ１２１３に進む。改善／サーバ指定の場合、ステップＳ１２１２に進む。

ステップＳ１２１２において、リソース配置改善部２０６は、サーバの関係や指定されたサーバ情報で、改善記録テーブル２１７を作成する。指定されたサーバやリソースが有る場合は、リソース配置改善部２０６が、サーバの関係テーブル２１４（図１０参照）からそのサーバやリソースとサーバの関係の強いサーバ同士を選択し、改善記録テーブル２１７のサーバ群１４０７の列に記録する。同じ改善ＩＤでの処理で再度選択するときは、改善記録テーブル２１７（図１４参照）の履歴から選択したことのある群にはならないように選択する。

リソース配置改善部２０６は、リソース確保・試行改善部２０７（図１７参照）を呼び出し（ステップＳ１２１３）、改善記録テーブル２１７（図１４参照）の成否１４０７の列を更新する（ステップＳ１２１４）。制限時間・回数を超過している場合は、成否１４０７の列を所要時間・回数情報とともに「失敗」に更新する。

それ以外の処理は、改善記録テーブル２１７（図１４参照）の改善指定１４０２の列の値で異なる。

（１）新規・改善の場合：
改善リソース情報テーブル２１２（図８参照）の全てのサーバに、リソースの割り当てが済んでいる場合、改善記録テーブル２１７（図１４参照）の成否１４０７の列に所要時間・回数情報とともに「改善」と格納する。

（２）保守の場合：
リソース情報テーブル２１１（図７参照）の試行情報７０９の列の値が「保守」になっているリソース全てで、割当状態７０６の列に割り当てられているサーバが無くなっている場合、改善記録テーブル２１７（図１４参照）の成否１４０７の列に所要時間・回数情報とともに「保守対応可」と格納する。すなわち、リソースがどのサーバにも割り当てられていない状態を意味する。

（３）増設／削減の場合：
リソース情報テーブル２１１（図７参照）の試行情報７０９の列が「増設」になっているリソースの使用率が１００％またはユーザ指定の値以上である場合、改善記録テーブル２１７（図１４参照）の成否１４０７の列を所要時間・回数情報とともに「増設可」にする。同様に、リソース情報テーブル２１１（図７参照）の試行情報７０９の列が「削減」になっているリソースの使用率が０％またはユーザ指定の値以下である場合、改善記録テーブル２１７（図１４参照）の成否１４０７の列を所要時間・回数情報とともに「削減可」にする。

本実施形態では、リソースの使用率が１００％またはユーザ指定の値以上である場合、リソースの増設を推奨する旨を改善記録テーブル２１７（図１４参照）に記録することができる。同様に、リソースの使用率が０％またはユーザ指定の値以下である場合、リソースの削除を推奨する旨を前記改善記録テーブル２１７に記録することができる。

試行情報７０９内の括弧内の番号（＃）が最後になっている場合、成否１４０７の列を所要時間・回数情報とともに「増設不可」または「削減不可」にする。番号（＃）は、全リソースに対して調査を行ったか判別するために使用される。図７に示すＦＣ１の行の試行情報７０９は、改善指定が「増設」の判定で２番目に、ＬＡＮ２の行の試行情報内７０９は、「故障」の判定で１番目に調査対象として選ばれたという履歴を表す。

（４）故障特定の場合
リソース情報テーブル２１１（図７参照）の試行情報７０９の列の値が「故障」となっているリソースの割当状態７０６列に情報が格納されていない場合、ユーザに故障の可能性があるリソースとして、改善記録テーブル２１７（図１４参照）の成否１４０７の列に所要時間・回数情報とともに「故障（リソース名）」を格納する。他方、リソースの割当状態７０６の列に情報が格納されており、試行情報７０９内の＃が最後になっている場合、改善記録テーブル２１７（図１４参照）の成否１４０７の列に所要時間・回数情報とともに「故障無し」と格納する。

リソース配置改善部２０６は、採用判定をする（ステップＳ１２１５）。改善記録テーブル２１７（図１４参照）の成否１４０７の列が空欄の場合（ステップＳ１２１５，再試行）、ステップＳ１２０５へ戻る。改善記録テーブル２１７の成否１４０７の列が「失敗」、「増設可」、「削減可」、「増設不可」、「削減不可」、「故障（リソース名）」、「故障無し」の場合（ステップＳ１２１５，試行終了）、ステップＳ１２１６へ進む。改善記録テーブル２１７の成否１４０７の列が「改善」の場合（ステップＳ１２１５，採用）、ステップＳ１２１７へ進む。

ステップＳ１２１６において、リソース配置改善部２０６は、ユーザに通知をする。「失敗」、「増設可」、「削減可」、「増設不可」、「削減不可」、「故障（リソース名）」、「故障無し」に応じた情報をユーザに提示し、リソース情報テーブル２１１（図７参照）を更新する。例えば、「故障」の場合は、リソース情報テーブル２１１の故障７０８の列を「有」にし、「故障無し」の場合は「無」にする。

ステップＳ１２１７において、リソース配置改善部２０６は、改善配置適用部２０９（図１９参照）を呼び出し、改善配置を実行し、ステップＳ１２０１に戻る。

本実施形態では、管理サーバ２００は、例えば、ジョブの判断方法を満たさない回数が所定回数を超えた場合、または、ジョブの判断方法を満たさない試行時間が所定時間を超えた場合、リソース配置の改善ができない旨を管理者に通知することができる。

図１７は、リソース確保・試行改善部の処理を示すフローチャートである。図１７は、リソース確保・試行改善部２０７の処理の詳細を表している。なお、所定のステップの処理（例えば、ステップＳ１３０１）は、所要時間の許す限り行うものとし、規定、またはユーザ指定の時間に達した場合は、処理を切り上げ次の処理に進む。

リソース確保・試行改善部２０７は、現用のサーバ群の比較情報取得部３１０を呼び出し、所定のジョブで性能を測定し、リソース情報テーブル２１１（図７参照）から該当するリソースの使用率を可能な範囲で調査する（ステップＳ１３０１）。具体的には、リソース確保・試行改善部２０７は、改善記録テーブル２１７（図１４参照）のサーバ群１４０５の列のサーバに割り当てられているリソースの性能を、テストに必要なジョブを改善指定１４０２および改善指定とジョブとの関係テーブル２１８（図１２参照）に基づいて特定する。そして、そのサーバ群１４０５に指定されたサーバに対し、比較情報取得部３１０を呼び出し、ジョブの結果を収集し、ジョブ結果管理テーブル２１６（図１３参照）を更新する。また、リソースの使用率は、リソース情報テーブル２１１（図７参照）の使用率グラフ７０７から収集する。

リソース確保・試行改善部２０７は、リソース情報テーブル２１１（図７参照）に基づき、未割り当てとなっているリソースを試行用リソースとして確保する（ステップＳ１３０２）。試行用リソースを確保する際、改善記録テーブル２１７（図１４参照）の今回の改善ＩＤの超過判断に格納されている時間（例えば、１００ｈ（１００時間））、確保することを試みる。また、過去の実績として、リソース情報テーブル２１１（図７参照）の使用率グラフに、変動がないリソースは、その未使用部分を、試行用リソースとして確保する。

また、改善記録テーブル２１７（図１４参照）で、サーバ群１４０５のサーバの関係の情報が類似（同じサーバ数、同じサーバの関係、など）しており、成否１４０７の列に成功情報が格納されている改善ＩＤがある場合は、成否１４０７の列にある所要時間だけ、過去の実績として、リソース情報テーブル２１１（図７参照）の使用率グラフに、変動がないリソースは、その未使用部分を、試行用リソースとして確保する。

リソース確保・試行改善部２０７は、試行改善部２０８（図１８参照）を呼び出し（ステップＳ１３０３）、ステップＳ１３０２で確保したリソースで、試行改善できるか否かの処理を行う。

リソース確保・試行改善部２０７は、改善リソース情報テーブル２１２（図８参照）を参照し、改善記録テーブル２１７（図１４参照）のサーバ群に改善後のリソース割り当てが行われているかについての改善リソース情報調査を行う（ステップＳ１３０４）。

リソース確保・試行改善部２０７は、改善されているか否かの判定を行う（ステップＳ１３０５）。リソース確保・試行改善部２０７は、ステップＳ１３０４における改善リソース情報調査で、改善記録テーブル２１７（図１４参照）のサーバ群の全てに、改善リソース情報テーブル２１２（図８参照）でリソースが割り当てられていた場合（ステップＳ１３０５，改善）、処理を終了し、割り当てられていなかった場合（ステップＳ１３０５、改善無し）、ステップＳ１３０６へ処理を進む。

リソース確保・試行改善部２０７は、集約調査として、リソースの使用率とジョブ結果管理テーブル（図１３参照）から処理の集約可能なリソースを特定する（ステップＳ１３０６）。すなわち、リソース確保・試行改善部２０７は、ジョブ結果管理テーブル２１６（図１３参照）のジョブＩＤ１３０７とジョブ結果１３０８からジョブに対する結果が同じ、または、同等のリソースの組み合わせを持つサーバを見つけ出し、リソース情報テーブル２１１（図７参照）の使用率グラフ７０７を参照し、過去においてグラフの和が１００％を超える事が無かったかを確認する。過去において超えることが無かった場合、比較したリソースを使用しているサーバはどちらかのリソース上に集約可能とする。

リソース確保・試行改善部２０７は、集約可能か判断し（ステップＳ１３０７）、集約可能なサーバが有る場合（ステップＳ１３０７，集約可）、ステップＳ１３０８に進み、集約可能なサーバが見つけられなかった場合（ステップＳ１３０７，集約不可）、集約不可として処理を終了する。

ステップＳ１３０８において、ステップＳ１３０６の集約調査において、リソース確保・試行改善部２０７は、集約可能と判明したサーバを集約させる。すなわち、同リソース上に同居させ、未割り当てリソースを増やすようにするとよい。

図１８は、試行改善部の処理を示すフローチャートである。試行改善部２０８は、サーバ群を生成（作成）し、作成したサーバ群に比較情報取得部３１０を配置し、試行のジョブで、現用のサーバ群と作成した試行用サーバ群とで性能比較し、サーバ群の改善があるか否かの判定処理などを行う。

試行改善部２０８は、サーバ群生成部２２０（図２４参照）を呼び出し（ステップＳ１４０１）、作成したサーバ群に比較情報取得部３１０を配置する（ステップＳ１４０２）。すなわち、サーバ群生成部２２０で作成した各試行用サーバ群に、比較情報取得部３１０をプッシュインストールする。

試行改善部２０８は、現用のサーバ群と、試行用サーバ群との比較情報取得部を呼び出す（ステップＳ１４０３）。具体的には、改善記録テーブル２１７（図１４参照）で今回の改善ＩＤに対応した改善指定１４０２の列とサーバ群１４０５の列から、改善指定とジョブとの関係テーブル２１８（図１２参照）に基づいてジョブを特定し、各試行用サーバ群上で比較情報取得部３１０がジョブを実行し、ジョブの実行後に回収した結果を、ジョブ結果管理テーブル２１６（図１３参照）へ格納する。

試行改善部２０８は、ジョブ結果管理テーブル２１６（図１３参照）にある現用のサーバ群と各試行用サーバ群のジョブ結果について、ジョブ管理テーブル２１５（図１１参照）の判断方法１１０４の列の情報と、改善記録テーブル２１７（図１４参照）の採用構成１４０３の列の情報を元に比較（ジョブの実行時間が短縮され、かつ、リソース使用量が減るか、など）し（ステップＳ１４０４）、採用か不採用かを決める。採用の場合は、改善リソース情報テーブル２１２（図８参照）に試行用サーバのリソース配置情報を格納する。また、採用の際に、ジョブ管理テーブル２１５（図１１参照）の判断方法に応じて比較値を更新することも可能である。

試行改善部２０８は、ステップＳ１４０４の比較結果、全ての試行用サーバ群が採用となった場合（ステップＳ１４０５，未改善サーバ無し）、処理を終了し、不採用があった場合（ステップＳ１４０５，未改善サーバ有り）、ステップＳ１４０６へ進む。

ステップＳ１４０６において、試行改善部２０８は、制限時間や回数が改善記録テーブル２１７（図１４参照）の超過判断１４０８の列の内容以上になっている場合（ステップＳ１４０６、以上）、処理を終了し、超えていない場合（ステップＳ１４０６，未達）、ステップＳ１４０１に戻る。

具体的に説明すると、図１４のＴｅｓｔ１の場合、現用のサーバ群である「Ｓｒｖ１」，「Ｓｒｖ２」，「Ｓｒｖ３」に対し、試行用サーバ群である「Ｓｒｖ１」，「Ｓｒｖ２」，「Ｓｒｖ３」を生成し、現用のサーバ「Ｓｒｖ１」と試行用サーバ「Ｓｒｖ１」の比較、現用のサーバ「Ｓｒｖ２」と試行用サーバ「Ｓｒｖ２」の比較、現用サーバ「Ｓｒｖ３」と試行用サーバ「Ｓｒｖ３」の比較を行い、これら全ての比較で、改善された結果を得られるようになるまで、試行用サーバ群を生成し、現用のサーバ群と試行用サーバ群との性能比較を繰り返すとよい。試行用サーバ群の性能が現用のサーバ群の性能と比較して改善している場合、試行用サーバ群をネットワーク上のサーバとして適用する。

図１９は、改善配置適用部の処理を示すフローチャートである。改善配置適用部２０９は、過去のリソースの使用率の傾向から将来的に移行できるか、リソースの使用率面積分で移行調査する（ステップＳ１５０１）。改善配置適用部２０９は、改善リソース情報テーブル２１２（図８参照）の移行先リソースと、改善記録テーブル２１７（図１４参照）のサーバ群１４０５のサーバに割り当てられている同種のリソースとについて、リソース情報テーブル２１１（図７参照）のリソースの使用率グラフ７０７に基づいて面積分し、その差を比較する。改善前後のサーバ（現用のサーバと試行用サーバ）で取得したジョブ結果管理テーブル２１６（図１３参照）のジョブ結果１３０８の列の結果に差があるときは、面積比較時にその差を考慮するため、面積値に性能差に基づく比率をかける。例えば、通信速度を測るジョブだった場合は、使用率の面積分にその速度比をかけた値を比較の数値にする。

具体的に説明すると、ジョブ結果管理テーブル２１６（図１３参照）で同じジョブＩＤと比較可能な結果を持つリソースだった場合、その結果を面積値に反映させ比較することになる。ＬＡＮ１の使用率グラフ面積分が「５０（２４ｈの％合計）」、ＬＡＮ２の使用率グラフの空き部分の面積分「３０（２４ｈの％合計）」であったとする。この場合において、ＬＡＮ１とＬＡＮ２との性能差があり、ＬＡＮ２の性能がＬＡＮ１の性能の５／３倍以上であった場合、ＬＡＮ２上の仮想ＬＡＮやＬＡＮ２使用中の他サーバと交互切替え使用であれば、ＬＡＮ１の移行先にできると判断する。

改善配置適用部２０９は、ステップＳ１５０１の面積分の差から移行できるか否かを判断し（ステップＳ１５０２）、面積分の差が移行先リソースの全てで現リソースより使用率グラフの面積分が小さい場合（ステップＳ１５０２，移行）、ステップＳ１５０３へ進み、どれか一つでも大きい場合（ステップＳ１５０２，移行対象変更）、ステップＳ１５０４へ進む。

ステップＳ１５０４において、改善配置適用部２０９は、サーバの関係を判断し（ステップＳ１５０４）、改善記録テーブル２１７（図１４参照）のサーバ群の関係１４０６の列に値がない場合（ステップＳ１５０４，関係無し）、ステップＳ１５０５に進み、値が有る場合（ステップＳ１５０５，関係有り）、ステップＳ１５０６に進む。

ステップＳ１５０６において、改善配置適用部２０９は、サーバ群の変更の処理を行う。具体的には、サーバ群１４０５（図１４参照）の列に示すサーバ群は、サーバ群の関係１４０６の列に記載されている情報を元に、図１０に示すサーバの関係テーブル２１４から、論理和で決定される。このため、サーバ群の関係１４０６の列から項目が減ることにより、サーバ群１４０５の列の内容にあるサーバの数も減る。また、図１０のサーバの関係テーブル２１４から包含関係が見出せる場合は、サーバ数が減少する方のサーバの関係にサーバ群の関係１４０６の列の内容を変更することで、サーバ群１４０５の列の内容にあるサーバ数を減らし、移行可能なサイズへの変更を試みる。

ステップＳ１５０３において、改善配置適用部２０９は、改善リソース情報テーブル２１２（図８参照）に従い、移行を進める。移行後はリソース情報テーブル２１１（図７参照）に割り当てられているリソースの割当状態７０６を更新する。

ステップＳ１５０５において、抽出確率Ｅｐの変更または移行不可情報を更新する。改善リソース情報テーブル２１２（図８参照）に残っているサーバの構成で割り当てられており、ステップＳ１５０１において面積分の差から移行不可であれば、改善記録テーブル２１７（図１４参照）の成否１４０７の列を所要時間・回数情報とともに「移行不可」に更新する。また、該当するリソースに対し、リソース情報テーブル２１１（図７参照）の抽出確率Ｅｐを下げる。または、増設したほうがよい増設推奨リソースとしてユーザに通知するとよい。

図２０は、比較情報取得部の処理を示すフローチャートである。比較情報取得部３１０は、管理サーバ１００から送付されたジョブを取得すると（ステップＳ１６０１）、取得したジョブを実行し（ステップＳ１６０２）、ジョブ管理テーブル２１５（図１１参照）の判断方法１１０４に必要なジョブ結果を、管理サーバ１００の試行改善部２０８へ送信し（ステップＳ１６０３）、処理を終了する。

図２１は、サーバの関係情報取得部の処理を示すフローチャートである。サーバの関係情報取得部３１１は、管理サーバ２００の情報収集部２１０によりプッシュインストールされた際に設定されたポリシーを判断し（ステップＳ１７０１）、定期の場合（ステップＳ１７０１，定期）、ステップＳ１７０２に進み、監視の場合（ステップＳ１７０１，監視）、ステップＳ１７０４に進む。

ステップＳ１７０２において、サーバの関係情報取得部３１１は、サーバの関係テーブル２１４（図１０参照）にある項目の内容を、ＯＳや管理ソフトウェアの持つそのサーバのデバイス情報から情報を取得する。そして、サーバの関係情報取得部３１１は、管理サーバ２００の情報収集部２１０へ、取得した情報を送信し（ステップＳ１７０３）、ステップＳ１７０１に戻る。次に、ステップＳ１７０１を実行する際は、予め設定されている時間経過後に実行する。

ステップＳ１７０４において、サーバの関係情報取得部３１１は、サーバの関係テーブル２１４（図１０参照）の情報に含まれる項目について変更が無いか監視し、変更の有無を判断する（ステップＳ１７０５）。変更があった場合（ステップＳ１７０５，有）、ステップＳ１７０２に進み、変更がない場合（ステップＳ１７０５，無）、ステップＳ１７０１に戻る。

図２２は、リソース情報取得部の処理を示すフローチャートである。リソース情報取得部３１２は、管理サーバ２００の情報収集部２１０によりプッシュインストールされた際に設定されたポリシーを判断し（ステップＳ１８０１）、定期の場合（ステップＳ１８０１，定期）、ステップＳ１８０２に進み、監視の場合（ステップＳ１８０１，監視）、ステップＳ１８０４に進む。

ステップＳ１８０２において、リソース情報取得部３１２は、リソース情報テーブル２１１（図７参照）にある項目の内容をＯＳや管理ソフトウェアの持つそのサーバのデバイス情報から情報を取得する。そして、リソース情報取得部３１２は、管理サーバ２００の情報収集部２１０へ取得した情報を送信し（ステップＳ１８０３）、ステップＳ１８０１に戻る。次に、ステップＳ１８０１を実行する際は、予め設定されている時間経過後に実行する。

ステップＳ１８０４において、リソース情報取得部３１２は、リソース情報（例えば、リソースの追加や削減）を監視し、変更の有無を判断する（ステップＳ１８０５）。変更があった場合（ステップＳ１８０５，有）、ステップＳ１８０２に進み、変更がない場合（ステップＳ１８０５，無）、ステップＳ１８０１に戻る。

図２３は、仮想割り当て情報取得部の処理を示すフローチャートである。仮想割り当て情報取得部３１３は、管理サーバ２００の情報収集部２１０によりプッシュインストールされた際に設定されたポリシーを判断し（ステップＳ１９０１）、定期の場合（ステップＳ１９０１，定期）、ステップＳ１９０２に進み、監視の場合（ステップＳ１９０１，監視）、ステップＳ１９０４に進む。

ステップＳ１９０２において、仮想割り当て情報取得部３１３は、リソース情報テーブル２１１（図７参照）とサーバの関係テーブル２１４（図１０参照）にある項目の内容を仮想化機構部のリソース割り当て情報から情報を取得する。そして、仮想割り当て情報取得部３１３は、管理サーバ２００の情報収集部２１０へ、取得した情報を送信し（ステップＳ１９０３）、ステップＳ１９０１に戻る。次に、ステップＳ１９０１を実行する際は、予め設定されている時間経過後に実行する。

ステップＳ１９０４において、仮想割り当て情報取得部３１３は、仮想化機構の各仮想マシンへの仮想割り当て情報を監視し、変更の有無を判断する（ステップＳ１９０５）。変更があった場合（ステップＳ１９０５，有）、ステップＳ１９０２に進み、変更がない場合（ステップＳ１９０５，無）、ステップＳ１９０１に戻る。

図２４は、サーバ群生成部の処理を示すフローチャートである。サーバ群生成部２２０（図２参照）は、ステップＳ１３０２（図１７参照）で確保した各試行用のリソースに対し、リソース情報テーブル２１１（図７参照）の抽出確率Ｅｐ（７１０）に基づいて、リソース情報テーブル２１１にある全て、または、一定範囲のリソース１つずつに対して、乱数生成部２２１（図２参照）で乱数を生成させ、今回のサーバ群生成部２２０内でサーバに割り当てるリソースとして使用するか、使用しないかを決定し抽出する（ステップＳ２００１）。なお、リソースの抽出方法として、ステップＳ２００１が本実施形態の特徴のひとつである。

サーバ群生成部２２０は、今回の改善ＩＤに対応した改善記録テーブル２１７（図１４参照）のサーバ群に格納されている現用のサーバの割り当てリソース情報（リソース情報テーブル２１１（図７参照）の割当状態７０６の列から把握する。）から作成するサーバ群のサーバ毎に割り当てるリソース個数を決定する（ステップＳ２００２）。なお、割り当てる個数については現在の割り当てリソースの数を既定値とし、確率的にゆらぎを入れることでそこから増減を行うことも可能である。

サーバ群生成部２２０は、改善記録テーブル２１７（図１４参照）のサーバ群のサーバ数だけ、ステップＳ２００１で抽出したリソースからサーバ群を生成する（ステップＳ２００３）。具体的には、サーバ群生成部２２０は、改善記録テーブル２１７（図１４参照）の今回の改善ＩＤに対応した改善指定１４０２の列、サーバ群の関係１４０６の列を参照し、改善指定のリソース、共用リソースとして、改善の際に要求されているリソースの指定を満たして、ステップＳ２００１で抽出したリソースを割り当てる。そのほかに、各サーバの割り当てるリソース数は、ステップＳ２００２によって決まった個数を参考にすることも可能である。また、ステップＳ２００１で抽出したリソース数が要求されているリソース数に届かなかった場合は、処理を終了し、試行改善部２０８の処理をやり直すとよい。

本実施形態によれば、管理サーバ２００は、計算機システムをなす複数のサーバが接続されるネットワークから確保できるリソースを組み合わせて形成する試行用サーバを計算機システムのサーバとして適用した際の適用情報の実績である抽出確率Ｅｐが登録されるリソース情報（例えば、リソース情報テーブル２１１）の記憶部と、試行用サーバを採用するか否かの所定条件であるジョブの判断方法をジョブごとに管理するジョブ管理情報（例えば、ジョブ管理テーブル２１５）が記憶されるジョブ管理情報の記憶部と、リソース情報の各リソースに対し、抽出確率が乱数生成部２２１で発生させた乱数確率Ｒｐ以上であれば、試行用のリソースとして選定し、選定された試行用のリソースを組み合わせて試行用サーバを形成する形成処理部と、形成された試行用サーバを用いてジョブを実行し、ジョブの実行結果がジョブの判断方法を満たせば、試行用サーバを該ネットワークのサーバとして適用する適用処理部と、を有する。なお、形成処理部および適用処理部は、プロセッサ２０２を機能別の処理部として表現したものである。

本実施形態によれば、管理サーバ２００は、リソース情報テーブル２１１の各リソースに対し、リソースごとの抽出確率Ｅｐが乱数生成部２２１で発生させた乱数確率Ｒｐ以上であれば、試行用のリソースとして選定し、選定されたリソースを組み合わせて試行用サーバ（例えば、試行用物理サーバ１００ｂ、試行用仮想サーバ１３０ｂ）を形成し、形成された試行用サーバを用いてジョブを実行し、ジョブの実行結果がジョブの判断方法を満たせば、試行用サーバを該ネットワーク上のサーバとして適用することができる。これにより、ネットワーク上のリソースを有効に活用することができる。

１００ 物理サーバ
１３０ 仮想サーバ
１３１ 仮想化機構部
１４０ ネットワークスイッチ
１５０ バス接続制御装置
１６０ Ｉ／Ｏスイッチ拡張装置
１７０ Ｉ／Ｏデバイス
１８０ ストレージ装置
１９０ ディスクボリューム
１９１ 仮想ディスク
２００ 管理サーバ
２０１ メモリ（記憶部）
２０２ プロセッサ（処理部）
２０３ ユーザＩ／Ｆ
２０４ ネットワークＩ／Ｆ
２０５ ディスクＩ／Ｆ
２０６ リソース配置改善部
２０７ リソース確保・試行改善部
２０８ 試行改善部
２０９ 改善配置適用部
２１０ 情報収集部
２１１ リソース情報テーブル
２１２ 改善リソース情報テーブル
２１３ 履歴テーブル
２１４ サーバの関係テーブル
２１５ ジョブ管理テーブル
２１６ ジョブ結果管理テーブル
２１７ 改善記録テーブル
２１８ 改善指定とジョブ関係テーブル
２２０ サーバ群生成部
３１０ 比較情報取得部
３１１ サーバの関係情報取得部
３１２ リソース情報取得部
３１３ 仮想割り当て情報取得部
Ｅｐ 抽出確率
Ｒｐ 乱数確率

Claims (20)

1. ネットワークに複数のサーバが接続された計算機システムにおいて、管理サーバが、該ネットワークで確保できたリソースを組み合わせて試行用サーバを形成し、該試行用サーバが所定条件を満たす場合にサーバとして適用するリソース管理方法であって、
   前記管理サーバは、前記ネットワークで確保できたリソースに対し、前記試行用サーバが適用された際の適用情報の実績である抽出確率が登録されたリソース情報と、前記試行用サーバを採用するか否かの前記所定条件であるジョブの判断方法をジョブごとに管理するジョブ管理情報とを記憶部に記憶しており、
   前記管理サーバは、前記リソース情報の各リソースに対し、前記抽出確率が乱数生成部で発生させた乱数確率以上であれば、試行用のリソースとして選定し、
   前記選定された試行用のリソースを組み合わせて前記試行用サーバを形成し、
   前記形成された試行用サーバを用いて前記ジョブを実行し、
   前記ジョブの実行結果が前記ジョブの判断方法を満たせば、前記試行用サーバを該ネットワークのサーバとして適用する
   ことを特徴とするリソース管理方法。
2. 前記管理サーバは、前記実行結果が前記ジョブの判断方法を満たさなければ、前記リソースの選定、前記試行用サーバの形成、前記ジョブの実行を繰り返し、前記繰り返したときのジョブの実行結果を改善記録情報として前記記憶部に記録する
   ことを特徴とする請求の範囲第１項に記載のリソース管理方法。
3. 前記管理サーバは、前記試行用サーバを適用するか否かを判定する際に、現用のサーバで前記ジョブを実行し、前記現用のサーバのジョブの実行結果と前記試行用サーバのジョブの実行結果とを比較し、前記試行用サーバの性能が前記現用のサーバの性能と比較して改善している場合、前記試行用サーバを該ネットワークのサーバとして適用する
   ことを特徴とする請求の範囲第１項に記載のリソース管理方法。
4. 前記管理サーバは、現用のサーバが指定され、かつ、保守要求がされた場合、前記現用のサーバと関係のあるサーバを特定し、前記特定されたサーバの数に対応する複数の試行用サーバを、前記選定されたリソースを組み合わせて形成し、前記複数の試行用サーバを用いて前記ジョブを実行し、前記ジョブの実行結果が前記ジョブの判断方法を満たせば、前記複数の試行用サーバを該ネットワークのサーバとして適用する
   ことを特徴とする請求の範囲第１項に記載のリソース管理方法。
5. 前記管理サーバは、ユーザが演算による方法を選択した場合、請求の範囲第１項に記載のリソース管理方法に代わり、該演算による方法でリソース配置の改善をする
   ことを特徴とする請求の範囲第１項に記載のリソース管理方法。
6. 前記管理サーバは、前記ジョブの実行を繰り返すごとに、前記抽出確率を変更する
   ことを特徴とする請求の範囲第２項に記載のリソース管理方法。
7. 前記管理サーバは、リソースとして選定される確率をあげる際、前記抽出確率をあげる
   ことを特徴とする請求の範囲第２項に記載のリソース管理方法。
8. 前記リソース情報には、リソースの使用率が含まれ、
   前記リソースの使用率がユーザ指定の値以上である場合、リソースの増設を推奨する旨を前記改善記録情報に記録する
   ことを特徴とする請求の範囲第２項に記載のリソース管理方法。
9. 前記リソース情報には、リソースの使用率が含まれ、
   前記リソースの使用率がユーザ指定の値以下である場合、リソースの削除を推奨する旨を前記改善記録情報に記録する
   ことを特徴とする請求の範囲第２項に記載のリソース管理方法。
10. 前記管理サーバは、前記ジョブの判断方法を満たさない回数が所定回数を超えた場合、または、前記ジョブの判断方法を満たさない試行時間が所定時間を超えた場合、リソース配置の改善ができない旨を管理者に通知する
    ことを特徴とする請求の範囲第２項に記載のリソース管理方法。
11. 計算機システムをなす複数のサーバが接続されるネットワークから確保できるリソースを組み合わせて形成する試行用サーバを前記計算機システムのサーバとして適用した際の適用情報の実績である抽出確率が登録されるリソース情報の記憶部と、
    前記試行用サーバを採用するか否かの前記所定条件であるジョブの判断方法をジョブごとに管理するジョブ管理情報が記憶されるジョブ管理情報の記憶部と、
    前記リソース情報の各リソースに対し、前記抽出確率が乱数生成部で発生させた乱数確率以上であれば、試行用のリソースとして選定し、前記選定された試行用のリソースを組み合わせて前記試行用サーバを形成する形成処理部と、
    前記形成された試行用サーバを用いて前記ジョブを実行し、前記ジョブの実行結果が前記ジョブの判断方法を満たせば、前記試行用サーバを該ネットワークのサーバとして適用する適用処理部と、を有する
    ことを特徴とする管理サーバ。
12. 前記管理サーバは、前記実行結果が前記ジョブの判断方法を満たさなければ、前記リソースの選定、前記試行用サーバの形成、前記ジョブの実行を繰り返し、前記ジョブの実行結果を改善記録情報として前記記憶部に記録する
    ことを特徴とする請求の範囲第１１項に記載の管理サーバ。
13. 前記管理サーバは、前記試行用サーバを適用するか否かを判定する際に、現用のサーバで前記ジョブを実行し、前記試行用サーバの実行結果が前記現用のサーバのジョブの実行結果より改善している場合、前記試行用サーバを該ネットワークのサーバとして適用する
    ことを特徴とする請求の範囲第１１項に記載の管理サーバ。
14. 前記管理サーバは、現用のサーバが指定され、かつ、保守要求がされた場合、前記現用のサーバと関係のあるサーバを特定し、前記特定されたサーバの数に対応する複数の試行用サーバを、前記選定されたリソースを組み合わせて形成し、前記複数の試行用サーバを用いて前記ジョブを実行し、前記ジョブの実行結果が前記ジョブの判断方法を満たせば、前記複数の試行用サーバを該ネットワークのサーバとして適用する
    ことを特徴とする請求の範囲第１１項に記載の管理サーバ。
15. 前記管理サーバは、ユーザが演算による方法を選択した場合、請求の範囲第１１項に記載のリソース管理方法に代わり、該演算による方法でリソース配置の改善をする
    ことを特徴とする請求の範囲第１１項に記載の管理サーバ。
16. 前記管理サーバは、前記ジョブの実行を繰り返すごとに、前記抽出確率を変更する
    ことを特徴とする請求の範囲第１２項に記載の管理サーバ。
17. 前記管理サーバは、リソースとして選定される確率をあげる際、前記抽出確率をあげる
    ことを特徴とする請求の範囲第１２項に記載の管理サーバ。
18. 前記リソース情報には、リソースの使用率が含まれ、
    前記リソースの使用率がユーザ指定の値以上である場合、リソースの増設を推奨する旨を前記改善記録情報に記録する
    ことを特徴とする請求の範囲第１２項に記載の管理サーバ。
19. 前記リソース情報には、リソースの使用率が含まれ、
    前記リソースの使用率がユーザ指定の値以下である場合、リソースの削除を推奨する旨を前記改善記録情報に記録する
    ことを特徴とする請求の範囲第１２項に記載の管理サーバ。
20. 前記管理サーバは、前記ジョブの判断方法を満たさない回数が所定回数を超えた場合、または、前記ジョブの判断方法を満たさない試行時間が所定時間を超えた場合、リソース配置の改善ができない旨を管理者に通知する
    ことを特徴とする請求の範囲第１２項に記載の管理サーバ。

Images