1

SLA Enforcement in the Service Cloud

Anja Grünheid

Fakultät für InformatikLehrstuhl III - Datenbanksysteme

2

Agenda

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

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

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

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

6

QoS Approach: Service Model

Differentiation between Dynamic and static services Scale-out capable and non scale-out capable

services

7

QoS Approach: Static Resource Management

7

QoS Approach: Static Resource Management

8

QoS Approach: Dynamic Resource Management

8

QoS Approach: Dynamic Resource Management

9

QoS Approach: Adaptive SLA Enforcement I

9

QoS Approach: Adaptive SLA Enforcement I

10

QoS Approach: Adaptive SLA Enforcement II

Conformance c as measurement of service level agreement

Definition of stepwise SLAs: Percentile constraints Deadline constraints

11

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

12

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

13

QoS Approach: Adaptive SLA Enforcement V

13

QoS Approach: Adaptive SLA Enforcement V

14

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

15

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

16

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

17

RS Approach: Example

17

RS Approach: Example

17

RS Approach: Example

17

RS Approach: Example

17

RS Approach: Example

18

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

19

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

20

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

21

PM Approach: Bottleneck Resource II

TPC-C benchmark, 10 clients per database warehouse

Picture 1: IBM DB2 Picture 2: PostgreSQL

differences in bottleneck resources

22

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

23

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

24

Conclusion II - ComparisonQoS approach RS approach PM approach

used for SOA systems Multiply-tiered web sites

OLTP and transactional web applications

component external external internal

bottleneck database database CPU, I/O, locking

content - Control in the large- Control in the small- Adaptive SLA management

- Gatekeeper proxy - Bottleneck identification- Algorithm implementation

25

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

26

Thank you for your attention!

QoS Approach: Static Resource Management I

Service load analysis for different resources, e.g. CPU Three steps: Preprocessing phase, Analysis phase,

Classification phase

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

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

QoS Approach: Dynamic Resource Management II

Four main components: Monitor and advisor modules monitoring system fuzzy controller archive

QoS Approach: Dynamic Resource Management III

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

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

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

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

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

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