7.1.1.1 Resources
Under Maui, the resources specified for a reservation
are specified by way of a task
description. Conceptually, a task can be thought of as an atomic,
or indivisible, collection of resources. The resources may include
processors, memory, swap, local disk, etc. For example, a single
task may consist of one processor, 2 GB of memory, and 10 GB of local disk.
A reservation consists of one or more tasks. In attempting to locate
the resources required for a particular reservation, Maui will examine
all feasible resources and locate the needed resources in groups specified
by the task description. An example may help clarify this concept:
Reservation A requires 4 tasks. Each task is
defined as 1 processor and 1 GB of memory.
Node X has 2 processors and 3 GB of memory available
Node Y has 2 processors and 1 GB of memory available
Node Z has 2 processors and 2 GB of memory available
In attempting to collect the resources needed for
the reservation, Maui would examine each node in turn. Maui finds
that Node X can support 2 of the 4 tasks needed by reserving 2 processors
and 2 GB of memory, leaving 1 GB of memory unreserved. Analysis of
Node Y shows that it can only support 1 task reserving 1 processor and
1 GB of memory, leaving 1 processor unreserved. Note that the unreserved
memory on Node X cannot be combined with the unreserved processor on Node
Y to satisfy the needs of another task because a task requires all resources
to be located on the same node. Finally, analysis finds that node
Z can support 2 tasks, fully reserving all of its resources.
Both reservations and jobs use the concept of a task
description in specifying how resources should be allocated. It is
important to note that although a task description is used to allocate
resources to a reservation, this description does not in any way constrain
the use of those resources by a job. In the above example, a job
requesting resources simply sees 4 processors and 4 GB of memory available
in reservation A. If the job has access to the reserved resources
and the resources meet the other requirements of the job, the job could
utilize these resources according to its own task description and needs.
Currently, the resources which can be associated
with reservations include processors, memory, swap, local disk, initiator
classes, and any number of arbitrary resources. Arbitrary resources
may include peripherals such as tape drives, software licenses, or any
other site specific resource.
7.1.1.2 TimeFrame
Associated with each reservation is a timeframe.
This specifies when the resources will be reserved or dedicated to jobs
which meet the reservation's ACL. The timeframe simply consists of
a start time and an end time. When configuring a reservation, this
information may be specified as a start time together with either an end
time or a duration.
7.1.1.3 Access Control List
A reservation's access control list specifies which
jobs can use a reservation. Only jobs which meet one or more of a
reservation's access criteria are allowed to use the reserved resources
during the reservation timeframe. Currently, the reservation access
criteria include the following: users, groups, accounts, classes,
QOS, and job duration.
7.1.1.4 Job to Reservation Mapping
While a reservation's ACL will allow particular jobs to utilize
reserved resources, it does not force any job to utilize these resources.
With each job, Maui attempts to locate the best possible combination of
available resources whether these are reserved or unreserved. For
example, in the figure below, note that job X, which meets access
criteria for both reservation A and B, allocates a portion
of its resources from each reservation and the remainder from resources
outside of both reservations.
Although by default, reservations make resources
available to jobs which meet particular criteria, Maui can be configured
to constrain jobs to only run within accessible reservations. This
can be requested by the user on a job by job basis using a resource manager
extension flag or can be enabled administratively via a QoS flag.
For example, assume two reservations were created as shown below.
> setres -g staff -d 8:00:00 'node[1-4]'
reservation 'staff.1' created on 4 nodes
> setres -u john tasks==2
reservation 'john.1' created on two nodes
If the user john, who happened to also be
a member of the group staff, wanted to force his job to run within
a particular reservation, he could do so using the FLAGS resource
manager extension. Specifically, in the case of a PBS job, the
following submission would force the job to run within the staff.1
reservation.
> qsub -l nodes=1,walltime=1:00:00 -W x=FLAGS:ADVRES:staff.1 testjob.cmd
Note that for this to work, PBS will need to have
resource manager extensions enabled as described in the PBS
Resource Manager Extension Overview. If the user simply wants
the job to run on reserved resources but does not care which, he could
submit the job with
> qsub -l nodes=1,walltime=1:00:00 -W x=FLAGS:ADVRES testjob.cmd
To enable job to reservation mapping via QoS,
the QoS flag 'USERRESERVED' should be set in a similar manner.
7.1.1.5 Reservation Specification
There are two main types of reservations which sites
typically deal with. The first, administrative reservations,
are typically one time reservations created for special purposes and projects.
These reservations are created using the setres
command. These reservations provide an integrated mechanism to allow
graceful management of unexpected system maintenance, temporary projects,
and time critical demonstrations. This command allows an administrator
to select a particular set of resources or just specify the quantity of
resources needed. For example an administrator could use a regular
expression to request a reservation be created on the nodes 'blue0[1-9]'
or could simply request that the reservation locate the needed resources
by specifying a quantity based request such as 'TASKS==20'.
The second type of reservation is called a standing
reservation. It is of use when there is a recurring need for a particular
type of resource distribution. For example, a site could use a standing
reservation to reserve a subset of its compute resources for quick turnaround
jobs during business hours on Monday thru Friday. Standing
reservations are created and configured by specifying parameters in the
maui.cfg file. The Standing
Reservation Overview provides more information about configuring and
using these reservations.
7.1.1.6 Reservation Behavior
As mentioned above, a given reservation may have
one or more access criteria. A job can utilize the reserved resources
if it meets at least one of these access criteria. It is possible
to 'stack' multiple reservations on the same node. In such a situation,
a job can only utilize the given node if it meets at least access criteria
of each active reservation on the node.
7.1.1.7 Other Reservation Attributes
Charge Account - Allows a reservation
to charge for resources which are dedicated to the reservation but not
used by any job.
See also:
N/A