Techniques for Virtual Machine Placement in Clouds

MTP Stage 1 Report Submitted in partial fulfillment of the requirements for the degree of Master of Technology

by Dhaval Bonde Roll No: 08305910

under the guidance of Prof. Umesh Bellur and Prof. Purushottam Kulkarni

a

Department of Computer Science and Engineering Indian Institute of Technology, Bombay Mumbai 2010

Contents 1 INTRODUCTION

2

2 PROBLEM STATEMENT

3

3 RELATED WORK

3

4 ALGORITHM DESIGN 4.1 LP Formulation . . . . . . . . . . . 4.2 Heuristics for VM Placement . . . 4.2.1 First Fit . . . . . . . . . . . 4.2.2 Single Dimensional Best Fit 4.2.3 Volume Based Best Fit . . 4.2.4 Dot Product Based Fit . . 4.2.5 Load Balanced Fit . . . . .

. . . . . . .

5 6 7 9 9 9 9 9

5 EXPERIMENTAL EVALUATION 5.1 Consolidation Validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.2 Algorithm Comparison-1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.3 Algorithm Comparison-2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

9 9 10 11

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

6 VIRTUALIZATION SCENARIOS 12 6.1 VM-VM affinity and Interference . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 6.1.1 Capturing Affinity and Interference . . . . . . . . . . . . . . . . . . . . . . 12 6.2 VM-PM affinity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 7 LOOKING AHEAD 7.1 LP and rounding approaches . . . . . . . . . . 7.2 Removing the homogeneity assumption . . . . . 7.3 Using Synthetic Datasets . . . . . . . . . . . . 7.4 Integrating the output into a Cloud Controlling

. . . . . . . . . . . . . . . software

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

14 14 14 14 15

8 CONCLUDING REMARKS

15

A Appendix

16

1

Abstract Traditional data centers offer many services hosted on dedicated physical servers, which are often under-utilized in terms of resources used. Virtualization allows these data centers to consolidate their services onto a lesser number of physical servers than originally required. There may be hundreds of such services running in a single data center. In our work, we have implemented different heuristics for server consolidation which work with such large number of services being hosted in the data center. We have also presented a study of approaches adopted in literature which implicitly assume small number of services leading to potentially unscalable solutions. The final goal of our project is to come up with a scalable system that takes the resource requirements of virtual machines and the number of physical machines available as input and gives a mapping of virtual machines to physical machines which considers any virtualization related scenarios that arise in data centers.

1

INTRODUCTION

In traditional data centers, applications are tied to specific physical servers that are often overprovisioned in order to serve the complex resource requirements of enterprise services and in the hope of handling unexpected surges in resource demands. As a consequence, the level of resource utilization on any server is typically very low [5]. This incurs high operational costs and heavy investments, not to mention wasted power and floor space and a significant management overhead. Such a situation may be referred to as a ‘server sprawl’ [14], a situation in which there are many underutilized servers taking up more space and energy than can be justified by their workloads. Cloud computing offers a means to decouple the application activities from the physical resources required. This has enabled consolidation of multiple applications onto a lesser number of physical servers resulting in an increase in server utilization. Such decoupling of resources is facilitated by the concept of a ‘virtual machine’ which encapsulates an application with a specific set of functionalities. Physical resources are made available to the virtual machine by a guest operating system running on each physical machine. The virtual machine runs over this guest operating system which also provides facilities for creation, destruction and migration of virtual machines. Xen [7], KVM [4], VMware [6] are some of the products that are widely used for management of such virtual machines. Due to the ability to host multiple applications (virtual machines) onto same physical servers while also being able to migrate them seamlessly across different servers, new challenges have cropped up. These challenges include balancing load amongst all physical machines, figuring out which VMs to place on which PMs and handling sudden surges in resource demands. Moving an application running in a physical non-virtualized environment to a virtualized one involves three broad stages: 1) Application Profiling in which the application is profiled in its physical environment to get its resource utilization, 2) Generation of Virtual Machine Configurations in which the resource utilizations are used to generate configurations for virtual machines after consideration of factors like virtualization overheads, etc. and 3) Virtual Machine Placement which takes these generated virtual machine configurations as input and tries to figure out the best possible grouping of the VMs onto the physical servers so that the number of physical machines is minimized. Our work revolves around addressing the issues related to this stage. For small number of virtual and physical machines, it might be possible for an operator to manage the placement of virtual machines. However, as the number of VMs and PMs increases, situation becomes unmanageable and automation becomes necessary. Even in an automated calculation of placement plans, the number of possible mappings to be evaluated for a given set of virtual and physical machines is [11]: 2

