Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Extended Use Case
The use case described in this section shows how you can combine the Sun ONE GEEE allocation policies with other management features to satisfy a more complicated scenario.
The following is an overview of the scenario:
Two kinds of jobs, ranked by priority
A large number of single-CPU systems, ranked by CPU speed, for example, host A: 900MHz, host B: 750MHz, host C: 464MHz,..., host H: 250MHz
High-priority jobs are to go to the fastest system and low-priority jobs go to the slowest system.
High-priority jobs should have greater percentage of resources allocated to them. However, a job should always run if a system is available, even if it means that a high- priority job goes to a slow system because all fast systems are occupied.
Multiple teams (departments), and each team has a different share of the two job types; for example, team 1 equals 75 percent high, 50 percent low, team 2 equals 25 percent high, 50 percent low, and so forth.
Sample Outcome
If a user submits five high-priority jobs and one low-priority job, and host E is already occupied, the following dispatch order is seen:
TABLE 4 Dispatch Order
|
Job |
Host |
|
high:job 1 |
host A |
|
high:job 2 |
host B |
|
high:job 3 |
host C |
|
high:job 4 |
host D |
|
occupied |
host E |
|
high:job5 |
host F |
|
low:job 1 host H |
|
Configuration
For simplicity, assume that:
Four Sun ONE GEEE projects (high_1, high_2, low_1, low_2) are set up.
Two Sun ONE GEEE departments (Dept1, Dept2) are set up.
To Configure the Extended Use Case
Set up the share tree configuration as shown in FIGURE 4.
The distinction between high and low is not made here, but in the override policy in the next step.
FIGURE 4
Share Tree Policy Assignments for Extended Use CaseIn the override policy, set the following:
TABLE 5 Override Policy
Project
Override Tickets
high_1
200,000
high_2
200,000
low_1
100,000
low_2 100,000
In the cluster configuration, set the following for schedd_params:
SHARE_OVERRIDE_TICKETS=FALSE (This will cause all high jobs to go ahead of low jobs) or SHARE_OVERRIDE_TICKETS=TRUE (This will cause high and low jobs to dispatch in a 2:1 ratio.)
POLICY_HIERARCHY=SO
Define two queues per host, each with a single slot; for example, hostname.x and hostname.y.
Set the queue number as follows:
TABLE 6 Queue Number Setup
Hostname
A
B
C
D
E
F
G
H
hostname.x queue No.
1
2
3
4
5
6
7
hostname.y queue No.
8
7
6
5
4
3
2
1
For every host, set the host-level slots parameter to 1 to ensure that only one slot in total is ever occupied on a single host. See man page complex(5).
Grant the access rights as follows:
hostname.x queues are only accessible to high_1, high_2.
hostname.y queues are only accessible to low_1, low_2.
Set scheduler configuration to "sort by queue number" See man page sched_conf(5).
Grant access for the departments in the Project Configuration as follows:
Dept1 can submit to high_1 and low_1
Dept2 can submit to high_2 and low_2
)
FIGURE 4
User Instructions
To Issue User Instructions
Submit job using the -P flag to indicate the priority.
For example, members of Dept 1 can do: qsub -P high_1 myjob.sh for high priority jobs and qsub -P low_1 myjob.sh for low priority jobs.