Mesos - 数据中心的操作系统

Mesos的核心理念，或者说愿景，就是成为数据中心的“内核”，类似像单机OS一样，屏蔽硬件，提供多节点资源的统一视图。

Mesos提供两阶段调度，简化来说，Mesos用来管理集群资源，并且向其提供高层级的能接受这些资源来启动任务的“框架”。

Master由zk协调选举产生，master本身不做负载计算。它以资源offer的形式将slave上的资源提供给调度框架，并根据已接受的offer在slave上启动任务，同时，负责任务与调度框架之间的通信。

slave管理单个节点上的资源，可以设定资源策略来适应不同业务优先级。slave管理资源包括CPU/RAM/PORT等，负责执行框架提交的任务。

框架其实包括调度程序和执行程序，调度程序负责决定接受/拒绝offer，执行程序是资源的消费者，运行在slave上，负责运行任务任务。

Mesos支持运行hadoop、spark、storm、samza、Hama（图像处理）、MPI（高性能计算）、存储（HDFS/Tachyon/Cassandra）、Jenkins、Gitlib等，及各种元调度框架，如Marathon、Aurora，使大部分已有程序可以直接运行。

Mesos已原生支持Docker，也支持其他容器格式。

http://mesos.apache.org/documentation/latest/frameworks/

Mesos要求内核版本3.10以上。支持物理机、虚拟机、AWS EC2上运行。

安装比较麻烦，需要自己编译。Mesos母公司提供了一些操作系统的二进制分发包，但是到本文写作日期，还没有公司常用的suse分发，需要自己编译。

编译主要依赖c++11，所以需要GCC4.8.1以上版本，同时需要python2.6开发库，jdk1.6以上，详细可以参考官网getstart中CentOS6.6的安装。

编译时建议新建一个build目录，在这里编译，编译好的软件可以分发复制。

mesos软件包，自带一个configure脚本，可以检查编译环境，缺失依赖包，都会报错。configure –help查看帮助。

mesos-local.sh可以启动本地mesos集群，配合官方的测试框架/mesos/build/src/examples/java/test-framework master:5050，可以查看安装是否成功，下面是其他的一些命令:

和其他常见的产品一样，Mesos也提供Web UI监控，通过

:

启动。

可以监控slave、聚合信息、框架等。

Twitter。Twitter使用mesos较早，整合了storm运行在mesos上，并开发了Aurora调度框架来管理其他的普通服务

Airbnb。Airbnb在mesos上运行Hadoop、Spark、Kafka、Cassandra、Redis等服务来完成数据分析。并开发了Chroanos调度框架。

Hubspot。Hubspot在AWS EC2上运行Mesos，开发了Singularity框架，构建PAAS。

安装编译复杂。官方原生支持的操作系统二进制包太少。

语言太多。作为开发人员和运维人员，我想要知道集群里运行的是什么，在发现代码基问题时，我要能够修复问题。要运行Mesos堆栈，涉及到很多组件：Mesos（C++），Marathon（Scala），Mesos-DNS（Golang）等等。不太容易找到对这么多语言都熟悉的开发人员。

所有调度器都没有很好地针对微服务进行抽象，就像Pod，Service，Namespace的抽象那样。这些很容易实现，但是还没有实现。

https://github.com/mesos/hadoop

Mesos调度器 – JobTracker

Mesos执行器 – TaskTracker

调度器和执行器的配置在conf/mapred-site.xml中，参考README.md

conf/core-site.xml里面可以配置mesos的资源策略，包括物理资源如CPU/RAM/DISK，和逻辑上的，如指定时间内MAP/REDUCE slot的最小数量。

Mesos支持从Hadoop导出metrics到外部监控系统，如CSV文件、Graphite、Cassandra。

Mesos上的hadoop支持role认证、user认证。

http://spark.apache.org/docs/latest/running-on-mesos.html#mesos-run-modes

spark和mesos都出自Berkeley数据分析栈，所以天然就有比较好的结合度。

