JP2020126498A - サーバシステム及びサーバ資源割り当てプログラム - Google Patents

Abstract

【課題】スケールアウトとスケールアップの最適な選択を行うこと。【解決手段】管理装置３は、集計テーブル３０と、スケールアップ処理部３３と、スケールアウト処理部３４と、選択部３８とを有する。選択部３８は、集計テーブル３０に基づいて、現状のスケール回数に１を加えた回数のスケールアウトの処理数とスケールアップの処理数を比較し、処理数が多い増強方法を選択する。そして、選択部３８は、スケールアウトを選択すると、スケールアウト処理部３４にスケールアウトを指示し、スケールアップを選択すると、スケールアップ処理部３３にスケールアップを指示する。【選択図】図７

Description

本発明は、サーバシステム及びサーバ資源割り当てプログラムに関する。

クラウドシステム等の仮想化環境において、ＶＭ（Virtual Machine：仮想マシン）の処理能力が不足すると、スケールアウト又はスケールアップが行われる。ここで、ＶＭは、仮想的なコンピュータである。また、スケールアウトはＶＭを追加することであり、スケールアップはＣＰＵ（Central Processing Unit）、メインメモリ等のＶＭのリソースを追加することである。

一方、ＶＭの処理負荷が低下すると、スケールイン又はスケールダウンが行われる。ここで、スケールインはＶＭを削除することであり、スケールダウンはＶＭのリソースを削除することである。

図２０は、スケールアウトとスケールインを説明するための図である。図２０において、ＶＭホスト＃９１及びＶＭホスト＃９２で表されるＶＭホスト９１は、ＶＭ９２が稼働する物理マシンであり、管理装置９は、ＶＭホスト９１で稼働するＶＭ９２を管理する装置である。

図２０に示すように、管理装置９は、ＶＭ９２から処理量を取り出す（ｔ８１）。ここで、処理量には、例えば、ＶＭ２が受け取ったリクエスト数と処理数と処理の滞留の有無を示す滞留ありフラグとが含まれる。そして、スケールアウトでは、管理装置９は、滞留ありフラグに基づいて処理数が限界か判断し（ｔ８２）、処理数が限界の場合はＶＭ９２を追加する（ｔ８３）。図２０では、ＶＭホスト＃９１で稼働するＶＭ９２が１台追加される。

一方、スケールインでは、管理装置９は、ＶＭ９２から処理量を取り出し（ｔ８４）、例えば、処理数が所定の閾値より小さいか判断し（ｔ８５）、所定の閾値より小さい場合、ＶＭ９２を削除する（ｔ８６）。図２０では、ＶＭホスト＃９２で稼働するＶＭ９２が１台削除される。

図２１は、スケールアップとスケールダウンを説明するための図である。図２１に示すように、スケールアップでは、管理装置９は、ＶＭ９２から処理量を取り出し（ｔ９１）、処理数が限界か判断し（ｔ９２）、処理数が限界の場合はリソースを追加する（ｔ９３）。図２１では、ＶＭホスト＃９１で稼働するＶＭ９２の１台にリソースが追加される。

一方、スケールダウンでは、管理装置９は、ＶＭ９２から処理量を取り出し（ｔ９４）、処理数が所定の閾値より小さいか判断し（ｔ９５）、所定の閾値より小さい場合、リソースを削除する（ｔ９６）。図２１では、ＶＭホスト＃９１で稼働するＶＭ９２の１台から一部のリソースが削除される。

なお、仮想サーバが所属する仮想サーバ群にスケールアウト方式又はスケールアップ方式のいずれが採用されているかに基づいて、スケールアウト又はスケールアップを動的に行う従来技術がある。

また、クライアントが、サービスが提供される際のサービス品質を示す品質情報を測定し、測定した品質情報を管理サーバに送信し、管理サーバは、送信された品質情報に基づいて、クライアントへのサービスの提供に適するサーバを選択する従来技術がある。

また、負荷テスト中のＶＭの稼働状況を解析し、性能が不足している場合にスケールアウトとスケールアップのいずれか一方又は両方をユーザに提示することで、最適化されたＶＭを提供する従来技術がある。

特開２０１０−３３２９２号公報 特開２０１２−２２５５５号公報 特開２０１８−２６０５９号公報

ＶＭの処理能力が不足した場合、スケールアウトとスケールアップのいずれかを適切に選択することは困難であるという問題がある。一般に、Ｗｅｂサーバにはスケールアウトが適し、ＤＢサーバにはスケールアップが適すると言われている。しかしながら、スケールアウトとスケールアップのいずれが適するかはＶＭの業務内容等に依存するため、適切な選択は困難である。

本発明は、１つの側面では、スケールアウトとスケールアップの最適な選択を行うことを目的とする。

１つの態様では、サーバシステムは、仮想マシンが動作するサーバと該仮想マシンを管理する管理装置とを有する。前記管理装置は、集計情報記憶部と増強部とを有する。前記集計情報記憶部は、スケールアップしたときの限界の処理数を示す第１処理数とスケールアウトしたときの限界の処理数を示す第２処理数を記憶する。前記増強部は、前記仮想マシンの処理に滞留がある場合、前記集計情報記憶部が記憶する前記第１処理数と前記第２処理数を比較し、前記第１処理数が大きい場合には、スケールアップを行い、前記第２処理数が大きい場合には、スケールアウトを行う。

