D Self-managed Cloud runtime prototype

Transcription

1 Project Acronym: OPTIMIS Project Title: Project Number: Optimized Infrastructure Services Instrument: Thematic Priority: Integrated Project ICT Internet of Services, Software and Virtualisation D Self-managed Cloud runtime prototype Activity 4: WP 4.2: Basic Service Operation Cloud Runtime Optimization Due Date: M17 Submission Date: 01/10/2011 Start Date of Project: 01/06/2010 Duration of Project: 36 months Organisation Responsible for the Deliverable: BSC Version: 2.0 Status Final (Resubmission) Author(s): J. Oriol Fitó J. Guitart George Kousiouris Roland Kübert Gregory Katsaros Tinghe Wang Daniel Henriksson BSC BSC NTUA HLRS HLRS HLRS UMU

2 Reviewer(s) Ahmed Aleyeldin Juan Luis Prieto Francisco Javier Nieto PramodS. Pawar Wolfgang Ziegler Craig Sheridan UMU ATOS ATOS CITY SCAI FLEX

3 Project co-funded by the European Commission within the Seventh Framework Programme Dissemination Level PU Public X PP Restricted to other programme participants (including the Commission) RE Restricted to a group specified by the consortium (including the Commission) CO Confidential, only for members of the consortium (including the Commission) OPTIMIS Consortium Page 2 of 39

4 Version History Version Date Comments, Changes, Status Authors, contributors, reviewers /05/11 First draft J. Oriol Fitó, J.Guitart (BSC), G. Kousiouris (NTUA), R. Kübert, G. Katsaros, T. Wang (HLRS), F.J. Nieto (ATOS), D. Henriksson, A. Aleyeldin(UMU), J. L. Prieto, F. J. Nieto (ATOS), P. S. Pawar (CITY) /05/11 Reviewed version W. Ziegler (SCAI) /05/11 Final version J. Oriol Fitó, J. Guitart (BSC) /09/11 First draft for resubmission J. Oriol Fitó, J. Guitart (BSC) /09/11 Final version for resubmission J. Oriol Fitó, J. Guitart (BSC) /10/11 Overall revision Malena Donato (ATOS) OPTIMIS Consortium Page 3 of 39

5 Table of Contents 1 EXECUTIVE SUMMARY INTRODUCTION PURPOSE GLOSSARY OF ACRONYMS CLOUD OPTIMIZER INTRODUCTION TO CLOUD OPTIMIZER Functions Features FEATURES AND FUNCTIONS IN THIS RELEASE RESTful interfaces Deployment andundeployment of Cloud services Add / remove VMs to services Restart VMs of services Maintenance of owned database FEATURES AND FUNCTIONS TO BE AVAILABLE IN THE NEXT RELEASES Integrated policy management in a self-managed Cloud runtime Remote deployment Configure IP-level components according to BLOs KNOWN LIMITATIONS Placement decision GETTING STARTED Software Dependencies Platforms Supported Installation Instructions Using the Software Testing the Software OTHER INFORMATION Source Code Information Directory Structure Contributors VM MANAGER INTRODUCTION TO VM MANAGER Functions Features FEATURES AND FUNCTIONS IN THIS RELEASE RESTful interfaces Create Virtual Machines Remove Virtual Machines Download VM images from distributed repository FEATURES AND FUNCTIONS TO BE AVAILABLE IN THE NEXT RELEASES Optimization of VMs placement during their deployment and operation Configurable through policies Update rules KNOWN LIMITATIONS OCCI specification GETTING STARTED Software Dependencies Platforms Supported Installation Instructions Using the Software Testing the Software OPTIMIS Consortium Page 4 of 39

6 4.6 OTHER INFORMATION Source Code Information Directory Structure Contributors FAULT TOLERANCE ENGINE INTRODUCTION TO FAULT TOLERANCE ENGINE Functions Features FEATURES AND FUNCTIONS IN THIS RELEASE RESTful interfaces Services monitoring Detection of virtual resources failures FEATURES AND FUNCTIONS TO BE AVAILABLE IN THE NEXT RELEASES Detection of physical resources failures Improving detection of resources failures Configurable through policies Update rules GETTING STARTED Software Dependencies Platforms Supported Installation Instructions Using the Software OTHER INFORMATION Source Code Information Directory Structure Contributors ELASTICITY ENGINE INTRODUCTION TO ELASTICITY ENGINE Functions Features FEATURES AND FUNCTIONS IN THIS RELEASE Reactive Elasticity Controller: KPI Based Elasticity FEATURES AND FUNCTIONS TO BE AVAILABLE IN THE NEXT RELEASES Proactive Elasticity control Vertical Elasticity KNOWN LIMITATIONS Elasticity Rule Format Single Type of Measurements Considering Time Periods GETTING STARTED Software Dependencies Platforms Supported Installation Instructions Using the Software Testing the Software OTHER INFORMATION Contributors SERVICE MANAGER INTRODUCTION TO SERVICE MANAGER Functions Features FEATURES AND FUNCTIONS IN THIS RELEASE Service management OPTIMIS Consortium Page 5 of 39

