WO2020166423A1 - リソース管理装置およびリソース管理方法 - Google Patents

リソース管理装置およびリソース管理方法 Download PDF

Info

Publication number
WO2020166423A1
WO2020166423A1 PCT/JP2020/004034 JP2020004034W WO2020166423A1 WO 2020166423 A1 WO2020166423 A1 WO 2020166423A1 JP 2020004034 W JP2020004034 W JP 2020004034W WO 2020166423 A1 WO2020166423 A1 WO 2020166423A1
Authority
WO
WIPO (PCT)
Prior art keywords
guest
host
processing
resource management
priority
Prior art date
Application number
PCT/JP2020/004034
Other languages
English (en)
French (fr)
Inventor
藤本　圭
光平 的場
荒岡　誠
Original Assignee
日本電信電話株式会社
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 日本電信電話株式会社 filed Critical 日本電信電話株式会社
Priority to US17/428,242 priority Critical patent/US12039375B2/en
Publication of WO2020166423A1 publication Critical patent/WO2020166423A1/ja

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/48—Program initiating; Program switching, e.g. by interrupt
    • G06F9/4806—Task transfer initiation or dispatching
    • G06F9/4843—Task transfer initiation or dispatching by program, e.g. task dispatcher, supervisor, operating system
    • G06F9/4881—Scheduling strategies for dispatcher, e.g. round robin, multi-level priority queues
    • 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
    • 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
    • G06F2009/4557—Distribution of virtual machine instances; Migration and load balancing
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
    • Y02D10/00—Energy efficient computing, e.g. low power processors, power management or thermal management

