On Elasticity Measurement in Cloud Computing

Elasticity is the foundation of cloud performance and can be considered as a great advantage and a key benefit of cloud computing. However, there is no clear, concise, and formal definition of elasticity measurement, and thus no effective approach to elasticity quantification has been developed so far. Existing work on elasticity lack of solid and technical way of defining elasticity measurement 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 a continuous-time Markov chain (CTMC) model, which is easy to use for precise calculation of elasticity value of a cloud computing platform. Our numerical results demonstrate the basic parameters affecting elasticity as measured by the proposed measurement approach. Furthermore, our simulation and experimental results validate that the proposed measurement approach is not only correct but also robust and is effective in computing and comparing the elasticity of cloud platforms. Our research in this paper makes significant contribution to quantitative measurement of elasticity in cloud computing.


Introduction
( ) Motivation. As a subscription-oriented utility, cloud computing has gained growing attention in recent years in both research and industry and is widely considered as a promising way of managing and improving the utilization of data center resources and providing a wide range of computing services [ ]. Virtualization is a key enabling technology of cloud computing [ ]. System virtualization is able to provide abilities to access so ware and hardware resources from a virtual space and enables an execution platform to provide several concurrently usable and independent instances of virtual execution entities, o en called virtual machines (VMs). A cloud computing platform relies on the virtualization technique to acquire more VMs to deal with workload surges or release VMs to avoid resource overprovisioning. Such a dynamic resource provision and management feature is called elasticity. For instance, when VMs do not use all the provided resources, they can be logically resized and be migrated from a group of active servers to other servers, while the idle servers can be switched to the low-power modes (sleep or hibernate) [ ].
Elasticity is the degree to which a system is able to adapt to workload changes by provisioning and deprovisioning resources in an autonomic manner, such that at each point in time the available resources match the current demand as closely as possible [ ]. By dynamically optimizing the total amount of acquired resources, elasticity is used for various purposes. From the perspective of service providers, elasticity ensures better use of computing resources and more energy savings [ ] and allows multiple users to be served simultaneously. From a user's perspective, elasticity has been used to avoid inadequate provision of resources and degradation of system performance [ ] and also achieve cost reduction [ ]. Furthermore, elasticity can be used for other purposes, such as increasing the capacity of local resources [ , ]. Hence, elasticity is the foundation of cloud performance and can be considered as a great advantage and a key bene t of cloud computing.
Elastic mechanisms have been explored recently by researchers from academia and commercial elds, and tremendous e orts have been invested to enable cloud systems to behave in an elastic manner. However, there is no common and precise formula to calculate the elasticity value. Existing de nitions of elasticity in the current research literature are all vague concepts and fail to capture the essence of elastic resource provisioning. ese formulas of elasticity are not suitable for quantifying and measuring elasticity. Moreover, there is no systematic approach that has been proposed to quantify elastic behavior. Only quantitative elasticity value can produce better comparison between different cloud platforms. erefore, the measurement of cloud elasticity should be further investigated. As far as we know, the current reported works are ine ective to cover all aspects of cloud elasticity evaluation and measurement. erefore, we are motivated to develop a comprehensive model and an analytical method to measure cloud elasticity.
( ) Our Contributions. In this paper, we propose a clear and concise de nition to compute elasticity value. In order to do that, an elasticity computing model is established by using a continuous-time Markov chain (CTMC). e proposed computing model can quantify, measure, and compare the elasticity of cloud platforms. e major contributions of this paper are summarized as follows.
(i) First, we propose a new de nition of elasticity in the context of virtual machine provisioning and a precise computational formula of elasticity value.
(ii) Second, we develop a technique of quantifying and measuring elasticity by using a continuous-time Markov chain (CTMC) model. We investigate the elastic calculation model intensively and completely. e model is not only an analytical method, but also an easy way to calculate the elasticity value of a cloud platform quantitatively.
(iii) ird, we examine and evaluate our proposed method through numerical data, simulations, and experiments. e numerical data demonstrate the basic parameters which a ect elasticity in our analytical model. e simulation results validate the correctness of the proposed method. e experimental results on a real cloud computing platform further show the robustness of our model and method in predicting and computing cloud elasticity. e rest of the paper is organized as follows. Section reviews the related work. Section describes the de nition of cloud elasticity. Section develops the computing model of cloud elasticity. Sections , , and present simulation and numerical and experimental results, respectively. Section concludes this paper.

