10.7 General Job Policies
There are a number of configurable policies that help control advanced job functions. These policies help determine allowable job sizes and structures.
10.7-A Multi-Node Support
You can configure the ability to allocate resources from multiple nodes to a job with the MAX.NODE limit.
10.7-B Multi-Req Support
Jobs can 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.
Resources specified in a multi-req job are delimited with a plus sign (+).
Neither SPANEVENLY nor DELAY values of the NODESETPLUS parameter will work with multi-req jobs or preemption.
Example 10-1:
-l nodes=4:ppn=1+10:ppn=5+2:ppn=2
This example 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 10-2:
-l nodes=15+1:ppn=4
The job submitted in this example requests a total of 16 nodes. 15 of these nodes have no specific requirements, but the remaining node must have 4 processors.
Example 10-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.
10.7-C 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.
10.7-D 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.
10.7-E 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 JOBVALIDATEURL should 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.
Example 10-4: SSH Proxy Settings
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:~$
In this example, 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.
This feature supports qsub only.
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.
Related topics