ACM通信
实践
实践研究:数据中心的集群调度
信贷:Aha-Soft
这一期的实践研究的特色是由Malte Schwarzkopf策划的精选，他带我们参观了分布式集群调度，从研究到实践，然后再回来。随着弹性计算资源的兴起，集群管理已经成为系统研发中的一个越来越热门的话题，包括Kubernetes、Mesos和Docker在内的许多竞争集群管理器目前都在争夺这个领域的王冠。对这些系统背后的基础感兴趣，以及如何实现快速、灵活和公平的调度?马特帮你搞定了!
彼得百利
越来越多的应用程序和网站依赖于运行在云数据中心的分布式后端。在这些数据中心中，由数百或数千台计算机组成的集群运行从容错、负载平衡的Web服务器到批处理数据处理管道和分布式存储堆栈等工作负载。
一个集群管理器是一种特殊的“编配”软件，可以自动管理数据中心中的机器和应用程序:一些广为人知的例子是Kubernetes、Mesos和Docker Swarm。为什么需要集群管理器?最明显的原因是，管理如此规模的系统超出了人类管理员的能力。然而，同样重要的是，自动化和智能资源管理可以节省真正的钱。这在大规模上是正确的，谷歌估计它的集群管理软件帮助避免了数十亿美元的数据中心建设，在初创公司的云部署规模上也是如此，每个月在未充分利用的虚拟机上浪费数百美元可能会浪费宝贵的资源。
由于很少有学术研究人员能够接触到真实的、大规模的部署，关于集群管理的学术论文主要集中在调度在资源有限的情况下，有效地处理工作负载，而不是处理更多操作方面的问题。调度是一个有许多可能答案的优化问题，它们的相对优劣取决于工作量和操作员的目标。然而，考虑调度问题的解决方案也引发了关于正确架构的激烈辩论可伸缩的用于越来越大的集群和越来越高要求的工作负载的调度器。
让我们先看一篇文章，它很好地总结了成熟的行业集群管理器的许多方面，然后深入讨论调度程序体系结构。
谷歌的“秘密武器”
Verma, A.等人。
在谷歌上使用Borg进行大规模集群管理。在第十届欧洲计算机系统会议论文集2015年,18:118:17;http://dl.acm.org/citation.cfm?id=2741964．
对于想要了解如何开发一个成熟的集群管理器并有效地部署它的人来说，本文是必读的。Borg处理集群编排的所有方面:它监视机器的运行状况，重新启动失败的作业，部署二进制文件和秘密文件，超额订阅仅够维护关键SLOs(服务级别目标)的资源，同时也很少留下空闲资源。
为了实现这一目标，博格人的开发者必须做出许多决定:从选择隔离模型(谷歌使用容器)，到如何将包分发到计算机(通过类似于torrent的分发树)，任务和作业如何找到彼此(使用类似于dns的自定义命名系统)，低优先级和高优先级工作负载为何以及如何共享相同的底层硬件(巧妙的超额订阅、优先级抢占和配额系统的组合)，甚至如何处理Borgmaster控制器组件的故障(基于paxos的故障转移到新的leader副本)。这里有很多巧妙的技巧(例如，§5.5中对任务实际资源需求的自动估计)，以及大量的操作经验和合理的分布式系统设计。
一个相关的队列文章描述了Borg和Omega(也是在谷歌开发的)是如何影响Kubernetes的，Kubernetes是一个开源集群管理器，其开发灵感来源于Borg。Kubernetes提供的功能目前比Borg的要有限得多，但Kubernetes在每一个版本中都能迎头赶上。
实际的调度机器的工作原理只包含了博格论文(§3.2)的一个小节，但它既具有挑战性又至关重要。许多独立的论文都是专门针对这个调度问题写的，通常提出的改进方案似乎也适用于Borg。不幸的是，它们有时非常令人困惑:有些描述的调度器在比Borg更高的级别上运行，或者为不同于谷歌的长时间服务作业和有限运行时批处理作业组合的工作负载设计的调度器。幸运的是，下一篇文章将描述一种分离这些关注点的简洁方法。
许多调度程序:提供还是请求?
Hindman, b等。
Mesos:数据中心中用于细粒度资源共享的平台。在网络系统设计与实现Usenix会议论文集、2011、295308;http://static.usenix.org/events/nsdi11/tech/full_papers/Hindman_new.pdf．
Mesos是第一本关于现代集群管理和调度的学术出版物。该实现是开源的，出现在Borg在谷歌之外还不为人知的时候。Mesos的作者有一个关键的见解，在许多不同的工作负载和框架(例如Hadoop、Spark和TensorFlow)之间动态地共享底层集群对实现高资源利用率至关重要，这一点后来在Borg的论文中得到了重申。
对于如何调度独立的工作单元(任务)，不同的框架通常有不同的想法;事实上，Mesos最初瞄准的框架已经有了自己的调度程序。为了在这些框架之间仲裁资源，而不将它们强制置于单一调度策略的束缚中，Mesos巧妙地分离了两个关注点:一个较低的层次资源管理器将资源分配给框架(例如，受公平约束的框架)和更高级别的框架框架调度器选择在哪里运行特定的任务(例如，尊重数据位置首选项)。这种设计的一个重要结果是Mesos可以支持长时间运行的服务任务，就像支持短的、高吞吐量的批处理任务一样——它们只是由不同的框架处理。
Mesos避免了框架使用复杂的API来指定它们的资源需求。通过反转框架和资源管理器之间的交互:而不是框架请求resources, Mesos资源管理器提供了资源依次转移到框架。每个框架都有自己的选择，资源管理器随后将剩余的资源提供给下一个框架。使用适当大小的报价，Mesos还可以跨框架执行公平政策，尽管这方面在实践中可能没有最初预期的那么重要。
调度是一个有许多可能答案的优化问题，它们的相对优劣取决于工作量和操作员的目标。
Mesos提供机制有些争议:谷歌的Omega论文观察到，Mesos必须向每个框架提供所有集群资源，以暴露现有状态的全部知识(包括，例如，抢占任务)，但在缺乏乐观的并行提供和冲突解决机制的情况下，缓慢的框架调度器可能会对其他框架和整体集群利用产生不利影响。作为回应，Mesos开发人员为这种Mesos扩展设计了概念。
Mesos引入的多调度程序设计非常有影响力:许多其他集群管理器已经采用了类似的体系结构，尽管它们要么使用请求驱动的分配(例如Hadoop YARN)，要么使用omega风格的共享状态体系结构(例如Microsoft的Apollo和HashiCorp的Nomad)。
提供驱动设计的另一个刻意的结果是Mesos资源管理器相当简单，这有利于其可伸缩性。接下来的两篇文章将更深入地研究这个问题:第一篇文章提出了一种更简单的设计，以获得更大的可伸缩性，第二篇文章认为扩展复杂的调度程序比人们普遍认为的更可行。
- http://mesos.apache.org/
- https://dl.acm.org/citation.cfm?id=2465386
- https://dl.acm.org/citation.cfm?id=2523633
- http://bit.ly/2sqMUmP
- https://www.nomadproject.io/
进一步分离调度程序
Ousterhout, k等人。
Sparrow:分布式、低延迟调度。在操作系统原理研讨会论文集、2013、6984;http://dl.acm.org/citation.cfm?id=2522716．
即使在Mesos认为的框架级任务中，也可能存在另一个级别的调度。具体来说，一些数据分析系统将其处理分解为许多短的工作单元:例如，Spark生成应用程序级的任务，通常只运行几百毫秒(注意，这些与集群级别Borg或Mesos框架放置的任务!)使用这样短的任务有很多好处:它隐式地平衡了处理它们的worker之间的负载;失败的任务只会损失少量的状态;而那些运行时间比其他任务长得多的零散任务的绝对影响更小。
然而，较短的任务会给放置它们的调度器施加较高的负载。在实践中，这通常是框架级别的调度器，或者是作业本身中的调度器(如在独立的Spark中)。对于数以万计的任务，这个调度器可能会不堪重负:它可能根本无法支持所需的决策吞吐量。实际上，这篇论文表明，每个Spark作业中的集中式应用程序级任务调度器每秒只能扩展到大约1500个任务。因此，在单个调度器上排队分配任务会增加它们的整体“最大完成时间”(任务提交和完成之间的时间)。在等待超负荷的调度器分配新任务时，它还会使资源处于空闲状态。
Sparrow以一种激进的方式解决了这个问题:它在每个worker上构建任务队列，并将调度器分解为几个分布式调度器，这些调度器独立地填充这些worker端队列。利用“两个随机选择的力量”属性，即(在某些假设下)轮询两个随机队列就足以实现良好的负载平衡，然后Sparrow将任务随机地分配给工人。这既不需要调度器上的状态，也不需要调度器之间的通信，因此只需添加更多的调度器就可以很好地扩展。
本文包括几个重要的细节，使随机放置方法具有实用性，并使其接近于全知调度程序为完美平衡队列长度所做的选择。例如，Sparrow将给定的任务放入多个队列中，将其押注分散到多个worker中，并平滑来自其他分散任务的一线阻塞。它还可以处理职位限制，并提供共享相同员工的多个工作的加权公平分成。
麻雀在原则上可以用作集群级别的调度器，但在实践中，当它在单个框架的长时间运行的工作者(例如，用于查询或运行分析作业)上对应用程序级别的任务进行负载平衡时，工作效果最好。在集群调度器级别，任务启动开销通常使持续时间低于几十秒的任务不切实际，因为包分发、容器启动等任务已经花费了几秒。因此，开源的Sparrow实现提供了一个Spark应用程序级调度器插件。
最后，尽管Sparrow的随机分布式决策是可伸缩的，但他们假设任务在固定大小的资源槽内运行，而长度相等的队列也构成了同样好的选择。后续的几篇论文在保持相同的分布式体系结构以实现可伸缩性和容错性的同时，在这些维度上进行了更多的改进。然而，有一篇论文研究了扩展性是否真的需要sparrow风格的广泛分布。
我们能拥有质量和速度吗?
高格，我，等人。
苍穹:大规模快速、集中的集群调度。在操作系统设计与实现Usenix会议论文集、2016、99115;https://www.usenix.org/system/files/conference/osdi16/osdi16-gog.pdf．
分布式决策提高了可伸缩性和容错性，但是调度器必须在存在关于集群状态的简化(且仅统计抽样)信息的情况下进行决策。按照约定，在同一地点做出所有决策的集中调度程序拥有应用更复杂算法的信息，例如，避免机器过载。当然，这适用于集群级别和应用程序级别的调度器。
这篇论文开始研究容错好处对可伸缩性是否确实是必要的。它指出，在许多任务上摊销决策成本是至关重要的，特别是如果调度器支持需要重新考虑现有位置的特性，例如任务抢占。可以这样考虑:如果调度器从队列中选择一个任务，查看一大堆机器，并进行一些复杂的计算，只是为了决定将这个任务放在哪里，那么它不能很好地扩展到许多任务。
Firmament推广了Quincy调度器，这是一个很酷但有时会被忽视的系统，它使用最小成本、最大流量约束求解器来调度批处理工作负载。约束求解器总是调度整个集群工作负载，而不仅仅是等待任务。因为最小成本、最大流量求解器是高度优化的，它们的算法很好地摊销了许多任务的工作。
然而，如果天真地应用昆西方法，就无法扩展到数千台机器上的大型工作负载——支配调度延迟的约束求解器运行时将长得不可接受。为了解决这个问题，Firmament同时运行几种具有不同属性的最小成本、最大流量算法，解决了优化问题增量如果可能，改进以前的解决方案，而不是重新开始。
通过一些额外的技巧，即使在调度一个运行数十万个任务的google规模的集群时，苍穹也能实现亚秒级的决策时间。这使得麻雀样式的应用程序级任务可以在几百毫秒内集中部署到数千台机器上。本文还表明，分布式集群级调度器不存在可伸缩性驱动的需求，因为Firmament运行250倍加速的谷歌集群跟踪，中间任务运行时间仅为4秒，同时在常见情况下仍然做出亚秒级决策。模拟器和Firmament本身都是开源的，并且有一个插件允许Kubernetes使用Firmament作为调度程序。
Firmament论文建议，我们不需要在决策质量上妥协来解决集群调度中的可伸缩性问题。尽管如此，Sparrow风格的分布式调度器还是很有用的:例如，服务于一组功能相同的固定工作人员的容错应用程序级负载平衡器可能很希望使用Sparrow的体系结构。
- https://dl.acm.org/citation.cfm?id=1629601
- https://github.com/camsas/firmament
- https://github.com/camsas/poseidon
研究实践
这一切对你这个读者来说意味着什么?首先，您几乎肯定每天都在使用在Borg和其他集群管理器上运行的应用程序。此外，如果您正在运行一个计算大数据或运行web应用程序的业务(或者，特别是两者都是!)，您可能需要集群管理器的自动化。许多公司已经这样做了，并在云上发放的虚拟机集群或在他们自己的机器上运行他们自己的Mesos或Kubernetes安装。
然而，将集群管理器及其调度程序扩展到非常大的集群的问题是大多数读者不必面对的:只有几十家公司运行这样大的集群，在AWS (Amazon Web Services)或谷歌或微软的云上购买资源是最简单的扩展方法。在某些情况下，调度器可伸缩性在较小的集群中也会成为一个问题，但是:如果您正在运行具有短任务的交互式分析工作负载，可伸缩的调度器可能会为您提供更好的资源利用率。
调度问题的另一个重要方面是，集群工作负载非常多样化，实际的调度策略通常需要使用位置约束进行大量手工调优。实际上，这就是集群调度与内核的多处理器调度不同之处:虽然大多数应用程序都可以使用内核应用的通用策略将进程分配给内核，但如果没有手动操作人员的帮助，当前的集群级放置策略通常不能很好地适用于所有工作负载混合。
未来的发展方向
由于对人类来说，开发适合所有(甚至大多数)工作负载的调度策略和良好的位置启发式是一项挑战，因此对在特定设置中有帮助的策略的研究肯定会继续下去。
然而，另一种方法可能也是可行的。最近的早期结果表明，丰富的度量数据和集群调度决策的反馈循环非常适合现代机器学习技术:它们允许训练神经网络自动学习定制的启发式，以适应工作负载。例如，强化学习可以有效地学习包装算法，这些算法可以匹配或优于现有的人工指定的启发式算法，而神经网络在TensorFlow的应用程序级操作员调度中优于人工计划器。
因此，未来的研究可能会进一步提高集群管理的自动化水平:也许有一天集群调度器将学会自己的算法。
数字图书馆是由计算机协会出版的。版权所有©2018 ACM, Inc.
没有发现记录