LSF实践专题（16）：reservation调度策略

在LSF集群中作业比较多的时候, 会出现多个作业对同一个计算节点的资源竞争的情况。

当竞争越激烈，资源需求越低的作业会更容易得到所需资源，而对资源需求越多越复杂的作业，就相对越难得到满足。

比如一个节点有16个CPU和32GB内存（为了计算方便，不计入系统运行所需内存），当前运行的作业1占用了8个CPU，16GB内存，作业2和作业3各占用了2个CPU和4GB内存，这样，当前节点还剩下4个CPU和8GB内存可以使用。假设当前集群其他节点都已经达到最大负载，只有当前节点可以使用。

假设用户此时提交了一个新作业——作业A，并指定该作业需要8个CPU和16G内存，这时，所剩的计算资源不够，所以作业A无法运行只能继续等待。

当作业A等待了一段时间后，又有其他用户提交了作业B，而作业B只需要2个CPU和4GB内存，此时，当前节点的剩余资源对作业B来说是足够的，所以作业B立刻就可以运行了。

但是，这时节点空余的计算资源也相应的减少到了2个CPU和4GB内存，这时，如果作业2和作业3结束，会释放4个CPU和8GB内存，如果没有作业B，那么当前剩余的资源正好是8个CPU和16GB内存，作业A刚好可以运行。

但是由于作业B的运行，此时作业A依然无法运行，如果这时候又来了需求比作业A小的作业C，那么当作业B结束时，作业A很有可能依然无法运行。如果小作业很多，又无法同时结束，作业A将很难拿到足够的资源运行，并且一直等待，而且这种情况下即使作业A提交到一个优先级很高的队列，也依然无法改善，因为是资源不足导致作业A没有立刻运行。

这种情况下，一种方式是为作业A所在的队列设置之前介绍过的抢占机制（PREEMPTION）。

还有一种解决方案是使用reservation策略。这种策略可以为设置了该策略的队列中的作业预先保留一部分计算资源，不给其他作业使用，这样就可以阻止作业A在等待时，作业B提前运行。

我们通过在队列中设置RESOURCE_RESERVE参数就可以启用reservation策略，如下图所示，定义了2个队列（lowQ与highQ），并且都设置了reservation策略。

下面我们先来测试一下这个功能的基本作业，再详细解读参数的含义。

我们看到当前的集群内只有一台可用的节点，slots是32，可用内存是6.7GB。我们先提交3个作业<519>、<520>和<521>来占用一部分资源。

如上所示，当前节点可用资源还有8个slots，1.8GB内存。这时我们向队列lowQ提交一个需求16个slots和4GB内存的作业<522>。

因为slots和内存都不够，所以lowQ上的作业<522>会处于pending状态。

通过bjobs -l命令， 我们看到作业<522>虽然没有运行，但是LSF为它预留了当前空余的8个slots和1.8GB内存。

通过bhosts和bhosts -l命令，我们也可以看到slots对应的reservation信息，RSV所对应的数字，就是有多少个slots被预留给作业了，同时，我们看到这个节点的状态也变成了closed，因为剩余的8个slots都被作业<522>预留了，剩余slots为0。

接下来我们杀掉一个占用了8个slots的作业<519>，这会释放8个slots和2GB内存，这样，空余内存会是3.8GB。

虽然slots足够，但是内存仍然不够作业<522>的需求。

这时我们向lowQ提交一个需求更低的作业<526>。

我们看到，新提交的作业<526>并不能立刻运行，因为slots和内存仍然在被作业<522>预留。

如果作业<522>要等很久才能拿到全部的所需资源，那么资源一直被它占用，这对整个集群的利用率是一个很大的降低，有没有好的解决办法？

我们再看一下队列里面启用reservation的参数：

RESOURCE_RESERVE=MAX_RESERVE_TIME[10]

这里的MAX_RESERVE_TIME是指定一个作业最长可以连续预留资源多久，这里的数字代表的是多少分钟。

我们指定了10就表示一次预留最长可以保留10分钟，这10分钟内，预留给一个作业的资源不会分给其它同优先级队列的作业。

但是如果超过了这个时间，预留资源的作业仍然没有运行，LSF会尝试把资源调度给其它等待资源的同优先级队列的作业。

如果没有其它作业拿到这部分资源后可以运行，LSF也会继续把资源预留给等待的作业<522>，并且重新开始计时，到下一个10分钟再次检查是否需要释放资源。

我们看到作业<526>在等待了366秒后，拿到了原本预留给作业<522>的资源，并且开始运行（因为这时作业<522>预留的10分钟期限已经到了，LSF发现把资源给<526>可以让<526>先运行，于是重新进行了分配）。

如果此时没有作业<526>，或者<526>即使拿到了所有预留给<522>的资源仍然不能运行，会再次在新一轮周期内把资源预留给作业<522>。

作业<526>运行占用了4个slots和500MB内存，所以LSF把剩下的12个slots和3408MB内存继续预留给作业<522>。

这时，我们向队列highQ提交一个同样不能满足需求的作业<527>。

我们同样为队列highQ配置了reservation，而作业<522>的新一个预留周期还没到，LSF是否会保留作业<522>的预留资源呢？

我们看到，LSF此时会打破之前的预留方案，把资源重新预留给优先级更高的队列中的作业<527>。

队列上的reservation参数，除了前面介绍的RESOURCE_RESERVE，还有一个SLOT_RESERVE参数，配置方法相同，所不同的是，SLOT_RESERVE只为作业预留slots资源。

配置了RESOURCE_RESERVE或者SLOT_RESERVE后，我们通过bqueues -l也可以看到对应的信息：

以上是对LSF的reservation策略的简单介绍，感谢您的耐心阅读。

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