(N umber of physical hosts)(N umber

of virtual machines)

(1)

Such a large solution space makes it almost impossible for any brute force VM-PM mapping algorithm to give exact placement plans in practically acceptable times. Hence, intelligent placement heuristics are needed to narrow down the search for a solution to obtain near-optimal placement plans. In our work, we aim to implement and try to compare such placement heuristics. Currently, we have developed and implemented an LP based formulation and a few heuristics like First Fit, Single Dimensional Best Fit, Volume Based Best fit and Dot Product based fit and are trying to compare these in terms of how well they perform, how many physical machines they use in relation to each other and what are their possible operating regions. We are also looking at trying to include certain scenarios like affinity and interference between VMs that may arise in actual data centers. In the remaining part of the document, we put forth our problem statement in section 2. We discuss related work in section 3. The algorithms are discussed in section 4. In section 5, we show the results of some initial experiments related to validation and algorithm comparison. Section 6 describes how virtualization scenarios like affinity and interference can be added to the current heuristics. In section 7, we discuss the next steps we are planning to take in the project. Finally, we make some concluding remarks in section 8.

2

PROBLEM STATEMENT

Our problem statement can be briefly described as follows: • ‘M’ physical machines are available and their resource capacities given along memory, CPU and Network bandwidth dimensions. • There are ‘N’ virtual machines to be placed. The requirements of these virtual machines are given along the dimensions of memory, CPU and network bandwidth. • We have to find a mapping between VMs and PMs that satisfies the VMs’ resource requirements while minimizing the number of physical machines used. While finding such a mapping, we have to take care that the total resource requirement of the VMs placed on a PM should not exceed its capacity. Also, we plan to include the information of affinity between two virtual machines while obtaining such a mapping. We also plan to handle the case of availability of only a restricted set of PMs for a given VM for placement.

3

RELATED WORK

Different approaches have been adopted in literature to address the problem of placement of virtual machines in modern data centers. While coming up with their plans for placement of virtual machines, these approaches try to address various criteria. These criteria range from the consideration of number of active physical machines and the cost of allocation to the level of SLA violations and so on. We discuss some of these approaches in this section. • Cost based consolidation: [10] and [12] address the issues of cost of allocation of resources while figuring out a placement plan. [10] proposes an optimal virtual machine placement algorithm which tries to minimize the cost spending in the reservation and on-demand payment plans generally offered by cloud providers. It views the provisioning 3

of resources in three phases: reservation, utilization and on-demand. The algorithm uses stochastic integer programming and works in two stages: the first stage calculates the number of VMs provisioned(demand) in the reservation phase and the second stage calculates the number of VMs allocated in both utilization and on-demand phases. It considers the set of all possible demands and prices, called realizations in general. Using these, an objective function and a set of constraints is developed considering the cost of resources charged by each provider in each phase, the probability of each demand being realized, the probability of each set of resource prices offered by each provider being realized. Decision (p) variables are Xij the number of VMs in class Vi to be allocated to provider Pj in phase p. Although this approach considers all possible demands and prices, we argue that it will not be scalable once the number of possible demands and prices goes high which is bound to happen in a real world scenario. Also, it ultimately formulates the problem as an integer linear program which is proved to be NP-hard [1]. So, this approach will not work with large problem sizes. [12] proposes an autonomic resource manager which pre-defines a set of Virtual Machine classes for applications to choose from. They propose a local decision module that measures each application’s satisfaction (called a resource level utility function) with the Virtual Machines allocated to it. Then, a global decision module evaluates these values coming from each application and tries to maximize a global utility function which also considers the cost of making the allocations. They do not, however, propose any specific cost function. These VM to application allocation vectors are then fed to another phase which uses a CSP to figure out a placement of these VMs onto Physical Machines so as to minimize the number of active PMs. Again, here the placement variables are modelled as binary which renders it unusable for large problem sizes. Another main drawback of their approach is that the VM sizes need to be discretized into specific VM classes. For a near accurate calculations, there should be many VM classes defined. But that would increase the number of variables in the constraints and hence increase complexity of their solution. • Consolidation based on number of active Physical Machines: [8] aims to minimize the number of active Physical Machines while coming up with a placement plan. It uses an Integer Linear Programming formulation to get a VM placement plan. They have proposed decision models for a static server allocation problem with and without variable workloads and also a dynamic server allocation problem which calculates allocation plans in individual time steps. However, all the decision models built by them have variables modelled as binary which again, may not work for large (and practical) problem sizes. • Load balanced placement: [13] proposes an algorithm called VectorDot which tries to determine the best choice of physical machines for relocation of virtual machines from overloaded nodes using dot products of capacity usage and resource requirement vectors. The dot product based fit implemented by us uses a similar technique but is tuned to do server consolidation instead of load balancing. • Placement for reduction in the level of SLA violations: [9] tries to provide a placement plan with minimum level of service level agreement violations. Their algorithm is based on measuring historical data, forecasting the future demand and then remapping the Virtual Machines to the Physical Machines given this information. Resource demands are predicted at regular intervals using resource demand data. These predicted values are used by a placement module to compute VM to PM mappings. This module uses first fit approximation.

