1

A Development to Grid Resource Management using Grid Broker

Sonchaya Rojanavipat1, Sivadon Chaisiri2, and Putchong Uthayopas3

High Performance Computing and Networking Center,
Faculty of Engineering, Kasetsart University
50 Phahoyothin Rd., Chatuchak, Bangkok 10900 Thailand
Email: {g4765412, g4665304, pu}@ku.ac.th

Abstract
Grid computing is a technology that allows the possibility of sharing distributed
resources among multiple organizations. Therefore, not only a middleware and its services are
needed, but also a resource management component that hides the complexity of accessing
and discovering of Grid resources from users. In this paper, we present the design and
implementation of a Globus tool kit Version 4.0 compatible Grid resource broker. This broker
allows users to easily discover the resource and helps management the resource usage to
maximize users and system benefits. This paper also presents the experimental results to
demonstrate the resource broker performance and the performance of a proof of concept
application. This works helps simplify the usage of Grid system for programmer while
delivering a better performance out of a Grid system. The prototype system has been
implemented and a drug design application is used to evaluate the system. The experimental
results show that this system can function well in a heterogeneous distributed system.

Keywords: Grid resource broker, Grid computing, Globus tool kit, Resource Management,
Grid Service.

1. Introduction
Grid Computing [1] is a technology that enable the sharing and accessing of
geographically dispersed resources. One approach of using the Grid System is to submit the
job into the system using grid aware job scheduler [1]. The Grid scheduler accepts a job
submission from users, select the appropriate computing resources and send the job to be
executed on those computing resources. After the computation finished, scheduler also collect
the results and deliver them to users. Grid Resource Allocation Management (GRAM) [1] is a
service that Grid provides for the access and management of resources. Fig. 1 (a) illustrates
the step involved. The efficiency of this system is depends on the suitability of the jobs and
resources capability.
With in the past few years, grid computing system is moving towards the approach of
Service Oriented Architecture (SOA) Grid. In this approach, Grid system is viewed a offering
a rich set of services. Application can be developed by creating a workflow that invokes these
services accordingly. In this kind of system, a new component called Grid Broker becomes an
important component. Grid Broker [13] is system component that manage the searching and
selecting of the suitable resources and provides a location and access information for the
applications. Grid Broker can rely on resources discovery [6] service of the system to selects
data, network, locations of resources, and other services. When Grid Broker received the data
from Resources Discovery, it will match the resources with user’s demands and select the
most suitable one. Then, Grid Broker sends the locations of the suitable resources to the
application. Finally, the application can invoke the selected resources to accomplish the task.
These steps are as shown in Fig. 1(b)
This paper presents the design and development of a Grid Broker that work under
Globus 4.0 grid system. The organization of this paper is as follows. Section 1 is the
introduction followed by the related works in Section 2. Section 3 describes the proposed
work which is applied and evaluate in Section 4. Finally, Section 5 gives a conclusion and
future works.

1
This work has been supported in part by Thai National Grid Project and Kasetsart University SRU
funding.
 Fig. 1. The operation of Grid Scheduler and Grid Broker

2. Related Works
In 1991, Common Object Request Broker Architecture (CORBA) [15] was developed
to be the architecture and regulations for the building and distributing of object under network
environment. The main concepts of CORBA are Object Request Broker (ORB) and ORB
supports network of clients and servers on heterogeneous computers. Thus, a client program
can request for the service from server located practically anywhere on the network. Anyway,
COBRA require a tightly couple interaction and complex protocol which lead to some
limitation in term of scalability.
In 2001, Tordson [11] proposed a system of resource brokering for Grid environment
that can choose resources by considering the work load and efficiency of the resources. Then,
broker selects a suitable resource for the application program. The goal is to reduce the
execution time of the application programs. The algorithm used are called Total Time to
Delivery (TTTD), with consider the characteristics of the application, the order of work, and
the input and output of work. In [18], Chapman presents another project called EZ-Grid
Project. The goal of this project is to build a broker that increases the efficiency of the
execution and control resources sharing of under the organization. The work proposes the
design of an automatic resource discovery system and prepared resources according to the
policy used. Cavatieri and Monforte[14] also proposed another resource broker architecture
and APIs .
In 2002, Abramson et al. proposed a system called Nimrod/G [16] which consists of a
broker that control and manage the parametric execution of jobs under Grid environment. An
architecture called GRACE (Grid Architecture for Computational Economy) has been
proposed. This GRACE architecture composes of global scheduler, bid-manager, and
directory server. One of the major parts in broker system is the resources discovery system
that works with the scheduling policy. These system helps user to optimize the budget and
deadline. Within the same year, Frey proposed Condor-G [17], which was developed from
Condor [19] but extended to work with Globus [3]. The users can control and manage
resources by creating a Condor resources pool from Globus. The mechanism called Glide-in
is built to allow a user to access and execute their job on any resource that belongs to that
pool. Condor-G uses Condor matching service to match the resources and job together.
In the previous year, Kim proposed a design and implementation of an OGSI-
Compliant Grid Broker Service [12]. This service tries to give the retrieval suitable resources
for the users.

