yarn和mesos_Mesos和YARN：两个集群的故事

yarn和mesos

这是两个孤立集群的故事。 第一个集群是Apache Hadoop集群。 这是一个孤岛，其资源与Hadoop及其流程完全隔离。 第二个集群是我对不属于Hadoop集群的所有资源的描述。 之所以将它们分解，是因为Hadoop使用Apache YARN（又是另一个资源协商器）来管理自己的资源。 这对Hadoop很好，但是当队列中没有大数据工作负载时，这些资源经常会被利用不足。 然后，当进行大数据作业时，这些资源就会被拉到极限，很可能需要更多的资源。 当您在岛上时，这可能会很难。

Hadoop是要拆除墙壁（尽管是数据孤岛的墙壁），但是要拆除墙壁。 发生的事情是，虽然拆除了一些墙，但其他类型的墙却在原处升起。

Apache Mesos是另一种技术，也意在拆除墙壁-但是Mesos通常被定位为管理“第二集群”，这些集群是所有其他非Hadoop工作负载。

这是故事的真正起点，其中包括Mesos和YARN的这两个孤岛。 它们常常相互抵触，好像它们不兼容。 原来他们在一起工作，这就是我的故事。

Mesos和YARN的简要说明

Mesos和YARN之间的主要区别在于它们的设计优先级以及它们如何进行调度工作。 Mesos旨在成为整个数据中心的可扩展全局资源管理器。 它是2007年在加州大学伯克利分校设计的，并在Twitter和Airbnb等公司的生产中得到了加强。 YARN的创建是出于扩展Hadoop的必要性。 在YARN之前，资源管理已嵌入Hadoop MapReduce V1中，必须删除它以帮助MapReduce扩展。 MapReduce 1 JobTracker实际上不会扩展到几千台机器。 YARN的创建对于Hadoop生命周期的下一个迭代至关重要，主要围绕扩展。

Mesos调度

Mesos确定哪些资源可用，并将其提供回给应用程序调度程序（应用程序调度程序及其执行程序称为“框架”）。 这些提议可以被框架接受或拒绝。 该模型被视为非整体模型，因为它是“两级”调度程序，调度算法可插入其中。 Mesos允许开发无限数量的调度算法，每种调度算法都有其自己的接受或拒绝的策略，并且可以容纳数千个在同一集群上运行多租户的调度程序。

Mesos的两级调度模型允许每个框架决定要使用哪种算法来调度需要运行的作业。 Mesos扮演仲裁者的角色，在多个调度程序之间分配资源，解决冲突，并确保根据业务策略公平分配资源。 提供报价，然后框架可以执行消耗这些提供资源的任务。 或者框架可以选择拒绝报价并等待其他报价进入。此模型与多个应用程序同时在笔记本电脑或智能手机上同时运行的方式非常相似，因为它们会生成新线程或根据需要请求更多内存它，然后操作系统在所有请求中进行仲裁。 该模型的优点之一是，它基于多年的操作系统和分布式系统研究，并且具有很高的可扩展性。 这是Google和Twitter大规模验证的模型。

YARN调度

现在，让我们看看YARN方面发生了什么。 当作业请求进入YARN资源管理器时，YARN评估所有可用资源，并放置作业。 这是一个决定应该去哪里工作的人。 因此，它以整体方式建模。 重申YARN是MapReduce框架演进步骤的必要条件，这一点很重要。 YARN从MapReduce 1 JobTracker中提取了资源管理模型，对其进行了概括，然后将其移入其自己的单独ResourceManager组件中，这主要是由于需要扩展Hadoop作业。

YARN已针对调度Hadoop作业进行了优化，这些作业在历史上（并且通常是）具有较长运行时间的批处理作业。 这意味着YARN既不是为长期运行的服务而设计的，也不是为短暂的交互式查询（例如小型和快速的Spark作业）设计的，尽管有可能安排其他类型的工作负载，但这并不是理想的模型。 MapReduce的资源需求，执行模型和体系结构需求与长期运行的服务（例如Web服务器或SOA应用程序）或实时工作负载（如Spark或Storm）的需求，差异很大。 此外，YARN专为无状态批处理作业而设计，如果失败，可以很容易地重新启动它们。 它不处理正在运行的状态服务，例如分布式文件系统或数据库。 虽然YARN的单片调度程序理论上可以演变为处理不同类型的工作负载（通过将上游的新算法合并到调度代码中），但它并不是一个轻量级的模型，无法支持越来越多的当前和将来的调度算法。

是YARN VS Mesos吗？

