Mesos Architecture

The above figure shows the main components of Mesos. Mesos consists of a master daemon that manages agent daemons running on each cluster node, and Mesos frameworks that run tasks on these agents.

上面的图形展示了Mesos的主要部件。Mesos由一个管理每个集群节点客户端进程的主进程以及在这些客户端运行任务的Mesos框架组成。

The master enables fine-grained sharing of resources (CPU, RAM, …) across frameworks by making them resource offers. Each resource offer contains a list of <agent ID, resource1: amount1, resource2: amount2, ...> (NOTE: as keyword ‘slave’ is deprecated in favor of ‘agent’, driver-based frameworks will still receive offers with slave ID, whereas frameworks using the v1 HTTP API receive offers with agent ID). The master decides how many resources to offer to each framework according to a given organizational policy, such as fair sharing or strict priority. To support a diverse set of policies, the master employs a modular architecture that makes it easy to add new allocation modules via a plugin mechanism.

master可以在框架之间进行细粒度的资源分配满足它们的资源需求。每个资源需求是由一个列表

A framework running on top of Mesos consists of two components: a scheduler that registers with the master to be offered resources, and an executor process that is launched on agent nodes to run the framework’s tasks (see the App/Framework development guide for more details about framework schedulers and executors). While the master determines how many resources are offered to each framework, the frameworks' schedulers select which of the offered resources to use. When a framework accepts offered resources, it passes to Mesos a description of the tasks it wants to run on them. In turn, Mesos launches the tasks on the corresponding agents.

一个运行在mesos上面的框架由两部门组成：一个用来向master注册并索取资源供应的调度，以及一个运行在代理节点运行框架任务（获取更多信息，请参考App/Framework开发指南）的执行进程。虽然master决定了资源怎么分配给每个框架，每个框架的调度会选择master提供的资源应该怎么来进行使用。当一个框架接受了提供的资源，框架会向mesos传递它想运行在这些资源上面运行任务的描述。反过来，mesos启动对应代理节点的任务。

Example of resource offer

The figure below shows an example of how a framework gets scheduled to run a task.

下面的图片展示了一个框架是如何被调度去运行一个任务。

Let’s walk through the events in the figure.

让我们穿越图片。

Agent 1 reports to the master that it has 4 CPUs and 4 GB of memory free. The master then invokes the allocation policy module, which tells it that framework 1 should be offered all available resources.

代理1向master报告，它有4个CPU和4GB的空闲内存。master这个时候调用分配策略模块，告诉它框架1可以被分配所有可用的资源。

The master sends a resource offer describing what is available on agent 1 to framework 1.
The framework’s scheduler replies to the master with information about two tasks to run on the agent, using <2 CPUs, 1 GB RAM> for the first task, and <1 CPUs, 2 GB RAM> for the second task.

master发送一个资源通知描述了啥可以在代理1上的框架1。框架调度回复master关于两个任务运行的代理信息，使用<2CPU,1GB RAM>用于第一个任务，使用<1CPU,2GB RAM>用于第二个任务。

Finally, the master sends the tasks to the agent, which allocates appropriate resources to the framework’s executor, which in turn launches the two tasks (depicted with dotted-line borders in the figure). Because 1 CPU and 1 GB of RAM are still unallocated, the allocation module may now offer them to framework 2.
In addition, this resource offer process repeats when tasks finish and new resources become free.

最后，master把任务发送给代理，代理分配合适的资源给框架的执行者，执行者接下来执行了两个任务（在图片中用虚线边界进行了描述）。由于1CPU和1GB的内存还是未分配状态，分配模块也许现在会提供给框架2。
另外，这个资源通知过程一直在重复，直到任务结束和新资源变成空闲。

While the thin interface provided by Mesos allows it to scale and allows the frameworks to evolve independently, one question remains: how can the constraints of a framework be satisfied without Mesos knowing about these constraints? For example, how can a framework achieve data locality without Mesos knowing which nodes store the data required by the framework? Mesos answers these questions by simply giving frameworks the ability to reject offers. A framework will reject the offers that do not satisfy its constraints and accept the ones that do. In particular, we have found that a simple policy called delay scheduling, in which frameworks wait for a limited time to acquire nodes storing the input data, yields nearly optimal data locality.

虽然mesos提供的细微的接口允许它进行扩展以及框架可以独立的扩展，有一个问题：如何在mesos没有知道这些限制的情况下，使得框架的限制得到满足？例如，一个框架需要有数据本地化需求，如何在mesos不知道哪些节点存储了这些数据的情况下，使得框架的需求得到满足？mesos的回答很简单，简单的赋予光甲有能力拒绝提供的资源。一个框架会拒绝没有满足限制，接受满足限制的提供。尤其是，我们找到了一个简单的策略叫做延迟调度，框架使用一定的限制时间等待节点装在输入的数据，达到最佳的数据本地化。

You can also read much more about the Mesos architecture in this technical paper.

你可以在科技白皮书阅读关于mesos架构更多的咨询。