# Determining feasible variations for assigning applications to resources

Constraints on assigning applications to resources are determined. The applications are divided into sets, wherein applications in a set are related by at least one of the constraints. Variations on assigning the applications in the sets to resources are determined. Feasible variations are determined from the variations for each set, wherein the feasible variations satisfy constraints on the applications for each set. The feasible variations are simulated.

## Latest Hewlett Packard Patents:

## Description

#### PRIORITY

This application is a continuation-in-part of U.S. patent application Ser. No. 11/147,096, filed Jun. 7, 2005, now U.S. Pat. No. 7,668,703, entitled “Determining Required Capacity For A Resource” by Jerry Rolia et al., which is incorporated by reference in its entirety.

#### BACKGROUND

Grid computing services, utility-based data centers, and other types of resource-on-demand systems are becomingly increasingly popular as a highly scalable means for utilizing computer resources to meet the computing demands of users. However, managing these resource-on-demand systems is a difficult task that typically requires a significant amount of time and labor and which conventional network management software is not designed to handle.

Many management tasks are performed manually, which tends to be time consuming and costly. For example, selecting computer resources from a pool of resources to assign to a particular user's computing demands is typically performed manually. The monitoring of the pool of resources may be performed using conventional management tools. However, many administrators may be required, especially for large resource-on-demand systems such as large utility data centers, to make resource allocation decisions, resulting either in an ineffective use of resources or in costly and time-consuming management tasks.

#### SUMMARY

According to an embodiment, constraints on assigning applications to resources are determined. The applications are divided into sets, wherein applications in a set are related by at least one of the constraints. Variations on assigning the applications in the sets to resources are determined. Feasible variations are determined from the variations for each set, wherein the feasible variations satisfy constraints on the applications for each set. The feasible variations are simulated.

#### BRIEF DESCRIPTION OF THE DRAWINGS

Various features of the embodiments can be more fully appreciated, as the same become better understood with reference to the following detailed description of the embodiments when considered in connection with the accompanying figures, in which:

#### DETAILED DESCRIPTION

For simplicity and illustrative purposes, the principles of the embodiments are described. However, one of ordinary skill in the art would readily recognize that the same principles are equally applicable to, and can be implemented using variations of the described embodiments.

A system and method for allocating resources from a shared pool of resource is described. A capacity manager simulates a workload or a set of workloads, referred to as a workload cluster, on a resource or set of resources to determine a required capacity. Each workload may include one or more applications that are configured to run on a resource or set of resources. A workload cluster may be assigned to run on one or more resources.

The capacity manager simulates a workload or workload cluster and determines whether the required capacity is less than the maximum capacity of the resource. The required capacity includes a capacity needed to run a workload or a workload cluster on a resource or set of resources that are being simulated by the simulator with the workload or the workload cluster. If the required capacity is less than the maximum capacity, the resource may be assigned to run the workload or workload cluster. The required capacity may be based on constraints. In one embodiment, the required capacity is the minimum capacity needed to run a workload or a workload cluster on a resource or set of resources that are being simulated and the minimum capacity needed to satisfy all resources access class of service constraints, which are described in further detail below.

Different variations are determined and simulated in order to identify a workload assignment that best satisfies objective(s) and satisfies constraints. A variation is workload or workload cluster that is different from a previous workload or workload cluster that has been simulated. In different embodiments, different algorithms, such as an objective attainment algorithm, may be used to select variations for simulation. Constraints on application assignments, such as whether a pair of applications must not be placed on the same resource, whether a pair of applications must be placed on the same resource, or whether an application must be placed on a specific subset of resources, limit the feasible solutions for workload assignment and may be considered when determining variations so simulation resources are not wasted. Also, a scoring algorithm may be used to assign scores to the simulated variations and to select a variation to implement as a workload assignment.

Also, according to an embodiment, a capacity manager is operable to determine a plurality of feasible workload assignments that satisfy constraints on application assignments. Sets of applications are identified that are independent of each other with respect to constraints. Also, sets of applications that are related through constraints, referred to as dependent sets, are also identified. The capacity manager is operable to determine a plurality of feasible workload assignments for the independent sets of applications. Also, the capacity manager is operable to determine a plurality of feasible workload assignments for the dependent sets of applications. The feasible workload assignments are assignments of the applications to resources operable to run the assignments, wherein the assignments satisfy the constraints for the applications.

**100** according to an embodiment that provides computer resources on demand and is operable to adjust allocated computer resources as needed. The system **100** includes a pool of resources **110**, a resource manager **120** and a capacity manager **130**. The pool of resources **110** may include, for example, processors, input/output (“I/O”) bandwidth, memory, etc. For example, the pool of resources **110** may include any type of resource available on servers or clusters of servers or racks of bladed servers that are to be shared by applications.

The resource manager **120** includes a scheduler **122** and a resource monitor **124**. Each resource of the pool of resources **110** may include a resource manager **120**. In other embodiments, each pool of resources may use a single resource manager or multiple pools of resources may use a single resource manager. The scheduler **122** schedules workloads to run on resources based on resource allocation assignments determined by the capacity manager **130**. The scheduler **122** may divide a resource across a workload cluster. In other words, the resource may be allocated to multiple workloads in a workload cluster at any given time.

