JP2020135167A

JP2020135167A - リソース管理装置およびリソース管理方法

Info

Publication number: JP2020135167A
Application number: JP2019025136A
Authority: JP
Inventors: 藤本　圭; Kei Fujimoto; 圭藤本; 光平的場; Kohei Matoba; 荒岡　誠; Makoto Araoka; 誠荒岡
Original assignee: Nippon Telegraph and Telephone Corp
Current assignee: Nippon Telegraph and Telephone Corp
Priority date: 2019-02-15
Filing date: 2019-02-15
Publication date: 2020-08-31
Anticipated expiration: 2039-02-15
Also published as: US20220138017A1; WO2020166423A1; JP7331374B2

Abstract

【課題】複数のゲストが共有するＣＰＵリソースを効率的に利用し、システム全体の処理性能を向上させる。【解決手段】サーバ１０は、ホストＯＳ１０４と、ホストＯＳ１０４上に仮想的に構築された複数の仮想マシン１０８Ａ，１０８Ｂ上でそれぞれ動作する複数のゲストＯＳ１１０Ａ，１１０Ｂとを有する。複数の仮想マシン１０８Ａ，１０８Ｂは、ハードウェア１０２により実現されるＣＰＵリソースを共有している。リソース管理装置（リソース管理部２０）のゲスト優先度算出部２０２は、ホストＯＳ１０４からゲストＯＳ１１０へのパケット転送レート、ホストＯＳ１０４のカーネルバッファの空き状況の少なくともいずれかに基づいて、少なくとも１つのゲストＯＳ１１０の処理優先度を算出する。また、リソース利用制御部２０４は、算出された処理優先度に基づいて、複数のゲストＯＳ１１０によるＣＰＵリソースの利用時間配分を制御する。【選択図】図１

Description

本発明は、仮想化システムのリソース管理装置およびリソース管理方法に関する。

従来、システム内のリソース利用状態を適切に管理することによって、システムの処理効率を向上させる技術が提案されている。
例えば、下記特許文献１には、仮想環境下において帯域保証を実現するために、パケットの優先度に応じてホスト−ゲスト区間の帯域保証を行う技術が開示されている。
また、下記特許文献２には、リアルタイムＯＳ（Operating System）のタスクスケジューリングにおいて、優先度の高いタスクと優先度の低いタスクが合あった場合に、優先度の低いタスクにもＣＰＵリソースが割り当たるように、レディ状態にあるタスクからディスパッチする技術が開示されている。
また、下記特許文献３には、パケットの優先度に応じて、タスクスケジューリングの処理タスク割当ての優先度を設定し、優先度に応じてタスクの横取りを行う技術が開示されている。

特開２０１７−４１８５８号公報特開平８−２４９１９４号公報特開平９−４６３７３号公報

サーバ仮想化環境下において、複数の仮想マシンがＣＰＵリソースを共有して動作するために、ＣＦＳ（Completely Fare Scheduler）等のタスクスケジューラにより、複数のゲスト（例えば第１のゲストと第２のゲスト）がＣＰＵを使用できる時間を交互に切り替えて、ＣＰＵタイムを割り当てる技術が提案されている（例えば、Ｌｉｎｕｘ（登録商標）ｋｅｒｎｅｌ２．６．２３以降にはＣＦＳが搭載されている）。

このような構成では、一方のゲストがＣＰＵを使用している時間は、他方のゲストがＣＰＵを使用した処理を行えないため、ＣＰＵタイム待ちによるネットワーク遅延が発生する可能性がある。例えば、ホストが処理したパケットを第１のゲストが更に処理する場合、パケットの転送レートが高速（例えば１Ｇｂｐｓ以上等）であると、ホストが処理したパケットを第１のゲストに割り当てられたＣＰＵタイム内に処理しきれず、第１のゲストが保有するキューに処理待ちパケットが蓄積し、数百ｍｓ程度の大きな遅延が発生する場合がある。

図４は、ＣＰＵタイムとパケット処理の関係を模式的に示す説明図である。
図４では、縦軸方向に時間を取り、ホストが処理したパケットを第１のゲスト（Ｇｕｅｓｔ１）が更に処理する場合について、左側にホストにおけるパケット処理状況を、右側に第１のゲストにおけるパケット処理状況を、それぞれ模式的に示している。

