59

CHAPTER 3

CLOUD GRAPH THEORETICAL WORKFLOW

MODEL AND PROPOSED ALGORITHMS

3.1 INTRODUCTION

In Cloud Computing, the Infrastructure as a Service (IaaS) layer,

the servers are distributed in nature and a set of analytical strategies are

required to study the layer in detail. This work focuses on IaaS Cloud

environments, e.g., Amazon EC2, where multiple independent users

dynamically provision VMs and deploy various types of applications. Cloud

provider should be able to handle variable workloads since it is not aware of

the nature of the workload. Since multiple workloads are possible, the types

of applications that can coexist are mixed in nature, a combination of High

Performance Computing (HPC) and Cloud load types. Response time and

throughput are valid for a specific set of situation where it defines the Energy

scheduling strategy. In this chapter we present the analytical strategies, a

graphical workflow analysis of the cost and performance characteristics of

algorithms. We discuss the basic structure of the Cloud Data Center by

analysing the arrival and service rates of the VM to an host. Workflow

analysis with the focus on the response time calculation is necessary for

proposing an algorithm, since the response time directly relates to the

efficiency of an algorithm. So it is necessary to analyze the VM

characteristics based on the response time characteristics. The Response time

characteristics are studied by a Multi-informative analysis of the problem of

energy and performance efficient dynamic VM consolidation. The response

60

time of the VM is taken into consideration and various algorithms have been

tested, proved and presented for its merits and demerits. To minimize energy

consumption one way is to switch servers dynamically to the sleep mode

since energy consumption is the major component of operating costs.

Switching servers randomly is not a viable option. Identifying the hosts and

dynamically consolidating the executing VMs is the solution for the Energy

Performance trade-off issue.

3.2 MOTIVATION

To address the above mentioned issues, we propose a Cloud

Graphical Workflow Model (CGWM). From the CGWM we intend to

analyze the VM by response time characteristics and find Cloud Workload.

From the Workload information we have proposed RAM based Host

Oversubscription (RHO) and RAM based VM selection (RVS) techniques.

The methodology proposed in this postulation oversubscribes the server CPUs

by exploiting data on the continuous CPU usage; then again, it doesn't over-

commit RAM. In this work, the significant measure of RAM that could be

depleted by a VM is utilized as an imperative when putting VMs on servers.

One of the purposes behind is that RAM is a more discriminating asset

contrasted and the CPU, as a provision might fizzle because of inadequate

RAM. The inadequacy CPU might only ease off the execution of the

requesting VM failure. In a CPU, RAM generally does not turn into a

bottleneck resource, and consequently, does not restrict the amount of VMs

that could be instantiated on a server, as demonstrated in the research

literature. Hence in the proposed algorithms we consider RAM behaviour of

VM as an important factor. An alternate perspective recognizing the work

introduced in this proposal is modeling the design of the VM administration

framework. A viable VM administration framework is vital for extensive

scale Cloud suppliers, as it empowers the characteristic scaling of the

61

framework when new process hosts are included. An outline of the

significance of versatility is the way that Rackspace, a well-known IaaS

supplier, has expanded the aggregate server number in the second quarter of

2012 to 84,978 up from 82,438 servers at the close of the first quarter. An

alternate profit by making the VM administration framework conveyed is the

enhanced blame tolerance by taking out single purposes of washout:

regardless of the fact that a process or controller host (or) provider fizzles, it

might not render the entire Cloud framework inoperable. Advanced resource

monitoring, analysis, and configuration tools can help address these issues,

since they bring the ability to dynamically provide and respond to information

about the platform and application state and would enable more appropriate,

efficient, and flexible use of the resources. Additionally such tools could be of

benefit to Cloud providers, users, and applications by providing more efficient

resource utilization in general.

Figure 3.1 Time - Space relation in a processing element

Our Cloud comprises of M heterogeneous processors. Jobs arrive at

in an irregular manner, the inter arrival time is exponentially appropriated

with an average of 1/ . The jobs are accepted to require service time time

exponentially dispersed by a mean 1/ . Job size includes program and data

62

size under normal distributed nature with a given mean and variance. The jobs

here are the Cloudlets in VM which dwells in hosts according to the

requisition. The Cloudlets (or) jobs consolidate VM residing in a host to

analyze the host oversubscription and underused host in a cloud datacenter.

The workload data of the VM is essential to solidify the host over-burdening

and underused servers in the data center. The Cloud assets are geographically

dispersed and our scheduler enactments as a medium between the Cloud

clients and the suppliers. In view of the accessibility of assets the scheduler

happens with the submissions of jobs and to maintain equilibrium to fulfil the

SLA (Subrataet al 2008). Data center overhauls the data of its assets and they

are hard real runtime of servers where execution time is inversely

proportional to CPU working instances (Garget al 2009).

Figure 3.2 Complexity of finding resource and data-host match for a single job in a Cloud Workflow

Scheduling of the jobs in the workflow essentially concentrates on

a sum of the machine capacities and consolidation of them: minimizing the

sum is vital, minimizing the generally speaking cost (monetary cost) of

execution and data transfer, executing within the deadline and allocated

63

budget. The mapping of the workflow jobs to minimize one of the objective

functions is a complex sub-problem of the general job scheduling problem.

The issue comes to be intricate with the expansion of imitating data sets with

jobs needing more than one file. Figure 3.2 presents the many-sided quality of

finding resources and data sets matched for a solitary job in a Cloud

environment. In Fig. 3.2, "a job" requires data cloudlets. These

information cloudlets are reproduced on data hosts. This gives us

conceivable sets of data set. Assuming that we have compute hosts, the

total conceivable asset might be . A lookup table arranges the total

number of syntheses conceivable for shifting number of cloudlets with settled

number of data hosts and compute hosts (Liu & Anderson 2011). The point

when the cloudlets are reproduced and a solitary job requires more than one

resource, the amount of correlations required to go to the best result (a

consolidation that gives a set of data hosts and compute hosts) increases. The

point when subordinate jobs are available, the issue of discovering the blend

of data hosts and compute hosts set turns into a non-trivial issue. This basic

issue comes to be remarkably perplexing when there are demands included,

such as heterogeneous resources, network costs, storage constraints, etc.

Before defining and analysing the algorithms, this chapter first

presents a workflow model and a resource model.

3.3 CLOUD GRAPHICAL WORKFLOW MODEL

We now describe the problem of data host selection and jobs to

resource mapping in the presence of large number of replicated cloudlets for

workflow applications.

Definition: CJSP (D,R,T,F,G,L,M) Given a set of resources R, a set

of jobs T, a set of cloudlets F (both input and output cloudlets of T), a graph

G that represents the data flow dependencies between jobs T, the Cloud-Job

64

Scheduling Problem (CJSP) is a problem of finding assignments of jobs to

compute-hosts [job schedule ={ } T, r R], and the partial data set

( = { } ) to be transferred from selected data-hosts to assign

