Scaling-up SLA Monitoring in Scaling-up SLA Monitoring in Pervasive - - PowerPoint PPT Presentation

scaling up sla monitoring in scaling up sla monitoring in
SMART_READER_LITE
LIVE PREVIEW

Scaling-up SLA Monitoring in Scaling-up SLA Monitoring in Pervasive - - PowerPoint PPT Presentation

Istituto di Scienza e Tecnologie dell'Informazione A. Faedo Software Engineering Laboratory Scaling-up SLA Monitoring in Scaling-up SLA Monitoring in Pervasive Environments Pervasive Environments Engineering of Software Services for


slide-1
SLIDE 1

Istituto di Scienza e Tecnologie dell'Informazione “A. Faedo”

Software Engineering Laboratory Antonia Bertolino*, Guglielmo De Angelis*, Sebastian Elbaum**, Antonino Sabetta*

* [bertolino,deangelis,sabetta]@isti.cnr.it ISTI-CNR, Pisa, Italy ** elbaum@cse.unl.edu

  • Univ. of Nebraska, Lincoln, USA

Engineering of Software Services for Pervasive Environments (ESSPE '07) Dubrovnik, September 4, 2007

Scaling-up SLA Monitoring in Scaling-up SLA Monitoring in Pervasive Environments Pervasive Environments

slide-2
SLIDE 2

SOFTWARE ENGINEERING LABORATORY

Motivation and Context

» To enable QoS management in

pervasive systems

» To check SLAs and to report

violations in an efficient and timely manner

slide-3
SLIDE 3

SOFTWARE ENGINEERING LABORATORY

Example scenario

» Fraud detection services (FDS):

» For online sellers: to detect suspicious

transactions and illegitimate payments

» For buyers: to verify that sellers can be

trusted (e.g. items sold are authentic)

» Different types of service requests, depth

  • f checks, users, locations
slide-4
SLIDE 4

SOFTWARE ENGINEERING LABORATORY

Example scenario

» Services accessed through many different

pervasive devices

» Clients may have different profiles and QoS

requirements

» SLAs can be complex, and possibly involve

application-specific conditions

» QoS level, which would otherwise be fine,

might suffer just because we are monitoring it

Requests coming from users

  • f class GOLD who have been registered

for more than a year and have used the service less than 10 times in the last hour must be served in less than 1500ms.

slide-5
SLIDE 5

SOFTWARE ENGINEERING LABORATORY

Checking SLAs is not weightless!

? how many clients we can't afford serving because we are busy monitoring (irrelevant events)?

slide-6
SLIDE 6

SOFTWARE ENGINEERING LABORATORY

Different clients, different “distance from violation”

clients QoS metric X

time=t1

slide-7
SLIDE 7

SOFTWARE ENGINEERING LABORATORY

Different clients, different “distance from violation”

clients QoS metric X

time=t2

slide-8
SLIDE 8

SOFTWARE ENGINEERING LABORATORY

Different clients, different “distance from violation”

clients QoS metric X

time=t3

slide-9
SLIDE 9

SOFTWARE ENGINEERING LABORATORY

Different clients, different “distance from violation”

clients QoS metric X

time=t4

slide-10
SLIDE 10

SOFTWARE ENGINEERING LABORATORY

Different clients, different “distance from violation”

clients QoS metric X

time=t5

slide-11
SLIDE 11

SOFTWARE ENGINEERING LABORATORY

A smarter way to do SLA checking

Key idea

Goal of monitoring: to reveal SLA violations

» Ideally, at a given instant:

» Monitor only the interactions for which

violations occur

» Ignore (=don't log, don't check) all the others

slide-12
SLIDE 12

SOFTWARE ENGINEERING LABORATORY

A smarter way to do SLA checking

» Dedicate more attention to

interactions that are more likely to violate an SLA

» Reduce checking activity for

interactions that are far from violation

» Shift SLA-checking effort dynamically

and automatically to save resources

slide-13
SLIDE 13

SOFTWARE ENGINEERING LABORATORY

Different clients, different “distance from violation”

clients QoS metric X

time=t5

slide-14
SLIDE 14

SOFTWARE ENGINEERING LABORATORY

analyze every event

How Opportunistic SLA Checking works

discard more discard some events T2 T1

slide-15
SLIDE 15

SOFTWARE ENGINEERING LABORATORY

Standard SLA checking infrastructure

slide-16
SLIDE 16

SOFTWARE ENGINEERING LABORATORY

Opportunistic SLA checking infrastructure

slide-17
SLIDE 17

SOFTWARE ENGINEERING LABORATORY

Prototype behaviour

slide-18
SLIDE 18

SOFTWARE ENGINEERING LABORATORY

Discussion

Approach assumes that:

» QoS fluctuations are slow enough to

enable prediction

» There is enough variability among clients

(service requested, usage profiles, SLAs)

slide-19
SLIDE 19

SOFTWARE ENGINEERING LABORATORY

Discussion

» Different optimization goals:

» Save storage (!)

» Always possible, with considerable gain if

missing some violations is not a problem

» Save CPU utilization (?)

» Only if the checks are heavy (complex SLAs)

» Trade-off between efficiency and

accuracy

slide-20
SLIDE 20

SOFTWARE ENGINEERING LABORATORY

Challenges and opportunities

» The sampling mechanism does have

an (albeit light) overhead

» If just simple checks are needed, the overhead

may exceed the optimization obtained by sampling » Optimize resource consumption:

» Approach reduces the use of storage » May also reduce cpu load

» Application-specific constraints can

be heavier to verify; checking them may be well worth optimizing

slide-21
SLIDE 21

SOFTWARE ENGINEERING LABORATORY

Summary

» Goal: to scale-up the ability to

check complex SLAs

» Approach: leverage users'

variability to save resources by shifting the attention to the interactions that are more critical (i.e. closer to violation)

» Trade-off: observe as many violations as

possible, saving as much as possible on resources

slide-22
SLIDE 22

SOFTWARE ENGINEERING LABORATORY

Open Issues

» For the Opportunistic SLA Checking

approach:

» Analyze the tradeoffs associated with the sampling

  • verhead

» Identify classes of SLAs (or SLA clauses) for which an

  • pportunistic approach is feasible/advantageous

» Develop support to leverage OSLAC for violation

isolation and regression testing activities

» For QoS monitoring in general:

» How to devise monitoring infrastructures that are

effective and timely, but do not interfere with the very QoS of the services they are meant to monitor