Prediction and cost assessment tool Initial version

Transcription

1 Grant Agreement N FP Title: Authors: Editor: Reviewers: Identifier: Nature: Prediction and cost assessment tool Initial version Danilo Ardagna, Michele Ciavotta, Giovanni Paolo Gibilisco (Polimi), Juan Pérez (Imperial), Francesco D Andria, Román Sosa González (ATOS) Danilo Ardagna, Michele Ciavotta (Polimi) Andrey Sadovykh (Softeam), Florin Fortis (IEAT) Prototype Version: 1.0 Date: 02/10/2014 Status: Diss. level: Final Public Executive Summary Cloud technologies provide tools to create dynamic systems capable to react to workload fluctuations by adapting themselves in order to keep the general performance unchanged. However, if on one hand Cloud Computing offers many advantages, on the other it introduces some important issues and new challenges in application development. In fact, the Cloud technologies and the pricing models are currently very different and so complex to evaluate that the selection of the configuration responding to the application requirements and minimising the costs, can result in a tremendous task. To carry on such a task the QoS (Quality of Service) engineer should consider multiple possible solutions and for each of them evaluate costs and performance. It is clear, therefore, that there exists a serious need for analytical techniques and automatic or semi-automatic tools to support design time decisions. One of the targets of MODAClouds project is to meet that need by developing a module consisting of set of tools integrated into MODAClouds IDE. The tools are designed to interact and cooperate to each other in order to help the user to find a satisfactory configuration for the application at design time. This document introduces the initial version of this module. It is structured in such a way that two different audiences, application users and developers, are addressed. From the point of view of the first kind of users this document is interesting as it presents a handbook of functionalities and a detailed guide for the tool installation and use. The developer, instead, would also be interested in the architectural and technological choices made in the development. Such information is also valuable for the open source community that wants to extend MODAClouds tools. 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/ ] under grant agreement n (MODAClouds).

2 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 Public Final version 1.0, Dated October, 2,

3 Contents 1 Introduction Context and objectives Objectives of the current deliverable and their achievement Structure of the document Overview of the QoS Modelling and Analysis Tools 7 3 SPACE4Cloud: Performance and Costs Assessment Tool Overview of the Features Features implemented in the initial release Improvements with respect to the proof of concept LINE: Fluid performance engine Introduction Features implemented in the initial release Improvements with respect to the proof of concept SLA tool Introduction Architecture Overview of the Features Features implemented in the initial version Filling the gap Batch engine Summary Extensions with respect to Deliverable D Appendices 25 A The MiC use case 25 B QoS Modelling Workflow 27 C QoS tools User Guide 28 C.1 SPACE4Cloud User Guide C.2 LINE User Guide C.3 SLA Core User Guide C.4 SLA Mediator User Guide C.5 Batch Engine User Guide D Developer documentation 60 D.1 SPACE4Cloud Developer Documentation D.2 Optimisation process D.3 Structure of the Input and Output Files D.4 LINE Developer Documentation Public Final Version 1.0, Dated October 2,

4 E Installation instructions 94 E.1 Pre-requisites E.2 Installing and building SPACE4Cloud E.3 Installing LINE E.4 SLA Core Installation Guide E.5 Batch Engine Installation Guide Public Final Version 1.0, Dated October 2,

5 1 Introduction This deliverable describes the prototypical implementation of a set of tools for design time prediction and analysis of cost and performance in the context of cloud application development. 1.1 Context and objectives Cloud Computing is assuming an increasingly important role in the ICT world. It is radically changing the process of designing and developing applications and services. Cloud technologies provide tools to create dynamic systems capable to react to workload fluctuations by adapting themselves in order to keep the general performance unchanged. In this environment the intensive tasks of infrastructure management and maintenance are delegated to the Cloud provider. However, if on one hand Cloud Computing offers many clear advantages, on the other it introduces some important issues and new challenges in application development. In fact, the current range of Cloud technologies and pricing models is very wide and so complex that determining the best cloud solution, which meets the application requirements and minimises costs, may result in a tremendous task. To carry out such a task, the QoS (Quality of Service) engineer should consider multiple architectures and should be able to evaluate costs (that often depends on the application dynamics) and performance for each of them. Moreover, as far as the performance evaluation is concerned one must say that Cloud platforms are usually multi-tenant and their performance can vary greatly with the time of day, according to the congestion level and competition for resources among applications. It is clear, therefore, that there exists a serious need for analytical techniques and automatic or semi-automatic tools to support design time decisions. One of the MODA- Clouds project targets is to meet that need by developing a module exposing a set of tools integrated into MODAClouds IDE. The tools are designed to interact and cooperate in order to help the user, at design time, to find a satisfactory configuration for the application under development. This document introduces initial version of this module, hereinafter referred to as QoS Modelling and Analysis Tool. This document will provide an overview of: Architecture: An important objective is to provide a clear and formal description of the QoS tools architecture. The overall architecture of the module as well as a thorough description of the components of each tool will be provided. Functionalities: Another objective of this document is to detail the aim and the main functionalities of the tools within the tools. We will also present a thorough description of the tools and the way they interact. Interaction with MODAClouds IDE: The presentation of the QoS tools will be completed by providing a complete overview of the relations between the QoS tools and MODAClouds IDE. Installation: This document accompanies the prototype also to describe its installation process. User guide: Finally, the document will present a user support guide for the use of the prototype. 1.2 Objectives of the current deliverable and their achievement In this section we present an objective-achievement summary table. The purpose of the table is to briefly summarise the objectives this document is meant to fulfil and the way, we believe, they are achieved. Furthermore, for each objective, pointers to specific sections of the documents are given. In this way the reader can quickly navigate to the parts of a document s(he) might be interested in. Public Final Version 1.0, Dated October 2,

