JP5338906B2 - サーバ管理プログラム、管理サーバ、仮想サーバ配置方法 - Google Patents

Description

本発明は、複数の物理サーバ上で複数の仮想サーバを動作させる仮想コンピューティングの技術に係り、より具体的には、仮想サーバを物理サーバに配置するに当たってのスケジューリングに関する。

近年の仮想サーバ技術の発展により、物理サーバ上で複数の仮想サーバを動作させることや、仮想サーバを稼動させたまま異なる物理サーバ間で移動できる技術（オンラインマイグレーション）が利用可能になっている。マイグレーションについては、例えば特許文献１において言及されている。

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

ところで、稼働中の１又は複数の物理サーバで得られる性能の総和と比較して、配置対象の複数の仮想サーバによる負荷が低すぎる場合には、物理サーバを無駄に稼動させていることになる。すなわち、この場合、稼動する物理サーバの電力消費量の観点から効率的ではない。
逆に、稼働中の１又は複数の物理サーバで得られる性能の総和と比較して、配置対象の複数の仮想サーバによる負荷が高すぎるとしたならば、稼動する物理サーバにおいて処理上の余裕がなく、突発的な仮想サーバの負荷の上昇に対して対処できず、処理期間が遅延する可能性がある。

よって、本発明の１つの側面では、複数の物理サーバに対して複数の仮想サーバを配置するとき、物理サーバの処理能力、及びその電力消費量の観点から効率的な配置を行うサーバ管理プログラム、管理サーバ、仮想サーバ配置方法を提供することを目的とする。

第１の観点では、複数の仮想サーバを複数の物理サーバに配置するためのサーバ管理プログラムが提供される。このサーバ管理プログラムは、
（Ａ）複数の仮想サーバの各々の現在までの所定期間における第１負荷に基づいて、各仮想サーバの将来の第２負荷を予測する手順と、
（Ｂ）物理サーバに配置される１又は複数の仮想サーバの第２負荷の総和がその物理サーバの処理能力に対して所定の比率の範囲内となるように、各仮想サーバの第２負荷に基づいて、複数の仮想サーバを複数の物理サーバに配置するためのスケジュールを決定する手順と、
（Ｃ）前記スケジュールに従って、前記複数の仮想サーバの一部又はすべてを、前記複数の物理サーバの一部又はすべての上に配置するための指示を行う手順と、
をコンピュータに実行させるためのプログラムである。同様の観点の、管理サーバによって実行される仮想サーバ配置方法も提供される。

第２の観点では、複数の仮想サーバを複数の物理サーバに配置するための管理サーバが提供される。この管理サーバは、
（Ｄ）複数の仮想サーバの各々の現在までの所定期間における第１負荷に基づいて、各仮想サーバの将来の第２負荷を予測する負荷予測部と、
（Ｅ）物理サーバに配置される１又は複数の仮想サーバの第２負荷の総和がその物理サーバの処理能力に対して所定の比率の範囲内となるように、各仮想サーバの第２負荷に基づいて、複数の仮想サーバを複数の物理サーバに配置するためのスケジュールを決定するスケジュール生成部と、
（Ｆ）前記スケジュールに従って、前記複数の仮想サーバの一部又はすべてを、前記複数の物理サーバの一部又はすべての上に配置するための指示を行う配置実行部と、
を備える。

複数の物理サーバに対して複数の仮想サーバを配置するとき、物理サーバの処理能力、及びその電力消費量の観点から効率的な配置を行うことができる。

実施形態におけるシステム全体の構成を示すブロック図。 実施形態のシステムにおいて負荷データが伝達される経路を例示する図。 実施形態の管理サーバにおいて、負荷データベースのデータ構造を例示する図。 実施形態の管理サーバにおいて、サーバ管理データベースの内容の一例を示す図。 管理端末から実施形態の管理サーバに対して管理情報の要求を送信し、その応答を受信する態様を示す図。 １ヶ月間における、１時間単位の予測結果（稼動期間、又は停止期間）を例示する図。 図６に対してさらに、１時間単位の負荷値の例を付加した図。 １６８時間（１週間）のすべての時間における負荷値の予測例を示す図。 実施形態の管理サーバにおいて、負荷予測アルゴリズムに従った、負荷値の予測処理のフローチャート。 ある時間区間における各仮想サーバの負荷予測値、及び各物理サーバの処理能力値を例示した図。 実施形態の管理サーバにおいて、最適配置作成部による処理を示すフローチャート。 図１１における最適化処理を示すフローチャート。 実施形態の管理サーバにおける配置スケジュールの一例を示す図。 実施形態の管理サーバにおける再配置実行の例を示す図。 実施形態の管理サーバにおける再配置実行の例を示す図。 実施形態の管理サーバにおける再配置処理のフローチャート。 実施形態の管理サーバにおいて、物理サーバで故障または故障予知が発生した場合の処理を示すフローチャート。 実施形態の管理サーバにおいて、物理サーバが保守交換等により正常に復旧した場合の処理を示すフローチャート。

（１）システム構成
以下、実施形態に係る管理サーバを含むネットワークシステム（以下、単に「システム」という。）の全体構成について、図１を参照して説明する。
図１に示すように、このシステムには、管理サーバ２、管理端末３及び管理対象サーバ群４がネットワークを介して接続される。このシステムでは、管理サーバ２により、管理対象サーバ群４における各物理サーバに対して１又は複数仮想サーバが配置されるように制御される。このとき、物理サーバの処理能力、及びその電力消費量の観点から効率的な仮想サーバの配置が行われることが意図されている。

図１に示すように、管理対象サーバ群４は、複数の仮想サーバ（図中、「Ｖ」で示す。）、及び複数の物理サーバ（図中、「Ｐ」で示す。）を含み、ネットワークを介して管理サーバ２により管理される対象となるサーバ群である。ここで、物理サーバは、仮想サーバが動作するためのプラットフォームであり、コンピュータハードウエア、及びハイパーバイザなどの仮想サーバ管理ソフトウエアを備える。
仮想サーバは、物理サーバ上においてソフトウエア的に実現されるサーバである。仮想サーバ上では１つ以上の業務（アプリケーション）が動作する。異なる業務を行う仮想サーバが複数組み合わされて物理サーバ上に配置される場合もあり、同一の業務を行う複数の仮想サーバが異なる物理サーバ上に配置される場合もある。
なお、仮想サーバのデータは、物理サーバに直接接続されたディスク装置に格納されてもよいし、物理サーバと別に存在し、ネットワークまたは直接結線により接続された共用ディスク（ＳＡＮ(Storage Area Network)、ＮＦＳ(Network File System)、ｉＳＣＳＩ(Internet Small Computer System Interface)等）に格納されてもよい。また、仮想サーバのデータが格納されるディスクの物理媒体の種類についても限定しない。

