Automatic, multi- grained elasticity- provisioning for the Cloud

(1)

Automatic, multi-‐grained elasticity-‐provisioning for the Cloud

Integration Prototype "CELAR System Prototype" V1

Companion Document

Date: 30-‐09-‐2013

(2)

List of Figures

Figure 1: CELAR System Architecture V1 ... 6

Figure 2: rSYBL prototype structure ... 8

Figure 3: MELA prototype structure ... 9

Figure 4 CELAR Platform Deployment ... 12

List of Tables

Table 1 CELAR Orchestrator API ... 13

(3)

Deliverable Title Integration Prototype "CELAR System Prototype" V1

Filename CELAR_D6.1_draft_v.X.doc

Author(s)

of companion document Konstantin Skaburskas, Dimitrios Tsoumakos, Nikos Papailiou, Ioannis Giannakopoulos, Christos Mantas, Craig Sheridan, Le Duc Hung, Stalo Sofokleous, Antonis Lioumis, Ioannis Mitsos

Date 30-‐09-‐2013

Start of the project: 01.10.2012

Duration: 36

Project coordinator organisation: ATHENA RESEARCH AND INNOVATION CENTER IN INFORMATION COMMUNICATION & KNOWLEDGE TECHNOLOGIES (ATHENA)

Deliverable title: Integration Prototype "CELAR System Prototype" V1

Deliverable no.: D6.1

Due date of deliverable: 30 September 2013 Actual submission date: 30 September 2013

Dissemination Level

X PU Public

PP Restricted to other programme participants (including the Commission Services) RE Restricted to a group specified by the consortium (including the Commission Services)

CO Confidential, only for members of the consortium (including the Commission Services)

Deliverable status version control

Version Date Author

0.1 08-‐09-‐2013 Konstantin Skaburskas

0.2

0.3 17-‐09-‐2013 20-‐09-‐2013 Konstantin Skaburskas Dimitrios Tsoumakos 0.4 0.5 0.6 0.7 1.0 23-‐09-‐2013 23-‐09-‐2013 24-‐09-‐2013 29-‐09-‐2013 30-‐09-‐2013 Craig Sheridan Stalo Sofokleous Le Duc Hung Vangelis Floros Konstantin Skaburskas

(4)

Abstract

Initial prototype of the CELAR System. This document represents complementary material to the released code to shortly describe the modules and their interaction.

Keywords

CELAR, integrated system V1.0, Elasticity provisioning, monitoring, application description, CELAR Server, CELAR Orchestrator, Decision-‐Making module

(5)

1 Introduction

CELAR Integration Subprojects (ISPs) foster systematic evolution of project results towards the targeted CELAR platform and applications, ensuring horizontal integration of the RTD contributions of the project. ISPs are timed so as to follow key research contribution and reporting periods. The results of each subproject are then integrated into a prototype that showcases the contributions achieved during the subproject. WP6’s main activities produce the CELAR integrated system. In particular, WP6 ensures smooth integration of the input from the technical WPs (WP2 to WP5) into an operational system.

This document describes D6.1, namely the first CELAR prototype that integrates technical contributions of the first year of the project. It describes the modules, their functionality, interactions, as well as the system setup and use.

2 Integration map

ISP-‐1 integrates and demonstrates Year 1 contributions. Main achievements during this period consist of the first versions of the Application Description and Cloud Monitoring tools, as well as Version 1.0 of the System Architecture and of the Elasticity Provisioning Platform.

In D1.1, the consortium presented the first version of the CELAR System Architecture. CELAR enhances the functionality provided by current cloud infrastructures in order to provide automated, multi-‐grained, elastic resource provisioning for cloud-‐based applications. CELAR contributes methods and modules along the three following areas:

1. Application Management: Enable intelligent, and user-‐driven description and deployment of applications provided under the c-‐Eclipse framework.

2. Cloud Information and Performance Monitoring: Scalable, lightweight and customizable monitoring system that allows the collection and storage of statistics that come from the infrastructure, platform and the application layers. 3. Elasticity Platform: It provides automated resource allocation based on the

application characteristics, the user-‐defined optimization and the incoming load. The elasticity platform is also responsible for the orchestration of cloud resources in the applications as well as methods for ensuring robustness and availability of the elastic operations w.r.t. the managed applications.

This architecture along with the modules CELAR will develop in each area is depicted in Figure 1.

(6)

Figure 1: CELAR System Architecture V1

During the first year, substantial effort has been devoted for setting a visionary – yet realistic – plan on the overall CELAR system. The overall System Architecture (D1.1), Elasticity Platform Architecture (D3.1) and the Decision Process for On-‐Demand Elasticity (D5.1) have been delivered. Relative to individual modules, the first versions of the Application Description tool (D2.1) and Cloud Monitoring tool (D4.1) have been produced. In parallel to the aforementioned efforts, the consortium has progressed with the implementation of basic system components as well as their integration. A list of the implemented subsystems/modules as well as their functionality and features follows.

