An Extended Algorithm to Enhance the Performance of …shoeb.info/wp-content/uploads/shoeb-iccet-2009.pdfAn Extended Algorithm to Enhance the Performance of the Gridbus Broker with

An Extended Algorithm to Enhance the Performance of the Gridbus Broker with Data Restoring Technique

Abu Awal Md. Shoeb, Altaf Hussain, Md. Abu Naser Bikas, and Md. Khalad Hasan Department of Computer Science & Engineering Shahjalal University of Science & Technology

Sylhet, Bangladesh {johnshoeb, altaf_sust_82, bikasbd}@yaho.com, [email protected]

Abstract—There are various types of Grids have been developed to support different types of Applications. The Gridbus broker that mainly focused on Data Grid mediates access to distributed resources by discovering suitable data and computational resources, job monitoring, accessing local or remote data sources during job execution, collecting and presenting results. In this paper, we present an enhanced version of Grid Service Broker scheduling on Global Data Grids with job restoration point. In the present version of scheduling algorithm, if any job associated with an application becomes failed during its runtime then the scheduling algorithm just marked the job as failed and reset. But it does not keep any track of the percentage of the work has already been done by the job. In Contrast, our proposed enhanced algorithm utilizes a restore point to store the proportion of task completed by an executor. In case of failure, it starts the job from that restored point rather than its initial point. From the experimental result, we have found that our proposed algorithm increases the performance of the present scheduling algorithm.

Keywords- Gridbus Broker, Data Grid, Data Restoration Technique, Data Restoration.

I. INTRODUCTION Grid computing is very useful in the large scientific

projects. A grate number of researcher organization and communities using grid computing to carry out their sheared resource out come. However the using of the power of Grid Computing remains to be a challenging problem for the users due to the complexity involved in the creation of the application and deployment on distributed computational resources. The Gridbus broker [1] is an advanced service-oriented meta-scheduler for data Grids. It supports different Grid middleware and services. It takes care of many functions that Grid applications require such as resource selection, job scheduling and management, data access to any distributed Grid resources and handling faults that may occur during execution, collecting result and presenting them. In Gridbus broker the task commands are encapsulated within an Agent which is dispatched to and executed on the remote machine. On completion of execution, the Agent returns any results to the broker and provides debugging information. The Monitoring component keeps track of job status – whether the jobs are queued, executing, finished successfully or failed. Here Gridbus broker does not keep track of the calculated

result of a failed job. In this paper we have present an enhanced version of Grid Service Broker scheduling on Global Data Grids with the failed job restoration point.

This paper is organized as follows: Section II discusses the Related Works and Section III shortly discusses Gridbus Broker Architecture and the problem scope of Gridbus Broker Architecture and Scheduling. Section IV elaborates our proposed algorithm to counteract the problems of Gridbus Broker Scheduling. Section V illustrates the Experimental Result and Performance Analysis of algorithm with some examples. We conclude in section VI.

II. RELATED WORK As the scheduling of independent jobs on distributed

heterogeneous resources [2] is a well-studied problem, so here we discussing only a few major work which deal with Grid. In the context of Data Grid, the Storage Resource Broker (SRB) [3] from San Diego Supercomputing Centre (SDSC) provides middleware for storing datasets over a network and accessing them. Although it does not deal with applications executing directly. The Gridbus broker extends the Nimrod-G [4] computational Grid resource broker model to distributed data-oriented grids. Nimrod-G specializes in parameter-sweep computation. However, the scheduling approach within Nimrod-G aims at optimizing user-supplied parameters such as deadline and budget [5] for computational jobs only. Like Nimrod-G, the AppLeS PST [6] supports deployment of parameter-sweep applications on computational grids, but its adaptive scheduling algorithm emphasizes on data-reuse. Harold, Shazia, Liao, Krishna, Buyya developed a Grid Thread Programming Environment (GTPE) [7] for the Gridbus Broker, a software grid resource broker that provide transparent access to grid services. However, it does not provide any way to save the output of thread at any point of it runtime. Venugopal, Buyya, Winton [1] focuses on a resource scheduling strategy within a Data Grid but concentrated on adaptive scheduling algorithms and brokering for heterogeneous resources that are shared by multiple user jobs.

