Architecture Model for Information Service in Large Scale Grid ...

Architecture Model for Information Service in Large Scale Grid Environments Wei Jie Terence Hung Institute of High Performance Computing, Singapore {jiewei, terence}@ihpc.a-star.edu.sg

Abstract The Information Service is a core component in the Grid software infrastructure. It provides diverse information to users or other service components in Grid environments. In this paper, we propose an Information Service architecture model for information management in a Grid Virtual Organization (VO). This Information Service is a hierarchical structure which consists of the VO layer, site layer and resource layer: at the resource layer, information agents and pluggable information sensors are deployed on each resource monitored. This information agent and sensor approach provides a flexible framework that enables specific information to be captured; at the site layer, a site information service component with caching capability aggregates and maintains up-to-date information of all the resources monitored within an administrative domain; at the VO layer, a peer-to-peer approach is used to build a virtual network of site information services for information discovery and query in a large scale Grid VO. This decentralized approach makes information management scalable and robust. Our Information Service has been implemented based on the Globus Toolkit 4 as a Web service compliant to the Web Services Resource Framework (WSRF) specifications. The experimental results show that the Information Service presents satisfactory scalability in handling information for large scale Grids.

1. Introduction The Grid is a large scale distributed system that supports scattered communities to form Virtual Organizations [1]. In a Grid environment, the description, discovery, and monitoring of resources (e.g. hardware, software, data, instruments) is very

Stephen J. Turner Wentong Cai Nanyang Technological University Singapore {aswtcai, assjturner}@ntu.edu.sg

challenging due to the diversity, large numbers, transient membership, dynamic behaviour, and geographical distribution of the entities in which a user might be interested. Consequently, Information Services [2, 3] are a vital part of any Grid software infrastructure, providing a fundamental mechanism for discovery and monitoring, and hence for planning and adapting application behavior. There are quite a few existing works on Grid Information Services. The most typical work is the MDS (Monitoring and Discovery System) [4] in the Globus Toolkit [5]. The MDS is an Information Service for information management in Grids. It provides interfaces for information management like generating, aggregating and accessing of information data from Grid resources. However, we believe there are still gaps between current Information Services and users’ expectations in the following aspects:  Performance Scalability: an Information Service should have appropriate architecture and mechanisms to efficiently collate and manage information spanning from the small data size of a single resource to the large data size of a Grid VO. The MDS uses local Index Services to build a hierarchical VO-wide centralized Information Service, but increasing numbers of users and a growing amount of information aggregated cause a bottleneck at the VO Information Service and thus quickly make this model ineffective.  Information Diversity: currently MDS provides adequate core information (e.g., hardware information), but other information provisioning is still lacking. A Grid Information Service should provide information beyond data currently provided by MDS, such as information that is needed by other Grid services and components (e.g. workflow service, execution management service, data management service, etc) or specific users and communities.

