11.7 General Job Policies
- 11.7.1 Multi-Node Support
- 11.7.2 Multi-Req Support
- 11.7.3 Job Size Policy
- 11.7.4 Malleable Job Support
- 11.7.5 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 only allowed to specify a single type of resource for allocation. For example, a job could request 4 nodes with 256 MB of memory or 8 nodes with feature fast present. However, the default behavior does not allow submission of a single job that requests both of these resource types. The parameter ENABLEMULTIREQJOBS can be set to TRUE to remove this constraint.
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 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. |
|
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 dynamic modified, or rejected in a custom manner depending on the site or the nature of the failure.
See Also