7 7.2.2 Infrastructure provider management FEATURES AND FUNCTIONS TO BE AVAILABLE IN THE NEXT RELEASES Database backend KNOWN LIMITATIONS Non-persistent data storage GETTING STARTED Software Dependencies Platforms Supported Installation Instructions Using the Software Testing the Software OTHER INFORMATION Source Code Information Directory Structure Contributors DATA MANAGER ECO-EFFICIENCY ASSESSMENT TOOL INTRODUCTION TO ECO-EFFICIENCY ASSESSMENT TOOL Functions Features FEATURES AND FUNCTIONS IN THIS RELEASE RESTful interfaces Basic eco-efficiency assessments and predictions FEATURES AND FUNCTIONS TO BE AVAILABLE IN THE NEXT RELEASES Accurate eco-efficient assessments and predictions KNOWN LIMITATIONS Energy consumption data is unavailable GETTING STARTED Software Dependencies Platforms Supported Installation Instructions Using the Software Testing the Software OTHER INFORMATION Source Code Information Directory Structure Contributors TRUST ASSESSMENT TOOL INTRODUCTION TO TRUST ASSESSMENT TOOL Functions Features FEATURES AND FUNCTIONS IN THIS RELEASE Integration with Monitoring Trust Calculation with Monitoring and SLAs Compliance with Manifest Files FEATURES AND FUNCTIONS TO BE AVAILABLE IN THE NEXT RELEASES Trust Calculation with Social Networking More Parameters for Current Calculations Integration with more Tools KNOWN LIMITATIONS Number of Parameters Used Integration with Real SLAs Simple Manifest Files GETTING STARTED OPTIMIS Consortium Page 6 of 39

8 10.6 OTHER INFORMATION Contributors RISK AND COST ASSESSMENT TOOLS REFERENCES ANNEX A. LICENSE CONDITIONS Index of Tables Table 1Cloud Optimizer software dependencies...13 Table 2VM Manager software dependencies...16 Table 3Fault Tolerance Engine software dependencies...19 Table 4Elasticity Engine software dependencies...22 Table 5 Eco-efficiency Assessment Tool software dependencies...30 OPTIMIS Consortium Page 7 of 39

9 Executive Summary This is a companion document of the software deliverable D of WP4.2. In the subsequent sections, information such as features, known limitations, instructions on how to get started, etc. is provided for each component comprising the self-managed Cloud runtime for the private Cloud scenario. Finally, the license information for the overall deliverable can be found in Annex A. OPTIMIS Consortium Page 8 of 39

10 1 Introduction This document introduces the software deliverable D Self-managed Cloud runtime prototype for WP4.2. The aim of WP4.2 is delivering a Cloud middleware that implements self-management and security capabilities in order to deal with Cloud complexity (e.g. variable workloads along time, resource failures, etc.) and allow quick adaptation to sudden environment changes. This adaptation will be carried out by dynamically provisioning the Cloud internal resources to the services depending on the agreed QoS while optimizing resource usage according to the provider s interests (a.k.a. business model). As the first year s result of Tasks 4.2.1, 4.2.2, , 4.2.4, 4.2.5, and 4.2.7, this deliverable D Self-managed Cloud runtime initial prototype describes the design and implementation of the private Cloud operation. The deliverable D Self-managed Cloud runtime prototype includes the following components: - Cloud Optimizer - VM Manager - Service Manager - Data Manager - Fault Tolerance Engine - Elasticity Engine - Eco-efficiency Assessment Tool - Risk Assessment Tool - Trust Assessment Tool - Cost Assessment Tool The license information can be found in Annex A. 1.1 Purpose The purpose of this document is: - to introduce the components included in this deliverable - to describe the features and functions available in this release and future releases - to describe the known limitations - to provide information on how to get started (software dependencies, hardware requirements and platforms supported, installation instructions, using the software, etc..) - to share the license information. OPTIMIS Consortium Page 9 of 39

11 1.2 Glossary of Acronyms Acronym BLO D DRS EC IP JAR OCCI OPTIMIS OVF PM PO REST SP TREC VM WAR WP Definition Business-Level Objective Deliverable Document Review Sheet European Commission Infrastructure Provider Java ARchive Open Cloud Computing Interface Optimized Infrastructure Services Open Virtualization Format Project Manager Project Officer Representational State Transfer Service Provider Trust, Risk, Eco-efficiency and Cost Virtual Machine Web Application archive Work Package OPTIMIS Consortium Page 10 of 39

