D5.1 Inter-Layer Cloud Stack Adaptation Summary

Transcription

1 D5.1 Inter-Layer Cloud Stack Adaptation Summary The ASCETiC architecture focuses on providing novel methods and tools to support software developers aiming at optimising energy efficiency resulting from designing, developing, deploying and running software in Clouds. In Y2 of the project, we focused on intra-layer adaptation in which each layer adapt independently, without taking into account the other cloud layers. In Y3 of the project, the layers cooperate with inter-layer self-adaptation. In particular, the Y3 further develops on Y1 and Y2. We focus on extending and consolidating the capabilities of dynamic energy management by ensuring the cloud layers interact and cooperate to mitigate energy consumption. Such interlayer self-adaptation ensures that the layers cooperate in order to achieve greater energy reductions than a per-layer approach can achieve on its own. Key aspects include communication and (re)negotiation between the layers so that optimisations can meet each stakeholder s requirements. Let us briefly summarize our scientific contributions per cloud layer, as well as the inter-layer scenarios we consider in Y3: SaaS layer: The Programming Model implements scheduling policies in the runtime to optimize performance, energy and cost, using global boundaries, and implements application-driven horizontal elasticity mechanisms. The SaaS Application Development Time Simulation Tooling runs a design-time simulation of workload for estimating anticipated behaviour of applications on time, cost and energy performance. The SaaS Virtual Machine Image Constructor implements the automation of image construction, fills the gap between generating base images in cloud computing and automatic configuration of cloud applications, packages cloud applications enabling provider-agnostic deployment, supports chef cookbooks to pass to the VMIC to build images, as well as supports translation of XML to OVF SLA terms and adaptation rules. Code Optimizer Plug-in is further improved to explore energy consumption within applications that are under development. PaaS layer: The Self-Adaptation is enabled taking decisions on the type of adaptation to make at PaaS, as well as performing application tailored adaptation based on rule specification. The Energy forecasts power using neural networks, and estimates VM consumption based only on data VM-observed data. The Pricing enables selfadaptation based on cost, vertical and horizontal elasticity, as well as SLA monitoring support. The Application enables renegotiation with the same provider to accommodate the needs of an application, moving an application to a different provider, support for extra SLA terms and self-adaptation rules, as well as changes in the elasticity workflow to verify that everything is inside the SLA agreement. The SLA provides PaaS-IaaS terms translation, error and proactive monitoring, and enables renegotiation and new supported terms. The 1

2 Provider Registry shows free slot information to know whether is possible to create a new VM without having a big impact in energy consumption. IaaS layer: The Virtual Machine supports hardware heterogeneity, vertical scalability and Docker containers, provides information regarding free slots, as well as considers green energy sources in scheduling policies. The Energy enables DFS-awareness through reallocation of power consumption from DFS based node to VMs, VM migration awareness and prediction capacity, as well as enhanced scale thorough, Watt meter emulation and the use of IPMI sensor data, with careful calibration. The Pricing supports enabling multiple providers, vertical and horizontal elasticity, as well as implements an energy provider simulator for supporting changes in energy prices. Finally, the SLA supports renegotiation, new supported terms, as well as error monitoring. Inter-layer Scenarios: In Y3, our research work was mainly focused on inter-layer communication and self-adaptation mechanisms in order to optimize energy efficiency. We briefly present three identified inter-layer optimization scenarios, intending to show the overall benefits that ASCETiC provides and consider the enabled self-adaptation mechanisms. In the GPF inter-layer scenario, we focused on Programming Model triggered self-adaptation, where the PMR requests or removes machines to accomplish the scheduling global boundaries specified by the user. If it is important for the user to accomplish them (i.e. certain performance, total energy consumption, or total cost), the user acknowledges any penalties applied by the PaaS layer due to the SLA violation. Otherwise, the user might be more interested in complying with the SLA defined, accomplishing the global boundaries defined, or being proactively indicated about a potential SLA violation. In the SocialSensor inter-layer scenario, we focused on slot-aware VM deployment. We assume that a performance violation occurs, notified by PaaS SLAM to PaaS SAM. To cope with the violation, PaaS SAM decides to scale up. To make an energy-aware scale up, SAM checks, through the Application acting as a proxy, how big is the biggest VM slot available in the running hosts of the current IaaS provider, to possibly avoid starting further hosts. The assumption in this scenario is that IaaS layer manages the available pool of hosts by scheduling VMs to maximize host utilization and therefore it powers off unused hosts. In the NewsAsset inter-layer scenario, we focused on SaaS bespoke adaptation-rule delegation. When the application needs to scale up, the Application bases its provisioning decision on the information provided by the VMM about which resources are available on the running hosts. This allows avoiding starting new hosts. Furthermore, the application provider may also specify rules when particular degree of workload is expected. These rules can then be used by the Cloud provider to adapt an application to the anticipated workload in a proactive way. Such rules may be used to scale down at specific time period such as night time, lunch time or Holiday periods in certain geographical location where most users are located. Alternatively, application-specific flags that indicate a high probability in workload variation in a near future may also be communicated from the application to the PaaS Application Monitor so that the appropriate number of VMs is provisioned anticipatively. 2