管理サーバ２は、管理対象サーバ群４とはネットワークを介して通信可能であるが、管理対象サーバ群４とは独立して存在し、システム全体を統括し制御する。
図１に示すように、管理サーバ２は、システム制御部２１と、負荷データベース（負荷ＤＢ）２２と、サーバ管理データベース（サーバ管理ＤＢ）２３と、負荷予測部２４と、最適配置作成部２５（スケジュール生成部）と、再配置実行部２６（配置実行部）と、故障監視部２７と、配置スケジュールデータ格納部２８と、を備える。この管理サーバ２の各構成要素は物理的に単一のサーバに収容されてもよいし、構成要素ごとに複数のサーバに亘って存在してもよい。

管理端末３は、管理情報表示部３１を備えたクライアントである。管理端末３は、管理サーバ２と直接、又はネットワークを経由して接続される。図１は、管理端末３がネットワークを経由して管理サーバ２と接続されている例を示している。なお、管理情報表示部３１は、管理端末３に実装してもよいし、管理サーバ２に実装してもよい。図１は、管理情報表示部３１が管理端末３に実装された例を示している。

（２）管理サーバの構成
次に、図１に示した管理サーバ２の各構成要素について、より詳細に説明する。

［システム制御部２１］
システム制御部２１は主としてマイクロコントローラにより構成され、管理サーバ２全体の制御、各データベースの管理、管理サーバ２の各部への指令の送出を行う。管理サーバ２が複数のコンピュータによって構成される場合には、システム制御部２１はその複数のコンピュータ全体を統括する。また、システム制御部２１は、管理端末３からの要求の受信、及びその要求に基づいて管理端末３で表示すべきデータの送信を行う。

［負荷データベース２２］
負荷データベース２２には、各仮想サーバの過去の負荷データが蓄積される。
ここで、負荷データは、各仮想サーバの負荷値、及び各仮想サーバの動作状態（稼動又は停止）に関する情報（以下、「動作情報」という。）を含む。

負荷データに含まれる負荷値は、後述する処理能力値と比較可能な指標であれば何でもよい。負荷値は、例えば、ＣＰＵ、メモリ或いはディスクなどの計算機のリソースに係る使用率、又はそれらのリソースを総合した指標値でもよいし、ある業務量を実行するのに必要な計算能力のベンチマーク値でもよい。
負荷データが負荷データベース２２に蓄積されるときの経路、蓄積される方法、蓄積されるタイミング等は限定しない。例えば、負荷データが負荷データベース２２に蓄積されるときの経路に関して言及すれば、仮想サーバ側に負荷データを計測し、管理サーバ２へ定期的に送信する機能を備えたエージェントを設けるようにしてもよいし、管理サーバ２から仮想サーバに対して定期的に負荷データを取得するマネージャを設けるようにしてもよい。物理サーバ上で動作し仮想サーバを管理するハイパーバイザ、又は物理サーバのインタフェースを経由して負荷データが管理サーバ２へ送信されるようにしてもよい。

図２は、このシステムにおいて、負荷データが伝達される経路を例示する図である。
図２（ａ）に示す例では、システム制御部２１がサーバ管理データベース２３に対して問い合わせを行い、負荷データの取得の対象となる仮想サーバの情報（例えば、仮想サーバＩＤやＩＰアドレスなど、ネットワーク上の位置を示す特定情報）を得る。システム制御部２１は、その仮想サーバの情報に基づいて、ネットワークを経由して、対象の仮想サーバが動作する物理サーバ上のハイパーバイザに問い合わせる。図２（ａ）に示す例では、ハイパーバイザは、仮想サーバの負荷データを読み取る機構を備えており、システム制御部２１からの問い合わせに対して、対象の仮想サーバの負荷データを返す。対象の仮想サーバの負荷データを取得したシステム制御部２１は、負荷データベース２２の該当仮想サーバＩＤのレコードに負荷データを記録する。以上の処理を全仮想サーバについて繰り返すことで、ある時刻におけるすべての仮想サーバの負荷データが取得される。このデータ取得処理を１分間等の一定期間ごとに繰り返し実行することで、負荷データベース２２には負荷データが蓄積されていく。
図２（ｂ）に示す例では、図２（ａ）とは異なり、仮想サーバ上に負荷データを送信するエージェントを設けた場合を示している。このとき、仮想サーバ上のエージェントは、ハイパーバイザを経由せず、直接管理サーバ２に対して負荷データを送信する。負荷データを受信したシステム制御部２１は、負荷データを送信した仮想サーバをサーバ管理データベース２３と照合し、負荷データベース２１の該当仮想サーバＩＤのレコードに記録する。

なお、図１及び図２では、負荷データベース２２とサーバ管理データベース２３をそれぞれ別個のデータベースとして存在することを前提として説明したが、単一のデータベース（単一のテーブル）として構成するようにしてもよい。

一定期間ごとに負荷データベース２２に記録される負荷データに含まれる負荷値は、瞬時値（１サンプル）でもよいし、平均値（複数のサンプルの平均値）でもよいし、合計値（複数のサンプルの合計値）でもよい。複数のサンプルに基づいて記録される負荷データを決定する場合には、そのサンプル数について特に限定しない。また、負荷データの取得間隔（上記の一定期間）は、少なくとも後述する負荷予測に必要な間隔以下に設定される。

前述したように、負荷データベース２２に記録される負荷データには、各仮想サーバの負荷値だけでなく、各仮想サーバの動作情報も含む。この動作情報は、後述する負荷予測において、仮想サーバの停止期間を考慮した、正確な予測値を算出するために利用される。
図２（ａ）に示す例では、システム制御部２１がハイパーバイザに問い合わせる際、対象の仮想サーバの動作情報を負荷値と同時に取得し、負荷値と動作情報を含む負荷データが負荷データベース２２に記録される。
図２（ｂ）に示す例では、仮想サーバの起動時及び停止時に、仮想サーバ、又はハイパーバイザは、システム制御部２１に対して、仮想サーバの動作状態の変更の通知を行う。この通知に基づき、システム制御部２１は、仮想サーバの動作情報を負荷データベース２２に記録する。

図３に負荷データベース２２のデータ構造の例を示す。
図３において、負荷データベース２２には、複数のレコード（レコード１，２，…，ｍ）に対応して、各仮想サーバＩＤ（ＶＭ１，ＶＭ２，…，ＶＭｍ）と、該当する仮想サーバの負荷データとが記録されている。仮想サーバＩＤは、負荷データベース２２上の仮想サーバと、サーバ管理データベース２３上の仮想サーバとを関連付けるための情報である。図３に示すように、負荷データは、負荷データを取得した時刻ごとの、仮想サーバの負荷値と動作情報が含まれる。図３では、負荷データの記録時刻として、一例として１分間単位の実際の時刻が記録される例を示しているが、必ずしも実際の時刻そのものが記録される必要はない。記録の開始時刻からのオフセットを記録してもよいし、記録時刻を特定可能な文字列を記録してもよい。

