JP2013164749A

JP2013164749A - 仮想サーバ管理システム

Info

Publication number: JP2013164749A
Application number: JP2012027804A
Authority: JP
Inventors: Goshi Anabuki; 豪士穴吹
Original assignee: Nomura Research Institute Ltd
Current assignee: Nomura Research Institute Ltd
Priority date: 2012-02-10
Filing date: 2012-02-10
Publication date: 2013-08-22
Anticipated expiration: 2032-02-10
Also published as: JP5722247B2

Abstract

【課題】各仮想サーバにおける処理状況に応じて、個々のジョブを実行するのに最適な仮想サーバを特定し、当該仮想サーバにジョブを割り当てる技術の実現。
【解決手段】物理サーバ14と、複数の仮想サーバと、管理サーバ12を備えた仮想サーバ管理システム10。管理サーバ12は、物理サーバの保有リソース量と、各仮想サーバの割当リソース量を登録しておくリソース配分情報記憶部40と、各ジョブの実行に必要な要求リソース量を登録しておくジョブ情報記憶部42と、各仮想サーバの割当リソース量と当該仮想サーバにおける現在の利用リソース量に基づいて各仮想サーバの余裕リソース量を算出するリソース利用状況算出部30と、各仮想サーバの余裕リソース量等に基づいて各ジョブの実行に最適な仮想サーバを特定すると共に、当該仮想サーバに当該ジョブの実行を指令するジョブ割当部32を備えた。
【選択図】図２

Description

この発明は、単一のサーバ上に複数のOSをセットアップし、当該サーバのCPUやメモリ、I/O等のリソースを各OSに配分することにより、論理的に複数のサーバとして動作させるサーバ仮想化技術に関する。

近年、サーバコンピュータを物理的に複数台導入する代わりに、単一のサーバを相互に独立した複数のサーバとして利用できるようにする仮想化技術が、コスト削減や省エネルギ、リソースの有効活用に資するものとして、注目されている（非特許文献１参照）。

具体的には、仮想化環境を実現するためのプログラムを物理サーバに導入し、この仮想化プログラムの機能に基づいて複数のOSをサーバにセットアップすると、各OS（以下「仮想OS」と称する）に対してサーバのCPUやメモリ、I/Oといったリソースが割り振られる。
この結果、各仮想OSは相互に独立した仮想サーバとして機能することとなり、それぞれに別個のアプリケーションプログラムを導入することで、恰も複数台のサーバを物理的に導入したのと同様の使い勝手を実現することが可能となる。
５分で分かる！サーバ仮想化のメリットインターネットURL：http://www.atmarkit.co.jp/ad/hp/vse0701/vse01.html 検索日：２０１１年１１月７日

このような仮想化環境下において、処理の効率化を真に実現するためには、各ジョブの特性や各仮想サーバにおける処理の実行状況に応じて、個々のジョブをどの仮想サーバに割り当てるのが現時点において最も効率的であるのかを判断することが極めて重要となるにもかかわらず、従来はこの点について等閑視されてきた。

この発明は、このような現状に鑑みて案出されたものであり、各仮想サーバにおける処理状況に応じて、個々のジョブを実行するのに最適な仮想サーバを特定すると共に、当該仮想サーバに対してジョブを割り当てることができる仮想サーバ管理技術の提供を目的としている。

上記の目的を達成するため、請求項１に記載した仮想サーバ管理システムは、OSがインストールされた少なくとも一つの物理サーバと、この物理サーバ上に構築された仮想化環境に複数のOSを導入することによって形成された複数の仮想サーバと、上記物理サーバ及び各仮想サーバと接続された管理サーバとを備えた仮想サーバ管理システムであって、上記管理サーバは、上記物理サーバが保有する特定種類のリソースの量である保有リソース量と、この物理サーバの保有リソース量の中から上記の各仮想サーバに割り当てた割当リソース量を登録しておくリソース配分情報記憶手段と、実行対象であるジョブ毎に、必要な属性情報を登録しておくジョブ情報記憶手段と、上記物理サーバの余裕リソース量を求める処理と、各仮想サーバの余裕リソース量を暫定的に算出する処理と、この仮想サーバの上記余裕リソース量が上記物理サーバの余裕リソース量を超えている場合には、当該仮想サーバの余裕リソース量を物理サーバの余裕リソース量まで減殺する処理を実行するリソース利用状況算出手段と、上記余裕リソース量に基づいて、各ジョブの実行に最適な仮想サーバを特定すると共に、当該仮想サーバに対して当該ジョブの実行を指令するジョブ割当手段とを備えたことを特徴としている。

