Using Intelligent Agents to Discover Energy Saving Opportunities within Data Centers

Transcription

1 1 Using Intelligent Agents to Discover Energy Saving Opportunities witin Data Centers Alexandre Mello Ferreira and Barbara Pernici Dipartimento di Elettronica, Informazione e Bioingegneria Politecnico di Milano, Milan, Italy {ferreira,pernici}@elet.polimi.it Abstract Tinking about te complexity of te data center environment, tis paper explores te caracteristics of knowledgebased agents to discover energy savings opportunities witin tese dynamic systems. Te goal is to concentrate on te most significant problems wile, at te same time, create some flexibility in wic undesired metrics are acceptable in face of teir positive and negative impact analysis from an energy perspective. I. INTRODUCTION Over te last years, managing te energy efficiency of ICT (Information and Communication Tecnology) as dramatically emerged as one of te most critical environmental callenges to be dealt wit. Energy consumption and energy efficiency of ICT centers became priority due to ig computing demand and new environmental regulations. Cloud computing paradigm as been an important contributor for increasing te data centers importance, were users are always connected troug different devices. Te Greenpeace 2012 year report [6] states tat data centers are te factories of te 21st century Information age wic can consume as muc electricity as 180,000 omes. In te present work, we consider te requirements for enabling energy-efficient mecanisms in service-based systems, based on a goal-event-action adaptive approac. One of te problems tat emerges wen trying to apply adaptive mecanisms based on monitoring in tis area is tat we need to select adaptation actions in an uncertain environment, in wic event occurrences and actions to acieve goals depend on te context of execution. Looking to provide an integrated solution for reasoning about suc complex environment, tis paper focuses on te data center energy aspect. Mecanisms are described to: (I) identify potential energy saving witout compromising performance metrics and (II) reason about te best action to be taken in order to acieve desired levels of satisfaction. Te solution is mainly composed by two knowledge-based agents [18], wic are able to discover new opportunities of savings considering a partially observable and igly dynamic environment like data centers. Tis paper is organized as following: Section two introduces metrics, called indicators, for controlling performance and Copyrigt c 2013 for te individual papers by te papers autors. Copying permitted only for private and academic purposes. Tis volume is publised and copyrigted by its editors. energy related issues of an data center; section tree discusses about te problem of identifying system treats wen we are dealing wit many and eterogeneous variables; te proposed solution, an Integrated Energy-aware Framework (IEF), is described in section four; and finally section five briefly discusses some remarking points. II. INDICATORS IT equipment is te data center s core and it is composed basically by servers, network equipment, and storage devices tat are available for service-based applications (SBAs) in a loosely coupled manner. Tey are monitored by several sensors installed trougout te facility, wic provide information bot from pysical (e.g., server energy consumption) and logical layers (e.g., web-service response time). Suc data represent levels of satisfaction wen we use tem to calculate performance and energy indicators. Tey are defined in terms of tresolds, wic can trigger alarming or warning alerts wen teir limits are not respected. Wen it appens, repairing actions are selected and enacted in order to restore desired levels of satisfaction. Suc elasticity is only possible wen tere is a compreensive view of te system, in wic te different elements relationsips are stipulated and alerts are properly signed as system treats. In tis section we describe tese indicators and ow tey can be used to identify system treats. An indicator is defined as a metric tat provides information about te status of te underlying system and is created according to te meta-model described in Figure 1. Te abstract class Indicator defines bot quality and energy related indicators wic are identified by te attribute type. Te attribute importance is based on te user s preferences and it dictates te indicator priority in case of multiple violations. Te indicator violation is defined by te Tresold class, wic is composed by two lower-bounds, minalarm (a min ) and minwarning (w min ), and two iger-bounds, maxalarm (a max ) and maxwarning (w max ). Indicators alarming tresolds represent critical boundaries tat sould not be violated in order to keep te system soundness. On te oter and, warning tresolds are less critical as teir violation can be accepted (altoug not desired). Tus, warning tresolds can be seem as te system elasticity, wic are used to keep te majority of te indicators outside te alarming zones. An indicator is not violated, i.e. green, wen its

