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


Published on

Published in: Technology, Business
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

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

  1. 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. 2. Learning Package Categorization S-Cube Adaptation Mechanisms Adaptation and evolution of SBA SLA aware autonomous Service Infrastructures © Gabor Kecskemeti
  3. 3. Learning Package Overview Problem Description SLA Aware service infrastructures Autonomous behavior SLA Violation Propagation Conclusions © Gabor Kecskemeti
  4. 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. 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. 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. 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. 8. Learning Package Overview Problem Description SLA Aware service infrastructures Autonomous behavior SLA Violation Propagation Conclusions © Gabor Kecskemeti
  9. 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. 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. 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. 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. 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. 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. 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. 16. Learning Package Overview Problem Description SLA Aware service infrastructures Autonomous behavior SLA Violation Propagation Conclusions © Gabor Kecskemeti
  17. 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. 18. Autonomous connections © Gabor Kecskemeti
  19. 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. 20. Self-management examples in the SSV © Gabor Kecskemeti
  21. 21. Autonomic reactions and faults for SLA NegotiationFault Autonomic Reaction PropagationNon-matching SLA SLA Mapping -templatesNon-matching SLA Negotiation bootstrapping -languages © Gabor Kecskemeti
  22. 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. 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. 24. Learning Package Overview Problem Description SLA Aware service infrastructures Autonomous behavior SLA Violation Propagation Conclusions © Gabor Kecskemeti
  25. 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. 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. 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. 28. Internal SLA monitoring and handling with aLayered Approach for SLA-Violation Propagation inSelf-manageable Cloud Infrastructures (LAYSI) © Gabor Kecskemeti
  29. 29. SLA violation propagation SC/BPM © Gabor Kecskemeti
  30. 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. 31. Learning Package Overview Problem Description SLA Aware service infrastructures Autonomous behavior SLA Violation Propagation Conclusions © Gabor Kecskemeti
  32. 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. 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. 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