JP4875525B2 - Virtual computer system and program - Google Patents

Description

  The present invention relates to a virtual computer system, and relates to a technology for automatically dynamically changing the allocation of computer resources to each LPAR according to a small amount of knowledge about the workload processed on the OS on each LPAR and the load on each OS. .

  The virtual computer system divides a physical computer into a plurality of logical partitions (LPARs) by using a hypervisor, allocates computer resources (CPU, main memory, I / O) to each LPAR, and each of them on each LPAR. The OS is operated.

  In access to a computer system using the recent Web (abbreviation of World Wide Web), it is generally difficult to predict a load, and sudden access concentrates and a load peak often appears. Further, it is known that the load is generally low during normal times other than the peak.

  Instead of allocating a lot of computer resources to the LPAR from the beginning due to the load peaks that come from time to time, allocate a small amount of resources during normal times, and increase the resources to be allocated in response to load peaks. Thus (this is called load adaptive control), it is possible to reduce useless computer resources or increase the number of LPARs that can be supported.

  In order to realize this, first, it is necessary to dynamically change the allocation of computer resources to each LPAR. The reference document “HITAC Processor Resource Partition Management Mechanism (PRMF) (Hitachi, Ltd. Manual 8080-2-148-40)” has a description of dynamically changing the allocation of computer resources to each LPAR. According to this, when changing the allocation of computer resources to each LPAR, an operator (administrator) operates to issue a resource allocation change command, and the hypervisor dynamically allocates computer resources to each LPAR according to this command. change.

  Such an assignment change based on an operator operation cannot be dealt with when an assignment change is required quickly, such as in an emergency such as a system down or a sudden load peak.

On the other hand, Japanese Patent Laid-Open No. 9-26889 discloses a virtual machine system that automatically changes the CPU allocation amount in accordance with changes in external conditions. According to the present invention, the allocation of computer resources to each LPAR can be automatically changed without operator intervention in accordance with an emergency situation or operation schedule. Further, by comparing the CPU allocation amount definition value with the actual processor usage time, the processor allocation rate definition value can be changed according to the excess or shortage of the processor usage time.
JP 9-26889 A

  However, in the above-described conventional invention, the allocation is performed according to the excess or deficiency of the processor usage time. However, it is difficult to know the load of the computer system from the CPU usage time. The allocation rate for each LPAR could not be changed appropriately.

  Even if the load value of each LPAR can be known correctly, it is difficult to always correctly calculate an appropriate allocation rate of computer resources for each LPAR from only the load, and in particular, on the OS on each LPAR. This is because the appropriate allocation rate of computer resources to each LPAR is considered to be different if the workload characteristics (load at normal time, load at peak time, peak width, etc.) executed in (1) are different.

  By combining a correct load value and a small amount of knowledge about the workload, it is considered that a system can be provided that automatically and appropriately allocates computer resources to each LPAR.

  Therefore, an object of the present invention is to adapt to the load of the OS running on each LPAR, and by giving a small amount of knowledge about the workload (workload characteristics) as a system control parameter by the administrator. It is an object of the present invention to provide a virtual computer system and program for automatically and appropriately assigning computer resource allocation amounts to LPARs.

The present invention is a virtual computer system that divides a computer resource of a computer system including a plurality of computers into a plurality of logical partitions, and allows each individual user to use each of the logical partitions as an independent logical computer. For the partition, any one of the CPU usage rate, the memory usage rate, and the I / O device usage rate is set as the type of load related to the control operation of the computer resources including the CPU, the memory, and the I / O device, and the computer A user interface that accepts resource allocation rate range settings;
As a load applied to each logical partition, a load measuring means for measuring the type of load set from the user interface, and a computer assigned to each logical partition based on the load applied to each logical partition measured by the load measuring means Adaptive control means for calculating a resource allocation rate and determining a computer resource allocation rate to be allocated to each logical partition based on a range of the computer resource allocation rate set from the user interface; Has a display function for displaying the time transition of the measurement result of the load applied to each logical partition received from the load measuring means and the time transition of the allocation rate of the computer resources to each logical partition determined by the adaptive control means. Have.

Accordingly, the present invention includes a load of each computer, from the setting information based on knowledge of the workload running on each computer, dynamically and optimally allocating computer resources to each computer, easy to manage customers possible to provide a calculated system performance Ru can ensure tailored to deal with the result, or, it is possible to provide a program that optimally allocate resources in such calculations system.

Hereinafter, an embodiment of the present invention will be described with reference to the accompanying drawings.
{1. Physical computer}
FIG. 1 shows the configuration of a physical computer 130 that operates the virtual computer system of the present invention. 100 to 10n indicate CPU0 to CPUn, and 120 to 12k indicate I / O0 to I / Ok. Reference numeral 111 denotes a main memory, and reference numeral 110 denotes a memory controller that couples a CPU (100 to 10n) and an I / O (120 to 12k) with the main memory 111.

  Note that one CPU or two or more CPUs may be used. When there are two or more CPUs, each CPU (110 to 10n) is a tightly coupled multiprocessor sharing the main memory 111.

