文章初步解决了long-running任务在HVM上的运行问题。通过对Harvest VM的特征分析发现，虽然HVM的资源空间和时间多样性很大，但是资源inter-change时间分布在一段时间内是相对稳定的。因此，即使不知道资源变化的确切时间，但变化之间的时间分布是已知的。主要包括以下几个核心设计点：预测资源变少的概率；将长任务与更稳定的HVM相匹配、将短任务与不稳定的HVM相匹配；维护一个相对稳定的HVM池。

文章对一个Microsoft的Harvest VM进行了特征分析，discover large spatial vairations in their stability and resources。文章通过预测哪些HVMs将足够稳定，可以在没有抢占的情况下运行任务，来利用这种多样性。

Introduction

Harvest VM是与其他常规（按需、高优先级）虚拟机共处的可变大小的虚拟机。当一个新的常规虚拟机被分配到服务器上时，HVM的容量就会缩小，而当一个常规虚拟机结束时，它就会增加。

Large harvested capacity克服了主要的capacity瓶颈，让金融、科学、地理、能源和气象部门的许多大规模应用能够在云中经济地运行。然而，由于抢占，HVM的资源变化会大大减慢这些长时间、不能间断的应用执行。

之前的努力试图用调度、资源获取和负载平衡技术来掩盖这种开销，但是这些技术不适合长时间、不能间断的应用。它们经常使用检查指向、迁移、复制或应用程序级别变化的组合。

Characterization & Motivation

Harvest VMs

主要回答以下几个问题：

HVMs的稳定性：HVMs变化的频率和程度如何？
- Size of CMT core changes：不同集群的平均变化幅度在大约5到13个SMT核心（同时多线程核心或硬件线程）之间。考虑到HVM的典型最小规模为2-8个SMT核心，并且考虑到1-2个核心是流行的常规VM规模，这些都是很大的变化。这样大的变化可能对应用产生重大的性能影响（包括正面和负面）。
- Frequency of changes：变化间时间具有高变异性和长尾。对于较高的活动群组（C1-C6），我们看到93-72%的变化在一小时之内，平均变化时间为26-224分钟，第95百分位数为1.2-11.2小时。对于较低的活动群组（C7-C8），我们看到61-55%的变化在一小时内，平均8-10小时，第95百分位数为几天。
HVMs的空间和时间多样性：How do different HVMs compare and how do they change over time?
- 对于每个HVM，在每个1小时的时间窗口，我们测量收获的内核（1小时内的时间平均值）和稳定性（变化的数量）
- 最差的10%的HVMs可以在一小时内见证几十次变化，而相对稳定的 50%的HVMs在一小时内最多出现一次变化。
- 一个特定的HVM的稳定性和资源也会随着时间的推移而变化
工作负载的影响：长期的、不间断的工作负载的运行时间与HVMs的资源变化是如何比较的？
- 主要内容在下一节

Target Workloads

这一节研究了一个主要云供应商的两个大规模生产应用： (1)一个在石油和天然气领域的应用，执行地震成像模拟，和(2)一个基因组学应用，分析遗传物质以确定各种属性（例如，人类的疾病敏感性和植物的物理特征）。

结果表明，任务运行时间的范围和HVM inter-change时间的范围有相当大的重叠。这意味着这些工作负载中的任务在典型的Harvest虚拟机上执行期间可能会目睹一些资源变化事件。（也就是可能收到资源变化事件的影响）

Figure 5的实验证明了这一点

Opportunities for Improvement

为了提高我们在HVMs上的目标工作负载的效率，论文提出了以下observation：

任务运行时间（在一个作业内或跨作业）和HVM的inter-change时间都有很大的差异，而且它们的范围有很大的重叠。这就提供了一个机会，将长任务与更稳定的HVM相匹配，将短任务与不稳定的HVM相匹配，从而通过最大限度地减少抢占和降低成本来有效利用HVM。
有些HVM比其他的更稳定，而且HVM的稳定性会随着时间的推移而改变。通过获取和保留更多即时稳定的HVM，有机会改善工作负载的执行时间。

