Apache YARN/Mesos与Google Borg差距多远？

Google于2013年和2015年分别公开了它的实验和生产环境中使用的数据中心资源管理系统Omega和Borg，其中Omega是一个实验产品，由几个实习生博士做出了原型， 比较新颖地提出了share state架构，是一种非常理想的架构，但个人认为离完全替换Borg还有一段距离，即使替换，在短时间内仍然不能完全替换，因此本文不会过多讨论（关于Omega的细节，也可参考我的这篇文章：“解析Google集群资源管理系统Omega”，链接： http://dongxicheng.org/mapreduce-nextgen/google-omega/）。 而Borg作为一个成熟的系统，已经在google内部使用了相当长的时间，Borg论文称，google内部不仅像计算型的应用，比如MapReduce，FlumeJava，Millwheel，和Pregel 运行在Borg上，存储类的应用，比如GFS，BigTable和Megastore等也运行在上面，真正做到了批处理作业和长服务混合部署动态调度。本文从笔者角度，对比了开源资源管理系统YARN/Mesos与Borg的差距（我曾经写过一篇非常浅显的对比文章，可参考“浅谈Borg/YARN/Mesos/Torca/Corona一类系统”，链接： http://dongxicheng.org/mapreduce-nextgen/borg-yarn-mesos-torca-corona/），由于笔者能力的局限性，文中很多观点可能会片面，浅显，望各位本着交流的心态，客观地阅读本文。

建造数据中心非常昂贵，因此我们必须用好它。 各大公司都在尝试用好自己的数据中心。根据几家互联网巨头这些年的实践，用好数据中心的常用手段是构建资源管理系统，对上次的各类应用进行统一管理和调度，进而达到简化数据中心运维，提高集群利用率的目的。细数国内外互联网巨头，他们都有自己的资源管理系统，比如Google的Borg，Twitter的Mesos，阿里巴巴的Fuxi，微软的Apollo等。本文涉及到的Google Borg相关内容，主要参考了论文“Large-scale cluster management at Google with Borg”，不了解Borg的读者，可自行阅读该论文。

1.架构对比

Google Borg采用了集中式master/slave架构 （Borgmaster和Borglet），其中Borgmaster负责集群资源管理和调度，Borglet负责执行实际的任务，Borgmaster通常有5个实例，通过Paxos协议组成一个高可用分布式集群；Borgmaster会周期性地主动poll各个Borglet以获取其状态和资源使用情况，一旦发现其出现问题，会触发容错，之所以采用poll，而不是像YARN/meso采用心跳机制，主要是考虑到这种方式能够更容易地控制网络通信开销，避免active Borgmaster选举时出现网络风暴等。前面提到Borg中存在5个Borgmaste，他们每个会分管一部分Borglet的状态获取和探测，并将收到的信息压缩和求差后，交给active Borgmaster，以分摊active Borgmaster压力。从这种细粒度的设计可以初探端倪：Borg尽管采用了集中式架构，但扩展性仍很好，对应Borg论文中这句话“We are not sure where the ultimate scalability limit to Borg’s centralized architecture will come from; so far, every time we have approached a limit, we’ve managed to eliminate it.”

开源系统YARN和Mesos均采用了双层调度架构，需要注意的是，google在论文omega和borg中均认为YARN是集中式架构，而把Mesos划归为双层调度架构，个人认为这是不准确的，YARN跟Mesos类似，ResourceManager负责集群调度，ApplicationMaster负责framework和应用程序内部调度，相比Mesos，由于YARN的ResourceManager要维护各个分配出去的Container的状态和位置等信息，因此，要比Mesos Master重一些。YARN和Mesos的Master均采用Zookeeper解决高可用问题，其中active master进行资源管理和调度，而backup master仅仅是backup作用，不会协助active master做任何事情；Slave会主动通过周期性心跳向Master汇报状态信息。

1.1扩展性

Borg对所管理的所有borglet进行了水平分片，让每个 Borgmaster分管一部分，这些borgmaster共享集群元信息，每个Borgmaster均可以为应用程序分配资源，但backup Borgmaster需要将分配信息发送给active Borgmaster进行审批，这个地方与Google Omega中的share state是一致的。在这方面，YARN和Mesos均是做不到，他们只有一个master进行资源管理和调度，在超大集群中，master可能会成为瓶颈，这是YARN和Mesos需要改进的方向。

1.2高可用

应用程序方面：Borg内置了各种错误重试机制，确保在机器故障，网络故障等情况下，应用程序不会失败。

服务方面：Borgmaster和Borglet挂掉后，其上正在运行的应用程序和任务不会受影响，这一点，目前Mesos和YARN已经做到。

2.对批处理作业和长服务的支持

为了简化应用程序分类，Borg把应用程序分成两类，批处理作业和长服务，批处理作业是类似于MapReduce和Spark的作业，在一定时间内会运行结束，长服务则类似于web service，HDFS service等，可能会永久运行下去，永不停止。批处理作业和长服务是绝配，混合部署它们对提高集群利用率是非常有帮助的，长服务占用大块资源，而批处理作业穿插到长服务未使用的小块资源中，当高优先级的应用需要资源时，可直接杀死抢占批处理作业。根据borg和omega论文的描述，在google集群中，长服务占用了集群中70%~80%的资源。