Reference numeral 140 denotes a console of this physical computer, which is connected to the I / O 0 (120).
{2. Virtual computer system}
FIG. 2 shows a hierarchical diagram of the virtual machine system constituting the present invention.

  The hypervisor 200 is operated on the physical computer 130. The hypervisor divides the physical computer 130 into two or more logical partitions (LPARs) LPAR0 (210) to LPARm (21m). OS0 (220) to OSm ((22m) are operated on each of LPAR0 to LPARm, and application 0 (230) to application m (23m) are operated on each OS.

The hypervisor allocates the CPU (100 to 10n), the main memory 111, and the I / O (120 to 12k) (referred to as computer resources) of the physical computer 130 to each LPAR (210 to 21m).
{3. Dedicated allocation and shared allocation}
There are two methods for the hypervisor to allocate computer resources to each LPAR: dedicated allocation and shared allocation.

  Dedicated allocation is a method in which a specific computer resource is exclusively allocated to a specific LPAR. Of the computer resources, the main memory (111) and the I / O (120 to 12k) are shared.

  Note that the CPU (100 to 10n) can be assigned exclusively. In the case of CPU dedicated allocation, the number of CPUs dedicated to a certain LPAR is referred to as the CPU allocation for that LPAR.

  On the other hand, in the shared allocation, computer resources are allocated to each LPAR little by little by time division. This shared allocation is performed only for the CPU. The ratio of the time for which a CPU is allocated to a certain LPAR to the time for which a CPU is allocated to all LPARs is referred to as a CPU allocation rate (expressed in%. The value is between 0 and 100).

  Thus, while dedicated allocation is in units of quantities, shared allocation is in units of rates. However, in the dedicated allocation, if the ratio of the number of CPUs dedicated to a certain LPAR to the total number of CPUs k + 1 is the CPU allocation ratio (expressed in%. The value is between 0 and 100), both the dedicated allocation and the shared allocation are the same. The allocation can be instructed in units of rates.

  For example, when a physical computer having two CPUs (CPU0 and CPU1) is divided into two LPARs (LPAR0 and 1) and the CPU allocation rate for LPAR0 and LPAR1 is 50% respectively, One CPU is assigned to each LPAR, and the time division means that two CPUs are alternately assigned to LPAR0 and LPAR1 for the same time (time slice), and can be applied to either case.

  However, in space division, the allocation rate is standardized by the number of CPUs (for example, the allocation rate in the case of 2 CPUs is 0%, 50%, or 100%), but there is no such limitation in time division. The allocation rate can be freely specified in the range of 0 to 100%.

  Therefore, in the following description, time division with no constraint on the allocation rate is considered as an allocation method, but the case of space division can also be applied by providing a constraint on the allocation rate.

In the following description, it is assumed that only the CPU (100 to 10n) is the computer resource that is dynamically allocated to each LPAR. The dynamic allocation to the main memory 111 and the I / O devices (120 to 12k) is the same as that of the CPU.
{4. Dynamic allocation change of computer resources}
The hypervisor 200 allocates computer resources to each LPAR according to a computer resource allocation rate for each LPAR (210 to 21m) set in advance before system operation.

  When the administrator (operator) changes the allocation rate from the physical computer console 140, the hypervisor 200 changes the allocation rate of the computer resources for each LPAR (210 to 21m).

  Alternatively, according to the schedule set in the hypervisor, the allocation rate is changed when the set time comes.

  In addition to these changing methods, in the present invention, a resource allocation change command is issued from the application operating on the OS (220-22m) on each LPAR (210-21m) to the hypervisor, The received hypervisor immediately responds to the request and provides a function for changing the allocation.

This function can be easily realized by mounting a mechanism for hooking the hypervisor code from an application on the OS.
{5. Constitution}
FIG. 3 shows the configuration of functional modules of a virtual machine system to which the present invention is applied.

The virtual computer system of the present invention includes a load module 0 (400) to a load measurement unit m (40m), an adaptive control unit 300, and a user interface in the functional modules of the virtual computer shown in part of FIG. 1000 is added.
{5.1 Load measurement unit}
The load measurement unit 0 (400) to the load measurement unit m (40m) are applications that operate on OS0 (220) to OSm (22m) that operate on LPAR0 (200) to LPARm (21m). 220) to OSm (22m) are measured.

  The load measurement unit 0 (400) to the load measurement unit m (40m) calls the load measurement library of OS0 (220) to OSm (22m), and uses the CPU usage rate, memory usage rate, disk usage rate (busy rate), and network usage. The load such as the rate (busy rate) is acquired (530 to 53 m).

These load values are in units of%, and the range is 0-100. The load measuring unit 0 (400) to the load measuring unit m (40 m) receive setting information of the type of load to be measured and the control interval from the user interface 1000 described later (540 to 54 m), and load based on the setting information Measure. Loads L0 to Lm of OS0 to OSm measured by the load measuring unit 0 to the load measuring unit m are sent to the adaptive control unit 300 (520 to 52m).
{5.2 Adaptive control unit}
The adaptive control unit 300 is installed in any of OS0 (220) to OSm (22m) as an application on the OS. The adaptive control unit 300 receives loads L0 to Lm of OS0 (220) to OSm (22m) from load measurement units 0 (400) to m (40 m) at 520 to 52 m, and LPAR0 (210) to LPARm. The allocation rate of the computer resource for (21m) is obtained, and if the allocation rate is different from the previous allocation rate, a resource allocation change instruction 502 is issued to the hypervisor 200.

  The exchange between each load measurement part (400-40m) and the adaptive control part 300 uses well-known techniques, such as socket communication. Alternatively, as well known, an inter-LPAR communication technology in which OS0 (220) to OSm (22m) on each LPAR0 (210) to LPARm (21m) communicate with each other via the hypervisor 200 may be used.

  The adaptive control unit 300 receives various setting information relating to a computer resource allocation rate determination method from the user interface 1000 described later (507), and the CPU for each LPAR (210 to 21m) from the measured loads L0 to Lm according to the setting information. Allocation rates S0 to Sm are obtained. Note that the total S0 + S1 +... + Sm of the CPU allocation rates S0 to Sm for each LPAR0 to LPARm is 100%.

The hypervisor that has received the resource allocation change instruction 502 from the adaptive control unit 300 changes the allocation rate of computer resources for LPAR0 (210) to LPARm (21m) to S0 to Sm, respectively (510 to 51m).
{5.3 User interface}
The user interface 1000 includes an interface function for an administrator or user to instruct various settings related to load measurement of the virtual machine system of the present invention and determination of the CPU allocation rate, load of each OS (220 to 22 m), It has an interface function for displaying the allocation rate of the CPU allocated to the LPAR (210 to 21m) to the administrator and the user.

  The setting information is input through the user interface 1000, and passed to each load measuring unit (400 to 40m) and the adaptive control unit 300 (540 to 54m, 507). Also, the load and allocation rate information 508 is transferred from the adaptive control unit 300 to the user interface 1000 and displayed.

The user interface 1000 is mounted on any of OS0 (220) to OSm (22m). An input screen and an output screen (described later) of the user interface are displayed on the screen of the OS equipped with the user interface 1000. The exchange between the user interface 1000 and the load measurement unit (400 to 40 m) or the adaptive control unit 300 may be performed using the above-described socket communication or inter-LPAR communication technology.
{5.4 Input User Interface}
FIG. 4 shows a screen image of the input user interface 1001 for specifying various settings among the functions of the user interface 1000 of FIG.

  A first input item (adaptive control valid setting) 1600 is a setting for whether to perform load adaptive control (adaptive control On) or not. 1601 and 1602 are alternative radio buttons. If load adaptive control is to be performed, 1601 is selected. If not, 1602 is selected.

  The second input item 1500 is a control interval setting. A value for the control interval is entered in the input field 1501. The unit is seconds, but may be milliseconds or minutes. The control interval input in the input field 1501 is used as a load measurement interval in the load measurement unit (400 to 40 m) and an allocation rate determination interval in the adaptive control unit 300.

  A third input item (measurement load setting) 1400 indicates the type of load of the OS (220 to 22 m) to be measured by the load measurement unit (400 to 40 m). Reference numerals 1401 to 1404 are radio buttons of four choices, and the selected one is a measurement target. Reference numeral 1401 denotes the CPU usage rate, and the CPU usage rate is measured in the initial setting. Check boxes 1402, 1403, and 1404 indicate a memory usage rate, a disk usage rate, and a network usage rate, respectively, and a “L” mark is displayed in the selected check box.

  A fourth input item (load machining setting) 1300 indicates a setting of what kind of machining is performed on the loads L0 to Lm measured by the load measuring unit (400 to 40 m). Reference numerals 1301, 1302, and 1303 are three-choice radio buttons. When 1301 is selected, no processing is performed on the loads L0 to Lm. When 1302 is selected, a moving average is applied to the loads L0 to Lm. The number of moving average samples is designated as 1304. The input field 1304 is valid only when the radio button 1302 is selected. When the radio button 1303 is selected, normalization is applied to the loads L0 to Lm. The standardization rank is designated in the input field 1305. The input field 1305 is valid only when the radio button 1303 is selected.

  Hereinafter, machining loads obtained by machining the loads L0 to Lm are represented as LA0 to LAm. When the radio button 1301 is selected and the load is not processed, the processing load is set to the same value as the measured load (LA0 = L0,..., LAm = Lm). The moving average and normalization will be described later (load processing).

  A fifth input item (allocation rate calculation setting) 1200 indicates a setting of an allocation rate calculation method for obtaining a CPU allocation rate for each LPAR (210 to 21m) from the values of the processing loads LA0 to LAm. 1201 and 1202 are alternative radio buttons. When the radio button 1201 is selected, the proportional method is used as the allocation rate calculation method.

  When the radio button 1202 is selected, the threshold method is used as the allocation rate calculation method. The high load determination threshold when using the threshold method is specified in the input field 1203, and the low load determination threshold is specified in the input field 1204. These input fields 1203 and 1204 are valid only when the threshold method is selected as the allocation rate calculation method.

  The CPU allocation rate (temporary CPU allocation rate) for each LPAR (210 to 21m) obtained by the allocation rate calculation is represented as SN0 to SNm. The proportional method and the threshold method will be described later (allocation rate calculation processing).

  A sixth input item (allocation rate range setting) 1100 indicates setting of a CPU allocation rate range (upper limit and lower limit or maximum value and minimum value) for each LPAR (210 to 21m). An upper limit (1110 to 111 m) and a lower limit (1120 to 112 m) of the allocation rate are designated for each LPAR. Both the upper limit and the lower limit take values from 0 to 100. The temporary CPU allocation rate (SN0 to SNm) for each LPAR (210 to 21m) obtained by the allocation rate calculation is corrected so as not to exceed the upper limit (1110 to 111m) value and not to fall below the lower limit value (1120 to 112m). The

  The CPU allocation ratios S0 to Sm are obtained by correcting the temporary CPU allocation ratio. By setting the upper and lower limits, it is possible to control the minimum guarantee of the allocation rate and the limitation of the maximum value of the allocation rate. This value is mainly determined by contracts with customers using each LPAR.

  Allocation rate correction processing based on the set allocation rate range will be described later in (allocation rate correction processing).

  Reference numeral 1700 denotes a button for actually enabling the setting designated by 1100 to 1600. For example, to perform load adaptive control with the first input item 1600 (adaptive control On), first, 1601 is selected, and then 1700 is pressed to validate the setting.

  The settings specified for the input items 1300, 1400, and 1500 are passed to the load measurement unit (400 to 40 m). All settings designated as 1100 to 1600 are also passed to the adaptive control unit 300. The load measuring unit (400 to 40 m) and the adaptive control unit 300 perform processing according to these various settings.

