図面 (/)

技術 制御方法、制御プログラム、及び情報処理装置

出願人 富士通株式会社
発明者 栗林遼太濱野賢治内野実杉山文康廣川誠荒川紀枝
出願日 2015年6月24日 (4年0ヶ月経過) 出願番号 2015-126482
公開日 2017年1月12日 (2年6ヶ月経過) 公開番号 2017-010358
状態 特許登録済
技術分野 マルチプログラミング
主要キーワード 手動テスト 一時停止前 ポート番 オンプレミス 制御キュー 処理監視 エージェントソフトウエア 一時停止指示
関連する未来課題
重要な関連分野

この項目の情報は公開日時点(2017年1月12日)のものです。
また、この項目は機械的に抽出しているため、正しく解析できていない場合があります

図面 (17)

課題

リソース不足によってリアルタイム処理の性能が低下することを抑制する。

解決手段

稼働中の仮想マシンがリアルタイム処理を実行する仮想マシン及びバッチ処理を実行する仮想マシンのいずれであるかの判定を行ない、仮想マシンが実行する処理が終了した場合、判定の結果に基づいて、仮想マシンがバッチ処理を実行する仮想マシンである場合は仮想マシンを停止し、仮想マシンがリアルタイム処理を実行する仮想マシンである場合は仮想マシンの稼働を維持する。

概要

背景

クラウドシステムにおいて稼働するVM(Virtual Machine)は、バッチ処理を実行するVM(以下、バッチVMと呼ぶ)とリアルタイム処理を実行するVM(以下、オンラインVMと呼ぶ)とに大別される。

バッチVMは、例えば、自動化テスト(例えばミドルウエア試験)、サイレントインストール、VMテンプレート更新する処理(例えばパッチの適用)、及びコンパイル等を実行する。バッチVMはデータを一括して処理するため、データを処理している間は割り当てられたリソースをフルに使用する。

オンラインVMは、例えば、手動テスト(例えば、自動化できないミドルウエア試験)、コーディング、環境構築(例えばOS(Operating System)、ミドルウエアのインストール)、及びトラブル調査等のために使用される。オンラインVMは要求に応じて処理を実行するため、要求が無い場合にはオンラインVMによって消費されるリソース(特に、CPU(Central Processing Unit)及びI/O(Input/Output))の量は少ない。

オンプレミスのシステムとは異なり、クラウドシステムは多数のユーザにより利用される。そのため、特定の時間帯においてバッチVMだけ或いはオンラインVMだけを稼働させるといった運用を行うことが難しく、バッチVMとオンラインVMとが両方実行される時間帯が発生する。特に昼間の時間帯においては、夜間の時間帯に比べてリアルタイム処理の要求が頻繁に発生するため、バッチVMとオンラインVMとが両方実行されると、オンラインVMに割り当てるリソースが競合により不足することがある。

VMの種別に着目してリソースの割り当てを行う従来技術は存在するが、従来技術はVMに割り当てるリソースが十分に存在することを前提としているので、リソースが十分でない場合にはリアルタイム処理の性能を確保できないことがある。

概要

リソース不足によってリアルタイム処理の性能が低下することを抑制する。稼働中の仮想マシンがリアルタイム処理を実行する仮想マシン及びバッチ処理を実行する仮想マシンのいずれであるかの判定を行ない、仮想マシンが実行する処理が終了した場合、判定の結果に基づいて、仮想マシンがバッチ処理を実行する仮想マシンである場合は仮想マシンを停止し、仮想マシンがリアルタイム処理を実行する仮想マシンである場合は仮想マシンの稼働を維持する。

目的

本発明の目的は、1つの側面では、リソース不足によってリアルタイム処理の性能が低下することを抑制するための技術を提供する

効果

実績

技術文献被引用数
0件
牽制数
0件

この技術が所属する分野

(分野番号表示ON)※整理標準化データをもとに当社作成

ライセンス契約や譲渡などの可能性がある特許掲載中! 開放特許随時追加・更新中 詳しくはこちら

請求項1

コンピュータに、稼働中の仮想マシンリアルタイム処理を実行する仮想マシン及びバッチ処理を実行する仮想マシンのいずれであるかの判定を行ない、前記仮想マシンが実行する処理が終了した場合、前記判定の結果に基づいて、前記仮想マシンが前記バッチ処理を実行する仮想マシンである場合は前記仮想マシンを停止し、前記仮想マシンが前記リアルタイム処理を実行する仮想マシンである場合は前記仮想マシンの稼働を維持する、処理を実行させるための制御プログラム

請求項2

前記コンピュータに、前記コンピュータ内のリソース使用率閾値を超えたか判定し、前記コンピュータ内のリソースの使用率が前記閾値を超えており且つ前記仮想マシンが前記バッチ処理を実行する仮想マシンである場合、前記仮想マシンを一時停止する、処理をさらに実行させるための請求項1記載の制御プログラム。

請求項3

前記コンピュータに、前記コンピュータ内のリソースの使用率が前記閾値を超えていない場合、一時停止中の他の仮想マシンの稼働を再開する、処理をさらに実行させるための請求項2記載の制御プログラム。

請求項4

前記コンピュータに、前記仮想マシンの状態が所定の状態であるか判定し、前記仮想マシンの状態が前記所定の状態であり且つ前記仮想マシンが前記リアルタイム処理を実行する仮想マシンである場合、前記仮想マシンを前記バッチ処理を実行する仮想マシンに変更する、処理をさらに実行させるための請求項3記載の制御プログラム。

