Fault tolerant workflow scheduling based on replication and resubmission of tasks in Cloud Computing

Transcription

1 Fault tolerant workflow schedulng based on replcaton and resubmsson of tasks n Cloud Computng Jayadvya S K* Department of Computer Scence & Engneerng Natonal Insttute of Technology Truchrappall, Taml Nadu, Inda jayadvyask@gmal.com Jaya Nrmala S Department of Computer Scence & Engneerng Natonal Insttute of Technology Truchrappall, Taml Nadu, Inda sjaya@ntt.edu Mary Sara Bhanu S Department of Computer Scence & Engneerng Natonal Insttute of Technology Truchrappall, Taml Nadu, Inda msb@ntt.edu Abstract The am of workflow schedulng system s to schedule the workflows wthn the user gven deadlne to acheve a good success rate. Workflow s a set of tasks processed n a predefned order based on ts data and control dependency. Schedulng these workflows n a computng envronment, lke cloud envronment, s an NP-Complete problem and t becomes more challengng when falures of tasks are consdered. To overcome these falures, the workflow schedulng system should be fault tolerant. In ths paper, the proposed Fault Tolerant Workflow Schedulng algorthm (FTWS) provdes fault tolerance by usng replcaton and resubmsson of tasks based on prorty of the tasks. The replcaton of tasks depends on a heurstc metrc whch s calculated by fndng the tradeoff between the replcaton factor and resubmsson factor. The heurstc metrc s consdered because replcaton alone may lead to resource wastage and resubmsson alone may ncrease makespan. Tasks are prortzed based on the crtcalty of the task whch s calculated by usng parameters lke out degree, earlest deadlne and hgh resubmsson mpact. Prorty helps n meetng the deadlne of a task and thereby reducng wastage of resources. FTWS schedules workflows wthn a deadlne even n the presence of falures wthout usng any hstory of nformaton. The experments were conducted n a smulated cloud envronment by schedulng workflows n the presence of falures whch are generated randomly. The expermental results of the proposed work demonstrate the effectve success rate n-spte of varous falures. Keywords-Cloud computng; Schedulng; Workflows; Replcaton; Resubmsson; Fault tolerance; I. INTRODUCTION Cloud computng [1][2] has emerged as a global nfrastructure for applcatons by provdng large scale servces through cloud servers. The servces can be ether storage servce or computaton servce. These servces can be confgured dynamcally by makng use of vrtualzaton. Any applcaton n cloud computng envronment can be represented by a workflow. However, ths computng envronment stll cannot delver the qualty, robustness and relablty that are needed for the executon of varous workflows because of dfferent falures lke lnk falure, falure of server provdng the servce, malcous code n the executng node, datasets requred by the task may be locked by other tasks etc [3]. The schedulng system n a cloud should overcome such falures whch can be provded by fault tolerant schedulng algorthms. Workflow s a sequence of tasks processed n a specfc order based on data or control dependency between these tasks. A workflow has a set of parameters and t s represented as a Drected Acyclc Graph (DAG) [4] n whch the nodes represent ndvdual applcaton tasks and drected arcs stand for precedence relatonshp among ISSN : Vol. 4 No. 06 June