Proceedings of the Sixth IEEE International Symposium on Cluster Computing and the Grid (CCGRID'06) 0-7695-2585-7/06 $20.00 © 2006 IEEE

 Information Extensibility: a Grid Information Service should provide mechanisms to handle the dynamic changing of information sources in a Grid environment (e.g. to capture and monitor newly added information sources; remove outdated information sources, etc). The MDS provides an information provider mechanism to collect new information, however, runtime hot plug-ins of new information providers are not supported.  Information Accuracy: real-time monitoring requires Grid Information Services to provide upto-date data especially for highly dynamic information. Many current Information Services like MDS handle mostly static information, but lack dynamic information provisioning and efficient caching mechanisms.  Information Security: the information service should incorporate security mechanisms such as authentication, authorization and access control, to protect information from unauthenticated and unauthorized access. MDS uses GSI (Grid Security Infrastructure) as a basic security mechanism, however, Globus GSI is a general security framework, and it does not provide mechanisms catering to the specific security requirements of Grid Information Services.  Resource Diversity: in order for MDS to collect information from resources, usually the resources should have the Globus Toolkit deployed. In practice, Grid Information Services should provide flexible information capturing infrastructures to monitor both Globus-enabled and non Globusenabled resources.  Service Manageability: a VO-wide Information Service may consist of quite a few sub-components or services. The management of such a complex service (e.g. installation, deployment, start up and shut down) may incur a lot of administration overheads. To reduce human intervention, a deployment tool is a necessity in order to automate the management of Information Services. In this paper, we present a Grid Information System to address the above gaps. Our Information Service can collate information from multiple administrative domains and present users with a global view of information from the perspective of a Grid VO. The paper discusses our Information Service in terms of its architecture, interface, implementation, and performance evaluation. In Section 2, the architecture model of this Information Service is described for each layer. Section 3 discusses the query interface to access the Information Service. Section 4 discusses some issues pertaining to the implementation of the

Information Service. To evaluate the performance of our Information Service, we conducted experiments and the experimental results are given in Section 5. Finally Section 6 concludes the paper and outlines the direction of future work.

2. Architecture model Our Information Service is a VO-oriented service with a hierarchical structure which comprises of three layers, i.e. resource layer, site layer, and VO layer (as illustrated in Figure 1). This hierarchical framework matches the structure of a Grid Virtual Organization in a natural way, allowing more efficient management of information at different levels of the Grid infrastructure. In the following subsections, we will discuss each layer of the Information Service in turn. End users

VO VOQuery Query Hub Hubs

Site Information Service

Grid VO

Site Information Service

… Info Agents & Info Sensors

…

Info Agents & Info Sensors

… Resources

Site X

Resources

Site Y

Figure 1. Overall architecture of the Grid Information Service

2.1 Resource layer The resource layer is the underlying layer of the Information Service. Physically it consists of all the resources being monitored in a Grid VO environment. Figure 2 depicts the detailed framework of the resource layer. The major components of the resource layer are the Information Sensor and Information Agent. Each

Proceedings of the Sixth IEEE International Symposium on Cluster Computing and the Grid (CCGRID'06) 0-7695-2585-7/06 $20.00 © 2006 IEEE

resource hosts an Information Agent and can have one or multiple Information Sensors as information sources.  Information Sensors Information Sensors are our basic mechanism for capturing information at the resource layer. Generally they can be implemented in any programming language. The framework is designed such that sensors are easily pluggable and can be integrated dynamically into the Information Service architecture: as illustrated in Figure 2, standard sensors are stored in a global sensor repository and could be downloaded and deployed by system/Grid administrators; meanwhile, users can also implement their own sensors which fulfill specific requirements and then deploy those sensors on Grid resources. Some examples of sensors we developed are given in Section 4. Site Layer

Information Hash Table

Create / Monitor / Retrieve

Create

Push

Information Agent

Sensor Hash Table

Load

Create

Invoke

Information Sensors

Publish

Sensor Config File

Host Download & Deploy

Global Sensors Repository

Develop & Deploy

Specific Sensors

Figure 2. Information gathering and processing at the resource layer This Information Sensor methodology brings us flexibility for information generation and capturing, and allows us to interact with any kind of Grid resources and to capture any type of data pertaining to all aspects of a Grid operation (resources, applications, jobs, services, etc). This sensor approach also allows information about resources without a Globus installation to be captured appropriately. The information captured by the sensors is classified into two categories, i.e. static information and dynamic information. The static information is unchanged information (e.g. some hardware and software configurations such as number of processors, memory

and disk size, OS, etc), while dynamic information is the real-time information that may change from time to time (e.g. processor load, job status, etc). Sensor developers usually can specify an expiry time for dynamic information.  Information Agent Each resource has an Information Agent serving as a daemon. At startup, the Information Agent will lookup the sensor configuration file (which defines the functions and behaviors of all sensors deployed on that resource), and accordingly create a sensor hash table in memory. Then the agent invokes all sensors in the sensor hash table. The execution of those sensors generate information which is subsequently piped into an information hash table (a data structure for storing the information in the form of pairs) which is maintained by the agent. The information is then shared out to the site layer through a push mechanism. Figure 2 describes the procedure of information capturing and processing at the resource layer. Each agent monitors its information hash table. If the values of some information, in particular, dynamic information, are detected as expired, the agent will invoke the corresponding sensors and capture up-todate values. The new values retrieved may be further pushed to the site layer to makes an update on the data cache. This ensures the accuracy of information provided by the Information Service. The caching mechanism on the site layer will be discussed in the following section. In addition, each agent also has an administration port opened to the sensor users/developers. Through this administration port, sensor users/developers can notify the agent of newly added or removed sensors at runtime. Accordingly the agent will update the tables maintained. In such a way, the Information Agent and Information Sensor approach supports the hot plug-in of new Information Sensors and removal of unwanted sensors.

2.2 Site layer Typically there is a site-wide Information Service which is called the Site Information Service (SIS) running on an administrative domain site which participates in a Grid VO. By talking to the underlying Information Agents, an SIS aggregates information data from the resources being monitored in a domain. The SIS is a WSRF-compliant [6] Web service that consists of a set of functional components including the Information Agent Registry & Registry Handler, Data Collection Daemon, Query Processor and Data Caching. Figure 3 illustrates the structure of the SIS. In

Proceedings of the Sixth IEEE International Symposium on Cluster Computing and the Grid (CCGRID'06) 0-7695-2585-7/06 $20.00 © 2006 IEEE

the following subsections, we will discuss these components in turns.  Information Agent Registry Each SIS maintains an Information Agent Registry which keeps track of all the underlying Information Agents (on the resources monitored) registered to it as well as the information needed to access these agents. The registry also contains information on the type of information data (or information class) available on each Information Agent registered to the SIS. Query / Return Results

Query Processor

Query / Return Caching Data

Data Caching Query / Return Info Agent Configuration

Registry Handler

Forward Query / Return Result

Pass on Info Agent Configuration

Update Cache

Data Collection Daemon

Construct / Query / Return

Information Agent Registry

Pull / Push Data from Info Agents SQL Database

Figure 3. The structure of the Site Information Service Usually the above data maintained by the Information Agent Registry is quite large. Consequently it is infeasible to store all data in memory. Our solution is to use an SQL database to maintain the registry. The registry database contains three tables: the first table contains the information needed to communicate with the respective Information Agents; the second table contains the type of information (or information class) available on each Information Agent, as well as the hierarchy of information classes and attributes; lastly, the third table associates each Information Agent with the respective information classes that they contain. The Registry Handler is a component that handles the Information Agent Registry construction and query.  Data Collection Daemon

The Data Collection Daemon provides the interface for the SIS to communicate with the underlying Information Agents. It provides two main functions, i.e. pulling of data by sending the query to appropriate Information Agents and listening for data updating from the Information Agents through notification (pushing). When the Data Collection Daemon is started, it first queries all the underlying Information Agents registered to get all the information classes (generated by Information Sensors) from the resources monitored. On receiving data from Information Agents, the daemon would pass them to the Registry Handler which will do the necessary construction / update on the Information Agent Registry database. Once the above initialization work is done, the daemon would then subscribe to all the Information Agents registered and listen for notifications from them. Whenever some information data on an Information Agent expires, that agent will send a notification to the daemon and the daemon would possibly update the cache subject to the caching policy. In another scenario, when some new sensors are plugged in and generate new information data, the Information Agent would also generate notifications to the Data Collection Daemon. This information would then be passed to the Registry Handler to check whether the information class exists on the registry database and whether it is associated with the sending Information Agent. The Registry Handler would then create a new entry on the registry database or update as necessary. The Data Collection Daemon maintains a job queue which allows the Query Processor to add query jobs to be served by the daemon. The daemon keeps a minimum number of threads to handle jobs from the queue and creates more threads up to a maximum specified by the administrator when there is a surge on the number of jobs in the queue.  Query Processor and Data Caching The Query Processor handles all queries forwarded to the SIS from the upper VO layer. Figure 4 shows how a query is processed when it is received by the Query Processor. The Query Processor works with other components of the SIS, obtains information and finally returns the information to the upper layer. The SIS maintains a data cache in order to reduce query response time and improve the throughput of queries. Currently we introduce the Least Recently Used (LRU) page replacement algorithm [7] as the caching management strategy. Under this strategy, information that has been heavily used in the last few queries will be paged into the data caching based on

Proceedings of the Sixth IEEE International Symposium on Cluster Computing and the Grid (CCGRID'06) 0-7695-2585-7/06 $20.00 © 2006 IEEE

the prediction that this information will probably be heavily used again in the next few queries. Conversely, information that has not been used for a certain time will probably remain unused for some time and this information will be evicted from the data cache. Query Processor checks whether data queried is in the cache; If (data queried is cached) Query Processor retrieves data from cache and returns; Else { Query Processor talks to Registry Handler checking whether queried information class exists in the Information Agent Registry; If (information class exists in the registry) { The Registry Handler tells the Query Processor the Information Agent(s) on which the information class is available; Then the Query Processor forwards the query to the Data Collection Daemon; The Data Collection Daemon will query the corresponding Information Agent(s) to retrieve information and returns; } Else Return no data or error message; }

Figure 4: Query processing flow at the site layer

2.3 VO layer Above we have discussed information management within an administrative domain site. In this section, we will discuss the federation of Site Information Services to present a global view of information in a Grid VO. Some existing works like the Globus MDS build VO-wide information services with typical hierarchical structures to manage information in a centralized manner. But this approach limits scalability – it may cause a bottleneck at the VO layer and make the Information Service ineffective with increasing numbers of users and a growing amount of information aggregated. Besides, a single point of failure can easily result at the VO layer. In order to address the above issues, we introduce a DHT (Distributed Hash Table) [8, 9] based peer-topeer approach to create a virtual network of Site Information Services for information discovery and query in a large scale Grid VO. Generally, DHTs provide a solution to the lookup problem in distributed systems - it associates hash values (keys) with some kind of content, and can efficiently locate the node that stores the desired data in a large scale system. Our DHT based peer-to-peer approach enables

decentralized information management for a large scale Grid and brings two features:  Scalability: the Information Service can remain efficient in handling users’ queries with an increasing number of Site Information Services federated and increasing query load.  Reliability: the peer-to-peer approach intrinsically presents system robustness and avoids a single point of failure. This approach also allows Site Information Services to join and leave the VO layer Information Service freely without affecting its robustness or efficiency.

VO Admin

VO membership management SIS Config.

End-users Send query

VO Query Hub/s

Locate SIS/s

DHT registry handler

DHT registration

Retrieve information class

SIS/s

DHT

Forward query to selected SIS/s

…

Figure 5. VO Information Service based on DHT The basic architecture of the VO layer Information Service based on the DHT approach is shown in Figure 5. Central to the architecture are two main components: the DHT Registry Handler and the VO Query Hub (there can be one or multiple instances of these components based on the consideration of VO scale and fault tolerance).  DHT Registry Handler A VO administrator maintains the membership of Site Information Services joining or leaving a Grid VO. At the initialization phase, a DHT Registry Handler will conduct the following steps to complete the registration of Site Information Services into the DHT: – The DHT Registry Handler connects to each Site Information Service listed in a VO membership configuration file, and gets a set of

Proceedings of the Sixth IEEE International Symposium on Cluster Computing and the Grid (CCGRID'06) 0-7695-2585-7/06 $20.00 © 2006 IEEE

all information classes each Site Information Service contains. – The DHT Registry Handler performs ‘put’ operations on the DHT, thus storing the information classes as key and the corresponding Site Information Service as value into the DHT for each Site Information Service. – The DHT Registry Handler has now created an index between information classes and their respective Site Information Services. The initialization work for the VO Information Service is complete, and the Information Service can now serve end users’ queries. The DHT Registry Handler also manages the runtime updating of the DHT whenever new Site Information Services join or leave the Grid VO.  VO Query Hub A VO Query Hub is the entry point for end-users’ queries. When a user issues a query, the query will be handled through the following steps: – After receiving a query, the VO Query Hub will validate the query to ensure that the query complies with the defined query interfaces. The query interfaces will be discussed in the next section. – The VO Query Hub will perform ‘get’ operations on the DHT to locate the SIS/s that contain the queried information classes as well as meet the logical relationships of the information classes specified in the query. – The VO Query Hub will then forward the original query only to those selected Site Information Services. – The Site Information Services will process the query, and return results to the VO query Hub. The VO Query Hub merges the results and finally sends back to end user.

3. Query interface The query interface defines the way in which information is retrieved from the Information Service. Our Information Service provides a set of expressive and easy-to-use query interfaces, and hides the complexity of Grid environments. The query interface of our Information Service is divided into two parts, i.e. the resource selection and query type. The resource selection part allows end users to specify the resources of interest, and this part is further divided into three types listed in the table 1. The query type part allows end users to specify the information class queried, and this part is further divided into two main types listed in the table 1.

Table 1. Query interface Resource Selection

Query Type

Format Single resource address (list of resource address) (*) Single info class Combinatory info class

Usage Query addressed to the specific resource only Query addressed to each individual resource listed Query addressed to all resources in a Grid VO Query for the value of that information class Query for resources that satisfy the conditions given.

Below we give some examples to show how our Information Service can support both basic types of queries as well as combinatory queries. - Query one or more resources in a Grid VO for some specific information class. For example, if a query like “(155.69.11.21) cpu.load” is issued, the Information Service will reply with the value of the CPU load on the machine with the give IP address. - Query for all resources in a Grid VO that satisfy a given condition. For example, if a query like “(*) cpu.number > 2 && cpu.load < 1.0” is issued, the Information Service will return all the resources in the Grid VO that satisfy the given condition. Before a query is sent for processing, it must be validated to ensure that only those query strings that conform to the pre-defined query format will be processed. Here we use JavaCC [10] which is a parser generator for query validation checking. After query format validation, the query string will be translated to the query request message which is understandable by the VO Query Hub.

4. Implementation A prototype Information Service that implements the architecture described above has been developed. In this section, we will discuss some issues pertaining to the implementation of the major components of this Information Service.

4.1 Implementation of Information Sensors and Information Agent A set of basic Information Sensors has been developed using the Perl language [11]. Currently these sensors can provide information about hardware (e.g. host, processor, memory, disk, networking, etc) and software (OS, file system, application, etc). We are now writing more sensors to capture information pertaining to job execution (job status, resource consumption, etc) in a Grid environment. The output of

Proceedings of the Sixth IEEE International Symposium on Cluster Computing and the Grid (CCGRID'06) 0-7695-2585-7/06 $20.00 © 2006 IEEE

these sensors is in XML format for easy and uniform processing by the Information Agents. The Information Agents are implemented using Java classes. Each agent keeps a pool of threads running. Whenever the agent detects any information expired, a thread will invoke the corresponding sensor to capture the up-to-date value, and push to the upper SIS for updating.

4.2 Implementation of site layer and VO layer components The SIS is a WSRF-compliant Web service implemented on top of the Globus Toolkit 4.0 [12]. As a stateful Web service, the SIS is coupled with a set of resources (see Figure 6). This pairing of the SIS Web service with a set of resources is called WS-Resources in the WSRF specifications. These resources act as Data Caching as discussed in Section 2.2. In our current design, each resource is structured to keep a certain information class (e.g. CPU, memory, software, etc), while each resource may consist of multiple resource properties (e.g. the CPU resource may have resource properties like CPU number, CPU speed, CPU load, etc). These resources can be created and destroyed at runtime as per the caching strategy discussed in Section 2.2. More concretely, whenever some information needs to be paged in, the corresponding resource will be created; conversely, whenever some information needs to be paged out, the corresponding resource will be destroyed.

Table system in the implementation of the VO layer framework. Other components like the Query Processor, Data Collection Daemon, Registry Handler and SIS handler are implemented as Java Classes.

5. Performance Study We conducted preliminary experiments to evaluate the performance of our Information Service. The main objective of these experiments is to study the scalability of the Information Service in handling large scale Grids with growing number of participating sites. Due to resource constrains we conducted experiments on a local Grid testbed to simulate a Grid VO environment. The testbed consists of ten machines each with two 2.6GHz Intel Xeon processors, 1GB memory and Globus Toolkit 4.0. These machines are connected through Giga-bit Ethernet. In our experiments, each machine may host up to five Site Information Services. It implies that the number of Site Information Services federated in our experiments varies from ten to fifty. Each Site Information Service monitors all the ten machines and collects information from them. In addition, the query response time is introduced as the key metric in our study. Here the query response time is defied as the average time span starting from a client sending a query to the Information Service till receiving response. In our experiments, we compare our peer-to-peer based approach with a multicasting approach. In the multicasting approach, the VO Query Hub sends queries to every site without selection. 16

Memory

SIS Web Service

Total Size Available Size …

… … Name Executable Path …

Software

14 Query Response Time (s)

CPU

Number Speed Load …

12 10

P2P Multicasting

8 6 4 2 0 10

Resources

Figure 6. SIS Web service and resource structure The Information Agent Registry is implemented using MySQL database [13]. We use Bamboo DHT [14] which is a robust, open-source Distributed Hash

20

30

40

50

Number of Sites Federated

Figure 7. Query response time with number of sites federated Figure 7 illustrates the response time of the Information Service with the number of sites federated in a Grid VO. We observed that our peer-to-peer based Information Service presents pretty satisfactory

Proceedings of the Sixth IEEE International Symposium on Cluster Computing and the Grid (CCGRID'06) 0-7695-2585-7/06 $20.00 © 2006 IEEE

scalability when more and more sites join the Grid VO. In other words, the Information Service works equally well for both small and large scale Grid deployment. We also note that the p2p based approach presents better performance than the multicasting approach. This is mainly because the peer-to-peer based approach adopted in our Information Service ensures scalability and efficiency in information lookup in a Grid VO information network that connects multiple Site Information Services.

7. Acknowledgement

6. Conclusions and Future Work

8. References

A Grid Information Service is the Grid equivalent of the directory service that maintains information about hardware, software, services and people that participate in a Grid VO, and makes that information available upon request. Our vision of the Grid Information Service is a hierarchal architecture with distributed control. The hierarchical architecture well suits the nature of Grid VO structure and efficiently manages information in a layered manner. The p2p based approach provides scalability and fault tolerance in managing a large amount of Grid VO information that comes from multiple administrative domains. The introduction of the information agent and sensor also allow the publication of user or application supplied information both static and dynamic. Our initial experiment results indicate that the architecture model of Information Service is capable of handling information in large scale Grid environments. For future works, we will conduct experiments for a quantifiable and qualitative performance evaluation of the Information Service. It will help further optimization and enhancement of our Information Service. We will also compare our Information Service with other systems like Globus MDS and Ganglia [15]. Currently we are also designing a security service for our Information Service. This security service aims to provide security policies for authentication and authorization control of the Information Service. For example, access to the Information Service must be authenticated; information providers are allowed to protect their information from unauthorized access, and so on. In addition, we are also building a deployment tool to ease the deployment of the Information Service and its components in a Grid VO environment. The functional requirements for this deployment tool are to perform the installation, configuration, activation and re-configuration of the Information Service and its components.

[1] I. Foster, C. Kesselman, et al, “The Anatomy of the Grid: Enabling Scalable Virtual Organizations”, International Journal of High Performance Computing Applications, Vol. 15, pp. 200-222, 2001. [2] S. Fitzgerald, I. Foster, et al, “A Directory Service for Configuring High-performance Distributed Computations”, Proceedings of 6th IEEE Symposium on High Performance Distributed Computing, IEEE Computer Society Press, pp. 365-375, 1997. [3] K. Czajkowski, S. Fitzgerald, I. Foster, and C. Kesselman, “Grid Information Service for Distributed Resource Sharing”, Proceedings 10th IEEE International Symposium on High Performance Distributed Computing, pp. 181 – 194, 2001. [4] Globus MDS, http://www.globus.org/toolkit/mds/. [5] Globus Toolkit, http://www.globus.org. [6] The WS-Resource Framework (WSRF). http://www.globus.org/wsrf/. [7] Andrew S. Tanenbaum, Modern Operating Systems, 2nd edition, Prentice Hall, 2001. [8] I. Stoica, R. Morris, D. Karger, F. Kaashaek, and H. Balakrishnan, ''Chord A scalable Peer-To-Peer lookup service far internet applications," Proceedings of the ACM SIGCOMM Conference, pp. 149-160, 2001. [9] A. Rowstron and P. Druschel, "Pastry: Scalable, distributed object location and routing for large-scale peerto-peer systems," Proceedings of the 18th IFIP/ACM International Conference on Distributed Systems Platforms (Middleware 2001), 2001. [10] JAVACC, https://javacc.dev.java.net/. [11] Larry Wall, Tom Christiansen, and Jon Orwant. Programming Perl, 3rd edition, July 2000, O'Reilly. [12] Globus Toolkit 4, http://www.globus.org/toolkit/docs/4.0/. [13] MySQL database, http://www.mysql.com/. [14] S. Rhea, B. Godfrey, et al, “OpenDHT: A Public

The authors would like to give special thanks to Benjamin Khoo, former member of the Institute of High Performance Computing, for his constructive input in the architecture design. We would like to thank Truong Minh Nguyen, Wang Mingjie, Tan Choon Pang and Irene Goh, Nanyang Technological University, for their valuable contributions on the system implementation and experiments.

DHT Service and Its Uses”, Proceedings of ACM SIGCOMM 2005, 2005. [15] M. Massie, B. Chun, and D. Culler. The ganglia distributed monitoring system: design, implementation, and experience. Parallel Computing, Vol. 30, No. 7, 2004.

Proceedings of the Sixth IEEE International Symposium on Cluster Computing and the Grid (CCGRID'06) 0-7695-2585-7/06 $20.00 © 2006 IEEE