Related Work
. . Elasticity De nition and Measurement.
ere has been some work on elasticity measurement of cloud computing.
In [ ], elasticity is described as the degree to which a system is able to adapt to workload changes by provisioning and deprovisioning resources in an autonomic manner, such that at each point in time the available resources match the current demand as closely as possible. In [ ], elasticity is de ned as the ability of customers to quickly request, receive, and later release as many resources as needed. In [ ], elasticity is measured as the ability of a cloud to map a single user's request to di erent resources. In [ ], elasticity is de ned as dynamic variation in the use of computer resources to meet a varying workload. In [ ], an elastic cloud application or process 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 speci c requirements. Recently, in [ ], elasticity is de ned by using the expression 1/( × ), where denotes the average time to switch from an underprovisioning state to an elevated state and denotes the o set between the actual scaling and the autoscaling. Existing de nitions of elasticity fail to capture the essence when elastic resource provisioning is performed with virtual machines, and the formulas of elasticity are not suitable for quantifying elasticity. For example, in the above expression is di cult to obtain when resource of a cloud is increasing or decreasing. In contrast, the de nition proposed in our work re ects the essence of elasticity, and the calculation formula focuses on how to measure the elasticity value e ectively.
ere are many approaches to predicting elasticity, anticipating the system load behavior, and deciding when and how to scale in/out resources by using heuristics and mathematical/analytical techniques. In [ ], the authors established an elasticity metric aiming to capture the key elasticity characteristics. In [ ], the authors proposed execution platforms and recon guration points to re ect the proposed elasticity de nition. In [ , , -], the authors adopted predictive techniques to scale resources automatically. Although these techniques perform well in elasticity prediction, further measurement of elasticity is not covered. In [ ], the authors just outlined an elasticity benchmarking approach focusing on special requirements on workload design and implementation. In [ ], the authors used thread pools as a kind of elastic resource of the Java virtual machine and presented preliminary results of running a novel elasticity benchmark which reveals the elastic behavior of the thread pool resource. ese studies mainly present initial research. In most elasticity work, di erent elasticity benchmark programs are expected to execute on di erent systems over varying data sizes and re ect their potential elasticity, but they can only get a macroscopic view of elasticity analysis rather than the calculation of the elasticity value. In contrast, our work performs in-depth research focusing on the measurement of elasticity value.
. . Analytical Modeling. Continuous-time Markov chain (CTMC) models have been used for modeling various random phenomena occurring in queuing theory, genetics, demography, epidemiology, and competing populations [ ]. CTMC has been applied in a lot of studies to adjust resource allocation in cloud computing. Khazaei et al. proposed an analytical performance model that addresses the complexity of cloud data centers by distinct stochastic submodels using  [ , ]. However, to the best of our knowledge, CTMC has never been applied in the research of cloud elasticity. Our work in this paper adopts a CTMC model for e ective elasticity measurement.

Definition of Cloud Elasticity
In this section, we rst present a detailed discussion of di erent states which characterize the elastic behavior of a system. en, we formally de ne elasticity that is applied in cloud platforms.
. . Notations and Preliminaries. For clarity and convenience, Notations describes the correlated variables which are used in the following sections. To elaborate the essence of cloud elasticity, we give the various states that are used in our discussion. Let denote the number of VMs in service and let be the number of requests in the system. Notice that constants and in this paper are only for illustration purpose and can be any other values, depending on how an elastic cloud platform is managed. Di erent cloud users and/or applications may prefer di erent bounds of the hypothetical just-in-need states. e length of the interval between the upper (e.g., 3 ) and lower (e.g., ) bounds controls the reprovisioning frequency. Narrowing down the interval leads to higher reprovision frequency for a uctuating workload. e just-in-need computing resource denotes a balanced state, in which the workload can be properly handled and quality of service (QoS) can be satisfactorily guaranteed. Computing resource overprovisioning, though QoS can be achieved, leads to extra but unnecessary cost to rent the cloud resources. Computing resource underprovisioning, on the other hand, delays the processing of workload and may be at the risk of breaking QoS commitment.
. . Elasticity De nition in Cloud Computing. In this section, we present our elasticity de nition for a realistic cloud platform and present mathematical foundation for elasticity evaluation. e de nition of elasticity is given from a computational point of view and we develop a calculation formula for measuring elasticity value in virtualized clouds. Let m be the measuring time, which includes all the periods in the justin-need, overprovisioning, and underprovisioning states; that is, m = j + o + u .

