JP5332065B2 - クラスタ構成管理方法、管理装置及びプログラム - Google Patents

Description

本発明は、クラスタ構成管理方法、クラスタ構成管理装置及びプログラムに係り、特に、負荷変動に伴い計算機資源の割当量の変更が必要な計算機システムにおいて、計算機資源の最適な割当てを行うクラスタ構成管理方法、クラスタ構成管理装置及びプログラムに関する。

企業で利用される計算機システム（以下、企業システムとする）では、時間や時期によって負荷が変動する。複数のサーバで構築するクラスタシステムでサービスを提供している企業システムにおいて、最大の負荷予測に合わせて計算機資源を用意しておくことは、余剰なコンピューティングリソースを消費し、維持費用の面においても無駄となる。このような課題に対して、負荷変動に応じて、サービスレベルを維持するために、計算機資源を制御する技術が提案されている。

特許文献１には、負荷変動を予測し、負荷の増減に応じてサーバのスケールイン、スケールアウトを適用することにより、サービスレベルを維持するための技術が開示されている。

また、特許文献２には、複数のアプリケーションが動作しているＷｅｂシステムにおける負荷予測方式が開示されている。

一方で、近年は、１台の物理サーバを独立した仮想サーバとして動作させるサーバ仮想化技術が広まっている。サーバ仮想化技術を導入した環境では、負荷が低い場合に、余剰リソースを他の仮想サーバに回すことにより、サーバの集約率の向上などが行える。そのため、動的な負荷変動への対応技術として、サーバ仮想化技術の重要度が高まっている。

非特許文献１には、１つの物理マシン内で複数のアプリケーションに応じてリソースの分配比率を決定する方式が提案されている。又、非特許文献２には、仮想サーバでのグリッド環境において、ＣＰＵの負荷予測に基づいてネットワーク負荷を中期的に予測する技術が開示されている。

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

Power and performance management of virtualized computing environments via look ahead control, 2008. グリッド環境でのCPU負荷予測に基づくネットワーク負荷中期予測, 電子情報通信学会論文誌. D-I,2004.

ところで、サーバ仮想化環境では、計算機システムの負荷変動に対してリソースの有効利用を図る場合、スケールイン、スケールアウト以外にも、ＣＰＵリソースの割り当て量の設定、仮想ＣＰＵの追加など多種のリソース量変更技術が提案されている。これら種々の技術は、計算機資源の割り当て変更の実行に必要となる時間やその実行によりその後発揮する性能も大きく異なるものである。

一般に負荷の変動幅は時間帯、業務内容及びイベントにより多種多様であり、状況に応じて適切なリソースの割り当て量を変更する手段を適用するのが好ましい。

例えば、所定の負荷の変動に追従する場合において、スケールアウトによるサーバの追加が間に合わない場合でも、実行に比較的時間がかからないＣＰＵリソースの割り当て量の追加を先に実施することにより、負荷変動に対応できる場合がある。逆に、負荷変動が少ない場合は、仮想サーバを追加するのではなく、より、少ない単位でのリソースの追加により、計算機資源の有効活用を図ることができる。

このように、複数のリソース量変更技術の中から、将来のある時刻に対する負荷予測に対して、実行に必要な時間を考慮しつつ選択可能なリソース量変更手段の組み合わせを選択することで、迅速又は適切に負荷変動に追従することが望まれる。

本発明は、これらの問題点に鑑みてなされたもので、負荷変動が発生した場合に、計算機資源の割当てを効率的に行い、業務のサービスレベルを維持するためのクラスタの管理に関する技術を提供するものである。

本発明は、プロセッサとメモリを含む計算機資源を備えた物理計算機と、前記計算機資源を仮想化して複数の仮想計算機に割り当てる仮想化部と、前記複数の仮想計算機でクラスタを構成し、前記仮想化部を管理する管理部と、を有する計算機システムのクラスタ構成管理方法であって、
前記管理部が、前記クラスタに対する所定時間後の負荷情報の予測値を演算する第１のステップと、
前記管理部が、前記クラスタを構成する前記仮想計算機の現在の計算機資源の割り当て量と、所定時間後の計算機資源の割り当て量とを保持する第２のステップと、
前記管理部が、前記クラスタの構成を変更するために利用可能な計算機資源の複数の変更手段を保持する第３のステップと、
前記管理部が、前記クラスタを構成する前記仮想計算機に割り当てた現在の計算機資源の割り当て量と、前記負荷情報の予測値と、から前記複数の変更手段の組み合わせを選択し、前記選択された現在の変更手段の組み合わせで、前記負荷情報の予測値を処理可能であるか否かを判定し、前記選択された複数の変更手段の組み合わせでは前記負荷情報の予測値を処理できないと判定された場合に、前記複数の変更手段の組み合わせまたは実行予定時刻を更新する第４のステップと、
前記管理部が、前記実行予定時刻に到達した変更手段を前記仮想化部に通知して実行させる第５のステップと、
を含む。

したがって、本発明は、仮想計算機でクラスタを提供する際に、負荷変動に追随しつつ、クラスタで使用する計算機資源の割り当て量を抑制しながら、クラスタが提供する業務のサービスレベルを維持し、計算機資源の有効活用が可能となる。

