JP5740352B2 - 仮想計算機システム及び仮想計算機システムの負荷制御方法 - Google Patents

Description

本発明は、仮想計算機システムの負荷制御に関する。

仮想計算機システムとは、１台の計算機を複数の仮想的な計算機に分割することにより、複数のオペレーティングシステム（ＯＳ）を動作させることを可能とするシステムである。物理的な計算機上に仮想計算機モニタ（ＶＭＭ）を動作させ、物理ＣＰＵや物理メモリといった物理資源を論理的に分割し、論理ＣＰＵや論理メモリといった論理資源を適切な仮想計算機（ＶＭ）に割当てることにより、仮想計算機上で動作する複数のＯＳ各々が自ＯＳ専用のＣＰＵやメモリを持っているかのように動作させるシステムのことである。 １台の物理計算機上の複数のＶＭの性能は、物理ＣＰＵや物理メモリを、どれだけ各ＶＭに配分するかにより決まる。従来では、計算機システムの運用者が、例えば物理ＣＰＵリソースの配分量を経験的に決定し、ＶＭ毎にその配分量を設定してきた。また、ＶＭ毎に負荷のアンバランスが生じた場合には、運用者が経験的に物理ＣＰＵリソースの再配分量を決定しＶＭ毎に再設定していた。

Scott Mueller他,"Upgrading and Repairing Servers", QUE, 2006, p.393

従来、仮想計算機システムを用いない物理計算機システムの負荷監視は、ＯＳ内に設けられているＣＰＵ性能モニタプログラムを動作させて、ＣＰＵ使用率を測定することにより実行されてきた。ＣＰＵ使用率とは、単位時間に対するＣＰＵが処理を実行した時間の割合である。

ＣＰＵ性能を表示できるモニタプログラム例としては、例えばMicrosoft社製のWindows(登録商標) 2003オペレーティングシステムの"perfmon"や、オープンソースソフトウェアであるLinux(登録商標)オペレーティングシステムの"vmstat"が、知られている。（非特許文献１：Scott Mueller他,"Upgrading and Repairing Servers", QUE, 2006, p.393）
また、仮想計算機システムを用いる場合、ＶＭ内部でのＣＰＵ使用率の測定は、物理計算機システムの場合と同様にして、ＯＳ内のＣＰＵ性能モニタプログラムを用いて行われる。これは、そのＶＭに割当てられた論理ＣＰＵのうち、何％を使用しているかを測定することを意味する。さらに、ＶＭＭ上のＣＰＵ使用率測定ツールを用いることにより、ＶＭ個々が物理計算機システム全体のうち何％の資源を使用しているかを、個別に表示する手法が一般である。

複数の物理計算機から構成される計算機システムの運用者は、計算機資源のＣＰＵ使用率を最適にして運用することを目標としている。そのため、計算機システムの運用者は、負荷の重いサーバと負荷の軽いサーバが混在したり、システム的にバランスの悪い状態を発見した場合には、なんとかバランスさせようと努力する。仮想計算機システムを使用しない従来の運用では、負荷の要求元のトラフィックを一部負荷の軽いサーバに流すよう、ロードバランサを用いて調整するといった方法がとられる。

しかしながら、負荷の重い物理計算機と負荷の軽い物理計算機との間で、このような調整が可能な場合は稀である。実質的には、非常に負荷の重い計算機に対しては、現在の計算機より計算性能の高い計算機に交換するという運用が、普通であった。このような負荷バランスの調整方法は、期間を要する上に、システム構築の手間や新規物理計算機の購入費用などのコストもかかるという課題があった。

上述の物理計算機システムにおける課題を解決するために、近年、仮想計算機システムが用いられている。仮想計算機システムでは、一般に、物理ＣＰＵリソースを論理ＣＰＵリソースに割当てる割合を調整する事により、負荷バランスを調整している。

しかしながら、上述の課題を解決可能とする仮想計算機システムにおいても、さらに下記のような課題がある。

仮想計算機システムを使用したシステムの場合には、予め計算性能の高い物理計算機を導入し、その上で複数のＶＭを立ち上げて複数のＯＳを動作させる。そして、各々のＶＭが使用可能な物理ＣＰＵリソースの上限（サービス率）を指定することにより、運用性の高い計算機システムを構成できる。予め上限を設定したサービス率よりも多くのリソースを使う状況となったＶＭには、サービス率を増加させた設定をおこなう。その代わりに、あまりリソースを使わないＶＭのサービス率を低下させた設定を行なう作業により、負荷バランス調整が実施可能となる。これにより、ネットワーク上のロードバランサの設定作業や物理サーバの交換作業などが不要となり、運用者の手間は大幅に削減可能となる。

しかしながら、仮想計算機システムにおいて、前記のような調整作業を実施したとしても、単純にＶＭ毎のＣＰＵ性能を測定するだけでは、それらＶＭが動作する物理サーバの利用率を最適にできないという課題があった。

上記課題を解決するために、本発明に係る仮想計算機システムは、従来から用いられてきたＶＭ内のＯＳが測定するＣＰＵ使用率に加え、ＶＭＭがＶＭ毎に測定し物理ＣＰＵ割当がどの程度不足しているかを示すＣＰＵ不足率を取得し、外部の管理サーバ上に１台の物理計算機上の複数ＶＭの性能バラツキをより平準化するサービス率の再配分量を計算し、計算結果を用いてＶＭＭに対してサービス率の変更を指示する。