12 2 Cloud Optimizer 2.1 Introduction to Cloud Optimizer The Cloud Optimizer is part of the OPTIMIS toolkit for Infrastructure Providers (IPs). It combines the monitoring and assessment tools in the OPTIMIS Base Toolkit with various management engines in order to create a self-managed Cloud infrastructure driven by provider s business-level objectives (i.e. BLOs). The detailed design of this component can be found at [1] (Section 11) Functions In particular to the implication of this component during services lifecycle, it exposes the IP external interfaces needed to deploy and undeploy services (i.e. a set of VMs). These operations can be requested by Service Providers, as well as by IPs in the Cloud bursting scenario. In addition, it offers the possibility to add, remove and restart services VMs during their operation. It should be noted that these operations can be requested by Elasticity Engine and Fault Tolerance Engine. Besides, it is responsible of maintaining a database containing all the information regarding physical and virtual resources ofa Cloud infrastructure Features The key features of this component are the following: Is able to deploy / undeploy services composed by several VMs Offers the possibility to add, remove, and restart VMs associated to a particular service already deployed and operating in a Cloud infrastructure Maintains the physical and virtual resources in a database o Offers the needed operations to that end: add, get, update, and delete Provides the number of VM instances running in the physical infrastructure, as well as identifier and hostname of such VMs. 2.2 Features and Functions in this release This release implements these new features and functionality: RESTful interfaces The RESTful interfaces are available needed by other OPTIMIS components, as well as the Java clients developed to make the use of those interfaces easier Deployment and undeployment of Cloud services The Cloud Optimizer serves as the entry point for Infrastructure Providers to deploy and undeploy services. On the one hand, for the deployment of services, it receives the service manifest and extracts its OVF. Thereafter, it splits such OVF in order to obtain the description of each service VM (i.e. the VirtualSystem tag). At the end, those VirtualSystems are the entities used to really create VMs. The Cloud Optimizer makes as many calls to the VM Manager as the number of VMs composing the service in question. Once the deployment has been successfully done, it notifies (1) the Service Manager to update the service resource; (2) the Monitoring Manager to start OPTIMIS Consortium Page 11 of 39

13 monitoring service's VMs; and (3) the Elasticity and Fault Tolerance Engines to start service monitoring. On the other hand, for the undeployment of services, the Cloud Optimizer receives the identifier of the service. Then, it requests to the Service Manager the identifiers of VMs belonging to such service. Once known which VMs are to be undeployed, the Cloud Optimizer contacts with the VM Manager in order to remove such virtual resources. Later on, once the undeployment is done, it deletes the service resource, stops the monitoring of service s VMs, and notifies both OPTIMIS engines Add / remove VMs to services In a similar way as the previous functionality, the Cloud Optimizer offers the RESTful interfaces to add and remove VMs to already running services. These operations are performed as the result of elasticity enactment. Regarding the add operation, it also receives the manifest representing the service owner of the VM, and extracts from it the VM description to be sent to the VM Manager. For removing a VM, it receives the identifier of the VM Restart VMs of services The Cloud Optimizer also provides an interface that allows the Fault Tolerance Engine to request a restart of a recently failed VM or physical node. Once such request is received, it communicates the VM Manager to apply the needed virtualization-level actions. Finally, the service resource is updated according to the changes made Maintenance of owned database The Cloud Optimizer is responsible of maintaining a mysql database containing all the needed information about the Cloud infrastructure resources, either physical or virtual. That information is stored in two different tables. It also provides the RESTful interfaces to create, update, get, and delete database entries. 2.3 Features and Functions to be available in the next releases Future releases will implement these new features and functionality: Integrated policy management in a self-managed Cloud runtime Cloud Optimizer will include a policy management framework for resource provisioning and data placement in a Cloud infrastructure that incorporates the provider s Business Level Objectives (BLO) to the decision process, in addition to the traditional parameters. In a Cloud infrastructure different objectives could be desirable for its decisions, such revenue maximization, energy efficiency, reputation maximization, risk minimization, or combinations of these. In order to accomplish this, decision policies for finding the optimal provisioning/placement given the actual status and the forecasted expectations will take into account several parameters. This includes the traditional ones, namely performance, reliability, SLAs, and infrastructure usage, but also business-level parameters such as costs, risk, trust, and energy consumption (i.e. sustainability), in order to take decisions that consider all of them in a synergistic fashion depending on provider s interests Remote deployment Upon a request to deploy a service or to add a new VM to an already running service, the Cloud Optimizer will be able to decide if deploying it in the local infrastructure or in a remote OPTIMIS Consortium Page 12 of 39

14 one. The decision will depend on the current status of the infrastructure, as well as provider s BLOs and TREC assessments Configure IP-level components according to BLOs The Cloud Optimizer will be capable of configuring and adjusting all the IP-level management components, i.e. VM Manager, Data Manager, Elasticity Engine, Fault Tolerance Engine, and Admission Control, in order to meet IP s BLOs. This will be done by means of policies and rules. 2.4 Known limitations This limitation is known to exist in this release of the software: Placement decision The current implementation does not take into account provider s BLOs and TREC factors when deciding where to deploy a service (locally or remotely). Therefore, we only consider local deployment for this first release. On the contrary, note that management actions during service operation phase, like adding a VM to an already running service, can be applied to remote infrastructures. 2.5 Getting Started Software Dependencies Product Version Licence Java 1.6 GPL Apache tomcat 1.6 Apache License version 2 Jersey-server 1.6 GPL Jersey-core 1.6 GPL mysql-connector-java GPL JAXB API 2.1 GPL EMOTIVE 1.0 LGPL VMManagerRESTClient 1.0 LGPL ElasticityEngine 1.0 LGPL FaultToleranceEngineRESTClient 1.0 LGPL ServiceManagerRestClient 1.0 LGPL Table 1Cloud Optimizer software dependencies Platforms Supported The component is platform independent. OPTIMIS Consortium Page 13 of 39