本発明の実施形態を示し、業務クラスタを構成する計算機システムのブロック図である。 本発明の実施形態を示し、負荷履歴テーブルの一例を示す説明図である。 本発明の実施形態を示し、資源管理テーブルを構成する物理計算機資源管理テーブルの一例を示す説明図である。 本発明の実施形態を示し、資源管理テーブルを構成する仮想計算機資源管理テーブルの一例を示す説明図である。 本発明の実施形態を示し、資源予約テーブルの一例を示す説明図である。 本発明の実施形態を示し、変更手段管理テーブルを構成する手段テーブルの一例を示す説明図である。 本発明の実施形態を示し、変更手段管理テーブルを構成する変更条件テーブルの一例を示す説明図である。 本発明の実施形態を示し、資源変更手段実施手順の一例を示す説明図である。 本発明の実施形態を示し、制御部で行われる処理の一例を示すフローチャートである。 本発明の実施形態を示し、手段選択処理で行われる処理の一例を示すフローチャートである。 本発明の実施形態を示し、負荷予測の上昇時の手段選択処理の選択結果の一例を示すグラフである。 本発明の実施形態を示し、負荷予測の下降時の手段選択処理の選択結果の一例を示すグラフである。 本発明の実施形態を示し、再構成処理で行われる処理の一例を示すフローチャートである。 本発明の実施形態を示し、実行部で行われる処理の一例を示すフローチャートである。

以下、本発明の一実施形態を添付図面に基づいて説明する。

図１は、本発明の第１の実施形態を示し、クラスタを構成する計算機システムの構成を示すブロック図である。

本計算機システムは、業務システム１１８と管理部１０１とで構成される。業務システム１１８は、複数の業務クラスタ１２３より構成される。ひとつの業務クラスタ１２３は、負荷分散機１１９、ひとつ以上の業務サーバ１２０で構成される。ひとつの業務クラスタ１２３はひとつの業務（またはサービス）を提供する。図示の例では、３つの業務クラスタ１２３で３種の業務を提供する例を示す。また、負荷分散機１１９は、業務クラスタ１２３毎に、あるいは、業務システム１１８毎に配置される。

業務サーバ１２０は、物理計算機１２２の計算機資源を仮想化するハイパーバイザ１２１により作成される仮想計算機として構成される。複数の物理計算機１２２は、ＣＰＵ１２２１とメモリ１２２２及びストレージ装置（図示省略）を備えており、これらの計算機資源は複数の業務クラスタ１２３で共用される。なお、ＣＰＵ１２２１は複数のプロセッサコアを備える。各業務クラスタ１２３の業務サーバ１２０に対する物理計算機１２２の計算機資源（物理計算機資源）の割り当ては、ひとつの業務クラスタ１２３に対して複数の物理計算機１２２の計算機資源を割り当てることができる。あるいは、ひとつの物理計算機１２２の計算機資源を複数の業務クラスタ１２３に割り当てることができる。

各業務クラスタ１２３は、クライアント（計算機）１１７からネットワーク５０を介してリクエストを受け付け、所定の業務処理を実行し、処理結果をクライアント１１７に返信する。負荷分散機１１９は、業務システム１１８に対する負荷情報を取得するためのインタフェースを備え、業務サーバ１２０間の負荷を制御する。また、ハイパーバイザ１２１は、ハイパーバイザ１２１上で実行される仮想計算機（業務サーバ１２０）に対する計算機資源の割当、解除、および、新たな仮想計算機を追加するためのインタフェースを有する。

管理部１０１は、入力部１０９、監視部１１０、制御部１１１、実行部１１６、負荷履歴テーブル１０３、資源管理テーブル１０４、資源予約テーブル１０５、変更手段管理テーブル１０６、資源変更手段実施手順１０７で構成される。負荷履歴テーブル１０３、変更手段管理テーブル１０６、資源変更手段実施手順１０７は、業務クラスタ１２０ごとに作成される。管理部１０１は、物理計算機１０２が実行する。物理計算機１０２はＣＰＵ１０２１とメモリ１０２２及びストレージ装置（図示省略）を備え、メモリ１０２２にロードした制御部１１１、監視部１１０、実行部１１６、入力部１０９をＣＰＵ１０２１が実行することで、各機能を実現する。このため、物理計算機１０２は図示しない管理ネットワーク（またはネットワーク５０）を介して業務システム１１８に接続される。

なお、管理部１０１は、業務システム１２３を構成する物理計算機１２２上の仮想計算機として実行してもよい。

監視部１１０では、業務クラスタ１２３が受け取るリクエストの件数（例えば、件数／秒）を負荷情報として計測し、時系列で計測結果を、負荷履歴テーブル１０３へ記録する。監視部１１０による業務クラスタ１２３のリクエストの測定は、例えば、負荷分散機１１９が受信した単位時間当たりのリクエスト数を監視部１１０が取得することで行われる。また、負荷分散機１１９は、測定した負荷情報を管理部１０１に送信する。

入力部１０９は、ユーザ（または計算機システムの管理者）が操作する入力装置（図示省略）からシステムの構成情報や業務サーバ１２０に対して、管理部１０１が実行可能な計算機資源の割当変更、解除などの資源変更手段及び資源変更手段の組み合わせに関する情報を受け付け、資源管理テーブル１０４、及び、変更手段管理テーブル１０６に記録する。

なお、各業務クラスタ１２３の各業務サーバ１２０に対する物理計算機１２２の計算機資源の割り当て開始は、管理者などが予め設定した資源管理テーブル１０４の情報に基づいて実行部１１６が各物理計算機１２２のハイパーバイザ１２１に対して指令することで行われる。

また、資源変更手段は、仮想計算機で構成される業務サーバ１２０及び業務クラスタ１２３に対する物理的な計算機資源の割り当ての態様を指す。本実施形態では、資源変更手段の一例として、業務サーバ１２０へ割り当てるＣＰＵ１２２１（またはプロセッサコア）の数の追加を「ＣＰＵ割当追加」とし、業務サーバ１２０へ割り当てるＣＰＵ１２２１（またはプロセッサコア）の使用率の増大を「ＣＰＵ割当率追加」とし、業務クラスタ１２３への仮想計算機（業務サーバ１２０）の追加を「仮想サーバ追加」とし、業務サーバ１２０へ割り当てたＣＰＵ１２２１（またはプロセッサコア）の削減を「ＣＰＵ割当削減」とし、業務サーバ１２０へ割り当てたＣＰＵ１２２１（またはプロセッサコア）の使用率の削減を「ＣＰＵ割当率削減」とし、業務クラスタ１２３に割り当てた仮想計算機（業務サーバ１２０）の削減を「仮想サーバ削減」とした例を示す。また、「ＣＰＵ割当追加」、「ＣＰＵ割当追加」は、物理計算機１２２のＣＰＵ１２２１が複数のプロセッサコアを有する場合は、プロセッサコアの単位で割り当ての追加または削減を行うことができる。また、論理プロセッサ（例えば、ハイパースレッドなど）を有するＣＰＵ１２２１の場合、プロセッサコアの追加、削減は、論理プロセッサ単位で追加または削減を行うようにしてもよい。また、資源変更手段としては、ＣＰＵ１２２１やプロセッサコアの追加、削減の他、メモリ１２２２の割り当て量の増大、削減を行うようにしてもよい。