The project has chosen an iterative approach to the development, integration and release process. One month long development cycles with regular checkpoints providing constant feedback to the development process were identified and followed.

2.1 Components of the System Prototype V1

The following components with the presented level of implementation constitute the first year System Prototype V1.

2.1.1 CELAR Client (c-‐Eclipse)

The c-‐Eclipse Application Management Platform functions as the interface of end-‐users with the CELAR system, and also serves as that information source through which application structure, elasticity requirements and deployment information are made available to the CELAR Orchestrator and Decision modules. c-‐Eclipse, contains the necessary graphical tools that enable Application Users to describe the application topology and model elasticity constraints and strategies, submit the application to the

Physical Layer IaaS VS SaaS/ Pass Custom Applications Services HBase Cassandra Hive Hadoop Cloud Provider Monitoring System CELAR DataBase Re so ur ce P ro vis io ne r Decision Module Application

Description ApplicationSubmission InformationSystem

Application Management Platform Application Profiler In te rc ep to r Elasticity Platform Cloud Information and Performance Monitor M ul ti-‐ le ve l M et ric s Ev al ua tio n Storage VM VM Cluster VM _VM VM _VS Clo ud O rch es tra tio n Other Custom

App 1 Custom App 2 Custom App 3

Ap plic ati on O rch es tra tio n CELAR Manager

(7)

underlying Cloud platform for deployment and execution, and finally monitor its complete life cycle. The c-‐Eclipse encompassed in the System Prototype V1 consists of the following tools:

• Application Description Tool: This tool interacts with the Application User who gives a description of the application that is to be deployed on the Cloud. The application description is translated into a formal XML specification that is passed through the Application Submission Tool to the CELAR Server.

• Application Submission Tool: This tool passes to the CELAR Server the application description, given by the Application User, enriched with some deployment information. The CELAR Server will then propagate the application description to the interested CELAR System modules.

• Monitoring Visualization Tool: This tool receives monitoring data from the CELAR DataBase about resource related metrics (CPU, memory usage, etc.) and application performance metrics and presents them graphically to the Application User.

2.1.2 CELAR Server

The CELAR Server contains the CELAR Manager and Applications Provisioner.

• CELAR Manager is a web server that acts as a mediator between the different components of the CELAR Platform. This is where CELAR Client connects to request a deployment of a certain application, Monitoring module pushes aggregate metrics and Decision making module connects to discover the structure and historical data of the applications. For this purpose, the CELAR Manager runs a database to persist such information.

• Application Deployment Provisioner service is based on SlipStream [12], which is an open source multi-‐cloud coordinated provisioning and image factory engine. This service is responsible for the deployment of the applications under question on IaaS Cloud platforms. It requests instantiation of the virtual machines of the required configurations and orchestrates the deployment of the distributed multi-‐layered applications themselves. The service will be extended to support the acceptance and enforcement of the required application run-‐time elasticity actions on Cloud IaaS and application levels.

2.1.3 CELAR Orchestrator and Provisioner Orchestrator

Those two components are responsible for actual materialization of the application deployment actions and are intended to be run in a special VM deployed by Provisioner at the initial phase of the deployment process.

• CELAR Orchestrator accepts scalability requests from Decision module and translates them to the ones understandable by the Provisioner.

• Provisioner Orchestrator is the SlipStream component whose task is to deploy the requested application, track it and apply the requested cloud IaaS level scalability actions.

(8)

2.1.4 Decision Module

The current implementation of Decision Module is rSYBL (runtime-‐SYBL) [6]. The main features of rSYBL are evaluating application user’s elasticity requirements in terms of cost, quality and resources, learning action effects and generating action plans.

rSYBL is composed of four core components: the SYBL Processing Engine, the Learning Engine, the Analysis Engine and the Planning Engine, and two components for interacting with the CELAR modules: the Data Processing Unit and the Reporting and Cloud Interaction Unit. For more details about these components, please refer to [D5.1]. A short description of the modules is presented in what follows.

-‐ The SYBL Processing Engine: Processes SYBL specifications and enforces described strategies when no planning is needed (e.g., “if … then …” strategy).

-‐ The Learning Engine: Uses information from Data Processing Unit to model application behavior.

-‐ The Analysis Engine: Determines elasticity requirements violations and traces the source of violated constraints to support action plan generation.

-‐ The Planning Engine: Generates action plans for enforcing more complex strategies (e.g. maximization of a certain metric) and fixing violated constraints.

-‐ The Data Processing Unit: Processes data coming from other CELAR modules such as application structure, load hints, or monitoring information.

-‐ The Reporting and Cloud Interaction Unit: Interacts with other modules for sending action enforcement plans and application analysis information.

