JP6969499B2 - Vmマイグレーションシステムおよびvmマイグレーション方法 - Google Patents

Vmマイグレーションシステムおよびvmマイグレーション方法 Download PDF

Info

Publication number
JP6969499B2
JP6969499B2 JP2018099347A JP2018099347A JP6969499B2 JP 6969499 B2 JP6969499 B2 JP 6969499B2 JP 2018099347 A JP2018099347 A JP 2018099347A JP 2018099347 A JP2018099347 A JP 2018099347A JP 6969499 B2 JP6969499 B2 JP 6969499B2
Authority
JP
Japan
Prior art keywords
priority group
priority
physical server
performance
information
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
JP2018099347A
Other languages
English (en)
Other versions
JP2019204309A (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 JP2018099347A priority Critical patent/JP6969499B2/ja
Priority to US17/057,339 priority patent/US12001868B2/en
Priority to PCT/JP2019/019279 priority patent/WO2019225429A1/ja
Publication of JP2019204309A publication Critical patent/JP2019204309A/ja
Application granted granted Critical
Publication of JP6969499B2 publication Critical patent/JP6969499B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements 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/44Arrangements for executing specific programs
    • G06F9/455Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533Hypervisors; Virtual machine monitors
    • G06F9/45558Hypervisor-specific management and integration aspects
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements 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/46Multiprogramming arrangements
    • G06F9/50Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5005Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G06F9/5027Allocation 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/5038Allocation 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
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements 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/46Multiprogramming arrangements
    • G06F9/50Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5083Techniques for rebalancing the load in a distributed system
    • G06F9/5088Techniques for rebalancing the load in a distributed system involving task migration
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements 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/44Arrangements for executing specific programs
    • G06F9/455Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533Hypervisors; Virtual machine monitors
    • G06F9/45558Hypervisor-specific management and integration aspects
    • G06F2009/4557Distribution of virtual machine instances; Migration and load balancing

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Hardware Redundancy (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Description

本発明は、ネットワーク仮想化技術を用いて、物理マシン上で共有される各VM(Virtual Machine:仮想マシン)の性能を保証するように各VMのマイグレーションを実行する、VMマイグレーションシステムおよびVMマイグレーション方法に関する。
物理サーバ上で複数のVMを稼働させる一般的な仮想化環境では、サーバリソースは全VMで共有される。そして、その共有の仕方は、ハイパーバイザおよびホストOS(Operating System)のスケジューラに一任され、制御することができない。仮想化環境として広く用いられているOpenStackでも、例えば物理CPU(pCPU)は物理サーバ上の全VMに共有される。
一方、VMを専用の物理CPU(CPUコア)に固定化(ピニング)する技術が開示されている(非特許文献1)。
上記のような従来技術では、物理サーバ上の複数のVMを、どの物理CPUで稼働させるかに関し、共有の程度を制御することはできない。このため、ネットワーク機能としてサービスの性能保証が求められる場合において、OpenStackをはじめとする仮想化環境では特に制御を行わないと、リソースが制御できない形で共有されてしまいVMの性能保証を行うことができなかった。
また、リソースを占有して固定的にVMを割り当てる手法を用いてしまうと、仮想化本来のメリットである柔軟な構成を用いることや、リソースの有効活用ができないという結果となる。
このような問題に対し、リソースの利用効率を高めつつ、VMの性能保証を実現することができるシステム(後記する図13の「VM性能保証システム100a」)が提案されている(非特許文献2参照)。
非特許文献2に記載のシステム(VM性能保証システム100a)は、複数のVMを備える物理サーバ(コンピュート)と、コントローラとを備えて構成される。このVM性能保証システム100aでは、物理リソースを複数のグループに分割し、共有できるVM数の異なる優先度グループを定義しておく。そして、コントローラが、VMのリソース利用量に基づき、性能不足もしくは性能過多と判定した場合に、物理サーバにおいて、そのVMの優先度グループを変更する。これにより、物理サーバの物理リソースを有効活用した上で、VMの性能保証を実現することができる。
「Red Hat OpenStack Platform インスタンス&イメージガイド 第4章 NUMAノードを使用するCPUピニングの設定」、[online]、Red Hat、[平成30年5月1日検索]、インターネット<URL:https://access.redhat.com/documentation/ja-jp/red_hat_openstack_platform/9/html/instances_and_images_guide/ch-cpu_pinning> 伊藤義人、「VNF性能保証システムのプロトタイプ実装」、[online]、社団法人電子情報通信学会、第15回ネットワークソフトウェア研究会のWebサイトにて2018年1月12日に講演原稿を掲載、インターネット<http://www.ieice.org/cs/ns/nws/20180118_nwspaper.zip>(特願2018-044010にて新規性喪失の例外を申請)
非特許文献2に記載した技術によれば、リソース利用効率を高めつつ、VMの性能保証を実現することが可能となる。しかしながら、以下に示す点において、さらに改善する余地があった。
非特許文献2に記載のVM性能保証システム100aにおいて、VMのリソース共有数の異なる優先度グループでは、リソース利用効率を高めるため、または、VMの性能保証を実現するために、VMの所属するグループを変更する。その際、変更先となる優先度グループに空きがあることが必要となる。一方、リソースの効率利用の観点から、優先度グループの空きが最小となるようにVMは物理サーバに配置されるため、VMを変更できる十分な空きが存在しないケースが生じる。
このように、性能保証を実現するためにそのVMの所属する優先度グループを変更しようとし変更できなかった場合に、VM性能保証システム100aでは、システムの管理装置等に警報情報を送信することとしている。しかしながら実運用では、性能保証が実現できない時間をできるだけ少なくするとともに、管理装置等におけるオペレータの処理負荷を低減するため、各VMに対して、性能保証を実現するようにシステムにおいて自律的に制御できることが望ましい。
このような点を鑑みて本発明がなされたのであり、本発明は、所属希望(所属候補)の優先度グループに空きがない場合であっても、VMのマイグレーションを実行し、性能保証を継続して実現することができる、VMマイグレーションシステムおよびVMマイグレーション方法を提供することを課題とする。
前記した課題を解決するため、請求項1に記載の発明は、複数のVM(Virtual Machine)を稼働させる複数の物理サーバと、前記物理サーバそれぞれに接続され、前記VMの稼働状態を管理するコントローラとを備えるVMマイグレーションシステムであって、前記物理サーバそれぞれが、当該物理サーバが有する物理リソースを複数のグループに分割し、当該分割したグループそれぞれに共有できるVM数である所属可能数を異なるように設定して、前記共有できるVM数が少ないほど優先度が高い優先度グループとし、前記優先度グループそれぞれとその優先度グループの物理リソース上で稼働させるVMとの対応関係を格納する優先度グループ設定情報が記憶される記憶部と、前記VMそれぞれが稼働する際のリソース利用量を収集し、前記コントローラに送信するリソース利用量収集部と、前記優先度グループ設定情報を、前記コントローラに送信する優先度グループ設定情報送信部と、前記コントローラから、マイグレーションの対象となるVMの情報および前記マイグレーションの移行先となる他の物理サーバの情報を含むマイグレーション指示情報を受信し、前記マイグレーションの対象となるVMの前記他の物理サーバへのマイグレーションを実行するVMマイグレーション実行部と、前記VMそれぞれに対する前記優先度グループの変更指示を示す優先度グループ設定変更情報を前記コントローラから受信すると、前記優先度グループ設定情報を参照し、当該VMが属する優先度グループを新たな優先度グループに変更する優先度グループ変更部と、を備え、前記コントローラが、前記物理サーバから前記VMそれぞれのリソース利用量および前記優先度グループ設定情報を取得するデータ取得部と、各VMが所定の第1の閾値未満の性能である性能不足および所定の第2の閾値以上の性能である性能過多とならないような所属先となる所属希望の優先度グループを、各VMの前記リソース利用量を用いて、各VMが優先度グループそれぞれに所属した場合の性能値を算出することにより決定する所属希望グループ決定部と、前記優先度グループ設定情報で示される現所属の優先度グループの情報、および、決定した前記所属希望の優先度グループの情報を用いて、各VMについての性能保証の可否を判定し、前記性能保証が不可の場合に性能保証不可警報情報を出力する性能保証可否判定部と、前記性能保証不可警報情報を取得すると、前記優先度グループ設定情報を参照し、当該性能保証不可警報情報に含まれる前記性能保証が不可とされたVMの所属希望の優先度グループであって、空き所属がない優先度グループの現所属のVMの中から、所定のルールに基づき、前記マイグレーションの対象とするVMを選択するVM選択部と、各物理サーバの処理能力についての余裕の度合を示す余裕度を、所定のロジックに基づき計算し、前記余裕度の最も大きい物理サーバを前記マイグレーションの移行先となる前記他の物理サーバとして選択するとともに、前記マイグレーション指示情報を生成し、前記性能保証が不可とされたVMを備える物理サーバに送信する物理サーバ選択部と、を備えることを特徴とするVMマイグレーションシステムとした。
また、請求項6に記載の発明は、複数のVMを稼働させる複数の物理サーバと、前記物理サーバそれぞれに接続され、前記VMの稼働状態を管理するコントローラとを備えるVMマイグレーションシステムのVMマイグレーション方法であって、前記物理サーバが、当該物理サーバが有する物理リソースを複数のグループに分割し、当該分割したグループそれぞれに共有できるVM数である所属可能数を異なるように設定して、前記共有できるVM数が少ないほど優先度が高い優先度グループとし、前記優先度グループそれぞれとその優先度グループの物理リソース上で稼働させるVMとの対応関係を格納する優先度グループ設定情報が記憶される記憶部を備えており、前記VMそれぞれが稼働する際のリソース利用量を収集し、前記コントローラに送信するステップと、前記優先度グループ設定情報を、前記コントローラに送信するステップと、を実行し、前記コントローラが、前記物理サーバから前記VMそれぞれのリソース利用量および前記優先度グループ設定情報を取得するステップと、各VMが所定の第1の閾値未満の性能である性能不足および所定の第2の閾値以上の性能である性能過多とならないような所属先となる所属希望の優先度グループを、各VMの前記リソース利用量を用いて、各VMが優先度グループそれぞれに所属した場合の性能値を算出することにより決定するステップと、前記優先度グループ設定情報で示される現所属の優先度グループの情報、および、決定した前記所属希望の優先度グループの情報を用いて、各VMについての性能保証の可否を判定し、前記性能保証が不可の場合に性能保証不可警報情報を出力するステップと、前記性能保証不可警報情報を取得すると、前記優先度グループ設定情報を参照し、当該性能保証不可警報情報に含まれる前記性能保証が不可とされたVMの所属希望の優先度グループであって、空き所属がない優先度グループの現所属のVMの中から、所定のルールに基づき、マイグレーションの対象とするVMを選択するステップと、各物理サーバの処理能力についての余裕の度合を示す余裕度を、所定のロジックに基づき計算し、前記余裕度の最も大きい物理サーバを前記マイグレーションの移行先となる前記他の物理サーバとして選択するとともに、前記マイグレーションの対象となるVMの情報および前記マイグレーションの移行先となる他の物理サーバの情報を含むマイグレーション指示情報を生成し、前記性能保証が不可とされたVMを備える物理サーバに送信するステップと、を実行し、前記物理サーバが、前記コントローラから、前記マイグレーション指示情報を受信し、前記マイグレーションの対象となるVMの前記他の物理サーバへのマイグレーションを実行するステップと、前記VMそれぞれに対する前記優先度グループの変更指示を示す優先度グループ設定変更情報を前記コントローラから受信して、前記優先度グループ設定情報を参照し、当該VMが属する優先度グループを新たな優先度グループに変更するステップと、を実行することを特徴とするVMマイグレーション方法とした。
このように、VMマイグレーションシステムは、物理サーバから取得した各VMのリソース利用量および優先度グループ設定情報に基づき、コントローラが、性能不足となったVMについて、性能保証を実現できる所属希望(所属候補)の優先度グループを決定する。そして、VMマイグレーションシステムは、所属希望の優先度グループに空きがなく、そのVMの優先度グループの変更ができない場合に、空き所属がない優先度グループの現所属のVMの中から、マイグレーションの対象とするVMを選択し、物理サーバの処理能力の余裕を示す余裕度が最も大きい物理サーバをマイグレーションの移行先の他の物理サーバに選択して、マイグレーション指示情報として物理サーバに送信する。物理サーバは、選択されたVMの他の物理サーバへのマイグレーションを実行することにより、VMの優先度グループの変更を可能とする。
これにより、VMマイグレーションシステムによれば、所属希望の優先度グループに空きがない場合であっても、VMのマイグレーションを実行し、性能保証を継続して実現することができる。
請求項2に記載の発明は、前記余裕度を計算する前記所定のロジックが、(式1)であり、
余裕度 M = S ・・・(式1)
ここで、Sは、各物理サーバkの空きVM数を示し、前記物理サーバ選択部が、前記優先度グループ設定情報を参照し、前記空きVM数を、各優先度グループの所属可能数から現所属のVM数を減じた空き所属数について、当該物理サーバに設定された全ての優先度グループについて合計することにより得ること、を特徴とする請求項1に記載のVMマイグレーションシステムとした。
このようにすることで、コントローラは、各物理サーバについて空きVM数が多いほど余裕度が大きいものとして、マイグレーションの移行先となる物理サーバを簡易に決定することが可能となる。
請求項3に記載の発明は、前記余裕度を計算する前記所定のロジックが、(式2)であり、
余裕度 M = Σ/P ・・・(式2)
ここで、Eは、優先度グループiにおける空き所属数を示し、Pは、優先度グループについて優先度の高い方から昇順に並べた場合の優先度グループiの優先順位を示し、aは、定数(優先度グループiの重み)を示し、前記物理サーバ選択部は、前記優先度グループ設定情報を参照し、前記空き所属数を、各優先度グループの所属可能数から現所属のVM数を減じることにより計算すること、を特徴とする請求項1に記載のVMマイグレーションシステムとした。
このようにすることで、コントローラは、優先度グループの空き所属数と、優先度グループの優先順位とを用いて、優先順位が高い優先度グループに空き所属が多いほど、その物理サーバの余裕度が大きいものとして、マイグレーションの移行先となる物理サーバを簡易に決定することが可能となる。
請求項4に記載の発明は、前記余裕度を計算する前記所定のロジックは、(式3)であり、
余裕度 M = Σ(N−C) ・・・(式3)
ここで、Nは、所属希望の優先度グループについて優先度の高い方から昇順に並べた場合の優先度グループの優先順位を示し、Cは、VMjの現所属の優先度グループの優先順位を示し、aは、定数(VMjの重み)を示すこと、を特徴とする請求項1に記載のVMマイグレーションシステムとした。
このようにすることで、コントローラは、所属希望の優先度グループの優先順位と、現所属の優先度グループの優先順位とを用いて、優先度の低い優先度グループに移行するVMが多いほど、その物理サーバの余裕度が大きいものとして、マイグレーションの移行先となる物理サーバを簡易に決定することが可能となる。
請求項5に記載の発明は、前記コントローラが、前記性能保証可否判定部を備えておらず、前記物理サーバが、替わりに、前記優先度グループ設定変更情報を前記コントローラから受信した場合に、変更指示された優先度グループの所属に空きがなく変更不可であるときに、前記性能保証不可警報情報を前記コントローラに送信する性能保証判定部を備えることを特徴とする請求項1ないし請求項4のいずれか1項に記載のVMマイグレーションシステムとした。
このようにすることで、コントローラ側に性能保証の可否を判定する機能(性能保証可否判定部)が備わっていない場合でも、物理サーバで実際にVMの優先度グループの変更が不可の場合に、性能保証不可警報情報をコントローラに送信することができる。よって、確実にVMのマイグレーションを実行し、性能保証を継続して実現することができる。
本発明によれば、所属希望(所属候補)の優先度グループに空きがない場合であっても、VMのマイグレーションを実行し、性能保証を継続して実現する、VMマイグレーションシステムおよびVMマイグレーション方法を提供することができる。
本実施形態に係るVMマイグレーションシステムを構成する複数の物理サーバおよびコントローラの機能ブロック図である。 本実施形態に係る優先度グループ状態情報のデータ構成例を示す図である。 本実施形態に係るVM状態情報のデータ構成例(初期設定)を示す図である。 本実施形態に係る所属希望グループ決定部による、降格グループ探索と、昇格グループ探索の結果を示す図である。 本実施形態に係るVM状態情報のデータ構成例を示す図である。 本実施形態に係る物理サーバ状態情報のデータ構成例を示す図である。 本実施形態に係るVMマイグレーションシステムが実行する処理の流れを示すフローチャートである。 VMの負荷が増大した場合に、リソース割当を増やす従来の手法を説明するための図である。 VMの負荷が増大した場合に、共有するVM数を変更する処理を説明するための図である。 物理サーバにおいて、リソースを優先度の異なるグループに分割することを説明するための図である。 優先度グループの変更処理を説明するための図である。 優先度グループの変更により、VMの性能保証が実現することを説明するための図である。 VM性能保証システムを構成する物理サーバおよびコントローラの機能ブロック図である。
本発明を実施するための形態(以下、「本実施形態」という。)について説明する前に、本発明の前提となるシステム(VM性能保証システム100a)を比較例として説明する。
<比較例>
本発明の比較例であるVM性能保証システム100aは、後記する図13で示すように、複数のVM1を備える物理サーバ10a(コンピュート)と、コントローラ20aとを備えて構成される。そして、このVM性能保証システム100aは、物理サーバ10aの利用効率を高めつつ、VM1の性能保証を実現するため、以下に示す技術的特徴を備える。
従来、図8に示すように、例えば、1つの物理リソース(CPUコア:図8の●印)に1つのVM1(図8では1つのVM1に2つの仮想CPU(図8の〇印)を備える。)が稼働する状況において、VM1の負荷が増大した場合、物理リソースの割り当てを増やす、つまり、CPUコアを追加しVM1へのリソース割当量を変更することにより、VM1の性能低下を防いでいた。具体的には、図8の左図のVM1の負荷が増大した場合、図8の右図に示すように、例えば、CPUコアを増加し、1つの仮想CPUに1つの物理リソース(CPUコア)を割り当てる制御を行っていた。
これに対し、VM性能保証システム100aでは、図9に示すように、2つの物理リソース(CPUコア)を2つのVM1が共有する状況において、VM1の負荷が増大した場合に、物理リソースに割り当てるVMの数を変更することにより、VM1の性能低下を防ぐようにする。図9では、物理リソースに共有するVM1の数を「2」から「1」に変更する制御を行う(図9の右図参照)。
つまり、VM1のリソース割当量を変更するのではなく、有限な物理リソース(CPUコア)に対して、割り当てるVM数を制御する。
また、VM性能保証システム100aの物理サーバ10aでは、有限の物理リソース(CPUコア)を優先度の異なるグループに分割しておく(図10参照)。そして、各VM1のリソース利用量から計算されるVM1の性能推定値(性能値)に基づき、性能不足のVM1は、高優先のグループに所属させるように所属先を変更する。また、性能過多のVM1は、低優先のグループに所属させるように所属先を変更する。このように、VM性能保証システム100aでは、各VM1について計算される性能推定値に基づき、どの優先度のグループに所属させるかを判断して所属先の優先度グループを変更する。
この優先度グループは、物理リソースに対するVM1の共有数(VM数)が異なるグループとして定義される。具体的には、オーバーコミット率の異なるCPUピニングパターンのグループに、物理リソースを分割しておく。そして、VM1の負荷に応じて、オーバーコミット率の異なる優先度グループ(CPUピニングパターン)を動的に変更する。高負荷時はオーバーコミット率の小さい(高優先)パターンでCPUを占有(固定化)し、低負荷時はオーバーコミット率の大きい(低優先)パターンでCPUを占有する。これにより、所定値以上の性能を保証しながら、物理リソースの利用効率を高めることができる。
例えば、図11に示すように、優先度の最も高いグループとして「優先度[1]のグループ」を設定する。この「優先度[1]のグループ」は、分割した有限の物理リソース(ここでは、2つのCPUコア)に、VM数が「2」、つまり2つのVM1まで共有できる設定のオーバーコミット率の小さい(高優先)のパターンである。次の「優先度[2]のグループ」は、分割した有限の物理リソース(2つのCPUコア)に、VM数が「4」まで共有できるグループである。次の「優先度[3]のグループ」は、分割した有限の物理リソース(2つのCPUコア)に、VM数が「8」まで共有できるグループである。そして、「優先度[4]のグループ」は、分割した有限の物理リソース(2つのCPUコア)に、VM数が「16」まで共有できる設定のオーバーコミット率の大きい(低優先)のパターンである。
VM性能保証システム100aでは、例えば、図12に示すように、最初は、VM数「16」の「優先度[4]のグループ」に所属していたVM1が、その性能が低下し、予めユーザとの間で取り決めがなされたSLA(Service Level Agreement:サービス品質保証)で示される性能値に所定値以上近づいた場合(性能不足に至る状況の場合)に、所属グループをより高優先でオーバーコミット率の小さい「優先度[3]のグループ」(共有できるVM数「8」)に変更する。そのVM1について、その後さらに性能が低下し、SLAで示される性能値に所定値以上近づいた場合には、同様に、所属グループを「優先度[2]のグループ」(共有できるVM数「4」)、「優先度[1]のグループ」(共有できるVM数「2」)のように、より高優先でオーバーコミット率の小さいグループに変更する。このようにすることにより、VM1の性能保証を実現することができる。
また、VM性能保証システム100aでは、性能に余裕がある場合には(性能過多の場合)には、そのVM1の所属グループをより低優先でオーバーコミット率の大きいグループに変更する。このようにすることで、物理リソース(CPUコア)の利用効率を高めることができる。
<比較例であるVM性能保証システムの構成>
次に、本発明の比較例であるVM性能保証システム100aの構成について説明する。
図13は、VM性能保証システム100aを構成する物理サーバ10aおよびコントローラ20aの機能ブロック図である。物理サーバ10aとコントローラ20aは、通信ネットワークを介して接続される。ここでは、1台の物理サーバ10a上に、仮想ルータとして機能するVM1が複数配置されるものとして説明する。
≪物理サーバ10a≫
物理サーバ10aは、自身の物理サーバ上に複数のVM1(仮想マシン)を設定する機能(コンピュートとしての機能)を有する。各VM1は、SLA等で規定される性能(例えば、パケット転送の遅延(レイテンシ)やスループット等)を満たすことが求められる。
この物理サーバ10aは、自身が備える物理リソース(例えば、CPUコア)を優先度の異なる複数のグループに分割しておき、その分割された物理リソース毎に、VM1の共有数(VM数)が異なるグループを定義しておく。そして、物理サーバ10aは、VM1の負荷に応じて、そのVM1の優先度グループをオーバーコミット率の異なる他の優先度グループに変更する。
この物理サーバ10aは、VM1を生成する機能(図示省略)を備えるとともに、リソース利用量収集部11、優先度グループ定義部12、優先度グループ変更部13、優先度グループ設定情報14を備える。
リソース利用量収集部11は、各VM1のリソース利用量(CPU使用量、メモリ使用量、パケット送受信数等)を収集する。そして、リソース利用量収集部11は、収集した各VM1のリソース利用量の情報を、コントローラ20aに送信する。
なお、リソース利用量収集部11は、コントローラ20aの指示により、後記するテストツールが実行された場合には、そのテストツールのテスト結果である各VM1のリソース利用量をコントローラ20aに送信する。
優先度グループ定義部12は、物理サーバ10aの物理リソースであるCPUコアを、複数のグループに分割する。そして、各グループを、オーバーコミット率の異なるCPUピニングパターンに分けて設定する。
具体的には、優先度グループ定義部12は、例えば図11で示したように、優先度が最も高いグループとして、共有できるVM数を「2」とする「優先度[1]のグループ」を設定する。次に優先度が高いグループとして、共有できるVM数を「4」とする「優先度[2]のグループ」を設定する。さらにその次に優先度が高いグループとして、共有できるVM数を「8」とする「優先度[3]のグループ」を設定する。さらにその次に優先度が高いグループ(優先度が最も低いグループ)として、共有できるVM数を「16」とする「優先度[4]のグループ」を設定する。
なお、VM1を専用のCPUコアに固定化(ピニング)する技術は、例えば非特許文献1の技術により実現する。
優先度グループ定義部12は、各優先度グループに対応する物理リソース(CPUコア)の情報と、その優先度グループの物理リソース(CPUコア)において共有するVM数(オーバーコミット率)と、VM1それぞれがどの優先度グループ(優先度[1]〜[4]のグループ)に所属するかを示す情報とを、優先度グループ設定情報14として記憶する。
優先度グループ変更部13は、コントローラ20aから、VM1についての優先度グループの変更指示を示す優先度グループ変更情報を受信し、そのVM1の所属する優先度グループを、優先度グループ設定情報14を参照して確認し、よりオーバーコミット率の小さい(または大きい)CPUピニングパターンの優先度グループに変更する。
≪コントローラ20a≫
コントローラ20aは、物理サーバ10aから各VM1のリソース利用量の情報を取得し、VM1(仮想ルータ)の性能推定値(性能値)を計算する。そして、コントローラ20aは、計算したVM1の性能推定値が、性能不足領域、変更不要領域、性能過多領域のうちのどの領域に属するのかを判定する。コントローラ20aは、VM1の性能推定値が、性能不足領域に属すると判定した場合には、よりオーバーコミット率の小さいCPUピニングパターンの優先度グループに変更する指示(優先度グループ変更情報)を物理サーバ10aに送信する。また、コントローラ20aは、VM1の性能推定値が、性能過多領域に属すると判定した場合には、よりオーバーコミット率の大きいCPUピニングパターンの優先度グループに変更する指示(優先度グループ変更情報)を物理サーバ10aに送信する。
このコントローラ20aは、データ取得部21と、テストツール機能部22と、学習機能部23と、性能値推定部24と、優先度変更判定部25と、データ保存DB26とを備える。
データ取得部21は、物理サーバ10aが収集した各VM1についてのリソース利用量を取得し、データ保存DB26に記憶する。また、データ取得部21は、物理サーバ10aが実行したテストツールの結果として収集した、リソース利用量等のテスト結果情報を取得し、データ保存DB26に記憶する。
テストツール機能部22は、テストツールを起動し、物理サーバ10aにデータ取得開始指示を送信することにより、各VM1のリソース利用量のデータとそれに対応する性能値(例えば、遅延)のデータを物理サーバ10aから取得する。
テストツール機能部22は、例えば、異なるオーバーコミット率で設定された優先度グループに属するVM1それぞれについて、負荷を所定パターンで変動させ、それにより得られるリソース利用量と、そのときの性能値とをテスト結果情報として取得する。
学習機能部23は、テストツール機能部22が取得したテストツールの結果データ(テスト結果情報)を用いて、機械学習による分析(例えば、回帰分析学習)を行い、学習結果データを生成する。この学習結果データは、各オーバーコミット率(優先度グループ)に所属するVM1毎に、リソース利用量から性能値を推定するための情報である。
性能値推定部24は、物理サーバ10aから取得した(現時点での)各VM1のリソース利用量に基づき、学習機能部23が保持する学習結果データを用いて、VM1それぞれの性能推定値(性能値)を計算する。
優先度変更判定部25は、性能値推定部24が計算したVM1それぞれの性能推定値を用いて、計算したVM1の性能推定値が、性能不足領域、変更不要領域、性能過多領域のうちのどの領域に属するのかを判定する。
例えば、優先度変更判定部25は、VM1の性能推定値が、性能不足領域に属すると判定した場合には、よりオーバーコミット率の小さいCPUピニングパターンの優先度グループに変更する指示(優先度グループ変更情報)を物理サーバ10aに送信する。また、優先度変更判定部25は、VM1の性能推定値が、性能過多領域に属すると判定した場合には、よりオーバーコミット率の大きいCPUピニングパターンの優先度グループに変更する指示(優先度グループ変更情報)を物理サーバ10aに送信する。なお、優先度変更判定部25は、VM1の性能推定値が、変更不要領域に属すると判定した場合には、優先度グループを変更する指示を物理サーバ10aに送信しない。これにより、そのVM1のその時点での優先度グループへの所属を維持させるようにする。
このように、比較例のVM性能保証システム100aによれば、VM1が性能不足または性能過多の場合に優先度グループを変更することで、物理リソースを効率的に活用した上で、VM1の性能保証を実現することができる。
<本実施形態>
次に、本実施形態に係るVMマイグレーションシステム100について説明する。
上記した比較例のVM性能保証システム100a(図13参照)においては、VM1が性能不足の場合、コントローラ20aから優先度グループ変更情報を物理サーバ10aが受け取ったときに、物理サーバ10aの優先度グループ変更部13は、変更先となる優先度グループに空きがなければ、優先度グループの変更ができない。この場合、物理サーバ10aは、コントローラ20aやVM性能保証システム100aの管理装置(図示省略)等に対し、警報情報を送信していた。
これに対し、本実施形態に係るVMマイグレーションシステム100は、物理サーバ10から取得した各VM1のリソース利用量に基づき、コントローラ20が、VM1毎の性能値を計算し、性能不足となったVM1について、性能保証を実現できるような所属希望先(所属候補)となる優先度グループを決定する。そして、VMマイグレーションシステム100は、所属希望の優先度グループに空きがなく、そのVM1の優先度グループの変更ができない場合に、その物理サーバ10の中から他のVM1を選択し、他の物理サーバ10にマイグレーションさせる。これにより、性能不足となったVM1の所属希望となる優先度グループへの変更を可能にし、各VM1の性能保証を継続して実現することができる。
図1は、本実施形態に係るVMマイグレーションシステム100を構成する複数の物理サーバ10およびコントローラ20の機能ブロック図である。
各物理サーバ10とコントローラ20とは、通信ネットワークを介して接続される。また、各物理サーバ10同士も通信ネットワークを介して接続される。本実施形態では、各物理サーバ10上に、例えば仮想ルータとして機能するVM1が複数配置されるものとして説明する。なお、各物理サーバ10は、同一の構成を備えるため、1台の物理サーバ10を代表して説明する。
≪物理サーバ10≫
物理サーバ10は、自身の物理サーバ上に複数のVM1(仮想マシン)を設定する機能(コンピュートとしての機能)を有する。なお、各VM1に対してSLA等で規定される性能は、例えば、VM1(仮想ルータ)のパケット転送の遅延(レイテンシ)やスループット等である。また、VM1(仮想ルータ)のCPU使用量、メモリ使用量、パケット送受信数等をリソース利用量とする。
この物理サーバ10は、自身が備える物理リソース(例えば、CPUコア)を優先度の異なる複数のグループに分割しておき、その分割された物理リソース毎に、VM1の共有数(VM1の所属可能数)が異なるグループを定義しておく。そして、物理サーバ10は、所定の時間間隔毎に、各VMのリソース利用量と、現時点の各VM1の所属を含む優先度グループ設定情報14とを、コントローラ20に送信する。また、物理サーバ10は、コントローラ20が決定したVM1の新たな所属先となる優先度グループを示す優先度グループ設定変更情報を受信し、VM1の優先度グループを変更する。
また、物理サーバ10は、優先度グループ設定変更情報で示されるVM1の新たな所属先の優先度グループにそのVM1を変更しようとした場合、変更先の優先度グループに空きがなく変更不可であった場合に、警報情報(性能保証不可警報情報)をコントローラ20へ送信する。そして、物理サーバ10は、コントローラ20が選択したVM1を、性能保証に関して余裕度が最大である物理サーバ10にマイグレーションする。これにより、性能不足となったVM1について、性能保証が実現可能な優先度グループ(新たな所属先の優先度グループ)に確実に変更させ、各VM1の性能保証を実現する。
この物理サーバ10は、VM1を生成する機能(図示省略)を備えるとともに、リソース利用量収集部11、優先度グループ定義部12、優先度グループ変更部13、優先度グループ設定情報14、優先度グループ設定情報送信部15、性能保証判定部16、VMマイグレーション実行部17を備える。また、物理サーバ10は、入出力部および記憶部(いずれも図示省略)を備える。
入出力部は、情報の送受信を行うための通信インタフェース、および、タッチパネルやキーボード等の入力装置や、モニタ等の出力装置との間で情報の送受信を行うための入出力インタフェースからなる。
また、記憶部は、フラッシュメモリやハードディスク、RAM(Random Access Memory)等により構成される。この物理サーバ10の記憶部には、図1に示す優先度グループ設定情報14が記憶される。
なお、図13で示した比較例のVM性能保証システム100aの物理サーバ10aが備える構成に比べ、本実施形態に係る物理サーバ10は、優先度グループ設定情報送信部15、性能保証判定部16、VMマイグレーション実行部17を備える点が異なる。比較例の物理サーバ10aと同一の機能を備える構成には、同一の名称と符号を付し、詳細な説明を省略する。
優先度グループ設定情報送信部15は、例えば、所定の時間間隔毎や、リソース利用量収集部11が各VM1のリソース利用量を収集したことを契機としたり、コントローラ20からの取得要求を受け付けたりすることにより、記憶部内の優先度グループ設定情報14をコントローラ20に送信する。
具体的には、優先度グループ設定情報送信部15は、優先度グループ設定情報14で示される、各優先度グループの物理リソース(CPUコア)において共有するVM数(所属可能数:オーバーコミット率)と、VM1それぞれがどの優先度グループ(例えば、優先度[1]〜[3]のグループ)に所属するかを示す情報とを、コントローラ20に送信する。
なお、本実施形態に係る物理サーバ10の優先度グループ定義部12は、VM1を収容する優先度グループとして(優先度(優先順位)[1]〜[3])の3つのグループを設定するものとして説明する。なお、優先順位は、優先度の高いグループから昇順に付される。このうち、優先度(優先順位)が最も高いグループは、優先度グループ[1]であり、共有できるVM数(所属可能数)を「2」とする。次に優先度(優先順位)が高いグループは、優先度グループ「2」であり、共有できるVM数(所属可能数)を「4」とする。その次に優先度(優先順位)が高い(最も優先度の低い)グループは、優先度グループ「3」であり、共有できるVM数(所属可能数)を「8」とする。
性能保証判定部16は、コントローラ20から優先度グループ設定変更情報を受信すると、その優先度グループ設定変更情報に含まれるVM1の現所属の優先度グループを、新たな所属先となる優先度グループに変更可能か否かについて、優先度グループ設定情報14を参照して判定する。
そして、性能保証判定部16は、変更先の優先度グループに空きがなく変更不可であった場合に、性能保証不可警報情報をコントローラ20へ送信する。また、性能保証判定部16は、変更先の優先度グループに空きがあり、変更可であった場合には、その旨の情報を、優先度グループ変更部13に出力し、変更を実行させる。
VMマイグレーション実行部17は、コントローラ20から、マイグレーションの対象となるVMとして選択されたVM1の情報と、マイグレーションによる移行先として選択された物理サーバ10の情報とを含むマイグレーション指示情報を受信する。そして、VMマイグレーション実行部17は、その選択されたVM1について、選択された物理サーバ10のVMマイグレーション実行部17と連携してマイグレーションを実行する。VMマイグレーション実行部17は、移行されたVM1の情報に基づき、優先度グループ設定情報14を更新する。
≪コントローラ20≫
コントローラ20は、物理サーバ10から、リソース利用量と優先度グループ設定情報14とを取得する。そして、コントローラ20は、各VM1の所属希望(所属候補)の優先度グループを決定する。コントローラ20は、決定した各VM1の所属希望の優先度グループを物理サーバ10に送信する。コントローラ20は、物理サーバ10から性能保証不可警報情報を受信した場合、または、決定した所属希望の優先度グループに基づき、性能保証不可とコントローラ20自身で判定することにより性能保証不可警報情報を生成した場合に、その性能保証不可と判定されたVM1を備える物理サーバ10に配置されたVMの中からマイグレーションの対象となるVM1を選択する。また、コントローラ20は、所定の時間間隔で、各物理サーバ10の性能に関する稼働状態の余裕度を計算しておく。そして、コントローラ20は、最も余裕度の大きい物理サーバ10を、マイグレーションの移行先の物理サーバ10として選択する。コントローラ20は、マイグレーションの対象として選択したVM1の情報と移行先として選択した物理サーバ10の情報を含むマイグレーション指示情報を、性能保証不可警報情報で示されるVM1を備える物理サーバ10に送信する。
このコントローラ20は、データ取得部21と、テストツール機能部22と、学習機能部23と、性能値推定部24と、データ保存DB26と、所属希望グループ決定部27と、性能保証可否判定部28と、VM選択部29と、物理サーバ選択部30と、優先度グループ状態情報210と、VM状態情報220と、物理サーバ状態情報230とを備える。また、コントローラ20は、入出力部および記憶部(いずれも図示省略)を備える。
入出力部は、情報の送受信を行うための通信インタフェース、および、タッチパネルやキーボード等の入力装置や、モニタ等の出力装置との間で情報の送受信を行うための入出力インタフェースからなる。
また、記憶部は、フラッシュメモリやハードディスク、RAM等により構成される。このコントローラ20の記憶部は、図1に示すように、データ保存DB26、優先度グループ状態情報210、VM状態情報220、物理サーバ状態情報230を備える。このデータ保存DB26は、物理サーバ10から取得した各VM1のリソース利用量(CPU使用量、メモリ使用量、パケット送受信数等)の情報や優先度グループ設定情報14等が記憶される。また、このデータ保存DB26には、テストツール機能部22の指示により、物理サーバ10から取得したVM1ごとのテスト結果の情報が記憶される。優先度グループ状態情報210、VM状態情報220および物理サーバ状態情報230は、コントローラ20が各VM1の優先度グループの変更に関する処理を行う毎に設けられる情報である(詳細は後記)。
なお、図13で示した比較例のVM性能保証システム100aのコントローラ20aが備える構成に比べ、本実施形態に係るコントローラ20は、コントローラ20aの優先度変更判定部25(図13)を備えていない。その代わりに、コントローラ20は、所属希望グループ決定部27、性能保証可否判定部28、VM選択部29、物理サーバ選択部30、優先度グループ状態情報210、VM状態情報220、物理サーバ状態情報230を備える点が異なる。比較例のコントローラ20aと同一の機能を備える構成には、同一の名称と符号を付し、詳細な説明を省略する。
所属希望グループ決定部27は、データ取得部21が物理サーバ10から取得した、リソース利用量と優先度グループ設定情報14とに基づき、各VM1について、性能不足および性能過多とならないような新たな所属先となる優先度グループ(所属希望優先度グループ)を決定する。なお、この所属希望優先度グループには、現所属の優先度グループを所属希望先とする場合も含まれる。
具体的には、所属希望グループ決定部27は、以下に示すように、物理サーバ10毎に、優先度グループ状態情報210(図2参照)およびVM状態情報220(図3参照)を生成することにより、新たな所属先となる優先度グループを決定する。
以下、所属希望グループ決定部27が実行する所属希望グループ決定処理を詳細に説明する。
まず、所属希望グループ決定部27は、データ取得部21が取得した優先度グループ設定情報14を用いて、各優先度グループの空き所属数を計算し、優先度グループ状態情報210を生成する。
図2は、本実施形態に係る優先度グループ状態情報210のデータ構成例を示す図である。
所属希望グループ決定部27は、優先度グループ設定情報14に含まれる、各優先度グループの物理リソース(CPUコア)において共有するVM数(所属可能数)と、VM1それぞれがどの優先度グループ(優先度[1]〜[3]のグループ)に所属するかを示す情報とを用いて、この優先度グループ状態情報210を生成する。
図2に示すように、優先度グループ状態情報210は、グループID211、優先順位212、所属可能数213、空き所属数214の項目により構成される。
グループID211は、各優先度グループを識別するための情報である。優先順位212は、各優先度グループの優先度([1]〜[3])を高い順に並べて順位をつけた値である。所属可能数213は、各優先度グループの物理リソース(CPUコア)において共有可能として設定されたVM数を示す。空き所属数214は、所属可能数213からその優先度グループに現時点で所属しているVM1の数を減じた空きとなる所属数である。所属希望グループ決定部27は、現時点のVM1における所属先の優先度グループの情報を優先度グループ設定情報14により把握することができる。
図2において、グループID211が「g0001」の優先度グループの空き所属数214は「1」である。グループID211が「g0002」の優先度グループの空き所属数214は「0」である。また、グループID211が「g0003」の優先度グループの空き所属数214は「2」である。
次に、所属希望グループ決定部27は、優先度グループ設定情報14に含まれる、各VM1がどの優先度グループ(優先度[1]〜[3]のグループ)に所属するかを示す情報を用いて、初期設定のVM状態情報220を生成する。
図3は、本実施形態に係るVM状態情報220のデータ構成例(初期設定)を示す図である。
図3に示すように、VM状態情報220は、VMID221、リソース利用量222、性能値223、現所属224、所属希望225の項目により構成される。
VMID221は、各VM1を識別するための情報である。
リソース利用量222には、物理サーバ10から取得した各VM1のリソース利用量(例えば、CPU使用量、メモリ使用量等)が格納される。
性能値223には、各VM1のリソース利用量に基づき、性能値推定部24が算出した性能値が格納される。
現所属224には、そのVM1が現在所属する優先度グループが格納される。
所属希望225には、所属希望グループ決定部27が後記する処理により決定する所属希望先となる優先度グループが格納される。
次に、所属希望グループ決定部27は、データ取得部21が物理サーバ10からリソース利用量の情報を取得する毎のタイミングで次の処理を実行する(適宜図5参照)。
まず、所属希望グループ決定部27は、データ取得部21が取得したリソース利用量の情報をVM状態情報220に取り込む。また、所属希望グループ決定部27は、そのリソース利用量に基づき、性能値推定部24が計算した性能値の情報を取り込み、VM状態情報220に格納する。
図5に示すVM状態情報220では、リソース利用量として、CPU使用量(図では「C」と表記)やメモリ使用量(図では「M」と表記)が格納され、そのリソース利用量の値から求められた性能値223が格納されていることを示している。なお、リソース利用量および性能値は、説明を簡単にするため、最大値を100として正規化した値で例示している。
ここで、所属希望グループ決定部27は、所定の性能値判定基準により、リソース利用量に基づき計算した性能値が、「性能不足領域」「変更不要領域」「性能過多領域」のいずれに属するかを判定する。この「性能不足領域」「変更不要領域」「性能過多領域」それぞれに属するか否かを判定する条件(基準)は、予め設定しておく。
例えば、性能不足を所定の第1の閾値未満の性能であるとし、性能過多を所定の第2の閾値以上の性能であると設定しておく。ここでは、性能不足領域を、性能値が「0以上60未満」とする。「変更不要領域」を、性能値が「60以上90未満」とする。性能過多領域を、性能値が「90以上100以下」として説明する。
図5に示す例では、VMID221が「v0001」のVM1は、性能値223が「100」であるので、性能過多領域に属すると判定される。VMID221が「v0002」のVM1は、性能値223が「50」であるので、性能不足領域に属すると判定される。VMID221が「v0003」のVM1は、性能値223が「80」であるので、変更不要領域に属すると判定される。VMID221が「v0004」のVM1は、性能値223が「20」であるので、性能不足領域に属すると判定される。VMID221が「v0005」のVM1は、性能値223が「30」であるので、性能不足領域に属すると判定される。
ここで、所属希望グループ決定部27は、変更不要領域に属すると判定したVMID221が「v0003」のVM1については、所属希望225を現在の優先度グループと同じ「g0002」とする。
続いて、所属希望グループ決定部27は、性能不足領域および性能過多領域に属するVM1について、所属希望となる新たな優先度グループを決定する。具体的には、所属希望グループ決定部27は、性能過多領域に属すると判定されたVM1について「降格グループ探索」を行い、計算した性能値が「変更不要領域」となった優先度グループをそのVM1の所属希望先に決定する。また、所属希望グループ決定部27は、性能不足領域に属すると判定されたVM1について「昇格グループ探索」を行い、計算した性能値が「変更不要領域」となった優先度グループをそのVM1の所属希望先に決定する。
降格グループ探索は、性能値推定部24が計算する性能値が「変更不要領域」になるまで以下の処理を実行することにより行う。
所属希望グループ決定部27は、現在所属するグループより1低い優先度グループでの性能値を性能値推定部24に計算させる。そして、所属希望グループ決定部27は、計算した性能値の領域を判定し、「変更不要領域」になるまで、さらに1低い優先度グループでの性能値の計算を繰り返す。そして、所属希望グループ決定部27は、「変更不要領域」となった優先度グループをそのVM1の所属希望に決定する。
昇格グループ探索は、性能値推定部24が計算する性能値が「変更不要領域」になるまで以下の処理を実行することにより行う。
所属希望グループ決定部27は、現在所属するグループより1高い優先度グループでの性能値を性能値推定部24に計算させる。そして、所属希望グループ決定部27は、計算した性能値の領域を判定し、「変更不要領域」になるまで、さらに1高い優先度グループでの性能値の計算を繰り返す。そして、所属希望グループ決定部27は、「変更不要領域」となった優先度グループをそのVM1の所属希望に決定する。
図4は、所属希望グループ決定部27による、降格グループ探索と、昇格グループ探索の結果を示す図である。
VMID221が「v0001」のVM1については、降格グループ探索を行い、「g0002」の優先度グループで「変更不要領域」になると計算される。VMID221が「v0002」のVM1については、昇格グループ探索を行い、「g0001」の優先度グループで「変更不要領域」になると計算される。VMID221が「v0004」のVM1については、昇格グループ探索を行い、「g0001」の優先度グループで「変更不要領域」になると計算される。VMID221が「v0005」のVM1については、昇格グループ探索を行い、「g0002」の優先度グループで「変更不要領域」になると計算される。
なお、所属希望グループ決定部27は、図4の一点鎖線で示される状態を含む、各VM1が全ての優先度グループに存在する場合を想定した計算を行うことにより、変更不要領域となる優先度グループを決定してもよい。
図5に示すように、所属希望グループ決定部27は、上記の降格グループ探索や昇格グループ探索を行うことにより決定した所属希望の優先度グループをVM状態情報220の所属希望225に格納する。
このようにして、所属希望グループ決定部27は、優先度グループ状態情報210(図2)およびVM状態情報220(図5)を生成して、各VM1の所属希望の優先度グループを決定し、所属希望グループ決定処理を終える。
そして、所属希望グループ決定部27は、VM状態情報220に格納した、各VM1についての新たな所属希望の優先度グループを、優先度グループ設定変更情報として、物理サーバ10に送信する。
図1に戻り、性能保証可否判定部28は、VM1の現時点(現所属)の優先度グループと、所属希望グループ決定部27が決定した所属希望の優先度グループとの情報を用いて、SLA等で規定される性能保証を実現できるか否かを所定のロジック(性能保証可否判定ロジック)に基づき判定する。
性能保証可否判定部28は、性能保証を実現できるか否かを判定するロジックとして、例えば、以下のロジックを採用する。
「Σ(所属希望の優先度グループの優先順位 − 現所属の優先度グループの優先順位) ≦ 0」(条件1)、かつ、
「優先順位aの優先度グループを希望するVM数 ≦ 優先順位a以上の優先度グループでのVMの所属可能総数」(条件2)
ここで、「a」は、優先順位「a」(ここでは、「1」〜「3」)の各優先度グループを示す。
図5で示す例においては、以下のように(条件1)(条件2)が判定される。なお、図5において、省略し記載していないVMID221「v0006」〜「v0011」の6つのVM1については、現所属224と所属希望225とが同じ優先度グループであるもものとして計算を行う。具体的には、現所属のグループIDが「g0002」のVM1が2つ、「g0003」のVM1が4つあるものとして説明する。
(条件1)は、VMID221が「v0001」「v0002」「v0004」「v0005」のVM1について、次のように計算させる。なお、所属希望と現所属が同じ優先順位の場合は、差が「0」であるので計算せず、記載を省略する。
Σ(所属希望の優先度グループの優先順位 − 現所属の優先度グループの優先順位)
=(2−1)+(1−2)+(1−3)+(2−3)= −3 ≦0
以上より、(条件1)を満たす。
(条件2)において、優先順位「1」(優先度グループ[1])を希望するVM数は、「2」であり、優先順位「1」以上の所属可能総数は「2」であるから、2 ≦ 2であり、優先順位「1」について、(条件2)を満たす。
優先順位「2」(優先度グループ[2])を希望するVM数は、「5」であり、優先順位「2」以上の所属可能総数は「4」(4+0)であるから、5 ≦ 4であり、優先順位「2」について、(条件2)を満たさない。なお、ここでは、優先順位「1」の優先度グループには空き所属がないため、「+0」としている。
優先順位「3」(優先度グループ[3])を希望するVM数は、「4」であり、優先順位「3」以上の所属可能総数は「8」(8+0+0)であるから、4 ≦ 8であり、優先順位「3」について、(条件2)を満たす。なお、ここでは、優先順位「1」「2」の優先度グループには空き所属がないため「+0+0」としている。
よって、優先順位「2」の優先度グループについて、(条件2)を満たさないため、性能保証可否判定部28は、性能保証不可であると判定する。そして、性能保証可否判定部28は、性能保証不可であると判定した場合、VM選択部29に性能保証不可警報情報を出力する。この性能保証不可警報情報には、性能保証不可とされたVM1の属する優先度グループとその物理サーバ10の識別情報が含まれる。ここでは、物理サーバ10の識別情報と空き所属のない優先度グループ[2]の情報を含む性能保証不可警報情報が出力される。
図1に戻り、VM選択部29は、物理サーバ10の性能保証判定部16、コントローラ20の性能保証可否判定部28のいずれかまたは両方から性能保証不可警報情報を取得した場合、その性能保証不可警報情報に含まれる、物理サーバ10の識別子を用いて、その物理サーバ10を特定する。VM選択部29は、データ保存DB26に記憶された、特定した物理サーバ10に関する優先度グループ設定情報14を参照して、性能保証不可とされたVM1の所属希望の優先度グループであって、空き所属がない優先度グループ(ここでは、優先度グループ[2])に現時点で所属するVM1を抽出する。そして、VM選択部29は、抽出したVM1の中から、所定にルールに従って、マイグレーションの対象とするVM1を選択する。この所定のルールは、リソース利用量(例えば、メモリ使用量)の最も小さいVM1を選択する等であり、予め設定される。
物理サーバ選択部30は、所定の時間間隔や、例えば、コントローラ20が物理サーバ10からリソース利用量および優先度グループ設定情報14の情報を取得したタイミング毎に、物理サーバ10の処理能力についての余裕の度合を示す余裕度を、所定のロジック(余裕度計算ロジック)に基づき計算する。そして、物理サーバ選択部30は、各物理サーバ10の余裕度のうち、最も余裕度が大きい物理サーバ10を、マイグレーション先の物理サーバ10として選択する。
なお、物理サーバ選択部30は、余裕度の計算に際し、図6に示す物理サーバ状態情報230を生成する。
図6に示すように、物理サーバ状態情報230は、物理サーバID231、空きVM数232、余裕度233の項目により構成される。
物理サーバID231は、各物理サーバ10を識別するための情報である。
空きVM数232は、各物理サーバ10のVM1の空き所属の合計である。この空きVM数232は、図2で示す優先度グループ状態情報210の空き所属数214を全ての優先度グループにおいて合計した値が格納される。
余裕度233は、例えば、以下の3つの余裕度計算ロジックのうちのいずれかを用いて計算される。
(余裕度計算ロジック「1」)
各物理サーバ10の空きVM数を余裕度として利用する。
余裕度 M = S- ・・・(式1)
ここで、Sは、物理サーバ10の空きVM数を示す。
なお、この余裕度計算ロジック「1」を採用した場合、図6に示す物理サーバ状態情報230の空きVM数232の値と、余裕度233の値とは、同一となる。
余裕度計算ロジック「1」を用いることで、コントローラ20は、各物理サーバ10について空きVM数が多いほど余裕度が大きいものとして、マイグレーションの移行先となる物理サーバ10を簡易に決定することが可能となる。
(余裕度計算ロジック「2」)
各物理サーバ10に属する優先度グループiに対し、(式2)を用いて余裕度を計算する。
余裕度 M = Σ/P ・・・(式2)
ここで、Eは、その優先度グループにおける空き所属数を示す。Pは、優先度グループの優先順位を示す。aは、定数(優先度グループ毎の重み)を示す。
なお、物理サーバ選択部30は、この空き所属数Eの情報と、優先度グループの優先順位Pの情報とを、各物理サーバ10に対応付けて記憶された、優先度グループ状態情報210(図2)を参照することにより取得することができる。
余裕度計算ロジック「2」を用いることで、コントローラ20は、優先度グループの空き所属数と、優先度グループの優先順位とを用いて、優先順位が高い優先度グループに空き所属が多いほど、その物理サーバ10の余裕度が大きいものとして、マイグレーションの移行先となる物理サーバ10を簡易に決定することが可能となる。
(余裕度計算ロジック「3」)
各物理サーバ10に配置されるVMに対し、(式3)を用いて余裕度を計算する。
余裕度 M = Σ(N−C) ・・・(式3)
ここで、Nは、所属希望の優先度グループの優先順位を示す。Cは、現所属の優先度グループの優先順位を示す。aは、定数(VM1毎の重み)を示す。
なお、物理サーバ選択部30は、この所属希望の優先度グループの優先順位Nの情報と、現所属の優先度グループの優先順位Cの情報とを、各物理サーバ10に対応付けて記憶された、VM状態情報(図5)を参照することにより取得することができる。
余裕度計算ロジック「3」を用いることで、コントローラ20は、所属希望の優先度グループの優先順位と、現所属の優先度グループの優先順位とを用いて、優先度の低い優先度グループに移行するVM1が多いほど、その物理サーバ10の余裕度が大きいものとして、マイグレーションの移行先となる物理サーバ10を簡易に決定することが可能となる。
物理サーバ選択部30は、3つの余裕度計算ロジックのうちのいずれかを用いて余裕度を計算する。そして、物理サーバ選択部30は、最も余裕度の大きい物理サーバ10をマイグレーション先の物理サーバ10として選択する。
物理サーバ選択部30は、VM選択部29がマイグレーションの対象として選択したVM1の情報と、マイグレーション先として選択した物理サーバ10との情報を含むマイグレーション指示情報を生成し、性能保証不可警報情報で示されるVM1を備える物理サーバ10に送信する。
<処理の流れ>
次に、VMマイグレーションシステム100が実行する処理の流れについて説明する。
図7は、本実施形態に係るVMマイグレーションシステム100が実行する処理の流れを示すフローチャートである。なお、図7は、VMマイグレーションシステム100を構成する複数の物理サーバ10のうち、1台を代表して記載している。他の物理サーバ10も同様の処理を実行する。
まず、物理サーバ10の優先度グループ定義部12は、各優先度グループに対応する物理リソース(CPUコア)において共有するVM数(所属可能数:オーバーコミット率)の情報と、VM1それぞれがどの優先度グループ(優先度(優先順位)[1]〜[3]のグループ)に所属するかを示す情報とを、優先度グループ設定情報14として記憶部に記憶する(ステップS10)。
続いて、コントローラ20のテストツール機能部22および学習機能部23により、テストツールを起動させて物理サーバ10からテストツールの実行結果を取得し、VM1の性能値を算出するために必要となる学習結果データを生成する(ステップS11)。この学習結果データを用いて、コントローラ20の性能値推定部24は、リアルタイムに更新される各VM1のリソース利用量のデータに基づき、性能値を計算することができる。
次に、物理サーバ10のリソース利用量収集部11は、所定時間が経過したか否かを判定する(ステップS12)。所定時間が経過していない場合には(ステップS12→No)、ステップS12に戻り、所定時間が経過するまで待機する。一方、所定時間が経過した場合には(ステップS12→Yes)、次のステップS13へ進む。つまり、以降の処理は、所定の時間間隔で繰り返し実行されるものである。
ステップS13において、物理サーバ10のリソース利用量収集部11が、各VM1についてのリソース利用量の情報を収集し、コントローラ20に送信する。
また、ステップS14において、物理サーバ10の優先度グループ設定情報送信部15は、記憶部内の優先度グループ設定情報14を所定の時間間隔毎にコントローラ20へ送信する。具体的には、優先度グループ設定情報送信部15は、優先度グループ設定情報14で示される、各優先度グループの物理リソース(CPUコア)において共有するVM数(所属可能数)と、VM1それぞれがどの優先度グループ(優先度[1]〜[3]のグループ)に所属するかを示す情報とを、コントローラ20に送信する。
なお、ステップS13とステップS14の処理の順序は問わず、どちらが先にコントローラ20へ送信されてもよいし、同時に送信されてもよい。
続いて、コントローラ20の所属希望グループ決定部27は、データ取得部21が物理サーバ10から取得した、リソース利用量と優先度グループ設定情報14とに基づき、各VM1について、性能不足および性能過多とならないような新たな所属先となる優先度グループ(所属希望優先度グループ)を決定するため、所属希望グループ決定処理を実行する(ステップS15)。
具体的には、所属希望グループ決定部27は、上記のように、優先度グループ設定情報14を用いて、各優先度グループの空き所属数を計算し、優先度グループ状態情報210(図2)を生成する。続いて、所属希望グループ決定部27は、各VM1のリソース利用量に基づき算出された性能値が、「性能不足領域」および「性能過多領域」に属するVM1について、昇格グループ探索または降格グループ探索を行うことにより、所属希望優先度グループを決定し、VM状態情報220(図5)を生成する。
そして、所属希望グループ決定部27は、VM状態情報220に格納した、各VM1についての新たな所属希望の優先度グループを、優先度グループ設定変更情報として、物理サーバ10に送信する(ステップS16)。
性能保証判定部16は、コントローラ20から優先度グループ設定変更情報を受信すると、その優先度グループ設定変更情報に含まれるVM1の現所属の優先度グループを、新たな所属先となる優先度グループに変更可能か否かを、優先度グループ設定情報14を参照して判定する(ステップS17:性能保証可否判定)。
そして、性能保証判定部16は、変更先の優先度グループに空きがあり、変更可であった場合には、その旨の情報を、優先度グループ変更部13に出力し、優先度グループの変更を実行させ、優先度グループ設定情報14を更新して処理を終える。一方、性能保証判定部16は、変更先の優先度グループに空きがなく変更不可であった場合には、性能保証不可警報情報をコントローラ20へ送信する(ステップS18)。
一方、コントローラ20の性能保証可否判定部28は、VM1の現時点(現所属)の優先度グループと、所属希望グループ決定部27が決定した所属希望の優先度グループとの情報を用いて、SLA等で規定される性能保証を実現できるか否かを所定のロジック(性能保証可否判定ロジック)に基づき判定する(ステップS19:性能保証可否判定)。
この所定のロジック(性能保証可否判定ロジック)は、上記した(条件1)かつ(条件2)を満たすか否かで判定される。性能保証可否判定部28は、(条件1)かつ(条件2)を満たさないと判定した場合に、性能保証不可とされたVM1の属する優先度グループとその物理サーバ10の識別情報とを含む性能保証不可警報情報を、VM選択部29に出力する(ステップS20)。
次に、コントローラ20のVM選択部29は、物理サーバ10の性能保証判定部16、コントローラ20の性能保証可否判定部28のいずれかまたは両方から性能保証不可警報情報を取得した場合、性能保証不可とされたVM1の所属希望の優先度グループであって、空き所属がない優先度グループの現所属のVM1の中から、所定のルールに基づき、マイグレーションの対象とするVM1を選択する(ステップS21)。例えば、VM選択部29は、空き所属がない優先度グループに属するVM1のうち、メモリ利用量が最も小さいVM1を選択する。
一方、コントローラ20の物理サーバ選択部30は、例えば、所定の時間間隔で、予め設定しておいた所定のロジック(余裕度計算ロジック「1」〜「3」のいずれか)に基づき、各物理サーバ10の余裕度を計算し(ステップS22)、物理サーバ状態情報230(図6)に格納しておく。
そして、物理サーバ選択部30は、VM選択部29がマイグレーションの対象とするVM1を選択したことを契機として、各物理サーバ10の余裕度のうち、最も余裕度が大きい物理サーバ10を、マイグレーション先の物理サーバ10として選択する(ステップS23)。
続いて、物理サーバ選択部30は、VM選択部29がマイグレーションの対象として選択したVM1の情報と、マイグレーション先として選択した物理サーバ10の情報とを含むマイグレーション指示情報を生成し、性能保証不可警報情報で示されるVM1を備える物理サーバ10に送信する(ステップS24)。
次に、物理サーバ10のVMマイグレーション実行部17は、マイグレーション指示情報を受信し、マイグレーションの対象として選択されたVM1について、選択された物理サーバ10のVMマイグレーション実行部17と連携しマイグレーションを実行する(ステップS25)。そして、VMマイグレーション実行部17は、移行されたVM1の情報に基づき、優先度グループ設定情報14を更新する。
続いて、物理サーバ10の優先度グループ変更部13が、現時点の優先度グループを、コントローラ20から取得した優先度グループ設定変更情報で示されるVM1の新たな所属先となる優先度グループに変更し(ステップS26)、優先度グループ設定情報14を更新して処理を終える。
以上説明したように、本実施形態に係るVMマイグレーションシステム100およびVMマイグレーション実行方法によれば、所属希望(所属候補)の優先度グループに空きがない場合であっても、最も余裕度の大きい物理サーバ10をマイグレーション先の物理サーバとして選択し、VM1のマイグレーションを実行することにより、所属希望の優先度グループへの変更を可能とすることができる。よって、各VM1の性能保証を継続して実現することが可能となる。
なお、本発明は、上記した本実施形態に限定されず、その趣旨を逸脱しない範囲で、変更実施が可能である。
例えば、本実施形態では、物理サーバ10に性能保証判定部16を備え、コントローラ20にも性能保証可否判定部28を備え、いずれかまたは両方から性能保証不可警報情報をコントローラ20のVM選択部29が取得した場合、マイグレーションの対象とするVM1を選択するものとした(図7のステップS21)。しかしながら、物理サーバ10側、コントローラ20側のどちらか一方に、性能保証の可否を判定する機能を備えるようにしてもよい。これによっても同等の効果を得ることができる。
1 VM(仮想ルータ)
10 物理サーバ(コンピュート)
11 リソース利用量収集部
12 優先度グループ定義部
13 優先度グループ変更部
14 優先度グループ設定情報
15 優先度グループ設定情報送信部
16 性能保証判定部
17 VMマイグレーション実行部
20 コントローラ
21 データ取得部
22 テストツール機能部
23 学習機能部
24 性能値推定部
26 データ保存DB
27 所属希望グループ決定部
28 性能保証可否判定部
29 VM選択部
30 物理サーバ選択部
100 VMマイグレーションシステム
210 優先度グループ状態情報
220 VM状態情報
230 物理サーバ状態情報

Claims (6)

  1. 複数のVM(Virtual Machine)を稼働させる複数の物理サーバと、前記物理サーバそれぞれに接続され、前記VMの稼働状態を管理するコントローラとを備えるVMマイグレーションシステムであって、
    前記物理サーバそれぞれは、
    当該物理サーバが有する物理リソースを複数のグループに分割し、当該分割したグループそれぞれに共有できるVM数である所属可能数を異なるように設定して、前記共有できるVM数が少ないほど優先度が高い優先度グループとし、前記優先度グループそれぞれとその優先度グループの物理リソース上で稼働させるVMとの対応関係を格納する優先度グループ設定情報が記憶される記憶部と、
    前記VMそれぞれが稼働する際のリソース利用量を収集し、前記コントローラに送信するリソース利用量収集部と、
    前記優先度グループ設定情報を、前記コントローラに送信する優先度グループ設定情報送信部と、
    前記コントローラから、マイグレーションの対象となるVMの情報および前記マイグレーションの移行先となる他の物理サーバの情報を含むマイグレーション指示情報を受信し、前記マイグレーションの対象となるVMの前記他の物理サーバへのマイグレーションを実行するVMマイグレーション実行部と、
    前記VMそれぞれに対する前記優先度グループの変更指示を示す優先度グループ設定変更情報を前記コントローラから受信すると、前記優先度グループ設定情報を参照し、当該VMが属する優先度グループを新たな優先度グループに変更する優先度グループ変更部と、を備え、
    前記コントローラは、
    前記物理サーバから前記VMそれぞれのリソース利用量および前記優先度グループ設定情報を取得するデータ取得部と、
    各VMが所定の第1の閾値未満の性能である性能不足および所定の第2の閾値以上の性能である性能過多とならないような所属先となる所属希望の優先度グループを、各VMの前記リソース利用量を用いて、各VMが優先度グループそれぞれに所属した場合の性能値を算出することにより決定する所属希望グループ決定部と、
    前記優先度グループ設定情報で示される現所属の優先度グループの情報、および、決定した前記所属希望の優先度グループの情報を用いて、各VMについての性能保証の可否を判定し、前記性能保証が不可の場合に性能保証不可警報情報を出力する性能保証可否判定部と、
    前記性能保証不可警報情報を取得すると、前記優先度グループ設定情報を参照し、当該性能保証不可警報情報に含まれる前記性能保証が不可とされたVMの所属希望の優先度グループであって、空き所属がない優先度グループの現所属のVMの中から、所定のルールに基づき、前記マイグレーションの対象とするVMを選択するVM選択部と、
    各物理サーバの処理能力についての余裕の度合を示す余裕度を、所定のロジックに基づき計算し、前記余裕度の最も大きい物理サーバを前記マイグレーションの移行先となる前記他の物理サーバとして選択するとともに、前記マイグレーション指示情報を生成し、前記性能保証が不可とされたVMを備える物理サーバに送信する物理サーバ選択部と、を備えること
    を特徴とするVMマイグレーションシステム。
  2. 前記余裕度を計算する前記所定のロジックは、(式1)であり、
    余裕度 M = S ・・・(式1)
    ここで、Sは、各物理サーバkの空きVM数を示し、
    前記物理サーバ選択部は、前記優先度グループ設定情報を参照し、前記空きVM数を、各優先度グループの所属可能数から現所属のVM数を減じた空き所属数について、当該物理サーバに設定された全ての優先度グループについて合計することにより得ること、
    を特徴とする請求項1に記載のVMマイグレーションシステム。
  3. 前記余裕度を計算する前記所定のロジックは、(式2)であり、
    余裕度 M = Σ/P ・・・(式2)
    ここで、Eは、優先度グループiにおける空き所属数を示し、Pは、優先度グループについて優先度の高い方から昇順に並べた場合の優先度グループiの優先順位を示し、aは、定数(優先度グループiの重み)を示し、
    前記物理サーバ選択部は、前記優先度グループ設定情報を参照し、前記空き所属数を、各優先度グループの所属可能数から現所属のVM数を減じることにより計算すること、
    を特徴とする請求項1に記載のVMマイグレーションシステム。
  4. 前記余裕度を計算する前記所定のロジックは、(式3)であり、
    余裕度 M = Σ(N−C) ・・・(式3)
    ここで、Nは、所属希望の優先度グループについて優先度の高い方から昇順に並べた場合の優先度グループの優先順位を示し、Cは、VMjの現所属の優先度グループの優先順位を示し、aは、定数(VMjの重み)を示すこと、
    を特徴とする請求項1に記載のVMマイグレーションシステム。
  5. 前記コントローラが、前記性能保証可否判定部を備えておらず、
    前記物理サーバが、替わりに、
    前記優先度グループ設定変更情報を前記コントローラから受信した場合に、変更指示された優先度グループの所属に空きがなく変更不可であるときに、前記性能保証不可警報情報を前記コントローラに送信する性能保証判定部を備えること
    を特徴とする請求項1ないし請求項4のいずれか1項に記載のVMマイグレーションシステム。
  6. 複数のVMを稼働させる複数の物理サーバと、前記物理サーバそれぞれに接続され、前記VMの稼働状態を管理するコントローラとを備えるVMマイグレーションシステムのVMマイグレーション方法であって、
    前記物理サーバは、
    当該物理サーバが有する物理リソースを複数のグループに分割し、当該分割したグループそれぞれに共有できるVM数である所属可能数を異なるように設定して、前記共有できるVM数が少ないほど優先度が高い優先度グループとし、前記優先度グループそれぞれとその優先度グループの物理リソース上で稼働させるVMとの対応関係を格納する優先度グループ設定情報が記憶される記憶部を備えており、
    前記VMそれぞれが稼働する際のリソース利用量を収集し、前記コントローラに送信するステップと、
    前記優先度グループ設定情報を、前記コントローラに送信するステップと、を実行し、
    前記コントローラは、
    前記物理サーバから前記VMそれぞれのリソース利用量および前記優先度グループ設定情報を取得するステップと、
    各VMが所定の第1の閾値未満の性能である性能不足および所定の第2の閾値以上の性能である性能過多とならないような所属先となる所属希望の優先度グループを、各VMの前記リソース利用量を用いて、各VMが優先度グループそれぞれに所属した場合の性能値を算出することにより決定するステップと、
    前記優先度グループ設定情報で示される現所属の優先度グループの情報、および、決定した前記所属希望の優先度グループの情報を用いて、各VMについての性能保証の可否を判定し、前記性能保証が不可の場合に性能保証不可警報情報を出力するステップと、
    前記性能保証不可警報情報を取得すると、前記優先度グループ設定情報を参照し、当該性能保証不可警報情報に含まれる前記性能保証が不可とされたVMの所属希望の優先度グループであって、空き所属がない優先度グループの現所属のVMの中から、所定のルールに基づき、マイグレーションの対象とするVMを選択するステップと、
    各物理サーバの処理能力についての余裕の度合を示す余裕度を、所定のロジックに基づき計算し、前記余裕度の最も大きい物理サーバを前記マイグレーションの移行先となる他の物理サーバとして選択するとともに、前記マイグレーションの対象となるVMの情報および前記マイグレーションの移行先となる他の物理サーバの情報を含むマイグレーション指示情報を生成し、前記性能保証が不可とされたVMを備える物理サーバに送信するステップと、を実行し、
    前記物理サーバは、
    前記コントローラから、前記マイグレーション指示情報を受信し、前記マイグレーションの対象となるVMの前記他の物理サーバへのマイグレーションを実行するステップと、
    前記VMそれぞれに対する前記優先度グループの変更指示を示す優先度グループ設定変更情報を前記コントローラから受信して、前記優先度グループ設定情報を参照し、当該VMが属する優先度グループを新たな優先度グループに変更するステップと、を実行する
    ことを特徴とするVMマイグレーション方法。
JP2018099347A 2018-05-24 2018-05-24 Vmマイグレーションシステムおよびvmマイグレーション方法 Active JP6969499B2 (ja)

Priority Applications (3)

Application Number Priority Date Filing Date Title
JP2018099347A JP6969499B2 (ja) 2018-05-24 2018-05-24 Vmマイグレーションシステムおよびvmマイグレーション方法
US17/057,339 US12001868B2 (en) 2018-05-24 2019-05-15 VM migration system and VM migration method
PCT/JP2019/019279 WO2019225429A1 (ja) 2018-05-24 2019-05-15 Vmマイグレーションシステムおよびvmマイグレーション方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2018099347A JP6969499B2 (ja) 2018-05-24 2018-05-24 Vmマイグレーションシステムおよびvmマイグレーション方法

Publications (2)

Publication Number Publication Date
JP2019204309A JP2019204309A (ja) 2019-11-28
JP6969499B2 true JP6969499B2 (ja) 2021-11-24

Family

ID=68616515

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2018099347A Active JP6969499B2 (ja) 2018-05-24 2018-05-24 Vmマイグレーションシステムおよびvmマイグレーション方法

Country Status (3)

Country Link
US (1) US12001868B2 (ja)
JP (1) JP6969499B2 (ja)
WO (1) WO2019225429A1 (ja)

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP6973292B2 (ja) * 2018-05-24 2021-11-24 日本電信電話株式会社 Vm優先度制御システムおよびvm優先度制御方法
US11327675B2 (en) * 2019-01-23 2022-05-10 Accenture Global Solutions Limited Data migration
CN112286622A (zh) * 2019-07-22 2021-01-29 中兴通讯股份有限公司 虚机迁移处理及策略生成方法、装置、设备及存储介质
US11593234B2 (en) 2020-01-16 2023-02-28 Vmware, Inc. Cloud restart for VM failover and capacity management
US11347521B2 (en) * 2020-01-16 2022-05-31 Vmware, Inc. Cloud restart for non-critical performance virtual machines
US20240126446A1 (en) * 2022-10-18 2024-04-18 VMware, LLC Management of multi-type storage including hyperconverged storage

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP5400482B2 (ja) * 2009-06-04 2014-01-29 株式会社日立製作所 管理計算機、リソース管理方法、リソース管理プログラム、記録媒体および情報処理システム
US9164791B2 (en) * 2012-07-02 2015-10-20 International Business Machines Corporation Hierarchical thresholds-based virtual machine configuration
WO2014032287A1 (zh) * 2012-08-31 2014-03-06 华为技术有限公司 中央处理器资源分配方法和计算节点
US9692706B2 (en) * 2013-04-15 2017-06-27 International Business Machines Corporation Virtual enhanced transmission selection (VETS) for lossless ethernet
JP6349264B2 (ja) * 2015-01-19 2018-06-27 株式会社日立製作所 計算資源割当て方法およびシステム
US9535738B2 (en) * 2015-04-03 2017-01-03 International Business Machines Corporation Migrating virtual machines based on relative priority of virtual machine in the context of a target hypervisor environment
JP2018097708A (ja) * 2016-12-15 2018-06-21 富士通株式会社 情報処理装置、情報処理システム、情報処理プログラム及び情報処理方法
US10860367B2 (en) * 2018-03-14 2020-12-08 Microsoft Technology Licensing, Llc Opportunistic virtual machine migration

Also Published As

Publication number Publication date
WO2019225429A1 (ja) 2019-11-28
US12001868B2 (en) 2024-06-04
JP2019204309A (ja) 2019-11-28
US20210216350A1 (en) 2021-07-15

Similar Documents

Publication Publication Date Title
JP6969499B2 (ja) Vmマイグレーションシステムおよびvmマイグレーション方法
KR102624607B1 (ko) 고성능 ssd들을 사용하여 롱 테일 레이턴시를 감소시키기 위한 랙-레벨의 스케줄링
CN110869909B (zh) 应用机器学习算法来计算健康分数以进行工作负载调度的系统和方法
CN107239336B (zh) 一种实现任务调度的方法及装置
JP4781089B2 (ja) タスク割り当て方法およびタスク割り当て装置
JP5851618B2 (ja) 複数の企業データセンタおよびクラウドにおける複数の仮想マシンマイグレーションのネットワーク対応調整
CN107111517B (zh) 针对归约器任务的虚拟机优化分配和/或生成
US9921861B2 (en) Virtual machine management method and information processing apparatus
KR20160087706A (ko) 가상화 플랫폼을 고려한 분산 데이터 처리 시스템의 자원 할당 장치 및 할당 방법
KR101471749B1 (ko) 클라우드 서비스의 가상자원 할당을 위한 퍼지 로직 기반의 자원평가 장치 및 방법
JP6973292B2 (ja) Vm優先度制御システムおよびvm優先度制御方法
CN107967164B (zh) 一种虚拟机热迁移的方法及系统
Farahnakian et al. Hierarchical vm management architecture for cloud data centers
Modarressi et al. Using task migration to improve non-contiguous processor allocation in NoC-based CMPs
Stavrinides et al. Orchestrating bag-of-tasks applications with dynamically spawned tasks in a distributed environment
JP2013210833A (ja) ジョブ管理装置、ジョブ管理方法、及びプログラム
JP6795536B2 (ja) Vm性能保証システムおよびvm性能保証方法
CN104008001B (zh) 用于大数据支撑的虚拟机动态迁移方法
Wided et al. A novel agent based load balancing model for maximizing resource utilization in grid computing
JP6285850B2 (ja) プロセスマイグレーション方法及びクラスタシステム
KR20230064963A (ko) 클러스터 컴퓨팅 시스템에서의 리소스 할당 방법 및 장치
Nzanywayingoma et al. Task scheduling and virtual resource optimising in Hadoop YARN-based cloud computing environment
Chen et al. Throughput enhancement through selective time sharing and dynamic grouping
WO2022102087A1 (ja) コンピュータシステムおよびフロー制御方法
Gu Efficient Resource Management for Deep Learning Clusters

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: 20210928

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20211011

R150 Certificate of patent or registration of utility model

Ref document number: 6969499

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150