15 2.5.3 Installation Instructions The server part of this component is distributed as a WAR file. The only installation step needed is to deploy such file in an application server (e.g. Apache Tomcat[7]) Using the Software The client part of the component is packaged as a JAR file and can be used by any user. The only thing that one needs to do is importing such file Testing the Software In a Maven environment the test case can be invoked by means of the following command: mvn test. 2.6 Other information Source Code Information This component has been developed in Java. The main classes of the Cloud Optimizer are the following: CloudOptimizerRESTClient: Java interfaces that act as a client of the RESTful interfaces provided CloudOptimizerREST: RESTful interfaces CloudOptimizer: the core functionality invoked by the RESTful interfaces DBUtil: establishes the connection with the database Queries: encapsulates all the mysqlrequests to the database PhysicalResource/ PhysicalResources and VirtualResource/ VirtualResources: representation of the infrastructure resources stored in the database Directory Structure This software component is divided in three main directories: CloudOptimizerCore: this part encapsulates the core functionality intended to be offered by a server. CloudOptimizerREST: this are the server s RESTful interfaces which provide access to all the functionalities of this component. CloudOptimizerRESTClient: this software part is intended to be used by clients of this component. It is composed by several Java interfaces that act as clients of REST methods offered by a server Contributors J. Oriol Fitó (BSC) Jordi Guitart (BSC) OPTIMIS Consortium Page 14 of 39

16 3 VM Manager 3.1 Introduction to VM Manager The VM Manager is part of the OPTIMIS toolkit for Infrastructure Providers (IPs). Mainly, it is the virtualization-level manager, i.e. operates at the level of virtual machines. In this sense, it offers interfaces which follow the OCCI specification [10]. The detailed design of this component can be found at [1] (Section 10) Functions This software component supports the OCCI interfaces, which allow adding, removing, and getting VMs specified through the OVF distribution format[11]. Besides, it is responsible for providing an efficient placement of VMs running in a Cloud infrastructure, both during their deployment and operation Features The features of this component are as follows: Offers the possibility to create and destroy virtual machines defined by the OVF format Optimizes the placement of virtual machines when deploying a new service, by considering assessments coming from the TREC tools Optimizes the placement of already running virtual machines in a Cloud infrastructure in order to meet changing conditions 3.2 Features and Functions in this release This release implements these new features and functionality: RESTful interfaces The RESTful interfaces are available needed by other OPTIMIS components, as well as the Java clients developed to make the use of those interfaces easier Create Virtual Machines The VM Manager provides the capability to add VMs in a Cloud infrastructure. It receives an OVF representing a single virtual machine. It deploys such VM by means of the OCCI API provided by the EMOTIVE middleware [2]. Once created, the VM Manager gets the location (the physical server) where the VM has been deployed and creates the proper virtual resource in the database Remove Virtual Machines The VM Manager also offers the possibility to remove VMs running in an infrastructure. To that end, it expects to receive the identifier of the VM that needs to be removed. Then, it also uses the OCCI API provided by EMOTIVE in order to terminate such virtual machine. Finally, the virtual resource in the database is removed Download VM images from distributed repository The VM Manager is capable of downloading the needed VM images from a HDFS repository provided by the Data Manager component. OPTIMIS Consortium Page 15 of 39

17 3.3 Features and Functions to be available in the next releases Future releases will implement these new features and functionality: Optimization of VMs placement during their deployment and operation Considering a set of VMs running in a physical infrastructure, the VM Manager will be able to optimize how these VMs are placed on physical resources so that the IP s internal (businesslevel) goals are optimized. At any given moment the VM Manager will be capable of reorganizing the mapping of VMs to physical resources according to those IP s objectives. To that end, it may need to request new assessments and/or predictions to the TREC tools Configurable through policies The VM Manager will offer an interface to allow the Cloud Optimizer to configure it according to IP s BLOs Update rules This component will offer an interface to update the rules of a given management policy. 3.4 Known limitations This limitation is known to exist in this release of the software: OCCI specification The VM Manager does not offer the whole OCCI specification since not all of its operations are used in OPTIMIS. The only methods used are to create and remove virtual machines. 3.5 Getting Started Software Dependencies Product Version Licence Java 1.6 GPL Apache tomcat 1.6 Apache License version 2 Jersey-server 1.6 GPL Jersey-core 1.6 GPL JAXB API 2.1 GPL EMOTIVE 1.0 LGPL CloudOptimizerRESTClient 1.0 LGPL DataManagerClient 1.0 LGPL Table 2VM Manager software dependencies Platforms Supported The component is platform independent. OPTIMIS Consortium Page 16 of 39