2 2 current value is witin bot warning and alarming boundaries. Oterwise, we can ave warning or alarming violation. In te first case, yellow, indicator values are between te warning and alarming tresolds. In te second case, red, te indicator value violates bot warning and alarming tresolds. It sows an unacceptable situation of one or more system components. Alarming indicators ave priority to be solved wit respect to warning ones as tey can cause iger damage to te system. Te current indicator situation (green, yellow or red) is represented by te attribute status. Te indicator last attribute, acceptance, defines te accepted interval in wic an indicator can stay in a violated state (warning or alarming violation) witout requiring adaptation. Tis attribute is important in order to avoid unnecessary adaptation enactment, were te violation is temporary and migt not require adaptation. For instance, let us suppose tat te action VM migration may violate te indicator availability of an application. In tis example, te acceptance attribute sall dictate te maximum time interval allowed for wic te indicator availability can stay violated witout triggering a new adaptation action, i.e., te maximum amount of time te VM migration action can take witout causing a new side-effect. Te indicator value is obtained troug te indicator formula calculation, wic uses te information provided by te monitoring system, wic is composed by several sensors. Indicators are divided in basic and composed. An indicator is called as basic (BasicIndicator class) wen its calculation formula is eiter a direct measure from te monitoring system variable or a combination of several monitoring variables witin a formula. Instead, composed indicators (ComposedIndicator class) formulae use oter basic indicators as input. Tey do not use oter composed indicators in order to avoid infinity recursive compositions. Fig. 1. Arcitectural layer StoredValues toringmetric 1 1 Indicators meta-model. 0..* * 1 Indicator +Name +Type +Importance +Status +Acceptance Basic Indicator 1..* +Formula 1 * * 1 1..* Composed Indicator +CompositionMetric Tresolds +minalarm +minwarning +maxwarning +maxalarm Green Performance Indicators : Focusing on te design of SBAs, energy consumption can be constantly monitored by specific indicators called Green Performance Indicators (GPIs) [12], [10]. Te aim is to guarantee te satisfaction of energy requirements, specified on tese GPIs, togeter wit te more traditional functional and non-functional (i.e., QoS) requirements. In order to properly design energy-aware applications, it is fundamental to consider te relationsip olding between te structure of an application and te energy consumed by te underlying infrastructure wic is executing tis application. III. THE PROBLEM OF THREATS IDENTIFICATION Once indicators are defined and teir value calculated, te system sall be able to recognize wic ones represent system treats, i.e., wic ones can arm te system. In tis way, an isolated indicator violation does not represent necessarily a system treat. Te identification of system treats introduces new complexity boundaries to te approac, wic need to be selective in mining te monitored data in order to identify relevant information to support te decision making mecanisms. Tese treats are identified troug timed event occurrences, wic can appear witin four different scenarios. In tese scenarios, an event occurrence is associated wit te execution of adaptation actions or indicators violations, wic occur witin defined time windows. Te scenarios are: I - Te adaptation action is not effective and event occurrences are created following te same pattern. II - Te adaptation action is temporary effective, solving te problem during a sort time interval wic defines te action approval period. In tis scenario, te same event occurrence comes back witin te action approval period wic means tat te enacted action was not suitable to eliminate te treat and a different solution sould be taken. III - Te adaptation action is fully effective to solve te identified treat. However, its execution generates non expected side-effects, creating a completely new treat. Tis scenario is quite dangerous as it may create an infinity cycle of action enactment and treat creation. IV - Te adaptation action seems to be fully effective, but te same treat appears again after some time. Differently from scenario II, in tis scenario te time gap is quite long and te treat appears in tis first event occurrence. In order to make clear te difference between te last tree scenarios, let us consider a flat tire example. After te identification of te problem, one possible action to solve te problem is filling te tire wit air. If te reason of te problem is a tire ole, tis action is not effective since te tire will be flat again in few minutes or ours. Tis situation is represented in Scenario II. Instead, if anoter action is cosen, suc as replace te tire, different events can be raised due to te enactment of te action. In te example, te events car unstable (due to inadequate spare tire) or drive not safe (due to te lack of available spare tire witin te car) can be raised. Tis situation is represented in Scenario III. Even if te tire replacement effectively solves te problem, it does not prevent tat a new ole appears in te future (Scenario IV). A more detailed analysis wit respect to an adaptation action feedback and te implications of failed actions is described in te following section.