すなわち、本発明に係る仮想計算機システム及びその負荷制御方法は、物理ＣＰＵ及び物理メモリを含む物理資源、論理ＣＰＵ及び論理メモリを含む論理資源を割当てられた仮想計算機、及び物理資源を論理的に分割した論理資源を仮想計算機に割当てる仮想計算機モニタを有する物理計算機と、物理計算機に接続する管理サーバとを備える。仮想計算機は、物理ＣＰＵの使用率を測定する使用率測定部を有し、仮想計算機モニタは、仮想計算機が使用可能な物理ＣＰＵリソースの上限であるサービス率を仮想計算機毎に記憶するサービス率記憶部と、仮想計算機毎に論理ＣＰＵに対する物理ＣＰＵの割当の不足率を測定する不足率測定部とを有する。管理サーバの調整部は、仮想計算機から、仮想計算機の使用率を取得し、仮想計算機モニタから、仮想計算機のサービス率及び不足率を取得し、所定の時間間隔における仮想計算機の平均使用率及び平均不足率を算出する。管理サーバの調整部は、平均使用率が所定の使用率閾値以上であり、且つ平均不足率が所定の不足率閾値以上である場合、仮想計算機の第１のサービス率に配分を加算し、配分を加算した第１のサービス率を第２のサービス率として仮想計算機モニタに通知する。仮想計算機モニタは、通知された第２のサービス率を、サービス率記憶部に設定する。

本発明により、仮想計算機システム上の複数の仮想計算機間で、負荷の偏りなく効率的な物理資源の利用が可能となる。

サービス率自動調整機構の処理構成を表すブロック図である。 物理計算機のハードウェア構成例である。 ＣＰＵ使用率とＣＰＵ不足率の関係を示す例である。 論理ＣＰＵへの物理ＣＰＵ資源割当て方法を示す。 仮想化システムの構成例である。 サービス率自動調整機構に含まれる性能データ格納部のテーブル例である。 サービス率自動調整機構に含まれる設定データ格納部のテーブル例である。 サービス率自動調整機構に含まれるサービス率調整用データ格納部のテーブル例である。 サービス率自動調整機構の処理フローを示すフローチャートの前半である。 サービス率自動調整機構の処理フローを示すフローチャートの後半である。

図２に、本発明を構成する仮想計算機システムを含む物理計算機のハードウェア構成例を示す。

物理計算機201と管理サーバ212とが、ＬＡＮ211により接続されている。物理計算機201は、物理ＣＰＵ204、Ｉ／Ｏアダプタ203、主記憶装置202を備える。物理ＣＰＵ204は、主記憶装置202から命令を取得して演算を実行することによりプログラムを実行し、Ｉ／Ｏアダプタ203を制御することによりストレージ208,209のアクセス、ＤＶＤドライブ210のアクセス、ＬＡＮ211のアクセスなどを実行する。

主記憶装置202は、ＶＭＭプログラムを配置するＶＭＭプログラム領域205、仮想化された計算機の主記憶装置部分として使用されるＶＭ１領域206、ＶＭ２領域207などを備える。物理計算機201の電源が投入されると、ＶＭＭプログラムは、ＶＭＭ用記憶媒体213からＩ／Ｏアダプタ203-4を経由してＶＭＭプログラム領域205にロードされる。ＶＭＭプログラムは、物理ＣＰＵ204により実行されることで仮想計算機モニタとして動作を開始し、外部管理サーバ212との通信が可能となる。

運用者の操作により管理サーバ212からＶＭ１およびＶＭ２の起動を指示すると、ＶＭＭは、Ｉ／Ｏアダプタ203-1を経由してＶＭ１用記憶媒体208をアクセスし、ＶＭ１上で動作するプログラムをＶＭ１領域206にロードする。同様に、ＶＭＭは、ＶＭ２用記憶媒体209からＶＭ２上で動作するプログラムをＶＭ２領域207にロードする。ＶＭＭは、必要に応じて物理ＣＰＵ204にＶＭ１領域206やＶＭ２領域207のプログラム実行を開始させたり、中断させたりすることにより、物理ＣＰＵ204リソースをＶＭに対して適切な量だけ割当てる。

ＶＭＭやＶＭは、以上の原理で動作する。以後、本発明に必要な部分以外はハードウェアの具体的な記述を省略する。

本発明において、ＣＰＵ割当ての制御のために導入する「ＣＰＵ不足率」とは、仮想計算機環境において定義される物理CPUの資源割当てについて、資源割当ての待ち状態の程度を現す概念である。以下、ＣＰＵ不足率の概念を、図４を用いて説明する。

物理計算機201内に構成される仮想計算機環境においては、仮想計算機モニタ（VMM）1004が、例えば物理CPU204のような物理資源を、VM1002上の論理CPU1003のような論理資源に適切に割当てることにより、仮想計算機（VM）1002の資源使用量を制御する。VMM1004内に設けられたスケジューラ1007は、多数の論理CPU1003各々にどの物理CPU204を割当てるかを判断し、割当て操作を実施する。

各VM1002上でプログラムが起動されると、ＶＭＭ1004は、起動されたプログラムを実行するために、論理CPU1003に物理CPU204を割当てる制御を実行する。論理CPU1003は、仮想的なＣＰＵであり、物理CPU204という物理的な資源を割当てることにより、プログラムの実行が可能となる。

また、各ＶＭ1002には、物理ＣＰＵ204資源を最大でどれだけ使用しても良いかを示すサービス率が定義される。サービス率は、サービス率記憶部1008に格納される。図４では、ＶＭ１のサービス率を37.5％、ＶＭ２のサービス率を62.5％と設定済みである場合を示す。

ＶＭ１に注目すると、ＶＭ１が使用可能な物理ＣＰＵ数は、最大で1.5個である（物理ＣＰＵ総数×ＶＭ１のサービス率）。これに対して、ＶＭ１の論理ＣＰＵは、４個存在する。この構成において、負荷状況に応じてＣＰＵ不足率がどのような考え方になるかを例示する。