3. Proposed Work
 In this paper, a design of a Grid broker called GustoFarms Grid Broker (GGB) is
discussed. The detail of this Grid Broker system and architecture are explained in the
following sections.

APPLICATION

API

QS

RSS RMS JSS JMS

CORE SERVICES
Resource Discovery

GUSTOFarm
SCMSWeb
JXTA

PC Farms

Fig. 2. The architecture of GGB

In Fig. 2, shows the architecture of GGB. The system has been divided into 5 layers as
follows:
1) PC Farms Layer is the lowest level; This layer consists of computing nodes that are
connected together using a network. To support cross platform capability, Java Runtime
Environment (JRE) is chosen to be an operating environment.
2) Resource Discovery Layer is a layer that collects and registers all services provided by
system and users. Currently, a previously developed system called GUSTOFarm has been
used .
3) Core Service Layer that provides various services for the system and applications. The
following the services are planned;
· Query Service (QS) is the resource query service that receives the requirement from
application and then forwards to RDS.
· Resource Selection Service (RSS) selects the suitable resource to the user’s
requirement.
· Resource Monitor Service (RMS) monitor resource status such as speed and loading
of processor, size of memory space left.
· Job Submission Service (JSS) is the service that sends the job to computing
resources for the processing.
· Job Monitor Service (JMS) is the service that shows the progress of job execution.
4) Application Programming Interface Layer (API) provides a set of API that users can use to
develop applications and tools for this system.
5) Application Layer is consists of users’s application that perform various works according
to users demands.
The processing steps required to initiate any services is as illustrated in Fig. 3. This steps are
as explained below.
1) A client requests the URL of Grid service on any compute nodes from the broker.
2) The Grid broker runs the resource selection algorithm and returns the URL of the chosen
compute node to requested client.
3) Client invokes Grid service on selected a compute resource.
4) The compute resource executes the service using inputs from the incoming request. Then,
results of the computing are returned to client.
The following section presents the realistic application of this system and shows the
performance attainable from the real application.
 Client node Front-End Compute node

t0 1) Discovery a URL of Grid Service

TRequire 2) Return the most TQuery

suitable URL

3) Call the Grid Service by policy

TComp
TSComp
4) Return result

tn

Fig. 3. Processing steps under GGB system

4. Evaluation
To evaluate the performance of the GGB framework, we develop a program based on
master -worker computing model. We implement a utility service as a worker application by
java Gird service development library named “Apache Axis” [10]. The utility service
provides a function for docking a Ligand and enzyme of autodock service. The code of
docking is improved from open-source software by drug design project under ThaiGrid[19].
The autodock application is being converted to Grid Service. We use a autodock service for
every testing. The Fig. 4 shows the final of drug design .

Fig. 4. The docking of Ligand and enzyme after processing by autodock service

4.1 Experimental Environment

We prepared the testing environment using 5 computers. One of these computers is
Cluster, called Helios, installed with Linux. The system uses AMD Opteron 64-bit 1.8 GHz
dual processor, 2 GB RAM. This machine is used to install Grid Broker system. Another 4
computers are AMD Athlon 64-bit 2.0 GHz processor, 2 GB RAM. We have installed
GUSTOFarm framework and announced the services in each computer to broker. The
services used are autodock grid service. For the client machine, an AMD Turion 64-bit, 1.6
GHz; 512 MB RAM are used . This machine installed with Window XP. Globus is used as a
middleware. Globus Version 4.0 has been installed on all nodes.

4.2 Experimental Results

We conducted two experiments. First, we measured the time spent when client send
a query service of autodock service to the Grid broker system to search for the services. We
have tested by recording the searching time of each query. The numbers of query are 1,
10,100,1000,10000. In the testing, we repeat the experiments for 10 times and use the average
value as a result. The results obtained are shown in Table 1 and in Fig. 5.

