D6.5.3 - MODAClouds

Grant Agreement N° FP7-318484

Title:

Runtime Environment Final Release

Authors:

Gabriel Iuhasz, Silviu Panica (IEAT), Giuliano Casale, Weikun Wang, Pooyan Jamshidi (Imperial), Danilo Ardagna, Michele Ciavotta (Polimi), Darren Whigham (FLEXI), Nicolas Ferry (SINTEF), Román Sosa González (ATOS)

Editor:

Daniel Pop (IEAT)

Reviewers:

Arnor Solberg (SINTEF), Alexander Gunka (BOC)

Identifier:

Deliverable # D6.5.3

Nature:

Prototype

Version:

1.0

Date:

31/03/2015

Status:

Final

Diss. level:

Public

Executive Summary This prototype deliverable presents the final release of the MODAClouds Runtime Environment. The platform builds upon the initial prototype presented in D6.5.1 “Run-time Environment Proof-ofConcept” and in D6.5.2 “Run-time Environment Initial Release”. The final release of the platform aligns the technical naming with the business assets, so that Runtime Environment is referred to as Energizer 4Clouds throughout the whole deliverable. The main features implemented in the 3rd year of the project mainly add support for auto-scaling and multi-cloud. The SLA management benefits of an improved SLA monitoring and it brings in a new component, namely SLA Dashboard. For all components, the deliverable provides a high-level overview, while the detailed information is available in the GitHub repositories.

Copyright © 2015 by the MODAClouds consortium – All rights reserved. The research leading to these results has received funding from the European Community's Seventh Framework Programme [FP7/2007-2013] under grant agreement n° 318484 (MODAClouds).

MODAClouds

D6.5.3

MOdel-Driven Approach for design and execution of applications on multiple Clouds

Members of the MODAClouds consortium: Politecnico di Milano Stiftelsen Sintef Institutul E-Austria Timisoara Imperial College of Science, Technology and Medicine SOFTEAM Siemens Program and System Engineering BOC Information Systems GMBH Flexiant Limited ATOS Spain S.A. CA Technologies Development Spain S.A.

Italy Norway Romania United Kingdom France Romania Austria United Kingdom Spain Spain

Published MODAClouds documents These documents are all available from the project website located at http://www.modaclouds.eu/ Software releases are available for download at http://www.modaclouds.eu/software/public-deliverables/

Final version 1, dated 31 March 2015

Page

2

MODAClouds Deliverable # D6.5.3

MOdel-Driven Approach for design and execution of applications on multiple Clouds

Contents 1 Introduction 1.1 Context and Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.1.1 Challenges and Achievements Overview . . . . . . . . . . . . . . . . . . . . . . 1.1.2 Structure of this document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 Achievements 2.1 What is new . . . . . . . . . . . . . . 2.2 The final release of Energizer 4Clouds 2.2.1 Use Case Example . . . . . . 2.2.2 Conclusion . . . . . . . . . .

4 4 5 7

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

8 8 9 9 11

A ADDapters 4Clouds A.1 Support Services . . . . . . . . . . . . . . A.1.1 Object Store . . . . . . . . . . . . A.1.2 Artifact Repository . . . . . . . . . A.1.3 mOS Platform . . . . . . . . . . . A.2 Load Balancer . . . . . . . . . . . . . . . . A.2.1 RESTful API for the Load Balancer A.2.2 Load balancing Failure management A.3 ]’ } keyValues : name : vm1 Finally, the remove command, which is used to remove a value or an object from the deployment model, follows the syntax described below. modification !remove{ parent : XPath property : Property index : Object value : Object crossRef : XPath }

//-- choose one from index, value, or crossRef //-- But for map, we always need an index

