Mesos架构

Mesos Architecture

上图显示了 Mesos 的主要组成部分。 Mesos 由一个 master daemon 来管理 slave daemon 在每个集群节点上的运行, mesos applications ( 也称为 frameworks )在这些 slaves 上运行 tasks。

Master 使用 Resource Offers 实现跨应用细粒度资源共享,如 cpu、内存、磁盘、网络等。 master 根据指定的策略来决定分配多少资源给 framework ,如公平共享策略,或优先级策略。 为了支持更多样性的策略,master 采用模块化结构,这样就可以方便的通过插件形式来添加新的分配模块。

在 Mesos 上运行的 framework 由两部分组成:一个是 scheduler ,通过注册到 master 来获取集群资源。另一个是在 slave 节点上运行的 executor 进程,它可以执行 framework 的 task 。 Master 决定为每个 framework 提供多少资源, framework 的 scheduler 来选择其中提供的资源。当 framework 同意了提供的资源,它通过 master 将 task发送到提供资源的 slaves 上运行。

资源供给的一个例子

下图描述了一个 Framework 如何通过调度来运行一个 Task

事件流程:

  1. Slave1 向 Master 报告,有4个CPU和4 GB内存可用
  2. Master 发送一个 Resource Offer 给 Framework1 来描述 Slave1 有多少可用资源
  3. FrameWork1 中的 FW Scheduler会答复 Master,我有两个 Task 需要运行在 Slave1,一个 Task 需要<2个cpu,1 gb内存="">,另外一个Task需要<1个cpu,2 gb内存="">
  4. 最后,Master 发送这些 Tasks 给 Slave1。然后,Slave1还有1个CPU和1 GB内存没有使用,所以分配模块可以把这些资源提供给 Framework2

当 Tasks 完成和有新的空闲资源时,Resource Offer 会不断重复这一个过程。 当 Mesos 提供的瘦接口允许其来扩展和允许 frameworks 相对独立的参与进来,一个问题将会出现: 一个 framwork 的限制如何被满足在不被 Mesos 对这些限制所知晓的情况下? 例如, 一个 framework 如何得到数据本地化在不被 Mesos所知晓哪个节点存储着被该 framwork 所需要的数据?Mesos 通过简单的寄予 frameworks 能够拒绝 offers 的能力来回答了这个问题。 一个 framework 将拒绝 不满足其限制要求的 offers 并接受满足其限制要求的 offers. 特殊情况下,我们找到一个简单的策略 delay scheduling, 在该 frameworks 等待 一个限制时间来获取存储输入数据的节点, 并生成接近的优化过得数据点。

+

你也可以从这里了解更多的 Mesos 架构:Mesos技术文档

时间: 2024-10-29 10:46:56

Mesos架构的相关文章

Mesos架构简介

1. 前言 同其他大部分分布式系统一样,Apache Mesos为了简化设计,也是采用了master/slave结构,为了解决master单点故障,将master做得尽可能地轻量级,其上面所有的元数据可以通过各个slave重新注册而进行重构,故很容易通过zookeeper解决该单点故障问题. (什么是apache mesos?参考:<统一资源管理与调度平台(系统)介绍>,本文分析基于Mesos SVN Revision 1327410) 2. Apache mesos中的基本术语解释 (1) 

mesos 集群安装部署规划、准备(1)

一:简介 Mesos诞生于UC Berkeley的一个研究项目,现已成为Apache Incubator中的项目.Mesos计算框架一个集群管理器,提供了有效的.跨分布式应用或框架的资源隔离和共享,可以运行Hadoop.MPI.Hypertable.Spark.使用ZooKeeper实现容错复制,使用Linux Containers来隔离任务,支持多种资源计划分配. 1: 总体架构 Apache Mesos由四个组件组成,分别是Mesos-master,mesos-slave,framework

深入浅出Mesos(五):成功的开源社区

