SLA Enforcement in the Service Cloud

1. Fakultät für InformatikLehrstuhl III - Datenbanksysteme SLA Enforcement in the Service Cloud Anja Grünheid 1

2. Agenda • Introduction • ‘Quality of Service’ (QoS) Approach • ‘Request Scheduling’ (RS) Approach • ‘Priority Mechanisms’ (PM) Approach • Conclusion 2

3. Introduction: Background • Increase in the deployment of service-oriented architecture (SOA) • Different quality of service requirements for each customer • Limited hardware and software resources 3

4. Introduction: Service Level Agreements • Defined for services invoked by the customer • Formal contract between provider and customer to prevent customers from bad performance • Violations of one SLA are punished with pre-defined penalties • The complete penalty sum is dependent on the severity and number of overall violations 4

5. QoS Approach: Introduction • Developed by a research team of the Technical University of Munich, Germany • Main ideas: • Specific service model • ‘Control in the Large’, static and dynamic resource management • ‘Control in the Small’, adaptive SLA enforcement 5

6. QoS Approach: Service Model Differentiation between • Dynamic and static services • Scale-out capable and non scale-out capable services 6

7. QoS Approach: Static Resource Management 7

8. QoS Approach: Static Resource Management 7

9. QoS Approach: Dynamic Resource Management 8

10. QoS Approach: Dynamic Resource Management 8

11. QoS Approach: Adaptive SLA Enforcement I 9

12. QoS Approach: Adaptive SLA Enforcement I 9

13. QoS Approach: Adaptive SLA Enforcement II • Conformance c as measurement of service level agreement • Definition of stepwise SLAs: • Percentile constraints • Deadline constraints 10

14. QoS Approach: Adaptive SLA Enforcement III • Lower service levels correspond to higher penalties • Maximum of opportunity costs and marginal costs defines the current penalty value 11

15. QoS Approach: Adaptive SLA Enforcement IV • SLA as external component, penalty information is piggybacked in SQL • The external database scheduler • Normalizes the SQL query to confirm service classes • Knows the execution times of service classes through execution monitoring plus a small overhead • Gives either admission to access the database directly or queues the request according to a specified algorithm 12

16. QoS Approach: Adaptive SLA Enforcement V 13

17. QoS Approach: Adaptive SLA Enforcement V 13

18. RS Approach: Introduction • Developed by a research team consisting of researchers at the EPFL Lausanne, Switzerland, and IBM researchers at New York, USA • Main ideas: • Gatekeeper proxy as black box intercepting service requests to schedule them more efficiently • Developed for three-tier architectures, like e-commerce web sites 14

19. RS Approach: Admission Control • Important factors: • Knowledge of the system capacity • Service load knowledge • Admission is granted if the capacity is not exceeded, else the transaction is queued in a FIFO queue until admission can be granted 15

20. RS Approach: Request Scheduling • Schedules the SQL requests according to a pre-defined algorithm • Gatekeeper uses the request scheduling policy shortest-job first (SJF) • To avoid starvation an aging algorithm is implemented 16

21. RS Approach: Example 17

22. RS Approach: Example 17

23. RS Approach: Example 17

24. RS Approach: Example 17

25. RS Approach: Example 17

26. RS Approach: Locks • Blocking the resource for other services • Two different options where to lock: • In the database, the DBMS controls the locking itself • Controlled by the application servlet, which improves the performance for example by using Java synchronization mechanisms 18

27. PM Approach: Introduction • Developed by a research team at the Carnegie Mellon University, Pittsburgh, USA • Main ideas: • DBMS internal scheduling policies instead of external methods like the admission control • Step 1: Detection of the bottleneck resource • Step 2: Implementation of specific algorithms improving the bottleneck 19

28. PM Approach: Bottleneck Resource I • Transaction time T is split into three components: • CPU • I/0 • Lock • Monitoring of their behavior while using three different database systems: IBM DB2, Shore and PostgreSQL 20

29. PM Approach: Bottleneck Resource II • TPC-C benchmark, 10 clients per database warehouse • Picture 1: IBM DB2 • Picture 2: PostgreSQL differences in bottleneck resources 21

30. PM Approach: Scheduling the Bottleneck • Lock scheduling policies • Non-preemptive • Preemptive • CPU scheduling policies • All processors use generalized processor sharing (GPS) and are therefore preemptive 22

31. Conclusion I • All systems have found ways to improve the service execution for the customer • Difficulties and levels of implementation differ, depending on the approach • The database as bottleneck is approached differently 23

32. Conclusion II - Comparison 24

33. Literature D. Gmach, S. Krompass, A. Scholz, M. Wimmer and A. Kemper: Adaptive Quality of Service Managament, ACM 2006 S. Krompass, D. Gmach, A. Scholz, S. Seltzsam and A. Kemper: Quality of Service Enabled Database Applications S. Elnikety, J. Tracey, E. Nahum, W. Zwaenepol: A Method for Transparent Admission Control and Request Scheduling in E-Commerce Web Sites D. McWherter, B. Schroeder, A. Ailamaki, M. Harchol-Balter: Priority Mechanisms for OLTP and Transactional Web Applications 25

34. Thank you for your attention! 26

35. QoS Approach: Static Resource Management I • Service load analysis for different resources, e.g. CPU • Three steps: Preprocessing phase, Analysis phase, Classification phase

36. QoS Approach: Static Resource Management II • Static allocation of services according to previously derived load patterns • Implementation of a greedy heuristics • Give resources to static and non scale-out capable services first because of their inflexibility • Find for non scale-out capable services best-match servers • Scale-out capable services are distributed following a specified, self-defined allocation strategy

37. QoS Approach: Dynamic Resource Management I • Dynamic adaptations during runtime • Two general approaches • Queuing models, high development and maintenance costs • Feedback control systems, e.g. event condition action (ECA) systems or fuzzy controller • Decision in favor of the fuzzy controller, because of low administration efforts and low costs

38. QoS Approach: Dynamic Resource Management II Four main components: • Monitor and advisor modules • monitoring system • fuzzy controller • archive

39. QoS Approach: Dynamic Resource Management III

40. QoS Approach: Dynamic Resource Management IV • Another method of dynamic resource management: short-term load forecasting • Take statistical knowledge derived from load patterns into consideration to allocate resources

41. QoS Approach: Performance Analysis – Control in the Large • 80% of CPU use as overload limit • 15% more users than the system has been originally designed for • Snapshots before and after implementing the control in the large significant improvement

42. QoS Approach: Performance Analysis – Control in the Small • Combination of high, medium and low priority SLAs with matching penalties • Snapshots before and after implementing the control in the small significant improvement

43. RS Approach: Performance Analysis • Locking is done in the application server, top picture, and the database (MySQL) improvement using FIFO and SJF improvement when locking is done in the application server

44. PM Approach: Performance Analysis • TPC-C benchmark, high-priority transactions • Picture 1: Shore • Picture 2: PostgreSQL lock scheduling more effective for Shore, CPU scheduling more effective for PostgreSQL

45. PM Approach: Performance Analysis II • Preemptive lock scheduling was proven to be insufficient through experimental results • Possible reasons: • Overhead due to abortion of service transactions • Low-priority transactions suffer because they are again queued at the end after an abortion