The administrator sets various items of the input items 1100 to 1600 in consideration of the nature of the workload operating on each OS (220 to 22m).
{5.5 output user interface}
Among the functions of the user interface 1000, FIG. 5 shows a screen image of the output user interface 1002 that displays the load and CPU allocation rate of each LPAR (210 to 21m).

  A display column 1800 to 180m shows a load time series for each LPAR (210 to 21m). The load may be a load L0 to Lm measured by each load measuring unit (400 to 40 m), or may be a processing load LA0 to LAm obtained by processing the loads L0 to Lm. Both of them may be displayed simultaneously. The user may be able to specify which load is displayed.

  A display column 1810 indicates a time series of CPU allocation rates for each LPAR (210 to 21 m). The total CPU allocation rate of all LPARs (210 to 21 m) is 100%. The CPU allocation rate for LPARi at a certain time is represented by the length in the vertical direction of the portion corresponding to LPARi in the 1810 graph.

  The display column 1820 displays the time when the allocation change occurred and the reason for the allocation change one by one.

  The output user interface 1002 acquires the load and allocation rate information 508 from the adaptive control unit 300 and displays it as shown in FIG.

The administrator who manages the virtual machine of the present invention looks at the output interface 1002 to see how the load of each LPAR (210 to 21m) has changed, whether adaptive control is operating properly, and the like. Can be obtained. The administrator can operate the virtual machine more efficiently by feeding back this information to the setting of the load adaptive control.
{5.6 Adaptive control processing}
Hereinafter, adaptive control processing in the virtual machine system of the present invention will be described with reference to the flowcharts of FIGS.

  FIG. 6 shows an outline of the load adaptive control process. In the load adaptive control process, first, the setting designated by the input interface 1001 in FIG. The setting is read by the load measuring unit (400 to 40 m) and the adaptive control unit 300.

  Next, in 2002, the load is measured. Load measurement is performed by a load measurement unit (400 to 40 m).

  Next, in 2003, the setting for whether to perform load adaptive control (1600) designated by the input user interface is checked. If the setting is to perform load adaptive control, load adaptive control is performed in 2004 or later, and not so. If so, the process ends.

  In 2004, CPU allocation rates S0 to Sm for each LPAR (210 to 21m) are determined. If one or more of the determined allocation rates are different from the previous allocation rates SO0 to SOm in 2005, the CPU is notified to the hypervisor 200 in 2006. The resource allocation change command is issued so as to change the allocation rate of the resource, the allocation is changed, and the process is terminated. If the allocation rate is exactly the same as the previous allocation rate, the process ends without issuing a resource allocation change command. Processing up to the allocation change instruction in 2003 to 2006 is performed by the adaptive control unit 300.

The virtual computer system of the present invention repeatedly performs a series of processes shown in FIG. 6 at control interval intervals. The control interval is a value specified in 1501 of the input interface 1001.
{5.7 Load measurement processing}
Details of the load measurement process 2002 in the adaptive control process of FIG. 6 are shown in FIG. The load measurement process is performed for each load measurement unit (400 to 40 m), and the loads L0 to Lm of each OS (220 to 22 m) are measured according to the type of load specified by the measurement load type 1400 of the input user interface 1001.

  That is, in LPARi, if the measured load type is the CPU usage rate in 2007, the CPU usage rate is measured in 2008, and the obtained value is set as the load Li.

  Otherwise, if the measured load type is the memory usage rate in 2009, the memory usage rate is measured in 2010, and the obtained value is set as the load Li.

  Otherwise, if the measured load type is the disk usage rate in 2011, the disk usage rate is measured in 2012, and the obtained value is set as the load Li.

Otherwise, if the measured load type is the network usage rate in 2013, the network usage rate is measured in 2014, and the obtained value is set as Li. Various usage rates are measured using a load measurement library provided in the OS (220 to 22 m). Here, the network usage rate is, for example, the number of connections, the number of requests, and the like, which are set as appropriate.
{5.8 Allocation Rate Determination Process}
FIG. 8 shows details of the allocation rate determination process 2004 in the adaptive control process of FIG. In the allocation rate determination processing, first, processing is performed on the loads L0 to Lm of the respective OSs (220 to 22m) measured by the load measurement processing in 2020 to obtain processing loads LA0 to LAm.

  In 2021, temporary CPU allocation rates SN0 to SNm for LPAR0 (210) to LPARm (21m) are obtained based on the processing loads LA0 to LAm (allocation rate calculation).