The resource monitor **124** monitors predetermined metrics of the resources in the pool of resources **110**. For example, the resources may be represented using one or more capacity attributes, such as CPU, memory, I/O operation rates, and bandwidths. Other capacity attributes may be used and measured as is known in the art. The resource monitor **124** measures values for the capacity attributes. For example, workload A is measured to use 80% of the CPU time for a processor resource. The measured capacity attributes are referred to as traces and may be gathered continuously over time. The traces may be gathered on a per-server basis or a per-application workload basis. In one embodiment, if the traces are gathered on a per-server basis, the aggregate load on the server may be treated as a single workload for analysis. Traces capturing past workloads demands are used as a prediction of future demands and are used for simulating workload assignments performed by the capacity manager **130** as described with respect

The capacity manager **130** determines a plan for assigning workloads to resources. The capacity manager **130** provides the resource manager **120** with instructions for assigning workloads to resources from the pool of resources **110** based on the plan.

The capacity manager **130** includes a simulator **132** and an optimizer **134**. The simulator **132** receives traces from the resource monitor **124** and simulates variations based on the traces where specific applications are assigned to specific resources of the pool of resources **110**. The optimizer **134** selects the best variation based on the objective(s) for optimization. A variation is a workload or a workload cluster that is varied from an initial set-up or prior variation and is simulated on a resource by the simulator **130**. The variation may be changed during an optimization process to determine a best variation based on the objective(s) for optimization. For example, the objective for optimization may include load balancing, where workloads are spread out over a fixed number of resources to lessen the likelihood of service level violations, or consolidation, where workloads are packed on to the fewest number of resources possible. Another example of an objective includes problem solving where alternative assignments are recommended to lessen the impact of unexpected demands on a particular resource. The optimizer **134** selects a variation to simulate on a resource that is likely best suited to meet the objective(s).

The optimizer **134** may also establish several variations for the simulator **132** to simulate and ultimately one may be selected. The variations may be based on the objective of the optimizer **134**, as discussed above.

The variations may also be determined based on constraints on workload assignments. The optimizer **134**, for example, identifies feasible workload assignments that satisfy constraints for the applications in the workloads being assigned.

The simulator **132** simulates each of the variations forwarded by the optimizer **134**. The simulated variations may include the feasible workload assignments determined by the optimizer **134**. The simulator **132**, for example, assigns a score to each variation based on the objective(s) for optimization. The score may be based on results of the simulation and the objective(s). The scores are used to select a variation for implementation.

Different scoring algorithms may be used to assign scores to variations based on the objective. For example, suppose the objective is consolidation, and the resources used in the simulation include ten processors and the variation being simulated includes a workload cluster. The simulator **132** simulates the variation and packs the workload cluster on five of the ten processors. The results of the simulation show that all demands are satisfied using only five of the ten processors for the workload cluster being simulated. Then, the score may be high because several workloads are able to be allocated to fewer resources. In this example, a score is given for the assignment of all workloads to the resources they require, and this score gets used to select a variation. In another example, a score may be given on a per resource basis and the scores are used to calculate a final score used to select a variation. Given the same example where the workload cluster is packed onto five of the ten processors, a score is given for each processor. For example, a “1” is given for processors assigned to run a workload in the cluster and a “0” is given to processors that are not assigned to a workload. These numbers are summed to determine a final score. A variation with the lowest final score may be selected for consolidation. In another example, the objective is load leveling. The workload cluster is spread among the ten processors. A score is given for each of the ten processors based on the CPU utilization at the busiest times. For example, each processor is given a score between 1 and 10 based on the CPU utilization at the busiest times. A final score is determined for the variation based on the difference between the scores for each processor. For example, if all the processors have the same score, then a high final score is given because the workload cluster is evenly distributed among the ten processors. It will be apparent to one of ordinary skill in the art that the scores may be calculated using other objective functions and based on other factors. For example, instead of CPU utilization, I/O bandwidth may be measured, or instead of measuring CPU utilization at the busiest times, CPU utilization may be determined over a time interval. In another example, CPU utilization may be a factor considered when the objective is consolidation, such as when the objective is to make the processors running the cluster as busy as possible. These and/or other factors may be considered separately or in conjunction for a scoring algorithm.

The optimizer **134** selects the variation with the best score and reports the selected variation as the best result. In another embodiment, the optimizer **134** may rank the variations and present them to a user, such that a user can select a variation to be implemented.

**134** forwards a new variation **242** of workloads to the simulator **132** for simulation of the new variation **242** on a selected resource **245** from the pool of resources **110** shown in **245** may be a set of resources, such as one or more processors, memory, I/O, and one or more servers. The new variation **242** may be based on an initial set-up **202** input into the optimizer **134**. The initial set-up **202** may include a current configuration of a system, such as a current allocation of resources to workloads, may be chosen at random, or may be determined using an algorithm, such as one of the algorithms described below.