請求項２に記載した仮想サーバ管理システムは、請求項１に記載のシステムであって、さらに上記ジョブ割当手段は、各仮想サーバの中で、上記余裕リソース量が最大の仮想サーバをジョブの実行に最適な仮想サーバと特定すること特徴としている。

請求項３に記載した仮想サーバ管理システムは、請求項１に記載のシステムであって、さらに、上記のジョブ情報記憶手段には各ジョブの実行に必要な特定種類のリソースの量が要求リソース量として登録されており、上記ジョブ割当手段は、各仮想サーバの中で、上記余裕リソース量がジョブの各要求リソース量を超えており、かつ、当該余裕リソース量が最大の仮想サーバを当該ジョブの実行に最適な仮想サーバをと特定することを特徴としている。

請求項４に記載した仮想サーバ管理システムは、請求項１に記載のシステムであって、さらに、上記のジョブ情報記憶手段には各ジョブの実行に必要な特定種類のリソースの量が要求リソース量として登録されると共に、各ジョブの処理時間が登録されており、上記リソース利用状況算出手段は、上記ジョブ割当情報記憶手段に格納された各ジョブの処理時間を参照することにより、物理サーバ及び各仮想サーバにおける将来の余裕リソース量を所定の時間間隔で算出し、上記ジョブ割当手段は、各仮想サーバの中で、各ジョブの全処理時間を通じてその要求リソース量を提供可能な仮想サーバを当該ジョブの実行に最適な仮想サーバと特定し、全ての仮想サーバにおいてリソース不足が生じる場合には、このリソース不足の時間が最も短くて済む仮想サーバを当該ジョブの実行に最適な仮想サーバと特定することを特徴としている。

請求項５に記載した仮想サーバ管理システムは、上記物理サーバが複数存在すると共に、各物理サーバ上に複数の仮想サーバが形成された請求項１〜４に記載の仮想サーバ管理システムにおいて、複数の仮想サーバがジョブの実行に最適な仮想サーバとして特定された場合に、上記ジョブ割当手段は、余裕リソース量が最大となる物理サーバに属する仮想サーバを、ジョブの実行に最適な仮想サーバと特定することを特徴としている。

請求項６に記載した仮想サーバ管理システムは、請求項３に記載のシステムであって、さらに、上記仮想サーバにおいてジョブを実行させた際の、リソース利用量の実績データを格納しておく記憶手段と、物理サーバの余裕リソース量を求める処理と、各仮想サーバの余裕リソース量を算出する処理と、この仮想サーバの余裕リソース量が上記物理サーバの余裕リソース量を超えている場合には、当該仮想サーバの余裕リソース量を物理サーバの余裕リソース量まで減殺する処理と、上記ジョブのリソース利用量と上記仮想サーバの余裕リソース量を比較し、両者間に所定の閾値以上の乖離がある場合に、当該リソース利用量を当該ジョブの要求リソース量と認定し、上記ジョブ情報記憶手段に格納する処理を実行する要求リソース量算出手段を備えたことを特徴としている。

請求項１に記載の仮想サーバ管理システムにあっては、各仮想サーバの余裕リソース量が求められ、少なくともこの余裕リソース量に基づいて個々のジョブの実行先が特定される仕組みを備えているため、現状を反映した最適な仮想サーバに対してジョブを割り振ることが可能となり、処理の効率化を実現することが可能となる。
しかも、各仮想サーバの余裕リソース量を算出するに際し、ある仮想サーバの余裕リソース量が物理サーバの余裕リソース量を上回る場合には、これを物理サーバの余裕リソース量まで減殺する補正が施される仕組みを備えているため、各仮想サーバに物理サーバの物理的なリソース量を超えてリソースを配分した場合であっても、各仮想サーバにおいて物理的なリソース量を超えた状態でジョブが実行されることを有効に回避することが可能となる。

請求項２に記載の仮想サーバ管理システムによれば、現時点で最もリソースに余裕のある仮想サーバにジョブが割り当てられるため、効率的な処理が実現される。

請求項３に記載の仮想サーバ管理システムの場合、各仮想サーバの余裕リソース量のみならず、個々のジョブの要求リソース量をも考慮して各ジョブの実行先が特定される仕組みであるため、より最適な仮想サーバにジョブを割り当てることが可能となる。

