D5.2.2 - MODAClouds

Grant Agreement N° FP7-318484

!

Title:

MODACloudML QoS abstractions and prediction models specification – Final version

Authors:

Danilo Ardagna, Michele Ciavotta, Marco Miglierina, Giovanni Paolo Gibilisco (Polimi), Giuliano Casale, Juan Pérez (Imperial), Francesco D’Andria, Román Sosa González (ATOS)

Editor:

Danilo Ardagna, Michele Ciavotta (Polimi)

Reviewers:

Nicolas Ferry (SINTEF), Cosmin Septimiu NECHIFOR (Siemens)

Identifier:

Deliverable # D5.2.2

Nature:

Report

Version:

1.0

Date:

10/10/2014

Status:

Final

Diss. level:

Public

Executive Summary This deliverable presents the final version of the MODACloudML languages and models for designtime non-functional analysis of Cloud applications. In particular, this document deals with those features that allow the specification of Quality of Service (QoS) constraints, performance and costs evaluation, and the specification of monitoring rules and SLAs. The modelling concepts and metamodels are detailed and illustrated on the MiC (Meeting in the Cloud) application use case.

Copyright © 2014 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


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 srl 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/

Draft version 1.0, dated October 10, 2014

2

MODAClouds Deliverable # D5.2.2

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

Contents 1

2

3

Introduction 1.1 Context . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2 Structure of the document . . . . . . . . . . . . . . . . . . 1.3 Objectives of the current deliverable and their achievement 1.4 Extensions with respect to Deliverable D5.2.1 . . . . . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

4 4 4 5 6

Use of MODACloudML for QoS and cost analysis 2.1 The MiC use case . . . . . . . . . . . . . . . . 2.2 CPIM and CPSM for performance specification 2.3 Constraints Specification . . . . . . . . . . . . 2.4 Monitoring rules specification . . . . . . . . . 2.5 SLA specification . . . . . . . . . . . . . . . . 2.6 Private Cloud Modelling and Cloud Bursting .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

7 7 14 17 19 21 26

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

Summary

28

Appendices

30

A Modelling Cloud Concepts A.1 CPIM for QoS and Cost Analyses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A.2 CPIM for Private Cloud specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . A.3 CPSM: The Windows Azure use case . . . . . . . . . . . . . . . . . . . . . . . . . . .

30 30 35 35

B MODACloudML for performance specification

45

C Mapping MODACloudML Models to PCM C.1 Mapping MODACloudML Meta-Models to the PCM . . . . . . . . . . . . . . . . . . . C.2 Cost derivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

50 50 53

D MODACloudML for constraints specification

56

E MODACloudML for Monitoring rules specification E.1 Monitoring Platform Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . E.2 The Monitoring Ontology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . E.3 Monitoring rules specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

58 58 58 60

F MODACloudML for SLA specification F.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . F.2 WS-Agreement implementation for MODAClouds SLA . . . F.3 Customer - Application Provider template generation . . . . F.4 Customer - Application Provider Agreement generation . . . F.5 Application Provider - Cloud Provider template generation . F.6 Application Provider - Cloud Provider Agreement generation

66 66 68 69 70 70 70

. . . . . .

Public Final Version 1.0, dated October 10, 2014

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

3

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

1


Introduction

This deliverable describes the MODACloudML Quality of Service (QoS) abstractions and prediction models that will be adopted within the project. These abstractions will allow the QoS Engineer to perform QoS evaluations, cost estimates, design-time exploration and optimisation of applications running on multiple Clouds and to specify Service Level Agreements (SLAs), that will be enacted at run-time. Furthermore, the models and a language for the specification of monitoring rules is provided as well.

1.1

Context

Verifying that a software system has certain non-functional properties is a primary concern for Cloud applications1 . Cloud technology offer and pricing models adopted by Cloud providers are very heterogeneous and the selection of the solution that fits the application requirements and provides the best QoS and costs trade-off is a non-trivial task. Within MODAClouds, we provide new design abstractions that help the QoS Engineer in specifying QoS requirements and compare multiple Cloud architectures evaluating costs and performance for each of them. This task can be very challenging, even infeasible if performed manually, as the number of possible solutions may become very large considering the number of possible providers and application configurations. Furthermore, Cloud systems are usually multi-tenant and their performance can vary with the time of day, according to the congestion level and the competition among the applications. New models and tools for the evaluation of QoS properties, such as availability and response time, of such systems will be proposed. As said, an assessment of the usage cost of cloud resources is obtained after the analysis of the QoS properties; however, business oriented cost analyses are performed within WP2, which include, e.g., migration costs and risk related costs. WP2 benefit by WP5 analyses to have a more accurate estimate of application performance and the billing cost for the selected cloud providers. Finally, since for availability reasons MODAClouds is envisioning the possibility to run applications on multiple clouds, we provide also models and a language that will simplify the problem of gathering and reasoning on monitoring ?> a5759880-8b34-4db4-b652-35 e63d3f2ebb__resourceContainer VM CPUUtilization 0.5 bdab062f-1760-42c5-8f9a-fedc706ff219_6f727885-d59f-4 f87-a71c-7d7cc1792eaa_seff Method ResponseTime 1000 38f6ef32-8eba-4d66-8303e6f69acd7d6c__resourceContainer VM RAM 2048 1 AverageRespTime ATOS amazon AgreementResponder 2015-09-10T12:24:22GMT f48fdf8c-5e44-42b3-8ec7-7a45998edcdb A list of Monitoring Rules

manual.md#what-is-a-monitoring-rule


63




64



Figure 40: The monitoring rules schema graphical representation


65


F


MODACloudML for SLA specification

F.1