図２は、負荷履歴テーブル１０３の一例を示す説明図である。負荷履歴テーブル１２０１は、負荷分散機１１９で負荷が測定された時刻（時刻１２０２）と、測定された時刻におけるクライアント１１７からの単位時間当たりのリクエスト到着件数１２０３とを含む。負荷履歴テーブル１０３は、監視部１１０によって更新される。なお、監視部１１０は、業務クラスタ１２３毎に負荷履歴テーブル１０３を作成し、それぞれを更新する。

なお、負荷分散機１１９は受信したリクエストに加えて、業務サーバ１２０に分配したリクエストを測定し、業務サーバ１２０毎の負荷情報を監視部１１０に送信してもよい。この場合、負荷履歴テーブル１０３には、リクエストの分配先の業務サーバ１２０毎にリクエスト数を管理してもよい。これにより、業務サーバ１２０毎に負荷情報を管理することができる。

図３Ａ、図３Ｂは、資源管理テーブル１０４の一例を示す説明図である。資源管理テーブル１０４は、業務システム１１８を提供する物理計算機１２２に関する計算機資源を管理する物理計算機資源管理テーブル２０１と、仮想計算機（業務サーバ１２０）に関する計算機資源を管理する仮想計算機資源管理テーブル２１１とを含む。資源管理テーブル１０４は、監視部１１０がハイパーバイザ１２１から取得した情報と、入力部１０９から受け付けた情報により更新される。

図３Ａは、物理計算機資源管理テーブル２０１を示し、図３Ｂは、仮想計算機資源管理テーブル２１１を示す。

図３Ａの物理計算機資源管理テーブル２０１は、サーバ名２０２、ＩＰアドレス２０３、ＣＰＵ資源２０４、メモリ資源２０６などの各種資源の搭載量と、現在割当て済み量（２０４〜２０７）を記録するＣＰＵ資源割当済２０５とメモリ資源割当済量２０７から一つのエントリが構成される。例えば、行２０８では、サーバ名２０２がサーバＡの物理計算機では、ＣＰＵ資源に関しては、２コア搭載（ＣＰＵ資源２０４）されており、１つ目のコアは資源を１００％割当済みであり、２つ目のコアは３０％の資源を割当済みである（ＣＰＵ資源割当済２０５）であることを示している。

図３Ｂの仮想計算機資源管理テーブル２１１は、物理計算機資源管理テーブル２０１と同様に、サーバ名２１２、ＩＰアドレス２１３、ＣＰＵ資源最大２１４、メモリ資源最大２１６などの各種資源の搭載量と、現在割り当てられている量（ＣＰＵ資源割当済み２１５、メモリ資源割当済２１７）、及び、当該仮想計算機を実行する物理計算機１２２の識別子が物理計算機２１８に格納される。

図４は、資源予約テーブル１０５の一例を示す説明図である。資源予約テーブル１０５は、手段選択処理１１３で作成または更新される。

資源予約テーブル１０５は、変更する計算機資源の予約の開始時刻を表す時刻３０２、サーバ名３０３、予約対象の計算機資源を表す資源種別３０４、及び、その計算機資源の予約量を示す変化量３０５を有する。例えば、行３０６は、時刻１０：１０：１０以降に、サーバＢがＣＰＵ資源を１コア分余分に使用するための予約を表している。

図５Ａ、図５Ｂは、変更手段管理テーブル１０６の一例を示す説明図である。変更手段管理テーブル１０６は、管理者などが入力部１０９を介して予め設定した値が格納される。

変更手段管理テーブル１０６は、制御部１１１で選択可能な計算機資源の資源変更手段を管理する手段テーブル４０１と、計算機資源の変更による性能の変動幅を格納する変動幅条件テーブル４１１とを含む。図５Ａは、手段テーブル４０１を示し、図５Ｂは、変動幅条件テーブル４１１を示す。

手段テーブル４０１は、選択可能な計算機資源の資源変更手段の種別を記載した手段４０２、当該資源変更手段の実行により変化する計算機資源の種別と変化量を格納する対象資源４０３、当該資源変更手段の実行により変化するクラスタシステムの能力（性能）を格納する変動幅４０４、当該資源変更手段の実行を完了するまでに必要な時間を記載する実行時間４０５から構成される。変動幅４０４で用いる指標は、応答時間（遅延時間）や処理可能なリクエスト量などが考えられるが、ここでは、処理可能なリクエスト数（例えば件／秒）を用いる。例えば、「手段４０２」が「ＣＰＵコア数」の場合、ＣＰＵコアを１つ追加すると、単位時間当たりに処理可能なリクエスト件数が変動幅４０４の「８５」だけ増加し、計算機資源の追加処理には実行時間４０５に格納された「１０秒」が必要であることを示している。あるいは、逆に資源の割当てを解除（削減）する場合、コアの割当てを１つ解除することにより、単位時間当たりに処理可能なリクエスト数が８５だけ減少することを示している。変動幅４０４の値は事前に業務システム１１８（または業務クラスタ１２３）に対し負荷を掛け、計算機資源量（計算機資源の割り当て量）の変化による処理可能リクエスト件数の変化を測定することで求めることができる。