spark on mesos的资源管理有很多配置项，可以限制spark可以获得最大的CPU核数、粗粒度下每个任务能申请额外CPU核数、内存总量等，参考http://spark.apache.org/docs/latest/running-on-mesos.html#configuration

spark基于mesos的资源管理有两种模式，粗粒度和细粒度。粒度控制通过 SparkConf: conf.set("spark.mesos.coarse", "true")，true为粗粒度。

细粒度：Spark默认将每个人物作为独立的mesos任务运行，也就是说，会和其他框架共享集群资源。这个模式下，Mesos可以弹性的在所有应用间共享集群资源。代价是启动任务时产生更高的额外代价，时间要求严格的业务可能有冲击。

粗粒度：适合长期运行的作业。Mesos节点会预留长期运行的Spark任务所需的资源，并按需把资源分给spark作业。好处就是作业无需额外的消耗来完成Mesos节点上任务的启动。

https://github.com/mesos/storm

配置沿用Storm的YAML格式，必须的配置有：

mesos.executor.uri： 执行器uri

mesos.master.url： Mesos master地址

storm.zookeeper.servers：storm关联的zk

一些可选参数用于限制资源等，如制定每个worker节点的CPU和内存的参数topology.mesos.worker.cpu和topology.mesos.worker.mem.mb，执行器的CPU和内存topology.mesos.executor.cpu、topology.mesos.executor.mem.mb。

目前storm也支持Marathon and Docker的方式运行在mesos上。

mesos支持多种存储：HDFS、Tachyon（以内存为中心的存储系统）、Riak、Canssandra、ElasticSearch等。

元框架是基于mesos的资源管理，承载应用程序运行的中介，负责运行服务、处理故障、重启服务、按需扩容等。

https://github.com/mesosphere/marathon

运行长期服务的框架。支持高可用（服务失败其他机器启动）和弹性扩展，Marathon之上不仅仅可以运行自定义服务，还可以运行Hadoop之类的框架，也可以运行自身。

除了mesos，Marathon还要依赖zk，运行时需指定mesos master和zk

Marathon提供标准命令行、多种语言的客户端，及REST接口，REST接口参考：http://mesosphere.github.io/marathon/docs/generated/api.html

大概分应用、组、部署、订阅、信息和日志几类。

组，是为了使应用便于管理。组可以包含应用或组，组分层，且组可以嵌套，所以可以用相对路径和绝对路径表示。依赖也可以定义在组级别。

http://mesosphere.github.io/marathon/docs/application-groups.html

约束，控制在哪里、如何产生任务，限制特定应用运行的位置，可以用于容错等。

http://mesosphere.github.io/marathon/docs/constraints.html

启动应用时约束条件就会被强制执行，一个约束包括字段、操作符和可选参数。字段是分布在mesos slave或其主机名上的任意属性。操作符有三种：

UNIQUE：指定某字段唯一性，如每个主机上只运行一个任务

CLUSTER：运行在有特定属性的slave上，如果对特殊硬件有区别要求，这就很有用

GROUP BY：在指定rack或datacenter上平均分配

LIKE：基于正则表达式过滤主机

UNLIKE：与LIKE相反，过滤出不符合正则的主机

事件总线，捕捉所有事件，如API请求、扩展，可以集成LB、监控等。

http://mesosphere.github.io/marathon/docs/event-bus.html

可以设置订阅，默认是HTTP回调订阅，发送POST JSON格式事件。事件包括：

API请求：应用CRUD请求

每次任务状态改变的状态更新

框架消息事件：包含字段slaveId、executorId、timestamp

健康检查：健康检查的CURD

部署事件：多种部署成功或失败

产品仓库Artifact Store，分布式应用需要的资源存储位置。类似一个集中仓库，Marathon只会下载一次，支持多种存储框架，如本地文件或HDFS等。

http://mesosphere.github.io/marathon/docs/artifact-store.html

健康检查，Marathon监控应用状态，只要是TASK_RUNNING，就判断他是健康的。

http://mesosphere.github.io/marathon/docs/health-checks.html

应用健康有生命周期判定，下图假设i是请求数、r是运行任务数、h是健康实例数。