１つの側面では、本発明は、スケールアウトとスケールアップの最適な選択を行うことができる。

図１は、実施例１に係る管理装置によるスケールアウトとスケールアップの選択方法を説明するための第１の図である。 図２は、実施例１に係る管理装置によるスケールアウトとスケールアップの選択方法を説明するための第２の図である。 図３は、実施例１に係る管理装置によるスケールアウトとスケールアップの選択方法を説明するための第３の図である。 図４は、実施例１に係る管理装置によるスケールアウトとスケールアップの選択方法を説明するための第４の図である。 図５は、増強の回数毎の特定結果の一例を示す図である。 図６は、図５に示した特定結果をツリーによって表した図である。 図７は、ＶＭ及び管理装置の機能構成を示す図である。 図８は、処理量テーブルの一例を示す図である。 図９は、集計テーブルの一例を示す図である。 図１０は、ＶＭによる処理量テーブルの更新処理のフローを示すフローチャートである。 図１１は、管理装置による増強縮小処理のフローを示すフローチャートである。 図１２は、集計テーブル更新処理のフローを示すフローチャートである。 図１３は、低負荷時処理のフローを示すフローチャートである。 図１４Ａは、集計テーブルのリセット範囲を説明するための第１の図である。 図１４Ｂは、集計テーブルのリセット範囲を説明するための第２の図である。 図１５は、実施例２に係る管理装置の機能構成を示す図である。 図１６は、実施例２に係る集計テーブルの一例を示す図である。 図１７は、リセット処理のフローを示すフローチャートである。 図１８は、経過時間を更新する処理のフローを示すフローチャートである。 図１９は、実施例に係る管理プログラムを実行するコンピュータのハードウェア構成を示す図である。 図２０は、スケールアウトとスケールインを説明するための図である。 図２１は、スケールアップとスケールダウンを説明するための図である。

以下に、本願の開示するサーバシステム及びサーバ資源割り当てプログラムの実施例を図面に基づいて詳細に説明する。なお、この実施例は開示の技術を限定するものではない。

まず、実施例１に係る管理装置によるスケールアウトとスケールアップの選択方法について図１〜図６を用いて説明する。図１〜図４は、実施例１に係る管理装置によるスケールアウトとスケールアップの選択方法を説明するための図である。図１〜図４において、実施例１に係るサーバシステム１０は、ＶＭホスト＃１及びＶＭホスト＃２で表される２台のＶＭホスト１と管理装置３とを有する。ＶＭホスト１は、ＶＭ２が稼働するサーバ（物理マシン）であり、管理装置３は、ＶＭホスト１で稼働するＶＭ２を管理する装置である。なお、サーバシステム１０は、１台又は３台以上のＶＭホスト１を有してもよい。

図１（ａ）に示すように、管理装置３は、負荷が増加すると、例えば、スケールアウトを試行する。具体的には、管理装置３は、処理数が限界か判断し（ｔ１）、限界の場合、スケールアウトを実施する（ｔ２）。図１（ａ）では、ＶＭホスト＃２で表されるＶＭホスト１にＶＭ２が追加される。

その後、管理装置３は、負荷がさらに増加すると、処理数が限界か判断し（ｔ３）、限界の場合、限界の処理数を記録する（ｔ４）。すなわち、管理装置３は、スケールアウト実施後に処理数が限界になったときの処理数を記録することで、スケールアウトした場合の処理数を特定する。

その後、負荷が低下すると、管理装置３は、図１（ｂ）に示すように、スケールインを行う。具体的には、管理装置３は、ＶＭホスト＃２のＶＭ２の処理数が小さいか判断し（ｔ５）、小さい場合、ＶＭホスト＃２からＶＭ２を削除する（ｔ６）。

そして、次に負荷が増加すると、管理装置３は、図２（ｃ）に示すように、スケールアップを試行する。具体的には、管理装置３は、処理数が限界か判断し（ｔ７）、限界の場合、スケールアップを実施する（ｔ８）。図２（ｃ）では、ＶＭホスト＃１で表されるＶＭホスト１のＶＭ２にリソースが追加される。

その後、管理装置３は、負荷がさらに増加すると、処理数が限界か判断し（ｔ９）、限界の場合、限界の処理数を記録する（ｔ１０）。すなわち、管理装置３は、スケールアップ実施後に処理数が限界になったときの処理数を記録することで、スケールアップした場合の処理数を特定する。

その後、負荷が低下すると、管理装置３は、図２（ｄ）に示すように、スケールダウンを行う。具体的には、管理装置３は、ＶＭホスト＃１のＶＭ２の処理数が小さいか判断し（ｔ１１）、小さい場合、ＶＭホスト＃１のＶＭ２からリソースを削除する（ｔ１２）。