［サーバ管理データベース２３］
サーバ管理データベース２３には、物理サーバとその処理能力一覧、及び仮想サーバ一覧が記録される。管理サーバからアクセス可能であれば、物理サーバのデータと仮想サーバのデータはそれぞれ独立のデータベースとして存在してもよい。
各物理サーバの処理能力値は、各物理サーバの処理能力（又は計算能力）に関する性能を示す指標値であって、前述した負荷値と比較可能なものであれば何でもよい。処理能力値は、例えば、ＣＰＵ、メモリ或いはディスクなどの計算機のリソースを示す値（計算速度、メモリ容量等）、又はそれらのリソースを総合した指標値でもよい。

図４は、サーバ管理データベース２３のテーブル（物理サーバテーブル、仮想サーバテーブル）が含む内容の一例を示している。ここでは、ｎ個の物理サーバとｍ個の仮想サーバが管理対象となっている。なお、仮想サーバの数が物理サーバの数よりも多いのが一般的である（ｍ＞ｎ）。
物理サーバテーブルには、レコード１〜ｎに対応してｎ個の物理サーバの特定情報（例えばアドレス）及び処理能力値が含まれる。図４に示すように、物理サーバテーブルにはさらに、各レコードに対応して、故障情報と動作情報が含まれる。物理サーバの故障情報とは、物理サーバが正常か否かについての情報（“正常”又は“故障”を示す。）である。物理サーバの動作情報とは、物理サーバの動作状態に関する情報（“稼動”又は“停止”を示す。）である。この故障情報及び／又は動作情報は、後述する配置スケジュールを作成する時においてスケジュール対象の物理サーバを特定するのに有用となる。
仮想サーバテーブルには、レコード１〜ｍに対応してｍ個の物理サーバの特定情報、仮想サーバＩＤ及び仮想サーバのイメージデータが含まれる。特定情報とは、管理サーバ２内で物理サーバ又は仮想サーバを一意に特定し、アクセス可能とするための情報であり、例えばネットワーク上のコンピュータ名やアドレスなどである。図４では、特定情報としてアドレスを例示してある。仮想サーバＩＤは、負荷データベース２２上のレコードと対応付けるために用いられる。
図４のサーバ管理データベース２３において、また、図４に示したデータ構成は例示に過ぎず、物理サーバ及び／又は仮想サーバの管理に必要な情報を、適宜加えて構成するようにしてもよい。

［負荷予測部２４］
負荷予測部２４は、後述する負荷予測アルゴリズムに従って動作し、過去の負荷データに基づいて、特定の仮想サーバの特定の期間における将来の負荷値の予測（負荷予測）を行う。負荷予測にあたっては、負荷データベース２２から各仮想サーバの負荷データに含まれる負荷値と動作情報を、ある程度長い一定期間（例えば１週間、１ヶ月）、又は全期間について参照する。以下の説明において、予測された負荷値（第２負荷）を、適宜「負荷予測値」という。負荷予測アルゴリズムについては、後で詳細に説明する。

［最適配置作成部２５］
スケジュール生成部としての最適配置作成部２５は、後述する最適配置作成アルゴリズムに従って動作し、負荷予測部２４が予測した負荷値に基づき、物理サーバに対する仮想サーバの最適な配置スケジュールを作成する。ここで、「最適な配置」とは、ある物理サーバ上に配置された複数の仮想サーバから予測される負荷値の合計が、その物理サーバの処理能力値に対して適切な比率の範囲（許容範囲）に収まるようになっていることである。その許容範囲の上限は、仮想サーバの突発的な負荷上昇に耐えうる余裕を持たせるために設けられ、許容範囲の下限は、物理サーバの性能を無駄なく使い、稼動する物理サーバの台数を最小限にとどめることで消費電力の低減を図るために設けられる。
最適配置作成部２５は、配置スケジュールを作成するとき、サーバ管理データベース２３及び負荷予測部２４をそれぞれ参照する。最適配置作成アルゴリズムについては、後で詳細に説明する。

［再配置実行部２６］
再配置実行部２６は、最適配置作成部２５が作成した配置スケジュールに従って、仮想サーバの再配置を行う。再配置実行部２６は、マイグレーションの指示を出すためのインタフェースを備える。このインタフェースは主に、ハイパーバイザなどの仮想サーバ管理ソフトウエアが提供するものを利用したものである。
再配置を実行するためのマイグレーションの方法については限定しない。再配置実行部２６は、マイグレーション対象の仮想サーバが停止中であればオフラインマイグレーションを行うが、マイグレーション対象の仮想サーバが稼動中の場合、一度仮想サーバを停止してからオフラインマイグレーションを行ってもよい。また、再配置実行部２６は、マイグレーション対象の仮想サーバが稼働中の場合、オンラインマイグレーションを行ってもよい。

再配置実行部２６は、物理サーバに対する電源の投入・停止の指示が可能なインタフェース、及び仮想サーバに対するマイグレーションの指示が可能なインタフェースを備える。
再配置実行部２６は、再配置の実行の結果、仮想サーバ数が０となる物理サーバに対しては、その物理サーバの電源を停止させる。また、再配置実行部２６は、再配置の実行の結果、新たに物理サーバを起動することが必要となったときには、その物理サーバを起動させる。さらには、再配置実行部２６は、その物理サーバが故障となったとき（故障情報が“故障”を示すようになったとき）には、その物理サーバの電源を停止させ、別の物理サーバを起動させる。電源の投入及び停止に使用されるインタフェースは、物理サーバそのものが備えるもの、物理サーバのベンダが提供する制御ソフト、一般のツールまたは独自の実装によるものでもかまわない。また、そのインタフェースにおけるプロトコル及び制御経路についても限定しない。
なお、再配置を実行するに際して、オンラインマイグレーション時、バッファとなる物理サーバが必要となる場合は、一時的に稼動していない物理サーバを起動してもよい。
また、再配置実行部２６による、物理サーバに対する電源の投入・停止の指示、仮想サーバに対するマイグレーションの指示は、いかなるプロトコルを介して行われてもよい。そのようなプロトコルの例として、ＳＮＭＰ(Simple Network Management Protocol)，ＩＰＭＩ(Intelligent Platform Management
Interface)、ＳＭＡＳＨ−ＣＬＰ（System Management Architecture for Server Hardware Command Line
Protocol）を挙げることができる。

［故障監視部２７］
故障監視部２７は、各物理サーバの状態（正常／故障）について監視し、故障が発生した場合にはサーバ管理データベース２３上の物理サーバに対応するレコードの故障情報を“故障”と書き換える。また、故障していた物理サーバが復旧した場合には、その物理サーバに対応するレコードの故障情報を“正常”と書き換える。

