在OpenLava中探索Fairshare调度

分享的好处非常明显。无论我们是共享一杯苏打，公寓还是HPC集群，分享都可以降低我们的费用。

OpenLava 的功能之一是fairshare调度。对于不熟悉fairshare调度的用户，这个新特性指的是根据策略共享资源。如果一个集群花费了一百万美元，而部门A贡献了800,000美元，而部门B贡献了200,000美元，基于80/20（当有争用时）共享资源可能被认为是公平的。Fairshare不意味着“平等份额” – 但它的意思是根据政策分享，通常与现有资源成比例。A部门可能有不同级别的员工。如果我的首席科学家和实习生之间的资源冲突，我可能需要一些措施，以确保聪明的实习生不能垄断集群，留下我的首席科学家无所适从。同时我也想测试一下层次共享。

OpenLava获取Fairshare

Fairshare调度在IBM Platform LSF中已存在多年，在OpenLava中，开源调度程序添加了此功能。为了演示共享场景，我将OpenLava设置如下：

首先，一个OpenLava配置文件中，我定义了两组用户。即我公司有工作人员和合作伙伴。我为他们各自设置一个组，并声明每个组的成员。三名工作人员将以1：1：1的比例共享资源，合作伙伴组的两名成员将共享平等分配的资源，如果有需要的话，我还可以选择不同的比率。这代表我的“部门内分享”政策。

Begin UserGroup

GROUP_NAME GROUP_MEMBER USER_SHARES

#G1 (david john zebra) ([david, 1] [john,1] [zebra, 1])

#G2 (crock wlu kluk) ([crock, 2] [wlu,1] [kluk,1])

staff (william david james) ([wlu, 1] [david, 1] [james, 1])

partners (gord dan) ([gord, 1] [dan, 1])

End UserGroup

我们在lsb.users的配置中添加一个附加约束。我不想任何时候，我的任何合作伙伴单独消耗超过五个集群中的五个位置（意味着他们最多同时在集群主机上运行五个作业）。语法partners @表示限制适用于组的每个成员。

Begin User

USER_NAME MAX_JOBS JL/P

#develop@ 20 8

#support 50 –

partners@ 5 –

End User

接下来，我们定义一个称为“共享”的队列，它将在我们的两组用户（员工和合作伙伴）之间实施分配策略。这是在lsb.queues中完成的，语法如下。每分配给员工三个位置，合作伙伴只能获得一个 – 这意味着我们的员工将在保证的基础上获得75％的资源 – 如果没有合作伙伴提交工作，这个比例甚至会更大。

Begin Queue

QUEUE_NAME = share

PRIORITY = 30

NICE = 20

DESCRIPTION = Queue to demonstrate fairshare scheduling policy

FAIRSHARE = USER_SHARES[[staff,3] [partners,1]]

End Queue

模拟作业

接下来，为了产生合理的工作量，我们编写了一个脚本，将代表五个用户提交工作 – 其中三个是“工作人员”，两个是“合作伙伴”。为了增加可信度，我们生成了一个工作负载，每个用户有1,000个作业，总计5000个作业。每个作业将需要10秒钟。以10秒为单位的5,000个作业的工作负载，如果在单个计算机上运行理想情况下将花费50,000秒或138.9小时。因为我们的集群允许我们同时运行40个作业（我们有40个作业插槽配置，如下所示），我们的理论时间减少到3.47小时，几乎正是我实际调整工作量和写这个博客所需要的时间。

下面是OpenLava bhosts命令，显示我们的四个群集主机上的可用调度插槽。

[root @ ip-172-31-34-75〜]＃bhosts

HOST_NAME状态JL / U MAX NJOBS运行SSUSP USUSP RSV

ip-172-31-34-75 ok – 10 0 0 0 0 0

ip-172-31-35-144 ok – 10 0 0 0 0 0

ip-172-31-35-97确定 – 10 0 0 0 0 0

ip-172-31-46-36 ok – 10 0 0 0 0 0

[root @ ip-172-31-34-75〜]＃

鉴于此集群配置和共享策略，下一步是向代表我们五个用户的定义提交5,000工作量。这个脚本的作用是提交工作数组，每个用户一个，每个包含1,000个作业。