6 Objectives Obj.1 Develop a MODACloudML package and tools for specifying QoS requirements and constraints at the CPIM level, and estimate the QoS characteristics of applications deployed on multiple clouds at the CPIM and CPSM levels Obj.2 Define and manage the acquisition of runtime QoS information from WP6 by means of a feedback system Achievements This document defines the QoS Modelling and Analysis tool architecture in Section 2. An important effort has been done in order to identify and describe the flow of information between those components(sections 3 B). For performance and cost estimations, SPACE4CLoud and LINE tools are integrated, and currently support the performance analysis and cost minimization of applications deployed in a multiple IaaS environments. Current work focus on the generation of SLA contracts for end users from QoS constraints. The SLA tool is presented in Section 5. The definition of the Filling the GAP/Batch Engine tool architecture and its interactions with other components of MODAClouds platforms has been provided(section 6). The implementation of the tools and their evaluation is on going and due at month Structure of the document The rest of the Deliverable is structured as follows: Section 2 gives an overview of the main features of the QoS Modelling and Analysis Tools. Section 3 provides a detailed introduction to SPACE4Cloud, performance and cost assessment tool, one of the main components of the QoS tools. Section 4 introduces LINE, a fluid performance engine designed to build and solve performance models from a high-lever description of the application. Section 5 provides an introduction to the SLA tool, a component to generate and enforce Service Level Agreements in the context of the MODAClouds project. Section 6 introduces the Filling the Gap (FG) component, in charge of providing runtime information to the design-time tools, as well as to the Cloud App Admin, the QoS Engineer, and the Feasibility Study Engineer, effectively closing the loop between runtime and design time. Appendices will complete the Deliverable: Appendix A describes the MiC use case (see also MODAClouds Deliverable D.5.2.2) that will be used to exemplify the use of the tools. Appendix B details the QoS Modelling Workflow process by means of the Mic use case. Appendix C serves as user guide for the tools. Appendix D provide some documentation for developers. Appendix E reports the instructions to follow for building and installing the tools. Public Final Version 1.0, Dated October 2,

7 2 Overview of the QoS Modelling and Analysis Tools In order to help the reader to deeper understand the scope of the QoS Moodelling and Analysis Tool, we provide herein a brief high-level view of the module object of this deliverable, the QoS Modelling and Analysis tools. Especially, in this section we want to provide an insight into the prototype s architecture. The main elements described herein will be further detailed later on. Figure 1 shows the main actors involved. The Feasibility Study engineer, the Application Developer and the QoS engineer provide the input to our proof of concept module. The Feasibility Study engineer provides a set of suitable providers for the application under design, the application developer instead creates a consistent model of the application and a set of architectural constraints using MODACloudML meta-models. Ultimately the QoS engineer is in charge to define QoS constraints. The tool receives as an input a set of models describing an application both in terms of functionalities and resource demands. More precisely, we have models describing the application by means of components and functionalities, models describing the Cloud environment (with its costs and performance specifications) and models that set up the execution of the QoS Modelling and Analysis tools (e.g. QoS and architectural constraint definition or workload profiles). A complete description of these input models can be found in the MODAClouds Deliverable D The models are used as a starting point for the definition of an initial solution. At this stage of the prototype evolution the construction of the initial solution is carried out by a fully-automated component leveraging an especially designed Mixed Integer Linear Program (MILP) presented in [1]. This initial solution (that can be even infeasible) is evaluated and the performance and costs are assessed. Performance models, namely Layered Queuing Network models (LQN), are needed to derive information about, for example, Response Time and CPU Utilization related to a certain application component. For this reason the solution is turned into a set of LQN models (namely 24, in order to analyse the daily behaviour of both application and Cloud environment) that are analytically evaluated. After that, the solution is checked against the set of QoS constrains to verify the feasibility. Since the aim of the tool is to find an optimised deployment solution that satisfies the constraints and minimises costs, the initial solution is then iteratively improved during the design-space exploration phase. The primary concern behind this process is to drive the current solution toward the feasibility and then optimising it in terms of cost. Eventually, the module returns to the QoS engineer a full configuration (set of providers, type of Virtual Machines (VMs) per tier, number of VMs per hour, number of violated constraints) and a report with useful information about the overall cost and performance. The user at that point may choose to accept the solution as it is or to modify the constraints or to change the deployment and evaluate different configurations. The QoS Modelling and Analysis tool is composed of four main components: SPACE4Cloud has a twofold function. First, by means of the Solution Manager sub-component (see Figure 1), it keeps track of candidate solutions and manage their creation, modification, evaluation, comparison and feasibility check. Second, SPACE4Cloud deals with the design-space exploration and optimisation process. The sub-component, named as Local Search Optimizer, applies iteratively a set of moves belonging to different search neighbourhoods in order to make the current solution to improve with the goal of fulfilling user constraints while minimising the overall costs. LINE is the component in charge of the evaluation of the performance models (LQN) enriched with information about the efficiency and the dynamic behaviour (by means of Random Environment and General Service Times see D5.2.2) that can affect the Cloud platform. Moreover, LINE can also compute Response Time Distributions, which can be directly used to assess service-level objectives defined as percentiles of the response time. LINE offers a parallel execution model for Public Final Version 1.0, Dated October 2,

