Upload
virtual-campus
View
317
Download
0
Embed Size (px)
DESCRIPTION
Citation preview
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
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)
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
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/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
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 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
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