- Global Grid Example One
- Overview of a Global Compute Grid
- Brief Description or the Globus Toolkit 2.0
- Distributed Resource Managers
- Portal Software and Authentication
- Global Grid Example One
- Global Grid Example Two
- About the Authors
- About the Authors
- Ordering Sun Documents
- Accessing Sun Documentation Online
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Distributed Resource Managers
As described in the previous BluePrints article, the core of any enterprise or cluster grid is the distributed resource manager (DRM). Examples of DRMs are Sun™ ONE Grid Engine, Platform Computing's Load Sharing Facility, or Veridian's PBS Pro. In a global compute grid, it is often beneficial to take advantage of the features provided by the DRMs at the global grid level. Such features may include the ability to do the following:
Create user sets whose access rights to the cluster grid might be controlled. This will strongly complement the limited authorization available through GT2.
Provide resource guarantees to grid users
Reserve portions of the local resource for local users
Perform advanced reservation of compute resources
One of the key advantages to using DRM software is that it can simplify the implementation of the Globus layer above it. Specifically, where the underlying compute resources are heterogeneous in terms of operating platform, processor architecture, and memory, the DRM provides a virtualization of these resources, usually by means of the queue concept.
Different DRMs have different definitions of a queue, but essentially a queue and its associated attributes, represents the underlying compute resource to which jobs are submitted. If a VO chooses to implement a specific DRM at each of its cluster grids, then the concept of implementing a virtualization of all the cluster grids is relatively straightforward, despite the possibility that the underlying hardware might be quite heterogeneous. One simply aggregates all the queue information across the VO. Since the attributes of the queues will have a common definition across the VO, the interface to this grid could be designed to be analogous to that implemented at the campus level.
Integration of the DRM with GT2 can mean a number of things. Primarily it means that:
There is an integration of the DRM with GRAM. This means that jobs submitted to Globus (using the Globus Resource Specification Language [RSL]) can be passed on to the DRMs. Evidently the key here is to provide a means of translation between RSL and the language understood by the DRM. These are implemented in Globus using GRAM job manager scripts.
There is an integration with MDS. The use of a GRAM reporter allows information about a DRM to be gathered and published in the MDS. The reporter will run at each campus site periodically via cron and query the local DRM. This means that up-to-date queue information can be gathered across many cluster grids.