In 2022, the temporary CPU allocation ratio SN0 to SNm is set so that it falls within the upper limit (1110 to 111m) and lower limit (1120 to 112m) of the allocation ratio range for each LPAR specified by the input user interface 1001. SN0 to SNm are corrected to obtain CPU allocation rates S0 to Sm, and the process is terminated.
{5.9 Load processing}
The details of the load processing process 2020 in the allocation rate determination process of FIG. 8 are shown in FIG.

  First, when the setting (no conversion) that does not perform load machining is selected in 1300 of the input user interface 1001, a check is made in 2030. When no machining is performed, in 2031, the loads L0 to Lm are directly used as machining loads LA0 to LAm. (LA0 = L0,..., LAm = Lm), and the process ends.

  On the other hand, if processing is to be performed, it is determined in 2032 whether the type of processing is a moving average method, and if it is a moving average method, a moving average is applied to the load in 2033.

  The moving average stores the past values of the loads L0 to Lm measured by the load measuring unit (400 to 40 m). The number to be stored is S−1 obtained by subtracting 1 from the number of samples (denoted as S) specified in 1304 of the load processing setting 1300 of the input user interface 1001.

  Here, the Li load of OSi on the LPARi in the previous k (0 <k <S) is expressed as Li (k). Load Li (S-1), ..., Li (1) is stored for each OSi. The moving average obtains an average value of S load series Li (0), Li (1),..., Li (S-1) including the latest load Li for each OS. The obtained value is set as the machining load LAi. That is, LAi = (Li (0) + Li (1) +... + Li (S-1)) / S. This calculation is performed for all the OSs (LPAR) to obtain LA0 to LAm, and the process is terminated.

  On the other hand, if the normalization method is selected as the processing method, in 2034, the OSi load Li is standardized.

  In normalization, the value is adjusted to one of preset jump values. The normalization rank is a value (N) specified in 1305 (floor) of the load processing setting 1300 of the input user interface 1001.

  The machining load LAi obtained by standardizing the rank N with respect to the OSi load Li is obtained from LAi = (floor (Li × N / 100) +1) × 100 / N. This calculation is performed for all the OSs (LPAR), the processing loads LA0 to LAm are obtained, and the process is terminated.

  The load processing may be performed by the load measuring unit (400 to 40 m) for each OS (220 to 22 m), or may be performed collectively by the adaptive control unit 300. In the case of performing the load measurement unit, the values 520 to 52m sent from the load measurement unit (400 to 40 m) to the adaptive control unit 300 are the machining loads LA0 to LAm.

When load processing is performed by the adaptive control unit 300, values 520 to 52m sent from the load measurement unit (400 to 40 m) to the adaptive control unit 300 are loads L0 to Lm.
{5.10 Allocation rate calculation process}
FIG. 10 shows details of the allocation rate calculation process 2021 in the allocation rate determination process of FIG. First, in 2040, it is checked whether the proportional method is selected in the allocation rate calculation setting 1200 of the input interface 1001 or whether the threshold method is selected. If it is the proportional method, the processing of 2042 to 2045 is performed.

(5.10.1 Proportional method)
In 2042, the loop counter i is initialized to 0. In 2043, the processing of 2044 and 2045 is repeated until the value of the loop counter i becomes larger than m.

  In 2044, the temporary CPU allocation rate SNi is obtained based on the processing loads LA0 to LAm. In the calculation of 2044, ΣLAi indicates the sum of all machining loads LA0 to LAm.

SNi: = 100LAi / ΣLAi
Represents the ratio of the OSi processing load LAi to the sum of all processing load values in percent, and the CPU allocation ratio SNi to LPARi is a value proportional to the OSi processing load LAi.

In 2045, the loop counter i is incremented by 1, and the flow returns to 2043. A series of processing from 2043 to 2045 is repeated, and the temporary CPU allocation rates SN0 to SNm for LPAR0 (210) to LPARm (21m) are obtained, and the processing ends.
(5.10.2 Processing by threshold method)
On the other hand, if the allocation calculation method is the threshold method, 2041 is executed. Details of 2041 are as shown in FIG.

  First, in 2050, the loop counter i is initialized to 0, and in 2051, the processes in and after 2052 are repeated until the loop counter i becomes larger than m. In 2052, the processing load LAi of OSi is larger than the value of the high load determination threshold TH specified in the threshold method 1203 of the allocation rate calculation method setting 1200 of the input user interface 1001 (LAi> TH), and the OSi is in a high load state. If the flag Hi indicating that it is present is not set (Hi = 0), that is, if the load has increased so far, but the load has increased, the process proceeds to 2053 and the processing when the OSi enters a high load state is performed. Do.

  That is, in 2053, the temporary CPU allocation rate SNi is set to 100− (100−SPi) Loi / B. Here, SPi indicates the CPU allocation rate obtained by the previous load adaptive control for LPARi. Loi represents the sum of machining loads LAj of OSj other than OSi. B indicates an upper limit value for increasing the OS load on the LPAR in the low load state.

  The total load of OSs other than OSi is currently Loi, and at this time, the CPU allocation rate for LPARs other than LPARi is (100-SPi).

  Since the load of OSi is currently high, we want to reduce the CPU allocation rate for LPARs other than LPARi on which OSi operates, and increase the CPU allocation rate for LPARi.

  Therefore, the CPU allocation rate for LPARs other than LPARi is reduced so that the total load of OSs operating in LPARs other than LPARi is B, and the reduced amount is added to the CPU allocation rate for LPARi.

Expressing this calculation as a formula:
SNi: = 100- (100-SPi) Loi / B
It is expressed. At the same time as calculating SNi, a flag Hi indicating that OSi is in a high load state is set to 1. The loop counter j is set to 0.

  While 2053 is a calculation of the temporary CPU allocation ratio for the OSi in a high load state, 2054 to 2057 are calculations for reducing the CPU allocation ratio in the LPAR other than the OSi.

  That is, in 2054, the processing of 2055 to 2057 is repeated until j becomes larger than m. In 2055, since the temporary CPU allocation ratio SNi for LPARi has already been calculated in 2053, it is determined whether j is i. If j = i, the process 2056 is not performed.

In 2056, a temporary CPU allocation rate SNj for LPARs other than LPARi is calculated. The calculation method is obtained by dividing the value excluding the temporary CPU allocation rate for LPARi (subtracted from 100) by the number of LPARs other than LPARi. This can be expressed as an expression:
SNj: = (100-SPi) Loi / (B * m)
It becomes.

  In 2057, the loop counter j is incremented by 1, and the flow returns to 2054. After exiting the loop of 2054, all the temporary CPU allocation ratios SNj for the respective LPARs (210 to 21m) are obtained, and the process ends.

  On the other hand, if the value of the machining load LAi does not exceed the high load determination threshold TH in 2052 or if the Hi flag indicating the high load state is set (Hi = 1), the processing after 2058 is performed.

  In 2058, when the machining load LAi is smaller than the low load determination threshold TL and the flag Hi indicating that the OSi is in a high load state is set, that is, when the load has been reduced until now. The allocation rate is calculated so that every LPAR has an equal CPU allocation rate.

  That is, in 2059, the loop counter j is initialized to 0, the flag indicating that the OSi is in a high load state is cleared (Hi: = 0), and in 2060, the loop counter j is repeated until the loop counter j becomes m. In 2061, the temporary CPU allocation ratio SNj of LPARj is set to 100 / m, the loop counter is incremented by 1, and the process returns to 2060. When the condition determination of 2060 is true and the process exits the loop, the temporary CPU allocation rates SN0 to SNm for each LPAR (210 to 21m) are all 100 / m, and the process is terminated.

  If the OSI processing load LAi is larger than the low load determination threshold or the OSi is not in a high load state (Hi = 0) in 2058, the loop counter i is incremented by 1 in 2062, and the flow returns to 2051.