なお、変動幅４０４の処理可能リクエスト件数の変化は、同じ計算機資源量の変化でも、そのときの他の条件により異なる場合がある。その場合、変動幅とその条件を変動幅条件テーブル４１１へ設定し、変動幅欄４０４には、実際の変動幅を求めるために参照する変動幅条件テーブル４１１の名称を記録する。変動幅条件テーブルの例を図５Ｂのテーブル４１１に示す。ここでは、ＣＰＵ資源の追加及び削除は、ＣＰＵコアの最大能力の１０％の単位で行うことを想定する。この例の場合、ＣＰＵの使用率４１２を「７０％」から「８０％」へ１０％増加させると処理可能なリクエスト数が変動幅４１３の「１０」だけ増えるが、「８０％」から「９０％」へ１０％増加させた場合は、処理可能なリクエスト数が「５」件しか増えないことを示している。

制御部１１１は、ＣＰＵ１０２１で実行され、メモリ１０２上に展開された所定のプログラムとの協働により、負荷予測処理１１２、手段選択処理１１３、判定処理１１４及び再構成処理１１５が実行される。

負荷予測処理１１２では、将来のある時刻Ｎまでの業務クラスタ１２３の負荷変動の予測値を求める処理を実行する。より具体的には、負荷履歴テーブル１０３に記録されている情報を元に、現在時刻より時間Ｎだけ先の時点までの負荷変動を予測する。負荷変動の予測方法は、例えば、前年度、先月、先日などの過去の負荷測定データ（負荷履歴テーブル１０３）に基づいた循環変動値を用いる。もしくは、さらに循環変動値を元に、直近の負荷測定データからマルコフモデルを元に予測した負荷の負荷値による補正を行う方式などを使うことができる。本実施形態の負荷予測については、上記従来例に示した特許文献２等に記載されている公知または周知の技術を採用することができる。

手段選択処理１１３は、負荷予測処理１１２の予測結果に対して、利用可能な計算機資源量などの制約条件を満たしつつ、後述する評価式による評価値が最高となる時刻Ｔまでに実行する計算機資源変更手段と、計算機資源変更手段の実施時刻などで構成される資源変更手段実施手順１０７を求める処理である。

より具体的には、各物理計算機１２２や仮想計算機（業務サーバ１２０）で使用可能な計算機資源量や、計算機資源量の変更手段を実施する場合に必要になる時間などの制約条件を考慮しつつ、負荷予測処理１１２で予測された負荷量を処理できるだけの計算機資源を業務クラスタ１２３に対して割り当てるための、資源変更手段実施手順１０７を求める。なお、制約を満たす資源変更手段実施手順１０７は多くの場合複数存在するため、予め与えられた評価式において、評価値が最高になる手順を選択する。なお、制約条件は、未割当の計算機資源の量と、資源変更手段が完了するまでの時間の例を示すが、他の制約条件を加えてもよい。また、資源変更手段が完了するまでの時間の制約条件は、資源変更手段の実施が完了するまで、現時点の計算機資源の割り当てで処理可能な負荷（リクエスト）を、負荷の予測値が超えない場合に、当該制約条件を満たすものとする。

判定処理１１４では、時刻Ｔまでの時間より短い間隔で、各時点での新たに予測した負荷に対して、現在登録されている資源変更手段実施手順１０７が適切か否かを判定する。

再構成処理１１５では、上記判定処理１１４での判定結果が適切でないと判定された場合に、組合せの見直しをする処理である。

図６は、資源変更手段実施手順１０７の一例を示す説明図である。この資源変更手段実施手順１０７は、実行部１１６が、資源予約テーブル１０５に基づいて、計算機資源量を変更する手段を実施する時刻５０２、実施する手段５０３、実施対象のサーバ５０４、手段５０３に対応するコマンドがすでに実行中か否かを示す実行状態欄５０５で構成される。例えば、行５０６は、時刻１０時１０分１０秒に、ある仮想計算機（サーバＢ）に対して、ＣＰＵの割当量を１０％増加すること、また、現在、このコマンドは未実行の状態であることを示している。なお、資源変更手段毎に予めコマンドが設定されており、実行部１１６が資源変更手段実施手順を読み込んで、制御対象の物理計算機１２２のハイパーバイザ１２１に対して資源変更手段毎のコマンドを送信する。

図７は、制御部１１１で行われる処理の一例を示すフローチャートである。この処理は、管理部１０１により一定の周期（再予測間隔、例えば数秒毎、かつ所定時間Ｎ未満）で呼び出される。また、本処理の初回の呼び出しの前に、再選択時刻として、現在時刻Ｔから所定時間Ｎだけ先の時刻（予測範囲）が設定される。なお、再選択時刻は、負荷予測を求めて計算機資源の割り当てを再評価する時刻である。

まず、制御部１１１は、負荷予測処理１１２により、業務クラスタ１２３毎に現在時刻Ｔから所定時間Ｎだけ先の時間までの負荷の予測値を求める（Ｓ６０１）。

次に、制御部１１１は、現在時刻が、再選択時刻であるか否かを判断する（Ｓ６０２）。再選択時刻の場合（Ｓ６０２：Ｙｅｓ）、制御部１１１は、ステップＳ６０７の処理に進み、手段選択処理１１３により、ステップＳ６０１で求めた負荷の予測値に対する業務クラスタ１２３を構成する業務サーバ１２０の資源変更手段の実施手順を求める（Ｓ６０７）。