De nition .
e elasticity of a cloud perform is the percentage of time when the platform is in just-in-need states; Broadly de ning, elasticity is the capability of delivering precon gured and just-in-need virtual machines adaptively in a cloud platform upon the uctuation of the computing resources required. Practically it is determined by the time needed from an underprovisioning or overprovisioning state to a balanced resource provisioning state. De nition provides a mathematical de nition which is easily and accurately measurable. Cloud platforms with high elasticity exhibit high adaptivity, implying that they switch from an overprovisioning or an underprovisioning state to a balanced state almost in real time. Other cloud platforms take longer time to adjust and recon gure computing resources. Although it is recognized that high elasticity can also be achieved via physical host standby, we argue that, with virtualizationenabled computing resource provisioning, elasticity can be delivered in a much easier way due to the exibility of service migration and image template generation.
Elasticity re ects the degree to which a cloud platform changes upon the uctuation of workloads and can be measured by the time of resource scaling by the quantity and types of virtual machine instances. We use the following equation to calculate its value: where m denotes the total measuring time, in which o is the overprovisioning time which accumulates each single period of time that the cloud platform needs to switch from an overprovisioning state to a balanced state and u is the underprovisioning time which accumulates each single period of time that the cloud platform needs to switch from an underprovisioning state to a corresponding balanced state. Let j , o , and u be the accumulated probabilities of just-in-need states, overprovisioning states, and underprovisioning states, respectively. If m is su ciently long, we have ) can be used when elasticity is measured by monitoring a real system. Equation ( ) can be used when elasticity is calculated by using our CTMC model. If elasticity metrics are well de ned, elasticity of cloud platforms could easily be captured, evaluated, and compared.
We would like to mention that the primary factors of elasticity, that is, the amount, frequency, and time of resource reprovisioning, are all summarized in o and u (i.e., o and surge of workload, if there is any, to minimize the time needed to start these nodes. Such a hot standby strategy increases cloud elasticity by reducing u . . . An Example. In Figure , 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. e measuring time of cloud platform is m = 24 hours and cloud platform 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., underprovisioning time of cloud platform ), and o = 21 = 10 hours (i.e., overprovisioning time of cloud platform ). According to ( ), 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 greater elasticity value would exhibit better elasticity.
. . Relevant Properties of Clouds. In this section, we compare cloud elasticity with a few other relevant concepts, such as cloud resiliency, scalability, and e ciency.
Resiliency. Laprie [ ] de ned resiliency as the persistence of service delivery that can be trusted justi ably, when facing changes. erefore, cloud resiliency implies (1) the extent to which a cloud system withstands the external workload variation and under which no computing resource reprovisioning is needed and (2) the ability to reprovision a cloud system in a timely manner. We think the latter implication de nes the cloud elasticity while the former implication only exists in cloud resiliency. In our elasticity study, we will focus on the latter one.
Scalability. Elasticity is o en confused with scalability in more ways than one. Scalability re ects the performance speedup when cloud resources are reprovisioned. In other words, scalability characterizes how well in terms of performance a new compute cluster, either larger or smaller, handles a given workload. On the other hand, elasticity explains how fast in terms of the reprovisioning time the compute cluster can be ready to process the workload. Cloud scalability is impacted by quite a few factors such as the compute node type and count and workload type and count. For example, Hadoop MapReduce applications typically scale much better than other single-thread applications. It can be de ned in terms of scaling number of threads, processes, nodes, and even data centers. Cloud elasticity, on the other hand, is only constrained by the capability that a cloud service provider o ers. Other factors that are relevant to cloud elasticity include the type and count of standby machines, computing resources that need to be reprovisioned. Di erent from cloud scalability, cloud elasticity does not concern workload/application type and count at all. E ciency. E ciency characterizes how cloud resource can be e ciently utilized as it scales up or down. is concept is derived from speedup, a term that de nes a relative performance a er computing resource has been recon gured. Elasticity is closely related to e ciency of the clouds. Eciency is de ned as the percentage of maximum performance (speedup or utilization) achievable. High cloud elasticity results in higher e ciency. However, this implication is not always true, as e ciency can be in uenced by other factors independent of the system elasticity mechanisms (e.g., di erent implementations of the same operation). Scalability is a ected by cloud e ciency. us, e ciency may enhance elasticity, but not su ciency.
is is due to the fact that elasticity depends on the resource types, but e ciency is not limited by resource types. For instance, with a multitenant architecture, users may exceed their resources quota. ey may compete for resources or interfere each other's job executions.

