s-cube lp: service level agreement based service infrastructures in the context of multi layered...
Post on 17-Dec-2014
456 Views
Preview:
DESCRIPTION
TRANSCRIPT
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
top related