【论文阅读】Not All Resources are Visible:Exploiting Fragmented Shadow Resources in Shared-State Scheduler

论文信息

论文地址： Not All Resources are Visible: Exploiting Fragmented Shadow Resources in Shared-State Scheduler Architecture

收录会议： 云计算顶会-ACM Symposium on Cloud Computing(SoCC2023)

作者： 交通大学-李超教授团队

背景

资源：一个集群中有成千上万台机器。

请求： 百万级的请求并发，请求需求更低，运行时间更短，到达秒级甚至毫秒级的运行时间，如下图所示。

调度： 主要有三种集群调度架构，如图2所示，单体式架构由于拓展性和灵活性不足，不适合大规模集群，两级式架构资源利用率低，共享状态架构具有高拓展性，更为流行。

共享状态架构的具体介绍：

• 有一个管理员维护了中央状态视图CSV，它包含了集群资源的最新信息。
• 存在多个并行调度器，调度范围是全局，调度依据是本地状态视图LSV，并将调度决策提交到CSV中，以避免与其他调度器发生冲突。
• CSV 定期更新每个调度器拥有的本地状态视图 (LSV)，并具有固定的更新延迟。
• 最初的共享状态设计会在每次成功的资源分配操作时更新，但在实际集群中，更新延迟通常为秒级，以减少更新带来的系统开销。

对低开销的追求使得每个调度器的LSV间歇性地过时，因为它们在更新延迟内对于已释放资源的最新状态是不可见的，本文将这些资源称为“影子资源”。
影子资源的数量与同步时间间隔和任务运行时间有关，根据理论和实验分析，它会占到已分配资源的2~13%，同时减少同步时间间隔会给调度系统带来较高的同步开销，难以实现，同时云中任务粒度小，会导致影子分散，所以考虑对其的利用是必要的。

但是之前的相关研究主要集中在优化调度策略来有效管理可见资源，如更高的利用率，更低的延迟，而忽略了对于影子资源利用的研究。

创新与贡献

考虑利用影子资源有两点需要注意：

1. 由于影子资源存在时间短，所以需要敏捷、高效地利用。
2. 要灵活、透明，避免干扰正常的调度。

故本文提出了RMiner机制来对影子资源进行利用，它包含三个协作组件：

1. shadow resource manager：负责收集影子资源。
2. RM filter：筛选适合给影子资源利用的任务。
3. RM scheduler：负责将筛选出的任务分配给影子资源。

针对不同的集群管理目标，RMiner 提供 SafeRM 和 SmartRM 两种资源挖掘模式，以平衡资源利用率最大化和冲突最小化

总体创新点如下：

1. 发现了共享状态调度架构中的影子资源，并从理论上和实验上对其进行了分析。
2. 提出了RMiner机制，对影子资源进行了利用。
3. 构建了RMiner的模拟器，实验证明了RMiner可以以较小的开销极大地提高集群性能。

理论分析

经过理论分析，本文得出了影子资源的期望式：

即影子资源总量主要与状态更新延迟d_u和集群中分配的资源数量r_run成正比，而与任务的平均执行时间η成反比。

根据谷歌数据集、fuxi2.0、Borg的数据，假设任务的执行时间为4s_{5s,状态更新延迟为0.3}1.0s，那么影子资源占已分配资源的3~12.5%。
这是值得被考虑的，同时随着轻量云任务的增多，影子资源的利用也会变得更加重要。

通过对阿里巴巴集群数据集的随机采样，并进行了10中不同配置的实验，记录了影子资源的分布情况，与实验分析基本一致，如图3所示。

RMiner机制设计

RMiner机制包含三个协作组件，如图4中的蓝色所示：

1. Shadow Resource Manager 通过新设计的索引，探测并管理最新的影子资源。
2. RM Filter选择适合影子资源的任务（RM Tasks）到任务队列中
3. RM Scheduler负责灵活地将影子资源分配给RM任务。根据特点

RMiner的两大设计原则：

1. 避免入侵：不对原始调度系统做侵入式修改，原始调度系统依旧不需要知道影子资源的存在，并且不会和影子资源的分配发生冲突。
2. 平衡性能：RMiner 面临着最大化利用不可见资源和最小化与可见调度冲突的权衡。过度利用影子资源可能会导致大量抢占式执行，从而降低集群的整体性能，反之亦然。