F
: Modeling an elastic cloud computing platform as an extended / / queuing system.

Elasticity Analysis Using CTMC
In this paper, we implement the cloud elasticity computing model using CTMC.

. . A Queuing Model.
is section mainly explains why the continuous-time Markov chain (CTMC) can be applied to compute cloud elasticity and the connection between them.
A continuous-time Markov chain is a continuous time, discrete-state Markov process. Many CTMC have transitions that only go to neighboring states, that is, either up one or down one; they are called birth-and-death processes. Motivated by population models, a transition up one is called a birth, while a transition down one is called a death. e birth rate in state is denoted by , while the death rate in state is denoted by . e state-transition-rate diagram for a birth-and-death process (with state space {0, 1, . . . , }) takes the simple linear form shown in Figure . In many applications, it is natural to use birth-and-death processes. One of the queuing models is / / queue, which has servers and unlimited waiting room. e main properties of a queuing system are as follows.
( ) Requests arrive in a Poisson process with parameter . ( ) e service times are exponential random variables with parameter . So a queuing system is a birth-and-death process with Markov property. A cloud computing service provider serves customers' service requests by using a multiserver system. An elastic cloud computing platform treated as a multiserver system and modeled as an extended / / queuing system is shown in Figure . Assume that service requests arrive by following a Poisson process and task service times are independent and identically distributed random variables that follow an exponential distribution. When a running request nishes, the capacity used by the corresponding VM is released and becomes available for serving the next request. e request at the head of the queue is processed (i.e., rstcome-rst-served) on a running VM if there is capacity to run a scheduled request. Elastic resource provisioning cannot be done with physical machines, and only virtual machines can be recon gured in real time. A cloud platform is able to adapt to variation in workload by starting up or shutting o VMs in an autonomic manner, avoiding overprovisioning or underprovisioning. If no enough running VMs are available (e.g., underprovisioning state), a new VM is started up and used for service. If there are excessive VMs (e.g., overprovisioning state), redundant VMs are shut o .
According to ( ) and ( ), the calculation of the elasticity value needs to count the accumulated time in all the overprovisioning and underprovisioning states. In real cloud platforms, it is possible to record the overprovisioning time and underprovisioning times. Furthermore and fortunately, the accumulated probability of both overprovisioning and underprovisioning states can be computed using our proposed CTMC model as discussed in the next section.
. . Elastic Cloud Platform Modeling. To model elastic cloud platforms, we make the following assumptions.
(i) All VMs are homogeneous with the same service capability and are added/removed one at a time. (ii) e user request arrivals are modeled as a Poisson process with rate .
(iii) e service time, the start-up time, and the shuto time of each VM are governed by exponential distributions with rates , , and , respectively [ ].
(iv) Let denote the number of virtual machines that are currently in service, and let denote the number of requests that are receiving service or in waiting.
(v) Let statev( , ) denote the various states of a cloud platform when the virtual machine number is and the request number is . Let the hypothetical just-inneed state, overprovisioning state, and underprovisioning state be JIN, OP, and UP, respectively. We can set the equations of the relation between the virtual machine number and the request number as follows: ( ) e hypothetical just-in-need state, overprovisioning state, and underprovisioning state are listed in Table . Based on these assumptions, we build a two-dimensional continuous-time Markov chain (CTMC) for our extended / / queuing system shown in Figure   ( ∈ {0, 1, . . . , }) denotes the number of requests that are receiving service. For the purpose of numerical calculation, we set the maximum number of VMs that can be deployed as , which is su ciently large to guarantee enough accuracy. Similarly, the maximum is . Let be the service rate of each VM. So the total service rate for each state is the product of number of running VMs and . e state transition in an elastic cloud computing model can occur due to user request arrival, service completion, virtual machine start-up, or virtual machine shut-o . In state ( , ), according to Table , the state can be determined as "just-in-need," "underprovisioning," or "overprovisioning." Depending on the upcoming event, four possible transitions can occur.
Case . When a new request arrives, the system transits to state ( , + 1) with rate .
Case . When a requested service is completed, if the system examines the state as not "overprovisioning," the system Scienti c Programming moves back to state ( , − 1) with total service rate . If the system examines the state as "overprovisioning" and = , the system moves back to state ( , − 1) with total service rate ( − 1) , because a server is shutting o and cannot perform any 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 .
e system examines the state as "underprovisioning" and transits to state ( + 1, ) with rate .

