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

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

Post on 29-Nov-2014

310 views

Category:

Technology

0 download

Embed Size (px)

DESCRIPTION

 

TRANSCRIPT

<ul><li> 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 </li> <li> 2. Learning Package Categorization S-Cube Adaptation Mechanisms Adaptation and evolution of SBA SLA aware autonomous Service Infrastructures Gabor Kecskemeti </li> <li> 3. Service Level Agreements TODO reference to some master slide introducing the idea of SLAs Gabor Kecskemeti </li> <li> 4. Learning Package Overview Problem Description SLA Aware service infrastructures Autonomous behavior SLA Violation Propagation Conclusions Gabor Kecskemeti </li> <li> 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 </li> <li> 6. Cross layer monitoring &amp; 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 </li> <li> 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 </li> <li> 8. Objectives 1. Hide the service infrastructures 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 </li> <li> 9. Learning Package Overview Problem Description SLA Aware service infrastructures Autonomous behavior SLA Violation Propagation Conclusions Gabor Kecskemeti </li> <li> 10. Relations within the research framework This research mainly targets the behavior of the service infrastructure level components of the service based applications Adaptation &amp; Monitoring Business Engineering &amp; 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 </li> <li> 11. Connections with the S-Cube lifecycle SSV architecture Identify Adaptation Requirements Need Operation &amp; Engineering Management Identify Design Adaptation Strategy Adaptation Evolution Deployment &amp; Enact Provisioning Realization Adaptation Support for IaaS cloud infrastructures Gabor Kecskemeti </li> <li> 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 &amp; 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 </li> <li> 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 </li> <li> 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 </li> <li> 15. Component &amp; 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 </li> <li> 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 </li> <li> 17. Learning Package Overview Problem Description SLA Aware service infrastructures Autonomous behavior SLA Violation Propagation Conclusions Gabor Kecskemeti </li> <li> 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 </li> <li> 19. Autonomous connections Gabor Kecskemeti </li> <li> 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 </li> <li> 21. Self-management examples in the SSV Gabor Kecskemeti </li> <li> 22. Autonomic reactions and faults for SLA NegotiationFault Autonomic Reaction PropagationNon-matching SLA SLA Mapping -templatesNon-matching SLA Negotiation bootstrapping -languages...</li></ul>