Definitions

  • the present invention relates to a resource management device and a resource management method for a virtualization system.
  • Patent Document 1 discloses a technique for guaranteeing the bandwidth in the host-guest section according to the priority of the packet in order to realize the bandwidth guarantee in the virtual environment.
  • Patent Document 2 in the task scheduling of a real-time OS (Operating System), when a high priority task and a low priority task are combined, the CPU resource is also assigned to the low priority task.
  • a technique of dispatching from a task in a ready state is disclosed.
  • Japanese Patent Application Laid-Open No. 2004-242242 discloses a technique of setting a priority of processing task assignment for task scheduling according to a priority of a packet and preempting a task according to the priority.
  • multiple virtual machines operate by sharing CPU resources, so multiple tasks (for example, first guest and second guest) are created by a task scheduler such as CFS (Completely Fare Scheduler).
  • CFS Comppletely Fare Scheduler
  • the other guest cannot perform processing using the CPU, so there is a possibility that network delay will occur due to waiting for CPU time.
  • the packet transfer rate is high (eg, 1 Gbps or higher)
  • the CPU time allocated to the first guest by the packet processed by the host In some cases, the packets waiting for processing cannot be completely processed, and packets waiting to be processed are accumulated in the queue held by the first guest, resulting in a large delay of several hundred ms.
  • FIG. 4 is an explanatory diagram schematically showing the relationship between CPU time and packet processing.
  • the first guest (Guest 1) further processes the packet processed by the host by taking time in the vertical axis direction
  • the packet processing status in the host is on the left side
  • the packet processing in the first guest is on the right side. The situation is shown schematically.
  • the host occupies the CPU, packet processing can be continuously performed, whereas on the guest side, the first guest and the second guest (Guest2) share the CPU, so packet processing is intermittent. Becomes Therefore, the first guest cannot complete the processing of the packet arriving from the host within the CPU time, and accumulates it in the queue. As the processing progresses, it is necessary to wait a plurality of CPU cycles until the processing is executed after the packet arrives from the host to the first guest, which causes a delay. For example, the process completed by the first guest at time T2 is the process delivered by the host by time T1, and the process between time T2 and T1 is accumulated in the queue of the first guest. ing. Furthermore, when packets are accumulated up to the maximum queue size of the first guest, packet loss will occur thereafter.
  • the present invention has been made in view of such circumstances, and an object of the present invention is to efficiently use the CPU resource shared by a plurality of guests and improve the processing performance of the entire system.
  • the invention according to claim 1 provides a host OS operating on hardware, and a plurality of guests operating on a plurality of virtual machines virtually constructed on the host OS.
  • a resource management device that manages resources of a virtualization system having an OS, wherein a plurality of the virtual machines share CPU resources realized by the hardware, and from the host OS to the guest OS. It is calculated by the guest priority calculation unit that calculates the processing priority of at least one of the guest OSs based on at least one of the packet transfer rate and the availability of the kernel buffer of the host OS, and the guest priority calculation unit. And a resource utilization control unit that controls the utilization time distribution of the CPU resources by the plurality of guest OSs based on the processing priority.
  • the invention according to claim 4 is a virtualization having a host OS operating on hardware, and a plurality of guest OSs respectively operating on a plurality of virtual machines virtually constructed on the host OS.
  • the resource management device (resource management unit) can dynamically change the usage time of the CPU resource by the plurality of guest OSs, improve CPU usage efficiency, and perform processing in the guest OS. It is possible to reduce the delay of the network in the server due to the delay.
  • the guest priority calculation unit increases the processing priority of the guest OS as the packet transfer rate is higher or the kernel buffer has less space.
  • the resource management device according to claim 1.
  • the processing priority of the guest OS is set higher as the packet transfer rate is higher or the available space in the kernel buffer is smaller.
  • the guest priority calculation unit determines, among the plurality of guest OSs, a guest OS that executes an application that requires network processing requiring real-time processing, as the processing priority calculation target.
  • a guest OS that executes an application that requires network processing requiring real-time processing among the plurality of guest OSs is a processing priority calculation target.
  • CPU resources can be distributed according to the state of the guest OS in which the processing load easily changes, and the utilization efficiency of the CPU can be improved.
  • FIG. 1 is a diagram showing a configuration of a server 10 according to the embodiment.
  • the server 10 includes a hardware (HW) 102, a host (Host) OS 104, a hypervisor (Hypervisor) 106, a first virtual machine (VM1) 108A, a first guest OS (Guest1) 110A, and a second virtual machine ( The VM 2) 108B, the second guest OS (Guest 2) 110B, and the applications 112A and 112B.
  • the hardware 102 is, for example, an IA (Intel Architecture) server (“Intel” is a registered trademark), includes a CPU 1022, a network interface card (NIC) 1024, and the like, and physically configures the server 10.
  • the host OS 104 provides the function of the hardware 102 to the upper layer.
  • the hypervisor 106 provides a virtualization environment on the host OS 104, and in this embodiment, as an example, the first virtual machine 108A and the second virtual machine 108B are constructed.
  • the first virtual machine 108A and the second virtual machine 108B have virtual CPUs (vCPUs) 1082A and 1082B and virtual network interface cards (vNICs) 1084A and 1084B, respectively, but are actually physical hardware 102.
  • the CPU 1022 and the network interface card 1024 realize the function.
  • the first guest OS 110A and the second guest OS 110B operate on the first virtual machine 108A and the second virtual machine 108B, respectively.
  • both the first guest OS 110A and the second guest OS 110B are referred to as the guest OS 110.
  • the applications 112A and 112B operate on the first guest OS 110A and the second guest OS 110B, respectively.
  • the server 10 is a virtualization including a host OS 104 that operates on the hardware 102 and a plurality of guest OSs 110A and 110B that respectively operate on a plurality of virtual machines 108A and 108B that are virtually constructed on the host OS 104. System.
  • the first guest OS 110A executes an application 112A that requires high real-time network processing (which requires real-time processing) and the second guest OS 110B executes non-real-time application 112B that requires CPU processing. Shall be executed. More specifically, the first guest OS 110A causes the guest packet processing unit 1102A to process the packet transmitted from the packet transmission device 30 outside the server 10. The packet transmitted from the packet transmission device 30 is first received by the network interface card 1024 and delivered to the guest packet processing unit 1102A via the host packet processing unit 1042 of the host OS 104.
  • the guest packet processing unit 1102A virtually performs packet processing by the virtual CPU 1082A, but in reality, the CPU 1022 performs processing. Similarly, the virtual CPU 1082B is also actually processed by the CPU 1022. That is, the plurality of virtual machines 108A and 108B share the resources of the CPU 1022 realized by the hardware 102.
  • a resource management unit 20 that manages the resources of the CPU 1022 is provided in the host OS 104 to improve the utilization efficiency of the CPU 1022 and suppress the processing delay in each guest OS 110.
  • the resource management unit 20 includes a guest priority calculation unit 202 and a resource usage control unit 204.
  • the guest priority calculation unit 202 based on at least one of the packet transfer rate from the host OS 104 to the guest OS 110 and the availability of the kernel buffer of the host OS 104, at least one guest OS 110 of the plurality of guest OSs 110A and 110B ( Hereinafter, the processing priority of the “monitored guest OS”) is calculated.
  • the resource management unit 20 includes a packet transfer rate measuring unit 206 and a buffer availability monitoring unit 208, measures both the packet transfer rate and the availability of the kernel buffer, and based on this, the guest
  • the priority calculation unit 202 calculates the processing priority of the monitored guest OS.
  • the processing priority may be calculated using only one of the packet transfer rate and the availability of the kernel buffer.
  • the packet transfer rate measurement unit 206 monitors the packet transfer rate for each guest OS 110A and 110B.
  • vhost-net which is a virtual device
  • the packet transfer rate in vhost-net is monitored, the packet transfer rate can be calculated in units of each guest OS 110A, 110B. Can be monitored.
  • the packet transfer rate cannot be acquired for each guest OS 110A, 110B.
  • /proc/net/dev such as acquiring the packet transfer rate of the network device of the host OS 104.
  • the amount of packets transferred to each guest OS 110A, 110B cannot be measured in units of flows as described above, the effect is low even if both guest OSs 110A, 110B are used as the guest OSes to be monitored. There is also thought to be.
  • the buffer availability monitoring unit 208 for example, a function of monitoring the availability of the kernel buffer provided in the kernel of the host OS 104 can be used. By using such a function, it is possible to detect the buffer empty state in real time, and it is possible to promptly deal with the situation when the buffer empty size is exhausted. For example, when the vhost-net kernel buffer described above is monitored by the buffer availability monitoring unit 208, the buffer availability can be identified by the flow of each guest OS 110A, 110B. On the other hand, when the ring buffer managed by the network driver under the host OS 104 is monitored, it is impossible to count the buffer free status of the flow in each guest OS 110A, 110B.
  • the guest priority calculation unit 202 increases the processing priority of the monitored guest OS as the packet transfer rate to the guest OS 110 (particularly the monitored guest OS) is higher or the kernel buffer has less space. That is, when the packet transfer rate to the monitored guest OS is high, the amount of packets handed over from the host OS 104 to the monitored guest OS is increasing, and the processing load on the monitored guest OS is considered to increase. To be Even when the kernel buffer has a small free space, it is expected that the amount of packets delivered from the host OS 104 to the monitored guest OS will increase, and the processing load on the monitored guest OS will increase. Therefore, the guest priority calculation unit 202 relatively increases the processing priority of the monitored guest OS when the packet transfer rate increases or the kernel buffer free space decreases.
  • the processing priority of the monitored guest OS is set relatively low. Note that the relationship between the packet transfer rate, the value of the free space in the kernel buffer, and the processing priority may be dynamically calculated using machine learning.
  • the resource use control unit 204 controls the CPU resource use time distribution by the plurality of guest OSs 110A and 110B based on the processing priority calculated by the guest priority calculation unit 202.
  • FIG. 2 is an explanatory diagram schematically showing the distribution of CPU resource usage times by the resource usage control unit 204.
  • the center of FIG. 2 shows usage time distribution in a predetermined reference state (for example, when the processing priority of the first guest OS 110A exceeds a predetermined threshold value 1 and is less than a predetermined threshold value 2 (>threshold value 1)). ..
  • a predetermined reference state for example, when the processing priority of the first guest OS 110A exceeds a predetermined threshold value 1 and is less than a predetermined threshold value 2 (>threshold value 1).
  • the first guest OS 110A (Guest1) and the second guest OS 110B (Guest2) alternately use the CPU 1022 for the same time (t1).
  • the right side of FIG. 2 shows the usage time distribution when the processing priority of the first guest OS 110A becomes high (for example, when it is the threshold 2 or more).
  • the usage time of the CPU 1022 of the first guest OS 110A is set longer than that of the second guest OS 110B.
  • the usage time of the CPU 1022 of the first guest OS 110A is set longer (t2 (>t1) in the illustrated example) and the usage time of the CPU 1022 of the second guest OS 110B is set shorter than that in the reference state (the illustrated example).
  • t3 ( ⁇ t1)).
  • the time t2 may be lengthened (or the time t3 shortened) in proportion to the magnitude of the processing priority of the first guest OS 110A.
  • the left side of FIG. 2 shows the usage time distribution when the processing priority of the first guest OS 110A becomes low (for example, when it is less than or equal to the above threshold 1).
  • the usage time of the CPU 1022 of the first guest OS 110A is set shorter than that of the second guest OS 110B.
  • the usage time of the CPU 1022 of the first guest OS 110A is shorter than that in the reference state (t4 ( ⁇ t1) in the illustrated example) and the usage time of the CPU 1022 of the second guest OS 110B is set to be longer (illustrated in the drawing).
  • t5 (>t1)).
  • the time t4 may be shortened (or the time t5 may be lengthened) in proportion to the magnitude of the processing priority of the first guest OS 110A.
  • the guest priority calculation unit 202 calculates the processing priority of the guest OS that executes an application that requires network processing with high real-time property, that is, the first guest OS 110A among the plurality of guest OSs 110.
  • the resource use control unit 204 controls the CPU resource use time distribution based on the processing priority of the first guest OS 110A.
  • the first guest OS 110A and the second guest OS 110A are not used. If both guest OSs 110B execute applications 112A and 112B that require highly realistic network processing, the effect of improving the utilization efficiency of CPU resources is considered to be low. Alternatively, only the second guest OS 110B may be the guest OS to be monitored.
  • FIG. 3 is a flowchart showing the procedure of processing by the resource management unit 20.
  • the packet transfer rate measurement unit 206 measures the packet transfer rate from the host OS 104 to the guest OS 110 (eg, xxMbps, etc.) and temporarily records the value in a memory or the like (step S300).
  • the buffer availability monitoring unit 208 acquires the availability of the kernel buffer of the host OS 104 and temporarily records the value in a memory or the like (step S302).
  • the guest priority calculation unit 202 determines the processing priority of the first guest OS 110A based on the packet transfer rate measured in step S300 (step S304), and the first guest based on the availability of the kernel buffer acquired in step S302.
  • the processing priority of the OS 110A is calculated (step S306).
  • the guest priority calculation unit 202 determines the processing priority to be adopted from the processing priorities calculated in step S304 and step S306 (step S308). Specifically, for example, the higher one of the two processing priorities is adopted.
  • the resource usage control unit 204 sets the usage time of the CPU 1022 for the virtual CPUs (vCPUs) 1082A and 1082B of the virtual machines 108A and 108B based on the adopted processing priority (step S310).
  • the resource management unit 20 can dynamically change the usage time of the CPU resources by the plurality of guest OSs 110 by repeating the procedure of the above processing at predetermined time intervals.
  • the server 10 it is possible to dynamically change the usage time of CPU resources by a plurality of guest OSs, improve CPU usage efficiency, and perform processing in the guest OS. It is possible to reduce the delay of the network in the server due to the delay.

