JP5857144B2 - 仮想サーバ管理システム - Google Patents
仮想サーバ管理システム Download PDFInfo
- Publication number
- JP5857144B2 JP5857144B2 JP2015041924A JP2015041924A JP5857144B2 JP 5857144 B2 JP5857144 B2 JP 5857144B2 JP 2015041924 A JP2015041924 A JP 2015041924A JP 2015041924 A JP2015041924 A JP 2015041924A JP 5857144 B2 JP5857144 B2 JP 5857144B2
- Authority
- JP
- Japan
- Prior art keywords
- server
- virtual
- job
- resource
- amount
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Landscapes
- Debugging And Monitoring (AREA)
Description
この発明は、単一のサーバ上に複数のOSをセットアップし、当該サーバのCPUやメモリ、I/O等のリソースを各OSに配分することにより、論理的に複数のサーバとして動作させるサーバ仮想化技術に関する。
近年、サーバコンピュータを物理的に複数台導入する代わりに、単一のサーバを相互に独立した複数のサーバとして利用できるようにする仮想化技術が、コスト削減や省エネルギ、リソースの有効活用に資するものとして、注目されている(非特許文献1参照)。
具体的には、仮想化環境を実現するためのプログラムを物理サーバに導入し、この仮想化プログラムの機能に基づいて複数のOSをサーバにセットアップすると、各OS(以下「仮想OS」と称する)に対してサーバのCPUやメモリ、I/Oといったリソースが割り振られる。
この結果、各仮想OSは相互に独立した仮想サーバとして機能することとなり、それぞれに別個のアプリケーションプログラムを導入することで、恰も複数台のサーバを物理的に導入したのと同様の使い勝手を実現することが可能となる。
5分で分かる!サーバ仮想化のメリット インターネットURL:http://www.atmarkit.co.jp/ad/hp/vse0701/vse01.html 検索日:2011年11月7日
この結果、各仮想OSは相互に独立した仮想サーバとして機能することとなり、それぞれに別個のアプリケーションプログラムを導入することで、恰も複数台のサーバを物理的に導入したのと同様の使い勝手を実現することが可能となる。
5分で分かる!サーバ仮想化のメリット インターネットURL:http://www.atmarkit.co.jp/ad/hp/vse0701/vse01.html 検索日:2011年11月7日
このような仮想化環境下において、処理の効率化を真に実現するためには、各ジョブの特性や各仮想サーバにおける処理の実行状況に応じて、個々のジョブをどの仮想サーバに割り当てるのが現時点において最も効率的であるのかを判断することが極めて重要となるにもかかわらず、従来はこの点について等閑視されてきた。
この発明は、このような現状に鑑みて案出されたものであり、各仮想サーバにおける処理状況に応じて、個々のジョブを実行するのに最適な仮想サーバを特定すると共に、当該仮想サーバに対してジョブを割り当てることができる仮想サーバ管理技術の提供を目的としている。
上記の目的を達成するため、請求項1に記載した仮想サーバ管理システムは、OSがインストールされた少なくとも一つの物理サーバと、この物理サーバ上に構築された仮想化環境に複数のOSを導入することによって形成された複数の仮想サーバと、上記物理サーバ及び各仮想サーバと接続された管理サーバとを備えた仮想サーバ管理システムであって、上記管理サーバは、上記物理サーバが保有する特定種類のリソースの量である保有リソース量と、この物理サーバの保有リソース量の中から上記の各仮想サーバに割り当てた割当リソース量を登録しておくリソース配分情報記憶手段と、実行対象であるジョブを登録しておくジョブ情報記憶手段と、上記リソース配分情報記憶手段に格納された物理サーバの保有リソース量から、各仮想サーバから送信された利用リソース量の総計値を減算することによって、物理サーバの現時点の余裕リソース量を求める処理と、上記リソース配分情報記憶手段に格納された各仮想サーバの割当リソース量から各仮想サーバの上記利用リソース量を減算することによって、各仮想サーバの現時点の余裕リソース量を算出する処理と、何れかの仮想サーバの余裕リソース量が上記物理サーバの余裕リソース量を超えている場合には、当該仮想サーバの余裕リソース量を物理サーバの余裕リソース量に補正する処理を実行するリソース利用状況算出手段と、少なくとも各仮想サーバの上記余裕リソース量を所定のルールに当てはめることによって、上記ジョブ情報記憶手段に格納されたジョブの実行を担当する仮想サーバを特定すると共に、当該仮想サーバに対して当該ジョブの実行を指令するジョブ割当手段とを備えたことを特徴としている。
請求項2に記載した仮想サーバ管理システムは、請求項1に記載のシステムであって、さらに上記ジョブ割当手段は、各仮想サーバの中で、上記余裕リソース量が最大の仮想サーバを、上記ジョブの実行を担当する仮想サーバとして特定すること特徴としている。
請求項3に記載した仮想サーバ管理システムは、上記物理サーバが複数存在すると共に、各物理サーバ上に複数の仮想サーバが形成された請求項1または2に記載の仮想サーバ管理システムにおいて、複数の仮想サーバが上記ジョブの実行を担当する仮想サーバとして特定された場合に、上記ジョブ割当手段は、最大の余裕リソース量を備えた物理サーバに属する仮想サーバを、ジョブの実行を担当する仮想サーバと特定することを特徴としている。
請求項1に記載の仮想サーバ管理システムにあっては、各仮想サーバの余裕リソース量が求められ、少なくともこの余裕リソース量に基づいて個々のジョブの実行先が特定される仕組みを備えているため、現状を反映した最適な仮想サーバに対してジョブを割り振ることが可能となり、処理の効率化を実現することが可能となる。
しかも、各仮想サーバの余裕リソース量を算出するに際し、ある仮想サーバの余裕リソース量が物理サーバの余裕リソース量を上回る場合には、これを物理サーバの余裕リソース量まで減殺する補正が施される仕組みを備えているため、各仮想サーバに物理サーバの物理的なリソース量を超えてリソースを配分した場合であっても、各仮想サーバにおいて物理的なリソース量を超えた状態でジョブが実行されることを有効に回避することが可能となる。
しかも、各仮想サーバの余裕リソース量を算出するに際し、ある仮想サーバの余裕リソース量が物理サーバの余裕リソース量を上回る場合には、これを物理サーバの余裕リソース量まで減殺する補正が施される仕組みを備えているため、各仮想サーバに物理サーバの物理的なリソース量を超えてリソースを配分した場合であっても、各仮想サーバにおいて物理的なリソース量を超えた状態でジョブが実行されることを有効に回避することが可能となる。
請求項2に記載の仮想サーバ管理システムによれば、現時点で最もリソースに余裕のある仮想サーバにジョブが割り当てられるため、効率的な処理が実現される。
請求項3に記載の仮想サーバ管理システムにあっては、複数の物理サーバ上にそれぞれ複数の仮想サーバが構築されている場合に、各仮想サーバの余裕リソース量の他に、それぞれが属する物理サーバの余裕リソース量をも参考にしてジョブの実行先が決定される仕組みを備えているため、同等の余裕リソース量を備えた複数の仮想サーバが競合している際に、それぞれの属している物理サーバの余裕リソース量を参考にしてより余裕度の高い仮想サーバを的確に選択することが可能となる。
図1は、この発明に係る仮想サーバ管理システム10の全体構成を示すものであり、管理サーバ12と、第1の物理サーバ14と、第2の物理サーバ16を備えている。
管理サーバ12と第1の物理サーバ14間、及び管理サーバ12と第2の物理サーバ16間は、通信ネットワークを介して接続されている。
物理サーバの数は2つに限定されるものではなく、3つ以上の物理サーバを管理サーバ12に接続することも当然に可能である。
管理サーバ12と第1の物理サーバ14間、及び管理サーバ12と第2の物理サーバ16間は、通信ネットワークを介して接続されている。
物理サーバの数は2つに限定されるものではなく、3つ以上の物理サーバを管理サーバ12に接続することも当然に可能である。
第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つの仮想サーバが存在している。
また、この物理エージェント18によって、物理OS-A上には3つの仮想OS(仮想OS-A1、仮想OS-A2、仮想OS-A3)が起動されている。この結果、物理サーバ14上には、仮想OS-A1、仮想OS-A2、仮想OS-A3に対応した3つの仮想サーバが存在している。
第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つの仮想サーバが存在している。
また、この物理エージェント18によって、物理OS-B上には3つの仮想OS(仮想OS-B1、仮想OS-B2、仮想OS-B3)が起動されている。この結果、第2の物理サーバ16上には、仮想OS-B1、仮想OS-B2、仮想OS-B3に対応した3つの仮想サーバが存在している。
仮想OSの数は3に限定されるものではなく、物理エージェント18は物理サーバ上に4以上の仮想OSを起動させることも当然に可能である。
各仮想OSは、物理OSと同様、OSとしての基本機能を発揮するものであるが、物理OSと仮想OSとは必ずしも同種のOSである必要はない。
また、各仮想OSには、仮想OS用のエージェントプログラム(以下「仮想エージェント22」)がそれぞれインストールされている。
さらに、各仮想OS上には、業務処理を実行するために必要な各種アプリケーションプログラムがインストールされている(図示省略)。
各仮想OSは、物理OSと同様、OSとしての基本機能を発揮するものであるが、物理OSと仮想OSとは必ずしも同種のOSである必要はない。
また、各仮想OSには、仮想OS用のエージェントプログラム(以下「仮想エージェント22」)がそれぞれインストールされている。
さらに、各仮想OS上には、業務処理を実行するために必要な各種アプリケーションプログラムがインストールされている(図示省略)。
管理サーバ12は、仮想エージェント22に対して必要なジョブの実行を個別に指令することができる。
また、物理エージェント18や各仮想エージェント22は、管理サーバ12に対して、各種リソースの利用状況(利用リソース量/実測値)や処理の結果等のデータを随時通知する。
また、物理エージェント18や各仮想エージェント22は、管理サーバ12に対して、各種リソースの利用状況(利用リソース量/実測値)や処理の結果等のデータを随時通知する。
図2は、管理サーバ12の機能構成を示すブロック図であり、リソース利用状況算出部30と、ジョブ割当部32と、実行結果受信部34と、ジョブ割当情報記憶部38と、リソース配分情報記憶部40と、ジョブ情報記憶部42とを備えている。
上記リソース利用状況算出部30、ジョブ割当部32及び実行結果受信部34は、管理サーバ12のCPUが、専用のアプリケーションプログラムに従って必要な処理を実行することにより、実現される。
また、上記ジョブ割当情報記憶部38、リソース配分情報記憶部40及びジョブ情報記憶部42は、管理サーバ12の外部記憶装置内に設けられている。
また、上記ジョブ割当情報記憶部38、リソース配分情報記憶部40及びジョブ情報記憶部42は、管理サーバ12の外部記憶装置内に設けられている。
リソース配分情報記憶部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リソース」とは、例えば単位時間当たりの処理能力を意味している。
例えば、物理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スピードを意味している。
この場合も、各リソースは上記指標OSの保有リソースを1000とした場合に、それとの対比で求められたスコアが各物理サーバの保有リソースとして表現されると共に、各仮想サーバへの配分リソース量として表現されている。
「メモリリソース」とは、物理サーバのメモリの容量を意味している。
また「I/Oリソース」とは、例えば物理サーバのディスクのI/Oスピードを意味している。
各仮想サーバが、各自に割り当てられた各種リソースを同時に最大限まで使い切る状況は希であるため、上記のように物理サーバの保有リソース量よりもトータルで大きくなるリソース量が、予め各仮想サーバに割り当てられている。この結果、資源の有効活用や処理の効率化が実現される。
ジョブ情報記憶部42には、実行対象ジョブの属性等が格納されている。
図4は、ジョブ情報記憶部42に格納されたデータの一例を示すものであり、各ジョブ毎に実行可能サーバ、CPU、メモリ、I/O、最大処理時間、平均処理時間、実行状況のデータ項目が設定されている。
図4は、ジョブ情報記憶部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秒であることが規定されている。
これらのデータは、過去の実績に基づいて設定される。この際、特定の仮想サーバにおける実績から、他の仮想サーバでの利用リソースを推定してもよい。
例えば、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を割り当てた時点で、「実行中」のステータスを設定する。
このデータ項目の値は、実行結果受信部34及びジョブ割当部32によって随時更新される。例えば、JOB-1が毎日決まった時間に実行されるジョブである場合、当該時刻が到来するまでは「実行待ち」のステータスが設定されている。
つぎに、当該時刻が到来し、ジョブ割当部32が所定の仮想OSにJOB-1を割り当てた時点で、「実行中」のステータスを設定する。
そして、仮想OSの仮想エージェント22から実行結果(「正常終了」または「異常終了」)が送信された時点で、実行結果受信部34が当該実行結果に対応したステータスを設定する。
図5は、仮想エージェント22から送信された実行結果データを示しており、受信日時、ジョブ名、サーバ名、実行結果のデータ項目を少なくとも備えている。
図5は、仮想エージェント22から送信された実行結果データを示しており、受信日時、ジョブ名、サーバ名、実行結果のデータ項目を少なくとも備えている。
ジョブ情報のデータ項目は上記に限定されるものではなく、例えば、CPUやメモリ、I/Oの各要求リソース量についても、最大値と平均値とに分けて細かく設定しておくことができる。
またリソースの種類として、CPU、メモリ、I/Oの他に、ネットワークリソース(ネットワークの利用状況)等を加えることもできる。
またリソースの種類として、CPU、メモリ、I/Oの他に、ネットワークリソース(ネットワークの利用状況)等を加えることもできる。
ジョブ割当情報記憶部38には、ジョブ割当部32によって関連付けられた各ジョブと仮想サーバとの対応関係が格納される。
図6は、ジョブ割当情報記憶部38に格納されたジョブ割当情報を示しており、割当日時、ジョブ名、サーバ名のデータ項目を少なくとも備えている。
図6は、ジョブ割当情報記憶部38に格納されたジョブ割当情報を示しており、割当日時、ジョブ名、サーバ名のデータ項目を少なくとも備えている。
つぎに、図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)のデータ項目が少なくとも設定されている。
まず、リソース利用状況算出部30により、リソース利用状況データが生成され、メモリ上に格納される(S10)。
図8は、リソース利用状況データの一例を示すものであり、物理OS及びその配下の仮想OS毎に、時間、CPU(total)、CPU(used)、CPU(capa)、メモリ(total)、メモリ(used)、メモリ(capa)、I/O(total)、I/O(used)、I/O(capa)のデータ項目が少なくとも設定されている。
「時間」のデータ項目には、時間経過を示す値が設定されている。すなわち、時間が「0」は現時点を表しており、「+1」は1分後を、また「+2」は2分後を表している。
ただし、時間間隔は1分単位に限られるものではなく、例えば「+1=5分後」、「+2=10分後」、「+3=15分後」のように、5分単位とすることもできる。
ただし、時間間隔は1分単位に限られるものではなく、例えば「+1=5分後」、「+2=10分後」、「+3=15分後」のように、5分単位とすることもできる。
CPU(total)のデータ項目には、物理サーバの場合であれば当該物理サーバのCPUリソースの総計値(保有リソース量)が記述され、仮想サーバの場合であれば当該仮想サーバに配分されたリソースの値(割当リソース量)が記述される。このCPU(total)の値は、リソース配分情報記憶部40から取得される。
また、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」が充填される。
すなわち、時間「0」のCPU(used)に関しては、物理エージェント18や仮想エージェント22から送信された利用リソース量の実測値が充填される。
これに対し、時間「+1」や「+2」等のCPU(used)に関しては、リソース利用状況算出部30が、ジョブ割当情報記憶部38に格納された割当て済みの各ジョブについて、ジョブ情報記憶部42に格納されたそれぞれの要求リソース量及び平均処理時間を適用することによって算出した将来における推定値が充填される。例えば、現時点においてある仮想サーバに要求リソース量が「100」のジョブが3つ割り当てられており、その結果、時間「0」のCPU(used)が300となっていたとしても、その中の1つのジョブが時間「+2」までに終了するということであれば、「+2」のCPU(used)として「200」が充填される。
CPU(capa)のデータ項目には、各サーバにおけるCPUリソースの余裕量(余裕リソース量)を示す数値が記述される。
このCPU(capa)は、物理OSについては単純に「CPU(total)−CPU(used)」によって求められる。仮想OSのCPU(capa)についても、基本的には「CPU(total)−CPU(used)」によって求められるが、これは暫定的な値であり、物理OSのCPU(capa)との兼ね合いで、補正が施される場合がある。
このCPU(capa)は、物理OSについては単純に「CPU(total)−CPU(used)」によって求められる。仮想OSのCPU(capa)についても、基本的には「CPU(total)−CPU(used)」によって求められるが、これは暫定的な値であり、物理OSのCPU(capa)との兼ね合いで、補正が施される場合がある。
例えば、図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)と認定される。
これに対し、図9(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から取得される。
すなわち、メモリ(total)のデータ項目には、物理サーバの場合であれば当該物理サーバのメモリの総計値(保有リソース量)が記述され、仮想サーバの場合であれば当該仮想サーバに割り当てられたメモリの配分値(割当リソース量)が記述される。このメモリ(total)の値は、リソース配分情報記憶部40から取得される。
また、メモリ(used)のデータ項目には、各サーバにおいて現に利用されているメモリの量(現在の利用リソース量/実測値)、あるいは将来利用されるメモリのリソース量(将来の利用リソース量/推定値)を示す数値が記述される。
また、メモリ(capa)のデータ項目には、各サーバにおけるメモリの余裕量(余裕リソース量)を示す数値が記述される。
このメモリ(capa)は、基本的には「メモリ(total)−メモリ(used)」によって求められるが、仮想OSのメモリ(capa)については、物理OSのメモリ(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)を上限とするというルールが適用されるため、これを超える分については減殺される。
このI/O(capa)も、基本的には「I/O(total)−I/O(used)」によって求められるが、仮想OSのI/O(capa)については、物理OSのI/O(capa)を上限とするというルールが適用されるため、これを超える分については減殺される。
つぎに、ジョブ割当部32がこのリソース利用状況データを参照することにより、ジョブ割当情報を生成する(S12)。
まずジョブ割当部32は、ジョブ情報記憶部42から実行状況として「実行待ち」のステータスが設定されているジョブを所定の順番に取り出した後、リソース利用状況データを参照して、当該ジョブの実行可能サーバの中で当該ジョブの実行に現時点で最も有利な仮想サーバを特定する。
この際、ジョブ割当部32は以下のルールに従い、個々のジョブを最適な仮想サーバに割り当てる。
まずジョブ割当部32は、ジョブ情報記憶部42から実行状況として「実行待ち」のステータスが設定されているジョブを所定の順番に取り出した後、リソース利用状況データを参照して、当該ジョブの実行可能サーバの中で当該ジョブの実行に現時点で最も有利な仮想サーバを特定する。
この際、ジョブ割当部32は以下のルールに従い、個々のジョブを最適な仮想サーバに割り当てる。
(1)複数の仮想サーバの中で、現時点において各リソース(例えば、CPU(capa)、メモリ(capa)、I/O(capa))が最も大きなものを選定する。
この際、ジョブ毎に優先するリソースの種類を登録しておき、優先順位が上位のソースに係る余裕リソース量が最も高い仮想サーバを選択するようにしてもよい。
例えば、ジョブαの最優先リソースがCPUである場合、他のリソースの余裕リソース量は度外視し、CPUリソースの余裕リソース量が最も高い仮想サーバを選択することが該当する。
あるいは、各リソースの余裕リソース量の合計値が最も高い仮想サーバを選定したり、平均値が最も高い仮想サーバを選定したりすることもできる。
この際、ジョブ毎に優先するリソースの種類を登録しておき、優先順位が上位のソースに係る余裕リソース量が最も高い仮想サーバを選択するようにしてもよい。
例えば、ジョブαの最優先リソースがCPUである場合、他のリソースの余裕リソース量は度外視し、CPUリソースの余裕リソース量が最も高い仮想サーバを選択することが該当する。
あるいは、各リソースの余裕リソース量の合計値が最も高い仮想サーバを選定したり、平均値が最も高い仮想サーバを選定したりすることもできる。
(2)各ジョブの要求リソース量を参照し、現時点において当該要求リソース量を提供可能な仮想サーバの中で、最も余裕リソース量の多い仮想サーバを選定する。
この(2)のルールによれば、各ジョブの要求リソース量を満たす仮想サーバが存在しない場合には、該当の仮想サーバが登場するまでジョブの実行が待たされることになる。これに対し、上記(1)のルールが適用される場合には、各ジョブの要求リソース量が満たされるか否かは度外視して、現時点で最も大きな余裕リソース量を備えた仮想サーバが選定される。
この(2)のルールによれば、各ジョブの要求リソース量を満たす仮想サーバが存在しない場合には、該当の仮想サーバが登場するまでジョブの実行が待たされることになる。これに対し、上記(1)のルールが適用される場合には、各ジョブの要求リソース量が満たされるか否かは度外視して、現時点で最も大きな余裕リソース量を備えた仮想サーバが選定される。
(3)各ジョブの平均処理時間を参照し、当該時間に亘って必要なリソースを提供可能な仮想サーバを選択する。
図10は、仮想サーバのCPU(capa)と実行予定ジョブの要求リソース量との関係を例示するものである。
まず図10(a)の例では、ジョブの投入後、5〜13秒辺りでCPU(capa)が低下することとなるが、それでも実行予定ジョブに必要なCPUリソース量を超えているため、当該ジョブは効率的に実行可能である。
これに対し図10(b)の例では、ジョブの投入後、5〜13秒辺りでCPU(capa)がジョブに必要なCPUリソース量を下回ってしまい、リソース不足に陥っている。
あるジョブの実行可能サーバの全てにおいて、このようなリソース不足が生じる場合には、このリソース不足時間が最も短くて済む仮想サーバが選択されることとなる。
図10は、仮想サーバのCPU(capa)と実行予定ジョブの要求リソース量との関係を例示するものである。
まず図10(a)の例では、ジョブの投入後、5〜13秒辺りでCPU(capa)が低下することとなるが、それでも実行予定ジョブに必要なCPUリソース量を超えているため、当該ジョブは効率的に実行可能である。
これに対し図10(b)の例では、ジョブの投入後、5〜13秒辺りでCPU(capa)がジョブに必要なCPUリソース量を下回ってしまい、リソース不足に陥っている。
あるジョブの実行可能サーバの全てにおいて、このようなリソース不足が生じる場合には、このリソース不足時間が最も短くて済む仮想サーバが選択されることとなる。
(4)複数の仮想サーバが同一条件で並んだ場合、各仮想サーバが属している物理サーバの余裕リソース量を比較し、より余裕リソース量の多い物理サーバ配下の仮想サーバを選択する。
上記(1)〜(3)のルールは択一的に適用されるのに対し、(4)のルールは(1)〜(3)のルールに対して補助的(並立的)に適用される。
もっとも、これらのルールはあくまでも一例であり、ジョブ割当部32は他の基準に従って最適な仮想サーバを選定することも当然に可能である。
また、どのルールを優先的に適用すべきかについては、予めポリシーによって規定されている。
もっとも、これらのルールはあくまでも一例であり、ジョブ割当部32は他の基準に従って最適な仮想サーバを選定することも当然に可能である。
また、どのルールを優先的に適用すべきかについては、予めポリシーによって規定されている。
つぎにジョブ割当部32は、生成したジョブ割当情報を、対応の仮想サーバの仮想エージェント22に送信し、ジョブの実行を指令した後(S14)、ジョブ割当情報をジョブ割当情報記憶部38に格納する(S16)。
そして、仮想サーバからジョブの実行結果データが送信されると(S18)、これに基づき実行結果受信部34がジョブ情報の「実行状況」を更新する(S20)。
そして、仮想サーバからジョブの実行結果データが送信されると(S18)、これに基づき実行結果受信部34がジョブ情報の「実行状況」を更新する(S20)。
必要なジョブの全てが実行されるまでの間、リソース利用状況算出部30によってリソース利用状況データが更新され(S24)、S12〜S20の処理が繰り返される(S22)。
このリソース利用状況データは、各リソースの余裕リソース量(capa)を最新のものにするため、少なくともジョブの実行開始時(投入時)とジョブの実行終了時に更新される。また、この更新に際し、各サーバにおける利用リソース量(used)が測定される。
このリソース利用状況データは、各リソースの余裕リソース量(capa)を最新のものにするため、少なくともジョブの実行開始時(投入時)とジョブの実行終了時に更新される。また、この更新に際し、各サーバにおける利用リソース量(used)が測定される。
物理サーバ内に設定された仮想サーバの数が多い場合には、その分、物理サーバのリソースが各仮想サーバに分散し、リソース不足が生じやすくなる。
そこで、他のサービスに係る特定の仮想サーバを停止させることにより、目的のサービスに係る仮想サーバの実質的なリソースを拡大させることが有効となる。
そこで、他のサービスに係る特定の仮想サーバを停止させることにより、目的のサービスに係る仮想サーバの実質的なリソースを拡大させることが有効となる。
上記においては、ジョブ情報記憶部42に格納される各ジョブの要求リソース量を人間が予め設定しておくことが前提であったが、これを自動的に算出する仕組みを設けておくことが有効である。
具体的には、図11に示すように、実績情報登録部52、実績情報記憶部54、要求リソース量算出部56を備えた要求リソース量設定機構50を、仮想サーバ管理システム10内に設けておく。
上記実績情報登録部52及び要求リソース量算出部56は、管理サーバ12のCPUが、専用のアプリケーションプログラムに従って必要な処理を実行することにより、実現される。また、上記実績情報記憶部54は、管理サーバ12の外部記憶装置内に設けられている。
実績情報登録部52には、各物理エージェント18及び各仮想エージェント22から、単位時刻毎に各ジョブのリソースの利用量(実績値)、当該ジョブを実行した仮想OSの利用リソース量(used)、当該仮想サーバが属する物理OSの利用リソース量(used)等のデータが送信される。
実績情報登録部52は、これらの実績データを実績情報記憶部54に格納する。
実績情報登録部52は、これらの実績データを実績情報記憶部54に格納する。
実績情報記憶部54に一定量のデータが蓄積された時点で、要求リソース量算出部56が上記の実績データ及びリソース配分情報記憶部40内のリソース配分情報に基づいてジョブ実行時における仮想OSの余裕リソース量(capa)を算出し、これとジョブの利用リソース量とを比較することにより、各ジョブの要求リソース量を認定する。
例えば、図12に示すように、JOB-βのCPUリソースの利用量は、時刻0〜3にかけて120のスコアが記録されており、その間、仮想OSのCPU(capa)は200で安定し、JOB-βのCPUリソースの利用量に対して十分な余裕を維持しているため、要求リソース量算出部56は、JOB-βにとって「120」がCPUの要求リソース量として妥当であると判定する。
これに対し、JOB-γのCPUリソースの利用量は、時刻0〜3にかけて100のスコアが記録されているが、その間における仮想OSのCPU(capa)は僅かに5であり、仮想OS側に全く余裕がなかったことを示している。このため、この「100」のスコアはJOB-γの要求リソース量として認定するには信頼性に欠けることから、要求リソース量算出部56はJOB-γにCPUリソースの利用量を認定することを見合わせる。仮想OS側により多くのCPU(capa)があれば、JOB-γのCPUリソースの利用量がさらに大きくなっていた可能性があるためである。
このような場合には、仮想OS側のCPU(capa)を高めた上でデータを取り直し、JOB-γの最適な要求リソース量を導出すればよい。
上記した要求リソース量算出部56の判断基準、すなわち、ジョブのリソース量が仮想OSの余裕リソース量に対してどの程度近づけば「余裕なし」と認定し、どの程度離れれば「余裕あり」と認定するのかについては、予め要求リソース量算出部56のプログラム中に閾値として設定されている。
10 仮想サーバ管理システム
12 管理サーバ
14 第1の物理サーバ
16 第2の物理サーバ
18 物理エージェント
22 仮想エージェント
30 リソース利用状況算出部
32 ジョブ割当部
34 実行結果受信部
38 ジョブ割当情報記憶部
40 リソース配分情報記憶部
42 ジョブ情報記憶部
50 要求リソース量設定機構
52 実績情報登録部
54 実績情報記憶部
56 要求リソース量算出部
12 管理サーバ
14 第1の物理サーバ
16 第2の物理サーバ
18 物理エージェント
22 仮想エージェント
30 リソース利用状況算出部
32 ジョブ割当部
34 実行結果受信部
38 ジョブ割当情報記憶部
40 リソース配分情報記憶部
42 ジョブ情報記憶部
50 要求リソース量設定機構
52 実績情報登録部
54 実績情報記憶部
56 要求リソース量算出部
Claims (3)
- OSがインストールされた少なくとも一つの物理サーバと、
この物理サーバ上に構築された仮想化環境に複数のOSを導入することによって形成された複数の仮想サーバと、
上記物理サーバ及び各仮想サーバと接続された管理サーバとを備えた仮想サーバ管理システムであって、
上記管理サーバは、上記物理サーバが保有する特定種類のリソースの量である保有リソース量と、この物理サーバの保有リソース量の中から上記の各仮想サーバに割り当てた割当リソース量を登録しておくリソース配分情報記憶手段と、
実行対象であるジョブを登録しておくジョブ情報記憶手段と、
上記リソース配分情報記憶手段に格納された物理サーバの保有リソース量から、各仮想サーバから送信された利用リソース量の総計値を減算することによって、物理サーバの現時点の余裕リソース量を求める処理と、上記リソース配分情報記憶手段に格納された各仮想サーバの割当リソース量から各仮想サーバの上記利用リソース量を減算することによって、各仮想サーバの現時点の余裕リソース量を算出する処理と、何れかの仮想サーバの余裕リソース量が上記物理サーバの余裕リソース量を超えている場合には、当該仮想サーバの余裕リソース量を物理サーバの余裕リソース量に補正する処理を実行するリソース利用状況算出手段と、
少なくとも各仮想サーバの上記余裕リソース量を所定のルールに当てはめることによって、上記ジョブ情報記憶手段に格納されたジョブの実行を担当する仮想サーバを特定すると共に、当該仮想サーバに対して当該ジョブの実行を指令するジョブ割当手段と、
を備えたことを特徴とする仮想サーバ管理システム。 - 上記ジョブ割当手段は、各仮想サーバの中で、上記余裕リソース量が最大の仮想サーバを、上記ジョブの実行を担当する仮想サーバとして特定すること特徴とする請求項1に記載の仮想サーバ管理システム。
- 上記物理サーバが複数存在すると共に、各物理サーバ上に複数の仮想サーバが形成された、請求項1または2に記載の仮想サーバ管理システムにおいて、
複数の仮想サーバが上記ジョブの実行を担当する仮想サーバとして特定された場合に、上記ジョブ割当手段は、最大の余裕リソース量を備えた物理サーバに属する仮想サーバを、ジョブの実行を担当する仮想サーバと特定することを特徴とする仮想サーバ管理システム。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2015041924A JP5857144B2 (ja) | 2015-03-04 | 2015-03-04 | 仮想サーバ管理システム |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2015041924A JP5857144B2 (ja) | 2015-03-04 | 2015-03-04 | 仮想サーバ管理システム |
Related Parent Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2012027804A Division JP5722247B2 (ja) | 2012-02-10 | 2012-02-10 | 仮想サーバ管理システム |
Publications (2)
Publication Number | Publication Date |
---|---|
JP2015127974A JP2015127974A (ja) | 2015-07-09 |
JP5857144B2 true JP5857144B2 (ja) | 2016-02-10 |
Family
ID=53837910
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2015041924A Expired - Fee Related JP5857144B2 (ja) | 2015-03-04 | 2015-03-04 | 仮想サーバ管理システム |
Country Status (1)
Country | Link |
---|---|
JP (1) | JP5857144B2 (ja) |
Family Cites Families (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP4739271B2 (ja) * | 2007-04-19 | 2011-08-03 | 株式会社富士通アドバンストエンジニアリング | 電源制御装置、仮想サーバ管理システム、電源制御方法および電源制御プログラム |
JP5338906B2 (ja) * | 2009-06-01 | 2013-11-13 | 富士通株式会社 | サーバ管理プログラム、管理サーバ、仮想サーバ配置方法 |
JP5396339B2 (ja) * | 2009-10-28 | 2014-01-22 | 株式会社日立製作所 | リソース制御方法及びリソース制御システム |
US9229783B2 (en) * | 2010-03-31 | 2016-01-05 | International Business Machines Corporation | Methods and apparatus for resource capacity evaluation in a system of virtual containers |
JP5664376B2 (ja) * | 2011-03-17 | 2015-02-04 | 日本電気株式会社 | 仮想計算機割り当てシステム、及び仮想計算機割り当て方法 |
-
2015
- 2015-03-04 JP JP2015041924A patent/JP5857144B2/ja not_active Expired - Fee Related
Also Published As
Publication number | Publication date |
---|---|
JP2015127974A (ja) | 2015-07-09 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US20200287961A1 (en) | Balancing resources in distributed computing environments | |
US9588789B2 (en) | Management apparatus and workload distribution management method | |
US9442763B2 (en) | Resource allocation method and resource management platform | |
US9183016B2 (en) | Adaptive task scheduling of Hadoop in a virtualized environment | |
US9304803B2 (en) | Cooperative application workload scheduling for a consolidated virtual environment | |
JP6386165B2 (ja) | 分散コンピュータシステムへの電力割り振りに変更がある場合に中断され得るジョブ及び中断され得ないジョブを管理するための方法並びに装置 | |
US8468246B2 (en) | System and method for allocating resources in a distributed computing system | |
EP2901312B1 (en) | Real time optimization of compute infrastructure in a virtualized environment | |
US10554575B2 (en) | Equitable sharing of system resources in workflow execution | |
JP6297980B2 (ja) | クラスタに依頼されたタスクを実行するために前記クラスタのコンピュータ資源を割り当てるための方法、コンピュータプログラム、およびデバイス | |
Dhari et al. | An efficient load balancing scheme for cloud computing | |
CN109564528B (zh) | 分布式计算中计算资源分配的***和方法 | |
US20170083367A1 (en) | System and method for resource management | |
Gabi et al. | Systematic review on existing load balancing techniques in cloud computing | |
Garala et al. | A performance analysis of load Balancing algorithms in Cloud environment | |
CN104917839A (zh) | 一种用于云计算环境下的负载均衡方法 | |
Xu et al. | Prophet: Scheduling executors with time-varying resource demands on data-parallel computation frameworks | |
JP2013164750A (ja) | ジョブ実行管理システム | |
JP5515810B2 (ja) | 負荷制御装置 | |
JP5722247B2 (ja) | 仮想サーバ管理システム | |
JP5857144B2 (ja) | 仮想サーバ管理システム | |
KR100788328B1 (ko) | 그리드 컴퓨팅을 이용한 미들웨어 시스템 및 그 동작 방법 | |
KR102014246B1 (ko) | 리소스 통합관리를 위한 메소스 처리 장치 및 방법 | |
JP6191361B2 (ja) | 情報処理システム、情報処理システムの制御方法及び制御プログラム | |
JP2013041485A (ja) | 仮想計算機システムおよび資源割り当て制御方法 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20151124 |
|
TRDD | Decision of grant or rejection written | ||
A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20151130 |
|
A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20151214 |
|
R150 | Certificate of patent or registration of utility model |
Ref document number: 5857144 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
LAPS | Cancellation because of no payment of annual fees |