［配置スケジュールデータ格納部２８］
配置スケジュールデータ格納部２８には、最適配置作成部２５が作成した配置スケジュールが格納される。再配置実行部２６は、配置スケジュールデータ格納部２８に格納されている配置スケジュールを参照して、再配置を実行する。なお、配置スケジュールは、定期的に更新される。

（３）管理端末の構成
次に、図１に示した管理端末３の構成要素についてさらに説明する。

［管理情報表示部３１］
管理情報表示部３１は、管理サーバ２から与えられるデータに基づいて、システムの運用情報を含む様々な情報を表示する。管理情報表示部３１で表示される情報は、例えば以下の情報である。
・物理サーバ、仮想サーバの詳細及び一覧
・仮想サーバ負荷データ（負荷値、動作情報）
・仮想サーバの負荷予測値
・仮想サーバの配置スケジュール
・仮想サーバの現在の配置状況

図５は、管理端末３から管理サーバ２に対して管理情報の要求を送信し、その応答を受信する態様を示す図である。図５において、管理情報の要求を受けた管理サーバ２では、システム制御部２１が負荷データベース２２又はサーバ管理データベース２３を参照して、要求に係る管理情報を取り出し、管理端末３へ管理情報を送信する。管理端末３では、管理サーバ２からの応答として受信した管理情報を、管理情報表示部３１に表示させる。これにより、例えば管理端末３を操作するシステム管理者が上記管理情報を視認できるようになっている。

（４）負荷予測アルゴリズム
次に、管理サーバ２の負荷予測部２４に実装されている負荷予測アルゴリズムの一例を、図６〜図９を参照して詳細に説明する。

負荷予測アルゴリズムでは先ず、各仮想サーバの将来の負荷予測値（第２負荷）を算出するに当たって、各仮想サーバが２４時間稼動するサーバであるか、又は停止期間（あるいは稼動期間）が存在するサーバであるかについて解析する。そして、停止期間が存在するサーバについては、その停止期間が予測される。
停止期間が存在する仮想サーバとしては、例えば週末や夜間に業務を行わないような利用方法が適用される仮想サーバが典型的である。停止期間がスケジュール化されている場合には、負荷予測アルゴリズムは、その停止期間のスケジュールを停止期間の予測値として直接利用できる。この場合、システム管理者がサーバ管理データベース２３に仮想サーバの稼動スケジュールを予め登録するようにしてもよい。
停止期間がスケジュール化されていない場合は、負荷予測アルゴリズムは、例えば１日のうちのある時間区間（特定の１時間）について数週間に亘って動作情報（負荷データベース２２内の情報；図３参照）を解析することにより、停止期間を予測（算出）する。この解析は例えば、仮想サーバの動作情報に基づき、１日のある特定の時間区間においてその仮想サーバが稼動している率（稼動率）を算出し、その稼動率が所定の閾値以下であることを条件として、その特定の時間区間が停止期間であると判断することにより行われる。停止期間を算出するために基礎とする動作情報は、日単位のもの、週単位のもの、又は月単位でもよいし、これらを組み合わせるようにしてもよい。
なお、負荷予測アルゴリズムにおいて稼動期間と停止期間を区別する理由は、仮に全期間中の負荷値の平均を算出したならば、その平均値は停止期間も含めて算出されるため、稼働中における負荷値の平均よりも低い値となって、実状と合致しないためである。

上述したようにして、例えば１ヶ月間において１時間単位で、稼動期間であるか、又は停止期間であるかを予測することができる。図６は、１ヶ月間における、１時間単位の予測結果（稼動期間、又は停止期間）を例示する図である。図６では、横軸を１時間単位で０〜２３時間、縦軸を１日単位の０〜３０日としたマトリクスにおいて、灰色で表した時間は仮想サーバの停止期間、白色で表した時間が仮想サーバの稼動期間、を例示している。

負荷予測アルゴリズムは、図６に示した１時間単位のデータに基づいて、特定の仮想サーバの休業日、営業日、及び就業時間を予測するようにしてもよい。以下の説明では、１時間単位の稼動期間及び停止期間をそれぞれ、稼動時間及び停止時間という。
負荷予測アルゴリズムは、仮想サーバについて稼動時間が所定の閾値（例えば、３０％）を下回る日を、その仮想サーバの「休業日」であると判断する。この休業日が７日おきに周期的に発生しているとすれば、その仮想サーバは土曜日・日曜日が休業日であり、将来も土曜日・日曜日は稼動しないことが予測できる。逆に、負荷予測アルゴリズムは、仮想サーバについて稼動時間が所定の閾値（例えば、３０％）を上回る日を、その仮想サーバの「営業日」であると判断する。
また、負荷予測アルゴリズムは、１ヶ月間の営業日のうち所定の閾値（例えば、３０％）を下回る日数で稼動時間となっている特定の時間帯は「休業時間」であると判断する。例えば図６の例では、この仮想サーバは朝２時から６時が休業時間であり、将来も２時から６時は稼動しないことが予測できる。また、負荷予測アルゴリズムは、１ヶ月間の営業日のうち所定の閾値（例えば、３０％）を上回る日数で稼動時間となっている特定の時間帯は「就業時間」であると判断する。

負荷予測アルゴリズムでは、以下で述べる、仮想サーバの負荷値の予測方法を、その仮想サーバの営業日の営業時間のみを対象として実行することが好ましい。

次に、負荷予測アルゴリズムによる負荷値の予測方法について説明する。
図７は、図６に対してさらに、１時間単位の負荷値の例を付加した図である。図７に示す例において、灰色で表した仮想サーバの停止時間の負荷値はすべて０となっている。
以下では、負荷予測アルゴリズムが１６８時間周期（１週間の周期）で順次、負荷値を予測していく方法について説明する。この方法では、過去の数週間、例えば１０週間の過去のデータ（１６８時間周期の負荷値のデータ×１０）で毎週、各時間の負荷値についての移動平均処理を実行することにより、１週間分の負荷値を予測する。このとき、１０週間に亘って特定の１時間に注目すると、その特定の１時間が稼働時間であったか、又は停止時間であったかについて平均処理において考慮される。例えば、特定の１時間に注目したときに、１０週間中７週間で稼動時間（３週間で停止時間）であったならば、稼動時間であった７時間分の負荷値の合計を７で割った値を、その特定の１時間の負荷予測値とする。このような移動平均処理を行うことにより、毎週、将来の１６８時間（１週間）のすべての時間における負荷値が予測される。この１６８時間（１週間）のすべての時間における負荷値の予測例を図８に示す。

なお、所定期間の移動平均処理により順次負荷値を予測していく上記方法は一例に過ぎず、その他の統計処理（例えば標準偏差を考慮する処理）、及び／又は予測計算の基礎とするデータ（サンプル）の他の取得方法（周期の設定、時間区分の設定等）を用いてもよい。