8 the efficient solution of a large number of performance models. Note that LINE receives as input the performance models derived from every SPACE4Cloud candidate solution. SLA tool 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. On the other hand, the SLA tool must assess business penalties (QoB: Quality of Business) associated with the fulfilment of the non-functional properties already assessed in the Monitoring Platform. Filling the gap tool aims at improving the accuracy of the design-time Quality-of-Service (QoS) models developed in WP5 [2], using the monitoring information collected at runtime through the Batch Engine component. This is done by means of techniques that provide estimates for the value of the QoS model parameters. Currently this component is at an early stage of development and according to MODAClouds Description of Work it will be released at month 30. Public Final Version 1.0, Dated October 2,

9 Feasibility Study Eng. Application Developer Application Provider MODAClouds IDE Decision Making Toolkit (WP2) Functional Modelling Environment (WP4) Data Mapping Component (WP4) CloudML Deployer (WP4) Batch Engine FG Tools Enriched PCM SPACE4Cloud Initial Solution Builder MILP Solver connector MILP solver QoS Eng. Initial solution Cost and Feasibility Evaluator Partial Solution Cache Multi-thread connectors LINE SLA Tool (WP5) Optimized Solution Figure 1: High-level Architecture Public Final Version 1.0, Dated October 2,

10 3 SPACE4Cloud: Performance and Costs Assessment Tool SPACE4Cloud (System PerformAnce and Cost Evaluation on Cloud) is a tool for specification, assessment and optimisation of QoS characteristics for cloud applications. It allows users to describe the architecture of their application by means of Palladio Component Models (PCMs) and to enrich them in order to include cloud specific attributes (see MODAClouds Deliverable D5.2.2). Extended PCMs also include a user defined workload in order to assess both performance and cost of the modelled solution. The tool is built on top of the Palladio Bench modelling environment but it differs significantly from Palladio since it completes the modelling capabilities allowing more expressiveness in the definition of the resource environment and workload specification. In particular, it maps the models onto different instances of PCMs in order to allow the user to perform all the analyses supported by the Palladio Bench tool for a day time horizon. Moreover, it allows users to choose among different performance analysis strategy via LINE, LQNS or the Palladio built-in Simulation engine. Users can specify the models defining the cloud application using an intuitive graphical interface. Information about the performance of the considered cloud resources are kept in a SQL database to decouple its evolution independent from the evolution of the tool itself. The tool can be used to either evaluate the cost of a fully described solution (application and cloud configuration) according to the cost model defined in [3] or to find a suitable (even multi-cloud) configuration that minimises the application running cost while meeting QoS requirements. 3.1 Overview of the Features This section presents the main features of the SPACE4Cloud tool: PCM compliance: The tool is fully PCM compliant, it can parse PCM models and use them in the construction of the optimised solution or help the QoS engineer in further specifying them. Enriched PCM: The tool extend PCM models by including cloud specific features. Enriched models can then be analysed to derive performance metrics. Enriched PCM can be fully or partially specified by the QoS engineer. The tool can work with partially specified models by filling the remaining parts by means of an optimisation search algorithm. Configuration Optimisation: This feature is the heart of the SPACE4Cloud tool. Its main goal is to find a multi-cloud deployment configuration optimised in terms of load balancing among cloud providers, size and number of cloud resources, minimising costs and fulfilling QoS constraints. The optimisation process leverages the cost evaluation capability in order to have an accurate estimate of the cost of each generated solution. It also integrates with LINE analysis tool for a more accurate performance estimation. The space of possible solutions is defined by the user s constraints at both architectural and QoS levels. State of the art techniques are exploited for the exploration of the search space in order to find optimised solutions to the resource provisioning problem. Multi-Cloud Support: The tool supports multi-cloud deployment of the modelled application. The application is entirely replicated among different cloud providers. The tool creates a replica of the model for each provider belonging to a user defined set and adds a virtual load balancer to distribute requests among them. The load balancing on a 24 hour horizon is also part of the configuration optimisation process. Automated building of the initial solution: An initial valid configuration of the system can be derived automatically by the tool starting from a partially specified application description given by the QoS engineer. In order to do so, a mixed integer linear model is built and fast solved. This solution is based on approximated performance models and it goes through a further refinement by the optimisation module that exploits much more expressive and realistic models for the solution Public Final Version 1.0, Dated October 2,