Similar to [1], our work focuses on a resource scheduling strategy within a data Grid but we concentrate on runtime thread scheduling algorithms and brokering for heterogeneous

2009 International Conference on Computer Engineering and Technology

978-0-7695-3521-0/09 $25.00 © 2009 IEEE

DOI 10.1109/ICCET.2009.233

371

resources that are shared by multiple user jobs. However our work focuses on failed job and reusing the execution time by creating restoration point. Our modified ‘File based Grid Thread Implementation’ provides a way of saving the output of a thread at any point of its life time.

III. GRIDBUS BROKER OVERVIEW The Gridbus broker inputs are considered as task and the

parameter values associated with the task. The parameters can be static or dynamic. Among the other component the Grid Index Information service (GIIS), gathers information from remote information services i.e. availability and the properties of compute resources. The Data Service Catalogue organizes the data files as Logical File Names (LFNs). Network weather service (NWS) obtains the information about the current available bandwidth between the data sources and the compute resources. Global Access to Secondary Storage (GASS) obtains the inputs or parameter file form the secondary storage if 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 Monitor keeps track of job status, whether the jobs are queued, executing, finished successfully or failed. A task is further considered as sequence of commands that focuses user requirements. The task along with its associated parameters decomposed in to jobs. 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 an input to the scheduler. For jobs requiring remote data, it interacts with a NWS to obtain the information about current available bandwidth between the data sources and the compute resources. It then uses this information to schedule jobs by optimizing on the amount of data transfer involved.

In the current implementation, the jobs are dispatched to the remote node through the Actuator component. The Actuator submits the job to the remote node using the functionality provided by the middleware running on it. The Actuator has been designed to operate with different Grid middleware frameworks and toolkits such as Globus 2.4 [9] that primarily runs on Unix-class machines and Alchemi [10], which is a .NET based grid computing platform for Microsoft Windows-enabled computers. The Gridbus broker scheduling algorithm schedules a job depending compute resources and data host associated with a job that is to be deployed to an executor. Firstly it gathers the information about the compute resources and data hosts using GIIS and Data Service Catalogue and determines the job completion rate for every compute resources for its history. For a job to be deployed, identifies the data hosts associated with that job and for every pair of data and compute resources, it finds the pair with earliest job completion rate and if such a pair exist the scheduler assigns the job to that pair. After the job has successfully finished at the remote node (i.e. executor), its returns any results to the Broker. If any job became failed, it is marked as failed and reset for rescheduling.

A. Problem Scope of Gridbus Broker Architecture And Scheduling When a job is executed in the remote node (i.e. executor),

the Agent returns any results to the broker. If any jobs are

failed during execution, the Agent does not return the output file (i.e. remote data) to the broker, it returns only the status of the job whether the jobs are finished successfully or failed. If a job becomes failed the job is marked as failed and reset for rescheduling without considering the job has been done so far. We all know that, in a network or Internet based application there is a high possibility that a GRID node can be interrupted for the inconsistent nature of the network. In the existing implementation there is no mechanism to save the percentage of job result to be recovered when the job is failed. As the GRID job can be a huge one so the lost of the job can cause a critical time factor. For example, scheduler submits a job to a Grid node that is 30 minutes long. If that job is lost or failed after 27 minutes of successful execution then the scheduler will reassign the job without using the results or data of the last 27 minutes. So the job will take roughly 57 (27+30) minutes rather than 30 minutes.

IV. PROPOSED SOLUTION Our proposed solution, we have kept the track of running job. Suppose, the remote node is failed after 90% of the job is completed, then the Agent will return the output file (i.e. remote data) with the job status to the broker. Since the job status is failed, the job is reassigned to another remote node with the last generated output file (i.e. last remote data) to restart the job from the failed point (i.e. from the 90%, not from the beginning). In our application (File Based GRID Thread Implementation), we created a random access file associated with each thread and writing the results to that file and thus creating restoration point. The file only contains the last two computed output of a thread. The file size depends on the type of application but in our application we managed it to be quite small. This generated file is stored in the Manager Node. Manager can reassigns that thread to any executor node with the same thread ID from the thread pool. A priority for each thread can be explicitly specified when it is created or submitted. Threads are scheduled on a Priority and First Come First Served (FCFS) basis [8], in that order. When the Manager distributes the thread to any Executor node, the node first check if there is any file is available with its own thread id. If any file is available for that thread, the node then recovers the resultant value of that thread from the file created and starts execution from the recovered value. If no file is found for that thread then the thread will start execution from the beginning and also create a file in the Manager Node using Thread ID (i.e. filename) as Thread ID remain same throughout the lifetime of an application. In the global grid environment, these generated restoration file can be stored in the remote data host assigned with that for that Grid node or can be stored in some different host depending on the bandwidth and cost of data transfer etc. For the jobs requiring remote data, the scheduler interacts with the