2 the tasks. Mappng between the tasks and servces depends on the deadlne of a workflow and the computaton power of the resources avalable. Executon of these workflows can last for hours, days or even weeks and hence the realzaton of workflow falure at the end may lead to mssng of a deadlne. The workflow executon system wth low tolerance for falures may lead to a stuaton that user may not realze the falure of workflow there by tasks may mss ther deadlne. Hence the workflow schedulng system should exhbt hgh levels of tolerance for falures. Schedulng of workflows wthn the deadlne s a challengng ssue when fault tolerance s consdered. There are many fault-tolerant schedulng algorthms whch make use of tasks replcaton and task resubmsson [5] and few algorthms make use of hstory of resource nformaton to fnd falure probablty [6]. Each method has ts own dsadvantages and advantages whch are dscussed n secton II. In ths paper, fault tolerance s acheved by compromsng task replcaton and task resubmsson methods. Tasks are replcated based on heurstc metrc and prorty of the task. Heurstc metrc s calculated by fndng the tradeoff between replcaton and resubmsson factor whch gves the replcaton number based on mpact of the resubmsson [7]. The heurstc metrc s consdered because replcaton alone may lead to resource wastage and resubmsson alone may ncrease makespan. Tasks are prortzed based on out degree, earlest deadlne and hgh resubmsson mpact [8]. Tasks are scheduled to meet deadlne by consderng prorty and thereby to reduce wastage of resources by restrctng unnecessary replcaton of tasks. The rest of ths paper s structured as follows: The related work s explaned n secton 2. Secton 3 dscusses about the proposed strategy. Secton 4 descrbes about expermental results and secton 5 gves the concluson and future work. II. RELATED WORK In ths secton, few fault tolerance technques used n schedulng of workflows are dscussed. As for cloud workflow systems, smlar to many other grd and dstrbuted workflow systems, schedulng s a very mportant component whch determnes the performance of a whole system. These workflow schedulng systems should be fault tolerant for the falures that occur n the computng envronment. Fault tolerant schedulng algorthms can be categorzed based on check pontng, traces of data, replcaton of tasks and resubmsson of tasks. Each category has ts own advantages and dsadvantages. Fault tolerant workflow schedulng s provded by makng use of falure probablty whch s consdered n algorthms [9][10][11]. Zhang et al. [9] descrbed an approach for combned fault tolerance and schedulng workflow applcatons n computatonal grds. Kandaswamy et al. [10] descrbed a mechansm for fault tolerant workflow by consderng check pontng, mgraton, and over-provsonng. Lang et al. [11] developed a falure predcton model based on falure analyss of BlueGene/L system. Analyss of falure probablty requres traces of falure data about each resource n the envronment but often cloud provders do not reveal about ther nfrastructure and most of the tme, ths nformaton s hdden from the user. Methods lke replcaton and resubmsson of tasks do not requre any hstory of nformaton. Few technques provde fault tolerance by makng use of replcaton. All tasks are replcated to ther maxmum count whch provdes very good fault tolerance but uses lot of resources. The tasks whch can be executed on hghly relable resources are also replcated and hence the resources are wasted. If there s enough number of resources avalable then ths method wll gve good fault tolerance power to the workflow schedulng system. Most of the tmes, number of tasks wll be very hgh when compared to the number of resources avalable and hence ths method may lead to task seralzaton nstead of parallel executon [12]. Another technque provdes fault tolerance by usng resubmsson of tasks. Here, tasks are resubmtted to the same or dfferent resource after ts falure declaraton whch wll not waste any resource but ncreases the makespan of a workflow. Ths may also lead to mssng deadlne of a workflow and hence gves the less success rate of schedulng when deadlne s consdered. To overcome the dsadvantages of replcaton and resubmsson, few technques are dscussed whch fnds the tradeoff between the replcaton and the resubmsson [7]. Tasks are replcated wthout consderng any other parameters except the heurstc metrc whch may replcate all the tasks even f they are not crtcal and may lead to resource wastage. Hence, n ths paper, prortzaton of tasks s consdered along wth heurstc metrc. The tradeoff between replcaton and resubmsson factor helps to fnd the heurstc metrc that ndcates the replcaton count for each task. Prorty for the tasks s provded by usng parameters lke out degree, earlest deadlne and hgh resubmsson mpact. Prortzaton of tasks helps to meet the deadlne and reduces resource wastage along wth provdng fault tolerance for the workflow system. Here, the objectve s to schedule the tasks wthn ts deadlne by toleratng the faults that may be present n a cloud computng envronment to provde good success rate of schedulng. ISSN : Vol. 4 No. 06 June

