LSF实践专题（12）：LSF中作业调度的基本顺序和fairshare简介

在LSF的集群中，往往会有大量的作业等待调度，那么这些作业调度有先后吗？又是以哪些条件作为决定调度先后的依据呢？

正如很多朋友都了解的，LSF集群中首先可以建立很多的队列，这些队列可以视作是管理存放LSF作业的容器，每一个作业都属于其中某一个队列。用户可以在提交作业时用bsub命令中的-q参数来指定将作业投放到哪一个队列，如果队列不存在，作业提交会失败，如果没有-q参数，就会默认投放到默认队列中，在初始情况下，默认队列是名为normal的队列，我们可以通过修改lsb.params中的DEFAULT_QUEUE来设置其它队列作为默认队列。

我们将默认队列修改为q1：

LSF的管理员可以为每一个队列设定一个优先级（priority），LSF在调度作业的时候就会依次从优先级最高到最低的队列里检查所有等待调度的作业。比如有三个队列q1, q2, q3，优先级分别是100，200，300，那么，LSF就会先检查q3队列里有哪些作业，将这些作业都调度完成以后，再看q2队列里面的作业，最后再看q1队列。

图中第二列PRIO就是priority的值，作业调度时，LSF也是按照priority从高到低的顺序依次调度每个队列里的作业，每个队列的priority 数值就是通过队列设置中的PRIORITY参数来指定。

为了避免高优先级队列被滥用，管理员可以对每个队列设置，有哪些用户可以将作业投放到这个队列中，队列设置中的USERS可以指定有哪些用户可以向这个队列提交作业，如果没有指定，相当于USERS=all，也就是任何用户都可以提交，这里还有一些对应的权限规则，我们今天主要讨论作业调度顺序，先不重点研究这个。

那么同一个队列里面的作业又是按照什么顺序调度的呢？

LSF有一个默认的基本调度策略，叫做先来先服务（FCFS），也就是说，按照作业的提交顺序，来进行调度。就像我们日常的排队一样，这是一个基本且公平的方案。

但是，实际使用中，有时候会遇到下面这样的问题：比如有A和B两个用户，用户A在9点的时候提交了500个作业，用户B在9点半提交了2000个作业，假设当前的集群，用户A和用户B的作业每个都要运行5分钟，而整个集群可以同时运行10个这样的作业。那么，在9点半，用户B提交作业时，用户A的作业完成了60个，还有440个没有完成，如果按照先来先服务的策略，那么用户B的所有作业都要等到用户A的作业全部完成才能得到调度。用户A的作业全部运行完需要（500 / 10）x 5 = 250 分钟，也就是说，用户B的作业要等到13点10分的时候才能开始调度，要等待将近4个小时，这对用户B来说是有些不太公平的，因为他只比用户A提交晚了30分钟，但是因为用户A一次性提交了很多的作业，导致用户B要等待很久才能使用计算资源。

这种情况下，一个直观的办法是：用户B将自己的作业提交到一个高优先级的队列中，但是一方面问题是，用户B不一定有使用高优先级队列的权利，另一方面问题是，如果用户B所有的队列都投放到高优先级队列，同样对用户A也不公平。那么还有什么好办法吗？

LSF还提供了另一种应用比较广泛的调度策略，专门来应对这种多用户的场景，这就是fairshare策略。这是一种基于用户的均衡调度策略，可以让不同的用户相对公平地使用集群资源。想要启用fairshare，只需要在相应的队列里配置fairshare参数即可，一个最基础的配置方式是：

这个配置是为所有的用户配置一样的基础值，里面的1000称为shares，是一个初始优先级，LSF会使用一个公式为每个有作业等待调度的用户计算一个当前的fairshare优先级，如果用户的基础值（shares）相同，那么谁已经使用了更多的资源，谁的优先级相应也就会更低，反之则会更高。

回到刚才用户A和用户B的例子中，因为9点半时，用户A已经使用了很多资源，所以当用户B的作业提交到LSF中时，用户B就能得到一个较高的优先级，这样，当有一批用户A的作业完成时，LSF就会优先调度用户B新提交的作业，而不必等待用户A的500个作业全部完成。同样，当用户B的作业也完成了和用户A一样多时，两个用户的优先级就再次相等，LSF会根据FCFS的原则进行调度，以此循环，用户A和用户B的作业会交替得到调度，实现了相对公平的原则。

如果我们希望某个用户能相对得到更多的一些资源，但又不至于完全独占，也可以为这个用户配置一个比其他用户更高的基础值（shares），比如配置成：

在这个配置中，user1就可以按照2:1的比例与其他用户分享集群的资源。也就是在作业充足的情况下，user1完成的作业数量与其他用户完成作业的数量比值是2:1。

那么具体这些优先级是怎么计算的呢？

我们来简单看一下fairshare的计算公式。在LSF中，默认会根据作业使用的CPU时间，作业总运行时间，和作业运行的数量来决定调度顺序。首先我们可以通过bparams -a看到默认 启用的factor参数有CPU_TIME_FACTOR，RUN_TIME_FACTOR和RUN_JOB_FACTOR。

fairshare在这时的计算公式就是：