Figure 1: Modified Adaptive scheduling algorithm for Data Grid

372

Initialization 1. Identify characteristics, configuration, capability, and suitability of compute resources using the Grid information services (GIS). 2. From the task definition, obtain the data query parameters (if present), such as the logical file name a. Resolve the data query parameter to obtain the list of Logical Data Files (LDFs) from the Data Catalog. b. For each LDF, get the data sources or Data Hosts that store that file by querying the Data Catalog. Scheduling Loop Repeat while there exists unprocessed jobs. [This step is triggered for each scheduling event. The event period is a function of job processing time, rescheduling overhead, resource share variation, etc.]: 3. For each compute resource, predict and establish the job consumption rate or the available resource share through the measure and extrapolation strategy taking into account the time taken to process previous jobs. Use this estimate along with its current commitment to determine expected job completion time. 4. Repeat if there exists any previously failed job a. Select the restoration file host (data host) that contain LDF associated with that job. b. Repeat from 6(b) to 6(d). c. If there exits such a resource pair, then assign the job to compute resource and remove it from the Failed-Jobs-List. 5. If any of the compute resource has jobs that are yet to be dispatched for execution and there is variation in resource availability in the Grid, then move such jobs to the unassigned-Jobs-List. 6. Repeat until all unassigned jobs are scheduled or all compute resources have reached their maximum job limit. a. Select the next job from the Unassigned-Jobs-List. b. Identify all Data Hosts that contain the LDF associated with the job. c. Create a Data-ComputeResource-List for the selected job: • For each data host, identify a compute resource that can complete the job earliest given its current commitment, job completion rate, and data transfer time using current available bandwidth estimates. d. Select a data host and compute resource pair with the earliest job completion time from the Data-ComputeResource-List. e. If there exist such a resource pair, then assign the job to the compute resource and remove it from the Unassigned-Jobs-List. 7. End of scheduling loop.

Network Weather Service (NWS) [11] to get the current bandwidth condition. We can create a new instance for the restoration file in the Logical File Names (LFNs) which maps to Physical File Name of the restoration file stored in the appropriate location

or data host. This instance can be updated and can use for the selection of the restoration file host. The Gridbus broker can resolve the restoration files by querying the Data Service Catalogue.

In the case of job failure, the LFNs instance can be updated that map the Physical File Names of the restoration files. When the scheduler reschedules that failed job for execution, the restoration file can be assigned with that job. This technique enables the new executor can retrieve the saved file from the data host before execution and stat execution from that successful executed point. Thus this data restoration technique saves the execution time for a failed job, as we did not need to start executing the job from the very beginning.

Depending on this approach, we modified the existing scheduling algorithm of the Grid bus broker. The modified Gridbus broker scheduling algorithm is stated in Figure: 1. We added a new module (Module: 4) in the existing algorithm for rescheduling the failed job. This algorithm gives us a way of rescheduling the failed job so that we can utilize the saved output the thread executed before being failed.

V. EXPERIMENTAL RESULTS AND PERFORMANCE ANALYSIS

Here, we have considered thread as job and implemented a file based GRID thread implementation using Alchemi Toolkit so that we can restore the lost or failed thread result. The details description of the file based Grid thread implementation is beyond the scope of this paper. Here we have found that our modified approach gives better performance than the existing approach in almost every case. The performance of modified approach depends on how long a thread is executed before it is being failed. The much longer a thread is executed before it is being failed the much better the performance is obtained by our modified file based implementation. To evaluate the performance analysis we have developed one Application program in two different approaches. One of them is existing approach (where failed thread starts its execution from its initial state) and another one is our file based approach. In second approach, we can save the output of any thread. This technique enabled us to create the restoration point of any thread. By utilizing these restoration points, we can start the failed job form the last saved point. Here we have shown different performance comparison table where our modified approach gives better performance than the existing approach in every case. The performance of modified approach depends on how long a thread is executed before it is being failed. The much longer a thread executed before it is being failed the much better performance is obtained by our modified file based implementation.

