GINGER: A Flexible Peer-to-Peer Grid Infrastructure

Grid computing allows organizations to share computing resources, and has been successfully deployed in large computer clusters, enabling corporate or scientific communities to run large-scale computations that would not be feasible in a centralized setting. However, the Grid revolution has not yet reached the common Internet user, partly due to the requirement of having a well-managed infrastructure where to deploy the Grid. In this proposal we present GINGER, a peer-to-peer Grid infrastructure that overcomes the existing barriers for widespread utilization of the Grid, by allowing users to cooperatively form a Grid infrastructure using each other's spare resources. GINGER's design was guided by several goals that are not met by current Grid infrastructures, such as ease of deployment and use, lack of centralized components, or the ability to run in an environment where nodes may not be willing to cooperate, and where failure is the norm, and not the exception. In this proposal we present some of the main problems that need to be addressed by GINGER, and how we intend to solve them. The first problem is node organization and discovery. GINGER nodes form a peer-to-peer overlay (using an enhanced version of Pastry). The resource discovery protocols follow overlay links, and inherit several of the good properties of the overlay, like automatically adjusting to membership changes. The second problem is partitioning and distributing the application workload. We introduce the concept of a Gridlet that represents both the code that is run remotely, and its input data. Gridlets can carry code in different formats, and one possibility that will enable easy adoption is for Gridlets to contain unmodified application binaries, in which case the client can make use of a special tool that partitions the input, creates and deploys the Gridlets, and aggregates the results. Finally we address the problem of tolerating faults (either due to node departures or malicious attacks). Benign faults are dealt by retrying, since Gridlets are stateless, and we store no data in the system. To address malicious faults, we occasionally audit node behavior using replication to detect incoherent replies, and we disseminate certified accusations to remove malicious nodes from the system. We also incorporate reputation measurements into the proximity metric used by the peer-to-peer overlay to bias the choice of peers during node discovery.

Sponsoring bodies: FCT

Coordinator: Luís Veiga

Partners: INESC-ID

Homepage: N/A