18 3.5.3 Installation Instructions The server part of this component is distributed as a WAR file. The only installation step needed is to deploy such file in an application server (e.g. Apache Tomcat[7]) Using the Software The client part of the component is packaged as a JAR file and can be used by any user. The only thing that one needs to do is importing such file Testing the Software In a Maven environment the test case can be invoked by means of the following command: mvn test. 3.6 Other information Source Code Information This component has been developed in Java. Its main classes are the following: VMManagerRESTClient: Java interfaces that act as a client of the RESTful interfaces provided VMManagerREST: contains the RESTful interfaces, which contact with the EMOTIVE OCCI API PlacementOptimizer: encapsulates the functionality of optimizing the placement of several VMs in a given Cloud infrastructure during their deployment and operation Directory Structure The VM Manager is divided in three directories: VMManagerCore: this part of the component s software comprises the functionality of optimizing the placement of already running VMs according to IP s BLOs, as well as values coming from the eco-efficiency, risk, trust, and cost assessment tools. VMManagerREST: it contains the server s RESTful interfaces that provide the OCCI interfaces. VMManagerRESTClient: this software part is intended to be used by clients of this component. It is composed by several Java interfaces that act as clients of REST methods offered by a server Contributors J. Oriol Fitó (BSC) Jordi Guitart (BSC) OPTIMIS Consortium Page 17 of 39

19 4 Fault Tolerance Engine 4.1 Introduction to Fault Tolerance Engine The Fault Tolerance Engine is part of the OPTIMIS toolkit for Infrastructure Providers (IPs). The detailed design of this component can be found at [1] (Section 9) Functions This component is responsible for monitoring and alerting of parts of self-healing infrastructure operation. As such, it explicitly asks or implicitly receives periodic updates to/from the monitoring system about the state of physical hardware hosts and virtual-it infrastructure (i.e. virtual machines, VMs). Later on, this engine decides whether any corrective action is required, such as restarting a recently failed VM. Note that this component only deals with failures at the infrastructure level. This means that software failures occurred during the execution of services within the VMs are not considered at this level, because this is a responsibility of the SP. The distinction between physical hardware hosts and virtual-it infrastructure is possible through querying the Cloud Optimizer, who maintains a database with all the needed information with regard to a particular Cloud infrastructure. However, for this first release, only the detection of failures in virtual resources is implemented. The system proposed is idempotent and tolerant to multiple failures, i.e. physical hosts failures and VMs crashes. To detect such failures, it uses the following information: metrics expressing resources consumption, communication failures to physical hosts, and the state of VMs Features The main features of this engine are the following: It is able to explicitly ask or implicitly receive monitoring information about physical and virtual resources Detects failures of virtual resources. Detection of failures of physical resources is planned for next year. It assumes stateless services. Therefore, no transaction/check-pointing mechanism is needed to handle recovery of services execution upon failures. Notifies the Cloud Optimizer when any corrective action is required during services operation, such as restarting a given VM. 4.2 Features and Functions in this release This release implements these new features and functionality: RESTful interfaces The RESTful interfaces are available needed by other OPTIMIS components, as well as the Java clients developed to make the use of those interfaces easier Services monitoring Once the Fault Tolerance Engine receives a notification that a new service has been deployed, it starts to constantly monitor the VMs associated to such service. OPTIMIS Consortium Page 18 of 39

20 4.2.3 Detection of virtual resources failures This engine is able to detect the failure of virtual resources. To that end, and in particular to this first release, it asks to the Aggregator component for the CPU consumption of those resources. It assumes that a resource has failed if its CPU consumption is equal to zero and its state is not running or blocked. Independently of its CPU usage, a virtual machine is also failing when its state is failed. When a VM failure is detected, the CO is asked to restart the failing VM in another host. 4.3 Features and Functions to be available in the next releases Future releases will implement these new features and functionality: Detection of physical resources failures This engine will able to detect the failure of physical resources. We will consider the failure of a whole host, not individual components within a host. To that end, it will periodically check if physical resources are online (i.e. pinging). If any physical resource does not respond within a given time, it will be considered to be down, and the CO will be asked to restart VMs running in that host in other hosts Improving detection of resources failures In future releases, we will consider to improve this mechanism, for instance by including also heartbeats within the VMs (as VMWare does) Configurable through policies The Fault Tolerance Engine will offer an interface allowing the Cloud Optimizer to configure it (by means of policies) according to IP s BLOs Update rules This component will offer an interface to update the rules associated to a particular management policy. 4.4 Getting Started Software Dependencies Product Version Licence Java 1.6 GPL Apache tomcat 1.6 Apache License version 2 Jersey-server 1.6 GPL Jersey-core 1.6 GPL JAXB API 2.1 GPL CloudOptimizerRESTClient 1.0 LGPL MonitoringInfrastructureRESTClient 1.0 LGPL Table 3Fault Tolerance Engine software dependencies OPTIMIS Consortium Page 19 of 39