11 performance evaluation. A biased good initial solution generated in this way has the positive effect to both accelerate the optimisation process and to improve the final solution. Charting and reporting The feedback to the user is implemented by using charts of the most meaningful parameters of the solution under investigation. Particularly, charts will report the cost of the solution, response time of each component and average utilisation of cloud resources. A visual feedback of the evolution of the solution optimisation is given to the user so that it can decide when to stop the evolution of the optimised configuration. Finally, the tool is capable of exporting the deployment solution derived automatically by the optimisation algorithm or by the QoS engineer in a model that is compliant with MODACloudML. This feature enables other tools in the MODAClouds framework to take advantage of the results of the assessment and optimisation phase. 3.2 Features implemented in the initial release The proof of concept currently implements a subset of the functionalities reported above. Moreover even if the prototype has been developed to support PaaS, IaaS and hybrid solutions only IaaS support can be considered complete at the moment of this deliverable. However, within this initial release an user will find as early feature the possibility to consider and analyse the Cloud Bursting scenario. This deliverable refers to version tagged as D5.4.2, the tag is available both on the update site used to install the tool and the source repositories. PCM compliance: SPACE4Cloud is fully PCM compliant. It can use PCM models as starting point for its execution, it is capable of processing them and use them in the construction of different run configurations. This compatibility allows the QoS engineer to use other features of Palladio (e.g. the simulation engine). Enriched PCM: This feature allows users to embed cloud specific aspects in the design of their application. Palladio Component Model does not offer sufficient modelling constructs to address the wide variety of cloud resources that are available in a Cloud environment. In particular this limitation is stronger in the definition of the resource environment. SPACE4Cloud allows users to define a complete PCM by using the Server concept of Palladio as a container of cloud resources. This container can then be further specified in order to model both IaaS and PaaS resources both at CPIM (using a generic cloud provider) and CPSM (using specific cloud resources) levels. The modelling capability of Palladio have been also extended by allowing users to specify variations of the workload, in terms of population and think time, for a 24 hours period. The extended solution is composed by 24 hourly solutions. Each solution contains the representation of the whole application. SPACE4Cloud gathers this information by asking the QoS Engineer about the preferred cloud resource and gathering performance specification from a database. The result of this modelling phase is a set of 24 PCM models that can be used for simulation. Cost Evaluation: The cost evaluation functionality is an implementation of the cost model presented in the MODAClouds Deliverable D It permits accurate estimation of the resources usage cost of a deployment solution. This functionality supports the cost analysis of multi-cloud configuration composed of both IaaS and PaaS resources. It takes into account the use of the entire application under the specified working conditions for the whole 24 hour period. Details about the cost of using each cloud resource and the overall cost of the solutions are calculated and reported to the user. The cost evaluation functionality is also used internally for the optimisation process. Automated building of the initial solution: A Mixed Integer Linear model is built from the extended PCMs and solved by means of an third-party MILP solver (currently commercial solvers as Cplex and Gurobi as well as open source projects as CBC and GLPK are supported). The model presented Public Final Version 1.0, Dated October 2,

12 in [1] has been proven to be solvable in time compatible with the work of the QoS engineer and to significantly improve the final optimised solution; however, currently the model only supports IaaS cloud resources. Multi-cloud support and configuration optimisation: The optimisation process is fully implemented and it is working both for single and multi-cloud IaaS (either public and hybrid) environments. The user can specify a list of candidate providers or a maximum/minimum number of them to be considered for the optimisation process. Other constraints as the minimum load percentage to be redirect to a certain provider or the minimum amount of memory for the VMs to consider can be expressed as well. The optimised solution contains for each hour of the day the workload redirected to each provider, the type and number of VMs for each tier and each provider along with the overall cost and information about performance, including average and percentile response time and utilization. Charting and reporting: This feature has been implemented only partially. Some examples of charts are reported in Figures 12 in Appendix C. The charts report the costs associated with the current best and candidate solutions and for each provider the number of VMs and number of violated constraints. 3.3 Improvements with respect to the proof of concept SPACE4Cloud component has to be considered stable. As far as IaaS environments (either public and hybrid) are concerned the module is capable of efficiently exploring the design space and finding an optimised multi-cloud deployment configuration that minimises costs and fulfils QoS and Architectural Requirements. The high-level architecture of the module along with its I/O relations with MODAClouds IDE has been updated while the now available multi-cloud optimisation feature can be considered fully mature. Public Final Version 1.0, Dated October 2,