請求項5

前記コンピュータに、前記仮想マシンの状態が前記所定の状態ではなく且つ前記仮想マシンが前記バッチ処理を実行する仮想マシンである場合、前記仮想マシンを前記リアルタイム処理を実行する仮想マシンに変更する、処理をさらに実行させるための請求項4記載の制御プログラム。

請求項6

コンピュータが、稼働中の仮想マシンがリアルタイム処理を実行する仮想マシン及びバッチ処理を実行する仮想マシンのいずれであるかの判定を行ない、前記仮想マシンが実行する処理が終了した場合、前記判定の結果に基づいて、前記仮想マシンが前記バッチ処理を実行する仮想マシンである場合は前記仮想マシンを停止し、前記仮想マシンが前記リアルタイム処理を実行する仮想マシンである場合は前記仮想マシンの稼働を維持する、処理を実行する制御方法

請求項7

稼働中の仮想マシンがリアルタイム処理を実行する仮想マシン及びバッチ処理を実行する仮想マシンのいずれであるかの判定を行なう判定部と、前記仮想マシンが実行する処理が終了した場合、前記判定の結果に基づいて、前記仮想マシンが前記バッチ処理を実行する仮想マシンである場合は前記仮想マシンを停止し、前記仮想マシンが前記リアルタイム処理を実行する仮想マシンである場合は前記仮想マシンの稼働を維持する制御部と、を有する情報処理装置

技術分野

0001

本発明は、仮想マシン配備技術に関する。

背景技術

0002

クラウドシステムにおいて稼働するVM(Virtual Machine)は、バッチ処理を実行するVM(以下、バッチVMと呼ぶ)とリアルタイム処理を実行するVM(以下、オンラインVMと呼ぶ)とに大別される。

0003

バッチVMは、例えば、自動化テスト(例えばミドルウエア試験)、サイレントインストール、VMテンプレート更新する処理(例えばパッチの適用)、及びコンパイル等を実行する。バッチVMはデータを一括して処理するため、データを処理している間は割り当てられたリソースをフルに使用する。

0004

オンラインVMは、例えば、手動テスト(例えば、自動化できないミドルウエア試験)、コーディング、環境構築(例えばOS(Operating System)、ミドルウエアのインストール)、及びトラブル調査等のために使用される。オンラインVMは要求に応じて処理を実行するため、要求が無い場合にはオンラインVMによって消費されるリソース(特に、CPU(Central Processing Unit)及びI/O(Input/Output))の量は少ない。

0005

オンプレミスのシステムとは異なり、クラウドシステムは多数のユーザにより利用される。そのため、特定の時間帯においてバッチVMだけ或いはオンラインVMだけを稼働させるといった運用を行うことが難しく、バッチVMとオンラインVMとが両方実行される時間帯が発生する。特に昼間の時間帯においては、夜間の時間帯に比べてリアルタイム処理の要求が頻繁に発生するため、バッチVMとオンラインVMとが両方実行されると、オンラインVMに割り当てるリソースが競合により不足することがある。

0006

VMの種別に着目してリソースの割り当てを行う従来技術は存在するが、従来技術はVMに割り当てるリソースが十分に存在することを前提としているので、リソースが十分でない場合にはリアルタイム処理の性能を確保できないことがある。

先行技術

0007

特開2013−196062号公報

発明が解決しようとする課題

0008

本発明の目的は、1つの側面では、リソース不足によってリアルタイム処理の性能が低下することを抑制するための技術を提供することである。

課題を解決するための手段

0009

1つの態様では、稼働中の仮想マシンがリアルタイム処理を実行する仮想マシン及びバッチ処理を実行する仮想マシンのいずれであるかの判定を行ない、仮想マシンが実行する処理が終了した場合、判定の結果に基づいて、仮想マシンがバッチ処理を実行する仮想マシンである場合は仮想マシンを停止し、仮想マシンがリアルタイム処理を実行する仮想マシンである場合は仮想マシンの稼働を維持する処理を含む。

発明の効果

0010

1つの側面では、リソース不足によってリアルタイム処理の性能が低下することを抑制できるようになる。

図面の簡単な説明

0011

図1は、本実施の形態のシステム概要を示す図である。
図2は、物理マシンハードウエア構成図である。
図3は、物理マシンの機能ブロック図である。
図4は、制御ブロックの一例を示す図である。
図5は、種別データ格納部に格納されるデータの一例を示す図である。
図6は、種別変更処理部が実行する処理の処理フローを示す図である。
図7は、種別変更処理部が実行する処理の処理フローを示す図である。
図8は、種別変更処理部が実行する処理の処理フローを示す図である。
図9は、処理監視部が実行する処理の処理フローを示す図である。
図10は、第2変更部が実行する処理の処理フローを示す図である。
図11は、第1変更部が実行する処理の処理フローを示す図である。
図12は、リソース監視部が実行する処理の処理フローを示す図である。
図13は、リソース監視部が実行する処理の処理フローを示す図である。
図14は、リソース監視部が実行する処理の処理フローを示す図である。
図15は、閾値の算出について説明するための図である
図16は、VMの実行とリソース使用率との関係について説明するための図である。

実施例

0012

図1に、本実施の形態のシステム概要を示す。例えばインターネットであるネットワーク3には、情報処理システム1と、ユーザ端末5とが接続される。情報処理システム1は、複数の物理マシン10を有する。各物理マシン10は、ユーザ端末5から受信した要求に応じて仮想マシンの配備を実行する。