3 In Deliverable 5.1, we present in detail the Y3 contributions per component, as well as an updated software user guide for each layer of the ASCETiC toolbox. Below, we summarise in tabula form on a per component basis the novelty of the ASCETiC architecture during Y3 of the project, as well as the overall progress during the whole project. Table 1: Summary of Novelty within the ASCETiC Architecture Component Novelty in Y3 Overall progress during the project ASCETiC Programming Implement scheduling policies in the runtime to optimize In Y1, versioning and greedy policy was implemented. Model performance, energy and cost, using global boundaries (considering the whole workflow for the scheduling). In Y2, intra-layer scheduling optimizing energy, performance or cost, with instant boundaries was Implement horizontal elasticity mechanisms driven from the application-level knowledge, which require inter-layer communication. implemented. Requirements and Design Modelling Tooling SaaS Virtual Machine Image Constructor SaaS Application SaaS Application Development Time Simulation Tooling: Run a design-time simulation of workload exercised on a tentative Cloud deployment configuration of an application for estimating its anticipated behaviour on time, cost and energy performance. Implements the automation of image construction. Fills the gap between generating base images in cloud computing and automatic configuration of cloud applications. Supports the energy efficiency goal within the architecture by providing means of packaging Cloud applications in a way that enables provider agnostic deployment, while maintaining energy awareness. New support for Chef cookbooks to pass to the VMIC In Y1, augmented UML deployment profile was implemented to specify ASCETIC deployment data. In Y2, we provided development time tools to guide conducting runtime experimentation to learn realistic measurements on time, energy and cost of an application to identify the best deployment configuration in relation to workload expected from targeted customer groups It has remained fairly stable throughout the project, its focus has been on providing the means to create multiple versions of a software deployment, thus enabling adaptation. This component was designed by scratch to take 3

4 Component Novelty in Y3 Overall progress during the project Packager to build images. the outcomes of the R&D New support to translate XML to OVF SLA terms and Adaptation rules. model and prepare the application to be packaged into VMs. In Y1, it was just a basic translation to OVF. In Y2, it also interacted with the VMIC to build the images of the application. Code Optimizer Plugin PaaS Self- Adaptation PaaS Energy PaaS Pricing PaaS Application PaaS SLA Further improvements to explore energy consumption within applications that are under development. Decision engine for deciding on the type of adaptation to make at PaaS. Application tailored adaptation, based on rule specification through OVF. Power forecasting using neural networks. Estimation of VM consumption based only on data VMobserved data. Self-adaptation based on cost. Vertical elasticity, horizontal elasticity. Support of SLA monitoring. Vertical competition. Renegotiation with the same provider to be able to accommodate the needs of an application. Moving an application to a different provider. Support for extra SLA terms and self-adaptation rules. Changes in the elasticity workflow to verify that everything is inside the SLA agreement. PaaS-IaaS terms translation. Renegotiation. New supported terms (including a parametric one). Introduced in Y3, this application profiles applications at development time for their power and energy usage. It was introduced in Y2 as the means to govern adaptation in the PaaS layer. It was introduced with only basic knowledge of the IaaS layer. In Y2, it gains more detailed knowledge and adapts accordingly. In Y1, estimations and measurements at application level were provided. In Y2, estimations and measurements were integrated with the ones at event level. Calculation of prices based on costs coming from IaaS providers. Multiple IaaS providers. In Y1, it just orchestrated a basic energy aware to deploy and manage application. In Y2, all the workflows complicated a bit more to enable the PaaS Self Adaptation, adding things such as elasticity. In Y1, it supported energy aware negotiation. In Y2, it supported reactive and proactive SLA 4

