• Multi-Node Support
• Multi-Req Support
• Job Size Policy
• Malleable Job Support
• Enabling Job User Proxy

There are a number of configurable policies that help control advanced job functions. These policies help determine allowable job sizes and structures.

11.7.1 Multi-Node Support

You can configure the ability to allocate resources from mutiple nodes to a job with the MAX.NODE limit.

11.7.2 Multi-Req Support

By default, jobs are allowed to specify multiple types of resources for allocation. For example, a job could request 4 nodes with 256 MB of memory and 8 nodes with feature fast present. The parameter DISABLEMULTIREQJOBS can be set to TRUE to limit jobs to a single resource type.

Resources specified in a multi-req job are delimited with a plus sign (+).

Example 1:

-l nodes=4:ppn=1+10:ppn=5+2:ppn=2

Example 1 requests 4 nodes with 1 proc each, 10 nodes with 5 procs each, and 2 nodes with 2 procs each. The total number of processors requested is (4*1) + (10*5) + (2*2), or 58 processors.

Example 2:

-l nodes=15+1:ppn=4

The job submitted in Example 2 requests a total of 16 nodes. 15 of these nodes have no specific requirements, but the remaining node must have 4 processors.

Example 3:

-l nodes=3:fast+1:io

The job requests a total of 4 nodes: 3 nodes with the fast feature, and 1 node with the io feature.

11.7.3 Job Size Policy

Moab allows jobs to request resource ranges. Using this range information, the scheduler is able to maximize the amount of resources available to the job while minimizing the amount of time the job is blocked waiting for resources. The JOBSIZEPOLICY parameter can be used to set this behavior according to local site needs.

Job resource ranges may only be specified when using a local queue as described in the Using a Local Queue section.

11.7.4 Malleable Job Support

A job can specify whether it is able to use more processors or less processors and what effect, if any, that has on its wallclock time. For example, a job may run for 10 minutes on 1 processor, 5 minutes on 2 processors and 3 minutes on 3 processors. When a job is submitted with a task request list attached, Moab determines which task request fits best and molds the job based on its specifications. To submit a job with a task request list and allow Moab to mold it based on the current scheduler environment, use the TRL flag in the Resource Manager Extension.

11.7.5 Enabling Job User Proxy

By default, user proxying is disabled. To be enabled, it must be authorized using the PROXYLIST attribute of the USERCFG parameter. This parameter can be specified either as a comma-delimited list of users or as the keyword validate. If the keyword validate is specified, the RMCFG attribute JOBVALIDATEURLshould be set and used to confirm that the job's owner can proxy to the job's execution user. An example script performing this check for ssh-based systems is provided in the tools directory.(See Job Validate Tool Overview.)

For some resource managers (RM), proxying must also be enabled at the RM level. The following example shows how ssh-based proxying can be accomplished in a Moab+TORQUE with SSH environment.

To validate proxy users, Moab must be running as root.

USERCFG[DEFAULT] PROXYLIST=validate
RMCFG[base]  TYPE=<resource manager>  JOBVALIDATEURL=exec://$HOME/tools/job.validate.sshproxy.pl

> qmgr -c 's s allow_proxy_user=true'
> su - testuser
> qsub -I -u testuser2 
qsub: waiting for job 533.igt.org to start
qsub: job 533.igt.org ready
testuser2@igt:~$

This feature supports qsub only.

In the example above, the validate tool, 'job.validate.sshproxy.pl', can verify proxying is allowed by becoming the submit user and determining if the submit user can achieve passwordless access to the specified execution user.  However, site-specific tools can use any method to determine proxy access including a flat file look-up, database lookup, querying of an information service such as NIS or LDAP, or other local or remote tests.   For example, if proxy validation is required but end-user accounts are not available on the management node running Moab, the job validate service could perform the validation test on a representative remote host such as a login host.

The job validate tool is highly flexible allowing any combination of job attributes to be evaluated and tested using either local or remote validation tests.  The validate tool allows not only pass/fail responses but also allows the job to be modified, or rejected in a custom manner depending on the site or the nature of the failure.

See Also

• Usage Limits