ADVISE: evAluating clouD serVIce elaSticity bEhavior

This page provides supplementary material for the paper:

• Georgiana Copil, Demetris Trihinas, Hong-Linh Truong, Daniel Moldovan, George Pallis, Schahram Dustdar, Marios Dikaiakos. "ADVISE - a Framework for Evaluating Cloud Service Elasticity Behavior" (submitted PDF) the 11th International Conference on Service Oriented Computing. Berlin, Germany, 2-5 December, 2013. Accepted

Complex cloud services rely on different elasticity control processes for dealing with resource, cost and quality elasticity. Due to the complexity of service structures, deployment strategies, and underlying infrastructure dynamics, such processes which consist of several actions are typically designed and applied to similar types of services. However, the enforcement of an elasticity control process on a cloud service may not produce an optimal gain in terms of quality or cost. Therefore, being able to estimate and evaluate the relation between cloud service behavior and elasticity control processes is crucial for deciding which elasticity control processes are the most appropriate. We present an approach for determining cloud service behavior based on various types of information, like control processes which are enforced and ongoing workload. An experimental evaluation with two cloud services illustrates the usefulness of our framework.

Experiments

Note: For seeing the different effects (estimated and observed) over the different parts of the application, just click on the first image from the list.

M2M DaaS

The Machine-to-Machine (M2M) DaaS shown in figure below processes information originating from several different types of data sensors (i.e., temperature, atmospheric pressure, or pollution). Specifically, the M2M DaaS is comprised of two service topologies, an Event Processing Service Topology and a Data End Service Topology. Each service topology consists of two service units, one with a processing goal, and the other acting as the service topology balancer/controller. To stress this cloud service we generate random sensor event information which is processed by the Event Processing Service Topology, and stored/retrieved from the Data End Service Topology.

• Scale In Data Node Service Unit: Effect on Cloud Service
  
• Scale In Data Node: Effect on Data End Topology
  
• Scale In Data Node: Effect on Data Node
  
• Scale In Event Processing: Effect on Event Processing Topology
  
• Scale Out Data Node: Effect on Data Controller
  
• Scale Out Data Node: Effect on Data Node
  
• Scale Out Event Processing: Effect on Event Processing Service Unit
  
• Scale Out Event Processing: Effect on Event Processing Service Topology
  

Video Service

The second cloud service is a three-tier web application which provides video streaming services to online users. Specifically, the cloud service is comprised of: (i) an HAProxy Load Balancer which distributes client requests (i.e., download, upload video) across multiple application servers; (ii) An Application Server Tier, where each application server is an Apache Tomcat server containing the video streaming web service;(iii) A Cassandra from where the necessary video content is retrieved.

• Scale In Cassandra Node: Effect on Cloud Service
  
• Scale Out Cassandra Node: Effect on Cloud Service
  
• Scale In Cassandra Node: Effect on Cassandra Cluster
  
• Scale Out Cassandra Node: Effect on Cassandra Cluster
  
• Scale In Application Server: Effect on Application Server
  
• Scale Out Application Server: Effect on Application Server
  

Prototype

Our prototype is available in the GitHub Repository

ADVISE can be used on MELA-provided data (in current example we have a running version of MELA on our local OpenStack cloud), or with recorded data (the user has to provide the files requested by the prototype - historical data, recent data which we want to test).

ADVISE monitors the evolution of the application over time, the learning process taking as input the current metrics behavior for the part of the cloud application we are focusing on (e.g.,at business layer, it would be the sequence of throughput and response time values for the last x minutes), and the intended Elasticity Control Process (e.g., add one more web service, or reconfigure application server to enable more threads followed by the addition of one more web service of type x), and produces expected metrics, in time, for current service part (in this case the business layer).


Please check the wiki for more details.

Contact

If you need any further information please contact Georgiana Copil.