13 4 LINE: Fluid performance engine 4.1 Introduction LINE is a tool for the performance analysis of cloud applications. LINE has been designed to automatically build and solve performance models from high-level descriptions of the application. This description is assumed to be available as a Palladio Component Model (PCM), which provides a complete picture of the application, including its architecture, deployment characteristics, and usage. From this description, LINE is able to provide accurate estimates of relevant performance measures such as application response time or server utilisation. LINE can also provide response times for specific components of the application, enabling the pinpointing of components causing a degradation in the quality-of-service (QoS). LINE can therefore be used at design time to diagnose whether the deployment characteristics are adequate to attain the desired QoS levels. Although other tools are available for performance modelling (such as LQNS and SimuCom), LINE stands apart for a number of reasons. 1. LINE can be directly integrated with the Palladio Bench tool, which allows the direct assessment of applications modelled as a PCM. 2. In addition to provide average performance measures, LINE has been designed to compute response time distributions, which can be directly used to assess percentile Service Level Agreements (SLAs). 3. LINE features a reliability model to capture a number of conditions that may affect the application, including servers breakdowns and repairs, slow start-up times, and multi-tenancy, a key property of cloud deployments. 4. LINE is able to model general request processing times, which can be used to represent the resource demands posed by the very broad range of cloud applications. In the next sections we describe in more detail the main features of LINE. The underlying performance models are described in [4]. 4.2 Features implemented in the initial release The proof of concept of LINE already implements a number of features, which we now describe in more detail. Automated Performance Modelling: The Palladio Bench tool provides the PCM2LQN transformation [5], which translates a PCM instance into a Layered Queueing Network (LQN) model [6]. LINE is able to parse the LQN description obtained from the PCM2LQN transformation, to build the underlying performance model without additional information. After building the model, LINE solves it using state-of-the-art techniques, and provides the performance measures in a convenient format. The complete transformation from the PCM instance to the underlying performance model and its solution is therefore completely automated. This facilitates the performance assessment, requiring no additional information than what is included in the PCM instance. Architectural Description: As described above, the performance model underlying LINE is defined from the PCM instance through model transformations, translating the PCM model into the LQN model and that into the LINE performance model. This process is performed so as to guarantee that the application architectural details are captured by the LINE performance model. In this manner, the application developer can assess the effect of different architectural options on the QoS perceived by the users, and on the SLAs compliance at design time. This assessment needs no other information than the description of the architectural change as provided in the Palladio Bench tool. Public Final Version 1.0, Dated October 2,

14 Multi-class Workload: A cloud application typically provides a number of services, each of them posing possibly very different demands on the cloud resources. LINE is able to capture this variety by describing workloads made of a number of different request classes. The LINE performance model has been designed to allow a very large number of classes, overcoming the limitations of traditional performance models. This allows a very accurate description of the workload faced by the application, which leads to better performance predictions. Random Environments: Software applications encounter a number of challenges in Cloud deployments that are not present in traditional environments. For instance, the use of virtualised resources results in multi-tenant conditions, where a cloud application is deployed on the same hardware as another application, a situation that may affect the QoS perceived by the users, but that is beyond the control of the application administrator. This and other characteristics of cloud deployments are captured in LINE by means of random environments. In addition to multi-tenancy, LINE also makes use of random environments to describe three other features: i) start-up times, that delay the usability of new instances when these are launched to, for instance, scale out capacity under an increasing load; ii) resource heterogeneity, that causes an application instance to be deployed on hardware with very different characteristics, due to the varied hardware made available by the cloud provider; iii) resource failures, which describe how the underlying hardware or software stack may fail, affecting the application performance. General Processing Times The demand posed by the application requests on software and hardware resources can be very different for different applications and even for different services within the same application. LINE provides tools to handle very diverse behaviours of the service demands, improving upon standard models that limit the characteristics of these demands. LINE has been designed to incorporate this information with little effort from the application developer, reducing the specification of the more general models to metrics available to the developer, or easily obtainable from monitoring data. Long-run Performance Measures LINE provides, by solving the underlying performance model, longrun, or stationary, performance measures. These measures include the long-run average response time and throughput of the services provided by the application, as well as those of its components. These also include the utilisation of the underlying hardware where the application is deployed. These measures can be used directly to compare the predicted performance against the desired one, and how changes in the deployment characteristics or in the architecture of the application can affect the performance. Since the performance measures can be computed for both the overall application as well as for the components, it is possible for the QoS Engineer to identify bottlenecks among the application components, as well as to determine changes in the deployment to improve the performance of specific components. Response Time Distribution Many traditional performance models focus on average measures, such as mean response time or mean throughput. SLAs, however, are usually defined as a percentile, e.g., that 90% of the requests be completed in at most 100ms. Since these percentile SLAs cannot be assessed with an average measure, LINE has been designed to compute the application response time distribution, and not only its average. The distribution provides for every level x, the percentage of requests that receive a response time of at most x time units. This is exactly the information required to assess percentile SLA compliance, and allows LINE to accurately evaluate whether the characteristics of the deployment are sufficient to attain a certain QoS level or not. Parallel Execution Starting with version 0.5, LINE operates as a server, which, after being initialized, can accept connections from clients that submit models for solution. In addition to simply solving the models sequentially, LINE offers the following two configuration modes to solve many models in parallel: Public Final Version 1.0, Dated October 2,

