JP6180866B2 - スケジューリング装置、システム、装置、方法およびプログラム - Google Patents

Description

本発明の実施形態は、スケジューリング装置、システム、装置、方法およびプログラムに関する。

従来、１つの装置上で複数のＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）を実行可能とする仮想化技術が知られている。仮想化技術は、たとえば、それぞれの仮想マシンに必要なＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）リソースを自動的に調整する。また、ＣＰＵリソースが仮想マシンに足りないと判断された場合にはフィードバック制御にてＣＰＵリソースを増す技術も存在する。

しかしながら、従来の仮想化技術を用いても、十分なＣＰＵリソースを仮想マシンに提供できない期間が存在してしまう場合がある。

米国特許第８１６６４８５号明細書

J. Lee, S. Xi, S. Chen, L. T.X. Phan, C. Gill, I. Lee, C. Lu, and O. Sokolsky, "Realizing Compositional Scheduling through Virtualization", 2012 IEEE 18th Raal Time and Embedded Technology and applications Symposium, Beijing, China, April 16-19, 2012

以下の実施形態では、十分でかつ可能な限り少ないＣＰＵリソースやネットワークリソースを仮想マシンに割り当てることが可能なスケジューリング装置、システム、装置、方法およびプログラムを提供することを目的とする。

実施形態にかかるスケジューリング装置は、仮想ＯＳ上で動作する１つ以上のタスクであってそれぞれ予め決められた周期的なデッドラインまでに１回分の処理を完了する必要がある前記１つ以上のタスクが必要とする第１リソース量を取得する負荷計算部と、前記第１リソース量に基づいて前記仮想ＯＳに割り当てる第２リソース量を計算するリソース計算部と、を備え、前記負荷計算部は、各タスクが必要とする最小限の第３リソース量に、各タスクの実行周期または１周期あたりの実行時間に基づく余裕を付加することで、前記第１リソース量を計算する。

図１は、実施形態１にかかる情報処理システムの概略構成例を示すブロック図。 図２は、実施形態１〜におけるタスクの実行周期の例を示す図。 図３は、実施形態１〜３における実行履歴の第１例を示す図。 図４は、実施形態１〜３における実行履歴の第２例を示す図。 図５は、実施形態１〜３におけるリソース量の例を示す図。 図６は、実施形態１の動作例を示すシーケンス図。 図７は、実施形態１および２においてオーケストレータが仮想ＯＳに割当てるリソース量を計算する方法の例を示すフローチャート図。 図８は、実施形態１および２においてオーケストレータがタスクに対して最小のリソース量を計算する方法の例を示すフローチャート図。 図９は、実施形態２の動作例を示すシーケンス図。 図１０は、実施形態３にかかる情報処理システムの概略構成例を示すブロック図。 図１１は、実施形態３の動作例を示すシーケンス図。

以下、添付図面を参照しながら、例示する実施形態にかかるスケジューリング装置、システム、装置、方法およびプログラムを詳細に説明する。

（実施形態１）
まず、実施形態１にかかるスケジューリング装置、システム、装置、方法およびプログラムを、図面を参照して詳細に説明する。図１は、実施形態１にかかる情報処理システムの構成例を示す。図１に示すように、情報処理システム１は、１台以上のサーバ１００Ａ〜１００Ｃと、スケジューリング装置１１０と、ストレージシステム１２０と、端末１３０とがネットワーク１４０を介して相互に接続された構成を有する。以下では、スケジューリング装置１１０をオーケストレータ１１０と記す場合もある。また、サーバ１００Ａ〜１００Ｃを個別に区別しない場合、その符号を１００と記す。

端末１３０は、管理者が操作する計算機である。管理者は、端末１３０を用いて、オーケストレータ１１０へ、仮想マシンの起動、テストまたは停止などの指示を入力する。端末１３０に入力された指示は、ネットワーク１４０を介してオーケストレータ１１０へ送信される。

オーケストレータ１１０は、仮想ＯＳ制御装置であり、サーバ１００上で動作する仮想ＯＳ等を制御する。たとえば、オーケストレータ１１０は、端末１３０から受信したメッセージに従い、仮想ＯＳの起動、テスト、停止などのコマンドを含むメッセージを作成する。作成されたメッセージは、ネットワーク１４０を介してサーバ１００へ送信される。

また、オーケストレータ１１０は、必要に応じて仮想ＯＳをサーバ１００（以下、移動元サーバという）から別のサーバ１００（以下、移動先サーバという）へ移動するコマンドを記したメッセージを作成し、そのメッセージをサーバ１００へ送信する。また、オーケストレータ１１０は、各サーバ１００から仮想ＯＳ上で実行されるタスクの実行周期を取得する。

各サーバ１００は、１つ以上のＣＰＵコア（演算装置）１０１、ハイパーバイザ１０２、０以上の仮想ＯＳ１０３Ａ〜１０３Ｂ、０以上のタスク１０４Ａ〜１０４Ｃで構成される。以下では、仮想ＯＳ１０３Ａ〜１０３Ｂを個別に区別しない場合、その符号を１０３と記す。また、タスク１０４Ａ〜１０４Ｃを個別に区別しない場合、その符号を１０４と記す。１つの仮想ＯＳ１０３上では、０以上のタスク１０４が実行される。図１の例では、タスク１０４Ａが仮想ＯＳ１０３Ａ上で実行され、タスク１０４Ｂおよびタスク１０４Ｃが仮想ＯＳ１０３Ｂ上で実行される。

仮想ＯＳ１０３は、たとえばサーバ１００がネットワーク１４０を介してストレージシステム１２０から仮想ＯＳ１０３のイメージファイルを取得して起動することで実行される。ハイパーバイザ１０２は、仮想ＯＳ１０３をスケジューリングし、計算機をエミュレートするソフトウェアまたは回路である。仮想ＯＳ１０３は、ＣＰＵコア１０１上で実行されるオペレーティングシステムである。タスク１０４は、周期的に処理を実行するソフトウェアである。

オーケストレータ１１０は、コントローラ１１１、リソース計算部１１２、負荷計算部１１３、記憶部１１４で構成される。

負荷計算部１１３は、サーバ１００から取得した仮想ＯＳ１０３および／またはタスク１０４の実行履歴から、仮想ＯＳ１０３上で実行される各タスク１０４に必要なリソースの量を計算する。

リソース計算部１１２は、各タスク１０４の実行に必要なリソースを用いて、仮想ＯＳ１０３に対する必要最小限のリソース量を計算する。

コントローラ１１１は、端末１３０から受信したメッセージに従い、仮想ＯＳ１０３の起動、テスト、停止などのコマンドを含むメッセージを作成し、作成したメッセージをサーバ１００へ送信する。また、コントローラ１１１は、必要に応じて仮想ＯＳ１０３を移動元サーバ１００から移動先サーバ１００へ移動するコマンドを記したメッセージを作成し、作成したメッセージを移動元サーバ１００へ送信する。さらに、コントローラ１１１は、仮想ＯＳ１０３に割り当てるリソース量を記したメッセージを作成し、作成したメッセージをサーバ１００へ送信する。仮想ＯＳ１０３に割り当てるリソース量は、仮想ＯＳ１０３の起動または移動を指示するメッセージに記されてもよい。

記憶部１１４は、タスクの実行履歴、および、仮想ＯＳに割り当てたリソース量を記憶する。

また、オーケストレータ１１０は、サーバ１００に対して仮想ＯＳ１０３のテストを指示し、そのテスト結果をサーバ１００から取得する。テスト結果には、たとえば仮想ＯＳ１０３上で実行された１以上のタスク１０４の実行履歴が含まれる。