5 Component Novelty in Y3 Overall progress during the project Margin of error taken into account while monitoring. monitoring. Proactive Monitoring. PaaS Provider Registry PaaS Application Monitor IaaS Virtual Machine IaaS Energy IaaS Pricing Now it shows free slot information to know if it is possible to create a new VM without having a big impact in energy consumption. Improvements related to maintenance tasks: bug solving, and some changes in the communication protocols between the rest of intra-layer components. Also, we added extra functions for aggregating monitoring data (e.g. percentiles, max, min, median). Supporting hardware heterogeneity. Extended information provisioning (free slots). Vertical scalability. Support for Docker containers. Extended scheduling policies that consider green energy sources. Distributed File System Awareness through reallocation of power consumption from DFS based node to VMs. VM migration awareness and prediction capacity. Enhanced scale thorough, Watt meter emulation and the use of IPMI sensor data, with careful calibration. This allows power values for hosts without associated Watt meters to be used within the ASCETiC framework. Multiple providers. Vertical elasticity, horizontal elasticity. Energy provider simulator for supporting changes in energy prices. During Y1 and Y2, it only showed basic information of each of the IaaS Providers. In Y1, the basic functionality, GUI and aggregation framework was implemented. In Y2, we focused on maintenance tasks. In Y1, we focused on the basic operation of VMs and management policies (consolidation, distribution, etc.). In Y2, inter-layer selfadaptation that considers information from the Energy and Price Modelers. Initial integration of OptaPlanner as optimisation engine. It provides the historic, current and future predictions for power consumption. In Y1, its focus was on basic linear models. In Y2, it was enhanced focusing on improved accuracy with: standalone calibration, using better predictors that were not necessarily linear models and better workload specification. Scalability was improved with the introduction of the Watt meter emulator. In Y1, a basic cost function and a basic price model was implemented. In Y2, a set of more sophisticated pricing models including resource 5

6 Component Novelty in Y3 Overall progress during the project Vertical competition. usage and energy cost were implemented. IaaS Infrastructure Monitor IaaS Infrastructure IaaS SLA Stability improvements. In Y1, it monitored both infrastructure and VMs, for the VMs it was necessary to install probes inside them. In Y2, a new set of probes acting over the hypervisor removed the need to use probes inside the VMs. Also, support to get energy metrics of nodes using IPMI or Energy Emulators was added. Increased testbed stability by enhanced update, backup, and management concepts. Some additional monitoring and control features, like SDN, were added. Renegotiation. New supported terms. Margin of error taken into account while monitoring. In Y1, we had an early testbed, which fulfilled Y1 requirements regarding energy-awareness, by providing power measurements of the physical nodes. In Y2, the testbed was built from scratch taking into account lessons learned during the first operation period. Moreover, the required mechanism for the intra layer self-adaptation was provided (e.g. live VM migrations), making everything more flexible and general purpose applicable. In Y1, it supported negotiation based on VM power consumption terms. In Y2, it supported reactive SLA Monitoring. This project has received funding from the European Union s Seventh Framework Programme for research, technological development and demonstration under grant agreement no