(57)【要約】【課題】所属希望の優先度グループに空きがない場合であっても、より確実にＶＭの性能保証を実現しつつ、リソース利用効率を高める。【解決手段】ＶＭ優先度制御システム１００の物理サーバ１０は、ＶＭのリソース利用量およびＶＭの所属する優先度グループが記憶された優先度グループ設定情報を、コントローラ２０に送信する。コントローラ２０は、取得したリソース利用量に基づき各ＶＭの所属希望の優先度グループを決定するとともに、空き所属についてダミーのＶＭを生成し、各ＶＭの性能保証が実現できるか否かを判定する。また、コントローラ２０は、各ＶＭおよびダミーのＶＭについての現所属の優先度グループと所属希望の優先度グループの組に関し、所属する優先度グループが対となる組との間で、現所属の優先度グループを交換して新たな現所属の優先度グループを決定する。【選択図】図１
2019204305.tif 000002
【特許請求の範囲】
【請求項１】
複数のＶＭ（Virtual Machine）を稼働させる物理サーバと、前記物理サーバに接続され、前記ＶＭの稼働状態を管理するコントローラとを備えるＶＭ優先度制御システムであって、
前記物理サーバは、
当該物理サーバが有する物理リソースを複数のグループに分割し、当該分割したグループそれぞれに共有できるＶＭ数である所属可能数を異なるように設定して、前記共有できるＶＭ数が少ないほど優先度が高い優先度グループとし、前記優先度グループそれぞれとその優先度グループの物理リソース上で稼働させるＶＭとの対応関係を格納する優先度グループ設定情報が記憶される記憶部と、
前記ＶＭそれぞれが稼働する際のリソース利用量を収集し、前記コントローラに送信するリソース利用量収集部と、
前記優先度グループ設定情報を、前記コントローラに送信する優先度グループ設定情報送信部と、
前記ＶＭそれぞれに対する前記優先度グループの変更指示を示す優先度グループ設定変更情報を前記コントローラから受信すると、前記優先度グループ設定情報を参照し、当該ＶＭが属する優先度グループを新たな優先度グループに変更する優先度グループ変更部と、を備え、
前記コントローラは、
前記物理サーバから前記ＶＭそれぞれのリソース利用量および前記優先度グループ設定情報を取得するデータ取得部と、
各ＶＭが所定の第１の閾値未満の性能である性能不足および所定の第２の閾値以上の性能である性能過多とならないような所属先となる所属希望の優先度グループを、各ＶＭの前記リソース利用量を用いて、各ＶＭが優先度グループそれぞれに所属した場合の性能値を算出することにより決定するとともに、前記優先度グループ設定情報を参照し、各優先度グループのＶＭの所属可能数から現所属のＶＭの数を減じた空き所属数を算出し、前記空き所属数分のダミーのＶＭを当該空きのある優先度グループに所属するものとして生成し、生成した前記ダミーのＶＭに関する所属希望の優先度グループを最も優先度の低い優先度グループとして決定する所属希望グループ決定部と、
各ＶＭの現所属の優先度グループと、決定された前記所属希望の優先度グループとの情報を用いて、所定の性能保証可否判定ロジックに基づき、各ＶＭの性能保証が実現できるか否かを判定する性能保証可否判定部と、
前記性能保証が実現できると判定された場合に、各ＶＭおよび前記ダミーのＶＭについての前記現所属の優先度グループと前記所属希望の優先度グループの組に関し、所属する優先度グループの対が反対であり入れ替えると一致する所属関係となる前記組との間で、現所属の優先度グループを交換することで得られる優先度グループを新たな現所属の優先度グループとして決定し、決定した前記新たな現所属の優先度グループの情報を含む前記優先度グループ設定変更情報を生成し前記物理サーバに送信する優先度変更先決定部と、
を備えることを特徴とするＶＭ優先度制御システム。
【請求項２】
前記所定の性能保証可否判定ロジックは、前記優先度グループの優先度について、優先度の高い方から昇順の優先順位とし、以下の（条件１）かつ（条件２）を満たすこと
Σ（所属希望の優先度グループの優先順位 − 現所属の優先度グループの優先順位） ≦ ０  ・・・（条件１）、
優先順位ａの優先度グループを希望するＶＭ数 ≦ 優先順位ａ以上の優先度グループでのＶＭの所属可能総数  ・・・（条件２）
（ａは、すべての優先順位のうちの任意の優先順位を示す）
を特徴とする請求項１に記載のＶＭ優先度制御システム。
【請求項３】
前記優先度変更先決定部は、前記現所属の優先度グループと前記所属希望の優先度グループの組に関し、前記所属する優先度グループの対が反対であり入れ替えると一致する所属関係となる組がない場合に、前記ダミーのＶＭのうち、その現所属の優先度グループが、前記所属する優先度グループの対が反対であり入れ替えると一致する所属関係となる組がないＶＭにおける所属希望の優先度グループの優先度以上である前記ダミーのＶＭを特定し、前記特定したダミーのＶＭの現所属の優先度グループと、前記所属する優先度グループの対が反対であり入れ替えると一致する所属関係となる組がないＶＭの現所属の優先度グループとを交換することで得られる優先度グループを前記新たな現所属の優先度グループとして決定すること
を特徴とする請求項１または請求項２に記載のＶＭ優先度制御システム。
【請求項４】
複数のＶＭを稼働させる物理サーバと、前記物理サーバに接続され、前記ＶＭの稼働状態を管理するコントローラとを備えるＶＭ優先度制御システムのＶＭ優先度制御方法であって、
前記物理サーバは、
当該物理サーバが有する物理リソースを複数のグループに分割し、当該分割したグループそれぞれに共有できるＶＭ数である所属可能数を異なるように設定して、前記共有できるＶＭ数が少ないほど優先度が高い優先度グループとし、前記優先度グループそれぞれとその優先度グループの物理リソース上で稼働させるＶＭとの対応関係を格納する優先度グループ設定情報が記憶される記憶部を備えており、
前記ＶＭそれぞれが稼働する際のリソース利用量を収集し、前記コントローラに送信するステップと、
前記優先度グループ設定情報を、前記コントローラに送信するステップと、を実行し、
前記コントローラは、
前記物理サーバから前記ＶＭそれぞれのリソース利用量および前記優先度グループ設定情報を取得するステップと、
各ＶＭが所定の第１の閾値未満の性能である性能不足および所定の第２の閾値以上の性能である性能過多とならないような所属先となる所属希望の優先度グループを、各ＶＭの前記リソース利用量を用いて、各ＶＭが優先度グループそれぞれに所属した場合の性能値を算出することにより決定するとともに、前記優先度グループ設定情報を参照し、各優先度グループのＶＭの所属可能数から現所属のＶＭの数を減じた空き所属数を算出し、前記空き所属数分のダミーのＶＭを当該空きのある優先度グループに所属するものとして生成し、生成した前記ダミーのＶＭに関する所属希望の優先度グループを最も優先度の低い優先度グループとして決定するステップと、
各ＶＭの現所属の優先度グループと、決定された前記所属希望の優先度グループとの情報を用いて、所定の性能保証可否判定ロジックに基づき、各ＶＭの性能保証が実現できるか否かを判定するステップと、
前記性能保証が実現できると判定された場合に、各ＶＭおよび前記ダミーのＶＭについての前記現所属の優先度グループと前記所属希望の優先度グループの組に関し、所属する優先度グループの対が反対であり入れ替えると一致する所属関係となる前記組との間で、現所属の優先度グループを交換することで得られる優先度グループを新たな現所属の優先度グループとして決定し、決定した前記新たな現所属の優先度グループの情報を含む優先度グループ設定変更情報を生成し前記物理サーバに送信するステップと、を実行し、
前記物理サーバは、
前記優先度グループ設定変更情報を前記コントローラから受信すると、前記優先度グループ設定情報を参照し、前記新たな現所属の優先度グループが示されたＶＭについて、その優先度グループを新たな優先度グループに変更するステップを実行すること
を特徴とするＶＭ優先度制御方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワーク仮想化技術を用いて、物理マシン上で共有される各ＶＭ（Virtual Machine：仮想マシン）の性能を保証するように各ＶＭの優先度を制御する、ＶＭ優先度制御システムおよびＶＭ優先度制御方法に関する。
【背景技術】
【０００２】
物理サーバ上で複数のＶＭを稼働させる一般的な仮想化環境では、サーバリソースは全ＶＭで共有される。そして、その共有の仕方は、ハイパーバイザおよびホストＯＳ（Operating System）のスケジューラに一任され、制御することができない。仮想化環境として広く用いられているOpenStackでも、例えば物理ＣＰＵ（ｐＣＰＵ）は物理サーバ上の全ＶＭに共有される。
【０００３】
一方、ＶＭを専用の物理ＣＰＵ（ＣＰＵコア）に固定化（ピニング）する技術が開示されている（非特許文献１）。
【０００４】
上記のような従来技術では、物理サーバ上の複数のＶＭを、どの物理ＣＰＵで稼働させるかに関し、共有の程度を制御することはできない。このため、ネットワーク機能としてサービスの性能保証が求められる場合において、OpenStackをはじめとする仮想化環境では特に制御を行わないと、リソースが制御できない形で共有されてしまいＶＭの性能保証を行うことができなかった。
また、リソースを占有して固定的にＶＭを割り当てる手法を用いてしまうと、仮想化本来のメリットである柔軟な構成を用いることや、リソースの有効活用ができないという結果となる。
【０００５】
このような問題に対し、リソースの利用効率を高めつつ、ＶＭの性能保証を実現することができるシステム（後記する図１８の「ＶＭ性能保証システム１００ａ」）が提案されている（非特許文献２参照）。
【０００６】
非特許文献２に記載のシステム（ＶＭ性能保証システム１００ａ）は、複数のＶＭを備える物理サーバ（コンピュート）と、コントローラとを備えて構成される。このＶＭ性能保証システム１００ａでは、物理リソースを複数のグループに分割し、共有できるＶＭ数の異なる優先度グループを定義しておく。そして、コントローラが、ＶＭのリソース利用量に基づき、性能不足もしくは性能過多と判定した場合に、物理サーバにおいて、そのＶＭの優先度グループを変更する。これにより、物理サーバの物理リソースを有効活用した上で、ＶＭの性能保証を実現することができる。
【先行技術文献】
【非特許文献】
【０００７】
【非特許文献１】「Red Hat OpenStack Platform  インスタンス＆イメージガイド  第４章  ＮＵＭＡノードを使用するＣＰＵピニングの設定」、［online］、Red Hat、［平成30年5月1日検索］、インターネット＜ＵＲＬ：https://access.redhat.com/documentation/ja-jp/red_hat_openstack_platform/9/html/instances_and_images_guide/ch-cpu_pinning＞
【非特許文献２】伊藤義人、「ＶＮＦ性能保証システムのプロトタイプ実装」、［online］、社団法人電子情報通信学会、第１５回ネットワークソフトウェア研究会のＷｅｂサイトにて2018年1月12日に講演原稿を掲載、インターネット＜http://www.ieice.org/cs/ns/nws/20180118_nwspaper.zip＞（特願2018-044010にて新規性喪失の例外を申請）
【発明の概要】
【発明が解決しようとする課題】
【０００８】
非特許文献２に記載された技術によれば、リソース利用効率を高めつつ、ＶＭの性能保証を実現することが可能となる。しかしながら、以下に示す点において、さらに改善する余地があった。
非特許文献２に記載のＶＭ性能保証システム１００ａにおいて、ＶＭのリソース共有数の異なる優先度グループでは、リソース利用効率を高めるため、または、ＶＭの性能保証を実現するために、ＶＭの所属するグループを変更する。その際、変更先となる優先度グループに空きがあることが必要となる。一方、リソースの効率利用の観点から、優先度グループの空きが最小となるようにＶＭは物理サーバに配置されるため、ＶＭを変更できる十分な空きが存在しないケースが生じる。よって、ＶＭが所属する優先度グループを変更する際に、新たに所属を希望する（所属候補の）優先度グループに空きがない場合であっても、ＶＭの性能保証を実現した上で各ＶＭの所属グループを調整して所属させることが必要となる。
【０００９】
このような点を鑑みて本発明がなされたのであり、本発明は、所属希望（所属候補）の優先度グループに空きがない場合であっても、より確実にＶＭの性能保証を実現しつつ、リソース利用効率の高めることができる、ＶＭ優先度制御システムおよびＶＭ優先度制御方法を提供することを課題とする。
【課題を解決するための手段】
【００１０】
前記した課題を解決するため、請求項１に記載の発明は、複数のＶＭ（Virtual Machine）を稼働させる物理サーバと、前記物理サーバに接続され、前記ＶＭの稼働状態を管理するコントローラとを備えるＶＭ優先度制御システムであって、前記物理サーバが、当該物理サーバが有する物理リソースを複数のグループに分割し、当該分割したグループそれぞれに共有できるＶＭ数である所属可能数を異なるように設定して、前記共有できるＶＭ数が少ないほど優先度が高い優先度グループとし、前記優先度グループそれぞれとその優先度グループの物理リソース上で稼働させるＶＭとの対応関係を格納する優先度グループ設定情報が記憶される記憶部と、前記ＶＭそれぞれが稼働する際のリソース利用量を収集し、前記コントローラに送信するリソース利用量収集部と、前記優先度グループ設定情報を、前記コントローラに送信する優先度グループ設定情報送信部と、前記ＶＭそれぞれに対する前記優先度グループの変更指示を示す優先度グループ設定変更情報を前記コントローラから受信すると、前記優先度グループ設定情報を参照し、当該ＶＭが属する優先度グループを新たな優先度グループに変更する優先度グループ変更部と、を備え、前記コントローラが、前記物理サーバから前記ＶＭそれぞれのリソース利用量および前記優先度グループ設定情報を取得するデータ取得部と、各ＶＭが所定の第１の閾値未満の性能である性能不足および所定の第２の閾値以上の性能である性能過多とならないような所属先となる所属希望の優先度グループを、各ＶＭの前記リソース利用量を用いて、各ＶＭが優先度グループそれぞれに所属した場合の性能値を算出することにより決定するとともに、前記優先度グループ設定情報を参照し、各優先度グループのＶＭの所属可能数から現所属のＶＭの数を減じた空き所属数を算出し、前記空き所属数分のダミーのＶＭを当該空きのある優先度グループに所属するものとして生成し、生成した前記ダミーのＶＭに関する所属希望の優先度グループを最も優先度の低い優先度グループとして決定する所属希望グループ決定部と、各ＶＭの現所属の優先度グループと、決定された前記所属希望の優先度グループとの情報を用いて、所定の性能保証可否判定ロジックに基づき、各ＶＭの性能保証が実現できるか否かを判定する性能保証可否判定部と、前記性能保証が実現できると判定された場合に、各ＶＭおよび前記ダミーのＶＭについての前記現所属の優先度グループと前記所属希望の優先度グループの組に関し、所属する優先度グループの対が反対であり入れ替えると一致する所属関係となる前記組との間で、現所属の優先度グループを交換することで得られる優先度グループを新たな現所属の優先度グループとして決定し、決定した前記新たな現所属の優先度グループの情報を含む前記優先度グループ設定変更情報を生成し前記物理サーバに送信する優先度変更先決定部と、を備えることを特徴とするＶＭ優先度制御システムとした。
【００１１】
また、請求項４に記載の発明は、複数のＶＭを稼働させる物理サーバと、前記物理サーバに接続され、前記ＶＭの稼働状態を管理するコントローラとを備えるＶＭ優先度制御システムのＶＭ優先度制御方法であって、前記物理サーバが、当該物理サーバが有する物理リソースを複数のグループに分割し、当該分割したグループそれぞれに共有できるＶＭ数である所属可能数を異なるように設定して、前記共有できるＶＭ数が少ないほど優先度が高い優先度グループとし、前記優先度グループそれぞれとその優先度グループの物理リソース上で稼働させるＶＭとの対応関係を格納する優先度グループ設定情報が記憶される記憶部を備えており、前記ＶＭそれぞれが稼働する際のリソース利用量を収集し、前記コントローラに送信するステップと、前記優先度グループ設定情報を、前記コントローラに送信するステップと、を実行し、前記コントローラが、前記物理サーバから前記ＶＭそれぞれのリソース利用量および前記優先度グループ設定情報を取得するステップと、各ＶＭが所定の第１の閾値未満の性能である性能不足および所定の第２の閾値以上の性能である性能過多とならないような所属先となる所属希望の優先度グループを、各ＶＭの前記リソース利用量を用いて、各ＶＭが優先度グループそれぞれに所属した場合の性能値を算出することにより決定するとともに、前記優先度グループ設定情報を参照し、各優先度グループのＶＭの所属可能数から現所属のＶＭの数を減じた空き所属数を算出し、前記空き所属数分のダミーのＶＭを当該空きのある優先度グループに所属するものとして生成し、生成した前記ダミーのＶＭに関する所属希望の優先度グループを最も優先度の低い優先度グループとして決定するステップと、各ＶＭの現所属の優先度グループと、決定された前記所属希望の優先度グループとの情報を用いて、所定の性能保証可否判定ロジックに基づき、各ＶＭの性能保証が実現できるか否かを判定するステップと、前記性能保証が実現できると判定された場合に、各ＶＭおよび前記ダミーのＶＭについての前記現所属の優先度グループと前記所属希望の優先度グループの組に関し、所属する優先度グループの対が反対であり入れ替えると一致する所属関係となる前記組との間で、現所属の優先度グループを交換することで得られる優先度グループを新たな現所属の優先度グループとして決定し、決定した前記新たな現所属の優先度グループの情報を含む優先度グループ設定変更情報を生成し前記物理サーバに送信するステップと、を実行し、前記物理サーバが、前記優先度グループ設定変更情報を前記コントローラから受信すると、前記優先度グループ設定情報を参照し、前記新たな現所属の優先度グループが示されたＶＭについて、その優先度グループを新たな優先度グループに変更するステップを実行することを特徴とするＶＭ優先度制御方法とした。
【００１２】
このようにすることで、ＶＭ優先度制御システムは、優先度グループの空き所属数分をダミーのＶＭとし、性能不足および性能過多とならないような所属希望の優先度グループを決定する。そして、ＶＭ優先度制御システムは、性能保証を実現できると判定した上で、ダミーのＶＭも含めた他のＶＭとの間で所属先を調整することにより、現所属の優先度グループを所属希望の優先度グループに変更することができる。よって、より確実にＶＭの性能保証を実現しつつ、リソース利用効率を高めることが可能となる。
【００１３】
請求項２に記載の発明は、前記所定の性能保証可否判定ロジックが、前記優先度グループの優先度について、優先度の高い方から昇順の優先順位とし、以下の（条件１）かつ（条件２）を満たすこと
Σ（所属希望の優先度グループの優先順位 − 現所属の優先度グループの優先順位） ≦ ０  ・・・（条件１）、
優先順位ａの優先度グループを希望するＶＭ数 ≦ 優先順位ａ以上の優先度グループでのＶＭの所属可能総数  ・・・（条件２）
（ａは、すべての優先順位のうちの任意の優先順位を示す）
を特徴とする請求項１に記載のＶＭ優先度制御システムとした。
【００１４】
このように、性能保証可否判定ロジックを、（条件１）かつ（条件２）を満たすものとすることで、現所属の優先度グループを所属希望の優先度グループに変更した場合であっても、各ＶＭの性能保証が実現できると確実に判定することができる。
【００１５】
請求項３に記載の発明は、前記優先度変更先決定部が、前記現所属の優先度グループと前記所属希望の優先度グループの組に関し、前記所属する優先度グループの対が反対であり入れ替えると一致する所属関係となる組がない場合に、前記ダミーのＶＭのうち、その現所属の優先度グループが、前記所属する優先度グループの対が反対であり入れ替えると一致する所属関係となる組がないＶＭにおける所属希望の優先度グループの優先度以上である前記ダミーのＶＭを特定し、前記特定したダミーのＶＭの現所属の優先度グループと、前記所属する優先度グループの対が反対であり入れ替えると一致する所属関係となる組がないＶＭの現所属の優先度グループとを交換することで得られる優先度グループを前記新たな現所属の優先度グループとして決定することを特徴とする請求項１または請求項２に記載のＶＭ優先度制御システムとした。
【００１６】
このようにすることで、現所属の優先度グループと所属希望の優先度グループの組に関し、対（所属する優先度グループの対が反対であり入れ替えると一致する所属関係）となる組がない場合であっても、性能保証を実現した上で、より確実に所属先の新たな優先度グループを決定するように調整することが可能となる。
【発明の効果】
【００１７】
本発明によれば、所属希望の優先度グループに空きがない場合であっても、より確実にＶＭの性能保証を実現しつつ、リソース利用効率の高める、ＶＭ優先度制御システムおよびＶＭ優先度制御方法を提供することができる。
【図面の簡単な説明】
【００１８】
【図１】本実施形態に係るＶＭ優先度制御システムを構成する物理サーバおよびコントローラの機能ブロック図である。
【図２】本実施形態に係る所属希望グループ決定部が実行する所属希望グループ決定処理の流れを示すフローチャートである。
【図３】本実施形態に係る優先度グループ状態情報のデータ構成例を示す図である。
【図４】本実施形態に係るＶＭ状態情報のデータ構成例（初期設定）を示す図である。
【図５】本実施形態に係るＶＭ状態情報（ダミーのＶＭの設定）のデータ構成例を示す図である。
【図６】本実施形態に係るＶＭ状態情報（リソース利用量と性能値の取り込み）のデータ構成例を示す図である。
【図７】本実施形態に係る所属希望グループ決定部による、降格グループ探索と昇格グループ探索の結果を示す図である。
【図８】本実施形態に係るＶＭ状態情報（所属希望の決定）のデータ構成例を示す図である。
【図９】本実施形態に係るＶＭ状態情報（変更先の決定（処理１））のデータ構成例を示す図である。
【図１０】本実施形態に係るＶＭ状態情報（ステータス「完了」）のデータ構成例を示す図である。
【図１１】本実施形態に係るＶＭ状態情報（変更先の決定（処理２））のデータ構成例を示す図である。
【図１２】本実施形態に係るＶＭ優先度制御システムが実行する全体の処理の流れを示すフローチャートである。
【図１３】ＶＭの負荷が増大した場合に、リソース割当を増やす従来の手法を説明するための図である。
【図１４】ＶＭの負荷が増大した場合に、共有するＶＭ数を変更する処理を説明するための図である。
【図１５】物理サーバにおいて、リソースを優先度の異なるグループに分割することを説明するための図である。
【図１６】優先度グループの変更処理を説明するための図である。
【図１７】優先度グループの変更により、ＶＭの性能保証が実現することを説明するための図である。
【図１８】ＶＭ性能保証システムを構成する物理サーバおよびコントローラの機能ブロック図である。
【発明を実施するための形態】
【００１９】
本発明を実施するための形態（以下、「本実施形態」という。）について説明する前に、本発明の前提となるシステム（ＶＭ性能保証システム１００ａ）を比較例として説明する。
【００２０】
＜比較例＞
本発明の比較例であるＶＭ性能保証システム１００ａは、後記する図１８で示すように、複数のＶＭ１を備える物理サーバ１０ａ（コンピュート）と、コントローラ２０ａとを備えて構成される。そして、このＶＭ性能保証システム１００ａは、物理サーバ１０ａの利用効率を高めつつ、ＶＭ１の性能保証を実現するため、以下に示す技術的特徴を備える。
【００２１】
従来、図１３に示すように、例えば、１つの物理リソース（ＣＰＵコア：図１３の●印）に１つのＶＭ１（図１３では１つのＶＭ１に２つの仮想ＣＰＵ（図１３の〇印）を備える。）が稼働する状況において、ＶＭ１の負荷が増大した場合、物理リソースの割り当てを増やす、つまり、ＣＰＵコアを追加しＶＭ１へのリソース割当量を変更することにより、ＶＭ１の性能低下を防いでいた。具体的には、図１３の左図のＶＭ１の負荷が増大した場合、図１３の右図に示すように、例えば、ＣＰＵコアを増加し、１つの仮想ＣＰＵに１つの物理リソース（ＣＰＵコア）を割り当てる制御を行っていた。
【００２２】
これに対し、ＶＭ性能保証システム１００ａでは、図１４に示すように、２つの物理リソース（ＣＰＵコア）を２つのＶＭ１が共有する状況において、ＶＭ１の負荷が増大した場合に、物理リソースに割り当てるＶＭの数を変更することにより、ＶＭ１の性能低下を防ぐようにする。図１４では、物理リソースに共有するＶＭ１の数を「２」から「１」に変更する制御を行う（図１４の右図参照）。
つまり、ＶＭ１のリソース割当量を変更するのではなく、有限な物理リソース（ＣＰＵコア）に対して、割り当てるＶＭ数を制御する。
【００２３】
また、ＶＭ性能保証システム１００ａの物理サーバ１０ａでは、有限の物理リソース（ＣＰＵコア）を優先度の異なるグループに分割しておく（図１５参照）。そして、各ＶＭ１のリソース利用量から計算されるＶＭ１の性能推定値（性能値）に基づき、性能不足のＶＭ１は、高優先のグループに所属させるように所属先を変更する。また、性能過多のＶＭ１は、低優先のグループに所属させるように所属先を変更する。このように、ＶＭ性能保証システム１００ａでは、各ＶＭ１について計算される性能推定値に基づき、どの優先度のグループに所属させるかを判断して所属先の優先度グループを変更する。
【００２４】
この優先度グループは、物理リソースに対するＶＭ１の共有数（ＶＭ数）が異なるグループとして定義される。具体的には、オーバーコミット率の異なるＣＰＵピニングパターンのグループに、物理リソースを分割しておく。そして、ＶＭ１の負荷に応じて、オーバーコミット率の異なる優先度グループ（ＣＰＵピニングパターン）を動的に変更する。高負荷時はオーバーコミット率の小さい（高優先）パターンでＣＰＵを占有（固定化）し、低負荷時はオーバーコミット率の大きい（低優先）パターンでＣＰＵを占有する。これにより、所定値以上の性能を保証しながら、物理リソースの利用効率を高めることができる。
【００２５】
例えば、図１６に示すように、優先度の最も高いグループとして「優先度［１］のグループ」を設定する。この「優先度［１］のグループ」は、分割した有限の物理リソース（ここでは、２つのＣＰＵコア）に、ＶＭ数が「２」、つまり２つのＶＭ１まで共有できる設定のオーバーコミット率の小さい（高優先）のパターンである。次の「優先度［２］のグループ」は、分割した有限の物理リソース（２つのＣＰＵコア）に、ＶＭ数が「４」まで共有できるグループである。次の「優先度［３］のグループ」は、分割した有限の物理リソース（２つのＣＰＵコア）に、ＶＭ数が「８」まで共有できるグループである。そして、「優先度［４］のグループ」は、分割した有限の物理リソース（２つのＣＰＵコア）に、ＶＭ数が「１６」まで共有できる設定のオーバーコミット率の大きい（低優先）のパターンである。
【００２６】
ＶＭ性能保証システム１００ａでは、例えば、図１７に示すように、最初は、ＶＭ数「１６」の「優先度［４］のグループ」に所属していたＶＭ１が、その性能が低下し、予めユーザとの間で取り決めがなされたＳＬＡ（Service Level Agreement：サービス品質保証）で示される性能値に所定値以上近づいた場合（性能不足に至る状況の場合）に、所属グループをより高優先でオーバーコミット率の小さい「優先度［３］のグループ」（共有できるＶＭ数「８」）に変更する。そのＶＭ１について、その後さらに性能が低下し、ＳＬＡで示される性能値に所定値以上近づいた場合には、同様に、所属グループを「優先度［２］のグループ」（共有できるＶＭ数「４」）、「優先度［１］のグループ」（共有できるＶＭ数「２」）のように、より高優先でオーバーコミット率の小さいグループに変更する。このようにすることにより、ＶＭ１の性能保証を実現することができる。
また、ＶＭ性能保証システム１００ａでは、性能に余裕がある場合には（性能過多の場合）には、そのＶＭ１の所属グループをより低優先でオーバーコミット率の大きいグループに変更する。このようにすることで、物理リソース（ＣＰＵコア）の利用効率を高めることができる。
【００２７】
＜比較例であるＶＭ性能保証システムの構成＞
次に、本発明の比較例であるＶＭ性能保証システム１００ａの構成について説明する。
図１８は、ＶＭ性能保証システム１００ａを構成する物理サーバ１０ａおよびコントローラ２０ａの機能ブロック図である。物理サーバ１０ａとコントローラ２０ａは、通信ネットワークを介して接続される。ここでは、１台の物理サーバ１０ａ上に、仮想ルータとして機能するＶＭ１が複数配置されるものとして説明する。
【００２８】
≪物理サーバ１０ａ≫
物理サーバ１０ａは、自身の物理サーバ上に複数のＶＭ１（仮想マシン）を設定する機能（コンピュートとしての機能）を有する。各ＶＭ１は、ＳＬＡ等で規定される性能（例えば、パケット転送の遅延（レイテンシ）やスループット等）を満たすことが求められる。
この物理サーバ１０ａは、自身が備える物理リソース（例えば、ＣＰＵコア）を優先度の異なる複数のグループに分割しておき、その分割された物理リソース毎に、ＶＭ１の共有数（ＶＭ数）が異なるグループを定義しておく。そして、物理サーバ１０ａは、ＶＭ１の負荷に応じて、そのＶＭ１の優先度グループをオーバーコミット率の異なる他の優先度グループに変更する。
【００２９】
この物理サーバ１０ａは、ＶＭ１を生成する機能（図示省略）を備えるとともに、リソース利用量収集部１１、優先度グループ定義部１２、優先度グループ変更部１３、優先度グループ設定情報１４を備える。
【００３０】
リソース利用量収集部１１は、各ＶＭ１のリソース利用量（ＣＰＵ使用量、メモリ使用量、パケット送受信数等）を収集する。そして、リソース利用量収集部１１は、収集した各ＶＭ１のリソース利用量の情報を、コントローラ２０ａに送信する。
なお、リソース利用量収集部１１は、コントローラ２０ａの指示により、後記するテストツールが実行された場合には、そのテストツールのテスト結果である各ＶＭ１のリソース利用量をコントローラ２０ａに送信する。
【００３１】
優先度グループ定義部１２は、物理サーバ１０ａの物理リソースであるＣＰＵコアを、複数のグループに分割する。そして、各グループを、オーバーコミット率の異なるＣＰＵピニングパターンに分けて設定する。
具体的には、優先度グループ定義部１２は、例えば図１６で示したように、優先度が最も高いグループとして、共有できるＶＭ数を「２」とする「優先度［１］のグループ」を設定する。次に優先度が高いグループとして、共有できるＶＭ数を「４」とする「優先度［２］のグループ」を設定する。さらにその次に優先度が高いグループとして、共有できるＶＭ数を「８」とする「優先度［３］のグループ」を設定する。さらにその次に優先度が高いグループ（優先度が最も低いグループ）として、共有できるＶＭ数を「１６」とする「優先度［４］のグループ」を設定する。
なお、ＶＭ１を専用のＣＰＵコアに固定化（ピニング）する技術は、例えば非特許文献１の技術により実現する。
【００３２】
優先度グループ定義部１２は、各優先度グループに対応する物理リソース（ＣＰＵコア）の情報と、その優先度グループの物理リソース（ＣＰＵコア）において共有するＶＭ数（オーバーコミット率）と、ＶＭ１それぞれがどの優先度グループ（優先度［１］〜［４］のグループ）に所属するかを示す情報とを、優先度グループ設定情報１４として記憶する。
【００３３】
優先度グループ変更部１３は、コントローラ２０ａから、ＶＭ１についての優先度グループの変更指示を示す優先度グループ変更情報を受信し、そのＶＭ１の所属する優先度グループを、優先度グループ設定情報１４を参照して確認し、よりオーバーコミット率の小さい（または大きい）ＣＰＵピニングパターンの優先度グループに変更する。
【００３４】
≪コントローラ２０ａ≫
コントローラ２０ａは、物理サーバ１０ａから各ＶＭ１のリソース利用量の情報を取得し、ＶＭ１（仮想ルータ）の性能推定値（性能値）を計算する。そして、コントローラ２０ａは、計算したＶＭ１の性能推定値が、性能不足領域、変更不要領域、性能過多領域のうちのどの領域に属するのかを判定する。コントローラ２０ａは、ＶＭ１の性能推定値が、性能不足領域に属すると判定した場合には、よりオーバーコミット率の小さいＣＰＵピニングパターンの優先度グループに変更する指示（優先度グループ変更情報）を物理サーバ１０ａに送信する。また、コントローラ２０ａは、ＶＭ１の性能推定値が、性能過多領域に属すると判定した場合には、よりオーバーコミット率の大きいＣＰＵピニングパターンの優先度グループに変更する指示（優先度グループ変更情報）を物理サーバ１０ａに送信する。
【００３５】
このコントローラ２０ａは、データ取得部２１と、テストツール機能部２２と、学習機能部２３と、性能値推定部２４と、優先度変更判定部２５と、データ保存ＤＢ２６とを備える。
【００３６】
データ取得部２１は、物理サーバ１０ａが収集した各ＶＭ１についてのリソース利用量を取得し、データ保存ＤＢ２６に記憶する。また、データ取得部２１は、物理サーバ１０ａが実行したテストツールの結果として収集した、リソース利用量等のテスト結果情報を取得し、データ保存ＤＢ２６に記憶する。
【００３７】
テストツール機能部２２は、テストツールを起動し、物理サーバ１０ａにデータ取得開始指示を送信することにより、各ＶＭ１のリソース利用量のデータとそれに対応する性能値（例えば、遅延）のデータを物理サーバ１０ａから取得する。
テストツール機能部２２は、例えば、異なるオーバーコミット率で設定された優先度グループに属するＶＭ１それぞれについて、負荷を所定パターンで変動させ、それにより得られるリソース利用量と、そのときの性能値とをテスト結果情報として取得する。
【００３８】
学習機能部２３は、テストツール機能部２２が取得したテストツールの結果データ（テスト結果情報）を用いて、機械学習による分析（例えば、回帰分析学習）を行い、学習結果データを生成する。この学習結果データは、各オーバーコミット率（優先度グループ）に所属するＶＭ１毎に、リソース利用量から性能値を推定するための情報である。
【００３９】
性能値推定部２４は、物理サーバ１０ａから取得した（現時点での）各ＶＭ１のリソース利用量に基づき、学習機能部２３が保持する学習結果データを用いて、ＶＭ１それぞれの性能推定値（性能値）を計算する。
【００４０】
優先度変更判定部２５は、性能値推定部２４が計算したＶＭ１それぞれの性能推定値を用いて、計算したＶＭ１の性能推定値が、性能不足領域、変更不要領域、性能過多領域のうちのどの領域に属するのかを判定する。
例えば、優先度変更判定部２５は、ＶＭ１の性能推定値が、性能不足領域に属すると判定した場合には、よりオーバーコミット率の小さいＣＰＵピニングパターンの優先度グループに変更する指示（優先度グループ変更情報）を物理サーバ１０ａに送信する。また、優先度変更判定部２５は、ＶＭ１の性能推定値が、性能過多領域に属すると判定した場合には、よりオーバーコミット率の大きいＣＰＵピニングパターンの優先度グループに変更する指示（優先度グループ変更情報）を物理サーバ１０ａに送信する。なお、優先度変更判定部２５は、ＶＭ１の性能推定値が、変更不要領域に属すると判定した場合には、優先度グループを変更する指示を物理サーバ１０ａに送信しない。これにより、そのＶＭ１のその時点での優先度グループへの所属を維持させるようにする。
【００４１】
このように、比較例のＶＭ性能保証システム１００ａによれば、ＶＭ１が性能不足または性能過多の場合に優先度グループを変更することで、物理リソースを効率的に活用した上で、ＶＭ１の性能保証を実現することができる。
【００４２】
＜本実施形態＞
次に、本実施形態に係るＶＭ優先度制御システム１００について説明する。
上記した比較例のＶＭ性能保証システム１００ａ（図１８参照）においては、ＶＭ１が性能不足または性能過多の場合、コントローラ２０ａから優先度グループ変更情報を物理サーバ１０ａが受け取ったときに、物理サーバ１０ａの優先度グループ変更部１３は、変更先となる優先度グループに空きがなければ、優先度グループの変更ができない。この場合、物理サーバ１０ａは、コントローラ２０ａやＶＭ性能保証システム１００ａの管理装置（図示省略）等に対し、警報情報を送信していた。
【００４３】
これに対し、本実施形態に係るＶＭ優先度制御システム１００では、リソース利用量に基づき計算した性能値により、所属する優先度グループに変更が必要であると判定された場合、そのＶＭ１の所属希望先（所属候補）となる優先度グループを決定する。そして、ＶＭ優先度制御システム１００は、所属希望の優先度グループに空きがない場合であっても、優先度グループの空き所属数分をダミーのＶＭとし、他のＶＭ１の所属希望先を含めて調整することにより、所属希望の優先度グループに、より確実に変更できるように制御することを特徴とする。
【００４４】
図１は、本実施形態に係るＶＭ優先度制御システム１００を構成する物理サーバ１０およびコントローラ２０の機能ブロック図である。
物理サーバ１０とコントローラ２０は、通信ネットワークを介して接続される。本実施形態では、１台の物理サーバ１０上に、例えば仮想ルータとして機能するＶＭ１が複数配置されるものとして説明する。なお、物理サーバ１０は１台に限定されるものではなく、複数台の物理サーバ１０がコントローラ２０に接続されていてもよい。
【００４５】
≪物理サーバ１０≫
物理サーバ１０は、自身の物理サーバ上に複数のＶＭ１（仮想マシン）を設定する機能（コンピュートとしての機能）を有する。なお、各ＶＭ１に対してＳＬＡ等で規定される性能は、例えば、ＶＭ１（仮想ルータ）のパケット転送の遅延（レイテンシ）やスループット等である。また、ＶＭ１（仮想ルータ）のＣＰＵ使用量、メモリ使用量、パケット送受信数等をリソース利用量とする。
【００４６】
この物理サーバ１０は、自身が備える物理リソース（例えば、ＣＰＵコア）を優先度の異なる複数のグループに分割しておき、その分割された物理リソース毎に、ＶＭ１の共有数（ＶＭ１の所属可能数）が異なるグループを定義しておく。そして、物理サーバ１０は、所定の時間間隔毎に、各ＶＭのリソース利用量と、現時点の各ＶＭ１の所属を含む優先度グループ設定情報１４とを、コントローラ２０に送信する。また、物理サーバ１０は、コントローラ２０が決定したＶＭ１の新たな所属先の優先度グループを示す優先度グループ設定変更情報を受信し、ＶＭ１の優先度グループを変更する。
【００４７】
この物理サーバ１０は、ＶＭ１を生成する機能（図示省略）を備えるとともに、リソース利用量収集部１１、優先度グループ定義部１２、優先度グループ変更部１３、優先度グループ設定情報１４、優先度グループ設定情報送信部１５を備える。また、物理サーバ１０は、入出力部および記憶部（いずれも図示省略）を備える。
入出力部は、情報の送受信を行うための通信インタフェース、および、タッチパネルやキーボード等の入力装置や、モニタ等の出力装置との間で情報の送受信を行うための入出力インタフェースからなる。
また、記憶部は、フラッシュメモリやハードディスク、ＲＡＭ（Random Access Memory）等により構成される。この物理サーバ１０の記憶部には、図１に示す優先度グループ設定情報１４が記憶される。
【００４８】
なお、図１８で示した比較例のＶＭ性能保証システム１００ａの物理サーバ１０ａが備える構成に比べ、本実施形態に係る物理サーバ１０は、優先度グループ設定情報送信部１５を備える点が異なる。比較例の物理サーバ１０ａと同一の機能を備える構成には、同一の名称と符号を付し、詳細な説明を省略する。
【００４９】
優先度グループ設定情報送信部１５は、記憶部内の優先度グループ設定情報１４を所定の時間間隔毎にコントローラ２０へ送信する。
具体的には、優先度グループ設定情報送信部１５は、優先度グループ設定情報１４で示される、各優先度グループの物理リソース（ＣＰＵコア）において共有するＶＭ数（所属可能数：オーバーコミット率）と、ＶＭ１それぞれがどの優先度グループ（優先度［１］〜［３］のグループ）に所属するかを示す情報とを、コントローラ２０に送信する。
【００５０】
なお、本実施形態に係る物理サーバ１０の優先度グループ定義部１２は、ＶＭ１を収容する優先度グループとして（優先度（優先順位）［１］〜［３］）の３つのグループを設定するものとして説明する。なお、優先順位は、優先度の高いグループから昇順に付される。このうち、優先度（優先順位）が最も高いグループは、優先度グループ［１］であり、共有できるＶＭ数（所属可能数）を「２」とする。次に優先度（優先順位）が高いグループは、優先度グループ「２」であり、共有できるＶＭ数（所属可能数）を「４」とする。その次に優先度（優先順位）が高い（最も優先度の低い）グループは、優先度グループ「３」であり、共有できるＶＭ数（所属可能数）を「８」とする。
【００５１】
≪コントローラ２０≫
コントローラ２０は、物理サーバ１０から、リソース利用量と優先度グループ設定情報１４とを取得する。そして、コントローラ２０は、各ＶＭ１の所属希望の優先度グループを決定する。コントローラ２０は、決定した所属希望の優先度グループに基づき、性能保証の可否を判定し、性能保証が実現できると判定した場合に、優先度グループの空き所属数分をダミーのＶＭとし、他のＶＭ１の所属希望を含めて所定の調整を行うことにより、そのＶＭ１の所属希望の優先度グループに、より確実に変更できるように制御する。
【００５２】
このコントローラ２０は、データ取得部２１と、テストツール機能部２２と、学習機能部２３と、性能値推定部２４と、データ保存ＤＢ２６と、所属希望グループ決定部２７と、性能保証可否判定部２８と、優先度変更先決定部２９と、優先度グループ状態情報２１０と、ＶＭ状態情報２２０とを備える。また、コントローラ２０は、入出力部および記憶部（いずれも図示省略）を備える。
入出力部は、情報の送受信を行うための通信インタフェース、および、タッチパネルやキーボード等の入力装置や、モニタ等の出力装置との間で情報の送受信を行うための入出力インタフェースからなる。
【００５３】
また、記憶部は、フラッシュメモリやハードディスク、ＲＡＭ等により構成される。このコントローラ２０の記憶部は、図１に示すように、データ保存ＤＢ２６、優先度グループ状態情報２１０、ＶＭ状態情報２２０を備える。このデータ保存ＤＢ２６は、物理サーバ１０から取得した各ＶＭ１のリソース利用量（ＣＰＵ使用量、メモリ使用量、パケット送受信数等）の情報や優先度グループ設定情報１４等が記憶される。また、このデータ保存ＤＢ２６には、テストツール機能部２２の指示により、物理サーバ１０から取得したＶＭ１ごとのテスト結果の情報が記憶される。優先度グループ状態情報２１０およびＶＭ状態情報２２０は、コントローラ２０が各ＶＭ１の優先度グループの変更に関する処理を行う毎に設けられる情報である（詳細は後記）。
【００５４】
なお、図１８で示した比較例のＶＭ性能保証システム１００ａのコントローラ２０ａが備える構成に比べ、本実施形態に係るコントローラ２０は、コントローラ２０ａの優先度変更判定部２５（図１８）を備えていない。その代わりに、コントローラ２０は、所属希望グループ決定部２７、性能保証可否判定部２８、優先度変更先決定部２９、優先度グループ状態情報２１０、ＶＭ状態情報２２０を備える点が異なる。比較例のコントローラ２０ａと同一の機能を備える構成には、同一の名称と符号を付し、詳細な説明を省略する。
【００５５】
所属希望グループ決定部２７は、データ取得部２１が物理サーバ１０から取得した、リソース利用量と優先度グループ設定情報１４とに基づき、各ＶＭ１について、性能不足および性能過多とならないような新たな所属先となる優先度グループ（所属希望優先度グループ）を決定する。なお、この所属希望優先度グループには、現所属の優先度グループを所属希望先とする場合も含まれる。
以下、所属希望グループ決定部２７が実行する、所属希望グループ決定処理について詳細に説明する。
【００５６】
図２は、本実施形態に係る所属希望グループ決定部２７が実行する所属希望グループ決定処理の流れを示すフローチャートである。
まず、所属希望グループ決定部２７は、データ取得部２１が取得した優先度グループ設定情報１４を用いて、各優先度グループの空き所属数を計算し、優先度グループ状態情報２１０（図３）を生成する（ステップＳ１０１）。
【００５７】
図３は、本実施形態に係る優先度グループ状態情報２１０のデータ構成例を示す図である。
所属希望グループ決定部２７は、優先度グループ設定情報１４に含まれる、各優先度グループの物理リソース（ＣＰＵコア）において共有するＶＭ数（所属可能数）と、ＶＭ１それぞれがどの優先度グループ（優先度［１］〜［３］のグループ）に所属するかを示す情報とを用いて、この優先度グループ状態情報２１０を生成する。
【００５８】
図３に示すように、優先度グループ状態情報２１０は、グループＩＤ２１１、優先順位２１２、所属可能数２１３、空き所属数２１４の項目により構成される。
グループＩＤ２１１は、各優先度グループを識別するための情報である。優先順位２１２は、各優先度グループの優先度（［１］〜［３］）を高い順に並べて順位をつけた値である。所属可能数２１３は、各優先度グループの物理リソース（ＣＰＵコア）において共有可能として設定されたＶＭ数を示す。空き所属数２１４は、所属可能数２１３からその優先度グループに現時点で所属しているＶＭ１の数を減じた空きとなる所属数である。所属希望グループ決定部２７は、現時点のＶＭ１における所属先の優先度グループの情報を優先度グループ設定情報１４により把握することができる。
図３においては、グループＩＤ２１１が「g0001」の優先度グループの空き所属数２１４が「１」である。グループＩＤ２１１が「g0002」の優先度グループの空き所属数２１４が「０」である。また、グループＩＤ２１１が「g0003」の優先度グループの空き所属数２１４が「２」である。
【００５９】
次に、所属希望グループ決定部２７は、優先度グループ設定情報１４に含まれる、各ＶＭ１がどの優先度グループ（優先度［１］〜［３］のグループ）に所属するかを示す情報を用いて、初期設定のＶＭ状態情報２２０（図４）を生成する（ステップＳ１０２）。
【００６０】
図４は、本実施形態に係るＶＭ状態情報２２０のデータ構成例（初期設定）を示す図である。
図４に示すように、ＶＭ状態情報２２０は、ＶＭＩＤ２２１、ステータス２２２、リソース利用量２２３、性能値２２４、現所属２２５、所属希望２２６、空き判定２２７の項目により構成される。
ＶＭＩＤ２２１は、各ＶＭ１を識別するための情報である。ステータス２２２は、処理の実行途中を示す「未完了」と、処理が終了したことを示す「完了」が格納される。なお、処理の開始前には「−」が格納される。
リソース利用量２２３には、物理サーバ１０から取得した各ＶＭ１のリソース利用量（例えば、ＣＰＵ使用量、メモリ使用量等）が格納される。
性能値２２４には、各ＶＭ１のリソース利用量に基づき、性能値推定部２４が算出した性能値が格納される。
現所属２２５には、そのＶＭ１が現在所属する優先度グループが格納される。
所属希望２２６には、所属希望グループ決定部２７が後記する処理により決定する所属希望先となる優先度グループが格納される。
【００６１】
空き判定２２７には、実際に設定されている（ダミーではない）ＶＭ１であるか、ダミーのＶＭであるかを判別する情報が格納される。ここで、実際に優先度グループに設定されているＶＭ１には、空き判定２２７に「０」を格納する。一方、ダミーで設定されるＶＭには、空き判定２２７に「１」を格納する（図５参照）。図４の初期設定のＶＭ状態情報２２０では、すべてが実際に設定されているＶＭ１であるため、空き判定２２７に「０」が格納される。
【００６２】
所属希望グループ決定部２７は、優先度グループ設定情報１４に含まれる、各ＶＭ１がどの優先度グループ（優先度［１］〜［３］のグループ）に所属するかを示す情報を用いて、例えば、ＶＭＩＤ２２１が「v0001」のＶＭ１について、図４に示すように、現所属２２５に「g0001」、空き判定２２７に「０」を格納する。以下、現時点で設定されている各ＶＭ１について、同様に現所属２２５と空き判定２２７（「０」）とを格納する。
【００６３】
次に、所属希望グループ決定部２７は、図３に示した優先度グループ状態情報２１０を参照し、空き所属数２１４の合計値（ここでは、１＋０＋２＝３）に対応する数のダミーのＶＭを、初期設定のＶＭ状態情報２２０（図４）に追加して設定する（ステップＳ１０３）。
具体的には、所属希望グループ決定部２７は、グループＩＤ２１１が「g0001」の優先度グループの空きが「１」（図３参照）であることから、図５で示すように、現所属が「g0001」のダミーのＶＭを「v0012」として設定する。そして、所属希望グループ決定部２７は、グループＩＤ２１１が「g0003」の優先度グループの空きが「２」（図３参照）であることから、図５で示すように、現所属が「g0003」である２つのダミーのＶＭを「v0013」「v0014」として設定する。
そして、所属希望グループ決定部２７は、ダミーで生成したＶＭ（「v0012」「v0013」「v0014」）の所属希望２２６を、優先度グループで最も優先順位の低い「g0003」に設定する。また、所属希望グループ決定部２７は、空き判定２２７にダミーのＶＭであることを示す「１」を設定する。
【００６４】
次に、所属希望グループ決定部２７は、データ取得部２１が物理サーバ１０からリソース利用量の情報を取得する毎のタイミングで次の処理を実行する（適宜、図６参照）。
まず、所属希望グループ決定部２７は、ＶＭ状態情報２２０の各ＶＭ１のステータス２２２を「未完了」とする（ステップＳ１０４）。
そして、所属希望グループ決定部２７は、データ取得部２１が取得したリソース利用量の情報をＶＭ状態情報２２０に取り込む（ステップＳ１０５）。また、所属希望グループ決定部２７は、そのリソース利用量に基づき、性能値推定部２４が計算した性能値の情報を取り込み、ＶＭ状態情報２２０に格納する（ステップＳ１０６）。
【００６５】
図６に示すＶＭ状態情報２２０では、各ＶＭ１のステータス２２２に「未完了」が格納されている。また、リソース利用量として、ＣＰＵ使用量（図では「Ｃ」と表記）やメモリ使用量（図では「Ｍ」と表記）が格納され、そのリソース利用量の値から求められた性能値２２４が格納されていることを示している。なお、リソース利用量および性能値は、説明を簡単にするため、最大値を１００として正規化した値で例示している。
【００６６】
ここで、所属希望グループ決定部２７は、所定の性能値判定基準により、リソース利用量に基づき計算した性能値が、「性能不足領域」「変更不要領域」「性能過多領域」のいずれに属するかを判定する（ステップＳ１０７）。この「性能不足領域」「変更不要領域」「性能過多領域」それぞれに属するか否かを判定する条件（基準）は、予め設定しておく。
例えば、性能不足を所定の第１の閾値未満の性能であるとし、性能過多を所定の第２の閾値以上の性能であると設定しておく。ここでは、性能不足領域を、性能値が「０以上６０未満」とする。「変更不要領域」を、性能値が「６０以上９０未満」とする。性能過多領域を、性能値が「９０以上１００以下」として説明する。
【００６７】
図６に示す例では、ＶＭＩＤ２２１が「v0001」のＶＭ１は、性能値２２４が「１００」であるので、性能過多領域に属すると判定される。ＶＭＩＤ２２１が「v0002」のＶＭ１は、性能値２２４が「５０」であるので、性能不足領域に属すると判定される。ＶＭＩＤ２２１が「v0003」のＶＭ１は、性能値２２４が「８０」であるので、変更不要領域に属すると判定される。ＶＭＩＤ２２１が「v0004」のＶＭ１は、性能値２２４が「２０」であるので、性能不足領域に属すると判定される。
ここで、所属希望グループ決定部２７は、変更不要領域に属すると判定したＶＭＩＤ２２１が「v0003」のＶＭ１については、所属希望２２６を現在の優先度グループと同じ「g0002」とする（図６参照）。
【００６８】
続いて、ステップＳ１０８において、所属希望グループ決定部２７は、次の処理を行う。所属希望グループ決定部２７は、性能過多領域に属すると判定されたＶＭ１について「降格グループ探索」を行い、計算した性能値が「変更不要領域」となった優先度グループをそのＶＭ１の所属希望先に決定する。また、所属希望グループ決定部２７は、性能不足領域に属すると判定されたＶＭ１について「昇格グループ探索」を行い、計算した性能値が「変更不要領域」となった優先度グループをそのＶＭ１の所属希望先に決定する。
【００６９】
降格グループ探索は、性能値推定部２４が計算する性能値が「変更不要領域」になるまで以下の処理を実行することにより行う。
所属希望グループ決定部２７は、現在所属するグループより１低い優先度グループでの性能値を性能値推定部２４に計算させる。そして、所属希望グループ決定部２７は、計算した性能値の領域を判定し、「変更不要領域」になるまで、さらに１低い優先度グループでの性能値の計算を繰り返す。そして、所属希望グループ決定部２７は、「変更不要領域」となった優先度グループをそのＶＭ１の所属希望に決定する。
【００７０】
昇格グループ探索は、性能値推定部２４が計算する性能値が「変更不要領域」になるまで以下の処理を実行することにより行う。
所属希望グループ決定部２７は、現在所属するグループより１高い優先度グループでの性能値を性能値推定部２４に計算させる。そして、所属希望グループ決定部２７は、計算した性能値の領域を判定し、「変更不要領域」になるまで、さらに１高い優先度グループでの性能値の計算を繰り返す。そして、所属希望グループ決定部２７は、「変更不要領域」となった優先度グループをそのＶＭ１の所属希望に決定する。
【００７１】
図７は、所属希望グループ決定部２７による、降格グループ探索と、昇格グループ探索の結果を示す図である。
ＶＭＩＤ２２１が「v0001」のＶＭ１については、降格グループ探索を行い、「g0002」の優先度グループで「変更不要領域」になると計算される。ＶＭＩＤ２２１が「v0002」のＶＭ１については、昇格グループ探索を行い、「g0001」の優先度グループで「変更不要領域」になると計算される。ＶＭＩＤ２２１が「v0004」のＶＭ１については、昇格グループ探索を行い、「g0001」の優先度グループで「変更不要領域」になると計算される。
なお、所属希望グループ決定部２７は、図７の一点鎖線で示される状態を含む、各ＶＭ１がすべての優先度グループに存在する場合を想定した計算を行うことにより、変更不要領域となる優先度グループを決定してもよい。
【００７２】
図８に示すように、所属希望グループ決定部２７は、上記の降格グループ探索や昇格グループ探索を行うことにより決定した所属希望の優先度グループをＶＭ状態情報２２０の所属希望２２６に格納する。
なお、この際、現所属の優先度グループから所属希望２２６の変更がないＶＭ１については、後記する優先度変更先決定部２９により、ステータスが「未完了」から「完了」に変更される。
【００７３】
図１に戻り、性能保証可否判定部２８は、ＶＭ１の現時点（現所属）の優先度グループと、所属希望グループ決定部２７が決定した所属希望の優先度グループとの情報を用いて、ＳＬＡ等で規定される性能保証を実現できるか否かを所定のロジック（性能保証可否判定ロジック）に基づき判定する。
【００７４】
性能保証可否判定部２８は、性能保証を実現できるか否かを判定するロジックとして、以下のロジックを採用する。
「Σ（所属希望の優先度グループの優先順位 − 現所属の優先度グループの優先順位） ≦ ０」（条件１）、かつ、
「優先順位ａの優先度グループを希望するＶＭ数 ≦ 優先順位ａ以上の優先度グループでのＶＭの所属可能総数」（条件２）
ここで、「ａ」は、優先順位「ａ」（ここでは、「１」〜「３」）の各優先度グループを示す。
【００７５】
図８で示す例においては、以下のように（条件１）（条件２）が判定される。なお、図８において、省略し記載していないＶＭＩＤ２２１が「v0005」〜「v0011」のＶＭ１については、現所属２２５と所属希望２２６とが同じ優先度グループであり、ステータスが「完了」であるとして以下の計算を行う。具体的には、現所属のグループＩＤが「g0002」のＶＭ１が２つ、「g0003」のＶＭ１が５つあるものとして説明する。
【００７６】
（条件１）は、ＶＭＩＤ２２１が「v0001」「v0002」「v0004」のＶＭ１について、次のように計算させる。なお、所属希望と現所属が同じ優先順位の場合は、差が「０」であるので計算せず、記載を省略する。
Σ（所属希望の優先度グループの優先順位 − 現所属の優先度グループの優先順位）
＝（２−１）＋（１−２）＋（１−３）＝ −２ ≦０
以上より、（条件１）を満たす。
【００７７】
（条件２）において、優先順位「１」（優先度グループ［１］）を希望するＶＭ数は、「２」であり、優先順位「１」以上の所属可能総数は「２」であるから、２ ≦ ２であり、優先順位「１」について、（条件２）を満たす。
優先順位「２」（優先度グループ［２］）を希望するＶＭ数は、「４」であり、優先順位「２」以上の所属可能総数は「４」（４＋０）であるから、４ ≦ ４であり、優先順位「２」について、（条件２）を満たす。なお、ここでは、優先順位「１」の優先度グループには空き所属がないため、「＋０」としている。
優先順位「３」（優先度グループ［３］）を希望するＶＭ数は、「５」であり、優先順位「３」以上の所属可能総数は「８」（８＋０＋０）であるから、５ ≦ ８であり、優先順位「３」について、（条件２）を満たす。なお、ここでは、優先順位「１」「２」の優先度グループには空き所属がないため「＋０＋０」としている。
よって、すべての優先順位について、（条件２）を満たす。
【００７８】
性能保証可否判定部２８は、（条件１）かつ（条件２）を満たす場合に、性能保証可能と判定する。一方、性能保証可否判定部２８は、（条件１）（条件２）のいずれかを満たさない場合には、性能保証不可と判定し、警報情報をシステム全体の管理装置等に出力する。
【００７９】
図１に戻り、優先度変更先決定部２９は、性能保証可否判定部２８が、性能保証可能と判定した場合に、以下の処理を実行する。
優先度変更先決定部２９は、図８に示すＶＭ状態情報２２０を参照し、空き判定２２７が「０」の各ＶＭ１について、まず、現所属２２５と所属希望２２６が等しいか異なるかを判定する。
そして、優先度変更先決定部２９は、現所属２２５と所属希望２２６が等しい場合に、ステータス２２２を「未完了」から「完了」に変更する。なお、この処理は、各ＶＭ１の所属希望２２６が算出されたときに行われてもよい。
【００８０】
また、優先度変更先決定部２９は、現所属２２５と所属希望２２６が異なる場合に、次の（処理１）（処理２）を実行する。
【００８１】
（処理１）他のＶＭ１（ダミーのＶＭを含む）に現所属２２５と所属希望２２６とが対（所属する優先度グループの対が反対であり入れ替えると一致する所属関係）になるものがある場合、そのＶＭ１と所属を交換し、ステータスを「未完了」から「完了」に変更する。
（処理２）他のＶＭ１（ダミーのＶＭを含む）に、現所属２２５と所属希望２２６とが対（所属する優先度グループの対が反対であり入れ替えると一致する所属関係）になるものがない場合、空き判定「１」のダミーのＶＭの現所属が、その対のないＶＭ１の所属希望以上のものと交換し、ステータスを「未完了」から「完了」に変更する。
【００８２】
（処理１）については、図９（ａ）に示すように、ＶＭＩＤ２２１が「v0001」と「v0002」は、現所属２２５と所属希望２２６が対（所属する優先度グループの対が反対であり入れ替えると一致する所属関係）になっているため、現所属２２５の優先度グループを交換する。また、ＶＭＩＤ２２１が「v0004」と「v0012」は、現所属２２５と所属希望２２６が対（所属する優先度グループの対が反対であり入れ替えると一致する所属関係）になっているため、現所属２２５の優先度グループを交換する。その結果、変更後の現所属２２５は、図９（ｂ）のようになる。
優先度変更先決定部２９は、優先度グループを交換した後、図１０に示すように、ステータス２２２を、「未完了」から「完了」に変換し処理を終える。
【００８３】
（処理２）については、図１１（ａ）に示すように、ＶＭＩＤ２２１が「v0004」のＶＭ１について、現所属２２５が「g0003」であり所属希望２２６が「g0002」である例として説明する。このとき、「v0004」のＶＭ１には、対になるＶＭ１（ダミーのＶＭを含む）は存在しない。この場合には、空き判定「１」のダミーのＶＭの現所属が、「v0004」のＶＭ１の所属希望２２６の「g0002」以上である、「v0012」のダミーのＶＭ（現所属が「g0001」）と優先度グループを交換する（図１１（ａ）の両矢印参照）。その結果、変更後の現所属２２５は、図１１（ｂ）のようになる。優先度グループを交換した後、優先度変更先決定部２９は、ステータス２２２を「未完了」から「完了」に変換し処理を終える。
このようにすることにより、現所属２２５と所属希望２２６とに対になるものがない場合でも、性能保証を実現することができる。
なお、優先度変更先決定部２９は、（処理１）のみを実行するように設定しておいてもよいし、（処理１）（処理２）の両方を実行するように設定しておいてもよい。
【００８４】
優先度変更先決定部２９は、図１０に示すように、ＶＭ状態情報２２０のステータス２２２がすべて「完了」になると、空き判定２２７が「０」のＶＭ１の現所属２２５の情報を、優先度グループ設定変更情報として、物理サーバ１０に送信する。
【００８５】
＜処理の流れ＞
次に、ＶＭ優先度制御システム１００が実行する処理の流れについて図１２を参照して説明する。
【００８６】
図１２は、本実施形態に係るＶＭ優先度制御システム１００が実行する全体の処理の流れを示すフローチャートである。
【００８７】
まず、物理サーバ１０の優先度グループ定義部１２は、各優先度グループに対応する物理リソース（ＣＰＵコア）において共有するＶＭ数（所属可能数：オーバーコミット率）の情報と、ＶＭ１それぞれがどの優先度グループ（優先度（優先順位）［１］〜［３］のグループ）に所属するかを示す情報とを、優先度グループ設定情報１４として記憶部に記憶する（ステップＳ１０）。
【００８８】
続いて、コントローラ２０のテストツール機能部２２および学習機能部２３により、テストツールを起動させて物理サーバ１０からテストツールの実行結果を取得し、ＶＭ１の性能値を算出するために必要となる学習結果データを生成する（ステップＳ１１）。この学習結果データを用いて、コントローラ２０の性能値推定部２４は、リアルタイムに更新される各ＶＭ１のリソース利用量のデータに基づき、性能値を計算することができる。
【００８９】
次に、物理サーバ１０のリソース利用量収集部１１は、所定時間が経過したか否かを判定する（ステップＳ１２）。所定時間が経過していない場合には（ステップＳ１２→Ｎｏ）、ステップＳ１２に戻り、所定時間が経過するまで待機する。一方、所定時間が経過した場合には（ステップＳ１２→Ｙｅｓ）、次のステップＳ１３へ進む。つまり、以降の処理は、所定の時間間隔で繰り返し実行されるものである。
【００９０】
ステップＳ１３において、物理サーバ１０のリソース利用量収集部１１が、各ＶＭ１についてのリソース利用量の情報を収集し、コントローラ２０に送信する。
また、ステップＳ１４において、物理サーバ１０の優先度グループ設定情報送信部１５は、記憶部内の優先度グループ設定情報１４を所定の時間間隔毎にコントローラ２０へ送信する。具体的には、優先度グループ設定情報送信部１５は、優先度グループ設定情報１４で示される、各優先度グループの物理リソース（ＣＰＵコア）において共有するＶＭ数（所属可能数）と、ＶＭ１それぞれがどの優先度グループ（優先度［１］〜［３］のグループ）に所属するかを示す情報とを、コントローラ２０に送信する。
なお、ステップＳ１３とステップＳ１４の処理の順序は問わず、どちらが先にコントローラ２０へ送信されてもよいし、同時に送信されてもよい。
【００９１】
続いて、コントローラ２０の所属希望グループ決定部２７は、データ取得部２１が物理サーバ１０から取得した、リソース利用量と優先度グループ設定情報１４とに基づき、各ＶＭ１について、性能不足および性能過多とならないような新たな所属先となる優先度グループ（所属希望優先度グループ）を決定するため、所属希望グループ決定処理を実行する（ステップＳ１５）。なお、この所属希望グループ決定処理は、図２等より説明したため、詳細な説明は省略する。
このステップＳ１５の所属希望グループ決定処理により、所属希望グループ決定部２７は、例えば、図８に示すように、各ＶＭ１について所属希望２２６となる優先度グループを決定することができる。
【００９２】
次に、コントローラ２０の性能保証可否判定部２８は、ＶＭ１の現時点の優先度グループ（図８の現所属２２５）と、所属希望グループ決定部２７が決定した所属希望の優先度グループ（図８の所属希望２２６）との情報を用いて、ＳＬＡ等で規定される性能保証を実現できるか否かを所定のロジック（性能保証可否判定ロジック）に基づき判定する（ステップＳ１６）。
なお、性能保証可否判定部２８が、所定のロジック（性能保証可否判定ロジック）で示される上記した（条件１）かつ（条件２）を満たさない場合には、性能保証を実現できないと判定して処理を中止し、警報情報をＶＭ優先度制御システム１００の管理装置等に送信する。一方、（条件１）かつ（条件２）を満たす場合には、性能保証が実現できるものと判定し、以降の処理に進む。
【００９３】
続いて、コントローラ２０の優先度変更先決定部２９は、優先度グループの変更先決定処理を実行する（ステップＳ１７）。
具体的には、優先度変更先決定部２９は、ＶＭ状態情報２２０を参照し、空き判定２２７が「０」の各ＶＭ１について、現所属２２５と所属希望２２６が等しい場合に、優先度グループを変更する必要がないと決定し、ステータス２２２を「完了」にする。
一方、優先度変更先決定部２９は、ＶＭ状態情報２２０を参照し、空き判定２２７が「０」の各ＶＭ１について、現所属２２５と所属希望２２６が異なる場合に、上記した（処理１）（処理２）を実行する。
【００９４】
優先度変更先決定部２９は、（処理１）により、他のＶＭ１（ダミーのＶＭを含む）との間で現所属２２５と所属希望２２６とが対（所属する優先度グループの対が反対であり入れ替えると一致する所属関係）になるものがある場合には、そのＶＭ１と優先度グループの現所属を交換することにより、優先度グループの変更先を決定する。
また、優先度変更先決定部２９は、（処理２）により、他のＶＭ１（ダミーのＶＭを含む）に、現所属２２５と所属希望２２６とが対になるものがない場合に、空き判定「１」のダミーのＶＭの現所属が、その対のないＶＭ１の所属希望以上のものと優先度グループの現所属を交換することにより、優先度グループの変更先を決定する。
【００９５】
優先度変更先決定部２９は、変更された現所属２２５の優先度グループの情報を含む優先度グループ設定変更情報を生成し、物理サーバ１０へ送信する（ステップＳ１８）。
【００９６】
物理サーバ１０の優先度グループ変更部１３は、受信した優先度グループ設定変更情報を参照し、現時点の優先度グループと異なる優先度グループが設定されているＶＭ１について、優先度グループを変更する（ステップＳ１９）。この際、優先度グループ変更部１３は、当該ＶＭ１について新たに所属する優先度グループに基づき、優先度グループ設定情報１４を更新し、処理を終える。
【００９７】
以上説明したように、本実施形態に係るＶＭ優先度制御システム１００およびＶＭ優先度制御方法によれば、優先度グループの空き所属を、ダミーのＶＭとして扱い、そのダミーのＶＭも含めて、優先度グループの所属先を調整する。これにより、所属希望の優先度グループに空きがない場合であっても、より確実にＶＭの性能保証を実現しつつ、リソース利用効率の高めることができる。
【符号の説明】
【００９８】
１      ＶＭ（仮想ルータ）
１０    物理サーバ（コンピュート）
１１    リソース利用量収集部
１２    優先度グループ定義部
１３    優先度グループ変更部
１４    優先度グループ設定情報
１５    優先度グループ設定情報送信部
２０    コントローラ
２１    データ取得部
２２    テストツール機能部
２３    学習機能部
２４    性能値推定部
２６    データ保存ＤＢ
２７    所属希望グループ決定部
２８    性能保証可否判定部
２９    優先度変更先決定部
１００  ＶＭ優先度制御システム
２１０  優先度グループ状態情報
２２０  ＶＭ状態情報
【図１】
2019204305.tif 000003
【図２】
2019204305.tif 000004
【図３】
2019204305.tif 000005
【図４】
2019204305.tif 000006
【図５】
2019204305.tif 000007
【図６】
2019204305.tif 000008
【図７】
2019204305.tif 000009
【図８】
2019204305.tif 000010
【図９】
2019204305.tif 000011
【図１０】
2019204305.tif 000012
【図１１】
2019204305.tif 000013
【図１２】
2019204305.tif 000014
【図１３】
2019204305.tif 000015
【図１４】
2019204305.tif 000016
【図１５】
2019204305.tif 000017
【図１６】
2019204305.tif 000018
【図１７】
2019204305.tif 000019
【図１８】
2019204305.tif 000020