When the condition becomes true in 2051, there is no change in load that satisfies the conditions of 2052 and 2058 (becomes true) in any OS (220 to 22m). Therefore, the temporary CPU allocation rate for LPARj after 2063 The value of SNj is set to the value of CPU allocation rate SPj for LPARj obtained in the previous adaptive control (SNj: = SPj) for each LPAR (210-21m) (2063, 2064, 2065). The process is terminated.
{5.11 Allocation rate correction processing}
Details of the allocation rate correction processing 2022 shown in the allocation rate determination processing of FIG. 8 are shown in FIGS. 12, 13, and 14.

First, in 2071 to 2078 of FIG. 12, the value of the temporary CPU allocation rate SNi for LPARi is the upper limit MaxSi (111i) and lower limit of the allocation rate for LPARi (21i) specified by the allocation rate range setting 1100 of the input user interface 1001. It is checked whether or not it is between MinSi (112i) (MinSi ≦ SNi ≦ MaxSi).
MinSi ≦ SNi + di ≦ MaxSi
Find the minimum value of di that satisfies.

  That is, the loop counter i is initialized to 0 in 2071, and the processing of 2073 to 2078 is repeated until i becomes larger than m in 2072. 2073 checks whether the temporary CPU allocation rate SNi is larger than MaxSi, and if it is larger, 2074 obtains the value of di from MaxSi-SNi (di is a negative value).

  If SNi is equal to or less than MaxSi in 2073, it is checked in 2075 whether the temporary CPU allocation rate SNi is smaller than MinSi. If it is smaller, the value of di is obtained from MinSi-SNi in 2076 (di is a positive value).

  In 2075, if SNi is greater than or equal to MaxSi, since MinSi ≦ SNi ≦ MaxSi is satisfied, di is set to 0 in 2077. When the value of di is obtained by any of 2074, 2076, and 2077, the value of the loop counter i is incremented by 1 in 2078, and the flow returns to 2072.

  If the condition determination of 2072 is true, di is obtained for each LPAR (210 to 21m).

If the calculated value of di is the CPU allocation rate Si in addition to SNi (Si: = SNi + di), the CPU allocation rate Si for any LPAR is
MinSi ≦ Si ≦ MaxSi
Satisfied.

  However, since the temporary CPU allocation rate is increased or decreased by di, ΣSi may not be 100%.

  Therefore, after 2079, the value of Si is corrected so that ΣSi = 100 while Si satisfies the range of the upper limit MaxSi and the lower limit MinSi.

  In 2079, it is checked whether Σdi (a value obtained by summing di from i = 0 to i = m) is positive. If it is positive, the number of di in which the di value is 0 or less in 2080 is defined as xm. Steps 2082 and after in FIG. 13 are executed.

  If Σdi is 0 or less in 2079, the number of di such that the value of di is 0 or more in 2081 is set to xp, and the processing from 2101 onward in FIG. 14 is executed.

  In 2082 of FIG. 13, the loop counter j is initialized to 0, and 2084 to 2089 are repeatedly performed until j is larger than m or the value of Σdi becomes 0 in 2083.

  Since the total ΣSNi of the temporary CPU allocation ratios SNi obtained by the CPU allocation ratio calculation process is determined to be 100%, that Σdi is positive means that Σ (SNi + di)> 100%.

  Therefore, the CPU allocation rate for some LPARs must be corrected to a smaller value. The fact that di is a value larger than 0 means that the temporary CPU allocation rate SNj itself is smaller than MinSj, and therefore SNj + di is MinSj. Therefore, the CPU allocation rate for this LPAR cannot be reduced. I won't go.

  In other words, the target for correcting the CPU allocation rate to be smaller is for the case where di is 0 or less. Therefore, in 2084, the processing of 2085 to 2089 is performed only for the case where the value of di is 0 or less.

Now, how much the allocation rate is to be reduced should be such that the final total CPU allocation rate is 100%. Therefore, Σdj / xm obtained by equally dividing the amount Σdj whose allocation rate exceeds 100% by the number xm of targets whose allocation rate can be corrected is subtracted from the correction target. However, since SNj + di−Σdj / xm must not be smaller than MinSj, this is determined in 2085. If it does not get smaller, a new one at 2086
dj: = dj-Σdj / xm
And

On the other hand, when SNj + di−Σdj / xm is smaller than MinSj, in 2087, a new CPU allocation rate is set to MinSj.
dj: = MinSj-SNj
And When the value of dj is corrected, xm is decremented by 1 at 2088, the loop counter j is incremented by 1 at 2089, and the flow returns to 2083.

When the condition determination of 2083 is true and the loop is terminated, the corrected dj is obtained. Therefore, the final CPU allocation rate Si for LPARi in 2090 to 2092 is
Sk: = SNk + dk
The calculation is obtained and the processing is terminated. In 2092, the counter k is incremented by one.

  Next, in 2101 of FIG. 14, the loop counter j is initialized to 0, and 2103 to 2108 are repeatedly performed until j is greater than m in 2102 or the value of Σdi becomes 0.

  Since the total ΣSNi of the temporary CPU allocation ratios SNi calculated by the CPU allocation ratio calculation process is determined to be 100%, the fact that Σdi is negative means that Σ (SNi + di) <100%.

  Therefore, some CPU allocation ratios must be corrected to be larger values. If di is a value smaller than 0, the temporary CPU allocation rate SNj itself is larger than MaxSj, and therefore SNj + di is MaxSj. Therefore, the CPU allocation rate for this LPAR cannot be increased. .

  In other words, the target for correcting the CPU allocation rate to a large value is the case where di is 0 or more.

  Therefore, in 2103, the processing of 2104 to 2107 is performed only for the case where the value of di is 0 or more.

  Now, how much the allocation rate is increased should be such that the final total CPU allocation rate is 100%. Therefore, Σdj / xp obtained by equally dividing the amount Σdj whose allocation rate is less than 100% by the number xp of targets whose allocation rate can be corrected is subtracted from the correction target (since Σdj / xp is a negative value).

However, since SNj + di−Σdj / xp must not be larger than MaxSj, this is determined in 2104. If it does not increase, a new 2105
dj: = dj-Σdj / xp
And

On the other hand, if it is larger, in 2106, the CPU allocation rate is set to MaxSj.
dj: = MaxSj−SNj
And When the value of dj is corrected, xp is decremented by 1 in 2107, the loop counter j is incremented by 1 in 2108, and the process returns to 2102.

