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

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

Learning Package Overview

Problem Description

SLA Aware service infrastructures

Autonomous behavior

SLA Violation Propagation

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)

En

gin

ee

rin

g &

De

sig

n

Ad

ap

tati

on

& M

on

ito

rin

g

Business

Process

Mgement

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 …

Au

ton

om

ic

Man

ag

er

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

. . .

. . . . . .

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

Learning Package Overview

Problem Description

SLA Aware service infrastructures

Autonomous behavior

SLA Violation Propagation

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

Fault Autonomic Reaction Propagation

Physical resource

failure

New service selection SLA renegotiation with ASD

Service failure New service selection SLA renegotiation with ASD

Wrong service

response

New service selection SLA renegotiation

Broker failure New broker selection SLA renegotiation 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

Fault Autonomic Reaction Propagation

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

Learning Package Overview

Problem Description

SLA Aware service infrastructures

Autonomous behavior

SLA Violation Propagation

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

Service 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

Learning Package Overview

Problem Description

SLA Aware service infrastructures

Autonomous behavior

SLA Violation Propagation

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