(二)：Mesos的体系结构与工作流.pdf

（⼆）：Mesos的体系结构和⼯作流 来源：http://www .infoq .com/cn/articles/analyse-mesos-part-02 在本系列的第⼀篇⽂章中，我简单介绍了Apache Mesos的背景、架构，以及它在数据 中 资源管理中的价值。本篇⽂章将深⼊剖析Mesos的技术细节和组件间的流程，以 便⼤家更好地理解为什么Mesos是数据中 操作系统内核的重要候选者。⽂中所述的 ⼤部分技术细节都来⾃Ben Hindman 团队20 10年在加州⼤学伯克利分校时发表的⽩⽪ 书。 顺便说⼀句，Hindman 已经离开Twitter去了Mesosphere ，着⼿建设并商业化以 Mesos为核 的数据中 操作系统。在此，我将重点放在提炼⽩⽪书的主要观点上， 然后给出⼀些我对相关技术所产⽣的价值的思考。 Mesos流程 接着上⼀篇⽂章说。并结合前述的加州⼤学伯克利分校的⽩⽪书以及Apache Mesos⽹ 站，开始我们的讲述： 我们来研究下上图的事件流程。上⼀篇谈到， lave是运⾏在物理或虚拟服务器上的 Mesos守护进程，是Mesos集群的⼀部分。Framework 由调度器 （cheduler ）应⽤程序 和任务执⾏器 （Executor ）组成，被注册到Mesos 以使⽤Mesos集群中的资源。 lave 1向Master汇报其空闲资源：4个CPU 、4GB 内存。然后，Master触发分配 策略模块，得到的反馈是Framework 1要请求全部可⽤资源。 Master 向Framework 1发送资源邀约，描述了 lave 1上的可⽤资源。 Framework 的调度器 （cheduler ）响应Master ，需要在 lave上运⾏两个任务， 第⼀个任务分配资源，第⼆个任务分配资源。 最后，Master 向 lave下发任务，分配适当的资源给Framework 的任务执⾏器 （Executor ）,接下来由执⾏器启动这两个任务 （如图中虚线框所⽰）。 此时， 还有1个CPU和1GB的RAM 尚未分配，因此分配模块可以将这些资源供给 Framework 2 。 资源分配 为了实现在同⼀组 lave节点集合上运⾏多任务这⼀⽬标，Mesos使⽤了隔离模块， 该 模块使⽤了⼀些应⽤和进程隔离机制来运⾏这些任务。 不⾜为奇的是，虽然可以使⽤ 虚拟机隔离实现隔离模块，但是Mesos当前模块⽀持的是容器隔离。 Mesos早在2009 年就⽤上了Linux的容器技术，如cgroups和 olaris Zone ，时⾄今⽇这些仍然是默认 的。 然⽽，Mesos社区增加了Docker作为运⾏任务的隔离机制。 不管使⽤哪种隔离模 块，为运⾏特定应⽤程序的任务，都需要将执⾏器全部打包，并在已经为该任务分配 资源的 lave服务器上启动。 当任务执⾏完毕后，容器会被“销毁” ，资源会被释放，以 便可以执⾏其他任务。 我们来更深⼊地研究⼀下资源邀约和分配策略，因为这对Mesos管理跨多个Framework 和应⽤的资源，是不可或缺的。 我们前⾯提到资源邀约的概念，即由Master 向注册其 上的Framework发送资源邀约。 每次资源邀约包含⼀份 lave节点上可⽤的CPU 、RAM 等资源的列表。 Master提供这些资源给它的Framework ，是基于分配策略的。分配策 略对所有的Framework普遍适⽤，同时适⽤于特定的Framework 。 Framework可以拒绝 资源邀约，如果它不满⾜要求，若此，资源邀约随即可以发给其他Framework 。 由 Mesos管理的应⽤程序通常运⾏短周期的任务，因此这样可以快速释放资源，缓解 Framework 的资源饥饿； lave定期向Master报告其可⽤资源，以便Master能够不断产 ⽣新的资源邀约。 另外，还可以使⽤诸如此类的技术， 每个Fraamework过滤不满⾜ 要求的资源邀约、Master主动废除给定周期内⼀直没有被接受的邀约。 分配策略有助于Mesos Master判断是否应该把当前可⽤资源提供给特定的Framework ， 以及应该提供多少资源。 关于Mesos中使⽤资源分配以及可插拔的分配模块，实现⾮ 常细粒度的资源共享，会单独写⼀篇⽂章。 ⾔归正传，Mesos实现了公平共享和严格 优先级 （这两个概念我会在资源分配那篇讲）分配模块， 确保⼤部分⽤例的最佳资源 共享。已经实现的新分配模块可以处理⼤部分之外的⽤例