在比较YARN和Mesos时，重要的是要了解常规的缩放功能以及为什么有人会选择一种技术而不是另一种技术。 尽管有些人可能认为YARN和Mesos正在争夺同一空间，但实际上并非如此。 放置这些模型的人从一开始就有不同的意图，这没关系。 两种模型都没有明显的错误，但是每种方法都会产生不同的长期结果。 我相信这是何时使用一个，另一个或两者兼而有之的关键。 Mesos与Google的Omega同时建造。 Ben Hindman和伯克利AMPlab团队与Google团队紧密合作，设计了Omega，以便他们俩都可以从Google Borg的课程中学到东西，并构建一个更好的非整体式调度程序。

在评估如何整体管理数据中心时，Mesos一方面可以管理数据中心中的所有资源，另一方面，您可以使用YARN，它可以安全地管理Hadoop作业，但是无法管理您的整个数据中心。 数据中心运营商倾向于通过将集群分为Hadoop和非Hadoop世界来解决这两种用例。

为了从两个资源管理器中受益，在同一个数据中心中使用Mesos和YARN当前需要创建两个静态分区。 两者都使用将意味着某些资源将专用于Hadoop以供YARN管理，而Mesos将获得其余资源。 可能过于简化了，但这实际上就是我们在这里谈论的内容。 从根本上讲，这是我们要避免的问题。

介绍项目Myriad

这引出了一个问题：我们可以让YARN和Mesos一起工作吗？ 我们能否使它们和谐地工作以造福于企业和数据中心？ 答案是肯定的。 一些著名的公司-eBay，MapR和Mesosphere-合作开展了名为Myriad的项目 。

这个开源软件项目既是Mesos框架，也是YARN调度程序，使Mesos可以管理YARN资源请求。 当作业进入YARN时，它将通过Myriad Scheduler对其进行计划，该计划会将请求与传入的Mesos资源提供进行匹配。 然后，Mesos会将其传递给Mesos工作程序节点。 然后，Mesos节点会将请求传达给运行YARN节点管理器的Myriad执行程序。 Myriad在Mesos资源上启动YARN节点管理器，然后将这些资源可用给YARN资源管理器。 然后，YARN可以根据需要消耗资源。 Myriad提供了从Mesos中可用的资源池到需要这些资源的YARN任务的无缝桥梁。

这种方法的优点在于，它不仅允许您在共享集群上弹性运行YARN工作负载，而且实际上使YARN比最初设计的更具动态性和弹性。 这种方法还使数据中心运营团队可以轻松扩展分配给YARN的资源（或视情况而定删除它们），而不必重新配置YARN集群。 动态控制整个数据中心变得非常容易。 该模型还提供了一种简单的方法来运行和管理多个YARN实现，甚至是同一群集上不同版本的YARN。

Myriad融合了YARN和Mesos世界的精华。 通过利用Myriad，Mesos和YARN可以合作，并且您可以实现即时业务。 可以在运行生产服务的同一硬件上就地执行数据分析。 您将不再面对静态分区所导致的资源限制（和低利用率）。 可以灵活地重新配置资源以满足业务发生时的需求。

最后的想法

为了确保人们了解我从这里来的位置，我认为Mesos和YARN都非常擅长于实现的目标，但都有改进的空间。 两位资源管理器都可以改善安全性； 安全支持对于企业采用至关重要。

Mesos需要端到端的安全体系结构，我个人不会在Kerberos上划定界限来提供安全支持，因为我的亲身经历并不是我所说的“有趣”。 Mesos的另一个需要改进的地方-可能变得非常复杂-我将其描述为资源撤销和抢占。 想象一下一个用例，其中分配了业务中的所有资源，然后就需要拥有您的业务所依赖的最重要的“事物”-即使此任务仅需要几分钟的时间才能完成，您还是很走运如果资源不可用。 资源抢占和/或撤销可以解决该问题。 今天，Mesos中目前有解决此问题的方法，但是我期待Mesos提交者为解决此问题而进行的工作，包括“ 动态预留”和“乐观（可撤消）资源” 。

Myriad是一项启用技术，可用于利用数据中心或云中的所有资源作为单个资源池。 无数使企业能够拆除隔离的群集之间的墙，就像Hadoop使企业能够拆除数据孤岛之间的墙一样。 使用Myriad，开发人员将能够专注于业务所依赖的数据和应用程序，而运营将能够管理计算资源以实现最大的敏捷性。 这打开了能够专注于数据的大门，而不用不断担心基础架构。 对于Myriad，存储网络的约束以及计算和数据访问之间的协调是实现完全灵活性，敏捷性和可扩展性的最后一刻。

• Myriad项目托管在GitHub上 ，可以下载。

那里有文档，提供了有关其工作原理的更深入的说明。 您甚至会看到一些漂亮的图表。 出去探索，然后尝试一下。

编者注：这篇文章最初是在O'Reilly Radar上发布的。

翻译自: https://www.javacodegeeks.com/2015/11/mesos-and-yarn-a-tale-of-two-clusters.html

yarn和mesos