Introduction
Motivation
-
For VM selection, there are several VM selection approaches are proposed in research [1, 2, 4], namely Maximum Correlation (MC), Minimum Migration Time (MMT), and Random Selection (RS). The maximum correlation (MC) approach selects the VM to migrate which has the highest correlation value among all the VMs of a host. The minimum migration time approach (MMT) selects the VM to migrate which has the least memory as it will be migrated faster. And the random selection approach (RS) selects the VM randomly from a host. The approaches offer different results. One method (MC) provides more power savings but lacks in QoS. Another method (MMT) provides better performance KPI, i.e., QoS incurring more power [4]. As the situation is uncertain and in real world the computation need is very dynamic, fuzzy logic can be applied with different inputs to achieve the tradeoff between energy consumption and QoS.
-
Migration control can be applied to select the VM to migrate. Refraining from steady resource consuming VM migration can lead to better performance in dynamic VM consolidation [3]. But constantly high resource consuming VM should not be migrated as they consume large number of resources. So, migration control can be applied on two types of VMs; steady resource consuming VM and high resources consuming VMs. These phenomena can be taken into account while designing a VM selection method.
-
To decide whether a host is overloaded or not, there are several algorithms proposed [1, 2, 4] (e.g., Inter Quartile Range (IQR): which decides the threshold of a host to be marked as overloaded using interquartile range, Median Absolute Deviation (MAD) uses median absolute deviation and THR provides threshold for a host to be marked as overloaded. Local Regression (LR) and Local Robust Regression (LRR) provide prediction of host utilization,). These statistical measures provide a threshold (IQR, MAD and THR) and prediction (LR and LRR) for a host to be identified as overloaded. In parallel, these algorithms rely on mean and standard deviation of resource utilization that gives an indication of future load of a VM which also can be an approach independently for overload detection [15]. However, mean and standard deviation is very much influenced by terminal values. Terminal values indicate the outlier values or the values that are too large or too small and do not represent the normal values. As VM’s resource utilization can be very dynamic in real world, instead of mean we can use median and we can modify the formula for standard deviation using median instead of mean. An overload detection algorithm can be designed from this.
-
When VM needs to be migrated to another datacenter in VM placement phase or underload detection phase, the destination host needs to be judged whether it will be overloaded in future by using overload detection method.
Proposed method
-
Fuzzy technique is an attractive approach to handle uncertain, imprecise, or un-modeled data in solving control and intelligent decision-making problems. Different VM selection methods offer different advantages. It will be worthy if we could generate a method which will have the benefits of all of them by combining them together. Fuzzy logic can be an ideal tool for this. It will consider all the options and depending on those options a fuzzy value will be generated based on the predetermined rule of inferences. To develop the fuzzy VM selection method we have selected three distinguished inputs and each of them offers some advantages over others and different researches have already proven them. Minimum migration time and Maximum Correlation can be found at [2, 4] and the idea steady resource consuming VM is adopted from [3]. The following subsections will be focusing on the variables we will be using as input to our fuzzy systems, member ship function generated, inference rules and algorithms for computation.1)Minimum migration Time
-
Minimum Migration Time (MMT) policy selects the VM which can be migrated within minimum time limit [2, 4]. The migration time is limited by the memory the VM is using and the spare bandwidth. At any moment t, The MMT with Migration Control policy finds VM x that will be selected for migration by the formula (1). RAM(x) is the Radom Access Memory (RAM) utilization of VM x and RAM(y) is the RAM utilization of VM y. NET h means the available bandwidth for migration and V h is the set of VMs of host h. So the this method comapares the migration time and selects the VM x with minimum migration time among all VMs reside in host h.$$ x\in\ {V}_h\ \Big|\ \forall y\in {V}_h,\ \frac{RAM(x)}{NE{T}_h}\le\ \frac{RAM(y)}{NE{T}_h} $$(1)
-
This policy gives us the lowest SLA among all VM selection models. Migration time will be considered as one input of our fuzzy system.
2)Correlation-
This method works based on the idea that the higher the correlation between the resource usages by applications running on an oversubscribed server, the higher the probability of server being overloaded [14]. It means that if the correlation of the CPU utilization of VMs of a particular host is high then the probability of this host being overloaded is also high [4, 14]. Based on this research outcome, correlation is considered as a metric as it will provide the information about the VM(s) that is going to cause the host to be overloaded. It is a predictive measure and consequently it will safer if such a VM could be migrated to other host where it will not have higher correlation with other VMs. In the subsequent portion, it is described how the correlations of VMs are calculated. An augmented matrix is created for all VMs of host using last n cycles’ CPU utilization and correlation value is calculated. The highest the correlation value of VM, the higher the probability of that VM makes the host to be overloaded.
-
As described in [4], let there are n number of VMs. Let Y be one out of those n VMs for which we want to determine the maximum correlation with other n-1 VMs. Here our objective is to evaluate the correlation of Y with the rest of VMs. The (n-1)*n augmented matrix is denoted by X. Each value in the matrix X represents the observed values of (n-1) VMs and y vector represents (n-1) observations of VM Y.$$ X=\left[\begin{array}{cccc}\hfill 1\hfill & \hfill {x}_{1,1}\hfill & \hfill ..\hfill & \hfill {x}_{1,n-1}\hfill \\ {}\hfill .\hfill & \hfill .\hfill & \hfill \hfill & \hfill \hfill \\ {}\hfill .\hfill & \hfill .\hfill & \hfill \hfill & \hfill \hfill \\ {}\hfill 1\hfill & \hfill {x}_{n-1,1}\hfill & \hfill .\hfill & \hfill {x}_{n-1,n-1}\hfill \end{array}\right]\;y=\left[\begin{array}{c}\hfill {y}_1\hfill \\ {}\hfill .\hfill \\ {}\hfill .\hfill \\ {}\hfill {y}_n\hfill \end{array}\right] $$(2)
-
A vector of predicted value of VM y is denoted by ŷ and expressed in Eq. 3.$$ \hat{y}=Xb,\kern1em where\kern0.5em b={\left({X}^TX\right)}^{-1}{X}^Ty $$(3)
-
As we can find the predicted vector ŷ of Y, the multiple correlation coefficient (RY, 1……N-1)2 also can be determined as this is equal to the squared correlation coefficient of the observed values y and predicted values of ŷ of VM Y. So the correlation coefficient can be defined by Eq. 4. Here m y and m ŷ are the sample mean of the values of y and \( \hat{y} \).$$ {R}_{Y,\ {X}_{1,}\dots {X}_{n-1\ }\kern0.5em }^2 = \frac{{\displaystyle {\sum}_{i=1}^n}\ {\left({y}_i-{m}_y\right)}^2{\left({\hat{y}}_i-{m}_{\hat{y}}\right)}^2}{{\displaystyle {\sum}_{i=1}^n}\ {\left({y}_i-{m}_y\right)}^2{\displaystyle {\sum}_{i=1}^n}{\left({\hat{y}}_i-{m}_{\hat{y}}\right)}^{2\kern0.75em }} $$(4)
-
Now the multiple correlation coefficient can be easily found for any VM Xi by \( {R}_{X_{i,}\ {X}_{1,}\dots \dots {X}_{n-i},\kern0.5em {X}_{n+i} \dots \dots .{X}_{n\ }\kern0.5em }^2 \). According to this method the VM that has the highest correlation with other VMs’ CPU utilization will be migrated. More details of this method could be found in [1, 14].
3)Migration control metric for steady resource consuming VM-
It has been proven that migration control provides better result in energy aware VM consolidation and this approach also saves the unwanted traffic load [3]. Migration control can be done in various ways. We can stop migrating the high CPU using VMs or we can restrict steady resourse consuming VM from migration. In this work we will take steady resource consumption as a non-migration factor. If a VM’s requirement highly fluctuates over time, then it can cause the host to be overloaded. In dynamic VM consolidation approach, VMs are resized in each iteration according to their need. So when a VM requests CPU which is abruptly high then host may not have such CPU available at that time and SLA violation will occur. As VM migration is triggered from an overloaded host we do not want to to migrate such VM from the overloaded host whose demands of CPU is not changed suddenly. In other words, if a VM is steady resource consuming over some iteration it means that it will be the least possible VM to make this host overloaded and we can expect the same behavior in the next iteration. We have used standard deviation for calculation of steady state resource consumption. If the standard deviation is high it means that the CPU request changes abruptly and we can call VMs with low standard deviation as steady resource consuming VMs.
-
Let us consider a host h and V h be the set of VMs in host h. CPU u (x t ) is the CPU utilization of VM X at time t. CPU u (x t-1 ), CPU u (x t-2 ) ….. CPU u (x t-n ) are the CPU utilizations of previous n time frames of VM X. Migration control parameter can be given by Eq. 5. Here CPUaverage means average CPU utilization in last n time frames. The standard deviation of CPU usage of VM X can be determined by this equation. This parameter will surely indicate the fluctuation of CPU usage of the particular VM X.$$ stdev=\sqrt{\frac{1}{n}\kern0.28em {{\displaystyle {\sum}_{i=1}^n\kern0.28em \left(\mathrm{C}\mathrm{P}{\mathrm{U}}_i-\mathrm{C}\mathrm{P}{\mathrm{U}}_{\mathrm{average}}\right)}}^2} $$(5)
4)Fuzzy Membership function-
A FIS (Fuzzy Inference System) is developed to provide fuzzy VM selection decision using three metrics as input. Member ship function needs to be defined to develop the FIS. We are using 4 linguistic variables including VMselection as output. Range of these membership function is chosen from the real cloud simulation data of PlanetLab. In order to do the so, we have run the simulation and collected data of all these variables and proportioned to decide the range. As the ranges have been collected from real world data by doing statistical proportion operation (e.g. top 30 % values are high) for deciding different level (i.e. high, medium and low), using trapezoidal membership function is logical as it deals with ranges with flat region better. As the range of values should be counted as medium or low or high, not a peak value, triangular function is being not used and sigmoid function is not used as it does not define the flat region like trapezoidal function does. Membership function of the linguistic variables are given below:
-
RAM: T(RAM) = {Low, Medium, High}
-
Correlation: T(Correlation) = {Low, Medium, High}
-
Standard Deviation: T(Stdev) = {Low, Medium, High}
-
VM selection: T(Vmselection) = {Low, Medium, High, Very High}
-
-
Equation for the Trapezoid membership function [27] can be expressed as Eq. 6.$$ \upmu \left(\mathrm{z}\right)=\left\{\begin{array}{c}\hfill \begin{array}{c}\hfill 0\kern1.5em ,\kern1.5em \mathrm{z}\le a\hfill \\ {}\hfill \left(\frac{\mathrm{z}-\mathrm{a}}{\mathrm{b}-\mathrm{a}}\right), \kern0.75em \mathrm{a}\ \le z\ \le b\ \hfill \end{array}\hfill \\ {}\hfill \begin{array}{c}\hfill 1\kern2.25em ,\kern0.75em \mathrm{b}\ \le z\ \le c\hfill \\ {}\hfill \begin{array}{c}\hfill \left(\frac{\mathrm{d}-\mathrm{z}}{\mathrm{d}-\mathrm{c}}\right), \kern0.75em \mathrm{c}\ \le z\ \le d\hfill \\ {}\hfill 0\kern3em ,\kern1.75em d\ \le z\hfill \end{array}\hfill \end{array}\hfill \end{array}\right. $$(6)
-
All the membership function graphs (Figs. 1, 2, 3 and 4) of the linguistic variables are given below and Table 1 shows the type of the membership function, the equation and the parameters.Table 1Memberhip functionsVariablesParameterLevelFunction TypeParameterRAMLowTrapezoidala = 0 b = 0 c = 650 d = 750MediumTrapezoidala = 700 b = 800 c = 900 d = 1000HighTrapezoidala = 900 b = 1100 c = 1800 d = 1800CorrelationLowTrapezoidala = 0 b = 0 c = .5 d = .6MediumTrapezoidala = .5 b = .6 c = .8 d = .85HighTrapezoidala = .8 b = .85 c = 1 d = 1StdevLowTrapezoidala = 0 b = 0 c = 3 d = .3.75MediumTrapezoidala = 3.25 b = 4 c = 6.75 d = 7.5HighTrapezoidala = 7.5 b = 8.5 c = 100 d = 100VM SelectionLowTrapezoidala = 0 b = 0 c = .3 d = .35MediumTrapezoidala = 0.3 b = 0.35 c = .6 d = .65HighTrapezoidala = .6 b = .65 c = .8 d = .85Very HighTrapezoidala = .8 b = .85 c = 1 d = 1××
-
As mentioned earlier, values and ranges of these membership functions are generated by heuristic approach. The source is 1-day (among 10 days) data of thousands of VM data of PlanetLab cloud network [25] (more discussed in section Experimental setup). For example, to deduce the standard deviation membership function, we have generated standard deviation value utilization of each of the thousand VMs. As these trace contains 288 (every 5 min from 1 day) data per VM, total sample size is about 288,000 (288 trace data*1000 VMs). Using a window size of 10, standard deviation is calculated for the total data and by doing ration the high, medium and low ranges are selected. The minimum migration time and correlation is also done in same way.
5)Fuzzy Inference Rule-
Fuzzy inference rules are generated from the given linguistic variables. We have given equal weight on the variables to influence the VM selection value. If RAM is low it gets high priority as it makes the migration faster. If correlation is high then it gets high priority in migration as the higher the correlation is, the higher the probability of overloading the host. Finally, if the standard deviation is high then it will get high priority in migration compared to its steady state counterparts. The following Table 2 depicts the inference rules.Table 2Fuzzy inference ruleInputOutputRAMCorrelationStddevVM SelectionLowHighHighVery_HighLowHighMediumVery_HighLowHighLowHighLowMediumHighVery_HighLowMediumMediumHighLowMediumLowMediumLowLowHighHighLowLowMediumMediumLowLowLowLowMediumHighHighVery_HighMediumHighMediumHighMediumHighLowMediumMediumMediumHighHighMediumMediumMediumMediumMediumMediumLowLowMediumLowHighMediumMediumLowMediumLowMediumLowLowLowHighHighHighHighHighHighMediumMediumHighHighLowLowHighMediumHighMediumHighMediumMediumLowHighMediumLowLowHighLowHighLowHighLowMediumLowHighLowLowLow
-
-
Combination of Fuzzy VM selection method and migration control is given in Eq. 7 and Eq. 8. These equations indicate that a VM will be nominated for migration if it produces lower CPU usage than the migration control threshold and possesses highest fuzzy output value. If all VMs of an overloaded host produce more CPU usage than the migration control threshold, then the VM that produces highest fuzzy output value will be migrated. It is described in detail below.
-
Here the VM x is selected for migration if the fuzzy output value of VM x is greater than all other VMs. However, there is a condition that is as follows. If the current time is t and in last n cycles CPU utilization of VM x is CPU u (x t ), CPU u (x t − 1), CPU u (x t − 2) … CPU u (x t − n ), then the average CPU utilization must be less than CPUthreshold to satisfy migration control, i.e., not to migrate the highly utilized VMs. The Eq. 8 means if the average CPU utilization is above threshold for all the VMs then the VM x with maximum fuzzy output value will be selected for migration.$$ x\in\ {V}_h\ \Big|\ \forall y\in {V}_h,\kern0.5em Fuzzy\ Output(x)\ge Fuzzy\ Output(y) $$
-
Only if;$$ \frac{\left[CP{U}_{u\ }\left({x}_t\right)+CP{U}_{u\ }\left({x}_{t-1}\right)+CP{U}_{u\ }\left({x}_{t-2}\right)+\dots CP{U}_{u\ }\left({x}_{t-n}\right)\right]}{\left(n+1\right)}<CP{U}_{thresold} $$(7)
-
However, if every VM vm satisfies the following condition that means average utilization is more than the threshold,$$ \frac{\left[CP{U}_{u\ }\left(v{m}_t\right)+CP{U}_{u\ }\left(vm{x}_{t-1}\right)+\dots + CP{U}_{u\ }\left(v{m}_{t-n}\right)\right]}{\left(n+1\right)}\ge CP{U}_{thresold} $$
-
then this technique will select the VM that produces the highest fuzzy output value;$$ x\in\ {V}_h\ \Big|\ \forall y\in {V}_h,\kern0.5em Fuzzy\ Output(x)\ge Fuzzy\ Output(y) $$(8)
-
-
The Algorithm 2 depicts how Fuzzy VM Selection algorithm (FSMC) works. There are two inputs of the algorithm: the host h and window size n (CloudSim Default window size has been used). The overloaded host is detected by previous phase: Overload detection. After having the host h at step-1, at step-2, GetMigratableVm(h) function pulls all the VM which are currently placed on that host h. At step-3, ExcludeVmInMigration function excludes all the VM which are already in migration for that host and assigned to VM hex . At step-4, the function UtilizationMatrix calculates utilization matrix and stores at UtilM (VM hex ). At step-5, function CorrelationCoefficient calculates correlation coefficient based on UtilM (VM hex ) and stores at Metric(n). At step-7, for each VM V i , CPU usage history of V i is fetched using the function GetMcParamFromCpuHistory (V i ) for last n iteration as per CloudSim settings. At Step-8, Migration control parameter is calculated. To determine the steadiness of a VM’s CPU usage, at Step-9, STDEV(V i ), Standard deviation is calculated using StandardDeviation function from CPU hist . At Step-10, current usage of RAM will be fetched for V i and will check for if the one is the lowest up to now. At Step-11, Correlation for this VM will fetched. At Step-12, fuzzy output Output fuzzy is determined using EvaluateFuzzy function where inputs of this function are STDEV(V i ), RAM (V i ) and MC (V i ). At step-13, If this one is the highest till now, at step-14, VM highest will be updated. At step-15, VM VM m will be updated if CPU mc is smaller than CPU threshold . If all VM is greater than the threshold and the highest fuzzy output VM is selected for migration at step-18 and finally step-19 returns the VM to be migrated.
-
Overload detection algorithm ensures that when a host is overloaded, then the algorithm will find it. Moreover, it will provide intelligent measure so that the datacenter does not get overloaded. There are several overload detection algorithms proposed in [1, 2, 4], 1) A Static CPU Utilization Threshold (THR): where overload decision is based on a static threshold; 2) Adaptive Median Absolute Deviation (MAD): the overload threshold is calculated dynamically using median absolute deviation; 3) Adaptive Interquartile Range (IQR): overload threshold is calculated dynamically using interquartile range method; 4) Local Regression(LR); and 5) Robust local Regression(LRR). LR and LRR are predication methods which will predict whether the host is going to be overloaded or not.
-
In this work, a new overload detection algorithm has been devised. When overloaded, a host incurs SLA violation. To be precise, a host incurs SLA violation when the required CPU utilization is greater than the actual utilization capacity. To avoid SLA violation, we have to design an overload detection mechanism which will predict this scenario. Host utilization is calculated from the VM utilization. If the summation of mean (μ) and standard deviation (δ) of last n iteration is greater than the maximum capacity of the VM then it can be inferred that this VM will request more utilization than allocated in future [15]. We apply that idea in our research.$$ \upmu +\updelta >1 $$(9)
-
Equation 9 means that if the summation of mean utilization of a VM for last n cycles and standard deviation of utilization of that VM for last n cycles is higher than the allocated CPU, then in next iteration this VM can go beyond the maximum capacity of that VM. As our objective is to keep SLA violation at the lowest level, we can calculate predicted utilization of all VM of a corresponding host using Eq. (9) and check whether the total predicted utilization of a host is greater than the capacity or not. If the predicted value is greater, then the host is at risk of being overloaded and SLA violation. This technique we are going to apply in our overload detection algorithms. However, mean and standard deviation is very much influenced by terminal values that refer the outlier values or values that are too large or too small. So, when the standard deviation is high (i.e. the value falls in the high range of standard deviation membership function of fuzzy VM selection method) meaning that there is a possibility of high values present in the last n cycles. From the fuzzy membership variable Stddev, high range is considered. To avoid terminal values, when standard deviation is high, we replace mean with median and standard deviation formula is changed by replacing mean with median by Eq. (10). Hence, the prediction formula can be represented by Eq. (11). So it ensures, if in last n cycles any sudden fluctuation, i.e., very low or very high CPU utilization is found, this will not impact on the overall decision. δMedian is the standard deviation calculated from median instead of mean. Like Eq. 9, Eq. 11 provides the prediction of a host. If the summation of Median and δ Median is greater than 1 i.e. more than the total CPU then the host is considered to be overloaded.$$ {\delta}_{Median}=\sqrt{\frac{1}{n}{\displaystyle \sum_{i=1}^n}{\left({\mathrm{CPU}}_{\mathrm{i}}-{\mathrm{CPU}}_{\mathrm{Median}}\right)}^2} $$(10)$$ \mathrm{Median}+{\updelta}_{\mathrm{Median}}>1 $$(11)
-
-
Algorithm 3 describes how MMSD works. The input of the algorithm is the host of interest and the output of the algorithm is to determine whether the host is overloaded or not. At second step the VMs are identified which are currently active on the host. For every VM a loop is started at step 3. Total requested MIPS (Million Instructions Per Second) is accumulated to get the total requested MIPS of the host. Then Mean, Standard deviation, Median and Standard deviation from median are calculated. Now the predicted MIPS is calculated by the standard deviation value. If the standard deviation is greater than the threshold (this threshold is taken from the fuzzy member ship variable Stddev’s High value which starts from 8.5) then Eq. (11) is followed else Eq. (9) is followed. Then utilization of the host and predicted utilization of the host is calculated. If any of these are beyond 1(meaning 100%) then the host is marked as overloaded by returning true otherwise returning false.
-
There is an underload detection and handling algorithm in CloudSim. The algorithm is simple; it sorts the hosts according to their utilization and starts with the lowest utilized host. If all VMs of a particular low utilized host can be placed to any/some of active hosts using VM placement method then the host is put to sleep mode by migrating all VMs to other hosts. VM placement will be discussed later section. It is worthwhile to mention that before migrating VM to other active hosts, the destination host is checked whether it will be overloaded by the new assignment with our newly designed overload detection algorithm.
-
In CloudSim toolkit power aware BFD (Best Fit Decreasing) algorithm is used for VM placement. When overload detection or underload detection finds VMs to migrate, VM placement algorithm assigns the VM in such way that power consumption is increased minimally [4]. VM is placed in the host with decreasing utilization order. In this work it has been ensured that if a new VM placement is considered, then our newly overload detection algorithm certifies that the destination host will not be overloaded in next iteration.
Experimental setup
Machine type | Power consumption based on CPU utilization | |||||
---|---|---|---|---|---|---|
0 %
|
20 %
|
40 %
|
60 %
|
80 %
|
100 %
| |
HP G4 (Watt) | 86 | 92.6 | 99 | 106 | 112 | 117 |
HP G5 (Watt) | 93.7 | 101 | 110 | 121 | 129 | 135 |
Date |
Number of VMs
|
---|---|
3 March | 1052 |
6 March | 898 |
9 March | 1061 |
22 March | 1516 |
25 March | 1078 |
3 April | 1463 |
9 April | 1358 |
11 April | 1233 |
12 April | 1054 |
20 April | 1033 |
-
This is the main metric as the target of VM consolidation is to reduce energy consumption. Energy consumption is computed by taking into account all hosts throughout the simulation by mapping of CPU and energy consumption from Table 3. At each iterations the CPU utilization is measured and power consumption is calculated from Table 3 and at the end of the simulation energy consumption is measured by accumulating all hosts’ energy consumption.
-
This metric counts the number of VMs migrated during the siumaltion. VM migration is an important factor because unnecessary migration causes SLA violation and network traffic.
-
Overload time fraction [4], OTF is a measure of SLA violatoin. it provides a measure of the fraction of time a host experienced 100 % CPU utilization leading to SLA violation. In Eq. (12), if N is the number of hosts, T si is the total time when host i experienced 100 % utilizaiton leading SLA Violation, T ai is the total active time of host i, then OTF is defined by:$$ OTF=\frac{1}{N}{\displaystyle {\sum}_{i=1}^N}\frac{T_{si}}{T_{ai}}\kern2.52em PDM=\frac{1}{M}{\displaystyle {\sum}_{j=1}^M}\frac{C_{dj}}{C_{rj}} $$(12)
-
Performance degradation due to migration(PDM) [4] is a measure of SLA violation. It measures the total SLA violation due to VM migration. When a host is overloaded, VMs are migrated from that host to non-overloaded host. At the time of migration, that VM is not capable of serving user needs, hence, it causes SLA violation. This metric calculates the SLA violation caused by migration. From Eq. (12), if M is the number of total VMs, C dj stands for the CPU request at the time of migration of VM j and C rj stands for total CPU requested by VM j, then PDM is defined by the Eq. (12).
-
Service level agreement violation, SLAV, is combined impact of OTF and PDM. It provides a SLA violation measure for the simmulation which is a product of OTF and PDM i. e., SLAV = OTF*PDM.
-
Energy consumption and SLA is already defined. It is perceivable that if we try to reduce too much energy consumption the SLA violation will be increased, because consolidating many VMs in a host increase the probability of overload. So it is desirable to obtain a method which will consume less power and still incur less SLA violation. To measure this, ESV is introduced. It is the combination of Energy consumption and SLA violation, i.e., ESV = Energy*SLAV. So this can be treated as one metric to make an overall measurement. If the product of energy consumption and SLA violation is lower, it means that the approach reduces energy consumption and making less SLA violation.
Experimental result
-
Main objective of this research is to design a VM consolidation algorithm so that the energy consumption is reduced. By comparing the proposed and existing methods in the Fig. 3, it is found that energy consumption is significantly reduced in proposed (MMSD_FS) method. Minimum energy consumption by the proposed method is 102 Kwh where the minimum of all other methods is 112 Kwh, therefore we got 8.5 % reduction. If we consider average value, MMSD_FS consumed 136.5 Kwh and all other methods consumed 169 Kwh on average resulting 19 % energy saving. Therefore, we can infer that the basic objective of this research is achieved by saving energy consumption.
-
SLA violation is one of the key indicators of QoS. SLA Violation is calculated by keeping two scenarios into consideration, i) if any VM got overloaded, and ii) The SLA violation incurred while migration. A method having low SLA violation ensures the desired QoS. From Fig. 4, SLA violation is decreased significantly which is clearly visible. Minimum SLAV by proposed method is 0.0004 % whereas the minimum of all other method is 0.00279 %, resulting 84 % reduction. If we consider average value, MMSD_FS incurred 0.0005 % SLAV and all other methods incurred 0.00617 % on average, resulting 91 % reduction in SLA violation. This is main achievement of this research. It means that the overload detection method we have used, predicted the overloaded host efficiently and as an outcome, SLA violation was dropped significantly. If host overload is predicted successfully then there will be less number of migration which will reduce SLA violation as well.
-
As energy consumption has been successfully reduced by the proposed method, now energy-QoS trade off needs to be checked. ESV is the metric which is a product of Energy consumption and SLA violation; hence, provides a tradeoff picture of the proposed method with other existing methods. From previous two sub-sections, we have observed that both energy and SLA violation reduced, so it is inevitable that ESV will also be reduced significantly. From the Fig. 5, ESV is found to be reduced significantly which is clearly visible. If ESV reduces it means that this approach saves energy and at the same time SLA violation is controlled. As ESV is reduced significantly, it means that Energy and SLA tradeoff has been achieved. Minimum ESV by proposed method is 0.04 whereas the minimum all other method is 0.49, resulting 91 % reduction. If we consider average value, MMSD_FS incurred 0.07 ESV and all other method incurred 1.09 on average, resulting 93 % reduction in ESV.
-
Less number of VM migrations means efficient consolidation, less traffic in cloud network and less SLA violation for VM migration. Reduction in Number of VM migration is also clearly visible from Fig. 6. To quantify, minimum number of VM migration caused by MMSD_FS is 5185 whereas the minimum all other method is 16,317, resulting 68 % reduction. If we consider average value, MMSD_FS incurred 7943 migrations on an average and average of all other methods is 24,929, resulting 68 % reduction in migration. From this percentage it is evident that the proposed method provides most optimum VM consolidation compared to the existing VM consolidation approaches.
-
From Fig. 7 to Fig. 8, it can be inferred that OTF and PDM is significantly reduced. The proposed method reduced both SLA violation due to overload and SLA violation due to VM migration. Minimum OTF is reduced up to 60 % by the proposed method and Minimum PDM is reduced up to 64 %. On an average OTF is decreased by 67 % and PDM is decreased by 74 % compared to the existing methods.
-
Finally, we have performed a statistical test namely two-tailed students’ t-test on the performance of the proposed method MMSD_FS and IQR_MMT method (the best method in CloudSim as per the ESV, Fig. 4). Our null hypothesis is: “There is no significant difference in the performance between two techniques”. Table 5 reports p-values for six performance metrics between MMSD_FS and IQR_MMT generated from 10 days’ experimental data. If the p-value is greater than 0.05, then we must accept the null hypothesis, otherwise we must reject the null hypothesis. From Table 5 we find that the p-value is significantly smaller than 0.05 for every performance metric. Therefore, we must reject the null hypothesis and we could conclude that there is significantly difference in performance found.Table 5P-values for performance metricsMetricP-valueEnergy Consumption0.004ESV2E–09Number of Migration1.4E–08SLAV6.78E–12OTF5.38E–19PDM1.44E–12
-
From all the performance metrics it can be inferred that the proposed method outperforms all other methods.
-
From the above result analysis, we have found that the proposed method improved significantly. Most of the improvement came from the SLA violation part. This phenomenon indicates that the proposed method identifies the host overload efficiently. To visualize the performance in easier way we have generated two heat maps of MMSD_FS method and another is IQR_MMT method which are given in Fig. 9 and Fig. 10 respectively.××
-
For this experiment, we have used 50 hosts and 50 VMs and random load. In the heat map, if a host is in sleeping mode i.e., 0 % utilization then it is marked by blue color and red color for high utilization. In the X-axis the time is portrayed. As iteration duration is 5 min, so there are total 288(starting from 0 to 8600 s) iterations as the simulation is done for 1-day data. Y-axis represents 50 hosts. From Fig. 9, it is visible that hosts are experiencing ON-OFF frequently and the map seems scattered and the total number of overload occurs 685 times. So this method will invoke VM migration at least 685 times. On the other hand, Fig. 10 shows the heat map for MMSD_FS where we can observe less fluctuation (ON-OFF) of the host. It is easily perceivable that the host is put to sleeping mode and stays in sleeping mode for long. Total number of overload incident is 92, which indicates the efficiency of the algorithm. The main reason behind the performance of MMSD_FS is the prediction done by this algorithm helped to reduce the number overloaded hosts.