Currently, the extend command supports the following commands: LoadDeployment, Deploy, and Start and follows the syntax described below. instruction !extended{ name : String //the name of the command to be executed params* : String //the parameters needed to execute the command } B.1.1.5.3 Interacting with the Models@Runtime engine with the CloudML library CloudML can be packaged as a library in order to be used programmatically. This library also includes the Model@Runtime engine. The Facade6 is the main entry point of the library and can be used to trigger deployments and adaptations of multi-cloud applications. From a technical point of view, the Facade follows the Command Pattern : each feature can be triggered by sending the related command to the facade. Command can be executed either in a synchronous or asynchronous way. Synchronous command will block the client execution until completion, whereas asynchronous commands will let the user continue its own activity while the command is running. Below is the Java interface of the Facade: public interface CloudML extends CommandHandler{ public void fireAndForget(CloudMlCommand command); public void fireAndWait(CloudMlCommand command); public void register(EventHandler handler); public void terminate(); public Deployment getDeploymentModel(); } 6

https://github.com/SINTEF-9012/cloudml/tree/master/facade

Public Final Version 1.0, Dated 31 March 2015

39

MODAClouds MOdel-Driven Approach for design and execution of applications on multiple Clouds


The Facade can be used in two modes: local and remote. In the local mode, the CloudML library is actually used to perform the deployment. Below is an example of how can be use the faade to load a deployment and enact it: CloudML cml= Factory.getInstance().getCloudML(); CommandFactory fcommand = new CommandFactory(); CloudMlCommand load = fcommand.loadDeployment(this.jSonFile.getAbsolutePath()); CloudMlCommand deploy = fcommand.deploy(); cml.fireAndWait(load); cml.fireAndWait(deploy); B.1.1.5.4 Models@Runtime engine GUI The Models@Runtime engine comes along with a Web-based graphical user interface7 . Currently, this interface provides the following features: (i) monitoring the deployment of a cloud-based application, (ii) triggering a deployment, and (iii) starting the scale out and burst commands (cf. Section B.1.2.4). As depicted in Figure B.3, within the editor, deployment model are denoted using a graph-based representation. Components are depicted as node and Relationships and ExecutionBindings (cf. D4.2.2) are depicted as arrows. The orientation of the arrows indicates that a node offers a feature to another node. The web editor embeds a deployment model in javascript which, once the editor connected to the Models@Runtime engine service, is synchronized with the running system, becoming itself a Models@Runtime. A deployment model can be loaded in two ways: (i) from a local file, the model can later be pushed to the Models@Runtime engine service, or (ii) retrieved from a Models@Runtime engine service. In both case, this can be achieved through the ”File:Load” menu.

Figure B.3: Model loaded into the editor As depicted in Figure B.5, a color code has been defined in order to identify the status of the various components of the cloud application being monitored. Details of the status can be seen by clicking on each node in the graph. Because deployment models might involve many components and relationships, the web editor allows user to: (i) select a set of components and group them into a single entity, or (ii) collapse all the components exploiting features offered by a component and that are running on the same VM by double clicking on it (see Figure B.6). 7

https://github.com/SINTEF-9012/cloudml/tree/master/ui/webeditor


40



Figure B.4: Connect to the Models@Runtime engine service

Figure B.5: Editor is synchronized whilst the model is being deployed


41



Figure B.6: Nodes can be grouped within a deployment graph Finally, scaling and bursting commands can be triggered by right clicking on a VM instance (see Figure B.7).

Figure B.7: Scaling out a VM


42



B.1.2 Execution Support for Autoscaling and Cloud Bursting Within the MODAClouds, the autoscaling process is understood as the dynamic QoS-based management of a cloud application, Cloud Bursting, instead, is the dynamic expansion of an application running on a private facility over another (public) cloud. Autoscaling addresses the problem to independently scale (in and out) the tiers of each application considered in order to meet the QoS requirements set at design time reducing at the same time the execution costs. Most of the cloud providers typically have naive or even no autoscaling mechanisms. The approach implemented in the MODAClouds project is, instead, based on a receding horizon mechanism working on a model of the application relying on queueing theory. To improve the effectiveness of our approach we introduced a feedback loop and a set of filters that refine and update the model parameters. Cloud bursting, on the other hand, concerns the problem of scaling out applications running within limited private clouds, by leveraging external resources provided by public or other private clouds. Cloud bursting is typically an adaptation leading to a multi-cloud deployment. Since both autoscaling and cloud bursting are required to scale the system and since both rely on Models@Runtime engine, in this section of the document, they will be jointly addressed. The following paragraphs present how the autoscaling and cloud bursting are enacted, how Tower 4Clouds is adapted to take into consideration the new deployment of the application and how encoding="UTF-8"?> Comment describing your root element Public Final Version 1.0, Dated 31 March 2015

64



Listing B.2: designAdaptationModel.xml

Listing B.3: Example of monitoring rule 1 Public Final Version 1.0, Dated 31 March 2015

65



1 ${VALUE(1)} > 4 RegisterWebTierResponseTime ${VALUE(1)}-${VALUE(2)} ${RESOURCEID(1)}

B.2.2.2.2 MAR Controller MAR Controller is the heart of the continuous adaptation mechanism at runtime. It is in charge of enacting the runtime optimisation step implementing a Receding Horizon algorithm to solve the virtual machine capacity allocation problem in a multi-cloud environment. Each execution of MAR Controller determines the number of VM instances to lease for each class, suitable to serving the incoming predicted workload, minimising the cost and guaranteeing that the average response time of each class is lower than a specified threshold. What is worthwhile to note is that the set of classes is made of all the application tiers deployed on a particular type of VM instance, that is homogeneous in terms of their computing capacity. So the number of executions of MAR Controller that is launched at each adaptation step is equal to the number of distinct clusters of VM on which at least one application tier is deployed. We model, as a first approximation, each class k hosted on a VM instance as an M/G/1 queue. In the following k will then use to indicate an application tier of the design time models. Moreover, multiple VM instances can run in parallel hosting the same class. Each VM instance is characterised by a capacity C (obtained from the design time Resource Model timeStep="10" timeWindow="10"> Public Final Version 1.0, Dated 31 March 2015

67



1 Workload METRIC ID Workload 30 1 1 1 300 ForecastedWorkloadFirst METRIC ID

The demand is, instead, estimated from information on the CPU Utilisation and the average response time of the considered resource. As before, the MAR must ensure that those metrics are observable by Tower 4Clouds, which is the same as checking there are appropriate rules installed. If those rules were not already installed, the tool will arrange for such rules to be installed; the rule appointed to monitor the demand soon after. An example of rules to monitor the average CPU utilisation, the average response time and consequently the demand are presented in Listing B.5. Also in this case the application methods are considered as target resources, but again the information can be monitored at a different granularity. Listing B.5: Example of rule for demand estimation 1 5 FrontendCPUUtilization METRIC ID


68



1 AvarageResponseTime METRIC ID 60000 4 MIC FrontendCPUUtilization AvarageResponseTime 300 /home/ubuntu/modaclouds-sda-1.2.2/ EstimatedDemand METRIC ID

B.2.2.5 Autoscaling workflow The rationale of this section is to describe the workflow of the self-adaptation autoscaling process at runtime. The self-adaptation loop can be roughly described a sequence of four actions executed by the MAR component at regular intervals. Such actions are: • updating the parameters of the MILP model with the latest estimates and predictions provided by the SDAs for all class k; • launching the executions of the MAR controller; • analysing the outcomes of the optimisation step to spawn suitable adaptation actions; • enforcing the resulting adaptation actions. A typical adaptation action at runtime can be, for example, starting a new VM in the moment in which the predicted workload growth was significant. In order to do this, the MAR Controller must keep an internal representation of the state of the system at runtime, in terms of all the VM instances that are switched on and off. In particular, for each VM the following record is stored:


69



where VMid is trivially the specific VM instance id, which is necessary to operate on it; status indicates whether the VM is powered on or off; and timeElapsed indicates the elapsed time since the purchase of the VM instance occurred. In this way all possible situations of adaptation are easily manageable. The critical point, however, is that MAR Controller returns only the number of VM instances that must be in execution in the next time step in order to handle the expected workload, but does not indicate whether it is possible to turn off some VM instances that currently represent a capacitive surplus. As a result, three critical scenarios are possible and since they are helpful in understanding the component behaviour we report them below: • if the solution of the MILP, knowing that the next time step a number of VMs currently active would expire, indicates that no new VMs must be purchased in the next timestep, we must then turn off these VMs at the time of their expiry. • if the solution of the MILP, knowing that the next time step a number of active VMs would expire, indicates instead a positive number of VM instances to be turned on at the next time step, then the VM instance at the expiration will not go off, but simply re-charged, while only the difference between those reported as to buy will actually purchased and started through M@R. • The last possible scenario is that in which there is no VM instance would expire at the next time step; in this case it will be purchased exactly the number of necessary VM reported by the solution of MILP model. B.2.2.6 User guide Prerequisite for the installation of MAR is having up running the following components: • Models@Runtime listening via the web socket interface • one instance of Tower 4Clouds • a CMPL (and CBC, the MILP solver) installation reachable through SSH Then one can launch the MAR executing its .jar file and passing as an argument the path to a suitable configuration file: java -jar modacloudsAutoscalingReasoner-1.0.jar The configuration file is an .xml file containing the information outlined in the template presented in Listing B.6 Listing B.6: MARConfiguration.xml

B.2.2.7 Cloud Bursting The support module for cloud bursting is the component within Energizer 4Clouds that supervises and manages the cloud bursting in a context of private and public cloud deployment. This module implements a rule-based control architecture where the Cloud Bursting Monitoring Rules, hereinafter referred to as CB-MRs, make scaling decisions over clusters of homogeneous VMs (corresponding to one application tier), enacting adjustments on the running application in terms of number and collocation of VMs through the Models@Runtime engine. The responsibilities of a CB-MR in normal conditions only involve the reactive enactment of a threshold-based scaling policy for a certain tier, however when the private cloud cannot start additional VMs, it acts at a higher level making decisions on cloud bursting. In a nutshell, a special monitoring rule is associated with each application tier and it continuously observes the average response time of the tier at hand. If the average response time exceeds the threshold a scaling out command is automatically triggered. However, in the scenario in which the a new VM cannot be started because of the private environment is saturated, the rule commands a full burst of the application on a public cloud. Figure B.21 depicts the interaction between the MODAClouds support module for Cloud Bursting (CB-MR) and the other runtime components of Energizer 4Clouds. In the scenario described in the figure, both the Models@Runtime engine and Tower 4Clouds platform reside in the private cloud. Moreover, we considered the case of n possible clusters corresponding to n application tiers running on heterogeneous VMs. For each application tier a suitable Data Collector (DC) measures the average response time and sends the data collected to Tower 4Clouds. Here, a set of n monitoring rules (CBMRs) are listening the data flow coming from the DCs and checking whether the response time exceeds a certain threshold value. Notice that the picture reports a second set of CB-MRs because in case of cloud bursting a new set of rules has to be installed to control the remote application. Models@runtime

CB-MR Private Tier 1

…

CB-MR Private Tier n

CB-MR Public Tier 1

…

CB-MR Public Tier n In house Cloud&Applica,on&

Cloud Cloud&Applica,on&

Monitoring Platform

Tier 1 - DC

Tier 1 - DC

Tier 2 - DC

Tier 2 - DC

Tier n - DC

Tier n - DC

Figure B.21: MODAClouds support module for Cloud Bursting


71



With the aim to gain a deeper insight of the MODAClouds support module for cloud bursting in the follow we describe two meaningful scenarios. Scenario 1 In this first scenario we focus on the simple situation in which the application is deployed only in local facilities. The case in which the status quo has to be kept or the number of VMs has to be reduced are not interesting for the cloud bursting case. The situation in which a CB-MR detects the need for an increment in the number of VMs is important, though. In this case, the CB-MR orders the Models@Runtime engine to scale out the related tier. The Models@Runtime engine controls the underlying cloud platform and trigger a proper scale out command. However, if the current spare capacity is insufficient to host the new VM it catches an error message and, in turn, it notifies an unsuccessful operation of the CB-MR. In this case the CB-MR asks the Models@Runtime engine to deploy the whole application (a VM for each tier) in the chosen public cloud and update consequently the settings of MODAClouds load balancer. We assume that the rule knows a priori the public cloud to burst in and the type of VM to be requested for each tier. Scenario 2 In this scenario the cloud application is already replicated in the environment supplied by the public cloud provider. If the CB-MR determines that the number of VMs allocated in the public cloud can be reduced and if this implies turning off a whole tier, the rule asks the Models@Runtime engine to turn off the remote application whenever possible and redirect the workload to the local cloud environment. As final a remark, notice that in the scenarios reported before the whole Monitoring/Cloud Bursting module/Enacting environment (i.e. Tower 4Clouds, the CB-MRs and the Models@Runtime engine) are entirely executed within the local private cloud platform whereas the public cloud runs only the application components. This design choice has been made in order to make easier and faster the cloud bursting process.


72



B.2.3 Self-Adaptation Tester In the design of MODAClouds Energizer 4Clouds, it has been observed that it is important to have a tool for workload generation capable of validating the efficiency of a given self-adaptation method to respond to sudden changes in the workload. This stress testing tool, called MDload, presented in this section addresses this problem, taking as an input the Palladio Component Models generated by the MODAClouds IDE and transforming them to a sequence of workload generation actions that are then executed on the running application. B.2.3.1 The MDload tester MDload is a model-driven workload generation tool that automatically generates requests to a web application by simulating a set of users. It has been developed as part of MODAClouds Energizer 4Clouds to fulfill the need for a self-adaptation testing tool, capable of injecting on-demand load to the cloud applications with characteristics of variability and burstiness. MDload is a general-purpose tool as it can be configured to generate traffic for specific applications. This is achieved by implementing a set of routines that generate and submit the application requests, but allowing the user to define the specific requests to submit and their order. This therefore simplifies the testing of web applications, since it is only necessary to define how the user interacts with the application. Once the user behavior has been specified, MDload emulates a set of users by relying on Selenium10 to automate a Firefox web browser that sequentially submits requests to the application server. MDload is able to generate bursty traffic, dynamically changing the traffic mix, that is, the proportion of requests types generated by the users. This behavior better represents the actual workload faced by the application. The operation of MDload is built in three logical layers. The lowest layer is the request level, which considers atomic requests submitted by the user. The second layer is the session level, where a single user submits a sequence of semantically-correct requests, reproducing an expected usage pattern. The highest logical level is the benchmark level, where a number of sessions are managed to achieve the predefined workload characteristics. These levels are associated with the three main actors participating in the traffic generation, namely the Overseer, the Dispatcher and the UserAgents, which are implemented as Java Threads. The main thread spawns an instance of the Overseer, which is the object delegated to coordinate the test at the benchmark level. The Overseer simply creates an instance of a Dispatcher, which creates and manages UserAgents threads. Each UserAgent generates traffic by submitting requests to the Selenium driver that produces HTTP requests via Firefox. This operation is therefore automated by MDload, and it is only necessary to specify the user behavior as described next. B.2.3.1.1 Specifying User Behavior To specify the application user behavior, the MDload user needs to specify (extend) two main (abstract) classes: Request and Session. These abstract classes are defined in the mdload.client.workload package, distributed as part of the mdload-dev project. The class Request is used to determine the action necessary to submit each of the possible application requests, which is done by implementing the action method. Thus, one Request class needs to be implemented for each type of application request to generate. The action method has Selenium Web driver object as its only parameter, which enables the action to use its functionality to interact with the application, e.g., clicking, clearing and filling fills, and submitting forms, among others. The second abstract class to extend as part of MDload is Session, which determines how an application user submits the different requests defined as Request classes. The constructor of a Session object includes a unique user identifier that enables MDload to distinguish among the different users active in a benchmark. The MDload user needs to implement two methods, getWarmUp and getNext, both of which provide a set of Requests to execute, in the form of a Linked List. The getWarmUp 10

http://docs.seleniumhq.org/


73



method is used during a first stage called Warm Up, which is typically used to register users with the application, so that they are able to access it later on. The getWarmUp method therefore returns a list of Requests that reflect this behavior, including for instance clicks to registration forms, filling and submitting these forms, among others. The getNext method is used once the Warm Up period has finished, and it therefore returns a list of requests that reflect the common usage of the application, including both logged-in and non-logged in users. After extending these classes, they must be compiled to create a non-executable jar file. The location of this jar file needs to be provided to the MDload application, by means of the config.client properties file, as follows WORKLOAD JAR = C://path//to//file//myapp-mdload.jar Similarly, the main Session class must be specified in the same properties file as follows WORKLOAD CLASS = mdload.userdefined.session.TestSession With these definitions, MDload is able to generate traffic for specific application considered, using the classes defined above. B.2.3.1.2 Automatic generation of requests from Palladio models Palladio component models provide a compact specification of a software application, including the workload that the users are expected to generate. To take advantage of this, MDload offers the module mdload-matlab, which generates a sequence of requests according to the usage defined in the Palladio model. The module is developed in Matlab11 and uses as input an XML file containing a Layered Queueing Network (LQN) model. This XML file can be easily obtained using the PCM2LQN transformation implemented in Palladio Bench, and therefore can help in bringing to Energizer 4Clouds the Palladio models. In addition to providing the LQN model in XML form, it is also necessary to provide a mapping between the Palladio request calls and the specific application calls. This is needed because a Palladio model may define a set of high-level requests, which are not the actual application requests. This is a standard approach to reduce the model complexity. For instance, a request in the Palladio model may correspond to a sequence of application requests that are always executed together in a certain context. This mapping can be specified in the function parseCallRequest in the script MDLprotocol, which consists of a switch instruction listing the possible requests names in the Palladio model and assigning them the corresponding application request names. Multiple application requests can be specified for a single Palladio request name by concatenating them with semi-colons. As an example, consider a checkLogin request defined in Palladio, which in fact refers to two consecutive application requests: Login and LoginDetails. The parseCallRequest function mentioned above will thus return the string Login:LoginDetails whenever checkLogin is specified as the Palladio request name. B.2.3.1.3 An example: OFBiz The MDload tool can be downloaded from https://github.com/imperial-MODAClouds. In addition to the libraries and source code, the distribution also includes a full example on how to use the MDload tool for the case of the OFBiz e-commerce application12 . The example includes the definition of the Request and Session classes, the resulting jar file, and the request mapping in Matlab.

11 12

This module is implemented in Matlab, but its binaries do not require a Matlab license to be executed. http://ofbiz.apache.org/ Public Final Version 1.0, Dated 31 March 2015

74



Appendix C

Other Tools C.1 SLA Monitoring The SLA tool, documented in D5.4.3, is the component responsible for generating a formal document describing a Service Level Agreement between the involved parties in MODAClouds: customers, application providers and cloud providers. This is an output of WP5 that plays an interfacing role between runtime and QoS/SLA analyses, thus it is here briefly summarized. Then, as original contribution of this deliverable, we focus on the integration of the SLA tool as part of Energizer 4Clouds, from which it dynamically consumes monitoring metrics for SLA monitoring purposes. On the other hand, the SLA tool must assess in runtime the business penalties (QoB: Quality of Business) associated with the fulfillment of the non-functional properties already assessed in Tower 4Clouds. We illustrate in Figure C.1 the key dependencies between Energizer 4Clouds and the SLA Tool.

Figure C.1: Dependencies of SLA Tool. Arrows indicate “depends on” relationships.


75



Latest version: https://github.com/modaclouds/modaclouds-sla-mediator, https://github.com/modaclouds/modaclouds-sla-core, https://github. com/modaclouds/modaclouds-sla-dashboard

C.1.1

Overview

In the MODAClouds context, Cloud Service Providers charge Application Providers for renting cloud computing resources and added value features provided by MODAClouds platform to design (model) and govern (deploy and manage at runtime) their applications. Application Providers (AP) may charge their Customers for processing their workloads (e.g., in Software-as-a-Service fashion) or may process the user requests for free (cloud-hosted business application). In both cases, Application Providers need to guarantee their customers SLA. In this scenario there are three parties to be taken into account: • Cloud Service Providers (CSP): They offer client provisioned and metered computing resources (e.g., CPU, storage, memory, network) that can be rented for flexible time durations. In particular, they include: Infrastructures-as-a-Service providers (IaaS) and Platform-as-a-Service providers (PaaS). Examples are: Amazon, Microsoft (Azure), Google (App-Engine), Rackspace, CloudBees, etc. • Application Providers (AP): They represent the cloud-hosted software applications that utilize the services of CSP and are financially responsible for their resource consumptions. To provide their application to the final users, they rely on the capabilities provided by MODAClouds tools. • Customers (End Users): They represent the legitimate users for the services (applications) that are offered by application providers. In the practice, we can consider that the resource management and SLA guarantee can fall into two separate layers: the Cloud Service Provider and the Application Provider. The Cloud Service Provider is responsible for the efficient utilization of the physical resources and guarantees their availability for their customers. Application Providers are responsible for the efficient utilization of their allocated resources in order to satisfy the SLA of their customers (end users) and achieve their business goals. Figure C.5 illustrates the relationship between the Customer/Application Provider SLA (C-AP SLA) and the Application Provider / Cloud Offering SLA (AP-CP SLA) in the software stack of cloud-hosted applications through MODAClouds. Figure C.3 shows an example of functionalities provided by an AP, using response time as QoS. The users are only concerned by the whole application response time, that are determined by operations O1, O2, O3, O4 and O5. So, the C-AP SLA will reflect these operations and desired QoS. On the other hand, the AP-CP SLA enforces the QoS of sub-operations. One of the features of SLA framework in MODAClouds is the use of Qualify of Business (QoB) metrics. The QoB rules rely on QoS rules to create complex metrics focused on business accounting. E.g., a certain number of Response Time violations in one day produce a penalty to the service provider, probably a price discount for that day. A possible business violation for the previous example is shown in Figure C.4, where besides the QoS levels, accounting penalties are also taken into account. In principle, business values can only be considered in the C-AP SLA, as MODAClouds cannot force CP to respect business values.

C.1.2

Components

The SLA Tool comprises a REST server (the SLA core), providing the main features, plus two additional helper tools: SLA Mediator and SLA Dashboard. The Mediator tool is a set of components that act as a


76



layer on top of the core, to add some MODAClouds’ specific behaviour. The SLA Dashboard shows the violations and penalties of agreements in a user-friendly way. The implemented code is divided into three Open Source projects: • MODAClouds-sla-core • MODAClouds-sla-mediator • MODAClouds-sla-dashboard Figure C.2 shows how the SLA Components are organized and how they are related to other MODAClouds components: • SLA Repository: provides useful capabilities to manage the persistence of SLA Templates, SLA Contracts and the relation between Services / Contracts / Templates. Moreover, it provides a place where Business Level Violations are stored and retrieved. • SLA Mediator: maps the QoS constraints defined by the QoS Engineer in SLA Agreements of both SLA levels. • Tower 4Clouds: the MODAClouds Tower 4Clouds is in charge of detecting the QoS violations and notify the Assessment component. • Assessment: computes the possible business violations, notifying any observer (like an external Accounting component) of raised penalties. • The MODAClouds IDE starts the SLA generation process. • The Dashboard shows the agreements’ violations and penalties to the final user in a user-friendly way.

C.1.3

Integration with Tower 4Clouds

The SLA Tool needs to communicate with Tower 4Clouds to perform its runtime tasks: • Attach as a metric observer of the relevant metrics. This step is executed at deployment time. The relevant metrics are obtained from the agreement document generated at design time with the help of the IDE. • Receive and store the constraint violations, calculating the penalties that incur in violating the QoB in the case of the C-AP SLA. These violations and penalties may be consumed later by the Cloud App Admin for further analysis, using the dashboard or other external tools.

C.1.4

Integration with the Models@Runtime engine

A mandatory step for the Runtime assessment of the agreements is the start of the enforcement job. That step was previously executed by hand using the Starter program in the Mediator. Now the Models@Runtime engine communicates the deployment of the application to the SLA Tool. The deployment model contains the agreement ids that are needed to start an enforcement job. When the Models@Runtime engine triggers the enforcement start of the C-AP agreement, all the related APCP SLA agreements are started. The main task of this process is the attachment to Tower 4Clouds as a metric observer of the QoS violations observed in the agreements.


77


C.1.5


Core

C.1.5.1 Installation For instructions on how to install the sla-core, we point to the appendix of D5.4.3. C.1.5.2 Usage The sla-core exposes a REST interface to interact with it. The exposed resources are: • providers • templates • agreements • violations • penalties There is also an operation relevant for Energizer 4Clouds, in charge of starting the enforcement of the agreement of the C-AP SLA level and the corresponding agreements of the AP-CP SLA level. This operation enables the listening of QoS violations of the C-AP and AP-CP SLA levels and the QoB enforcement of the agreement of the C-AP SLA level. For this purpose, it attaches the sla-core as a metric observer of the rules referenced in the agreements. For a detailed user guide, we point to the appendix of D5.4.3

C.1.6

Mediator

C.1.6.1 Installation The mediator does not need installation in its current form. The compile process generates a selfcontained jar in target/ directory, which may be executed or distributed. C.1.6.2 Usage The mediator contains an utility to start the enforcement of an agreement: the Starter. Since the integration with cloudML, this utility is only useful for debugging purposes: cloudML is now the responsible to perform the necessary REST call to the core to start the enforcement. The Starter is a command line application that takes as input an agreement identifier (that has been previously defined by the use of Modelio) and subsribes the core as an observer of Tower 4Clouds for the relevant metrics. The available options are: –id value : Agreement Id [–callback value] : Callback Url. If not set, fallback to $sla/metrics –user -u value : Sla Credentials (user:password) [–dir -d value] : Directory where to find rules file. If not specified, tries to retrieve OutputMetric information from agreement –metrics value : Monitoring Platform Metrics Url –sla value : Sla Core Url So, for example, a valid invocation is: $starter –id a2e81c4e-6814-48d0-8493-6f3e68a4aae7 –sla http://localhost:8080/sla-service –user user:password –metrics=http://192.168.56.101:8888/v1/metrics The program retrieves the agreement from the core and attach to the metrics.


78



Figure C.2: SLA Management: Architecure

Figure C.3: SLA Management: Operations

C.1.7

Dashboard

The SLA Dashboard is a web application where the Cloud App Admin can consult the QoS violations and QoB penalties of the agreements that are comprising the application. C.1.7.1 Installation For instructions on how to install the SLA Dashboard, we point to the appendix of D5.4.3. C.1.7.2 Usage The main screen lists the agreements of both SLA levels and their status. The agreement detail will be showed when clicking on the ’agreement info’ link, where we can inspect the parties of the agreement, a summary of the raised violations and the business penalties that have been applied according to the business rules. From the agreement detail screen we can access to the the actual agreement text, and to the full violations list per guarantee term. For more details, we point to the appendix of D5.4.3


79



Figure C.4: SLA Management: QoB and QoS

Figure C.5: SLA Management: Layers


80



Bibliography [1] G. Casale, C. Craciun, M. Neagul, I. Gabriel, S. Panica, J. F. Perez, W. Wang, D. Ardagna, M. Ciavotta, C. Sheridan, N. Ferry, F. D’Andria, and R. S. Gonzlez, “Runtime Environment Initial Release,” Modaclouds Deliverable D6.5.2, 2014. [2] F. D’Andria, “MODAClouds Integration Report - Initial Version,” Modaclouds Deliverable D3.4.1, 2014. [3] M. Miglierina, W. Wang, G. Casale, and V. I. Munteanu, “Monitoring Platform Final Release,” Modaclouds Deliverable D6.3.2, 2014. [4] R. T. Fielding, “Architectural styles and the design of network-based software architectures,” Ph.D. dissertation, 2000, aAI9980887. [5] M. Grinberg, Flask Web Development: Developing Web Applications with Python, 1st ed. O’Reilly Media, Inc., 2014. [6] M. Scavuzzo, Modaclouds Deliverable D6.7, 2015. [7] B. Morin, O. Barais, J.-M. Jézéquel, F. Fleurey, and A. Solberg, “[email protected] to Support Dynamic Adaptation,” IEEE Computer, vol. 42, no. 10, pp. 44–51, 2009. [8] G. Blair, N. Bencomo, and R. France, “[email protected],” IEEE Computer, vol. 42, no. 10, pp. 22–27, 2009. [9] “Haproxy,” http://www.haproxy.org//. [10] J. Anselmi and G. Casale, “Heavy-traffic revenue maximization in parallel multiclass queues,” Performance Evaluation, vol. 70, no. 10, pp. 806–821, 2013. [11] G. Casale, F. Kalo, J. F. Pérez, W. Wang, D. Ardagna, M. Ciavotta, and G. Iuhasz, “D6.4 run-time adaptation policies,” 2014. [12] “The modaclouds haproxy rest api,” https://bitbucket.org/igabriel/pyhrapi/. [13] “The modaclouds monitoring manager repository,” https://github.com/deib-polimi/modacloudsmonitoring-manager/. [14] “The modaclouds data collector repository,” https://github.com/imperial-modaclouds/modacloudsdata-collectors/wiki/. [15] “The modaclouds sda repository,” https://github.com/imperial-modaclouds/modaclouds-sda/wiki/. [16] G. Casale, F. Kalo, J. F. Perez, W. Wang, D. Ardagna, M. Ciavotta, and G. Iuhasz, “Run-time adaptation policies,” Modaclouds Deliverable D6.4, vol. 2, 2014. [17] D. Ardagna, M. Ciavotta, and R. Lancellotti, “A receding horizon approach for the runtime management of iaas cloud systemss,” in Proceedings of MICAS-SYNASC 2014 Workshops, 2014. Public Final Version 1.0, Dated 31 March 2015

81



[18] G. Casale, F. Kalo, J. F. Pérez, W. Wang, D. Ardagna, M. Ciavotta, and G. Iuhasz, “Run-time adaptation policies,” MODAClouds EU Project Deliverable, 2014. [19] D. Ardagna, M. Ciavotta, and R. Lancillotti, “A receding horizon approach for the runtime management of iaas cloud systems,” Symbolic and Numeric Algorithms for Scientific Computing (SYNASC), 2014 16th International Symposium on, pp. 417–423, 2014.


82