|
Moab Workload Manager® |
11.8 Using a Local Queue
Moab allows jobs to be submitted directly to the scheduler. With a local queue, Moab is able to directly manage the job or translate it for resubmission to a standard resource manager queue. There are multiple advantages to using a local queue:
- Jobs may be translated from one resource manager job submission language to another (such as submitting a PBS job and running it on an LSF cluster).
- Jobs may be migrated from one local resource manager to another.
- Jobs may be migrated to remote systems using Moab peer-to-peer functionality.
- Jobs may be dynamically modified and optimized by Moab to improve response time and system utilization.
- Jobs may be dynamically modified to account for system hardware failures or other issues.
- Jobs may be dynamically modified to conform to site policies and constraints.
- Grid jobs are supported.
11.8.1 Local Queue Configuration
A local queue is configured just like a standard resource manager queue. It may have defaults, limits, resource mapping, and credential access constraints. The following table describes the most common settings:
ATTRIBUTE | Default queue |
| FORMAT | RMCFG[internal] DEFAULTCLASS=<CLASSID>
|
| DESCRIPTION |
The job class/queue assigned to the job if one is not explicitly requested by the submittor. NOTE: All jobs submitted directly to Moab are initially received by the pseudo-resource manager internal. Therefore, default queue configuration may only be applied to it. |
| EXAMPLE | RMCFG[internal] DEFAULTCLASS=batch |
ATTRIBUTE | Class default resource requirements |
| FORMAT |
CLASSCFG[<CLASSID>] DEFAULT.FEATURES=<X>
|
| DESCRIPTION | The settings assigned to the job if not explicitly set by the submittor. Default values are available for node features, per task memory, node count, nodeset configuration, processor count, and wallclock limit. |
| EXAMPLE |
CLASSCFG[batch] DEFAULT.WCLIMIT=4 DEFAULT.FEATURES=matlab
or
|
ATTRIBUTE | Class maximum resource limits |
| FORMAT |
CLASSCFG[<CLASSID>] MAX.FEATURES=<X>
|
| DESCRIPTION |
The maximum node features, node count, processor count, and wallclock limit allowed for a job submitted to the class/queue. If these limits are not satisfied, the job is not accepted and the submit request fails.
MAX.FEATURES indicates that only the listed features may be requested by a job.
|
| EXAMPLE |
CLASSCFG[smalljob] MAX.PROC=4 MAX.FEATURES=slow,matlab
or
|
ATTRIBUTE | Class minimum resource limits |
| FORMAT |
CLASSCFG[<CLASSID>] MIN.FEATURES=<X>
|
| DESCRIPTION |
The minimum node features, node count, processor count, and wallclock limit allowed for a job submitted to the class/queue. If these limits are not satisfied, the job is not accepted and the submit request fails.
MIN.FEATURES indicates that only the listed features may be requested by a job.
|
| EXAMPLE |
CLASSCFG[bigjob] MIN.PROC=4 MIN.WCLIMIT=1:00:00
or
|
ATTRIBUTE | Class access |
| FORMAT | CLASSCFG[<CLASSID>] REQUIREDUSERLIST=<USERID>[,<USERID>]... |
| DESCRIPTION | The list of users who may submit jobs to the queue. |
| EXAMPLE | CLASSCFG[math] REQUIREDUSERLIST=john,steve |
ATTRIBUTE | Available resources |
| FORMAT | CLASSCFG[<CLASSID>] HOSTLIST=<HOSTID>[,<HOSTID>]... |
| DESCRIPTION | The list of nodes that jobs in the queue may use. |
| EXAMPLE | CLASSCFG[special] HOSTLIST=node001,node003,node13 |
Class mapping between multiple sites is described in the section on Moab grid facilities.
If a job is submitted directly to the resource manager used by the local queue, the class default resource requirements are not applied. Also, if the job violates a local queue limitation, the job is accepted by the resource manager, but placed in the Blocked state.