Shadow Resource Manager

Shadow Resource Manager 通过图5所示的6种索引来探测并管理最新的影子资源：

1. Shadow Resource Id: 用于标识影子资源的唯一ID。
2. Survival Time: 用于标识影子资源的存活时间。
3. Machine Id: 用于标识影子资源所在的机器。(注意同一机器的影子资源会被合并)
4. Available Resource: 用于标识影子资源的可用资源。
5. Occupied Resource: 用于标识影子资源的已占用资源。
6. Allocated Tasks: 用于标识影子资源已分配的任务。

注意在每次状态更新时，Shadow Resource Manager 会将所有空闲的影子资源释放，而只会继续管理已经被占用了的影子资源。

RM任务分配和运行结束释放都不用更新CSV，即CSV还是会一直认为这时候这些资源是空闲的，这样做是为了不影响原本的整个系统。

具体来说，它通过Echo State机制来迅速侦测新的影子资源，这种机制使得影子资源视图能够与CSV同步，但是主机影子资源的状态更新信息会被CSV忽略，而只会被Shadow Resource Manager处理，以避免影响原本的系统

问题：相当于是一种增量式的更新？但是问题在于这种大规模增量式的更新是否也会导致manager的状态更新延迟？延迟会有多严重？而且如果这里假设了这样子可以与最新的资源状态保持同步，那么这种方法能不能用到普通的调度器的同步上。或许直接预测可能的影子资源状态会更好？

RM Filter

RM Filter 是会在任务分配给各个调度器之前提前进行，任务选取有以下3个原则：

1. 过滤的任务应该与影子资源的短暂和碎片化属性相匹配。
2. 其次，过滤后的任务应该被抢先杀死或迁移，因为为了避免入侵，我们优先执行普通任务而不是 RM 任务，这样可以避免影响原始调度系统。
3. 不选取太多任务，以免形成性能瓶颈。具体来说会考虑5个因素：
   1. RM任务队列的长度，表示RM调度器的工作负载；（负相关）
   2. 来自影子资源管理器的当前影子资源量； （正相关）
   3. 当前任务提交率，表示集群的工作负载；（正相关）
   4. RM任务调度的成功率；（正相关）
   5. 调度系统当前的更新延迟。（正相关）

实际上还可以通过强化学习来进行任务的筛选，但是这不是本文的重点。

RM Scheduler

RM Scheduler 的执行如图6所示。它有两种调度模式：

1. 虚线： 调度足够在影子资源上执行的任务，直接分配给影子资源，对CSV透明。（这种才叫RM任务）实际上就是将影子资源倒序排列，遍历选取合适的资源进行分配。
2. 实线： 调度不能在影子资源上执行的任务，当做是普通的调度器进行调度。流程如下：
   1. 提交资源分配决定给影子状态管理视图；
   2. 影子资源管理视图返回信号没有足够的影子资源；
   3. 提交调度决策给CSV，就像普通的调度器一样；
   4. 如果调度成功就直接执行。

可以看出实际上RM Scheduler在执行时既需要拥有对影子资源的视图，也需要拥有对CSV的视图。

Resource Miner 优化

影子资源等待延迟： 当通过CSV更新，调度器对影子资源可见到这部分影子资源实际上被分配出去的这段时间。

可以探索RMiner去利用这段时间的资源。

举例，如图7所示，T0时刻R释放，成为了一种影子资源，CSV通过echo state更新给了RMiner，RMiner在T1时刻将任务放置到了这部分资源上（注意这时候不需要更新CSV），T2时刻进行了CSV更新，注意这时候调度器也认为原本被分配的影子资源也还是可以利用的，在T3时刻，调度器进行了一次普通的任务分配，没有冲突，但是在T4时刻，调度器将任务发送给了影子资源，这时候和影子资源的分配产生了冲突。其中T2~T4这段时间就是影子资源的等待延迟。

问题： 为什么不告诉CSV这部分资源已经被分配了？这样就可以避免后续的冲突了。

对影子资源的高利用率和低冲突率的权衡，所导致的对等待延迟时刻的影子资源的利用方式，使得本文提出了两种资源挖掘模式：

SafeRM Mode

