4.3. Execution Platform Models

Overview

The GRIA architecture is flexible enough to use a variety of underlying computing platforms to run jobs e.g. from single computers to clusters of workstations or even supercomputers. The following sections of this document describe GRIA constraints on different platforms.

GRIA system administrators should read this document and configure GRIA accordingly to accommodate the infrastructure of their underlying computing platform.

• Applications should be accessible by compute nodes only. Installation of the applications can be either local per compute node or over disk space shared among all nodes.
• Platform scripts should be accessible by the GRIA Job Service middleware.
• Application scripts should be accessible by the GRIA Job Service middleware and compute nodes, e.g. either copy wrappers locally per node or use a shared directory.
• Scratch area, i.e. job workspace area, should be accessible (read/write) by both the GRIA Job Service middleware and compute nodes. The scratch area cannot be copied between compute nodes, instead it has to be exported as a shared disk space.

Directory names and paths for wrappers should be similar whether the access point is a compute node or the GRIA Job Service middleware. The following figure illustrates an overview of the GRIA Job Service in relation to its execution resources.

Figure 1. Diagram of the job service and its wrapper scripts

The Need for Platform Scripts

GRIA Services do not access resource mangers directly to submit and check jobs. Instead, GRIA Services introduce an extra layer of resource manager dependant platform scripts to submit and check jobs. For each resource manager GRIA requires a separate suite of platform scripts. This extra layer of platform dependant scripts decouples GRIA Services form resource managers and applications.

GRIA defines platform scripts APIs to handle jobs such as:

• Start job script to submit jobs
• Check job to check the status of a job
• Kill job to terminate a job

The Job Service then can be configured to use platform scripts suitable for the underlying computing platform. Platform scripts then, know how to handle (start, check, kill) jobs for that particular computing platform, and can be instructed to run a particular application via its application wrapper.

Figure 1 illustrates how the platform script layer sits between the Job Service and application wrappers hiding resource manager details.

Local Execution Scenario

This is a minimum configuration scenario, all GRIA Services and jobs run locally on the same machine.

The following figure shows how GRIA can be deployed with services running locally. In this example the Job Service middleware is using platform scripts that run jobs locally. Job workspace, wrappers and applications should be accessible by the system that runs GRIA services.

Note: this is the same configuration the GRIA release demo is using to run the tutorial applications locally.

Figure 2 - GRIA service running jobs locally.

Using a Cluster of Resources Scenario

The GRIA Services can be deployed and use, as a computational platform, a cluster of workstations. For example, in Figure 3 the Job Service middleware is using PBS platform scripts to handle jobs. Cluster compute nodes need to access applications, wrappers and the job workspace, on the other hand the GRIA Services should access job workspaces, and the wrappers.

Figure 3 - GRIA service running jobs via a cluster of resources

Next: Application Wrapper Scripts and Description Files Previous: Managing Applications