Design

图6显示了SLACKSCHED的架构和三个主要实体的协调（以紫色显示）。

per-node的节点管理器，在集群中的每个节点上运行，负责报告节点的健康状况和在节点上运行任务。在HVM的情况下，它也负责传达HVM上的即时资源可用性。
per-job的作业管理器，负责管理单个作业中的任务进度。
一个集群范围内的资源管理器（RM），接收来自作业管理器的资源请求，安排和映射这些请求到节点，并将资源分配传达给作业管理器。然后，工作管理员根据分配的资源在节点上启动容器化程序。

SLACKSCHED由两个关键组件组成（以蓝色显示）：Scheduler和Acquirer。 Scheduler扩展了默认的协调器调度器，并利用任务运行时间的多样性和HVM资源的变化来匹配任务和HVM。 Acquirer与Provider和资源管理器互动，以获取和维护一组低成本的HVM，收获更多的资源，并对工作负载足够稳定。

Scheduler

主要分成两个部分：预测引擎，预测每个HVM在未来的稳定性；匹配器，根据任务持续时间和HVM的稳定性将任务与HVM匹配。

Prediction Engine

文章没有进行point estimation，而是采取了另一种基于分布的预测和条件概率的方法。与之前的工作类似，文章以inter-change时间分布为条件来估计特定HVM的下一次变更前的剩余时间。文章发现，inter-change时间分布在一段时间内是相对稳定的。因此，即使不知道资源变化的确切时间，但变化之间的时间分布是已知的。

Workflow。对过去D天（文章中D=1）的inter-change事件分布进行滚动snapshot，以估计completion probability。并且将一个任务和HVM的完成概率近似为HVM在给定任务的生命周期内不会缩减的概率。（为什么是近似：因为实际上即使HVM的资源缩减，任务仍然可能完成）

分两步来计算完成概率。首先，我们估计在某一特定HVM上的任务有效期内发生资源变化事件的可能性。其次，我们估计这个资源变化事件是一个收缩事件的可能性。

Match Maker

给了Completion probability计算的公式，并不复杂。

延迟调度。 在某些情况下，等待一个更稳定的节点（即具有更好的完成概率）可能是一个更好的选择，而不是从当前可用的资源中挑选。在不了解未来的情况下，决定是等待还是用当前的最佳资源运行是很有挑战性的。我们可以实现一个简单的方法，只有当HVM提供了一个阈值的完成概率时，才在它上面启动任务。然而，这可能会导致调度器无限期地延迟。为了解决这个问题，我们通过估计从各种决策选择中得到的预期完成时间来形成等待的成本和收益。

Workflow。 Match Maker使用等式2将任务安排在给出最佳预期完成时间的节点上。如果这个节点目前没有资源，那么它就等待，并在下一次调度迭代时重新考虑这个决定。

Acquirer

理想情况下，我们希望维护一组HVM，其稳定性与任务的运行时间相匹配。然而，除了任务运行时间信息外，这还需要对以下方面有充分的了解： (1)未分配的资源如何分布在数据中心的服务器上，以及(2)这些资源在任何时间点的稳定性如何。作为一个用户（或集群协调者），这些信息是不可用的，也不可能建模。即使作为提供者，这些指标也只是即时可用，而HVM模式可能会随着时间的推移而改变（图3）。

解决方法是采用“exploration-exploitation”。 Acquirer从一个随机的HVM组合开始，定期识别最差的HVM并将其淘汰，逐渐形成一个更稳定的HVM池。 Acquirer将"最差"定义为最近改变的HVMs。当HVM池相对于provider可以返回的HVM来说不稳定时，这个简单的策略是有效的。

在文章的实现中，Acquirer每小时运行一次，并处理10%的分配的HVMs。同时，它向供应商请求同等数量的新的HVM，以保持相同数量的集群资源。