RMiner只在影子资源的存在时间对其进行利用，而不再等待延迟时间内对其进行利用，以最大程度避免冲突。在SafeRM模式下，RM Filter会优先考虑任务运行时间短的任务。RM调度器主要将短任务给小的影子资源。

当然由于RM任务的工作时长难以确定，所以RM任务也可能会超过影子资源存活时间，这是会尝试先迁移，如果不行再杀死。

SmartRM Mode.

在影子资源的存在时间和等待延迟时间内对其进行利用，以最大程度提高资源利用率。在SmartRM模式下，RM Filter首先考虑任务的资源需求和驱逐成本，并优先考虑低优先的任务。RM调度器主要讲资源需求大的任务分配给尽量多空闲资源的合适的影子资源。

当冲突发生时，RM调度器会先杀死低优先级的RM任务，然后再尝试为其迁移。

实验

实验时，在谷歌集群模拟系统上添加了RM相关的组件。实验任务为2k+。模拟的节点为1500个同构节点，每个节点64个CPU，16个内存。

实验的任务主要来自阿里巴巴集群数据集。更新延迟为0.5s，调度器调度速率为每秒1000个任务，调度器数量分别设置为8和16，任务平均执行时间为5s，指数分布，平均一个作业包含12个任务，任务达到速率有1.43和0.7，前者在300秒内生成了200多个作业，即约2400个任务。

实验主要想回答3个问题：

1. RMiner 能为共享状态架构带来哪些性能提升？
2. 在当前的共享状态调度器中采用RMiner的成本是多少？
3. 引入的优化如何有助于性能改进？

资源利用率

图是真好看啊！

条形图表示 CPU 利用率的改进。显然，RMiner 通过挖掘影子资源来提高集群 CPU 利用率。不同场景下，影子资源占用集群资源的1.5%~5.0%。通过利用资源等待延迟方面的资源，SafeRM 的性能优于 NoRM 1.5% 至 4%，SmartRM 的性能优于 NoRM 1.6% 至 5.8%。

更具体地说，RMiner 在 8 个调度程序场景（平均利用率为 36.9%）下比在 16 个调度程序（平均利用率为 71.8%）下工作得更好，因为更少的调度程序可以更容易地为影子资源找到合适的 RM 任务（因为资源利用率低） 。此外，RMiner 在较高的任务提交率（2 倍）下表现更好，因为更多的任务提供了更多可供利用的已释放资源。

我们还将每个设置下的影子资源利用率报告为标记线。通过记录总体影子资源和分配的影子资源，SafeRM 使用了 26% 到 82% 的影子资源，SmartRM 使用了 58% 到 112% 的影子资源。 SafeRM 更加保守，仅限制影子资源生存时间的任务，而 SmartRM 则更加激进，在资源等待延迟中利用影子资源，甚至超过了不可见影子资源的上限。

任务吞吐量

图 10 (a) 显示了阿里巴巴跟踪的改进，其中 SafeRM 比 NoRM 实现了高达 10% 的吞吐量提升，SmartRM 实现了高达 28% 的吞吐量提升在高工作负载（任务提交率）下，RMiner 比低工作负载表现更好，因为更多已完成的任务产生更多的影子资源。

此外，我们在图 10(b) 中比较了 Google 跟踪上三种方案的吞吐量。结果表明，SafeRM 实现了 2% 到 9% 的改进，SmartRM 实现了 10% 到 28% 的改进，这与阿里巴巴的结果类似，进一步验证了 RMiner 的性能。

任务等待延迟

我们在图 11 中展示了作业等待时间的结果。它表明 RMiner 在较低工作负载下的表现与 NoRM 类似，因为在这种情况下任务不需要在队列中等待。然而，在更高的工作负载（1.75x和2x）下，并行提交的任务更多，普通调度器几乎已经达到了调度能力。 RMiner 的表现非常出色，因为它利用了更多短期任务来减少整体排队延迟。 RMiner 在 8 个调度程序下将作业等待时间缩短高达 25.4%，在 16 个调度程序下将作业等待时间缩短高达 10.4%。更多的调度器减少了并发调度任务的压力，但会导致更多的调度冲突。此外，我们进一步在 Google 的跟踪上验证了改进，发现 RMiner 在 8 个调度器下实现了 59.9% 的改进，在 16 个调度器下实现了 24.9% 的改进。