Figure 2 depicts the structure of rSYBL prototype which is a multi-‐modules Maven project. When building the parent project, Maven will automatically build sub-‐modules and create the web service in the folder: “rSYBL-‐analysis-‐engine/target/”.

Figure 2: rSYBL prototype structure

2.1.5 Multi-‐Level Metrics Evaluation Module

The implementation of Multi-‐Level Metrics Evaluation Module is MELA [6], a service for monitoring and analysis elasticity of cloud application. The main features of MELA are composing multiple low level monitor metrics to high level metrics and evaluating application composed cost. The current MELA prototype is structured in two major modules: MELA-‐Core and MELA-‐Celar, which are short described as following.

(9)

-‐ MELA-‐Core: contains the multi-‐level cost composition and monitoring data analysis functionality. This module is structured in to three sub-‐modules.

o MELA-‐DataService: Gets monitoring information from JCatascopia.

o MELA-‐AnalysisService: Retrieves data from MELA-‐DataService, aggregates and analyzes it, and performs multi-‐level evaluation in terms of cost, quality and resource usage. This module exposes a RESTful web service that provides the composed and analyzed metrics to other interested CELAR modules, especially Decision Module.

o MELA-‐Common: Holds common data model used in communication with the MELA-‐AnalysisService and the MELA-‐DataService.

-‐ MELA-‐Celar: contains sub-‐modules for interacting with other CELAR modules. o MELA-‐JCatascopia-‐Client: Allows MELA-‐DataService to collect monitoring

data from JCatascopia.

o MELA-‐RSYBL-‐Client: Allows rSYBL can use MELA RESTful API.

Figure 3 depicts the MELA prototype structure. Maven will automatically build the sub-‐ modules when building the parent project. The built packages are put in the folder “MELA-‐AnalysisService/target” and “MELA-‐DataService/target”.

Figure 3: MELA prototype structure

2.1.6 Monitoring server and agents

The System Prototype V1 will encompass and fully utilize the first release of the JCatascopia Monitoring system (MS). JCatascopia is a fully automated, scalable, real-‐time Cloud Monitoring System, implemented in Java, which aims at supporting automated multi-‐grained Cloud platforms which offer elastic resource provisioning for the deployed Cloud applications. JCatascopia can be utilized to collect monitoring metrics from multiple layers of the underlying infrastructure as well as performance metrics from the deployed applications, and subsequently distribute them to subscribed users and platform operators. JCatascopia provides self-‐adaptive mechanisms to minimize the intrusiveness of its presence, and enhanced filtering to reduce communication costs for metric distribution. JCatascopia’s elastic properties are further enhanced with the ability

(10)

to dynamically add/remove monitoring instances located on multiple levels of the infrastructure without any human intervention or the need to restart the monitoring system. Furthermore, JCatascopia supports, via a subscription mechanism, aggregation and grouping of low-‐level metrics to generate high-‐level metrics at runtime.

Particularly, the following features are available in the current version (v1.0) of JCatascopia MS:

• Monitoring Probes: low level metric collectors utilized to gather raw metrics and generate time-‐stamped monitoring events. Probes are utilized to collect metrics concerning resource allocation and usage from multiple levels of the Cloud infrastructure, such as at VM, Virtual Cluster and Cloud level. Probes are also used to collect application performance metrics from the application level. Probes are written in Java and can be implemented by adhering to a comprehensive API provided by JCatascopia.

• Monitoring Agents: entities responsible for collecting, processing and distributing monitoring information, originating from the Probes, to JCatascopia Monitoring Server. An Agent can be considered as the Probe Manager for a particular VM, since it is responsible for activating/deactivating Probes, configuring accordingly their parameters and upon user request pull different metrics. By allowing monitoring Probes to be dynamically deployed at runtime, the JCatascopia MS is flexible and extensible.

• Monitoring Server: entities responsible for managing MS Agents. The basic functionality of a Server consists of receiving monitoring metrics from Agents, processing and storing them to the Monitoring Database and further distributing the acquired metrics to any interested entities.

• XProbe: a system (background) process that serves as an interface between third-‐party applications and the local Monitoring Agent. It enables developers to instrument their applications to report metrics either periodically or upon availability to the locally deployed JCatascopia Monitoring Agent. In the case of System Prototype V1, YCSB clients are instrumented to report throughput and latency metrics to the MS via XProbe.

• Subscription Mechanism: built into the Server to allow Application Users and various CELAR modules (e.g. Decision Module) via a RESTful API to apply aggregation filters and grouping functions upon low-‐level monitoring metrics gathered by individual monitoring Agents to create new high-‐level metrics. • Monitoring Database: a relational database for storing the current state of the

MS. Specifically, the current state refers to metadata concerning the Agents currently distributing metrics to the Server and the latest value of these metrics. The MS Server after processing freshly received metrics from Agents deployed on application VMs, stores these metrics locally for each application to an Application Monitoring Repository, in order to be consumed mainly by the Application User(s) (using the c-‐Eclipse Monitoring Visualization Tool) and the Decision Module via pull requests.

