Automating SLA Modelling

1
Automating SLA Modelling

• Tony Chau
• IBM Toronto University of Toronto
• Vinod Muthusamy, Hans-Arno Jacobsen
• University of Toronto
• Elena Litani, Allen Chan, Phil Coulthard
• IBM Toronto
• October 27, 2008

2
Outline

• Service level agreement (SLA)
• SLA modelling implementation
• Flexible SLA model
• Automatic generation of monitoring artifacts

3
SLA Example
service time lt 3s, otherwise, charge provider
4
SLA Example
service time lt 3s, otherwise, charge provider
Y
Deposit
Y
Approved?
Good?
Check credit history
Validaterequest
Ask Manager
Notify
N
N
cost lt 0.02
5
SLA Example
service time lt 3s, otherwise, charge provider
Y
Deposit
Y
Approved?
Good?
Check credit history
Validaterequest
Ask Manager
Notify
N
N
cost lt 0.02
6
Service Level Agreement

• Contract between service providers and consumers
• Define the level of service agreed by both
  parties
• Optionally define the penalty if the level of
  service is not satisfied

7
SLA Modelling Today

• Informally expressed (e.g., in a Word document)
• Error-prone interpretation
• Time consuming implementation
• e.g., to monitor the SLA, create dashboards,
  perform service selection (fabric support),
  automate resource provisioning
• Tightly coupled with the business process
• Formally expressed (e.g., WSLA)
• Still tightly coupled with the process
• Not designed to be reused
• Inflexible to changes in the SLA or process

8
Objective

• Simplify modelling and monitoring of SLA for any
  given business process
• Encourage reusability and extensibility of SLA
  model
• Automatic generation of monitoring artifacts

9
Automating SLA Modelling

• Flexible SLA model
• Based on modular, composable and extensible SLA
  components
• Automatic Generation of Monitoring Artifacts
• Based on distributed, event-driven architecture

10
The Flexible SLA Model

• Component-oriented
• Composes of several SLA components
• Metrics
• Service level objectives (SLOs)
• Violation actions
• SLA components grouped in libraries
• form building blocks of constructing SLAs

11
Reusable SLA Components
A library of SLA components can be reused,
composed, configured, and extended to quickly
model arbitrarily complex SLAs.
12
Reusable SLA Components
A library of SLA components can be reused,
composed, configured, and extended to quickly
model arbitrarily complex SLAs.
13
Reusable SLA Components
A library of SLA components can be reused,
composed, configured, and extended to quickly
model arbitrarily complex SLAs.
14
Reusable SLA Components
A library of SLA components can be reused,
composed, configured, and extended to quickly
model arbitrarily complex SLAs.
15
Loose Coupling of Flexible Model
SLAs and processes can be modified independently.
Their loose coupling reduces the possibility of
invalidating the SLA.
SLA Modification Change SLA to consider cost of
all invoked services.
Processes Modification Change process to only
look for a flight if the train takes too long.
No changes to the process are required.
No changes to the SLAare required.
16
Validation
During design time, the SLA can be automatically
validated against the process. This provides
confidence to modify SLAs or processes
independently.
17
Automatic Generation
Given an SLA, monitoring artifacts can be
automatically generated for the process. The
runtime artifacts, when executing, monitors the
process to detect whether the SLA is violated.
Process
Necessary events turned on
Generation Engine
SLA
18
Runtime Architecture
Runtime is based on publish/subscribe model. SLA
components in the SLA model are generated as
agents in the publish/subscribe system. These
agents act as both publishers and subscribers.
GenEventAction
EmailAdminAction
Process
PoorExecTimeSLO
SevereExecTimeSLO
AvgExecTime
FinishProcInstance
ProcExecTime
publish execTime event
subscribe start and end event
publish avgExecTime event
subscribe execTime event
StartProcInstance
publish end event
publish start event
Publish/Subscribe System
19
Runtime Execution
Events are consumed by agents. After events are
processed, agents emit new events to propagate
updates. It causes a chain reaction to
re-evaluate the SLA.
GenEventAction
EmailAdminAction
Process
PoorExecTimeSLO
SevereExecTimeSLO
AvgExecTime
FinishProcInstance
ProcExecTime
publish execTime event
subscribe start and end event
subscribe execTime event
StartProcInstance
publish start event
20
Distributed Architecture

• Designed for distributed systems
• Agents can be arbitrarily deployed across the
  pub/sub system
• Scalable

21
Flexible Architecture

• Shared processing and network traffic
• Multiple SLAs that make use of the same metric
  can share the generated agent
• Events are sent once even if multiple agents are
  interested
• Dynamic runtime modification of SLAs
• Add, modify or remove SLAs during monitoring
• No downtime

22
Implementation

• Flexible SLA model
• Editor implemented for user to modify SLAs
• SLAs created for a given BPEL process
• BPEL and WebSphere Integration Developer used as
  proof of concept
• Generation engine
• Generate monitoring artifacts to be executed in
  WebSphere Business Monitor Server
• Monitoring artifacts monitors BPEL process, to
  detect whether the SLA is violated
• WebSphere products used as proof of concept

23
Conclusion

• Simplify modelling and monitoring of an SLA for
  any given business process
• Maximize reusability and extensibility
• Reduce development time
• Reduce likelihood of errors
• Flexible SLA model
• SLA components grouped in libraries
• SLAs developed by assembling different SLA
  components
• Extensible, flexible, compensable and
  configurable
• Validation
• Automatic generation of monitoring artifacts
• Automatic enabling of events in a process
• Runtime architecture based on pub/sub system
• Decentralized and scalable
• Better use of computing/network resources