４個の論理ＣＰＵ1003のうち、1.5個以内の論理ＣＰＵ1003しか動作しない負荷状況では、ＶＭＭ1004のスケジューラ1007は、前記1.5個以内の論理ＣＰＵ1003すべてに物理ＣＰＵ204を割当てることができる。したがって、物理ＣＰＵ204は充足されており、物理ＣＰＵ204の不足は発生していない。この場合、ＣＰＵ不足率は０％ということになる。

ＶＭ１内の４個の論理ＣＰＵ1003のうち４個全部が動作しなければならない場合、動作要求全部が開始されてから完了するために必要な時間は、物理ＣＰＵ204が1.5個しか使用できないため、物理ＣＰＵ204の個数が充足されている場合の約2.7倍となる。つまり、ある単位時間を考えると、４個の物理ＣＰＵを必要としているのに物理ＣＰＵが1.5個しかないために、残り2.5個分の論理ＣＰＵ1003が待つことになる。このとき、ＣＰＵ不足率は約167％ということになる（(ＶＭ１が必要とする論理ＣＰＵ個数÷ＶＭ１が使用可能な物理ＣＰＵ個数)−１）。

ＣＰＵ不足率という尺度であれば、ＶＭ上で動作するＯＳから観測可能なＣＰＵ使用率のみでは分からない、真のＣＰＵ負荷状況が分かる。例えば、ＶＭ１とＶＭ２の上では、各々の上で動作するＯＳがＣＰＵ使用率を100％と観測していたとしても、ＶＭ１の論理ＣＰＵは２個が待ちであり、ＶＭ２の論理ＣＰＵは1個が待ちである、といった場合には、CPU不足率はＶＭ１の場合の方が高くなりＶＭ２よりも実質的な負荷が高いことが分る。

さらに注意が必要な点は、ゲストＯＳ上で測定されるＣＰＵ使用率が100％に達しない場合にも、ＣＰＵ不足状態が発生するケースの存在である。このケースでは、従来通りのＯＳ上で計測したＣＰＵ使用率だけで評価すると、ＣＰＵリソースは十分に足りているように見えるが、実際には物理ＣＰＵが不足しているのでリソースの追加が望ましいのである。

図３は、ＶＭ１上でディスパッチ要求されている論理ＣＰＵの数（Ｌ）と、ＶＭ１に対するサービス率設定により使用可能となっている物理ＣＰＵの数（Ｐ）との大小関係により、ゲストＯＳ上で観測されるＣＰＵ使用率（ｃ）とＶＭＭから測定されるＣＰＵ不足率（ｓ）とが、どのように変化するかを例示した表である。L=2、P=1.5のとき、ＶＭ１のゲストＯＳ上では、論理ＣＰＵを２個しか動作させようとしていないので、ＣＰＵ使用率は50％と測定される。しかし、物理ＣＰＵを1.5個しか使用できないため、論理ＣＰＵでは待ちが発生し、ＣＰＵ不足率は33.3％となる。このような意味でも、ＣＰＵ不足率を見なければ、真のＣＰＵ負荷を判断することができないことがわかる。

図５は仮想計算機システムの構成例である。

物理計算機201には、物理CPU204がｎ個備わり、物理メモリ1151がｎ個備わっている。物理計算機201上で動作するVMM（仮想計算機モニタ）1004が１つ備わり、物理計算機201上で動作するVM（仮想計算機）1002がｎ台備わっている。

VMM1004には、VM1002-1〜ｎに物理CPU204-1〜ｎのリソースを配分するスケジューラ1007と、VM1002-1〜ｎの不足率を測定する不足率測定部1104と、VM1002-1〜ｎに物理CPU204-1〜ｎのリソースを割当てする時の配分比率であるサービス率を記憶しておくサービス率記憶部1008がある。なお、サービス率は、予めユーザ等により設定されるものである。

VM1002には、スケジューラ1007によって割当てられた論理CPU1003が備わっている。図５の例では、論理CPU1003は２つ割当てられているが、物理CPU204の搭載数以下であればいくつでもよい。また、VM1002毎に論理CPU1003の数に違いがあってもよい。

VM1002には、VM1002上で動作するゲストOS1121がある。VM1002で使用するメモリは、物理メモリ1151から占有的にスケジューラ1007が割当てる。

ゲストOS1121には、CPU使用率を測定するCPU使用率測定機構1113が動作している。CPU使用率測定機構1113は、OSのCPU使用率取得機能を用いて、定期的にCPU使用率を測定する。

不足率測定部1104は、スケジューラ1007より、論理CPU1003の命令が物理CPU204で実行されるまでの待機時間と命令実行途中の割り込みによる中断時間とをVM1002毎に取得して、不足率を算出する。この時間の合計は、論理CPU1003の命令実行が待たされた時間、すなわち物理CPU204のリソースが不足していた時間を表しており、不足時間と呼ぶ。不足率測定部1104は、VM1002毎に論理CPU1003が物理CPU204に割当てられる最大時間に対する不足時間を不足率として、単位時間で測定し計算している。

物理計算機201は、LAN211に接続されている。

管理サーバ212は、物理メモリ1162、物理CPU1163が搭載され、ユーザインターフェースである情報出力用の表示部1165とユーザ入力用の入力部1166を備えている。

管理サーバ212には、管理サーバ212上で動作するOS1164があり、OS1164上ではサービス率自動調整機構1201が動作する。

管理サーバ212は、LAN211に接続されており、LAN211を介して物理計算機201と通信することができる。