Marathon是长期运行服务的支持，Chronos就是定时触发任务的支持。

Chronos基于 ISO8601，可以理解为mesos上的cron功能，同样依赖zk容错，依托mesos执行。

https://github.com/mesos/chronos

Chronos可以与hadoop集成，也可以与docker集成

安装运行可以参考

https://mesos.github.io/chronos/docs/

Chronos同样提供了一套REST API，可以管理和监控job

https://mesos.github.io/chronos/docs/api.html

描述job采用json格式，上面的连接有个样例描述

其中name指定jbo名称、command指定需要运行的命令、schedule指定符合ISO8601标准的执行计划、async指定是否后台运行、epsilon指定启动job的时间间隔，以防Chronos错过调度时间。

Aurora由Twitter开发，也是个很火的元框架。mesos官方文档中，也算在长期服务支撑类中，但其实也支持cron类任务。

http://aurora.apache.org/

Aurora一个job包含多个task副本，一个job是在同一个机器上运行的一个或多个进程。因为mesos只做任务抽象，所以Aurora提供了一个Thermos组件管理单个task中的进程，因为每个task都是运行在沙箱中，thermos今晨可以在这些沙箱间共享状态。Thermos主要分两部分，一个是执行器，负责启动和管理任务，一个是观察期，负责监控后台程序。

http://aurora.apache.org/documentation/latest/user-guide/

Aurora架构包含一个client，一个状态机、一个事件总线及订阅者、存储。

client从状态机获得所有信息，不同组件都通过订阅消息总线来通信。状态机后台是存储支持，持久化不同数据，如任务配置、作业配置、更新进程等，以实现故障转移。

存储采用不可变模式，修改其实都是新建版本。

滚动式更新，Aurora更新任务配置会一批一批的执行，旧配置任务killed，然后拉起新配置的任务。迭代这个过程直到所有更新完毕。过程中会不断进行健康检查，如果一定比例的更新后的任务运行状态变为failed，客户端会触发回滚，所有新配置任务都会销毁，然后恢复旧配置。

Job生命周期，新任务是pending，找到满足条件的机器，状态变为assigned。slave从调度器接收任务的配置，生成执行器，调度器收到确认消息，状态变为starting。任务完成初始化，变为running，Thermos开始运行进程。长时间处于pending和assigned状态，调度器会标记lost，然后重新生成pending任务。正常结束，finished或failed状态，强制终止为killing或restarting。需要释放资源时，非生产作业可能被强制终止，变为PREEMPTING，然后killed。

Aurora的配置，其实就是一个python文件，使用pystachio库指定配置。配置文件必须由.aurora后缀。配置文件里包含三类对象：Process、Task、Job，官方给了一个hello world任务配置的样例http://aurora.apache.org/documentation/latest/tutorial/

Aurora支持cron任务，通过配置job对象的cron_schedule属性识别，cron_collision_policy字段指定当前运行的作业到达下一个作业启动时间时还么有完成时的行为，可以杀死旧作业，或不启动新作业，杀死旧作业是默认行为。还支持失败重试任务。

Mesos-DNS提供基于DNS的服务发现机制，接受DNS请求，回复DNS记录。工作对框架完全透明，只需要使用标准的DNS查询就可以通过名称解析出地址。

https://github.com/mesosphere/mesos-dns

目前支持ANY、A、SRV DNS记录。其他类型的记录都会返回NXDOMIN

Mesos-DNS有两个主要组件。

DNS记录生成器，负责为所有运行的应用程序生成DNS A和SRV记录。周期性的查询master，scan所有运行应用的任务信息，记录任务状态，并用DNS格式保存最新的服务状态。

DNS解析器，解析DNS请求，并响应。模拟普通的DNS服务器的行为。

为了保证无状态化，mesos-dns没有提供健康检查、应用生命周期管理等功能。

安装运行指导参考http://mesosphere.github.io/mesos-dns/docs/

最小化接口，两阶段调度，专注于资源管理，是mesos设计背后体现的理念。这样使mesos核心简洁，且和调度框架解耦，可以独立发展。Mesos架构很简单，主要分为master、slave、框架、通信这几部分。