21 4.4.2 Platforms Supported The component is platform independent Installation Instructions The server part of this component is distributed as a WAR file. The only installation step needed is to deploy such file in an application server (e.g. Apache Tomcat[7]) Using the Software The client part of the component is packaged as a JAR file and can be used by any user. The only thing that one needs to do is importing such file. 4.5 Other information Source Code Information This component has been developed in Java. Its main classes are the following: FaultToleranceEngineRESTClient: Java interfaces that act as a client of the RESTful interfaces provided FaultToleranceEngineREST: contains the RESTful interfaces FTAssessor: encapsulates core functionalities and establishes communications with the Cloud Optimizer in order to react to resources failures Monitor: it is a Java thread in charge of monitoring services VMs and physical hosts Directory Structure This OPTIMIS engine is divided in three directories: FaultToleranceEngineCore: this core part of the component comprises the main functionality of this engine, and is intended to be offered by an application server. FaultToleranceEngineREST: this is composed by the server side REST interfaces, and provides access to core functionalities. FaultToleranceEngineRESTClient: this software part should be used by clients of this component. It is composed by several Java interfaces that act as clients of REST methods offered by a server Contributors J. Oriol Fitó (BSC) Jordi Guitart (BSC) OPTIMIS Consortium Page 20 of 39

22 5 Elasticity Engine 5.1 Introduction to Elasticity Engine The Elasticity Engine is responsible for the enactment of elasticity. It receives information from the Monitoring System about updates of the terms (the runtime state) that are associated with elasticity rules in the service manifest. For each updated state datum, the engine controls whether to trigger a rule. Examples of elasticity rules of an SP include, for instance, allocating more storage if the number of users of a service exceeds 500. On the contrary, rules at the IP level can determine, for instance, that an additional application service VM must be started if more than 5% of user requests are lost during the last 5 minute period. Upon triggering of an elasticity rule, the engine emits an action (e.g., to start or shutdown a VM) to the VM and/or Data Management components Functions The elasticity engine API is responsible for controlling the number of VMs assigned to a service. The engine assigns VMs to a service based on the current load Features A reactive controller is used for making the allocation and deallocation of VMs decisions. This component can be used by an infrastructure provider or by a service provider to control the number of VMs allocated to a service running on the infrastructure allowing for a reduction in both the cost of running the service and the cost of operation. 5.2 Features and Functions in this release This release implements these new features and functionality: Reactive Elasticity Controller: The elasticity engine API provides a controller for adding or removing VMs autonomously. The engine can be used by the service provider or the infrastructure provider KPI Based Elasticity The elasticity engine may operate on either hardware measurements (such as CPU utilization) or on Key Performance Indicators (KPIs). A KPI may be any measurement taken from inside the service itself, and allows for very customized elasticity on the service level. 5.3 Features and Functions to be available in the next releases Future releases will implement these new features and functionality: Proactive Elasticity control In the next release of the API, the elasticity engine will predict the future load on a service allowing the service provider or the infrastructure provider to proactively allocate resources to the service in order to improve the quality of the service. It will also allow the infrastructure provider to better enforce the SLAs and predict the total future usage of the infrastructure. OPTIMIS Consortium Page 21 of 39

23 5.3.2 Vertical Elasticity The next release of the API will incorporate vertical elasticity which is the ability of the infrastructure provider or the service provider to increase and/or decrease the size of VMs to adapt with the changing load. 5.4 Known limitations These limitations are known to exist in this release of the software: Elasticity Rule Format The format for specifying elasticity rules in the manifest have not been thoroughly investigated and designed. The format in use for the current version of the software is a legacy format, which might not be applicable to all situations. However, for the first year, this legacy format is considered being sufficient Single Type of Measurements Due to the limitations in the elasticity rule format, the rules do not support specifying the type of measurement (hardware or KPI) to be used for a specific rule. For this reason, only service level metrics are used in this first release Considering Time Periods More advanced elasticity rules, such as considering the average CPU usage during the last five minutes, is currently not supported in the elasticity engine. This requires some aggregation and calculations on the data received from monitoring, but the current version of the software only considers the most recent values. 5.5 Getting Started Software Dependencies Product Version Licence XStream XML Parser GPL Monitoring REST Client SNAPSHOT LGPL Monitoring Resources Common SNAPSHOT LGPL Cloud Optimizer REST Client 1.0-SNAPSHOT LGPL JUnit Common Public License - v 1.0 Log4j The Apache software license version 2.0 Commons Lang 2.4 The Apache software license version 2.0 Commons Configuration 1.6 The Apache software license version 2.0 Table 4Elasticity Engine software dependencies Platforms Supported This is a Java API which can be used under any operating system. OPTIMIS Consortium Page 22 of 39