請求項４に記載の仮想サーバ管理システムの場合、各仮想サーバの現時点における余裕リソース量の他に、将来に亘る余裕リソース量の推移をも参考にしてジョブの実行サーバが決定される仕組みを備えているため、処理の途中でリソース不足に陥ることを事前に回避可能となる。

請求項５に記載の仮想サーバ管理システムにあっては、複数の物理サーバ上にそれぞれ複数の仮想サーバが構築されている場合に、各仮想サーバの余裕リソース量の他に、それぞれが属する物理サーバの余裕リソース量をも参考にしてジョブの実行先が決定される仕組みを備えているため、同等の余裕リソース量を備えた複数の仮想サーバが競合している際に、それぞれの属している物理サーバの余裕リソース量を参考にしてより余裕度の高い仮想サーバを的確に選択することが可能となる。

請求項６に記載の仮想サーバ管理システムによれば、各ジョブの要求リソース量を自動的に算出可能となり、省力化に資する。

図１は、この発明に係る仮想サーバ管理システム10の全体構成を示すものであり、管理サーバ12と、第１の物理サーバ14と、第２の物理サーバ16を備えている。
管理サーバ12と第１の物理サーバ14間、及び管理サーバ12と第２の物理サーバ16間は、通信ネットワークを介して接続されている。
物理サーバの数は２つに限定されるものではなく、３つ以上の物理サーバを管理サーバ12に接続することも当然に可能である。

第１の物理サーバ14には、OS（以下「物理OS-A」）がセットアップされており、この物理OS-A上にエージェントプログラム（以下「物理エージェント18」）がインストールされている。
また、この物理エージェント18によって、物理OS-A上には３つの仮想OS（仮想OS-A1、仮想OS-A2、仮想OS-A3）が起動されている。この結果、物理サーバ14上には、仮想OS-A1、仮想OS-A2、仮想OS-A3に対応した３つの仮想サーバが存在している。

第２の物理サーバ16にも、OS（以下「物理OS-B」）がセットアップされており、この物理OS-B上にも物理エージェント18がインストールされている。
また、この物理エージェント18によって、物理OS-B上には３つの仮想OS（仮想OS-B1、仮想OS-B2、仮想OS-B3）が起動されている。この結果、第２の物理サーバ16上には、仮想OS-B1、仮想OS-B2、仮想OS-B3に対応した３つの仮想サーバが存在している。

仮想OSの数は３に限定されるものではなく、物理エージェント18は物理サーバ上に４以上の仮想OSを起動させることも当然に可能である。
各仮想OSは、物理OSと同様、OSとしての基本機能を発揮するものであるが、物理OSと仮想OSとは必ずしも同種のOSである必要はない。
また、各仮想OSには、仮想OS用のエージェントプログラム（以下「仮想エージェント22」）がそれぞれインストールされている。
さらに、各仮想OS上には、業務処理を実行するために必要な各種アプリケーションプログラムがインストールされている（図示省略）。

管理サーバ12は、仮想エージェント22に対して必要なジョブの実行を個別に指令することができる。
また、物理エージェント18や各仮想エージェント22は、管理サーバ12に対して、各種リソースの利用状況（利用リソース量／実測値）や処理の結果等のデータを随時通知する。

図２は、管理サーバ12の機能構成を示すブロック図であり、リソース利用状況算出部30と、ジョブ割当部32と、実行結果受信部34と、ジョブ割当情報記憶部38と、リソース配分情報記憶部40と、ジョブ情報記憶部42とを備えている。

上記リソース利用状況算出部30、ジョブ割当部32及び実行結果受信部34は、管理サーバ12のCPUが、専用のアプリケーションプログラムに従って必要な処理を実行することにより、実現される。
また、上記ジョブ割当情報記憶部38、リソース配分情報記憶部40及びジョブ情報記憶部42は、管理サーバ12の外部記憶装置内に設けられている。

リソース配分情報記憶部40には、図３に示すように、各物理サーバが保有しているリソースの配分情報が予め規定されている。
例えば、物理OS-AのCPUリソースの利用可能量を、所定の指標OSのCPUリソースとの対比で1000と表現した場合に、配下の仮想OS-A1、仮想OS-A2、仮想OS-A3に対して、それぞれ400ずつ割り当てられている。
また、物理OS-BのCPUリソースの利用可能量を、上記指標OSとの対比で1200とした場合に、配下の仮想OS-B及び仮想OS-B2に対して500が割り当てられると共に、仮想OS-B3に対して400が割り当てられている。
「CPUリソース」とは、例えば単位時間当たりの処理能力を意味している。