3 3 IV. INTEGRATED ENERGY-AWARE FRAMEWORK As described in te previous section, indicators violation may represent system treats tat ave to be eliminated for te system soundness. Te treat elimination is represented by te enactment of combined adaptation actions tat bring positive and negative impact to te overall system. In order to identify tese system treats and to select te best set of adaptation actions to be executed, we use a knowledge-based agent approac. In tis section we detail all te elements present in an Integrated Energy-aware Framework (IEF), wic are responsible for identifying and eliminating treats tat may compromise te system. Figure 2 sows te main elements tat compose te proposed framework. First, te runtime and monitoring system provides raw data about te underlying environment. Tis information is used to calculate te defined indicators by te indicator calculation module. Te first agent, Agent 1, is responsible to verify bot monitored variables and indicators values in order to recognize possible situations tat represent a treat to te overall system. If a treat is identified, te agent creates several event occurrences tat are analyzed by te second agent, Agent 2, looking to separate te different types of events and, in particular, te ones tat require te enactment of adaptation actions (meaningful events). To do so, bot agents inference rules are based on te system knowledge base, wic contains current monitored data and all past experiences. As new information is arriving, te knowledge base is constantly updated by bot inference engines. Tese canges impact on bot te conceptualization of system treats and te selection of adaptation actions. Finally, te adaptation parameterization module is responsible to approve or to disapprove te selected adaptation actions by te system manager and, if approved, e sould provide te necessary actions parameters values. Fig. 2. Agent 1 Knowledge base Inference engine 1 A. Agent 1 Framework overview Inference engine 2 Indicators values Prior knowledge Agent 2 Indicator calcula on Monitoring data Adapta on set Monitoring data System Manager Supervise Adapta on parameteriza on Enable Run me and monitoring Based on te monitored data and te indicator calculated values, Agent 1 recognizes tree different levels of treats, wic migt or migt not result in te creation of an event occurrence. An event occurrence represents an event tat is currently arming one or more indicators fulfillment and, terefore, adaptation actions sall be enacted in order to restore desired levels of satisfaction. Te creation of an event occurrence is based on te underlying environment, wic is represented by te instantiation of some context rules. Due to te spread usage of te word context and to avoid misunderstandings, we adopt te context definition provided by [2]: context is a partial state of te world tat is relevant to an actor s goals, were world is te agent underling environment captured by te monitoring system, actor is te agent itself and goals represent te indicators satisfaction. Defined by assert predicates in first-order logic, te context is important to limit te agent observation scope and to clarify te impact relations polarity (positive/negative). Tis agent PEAS description is: Performance: Number of warning and alarming indicators violation; Environment: Indicators levels identified as yellow, orange and red; Actuators: Identification of tree levels of system treats and creation of event occurrences; Sensors: Indicators value and tresolds. 1) Treats identification: Considering tat data is continuously produced by te monitoring system, te agent is responsible to recognize situations tat migt treaten te indicators fulfillment. In order to deal wit suc a uge bunc of data rapidly, we adopt Stream Reasoning tecniques proposed by [4] were streams generated by te monitoring system are represented as materialized views of RDF 1 triples. Tese views are based on deductive rules and eac triple is associated wit an expiration time. Data streams are defined as unbounded sequences of time-varying data elements [1] and te proposed solution manages to inspect continuous data streams. Differently from oter types of data, streams are consumed by queries registered into a stream processor, tat continuously produce answers. A common and important simplification applied by stream engines is tat tey process information witin windows, defined as periods of time slots in wic te flowing information sould be considered. Suc windows are continuously evolving due to te arrival of new data in te stream, wereas data falling outside of te windows is lost, in oter words, it expires. Te window size defines te stream expiration time wic represents te triple arrival timestamp plus te window size, assuming te window size to be constant (time-invariant). We also assume time as a discrete and linear ordered variable parameter. Terefore, if te window is defined as 3 time slots long and a time slot is 5 seconds long, a triple entering at time τ will expire at time τ + 15s. Te expiration time of derived triples depends on te minimum expiration time of te triples it was derived from. Considering te current materialized predicates window, te event identification module derives different levels Raised events of treat in order to raise an event based on te a set of rules. A treat is identified if one or more indicators are violated wit 1 Resource Description Framework (RDF) is a W3C recommendation for resource description [11]