When the condition determination of 2102 is true and the loop is finished, the corrected dj is obtained. Therefore, the final CPU allocation rate Si for LPARi in 2090 to 2092 (FIG. 13) is as follows.
Si: = SNi + di
The calculation is obtained and the processing is terminated.
{6. Overall action}
Through the above processing, the input user is selected according to the workload characteristics (characteristics such as steady load, peak load, and peak width) of applications (including services and daemons) executed on the OS on each LPAR. By appropriately selecting the type of measurement load for each LPAR using the interface 1001 and setting an appropriate control interval 1500, it is possible to change the appropriate allocation rate for sudden increases in workload (occurrence of peaks) Thus, it is possible to realize automation of appropriate allocation of computer resources to each LPAR.

  For example, when a web server is running on the OS of LPARa and a database server is running on the OSb of LPARb, even if the CPU usage rate of each LPAR is the same, the load is different (work) Load characteristics) In the Web server, an increase in load accompanies an increase in the network usage rate, and in a database server, an increase in load has a characteristic that the disk usage rate (or memory usage rate for cache) increases.

  Therefore, the administrator only has to determine the type of measurement load according to the workload characteristics of the application running on the OSi of each LPARi using the input user interface 1001. In the above example, the LPARa running the Web server By selecting the network usage rate and selecting the disk usage rate in the LPARb in which the database server is operating, it becomes possible to appropriately change the dynamic allocation rate of computer resources according to the type and size of the load. It is.

  In particular, in a Web server or the like, it is very difficult to predict the time when a load peak appears, and therefore adaptive control is performed by appropriately selecting the type of load measurement according to the workload characteristics as in the present invention. This makes it possible to automatically and appropriately change the allocation rate of computer resources in accordance with the increase or decrease of the load.

  In addition, since the input user interface 1001 selects either non-conversion, moving average, or normalization for the processing of the measured load, tuning (optimization) according to the occurrence of the peak of each LPAR, etc. Can be performed.

  In other words, if no conversion is selected for load processing, the dynamic allocation rate change of computer resources can respond linearly to load fluctuations, and if moving average is selected, it will respond to minute load fluctuations. In this way, it is possible to reduce the overhead associated with changing the allocation rate by suppressing frequent changes in the allocation rate, and to perform a wide range of tuning (optimization) in combination with the control interval and the number of samples. Can be used to suppress the frequent change of the allocation rate in response to minute changes in the load, reducing the overhead associated with the change in the allocation rate, and it can vary widely depending on the combination of the control interval and the number of standardization layers Tuning can be performed.

  Furthermore, in the allocation conversion (allocation rate calculation) 1200, the proportional method and the threshold method can be selected. Therefore, in the case where it is necessary to respond linearly to the load fluctuation, the proportional method is applied to reduce the minute load fluctuation. On the other hand, if you want to suppress frequent changes in the allocation rate, the threshold method can be used to reduce the overhead associated with frequent allocation rate changes, and a wide range of tuning (optimization) according to the high and low load thresholds. It can be performed.

  In addition, since the output user interface 1002 displays the relationship between the load and time for each LPARi and the content of the allocation rate change in time series, how the allocation rate of computer resources can be determined against load fluctuations. The user (administrator) can be informed whether the change has been made, and the administrator examines various parameters to be set in the input user interface 1001 based on the history of the load and the allocation rate, and is optimal for each LPARi. Tuning can be performed.

  FIG. 15 shows a second embodiment, in which a part of the first embodiment is changed and an LPAR mounting the user interface 1000 is made independent.

  Hereinafter, only differences from the first embodiment will be described.

  FIG. 15 shows an LPAR (LPARx) for management purposes other than the LPAR0 (210) to LPARm (21m) shown in FIG. 3 of the first embodiment, and the OSx is operated on the LPAR0 (LPARx). 300 and a user interface 1000 are installed.

  The input screen and output screen of the user interface 1000 are displayed on the OSx screen. Also, no load measuring unit is mounted on OSx. Exchanges among the load measurement units (400 to 40 m), the adaptive control unit 300, and the user interface 1000 use socket communication or inter-LPAR communication technology. The rest is the same as in the first embodiment.

  In this example, since the adaptive control unit 300 and the user interface 1000 operate on the management LPARx (22x), the other LPAR0 to m do not require computer resources required for dynamically changing the LPAR allocation rate. Each of the OSs 0 to m can concentrate on executing the application except for the processing of the load measuring units 400 to 40m, and can improve the utilization efficiency of each LPAR.

  FIG. 16 shows a third embodiment, in which a part of the first embodiment is changed, and an adaptive control unit 300 and a user interface 1000 are provided inside the hypervisor 200.

  Hereinafter, only differences from the first embodiment will be described.

  FIG. 16 is a diagram in which the adaptive controller 300 and the user interface 1000 shown in FIG. 3 of the first embodiment are provided inside the hypervisor 200. The input screen and output screen of the user interface 1000 are displayed on the console 140 of the physical computer 130.

  The exchange between each load measuring unit (400 to 40 m), the adaptive control unit 300 and the user interface 1000 is performed via a shared memory used for inter-LPAR communication. Further, the exchange between the adaptive control unit 300 and the user interface 1000 may use the internal memory of the hypervisor 200. Other configurations are the same as those of the first embodiment.

  FIG. 17 shows the fourth embodiment, which is a partial modification of the user interface of the first embodiment.

  Hereinafter, only differences from the first embodiment will be described.

  An input user interface 1003 in FIG. 17 is obtained by adding a Save button 1701 and a Restore button to the input user interface shown in FIG. 4 of the first embodiment, and other configurations are the same as those in FIG. 4 of the first embodiment. It is the same.

  This input user interface 1003 is obtained by adding a Save button 1701 and a Restore button 1702 to the lower part of the display area.

  When the save button 1701 is pressed (clicked), various settings designated by the input items 1100 to 1600 are written to a preset setting save file on the disc. When the Restore button 1702 is pressed, the setting storage file storing the settings is read, and the input items 1100 to 1600 are restored to the settings at the time of saving.

  This eliminates the need for the administrator to input settings from the input user interface 1003 each time the virtual computer system of the present invention is activated, and the stored settings can be restored simply by calling the setting storage file.

  FIG. 18 shows a fifth embodiment, in which the output interface (output unit) of the user interface of the first embodiment is changed to a log recording unit 1004, and the other configuration is the first embodiment. It is the same. Hereinafter, only differences from the first embodiment will be described.

  The log recording unit 1004 in FIG. 18 is mounted on any of the OS0 (210) to OSm (22m) of the first embodiment.

  The log recording unit 1004 receives loads L0 to Lm or processing loads LA0 to LAm of each OS (220 to 22m) from the adaptive control unit 300, CPU allocation rates S0 to Sm for each LPAR (210 to 21m), and allocation changes. The reason for change at the time of being made is received at regular intervals, and they are written in the log file 1005 as time series.

  By referring to this log file 1005, the administrator can know how the computer resource allocation rate has been changed in response to load fluctuations, and the administrator can determine based on the history of this load and allocation rate. Thus, various parameters set by the input user interface 1001 can be examined, and optimal tuning can be performed for each LPARi.

  When this log recording unit 1004 is applied to the second embodiment, the log recording unit 1004 is mounted on a management LPAR (LPARx) on which the adaptive control unit 300 is mounted.

  Similarly, when applied to the third embodiment, a log recording unit 1004 is provided inside the hypervisor 200.

  FIG. 19 shows a sixth embodiment in which a contract user interface provided to a customer who uses each LPAR is added to the user interface 1000 of the first embodiment. This is the same as in the first embodiment.

  Contract user interface 0 (3000) to contract user interface m (300m) are provided corresponding to LPAR0 (210) to LPARm (21m), respectively.

  In the virtual machine of this embodiment, an LPAR is prepared for each customer who has a contract, and the customer accesses the LPAR assigned to the customer via the Internet (or network) and performs processing. Therefore, the contract user interface (3000 to 300 m) is displayed on the screen (display means) of the customer's computer with the contract.

  Contract user interface 0 (3000) is connected to user interface 1000 by input data 600 and output data 610. The contract user interface m (300m) is connected to the user interface 1000 by input data 60m and output data 61m.

  The contract user interface (3000 to 300m) executes a contract status update by the customer, a display of service status such as an allocation rate of the computer resources allocated to the customer by the virtual computer system of the present invention, and the like.

  The contract user interface (3000 to 300m) includes a contract input user interface 3100 shown in FIG. 20 and a contract confirmation user interface 3200 shown in FIG. Alternatively, the contract output user interface of FIG. 22 may be included.

  Next, the contract input user interface 3100 in FIG. 20 will be described.

  The contract input user interface in FIG. 20 is an interface for the contract customer to change the content of the contract. The contract contents here are input fields for an upper limit 3101 and a lower limit 3102 of the CPU allocation rate for the contracted LPAR.

  The customer designates the upper limit and the lower limit of the CPU allocation rate for the LPAR assigned to the customer as the upper limit 3101 and the lower limit 3102 of the contract input user interface 3100 while using knowledge about the workload of processing performed on the LPAR.

  Reference numeral 3103 denotes a button for validating (changing the contract) the upper and lower limits (allocation ratio range) of the allocation ratios input to 3101 and 3102 in FIG.

  When the change button 3103 is pressed (clicked), information on the upper limit and lower limit of the allocation rate specified in the input fields 3101 and 3102 is input to the input user interface 1001 of the user interface 1000 via the input data 600 of FIG. Sent.

  The input user interface 1001 confirms whether or not the designated allocation rate range is valid. If it is valid, the input user interface 1001 sets the upper limit (111i) and lower limit (112i) of the LPARi in the allocation rate range setting 1100 of the input user interface 1001. The upper and lower limit values sent are set, and the settings are validated in the same manner as when the update button 1700 shown in FIG. 4 is pressed.

  If the quota range is not valid (if another customer sets the lower limit value large and the value specified for the customer cannot be set to the lower limit, it is judged not valid) The upper and lower limits are not reflected in the allocation rate range setting 1100.

  Then, the input user interface 1001 displays the contract confirmation user interface 3200 of FIG. 21 on the customer's screen, and notifies the customer whether or not the previous contract change has been correctly accepted.

  Next, the contract confirmation user interface of FIG. 21 will be described.

  The contract confirmation user interface 3200 in FIG. 21 is a user interface that presents a confirmation to the customer whether or not the contract change request instructed by the customer through the contract input user interface 3100 has been correctly received. Reference numeral 3201 denotes a contract change acceptance status. The acceptance status 3201 displays Accepted when the contract change request is correctly accepted, and displays Invalid or the like when it is not correctly accepted.

  In order to be accepted correctly, the allocation ratio range sent from the contract input user interface 3100 to the input user interface 1001 needs to be valid.

  In the contract content 3202, when the contract change is correctly accepted, the changed contract content is displayed. When the contract change is not correctly accepted, the reason is displayed.

  Next, the contract output user interface of FIG. 22 will be described.

  The contract output user interface 3300 in FIG. 22 includes a time series (3301) of OS load or processing load operating on the LPAR corresponding to the customer, and a time series of allocation rate of computer resources allocated to the LPAR ( 3302), and a change reason 3303 when an assignment change occurs are displayed. Unlike the output user interface 1002 of FIG. 5 shown in the first embodiment, only the information related to the LPAR that the customer has contracted is displayed here, and other customers have contracted. The information of the LPAR that is being displayed is not displayed.

  As described above, customers who use each LPAR can check the load and allocation rate change for each LPAR to be used in chronological order through the contract user interface 3000 to 300m, and change the allocation rate within the scope of the contract. As a result, customers can always confirm the details of the contract and can change the allocation rate based on the change history of the load and the allocation rate, improving the service for LPAR users. Can be planned.

  The contract output user interface 3300 is a user interface that displays values on the screen (console 140), but this may be replaced by the log recording unit 1004 shown in FIG. At this time, the log recording unit 1004 is mounted on an access device (computer or the like) used when the customer accesses the virtual machine of the present invention via the Internet, and the log recording unit 1004 outputs a log file to the customer access device. You may make it do.

  FIG. 23 shows the seventh embodiment, in which the input of the contract input user interface 3100 of the sixth embodiment is changed, and the other configurations are the same as those of the sixth embodiment.

  In FIG. 23, the contract input user interface 3400 is more abstract than the contract input user interface 3100 of FIG. 20, and the operation for changing the LPAR user allocation rate is simplified. To do.

  That is, in order to select the service level from S, A, B, and C, 3401 to 3404 in the figure are four-way radio buttons, 3401 is the selection of level S, and 3402 is the level A. A selection 3403 indicates a selection of level B, and 3404 indicates a selection of level C.

  Level S indicates the most performance-oriented contract. Level C represents the most price-oriented contract. Level A is a performance-oriented, but price is not as high as level S, and level B is a price-oriented contract, but performance is more important than level C. Which level provides what service is based on a description such as a contract.

  In the figure, reference numeral 3403 denotes a contract change button. When this button is pressed, the selected service level is sent to the input user interface 1001. When the service level is sent, the input user interface 1001 refers to a predetermined chart (not shown) or the like to convert the service level into an upper limit and a lower limit of the computer resource allocation rate, and those values (If the service level contracted with another customer cannot be observed, it is determined that the service level instructed by the customer is not valid). If so, the allocation rate range setting of the input user interface 1001 is set. The upper limit and lower limit values obtained by referring to the chart are set in the upper limit (111i) and lower limit (112i) of the LPARi in 1100, and the settings are validated in the same manner as when the update button in 1700 is pressed. If not valid, the upper and lower limit values are not reflected in the allocation rate range setting 1100.

  The contract input user interface 3400 issues a contract content change instruction, and the contract confirmation user interface 3200 that the input user interface 1001 outputs to the customer screen is the same as in the sixth embodiment. The contract output user interface 3300 is the same as that in the sixth embodiment.

  The load measuring means has an output user interface that outputs the load measured by the load measuring means or the allocation rate of the computer resource for each logical partition determined by the adaptive control means, and the output user interface includes the output user interface measured by the load measuring means. The virtual computer system may be characterized in that the OS load on the LPAR and the allocation rate of the computer resource for each LPAR determined by the adaptive control means are displayed as a time series.

  And an output user interface for outputting the load measured by the load measuring means or the allocation rate of the computer resources for each logical partition determined by the adaptive control unit, and the adaptive control means determines the allocation rate of the computer resources for each LPAR. When changed, the output user interface may display a reason for the change, and may be a virtual machine system.

  In addition, the virtual computer system includes a hypervisor that divides a physical computer into a plurality of LPARs, causes an OS to operate on each LPAR, and controls allocation of physical computer resources to each LPAR. Based on the load measuring means for measuring the load and the load of the OS on each LPAR measured by the load measuring means, the allocation rate of the computer resource allocated to each LPAR is determined, and the allocation rate has been allocated so far If the allocation rate is different, the adaptive control means for instructing the hypervisor to change the resource allocation rate, the load measured by the load measuring means, and the allocation rate of the computer resource for each LPAR determined by the adaptive control means as a time series Log recording means for recording in a file (log file), the hypervisor following instructions from the adaptive control means The virtual computer system may be provided with means for dynamically changing the allocation rate of the computer resources for the LPAR, and the log recording unit may be configured such that the adaptive control unit determines the allocation rate of the computer resources for each LPAR. It is good also as a virtual machine system characterized by recording the changed history in a log file.

  In addition, a contract user interface for setting contract conditions for each customer is provided, and the OS load on the logical partition assigned to the customer and switching of the allocation rate and allocation rate of computer resources for the logical partition are provided in the contract user interface. A virtual computer system characterized by providing means for displaying the reasons in time series on the screen of the customer's computer may be used.

  Further, the user interface is provided with means for writing the specified setting to a setting file, and means for reading the setting file and restoring the setting saved in the setting file on the user interface. A virtual computer system may be used.

  The embodiment disclosed this time should be considered as illustrative in all points and not restrictive. The scope of the present invention is defined by the terms of the claims, rather than the description above, and is intended to include any modifications within the scope and meaning equivalent to the terms of the claims.

