1 sla enforcement in the service cloud anja grünheid fakultät für informatik lehrstuhl iii -...
TRANSCRIPT
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