ホストはＣＰＵを占有しているためパケット処理を継続的に行えるのに対して、ゲスト側では第１のゲストと第２のゲスト（Ｇｕｅｓｔ２）とによりＣＰＵを共有しているためパケット処理が断続的となる。
よって、第１のゲストは、ホストから到着するパケットの処理をＣＰＵタイム内に完了することができず、キューに貯め込んでいく。処理が進んでいくと、ホストから第１のゲストにパケットが到着してから処理を実行するまで複数ＣＰＵサイクル待つ必要があり、遅延が生じる。例えば、時刻Ｔ２の時点において第１のゲストで完了している処理は、ホストが時刻Ｔ１までに引き渡した処理までであり、時刻Ｔ２−Ｔ１間の処理は、第１のゲストのキューに蓄積されている。更に、パケットが第１のゲストの最大キューサイズまで貯まると、以降パケットロスが発生することになる。

このような課題に対応するため、例えば、パケット処理を行う第１のゲストのＣＰＵ使用優先度を高く設定し、第１のゲストに割り当てるＣＰＵタイムを拡大することで、パケット処理のネットワーク遅延を小さくする方法が考えられる。しかし、この方法では、第２のゲストのＣＰＵタイムが定常的に減少し、ＣＰＵの利用効率が低下するという課題がある。例えば、第１のゲストのｑｅｍｕ−ｋｖｍプロセスのｎｉｃｅ値＝−１０と設定すると、第２のゲストのＣＰＵタイムが減少することにより、第２のゲストへのＳＳＨ（Secure Shell）ログインすらできなくなる。

本発明は、このような事情に鑑みなされたものであり、複数のゲストが共有するＣＰＵリソースを効率的に利用し、システム全体の処理性能を向上させることを目的とする。

上述の目的を達成するため、請求項１に記載の発明は、ハードウェア上で動作するホストＯＳと、前記ホストＯＳ上に仮想的に構築された複数の仮想マシン上でそれぞれ動作する複数のゲストＯＳとを有する仮想化システムのリソースを管理するリソース管理装置であって、複数の前記仮想マシンが、前記ハードウェアにより実現されるＣＰＵリソースを共有しており、前記ホストＯＳから前記ゲストＯＳへのパケット転送レート、前記ホストＯＳのカーネルバッファの空き状況の少なくともいずれかに基づいて、少なくとも１つの前記ゲストＯＳの処理優先度を算出するゲスト優先度算出部と、前記ゲスト優先度算出部により算出された前記処理優先度に基づいて、複数の前記ゲストＯＳによる前記ＣＰＵリソースの利用時間配分を制御するリソース利用制御部と、を備えることを特徴とするリソース管理装置とした。

また、請求項４に記載の発明は、ハードウェア上で動作するホストＯＳと、前記ホストＯＳ上に仮想的に構築された複数の仮想マシン上でそれぞれ動作する複数のゲストＯＳとを有する仮想化システムのリソースを管理するリソース管理装置のリソース管理方法であって、複数の前記仮想マシンが、前記ハードウェアにより実現されるＣＰＵリソースを共有しており、前記リソース管理装置が、前記ホストＯＳから前記ゲストＯＳへのパケット転送レート、前記ホストＯＳのカーネルバッファの空き状況の少なくともいずれかに基づいて、少なくとも１つの前記ゲストＯＳの処理優先度を算出するゲスト優先度算出工程と、算出された前記処理優先度に基づいて、複数の前記ゲストＯＳによる前記ＣＰＵリソースの利用時間配分を制御するリソース利用制御工程と、を実行することを特徴とするリソース管理方法とした。

このようにすることで、リソース管理装置（リソース管理部）は、複数のゲストＯＳによるＣＰＵリソースの利用時間を動的に変更することができ、ＣＰＵの利用効率を向上させるとともに、ゲストＯＳにおける処理遅延に起因するサーバ内ネットワークの遅延を低減することができる。

また、請求項２に記載の発明は、前記ゲスト優先度算出部が、前記パケット転送レートが高いほど、または、前記カーネルバッファの空きが少ないほど、前記ゲストＯＳの処理優先度を高くする、ことを特徴とする請求項１に記載のリソース管理装置とした。