4 4 respect to teir warning and alarming tresolds. An indicator violation represents te first level of a treat, wic migt or migt not raise an event based on te indicator alarming violation duration. Tis means tat, a single indicator violation migt not represent an ongoing system problem tat requires an adaptation action. For example, during te VM migration action, te application availability indicator may be violated. However, if te migration action is executed normally, i.e., te VM is successfully migrated witout errors, te application availability violation does not require an adaptation action and, terefore, an event occurrence sould not be created. Te identification of an indicator violation is represented by te creation of te following entailment: Status(i, yellow ) i.value Y / T Y = ([a min, a max ](t) \ [w min, w max ](t)) t=1 Status(i, red ) i.value R / T R = U \ [a min, a max ](t) t=1 were i.value is te calculated value of indicator i and U is te set of all possible values te indicator can assume and, terefore, v U. Te set of values tat does violate te indicator s warning tresolds (max or min) is defined as Y. In te same manner, R represents te set of values tat violates alarming (max or min) tresolds, in wic (Y R ) U. Finally, T represents tresolds sets of i were t defines te tresolds dimensions {a min, w min, v, w max, a max } suc. tat a min w min w max a max Te second level of a treat tries to identify warned violated indicators (yellow) tat are likely to become alarmed violated indicators (red). We represent tese indicators as orange ones. Te identification of an orange indicator is similar to te identification of yellow ones, but narrowing alarming tresolds. Let us consider tat W represents te set of triples of i suc tat warning tresold (min or max) is violated. Te alarming tresolds are narrowed based on W standard deviation σ (R ). Te calculation of σ(w ) is 1 N (1) N (x n µ) 2 were n=1 N is te number of triples in W. As we aim only te triples tat violate te narrowed alarming tresolds but do not violate te normal alarming tresolds, we ave R Y. Tus, an indicator status is defined as orange according to te following: Status(i, orange ) i.value R Y / T R = U \ [a min + σ(w ), a max σ(w )](t) t=1 (2) Finally, te tird level of treat actually raises an event after we ave identified indicators as red or orange. However, differently from te first level of treat, te violation lasts more tan it is accepted by te system. Te indicator alarming violation is linked wit an acceptance value acp, measured in number of monitored time slots te indicator can stay violated witout te enactment of adaptation action. As eac triple is associated wit a timestamp, te calculation of te violation duration is obtained by subtracting te timestamp of te last triple by te first one. Considering tat V is te set of indicators wit eiter red or orange violation, it is calculated te violation duration by MaxT ime(v ) MinT ime(v ), were M axt ime() returns te last violated triple window and MinT ime() returns te first violated triple window. Tus, an event occurrence is created wen te following expression olds: MaxT ime(v ) MinT ime(v ) > acp / v V : Status(v, red ) Status(v, orange ) 2) Creation of event occurrences: Te creation of a new event occurrence ec i,j EC i means tat event e i E is raised, were EC i is te set of occurrences of event e i. Event occurrences are created by te event occurrence module. Tey are defined by te following attributes: timetsamp, value, window, direction, significance, severity, were: Timestamp: it is te timestamp of te RDF triple tat triggers ec i,j creation. Value: it is te monitored variable value of te RDF triple tat triggers ec i,j creation. Window: it represents te window in wic te RDF triple tat triggers ec i,j is placed. Direction: it dictates if te obtained value is increasing or decreasing based on tresold violation, i.e., max or min. Tis information is important in order to support te adaptation action selection pase. Significance: it is a value between [0..1] resulted from two variables: variable significance and normalized variable value based on te indicator tresolds. Te significance is important (togeter wit impact) to define wic event occurrences ave priority to be eliminated by te adaptation actions. Severity: tis attribute defines quantitatively te severity level of event occurrence ec i,j over one or more goals. Algoritm 1 details te process of creating a new event occurrence ec i,j. Te algoritm input parameter is te RDF triple t k tat satisfies Eq.3, i.e., an indicator alarming violation wit longer duration tan it is accepted. Algoritm 1 Creating new event occurrences Require: t k 1: i getind(t k ) 2: W getvtriples(t k, i ) 3: g p getgoal(i ) 4: E impact e i E : e i g p 5: for all e i E do 6: emc i σ emci.event=e i (ECM) 7: for all neg effect j emc i.negeffect do 8: ctx getcontextvalues(neg effect j) 9: if ceckcondrule(ctx,neg effect j) ten 10: ec i,j new EC(e i, i, neg effect j) 11: end if 12: end for 13: end for Te first step is to find out te set of triples tat represent red or orange violations, according to Eq. 3. Tis is done by function getvtriples() (line 2), wic retrieves te set (3)

