听过不少人在讨论 Mesos,然而并不是很明白 Mesos 到底能够解决什么问题,使用场景是怎样的,周伟涛(国内较早一批接触使用 Docker,Mesos 等技术的开发者)用一句话形容它, Mesos 能够管理每台机器的 CPU,内存等资源,让你像操纵单个资源池一样来操纵整个数据中心。

周伟涛,现数人科技(主要产品数人云,基于 Mesos 和 Docker 技术的云操作系统)云平台负责人,曾就职于国际开源解决方案供应商 Red Hat, 红帽认证工程师, Mesos Contributor,高级 Python 开发工程师。 是国内较早一批接触使用Docker,Mesos 等技术的开发者。

Apache Mesos 是一个集群管理器,提供了有效的、跨分布式应用或框架的资源隔离和共享,可以运行 Hadoop、MPI、Hypertable、Spark。

13 个问题带你深入了解 Mesos

(问答来自 OSChina 开源中国社区第 100 期高手问答 —— Apache Mesos)

Q1:对大多数人来说还不知道什么是 Mesos,请介绍下他是干什么的,有什么用,怎么用?

A1:你好, Mesos 在国内的资料目前虽然不多,但是你随便百度,谷歌一下,还是有一些的。这里我想拿一个例子来解释 Mesos,假设某公司需要频繁进行大数据计算,该任务运行时需要 N 多 CPU 和内存,为了满足这个需求,我们有两种思路:

思路一)使用小型机,单机即可为任务提供足够 的资源;

思路二)分布式计算,即提供一批普通配置的机器(计算节点),也就是集群,将计算任务拆分到各机器上计算,然后汇总结果。

思路二是当前正在流行的做法,这种方式的优点不再多说。为了达到思路二的要求,我们需要建立数据中心(集群)。进一步,为了充分利用数据中心(集群)的资源(譬如为不同的任务分配不同资源,按任务优先级分配资源等),我们就需要一个工具来进行整个数据中心资源的管理、分配等, 这个工具就是 Mesos。 与 Mesos 类似的工具还有 YARN.

除此之外, Mesos 不仅为计算任务 Offer 资源, 它也支持运行长时任务(譬如 Web应用)。目前国外好多互联网公司都在使用 Mesos 来作为它们的集群管理工具,这里是一个 Powered by Mesos list:https://mesos.apache.org/documentation/latest/powered-by-mesos/

Q2:我们现在用 Cloudera 这套,能简单介绍下 Mesos 和 Cloudera 的差别吗?

A2:Mesos 的主要目标就是去帮助管理不同框架(或者应用栈)间的集群资源。比如说,有一个业务需要在同一个物理集群上同时运行Hadoop,Storm及 Spark。这种情况下,现有的调度器是无法完成跨框架间的如此细粒度的资源共享的。Hadoop 的 YARN 调度器是一个中央调度器,它可以允许多个框架 运行在一个集群里。

但是,要使用框架特定的算法或者调度策略的话就变得很难了,因为多个框架间只有一种调度算法。比如说,MPI 使用的是组调度算法,而 Spark 用的是延迟调度。它们两个同时运行在一个集群上会导致供求关系的冲突。还有一个办法就是将集群物理拆分成多个小的集群,然后将不同的框架独立地 运行在这些小集群上。再有一个方法就是为每个框架分配一组虚拟机。正如Regola 和 Ducom 所说的,虚拟化被认为是一个性能瓶颈,尤其是在高性能计算 (HPC)系统中。这正是 Mesos 适合的场景——它允许用户跨框架来管理集群资源。

Mesos 是一个双层调度器。在第一层中,Mesos 将一定的资源提供(以容器的形式)给对应的框架。框架在第二层接收到资源后,会运行自己的调度算法来 将任务分配到 Mesos 所提供的这些资源上。和 Hadoop YARN 的这种中央调度器相比,或许它在集群资源使用方面并不是那么高效。但是它带来了灵活性——比如说,多个框架实例可以运行在一个集群里。这是现有的这些调度器都无法实现的。就算是 Hadoop YARN 也只是尽量争取在同一个集群上支持类似 MPI 这样的第三方框架而已。更重要的是,随着新框架的诞生,比如说
Samza 最近就被 LinkedIn 开源出来了——有了 Mesos 这些新框架可以试验性地部署到现有的集群上,和其它的框架和平共处。

Q3:您好,Mesos 有哪些典型的应用场景?看了一些介绍,说是能做 Docker 的编排服务。与 OpenStack 这样的云平台管理物理机 CPU、内存,Cloudera Manager 管理 Hadoop 集群服务有什么区别?