ここで、図２に、タスクの実行周期の一例を示す。図２に示すように、タスク１０４は、予め決められた周期的なデッドラインＤＬまでに１回分の処理を完了する必要がある。デッドラインＤＬは、一定の間隔で設定され、その間隔がタスクの実行周期Ｃである。また、１つの実行周期Ｃ中にタスク１０４が実行される期間が、タスクの実行期間Ｐである。なお、タスク１０４は、１回の処理が完了するまで連続して実行される必要はなく、複数の期間に分割されて実行されてもよい。たとえば図２の実行周期Ｃ１に示すように、２つの期間Ｐ１およびＰ２に分割されて実行されてもよい。

図３は、ＣＰＵコア１０１のひとつがタスクＡとタスクＢとを実行したときの実行履歴の一例を示す。タスクの実行履歴は、ＣＰＵコア１０１があるタスクＡおよびタスクＢを実行した期間で表される。

図３に示すタスクＡおよびＢの実行履歴は、それぞれ１以上の実行期間を含む。ただし、図３は、ＣＰＵコア１０１がタスクＡとタスクＢとを切り替えながら実行した例を示す。そのため、図３は、それぞれのタスクＡおよびＢの実行期間が断続的である例を示す。

タスクの実行期間Ｐは、開始時刻と終了時刻とで表される。開始時刻は、ＣＰＵコア１０１がタスクＡまたはＢの実行を開始または再開した時刻である。終了時刻は、ＣＰＵコア１０１がタスクＡまたはＢの実行を終了または中断した時刻である。

これらの開始時刻と終了時刻は、たとえばＵｎｉｘ（登録商標） Ｅｐｏｃｈからの経過時間で表される。たとえば図３において、タスクＡの最初の開始時刻は、Ｕｎｉｘ（登録商標） Ｅｐｏｃｈから１３６５５５７００４．３１３２２１２４２秒経過した時点である。

なお、開始時刻と終了時刻とは、経過時間に限らず、どのような形式で表されてもよい。たとえば、任意のタイムゾーンにおける時刻で表されてもよいし、ＵＴＣ（協定世界時）、ＴＡＩ（国際原子時）、ＧＭＴ（グリニッジ平均時）などで表されてもよい。また、開始時刻と終了時刻は、不図示のタイマを起動またはリセットしたタイミングからの経過時間で表されてもよい。また、開始時刻および終了時刻の単位は、秒に限らず、秒より短い単位であってもよい。さらに、終了時刻の代わりに、開始時刻から終了時点までの時間が用いられてもよい。

実行履歴は、図３に示すように、タスクごとに管理されていなくてもよい。たとえば、図４に示すように、タスクＡとタスクＢとの実行期間を一意に識別するための識別子（以下、タスクＩＤという）とともに列挙する形式で、実行履歴が管理されてもよい。なお、実行履歴には、１つのタスクに対して１以上のデッドラインＤＬの時刻が含まれる。

オーケストレータ１１０は、以上のような実行履歴を用いて仮想ＯＳ１０３に割り当てるリソースを計算する。また、オーケストレータ１１０は、計算したリソースの量を記したメッセージをサーバ１００へ送信する。

サーバ１００は、１以上の仮想ＯＳ１０３を実行する計算機である。サーバ１００は、オーケストレータ１１０から受信したメッセージに従い、仮想ＯＳ１０３を起動、テストおよび停止する。また、サーバ１００は、オーケストレータ１１０から受信したメッセージに従い、仮想ＯＳ１０３に割り当てるリソースを調節する。

次に、図５を用いてリソースの定義を説明する。本説明において、リソースは、たとえばＣＰＵリソースまたはネットワークリソースである。ただし、これらに限定されるものではなく、多数の仮想ＯＳまたはタスクが時分割で利用するリソースであればどのようなリソースであってもよい。実行周期はリソースを使用する周期に一般化され、実行期間はリソースを使用する期間に一般化される。

リソースは、タスクまたは仮想ＯＳに割り当てられる。リソースは、割り当て周期Πと、１周期あたりの割当て時間Θとの組（Π，Θ）で定義される。つまり、リソース（Π，Θ）が与えられたタスクは、割当て周期Π毎に合計Θの期間リソースを使用可能である。リソースは実行周期および実行期間の総時間の組に似ているが、異なる概念である。タスクは与えられた全てのリソースを必ずしも消費する必要がない。そのため、リソース（Π，Θ）が割り当てられたタスクの実行周期はΠでなくてもよく、実行期間の総時間はΘでなくてもよい。仮想ＯＳに割り当てるリソースの定義もタスクに割り当てるリソースと同様である。リソース（Π，Θ）が仮想ＯＳに割り当てられると、仮想ＯＳは周期Π毎にΘの時間、いずれかのタスクにＣＰＵコアを使用させることができる。なお、割当て周期Πおよび割当て時間Θの単位は、例えば仮想ＯＳ１０３に割り当てることができる最短の時間で定義される。

図５は、図１に示す仮想ＯＳ１０３に割り当てられたＣＰＵリソースの割当て周期Ｃｒと割当て時間Ｔｒとがそれぞれ１００ｍｓと５０ｍｓとである場合の例を示す。その場合、仮想ＯＳ１０３は、１００ｍｓごとに５０ｍｓの時間、ＣＰＵコア１０１を使用することができる。ＣＰＵコア１０１が仮想ＯＳ１０３上のタスク１０４を実行する期間は、必ず仮想ＯＳ１０３にＣＰＵコア１０１が割り当てられた期間に含まれる。

なお、仮想ＯＳ１０３に割り当てられるリソースの割当て時間Ｔｒは、連続である必要はない。たとえば、図５に示す例では、期間Ｃｒ１における割当て時間が第１割当て時間Ｔｒ１と第２割当て時間Ｔｒ２とに分断されている。その場合、第１割当て時間Ｔｒ１と第２割当て時間Ｔｒ２とを足したトータルの時間が割当て時間Ｔｒ（５０ｍｓ）であればよい。また、期間Ｃｒ１における仮想ＯＳ１０３の実行時間は、第１割当て時間Ｔｒ１内に実行された実行時間Ｐｒ１と、第２割当て時間Ｔｒ２内に実行された実行時間Ｐｒ２とを足した時間となる。この時間（Ｐｒ１＋Ｐｒ２）は、仮想ＯＳ１０３を連続して実行した場合の実行時間Ｐｒと実質的に等しい。

次に、実施形態１にかかる情報処理システム１の動作を、図面を用いて詳細に説明する。図６は、実施形態１にかかる情報処理システムの動作例を示すシーケンス図である。なお、図６では、管理者が仮想ＯＳ１０３Ｂのイメージファイルを作成し、サーバ１００において仮想ＯＳ１０３Ｂを起動する場合を例示する。

図６に示すように、まず、管理者が端末１３０へ仮想ＯＳ１０３Ｂの作成指示を入力すると、端末１３０は、仮想ＯＳ１０３Ｂを作成する指示が記されたメッセージＭ１をオーケストレータ１１０へ送信する（ステップＳ１）。メッセージＭ１には、少なくとも仮想ＯＳ１０３Ｂのイメージファイルを識別するための識別子が含まれる。

次に、オーケストレータ１１０のコントローラ１１１は、メッセージＭ１に含まれる識別子に対応するイメージファイルＩＦ１をストレージシステム１２０から取得する（ステップＳ２）。また、コントローラ１１１は、ストレージシステム１２０にイメージファイルＩＦ１のコピー１Ｆ２を保存する（ステップＳ３）。そして、オーケストレータ１１０は、仮想ＯＳ１０３Ｂの作成完了を示すメッセージＭ２を端末１３０へ通知する（ステップＳ４）。