Table 1 Average Respond Time

No of queries Time (sec.)

1 0.400
10 2.831
100 10.153
1000 61.940
10000 511.644

Response Time

0.450
0.400
0.350
0.300
Time (s

0.250
Time/Query (s)
0.200
0.150
0.100
0.050
0.000
1 10 100 1000 10000
No.Query

Fig. 5. Average Responding Time for Query Service

We have found that the respond time increases with more simultaneous access. The
numbers of query from 1, 10, 100, and 1000 is reasonably fast. The query time is less than
100 seconds. If we consider that the running time of autodock service is about 10-20 minutes,
the discovery time is lower than 10%. When number of simultaneous query reaches 10000 the
response time is about 500 seconds, thus, there is some concern about scalability at this point.
Anyway, we can safely claim that the broker work fine for less than 1000 simultaneous client
which is a reasonably large system.
For the second experiment, we tested the load balancing algorithm used by creating a
client program that send multiple requests to the broker system. Two load balancing
algorithm has been built into the broker which is round-robin and random selection.
Therefore, we tested the case where no load balancing has been used against two load
balancing algorithm implemented. We record the time spent for the requests. The experiment
was repeated for ten times and the average value is presented in Table 2. The speedup and
efficiency of the computation are also calculated and presented in Table 3 and 4. The plot of
speedup and efficiency is as show in Fig. 7 and 8

Table 2 average running times used to process the docking (minutes) for 1, 2, 3, and 4 nodes system.

Load Balancing Number of compute node

Algorithm
1 2 3 4
Round-Robin 93.06 56.74 38.58 31.35
Random 254.05 224.63 126.42 84.87
Not Load 448.32 407.72 587.04 498.75
Balancing
Table 3 Speedup computed from Table 2.

Load Balancing Number of compute node

Algorithm
1 2 3 4
Round-Robin 1.00 1.64 2.41 2.97
Random 1.00 1.13 2.01 2.99
Not Load 1.00 1.10 0.76 0.90
Balancing

Table 4 Efficiency of the processing computed from Table 2 and 3.

Load Balancing Number of compute node

Algorithm
1 2 3 4
Round-Robin 1.00 0.82 0.80 0.74
Random 1.00 0.57 0.67 0.75
Not Load 1.00 0.55 0.25 0.23
Balancing

From the experimental results it can be seen that the average running time is decreasing when
we use more compute nodes. Both round robin and random distribution result in faster
execution. This is a direct result from a better workload distribution due to the use of Grid
Broker. Hence, this proves that Grid Broker and Grid service based implementation only add
a slightly more overhead but results in a much better system performance. This speedup
eventually levels off due to the high overhead inherent to the system. If more machines are
available for testing, we may be able to determine this limit. In addition, when we consider
the system’s efficiency (define as the speedup divided by number of compute nodes), the
efficiency of the system tends to decrease when the number of node increases. Without the
load balancing, efficiency of the system degrades faster. This can clearly be seen in Fig. 7.

Average Running Time

700
_

600
500
Round Robin
400
Random
300
Time (min)

Not Load Balancing

200
100
0
1 2 3 4
Number of compute node

Fig. 6. Average running time

Speed up

3.50
_

3.00
2.50
Round Robin
2.00
Random
1.50
Not Load Balancing
Speed up

1.00
0.50
0.00
1 2 3 4
Number of compute node
 Efficiency

_
1.20
1.00
0.80 Round Robin
0.60 Random
Not Load Balancing

Efficiency
0.40
0.20
0.00
1 2 3 4
Number of compute node

Fig. 7. Speedup and Efficiency of the Prototype Application

5. Conclusion
In paper, we presented a development of a Grid resource management using Grid
Broker, which can help improve system performance can scalability by choosing right
resources for client application. The experimental application using computational chemistry
shows that system work well and helps increase system performance. Furthermore, with a
built-in load balancing, system performance can further increases. In the future, more testing
and deployment will be done to improve the implementation. This also includes the
development of a new load balancing that capitalizes more on the Grid characteristics.
Finally, we develop GGB in order to help users increase the system usage efficiently and
hope to improve GGB until it becomes a real useful system for the Grid community.

6. References
[1]. (Foster a, 1998) I. Foster, C. Kesselman (eds.). “Computational Grids,” The Grid:
Blueprint for a New Computing Infrastructure, Ch. 2, Morgan-Kaufman, San Francisco, 1998.
[2]. (Foster b, 2001) I. Foster, C. Kesselman, S. Tuecke, “The Anatomy of the Grid –
Enabling Scalable Virtual Organizations,” Proc. of First IEEE/ACM International Symposium
on Cluster Computing and the Grid, pp: 6 -7, 2001.
[3]. (GT4) Globus Toolkit 4 ,”A Globus Primer”,http://www.globus.org.
[4]. (Foster e, 2002) I. Foster, C. Kesselman, J. Nick, S. Tuecke, “The Physiology of the Grid:
An Open Grid Services Architecture for Distributed Systems Integration,” Open Grid Service
Infrastructure WG, Global Grid Forum, 2002.
[5]. (Hoschek b, 2002) W. Hoschek, “The Web Service Discovery Architecture,” Proceedings
of the 2002 ACM/IEEE conference on Supercomputing, pp: 1-15, 2002.
[6]. (Iamnitchi c, 2002) A. Iamnitchi, “Resource Discovery In Large-Scale Distributed
Environments,” Doctoral thesis proposal, University of Chicago, 2002.
[7]. (Krauter, 2000) K. Krauter, R. Buyyaa, and M. Maheswaran, “A Taxonomy and Survey
of Grid Resource Management Systems,” Technical Report: Manitoba University (Canada)
and Monash University (Australia), 2000.
[8]. (O. Ossama 2003) Ossama Othman, Jaiganesh Balasubramanian, and Douglas C.
Schmidt, “The Design of an Adaptive Middleware Load Balancing and Monitoring
Service,”in LNCS/LNAI: Proceedings of the Third International Workshop on Self-Adaptive
Software, Heidelberg, June 2003, Springer Verlag.
[9]. (Law, 2000) C. Law, Kai-Yeung Siu, “An O(log n) randomized resource discovery
algorithm,” The14th International Symposium on Distributed Computing, Technical Report,
Technical University of Madrid, pp: 5-8, Oct. 2000.
[10] The website of Apache Axis – An implementation of the SOAP,
“http://ws.apache.org/axis”,
[11]. (Johan Tordsson) ,” Resource Brokering for Grid Environments” , Master Thesis,
Department of Computer Science, Umea University, Sweden,
http://www.cs.umu.se/~tordsson/thesis/index.html
[12]. (Kim Y.) Young-Seok Kim,”Design and Implementation of an OGSI-Compliant Grid
Broker Service “ IEEE ccgrid 2004, 19-22 April, Chicago, Illinois, USA.
[13]. (Enis Afgan) Enis Afgan,”Role of the Resource Broker in the Grid”, Proceedings of the
42nd annual Southeast regional conference, Huntsville, Alabama , Pages: 299 - 300 , 2004.
[14]. (S. Cavalieri) S. Cavalieri and S. Monforte,” Resource Broker Architecture and APIs”,
Technical Report, University of Catania-DIIT. http://server11.infn.it/workload-grid/internal-
documents.html
[15]. (V. Steve1998) Steve Vinoski,“ New Features for CORBA 3.0 “ ,
www.iona.com/hyplan/vinoski/cacm.pdf
[16]. (D. Abramson 2002)D. Abramson, R. Buuya and J. Giddy,” A Computational Economy
for Grid Computing and its Implementation in the Nimrod-G Resource Broker”,Future
Generation Computer Systems.18(8),202.
[17]. (J. Frey 2002)J. Frey, T. Tannenbaum, I. Foster, M. Livny, and S. Tuecke, “ Condor-
G:A Computation Management Agent for Multi-Institutional Grids”Cluster
Computing.5(3):237-246,2002.
[18]. (B. Chapman 2001)B. Chapman et al, “EZ-Grid Resource Brokerage System”,
http://ww.cs.uh.edu/~ezgrid/,2001.
[19].Sriprayoonsakul Somsak, “Drug Design with Computation Grid Technology” ,
http://tgcc.cpe.ku.ac.th/drugdesign.
[20] L. Gong, “JXTA: A Network Programming Environment”, IEEE Internet Computing, v,
5. pp. 88-95,2001
[21] S. Chaisiri and P, Uthayopas, “Building a Utility Computing Infrastructure using
GUSTOFarm”, Master Thesis, Department of Computer Engineering, Faculty of Engineering,
Kasetsart University, 2005.