Case .
e system examines the state as "overprovisioning" and transits to state ( − 1, ) with rate .

( )
In the above equations, , , , and are the request arrival rate (i.e., the interarrival times of service requests are independent and identically distributed exponential random variables with mean 1/ ), the service rate (i.e., the average number of tasks that can be nished by a VM in one unit of time), the virtual machine start-up rate (i.e., a VM needs time = 1/ to turn on), and the virtual machine shuto rate (i.e., a VM needs time = 1/ to shut down), respectively. e balance equations link the probabilities of entering and leaving a state in equilibrium. e total number of equations is × ( + 1) + 1, but there are only × ( + 1) variables: 1,0 , 1,1 , . . . , , . erefore, in order to derive , , we need to remove one of the equations to obtain the unique equilibrium solution. Unfortunately, the steady-state balance equations cannot be solved in a closed form; hence, we must resort to a numerical solution. e input and output parameters of our CTMC model are summarized in the following.
Input. e request arrival rate is , the service rate is , the virtual machine start-up rate is , and the virtual machine shut-o rate is . (In addition, the de nitions of "just-inneed," "underprovisioning," and "overprovisioning" states should also be included.)

Scienti c Programming
Output (i) e accumulated underprovisioning state probability u of a cloud platform is as follows: where , is the steady-state probability.
(ii) e accumulated overprovisioning state probability o of a cloud platform is as follows: where , is the steady-state probability.
(iii) e elasticity value of a cloud platform is obtained by ( ), ( ), and ( ).