次に、オーケストレータ１１０は、イメージファイルＩＦ２に含まれる仮想ＯＳ１０３Ｂをテストモードで起動するコマンドを記したメッセージＭ３をサーバ１００へ送信する（ステップＳ５）。このメッセージＭ３には、仮想ＯＳ１０３ＢのイメージファイルＩＦ２を特定するための識別子も含まれる。

次に、サーバ１００は、受信したメッセージＭ３に基づいてイメージファイルＩＦ２に含まれる仮想ＯＳ１０３Ｂを起動し（ステップＳ６）、その後、仮想ＯＳ１０３Ｂの起動が完了すると、起動完了を示すメッセージＭ４をオーケストレータ１１０へ送信する（ステップＳ７）。

具体的には、ステップＳ６において、サーバ１００のハイパーバイザ１０２は、受信したメッセージＭ３に含まれる識別子を用いてストレージシステム１２０から仮想ＯＳ１０３Ｂを含むイメージファイルＩＦ２を取得する。次に、ハイパーバイザ１０２は、１以上のＣＰＵコア１０１から１つのＣＰＵコア１０１を選択し、このＣＰＵコア１０１の１００％のＣＰＵリソースを仮想ＯＳ１０３Ｂに割り当てる。つまり、ステップＳ６において、仮想ＯＳ１０３Ｂに割り当てられるＣＰＵリソースの割当て周期と１周期当たりの割当て時間とは同一である。そして、選択されたＣＰＵコア１０１は仮想ＯＳ１０３Ｂと仮想ＯＳ１０３Ｂ上のタスク１０４とを実行する。このように仮想ＯＳ１０３Ｂのテストモードでの起動が完了すると、サーバ１００は、ステップＳ７において、起動完了を示すメッセージＭ４をオーケストレータ１１０へ送信する。

次に、オーケストレータ１１０は、サーバ１００へ実行履歴の要求を示すメッセージＭ５を送信する（ステップＳ８）。これに対し、サーバ１００は、仮想ＯＳ１０３Ｂ上の全タスク１０４の実行履歴をあらかじめ決められた時間分計測して記録し（ステップＳ９）、記録した実行履歴を記したメッセージＭ６をオーケストレータ１１０へ送信する（ステップＳ１０）。なお、ステップＳ１０におけるサーバ１００からオーケストレータ１１０への実行履歴の通知方法は、種々変更可能である。たとえば、タスク１０４Ｂとタスク１０４Ｃからハイパーバイザ１０２へ開始時刻と終了時刻とを渡すＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ）を仮想ＯＳ１０３Ｂがタスク１０４Ｂとタスク１０４Ｃへ提供してもよい。この場合、タスク１０４Ｂおよびタスク１０４Ｃが開始時刻および終了時刻を記録し、ハイパーバイザ１０２へＡＰＩを通じて渡す。そしてハイパーバイザ１０２は開始時刻と終了時刻とを実行履歴としてオーケストレータ１１０へ送信してもよい。または、仮想ＯＳ１０３Ｂがタスク１０４Ｂとタスク１０４Ｃの実行開始時刻と実行終了時刻とを記録し、記録された実行開始時刻と実行終了時刻とを実行履歴としてハイパーバイザ１０２がオーケストレータ１１０へ送信してもよい。また、ハイパーバイザ１０２を経由する代わりに、タスク１０４Ｂ、タスク１０４Ｃまたは仮想ＯＳ１０３Ｂが直接オーケストレータ１１０へ実行履歴を送信してもよい。

次に、オーケストレータ１１０は、受信したメッセージＭ６に含まれる実行履歴から、仮想ＯＳ１０３Ｂに割り当てるＣＰＵリソースを計算する（ステップＳ１１）。計算された仮想ＯＳ１０３Ｂに割り当てるべきリソース量は、たとえば記憶部１１４に記憶される。

次に、オーケストレータ１１０のコントローラ１１１は、サーバ１００にテストモードの終了を指示するメッセージＭ７を送信する（ステップＳ１２）。これに対し、サーバ１００は、メッセージＭ７に含まれるテストモードの終了指示に従い、仮想ＯＳ１０３Ｂを停止する（ステップＳ１３）。つづいて、サーバ１００は、仮想ＯＳ１０３Ｂの停止が完了したことを通知するメッセージＭ８をオーケストレータ１１０へ送信する（ステップＳ１４）。また、オーケストレータ１１０は、端末１３０へテストモードを終了したことを通知するメッセージＭ９を送信する（ステップＳ１５）。

端末１３０がメッセージＭ９を受信した後、管理者が仮想ＯＳ１０３Ｂの起動指示を端末１３０に入力すると、端末１３０は、仮想ＯＳ１０３Ｂの起動を示すメッセージＭ１０をオーケストレータ１１０へ送信する（ステップＳ１６）。メッセージＭ１０を受信したオーケストレータ１１０のコントローラ１１１は、記憶部１１４から仮想ＯＳ１０３Ｂに割り当てるリソース量を取得し、このリソース量を仮想ＯＳ１０３Ｂの起動指示とともにメッセージＭ１１に含めてサーバ１００へ送信する（ステップＳ１７）。

次に、サーバ１００は、メッセージＭ１１に記載されたリソース量に従って仮想ＯＳ１０３ＢにＣＰＵリソースを割り当てるとともに、仮想ＯＳ１０３Ｂを起動する（ステップＳ１８）。その際、サーバ１００のハイパーバイザ１０２は、仮想ＯＳ１０３ＢをＲａｔｅ Ｍｏｎｏｔｏｎｉｃ Ｓｃｈｅｄｕｌｉｎｇでスケジュールしてもよい。または、ハイパーバイザ１０２は、仮想ＯＳ１０３ＢをＥａｒｌｉｅｓｔ Ｄｅａｄｌｉｎｅ Ｆｉｒｓｔでスケジュールしてもよい。いずれにせよ、ハイパーバイザ１０２は、仮想ＯＳ１０３Ｂに割当てるリソースＲ２を（Π２，Θ２）として、ＣＰＵコア１０１が周期Π２毎に仮想ＯＳ１０３Ｂ上のタスク１０４を多くとも時間Θ２だけ実行するように、スケジュールを組み立てる。

次に、サーバ１００は、仮想ＯＳ１０３Ｂの起動が完了したことを示すメッセージＭ１２をオーケストレータ１１０へ送信する（ステップＳ１９）。これに対し、オーケストレータ１１０は、仮想ＯＳ１０３Ｂの起動が完了したことを示すメッセージＭ１３を端末１３０へ送信する（ステップＳ２０）。これにより、仮想ＯＳへ割り当てるリソース量の算出を目的としたテストモードの実行から実際の仮想ＯＳの実行までの実施形態１による動作が完了する。

ここで、上記図６のステップＳ１１におけるリソース量の計算方法について、以下に説明する。リソース量を計算するにあたり、オーケストレータ１１０は、少なくともステップＳ１１より前の任意のタイミングで、タスク１０４Ｂおよびタスク１０４Ｃの実行周期を取得する。ただし、オーケストレータ１１０は、タスク１０４Ｂおよびタスク１０４Ｃの実行周期をそれぞれ異なるタイミングで取得しても良い。

オーケストレータ１１０は、以下のいずれかの方法で仮想ＯＳ１０３Ｂ上のタスク１０４Ｂの実行周期を取得してよい。たとえば、タスク１０４Ｂの実行周期をあらかじめ管理者が図１に示すオーケストレータ１１０の記憶部１１４に保存しておき、これをオーケストレータ１１０のリソース計算部１１２がコントローラ１１１を介して取得するようにしてもよい。もしくは、タスク１０４Ｂの実行周期を記したファイルをあらかじめストレージシステム１２０に保存しておき、このファイルをオーケストレータ１１０がネットワーク１４０を介して取得してリソース計算部１１２に渡すようにしてもよい。仮想ＯＳ１０３Ｂのプロバイダがタスク１０４Ｂの実行周期を記したファイルを仮想ＯＳ１０３Ｂのイメージとともに配布した場合、管理者がタスク１０４の実行周期を入力する手間を省くことができる。