A3:现在 Mesos 的应用场景非常多,譬如

1)Spark on Mesos (这是标配 )

2)Jenkins on Mesos

3)Mesos 做 docker 的编排服务等。

与 OpenStack 相比, 首先,物理机,虚拟机都可以作为 Mesos 的集群节点;其次, 粒度不同, Mesos 的基本计算单元是容器(LXC) , 而 OpenStack 的是 VM(听说现在也支持Docker 容器技术了),前者资源利用率更高;最后,轻量级,Mesos 只负责 Offer 资源给Framework,不负责调度资源。 OpenStack 更贴近于 IaaS 层,而 Mesos 在 IaaS 之上。所以有人称其为 DCOS,或者分布式操作系统。

Q4:各方面边界在哪,有什么优劣势,谢谢。

A4:优点

资源管理策略 Dominant Resource Fairness(DRF)
, 这是 Mesos 的核心,也是我们把Mesos 比作分布式系统 Kernel 的根本原因。通俗讲,Mesos 能够保证集群内的所有用户有平等的机会使用集群内的资源,这里的资源包括 CPU,内存,磁盘等等。很多人拿 Mesos跟 k8s 相比,我对 k8s 了解不深,但是,我认为这两者侧重点不同不能做比较,k8s 只是负责容器编排而不是集群资源管理。不能因为都可以管理 Docker,我们就把它们混为一谈。

轻量级。相对于 YARN,Mesos只负责 Offer 资源给 Framework,不负责调度资源。这样,理论上,我们可以让各种东西使用 Mesos 集群资源,而不像 YARN 只拘泥于 Hadoop,我们需要做的是开发调度器(Mesos Framework)。

提高分布式集群的资源利用率:这是一个 Generic 的优点。从某些方面来说,所有的集群管理工具都是为了提高资源利用率。VM 的出现,催生了 IaaS;容器的出现,催生了 K8s, Mesos 等等。简单讲,同样多的资源,我们利用 IaaS 把它们拆成 VM 与 利用 K8s/Mesos 把它们拆成容器,显然后者的资源利用率更高。(这里我没有讨论安全的问题,我们假设内部子网环境不需要考虑这个。)

缺点

门槛太高。只部署一套 Mesos,你啥都干不了,为了使用它,你需要不同的 Mesos Framework,像 Marathon,Chronos,Spark 等等。或者自己写 Framework 来调度 Mesos给的资源,这让大家望而却步。

目前对 Stateful Service 的支持不够。Mesos 集群目前无法进行数据持久化。0.23 版本增加了 Persistent resource 和 Dynamic reserver,数据持久化问题将得到改善。

脏活累活不会少。Team 在使用 Mesos 前期很乐观,认为搞定了 Mesos,我们的运维同学能轻松很多。然而,根本不是那么回事儿,集群节点的优化,磁盘,网络的设置,等等这些,Mesos 是不会帮你干的。使用初期,运维的工作量不仅没有减轻,反而更重了。Mesos 项目还在紧锣密鼓的开发中,很多功能还不完善。

Q5:我想请教下,如果要做一个云服务平台,Mesos 和 Kubernates 怎么去选型

A5:目前的现状是 Mesos 和 K8s 的生态圈各自都发展的比较好,丢弃哪一个都很吃亏。不如按你个人的喜好,先选择一个投下去先用起来。比如数人云 直接一键部署,这样太方便了。可以快速体验 Mesos 的好处。

这个要看你的具体需求。据我所知, K8s 目前只支持 Docker 而且鲜有生产环境的用例; 而 Mesos 不需要你的应用包到 Docker 里面并且其经历过生产环境的考验。 但是, 反过来, K8s 的社区更加活跃,其正在高速发展中,前景非常好。 当然,上述都不是关键, 一个好用的云平台更多的是要有好的产品理念。 请参考数人云

Q6:对于长时间任务,有没有好的调度器算法或者策略

A6:长任务是依靠马拉松 Marathon 框架,对于 Docker,Mesos + Marathon 基本上是现在最成熟的分布式运行框架。长任务是依靠马拉松 Marathon 框架,对于 Docker,Mesos + Marathon 基本上是现在最成熟的分布式运行框架。

Q7:请问下 Mesos 和 Docker 结合,Mesos 只是能解决资源分配问题对么?

