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

33 9 Trust Assessment Tool 9.1 Introduction to Trust Assessment Tool This component takes care of the trust calculation about resources in the cloud. It uses the inputs from the Monitoring tools and the Social Network in order to determine whether a resource should be trusted or not. This component is developed in WP3.3 and, while the document D3.3.1 Trust Framework Detailed Design [12] explains its main design and principles, the document D3.3.2 Trust Framework Software Prototype [5] explains more in detail its features Functions Its main function is to gather information about resources and services execution, and calculate the trust corresponding to the resources and the infrastructure provider. In this release, the main functions implemented are: Calculate trust by using monitoring information Calculate trust by using SLA compliance information Aggregate both calculations for obtaining a general one More detail about the functions can be found in [5] Features Some of the features included in the first prototype of the tool are: API exposed as web service, for easy integration; Integration with Monitoring tools in order to retrieve information about real interactions; Usage of statistical tests (Fleiss Kappa & Cohen s Kappa) and Subjective Logic for calculating trust; Capability to read service manifest, in order to extract information about services requirements. 9.2 Features and Functions in this release This release implements these new features and functionality (more detail in [5]): Integration with Monitoring The current version of the tool includes a client which is able to connect with the Monitoring tool and extract information for calculating trust. Currently, the Monitoring tool supports metrics in three levels: Service Level Metrics associated directly to the service; VM level Metrics related to the VM where the service is deployed; Physical level Metrics coming from the physical machine hosting the VMs where the service is deployed. Due to the current features of Monitoring tools, the Trust Framework is able to take advantage of five metrics, four from the VM level and one from the Physical level. OPTIMIS Consortium Page 32 of 39

34 9.2.2 Trust Calculation with Monitoring and SLAs Taking the monitoring information and SLAs compliance information as input, the Trust Framework performs some calculations which provide, at the end, an opinion about the VM where the service is deployed. This is performed by combining two techniques: Fleiss Kappa A statistical test which provides information about agreement between monitoring sources, as a way to determine uncertainty; Subjective Logic Using monitoring information as facts becoming beliefs and the Fleiss kappa, an opinion is generated, according to Subjective Logic theory The result coming from the combination of opinions provides a value considered the trust Compliance with Manifest Files As part of its implementation, calculation mechanisms require to use information about service deployment requirements as a reference. For that reason the Trust Framework includes a component which is able to parse the XML file representing these requirements, storing some data which can be mapped with the monitoring information gathered, which will be used later for calculating trust. 9.3 Features and Functions to be available in the next releases Future releases will implement these new features and functionality (more information in [5]): Trust Calculation with Social Networking An important part of the trust calculation comes from the opinion which others provide about a resource or an Infrastructure Provider because of their own experience interacting directly with them (using the resource, for instance). It will be possible to gather opinions from several sources in order to determine the reputation associated to a resource. This reputation will represent part of the trust and will be merged with the rest of metric used in the Trust Framework More Parameters for Current Calculations As the implementation of Monitoring tools goes on and more information is available, it will be possible to determine how to integrate more metrics in the calculation. It will be necessary to perform the correct mapping with existing information in the service manifest as well, taking the correct reference values for calculating trust Integration with more Tools It is necessary to increase the number of tools to be integrated with the Trust Framework. One example is the Service Manager, as source of information about in which VMs a service is deployed. Another one is the SLA compliance analyzer, which will provide accurate information about the fulfillment of SLAs. Currently, service manifest files are accessed directly from the file stored in the local hard disk but the idea is to obtain files directly from the deployment responsible, in an automatic way. 9.4 Known limitations These limitations are known to exist in this release of the software (more information in [5]): OPTIMIS Consortium Page 33 of 39

