Download
1 / 23
230 likes | 408 Views
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
E N D
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 • Flexible SLA model • Automatic generation of monitoring artifacts
Y Deposit Y Approved? Good? Validaterequest Check credit history Ask Manager Notify N N cost < $0.02 SLA Example service time < 3s, otherwise, charge provider
SLA Example service time < 3s, otherwise, charge provider Y Deposit Y Approved? Good? Validaterequest Check credit history Ask Manager Notify N N cost < $0.02
SLA Example service time < 3s, otherwise, charge provider Y Deposit Y Approved? Good? Validaterequest Check credit history Ask Manager Notify N N cost < $0.02
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
Metric Library SLO Library Action Library Evaluate an SLA objective Measure some aspectof a process Code that is executed upon SLO violation Example Metric Type Metric Instances Component Compositions GenEventAction EmailAdminAction PoorExecTimeSLO SevereExecTimeSLO AvgExecTime ProcExecTime FinishProcInstance StartProcInstance Reusable SLA Components A library of SLA components can be reused, composed, configured, and extended to quickly model arbitrarily complex SLAs. Id = ExecTime Name = Execution Time Schema = {Scope (type:Scope)} Name = ProcessTime Name = BookingTime Type = ExecTime Type = ExecTime Dependent Events Function void getDependentEvents() { return {e1, e2, e3, e4}; } Scope=EntireProcess Scope={flight, train} Event Handler void 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) }
Metric Library SLO Library Action Library Evaluate an SLA objective Measure some aspectof a process Code that is executed upon SLO violation Example Metric Type Metric Instances Component Compositions GenEventAction EmailAdminAction PoorExecTimeSLO SevereExecTimeSLO AvgExecTime ProcExecTime FinishProcInstance StartProcInstance Reusable SLA Components A library of SLA components can be reused, composed, configured, and extended to quickly model arbitrarily complex SLAs. Id = ExecTime Name = Execution Time Schema = {Scope (type:Scope)} Name = ProcessTime Name = BookingTime Type = ExecTime Type = ExecTime Dependent Events Function void getDependentEvents() { return {e1, e2, e3, e4}; } Scope=EntireProcess Scope={flight, train} Event Handler void 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) }
Metric Library SLO Library Action Library Evaluate an SLA objective Measure some aspectof a process Code that is executed upon SLO violation Example Metric Type Metric Instances Component Compositions GenEventAction EmailAdminAction PoorExecTimeSLO SevereExecTimeSLO AvgExecTime ProcExecTime FinishProcInstance StartProcInstance Reusable SLA Components A library of SLA components can be reused, composed, configured, and extended to quickly model arbitrarily complex SLAs. Id = ExecTime Name = Execution Time Schema = {Scope (type:Scope)} Name = ProcessTime Name = BookingTime Type = ExecTime Type = ExecTime Dependent Events Function void getDependentEvents() { return {e1, e2, e3, e4}; } Scope=EntireProcess Scope={flight, train} Event Handler void 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) }
Metric Library SLO Library Action Library Evaluate an SLA objective Measure some aspectof a process Code that is executed upon SLO violation Example Metric Type Metric Instances Component Compositions GenEventAction EmailAdminAction PoorExecTimeSLO SevereExecTimeSLO AvgExecTime ProcExecTime FinishProcInstance StartProcInstance Reusable SLA Components A library of SLA components can be reused, composed, configured, and extended to quickly model arbitrarily complex SLAs. Id = ExecTime Name = Execution Time Schema = {Scope (type:Scope)} Name = ProcessTime Name = BookingTime Type = ExecTime Type = ExecTime Dependent Events Function void getDependentEvents() { return {e1, e2, e3, e4}; } Scope=EntireProcess Scope={flight, train} Event Handler void 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) }
Deposit Approved? Good? Validaterequest Check credit history Ask Manager Notify Deposit Approved? Good? Validaterequest Check credit history Notify Ask Manager 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. Name = ServiceCost Name = ServiceCost Type = TotalServiceCost Type = TotalServiceCost Scope = EntireProcess Scope = {deposit, notify} No changes to the process are required. No changes to the SLAare required.
Pass or Fail Process Validation Invalid SLA components SLA • 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. Validation During design time, the SLA can be automatically validated against the process. This provides confidence to modify SLAs or processes independently. GenEventAction EmailAdminAction PoorExecTimeSLO SevereExecTimeSLO AvgExecTime ProcExecTime FinishProcInstance StartProcInstance
Machine logic for monitoring 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 GenEventAction Necessary events turned on EmailAdminAction Generation Engine PoorExecTimeSLO SevereExecTimeSLO AvgExecTime ProcExecTime SLA FinishProcInstance StartProcInstance
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 avgExecTime event subscribe execTime event publish execTime event subscribe start and end event StartProcInstance publish end event publish start event Publish/Subscribe System
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 subscribe execTime event publish execTime event subscribe start and end event StartProcInstance publish start 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