0013

図2に、物理マシン10のハードウエア構成図を示す。物理マシン10は、1又は複数のCPU151と、1又は複数のメモリ152と、1又は複数のI/O153と、1又は複数の記憶媒体154とを有する。I/O153は、例えば物理ポート等である。記憶媒体154は、不揮発性の記憶媒体である。CPU151とメモリ152とI/O153とは、バスによって接続される。

0014

本実施の形態の処理を実行するためのプログラムは、メモリ152にロードされてCPU151に実行され、図3に示す各種機能を実現する。図3に、物理マシン10の機能ブロック図を示す。物理マシン10は、受付部100と、実行制御部110と、管理部120と、VM実行部130と、VM実行部130によって実行される複数のVMとを含む。なお、ここでは1台の物理マシン10において上記機能が実現される例を示したが、複数台の物理マシン10において実現されてもよい。また、受付部100、実行制御部110、及び管理部120は、1又は複数の仮想マシンによって実現されてもよい。

0015

受付部100は、要求受付部101と、第1変更部102とを含む。

0016

要求受付部101は、VMを配備することを要求する配備要求をユーザ端末5から受信した場合、管理部120における配備部123に、オンデマンド命令によってVMの配備を指示する。また、要求受付部101は、VMを返却することを要求する返却要求をユーザ端末5から受信した場合、管理部120における配備部123に、オンデマンド命令によってVMの返却を指示する。オンデマンド命令は、OS種別の情報と、VM名と、VMの実行状態を示す情報と、リソースの情報(例えば、CPU、メモリ、ディスクサイズ、及びトラフィック量の情報など)と、IP(Internet Protocol)アドレスと、VM種別の情報とを含む。VMの配備時においてはVM種別は「オンラインVM」に設定される。上で述べたように、オンラインVMはリアルタイム処理を実行するVMであり、バッチVMはバッチ処理を実行するVMである。VM名は、ユーザが付けた名前である。VMの実行状態は、「実行中」、「一時停止」、及び「停止」のいずれかに設定される。「実行中」の場合はバッチVMに電源投入されており、「一時停止」及び「停止」の場合にはバッチVMに電源が投入されていない。但し、「一時停止」の場合にはバッチ処理に使用するデータが記憶媒体154に保存され、再起動時にはそのデータを用いてバッチ処理が再開される。なお、本実施の形態においては、バッチVMの実行状態は制御ブロックによって管理されるが、オンラインVMの実行状態は管理されない。

0017

第1変更部102は、VMの種別を変更することを要求する変更要求をユーザ端末5から受信した場合、変更要求の内容に応じて、種別変更処理部116にVM種別を変更させる。VMの種別は、オンラインVMからバッチVMへ変更されるか又はバッチVMからオンラインVMへ変更される。

0018

なお、リアルタイム処理の要求をユーザ端末5からいつ受信するかは不明であるため、特に昼間の時間帯においては、リアルタイム処理の性能を維持するためオンラインVMが稼働し続けていることが好ましい。本実施の形態においては、明示的な停止指示があるまで或いはスケジュールに従って停止されるまでは、オンラインVMの稼働は維持される。一方、バッチ処理の終了後においてはバッチVMを停止することが可能である。本実施の形態においては、バッチ処理を終了したバッチVMは原則として停止される。なお、バッチ処理の終了後においてバッチVMが消費するリソース量は比較的少ない。

0019

実行制御部110は、キュー管理部111と、制御キュー112と、リソース監視部113と、処理監視部114と、第2変更部115と、種別変更処理部116とを含む。

0020

キュー管理部111は、制御キュー112に格納される制御ブロックを管理する。また、キュー管理部111は、種別データ格納部121に格納されたデータを更新することを管理部120における種別管理部122に指示する。

0021

制御キュー112は、制御ブロックを格納する。図4に、制御ブロックの一例を示す。制御ブロックはバッチVMを管理するためのデータであり、OS種別の情報と、バッチVMのVM名と、バッチVMのVM識別子、バッチVMの実行状態を示す情報とを含む。VM識別子は、各VMに割り当てられる一意文字列である。

0022

リソース監視部113は、物理マシン10内のリソースの情報を管理部120から取得し、リソースの使用状況監視する。リソース監視部113が監視に使用する閾値εnは、ユーザによって固定値に設定されてもよいし、リソース監視部113によって動的に変更されてもよい。閾値εnは、CPU151及びメモリ152のそれぞれについて設定される。

0023

処理監視部114は、例えば定期的に、物理マシン10におけるVMの実行状態についての情報を管理部120から取得し、VMの実行状態を監視する。また、処理監視部114は、VMの実行状態に応じて、種別変更処理部116にVM種別を変更させる。

0024

第2変更部115は、例えば定期的に、VMが判定条件を満たすか判定を行い、判定の結果に応じて、種別変更処理部116にVM種別を変更させる。

0025

種別変更処理部116は、処理監視部114、第1変更部102、及び第2変更部115からの呼び出しに応じて、後で説明する第1の種別変更処理及び第2の種別変更処理を実行する。

0026

管理部120は、種別データ格納部121と、種別管理部122と、配備部123と、移動部124と、リソース変更部125と、状況管理部126と、仮想化管理部127とを含む。

0027

種別管理部122は、種別データ格納部121に格納されたデータを管理する。

0028