24 5.5.3 Installation Instructions The elasticity engine is compiled into a separate JAR file, which would normally be used internally by other components. The elasticity engine is not meant to run stand-alone Using the Software As the elasticity engine is an API, the developer will use the functions as are void updaterules (ServiceID,serviceManifest) This method receives the service manifest which specifies, among others, the expected levels of elasticity, such as the minimum and maximum number of instances of each VM in the service. This allows other OPTIMIS components, i.e. Cloud Optimizer, to change elasticityrelated rules. startelasticityengine(serviceid) This method is called by the Cloud Optimizer and creates a new instance of the elasticity engine for a new service when it is deployed to enact elasticity for the service. Besides, this engine uses the following external interfaces exposed by other components of the OPTIMIS toolkit: dataset getdata(serviceid, parametername) This method is offered by the Monitoring Stream. Essentially, it is used to obtain the information needed whether to enact elasticity rules are or not. Because of this engine can be used by both SPs and IPs, this information can be either service-level (e.g. the total number of users of a service) or infrastructure-level (e.g. VMs resources utilization). addvm (serviceid,servicemanifest) removevm(serviceid) Both methods are implemented by the Cloud Optimizer to receive the elasticity decisions of the elasticity engine. The serviceid tells the Cloud Optimizer which service to change Testing the Software There are some unit tests included in the software distribution, run automatically when the software is built. As the elasticity engine is a support component to other parts of the OPTIMIS toolkit, stand-alone tests does not exist at this point. 5.6 Other Information Contributors Daniel Henriksson Ahmed Aley OPTIMIS Consortium Page 23 of 39

25 6 Service Manager 6.1 Introduction to Service Manager This component is aimed to optimize the management of services during deployment and operation. This means to offer the environment and capabilities needed to deploy and contextualize services and to obtain an efficient operation.in a nutshell, the Service Manager has to manage deployed services and their corresponding information Functions This component is a RESTful web service that allows the management for services; services are described by different features: - an identifier unique to a service; - the status the service is currently in (pending, running, ); - a list of infrastructure providers associated with this service. Each infrastructure provider, in turn, is characterized by: - its own unique id, - its address and - a list of virtual machines running at the specific infrastructure provider Features - Management of services and their corresponding information through a straightforward RESTful API - Management of infrastructure provider and VM data through a straightforward RESTful API - Support for XML-based (CLI) as well as HTML-based (GUI) access 6.2 Features and Functions in this release This is the first release of this component and all of the functionality that has been implemented until now can be thought of as new functionality. This release implements these new features and functionality: Service management The software provides a RESTful interface for the management of services (creation, deleting, querying) Infrastructure provider management The software provides a RESTful interface for the management of infrastructure providers associated to services and for the virtual machines running at an infrastructure provider. 6.3 Features and Functions to be available in the next releases Future releases will implement these new features and functionality: OPTIMIS Consortium Page 24 of 39

26 6.3.1 Database backend Future version will provide support for using database backend. 6.4 Known limitations This limitationis known to exist in this release of the software: Non-persistent data storage Data storage is currently only implemented with an in-memory solution. Restarting the container will result in the loss of all data stored in the service manager. This will be remedied by switching to a database-backed storage instead of the in-memory storage in future releases. 6.5 Getting Started Software Dependencies The binary archive provided for deployment does not depend on any other software Platforms Supported The Service Manager runs inside the Apache Tomcat web container and therefore is running on all platforms that support Apache Tomcat[7] Installation Instructions The Service Manager is provided as a WAR archive that can be deployed out of the box. No compilation is necessary Using the Software There are multiple possibilities to use the software: - Access via curl [9]or similar tools (see section 6.5.5) - Access using the prepared clients - Access using custom clients In the first case, the payload information has to be constructed manually. The second case offers convenient implementations that can be readily used, and the third case enables developers to use their own clients Testing the Software The simplest way to test this component is by accessing it via the command-line tool curl[9]. For these commands, we assume software is deployed at and server has been freshly restarted. Initially, let's see if we get a list of services: $ curl This should yield the following result: <services></services> No service exists, which is the expected result. OPTIMIS Consortium Page 25 of 39

27 Creating a service works by POSTing to the /services URI: $ curl -X POST \ -d "<service xmlns=\" </service>" This should yield the following output: <service> <service_id>14711</service_id> <status>running</status> <IP><ip_id>null</ip_id><ip_address>null</ip_address><vms></vms>< /IP> <link>/services/14711</link> </service> Trying the first command above again will then yield the previous output wrapped in the <services></services> tags. Adding a VM works by PUTting a VM id, as shown in the following request: $ curl -X PUT -d 135 This yields: <service> <service_id>14711</service_id> <status>running</status> <IP> <ip_id>null</ip_id> <ip_address>null</ip_address> <vms><vm>135</vm></vms> </IP> <link>/services/14711</link> </service> 6.6 Other information Source Code Information The two main classes that are exposed to the client are: OPTIMIS Consortium Page 26 of 39

28 - src/main/java/eu/optimis/service_manager/servicesresource.java (Listing multiple services and creating new services) - src/main/java/eu/optimis/service_manager/serviceresource.java (Operations on a single service) Starting from these two classes, it is easy to see the implementation Directory Structure The Service Manager is developed using Apache Maven[8] and the directory structure therefore adheres to the one proposed by Maven Contributors Gregory Katsaros Roland Kübert Tinghe Wang OPTIMIS Consortium Page 27 of 39