また、請求項５に記載の発明は、前記ゲスト優先度算出工程では、前記パケット転送レートが高いほど、または、前記カーネルバッファの空きが少ないほど、前記ゲストＯＳの処理優先度を高くする、ことを特徴とする請求項４に記載のリソース管理方法とした。

このようにすることで、ゲストＯＳにおけるパケット処理負荷を精度よく反映することができる。

また、請求項３に記載の発明は、前記ゲスト優先度算出部が、複数の前記ゲストＯＳのうち、リアルタイム性が求められるネットワーク処理を要するアプリケーションを実行するゲストＯＳを前記処理優先度の算出対象とする、ことを特徴とする請求項１または請求項２に記載のリソース管理装置とした。

また、請求項６に記載の発明は、前記ゲスト優先度算出工程では、複数の前記ゲストＯＳのうち、リアルタイム性が求められるネットワーク処理を要するアプリケーションを実行するゲストＯＳを前記処理優先度の算出対象とする、ことを特徴とする請求項４または請求項５に記載のリソース管理方法とした。

このようにすることで、処理負荷が変動しやすいゲストＯＳの状態に合わせてＣＰＵリソースを配分することができ、ＣＰＵの利用効率を向上させることができる。

本発明によれば、複数のゲストが共有するＣＰＵリソースを効率的に利用し、システム全体の処理性能を向上させることができる。

実施の形態にかかるサーバの構成を示す図である。リソース利用制御部によるＣＰＵリソースの利用時間配分を模式的に示す説明図である。リソース管理部による処理の手順を示すフローチャートである。ＣＰＵタイムとパケット処理の関係を模式的に示す説明図である。

以下に添付図面を参照して、本発明にかかるリソース管理装置およびリソース管理方法の好適な実施の形態を詳細に説明する。本実施の形態では、複数の仮想マシン（ゲスト）が構成されたサーバに本発明にかかるリソース管理装置およびリソース管理方法を適用した場合について説明する。

図１は、実施の形態にかかるサーバ１０の構成を示す図である。
サーバ１０は、ハードウェア（ＨＷ）１０２、ホスト（Ｈｏｓｔ）ＯＳ１０４、ハイパーバイザ（Ｈｙｐｅｒｖｉｓｏｒ）１０６、第１の仮想マシン（ＶＭ１）１０８Ａ、第１のゲストＯＳ（Ｇｕｅｓｔ１）１１０Ａ、第２の仮想マシン（ＶＭ２）１０８Ｂ、第２のゲストＯＳ（Ｇｕｅｓｔ２）１１０Ｂ、アプリケーション１１２Ａ，１１２Ｂを備える。

ハードウェア１０２は、例えばＩＡ（Intel Architecture）サーバ（「Intel」は登録商標）であり、ＣＰＵ１０２２やネットワークインターフェースカード（ＮＩＣ）１０２４等を備え、サーバ１０を物理的に構成する。
ホストＯＳ１０４は、ハードウェア１０２の機能を上位レイヤに提供する。
ハイパーバイザ１０６は、ホストＯＳ１０４の上で仮想化環境を提供し、本実施の形態では、例として、第１の仮想マシン１０８Ａおよび第２の仮想マシン１０８Ｂを構築する。

第１の仮想マシン１０８Ａ、第２の仮想マシン１０８Ｂは、それぞれ仮想ＣＰＵ（ｖＣＰＵ）１０８２Ａ，１０８２Ｂや仮想ネットワークインターフェースカード（ｖＮＩＣ）１０８４Ａ，１０８４Ｂを有するが、実際には物理的なハードウェア１０２であるＣＰＵ１０２２やネットワークインターフェースカード１０２４がその機能を実現する。

