S-CUBE LP: Service Level Agreement based Service infrastructures in the context of multi layered adaptation

www.s-cube-network.eu

S-Cube Learning Package

Service Level Agreement based Service infrastructures in the context of multi layered

adaptation

MTA-SZTAKI, TU Wien (TUW)

Gabor Kecskemeti, SZTAKI

© Gabor Kecskemeti

Learning Package Categorization

S-Cube

Adaptation Mechanisms

Adaptation and evolution of SBA

SLA aware autonomous Service Infrastructures

Service Level Agreements

  TODO reference to some master slide introducing the idea of SLAs

© Gabor Kecskemeti

Learning Package Overview

  Problem Description

  SLA Aware service infrastructures

  Autonomous behavior

  SLA Violation Propagation

  Conclusions

© Gabor Kecskemeti

Service infrastructure diversity - Problem area #1   Different resource models

–  Physical hosts (grid5000) –  Virtualized machines (e.g. Xen, VMWare)

–  Clusters (one click virtual clusters)

–  Platforms (Platform as a Service)

  Pricing strategies –  Free (e.g. academic grids, desktop grids)

–  Static (classical virtual private server – VPS – providers, Amazon Ec2)

–  Dynamic (e.g. Amazon spot instances)

  Available interfaces to access resources –  GRAM, EC2, Brokering (Workload Management System – WMS) …

© Gabor Kecskemeti

Cross layer monitoring & adaptation - Problem area #2   Composition and business process level adaptation decisions

do not consider Infrastructure level constraints –  Changes in the business process cannot be supported by the

infrastructure (e.g. price constraints of the user does not allow infrastructure level parallel execution even though the modified business process would require it)

  Infrastructure level adaptation contradict higher level assumptions

–  BPM layer assumes the availability of a service instance that is moved/destructed before the process would invoke it

© Gabor Kecskemeti

Infrastructure rigidness - Problem area #3   Unexpected behavior frequently passed towards higher level

components –  Resource access problems require intelligent higher SBA layers that

consider SLAs before behavior changes – e.g. new resource request could be started if the agreed SLA is not yet violated

  No fine-grained monitoring and status information to allow SLA violation prediction

–  For longer running service calls, it is hard to determine whether the call is already under processing or the infrastructure only queues it

  Service instances cannot be easily deployed in multiple infrastructures

© Gabor Kecskemeti

Objectives

  1. Hide the service infrastructure’s differences –  Generalize the access towards the various service infrastructure (e.g.

clouds, grids) implementations with a unified SLA aware interface set

  2. Support higher layers of SBAs –  Influence autonomous decisions taken at the infrastructure level by

SLAs between the functional layers of the SBA

  3. SLA oriented self-adaptation or violation propagation –  Autonomous decisions on every layer in the infrastructure layer

–  Decisions are constrained by infrastructure capabilities and future possibilities and previously agreed higher level SLAs

© Gabor Kecskemeti






  Conclusions

© Gabor Kecskemeti

Relations within the research framework

  This research mainly targets the behavior of the service infrastructure level components of the service based applications

  Adaptation and monitoring principles are used to provide autonomous behavior in service infrastructures

  SLA violation propagation allows the interfacing between the various layers of the architecture (Business process management, composition)

Engi

neer

ing

& D

esig

n

Ada

ptat

ion

& M

onito

ring

Business Process Management

Service Compo- sition

Service Infra- structure

© Gabor Kecskemeti

Connections with the S-Cube lifecycle

Evolution

Requirements Engineering

Design

Realization Deployment & Provisioning

Operation & Management

Identify Adaptation Need

Identify Adaptation Strategy

Enact Adaptation

Adaptation

SSV architecture

Support for IaaS cloud infrastructures

© Gabor Kecskemeti

SLA-based Service Virtualization architecture

Production Grids Clouds Web Services

Meta-Negotiator

Meta-Broker

Automatic Sevice Deployer

Broker Broker … A

utonomic

Manager

Service composition layer

Service infrastructure layer SLAs Violation

propagation

Adaptation & Monitoring

Ivona Brandic, Vincent C Emeakaroha, Michael Maurer, Sandor Acs, Attila Kertesz, Gabor Kecskemeti, Schahram Dustdar. "LAYSI: A Layered Approach for SLA-Violation Propagation in Self-manageable Cloud Infrastructures” – 2010 – CloudApp © Gabor Kecskemeti

S

R

S S

R

Target areas, operational steps