In one embodiment, new variations, such as the new variation **242**, are determined based on the objective attainment algorithm **212**. The objective attainment algorithm **212** may include a specific algorithm that allows attainment of the objective(s) of the optimization process. For example, a greedy algorithm may be used. In one example, the objective of the optimization process is packing as many workloads onto as few resources as possible, i.e., consolidation. The greedy algorithm may include selecting one or more clusters of workloads as the new variation **242** based on a cluster ratio. Each cluster ratio is a comparison of a required capacity of two or more workloads running together to the sum of the required capacity of all of the workloads in the variation when each workload is running by itself.

Another objective attainment algorithm that may be used to identify new variations, after the initial set-up has been run, includes a genetic algorithm. As is known in the art, a genetic algorithm may include an initializer function, a crossover function, and a mutation function. The genetic algorithm directs a search for a high scoring variation. The search is affected by the mutation and crossover functions. According to an embodiment, the mutation function is determined based on the objective for selecting a variation to be implemented. For purposes of determining variations, the genetic algorithm doesn't need to know about the constraints. For example, the genetic algorithm treats each application set as a unit, and all the units are independent of one another for purposes of determining variations.

Regarding the mutation function in general, one result of a simulation is a determination of the required capacity for the applications on each resource, such as described in detail below. The ratio of required capacity with total available capacity is the peak utilization of the resource. In general, the greater the concurrency of capacity within a resource, such as the more processors per multi-processor server, the higher the acceptable peak utilization for the resource. Many times it may be necessary to compare peak utilizations of servers with different numbers of processors to select a server to run the workload or workload cluster. In one embodiment, the peak utilization of a resource, such as a server, is normalized to compare servers having different components, such as a different number of processors. For example, the optimizer **134** normalizes the peak utilization of a resource, referred to as U, by the power of P, namely power (U, P) where P is the number of processors on a multi-processor server. Normalized peak utilizations may then be compared even if the resources are different, such as having different numbers of processors. An example is described of normalizing values for a particular attribute of a resource, such as peak utilization. It will be apparent that resource may be compared by normalizing other attributes. For example, servers may be normalized based on a rating of the compute capacity of processors.

According to an embodiment, different resources are normalized, such as normalizing peak utilizations of different resources, in order to compare and select a resource to simulate or to run workloads based on an objective.

For example, the objective is consolidation. The mutation function is used to select a resource, such as the selected resource **245** shown in Figure **2**. For example, the selection is done using pseudo-random numbers. Each resource from a set of resources, such as the pool of resources **110** shown in **245** with a higher weight. The applications previously assigned to the selected resource **245** are then assigned to resources already being used. In this way the total number of resources used is decreased by one. This helps to find a solution that minimizes the number of resources that are used.

In another example, the objective is load leveling, where an attempt is made to divide the workload evenly across resources. In one embodiment, the mutation function is used to select a resource **245** that has the largest normalized peak utilization. One or more applications previously assigned to the selected resource **245** are then assigned to other resources.

In addition to using the objective attainment algorithm **212** to select new variations for simulation application assignment constraints may be considered. When searching for a new variation that best satisfies an objective, it is advantageous to consider only those alternative assignments that satisfy constraints to the problem. In one embodiment, constraints on application assignments, such as whether a pair of applications must not be placed on the same resource, whether a pair of applications must be placed on the same resource, or whether an application must be placed on a specific subset of resources, limit the variations that may be selected as the new variation **242**. These constraints limit the feasible solutions for the optimizing search. Avoiding infeasible solutions ensures that simulation resources are not wasted.

For example, a list of constraints are used to identify sets of applications related by the constraints so that their assignments are governed together. For each such set, a specified number of alternative feasible assignments are pre-computed such that all constraints are satisfied for each of the assignments. Each feasible assignment for a set is associated with a unique index. This index defines how each application in its corresponding set is assigned to a resource for its particular assignment. For example, the resources being assigned to applications are servers and the index is a vector of applications. Each slot in the vector corresponds to a server. For example, the vector {(A, B), C, D} indicates that applications A and B are assigned to server **1**, and the applications C and D are assigned to servers **2** and **3**, respectively. A vector is provided for each workload assignment.

Each feasible assignment may be used as the new variation **242** or the feasible assignments may be a set of variations, one or more of which may be selected by the objective attainment algorithm **212**, for simulation.

The number of alternative feasible assignments for a set of applications related by the constraints so that their assignments are governed together could be very large. Yet an algorithm is needed to enumerate a diverse subset of these. The algorithm may be used to search for a number of the feasible assignments, one at a time. In one embodiment, a probabilistic, recursive, depth first search algorithm is used to find a feasible assignment for the set. This assignment, which may be identified using a single index for the corresponding set of applications actually specifies the assignment of each application to a specific resource such that the constraints are satisfied. The algorithm uses pseudo-randomly generated probabilities to guide the search so that the assignments are likely to differ more significantly from one another in nature. The algorithm reports a feasible assignment (if one can be found) that differs from other assignments that may have been previously reported.