CPU以外のメモリ及びI/Oについても同様に、物理OSが保有しているリソースが配下の各仮想OSにそれぞれ割り当てられている。
この場合も、各リソースは上記指標OSの保有リソースを1000とした場合に、それとの対比で求められたスコアが各物理サーバの保有リソースとして表現されると共に、各仮想サーバへの配分リソース量として表現されている。
「メモリリソース」とは、物理サーバのメモリの容量を意味している。
また「I/Oリソース」とは、例えば物理サーバのディスクのI/Oスピードを意味している。

各仮想サーバが、各自に割り当てられた各種リソースを同時に最大限まで使い切る状況は希であるため、上記のように物理サーバの保有リソース量よりもトータルで大きくなるリソース量が、予め各仮想サーバに割り当てられている。この結果、資源の有効活用や処理の効率化が実現される。

ジョブ情報記憶部42には、実行対象ジョブの属性等が格納されている。
図４は、ジョブ情報記憶部42に格納されたデータの一例を示すものであり、各ジョブ毎に実行可能サーバ、CPU、メモリ、I/O、最大処理時間、平均処理時間、実行状況のデータ項目が設定されている。

例えば、JOB-1には実行可能サーバとして仮想OS-A1、仮想OS-A2、仮想OS-A3、仮想OS-B1、仮想OS-B2、仮想OS-B3が規定されている。
ここで実行可能サーバとは、当該ジョブを実行するためのアプリケーションプログラムがインストールされている仮想サーバを意味している。

また、各実行可能サーバ毎に、CPU、メモリ、I/Oの各リソースに関する要求リソース量と、最大処理時間、平均処理時間が格納されている。
例えば、JOB-1を仮想OS-A1の仮想サーバで実行する場合には、CPU：100、メモリ：100、I/O：100のリソースを要し、最大処理時間：200秒、平均処理時間：100秒であるのに対し、同じJOB-1を仮想OS-B2の仮想サーバで実行する場合には、CPU：150、メモリ：150、I/O：150のリソースを要し、最大処理時間：300秒、平均処理時間：150秒であることが規定されている。
これらのデータは、過去の実績に基づいて設定される。この際、特定の仮想サーバにおける実績から、他の仮想サーバでの利用リソースを推定してもよい。

「実行状況」は、当該ジョブの実行状況を表す値（「実行中」、「正常終了」、「異常終了」、「実行待ち」）が格納されるデータ項目である。
このデータ項目の値は、実行結果受信部34及びジョブ割当部32によって随時更新される。例えば、JOB-1が毎日決まった時間に実行されるジョブである場合、当該時刻が到来するまでは「実行待ち」のステータスが設定されている。
つぎに、当該時刻が到来し、ジョブ割当部32が所定の仮想OSにJOB-1を割り当てた時点で、「実行中」のステータスを設定する。

そして、仮想OSの仮想エージェント22から実行結果（「正常終了」または「異常終了」）が送信された時点で、実行結果受信部34が当該実行結果に対応したステータスを設定する。
図５は、仮想エージェント22から送信された実行結果データを示しており、受信日時、ジョブ名、サーバ名、実行結果のデータ項目を少なくとも備えている。

ジョブ情報のデータ項目は上記に限定されるものではなく、例えば、CPUやメモリ、I/Oの各要求リソース量についても、最大値と平均値とに分けて細かく設定しておくことができる。
またリソースの種類として、CPU、メモリ、I/Oの他に、ネットワークリソース（ネットワークの利用状況）等を加えることもできる。

ジョブ割当情報記憶部38には、ジョブ割当部32によって関連付けられた各ジョブと仮想サーバとの対応関係が格納される。
図６は、ジョブ割当情報記憶部38に格納されたジョブ割当情報を示しており、割当日時、ジョブ名、サーバ名のデータ項目を少なくとも備えている。

つぎに、図７のフローチャートに従い、この仮想サーバ管理システム10における処理手順を説明する。
まず、リソース利用状況算出部30により、リソース利用状況データが生成され、メモリ上に格納される（Ｓ10）。
図８は、リソース利用状況データの一例を示すものであり、物理OS及びその配下の仮想OS毎に、時間、CPU（total）、CPU（used）、CPU（capa）、メモリ（total）、メモリ（used）、メモリ（capa）、I/O（total）、I/O（used）、I/O（capa）のデータ項目が少なくとも設定されている。

