QoS-based Scheduling of Workflow Applications on Service Grids

Transcription

1 QoS-based Schedulng of Workflow Applcatons on Servce Grds Ja Yu, Rakumar Buyya and Chen Khong Tham Grd Computng and Dstrbuted System Laboratory Dept. of Computer Scence and Software Engneerng The Unversty of Melbourne, VIC 3010 Australa {ayu, Dept. of Electrcal and Computer Engneerng Natonal Unversty of Sngapore 10 Kent Rdge Crescent, Sngapore Abstract Over the last few years, Grd technologes have been enhanced towards a servce-orented paradgm that enables a new way of servce provson based on utlty computng models, whch users consume based on ther QoS (Qualty of Servce) requrements. In such pay-per-use servce Grds, ssues such as resource management and schedulng based on users QoS constrants are yet to be addressed especally n the context of workflow management systems. In ths paper, we propose a QoS-based workflow management system and schedulng algorthm that mnmzes executon cost workflow applcaton whle meetng tmeframe for delverng results. We also attempt to optmally solve the task schedulng problem n branches wth several sequental tasks by modelng the branch as a Markov Decson Process and usng the value teraton method. I. INTRODUCTION Utlty computng [13] has emerged as a new servce provson model and ts servces [7] are capable of supportng dverse applcatons ncludng e-busness and e-scence over a global network. The users utlze the servces when they need to, and pay only for what they use. In the recent past, provdng utlty computng servces has been renforced by servce-orented Grd computng [9] by provdng an nfrastructure that enables users to consume utlty servces transparently over a secure, shared, scalable and standard world-wde network envronment. Many Grd applcatons such as bonformatcs and astronomy requre workflow processng n whch tasks are executed based on ther control or data dependences. As a result, a number of Grd workflow management systems wth schedulng algorthms have been developed by several proects (e.g. Condor DAGMan [16], Askalon [8], GrADS [5], ICENI [10], APST [18], and Pegasus [6][17]). They facltate workflow applcaton executon on Grds and mnmze executon tme. However, schedulng workflows based on users QoS (Qualty of Servce) requrements (e.g. deadlne and budget) has not been addressed n these exstng Grd workflow management systems. For a utlty servce, prcng s dependent on the level of QoS offered. Typcally servce provders charge hgher prces for hgher QoS. Therefore, users may not always need to complete workflows earler than they requre. Instead, they prefer to use cheaper servces wth lower QoS that are suffcent to meet ther requrements. Gven ths motvaton, we focus on QoS-based workflow management whch attempts to mnmze executon cost whle satsfyng users QoS requrements. In ths paper, we dscuss basc QoS-based workflow management requrements for servce Grds and present a novel workflow schedulng method. The obectve functon of the proposed schedulng algorthm s to develop workflow schedule such that t mnmzes the executon cost and yet meet the tme constrants mposed by the user. In order to solve schedulng problems effcently for large-scale workflows, we partton workflow tasks and generate the workflow executon schedule based on the optmal schedules of task parttons. A deadlne assgnment strategy s also developed to dstrbute the overall deadlne over each partton. We also attempt to solve optmally the schedulng problem for sequental tasks by modelng the branch partton as a Markov Decson Process (MDP) [12], whch has proven to be effectve for modelng decson problems. Proposed workflow schedulng approach can be used by both end-users and utlty provders. End users can use the approach to orchestrate Grd servces, whle utlty provders can outsource computng resources to meet customers servce-level requrements. The remander of the paper s organzed as follows. Secton II provdes an overvew of QoS-based workflow management on servce grds. We descrbe our novel workflow schedulng approach n Secton III. Expermental detals and smulaton results are presented n Secton IV. Fnally, we conclude the paper wth drectons for further work n Secton V. II. QOS-BASED WORKFLOW MANAGEMENT SYSTEM QoS-based workflow management on servce Grds mpacts all levels ncludng workflow specfcaton, servce dscovery and workflow schedulng. In ths paper we use the term servce to mean utlty computng servce as descrbed before. The archtecture of a typcal QoS-based workflow management system s shown n Fgure 1. The components of the workflow management system are dscussed below. A. Workflow Specfcaton The QoS-based workflow management system allows the user to specfy ther requrements along wth the descrptons of tasks and ther dependences usng the workflow specfcaton. In general, QoS constrants express the preferences of users and are essental for effcent resource 1

2 allocaton. We categorze workflow QoS constrants nto tasklevel and workflow-level constrants. At the task level, as llustrated n Fgure 2, QoS constrants are specfed wth ther correspondng tasks. In ths scenaro, the two QoS constrants, namely tme and cost are specfed wth task A. In contrast, QoS constrants at the workflow level are gven for entre workflow executon. In the example shown n Fgure 3, the workflow executon s requred to be completed before T04:20: :00 at the mnmum cost. QoS-based Workflow Management System Contract volaton Workflow Specfcaton Servce Dscovery Workflow Plannng QoS Montor Advance Reservaton Executor Workflow executon Workflow schedulng QoS Request ReservatonRequest(SLA) ServceRequest(SLA) Feedback Optonal GSP: Grd Servce Provder SLA: Servce Level Agreement Grd Market Drectory Grd Servce Grd Servce Grd Servce GSP marketplace Fg. 1. QoS-based workflow management system archtecture. B. Servce Dscovery and QoS Request After submsson of the workflow specfcaton, the workflow system needs to dscover the approprate servces for processng the tasks. In a complex workflow, dfferent tasks requre dfferent types of servces. For example, for a bologcal magng process, some tasks need to access a genome search servce and some other tasks need to access a proten foldng servce. However, n a servce Grd, even for the same type of servces, they are deployed by dfferent servce provders and are dstrbuted across multple admnstratve domans. In addton, every servce has ts own local polcy for dfferent users, such as authorzaton and prcng. The workflow system should be able to query a Grd nformaton servce such as a grd market drectory and generate a lst of avalable servces for every task for the user of the workflow. In a servce Grd, the QoS attrbutes of servces for processng the same task s dverse. Dfferent servce provders can offer dfferent QoS. One servce provder also can offer varous QoS levels for satsfyng dfferent users requrements. The prcng for the servces s usually closely related to the QoS provded. However, some users may have prorty n terms of servce order, executon tme and prce from certan servce provders. In addton, servce provders may adust the servce prce based on peak and off-peak perods n order to enhance the utlzaton of ther resources. <Workflow> <tasks> <task name= A > <qos-constrants> <qos-constrant name= tme value= /> <qos-constrant name= cost value= /> </qos-constrants>.. </task> </tasks> </Workflow> Fg. 2. Task-level QoS specfcaton. <Workflow> <qos-constrants> <qos-constrant name= tme value= T04:20: :00 /> <qos-constrant name= cost optmal= on /> </qos-constrants> <tasks> </tasks> </Workflow> Fg 3. Workflow-level QoS specfcaton. Users may want to specfy QoS constrants, such as deadlne and budget, for the overall workflow processng rather than for each task. For nstance, users may want the entre workflow executon fnshed n 2 hours nstead of specfyng an executon tme of 30 mnutes for each task. In ths paper, we focus on the overall tme constrant,.e. deadlne. WMS QoSRequest (task parameters, user, perod) QoSACK (processng tme, prce) Fg. 4. QoS request scenaro. Grd Servce The knowledge of QoS detals for all avalable servces s the key to schedulng workflow tasks effcently. A possble QoS request scenaro s presented n Fgure 4. It ntally starts from the Workflow Management System (WMS) sendng a QoS request to the Grd servces for every task. In the request t ndcates the task parameters, user of the workflow and the estmated executon perod. On recevng the request, the Grd servces reply wth the QoS parameters (e.g. processng speed, avalable storage space and free memory) of the servce they can offer and the correspondng prce for delverng the servce at the specfed QoS level. C. Workflow Schedulng Workflow schedulng focuses on mappng and managng the executon of workflow tasks onto grd servces. For the pay-per-use servce Grd, the schedulng decson durng workflow schedulng must be guded by users QoS constrants. There are three maor steps n workflow schedulng: workflow plannng, advance reservaton, workflow executon wth run-tme reschedulng. 2

3 1) Workflow Plannng Workflow plannng s to select a servce for every task n the workflow and generate a schedule before workflow executon. The result of the schedule must satsfy users QoS constrants. The decson makng of the planner for workflow executon needs to reference the entre workflow accordng to the QoS parameters of servces obtaned from QoS requests. In general, mappng tasks on dstrbuted servces s an NPhard problem; the workflow planner may only produce a suboptmal schedule n order to balance the schedulng tme. 2) Advance Reservaton An advance reservaton functon has been proposed to be supported by guaranteed QoS servces [1]. It s mportant to workflow schedulng especally for long lastng workflow executon. Workflow management systems need to make reservaton of servces selected by the planner n advance to ensure the avalablty of servces. starttme: t03:20: :00 endtme: t03:50: :00 starttme: T03:00: :00 endtme: T03:20: :00 B A D Fg. 5. Possble reservaton schedule. The tme slots for advance reservaton servces can be generated based on every optmal servce and possble start tme of the workflow executon. Fgure 5 llustrates a possble advance reservaton schedule for workflow executon. The earlest start tme of the task depends on the possble completon tme of ts parent tasks. If a task has more than one predecessor, the start tme s the latest completon tme of ts predecessors. If we consder communcaton overhead, the task start tme wll be the latest completon tme of parent tasks plus the communcaton tme. However, the tme slots of desred servces requested by the result of plannng may not be avalable when the workflow system makes the reservatons. Therefore, the workflow schedulng needs to be able to re-plan so that t can acqure an alteratve schedule. 3) Workflow executon wth run-tme reschedulng Typcal utlty computng servces are QoS guaranteed and need to meet servce commtments. However, there s stll a possblty that servces may volate the contract between the workflow system and servce provder for reasons such as servce falure and servce delay due to the competton wth other servce consumers wth hgher prorty. Therefore, the workflow scheduler must be able to adapt and update the schedule based on resource dynamcs. For example, f a task executon s delayed behnd the desred start tme of ts chldren tasks, the schedulng must adust the reservaton schedule for unexecuted tasks. A QoS montor s requred n C starttme: t04:10: :00 endtme: t04:20: :00 starttme: t03:20: :00 endtme: t04:10: :00 the system to montor the agreed performance and nform the planner of any changes. For non-reservaton servces, servce avalablty can only be known at run-tme. In ths case, run-tme reschedulng s more crtcal. In addton to dealng wth the stuatons of contract volaton, reschedulng also needs to handle unavalablty of optmal servces at the tme of a task executon. 4) Servce Level Agreement In the servce Grd, the actual allocaton of servces s not under the control of workflow management system. The commtment for servce executon s based on the Servce Level Agreement (SLA) between the workflow management system and servce provders. An SLA s a contract that specfes the mnmum expectatons and oblgatons that exst between consumers and provders [2]. SLA parameters for workflow tasks are QoS requrements of task processng and they nclude performance obectves such as earlest start tme and latest completon tme, and a rate model such as processng prce. Penalty clauses for servce level volaton are also requred n an SLA to enforce servce level guarantees. The penalty levels for servce executon volaton may vary for dfferent workflow tasks. For example, f the servce for executng task B n Fgure 5 s delayed for 20 mnutes, t does not affect the completon of the overall workflow. However, wth any delay of executng task C, the whole workflow executon wll delay. Therefore, the penalty levels for workflow task processng should be based on the degree of mpact on the whole workflow executon rather than on a sngle servce executon. III. A QOS-BASED WORKFLOW SCHEDULING The processng tme and executon cost are two typcal QoS constrants for executng workflows on pay-per-use servces. The users normally would lke to get the executon done at lowest possble cost wthn ther requred tmeframe. Gven ths motvaton, n ths secton we present a QoS-based workflow schedulng methodology and algorthm that allows the workflow management system to mnmze the executon cost whle delverng results wthn the deadlne. 1) Problem Descrpton and Methodology We model workflow applcatons as a Drected Acyclc Graph (DAG). Let be the fnte set of tasks ( 1 n). T ( T Let be the set of drected arcs of the form T, ) where T s called a parent task oft, and T the chld task oft. We assume that a chld task cannot be executed untl all of ts parent tasks are completed. Let D be the tme constrant (deadlne) specfed by the users for workflow executon. Then, the workflow applcaton can be descrbed as a tuple (,,. In a workflow graph, we call a task whch does not have any parent task an entry task denoted as T and a task whch does not have any chld task an ext task denoted as T. ext entry 3

4 Let m be the total number of servces avalable. There are a set of servces S : cond ( 1 n, 1 m, m m) s capable of executng the taskt, but only one servce can be assgned for the executon of a task. Servces have vared processng capablty delvered at dfferent prces. In general, the servce prce s nversely proportonal to the processng tme as shown n Fgure 6. We denote t (such that cond s satsfed) as the sum of the processng tme and data transmsson tme, and c (such that cond s satsfed) as the sum of the servce prce and data transmsson cost for processng T on servce S. Processng tme Fg. 6. Processng tme vs. prce for task executon. The schedulng problem s to map every T onto some S to acheve mnmum executon cost and complete the workflow executon wthn the deadlne D. We solve the schedulng problem by followng the dvde-and-conquer technque usng the methodology lsted below: Step 1. Dscover avalable servces and request QoS parameters of servces for every task. Step 2. Group workflow tasks nto task parttons. Step 3. Dstrbute user s overall deadlne nto every task partton. Step 4. Generate optmzed schedule plan based on the local optmal soluton of every task partton. Step 5. Start workflow executon and reschedule when the ntal schedule s volated at run-tme. We provde detals of steps 2-5 n the followng subsectons. The servce dscovery can be done by queryng a drectory servce such as the Grd market drectory [14]. B. Workflow Task Parttonng We categorze workflow tasks to be ether a synchronzaton task or a smple task. A synchronzaton task s defned as a task whch has more than one parent or chld task. In Fgure 7a, T 1, T 10 and T 14 are synchronzaton tasks. Other tasks whch have only one parent task and chld task are smple tasks. In the example, T2 T9 and T11 T13 are smple tasks. T 1 T 8 Prce Smple task Synchronzaton task T 2 T 5 T 7 T 9 T 3 T 6 T 10 T 11 T 4 T 12 T 14 T 13 T 1 (a) Before parttonng. (b) After parttonng. Fg. 7. Workflow task partton. T 8 Branch T 2 T 3 T 5 T 7 T 6 T 10 T 11 T 9 T 12 T 4 T 13 T 14 Let a branch be a set of smple tasks that are executed sequentally between two synchronzaton tasks. For example, the branches n Fgure 7b are T, T, }, T, }, T }, { T 8 9 { 2 3 T4 { T 5 6 T, }, T } and T, }. We then partton workflow { 11 { T { 7 tasks nto ndependent branches ( 1 k) B and synchronzaton tasks Y ( 1 l), such that k and l are the total number of branches and synchronzaton tasks n the workflow respectvely. LetV be a set of nodes n a DAG correspondng to a set of task parttons V ( 1 k + l). Let E be the set of drected edges of the form V, V ) of V and ( where V s a parent task partton V s a chld task partton of V. Then, a task partton graph s denoted as G ( V, E,. A smple path (referred to as path) n G s a sequence of task parttons such that there s a drected edge from every task partton (n the path) to ts chld, where none of the vertces (task parttons) n the path s repeated. A task partton V has four attrbutes: start tme ( st [ V ] ), deadlne ( dl V ] ), expected executon tme ( eet V ] ), and [ mnmum executon tme ( met V ] ). The earlest start tme of [ V s the earlest tme the frst task n t can be executed and t can be computed accordng to ts parent parttons, st [ V ] = max dl[ V ], where P s the set of parent task V P parttons of V s mn 1 y m Tx V x ] st [ V. dl[ V - ] V t y x [. The mnmum executon tme of. The attrbutes are related as: eet V ] = C. Deadlne Assgnment After workflow task parttonng, we dstrbute the overall deadlne between each V n G. The deadlne dl [ V ] assgned to any V s a sub-deadlne of the overall deadlne D. In ths paper, we consder the followng deadlne assgnment polces: P1. The cumulatve sub-deadlne of any ndependent path between two synchronzaton tasks must be same. A synchronzaton task cannot be executed untl all tasks n ts parent task parttons are completed. Thus, nstead of watng for other ndependent paths to be completed, a path capable of beng fnshed earler can be executed on slower but cheaper servces. For example, the deadlne assgned to T, } s the same as T } n Fgure 7. Smlarly, deadlnes { T 8 9 { 7 { 2, T3, T4 assgned to T }, T, }, and { T }, { T10 },{ T12, T13 }} are same. { T 5 6 [ { 7 P2. The cumulatve sub-deadlne of any path from V T V ) to V T V ) s equal to the overall ( entry ( ext deadlne D. P2 assures that once every task partton s computed wthn ts assgned deadlne, the whole workflow executon can satsfy the user s requred deadlne. 4

5 P3. Any assgned sub-deadlne must be greater than or equal to the mnmum processng tme of the correspondng task partton. If the assgned sub-deadlne s less than the mnmum processng tme of a task partton, ts expected executon tme wll exceed the capablty that ts executon servces can handle. P4. The overall deadlne s dvded over task parttons n proporton to ther mnmum processng tme. The executon tmes of tasks n workflows vary; some tasks may only need 20 mnutes to be completed, and some others may need at least one hour. Thus, the deadlne dstrbuton for a task partton should be based on ts executon tme. Snce there are multple possble processng tmes for every task, we use the mnmum processng tme to dstrbute the deadlne. We mplemented deadlne assgnment polces on the task partton graph by combnng Breadth-Frst Search (BFS) and Depth-Frst Search (DFS) algorthms wth crtcal path analyss to compute start tmes, proporton and sub-deadlnes of every task partton. D. Plannng The plannng stage s to generate an optmzed schedule for advance reservaton and run-tme executon. The schedule allocates every workflow task to a selected servce such that they can meet users deadlne at low executon cost. We solve the workflow schedulng problem by dvdng the entre problem nto several task partton schedulng problems. Once each task partton has ts own sub-deadlne, we can fnd a local optmal schedule for each task partton. If each local schedule guarantees that ther task executon can be completed wthn ther sub-deadlne, the whole workflow executon wll be completed wthn the overall deadlne. Smlarly, the result of the cost mnmzaton soluton for each task partton leads to an optmzed cost soluton for the entre workflow. Therefore, an optmzed workflow schedule can be easly constructed by all local optmal schedules. There are two types of task parttons: synchronzaton task and branch partton. The schedulng solutons for each type of partton and the overall algorthm are descrbed n followng sub-sectons. 1) Synchronzaton Task Schedulng (STS) For STS, the scheduler only consders one task to decde the servce for executng that task. The obectve functon for schedulng of a synchronzaton task Y s: mn, where 1 m and t eet Y ) c The soluton to a sngle task schedulng problem s smple. The optmal decson s to select the cheapest servce that can process the task wthn the assgned sub-deadlne. 2) Branch Task Schedulng (BTS) If there s only one smple task n a branch, the soluton for BTS s the same as STS. However, f there are multple tasks, the scheduler needs to make a decson on whch servce to execute ts chld task after the completon of the parent task. The optmal decson s to mnmze the total executon cost ( of the branch and complete branch tasks wthn the assgned sub-deadlne. The obectve functon for schedulng branch B s: k k mn, where 1 k m and t eet( B ) c T B T B BTS can be acheved by modelng the problem as a Markov Decson Process (MDP) [12], whch has been shown to be effectve for solvng sequental decson problems. 3) MDP Model for Sequental Branch Tasks The defnton of our MDP model for schedulng branch B s descrbed below: States: A Markov decson process s a state space S such that: Defnton 1: A state s S conssts of current executon task T and remanng deadlne RD. Defnton 2: A start state s a state when the current executon task s the frst task of the branch and RD s dl B ]. Defnton 3: A termnal state s a state after the last task of the branch s completed. Actons and transtons: For every state s, there are a set of actons A s. Actons ncur mmedate utlty and affect the MDP to transt from one state to another. Defnton 4: An acton n the MDP s to allocate a servce to a task. There are two varables assocated wth each acton a : the processng tme of the servce denoted as t and the servce prce denoted as c. Defnton 5: u (s,a,s') s the mmedate utlty obtaned from takng acton a at state s and transtonng to state s'., s'. RD < 0 u (s,a,s') = a.c, otherwse Defnton 6: A transton ncurred by an acton from one state to another s determnstc, as servces are QoS guaranteed. * The MDP problem s to fnd an optmal polcy π for all possble states. A polcy s a mappng from s to a. Decson makng for fndng an optmal acton for each state s not based on the mmedate utlty of the acton but ts expected utlty, whch s the sum of all the mmedate utltes obtaned as a result of decsons made for transtng from ths state to a termnal state. The value assocated to each state represents the expected utlty of ths state n the MDP. Ths value s calculated recursvely by usng the value of successor states. The value of one state s s: U ( s) = mn{ u( s, a, s )' + U ( s' )} a As The best acton for state s s: * π ( s) = arg mn{ u( s, a, s )' + U ( s' )} a As The computaton of the optmal polcy can be solved by usng a standard dynamc programmng algorthm such as polcy teraton and value teraton [12] (we have used value [ 5

6 teraton here). The optmal polcy ndcates the best servces that should be assgned to execute branch tasks under a specfc sub-deadlne. 4) Plannng Algorthm Fgure 8 shows the pseudo-code of the algorthm for plannng an executon schedule. After acqurng the nformaton about avalable servces for each task, a task partton graph G s generated from the applcaton graph and overall deadlne D s dstrbuted over every partton n t. Then optmal schedules are computed for every partton n G level-by-level usng ether STS or BTS. We also found that after the optmzaton of one partton, there s an dle tme between expected completon of planned servces and assgned sub-deadlne. Instead of watng, we adust the assgned sub-deadlne of planned parttons and the start tme of ther chld parttons. Input: A workflow graph (,, Output: a schedule for all workflow tasks 1 request processng tme and prce from avalable servces for 2 convert nto G ( V,E, 3 dstrbute deadlne D over G 4 for all V G do scheduled[] 5 S 1 all entry parttons V false 6 for all S1 do 7 f s a branch then 8 compute an optmal schedule for usng BTS 9 else 10 compute an optmal schedule for usng STS 11 scheduled[] true 12 Chld-ParttonHandlng() [see below] 13 whle Q s not empty do 14 remove the frst element n Q 15 S 2 all parent task parttons of 16 f S2, scheduled[ ] s true then st[ ] max dl[ ] 17 else put nto Q 18 compute an optmal schedule for usng STS 19 Chld-ParttonHandlng() Chld-ParttonHandlng( ): 20 dl[ ] get expected completon tme of 21 S 2 get chld task parttons of 22 for all S2 do 23 f s a branch partton then 24 st[ ] dl[ ] 25 compute an optmal schedule for usng BTS 26 k get the chld partton of 27 put k nto a queue Q 28 else put nto Q Fg. 8. Plannng algorthm for optmzng executon cost wthn users deadlne. STS s to compute an optmal schedule for a synchronzaton task to optmze the executon wthn sub-deadlne whle BTS s for branch tasks. E. Reschedulng In order to complete workflows and satsfy users requrements, run-tme reschedulng s requred to be able to adapt to dynamc stuatons such as the varaton n avalablty of servces due to falures. The key dea of our S3 T reschedulng polcy for handlng an unexpected stuaton s to adust sub-deadlnes and re-compute optmal schedules for unexecuted task parttons level-by-level. The motvaton of the level-by-level task partton approach s to reschedule the mnmum number of task parttons. For example, f the executon of one task partton s delayed, we look at ts chld task parttons. If the delay tme can be accommodated by the chld task parttons, reschedulng wll not mpact on ts lower levels. Otherwse, the rest of the delay tme s accumulated to ts successors untl the total delay tme has been dstrbuted. Input: A task partton graph G ( V,E,, delayed synchronzaton task X and delay tme delay Output: a new schedule for the unexecuted tasks n the workflow 1 S 1 all chld task parttons of X 2 for all G do scheduled[] true 4 for all S1 do st [ ] st[ ] + delay 6 ParttonReschedulng() 7 whle Q s not empty do 8 remove the frst task partton n Q 9 S 3 all parent task parttons of 10 f S2, scheduled[ ] s true then st[ ] max dl[ ] 12 ParttonReschedulng( ) ParttonReschedulng( ): 13 f ( dl[ ] - st[ ] ) me[ ] then 14 compute a new optmal schedule for 15 scheduled [ ] true 16 else dl [ ] st[ ] + me[ ] 17 compute a new optmal schedule for 18 scheduled [ ] true 19 S 4 all chld task parttons of 20 for all S4 do 21 put nto Q 22 scheduled [ ] false Fg. 9. Reschedulng algorthm for a synchronzaton delay. The reschedulng algorthm for a synchronzaton task delay s llustrated n Fgure 9. Frst, we adust the start tme of chld task parttons to be the actual completon tme of the delayed synchronzaton task (lne 4). Then, we check whether the new deadlnes of the chld task parttons can be acheved by comparng ther mnmum processng tmes (lne 13). If achevable, the planner generates new optmal schedules for the tasks n the chld task parttons based on the new expected executon tmes (lne 14) and reschedulng s stopped. Otherwse, new sub-deadlnes are assgned by usng the mnmum processng tme as the expected executon tme and then new schedules are generated (lne 16-18). When the delay cannot be accommodated by the frst level chld parttons, the lower level chld parttons are put nto the queue for further reschedulng (lne 19-22). A queue, Q, s used for mplementng the breadth-frst search algorthm for dentfyng new start tme n the graph. For branch task reschedulng, f a branch task executon s delayed, the optmal schedule for the next branch task of the delayed task can stll be obtaned from the ntal MDP result, accordng to ts current remanng sub-deadlne. The other S3 6

7 unexecuted parttons wll not be affected as long as the delay does not exceed the mnmum processng tme of the remanng unexecuted tasks n the branch. In addton to handlng task executon delay, the level-bylevel task partton based approach can also be appled for managng other dynamc stuatons such as servce unavalablty and servce polcy change. IV. PERFORMANCE EVALUATION The performance of QoS-based workflow schedulng algorthm descrbed n Secton III has been evaluated through smulaton usng the GrdSm Toolkt [4]. We conducted several experments by smulatng the structure of a proten annotaton workflow applcaton (see Fgure 10) developed by the London e-scence Centre [3]. The number n bracket next to the task represents the length of task n MI (mllon nstructons). Every task n the workflow requres a certan type of servce for processng. We smulated 15 types of servces and each servce type s supported by 5 dfferent servce provders. That s, we smulated 80 servce provders. Table I shows attrbutes an nstance of 5 dfferent servce provders n terms of ther processng capacty n MIPS (Mllon Instructons Per Second), delvery/processng tme n second and prce n G$. They all delver the same type of servce requred for executng task 3. We extended GrdSm to support servce dscovery wth request based on QoS parameters. As ndcated n Fgure 11, the workflow system frst dscovers avalable servces for every task va Grd Index Servce (GIS) wthn GrdSm and then queres the servces to obtan ther processng tme and prce. The processng tme of a task on a servce depends on the complexty of the task and the combned capablty of resource used for servce provson. As ndcated n Fgure 6, servces wth lower processng tme are delvered at hgher prce SgnalP COILS2 SEG PROSITE TMHMM 11 Prospero Summary HMMer 7 PSI-BLAST BLAST IMPALA (40000) (100000) (300000) PSI-PRED 3D-PSSM 8 (40000) (100000) (300000) (60000) (60000) (60000) Genome Summary SCOP (40000) (40000) (100000) (200000) (40000) Table I. QoS attrbutes of servces of dfferent provders for executng task 3. Servce ID MIPS Ratng Processng Tme (sec) Cost (G$) Fg. 10. A workflow for the proten annotaton. In our frst experment, we compare our proposed schedulng algorthm denoted as Deadlne Mn-Cost wth three other schedulng algorthms: Greedy-Cost, Greedy-Tme and 100-Random Selecton. The Greedy-Cost and Greedy- Tme algorthms always arrve at the best mmedate soluton whle searchng for an answer. The Greedy-Cost algorthm selects the cheapest servce for executng each task, whereas the Greedy-Tme algorthm selects the fastest servce. The 100-Random Selecton algorthm uses the average value of executon tme and executon cost captured through the repeated executon of workflow applcaton 100 tmes n whch servces are selected randomly. Fg. 11. Servce dscovery n GrdSm. The two man measurements used to evaluate the schedulng approaches are the tme constrant and executon cost. The former ndcates whether the schedule produced by the schedulng approach meets the requred deadlne, whle the latter ndcates how much t costs to schedule the workflow tasks on the smulated servce Grd. Fgure 12 compares the executon tme and cost generated by the planner usng the four schedulng approaches. As shown n Fgure 12a, the expected executon tme of workflow usng Deadlne Mn-Cost algorthm ncreases as users relax ther deadlne. The workflow executon tme for Greedy-Cost and 100-Random Selecton algorthms s hgher and cannot meet the users requrements when the deadlne s lower. The Greedy-Tme algorthm can complete earler than the Deadlne Mn-Cost algorthm but ts executon cost s much hgher (Fgure 12b). Fgure 12b shows that the executon cost of workflow usng Deadlne Mn-Cost algorthm s reduced as users relax ther deadlne. Expected Executon Tme (seconds) Expected Executon Cost (G$) Deadlne Mn-Cost Greedy-Tme Greedy-Cost 100-Random Selecton query(type A) Workflow System submt(task 1) GIS servce lst regster QoSRequest (task 1) tme, prce regster(servce type) User s Deadlne (seconds) a. Expected executon tme of four schedulng approaches. Deadlne Mn-Cost Greedy-Tme Greedy-Cost 100-Random Selecton Grd Servce Grd Servce User s Deadlne (seconds) b. Expected executon cost of four schedulng approaches. Fg. 12. Expected executon tme and cost usng four schedulng approaches. Greedy-Tme can complete the executon wth earlest tme, but the correspondng cost s very hgh. Greedy-Cost can complete the executon wth cheapest cost, but t s unable to meet users deadlnes when the deadlne s small. 7

8 We can see from Fgure 12 that the Deadlne Mn-Cost algorthm s the only one that consders users deadlne requrements whle optmzng the cost. The Greedy-Tme and Greedy-Cost algorthms represent the schedulng approaches that ntend to acheve mnmzaton of executon tme and cost respectvely. In another experment, we executed the workflow wth the optmal servces produced by the planner usng the Deadlne Mn-Cost algorthm. At run-tme, we smulated delays for the executon of task 6 as 0, 50, 100, 150, 200, 250 and 300 seconds. Fgure 13 shows that actual workflow completon tme wth and wthout reschedulng. We can see that reschedulng s able to adapt to the delay tme and complete the workflow executon on tme. However, the actual executon cost ncreases (Fgure 14), snce the scheduler swtches the remanng tasks to more expensve servces to speed up executon. Therefore, there s a need for approprate penalty mechansms to compensate for the loss caused by the volaton of the QoS guarantees. Actual Executon Tme (seconds) wth reschedulng wthout reschedulng Executon Delay Tme (seconds) of Task 6 wthn Deadlne 1000 seconds Fg. 13. Actual executon tme of task 6 (deadlne 1000 seconds) wth reschedulng and wthout reschedulng for ncreasng delay. Actual Executon Cost (G$) wth reschedulng expected cost Executon Delay Tme (seconds) of Task 6 wthn Deadlne 1000 seconds Fg. 14. Actual executon cost of task 6 (deadlne 1000 seconds) wth reschedulng for ncreasng delay. VI. CONCLUSION AND FUTURE WORK Workflow management on pay-per-use servce Grds has not been addressed n exstng Grd workflow systems. In ths paper, we presented a QoS-based workflow management system. In ths, we proposed a novel QoS-based workflow schedulng algorthm that mnmzes the cost of executon whle meetng the deadlne. We also descrbed task parttonng and overall deadlne assgnment for optmzed executon plannng and effcent run-tme reschedulng. We have utlzed a Markov Decson Process approach to schedule sequental workflow task executon. The current system uses run-tme reschedulng to handle servce agreement volatons. In future work, we wll further enhance our schedulng method to handle more dynamc scenaros such as dynamc prcng. ACKNOWLEDGMENTS We would lke to thank Hussen Gbbns, Chee Shn Yeo, Srkumar Venugopal, Sushant Goel, and Arun Konagurthu for ther comments on ths paper. Ths work s partally supported through StorageTek Fellowshp and Australan Research Councl (ARC) Dscovery Proect grant. REFERENCES [1] S. Benkner, I. Brandc, G. Engelbrecht, R. Schmdt, VGE - A Servce-Orented Grd Envronment for On-Demand Supercomputng, In the Ffth IEEE/ACM Internatonal Workshop on Grd Computng (Grd 2004), Pttsburgh, PA, USA, November [2] M.J. Buco et al, Utlty computng SLA management based upon busness obectves, IBM System Journal, Vol. 43(1): , [3] A. O Bren, S. Newhouse and J. Darlngton, Mappng of Scentfc Workflow wthn the e-proten proect to Dstrbuted Resources, In UK e-scence All Hands Meetng, Nottngham, UK, Sep [4] R. Buyya and M. Murshed, GrdSm: A Toolkt for the Modelng and Smulaton of Dstrbuted Resource Management and Schedulng for Grd Computng Concurrency and Computaton: Practce and Experence, Vol. 14(13-15): , Wley Press, USA, [5] K. Cooper et al, New Grd Schedulng and Reschedulng Methods n the GrADS Proect, NSF Next Generaton Software Workshop, Internatonal Parallel and Dstrbuted Processng Symposum, Santa Fe, IEEE CS Press, Los Alamtos, CA, USA, Aprl [6] E. Deelman et al, Mappng Abstract Complex Workflows onto Grd Envronments, Journal of Grd Computng, Vol.1:25-39, [7] T. Elam et al, A utlty computng framework to develop utlty systems, IBM System Journal, Vol. 43(1):97-120, [8] T. Fahrnger et al, ASKALON: a tool set for cluster and Grd computng, Concurrency and Computaton: Practce and Experence, 17: , Wley InterScence, [9] I. Foster et al, The Physology of the Grd, Open Grd Servce Infrastructure WG, Global Grd Forum, [10] A. Mayer et al, ICENI Dataflow and Workflow: Composton and Schedulng n Space and Tme, In UK e-scence All Hands Meetng, Nottngham, UK, IOP Publshng Ltd, Brstol, UK, September [11] S. Newhouse, Grd Economy Servces Archtecture (GESA), Grd Economc Servces Archtecture WG, Global Grd Forum, [12] R. S. Sutton and A. G. Barto, Renforcement Learnng: An Introducton, MIT Press, Cambrdge, MA, [13] G. Thckns, Utlty Computng: The Next New IT Model, Darwn Magazne, Aprl [14] J. Yu, S. Venugopal, and R. Buyya, A Market-Orented Grd Drectory Servce for Publcaton and Dscovery of Grd Servce Provders and ther Servces, Journal of Supercomputng, Kluwer Academc Publshers, USA, [15] J. Yu and R. Buyya, A Taxonomy of Workflow Management Systems for Grd Computng, Techncal Report, GRIDS-TR , Grd Computng and Dstrbuted Systems Laboratory, Unversty of Melbourne, Australa, March 10, [16] T. Tannenbaum, D. Wrght, K. Mller, and M. Lvny. Condor - A Dstrbuted Job Scheduler. Beowulf Cluster Computng wth Lnux, The MIT Press, MA, USA, [17] G. Sngh, E. Deelman, G. Mehta, K. Vah, M. Su, B. Berrman, J. Good, J. Jacob, D. Katz, A. Lazzarn, K. Blackburn, S. Koranda, "The Pegasus Portal: Web Based Grd Computng", The 20th Annual ACM Symposum on Appled Computng, Santa Fe, NM, Mar , [18] A. Brnbaum, J. Hayes, W. L, M. Mller, P. Bourne, H. Casanova, Grd workflow software for Hgh-Throughput Proteome Annotaton Ppelne, Proceedngs of the Frst Internatonal Workshop on Lfe Scence Grd (LSGRID2004), Ishkawa, Japan, June