JP2013041485A - Virtual computer system and resource allocation control method - Google Patents

Abstract

PROBLEM TO BE SOLVED: To achieve priority control over a plurality of guest OSs and efficiently utilize a CPU, in a virtual computer system.SOLUTION: A virtual computer system which implements a plurality of guest OSs and executes processing by performing time-sharing of processing time of a CPU to allocate it to the guest OSs comprises: priority identification means 8 for identifying priority of a received plurality of processing requests; load information storage means 7 for storing load information on a load required by the guest OSs when processing for the processing requests is executed; and allocation determination means 5 for determining processing time of the CPU which is to be allocated to a guest OS on the basis of the identification result by the priority identification means and the load information stored in the load information storage means.

Description

  The present invention relates to a virtual machine system in which a plurality of virtual machines operate, and a resource allocation control method for controlling usage allocation of resources of the virtual machine system, for example, a CPU (Central Processing Unit).

  Conventionally, a virtual computer system in which a plurality of virtual computers operate on a computer is known, but in recent years, the technology of a virtual computer system has been applied to a small computer such as a personal computer. In a typical virtual machine system implementation format, a control program called a hypervisor is installed on computer hardware, and the hardware such as CPU, memory, and device is managed and controlled by the hypervisor function. The virtual machine (virtual machine) environment is provided to the guest OS installed in the system. By constructing a virtual machine system using a hypervisor, it is possible to physically operate multiple OSes on a single computer, reducing power consumption from the viewpoint of system operating costs. There is also a merit from a point.

  A plurality of guest OSs are mounted on the hypervisor, and the physical CPU is used in a time-sharing manner among virtual machines corresponding to each guest OS by a scheduling function by the hypervisor. In a conventional virtual computer system, a method has been proposed in which the hypervisor uses information on the CPU usage rate presented from each guest OS in order to determine a schedule for CPU allocation to each guest OS (for example, patents). Reference 1).

  In Patent Document 1, in response to a processing request from outside the system, a guest OS that requests processing to another guest OS on the same hypervisor is called a client OS, and processing is performed in response to a request from the client OS. The guest OS is called a server OS. The server OS provides the client OS with information on the CPU usage rate, which is the rate at which the CPU is actually used out of the CPU time allocated to itself, and each client OS actually uses the CPU. The CPU allocation schedule is appropriately determined for each CPU based on the actual CPU usage.

JP 2010-218151 A

  In the conventional virtual machine system, the CPU allocation time for each guest OS installed on the hypervisor can be dynamically changed, and it is possible to cope with scheduling that focuses on the CPU usage time of each guest OS. However, it was not possible to deal with processing that was conscious of real-time characteristics.

  For example, the priority of the process actually using the CPU cannot be reflected in the CPU allocation time allocated by the hypervisor. Since a process with a high priority is executed first on the same guest OS, a large amount of CPU processing time is allocated to a process with a high priority. However, if low priority CPU processing and high priority processing are operating on different guest OSes, the CPU usage is evaluated to be the same regardless of the priority. The CPU allocation time for a guest OS in which a high priority process is operating and the guest OS in which a low priority process is operating are the same as the guest OS that is executing a high priority process. Processing time will be allocated.

  Because of these problems, in the conventional virtual machine system, priority over the guest OS cannot be considered, and as a result, priority control cannot be realized as the entire system, and processing that requires real-time performance is required. CPU time could not be allocated efficiently.

  The present invention has been made to solve the above-described problems, and it is an object of the present invention to realize priority control across a plurality of guest OSs and realize efficient use of a CPU.

  A virtual machine system according to the present invention is a virtual machine system in which a plurality of guest OSs are mounted, and processing is performed by allocating CPU processing time to a plurality of guest OSs. When receiving processing request receiving means, priority identifying means for identifying priorities of a plurality of processing requests received by the processing request receiving means, and processing for a plurality of processing requests, a plurality of guest OSs respectively Based on the load information storage means for storing the load information about the required load, the identification result by the priority identification means and the load information stored in the load information storage means, the CPU processing time allocated to the guest OS is determined. Allocation determining means.

  The resource allocation control method according to the present invention is applied to a virtual machine system in which a plurality of guest OSs are mounted on a computer, and processing is performed by time-sharing the CPU processing time of the computer and allocating to a plurality of guest OSs. A possible resource allocation control method, a process request receiving step for receiving a plurality of process requests, a priority identifying step for identifying priorities of a plurality of process requests received in the process request receiving step, and a process request receiving step Based on the load calculation step for calculating the load required by the plurality of guest OSs when executing the processing for the plurality of processing requests received in step, the identification result in the priority identification step, and the load calculation result in the load calculation step And an allocation determination step for determining a processing time of the CPU allocated to the guest OS. Obtain

  According to the present invention, it is possible to perform priority control across guest OSes, thereby realizing efficient use of the CPU.