管理サーバ212上で動作するサービス率自動調整機構1201は、LAN211を介してVMM1004と通信し、不足率測定部1104で測定したVM1002のCPU不足率データを取得する。また、サービス率自動調整機構1201は、LAN211を介してVM1002と通信し、CPU使用率測定機構1113で測定したVM1002のCPU使用率データを、取得する。

図１は、図５のサービス率自動調整機構1201の詳細なブロック構成を示している。

サービス率自動調整機構1201は、LAN211を介して物理計算機201と通信をおこなうための対サーバ通信部1205、CPU使用率やCPU不足率を取得する性能データ取得部1202、性能データを記憶しておく為の性能データ格納部1211、性能データを表示させるための性能値表示部1241、VM1002に設定するサービス率を計算するサービス率調整部1203、計算したサービス率をVM1002に設定するサービス率設定部1204、VM1002の設定値を取得するVM設定取得部1206、VM1002の設定値を記憶しておく設定データ格納部1221、サービス率の自動調整に必要な情報を記録しておくサービス率調整用データ格納部1231、設定データ格納部1221にデータを入力する設定入力部1242、を有する。

サービス率自動調整機構1201は、動作開始直後に、VM設定取得部1206が動作し、VMのサービス率を取得する。取得する方法を次に説明する。

VM設定取得部1206は、設定データ格納部1221のVMM設定データテーブル1401のVMM識別子列1402を読み出し、VMM設定データテーブル1401に登録されている全VMMに対し、対サーバ通信部1205にサービス率取得コマンドを発行する。

対サーバ通信部1205は、VM設定取得部1206からのサービス率取得コマンドを受けて、全VMMにサービス率取得コマンドを送信する。

対サーバ通信部1205は、全VMMよりレスポンスを受信すると、VM設定取得部1206にレスポンスデータを返す。

VM設定取得部1206は、対サーバ通信部1205から取得したレスポンスデータに含まれるサービス率を、設定データ格納部1221のVM設定データテーブルに記録する。サービス率は、VM単位に存在する。サービス率は、設定データ格納部1221の設定データテーブルに、VM毎に記録される。

サービス率の取得を完了すると、性能データ取得部1202は、性能データの取得を開始する。性能データとは、VMのCPU使用率とCPU不足率のことである。性能データの取得する方法を次に説明する。

性能データ取得部1202は、最初に設定データ格納部1221のVMM設定データテーブル1401より、測定間隔1403を取得する。測定間隔1403は、性能データ取得部1202が採取する時間間隔であり、VMM毎に設定されている。

性能データ取得部1202は、対象VMMの測定間隔1403だけ時間が経過すると、対サーバ通信部1205に対象VMMへの性能データ取得コマンドを発行する。

対サーバ通信部1205は、性能データ取得部1202からの性能データ取得コマンドを受けて、対象VMMに性能データ取得コマンドを送信する。

対サーバ通信部1205は、対象VMMよりレスポンスを受信すると、性能データ取得部1202にレスポンスデータを返す。

性能データ取得部1202は、対サーバ通信部1205から取得した性能データを、性能データ格納部1211の性能データテーブル1301に記録する。

性能データの取得を開始したあと、サービス率調整部1203は、サービス率の自動調整を開始する。サービス率の自動調整方法を次に説明する。

サービス率調整部1203は、最初に設定データ格納部1221のVMM設定データテーブル1401より、自動調整間隔1404を取得する。自動調整間隔1404は、サービス率調整部1203がサービス率の自動設定を行なう時間間隔であり、VMM毎に設定されている。

サービス率調整部1203は、対象VMMの自動調整間隔1404だけ時間が経過すると、サービス率自動調整処理を実行する。なお、サービス率自動調整処理は、図９を用いて後述する。

サービス率自動調整処理の中で、VMのサービス率の変更が必要な場合、サービス率調整部1203は、サービス率設定部1204にコマンドを発行する。

サービス率設定部1204は、サービス率調整部1203からサービス率の変更のコマンドを受け付けると、対サーバ通信部1205に対象VMMへの対象VMのサービス率変更コマンドを発行し、対サーバ通信部1205は対象VMのサービス率変更コマンドを受けて、対象VMMにサービス率変更コマンドを送信する。

図６は、図１の性能データ格納部1211のテーブルフォーマットの詳細を示している。

性能データ格納部1211は、性能データテーブル1301をもつ。性能データテーブル1301は、性能データを取得した時刻を記録しておく取得時刻列1302、VMを識別するためのVM識別子列1304、そのVMのCPU使用率を記録するCPU使用率列1305、そのVMのCPU不足率を記録するCPU不足率列1306を有する。VM識別子列1304とCPU使用率列1305とCPU不足率列1306とを１組として、性能データを取得した全VMの性能データが格納される。性能データ取得部1202は、性能データを取得するたびに、性能データテーブル1301に書き込む。 図７は、図１の設定データ格納部1221のテーブルフォーマットの詳細を示している。

設定データ格納部1221は、VMM毎の設定を記録しておくVMM設定データテーブル1401と、VMの設定を格納しておくVM設定データテーブル1451とをもつ。VM設定データテーブル1451は、VMM単位のテーブルで、対象VMMの数だけテーブルをもつ。

VMM設定データテーブル1401は、あらかじめ設定されるもので、図１の入力部1166でユーザが入力した値を設定入力部1242が受けて、その値を設定データ格納部1221に書き込む。VMM設定データテーブル1401には、VMM識別子列1402と、測定間隔列1403と、自動調整間隔列1404と、CPU使用率閾値列1405と、CPU不足率閾値列1406と連続回数閾値1407と、条件式列1408と、サービス率調整式列1409がある。

VMM識別子列1402には、VMMを識別するための値を格納する。この列に格納されたVMMが、サービス率自動調整の対象VMMとなる。

