Proceedings of Intemational Workshop on Data Mining and Artificial Intelligence (DMAI' 08)24 December, 2008, Khulna, Bangladesh

Runtime Thread Rescheduling: An Extended Scheduling Algorithm toEnhance the Performance of the Gridbus Broker

AltafHussain, Abu Awal Md. Shoeb, Md. Abu Naser Bikas and Mohammad Khalad HasanDepartment ofComputer Science & Engineering

Shahjalal University ofScience & TechnologySylhet, Bangladesh

{altaf_sust_82, johnshoeb, bikasbd}@yahoo.com, khalad-cse@Sust.edu

Abstract

Grid computing is becoming a requirement for theprocessing of large amount of data now-a-days. TheGridbus broker schedules jobs depending on data andcompute resources. Current scheduling process doesnot reassign a job from lower compute resource tohigher compute resource if higher compute resourceis available. In this paper, we have proposed atechnique to reassign a thread to higher gradeexecutor by preempting the thread in lower gradeexecutor by using the data restoration techniquewhich track the information of the thread so far ranon a lower rate compute resource. It is done only ifthere is an idle higher computer resource is available.The peiformance as well as the reliability of the Gridhas been improved by this approach in a considerableextent.

1. Introduction

Grid computing is very useful in the large scientificprojects. A grate number of researcher organizationand communities using grid computing to carry outtheir sheared data resource out come. However theusing of the power of Grid Computing remains to be achallenging problem for the users due to thecomplexity involved in the creation of the applicationand deployment on distributed computationalresources [1]. The Gridbus broker is an advancedservice-oriented meta-scheduler for data Grids whichdeals with computation on very large amount of datawhere data host may geographically distributed. Itsupports different Grid middleware and services. Ittakes care of many functions that Grid applicationsrequire such as resource selection, job scheduling andmanagement, data access to any distributed Grid

1-4244-2136-7/08/$20.00 ©2008 IEEE 80

resources and handling faults that may occur duringexecution, collecting result and presenting them. TheGridbus Broker schedules the job depending on somecriteria like data and computes resources, jobcompletion history etc. Here we present a modifiedscheduling algorithm, where we can use any idlehigher power compute resource extensively and thuscan improve the performance.

This paper is organized as follows: section 2discusses the related works and section 3 shortlydiscusses Gridbus broker architecture, section 4describes the problem scope of Gridbus brokerarchitecture and scheduling, section 5 elaborates ourproposed algorithm to counteract the problems ofGridbus broker scheduling, section 6 illustrates theexperimental evaluation and performance analysis ofalgorithm with some examples. We conclude insection 7.

2. Related works

As the scheduling of independent jobs ondistributed heterogeneous resources [2] is a well­studied problem, so here we discussing only a fewmajor work which deal with Grid. In the context ofData Grid, the Storage Resource Broker (SRB) [3]from San Diego Supercomputing Centre (SDSC)provides middleware for storing datasets over anetwork and accessing them; although it does not dealwith applications executing directly.

The Gridbus broker extends the Nimrod-G [4]computational Grid resource broker model todistributed data-oriented grids. Nimrod-G specializesin parameter-sweep computation. However, thescheduling approach within Nimrod-G aims atoptimizing user-supplied parameters such as deadlineand budget [5] for computational jobs only. Like

Nimrod-G, the AppLeS PST [6] supports deploymentof parameter-sweep applications on computationalgrids, but its adaptive scheduling algorithmemphasizes on data-reuse.

Harold, Shazia, Liao, Krishna, Buyya developed aGrid Thread Programming Environment (GTPE) [7]for the Gridbus broker, a software grid resource brokerthat provide transparent access to grid services.However, it does not provide any way to save theoutput of thread at any point of it runtime.

Venugopal, Buyya, Winton [1] focuses on aresource scheduling strategy within a Data Grid butconcentrated on adaptive scheduling algorithms andbrokering for heterogeneous resources that are sharedby multiple user jobs.

Similar to [1], our work focuses on a resourcescheduling strategy within a Data Grid but weconcentrate on runtime thread scheduling algorithmsand brokering for heterogeneous resources that areshared by multiple user jobs. However our workfocuses on using the higher rate compute resourcesmore extensively. In addition, the scheduling strategyis based on our 'File based Grid ThreadImplementation' that provides a way for saving theoutput of a thread and creating restoration files.

3. Gridbus broker overview

The architecture of the Gridbus broker is shown inFigure 1[1]. The Gridbus broker inputs are consideredas task and the parameter values associated with thetask. The parameters can be static or dynamic. Amongthe other component the Grid Index Informationservice (GIIS), gathers information from remoteinformation services i.e. availability and the propertiesof compute resources. The Data Service Catalogueorganizes the data files as Logical File Names (LFNs).Network weather service (NWS) obtains theinformation about the current available bandwidthbetween the data sources and the compute resources.Global Access to Secondary Storage (GASS) obtainsthe inputs or parameter file form the secondary storageif required. Logical and Physical File Names (LFNs),each LFN maps to one or many Physical File Names(PFNs) somewhere on the Grid and the Job Monitorkeeps track ofjob status, whether the jobs are queued,executing, finished successfully or failed.

A task is further considered as sequence ofcommands that focuses user requirements. The taskalong with its associated parameters decomposed in tojobs. A job is unit of work that is send to a Grid node.The set of jobs along with the set of service nodes are

81

an input to the scheduler. For jobs requiring remotedata, it interacts with a NWS to obtain the informationabout current available bandwidth between the datasources and the compute resources. It then uses thisinformation to schedule jobs by optimizing on theamount of data transfer involved.

In the current implementation, the jobs aredispatched to the remote node through the Actuatorcomponent. The Actuator submits the job to theremote node using the functionality provided by themiddleware running on it. The Actuator has beendesigned to operate with different Grid middlewareframeworks and toolkits such as Globus 2.4 thatprimarily runs on Unix-class machines and Alchemi[8], which is a .NET based grid computing platformfor Microsoft Windows-enabled computers.

j'..1=== Li==-~ --

.. 1.~ .=-~ ...._

IF''~: ....__._.____ ~I' i Jab6I"""':"cIIedult~L_--, r-~,__ +--._~~~I·' __ i

=- '<:j~~j------------~~~-----------

Figure 1: Gridbus broker architecture and itsinteraction with other Grid entities

The Gridbus broker scheduling algorithm schedulesa job depending compute resources and data hostassociated with a job that is to be deployed to anexecutor. Firstly it gathers the information about thecompute resources and data hosts using GUS and DataService Catalogue and determines the job completionrate for every compute resources for its history. For ajob to be deployed, identifies the data hosts associatedwith that job and for every pair of data and computeresources, it finds the pair with earliest job completionrate and if such a pair exist the scheduler assigns thejob to that pair. After the job has successfully finishedat the remote node (i.e. executor), its returns anyresults to the Broker. If any job becomes failed, it ismarked as failed and reset for rescheduling.

4. Problem scope of Gridbus Brokerarchitecture and scheduling

In the present scheduling algorithm, the GridbusBroker schedules the jobs depending on data andcompute resources available at the time of thedeployment of jobs. An executor (i.e. remote node)with a higher history ofjob completion gets the higherpriority for executing new job i.e. if there is one threadand two executor, one with relatively rich jobcompletion history but lower compute resource andother with poor job completion history but highercompute resource then the first one will get the job.Then the scheduler takes decision depending on thecompute resource. Also in the case when a computeresource with a higher job completion rate comes afterthe scheduling and deployment all jobs, the presentscheduling algorithm does not takes advantage of thatcompute resource. Also if there are two executorsworking for an application one with much highercomputing power then the other and the slower oneexecutes the last thread then the completion time ofthe application depends on the completion of the lastthread while the faster one remain idle aftercompleting its last job long before the slower one. Inthese contexts, the completion time of a job as well asfor an application gets much higher as a result ofthreads running on lower grade compute resource. Butin this case if we can use the idle time of the highercompute resource then it can reduce the computationtime by a considerable factor.

5. Proposed solution

For the solution of the problem stated in theprevious section, if any job running on lower gradecompute resource and there is a much higher gradecompute resource ( let it can finish the job in half ofthe time than current one) available after the taskassignment or gets connected to grid after the firstdeployment of the job. Then we can preempt the jobfrom the current executor with lower resources andassign the job to the newly available compute resourcedepending on the data resource for the job. Thoughthis approach gives better performance than existingone however as the new executor starts the job fromthe beginning the margin of performanceimprovement is low depending on the time ofpreemption. The closer the preemption happens to thecloser to the start time of the thread the higher thedegree of performance improvement. However, therecases can be found where this approach gives much

82

worse result if the preemption time is very closer tothe finished time of the job.

So, we further moves to an approach where we cansave the output of a thread in any point of runtime. Aswe can make restoration point of a thread then we cansave the computation time of the job has been executedbefore preemption. By this approach, whenever a~ompute re~ource with higher computation power getsIdle or avatlable in the Grid, we can preempt the jobrunning on a lower grade computation resource andreschedule the job to execute on that new executor. Atthe time of reassigning the job to the new computeres~urce we can make the restoration file of the jobavaIlable to the new executor so that it can startexecuting from the saved point of the job. Suppose theprevious node compute 40% of the job beforepreemption, when the job is reassigned to new nodewith generated output file. This node will restart thejob from the saved point (i.e. from the 40%, not fromthe beginning). As in this approach the new executordoes not need to start form the beginning of the job, asa result the degree of performance improvement getsmuch higher.

In our application (File Based GRID ThreadImplementation), we created a random access fileassociated with each thread and writing the results tothat file and thus creating restoration point. The fileonly contains the last two computed output of a thread.The file size depends on the type of application but inour application we managed it to be quite small. Thisgenerated file is stored in the Manager Node. The fileof a thread is deleted automatically after the successfulcompletion of the thread. Threads received from theUser are placed in a pool and scheduled to be executedon the various available Executors by the Manager.Manager can reassigns that thread to any executornode with the same thread ID from the thread pool.When the Manager distributes the thread to anyExecutor node, the node first check if there is any fileis available with its own thread id. If any file isavailable for that thread, the node then recovers theresultant value of that thread from the file created andstarts execution from the recovered value. If no file isfound for that thread then the thread will startexecution from the beginning and also create a file inthe Manager Node using Thread ID (i.e. filename) asThread ID remain same throughout the lifetime of anapplication.

In the global grid environment, these generatedrestoration file can be stored in the remote data hostassigned with that for that Grid node or can be storedin some different host depending on the bandwidth

and cost of data transfer etc. For the jobs requiringremote data, the scheduler interacts with the NetworkWeather Service (NWS) [9] to get the currentbandwidth condition. We can create a new instance forthe restoration file in the Logical File Names (LFNs)which maps to Physical File Name of the restorationfile stored in the appropriate location or data host.This instance can be updated and can use for theselection of the restoration file host. The Gridbusbroker can resolve the restoration files by querying theData Service Catalogue. When the schedulerreschedules that job for execution the restoration filecan be assigned with that job so that the new executorcan retrieve the file from the data host beforeexecution and stat execution from that successfulexecuted point.

Depending on this approach, we modified theexisting scheduling algorithm of the Grid bus broker.The modified Gridbus broker scheduling algorithm isstated in Figure 2. We added a new module (module6) in the existing algorithm for rescheduling the jobsrunning on lower grade compute resource while thereavailable any idle higher grade compute resource andno job in unassigned-job-list.

The scheduler schedules the job considering theearliest job completion time between two computeresources depending on the data host associated withthat job. If the higher grade compute resource has theearliest job completion time then the schedulerpreempt the job and reassign it to the new executorwith the restoration files. The new executor collect therestoration files and start the job form the last savedpoint.

Initialization1. Identify characteristics, configuration, capability,and suitability of compute resources using the Gridinformation services (GIS).2. From the task definition, obtain the data queryparameters (if present), such as the logical filename.

a. Resolve the data query parameter to obtain thelist of Logical Data Files (LDFs) from the DataCatalog.

b. For each LDF, get the data sources or DataHosts that store that file by querying the DataCatalog.Scheduling loopRepeat while there exists unprocessed jobs. [Thisstep is triggered for each scheduling event. Theevent period is a function of job processing time,rescheduling overhead, resource share variation,etc.]:3. For each com pute resource, predict andestablish the job consumption rate or the available

83

resource share through the measure andextrapolation strategy taking into account the timetaken to process previous jobs. Use this estimatealong with its current commitment to determineexpected job completion time.4. If any of the com pute resource has jobs that areyet to be dispatched for execution and there isvariation in resource availability in the Grid, thenmove such jobs to the unassigned-Jobs-List.5. Repeat until all unassigned jobs are scheduledor all compute resources have reached theirmaximum job limit.

a. Select the next job from the Unassigned-Jobs­List.

b. Identify all Data Hosts that contain the LDFassociated with the job.

c. Create a Data-ComputeResource-List for theselected job:

• For each data host, identify a com puteresource that can complete the job earliest givenits current commitment, job completion rate, anddata transfer time using current availablebandwidth estimates.

d. Select a data host and compute resource pairwith the earliest job completion time from the Data­ComputeResource-List.

e. If there exists such a resource pair, thenassign the job to the compute resource and removeit from the Unassigned-Jobs List.6. Repeat while there is no unassigned job andthere exits any idle higher grade compute resourcethen any node in the Grid [This step is triggered foreach scheduling event. The event period is afunction of rescheduling overhead, restoration filerecovering over head, etc.]:

a. Select the lowest grade compute resourceexecuting any job.

b. Select a data host and compute resource withthe earliest job completion time between the twocompute resources depending Data­ComputeResource-List.

c. If the idle compute resource can com plete thejob in earliest time then preempt the job and

i. Select the restoration file host (data host)that contain LDF associated with that job.

ii. Reassign the job to the higher gradecompute resource.7. End of scheduling loop.

Figure 2: Modified adaptive schedulingalgorithm for Data Grid

6. Experimental result and performanceanalysis

We setup the experiment environment withheterogeneous executors, one with lower gradecomputation power and the other with much higher

grade computation power. This higher grade computeresource can perform almost twice as faster than theother lower grade compute resource. Theconfiguration of the two executors is given in Figure 3and Figure 4.

Processor: Inter Celeron® CPU 2.66 GHzRam: 512 MBas: Microsoft Windows XP Professional V2002 Service Pack 2

Figure 3: Executor 1 (lower grade computeresource)

Processor: Inter Core2Duo 1.86 GHzRam: 1024 MBas: Microsoft Windows XP Professional V2002 Service Pack 2

Figure 4: Executor 2 (higher grade computeresource)

Two different application programs have been usedto evaluate the performance comparison. In ourImplementation, both applications take an integer asinput and give the number of factors as output. In caseof first application program, we developed withexisting algorithm that does not use any technique tosave the output of any thread. As there is a non-zeroprobability of thread failure so, if any thread becamefailed, we can not get the partial result so farcomputed by that thread. In contrast, in our 'Filebased Grid Thread implementation", we created arandom access file associated with each thread andwriting the results to that file and thus creatingrestoration point. The file only contains the last twocomputed output of a thread. Two status characters fortwo results are also stored to indicate which of theresults are stored successfully or not. The size of eachresult is 10 byte. Since the file contains two results,the total size of the file is 20 byte.

In both applications, same input is used to comparebetween them, both give the same results as well. Bothapplication give the total number of factors of a given

84

input value (e.g. 101\10). We will show theperformance comparisons in the context of a singlethread and also in the context of an applicationcomprises by a number of thread. These cases willgive us an overview of how these approaches effect incase of a thread and in the application context. Herewe have shown different performance comparisonswhere our modified approach gives better performancethan the existing approach in almost every case. Theperformance of modified approach depends on howlong a thread is executed before it is being preempted.The much shorter a thread executed before it is beingpreempted the much better performance is obtained byour modified file based implementation.

6.1. In the context of a single thread

This case gives an overview how the modified runthread scheduling using preemption approachimproves performance in case of a single thread. Herewe give the comparisons between the performance ofthread scheduling technique using the existingimplementation (where preempted thread starts formthe beginning at the reassigned executor) and themodified file based implementation (where preemptedthread starts form the last saved point at thereassigned executor).

6.1.1. Test case 1 (without preemption): In this testmodule we showed how much time a single threadtakes to finish by Executor 1 and by the Executor 2separately. In all the test cases here threads areexecuted without any preemption (i.e. finishedsuccessfully). This table also shows the comparisonsbetween the times taken by the existingimplementation verses our modified file basedimplementation.

6.1.2. Test case 2 (with preemption): In this testmodule we show the comparison between theperformance of the existing implementation and themodified implementation by preempting a thread atseveral times in its life time. We took the thread sameas the thread describe in Test Module 1. The threadusing existing implementation, first executed in theExecutor 1, which takes an average of 1:21.9 min toexecute normally. So we preempt the thread for loth to70th second with 10 sec interval after startingexecution at the Executor 1. Then we make the highercompute resource (Executor 2) available to the gridand the thread starts execution form the saved pointusing restoration point. This technique finishes the job

Table 2: Comparison between twoimplementation with job preemption

in much lesser time in almost every case though thesecond executor stats the job form the beginning.

6.2.1. Test case 1 (without preemption): This testmodule gives an overview of how much time theexecutors takes (separately or both executors together)to finish an application with five threads. This tablealso compares between the existing and modifiedimplementation.

In this case we show how the run time threadscheduling with preemption effect on completion timeof an application comprises of several number ofthreads. We take an application with five threads. Forthis test case last thread is executed on the lower gradecompute resource. Here we preempt the last thread inseveral point of its life time.

has executed in the first executor thus we can savemore time. Thus this approach gives a greater degreeof performance improvement, which can be clearlyseen from the Figure 5 and Table 2.

6.2. In the context of an application (multiplethreads)

Table 1: Comparisons between the executiontime of Executor 1 and Executor 2 with a

I th dsing e reaExisting Modified file

Test #of implementation basedcase thre- implementation

ad Execu- Execu- Execu- Execu-tor 1 tor 2 tor 1 tor 2

1 1 0:1 :21. 0:0:36. 0:1:21. 0:0:37.87500 39062 82812 68750

5 5 02 1 0:1 :21. 0:0:36. 0:1 :21. 0:0:36.

78125 43750 10937 421870 5 5

3 1 0:1:22. 0:0:37. 0:1 :21. 0:0:36.12500 39062 89062 39062

5 5 5

Test Finish time with preemptionCas Preempt (min: sec)

e time Existing Modified(nth sec) Implementation Implementation

1 10 0:57.265625 0:39.4218752 20 1:06.171875 0:57.984375

3 30 1:17.546875 0:59.015625

4 40 1:26.859375 1:09.3593755 50 1:37.187500 1:32.078125

6 60 1:48.515625 1:38.9531257 70 1:58.156250 1:48.609375

6.2.2. Test case 2 (with preemption): In this testmodule we show the comparison between theperformance of the existing implementation and themodified implementation by preempting the lastthread of an application which runs at the lower gradecompute resource (Executor 1) by the existing GridbusBroker scheduling algorithm. Firstly, we run theapplication with existing implementation and preemptthe last thread at Executor 1. We took the similarapproach described in the Test Module 2 to do thissection experiment. We preempted the job with 10

By using the modified file based implementationwe use the same technique but the second executordoes not need to start the job form the beginning. Asthe Executor 2 starts the job from last saved point it

Modified Existingimplementation implementation

(min: sec) min: secExec- Exec- Toge- Exec- Exec- Toge-utor 1 utor 2 ther utor 1 utor 2 ther6:45.7 3:01. 3:00. 6:47. 3:01.8 2:43.

344 4063 1094 2031 069 28126:44.9 3:00. 2:54. 6:48. 3:01.4 2:43.

817 4063 8594 1709 687 05706:44.1 3:00. 2:54. 6:47. 3:00.8 2:44.

986 1563 8906 5803 390 0196

Table 3: Comparison of execution time of anapplication with five threads between existing

and modified implementation

seconds interval and let the Executor 2 to execute thejob which can do the job much faster than the

8020 40 60Preemption at time nth (sec)

Figure 5: Comparison between twoimplementation with job pre-emption

oo

-.- Existing with Preemption --~- ~odified with Preemption J

140

'U'120~

~100

~ 80.c:"a 60r::'C 40~.a 20~

85

Figure 6: Performance comparison betweentwo implementations with job preemption

Table 4: Performance comparison betweentwo implementations with job preemption

implementation. It is known that, Grid thread is thelast unit of the job that is executed in the executornode. As we get better performance by using discussedapproach so we can propose that if this mechanismcan be added to the Gridbus Broker it can push theGrid computing one step further.

8. References

[1] A.B. Smith, C.D. Jones, and E.F. Roberts, "ArticleTitle", Journal, Publisher, Location, Date, pp. 1-10.

[2] Jones, C.D., A.B. Smith, and E.F. Roberts, Book Title,Publisher, Location, Date.

[1] S. Venugopal, R. Buyya and L. Winton, "A Grid ServiceBroker for Scheduling Distributed Data-OrientedApplications on Global Grids", Technical Report, GRIDS­TR-2004-1, Grid Computing and Distributed SystemsLaboratory, University of Melbourne, Australia, February2004.

[2] M. Maheswaran, S. Ali, H. 1. Siegel, D. Hensgen and R.F.Freund, Dynamic Mapping of a Class of IndependentTasks onto Heterogeneous Computing Systems, Journal ofParallel and Distributed Computing, Volume 59, Issue 2,November 1999, Pages 107-131.

[4] A. Samar, H. Stockinger. Grid Data Management Pilot(GDMP): A Tool for Wide Area Replication, IASTEDInternational Conference on Applied Informatics (AI2001),Innsbruck, Austria, February 2001, ACTA Press,Calgary,AB, Canada.

[5] A. Chervenak, E. Deelman, 1. Foster, L. Guy, W.Hoschek, A. Iamnitchi, C. Kesselman, P. Kunst, M.Ripeanu,B, Schwartzkopf, H, Stockinger, K. Stockinger, B.Tierney. Giggle: A Framework for Constructing ScalableReplica Location Services, Proceedings of Supercomputing2002 (SC2002), November 2002, IEEE Computer SocietyPress, Los Alamitos, CA, USA.

[3] C. Baru, R. Moore, A. Rajasekar, and M. Wan, TheSDSC Storage Resource Broker, in Proceedings of the 1998conference of the IBM Centre for Advanced Studies onCollaborative research (CASCON'98), Toronto, Canada,October 1998, ACM Press, New York, USA.

8020 Preemption ~q nth (sec) 60

-~- -+-Existing with Preemption -------=i=ModiftedWith Preemption --__Existing without Preemption

250

!200

.~ 150

.c:

.; 100I:

1:1

~ 50

.~"!. 0=­< 0

Application finish timeTest Preempt ( min: sec)Case time Existing Modified

(nth sec) Implementation Implementation1 2 2:25.406250 2:16.578125

2 10 2:25.312500 2:07.171875

3 20 2:27.921875 2:16.250000

4 30 2:32.500000 2:28.812500

5 40 2:41.937500 2:35.843750

6 50 2:51.859375 2:44.875000

7 60 3:01.156250 2:51.468750

8 70 3:10.734375 2:54.281250

Executor 1. This technique finishes the application inmuch lesser time in almost every case as we removethe bottleneck created by the lower grade executorthough the second executor stats the job form thebeginning. By using the modified file basedimplementation we use the same technique but as thesecond executor does not need to start the job form thebeginning. Since the Executor 2 starts the job fromlast saved point it has executed by the first executor, itreduces the execution time greatly. Thus this approachgives a greater degree of performance improvement,which we can clearly see in the Figure 6 and Table 4.

7. Conclusion

In this paper, a modified algorithm has beenpresented for the scheduling of the Gridbus broker. Byusing this modified file based implementation and thedescribed approach to reschedule the threads at runtime; it is clear that algorithm gives better timeimprovement with compare to the existing thread

[6] W. Hoschek, 1. Jaen-Martinez, A. Samar, H. Stockinger,K. Stockinger, Data Management in an International DataGrid Project, Proceedings of the 1st International Workshopon Grid Computing (Grid 2000, Bangalore,India), Springer­Verlag, Berlin, Germany, 2000.

[7] Harold Soh, Shazia Haque, Weili Liao, KrishnaNadiminti and Rajkumar Buyya, "GTPE: A ThreadProgramming Environment for the Grid".

86

[8] A. Luther, R. Buyya, R. Ranjan, and S. Venugopal,Alchemi: A .NET-based Grid Computing Framework and itsIntegration into Global Grids, Technical Report, GRIDS­TR-2003-8, Grid Computing and Distributed SystemsLaboratory, University of Melbourne, Australia, December2003.

87

[9] R. Wolski, N. Spring, and 1. Hayes, "The NetworkWeather Service: A Distributed Resource PerformanceForecasting Service for Metacomputing", Journal of FutureGeneration Computing Systems, Volume 15, Numbers 5-6,pp. 757-768, Elsevier Science, Amsterdam, Netherlands.