189 8069 5689
这篇文章主要讲解了“Mesos和YARN是怎么协同工作的”，文中的讲解内容简单清晰，易于学习与理解，下面请大家跟着小编的思路慢慢深入，一起来研究和学习“Mesos和YARN是怎么协同工作的”吧！
为保定等地区用户提供了全套网页设计制作服务，及保定网站建设行业解决方案。主营业务为成都做网站、成都网站制作、保定网站设计，以传统方式定制建设网站，并提供域名空间备案等一条龙服务，秉承以专业、用心的态度为用户提供真诚的服务。我们深信只要达到每一位用户的要求，就会得到认可，从而选择与我们长期合作。这样，我们也可以走得更远！
Hadoop 2.0之后把对集群资源的管理从MapReduce v1的JobTracker中提取出来，在YARN中进行了实现。虽然YARN支持了多种不同的计算框架，但依旧没有很好的解决集群资源的弹性伸缩问题。本文介绍了一个新的项目- Myriad，它把YARN和Mesos两者的优势结合起来，不仅使YARN的运行使用更加灵活，而且让整个数据中心的扩容变得更简单。
这是一个关于两个集群的故事。第一个是Apache Hadoop集群，其中资源与Hadoop以及进程完全隔离。另一个集群是对所有资源的描述，这些资源并不是Hadoop集群的一部分。通过这种方式来区分两个集群是因为Hadoop通过Apache YARN（Yet Another Resource Negotiator）来管理自己的资源。对于Hadoop来说，在没有大数据任务在队列中时，这些资源常常是未被充分使用的。当一个大数据任务运行时，这些资源迅速被用到极限，并且在请求更多资源。这对于第一种Hadoop集群而言相当困难。
图1- 独立集群- 来源：Mesosphere and MapR,侵删.
尽管Hadoop有意打算消除数据壁垒，但是在拆去一些壁垒的同时，其他类型的壁垒又在相同的地方产生。作为新的技术方案，Apache Mesos也有意消除这些壁垒。但Mesos常被用来管理“第二种集群”，这些集群包括除去Hadoop任务之外的所有资源。
前面介绍的关于Mesos和YARN的不同点，这只是开始。正如它们并不兼容，经常互相竞争。而我的故事，讲的却是它们协同工作。
Mesos和YARN之间的主要区别围绕着优先级的设计以及调度任务的方式。Mesos于2007年诞生于UC Berkeley并在Twitter和Airbnb等公司的商用下不断被巩固，它的设计初衷是作为整个数据中心的一个可拓展的全局资源管理器。YARN出于管理Hadoop规模的需求。在YARN出现之前，资源管理（功能）集成在Hadoop MapReduce V1架构中，为了有助于MapReduce的扩展而将其移除（转移到YARN中实现）。MapReduce的Job Tracker并不能在超过上千台的机器中有效调度MapReduce任务。YARN在下一代Hadoop生命周期中被创造，主要围绕着资源扩缩。
Mesos决定了哪些资源可用，它把分配请求返回给一个应用调度器（应用调度器和执行器被称作“框架”）。这些分配请求被框架接受或者拒绝。这个模型被认为是非单体模型，因为它是一个“两级”调度器，调度算法是可拔插的。Mesos允许任何实现任何调度算法，每个算法都能根据自己的策略进行接收或是拒绝分配请求，并且可以容纳成千上万种调度程序以多租户的方式运行在同一个集群。
Mesos的两级调度模型允许每个框架（自己）决定使用哪种算法来调度运行的工作。Mesos扮演仲裁者，在多个调度器上来调度资源，解决冲突，并且确保资源基于业务策略被公平地分发。分配请求到来时，框架会执行任务来消费那些提供的资源。或者框架可以选择拒绝请求并且等待下一个分配请求。这种模型与在一台笔记本电脑或智能手机上如何同时运行多个App十分类似，当需要更多内存时会创建新的线程或请求，操作系统来仲裁管理所有的请求。多年的操作系统和分布式系统的实践发展证明，这种模型的好处在于它具有良好的扩展性。它已被Google和Twitter证明。
现在，我们再看一下YARN。当job请求到达YARN资源管理器，YARN评估所有可用的资源然后调度job。YARN以一种整体的方式，直接决定job运行的位置。在MapReduce架构演变的过程中，重申强调YARN的出现十分重要。在Hadoop任务的资源规模伸缩需求的驱动下，YARN把资源管理的模型从MR的Job Tracker中独立出来，在Resources Manager组件中实现。
过去一贯的Hadoop任务是持续一段时间的批处理任务，YARN为了调度新的Hadoop任务进行了优化。这意味着YARN既不是为长时间运行的服务而设计，也不是为满足短期交互/快速响应式请求（像简短而快速的Spark任务），尽管它可能调度其他种类的工作负载，但这并不是一个理想的模型。MapReduce的资源需求、执行模型和架构需求不同于长时间运行的服务，如Web服务器、SOA应用程序或是像Spark和Storm那样的实时任务。同时，YARN针对调度无状态的脚本任务设计，这些任务失败时可以任意重启。 但它并不能处理像分布式文件系统或数据库那样的有状态的服务。然而YARN的集中式调度器，理论上可以处理不同类型的工作负载（通过把新的算法合并到调度代码），对于支持日益复杂的调度算法，这并不是一个轻量级的模型。
在对比YARN和Mesos时，理解通用的调度能力和为什么需要在他们之间做取舍十分重要。虽然有些人可能认为YARN和Mesos大同小异，但并非如此。区别在于用户一开始使用时需求模型的不同。每种模型没有明确地错误，但每种方法会产出不同的长期结果。我认为这就是选择如何使用它们的关键。Ben Hindman和Berkeley AMP实验室在设计Mesos时，与Google设计Omega的团队同期进行，Mesos系统得益于Google的Omega系统设计的经验，构建了一个更好的非单体（两阶段）的调度器。
当你把如何管理数据中心作为整体来评估时，一方面使用Mesos来管理数据中心的所有资源，另一方面使用YARN来安全的管理Hadoop任务，但它并不具有管理整个数据中心的能力。数据中心运营商倾向于把集群划分为的不同区域（Hadoop集群和非Hadoop集群）来应对这两个场景。
在同一个数据中心使用Mesos和YARN，为了受益于资源管理器，目前需要创建两个静态分区。此时意味着当指定资源被Hadoop的YARN管理时，Mesos就无法起作用。这也许过于简化了，尽管这么做确实有效。但本质上，我们是想避免这种情况。
这不禁让我们发问：能否让企业和数据中心受益于YARN和Mesos的协调工作？答案是肯定的。一些著名的公司——eBay、MapR和Mesosphere共同合作了一个项目叫做Myriad.
这个开源软件项目既是一个Mesos框架，又是一个YARN调度器，这就使得Mesos能够管理YARN的资源请求。当一个任务到达YARN时，它会通过Myriad调度器调度它，使请求与Mesos提供的资源匹配。相应的，Mesos也会将它传递给Mesos工作节点。之后，这个Mesos节点会把这个请求与一个正在执行YARN节点的管理器的Myriad执行器关联。Myriad在Mesos资源启动YARN节点管理器，启动之后，Mesos资源会告诉YARN资源管理器哪些资源可用。这时YARN就可以随意地使用这些资源。Myriad为Mesos的可用资源池和YARN的任务（需要用到Mesos中资源）之间架起了一座无缝连接的桥梁。
图2- myriad如何工作？ 来源：Mesosphere and MapR,侵删.
这种做法的优点是，它不仅让你在共享的集群中弹性的使用YARN，使得YARN比最初设计时更具活力和弹性。而且，它使得数据中心的运维团队在给YARN资源扩容时无需重新配置YARN集群。整个数据中心的扩容变得十分容易。该模型提供了一种简单的方式运行和管理多个YARN的实现，甚至在同一个集群上运行多个不同版本的YARN。
图3- 资源共享 来源：Mesosphere and MapR,侵删.
Myriad把YARN和Mesos两者的优势结合起来。通过使用Myriad项目，让Mesos和YARN可以协作，你可以完成一个实时业务。数据分析可以在和运行生产服务的相同硬件上执行。你不再需要面临由静态分区引起的资源限制（和低利用率）。资源可以根据业务的需求弹性的伸缩。
感谢各位的阅读，以上就是“Mesos和YARN是怎么协同工作的”的内容了，经过本文的学习后，相信大家对Mesos和YARN是怎么协同工作的这一问题有了更深刻的体会，具体使用情况还需要大家实践验证。这里是创新互联，小编将为大家推送更多相关知识点的文章，欢迎关注！