配備部123は、オンデマンド命令によってVMの配備を指示された場合、VMの配備についての実行指示をVM実行部130に送信する。また、配備部123は、オンデマンド命令によってVMの返却を指示された場合、VMの返却についての実行指示をVM実行部130に送信する。なお、配備部123は、配備完了時にVMにVM識別子を割り当て、VMのユーザにVM識別子を通知する。通知は、例えばメール或いは表示装置への表示等によって行われる。

0029

移動部124は、VMのマイグレーションについての実行指示をVM実行部130に送信する。VMのマイグレーションは、例えば、或る物理マシン10の処理負荷が閾値を超えた場合に実行される。

0030

リソース変更部125は、物理マシン10において実行されるVMに割り当てるリソース量(例えば、CPU数CPU使用率、メモリ量、ディスク容量、及びネットワーク数など)の変更についての実行指示をVM実行部130に送信する。

0031

状況管理部126は、物理マシン10におけるVMのリソース量の情報を、例えば定期的にVM実行部130から取得し、実行制御部110に送信する。

0032

仮想化管理部127は、VMの実行状態等を監視する処理を実行し、VMの実行状態等についての情報を実行制御部110に送信する。

0033

VM実行部130は、例えばハイパバイザである制御部131を含む。制御部131は、電源が投入されており実行可能なVMを実行する。制御部131は、管理部120から実行指示を受け付けた場合、実行指示に従いVMの配備、返却、及びマイグレーション等を実行する。制御部131は、VMによって使用されるリソースの情報を管理部120に送信する。

0034

図5に、種別データ格納部121に格納されるデータの一例を示す。図4の例では、VM識別子と、VM種別の情報とが格納される。

0035

次に、図6乃至図16を用いて、物理マシン10において実行される処理について説明する。まず、図6及び図7を用いて、種別変更処理部116が実行する第1の種別変更処理について説明する。本処理は、処理監視部114、第2変更部115、又は第1変更部102に呼び出されて実行される。

0036

本処理の対象となるVMのことを対象VMと呼ぶこととする。まず、種別変更処理部116は、対象VMのVM種別が「バッチVM」であるか判定する(図6:ステップS11)。対象VMのVM種別が「バッチVM」ではない場合(ステップS11:Noルート)、呼び出し元の処理に戻る。一方、対象VMのVM種別が「バッチVM」である場合(ステップS11:Yesルート)、種別変更処理部116は、キュー管理部111を介して、対象VMの制御ブロックにおけるVM種別を「バッチVM」から「オンラインVM」に変更する(ステップS13)。また、種別変更処理部116は、管理部120における種別管理部122に、対象VMのVM種別の変更を指示する。これに応じ、種別管理部122は、種別データ格納部121に格納された、対象VMのVM種別の情報を、「バッチVM」から「オンラインVM」に変更する。

0037

種別変更処理部116は、対象VMの制御ブロックにおける実行状態が「一時停止」であるか判定する(ステップS15)。対象VMの制御ブロックにおける実行状態が「一時停止」ではない場合(ステップS15:Noルート)、ステップS19の処理に移行する。一方、対象VMの制御ブロックにおける実行状態が「一時停止」である場合(ステップS15:Yesルート)、種別変更処理部116は、対象VMについて再開処理を実行する(ステップS17)。再開処理については、図7を用いて説明する。なお、再開処理は、バッチVMとして再開する処理とオンラインVMとして再開する処理とが有るが、ステップS17の再開処理については、対象VMがオンラインVMとして再開されるものとする。

0038

まず、種別変更処理部116は、管理部120を介して、VM実行部130に対象VMの再開を指示する再開指示を送信する(図7:ステップS21)。これに応じ、VM実行部130における制御部131は、対象VMに電源を投入し、対象VMをオンラインVMとして再開する。なお、オンラインVMとして再開する場合、制御部131は、対象VMに電源を投入し、一時停止前に記憶媒体154に保存したデータ(例えばコンテキストなど)によって対象VMに処理を再開させる。なお、VMの再開処理はよく知られた処理であるので、ここでは詳細な説明を省略する。

0039

種別変更処理部116は、対象VMの制御ブロックにおける実行状態を「一時停止」から「実行中」に変更する(ステップS23)。そして呼び出し元の処理に戻る。

0040

図6の説明に戻り、種別変更処理部116は、対象VMの制御ブロックを制御キュー112から取り出し、削除する(ステップS19)。そして呼び出し元の処理に戻る。

0041

次に、図8を用いて、種別変更処理部116が実行する第2の種別変更処理について説明する。本処理は、第2変更部115又は第1変更部102に呼び出されて実行される。

0042

まず、種別変更処理部116は、対象VMのVM種別が「オンラインVM」であるか判定する(図8:ステップS31)。対象VMのVM種別が「オンラインVM」ではない場合(ステップS31:Noルート)、呼び出し元の処理に戻る。一方、対象VMのVM種別が「オンラインVM」である場合(ステップS31:Yesルート)、種別変更処理部116は、キュー管理部111を介して、対象VMの制御ブロックにおけるVM種別を「オンラインVM」から「バッチVM」に変更する(ステップS33)。また、種別変更処理部116は、管理部120における種別管理部122に、対象VMのVM種別の変更を指示する。これに応じ、種別管理部122は、種別データ格納部121に格納された、対象VMのVM種別の情報を、「オンラインVM」から「バッチVM」に変更する。

0043

種別変更処理部116は、対象VMについて制御ブロックを生成する(ステップS35)。そして、種別変更処理部116は、生成した制御ブロックにおける実行状態を「実行中」に設定する(ステップS37)。ステップS37においてはOS種別、VM名及びVM識別子等も設定される。