測定間隔列1403は、性能データ取得部1202が性能データを取得する時間間隔である。

自動調整間隔列1404は、サービス率調整部1203がサービス率の自動調整を実行する時間間隔である。

CPU使用率閾値列1405は、サービス率の調整が必要なVMを判別するのに必要なCPU使用率の閾値である。CPU使用率がこの閾値を越えたVMが、サービス率調整の対象VMの候補となる。

CPU不足率閾値列1406は、サービス率の調整が必要なVMを判別するのに必要なCPU不足率の閾値である。CPU不足率がこの閾値を越えたVMが、サービス率調整の対象VMの候補となる。

条件式列1408は、サービス率の調整が必要なVMを判定する条件式を格納する。図７の例では、「CPU使用率閾値以上 かつ CPU不足率閾値以上」としている。条件式は、図７の例を固定的にしてもよい。対象VMMごとに可変にしておく事で、VMの構成に柔軟に対応可能となる。

サービス率調整式列1409は、サービス率の調整が必要と判定したVMに対し、実際のサービス率の調整方法を記述しておく。図７の例では、「不足率最大VMを5%上げ、使用率最低VMを5%下げる」としている。サービス率調整式は、図７の例を固定的にしてもよい。対象VMMごとに可変にしておく事で、VMの構成に柔軟に対応可能となる。

VM設定データテーブル1451には、VMを識別する為のVM識別子列1452と、そのVMのサービス率を格納しておくサービス率列1453がある。サービス率は、図１のVM設定取得部1206が対象VMMから取得して、VM識別子列1452に書き込む。

図８は、図１のサービス率調整用データ格納部1231のテーブルフォーマットの詳細を示している。

サービス率調整用データ格納部1231は、サービス率調整用のデータを格納しておくサービス率調整用データテーブル1501をもつ。サービス率調整用データテーブル1501はVMM単位のテーブルで、対象VMMの数だけテーブルをもつ。

サービス率調整用データテーブル1501には、VMを識別するためのVM識別子列1502と、そのVMの平均CPU使用率を格納する平均CPU使用率列1504と、そのVMの平均CPU不足率を格納する平均CPU不足率列15054と、VMM設定データテーブル1401の条件式1408の条件が合致した連続の回数を格納する連続回数列1506がある。

サービス率調整用データテーブル1501は、図１のサービス率調整部でサービス率の自動調整処理が実行される毎に書き換わる。

図９及び１０は、サービス率調整部1203が実行するサービス率自動調整処理のフロー例を示しており、VMM単位で処理することを前提としている。フローチャートを説明する上で、対象を図５に示す仮想計算機システムとする。

ステップ1601では、VMM1004の設定値（自動調整間隔1405、CPU使用率閾値1405、CPU不足率閾値1406、連続回数閾値1407、条件式1408、サービス率調整式1409）を、VMM設定データテーブル1401から取得する。

ステップ1602では、VMM1004のVM設定データテーブル1451からレコード登録順が最初のレコードを取得し、そのレコードからVM１(1111-1)のVM識別子1452を取り出す。

ステップ1604では、性能データテーブル1301から、ステップ1602で取り出したVM１(1111-1)のVM識別子1452の性能データを取り出す。この時取り出す性能データは、前回のサービス率自動調整処理から現在時刻までに、測定した性能データである。すなわち、性能データテーブル1301のレコードのうち、取得時刻1302が、現在時刻からステップ1601で取り出した自動調整間隔1404だけ過去の時刻から、現在時刻との間の時刻になっているレコードを取得する。

ステップ1605では、ステップ1604で取得した性能データから、VM1(1111-1)のCPU使用率1305の合計を取得回数で割った平均値と、VM1(1111-1)のCPU不足率1306の合計を取得回数で割った平均値を求めて、VMM1004のサービス率調整用データテーブルに書き込む。書き込むデータは、VM１(1111-1)の識別子「VM1」をVM識別子1502、現在時刻を最終取得時刻1503、求めた平均CPU使用率を平均CPU使用率1504、求めた平均CPU不足率を平均CPU不足率1505、に書き込む。ただし、VM１(1111-1)のVM識別子がサービス率調整用データテーブル1501のレコードに存在していた場合は、最終取得時刻1503と平均CPU使用率1504と平均CPU不足率1505に、上書きのみする。

ステップ1605で、平均CPU使用率1504と平均CPU不足率1605とをサービス率調整用データテーブル1501に書き込むのは、性能データテーブル1301のデータを削除可能とするためである。性能データは、データの粒度を細かくするために、なるべく測定間隔1403を短く取るのが望ましい。しかし、測定間隔1403を短くすると、性能データテーブル1301のレコード数が増す事になる。また、対象VMMや対象VMの数にも比例し、これらが多くなると管理サーバ1151のメモリを圧迫し、また性能データテーブル1301への書き込み／読み取り処理の性能が落ちることになる。したがって、性能データテーブル1301に書き込む性能データは定期的に削除する事が必要である。

ステップ1606では、ステップ1602およびステップ1603で取得したレコードが、VMM1004のVM設定データテーブル1451のテーブル順で最後のレコードかを確認し、最後のレコードであればステップ1607へ、最後のレコードでない場合はステップ1603へ分岐する。本例の場合、VM識別子1452がVMn（1111-n）のレコードが最後のレコードとなる。

ステップ1603では、VMM1004のVM設定データテーブル1451から、ステップ1606で最後のレコードかを判定したレコードのレコード登録順の次のレコード順のレコードを取得し、そのレコードからVM1004のVM識別子1452を取り出す。ここで取り出したVM識別子1452を元に、ステップ1604、ステップ1605を実行し、ステップ1606の判定を行ない、レコード順が最後のレコードになってステップ1607に分岐するまで、繰り返し実行する。

