为什么用Yarn来做Docker容器调度引擎

问题导读：





1.为什么选择yarn而不是Mesos？
2.Yarn的未来发展？
3.Yarn做long running services 需要考虑什么？








在过去一年中，Hadoop YARN取得了飞速发展，尤其是在long-running service方面，已经得到了比较完备的支持。经hulu内部测试，从hadoop 2.6.0开始，YARN对service的支持已经可以满足生产环境需求。由于YARN具备了RM HA，RM Recovery和NM Recovery三个重要特性，这使得ResourceManager重启，或者NomeManager重启时，均不会对正在运行的container产生任何影响。加之Hulu的voidbox（Docker On YARN）内置了ApplicationMaster HA特性，使得服务可以非常可靠地运行在YARN上。“为什么用Yarn来做Docker容器调度引擎”一文（祝海林在微博（微博：@祝威廉二世）发表）中提到的hulu实现，便是指的Voidbox，大家可直接在百度或google中搜索“voidbox”，前几篇文章全是关于voidbox内部实现的详细介绍。

一、先说说为什么选择yarn而不是Mesos?

1. 首先是可部署性。Yarn如果打包JDK后可以没有任何依赖的，Mesos因为是C/C++开发的，

安装部署可能会有库依赖。 这点我不知道大家是否看的重，反正我是看的相当重的。软件就应该是

下下来就可以Run。所以12年的时候我就自己开发了一套Java服务框架，开发完之后运行个main方法就行。

让应用包含容器，而不是要把应用丢到tomcat这些容器，太复杂，不符合直觉。

2. 二次开发。Yarn其实就是个Jar包，而且和Lucene也一样，提供了非常多的扩展接口，很多实现都是可插拔

可替换的，在xml配置下，可能就能用你的实现替换掉原来的实现，没有太大的侵入性，所以就算是未来Yarn升级，

也不会有太大问题。Mesos我不知道这种二次开发性如何。

当然， Mesos和Yarn 都非常棒，都是可编程的框架。一个系统，只要是可编程的，基本就有活了。一个硬件，不能编程，就是死的，一旦可以编程

就活了，就可以各种折腾，有各种奇思妙想可以实现。

上面是说Mesos和Yarn的选型。我再说说为啥选择要对Yarn再进行一次封装。

二、为啥选择要对Yarn再进行一次封装？

1. 首先，Yarn为了灵活，或者为了能够满足开发者大部分的需求，底层交互的API就显得比较原始了。自然造成开发难度很大。这个也不是我一个人觉得，现在Apache的twill,以及Hulu他们开发的时候Core那一层（大家可点击左下角“阅读原文”查看hulu的实现），其实都是为了解决这个问题。那为什么我没有用Twill呢，第一是文档实在太少，第二是有点复杂，我不需要这么复杂的东西。我觉得，Twill与其开发这么多功能，真的不如好好写写文档。

2. 还有就是为了隔离，让上层你开发的Framework可以移植。Spark是个典型,他可以跑在Mesos上，也可以跑在Yarn上 ,还可以跑在自己上面，就是因为Spark的Framework不依赖于底层的Core,这个Core其实就是适配。我封装了Yarn后，上层的Framework是看不到的Yarn的API的。

3. 这些做好后，你想要开发组件，其实就是基于Core再开发个Framework,如果你想开发应用，就是针对Framework开发了。

Framework是个什么概念，其实就是类似Spark,类似MR,他们都是一个在Yarn之上的Framework,你开发的MR程序，Spark程序则是应用。

我们说容器解决了资源隔离，解决了库的依赖问题。同样的，Yarn对操作系统也没有任何要求，没有任何库的依赖，把Yarn和容器结合，基本上算是天作之合，整套资源管理，调度编排可以跑在一个混合的系统上(比如你的集群由100台centos,100台Ubuntu构成)，也不需要担心库的依赖。部署起来也会很简单。

本文比较完整的介绍了YARN朝着通用资源管理系统前行过程的曲折，以及目前YARN在长服务方面支持的能力。借助强大的Hadoop社区以及众多commmiter的努力，2015一年时间，YARN在资源管理方面突飞猛进，相信在2016年，会有越来越多的公司开始意识到这一点，并开始尝试在YARN上运行长服务。

     需要注意的是，YARN是资源管理系统，只负责资源的管理和调度，至于服务依赖等问题，通常通过上层framework解决，这也是Apache Twill（http://twill.apache.org/，在YARN基础上封装的API，方便用户在YARN上开发应用程序）和Apache Slider（http://slider.apache.org/，支持将HBase，Storm系统等以服务形式运行在YARN上）两个项目出现的原因。下图是Hortonworks公司最近公布的YARN生态图（标题为“YARN with Slider”）：

