Title: Re: [slurm-dev] Configuring multiple priority levels
What's the trade-off for using tier3? It would seem inconsiderate
users would never use tier2, bypassing it completely, as there is no
advantage to using it over tier3.|
On 04/08//2017 17:30, Evan Remington
Configuring multiple priority levels
I'm looking for some feedback on a scheme I've come up with
to configure priority tiers on our cluster which is used by a
few dozen groups.
The desired behavior is that users can submit jobs to one
of three priority tiers:
- Tier 1: Lowest priority; any user can use as many
resources as are available (priority subject to
- Tier 2: Higher priority; users can use up to a certain
amount of resources which are shared by their group.
- Tier 3: Higher priority AND the ability to preempt jobs
in Tier 1. The available resources in this tier are shared
between those of Tier 2.
The way I've thought to do this is to set up three QOSs
with the behavior described above (but without TRES limits),
and then for each group, three corresponding accounts. The
first account would only be allowed to submit to the Tier 1
QOS, the second to Tier 2, and the Third to Tier 3. Tier 2
would have GrpTRES configured, and then Tier 3 would be a
child of Tier 2 and therefore share the available TRES.
Jobs would default to the Tier 1 account, going to the Tier
1 QOS. Anyone who wants to submit a higher priority job just
adds --account=Tier2 or --account=Tier3.
I've tested this configuration for a single user and it
seems to produce the desired result. Is there a more
straightforward way to achieve the same behavior? Or is there
some reason this configuration would be problematic?
Description: S/MIME Cryptographic Signature