揭秘你不知道的分布式云计算框架Mesos

Mesos计算框架一个集群管理器,提供了有效的、跨分布式应用或框架的资源隔离和共享,可以运行Hadoop、MPI、Hypertable、Spark。使用ZooKeeper实现容错复制,使用Linux Containers来隔离任务,支持多种资源计划分配。

Mesos中包含四类主要的服务(实际上是一个socket server),它们分别是Mesos Master,Mesos Slave,SchedulerProcess和ExecutorProcess,它们之间通过Protocal Buffer消息进行通信,每种服务内部注册了若干种Protocal Buffer消息处理器,一旦收到某种消息,则会调用相应的消息处理器进行处理。除了以上四种服务之外,Mesos还对外提供了三种可编程组件,分别是 Alloctor、Framework Scheduler和Framework Executor,编写这几个组件必须按照要求实现了几个接口,而这些接口将分别被下图中相邻的服务调用。

大部分人看到以上Mesos架构后,均会认为Framework必须是一个通用的框架,比如MapReduce、Storm、Spark等,而 Mesos Master负责将资源分配给各个框架,而各个框架的Scheduler进一步将资源分配给其内部的各个应用程序。这种观念是错误的,是对Mesos架构 的一种错误解读。

事实上,Framework不仅可以是通用的框架,也可以是像Hadoop的Job或者YARN的Application那样的简单计算任务,也就 是说,Framework并需要一定是一个“Framework”,或者一个长时间运行的服务(比如JobTracker等),也可以是一个短生命周期的 Job或者Application。如果让Framework对应一个Hadoop Job,则可以这样设计Framework Scheduler和Framework Executor:

(1)Framework Scheduler功能

Framework Scheduler负责按照作业的输入数据量,将之分解成若干任务,并为这些任务申请资源、监控这些任务的运行状态,一旦发现某个任务运行失败则重新为之申请资源。

(2)Framework Executor功能

为一个节点上的Map Task或者Reduce Task准备运行环境,包括准备各种jar包、二进制文件,设置必要的环境变量,进行必要的资源隔离,启动Jetty Shuffle以为Reduce Task提供远程数据拷贝服务等,接收来自Framework Scheduler的命令(启动任务、杀死任务等),并执行。

通过上面的介绍可以知道,Framework Scheduler只负责运行一个Hadoop Job,而如果你对YARN比较熟悉,便会发现者正是YARN中的MapReduce ApplicationMaster做的事情,没错,Mesos与YARN的设计架构如此的相近,以至于我们很容易通过修改YARN 的任何一个ApplicationMaster,让它作为一个Framework Scheduler运行在Mesos中。

最近Mesos提供了一个mesos-submit工具(注意,该工具尚不完善),该工具可以让用户的Framework Scheduler运行在任何一个Mesos Slave上,以防止客户端运行过多的Framework Scheduler,这样,Mesos的整个架构和工作流程已经变得与YARN相差无几了。

为了让大家更容易理解Mesos和YARN在架构上的相似性,下面给出了Mesos和YARN的组件对应表:

Mesos中的组件YARN中的组件功能Mesos MasterResource Manager整个集群的资源管理和调度Mesos SlaveNode Manager单个节点的资源管理(资源隔离、汇报等)、任务启动等Framework ExecutorFramework SchedulerApplicationMaster单个应用程序的管理和资源二次调度,基本操作均包括注册、资源申请/获取、资源分配(给内部的任务)等。

既然Mesos和YARN如此的相近,那么我们到底应该使用哪一个呢?或者说,哪一个系统更有前景?

就目前看来,YARN在以下几个方面存在明显优势:(1)人力投入大。目前YARN有专门的公司(hortonwork)维护和开发 (2)知名度高。YARN之前从Hadoop 1.0中演化而来,继承了Hadoop的知名度,且有大量公司和开发人员共享patch。然而,Mesos最大优点的设计简单、容易上手使用,它不像 YARN那样,一个资源的分配过程要涉及到若干个状态机,且每种状态机十几种状态,十几种事件。但稳定性看,两个系统都处于研发和测试阶段,离稳定可用还 有一段距离。

您可能还喜欢:1 Apache Mesos总体架构2 Apache Mesos底层基础库3 Apache Mesos模块间通信架构4 Apache Mesos调度机制5 Apache Mesos的任务状态更新过程分析6 Apache Mesos的任务分配过程分析7 Mesos的Framework与Executor注册过程

时间: 2024-09-30 11:32:09

揭秘你不知道的分布式云计算框架Mesos的相关文章

基于Spark 的抄袭检测云计算框架研究

基于Spark 的抄袭检测云计算框架研究 于海浩 抄袭检测从根本上说是一个文本相似度的计算问题,需要迅速准确的在海量文集中对文本的原创性进行检测,耗费大量时间和资源,是计算密集和数据密集的复杂过程.采用分布式计算是是提高检测效率的有有效手段之一.本文提出了一套基于Spark的分布式抄袭检测云计算框架该框架使用由集群资源管理器Apache Mesos,支持内存驻留的 MapReduce计算框架,分布式 Hadooop 文件系统构成的分布式计算集群.测试结果表明,此框架比Hadooop传统分布式计算