Master负责给框架提供资源分配，管理任务的生命周期。Mesos通过资源offer的形式完成细粒度的资源分配。Mesos作为资源的中介，利用各种可插拔的策略为框架提供资源。资源offer就是一个资源分配的单元，由一个节点上可用资源组成的向量，代表着每个slave锁提供给某个框架的资源

Slave执行框架下发的任务。并对任务进行隔离，保证资源不多不少的分配。

Slave上的资源通过slave资源和slave属性描述。资源是顾名思义，属性是用来描述slave的特殊信息，比如特殊的硬件、操作系统、网络环境等。属性是键值对，并随着资源offer传递给框架。mesos自身不去理解这些属性，只是每次向框架提供offer时传递，各个框架来实现对这些属性的解析和利用。参考http://mesos.apache.org/documentation/latest/attributes-resources/

资源、属性支持几种类型描述：

scalar : floatValue

floatValue : ( intValue ( "." intValue )? ) | ...

intValue : [0-9]+

range : "[" rangeValue ( "," rangeValue )* "]"

rangeValue : scalar "-" scalar

set : "{" text ( "," text )* "}"

text : [a-zA-Z0-9_/.-]

master会处理名称为cpus、mem、disk、ports关键字的资源，没有cpus和mem资源的slave节点将不会为框架提供服务。

Mesos暂时还不支持GPU资源的调度，但是可以自定义资源类型作为offer一部分提供。

框架管理和运行任务，任务是资源的最终消费者。框架包括框架调度器和执行器。调度器负责协调任务，执行器控制任务执行。执行器可以选择运行单任务，或执行器内启动多进程处理多任务。任务管理，包括生命周期，框架API还提供了和调度器和执行器通信的功能。

Mesos用libprocess实现了一个类HTTP协议支撑组件间的通信。通过通信原语和actor通信模式进行异步通信，且消息不可变。消息采用POST方法，头User-Agent标记为libprocess/…，消息数据存在body，用PB序列化。

Mesos内部有几个主要的API通信：

调度器API：框架调度器和Mesos master进行通信。

执行器API：执行器和mesos slave间通信

内部API：mesos的master和slave间通信

运维API：这是mesos内部唯一一组同步通信。被WEB UI或运维工具消费。

已经一再讲过，mesos是两级调度，资源分配和任务调度是隔离的。Mesos master负责决定分配给每个框架多少资源，任务调度器负责决定如何使用这些资源，这个如何使用，是框架调度器自己按需实现的，也可以选择接受或拒绝offer。也可以理解为，mesos给各个框架提供粗粒度的资源分配，每个框架根据自身特点进行细粒度任务调度。

http://mesos.berkeley.edu/mesos_tech_report.pdf

这种双层调度设计使mesos本身保持简单、易扩展、稳定。资源分配的过程也不需要了解真正的调度何时运行。但是也不是没有缺点：调度器并不了解全局的资源利用率，所以资源分配可能不是全局最优。框架在执行任务对资源有特殊要求，如数据局部性、特殊硬件或安全限制，这些信息mesos并不会知道，只能被动的不断发送offer，等待拒绝或接受，整个流程可能会稍显低效。

一个典型的框架事件通信流程：

1. 框架调度器在Mesos master中进行注册

2. Mesos master从slave获取资源offer，调用分配模块函数去决定将这些资源分配给哪些框架

3. 框架调度器从mesos master处得到资源offer

4. 框架调度器判断当前资源offer是否合适，选择接受并向mesos master返回一个需要在slave上利用这些资源运行的执行器列表，或拒绝offer，等待下一个offer。

5. slave分配所请求的资源并运行任务执行器，任务执行器在slave节点上运行框架下发的任务

6. 框架调度器接收任务运行成功或失败的通知。同时框架调度器继续重复#3和#6

7. 框架从Mesos master注销，这时开始不再接收资源offer。这个步骤是可选的，长期运行的元框架一般没有注销的动作。

Mesos默认算法是DRF（主导资源公平算法 Dominant Resource Fairness）。