Landscapes

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

Abstract

【課題】複数のゲストが共有するＣＰＵリソースを効率的に利用し、システム全体の処理性能を向上させる。 【解決手段】サーバ１０は、ホストＯＳ１０４と、ホストＯＳ１０４上に仮想的に構築された複数の仮想マシン１０８Ａ，１０８Ｂ上でそれぞれ動作する複数のゲストＯＳ１１０Ａ，１１０Ｂとを有する。複数の仮想マシン１０８Ａ，１０８Ｂは、ハードウェア１０２により実現されるＣＰＵリソースを共有している。リソース管理装置（リソース管理部２０）のゲスト優先度算出部２０２は、ホストＯＳ１０４からゲストＯＳ１１０へのパケット転送レート、ホストＯＳ１０４のカーネルバッファの空き状況の少なくともいずれかに基づいて、少なくとも１つのゲストＯＳ１１０の処理優先度を算出する。また、リソース利用制御部２０４は、算出された処理優先度に基づいて、複数のゲストＯＳ１１０によるＣＰＵリソースの利用時間配分を制御する。

Description

リソース管理装置およびリソース管理方法
　本発明は、仮想化システムのリソース管理装置およびリソース管理方法に関する。
　従来、システム内のリソース利用状態を適切に管理することによって、システムの処理効率を向上させる技術が提案されている。
　例えば、下記特許文献１には、仮想環境下において帯域保証を実現するために、パケットの優先度に応じてホスト－ゲスト区間の帯域保証を行う技術が開示されている。
　また、下記特許文献２には、リアルタイムＯＳ（Operating System）のタスクスケジューリングにおいて、優先度の高いタスクと優先度の低いタスクが合あった場合に、優先度の低いタスクにもＣＰＵリソースが割り当たるように、レディ状態にあるタスクからディスパッチする技術が開示されている。
　また、下記特許文献３には、パケットの優先度に応じて、タスクスケジューリングの処理タスク割当ての優先度を設定し、優先度に応じてタスクの横取りを行う技術が開示されている。
特開２０１７－４１８５８号公報 特開平８－２４９１９４号公報 特開平９－４６３７３号公報
　サーバ仮想化環境下において、複数の仮想マシンがＣＰＵリソースを共有して動作するために、ＣＦＳ（Completely Fare Scheduler）等のタスクスケジューラにより、複数のゲスト（例えば第１のゲストと第２のゲスト）がＣＰＵを使用できる時間を交互に切り替えて、ＣＰＵタイムを割り当てる技術が提案されている（例えば、Ｌｉｎｕｘ（登録商標）ｋｅｒｎｅｌ　２．６．２３以降にはＣＦＳが搭載されている）。
　このような構成では、一方のゲストがＣＰＵを使用している時間は、他方のゲストがＣＰＵを使用した処理を行えないため、ＣＰＵタイム待ちによるネットワーク遅延が発生する可能性がある。例えば、ホストが処理したパケットを第１のゲストが更に処理する場合、パケットの転送レートが高速（例えば１Ｇｂｐｓ以上等）であると、ホストが処理したパケットを第１のゲストに割り当てられたＣＰＵタイム内に処理しきれず、第１のゲストが保有するキューに処理待ちパケットが蓄積し、数百ｍｓ程度の大きな遅延が発生する場合がある。
　図４は、ＣＰＵタイムとパケット処理の関係を模式的に示す説明図である。
　図４では、縦軸方向に時間を取り、ホストが処理したパケットを第１のゲスト（Ｇｕｅｓｔ１）が更に処理する場合について、左側にホストにおけるパケット処理状況を、右側に第１のゲストにおけるパケット処理状況を、それぞれ模式的に示している。
　ホストはＣＰＵを占有しているためパケット処理を継続的に行えるのに対して、ゲスト側では第１のゲストと第２のゲスト（Ｇｕｅｓｔ２）とによりＣＰＵを共有しているためパケット処理が断続的となる。
　よって、第１のゲストは、ホストから到着するパケットの処理をＣＰＵタイム内に完了することができず、キューに貯め込んでいく。処理が進んでいくと、ホストから第１のゲストにパケットが到着してから処理を実行するまで複数ＣＰＵサイクル待つ必要があり、遅延が生じる。例えば、時刻Ｔ２の時点において第１のゲストで完了している処理は、ホストが時刻Ｔ１までに引き渡した処理までであり、時刻Ｔ２－Ｔ１間の処理は、第１のゲストのキューに蓄積されている。更に、パケットが第１のゲストの最大キューサイズまで貯まると、以降パケットロスが発生することになる。
　このような課題に対応するため、例えば、パケット処理を行う第１のゲストのＣＰＵ使用優先度を高く設定し、第１のゲストに割り当てるＣＰＵタイムを拡大することで、パケット処理のネットワーク遅延を小さくする方法が考えられる。しかし、この方法では、第２のゲストのＣＰＵタイムが定常的に減少し、ＣＰＵの利用効率が低下するという課題がある。例えば、第１のゲストのｑｅｍｕ－ｋｖｍプロセスのｎｉｃｅ値＝－１０と設定すると、第２のゲストのＣＰＵタイムが減少することにより、第２のゲストへのＳＳＨ（Secure Shell）ログインすらできなくなる。
　本発明は、このような事情に鑑みなされたものであり、複数のゲストが共有するＣＰＵリソースを効率的に利用し、システム全体の処理性能を向上させることを目的とする。
　上述の目的を達成するため、請求項１に記載の発明は、ハードウェア上で動作するホストＯＳと、前記ホストＯＳ上に仮想的に構築された複数の仮想マシン上でそれぞれ動作する複数のゲストＯＳとを有する仮想化システムのリソースを管理するリソース管理装置であって、複数の前記仮想マシンが、前記ハードウェアにより実現されるＣＰＵリソースを共有しており、前記ホストＯＳから前記ゲストＯＳへのパケット転送レート、前記ホストＯＳのカーネルバッファの空き状況の少なくともいずれかに基づいて、少なくとも１つの前記ゲストＯＳの処理優先度を算出するゲスト優先度算出部と、前記ゲスト優先度算出部により算出された前記処理優先度に基づいて、複数の前記ゲストＯＳによる前記ＣＰＵリソースの利用時間配分を制御するリソース利用制御部と、を備えることを特徴とするリソース管理装置とした。
　また、請求項４に記載の発明は、ハードウェア上で動作するホストＯＳと、前記ホストＯＳ上に仮想的に構築された複数の仮想マシン上でそれぞれ動作する複数のゲストＯＳとを有する仮想化システムのリソースを管理するリソース管理装置のリソース管理方法であって、複数の前記仮想マシンが、前記ハードウェアにより実現されるＣＰＵリソースを共有しており、前記リソース管理装置が、前記ホストＯＳから前記ゲストＯＳへのパケット転送レート、前記ホストＯＳのカーネルバッファの空き状況の少なくともいずれかに基づいて、少なくとも１つの前記ゲストＯＳの処理優先度を算出するゲスト優先度算出工程と、算出された前記処理優先度に基づいて、複数の前記ゲストＯＳによる前記ＣＰＵリソースの利用時間配分を制御するリソース利用制御工程と、を実行することを特徴とするリソース管理方法とした。
　このようにすることで、リソース管理装置（リソース管理部）は、複数のゲストＯＳによるＣＰＵリソースの利用時間を動的に変更することができ、ＣＰＵの利用効率を向上させるとともに、ゲストＯＳにおける処理遅延に起因するサーバ内ネットワークの遅延を低減することができる。
　また、請求項２に記載の発明は、前記ゲスト優先度算出部が、前記パケット転送レートが高いほど、または、前記カーネルバッファの空きが少ないほど、前記ゲストＯＳの処理優先度を高くする、ことを特徴とする請求項１に記載のリソース管理装置とした。
　また、請求項５に記載の発明は、前記ゲスト優先度算出工程では、前記パケット転送レートが高いほど、または、前記カーネルバッファの空きが少ないほど、前記ゲストＯＳの処理優先度を高くする、ことを特徴とする請求項４に記載のリソース管理方法とした。
　このようにすることで、ゲストＯＳにおけるパケット処理負荷を精度よく反映することができる。
　また、請求項３に記載の発明は、前記ゲスト優先度算出部が、複数の前記ゲストＯＳのうち、リアルタイム性が求められるネットワーク処理を要するアプリケーションを実行するゲストＯＳを前記処理優先度の算出対象とする、ことを特徴とする請求項１または請求項２に記載のリソース管理装置とした。
　また、請求項６に記載の発明は、前記ゲスト優先度算出工程では、複数の前記ゲストＯＳのうち、リアルタイム性が求められるネットワーク処理を要するアプリケーションを実行するゲストＯＳを前記処理優先度の算出対象とする、ことを特徴とする請求項４または請求項５に記載のリソース管理方法とした。
　このようにすることで、処理負荷が変動しやすいゲストＯＳの状態に合わせてＣＰＵリソースを配分することができ、ＣＰＵの利用効率を向上させることができる。
　本発明によれば、複数のゲストが共有するＣＰＵリソースを効率的に利用し、システム全体の処理性能を向上させることができる。
実施の形態にかかるサーバの構成を示す図である。 リソース利用制御部によるＣＰＵリソースの利用時間配分を模式的に示す説明図である。 リソース管理部による処理の手順を示すフローチャートである。 ＣＰＵタイムとパケット処理の関係を模式的に示す説明図である。
　以下に添付図面を参照して、本発明にかかるリソース管理装置およびリソース管理方法の好適な実施の形態を詳細に説明する。本実施の形態では、複数の仮想マシン（ゲスト）が構成されたサーバに本発明にかかるリソース管理装置およびリソース管理方法を適用した場合について説明する。
　図１は、実施の形態にかかるサーバ１０の構成を示す図である。
　サーバ１０は、ハードウェア（ＨＷ）１０２、ホスト（Ｈｏｓｔ）ＯＳ１０４、ハイパーバイザ（Ｈｙｐｅｒｖｉｓｏｒ）１０６、第１の仮想マシン（ＶＭ１）１０８Ａ、第１のゲストＯＳ（Ｇｕｅｓｔ１）１１０Ａ、第２の仮想マシン（ＶＭ２）１０８Ｂ、第２のゲストＯＳ（Ｇｕｅｓｔ２）１１０Ｂ、アプリケーション１１２Ａ，１１２Ｂを備える。
　ハードウェア１０２は、例えばＩＡ（Intel Architecture）サーバ（「Intel」は登録商標）であり、ＣＰＵ１０２２やネットワークインターフェースカード（ＮＩＣ）１０２４等を備え、サーバ１０を物理的に構成する。
　ホストＯＳ１０４は、ハードウェア１０２の機能を上位レイヤに提供する。
　ハイパーバイザ１０６は、ホストＯＳ１０４の上で仮想化環境を提供し、本実施の形態では、例として、第１の仮想マシン１０８Ａおよび第２の仮想マシン１０８Ｂを構築する。
　第１の仮想マシン１０８Ａ、第２の仮想マシン１０８Ｂは、それぞれ仮想ＣＰＵ（ｖＣＰＵ）１０８２Ａ，１０８２Ｂや仮想ネットワークインターフェースカード（ｖＮＩＣ）１０８４Ａ，１０８４Ｂを有するが、実際には物理的なハードウェア１０２であるＣＰＵ１０２２やネットワークインターフェースカード１０２４がその機能を実現する。
　第１のゲストＯＳ１１０Ａ、第２のゲストＯＳ１１０Ｂは、それぞれ第１の仮想マシン１０８Ａ、第２の仮想マシン１０８Ｂ上で動作する。以下、第１のゲストＯＳ１１０Ａと第２のゲストＯＳ１１０Ｂとの両方を指す場合には、ゲストＯＳ１１０と称する。
　アプリケーション１１２Ａ、１１２Ｂは、それぞれ第１のゲストＯＳ１１０Ａ、第２のゲストＯＳ１１０Ｂ上で動作する。
　すなわち、サーバ１０は、ハードウェア１０２上で動作するホストＯＳ１０４と、ホストＯＳ１０４上に仮想的に構築された複数の仮想マシン１０８Ａ，１０８Ｂ上でそれぞれ動作する複数のゲストＯＳ１１０Ａ，１１０Ｂとを有する仮想化システムである。
　本実施の形態では、第１のゲストＯＳ１１０Ａはリアルタイム性の高い（リアルタイム性が求められる）ネットワーク処理を要するアプリケーション１１２Ａを実行し、第２のゲストＯＳ１１０ＢはＣＰＵ処理を要する非リアルタイム処理を行うアプリケーション１１２Ｂを実行するものとする。
　より詳細には、第１のゲストＯＳ１１０Ａは、サーバ１０の外部にあるパケット送信装置３０から送信されたパケットをゲストパケット処理部１１０２Ａで処理する。パケット送信装置３０から送信されたパケットは、まずネットワークインターフェースカード１０２４で受信され、ホストＯＳ１０４のホストパケット処理部１０４２を介してゲストパケット処理部１１０２Ａへと引き渡される。
　ゲストパケット処理部１１０２Ａは、仮想的には仮想ＣＰＵ１０８２Ａによりパケット処理を行うが、実体的にはＣＰＵ１０２２により処理が行われる。同様に、仮想ＣＰＵ１０８２Ｂについても、実体的にはＣＰＵ１０２２が処理を行う。すなわち、複数の仮想マシン１０８Ａ，１０８Ｂは、ハードウェア１０２により実現されるＣＰＵ１０２２のリソースを共有している。
　例えば、第１のゲストＯＳ１１０Ａ（仮想ＣＰＵ１０８２Ａ）がＣＰＵ１０２２を使用する時間と、第２のゲストＯＳ１１０Ｂ（仮想ＣＰＵ１０８２Ｂ）がＣＰＵ１０２２を使用する時間とが固定されていると、例えば一方のゲストＯＳ１１０の処理負荷が増大した場合（一時的にパケット送信装置３０から送信されるパケットが増大した場合など）に処理に遅延が生じる。
　そこで、ホストＯＳ１０４にＣＰＵ１０２２のリソースを管理するリソース管理部２０（リソース管理装置）を設け、ＣＰＵ１０２２の利用効率を向上させ、各ゲストＯＳ１１０における処理の遅延を抑制している。
　リソース管理部２０は、ゲスト優先度算出部２０２とリソース利用制御部２０４とを備える。
　ゲスト優先度算出部２０２は、ホストＯＳ１０４からゲストＯＳ１１０へのパケット転送レートと、ホストＯＳ１０４のカーネルバッファの空き状況の少なくともいずれかに基づいて、複数のゲストＯＳ１１０Ａ，１１０Ｂのうち少なくとも１つのゲストＯＳ１１０（以下「監視対象ゲストＯＳ」という）の処理優先度を算出する。
　本実施の形態では、リソース管理部２０は、パケット転送レート計測部２０６およびバッファ空き状況監視部２０８を備えており、パケット転送レートおよびカーネルバッファの空き状況の両方を測定し、これに基づいてゲスト優先度算出部２０２は監視対象ゲストＯＳの処理優先度を算出する。なお、パケット転送レートと、カーネルバッファの空き状況のいずれか一方のみを用いて処理優先度を算出してもよい。
　パケット転送レート計測部２０６は、例えば各ゲストＯＳ１１０Ａ，１１０Ｂへのフローごとにパケット転送レートを識別できる場合には、各ゲストＯＳ１１０Ａ，１１０Ｂ単位でパケット転送レートを監視する。例えば、仮想デバイスであるｖｈｏｓｔ－ｎｅｔは、仮想マシン１０８（１０８Ａ，１０８Ｂ）単位で生成されるので、このｖｈｏｓｔ－ｎｅｔにおけるパケット転送レートを監視すれば、各ゲストＯＳ１１０Ａ，１１０Ｂ単位でパケット転送レートを監視することができる。
　一方で、環境に依っては、各ゲストＯＳ１１０Ａ，１１０Ｂ単位でパケット転送レートを取得できない可能性がある。この場合は、例えば／ｐｒｏｃ／ｎｅｔ／ｄｅｖといった、ホストＯＳ１０４が持つネットワークデバイスのパケット転送レートを取得する等の対応が考えられる。なお、このように各ゲストＯＳ１１０Ａ，１１０Ｂへのフロー単位にパケット転送量を分計できない場合には、後述するように２つのゲストＯＳ１１０Ａ，１１０Ｂの両方を監視対象ゲストＯＳにしても効果が低い場合もあると考えられる。
　バッファ空き状況監視部２０８としては、例えばホストＯＳ１０４のカーネルに備えられたカーネルバッファの空き状況を監視する機能を利用することができる。このような機能を利用すれば、リアルタイムにバッファ空き状況を検知することができ、例えばバッファの空きサイズが枯渇してきた際に迅速に対応することができる。
　バッファ空き状況監視部２０８の監視対象として、例えば前述したｖｈｏｓｔ－ｎｅｔのカーネルバッファを監視する場合は、各ゲストＯＳ１１０Ａ，１１０Ｂ単位のフローでバッファ空き状況を識別可能となる。一方、ホストＯＳ１０４配下のネットワークドライバが管理するリングバッファを監視する場合は、各ゲストＯＳ１１０Ａ，１１０Ｂ単位でのフローのバッファ空き状況を分計することはできない。
　ゲスト優先度算出部２０２は、ゲストＯＳ１１０（特に監視対象ゲストＯＳ）へのパケット転送レートが高いほど、またはカーネルバッファの空きが少ないほど、監視対象ゲストＯＳの処理優先度を高くする。
　すなわち、監視対象ゲストＯＳへのパケット転送レートが高い場合には、ホストＯＳ１０４から監視対象ゲストＯＳに引き渡されるパケット量が増大しており、監視対象ゲストＯＳでの処理負荷が増加していると考えられる。また、カーネルバッファの空きが少ない場合にも、ホストＯＳ１０４から監視対象ゲストＯＳに引き渡されるパケット量が増大し、監視対象ゲストＯＳでの処理負荷が増加すると予想される。
　このため、ゲスト優先度算出部２０２は、パケット転送レートの上昇やカーネルバッファの空きの減少があった場合には、監視対象ゲストＯＳの処理優先度を相対的に高くする。また、反対にパケット転送レートの低下やカーネルバッファの空きの増加があった場合には、監視対象ゲストＯＳの処理優先度を相対的に低くする。
　なお、パケット転送レートやカーネルバッファの空き容量の値と、処理優先度との関係を、機械学習を用いて動的に算出してもよい。
　リソース利用制御部２０４は、ゲスト優先度算出部２０２により算出された処理優先度に基づいて、複数のゲストＯＳ１１０Ａ，１１０ＢによるＣＰＵリソースの利用時間配分を制御する。
　図２は、リソース利用制御部２０４によるＣＰＵリソースの利用時間配分を模式的に示す説明図である。
　図２の中央は、所定の基準状態（例えば第１のゲストＯＳ１１０Ａの処理優先度が所定の閾値１を超え、かつ所定の閾値２（＞閾値１）未満である場合）における利用時間配分を示す。基準状態では、例えば第１のゲストＯＳ１１０Ａ（Ｇｕｅｓｔ１）と第２のゲストＯＳ１１０Ｂ（Ｇｕｅｓｔ２）が同時間（ｔ１）ずつ交互にＣＰＵ１０２２を利用する。
　図２の右側は、第１のゲストＯＳ１１０Ａの処理優先度が高くなった場合（例えば上記閾値２以上である場合）における利用時間配分を示す。この場合には、第１のゲストＯＳ１１０ＡのＣＰＵ１０２２の利用時間を、第２のゲストＯＳ１１０Ｂと比較して長くする。具体的には、例えば基準状態よりも第１のゲストＯＳ１１０ＡのＣＰＵ１０２２の利用時間を長く（図示の例ではｔ２（＞ｔ１））、第２のゲストＯＳ１１０ＢのＣＰＵ１０２２の利用時間を短くする（図示の例ではｔ３（＜ｔ１））。時間ｔ２は、第１のゲストＯＳ１１０Ａの処理優先度の大きさに比例して長く（または時間ｔ３を短く）してもよい。
　図２の左側は、第１のゲストＯＳ１１０Ａの処理優先度が低くなった場合（例えば上記閾値１以下である場合）における利用時間配分を示す。この場合には、第１のゲストＯＳ１１０ＡのＣＰＵ１０２２の利用時間を、第２のゲストＯＳ１１０Ｂと比較して短くする。具体的には、例えば基準状態よりも第１のゲストＯＳ１１０ＡのＣＰＵ１０２２の利用時間を短く（図示の例ではｔ４（＜ｔ１））、第２のゲストＯＳ１１０ＢのＣＰＵ１０２２の利用時間を長くする（図示の例ではｔ５（＞ｔ１））。時間ｔ4は、第１のゲストＯＳ１１０Ａの処理優先度の大きさに比例して短く（または時間ｔ５を長く）してもよい。
　このように、第１のゲストＯＳ１１０Ａの処理優先度、すなわちパケットの緩急に応じて、各ゲストＯＳ１１０のＣＰＵ１０２２の利用時間を動的に設定することにより、一方のゲストＯＳ１１０の優先度を固定する場合と比較してＣＰＵ１０２２の利用効率を向上させることができる。
　なお、本実施の形態では、ゲスト優先度算出部２０２は、複数のゲストＯＳ１１０のうち、リアルタイム性の高いネットワーク処理を要するアプリケーションを実行するゲストＯＳ、すなわち第１のゲストＯＳ１１０Ａを処理優先度の算出対象（監視対象ゲストＯＳ）とし、リソース利用制御部２０４は、第１のゲストＯＳ１１０Ａを処理優先度に基づいて、ＣＰＵリソースの利用時間配分を制御する。
　これにより、処理遅延の影響が大きいリアルタイム性の高い処理を行うのに最適化した形でＣＰＵ１０２２の利用時間を配分することができる。
　なお、第１のゲストＯＳ１１０Ａと第２のゲストＯＳ１１０Ｂの両方を監視対象ゲストＯＳとすることも可能である。しかしながら、上述のようにパケット転送レートや、カーネルバッファの空き状況について、ゲストＯＳ１１０Ａ，１１０Ｂ別に測定できない場合には、本実施の形態で例示すケースと異なり、例えば、第１のゲストＯＳ１１０Ａと第２のゲストＯＳ１１０Ｂがともにリアル性の高いネットワーク処理を要するアプリケーション１１２Ａ，１１２Ｂを実行しているとすると、ＣＰＵリソースの利用効率を向上させる効果が低くなると考えられる。
　また、第２のゲストＯＳ１１０Ｂのみを監視対象ゲストＯＳとしてもよい。
　図３は、リソース管理部２０による処理の手順を示すフローチャートである。
　パケット転送レート計測部２０６は、ホストＯＳ１０４からゲストＯＳ１１０へのパケットの転送レートを計測（例：ｘｘＭｂｐｓ等）し、その値をメモリ等に一時記録する（ステップＳ３００）。
　バッファ空き状況監視部２０８は、ホストＯＳ１０４のカーネルバッファの空き状況を取得し、その値をメモリ等に一時記録する（ステップＳ３０２）。
　ゲスト優先度算出部２０２は、ステップＳ３００で測定したパケットの転送レートに基づく第１のゲストＯＳ１１０Ａの処理優先度と（ステップＳ３０４）、ステップＳ３０２で取得したカーネルバッファの空き状況に基づく第１のゲストＯＳ１１０Ａの処理優先度とを算出する（ステップＳ３０６）。
　ゲスト優先度算出部２０２は、ステップＳ３０４およびステップＳ３０６で算出した処理優先度から、採用する処理優先度を決定する（ステップＳ３０８）。具体的には、例えば２つの処理優先度のうち高い方を採用する。
　そして、リソース利用制御部２０４は、採用した処理優先度に基づいて、各仮想マシン１０８Ａ，１０８Ｂの仮想ＣＰＵ（ｖＣＰＵ）１０８２Ａ，１０８２Ｂに対して、ＣＰＵ１０２２の利用時間を設定する（ステップＳ３１０）。
　リソース管理部２０は、上記の処理の手順を、所定の時間間隔で繰り返すことにより、複数のゲストＯＳ１１０によるＣＰＵリソースの利用時間を動的に変更することができる。
　以上説明したように、実施の形態にかかるサーバ１０によれば、複数のゲストＯＳによるＣＰＵリソースの利用時間を動的に変更することができ、ＣＰＵの利用効率を向上させるとともに、ゲストＯＳにおける処理遅延に起因するサーバ内ネットワークの遅延を低減することができる。
　１０　　サーバ
　１０２　ハードウェア
　１０２２　ＣＰＵ
　１０４　ホストＯＳ
　１０４２　ホストパケット処理部
　１０６　ハイパーバイザ
　１０８（１０８Ａ，１０８Ｂ）　仮想マシン
　１０８２（１０８２Ａ，１０８２Ｂ）　仮想ＣＰＵ
　１１０（１１０Ａ，１１０Ｂ）　ゲストＯＳ
　１１０２Ａ　ゲストパケット処理部
　１１２（１１２Ａ，１１２Ｂ）　アプリケーション
　２０　　リソース管理部（リソース管理装置）
　２０２　ゲスト優先度算出部
　２０４　リソース利用制御部
　２０６　パケット転送レート計測部
　２０８　バッファ空き状況監視部
　３０　　　パケット送信装置