4

From the above discussion, it is clear that while most of the approaches use some form of an LP formulation to get placement plans [10, 12, 8], they have formulated the decision variables as either integers or as binary variables which does not promise a scalable solution as we observe in section 4.1. This has motivated us to extend such an ILP formulation to consider fractional variables and then use approaches for rounding the resulting solutions so as to make it work for large problem sizes. Also, [13] presents a few heuristics like FirstFit, BestFit and WorstFit for load balancing, some of which could be tuned to serve our purpose of server consolidation. Bin Packing: In our work, we view the problem of placement of virtual machines in a data center as similar to a bin-packing problem. The individual physical machines can be considered as bins having different dimensions. These dimensions correspond to resource capacities of the physical machines in our case. Similarly, the virtual machines can be considered as objects to be packed into these bins. Again, for each virtual machine, the amount of resources required (dimensional requirements of objects) is specified. We have to find a mapping between these objects and bins such that the total number of bins required is minimized. Hence, due to the similarities of our problem with the bin-packing problem, we have adopted techniques like Linear Programming and First Fit which are typically used to solve traditional bin-packing problems, to solve our problem of VM Placement.

4

ALGORITHM DESIGN

The main inputs to our algorithms are the resource requirements of each virtual machine to be placed. To capture these requirements along various dimensions, we define a requirements matrix as follows:   r11 r12 ... r1d  r21 r22 ... r2d   Requirements M atrix =   : : : :  rn1 rn2 ... rnd

where each rij indicates the requirement of VM i along the dimension j. Currently, we consider three dimensions for our purposes: CPU, Memory and Network bandwidth used. Requirements along these dimensions are expressed as fractions of the total capacity of a PM (Appendix A). Given the resource requirements of virtual machines, an algorithm is expected to come up with a placement plan which gives a mapping of which virtual machine is to be placed on which physical machine. This placement plan given by an algorithm can be captured in the form of an ‘Allocation Matrix’ as follows:   x11 x12 ... x1m  x21 x22 ... x2m   Allocation M atrix =   : : : :  xn1 xn2 ... xnm

where each xij indicates whether VM i is placed on the physical machine j. So, xij will be 1 if VM i is placed on PM j, 0 otherwise.

5

To solve our problem, we essentially have to calculate this allocation matrix. For this, we implement an LP formulation of the problem and also define some heuristics. These solutions read the input requirements matrix in a specific format as given in appendix A. So as to have an ordered list of Virtual Machines, the requirements matrix is pre-ordered while reading from the configuration file.

4.1

LP Formulation

With reference to the matrices defined above, we can express the VM Placement problem in the form of an Integer Linear Program (ILP). Hence, we define the constraints that need to be satisfied during placement of virtual machines and write them in the form of inequalities: • Capacity Constraints: For each dimension of a given PM j, the sum of the resource requirements of all VMs placed on it should be less than or equal to the total available capacity: ∑ rik .xij ≤ 1 ∀k ∀j (2) i

where, rik is the fractional resource requirement of an individual VM i along the dimension k. For each PM, this inequality is created for each dimension. • Placement Guarantee Constraints: All virtual machines should be placed. So, for each VM i, exactly one of the xij ’s is expected to be one, and others 0. So we get the equation: ∑ xij = 1 ∀i (3) j