＃！/ bin / sh

sudo -u gord -i bsub -q share -J“gordArray [1-1000]”sleep 10

sudo -u dan -i bsub -q share -J“danArray [1-1000]”sleep 10

sudo -u william -i bsub -q share -J“williamArray [1-1000]”sleep 10

sudo -u david -i bsub -q share -J“davidArray [1-1000]”sleep 10

sudo -u james -i bsub -q share -J“jamesArray [1-1000]”sleep 10

我们执行脚本，通过运行脚本将这5,000个耗时10秒的作业提交到我们的集群。

[root@ip-172-31-34-75 ~]# ./fairshare_demo.sh

Job is submitted to queue .

几分钟后，我们发出一个命令来查看我们的5000个作业，以了解它们的状态以及它们是如何被分配给群集主机的。显然，运行的作业正是我们所期望的比例。我们的每个员工有10个运行工作，总共30个工作（75％的插槽） – 我们的两个合作伙伴，相比之下每个运行5个工作，总计25％的插槽。

[root@ip-172-31-34-75 ~]# bjobs -u all | more

JOBID USER STAT QUEUE FROM_HOST EXEC_HOST JOB_NAME SUBMIT_TIME

313 william RUN share ip-172-31-3 ip-172-31-3 *mArray[1] Mar 15 16:10

313 william RUN share ip-172-31-3 ip-172-31-3 *mArray[2] Mar 15 16:10

313 william RUN share ip-172-31-3 ip-172-31-3 *mArray[3] Mar 15 16:10

313 william RUN share ip-172-31-3 ip-172-31-3 *mArray[4] Mar 15 16:10

313 william RUN share ip-172-31-3 ip-172-31-3 *mArray[5] Mar 15 16:10

313 william RUN share ip-172-31-3 ip-172-31-3 *mArray[6] Mar 15 16:10

313 william RUN share ip-172-31-3 ip-172-31-3 *mArray[7] Mar 15 16:10

313 william RUN share ip-172-31-3 ip-172-31-3 *mArray[8] Mar 15 16:10

313 william RUN share ip-172-31-3 ip-172-31-3 *mArray[9] Mar 15 16:10

313 william RUN share ip-172-31-3 ip-172-31-3 *Array[10] Mar 15 16:10

314 david RUN share ip-172-31-3 ip-172-31-4 *dArray[1] Mar 15 16:10

314 david RUN share ip-172-31-3 ip-172-31-4 *dArray[2] Mar 15 16:10

314 david RUN share ip-172-31-3 ip-172-31-4 *dArray[3] Mar 15 16:10

314 david RUN share ip-172-31-3 ip-172-31-4 *dArray[4] Mar 15 16:10

314 david RUN share ip-172-31-3 ip-172-31-4 *dArray[5] Mar 15 16:10

314 david RUN share ip-172-31-3 ip-172-31-4 *dArray[6] Mar 15 16:10

314 david RUN share ip-172-31-3 ip-172-31-4 *dArray[7] Mar 15 16:10

314 david RUN share ip-172-31-3 ip-172-31-4 *dArray[8] Mar 15 16:10

314 david RUN share ip-172-31-3 ip-172-31-4 *dArray[9] Mar 15 16:10

314 david RUN share ip-172-31-3 ip-172-31-4 *Array[10] Mar 15 16:10

311 gord RUN share ip-172-31-3 ip-172-31-3 *dArray[1] Mar 15 16:10

312 dan RUN share ip-172-31-3 ip-172-31-3 *nArray[1] Mar 15 16:10

311 gord RUN share ip-172-31-3 ip-172-31-3 *dArray[2] Mar 15 16:10

312 dan RUN share ip-172-31-3 ip-172-31-3 *nArray[2] Mar 15 16:10

311 gord RUN share ip-172-31-3 ip-172-31-3 *dArray[3] Mar 15 16:10

312 dan RUN share ip-172-31-3 ip-172-31-3 *nArray[3] Mar 15 16:10

311 gord RUN share ip-172-31-3 ip-172-31-3 *dArray[4] Mar 15 16:10

312 dan RUN share ip-172-31-3 ip-172-31-3 *nArray[4] Mar 15 16:10