「時間」のデータ項目には、時間経過を示す値が設定されている。すなわち、時間が「０」は現時点を表しており、「＋１」は１分後を、また「＋２」は２分後を表している。
ただし、時間間隔は１分単位に限られるものではなく、例えば「＋１＝５分後」、「＋２＝１０分後」、「＋３＝１５分後」のように、５分単位とすることもできる。

CPU（total）のデータ項目には、物理サーバの場合であれば当該物理サーバのCPUリソースの総計値（保有リソース量）が記述され、仮想サーバの場合であれば当該仮想サーバに配分されたリソースの値（割当リソース量）が記述される。このCPU（total）の値は、リソース配分情報記憶部40から取得される。

また、CPU（used）のデータ項目には、各サーバにおいて現に利用されているCPUリソースの量（現在の利用リソース量）、あるいは将来利用されるCPUリソースの量（将来の利用リソース量）を示す数値が記述される。
すなわち、時間「０」のCPU（used）に関しては、物理エージェント18や仮想エージェント22から送信された利用リソース量の実測値が充填される。
これに対し、時間「＋１」や「＋２」等のCPU（used）に関しては、リソース利用状況算出部30が、ジョブ割当情報記憶部38に格納された割当て済みの各ジョブについて、ジョブ情報記憶部42に格納されたそれぞれの要求リソース量及び平均処理時間を適用することによって算出した将来における推定値が充填される。例えば、現時点においてある仮想サーバに要求リソース量が「100」のジョブが３つ割り当てられており、その結果、時間「０」のCPU（used）が300となっていたとしても、その中の１つのジョブが時間「＋２」までに終了するということであれば、「＋２」のCPU（used）として「200」が充填される。

CPU（capa）のデータ項目には、各サーバにおけるCPUリソースの余裕量（余裕リソース量）を示す数値が記述される。
このCPU（capa）は、物理OSについては単純に「CPU（total）−CPU（used）」によって求められる。仮想OSのCPU（capa）についても、基本的には「CPU（total）−CPU（used）」によって求められるが、これは暫定的な値であり、物理OSのCPU（capa）との兼ね合いで、補正が施される場合がある。

例えば、図９(a)に示すように、ある時間帯における物理OS-AのCPU（capa）が300であり、仮想OS-A1のCPU（capa）が200、仮想OS-A2のCPU（capa）が100、仮想OS-A3のCPU（capa）が200であった場合、各仮想OSのCPU（capa）は何れも物理OS-AのCPU（capa）を下回っているため、補正なしでそれぞれのCPU（capa）と認定される。

これに対し、図９(b)に示すように、仮想OS-A3のCPU（total）が400であり、CPU（used）が50であった場合、「CPU（total）−CPU（used）」によって求められるCPU（capa）は350となるが、これは物理OS-A1のCPU（capa）を50ほど上回ってしまうため、300に減殺する補正が施される。

メモリ及びI/Oに係る各データ項目についても、上記したCPUに係るデータ項目の説明が当てはまる。
すなわち、メモリ（total）のデータ項目には、物理サーバの場合であれば当該物理サーバのメモリの総計値（保有リソース量）が記述され、仮想サーバの場合であれば当該仮想サーバに割り当てられたメモリの配分値（割当リソース量）が記述される。このメモリ（total）の値は、リソース配分情報記憶部40から取得される。

また、メモリ（used）のデータ項目には、各サーバにおいて現に利用されているメモリの量（現在の利用リソース量／実測値）、あるいは将来利用されるメモリのリソース量（将来の利用リソース量／推定値）を示す数値が記述される。

また、メモリ（capa）のデータ項目には、各サーバにおけるメモリの余裕量（余裕リソース量）を示す数値が記述される。
このメモリ（capa）は、基本的には「メモリ（total）−メモリ（used）」によって求められるが、仮想OSのメモリ（capa）については、物理OSのメモリ（capa）を上限とするというルールが適用されるため、これを超える分については減殺される。

また、I/O（total）のデータ項目には、物理サーバの場合であれば当該物理サーバのI/Oリソースの総計値（保有リソース量）が記述され、仮想サーバの場合であれば当該仮想サーバに配分されたI/Oリソースの値（割当リソース量）が記述される。このI/O（total）の値は、リソース配分情報記憶部40から取得される。