Introduction

In the context MODAClouds is considering, Cloud Service Providers charge Application Providers for renting cloud computing resources. Application Providers (AP), in turn, 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. Moreover, SLA violations have also an implication on SaaS reputation and revenue loss incurred in the case of cloud-hosted business applications. For example: Amazon found every 200ms of latency cost them 1% in sales; Google experienced that an extra 700ms in search page generation, implies a traffic drop around 25%. In addition, large enterprise web applications (e.g., eBay and Facebook) need to provide high assurance in terms of SLA metrics such as response times and service availability to their users. Without such guarantees, service providers of these applications stand to loose their user base, and hence their revenues. For this reason we felt the need to extend MODACloudML (with respect to the the previous version reported in D5.2.1) in order to allow the SLA specification. In MODAClouds context, there are three parties to be taken into account from an SLA perspective: • 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 include Amazon EC2, Microsoft Azure, Google APP-Engine, Rackspace, CloudBees, etc. • Application Providers (AP): They represent the cloud-hosted software applications that use 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 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 41 illustrates the relationship between the Customer/Application Provider SLA (C-AP-SLA) and the Application Provider / Cloud Offering SLA (AP-CO-SLA) in the software stack of cloud-hosted applications through MODAClouds. On the other hand, the lifecycle of an SLA can be split up in several different phases: 1. The preparation of the service offer as a template, 2. The location and mediation of the agreement, 3. The service provisioning and business application deployment, 4. The assessment of the agreement / corrective actions during execution (parallel phase to service execution), and 5. Termination and decommission of the agreement. Public Final Version 1.0, dated October 10, 2014

66



Figure 41: Customer/Application Provider SA relationship


67



Within the MODAClouds project we design and implement a policy-driven SLA framework that focus on the phase 1-4 of the lifecycle. 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. For example, a certain number of Response Time violations in one day produce a penalty to the service provider, probably a price discount for that day. Figure 42 shows an example of functionalities provided by an AP, using response time as QoS.

Figure 42: Example of functionalities provided by an AP, using response time as QoS The users are only worried by the whole application response time, that are in this case 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. A possible business violation for the previous example is shown in Figure 43, 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.

F.2

WS-Agreement implementation for MODAClouds SLA

The SLA framework developed within MODAClouds follows the concepts and XML structure for agreements and templates that are defined in the WS-Agreement specification (an overview of WS-Agreement can be found in [14]). In this specification, a template describe a service offer, and an agreement describe an instantiation of a template associated to a particular customer. WS-Agreement specifies an XML structure to define agreements and templates, and a two layers interface of web services for operation. This implementation is focused on the XML structure, and defines simpler REST interfaces for operation.


68



Figure 43: A possible business violation example

F.3

Customer - Application Provider template generation

For the Customer - Application Provider SLA, only the high level constraints are being considered, i.e. constraints that directly affects the end user. A clear example is a constraint where the Application Provider wants to offer an availability of 99.9% to the Customer. The details of the generation are: • An autogenerated UUID is assigned as TemplateId. • The context is filled with the following data: – service provider; in MODAClouds, the service provider is the AgreementResponder. As such, the element ServiceProvider contains always the value AgreementResponse, and the element AgreementResponder constains a value that represents the service provider (id, name,. . . ) – name of service • There is one guarantee term for each high-level constraint associated to each InternalComponent or Method as value in its targetClass attribute. The scope of the guarantee term is a readable representation of the targetResourceIDRef attribute. If the targetClass is InternalComponent, the scope is the name of the referenced component. If the targetClass is Method, the scope is the concatenation of the name of the component containing the method, and the referenced methods name. The service level of the guarantee term constains three attributes: – QoS: represents the modeled QoS, – aggregation: represents the desired aggregation for the metric. – constraint: contains the name of the associated QoS violation. This indicates that each QoS violation received from the Monitoring Platform is automatically a QoS violation for the SLA Tool. Public Final Version 1.0, dated October 10, 2014

69


F.4


Customer - Application Provider Agreement generation

As a final step SLA agreements are generated from templates. Several agreements can be created based on a single template, although in the context of MODAClouds, only one agreement is generated from a single template. The agreement is a copy of the template, with some extra fields in the context that are not present in the template and include: • the customer, • the expiration time of the agreement, • the id of the template which this agreement is based on.

F.5

Application Provider - Cloud Provider template generation

For the Application Provider - Cloud Provider SLA, only the low level constraints are being considered, i.e., constraints that affects the virtual machine or a component. An example is a constraint where the Application Provider wants a maximum VM CPU utilization of 80% or a constraint where the Response Time of the backend tier should be less than 1 second. The details of the generation are: • An autogenerated UUID is assigned as TemplateId. • The context is filled with the following data: – service provider, i.e., the cloud provider; in MODAClouds, the service provider is the AgreementResponder. As such, the element ServiceProvider contains always the value AgreementResponse, and the element AgreementResponder contains a value that represents the service provider (id, name) – name of service • There is one guarantee term for each low level constraint. The scope of the guarantee term is a readable representation of the targetResourceIDRef attribute. The service level of the guarantee term contains three attributes: – qos: represents the original modelled QoS, – aggregation: represents the desired aggregation for the metric, – constraint: contains the name of the associated QoS violation. This indicates that each QoS violation received from the Monitoring Platform is automatically a QoS violation for the SLA Tool.

F.6

Application Provider - Cloud Provider Agreement generation

Several agreements can be created based on a single template, although in the context of MODAClouds, only one agreement is generated from a template. The agreement is a copy of the template, with some extra fields that are not present in the template: • the customer, • the expiration time of the agreement, • the id of the template which this agreement is based on.


70