または、オーケストレータ１１０は、サーバ１００から任意のタイミングでタスク１０４Ｂの実行周期を記したメッセージを受信して、タスク１０４Ｂの実行周期を記憶部１１４に保存しておいてもよい。その場合、サーバ１００のハイパーバイザ１０２、または、仮想ＯＳ１０３Ｂが、オーケストレータ１１０へ送信するメッセージにタスク１０４Ｂの実行周期を記載するようにしてもよい。もしくは、タスク１０４Ｂが、自身の実行周期をオーケストレータ１１０へ直接通知してもよい。その場合、たとえばタスク１０４Ｂの実行周期が変更された場合でも、管理者がタスク１０４Ｂの実行周期を入力し直さなければならないという手間を省くことができる。

または、サーバ１００がメッセージＭ６にタスク１０４Ｂの実行周期を記載することで、タスク１０４Ｂの実行履歴と共にオーケストレータ１１０へ送信してもよい。その場合、オーケストレータ１１０は、一度で実行周期と実行履歴とを取得することができる。オーケストレータ１１０がタスク１０４Ｃの実行周期を取得する方法も、上記のいずれかの方法でよい。

次に、オーケストレータ１１０が仮想ＯＳ１０３Ｂ上のタスク１０４の実行周期と実行履歴とから仮想ＯＳ１０３Ｂに割り当てるリソース量を計算する方法を説明する。図７は、仮想ＯＳ１０３Ｂに割り当てるリソース量を算出する際のオーケストレータの動作を示すフローチャートである。以下、図７に示すオーケストレータ１１０の動作の説明において、タスク１０４はタスク１０４Ｂおよびタスク１０４Ｃを指す。

図７に示すように、まず、コントローラ１１１が、サーバ１００から実行履歴を含むメッセージＭ６を受信し（ステップＳ１０１）、かつ、タスク１０４の実行周期を取得すると（ステップＳ１０２）、受信したメッセージＭ６に含まれる実行履歴と、取得したタスク１０４の実行周期とを、負荷計算部１１３へ入力する（ステップＳ１０３）。

タスク１０４の実行履歴と実行周期とを取得した負荷計算部１１３は、仮想ＯＳ１０３Ｂ上で動作する全てのタスク１０４のうち未選択のタスクを１つ選択する（ステップＳ１０４）。負荷計算部１１３が選択したタスクをタスクαと記す。タスクαについて実行履歴を解析することで、タスクαが必要とするＣＰＵリソースの量を計算する（ステップＳ１０５）。次に、負荷計算部１１３は、仮想ＯＳ１０３Ｂ上で動作する全てのタスク１０４についてＣＰＵリソースの量を計算したか否かを判定し（ステップＳ１０６）、全てのタスク１０４についてのリソース量の計算が完了していない場合（ステップＳ１０６；ＮＯ）、ステップＳ１０２４へリターンする。これにより、仮想ＯＳ１０３Ｂ上で動作する全てのタスク１０４について、各タスク１０４が必要とするリソースの量が計算される。

次に、リソース計算部１１２は、負荷計算部１１３によって計算された各タスク１０４が必要とするリソース量を用いて、仮想ＯＳ１０３Ｂに割り当てるリソース量を計算する（ステップＳ１０７）。そして、コントローラ１１１は、仮想ＯＳ１０３Ｂに割り当てるリソースの量を記憶部１１４に保存する（ステップＳ１０８）。

また、図７のステップＳ１０５おける負荷計算部１１３の動作例を、図８を用いて説明する。図８には、仮想ＯＳ１０３Ｂ上で動作するタスク１０４の数が２である場合を例示するが、仮想ＯＳ上で動作するタスクの数には制限がない。そこで、以下では仮想ＯＳ１０３上で動作するタスクの数をｎで表す。また、仮想ＯＳ１０３Ｂ上で動作するタスク１０４をＴ（ｉ）とする。変数ｉは０≦ｉ＜ｎを満たす整数である。さらに、実行履歴に含まれるタスクＴ（ｉ）のうち最も早い開始時刻の直前のタスクＴ（ｉ）のデッドラインの時刻をＤ（ｉ，０）とし、実行履歴に含まれるタスクＴ（ｉ）のうち最も遅い終了時刻の直後のタスクＴ（ｉ）のデッドラインの時刻をＤ（ｉ，ｍ）とする。さらにまた、時刻Ｄ（ｉ，０）から時刻Ｄ（ｉ，ｍ）の間のタスクＴ（ｉ）のデッドラインの時刻をＤ（ｉ，ｊ）（但し、ｊは０≦ｊ≦ｍを満たす整数）とし、時刻Ｄ（ｉ，ｊ）から時刻Ｄ（ｉ，ｊ＋１）（但し、０≦ｊ≦ｍ−１）の間の期間をＩ（ｉ，ｊ）とする。

まず、負荷計算部１１３は、それぞれの期間Ｉ（ｉ，ｊ）に含まれるタスクＴ（ｉ）の実行時間（分割されている場合はその総量）Ｃ（ｉ，ｊ）を求める。具体的には、負荷計算部１１３は、変数ｊに０をセットし（ステップＳ１１１）、実行期間が期間Ｉ（ｉ，ｊ）に含まれるタスクＴ（ｉ）の実行時間Ｃ（ｉ，ｊ）を計算する（ステップＳ１１２）。つぎに、変数ｊを１つインクリメントし（ステップＳ１１３）、インクリメント後の変数ｊがｍに達したか否かを判定する（ステップＳ１１４）。変数ｊがｍに達していない場合（ステップＳ１１４；ＮＯ）、負荷計算部１１３は、ステップＳ１１２へリターンし、以降、変数ｊがｍに達するまで、ステップＳ１１２〜Ｓ１１４を繰り返すことで、それぞれの期間Ｉ（ｉ，ｊ）に含まれるタスクＴ（ｉ）の実行時間Ｃ（ｉ，ｊ）を求める。

なお、実行履歴に含まれるタスクＴ（ｉ）のそれぞれの開始時間をＳ（ｉ，ｋ）、終了時刻をＥ（ｉ，ｋ）とすると、実行時間Ｃ（ｉ，ｊ）は以下の式（１）で計算することできる。
Ｃ（ｉ，ｊ）＝Σ｛Ｅ（ｉ，ｋ）−Ｓ（ｉ，ｋ）｝ …（１）
（ただし、Ｅ（ｉ，ｋ）およびＳ（ｉ，ｋ）は期間Ｉ（ｉ，ｊ）に含まれる）

次に、負荷計算部１１３は、タスクＴ（ｉ）に対して必要最小限のリソースＲを求める（ステップＳ１１５）。ここで、タスクＴ（ｉ）に対する必要最小限のリソースＲ（ｉ）は、割り当て周期Π（ｉ）と１周期あたりの割当て時間Θ（ｉ）とで定義することができる。たとえば、負荷計算部１１３は、割り当て周期Π（ｉ）をタスクＴ（ｉ）の実行周期とすることができる。