DFR算法论文：https://www.cs.berkeley.edu/~alig/papers/drf.pdf

说明白DFR之前要有两个铺垫：

单资源公平算法：很容易定义，如内存平均分配给每个框架

最大-最小资源公平算法：单一资源，但多用户请求量不同，尽可能满足用户所能获得最少资源的最大化，参考http://www.ece.rutgers.edu/~marsic/Teaching/CCN/minmax-fairsh.html

Compute the max-min fair allocation for a set of four sources with demands 2, 2.6, 4, 5 when the resource has a capacity of 10.

Solution: We compute the fair share in several rounds of computation. In the first round, we tentatively divide the resource into four portions of size 2.5. Since this is larger than source 1's demand, this leaves 0.5 left over for the remaining three sources, which we divide evenly among the rest, giving them 2.66... each. This is larger than what source 2 wants, so we have an excess of 0.066..., which we divide evenly among the remaining two sources, giving them 2.5 + 0.66... + 0.033... = 2.7 each. Thus, the fair allocation is: source 1 gets 2, source 2 gets 2.6, sources 3 and 4 get 2.7 each.

这两种算法都不能解决不同质、多个资源的分配，如CPU/RAM/DISK等混合资源。

DFR，将最大-最小公平资源算法在多资源的情况下进行泛化，所占资源在总资源比例最多的资源类型被称为该请求的主导资源。如：总资源 <8 CPU, 5 GB>, 请求 <2 CPU, 1 GB>, 主导资源是max(2/8,1/5)，即CPU。分配过程按最大最小公平算法分配，如，F1主导资源是CPU 20%，F2主导资源是RAM30%，随便挑一个为起始分配（不影响结果），先分配给F2，目前主导资源F1=0%，F2=30%，下次分F1，则F1=20%,F2=30%，按算法，F1目前占用较小，所以还分配给F1。详细可以参考：http://cloudarchitectmusings.com/2015/04/08/playing-traffic-cop-resource-allocation-in-apache-mesos/

DRF有几个好处：

策略可验证：用户无法通过夸大自己的需求获得更多的优势

鼓励资源共享：保证每个用户所能获得的最小资源

单一资源公平：同质单一次元，DRF和最大-最小公平资源算法是等价的

无嫉妒Envy-free：每个用户获得的资源都不比别人的差

瓶颈公平性：某个资源是瓶颈，对于所有主导资源为这个资源的请求，DRF与最大-最小公平资源算法等价

单调性：增加资源或减少用户只会增加剩余用户所获得的资源

帕累托最优：http://baike.baidu.com/view/98065.htm 不可能在不损害其他请求的情况下，单独优化某个请求的资源

Mesos支持加权DRF，通过role和weight把资源做倾斜分配。

长期运行的有状态服务，可能需要资源预留。

资源预留需要使用mesos鉴权机制。在master配置。

资源预留有两种方式

静态预留，为某个特定角色预留，如果没有指定角色，默认华为*角色

动态预留，框架对资源进行预留，这部分资源后续只能分配给同一个框架

资源隔离mesos同样采用插件式方式，slave利用容器来为执行器和任务提供隔离的运行环境。容器API目的是支持不同的容器实现，slave进程启动后，可以指定容器和隔离策略。

mesos自带一个容器实现，也默认支持docker，目前基本都在用docker，就不再展开。

http://mesos.apache.org/documentation/latest/containerizer/

Mesos通过zookeeper实现分布式协调，利用zk的超时机制判断节点是否可用。slave如果不可用，master会通知框架。master不可用，会重新选主。配合mesos健康检查的机制，失联的任务会标记为LOST。

mesos master有Registry机制，使master变的有少量“状态”。Registry保存一个已注册的slave列表，master控制slave的注册、重新注册、删除都写入Registry。这样避免数据不一致，如slave在master故障的时候异常，任务丢失会发送给框架，但是master不知道。

Registry后端实现有几种，内存（测试用）、LevelDB、Replicated Log（MultiPaxos算法）

Mesos监控与管理

Mesos可以以插件模式与Nagios、collectd等工具集成。