It is a figure which shows the structure of the physical computer which operates the virtual computer of this invention. Similarly, it is a conceptual diagram of a virtual machine. It is the schematic which shows the module structure of a virtual machine. It is a figure which shows the screen image of the input user interface for inputting a setting. It is a figure which shows the screen image of the output user interface which displays the load of each LPAR, the time series of CPU allocation rate, and an allocation change reason. It is a flowchart explaining the outline | summary of the process of the load adaptive control which changes the allocation of the computer resource with respect to each LPAR based on load. It is a flowchart which shows the flow of the load measurement process performed in a load measurement part. It is a flowchart which shows the flow of a process in which an adaptive control part determines CPU allocation rate from the load measured by the load measurement part. It is a flowchart which shows the flow of the process which processes to the load performed by the allocation rate determination process. It is a flowchart which shows the flow of the calculation process of the temporary CPU allocation rate performed by allocation rate determination processing. Similarly, it is a flowchart in the case of calculating a temporary CPU allocation rate by a threshold method. It is the flowchart which shows an example of an allocation rate correction process, and is the first half. Similarly, in the flowchart showing an example of the allocation rate correction process, it is an intermediate part thereof. Similarly, it is the latter half part in the flowchart which shows an example of an allocation rate correction process. It is the schematic which shows 2nd Embodiment and shows the module structure of a virtual machine. It is the schematic which shows 3rd Embodiment and shows the module structure of a virtual machine. It is a figure which shows 4th Embodiment and shows the screen image of an input user interface. FIG. 20 is a conceptual diagram illustrating a fifth embodiment and using an output interface as a log recording unit. It is the schematic which shows 6th Embodiment and shows the module structure of a virtual machine. Similarly, it is a figure which shows the screen image of a contract input user interface. Similarly, it is a figure which shows the screen image of a contract confirmation user interface. Similarly, it is a figure which shows the screen image of a contract output user interface. It is a figure which shows 7th Embodiment and shows the screen image of a contract input user interface.