また、I/O（used）のデータ項目には、各サーバにおいて現に利用されているI/Oリソースの量（現在の利用リソース量／実測値）、あるいは将来利用されるI/Oのリソース量（将来の利用リソース量／推定値）を示す数値が記述される。

さらに、I/O（capa）のデータ項目には、各サーバにおけるI/Oリソースの余裕量（余裕リソース量）を示す数値が記述される。
このI/O（capa）も、基本的には「I/O（total）−I/O（used）」によって求められるが、仮想OSのI/O（capa）については、物理OSのI/O（capa）を上限とするというルールが適用されるため、これを超える分については減殺される。

つぎに、ジョブ割当部32がこのリソース利用状況データを参照することにより、ジョブ割当情報を生成する（Ｓ12）。
まずジョブ割当部32は、ジョブ情報記憶部42から実行状況として「実行待ち」のステータスが設定されているジョブを所定の順番に取り出した後、リソース利用状況データを参照して、当該ジョブの実行可能サーバの中で当該ジョブの実行に現時点で最も有利な仮想サーバを特定する。
この際、ジョブ割当部32は以下のルールに従い、個々のジョブを最適な仮想サーバに割り当てる。

(1)複数の仮想サーバの中で、現時点において各リソース（例えば、CPU（capa）、メモリ（capa）、I/O（capa））が最も大きなものを選定する。
この際、ジョブ毎に優先するリソースの種類を登録しておき、優先順位が上位のソースに係る余裕リソース量が最も高い仮想サーバを選択するようにしてもよい。
例えば、ジョブαの最優先リソースがCPUである場合、他のリソースの余裕リソース量は度外視し、CPUリソースの余裕リソース量が最も高い仮想サーバを選択することが該当する。
あるいは、各リソースの余裕リソース量の合計値が最も高い仮想サーバを選定したり、平均値が最も高い仮想サーバを選定したりすることもできる。

(2)各ジョブの要求リソース量を参照し、現時点において当該要求リソース量を提供可能な仮想サーバの中で、最も余裕リソース量の多い仮想サーバを選定する。
この(2)のルールによれば、各ジョブの要求リソース量を満たす仮想サーバが存在しない場合には、該当の仮想サーバが登場するまでジョブの実行が待たされることになる。これに対し、上記(1)のルールが適用される場合には、各ジョブの要求リソース量が満たされるか否かは度外視して、現時点で最も大きな余裕リソース量を備えた仮想サーバが選定される。

(3)各ジョブの平均処理時間を参照し、当該時間に亘って必要なリソースを提供可能な仮想サーバを選択する。
図１０は、仮想サーバのCPU（capa）と実行予定ジョブの要求リソース量との関係を例示するものである。
まず図１０(a)の例では、ジョブの投入後、５〜１３秒辺りでCPU（capa）が低下することとなるが、それでも実行予定ジョブに必要なCPUリソース量を超えているため、当該ジョブは効率的に実行可能である。
これに対し図１０(b)の例では、ジョブの投入後、５〜１３秒辺りでCPU（capa）がジョブに必要なCPUリソース量を下回ってしまい、リソース不足に陥っている。
あるジョブの実行可能サーバの全てにおいて、このようなリソース不足が生じる場合には、このリソース不足時間が最も短くて済む仮想サーバが選択されることとなる。

(4)複数の仮想サーバが同一条件で並んだ場合、各仮想サーバが属している物理サーバの余裕リソース量を比較し、より余裕リソース量の多い物理サーバ配下の仮想サーバを選択する。

上記(1)〜(3)のルールは択一的に適用されるのに対し、(4)のルールは(1)〜(3)のルールに対して補助的（並立的）に適用される。
もっとも、これらのルールはあくまでも一例であり、ジョブ割当部32は他の基準に従って最適な仮想サーバを選定することも当然に可能である。
また、どのルールを優先的に適用すべきかについては、予めポリシーによって規定されている。

つぎにジョブ割当部32は、生成したジョブ割当情報を、対応の仮想サーバの仮想エージェント22に送信し、ジョブの実行を指令した後（Ｓ14）、ジョブ割当情報をジョブ割当情報記憶部38に格納する（Ｓ16）。
そして、仮想サーバからジョブの実行結果データが送信されると（Ｓ18）、これに基づき実行結果受信部34がジョブ情報の「実行状況」を更新する（Ｓ20）。