• JCatascopia Web Service: allows external entities such as Application Users or CELAR modules (i.e. Decision Module, Multi-‐Level Metrics Evaluation Module, etc.) to communicate / interact with the MS. For instance, Application Users can access monitoring information through the c-‐Eclipse Monitoring Visualization Tool.

(11)

2.1.7 IaaS Cloud connectors for the Provisioner Orchestrator

The ultimate goal of the project is to implement the elasticity platform on top of the two chosen IaaS Cloud infrastructures: ~Okeanos and Flexiant FCO. The IaaS level provisioning is done by a special component – the Provisioner Orchestrator, instantiated through SlipStream. SlipStream requires the connectors to the respective clouds to be developed.

~Okeanos.

~okeanos service builds on top of Synnefo open source, cloud software, developed by GRNET. Synnefo [11] implements most of the OpenStack [9] API. Since initially SlipStream already had an OpenStack connector the development of the one for Synnefo was based on the latter.

Flexiant Cloud Orchestrator (FCO).

For the Y1 prototype, the ~Okeanos platform is used to deploy the demo application and showcase project results. Work has progressed in parallel to this work for integration with Flexiant’s FCO: The project platform at Flexiant has already been designed, built, configured, details passed to the consortium and individual accounts have been registered. Work has begun to expose the IaaS level metrics needed for the JCatascopia monitoring probe which includes a custom script called ‘node-‐tool’ that exposes metrics from a physical compute node. Plans are in place to integrate the Flexiant platform with SlipStream and a list of IaaS actions identified for a wrapper to be written to communicate with the Orchestration VM of SlipStream. This work will be showcased in the Y2 prototype.

2.2 Interdependencies between Platform components for System Prototype

V1

As described in D1.1, the CELAR Platform consists of the Decision Module, responsible for taking the elastic decisions, the Monitoring System which monitors the performance and the health of the application VMs and the Orchestrator module which applies the decisions taken by the Decision Module. These components communicate with each other, in order to deploy, orchestrate and elastically scale the application, described by the user using the c-‐Eclipse tool. The communication, which is crucial to the performance of the Platform in total, will be achieved through a proper and generic enough protocol of communication. This section describes how the communication between these modules occurs.

(12)

Figure 4 CELAR Platform Deployment

The Decision Module, the Monitoring System and the Application Orchestrator modules are located in a dedicated VM (referenced as the “Application Orchestrator VM”), allocated when the application is initially deployed in order to monitor the application and apply all the necessary decisions needed to elastically scale the application. The Cloud Orchestrator module is located into a “static” VM (referenced as “CELAR Server”), which is responsible for the allocation of the Application Orchestrator VM and the application VMs. These modules interact with each other through an API, which is exported as a set of REST web services. The communication between the modules is depicted in Figure 4, along with the communication between the platform and the application VMs.

Each of the aforementioned modules provides a set of web services which will ease the communication and the cooperation between them. For example, when an elastic decision must be taken, the Decision Module fetches the latest monitoring metrics gathered by the Decision Module, through an HTTP call and when the decision is taken it will be forwarded to the Application Orchestrator using a second call. The Application Orchestrator will then contact the cloud Orchestrator (located in the CELAR Server) and

In fo rm a tio n T o o l U I C E LA R D a ta B a se P ro visio n e r Se rve r A p p lica tio n V M M o n ito rin g A ge n t A p p lica tio n V M M o n ito rin g A ge n t M o n ito rin g Se rve r

D e cisio n M o d u le C E LA R O rch e stra to r P ro visio n e r O rch e stra to r C lo u d P ro vid e r C E LA R M a n a ge r

C ELA R Se rve r C ELA R A p p lica tio n O rch e stra to r (A p p lica tio n A )

A p p lica tio n A

A p p lica tio n V M M o n ito rin g

A ge n t

C ELA R C lie n t

c-‐E clip se P la tfo rm A p p lica tio n

D e scrip tio n T o o l M o n ito rin g T o o l U I A p p lica tio n Su b m issio n T o o l

(13)

the necessary resources will be allocated. This procedure will be repeated each time a new decision is taken.

The use of RESTful API calls eases the development process (as changes on the exported web services can happen in parallel for different modules) and enables the use of more than one VM for the application orchestrator if needed (if the modules interact through HTTP protocol then they can also communicate when located in different VMs). The prospect of breaking the Application Orchestrator into more than one VM will be examined if the performance of the platform deteriorates because of the shared resources. A brief overview of the CELAR Orchestrator API (which includes both the Application and Cloud Orchestrator calls) is provided in the following table (

Table 1).

(14)

3 Source Code, Integration Platform and Process

CELAR project uses git [9] as SCM and source code can be found on GitHub in the CELAR organization https://github.com/CELAR. There are ten multi-‐module projects, which