また、負荷計算部１１３は、割当て時間Θ（ｉ）を実行時間Ｃ（ｉ，ｊ）の最小値（但し、０≦ｊ≦ｍ−１）としてもよいし、実行時間Ｃ（ｉ，ｊ）の最大値（但し、０≦ｊ≦ｍ−１）としてもよい。または、負荷計算部１１３は、割当て時間Θ（ｉ）を実行時間Ｃ（ｉ，ｊ）の平均値（但し、０≦ｊ≦ｍ−１）としてもよい。もしくは、負荷計算部１１３は、実行時間Ｃ（ｉ，ｊ）のうち平均値に近いものから（ｍ・Ｘ）個を選び、その最大値を割当て時間Θ（ｉ）としてもよい。なお、Ｘは、０＜Ｘ＜１を満たす実数であれば如何なる値であってもよい。

次に、負荷計算部１１３は、タスクＴ（ｉ）に対して求めた必要最小限のリソースＲ（ｉ）に対し、余裕を付加することで、新たなリソースＲ１（ｉ）を求める（ステップＳ１１６）。たとえば、負荷計算部１１３は、リソースＲ１（ｉ）の割り当て周期Π１（ｉ）を周期Π（ｉ）と同じタスクＴ（ｉ）の実行周期にする。リソースＲ１（ｉ）は、タスクＴ（ｉ）が必要とするリソースを表す。

負荷計算部１１３は、余裕を含むリソースＲ１（ｉ）の割当て時間Θ１（ｉ）を、以下の式（２）で計算してもよい。なお、式（２）において、ε（ｉ）はリソースＲ（ｉ）に対して設定する余裕である。式（２）において、余裕ε（ｉ）は時間で定義される。
Θ１（ｉ）＝Θ（ｉ）＋ε（ｉ） …（２）

また、負荷計算部１１３は、たとえば以下の式（３）に示されるルールで余裕ε（ｉ）を設定してもよい。式（３）においても、余裕ε（ｉ）は時間で定義される。
Π（ａ）≦Π（ｂ）の場合、ε（ａ）≦ε（ｂ） …（３）

実行周期が長いタスクほど、実行履歴に含まれる期間Ｉの数が少ないため、実行時間Ｃ（ｉ，ｊ）はばらつく。そこで、上記の式（３）のように、実行周期が長いタスクほど、大きな余裕ε（ｉ）を加えることで、最終的に仮想ＯＳ１０３Ｂに割り当てたリソースが不足する事態を回避することができる。

また、負荷計算部１１３は、たとえば以下の式（４）に示されるルールで余裕ε（ｉ）を設定してもよい。
Θ（ａ）≦Θ（ｂ）の場合、ε（ａ）≦ε（ｂ） …（４）

また、負荷計算部１１３は、たとえば余裕ε（ｉ）を以下の式（５）で計算してもよい。
ε（ｉ）＝ｋ×δ（ｉ） …（５）

なお、式（５）において、δ（ｉ）はタスクＴ（ｉ）の実行時間のＣ（ｉ，ｊ）（０≦ｊ≦ｍ−１）の分散または標準偏差である。または、δ（ｉ）は実行時間Ｃ（ｉ，ｊ）（０≦ｊ≦ｍ−１）の最大値から最小値を引いた値でもよい。また、式（５）におけるｋはあらかじめ決められた０より大きい実数の定数である。

次に、図７のステップＳ１０７におけるリソース計算部１１２の動作例を説明する。リソース計算部１１２は、各タスクに必要なリソースＲ１（ｉ）（０≦ｉ＜ｎ）を入力として、たとえば非特許文献１に記載の方法を用いてリソースＲ２＝（Π２，Θ２）を計算し、リソースＲ２を仮想ＯＳ１０３に割り当てても良い。

また、リソース計算部１１２は、仮想ＯＳ１０３Ｂに対して計算したリソースＲ２に余裕ψを加えて新たなリソースＲ３＝（Π３、Θ３）を計算し、リソースＲ３を仮想ＯＳ１０３に割り当ててもよい。余裕ψは時間で定義される。たとえば、リソース計算部１１２はΠ３＝Π２−ψにするか、Θ３＝Θ２＋ψとすることで仮想ＯＳ１０３Ｂに割り当てるリソースに余裕を加える。また、たとえば、リソース計算部１１２は、各タスク１０４の実行周期Π（ｉ）の分散が小さいほど余裕ψを大きくしてもよい。

たとえば仮想ＯＳ１０３ＢがＲａｔｅ Ｍｏｎｏｔｏｎｉｃ Ｓｃｈｅｄｕｌｉｎｇなどの静的優先度に基づくスケジューリングアルゴリズムを用いる場合、割り当て周期Π（ｉ）の分散が小さいほど割り当て周期Π３に占める割当て時間Θ３の割合が大きいため、タスクＴ（ｉ）のいずれかがリソース不足になる可能性が高くなる。そこで、割り当て周期Π（ｉ）の分散が小さい場合に余裕ψを大きくすることで、タスクＴ（ｉ）のいずれかがリソース不足になる可能性を小さくできる。

また、リソース計算部１１２は、たとえば仮想ＯＳ１０３Ｂ上で動作する各タスクＴ（ｉ）のうち最大の実行周期Πから最小の実行周期Πを引いた値が小さいほど余裕ψを大きくしてもよい。これにより、分散を計算するより小さい計算量で余裕ψを計算できる。

さらに、リソース計算部１１２は、リソースＲ２に加える余裕ψを、以下の式（６）で計算することで、仮想ＯＳ１０３Ｂがリソースを使わない割合を必ず値Ωよりも大きくしてもよい。
Δ＝１−Σ｛Θ（ｉ）／Π（ｉ）｝
ψ＝Π２×（Ω―Δ） （Δ＜Ωの場合）または０（Δ≧Ωの場合） …（６）

なお、式（６）において、Ωは、あらかじめ決められた値である。Δは、仮想ＯＳ１０３ＢにリソースＲ２を割り当てた場合における、仮想ＯＳ１０３Ｂがリソースを使わない割合の推定値を示す。

上記した余裕εおよびψの算出方法のいずれにおいても、リソース計算部１１２は、余裕εまたはψは、各タスクＴ（ｉ）の実行周期または１周期あたりの実行時間に基づいて決定されればよい。

以上のように、実施形態１によれば、十分でかつ可能な限り少ないＣＰＵリソースを、リアルタイムタスクを実行する仮想マシンに提供することが可能になる。

なお、実施形態１では、オーケストレータ１１０は、実際にサーバ１００の仮想ＯＳ１０３Ｂ上で動作するタスク１０４の実行期間を計測させる機能を備えるため、精度よく１周期当たりの実行時間を取得可能である。

また、オーケストレータ１１０は、実行履歴を用いて計算した仮想ＯＳ１０３Ｂ上の各タスクＴ（ｉ）に対する最小限のリソース量に余裕を加えるため、仮想ＯＳ１０３Ｂ上で動作するいずれかのタスクＴ（ｉ）がリソース不足になることを防止可能である。

さらに、オーケストレータ１１０は、タスクＴ（ｉ）に対する最小限のリソース量に加える余裕を、タスクＴ（ｉ）の実行周期に基づいて決定するため、余裕を最小限にすることができる。

さらにまた、オーケストレータ１１０は、タスクＴ（ｉ）の実行周期の分散が大きい仮想ＯＳほど加える余裕を小さくすることで、加える余裕を最小限にすることができる。

さらにまた、オーケストレータ１１０は、サーバ１００に実際にタスクＴ（ｉ）の実行期間を計測するよう指示する機能を備える。これにより、たとえばサーバ１００が異なるパフォーマンスを備えるサーバに置き換えられる場合であっても、管理者がタスクＴ（ｉ）の１周期当たりの実行時間を入力する手間を省くことができる。