必要なジョブの全てが実行されるまでの間、リソース利用状況算出部30によってリソース利用状況データが更新され（Ｓ24）、Ｓ12〜Ｓ20の処理が繰り返される（Ｓ22）。
このリソース利用状況データは、各リソースの余裕リソース量（capa）を最新のものにするため、少なくともジョブの実行開始時（投入時）とジョブの実行終了時に更新される。また、この更新に際し、各サーバにおける利用リソース量（used）が測定される。

物理サーバ内に設定された仮想サーバの数が多い場合には、その分、物理サーバのリソースが各仮想サーバに分散し、リソース不足が生じやすくなる。
そこで、他のサービスに係る特定の仮想サーバを停止させることにより、目的のサービスに係る仮想サーバの実質的なリソースを拡大させることが有効となる。

上記においては、ジョブ情報記憶部42に格納される各ジョブの要求リソース量を人間が予め設定しておくことが前提であったが、これを自動的に算出する仕組みを設けておくことが有効である。

具体的には、図１１に示すように、実績情報登録部52、実績情報記憶部54、要求リソース量算出部56を備えた要求リソース量設定機構50を、仮想サーバ管理システム10内に設けておく。

上記実績情報登録部52及び要求リソース量算出部56は、管理サーバ12のCPUが、専用のアプリケーションプログラムに従って必要な処理を実行することにより、実現される。また、上記実績情報記憶部54は、管理サーバ12の外部記憶装置内に設けられている。

実績情報登録部52には、各物理エージェント18及び各仮想エージェント22から、単位時刻毎に各ジョブのリソースの利用量（実績値）、当該ジョブを実行した仮想OSの利用リソース量（used）、当該仮想サーバが属する物理OSの利用リソース量（used）等のデータが送信される。
実績情報登録部52は、これらの実績データを実績情報記憶部54に格納する。

実績情報記憶部54に一定量のデータが蓄積された時点で、要求リソース量算出部56が上記の実績データ及びリソース配分情報記憶部40内のリソース配分情報に基づいてジョブ実行時における仮想OSの余裕リソース量（capa）を算出し、これとジョブの利用リソース量とを比較することにより、各ジョブの要求リソース量を認定する。

例えば、図１２に示すように、JOB-βのCPUリソースの利用量は、時刻０〜３にかけて120のスコアが記録されており、その間、仮想OSのCPU（capa）は200で安定し、JOB-βのCPUリソースの利用量に対して十分な余裕を維持しているため、要求リソース量算出部56は、JOB-βにとって「120」がCPUの要求リソース量として妥当であると判定する。

これに対し、JOB-γのCPUリソースの利用量は、時刻０〜３にかけて100のスコアが記録されているが、その間における仮想OSのCPU（capa）は僅かに５であり、仮想OS側に全く余裕がなかったことを示している。このため、この「100」のスコアはJOB-γの要求リソース量として認定するには信頼性に欠けることから、要求リソース量算出部56はJOB-γにCPUリソースの利用量を認定することを見合わせる。仮想OS側により多くのCPU（capa）があれば、JOB-γのCPUリソースの利用量がさらに大きくなっていた可能性があるためである。

このような場合には、仮想OS側のCPU（capa）を高めた上でデータを取り直し、JOB-γの最適な要求リソース量を導出すればよい。

上記した要求リソース量算出部56の判断基準、すなわち、ジョブのリソース量が仮想OSの余裕リソース量に対してどの程度近づけば「余裕なし」と認定し、どの程度離れれば「余裕あり」と認定するのかについては、予め要求リソース量算出部56のプログラム中に閾値として設定されている。

この発明に係る仮想サーバ管理システムの全体構成を示す模式図である。管理サーバの機能構成を示すブロック図である。リソース配分情報の一例を示す図である。ジョブ情報の一例を示す図である。実行結果データの一例を示す図である。ジョブ割当情報の一例を示す図である。このシステムの処理手順を示すフローチャートである。リソース利用状況データの一例を示す図である。物理サーバのCPU（capa）と仮想サーバのCPU（capa）との関係を示す図である。仮想サーバのCPU（capa）と実行予定ジョブの要求リソース量との関係を示す模式図である。各ジョブの要求リソース量を自動的に算出する要求リソース量設定機構の構成を示すブロック図である。各ジョブの要求リソース量を自動的に算出する際の考え方を説明するための図である。