311 gord RUN share ip-172-31-3 ip-172-31-3 *dArray[5] Mar 15 16:10

312 dan RUN share ip-172-31-3 ip-172-31-3 *nArray[5] Mar 15 16:10

315 james RUN share ip-172-31-3 ip-172-31-3 *sArray[1] Mar 15 16:10

315 james RUN share ip-172-31-3 ip-172-31-3 *sArray[2] Mar 15 16:10

315 james RUN share ip-172-31-3 ip-172-31-3 *sArray[3] Mar 15 16:10

315 james RUN share ip-172-31-3 ip-172-31-3 *sArray[4] Mar 15 16:10

315 james RUN share ip-172-31-3 ip-172-31-3 *sArray[5] Mar 15 16:10

315 james RUN share ip-172-31-3 ip-172-31-3 *sArray[6] Mar 15 16:10

315 james RUN share ip-172-31-3 ip-172-31-3 *sArray[7] Mar 15 16:10

315 james RUN share ip-172-31-3 ip-172-31-3 *sArray[8] Mar 15 16:10

315 james RUN share ip-172-31-3 ip-172-31-3 *sArray[9] Mar 15 16:10

315 james RUN share ip-172-31-3 ip-172-31-3 *Array[10] Mar 15 16:10

311 gord PEND share ip-172-31-3 *dArray[6] Mar 15 16:10

311 gord PEND share ip-172-31-3 *dArray[7] Mar 15 16:10

311 gord PEND share ip-172-31-3 *dArray[8] Mar 15 16:10

311 gord PEND share ip-172-31-3 *dArray[9] Mar 15 16:10

311 gord PEND share ip-172-31-3 *Array[10] Mar 15 16:10

311 gord PEND share ip-172-31-3 *Array[11] Mar 15 16:10

311 gord PEND share ip-172-31-3 *Array[12] Mar 15 16:10

311 gord PEND share ip-172-31-3 *Array[13] Mar 15 16:10

分配与我们的共享策略直接一致。

该bqueue s命令作用是显示出谁的工作是由用户执行特定的队列分配。

[root@ip-172-31-34-75 ~]# bqueues -l share

QUEUE: share

— Queue to demonstrate fairshare scheduling policy

PARAMETERS/STATISTICS

PRIO NICE STATUS MAX JL/U JL/P JL/H NJOBS PEND RUN SSUSP USUSP RSV

30 20 Open:Active – – – – 4720 4680 40 0 0 0

Interval for a host to accept two jobs is 0 seconds

SCHEDULING PARAMETERS

r15s r1m r15m ut pg io ls it tmp swp mem

loadSched – – – – – – – – – – –

loadStop – – – – – – – – – – –

SCHEDULING POLICIES: FAIRSHARE

TOTAL_SLOTS: 40 FREE_SLOTS: 0

USER/GROUP SHARES PRIORITY DSRV PEND RUN

staff/ 3 0.750 30 2760 30

william 1 0.333 10 920 10

david 1 0.333 10 920 10

james 1 0.333 10 920 10

partners/ 1 0.250 10 1920 10

gord 1 0.500 5 960 5

dan 1 0.500 5 960 5

USERS: all users

HOSTS: all hosts used by the OpenLava system

请注意，即使集群中有成千上万个作业，bqueues -l输出显示的共享策略仍具有完全保真性。有一段时间，在工作完成之后，我们看到，我们的工作人员已经完成了超过50％的工作，资源分配仍然完美平衡。

SCHEDULING POLICIES: FAIRSHARE

TOTAL_SLOTS: 40 FREE_SLOTS: 40

USER/GROUP SHARES PRIORITY DSRV PEND RUN

staff/ 3 0.750 30 1380 0

william 1 0.333 10 460 0

david 1 0.333 10 460 0

james 1 0.333 10 460 0

partners/ 1 0.250 10 1460 0

gord 1 0.500 5 730 0

dan 1 0.500 5 730 0

USERS: all users

HOSTS: all hosts used by the OpenLava system

OpenLava的Fairshare调度策略有多公平？虽然这是一个非常简单的例子，但基于这个测试，Openlava的Fairshare调度策略看起来很强大！