监控可以通过HTTP Endpoint获取数据，参考

http://mesos.apache.org/documentation/latest/monitoring/

master信息通过http://

:5050/metrics/snapshot

分Resources、Master、System、Slaves、Frameworks、Tasks、Messages、Event queue、Registrar几类

slave节点信息通过http://

:5051/metrics/snapshot

分Resources、Slave、System、Executors、Tasks、Messages几类。

http://mesos.apache.org/documentation/latest/network-monitoring/

默认并不开启，需要配置开启。需要依赖内核3.6以上版本，依赖内核的network namespace、libnl3、iproute包。

开启后，每个容器得到主机端口的一个子集，进行端口映射，还需要指定给容器分配多少随机端口，最好是2的幂。

通过/monitor/statistics提供信息。根据信息也可以配置特定容器的网络限速。

http://mesos.apache.org/documentation/latest/authorization/

鉴权，通过SASL库实现，包括几种鉴权方式：

框架以授权的角色形式进行注册

框架以授权用户的身份启动任务

授权过的管理员通过shutdown/接入点和HTTP API来关闭框架

授权，通过ACL来实现，每个通过master的请求，mesos master都会检查当前的请求是否经过ACL授权。每个ACL包含目标、动作、对象三部分组成，即“目标”在“对象”上可以执行的“动作”。

对象，支持roles（register_frameworks）和users（run_task）及framework_principals（HTTP接入点）

目标，支持principals，是register_frameworks、run_task中的框架管理员，或shutdown_frameworks的用户名

动作，register_frameworks、run_task，或shutdown_frameworks

ACL规则是按顺序进行匹配，所以多条以第一条为准，如果没有ACL规则与当前请求匹配，则ACLs.permissive将决定当前请求是否授权。

http://mesos.apache.org/documentation/latest/framework-rate-limiting/

mesos上运行多框架时，为防止某个框架过度请求资源，可以限定特定框架的qps限制。

框架超出限制后，会收到FrameworkErrorMessage ，会导致调取器异常退出，调用error（）回调函数，但这一步不会杀死任何任务和调度器本身。如果框架认为master没有处理完全部请求，框架可以选择重启或其他故障恢复机制。

master启动时以--rate_limits参数控制配置文件，文件是JSON格式，包含：

principal：指定哪些框架需要限制

qps：每秒请求个数

capacity：控制mesos master内存队列中指定的principal等待消息个数，如果没指定，默认无穷大。这个值配置需要权衡，太小无法有效利用资源，太大会过多消耗master内存。

aggregate_default_qps and aggregate_default_capacity配置限制其他未特殊指定的框架。

master通过HTTP接入点对外提供每个框架接受和处理的消息个数，frameworks/foo/messages_received and frameworks/foo/messages_processed，要观察是否两个值差异过大，就可能发生异常。

http://mesos.apache.org/documentation/latest/configuration/

分共用配置及master/slave单独的配置，及构建时的配置。

slave节点硬件升级等场景，允许平滑过渡。slave将要维护状态的信息会通知给框架，框架将不再slave启动新任务。mesos等待slavve上的任务结束并通知框架下一批将要进入维护状态的slave。通过撤销指定，框架会根据调度器的实现将任务重新调度到其他节点。slave维护期结束，再次向master发送资源offer，重新成为集群的一份子。

Mesos扩展

Mesos设计了模块化的系统，提供插件化的机制，无需重新编译即可添加mesos内部扩展

http://mesos.apache.org/documentation/latest/modules/

mesos目前支持鉴权模块、隔离器模块、匿名模块（不接受任何回调，只和父进程共同存在）、分配器模块（决定框架资源分配），不提供模块扩展的功能，还可以通过hook的钩子回调方式扩展。

通过--modules=filepath的方式指定模块加载。加载模块过程：

1. 从模块实例中加载包含模块的动态库，这个实例可能是在命令行选项中指定的

2. 确定模块版本的兼容性

3. 以单例模式初始化每个模块

4. 将模块中的引用和实际所使用的函数进行绑定