そして、次に負荷が増加すると、管理装置３は、図３（ｅ）に示すように、履歴からスケールアウトを選択する。ここで、履歴とは、スケールアウトした場合にｔ４で記録された処理数とスケールアップをした場合にｔ１０で記録された処理数である。スケールアウトをした場合の処理数がスケールアップをした場合の処理数より大きい場合には、スケールアウトが選択され、スケールアップをした場合の処理数がスケールアウトをした場合の処理数より大きい場合には、スケールアップが選択される。ここでは、スケールアウトをした場合の処理数がスケールアップをした場合の処理数より大きいと仮定し、管理装置３は、スケールアウトを選択する。具体的には、管理装置３は、処理数が限界か判断し（ｔ１３）、限界の場合、履歴に基づきスケールアップを実施する（ｔ１４）。

このように、管理装置３は、スケールアウトとスケールアップを行った際の限界の処理数を履歴として記録し、その後負荷が増加した場合に、履歴に基づいて、スケールアウトとスケールアップのいずれかを選択する。

また、１回目のスケールアウト又はスケールアップの実行後、さらに負荷が増加すると、管理装置３は、２回目のスケールアウトとスケールアップを試行し、試行後に処理数が限界になったときの処理数を記録する。

具体的には、管理装置３は、図４（ｆ）に示すように、処理数が限界か判断し（ｔ１５）、限界の場合、２回目の増強としてスケールアウトを実施する（ｔ１６）。その後、管理装置３は、負荷がさらに増加すると、処理数が限界か判断し（ｔ１７）、限界の場合、限界の処理数を記録する（ｔ１８）。

その後、負荷が低下し、スケールダウンを行った後、負荷が増加すると、管理装置３は、図４（ｇ）に示すように、処理数が限界か判断し（ｔ１９）、限界の場合、２回目の増強としてスケールアップを実施する（ｔ２０）。その後、管理装置３は、負荷がさらに増加すると、処理数が限界か判断し（ｔ２１）、限界の場合、限界の処理数を記録する（ｔ２２）。

そして、管理装置３は、ｔ１８で記録した処理数がｔ２２で記録した処理数より大きい場合には、２回目の増強としてスケールアウトを選択し、ｔ２２で記録した処理数がｔ１８で記録した処理数より大きい場合には、２回目の増強としてスケールアップを選択する。

このように、管理装置３は、１回目〜ｎ回目の増強を行い、増強後の限界の処理数を記録し、スケールアウト実施後の処理数とスケールアップ実施後の処理数を比較してスケールアウトとスケールアップのいずれを選択するかを増強の回数毎に特定する。ここで、ｎは２以上の整数である。なお、各回における処理数は、負荷の変動に伴ってＶＭ２の増強と縮小を繰り返す過程で記録されるため、記録される順番は、負荷の変動に依存する。

図５は、増強の回数毎の特定結果の一例を示す図である。図５において、「ｏｕｔ」はスケールアウトを示し、「ｕｐ」はスケールアップを示す。図５に示すように、１回目の増強では、スケールアウトの処理数が「８０００」であり、スケールアップの処理数が「９０００」である。このため、管理装置３は、１回目の増強ではスケールアップを行うと判定する。

また、２回目の増強では、スケールアウトの処理数が「１６０００」であり、スケールアップの処理数が「１５０００」である。このため、管理装置３は、２回目の増強ではスケールアウトを行うと判定する。同様に、管理装置３は、３回目の増強ではスケールアウトを行うと判定し、４回目の増強ではスケールアップを行うと判定する。図５では、○が判定により選択された増強方法を示す。

図６は、図５に示した特定結果をツリーによって表した図である。実線は試行の結果選択されたルートを表し、破線は選択されなかったルートを表し、点線は最適ではないので試行されていないルートを表す。

このように、管理装置３は、増強後の限界の処理数に基づいて増強回数毎にスケールアウト又はスケールアップを選択するので、最適な選択を行うことができる。

次に、ＶＭ２及び管理装置３の機能構成について説明する。図７は、ＶＭ２及び管理装置３の機能構成を示す図である。図７に示すように、ＶＭ２は、処理量テーブル２０と、リクエスト処理部２１と、リクエスト数集計部２２と、処理数集計部２３と、処理滞留判断部２４とを有する。管理装置３は、集計テーブル３０と、ＶＭ処理量取得部３１と、集計テーブル更新部３２と、スケールアップ処理部３３と、スケールアウト処理部３４と、低負荷時処理部３５と、スケールダウン処理部３６と、スケールイン処理部３７と、選択部３８とを有する。

処理量テーブル２０は、処理量に関する情報を記憶するテーブルである。図８は、処理量テーブル２０の一例を示す図である。図８に示すように、処理量テーブル２０には、リクエスト数と、処理数と、滞留ありフラグとが含まれる。

リクエスト数は、ＶＭ２が受信したリクエストの数である。処理数は、ＶＭ２が処理したリクエストの数である。リクエスト数及び処理数は、例えば、１分毎の集計数である。滞留ありフラグは、リクエストの処理に滞留がある（ｙｅｓ）か否（ｎｏ）かを示すフラグである。例えば、リクエスト数が処理数より多い場合に、滞留ありフラグに「ｙｅｓ」が設定される。

リクエスト処理部２１は、リクエストを処理する。リクエストは、例えば、ネットワークを介してクライアント装置から送信される。リクエスト数集計部２２は、ＶＭ２が受信したリクエストの数を集計し、処理量テーブル２０に格納する。処理数集計部２３は、リクエスト処理部２１が処理したリクエストの数を集計し、処理量テーブル２０に格納する。処理滞留判断部２４は、リクエスト数と処理数に基づいて処理が滞留しているか否かを判断し、判断結果を処理量テーブル２０に格納する。