ステップ1607では、VMM1004のサービス率調整用データテーブル1501から、レコード順が最初のレコードを取得し、そのレコードから平均CPU使用率1504と平均CPU不足率1505と連続回数1506を取り出す。

ステップ1609では、ステップ1607で取り出した平均CPU使用率1514が、ステップ1601で取り出したCPU使用率閾値1405以上の数値かを判定する。CPU使用率閾値1405以上の場合はステップ1610へ、未満の場合はステップ1612へ分岐する。ステップ1612へ分岐する場合は、サービス率を上げる対象から外す事とする。

ステップ1610では、ステップ1609にて平均CPU使用率1514がCPU使用率閾値1405以上と判定された場合に、ステップ1607で取り出した平均CPU不足率1515が、ステップ1601で取り出したCPU不足率閾値1406以上の数値かを判定する。CPU不足率閾値1406以上の場合はステップ1611へ、未満の場合はステップ1612へ分岐する。ステップ1612へ分岐する場合は、サービス率を上げる対象から外す事とする。

ステップ1609とステップ1610で判定した内容は、VMM設定データテーブル1401の条件式1408に記載された内容に従っている。本実施例では、条件式1408は固定的な内容としているが、条件式1408を対象VMM毎に変更してもよい。この条件を変更可能とする事で、サービス率自動調整機構を修正する事なく、サービス率を増加させる対象VMの判断を変更する必要が発生した場合に柔軟に対応可能となる。

ステップ1611では、ステップ1607で取得した連続回数1506のカウントを１加算した値を、VMM1004のサービス率調整用データテーブル1501の連続回数1506へ書き込む。

ステップ1612では、VMM1004のサービス率調整用データテーブル1501の連続回数1506の値を、0に初期化する。

ステップ1613では、ステップ1607およびステップ1608で取得したレコードが、VMM1004のサービス率調整用データテーブル1501のレコード順が最後のレコードかを確認し、最後のレコードであればステップ1614へ、最後のレコードでない場合はステップ1608へ分岐する。

ステップ1608では、VMM1004のサービス率調整用データテーブル1501から、レコード順の次のレコードを取得し、そのレコードから平均CPU使用率1504と平均CPU不足率1505と連続回数1506を取り出す。

ステップ1614では、サービス率調整用テーブル1501より、連続回数1516がステップ1601で取得してきた連続回数閾値1407の値以上のVMを、検索する。この連続回数1516は、ステップ1609やステップ1610で判定した値が、連続で何回合致したかを表すものである。この連続回数1516の値を確認する事で、一時的なCPU不足のVMをサービス率増加の対象から外す事が可能となり、継続したCPU不足のVMのみを対象とする事ができる。なお、一時的なCPU不足のVMも対象としたい場合は、連続回数1516を1とすればよい。

ステップ1615では、ステップ1614で検索したVMの数により、分岐を行なう。ステップ1614で検索したVMの数が0で、該当VMが存在しなかった場合は、本処理は終了となる。ステップ1614で検索したVMの数が1の場合は、該当VMが１つなので、該当VMをサービス率の調整対象VMとし、ステップ1621へ分岐する。ステップ1614で検索したVMの数が２以上の場合は、対象VMが複数となるので、対象VMを１つに選別する為にステップ1616へ分岐する。なお本実施例では対象VMを１つとするが、複数としてもよい。

ステップ1616では、ステップ1614で検索した複数のVMから対象VMを選別するために、ステップ1614で検索した複数のVMの中で、サービス率調整用データテーブル1501から平均CPU不足率1515が最大のVMを検索する。ここで、平均CPU使用率1514よりも平均CPU不足率1515が最大のVMを検索するのは、より不足が発生しているVMを優先的にサービス率の増加を行なう為である。

ステップ1617では、ステップ1616で検索したVMの数により、分岐を行なう。ステップ1616で検索したVMが１つの場合は、そのVMをサービス率の調整対象VMとし、ステップ1621へ分岐する。複数ある場合は、対象VMを１つに選別する為にステップ1618へ分岐する。

ステップ1618では、ステップ1616で検索した複数のVMから対象VMを選別するために、ステップ1616で検索した複数のVMの中で、サービス率調整用データテーブル1501から平均CPU使用率1514が最大のVMを検索する。

ステップ1619では、ステップ1618で検索したVMの数により、分岐を行なう。ステップ1618で検索したVMが１つの場合は、そのVMをサービス率の調整対象VMとし、ステップ1621へ分岐する。複数ある場合は、対象VMを１つに選別する為にステップ1620へ分岐する。

ステップ1620では、ステップ1618で検索した複数のVMから、サービス率調整用データテーブル1501のレコード登録順（行番号）が一番小さい値（最若番）のVMを、サービス率の調整対象VMとする。ここでさらに条件を設けて、ステップ1618で検索した複数のVMの中から対象VMを選別させてもよい。ただし実運用上、ここまで条件が合致するVMが複数存在する事はほぼないと考えられ、仮に発生した場合の選択基準として、本例では必ず一意に決定できるレコードを決定するためにレコード順が一番小さい値（最若番）を対象VMとするようにした。

ステップ1621では、ステップ1614で検索したVM、またはステップ1616で検索したVM、またはステップ1618で検索したVMを、対象VMとする。

ステップ1622では、対象VMMのVM設定データテーブル1451から、対象VMの現在のサービス率1453を取得する。

ステップ1623では、ステップ1622で取得したサービス率に5%加算した値を、対象VMのサービス率として対象VMMに設定する。ここで5%としたのは１例であり、特にこの数値にする必要はない。予め設定されているサービス率調整式1409に従う。