0044

種別変更処理部116は、制御キュー112の最後尾に、対象VMについての制御ブロックを追加する(ステップS39)。そして呼び出し元の処理に戻る。

0045

次に、図9を用いて、処理監視部114が実行する処理について説明する。本処理は、例えば定期的に実行される。

0046

まず、処理監視部114は、制御キュー112に格納されている制御ブロックの数が1以上であるか判定する(図9:ステップS41)。

0047

制御キュー112に格納されている制御ブロックの数が1以上ではない場合(ステップS41:Noルート)、処理は終了する。一方、制御キュー112に格納されている制御ブロックの数が1以上である場合(ステップS41:Yesルート)、処理監視部114は、実行状態が「停止」であるVM(ここでは、バッチVM)についての制御ブロックが制御キュー112に有るか判定する(ステップS43)。

0048

実行状態が「停止」であるVMについての制御ブロックが制御キュー112に無い場合(ステップS43:Noルート)、処理は終了する。一方、実行状態が「停止」であるVMについての制御ブロックが制御キュー112に有る場合(ステップS43:Yesルート)、処理監視部114は、種別変更処理部116を呼び出す。これに応じ、種別変更処理部116は、実行状態が「停止」であるVMを対象として第1の種別変更処理を実行する(ステップS45)。第1の種別変更処理については、図6及び図7を用いて説明したとおりである。そして処理は終了する。

0049

以上のような処理を実行すれば、バッチ処理の完了をシステムにおいて検知して、バッチVMをオンラインVMに変更し、自動実行制御の対象から外すことができるようになる。なお、停止中のオンラインVMは、予め定められたスケジュールに従って又は起動指示に従って起動される。

0050

次に、図10を用いて、第2変更部115が実行する処理について説明する。本処理は、例えば定期的に実行される。なお、本処理は全VMについて実行されるが、説明を簡単にするため、ここでは1台のVM(以下、対象VMと呼ぶ)について処理を実行する場合を例にして説明する。

0051

まず、第2変更部115は、バッチVMの判定条件がユーザ或いは管理者によって設定されているか判定する(図10:ステップS51)。バッチVMの判定条件とは、稼働中のVMがバッチVMであるか判定するための条件である。本実施の形態においては、以下のような判定条件のうち少なくともいずれかを満たすVMをバッチVMであると判定する。

0052

(1)トラフィック量が所定値(例えば0)以下であるVM。トラフィック量が所定値以下であるVMは、バッチ処理であるサイレントインストール或いはコンパイル処理等を実行している可能性が高い。トラフィック量の情報は、状況管理部126から取得可能である。

0053

(2)ユーザからの入力を受け付けていないVM。ユーザからの入力を受け付けていないVMは、手動テスト、コーディング、環境構築、及びトラブル調査等についてのリアルタイム処理を実行していない(すなわち、バッチVMである)と考えられる。入力とは、例えばマウス又はキーボードによる入力である。ユーザからの入力は、例えば、マウス座標の変化及びキー入力を受け付けるためのエージェントソフトウエアをVMに導入することで検出される。

0054

(3)問いかけに対するユーザからの応答が検出されないVM。例えば、VMに導入したエージェントソフトウエアによって、ユーザへの問いかけを行う文字列をユーザ端末5に送信し、その問いかけに対する応答が検出されない場合にはバッチVMであると判定する。

0055

(4)特定のネットワークポート(例えば、ポート番号が22であるSSH(Secure SHell)のポート或いはポート番号が3389であるRDP(Remote Desktop Protocol)のポート)での通信確立していないVM。特定のネットワークポートでの通信が確立されているか否かは、例えば、OSのセッションを監視するエージェントソフトウエアをVMに導入することで判断することができる。

0056

バッチVMの判定条件がユーザ或いは管理者によって設定されていない場合(ステップS51:Noルート)、処理は終了する。一方、バッチVMの判定条件がユーザ或いは管理者によって設定されている場合(ステップS51:Yesルート)、第2変更部115は、対象VMが判定条件を満たすか判定する(ステップS52)。

0057

対象VMが判定条件を満たさない場合(ステップS52:Noルート)、第2変更部115は、種別変更処理部116に第1の種別変更処理の実行を指示する。これに応じ、種別変更処理部116は、第1の種別変更処理を実行する(ステップS54)。第1の種別変更処理については、図6及び図7を用いて説明したとおりであるので、説明を省略する。

0058

一方、対象VMが判定条件を満たす場合(ステップS52:Yesルート)、第2変更部115は、種別変更処理部116に第2の種別変更処理の実行を指示する。これに応じ、種別変更処理部116は、対象VMについて第2の種別変更処理を実行する(ステップS53)。第2の種別変更処理については、図8を用いて説明したとおりであるので、説明を省略する。そして処理は終了する。

0059

以上のような処理によれば、判定条件を満たすVMの種別を「バッチVM」に自動的に変更できる一方、リソース不足であると閾値によって判定された時点でバッチVMを一時停止し、リソースをオンラインVMで利用できるようになる。これにより、オンラインVMの応答性能劣化等を防止し、また、リソースを有効利用できるようになる。

0060

次に、図11を用いて、第1変更部102が実行する処理について説明する。

0061

まず、第1変更部102は、VMの種別を変更することを要求する変更要求をユーザ端末5から受信する(図11:ステップS55)。変更要求は、VM名又はVM識別子とVM種別の指定とを含む。