第１のゲストＯＳ１１０Ａ、第２のゲストＯＳ１１０Ｂは、それぞれ第１の仮想マシン１０８Ａ、第２の仮想マシン１０８Ｂ上で動作する。以下、第１のゲストＯＳ１１０Ａと第２のゲストＯＳ１１０Ｂとの両方を指す場合には、ゲストＯＳ１１０と称する。
アプリケーション１１２Ａ、１１２Ｂは、それぞれ第１のゲストＯＳ１１０Ａ、第２のゲストＯＳ１１０Ｂ上で動作する。
すなわち、サーバ１０は、ハードウェア１０２上で動作するホストＯＳ１０４と、ホストＯＳ１０４上に仮想的に構築された複数の仮想マシン１０８Ａ，１０８Ｂ上でそれぞれ動作する複数のゲストＯＳ１１０Ａ，１１０Ｂとを有する仮想化システムである。

本実施の形態では、第１のゲストＯＳ１１０Ａはリアルタイム性の高い（リアルタイム性が求められる）ネットワーク処理を要するアプリケーション１１２Ａを実行し、第２のゲストＯＳ１１０ＢはＣＰＵ処理を要する非リアルタイム処理を行うアプリケーション１１２Ｂを実行するものとする。
より詳細には、第１のゲストＯＳ１１０Ａは、サーバ１０の外部にあるパケット送信装置３０から送信されたパケットをゲストパケット処理部１１０２Ａで処理する。パケット送信装置３０から送信されたパケットは、まずネットワークインターフェースカード１０２４で受信され、ホストＯＳ１０４のホストパケット処理部１０４２を介してゲストパケット処理部１１０２Ａへと引き渡される。

ゲストパケット処理部１１０２Ａは、仮想的には仮想ＣＰＵ１０８２Ａによりパケット処理を行うが、実体的にはＣＰＵ１０２２により処理が行われる。同様に、仮想ＣＰＵ１０８２Ｂについても、実体的にはＣＰＵ１０２２が処理を行う。すなわち、複数の仮想マシン１０８Ａ，１０８Ｂは、ハードウェア１０２により実現されるＣＰＵ１０２２のリソースを共有している。

例えば、第１のゲストＯＳ１１０Ａ（仮想ＣＰＵ１０８２Ａ）がＣＰＵ１０２２を使用する時間と、第２のゲストＯＳ１１０Ｂ（仮想ＣＰＵ１０８２Ｂ）がＣＰＵ１０２２を使用する時間とが固定されていると、例えば一方のゲストＯＳ１１０の処理負荷が増大した場合（一時的にパケット送信装置３０から送信されるパケットが増大した場合など）に処理に遅延が生じる。
そこで、ホストＯＳ１０４にＣＰＵ１０２２のリソースを管理するリソース管理部２０（リソース管理装置）を設け、ＣＰＵ１０２２の利用効率を向上させ、各ゲストＯＳ１１０における処理の遅延を抑制している。

リソース管理部２０は、ゲスト優先度算出部２０２とリソース利用制御部２０４とを備える。
ゲスト優先度算出部２０２は、ホストＯＳ１０４からゲストＯＳ１１０へのパケット転送レートと、ホストＯＳ１０４のカーネルバッファの空き状況の少なくともいずれかに基づいて、複数のゲストＯＳ１１０Ａ，１１０Ｂのうち少なくとも１つのゲストＯＳ１１０（以下「監視対象ゲストＯＳ」という）の処理優先度を算出する。
本実施の形態では、リソース管理部２０は、パケット転送レート計測部２０６およびバッファ空き状況監視部２０８を備えており、パケット転送レートおよびカーネルバッファの空き状況の両方を測定し、これに基づいてゲスト優先度算出部２０２は監視対象ゲストＯＳの処理優先度を算出する。なお、パケット転送レートと、カーネルバッファの空き状況のいずれか一方のみを用いて処理優先度を算出してもよい。