ステップ1624では、ステップ1623で設定したサービス率を、対象VMMのVM設定データテーブル1451の対象VMのサービス率1453に、書き込む。

ステップ1625では、対象VMMのサービス率調整用データテーブル1501の対象VMの連続回数1516に、0を書き込む。

ステップ1626では、対象VMMのサービス率調整用データテーブル1501より、平均CPU使用率1504が最低のVMを検索する。サービス率は物理CPUの配分率を表すものなので、あるVMを5％上げた場合は、他のVMを5％下げる必要がある。その下げる対象のVMを判別するために、平均CPU使用率1504が最低のVMを検索する。

ステップ1627では、ステップ1626で検索したVMの数により、分岐を行なう。ステップ1626で検索したVMの数が1の場合は、該当VMが１つなので、該当VMをサービス率を下げる対象VMとし、ステップ1631へ分岐する。ステップ1626で検索したVMの数が２以上の場合は、対象VMが複数となるので、対象VMを１つに選別する為にステップ1628へ分岐する。なお本実施例では対象VMを１つとするが、複数としてもよい。

ステップ1628では、ステップ1626で検索した複数のVMから対象VMを選別するために、ステップ1626で検索した複数のVMの中で、サービス率調整用データテーブル1501から平均CPU不足率1515が最低のVMを検索する。ここで最低の平均CPU不足率1515のVMを検索するのは、より不足の少ないVMからCPUリソースを取得するためである。

ステップ1629では、ステップ1628で検索したVMの数により、分岐を行なう。ステップ1628で検索したVMが１つの場合は、そのVMをサービス率を下げる対象VMとし、ステップ1631へ分岐する。複数ある場合は、対象VMを１つに選別する為にステップ1630へ分岐する。

ステップ1630では、ステップ1628で検索した複数のVMから、サービス率調整用データテーブル1501のレコード順で最若番のVMを、サービス率を下げる対象VMとする。ここでさらに条件を設けて、ステップ1628で検索した複数のVMの中から対象VMを選別させてもよい。ただし実運用上、ここまで条件が合致するVMが複数存在する事はほぼないと考えられ、仮に発生した場合の選択基準として、絶対的に決定可能なレコードの最若番を対象VMとするようにした。

ステップ1631では、ステップ1626で検索したVM、またはステップ1628で検索したVMを、対象VMとする。

ステップ1632では、対象VMMのVM設定データテーブル1451から、対象VMの現在のサービス率1453を取得する。

ステップ1633では、ステップ1632で取得したサービス率に5%減算した値を、対象VMのサービス率として対象VMMに設定する。

ステップ1634では、ステップ1633で設定したサービス率を、対象VMMのVM設定データテーブル1451の対象VMのサービス率1453に、書き込む。

ステップ1623とステップ1633で変更したサービス率の値は、VMM設定データテーブル1401のサービス率調整式1409に記載された内容に従っている。本実施例ではサービス率調整式1409は固定的な内容としているが、サービス率調整式1409を対象VMM毎に変更してもよい。この調整式を変更可能とする事で、サービス率自動調整機構を修正する事なく、サービス率の増減方法を変更する必要が発生した場合に柔軟に対応可能となる。

ステップ1634の終了で、本フローチャートの処理は終了する。

以上説明したように、本発明を適用した仮想計算機システムでは、ＶＭ間の性能バラツキを平準化することができる。従来では、特定ＶＭによる処理のみ短時間に実行が完了したり、その他のＶＭによる処理は長時間かかるといった処理待ち時間のバラツキが生じていたが、本発明の適用により、処理待ち時間のバラツキが小さくなる。また、物理計算機201のＣＰＵ使用率が向上し、物理リソースの無駄が小さくなるため、計算機システムへの投資効率が向上するという効果がある。

２０１ 物理計算機
２０２ 主記憶装置
２０３ Ｉ／Ｏアダプタ
２０４ 物理ＣＰＵ
２１２ 管理サーバ
１００２ 仮想計算機（ＶＭ）
１００３ 論理ＣＰＵ
１００４ 仮想計算機モニタ（ＶＭＭ）
１００７ スケジューラ
１００８ サービス率記憶部
１１０４ 不足率測定部
１１１２ ゲストOS
１１１３ CPU使用率測定機構
１１５１ 物理メモリ
１１６２ 物理メモリ
１１６３ 物理CPU

Claims (10)

1. 物理ＣＰＵ及び物理メモリを含む物理資源、論理ＣＰＵ及び論理メモリを含む論理資源を割当てられた仮想計算機、及び前記物理資源を論理的に分割した前記論理資源を前記仮想計算機に割当てる仮想計算機モニタを有する物理計算機と、
   前記物理計算機に接続する管理サーバとを備え、
   前記仮想計算機は、前記物理ＣＰＵの使用率を測定する使用率測定部を有し、
   前記仮想計算機モニタは、前記仮想計算機が使用可能な物理ＣＰＵリソースの上限であるサービス率を前記仮想計算機毎に記憶するサービス率記憶部と、前記仮想計算機毎に前記論理ＣＰＵに対する前記物理ＣＰＵの割当の不足率を測定する不足率測定部とを有し、 前記管理サーバの調整部は、
   前記仮想計算機から、前記仮想計算機の前記使用率を取得し、
   前記仮想計算機モニタから、前記仮想計算機のサービス率及び前記不足率を取得し、 所定の時間間隔における前記仮想計算機の平均使用率及び平均不足率を算出し、
   前記平均使用率が所定の使用率閾値以上であり、且つ前記平均不足率が所定の不足率閾値以上である場合、
   前記仮想計算機の第１のサービス率に配分を加算し、配分を加算した第１のサービス率を第２のサービス率として前記仮想計算機モニタに通知し、
   前記仮想計算機モニタは、
   前記通知された第２のサービス率を、前記サービス率記憶部に設定すること
   を特徴とする仮想計算機システム。