3 Fgure 1. Archtecture of FTWS Fgure 2. Control flow dagram of modules III. ARCHITECTURE AND METHODOLOGY A. Overvew of FTWS Fg. 1 shows the archtecture of the FTWS n a cloud envronment. There are two major types of servers n cloud whch are storage server and computatonal server. Storage server provdes the servces related to data storage and modfcaton whch does not requre any mappng of servces. Computatonal server provdes the servce related to computng resources whch requres mappng of servces to a task. FTWS process s desgned wth four major modules whch are Preprocessor Module (PM), Replcaton based Scheduler Module (RSM), Executor Module (ResEM) wth Reschedulng f requred and Data Scheduler (DS). The control flow dagram of these modules s shown n Fg. 2. FTWS replcates and schedules the tasks to meet the deadlne of a workflow by usng replcaton and resubmsson of tasks. Replcaton of tasks s performed n the schedulng phase where as resubmsson s performed n the executon phase. Users frst submt ther workflows wth deadlne, replcaton factor and resubmsson factor n the form of Abstract data structure format to PM. The PM dscovers the servces requred for those tasks and generates the DAG [3] based on the data and control dependences between them and dvdes the tasks based on computaton servces and storage servces. It also generates the threshold whch helps n prortzng the tasks and heurstc metrc whch ndcates replcaton count. The RSM replcates the tasks based on the prorty and heurstc metrc. It allocates the partcular servces to these tasks based on the QWS (QoS based Workflow Schedulng) algorthm [13] n cloud envronment. After mappng, ResEM sends the tasks to the mapped servers and starts the tmer based on expected executon tme. If ResEM receves the successful output from the server wthn the tmer expry then t actvates all the tasks whch are dependent on the task. If t fals to receve successful output, then ResEM wats for other replcas. If all replcas fal then t resubmts the task. The DS manages the datasets by replcatng them on dfferent stes for the executon of replcated tasks. Detaled explanatons of these modules are explaned n Secton C. B. Problem Defnton Workflow ω s represented by a set of four tuples <T,j, D, Rep, Res > where T,j s a set of fnte tasks T,1, T,2, T,3, T,j, D s the Deadlne of the workflow ω before that the workflow has to be executed, Rep ndcates the replcaton count of a task n a workflow ω and Res s the maxmum resubmsson count of a workflow ω. Each task T,j has a set of attrbutes lke task-d, deadlne, executon tme, datasets and servces needed, sze, etc. Deadlne of each task s calculated by dstrbutng the deadlne of workflow among tasks n a crtcal path. Most of the tmes the executon tme of the task depends on the performance of the machne n whch job has to be executed [14]. For ths reason, executon tme s calculated when t s assgned to a node based on ts MIPS rate. Let m be the number of servces avalable n cloud and s k s the set of servces whch are capable of executng the task T,j. The FTWS replcates and schedules a set of tasks by mappng each task to sutable s k by executng tasks wthn the deadlne as n QWS algorthm wth few changes requred to handle replcaton. It also reduces the makespan requred to execute a workflow. Makespan s calculated as shown n (1). ISSN : Vol. 4 No. 06 June

4 makespan max executontme( Pj ) Pj n (1) where τ n s the crtcal paths n the ω C. Modules Descrpton 1) Preprocessng Module (PM): The man functonalty of ths module s to calculate all the parameters lke heurstc metrc, threshold, deadlne of each task n a workflow etc., whch are requred n the process of schedulng workflows. The PM accepts the data requred for the workflow from the user n the form of an abstract data structure template as shown n the followng example. No.of workflows: 1 No.of tasks: 4 task1: Datasets: d1,d 2,d3, Servces:s1,s2 ctrl_on: Null task2: Datasets: d 2,d4,d5, Servces:s3,s4 ctrl_on: Null task3: datasets: d3,d7,d1, servces:s10,s5 ctrl_on:task2 task4: datasets: d5,d6,d10, servces:s7,s12 ctrl_on: Null Deadlne:Sun May 4 12: 53: replcaton factor : 6 resubmsson factor : 6 DAG s a drected set of arcs of the form (T,T j ) where T s called the parent task and T j s called the chld task of T. Chld task cannot be executed untl all ts parent tasks complete ts executon. PM generates the DAG by fndng the data and control dependences (Dep (T,T j )) between the tasks of a workflow usng the expresson shown below. Dep ( T, T j ) ( datasets ( T ) datasets ( T j )! ) ( Task _ d ( T ) ctrl _ on( T j ))? 1 : 0 ; It s essental that each task should be completed before a deadlne so that the workflow meets the deadlne D gven by the user. So the deadlne of the whole workflow s dstrbuted n to sub-deadlnes among the tasks n a crtcal path based on ther sze[15]. Backtrackng algorthm as shown below s used to fnd the crtcal paths n a workflow. vod backtrack( ) get DAG of workflow crtcal_ path( DAG) vod crtcal _ path( DAG ) /* start root node end termnatng node n DAG*/ for ( each set of start and end tasks n ) allpaths ( DAG, start, end ); ISSN : Vol. 4 No. 06 June