パケット転送レート計測部２０６は、例えば各ゲストＯＳ１１０Ａ，１１０Ｂへのフローごとにパケット転送レートを識別できる場合には、各ゲストＯＳ１１０Ａ，１１０Ｂ単位でパケット転送レートを監視する。例えば、仮想デバイスであるｖｈｏｓｔ−ｎｅｔは、仮想マシン１０８（１０８Ａ，１０８Ｂ）単位で生成されるので、このｖｈｏｓｔ−ｎｅｔにおけるパケット転送レートを監視すれば、各ゲストＯＳ１１０Ａ，１１０Ｂ単位でパケット転送レートを監視することができる。
一方で、環境に依っては、各ゲストＯＳ１１０Ａ，１１０Ｂ単位でパケット転送レートを取得できない可能性がある。この場合は、例えば／ｐｒｏｃ／ｎｅｔ／ｄｅｖといった、ホストＯＳ１０４が持つネットワークデバイスのパケット転送レートを取得する等の対応が考えられる。なお、このように各ゲストＯＳ１１０Ａ，１１０Ｂへのフロー単位にパケット転送量を分計できない場合には、後述するように２つのゲストＯＳ１１０Ａ，１１０Ｂの両方を監視対象ゲストＯＳにしても効果が低い場合もあると考えられる。

バッファ空き状況監視部２０８としては、例えばホストＯＳ１０４のカーネルに備えられたカーネルバッファの空き状況を監視する機能を利用することができる。このような機能を利用すれば、リアルタイムにバッファ空き状況を検知することができ、例えばバッファの空きサイズが枯渇してきた際に迅速に対応することができる。
バッファ空き状況監視部２０８の監視対象として、例えば前述したｖｈｏｓｔ−ｎｅｔのカーネルバッファを監視する場合は、各ゲストＯＳ１１０Ａ，１１０Ｂ単位のフローでバッファ空き状況を識別可能となる。一方、ホストＯＳ１０４配下のネットワークドライバが管理するリングバッファを監視する場合は、各ゲストＯＳ１１０Ａ，１１０Ｂ単位でのフローのバッファ空き状況を分計することはできない。

ゲスト優先度算出部２０２は、ゲストＯＳ１１０（特に監視対象ゲストＯＳ）へのパケット転送レートが高いほど、またはカーネルバッファの空きが少ないほど、監視対象ゲストＯＳの処理優先度を高くする。
すなわち、監視対象ゲストＯＳへのパケット転送レートが高い場合には、ホストＯＳ１０４から監視対象ゲストＯＳに引き渡されるパケット量が増大しており、監視対象ゲストＯＳでの処理負荷が増加していると考えられる。また、カーネルバッファの空きが少ない場合にも、ホストＯＳ１０４から監視対象ゲストＯＳに引き渡されるパケット量が増大し、監視対象ゲストＯＳでの処理負荷が増加すると予想される。
このため、ゲスト優先度算出部２０２は、パケット転送レートの上昇やカーネルバッファの空きの減少があった場合には、監視対象ゲストＯＳの処理優先度を相対的に高くする。また、反対にパケット転送レートの低下やカーネルバッファの空きの増加があった場合には、監視対象ゲストＯＳの処理優先度を相対的に低くする。
なお、パケット転送レートやカーネルバッファの空き容量の値と、処理優先度との関係を、機械学習を用いて動的に算出してもよい。

リソース利用制御部２０４は、ゲスト優先度算出部２０２により算出された処理優先度に基づいて、複数のゲストＯＳ１１０Ａ，１１０ＢによるＣＰＵリソースの利用時間配分を制御する。

図２は、リソース利用制御部２０４によるＣＰＵリソースの利用時間配分を模式的に示す説明図である。
図２の中央は、所定の基準状態（例えば第１のゲストＯＳ１１０Ａの処理優先度が所定の閾値１を超え、かつ所定の閾値２（＞閾値１）未満である場合）における利用時間配分を示す。基準状態では、例えば第１のゲストＯＳ１１０Ａ（Ｇｕｅｓｔ１）と第２のゲストＯＳ１１０Ｂ（Ｇｕｅｓｔ２）が同時間（ｔ１）ずつ交互にＣＰＵ１０２２を利用する。

図２の右側は、第１のゲストＯＳ１１０Ａの処理優先度が高くなった場合（例えば上記閾値２以上である場合）における利用時間配分を示す。この場合には、第１のゲストＯＳ１１０ＡのＣＰＵ１０２２の利用時間を、第２のゲストＯＳ１１０Ｂと比較して長くする。具体的には、例えば基準状態よりも第１のゲストＯＳ１１０ＡのＣＰＵ１０２２の利用時間を長く（図示の例ではｔ２（＞ｔ１））、第２のゲストＯＳ１１０ＢのＣＰＵ１０２２の利用時間を短くする（図示の例ではｔ３（＜ｔ１））。時間ｔ２は、第１のゲストＯＳ１１０Ａの処理優先度の大きさに比例して長く（または時間ｔ３を短く）してもよい。