compute hosts = {{ }( , r R, |{ }| |R|}

for each job, simultaneously, such that: total execution time (and cost) at r and

data transfer time (and cost) incurred by data transfers { }for all the

jobs are minimized.

This chapter assumes the following pre-conditions that are

associated with definition:

1. Data cloudlets are replicated across multiple data hosts in a

data center

2. Each job requires more than one data file of the Cloud

application

3. Total time and cost are bounded by L and M, respectively,

where L signifies the end time and M denotes the maximum

amount that can be spent on executing all the jobs in T of a

cloud-flow graph G.

A workflow is represented by a directed acyclic graph = ( , ),

where = { , , … } and E represent the vertices and edges of the graph,

respectively (Kwok & Ahmad, 1999). Each vertex represents a job t and there

are n jobs in the workflow. The edges maintain execution precedence

constraints. We define edges in Cloud Datacenters as Data dependency and

largely forms a subset of Latency and Bandwidth of the underlying network.

Having a directed edge from to , x, y N means that cannot start to

execute until is completed. The components are described as a set of

job = { , , … , }, set of cloudlets = { , , … , }, set of Hosts and

65

Resource (Datacenter) = { , , … }. A job requires a set of Cloudlets

= { , , … , } to be staged in for execution. Each cloudlet required by

a job is hosted by multiple data-hosts. Partial segments of each file

that need to be transferred for a job assigned to a data center r is

denoted by a set = {{ }( ,r R, }|

|R|}.

This chapter does not consider conditions cycles in the workflow

structure. This leads to an assumption that the cycles and conditions in the

workflow can be represented in the form of a Directed Acyclic Graph (DAG)

for the scheduling system to execute them, whenever necessary. To simplify

the problem for understanding, it can be broken down into two stages. To

begin with, a set of data that has the needed cloudlets for the jobs in the

workflow ought to be discovered. The choice of the optimal set of data has to

be in the vicinity of the extensive number of repeated cloudlets for a single

work. This choice of the set with optimal number of cloudlets gives a solution

to solve a set-coverage aspect.

There are just three exceptional cases for which there exist optimal

polynomial-time calculations.

These cases are:

1. Scheduling tree-organized work diagrams with uniform

reckoning expenses on a discretionary number of servers;

2. Scheduling self-assertive work diagrams with uniform

processing expenses on two Hosts; and

3. Scheduling an interim requested job development. In any case,

these results expect correspondence between jobs to take a step

back.

66

The mapping of jobs in a workflow to the resources in our case is

fundamentally unique in relation to the general mapping issue. Given the

repeated cloudlets and various data hosts, fitting choice of data hosts and

compute hosts ought to be made for each job in the workflow such that the

subordinate jobs will profit from determining set of its parents. The best case

is the point at which every job gets the optimal information data host and

compute host for execution so the make span and expense are optimal. The

naive case is when the resource set is chosen irrespective of the dependencies

for each job.

Figure 3.3 Graph Components in a Cloud Workflow System

Figure 3.3 shows a simple workflow with compute-hosts and

data-hosts , assigned to each job (the separation of data-hosts and compute-

hosts are for clarity only). We first consider the information exchanges

happening because of the determination of compute hosts and data hosts for

job ‘a’ and job ‘c’. Since the jobs are mapped to two distinctive compute

hosts, the yield cloudlet from job ‘a’ need to be exchanged between the two

processes has an expense of time and cost with it. Job ‘a’ has cost and job

67

‘c’ has cost for transfer between two data host based on space shared

policy. Therefore the optimal result might select a mix compute and data host

to minimize the bandwidth cost and execution time (Fakhar et al 2012). The

main strategy is by acknowledging the closeness of data host as far as system

separation with the set of compute hosts. The second strategy is by attempting

to amplify the co-connection between two set of data hosts, for some set of

jobs that require same set of cloudlets. The foremost strategy dependably

seeks the whole set of data hosts and compute hosts to discover one combo

that fulfils the destination capacity. However, it doesn't consider that jobs

could be offering the same set of cloudlets. Also, past emphases may have as

of recently discovered the data host and process host set consolidation that

could be connected an ensuing set of jobs. Case in point jobs ‘a’ and ‘c’ could

be needing same set of cloudlets, so the register concentrated determination of

competitor data host sets and compute host might be stayed away from for the

second occupation. The second way might practically select the same set of

data host by attempting to expand their co-connection. In the recent case,

when the amount of jobs increments, both the compute hosts and data hosts

got over-burdened, as the vast majority of the jobs are mapped to these

restricted resources. This expands the waiting time of all jobs mapped to these

resources. Subsequently a legitimate determination calculation might as well

convey the burden and fulfil the destination capacity. We propose the multi-

informative VM analysis to estimate the Cloud Workload. Next we limit the

consolidation of VMs by our proposed algorithms within the stipulated

response time. This helps in an efficient solution of Efficient Energy strategy

in Cloud Data Center.

3.3.1 Multi-informative VM Analysis

A workflow’s makespan and overall cost depends on the selection

of data sources and mapping of jobs to resources. Selection of ‘best’ data

68

sources before irrespective of compute sources, as is done in existing

scheduling algorithms, does not give time and cost efficient schedules when

the size of data is comparatively larger than the computation time of jobs.

Significant bandwidth is required to stage-in and stage-out these data prior to

the execution of the jobs in a workflow. Similarly, if the data is to be re-used,

the scheduling policy must select nearer (in terms of network distance)

compute resources as selecting them affects the time/cost of transferring

output data, and hence the overall execution time/cost. If the compute host

and data-host are closer in terms of network distance, the transfer time is

significantly reduced. The challenges that need to be faced are:

1. How to select data hosts and compute hosts such that the job-

resource mappings give a schedule that optimizes overall

Energy, Time and SLAV?

2. How to estimate cloudlet execution time and data-transfer

times by the workload information?

3. How to adjust job-resource mappings to fit the execution

environment at run-time?

To solve the aforementioned challenges from the Workload

information we analyze VMs and then propose VM consolidation algorithms

for an environmentally sustainable data center. The distribution of the

cloudlet on a VM to be efficient is necessary and VM analysis has to be done

for better scheduling. The temporal validity based on the timing constraints of

SLA should be modelled in order to study it on an energy perspective. Hence

from the arrival and service rates we define the multi-informative VM on a

host and how Energy curve is developed through SLA and VM migration.

The objective is to finish the workload in an estimated double threshold

(avg. response time), thus indicating the accountability of the metric based on

69

application performance rather than the infrastructure performance. The

equilibrium of the workload is maintained to achieve SLA. Since response

time and throughput are the major criteria of purpose in SLA. The response

time based analysis helped to find a better way for scheduling to maximize

throughput as shown in Figure 3.4.

Figure 3.4 Server Load (Courtesy: www.eventsratio.org)

We decided to analyze VM scheduled for MIPS in Host based on

the response time. Energy Consumption increases when the Response time

increases. It is necessary to efficiently handle VMs before the Response time

becomes unacceptable. This reduces the SLA violation. VM migration and the

reduction in SLA violation will in turn reduce Energy consumption. Hence in

this section we analyze the response time of VM and propose VM selection

and Host Oversubscription consolidation Algorithms.

The VM arrival rate and service rates for cloud workload to a

cloud provider are such that,

70

> (3.1)

where arrival rate is greater than the service rate

In order for stability

< (3.2)

where is the number of Host (or) CPU.

The total arrival rate should be less than the total service rate as in

Equation (3.2)

The set of VMs where cloudlets have been executed is a workload

and VM migration takes place with a Host alive for service transaction.

Average response time is given by Equation (3.3)

= 1/ ( ) (3.3)

Where is the number of VM

= time at which VM arrives

= time at which VM leaves the system

The cloud scheduler admits more VM and maintains a SLA based

on and least and scheduled to hosts with min deadline andwith

maximum free processing availability. We propose the workload aware

placement model for VM to a host so that VM selection can be consolidated.

For every estimated workload interval load estimation( , )

is taken. Each host calculates its period at instant as shown in Equation

(3.4)

( ) = ( ) + (1 ) (3.4)

71

here = probability of possible arrival rate

( ) being Estimated arrival rate for cloudlet at time

Actual number of jobs (VM) arrive on host at time

( ) = ( ) + (1 ) (3.5)

here = probability of possible service rate

( ) being Estimated service rate for cloudlet at time

Actual number of jobs (VM) depart from host at time

( ) = ( )/ ( ) (3.6)

Hence from Equation (3.7) we get the Workload on VM,

, ( + ) = ( ) ( )( ) ( )

(3.7)

where i=1,2,3,………..m-1.

( ) Expected numbers of jobs (VM) arrive at a host with a

processing capacity to finish processing of a cloudlet at time

( )Expected numbers of jobs (VM) depart from a host with a

processing capacity to finish processing of a cloudlet at time

The workload information as shown in Equation (3.7) is calculated

to know the status of the scenario to be evaluated and therefore schedule it to

a free processor. The workload information lets us know the Response time of

the VM in an instant of time.

Minimum of (3.8) is the objective for the workload information.

( ) =

72

such that

( ( ( ) )( ( ) ) / )! 1 (3.8)

where is the arrival rate estimation factor

( ) =

such that

( ( ( ) )( ( ) ) / )! 1 (3.9)

where service rate estimation factor

( . . ) (3.10)

The type of VM and the cloudlet in VM , involved has to be

analyzed to form coalesce. A workload coalesce in a data center is a set of job

scheduler successful if = isexecutedon as { |

w}, where w is a condition which states that jobs are executed on a FREE

processor or host.

= | w} (3.11)