In both program, same input is used to compare between them, both give the same result as well. Both application give the total number of factors of a given input value (e.g. 10^10). For comparing between the two implementations we have taken different datasets in two different scenarios.

373

A. Scenario-1 (Considering No Thread Failure) 1) Here, different number of thread has been executed

using both algorithm where all the threads successfully executed in the Executor node without any interruption and returned the result to the Manager node.

TABLE I. OVERHEAD OF OUR MODIFIED ALGORITHM WITH COMPARED TO THE EXISTING ONE WHEN NO THREAD IS INTERRUPTED

Time Taken (min) Test Cases

# of Thread

Previous Algorithm

Modified Algorithm

Overhead (sec)

1 3 0:55.37500 0:56.328125 0.953125 2 5 1:35.81250 1:39.140625 3.328125 3 8 2:41.71875 2:43.906250 2.1875 4 15 4:25.62500 4:31.437500 5.8125

Table 1 shows a slight overhead of our modified algorithm. This overhead indicates the time access file. From the above comparison, we clearly see that the exiting procedure is better when the number of thread is small but when the number of thread increases the modified approach finish the thread almost at the same time. File read and writes overhead is negligible when number of thread increases.

B. Scenario-2 (Threads Are Terrupted) Two approaches have also been compared where one or

more threads have been failed during execution time and rescheduled by the manager. For all the test cases we use: Input Value = 1000000000 Average Thread Execution Time = 19 sec (measured without interruption) Time between the interrupt and restart a thread = 5 sec Condition 1 No of Thread = 1 The Thread is interrupted at different time counting from the start of the execution.

TABLE II. TIME SAVED BY THE MODIFIED ALGORITHM WITH COMPARED TO THE EXISTING ONE WHEN ONLY ONE THREAD IS INTERRUPTED AT DIFFERENT TIME

Time Taken (sec) Test Cases

Interrupted Time

(nth Sec) Previous Algorithm

Modified Algorithm

Saved Time (sec)

1 5 30.56250 23.125000 7.437500 2 10 32.65625 23.015625 9.640625 3 15 36.65625 27.453125 9.203125

From the above comparison, it is clear that in every case our modified approach gives better performance (i.e. time improvement) than the exiting approach. It is also clear that modified implementation performs well when a thread fails after maximum execution of its lifetime.

Condition 2 No of Thread = 3

Different number of threads has been interrupted and datasets are taken using both algorithm.

TABLE III. TIME SAVED BY THE MODIFIED ALGORITHM WITH COMPARED TO THE EXISTING ONE WHEN MULTIPLE THREADS ARE

INTERRUPTED

Previous Algorithm Modified Algorithm Test Cas

e

Thread No

Is

Interrupted?

Time Per Thread (sec)

Total Time (min)

Time Per Thread (sec)

Total Time (min)

1 Yes 36.843750 26.562500 2 No 17.718750 17.890625

1

3 No 18.703125

01:13.28

125 18.765625

01:03.250000

1 Yes 37.906250 27.328125 2 No 17.781250 18.796875

2

3 Yes 39.406250

01:35.09

375 28.046875

01:14.171875

1 Yes 41.937500 26.343750 2 Yes 40.515625 25.843750

3

3 Yes 42.500000

02:04.96

875 25.843750

01:18.031250

020406080

100120140

0 1 2 3 4

No of Failed Thread

Tota

l Tim

e Ta

ken(

sec)

Existing Implementation Modified Implementation

Figure 2: Comparison between the two implementation in case of thread failure

From the Table 3 and Figure 2, it is clearer that, modified algorithm gives better result when one or more thread fails during execution and performance is enhanced when the degree of failure of thread increases in GRID environment.

