Mesos Architecture
发布于 2015-12-05 11:08:30 | 1042 次阅读 | 评论: 0 | 来源: 网络整理
上图是Mesos的主要部件。 Mesos包括一个 主控 守护进程，用来管理子节点的 被控 守护进程。 同时还包含Mesos 应用（application，下文也称 框架 framework） 负责在 子节点上运行 任务(tasks)。
主控进程 通过 给予各个应用框架来提供资源邀约（resource offers）来提供更细粒度的资源共享能力（资源类型包括CPU，内存……）。每种资源邀约 包含 一个列表<slave ID, resource1: amount1, resource2, amount2, ...>即：被控端ID，资源1：数量，资源2：数量……
主控进程 可根据给定的组织策略 来决定分配给每个应用多少资源，比如：平均分配，或者严格按优先级分配等。
为了支持多样化的策略，主控采用了模块化的架构，这样一来，通过插件机制来添加新的资源分配模块变得很容易。
一个运行在 Mesos 之上的应用框架包含两个组件：调度器 (scheduler)进程和 执行器(executor)进程。
调度器进程 用于从 主控提供的资源里选定使用哪些资源。执行器进程在被控节点启动来执行应用任务（详见App/应用开发指南）。
主控 负责决定给每个应用分配多少资源，而应用框架的调度器才会真正选择使用哪些被分配到的资源。当应用框架接收了分配的资源，它会向Mesos发送一个它希望运行任务的描述信息。然后，Mesos会负责在相应的被控节点上启动任务。
示例：资源分派流程
下图给出了一个例子，展示了一个应用如何被调度来执行任务：
根据上图，看一下图片中的事件：
- 被控端1 报告给 主控，报告内容是它有 4个CPU和4 GB内存可用。然后，主控触发分配策略模块（allocation module），该模块告诉它应该给应用框架1分派所有可用的资源。
- 主控将 被控端1 可以的资源信息通过资源邀约（resource offer）发送至 应用框架1。
- 应用框架1 的 调度进程 发送给主控相应的反馈信息，内容是它会在被控端上运行两个任务，第一个要用“2 CPU，1 GB内存”，第二个要用“1 CPU，2 GB内存”。
- 最后，主控发送任务至被控端1，将其可用资源分配给应用1的执行器。之后，执行器会启动两个相应的任务（在图中显示为点划线边框）。由于被控端还剩余1个CPU和1 GB内存没有被分配，分配模块之后可能会把它们提供给应用框架2。
之后，当任务结束，被控端的资源被释放时，资源调度分派进程会根据新任务来循环执行上面的流程。
通过这样简化的交互接口设计，Mesos集群可以方便的进行横向扩展。而与此同时，每一个运行其上的应用框架也会相互独立，完成各自的演进和升级。
那么，问题来了：如何在Mesos不知道应用框架存在特殊限制条件的前提下满足其限制条件？比如，在Mesos不知道哪个节点存储着应用所需要的数据时，应用框架如何满足数据处理的本地化要求？Mesos的处理方式是让应用直接拒绝（reject）资源邀约。应用会拒绝不满足其限制条件的资源邀约，而只接受满足条件的资源。特别指出的是，我们发现了一种简单的策略，称之为延迟调度（delay scheduling）机制，即应用可以等待一定的时间，来获得存储需要数据的相应节点，从而获得近似优化过的数据本地处理结果。
想了解更多 Mesos架构，可见论文 Mesos的实现技术.