15 The first mode exploits the parfor mechanism in Matlab to execute several workers in parallel, each of which can solve several models sequentially. The second mode operates as a batch engine, packing a set of models into a parallel job, which is executed in the local cluster. This feature offers significant reductions in execution times, especially when solving a large number of models. This is particularly relevant for resource provisioning problems based on optimization routines. 4.3 Improvements with respect to the proof of concept The main new features introduced in this initial version, not part of the previous proof of concept are: - LINE now provides reliability-modelling capabilities, by means of the random environment abstraction. This allows the modelling and analysis of external effects that affect the application reliability, such as multi-tenancy in Cloud deployments, or failures and start-up times of Virtual Machines. - LINE now computes the response time distribution in addition to the mean response time. This enables the evaluation of Service-Level Objectives (SLOs) defined as percentiles, e.g., 90% of the requests must be processed in at most 300 ms. - LINE now supports general request processing times, extending LQN models, which support exponential distributions only. With this feature it is possible to capture the different processing times offered by different Cloud applications, which may also depend on the underlying infrastructure and the virtualization layer. - LINE now provides a parallel execution option, enabling the efficient solution of several application models, which can be critical when exploring many different application configurations, and for optimization purposes, as performed by the SPACE4Cloud tools. - The automated transformation in LINE from LQN models has been improved to consider more general cases, including multiple Usage Scenarios and general probabilistic activity graphs at the Usage Model level. Public Final Version 1.0, Dated October 2,

16 5 SLA tool 5.1 Introduction In the MODAClouds context, Cloud Service Providers charge Application Providers (APs) for renting cloud resources to host added value features provided by MODAClouds platform to design (model) and govern (deploy and manage at runtime) their applications. APs may charge their Customers for processing their workloads (e.g., in Software-as-a-Service fashion) or may process the user s requests for free (cloud-hosted business application). In both cases, Application Providers need to guarantee their customers SLA. In both circumstances penalty-based policies are applied. Moreover, SLA violations have also an implication on SaaS reputation and revenue loss incurred in the case of cloud-hosted business applications. In this scenario there are three parties to take into account: Cloud Service Providers (CSPs): 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 (IaaS) and Platform-as-a-service (PaaS) providers. Examples are: Amazon, Microsoft (AZURE), Google (APP-Engine), Rackspace, CloudBees, etc. Application Providers (APs): They represent the cloud-hosted software applications that employ 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 platform. Customers (End Users): They represent the legitimate users for the services (applications) that are offered by the application providers. In practice, we can consider that the resource management and SLA guarantees can fall into two separate layers, one related to the Cloud Service Provider and the other to the Application Provider: The Cloud Service Provider is responsible for the efficient utilization of the physical resources and guarantees their availability for the customers. Application Providers are responsible for the efficient utilization of their allocated resources in order to satisfy the SLA established with their customers (end users) and achieve their business goals. Figure 2 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 a Service Level Agreement can be split up in several different phases: 1. preparation of the service offer as a template, 2. location and mediation of the agreement, 3. service provisioning and business application deployment, 4. assessment of the agreement during execution (this is a parallel phase to the service execution), and 5. termination and decommission of the agreement. Within the MODAClouds project we design and implement a policy-driven SLA framework that focus on the phase 1-4 of the described lifecycle. Public Final Version 1.0, Dated October 2,

17 Figure 2: Customer/Application Provider SLA relationship 5.2 Architecture The SLA Tool comprises a REST server (the SLA core), where main features are implemented, and a set of additional helper tools (the SLA Mediator). The Mediator tool is a set of tools that act as a layer on top of the core, to add some MODAClouds specific behaviour. The implemented code is divided into two Open Source projects: modaclouds-sla-core modaclouds-sla-mediator Figure 3 shows how the SLA Components are organized and how they are related to other MODA- Clouds 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 relying on the SLA Template provided by the Cloud Offerings. Monitoring Platform: the MODAClouds Monitoring Platform is in charge to detect the QoS violations and notify the Assessment component. Assessment: computes the possible business violations, notifying any observer (like an Accounting component) of raised penalties. The MODAClouds IDE starts the SLA generation process. The Business Violation GUI shows the final user the violations and penalties in a friendly way. Public Final Version 1.0, Dated October 2,