なお、実施形態１において、仮想ＯＳ１０３Ｂ上で動作する各タスクＴ（ｉ）に対する必要最小限のリソースがあらかじめストレージシステム１２０またはオーケストレータ１１０の記憶部１１４に記憶されている場合、オーケストレータ１１０、ストレージシステム１２０およびサーバ１００は、図６に示すステップＳ５〜Ｓ９およびステップＳ１２〜Ｓ１４を省略することができる。この場合、仮想ＯＳ１０３Ｂに余分なリソースを割り当てるための時間を短縮することができる。

また、サーバ１００は、仮想ＯＳ１０３Ｂに複数のＣＰＵコア１０１を割り当ててもよい。その場合、図６に示すステップＳ１７において、オーケストレータ１１０は１以上のタスクを１以上のグループに分けてよい。そして、オーケストレータ１１０は、それぞれのグループに割り当てるリソース量を計算してよい。計算されたグループ毎のリソース量は、図６に示すメッセージＭ１１に含められてよい。さらに、サーバ１００は、同一グループに属すタスク１０４を同一のＣＰＵコア１０１で実行してもよい。

さらに、実施形態１において、サーバ１００がタスク１０４の実行時間を計測する計測期間は、あらかじめ決められた時間であってもよい。または、計測期間は、あらかじめ決められた回数であってもよい。または、計測期間は、１回の実行周期あたりの実行時間の分散があらかじめ決められた値以下になるまでの期間であってもよい。

（実施形態２）
次に、実施形態２にかかるスケジューリング装置、システム、装置、方法およびプログラムを、図面を参照して詳細に説明する。上述した実施形態１では、仮想ＯＳ１０３がテストモードを備える場合を例示した。これに対し、実施形態２では、仮想ＯＳ１０３がテストモードを備えていない場合を例示する。そこで、実施形態２では、仮想ＯＳ１０３が起動している任意のタイミングで、オーケストレータ１１０が自動的に仮想ＯＳ１０３に割り当てる必要最小限のリソースを計算する。

実施形態２にかかる情報処理システムの構成は、実施形態１において図１を用いて説明した情報処理システム１と同様であってよいため、ここでは重複する説明を省略する。

図９は、実施形態２にかかる情報処理システムの動作例を示すシーケンス図である。なお、実施形態２にかかる情報処理システムの動作を説明するにあたり、図１に示す仮想ＯＳ１０３Ｂのイメージファイルがストレージシステム１２０に保存されているとする。

図９に示すように、まず、管理者がストレージシステム１２０に保存された仮想ＯＳ１０３Ｂの起動指示を端末１３０に入力すると、端末１３０は、仮想ＯＳ１０３Ｂを起動する指示が記されたメッセージＭ３１をオーケストレータ１１０へ送信する（ステップＳ３１）。これに対し、オーケストレータ１１０は、仮想ＯＳ１０３Ｂの起動指示を含むメッセージＭ３２をサーバ１００へ送信する（ステップＳ３２）。なお、メッセージＭ３１およびＭ３２には、少なくとも仮想ＯＳ１０３ＢのイメージファイルＩＦ１を識別するための識別子が含まれる。また、メッセージＭ３２には、仮想ＯＳ１０３Ｂに十分なリソース量を割り当てるための指示が含まれていてもよい。十分なリソース量とは、たとえばＣＰＵコア１つ分のＣＰＵリソースであってよい。この場合、仮想ＯＳ１０３Ｂに割り当てられるリソースの割り当て周期と割り当て時間が等しい。

次に、サーバ１００は、受信したメッセージＭ３２に基づいてイメージファイルＩＦ１に含まれる仮想ＯＳ１０３Ｂを起動し（ステップＳ３３）、その後、仮想ＯＳ１０３Ｂの起動が完了すると、起動完了を示すメッセージＭ３４をオーケストレータ１１０へ送信する（ステップＳ３４）。

具体的には、ステップＳ３３において、サーバ１００は、仮想ＯＳ１０３ＢのイメージファイルＩＦ１を要求するメッセージＭ３３をストレージシステム１２０に送信する。これに対し、ストレージシステム１２０は、要求されたイメージファイルＩＦ１を読み出し、これをサーバ１００へ送信する。

また、ステップＳ３３では、サーバ１００は、起動する仮想ＯＳ１０３ＢにＣＰＵリソースを割り当てる。たとえば、サーバ１００は、仮想ＯＳ１０３ＢにＣＰＵコア１つ分のＣＰＵリソースを割り当てる。その場合、仮想ＯＳ１０３ＢがＣＰＵコア１つを占有することが可能になるため、仮想ＯＳ１０３Ｂまたは仮想ＯＳ１０３Ｂ上で動作するタスク１０４Ｂとタスク１０４ＣはいつでもＣＰＵコアを利用することが可能である。このとき、仮想ＯＳ１０３Ｂに割り当てられたＣＰＵリソースの割当て周期および１周期当たりの割当て時間は同一であってよい。その後、サーバ１００は、イメージファイルＩＦ１に含まれる仮想ＯＳ１０３Ｂのプログラムコードを実行して仮想ＯＳ１０３を起動する。

その後、仮想ＯＳ１０３Ｂの起動が完了したことを示すメッセージＭ３４をサーバ１００から受信したオーケストレータ１１０は、端末１３０へ仮想ＯＳ１０３Ｂの起動が完了したことを示すメッセージＭ３５を送信する（ステップＳ３５）。

仮想ＯＳ１０３Ｂが起動され、任意の時間が経過した後、オーケストレータ１１０は、実行履歴の要求を示すメッセージＭ３６をサーバ１００へ送信する（ステップＳ３６）。これに対し、サーバ１００は、仮想ＯＳ１０３Ｂ上で実行される全てのタスク１０４の実行履歴をあらかじめ決められた時間の間計測して記録し（ステップＳ３７）、記録した実行履歴を記したメッセージＭ３７をオーケストレータ１１０へ送信する（ステップＳ３８）。実行履歴を取得したオーケストレータ１１０は、仮想ＯＳ１０３Ｂに割り当てるリソース量を計算する（ステップＳ３９）。

なお、ステップＳ３６〜Ｓ３９におけるオーケストレータ１１０およびサーバ１００の動作は、図６のステップＳ８〜Ｓ１１に示した動作と同様である。

次に、オーケストレータ１１０は、仮想ＯＳ１０３Ｂのリソース量の縮小を示すメッセージＭ３８をサーバ１００へ送信する（ステップＳ４０）。このメッセージＭ３８には、仮想ＯＳ１０３ＢのＣＰＵリソースの割当て周期および１周期当たりの時間が記載される。

次に、サーバ１００は、メッセージＭ３８に記載された割当て周期および１周期当たりの時間に従って、仮想ＯＳ１０３Ｂに割り当てるリソース量を縮小する（ステップＳ４１）。その後、サーバ１００は、リソースの縮小が完了したことを示すメッセージＭ３９をオーケストレータ１１０へ送信する（ステップＳ４２）。

以上のように、実施形態２によれば、実施形態１と同様に、十分でかつ可能な限り少ないリソースを、リアルタイムタスクを実行する仮想マシンに提供することが可能になる。

また、実施形態２では、仮想ＯＳ１０３Ｂが起動している任意のタイミングで、オーケストレータ１１０が自動的に仮想ＯＳ１０３Ｂに割り当てる必要最小限のリソースを計算する。そのため、管理者は、仮想ＯＳ１０３Ｂを起動する前に仮想ＯＳ１０３Ｂ上の全タスク１０４の実行履歴の計測完了を待つ必要なく、仮想ＯＳ１０３Ｂの作成指示を入力することができる。