集計テーブル３０は、現在のユーザ毎の増強状態ととともに、スケールアウト及びスケールアップを行った後の限界の処理数を示す限界処理数をユーザ毎増強回数毎に記憶するテーブルである。図９は、集計テーブル３０の一例を示す図である。図９に示すように、集計テーブル３０は、ユーザ名と、スケールアウトフラグと、スケール回数と、スケール種別と、リクエスト数と、処理数とを記憶する。

ユーザ名は、ＶＭ２のユーザを識別する名前である。スケールアウトフラグは、増強後の限界処理数が同じである場合にスケールアウトを優先する（ｙｅｓ）か否（ｎｏ）かを示すフラグである。スケールアウトフラグは、ＶＭ２が処理を行う業務の特性に応じてユーザにより指定される。ユーザは、例えば、業務停止をできるだけ回避したい場合には、スケールアウトを指定し、ある程度の時間停止しても影響が少ない業務の場合には、スケールアップを指定する。

スケール回数は、増強を行った回数である。スケール回数の初期値は「０」である。スケール種別は、「ｏｕｔ」又は「ｕｐ」である。

リクエスト数は、スケールアウト又はスケールアップを行った後の限界のリクエスト数を示す限界リクエスト数である。処理数は、スケールアウト又はスケールアップを行った後の限界処理数である。リクエスト数及び処理数の初期値は「０」である。

例えば、ユーザ名が「ｕｓｅｒ０１」であるユーザのＶＭ２については、スケールアウト優先ではなく、現在の増強回数は「２」であり、２回目の増強としてスケールアップが行われた状態にある。また、１回目の増強につてはスケールアウトが有効であり、２回目の増強につてはスケールアップが有効であり、３回目の増強についてはスケールアウトが未試行のため、スケールアウトとスケールアップのいずれが有効かが特定されていない。

図７に戻って、ＶＭ処理量取得部３１は、ＶＭ２から処理量テーブル２０の情報を取得する。集計テーブル更新部３２は、ＶＭ処理量取得部３１により取得された処理量テーブル２０の滞留ありフラグが「ｙｅｓ」の場合に、集計テーブル３０を更新する。スケールアップ処理部３３は、スケールアップを実行する。スケールアウト処理部３４は、スケールアウトを実行する。

低負荷時処理部３５は、ＶＭ２の処理が滞留していない場合に、ＶＭ２の縮小が可能か否かを判定し、縮小可能である場合に、スケール状態に基づいてスケールイン又はスケールダウンを行う。ここで、スケール状態は、集計テーブル３０の現在の状態のスケール種別である。

また、ＶＭ２の縮小が可能か否かを、低負荷時処理部３５は、（今回のリクエスト数）／（限界処理数）が（スケール回数）／（スケール回数＋１）より小さいか否かに基づいて判定する。スケール回数が１の場合には、（スケール回数）／（スケール回数＋１）＝１／２であり、スケール回数が２の場合には、（スケール回数）／（スケール回数＋１）＝２／３である。スケール回数が３の場合には、（スケール回数）／（スケール回数＋１）＝３／４である。

スケールダウン処理部３６は、スケールダウンを実行する。スケールイン処理部３７はスケールインを実行する。

選択部３８は、集計テーブル３０に基づいてスケールアウトかスケールアップかを選択する。具体的には、選択部３８は、現状のスケール回数に１を加えた回数のスケールアウトの処理数とスケールアップの処理数を比較し、処理数が多い増強方法を選択する。

処理数が等しい場合には、選択部３８は、スケールアウトフラグが「ｙｅｓ」であればスケールアウトを選択し、スケールアウトフラグが「ｎｏ」であればスケールアップを選択する。

選択部３８は、スケールアウトを選択した場合には、スケールアウト処理部３４にスケールアウトを指示し、スケールアップを選択した場合には、スケールアップ処理部３３にスケールアップを指示する。

次に、ＶＭ２による処理量テーブル２０の更新処理のフローについて説明する。図１０は、ＶＭ２による処理量テーブル２０の更新処理のフローを示すフローチャートである。なお、図１０に示す処理は、例えば１分毎等で定期的に実行される。

図１０に示すように、ＶＭ２は、リクエスト数を集計し（ステップＳ１）、処理量テーブル２０のリクエスト数を更新する。そして、ＶＭ２は、処理数を集計し（ステップＳ２）、処理量テーブル２０の処理数を更新する。そして、ＶＭ２は、処理の滞留があるか否かを判定し（ステップＳ３）、ある場合には、処理量テーブル２０の滞留ありフラグを「ｙｅｓ」で更新し（ステップＳ４）、ない場合には、処理量テーブル２０の滞留ありフラグを「ｎｏ」で更新する（ステップＳ５）。

このように、ＶＭ２が定期的に処理量テーブル２０を更新するので、管理装置３は、処理量テーブル２０の情報を取得することで、ＶＭ２の最新の負荷状態を知ることができる。

