Mesos和YARN的区别以及它们如何协同工作

发布网友 发布时间：2022-04-21 09:12

我来回答

共2个回答

懂视网 时间：2022-04-09 20:42

　　直到最近，Mesos都仅仅能够运行无须向磁盘存储数据的服务。这是因为没有方法预留所需的磁盘块。从Mesos 0.23版本开始，可以预留磁盘了。
　　我们可以将Mesos当作一个部署系统。如果MySQL数据库能够自动将自身备份，并且按需创建新的副本，是不是很好呢？或者如果拥有一个简单的，自服务的REST API，能够创建新的Riak和Cassandra集群，又会怎么样呢？为Mesos构建数据库框架的工作从2014年就开始了。这些框架的问题是每个主机都必须创建特别的数据分区，并且在Mesos之外加以管理。使用持久化卷，类似Apache Cotton（MySQL所用）以及Cassandra和Riak Mesos框架的项目就都能够独立启动和维护了。
　　在Mesos的设计里，磁盘空间是短暂的，并且是按任务隔离的。这通常是一件好事，除非用户想要持久地保存数据。要解决这个问题，Mesos引入了一个新的磁盘资源的子类型，称为volume。volume是分配给一个任务的磁盘块，并且挂载在特定位置。完成这一功能的API和挂载主机卷的Marathon API（详见“挂载主机卷”部分），几乎完全一致。用户甚至可以创建不持久的卷，这在想将多个独立磁盘暴露给Mesos时会很有用。
　　下面研究一下如何创建并且使用持久化卷。
　　有两个acceptOffers Operation用来创建以及销毁持久化卷。不出意外地，它们称为Create和Destroy。仅仅能够在已经被预留的磁盘资源上创建持久化卷。通常，用户会预留资源，创建卷，并且在单个acceptOffers里启动任务，如下面示例所示。
　　　　　　　　　　　　　
　　持久化卷资源和常规磁盘资源一样，但是它带有字段disk，设置为合适的DiskInfo。DiskInfo给该持久化卷命名，这样它能够挂载上，名字为嵌套的字符串子字段persistence.id的名称。DiskInfo的Volume必须使用RW模式（因为Mesos 0.24只支持RW）。Volume的container_path字段会指定容器在任务沙箱里的挂载位置。
　　持久化卷API是很新的功能，因此还没有任何生产环境框架用到它。它也有一些限制，比如卷必须一直挂载为RW，并且没有办法暴露多个磁盘，也没有任何磁盘或I/O隔离。即使添加了新特性和功能之后，也会保证该API的后向兼容性。因此，类似Apache Cotton的项目已经在其代码基里集成了持久化卷。
　　本文选自《用Mesos框架构建分布式应用》，点此链接可在博文视点官网查看此书。
　　　　　　　　　　　　　　　　　　
　　想及时获得更多精彩文章，可在微信中搜索“博文视点”或者扫描下方二维码并关注。
　　　　　　　　　　　　　　　　　　　　　

本文出自 “博文视点官方博客” 博客，请务必保留此出处http://bvbroadview.blog.51cto.com/3227029/1902576

Mesos：数据库使用的持久化卷

标签：mesos   数据库   

热心网友 时间：2022-04-09 17:50

　　Hadoop 2.0之后把对集群资源的管理从MapRece v1的JobTracker中提取出来，在YARN中进行了实现。虽然YARN支持了多种不同的计算框架，但依旧没有很好的解决集群资源的弹性伸缩问题。本文介绍了一个新的项目- Myriad，它把YARN和Mesos两者的优势结合起来，不仅使YARN的运行使用更加灵活，而且让整个数据中心的扩容变得更简单。

　　这是一个关于两个集群的故事。第一个是Apache Hadoop集群，其中资源与Hadoop以及进程完全隔离。另一个集群是对所有资源的描述，这些资源并不是Hadoop集群的一部分。通过这种方式来区分两个集群是因为Hadoop通过Apache YARN(Yet Another Resource Negotiator)来管理自己的资源。对于Hadoop来说，在没有大数据任务在队列中时，这些资源常常是未被充分使用的。当一个大数据任务运行时，这些资源迅速被用到极限，并且在请求更多资源。这对于第一种集群而言相当困难。

　　尽管Hadoop有意打算消除数据壁垒，但是在拆去一些壁垒的同时，其他类型的壁垒又在同样的地方产生。作为另一种技术方案，Apache Mesos也有意消除这些壁垒。但Mesos常被用来管理第二种集群，这些集群包括除去Hadoop任务之外的所有资源。

　　前面介绍的关于Mesos和YARN的不同点，只是故事的开端。正如它们并不兼容，经常互相竞争。而我的故事，讲的却是它们协同工作。

　　Mesos和YARN的简介

　　Mesos和YARN之间的主要区别围绕着优先级的设计以及调度任务的方式。Mesos于2007年诞生于UC Berkeley并在Twitter和Airbnb等公司的商用下不断被巩固，它的设计初衷是作为整个数据中心的一个可拓展的全局资源管理器。YARN出于管理Hadoop规模的需求。在YARN出现之前，资源管理(功能)集成在Hadoop MapRece V1架构中，为了有助于MapRece的扩展而将其移除(转移到YARN中实现)。MapRece的Job Tracker并不能在超过上千台的机器中有效调度MapRece任务。YARN在下一代Hadoop生命周期中被创造，主要围绕着资源拓展。

　　Mesos的调度