T = { t + t } (with service and reply time factor)

T = { t }(with arrival time factor)

Then the workload response time is

= (3.12)

Assuming in a data center available is the maximum

availability of processing capacity is given by calculating , ( + )and

73

the is not active or no available active hosts due to variable

dimensions on a status of Hosts in a data center. The min TR subject to

(3.13)

where, = =

If free host is not available then the host should be found with no

job running on it. For generosity we define T = 0 and min given by

min = { {( )}, (3.14)

where, = 0if = 0; 1ifF > 0

The abundance of workload information for a cloudlet on a VM

caters to need of a processor where the success rate of the application to be

executed gets higher, provided the processor is active. Equation (3.15) gives

the maximum profit in the processing of VM with a available host, Maximum

profit can be obtained by finding the alive hosts and with maximum free

processing availability. Processing time factor is the sum of reply rate and

service rate factor + . Hence maximum profit is given by

Max{T } (3.15)

where = { {( )}

where, = 0if = 0; 1ifF > 0, the processing time factor.

From the available workload information we have to decide the

purpose of the algorithm to schedule VMs. VM consolidation is done to

minimize the number of active physical hosts, the individual inter-migration

time interval has to be maximized since in a time of frames the mean

74

number of hosts that are alive is inversely proportional to the efficiency of

VM consolidation. The system responses have been made more precise and

efficient to manage the fluctuating cloud traffic scenario. We have our data

centers broker and cloudlets created followed by identification of utilization

values of all hosts. If any of these utilization values exceed statistically

determined value of threshold utilization host is declared as overloaded. The

overloaded hosts assign an array namely Hoj. VM consolidation techniques

have been introduced at VM selection level and host oversubscription

detection level. Algorithms RHO has been implemented in host

oversubscription detection part and RVS have been implemented in VM

selection part. These algorithms and the statistical analysis involved in each

are discussed here. Before explaining our algorithm we discuss on the existing

methods (or) legacy procedures to harness a data center for VM consolidation.

3.4 LEGACY METHODS

3.4.1 Median of Absolute Deviation

The idea is to produce estimators that are not exorbitantly

influenced by small departures from model surmises. The Median of Absolute

Deviation (MAD) is a measure of statistical dispersion. It is a more robust

estimator of scale than the sample variance or standard deviation, as it carries

on better with disseminations without a mean or change, for example the

Cauchy distribution. The MAD is a robust statistic, being more flexible to

outliers in a data set than the standard deviation. In standard deviation, the

distances from the mean are squared leading to large deviations being on

normal weighted all the more vigorous. This implies that outliers might

altogether impact the quality of standard deviation. In the MAD, the extent of

the separations of a minor number of outliers is superfluous. For a uni-variate

data set, the MAD is outlined as the average of irrefutably the deviations from

75

the average of the information set, that is, the MAD is the average of

unquestionably the qualities of deviations (residuals) from the information's

average. In the proposed oversubscription identification calculation, the CPU

usage limit is demarcated. Parametrical evaluation has been carried out, the

parameters permits the conformity of the security of the system: an easier

quality of effects in a higher tolerance to variety in the CPU usage, while

potentially expanding the level of SLA violations brought about by the

consolidation.

3.4.2 Interquartile Range

This section proposes a method for setting an adaptive CPU

utilization threshold based on another robust statistic. In descriptive statistics,

the Interquartile Range (IQR) (Beloglazov & Buyya 2012), also called the

Mid-Spread or Middle Fifty is a measure of statistical dispersion. It is equal to

the difference between the third and first quartiles. Unlike the (total) range,

the interquartile range is a robust statistic, having a breakdown point of 25%,

and thus, is often preferred to the total range. For a symmetric distribution

(i.e., such that the median equals the average of the first and third quartiles),

half of the IQR equals the MAD.

3.4.3 Local Regression

The next heuristic is based on the Loess method (from the German

loss – short for local regression) proposed by Cleveland (1979). The main

idea of the local regression method is fitting simple models to localized

subsets of data to build up a curve that approximates the original data. The

observations (xi, yi) are assigned neighbourhood weights using the tri-cube

weight function the weight function gives the most weight to the data points

nearest the point of estimation and the least weight to the data points that are

76

furthest away. The use of the weights is based on the idea that points near

each other in the explanatory variable space are more likely to be related to

each other in a simple way than points that are further apart. Following this

logic, points that are likely to follow the local model best influence the local

model parameter estimates the most. Points that are less likely to actually

conform to the local model have less influence on the local model parameter

estimates. The traditional weight function used for LOESS is the tri-cube

weight function as shown in Equation (3.16),

( ) = (1 | | ) [| | < 1] (3.16)

However, any other weight function that satisfies the properties

listed in (Cleveland & Loader 1996) could also be used. The weight for a

specific point in any localized subset of data is obtained by evaluating the

weight function at the distance between that point and the point of estimation,

after scaling the distance so that the maximum absolute distance over all of

the points in the subset of data is exactly one.

The distance from to , and let ( )( ) be these distances in

order from most modest to biggest. At that point, the neighbourhood weight

for the perception ( , ) is described by the weight ( ). For such that

( ) < ( ) , where is the amount of perceptions in the subset of

information limited around . The measure of the subset is described by a

parameter of the strategy called the Bandwidth. For instance, if the level of

the polynomial fitted by the strategy is 1, the parametric group of capacities is

y = a + bx, y is the CPU utilization which is a dependent variable and x being

time is the independent variable. The line is fitted to the information using the

weighted least squares strategy with weight ( ) at( , ). The qualities of

a and b are considered by minimizing the capacity. In the proposed

calculation, this approach is connected to fit a pattern polynomial to the final

77

observation of the CPU utilization, where = [ /2]. A polynomial is fit

for a single point, the last observation of the CPU utilization (i.e., the right

limit of the data set). The problem of the boundary region is well-known as

leading to a high bias. According to Cleveland, fitted polynomials of degree 1

typically distort peaks in the interior of the configuration of observations,

whereas polynomials of degree 2 remove the distortion but result in higher

biases at boundaries. Hence, for host overload identification, polynomials of

degree 1 are decided to lessen the bias at the boundary. Let be the final

perception, and be the kth perception from the right boundary. In the

proposed Local Regression (LR) algorithm, using the described method

derived from Loess, a new trend line is found for each new observation

(Beloglazov & Buyya 2012). This trend line is used to estimate the next

observation. If the inequalities are satisfied, the algorithm detects a host

overload, requiring some VMs to be offloaded from the host and any of the

VMs allocated to the host.

3.4.4 Robust Local Regression

The version of Loess is vulnerable to outliers that can be caused by

heavy-tailed distributions. To make Loess robust, Cleveland (1979) proposed

the addition of the robust estimation method bi-square to the least-squares

method for fitting a parametric family. This modification transforms Loess

into an iterative method. The initial fit is carried out with weights defined

using the tri-cube weight function.

Using the estimated trend line, the method described in Section

3.4.3 is applied to estimate the next observation. If the referred inequalities

are satisfied, the host is detected to be overloaded. This host algorithm is

denoted Local Regression Robust (LRR).

78

3.4.4.1 VM Selection

Once a host overloading is detected, the next step is to select VMs

to offload from the host to avoid performance degradation. This section

presents three policies for VM selection.

3.4.4.2 The Minimum Migration Time Policy

The Minimum Migration Time (MMT) policy migrates a VM v that

requires the minimum time to complete a migration relatively to the other

VMs allocated to the host. The migration time is estimated as the amount of

RAM utilized by the VM divided by the spare network bandwidth available

for the host j. Let Vj be a set of VMs currently allocated to the host j. The

MMT policy finds a VM v that satisfies the conditions formalized.

3.4.4.3 The Random Selection Policy

The Selection Choice (RS) policy randomly selects a VM to be

migrated from the host according to a uniformly distributed discrete random

variable, whose values index a set of VMs allocated to the host j.

3.4.4.5 The Maximum Correlation Policy

The Maximum Correlation (MC) policy is based on the idea

proposed by Verma et al (2009). The idea is that the higher the correlation

between the resource usage by applications running on an oversubscribed

server, the higher the probability of the server oversubscription. According to

this idea, those VMs are selected to be migrated that have the highest

correlation of the CPU utilization with the other VMs. To estimate the

correlation between the CPU utilization of VMs, the multiple correlation co-

efficient is applied. It is used in multiple regression analysis to assess the

quality of the prediction of the dependent variable. The multiple correlation

79

coefficient corresponds to the squared correlation between the predicted and

the actual values of the dependent variable. It can also be interpreted as the

proportion of the variance of the dependent variable explained by the

independent variables. A set of random variables represent the CPU

utilization of VMs allocated to a host. The objective is to evaluate the strength

of the correlation between remaining random variables. An augmented matrix

containing the observed values of the independent random variables is the

vector of observations for the dependent variable. The matrix is called

augmented because the first column is composed only of one. A vector of

predicted values of the dependent random variable is obtained. Having found

a vector of predicted values, it is now possible to compute the Multiple

Correlation Co-efficient, which is equal to the squared coefficient of

correlation between the observed values of the dependent variable and the

predicted values.

3.5 RAM BASED HOST OVERSUBSCRIPTION (RHO)

One of the simplest overload detection algorithms is dependent

upon a thought of setting a CPU utilization limit recognizing the non-over-

loading and over-loading status of the host. The point when the calculation is

summoned, it thinks about the present CPU utilization of the host with the

characterized edge. In the event that the edge is surpassed, the calculation

distinguishes a host over-loading. This section presents a heuristic algorithm

for auto-adjustment of the utilization threshold based on statistical analysis of

historical data collected during the lifetime of VMs. The algorithm applies a

robust statistical method, which is more effective than classical methods for

data containing outliers or coming from non-normal distributions. The

proposed adaptive-threshold algorithm adjusts the value of the CPU

utilization threshold depending on the strength of the deviation of the CPU

utilization. The higher the deviation, the lower the value of the upper

80

utilization threshold. This is explained by an observation that a higher

deviation increases the likelihood of the CPU utilization reaching 100% and

causing an SLA violation.

In this chapter we propose an efficient energy aware technique by

combination of two techniques RHO and RVS and we consolidate based on

RAM for an efficient energy analysis in a data center using Local Regression.

In recent cloud computing research the data center analysis is done in

performance and thermal analysis and better energy efficient techniques have

to be implemented. We consider a data center with number of hosts and

allocate VMs to each host according to the kind of applications or work load

fed to the system. The system load can be defined by the kind of PlanetLab

workload that we have fed in the sample code using CloudSim simulation

software. Here we have analyzed a situation involving number of hosts each

host having a capability of holding number of VMs. The VM utilization

depends on the multi-dimensional tuple characteristic of its evolution. VM,

Host and Cloudlet are multi-dimensional and depend on various dimensions.

The host utilization and VMs utilizations are calculated periodically and

updated and saved in an array named and expressed in Equation (3.17).

= and = (3.17)

Here the matrices and represent the utilization values of all

the hosts and VMs within these hosts at ‘ ’ time instants. We have the values

of these host utilization arranged in oldest to the latest fashion and with

respect to time, the same applies to VM utilization values. Our algorithm

aims at limiting the utilization values to suitable levels so as to protect our

hosts from running in to over utilized states. The utilization values are

81

calculated by taking RAM as parameter. The total requested RAM within a

host and the total requested RAM by all the cloudlets running within a VM

are being considered for calculation of utilization limits for Hosts and VMs

respectively. The newly allocated VMs are to be placed inside hosts with

minimum utilization care must also be taken to prevent the hosts from running

into over utilized state by suitably adding VMs into a migratableVMs list by

considering various parameters. The MigartableVMs list is represented as a

linear array with respect to a particular host given by ‘ ’. The simulation

software used by us is CloudSim and we have incorporated real time work

load samples from PlanetLab. The VM placement and migratable VM

selections are completely based on statistical analyzes using most efficient

statistical approaches namely Median of Absolute Deviation (MAD)

technique and Minimum Utilization Technique (MUT). We have our data

centers broker and cloudlets created followed by identification of utilization

values of all hosts. If any of these utilization values exceed our statistically

determined value of utilization we declare that host to be overloaded. The

overloaded hosts assign an array namelyH . These overloaded hosts are being

considered for running VM selection algorithms that selects the VMs that if

migrated from these hosts can help them from getting overloaded.

The value of utilization of each host is calculated using the concept

of total number of VMs running within a data center and the current amount

of RAM requested by all of them. This quantity when divided by the total

RAM allocated to the host under consideration is done we obtain the

utilization of that particular host. The utilization of host-1 at a time instant is

given by . Here represents the RAM capacity of each VM within Host-1.

‘ ’ gives the total RAM allocated to host-1.

= (3.18)

82

Hence we obtain the matrix of utilization history of all hosts for ‘ ’

particular time instants. This utilization matrix is used for calculating the

MAD (Median of absolute deviation) for each host. The process is explained

in Equation (3.19).

= (3.19)

At any particular time instant say we consider utilization values

of all hosts from the first column represented by the variable =

, , , … , . We calculate the median of array ‘ ’ and name it as

‘ ’.We calculate the deviation array and name it as delta ‘ ’. is

represented as = [ ; ; … , … , … , ] . We

calculate the median of the deviation array which in turn is represented by

‘ ’. Similarly we calculate the value for all the ‘n’ time instants

represented as = { ; ; … ; … ; … ; } . At a particular instant we

compare the values of utilization for all hosts i.e., , , , … , with

and all those hosts with utilization value greater than is declared as

over-utilize. Hence we set an array of over-utilized hosts named

comprising all those hosts with its utilization value greater than , i.e., >

.This array of over-utilized hosts is deducted from the list of total hosts to

obtain the array of underutilized hosts. The array of underutilized hosts is

being considered while allocating new VMs to the data centers. This list of

underutilized hosts will also be considered for switching off of data centers

thereby reducing power depletion by allocating the current VMs in these data

centers to other hosts so that the jobs performed are unaffected. From the

array of over-utilized hosts we fix upon the hosts which has to be subjected to

VM selection algorithms there by helping these hosts from going in to over-

utilize state.

83

Pseudocode for RHO

Input :Utilization History of Host;

Output: Migratable VM list

For each host all the VMs are loaded in to an array

For each host in overutilizedhostlist do

If host.availableRAMutilization>vm.requestedRAMthreshold do

Update overutilizedHostlist

Hostlist.add(sortedHostlist)

If host in underloadedhostlist do

MigratableVMslist.add(DecreasingOrderutilizazion)

Migration map.list(update)

Return migration map

Figure 3.5 Pseudo code and Flow Diagram for RHO

84

The pseudo code flow diagram for the proposed RHO is shown in

Figure 3.5. The RHO finds the host based on incoming VMs as shown in the

pseudocode. The utilization of RAM on every set of VMlist is estimated. The

under-utilized HostList is analyzed for the utilization of RAM and is sorted in

decreasing order. In the Migration Map the host is selected in the sorted order

and the VMs are assigned to it. The over utilized hosts are identified by

comparing the under-utilized host with respect to the threshold Th which for

our simulation is taken as 80% as given by PlanetLab trace. For all over-

utilized hosts RVS algorithm is implemented to find the VMs in the list that

creates the over-utilization. The VMs are selected from over-loaded hosts and

migrated to a capable host identified by migration map and equilibrium is

maintained between over-loaded and under-loaded hosts. The complexity of

the algorithms is m * n where m and n are the product of number of Hosts and

VMs.

The performance improvement can be attributed to the efficiency

with which we could predict the future requirement of the host. By

applying median of absolute deviation and calculating for any time instant

helped us in grouping hosts in to Ho list thereby increasing the energy

efficiency by improved RAM allocation. We can see that by implementing

RHO algorithm for host oversubscription detection we could significantly

reduce the overall energy consumed by the data centers. But there is a trade-

off between average SLA violation and energy as it is evident from graph.

We have implemented the RAM consolidation for utilization

calculation in the pseudo code of RHO as shown in Figure 3.5. When

simulated for the MAD statistical technique we obtained results that showed

significant improvements in terms of energy.

85

3.6 RAM CONSOLIDATED VM SELECTION (RVS)

To the above list of over utilized hosts we apply the VM

migration policy so that we fix upon the VMs that has to be migrated from

these hosts so as to prevent them from causing SLA violations or at least

reduce the SLA violations. We have implemented minimum utilization

technique to establish the migratableVMs list. The migratableVMs list is

indicated by the variable . If we have ‘k’ number of overloaded hosts, the

VM migration policy is applied to VMs within these ‘k’ hosts. Let each of

these hosts have ‘n’ number of VMs. Then we can approximate the utilization

values of these VMs for a single host-1 as a matrix shown in Equation

(3.20).

= (3.20)

where the column matrix represented by , , … ,

Refers to utilization values of ‘v’ number of VMs in host-1 at a particular

time instant say ‘ ’.

From these values [ , , …, ], we calculate the one with minimum

utilization for migration. This can be proved with help of the theorem of

minimum achievable utilization for fault tolerant processing of periodic jobs.

3.6.1 Minimum Achievable Utilization Theorem

The theorem states that for any job set utilization factor is given by

‘U’ which can be represented by an Equation (3.21).

= + + + (3.21)

86

where the factors and represent the execution time of the job and period of the job respectively.

The theorem declares a job set ‘S’ consisting of ‘n’ jobs. The job set ‘S’ can be defined by = { , , } represent the release time. The same utilization concept has been implemented into the cloud concept by calculating utilization of a VM by adding the RAM requirement of all cloudlets running in a VM divided by the total RAM capacity of the VM is given in Equation (3.22).

= (3.22)

Here represents the RAM utilized by each cloudlet if there is a total of ‘n’ Cloudlets running in this VM under consideration. ‘ ’ represents

the total RAM allocated to the VM under consideration. represents the utilization of VM-1 at time instant . Thereby we obtain the utilization values of all the VMs inside the host under consideration, and select VMs with minimum utilization values for migration by mapping them into a migrationmap which will be migrated to under-loaded hosts.

An Efficient Energy aware algorithm by introducing RAM consolidation for VM selection policies has been proposed. RVS has proved to be highly effective in combination with RAM consolidated host oversubscription detection algorithms as they are capable of reducing energy requirement significantly. We have our data centers broker and cloudlets created followed by identification of utilization values of all VMs with in a host under consideration. VM with minimum RAM utilization will be considered for migration. MigratableVMs are saved in a linear array named Migratable VM list. RVS when applied in combination with IQR (Inter Quartile Range), MAD (Median Of Absolute Deviation), and LR (Local Regression) gave competitive results than established VM selection

87

algorithms like MC (Maximum Correlation), MMT (Minimum Migration Time) and MU (Minimum Utilization).

Pseudo code for RVS

Input : Utilization History of VMs

Output: Migratable VM list;All the hosts are loaded in to an arrayFor each host in hostlist dohostlistadd(host.RAMutilization)

RAMutilizationHostlist.updateOverutilizedhost.list(update)

If host not an element of overutilizedhost.list doUnderutilized hostlist.add(hosts)underutilizedhost.list(update )

Return migration map;

Figure 3.6 Pseudo code and Flow Diagram of RVS

88

The pseudo-code for the RVS algorithm for the over-utilization is

as shown in Figure 3.6. The calculation sorts the agenda of VMs in the

diminishing request of the CPU utilization. By then, it is over and again looks

through the program of VMs and finds a VM that is the best to move from the

host. The best VM is the specific case that fulfils two conditions. To begin

with, the VM might moreover have the utilization higher than the

qualification between the host's general use and the upper usage limit.

Second, if the VM is moved from the host, the qualification between the

upper limit and the new use is the base over the qualities outfitted by all the

VMs. Furnished that there is no such VM, the computation picks the VM with

the most astounding use, removes it from the plan of VMs, and comes back to

an alternate cycle. The computation stops when the new utilization of the host

is underneath the upper utilize edge. The diverse nature of the calculation is

comparing to the after-effect of the measure of over-utilized hosts and the

measure of VMs allotted to these hosts.

We use the above algorithms to form groups by randomly adding

hosts until coalesce is met. We create pairs to achieve coalesce between the

best Cloud character and the best energy heuristics. We handle this parameter

to leverage the energy consumed in a data center where VMs are acquired in a

host by the CPU. The host oversubscription has to be minimized by

maintaining the VM migration to be processed at a host which is not

overloaded. We have implemented the RAM consolidation and for

utilization calculation in the algorithms mentioned. When simulation aimed at

the MAD statistical technique we obtained results that showed significant

improvements in terms of energy. The improvement in energy can be

explained by the effectiveness of implementing a greater number of

instructions per second which in turn has been attributed by the introduction

of . The performance improvement can be attributed to the efficiency with

89

which we could predict the future requirement of the host. By applying

median of absolute deviation and calculating for any time instant helped us

in group hosts in to list thereby increasing the energy efficiency of

improved Ram allocation. In RVS algorithm we have applied in such a

way that the current request RAM of VMs when divided by yields

utilization of that VM. These utilization factors are taken into consideration

for adding the VMs into a migratableVMs list ( ). We have approximated

the cloudlets RAM requirements at any particular time instant into a

variable . The sum of all running in a VM when divided by net RAM of

the VM yields its utilization. These utilization values represented by

helping us in mapping VMs to migratable list thereby, preventing the

hosts from running into over-utilized states. For various statistical methods

we have simulated our algorithms and results have been exhibited. The

algorithms are used to find the relationship of cloud character model and find

an efficient scenario where cloud works best. Performance and energy

consumption depends on the availability of efficient resources and scarcity of

efficient resources burdens time of SLA violation and VM migration.

3.7 A BENCHMARK SUITE

A set of workload traces holding information on the CPU

consumption or utilization, gathered at regular intervals from more than a

thousand PlanetLabVMs deployed on servers placed in more than 500 spots

around the globe. A set of execution measurements catching the

accompanying perspectives: overhead of VM merging; overhead of VM

consolidation in terms of the number of VM migration; and execution time of

the consolidation algorithms. Assessment technique recommending the

methodology of getting ready examinations, conveying the framework,

producing workload utilizing the PlanetLab trace, and also handling and

breaking down the outcomes. The accessibility of such a benchmark suite will

90

encourage and expedite research endeavours and anticipated headways in the

region of dynamic VM combining. Furthermore, specialists are urged to

expose and offer the actualized combination calculations to improve

execution correlations with anticipated results. Contributed algorithms are

added as class policies and the traces are used for an extensive research. The

accompanying segments give more data on the workload follow, execution

measurements, and assessment technique of the proposed benchmark suite. In

this chapter, IaaS environment focuses on a framework which is an expansive

scale data center with N heterogeneous physical hubs (or) hosts. The CPU

execution of every hub is described in Millions Instructions Per Second

(MIPS), outlined in measure of RAM and bandwidth speed. There is no

nearby memory in the servers and Network Attached Storage (NAS) is the

space to empower live migration of VMs (Beloglazov et al 2011).

Heterogeneous VMs say are solicited by Cloud autonomous customers

which are portrayed by necessities to prepare a VM characterized in MIPS,

measure of RAM and bandwidth (Kliazovich et al 2010) to a host (or) hub.

Different VMs on a solitary physical hub is blended since the cloud provider

supervise VMs. HPC and web-applications, which use the assets concurrently

which is the blended workload is framed by different sorts of provisions. The

client secures SLAs with the asset supplier to formalize the QoS conveyed.

The supplier pays a punishment to the provider in instances of SLA

violations. A local and global manager is sandwiched as the programming

layer of the framework. The nearby supervisors dwell on every hub as a

module of the Virtual Machine Manager (VMM). Their goal is the consistent

following of the hub's CPU usage, resizing the VMs consistent with their

asset needs, and choosing when and which VMs ought to be moved from the

hub.

The Effect of the VM estimate regarding the VM migration and

Energy has been investigated for a day at the PlanetLab where the data center

91

is of 800 heterogeneous hosts 50% of which are HP Proliant ML 110 G4

servers and other half are HP Proliant ML 110 G5 servers. The server use and

power expended by these servers are taken from true data from SPECPower

benchmark (Corporation, 2012). In DVFS the limited number of states that

can be set to the frequency and voltage of a CPU is the possibility. The

voltage and performance scaling cannot applied to other system components,

such as memory and network interfaces. However, modern servers have

heavy memory and modeling of the multi core processors is a complex

research problem. Therefore, instead of using an analytical model of power

consumption by a server, we utilize real data on power consumption provided

by the results of the SPECpower benchmark as shown in Table 3.1. The

server utilization for a level of load is depicted for 100% load HP Proliant G4

consumes 117 watts.

Table 3.1 SPECwork Benchmark Power Consumption (Watts) of servers at different Load Levels, Feb 2011

Server 0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100%HP ProLiant

G4 86 89.4 92.6 96 99.5 102 106 108 112 114 117

HP ProLiant G5 93.7 97 101 105 110 116 121 125 129 133 135

Virtual Machine Managers are the paramount part of our trials

since they perform genuine resizing and movement of VMs and also updates

in force modes of the hubs. The global master resides on the master hub and

gathers data from the nearby administrators to keep up the general perspective

of the use of assets, it likewise issues orders for the streamlining of the VM

position. Since we utilize CloudSim (Beloglazov & Buyya 2012)which is the

MIPS rating is given by the server CPU recurrence: 1860 MIPS every center

of the HP Proliant Ml110 G5 server and 2660 MIPS every center of the HP

92

Proliant Ml110 G5 server. Every server is modeled to have 1 Gb/s system

transmission capacity. The qualities of the VM sorts compare to Amazon EC2

instance types with the main exemption that all the VMs are single-center,

which is clarified by the way that the workload information utilized for the

reproductions hail from single-center VMs as given in Beloglazov & Buyya

(2012). For the same explanation for why the measure of RAM is partitioned

by the amount of centers for every VM sort: High-CPU Medium Instance

(2500 MIPS, 0.85 GB); Extra Large Instance (2000 MIPS, 3.75 GB); Small

Instance (1000 MIPS, 1.7 GB); and Micro Instance (500 MIPS, 613 MB). VM

sort's asset prerequisites characterize the VM allotment; VMs use less

resource as per the workload information, making chances for dynamic

consolidation. In this chapter, IaaS environment focuses on a framework

which is an expansive scale data center with N heterogeneous physical hubs

(or) hosts. We have simulated the cloud model for the best conceivable QoS

bearing the trade-off between the performance and power consumption.

3.8 REAL TIME WORKLOAD TRACES

To make simulations reproducible, it is essential to depend on a set

of trace to dependably produce the workload, which might permit the

analyzes to be rehashed the same amount times as fundamental. It is likewise

significant to utilize workload trace gathered from a true framework as

opposed to falsely created, as this might serve to imitate a reasonable

situation. This part utilizes workload trace information furnished as a part of

the CoMon venture, a monitoring infrastructure of PlanetLab. The trace

incorporate information on the CPU utilization gathered for a day from more

than a thousand VMs sent on servers found in 500 places as far and wide as

possible. 10 days of workload trace gathered throughout March and April

2011 have been haphazardly picked, which brought about the sum of 11,746

24-hour long trace. The full set of workload follow is freely accessible on the

93

web. The workload from PlanetLabVMs is illustrative of an IaaS nature's

domain, for example Amazon EC2, as in the VMs are made and supervised

by numerous autonomous clients, and the foundation supplier is not familiar

with what specific requisitions are executing in the VMs. Moreover, this

infers that the general framework workload is made out of various

autonomous heterogeneous provisions, which likewise relates to a nature's

turf. In any case, there is distinction from an open Cloud supplier, for example

Amazon EC2. The contrast is that PlanetLab is a base basically utilized for

exploration purposes; consequently, the provisions are possibly closer to the

HPC sort, instead of web administrations, which are normal open Clouds.

HPC requisitions are normally CPU-escalated with easier progress in the asset

use contrasted and web administrations, whose asset utilization hinges on

upon the amount of client solicitations and might fluctuate over the long haul.

HPC workload is simpler to handle for a VM union framework because of

slower variety in the asset use. Hence, to stretch the framework in the

examinations, the definitive workload follow have been sifted to leave just the

ones that show high variability. Specifically, just the follow that fulfil the

accompanying two conditions have been chosen: (1) no less than 10% of time

the CPU usage is lower than 20%; and (2) no less than 10% of time the CPU

utilization is higher than 80%. This essentially diminished the amount of

workload follow bringing about just 33 out of 11,746 24-hour trace left. The

set of chosen trace and separating script are accessible online. The resulting

amount of trace was sufficient for the analyzes, whose scale was restricted by

the span of the testbed portrayed in Section 3.8. In the event that a bigger

number of trace is instructed to fulfil bigger scale tests, one approach is to

unwind the states of sifting the definitive set of trace. An alternate approach is

to arbitrarily inspect with replacing from the restricted set of trace available.

In the event that an alternate set of suitable workload trace comes to be openly

accessible, it could be incorporated in the benchmark suite as an elective.

94

3.9 PERFORMANCE METRICS

For effective performance evaluation and comparison of algorithms

it is essential to define performance metrics that capture the relevant

characteristics of the algorithms. One of the objectives of dynamic VM

consolidation is the minimization of energy consumption by the physical

nodes, which can be a metric for performance evaluation and comparison.

However, energy consumption is highly dependent on the particular model

and configuration of the underlying hardware, efficiency of power supplies,

implementation of the sleep mode, etc. A metric that abstracts from the

mentioned factors, but is directly proportional and can be used to estimate

energy consumption, is the time of a host being idle, aggregated over the full

set of hosts. Using this metric, the quality of VM consolidation can be

represented by the increase in the aggregated idle time of hosts. However, this

metric depends on the length of the overall evaluation period and the number

of hosts.

SLA Violation (SLAV) and Performance Degradation due to

Migration (PDM) as given in Equation (3.23) and (3.25).

= (3.23)

= % (3.24)

= ( )

( )(3.25)

SLA time per Active Host (SLATAH) is given by the Equation

(3.24) where the number of hosts is , % is the total time during which

the host has experienced the utilization of 100% leading to an SLA violation.

is the total of the host being in the VM feeder state.

95

PDM is given in Equation (3.25) where the number of VMs is ;

( ) the estimate of the performance degradation of the VM caused by

migrations; ( ) is the total CPU capacity requested by the VM

during its lifetime.

The threshold for our simulation is fixed at 80% for over-utilized

hosts or processors. Over-utilized hosts are the difference between total active

hosts and the under-utilized hosts. VMs are identified and updated into

migratableVMlist. Reason behind host overloading is SLATAH which is a

negative parameter and this leads the hosts to an inefficient state.

3.9.1 Average SLA Violation

Average SLA violation is the SLA violation for the whole

simulation time. The SLA violation time till the end of the simulation eg: 24

hours (1 Day) is calculated.

3.9.2 VM Migration

VM migration is the transfer of VM on NAS between hosts (or)

CPU. It is done by Live Migration where a running VM is migrated without

disconnecting the client or application.

3.9.3 Energy Consumption

The Energy Consumption is the energy consumed by two hosts for

one VM migration. The amount of Energy consumed by the data center for a

day is calculated.

96

3.10 PERFORMANCE EVALUATION METHODOLOGY

The following step is composing scripts for planning the

framework for an experiment, which incorporates beginning up the needed

administrations, booting VM instances, and preparing them for starting the

workload generation. While the greater part of the specified steps are trifling,

workload generation is confounded by the necessity of synchronizing the time

of beginning the workload generation on all the VMs. An alternate critical

part of workload generation is the way workload trace are executed out to

VMs. Normally, the wanted conduct is running out a special workload trace

out of the full set of trace to every VM. At last, it is essential to make and

administer a particular level of CPU usage for the entire interim between

progressions of the CPU utilization level, characterized by the workload trace

for every VM.

This issue is tended to utilizing a consolidation of a CPU load

generation program, and a workload distribution web administration and

customers conveyed on VMs. The point when a VM boots from a

preconfigured picture, it immediately begins a script that surveys the focal

workload appropriation web administration to be relegated a workload trace.

At first, the workload dispersion web administration drops asks for from

customers sent on VMs to hold up for the minute when all the needed VM

occasions are booted up and primed for creating workload. When all

customers are primed, the web administration accepts an order to begin the

workload follow circulation. The web service begins answering to customers

by sending each of them an exceptional workload follow. Upon getting a

workload trace, each customer starts the CPU load generator and passes the

appropriated workload follow as a contention. The CPU load generator

peruses the furnished workload follow record, and begins producing CPU

97

usage levels relating to the qualities specified in the workload trace index for

every time frame.

3.11 RESULTS AND DISCUSSION

We have our data center broker and cloudlets created followed by

identification of utilization values of all hosts. If any of these utilization

values exceed our statistically determined value of utilization we declare that

host to be overloaded. The overloaded hosts assign an array namely Hoj. The

Hosts consumption for each VM is higher when the VM density gets higher.

The VM characteristic component utilization gets higher when the utilization

of the virtual component in the VM such as Processor, RAM or Memory gets

higher. Here we have shown that by implementing RHO algorithm for host

oversubscription detection we could significantly reduce the overall energy

consumed by the data centers. But there is a trade-off between average SLA

violation and energy still exists as it is evident from graph that when we were

successful in reducing the energy we had an increase in SLAV which in turn

proves the fact that energy and SLAV are inversely related. From the Figure

3.7 we can see that the RHO has 27.22% better performance in terms of

energy when compared to an IQR algorithm for host oversubscription

detection.

The Energy consumed by the proposed Host Overloading detection

based on the energy consumption of the system showed varied results as in

Figure 3.7. We harnessed the requested RAM characteristics and found the

Energy efficiency was achieved. The Energy Efficiency in turn had to deal

with an inefficient nature of average SLA violation. Here we can see that

RHO has significantly better performance in terms of PDM when compared

to other host oversubscription detection algorithms. Here again we can see

that PDM and SLAV has a trade-off, as we try to improve PDM we have

compromises in SLAV. For RHO there is 83% improvement in PDM when

98

compared to IQR. Decrease in PDM was due to the lesser VM migration

caused due to the proposed method.

Figure 3.7 Analysis of SLAV and Energy of the proposed RHO and RVS with respect to MMT and other VM consolidationalgorithms for 1052 VMs and 800 hosts

VM migration is much higher in other methods. The Hosts which

are alive should necessarily maintain equilibrium between the VM migrations

and Host Oversubscription. Virtual Machine Manager should be designed to

handle workloads as and when the Host gets overloaded.

3.11.1 Energy Vs SLAV (MC)

For VM selection algorithm MC (Maximum Correlation) as in

Figure 3.9 we have compared the performance of host oversubscription

detection algorithms RHO, IQR, LR, MAD. From the observations we can

see that RHO has been able to give 37.26 % improvement over IQR. Here

again we can see a trade-off between SLAV and Energy. As we try to

improve upon energy factor we have a trade-off in SLAV. The average SLA

1

5

25

125 RHOMMT

IQRMMT

LRMMT MADMMT

RHORVS

ENERGY (kWh)

SLAV (%)

99

violation when compared to other techniques our proposed algorithm

decreased.

Figure 3.8 Analysis of SLAV and PDM of the proposed RHO and RVS with respect to MMT other VM consolidation algorithms for 1052 VMs and 800 hosts

This efficiency was evident in our proposed method. RAM based

consolidation proved more efficient than other Host oversubscription and VM

selection techniques. RAM utilization in VM and its MIPS space occupied on

a host depends on the Host characteristics. Hence RAM consideration being

an important parameter was harnessed for an Efficient Energy strategy.

0.0001

0.01

1 RHOMMT

IQRMMT

LRMMT MADMMT

RHORVS

PDM (%)

SLAV (%)

100

Figure 3.9 Analysis of SLAV and Energy of the proposed RHORVS with respect to other MC and other VM consolidation algorithms for 1052 VMs and 800 hosts

3.11.2 PDM Vs SLAV(MC)

Here we tabulate the performance of MC along with host

oversubscription detection algorithms like RHO, LR, MAD, IQR. We can see

that there is a trade-off between PDM (power degradation due to migration)

and SLAV. As we try to improve up on PDM we have a faceoff in SLAV. We

have attained 74% improvement in terms of PDM by implementing RHO

over IQR. Comparing other methods of combination of VM placement and

Host Oversubscription techniques the proposed RAM based consolidation

proved better. The PDM decreased and a meager increase in SLAV was

observed. The number of VM migration reduced to a 73% which helped us to

efficiently harness the estimate of performance degradation. The performance

degradation reduction helped in energy reduction due to a small SLATAH

time higher than the legacy method. SLA violation and the PDM analysis is

depicted in Figure 3.10.

1

5

25

125 RHOMC

IQRMC

LRMC MADMC

RHORVS

ENERGY (kWh)

SLAV (%)

101

Figure 3.10 Analysis of SLAV and PDM of the proposed RHORVS with respect to MC and other VM consolidation algorithms for 1052 VMs and 800 hosts

The mean value of the sample means of the time before a host is switched to

the sleep mode for the RHO RVS algorithm combination is 645.5 seconds

with the 95% CI: (689, 603). The mean value of the sample means of the time

before a VM is migrated from a host for the same algorithm combination is

20.26 seconds with the 95% CI: (19.9, 20.62). The mean value of the sample

means of the execution time of the RHO RVS algorithm on a server with an

Intel Core i7 (2.40 GHz) processor and 2 GB of RAM is 0.14 ms with the

95% CI: (0.13, 0.15).

3.12 SUMMARY

Taking into account the literature in Chapter 2, this part proposed

novel heuristics for distributed dynamic VM consolidation that depend on an

investigation of verifiable information on the CPU utilization by VMs to

leverage the predictability of the workload. Cloud providers need to apply

energy productive resource management procedures, for example dynamic

0.0001

0.01

1 RHOMC

IQRMC

LRMC MADMC

RHORVS

PDM (%)

SLAV (%)

102

VM consolidation with switching idle servers to power-saving modes to

maximize their Return On Investment (ROI). However, such consolidation is

not trivial, as it may result in violations of the SLAs negotiated with

customers. Re-enactments of an expansive scale data center utilizing

workload trace from more than a thousand PlanetLabVMs have demonstrated

that the proposed proximity based host oversubscription estimation. With the

MMT and MC, VM consolidation essentially outflanks other dynamic VM

consolidation calculations with respect to the performance metrics because of

a significantly decreased level of SLA violations and the amount of VM

migrations. Energy efficiency of about 27 % was achieved due to the

proposed algorithm RHO RVS. The proposed algorithms had trade-off

between SLA violation and performance degradation due to migration. Hence

there was a necessity to model a hypothesis for an energy perspective for the

trade-off parameters. Cost model was necessary to define SLA violation and

VM migration timing constraints. Energy Curve model due on the cost

function based on VM migration and SLA violation has been presented in the

chapter 4.