URI Service Name Parameters

Description /iaas/resources Get Provided Resources type (images, VMs,

disks etc.) Returns a list of the provided resources by the IaaS.

/iass/quotas Get quotas userid Returns a list of the remaining quotas of the specified user.

/iaas/actions Get Resizing Actions None Returns a list of the allowed resizing actions by the IaaS.

/iaas/probes Get Monitoring Probes None Returns a list of the available monitoring probes.

/metrics/insert Insert metrics to DB metric (JSON) Inserts a new metrics into the database.

/metrics/get Get metrics from DB Deploymentid, metricid, timeframe

Returns a metric from the database for a specific deployment, metric type and timeframe.

/probes/upload Upload custom probe Probe

app. components Upload monitoring probe to an a custom application VM.

/deployment/deploy Deploy an application ApplicationId, deployment configuration

Deploys an application.

/deployment/smartdeploy Deploy an application using a “smart deployment”

configuration

ApplicationId, policy Deploys a new application using the Decision Module to decide about a proper deployment configuration. /deployment/shutdown Shut down an

application deployment DeploymentId Terminates deployment, a running /deployment/resize Apply resizing action Deploymentid,

resizing action (JSON/XML)

Performs a resizing action.

/deployment/getconf Get deployment

configuration DeploymentId, timestamp Returns the configuration of a deployment. /action/getActionHistory Get action history Resizing action id,

(max results, state before action)

Returns the actions applied for a deployment in the past (for a specific time frame).

(15)

correspond to the different components and modules which in turn constitute the CELAR Platform. https://github.com/CELAR/decision-‐module Decision-‐Making Module https://github.com/CELAR/multilevel-‐metrics-‐evaluation Cloud Cost Evaluation

https://github.com/CELAR/cloud-‐ms Cloud Monitoring System

https://github.com/CELAR/app-‐orchestrator

CELAR Orchestrator, Provisioner Orchestrator https://github.com/CELAR/celar-‐server

CELAR Manager, Provisioner Server, CELAR DataBase https://github.com/CELAR/c-‐Eclipse

c-‐Eclipse related components https://github.com/CELAR/cloud-‐is

CELAR Cloud Information System https://github.com/CELAR/interceptor

Interceptor

https://github.com/CELAR/app-‐profiler Application Profiler

https://github.com/CELAR/elasticity-‐provisioning-‐platform CELAR Elasticity Provisioning Platform

For the demonstration purposes of the usage of the Maven [4] for managing and building single-‐ and multi-‐module projects the following example projects were created

https://github.com/CELAR/celar-‐hellocelar CELAR example Maven multi-‐module project https://github.com/CELAR/celar-‐helloworld

CELAR example Maven single-‐module project

For automating the build, test and release process Jenkins Continuous Integration and Nexus (Maven) servers were deployed. Both servers were deployed on ~Okeanos Cloud infrastructure and

• Jenkins CI server is available at https://snf-‐153388.vm.okeanos.grnet.gr • Nexus server is available at https://snf-‐153390.vm.okeanos.grnet.gr/nexus

Maven was used for the projects definitions of the corresponding CELAR components and facilitation of the build process. This materializes in the set of POM (Project Object Model) [10] files accompanying each software project, which define the project dependencies, build, test and distribution processes and goals.

Development, integration, tests and artifacts archiving pipeline was set up as follows: • for each GitHub project a corresponding build job was created in Jenkins CI; the

jobs were configured in a polling mode to monitor git commits in the project with the interval of 5 min;

(16)

• after developer writes, commits and pushes the changes to GitHub, Jenkins discovers the change-‐set, checks out the project and builds it using Maven; all Maven projects execute ‘test’ goal to execute unit-‐tests;

• the final build goal is ‘deploy’ which uploads the generated artifacts to the project’s Nexus repository.

Binary artifacts are available under the following URLs in the project’s Nexus server https://snf-‐153390.vm.okeanos.grnet.gr/nexus/content/repositories/snapshots/ Snapshots https://snf-‐153390.vm.okeanos.grnet.gr/nexus/content/repositories/releases/ Releases

To facilitate the development and integration process the project partners set up a weekly Integration teleconference meeting during which the most important issues and showstoppers were brought in, discussed and followed by the respective action points. This proved to be very useful and effective practice allowing every partner to be up-‐to-‐ date with the global development and integration process as well as having a possibility to directly influence it.

4 Packaging and Delivery

4.1 CELAR Client

c-‐Eclipse is implemented on top of the Eclipse platform, and follows its plug-‐in based architecture. It is platform independent, since it can be run on any platform supported by Eclipse (Windows, Linux, Sun Solaris, Mac OS X and others). It can be run on the client side by importing the implementation java packages into an Eclipse workspace and running it as an ‘Eclipse Application’.

4.2 CELAR Server

