S-Cube Learning Package   Service Level Agreement based Serviceinfrastructures in the context of multi layered            ...
Learning Package Categorization                       S-Cube                Adaptation Mechanisms            Adaptation an...
Service Level Agreements  TODO reference to some master slide introducing the idea of   SLAs                             ...
Learning Package Overview  Problem Description  SLA Aware service infrastructures  Autonomous behavior  SLA Violation ...
Service infrastructure diversity- Problem area #1  Different resource models   –  Physical hosts (grid5000)   –  Virtuali...
Cross layer monitoring & adaptation- Problem area #2  Composition and business process level adaptation decisions   do no...
Infrastructure rigidness- Problem area #3  Unexpected behavior frequently passed towards higher level   components   –  R...
Objectives  1. Hide the service infrastructure’s differences   –  Generalize the access towards the various service infra...
Learning Package Overview  Problem Description  SLA Aware service infrastructures  Autonomous behavior  SLA Violation ...
Relations within the research framework  This research mainly targets the   behavior of the service   infrastructure leve...
Connections with the S-Cube lifecycle   SSV architecture          Identify          Adaptation                          Re...
SLA-based Service Virtualization  architecture                                 Service composition layer                  ...
Target areas, operational steps            SC/BPM layer                           Meta negoti                             ...
Parties, components   MN – Meta-Negotiator: A component/service that manages    Service-level agreements. It mediates bet...
Component & Objectives relations  Meta-Negotiator   –  Interacts with the Composition and BPM layers allows the specifica...
Connections  Virtual campus learning package:   –  SLA-based Service Virtualization in distributed,      heterogenious en...
Learning Package Overview  Problem Description  SLA Aware service infrastructures  Autonomous behavior  SLA Violation ...
The Autonomic Manager  Basic autonomous                      Autonomic Manager   operations:                         Anal...
Autonomous connections                         © Gabor Kecskemeti
Autonomic interfaces in theinfrastructure  Sensors provide the state of the service infrastructure on   three aggregation...
Self-management examples in the SSV                                      © Gabor Kecskemeti
Autonomic reactions and faults for SLA  NegotiationFault              Autonomic Reaction          PropagationNon-matching ...
Autonomic reactions and faults for Meta  BrokeringFault                        Autonomic Reaction           PropagationPhy...
Autonomic reactions and faults for Self-  Initiated deploymentFault                     Autonomic Reaction              Pr...
Learning Package Overview  Problem Description  SLA Aware service infrastructures  Autonomous behavior  SLA Violation ...
Cross-layer adaptationFramework                                           M                                               ...
Monitoring & Correlation #1•  Invocation Monitor: produces low-level events through the observation of   the infrastructur...
Monitoring & Correlation #2•  Aggregator: aggregate   metrics are calculated by   applying their Esper event   processing ...
Internal SLA monitoring and handling with aLayered Approach for SLA-Violation Propagation inSelf-manageable Cloud Infrastr...
SLA violation propagation         SC/BPM                            © Gabor Kecskemeti
SLA violation propagation         SLA violation Sensor of Autonomic                  Servic instance                     ...
Learning Package Overview  Problem Description  SLA Aware service infrastructures  Autonomous behavior  SLA Violation ...
Summary  Service level agreements can be efficiently used for cross   layer interaction  Steps:   1.  Define an SLA in t...
Further S-Cube ReadingKertesz, A., Kecskemeti, G., & Brandic, I. (2009). Autonomic ResourceVirtualization in Cloud-like En...
Acknowledgements      The research leading to these results has      received funding from the European      Community’s S...
Upcoming SlideShare
Loading in …5
×

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