Claims (6)

  1. 　ハードウェア上で動作するホストＯＳと、前記ホストＯＳ上に仮想的に構築された複数の仮想マシン上でそれぞれ動作する複数のゲストＯＳとを有する仮想化システムのリソースを管理するリソース管理装置であって、
    　複数の前記仮想マシンは、前記ハードウェアにより実現されるＣＰＵリソースを共有しており、
    　前記ホストＯＳから前記ゲストＯＳへのパケット転送レート、前記ホストＯＳのカーネルバッファの空き状況の少なくともいずれかに基づいて、少なくとも１つの前記ゲストＯＳの処理優先度を算出するゲスト優先度算出部と、
    　前記ゲスト優先度算出部により算出された前記処理優先度に基づいて、複数の前記ゲストＯＳによる前記ＣＰＵリソースの利用時間配分を制御するリソース利用制御部と、
    　を備えることを特徴とするリソース管理装置。
  2. 　前記ゲスト優先度算出部は、前記パケット転送レートが高いほど、または、前記カーネルバッファの空きが少ないほど、前記ゲストＯＳの処理優先度を高くする、
    　ことを特徴とする請求項１に記載のリソース管理装置。
  3. 　前記ゲスト優先度算出部は、複数の前記ゲストＯＳのうち、リアルタイム性が求められるネットワーク処理を要するアプリケーションを実行するゲストＯＳを前記処理優先度の算出対象とする、
    　ことを特徴とする請求項１または請求項２に記載のリソース管理装置。
  4. 　ハードウェア上で動作するホストＯＳと、前記ホストＯＳ上に仮想的に構築された複数の仮想マシン上でそれぞれ動作する複数のゲストＯＳとを有する仮想化システムのリソースを管理するリソース管理装置のリソース管理方法であって、
    　複数の前記仮想マシンは、前記ハードウェアにより実現されるＣＰＵリソースを共有しており、
    　前記リソース管理装置は、
    　前記ホストＯＳから前記ゲストＯＳへのパケット転送レート、前記ホストＯＳのカーネルバッファの空き状況の少なくともいずれかに基づいて、少なくとも１つの前記ゲストＯＳの処理優先度を算出するゲスト優先度算出工程と、
    　算出された前記処理優先度に基づいて、複数の前記ゲストＯＳによる前記ＣＰＵリソースの利用時間配分を制御するリソース利用制御工程と、
    　を実行することを特徴とするリソース管理方法。
  5. 　前記ゲスト優先度算出工程では、前記パケット転送レートが高いほど、または、前記カーネルバッファの空きが少ないほど、前記ゲストＯＳの処理優先度を高くする、
    　ことを特徴とする請求項４に記載のリソース管理方法。
  6. 　前記ゲスト優先度算出工程では、複数の前記ゲストＯＳのうち、リアルタイム性が求められるネットワーク処理を要するアプリケーションを実行するゲストＯＳを前記処理優先度の算出対象とする、
    　ことを特徴とする請求項４または請求項５に記載のリソース管理方法。