5 vod allpaths ( DAG, current, end) /* current node from whch path has to be found */ push( current); f ( currentend) store each task n crtcal path set of ; for ( from 0to number of nebours of ) allpaths( DAG,, end); The PM fnds the threshold whch s used as one of the parameter to prortze the tasks durng replcaton n schedulng phase. The threshold (T h ) s calculated by fndng the average number of chldren for a task n a workflow as shown n (2). Where n T h chld ( t ) / 1 n ndcates number of n workflows The heurstc metrc s developed by usng the algorthm shown below. Here the make span of a workflow s calculated by makng use of a QWS algorthm whch was desgned n our prevous work [13]. In the heurstc metrc calculaton, workflow data s coped to workflow /. Number of nstructons requred to execute a / task n workflow s multpled wth resubmsson factor whch gves the worst case number of nstructons / to execute a partcular task. Then, the dfference between the makespan of and s calculated whch helps n analyzng the mpact of resubmsson on a workflow wth respect to one partcular task T. Resubmsson Impact (RI) s calculated by normalzng the dfference. RI s one of the parameter whch helps n prortzng tasks for replcaton. The heurstc metrc s calculated by multplyng the RI fracton wth the replcaton factor mentoned by user for each workflow whch gves the replcaton count for each task n a workflow. / / T, ( T )* res _ factor / makespan ( ) makespan ( ) normalze RI RI max j j0.. n rep RI * rep _ factor New rep s gven to Tasks can be dvded nto dependent tasks and ndependent tasks. Tasks whch are ndependent from all other tasks are sad to be ready tasks. PM fnds ready tasks usng (3) n all workflows whch are ndependent tasks whose predecessor tasks executed successfully or they are the start tasks of workflows.e., root nodes of all DAGs and t sends these tasks to the scheduler module by placng them n to a ready queue. n k DAG (T,T ) 0 k l k0l0 then T s ready task k where n s total number tasks n a workflow 2) Replcaton based Schedulng module(rsm): Ths module sorts all tasks n the ready queue as n QWS algorthm based on: Instructons_tme_rato Number of servces ISSN : Vol. 4 No. 06 June

6 Instructons_tme_rato s the rato between the number of nstructons n the task and the deadlne of the task. The tasks wth less nstructons_tme_rato are scheduled frst. If a task requres more number of servces, t may block the tasks whch requre fewer servces thereby ncreasng the watng tme of these tasks. So the task wth fewer servces s scheduled frst. After sortng the tasks n ready queue, t checks whether the task requres computaton servce or storage servce. If the task s related to storage servce, then t maps the task to the storage server. If t s related to the computatonal servce, then t replcates the task T as shown n followng snppet. f((no. of chldren (T,j ) Threshold(ω ) && all chldren of T,j are ( Resubmsson_mpact for T,j 0. 9 ) ( deadlne (T,j ) current_tme estmated_ executon_tme(t,j ) expected _commn_tme)) then replcate task based on the heurstc metrc value endf feasble) Here the condton for replcaton s based on task prorty whch s calculated by any of the followng three factors. No. of chldren Resubmsson Impact Deadlne If the number of chldren of T s more than the threshold (T h ), then the task becomes crtcal because number of tasks watng on ts result s more. Snce watng tme for chldren ncreases due to the falure, T s replcated. If the chldren of T depends on the other tasks n addton tot, then the replcaton of T only wastes the resources hence T wll not be replcated. Resubmsson mpact descrbes the overhead nvolved n the schedulng process f the task T fals. Hence f ths RI factor s more than 90% then the task T s replcated. Even n falure of above two condtons, f the expected completon tme of task T s very close to the deadlne then task T s replcated. After replcaton, the replcated tasks are placed next to the orgnal task n the ready queue. Here the tasks are adjusted based on the servces requred by the replcated tasks (Servces(T rep )) and other tasks (Servces(T other )) n the queue. Servces(Trep ) Servces(T other ) φ? no adjustement : number (avable resources ) number (Trep T other )? no adjustment : adjustment requred ; Ths adjustment s performed because f the avalable servces are able to execute only replcated tasks, then all other tasks may get delayed because of replcaton whch may lead to mss deadlne. Ths also helps n avodng seralzaton. If the adjustment s requred, then tasks n ready queue are checked aganst deadlne and readjusted based on earlest deadlne frst. Ths rearrangement may reduce the number of replcatons but ensures meetng deadlne wthout ncreasng the makespan. The tasks n ready queue are mapped wth the avalable servces n a data center by usng the nformaton present n the regstry. If the servces avalable n a datacenter are busy then t checks for other datacenters and assgns to the next free server. If all are busy then t wll be mapped to the wat queue of the data center whch has lesser load compared to others. The algorthm for mappng and schedulng tasks on servces s shown below: ISSN : Vol. 4 No. 06 June