The probabilistic, depth first search algorithm is used to determine new variations. The determined feasible variations are compared against previously determined feasible variations to determine whether there are any duplicates. The duplicates are removed or are not selected for simulation. This results in a plurality of feasible variations, which are a number of distinct workload assignments. A plurality of feasible variations are computed for each set of applications.

Once a number of distinct assignments have been pre-computed for all sets, the objective attainment algorithm **212** chooses amongst these application-set assignment indexes. For any particular combination of set assignment indexes, each application is associated with a particular resource. This information is used for the simulation.

In addition to constraints, correlations may be used to select the new variation **242**. Simulating variations of workload clusters allows the capacity manager **130** to observe correlations between applications and use the correlations to better utilize capacity on resources. For example, if each application of a workload cluster having two applications uses 0.75 CPUs at its peak, a conventional management tool may assign 0.75 CPUs to each of the two applications, requiring allocation of 1.5 CPUs to the workload cluster. However, simulating the workload cluster may reveal that each application has its peak demand at alternating times. Thus, the two applications may be able to share 0.75 CPUs.

As shown in **132** receives the new variation **242** as well as traces **244** of observed demands and a maximum capacity **246** of each resource as input. The simulator **132** emulates the assignment of the new variation **242** on the selected resource **245**. The traces **244** may include traces received from a resource monitor, such as the resource monitor **124** shown in **244**, for example, correspond to the previously measured demands of the workloads in the new variation **242**. The maximum capacity **246** of the selected resource **245** may include a time-varying capacity of the resource. For example, if an attribute of the selected resource **245** includes bandwidth over a network, the bandwidth for the network may be higher at night than during the day or vice versa. Thus, the maximum capacity **246** may become a time-varying maximum capacity. The time-varying nature of the maximum capacity **246** is taken into account in the simulation process. Also, the required capacity also takes into account the time-varying capacity of workloads because the traces **244** used to determine the required capacity include observed, time-varying demands of workloads.

In one embodiment, the maximum capacity **246** may be included in the traces **244**. For example, the maximum capacity **246** may be determined through analysis of the traces **244**. In one embodiment, the maximum capacity **246** is the maximum capacity of the selected resource **245**, which may be specified in manufacture specifications. In another embodiment, the maximum capacity **246** of the selected resource **245** may be less than the actual maximum capacity of the selected resource **245**, which may be specified in manufacturer specifications. For example, if a goal of resource allocation is for the selected resource **245** to be used to 50% capacity, the maximum capacity **246** of the resource may be 50% of the selected resource **245**. Thus, if the selected resource **245** is a processor, the maximum capacity **246** may be half of a processor in terms of CPU utilization.

The simulator **132** then compares the results of the simulation to constraints to determine the required capacity of the workloads at a processing block **248** of the simulator **132**. Constraints may include minimum requirements that should be met when assigning workloads to resources. These minimum requirements may be provided in service level agreements and/or may be based on resources access class of service (CoS). Also, the constraints may include constraints on application assignment, such as whether an application for one entity may be run on the same hardware as an application for another entity. Constraints may include, for example, that two workloads must be together on a resource, two workloads must not be together on a resource (in other words, must be apart), a workload must reside on a specific list of resources, or any combination of such constraints.

The required capacity includes a capacity needed to run a workload or a workload cluster, such as the new variation **242**, on the selected resource **245**. The required capacity may be based on the constraints. In one embodiment, the required capacity is the minimum capacity needed to run the workload or workload cluster and satisfy all resources access CoS constraints.

According to an embodiment, a constraint, such as a CoS constraint or other type of constraint, may be expressed in terms of the capacity attributes, which are measured by the resource monitor **124** shown in

The resource access CoS constraints refer to constraints for workloads assigned to a particular class of service. Different classes may have different constraints. In one embodiment a resource access CoS constraint may include a probability, θ, and a deadline, s. The resource access probability, θ, refers to the probability that a workload receives a unit of capacity when requested. Based on simulations performed by the simulator **132** for the new variation **242**, an achieved resource access probability, θ, and a deadline, s, are determined and compared to a resource access probability, θ, and a deadline, s, specified in a resource access CoS constraint to determine whether a required capacity is met. As an example of different classes, interactive applications may be included in one class and batch applications may be included in another class. The class for the interactive applications may have a higher resource access probability, θ, than the class for the batch applications, because batch application processing typically can be deferred without violating a SLA.

Each application may be assigned to a CoS. In one embodiment, when multiple CoS are involved, the simulator **132** may schedule access to capacity in the following way. Capacity is assigned to the highest priority, e.g., greatest θ value, CoS first. If a CoS does not have a probability of 1.0, then it is only offered its specified probability of access with remaining demands deferred to future intervals. The remaining capacity is assigned to the next lower CoS. This repeats for other lower CoS.