2. 前記調整部は、
   前記仮想計算機モニタから取得した前記サービス率を管理する仮想計算機設定データテーブルと、前記仮想計算機モニタ毎に前記使用率閾値及び前記不足率閾値を管理する仮想計算機モニタ設定データテーブルとを格納する設定データ格納部と、
   前記取得した前記使用率及び前記不足率を格納する性能データ格納部と、
   前記算出した前記平均使用率及び前記平均不足率を格納するサービス率調整用データ格納部と、
   前記設定データ格納部、前記性能データ格納部、前記サービス率調整用データ格納部を参照して、前記仮想計算機のサービス率を調整するサービス率調整部とを有すること
   を特徴とする請求項１記載の仮想計算機システム。
3. 前記管理サーバの調整部は、前記第２のサービス率の通知後、
   複数の前記仮想計算機毎の前記平均使用率及び前記平均不足率を格納する前記サービス率調整用データ格納部を参照して、前記平均使用率が最小である仮想計算機を検索し、 前記検索された仮想計算機の第３のサービス率に、前記加算した配分と等しい配分を減算し、配分を減算した第３のサービス率を第４のサービス率として前記仮想計算機モニタに通知し、
   前記仮想計算機モニタは、
   前記通知された第４のサービス率を、前記サービス率記憶部に設定すること
   を特徴とする請求項２記載の仮想計算機システム。
4. 前記管理サーバの調整部は、前記新たなサービス率の通知後、
   前記新たなサービス率を前記仮想計算機設定データテーブルに書き込むことを特徴とする請求項３記載の仮想計算機システム。
5. 前記使用率閾値は、前記仮想計算機モニタ毎に管理され、前記仮想計算機モニタにより動作する仮想計算機のうち前記サービス率の調整が必要な仮想計算機を判定する際に、前記仮想計算機モニタにより動作する仮想計算機の使用率と比較され、
   前記不足率閾値は、前記仮想計算機モニタ毎に管理され、前記仮想計算機モニタにより動作する仮想計算機のうち前記サービス率の調整が必要な仮想計算機を判定する際に、前記仮想計算機モニタにより動作する仮想計算機の不足率と比較されること
   を特徴とする請求項４記載の仮想計算機システム。
6. 前記管理サーバは、物理メモリ、物理ＣＰＵを備えることを特徴とする請求項４記載の仮想計算機システム。
7. 物理ＣＰＵ及び物理メモリを含む物理資源、論理ＣＰＵ及び論理メモリを含む論理資源を割当てられた仮想計算機、及び前記物理資源を論理的に分割した前記論理資源を前記仮想計算機に割当てる仮想計算機モニタを有する物理計算機と、前記物理計算機に接続する管理サーバとを備える仮想計算機システムの負荷制御方法であって、
   前記仮想計算機は、
   前記物理ＣＰＵの使用率を測定し、
   前記仮想計算機モニタは、
   前記仮想計算機が使用可能な物理ＣＰＵリソースの上限であるサービス率を前記仮想計算機毎に記憶し、
   前記仮想計算機毎に前記論理ＣＰＵに対する前記物理ＣＰＵの割当の不足率を測定し、
   前記管理サーバは、
   前記仮想計算機から、前記仮想計算機の前記使用率を取得し、
   前記仮想計算機モニタから、前記仮想計算機のサービス率及び前記不足率を取得し、 所定の時間間隔における前記仮想計算機の平均使用率及び平均不足率を算出し、
   前記平均使用率が所定の使用率閾値以上であり、且つ前記平均不足率が所定の不足率閾値以上である場合、
   前記仮想計算機の第１のサービス率に配分を加算し、
   配分を加算した第１のサービス率を第２のサービス率として前記仮想計算機モニタに通知し、
   前記仮想計算機モニタは、
   前記通知された第２のサービス率を、前記サービス率記憶部に設定すること
   を特徴とする仮想計算機システムの負荷制御方法。
8. 前記管理サーバは、
   前記仮想計算機モニタから取得した前記サービス率を管理する仮想計算機設定データと、前記仮想計算機モニタ毎に前記使用率閾値及び前記不足率閾値を管理する仮想計算機モニタ設定データとを設定データ格納部に格納し、
   前記取得した前記使用率及び前記不足率を性能データ格納部に格納し、
   前記算出した前記平均使用率及び前記平均不足率をサービス率調整用データ格納部に格納し、
   前記設定データ格納部、前記性能データ格納部、前記サービス率調整用データ格納部を参照して、前記仮想計算機のサービス率を調整すること
   を特徴とする請求項７記載の仮想計算機システムの負荷制御方法。
9. 前記管理サーバは、前記第２のサービス率の通知後、
   複数の前記仮想計算機毎の前記平均使用率及び前記平均不足率を格納する前記サービス率調整用データ格納部を参照して、前記平均使用率が最小である仮想計算機を検索し、 前記検索された仮想計算機の第３のサービス率に、前記加算した配分と等しい配分を減算し、配分を減算した第３のサービス率を第４のサービス率として前記仮想計算機モニタに通知し、
   前記仮想計算機モニタは、
   前記通知された第４のサービス率を、前記サービス率記憶部に設定すること
   を特徴とする請求項８記載の仮想計算機システムの負荷制御方法。
10. 前記管理サーバは、前記新たなサービス率の通知後、
    前記新たなサービス率を前記仮想計算機設定データテーブルに書き込むことを特徴とする請求項９記載の仮想計算機システムの負荷制御方法。

Images