　　Mesos决定了哪些资源可用，它把分配请求返回给一个应用调度器(应用调度器和执行器被称作“框架”)。这些分配请求被框架接受或者拒绝。这个模型被认为是非单体模型，因为它是一个“两级”调度器，调度算法是可拔插的。Mesos允许任何实现任何调度算法，每个算法都能根据自己的策略进行接收或是拒绝分配请求，并且可以容纳成千上万种调度程序以多租户的方式运行在同一个集群。

　　Mesos的两级调度模型允许每个框架(自己)决定使用哪种算法来调度运行的工作。Mesos扮演仲裁者，在多个调度器上来调度资源，解决冲突，并且确保资源基于业务策略被公平地分发。分配请求到来时，框架会执行任务来消费那些提供的资源。或者框架可以选择拒绝请求并且等待下一个分配请求。这种模型与在一台笔记本电脑或智能手机上如何同时运行多个App十分类似，当需要更多内存时会创建新的线程或请求，操作系统来仲裁管理所有的请求。多年的操作系统和分布式系统的实践发展证明，这种模型的好处在于它具有良好的扩展性。它已被Google和Twitter证明。

　　YARN的调度

　　现在，我们再看一下YARN这边发生了什么。当job请求到达YARN资源管理器，YARN评估所有可用的资源然后调度job。YARN以一种整体的方式，直接决定job运行的位置。在MapRece架构演变的过程中，重申强调YARN的出现十分重要。在Hadoop任务的资源规模伸缩需求的驱动下，YARN把资源管理的模型从MR的Job Tracker中独立出来，在Resources Manager组件中实现。

　　为了调度Hadoop任务，YARN进行了优化(过去一贯的Hadoop任务是持续一段时间的批处理任务)。这意味着YARN既不是为长时间运行的服务而设计，也不是为满足短期交互/快速响应式请求(像简短而快速的Spark任务)，尽管它可能调度其他种类的工作任务，但这并不是一个理想的模型。MapRece的资源需求、执行模型和架构需求不同于长时间运行的服务，如Web服务器、SOA应用程序或是像Spark和Storm那样的实时任务。同时，YARN为了易于无状态的脚本任务重启而设计。它并不能处理像分布式文件系统或数据库那样的有状态的服务。然而YARN的整体的调度器理论上可以处理不同类型的工作负载(通过把新的算法合并到调度代码)，对于支持日益复杂的调度算法，这并不是一个轻量级的模型。

　　YARN vs Mesos?

　　在对比YARN和Mesos时，明白整体的调度能力和为什么需要两者选一十分重要。虽然有些人可能认为YARN和Mesos大同小异，但并非如此。区别在于用户一开始使用时需求模型的不同。每种模型没有明确地错误，但每种方法会产出不同的长期结果。我认为这就是选择如何使用它们的关键。Ben Hindman和Berkeley AMP实验室在设计Mesos时，与Google设计Omega的团队同期进行，Mesos系统得益于Google的Omega系统设计的经验，构建了一个更好的非单体(两阶段)的调度器。

　　当你把如何管理数据中心作为整体来评估时，一方面使用Mesos来管理数据中心的所有资源，另一方面使用YARN来安全的管理Hadoop任务，但它并不具有管理整个数据中心的能力。数据中心运营商倾向于把集群划分为的不同区域(Hadoop集群和非Hadoop集群)来应对这两个场景。

　　在同一个数据中心使用Mesos和YARN，为了受益于资源管理器，目前需要创建两个静态分区。此时意味着当指定资源被Hadoop的YARN管理时，Mesos就无法起作用。这也许过于简化了，尽管这么做确实有效。但本质上，我们是想避免这种情况。

　　项目Myriad介绍

　　这不禁让我们发问：能否让企业和数据中心受益于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中资源)之间架起了一座无缝连接的桥梁。

　　Myriad把YARN和Mesos两者的优势结合起来。通过使用Myriad项目，让Mesos和YARN可以协作，你可以完成一个实时业务。数据分析可以在和运行生产服务的相同硬件上执行。你不再需要面临由静态分区引起的资源*(和低利用率)。资源可以根据业务的需求弹性的伸缩。

　　最后的思考

　　为了确保人们理解这个项目的来源，我认为Mesos和YARN擅长在自己特定的场景下工作，并且都有提升的空间。两者的资源管理器在安全领域都能有所提升;而安全的支持对企业采纳与否至关重要。

　　Mesos需要一个端到端的安全架构，我个人觉得可以使用Kerberos来提供安全支持，但根据个人经验，这样做应该不会简单。对Mesos其他方面的提升同样十分复杂，主要归纳为资源的抢占和撤销。假设一个业务的所有资源已经分配，当业务依赖运行的一个最重要的资源项需要扩容时，甚至这个扩容工作仅需要数十分钟来完成，你仍然会因为缺少资源而无法完成。资源的抢占和撤销就可以解决这个问题。目前，Mesos围绕着这个问题有多种解决方案，但我十分期待Mesos委员会使用Dynamic Reservations和Optimistic (Revocable) Resources Offers来解决这个问题。

　　Myriad作为一种新的技术，让我们把数据中心或云端的所有资源当作一个简单的资源池来使用。正如Hadoop消除数据孤岛之间的壁垒一样，Myriad消除了孤立的集群之间的壁垒。通过Myriad，开发者可以专注于业务依赖的数据和应用程序，而运维团队可以更敏捷地管理他们的计算资源。这为我们专注数据而不被基础设施持续困扰打开了另一扇窗。有了Myriad，存储网络的*和计算与存储之间的协调就成为我们在实现完整的灵活性、敏捷和伸缩上的最后一个需要攻克的难题。