次に、図９のフローチャートを参照して、負荷予測部２４において負荷予測アルゴリズムに従って実行される負荷値の予測処理について説明する。図９において、ステップＳ１０〜Ｓ１８の処理がｍ個のすべての仮想サーバＶｘ（ｘ＝０，１，…，ｍ）を対象として実行される。
先ず、負荷予測部２４は、負荷データベース２２を参照し、例えば１０週間分の仮想サーバＶｘの負荷データ（負荷値、動作情報）を取得し（ステップＳ１０）、取得した仮想サーバＶｘの動作情報を解析する（ステップＳ１２）。すなわち、取得した動作情報により、例えば１分間隔ごとの仮想サーバＶｘの状態（稼動又は停止）が分かるため（図３参照）、負荷予測部２４は、１日のある特定の時間区間において仮想サーバＶｘの稼動率を算出する。そして、負荷予測部２４は、その稼動率が所定の閾値以下であることを条件としてその特定の時間区間が停止時間であると判断し、稼動率が所定の閾値を上回ることを条件としてその特定の時間区間が稼働時間であると判断する。この解析によって、負荷予測部２４は、例えば図６に示した、稼動状況に関する予測データを作成する（ステップＳ１４）。さらに、負荷予測部２４は、稼動期間（各１時間ごとの稼動時間）中の負荷値を解析する（ステップＳ１６）。具体的には、負荷予測部２４は、稼動時間について、ステップＳ１０で取得した１分間隔ごとの負荷値の平均をとり、その稼動時間における負荷値を算出する。これにより、例えば図７に例示したようなマトリクスのデータ（例えば１０週間分のデータ）が得られる。そして、負荷予測部２４は、稼動時間のみを対象として、１０週間分の負荷値の平均をとることで、稼動時間における予測負荷データを得る（ステップＳ１８）。このとき、前述したように、特定の１時間において１０週間中７週間で稼動時間（３週間で停止時間）であったならば、稼動時間であった７時間分の負荷値の合計を７で割った値を、その特定の１時間の負荷予測値とする。なお、予測負荷データには、負荷予測値とともに、停止時間の情報も含まれる。
図９に示す処理を、例えば毎週実行することで１週間ごとの負荷予測データがすべての仮想サーバについて生成される。

（５）最適配置作成アルゴリズム
次に、管理サーバ２の最適配置作成部２５に実装されている最適配置作成アルゴリズムについて、図１０〜図１３を参照して詳細に説明する。

最適配置作成部２５は、負荷予測部２４からすべての仮想サーバについて、例えば将来の１週間分の各時間区間における予測負荷データを得る。予測負荷データを得るタイミングについては特に限定しないが、例えば１時間等、負荷データのサンプルタイミング（図３では１分間）よりも長い期間ごとでよい。

最適配置作成アルゴリズムでは、物理サーバに配置される１又は複数の仮想サーバの負荷予測値の総和がその物理サーバの処理能力に対して所定の比率の範囲（許容範囲）内となるように、各仮想サーバの負荷予測値に基づいて、複数の仮想サーバを複数の物理サーバに配置するためのスケジュールが決定される。上記許容範囲の上限は、仮想サーバの突発的な負荷上昇に耐えうる余裕を持たせるために設定され、許容範囲の下限は、物理サーバの性能を無駄なく使い、稼動する物理サーバの台数を最小限にとどめることで消費電力の低減を図るために設定される。例えば、上記所定の比率として適性値を７０％、上記許容範囲の上限が８０％で下限が６０％、に設定される。

上記比率の範囲の数値例（適性値：７０％，許容範囲：６０〜８０％）を用いて、以下、スケジュール決定の具体的な方法について、図１０を参照して説明する。図１０は、ある時間区間における各仮想サーバＶ１〜Ｖｍの負荷予測値、及び各物理サーバＰ１〜Ｐｎの処理能力値を例示したものである。図１０に示す負荷予測値、及び処理能力値は、説明のための例示に過ぎず、また、両者は比較可能な指標値である。
例えば、図１０に示すように、各物理サーバの処理能力値がすべて１００であり、配置対象の複数の仮想サーバの負荷予測値の合計が５００である場合を想定する。仮想サーバすべてを動作させるのに必要な物理サーバ台数をＮとすると、１００×Ｎ×７０％≧５００という不等式が成立する最小の整数Ｎが最低限必要なサーバ台数となる。この場合、Ｎ≧７．１４となるため、最低８台の物理サーバが必要となる。ここではすべての物理サーバの性能が同一としたが、同一でない場合は、物理サーバ性能の総和に０．７を乗じたものが左辺になると考えてよい。

図１０に示す例では、最適配置作成アルゴリズムでは、８台の物理サーバ（Ｐ_１，Ｐ_２，…，Ｐ_８）に対して、負荷予測値が大きい仮想サーバの順で物理サーバに割り当てていく。具体的には、最適配置作成アルゴリズムでは、１番目の仮想サーバＶ_１を物理サーバＰ_１、２番目の仮想サーバＶ_２を物理サーバＰ_２、…、８番目の仮想サーバＶ_８を物理サーバＰ_８、９番目の仮想サーバＶ_９を物理サーバＰ_１、…、１６番目の仮想サーバを物理サーバＰ_８というようにして、順番に割り当てる。このとき、割り当てようとした仮想サーバの負荷予測値の合計値が物理サーバの処理能力値１００に適正範囲の上限８０％を乗じた８０を超える場合、その物理サーバには割り当てず、次の物理サーバに割り当てる。次の物理サーバにも割り当てることができず、最終的に８番目の物理サーバＰ_８にも割り当てができない場合は、９番目の物理サーバＰ_９を新たに用意して割り当てる。このようにして、最適配置作成アルゴリズムでは、すべての仮想サーバを割り当て、ある時間区間における配置スケジュールが作成される。

次に、図１１及び図１２のフローチャートを参照して、最適配置作成部２５において最適配置作成アルゴリズムに従って実行される配置スケジュールの生成処理について説明する。なお、図１１は、最適配置作成部２５による処理を示すフローチャートであり、図１２は、図１１における最適化処理を示すフローチャート（上述した最適配置作成アルゴリズムをフローチャートにしたもの）である。

図１１において、ステップＳ２０〜Ｓ２６の処理が、例えば将来の１週間分のすべての時間区間Ｐｔ（ｔ＝０，１，…，ｍａｘ）を対象として実行される。
最適配置作成部２５は先ず、サーバ管理データベース２３を参照し、物理サーバと仮想サーバの一覧を取得する（ステップＳ２０）。これにより、配置対象の仮想サーバの仮想サーバＩＤ、及び各物理サーバの処理能力値が分かる（図４参照）。次に最適配置作成部２５は、負荷予測部２４から時間区間Ｐｔにおける全仮想サーバの予測負荷データ（負荷予測値、停止時間のデータ）を取得する（ステップＳ２２）。ステップＳ２０及びＳ２２により、時間区間Ｐｔにおける、配置対象のすべての仮想サーバの負荷予測値と、各物理サーバの処理能力値とが得られたので、上述した最適配置作成アルゴリズムに従って最適化処理が実行される（ステップＳ２４）。