4款开源云计算框架和工具简介

本文讲的是4款开源云计算框架和工具简介,[IT168 资讯]1.Enomalism (http://www.enomaly.com/) 云计算平台.Enomalism 是一个开放源代码项目,它提供了一个功能类似于 EC2 的云计算框架.Enomalism 基于 Linux,同时支持 Xen 和 Kernel Virtual Machine(KVM).Enomalism 提供了一个基于 TurboGears Web 应用程序框架和 Python 的软件栈. 2.Euclyptus (http://

Dubbo分布式服务框架入门(附工程)

版权声明:本文为博主原创文章,转载注明出处http://blog.csdn.net/u013142781 目录(?)[+] 要想了解Dubbo是什么,我们不防先了解它有什么用.  使用场景:比如我想开发一个网上商城项目,这个网上商城呢,比较复杂,分为pc端web管理后台,微信端销售公众号,那么我们分成四个项目,pc端网站,微信端网站,还有一个后台服务项目,接口服务项目. 对数据库的操作的相关接口放到接口服务项目,这些接口的实现放在后台服务项目,pc端网站和微信端网站都依赖接口服务项目,调用后台数

基于Spring-DM实现分布式服务框架(DSF)(一)

经过上篇分析分布式服务框架的blog后,正式对之前的基于OSGi实现分布式服务框架的系列改名(顺便把分布式服务框架改为使用DSF缩写),因为已经决定基于Spring-DM来实现,为什么呢,而且为什么一定要是Spring-DM,而不直接说Spring呢? 今天是Spring-DM 1.0 release的大好日子,,不容易呀,做了这么久,具体怎么样还没来得及细看,不过之前有用过1.0 m2,已经觉得很不错了,相信1.0 release更不会失望. 在我眼里看来,Spring是个很大的东西,其实DS

基于OSGi实现分布式服务框架历程(四)

在这个篇幅中将来分析下这个分布式服务框架的服务的生命周期的管理的问题,在分布式服务框架中,支持服务的动态部署.卸载.升级是很关键的,至于服务的生命周期是否需要做到像OSGi那样的动态通知,在这个篇幅中会进行分析,并最终形成这个分布式服务框架的生命周期模型以及到目前为止的服务架构模型. 先来分析下服务的生命周期是否需要做到像OSGi DS的动态通知,这里以服务组件安装为例稍微的说下OSGi DS服务的生命周期模型,在OSGi DS中,当有新的Service Component安装时,首先会检查其是

基于OSGi实现分布式服务框架历程(二)

在这篇历程中来完成对于JINI的Spike,目标仍然是判断基于JINI实现服务的路由.查找需求的满足度. JINI是由Sun研究院制定的,其目标就是为了实现分布式的服务,所以在很多地方可以看到它和分布式服务框架是有不少重叠之处的,来先看看它对于需求的满足度,最后再来分析做个总结. 1.怎么实现远程的将服务注册到服务中心? 在jini中暂时没有找到远程注册服务到服务中心的方法. jini的服务需要和服务中心部署在同一台机器上,这个倒是可以通过服务管理中心直接将sar格式的服务部署上去,支持服务的动

基于OSGi实现分布式服务框架历程(一)

写完之前的那篇基于OSGi实现服务框架的分析后,决定动手来实现一个基于OSGi的分布式服务框架,而其feature呢,就会遵照之前写的服务框架的要素来实现,根据之前的分析,将这个实现过程分为了三个大的步骤来完成:Spike阶段.实现阶段和测试阶段,Spike阶段用于完成几个关键问题的技术的研究和选型:实现阶段用于完成基于OSGi的分布式服务框架:测试阶段用于判断实现的分布式框架对于应用场景的符合程度.性能的情况. 首先进入Spike阶段,在Spike阶段需要完成服务注册.创建以及服务的proxy

分析分布式服务框架

技术是为需求而服务的,分布式服务框架也同样如此,它不是凭空诞生的,也是因为有这样的需求才会有分布式服务框架这么样的东西诞生,在这篇blog中来详细的分析分布式服务框架诞生的原因(其实也是需要用分布式服务框架的应用场景,这里隐含的意思就是并不是什么应用都需要分布式服务框架的).分布式服务框架需要提供的feature以及实现这些feature可选的技术方案. 其实这篇blog应该写在实现分布式服务框架系列blog之前,:),不废话了,来看为什么会需要分布式服务框架,在一个不断发展的大型应用中,系统的

基于zeromq的高性能分布式RPC框架Zerorpc 性能测试

Zeromq 是基于zeromq.gevent和 msgpack开发的分布式RPC框架zerorpc-python.这个框架简单.易用. 1. 安装zeromq yum -y install zeromq yum install gcc gcc-c++ libuuid-devel python-uuid uuid wget http://download.zeromq.org/zeromq-2.1.9.tar.gz ./configure make make install 2.安装gevent