Model Analysis
In this section, we present some numerical results obtained based on the proposed elastic cloud platform modeling, illustrating and quantifying the elasticity value under di erent load conditions and di erent system parameters. All the numerical data in this section are obtained by setting = , , that is, the maximum number of VMs that can be deployed, to guarantee su cient numerical accuracy.
. . Varying the Arrival Rate. For the rst scenario, we have considered a system with di erent service rates ( = 100, , , , and jobs/hour), while the arrival rate is a variable from = 100 to 400 jobs/hour in sixteen steps. In all cases, the virtual machine start-up rate and virtual machine shut-o rate are assigned values of = 120 VMs/hour and = 540 VMs/hour. Figure illustrates that the elasticity value is an increasing function of the arrival rate. As can been seen, it increases rather quickly when the arrival rate is up to and smoothly when the arrival rate is higher. is behavior is due to the fact that increasing results in noticeable reduction of the probability of overprovisioning but slight change of the probability of underprovisioning. Furthermore, it is observed that the elasticity value decreases as the service rate increases, as described in the next section.
. . Varying the Service Rate. For the second scenario, we have considered a system with di erent arrival rates ( = 200, , , , and jobs/hour), while the service rate is a variable from = 10 to 290 jobs/hour in een steps. In all cases, the virtual machine start-up rate and virtual machine shut-o rate are assigned values of = 120 VMs/hour and = 540 VMs/hour.
Figure illustrates that the elasticity value is a decreasing function of the service rate. It shows that, for a xed arrival rate, increasing service rate decreases the elasticity value sharply and almost linearly. is phenomenon is due to the fact that increasing results in noticeable increment of the probability of overprovisioning, and change of the probability of underprovisioning does not a ect the decreasing trend of the just-in-need probability. Figure also con rms that the elasticity value is an increasing function of the arrival rate.
. . Varying the Virtual Machine Start-Up Rate. For the third scenario, Figure shows numerical results for a xed arrival rate, service rate, and virtual machine shut-o rate but di erent virtual machine start-up rates.
First, we characterize the elasticity value by presenting the e ect of di erent arrival rates ( = , , , , and jobs/hour) and the virtual machine start-up rate is a variable from = 120 to 260 VMs/hour in een steps. In all cases, other system parameters are set as follows. e service rate is = 100 jobs/hour, and the virtual machine shut-o rate is = 540 VMs/hour. As can be seen in Figure (a), it increases slightly when the virtual machine start-up rate increases. is is due to the fact that, for high virtual machine start-up rate, each virtual machine start-up time is shorter, meaning that less time is needed to switch from an underprovisioning state to a balanced state, so the probability of underprovisioning u is smaller, while the probability of overprovisioning o does not change too much, and the probability of just-in-need j is increasing. Second, we also analyze the e ects of di erent service rates ( = 100, , , , and jobs/hour), while the virtual machine start-up rate is a variable from = 120 to 260 VMs/hour in een steps. In all cases, other system parameters are set as follows. e arrival rate is = 200 jobs/hour, and the virtual machine shut-o rate is = 540 VMs/hour. It can be seen in Figure (b) that the elasticity value increases slightly with increasing virtual machine startup rate. e results allow us to conclude the increasing elasticity value at increasing virtual machine start-up rate for a xed arrive rate, service rate, and virtual machine shut-o rate. In other words, increasing the virtual machine start-up rate will decrease the probability of underprovisioning and increase the just-in-need probability. ese behaviors (see Figure ) con rm that the elasticity value of a cloud platform has a relationship to its virtual machine start-up speed.
. . Varying the Virtual Machine Shut-O Rate. For the fourth scenario, Figure shows numerical results for a xed arrival rate, service rate, and virtual machine start-up rate but di erent virtual machine shut-o rates.
We examine the e ect of virtual machine shut-o rate on elasticity. For di erent arrival rates ( = 200, , , , and jobs/hour), the virtual machine shut-o rate is a variable from = 540 to 680 VMs/hour in een steps. In all cases, other system parameters are set as follows. e service rate is = 100 jobs/hour, and the virtual machine start-up rate is = 120 VMs/hour. It can be seen from Figure (a) that the elasticity value increases slightly where the virtual machine shut-o rate is increased from to VMs/hour. is happens because the virtual machine shut-o time is shorter, and a platform becomes more responsive, resulting in diminishing overprovisioning time which is the accumulate time for the system to switch from an overprovisioning state to a balanced state. Furthermore, the probability of overprovisioning o is smaller, the probability of underprovisioning u shows slight change, and the probability of just-in-need j is increasing.
We also calculate the elasticity value under the di erent service rates ( = 100, , , , and jobs/hour), while the virtual machine shut-o rate is a variable from = 540 to 680 VMs/hour in een steps. e arrival rate is = 200 jobs/hour, and the virtual machine start-up rate is = 120 VMs/hour. In Figure (b), the elasticity value increases slightly by increasing the virtual machine shut-o rate. is is also because of the corresponding reduction in virtual machine shut-o time, guaranteeing shorter overprovisioning probability o .
Based on these results, we can conclude the increasing elasticity value at increasing virtual machine shut-o rate for a xed arrive rate, service rate, and virtual machine startup rate. In other words, increasing the virtual machine shuto rate will decrease the probability of overprovisioning and increase the just-in-need probability. ese behaviors of Figure con rm that the elasticity value of a cloud platform has a relationship to its virtual machine shut-o speed.