5 5 of triples W = i ind:value v. Goals (G) are defined as indicators tresolds and events (E) in terms of monitored variables. If te calculation of an indicator value depends on more tan one variable, it means tat one goal is impacted by more tan one event. Tus, we need to identify te event e i E, were E E represents te set of candidates events to be raised due to i violation. In order to create E we need to identify te goal g p tat represents te violated indicator tresold i troug te function getgoal() (line 3). Based on g p we select all events tat old impact relationsip like e i g p (line 4). Te identification te rigt event tat is triggering te indicator violation is based on te event context-model and, terefore, we need to select te event context-models wit respect te event candidates E (lines 5-6). An event context-model emc i may ave several positive and negative effects context (line 7). Terefore, an event is raised wen negative conditional context rules old (line 9-10), wic are based on current context variable values (line 8). Note tat an indicator violation can raise more tan one event and, eac event can create one or more event occurrences, depending on te defined event context conditional rules. B. Agent 2 Wenever event occurrences are identified and raised by Agent 1, te system sall be able to recognize events relationsips and properly enact corrective actions. Tis is done by Agent 2, wic analyzes situations wen one event is caused by anoter troug te enactment of its related adaptation action. By knowing tese relationsips, te agent drives te system adaptive beavior. Agent 2 PEAS description is: Performance: Number of raised event occurrences; Environment: Current and previous materialized windows; Actuators: Analysis of triggered adaptation actions (AdaptationRequired, OngoingAdaptation, Adaptation- Completed, AdaptationStillRequired and AdaptationEffective) and selection of new ones; Sensors: Event occurrences, event status and enacted actions witin materialized windows. 1) Event analysis: Te existence of raised events troug event occurrences indicates tat adaptation actions ave to be enacted. However, we argue te approac sould be able to identify te different raised events in order to support te adaptation action selection. Tere are five different status transitions wic te relation status can represent: (i) Ready, ec i,j as no relation wit past ones; (ii) new, an adaptation was not yet selected; (iii) wip (work in progress), tere are actions under execution; (iv) done, all actions are set as finised ; and (v) renew, new ec i,j regarding to te same event during te approval period. Te detailed description of te rules used in te states transitions are expressed as follows: AdaptationRequired r1 a : W + (Status(e i, new )) :- W before (Status(e i, ready )), W ins (Occur(e i, ec i,j) AdaptationStillRequired r2 a : W + (Status(e i, renew )) :- W before (Status(e i, done )), OngoingAdaptation W ins (Occur(e i, ec i,j)), W(Enact(a v, finised )) r3 a : W + (Status(e i, wip )) :- W before (Status(e i, new )), W ins (Occur(e i, ec i,j)), W(Enact(a v, finised )) r3 b : W + (Status(e i, wip )) :- W before (Status(e i, wip )), W ins (Occur(e i, ec i,j)), W(Enact(a v, finised )) r3 c : W + (Status(e i, wip )) :- W before (Status(e i, renew )), AdaptationCompleted W ins (Occur(e i, ec i,j)), W(Enact(a v, finised )) r4 a : W + (Status(e i, done )) :- W before (Status(e i, wip )), W ins (Occur(e i, ec i,j)), W(Enact(a v, finised )) r4 b : W + (DoneAt(e i, τ) :- W +( (Status(e i, done )),?τ ) AdaptationEffective r5 a : W + (Status(e i, ready )) :- W before (Status(e i, done )), W(DoneAt(e i,?donet ime), (Approval(e i,?approvalp eriod)), now()?donet ime >?approvalp eriod were?time represents te current timestamp. In addition, te rules are based on te following materialized windows: W is current materialized window, W + contains te derived triples to be added in W, W before represents te previous materialized window, and W in represents te new triples tat are coming from te event identification module, i.e., event occurrences or monitored variables values. Adaptation actions are required only for raised events tat old eiter new or renew status. 2) Adaptation selection: Wen tere are event occurrences ec i,j identified as new or renew by te relation Status, te adaptation selection is triggered. Actions are combined in order to create an adaptation strategy, wic is a composed by a set of coordinated adaptation actions, i.e., actions tat are executed in sequence and/or parallel (coordination). It can appen tat tis set is composed by only one action, so it does not require any coordination. An adaptation action is described by te following attributes: Type identifies if te action consequence is regarding functionality/quality reduction or resource reallocation; Duration is a time interval attribute tat specifies te expected time interval, in terms of maximum and minimum, tat te action takes to complete its execution; Cost is an interval attribute tat represents te expected cost of te action execution and migt depend on te action parameters defined by te system manager in te adaptation parameterization module; ApprovalPeriod is te expected time interval defined to validate te action effectiveness; AvailabilityCond represents te set of conditional rules tat sould be satisfied in order to enable te action

6 6 execution; TriggerCond also represents a set of conditional rules, but it describes triggering conditions tat can be eiter reactive or proactive; Group identifies te action group from an energy perspective; and finally Action is te adaptation action implementation, i.e., wat te action sould do. Considering tese attributes, Agent 2 selects te most suitable set of adaptation actions looking to eliminate event occurrences tat are causing indicators violation. Five steps are used to do so. Te first step (Step 1) identifies te incoming event occurrences tat did not trigger adaptation yet. Tis identification is based on te event status attribute. Te next step (Step 2) aims to cut off te list of existing adaptation actions in order to keep only te available and suitable ones. In te first case, available actions, we use te action s availability conditional rules. Tese rules are connected to single BPs tat were previously designed to execute te action. For instance, te adaptation action skip task can be enacted if and only if te task is defined as optional task, i.e., te task is not critical. In te second case, suitable actions, we use te actions triggering conditions attribute in order to rule out actions from te list tat were not designed to stop te incoming event occurrence. Eac adaptation action is associated wit events (event-trigger) or indicators violation (indicator-trigger) and, depending on te event occurrence, we keep only te actions tat are directly or indirectly related to eac oter troug an indicator violation, wic is represented by contribution relations witin te goalbased model. Having te subset of actions provided by Step 2, te next step (Step 3) determines te optimal set of actions tat are supposed to stop te arrival of new event occurrence wit minimal side-effects. Tis step can be divided into four substeps, wic are: i An indicator violation may represent a violation of oter indicators tat compose te first one. Tus, te aim of tis sub-step is to find te indicatorsbase tat ave been violated. Tis is done troug and/or decomposition relationsips among indicators witin te goal-based model; ii Searc for previous situations in wic te current treat was identified and, most important, wat adaptation strategies were selected wit teir obtained results; iii A verification process estimates eac action effects, bot positive and negative. Te actions tat propagate more negative effects tan positive or do not satisfy minimal duration time or cost are ruled out of te candidate set. After we ensure tat all quality and energy constraints are satisfied, Constraint Satisfaction Optimization Problem is used; iv Finally, te selection of te adaptation actions and teir coordination are performed by te algoritm proposed in [5] performed by te Energy-aware controller. Te controller gaters te necessary context information to establis te actions parameters range according to te underlying ardware and software specification. Once te set of adaptation actions is created, tese actions need to be properly coordinated (wen tere is more tan one action involved) in order to compose an adaptation strategy. Tis is done in Step 4, in wic input and output parameters of eac action are cecked in order to identify immediate sequence and parallel patterns. Based on tat, te attributes TotalDuration and TotalCost can be calculated. Te total duration time is particularly sensible to te adopted flow pattern, sequence or parallel, for te actions execution. If te total duration time or cost exceed teir constraints, te process returns to te previous step. Oterwise, te next step (Step 5) sends te created adaptation action to te adaptation parameterization module, in wic te system manager sall validate te initially suggested actions parameters. V. RELATED WORK A. Green business process metrics Starting from general software engineering metrics, Kaner and Bond [7] delineate a framework for evaluating software metrics regarding to teir purpose, scope, calculation formula, value meaning, and teir relationsips. In te approac, a metric is generally defined as te empirical, objective assignment of numbers, according to a rule derived from a model or teory, to attributes of objects or events wit te intent of describing tem. Distinctively from software engineering metrics, te introduced metrics evaluate BP design attributes and masup applications performance and energy parameters during its execution. In order to automatically identify te KPI relations and extract teir potential influential factors, Popova and Sarpanskyk [15] formalize te concept of performance indicator and teir internal (between indicators) and external (indicators and processes) relationsips. However, te relation wit external concepts (suc as process) does not specify te process instance. Runtime variables may cause ambiguous values interpretation of te same process aving two or more instances. Tis problem is partially solved by Rodriguez et al. [17] approac tat quantifies relationsips in te performance measurement system context (QRPMS). Tis is done by defining te relationsips among KPIs and mapping tem wit Performance Measurement System (PMS) in order to create cause-effect relations at business goals level. Te relationsips between performance indicators are identified by applying two matematical tecniques over te data matrix. Te first, principal component analysis (PCA), recognizes cause-effect relations based on eac indicator description. Te KPIs tat contain cause-effect relations are named Business Drivers Key Performance Indicators (BDKPI) because of teir ig factor of impact wit respect te oters. Te second tecnique, partial least squares models, quantifies te importance degree of eac identified cause-effect relation. Tese models are represented by typical regression equations tat predict effect(s) from cause(s) variable(s), called PLS models, wic is igly based on te designer expertise. Taking into consideration te green aspects of te BPs, Nowak et al. [14] introduce te green Business Process Reengineering (gbpr) metodology in order to tackle existing SBAs and energy consumption issues from a olistic approac witin modern data centers. Te autors introduce te Key Ecologial Indicators (KEIs), wic are special types

7 7 of performance indicators to measure up business process greenness. Te approac relies on impact of te process execution decisions into te company s business goals. For instance, to reduce te KEI CO 2 emission of a sipping process, te solution adopted is to reduce te number of times per day te sipper picks up te carge from tree to one. Instead, te CO 2 emission wit respect to te IT resources used to execute te BP is not taken into consideration. B. Service-based application self-adaptation frameworks Service-based Applications are caracterized by independent services tat, wen composed, perform desired functionalities [19]. In general, tese services are provided by tird parties and are utilized by different applications. Tus, SBAs operate in a eterogeneous and constantly canging environment. Tus, tey ave to be able to constantly modify temselves in order to meet agreed functional and quality constraints in face of a raised problem or an identified optimization or an execution context cange [8]. In te ambit of service oriented computing (SOC), application adaptive features play an even more important role. Considering more compreensive approaces, SBA adaptation frameworks deal wit large different types of service adaptations and, in particular, propose an integrated view from te infrastructure to te application layer [3], [9], [16]. Tese frameworks dynamic adapt SBAs from bot structural and beavioral aspects by taking into account software and ardware canges. Te PAWS (Process wit Adaptive Web Services) framework proposed by [3] divides service adaptation issues in process design (design-time) and execution (runtime) pases. Te importance of process design pase is empasized as it actually enables autonomous service adaptation at runtime. Focusing on te interrelationsips among te different adaptation actions, [9] present a cross-layer SBA adaptation framework. Te aim of te approac is to align te adaptation actions and monitored events from te different layers in order to obtain more effective adaptation results. Tree layers are taken into consideration: BPM (business process management composed by te business process workflow and KPIs), SCC (service composition and coordination composed by service compositions and process performance metrics - PPM) and SI (service infrastructure composed by service registry, discovery and selection mecanisms). Te key point made by te autors regarding to teir framework is tat it takes into consideration te dependencies and effects of suc actions witin te tree different layers. First, tey tackle te lack of alignment of monitored events suc tat events and teir mecanisms ave to be related in a cross-layer manner. It enables teir correlation and aggregation. Second, te lack of adaptation effectiveness is filled by providing a centralized mecanism able to aggregate and to coordinate different adaptation actions tat are triggered by te same event. Tird, te lack of adaptation compatibility, wic means to identify adaptation necessities across layers by identifying te source of te problem tat generated te event. Finally, te lack of adaptation integrity is dealt in terms of foreseeing results. It means to assess weter te selected adaptation actions are enoug to acieve te desired results and ow many times tey need to be enacted. Mirandola and Potena [13] framework also considers dynamic service adaptation based on optimization models in order to minimize adaptation costs and enforce QoS aspects. Te necessity for adaptation is assessed troug a contextaware self-adaptation mecanism tat captures required data about te environment and triggers appropriate adaptation actions. Te novelty of te framework relies on te fact tat it andles bot software and ardware adaptation from functional and non-functional requirements perspectives. In addition, te framework optimization model is flexible as it is independent from te adopted metodology or arcitectural model. In a similar way, Psaiser et al. [16] present VieCure framework. Te framework focuses on unpredictable and faulty beavior of service into a mixed system of Service-based Systems (SBSs) and Human-provided Services (HPSs). Feedback loop functions are used to provide te framework self-adaptation and beavior monitoring features troug a MAPE-k cycle (Monitor, Analyze, Plan, Execute, and Knowledge). Te monitoring components are responsible to gater and to store information about different systems, mixed systems, regarding to te infrastructure, application activities, and QoS. Te aggregation of suc information is terefore presented as events tat trigger te diagnosis and analysis component. Tese components define te required recovery actions by analyzing istorical failure data sources. VI. CONCLUDING REMARK Te solution described in tis paper presents an integrated mecanism to identify and to reason about energy savings opportunities witin complex environments suc as data centers. It takes into consideration several aspects of a partially observable environment using knowledge-based agents. Simulated results ave being performed in order to evaluate te agent beavior under stressed situations and are expected to be publised in te future. A similar solution is also under evaluation wic is based on a goal-based model instead of agents. Acknowledgment. Tis work as been partially supported by te GAMES project (ttp:// and Eco2Clouds EU Project (ttp://eco2clouds.eu), wic are partially funded by te European Commission under te 7t Framework Program grant agreement numbers and , respectively. Tis work expresses te opinions of te autors and not necessarily tose of te European Commission. Te European Commission is not liable for any use tat may be made of te information contained in tis work. REFERENCES [1] C. C. Aggarwal. Data Streams: Models and Algoritms (Advances in Database Systems). Springer-Verlag New York, Inc., Secaucus, NJ, USA, [2] R. Ali, F. Dalpiaz, and P. Giorgini. A goal-based framework for contextual requirements modeling and analysis. Requirements Engineering, 15(4): , November 2010.

8 8 [3] D. Ardagna, M. Comuzzi, E. Mussi, B. Pernici, and P. Plebani. PAWS: A framework for executing adaptive web-service processes. IEEE Software Magazine, 24(6):39 46, November [4] D. F. Barbieri, D. Braga, S. Ceri, E. Della Valle, and M. Grossniklaus. Incremental reasoning on streams and ric background knowledge. In Proc. of te 7t International Conference on Te Semantic Web: researc and Applications - Volume Part I, ESWC 10, pages 1 15, Berlin, Heidelberg, Springer-Verlag. [5] C. Cappiello, M. Fugini, A. Ferreira, P. Plebani, and M. Vitali. Business process co-design for energy-aware adaptation. In Proceedings of 4t International Conference on Intelligent Computer Communication and Processing, ICCP 11, pages IEEE, Aug [6] G. Cook. How clean is your cloud? Report, Greenpeace International, April ttp:// Campaign-reports/Climate-Reports/How-Clean-is-Your-Cloud/. [7] C. Kaner and W. P. Bond. Software engineering metrics: Wat do tey measure and ow do we know? In Proc. of te 10t International Software Metrics Symposium, METRICS 04, [8] R. Kazamiakin, S. Benbernou, L. Baresi, P. Plebani, M. Ulig, and O. Barais. Adaptation of service-based systems. In M. Papazoglou, K. Pol, M. Parkin, and A. Metzger, editors, Service Researc Callenges and Solutions for te Future Internet, volume 6500 of Lecture Notes in Computer Science, pages Springer Berlin / Heidelberg, [9] R. Kazamiakin, M. Pistore, and A. Zengin. Cross-layer adaptation and monitoring of service-based applications. In Proc. of te 2009 international conference on Service-oriented computing, ICSOC/ServiceWave 09, pages , Berlin, Heidelberg, Springer-Verlag. [10] A. Kipp, T. Jiang, M. Fugini, and I. Salomie. Layered green performance indicators. Future Gener. Comput. Syst., 28(2): , Feb [11] F. Manola and E. Miller. Rdf primer. ttp:// February [12] A. Mello Ferreira, B. Pernici, and P. Plebani. Green performance indicators aggregation troug composed weigting system. In Proc. ICT as Key Tecnology against Global Warming, volume 7453 of Lecture Notes in Computer Science, pages Springer Berlin / Heidelberg, September [13] R. Mirandola and P. Potena. A QoS-based framework for te adaptation of service-based systems. Scalable Computing: Practice and Experience, 12(1):63 78, [14] A. Nowak, F. Leymann, and R. Mietzner. Towards green business process reengineering. In Proceedings of te 2010 International Conference on Service-oriented Computing, ICSOC 10, pages , Berlin, Heidelberg, Springer-Verlag. [15] V. Popova and A. Sarpanskyk. Modeling organizational performance indicators. Information Systems, 35(4): , June [16] H. Psaier, F. Skopik, D. Scall, and S. Dustdar. Beavior monitoring in self-ealing service-oriented systems. In Proc. of te 34t IEEE Annual Computer Software and Applications Conference, COMPSACW 10, pages , July [17] R. R. Rodriguez, J. J. A. Saiz, and A. O. Bas. Quantitative relationsips between key performance indicators for supporting decision-making processes. Computers & Industrial Engineering, 60(2): , February [18] S. J. Russell and P. Norvig. Artificial intelligence - a modern approac: te intelligent agent book. Prentice Hall series in artificial intelligence. Prentice Hall, [19] S-Cube Partners. State of te art report on software engineering design knowledge and survey of HCI and contextual knowledge. Deliverable JO-JRA-1.1.1, S-Cube Network of Excellence, July 2008.