任务冲突

我们记录了 16 个调度程序设置的不同工作负载级别下的冲突。图 12 报告了性能改进和引发的冲突之间的关系。图 12（a）显示了基线和 SafeRM 之间的比较，这表明 SafeRM 在最坏情况下导致冲突增加不到 3%，从而将资源利用率和任务吞吐量提高了 4%。平均而言，与当前的共享状态调度程序相比，SafeRM 造成的冲突多了 0.5%，这与性能收益相比是可以接受的。

此外，我们在图 14 (b) 中报告了 SmartRM 的结果。同样，SmartRM 在最坏的情况下会导致冲突增加 3%，资源利用率提高 6%，吞吐量提高 13%。 SmartRM 的平均冲突成本为 0.73%，由于挖矿策略更加激进，比 SafeRM 略高。我们还发现，在较高工作负载下，冲突成本更加严重，因为更多并发任务提交使 SmartRM 更容易与正常调度程序发生冲突。综上所述，从工作冲突的角度来看，成本与绩效的提升相比可以忽略不计。

总体分析

RMiner 的额外开销也是回答问题 3 的一个重要方面。不幸的是，工业模拟器没有对调度开销进行建模，因此我们进行了全面的理论分析。 RMiner的开销包括影子资源管理开销和RM调度开销。影子资源管理器占用额外的内存空间来存储和更新影子资源状态索引，大约是CSV空间的3%-12.5%。在较高工作负载下，管理算法的频率很频繁，但通过哈希映射，操作的复杂度为 O(1)，从而导致可接受的计算开销。总体而言，影子资源的管理所产生的开销可以忽略不计。

至于额外的调度开销，当前的共享状态调度器设计配备了数十个具有全局状态视图的并行分布式调度器。 RMiner 增加了一个 RM 调度器，大大增强了当前设计的可见性，并且 RM 调度器的调度成本比传统的并行调度器要低，因为调度范围和实体都比以前更小。因此，RMiner 的调度开销比当前共享状态设计大约增加了个位数。总体而言，与集群性能的显着提升相比，在当前共享状态调度器中采用 RMiner 的成本可以忽略不计。

RM模式对比

实验中，SafeRM保留更新延迟的过滤阈值以保证最小化冲突。 SmartRM的默认阈值也是更新延迟，我们将过滤器阈值调整为2x更新延迟和4x更新延迟来比较性能。前者发生冲突的可能性较低，被定义为保守派SmartRM（SmartRM-C）。相反，后者被定义为激进的SmartRM（SmartRM-A）。此外，我们改变了 0.5 秒的默认更新延迟来调查对结果的影响。实验在 1x 工作负载级别和 16 个并行调度器下进行。

查看图13，与直觉相反，将更多任务过滤到 RMiner (SmartRM-A) 会提高资源利用率，同时降低任务吞吐量。这是因为此设置留给普通调度程序的短期任务较少，而普通调度程序往往会将重量级任务调度到集群，集群会同时占用更多资源，但总共完成的任务较少。因此，我们需要仔细控制过滤原则，以避免 RMiner 中的过度过滤和欠过滤任务。更新延迟也会影响 RMiner 的性能。更新延迟越大，资源浪费越大，导致任务吞吐量和资源利用率降低。在较高的更新延迟下，SmartRM-A 在利用率方面的表现比在较低情况下更差，因为 RMiner 的改进被正常调度程序的退化所掩盖，但它在利用率方面的表现几乎相同，因为在这种情况下执行了更多的重量级任务。

此外，我们在图 14 中报告了冲突的详细信息。我们记录了由于冲突而终止的任务，并将数量标准化为 RM 任务。该指标的值越低意味着与正常调度发生冲突的 RM 任务就越少。显然，SafeRM 很少与正常调度发生冲突。对于SmartRM来说，过滤器阈值越高，杀死RM任务的比例就越高，导致与并行调度器的冲突更多。性能改进和冲突成本之间存在权衡，权衡的两侧代表了RMiner的不同设计目标：最高的性能改进或对正常系统的最低侵入。总体而言，不同的RMiner以可接受的成本实现了相当大的性能提升，并且可以针对不同的目标进行灵活配置。