図１２を参照すると、この最適化処理は以下のとおり実行される。
すなわち、先ず、図１１のステップＳ２２で得られた負荷予測値の合計と、図２０で得られた、稼働中の物理サーバの処理能力値とに基づいて、最低限必要な物理サーバの台数の初期値ｎ_ｔｍｐを算出する（ステップＳ３０）。その後、ステップＳ３２、Ｓ３４、Ｓ３６が、時間区間Ｐｔにおける、配置対象のすべての仮想サーバｘ（ｘ＝０，１，…，ｍ）と、ｎ_ｔｍｐ個の物理サーバｙ（ｙ＝０，１，…，ｎ_ｔｍｐ）とに対して実行される。ステップＳ３２及びＳ３４では、各仮想サーバを順に１つずつ物理サーバに割り当てる処理が行われる。ステップＳ３２において、物理サーバｙに仮想サーバｘを配置可能かについての判断は、物理サーバに配置される仮想サーバの負荷予測値の総和がその物理サーバの処理能力に対して所定の比率の範囲内にあるか否かに基づく。
ステップＳ３６で、物理サーバ０〜ｎ_ｔｍｐにこれ以上配置できない、すなわち、ステップＳ３０で決めた物理サーバ台数では上記所定の比率の範囲（許容範囲）を満足しない場合には、物理サーバに余裕があることを条件として（ステップＳ３８）、配置先の物理サーバを１台追加した上で（ステップＳ４０）、処理が継続される。

図１１の説明に戻る。
図１１において最適化処理が実行されると、時間区間Ｐｔにおける最適配置の組合せ（各物理サーバと、各物理サーバに配置される仮想サーバとの組合せ）が決定される（ステップＳ２６）。ステップＳ２０〜Ｓ２６をすべての時間区間を対象に実行することで、例えば将来の１週間分における１時間ごとの配置スケジュールが作成される（ステップＳ２８）。この配置スケジュールの一例を図１３に示す。図１３の例では、YYYY/MM/DDの日付の時刻10:00:00において、例えば物理サーバＰ１に仮想サーバＶ_１，Ｖ_４，Ｖ_７，Ｖ_１０，Ｖ_１２が配置される予定であることを示している。配置スケジュールは、配置スケジュールデータとして配置スケジュールデータ格納部２８に格納される。

（６）再配置実行部の処理
次に、管理サーバ２の再配置実行部２６の処理について、図１４〜図１６を参照して説明する。

再配置実行部２６によって行われる処理は、再配置の実行の対象となる時間区間（「対象時間区間」という。）についての、以下の３つの処理（処理６Ａ，６Ｂ，６Ｃ）である。
［処理６Ａ］
対象時間区間における配置スケジュールデータを読み込む。また、物理サーバ及び仮想サーバの情報をサーバ管理データベース２３に問い合わせる。
［処理６Ｂ］
対象時間区間で稼動する物理サーバと、対象時間区間の一つ前の（１時間前の）時間区間で稼動する物理サーバとを比較する。一致する物理サーバ（すなわち、両方の時間区間で稼動する物理サーバ）に対しては特に何も処理しないが、一致しない物理サーバ（すなわち、一方の時間区間のみで稼動する物理サーバ）に対しては電源の投入または停止の指示を行う。ここで、対象時間区間において物理サーバ数が増加する場合、電源の投入が対象時間区間の仮想サーバの配置に先立って行われる。対象時間区間において物理サーバ数が減少する場合、対象時間区間で停止する物理サーバの電源の切断は、その物理サーバに配置されていた仮想サーバを別の物理サーバへ移動し、すべての仮想サーバがその物理サーバ上で動作していない状態になってから実施する。
［処理６Ｃ］
処理６Ｂと同様に、対象時間区間とその一つ前の時間区間において、各仮想サーバが配置されている物理サーバを比較する。その結果、配置される物理サーバが一致する仮想サーバに対しては何も処理を行わないが、一致しない仮想サーバに対してはマイグレーションの指示を行う。

処理６Ｂ，処理６Ｃのいずれにおいても、対象時間区間とその一つ前の時間区間の比較は、処理６Ａで読み込まれた配置スケジュールデータを比較することにより行われる。比較するための他の方法として、リアルタイムな稼働状況に関する情報を取得することによって行う方法も考えられる。後者の方法では、スケジュールされていないシステム管理者によるオペレーション、あるいは物理サーバの故障等を考慮することも可能となる。

図１４及び図１５に再配置実行の例を示す。
図１４の例では、（ａ）に示すように再配置前に物理サーバが８台稼動している場合を想定する。このとき、配置スケジュールデータを参照し、９台の物理サーバが必要なスケジュールであると分かると、再配置実行部２６は、（ｂ）に示すように、再配置前に１台の物理サーバの電源を投入する指示を行う。そして、再配置実行部２６は、（ｃ）に示すように、新たに電源投入された物理サーバに対して仮想サーバのマイグレーションを行うための指示を出す。
図１５の例では、（ａ）に示すように再配置前に物理サーバが１０台稼動している場合を想定する。このとき、配置スケジュールデータを参照し、９台の物理サーバで足りるスケジュールであると分かると、再配置実行部２６は、（ｂ）に示すように、仮想サーバのマイグレーションを行うための指示を出し、再配置を実行する。そして、再配置実行部２６は、（ｃ）に示すように、マイグレーションにより仮想サーバを１つも配置しなくなった物理サーバの電源を切断する指示を行う。

次に、図１６のフローチャートを参照して、特定の時間区間（対象時間区間）に対して、再配置実行部２６によって実行される再配置処理について説明する。
図１６において、先ず、再配置実行部２６は、配置スケジュールデータ格納部２８に格納されている配置スケジュールデータを読み出し、その配置スケジュールデータから対象時間区間における配置一覧（仮想サーバをどの物理サーバに配置するかについての一覧のデータ）を読み込む（ステップＳ５０）。そして、再配置実行部２６は、サーバ管理データベース２３に対して物理サーバ及び仮想サーバの動作情報（“稼動”又は“停止”のいずれかの状態を示す情報）を問い合わせる（ステップＳ５２）。そして、再配置実行部２６は、ステップＳ５２で得られた動作情報に基づき、対象時間区間とその１つ前の時間区間における各物理サーバの動作状態を比較し、各物理サーバの動作状態の変化を調べる（ステップＳ５４）。さらに、再配置実行部２６は、負荷データベース２２を参照して、対象時間区間とその１つ前の時間区間における各仮想サーバの動作状態を比較し、各仮想サーバの動作状態の変化を調べる（ステップＳ５６）。

