Borg/Mesos/Yarn三大主流资源管理与调度系统对比

转载来自于：Borg/Mesos/Yarn三大主流资源管理与调度系统对比

0. 前言

Mesos（Twitter）、YARN（apache）和Borg(google)三个资源管理与调度系统可以说是目前资源管理和调度系统的先导者，现有的大多数资源管理和调度系统都从这三个系统中吸纳设计思想。对这三个系统的对比总结有助于更好的了解目前资源管理与调度系统的状态和未来的发展趋势。

需要特别说明的是，borg系统所提出的思想直接影响了资源管理和调度系统的发展，例如其提出的在线任务和离线任务混合部署的思路以及资源超售的思路领先行业十余年。直到今天一些业界的系统才开始在混部方面进行探索，而borg早在十多年前就已经提出并在内部系统中进行成熟使用。

对于这三个系统最早出现的应该是borg，其是谷歌内部的资源管理系统，但是一直没有对外公开，直到2015年才发表论文进行说明。接着是Mesos系统，发表于2012年左右，YARN系统发表于2013年，这三个系统无论是在架构设计还是针对的场景、实现思路上都存在较大的差异，下面将针对不同的维度进行阐述。

1. 架构方面

borg架构

Mesos架构

YARN架构

相同之处：三种架构都是基于master/slave架构进行设计的，master主要负责全局的资源分配，slave节点主要负责本节点的各项信息收集、汇报工作。但是具体的实现细节方面还有很大差别。
不同之处：

• 资源分配框架不同。borg针对task任务进行资源分配；mesos针对不同的计算框架进行资源分配；yarn针对具体的job进行资源分配；
• 资源分配策略不同。borg是基于请求方式进行资源分配的，task首先描述其需要的细粒度资源情况，然后由borg根据硬约束条件和基于打分的软约束条件为其分配资源；mesos是基于供应的资源分配方式，master向计算框架推送资源，计算框架决定是否接受资源；yarn是基于资源请求的分配方式，job描述资源需求，然后当集群中有空闲资源（NM发送心跳）时进行资源分配。
• 触发分配的条件不同。borg是为task匹配机器，会根据软硬约束筛选出一些机器供task选择；而mesos和yarn则是为机器匹配任务，当slave节点发送来心跳信息时，才去选择合适的框架或者任务进行分配。
• master的职责情况。borgmaster需要处理的任务最多，需要分配资源并进行不同模块之间的通信和状态维护，但是其中进行了并行设计的思想，对于调度模块存在多个调度器可以并发进行调度，master也有多个，这些备份的master在正常情况下也会参与到系统的工作中而不仅仅是状态维护，他们会与一部分的slave节点进行通信，然后将结果发送给主master节点。因此虽然master需要负责的任务较多，但是扩展性很强。而对于YARN来说其比Mesos的master要重一些，mesos只负载进行资源的分配，而计算框架内部的资源分配情况和任务运行情况其并不关系，但是对于yarn来说，其任务的划分粒度较大，其除了需要进行资源分配外还需要维护任务和container的状态信息。
• slave节点的汇报方式不同。borg采用poll的方式去拉取slave节点的信息，这里面有一个设计思想，在borg中因为需要通过打分的方式来选择合适的机器放置任务，但是对于大集群来说对所有机器打分的开销是很大的，所以其采用的方式一方面是缓存打分结果，另外就是先随机选择一部分机器进行筛选，只要筛选出足够的机器即可，这样就可以减少对机器进行打分操作，这样我们就不需要知道所有机器的资源情况，只需要按照实际需求获取相应机器的资源情况即可，这种方式采用poll的方式更合理。另外采用poll的方式可以避免在进行master选举的时候产生通信风暴。而对于mesos和YARN都是采用slave节点定期以心跳的方式进行汇报来统计资源信息的，这种方式会带来比较大的通信开销。
• 扩展性方面。borg因为采取多个调度器和多个master协同工作的方式，所以可扩展性高。而对于mesos和yarn来说，其master节点是瓶颈。
• 高可用方面。borg通过多副本维护的方式保证master节点高可用，mesos中通过zookeeper来保证master节点的高可用，YARN虽然也设计了使用zookeeper方式来保证高可用，但是目前版本的实现中还比较弱。

1. 批处理和长服务支持

borg系统可以很好的处理批处理和长服务，让两者在同一个集群中运行，真正达到资源共享的目的。其内部设计了针对批处理和长服务的不同处理机制来保证两种任务之间的运行质量。此外还采取了超售的机制来适时复用申请了但是没有被使用的资源。

mesos和YARN虽然也可以支持长服务，但是目前的版本下，长服务的引入会带来一系列的问题。目前使用mesos和yarn架构的公司一般会将在线集群和离线集群分开进行处理。引入的问题如下：