図２の左側は、第１のゲストＯＳ１１０Ａの処理優先度が低くなった場合（例えば上記閾値１以下である場合）における利用時間配分を示す。この場合には、第１のゲストＯＳ１１０ＡのＣＰＵ１０２２の利用時間を、第２のゲストＯＳ１１０Ｂと比較して短くする。具体的には、例えば基準状態よりも第１のゲストＯＳ１１０ＡのＣＰＵ１０２２の利用時間を短く（図示の例ではｔ４（＜ｔ１））、第２のゲストＯＳ１１０ＢのＣＰＵ１０２２の利用時間を長くする（図示の例ではｔ５（＞ｔ１））。時間ｔ4は、第１のゲストＯＳ１１０Ａの処理優先度の大きさに比例して短く（または時間ｔ５を長く）してもよい。

このように、第１のゲストＯＳ１１０Ａの処理優先度、すなわちパケットの緩急に応じて、各ゲストＯＳ１１０のＣＰＵ１０２２の利用時間を動的に設定することにより、一方のゲストＯＳ１１０の優先度を固定する場合と比較してＣＰＵ１０２２の利用効率を向上させることができる。

なお、本実施の形態では、ゲスト優先度算出部２０２は、複数のゲストＯＳ１１０のうち、リアルタイム性の高いネットワーク処理を要するアプリケーションを実行するゲストＯＳ、すなわち第１のゲストＯＳ１１０Ａを処理優先度の算出対象（監視対象ゲストＯＳ）とし、リソース利用制御部２０４は、第１のゲストＯＳ１１０Ａを処理優先度に基づいて、ＣＰＵリソースの利用時間配分を制御する。
これにより、処理遅延の影響が大きいリアルタイム性の高い処理を行うのに最適化した形でＣＰＵ１０２２の利用時間を配分することができる。
なお、第１のゲストＯＳ１１０Ａと第２のゲストＯＳ１１０Ｂの両方を監視対象ゲストＯＳとすることも可能である。しかしながら、上述のようにパケット転送レートや、カーネルバッファの空き状況について、ゲストＯＳ１１０Ａ，１１０Ｂ別に測定できない場合には、本実施の形態で例示すケースと異なり、例えば、第１のゲストＯＳ１１０Ａと第２のゲストＯＳ１１０Ｂがともにリアル性の高いネットワーク処理を要するアプリケーション１１２Ａ，１１２Ｂを実行しているとすると、ＣＰＵリソースの利用効率を向上させる効果が低くなると考えられる。
また、第２のゲストＯＳ１１０Ｂのみを監視対象ゲストＯＳとしてもよい。

図３は、リソース管理部２０による処理の手順を示すフローチャートである。
パケット転送レート計測部２０６は、ホストＯＳ１０４からゲストＯＳ１１０へのパケットの転送レートを計測（例：ｘｘＭｂｐｓ等）し、その値をメモリ等に一時記録する（ステップＳ３００）。
バッファ空き状況監視部２０８は、ホストＯＳ１０４のカーネルバッファの空き状況を取得し、その値をメモリ等に一時記録する（ステップＳ３０２）。

ゲスト優先度算出部２０２は、ステップＳ３００で測定したパケットの転送レートに基づく第１のゲストＯＳ１１０Ａの処理優先度と（ステップＳ３０４）、ステップＳ３０２で取得したカーネルバッファの空き状況に基づく第１のゲストＯＳ１１０Ａの処理優先度とを算出する（ステップＳ３０６）。
ゲスト優先度算出部２０２は、ステップＳ３０４およびステップＳ３０６で算出した処理優先度から、採用する処理優先度を決定する（ステップＳ３０８）。具体的には、例えば２つの処理優先度のうち高い方を採用する。
そして、リソース利用制御部２０４は、採用した処理優先度に基づいて、各仮想マシン１０８Ａ，１０８Ｂの仮想ＣＰＵ（ｖＣＰＵ）１０８２Ａ，１０８２Ｂに対して、ＣＰＵ１０２２の利用時間を設定する（ステップＳ３１０）。
リソース管理部２０は、上記の処理の手順を、所定の時間間隔で繰り返すことにより、複数のゲストＯＳ１１０によるＣＰＵリソースの利用時間を動的に変更することができる。