http://www.infoq.com/cn/articles/analyse-mesos-part-05 [编者按]Mesos是Apache下的开源分布式资源管理框架,它被称为是分布式系统的内核.Mesos最初是由加州大学伯克利分校的AMPLab开发的,后在Twitter得到广泛使用.InfoQ接下来将会策划系列文章来为读者剖析Mesos.本文是整个系列的第一篇,简单介绍了Mesos的背景.历史以及架构. 注:本文翻译自Cloud Architect Musings,InfoQ中文站在获得作

使用Mesos和Marathon管理Docker集群

分布式系统是难于理解.设计.构建 和管理的,他们将比单个机器成倍还要多的变量引入到设计中,使应用程序的根源问题更难发现.SLA(服务水平协议)是衡量停机和/或性能下降的标准,大多数现代应用程序有一个期望的弹性SLA水平,通常按"9"的数量增加(如,每月99.9或99.99%可用性).每个额外的9变得越来越难实现. 分布式系统通常是以静态分区,比如Akka/Play. Spark/Hadoop.Storm和 Redis各自分区分组划分.静态分区带来的缺点是增加复杂性,随着机器数量增加,软

深入解析DC/OS 1.8 – 高可靠的微服务及大数据管理平台

深入解析DC/OS 1.8 – 高可靠的微服务及大数据管理平台 大家好,欢迎大家参加这次DC/OS的技术分享. 先做个自我介绍,刘超,Linker Networks首席架构师,Open DC/OS社区贡献者,长期专注于OpenStack, Docker, Mesos等开源软件的企业级应用与产品化. 从事容器方面工作的朋友可能已经听说过DC/OS,往往大家误解DC/OS就是marathon + mesos,其实DC/OS包含很多的组件,DC/OS 1.8九月份发布了,此次分享给大家做一个介绍. 一

分布式方向一周技术动态 2016.05.08

分布式系统实践 1. 使用Basic-Paxos协议的日志同步与恢复 http://oceanbase.org.cn/?p=90 要点: 这篇文章和上期给大家推荐的Hadoop的HA方案有着很多相同的地方, 基本思路就是使用paxos协议来同步数据库的binlog从而实现多个数据库实例的一致性. 同时这篇文章还有后续两篇相关文章, 分别对basic-paxos协议的优化以及在线实现成员变更的算法. 我们之前对paxos协议的应用基本上都限制在了基于zookeeper(基于ZAB一致性协议)的使用

hadoop,spark,Zookeeper,,, 这些名字都是怎么来的呢?

Apache 首先我们要明白,Apache 是一个 http 服务器,而我们熟悉的另一种说法"Apache Hadoop"中的 Apache 则指的是 Apache 软件基金会."Apache"是 Apache 软件基金会中的一个项目. 关于其名字,流传最广的解释是(也是最显而易见的):这个名字来自于一个事实:当Apache在1995年初开发的时候,它是由当时最流行的HTTP服务器NCSA HTTPd 1.3的代码修改而成的,因此是"一个修补的(a pat

大型云原生项目在数字化企业落地过程解密

当前,随着互联网的高速发展,各企业的业务量出现几何级增长趋势.越来越多企业发现,使用传统模式部署及运营的产品越来越难以适应新模式下的要求,运维工作越发难以推进.如何搭建一套能够满足子系统高效调度,系统资源充分利用,同时具有动态调整资源,具备高系统扩展性的应用调度系统,成为摆在各企业面前的一道难题.用友云开发者中心是一个应用全生命周期管理的平台,它的底层基于容器技术,结合DevOps等理念,为用户提供了资源管理.持续集成.应用管理等应用基础服务,同时提供了完备的应用调度服务.现在,开发者中心正用着

Mesos 基本原理与架构

首先,Mesos 是一个资源调度框架,并非一整套完整的应用管理平台,本身是不能干活的.但是它可以比较容易的跟各种应用管理或者中间件平台整合,一起工作,提高资源使用效率. 架构  master-slave 架构,master 使用 zookeeper 来做 HA. master 单独运行在管理节点上,slave 运行在各个计算任务节点上. 各种具体任务的管理平台,即 framework 跟 master 交互,来申请资源. 基本单元 master 负责整体的资源调度和逻辑控制. slave 负责汇