As we can save the result of a failed thread and have shown that this file based implementation gives better performance and if we consider this approach in job we can say that our proposed modified algorithm will obviously give better performance than the existing Gridbus broker scheduling algorithm.

VI. CONCLUSION In this paper, a modified algorithm has been presented for

the scheduling of the Gridbus broker. We implemented an extended GRID thread application program where we showed that using file based modified algorithm gives better time improvement with compare to the existing thread implementation. As Grid thread is the last unit of the job that is executed in the executor node and if the file based approach is used for failed job then our modified Gridbus broker algorithm gives better performance than the existing Gridbus broker

374

scheduling algorithm. Thus, it has the potential to push the Grid computing one step further.

REFERENCES [1] Venugopal, S., Buyya, R., Winton, L.: A Grid Service Broker for

Scheduling Distributed Data-Oriented Applications on Global Grids. In: Proceedings of the 2nd Workshop on Middleware in Grid Computing (MGC 04): 5th ACM International Middleware Conference (Middleware 2004), Toronto, Canada (2004)

[2] M. Maheswaran, S. Ali, H. J. Siegel, D. Hensgen and R. F.Freund,

Dynamic Mapping of a Class of Independent Tasks onto Heterogeneous Computing Systems, Journal of Parallel and Distributed Computing, Volume 59, Issue 2, November 1999, Pages 107-131

[3] C. Baru, R. Moore, A. Rajasekar, and M. Wan, The SDSC Storage

Resource Broker, in Proceedings of the 1998 conference of the IBM Centre for Advanced Studies on Collaborative research (CASCON’98), Toronto,Canada, October 1998, ACM Press, New York, USA.

[4] D. Abramson, J. Giddy, and L. Kotler, High Performance

Parametric Modeling withNimrod/G: Killer Application for the Global Grid?, Proceedings of the International Parallel and Distributed Processing Symposium (IPDPS 2000), May 1-5, 2000, Cancun, Mexico, IEEE Computer Society Press, Los Alamitos,CA, USA.

[5] R. Buyya, D. Abramson, and J. Giddy, an Economy Driven

Resource Management Architecture for Global Computational Power Grids, Proceedings of the 2000 International Conference on Parallel and Distributed Processing Techniques and Applications (PDPTA 2000), June 26-29, 2000, Las Vegas, USA, CSREA Press,Las Vegas, USA, 2000.

[6] H. Casanova, G. Obertelli, F. Berman, and R. Wolski, The AppLeS

Parameter Sweep Template: User-Level Middleware for the Grid, Proceedings of the IEEE SC 2000: International Conference Networking and Computing, Nov. 2000, Dallas, Texas, IEEE Computer Society Press, Los Alamitos, CA, USA.

[7] Harold Soh, Shazia Haque, Weili Liao, Krishna Nadiminti and

Rajkumar Buyya, “GTPE: A Thread Programming Environment for the Grid”, Proceedings of the 13th International Conference on Advanced Computing and Communications (ADCOM 2005, Allied Publishers, Mumbai, India, ISBN: 81-8424-109-7), December 14-17, 2005, Coimbatore, India.

[8] Srikumar Venugopal, Rajkumar Buyya and Lyle Winton, A Grid

Service Broker for Scheduling e-Science Applications on Global Data Grids, Concurrency and Computation: Practice and Experience, Volume 18, Issue 6, Pages: 685-699, Wiley Press, New York, USA, May 2006

[9] Ian Foster and Carl Kesselman, “Globus: A Metacomputing

Infrastructure Toolkit”, International Journal of Supercomputer Applications, Volume 11, Issue 2, pp.115-128, MIT Press, Boston, MA, USA, 1997.

[10] A. Luther, R. Buyya, R. Ranjan, and S. Venugopal, Alchemi: A

.NET-based Grid Computing Framework and its Integration into Global Grids, Technical Report, GRIDS-TR-2003-8, Grid Computing and Distributed Systems Laboratory, University of Melbourne, Australia, December 2003.

[11] R. Wolski, N. Spring, and J. Hayes, “The Network Weather

Service: A Distributed Resource Performance Forecasting Service for Metacomputing”, Journal of Future Generation Computing

Systems,Volume 15, Numbers 5-6, pp. 757-768, Elsevier Science, Amsterdam, Netherlands.

375