10 仮想サーバ管理システム
12 管理サーバ
14 第１の物理サーバ
16 第２の物理サーバ
18 物理エージェント
22 仮想エージェント
30 リソース利用状況算出部
32 ジョブ割当部
34 実行結果受信部
38 ジョブ割当情報記憶部
40 リソース配分情報記憶部
42 ジョブ情報記憶部
50 要求リソース量設定機構
52 実績情報登録部
54 実績情報記憶部
56 要求リソース量算出部

Claims

OSがインストールされた少なくとも一つの物理サーバと、
この物理サーバ上に構築された仮想化環境に複数のOSを導入することによって形成された複数の仮想サーバと、
上記物理サーバ及び各仮想サーバと接続された管理サーバとを備えた仮想サーバ管理システムであって、
上記管理サーバは、上記物理サーバが保有する特定種類のリソースの量である保有リソース量と、この物理サーバの保有リソース量の中から上記の各仮想サーバに割り当てた割当リソース量を登録しておくリソース配分情報記憶手段と、
実行対象であるジョブ毎に、必要な属性情報を登録しておくジョブ情報記憶手段と、
上記物理サーバの余裕リソース量を求める処理と、各仮想サーバの余裕リソース量を算出する処理と、この仮想サーバの上記余裕リソース量が上記物理サーバの余裕リソース量を超えている場合には、当該仮想サーバの余裕リソース量を物理サーバの余裕リソース量まで減殺する処理を実行するリソース利用状況算出手段と、
上記余裕リソース量に基づいて、各ジョブの実行に最適な仮想サーバを特定すると共に、当該仮想サーバに対して当該ジョブの実行を指令するジョブ割当手段と、
を備えたことを特徴とする仮想サーバ管理システム。
上記ジョブ割当手段は、各仮想サーバの中で、上記余裕リソース量が最大の仮想サーバをジョブの実行に最適な仮想サーバと特定すること特徴とする請求項１に記載の仮想サーバ管理システム。
上記のジョブ情報記憶手段には、各ジョブの実行に必要な特定種類のリソースの量が要求リソース量として登録されており、
上記ジョブ割当手段は、各仮想サーバの中で、上記余裕リソース量がジョブの各要求リソース量を超えており、かつ、当該余裕リソース量が最大の仮想サーバを当該ジョブの実行に最適な仮想サーバと特定することを特徴とする請求項１に記載の仮想サーバ管理システム。
上記のジョブ情報記憶手段には、各ジョブの実行に必要な特定種類のリソースの量が要求リソース量として登録されると共に、各ジョブの処理時間が登録されており、
上記リソース利用状況算出手段は、上記ジョブ割当情報記憶手段に格納された各ジョブの処理時間を参照することにより、物理サーバ及び各仮想サーバにおける将来の余裕リソース量を所定の時間間隔で算出し、
上記ジョブ割当手段は、各仮想サーバの中で、各ジョブの全処理時間を通じてその要求リソース量を提供可能な仮想サーバを当該ジョブの実行に最適な仮想サーバと特定し、全ての仮想サーバにおいてリソース不足が生じる場合には、このリソース不足の時間が最も短くて済む仮想サーバを当該ジョブの実行に最適な仮想サーバと特定することを特徴とする請求項１に記載の仮想サーバ管理システム。
上記物理サーバが複数存在すると共に、各物理サーバ上に複数の仮想サーバが形成された、請求項１〜４に記載の仮想サーバ管理システムにおいて、
複数の仮想サーバがジョブの実行に最適な仮想サーバとして特定された場合に、上記ジョブ割当手段は、余裕リソース量が最大となる物理サーバに属する仮想サーバを、ジョブの実行に最適な仮想サーバと特定することを特徴とする仮想サーバ管理システム。
上記仮想サーバにおいてジョブを実行させた際の、リソース利用量の実績データを格納しておく記憶手段と、
物理サーバの余裕リソース量を求める処理と、各仮想サーバの余裕リソース量を算出する処理と、この仮想サーバの余裕リソース量が上記物理サーバの余裕リソース量を超えている場合には、当該仮想サーバの余裕リソース量を物理サーバの余裕リソース量まで減殺する処理と、上記ジョブのリソース利用量と上記仮想サーバの余裕リソース量を比較し、両者間に所定の閾値以上の乖離がある場合に、当該リソース利用量を当該ジョブの要求リソース量と認定し、上記ジョブ情報記憶手段に格納する処理を実行する要求リソース量算出手段と、
を備えたことを特徴とする請求項３に記載の仮想サーバ管理システム。