35 9.4.1 Number of Parameters Used Currently, the number of parameters used from the Monitoring tool is quite limited, due to the concurrent development of tools. By now, only five parameters are used, although the number will increase in next releases. For the same reason, the number of monitors to be taken into account is limited too, and it will be increased when more tools are integrated (i.e. Service Manager) Integration with Real SLAs Even if conceptually the SLAs compliance is included as part of the trust calculation, that compliance is currently simulated by using a simple approach which gives an idea about the compliance, but it is not as accurate as the component dedicated to SLA compliance Simple Manifest Files The Trust Framework is able to read service manifest files, but these files are expected only to contain a VM definition for application and a VM definition for the database. In case more VMs definitions are included, only those values defined in the last one are recovered, as the former ones are overwritten. 9.5 Getting Started All the information about how to get started (software dependencies, hardware requirements, platforms supported, installation instructions, how to use the software and how to test the software) can be found in [5]. 9.6 Other information Contributors People who contributed to this component are: Juan Luis Prieto (Atos) Francisco Javier Nieto (Atos) PramodS. Pawar(BT) OPTIMIS Consortium Page 34 of 39

36 10 Risk and Cost Assessment Tools Apart from the eco-efficiency and trust assessments, the self-managed Cloud runtime also uses risk, and cost assessments, which are provided by the respective assessment tools. The detailed description of these assessment tools can be found on D (cost)[4], and D (risk)[6]. OPTIMIS Consortium Page 35 of 39