• Now, to be able to formulate the objective function, we associate a variable yj for each PM j as given below. yj will be either 0 or 1 depending on whether PM j has to be used or not. yj ≥ xij ∀i, j (4) • And the objective function will be: M inimize

∑

yj

(5)

Thus, summarizing the formulation: M inimize :

∑

yj

Subject to :

∑ i

ri .xij ≤ 1

∑

∀j

xij = 1

∀i

yj ≥ xij

∀i, j

j

Once we solve this, yj will tell us whether PM j is to be used or not, while the values of xij will give us the VM to PM mapping. We have used the open source linear programming tool, lpsolve [3], to implement this formulation.

6

NP-Hardness and need for LP Relaxation: When variables are modelled as binary, this problem is NP-hard [1]. Hence, although the ILP formulation gives an exact placement plan, it does not scale well with the increase in the number of Virtual or Physical Machines. Some quick experimentation revealed (table 1) that the time required to figure out a placement plan for as low as 20 VMs reached more than 8.5 hours! This is undesirable in a practical scenario. Table 1: Time taken for ILP Number of VMs Time taken 6 30ms 9 4110ms 10 4261ms 20 >8.5hrs (!)

To avoid this, we relax the constraint that each variable be 0 or 1 by a weaker constraint that each variable be fractional in the interval [0,1]. This technique is called LP Relaxation [2]. But using such a relaxation would mean we get the solutions to the LP as fractions (in the range [0,1]). Which means we will get solutions suggesting that different fractions of a virtual machine be allocated to different physical machines, which is undesirable. Hence, we will have to include techniques for rounding the resulting solutions (values of the decision variables) to 0 or 1.

4.2

Heuristics for VM Placement

Here, we define some heuristics for placement of virtual machines. These heuristics take one VM at a time and try to place it amongst a fixed set of Physical Machines. They mainly differ from each other in the way in which they choose Physical Machines to test for a possible placement. The algorithm 1 gives a generic algorithmic framework under which each of these heuristics fit in. In subsequent sections, we describe each of the heuristics in detail.

7

Algorithm 1 Require: Physical Machines: (double dimensions[], int pm id, vector vms placed[]) Require: Ordered Requirements Matrix: req matrix[] Require: List of Physical Machines and their current usages: PM[] Require: Order of visiting the Physical Machines: order of PMvisit[] 1: req matrix = readConfigFile() 2: for each VM i do 3: j=0 4: order of PMvisit = getOrder() 5: while VM not placed do 6: nextPM = order of PMvisit[j++] 7: place(req matrix[i], i, nextPM) 8: if number of PMs is finished and VM is not placed then 9: break loop 10: end if 11: end while 12: if placed then 13: update the alloc matrix 14: else 15: return null 16: end if 17: end for 18: return alloc matrix readConfigFile(): 1: Read VM requirements, no of dimensions, VMs and PMs from the config file. 2: Order req matrix in decreasing order of first column in req matrix followed by the second column if the first is same and so on. place(vm dim[], i, j): 1: for each dimension i do 2: add vm dim[i] to dimensions[i] of this PM 3: end for 4: if any dimensions[i] > 1 then 5: subtract vm dim[i] from dimensions[i] of this PM 6: return false 7: else 8: return true 9: end if As given above, we start by reading the virtual machine resource requirements and the number of physical machines available. The requirements matrix thus constructed is ordered according to its dimensions starting with the first dimension. Thus, we now have an ordered list of VMs and their requirements. Also, we maintain a list of Physical Machines and their current resource usages (initially zero). For each VM, we determine the order in which these Physical Machines should be considered for placement. The decision of what order to choose depends on the heuristic we use. This is explained in detail in the forthcoming subsections. Once we get this order, we visit the PMs in that order and check if the VM can be placed onto those PMs. If a suitable placement was found in this way, the allocation matrix is updated.

8

Otherwise, the inability to find a placement plan is flagged. Finally, if all the VMs are placed, the allocation matrix thus constructed gives the placement plan for the given input. In the following sections, we describe each of the heuristics in detail. 4.2.1

First Fit

