Your SlideShare is downloading. ×
S-CUBE LP: Service Level Agreement based Service infrastructures in the context of multi layered adaptation
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Saving this for later?

Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime - even offline.

Text the download link to your phone

Standard text messaging rates apply

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

473
views

Published on

Published in: Technology, Business

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
473
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
13
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. S-Cube Learning Package Service Level Agreement based Serviceinfrastructures 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 ASDS 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 theinfrastructure 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 NegotiationFault Autonomic Reaction PropagationNon-matching SLA SLA Mapping -templatesNon-matching SLA Negotiation bootstrapping -languages © Gabor Kecskemeti
  • 22. Autonomic reactions and faults for Meta BrokeringFault Autonomic Reaction PropagationPhysical resource New service selection SLA renegotiation with ASDfailureService failure New service selection SLA renegotiation with ASDWrong service New service selection SLA renegotiationresponseBroker failure New broker selection SLA renegotiation ASDNo service found by New broker SLA renegotiationbroker selection/Deployment with ASD(Meta) Broker Initiate new (Meta) SLA renegotiationoverloading broker deployment © Gabor Kecskemeti
  • 23. Autonomic reactions and faults for Self- Initiated deploymentFault Autonomic Reaction PropagationDegraded service health Service reconfiguration -Reconfiguration fails Initiate service cloning with Notify Broker/SLA state transfer renegotiationDefunct service Initiate service cloning Notify Broker/SLA renegotiationService Decommissioned Offer proxy Notify BrokerProxy 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 adaptationFramework 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 aLayered Approach for SLA-Violation Propagation inSelf-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 ReadingKertesz, A., Kecskemeti, G., & Brandic, I. (2009). Autonomic Resource Virtualization in Cloud-likeEnvironments. 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: ALayered Approach for SLA-Violation Propagation in Self-manageable Cloud Infrastructures. In The First IEEEInternational Workshop on Emerging Applications for Cloud Computing (CloudApp 2010), In conjunction withthe 34th Annual IEEE International Computer Software and Applications Conference (pp. 365–370). IEEEInternational Workshop on Emerging Applications for Cloud Computing.Guinea, S., Kecskemeti, G., Marconi, A., Wetzstein, B. (2011): Multi layered Monitoring and Adaptation. InProceedings 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