资源管理与任务调度系统Mesos论文及架构详细解读

0. 前言

关于资源管理与任务调度系统出现的背景、发展历程及一些基础知识可以参考博客集群资源管理与任务调度系统综述
Mesos2007年诞生于UC Berkeley，并在Twitter和Airbnb公司中得到实践和巩固，其论文发表于2011年的NSDI，目标是构建一个数据中心可扩展的全局资源管理器。
论文原文：http://static.usenix.org/events/nsdi11/tech/full_papers/Hindman_new.pdf

目前在资源管理与任务调度系统中，影响力比较大比较经典的几个系统分别是YARN、Mesos、Borg、Omeag、Apollo、Sparrow，Kubernetes。目前工业界中大部分集群资源管理和任务调度系统都吸纳了这些系统中的思想，并根据实际的业务场景进行改进，例如阿里伏羲调度系统可以看做是YARN的变体，腾讯云VSTation则吸纳了Omega中的思想。总的来看影响最大的系统当属YARN和Mesos，目前两者均已开源。Borg对调度系统的指导作用很大，但是目前是谷歌的闭源内部系统。Omega和Sparrow目前仅是学术研究并没有真正在线上实践。Apollo主要是微软针对短作业设计的一个调度系统，目前也闭源。Kubernetes主要对容器进行编排，开源。下面就针对Mesos的论文和一些实践来讨论其设计原理，下文思路主要按照论文中的思路进行。

1. Abstract & Introduction

Mesos是一个基于资源供应的两层调度器，通过一个细粒度的管理器为集群计算框架（Hadoop，MPI）分配资源，集群计算框架决定接受资源的量并将任务运行在其上。结果表明在不同集群架构中共享集群时可以扩展到50000个节点并对故障有弹性。
背景：

• 大背景。随着数据增长，集群成为主要的计算平台，随着业务场景的多元化，各种针对不同场景的计算框架相继出现例如：MR，Dryad，Pregel等；
• 小背景。新的计算框架会继续出现，没有一个通用的计算框架可以适配所有的应用程序。期望在同一个集群中运行多种计算框架以提升集群资源利用率以及共享访问大型数据集降低多个计算集群中数据重复而导致的代价；
• 目前解决方案缺点。 目前针对多计算框架的解决方案：静态划分集群和实用VM，这些方案的缺点在于不能实现高利用率且不能有效进行数据共享，根本原因在于这些方案的分配粒度和计算框架的分配粒度不匹配。例如：Hadoop框架中，一个job由很多task构成，一个task由很多instance构成，这些任务被分配到计算节点的slot中，任务的短暂性以及一个节点上能够运行多个任务的能力允许作业能够实现高的数据本地化；
• 面临挑战。Mesos想要实现高可扩展性和高效性面临以下挑战：（1）每个计算框架有自己的调度需求、编程模型、同行模型、任务依赖和数据存放；（2）调度系统必须能够支持上千个节点，支持上百万个任务运行；（3）Mesos是系统的中心，必须可容错和高可用；
• 可行解分析。对于Mesos来说一个可行的方案是实现一个中央调度器，输入框架要求、资源可用性和组织策略，然后对所有任务计算出一个全局调度。但是这样做存在一些挑战：（1）复杂性，系统需要提供一个丰富的API来支持不同的计算框架，并完成一个针对百万个任务的在线优化问题，会对扩展性和恢复能力造成消极影响；（2）新的计算框架不断出现，需要不断增加接口；（3）许多框架实现了自己的调度逻辑，将其移植到全局调度器中需要昂贵的重构过程；
• 所采用的方法。Mesos提出了一种新的方法，将具体的调度过程委派给计算框架，并抽象出一个资源供给层。Mesos按照一定的分配策略（DRF）决定分配多少资源给计算框架，计算框架决定接受哪些资源并运行任务。虽然该模型不能实现全局最优调度，但是在生产实践中运行的很好&