1. 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
www.s-cube-network.eu

2. Learning Package Categorization
S-Cube
Adaptation Mechanisms
Adaptation and evolution of SBA
SLA aware autonomous
Service Infrastructures
© Gabor Kecskemeti

3. Learning Package Overview
 Problem Description
 SLA Aware service infrastructures
 Autonomous behavior
 SLA Violation Propagation
 Conclusions
© Gabor Kecskemeti

4. 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

5. 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

6. 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

7. 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

8. Learning Package Overview
 Problem Description
 SLA Aware service infrastructures
 Autonomous behavior
 SLA Violation Propagation
 Conclusions
© Gabor Kecskemeti

9. Relations within the research framework
 This research mainly targets
the behavior of the service
infrastructure level components
of the service based
Adaptation & Monitoring
Engineering & Design
applications
Business
Process
 Adaptation and monitoring Mgement
principles are used to provide
autonomous behavior in service Service
Compo-
infrastructures sition
 SLA violation propagation Service
Infra-
allows the interfacing between structure
the various layers of the
architecture (Business process
management, composition)
© Gabor Kecskemeti

10. Connections with the S-Cube lifecycle
SSV architecture
Identify
Adaptation Requirements
Need Operation & Engineering
Management
Identify Design
Adaptation
Strategy Adaptation Evolution
Deployment &
Enact Provisioning Realization
Adaptation
Support for IaaS cloud infrastructures
© Gabor Kecskemeti

11. SLA-based Service Virtualization
architecture
Service composition layer
SLAs Violation
propagation
Service infrastructure layer
Meta-Negotiator
Manager
Autonomic
Meta-Broker
Broker … Broker
Automatic Adaptation
&
Sevice Monitoring
Deployer
Production Grids Web Services Clouds
Ivona Brandic, Vincent C Emeakaroha, Michael Maurer, Sandor Acs, Attila Kertesz, Gabor Kecskemeti, Schahram Dustdar.
© Gabor Kecskemeti "LAYSI: A Layered Approach for SLA-Violation Propagation in Self-manageable Cloud Infrastructures” – 2010 – CloudApp

12. Target areas, operational steps
SC/BPM layer
Information on
availability, properties
MN
MB
...
B B
SLA negotiation,
assurance
... ...
ASD ASD ASD ASD
S S
R
R S
R
R
© Gabor Kecskemeti

13. 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

14. 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

15. 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

16. Learning Package Overview
 Problem Description
 SLA Aware service infrastructures
 Autonomous behavior
 SLA Violation Propagation
 Conclusions
© Gabor Kecskemeti

17. The Autonomic Manager
Autonomic Manager
 Basic autonomous
Analysis Planning
operations:
– sense state changes of the Knowledge
managed resources
Monitoring Execution
– invoke appropriate set of
actions to maintain some Sensor Actuator
desired system state
 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

18. Autonomous connections
© Gabor Kecskemeti

19. 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

20. Self-management examples in the SSV
© Gabor Kecskemeti

21. Autonomic reactions and faults for SLA
Negotiation
Fault Autonomic Reaction Propagation
Non-matching SLA SLA Mapping -
templates
Non-matching SLA Negotiation bootstrapping -
languages
© Gabor Kecskemeti

22. Autonomic reactions and faults for Meta
Brokering
Fault Autonomic Reaction Propagation
Physical resource New service selection SLA renegotiation with ASD
failure
Service failure New service selection SLA renegotiation with ASD
Wrong service New service selection SLA renegotiation
response
Broker failure New broker selection SLA renegotiation ASD
No service found by New broker SLA renegotiation
broker selection/Deployment
with ASD
(Meta) Broker Initiate new (Meta) SLA renegotiation
overloading broker deployment © Gabor Kecskemeti

23. Autonomic reactions and faults for Self-
Initiated deployment
Fault Autonomic Reaction Propagation
Degraded service health Service reconfiguration -
Reconfiguration fails Initiate service cloning with Notify Broker/SLA
state transfer renegotiation
Defunct service Initiate service cloning Notify Broker/SLA
renegotiation
Service Decommissioned Offer proxy Notify Broker
Proxy lifetime expired Decommission proxy -
© Gabor Kecskemeti

24. Learning Package Overview
 Problem Description
 SLA Aware service infrastructures
 Autonomous behavior
 SLA Violation Propagation
 Conclusions
© Gabor Kecskemeti

25. Cross-layer adaptation
Framework
M
A
P
E
• Monitoring and correlation: reveals • Identification of multi-layer strategies:
correlations between the observed generates adaptation strategies with
software and infrastructure level events regard to the currently available
adaptation capabilities of the system
• Analysis of adaptation needs: identifies
anomalous situations and pinpoints the • Adaptation Enactment: enact the
parts of the architecture that needs to corresponding part of the generated
adapt adaptation strategy
© Gabor Kecskemeti

26. 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

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

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

29. SLA violation propagation
SC/BPM
© Gabor Kecskemeti

30. SLA violation propagation
SLA Violation Sensor of Autonomic
Service instance  Monitoring
– Already negotiated SLAs cannot be fulfilled
events: SLA
violations
Autonomic
 Adaptation needs engine
Manager of – Analyzes automatically the relations between the metrics to
the Current detect their impact on the other Agreements and on the layer
Layer level SLA agreed for the current invocation
- SI receives multiple service invocation requests with a single SLA
needs: generic and level specific knowledge base
– Needs: Knowledge base to support level specific SLA related
decisions
Negotiation
Broker
 Adaptation strategy engine
strategy: set of services to renegotiate – Analyzes automatically if the current SBA layer can handle
the SLA violation without propagating it to higher levels for
renegotiation
Higher Level
SLA
Management  Adaptation enactment engine
invocations: service re-binding or SLA renegotiation – SBA Layers decide whether they can replace a service
instance with rebinding or renegotiate with upper layers
Dynamic SLA
Binding Renegotiation
© Gabor Kecskemeti

31. Learning Package Overview
 Problem Description
 SLA Aware service infrastructures
 Autonomous behavior
 SLA Violation Propagation
 Conclusions
© Gabor Kecskemeti

32. 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

33. 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

34. 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