Mesos和YARN均对批处理作业有良好的支持，这类应用的支持也是最简单的，而难点在于长服务，一旦引入长服务，会带来以下问题：

（1）资源竞争与饿死问题。 当一个集群中只存在批处理作业时，资源调度是很容易做的，因为资源释放和申请是不断在进行中的，任何资源的申请都可以得到满足。但存在长服务后则不同，因为目前主流的调度器均采用资源预留的调度机器，比如一个作业需要10G内存，目前没有任何节点存在10GB内存呢，为了避免永远拿不到资源，调度器会找一个存在部分资源的节点，比如node1存在6GB内存，则会为该作业预留着，一直等到再次释放出4GB ，则将node1上的10GB内存分配给该作业，整个过程在批处理场景中能自然的发生，一旦加入长服务后，则可能产生饿死现象，也就是说node1上的4GB内存可能永远等不到，因为可能被长服务占着。在这方面，Borg做得很好，但mesos和YARN均存在饿死问题，目前无法解决。

（2）服务高可用问题。 资源管理系统一旦支持长服务后，应保证系统服务出现故障时，上层的长服务不会受到应用，比如在YARN中，ResourceManager或者NodeManager出现故障后，其上运行的长服务，比如MySQL，不应受到影响，到恢复后，重新接管这些服务。这一点，Borg/Mesos/YARN（本文指的是Hadoop 2.6.0之后的版本）均已经支持。

（3）日志收集和滚动。 长服务永不停止，为了方面排错和监控，长服务的日志收集也是需要解决的，Borg/Mesos/YARN在这一块均有很好地支持，其中mesos/YARN可通过上层框架解决，比如Mesos中的 aurora和Marathon（apache顶级项目），YARN中的Twill和Slider（Apache二级项目）。

（4）服务发现。长服务部署到资源管系统中后，可能被调度运行到任意一个节点上，为了让外界的访问者（客户端）发现自己的位置，需要有一个服务注册组件登记这些长服务，Borg/Mesos/YARN均对服务注册有支持，Mesos可通过上层框架，比如Aurora，YARN内核内置了对服务注册的支持。

（5）资源伸缩。长服务运行一段时间后，由于访问量的增加或减少，可能需要动态调整所使用的资源量。资源伸缩有两个维度：一个是横向的，即增加实例数目；另一方面是纵向的，即原地增加正在运行实例的资源量。这方面Borg/Mesos/YARN均已经支持，其中横向支持是通过上层框架实现的，而纵向支持是通过资源管理系统内核支持的（https://issues.apache.org/jira/browse/YARN-1197 ）。

（6）服务配置更新和在线升级。 这一块均与资源管理系统无直接关系，一般通过上层的框架实现。

3.其他实现机制

（1）资源预申请（在borg论文中，称之为“alloc”）。应用程序可以预申请一些资源，可用于快速启动一些低延迟task，动态扩容等方面使用。 这一块mesos和yarn没有直接支持。在mesos和yarn中，应用框架申请到资源后，必须在一定时间内使用，如果未使用，mesos和yarn会进行回收。 实际上，mesos和yarn可以在上层框架层面解决这一问题，比如hive on Tez则实现了资源预申请，具体可参考我的这篇文章：“Tez：运行在YARN上的DAG计算框架”：http://dongxicheng.org/mapreduce-nextgen/tez-yarn-dag/。

（2）作业优先级与资源抢占。在一个混合应用部署的集群中，抢占是必须要支持的，为了支持抢占，必须提前合理规划好应用程序的优先级，以便于在一些情况下，为高优先级的作业抢占低优先级作业的资源。 资源抢占在YARN中以及得到了支持，但没能够用在批处理和长服务混合资源调度中。实际上，在YARN中，资源抢占仅仅用于队列回收资源的场景中。

（3）份额限制（Quota）和进入控制（admission control）

为了防止应用程序无限制申请资源，满足长服务的SLA，需要由一套完善的admission control机制，在开源实现中，YARN在2.6.0开始加入了这一套机制，具体参考：https://issues.apache.org/jira/browse/YARN-1051 。

4.总结

目前看来，Mesos/YARN的架构和设计上，与Google Borg仍有一定的差距，但需要注意的是，很多细节之处，都是tradeoff的结果，很难说哪种机制更适合我们的场景，对于搭建中小型的集群和数据中心，Mesos/YARN已经绰绰有余了。

5.参考资料

（1）google paper：Large-scale cluster management at Google with Borg

（2）google paper：Omega: flexible, scalable schedulers for large compute clusters

（3）YARN paper：Apache Hadoop YARN: Yet Another Resource Negotiator

（4）YARN书籍：“Hadoop技术内幕：深入分析YARN基本架构和原理”

（5）Apache slider：http://slider.incubator.apache.org/

（6）Apache Twill：http://twill.incubator.apache.org/

（7）Apache Aurora：http://aurora.apache.org/

（8）Apache marathon：https://mesosphere.github.io/marathon/

（9）Mesos paper：Mesos: A Platform for Fine-Grained Resource Sharing in the Data Center