The CELAR Server (machine or VM) will contain “static” information regarding the platform and the IaaS. The term “static” here is used in order to show that the existence and the functionalities of its components will not be affected by deployed applications and it will not interact immediately with the application, as the rest of the modules will. The CELAR Server will fetch and provide IaaS specific information (e.g. user quotas, available resizing actions, resource granularity, etc.) needed by other modules and it will also operate as an endpoint the CELAR Client application. In contrast to the CELAR Application Orchestrator VM, the CELAR Server will be constantly available in order to provide information and allocate resources from the IaaS for the already deployed applications.

More specifically, the CELAR Server will be responsible for the following actions:

1. The Server will store aggregated and historic metrics of the previously deployed applications, in order to provide them to the CELAR Client when needed. For example, if a CELAR user wants to view performance metrics of terminated deployments, the data will be fetched by the CELAR Server, as the CELAR Application Orchestrator VM will be terminated with the termination of the

(17)

deployment by the user. Along with these metrics the CELAR Server will store information about the taken decisions, the allocated resources and any other available detail regarding the behavior of the application and its scaling reactions.

2. It will store profiling data (when a profiling task is executed) and serve them to the Decision Module in order to create a knowledge basis.

3. It will be the contact point between a CELAR client (c-‐Eclipse) and the platform. The CELAR Server will also accept the application description and initialize the deployment of the application.

4. Finally, the CELAR Server will be responsible for the Cloud-‐level Orchestration, as it will interact with the IaaS and it will (de)allocate new resources for the deployed applications.

4.3 Application Orchestrator VM

The Application Orchestrator VM will be initially allocated when a new application deployment request is received by the CELAR Server. This VM will host the main components of the CELAR platform: the Decision Module, the Monitoring System and the CELAR Orchestrator module. These modules will interact with each other and guarantee that the application achieves the desired performance according to the user provided policy.

The CELAR Orchestrator will receive requests from the Decision Module in order to update the application’s configuration and perform the elastic operations, decided by the Decision Module. These actions could involve the allocation (deallocation) of new resources (previously allocated resources) respectively, or updating the applications configuration (if the user has given hints on the application operation) in order to improve the application performance according to the provided policy. Apart from this, the CELAR Orchestrator will be responsible for providing all the needed information regarding the application’s current state to the Decision Module and it will manage the database used for storing all data, before they get flushed to CELAR Server.

The aforementioned database is a classic RDBMS (MySQL v5.5) because of the ability of such databases to execute fast enough complex queries (possibly involving many joins between different tables). As discussed in Section 2.2, each module will export a set of web services in order to communicate with the rest of the modules. These services run in a servlet container (Apache Tomcat v 7.0) and they are written in Java. For the communication between the Application Orchestrator and the CELAR Server (when a resizing action must be applied, for instance), Python scripts should be executed from the Web Services (in order to allocate new resources through SlipStream) and Bash scripts should run after the allocation into the newly created VMs in order to Orchestrate them and ensure that the resources are utilized by the application.

(18)

4.3.1 Decision module

Decision module is the rSYBL tool and needs to be configured before deploying. The configuration file can be found under rSYBL-‐analysis-‐engine/src/main/resources/ config.properties. rSYBL needs following configuration

-‐ The Monitoring configuration: specifies the Monitoring Service URL as MELA RESTful API, which allows rSYBL to connect to MELA.

-‐ The Enforcement configuration: specifies the necessary information for connecting to the Orchestration Service (e.g., Orchestration Service URL).

In rSYBL, the Analysis Engine exposes a RESTful service and coordinates the rest of the modules. The RESTful Web Service exposed by rSYBL tool is rSYBL-‐analysis-‐engine-‐0.1-‐ SNAPSHOT. To run rSYBL, rSYBL-‐analysis-‐engine-‐0.1-‐SNAPSHOT.war needs to be deployed on a web application container.

4.3.2 Multi-‐level Metrics Evaluation module

Multi-‐level Metrics Evaluation module is MELA tool and needs to be configured before deploying. The configuration file can be found under MELA-‐AnalysisService/src/main/ resources/config/Config.properties. The configurations are the MELA-‐DataService IP and port, and others parameters such as interval time for collecting and aggregating data. MELA and consists of two artifacts to be deployed:

-‐ The MELA-‐AnalysisService: exposes a RESTful service which provides composed and analyzed metrics for other services.

-‐ The MELA-‐DataService: a background service which retrieves monitoring data from JCataScopia.

Currently, to run MELA, MELA-‐DataService-‐0.1-‐SNAPSHOT.jar needs to be executed like normal jar. Afterwards, MELA-‐AnalysisService-‐0.1-‐SNAPSHOT.war must be deployed on a web application server. After the successful deployment, we can access to http://<HOST_NAME>/MELA-‐AnalysisService-‐0.1-‐SNAPSHOT/ to view the visual monitoring metrics corresponding with application topology.