現在時刻が、再選択時刻でない場合（Ｓ６０２：Ｎｏ）、制御部１１１は、ステップ６０３において、現在の資源変更手段実施手順１０７が、ステップ６０１で求められた負荷予測に対して有効か否かを判定する（Ｓ６０３）。有効か否かの判定は、負荷予測処理１１２で予測された負荷（予測値）に対して、現在予定されている資源変更手段の実行で負荷予測（現在時刻＋Ｎにおける予想リクエスト数）に追従可能か否かで判定する。つまり、制御部１１１は、現在時刻で業務クラスタ１２３に割り当てられた計算機資源の割り当て量を、資源管理テーブル１０４（物理計算機資源管理テーブル２０１、仮想計算機資源管理テーブル２１１）から取得し、各業務サーバ１２０ごとに処理可能なリクエスト数を求める。なお、処理可能なリクエスト数は、例えば、ＣＰＵ１２２１やプロセッサコアの割当数や割り当て率に応じて予め処理可能なリクエスト数を設定することで制御部１１１で演算することができる。そして、制御部１１１は、業務クラスタ１２３を構成する各業務サーバ１２０の処理可能なリクエスト数の和を当該業務クラスタ１２３の処理可能な負荷とする。

そして、現在の資源変更手段実施手順１０７で変更される予定の計算機資源の割り当て量に応じた処理可能なリクエスト数（変動幅４０４）の和を処理可能な負荷の変化分とする。

制御部１１１は、上記処理可能な負荷と処理可能な負荷の変化分の和が、負荷の予測値以上であれば、現在の資源変更手段実施手順１０７が、ステップ６０１で求められた負荷予測に対して有効であると判定し、上記処理可能な負荷と処理可能な負荷の変化分の和が、負荷の予測値未満であれば、無効と判定する。

制御部１１１は、現在予定されている資源変更手段が有効であり見直しの必要がないと判断する場合（Ｓ６０４：Ｎｏ）、処理を終了する。

一方、現在予定されている資源変更手段が有効でなく見直しが必要と判定される場合（ステップＳ６０４：Ｙｅｓ）、制御部１１１は、再構成処理１１５により、資源変更手段実施手順１０７における実行実施時刻の補正を試みる（６０５）。もし補正が行えた場合（ステップＳ６０６：Ｙｅｓ）、処理を終了する。

一方、ステップ６０５の補正が行えなかった場合（ステップＳ６０６：Ｎｏ）、ステップ６０７へ進む。ステップ６０７では、手段選択処理１１３により、現在の負荷予測に対する、新たな資源変更手段実施手順１０７を作成する。また、再選択時刻を、ステップ６０１における予測で用いた、現在時刻Ｔから所定時間Ｎだけ先の時刻に設定する。

上記処理により、仮想化環境上の業務クラスタ１２３において、負荷変動に追従するために業務クラスタ１２３毎に負荷を予測し、負荷の予測結果に対して業務クラスタ１２３を構成する各業務サーバ１２０に割り当てる計算機資源を制御する。この計算機資源の割り当ては、計算機資源の割り当て量の変更に利用できる資源変更手段と、当該資源変更手段による許容量（処理可能なリクエスト数）の変化と、割り当て変更の実行完了に必要な時間を条件として、現在、および、将来（現在時刻＋時間Ｎ）の計算機資源の予約状況を考慮して、負荷変動に追従でき、かつ、使用する計算機資源の割り当て量の少ない資源変更手段の組み合わせを選択する。そして、選択した資源変更手段の組み合わせが負荷変動に追従できなくなった場合には、各手段の実行の時刻を調整することにより、再構成を試みる。さらに、再構成に失敗した場合、再度、資源変更手段の組み合わせを求めることができる。

以下に各処理の詳細を示す。

図８は、手段選択処理１１３で行われる処理の一例を示すフローチャートである。この処理は、図７のステップ６０７で行われる処理の詳細を示す。この処理では、制約条件を満たす資源変更手段の組み合わせが複数存在する場合に、最も評価値の高い資源変更手段の組み合わせを選択する。

まず、制御部１１１は、最大の評価値を記録するための変数に初期値として負の最大値を設定する（７０１）。

次に、ステップ７０２において、制御部１１１は、各種計算機資源の制約（未割当の計算機資源の量）を満たす資源変更手段の組み合わせのうち未処理のものを１つ選択する。本処理の詳細は、後述する。

ステップ７０２で、制約を満たす資源変更手段の組み合わせが選択できた場合（Ｓ７０３：Ｙｅｓ）、Ｓ７０４において、Ｓ７０２において見つかった資源変更手段の組み合わせに対する評価値を求める。評価値の求め方は後述する。

次にステップ７０５において、ステップ７０４で求めた評価値が変数Ｍａｘに格納されている値より大きいか調べる。

評価値が変数Ｍａｘよりも大きい場合（Ｓ７０５：Ｙｅｓ）ステップ７０６へ進み、変数ＭａｘにＳ７０４で求めた評価値を格納すると共に、現在選択されている資源変更手段の組み合わせを変数などに記録する。

ステップ７０３において選択できる組み合わせが見つからなかった場合（つまり、すべての組み合わせの選択が終了した場合）、ステップ７０７において、ステップ７０６で記録された変数Ｍａｘに格納されている評価値をもつ組み合わせを資源変更手段実施手順１０７へ格納する。

次に、ステップ７０８において、ステップ７０６において記録されたＭａｘに格納されている評価値をもつ資源変更手段の組み合わせを実施するために必要となる計算機資源の予約を、資源予約テーブル１０５へエントリを追加することにより実施する。

図９、図１０は、図８に示したステップ７０２における資源変更手段の組合せを選択する処理の一例を示すグラフである。図９は業務クラスタ１２３に計算機資源を追加する例を示す。図１０は業務クラスタ１２３から計算機資源を削減する例を示す。

図９、図１０において、グラフの縦軸は負荷（リクエスト量／秒）であり、横軸は経過時間である。

まず、図９において、曲線８０１は、現在時刻Ｔ０（８０２）より前は、実際に測定された負荷を示し、現在時刻Ｔ０（８０２）より後は、予測された負荷を表している。