次に、管理装置３による増強縮小処理のフローについて説明する。ここで、増強縮小処理とは、ＶＭ２の負荷が増加した場合にはＶＭ２を増強し、ＶＭ２の負荷が低下した場合にはＶＭ２を縮小する処理である。図１１は、管理装置３による増強縮小処理のフローを示すフローチャートである。なお、図１１に示す処理は、例えば５分毎等で定期的に実行される。

図１１に示すように、管理装置３は、ＶＭ２から処理量テーブル２０の情報を取得し（ステップＳ１１）、取得した情報の滞留ありフラグが「ｙｅｓ」であるか否かを判定する（ステップＳ１２）。そして、取得した情報の滞留ありフラグが「ｙｅｓ」である場合には、管理装置３は、集計テーブル３０を更新する集計テーブル更新処理を実行し（ステップＳ１３）、スケール回数に１を加算する（ステップＳ１４）。

そして、管理装置３は、集計テーブル３０のスケール回数のｕｐの処理数が「０」であるか否かを判定し（ステップＳ１５）、「０」である場合には、スケールアップを実行し、スケール状態を「ｕｐ」に設定する（ステップＳ１６）。

一方、集計テーブル３０のスケール回数のｕｐの処理数が「０」でない場合には、管理装置３は、集計テーブル３０のスケール回数のｏｕｔの処理数が「０」であるか否かを判定する（ステップＳ１７）。そして、集計テーブル３０のスケール回数のｏｕｔの処理数が「０」である場合には、管理装置３は、スケールアウトを実行し、スケール状態を「ｏｕｔ」に設定する（ステップＳ１８）。

一方、集計テーブル３０のスケール回数のｏｕｔの処理数が「０」でない場合には、管理装置３は、ｕｐの処理数がｏｕｔの処理数より大きいか否かを判定する（ステップＳ１９）。そして、ｕｐの処理数がｏｕｔの処理数より大きい場合には、管理装置３は、スケールアップを実行し、スケール状態を「ｕｐ」に設定する（ステップＳ２０）。

一方、ｕｐの処理数がｏｕｔの処理数より大きくない場合には、管理装置３は、ｏｕｔの処理数がｕｐの処理数より大きいか否かを判定する（ステップＳ２１）。そして、ｏｕｔの処理数がｕｐの処理数より大きい場合には、管理装置３は、スケールアウトを実行し、スケール状態を「ｏｕｔ」に設定する（ステップＳ２２）。

一方、ｏｕｔの処理数がｕｐの処理数より大きくない場合には、ｏｕｔの処理数がｕｐの処理数と等しいので、管理装置３は、集計テーブル３０のスケールアウトフラグが「ｙｅｓ」であるか否かを判定する（ステップＳ２３）。そして、スケールアウトフラグが「ｙｅｓ」である場合には、管理装置３は、スケールアウトを実行し、スケール状態を「ｏｕｔ」に設定する（ステップＳ２４）。

一方、スケールアウトフラグが「ｙｅｓ」でない場合には、管理装置３は、スケールアップを実行し、スケール状態を「ｕｐ」に設定する（ステップＳ２５）。

また、ステップＳ１２において、滞留ありフラグが「ｙｅｓ」でない場合には、管理装置３は、低負荷であるか否かを判定して低負荷である場合にＶＭ２を縮小する低負荷時処理を実行する（ステップＳ２６）。

このように、管理装置３は、ＶＭ２から取得した情報に基づいてＶＭ２の増強及び縮小を行うので、ＶＭ２の負荷変動に対応することができる。

図１２は、集計テーブル更新処理のフローを示すフローチャートである。図１２に示すように、集計テーブル更新部３２は、スケール回数が「０」か否かを判定し（ステップＳ３１）、「０」である場合には、処理を終了する。

一方、スケール回数が「０」でない場合には、集計テーブル更新部３２は、スケール状態は「ｕｐ」か否かを判定する（ステップＳ３２）。そして、「ｕｐ」の場合には、集計テーブル更新部３２は、集計テーブル３０内のｕｐのリクエスト数と処理数を処理量テーブル２０の情報で更新する（ステップＳ３３）。一方、「ｕｐ」でない場合には、集計テーブル更新部３２は、集計テーブル３０内のｏｕｔのリクエスト数と処理数を処理量テーブル２０の情報で更新する（ステップＳ３４）。

このように、集計テーブル更新部３２が集計テーブル３０のｕｐとｏｕｔのリクエスト数と処理数を更新することで、選択部３８は、集計テーブル３０に基づいてスケールアウトかスケールアップかを選択することができる。

図１３は、低負荷時処理のフローを示すフローチャートである。図１３に示すように、低負荷時処理部３５は、集計テーブル３０の現スケール回数は「１」以上であるか否かを判定する（ステップＳ４１）。すなわち、低負荷時処理部３５は、スケールアップ又はスケールアウトをしている状態であるか否かを判定する。そして、集計テーブル３０の現スケール回数は「１」以上でない場合には、低負荷時処理部３５は、処理を終了する。

一方、集計テーブル３０の現スケール回数が「１」以上である場合には、低負荷時処理部３５は、限界処理数が格納済であるか否かを判定し（ステップＳ４２）、格納済でない場合には、低負荷時処理部３５は、処理を終了する。

一方、限界処理数が格納済である場合には、低負荷時処理部３５は、今回のリクエスト数が限界処理数×（スケール回数）／（スケール回数＋１）より小さいか否かを判定し（ステップＳ４３）、小さくない場合には、処理を終了する。

