Reservations: Difference between revisions
(Created page with "SLURM is capable of assuring resources be available at a specified time for a specified set of users and/or groups via the use of reservations. A reservation can be made far i...") |
No edit summary |
||
Line 1: | Line 1: | ||
SLURM is capable of assuring resources be available at a specified time for a specified set of users | SLURM is capable of assuring resources be available at a specified time for a specified set of users via the use of reservations. A reservation can be made far in advance of the time when the resources are needed, and SLURM will automatically prevent jobs from being scheduled that do not belong to that reservation during that time. In fact, the earlier the better - this allows long jobs to terminate properly. | ||
This may be required in extreme circumstances where resources must be available for demonstration or teaching purposes at the moment when the event is happening. | This may be required in extreme circumstances where resources must be available for demonstration or teaching purposes at the moment when the event is happening. | ||
Line 9: | Line 9: | ||
== Requesting a Reservation == | == Requesting a Reservation == | ||
There is no way to create a reservation yourself - an admin must create it. To request a reservation, please email your system administrator. Given that this will dedicate the resources away from general use, there will be a financial cost involved in this, typically equivalent to the cost of running jobs for the entire period defined. | There is no way to create a reservation yourself - an admin must create it. To request a reservation, please email your system administrator and define the list of users (not groups!) who may use this reservation. Given that this will dedicate the resources away from general use, there will be a financial cost involved in this, typically equivalent to the cost of running jobs for the entire period defined. | ||
In addition, it's not currently possible to reserve less than entire nodes at a time, as there's no means to reserve memory and cores separately (And there'd be no guarantee that they'd be on the same machine if so). Thus, the minimum reservation possible is one normal node, and the maximum should be no more than three in order to not disrupt the main workflow. | In addition, it's not currently possible to reserve less than entire nodes at a time, as there's no means to reserve memory and cores separately (And there'd be no guarantee that they'd be on the same machine if so). Thus, the minimum reservation possible is one normal node, and the maximum should be no more than three in order to not disrupt the main workflow. |
Revision as of 12:07, 9 June 2017
SLURM is capable of assuring resources be available at a specified time for a specified set of users via the use of reservations. A reservation can be made far in advance of the time when the resources are needed, and SLURM will automatically prevent jobs from being scheduled that do not belong to that reservation during that time. In fact, the earlier the better - this allows long jobs to terminate properly.
This may be required in extreme circumstances where resources must be available for demonstration or teaching purposes at the moment when the event is happening.
Usage
In order to use a reservation, simply add the following line into your sbatch script:
#SBATCH --reservation="MyReservation"
When you submit your job, SLURM is then asked if you can use these resources. If yes, then your job will proceed as soon as there are resources available inside the reserved allocation.
Requesting a Reservation
There is no way to create a reservation yourself - an admin must create it. To request a reservation, please email your system administrator and define the list of users (not groups!) who may use this reservation. Given that this will dedicate the resources away from general use, there will be a financial cost involved in this, typically equivalent to the cost of running jobs for the entire period defined.
In addition, it's not currently possible to reserve less than entire nodes at a time, as there's no means to reserve memory and cores separately (And there'd be no guarantee that they'd be on the same machine if so). Thus, the minimum reservation possible is one normal node, and the maximum should be no more than three in order to not disrupt the main workflow.