(57)【要約】【課題】サーバのリソース使用量に応じて稼動するサーバの台数が変更される分散処理システムにおいて、待機サーバによるリソース使用量を抑えつつ、必要なタイミングで稼動サーバの台数を増やし、負荷上昇への対応を可能とすることを目的とする。【解決手段】待機サーバを稼動サーバへ切り替える指標となる閾値にリソース使用量が達するまでの予測時間を計算して、計算した予測時間内に生成可能な待機サーバの待機方式を選択し、その待機方式の待機サーバを生成する。【選択図】図１
2011243162.tif 000002
【特許請求の範囲】
【請求項１】
複数のサーバに処理を分散させる分散処理システムであって、サーバのリソースが使用されている量であるリソース使用量に応じて稼動する稼動サーバの台数が変更される分散処理システムにおける稼動サーバの台数を制御する台数制御装置であり、
前記稼動サーバへの切り替えを待機している待機サーバを所定の設定状態のサーバから生成するまでにかかる生成時間を、前記待機サーバの待機方式毎に記憶装置に記憶する時間記憶部と、
処理装置により、所定のリソース使用量が予め設定された第１閾値に前記リソース使用量が達するまでの第１予測時間を計算する予測時間計算部と、
処理装置により、前記時間記憶部が記憶した前記生成時間が、前記予測時間計算部が計算した第１予測時間よりも短い待機方式を選択する待機方式選択部と、
処理装置により、前記所定の設定状態のサーバから、前記待機方式選択部が選択した待機方式の待機サーバを生成する待機サーバ生成部と、
前記リソース使用量が前記第１閾値に達した場合、前記待機サーバ生成部が生成した待機サーバを稼動させて稼動サーバに切り替える切替部と
を備えることを特徴とする台数制御装置。
【請求項２】
前記時間記憶部は、さらに、前記待機サーバを稼動させて前記稼動サーバに切り替えるまでにかかる切替時間を、前記待機サーバの待機方式毎に記憶し、
前記予測時間計算部は、さらに、前記第１閾値よりも多いリソース使用量が設定された第２閾値に前記リソース使用量が達するまでの第２予測時間を計算し、
前記待機方式選択部は、前記生成時間が前記第１予測時間よりも短く、かつ、前記切替時間が前記第２予測時間よりも短い待機方式を選択する
ことを特徴とする請求項１に記載の台数制御装置。
【請求項３】
前記待機方式選択部は、前記生成時間が前記第１予測時間よりも短く、かつ、前記切替時間が前記第２予測時間よりも短い待機方式がない場合には、前記生成時間と前記切替時間との和が最も短い待機方式を選択する
ことを特徴とする請求項２に記載の台数制御装置。
【請求項４】
前記待機方式選択部は、前記生成時間が前記第１予測時間よりも短く、かつ、前記切替時間が前記第２予測時間よりも短いという条件を満たす待機方式が複数存在する場合には、前記条件を満たす待機方式のうち、その待機方式の待機サーバを生成することによって使用されるリソース使用量が少ない待機方式を選択する
ことを特徴とする請求項２又は３に記載の台数制御装置。
【請求項５】
前記台数制御装置は、さらに、
前記待機方式選択部が選択した待機方式を記憶する待機方式記憶部
を備え、
前記切替部は、さらに、前記リソース使用量が前記第１閾値よりも少ないリソース使用量が設定された第３閾値よりも前記リソース使用量が少なくなった場合、少なくとも１台の稼動サーバを前記待機方式記憶部が記憶した待機方式の待機サーバに切り替える
ことを特徴とする請求項１から４までのいずれかに記載の台数制御装置。
【請求項６】
前記複数のサーバは、役割に応じて複数のグループに分けられ、
前記台数制御装置は、前記複数のグループのグループ毎に、そのグループに属する稼動サーバの台数を制御し、
前記待機サーバ生成部は、前記複数のグループのうち所定のグループよりもクライアント寄りのフロントエンドグループに属する待機サーバが存在するか否かに応じて、前記所定のグループに属する待機サーバを生成するか否かを決定する
ことを特徴とする請求項１から５までのいずれかに記載の台数制御装置。
【請求項７】
前記切替部は、稼動サーバが停止した場合、前記待機サーバを稼動させて稼動サーバに切り替え、
前記予測時間計算部は、前記切替部が前記待機サーバを稼動させて稼動サーバに切り替えた後、前記第１閾値に前記リソース使用量が達するまでの第１予測時間を再計算し、
前記待機方式選択部は、前記時間記憶部が記憶した前記生成時間が、前記予測時間計算部が再計算した第１予測時間よりも短い待機方式を選択し、
前記待機サーバ生成部は、前記所定の設定状態のサーバから、前記待機方式選択部が選択した待機方式の待機サーバを生成する
ことを特徴とする請求項１から６までのいずれかに記載の台数制御装置。
【請求項８】
複数のサーバに処理を分散させる分散処理システムであって、サーバのリソースが使用されている量であるリソース使用量に応じて稼動する稼動サーバの台数が変更される分散処理システムにおける稼動サーバの台数を制御する台数制御方法であり、
処理装置が、所定のリソース使用量が予め設定された第１閾値に前記リソース使用量が達するまでの第１予測時間を計算する予測時間計算ステップと、
処理装置が、前記稼動サーバへの切り替えを待機している待機サーバを所定の設定状態のサーバから生成するまでにかかる生成時間が、前記予測時間計算ステップで計算した第１予測時間よりも短い待機方式を選択する待機方式選択ステップと、
処理装置が、前記所定の設定状態のサーバから、前記待機方式選択ステップで選択した待機方式の待機サーバを生成する待機サーバ生成ステップと、
前記リソース使用量が前記第１閾値に達した場合、前記待機サーバ生成ステップで生成した待機サーバを稼動させて稼動サーバに切り替える切替ステップと
を備えることを特徴とする台数制御方法。
【請求項９】
複数のサーバに処理を分散させる分散処理システムであって、サーバのリソースが使用されている量であるリソース使用量に応じて稼動する稼動サーバの台数が変更される分散処理システムにおける稼動サーバの台数を制御する台数制御プログラムであり、
所定のリソース使用量が予め設定された第１閾値に前記リソース使用量が達するまでの第１予測時間を計算する予測時間計算処理と、
前記稼動サーバへの切り替えを待機している待機サーバを所定の設定状態のサーバから生成するまでにかかる生成時間が、前記予測時間計算処理で計算した第１予測時間よりも短い待機方式を選択する待機方式選択処理と、
前記所定の設定状態のサーバから、前記待機方式選択処理で選択した待機方式の待機サーバを生成する待機サーバ生成処理と、
前記リソース使用量が前記第１閾値に達した場合、前記待機サーバ生成処理で生成した待機サーバを稼動させて稼動サーバに切り替える切替処理と
をコンピュータに実行させることを特徴とする台数制御プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、複数のサーバに処理を分散させる分散処理システムであって、サーバのリソース使用量に応じて稼動するサーバの台数が変更される分散処理システムに関する。
【背景技術】
【０００２】
分散処理システムでは、負荷分散装置が、複数のサーバへ処理を分散させ、各サーバへの負荷を分散させる。特に、分散処理システムには、負荷分散装置が、全体の負荷状況に応じて、サーバの稼働台数を制御することで、負荷の上昇や減少に対応するものもある。
【０００３】
また、仮想化技術を用いることにより、各サーバを仮想サーバとすることで、サーバの生成や削除を短時間で行うことができる。また、各サーバを仮想サーバとすることで、新たにハードウェアを用意することなく、新たなサーバを生成することができる。そのため、複数のシステムが混在した環境において、一時的に負荷が高いシステムに、より多くのリソースを割り当てる等の制御が可能となっている。
【０００４】
分散処理システムにおいて、負荷の急激な上昇に対応するには、待機サーバを予め用意しておき、必要になった時点で待機サーバを稼動サーバに切り替える方法がある（特許文献１参照）。しかし、待機サーバは通常は使われないサーバであるため、待機サーバを用意しておくことは、負荷の上昇が発生しない場合には、無駄なリソースを使用することになる。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】国際公開ＷＯ２００６／０４０８１１号
【発明の概要】
【発明が解決しようとする課題】
【０００６】
特許文献１では、待機サーバを用意する方式が一意に決められており、その方式の待機サーバを起動した状態にしておくか、起動していない状態にしておくかの選択のみが可能である。待機サーバを予め起動した状態で用意しておけば、負荷の上昇への対応はすぐにできるが、負荷の上昇が発生しない場合には無駄なリソースを使用することになる。一方、待機サーバを起動しない状態で用意しておけば、負荷の上昇の発生しない場合におけるリソースの使用を抑えることができるものの、負荷の上昇への対応が遅れる可能性がある。
この発明は、待機サーバによるリソース使用量を抑えつつ、必要なタイミングで稼動サーバの台数を増やし、負荷上昇への対応を可能とすることを目的とする。
【課題を解決するための手段】
【０００７】
この発明に係る台数制御装置は、
複数のサーバに処理を分散させる分散処理システムであって、サーバのリソースが使用されている量であるリソース使用量に応じて稼動する稼動サーバの台数が変更される分散処理システムにおける稼動サーバの台数を制御する台数制御装置であり、
前記稼動サーバへの切り替えを待機している待機サーバを所定の設定状態のサーバから生成するまでにかかる生成時間を、前記待機サーバの待機方式毎に記憶装置に記憶する時間記憶部と、
処理装置により、所定のリソース使用量が予め設定された第１閾値に前記リソース使用量が達するまでの第１予測時間を計算する予測時間計算部と、
処理装置により、前記時間記憶部が記憶した前記生成時間が、前記予測時間計算部が計算した第１予測時間よりも短い待機方式を選択する待機方式選択部と、
処理装置により、前記所定の設定状態のサーバから、前記待機方式選択部が選択した待機方式の待機サーバを生成する待機サーバ生成部と、
前記リソース使用量が前記第１閾値に達した場合、前記待機サーバ生成部が生成した待機サーバを稼動させて稼動サーバに切り替える切替部と
を備えることを特徴とする。
【発明の効果】
【０００８】
この発明に係る台数制御装置は、待機サーバを稼動サーバへ切り替える指標となる閾値にリソース使用量が達するまでの予測時間を計算して、計算した予測時間内に生成可能な待機サーバの待機方式を選択し、その待機方式の待機サーバを生成する。そのため、稼動サーバへの切り替えが必要となる時点には、待機サーバを用意することができており、必要なタイミングで稼動サーバの台数を増やし、負荷上昇への対応が可能である。
【図面の簡単な説明】
【０００９】
【図１】実施の形態１に係るサーバリソース制御システムの構成図。
【図２】図１に示す各仮想サーバ３の構成を論理的に示した図。
【図３】実施の形態１に係るリソース提供時間管理テーブル２６の例を示す図。
【図４】各待機方式２６−１で示した方式で待機サーバの生成する処理（生成手順）と、待機サーバから稼動サーバに変更する際の処理（切替手順）との例を示した図。
【図５】実施の形態１に係るリソース管理テーブル２７の例を示す図。
【図６】実施の形態１に係るリソース管理・制御サーバ６の負荷上昇時における動作の流れを示すフローチャート。
【図７】実施の形態１に係る将来の負荷の上昇の予測計算の説明図。
【図８】実施の形態２に係るリソース管理テーブル２７の例を示す図。
【図９】実施の形態２に係るリソース管理・制御サーバ６の負荷上昇時における動作の流れを示すフローチャート。
【図１０】実施の形態２に係るリソース管理・制御サーバ６の負荷減少時における動作の流れを示すフローチャート。
【図１１】実施の形態３に係るリソース管理テーブル２７の例を示す図。
【図１２】実施の形態３に係るリソース管理・制御サーバ６の各サーバグループに対する処理開始時における動作の流れを示すフローチャート。
【図１３】実施の形態４に係るサーバリソース制御システムの構成図。
【図１４】実施の形態４に係るリソース管理・制御サーバ６の稼動サーバ停止時の動作の流れを示すフローチャート。
【図１５】実施の形態４に係る将来の負荷の上昇の予測計算の説明図。
【図１６】物理計算機１、リソース管理・制御サーバ６、負荷分散装置５、端末８のハードウェア構成の一例を示す図。
【発明を実施するための形態】
【００１０】
以下、図に基づき、発明の実施の形態を説明する。
以下の説明において、処理装置は後述するＣＰＵ９１１等である。記憶装置は後述するＲＯＭ９１３、ＲＡＭ９１４、磁気ディスク９２０等の記憶装置である。つまり、処理装置、記憶装置はハードウェアである。
【００１１】
実施の形態１．
この実施の形態では、負荷上昇時に用意する待機サーバの待機方式を決定する方法について説明する。
【００１２】
図１は、実施の形態１に係るサーバリソース制御システムの構成図である。
図１に示すように、サーバリソース制御システムは、複数の物理計算機１（１−１，１−２，・・・）と、負荷分散装置５と、リソース管理・制御サーバ６（台数制御装置）と、複数の端末８と、ストレージ１０とを備える。各物理計算機１と負荷分散装置５やリソース管理・制御サーバ６とは、通信回線４を介して接続される。各物理計算機１とストレージ１０とは通信回線９を介して接続される。また、負荷分散装置５と各端末８とは、インターネット／イントラネット７を介して接続される。
【００１３】
各物理計算機１は、仮想化ソフトウェア２（２−１，２−２，・・・）を備える。仮想化ソフトウェア２は、サーバ仮想化を実現するソフトウェアである。各物理計算機１では、仮想化ソフトウェア２により、システムを構成するサーバ群が仮想サーバ３（３−１〜３−１０，・・・）として構築されている。
物理計算機１−１では、Ｗｅｂ１−１仮想サーバ、Ｗｅｂ２−３仮想サーバ、Ａｐｐ１−１仮想サーバ、ＤＢ−１仮想サーバ、Ｗｅｂ２−２仮想サーバが、仮想化ソフトウェア２−１により仮想サーバ３として構築されている。また、物理計算機１−２では、Ｗｅｂ１−２仮想サーバ、Ｗｅｂ２−１仮想サーバ、Ａｐｐ２−１仮想サーバ、Ｗｅｂ１−３仮想サーバ、Ａｐｐ１−２仮想サーバが、仮想化ソフトウェア２−２により仮想サーバ３として構築されている。
各仮想サーバ３は、各種サービスを提供する。ここでは、Ｗｅｂ１の機能を提供する仮想サーバ３として、Ｗｅｂ１−１仮想サーバ、Ｗｅｂ１−２仮想サーバ、Ｗｅｂ１−３仮想サーバがある。また、Ｗｅｂ２の機能を提供する仮想サーバ３として、Ｗｅｂ２−１仮想サーバ、Ｗｅｂ２−２仮想サーバ、Ｗｅｂ２−３仮想サーバがある。また、Ａｐｐ１の機能を提供する仮想サーバ３として、Ａｐｐ１−１仮想サーバ、Ａｐｐ１−２仮想サーバがある。また、Ａｐｐ２の機能を提供する仮想サーバ３として、Ａｐｐ２−１仮想サーバがある。また、ＤＢの機能を有した仮想サーバ３として、ＤＢ−１仮想サーバがある。
なお、これらの仮想サーバのうち、Ｗｅｂ１−３仮想サーバと、Ｗｅｂ２−３仮想サーバとが待機サーバであり、他は稼動サーバである。各稼動サーバには、使用可能なリソースが割り当てられる。
以下の説明では、同一の機能を提供する仮想サーバ３をサーバグループと呼ぶ。例えば、Ｗｅｂ１−１仮想サーバ、Ｗｅｂ１−２仮想サーバ、Ｗｅｂ１−３仮想サーバが１つのサーバグループであり、Ａｐｐ１−１仮想サーバ、Ａｐｐ１−２仮想サーバが１つのサーバグループである。
【００１４】
通信回線４は、例えばイントラネット、ＬＡＮ（Ｌｏｃａｌ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）等のネットワークである。ここでは１本のネットワークで記載しているが、管理用のネットワークや業務用のネットワーク等で複数用意することも可能である。
【００１５】
負荷分散装置５は、ある機能に対するリクエストを、その機能を有した複数の仮想サーバ３に振り分けてリクエストを送信し、同一機能の処理を分散させることで、処理能力を向上させる機能を実現するための装置である。
負荷分散装置５としては、アプライアンスサーバを導入する場合、ソフトウェアで実現する場合、ＤＮＳ（Ｄｏｍａｉｎ  Ｎａｍｅ  Ｓｙｓｔｅｍ）サーバの機能を利用する場合等あるが、その実現方法はどのようなものであっても構わない。
【００１６】
リソース管理・制御サーバ６は、仮想サーバ３のリソース使用量に応じて、稼動サーバの台数制御を行うサーバである。リソース管理・制御サーバ６は、リソース情報収集・蓄積部２１、負荷傾向判断部２２、役割変更部２３、リソース提供方式決定部２４、待機生成・削除部２５、リソース提供時間管理テーブル２６、リソース管理テーブル２７を備える。
リソース情報収集・蓄積部２１は、各仮想サーバ３のリソース使用情報と、各サーバグループに割り当てているリソース量情報とを、定期的に収集し、リソース管理・制御サーバ６の記憶装置に蓄積する。また、リソース情報収集・蓄積部２１は、処理装置により、サーバグループ毎に定義されている第１閾値を、そのサーバグループのリソース使用量が超えたか否かを判断する。
負荷傾向判断部２２は、リソース情報収集・蓄積部２１が収集したリソース使用情報を基に、回帰分析等を用いて処理装置により負荷の将来の上昇の予測計算を行う。
役割変更部２３は、処理装置により、待機サーバを稼動サーバに変更する、あるいは稼動サーバを待機サーバに変更する。
リソース提供方式決定部２４は、負荷傾向判断部２２が予測計算することにより導出した負荷上昇傾向と、待機サーバの生成が必要なサーバグループに割り当てられているリソース量の情報、待機サーバを生成するための時間、待機サーバを稼動サーバに変更するために要する時間、待機サーバ用に必要とするリソース量情報を基に、処理装置により最適な待機サーバの待機方式を判定する。
待機生成・削除部２５は、処理装置により、リソース提供方式決定部２４が導出した待機方式に基づき、待機サーバを生成する、あるいは待機サーバを削除する。
リソース提供時間管理テーブル２６は、各待機方式の生成時間、待機サーバを稼動サーバに変更させるために要する時間、リソース利用の情報が格納されたテーブル（記憶装置）である。
リソース管理テーブル２７は、各サーバグループの構成情報や閾値等の情報が格納されたテーブル（記憶装置）である。
【００１７】
インターネット／イントラネット７は、各サーバ群に対してリクエストを行う際に利用されるネットワークであり、インターネットやイントラネット、ＬＡＮ、専用回線等である。
【００１８】
端末８は、各サーバ群に対して、インターネット／イントラネット７を介してリクエストを送出する。
【００１９】
通信回線９は、各物理計算機がストレージにアクセスするネットワークＳＡＮ（Ｓｔｏｒａｇｅ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）である。
【００２０】
ストレージ１０は、各物理計算機１で稼動する仮想サーバ３のブートディスクイメージや待機サーバを生成する基となるテンプレートが格納されたストレージである。特に、仮想サーバディスクイメージ１１は、各仮想サーバ３のブートディスクイメージである。また、仮想サーバテンプレート１２は、各サーバグループの待機サーバを生成する基となるテンプレートである。
【００２１】
図２は、図１に示す各仮想サーバ３の構成を論理的に示した図である。図２に示すように、各仮想サーバ３によって実現されるシステムは、Ｗｅｂ１、Ｗｅｂ２をフロントエンドとする２つのシステムが混在した環境となっている。
端末８からのリクエストは、インターネット／イントラネット７を介して負荷分散装置５に届けられる。そのリクエストがＷｅｂ１に対するものであれば、負荷分散装置５からＷｅｂ１−１あるいはＷｅｂ１−２のいずれかにリクエストが送出される。また、必要に応じ、負荷分散装置５を介してＡｐｐ１−１あるいはＡｐｐ１−２にリクエストが送出される。また、必要に応じＤＢ−１にリクエストが送出される。そして、処理結果が、リクエストが送られた順の逆順で戻っていく構成となっている。
また、同様に、リクエストがＷｅｂ２に対するものであれば、負荷分散装置５からＷｅｂ２−１あるいはＷｅｂ２−２のいずれかにリクエストが送出される。また、必要に応じ、負荷分散装置５を介してＡｐｐ２−１にリクエストが送出される。そして、処理結果が、リクエストが送られた順の逆順で戻っていく構成となっている。
【００２２】
図３は、実施の形態１に係るリソース提供時間管理テーブル２６の例を示す図である。
リソース提供時間管理テーブル２６は、待機方式２６−１、切替時間２６−２（待機から稼動に要する時間）、生成時間２６−３（生成のための時間）、リソース使用量の順位２６−４の項目を有するテーブルである。
待機方式２６−１は、待機サーバを用意する方式を識別するための方式名が格納される。本例では、待機サーバを一時停止状態にしたサスペンド、待機サーバの状態を保存したスナップショット、待機サーバのブートイメージを用意したブート、待機サーバの基となるテンプレートの状態のままのテンプレートを待機方式として用意した例を示している。
切替時間２６−２は、各待機方式で用意された待機サーバを稼動サーバに変更するために要する時間が格納される。
生成時間２６−３は、各待機方式の待機サーバを生成するために要する時間が格納される。
リソース使用量の順位２６−４は、各待機方式にて待機サーバを用意した場合に、その待機サーバによって使用されるリソースの量（リソース使用量）の順位が格納される。この例では、リソース使用量が多いものほど少ない数字で表している。
【００２３】
図４は、各待機方式２６−１で示した方式で待機サーバを生成する処理（生成手順）と、待機サーバから稼動サーバに変更する際の処理（切替手順）との例を示した図である。
ここでは、各サーバグループの待機サーバを生成するためのＯＳやアプリケーション等のインストールが完了したテンプレートが予め用意されている前提としている。
【００２４】
（サスペンド）
生成手順は次の（１）から（３）までである。（１）テンプレートからブートイメージをコピーして、ブートディスクの生成を行う。（２）ブートディスクのブートイメージで起動する。（３）一時停止状態にする。
切替手順は次の（１）（２）である。（１）一時停止状態を解除して稼動させる。（２）稼動状態にした後、負荷分散装置５へ登録する。
【００２５】
（スナップショット）
生成手順は次の（１）から（４）までである。（１）テンプレートからブートイメージをコピーして、ブートディスクの生成を行う。（２）ブートディスクのブートイメージで起動する。（３）スナップショット情報の生成を行う。（４）スナップショット情報の生成完了後、生成した待機サーバをシャットダウンする。
切替手順は次の（１）（２）である。（１）スナップショットから起動を行う。（２）稼動状態にした後、負荷分散装置５へ登録する。
【００２６】
（ブート）
生成手順は次の（１）である。（１）テンプレートからブートイメージをコピーして、ブートディスクの生成を行う。
切替手順は次の（１）（２）である。（１）ブートディスクのブートイメージで起動する。（２）稼動状態にした後、負荷分散装置５へ登録する。
【００２７】
（テンプレート）
テンプレートは用意されていることが前提のため、生成手順は存在しない。
切替手順は次の（１）から（３）までである。（１）テンプレートからブートイメージをコピーして、ブートディスクの生成を行う。（２）ブートディスクのブートイメージで起動する。（３）稼動状態にした後、負荷分散装置５へ登録する。
【００２８】
このように、待機方式毎に生成手順や切替手順が異なるため、待機方式毎に待機サーバの生成にかかる時間や、待機サーバから稼動サーバへの切り替えにかかる時間や、待機サーバによって使用されるリソース使用量が異なる。そこで、これらの情報をリソース提供時間管理テーブル２６に記憶しておき、最適な待機方式を導出する。
【００２９】
なお、切替手順では、最後に必ず負荷分散装置５へ登録するという処理が行われる。待機サーバを稼動サーバに切り替える処理にかかる時間を短縮するため、予めサーバグループ毎に割り当て可能なＩＰアドレスを確保しておき、待機サーバが生成された時点で確保されたＩＰアドレスをその待機サーバに割り当てておいてもよい。この場合、待機サーバから稼動サーバへ切り替えされた場合、待機サーバに割り当てられていたＩＰアドレスを負荷分散装置５へ登録すればよい。つまり、待機サーバから稼動サーバへ切り替えた場合、単にＩＰアドレスを負荷分散装置５へ登録するだけで、負荷分散装置５はどのサーバグループの稼動サーバが、どのＩＰアドレスで追加されたかを識別することが可能になる。
【００３０】
図５は、実施の形態１に係るリソース管理テーブル２７の例を示す図である。
リソース管理テーブル２７は、サーバグループ名２７−１、稼動サーバ２７−２、待機サーバ２７−３、待機方式２７−４、テンプレート名２７−５、最大数２７−６、第１閾値２７−７、第２閾値２７−８、第３閾値２７−９の項目を有するテーブルである。
サーバグループ名２７−１は、各サーバグループを識別するための名前が格納される。
稼動サーバ２７−２は、各サーバグループで稼動サーバとして動作しているサーバを識別するための名前が格納される。
待機サーバ２７−３は、現時点で用意されている待機サーバを識別するための名前が格納される。
待機方式２７−４は、用意されている待機サーバの待機方式の方式名が格納される。なお、待機方式２７−４は、リソース提供時間管理テーブル２６の待機方式２６−１に記録されているいずれかの方式名が格納される。
テンプレート名２７−５は、待機サーバを生成するための基となるテンプレートを識別する名前が格納される。
最大数２７−６は、各サーバグループで稼動可能な最大サーバ数が格納される。
第１閾値２７−７、第２閾値２７−８、第３閾値２７−９は、リソースの閾値が格納される。第１閾値２７−７は、待機サーバから稼動サーバへの変更を開始するトリガーとして利用される値が格納される。第２閾値２７−８は、各サーバグループのリソース使用量の上限値として利用される値であり、この値を超えた状態が長く続かないようにすべき値が格納される。第３閾値２７−９は、リソース使用量が少なくなり、稼動サーバ数を減らすトリガーとして利用される値が格納される。なお、各閾値には、そのサーバグループに割り当てられたリソース量に対するリソース使用量の割合（パーセンテージ）が閾値として格納される。
【００３１】
図６は、実施の形態１に係るリソース管理・制御サーバ６の負荷上昇時における動作の流れを示すフローチャートである。なお、リソース管理・制御サーバ６は、図６に示す処理をサーバグループ毎に実行する。
（ＳＴ１０１）では、リソース情報収集・蓄積部２１が、各仮想サーバ３のリソース使用量を示すリソース使用情報を定期的に収集して、リソース管理テーブル２７に格納されている第１閾値２７−７を超えたか否かを処理装置により判定する。なお、ここでリソース情報収集・蓄積部２１が収集したリソース使用情報は、リソース管理・制御サーバ６の記憶装置に蓄積される。
第１閾値２７−７を超えたと判定した場合、処理を（ＳＴ１０２）へ進める。一方、第１閾値２７−７を超えていないと判定した場合、所定の時間が経過した後、再度（ＳＴ１０１）を実行する。
【００３２】
（ＳＴ１０２）では、役割変更部２３が、リソース管理テーブル２７の待機サーバ２７−３に格納された情報から、処理装置により、待機サーバが用意されているか否かを判定する。
待機サーバが用意されていれる場合、処理を（ＳＴ１０５）へ進める。一方、待機サーバが用意されていない場合、処理を（ＳＴ１０３）へ進める。
【００３３】
（ＳＴ１０３）では、役割変更部２３が、リソース管理テーブル２７の稼動サーバ２７−２と最大数２７−６とに格納された情報から、処理装置により、稼動サーバ数が最大数に達しているか否かを判定する。
最大数に達していると判定した場合、稼動サーバを追加できないため処理を（ＳＴ１０１）へ戻す。最大数に達していないと判定した場合、処理を（ＳＴ１０４）へ進める。
【００３４】
（ＳＴ１０４）では、最大数に達していないにも関わらず待機サーバが用意されていない場合、待機サーバが生成中であるため、役割変更部２３が、処理装置により、待機サーバの生成が完了したか否かを判定する。
生成が完了していないと判定した場合、所定の時間が経過した後、再度（ＳＴ１０４）を実行する。一方、生成が完了したと判定した場合、処理を（ＳＴ１０５）へ進める。
【００３５】
（ＳＴ１０５）では、役割変更部２３が、リソース管理テーブル２７の待機方式２７−４に格納された情報に基づき、待機サーバを稼動サーバに切り替える。また、役割変更部２３が、リソース管理テーブル２７の稼動サーバ２７−２、待機サーバ２７−３、待機方式２７−４に格納された情報を更新する。
そして、処理を（ＳＴ１０６）へ進める。
【００３６】
（ＳＴ１０６）では、負荷傾向判断部２２が、処理装置により、将来の負荷の上昇の予測計算を行う。
図７は、実施の形態１に係る将来の負荷の上昇の予測計算の説明図である。図７において、各プロットは、過去所定の時間（時間ｔ０）に、（ＳＴ１０１）で収集し、記憶装置に蓄積されたリソース使用情報が示すリソース使用量である。このリソース使用量（リソースの使用状況の分布）から回帰分析等の手法を用い、将来の負荷の上昇の予測計算を行う。例えば、ｙ＝ａｘ＋ｂ（ｙ：リソース使用量、ｘ：時間、ａ，ｂ：はリソース使用量から計算される値）等の近似式を導出して、導出した近似式から予測計算を行う。
そして、処理を（ＳＴ１０７）へ進める。
【００３７】
（ＳＴ１０７）では、リソース提供方式決定部２４が、負荷傾向判断部２２によって導出された負荷上昇の傾向と、現時点で対象のサーバグループに割り当てられているリソース量とから、処理装置により、リソース使用量が第１閾値２７−７に達するまでの時間（図７のｔ１、第１予測時間）を計算する。また、リソース提供方式決定部２４は、処理装置により、リソース使用量が第１閾値２７−７に達してから第２閾値２７−８に達するまでの時間（図７のｔ２、第２予測時間）を計算する。
なお、現時点で対象のサーバグループに割り当てられているリソース量とは、（ＳＴ１０５）で稼動サーバが追加されるまでに、各稼動サーバに割り当てられていたリソース量の合計に、（ＳＴ１０５）で追加された稼動サーバに割り当てられたリソース量を加えたリソース量である。
【００３８】
（ＳＴ１０８）では、リソース提供方式決定部２４が、処理装置により、リソース提供時間管理テーブル２６の生成時間２６−３に格納された時間と、（ＳＴ１０７）で計算した第１予測時間とを比較する。また、リソース提供方式決定部２４が、処理装置により、リソース提供時間管理テーブル２６の切替時間２６−２に格納された時間と、（ＳＴ１０７）で計算した第２予測時間とを比較する。そして、リソース管理テーブル２７が、第１予測時間よりも生成時間２６−３の時間が短く、かつ、第２予測時間よりも切替時間２６−２の時間が短い待機方式が存在するか否かを判定する。
両方の時間を満たす待機方式が存在すると判定した場合、処理を（ＳＴ１０９）へ進める。一方、両方の時間を満たす待機方式が存在しないと判定した場合、処理を（ＳＴ１１０）へ進める。
【００３９】
（ＳＴ１０９）では、リソース提供方式決定部２４が、処理装置により、両方の時間を満たす待機方式が１方式のみか複数存在するかを判定する。
１方式のみと判定した場合、処理を（ＳＴ１１２）へ進める。一方、複数存在すると判定した場合、処理を（ＳＴ１１１）へ進める。
【００４０】
（ＳＴ１１０）では、リソース提供方式決定部２４が、処理装置により、リソース提供時間管理テーブル２６の切替時間２６−２に格納された時間と生成時間２６−３に格納された時間との和が最も小さい待機方式を選択する。
そして、処理を（ＳＴ１１２）へ進める。
【００４１】
（ＳＴ１１１）では、リソース提供方式決定部２４が、処理装置により、リソース提供時間管理テーブル２６のリソース使用量の順位２６−４に格納された値が低い（リソース使用量が少ない）待機方式を選択する。
【００４２】
（ＳＴ１１２）では、待機生成・削除部２５が、処理装置により、リソース提供方式決定部２４が決定した待機方式の待機サーバを生成する。そして、待機生成・削除部２５は、リソース管理テーブル２７の待機サーバ２７−３、待機方式２７−４の情報を更新する。
そして、処理を（ＳＴ１０１）へ戻す。
【００４３】
以上のように、リソース管理・制御サーバ６は、負荷傾向に基づき、必要とされる時間内に稼動サーバの追加（リソース追加）が可能な待機方式を選択する。また、必要とされる時間内に稼動サーバの追加が可能な待機方式が複数存在する場合には、待機サーバが使用するリソースが少ない待機方式を選択する。
そのため、待機サーバのリソース使用量を抑えつつ、必要なタイミングで待機サーバを稼動サーバに変更して、負荷上昇へ対応することが可能である。
特に、同じサーバグループで同じ負荷傾向であっても、稼動サーバ数が少ない場合には、サーバグループに割り当てられている総リソース量が少ないため、即時に追加が必要となり、稼動サーバ数が多い場合には、サーバグループに割り当てられている総リソース量が多いため、即時追加は不要となるといった傾向がある。リソース管理・制御サーバ６によれば、このような傾向に合わせて、稼動サーバの追加を行うことができる。
【００４４】
なお、上記説明では、仮想サーバの構成で説明したが、物理サーバの構成に適用することも可能である。
また、上記説明では、負荷傾向を判断する手法として回帰分析による一次式の例を示したが、負荷傾向を予測できる手法であれば、別の手法としても構わない。
また、上記説明では、待機方式の例としてサスペンド、スナップショット、ブート、テンプレートを示したが、これらの方式に限定されるものではない。
【００４５】
つまり、実施の形態１に係るサーバリソース制御方式は、グループ化された複数のサーバに処理を分散させ、サーバの追加により処理量の増加を実現するシステムにおいて、
待機サーバを生成する時間情報と、待機サーバから稼動サーバに役割を変更するための時間情報と、稼動サーバのリソース使用状況の履歴情報から導出する負荷変動傾向と、その時の稼動サーバ群に割り当てられているリソース量により変化する閾値に達するまでの時間予測に基づき、稼動サーバのリソース量変更に必要な時間内に対応でき、かつ、最も待機サーバをリソース使用量の少ない形態を選択し、待機サーバの生成を実施することを特徴とする。
【００４６】
実施の形態２．
この実施の形態では、負荷上昇時に選択した待機サーバの待機方式を記録し、記録した待機方式に基づき、負荷減少時の待機サーバの待機方式を決定する方法について説明する。
【００４７】
図８は、実施の形態２に係るリソース管理テーブル２７の例を示す図である。
図８に示すリソース管理テーブル２７には、図５に示すリソース管理テーブル２７に初期台数２７−１０と選択待機方式２７−１１とが追加されている。他は図５に示すリソース管理テーブル２７と同様である。
初期台数２７−１０は、初期の稼動サーバ台数が格納される。なお、ここでは、初期の稼動サーバ台数よりも少ない台数に稼動サーバを減らせないものとする。
選択待機方式２７−１１は、各稼動サーバ数の時に、待機方式としてどの方式が選択されたかが格納される。例えば、図８では、Ｗｅｂ１のサーバグループであれば、稼動サーバが２台の場合における待機サーバの待機方式がサスペンドであり、３台の場合における待機サーバの待機方式がブートであり、４台の場合における待機サーバの待機方式がブートであることを示す。
【００４８】
図９は、実施の形態２に係るリソース管理・制御サーバ６の負荷上昇時における動作の流れを示すフローチャートである。
図９の（ＳＴ１０１）から（ＳＴ１１２）までの動作は、実施の形態１で説明した図６に示す動作と同様である。
（ＳＴ２０１）では、リソース提供方式決定部２４が、選択した待機方式を、リソース管理テーブル２７の選択待機方式２７−１１における稼動サーバ数に応じた項目に格納する。
【００４９】
図１０は、実施の形態２に係るリソース管理・制御サーバ６の負荷減少時における動作の流れを示すフローチャートである。なお、リソース管理・制御サーバ６は、サーバグループ毎に図１０に示す処理を実行する。
（ＳＴ２０２）では、リソース情報収集・蓄積部２１が、各仮想サーバ３のリソース使用情報を定期的に収集して、リソース管理テーブル２７に格納されている第３閾値２７−９を下回ったか否かを処理装置により判定する。なお、ここでリソース情報収集・蓄積部２１が収集したリソース使用情報は、リソース管理・制御サーバ６の記憶装置に蓄積される。
第３閾値２７−９を下回ったと判定した場合、処理を（ＳＴ２０３）へ進める。一方、第３閾値２７−９を下回っていないと判定した場合、所定の時間が経過した後、再度（ＳＴ２０２）を実行する。
【００５０】
（ＳＴ２０３）では、リソース提供方式決定部２４が、リソース管理テーブル２７の稼動サーバ２７−２と初期台数２７−１０とに格納された情報から、処理装置により、稼動サーバの台数が初期台数か否かを判断する。
初期台数ではないと判定した場合、処理を（ＳＴ２０４）へ進める。一方、初期台数であると判定した場合、稼動サーバを減らせないため、処理を（ＳＴ２０２）へ戻す。
【００５１】
（ＳＴ２０４）では、リソース提供方式決定部２４が、リソース管理テーブル２７の稼動サーバ２７−２に格納された情報から、処理装置により、現在の稼動サーバ数を計算する。そして、リソース提供方式決定部２４が、リソース管理テーブル２７の選択待機方式２７−１１における計算した稼働サーバ数から１台減少させた台数の項目に格納された待機方式を読み出す。
そして、処理を（ＳＴ２０５）へ進める。
【００５２】
（ＳＴ２０５）では、役割変更部２３が、処理装置により、現在の稼動サーバのうちの１台を、（ＳＴ２０４）で読み出された待機方式の待機サーバに切り替える。そして、役割変更部２３が、リソース管理テーブル２７の稼動サーバ２７−２、待機サーバ２７−３、待機方式２７−４の情報を更新する。
【００５３】
（ＳＴ２０６）では、待機生成・削除部２５が、処理装置により、（ＳＴ２０５）で待機サーバに切り替える前から用意されていた待機サーバを削除する。
【００５４】
以上のように、負荷上昇時であれば、時間やリソース使用状況で待機方式を選択可能であるが、負荷減少時では、次の上昇傾向が予測できないため、待機方式の選択が困難となる。そこで、負荷上昇時に選択した待機方式を記録しておき、その負荷減少時に記録した待機方式を選択することにより、そのシステムに最適な待機方式を選択できる。
【００５５】
なお、図９に示す流れでは、同一の稼動サーバ数の場合における待機方式が最新の情報に常に更新される。しかし、過去の情報の中で最もリソースを使わない待機方式、あるいは最も高速に待機サーバを稼動サーバに切り替えられる待機方式等を記録しておくとしてもよい。
【００５６】
つまり、実施の形態２に係るサーバリソース制御方式は、負荷上昇に伴い、稼動サーバを追加した後に用意した待機サーバの待機方式を稼動サーバの台数と対応させて記録し、負荷減少時の稼動サーバ台数削減時に、稼動サーバ台数に対応した待機方式を記録された方式にて用意することにより、負荷減少時の待機サーバの待機方式を負荷上昇時に選択した方式をそのまま利用可能とすることで、特別な計算をすることなく、そのシステムに適した待機方式を選択可能とすることを特徴とする。
【００５７】
実施の形態３．
この実施の形態では、サーバグループの役割に応じて、待機サーバを用意する動作を変更する方法について説明する。
【００５８】
図１１は、実施の形態３に係るリソース管理テーブル２７の例を示す図である。
図１１に示すリソース管理テーブル２７には、図８に示すリソース管理テーブル２７にフロントグループ２７−１２が追加されている。他は図８に示すリソース管理テーブル２７と同様である。
フロントグループ２７−１２は、サーバグループ名２７−１の名前が示すサーバグループのフロントエンドとして動作する他のサーバグループが存在する場合、そのサーバグループの名前が格納される。フロントエンドとして動作する他のサーバグループが存在しない場合には、“なし”との情報が格納される。
なお、フロントエンドで動作するサーバグループとは、端末８よりで動作するサーバグループである。例えば、図２に示すように、Ａｐｐ１のサーバグループよりもＷｅｂ１のサーバグループは端末８よりで動作するため、Ｗｅｂ１のサーバグループはＡｐｐ１のサーバグループのフロントエンドとして動作するサーバグループである。なお、この場合、Ａｐｐ１のサーバグループをＷｅｂ１のサーバグループのバックエンドとして動作するサーバグループと呼ぶ。
【００５９】
図１２は、リソース管理・制御サーバ６の各サーバグループに対する処理開始時における動作の流れを示すフローチャートである。なお、前提として、バックエンドサーバグループには、待機サーバを用意しておかず、リソース管理テーブル２７の待機方式２７−４に用意すべき待機方式が設定されている状態とする。
（ＳＴ３０１）では、リソース提供方式決定部２４が、リソース管理テーブル２７のフロントグループ２７−１２に格納された情報に基づき、処理装置により、フロントエンドで動作するサーバグループが存在するサーバグループか否かを判断する。
フロントエンドで動作するサーバグループが存在しないと判定した場合、処理を図６や図９に示す（ＳＴ１０１）へ進め、以降は図６や図９に示した処理が実行される。一方、フロントエンドサーバグループが存在すると判定した場合、処理を（ＳＴ３０２）へ進める。
【００６０】
（ＳＴ３０２）では、リソース提供方式決定部２４が、リソース管理テーブル２７の待機サーバ２７−３に格納された情報から、処理装置により、フロントエンドサーバグループに待機サーバが存在するか否かを判定する。
待機サーバが存在すると判定した場合、処理を図６や図９に示す（ＳＴ１０１）へ進め、以降は図６や図９に示した処理が実行される。一方、待機サーバが存在しないと判定した場合、処理を（ＳＴ３０３）へ進める。
【００６１】
（ＳＴ３０３）では、リソース提供方式決定部２４が、処理装置により、フロントエンドサーバグループに、待機サーバが追加されたか否かを判定する。なお、待機サーバが追加されたとは、初期状態で用意されていた待機サーバとは別に待機サーバが生成されたという意味である。例えば、リソース管理テーブル２７の初期台数２７−１０よりも稼動サーバ数が多く、かつ、待機サーバが用意されていれば、待機サーバが追加されたと判定できる。
追加されていないと判定した場合、所定の時間が経過した後、再度（ＳＴ３０３）を実行する。一方、追加されたと判定した場合、処理を（ＳＴ３０４）へ進める。
【００６２】
（ＳＴ３０４）では、待機生成・削除部２５が、処理装置により、リソース管理テーブル２７の待機方式２７−４に記録されている待機方式の待機サーバを生成する。
【００６３】
（ＳＴ３０５）では、待機生成・削除部２５が、生成した待機方式をリソース管理テーブル２７の選択待機方式２７−１１における稼動サーバ数に応じた項目に記録する。
【００６４】
フロントエンドのサーバグループにリソースが追加されていなければ、バックエンドのサーバグループにリソースを追加しても、フロントエンドのサーバグループがネックとなって処理量を増やせない。
そこで、以上のように、バックエンドとなるサーバグループは、フロントエンドのサーバグループの負荷が上昇し、初期状態からリソースが追加された（稼動サーバが追加された）と判断されてから、待機サーバの用意を実施する。これにより、待機サーバが使用するリソース使用量を不用に多くすることを防ぐことができる。
【００６５】
つまり、実施の形態３に係るサーバリソース制御方式は、グループ間の階層構造情報に基づき、負荷上昇時に、フロントとなるグループの稼動サーバ台数が追加されたことを契機に、そのグループのバックエンドとなるグループの待機サーバの生成を開始することでバックエンド側の待機サーバを予め用意しないようにすることで、待機サーバのためのリソース確保を抑えることを特徴とする。
【００６６】
実施の形態４．
この実施の形態では、稼動サーバが障害等で停止した場合の動作について説明する。
【００６７】
図１３は、実施の形態４に係るサーバリソース制御システムの構成図である。図１に示す構成図に対し、障害監視部３１が追加されている。追加された障害監視部３１以外の構成は図１と同様である。
障害監視部３１は、処理装置により、各サーバグループにおける稼動サーバの稼動状態を監視する。
【００６８】
図１４は、実施の形態４に係るリソース管理・制御サーバ６の稼動サーバ停止時の動作の流れを示すフローチャートである。
（ＳＴ４０１）では、障害監視部３１が、処理装置により、サーバグループ内の稼動サーバの稼動状態を監視し、障害等により稼動サーバが停止したか否かを判定する。
停止していないと判断した場合、所定の時間が経過した後、再度（ＳＴ４０１）を実行する。一方、停止したと判断した場合、処理を（ＳＴ４０２）へ進める。
【００６９】
（ＳＴ４０２）では、障害監視部３１が、（ＳＴ４０１）で稼動サーバが停止したと判断されたサーバグループについてのリソース管理テーブル２７の待機サーバ２７−３に格納された情報に基づき、処理装置により、待機サーバが用意されているか否かを判定する。
用意されていると判定した場合、処理を（ＳＴ４０８）へ進める。一方、用意されていないと判定した場合、処理を（ＳＴ４０３）へ進める。
【００７０】
（ＳＴ４０３）では、役割変更部２３が、リソース管理テーブル２７の稼動サーバ２７−２と最大数２７−６とに格納された情報から、処理装置により、稼動サーバ数が最大数に達しているか否かを判定する。
最大数に達していると判定した場合、処理を（ＳＴ４０４）へ進める。一方、最大数に達していないと判定した場合、処理を（ＳＴ４０７）へ進める。なお、ここでは、稼動サーバが停止してしまったため、最大数に達していても新たに稼動サーバを追加することが可能である。
【００７１】
（ＳＴ４０４）では、リソース提供方式決定部２４が、処理装置により、リソース提供時間管理テーブル２６の切替時間２６−２と生成時間２６−３との和が最も小さい待機方式を選択する。そして、処理を（ＳＴ４０５）へ進める。
（ＳＴ４０５）では、待機生成・削除部２５が、処理装置により、リソース提供方式決定部２４が決定した待機方式の待機サーバを生成する。
（ＳＴ４０６）では、役割変更部２３が、処理装置により、生成された待機サーバを稼動サーバに変更する。これにより、稼動サーバ数が稼動サーバが停止する前の状態（最大数）に戻る。
【００７２】
（ＳＴ４０７）では、最大数に達していない場合、待機サーバが生成中であるため、役割変更部２３が、処理装置により、待機サーバの生成が完了したか否かを判定する。
生成が完了していないと判定した場合、所定の時間が経過した後、再度（ＳＴ４０７）を実行する。一方、生成が完了したと判定した場合、処理を（ＳＴ４０８）へ進める。
【００７３】
（ＳＴ４０８）では、役割変更部２３が、リソース管理テーブル２７の待機方式２７−４に格納された情報に基づき、待機サーバを稼動サーバに切り替える。これにより、稼動サーバ数が稼動サーバが停止する前の状態に戻る。また、役割変更部２３が、リソース管理テーブル２７の稼動サーバ２７−２、待機サーバ２７−３、待機方式２７−４に格納された情報を更新する。
そして、処理を（ＳＴ４０９）へ進める。
【００７４】
（ＳＴ４０９）では、負荷傾向判断部２２が、処理装置により、将来の負荷の上昇の予測計算を行う。
図１５は、実施の形態４に係る将来の負荷の上昇の予測計算の説明図である。なお、図１５では、障害発生時に待機サーバが生成されていた場合（ＳＴ４０２でＹｅｓとなった場合）と、待機サーバが生成中であった場合（ＳＴ４０７を経由した場合）との２つの場合を示す。
稼動サーバ数が元の構成に戻った時点（図１５において、障害発生時に待機サーバの生成が完了している場合には障害発生時点、障害発生時に待機サーバの生成が完了していない場合には、待機サーバの生成が完了した時点）で、負荷傾向判断部２２が過去所定の時間（時間ｔ０）のリソースの使用状況の分布から回帰分析等の手法を用い、将来の負荷の上昇の予測計算を行う。例えば、ｙ＝ａｘ＋ｂ（ｙ：リソース使用量、ｘ：時間、ａ，ｂ：はリソース使用量から計算される値）等の近似式を導出して、導出した近似式から予測計算を行う。
【００７５】
（ＳＴ４１０）から（ＳＴ４１５）までの処理は、図６の（ＳＴ１０７）から（ＳＴ１１２）までの処理と同様である。
【００７６】
以上のように、稼動サーバに障害が発生し、現在割り当てているリソース量の減少が発生した場合には、即座に待機サーバを稼動サーバに変更し、今後のリソース増加に備えた待機サーバを用意する。これにより、障害発生時のリソース量の減少時間を最小限に食い止めることができるとともに、その後に発生する可能性がある負荷増加にも対応することができる。
また、障害発生時に生成した待機方式は記録しない。これにより、負荷減少時の待機方式は、障害の影響を受けることなく、通常時の待機方式を提供することが可能となる。
【００７７】
つまり、実施の形態４に係るサーバリソース制御方式は、サーバが障害等により切り離された場合に、待機サーバを稼動サーバに即座に変更すると共に、障害発生時点で稼動サーバのリソース使用状況の履歴情報から導出する負荷変動傾向を再計算し、その時の稼動サーバ群に割り当てられているリソース量により変化する閾値に達するまでの時間予測に基づき、稼動サーバのリソース量変更に必要な時間内に対応でき、かつ、最も待機サーバをリソース使用量の少ない形態を選択し、待機サーバの生成を実施することを特徴とする。
【００７８】
次に、実施の形態における物理計算機１、負荷分散装置５、リソース管理・制御サーバ６、端末８のハードウェア構成について説明する。
図１６は、物理計算機１、負荷分散装置５、リソース管理・制御サーバ６、端末８のハードウェア構成の一例を示す図である。
図１６に示すように、物理計算機１、負荷分散装置５、リソース管理・制御サーバ６、端末８は、プログラムを実行するＣＰＵ９１１（Ｃｅｎｔｒａｌ・Ｐｒｏｃｅｓｓｉｎｇ・Ｕｎｉｔ、中央処理装置、処理装置、演算装置、マイクロプロセッサ、マイクロコンピュータ、プロセッサともいう）を備えている。ＣＰＵ９１１は、バス９１２を介してＲＯＭ９１３、ＲＡＭ９１４、ＬＣＤ９０１（Ｌｉｑｕｉｄ  Ｃｒｙｓｔａｌ  Ｄｉｓｐｌａｙ）、キーボード９０２（Ｋ／Ｂ）、通信ボード９１５、磁気ディスク装置９２０と接続され、これらのハードウェアデバイスを制御する。磁気ディスク装置９２０（固定ディスク装置）の代わりに、光ディスク装置、メモリカード読み書き装置などの記憶装置でもよい。磁気ディスク装置９２０は、所定の固定ディスクインタフェースを介して接続される。
【００７９】
ＲＯＭ９１３、磁気ディスク装置９２０は、不揮発性メモリの一例である。ＲＡＭ９１４は、揮発性メモリの一例である。ＲＯＭ９１３とＲＡＭ９１４と磁気ディスク装置９２０とは、記憶装置（メモリ）の一例である。また、キーボード９０２、通信ボード９１５は、入力装置の一例である。また、通信ボード９１５は、通信装置（ネットワークインタフェース）の一例である。さらに、ＬＣＤ９０１は、表示装置の一例である。
【００８０】
磁気ディスク装置９２０又はＲＯＭ９１３などには、オペレーティングシステム９２１（ＯＳ）、ウィンドウシステム９２２、プログラム群９２３、ファイル群９２４が記憶されている。プログラム群９２３のプログラムは、ＣＰＵ９１１、オペレーティングシステム９２１、ウィンドウシステム９２２により実行される。
【００８１】
プログラム群９２３には、上記の説明において「仮想化ソフトウェア２」、「リソース情報収集・蓄積部２１」、「負荷傾向判断部２２」、「役割変更部２３」、「リソース提供方式決定部２４」、「待機生成・削除部２５」、「障害監視部３１」等として説明した機能を実行するソフトウェアやプログラムやその他のプログラムが記憶されている。プログラムは、ＣＰＵ９１１により読み出され実行される。
ファイル群９２４には、上記の説明において「リソース提供時間管理テーブル２６」、「リソース管理テーブル２７」に格納される情報やデータや信号値や変数値やパラメータが、「ファイル」や「データベース」の各項目として記憶される。「ファイル」や「データベース」は、ディスクやメモリなどの記録媒体に記憶される。ディスクやメモリなどの記憶媒体に記憶された情報やデータや信号値や変数値やパラメータは、読み書き回路を介してＣＰＵ９１１によりメインメモリやキャッシュメモリに読み出され、抽出・検索・参照・比較・演算・計算・処理・出力・印刷・表示などのＣＰＵ９１１の動作に用いられる。抽出・検索・参照・比較・演算・計算・処理・出力・印刷・表示のＣＰＵ９１１の動作の間、情報やデータや信号値や変数値やパラメータは、メインメモリやキャッシュメモリやバッファメモリに一時的に記憶される。
【００８２】
また、上記の説明におけるフローチャートの矢印の部分は主としてデータや信号の入出力を示し、データや信号値は、ＲＡＭ９１４のメモリ、その他光ディスク等の記録媒体やＩＣチップに記録される。また、データや信号は、バス９１２や信号線やケーブルその他の伝送媒体や電波によりオンライン伝送される。
また、上記の説明において「〜部」として説明するものは、「〜回路」、「〜装置」、「〜機器」、「〜手段」、「〜機能」であってもよく、また、「〜ステップ」、「〜手順」、「〜処理」であってもよい。また、「〜装置」として説明するものは、「〜回路」、「〜機器」、「〜手段」、「〜機能」であってもよく、また、「〜ステップ」、「〜手順」、「〜処理」であってもよい。さらに、「〜処理」として説明するものは「〜ステップ」であっても構わない。すなわち、「〜部」として説明するものは、ＲＯＭ９１３に記憶されたファームウェアで実現されていても構わない。或いは、ソフトウェアのみ、或いは、素子・デバイス・基板・配線などのハードウェアのみ、或いは、ソフトウェアとハードウェアとの組み合わせ、さらには、ファームウェアとの組み合わせで実施されても構わない。ファームウェアとソフトウェアは、プログラムとして、ＲＯＭ９１３等の記録媒体に記憶される。プログラムはＣＰＵ９１１により読み出され、ＣＰＵ９１１により実行される。すなわち、プログラムは、上記で述べた「〜部」としてコンピュータ等を機能させるものである。あるいは、上記で述べた「〜部」の手順や方法をコンピュータ等に実行させるものである。
【符号の説明】
【００８３】
１  物理計算機、２  仮想化ソフトウェア、３  仮想サーバ、４，９  通信回線、５  負荷分散装置、６  リソース管理・制御サーバ、７  インターネット／イントラネット、８  端末、１０  ストレージ、１１  仮想サーバディスクイメージ、１２  仮想サーバテンプレート、２１  リソース情報収集・蓄積部、２２  負荷傾向判断部、２３  役割変更部、２４  リソース提供方式決定部、２５  待機生成・削除部、２６  リソース提供時間管理テーブル、２７  リソース管理テーブル、３１  障害監視部。
【図１】
2011243162.tif 000003
【図２】
2011243162.tif 000004
【図３】
2011243162.tif 000005
【図４】
2011243162.tif 000006
【図５】
2011243162.tif 000007
【図６】
2011243162.tif 000008
【図７】
2011243162.tif 000009
【図８】
2011243162.tif 000010
【図９】
2011243162.tif 000011
【図１０】
2011243162.tif 000012
【図１１】
2011243162.tif 000013
【図１２】
2011243162.tif 000014
【図１３】
2011243162.tif 000015
【図１４】
2011243162.tif 000016
【図１５】
2011243162.tif 000017
【図１６】
2011243162.tif 000018