《看论文》是分析计算机与软件工程领域论文的系列文章。在本系列的每篇文章中，我们都会阅读一篇来自OSDI、SOSP等顶级会议的文章。论文，这里不会详细介绍所有的细节，但是会筛选出论文的重点内容，如果你对相关论文非常感兴趣，可以直接点击链接阅读原文。本文是关于2011年NSDI期刊论文-Mesos:APlatformforFine-GrainedResourceSharingintheDataCenter[^1]，它实现了Mesos来管理集群中的不同计算框架，例如Hadoop和MPI等。虽然Mesos集群管理系统是10多年前发布的技术，如今已经逐渐被更主流更通用的容器编排系统Kubernetes所取代，但它确实可以解决集群管理中的一些问题。ApacheMesos和Kubernetes都是优秀的开源框架，都支持大规模集群管理，但是它们管理的集群规模还是相差一个数量级。单个Mesos集群可以管理50,000个节点，而Kubernetes集群只能管理5,000个节点，需要许多优化和约束才能达到相同的数量级。图1——Kubernetes和Mesos集群虽然Kubernetes是当今集群管理的主流技术，但Mesos刚出现时也是一个非常先进的集群管理系统。它想取代当时更常见的静态分片集群。虽然静态分片集群可以同时运行属于不同框架（如Hadoop、MPI）的工作负载，但是由于框架的异构性，使用静态分片技术会将集群中的机器预先分配给不同的框架，然后再由这些框架分配和管理资源。图2-StaticshardingMesos在最初设计时并没有直接对开发者提交的工作负载进行管理和调度，而是提供了一套接口来暴露集群资源，并通过这套轻量级接口同时连接Hadoop和MPI接口和其他框架。架构如下图所示，Mesos集群同时运行Hadoop和Mesos框架。如果忽略图中与Hadoop和MPI框架相关的模块，我们会发现架构会变得非常简单。它仅由Zookeeper集群、Mesos主节点和工作节点组成。图3-Mesos架构图Zookeeper集群提供高可用的数据存储和选举功能；Mesos主节点收集工作节点上报的数据，为框架调度器提供资源；在本地启动任务；每个Mesos集群中运行的框架由一个调度器和一个执行器组成。调度器将处理主节点提供的资源，其功能与Kubernetes调度器相同。当调度器接受主节点提供的资源后，会返回待运行任务的信息；执行器将在工作节点上运行框架创建的任务。为了保证更好的可扩展性，Mesos定义了一套能够满足资源共享的最小接口。任务调度和执行的控制权通过下图接口交给了框架。它只保留了粗粒度的调度和资源管理功能。图4-Mesos界面由于Mesos中的任务调度是一个分布式过程，为了保证过程的高效性和可靠性，它引入了以下三种机制：节点过滤器：该框架使用过滤器来消除集群中未使用的节点。满足自身调度条件的节点；主动分配资源：为了提高框架的调度速度，提前提供给框架的资源将计入框架的总分配资源中，直到框架完成调度，可以鼓励框架执行一个更快的调度程序；资源撤回：如果框架在一段时间内没有处理主节点提供的资源，Mesos会撤回资源，提供给其他框架；除了提供良好的可扩展性和性能，作为集群调度管理系统，Mesos还面临着隔离。任务资源问题。在Mesos刚刚发布的时候，容器技术还没有今天这么流行，但它也是利用操作系统的容器来隔离不同工作负载的影响[^2]，并使用可插拔的隔离模块来支持多种隔离机制。调度模型我们在文章开头已经介绍过，Mesos和Kubernetes能够管理的集群规模存在一个数量级的差异。这里简单对比分析一下两者在scheduler上的区别，可以帮助我们理解Kubernetesscheduler的设计。决策，以及这些决策如何影响其可扩展性。需要注意的是，提高系统的可扩展性往往是一个复杂的问题，在像Kubernetes这样庞大的系统中会更加复杂。Kubernetes调度程序并不是影响其可扩展性的唯一因素。如果要提高单个集群的性能Scale应该从多方面入手。Mesos调度器选择两层调度设计，顶层调度器只根据底层框架调度器的需要粗略过滤集群中的节点，而框架调度器进行真正的任务调度，将任务绑定到对应的节点。图5-两层调度器这种两层调度器设计看起来很复杂，但它实际上降低了Mesos调度器的复杂性并提高了它的可扩展性：降低复杂性：顶层调度器不需要处理真正的调度过程，它只通过ResourceOffer机制将一组节点交给底层调度器；提高可扩展性：两层调度器设计可以更方便的接入新框架调度器，兼容不同复杂的调度策略，不同框架的调度器可以选择节点串联任务，提高整体调度的吞吐量；尽管Mesos通过两层调度器设计提供了强大的可扩展性，但它无法提供调度决策提供全局最优解。这是因为所有的调度决策都是在整个集群的一部分节点上做出的，所有的调度决策都只是局部最优的，这也是多调度器中的一个普遍问题[^3]。在调度系统中，要想实现更好的扩展性，就必须面对碎片化。碎片化必然使调度器无法提供全局最优解，显着增加系统的复杂度。我们可以从Linux和Go语言等CPU调度器的演进中观察到这一点。大多数初始调度程序都是单线程的。为了提高调度器的性能，将使用多个调度器并引入工作窃取机制来处理多个调度。服务器中要调度的任务队列不平衡。Kubernetesv1.21内置的调度器仍然是单线程的。为了在5000个全局节点中做出最优的调度决策，它需要使用不同的插件对5000个节点进行遍历和排序，这也影响了它的扩展性。性的重要原因之一。全局最优解听起来是个很漂亮的设计，但是在调度等更复杂的场景下，局部最优解往往可以满足要求。当业务不需要保证这个约束时，可以通过多个调度器来实现。以提高性能。总结在比较Mesos和静态分片集群的资源利用率时，我们会发现Mesos的CPU和内存集群资源利用率明显高于使用静态分片的集群，这个结果不会造成太多意外，因为动态资源分配策略通常可以提高集群的资源利用率。图6-Mesos和静态集群的资源利用率比较了解Mesos出现时解决的问题及其设计可以让我们更好地理解我们今天面临的挑战。在产品上，它确实提供了很强的灵活性，但是随着Yarn、Kubernetes等技术的出现，它的很多场景已经被新技术所取代，这也是技术发展的必然趋势。[^1]：BenjaminHindman、AndyKonwinski、MateiZaharia、AliGhodsi、AnthonyD.Joseph、RandyKatz、ScottShenker和IonStoica。2011.Mesos：数据中心细粒度资源共享平台。在第8届USENIX网络系统设计与实现会议论文集(NSDI'11)中。USENIX协会，美国，295–308。[^2]：什么是LXC？https://linuxcontainers.org/lxc/introduction/[^3]：调度系统设计精要https://draveness.me/system-design-scheduler/本文转载自微信公众号》没有逻辑"，您可以通过以下二维码关注。转载本文请联系真诺逻辑公众号。