Concerning the Monitoring System, the JCatascopia MS Server and Web Service reside on the Orchestrator VM. Particularly, the MS Server is re-‐distributed as a runnable Java archive (JAR), which itself is packaged into a TAR archive. An installation shell script (Bash) is used to untar the archive, copy it into a predefined directory on the Orchestrators VM’s file system and set the necessary permissions. Once the above process is successfully completed, the JAR is executed and registered as a Linux service (i.e. daemon) using native OS libraries (/etc/init.d). On the other hand, the JCatascopia Web Service is packaged and re-‐distributed as a WAR (Web Application Archive) file for easy and transparent deployment into the Apache Tomcat web server running on the VM.

4.4 Application VMs

Concerning the Monitoring System, only JCatascopia Agents, and consequently probes embedded to these Agents, reside on the Application VMs. Similarly to above, MS Agents are packaged as a runnable Java archive (JAR), and re-‐distributed in a TAR archive. An installation shell script (Bash) is used to untar the archive, copy it into a predefined directory on the Application VM’s file system and set the necessary permissions. Once

(19)

the above process is successfully completed, the JAR is executed and the respective Agent is registered as a Linux service (i.e. daemon) using native OS libraries (/etc/init.d).

5 System level testing

To verify that the fully integrated chain of an application description, deployment, decision-‐making and auto-‐scaling process works as expected a set of system level tests were conducted.

5.1 Choice of the test application

In order to test the first prototype of the CELAR platform we have chosen the Apache Cassandra [1] distributed NoSQL database. Cassandra is a distributed key-‐value store that bases its distribution on Amazon’s Dynamo [2] and its data model on Google’s BigTable [3].

Cassandra is a good candidate for the CELAR platform because it offers linear scalability to the number of nodes participating in the Cassandra cluster and thus can be dynamically scaled to accommodate the desired user load. Furthermore, Cassandra has no single point of failure due to its distributed peer-‐to-‐peer ring architecture. Exploiting its modular peer-‐to-‐peer architecture Cassandra provides a lot of tools that can be used to achieve horizontal scaling. Nodes can be added and removed from a live Cassandra cluster without worrying about data loss and service unavailability.

Finally, Cassandra is the central component of CELAR's Cloud Gaming use case and therefore lessons learned from the testing of the first prototype can be applied in the upcoming integration of the Cloud Gaming application.

To generate variable workloads for our Cassandra deployment we use the YCSB (Yahoo! Cloud Serving Benchmark) [4] workload generator that is widely used for benchmarking cloud-‐based NoSQL databases. The architecture of the test application can be seen in the Figure 3. We use YCSB to create and load large datasets in our test Cassandra clusters and then generate a mix of workloads that help us profile the performance of Cassandra under different usage senarios. Cassandra’s profiling with YCSB is used to derive good indicators about when a Cassandra cluster is over or under utilized.

(20)

Cassandra Node Cassandra Node Cassandra Node Cassandra Node Cassandra Node Cassandra Node YCSB Client YCSB Client Figure 3: Test application

5.2 Tests

As stated in the previous section we used Cassandra in order to test the integration of the CELAR platform components.

Cassandra deployment

At first we generated SlipStream deployment scripts that can be used to deploy a Cassandra cluster with variable number of nodes to a cloud provider. This procedure fostered the integration between the CELAR Server and the SlipStream resource provisioner modules and can help synthesize the final CELAR application description structure.

We tested the deployment of the application with variable number of both YCSB clients and Cassandra nodes, on the ~Okeanos [5] cloud infrastructure. For the Cassandra cluster we used 1-‐9 VMs each consisting of 1 virtual CPU, 1GB of main memory and 10GB of hard disk. For the YCSB clients we used 1-‐3 VMs each consisting of 1 virtual CPU, 512MB of main memory and 5GB of hard disk.

Cassandra load tests

During our tests we also experimented using various YCSB datasets. We loaded from 1 to 20 million records in order to see the impact of the dataset size on Cassandra’s performance. Concerning the YCSB workloads, we used 2 basic workload types:

• Cached reads: All YCSB clients request random keys from a small subset of the dataset. The total amount of keys that are requested can fit in Cassandra’s cache and doesn’t produce costly I/O operations.

• Non Cached reads: All YCSB clients randomly request keys from the whole dataset resulting in high I/O overhead and lower request throughput.

(21)

We also vary the amount of requests that are issued by the YCSB clients through time. We created sinusoidal and step based workloads that can be used to stress out our Cassandra cluster and trigger resizing actions.

Integration with monitoring module

In order to test Cassandra's scalability we generated resizing scripts that add and remove nodes from an existing Cassandra cluster. The procedure shows that those operations are feasible and can be performed in a live cluster without losing data or availability. We also confirmed our initial expectations for the linear relation between the number of Cassandra nodes and the observed request throughput.

c-‐Eclipse

