There are several way to control which hosts the supervisor will select when deciding where to start job instances on the farm.
Hosts: Send only to an explicit set of workers
Host Groups: Send only to an explicit pre-defined group of workers
Host Order: Select hosts in a certain preferential order
Job and Worker Restrictions
Restrictions are used to allow or restrict where jobs run, and are applied to both jobs and workers. Restrictions are based on cluster names, but differ from the clusters themselves by an important difference:
This seems a bit hard to fathom, until you remember that a job has preferential priority on a worker whose cluster matches the job's cluster, but the job is free to run on any host in other clusters. The job's restriction value can be used to limit what other clusters the job could possibly run on.
Restrictions defined for jobs
When a job has a restriction defined, it means only run on hosts that satisfy the restriction expression. Hosts that don't satisfy the restriction expression won't be considered as dispatch candidates (the job will never be sent to that worker).
Restrictions defined for worker hosts
When a worker has a restriction defined via its worker_restrictions value, it means only run jobs whose cluster value matches one of the clusters in that worker's restriction expression. The worker won't accept jobs whose cluster doesn't match one of the clusters in the worker's restriction expression.
Restrictions Syntax
A restriction is really defined as a "filter" for hosts based upon information in the queuing algorithm; the values are one or more cluster names. In the priority/cluster queuing system, a user specifies their restrictions by directory structure format:
/[<segment>/][<segment>/][+|*]
- * means only the first level below.
- + means all levels below that level, regardless of depth in the hierarchy.
Examples
Worker Restrictions
Define a host that will only run jobs in /private/very/deep
worker_cluster = "/private/very/deep"
worker_restrictions = "/private/very/deep"
Define a host that will run jobs in any cluster at /private or 1 level below - done with the *
worker_cluster = "/private"
worker_restrictions = "/private or /private/*"
Define a host that will only run jobs in /private/very or any level below - done with the +
worker_cluster = "/private/very"
worker_restrictions = "/private/very or /private/very/+"
Job Restrictions
Submit a job that will have highest priority in /private and run only in /private:
qbsub -cl /private -restr /private <cmd>
Submit a job that will have highest priority in /private/very, but could run in any host in /private or in the first level below /private
qbsub -cl /private/very -restr '/private or /private/*' <cmd>
Submit a job that will have highest priority in /private/very/deep, but could run in any host at any level at /private or below
qbsub -cl /private/very/deep -restr '/private or /private/+' hostname
Hosts
Qube allows users to specify a list of hosts, for the job to run on. This is a comma-delimited list of hostnames.
Example
% qbsub --hosts "qb001,qb002" command
Omit Hosts
Qube allows users to specify a list of hosts on which the job is restricted from running. This is a comma-delimited list of hostnames. This blacklists the hosts from running on these hosts.
Example
% qbsub --omithosts "qb001,qb002" command
Host Groups
Qube allows the administrator to organize the farm into clusters or host groups. These groups have no hierarchy, and hosts are allowed membership in multiple groups. In order to restrict a job to a specific set of hosts, the user may specify in the 'group' field of the job, which groups they want the job restricted to.
Example
% qbsub --groups "vfx,character" Render my/file.ma
Omit Groups
This is the opposite of the Host Groups option, where the job will restrict itself from running upon any hosts which are contained by the specified groups.
Example
% qbsub --omitgroups "vfx,character" command
Host Order
By default Qube chooses any host in the list of hosts which qualify. If given a choice, a job is allowed to prefer a particular host based upon its attributes. This is established using the Qube resources and priorities defined earlier in the Requirements section of this document.
Syntax:
signhost.property
signhost.resource.[total|used|avail]
The sign in the expression is used to determine if the job would prefer the smallest or the largest value possible.
The possible values for sign are "+" or "-", and if not specified, sign defaults to "+". The "+" is used to specify using the highest value first, and the "-" is to use the lowest value. These can be combined and will be used in order specified.
Example
Choose the fastest host:
% qbsub --hostorder "host.processor_speed" Render myscene.ma
Choose the host with the least processors:
% qbsub --hostorder "-host.processors.total" Render myscene.ma
Choose the fastest host with the least processors:
% qbsub --hostorder "host.processor_speed,-host.processors.total" Render myscene.ma