The resource access probability θ may be defined as follows. Let A be the number of workload traces **244** under consideration. Each trace has W weeks of observations with T observations per day as measured every m minutes. The notion of a week may be used as a timescale for service level agreements, however, other timescales may be used. Time of day captures the diurnal nature of interactive enterprise workloads (e.g., those used directly by end users). Other time scales and patterns may also be used. Each of the T times of day, e.g., 8:00 am to 8:05 am, is referred to as a slot. For 5 minute measurement intervals, there are T=288 slots per day. Each slot, t, may be denoted using an index 1≦t≦T. Each day x of the seven days of the week has an observation for each slot t. Each observation has a measured value for each of the capacity attributes considered in the analysis.

To define resource access CoS more formally, one CoS and one capacity attribute that has a capacity limit of L units of demand may be considered. Let D_{w,x,t }be the sum of the demands upon the attribute by the A workloads for week w, day x and slot t. The measured value of θ may be defined as:

Thus, θ may be reported as the minimum resource access probability received any week for any of the T slots per day. Furthermore, let L′ be the required capacity for a capacity attribute to support a CoS constraint. A required capacity L′ may be the smallest capacity value, L′≦L, to offer a probability θ′ such that θ′≧θ, and such that those demands that are not satisfied upon request, D_{w,x,t}−L′>0, are satisfied within a deadline s. The deadline may be expressed as an integer number of slots s.

Those requests for units of capacity that are not received on demand may be deferred. Deferred units of capacity must be made available to the workload within the deadline s. If either part of the constraint is unsatisfied then there is a service level violation. The demands reflected in the traces are used to compute the empirical value for θ for the traces and/or the minimum capacity required to ensure that a CoS constraint is satisfied. Multiple CoS may be supported so that workloads with different needs may be accommodated.

Other constraints may be introduced into the simulator, such as application placement constraints. For example, some workloads must be hosted on separate resources for the purpose of availability. In another example, some workloads must be associated with specific resources because of licensing constraints.

The resource access probability θ is one example of a QoS metric that may be used to determine whether a variation may be satisfactory even if demands exceeds supply. Other metrics may also be used.

**132** shown in **132** may perform a plurality of simulations for each configuration to determine the required capacity. In the example described below, the workload being simulated is the new variation **242** simulated on the selected resource **245** shown in

At processing block **310**, the simulator **132** runs a simulation to determine the achieved θ and s. The processing block **310** may receive the inputs of traces **244** and maximum capacity **246** of the selected resource **245** in addition to the new variation **242**. The simulation may include replaying the traces **244**, comparing the aggregate demand of the observations in the traces with the capacity of the selected resource **245**, and computing the resource access CoS statistics, θ and s. A search method, such as a binary search, may be used to find the required capacity for each capacity attribute such that the CoS constraints are satisfied.

The simulator **132** determines the required capacity of the new variation **242** shown in **315**, the simulator **132** determines if the achieved θ and s satisfy the resource access CoS constraints. If resource access CoS constraints are satisfied after a simulation, the simulator **132** may reduce the intermediate required capacity of the workload or workload cluster being simulated at processing block **320**. If the resource access CoS constraints are not satisfied after a simulation, the intermediate required capacity of the resource may be increased at processing block **325**.

The simulator **132** may then determine, at processing block **330**, if the intermediate required capacity differs from the previously determined intermediate capacity by less than a tolerance. For example, a previous run of the steps shown in **325** or **320** from the first intermediate capacity. A difference between the first and second intermediate capacities is compared to a tolerance. If the difference is greater than a tolerance than another intermediate capacity may be determined. If the difference is less than the tolerance, then the current intermediate capacity becomes the required capacity of the new variation **242**.

At processing block **332**, the required capacity is compared to the maximum capacity **246** of the selected resource **245**. If the maximum capacity **246** is exceeded, then the simulator **132** reports at block **340** that the new variation **242** cannot be supported by the selected resource **245** while the resource access CoS constraints are satisfied. Another resource may then be selected.

If successive intermediate required capacities differ by less than the tolerance at block **330**, the simulator **132** reports at block **340** that there is sufficient capacity in the selected resource **245** to provide the required capacity of the new variation **242**. The selected resource **245** becomes a candidate for running the new variation **242**. Other resources may also be determined to be candidates using the same steps. As described above, candidates may be assigned scores and the candidate with the best score may be selected and assigned the workload or workload cluster.

The report of sufficient capacity to meet the required capacity is shown as the evaluated score **250** in **134**. The resource with the score **250**, such as the selected resource **245**, becomes a candidate to be assigned the workload or workload cluster of, for example, the new variation **242**. The optimizer **134** may store the received scores in a scores store **216**. In one example, the scores may include a measure of how well a capacity of a resource being simulated is able to satisfy a required capacity. For example, if a resource has a 10% over provisioning above the required capacity versus a 2% over provisioning above the required capacity, the resource with 10% over provisioning may be given a higher score if the objective is to provide a high degree of assurance of satisfying the required capacity. Other techniques may be used to determine the scores **216**. The reporter **214** reports the best results in a best results report **260** as shown in

The steps or processing blocks shown in