なお、実施形態２において、仮想ＯＳ１０３Ｂ上で動作する各タスク１０４に対する必要最小限のリソースがあらかじめストレージシステム１２０またはオーケストレータ１１０の記憶部１１４に記憶されている場合、オーケストレータ１１０、ストレージシステム１２０およびサーバ１００は、図９に示すステップＳ３６〜Ｓ３８を省略することができる。この場合、仮想ＯＳ１０３Ｂに余分なリソースを割り当てるための時間を短縮することができる。

また、サーバ１００は、仮想ＯＳ１０３Ｂに複数のＣＰＵコア１０１を割り当ててもよい。その場合、図９に示すステップＳ３９において、オーケストレータ１１０は１以上のタスクを１以上のグループに分けてよい。そして、オーケストレータ１１０は、それぞれのグループに割り当てるリソース量を計算してよい。計算されたグループ毎のリソース量は、図９に示すメッセージＭ３８に含められてよい。さらに、サーバ１００は、同一グループに属すタスク１０４を同一のＣＰＵコア１０１で実行してもよい。

さらに、実施形態２において、サーバ１００がタスク１０４の実行時間を計測する計測期間は、あらかじめ決められた時間であってもよい。または、計測期間は、あらかじめ決められた回数であってもよい。または、計測期間は、１回の実行周期あたりの実行時間の分散があらかじめ決められた値以下になるまでの期間であってもよい。この場合、仮想ＯＳ１０３に割り当てるリソースに加える余裕εまたは余裕ψを小さくすることができる。

さらにまた、実施形態２において、オーケストレータ１１０は、ステップＳ３６〜Ｓ４２までの工程を２回以上実行してもよい。その際、繰返しの間に任意の時間間隔を設けるとよい。この場合、サーバ１００は、ステップＳ３７の前に仮想ＯＳ１０３に割当てるリソースを増やしてもよい。

（実施形態３）
つぎに、実施形態３にかかるスケジューリング装置、システム、装置、方法およびプログラムを、図面を参照して詳細に説明する。上述した実施形態１および２では、リソース量を計算する装置（オーケストレータ１１０）と実際にリソースを仮想ＯＳ１０３Ｂに割り当てる装置（サーバ１００）とが異なっていた。これに対し、実施形態３では、仮想ＯＳ１０３Ｂを実行するサーバと同じサーバ１００が、仮想ＯＳ１０３Ｂに割り当てるリソース量を計算する。

図１０に、実施形態３にかかる情報処理システムの構成例を示す。図１０に示すように、情報処理システム２は、１台以上のサーバ２００と、ストレージシステム１２０と、端末１３０とがネットワーク１４０を介して相互に接続された構成を有する。ただし、図１０において、サーバ２００は、ネットワーク１４０に接続されていてもよいし、接続されなくてもよい。

図１０において、サーバ２００は、タスク１０４Ａ〜１０４Ｃ、仮想ＯＳ１０３Ａ〜１０３Ｂ、ハイパーバイザ１０２およびＣＰＵコア１０１を備える。これらの構成および動作は、それぞれ実施形態１または２において例示したタスク１０４、仮想ＯＳ１０３、ハイパーバイザ１０２およびＣＰＵコア１０１と同様であってよい。

また、サーバ２００は、リソース割当て部２１０をさらに備える。リソース割当て部２１０は、たとえば上述したオーケストレータ１１０の機能を実現するプログラムであり、リソース計算部１１２、負荷計算部１１３、記憶部１１４、およびコントローラ２１１を備える。リソース計算部１１２、負荷計算部１１３および記憶部１１４の構成および動作は、それぞれ実施形態１または２において例示したリソース計算部１１２、負荷計算部１１３、記憶部１１４と同様であってよい。コントローラ２１１は、コントローラ１１１と異なり、同一サーバ２００内で、直接ハイパーバイザ１０２と通信する。

次に、実施形態３にかかる情報処理システム２の動作例を、図１１を用いて説明する。図１１に示すように、まず、管理者がストレージシステム１２０に保存された仮想ＯＳ１０３Ｂの起動指示を端末１３０に入力すると、端末１３０は、仮想ＯＳ１０３Ｂを起動する指示が記されたメッセージＭ４１をサーバ２００へ送信する（ステップＳ４１）。なお、メッセージＭ４１には、少なくとも仮想ＯＳ１０３ＢのイメージファイルＩＦ１を識別するための識別子が含まれる。

次に、サーバ２００のコントローラ２１１は、受信したメッセージＭ４１に基づいてイメージファイルＩＦ１に含まれる仮想ＯＳ１０３Ｂを起動し（ステップＳ４２）、その後、仮想ＯＳ１０３Ｂの起動が完了すると、起動完了を示すメッセージＭ４３を端末１３０へ送信する（ステップＳ４３）。

具体的には、ステップＳ４２において、サーバ２００は、仮想ＯＳ１０３ＢのイメージファイルＩＦ１を要求するメッセージＭ４２をストレージシステム１２０に送信する。これに対し、ストレージシステム１２０は、要求されたイメージファイルＩＦ１を読み出し、これをサーバ２００へ送信する。

また、ステップＳ４２では、サーバ２００は、起動する仮想ＯＳ１０３ＢにＣＰＵリソースを割り当てる。たとえば、サーバ２００は、仮想ＯＳ１０３ＢにＣＰＵコア１つ分のＣＰＵリソースを割り当てる。その場合、仮想ＯＳ１０３ＢがＣＰＵコア１つを占有することが可能になるため、仮想ＯＳ１０３Ｂまたは仮想ＯＳ１０３Ｂ上で動作するタスク１０４はいつでもＣＰＵコアを利用することが可能である。このとき、仮想ＯＳ１０３Ｂに割り当てられたＣＰＵリソースの割当て周期および１周期当たりの割当て時間は同一であってよい。その後、サーバ２００は、イメージファイルＩＦ１に含まれる仮想ＯＳ１０３Ｂのプログラムコードを実行して仮想ＯＳ１０３Ｂを起動する。

次に、サーバ２００は、仮想ＯＳ１０３Ｂ上で実行される各タスク１０４の実行履歴を計測する（ステップＳ４４）。ステップＳ４４では、サーバ２００のコントローラ２１１は、ハイパーバイザ１０２に、実行履歴を要求するメッセージを渡す。これに対し、ハイパーバイザ１０２は、仮想ＯＳ１０３Ｂ上の各タスク１０４の開始時刻および終了時刻を計測する。そして、ハイパーバイザ１０２は、実行履歴をコントローラ２１１に渡す。なお、ステップＳ４４において、ハイパーバイザ１０２の代わりに、仮想ＯＳ１０３Ｂまたは仮想ＯＳ１０３Ｂ上のタスク１０４が開始時刻および終了時刻を計測してもよい。

次に、サーバ２００のリソース割当て部２１０は、仮想ＯＳ１０３Ｂに割り当てるリソース量を計算する（ステップＳ４５）。ステップＳ４５における負荷計算部１１３およびリソース計算部１１２の動作は、図６のステップＳ１１における負荷計算部１１３およびリソース計算部１１２の動作と同様であってよい。

次に、サーバ２００のコントローラ２１１は、仮想ＯＳ１０３Ｂに割り当てるリソース量を縮小する（ステップＳ４６）。ステップＳ４６の動作は、図９のステップＳ４１と同様であってよい。

以上のように、実施形態３によれば、実施形態１または２と同様に、十分でかつ可能な限り少ないＣＰＵリソースを、リアルタイムタスクを実行する仮想マシンに提供することが可能になる。

なお、実施形態１〜３では、サーバ１００または２００が仮想ＯＳ１０３Ｂに１つのＣＰＵコア１０１のリソースを割り当てるが、仮想ＯＳ１０３Ｂに割り当てるべきリソース量が１つのＣＰＵコア１０１のリソースより少ないリソース量で十分であることが判明している場合は、サーバ１００または２００は、１つのＣＰＵコア１０１のリソースよりも少ないリソース量を仮想ＯＳ１０３Ｂに割り当ててもよい。