そして、再配置実行部２６は、対象時間区間とその１つ前の時間区間との間で、物理サーバの数を増加させるべき場合には（ステップＳ５８のＹＥＳ）、新たに追加する物理サーバの電源の投入を指示し（ステップＳ６０）、物理サーバの数を増加させる必要がなければ何もしない。そして、再配置実行部２６は、ステップＳ５０で読み出した配置スケジュールデータに従って、仮想サーバのマイグレーションを指示する（ステップＳ６２）。逆に、対象時間区間とその１つ前の時間区間との間で、物理サーバの数を減少させるべき場合には（ステップＳ６４のＹＥＳ）、削減する物理サーバの電源の切断を指示し（ステップＳ６６）、物理サーバの数を減少させる必要がなければ何もしない。

以上、再配置処理についてフローチャートを参照して説明したが、再配置の実行にあたっては、対象時間区間の処理を開始する時刻に達したことを検知するためのスケジューラを設けることが好ましい。このスケジューラは、システム制御部２１に設けてもよいし、再配置実行部２６に設けてもよい。システム制御部２１にスケジューラを設けた場合は、処理開始時刻に達した時点で再配置実行部２６に対して処理開始の指示を出す。
また、再配置処理においては、オンライン又はオフラインで行ったとしても、再配置に処理に関わるオーバヘッド（ネットワーク負荷など）が生ずるため、最適配置作成部２５では、このオーバヘッドが極力少なくなるような配置スケジュールとなるように考慮がされたアルゴリズムの実装が好ましい。

（７）物理サーバ故障時及び復旧時の処理
次に、本実施形態の管理サーバ２の好ましい処理として、物理サーバ故障時及び復旧時の処理について説明する。
物理サーバに故障が生じた場合には、故障が生じた物理サーバ上の仮想サーバを代替の別の物理サーバ上へ移動することが好ましい。具体的には、故障監視部２７が各物理サーバの状態（正常／故障）について監視し、故障が発生した場合（直ちに物理サーバが停止した場合）にはサーバ管理データベース２３上の物理サーバに対応するレコードの故障情報を“故障”と書き換える。同時に、再配置実行部２６は、サーバ管理データベース２３上物理サーバの故障情報に変化に応じて、代替の別の物理サーバの起動、及び仮想サーバのマイグレーションにより自動復旧を行う。また、最適配置作成部２５は、サーバ管理データベース２３上物理サーバの故障情報に変化に基づき、故障が生じた物理サーバをスケジュール対象の物理サーバから除外する。

物理サーバに故障ではなく、故障の予兆が発生した場合には、直ちにその故障の予兆が生じた物理サーバを別の物理サーバへの切り替える処理は行わないが、故障監視部２７は、サーバ管理データベース２３上で、故障の予兆が発生した物理サーバに対応するレコードの故障情報を“故障”と書き換えることが好ましい。これにより、次回の配置スケジュール作成時に、故障の予兆が生じた物理サーバがスケジュール対象の物理サーバから除外される。
なお、ここで故障の予兆とは、サーバに備わる冷却用ファンの回転数に異常が生ずることや、一定期間にコレクタブルエラーが所定の回数以上発生すること等、放置しておけば故障につながる可能性が高い事象をいう。

また、物理サーバが保守交換等により正常に復旧した場合は、故障監視部２７がサーバ管理データベース２３の該当する物理サーバの故障情報を“正常”に書き換える。これにより、最適配置作成部２５では、次回の配置スケジュール作成時に、復旧した物理サーバがスケジュール対象の物理サーバに組み込まれるようになる。

次に、物理サーバ故障時及び復旧時の処理について、それぞれ図１７及び図１８のフローチャートを参照して説明する。図１７は物理サーバで故障または故障予知が発生した場合の処理を示すフローチャートであり、図１８は物理サーバが保守交換等により正常に復旧した場合の処理を示すフローチャートである。
図１７では、先ず、故障監視部２７が各物理サーバを監視することにより、物理サーバの故障／故障予兆を検知する（ステップＳ７０）。そして、物理サーバに故障が生じた場合には（ステップＳ７２）、再配置実行部２６は、故障した物理サーバ上に配置されている仮想サーバをすべて代替の別の物理サーバへマイグレーションを行う指示を出す（ステップＳ７４）。ステップＳ７２で物理サーバの故障の予兆が検知された場合には、ステップＳ７４は実行しない。さらに、故障監視部２７は、サーバ管理データベース２３上で、故障又は故障の予兆が検知された物理サーバの故障情報を“故障”に書き換える（ステップＳ７６）。これにより、最適配置作成部２５では、次回の配置スケジュール作成時に、稼動物理サーバの候補、すなわち、スケジュール対象の物理サーバの候補から、故障又は故障の予兆が検知された物理サーバが除外される。
図１８では、先ず、故障監視部２７が各物理サーバを監視することにより、物理サーバの復旧を検知する（ステップＳ８０）。そして、故障監視部２７は、サーバ管理データベース２３上で、復旧を検知した物理サーバの故障情報を“正常”に書き換える（ステップＳ８２）。これにより、最適配置作成部２５では、次回の配置スケジュール作成時に、スケジュール対象の物理サーバの候補に、復旧した物理サーバが組み込まれるようになる。

なお、前述した最適配置作成アルゴリズム（最適配置作成部２５の処理）では、将来の１週間分の配置スケジュールを予め作成する場合について説明したが、配置スケジュールに組み込まれた物理サーバに故障または故障の予兆が発生した場合は、次の時間区間以降について故障または故障の予兆が発生した物理サーバを除外してスケジュールが再作成される。このとき、故障または故障の予兆が発生した物理サーバと同一の処理能力を有し、かつ配置スケジュールに組み込まれていない別の物理サーバが存在する場合には、その別の物理サーバを故障または故障の予兆が発生した物理サーバと置換することで、スケジュールの再作成を省略することも可能である。

故障監視部２７による、物理サーバの故障検知（復旧）方法は、特に限定しないが、例えば、物理サーバのベンダなどから提供される監視ソフトからのイベントをトリガにする方法、又は故障監視部２７が各物理サーバとの通信により物理サーバの状態に関する情報を収集する方法、オペレータの操作による入力から物理サーバの状態に関する情報を取得・更新する方法等が考えられる。

以上説明したように、本実施形態の管理サーバによれば、複数の仮想サーバの各々の過去の負荷データから負荷予測値を算出し、物理サーバに対する仮想サーバの最適な配置スケジュールを作成し、定期的に再配置が実行される。この配置スケジュールでは、ある物理サーバ上に配置された複数の仮想サーバから予測される負荷値の合計が、その物理サーバの処理能力値に対して適切な比率の範囲に収まるようにして行われる。よって、仮想サーバの突発的な負荷上昇に耐えうる余裕があり、かつ物理サーバの性能を無駄なく使い、稼動する物理サーバの台数を最小限にとどめることで消費電力の低減、ひいては二酸化炭素排出量削減が図られる。
また、上記配置スケジュールの生成及び再配置の実行は、自動的に行われて人手を要しないため、運用・管理コストが上昇しない。