7 vod schedule (t,ω ) /* t task s servce*/ whle ( ready_queue not empty ) t frst task n ready_queue s getservce(t) send task to the data center by dequeue( ready_queue) make s as busy nt getservce(t) select servce S such that executontme(t) deadlne(t) return S placng n run queue All avalable data centers wll be regstered n the regstry wth the attrbutes MIPS rate, avalable memory, servces t can provde, etc. 3) Resubmsson based Executor module: ResEM sends all mapped tasks to the respectve data centers and also wats for the acceptance and reply from the data center. The data center can accept the task or reject the task based on surplus nformaton as shown n (4). T ( t t t resolve ( t )) ready _ queue wat _ queue Deadlne ( t ) Where t tme requred to execute tasks n ready queue ready _ queue t tme requred to execute tasks n wat queue wat _ queue t tme requred to execute the nco mn g task resolve ( t ) tme requred to get datasets used by task t If the datacenter accepts the task, then ResEM sends the task to the data center by assngng a unque verson dentty to the task and then wats for the result. Whle sendng the task t also starts a tmer by spawnng the thread wth the expected tme to execute the task as shown below. pthread_create ( &tmer_ var, NULL, tmer, &lc_ expected_etme ); ResEM wats tll the tmer expry or tll the result comes back. Once ResEM gets the result, t checks for the correctness of a task by checkng the gven verson d and the obtaned verson d. If the completed task s correct then, t sends the sgnal to the node where the task was executed to update the datasets n data store and also to stop all the other replcas. ResEM sends the result to preprocessor whch masks the dependences of all ts chld tasks. ISSN : Vol. 4 No. 06 June

8 Fgure 3. Process of FTWS If the completed task does not meet the requrements or tmer expred before gettng the result, then ResEM wats for the result of other replcas. If all the replcas fal then t resubmts the task by calculatng ts parameters agan and the task s scheduled on the same node wth a new set of parameters. If the task fals agan then t s resubmtted tll t reaches maxmum falure factor. Falure factor s a varable and n ths work t s assumed to be 75% of the maxmum number of resubmsson count. If the falure of the task had reached the falure factor, t s consdered as a new task and re-scheduled on a dfferent node. If the task fals and reaches the maxmum resubmsson count on the new node then ResEM sends an error sgnal to preprocessor whch dsplays message to the user. The complete process of the FTWS s shown n Fg. 3. Ths shows how the tasks can move from ntaton state to completon state. 4) Data Scheduler: Tasks may be replcated n dfferent nodes so all those nodes may requre accessng the same set of datasets. Hence the data sets are also replcated. The management of these data sets s done by the DS. The strategy followed here s to mantan two copes of datasets. They are prmary copy and local copy. After gettng the datasets from the data store to the node, the copy of datasets n node becomes a local copy. All the changes done by the node are modfed locally. Once the sgnal comes from the ResEM, the updated datasets are sent to the data store and also DS nvaldates all the local copes n other nodes. DS mantans a table to keep track of all the replca nformaton whch helps n nvaldatng the datasets. The process of data replcaton and updaton of datasets s shown n Fg. 4. IV. EXPERIMENTAL RESULTS In ths secton, the expermental results of the proposed FTWS model are dscussed. The Cloud envronment s smulated usng VMware vrtual machnes. Communcaton between them s acheved by usng SSH programmng. Dfferent types of faults that can occur n a cloud envronment are also smulated. There are around 25 servces n cloud envronment whch are scattered n dfferent computatonal data centers and storage servers. To evaluate the performance of multple workflows rangng from 5 to 50 wth a mnmum of 8 tasks n each workflow wth dfferent set of parameters are generated randomly usng random generaton algorthm wth unform dstrbuton. ISSN : Vol. 4 No. 06 June