This heuristic considers the Physical Machines in a sequential order for placement. That is, getOrder() method always returns the sequence {0,1,2,3,...}. Effectively, this tries to place the VM onto the first physical machine in the list that has enough space for it to fit. 4.2.2

Single Dimensional Best Fit

This heuristic visits the Physical Machines in a decreasing order of capacity used along a single dimension. That is, the Physical Machine which has the maximum of capacity used along the given dimension will be considered first. 4.2.3

Volume Based Best Fit

This visits the Physical Machines in the decreasing order of some function of capacity used along all dimensions. We have implemented this function as the product of the capacity usages, because multiplication is nearer to the real world concept of ‘volume’. 4.2.4

Dot Product Based Fit

Here, the requirements of the VM along the specified dimensions and PM capacity usages along those dimensions are expressed as vectors. Then, a dot product of these two vectors is taken for each PM. The PMs are visited in decreasing order of this dot product. 4.2.5

Load Balanced Fit

In this heuristic, we visit the Physical Machines in an increasing order of a function of capacity used along all dimensions. The volume function is used here too. Clearly, this heuristic tries to place VMs on Physical Machines with highest remaining capacity. And hence, effectively, it provides a placement plan which balances the load amongst the given set of Physical Machines, thus using more number of Physical Machines than the other algorithms. Therefore, we use this heuristic as a benchmark for comparison amongst the set of heuristics as explained in section 5.

5

EXPERIMENTAL EVALUATION

In this section, we present results of the experiments we have conducted. We try to analyse the heuristics we defined in section 4 to try and find out how they work in relation to each other. We also first conduct a few validation experiments. These experiments are described in the following sections.

5.1

Consolidation Validation

This experiment aimed at testing whether consolidation is taking place and whether the heuristics give valid consolidation plans. For each Virtual Machine, the requirement along any dimension was generated as a random number (uniform distribution) between 0.0 and a certain ‘cap’ (0.0 < cap ≤ 1.0). Five configuration files were generated each for a cap of 0.1, 0.2, 0.3, 0.4, 9

... 0.9 and 1.0. For each of the 10 types of configuration files, the average number of Physical Machines suggested by each heuristic was noted. The results are shown in the graph 1. Consolidation Validation Experiment 70 First Fit Single Dimensional Best Fit Volume Based Fit Dot Product Based Fit Load Balanced Fit

Number of Physical Machines

60

50

40

30

20

10

0 0.0-0.1

0.0-0.2

0.0-0.3

0.0-0.4 0.0-0.5 0.0-0.6 0.0-0.7 VM size cap per dimension

0.0-0.8

0.0-0.9

0.0-1.0

Figure 1: Consolidation Validation Experiment

As can be seen from the graph, as heavier VMs got included in the VM list, the number of Physical Machines used by the heuristics increased but this number was lesser than that used in a load balanced case. This indicates consolidation. Also, every placement plan given by any heuristic was validated against the set of constraints that we have defined in the LP formulation (constraints 2 and 3) since these are the conditions that should be true for any valid plan. We observe that all the placement plans are valid.

5.2

Algorithm Comparison-1

In this experiment, we planned to study how well do each of the algorithms work in relation to one another. For input datasets, we wanted to create a mix of CPU intensive, memory intensive and network intensive VMs. So, the VM requirements were generated as a mix of different ranges of uniformly distributed random numbers as follows: : 20 VMs : 20 VMs : 20 VMs Ten such configuration files of 60 VMs each were generated for input. In order to be able to differentiate between the algorithms, we define something called as a ‘packing factor’. For any given algorithm, the Packing Factor is defined as follows: P ackingF actor =

Average no. of P M s used by the algorithm Average no. of P M s used by Load Balanced F it

The lower the packing factor, the better is the algorithm with respect to consolidation. 10

(6)

The algorithms were run over the algorithm. 1 2 First Fit 41 42 Single-D Best Fit (dim 1) 41 42 Single-D Best Fit (dim 2) 40 41 Single-D Best Fit (dim 3) 39 40 Volume Based Best Fit 39 40 Dot Product Based Fit 40 40 Load Balanced Fit 60 60 Max difference (disregarding Load Balanced Fit)

2

2

input files and packing factor was calculated for each 3 38 38 33 34 33 34 60

4 36 36 35 35 35 35 60

5 39 39 37 37 36 36 60

6 40 40 36 35 35 36 60