18 Figure 3: SLA tool: Architecture 5.3 Overview of the Features This section presents the main features of the SLA tool: WS-Agreement compliance. The tool follows, in its implementation, the concepts and XML structure for agreements and templates that are defined in the WS-Agreement [7] specification. In this specification, a template describe a service offer, and an agreement describes an instantiation of a template associated to a particular customer. Two layers of SLA are considered: the Customer-Application Provider SLA, and the Application Provider - Cloud Provider SLA. The former layer describes the service and its QoS from the point of view of the end user. The latter one describes the service and resources offered by the Cloud Provider to the Application Provider. One shot negotiation. A simple negotiation (as described in [7]), where a Service Provider automatically accepts a Customer offer, is implemented. The development of a real negotiation process is outside the scope of the SLA tool. Renegotiation is the process in which a new agreement is issued when the offered service changes, or when the violations of the agreement by the provider impose a new agreement. External Smart Monitoring Platform. The SLA tool relies on the MODAClouds Monitoring Platform, that evaluates the QoS constraints and communicate the violations to the SLA tool. Quality of Business rules. The tool will enforce the QoB rules defined in the agreements. The QoB rules rely on QoS rules to create complex metrics focused on business accounting. Graphical User Interface. The tool will have a GUI to check the status of the agreements, emphasising in the information of violations and associated penalties, in order to analyse the general behaviour of different providers. Public Final Version 1.0, Dated October 2,

19 5.4 Features implemented in the initial version The proof of concept currently implements a subset of the functionalities reported above: WS-Agreement compliance. The tool has been built from scratch based on the foundations of WS-Agreement. One-shot negotiation. Customer - Application Provider SLA. Currently, only the templates and agreements of the C- AP SLA are generated and enforced. Simple QoB rules. A single QoS violation implies a QoB violation. REST interface. The tool exposes a REST interface that may be currently used to extract the information related to agreements status and their violations. Public Final Version 1.0, Dated October 2,

20 6 Filling the gap The Filling the Gap (FG) component [8] is in charge of providing runtime information to the designtime tools, as well as to the Cloud App Admin, the QoS Engineer, and the Feasibility Study Engineer, effectively closing the loop between runtime and design time. The FG component has therefore two main objectives. 1. The first objective is to improve the accuracy of the design-time Quality-of-Service (QoS) models developed in WP5 [2], using the monitoring information collected at runtime. This is done by means of techniques that provide estimates for the value of the QoS model parameters. This is similar to the estimation performed by the Statistical Data Analyzers (SDAs) at runtime, as part of the monitoring platform [9]. However, the SDAs are light-weight methods that use a limited number of samples to rapidly produce estimates, which are then used to support online adaptations decisions [10]. Instead, the FG techniques have the flexibility of being executed offline, and can therefore be more computationally intensive and make use of the extensive datasets collected at runtime, with the aim of producing more accurate results. The procedure of executing the estimation routines aiming at improving the accuracy of the QoS models is referred to as FG Analysis. 2. The second objective of the FG component is to provide the user with a view of the actual behavior of the application at runtime. The expected users of this information are the Cloud App Admin, the QoS Engineer, and the Feasibility Study Engineer. Relevant information includes, among others, the application compliance with the SLAs, the effective QoS offered, and the deployment cost. This information is collected at runtime and stored for later analysis through the FG component. Based on these results, the user can make informed decisions regarding the characteristics of the deployment, improving the QoS or reducing the incurred cost. To fulfill these objectives, the MODAClouds FG component relies on a Batch Engine, which provides the computational resources to support the execution of the FG component. 6.1 Batch engine The main goal of the Batch Engine (BE) is to support the computationally-intensive routines that will be executed as part of the FG Analysis. Since these routines are executed offline, it is not necessary to comply with tight deadlines, and it is therefore possible to exploit the large datasets of monitoring information collected at runtime. We therefore opt for a BE that exploits a pool of parallel resources. In particular, the BE aims to provide on demand HTC/HPC clusters on top of existing computational cloud resources (e.g., Eucalyptus, EC2, Flexiant, PTC, etc). From a technical perspective, the BE will integrate the services provided by the QosCosGrid[11] Compute Middleware, services that are built on top of automatically-provisioned LoadLeveler, Condor or PBS clusters. The BE exposes REST APIs allowing the control of the deployment, monitoring, as well as capabilities for job management. The APIs offered by the BE are separated in two main APIs, which together provide a complete abstraction of the intricacies of both the cluster deployment and the interaction with the various job-scheduling engines. Internally the BE will provide extension points allowing the addition of new HPC/HTC capabilities (e.g., job schedulers, middleware, etc). As the FG analysis techniques will be implemented in Matlab, we will make use of the Parallel Toolbox and the APIs offered by the BE to submit and manage the parallel jobs, as well as to retrieve the results. The execution of the FG analysis will rely on the Matlab Compiler Runtime (MCR), which is a royalty-free runtime platform to execute standalone applications developed in Matlab. From an architectural point of view the BE is composed of five main subsystems (see Figure 4): Batch Engine API: This subsystem is responsible for interacting with the client applications or users. It handles the requests and delegates them to the other subsystems. Public Final Version 1.0, Dated October 2,