531 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
531
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
8
Comments
0
Likes
0
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. Service Level Agreements  TODO reference to some master slide introducing the idea of SLAs © Gabor Kecskemeti
  4. 4. Learning Package Overview  Problem Description  SLA Aware service infrastructures  Autonomous behavior  SLA Violation Propagation  Conclusions © Gabor Kecskemeti
  5. 5. 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
  6. 6. 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
  7. 7. 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
  8. 8. 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
  9. 9. Learning Package Overview  Problem Description  SLA Aware service infrastructures  Autonomous behavior  SLA Violation Propagation  Conclusions © Gabor Kecskemeti
  10. 10. Relations within the research framework  This research mainly targets the behavior of the service infrastructure level components of the service based applications Adaptation & Monitoring Business Engineering & Design Process  Adaptation and monitoring Management 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
  11. 11. 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
  12. 12. 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
  13. 13. Target areas, operational steps SC/BPM layer Meta negoti Information on ation availability, properties MN MB ... B B SLA negotiation, assurance ... ... ASD ASD ASD ASDS S R R S R R © Gabor Kecskemeti
  14. 14. 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
  15. 15. 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
  16. 16. 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
  17. 17. Learning Package Overview  Problem Description  SLA Aware service infrastructures  Autonomous behavior  SLA Violation Propagation  Conclusions © Gabor Kecskemeti
  18. 18. The Autonomic Manager  Basic autonomous Autonomic Manager operations: Analysis Planning –  sense state changes of the Knowledge managed resources –  invoke appropriate set of Monitoring Execution actions to maintain some desired system state 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
  19. 19. Autonomous connections © Gabor Kecskemeti
  20. 20. 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
  21. 21. Self-management examples in the SSV © Gabor Kecskemeti
  22. 22. Autonomic reactions and faults for SLA NegotiationFault Autonomic Reaction PropagationNon-matching SLA SLA Mapping -templatesNon-matching SLA Negotiation bootstrapping -languages © Gabor Kecskemeti
  23. 23. Autonomic reactions and faults for Meta BrokeringFault Autonomic Reaction PropagationPhysical resource failure New service selection SLA renegotiation/ Redeployment with ASDService failure New service selection SLA renegotiation/ Redeployment with ASDWrong service response New service selection SLA renegotiationBroker failure New broker selection SLA renegotiation/ Deployment with ASDNo service found by broker New broker selection/ SLA renegotiation Deployment with ASD(Meta) Broker overloading Initiate new (Meta) broker SLA renegotiation deployment © Gabor Kecskemeti
  24. 24. 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
  25. 25. Learning Package Overview  Problem Description  SLA Aware service infrastructures  Autonomous behavior  SLA Violation Propagation  Conclusions © Gabor Kecskemeti
  26. 26. 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
  27. 27. 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
  28. 28. 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 & [1] L. Baresi and S. Guinea. Self-Supervising BPEL Processes. IEEE Trans. Aggregator) and Software Engineering, 37(2):247–263, 2011. [2] A. Kertesz, G. Kecskemeti, and I. Brandic. Autonomic SLA-Aware Service Adaptation needs Virtualization for Distributed Systems. In Proceedings of the 19th analyzer 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© Gabor Kecskemeti on Web Services, ECOWS, pages 147–154. IEEE Computer Society, 2010.
  29. 29. Internal SLA monitoring and handling with aLayered Approach for SLA-Violation Propagation inSelf-manageable Cloud Infrastructures (LAYSI) © Gabor Kecskemeti
  30. 30. SLA violation propagation SC/BPM © Gabor Kecskemeti
  31. 31. SLA violation propagation SLA violation Sensor of Autonomic Servic 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 SLA Dynamic renegotiatio binding n © Gabor Kecskemeti
  32. 32. Learning Package Overview  Problem Description  SLA Aware service infrastructures  Autonomous behavior  SLA Violation Propagation  Conclusions © Gabor Kecskemeti
  33. 33. 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
  34. 34. Further S-Cube ReadingKertesz, A., Kecskemeti, G., & Brandic, I. (2009). Autonomic ResourceVirtualization in Cloud-like Environments. Distributed Systems Group, Institutefor 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 inSelf-manageable Cloud Infrastructures. In The First IEEE International Workshopon Emerging Applications for Cloud Computing (CloudApp 2010), In conjunction withthe 34th Annual IEEE International Computer Software and Applications Conference(pp. 365–370). IEEE International Workshop on Emerging Applications for CloudComputing. !Guinea, S., Kecskemeti, G., Marconi, A., Wetzstein, B. (2011): Multi layeredMonitoring and Adaptation. In Proceedings of The 9th International Conference onService Oriented Computing (Paphos, Ciprus) [ACCEPTED]! © Gabor Kecskemeti
  35. 35. 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

×