View
2
Download
0
Category
Preview:
Citation preview
Research ArticleOn Elasticity Measurement in Cloud Computing
Wei Ai,1 Kenli Li,1 Shenglin Lan,1 Fan Zhang,2 Jing Mei,1 Keqin Li,1,3 and Rajkumar Buyya4
1College of Information Science and Engineering, Hunan University, Changsha, Hunan 410082, China2IBMMassachusetts Lab, 550 King Street, Littleton, MA 01460, USA3Department of Computer Science, State University of New York, New Paltz, NY 12561, USA4Department of Computing and Information Systems, University of Melbourne, Melbourne, VIC 3010, Australia
Correspondence should be addressed to Kenli Li; lkl@hnu.edu.cn
Received 21 January 2016; Accepted 8 May 2016
Academic Editor: Florin Pop
Copyright Β© 2016 Wei Ai et al. This is an open access article distributed under the Creative Commons Attribution License, whichpermits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited.
Elasticity is the foundation of cloud performance and can be considered as a great advantage and a key benefit of cloudcomputing. However, there is no clear, concise, and formal definition of elasticity measurement, and thus no effective approach toelasticity quantification has been developed so far. Existing work on elasticity lack of solid and technical way of defining elasticitymeasurement and definitions of elasticity metrics have not been accurate enough to capture the essence of elasticity measurement.In this paper, we present a new definition of elasticity measurement and propose a quantifying and measuring method using acontinuous-timeMarkov chain (CTMC) model, which is easy to use for precise calculation of elasticity value of a cloud computingplatform. Our numerical results demonstrate the basic parameters affecting elasticity as measured by the proposed measurementapproach. Furthermore, our simulation and experimental results validate that the proposed measurement approach is not onlycorrect but also robust and is effective in computing and comparing the elasticity of cloud platforms. Our research in this papermakes significant contribution to quantitative measurement of elasticity in cloud computing.
1. Introduction
(1) Motivation. As a subscription-oriented utility, cloud com-puting has gained growing attention in recent years in bothresearch and industry and is widely considered as a promisingway of managing and improving the utilization of data centerresources and providing a wide range of computing services[1]. Virtualization is a key enabling technology of cloud com-puting [2]. System virtualization is able to provide abilitiesto access software and hardware resources from a virtualspace and enables an execution platform to provide severalconcurrently usable and independent instances of virtualexecution entities, often called virtual machines (VMs). Acloud computing platform relies on the virtualization tech-nique to acquire more VMs to deal with workload surgesor release VMs to avoid resource overprovisioning. Such adynamic resource provision andmanagement feature is calledelasticity. For instance, when VMs do not use all the providedresources, they can be logically resized and be migrated froma group of active servers to other servers, while the idle
servers can be switched to the low-power modes (sleep orhibernate) [3].
Elasticity is the degree to which a system is able to adaptto workload changes by provisioning and deprovisioningresources in an autonomic manner, such that at each pointin time the available resources match the current demand asclosely as possible [4]. By dynamically optimizing the totalamount of acquired resources, elasticity is used for variouspurposes. From the perspective of service providers, elasticityensures better use of computing resources and more energysavings [5] and allows multiple users to be served simultane-ously. From a userβs perspective, elasticity has been used toavoid inadequate provision of resources and degradation ofsystem performance [6] and also achieve cost reduction [7].Furthermore, elasticity can be used for other purposes, suchas increasing the capacity of local resources [8, 9]. Hence,elasticity is the foundation of cloud performance and can beconsidered as a great advantage and a key benefit of cloudcomputing.
Elastic mechanisms have been explored recently byresearchers from academia and commercial fields, and
Hindawi Publishing CorporationScientific ProgrammingVolume 2016, Article ID 7519507, 13 pageshttp://dx.doi.org/10.1155/2016/7519507
2 Scientific Programming
tremendous efforts have been invested to enable cloudsystems to behave in an elastic manner. However, there isno common and precise formula to calculate the elasticityvalue. Existing definitions of elasticity in the current researchliterature are all vague concepts and fail to capture theessence of elastic resource provisioning. These formulas ofelasticity are not suitable for quantifying and measuringelasticity. Moreover, there is no systematic approach that hasbeen proposed to quantify elastic behavior. Only quantitativeelasticity value can produce better comparison between dif-ferent cloud platforms. Therefore, the measurement of cloudelasticity should be further investigated. As far as we know,the current reported works are ineffective to cover all aspectsof cloud elasticity evaluation and measurement. Therefore,we are motivated to develop a comprehensive model and ananalytical method to measure cloud elasticity.
(2) Our Contributions. In this paper, we propose a clear andconcise definition to compute elasticity value. In order to dothat, an elasticity computing model is established by usinga continuous-time Markov chain (CTMC). The proposedcomputing model can quantify, measure, and compare theelasticity of cloud platforms.
The major contributions of this paper are summarized asfollows.
(i) First, we propose a new definition of elasticity in thecontext of virtual machine provisioning and a precisecomputational formula of elasticity value.
(ii) Second, we develop a technique of quantifying andmeasuring elasticity by using a continuous-timeMarkov chain (CTMC) model. We investigate theelastic calculation model intensively and completely.The model is not only an analytical method, but alsoan easy way to calculate the elasticity value of a cloudplatform quantitatively.
(iii) Third, we examine and evaluate our proposedmethodthrough numerical data, simulations, and experi-ments. The numerical data demonstrate the basicparameters which affect elasticity in our analyticalmodel.The simulation results validate the correctnessof the proposed method. The experimental results ona real cloud computing platform further show therobustness of our model and method in predictingand computing cloud elasticity.
The rest of the paper is organized as follows. Section 2reviews the related work. Section 3 describes the definition ofcloud elasticity. Section 4 develops the computing model ofcloud elasticity. Sections 5, 6, and 7 present simulation andnumerical and experimental results, respectively. Section 8concludes this paper.
2. Related Work
2.1. Elasticity Definition and Measurement. There has beensome work on elasticity measurement of cloud computing.In [4], elasticity is described as the degree to which a systemis able to adapt to workload changes by provisioning and
deprovisioning resources in an autonomic manner, such thatat each point in time the available resourcesmatch the currentdemand as closely as possible. In [10], elasticity is definedas the ability of customers to quickly request, receive, andlater release as many resources as needed. In [11], elasticityis measured as the ability of a cloud to map a single userβsrequest to different resources. In [12], elasticity is defined asdynamic variation in the use of computer resources to meeta varying workload. In [13], an elastic cloud application orprocess has three elasticity dimensions, that is, cost, quality,and resources, enabling it to increase and decrease its cost,quality, or available resources, as to accommodate specificrequirements. Recently, in [14], elasticity is defined by usingthe expression 1/(π Γ π), where π denotes the average time toswitch from an underprovisioning state to an elevated stateand π denotes the offset between the actual scaling and theautoscaling. Existing definitions of elasticity fail to capturethe essence when elastic resource provisioning is performedwith virtual machines, and the formulas of elasticity arenot suitable for quantifying elasticity. For example, π in theabove expression is difficult to obtain when resource of acloud is increasing or decreasing. In contrast, the definitionproposed in our work reflects the essence of elasticity, and thecalculation formula focuses on how to measure the elasticityvalue effectively.
There aremany approaches to predicting elasticity, antici-pating the system load behavior, and deciding when and howto scale in/out resources by using heuristics and mathemat-ical/analytical techniques. In [4], the authors established anelasticity metric aiming to capture the key elasticity charac-teristics. In [15], the authors proposed execution platformsand reconfiguration points to reflect the proposed elasticitydefinition. In [5, 7, 16β18], the authors adopted predictivetechniques to scale resources automatically. Although thesetechniques perform well in elasticity prediction, furthermeasurement of elasticity is not covered. In [4], the authorsjust outlined an elasticity benchmarking approach focusingon special requirements on workload design and implemen-tation. In [15], the authors used thread pools as a kind ofelastic resource of the Java virtual machine and presentedpreliminary results of running a novel elasticity bench-mark which reveals the elastic behavior of the thread poolresource. These studies mainly present initial research. Inmost elasticity work, different elasticity benchmark programsare expected to execute on different systems over varyingdata sizes and reflect their potential elasticity, but they canonly get a macroscopic view of elasticity analysis rather thanthe calculation of the elasticity value. In contrast, our workperforms in-depth research focusing on the measurement ofelasticity value.
2.2. Analytical Modeling. Continuous-time Markov chain(CTMC) models have been used for modeling variousrandom phenomena occurring in queuing theory, genetics,demography, epidemiology, and competing populations [19].CTMC has been applied in a lot of studies to adjust resourceallocation in cloud computing. Khazaei et al. proposed ananalytical performance model that addresses the complexityof cloud data centers by distinct stochastic submodels using
Scientific Programming 3
CTMC [20]. Ghosh et al. proposed a performance modelthat quantifies power performance trade-offs by interactingstochastic submodels approach using CTMC [21]. Pacheco-Sanchez et al. proposed an analytical performancemodel thatpredicts the performance of servers deployed in the cloud byusing CTMC [22]. Ghosh et al. proposed a stochastic rewardnet that quantifies the resiliency of IaaS cloud by usingCTMC[23, 24]. However, to the best of our knowledge, CTMChas never been applied in the research of cloud elasticity.Our work in this paper adopts a CTMC model for effectiveelasticity measurement.
3. Definition of Cloud Elasticity
In this section, we first present a detailed discussion ofdifferent states which characterize the elastic behavior of asystem. Then, we formally define elasticity that is applied incloud platforms.
3.1. Notations and Preliminaries. For clarity and convenience,Notations describes the correlated variables which are usedin the following sections. To elaborate the essence of cloudelasticity, we give the various states that are used in ourdiscussion. Let π denote the number of VMs in service andlet π be the number of requests in the system.
(1) Just-in-Need State. A cloud platform is in a just-in-need state if π < π β©½ 3π. πj is defined as the accu-mulated time in all just-in-need states.
(2) Overprovisioning State. A cloud platform is in anoverprovisioning state if 0 β©½ π β©½ π. πo is defined asthe accumulated time in all overprovisioning states.
(3) Underprovisioning State. A cloud platform is in anunderprovisioning state if π > 3π. πu is defined as theaccumulated time in all underprovisioning states.
Notice that constants 1 and 3 in this paper are only forillustration purpose and can be any other values, dependingon how an elastic cloud platform is managed. Differentcloud users and/or applications may prefer different boundsof the hypothetical just-in-need states. The length of theinterval between the upper (e.g., 3π) and lower (e.g., π)bounds controls the reprovisioning frequency. Narrowingdown the interval leads to higher reprovision frequency fora fluctuating workload.
The just-in-need computing resource denotes a balancedstate, in which the workload can be properly handled andquality of service (QoS) can be satisfactorily guaranteed.Computing resource overprovisioning, though QoS can beachieved, leads to extra but unnecessary cost to rent the cloudresources. Computing resource underprovisioning, on theother hand, delays the processing of workload and may be atthe risk of breaking QoS commitment.
3.2. Elasticity Definition in Cloud Computing. In this section,we present our elasticity definition for a realistic cloudplatform and present mathematical foundation for elasticityevaluation.The definition of elasticity is given from a compu-tational point of view and we develop a calculation formula
for measuring elasticity value in virtualized clouds. Let πm bethemeasuring time, which includes all the periods in the just-in-need, overprovisioning, andunderprovisioning states; thatis, πm = πj + πo + πu.
Definition 1. The elasticity πΈ of a cloud perform is thepercentage of timewhen the platform is in just-in-need states;that is, πΈ = πj/πm = 1 β πo/πm β πu/πm.
Broadly defining, elasticity is the capability of deliveringpreconfigured and just-in-need virtual machines adaptivelyin a cloud platform upon the fluctuation of the computingresources required. Practically it is determined by the timeneeded from an underprovisioning or overprovisioning stateto a balanced resource provisioning state. Definition 1 pro-vides amathematical definition which is easily and accuratelymeasurable. Cloud platforms with high elasticity exhibit highadaptivity, implying that they switch from an overprovi-sioning or an underprovisioning state to a balanced statealmost in real time. Other cloud platforms take longer timeto adjust and reconfigure computing resources. Although itis recognized that high elasticity can also be achieved viaphysical host standby, we argue that, with virtualization-enabled computing resource provisioning, elasticity can bedelivered in a much easier way due to the flexibility of servicemigration and image template generation.
Elasticity πΈ reflects the degree to which a cloud platformchanges upon the fluctuation of workloads and can bemeasured by the time of resource scaling by the quantityand types of virtual machine instances. We use the followingequation to calculate its value:
πΈ = 1 β(πo + πu)
πm= 1 βπoπmβπuπm, (1)
where πm denotes the total measuring time, in which πois the overprovisioning time which accumulates each singleperiod of time that the cloud platform needs to switchfrom an overprovisioning state to a balanced state and πu isthe underprovisioning time which accumulates each singleperiod of time that the cloud platform needs to switch froman underprovisioning state to a corresponding balanced state.
Let πj, πo, and πu be the accumulated probabilities ofjust-in-need states, overprovisioning states, and underprovi-sioning states, respectively. If πm is sufficiently long, we haveπj = πj/πm, πo = πo/πm, and πu = πu/πm. Therefore, we get
πΈ = πj = 1 β πo β πu. (2)
Equation (1) can be used when elasticity is measured bymonitoring a real system. Equation (2) can be used whenelasticity is calculated by using our CTMCmodel. If elasticitymetrics are well defined, elasticity of cloud platforms couldeasily be captured, evaluated, and compared.
We would like to mention that the primary factors ofelasticity, that is, the amount, frequency, and time of resourcereprovisioning, are all summarized in πo and πu (i.e., πo andπu). Elasticity can be increased by changing these factors. Forexample, one can maintain a list of standby or underutilizedcompute nodes. These nodes are prepared for the upcoming
4 Scientific Programming
Resource demandUnderprovisioningResource supplyOverprovisioning
Just-in-need
Measure time
Prov
ision
ed re
sour
ces B11 B12
A11
(a) Elastic cloud resource provisioning in cloud platform π΄
Resource demandUnderprovisioningResource supplyOverprovisioning
Just-in-need
Measure time
Prov
ision
ed re
sour
ces
B21
A21
A22
(b) Elastic cloud resource provisioning in cloud platform π΅
Figure 1: An example of elasticity metrics.
surge ofworkload, if there is any, tominimize the time neededto start these nodes. Such a hot standby strategy increasescloud elasticity by reducing πu.
3.3. An Example. In Figure 1, π΄11= 3 hours, π΄
21= 5 hours,
and π΄22= 4 hours are the time spans in underprovisioning
states, and π΅11= 4 hours, π΅
12= 5 hours, and π΅
21= 10 hours
are the time spans in overprovisioning states. The measuringtime of cloud platform π΄ is ππ΄m = 24 hours and cloudplatform π΅ is ππ΅m = 26 hours. So π
π΄
u = π΄11 = 3 hours (i.e.,underprovisioning time of cloud platform π΄), ππ΄o = π΅11 +π΅12= 9 hours (i.e., overprovisioning time of cloud platform
π΄), ππ΅u = π΄21 + π΄22 = 9 hours (i.e., underprovisioningtime of cloud platform π΅), and ππ΅o = π΅21 = 10 hours (i.e.,overprovisioning time of cloud platform π΅). According to (1),the elasticity value of cloud platform π΄ is πΈπ΄ = 1 β ππ΄o /π
π΄
m β
ππ΄
u /ππ΄
m = 0.5, and the elasticity value of cloud platform π΅ isπΈπ΅= 1 β π
π΅
o /ππ΅
m β ππ΅
u /ππ΅
m = 0.27. As can be seen, a greaterelasticity value would exhibit better elasticity.
3.4. Relevant Properties of Clouds. In this section, we com-pare cloud elasticity with a few other relevant concepts, suchas cloud resiliency, scalability, and efficiency.
Resiliency. Laprie [25] defined resiliency as the persistence ofservice delivery that can be trusted justifiably, when facingchanges. Therefore, cloud resiliency implies (1) the extent towhich a cloud systemwithstands the external workload varia-tion and under which no computing resource reprovisioningis needed and (2) the ability to reprovision a cloud systemin a timely manner. We think the latter implication definesthe cloud elasticity while the former implication only existsin cloud resiliency. In our elasticity study, we will focus onthe latter one.
Scalability. Elasticity is often confused with scalability inmore ways than one. Scalability reflects the performance
speedup when cloud resources are reprovisioned. In otherwords, scalability characterizes how well in terms of per-formance a new compute cluster, either larger or smaller,handles a given workload. On the other hand, elasticityexplains how fast in terms of the reprovisioning time thecompute cluster can be ready to process the workload.Cloud scalability is impacted by quite a few factors such asthe compute node type and count and workload type andcount. For example, Hadoop MapReduce applications typi-cally scale much better than other single-thread applications.It can be defined in terms of scaling number of threads,processes, nodes, and even data centers. Cloud elasticity,on the other hand, is only constrained by the capabilitythat a cloud service provider offers. Other factors that arerelevant to cloud elasticity include the type and count ofstandby machines, computing resources that need to bereprovisioned. Different from cloud scalability, cloud elastic-ity does not concern workload/application type and countat all.
Efficiency. Efficiency characterizes how cloud resource canbe efficiently utilized as it scales up or down. This conceptis derived from speedup, a term that defines a relative per-formance after computing resource has been reconfigured.Elasticity is closely related to efficiency of the clouds. Effi-ciency is defined as the percentage of maximumperformance(speedup or utilization) achievable. High cloud elasticityresults in higher efficiency. However, this implication isnot always true, as efficiency can be influenced by otherfactors independent of the system elasticitymechanisms (e.g.,different implementations of the same operation). Scalabilityis affected by cloud efficiency. Thus, efficiency may enhanceelasticity, but not sufficiency. This is due to the fact thatelasticity depends on the resource types, but efficiency is notlimited by resource types. For instance, with a multitenantarchitecture, users may exceed their resources quota. Theymay compete for resources or interfere each otherβs jobexecutions.
Scientific Programming 5
π0 π1 π2 πnπnβ1πnβ2
π1 π2 π3 πnβ1 πn πn+1
Β· Β· Β· Β· Β· Β·0 1 2 3 n β 2 n β 1 n n + 1
Figure 2: State-transition-rate diagram for a birth-death process.
Service requestqueue
π
Incomingservice
requests
Β·Β·Β·VM1 VM2 VM3
Figure 3: Modeling an elastic cloud computing platform as an extendedπ/π/π queuing system.
4. Elasticity Analysis Using CTMC
In this paper, we implement the cloud elasticity computingmodel using CTMC.
4.1. A Queuing Model. This section mainly explains why thecontinuous-time Markov chain (CTMC) can be applied tocompute cloud elasticity and the connection between them.
A continuous-time Markov chain is a continuous time,discrete-state Markov process. Many CTMC have transitionsthat only go to neighboring states, that is, either up oneor down one; they are called birth-and-death processes.Motivated by populationmodels, a transition up one is calleda birth, while a transition down one is called a death. Thebirth rate in state π is denoted by π
π, while the death rate in
state π is denoted by ππ. The state-transition-rate diagram for
a birth-and-death process (with state space {0, 1, . . . , π}) takesthe simple linear form shown in Figure 2.
In many applications, it is natural to use birth-and-deathprocesses. One of the queuing models is π/π/π queue,which has π servers and unlimited waiting room. The mainproperties of a queuing system are as follows.
(1) Requests arrive in a Poisson process with parameterπ.
(2) The service times are exponential random variableswith parameter π.
So a queuing system is a birth-and-death process withMarkov property.
A cloud computing service provider serves customersβservice requests by using a multiserver system. An elasticcloud computing platform treated as a multiserver system
and modeled as an extended π/π/π queuing system isshown in Figure 3. Assume that service requests arrive byfollowing a Poisson process and task service times areindependent and identically distributed random variablesthat follow an exponential distribution. When a runningrequest finishes, the capacity used by the corresponding VMis released and becomes available for serving the next request.The request at the head of the queue is processed (i.e., first-come-first-served) on a runningVM if there is capacity to runa scheduled request. Elastic resource provisioning cannot bedone with physical machines, and only virtual machines canbe reconfigured in real time. A cloud platform is able to adaptto variation in workload by starting up or shutting off VMs inan autonomic manner, avoiding overprovisioning or under-provisioning. If no enough running VMs are available (e.g.,underprovisioning state), a new VM is started up and usedfor service. If there are excessive VMs (e.g., overprovisioningstate), redundant VMs are shut off.
According to (1) and (2), the calculation of the elastic-ity value needs to count the accumulated time in all theoverprovisioning and underprovisioning states. In real cloudplatforms, it is possible to record the overprovisioning timeand underprovisioning times. Furthermore and fortunately,the accumulated probability of both overprovisioning andunderprovisioning states can be computed using our pro-posed CTMCmodel as discussed in the next section.
4.2. Elastic Cloud Platform Modeling. To model elastic cloudplatforms, we make the following assumptions.
(i) All VMs are homogeneous with the same servicecapability and are added/removed one at a time.
6 Scientific Programming
4,1 4,2 4,3 4,4 4,5 4,6 4,7 4,8 4,9 4,10
3,0
4,0
3,1 3,2 3,3 3,4 3,5 3,6 3,7 3,8 3,9 3,10
2,0 2,1 2,2 2,3 2,4 2,5 2,6 2,7 2,8 2,9 2,10
1,0 1,1 1,2 1,3 1,4 1,5 1,6 1,7 1,8 1,9 1,10
M/M/4
M/M/3
M/M/2
M/M/1
π
π π
π
π
π π π π π π π π π π
π π π π π π π π π π π
π π π π π π π π π π π
π π π π π π π π π π π
π π π π π π π π π π π
Β· Β· Β·
Β· Β· Β·
Β· Β· Β·
Β· Β· Β·
......
......
......
......
......
...
π½ π½ π½
π½
π½ π½ π½
π½ π½ π½
π½ π½ πΌ
πΌπΌπΌπΌ
πΌ πΌ πΌ πΌ πΌ πΌ πΌ
2π
2π 2π 2π 2π 2π 2π 2π 2π 2π
2π
2π 3π 3π
3π3π
3π 3π 3π 3π 3π 3π
4π4π4π4π4π4π4π
Figure 4: State-transition-rate diagram of our extendedπ/π/π queuing system.
(ii) The user request arrivals are modeled as a Poissonprocess with rate π.
(iii) The service time, the start-up time, and the shut-off time of each VM are governed by exponentialdistributions with rates π, πΌ, and π½, respectively [26].
(iv) Let π denote the number of virtual machines that arecurrently in service, and let π denote the number ofrequests that are receiving service or in waiting.
(v) Let statev(π, π) denote the various states of a cloudplatform when the virtual machine number is π andthe request number is π. Let the hypothetical just-in-need state, overprovisioning state, and underprovi-sioning state be JIN, OP, and UP, respectively. We canset the equations of the relation between the virtualmachine number and the request number as follows:
statev (π, π) ={{{{
{{{{
{
OP, if 0 β€ π β€ π;
JIN, if π < π β€ 3π;
UP, if π > 3π.
(3)
The hypothetical just-in-need state, overprovisioningstate, and underprovisioning state are listed in Table 1.
Based on these assumptions, we build a two-dimensionalcontinuous-time Markov chain (CTMC) for our extendedπ/π/π queuing system shown in Figure 4, which is actuallya mixture of π/π/π systems for all π = 1, 2, 3, . . .. TheCTMC model records the number of VMs and the numberof user requests received for service, which can eventually beemployed to calculate the elastic value πΈ.
Each state in the model, shown in Figure 4, is labeledas (π, π), where π (π β {1, . . . , π}) denotes the number ofvirtual machines that are currently processing requests and
Table 1: The relation between the virtual machine number and therequest number.
VMnumber
Overprovisioningstate
Just-in-needstate
Underprovisioningstate
1 0 β©½ π β©½ 1 1 < π β©½ 3 π > 32 0 β©½ π β©½ 2 2 < π β©½ 6 π > 63 0 β©½ π β©½ 3 3 < π β©½ 9 π > 94 0 β©½ π β©½ 4 4 < π β©½ 12 π > 12...
.
.
.
.
.
.
.
.
.
π 0 β©½ π β©½ π π < π β©½ 3π π > 3π
.
.
.
.
.
.
.
.
.
.
.
.
π (π β {0, 1, . . . , π}) denotes the number of requests that arereceiving service. For the purpose of numerical calculation,we set the maximum number of VMs that can be deployed asπ, which is sufficiently large to guarantee enough accuracy.Similarly, the maximum π is π. Let π be the service rate ofeach VM. So the total service rate for each state is the productof number of running VMs and π.
The state transition in an elastic cloud computing modelcan occur due to user request arrival, service completion,virtual machine start-up, or virtual machine shut-off. In state(π, π), according to Table 1, the state can be determined asβjust-in-need,β βunderprovisioning,β or βoverprovisioning.βDepending on the upcoming event, four possible transitionscan occur.
Case 1. When a new request arrives, the system transits tostate (π, π + 1) with rate π.
Case 2. When a requested service is completed, if the systemexamines the state as not βoverprovisioning,β the system
Scientific Programming 7
moves back to state (π, π β 1) with total service rate ππ. If thesystem examines the state as βoverprovisioningβ and π = π,the systemmoves back to state (π, π β 1)with total service rate(π β 1)π, because a server is shutting off and cannot performany task at the moment. If the system examines the state asβoverprovisioningβ and π ΜΈ= π, the system moves back to state(π, π β 1) with total service rate ππ.
Case 3. The system examines the state as βunderprovision-ingβ and transits to state (π + 1, π) with rate πΌ.
Case 4. The system examines the state as βoverprovisioningβand transits to state (π β 1, π) with rate π½.
We use ππ,πto denote the steady-state probability that the
system stays in state (π, π), where π β {1, . . . , π} and π β{0, 1, . . . , π}.We can now set the balance equations as follows:
πππ,π= πΎ2πππ,π+1+ π½ππ+1,π,
if π = 1, π = 0;
(π + πΎ1π) ππ,π= πππ,πβ1+ πΎ2πππ,π+1+ π½ππ+1,π,
if π = 1, 0 < π β€ π + 1;
(π + πΎ1π) ππ,π= πππ,πβ1+ πΎ2πππ,π+1,
if π = 1, π + 1 < π β€ 3π;
(π + πΎ1π + πΌ) π
π,π= πππ,πβ1+ πΎ2πππ,π+1,
if π = 1, 3π < π < π;
(πΎ1π + πΌ) π
π,π= πππ,πβ1, if π = 1, π = π;
(π + π½) ππ,π= πΎ2πππ,π+1+ π½ππ+1,π,
if 1 < π < π, π = 0;
(π + πΎ1π + π½) π
π,π= πππ,πβ1+ πΎ2πππ,π+1+ π½ππ+1,π,
if 1 < π < π, 0 < π β€ π;
(π + πΎ1π) ππ,π= πππ,πβ1+ πΎ2πππ,π+1+ π½ππ+1,π,
if 1 < π < π, π = π + 1;
(π + πΎ1π) ππ,π= πππ,πβ1+ πΎ2πππ,π+1,
if 1 < π β€ π, π + 1 < π β€ 3 (π β 1) ;
(π + πΎ1π) ππ,π= πππ,πβ1+ πΎ2πππ,π+1+ πΌππβ1,π,
if 1 < π < π, 3 (π β 1) < π β€ 3π;
(π + πΎ1π + πΌ) π
π,π= πππ,πβ1+ πΎ2πππ,π+1+ πΌππβ1,π,
if 1 < π < π, 3π < π < π;
(πΎ1π + πΌ) π
π,π= πππ,πβ1+ πΌππβ1,π,
if 1 < π < π, π = π;
(π + π½) ππ,π= πΎ2πππ,π+1, if π = π, π = 0;
(π + πΎ1π + π½) π
π,π= πππ,πβ1+ πΎ2πππ,π+1,
if π = π, 0 < π β€ π + 1;
(π + πΎ1π) ππ,π= πππ,πβ1+ πΎ2πππ,π+1+ πΌππβ1,π,
if π = π, 3 (π β 1) < π < π;
πΎ1πππ,π= πππ,πβ1+ πΌππβ1,π,
if π = π, π = π,(4)
where
πΎ1= π, if π > π;
πΎ1= π β 1, if π = π, π ΜΈ= 1;
πΎ1= 1, if π = π, π = 1;
πΎ1= π, if π < π;
πΎ2= π + 1, if π > π + 1;
πΎ2= π, if π = π + 1, π + 1 ΜΈ= 1;
πΎ2= 1, if π = π + 1, π + 1 = 1;
πΎ2= π, if π < π + 1,
π
β
π=1
π+1
β
π=0
ππ,π= 1.
(5)
In the above equations, π, π, πΌ, and π½ are the requestarrival rate (i.e., the interarrival times of service requests areindependent and identically distributed exponential randomvariables with mean 1/π), the service rate (i.e., the averagenumber of tasks that can be finished by a VM in one unitof time), the virtual machine start-up rate (i.e., a VM needstime π = 1/πΌ to turn on), and the virtual machine shut-off rate (i.e., a VM needs time π = 1/π½ to shut down),respectively. The balance equations link the probabilities ofentering and leaving a state in equilibrium.The total numberof equations isπΓ (π+ 1) + 1, but there are onlyπΓ (π+ 1)variables:π
1,0, π1,1, . . . , π
π,π.Therefore, in order to deriveπ
π,π,
we need to remove one of the equations to obtain the uniqueequilibrium solution. Unfortunately, the steady-state balanceequations cannot be solved in a closed form; hence, we mustresort to a numerical solution.
The input and output parameters of our CTMCmodel aresummarized in the following.
Input. The request arrival rate is π, the service rate is π, thevirtual machine start-up rate is πΌ, and the virtual machineshut-off rate is π½. (In addition, the definitions of βjust-in-need,β βunderprovisioning,β and βoverprovisioningβ statesshould also be included.)
8 Scientific Programming
Output
(i) The accumulated underprovisioning state probabilityπu of a cloud platform is as follows:
πu =π
β
π=1
π+1
β
π=3π+1
ππ,π, (6)
where ππ,πis the steady-state probability.
(ii) The accumulated overprovisioning state probabilityπo of a cloud platform is as follows:
πo =π
β
π=2
π
β
π=0
ππ,π, (7)
where ππ,πis the steady-state probability.
(iii) The elasticity value πΈ of a cloud platform is obtainedby (2), (6), and (7).
5. Model Analysis
In this section, we present some numerical results obtainedbased on the proposed elastic cloud platformmodeling, illus-trating and quantifying the elasticity value under differentload conditions and different system parameters. All thenumerical data in this section are obtained by setting π =1,000, that is, the maximum number of VMs that can bedeployed, to guarantee sufficient numerical accuracy.
5.1. Varying the Arrival Rate. For the first scenario, we haveconsidered a systemwith different service rates (π = 100, 120,140, 160, and 180 jobs/hour), while the arrival rate is a variablefrom π = 100 to 400 jobs/hour in sixteen steps. In all cases,the virtualmachine start-up rate and virtualmachine shut-offrate are assigned values of πΌ = 120 VMs/hour and π½ = 540VMs/hour.
Figure 5 illustrates that the elasticity value is an increasingfunction of the arrival rate. As can been seen, it increasesrather quickly when the arrival rate is up to 300 and smoothlywhen the arrival rate is higher. This behavior is due tothe fact that increasing π results in noticeable reduction ofthe probability of overprovisioning but slight change of theprobability of underprovisioning. Furthermore, it is observedthat the elasticity value decreases as the service rate increases,as described in the next section.
5.2. Varying the Service Rate. For the second scenario, wehave considered a systemwith different arrival rates (π = 200,220, 240, 260, and 280 jobs/hour), while the service rate is avariable from π = 10 to 290 jobs/hour in fifteen steps. In allcases, the virtual machine start-up rate and virtual machineshut-off rate are assigned values of πΌ = 120 VMs/hour andπ½ = 540 VMs/hour.
Figure 6 illustrates that the elasticity value is a decreasingfunction of the service rate. It shows that, for a fixed arrivalrate, increasing service rate decreases the elasticity valuesharply and almost linearly. This phenomenon is due to thefact that increasing π results in noticeable increment of the
E1(π = 100)E2(π = 120)E3(π = 140)
E4(π = 160)E5(π = 180)
100
120
140
160
180
200
220
240
260
280
300
320
340
360
380
400
Arrive rate (jobs/h)
0.44
0.46
0.48
0.50
0.52
0.54
0.56
0.58
0.60
0.62
0.64
0.66
0.68
0.70
0.72
Elas
ticity
Figure 5: Elasticity versus arrival rate.
E1(π = 200)E2(π = 220)E3(π = 240)
E4(π = 260)E5(π = 280)
10 30
50
70
90
110
130
150
170
190
210
230
250
270
290
Service rate (jobs/h)
0.3
0.4
0.5
0.6
0.7
0.8
0.9
1.0
Elas
ticity
Figure 6: Elasticity versus service rate.
probability of overprovisioning, and change of the probabilityof underprovisioning does not affect the decreasing trend ofthe just-in-need probability. Figure 6 also confirms that theelasticity value is an increasing function of the arrival rate.
5.3. Varying the Virtual Machine Start-Up Rate. For thethird scenario, Figure 7 shows numerical results for a fixedarrival rate, service rate, and virtual machine shut-off rate butdifferent virtual machine start-up rates.
First, we characterize the elasticity value by presenting theeffect of different arrival rates (π = 200, 220, 240, 260, and 280jobs/hour) and the virtual machine start-up rate is a variablefrom πΌ = 120 to 260 VMs/hour in fifteen steps. In all cases,other system parameters are set as follows. The service rate is
Scientific Programming 9
Virtual machine start-up rate (VMs/h)
120
130
140
150
160
170
180
190
200
210
220
230
240
250
260
E1(π = 200)E2(π = 220)E3(π = 240)
E4(π = 260)E5(π = 280)
0.675
0.680
0.685
0.690
0.695
Elas
ticity
(a) Variable arrival rate
Virtual machine start-up rate (VMs/h)
0.56
0.58
0.60
0.62
0.64
0.66
0.68
Elas
ticity
E1(π = 100)E2(π = 120)E3(π = 140)
E4(π = 160)E5(π = 180)
120
130
140
150
160
170
180
190
200
210
220
230
240
250
260
(b) Variable service rate
Figure 7: Elasticity versus virtual machine start-up rate.
π = 100 jobs/hour, and the virtual machine shut-off rate isπ½ = 540VMs/hour. As can be seen in Figure 7(a), it increasesslightly when the virtualmachine start-up rate increases.Thisis due to the fact that, for high virtual machine start-up rate,each virtual machine start-up time is shorter, meaning thatless time is needed to switch from an underprovisioning stateto a balanced state, so the probability of underprovisioningπuis smaller, while the probability of overprovisioning πo doesnot change toomuch, and the probability of just-in-need πj isincreasing.
Second, we also analyze the effects of different servicerates (π = 100, 120, 140, 160, and 180 jobs/hour), while thevirtual machine start-up rate is a variable from πΌ = 120to 260 VMs/hour in fifteen steps. In all cases, other systemparameters are set as follows. The arrival rate is π = 200jobs/hour, and the virtual machine shut-off rate is π½ = 540VMs/hour. It can be seen in Figure 7(b) that the elasticityvalue increases slightly with increasing virtual machine start-up rate.
The results allow us to conclude the increasing elasticityvalue at increasing virtual machine start-up rate for a fixedarrive rate, service rate, and virtual machine shut-off rate. Inother words, increasing the virtual machine start-up rate willdecrease the probability of underprovisioning and increasethe just-in-need probability. These behaviors (see Figure 7)confirm that the elasticity value of a cloud platform has arelationship to its virtual machine start-up speed.
5.4. Varying the Virtual Machine Shut-Off Rate. For thefourth scenario, Figure 8 shows numerical results for a fixedarrival rate, service rate, and virtual machine start-up rate butdifferent virtual machine shut-off rates.
We examine the effect of virtual machine shut-off rateon elasticity. For different arrival rates (π = 200, 220, 240,260, and 280 jobs/hour), the virtual machine shut-off rate is avariable from π½ = 540 to 680VMs/hour in fifteen steps. In all
cases, other system parameters are set as follows. The servicerate is π = 100 jobs/hour, and the virtual machine start-uprate is πΌ = 120 VMs/hour. It can be seen from Figure 8(a)that the elasticity value increases slightly where the virtualmachine shut-off rate is increased from 540 to 680VMs/hour.This happens because the virtual machine shut-off time isshorter, and a platformbecomesmore responsive, resulting indiminishing overprovisioning time which is the accumulatetime for the system to switch from an overprovisioning stateto a balanced state. Furthermore, the probability of overpro-visioning πo is smaller, the probability of underprovisioningπu shows slight change, and the probability of just-in-need πjis increasing.
We also calculate the elasticity value under the differentservice rates (π = 100, 120, 140, 160, and 180 jobs/hour), whilethe virtual machine shut-off rate is a variable from π½ = 540to 680 VMs/hour in fifteen steps. The arrival rate is π =200 jobs/hour, and the virtual machine start-up rate is πΌ =120 VMs/hour. In Figure 8(b), the elasticity value increasesslightly by increasing the virtual machine shut-off rate. Thisis also because of the corresponding reduction in virtualmachine shut-off time, guaranteeing shorter overprovision-ing probability πo.
Based on these results, we can conclude the increasingelasticity value at increasing virtual machine shut-off rate fora fixed arrive rate, service rate, and virtual machine start-up rate. In other words, increasing the virtual machine shut-off rate will decrease the probability of overprovisioningand increase the just-in-need probability. These behaviors ofFigure 8 confirm that the elasticity value of a cloud platformhas a relationship to its virtual machine shut-off speed.
6. Simulation Results
In this section, we present our elastic cloud simulationsystem calledCloud Elasticity Value. Its aim is to demonstrate
10 Scientific Programming
540
550
560
570
580
590
600
610
620
630
640
650
660
670
680
Virtual machine shut-off rate (VMs/h)
E1(π = 200)E2(π = 220)E3(π = 240)
E4(π = 260)E5(π = 280)
0.674
0.6760.6780.6800.6820.6840.6860.6880.6900.6920.6940.6960.6980.7000.702
Elas
ticity
(a) Variable arrival rate
E1(π = 100)E2(π = 120)E3(π = 140)
E4(π = 160)E5(π = 180)
540
550
560
570
580
590
600
610
620
630
640
650
660
670
680
Virtual machine shut-off rate (VMs/h)
0.54
0.56
0.58
0.60
0.62
0.64
0.66
0.68
Elas
ticity
(b) Variable service rate
Figure 8: Elasticity versus virtual machine shut-off rate.
that our elasticity measurement is correct and effective incomputing and comparing the elasticity value and to showcloud elasticity under different parameter settings.
6.1. Design of the Simulator. Our simulation uses the samecode base for the elasticity measurement as the real imple-mentation. The simulator is implemented in about 40,000lines of C++ code. It runs in a Linux box over a rack-mountserver with IntelοΏ½CoreοΏ½2 Duo CPU and 4.00GB of memory.
The simulator consists of four modules, that is, the taskgenerator module, the virtual machine monitor module, therequest monitor module, and the queue module. The taskgenerator module produces simulation of Poisson distribu-tion requests.The virtualmachinemonitormodule is used fordeciding whether to start up and shut off the virtualmachinesand recording the start-up and shut-off times. The requestmonitor module is used to count how many requests arebeing serviced in the system and to record the service times.Arrived service requests are first placed in a queue moduleand recorded their arrival times before they are processed byany virtual machine.
The main process of the simulator is listed as follows.
Step 1. The task generator module produces simulation ofPoisson distribution requests. When the service requestsarrive, they are placed in a queue module and recorded theirarrival times.
Step 2. The virtual machine monitor module determineswhether to start up or shut off the VMs and records the start-up and shut-off times.
Step 3. The request monitor module determines whetherthere is a request in the queue. If there is a request, it takesa request and assigns it to a running virtual machine andrecords the service time.
Step 4. After the simulation time is over, the simulatorcounts up the accumulated time in overprovisioning andunderprovisioning states and returns the elasticity valueusing (1).
6.2. Simulation Results and Analysis. We have evaluatedcloud elasticity values using two methods, that is, (1) theelasticity values in terms of the steady-state probabilitiesobtained for the given parameter and (2) the elasticity valuesin terms of our simulation system obtained for the sameparameters.We compare ourCTMCmodel solutionswith theresults produced by the simulation method.
We have considered the arrival rate characterized by π =60, 200, and 600 jobs/hour. The service rate values chosenare π = 60, 200, and 600 jobs/hour. In all cases, the virtualmachine start-up rate is assigned the value of πΌ = 300VMs/hour, while the virtual machine shut-off rate is π½ = 540VMs/hour.
Table 2 shows the difference between the elasticity valuesobtained by the CTMC model and the simulator. FromTable 2, we can see that the elasticity values between the twocases are very close, with the maximum relative differenceonly 0.8 percent. The agreement between the simulationand CTMC model results is excellent, which confirms thevalidity of our CTMC model. So we conclude that theproposed elasticity quantifying and measuring method usingthe continuous-timeMarkov chain (CTMC)model is correctand effective.
7. Experiments on Real Systems
7.1. Experiment Environment. We have conducted our exper-iments on LuCloud, a cloud computing environment locatedin Hunan University. On top of hardware and UbuntuLinux 12.04 operating system, we install KVM virtualization
Scientific Programming 11
Table 2: Comparison of CTMCmodel results and simulation results.
Arrival rate Service rate Start-up rate Shut-off rate Method DifferenceCTMCmodel Simulation
60 60 300 540 0.705212 0.702837 0.3%60 200 300 540 0.445756 0.475257 0.4%60 600 300 540 0.635151 0.637240 0.3%200 60 300 540 0.735167 0.739055 0.5%200 200 300 540 0.543948 0.546414 0.5%200 600 300 540 0.235727 0.234727 0.4%600 60 300 540 0.827098 0.828784 0.2%600 200 300 540 0.688974 0.684784 0.6%600 600 300 540 0.435171 0.438784 0.8%
Table 3: Comparison of CTMCmodel results and experimental results with exponential service times.
Arrival rate Service rate Start-up rate Shut-off rate Method DifferenceCTMCmodel Experiment
60 60 120 540 0.701205 0.706082 0.6%60 200 120 540 0.475480 0.479752 0.9%60 600 120 540 0.631525 0.649275 3.0%200 60 120 540 0.731117 0.739533 1.2%200 200 120 540 0.516099 0.521308 1.0%200 600 120 540 0.221065 0.269039 2.2%600 60 120 540 0.817088 0.826455 1.1%600 200 120 540 0.687533 0.681169 0.9%600 600 120 540 0.409537 0.491034 0.9%
software which virtualizes the infrastructure and providesunified computing and storage resources. To create a cloudenvironment, we install CloudStack open-source cloud envi-ronment, which is composed of a cluster and responsible forglobal management, resource scheduling, task distribution,and interaction with users. The cluster is managed by acloud manager (8 AMD Opteron Processor 4122 CPU, 8GBmemory, and 1 TB hard disk). We use our elasticity testingplatform to achieve the allocation of resources, that is, virtualmachine start-up and shut-off on LuCloud.
7.2. Experiment Process and Results. First, in order to validatethe proposed model, Table 3 summarizes the comparisonbetween the two approaches, that is, the CTMC model andthe experiments on LuCloud. We have considered the arrivalrate characterized by π = 60, 200, and 600 jobs/hour. Theservice rate values chosen are π = 60, 200, and 600 jobs/hour.The virtual machine start-up rate is assigned the value ofπΌ = 120VMs/hour, and the virtual machine shut-off rate isassigned the value of π½ = 540VMs/hour.
In Table 3, we can observe that the elasticity values ofboth approaches are very close, with the maximum relativedifference only 3.0 percent. We conclude that the proposedCTMC model can be used to compute the elasticity of cloudplatforms and can offer accurate results within reasonabledifference.
Our second set of experiments focus on the robustnessof our model and method, that is, its applicability when
the assumptions of our model are not satisfied. We haveconsidered Gamma distributions for the service times. TheGamma(π, π) distribution is defined in terms of a shapeparameter π and a scale parameter π [27]. We use the sameparameter settings in Table 3, except that the exponentialdistributions of service times are replaced by Gamma distri-butions, that is, Gamma(0.0083, 2), Gamma(0.0025, 2), andGamma(0.00083, 2), such that the service rates are still π =60, 200, and 600 jobs/hour.
From Table 4, we can see that the elasticity values of theCTMC model and the experiments are very close, with themaximum relative difference only 3.3 percent. We observethat the experimental results with Gamma service timesmatch very closely with those of the proposed CTMCmodel.So we conclude that the proposed model and method forquantifying and measuring elasticity using continuous-timeMarkov chain (CTMC) are not only correct and effective,but also robust and applicable to real cloud computingplatforms.
8. Conclusion
In this paper, we have introduced a new definition of cloudelasticity. We have presented an analytical method suitablefor evaluating the elasticity of cloud platforms, by using acontinuous-time Markov chain (CTMC) model. Validationof the analytical results through extensive simulations hasshown that our analytical model is sufficiently detailed tocapture all realistic aspects of resource allocation process,
12 Scientific Programming
Table 4: Comparison of CTMCmodel results and experimental results with Gamma service times.
Arrival rate Start-up rate Shut-off rate Service distribution Method DifferenceCTMCmodel Experiment
60 120 540 Gamma(0.0083, 2) 0.701205 0.716401 2.2%60 120 540 Gamma(0.0025, 2) 0.475480 0.476752 0.3%60 120 540 Gamma(0.00083, 2) 0.631525 0.612930 3.0%200 120 540 Gamma(0.0083, 2) 0.731117 0.711420 2.7%200 120 540 Gamma(0.0025, 2) 0.516099 0.522762 1.3%200 120 540 Gamma(0.00083, 2) 0.221065 0.227146 2.8%600 120 540 Gamma(0.0083, 2) 0.817088 0.835865 2.3%600 120 540 Gamma(0.0025, 2) 0.687533 0.667146 3.0%600 120 540 Gamma(0.00083, 2) 0.409537 0.395865 3.3%
that is, virtual machine start-up and virtual machine shut-off, while maintaining excellent accuracy between CTMCmodel results and simulation results. We have examinedthe effects of various parameters including request arrivalrate, service time, virtual machine start-up rate, and virtualmachine shut-off rate. Our experimental results furtherevidence that the proposed measurement approach can beused to compute cloud elasticity in real cloud platforms.Consequently, cloud providers and users can obtain quanti-tative, informative, and reliable estimation of elasticity, basedon a few essential characterizations of a cloud computingplatform.
Notations
πΈ: The elasticity valueπ: The number of VMs in serviceπ: The number of requests in the queueπj: The accumulated just-in-need timeπo: The accumulated overprovisioning timeπu: The accumulated underprovisioning timeπm: The measuring timeπj: The accumulated probability of just-in-need
statesπo: The accumulated probability of
overprovisioning statesπu: The accumulated probability of
underprovisioning statesπ: The request arrival rateπ: The request service rateπΌ: The virtual machine start-up rateπ½: The virtual machine shut-off rate(π, π): A state in our CTMCmodelππ,π: The steady-state probability of state (π, π)π: The average number of requests in the queueπ: The average response timeπ: The average number of VMs in serviceCPR: The cost-performance ratio.
Competing Interests
The authors declare that they have no competing interests.
Acknowledgments
The research was partially funded by the Key Program ofNational Natural Science Foundation of China (Grants nos.61133005 and 61432005) and the National Natural ScienceFoundation of China (Grants nos. 61370095 and 61472124).
References
[1] J. Cao, K. Li, and I. Stojmenovic, βOptimal power allocation andload distribution for multiple heterogeneous multicore serverprocessors across clouds and data centers,β IEEE Transactionson Computers, vol. 63, no. 1, pp. 45β58, 2014.
[2] M. Bourguiba, K. Haddadou, I. E. Korbi, and G. Pujolle, βIm-proving network I/O virtualization for cloud computing,β IEEETransactions on Parallel and Distributed Systems, vol. 25, no. 3,pp. 673β681, 2014.
[3] Cost-efficient consolidating service for Aliyunβs cloud-scalecomputing, http://kylinx.com/papers/c4.pdf.
[4] N. R. Herbst, S. Kounev, and R. Reussner, βElasticity in cloudcomputing: what it is, and what it is not,β in Proceedings of the10th International Conference on Autonomic Computing (ICACβ13), pp. 23β27, San Jose, Calif, USA, June 2013.
[5] Z. Shen, S. Subbiah, X. Gu, and J. Wilkes, βCloudScale: elasticresource scaling for multi-tenant cloud systems,β in Proceedingsof the 2nd ACM Symposium on Cloud Computing (SOCC β11), p.5, ACM, Cascais, Portugal, October 2011.
[6] G. Galante and L. C. E. de Bona, βA survey on cloud computingelasticity,β in Proceedings of the IEEE/ACM 5th InternationalConference on Utility and Cloud Computing (UCC β12), pp. 263β270, Chicago, Ill, USA, November 2012.
[7] U. Sharma, P. Shenoy, S. Sahu, and A. Shaikh, βA cost-awareelasticity provisioning system for the cloud,β in Proceedingsof the 31st International Conference on Distributed ComputingSystems (ICDCS β11), pp. 559β570, IEEE, Minneapolis, Minn,USA, July 2011.
[8] R.N. Calheiros, C. Vecchiola, D. Karunamoorthy, andR. Buyya,βThe Aneka platform and QoS-driven resource provisioningfor elastic applications on hybrid clouds,β Future GenerationComputer Systems, vol. 28, no. 6, pp. 861β870, 2012.
[9] J. O. FitoΜ, IΜ. Goiri, and J. Guitart, βSLA-driven elastic cloud host-ing provider,β in Proceedings of the 18th Euromicro Conferenceon Parallel, Distributed and Network-based Processing (PDP β10),pp. 111β118, IEEE, Pisa, Italy, February 2010.
Scientific Programming 13
[10] L. Badger, T. Grance, R. Patt-Corner, and J. Voas, Draft CloudComputing Synopsis and Recommendations, vol. 800, NISTSpecial Publication, 2011.
[11] R. Cohen, Defining Elastic Computing, 2009, http://www.elas-ticvapor.com/2009/09/defining-elastic-computing.html.
[12] R. Buyya, J. Broberg, and A. M. Goscinski, Cloud Computing:Principles and Paradigms, vol. 87, JohnWiley & Sons, New York,NY, USA, 2010.
[13] S. Dustdar, Y. Guo, B. Satzger, and H.-L. Truong, βPrinciples ofelastic processes,β IEEE Internet Computing, vol. 15, no. 5, pp.66β71, 2011.
[14] K. Hwang, X. Bai, Y. Shi, M. Li, W. Chen, and Y. Wu, βCloudperformance modeling with benchmark evaluation of elasticscaling strategies,β IEEETransactions on Parallel andDistributedSystems, vol. 27, no. 1, pp. 130β143, 2016.
[15] M. Kuperberg, N. Herbst, J. von Kistowski, and R. Reussner,Defining and Quantifying Elasticity of Resources in Cloud Com-puting and Scalable Platforms, KIT, FakultaΜt fuΜr Informatik,2011.
[16] W. Dawoud, I. Takouna, and C. Meinel, βElastic VM for cloudresources provisioning optimization,β inAdvances inComputingand Communications, A. Abraham, J. L. Mauri, J. F. Buford, J.Suzuki, and S. M. Thampi, Eds., vol. 190 of Communicationsin Computer and Information Science, pp. 431β445, Springer,Berlin, Germany, 2011.
[17] N. Roy, A. Dubey, and A. Gokhale, βEfficient autoscaling inthe cloud using predictive models for workload forecasting,β inProceedings of the IEEE 4th International Conference on CloudComputing (CLOUD β11), pp. 500β507, IEEE, Washington, DC,USA, July 2011.
[18] Z. Gong, X. Gu, and J.Wilkes, βPress: predictive elastic resourcescaling for cloud systems,β in Proceedings of the InternationalConference on Network and Service Management (CNSM β10),pp. 9β16, IEEE, Ontario, Canada, October 2010.
[19] W. J. Anderson, Continuous-Time Markov Chains, SpringerSeries in Statistics: Probability and Its Applications, Springer,New York, NY, USA, 1991.
[20] H. Khazaei, J. MisΜicΜ, V. B. MisΜicΜ, and S. Rashwand, βAnalysis ofa pool management scheme for cloud computing centers,β IEEETransactions on Parallel and Distributed Systems, vol. 24, no. 5,pp. 849β861, 2013.
[21] R. Ghosh, V. K. Naik, and K. S. Trivedi, βPower-performancetrade-offs in IaaS cloud: a scalable analytic approach,β inProceedings of the IEEE/IFIP 41st International Conference onDependable Systems and Networks Workshops (DSN-W β11), pp.152β157, IEEE, Hong Kong, June 2011.
[22] S. Pacheco-Sanchez, G. Casale, B. Scotney, S. McClean, G.Parr, and S. Dawson, βMarkovian workload characterization forQoS prediction in the cloud,β in Proceedings of the IEEE 4thInternational Conference on Cloud Computing (CLOUD β11), pp.147β154, IEEE, Washington, Wash, USA, July 2011.
[23] R. Ghosh, F. Longo, V. K. Naikz, and K. S. Trivedi, βQuantifyingresiliency of IaaS cloud,β in Proceedings of the 29th IEEESymposium on Reliable Distributed Systems, pp. 343β347, IEEE,New Delhi, India, November 2010.
[24] R. Ghosh, D. Kim, andK. S. Trivedi, βSystem resiliency quantifi-cation using non-state-space and state-space analytic models,βReliability Engineering & System Safety, vol. 116, pp. 109β125,2013.
[25] J.-C. Laprie, βFrom dependability to resilience,β in Proceedingsof the 38th IEEE/IFIP International Conference on Dependable
Systems and Networks, pp. G8βG9, Anchorage, Alaska, USA,June 2008.
[26] M. Mao and M. Humphrey, βA performance study on theVM startup time in the cloud,β in Proceedings of the IEEE 5thInternational Conference on Cloud Computing (CLOUD β12), pp.423β430, IEEE, Honolulu, Hawaii, USA, June 2012.
[27] S. Ali, H. J. Siegel, M. Maheswaran, and D. Hensgen, βTask exe-cution timemodeling for heterogeneous computing systems,β inProceedings of the IEEE 9thHeterogeneous ComputingWorkshop(HCW β00), pp. 185β199, Cancun, Mexico, 2000.
Submit your manuscripts athttp://www.hindawi.com
Computer Games Technology
International Journal of
Hindawi Publishing Corporationhttp://www.hindawi.com Volume 2014
Hindawi Publishing Corporationhttp://www.hindawi.com Volume 2014
Distributed Sensor Networks
International Journal of
Advances in
FuzzySystems
Hindawi Publishing Corporationhttp://www.hindawi.com
Volume 2014
International Journal of
ReconfigurableComputing
Hindawi Publishing Corporation http://www.hindawi.com Volume 2014
Hindawi Publishing Corporationhttp://www.hindawi.com Volume 2014
Applied Computational Intelligence and Soft Computing
βAdvancesβinβ
Artificial Intelligence
HindawiβPublishingβCorporationhttp://www.hindawi.com Volumeβ2014
Advances inSoftware EngineeringHindawi Publishing Corporationhttp://www.hindawi.com Volume 2014
Hindawi Publishing Corporationhttp://www.hindawi.com Volume 2014
Electrical and Computer Engineering
Journal of
Journal of
Computer Networks and Communications
Hindawi Publishing Corporationhttp://www.hindawi.com Volume 2014
Hindawi Publishing Corporation
http://www.hindawi.com Volume 2014
Advances in
Multimedia
International Journal of
Biomedical Imaging
Hindawi Publishing Corporationhttp://www.hindawi.com Volume 2014
ArtificialNeural Systems
Advances in
Hindawi Publishing Corporationhttp://www.hindawi.com Volume 2014
RoboticsJournal of
Hindawi Publishing Corporationhttp://www.hindawi.com Volume 2014
Hindawi Publishing Corporationhttp://www.hindawi.com Volume 2014
Computational Intelligence and Neuroscience
Industrial EngineeringJournal of
Hindawi Publishing Corporationhttp://www.hindawi.com Volume 2014
Modelling & Simulation in EngineeringHindawi Publishing Corporation http://www.hindawi.com Volume 2014
The Scientific World JournalHindawi Publishing Corporation http://www.hindawi.com Volume 2014
Hindawi Publishing Corporationhttp://www.hindawi.com Volume 2014
Human-ComputerInteraction
Advances in
Computer EngineeringAdvances in
Hindawi Publishing Corporationhttp://www.hindawi.com Volume 2014
Recommended