21 Batch Engine Cluster Manager: Uses the Configuration Management subsystem (mainly Puppet) and the cloud interface for deploying nodes and provisioning the job scheduler (e.g., Condor). It also handles the QosCosGrid Middleware deployment on designated nodes. Configuration Management: Is responsible for the effective installation, configuration and integration of the various components used, ranging from basic virtual machine provisioning to LoadLeveler and QosCosGrid configuration. QosCosGrid: Handles the interface with the underlying subsystems, specifically the scheduling subsystem, abstracting its specific API. Scheduler: Represents the effective job-scheduling system, responsible for executing the submitted jobs. User Batch Engine API Manage Cluster Manage Jobs <uses> <uses> <uses> <uses> <uses> Cluster Manager QCG Create Cluster Destroy Cluster Terminate Job Create Job Monitor Job <uses> <uses> <extends> <extends> <extends> Configuration Management (Puppet) Condor Deploy QCG Deploy Condor Kill Job Run Job Monitor Job Figure 4: Batch Engine Base Architecture The Batch Engine user guide is provided in Appendix C.5. Additional details on the FG component can be found in [8]. Public Final Version 1.0, Dated October 2,

22 7 Summary This deliverable presented the first release of QoS Modelling and Analysis Tools, the set of components of MODAClouds IDE aimed at providing a mechanism for design time exploration and optimisation (Cost reduction while fulfilling performance constraints) of multi-cloud applications. This document is structured in such a way that two different audiences, application users and developers, are addressed. From the point of view of the first category of users this document is interesting as it presents an handbook of functionalities and a detailed guide for the prototype installation and use. The developer, instead, would also be interested in the architectural and technological choices made in the development of this MODAClouds IDE component. The presented proof of concept is made out of four main tools: SPACE4Cloud, LINE, SLA tool and Filling the gap tool. We reported individual sections where they are described in detail, in terms of prerequisite and expected and actually implemented features. A general section with the overall architecture of the prototype is also provided. Being an intermediate release, some features can be considered complete and stable while others are still work-in-progress and in particular, as far as SPACE4Cloud tool is concerned, future work will focus mainly on extending the applicability of the tool to PaaS solutions. Moreover, we will try to reduce or even eliminate the need to expose to the QoS Engineer Palladio Component Models, with the aim to perform modelling activities only with MODACloudML concepts. Regarding LINE, its development will continue to support the computation of response time distributions at two levels of granularity: workload and services. We will also setup and conduct a number of tests to evaluate the performance and accuracy of LINE. The LINE models will make use of the Filling the Gap component to update the model parameters, evaluating the application at hand under different conditions. The next step in the SLA tool is the development of complex Quality of Business metrics, both in the design side and the runtime side, including an interface to consult the applied penalties. Also, the Application Provider - Cloud Provider SLA will be developed. Finally, the renegotiation functionality will cover any change in the terms of a service. Filling the gap tools are under development and will be released at M30. This document has introduced the initial version of the Batch Engine which will provide the computing architecture for performing filling the gap analyses. 7.1 Extensions with respect to Deliverable D5.4.1 In this intermediate deliverable, that is meant to go with the prototype of QoS Modelling and Analysis tool, almost every section has been updated with respect to Deliverable In particular, some architectural choices have been revised as some sub-components of the module (namely SPACE4Cloud and LINE), achieved a higher maturity level whereas others appear here in preview. As a consequence some parts, that were already well-defined in the previous version of the document, have been only slightly modified, some others have been better detailed, while other components are presented in this deliverable for the first time. There is still some ongoing work within of each tool but the overall architecture and the flow of information has to be considered stable. In what follows the reader will find listed the major updates made with respect to the previous version of the architecture. SPACE4Cloud presented in Section 3 has to be considered stable. As far as IaaS environment are concerned the module is capable of efficiently exploring the design space and finding an optimised multi-cloud deployment configuration that minimises costs and fulfils QoS and Architectural Requirements. The high-level architecture of the module along with its I/O relations with MODA- Clouds IDE has been updated while the now available multi-cloud optimisation process has been highlighted in the description of the module. Public Final Version 1.0, Dated October 2,