7 40 40 38 38 37 37 60

8 40 40 36 38 37 38 60

9 39 39 38 38 38 37 60

10 40 40 37 35 36 35 60

Average

PackingFactor

39.5 39.5 37.1 36.9 36.6 36.8 60

0.66 0.66 0.62 0.62 0.61 0.61 1

5

1

3

5

3

3

2

5

3.1

The above table gives the output of all the 10 runs and the average number of Physical Machines used by each algorithm. Also, we calculated the maximum difference between the number of physical machines used by algorithms which consider all three dimensions for consolidation and those which do not. (We disregard load-balanced fit here because it takes all the machines and does not actually consolidate). We get this difference as high as 5 in some cases, which suggests an encouraging improvement. On an average, the algorithms which consider all the three dimensions took 3 Physical Machines less than the ones which do not.

5.3

Algorithm Comparison-2

This is an ongoing experiment, in which we aim to find out that out of a sufficiently large number of sets of input configurations of VMs, how many times does any particular algorithm work better than others. How better does it perform? Generally, which algorithm works best amongst all algorithms? Is there an algorithm which performs no better than the other algorithms? We generate thousand configuration files with virtual machine requirements distributed uniformly between 0.0 to 1.0. We run the algorithms over each of these configuration files and record the number of physical machines each algorithm took in each case. From this information, we calculate the number of times an algorithm performed better than others, i.e., the number of times it took lesser number of physical machines than others. We repeated the experiment for different ordering of virtual machines. The results are as follows: When the VMs are ordered in decreasing order of dimensions starting dimension 1, then dimension 2, then 3, the results are as shown in table below: Algorithm First Fit Single-D Best Fit (dim 1) Single-D Best Fit (dim 2) Single-D Best Fit (dim 3) Volume Based Best Fit Dot Product Based Fit Load Balanced Fit

# times performed better 0 0 73 74 209 42 0

Avg PackingFactor 0.73336 0.73304 0.70406 0.70383 0.69715 0.70155 1

When the VMs are ordered in decreasing order of volume, the results are as shown below:

11

Algorithm First Fit Single-D Best Fit (dim 1) Single-D Best Fit (dim 2) Single-D Best Fit (dim 3) Volume Based Best Fit Dot Product Based Fit Load Balanced Fit

# times performed better 0 26 40 42 0 30 0

Avg PackingFactor 0.68433 0.69006 0.68982 0.68996 0.68433 0.68456 1

From the above results, we can observe a few points. Firstly, FirstFit never performs better than any of the other algorithms. Secondly, apart from the order of PM visit, ordering of VMs also affects the packingFactor. Results show that VMs ordered by volume give better packingFactors. Lastly, volume based best fit generally gives lowest packingFactors amongst the algorithms. Some more analysis of the results is required here. Given the above results, we need to establish how better does an algorithm work in relation to the others. Also, we wish to create clusters of the input datasets for each algorithm containing cases for which it worked better. From these, we could be able to establish operating regions for each algorithm.

6

VIRTUALIZATION SCENARIOS

In this section, we describe some virtualization scenarios that can be added to the algorithms. These scenarios basically try to capture some virtualization specific requirements that may arise while placing Virtual Machine onto Physical Machines. These may be related to affinity or interference between virtual and physical machines. These scenarios are described in detail in the following sections alongwith thoughts on how we plan to implement these.

6.1

VM-VM affinity and Interference

There may be affinity between two virtual machines due to which they may be required to be placed together. There can be various possible reasons for such affinity. For example, the network traffic between two communicating VMs may suggest that they be placed together so as to reduce the network overheads. Or, there may be business constraints like the requirement of web-server and database layers to be together. There could also be interference between two VMs which requires that they should not be placed together. This may be due to technical constraints. For example, say there is a resource (some remote datastructure) mirrored at two places that two VMs need to access. The VMs are programmed to access the nearest resource. Now, there may be a technical requirement to keep the 2 VMs separately so that both do not access the same copy. Or there may be a disk contention: Two VMs trying to access the same data on disk. Interference can ofcourse also be due to business constraints like not keeping virtual machines of competitors together. Or, so that one of the virtual machine remains available even if the physical host hosting the other VM fails. 6.1.1

Capturing Affinity and Interference