一方、今回のリクエスト数が限界処理数×（スケール回数）／（スケール回数＋１）より小さい場合には、低負荷時処理部３５は、スケール状態が「ｕｐ」であるか否かを判定する（ステップＳ４４）。そして、スケール状態が「ｕｐ」である場合には、低負荷時処理部３５は、スケールダウン処理部３６に指示してスケールダウン処理を実施する（ステップＳ４５）。一方、スケール状態が「ｕｐ」である場合には、低負荷時処理部３５は、スケールイン処理部３７に指示してスケールイン処理を実施する（ステップＳ４６）。

そして、低負荷時処理部３５は、スケール回数から１を減算し（ステップＳ４７）、スケール回数が「０」であるか否かを判定する（ステップＳ４８）。そして、スケール回数が「０」である場合には、低負荷時処理部３５は、スケール状態を「０」とし（ステップＳ４９）、スケール回数が「０」でない場合には、スケール状態をスケール回数のスケール種別とする（ステップＳ５０）。ここで、スケール回数のスケール種別とは、集計テーブル３０のスケール回数の処理数が大きい方のスケール種別であり、２つの処理数が等しい場合には、スケールアウトフラグにより決定されるスケール種別である。

このように、低負荷時処理部３５が処理数の減少にともなってスケールダウン又はスケールインを行うことで、ＶＭ２及びリソースの無駄な使用を防ぐことができる。

上述してきたように、実施例１では、選択部３８は、集計テーブル３０に基づいて、現状のスケール回数に１を加えた回数のスケールアウトの処理数とスケールアップの処理数を比較し、処理数が多い増強方法を選択する。また、処理数が等しい場合には、選択部３８は、スケールアウトフラグが「ｙｅｓ」であればスケールアウトを選択し、スケールアウトフラグが「ｎｏ」であればスケールアップを選択する。したがって、管理装置３は、スケールアウトとスケールアップの最適な選択を行うことができる。

また、実施例１では、管理装置３は、ＶＭ２の処理が滞留し、集計テーブル３０のスケール回数のｕｐの処理数が「０」である場合には、スケールアップを実行する。そして、管理装置３は、次にＶＭ２の処理が滞留した際の処理数を、集計テーブル３０のスケール回数のｕｐの処理数として格納する。また、管理装置３は、ＶＭ２の処理が滞留し、集計テーブル３０のスケール回数のｏｕｔの処理数が「０」である場合には、スケールアウトを実行する。そして、管理装置３は、次にＶＭ２の処理が滞留した際の処理数を、集計テーブル３０のスケール回数のアウトの処理数として格納する。したがって、管理装置３は、集計テーブル３０を作成することができる。

また、実施例１では、管理装置３は、実際の負荷変動に応じてスケールアップ、スケールダウン、スケールアウト及びスケールインを行いながら集計テーブル３０を作成するので、正確な集計テーブル３０を作成することができる。

ところで、業務内容の変更等により、集計テーブルの処理数の更新が必要になる場合がある。そこで、実施例２では、集計テーブルをリセットする管理装置について説明する。ただし、集計テーブルを全てリセットすると、集計テーブルの再作成に時間がかかる。このため、実施例２に係る管理装置は、ＶＭ２の増強状態の経過時間に応じてリセット範囲を特定し、特定したリセット範囲で集計テーブルをリセットする。なお、集計テーブルをリセットするとは、集計テーブルのリクエスト数と処理数を０にすることである。

図１４Ａ及び図１４Ｂは、集計テーブルのリセット範囲を説明するための図である。図１４Ａでは、３回目の増強が行われた増強状態と４回目の増強が行われた増強状態でＶＭ２の増強状態が遷移している。このような増強状態の場合、実施例２に係る管理装置は、集計テーブルの４回目の増強の部分だけをリセットする。実施例２に係る管理装置は、一時的にＶＭ２の増強状態が他の増強状態に変わっても、他の増強状態の経過時間が短い場合には、集計テーブルの４回目の部分だけをリセットする。

一方、図１４Ｂでは、過去に４回目までの増強が行われたが、現在は増強なしの増強状態と１回目の増強が行われた増強状態でＶＭ２の増強状態が遷移している。このような増強状態の場合、実施例２に係る管理装置は、集計テーブルを全てリセットする。

図１５は、実施例２に係る管理装置の機能構成を示す図である。なお、ここでは説明の便宜上、図７に示した各部と同様の役割を果たす機能部については同一符号を付すこととしてその詳細な説明を省略する。図１５に示すように、実施例２に係る管理装置３ａは、図７に示した管理装置３と比較して、集計テーブル３０の代わりに集計テーブル３０ａを有し、新たにリセット部３９と経過時間更新部４０とを有する。

集計テーブル３０ａは、集計テーブル３０が記憶する情報と比較して、新たに増強状態の経過時間を記憶する。図１６は、実施例２に係る集計テーブル３０ａの一例を示す図である。図１６に示すように、集計テーブル３０ａには、集計テーブル３０が記憶する情報に経過時間が追加される。