29 7 Data Manager The data management component is included in a Virtual Machine format, which consists of two types of VMs, the Data Manager and the Data Nodes. It is heavily based on the Apache Hadoop project implementation and especially the data management part of the latter, HDFS, on top of which suitable RESTful interfaces have been added. Furthermore, extensions to existing software components such as FUSE and sshfs have been implemented in order to extend their functionality in the scope of the OPTIMIS project. In this year's release, the most significant features are the RESTful interfaces through which a Service Provider may create an account on the HDFS, upload or download data or get information regarding the account or the Infrastructure Provider's data center locations. Furthermore, data encryption has been incorporated in order to increase security on this multi-tenant environment in addition to a data location monitor. More information regarding the design of the component can be found in[1], while more information regarding the technical implementation and installation can be found in[3]. OPTIMIS Consortium Page 28 of 39

30 8 Eco-efficiency Assessment Tool 8.1 Introduction to Eco-efficiency Assessment Tool The Eco-efficiency Assessment Tool is part of the OPTIMIS Base Toolkit. The detailed design of this component can be found at [1] (Section 5) Functions This assessment tool is in charge of assessing ecological efficiency-related aspects, such as energy efficiency and carbon emission levels, in a given Cloud infrastructure. In this sense, it uses the information obtained by the respective collector of the OPTIMIS monitoring infrastructure, i.e. the energy efficiency monitoring collector. More to the point, those assessments arefully guided by energy-related constraintsspecified in service manifest Features The key features of this assessment tool are: Assessment and forecasting of the eco-efficiency of entities at the level of Service Providers, i.e. Cloud services. For this first release, this is done by deriving the energy consumption of physical hosts using their CPU utilization. Then, according to the CPU consumption of each VM running on that host, we can somehow estimate the energy consumption of those VMs. Then, the energy consumption of services is the sum of their VMs energy consumption. In other words, the eco-efficiency of services is the mean of their VMs eco-efficiency. Assessment and forecasting of the eco-efficiency of entities at the level of Infrastructure Providers, i.e. single physical node or the whole Cloud infrastructure. For this first release, this is done by deriving the energy consumption of physical hosts from their CPU utilization. 8.2 Features and Functions in this release This release implements these new features and functionality: RESTful interfaces The RESTful interfaces needed by other OPTIMIS components, as well as the Java clients developed to make easier the use of those interfaces (either at service or infrastructure level), are available Basic eco-efficiency assessments and predictions In this first release, this TREC tool is only able to produce basic eco-efficiency assessments and predictions, since no energy-related data is available. In actual fact, this tool obtains the CPU consumption of physical hosts and virtual machines and, based on that, it determines the energy consumption by means of energy models (see [13]for more information). 8.3 Features and Functions to be available in the next releases Future releases will implement these new features and functionality: Accurate eco-efficient assessments and predictions This assessment tool will be able to provide accurate and more sophisticated assessments and predictions once energy consumption data, as well as other energy-related data (e.g. carbon OPTIMIS Consortium Page 29 of 39

31 emissions), will be available. In fact, we will seek the evaluation of some Green Performance Indicators (GPI) in order to assess the eco-efficiency at service- and infrastructure-level. 8.4 Known limitations This limitation is known to exist in this release of the software: Energy consumption data is unavailable Special devices to monitor energy consumption of servers are not available. Therefore, there is not real energy-related information, which is mandatory to provide eco-efficiency assessments. 8.5 Getting Started Software Dependencies Product Version Licence Java 1.6 GPL Apache tomcat 1.6 Apache License version 2 Jersey-server 1.6 GPL Jersey-core 1.6 GPL JAXB API 2.1 GPL CloudOptimizerRESTClient 1.0 LGPL MonitoringInfrastructureRESTClient 1.0 LGPL Table 5 Eco-efficiency Assessment Tool software dependencies Platforms Supported The component is platform independent Installation Instructions The server part of this component is distributed as a WAR file. The only installation step needed is to deploy such file in an application server (e.g. Apache Tomcat [7]) Using the Software The client part of the component is packaged as two different JAR files, which can be used by any user (one to request assessments at the level of SPs and the other one toward IPs). The only thing that one needs to do is importing such file Testing the Software In a Maven environment the test case can be invoked by means of the following command: mvn test. OPTIMIS Consortium Page 30 of 39

32 8.6 Other information Source Code Information The eco-efficiency assessment tool has been developed in Java, and its main classes are the following: EcoEfficiencyToolRESTClientSP: Java interfaces that act as an SP-level client of the RESTful interfaces provided EcoEfficiencyToolRESTClientIP: Java interfaces that act as an IP-level client of the RESTful interfaces provided EcoEfficiencyToolREST: contains the RESTful interfaces EcoEffAssessor: encapsulates core methods which really calculates the eco-efficiency assessments and predictions Directory Structure This assessment tool is divided in three directories: EcoEfficiencyToolCore: this core part of the component comprises the main functionality of this tool. EcoEfficiencyToolREST: this is composed by the server side RESTful interfaces, and provides access to core functionalities. EcoEfficiencyToolRESTClient: this software part should be used by other components. It is composed by several Java interfaces that act as clients of RESTful methods offered by a server Contributors J. Oriol Fitó (BSC) Jordi Guitart (BSC) OPTIMIS Consortium Page 31 of 39