Abstract
The following provides available information about migrating from previous versions of the Globus Toolkit.
Table of Contents
Table of Contents
The GRAM5 protocol has been designed to be backward compatible with GRAM2 protocol from GT 4.2.x. There is no compatibility between GRAM5 and the GRAM4 protocol.
GRAM5 supports generating audit records the same as GRAM2. It also
adds support for a Teragrid-specific Gateway User field in the audit
records. The
globus_gram_job_manager_auditing package
contains the audit database interface code. The
globus_gram_job_manager_auditing_setup
setup package configures this package. GRAM5 auditing is enabled by
using the -audit-directory command-line option in the
job manager configuration file. For more information about GRAM5 audit
support, see the GRAM5 admin guide.
Table of Contents
The GRAM5 protocol has been designed to be backward compatible with GRAM2 protocol from GT 4.0.x. There is no compatibility between GRAM5 and the GRAM4 protocol.
GRAM5 supports generating audit records the same as GRAM2. It also
adds support for a Teragrid-specific Gateway User field in the audit
records. The
globus_gram_job_manager_auditing package
contains the audit database interface code. The
globus_gram_job_manager_auditing_setup
setup package configures this package. GRAM5 auditing is enabled by
using the -audit-directory command-line option in the
job manager configuration file. For more information about GRAM5 audit
support, see the GRAM5 admin guide.
The GRAM5 protocol has been designed to be backward compatible with GRAM2 protocol from GT 3.0.x. There is no compatibility between GRAM5 and the Web Service GRAM protocol GT3.
Table of Contents
In GRAM2, jobs are submitted to a job manager process started by a Gatekeeper process. In GRAM5, the job submit protocol is the same; however, all jobs for a particular user and LRM run in the same job manager process.
In GRAM2, the GRAM client is required to delegate a proxy credential to the Gatekeeper so that the job manager can send authenticated job state change messages. Because each job is monitored by a separate job manager in GRAM2, each job manager has access to a different delegated credential. In GRAM5, the shared job manager uses the delegated credential with the latest expiration time as its credential.
In GRAM2, the client can control the job manager proxy timeout by setting
the value of proxy_timeout RSL attribute to a time interval
in seconds indicating when the job manager will exit if the proxy is about
to expire. In GRAM5, this is a job manager-wide setting and the
proxy_timeout RSL attribute is ignored.
In GRAM2, the standard output and standard error streams of a job may be sent in near real time to a file server such as the GASS server embedded in a globusrun execution. In GRAM5 the same RSL syntax is used to name output and error stream destinations, but those are not sent until after the job execution is complete.
In GRAM2, the job manager implements intra-job communication via DUCT and task synchronization via DUROC. These features have been dropped in GRAM5.
GRAM5 adds various protocol extensions to the GRAM2 protocol. This is done in a way such that the existing GRAM2 protocol processors will ignore the extensions to the messages. Details about the protocol and its extensions can be found in the GRAM5 public interface document.
In GRAM2, all file system and LRM interactions occur within a perl module called by the globus-job-manager-script.pl program. Scheduler-specific perl modules implement a number of methods which are used by the job manager:
- submit
- poll
- cancel
- signal
- make_scratchdir
- remove_scratchdir
- stage_in
- stage_out
- cache_cleanup
- remote_io_file_create
- proxy_relocate
- proxy_update
Only a small set of these script methods are used in the GRAM5 implementation. The subset used is:
- submit
- signal (called when not using SEG)
- poll (called when not using SEG)
- cancel
Some of the functionality has been moved into the job manager or other services for performance reasons.
In GRAM2, each job submitted would cause the following processes to be created:
- gatekeeper (short lived)
- job manager (lives the duration of the job)
- perl script (short lived 4 or more instances depending on job type)
- perl script poll called periodically
In GRAM5, each job causes the following processes to be created
- globus-gatekeeper (short lived)
- globus-job-manager (short lived for all but one concurrent instance)
- globus-job-manager-script (up to 5 per lifetime of the job manager)
- globus-fork-starter (up to 5 per job manager when using the fork LRM and the SEG).
Additionally, there will be a per-scheduler instance of the SEG-related program, globus-job-manager-event-generator.
S
- Scheduler Event Generator (SEG)
The Scheduler Event Generator (SEG) is a program which uses scheduler-specific monitoring modules to generate job state change events. Depending on scheduler-specific requirements, the SEG may need to run with privileges to enable it to obtain scheduler event notifications. As such, one SEG runs per scheduler resource. For example, on a host which provides access to both PBS and fork jobs, two SEGs, running at (potentially) different privilege levels will be running. One SEG instance exists for any particular scheduled resource instance (one for all homogeneous PBS queues, one for all fork jobs, etc). The SEG is implemented in an executable called the globus-scheduler-event-generator, located in the Globus Toolkit's libexec directory.