• 资源竞争和饿死的问题。如果系统中仅包含批处理任务，资源调度比较容易做，因为在系统中每时每刻都在进行着资源申请和释放，资源可以动态得到保证。但是长服务的出现则不同，现在的资源管理系统多是基于资源预留的，比如一个作业需要10G内存，目前没有任何节点存在10GB内存呢，为了避免永远拿不到资源，调度器会找一个存在部分资源的节点，比如node1存在6GB内存，则会为该作业预留着，一直等到再次释放出4GB ，则将node1上的10GB内存分配给该作业，整个过程在批处理场景中能自然的发生，一旦加入长服务后，则可能产生饿死现象，也就是说node1上的4GB内存可能永远等不到，因为可能被长服务占着。在这方面，Borg做得很好，但mesos和YARN均存在饿死问题，目前无法解决。
• 服务高可用问题。 资源管理系统一旦支持长服务后，应保证系统服务出现故障时，上层的长服务不会受到影响，比如在YARN中，ResourceManager或者NodeManager出现故障后，其上运行的长服务，比如MySQL，不应受到影响，到恢复后，重新接管这些服务。这一点，Borg/Mesos/YARN（本文指的是Hadoop 2.6.0之后的版本）均已经支持。
• 日志收集和滚动。 长服务永不停止，为了方便排错和监控，长服务的日志收集也是需要解决的，Borg/Mesos/YARN在这一块均有很好地支持，其中mesos/YARN可通过上层框架解决，比如Mesos中的 aurora和Marathon（apache顶级项目），YARN中的Twill和Slider（Apache二级项目）。
• 服务发现。长服务部署到资源管系统中后，可能被调度运行到任意一个节点上，为了让外界的访问者（客户端）发现自己的位置，需要有一个服务注册组件登记这些长服务，Borg/Mesos/YARN均对服务注册有支持，Mesos可通过上层框架，比如Aurora，YARN内核内置了对服务注册的支持。
• 资源伸缩。长服务运行一段时间后，由于访问量的增加或减少，可能需要动态调整所使用的资源量。资源伸缩有两个维度：一个是横向的，即增加实例数目；另一方面是纵向的，即原地增加正在运行实例的资源量。这方面Borg/Mesos/YARN均已经支持，其中横向支持是通过上层框架实现的，而纵向支持是通过资源管理系统内核支持的（https://issues.apache.org/jira/browse/YARN-1197 ）。
• 服务配置更新和在线升级。 这一块均与资源管理系统无直接关系，一般通过上层的框架实现。
  从上面可以看出，borg在一开始就立足于在离线混合部署，而mesos和yarn在一开始并没有考虑到很多细节的问题，而是在后来的实践过程中才慢慢开始加入一些新的特性和处理机制。

3. 其他实现机制

• 资源预申请。borg中称为alloc，应用程序可以预申请一些资源用于快速启动一些低延迟task、动态扩容等方面的内容。但是mesos和yarn没有支持，在这两个系统中，分配的资源必须在一定时间内使用，否则资源将会被回收。
• 作业优先级抢占。borg中具有严格的优先级和详细的资源抢占机制，在线任务具有较高的优先级可以抢占离线任务，同优先级的任务之间不可以抢占，被抢占的任务将会被放置在等待队列中进行重新调度等；mesos因为是基于资源供给的，所以不支持优先级抢占；yarn支持优先级抢占，但是对于在线任务和离线任务混合调度场景目前还没有支持，在YARN中资源抢占仅仅用于队列回收资源的场景中。
• 份额限制和准入控制。borg中有详细的份额限制和准入控制，以防止应用程序无限制的申请资源。yarn在2.6版本之后也加入了这套机制。

4. 总结

• 目前来看，mesos和yarn在架构设计上与borg还有较大差距，但是borg系统没有开源，不清楚其内部的具体实现。
• 对于中小型的数据中心采用mesos和yarn已经绰绰有余了。
• 不得不说borg的科技实力非常雄厚，你能想象得到一个Omega系统的原型是由几个实习生和博士生搞出来的吗？borg的出现比mesos和yarn早了十余年。borg中渗透的设计思想如：在离线混合部署，超售机制，直到今天才被业界关注到并应用于实践。
• K8S作为borg的类开源版本，这里用类开源版本是说其并不是borg的开源版本，而是其中的设计思想吸纳了borg的思想并且两个系统的开发团队有重叠。所以在为了K8S绝对是趋势。
• 就在5月2号，Twitter宣布弃用mesos并将在2020年完成系统向K8S的转化，这也说明了K8S在未来资源管理和调度系统中的地位。
• 就目前来说，云计算的快速发展，使得企业可以不同维护自己的数据中心，可以将自己的服务部署在云平台上，这在一定程度会减缓资源管理和调度系统的发展。而云服务提供者可以根据实际场景研发其自己的调度系统，来综合满足不同维度的需求，例如阿里云自研的伏羲系统sigma系统等。
• 只要有云计算，资源管理和调度系统就是一个不能绕开的话题，其就像电脑的CPU一样，为任务的执行提供条件。