閾値８０３は、現在時刻Ｔ０において業務クラスタ１２３に割り当てられた資源を用いて処理可能な負荷の量を示している。この閾値に対して、資源変更手段として、ＣＰＵ資源割当追加コマンドを２回、仮想計算機の追加コマンドを１回行う場合を考える。この場合、負荷予測８０１と閾値８０３が交わる時刻Ｔ１（８０４）と、現在時刻Ｔ０からＣＰＵ資源追加コマンドの実行時間経過時間のうち、後の時刻がコマンド実行完了時刻となる。この例では、時刻Ｔ１（８０４）がコマンド完了時刻、その時刻からコマンド実行時間を差し引いた時刻が、コマンド実行時刻となる。このコマンドにより、時刻Ｔ１（８０４）以降では、閾値は新たに、８０８となる。

同様の手順で、２回目のＣＰＵ資源割当の実施完了時刻はＴ２（８０５）、仮想計算機追加完了時刻はＴ３（８０６）となる。また、これらにより、閾値は、負荷予測時刻ＴＮ（８０７）までの負荷に対応可能となり、これ以上の追加は必要ない。

以上により、各資源変更手段の実施手順が求まる。本実施形態では、複数の資源変更手段の実行順序を含めて資源変更手段の組み合わせとする。

次に、この資源変更手段実施手順が計算機資源の制約を満たしているか否かを判定する。例えば、最初のコマンドの制約は、時刻Ｔ１（８０４）以降で、割当可能なＣＰＵ資源の空きが、物理計算機１２２上に存在し、かつ、ＣＰＵ資源を割当可能な仮想計算機が存在することである。これらは、制御部１１１が資源管理テーブル１０４と、資源予約テーブル１０５を参照することで計算機資源の制約を満たしているか否かを判定することができる。資源管理テーブル１０４は現在時刻Ｔ０における計算機資源の割当状況を管理している。一方、資源予約テーブル１０５は、今後の他の業務クラスタ１２３（または業務サーバ１２０）で実施予定のコマンドで使用する計算機資源に関する情報を管理する。

資源予約テーブル１０５の例を図４に示す。資源予約テーブル１０５は、上述のように、サーバ名３０３、変化する資源種別３０４、変化量３０５、及びコマンドを実行する予定の時刻３０２により構成される。例えば、行３０６は、時刻Ｔにおいて、仮想サーバＢに対するＣＰＵ資源割当（コアを１つ追加）が行われる予定を示している。

また、これは、同時刻に仮想サーバＢが実行される物理計算機１２２のＣＰＵ資源の空き容量が割当実施量だけ減少することを示している。なお、業務システム１１８の保守作業や、物理計算機１２２の増強などによる資源量の変化も、本資源予約テーブル１０５により管理する。

次に、負荷の予測値が下降の場合の例を図１０に示す。この場合、最初に実行するコマンドの変化量を、現在時刻Ｔ０（９０３）の閾値９０２から引いた値が、負荷曲線９０１と交わる時刻が最初のコマンド実行完了候補時刻（Ｔ１（９０３））となる。負荷上昇時と同様にコマンドの実行時間から導きだされる最速実行完了時間とのうち、遅いほうが実行完了時刻となる。以下、新たな閾値を元に、時刻ＴＮ（９０７）までの区間で、適用できるコマンドがなくなるまで行うことにより、実行するコマンドの組み合わせが２つのＣＰＵ割り当て削減と１つの仮想サーバの削減となる。

なお、求められた負荷予測が増加、下降を繰り返すパターンである場合は、各グラフの区間を曲線の頂点で区切った部分グラフを求め、各部分グラフでの資源変更手段の組み合わせの結果を結合することにより、コマンドの組み合わせと順序を含む資源変更手段実施手順を求める。

また、本処理により、資源変更手段の組み合わせを選択する時点で、以前に求めた資源変更手段実施手順が実行中であり、まだ、実行が完了していない場合が考えられる。資源変更手段のコマンドが実行中であるか否かは、資源変更手段実施手順１０７の実行中５０５により判定できる。この場合、上記の組み合わせを求める手順において、コマンド実行後の新たな閾値が負荷予測曲線と交わる時刻までに、コマンドの実行が完了する場合、それまでに求まっている資源変更手段実施手順の次に、実行完了するコマンドを追加することにより求めることができる。

次に、図８のステップ７０４で行われる評価値の算出処理の詳細について述べる。本実施形態では、資源変更手段実施手順の評価値を求めるために、次の評価式を用いる。

評価値 ＝ Σ安定稼動期間
− αΣコマンド実行コスト
− βΣ（Ｎ − 安定稼動時間）
− γ（使用資源量） … 評価式１
ここで、評価式１の安定稼動時間とは、現在時刻から、負荷予測時刻ＴＮまでの間において、閾値（処理可能なリクエスト数）が予測負荷（負荷の予測値）を上回っている時間であるとする。また、コマンド実行コストは、資源変更手段実施手順のコマンドの実行時間とする。使用資源量は、現在時刻から時刻Ｎまでの閾値で構成される矩形の面積である。また、α、β、γは、所定の係数であり業務システム１１８または業務クラスタ１２３ごとに予め決まった値を設定する。係数は、０でもよく、その場合は、特定の項目を無視することができる。なお、コマンド実行コストは、資源変更手段実施手順のコマンド（資源変更手段）の実行回数としてもよい。

図１１は、図７のステップ６０５で行われる実行時刻補正処理の詳細を示すフローチャートである。本処理では、資源変更手段実施手順１０７で設定されたコマンドの実行時刻５０２に対してコマンド実行の時刻を前倒しすることにより、負荷予測に対応できるか否かを調べ、負荷の予測値に対応可能な場合、新たなコマンド実行時刻を求める。これは、他の業務システム１１８（または業務クラスタ１２３）に対する資源変更手段実施手順１０７が、現在の計算機資源の予約状況を元に作成されているため、未割当の計算機資源に対する影響を出来るだけ押さえるためである。本処理では、資源変更手段実施手順１０７の資源変更手段５０３に対応する各コマンドに対して、ステップ１００２〜１００５の処理を適用する（ステップ１００１、１００６、１００７）。