模块名要唯一，官方推荐java包命名规范来给模块命名。http://docs.oracle.com/javase/tutorial/java/package/namingpkgs.html

模块兼容性信息维护在src/module/manager.cpp，加载时要保证kind version <= Library version <= Mesos version

http://mesos.apache.org/documentation/latest/app-framework-development-guide/

框架语言可以选择 C, C++, Java/Scala, or Python。

一个mesos框架由scheduler, executor, launcher组成。其中executor非必须。可选label的处理和服务发现功能。

javadoc在http://mesos.apache.org/api/latest/java/

继承Scheduler接口，有几个API单独拿出来说一下：

error：这个方法是在一个可恢复的错误产生或调度器和驱动停止工作时调用

resourceOffers：最重要的一个接口，master向框架提供资源offer时调用。调度器可以接受offer并利用offerIds启动任务，也可以拒绝任务。分配器策略有时可以把同一个offer发送给多个框架，这时，第一个使用资源offer启动任务的框架将实际使用这份offer，其他会收到offerRescinded发出的消息

启动器实际就是一个main函数，通过MesosSchedulerDriver来实例化SchedulerDriver，管理调度器的生命周期。

SchedulerDriver接口，有几个API说一下：

join()，等待驱动退出stopped or aborted，可能一直组侧下去。通过返回状态可以知道驱动是正常退出还是异常退出。

launchTasks多个方法，支持单个或批量启动任务。

sendFrameworkMessage：框架向执行器发送消息。

requestResources：向mesos请求资源，资源将提供给调度器

继承Executor接口，其中error和frameworkMessage和调度器语义基本相同。

核心API是launchTask(ExecutorDriver driver, TaskInfo task)。这个函数在调用时会阻塞，在回调完成前，执行器无法执行其他回调函数。如果需要长时间运行任务，最好单独一个线程去运行。

其中，ExecutorDriver 是执行器与mesos的接口，管理执行器生命周期，及与mesos通信。

sendStatusUpdate(TaskStatus status)会向调度器发送状态更新，且会在收到确认消息前不断重试。执行器异常退出，TASK_LOST状态更新会发送给调度器。主要区别sendFrameworkMessage的不会重试。

Mesos内部消息格式都是pb，定义在https://github.com/apache/mesos/blob/master/include/mesos/mesos.proto

基本上可以顾名思义

http://mesos.apache.org/documentation/latest/reconciliation/

Mesos使用actor模型进行通信。所以绝大部分消息语义都是最多一次的。有个例外是任务状态更新，这个消息是至少一次的。

master和调度器驱动在连接断开或重新注册时执行故障检测。这里面涉及两个一致性的协调

offer一致性协调。offer状态不会持久化，所以断开连接后offer会失效，重新注册时会重新生成。

任务一致性协调，这里面又分两种，显式的，调度器将正在执行的task发送给master；隐式的，调度器发送空的任务列表，master将所有他已知的任务状态返回，无法找到的任务状态被更新为TASK_LOST。当出现错误时，必须采用显式的协调方式。不一致时，在每次重新注册时采用一致性调节算法，框架需要保证在指定时间内只能有一个一致性调解在执行，官方给了一个算法：

let start = now()

let remaining = { T in tasks | T is non-terminal }

Perform reconciliation: reconcile(remaining)

Wait for status updates to arrive (use truncated exponential backoff). For each update, note the time of arrival.

let remaining = { T in remaining | T.last_update_arrival() < start }

If remaining is non-empty, go to 3.

资源协调者。框架只为其他框架协调资源。通常就是元框架。

基于负载。根据框架的负载来调节资源的使用。Jenkins on mesos等框架就会根据等待队列的长度来刁杰资源的使用。Marathon和Aurora也可以根据约定自动扩容或缩容。

基于预留。运行时静态预留资源。执行前就获得所有资源，并在框架的整个生命周期都持有。

https://github.com/mesosphere/RENDLER

mesosphere创建的一个mesos网页爬虫框架，可以借鉴来学习框架开发，有多种语言实现。

转载请注明出处：华为云博客 https://portal.hwclouds.com/blogs

边缘数据中心管理 EDCM

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。