(58)【調査した分野】(Int.Cl.,DB名)
【発明を実施するための最良の形態】
【0018】
図1は、この発明に係る仮想サーバ管理システム10の全体構成を示すものであり、管理サーバ12と、第1の物理サーバ14と、第2の物理サーバ16を備えている。
管理サーバ12と第1の物理サーバ14間、及び管理サーバ12と第2の物理サーバ16間は、通信ネットワークを介して接続されている。
物理サーバの数は2つに限定されるものではなく、3つ以上の物理サーバを管理サーバ12に接続することも当然に可能である。
【0019】
第1の物理サーバ14には、OS(以下「物理OS-A」)がセットアップされており、この物理OS-A上にエージェントプログラム(以下「物理エージェント18」)がインストールされている。
また、この物理エージェント18によって、物理OS-A上には3つの仮想OS(仮想OS-A1、仮想OS-A2、仮想OS-A3)が起動されている。この結果、物理サーバ14上には、仮想OS-A1、仮想OS-A2、仮想OS-A3に対応した3つの仮想サーバが存在している。
【0020】
第2の物理サーバ16にも、OS(以下「物理OS-B」)がセットアップされており、この物理OS-B上にも物理エージェント18がインストールされている。
また、この物理エージェント18によって、物理OS-B上には3つの仮想OS(仮想OS-B1、仮想OS-B2、仮想OS-B3)が起動されている。この結果、第2の物理サーバ16上には、仮想OS-B1、仮想OS-B2、仮想OS-B3に対応した3つの仮想サーバが存在している。
【0021】
仮想OSの数は3に限定されるものではなく、物理エージェント18は物理サーバ上に4以上の仮想OSを起動させることも当然に可能である。
各仮想OSは、物理OSと同様、OSとしての基本機能を発揮するものであるが、物理OSと仮想OSとは必ずしも同種のOSである必要はない。
また、各仮想OSには、仮想OS用のエージェントプログラム(以下「仮想エージェント22」)がそれぞれインストールされている。
さらに、各仮想OS上には、業務処理を実行するために必要な各種アプリケーションプログラムがインストールされている(図示省略)。
【0022】
管理サーバ12は、仮想エージェント22に対して必要なジョブの実行を個別に指令することができる。
また、物理エージェント18や各仮想エージェント22は、管理サーバ12に対して、各種リソースの利用状況(利用リソース量/実測値)や処理の結果等のデータを随時通知する。
【0023】
図2は、管理サーバ12の機能構成を示すブロック図であり、リソース利用状況算出部30と、ジョブ割当部32と、実行結果受信部34と、ジョブ割当情報記憶部38と、リソース配分情報記憶部40と、ジョブ情報記憶部42とを備えている。
【0024】
上記リソース利用状況算出部30、ジョブ割当部32及び実行結果受信部34は、管理サーバ12のCPUが、専用のアプリケーションプログラムに従って必要な処理を実行することにより、実現される。
また、上記ジョブ割当情報記憶部38、リソース配分情報記憶部40及びジョブ情報記憶部42は、管理サーバ12の外部記憶装置内に設けられている。
【0025】
リソース配分情報記憶部40には、
図3に示すように、各物理サーバが保有しているリソースの配分情報が予め規定されている。
例えば、物理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リソース」とは、例えば単位時間当たりの処理能力を意味している。
【0026】
CPU以外のメモリ及びI/Oについても同様に、物理OSが保有しているリソースが配下の各仮想OSにそれぞれ割り当てられている。
この場合も、各リソースは上記指標OSの保有リソースを1000とした場合に、それとの対比で求められたスコアが各物理サーバの保有リソースとして表現されると共に、各仮想サーバへの配分リソース量として表現されている。
「メモリリソース」とは、物理サーバのメモリの容量を意味している。
また「I/Oリソース」とは、例えば物理サーバのディスクのI/Oスピードを意味している。
【0027】
各仮想サーバが、各自に割り当てられた各種リソースを同時に最大限まで使い切る状況は希であるため、上記のように物理サーバの保有リソース量よりもトータルで大きくなるリソース量が、予め各仮想サーバに割り当てられている。この結果、資源の有効活用や処理の効率化が実現される。
【0028】
ジョブ情報記憶部42には、実行対象ジョブの属性等が格納されている。
図4は、ジョブ情報記憶部42に格納されたデータの一例を示すものであり、各ジョブ毎に実行可能サーバ、CPU、メモリ、I/O、最大処理時間、平均処理時間、実行状況のデータ項目が設定されている。
【0029】
例えば、JOB-1には実行可能サーバとして仮想OS-A1、仮想OS-A2、仮想OS-A3、仮想OS-B1、仮想OS-B2、仮想OS-B3が規定されている。
ここで実行可能サーバとは、当該ジョブを実行するためのアプリケーションプログラムがインストールされている仮想サーバを意味している。
【0030】
また、各実行可能サーバ毎に、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秒であることが規定されている。
これらのデータは、過去の実績に基づいて設定される。この際、特定の仮想サーバにおける実績から、他の仮想サーバでの利用リソースを推定してもよい。
【0031】
「実行状況」は、当該ジョブの実行状況を表す値(「実行中」、「正常終了」、「異常終了」、「実行待ち」)が格納されるデータ項目である。
このデータ項目の値は、実行結果受信部34及びジョブ割当部32によって随時更新される。例えば、JOB-1が毎日決まった時間に実行されるジョブである場合、当該時刻が到来するまでは「実行待ち」のステータスが設定されている。
つぎに、当該時刻が到来し、ジョブ割当部32が所定の仮想OSにJOB-1を割り当てた時点で、「実行中」のステータスを設定する。
【0032】
そして、仮想OSの仮想エージェント22から実行結果(「正常終了」または「異常終了」)が送信された時点で、実行結果受信部34が当該実行結果に対応したステータスを設定する。
図5は、仮想エージェント22から送信された実行結果データを示しており、受信日時、ジョブ名、サーバ名、実行結果のデータ項目を少なくとも備えている。
【0033】
ジョブ情報のデータ項目は上記に限定されるものではなく、例えば、CPUやメモリ、I/Oの各要求リソース量についても、最大値と平均値とに分けて細かく設定しておくことができる。
またリソースの種類として、CPU、メモリ、I/Oの他に、ネットワークリソース(ネットワークの利用状況)等を加えることもできる。
【0034】
ジョブ割当情報記憶部38には、ジョブ割当部32によって関連付けられた各ジョブと仮想サーバとの対応関係が格納される。
図6は、ジョブ割当情報記憶部38に格納されたジョブ割当情報を示しており、割当日時、ジョブ名、サーバ名のデータ項目を少なくとも備えている。
【0035】
つぎに、
図7のフローチャートに従い、この仮想サーバ管理システム10における処理手順を説明する。
まず、リソース利用状況算出部30により、リソース利用状況データが生成され、メモリ上に格納される(S10)。
図8は、リソース利用状況データの一例を示すものであり、物理OS及びその配下の仮想OS毎に、時間、CPU(total)、CPU(used)、CPU(capa)、メモリ(total)、メモリ(used)、メモリ(capa)、I/O(total)、I/O(used)、I/O(capa)のデータ項目が少なくとも設定されている。
【0036】
「時間」のデータ項目には、時間経過を示す値が設定されている。すなわち、時間が「0」は現時点を表しており、「+1」は1分後を、また「+2」は2分後を表している。
ただし、時間間隔は1分単位に限られるものではなく、例えば「+1=5分後」、「+2=10分後」、「+3=15分後」のように、5分単位とすることもできる。
【0037】
CPU(total)のデータ項目には、物理サーバの場合であれば当該物理サーバのCPUリソースの総計値(保有リソース量)が記述され、仮想サーバの場合であれば当該仮想サーバに配分されたリソースの値(割当リソース量)が記述される。このCPU(total)の値は、リソース配分情報記憶部40から取得される。
【0038】
また、CPU(used)のデータ項目には、各サーバにおいて現に利用されているCPUリソースの量(現在の利用リソース量)、あるいは将来利用されるCPUリソースの量(将来の利用リソース量)を示す数値が記述される。
すなわち、時間「0」のCPU(used)に関しては、物理エージェント18や仮想エージェント22から送信された利用リソース量の実測値が充填される。
これに対し、時間「+1」や「+2」等のCPU(used)に関しては、リソース利用状況算出部30が、ジョブ割当情報記憶部38に格納された割当て済みの各ジョブについて、ジョブ情報記憶部42に格納されたそれぞれの要求リソース量及び平均処理時間を適用することによって算出した将来における推定値が充填される。例えば、現時点においてある仮想サーバに要求リソース量が「100」のジョブが3つ割り当てられており、その結果、時間「0」のCPU(used)が300となっていたとしても、その中の1つのジョブが時間「+2」までに終了するということであれば、「+2」のCPU(used)として「200」が充填される。
【0039】
CPU(capa)のデータ項目には、各サーバにおけるCPUリソースの余裕量(余裕リソース量)を示す数値が記述される。
このCPU(capa)は、物理OSについては単純に「CPU(total)−CPU(used)」によって求められる。仮想OSのCPU(capa)についても、基本的には「CPU(total)−CPU(used)」によって求められるが、これは暫定的な値であり、物理OSのCPU(capa)との兼ね合いで、補正が施される場合がある。
【0040】
例えば、
図9(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)と認定される。
【0041】
これに対し、
図9(b)に示すように、仮想OS-A3のCPU(total)が400であり、CPU(used)が50であった場合、「CPU(total)−CPU(used)」によって求められるCPU(capa)は350となるが、これは物理OS-A1のCPU(capa)を50ほど上回ってしまうため、300に減殺する補正が施される。
【0042】
メモリ及びI/Oに係る各データ項目についても、上記したCPUに係るデータ項目の説明が当てはまる。
すなわち、メモリ(total)のデータ項目には、物理サーバの場合であれば当該物理サーバのメモリの総計値(保有リソース量)が記述され、仮想サーバの場合であれば当該仮想サーバに割り当てられたメモリの配分値(割当リソース量)が記述される。このメモリ(total)の値は、リソース配分情報記憶部40から取得される。
【0043】
また、メモリ(used)のデータ項目には、各サーバにおいて現に利用されているメモリの量(現在の利用リソース量/実測値)、あるいは将来利用されるメモリのリソース量(将来の利用リソース量/推定値)を示す数値が記述される。
【0044】
また、メモリ(capa)のデータ項目には、各サーバにおけるメモリの余裕量(余裕リソース量)を示す数値が記述される。
このメモリ(capa)は、基本的には「メモリ(total)−メモリ(used)」によって求められるが、仮想OSのメモリ(capa)については、物理OSのメモリ(capa)を上限とするというルールが適用されるため、これを超える分については減殺される。
【0045】
また、I/O(total)のデータ項目には、物理サーバの場合であれば当該物理サーバのI/Oリソースの総計値(保有リソース量)が記述され、仮想サーバの場合であれば当該仮想サーバに配分されたI/Oリソースの値(割当リソース量)が記述される。このI/O(total)の値は、リソース配分情報記憶部40から取得される。
【0046】
また、I/O(used)のデータ項目には、各サーバにおいて現に利用されているI/Oリソースの量(現在の利用リソース量/実測値)、あるいは将来利用されるI/Oのリソース量(将来の利用リソース量/推定値)を示す数値が記述される。
【0047】
さらに、I/O(capa)のデータ項目には、各サーバにおけるI/Oリソースの余裕量(余裕リソース量)を示す数値が記述される。
このI/O(capa)も、基本的には「I/O(total)−I/O(used)」によって求められるが、仮想OSのI/O(capa)については、物理OSのI/O(capa)を上限とするというルールが適用されるため、これを超える分については減殺される。
【0048】
つぎに、ジョブ割当部32がこのリソース利用状況データを参照することにより、ジョブ割当情報を生成する(S12)。
まずジョブ割当部32は、ジョブ情報記憶部42から実行状況として「実行待ち」のステータスが設定されているジョブを所定の順番に取り出した後、リソース利用状況データを参照して、当該ジョブの実行可能サーバの中で当該ジョブの実行に現時点で最も有利な仮想サーバを特定する。
この際、ジョブ割当部32は以下のルールに従い、個々のジョブを最適な仮想サーバに割り当てる。
【0049】
(1)複数の仮想サーバの中で、現時点において各リソース(例えば、CPU(capa)、メモリ(capa)、I/O(capa))が最も大きなものを選定する。
この際、ジョブ毎に優先するリソースの種類を登録しておき、優先順位が上位のソースに係る余裕リソース量が最も高い仮想サーバを選択するようにしてもよい。
例えば、ジョブαの最優先リソースがCPUである場合、他のリソースの余裕リソース量は度外視し、CPUリソースの余裕リソース量が最も高い仮想サーバを選択することが該当する。
あるいは、各リソースの余裕リソース量の合計値が最も高い仮想サーバを選定したり、平均値が最も高い仮想サーバを選定したりすることもできる。
【0050】
(2)各ジョブの要求リソース量を参照し、現時点において当該要求リソース量を提供可能な仮想サーバの中で、最も余裕リソース量の多い仮想サーバを選定する。
この(2)のルールによれば、各ジョブの要求リソース量を満たす仮想サーバが存在しない場合には、該当の仮想サーバが登場するまでジョブの実行が待たされることになる。これに対し、上記(1)のルールが適用される場合には、各ジョブの要求リソース量が満たされるか否かは度外視して、現時点で最も大きな余裕リソース量を備えた仮想サーバが選定される。
【0051】
(3)各ジョブの平均処理時間を参照し、当該時間に亘って必要なリソースを提供可能な仮想サーバを選択する。
図10は、仮想サーバのCPU(capa)と実行予定ジョブの要求リソース量との関係を例示するものである。
まず
図10(a)の例では、ジョブの投入後、5〜13秒辺りでCPU(capa)が低下することとなるが、それでも実行予定ジョブに必要なCPUリソース量を超えているため、当該ジョブは効率的に実行可能である。
これに対し
図10(b)の例では、ジョブの投入後、5〜13秒辺りでCPU(capa)がジョブに必要なCPUリソース量を下回ってしまい、リソース不足に陥っている。
あるジョブの実行可能サーバの全てにおいて、このようなリソース不足が生じる場合には、このリソース不足時間が最も短くて済む仮想サーバが選択されることとなる。
【0052】
(4)複数の仮想サーバが同一条件で並んだ場合、各仮想サーバが属している物理サーバの余裕リソース量を比較し、より余裕リソース量の多い物理サーバ配下の仮想サーバを選択する。
【0053】
上記(1)〜(3)のルールは択一的に適用されるのに対し、(4)のルールは(1)〜(3)のルールに対して補助的(並立的)に適用される。
もっとも、これらのルールはあくまでも一例であり、ジョブ割当部32は他の基準に従って最適な仮想サーバを選定することも当然に可能である。
また、どのルールを優先的に適用すべきかについては、予めポリシーによって規定されている。
【0054】
つぎにジョブ割当部32は、生成したジョブ割当情報を、対応の仮想サーバの仮想エージェント22に送信し、ジョブの実行を指令した後(S14)、ジョブ割当情報をジョブ割当情報記憶部38に格納する(S16)。
そして、仮想サーバからジョブの実行結果データが送信されると(S18)、これに基づき実行結果受信部34がジョブ情報の「実行状況」を更新する(S20)。
【0055】
必要なジョブの全てが実行されるまでの間、リソース利用状況算出部30によってリソース利用状況データが更新され(S24)、S12〜S20の処理が繰り返される(S22)。
このリソース利用状況データは、各リソースの余裕リソース量(capa)を最新のものにするため、少なくともジョブの実行開始時(投入時)とジョブの実行終了時に更新される。また、この更新に際し、各サーバにおける利用リソース量(used)が測定される。
【0056】
物理サーバ内に設定された仮想サーバの数が多い場合には、その分、物理サーバのリソースが各仮想サーバに分散し、リソース不足が生じやすくなる。
そこで、他のサービスに係る特定の仮想サーバを停止させることにより、目的のサービスに係る仮想サーバの実質的なリソースを拡大させることが有効となる。
【0057】
上記においては、ジョブ情報記憶部42に格納される各ジョブの要求リソース量を人間が予め設定しておくことが前提であったが、これを自動的に算出する仕組みを設けておくことが有効である。
【0058】
具体的には、
図11に示すように、実績情報登録部52、実績情報記憶部54、要求リソース量算出部56を備えた要求リソース量設定機構50を、仮想サーバ管理システム10内に設けておく。
【0059】
上記実績情報登録部52及び要求リソース量算出部56は、管理サーバ12のCPUが、専用のアプリケーションプログラムに従って必要な処理を実行することにより、実現される。また、上記実績情報記憶部54は、管理サーバ12の外部記憶装置内に設けられている。
【0060】
実績情報登録部52には、各物理エージェント18及び各仮想エージェント22から、単位時刻毎に各ジョブのリソースの利用量(実績値)、当該ジョブを実行した仮想OSの利用リソース量(used)、当該仮想サーバが属する物理OSの利用リソース量(used)等のデータが送信される。
実績情報登録部52は、これらの実績データを実績情報記憶部54に格納する。
【0061】
実績情報記憶部54に一定量のデータが蓄積された時点で、要求リソース量算出部56が上記の実績データ及びリソース配分情報記憶部40内のリソース配分情報に基づいてジョブ実行時における仮想OSの余裕リソース量(capa)を算出し、これとジョブの利用リソース量とを比較することにより、各ジョブの要求リソース量を認定する。
【0062】
例えば、
図12に示すように、JOB-βのCPUリソースの利用量は、時刻0〜3にかけて120のスコアが記録されており、その間、仮想OSのCPU(capa)は200で安定し、JOB-βのCPUリソースの利用量に対して十分な余裕を維持しているため、要求リソース量算出部56は、JOB-βにとって「120」がCPUの要求リソース量として妥当であると判定する。
【0063】
これに対し、JOB-γのCPUリソースの利用量は、時刻0〜3にかけて100のスコアが記録されているが、その間における仮想OSのCPU(capa)は僅かに5であり、仮想OS側に全く余裕がなかったことを示している。このため、この「100」のスコアはJOB-γの要求リソース量として認定するには信頼性に欠けることから、要求リソース量算出部56はJOB-γにCPUリソースの利用量を認定することを見合わせる。仮想OS側により多くのCPU(capa)があれば、JOB-γのCPUリソースの利用量がさらに大きくなっていた可能性があるためである。
【0064】
このような場合には、仮想OS側のCPU(capa)を高めた上でデータを取り直し、JOB-γの最適な要求リソース量を導出すればよい。
【0065】
上記した要求リソース量算出部56の判断基準、すなわち、ジョブのリソース量が仮想OSの余裕リソース量に対してどの程度近づけば「余裕なし」と認定し、どの程度離れれば「余裕あり」と認定するのかについては、予め要求リソース量算出部56のプログラム中に閾値として設定されている。