0062

第1変更部102は、変更要求においてバッチVMへの変更が指定されているか判定する(ステップS56)。変更要求においてバッチVMへの変更が指定されている場合(ステップS56:Yesルート)、第1変更部102は、種別変更処理部116に、第2の種別変更処理の実行を指示する。これに応じ、種別変更処理部116は、VM名又はVM識別子によって特定されるVMについて、第2の種別変更処理を実行する(ステップS57)。そして処理は終了する。第2の種別変更処理については、図8を用いて説明したとおりであるので、説明を省略する。

0063

一方、変更要求においてバッチVMへの変更が指定されていない場合(ステップS56:Noルート)、第1変更部102は、種別変更処理部116に、第1の種別変更指示の実行を指示する。これに応じ、種別変更処理部116は、第1の種別変更処理を実行する(ステップS58)。そして処理は終了する。第1の種別変更処理については、図6及び図7を用いて説明したとおりであるので、説明を省略する。

0064

以上のような処理を実行すれば、ユーザの意向に合わせてVM種別を変更できるようになる。

0065

次に、図12及び図13を用いて、リソース監視部113が実行する処理について説明する。本処理は、CPU151及びメモリ152について定期的に実行される。

0066

まず、リソース監視部113は、リソース使用率が閾値εn未満であるか判定する(図12:ステップS61)。リソース利用率が閾値εn未満ではない場合(ステップS61:Noルート)、リソース監視部113は、実行状態が「実行中」であるバッチVMについての制御ブロックが制御キュー112に有るか判断する(ステップS63)。

0067

実行状態が「実行中」であるバッチVMについての制御ブロックが制御キュー112に無い場合(ステップS63:Noルート)、処理は終了する。一方、実行状態が「実行中」であるバッチVM(以下、対象VMと呼ぶ)についての制御ブロックが制御キュー112に有る場合(ステップS63:Yesルート)、リソース監視部113は、一時停止処理を実行する(ステップS65)。一時停止処理については、図13を用いて説明する。

0068

まず、リソース監視部113、管理部120を介して、VM実行部130に対象VMの一時停止を指示する一時停止指示を送信する(図13:ステップS81)。これに応じ、VM実行部130における制御部131は、対象VMを一時停止する。具体的には、制御部131は、対象VMが使用するデータを記憶媒体154に保存し、対象VMの電源を切断する。なお、VMの一時停止処理はよく知られた処理であるので、ここでは詳細な説明を省略する。

0069

処理監視部114は、対象VMの制御ブロックにおける実行状態を「実行中」から「一時停止」に変更する(ステップS83)。そして呼び出し元の処理(図12)に戻り処理は終了する。

0070

一方、リソース利用率が閾値εn未満である場合(ステップS61:Yesルート)、リソース監視部113は、制御キュー112における制御ブロックの数が1以上であるか判定する(ステップS67)。制御ブロックの数が1以上ではない場合(ステップS67:Noルート)、処理は終了する。一方、制御ブロックの数が1以上である場合(ステップS67:Yesルート)、リソース監視部113は、実行状態が「一時停止」であるバッチVMについての制御ブロックが制御キュー112に格納されているか判定する(ステップS69)。

0071

実行状態が「一時停止」であるバッチVMについての制御ブロックが制御キュー112に格納されていない場合(ステップS69:Noルート)、処理は終了する。一方、実行状態が「一時停止」であるバッチVM(ここでは、対象VMと呼ぶ)についての制御ブロックが制御キュー112に格納されている場合(ステップS69:Yesルート)、リソース監視部113は、再開処理の実行を処理監視部114に指示する。これに応じ、処理監視部114は、対象VMについて再開処理を実行する(ステップS71)。そして処理は終了する。再開処理については、図7を用いて説明したとおりであるが、ステップS17の場合とは異なり、ここでは対象VMをバッチVMとして再開する処理を行う。

0072

以上のような処理を実行すれば、リソース使用率に応じてバッチVMの一時停止と再開とを適切に行えるので、リソースが不足してオンラインVMの処理性能が劣化することを抑制できるようになると共に、リソースを有効に活用できるようになる。

0073

次に、図14及び図15を用いて、閾値εnを算出する処理について説明する。本処理は、例えば定期的に実行される。

0074

まず、リソース監視部113は、物理マシン10内のリソースの情報を管理部120から取得する(図14:ステップS91)。

0075

リソース監視部113は、ステップS91において取得した情報に基づき閾値εnを算出する(ステップS93)。そして処理は終了する。ステップS93において算出された閾値εnは、図12及び図13を用いて説明した処理において使用される。

0076

図15を用いて、閾値εの算出について説明する。図15において、横軸tは時間を表し、縦軸Rはリソースの使用率(%)を表す。Rumaxは使用率の最大値であり、Roは全オンラインVMによるリソースの使用率である。kはサンプリング数、δはサンプリング間隔であり、Δ(=k*δ)は単位監視期間である。εmaxは閾値の上限であり、εminは閾値の下限である。Roの算出に使用される各オンラインVMのリソース使用率は、単位監視期間においてk回サンプリングされる。図15においては、サンプリング数k=5であり、サンプリング間隔δ=1である。

0077

閾値εnの初期値であるε1は、Rumaxの1/2である50とする。Δ1におけるサンプリング時刻t1乃至t5にてサンプリングが実行され、Roが算出される。Roが算出されると、Δ2についての閾値であるε2が算出される。なお、監視間隔Δnについての閾値εnは、以下の式によって与えられる。