例えば、ユーザ名が「ｕｓｅｒ０１」であるユーザは、１回目の増強が行われてから２１６時間（２４ｈ×９ｄａｙ）、２回目の増強が行われてから１６８時間（２４ｈ×７ｄａｙ）、３回目の増強が行われてから１２０時間（２４ｈ×５ｄａｙ）経過している。

また、ユーザ名が「ｕｓｅｒ０２」であるユーザは、１回目の増強が行われてから１６８時間（２４ｈ×７ｄａｙ）経過し、２回目の増強が行われてから９６時間（２４ｈ×４ｄａｙ）経過し、３回目の増強は行われていない。

リセット部３９は、集計テーブル３０ａの経過時間に基づいて、リセット範囲を特定し、特定したリセット範囲で集計テーブル３０ａをリセットする。リセット部３９は、スケール回数について、履歴の最大回数から経過時間が所定の閾値未満でない最大の回数までをリセット範囲として特定する。ここで、履歴の最大回数とは、集計テーブル３０ａのｕｐ及びｏｕｔの処理数が０でない最大のスケール回数である。リセット部３９は、例えば１週間毎等で全てのユーザについて定期的に実行される。

例えば、図１６に示した「ｕｓｅｒ０１」の場合、履歴の最大回数は３であり、所定の閾値を１時間とすると、経過時間が１時間未満でない最大の回数は３であるので、スケール回数の３がリセット範囲である。また、「ｕｓｅｒ０２」の場合、履歴の最大回数は３であり、経過時間が１時間未満でない最大の回数は２であるので、スケール回数が３と２をリセット範囲とする。

経過時間更新部４０は、例えば５分毎に起動され、全てのユーザについて、現在のスケール回数以下のスケール回数の経過時間に５分を加算する。経過時間更新部４０は、正の整数ｍについてｍ分毎に起動された場合には、ｍ分を加算する。

図１７は、リセット処理のフローを示すフローチャートである。図１７に示すように、リセット部３９は、履歴の最大回数を現在回数とし、現在回数の経過時間を集計テーブル３０ａから取り出し（ステップＳ６１）、経過時間は所定の閾値未満か否かを判定する（ステップＳ６２）。

そして、経過時間が所定の閾値未満である場合には、リセット部３９は、現在回数の範囲をリセットする（ステップＳ６３）。ここで、現在回数の範囲とは、集計テーブル３０ａのスケール回数が現在回数であるリクエスト数と処理数である。そして、リセット部３９は、次に小さいスケール回数はあるか否かを判定し（ステップＳ６４）、ある場合には、現在回数から１を減算し、現在回数の経過時間を集計テーブル３０ａから取り出す（ステップＳ６５）。そして、リセット部３９は、ステップＳ６２へ戻る。

一方、次に小さいスケール回数がない場合には、全スケール回数の経過時間をリセットする（ステップＳ６６）。また、ステップＳ６２において、経過時間が所定の閾値未満でない場合には、現在回数の範囲をリセットし（ステップＳ６７）、全スケール回数の経過時間をリセットする（ステップＳ６６）。

このように、リセット部３９は、履歴の最大回数から経過時間が所定の閾値未満でない最大の回数までのリセット回数の範囲をリセットするので、管理装置３ａは、業務内容の変更等に効率よく対応することができる。

図１８は、経過時間を更新する処理のフローを示すフローチャートである。なお、図１８は、５分毎に実行された場合を示す。図１８に示すように、経過時間更新部４０は、現在のスケール回数を取り出し（ステップＳ７１）、スケール回数以下の経過時間に５分を加算する（ステップＳ７２）。そして、経過時間更新部４０は、次のユーザ名の値があるか否かを判定し（ステップＳ７３）、ある場合には、ステップＳ７１に戻り、なお場合には、処理を終了する。

このように、経過時間更新部４０が経過時間を更新するので、リセット部３９は、経過時間に基づいて集計テーブル３０ａのリセットを行うことができる。

上述してきたように、実施例２では、経過時間更新部４０が経過時間を更新し、リセット部３９が経過時間に基づいてリセット範囲と特定し、特定したリセット範囲で集計テーブル３０ａをリセットする。したがって、管理装置３ａは、業務内容の変更等に効率よく対応することができる。

なお、実施例では、管理装置３及び３ａについて説明したが、管理装置３及び３ａが有する構成をソフトウェアによって実現することで、同様の機能を有する管理プログラムをサーバ資源割り当てプログラムとして得ることができる。そこで、管理プログラムを実行するコンピュータについて説明する。

図１９は、実施例に係る管理プログラムを実行するコンピュータのハードウェア構成を示す図である。図１９に示すように、コンピュータ５０は、メインメモリ５１と、ＣＰＵ５２と、ＬＡＮ（Local Area Network）インタフェース５３と、ＨＤＤ（Hard Disk Drive）５４とを有する。また、コンピュータ５０は、スーパーＩＯ（Input Output）５５と、ＤＶＩ（Digital Visual Interface）５６と、ＯＤＤ（Optical Disk Drive）５７とを有する。

メインメモリ５１は、プログラムやプログラムの実行途中結果等を記憶するメモリである。ＣＰＵ５２は、メインメモリ５１からプログラムを読み出して実行する中央処理装置である。ＣＰＵ５２は、メモリコントローラを有するチップセットを含む。