**400** for allocating resources. The method **300** is described with respect to **401**, a capacity manager, such as the capacity manager **130** shown in **110**, such as the selected resource **245** shown in **402**, the capacity manager **130** simulates one or more workloads, such as the new variation **242** shown in **245**. Each of the one or more workloads may represent at least one application configured to run on the resource. In one embodiment, an objective attainment algorithm, such as a greedy algorithm or a genetic algorithm may be used to identify one or more workload clusters to simulate on the resource. In another instance, the workload cluster to simulate may be based on an initial set-up. For example, the workload cluster may be a workload cluster already running on the resource. In another example, the workload cluster may be selected by user input. In another example, the capacity manager may select one or more permutations of the workloads available to run on the resource as a workload cluster to simulate. The simulation may be performed by a simulator **134** as described above with respect to **402**.

At step **403**, the capacity manager **130** determines the required capacity of the workloads based on the simulation. The required capacity of the workloads may be used to determine a score for the workloads on the resource. The steps **402**-**403** may be repeated for other variations of workloads for each resource. The determined score for each variation of workloads may be used to determine an assignment of workload clusters for each resource.

**500** for selecting one or more new variations, such as the new variation **242**, based on application assignment constraints. The steps of the method **500** may be used to select one or more workloads to simulate at step **402** of the method **400** shown in **400** is described with respect to

