(57)【要約】【課題】所属希望の優先度グループに空きがない場合であっても、ＶＭのマイグレーションを実行し、性能保証を継続して実現する。【解決手段】ＶＭマイグレーションシステム１００は、物理サーバ１０から取得した各ＶＭ１のリソース利用量および優先度グループ設定情報１４に基づき、コントローラ２０が、性能不足となったＶＭについて、所属希望の優先度グループを決定する。そして、コントローラ２０は、性能保証不可警報情報を取得すると、空き所属がない優先度グループの現所属のＶＭの中から、マイグレーションの対象とするＶＭを選択し、物理サーバの余裕度が最も大きい物理サーバをマイグレーションの移行先の他の物理サーバに選択して、マイグレーション指示情報を物理サーバに送信する。物理サーバは、選択されたＶＭの他の物理サーバへのマイグレーションを実行する。【選択図】図１
2019204309.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」のＶＭ１は、性能値２２３が「１００」であるので、性能過多領域に属すると判定される。ＶＭＩＤ２２１が「v0002」のＶＭ１は、性能値２２３が「５０」であるので、性能不足領域に属すると判定される。ＶＭＩＤ２２１が「v0003」のＶＭ１は、性能値２２３が「８０」であるので、変更不要領域に属すると判定される。ＶＭＩＤ２２１が「v0004」のＶＭ１は、性能値２２３が「２０」であるので、性能不足領域に属すると判定される。ＶＭＩＤ２２１が「v0005」のＶＭ１は、性能値２２３が「３０」であるので、性能不足領域に属すると判定される。
ここで、所属希望グループ決定部２７は、変更不要領域に属すると判定したＶＭＩＤ２２１が「v0003」のＶＭ１については、所属希望２２５を現在の優先度グループと同じ「g0002」とする。
【００７３】
続いて、所属希望グループ決定部２７は、性能不足領域および性能過多領域に属するＶＭ１について、所属希望となる新たな優先度グループを決定する。具体的には、所属希望グループ決定部２７は、性能過多領域に属すると判定されたＶＭ１について「降格グループ探索」を行い、計算した性能値が「変更不要領域」となった優先度グループをそのＶＭ１の所属希望先に決定する。また、所属希望グループ決定部２７は、性能不足領域に属すると判定されたＶＭ１について「昇格グループ探索」を行い、計算した性能値が「変更不要領域」となった優先度グループをそのＶＭ１の所属希望先に決定する。
【００７４】
降格グループ探索は、性能値推定部２４が計算する性能値が「変更不要領域」になるまで以下の処理を実行することにより行う。
所属希望グループ決定部２７は、現在所属するグループより１低い優先度グループでの性能値を性能値推定部２４に計算させる。そして、所属希望グループ決定部２７は、計算した性能値の領域を判定し、「変更不要領域」になるまで、さらに１低い優先度グループでの性能値の計算を繰り返す。そして、所属希望グループ決定部２７は、「変更不要領域」となった優先度グループをそのＶＭ１の所属希望に決定する。
【００７５】
昇格グループ探索は、性能値推定部２４が計算する性能値が「変更不要領域」になるまで以下の処理を実行することにより行う。
所属希望グループ決定部２７は、現在所属するグループより１高い優先度グループでの性能値を性能値推定部２４に計算させる。そして、所属希望グループ決定部２７は、計算した性能値の領域を判定し、「変更不要領域」になるまで、さらに１高い優先度グループでの性能値の計算を繰り返す。そして、所属希望グループ決定部２７は、「変更不要領域」となった優先度グループをそのＶＭ１の所属希望に決定する。
【００７６】
図４は、所属希望グループ決定部２７による、降格グループ探索と、昇格グループ探索の結果を示す図である。
ＶＭＩＤ２２１が「v0001」のＶＭ１については、降格グループ探索を行い、「g0002」の優先度グループで「変更不要領域」になると計算される。ＶＭＩＤ２２１が「v0002」のＶＭ１については、昇格グループ探索を行い、「g0001」の優先度グループで「変更不要領域」になると計算される。ＶＭＩＤ２２１が「v0004」のＶＭ１については、昇格グループ探索を行い、「g0001」の優先度グループで「変更不要領域」になると計算される。ＶＭＩＤ２２１が「v0005」のＶＭ１については、昇格グループ探索を行い、「g0002」の優先度グループで「変更不要領域」になると計算される。
なお、所属希望グループ決定部２７は、図４の一点鎖線で示される状態を含む、各ＶＭ１が全ての優先度グループに存在する場合を想定した計算を行うことにより、変更不要領域となる優先度グループを決定してもよい。
【００７７】
図５に示すように、所属希望グループ決定部２７は、上記の降格グループ探索や昇格グループ探索を行うことにより決定した所属希望の優先度グループをＶＭ状態情報２２０の所属希望２２５に格納する。
このようにして、所属希望グループ決定部２７は、優先度グループ状態情報２１０（図２）およびＶＭ状態情報２２０（図５）を生成して、各ＶＭ１の所属希望の優先度グループを決定し、所属希望グループ決定処理を終える。
そして、所属希望グループ決定部２７は、ＶＭ状態情報２２０に格納した、各ＶＭ１についての新たな所属希望の優先度グループを、優先度グループ設定変更情報として、物理サーバ１０に送信する。
【００７８】
図１に戻り、性能保証可否判定部２８は、ＶＭ１の現時点（現所属）の優先度グループと、所属希望グループ決定部２７が決定した所属希望の優先度グループとの情報を用いて、ＳＬＡ等で規定される性能保証を実現できるか否かを所定のロジック（性能保証可否判定ロジック）に基づき判定する。
【００７９】
性能保証可否判定部２８は、性能保証を実現できるか否かを判定するロジックとして、例えば、以下のロジックを採用する。
「Σ（所属希望の優先度グループの優先順位 − 現所属の優先度グループの優先順位） ≦ ０」（条件１）、かつ、
「優先順位ａの優先度グループを希望するＶＭ数 ≦ 優先順位ａ以上の優先度グループでのＶＭの所属可能総数」（条件２）
ここで、「ａ」は、優先順位「ａ」（ここでは、「１」〜「３」）の各優先度グループを示す。
【００８０】
図５で示す例においては、以下のように（条件１）（条件２）が判定される。なお、図５において、省略し記載していないＶＭＩＤ２２１「v0006」〜「v0011」の６つのＶＭ１については、現所属２２４と所属希望２２５とが同じ優先度グループであるもものとして計算を行う。具体的には、現所属のグループＩＤが「g0002」のＶＭ１が２つ、「g0003」のＶＭ１が４つあるものとして説明する。
【００８１】
（条件１）は、ＶＭＩＤ２２１が「v0001」「v0002」「v0004」「v0005」のＶＭ１について、次のように計算させる。なお、所属希望と現所属が同じ優先順位の場合は、差が「０」であるので計算せず、記載を省略する。
Σ（所属希望の優先度グループの優先順位 − 現所属の優先度グループの優先順位）
＝（２−１）＋（１−２）＋（１−３）＋（２−３）＝ −３ ≦０
以上より、（条件１）を満たす。
【００８２】
（条件２）において、優先順位「１」（優先度グループ［１］）を希望するＶＭ数は、「２」であり、優先順位「１」以上の所属可能総数は「２」であるから、２ ≦ ２であり、優先順位「１」について、（条件２）を満たす。
優先順位「２」（優先度グループ［２］）を希望するＶＭ数は、「５」であり、優先順位「２」以上の所属可能総数は「４」（４＋０）であるから、５ ≦ ４であり、優先順位「２」について、（条件２）を満たさない。なお、ここでは、優先順位「１」の優先度グループには空き所属がないため、「＋０」としている。
優先順位「３」（優先度グループ［３］）を希望するＶＭ数は、「４」であり、優先順位「３」以上の所属可能総数は「８」（８＋０＋０）であるから、４ ≦ ８であり、優先順位「３」について、（条件２）を満たす。なお、ここでは、優先順位「１」「２」の優先度グループには空き所属がないため「＋０＋０」としている。
よって、優先順位「２」の優先度グループについて、（条件２）を満たさないため、性能保証可否判定部２８は、性能保証不可であると判定する。そして、性能保証可否判定部２８は、性能保証不可であると判定した場合、ＶＭ選択部２９に性能保証不可警報情報を出力する。この性能保証不可警報情報には、性能保証不可とされたＶＭ１の属する優先度グループとその物理サーバ１０の識別情報が含まれる。ここでは、物理サーバ１０の識別情報と空き所属のない優先度グループ［２］の情報を含む性能保証不可警報情報が出力される。
【００８３】
図１に戻り、ＶＭ選択部２９は、物理サーバ１０の性能保証判定部１６、コントローラ２０の性能保証可否判定部２８のいずれかまたは両方から性能保証不可警報情報を取得した場合、その性能保証不可警報情報に含まれる、物理サーバ１０の識別子を用いて、その物理サーバ１０を特定する。ＶＭ選択部２９は、データ保存ＤＢ２６に記憶された、特定した物理サーバ１０に関する優先度グループ設定情報１４を参照して、性能保証不可とされたＶＭ１の所属希望の優先度グループであって、空き所属がない優先度グループ（ここでは、優先度グループ［２］）に現時点で所属するＶＭ１を抽出する。そして、ＶＭ選択部２９は、抽出したＶＭ１の中から、所定にルールに従って、マイグレーションの対象とするＶＭ１を選択する。この所定のルールは、リソース利用量（例えば、メモリ使用量）の最も小さいＶＭ１を選択する等であり、予め設定される。
【００８４】
物理サーバ選択部３０は、所定の時間間隔や、例えば、コントローラ２０が物理サーバ１０からリソース利用量および優先度グループ設定情報１４の情報を取得したタイミング毎に、物理サーバ１０の処理能力についての余裕の度合を示す余裕度を、所定のロジック（余裕度計算ロジック）に基づき計算する。そして、物理サーバ選択部３０は、各物理サーバ１０の余裕度のうち、最も余裕度が大きい物理サーバ１０を、マイグレーション先の物理サーバ１０として選択する。
【００８５】
なお、物理サーバ選択部３０は、余裕度の計算に際し、図６に示す物理サーバ状態情報２３０を生成する。
図６に示すように、物理サーバ状態情報２３０は、物理サーバＩＤ２３１、空きＶＭ数２３２、余裕度２３３の項目により構成される。
物理サーバＩＤ２３１は、各物理サーバ１０を識別するための情報である。
空きＶＭ数２３２は、各物理サーバ１０のＶＭ１の空き所属の合計である。この空きＶＭ数２３２は、図２で示す優先度グループ状態情報２１０の空き所属数２１４を全ての優先度グループにおいて合計した値が格納される。
余裕度２３３は、例えば、以下の３つの余裕度計算ロジックのうちのいずれかを用いて計算される。
【００８６】
（余裕度計算ロジック「１」）
各物理サーバ１０の空きＶＭ数を余裕度として利用する。
余裕度 Ｍ ＝ Ｓ-ｋ  ・・・（式１）
ここで、Ｓｋは、物理サーバ１０の空きＶＭ数を示す。
なお、この余裕度計算ロジック「１」を採用した場合、図６に示す物理サーバ状態情報２３０の空きＶＭ数２３２の値と、余裕度２３３の値とは、同一となる。
【００８７】
余裕度計算ロジック「１」を用いることで、コントローラ２０は、各物理サーバ１０について空きＶＭ数が多いほど余裕度が大きいものとして、マイグレーションの移行先となる物理サーバ１０を簡易に決定することが可能となる。
【００８８】
（余裕度計算ロジック「２」）
各物理サーバ１０に属する優先度グループｉに対し、（式２）を用いて余裕度を計算する。
余裕度 Ｍ ＝ ΣｉａｉＥｉ／Ｐｉ  ・・・（式２）
ここで、Ｅｉは、その優先度グループにおける空き所属数を示す。Ｐｉは、優先度グループの優先順位を示す。ａｉは、定数（優先度グループ毎の重み）を示す。
なお、物理サーバ選択部３０は、この空き所属数Ｅｉの情報と、優先度グループの優先順位Ｐｉの情報とを、各物理サーバ１０に対応付けて記憶された、優先度グループ状態情報２１０（図２）を参照することにより取得することができる。
【００８９】
余裕度計算ロジック「２」を用いることで、コントローラ２０は、優先度グループの空き所属数と、優先度グループの優先順位とを用いて、優先順位が高い優先度グループに空き所属が多いほど、その物理サーバ１０の余裕度が大きいものとして、マイグレーションの移行先となる物理サーバ１０を簡易に決定することが可能となる。
【００９０】
（余裕度計算ロジック「３」）
各物理サーバ１０に配置されるＶＭｊに対し、（式３）を用いて余裕度を計算する。
余裕度 Ｍ ＝ Σｊａｊ（Ｎｊ−Ｃｊ）  ・・・（式３）
ここで、Ｎｊは、所属希望の優先度グループの優先順位を示す。Ｃｊは、現所属の優先度グループの優先順位を示す。ａｊは、定数（ＶＭ１毎の重み）を示す。
なお、物理サーバ選択部３０は、この所属希望の優先度グループの優先順位Ｎｊの情報と、現所属の優先度グループの優先順位Ｃｊの情報とを、各物理サーバ１０に対応付けて記憶された、ＶＭ状態情報（図５）を参照することにより取得することができる。
【００９１】
余裕度計算ロジック「３」を用いることで、コントローラ２０は、所属希望の優先度グループの優先順位と、現所属の優先度グループの優先順位とを用いて、優先度の低い優先度グループに移行するＶＭ１が多いほど、その物理サーバ１０の余裕度が大きいものとして、マイグレーションの移行先となる物理サーバ１０を簡易に決定することが可能となる。
【００９２】
物理サーバ選択部３０は、３つの余裕度計算ロジックのうちのいずれかを用いて余裕度を計算する。そして、物理サーバ選択部３０は、最も余裕度の大きい物理サーバ１０をマイグレーション先の物理サーバ１０として選択する。
物理サーバ選択部３０は、ＶＭ選択部２９がマイグレーションの対象として選択したＶＭ１の情報と、マイグレーション先として選択した物理サーバ１０との情報を含むマイグレーション指示情報を生成し、性能保証不可警報情報で示されるＶＭ１を備える物理サーバ１０に送信する。
【００９３】
＜処理の流れ＞
次に、ＶＭマイグレーションシステム１００が実行する処理の流れについて説明する。
図７は、本実施形態に係るＶＭマイグレーションシステム１００が実行する処理の流れを示すフローチャートである。なお、図７は、ＶＭマイグレーションシステム１００を構成する複数の物理サーバ１０のうち、１台を代表して記載している。他の物理サーバ１０も同様の処理を実行する。
【００９４】
まず、物理サーバ１０の優先度グループ定義部１２は、各優先度グループに対応する物理リソース（ＣＰＵコア）において共有するＶＭ数（所属可能数：オーバーコミット率）の情報と、ＶＭ１それぞれがどの優先度グループ（優先度（優先順位）［１］〜［３］のグループ）に所属するかを示す情報とを、優先度グループ設定情報１４として記憶部に記憶する（ステップＳ１０）。
【００９５】
続いて、コントローラ２０のテストツール機能部２２および学習機能部２３により、テストツールを起動させて物理サーバ１０からテストツールの実行結果を取得し、ＶＭ１の性能値を算出するために必要となる学習結果データを生成する（ステップＳ１１）。この学習結果データを用いて、コントローラ２０の性能値推定部２４は、リアルタイムに更新される各ＶＭ１のリソース利用量のデータに基づき、性能値を計算することができる。
【００９６】
次に、物理サーバ１０のリソース利用量収集部１１は、所定時間が経過したか否かを判定する（ステップＳ１２）。所定時間が経過していない場合には（ステップＳ１２→Ｎｏ）、ステップＳ１２に戻り、所定時間が経過するまで待機する。一方、所定時間が経過した場合には（ステップＳ１２→Ｙｅｓ）、次のステップＳ１３へ進む。つまり、以降の処理は、所定の時間間隔で繰り返し実行されるものである。
【００９７】
ステップＳ１３において、物理サーバ１０のリソース利用量収集部１１が、各ＶＭ１についてのリソース利用量の情報を収集し、コントローラ２０に送信する。
また、ステップＳ１４において、物理サーバ１０の優先度グループ設定情報送信部１５は、記憶部内の優先度グループ設定情報１４を所定の時間間隔毎にコントローラ２０へ送信する。具体的には、優先度グループ設定情報送信部１５は、優先度グループ設定情報１４で示される、各優先度グループの物理リソース（ＣＰＵコア）において共有するＶＭ数（所属可能数）と、ＶＭ１それぞれがどの優先度グループ（優先度［１］〜［３］のグループ）に所属するかを示す情報とを、コントローラ２０に送信する。
なお、ステップＳ１３とステップＳ１４の処理の順序は問わず、どちらが先にコントローラ２０へ送信されてもよいし、同時に送信されてもよい。
【００９８】
続いて、コントローラ２０の所属希望グループ決定部２７は、データ取得部２１が物理サーバ１０から取得した、リソース利用量と優先度グループ設定情報１４とに基づき、各ＶＭ１について、性能不足および性能過多とならないような新たな所属先となる優先度グループ（所属希望優先度グループ）を決定するため、所属希望グループ決定処理を実行する（ステップＳ１５）。
具体的には、所属希望グループ決定部２７は、上記のように、優先度グループ設定情報１４を用いて、各優先度グループの空き所属数を計算し、優先度グループ状態情報２１０（図２）を生成する。続いて、所属希望グループ決定部２７は、各ＶＭ１のリソース利用量に基づき算出された性能値が、「性能不足領域」および「性能過多領域」に属するＶＭ１について、昇格グループ探索または降格グループ探索を行うことにより、所属希望優先度グループを決定し、ＶＭ状態情報２２０（図５）を生成する。
【００９９】
そして、所属希望グループ決定部２７は、ＶＭ状態情報２２０に格納した、各ＶＭ１についての新たな所属希望の優先度グループを、優先度グループ設定変更情報として、物理サーバ１０に送信する（ステップＳ１６）。
【０１００】
性能保証判定部１６は、コントローラ２０から優先度グループ設定変更情報を受信すると、その優先度グループ設定変更情報に含まれるＶＭ１の現所属の優先度グループを、新たな所属先となる優先度グループに変更可能か否かを、優先度グループ設定情報１４を参照して判定する（ステップＳ１７：性能保証可否判定）。
そして、性能保証判定部１６は、変更先の優先度グループに空きがあり、変更可であった場合には、その旨の情報を、優先度グループ変更部１３に出力し、優先度グループの変更を実行させ、優先度グループ設定情報１４を更新して処理を終える。一方、性能保証判定部１６は、変更先の優先度グループに空きがなく変更不可であった場合には、性能保証不可警報情報をコントローラ２０へ送信する（ステップＳ１８）。
【０１０１】
一方、コントローラ２０の性能保証可否判定部２８は、ＶＭ１の現時点（現所属）の優先度グループと、所属希望グループ決定部２７が決定した所属希望の優先度グループとの情報を用いて、ＳＬＡ等で規定される性能保証を実現できるか否かを所定のロジック（性能保証可否判定ロジック）に基づき判定する（ステップＳ１９：性能保証可否判定）。
この所定のロジック（性能保証可否判定ロジック）は、上記した（条件１）かつ（条件２）を満たすか否かで判定される。性能保証可否判定部２８は、（条件１）かつ（条件２）を満たさないと判定した場合に、性能保証不可とされたＶＭ１の属する優先度グループとその物理サーバ１０の識別情報とを含む性能保証不可警報情報を、ＶＭ選択部２９に出力する（ステップＳ２０）。
【０１０２】
次に、コントローラ２０のＶＭ選択部２９は、物理サーバ１０の性能保証判定部１６、コントローラ２０の性能保証可否判定部２８のいずれかまたは両方から性能保証不可警報情報を取得した場合、性能保証不可とされたＶＭ１の所属希望の優先度グループであって、空き所属がない優先度グループの現所属のＶＭ１の中から、所定のルールに基づき、マイグレーションの対象とするＶＭ１を選択する（ステップＳ２１）。例えば、ＶＭ選択部２９は、空き所属がない優先度グループに属するＶＭ１のうち、メモリ利用量が最も小さいＶＭ１を選択する。
【０１０３】
一方、コントローラ２０の物理サーバ選択部３０は、例えば、所定の時間間隔で、予め設定しておいた所定のロジック（余裕度計算ロジック「１」〜「３」のいずれか）に基づき、各物理サーバ１０の余裕度を計算し（ステップＳ２２）、物理サーバ状態情報２３０（図６）に格納しておく。
【０１０４】
そして、物理サーバ選択部３０は、ＶＭ選択部２９がマイグレーションの対象とするＶＭ１を選択したことを契機として、各物理サーバ１０の余裕度のうち、最も余裕度が大きい物理サーバ１０を、マイグレーション先の物理サーバ１０として選択する（ステップＳ２３）。
【０１０５】
続いて、物理サーバ選択部３０は、ＶＭ選択部２９がマイグレーションの対象として選択したＶＭ１の情報と、マイグレーション先として選択した物理サーバ１０の情報とを含むマイグレーション指示情報を生成し、性能保証不可警報情報で示されるＶＭ１を備える物理サーバ１０に送信する（ステップＳ２４）。
【０１０６】
次に、物理サーバ１０のＶＭマイグレーション実行部１７は、マイグレーション指示情報を受信し、マイグレーションの対象として選択されたＶＭ１について、選択された物理サーバ１０のＶＭマイグレーション実行部１７と連携しマイグレーションを実行する（ステップＳ２５）。そして、ＶＭマイグレーション実行部１７は、移行されたＶＭ１の情報に基づき、優先度グループ設定情報１４を更新する。
【０１０７】
続いて、物理サーバ１０の優先度グループ変更部１３が、現時点の優先度グループを、コントローラ２０から取得した優先度グループ設定変更情報で示されるＶＭ１の新たな所属先となる優先度グループに変更し（ステップＳ２６）、優先度グループ設定情報１４を更新して処理を終える。
【０１０８】
以上説明したように、本実施形態に係るＶＭマイグレーションシステム１００およびＶＭマイグレーション実行方法によれば、所属希望（所属候補）の優先度グループに空きがない場合であっても、最も余裕度の大きい物理サーバ１０をマイグレーション先の物理サーバとして選択し、ＶＭ１のマイグレーションを実行することにより、所属希望の優先度グループへの変更を可能とすることができる。よって、各ＶＭ１の性能保証を継続して実現することが可能となる。
【０１０９】
なお、本発明は、上記した本実施形態に限定されず、その趣旨を逸脱しない範囲で、変更実施が可能である。
例えば、本実施形態では、物理サーバ１０に性能保証判定部１６を備え、コントローラ２０にも性能保証可否判定部２８を備え、いずれかまたは両方から性能保証不可警報情報をコントローラ２０のＶＭ選択部２９が取得した場合、マイグレーションの対象とするＶＭ１を選択するものとした（図７のステップＳ２１）。しかしながら、物理サーバ１０側、コントローラ２０側のどちらか一方に、性能保証の可否を判定する機能を備えるようにしてもよい。これによっても同等の効果を得ることができる。
【符号の説明】
【０１１０】
１      ＶＭ（仮想ルータ）
１０    物理サーバ（コンピュート）
１１    リソース利用量収集部
１２    優先度グループ定義部
１３    優先度グループ変更部
１４    優先度グループ設定情報
１５    優先度グループ設定情報送信部
１６    性能保証判定部
１７    ＶＭマイグレーション実行部
２０    コントローラ
２１    データ取得部
２２    テストツール機能部
２３    学習機能部
２４    性能値推定部
２６    データ保存ＤＢ
２７    所属希望グループ決定部
２８    性能保証可否判定部
２９    ＶＭ選択部
３０    物理サーバ選択部
１００  ＶＭマイグレーションシステム
２１０  優先度グループ状態情報
２２０  ＶＭ状態情報
２３０  物理サーバ状態情報
【図１】
2019204309.tif 000003
【図２】
2019204309.tif 000004
【図３】
2019204309.tif 000005
【図４】
2019204309.tif 000006
【図５】
2019204309.tif 000007
【図６】
2019204309.tif 000008
【図７】
2019204309.tif 000009
【図８】
2019204309.tif 000010
【図９】
2019204309.tif 000011
【図１０】
2019204309.tif 000012
【図１１】
2019204309.tif 000013
【図１２】
2019204309.tif 000014
【図１３】
2019204309.tif 000015