shares / (cpu_time / 3600 * CPU_TIME_FACTOR + run_time / 3600 * RUN_TIME_FACTOR + (1 + job_slots) * RUN_JOB_FACTOR)

公式里的cpu_time指的是用户当前所有正在运行的作业已经使用的CPU time总和；run_time则是用户当前所有正在运行作业的运行时间总和；job_slots则代表用户所有正在运行作业所占用的slots总和。3600是一小时的秒数，也就是说我们在计算runtime和cputime时是以小时作为运算单位的。

我们假设，用户A和用户B的shares都是1000，当前用户A正在运行10个作业，10个作业运行5分钟时，集群内空余了一个slots出来，则此时，用户A（tadmin1）和用户B（tadmin2）的priority可以通过bqueues -l命令看到关于fairshare相关的数据，如下图所示。输出中包括CPU_TIME，RUN_TIME，SHARES和最终的priority数值等，PRIORITY值越高，用户的作业就越先被调度。

按照上图数据计算，用户A（tadmin1）的fairshare priority = 1000 / (1147 / 3600 * 0.7 + 3010 / 3600 * 0.7 + (1 + 10) * 3) = 29.5785266 ， 进行小数截取后就是图中的29.579。

而用户B（tadmin2）的fairshare priority = 1000 / (0 * 0.7 + 0 * 0.7 + (1 + 0) * 3) =333.333 。

因此，LSF会优先调度用户B的作业，而每多运行一个作业，用户B的fairshare priority就会相应有所降低，当用户B的fairshare优先级低于用户A的时候，用户A的作业就会优先得到调度。

小提示：我们这里只是用于演示，所以集群内的作业数量很少，如果用户的作业到达了上千个的时候，根据公式计算出的priority值就会变成小于1的浮点数，这样会使得各个用户的priority比较不是特别明显，容易造成fairshare的不敏感。在这种情况下，我们可以通过增大fairshare设置中的基础值（SHARES）的倍率来进行调整，比如把基础值设为10000甚至100000，我们可以根据自己集群的规模和作业情况选择适合自己集群的基础值的大小，这样会使得fairshare更加灵敏。

我们用另一个例子来看一下在fairshare原则下，如何实现用户间的相对公平。假设此时用户A和用户B都没有正在运行的作业，但是各自都有1000个作业等待调度，如果这时有100个slots空余出来，那么在接下来的调度中，会发生什么呢？

在最开始，用户A和用户B的fairshare优先级相等，因此LSF会按照FCFS的原则选取用户A或者用户B的一个作业进行调度，如果作业的调度结果是可以运行，LSF会将该用户的job_slots变成1，这样，这个用户的fairshare就会略低于另一个用户，所以第二个job就从另一个用户的作业进行选取。以此类推，每多调度一个作业，所属用户的fairshare优先级就会相应降低，这样最终我们发现，用户A和用户B会各自得到50个slots来运行自己的作业，得到了相对公平的调度结果。

读到这里，也许有些朋友会发现另一个问题，如果用户A的作业时间相对很长，对公平性会有什么影响呢？

假设当前集群有100个slots，用户A在9点时提交了100个作业，且每个都要运行1小时。因为当前没有其他用户等待，所以100个作业都会运行起来。在9点10分的时候，用户B提交了500个作业，9点15分，用户A也提交了500个作业，那么当用户B等待了50分钟后，在用户A的第一批100个作业结束后，用户A和用户B仍然以1:1的比例分享集群资源，对于用户B是否不是非常公平呢？

对于这种情况， LSF有另外一个参数来控制：HIST_HOURS

这个参数默认值是5，表示LSF会将之前5小时以内完成作业的运行时间和占用的CPU时间都计入到fairshare计算公式中，这样，当用户A的100个作业都完成以后，用户A的fairshare priority不会上升，而是随着时间以一个曲线方式逐渐上升，使得fairshare策略更加的公平。

我们尝试来模拟计算一下用户A在完成了100个作业后的fairshare priority，因为我们假设每个作业运行时间（RUN TIME）是1小时，也就是3600秒，所以100个作业总共是360000秒。为了方便计算我们假设每个作业的CPU TIME是RUN TIME的50%，所以100个作业的CPU TIME 就是180000秒。因为用户A当前没有作业，所以run job数量是0。我们将这些数字带入公式：

1000 / ( 180000 / 3600 * 0.7 + 360000 / 3600 * 0.7 + (1 + 0) * 3) = 9.259

而对于用户B，因为还没有运行过作业，RUN TIME和CPU TIME的总和都是0，run job 数量也是0，所以用户B的priority仍然是：

1000 / (0 + 0 + (1+0) * 3) = 333.333

这就让用户A的优先级在相当一段时间都会低于没有运行任何作业的用户B，从而达到更好的公平原则。

对于fairshare，还有很多相关的细节用于更多更复杂的场景，我们这次就先介绍到这里，后面有机会再做更深入的探讨。

欢迎关注下方微信公众号【HPC常青园】，共同交流HPC集群管理经验和最佳实践。如果您有关于HPC集群的具体需求，欢迎邮件沟通交流：hpc@ivyent.cn。