三、生态方面

没想到在群里给人的回复整理出来的内容，发到微博上发现对大家还是有帮助的。原文只是纯粹从开发的角度来看的，这里再补充补充几点生态方面的：

1. Yarn 因为诞生于Hadoop这个大数据的始作俑者项目，所以在大数据领域具有先天优势。和HDFS有天然的集成。其上支撑了Spark,MR等大数据领域的扛顶之座，最近发布版本也明显加快，对于长任务的支持也越来越优秀。说了这么多，就是说，Yarn的社区绝对不用担心，Yarn的发展自然也不用担心。

2. Yarn之前之所以没有脱离大数据生态，成为一个通用的资源管理调度组件(虽然一开始他就是朝着这个目标的)，我觉得有两点：

• 习惯的力量。因为Yarn是从MR里剥离出来的，大家自然而然的认为Yarn必须活在Hadoop生态群里。我在之前的一篇课程里，反复强调，Hadoop是一个软件集合，包含分布式存储，资源管理调度，计算框架三个部分。他们之间没有必然的关系，是可以独立开来的。
  
  
  

• Yarn确实对HDFS有些耦合，比如ContainerLocalization等就需要HDFS的支持。这个问题还是比较容易解决的。
  
  
  

• 固有的认为Yarn适合批量任务的调度，而不适合服务。其实从13年开始Yarn社区就一直在加强这块。到目前的2.6,2.7版本，我认为是足以支持长任务的。
  
  
  

四、总结

说到长任务，我之前在群里也和人有讨论，并做了下总结。

Yarn做long running services 需要考虑一下几个点：

1. Fault tolerance. 主要是AM的容错。

2. Yarn Security. 如果开启了安全机制，令牌等的失效时间也是需要注意的。

3. 日志收集

4. 还有就是资源隔离和优先级。这个我觉得可以通过容器能很好的解决。

关于这块可以参考Jira https://issues.apache.org/jira/browse/YARN-896.

我看这个Jira 13年就开着了。说明这事还是需要一个过程。

AM容错，我看从2.4版本(看的源码，也可能更早的版本就已经支持)就已经支持 keep containers across attempt 的选项了。什么意思呢？就是如果AM挂掉了，在Yarn重新启动AM的过程中，所有由AM管理的容器都会被保持而不会被杀掉。除非Yarn多次尝试都没办法把AM再启动起来(默认两次)。 这说明从底层调度上来看，已经做的很好了。

第二个是Yarn以及HDFS的安全令牌机制，有个失效时间。这个就不具体阐述。总之是因为一开始确实没有给LRS程序考虑。

日志收集在2.6版本已经是边运行边收集了。

资源隔离的话，Yarn做的不好，目前有效的是内存，对其他方面一直想做支持，但一直有限。这估计也是很多最后选择Mesos的缘由。但是现在这点优势Mesos其实已经荡然无存，因为Docker容器在资源隔离上已经做的足够好。Yarn和Docker一整合，就互补了。

容器技术使得所有应用可以被操作系统运行起来。并且可以吻合Yarn内核对资源控制的要求。但是我们可能需要对被容器包括起来应用更细致的控制。 我们先来看两个概念。

哑应用：所谓哑应用指的是无法和分布式系统直接进行交互，分布式系统也仅仅透过容器能进行生命周期的控制，比如关闭或者开启的应用。典型的比如MySQL,Nginx等这些基础应用。他们一般有自己特有的交互方式，譬如命令行或者socket协议或者HTTP协议。

伴生组件：因为有了哑应用的存在，操作系统为了能够和这些应用交互，所以有了伴生组件的存在。这些伴生组件和哑应用具有相同的生命周期。伴生组件其实是哑应用的Proxy,从而使得哑应用可以和分布式系统进行交流。典型的比如，某个服务被关停后，该事件会被操作系统获知，操作系统会将该事件发送给Nginx的伴生组件，伴生组件转化为Nginx能够识别的指令，将停止的服务从Nginx的ProxyBackend列表中剔除。

所以，Yarn管理的其实还是Java的Container，如果该Container同时也是伴生组件，则该Java Container可以直接和第三方应用做交互。否则就需要借助另外一个伴生组件做中转，从而实现对任意，第三方应用的统一管理。

这个方案就奠定了，Yarn可以作为一个通用的资源调度引擎，将包括存储，应用等都囊括进来，同时也自然而然的集成了大数据平台。我觉得从这来来看，更像Google的Borg了。

写的很详细，学习了。

谢谢楼主分享

写的很详细，学习了。