以上説明したように、実施の形態にかかるサーバ１０によれば、複数のゲストＯＳによるＣＰＵリソースの利用時間を動的に変更することができ、ＣＰＵの利用効率を向上させるとともに、ゲストＯＳにおける処理遅延に起因するサーバ内ネットワークの遅延を低減することができる。

１０サーバ
１０２ハードウェア
１０２２ＣＰＵ
１０４ホストＯＳ
１０４２ホストパケット処理部
１０６ハイパーバイザ
１０８（１０８Ａ，１０８Ｂ）仮想マシン
１０８２（１０８２Ａ，１０８２Ｂ）仮想ＣＰＵ
１１０（１１０Ａ，１１０Ｂ）ゲストＯＳ
１１０２Ａゲストパケット処理部
１１２（１１２Ａ，１１２Ｂ）アプリケーション
２０リソース管理部（リソース管理装置）
２０２ゲスト優先度算出部
２０４リソース利用制御部
２０６パケット転送レート計測部
２０８バッファ空き状況監視部
３０パケット送信装置

Claims

ハードウェア上で動作するホストＯＳと、前記ホストＯＳ上に仮想的に構築された複数の仮想マシン上でそれぞれ動作する複数のゲストＯＳとを有する仮想化システムのリソースを管理するリソース管理装置であって、
複数の前記仮想マシンは、前記ハードウェアにより実現されるＣＰＵリソースを共有しており、
前記ホストＯＳから前記ゲストＯＳへのパケット転送レート、前記ホストＯＳのカーネルバッファの空き状況の少なくともいずれかに基づいて、少なくとも１つの前記ゲストＯＳの処理優先度を算出するゲスト優先度算出部と、
前記ゲスト優先度算出部により算出された前記処理優先度に基づいて、複数の前記ゲストＯＳによる前記ＣＰＵリソースの利用時間配分を制御するリソース利用制御部と、
を備えることを特徴とするリソース管理装置。
前記ゲスト優先度算出部は、前記パケット転送レートが高いほど、または、前記カーネルバッファの空きが少ないほど、前記ゲストＯＳの処理優先度を高くする、
ことを特徴とする請求項１に記載のリソース管理装置。
前記ゲスト優先度算出部は、複数の前記ゲストＯＳのうち、リアルタイム性が求められるネットワーク処理を要するアプリケーションを実行するゲストＯＳを前記処理優先度の算出対象とする、
ことを特徴とする請求項１または請求項２に記載のリソース管理装置。
ハードウェア上で動作するホストＯＳと、前記ホストＯＳ上に仮想的に構築された複数の仮想マシン上でそれぞれ動作する複数のゲストＯＳとを有する仮想化システムのリソースを管理するリソース管理装置のリソース管理方法であって、
複数の前記仮想マシンは、前記ハードウェアにより実現されるＣＰＵリソースを共有しており、
前記リソース管理装置は、
前記ホストＯＳから前記ゲストＯＳへのパケット転送レート、前記ホストＯＳのカーネルバッファの空き状況の少なくともいずれかに基づいて、少なくとも１つの前記ゲストＯＳの処理優先度を算出するゲスト優先度算出工程と、
算出された前記処理優先度に基づいて、複数の前記ゲストＯＳによる前記ＣＰＵリソースの利用時間配分を制御するリソース利用制御工程と、
を実行することを特徴とするリソース管理方法。
前記ゲスト優先度算出工程では、前記パケット転送レートが高いほど、または、前記カーネルバッファの空きが少ないほど、前記ゲストＯＳの処理優先度を高くする、
ことを特徴とする請求項４に記載のリソース管理方法。
前記ゲスト優先度算出工程では、複数の前記ゲストＯＳのうち、リアルタイム性が求められるネットワーク処理を要するアプリケーションを実行するゲストＯＳを前記処理優先度の算出対象とする、
ことを特徴とする請求項４または請求項５に記載のリソース管理方法。