以上、実施形態に係る管理サーバ、及びそのシステムについて詳細に説明したが、本発明の管理サーバは上記実施形態に限定されず、本発明の主旨を逸脱しない範囲において、種々の改良や変更をしてもよいのは勿論である。

また、上記実施形態に係る管理サーバの各部の動作に関連して、この管理サーバによって実行される仮想サーバ配置方法が開示される。
この仮想サーバ配置方法によれば、複数の仮想サーバの各々の現在までの所定期間における負荷値に基づいて、各仮想サーバの将来の負荷値（負荷予測値）を予測し、物理サーバに配置される１又は複数の仮想サーバの負荷予測値の総和がその物理サーバの処理能力に対して所定の比率の範囲内となるように、各仮想サーバの負荷予測値に基づいて、複数の仮想サーバを複数の物理サーバに配置するためのスケジュールを決定し、そのスケジュールに従って、複数の仮想サーバの一部又はすべてを、複数の物理サーバの一部又はすべての上に配置するための指示を行う。

上記実施形態に係る管理サーバの各部の動作、又は上記仮想サーバ配置方法は、プログラムによって実現することができる。この場合、上記仮想サーバ配置方法による手順が記述されたサーバ管理プログラムを、例えばシステム制御部２１に含まれるマイクロコントローラ（コンピュータ）に実行させ、これにより、負荷予測部２４、最適配置作成部２５、配置スケジュールデータ格納部２８、及び再配置実行部２６の各部のハードウエア資源を用いて上記仮想サーバ配置方法が実現される。また、上記プログラムは、ファームウエアとして管理サーバに予め組み込まれるものでもよいし、汎用ソフトウエアとして管理サーバに実行されるものでもよい。

２…管理サーバ、２１…システム制御部、２２…負荷データベース、２３…サーバ管理データベース、２４…負荷予測部、２５…最適配置作成部、２６…再配置実行部、２７…故障監視部、２８…配置スケジュールデータ格納部、３…管理端末、３１…管理情報表示部、４…管理対象サーバ群（複数の物理サーバ、複数の仮想サーバ）

Claims (9)

1. 複数の仮想サーバを複数の物理サーバに配置するためのサーバ管理プログラムであって、
   複数の仮想サーバの各々の現在までの所定期間における第１負荷に基づいて、各仮想サーバの将来の第２負荷を予測する手順と、
   各仮想サーバの前記第２負荷に基づいて、前記複数の物理サーバのうちから順に１つずつ物理サーバを選択し、該選択された物理サーバの処理能力に対して割り当てられた負荷の総和が所定の比率の範囲内となるように、前記選択された物理サーバに前記複数の仮想サーバを割り当ててゆくことで、前記複数の仮想サーバを前記複数の物理サーバに配置するスケジュールを決定する手順と、
   前記スケジュールに従って、前記複数の仮想サーバの一部又はすべてを、前記複数の物理サーバの一部又はすべての上に配置するための指示を行う手順と、
   前記複数の物理サーバの一部又はすべての上に配置するための指示を行う手順において、仮想サーバが割り当てられなかった物理サーバの電源を停止させる指示を行う手順と、
   をコンピュータに実行させるためのサーバ管理プログラム。
2. 前記第２負荷を予測する手順において、
   前記所定期間のうち仮想サーバの稼動期間を対象として各仮想サーバの前記第１負荷を統計処理し、各仮想サーバの前記第２負荷を算出する、
   請求項１に記載されたサーバ管理プログラム。
3. 前記スケジュールを決定する手順において、
   前記複数の物理サーバのうち故障中の物理サーバを、前記複数の仮想サーバの配置対象から除外する、
   請求項１に記載されたサーバ管理プログラム。
4. 複数の仮想サーバを複数の物理サーバに配置するための管理サーバであって、
   複数の仮想サーバの各々の現在までの所定期間における第１負荷に基づいて、各仮想サーバの将来の第２負荷を予測する負荷予測部と、
   各仮想サーバの前記第２負荷に基づいて、前記複数の物理サーバのうちから順に１つずつ物理サーバを選択し、該選択された物理サーバの処理能力に対して割り当てられた負荷の総和が所定の比率の範囲内となるように、前記選択された物理サーバに前記複数の仮想サーバを割り当ててゆくことで、前記複数の仮想サーバを前記複数の物理サーバに配置するスケジュールを決定するスケジュール生成部と、
   前記スケジュールに従って、前記複数の仮想サーバの一部又はすべてを、前記複数の物理サーバの一部又はすべての上に配置するための指示を行い、該配置するための指示により仮想サーバが割り当てられなかった物理サーバの電源を停止させる指示を行う配置実行部と、
   を備えた管理サーバ。
5. 前記負荷予測部は、前記所定期間のうち仮想サーバの稼動期間を対象として各仮想サーバの前記第１負荷を統計処理し、各仮想サーバの前記第２負荷を算出する、
   請求項４に記載された管理サーバ。
6. 前記スケジュール生成部は、前記複数の物理サーバのうち故障中の物理サーバを、前記複数の仮想サーバの配置対象から除外する、
   請求項４に記載された管理サーバ。
7. 複数の仮想サーバを複数の物理サーバに配置するために、管理サーバによって実行される仮想サーバ配置方法であって、
   複数の仮想サーバの各々の現在までの所定期間における第１負荷に基づいて、各仮想サーバの将来の第２負荷を予測し、
   各仮想サーバの前記第２負荷に基づいて、前記複数の物理サーバのうちから順に１つずつ物理サーバを選択し、該選択された物理サーバの処理能力に対して割り当てられた負荷の総和が所定の比率の範囲内となるように、前記選択された物理サーバに前記複数の仮想サーバを割り当ててゆくことで、前記複数の仮想サーバを前記複数の物理サーバに配置するスケジュールを決定し、
   前記スケジュールに従って、前記複数の仮想サーバの一部又はすべてを、前記複数の物理サーバの一部又はすべての上に配置するための指示を行い、
   前記複数の物理サーバの一部又はすべての上に配置するための指示を行う手順において、仮想サーバが割り当てられなかった物理サーバの電源を停止させる指示を行う、
   仮想サーバ配置方法。
8. 前記第２負荷を予測するとき、
   前記所定期間のうち仮想サーバの稼動期間を対象として各仮想サーバの前記第１負荷を統計処理し、各仮想サーバの前記第２負荷を算出する、
   請求項７に記載された仮想サーバ配置方法。
9. 前記スケジュールを決定するとき、
   前記複数の物理サーバのうち故障中の物理サーバを、前記複数の仮想サーバの配置対象から除外する、
   請求項７に記載された仮想サーバ配置方法。

Images