Affinity Matrix To capture affinity/interference between two VMs, we define a VM x VM affinity matrix. For example:

12

VM ids VM1 VM2 VM3 VM4 VM5

VM1 0.0 0.3 -0.6 0.9 0.2

VM2 0.3 0.0 0.8 -0.3 0.5

VM3 -0.6 0.8 0.0 0.4 -0.7

VM4 0.9 -0.3 0.4 0.0 0.3

VM5 0.2 0.5 -0.7 0.3 0.0

The ‘affinity’ and ‘interference’ are considered as opposite concepts. In the above matrix, a negative value indicates interference. The magnitude of this value is the magnitude of interference. The numbers in this affinity matrix indicate the level of affinity/interference between two VMs. These numbers can be captured by measuring the factors because of which the VMs are affine or interfere with each other. For eg, affinity can be the ratio of the amount of traffic flowing between two VMs to the total amount of traffic of the two VMs. Interference between two VMs accessing the same resource can be the ratio of total number of accesses to the resource by the two VMs to the total number of accesses to all resources required by the VMs. Consolidation Function The consolidation function c() of a Physical Machine indicates the preference of this PM for placement of the given VM based on the base-algorithm requirements. (So, for volume based algorithm, this is the product of resources used on the PM, and so on). While calculating this, we can include any given alternate co-location based requirements of the VMs involved. Affinity Function The affinity function a() describes the cumulative affinity of the VM to be placed towards the VMs already placed on the PM in consideration. In other words, this is the summation of affinities between the VM to be placed and the VMs already placed on the PM. Heuristic Function The heuristic function f() is the addition of the consolidation function c() and the affinity function a(): f() = c() + a(). This value will decide the order of PM visit. PMs will be visited in descending order of f() values. Thus, the f() value of a Physical Machine basically indicates the attractiveness of this Physical Machine for the placement of the VM in consideration. If we observe closely, the consolidation function c() already measured the attractiveness of each PM for placement of a VM. By adding the affinity function a(), we try to alter this attractiveness to consider affinity too. Hence, the function f() now represents the degree of attractiveness of a PM for placement of the VM, considering its affinity with the VMs already placed on that PM.

6.2

VM-PM affinity

In addition to affinity between two Virtual Machines, there may be a requirement to place a particular VM i onto one out of a restricted set K of k servers, e.g., running a certain operating system. • This can be done by accepting a ‘VM-PM-mapping-prerequisite matrix’ from the user. • Eg.:

13

Ids VM1 VM2 VM3 VM4 VM5

PM1 1 0 1 1 0

PM2 1 1 1 0 1

PM3 0 1 1 0 1

PM4 1 0 1 0 1

PM5 0 0 1 0 0

A ‘1’ in the above matrix indicates that the corresponding Physical Machine belongs to the pool of Physical Machines to be considered for placement of the corresponding VM. A ‘0’ indicates the opposite. • While obtaining the order in which the Physical Machines are to be visited for a given VM, we may go about in the following way: – PM[] = List of PMs to be considered for placement according to the above matrix. – An order to visit PMs from PM[] can be decided using any of the placement algorithms. • The modification required in our present scenario would be that instead of assuming the same set of Physical Machines while deciding the order of PM visit for each VM, now we have a different set everytime.

7 7.1

LOOKING AHEAD LP and rounding approaches

As mentioned in section 4.1, modelling the variables in LP as binary makes the problem NPhard. Hence, in the next stage of the project, we plan to model these variables as fractional in the interval [0,1]. Strategies to round up the resulting fractional solutions need to be adopted here which could possibly also address some of the virtualization scenarios mentioned in section 6.

7.2

Removing the homogeneity assumption

Currently, we assume, for simplicity, that all the Physical Machines are homogeneous in terms of their resource capacities and accept the input virtual machine requirements as fractions of those capacities. However, this assumption may not hold for large data centers with hundreds of machines where it is difficult to ensure Physical Machine homogeneity. Hence, we also plan to extend the solution to consider such heterogeneity.

7.3

Using Synthetic Datasets

In our experiments, we have generated the datasets using random numbers independently for each resource dimension. However, in practical scenarios, resource usages may actually be interdependent. Hence, it would be interesting to use datasets gathered from actual virtual machines by deploying synthetic workloads. For this, we need resource usage traces of virtual machines for different types of workloads like CPU/memory/network intensive and combinations of these. We are in the process of gathering these numbers. Data for 100 VMs each of Network intensive, CPU + Memory intensive, Memory + Network intensive, CPU + network intensive, CPU + memory + network intensive has been collected. After gathering this data, we plan to use these datasets for our analyses. 14