0078

0079

よって、ε2は以下のようにして算出される。

0080

0081

ε2=40でありε1より小さいので、バッチVMが実行されにくくなる。

0082

このように、或る監視間隔Δnについて算出されたリソース使用率Roが閾値εnを超える場合、次の監視間隔Δn+1において使用する閾値εn+1の値が小さくなる。逆に、或る監視間隔Δnについて算出されたリソース使用率Roが閾値εnを超えない場合、次の監視間隔Δn+1において使用する閾値εn+1の値が大きくなる。

0083

これにより、オンラインVMのリソース使用率が日々大きく変動するために予測が困難な場合であっても適切な閾値を算出することができるようになる。

0084

なお、εmax及びεminを導入することで、極端に大きい又は小さいRoが算出された場合に閾値εnが不適切な値になることを抑制できるようになる。

0085

図16を用いて、VMの実行とリソース使用率との関係について説明する。図16において、横軸は時間を表し、縦軸はリソースの使用率を表す。破線は閾値を表す。最初の段階では、オンラインVMであるVM1とバッチVMであるVM2とが実行されているが、オンラインVMであるVM3の起動に伴い、リソース使用率が閾値を超えることが検出された。そこで、バッチVMであるVM2は一時停止される。VM3の起動後にVM4が起動し、リソースの使用率は閾値を超えるが、オンラインVMしか実行されていないので、VMの一時停止は行われない。VM3及びVM4が停止後、リソース使用率が閾値を下回ったため、VM2のバッチ処理が再開される。その後、VM2のバッチ処理が終了すると、VM2が停止する。一方、VM3及びVM4は、夜間の時間帯にはオンラインVMからバッチVMに変更され、バッチ処理を実行する。図16の例では、昼間の時間帯の閾値は50(%)であり、夜間の時間帯の閾値は80(%)である。

0086

以上本発明の一実施の形態を説明したが、本発明はこれに限定されるものではない。例えば、上で説明した物理マシン10の機能ブロック構成は実際のプログラムモジュール構成に一致しない場合もある。

0087

また、上で説明した各テーブルの構成は一例であって、上記のような構成でなければならないわけではない。さらに、処理フローにおいても、処理結果が変わらなければ処理の順番入れ替えることも可能である。さらに、並列に実行させるようにしても良い。

0088

以上述べた本発明の実施の形態をまとめると、以下のようになる。

0089

本実施の形態に係る制御方法は、(A)稼働中の仮想マシンがリアルタイム処理を実行する仮想マシン及びバッチ処理を実行する仮想マシンのいずれであるかの判定を行ない、(B)仮想マシンが実行する処理が終了した場合、判定の結果に基づいて、仮想マシンがバッチ処理を実行する仮想マシンである場合は仮想マシンを停止し、仮想マシンがリアルタイム処理を実行する仮想マシンである場合は仮想マシンの稼働を維持する処理を含む。

0090

このようにすれば、バッチ処理を実行する仮想マシンによってリソースが占有されることを抑制できるので、リソース不足によってリアルタイム処理の性能が低下することを抑制できるようになる。

0091

また、本制御方法は、(C)コンピュータ内のリソースの使用率が閾値を超えたか判定し、(D)コンピュータ内のリソースの使用率が閾値を超えており且つ仮想マシンがバッチ処理を実行する仮想マシンである場合、仮想マシンを一時停止する処理をさらに含んでもよい。このようにすれば、バッチ処理によりリソースが消費されることを抑制できるようになる。また、仮想マシンは一時停止されるので、仮想マシンがバッチ処理を後で再開することもできる。

0092

また、本制御方法は、(E)コンピュータ内のリソースの使用率が閾値を超えていない場合、一時停止中の他の仮想マシンの稼働を再開する処理をさらに含んでもよい。このようにすれば、リアルタイム処理の性能が劣化することを抑制しつつリソースを有効に利用できるようになる。

0093

また、本制御方法は、(F)仮想マシンの状態が所定の状態であるか判定し、(G)仮想マシンの状態が所定の状態であり且つ仮想マシンがリアルタイム処理を実行する仮想マシンである場合、仮想マシンをバッチ処理を実行する仮想マシンに変更する処理をさらに含んでもよい。このようにすれば、仮想マシンの種別を自動的に変更できるようになる。

0094

また、本制御方法は、(G)仮想マシンの状態が所定の状態ではなく且つ仮想マシンがバッチ処理を実行する仮想マシンである場合、仮想マシンをリアルタイム処理を実行する仮想マシンに変更する処理をさらに含んでもよい。このようにすれば、仮想マシンの種別を自動的に変更できるようになる。

0095

また、本制御方法は、(H)直近の所定期間におけるコンピュータ内のリソースの使用率に基づき、閾値を算出する処理をさらに含んでもよい。

0096

また、上で述べた所定の状態は、トラフィック量が所定値以下である状態、ユーザからの入力を受け付けていない状態、及び所定のポート番号のネットワークポートでの通信が確立していない状態の少なくともいずれかを含んでもよい。

0097

なお、上記方法による処理をプロセッサに行わせるためのプログラムを作成することができ、当該プログラムは、例えばフレキシブルディスクCD−ROM光磁気ディスク半導体メモリハードディスク等のコンピュータ読み取り可能な記憶媒体又は記憶装置に格納される。尚、中間的な処理結果はメインメモリ等の記憶装置に一時保管される。

0098

以上の実施例を含む実施形態に関し、さらに以下の付記を開示する。