At step **501**, the capacity manager **130** shown in **110** shown in **242**. These constraints limit the feasible solutions for the optimizing search performed by the optimizer **134**. Avoiding infeasible solutions ensures that simulation resources are not wasted. Application assignment constraints may be specified in service level agreements (SLA's) or through other ways.

At step **502**, the capacity manager **130** determines sets of applications, wherein each set includes one or more applications related by the constraints identified at step **501**. For example, a list of constraints is determined for the applications to be assigned to resources. Then, applications that are associated by constraints, either directly or transitively, are assigned to the same set.

Each set includes one or more applications related by one or more constraints. For example, this may include sets of applications that must be assigned to the same resource as specified in an SLA or sets of applications that must be assigned to different resources. An example of set determination is as follows. A constraint on applications A and B is that these applications must be assigned to the same resource. A constraint on applications B and C is that these applications must be assigned to the same resource. Thus, applications A-C have a transitive relationship and must be assigned to the same resource, and the capacity manager **130** assigns these applications to a single set. In another example, a constraint on applications D and E is that these applications must not be assigned to the same resource. These applications are also related by constraint and are assigned to a single set, which is different from the set for the applications A-C. It will be apparent to one of ordinary skill in the art that constraints on assigning applications to resources may include constraints other than provided in the examples above. Also, assignment of all the applications in a set may be considered when assigning each application in the set to a resource.

At step **503**, the capacity manager **130** identifies the sets that are independent. A set is considered independent from other sets if all the applications in the set are not associated by one or more constraints with an application in another set. For example, applications that have no constraints are each in their own independent set. Also, with regard to the example above including applications A-C in a set, this set is independent if the constraints on workload assignment for these applications are not associated with any applications other than A-C. This set would be considered dependent, i.e., related to another set, if at least one of the applications A-C were related to an application in another set by a constraint. For example, the application A may have been assigned to a second set, because the application F has a constraint that it cannot be assigned to the same resource as the application A. Then, the set for the applications A-C and the set having the application F are dependent sets.

At step **504**, the capacity manager **130** determines a predetermined number of new variations. The objective attainment algorithm **212** may be used to determine the new variations. Examples of the objective attainment algorithm **212** include but are not limited to a genetic algorithm or a greedy algorithm.

At step **505**, the capacity manager **130** selects new variations from the variations determined at step **504** that are feasible. Feasible variations are workload assignments that satisfy the constraints of the applications being assigned to resources. Feasible variations may be determined by comparing the assignments in the new variations to the constraints for the applications assigned to resources in the new variations. If duplicate variations are determined, one of the duplicates is not selected as a feasible variation.

At step **506**, the new variations selected at step **505** are simulated by the simulator **132** shown in

After step **502**, where the sets of applications are determined, in addition to determining the independent sets at step **503**, the capacity manager **130** determines the dependent sets at step **510** shown in

At step **511**, the capacity manager **130** determines a predetermined number of new variations for the dependent sets. The objective attainment algorithm **212** may be used to determine the new variations. Examples of the objective attainment algorithm **212** include but are not limited to a genetic algorithm or a greedy algorithm.

At step **512**, the capacity manager **130** selects new variations from the variations determined at step **511** that are feasible. In one embodiment, a probabilistic, recursive, depth first search algorithm is used to search a search space comprising the new variations determined at step **511** for variations that are feasible variations for each dependent set. Feasible variations for a set, which may be identified using a single index for the corresponding set of applications, specifies the assignment of each application to a specific resource such that the constraints are satisfied. The algorithm uses pseudo-randomly generated probabilities to guide the search so that the assignments are likely to differ more significantly from one another in nature. The algorithm reports a feasible assignment (if one can be found) that differs from other assignments that may have been previously reported. It will be apparent to one of ordinary skill in the art that other well known search algorithms may be used to identify feasible variations. In an alternative embodiment, a constraint satisfaction solver based on optimization techniques may be used to discover feasible variations **511** for each set of applications.

At step **513**, the new variations selected at step **511** are simulated by the simulator **132** shown in **130** scores the results to identify the variations that best satisfy the desired objective. A feasible variation that describes the assignment of each application to a particular resource is selected for each set. The capacity manager **130** may report the feasible variation for each set that best satisfies an objective for assigning the applications to the resources based on the simulations of the feasible variations or may report a predetermined number of the feasible variations that best satisfy the objective and one variation is selected and used for allocation.

Then, the resources are allocated to the applications in each set. For example, the scheduler **122** shown in

The steps **503**-**506** shown in

Many of the steps of the method **500** are described with respect to the capacity manger **130** performing the steps. It will be apparent to one of ordinary skill in the art that one or more of the steps of the method **500** may be performed by another computer system or by a system administrator. Furthermore, one or more of the steps of the method **500** may be performed in an order other than shown. For example, the dependent and independent sets may be determined simultaneously and the processing of the dependent and independent sets may be performed simultaneously. Alternatively, the dependent and independent sets may be processed subsequently.

Referring to **600** is shown in accordance with an embodiment. The computer system **600** shown may be used as the system for allocating resources shown in **600** may include one or more processors, such as processor **602**, providing an execution platform for executing software. The computer system **600** also includes a memory **606**, which may include Random Access Memory (RAM) where software is resident during runtime. Other types of memory such as ROM (read only memory), EPROM (erasable, programmable ROM), EEPROM (electrically erasable, programmable ROM) and data storage, such as hard disks, etc., may be used.

A user interfaces with the computer system **600** with one or more input devices **618**, such as a keyboard, a mouse, a stylus, and the like and a display **620**. A network interface **630** is provided for communicating with other computer systems. It will be apparent to one of ordinary skill in the art that **600** are optional, such as the display and input devices, and other types of components may be used or substituted as is known in the art.

One or more of the steps of the methods **400**-**500** and other steps described herein may be implemented as software instructions embedded or stored on a computer readable medium, such as the memory **606**, and executed by the processor **602**. The steps may be embodied by a computer program, which may exist in a variety of forms both active and inactive. For example, there may exist as software program(s) comprised of program instructions in source code, object code, executable code or other formats for performing some of the steps when executed. Any of the above may be stored on a computer readable medium, which include storage devices and signals, in compressed or uncompressed form. Examples of suitable computer readable storage devices include conventional computer system RAM (random access memory), ROM (read only memory), EPROM (erasable, programmable ROM), EEPROM (electrically erasable, programmable ROM), and magnetic or optical disks or tapes. Examples of computer readable signals, whether modulated using a carrier or not, are signals that a computer system hosting or running the computer program may be configured to access, including signals downloaded through the Internet or other networks. Concrete examples of the foregoing include distribution of the programs on a CD ROM or via Internet download. In a sense, the Internet itself, as an abstract entity, is a computer readable medium. The same is true of computer networks in general. It is therefore to be understood that those functions enumerated herein may be performed by any electronic device capable of executing the above-described functions.

While the embodiments have been described with reference to examples, those skilled in the art will be able to make various modifications to the described embodiments without departing from the true spirit and scope. The terms and descriptions used herein are set forth by way of illustration only and are not meant as limitations. In particular, although the methods have been described by examples, steps of the methods may be performed in different orders than illustrated or simultaneously. Those skilled in the art will recognize that these and other variations are possible within the spirit and scope as defined in the following claims and their equivalents.

## Claims

1. A method comprising:

- determining constraints on assigning applications to resources;

- determining sets of the applications assigned to resources, wherein applications in a determined set are related by at least one of the constraints;

- determining variations on assigning the applications in the sets to resources;

- selecting feasible variations from the determined variations for each set, wherein the feasible variations satisfy constraints on the applications for each set; and

- simulating the feasible variations.

2. The method of claim 1, further comprising:

- determining a feasible variation for each set that best satisfies an objective for assigning the applications to the resources based on the simulations of the feasible variations.

3. The method of claim 2, further comprising:

- allocating the applications in each set to the resources as described in the determined feasible variation for each set that best satisfies the objective.

4. The method of claim 1, further comprising:

- identifying independent sets of the sets of applications, wherein the independent sets include applications not related by constraints to applications in any other set of the sets.

5. The method of claim 1, further comprising:

- identifying dependent sets of the sets of applications; and

- selecting feasible variations further comprises performing a probabilistic, recursive search of determined variations for the dependent sets to select the feasible variations.

6. The method of claim 5, wherein selecting feasible variations further comprises:

- using pseudo-randomly generated probabilities to select the feasible variations such that each variation is likely to differ from another variation.

7. The method of claim 1, wherein selecting feasible variations further comprises using a constraint satisfaction solver to select the feasible variations.

8. The method of claim 1, wherein determining variations on assigning applications in the sets to resources further comprises:

- determining an objective for assigning the applications to the resources; and

- determining variations that best satisfy the objective.

9. The method of claim 8, further comprising:

- using a genetic algorithm to determine the variations.

10. The method of claim 1, wherein determining sets of applications further comprises:

- identifying sets of applications such that assignment of all the applications in a set is considered when assigning each application in the set to one or more of the resources.

11. The method of claim 1, further comprising:

- determining a required capacity of a set;

- determining whether a maximum capacity of a resource to be assigned to an application in the set is greater than the required capacity; and

- assigning the application to run on the resource in response to the maximum capacity being greater than the required capacity.

12. The method of claim 11, wherein the required capacity comprises a capacity needed to satisfy resources access class of service constraints for the application.

13. A capacity manager for a resource-on-demand system, the capacity manager comprising:

- an optimizer, executed by a processor, operable to determine constraints on assigning applications to resources and determine sets of applications, wherein applications in each set are related by at least one of the constraints and each set is identified as an independent set or a dependent set related to another one of the sets by at least one of the constraints;

- the optimizer is further operable to process the independent sets and the dependent sets differently to determine feasible variations on assigning the applications in the sets to resources, wherein the feasible variations satisfy constraints on the applications for each set; and

- a simulator operable to simulate the feasible variations for the sets to determine at least one feasible variation operable to be used to allocate the applications in each set to one or more of the resources.

14. The capacity manager of claim 13, wherein the optimizer is further operable to select feasible variations for each of the sets based on an objective for utilizing the resources.

15. The capacity manager of claim 13, wherein the optimizer is further operable to execute a genetic algorithm to determine variations for each set.

16. The capacity manager of claim 13, wherein a constraint satisfaction solver or a probabilistic, recursive search of the variations is used to identify feasible variations from the determined variations.

17. A resource-on-demand system comprising:

- resources for running applications;

- a resource manager for scheduling applications to be run on the resources; and

- an optimizer, executed by a processor, for determining constraints on assigning applications to the resources and determining sets of applications, wherein applications in each set are related by at least one of the constraints and each set is identified as an independent set or a dependent set related to another one of the sets by at least one of the constraints;

- wherein the optimizer is also for processing the sets to determine feasible variations on assigning the applications in the sets to the resources, wherein the feasible variations satisfy constraints on the applications for each set, and a probabilistic, recursive search is used to identify feasible variations from determined variations that are likely to differ from one another for the dependent sets.

18. The system of claim 17, further comprising:

- a simulator for simulating the feasible variations for the sets to determine the feasible variations that best satisfy an objective for utilizing the resources.

19. The system of claim 17, wherein the optimizer uses a genetic algorithm to determine variations for the sets, and the feasible variations are selected from the variations.

20. The system of claim 17, further comprising a scheduler for assigning applications in a set to run on one or more resources of the resources if a maximum capacity of the one or more resources is greater than a required capacity of the applications in the set.

## Referenced Cited

#### U.S. Patent Documents

7020697 | March 28, 2006 | Goodman et al. |

7146353 | December 5, 2006 | Garg et al. |

7310673 | December 18, 2007 | Zhu et al. |

7685281 | March 23, 2010 | Saraiya et al. |

20050010664 | January 13, 2005 | Hubbard |

#### Other references

- Andrzejak, A. et al., “Bounding the Resource Savings of Utility Computing Models”, HP Labs Technical Report, HPL-2002-339, Internal Accession Date Dec. 2002.
- Appleby, K. et al., “Oceano-SLA Based Management of a Computing Utitlity”, downloaded Jun. 6, 2005.
- Chase, J. S. et al., “Manageing Energy and Server Resources in Hosting Centers”, downloaded Jun. 6, 2005.
- Pieper, J. et al., “High Level Cache Simulation for Heterogeneous Multiprocessors”, DAC '04, ACM Press, Jun. 2004.
- Hrischuk, C. E. et al., “Trace-Based Load Characterization for Generating Performance Software Models”, IEEE Transactions on Software Engineering, Jan. 1999, Abstract only.
- Rolia, J. et al., “Automating Enterprise Application Placement in Resource Utilities”, 2003.
- Singhal, S. et al., “Quartermaster—A Resource Utility System”, HP Labs Technical Report, HPL-2004-152, Internal Accession Date Sep. 2004.
- http://www.aogtech.com/, Asset Optimization Group, downloaded Jun. 6, 2005.
- http://www.hp.com/go/PRM, HP Process Resource Manager, downloaded Jun. 6, 2005.
- http://www.teamquest.com, TeamQuest, downloaded Jun. 6, 2005.

## Patent History

**Patent number**: 8103486

**Type:**Grant

**Filed**: Oct 12, 2006

**Date of Patent**: Jan 24, 2012

**Assignee**: Hewlett-Packard Development Company, L.P. (Houston, TX)

**Inventors**: Jerry Rolia (Ontario), Martin Arlitt (Alberta)

**Primary Examiner**: Russell Frejd

**Application Number**: 11/546,632

## Classifications

**Current U.S. Class**:

**Modeling By Mathematical Expression (703/2);**Resource Allocation (718/104); Distributed Data Processing (709/201); Network Resource Allocating (709/226)

**International Classification**: G06F 17/10 (20060101);