PCT/JP2020/004034 2019-02-15 2020-02-04 リソース管理装置およびリソース管理方法 WO2020166423A1 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US17/428,242 US12039375B2 (en) 2019-02-15 2020-02-04 Resource management device and resource management method

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2019-025136 2019-02-15
JP2019025136A JP7331374B2 (ja) 2019-02-15 2019-02-15 リソース管理装置およびリソース管理方法

Publications (1)

Publication Number Publication Date
WO2020166423A1 true WO2020166423A1 (ja) 2020-08-20

Family

ID=72045509

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2020/004034 WO2020166423A1 (ja) 2019-02-15 2020-02-04 リソース管理装置およびリソース管理方法

Country Status (2)

Country Link
JP (1) JP7331374B2 (ja)
WO (1) WO2020166423A1 (ja)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20240015952A (ko) * 2022-07-28 2024-02-06 삼성전자주식회사 컴퓨팅 장치 및 그 동작 방법

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2009133669A1 (ja) * 2008-04-28 2009-11-05 パナソニック株式会社 仮想計算機制御装置、仮想計算機制御方法及び仮想計算機制御プログラム
WO2016006228A1 (ja) * 2014-07-11 2016-01-14 日本電気株式会社 仮想化システムおよび仮想化方法

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2000112858A (ja) 1998-10-06 2000-04-21 Nec Corp データダウンロード方法および装置
JP2004021555A (ja) 2002-06-14 2004-01-22 Nippon Telegr & Teleph Corp <Ntt> ネットワーク型オークションシステムの運用方法、オークション管理サーバ、クライアントコンピュータ及び代替サーバ用プログラム
JP5553356B2 (ja) 2011-01-11 2014-07-16 独立行政法人情報通信研究機構 管理装置、無線装置、周波数および送信電力の決定方法

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2009133669A1 (ja) * 2008-04-28 2009-11-05 パナソニック株式会社 仮想計算機制御装置、仮想計算機制御方法及び仮想計算機制御プログラム
WO2016006228A1 (ja) * 2014-07-11 2016-01-14 日本電気株式会社 仮想化システムおよび仮想化方法

