automating sla modelling
DESCRIPTION
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. Outline. Service level agreement (SLA) SLA modelling & implementation - PowerPoint PPT PresentationTRANSCRIPT
Automating SLA ModellingTony Chau
IBM Toronto & University of Toronto
Vinod Muthusamy, Hans-Arno JacobsenUniversity of Toronto
Elena Litani, Allen Chan, Phil CoulthardIBM Toronto
October 27, 2008
Outline
• Service level agreement (SLA)
• SLA modelling & implementation
• Flexible SLA model
• Automatic generation of monitoring artifacts
SLA Exampleservice time < 3s, otherwise, charge
provider
N
Y
Good?Check
credit history
Ask Manager
cost < $0.02
Validaterequest
Approved?
Deposit
Notify
Y
N
SLA Exampleservice time < 3s, otherwise, charge
provider
N
Y
Good?Check
credit history
Ask Manager
cost < $0.02
Validaterequest
Approved?
Deposit
Notify
Y
N
SLA Exampleservice time < 3s, otherwise, charge
provider
N
Y
Good?Check
credit history
Ask Manager
cost < $0.02
Validaterequest
Approved?
Deposit
Notify
Y
N
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
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
Objective
• Simplify modelling and monitoring of SLA for any given business process– Encourage reusability and extensibility of SLA
model– Automatic generation of monitoring artifacts
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
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
Reusable SLA ComponentsA library of SLA components can be reused, composed, configured,
and extended to quickly model arbitrarily complex SLAs.
Metric Library
Measure some aspectof a process
SLO Library
Action Library
Evaluate an SLA objective
Code that is executed upon SLO violation
Id = ExecTime
Dependent Events Functionvoid getDependentEvents() { return {e1, e2, e3, e4};}
Event Handlervoid onEvent(e) { static entry = {i1, i2, …, in} if (e.activity in entry) entry[e.instance] = e.time else diff = e.time – entry[e.instance] publish (diff, e.instance)}
Name = Execution Time
Schema = {Scope (type:Scope)}
Example Metric Type Metric Instances Component Compositions
Name = ProcessTime
Type = ExecTime
Scope=EntireProcess
Name = BookingTime
Type = ExecTime
Scope={flight, train}
EmailAdminAction
SevereExecTimeSLOPoorExecTimeSLO
GenEventAction
AvgExecTime
FinishProcInstanceStartProcInstance
ProcExecTime
Reusable SLA ComponentsA library of SLA components can be reused, composed, configured,
and extended to quickly model arbitrarily complex SLAs.
Metric Library
Measure some aspectof a process
SLO Library
Action Library
Evaluate an SLA objective
Code that is executed upon SLO violation
Id = ExecTime
Dependent Events Functionvoid getDependentEvents() { return {e1, e2, e3, e4};}
Event Handlervoid onEvent(e) { static entry = {i1, i2, …, in} if (e.activity in entry) entry[e.instance] = e.time else diff = e.time – entry[e.instance] publish (diff, e.instance)}
Name = Execution Time
Schema = {Scope (type:Scope)}
Example Metric Type Metric Instances Component Compositions
Name = ProcessTime
Type = ExecTime
Scope=EntireProcess
Name = BookingTime
Type = ExecTime
Scope={flight, train}
EmailAdminAction
SevereExecTimeSLOPoorExecTimeSLO
GenEventAction
AvgExecTime
FinishProcInstanceStartProcInstance
ProcExecTime
Reusable SLA ComponentsA library of SLA components can be reused, composed, configured,
and extended to quickly model arbitrarily complex SLAs.
Metric Library
Measure some aspectof a process
SLO Library
Action Library
Evaluate an SLA objective
Code that is executed upon SLO violation
Id = ExecTime
Dependent Events Functionvoid getDependentEvents() { return {e1, e2, e3, e4};}
Event Handlervoid onEvent(e) { static entry = {i1, i2, …, in} if (e.activity in entry) entry[e.instance] = e.time else diff = e.time – entry[e.instance] publish (diff, e.instance)}
Name = Execution Time
Schema = {Scope (type:Scope)}
Example Metric Type Metric Instances Component Compositions
Name = ProcessTime
Type = ExecTime
Scope=EntireProcess
Name = BookingTime
Type = ExecTime
Scope={flight, train}
EmailAdminAction
SevereExecTimeSLOPoorExecTimeSLO
GenEventAction
AvgExecTime
FinishProcInstanceStartProcInstance
ProcExecTime
Reusable SLA ComponentsA library of SLA components can be reused, composed, configured,
and extended to quickly model arbitrarily complex SLAs.
Metric Library
Measure some aspectof a process
SLO Library
Action Library
Evaluate an SLA objective
Code that is executed upon SLO violation
Id = ExecTime
Dependent Events Functionvoid getDependentEvents() { return {e1, e2, e3, e4};}
Event Handlervoid onEvent(e) { static entry = {i1, i2, …, in} if (e.activity in entry) entry[e.instance] = e.time else diff = e.time – entry[e.instance] publish (diff, e.instance)}
Name = Execution Time
Schema = {Scope (type:Scope)}
Example Metric Type Metric Instances Component Compositions
Name = ProcessTime
Type = ExecTime
Scope=EntireProcess
Name = BookingTime
Type = ExecTime
Scope={flight, train}
EmailAdminAction
SevereExecTimeSLOPoorExecTimeSLO
GenEventAction
AvgExecTime
FinishProcInstanceStartProcInstance
ProcExecTime
Loose Coupling of Flexible ModelSLAs 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.
Name = ServiceCost
Type = TotalServiceCost
Scope = {deposit, notify}
Name = ServiceCost
Type = TotalServiceCost
Scope = EntireProcess
No changes to the process are required.
No changes to the SLAare required.
Good?Check
credit history
Ask Manager
Validaterequest
Approved?
Deposit
Notify
Good?Check
credit history
Ask Manager
Validaterequest
Approved?
Deposit
Notify
ValidationDuring design time, the SLA can be automatically validated against the process. This provides confidence to modify SLAs or processes
independently.
Validation
EmailAdminAction
SevereExecTimeSLO
PoorExecTimeSLO
GenEventAction
AvgExecTime
FinishProcInstance
StartProcInstance
ProcExecTime
Process
SLA
Pass or Fail
Invalid SLA components
Check if required parameters in all component instance have been specified.
Verify that parameters are valid. Traverse SLA component graph and
compute union of dependent events. Verify that each event’s activity exists in
process.
Automatic GenerationGiven 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.
GenerationEngine
EmailAdminAction
SevereExecTimeSLO
PoorExecTimeSLO
GenEventAction
AvgExecTime
FinishProcInstance
StartProcInstance
ProcExecTime
Process
SLA
Necessary events turned on
Machine logic for monitoring
Runtime ArchitectureRuntime 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.
Process
EmailAdminAction
SevereExecTimeSLOPoorExecTimeSLO
GenEventAction
AvgExecTime
FinishProcInstance
StartProcInstance
ProcExecTime
Publish/Subscribe System
publish start event
publish end event
publish execTime event
subscribe start and end event
publish avgExecTime event
subscribe execTime event
Process
Runtime ExecutionEvents 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.
EmailAdminAction
SevereExecTimeSLOPoorExecTimeSLO
GenEventAction
AvgExecTime
FinishProcInstance
StartProcInstance
ProcExecTime
publish start event
publish execTime event
subscribe start and end event
subscribe execTime event
Distributed Architecture•Designed for distributed systems
– Agents can be arbitrarily deployed across the pub/sub system– Scalable
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
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
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