1 is a block diagram illustrating a configuration of a virtual computer system illustrated in Embodiment 1. FIG. It is a figure which shows the structure of the request | requirement database shown in Embodiment 1. FIG. FIG. 3 is a diagram showing a configuration of a type table shown in the first embodiment. 3 is a flowchart illustrating an operation of assigning CPU processing time according to the first embodiment. It is a figure which shows the structural example of the request database shown in Embodiment 1. FIG. 3 is a diagram illustrating a configuration example of a type table illustrated in Embodiment 1. FIG. It is a figure which shows the structural example of the request database shown in Embodiment 1. FIG. 6 is a diagram illustrating a configuration example of a type table shown in Embodiment 2. FIG. It is a figure which shows the structure of the request | requirement database shown in Embodiment 3. FIG. FIG. 10 is a diagram showing a configuration of a type table shown in the third embodiment. It is a figure which shows the structural example of the request database shown in Embodiment 3. FIG. 10 is a diagram illustrating a configuration example of a type table illustrated in Embodiment 3. FIG. FIG. 10 is a diagram showing an update operation of a request database shown in the third embodiment. 10 is a diagram illustrating an example of updating the type table illustrated in Embodiment 3. FIG.

Embodiment 1 FIG.
A virtual machine system to which the present invention is applied will be described by taking a virtual machine system equipped with a hypervisor as an example. FIG. 1 is a configuration diagram of a virtual machine system according to Embodiment 1 of the present invention. In FIG. 1, a virtual computer system 1 shows the entire system of the virtual computer system according to the first embodiment, and is realized by using a computer such as a personal computer or a server computer. Although FIG. 1 shows a case where a virtual computer system is configured using one computer, it may be configured by a plurality of computers. Although not shown in FIG. 1, a user terminal or the like is connected to the outside via an input / output device and a network.

  The physical resource unit 2 is a physical component constituting the virtual computer system 1, and the physical resource 2 includes a CPU 11 and a main storage device, an input / output device, and the like not shown in FIG. The hypervisor 3 provides a virtual computer environment to a plurality of guest OSs 4 to realize a virtual machine. The hypervisor 3 includes a CPU allocation unit 10 that controls access to the physical resource unit 2 for each guest OS 4, and each guest OS has a function of accessing the physical resource 2 such as a main memory and an input / output device. have.

  There is only one CPU allocation determination unit 5 in the virtual machine system 1, and the virtual machine system 1 is mounted on the same guest OS as the reception application 8 having a function of receiving a processing request from the outside. The request database (DB) 6 is a database that manages a list of external processing requests received by the receiving application 8. The type table (TBL) 7 is a table for managing the processing load and priority for each type of request processing that may be received by the receiving application 8. Here, the processing load for each type refers to the processing load required by each guest OS when processing a processing request is executed. The reception application 8 and other individual applications (APL) 9 are applications that operate on each guest OS, and the reception application receives a processing request from a user terminal connected to the virtual machine system 1.