Also Published As

Publication number Publication date
JP7331374B2 (ja) 2023-08-23
JP2020135167A (ja) 2020-08-31
US20220138017A1 (en) 2022-05-05

Similar Documents

Publication Publication Date Title
US10445850B2 (en) Technologies for offloading network packet processing to a GPU
US11221880B2 (en) Adaptive computing resource allocation approach for virtual network functions
US9378032B2 (en) Information processing method, information processing apparatus, recording medium, and system
Xu et al. {vTurbo}: Accelerating Virtual Machine {I/O} Processing Using Designated {Turbo-Sliced} Core
CN109697122B (zh) 任务处理方法、设备及计算机存储介质
JP5687666B2 (ja) スケジューリング装置、システム、方法およびプログラム
Guan et al. Workload-aware credit scheduler for improving network I/O performance in virtualization environment
US10733022B2 (en) Method of managing dedicated processing resources, server system and computer program product
Hu et al. Towards efficient server architecture for virtualized network function deployment: Implications and implementations
Shojafar et al. Minimizing computing-plus-communication energy consumptions in virtualized networked data centers
Lin et al. {RingLeader}: efficiently Offloading {Intra-Server} Orchestration to {NICs}
Guan et al. Performance enhancement for network I/O virtualization with efficient interrupt coalescing and virtual receive-side scaling
WO2020166423A1 (ja) リソース管理装置およびリソース管理方法
Asyabi et al. Kani: a QoS-aware hypervisor-level scheduler for cloud computing environments
CN115378885B (zh) 超融合架构下的虚拟机业务网络带宽管理方法及装置
Aragiorgis et al. Coexisting scheduling policies boosting I/O virtual machines
JP2019159646A (ja) Ｖｍ性能保証システムおよびｖｍ性能保証方法
US12039375B2 (en) Resource management device and resource management method
Liu et al. Improving resource utilization of a cloud-based testing platform for android applications
Dehsangi et al. cCluster: a core clustering mechanism for workload-aware virtual machine scheduling
US11068294B2 (en) Balancing processing loads of virtual machines
Kontodimas et al. Analysis and evaluation of I/O hypervisor scheduling
JP5646560B2 (ja) 仮想ｏｓ制御装置、システム、方法およびプログラム
Lee et al. Autothrottle: satisfying network performance requirements for containers
KR102145183B1 (ko) 멀티코어 기반 네트워크 인터페이스 카드에서 가상머신 QoS 보장형 데이터 전송 장치 및 방법

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 20756646

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 20756646

Country of ref document: EP

Kind code of ref document: A1