A7:对的,Mesos 负责资源分配,需要有个东东负责 Docker 的任务调度,这样就能将 Docker实例自动下发到集群中运行。这个组件叫马拉松 Marathon。Mesos + Marathon 基本上现在最稳定的 Docker 集群化调度框架

Q8:Mesos 现在可以逐渐应用到生产环境了?

A8:Mesos 早就可以应用到生产环境了, 国外的 Airbnb, Apple, Uber, Twitter,国内的携程,爱奇艺,还有我们公司数人科技都在生产环境使用了 Mesos。 你在这里可以看到使用 Mesos 的列表https://mesos.apache.org/documentation/latest/powered-by-mesos/

Q9:Mesos 和 Zookeeper 有什么关联吗?

A9:Zookeeper 是一个为分布式应用提供一致性服务的软件, 而 Mesos 是一个分布式应用。所以在生产环境,我们需要使用 Zookeeper 来为 Mesos 提供一致性服务。

Q10:Mesos,Swarm,Kubernetes 之间有没有竞争关系?虽然这三家都说互相支持,但是这样做会不会太啰嗦了?

A10:Swarm 与 K8s 有很多交叉。 Mesos 更多的是 Focus 在资源管理上, 只是恰好可以使用 Container 做资源隔离。竞争与否,还需要看社区的走向吧。

Q11:你好,看了看这个框架想请教几个问题:

1.这个框架是否自带日志搜集模块?

2.这个框架能否进行性能统计?

3.这个框架在某个节点资源耗尽时可否自动切换?如果所有节点资源耗尽是否容易崩溃,自恢复能力如何?

4.这个框架可否配置负载均衡?

谢谢:)

A11:

  1. 带日志模块,但是功能比较简单,没有一个全局的展示
  2. 可以进行性能统计
  3. Mesos 是根据当前的集群资源统计来决定给调度器分配多少资源的,资源耗尽只会导致新的应用无法部署,不会影响正在运行的东西。
  4. 可以配置负载均衡。 并且 Mesos 本身也有多 Master 机制

Q12:请问 Mesos 怎样决定分配多少资源?分配的资源什么时候回收?

A12:Mesos 与其它的集群管理工具不同, Mesos 本身不负责分配资源,它只是将当前集群的剩余资源提供给注册到它的调度器,由调度器本身来决定使用多少资源,以及合适释放资源。

Q13:假设集群里有 3 台服务器,每台服务器可用内存 16G,现在调度器要运行一个任务需要24G 内存,那么 Mesos 是把整个集群的 48G 内存当成一个整体来提供,还是会向调度器提供每台服务器剩余的内存,也就是说下面两种情况哪种才是正确的:

1. 调度器先申请节点1的 16G 内存,再申请节点 2 的 8G 内存,用哪个节点的内存完全由调度器控制

2. 调度器一次过申请 24G 内存,由 Mesos 控制具体是用了哪个节点的内存。有可能是每个节点都分配了 8G;也有可能是一个节点 16G,另一个节点 8G

A13:看过 DPark 实现 Mesos 的调度器。你一个任务需要 24G 内存,这个任务就需要拆分才可以调度起来。每个小任务需要 16G 以下的内存。才能通过调度器,调度到具体服务器。 调度器一般都是把任务调度到文件所在的机器上。由调度器控制使用哪里的资源, Mesos 告诉调度器哪些资源可用。

阅读完这 13 个问答,希望可以让你对 Mesos 的认识更深,并用于项目实践,分享更多地经验给 Mesos 爱好者:)

作者:数人云

链接:http://www.jianshu.com/p/ef220ec34b6e

來源:简书

著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。

