26.3　原理与架构

26.3　原理与架构

首先，需要再次强调，Mesos自身只是一个资源调度框架，并非一整套完整的应用管理平台，所以只有Mesos自己是不能干活的。但是基于Mesos，可以比较容易地为各种应用管理框架，或者为中间件平台（作为Mesos的应用）提供分布式运行能力；同时，由于多个框架也可以同时运行在一个Mesos集群中，提高了整体的资源使用效率。

Mesos对自己的定位划分清楚，使得它要完成的任务很明确，其他任务框架也可以很容易地与它进行整合。

26.3.1　架构

图26-4基本架构图来自Mesos官方。

图26-4　Mesos的基本架构

可以看出，Mesos采用了经典的“主-从”（master-slave）架构，其中主节点（管理节点）可以使用ZooKeeper来做HA（高可靠性）。Mesos master服务将运行在主节点上，Mesos slave服务则需要运行在各个计算任务节点上。负责完成具体任务的应用框架（framwork）跟Mesos master进行交互，来申请资源。

26.3.2　基本单元

Mesos中有三个基本的组件：管理服务（master）、任务服务（slave）以及应用框架（framework）。

跟大部分分布式系统中类似，主节点（master）起到管理作用，将看到全局的信息，负责不同应用框架之间的资源调度和逻辑控制。应用框架需要注册到管理服务上才能被使用。用户和应用需要通过主节点提供的API来获取集群状态和操作集群资源。

slave负责汇报本从节点上的资源状态（空闲资源、运行状态等等）给主节点，并负责隔离本地资源来执行主节点分配的具体任务。隔离机制目前包括各种容器机制，包括LXC、Docker等。

应用框架（framework）是实际干活的，包括两个主要组件：

·调度器（scheduler）：注册到主节点，等待分配资源；

·执行器（executor）：在从节点上执行框架指定的任务（框架也可以使用Mesos自带的执行器，包括shell脚本执行器和Docker执行器）。

应用框架可以分两种：一种是对资源的需求，是会扩展的（如Hadoop、Spark等），申请后还可能调整；另一种是对资源需求大小是固定的（如MPI等），一次申请即可。

26.3.3　调度

对于一个资源调度框架来说，最核心的就是调度机制，怎么能快速高效地完成对某个应用框架资源的分配，是核心竞争力所在。最理想情况下（大部分时候都无法实现），最好是能猜到应用的实际需求，实现最大化的资源使用率。

Mesos为了实现尽量优化的调度，采取了两层的调度算法。

1.算法基本过程

调度的基本思路很简单，master先全局调度一大块资源给某个framework，framework自己再实现内部的细粒度调度，决定哪个任务用多少资源。两层调度简化了Mesos master自身的调度过程，通过将复杂的细粒度调度交由framework实现，避免了Mesos master成为性能瓶颈。

调度机制支持插件机制来实现不同的策略。默认是Dominant Resource Fairness（DRF）^[1]。

2.调度过程

调度通过offer发送的方式进行交互。一个offer是一组资源，例如<1 CPU，2 GB Mem>。基本调度过程如下：

1）slave节点会周期性汇报自己可用的资源给master；

2）某个时候，master收到应用框架发来的资源请求，根据调度策略，计算出来一个资源offer给framework；

3）framework收到offer后可以决定要不要，如果接受的话，返回一个描述，说明自己希望如何使用和分配这些资源来运行某些任务（可以说明只希望使用部分资源，则多出来的会被master收回）；

4）最后，master则根据framework答复的具体分配情况发送给slave，以使用framework的executor来按照分配的资源策略执行任务。

具体给出一个例子，某从节点向主节点汇报自己有<4 CPU，8 GB Mem>的空闲资源，同时，主节点看到某个应用框架请求<3 CPU，6 GB Mem>，就创建一个offer<slave#1，4 CPU，8 GB Mem>把满足的资源发给应用框架。应用框架（的调度器）收到offer后觉得可以接受，就回复主节点，并告诉主节点希望运行两个任务：一个占用<1 CPU，2 GB Mem>，另一个占用<2 CPU，4 GB Mem>。主节点收到任务信息后分配任务到从节点上进行运行（实际上是应用框架的执行器来负责执行任务）。任务运行结束后可将资源释放出来。剩余的资源还可以继续分配给其他应用框架或任务。

应用框架在收到offer后，如果offer不满足自己的偏好（例如希望继续使用上次的slave节点），则可以选择拒绝offer，等待master发送新的offer过来。另外，可以通过过滤器机制来加快资源的分配过程。

3.过滤器

framework可以通过过滤器机制告诉master它的资源偏好，比如希望分配过来的offer有哪个资源，或者至少有多少资源等。

过滤器可以避免某些应用资源长期分配不到所需要的资源的情况，加速整个资源分配的交互过程。

4.回收机制

为了避免某些任务长期占用集群中资源，Mesos也支持回收机制。

主节点可以定期回收计算节点上的任务所占用的资源，可以动态调整长期任务和短期任务的分布。

26.3.4　高可用性

从架构上看，最为核心的节点是master节点。除了使用ZooKeeper来解决单点失效问题之外，Mesos的master节点自身还提供了很高的鲁棒性。

Mesos master节点在重启后，可以动态通过slave和framework发来的消息重建内部状态，虽然可能导致一定的时延，但这避免了传统控制节点对数据库的依赖。

当然，为了减少master节点的负载过大，在集群中slave节点数目较多的时候，要避免把各种通知的周期配置得过短。在实践中，可以通过部署多个Mesos集群来保持单个集群的规模不要过大。

[1] DRF算法细节可以参考论文《Dominant Resource Fairness: Fair Allocation of Multiple Resource Types》，其核心思想是对不同类型资源进行多个请求，计算请求的主资源类型，然后根据主资源进行公平分配。

26.3 原理与架构