9 Fgure 4. Datasets Mantenance Fgure 5. Success Rate of Schedulng Fgure 6. Resource Utlzaton Fgure 7. Cost Comparson The most common method for generatng the random sequence r 1, r 2, r 3,, r k over the [n, m] s the lnear congruent method. Ths method multples the prevous random number r -1 by the constant n and addng wth constant c to t, then the modulus of the result s taken by dvdng t by m whch gves r as shown n (5). Ths helps n dstrbutng the values over [n, m] unformly. 1 s added n the expresson (5) to avod generaton of zero. r ( nr 1 c) modm (5) The servces are chosen for each task randomly n the set S 1, S 2, S 3,., S 25. Then ths nformaton s sent to PM whch starts the process of FTWS as explaned n secton III. Varous faults generated n nodes are lnk falure, malcous code attack, deletng results, request loss, no route to data store etc. Randomly we generate the MTBF (Mean Tme Between Falures) and MTTR (Mean Tme To Repar) values n each node. The tmer thread s started usng the value of MTBF. After the expry of MTBF thread, new thread wth MTTR s started and tll the expry of MTTR thread dfferent faults are generated lke deletng the results generated by the node, deletng the request, changng the executon tme to maxmum or mnmum or deletng the communcaton address for the data store etc. After the MTTR tmer expry.e., after repar t actvates the MTBF thread, the node works properly tll expry of MTBF thread and the cycle contnues. The proposed FTWS algorthm was run to evaluate ts performance for varous test cases wth dfferent number of workflows wth dfferent deadlnes and wth varous types of faults. The experments were repeated wth dfferent replcaton and resubmsson factors and averages of dfferent results were found. ISSN : Vol. 4 No. 06 June

10 Fgure 8. Performance Comparson Fgure 9. Falure Probablty The graph for comparson between success rate wth replcaton and success rate wthout replcaton s shown n Fg. 5. Snce the tasks are replcated on dfferent resources, the usage of resources may be more compared to schedulng wthout replcaton. Fg. 6 shows the graph for resource usage. Cost may also ncrease because of replcaton whch s showed n Fg. 7. Fg. 8 shows the rato between success rate and the resource usage and also the falure probablty s compared between schedulng wth replcaton and wthout replcaton as shown n Fg. 9. From the analyss we found that, the success rate of the schedulng s better than QWS (whch s the schedulng algorthm wthout any consderaton of fault tolerance).e., the success rate of schedulng wth replcaton s better than the success rate of schedulng wthout replcaton wth lttle compensaton of resource usage. Ths work s an enhancement of the prevous work [13]. V. CONCLUSION AND FUTURE WORK Many falures may occur whle schedulng workflows n Cloud Envronment. Hence the workflow schedulng applcaton should be fault tolerant for falures. The man goal s to schedule workflows and execute these workflows wthn the deadlne n-spte of many falures that occur n the envronment. Many exstng systems have addressed for provdng fault tolerance but wthout consderng the user gven deadlne. The proposed work, Fault tolerant workflow schedulng (FTWS), allows users to execute ther workflows by satsfyng deadlne n-spte of dfferent falures that occur n the envronment. Experments were conducted to test FTWS wth random generaton of workflows n a smulated cloud computng envronment wth smulated faults. The results of these experments were compared wth replcaton and wthout replcaton. Ths showed that FTWS algorthm produced good success rate of schedulng even after consderng dfferent falures that occur n the envronment. In future, other falures lke data center shutdowns, network falures, etc., may be added to the faults. Mappng of tasks and resources may be mproved by mantanng vald datasets at varous nodes, so that the transmsson overhead of datasets can be reduced. REFERENCES [1] Rajkumar Buyya, Chee Shn Yeo, Srkumar Venugopal, James Broberg, and Ivona Breandc, Cloud Computng and Emergng IT Platforms: Vson, Hype, and Realty for Delverng Computng as the 5 th Utlty, Future Generaton Computer Systems, Elsever Scence, Amsterdam, June 2009, Volume 25, Number 6, pp [2] C. German-Renaud and O.Rana, The Convergence of Clouds, Grds and Autonomcs, IEEE Internet Computng, p. 9, 2009 [3] Goverdhan P.V and S.Y.Kulkarn, Error detecton n Grd Computng, Second Internatonal Conference on Computer and Electrcal Engneerng, [4] Z. Sh and J.J.Donagarra, Schedulng workflow applcatons on processors wth dfferent capabltes, Future Gen. Comupter systems 22, pp , [5] K.Plankenstener, R.Prodan, T.Fahrnger, A.Kertesz, and P.Kacsuk, Fault-tolerant behavor n state-of-the-art grd workflow management systems, Techncal Report TR-0091, Insttute on Grd Informaton, Resource and Workflow Montorng Servces, Core GRID-Network of Excellence, October ISSN : Vol. 4 No. 06 June