例えば、オーケストレータ１１０またはリソース割当て部２１０は、割当て周期よりも短い１周期当たりの割当て時間を仮想ＯＳ１０３Ｂに割り当ててもよい。これにより、ＣＰＵコア一つ分のリソースを確保する必要がないため、仮想ＯＳ１０３Ｂを起動するサーバ１００または２００の候補を多くすることができる。

また、実施形態１〜３において、ストレージシステム１２０は必須の構成ではない。ストレージシステム１２０を省略した場合、実施形態１における仮想ＯＳ１０３ＢのイメージファイルＩＦ２または実施形態２〜３のイメージファイルＩＦ１は、サーバ１００または２００に保存されていればよい。

また、実施形態１〜３において、サーバ１００または２００は、直接管理者が仮想ＯＳ１０３Ｂの起動を操作できるインタフェースを備えていてもよい。この場合、管理者が端末１３０Ｂを用いてサーバ１００にリモートアクセスする必要がなくなるため、端末１３０Ｂを省略することができる。

上記実施形態およびその変形例は本発明を実施するための例にすぎず、本発明はこれらに限定されるものではなく、仕様等に応じて種々変形することは本発明の範囲内であり、更に本発明の範囲内において、他の様々な実施形態が可能であることは上記記載から自明である。例えば実施形態に対して適宜例示した変形例は、他の実施形態と組み合わせることも可能であることは言うまでもない。

１，２…情報処理システム、１００，１００Ａ〜１００Ｃ，２００…サーバ、１０１…ＣＰＵコア、１０２…ハイパーバイザ、１０３，１０３Ａ〜１０３Ｂ…仮想ＯＳ、１０４，１０４Ａ〜１０４Ｃ…タスク、１１０…オーケストレータ、１１１，２１１…コントローラ、１１２…リソース計算部、１１３…負荷計算部、１１４…記憶部、１２０…ストレージシステム、１３０…端末、１４０…ネットワーク、２１０…リソース割当て部

Claims (12)

1. 仮想ＯＳ上で動作する１つ以上のタスクであってそれぞれ予め決められた周期的なデッドラインまでに１回分の処理を完了する必要がある前記１つ以上のタスクが必要とする第１リソース量を取得する負荷計算部と、
   前記第１リソース量に基づいて前記仮想ＯＳに割り当てる第２リソース量を計算するリソース計算部と、
   を備え、
   前記負荷計算部は、各タスクが必要とする最小限の第３リソース量に、各タスクの実行周期または１周期あたりの実行時間に基づく余裕を付加することで、前記第１リソース量を計算する
   スケジューリング装置。
2. 前記負荷計算部は、前記実行周期の長さ、前記１周期あたりの実行時間の長さ、前記実行周期の分散、前記実行周期の標準偏差、および、前記１つ以上のタスクの前記１周期あたりの実行時間のうち最大値から最小値を引いた値のうち少なくとも１つを用いて前記余裕を計算する
   請求項１に記載のスケジューリング装置。
3. 前記負荷計算部は、前記実行周期が長いタスクほど大きな前記余裕を前記第３リソース量に付加することで、前記第１リソース量を計算する
   請求項１に記載のスケジューリング装置。
4. 前記リソース計算部は、前記１つ以上のタスクの実行周期の分散が小さいほど大きな前記余裕を前記第３リソース量に付加することで、前記第１リソース量を計算する
   請求項１に記載のスケジューリング装置。
5. 前記仮想ＯＳ上で動作する前記１つ以上のタスクの実行履歴を取得するコントローラをさらに備え、
   前記負荷計算部は、前記コントローラにより取得された前記実行履歴に基づいて各タスクが必要とする前記第１リソース量を計算する
   請求項１に記載のスケジューリング装置。
6. 前記コントローラは、前記１つ以上のタスクの実行周期をさらに取得し、
   前記負荷計算部は、前記実行履歴から各タスクの前記１周期あたりの実行時間を計算し、前記１周期あたりの実行時間から各タスクが必要とする前記第１リソース量を計算する
   請求項５に記載のスケジューリング装置。
7. 前記実行履歴は、前記１つ以上のタスクの開始時刻と終了時刻とを含み、
   前記負荷計算部は、各タスクの開始時刻と終了時刻とから前記１周期あたりの実行時間を計算する
   請求項５に記載のスケジューリング装置。
8. 請求項１に記載のスケジューリング装置と、
   所定のネットワークを介して前記スケジューリング装置に接続され、前記仮想ＯＳを実行するサーバと、
   を備え、
   前記スケジューリング装置は、前記サーバへ前記仮想ＯＳ上で動作する１つ以上のタスクの実行履歴の送信を要求する第１メッセージを送信し、前記サーバから送信された前記実行履歴を含む第２メッセージを受信するとともに、前記リソース計算部で計算された前記第２リソース量を記述した第３メッセージを前記サーバへ送信し、
   前記サーバは、前記第１メッセージを受信すると、前記１つ以上のタスクを実測して前記実行履歴を取得し、取得した前記実行履歴を含む前記第２メッセージを前記スケジューリング装置へ送信するとともに、受信した前記第３メッセージに記述された前記第２リソース量に基づいて前記仮想ＯＳに割り当てられているリソース量を縮小する
   情報処理システム。
9. 前記スケジューリング装置は、前記第１メッセージを前記サーバへ送信する前に、前記仮想ＯＳに十分なリソース量を割り当てるための第４リソース量を記述した第４メッセージを前記サーバへ送信し、
   前記サーバは、前記第４メッセージを受信すると、前記仮想ＯＳを起動するとともに、前記仮想ＯＳに前記第４リソース量を割り当て、
   前記第４リソース量は、少なくとも前記第２リソース量よりも大きいか等しい
   請求項８に記載の情報処理システム。
10. 請求項１に記載のスケジューリング装置と、
    前記仮想ＯＳを実行する１つ以上の演算装置と、
    を備え、
    前記スケジューリング装置は、前記リソース計算部によって計算された前記第２リソース量を前記仮想ＯＳに割り当てる
    情報処理装置。
11. １つ以上のタスクを実行する仮想ＯＳへ割り当てるリソースをスケジューリングするコンピュータが実行するスケジューリング方法であって、
    前記１つ以上のタスクそれぞれは、予め決められた周期的なデッドラインまでに１回分の処理を完了する必要があるタスクであり、
    前記コンピュータは、
    前記仮想ＯＳ上で動作する前記１つ以上のタスクが必要とする最小限の第１リソース量を計算し、
    各タスクの実行周期または１周期あたりの実行時間に基づく余裕を前記第１リソース量に付加することで、前記１つ以上のタスクが必要とする第２リソース量を計算し、
    前記第２リソース量に基づいて前記仮想ＯＳに割り当てる第３リソース量を計算する
    スケジューリング方法。
12. １つ以上のタスクを実行する仮想ＯＳへ割り当てるリソースをスケジューリングするコンピュータを動作させるためのプログラムであって、
    前記仮想ＯＳ上で動作する前記１つ以上のタスクであってそれぞれ予め決められた周期的なデッドラインまでに１回分の処理を完了する必要がある前記１つ以上のタスクが必要とする最小限の第１リソース量を計算し、
    各タスクの実行周期または１周期あたりの実行時間に基づく余裕を前記第１リソース量に付加することで、前記１つ以上のタスクが必要とする第２リソース量を計算し、
    前記第２リソース量に基づいて前記仮想ＯＳに割り当てる第３リソース量を計算する
    ことを前記コンピュータに実行させるためのプログラム。

Images