R R

ASD ASD ASD ASD

B B

MB

SC/BPM layer

MN

. . .

. . . . . .

Meta negotiation

SLA negotiation, assurance

Information on availability, properties

© Gabor Kecskemeti

Parties, components

  MN – Meta-Negotiator: A component/service that manages Service-level agreements. It mediates between the user and the Meta-Broker, selects appropriate protocols for agreements; negotiates SLA creation, handles fulfillment and violation.

  MB – Meta-Broker: Its role is to select a broker that is capable of deploying/executing a service with the specified user requirements.

  B – Broker: It interacts with virtual or physical resources, and in case the required service needs to be deployed it interacts directly with the ASD.

  ASD – Automatic Service Deployment: It installs the required service on the selected resource.

  S – Service: The service that users want to deploy and/or execute.

  R – Resource: Physical machines, on which virtual machines can be deployed/installed.

© Gabor Kecskemeti

Component & Objectives relations

  Meta-Negotiator –  Interacts with the Composition and BPM layers allows the specification of

SLAs that later influence infrastructure level adaptation decisions (Objective 2-3)

  Meta-Broker –  Hides the infrastructure details by offering unified access to various

resource provisioning systems (Objective 1)

  Broker –  Removes the rigidness of the underlying infrastructure by publishing

aggregated SLA related information and decides on resource outsourcing with the help of ASD (Objective 3)

  Automatic service deployment –  Independently from the currently applied infrastructure it offers

deployment capabilities of the utilized services of the SBA (Objective 3) © Gabor Kecskemeti

Connections

  Virtual campus learning package:

– SLA-based Service Virtualization in distributed, heterogenious environments (JRA-2.3, SZTAKI)

– Cross-layer Adaptation: Multi-Layer Monitoring and adaptation of Service Based Applications (JRA-1.2, FBK)

© Gabor Kecskemeti






  Conclusions

© Gabor Kecskemeti

The Autonomic Manager

 Basic autonomous operations:

–  sense state changes of the managed resources

–  invoke appropriate set of actions to maintain some desired system state

Autonomic Manager

Analysis Planning

Monitoring Execution

Knowledge

Sensor Actuator

 Possible Autonomic manager integration options: – Global (one autonomic manager for the infrastructure)

–  Local (one autonomic manager for the MN/MB/B/ASD components)

– Hybrid (mix of the above two) © Gabor Kecskemeti

Autonomous connections

© Gabor Kecskemeti

Autonomic interfaces in the infrastructure   Sensors provide the state of the service infrastructure on

three aggregation levels: individual service, provider and global infrastructure

  Negotiation interfaces enable to express the higher level requirements during renegotiation (such as negotiation protocols, SLA specification languages, security standards, resource constraints, etc.)

  Job management interfaces allow the manipulation of services during execution

  Self-Management interfaces enable the modification of the expected service instance behavior during runtime

© Gabor Kecskemeti

Self-management examples in the SSV

© Gabor Kecskemeti

Autonomic reactions and faults for SLA Negotiation

Fault Autonomic Reaction Propagation

Non-matching SLA templates

SLA Mapping -

Non-matching SLA languages

Negotiation bootstrapping -

© Gabor Kecskemeti

Autonomic reactions and faults for Meta Brokering


Physical resource failure New service selection SLA renegotiation/Redeployment with ASD

Service failure New service selection SLA renegotiation/Redeployment with ASD

Wrong service response New service selection SLA renegotiation

Broker failure New broker selection SLA renegotiation/Deployment with ASD

No service found by broker New broker selection/Deployment with ASD

SLA renegotiation

(Meta) Broker overloading Initiate new (Meta) broker deployment

SLA renegotiation

© Gabor Kecskemeti

Autonomic reactions and faults for Self-Initiated deployment


Degraded service health Service reconfiguration -

Reconfiguration fails Initiate service cloning with state transfer

Notify Broker/SLA renegotiation

Defunct service Initiate service cloning Notify Broker/SLA renegotiation

Service Decommissioned Offer proxy Notify Broker

Proxy lifetime expired Decommission proxy -

© Gabor Kecskemeti






  Conclusions

© Gabor Kecskemeti

Cross-layer adaptation Framework

•  Monitoring and correlation: reveals correlations between the observed software and infrastructure level events

•  Analysis of adaptation needs: identifies anomalous situations and pinpoints the parts of the architecture that needs to adapt