11 [6] Zhfeng Yu, Chenja Wang and Wesong Sh, FLAW: FaLure-Aware Workflow Schedulng n Hgh Performance Computng Systems, Journal of Cluster Computng, Kluwer Academc Publshers Hngham, MA, USA, Vol. 13 Issue 4, pp , December [7] Kassan plankenstener, Radu Prodan, and Thomas Fahrnger, A New Fault Tolerance Heurstc for Scentfc Workflows n Hghly Dstrbuted Envronments based on Resubmsson Impact, Ffth IEEE Internatonal Conference on e-scence, [8] Raul Srvent, Rosa M. Bada and Jesus Labarta, Graph-based task replcaton for workflow applcaton, 11 th IEEE Internatonal Conference on Hgh Performance Computng and Communcatons, [9] Y. Zhang, A. Mandal, and K. Cooper, Combned fault tolerance and schedulng techques for workflow applcatons on computatonal grds, n Internatonal Symposum on Cluster Computng and the Grd. IEEE Computer Socery, 2009, pp [10] G. Kandaswamy, A. Mandal, and D. A. Reed, Fault tolerance and recovery of scentfc workflows on computatonal grds, Cluster Computng and the Grd, IEEE Internatonal Symposum on, vol. 0, pp , [11] Y. Lang, A. Svasubramanam, and J. Morera, Flterng falure logs for a bluegene/l prototype, n Proceedng of 2005 Internatonal Conference on Dependable Systems and Networks (DSN 05). Washngton, DC, USA: IEEE Computer Socety, 2005, pp [12] R. Prodan and T. Fahrnger. Overhead analyss of scentfc workflows n Grd envronments. IEEE Transactons on Parallel and Dstrbuted Systems, 19(3): , mar [13] Jayadvya S. K. and S. Mary Sara Bhanu, QoS based Workflow Schedulng n Cloud Computng, n Proceedng of Internatonal Conference on Cloud Comutng ICCC-2012, Interscence Research Netwrok, 2012, n Press. [14] H. Topcuouglu, S. Harr and M. Wu, Performance-effectve and low-complexty task schedulng for heterogeneous computng, IEEE Transactons on Parallel and Dstrbuton Systems, vol. 13, no. 3, pp , [15] Ja Yu, Rajkumar Buyya and Chen Khong Tham, Cost-based Schedulng of Scentfc Workflows Applcatons on Utlty Grds, In 1 st IEEE Internatonal Conference on e-scence and Grd Computng, Melbourne, Australa, Dec. 5-8,2005. AUTHORS PROFILE Jayadvya S K receved the B.E Degree n Computer Scence & Engneerng from Vsveshwaraah Technologcal Unversty, Bangalore, Karnataka. Currently, she s pursung the MTech Degree n Computer Scence from Natonal Insttute of Technology, Truchrappall, Inda. Her areas of nterests nclude cloud computng, Grd Computng and Real Tme Operatng Systems. S. Jaya Nrmala receved the B.E Degree n Computer Scence and Engneerng from Peryar Unversty, Salem and the M.E Degree n Computer Scence and Engneerng from Anna Unversty, Chenna. Currently, she s pursung her doctoral degree n the area of Servce Dscovery n Cloud Computng n the Department of Computer Scence and Engneerng, Natonal Insttute of Technology, Truchrappall, Inda. She s an Assstant Professor n Natonal Insttute of Technology, Truchrappall, Inda. Her areas of nterest nclude Cloud Computng, Cryptography and Operatng Systems. Mary Sara Bhanu S receved the B.E Degree n Electroncs and communcaton from Madura Kamaraj Unversty, the M.E Degree n Computer Scence from Bharathdasan Unversty and the Ph.D. Degree from Natonal Insttute of Technology, Truchrappall. Currently, she s an Assocate Professor n the Department of Computer Scence and Engneerng n Natonal Insttute of Technology, Truchrappall, Inda. Her research nterests nclude OS, Real Tme Systems, Dstrbuted Computng, Grd Computng and Cloud Computng. ISSN : Vol. 4 No. 06 June