まず、ステップ１００２で、ステップ１００１で読み込んだ資源変更手段実施手順１０７のコマンドの実行時に閾値が負荷の予測値を満たしているかを調べる。閾値が負荷の予測値以上で現在の業務クラスタ１２３の性能が負荷を満たせている場合は、次のコマンドへ進む。現在の業務クラスタ１２３の性能が負荷を満たせていない場合（負荷が過大）で、すでにコマンドの実行が開始されているか否かを判定する（１００３）。この判定は、制御部１１１は、資源変更手段実施手順１０７の実行状態欄５０５が「未」であれば、コマンドが実行されていないと、判定する。

当該コマンドの実行が開始されていない場合、上述の制約条件を満たす上でコマンドの実行時刻を早めることで、現時点の計算機資源の割り当て量で予測負荷（負荷の予測値）を満たせるかを否かを判定する（１００４）。コマンドの実行時刻を前倒ししても制約条件を満たせる場合（１００５）は、資源変更手段実施手順１０７の時刻５０２を所定時間だけ早めて修正し、当該修正に合わせて資源予約テーブル１０５の時刻３０２も更新する。

一方、コマンドの実行時刻を早めても予測負荷を満たせない場合、もしくは、ステップ１００３においてコマンドが既に開始されている場合、ステップ１００８へ進み、開始されているコマンドを除いて、現在の資源変更手段実施手順１０７を破棄し、破棄した資源変更手段について資源予約テーブル１０５を更新してから終了する。

上記処理により、資源変更手段実施手順で変更される計算機資源の割り当て量が、負荷の予測値に対応できない場合、現在実行中のコマンド以外の資源変更手段を削除することになる。

図１２は、実行部１１６で行われる処理の一例を示すフローチャートである。

実行部１１６は、管理部１０１により一定間隔（所定の周期）で起動し、資源変更手段実施手順１０７のうち、現在時刻が実行時刻５０２に到達した資源変更手段５０３に対応するコマンドに対して、コマンドの実行を開始する（１１０１）。なお、一定間隔は、再選択時刻となる所定時間Ｎよりも小さい値が望ましい。実行部１１６は、対象サーバ５０４を実行するハイパーバイザ１２１に対して当該コマンドを送信し、資源変更手段を実施させる。

次に、実行部１１６は、ハイパーバイザ１２１に送信したコマンドに対応する資源予約テーブル１０５のエントリを削除し（１１０２）、当該コマンドに対応する資源割当量の変更を資源管理テーブル１０４に対して行い（１１０３）、実行が終了したコマンドに対応する資源変更手段５０３のエントリを資源変更手段実施手順１０７から削除する。

以上の処理により、資源変更手段実施手順１０７のテーブルに設定された資源変更手段が、実行予定の時刻５０２を経過する度に、資源変更手段５０３に対応するコマンドがハイパーバイザ１２１に送信されて計算機資源の割り当て量の変更が実施される。

なお、上記実施形態では、業務クラスタ１２３ごとに計算機資源の割り当て量を制御する例について説明したが、複数の業務クラスタ１２３を同じタイミングで制御することも考えられる。この場合、各業務クラスタ１２３における評価値は上述の処理で求め、各業務クラスタ１２３の評価値の合計が最大となる組み合わせを選択する。また、同じタイミングで評価値を求める場合、先に評価値を求める業務クラスタ１２３ほど優先される。これは、先に評価値を求める業務クラスタ１２３により資源が予約されるためである。そのため、各業務クラスタ１２３に対して優先度を指定して、優先度の順に評価値を求める。

また、上記実施形態では、使用する物理計算機１２２のハードウェアのＣＰＵ１２２１の性能は均質であると仮定していた。ＣＰＵ１２２１の性能が均質でない場合は、変更手段管理テーブル１０６をＣＰＵ１２２１の種別または性能ごとに保持し、業務サーバ１２０が動作している物理計算機１２２に応じて使い分けるか、あるいは、あるＣＰＵ１２２１に対して変更手段管理テーブル１０６を用意し、さらに、ＣＰＵ１２２１の種別に応じて値を補正する変換テーブルを用意することにより対応することが可能である。

以上説明したように、本実施形態によれば、仮想化環境上において、複数の業務クラスタ１２３により構成される業務システム１１８に対して、将来の負荷変動を予測し、予測された結果に対して、複数のハードウェア資源を変更させる手段を組み合わせることにより、負荷変動に追従するために必要な資源を割り当てることが可能となる。これにより、負荷変動への追随しつつ、業務クラスタで使用とする資源を低く抑えることにより、資源有効活用が可能となる。

１０１ 管理部
１０３ 負荷履歴テーブル
１０４ 資源管理テーブル
１０５ 資源予約テーブル
１０６ 変更手段管理テーブル
１０７ 資源変更手段実施手順
１１０ 監視部
１１１ 制御部
１１２ 負荷予測処理
１１３ 手段選択処理
１１４ 判定処理
１１５ 再構築処理
１１６ 実行部
１１８ 業務システム
１２０ 業務サーバ
１２１ ハイパーバイザ
１２２ 物理計算機
１２３ 業務クラスタ
１２２１ ＣＰＵ
１２２２ メモリ

Claims (9)