0099

(付記1)
コンピュータに、
稼働中の仮想マシンがリアルタイム処理を実行する仮想マシン及びバッチ処理を実行する仮想マシンのいずれであるかの判定を行ない、
前記仮想マシンが実行する処理が終了した場合、前記判定の結果に基づいて、前記仮想マシンが前記バッチ処理を実行する仮想マシンである場合は前記仮想マシンを停止し、前記仮想マシンが前記リアルタイム処理を実行する仮想マシンである場合は前記仮想マシンの稼働を維持する、
処理を実行させるための制御プログラム

0100

(付記2)
前記コンピュータに、
前記コンピュータ内のリソースの使用率が閾値を超えたか判定し、
前記コンピュータ内のリソースの使用率が前記閾値を超えており且つ前記仮想マシンが前記バッチ処理を実行する仮想マシンである場合、前記仮想マシンを一時停止する、
処理をさらに実行させるための付記1記載の制御プログラム。

0101

(付記3)
前記コンピュータに、
前記コンピュータ内のリソースの使用率が前記閾値を超えていない場合、一時停止中の他の仮想マシンの稼働を再開する、
処理をさらに実行させるための付記2記載の制御プログラム。

0102

(付記4)
前記コンピュータに、
前記仮想マシンの状態が所定の状態であるか判定し、
前記仮想マシンの状態が前記所定の状態であり且つ前記仮想マシンが前記リアルタイム処理を実行する仮想マシンである場合、前記仮想マシンを前記バッチ処理を実行する仮想マシンに変更する、
処理をさらに実行させるための付記3記載の制御プログラム。

0103

(付記5)
前記コンピュータに、
前記仮想マシンの状態が前記所定の状態ではなく且つ前記仮想マシンが前記バッチ処理を実行する仮想マシンである場合、前記仮想マシンを前記リアルタイム処理を実行する仮想マシンに変更する、
処理をさらに実行させるための付記4記載の制御プログラム。

0104

(付記6)
前記コンピュータに、
直近の所定期間における前記コンピュータ内のリソースの使用率に基づき、前記閾値を算出する、
処理をさらに実行させるための付記2又は3記載の制御プログラム。

0105

(付記7)
前記所定の状態は、
トラフィック量が所定値以下である状態、ユーザからの入力を受け付けていない状態、及び所定のポート番号のネットワークポートでの通信が確立していない状態の少なくともいずれかを含む
付記4又は5記載の制御プログラム。

0106

(付記8)
コンピュータが、
稼働中の仮想マシンがリアルタイム処理を実行する仮想マシン及びバッチ処理を実行する仮想マシンのいずれであるかの判定を行ない、
前記仮想マシンが実行する処理が終了した場合、前記判定の結果に基づいて、前記仮想マシンが前記バッチ処理を実行する仮想マシンである場合は前記仮想マシンを停止し、前記仮想マシンが前記リアルタイム処理を実行する仮想マシンである場合は前記仮想マシンの稼働を維持する、
処理を実行する制御方法。

0107

(付記9)
稼働中の仮想マシンがリアルタイム処理を実行する仮想マシン及びバッチ処理を実行する仮想マシンのいずれであるかの判定を行なう判定部と、
前記仮想マシンが実行する処理が終了した場合、前記判定の結果に基づいて、前記仮想マシンが前記バッチ処理を実行する仮想マシンである場合は前記仮想マシンを停止し、前記仮想マシンが前記リアルタイム処理を実行する仮想マシンである場合は前記仮想マシンの稼働を維持する制御部と、
を有する情報処理装置

0108

1情報処理システム3ネットワーク
5ユーザ端末10物理マシン
151 CPU 152メモリ
153 I/O 154記憶媒体
100 受付部 101要求受付部
102 第1変更部 110実行制御部
111キュー管理部112制御キュー
113リソース監視部 114処理監視部
115 第2変更部 116種別変更処理部
120 管理部 121種別データ格納部
122 種別管理部 123配備部
124 移動部 125リソース変更部
126 状況管理部 127仮想化管理部
130 VM実行部 131 制御部

ページトップへ

この技術を出願した法人

この技術を発明した人物

ページトップへ

関連する挑戦したい社会課題

該当するデータがありません

関連する公募課題

該当するデータがありません

ページトップへ

技術視点だけで見ていませんか?

この技術の活用可能性がある分野

分野別動向を把握したい方- 事業化視点で見る -

(分野番号表示ON)※整理標準化データをもとに当社作成

ページトップへ

おススメ サービス

おススメ astavisionコンテンツ

新着 最近 公開された関連が強い技術

この 技術と関連性が強い技術

関連性が強い 技術一覧

この 技術と関連性が強い人物

関連性が強い人物一覧

この 技術と関連する社会課題

該当するデータがありません

この 技術と関連する公募課題

該当するデータがありません

astavision 新着記事

サイト情報について

本サービスは、国が公開している情報(公開特許公報、特許整理標準化データ等)を元に構成されています。出典元のデータには一部間違いやノイズがあり、情報の正確さについては保証致しかねます。また一時的に、各データの収録範囲や更新周期によって、一部の情報が正しく表示されないことがございます。当サイトの情報を元にした諸問題、不利益等について当方は何ら責任を負いかねることを予めご承知おきのほど宜しくお願い申し上げます。

主たる情報の出典

特許情報…特許整理標準化データ(XML編)、公開特許公報、特許公報、審決公報、Patent Map Guidance System データ