37 11 References [1] OPTIMIS Detailed Design, Deliverable D of OPTIMIS project. [2] EMOTIVE Website, [3] Federated Data Management Mechanisms Prototype, Deliverable D of OPTIMIS project [4] Cloud Service economics Framework, Deliverable D of OPTIMIS project [5] Trust framework Software prototype, Deliverable D of OPTIMIS project [6] Provider s risk assessment tools static data, Deliverable D of OPTIMIS project [7] Apache Tomcat, Apache Software Foundation, [8] Apache Maven, Apache Software Foundation, [9] Curl home page, [10] Open Grid Forum. Open Cloud Computing Interface (OCCI) Infrastructure, Version 1. [11] Distributed Management Task Force. Open Virtualization Format (OVF) Specification, Version [12] Trust Framework Detailed Design, Deliverable ID3.3.1 of OPTIMIS project [13] I. Goiri, F. Julià, R. Nou, J.L. Berral, J. Guitart, and J. Torres. Energy-aware Scheduling in Virtualized Datacenters. 12th IEEE International Conference on Cluster Computing (Cluster'10). Heraklion, Crete, Greece, September 20-24, 2010, pp OPTIMIS Consortium Page 36 of 39

38 Annex A. License conditions. This is a public deliverable that is provided to the community under the license Attribution-NoDerivs 2.5 defined by creative commons This license allows you to to copy, distribute, display, and perform the work to make commercial use of the work Under the following conditions: Attribution. You must attribute the work by indicating that this work originated from the IST- OPTIMIS project and has been partially funded by the European Commission under contract number IST No Derivative Works. You may not alter, transform, or build upon this work without explicit permission of the consortium For any reuse or distribution, you must make clear to others the license terms of this work. Any of these conditions can be waived if you get permission from the copyright holder. This is a human-readable summary of the Legal Code below: License THE WORK (AS DEFINED BELOW) IS PROVIDED UNDER THE TERMS OF THIS CREATIVE COMMONS PUBLIC LICENSE ("CCPL" OR "LICENSE"). THE WORK IS PROTECTED BY COPYRIGHT AND/OR OTHER APPLICABLE LAW. ANY USE OF THE WORK OTHER THAN AS AUTHORIZED UNDER THIS LICENSE OR COPYRIGHT LAW IS PROHIBITED. BY EXERCISING ANY RIGHTS TO THE WORK PROVIDED HERE, YOU ACCEPT AND AGREE TO BE BOUND BY THE TERMS OF THIS LICENSE. THE LICENSOR GRANTS YOU THE RIGHTS CONTAINED HERE IN CONSIDERATION OF YOUR ACCEPTANCE OF SUCH TERMS AND CONDITIONS. 1. Definitions "Collective Work" means a work, such as a periodical issue, anthology or encyclopedia, in which the Work in its entirety in unmodified form, along with a number of other contributions, constituting separate and independent works in themselves, are assembled into a collective whole. A work that constitutes a Collective Work will not be considered a Derivative Work (as defined below) for the purposes of this License. "Derivative Work" means a work based upon the Work or upon the Work and other pre-existing works, such as a translation, musical arrangement, dramatization, fictionalization, motion picture version, sound recording, art reproduction, abridgment, condensation, or any other form in which the Work may be recast, transformed, or adapted, except that a work that constitutes a Collective Work will not be considered a Derivative Work for the purpose of this License. For the avoidance of doubt, where the Work is a musical composition or sound recording, the synchronization of the Work in timed-relation with a moving image ("synching") will be considered a Derivative Work for the purpose of this License. "Licensor" means all partners of the OPTIMIS consortium that have participated in the production of this text "Original Author" means the individual or entity who created the Work. "Work" means the copyrightable work of authorship offered under the terms of this License. "You" means an individual or entity exercising rights under this License who has not previously violated the terms of this License with respect to the Work, or who has received express permission from the Licensor to exercise rights under this License despite a previous violation. 2. Fair Use Rights. Nothing in this license is intended to reduce, limit, or restrict any rights arising from fair use, first sale or other limitations on the exclusive rights of the copyright owner under copyright law or other applicable laws. 3. License Grant. Subject to the terms and conditions of this License, Licensor hereby grants You a worldwide, royalty-free, nonexclusive, perpetual (for the duration of the applicable copyright) license to exercise the rights in the Work as stated below: to reproduce the Work, to incorporate the Work into one or more Collective Works, and to reproduce the Work as incorporated in the Collective Works; to distribute copies or phonorecords of, display publicly, perform publicly, and perform publicly by means of a digital audio transmission the Work including as incorporated in Collective Works. For the avoidance of doubt, where the work is a musical composition: Performance Royalties Under Blanket Licenses. Licensor waives the exclusive right to collect, whether individually or via a performance rights society (e.g. ASCAP, BMI, SESAC), royalties for the public performance or public digital performance (e.g. webcast) of the Work. Mechanical Rights and Statutory Royalties. Licensor waives the exclusive right to collect, whether individually or via a music rights society or designated agent (e.g. Harry Fox Agency), royalties for any phonorecord You create from the Work ("cover version") and OPTIMIS Consortium Page 37 of 39

39 distribute, subject to the compulsory license created by 17 USC Section 115 of the US Copyright Act (or the equivalent in other jurisdictions). Webcasting Rights and Statutory Royalties. For the avoidance of doubt, where the Work is a sound recording, Licensor waives the exclusive right to collect, whether individually or via a performance-rights society (e.g. SoundExchange), royalties for the public digital performance (e.g. webcast) of the Work, subject to the compulsory license created by 17 USC Section 114 of the US Copyright Act (or the equivalent in other jurisdictions). The above rights may be exercised in all media and formats whether now known or hereafter devised. The above rights include the right to make such modifications as are technically necessary to exercise the rights in other media and formats, but otherwise you have no rights to make Derivative Works. All rights not expressly granted by Licensor are hereby reserved. 4. Restrictions. The license granted in Section 3 above is expressly made subject to and limited by the following restrictions: You may distribute, publicly display, publicly perform, or publicly digitally perform the Work only under the terms of this License, and You must include a copy of, or the Uniform Resource Identifier for, this License with every copy or phonorecord of the Work You distribute, publicly display, publicly perform, or publicly digitally perform. You may not offer or impose any terms on the Work that alter or restrict the terms of this License or the recipients' exercise of the rights granted hereunder. You may not sublicense the Work. You must keep intact all notices that refer to this License and to the disclaimer of warranties. You may not distribute, publicly display, publicly perform, or publicly digitally perform the Work with any technological measures that control access or use of the Work in a manner inconsistent with the terms of this License Agreement. The above applies to the Work as incorporated in a Collective Work, but this does not require the Collective Work apart from the Work itself to be made subject to the terms of this License. If You create a Collective Work, upon notice from any Licensor You must, to the extent practicable, remove from the Collective Work any credit as required by clause 4(b), as requested. If you distribute, publicly display, publicly perform, or publicly digitally perform the Work or Collective Works, You must keep intact all copyright notices for the Work and provide, reasonable to the medium or means You are utilizing: (i) the name of the Original Author (or pseudonym, if applicable) if supplied, and/or (ii) if the Original Author and/or Licensor designate another party or parties (e.g. a sponsor institute, publishing entity, journal) for attribution in Licensor's copyright notice, terms of service or by other reasonable means, the name of such party or parties; the title of the Work if supplied; and to the extent reasonably practicable, the Uniform Resource Identifier, if any, that Licensor specifies to be associated with the Work, unless such URI does not refer to the copyright notice or licensing information for the Work. Such credit may be implemented in any reasonable manner; provided, however, that in the case of a Collective Work, at a minimum such credit will appear where any other comparable authorship credit appears and in a manner at least as prominent as such other comparable authorship credit. 5. Representations, Warranties and Disclaimer. UNLESS OTHERWISE MUTUALLY AGREED TO BY THE PARTIES IN WRITING, LICENSOR OFFERS THE WORK AS-IS AND MAKES NO REPRESENTATIONS OR WARRANTIES OF ANY KIND CONCERNING THE MATERIALS, EXPRESS, IMPLIED, STATUTORY OR OTHERWISE, INCLUDING, WITHOUT LIMITATION, WARRANTIES OF TITLE, MERCHANTIBILITY, FITNESS FOR A PARTICULAR PURPOSE, NONINFRINGEMENT, OR THE ABSENCE OF LATENT OR OTHER DEFECTS, ACCURACY, OR THE PRESENCE OF ABSENCE OF ERRORS, WHETHER OR NOT DISCOVERABLE. SOME JURISDICTIONS DO NOT ALLOW THE EXCLUSION OF IMPLIED WARRANTIES, SO SUCH EXCLUSION MAY NOT APPLY TO YOU. 6. Limitation on Liability. EXCEPT TO THE EXTENT REQUIRED BY APPLICABLE LAW, IN NO EVENT WILL LICENSOR BE LIABLE TO YOU ON ANY LEGAL THEORY FOR ANY SPECIAL, INCIDENTAL, CONSEQUENTIAL, PUNITIVE OR EXEMPLARY DAMAGES ARISING OUT OF THIS LICENSE OR THE USE OF THE WORK, EVEN IF LICENSOR HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. 7. Termination This License and the rights granted hereunder will terminate automatically upon any breach by You of the terms of this License. Individuals or entities who have received Collective Works from You under this License, however, will not have their licenses terminated provided such individuals or entities remain in full compliance with those licenses. Sections 1, 2, 5, 6, 7, and 8 will survive any termination of this License. Subject to the above terms and conditions, the license granted here is perpetual (for the duration of the applicable copyright in the Work). Notwithstanding the above, Licensor reserves the right to release the Work under different license terms or to stop distributing the Work at any time; provided, however that any such election will not serve to withdraw this License (or any other license that has been, or is required to be, granted under the terms of this License), and this License will continue in full force and effect unless terminated as stated above. 8. Miscellaneous Each time You distribute or publicly digitally perform the Work, the Licensor offers to the recipient a license to the Work on the same terms and conditions as the license granted to You under this License. If any provision of this License is invalid or unenforceable under applicable law, it shall not affect the validity or enforceability of the remainder of the terms of this License, and without further action by the parties to this agreement, such provision shall be reformed to the minimum extent necessary to make such provision valid and enforceable. No term or provision of this License shall be deemed waived and no breach consented to unless such waiver or consent shall be in writing and signed by the party to be charged with such waiver or consent. This License constitutes the entire agreement between the parties with respect to the Work licensed here. There are no understandings, agreements or representations with respect to the Work not specified here. Licensor shall not be bound by any additional provisions that may appear in any communication from You. This License may not be modified without the mutual written agreement of the Licensor and You. OPTIMIS Consortium Page 38 of 39