« PreviousContinue »
RESOURCE ENTITLEMENT CONTROL
In many of today's data centers, servers are shared across multiple applications. However, current tools for allocating servers or server partitions to applications typically rely on offline capacity planning and performing a static partitioning of system resources to support these co-hosted applications. 10 For example, each application is allocated a maximum entitlement of system resources for execution. Many times, the amount of the maximum entitlement of system resources is either based on anticipated peak load or demand profiles computed from historic data. However, the entitlement of 15 system resources is static. For example, the entitlement of system resources is determined and used for a long period of time before being re-evaluated. This static entitlement typically results in low utilization of system resources and does not take full advantage of demands that vary over time due to 20 changes in operating conditions and user demands.
A resource entitlement control system includes a control- 25 ler, a model estimator, and a controller designer. The controller is operable to control an allocation of resources to a resource container. The model estimator is operable to calculate one or more model parameters based on performance metrics for the resource container, and the controller designer 30 is operable to calculate one or more controller parameters based on the model parameters. The controller is also operable to calculate a control variable for controlling the allocation of resources to the resource container based on the controller parameters and the performance metrics. 35
BRIEF DESCRIPTION OF THE DRAWINGS
The utility, objects, features and advantages of the invention will be readily appreciated and understood from consid- 40 eration of the following detailed description of the embodiments of this invention, when taken with the accompanying drawings, in which same numbered elements are identical and:
FIG. 1 is a system block diagram of a system according to 45 an embodiment;
FIG. 2 is a detailed functional block diagram of the system, according to an embodiment;
FIG. 3 is a block diagram of a resource entitlement control system according to an embodiment; 50
FIG. 4 is a flowchart of a method, according to an embodiment; and
FIG. 5 is a block diagram of a computer system, according to an embodiment.
For simplicity and illustrative purposes, the principles of the embodiments are described by referring mainly to examples thereof. In the following description, numerous 60 specific details are set forth in order to provide a thorough understanding of the embodiments. It will be apparent however, to one of ordinary skill in the art, that the embodiments may be practiced without limitation to these specific details. In other instances, well known methods and structures have 65 not been described in detail so as not to unnecessarily obscure the embodiments.
With reference first to FIG. 1, there is shown a system 100, according to an embodiment. The system 100 is operable to provide resources on demand. It will be apparent to one of ordinary skill in the art that one or more of the embodiments described herein may be practiced in different types of resource on demand environments, such as a data center where servers or portions of servers are allocated, a grid environment, and other types of resource-on-demand environments.
As shown, the system 100 includes a data center 101 connected to a network 108. One or more client devices 109a . . . m, such as a Personal Computer (PC), Personal Digital Assistant (PDA), wireless terminal, cellular telephone, or another type of well known client device is connected to the data center 101 via the network 108. The client device may also include servers which may be in different data centers. The network 108 may be a private network such as an intranet, and/or a public network such as, for example, the Internet.
The data center 101 includes servers 102a .../a resource allocator 106, a performance monitor 107, and SLA inputs 105. The servers 102a ■ ■ ■ f are partitioned into resource containers. Resource containers 103a . . . n are shown as an example of partitioning the server 102a. Each resource container 103a... n includes resources allocated for one or more applications. Examples of resources include one or more CPUs, memory, I/O bandwidth, disk space, and other known server resources.
In one embodiment, a resource container is represented as a process group including one or more applications. The resource container 103a, for example, is a process group including application 104a. A process group may include multiple applications such as shown for the resource container 1036. In this embodiment, the resources of the server 102a are partitioned for each process group. For example, the CPUs in the server 102a are divided among the resource containers 103a . . . n, whereby each resource container includes a process group.
In another embodiment, the servers 102a . . ./are partitioned into virtual machines. For example, each resource container includes a virtual machine wherein a set of resources are allocated to each virtual machine. In yet another embodiment, the servers 102a.. ./may include a plurality of server groups that are allocated to one or more applications.
Each of the servers 102a . . ./may also include a resource scheduler that allocates resources among the resource containers based on instructions from the resource allocator 106. In one embodiment, a resource scheduler is the scheduler in Hewlett-Packard's HP-UX Process Resource Manager (PRM). The PRM is a resource management tool that controls how resources are allocated.
A resource scheduler 110a is shown for the server 102a. Although not shown, one or more resource schedulers may be provided for each server or a single resource scheduler may be used for multiple servers.
The SLA inputs 105 includes one or more performance parameters that specify a level of service to be provided by a particular application. For example, SLA inputs 105 may include a parameter that specifies a maximum response time, a minimum communications bandwidth, or a minimum local memory size to be allocated to an application.
The resource allocator 106 determines the allocation of resources for a resource container. For example, the resource allocator 106 identifies performance parameters from the SLA inputs 105 and allocates the resources of the server 102a to each resource container 103a . . . n based on one or more
performance metrics measured by the performance monitor 107, and one or more performance parameters to be met for each application.
The performance monitor 107 provides performance monitoring information to the resource allocator 106 associ- 5 ated with the demand on the resources of the server 102a. For example, the performance monitor 107 monitors performance metrics for each resource container 103a . . . n and provides the metrics to the resource allocator 106. The metrics may be related to the performance parameters specified in l o the SLA inputs 105. Examples of the performance metrics include response time, throughput, CPU utilization, memory utilization, I/O bandwidth utilization, disk space utilization, and others. The resource allocator 106 adjusts the resources allocated for each resource container 103a... n in response to 15 the measured performance metrics and the corresponding SLA input(s) 105.
In one example, the resource container 103a includes application 104a for a server providing an e-commerce site that offers products for purchase online. An SLA input for the 20 server includes a maximum response time of 5 seconds. For example, user 1 using the client device 109a should not wait longer than 5 seconds to receive a requested web page from the e-commerce site. If the demand on the server is high, the resource allocator 106 may allocate resources from the other 25 resource containers 1036 or 103c to satisfy the performance parameter of a maximum response time of 5 seconds for the server.
FIG. 1 shows one resource allocator and one performance monitor by way of example. It will be apparent to one of 30 ordinary skill in the art that more than one resource allocator and performance monitor may be used.
With respect to FIG. 2, there is shown an embodiment of a resource container which may be included in a server of the servers 102a ■ ■ ■ f shown in FIG. 1. FIG. 2 illustrates the 35 resource container 103a including application 104a. In this embodiment, the resource container 103a is a process group including the application 104a. However, the resource container 103a may include other types of server partitions. Also, in FIGS. 2 and 3, a single resource container is shown by way 40 of example, and the systems shown in those figures may include multiple resource containers.
The resource scheduler 110a and a performance monitoring agent 165 may be respectively used to allocate resources for the resource container 103a and to determine the perfor- 45 mance monitoring information for the resource container 103a. The performance monitoring agent 165, for example, is part of the performance monitor 107 shown in FIG. 1. In one example, the performance monitoring agent 165 measures the performance metrics for the application performance in the 50 resource container 103a. Measuring or determining the performance metrics includes measuring the performance of the application 104a in the resource container 103a according to the performance metrics which may be specified in the SLA. The performance monitoring agent 165 sends the perfor- 55 mance monitoring information, including the measured metrics, to the resource allocator 106. The measured metrics may be used as performance feedback of the application 104a and/or feedback on resource usage in the resource container 103a. In another example, the performance monitor deter- 60 mines a statistical metric from one or more measured performance metrics, such as an average or a moving average for one or more measured attributes. The statistical metric is also a performance metric.
The resource allocator 106 determines the allocation of 65 resources for the resource container 103a using the performance monitoring information and the SLA inputs 105 for
the applications 104a. Determining the allocation of resources is described in further detail with respect to FIGS. 3 and 4.
The resource allocator 106 sends resource entitlement instructions to the resource scheduler 110a for adjusting the allocation of resources in the resource container 103a. For example, the server 102a may include one or more resource schedulers, one for each resource type, such as the resource scheduler 110a. The resource allocator 106 sends resource entitlement instructions to the resource scheduler 110a and the resource scheduler 110a allocates resources to the resource container 103a and possibly other resource containers in the server 102a accordingly. A control variable calculated by the resource allocator 106 is an example of an instruction.
With reference to FIG. 3, there is shown a resource entitlement control system providing adaptive feedback control for allocating resources. The control system 200 includes the resource allocator 106, the resource container 103a and the performance monitor 107. In particular, the control system 200 may be a self-tuning regulator having a feedback control loop. The resource allocator 106, for example, includes a controller 205, a model estimator 201, and a controller designer 202. The feedback control loop in the control system 200 includes the performance monitor 107 providing feedback, such as the performance monitoring information, to the controller 205 via feedback node 203. The self-tuning portion of the control system 200 includes the model estimator 201, the controller designer 202, and the controller 205. The selftuning portion provides adaptive control of the feedback loop.
Regarding the feedback loop, the performance monitor 107 measures the performance metrics of the application 104a, which is shown in FIG. 1, inside the resource container 103a to determine the performance monitoring information for the resource container 103a. The performance monitoring information may include a performance metric that indirectly reflects the demand on the resources allocated to the resource container 103a. For example, the performance monitor 107 may calculate the mean response time (MRT) for the application 104a in the resource container 103a to service requests. For example, if the MRT is increasing in successive intervals, then the demand is increasing.
An example of a performance metric is shown in FIG. 3 as "y". The performance metric "y" may be represented as the performance metric "y(k)"; where "k" is an index for a sampling interval. For example, the performance monitor 107 may calculate "y(k)" for each of a plurality of metrics measured for the resource container 103a during sampling intervals. The value of "y(k)" may be an average, such as the MRT, or a moving average. For example, as an average, "y(k)" may be calculated as the sum of the all the sample values for a particular metric measured at the last interval k-1. As another example, as a moving average, "y(k)" may be calculated as the sum of the five MRT's calculated forthe last five intervals k-5, k-4, k-3, k-2, and k-1. The sum is divided by the number of intervals, which is five in this example. Thus, as the performance metric changes, the values for "y(k)" change.
The performance monitor 107 may output "y" to a feedback node 203 and to the model estimator 201. At the feedback node 203, "y" is compared to a reference value "r" to determine an error "e". In one example,
e(k)=r(k)-y(k) Eq. (1)
The reference value "r", for example, is a performance parameter from the SLA inputs 105 shown in FIG. 1. An example of "r" is a maximum MRT. The reference value "r"