Explanation of symbols

100, ... 10m CPU0, ... CPUm
110 Memory controller 111 Main memory 120, ..., 12m I / O0, ..., I / Om
130 physical computer 140 console 200 hypervisor 210, ..., 21m LPAR0, ..., LPARm
220, ..., 22m OS0, ..., OSm
300 Adaptive control unit 400, ..., 40m Load measurement unit 0, ..., load measurement unit m
1000 User interface 1001 Input user interface 1002 Output user interface 1004 Log recording unit 1100 Allocation rate range setting 1200 Allocation rate calculation setting 1300 Load processing setting 1400 Measurement load setting 1500 Control interval setting 1600 Adaptive control valid setting 1800, ..., 180m OS0 Load time series display column 1810: OSm load time series display column 1810 CPU allocation rate time series display column 1820 for each LPAR Allocation change reason display column 3000, ..., 300m Contract user interface 0, ... Contract user interface m

Claims (6)

A virtual computer system that divides computer resources of a computer system including a plurality of computers into a plurality of logical partitions, and allows each individual user to use each of the logical partitions as an independent logical computer,
For each logical partition, the CPU usage rate, the memory usage rate, and the I / O device usage rate are set as the types of loads related to the control operations of the computer resources including the CPU, memory, and I / O device. A user interface for accepting a range setting of the computer resource allocation rate;
As a load applied to each logical partition, a load measuring means for measuring the type of load set from the user interface,
Based on the load applied to each logical partition measured by the load measuring means, the computer resource allocation rate to be allocated to each logical partition is calculated, and based on the range of the computer resource allocation rate set from the user interface Adaptive control means for determining an allocation rate of computer resources allocated to each logical partition;
The user interface displays the time transition of the load measurement result applied to each logical partition received from the load measuring means and the time transition of the allocation rate of computer resources to each logical partition determined by the adaptive control means. A virtual computer system having a display function.   The virtual computer system according to claim 1, wherein an occurrence time of allocation change by the adaptive control means is displayed on the user interface. The adaptive control means includes
The computer resource amount allocated to the logical partition is changed when a measured value of the load of the logical partition measured by the load measuring means exceeds the threshold while holding a predetermined threshold. Virtual computer system. The user interface is
An individual user interface for providing each of the individual users;
In the individual user interface,
Claims characterized in that the user selects one service level from a plurality of service levels prepared in advance, converts the selected service level into a range of allocation rates of computer resources, and accepts the allocation rate as a range setting. The virtual machine system according to any one of claims 1 to 3. A computer system resource allocation management method that divides computer resources of a computer system including a plurality of computers into a plurality of logical partitions, and allows each individual user to use each of the logical partitions as an independent logical computer,
For each logical partition, the CPU usage rate, the memory usage rate, and the I / O device usage rate are set as the types of loads related to the control operations of the computer resources including the CPU, memory, and I / O device. , Accepting the range setting of the computer resource allocation rate with a user interface,
As the load on each logical partition, measure the type of load set from the user interface,
Based on the load applied to each logical partition measured by the load measuring means, the computer resource allocation rate to be allocated to each logical partition is calculated, and based on the range of the computer resource allocation rate set from the user interface Determine the allocation rate of computer resources to be allocated to each logical partition,
In the user interface, the time transition of the measurement result of the load applied to each logical partition received from the load measuring means and the time transition of the allocation rate of the computer resources to each logical partition determined by the adaptive control means are displayed side by side. A resource allocation management method for a computer system. A computer system resource allocation management program that divides a computer resource of a computer system including a plurality of computers into a plurality of logical partitions and causes a computer to execute a process for allowing each user to use each of the logical partitions as an independent logical computer. There,
For each logical partition, the CPU usage rate, the memory usage rate, and the I / O device usage rate are set as the types of loads related to the control operations of the computer resources including the CPU, memory, and I / O device. , A procedure for accepting a range setting of the computer resource allocation rate with a user interface;
As a load applied to each logical partition, a procedure for measuring the type of load set from the user interface;
Based on the load applied to each logical partition measured by the load measuring means, the computer resource allocation rate to be allocated to each logical partition is calculated, and based on the range of the computer resource allocation rate set from the user interface A procedure for determining the allocation rate of computer resources allocated to each logical partition;
In the user interface, the time transition of the measurement result of the load applied to each logical partition received from the load measuring means and the time transition of the allocation rate of the computer resources to each logical partition determined by the adaptive control means are displayed side by side. Procedure and
A resource allocation management program for a computer system that causes the computer to execute.

Images