•  Identification of multi-layer strategies: generates adaptation strategies with regard to the currently available adaptation capabilities of the system

•  Adaptation Enactment: enact the corresponding part of the generated adaptation strategy

M

A

P

E

© Gabor Kecskemeti

Monitoring & Correlation #1

•  Invocation Monitor: produces low-level events through the observation of the infrastructure managed by LAYSI

•  Information Collector: aggregates and caches the actual status of the service infrastructure

© Gabor Kecskemeti

Monitoring & Correlation #2

•  Aggregator: aggregate metrics are calculated by applying their Esper event processing description

•  Dynamo/LAYSI correlator

•  Correlation data: every service call towards the infrastructure embeds (i) process name, (ii) JSDL and (iii) unique instance ID.

•  Siena publish and event bus: interconnects Dynamo[1], Laysi[2], EcoWare[3] (Correlator & Aggregator) and Adaptation needs analyzer

[1] L. Baresi and S. Guinea. Self-Supervising BPEL Processes. IEEE Trans. Software Engineering, 37(2):247–263, 2011. [2] A. Kertesz, G. Kecskemeti, and I. Brandic. Autonomic SLA-Aware Service Virtualization for Distributed Systems. In Proceedings of the 19th International Euromicro Conference on Parallel, Distributed and Network-based Processing, PDP, pages 503–510, 2011. [3] L. Baresi, M. Caporuscio, C. Ghezzi, and S. Guinea. Model-Driven Management of Services. In Proceedings of the Eighth European Conference on Web Services, ECOWS, pages 147–154. IEEE Computer Society, 2010. © Gabor Kecskemeti

Internal SLA monitoring and handling with a Layered Approach for SLA-Violation Propagation in Self-manageable Cloud Infrastructures (LAYSI)

© Gabor Kecskemeti

SLA violation propagation

SC/BPM

© Gabor Kecskemeti

SLA violation propagation

SLA violation Sensor of Autonomic Servic instance

Autonomic Manager of the current Layer

Negotiation Broker

Higher level SLA management

Dynamic binding

events: SLA violations

needs: generic and level specific knowledge base

strategy: set of services to renegotiate

  Monitoring –  Already negotiated SLAs cannot be fulfilled

  Adaptation needs engine –  Analyzes automatically the relations between the metrics to

detect their impact on the other Agreements and on the layer level SLA agreed for the current invocation

-  SI receives multiple service invocation requests with a single SLA

–  Needs: Knowledge base to support level specific SLA related decisions

  Adaptation strategy engine –  Analyzes automatically if the current SBA layer can handle

the SLA violation without propagating it to higher levels for renegotiation

  Adaptation enactment engine –  SBA Layers decide whether they can replace a service

instance with rebinding or renegotiate with upper layers

SLA renegotiation

invocations: service re-binding or SLA renegotiation

© Gabor Kecskemeti






  Conclusions

© Gabor Kecskemeti

Summary

  Service level agreements can be efficiently used for cross layer interaction

  Steps: 1.  Define an SLA in the Business process layer that contains

infrastructure level constraints

2.  Autonomously manage infrastructure until SLA is not violated

3.  Propagate the violation to the SBA layer that added the violated constraint

© Gabor Kecskemeti

Further S-Cube Reading

Kertesz, A., Kecskemeti, G., & Brandic, I. (2009). Autonomic Resource Virtualization in Cloud-like Environments. Distributed Systems Group, Institute for Information Systems, Vienna University of Technology.!

Brandic, I., Emeakaroha, V. C., Maurer, M., Dustdar, S., Acs, S., Kertesz, A., Kecskemeti G. (2010). LAYSI: A Layered Approach for SLA-Violation Propagation in Self-manageable Cloud Infrastructures. In The First IEEE International Workshop on Emerging Applications for Cloud Computing (CloudApp 2010), In conjunction with the 34th Annual IEEE International Computer Software and Applications Conference (pp. 365–370). IEEE International Workshop on Emerging Applications for Cloud Computing. !

Guinea, S., Kecskemeti, G., Marconi, A., Wetzstein, B. (2011): Multi layered Monitoring and Adaptation. In Proceedings of The 9th International Conference on Service Oriented Computing (Paphos, Ciprus) [ACCEPTED]!

© Gabor Kecskemeti

Acknowledgements

The research leading to these results has received funding from the European Community’s Seventh Framework Programme [FP7/2007-2013] under grant agreement 215483 (S-Cube).

© Philipp Leitner