Mesos框架对比:Marathon 和 Aurora

简介: 本文讲的是Mesos框架对比:Marathon 和 Aurora,【编者的话】 Marathon 和 Aurora 都能在 Mesos 集群上调度和运行常驻服务。本文比较了两个框架的不同和优劣。
本文讲的是Mesos框架对比:Marathon 和 Aurora 【编者的话】 Marathon 和 Aurora 都能在 Mesos 集群上调度和运行常驻服务。本文比较了两个框架的不同和优劣。

问题

Marathon  框架和  Aurora  框架都能在  Mesos  集群上调度和运行常驻服务。我的问题是:
  1. 两个框架有哪些不同?我费了半天劲,也没有找到能够很好地解释二者的关键区别的资料。
  2. 任何程序或代码,只要能在 Linux 系统上正常地运行,就能被这些框架调度和运行,这么说对吗? Marathon 的开发者说 Marathon 能够运行“可在 shell 中执行”的任何程序或代码。不过,这话有点空洞,让人琢磨不透,:)

第 1 个解答

声明:我是 Apache Aurora 的副总裁,担任 Twitter 公司 Aurora 团队的技术负责人也差不多五年了。我的观点或许有片面之处,纯属个人观点,与 Twitter 公司或者 Apache 基金会无关。

任何程序或代码,只要能在 Linux 系统上正常地运行,就能被这些框架调度和运行,这么说对吗? Marathon 的开发者说 Marathon 能够运行“可在 shell 中执行”的任何程序或代码。不过,这话有点空洞,让人琢磨不透,:)
完全正确。  Marathon 和 Aurora 框架的本质就是调度集群的资源,执行用户提交的 Shell 代码。

两个框架有哪些不同?我费了半天劲,也没有找到能够很好地解释二者的关键区别的资料。
确实, Aurora 和 Marathon 提供了相似的功能特性,都属于“常驻服务的调度器”。换句话说,用户提交如何运行常驻服务的脚本代码,两个框架将尽全力保证常驻服务的持续运行。

下面粗略地谈谈两个框架的不同,包括每个框架的缺陷。我可以负责任地说,框架的开发者非常了解这些缺陷,正在设法修正。

易用程度

安装 Aurora ,给人感觉好似在拓荒,不容易。 用户要控制和使用 Aurora ,要么使用命令行程序,要么使用某个 thrift 客户端调用 Aurora 对外暴露的 thrift API (正在开发 REST API ,目前还不可用)。 用户会感到犯难,因为他们得使用领域特定语言( DSL )配置 Aurora 。这种做法的好处是方便分享配置的模板和通用模式。

与之相比, Marathon 很容易上手,用户很快就能运行一个 “Hello World”服务。 Marathon 提供非常棒的文档,描述多种环境下如何运行一个服务。Marathon 提供 REST API ,方便用户编写调用 Marathon 的定制工具。 Marathon 使用 JSON 作为配置格式,容易上手,但有为了使用而使用之嫌。

目标用户

Aurora 一直是为大型工程组织而而设计的。 在 Twitter 公司,计算机集群包含数万台机器,几百个工程师在使用它,它也是支撑 Twitter 业务的关键。这势必要求保证集群系统的扩展性、稳定性和安全性。因此,我们只会为 Aurora 添加能够在生产环境中扩展的特性(例如,我们把 Aurora 的 Docker 支持标记为一个 beta 特性,因为 Docker 本身以及 Mesos-Docker 进程都存在需要解决的问题)。 Aurora 还提供了抢占等功能,从而支持在同一个集群中混合部署关键业务服务和原型、实验任务。

很难评价 Marathon 的扩展性。 Marathon 总是很快推出新特性( 例如, 添加 Docker 支持),从实践的角度,感觉太过冒进。这不能总是归因于 Marathon ,其它各层也难逃干系。 Marathon 没有提供抢占的功能。

所有权

重点是搞清楚一个项目的所有权和管治模式。这不仅决定了项目的开放性,更决定了哪些人和哪些公司拥有否定决议的权力。
  • Marathon 的拥有者是 Mesosphere 公司

这是好事还是坏事,不同的人有不同的看法。首先,用户可以付费购买 Marathon 的支持和额外功能;其次, Marathon 项目存在商业销售, Mesosphere 公司的商业利益最终决定该项目的走向。
  • Aurora 的拥有者是 Apache 基金会( ASF )

Aurora 项目采用 ASF 的管治模式,完全由社区驱动。 Aurora 没有付费客户,现在也没有软件商店。

小结  如果你是一个新手,准备在 Mesos 上运行服务,我推荐使用 Marathon ,既容易上手,又方便融入 Mesos 生态系统。如果你准备为公司构建具有战略意义的私有云平台,敬请考虑使用 Aurora ,因为它本就是为此而生,而且已经在实践中得到证明。

第 2 个解答

两个框架我都用过,下面是我的经验总结。

Aurora

[+] 还能调度周期性任务
[+] 细粒度、可扩展、基于文件的配置
[+] 支持命名空间,所以多个环境可以共存
[-] 只读的用户界面,没有官方 API
[~] 文件配置和命令行执行的模式很麻烦(好处是更容易扩充功能集)

Marathon

