«

»

GridAtlas

e.g., Globus Toolkit, GridWay) enables simultaneous access and invocation of application instances across grid resources, complexities involved with the installation properties on selected resources should not be left for the end-user to deal with and manage. GridAtlas is a tool that hides and automates this process by keeping track of resource and application instance details. Upon a user job submission, a job submission interface contacts GridAtlas and obtains necessary information to complement user provided information after which further steps of job submission process can take place.

Architecture

The architecture for GridAtlas consists of two main entities: the information providing GridAtlas Deamons (GAD) and information aggregating GridAtlas instances. GADs are low-level information providers that provide access to detailed, dynamic information about grid resources. Examples of such information would include list of applications installed on a given resource with associated paths and linked input data. Aggregating GridAtlas instances provide VO-specific aggregation of low-level GADs. Services (e.g., job submission engine, scheduler) or users can access these instances to obtain information relevant to the particular user under the cap of a single VO. Aggregated GridAtlas instances provide an excellent solution to the scalability of this infrastructure. Each aggregate directory provides an entry point for an individual VO thus limiting the amount of data required to be handled by any on GridAtlas instance. By defining the scope through VO participation, GridAtlas instances can limit the amount and type of information that it provides for its users. This is an important issue when tradeoffs between the speed and scope of access are compared to the cost of maintaining this data. Presented model supports both push and pull methods for data collection and thus leaves enough flexibility to configure GridAtlas bases on VOs preferences. Click here for architecture diagram.

Interfaces

The primary protocol for interaction with GridAtlas is a well-defined web-service API interface. Any of the components interacting with GridAtlas must conform to the defined protocol. As such, any communication between the aggregate GridAtlas instances and GADs is handled through this protocol. The protocol thus provides direct link to all of the functionality provided by GridAtlas. In addition to the web-service API, a web-based portal allowing for easy browsing is also built on top of this protocol.

Data access methods

The following is the list functionality offered by GridAtlas through its well-defined web-service API protocol:

  • Get application path provided application name and resource FQDN
  • Get number of PE per each PS on a resource given resource FQDN
  • Get list of applications installed on a resource, provided resource FQDN
  • Get list of resources an application is installed on, provided application name
  • Get application description, provided application name (note that multiple application versions and thus description may exist under the same name, so this needs to be addressed)
  • Get application version, provided application name (note that multiple application versions and thus description may exist under the same name, so this needs to be addressed)
  • Get path of application input entity provided application name, resource FQDN and name of application input entity
  • Get description of application input entity provided application name, resource FQDN and name of application input entity
  • Get list of all application input entities provided application name and resource FQDN

Software

As described above, GridAtlas Daemon (GAD) runs as a service on a host that in turn provides necessary resource- and application-specific information. This information is accessed from a known location through the GridAtlas Aggregator (GAA), which aggregates information from multiple resource providers (i.e., GADs). From the implementation standpoint, the difference between the GAD and GAA services in only conceptual and it is realized through a configuration file provided with GridAtlas deployment. As such, only one instance of the application needs to be maintained, downloaded and deployed. In order to download GridAtlas, click here. The deployment instructions are provided on the GridAtlas Trac page. The package provided for download represents a standalone package that incorporates all the other tools required to successfully deploy GridAtlas service (e.g., Apache Tomcat, Ant). However, note that because of such packaging, the package download size is approx 125MB. If you are interested in simply taking a look at GridAtlas in action, a live GridAtlas service instance is available here.

Projects using GridAtlas

People

Additional links and documents

  • GridAtlas Trac project website with implementation and installation details