JP6973292B2 - Ｖｍ優先度制御システムおよびｖｍ優先度制御方法 - Google Patents

Ｖｍ優先度制御システムおよびｖｍ優先度制御方法 Download PDF

Info

Publication number
JP6973292B2
JP6973292B2 JP2018099327A JP2018099327A JP6973292B2 JP 6973292 B2 JP6973292 B2 JP 6973292B2 JP 2018099327 A JP2018099327 A JP 2018099327A JP 2018099327 A JP2018099327 A JP 2018099327A JP 6973292 B2 JP6973292 B2 JP 6973292B2
Authority
JP
Japan
Prior art keywords
priority
priority group
group
affiliation
vms
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
JP2018099327A
Other languages
English (en)
Other versions
JP2019204305A (ja
Inventor
義人 伊藤
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Nippon Telegraph and Telephone Corp
Original Assignee
Nippon Telegraph and Telephone Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Nippon Telegraph and Telephone Corp filed Critical Nippon Telegraph and Telephone Corp
Priority to JP2018099327A priority Critical patent/JP6973292B2/ja
Priority to PCT/JP2019/019240 priority patent/WO2019225419A1/ja
Priority to US17/057,200 priority patent/US11714670B2/en
Publication of JP2019204305A publication Critical patent/JP2019204305A/ja
Application granted granted Critical
Publication of JP6973292B2 publication Critical patent/JP6973292B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5061—Partitioning or combining of resources
    • G06F9/5077—Logical partitioning of resources; Management or configuration of virtualized resources
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G06F9/5027—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals
    • G06F9/5038—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals considering the execution order of a plurality of tasks, e.g. taking priority or time dependency constraints into consideration
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/0893—Assignment of logical groups to network elements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/0895—Configuration of virtualised networks or elements, e.g. virtualised network function or OpenFlow elements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/40—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks using virtualisation of network functions or resources, e.g. SDN or NFV entities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/50—Network service management, e.g. ensuring proper service fulfilment according to agreements
    • H04L41/5003—Managing SLA; Interaction between SLA and QoS
    • H04L41/5009—Determining service level performance parameters or violations of service level contracts, e.g. violations of agreed response time or mean time between failures [MTBF]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/50—Network service management, e.g. ensuring proper service fulfilment according to agreements
    • H04L41/5003—Managing SLA; Interaction between SLA and QoS
    • H04L41/5019—Ensuring fulfilment of SLA
    • H04L41/5022—Ensuring fulfilment of SLA by giving priorities, e.g. assigning classes of service
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/50—Network service management, e.g. ensuring proper service fulfilment according to agreements
    • H04L41/5003—Managing SLA; Interaction between SLA and QoS
    • H04L41/5019—Ensuring fulfilment of SLA
    • H04L41/5025—Ensuring fulfilment of SLA by proactively reacting to service quality change, e.g. by reconfiguration after service quality degradation or upgrade
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G06F2009/45595—Network integration; Enabling network access in virtual machine instances
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2209/00—Indexing scheme relating to G06F9/00
    • G06F2209/50—Indexing scheme relating to G06F9/50
    • G06F2209/508—Monitor
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/50—Testing arrangements

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Quality & Reliability (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Computer And Data Communications (AREA)

Description

本発明は、ネットワーク仮想化技術を用いて、物理マシン上で共有される各ＶＭ（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」）と優先度グループを交換する（図１１（ａ）の両矢印参照）。その結果、変更後の現所属２２５は、図１１（ｂ）のようになる。優先度グループを交換した後、優先度変更先決定部２９は、ステータス２２２を「未完了」から「完了」に変換し処理を終える。
このようにすることにより、現所属２２５と所属希望２２６とに対になるものがない場合でも、性能保証を実現することができる。
なお、優先度変更先決定部２９は、（処理１）のみを実行するように設定しておいてもよいし、（処理１）（処理２）の両方を実行するように設定しておいてもよい。
優先度変更先決定部２９は、図１０に示すように、ＶＭ状態情報２２０のステータス２２２がすべて「完了」になると、空き判定２２７が「０」のＶＭ１の現所属２２５の情報を、優先度グループ設定変更情報として、物理サーバ１０に送信する。
＜処理の流れ＞
次に、ＶＭ優先度制御システム１００が実行する処理の流れについて図１２を参照して説明する。
図１２は、本実施形態に係るＶＭ優先度制御システム１００が実行する全体の処理の流れを示すフローチャートである。
まず、物理サーバ１０の優先度グループ定義部１２は、各優先度グループに対応する物理リソース（ＣＰＵコア）において共有するＶＭ数（所属可能数：オーバーコミット率）の情報と、ＶＭ１それぞれがどの優先度グループ（優先度（優先順位）［１］〜［３］のグループ）に所属するかを示す情報とを、優先度グループ設定情報１４として記憶部に記憶する（ステップＳ１０）。
続いて、コントローラ２０のテストツール機能部２２および学習機能部２３により、テストツールを起動させて物理サーバ１０からテストツールの実行結果を取得し、ＶＭ１の性能値を算出するために必要となる学習結果データを生成する（ステップＳ１１）。この学習結果データを用いて、コントローラ２０の性能値推定部２４は、リアルタイムに更新される各ＶＭ１のリソース利用量のデータに基づき、性能値を計算することができる。
次に、物理サーバ１０のリソース利用量収集部１１は、所定時間が経過したか否かを判定する（ステップＳ１２）。所定時間が経過していない場合には（ステップＳ１２→Ｎｏ）、ステップＳ１２に戻り、所定時間が経過するまで待機する。一方、所定時間が経過した場合には（ステップＳ１２→Ｙｅｓ）、次のステップＳ１３へ進む。つまり、以降の処理は、所定の時間間隔で繰り返し実行されるものである。
ステップＳ１３において、物理サーバ１０のリソース利用量収集部１１が、各ＶＭ１についてのリソース利用量の情報を収集し、コントローラ２０に送信する。
また、ステップＳ１４において、物理サーバ１０の優先度グループ設定情報送信部１５は、記憶部内の優先度グループ設定情報１４を所定の時間間隔毎にコントローラ２０へ送信する。具体的には、優先度グループ設定情報送信部１５は、優先度グループ設定情報１４で示される、各優先度グループの物理リソース（ＣＰＵコア）において共有するＶＭ数（所属可能数）と、ＶＭ１それぞれがどの優先度グループ（優先度［１］〜［３］のグループ）に所属するかを示す情報とを、コントローラ２０に送信する。
なお、ステップＳ１３とステップＳ１４の処理の順序は問わず、どちらが先にコントローラ２０へ送信されてもよいし、同時に送信されてもよい。
続いて、コントローラ２０の所属希望グループ決定部２７は、データ取得部２１が物理サーバ１０から取得した、リソース利用量と優先度グループ設定情報１４とに基づき、各ＶＭ１について、性能不足および性能過多とならないような新たな所属先となる優先度グループ（所属希望優先度グループ）を決定するため、所属希望グループ決定処理を実行する（ステップＳ１５）。なお、この所属希望グループ決定処理は、図２等より説明したため、詳細な説明は省略する。
このステップＳ１５の所属希望グループ決定処理により、所属希望グループ決定部２７は、例えば、図８に示すように、各ＶＭ１について所属希望２２６となる優先度グループを決定することができる。
次に、コントローラ２０の性能保証可否判定部２８は、ＶＭ１の現時点の優先度グループ（図８の現所属２２５）と、所属希望グループ決定部２７が決定した所属希望の優先度グループ（図８の所属希望２２６）との情報を用いて、ＳＬＡ等で規定される性能保証を実現できるか否かを所定のロジック（性能保証可否判定ロジック）に基づき判定する（ステップＳ１６）。
なお、性能保証可否判定部２８が、所定のロジック（性能保証可否判定ロジック）で示される上記した（条件１）かつ（条件２）を満たさない場合には、性能保証を実現できないと判定して処理を中止し、警報情報をＶＭ優先度制御システム１００の管理装置等に送信する。一方、（条件１）かつ（条件２）を満たす場合には、性能保証が実現できるものと判定し、以降の処理に進む。
続いて、コントローラ２０の優先度変更先決定部２９は、優先度グループの変更先決定処理を実行する（ステップＳ１７）。
具体的には、優先度変更先決定部２９は、ＶＭ状態情報２２０を参照し、空き判定２２７が「０」の各ＶＭ１について、現所属２２５と所属希望２２６が等しい場合に、優先度グループを変更する必要がないと決定し、ステータス２２２を「完了」にする。
一方、優先度変更先決定部２９は、ＶＭ状態情報２２０を参照し、空き判定２２７が「０」の各ＶＭ１について、現所属２２５と所属希望２２６が異なる場合に、上記した（処理１）（処理２）を実行する。
優先度変更先決定部２９は、（処理１）により、他のＶＭ１（ダミーのＶＭを含む）との間で現所属２２５と所属希望２２６とが対（所属する優先度グループの対が反対であり入れ替えると一致する所属関係）になるものがある場合には、そのＶＭ１と優先度グループの現所属を交換することにより、優先度グループの変更先を決定する。
また、優先度変更先決定部２９は、（処理２）により、他のＶＭ１（ダミーのＶＭを含む）に、現所属２２５と所属希望２２６とが対になるものがない場合に、空き判定「１」のダミーのＶＭの現所属が、その対のないＶＭ１の所属希望以上のものと優先度グループの現所属を交換することにより、優先度グループの変更先を決定する。
優先度変更先決定部２９は、変更された現所属２２５の優先度グループの情報を含む優先度グループ設定変更情報を生成し、物理サーバ１０へ送信する（ステップＳ１８）。
物理サーバ１０の優先度グループ変更部１３は、受信した優先度グループ設定変更情報を参照し、現時点の優先度グループと異なる優先度グループが設定されているＶＭ１について、優先度グループを変更する（ステップＳ１９）。この際、優先度グループ変更部１３は、当該ＶＭ１について新たに所属する優先度グループに基づき、優先度グループ設定情報１４を更新し、処理を終える。
以上説明したように、本実施形態に係るＶＭ優先度制御システム１００およびＶＭ優先度制御方法によれば、優先度グループの空き所属を、ダミーのＶＭとして扱い、そのダミーのＶＭも含めて、優先度グループの所属先を調整する。これにより、所属希望の優先度グループに空きがない場合であっても、より確実にＶＭの性能保証を実現しつつ、リソース利用効率の高めることができる。
１ ＶＭ（仮想ルータ）
１０ 物理サーバ（コンピュート）
１１ リソース利用量収集部
１２ 優先度グループ定義部
１３ 優先度グループ変更部
１４ 優先度グループ設定情報
１５ 優先度グループ設定情報送信部
２０ コントローラ
２１ データ取得部
２２ テストツール機能部
２３ 学習機能部
２４ 性能値推定部
２６ データ保存ＤＢ
２７ 所属希望グループ決定部
２８ 性能保証可否判定部
２９ 優先度変更先決定部
１００ ＶＭ優先度制御システム
２１０ 優先度グループ状態情報
２２０ ＶＭ状態情報

Claims (4)

  1. 複数のＶＭ（Virtual Machine）を稼働させる物理サーバと、前記物理サーバに接続され、前記ＶＭの稼働状態を管理するコントローラとを備えるＶＭ優先度制御システムであって、
    前記物理サーバは、
    当該物理サーバが有する物理リソースを複数のグループに分割し、当該分割したグループそれぞれに共有できるＶＭ数である所属可能数を異なるように設定して、前記共有できるＶＭ数が少ないほど優先度が高い優先度グループとし、前記優先度グループそれぞれとその優先度グループの物理リソース上で稼働させるＶＭとの対応関係を格納する優先度グループ設定情報が記憶される記憶部と、
    前記ＶＭそれぞれが稼働する際のリソース利用量を収集し、前記コントローラに送信するリソース利用量収集部と、
    前記優先度グループ設定情報を、前記コントローラに送信する優先度グループ設定情報送信部と、
    前記ＶＭそれぞれに対する前記優先度グループの変更指示を示す優先度グループ設定変更情報を前記コントローラから受信すると、前記優先度グループ設定情報を参照し、当該ＶＭが属する優先度グループを新たな優先度グループに変更する優先度グループ変更部と、を備え、
    前記コントローラは、
    前記物理サーバから前記ＶＭそれぞれのリソース利用量および前記優先度グループ設定情報を取得するデータ取得部と、
    各ＶＭが所定の第１の閾値未満の性能である性能不足および所定の第２の閾値以上の性能である性能過多とならないような所属先となる所属希望の優先度グループを、各ＶＭの前記リソース利用量を用いて、各ＶＭが優先度グループそれぞれに所属した場合の性能値を算出することにより決定するとともに、前記優先度グループ設定情報を参照し、各優先度グループのＶＭの所属可能数から現所属のＶＭの数を減じた空き所属数を算出し、前記空き所属数分のダミーのＶＭを当該空きのある優先度グループに所属するものとして生成し、生成した前記ダミーのＶＭに関する所属希望の優先度グループを最も優先度の低い優先度グループとして決定する所属希望グループ決定部と、
    各ＶＭの現所属の優先度グループと、決定された前記所属希望の優先度グループとの情報を用いて、所定の性能保証可否判定ロジックに基づき、各ＶＭの性能保証が実現できるか否かを判定する性能保証可否判定部と、
    前記性能保証が実現できると判定された場合に、各ＶＭおよび前記ダミーのＶＭについての前記現所属の優先度グループと前記所属希望の優先度グループの組に関し、所属する優先度グループの対が反対であり入れ替えると一致する所属関係となる前記組との間で、現所属の優先度グループを交換することで得られる優先度グループを新たな現所属の優先度グループとして決定し、決定した前記新たな現所属の優先度グループの情報を含む前記優先度グループ設定変更情報を生成し前記物理サーバに送信する優先度変更先決定部と、
    を備えることを特徴とするＶＭ優先度制御システム。
  2. 前記所定の性能保証可否判定ロジックは、前記優先度グループの優先度について、優先度の高い方から昇順の優先順位とし、以下の（条件１）かつ（条件２）を満たすこと
    Σ（所属希望の優先度グループの優先順位 − 現所属の優先度グループの優先順位） ≦ ０ ・・・（条件１）、
    優先順位ａの優先度グループを希望するＶＭ数 ≦ 優先順位ａ以上の優先度グループでのＶＭの所属可能総数 ・・・（条件２）
    （ａは、すべての優先順位のうちの任意の優先順位を示す）
    を特徴とする請求項１に記載のＶＭ優先度制御システム。
  3. 前記優先度変更先決定部は、前記現所属の優先度グループと前記所属希望の優先度グループの組に関し、前記所属する優先度グループの対が反対であり入れ替えると一致する所属関係となる組がない場合に、前記ダミーのＶＭのうち、その現所属の優先度グループが、前記所属する優先度グループの対が反対であり入れ替えると一致する所属関係となる組がないＶＭにおける所属希望の優先度グループの優先度以上である前記ダミーのＶＭを特定し、前記特定したダミーのＶＭの現所属の優先度グループと、前記所属する優先度グループの対が反対であり入れ替えると一致する所属関係となる組がないＶＭの現所属の優先度グループとを交換することで得られる優先度グループを前記新たな現所属の優先度グループとして決定すること
    を特徴とする請求項１または請求項２に記載のＶＭ優先度制御システム。
  4. 複数のＶＭを稼働させる物理サーバと、前記物理サーバに接続され、前記ＶＭの稼働状態を管理するコントローラとを備えるＶＭ優先度制御システムのＶＭ優先度制御方法であって、
    前記物理サーバは、
    当該物理サーバが有する物理リソースを複数のグループに分割し、当該分割したグループそれぞれに共有できるＶＭ数である所属可能数を異なるように設定して、前記共有できるＶＭ数が少ないほど優先度が高い優先度グループとし、前記優先度グループそれぞれとその優先度グループの物理リソース上で稼働させるＶＭとの対応関係を格納する優先度グループ設定情報が記憶される記憶部を備えており、
    前記ＶＭそれぞれが稼働する際のリソース利用量を収集し、前記コントローラに送信するステップと、
    前記優先度グループ設定情報を、前記コントローラに送信するステップと、を実行し、
    前記コントローラは、
    前記物理サーバから前記ＶＭそれぞれのリソース利用量および前記優先度グループ設定情報を取得するステップと、
    各ＶＭが所定の第１の閾値未満の性能である性能不足および所定の第２の閾値以上の性能である性能過多とならないような所属先となる所属希望の優先度グループを、各ＶＭの前記リソース利用量を用いて、各ＶＭが優先度グループそれぞれに所属した場合の性能値を算出することにより決定するとともに、前記優先度グループ設定情報を参照し、各優先度グループのＶＭの所属可能数から現所属のＶＭの数を減じた空き所属数を算出し、前記空き所属数分のダミーのＶＭを当該空きのある優先度グループに所属するものとして生成し、生成した前記ダミーのＶＭに関する所属希望の優先度グループを最も優先度の低い優先度グループとして決定するステップと、
    各ＶＭの現所属の優先度グループと、決定された前記所属希望の優先度グループとの情報を用いて、所定の性能保証可否判定ロジックに基づき、各ＶＭの性能保証が実現できるか否かを判定するステップと、
    前記性能保証が実現できると判定された場合に、各ＶＭおよび前記ダミーのＶＭについての前記現所属の優先度グループと前記所属希望の優先度グループの組に関し、所属する優先度グループの対が反対であり入れ替えると一致する所属関係となる前記組との間で、現所属の優先度グループを交換することで得られる優先度グループを新たな現所属の優先度グループとして決定し、決定した前記新たな現所属の優先度グループの情報を含む優先度グループ設定変更情報を生成し前記物理サーバに送信するステップと、を実行し、
    前記物理サーバは、
    前記優先度グループ設定変更情報を前記コントローラから受信すると、前記優先度グループ設定情報を参照し、前記新たな現所属の優先度グループが示されたＶＭについて、その優先度グループを新たな優先度グループに変更するステップを実行すること
    を特徴とするＶＭ優先度制御方法。
JP2018099327A 2018-05-24 2018-05-24 Ｖｍ優先度制御システムおよびｖｍ優先度制御方法 Active JP6973292B2 (ja)

Priority Applications (3)

Application Number Priority Date Filing Date Title
JP2018099327A JP6973292B2 (ja) 2018-05-24 2018-05-24 Ｖｍ優先度制御システムおよびｖｍ優先度制御方法
PCT/JP2019/019240 WO2019225419A1 (ja) 2018-05-24 2019-05-15 Ｖｍ優先度制御システムおよびｖｍ優先度制御方法
US17/057,200 US11714670B2 (en) 2018-05-24 2019-05-15 VM priority level control system and VM priority level control method

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2018099327A JP6973292B2 (ja) 2018-05-24 2018-05-24 Ｖｍ優先度制御システムおよびｖｍ優先度制御方法

Publications (2)

Publication Number Publication Date
JP2019204305A JP2019204305A (ja) 2019-11-28
JP6973292B2 true JP6973292B2 (ja) 2021-11-24

Family

ID=68616511

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2018099327A Active JP6973292B2 (ja) 2018-05-24 2018-05-24 Ｖｍ優先度制御システムおよびｖｍ優先度制御方法

Country Status (3)

Country Link
US (1) US11714670B2 (ja)
JP (1) JP6973292B2 (ja)
WO (1) WO2019225419A1 (ja)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11853807B1 (en) 2020-12-01 2023-12-26 Amazon Technologies, Inc. Cluster scaling based on task state information
US11995466B1 (en) * 2021-06-30 2024-05-28 Amazon Technologies, Inc. Scaling down computing resource allocations for execution of containerized applications
US11989586B1 (en) * 2021-06-30 2024-05-21 Amazon Technologies, Inc. Scaling up computing resource allocations for execution of containerized applications

Family Cites Families (22)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8185894B1 (en) * 2008-01-10 2012-05-22 Hewlett-Packard Development Company, L.P. Training a virtual machine placement controller
JP5400482B2 (ja) * 2009-06-04 2014-01-29 株式会社日立製作所 管理計算機、リソース管理方法、リソース管理プログラム、記録媒体および情報処理システム
US8464255B2 (en) * 2010-03-12 2013-06-11 Microsoft Corporation Managing performance interference effects on cloud computing servers
US9477286B2 (en) * 2010-11-05 2016-10-25 International Business Machines Corporation Energy allocation to groups of virtual machines
US8918784B1 (en) * 2010-12-21 2014-12-23 Amazon Technologies, Inc. Providing service quality levels through CPU scheduling
US9710295B2 (en) * 2011-04-20 2017-07-18 Nec Corporation Grouping and placement of virtual machines based on similarity and correlation of functional relations
US20170206107A1 (en) * 2012-02-14 2017-07-20 Aloke Guha Systems And Methods For Provisioning Of Storage For Virtualized Applications
WO2014032287A1 (zh) * 2012-08-31 2014-03-06 华为技术有限公司 中央处理器资源分配方法和计算节点
US9047111B2 (en) * 2012-09-06 2015-06-02 International Business Machines Corporation Resource allocation in a virtualized computing environment
JP6191686B2 (ja) * 2013-03-21 2017-09-06 富士通株式会社 情報処理装置、資源割当方法、及びプログラム
US8904389B2 (en) * 2013-04-30 2014-12-02 Splunk Inc. Determining performance states of components in a virtual machine environment based on performance states of related subcomponents
US9207976B2 (en) * 2013-08-13 2015-12-08 International Business Machines Corporation Management of prioritizing virtual machines in an operating environment
US9389900B2 (en) * 2014-04-29 2016-07-12 Vmware, Inc. Method and system for supporting a change in state within a cluster of host computers that run virtual machines
US9529619B2 (en) * 2014-09-30 2016-12-27 Nicira, Inc. Method of distributing network policies of virtual machines in a datacenter
JP6349264B2 (ja) * 2015-01-19 2018-06-27 株式会社日立製作所 計算資源割当て方法およびシステム
JP2018026042A (ja) * 2016-08-12 2018-02-15 富士通株式会社 移動制御プログラム、移動制御装置及び移動制御方法
US11204702B2 (en) * 2017-08-15 2021-12-21 Red Hat Israel, Ltd. Storage domain growth management
JP6795536B2 (ja) * 2018-03-12 2020-12-02 日本電信電話株式会社 Ｖｍ性能保証システムおよびｖｍ性能保証方法
JP6969499B2 (ja) * 2018-05-24 2021-11-24 日本電信電話株式会社 Ｖｍマイグレーションシステムおよびｖｍマイグレーション方法
US10831610B2 (en) * 2018-06-28 2020-11-10 EMC IP Holding Company System and method for adaptive backup workflows in dynamic priority environment
US11163647B2 (en) * 2019-04-23 2021-11-02 EMC IP Holding Company LLC System and method for selection of node for backup in distributed system
US20220229679A1 (en) * 2021-01-15 2022-07-21 Microsoft Technology Licensing, Llc Monitoring and maintaining health of groups of virtual machines

Also Published As

Publication number Publication date
JP2019204305A (ja) 2019-11-28
US20210191748A1 (en) 2021-06-24
WO2019225419A1 (ja) 2019-11-28
US11714670B2 (en) 2023-08-01

Similar Documents

Publication Publication Date Title
JP6969499B2 (ja) Ｖｍマイグレーションシステムおよびｖｍマイグレーション方法
US11200486B2 (en) Convolutional neural networks on hardware accelerators
WO2020258920A1 (zh) 一种网络切片资源管理方法及设备
CN110869909B (zh) 应用机器学习算法来计算健康分数以进行工作负载调度的系统和方法
EP3553657A1 (en) Method and device for allocating distributed system task
Karthiban et al. An efficient green computing fair resource allocation in cloud computing using modified deep reinforcement learning algorithm
CN107239336B (zh) 一种实现任务调度的方法及装置
CN107111517B (zh) 针对归约器任务的虚拟机优化分配和/或生成
US20160350146A1 (en) Optimized hadoop task scheduler in an optimally placed virtualized hadoop cluster using network cost optimizations
KR20160087706A (ko) 가상화 플랫폼을 고려한 분산 데이터 처리 시스템의 자원 할당 장치 및 할당 방법
CN107003887A (zh) Cpu超载设置和云计算工作负荷调度机构
JP6973292B2 (ja) Ｖｍ優先度制御システムおよびｖｍ優先度制御方法
EP3506575B1 (en) Method and device for data transmission
Modarressi et al. Using task migration to improve non-contiguous processor allocation in NoC-based CMPs
Liu et al. Deadline guaranteed service for multi-tenant cloud storage
JP6795536B2 (ja) Ｖｍ性能保証システムおよびｖｍ性能保証方法
Stavrinides et al. Orchestrating bag-of-tasks applications with dynamically spawned tasks in a distributed environment
Wided et al. A novel agent based load balancing model for maximizing resource utilization in grid computing
Lin et al. Joint deadline-constrained and influence-aware design for allocating MapReduce jobs in cloud computing systems
JP2019149043A (ja) 見積り装置および見積り方法
Miranda et al. Dynamic communication-aware scheduling with uncertainty of workflow applications in clouds
Soryani et al. Improving inter-node communications in multi-core clusters using a contention-free process mapping algorithm
Na et al. Optimal service placement using pseudo service chaining mechanism for cloud-based multimedia services
JP2016099972A (ja) プロセスマイグレーション方法及びクラスタシステム
Xu et al. Service placement strategy for joint network selection and resource scheduling in edge computing

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20200824

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20211005

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20211018

R150 Certificate of patent or registration of utility model

Ref document number: 6973292

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150