1. プロセッサとメモリを含む計算機資源を備えた物理計算機と、前記計算機資源を仮想化して複数の仮想計算機に割り当てる仮想化部と、前記複数の仮想計算機でクラスタを構成し、前記仮想化部を管理する管理部と、を有する計算機システムのクラスタ構成管理方法であって、
   前記管理部が、前記クラスタに対する所定時間後の負荷情報の予測値を演算する第１のステップと、
   前記管理部が、前記クラスタを構成する前記仮想計算機の現在の計算機資源の割り当て量と、所定時間後の計算機資源の割り当て量とを保持する第２のステップと、
   前記管理部が、前記クラスタの構成を変更するために利用可能な計算機資源の複数の変更手段を保持する第３のステップと、
   前記管理部が、前記クラスタを構成する前記仮想計算機に割り当てた現在の計算機資源の割り当て量と、前記負荷情報の予測値と、から前記複数の変更手段の組み合わせを選択し、前記選択された現在の変更手段の組み合わせで、前記負荷情報の予測値を処理可能であるか否かを判定し、前記選択された複数の変更手段の組み合わせでは前記負荷情報の予測値を処理できないと判定された場合に、前記複数の変更手段の組み合わせまたは実行予定時刻を更新する第４のステップと、
   前記管理部が、前記実行予定時刻に到達した変更手段を前記仮想化部に通知して実行させる第５のステップと、
   を含むことを特徴とするクラスタ構成管理方法。
2. 請求項１に記載のクラスタ構成管理方法であって、
   前記第４のステップは、
   前記変更手段の組み合わせを複数選択するステップと、
   前記選択された変更手段の組み合わせ毎に所定の指標を演算するステップと、
   前記指標が最大となる変更手段の組み合わせを選択するステップと、
   を含むことを特徴とするクラスタ構成管理方法。
3. 請求項２に記載のクラスタ構成管理方法であって、
   前記指標を演算するステップは、
   前記変更手段を適用した場合に、前記負荷情報の予測値を処理可能となる期間の長さと、 前記変更手段が使用する計算機資源の割り当て量と、前記変更手段を実行する際のコストの組み合わせから前記指標を演算することを特徴とするクラスタ構成管理方法。
4. 請求項３に記載のクラスタ構成管理方法であって、
   前記コストは、前記変更手段の実行開始から実行完了までの時間であることを特徴とするクラスタ構成管理方法。
5. 請求項３に記載のクラスタ構成管理方法であって、
   前記コストは、前記変更手段の数であることを特徴とするクラスタ構成管理方法。
6. 請求項１に記載のクラスタ構成管理方法であって、
   前記第４のステップは、
   前記選択された現在の変更手段の組み合わせで、前記負荷情報の予測値を処理可能であるか否かを判定するステップと、
   前記判定の結果が、前記現在の変更手段の組み合わせでは前記負荷情報の予測値を処理できない場合に、前記実行予定時刻を所定時間だけ早めた場合に前記負荷情報の予測値を処理可能であるか否かを判定するステップと、
   当該判定の結果が、前記実行予定時刻を所定時間だけ早めた場合に前記負荷情報の予測値を処理可能である場合には、前記実行予定時刻を所定時間だけ早めて更新するステップと、
   を含むことを特徴とするクラスタ構成管理方法。
7. 請求項１に記載のクラスタ構成管理方法であって、
   前記第４のステップは、
   前記選択された現在の変更手段の組み合わせで、前記負荷情報の予測値を処理可能であるか否かを判定するステップと、
   前記判定の結果が、前記現在の変更手段の組み合わせでは前記負荷情報の予測値を処理できないと判定された場合に、前記実行予定時刻を所定時間だけ早めた場合に前記負荷情報の予測値を処理可能であるか否かを判定するステップと、
   当該判定の結果が、前記実行予定時刻を所定時間だけ早めた場合に前記負荷情報の予測値を処理できないと判定した場合には前記変更手段の新たな組み合わせと実行予定時刻を設定するステップと、
   を含むことを特徴とするクラスタ構成管理方法。
8. 計算機資源を仮想化する仮想化部を有する物理計算機で複数の仮想計算機を稼動させ、前記複数の仮想計算機でクラスタを構成し、プロセッサとメモリを備えて前記クラスタを管理する管理装置であって、
   前記クラスタに対する所定時間後の負荷情報の予測値を演算する負荷予測部と、
   前記クラスタを構成する前記仮想計算機の現在の計算機資源の割り当て量と、所定時間後の計算機資源の割り当て量とを保持する資源管理部と、
   前記クラスタの構成を変更するために利用可能な計算機資源の複数の変更手段を保持する資源変更部と、
   前記クラスタを構成する前記仮想計算機に割り当てた現在の計算機資源の割り当て量と、前記負荷情報の予測値と、から前記複数の変更手段の組み合わせを選択し、前記選択された現在の変更手段の組み合わせで、前記負荷情報の予測値を処理可能であるか否かを判定し、前記選択された複数の変更手段の組み合わせでは前記負荷情報の予測値を処理できないと判定された場合に、前記複数の変更手段の組み合わせまたは実行予定時刻を更新する制御部と、
   前記実行予定時刻に到達した前記変更手段を前記仮想化部に通知して実行させる実行部と、
   を有することを特徴とする管理装置。
9. プロセッサとメモリを備えた計算機で複数の仮想計算機で構成されたクラスタを制御するプログラムであって、
   前記クラスタに対する所定時間後の負荷情報の予測値を演算する第１の手順と、
   前記クラスタを構成する前記仮想計算機の現在の計算機資源の割り当て量と、所定時間後の計算機資源の割り当て量とを保持する第２の手順と、
   前記クラスタの構成を変更するために利用可能な計算機資源の複数の変更手段を保持する第３の手順と、
   前記クラスタを構成する前記仮想計算機に割り当てた現在の計算機資源の割り当て量と、前記負荷情報の予測値と、から前記複数の変更手段の組み合わせを選択し、前記選択された現在の変更手段の組み合わせで、前記負荷情報の予測値を処理可能であるか否かを判定し、前記選択された複数の変更手段の組み合わせでは前記負荷情報の予測値を処理できないと判定された場合に、前記複数の変更手段の組み合わせまたは実行予定時刻を更新する第４の手順と、
   前記実行予定時刻に到達した変更手段を実行する第５の手順と、
   を前記計算機に実行させることを特徴とするプログラム。

Images