Managing and Monitoring Elastic Cloud Applications
In the current webpage you will find screenshots that showcase the proposed demonstration for the demo paper entitled: "Managing and Monitoring Elastic Cloud Applications" which was submitted to ICWE 2014.
This demonstration showcases the functionality of an Elasticity Management Platform (Fig. 1) which is used to manage the full lifecycle of an elastic Cloud application. The demonstration focuses on presenting two powerful and open-source tools: c-Eclipse: a framework for describing Cloud applications along with their elasticity requirements and deploying them on any IaaS provider; and JCatascopia: a fully-automated, multi-layer, interoperable Cloud monitoring system.
Specifically, in this demonstration, we will:
- Describe, via c-Eclipse's Application Description Tool, a Cloud application's topology, software dependencies and relationships between its tiers;
- Select a Cloud platform (i.e. Amazon EC2 or an Openstack private Cloud) and submit the generated TOSCA description to the Cloud Manager, via c-Eclipse's Submission Tool;
- Define, via c-Eclipse, elasticity requirements for the elastic components comprising the application;
- Monitor both the Cloud resources allocated for the application and its performance by utilizing JCatascopia;
- Scale the application, via the Cloud Manager, based on collected metrics and the user-defined elasticity requirements.
Use case scenario: we will consider a three-tier online video streaming service 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. Aggregated tier metrics such as the average number of connections, memory utilization and/or request throughput can be used to decide when a scaling action should occur; (iii) a Cassandra NoSQL distributed data storage backend. Similarly, aggregated metrics such as the average CPU utilization, network utilization and/or query latency will be used to add/remove nodes to/from the Cassandra ring.
Furthermore, we will allow attendees to configure the deployment by refining the elasticity requirements. Finally, via the JCatascopia Web interface, the developers can observe real-time graphs for each collected metric, configure monitoring parameters (i.e. sampling rate) and generate graphs by aggregating metrics originated from multiple instances.
At first, we describe the video streaming service topology, relationships between its tiers and its elasticity requirements via c-Eclipse's Application Description Tool. The description is generic and can be used to deploy the same web application to multiple providers.
After describing the video streaming service, we select a Cloud platform (i.e. Amazon EC2, Openstack private Cloud, Flexiant FCO, etc.) and then add Cloud provider specific components to the description such as VM images. In the following screenshot, we have selected to deploy the video streaming service to Amazon EC2.
We then specify elasticity requirements for both the application server tier and the database backend. In the following figure we specify that we want the database backend to scale out when the condition CPUutilization < 80% is violated.
After successfully deploying the video service we can overview the whole deployment on c-Eclipse and JCatascopia's web interface which is integrated in c-Eclipse environment. The following figure present c-Eclipse deployment status property view which shows that we have deployed the video service on Amazon EC2 and it also shows a previous deployment which is still running on an Openstack private Cloud.
As we can observe from JCatascopia web interface, the initial deployment is comprised of 3 VMs: (i) a load balancer; (ii) an application server; and (iii) a Cassandra DB node.
To stress the video service, we have developed a client request workload generator where the workload form (i.e. sinusoidal, linear), type (i.e. read-heavy, write-heavy, combination) and parameters (i.e. intensity, max execution time) are all configurable. Attendees will be able to configure the workload, in order to observe how the workload imposed, affects the overall system. The following figure depicts a sinusoidal client request rate as shown in JCatascopia.
The following figure shows the current number of busy threads (active client connections) of an application server which runs the video streaming web application when a sinusoidal workload is utilized. The current number of busy threads, as well as, memory utilization are key indicatiors of when a resizing action should be enforced. When the number of busy threads is too high (low) then a new application server is automatically added (or removed).
Imposing a significant workload to the video service will result in instantiating a number of Cassandra Database nodes to facilitate the high number of client requests to download/upload videos. In the following figure, we observe that 6 Cassandra nodes are up and running and we can see the average CPU utilization imposed to the Cassandra ring. The average CPU utilization is exposed by creating in JCatascopia, at runtime, a new metric which aggregates CPU utilization throughout the Cassandra ring.
Finally, in the following figure we can see the deployment after an hour which we can see that currently 9 nodes (1 load balancer, 2 application servers and 6 cassandra nodes) are up and running.
Describing an online video streaming service with c-Eclipse
A video which showcases the CELAR project; an automatic, multi-grained, elasticity provisioning system for Cloud applications. The video presents the motivation and architecture of CELAR where c-Eclipse and JCatascopia are components integrated in the overall system.
A video showcasing c-Eclipse in its early developing stage
A video showcasing how c-Eclipse and JCatascopia are used to elastically provision the resources allocated to a Cassandra Database cluster when imposing a sinusoidal workload. The elasticity provisioner is configured, through specifying in c-Eclipse an elasticity requirement, to scale out the database cluster when latency is greater than 12ms.
A video showcasing how c-Eclipse and JCatascopia are used to elastically provision the resources allocated to a Cassandra Database cluster when imposing a sinusoidal workload. In this case, the elasticity provisioner is configured to scale the database backend in order to minimize latency while keeping cost below a threshold ($1.80).