By Sinisa Veseli
Advance reservation (AR) capability is one of the most important new features of the upcoming Grid Engine 6.2 release. New command line utilities allow users and administrators to submit resource reservations (qrsub), view granted reservations (qrstat), or delete reservations (qrdel). Also, some of the existing commands are getting new switches. For example, the “-ar <AR id>“ option for qsub indicates that the submitted job is a part of an existing advanced reservation. Given that AR is a new functionality, I thought that it might be useful to describe how it works on a simple example (using 6.2 Beta software).
Advanced resource reservations can be submitted to Grid Engine by queue operators and managers, and also by a designated set of privileged users. Those users are defined in ACL “arusers”, which by default looks as follows:
$ qconf -sul arusers deadlineusers defaultdepartment
$ qconf -su arusers name arusers type ACL fshare 0 oticket 0 entries NONE
The “arusers” ACL can be modified via the “qconf -mu” command:
$ qconf -mu arusers veseli@tolkien.ps.uud.com modified "arusers" in userset list
$ qconf -su arusers name arusers type ACL fshare 0 oticket 0 entries veseli
Once designated as a member of this list, the user is allowed to submit ARs to Grid Engine:
[veseli@tolkien]$ qrsub -e 0805141450.33 -pe mpi 2 Your advance reservation 3 has been granted
[veseli@tolkien]$ qrstat ar-id name owner state start at end at duration ----------------------------------------------------------------------------------------- 3 veseli r 05/14/2008 14:33:08 05/14/2008 14:50:33 00:17:25
[veseli@tolkien]$ qstat -f queuename qtype resv/used/tot. load_avg arch states --------------------------------------------------------------------------------- all.q@tolkien.ps.uud.com BIP 2/0/4 0.04 lx24-x86
For the sake of simplicity, in the above example we have a single queue (all.q) that has 4 job slots and a parallel environment (PE) mpi assigned to it. After reserving 2 slots for the mpi PE, there are only 2 slots left for running regular jobs until the above shown AR expires. Note that the "–e" switch for qrsub designates requested reservation end time in the format YYMMDDhhmm.ss. It is also worth pointing out that the qstat output changed slightly with respect to previous software releases in order to accommodate display of existing reservations.
If we now submit several regular jobs, only 2 of them will be able to run:
[veseli@tolkien]$ qsub regular_job.sh
Your job 15 ("regular_job.sh") has been submitted
...
[veseli@tolkien]$ qsub regular_job.sh
Your job 19 ("regular_job.sh") has been submitted[veseli@tolkien]$ qstat -f queuename qtype resv/used/tot. load_avg arch states --------------------------------------------------------------------------------- all.q@tolkien.ps.uud.com BIP 2/2/4 0.03 lx24-x86 15 0.55500 regular_jo veseli r 05/14/2008 14:34:32 1 16 0.55500 regular_jo veseli r 05/14/2008 14:34:32 1
############################################################################ - PENDING JOBS - PENDING JOBS - PENDING JOBS - PENDING JOBS - PENDING JOBS ############################################################################ 17 0.55500 regular_jo veseli qw 05/14/2008 14:34:22 1 18 0.55500 regular_jo veseli qw 05/14/2008 14:34:23 1 19 0.55500 regular_jo veseli qw 05/14/2008 14:34:24 1
However, if we submit jobs that are part of the existing AR, those are allowed to run, while jobs submitted earlier are still pending:
[veseli@tolkien]$ qsub -ar 3 reserved_job.sh
Your job 20 ("reserved_job.sh") has been submitted
[veseli@tolkien]$ qsub -ar 3 reserved_job.sh
Your job 21 ("reserved_job.sh") has been submitted[veseli@tolkien]$ qstat -f queuename qtype resv/used/tot. load_avg arch states --------------------------------------------------------------------------------- all.q@tolkien.ps.uud.com BIP 2/4/4 0.02 lx24-x86 15 0.55500 regular_jo veseli r 05/14/2008 14:34:32 1 16 0.55500 regular_jo veseli r 05/14/2008 14:34:32 1 20 0.55500 reserved_j veseli r 05/14/2008 14:35:02 1 21 0.55500 reserved_j veseli r 05/14/2008 14:35:02 1
############################################################################ - PENDING JOBS - PENDING JOBS - PENDING JOBS - PENDING JOBS - PENDING JOBS ############################################################################ 17 0.55500 regular_jo veseli qw 05/14/2008 14:34:22 1 18 0.55500 regular_jo veseli qw 05/14/2008 14:34:23 1 19 0.55500 regular_jo veseli qw 05/14/2008 14:34:24 1
The above example illustrates how ARs work. As long as particular reservation is valid, only jobs that are designated as part of it can utilize resources that have been reserved.
I think that AR will prove to be extremely valuable tool for planning grid resource usage, and I’m very pleased to see it in the new Grid Engine release.
No comments:
Post a Comment