[+] 很容易安装和使用
[+] 提供用户控制界面和扩展功能的 API (有些 API 功能目前都没包含在用户界面中) 
[+] 监听 API 调用的事件总线
[-] 只能处理常驻任务
[-] 部署-运行-清理三个步骤的区分不是很清晰,必须写在一行脚本里

即使 Aurora 的功能更强,我还是愿意选择使用 Marathon ,因为 Aurora 太复杂,没有用户控制界面,没有提供 API 。

第 3 个解答

我使用 Marathon 的经验更多些。

务虚:
  • 相对而言, Marathon 是经过检验的产品,已经用在 AirBnB 的生产环境中。 Aurora 只是一个处于早期阶段的 Apache 项目。
  • 两个框架都开源且开发活跃。大家既可以请求官方代码库合并自己的贡献,又可以指出官方代码库存在的问题。

务实:
  • Marathon 不能调度批处理任务和轮转任务
  • Marathon ( 0.8.x ) 有友好的用户界面,更好的任务执行状态监控

至于你的第二个问题,用户可以运行任何命令或者 Docker 容器, Mesos 保证了资源的隔离。假定你的机群中 50% 是 CentOS 节点, 50% 是 Ubuntu 节点。如果你请求执行一个任务  apt-get  ,有 50% 的可能会无法执行。 Mesos 和 Marathon 对节点的实际系统一无所知。

第 4 个解答

声明:我只有 Marathon 的使用经验,没用过 Aurora 。  

关于第一个问题:从本质上说, Apache Aurora 相当于 Marathon Chronos ,即它能够调度和执行常驻服务和轮转(批处理)任务。请参考  Aurora 用户指南

关于第二个问题:是的,任何程序或代码都能被两个框架调度和执行能够。目前用 cgroups 和 Docker 运行程序,你也可以 指定自己的容器机制

原文链接:Marathon vs Aurora and their purposes(翻译:柳泉波)

=======================

译者介绍

柳泉波,读书喝茶踢球写程序。

原文发布时间为:2015-05-10
本文作者:bnuhero
本文来自云栖社区合作伙伴DockerOne,了解相关信息可以关注DockerOne。
原文标题:Mesos框架对比:Marathon 和 Aurora
目录
相关文章
|
10月前
|
Kubernetes 网络协议 Java
在Kubernetes上运行Flink应用程序时
【2月更文挑战第27天】在Kubernetes上运行Flink应用程序时
89 10
|
存储 Cloud Native 云计算
Twitter 宣布抛弃 Mesos,全面转向Kubernetes
从最早Mesos“代言人”到如今的全面转向“Kubernetes Native”,Twitter的举动再一次佐证了‘Kuberentes已经成为容器编排事实标准’这一断言。
10569 0
|
分布式计算 大数据 Spark
Hadoop大数据平台实战(05):深入Spark Cluster集群模式YARN vs Mesos vs Standalone vs K8s
Hadoop大数据平台实战(05):Spark Cluster集群模式YARN, Mesos,Standalone和K8s深入对比。监控,调度,监控,安全机制,特性对比,哪个才是最好的Spark集群管理工具。
9571 0
|
缓存 弹性计算 运维
在阿里云上使用Marathon
本文介绍了小博无线目前的线上环境,Mesos+Marathon,是如何做到高可用零宕机的。基于Marathon本身的高可用模式并利用SLB API解决容器启停的平滑切换问题,再结合运维机器人TidyMaid实现了自动伸缩。
5431 0
|
存储 Kubernetes Docker
聊聊调度框架,K8S、Mesos、Swarm 一个都不能少
Swarm、Mesos、和Kubernetes都为各种规模的企业提供了全面的支持,如何选择是好? API 目前找到符合企业自身需求的调度框架比较困难,Docker Swarm、Mesos、Kubernetes三大巨头之间最大的区别在可扩展性方面,Swarm的 Zero To Dev 快速设置功能拥有巨大的优势,Docker API的灵活性让它易于集成,并允许使用其他工具,如定制脚本或编写的自定义接口以及复杂的调度。
2422 0
|
Kubernetes 网络协议 Docker
Swarm Kubernetes Marathon 编排引擎对比剖析
Docker Native Orchestration 基本结构 Docker Engine 1.12 集成了原生的编排引擎,用以替换了之前独立的Docker Swarm项目。Docker原生集群(Swarm)同时包括了(Docker Engine \/ Daemons),这使原生docker可以任意充当集群的管理(manager)或工作(worker)节点角色。
2335 0
|
分布式计算 Apache Spark
|
分布式计算 应用服务中间件 nginx
基于Docker搭建多节点Mesos/Marathon
本文讲的是基于Docker搭建多节点Mesos/Marathon【编者的话】在之前的一篇博客中,我介绍了基于Docker搭建单机版Mesos/Marathon,但是仅仅使用了单个节点。而在这篇博客中,我将介绍基于Docker搭建多节点Mesos/Marathon,开发者可以使用3个节点快速地搭建一个真正的分布式容器集群系统。
3328 0
|
前端开发 测试技术 Apache
MESOS-UI介绍:Apache Mesos的另一种前端选择
本文讲的是MESOS-UI介绍:Apache Mesos的另一种前端选择,【编者的话】Mesos-ui开源啦,有兴趣赶紧试试吧。
1509 0