ＬＡＮインタフェース５３は、コンピュータ５０をＬＡＮ経由で他のコンピュータに接続するためのインタフェースである。ＨＤＤ５４は、プログラムやデータを格納するディスク装置であり、スーパーＩＯ５５は、マウスやキーボード等の入力装置を接続するためのインタフェースである。ＤＶＩ５６は、液晶表示装置を接続するインタフェースであり、ＯＤＤ５７は、ＤＶＤの読み書きを行う装置である。

ＬＡＮインタフェース５３は、ＰＣＩエクスプレス（ＰＣＩｅ）によりＣＰＵ５２に接続され、ＨＤＤ５４及びＯＤＤ５７は、ＳＡＴＡ（Serial Advanced Technology Attachment）によりＣＰＵ５２に接続される。スーパーＩＯ５５は、ＬＰＣ（Low Pin Count）によりＣＰＵ５２に接続される。

そして、コンピュータ５０において実行される管理プログラムは、コンピュータ５０により読み出し可能な記録媒体の一例であるＤＶＤに記憶され、ＯＤＤ５７によってＤＶＤから読み出されてコンピュータ５０にインストールされる。あるいは、管理プログラムは、ＬＡＮインタフェース５３を介して接続された他のコンピュータシステムのデータベース等に記憶され、これらのデータベースから読み出されてコンピュータ５０にインストールされる。そして、インストールされた管理プログラムは、ＨＤＤ５４に記憶され、メインメモリ５１に読み出されてＣＰＵ５２によって実行される。

１，９１ ＶＭホスト
２，９２ ＶＭ
３，３ａ，９ 管理装置
１０ サーバシステム
２０ 処理量テーブル
２１ リクエスト処理部
２２ リクエスト数集計部
２３ 処理数集計部
２４ 処理滞留判断部
３０，３０ａ 集計テーブル
３１ ＶＭ処理量取得部
３２ 集計テーブル更新部
３３ スケールアップ処理部
３４ スケールアウト処理部
３５ 低負荷時処理部
３６ スケールダウン処理部
３７ スケールイン処理部
３８ 選択部
３９ リセット部
４０ 経過時間更新部
５０ コンピュータ
５１ メインメモリ
５２ ＣＰＵ
５３ ＬＡＮインタフェース
５４ ＨＤＤ
５５ スーパーＩＯ
５６ ＤＶＩ
５７ ＯＤＤ

Claims (7)

1. 仮想マシンが動作するサーバと該仮想マシンを管理する管理装置とを有するサーバシステムにおいて、
   前記管理装置は、
   スケールアップしたときの限界の処理数を示す第１処理数とスケールアウトしたときの限界の処理数を示す第２処理数を記憶する集計情報記憶部と、
   前記仮想マシンの処理に滞留がある場合、前記集計情報記憶部が記憶する前記第１処理数と前記第２処理数を比較し、前記第１処理数が大きい場合には、スケールアップを行い、前記第２処理数が大きい場合には、スケールアウトを行う増強部と
   を有することを特徴とするサーバシステム。
2. 前記増強部は、前記第１処理数と前記第２処理数が等しい場合には、スケールアウトとスケールアップのうち前記仮想マシンのユーザにより指定された方で増強を行うことを特徴とする請求項１に記載のサーバシステム。
3. 前記仮想マシンの処理に滞留があって前記第１処理数が未測定であることを示す値である場合にスケールアップの実行により計測された前記第１処理数と、前記仮想マシンの処理に滞留があって前記第２処理数が未測定であることを示す値である場合にスケールアウトの実行により計測された前記第２処理数を、前記集計情報記憶部に格納する格納部をさらに有することを特徴とする請求項１又は２に記載のサーバシステム。
4. 前記集計情報記憶部は、スケールアップ又はスケールアウトが実行される回数を示すスケール回数に対応付けて前記第１処理数と前記第２処理数を記憶し、
   前記増強部は、スケールアップ又はスケールアウトを実行する回数に基づいて前記集計情報記憶部が記憶する前記第１処理数と前記第２処理数を比較することを特徴とする請求項１、２又は３に記載のサーバシステム。
5. 前記格納部は、前記仮想マシンの負荷変動に応じて行われたスケールアップ、スケールダウン、スケールアウト及びスケールインの際に計測された前記第１処理数及び前記第２処理数を前記集計情報記憶部に格納することを特徴とする請求項３に記載のサーバシステム。
6. 前記スケール回数毎の増強状態の経過時間に基づいてリセットの対象とするスケール回数の範囲を特定し、特定した範囲のスケール回数に対応づけられた前記第１処理数と前記第２処理数を未測定であることを示す値にリセットするリセット部をさらに有することを特徴とする請求項４に記載のサーバシステム。
7. コンピュータに、
   サーバで動作する仮想マシンをスケールアップしたときの限界の処理数を示す第１処理数とスケールアウトしたときの限界の処理数を示す第２処理数を集計情報記憶部に記憶し、
   前記仮想マシンの処理に滞留がある場合、前記集計情報記憶部が記憶する前記第１処理数と前記第２処理数を比較し、前記第１処理数が大きい場合には、スケールアップを行い、前記第２処理数が大きい場合には、スケールアウトを行う
   処理を実行させることを特徴とするサーバ資源割り当てプログラム。

Images