Simulation Results
In this section, we present our elastic cloud simulation system called Cloud Elasticity Value. Its aim is to demonstrate that our elasticity measurement is correct and e ective in computing and comparing the elasticity value and to show cloud elasticity under di erent parameter settings.
. . Design of the Simulator. Our simulation uses the same code base for the elasticity measurement as the real implementation. e simulator is implemented in about , lines of C++ code. It runs in a Linux box over a rack-mount server with Intel5Core6 Duo CPU and . GB of memory. e simulator consists of four modules, that is, the task generator module, the virtual machine monitor module, the request monitor module, and the queue module. e task generator module produces simulation of Poisson distribution requests. e virtual machine monitor module is used for deciding whether to start up and shut o the virtual machines and recording the start-up and shut-o times. e request monitor module is used to count how many requests are being serviced in the system and to record the service times. Arrived service requests are rst placed in a queue module and recorded their arrival times before they are processed by any virtual machine. e main process of the simulator is listed as follows.
Step . e task generator module produces simulation of Poisson distribution requests. When the service requests arrive, they are placed in a queue module and recorded their arrival times.
e virtual machine monitor module determines whether to start up or shut o the VMs and records the startup and shut-o times.
e request monitor module determines whether there is a request in the queue. If there is a request, it takes a request and assigns it to a running virtual machine and records the service time.
Step . A er the simulation time is over, the simulator counts up the accumulated time in overprovisioning and underprovisioning states and returns the elasticity value using ( ).
. . Simulation Results and Analysis. We have evaluated cloud elasticity values using two methods, that is, (1) the elasticity values in terms of the steady-state probabilities obtained for the given parameter and (2) the elasticity values in terms of our simulation system obtained for the same parameters. We compare our CTMC model solutions with the results produced by the simulation method.
We have considered the arrival rate characterized by = 60, , and jobs/hour. e service rate values chosen are = 60, , and jobs/hour. In all cases, the virtual machine start-up rate is assigned the value of = 300 VMs/hour, while the virtual machine shut-o rate is = 540 VMs/hour. . . % so ware which virtualizes the infrastructure and provides uni ed computing and storage resources. To create a cloud environment, we install CloudStack open-source cloud environment, which is composed of a cluster and responsible for global management, resource scheduling, task distribution, and interaction with users. e cluster is managed by a cloud manager ( AMD Opteron Processor CPU, GB memory, and TB hard disk). We use our elasticity testing platform to achieve the allocation of resources, that is, virtual machine start-up and shut-o on LuCloud.
. . Experiment Process and Results. First, in order to validate the proposed model, Table summarizes the comparison between the two approaches, that is, the CTMC model and the experiments on LuCloud. We have considered the arrival rate characterized by = 60, , and jobs/hour. e service rate values chosen are = 60, , and jobs/hour. e virtual machine start-up rate is assigned the value of = 120 VMs/hour, and the virtual machine shut-o rate is assigned the value of = 540 VMs/hour.
In Table , we can observe that the elasticity values of both approaches are very close, with the maximum relative di erence only . percent. We conclude that the proposed CTMC model can be used to compute the elasticity of cloud platforms and can o er accurate results within reasonable di erence.
Our second set of experiments focus on the robustness of our model and method, that is, its applicability when the assumptions of our model are not satis ed. We have considered Gamma distributions for the service times. e Gamma( , ) distribution is de ned in terms of a shape parameter and a scale parameter [ ]. We use the same parameter settings in Table , except that the exponential distributions of service times are replaced by Gamma distributions, that is, Gamma(0.0083, 2), Gamma(0.0025, 2), and Gamma(0.00083, 2), such that the service rates are still = 60, , and jobs/hour. From Table , we can see that the elasticity values of the CTMC model and the experiments are very close, with the maximum relative di erence only . percent. We observe that the experimental results with Gamma service times match very closely with those of the proposed CTMC model. So we conclude that the proposed model and method for quantifying and measuring elasticity using continuous-time Markov chain (CTMC) are not only correct and e ective, but also robust and applicable to real cloud computing platforms.

Conclusion
In this paper, we have introduced a new de nition of cloud elasticity. We have presented an analytical method suitable for evaluating the elasticity of cloud platforms, by using a continuous-time Markov chain (CTMC) model. Validation of the analytical results through extensive simulations has shown that our analytical model is su ciently detailed to capture all realistic aspects of resource allocation process, e average number of VMs in service CPR: e cost-performance ratio.