Elasticity (cloud computing)

In cloud computing, elasticity is defined 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.[1] It is a defining characteristic, that differentiates it from previously proposed computing paradigms, such as grid computing. This dynamic variation in the use of computer resources to meet a varying workload is called "elastic computing".[2][3] In general an elastic cloud application or process has three elasticity dimensions,[4] Cost, Quality, and Resources, enabling it to increase and decrease its cost, quality, or available resources, as to accommodate specific requirements.

Example

Let us illustrate elasticity through a simple example of a service provider who wants to run a website on an IaaS cloud. At moment t_0, the website is unpopular and a single machine (most commonly a virtual machine) is sufficient to serve all web users. At moment t_1, the website suddenly becomes popular, for example, as a result of a flash crowd, and a single machine is no longer sufficient to serve all users. Based on the amount of web users simultaneously accessing the website and the resource requirements of the web server, it might be that ten machines are needed. An elastic system should immediately detect this condition and provision nine additional machines from the cloud, so as to serve all web users responsively.

At time t_2, the website becomes unpopular again. The ten machines that are currently allocated to the website are mostly idle and a single machine would be sufficient to serve the few users who are accessing the website. An elastic system should immediately detect this condition and deprovision nine machines and release them to the cloud.

Purpose

Elasticity aims at matching the amount of resources allocated to a service with the amount of resources it actually requires, avoiding over- or under-provisioning. Over-provisioning, i.e., allocating more resources than required, should be avoided as the service provider often has to pay for the resources that are allocated to the service. For example, at the time of this writing, Amazon EC2 charges $0.480/hour for an "extra large" virtual machine. If a service is allocated two virtual machines, instead of one required, the service provider wastes $4,205 every year. Hence, the service provider's expenses are higher than optimal and the profit is reduced.

Under-provisioning, i.e., allocating fewer resources than required, must be avoided, otherwise the service cannot serve its users with a good service. In the above example, under-provisioning the website may make it seem slow or unreachable. Web users eventually give up on accessing it, thus, the service provider loses customers. On the long term, the provider's income will decrease, which also reduces the profit.

Problems

Resources provisioning time

One potential problem is that elasticity takes time. A cloud virtual machine (VM) can be acquired at any time by the user, however, it may take up to several minutes for the acquired VM to be ready to use. The VM startup time is dependent on factors, such as image size, VM type, data center location, number of VMs, etc.[5] Cloud providers have different VM startup performance. This implies any control mechanism designed for elastic applications must consider in its decision process the time needed for the elasticity actions to take effect,[6] such as provisioning another VM for a specific application component.

Monitoring elastic applications

Elastic applications can allocate and deallocate resources (such as VMs) on demand for specific application components. This makes cloud resources volatile, and traditional monitoring tools which associate monitoring data with a particular resource (i.e. VM), such as Ganglia or Nagios, are no longer suitable for monitoring the behavior of elastic applications. For example, during its lifetime, a data storage tier of an elastic application might add and remove data storage VMs due to cost and performance requirements, varying the number of used VMs. Thus, additional information is needed in monitoring elastic applications, such as associating the logical application structure over the underlying virtual infrastructure.[7] This in turn generates other problems, such as how to aggregate data from multiple VMs towards extracting the behavior of the application component running on top of those VMs, as different metrics might need to be aggregated differently (e.g., cpu usage could be averaged, network transfer might be summed up).

Elasticity requirements

When deploying applications in cloud infrastructures (IaaS/PaaS), requirements of the stakeholder need to be considered in order to ensure proper elasticity behavior. Even though traditionally one would try to find the optimal trade-off between cost and quality or performance, for real world cloud users requirements regarding the behavior are more complex and target multiple dimensions of elasticity (e.g., SYBL[8]).

Multiple levels of control

Cloud applications can be of varying types and complexities, with multiple levels of artifacts deployed in layers. Controlling such structures must take into consideration a variety of issues, an approach in this sense being rSYBL.[9] For multi-level control, control systems need to consider the impact lower level control has upon higher level ones and vice versa (e.g., controlling virtual machines, web containers, or web services in the same time), as well as conflicts which may appear between various control strategies from various levels.[10]

See also

References

  1. ↑ Herbst, Nikolas Roman; Samuel Kounev; Ralf Reussner (2012). "Elasticity in Cloud Computing: What It Is, and What It Is Not". Proceedings of the 10th International Conference on Autonomic Computing (ICAC 2013), San Jose, CA, June 24–28.
  2. ↑ Cloud Computing Principles and Paradigms, John Wiley and Sons, 2011, ISBN 978-0-470-88799-8
  3. ↑ Perez et al, Responsive Elastic Computing, ISBN 978-1-60558-578-9
  4. ↑ Schahram, Dustdar; Yike Guo, Benjamin Satzger, Hong-Linh Truong (2011). "Principles of Elastic Processes". IEEE Internet Computing, vol. 15, no. 5, pp. 66-71, September/October,. doi:10.1109/MIC.2011.121.
  5. ↑ Mao, Ming; M. Humphrey (2012). "A Performance Study on the VM Startup Time in the Cloud". Proceedings of 2012 IEEE 5th International Conference on Cloud Computing (Cloud2012): 423. doi:10.1109/CLOUD.2012.103. ISBN 978-1-4673-2892-0.
  6. ↑ Gambi, Alessio; Daniel Moldovan, Georgiana Copil,Hong-Linh Truong, Schahram Dustdar (2013). "On estimating actuation delays in elastic computing systems". Proceedings of ICSE Workshop on Software Engineering for Adaptive and Self-Managing Systems (SEAMS). doi:10.1109/SEAMS.2013.6595490.
  7. ↑ Moldovan, Daniel; Georgiana Copil,Hong-Linh Truong, Schahram Dustdar (2013). "MELA: Monitoring and Analyzing Elasticity of Cloud Services". Proceedings of IEEE 5th International Conference on Cloud Computing Technology and Science (CloudCom 2013). doi:10.1109/CloudCom.2013.18.
  8. ↑ Georgiana Copil, Daniel Moldovan, Hong-Linh Truong, Schahram Dustdar, "SYBL: an Extensible Language for Controlling Elasticity in Cloud Applications", Proceedings of the 13th IEEE/ACM International Symposium on Cluster, Cloud and Grid Computing (CCGrid), May 14–16, 2013, Delft, the Netherlands
  9. ↑ Georgiana Copil, Daniel Moldovan, Hong-Linh Truong, Schahram Dustdar, "Specifying, Monitoring, and Controlling Elasticity of Cloud Services", Proceedings of the 11th International Conference on Service Oriented Computing. Berlin, Germany, 2–5 December 2013. doi=10.1007/978-3-642-45005-1_31
  10. ↑ Kranas, Pavlos (2012). "ElaaS: An Innovative Elasticity as a Service Framework for Dynamic Management across the Cloud Stack Layers". Proceedings of Sixth International Conference on Complex, Intelligent and Software Intensive Systems (CISIS) 4–6 July 2012 (IEEE). doi:10.1109/CISIS.2012.117.

External links