(Description of configuration 1)
FIG. 2 is a diagram showing a logical configuration of the request database 6. The request database 6 is a set of entries including information of a request ID 601 that is an identifier for uniquely managing a processing request received by the receiving application and information of a request processing type 602 that indicates the processing content of the received processing request. .

  FIG. 3 is a diagram showing a logical configuration of the type table 7. The type table 7 is a table for managing the load for each request processing type 701 indicating information for each request processing type and for each guest OS 4 installed in the virtual machine system 1. In the process shown in FIG. 3 where the requested process type 701 is FID # 1, the load 702 of the guest OS # 1 is W # 1-1, the load 703 of the guest OS # 2 is W # 2-1, and the guest OS # 3 The load 704 is defined by W # 3-1. Further, the priority 705 of the process whose request process type 701 is indicated by FID # 1 is defined by PRI # 1.

  Next, the operation will be described. First, the overall operation of the virtual machine system according to the first embodiment of the present invention will be described. The virtual machine system according to the first embodiment of the present invention receives processing requests from external devices / users, and resources used by each guest OS based on the load and priority of each processing request in the virtual machine system 1 (Here, the processing time of the CPU) is determined, and each guest OS performs processing using the CPU during the allocated processing time. When the processing is completed, the processing result is transmitted to an external device / user. Note that the destination to which the virtual machine system 1 transmits the processing result is not necessarily the requesting user terminal that has input the processing request.

  Next, the CPU processing time allocation operation used by each guest OS will be described with reference to FIG. When a processing request is input to the virtual machine system 1 from an external device / user, the processing request is transferred to the reception application 8 (step S1). The reception application 8 examines the received processing request information and determines the type of processing required. The request processing type shown is determined (step S2). If the request process type can be determined, the reception application 8 requests the application 9 necessary for realizing the request process. Thereafter, the reception application 8 assigns an identifier to the content of the processing request currently being processed, registers it in the request database 6, and updates the request database (step S3). After registration in the request database 6 is completed, the reception application 8 notifies the CPU allocation determination function 5 that the contents of the request database 6 are changed due to the registration of a new request (step S4). When the update of the request database 6 is notified, the CPU allocation determination function 5 allocates the CPU to each guest OS based on the contents of the request database 6 and the type table 7. Is calculated (step S6). If there is a processing request in the request DB, the process returns to step S1, and if the processing by the CPU is completed and all the processing requests are processed, the process ends (step S7).

  The CPU 11 can execute the requested processing by executing the application 9 on the content of the processing request based on the allocation schedule, and can transmit the processing result to an external apparatus / user. The operation that characterizes the present invention will be described in detail below.

  The registration operation (step S4) in the request database 6 will be described. When a processing request is input from an external user terminal, the reception application 8 receives the processing request. The reception application 8 assigns a request ID to the received processing request and registers it in the request database 6. Further, the type of the received processing request is determined, and the type is registered in the request database 6 in association with the request ID. A setting example of the request database 6 is shown in FIG. In the setting example shown in FIG. 5, four requests with request IDs 1, 2, 3, and 4 are registered, and the request types are A, A, D, and C, respectively.

  FIG. 6 shows a setting example of the type table 7. In FIG. 5, the types of processing requests A to E are registered. The load of each OS (# 1 to # 3) is stored for each type. For example, in the request processing type A, the load of each guest OS is (OS # 1, OS # 2, OS # 3) = (1, 0, 1). Further, a priority is stored for each request processing type, and the priority is (A, B, C, D, E) = (low, high, low, low, high).

A method for determining the CPU allocation schedule (step S6) will be described. First, as shown in FIG. 4, an allocation determination operation in the case where a high priority processing request (the highest priority processing request) is not stored in the request database 6 will be described.
When the update of the request database 6 is notified, the CPU allocation determination unit 10 confirms the registration contents of the request database 6. The request types of requests being processed in the virtual machine system 1 are three types A, C, and D. The CPU allocation determination unit 10 refers to the type table 7 for the three types of processing A, C, and D currently being processed in the virtual computer system 1, and calculates the priority corresponding to each type and the load on each guest OS. To do. In the setting example of FIG. 5, for the process with the request type A, the priority is low, and the load on each guest OS is (OS # 1, OS # 2, OS # 3) = (1, 0, 1). ing. Similarly, when the request type is C, the priority is low, (OS # 1, OS # 2, OS # 3) = (1, 1, 1), and when the request type is D, the priority is low, (OS # 1, OS # 2, OS # 3) = (1, 0, 2).

  From this result, it can be seen that the request types A, C, and D corresponding to the request currently being processed are all defined with low priority and have the same priority. If all processing requests have the same priority, the CPU allocation ratio of each OS is determined at a ratio corresponding to the load of each defined guest OS. Since the requests currently being processed are A, A, D, and C, the value of the processing load of each OS required for the processing is added (OS # 1, OS # 2, OS # 3) = A + A + D + C = (1,0,1) + (1,0,1) + (1,0,2) + (1,1,1) = (4,1,5), OS # 1: OS # 2: It is determined to perform CPU allocation at a ratio of OS # 3 = 4: 1: 5.

  The CPU allocation determination unit 5 that has determined the CPU allocation schedule corresponding to the request database 6 sets the result in the CPU allocation unit 10 installed in the hypervisor 3. The CPU allocation unit 10 controls the CPU allocation schedule of each guest OS 4 based on the set CPU allocation schedule.

  When the processing requested from the reception application 8 to the other application 9 is completed and a response is returned to the reception application 8, the reception application confirms the content of the response, and from the content registered in the request database 6. The registration information of the corresponding request ID 601 is deleted, and the CPU allocation determination function 5 is notified that the request database 6 has been changed. The CPU allocation determination function 5 determines the CPU allocation schedule based on the information of the current latest request database 6 and sets it in the CPU allocation unit 10 in the hypervisor 3. With this operation, the CPU allocation schedule to each guest OS is changed based on the request type of processing requested from outside the virtual machine system 1.

Next, the assignment determination operation (step S6) when a high-priority processing request (a processing request with the highest priority) is received will be described. That is, the operation when the request database 6 is in the setting state shown in FIG. 5 and the request processing types B and E are input from the outside will be described.
When the update of the request database 6 is notified and the CPU allocation determination function 5 determines the allocation schedule, A, B, C, D, and E are registered when the request processing type of the processing request registered from the request database 6 is searched. You can see that When information corresponding to the request types A, B, C, D, and E is retrieved from the type table 7 shown in FIG. 5, the priority of B and E is set as high, and the priority of A, C, and D is set as low. You can see that

  Since it can be seen that requests having different priorities 705 are registered in the request database 6, the CPU allocation determination function 5 determines a CPU allocation schedule based on the processing request having the highest priority 705. The priorities of the registered request processing types A, B, C, D, and E are classified into two types, “high” and “low”. Among these, the group with the highest priority is set with the priority “high”.

  From this result, the CPU allocation determination function 5 determines the CPU allocation schedule using the information of the request processing types B and E corresponding to the priority “high”. That is, in this case, the load on each OS is (OS # 1, OS # 2, OS # 3) = B + E = (1,1,0) + (1,0,2) = (2,1,2), The CPU allocation is determined at a ratio of OS # 1: OS # 2: OS # 3 = 2: 1: 2.

  The CPU 11 executes the requested processing by executing the application 9 for the content of the processing request based on the set allocation schedule, and transmits the processing result to an external device / user.

  With these operations, it is possible to take into account priorities across guest OSes, realize priority control for the entire system, and efficiently allocate CPU time for processing that requires real-time performance. become able to.

  Here, the case where the allocation schedule is determined based on the processing request with the highest priority is shown, but when there are three or more priorities (for example, high, medium, and low), 2 is assigned. The allocation schedule may be determined based on the processing requests with the above priorities (for example, high / medium). Further, in the present embodiment, the case where the processing time of the CPU is allocated when the processing request is received is shown, but the CPU's processing is periodically performed based on the contents of the request database regardless of whether or not the processing request is received. A configuration may be adopted in which processing time is allocated.

Embodiment 2. FIG.
In the first embodiment, the case where the CPU allocation determination unit 10 determines the CPU allocation schedule based on the processing request information with the highest priority has been described. In the second embodiment, the CPU allocation determination unit 10 corresponds to the priority ratio. A case where CPU allocation time is allocated will be described. The configuration of the virtual machine system according to the second embodiment is the same as that of the virtual machine system according to the first embodiment shown in FIG. FIG. 8 shows a setting example of the type table 7 relating to the present embodiment. In the type table 7 shown in FIG. 8, unlike the type table shown in the first embodiment, the priority is set by numerical values (1 to 3).

  Next, the operation will be described. The overall operation of the virtual machine system and the CPU allocation determination operation according to the second embodiment are the same as those shown in the first embodiment and are as shown in FIG. Here, determination of a CPU allocation schedule (step S6) that differs in operation from the virtual machine system shown in the first embodiment will be described.

  When the request database 6 is updated and set as shown in FIG. 7, the CPU allocation determination function 5 stores the request processing types A, B, C, D, and E registered in the request database 6 in the type table 7. Are searched, the priority of each request processing type is identified, and the addition to each guest OS is calculated. For the processing with the request type A, the priority is 1, and the load on each guest OS is (OS # 1, OS # 2, OS # 3) = (1, 0, 1). Similarly, when the request type is B, the priority is 2, (1, 1, 0), when the request type is C, the priority is 1, (1, 1, 1), and the request type is D. In this case, the priority is 1, (1, 0, 2), and when the request type is E, the priority is 2, (1, 0, 2). From these results, the CPU allocation time for each guest OS is determined by adding the weight to each guest OS according to the priority, that is, adding information obtained by multiplying the priority.

  Specifically, (OS # 1, OS # 2, OS # 3) = A + A + D + C + B + E = (1,1,0) + (1,1,0) + (1,0,2) + (1,1, 1) + 2 × (1,1,0) + 3 × (1,0,2) = (9,5,9), where OS # 1: OS # 2: OS # 3 = 9: 5: 9 Decide to allocate CPUs.

  The CPU 11 executes the requested processing by executing the application 9 for the content of the processing request based on the set allocation schedule, and transmits the processing result to an external device / user.

  Since the virtual machine system according to the second embodiment has the above-described configuration, it is possible to consider the priority across guest OSes, realize priority control for the entire system, and realize real-time. CPU time can be efficiently allocated to processing that requires high performance.

Embodiment 3 FIG.
In the first and second embodiments, the case where the CPU allocation schedule is determined based on the CPU load on each guest OS for each processing request type predetermined in the type table 7 is described. In the third embodiment, the processing request type is determined. The case where the type table 7 is corrected based on the actual response time and the CPU assignment is determined based on the corrected type table 7 will be described. The configuration of the computer system according to the third embodiment is the same as that shown in the first embodiment, as shown in FIG.

  FIG. 9 shows the configuration of the request database 6 of the virtual machine system according to the third embodiment. In FIG. 8, an item for storing a request execution time 603 corresponding to the request ID 601 is set in each entry. The request execution time 603 stores the time when the reception application 8 requests the other application 9 to make a request.

  FIG. 9 shows the configuration of the type table 7 of the virtual machine system according to the third embodiment. Information of response time lower limit 706 and response time upper limit 707 corresponding to request processing type 701 is set in each entry. Here, the response time lower limit 706 is a preset lower limit value of response time, and similarly, the response time upper limit 707 is a preset response time upper limit value. The response time here indicates the time required to process each processing request. Here, the receiving application 8 requests another application 9 for a request, and then the other application for which the request is requested. The time from 9 to receiving a response shall be said.

  Next, the operation will be described. The overall operation of the virtual machine system according to the third embodiment is the same as that shown in FIG. When the virtual machine system 1 receives a processing request from the outside (step S1), the receiving application 8 receives the processing request, requests another application 9 for the request (step S2), and updates the request database 6. At this time, in the third embodiment, time information at the time of request request corresponding to the request ID 601 is stored in the request execution time 603. Thereafter, the receiving application 8 notifies the CPU allocation determination function 5 that the request database 6 has been updated (step S5), and the CPU allocation determination function 5 recalculates the schedule of the CPU allocation time for each guest OS 4. Then, each guest OS executes processing based on the recalculated allocation time (step S6).

  When a response is received from another application 9, the corresponding processing request is deleted from the request database 6, and the CPU allocation determination function 5 calculates the response time based on the updated request database 5. The time taken to execute the processing request using the information of the request execution time 603 of the corresponding processing request registered in the database 5 and the information of the time of receiving the response from the application 9 that executed the requested processing (response Time) is calculated and compared with the values of the response time lower limit 706 and the response time upper limit 707 corresponding to the corresponding request processing type 701. When the execution time is smaller than the response time lower limit 706, or when the execution time is larger than the response time upper limit 707, the value of the processing load 702 to 704 of each guest OS of the target request processing type 701 To change.

  FIG. 11 shows a setting example of the request database 6 corresponding to the third embodiment. FIG. 12 shows a setting example of the type table 7 corresponding to the third embodiment. In FIG. 11, the virtual machine system 1 is currently processing one request whose request processing type 602 is A. The processing request of the request ID 601 is transferred from the reception application 8 to another application 9 at 01: 02: 03000. FIG. 13 shows an operation when the reception application 8 receives a response to the processing request.

  In this state, when the reception application 8 receives a response to the processing request in which the request ID 601 is set to 1 from another application, the entry of the corresponding request database 6 is stored in the temporary storage area 12 and the request completion time 1204. This information is added and saved, and the operation for deleting the entry corresponding to the corresponding request ID 601 in the request database 6 is shown. The CPU allocation determination function 5 recalculates the CPU allocation schedule based on the updated request database 6 and then updates the type table 7 based on the information in the temporary storage area 12.

  In the example of FIG. 13, in the measurement of the processing time in the reception application 8 for the processing request having the request ID 601 value of 1, 8 msec has elapsed when the value of the request execution time 1203 is subtracted from the request completion time 1204. . Here, looking at the processing time lower limit 706 and the processing time upper limit 707 when the request processing type 701 is A, since the current processing time is larger than 5 which is the value of the processing time upper limit 707, the request processing type A from the next time. 14, the load 702 to 704 of each guest OS corresponding to the request processing type A in the type table 7 is increased by 10%, for example, as shown in FIG. If the processing time is shorter than the processing time lower limit 706, the load 702 to 704 of each guest OS is reduced by 10%, for example.

  By optimizing the processing load used for allocation of CPU usage rate according to these operations according to the current system operating status, it does not allocate resources excessively for priority processing, Appropriate resource distribution can be realized.

DESCRIPTION OF SYMBOLS 1 Virtual computer system, 2 Physical resource part, 3 Hypervisor, 4 Guest OS, 5 CPU allocation determination part, 6 Request database, 7 Type table, 8 Reception application, 9 Application, 10 CPU allocation part, 11 CPU, 12 Temporary storage Area, 601 Request ID, 602 Request processing type, 603 Request execution time, 701 Request processing type, 702-704 Load of OS # 1 to 705, Priority, 706 Response time lower limit, 707 Response time upper limit, 1201 Request ID, 1202 Request processing type, 1203 Request execution time, 1204 Request completion time

Claims (6)

A virtual machine system in which a plurality of guest OSs are mounted and processing is performed by allocating CPU processing time to the plurality of guest OSs,
Processing request receiving means for receiving a plurality of processing requests;
Priority identifying means for identifying priorities of a plurality of processing requests received by the processing request receiving means;
Load information storage means for storing load information on loads required by each of the plurality of guest OSes when executing processing for the plurality of processing requests;
An allocation determination unit that determines a processing time of the CPU to be allocated to the guest OS based on the identification result by the priority identification unit and the load information stored in the load information storage unit;
A virtual computer system comprising: The allocation determining means determines the CPU processing time allocated to the guest OS based on the load calculation result of the processing request with the highest priority;
The virtual computer system according to claim 1. The priority identifying means classifies the plurality of processing requests into a plurality of groups based on the priority,
The allocation determining means determines a processing time of the CPU allocated to the guest OS based on a load calculation result of a group having the highest priority set among the plurality of groups;
The virtual computer system according to claim 1. The allocation determining means determines the processing time of the CPU allocated to the guest OS based on the load information weighted according to the priority identified by the priority identifying means;
The virtual machine system according to any one of claims 1 to 3, wherein Response time measuring means for measuring the time required for the CPU to execute the processing of the processing request,
The load information storage means updates the load information for the corresponding processing request when the response time measured by the response time measurement means is outside a predetermined range;
The virtual machine system according to any one of claims 1 to 4, wherein A resource allocation control method applicable to a virtual computer system in which a plurality of guest OSs are mounted on a computer, and processing is performed by time-sharing CPU processing times of the computers and allocating them to the plurality of guest OSes,
A process request receiving step for receiving a plurality of process requests;
A priority identifying step for identifying priorities of a plurality of processing requests received in the processing request receiving step;
A load calculating step of calculating a load required by the plurality of guest OSes when executing processing for a plurality of processing requests received in the processing request receiving step;
An allocation determination step for determining a processing time of the CPU to be allocated to the guest OS based on the identification result in the priority identification step and the load calculation result in the load calculation step;
A resource allocation control method comprising:

Images