mesos是什么的更多相关文章

  1. Mesos高可用解决方案剖析

    本文作者王勇桥,80后的IT攻城狮,供职于IBM多年,Mesos和Swarm社区的贡献者.本文是他根据自己对Mesos的高可用(High-Availability)设计方案的了解以及在Mesos社区贡 ...

  2. [系统集成] 部署 mesos-exporter 和 prometheus 监控 mesos task

    前几天我在mesos平台上基于 cadvisor部署了 influxdb 和 grafana,用于监控 mesos 以及 docker app 运行信息,发现这套监控系统不太适合 mesos + do ...

  3. [经验交流] 为 mesos framework 分配资源

    前段时间我在办公网搭建了一套mesos平台,用于docker 集群相关的调研和测试,mesos + marathon + docker 架构运行正常.但是在启用了chronos后,marathon无法 ...

  4. Mesos

    1. 软件定义数据中心 Mesos的二级调度机制: maseos协调每个节点的slave,获取每个节点的机器资源.获取资源后,在相应节点运行framework,在容器中执行任务.从而使得多种类型的服务 ...

  5. mesos 学习笔记1 -- mesos安装和配置

    参考资料: 官方文档:http://mesos.apache.org/documentation 中文翻译:http://mesos.mydoc.io/ GitHub:https://github.c ...

  6. 利用听云Server和听云Network实测Kubernetes和Mesos在高并发下的网络性能

    文章出自:听云博客 随着公司业务的不断增长,我们的应用数量也有了爆发式增长.伴随着应用爆发式的增长,管理的难度也随之加大.如何在业务爆发增长的同时快速完成扩容成了很大的挑战.Docker的横空出世恰巧 ...

  7. mesos+marathon+zookeeper的docker管理集群亲手搭建实例(环境Centos6.8)

    资源:3台centos6.8虚拟机 4cpu 8G内存 ip 10.19.54.111-113 1台centos6.8虚拟机2cpu 8G ip 10.19.53.55 1.System Requir ...

  8. [经验交流] Apache Mesos Docker集群初探

    前言 因工作需要,我对基于Apache Mesos 的 Docker 集群作了一点研究,并搭建了一套环境,以下是资料分享. 1. Apache Mesos概述 Apache Mesos是一款开源群集管 ...

  9. 让spark运行在mesos上 -- 分布式计算系统spark学习(五)

    mesos集群部署参见上篇. 运行在mesos上面和 spark standalone模式的区别是: 1)stand alone 需要自己启动spark master 需要自己启动spark slav ...

  10. mesos框架编译部署

    mesos是什么呢? 一个分布式调度框架,让你编写代码时面对整个集群像面对一台机器那么简单.所有的运行,资源调度都可以由它来帮你搞掂. 1.mesos安装有两种方式: 1)参考官网的getstart, ...

随机推荐

  1. DevOps实战(Docker+Jenkins+Git)

    基于Docker+Jenkins+Git的CI/CD实战 与上一篇随笔:基于 Jenkins+Docker+Git 的CI流程初探 有所不同,该内容更偏向于实际业务的基础需求. 有几点需要注意: 该实 ...

  2. Docker 与 K8S学习笔记(十)—— 容器的端口映射

    我们一般将应用部署在容器里面,而一个服务器上会有许许多多的容器,那么外界该如何访问我们的应用呢?答案是:端口映射. Docker可以将容器对外提供服务的端口映射到host的某个端口上,外网通过此端口访 ...

  3. SNGAN

    目录 概 主要内容 Miyato T., Kataoka T., Koyama M & Yoshida Y. SPECTRAL NORMALIZATION FOR GENERATIVE ADV ...

  4. Stirling's Formula

    目录 Stirling's Formula Keith Conrad. Stirling's Formula. Stirling's Formula \[\lim_{n \rightarrow \in ...

  5. jsoncpp转换字符串

    Json::Value root; ...//root中写入数据 //方法一:转为格式化字符串,里面加了很多空格及换行符 string strJson1 = root.toStyledString() ...

  6. 【jvm】09-full gc分析思路

    [jvm]09-full gc分析思路 欢迎关注b站账号/公众号[六边形战士夏宁],一个要把各项指标拉满的男人.该文章已在github目录收录. 屏幕前的大帅比和大漂亮如果有帮助到你的话请顺手点个赞. ...

  7. Hive on Spark和Spark sql on Hive,你能分的清楚么

    摘要:结构上Hive On Spark和SparkSQL都是一个翻译层,把一个SQL翻译成分布式可执行的Spark程序. 本文分享自华为云社区<Hive on Spark和Spark sql o ...

  8. 【】Kerberos原理--经典对话

    这是MIT(Massachusetts Institute of Technology)为了帮助人们理解Kerberos的原理而写的一篇对话集.里面有两个虚构的人物:Athena和Euripides, ...

  9. 【计项02组01号】Java版图形界面计算器

    Java版图形界面计算器1.0版本 项目分析[1.0] 组成部分 代码结构 (1)窗口的创建 在<JDK 核心 API>中我们提到,创建一个窗口需要使用 JFrame 类.在本实验中,我们 ...

  10. python_接口自动化测试_处理参数替换

    在进行自动化测试时,通常会存在A接口用例的返回值是B接口用例的入参这样的情况 可进行如下方式处理: step1.处理A用例时,在响应结果中提取出该数据的值,并赋给一变量,比如 exeId = res. ...