c-‐Eclipse has been tested on different Windows and MAC OS X versions (Windows 7, Windows 8, latest MAC OS X stable version) to see whether it can be executed on these platforms without arising any errors or problems. The Application Description/Submission Tools have also been tested in terms of user friendliness and ease of use by asking Cloud users of multiple expertise levels to describe an application to be submitted to the Cloud for deployment. The XML outcome of the Application Description Tool has also been tested whether it is a valid XML file according to the TOSCA specification. The Monitoring Visualization Tool has been tested in terms of correctly receiving metrics from the Monitoring DB and displaying them graphically to the c-‐Eclipse Users.

JCatascopia

The behavior of v1.0 of the JCatascopia Monitoring System was tested on both of the consortium IaaS platforms (Okeanos Public Cloud and Flexiant FCO) and on the UCY Nephelae private Cloud infrastructure, utilizing different Linux OS distributions (Ubuntu, Debian, CentOS) and various VM flavors (e.g. different no. of VCPUs, RAM and disk size). Testing involved: (i) checking if JCatascopia Monitoring Probes where collecting monitoring metrics, originating from the system level (CPU, Memory, Network etc.) and the application level (latency, throughput from YCSB clients, etc.), correctly, (ii) checking if metrics where distributed by JCatascopia Agents to their corresponding Monitoring Server, (iii) checking if JCatascopia Monitoring Servers where receiving, processing, storing and distributing monitoring metrics to Application Users and CELAR interested modules which access the Monitoring System via the c-‐Eclipse Monitoring Visualization Tool and/or via the JCatascopia RESTful API.

5.3 Feedback

After running the above tests using the first prototype of the CELAR platform we have tested and confirmed the capability of the CELAR platform to perform automated deployment and resizing actions to a cloud application. We also confirmed our expectations about application elasticity and the need to automate the decision-‐making process.

c-‐Eclipse tools have run on the different testing platforms without any changes required in the implementation packages. The Application Description and Submission Tools were successfully used by the Cloud users and the outcome of the Application

(22)

Description Tool is a valid XML file that can be parsed and read by XML editors. Finally, the c-‐Eclipse Monitoring Visualization Tool receives accurately and in time the monitoring metrics from the Monitoring DB and displays them graphically to the Application Users.

Testing is an ongoing process for the CELAR Monitoring System. The feedback obtained after concluding various preliminary tests involved: (i) when testing the Monitoring Probes, we experienced problems collecting various resource-‐related metrics (i.e. disk usage, disk IO, etc.) from VMs which were not evident when monitoring physical machines. (ii) In large distributed infrastructures faults and unexpected errors are bound to present. When network connectivity errors appeared we experienced various problems while Monitoring Agents where attempting to push metrics to their corresponding Server. Such problems resulted in metric delivery failures and the worst scenario was that Monitoring Agents were disconnected from their Monitoring Server. After experiencing the aforementioned problems we enhanced the CELAR Monitoring System with heartbeat monitoring in order to take into consideration connectivity errors, allowing for Agents to appear as “DOWN” for a short time interval and we also enhanced Monitoring Agents with a better distribution mechanism allowing for messages to be re-‐send if not delivered.

6 Summary

For the purpose of the code development, build, test and distribution the project partners have set up and successfully used the respective processes and the purposefully built infrastructure. This allowed in a short time produce the required components and integrate them into a working prototype of the CELAR Platform V1. The next identified points of improvement will be the generation of OS level packages (rpm and deb) as well as defining and implementing deployment and delivery processes for the CELAR Platform components.

7 References

[1] http://cassandra.apache.org/

[2] DeCandia, Giuseppe, Deniz Hastorun, Madan Jampani, Gunavardhan Kakulapati, Avinash Lakshman, Alex Pilchin, Swaminathan Sivasubramanian, Peter Vosshall, and Werner Vogels. "Dynamo: amazon's highly available key-‐value store." In SOSP, vol. 7, pp. 205-‐220. 2007.

[3] Chang, Fay, Jeffrey Dean, Sanjay Ghemawat, Wilson C. Hsieh, Deborah A. Wallach, Mike Burrows, Tushar Chandra, Andrew Fikes, and Robert E. Gruber. "Bigtable: A distributed storage system for structured data." ACM Transactions on Computer Systems (TOCS) 26, no. 2 (2008): 4. [4] https://github.com/brianfrankcooper/YCSB/wiki [5] https://okeanos.grnet.gr [6] http://www.infosys.tuwien.ac.at/research/viecom/SYBL/ [7] http://www.infosys.tuwien.ac.at/research/viecom/mela/ [8] http://git-‐scm.com/ [9] http://openstack.org

(23)

[10] http://maven.apache.org/pom.html [11] http://www.synnefo.org

[12] http://sixsq.com/products/slipstream.html

Automatic, multi- grained elasticity- provisioning for the Cloud