7.4

Integrating the output into a Cloud Controlling software

Finally, we plan to integrate these approaches into a cloud controlling software which controls VM creation, destruction and migration. The placement plan given by an algorithm will be used by the tool to trigger VM starts accordingly.

8

CONCLUDING REMARKS

To solve the problem of Virtual Machine placement in data centers, we have presented few placement algorithms. An ILP-based approach gives us an exact solution but does not promise obtaining the solution in practically acceptable times. Also, heuristics like first fit, single dimensional best fit, volume and dot product based fits have been implemented which give valid placement plans in acceptable times. We observe that of these heuristics those which consider all three dimensions for their placement decisions perform better than those which do not. Also, we find that first fit which is widely used in today’s data centers never performs better than any of the other algorithms. We also see that volume based best fit gives the lowest packingFactors amongst the algorithms and hence it provides the highest amount of consolidation.

15

A

Appendix

Configuration File: To be able to read the inputs like the requirements matrix and the number of Physical Machines available, we use a configuration file. We define a specific format for the configuration file as given below. This acts as the input to all our algorithms. Dimensions: VMs: PMs: Matrix: .. .. .. .. .. .. (where under ‘Matrix’, the Requirements Matrix is to be specified) Sample Requirements Matrix: A sample requirements matrix is shown below:  0.2 0.4  0.2 0.4   0.6 0.2 0.6 0.2

 0.3 0.5   0.3  0.5

In this matrix, each row corresponds to one virtual machine’s requirements along the dimensions of CPU, memory and network I/O. For example, the first row specifies that the corresponding VM uses 20% of CPU, 40% of memory and 30% of network capacity of a physical machine.

16

References [1] http://en.wikipedia.org/wiki/0-1 integer programming#integer unknowns. [2] http://en.wikipedia.org/wiki/linear programming relaxation. [3] http://lpsolve.sourceforge.net/5.5/. [4] http://www.linux-kvm.org/page/main page. [5] http://www.slideshare.net/topline/virtualization-business-case. [6] http://www.vmware.com/products/datacenter-virtualization.html. [7] http://www.xen.org/. [8] Martin Bichler, Thomas Setzer, and Benjamin Speitkamp. Capacity Planning for Virtualized Servers. Presented at Workshop on Information Technologies and Systems (WITS), Milwaukee, Wisconsin, USA, 2006. [9] Norman Bobroff, Andrzej Kochut, and Kirk A. Beaty. Dynamic placement of virtual machines for managing SLA violations. In Integrated Network Management, pages 119–128. IEEE, 2007. [10] Sivadon Chaisiri, Bu-Sung Lee, and Dusit Niyato. Optimal virtual machine placement across multiple cloud providers. In Markus Kirchberg, Patrick C. K. Hung, Barbara Carminati, Chi-Hung Chi, Rajaraman Kanagasabai, Emanuele Della Valle, Kun-Chan Lan, and LingJyh Chen, editors, APSCC, pages 103–110. IEEE, 2009. [11] Chris Hyser, Bret Mckee, Rob Gardner, and Brian J Watson. Autonomic virtual machine placement in the data center. Technical report, HP Labs, 2008. [12] Hien Nguyen Van, Frederic Dang Tran, and Jean-Marc Menaud. Autonomic virtual resource management for service hosting platforms. In CLOUD ’09: Proceedings of the 2009 ICSE Workshop on Software Engineering Challenges of Cloud Computing, pages 1–8, Washington, DC, USA, 2009. IEEE Computer Society. [13] Aameek Singh, Madhukar Korupolu, and Dushmanta Mohapatra. Server-storage virtualization: integration and load balancing in data centers. In SC ’08: Proceedings of the 2008 ACM/IEEE conference on Supercomputing, pages 1–12, Piscataway, NJ, USA, 2008. IEEE Press. [14] Benjamin Speitkamp and Martin Bichler. A mathematical programming approach for server consolidation problems in virtualized data centers. IEEE Transactions on Services Computing, 99(RapidPosts), 2010.

17