> 来源：http://www.infoq.com/cn/articles/analyse-mesos-part-05  包括技术考量在内，我同样对Mesos项目本身的进展颇为兴奋。所以，我想从以技术为重点的文章中走出，做些关于Mesos项目的总体观察。正如我此前在推文中所说的，我对Mesos一直颇具深刻印象的是它的三个特点： 1. 让人清楚地理解它的好处 2. 易于管控的作用域 3. 没有第二家厂商的实现 借此机会，我要说下近来大家对Mesos的认识，我发现人们已经非常容易掌握Mesos的概念，并了解其技术的价值。这对于正在发展并寻求扩大其覆盖面的项目来说是至关重要的。一个项目中的技术所带来的切实利益是非常重要的，它能让人心生向往并积极参与在社区中。 正如[本系列第二篇文章](http://www.infoq.com/cn/articles/analyse-mesos-part-02)中所述，我看到了在效率、商业敏捷性和可扩展性等方面，Mesos带给数据中心的很清晰的好处。随着分布式应用程序和微服务的流行，越来越多的用户正在寻找一种技术，以帮助他们管理这些复杂的应用程序。因此，我们看到越来越多的人在关注着Mesos项目和[Mesosphere](https://mesosphere.com/)，Mesosphere是一家基于Mesos来构建商业产品的公司。 Mesos项目的另一个重要优势是对其作用域的限制。Mesos被设计成一个数据中心资源管理系统，Mesos具备其主要功能，并避免超越设计理念的诱惑，至少在这之前，已经建立了一个坚实的基础。相信Mesos项目已完成了两件重要的事情，使Mesos不会过早迷失于作用域之外。 * 建立了坚实的基础——诱惑是永远存在的，新的技术总是会不断地增加新的功能。当功能驱动开发并以代码的稳定性为代价时，问题随之而来，特别是疏于确保新增加的模块不会破坏已有模块的时候。 Mesos项目已经为此做出了很好的工作，Mesos关注于修复社区中报出的缺陷并加强现有功能，并不鼓励人们不断地追逐闪亮的新事物。 * 构建了强大的生态系统——为了专注于资源管理和控制Mesos架构的规模，该项目启用了插件化的Framework生态系统。在大多数情况下，Mesos项目避免了为每个应用程序建立一个调度器或者严格限定一个隔离模块。这使得不同的社区可以参与其中，例如Hadoop社区和Docker社区都可以为Mesos开发插件。可以预见Mesos项目的好兆头，因为拥有一个强大的生态系统是其在软件领域成功的必要条件。 在做好培养一个强大生态系统的同时，Mesos项目做到了避免让太多的厂商太早介入。相反，似乎有一个最终用户和厂商合作的极佳组合。这其中的主要原因是因为Mesos是为特定问题，提供解决方案的，而不是像AWS那样针对通用的问题。不管是什么原因，阻止大量厂商的介入以及该项目日趋成熟，使得Mesos社区的成长没有厂商政治干预、利益斗争，以及过度的商业诉求等包袱。我不是说这些挑战就没有，但Mesos至少不是一个基本上由厂商控制的项目，Mesos可以以一个自然的步伐去成长。就像Linux项目，厂商的参与是以匹配客户的兴趣和使用，自然而然地发生的。  正如你所知道的，我很期待Mesos项目的未来，当更多的最终用户走进分布式系统的世界之时，希望可以看到Mesos在数据中心操作系统内核中发挥的价值。同时，我鼓励大家学习和参与进来。David Lester在这篇[采访](https://www.linux.com/news/featured-blogs/200-libby-clark/809568-how-to-get-involved-with-the-apache-mesos-open-source-cloud-project)中讲述了一些与此相关的方法，[David Lester](https://twitter.com/davelester)是Twitter的工程师和开源倡导者。 本系列的后续文章将讲述如何搭建Mesos集群、如何为部署和管理应用程序，集成和编写Framework。同时，我鼓励读者提供反馈，特别是关于如果我打标的地方，如果你发现哪里不对，请反馈给我。我非全知，虚心求教，所以期待读者的校正和启示。我也会在[twitter](https://twitter.com/hui_kenneth)响应你的反馈，请关注 @hui_kenneth。 **查看英文原文：** [APACHE MESOS: OPEN SOURCE COMMUNITY DONE RIGHT](http://cloudarchitectmusings.com/2015/04/13/apache-mesos-open-source-community-done-right/)

> 来源：http://www.infoq.com/cn/articles/analyse-mesos-part-04  Apache Mesos能够成为最优秀的数据中心资源管理器的一个重要功能是面对各种类型的应用，它具备像交警一样的疏导能力。本文将深入Mesos的资源分配内部，探讨Mesos是如何根据客户应用需求，平衡公平资源共享的。在开始之前，如果读者还没有阅读这个系列的前序文章，建议首先阅读它们。第一篇是[Mesos的概述](http://www.infoq.com/cn/articles/analyse-mesos-part-01)，第二篇是[两级架构的说明](http://www.infoq.com/cn/articles/analyse-mesos-part-02)，第三篇是[数据存储和容错](http://www.infoq.com/cn/articles/analyse-mesos-part-03)。 我们将探讨Mesos的资源分配模块，看看它是如何确定将什么样的资源邀约发送给具体哪个Framework，以及在必要时如何回收资源。让我们先来回顾一下Mesos的任务调度过程：  从前面提到的[两级架构的说明](http://www.infoq.com/cn/articles/analyse-mesos-part-02)一文中我们知道，Mesos Master代理任务的调度首先从Slave节点收集有关可用资源的信息，然后以资源邀约的形式，将这些资源提供给注册其上的Framework。 Framework可以根据是否符合任务对资源的约束，选择接受或拒绝资源邀约。一旦资源邀约被接受，Framework将与Master协作调度任务，并在数据中心的相应Slave节点上运行任务。 如何作出资源邀约的决定是由资源分配模块实现的，该模块存在于Master之中。资源分配模块确定Framework接受资源邀约的顺序，与此同时，确保在本性贪婪的Framework之间公平地共享资源。在同质环境中，比如Hadoop集群，使用最多的公平份额分配算法之一是最大最小公平算法（max-min fairness）。[最大最小公平算法](http://en.wikipedia.org/wiki/Max-min_fairness)算法将最小的资源分配最大化，并将其提供给用户，确保每个用户都能获得公平的资源份额，以满足其需求所需的资源；一个简单的例子能够说明其工作原理，请参考[最大最小公平份额算法页面](http://www.ece.rutgers.edu/~marsic/Teaching/CCN/minmax-fairsh.html)的示例1。如前所述，在同质环境下，这通常能够很好地运行。同质环境下的资源需求几乎没有波动，所涉及的资源类型包括CPU、内存、网络带宽和I/O。然而，在跨数据中心调度资源并且是异构的资源需求时，资源分配将会更加困难。例如，当用户A的每个任务需要1核CPU、4GB内存，而用户B的每个任务需要3核CPU、1GB内存时，如何提供合适的公平份额分配策略？当用户A的任务是内存密集型，而用户B的任务是CPU密集型时，如何公平地为其分配一揽子资源？ 因为Mesos是专门管理异构环境中的资源，所以它实现了一个可插拔的资源分配模块架构，将特定部署最适合的分配策略和算法交给用户去实现。例如，用户可以实现加权的最大最小公平性算法，让指定的Framework相对于其它的Framework获得更多的资源。默认情况下，Mesos包括一个严格优先级的资源分配模块和一个改良的公平份额资源分配模块。严格优先级模块实现的算法给定Framework的优先级，使其总是接收并接受足以满足其任务要求的资源邀约。这保证了关键应用在Mesos中限制动态资源份额上的开销，但是会潜在其他Framework饥饿的情况。 由于这些原因，大多数用户默认使用DRF（主导资源公平算法 Dominant Resource Fairness），这是Mesos中更适合异质环境的改良公平份额算法。 DRF和Mesos一样出自Berkeley AMPLab团队，并且作为Mesos的默认资源分配策略实现编码。 读者可以从[此处](https://www.cs.berkeley.edu/~alig/papers/drf.pdf)和[此处](http://www.eecs.berkeley.edu/Pubs/TechRpts/2010/EECS-2010-55.pdfhttp://www.eecs.berkeley.edu/Pubs/TechRpts/2010/EECS-2010-55.pdf)阅读DRF的原始论文。在本文中，我将总结其中要点并提供一些例子，相信这样会更清晰地解读DRF。让我们开始揭秘之旅。 DRF的目标是确保每一个用户，即Mesos中的Framework，在异质环境中能够接收到其最需资源的公平份额。为了掌握DRF，我们需要了解主导资源（dominant resource）和主导份额（dominant share）的概念。Framework的主导资源是其最需的资源类型（CPU、内存等），在资源邀约中以可用资源百分比的形式展示。例如，对于计算密集型的任务，它的Framework的主导资源是CPU，而依赖于在内存中计算的任务，它的Framework的主导资源是内存。因为资源是分配给Framework的，所以DRF会跟踪每个Framework拥有的资源类型的份额百分比；Framework拥有的全部资源类型份额中占最高百分比的就是Framework的主导份额。DRF算法会使用所有已注册的Framework来计算主导份额，以确保每个Framework能接收到其主导资源的公平份额。 概念过于抽象了吧？让我们用一个例子来说明。假设我们有一个资源邀约，包含9核CPU和18GB的内存。Framework 1运行任务需要（1核CPU、4GB内存），Framework 2运行任务需要（3核CPU、1GB内存） Framework 1的每个任务会消耗CPU总数的1/9、内存总数的2/9，因此Framework 1的主导资源是内存。同样，Framework 2的每个任务会CPU总数的1/3、内存总数的1/18，因此Framework 2的主导资源是CPU。DRF会尝试为每个Framework提供等量的主导资源，作为他们的主导份额。在这个例子中，DRF将协同Framework做如下分配：Framework 1有三个任务，总分配为（3核CPU、12GB内存），Framework 2有两个任务，总分配为（6核CPU、2GB内存）。 此时，每个Framework的主导资源（Framework 1的内存和Framework 2的CPU）最终得到相同的主导份额（2/3或67％），这样提供给两个Framework后，将没有足够的可用资源运行其他任务。需要注意的是，如果Framework 1中仅有两个任务需要被运行，那么Framework 2以及其他已注册的Framework将收到的所有剩余的资源。  那么，DRF是怎样计算而产生上述结果的呢？如前所述，DRF分配模块跟踪分配给每个Framework的资源和每个框架的主导份额。每次，DRF以所有Framework中运行的任务中最低的主导份额作为资源邀约发送给Framework。如果有足够的可用资源来运行它的任务，Framework将接受这个邀约。通过前面引述的DRF论文中的示例，我们来贯穿DRF算法的每个步骤。为了简单起见，示例将不考虑短任务完成后，资源被释放回资源池中这一因素，我们假设每个Framework会有无限数量的任务要运行，并认为每个资源邀约都会被接受。 回顾上述示例，假设有一个资源邀约包含9核CPU和18GB内存。Framework 1运行的任务需要（1核CPU、4GB内存），Framework 2运行的任务需要（3核CPU、2GB内存）。Framework 1的任务会消耗CPU总数的1/9、内存总数的2/9，Framework 1的主导资源是内存。同样，Framework 2的每个任务会CPU总数的1/3、内存总数的1/18，Framework 2的主导资源是CPU。  上面表中的每一行提供了以下信息： * Framework chosen——收到最新资源邀约的Framework。 * Resource Shares——给定时间内Framework接受的资源总数，包括CPU和内存，以占资源总量的比例表示。 * Dominant Share（主导份额）——给定时间内Framework主导资源占总份额的比例，以占资源总量的比例表示。 * Dominant Share %（主导份额百分比）——给定时间内Framework主导资源占总份额的百分比，以占资源总量的百分比表示。 * CPU Total Allocation——给定时间内接受的所有Framework的总CPU资源。 * RAM Total Allocation——给定时间内接受的所有Framework的总内存资源。 注意，每个行中的最低主导份额以粗体字显示，以便查找。 最初，两个Framework的主导份额是0％，我们假设DRF首先选择的是Framework 2，当然我们也可以假设Framework 1，但是最终的结果是一样的。 1. Framework 2接收份额并运行任务，使其主导资源成为CPU，主导份额增加至33％。 2. 由于Framework 1的主导份额维持在0％，它接收共享并运行任务，主导份额的主导资源（内存）增加至22％。 3. 由于Framework 1仍具有较低的主导份额，它接收下一个共享并运行任务，增加其主导份额至44％。 4. 然后DRF将资源邀约发送给Framework 2，因为它现在拥有更低的主导份额。 5. 该过程继续进行，直到由于缺乏可用资源，不能运行新的任务。在这种情况下，CPU资源已经饱和。 6. 然后该过程将使用一组新的资源邀约重复进行。 需要注意的是，可以创建一个资源分配模块，使用加权的DRF使其偏向某个Framework或某组Framework。如前面所提到的，也可以创建一些自定义模块来提供组织特定的分配策略。 一般情况下，现在大多数的任务是短暂的，Mesos能够等待任务完成并重新分配资源。然而，集群上也可以跑长时间运行的任务，这些任务用于处理挂起作业或行为不当的Framework。 值得注意的是，在当资源释放的速度不够快的情况下，资源分配模块具有撤销任务的能力。Mesos尝试如此撤销任务：向执行器发送请求结束指定的任务，并给出一个宽限期让执行器清理该任务。如果执行器不响应请求，分配模块就结束该执行器及其上的所有任务。 分配策略可以实现为，通过提供与Framework相关的保证配置，来阻止对指定任务的撤销。如果Framework低于保证配置，Mesos将不能结束该Framework的任务。 我们还需了解更多关于Mesos资源分配的知识，但是我将戛然而止。接下来，我要说点不同的东西，是关于Mesos社区的。我相信这是一个值得考虑的重要话题，因为开源不仅包括技术，还包括社区。 说完社区，我将会写一些关于Mesos的安装和Framework的创建和使用的，逐步指导的教程。在一番实操教学的文章之后，我会回来做一些更深入的话题，比如Framework与Master是如何互动的，Mesos如何跨多个数据中心工作等。 与往常一样，我鼓励读者提供反馈，特别是关于如果我打标的地方，如果你发现哪里不对，请反馈给我。我非全知，虚心求教，所以非常期待读者的校正和启示。我们也可以在[twitter](https://twitter.com/hui_kenneth)上沟通，请关注 @hui_kenneth。 **查看英文原文：** [PLAYING TRAFFIC COP: RESOURCE ALLOCATION IN APACHE MESOS](http://cloudarchitectmusings.com/2015/04/08/playing-traffic-cop-resource-allocation-in-apache-mesos/)

> 来源：http://www.infoq.com/cn/articles/analyse-mesos-part-03 在深入浅出Mesos系列的[第一篇文章](http://www.infoq.com/cn/articles/analyse-mesos-part-01)中，我对相关的技术做了简要概述，在[第二篇](http://www.infoq.com/cn/articles/analyse-mesos-part-02)文章中，我深入介绍了Mesos的架构。完成第二篇文章之后，我本想开始着手写一篇Mesos如何处理资源分配的文章。不过，我收到一些读者的反馈，于是决定在谈资源分配之前，先完成这篇关于Mesos持久化存储和容错的文章。 ## 持久化存储的问题  正如我在前文中讨论过的，使用Mesos的主要好处是可以在同一组计算节点集合上运行多种类型的应用程序（调度以及通过Framework初始化任务）。这些任务使用隔离模块（目前是某些类型的容器技术）从实际节点中抽象出来，以便它们可以根据需要在不同的节点上移动和重新启动。 由此我们会思考一个问题，Mesos是如何处理持久化存储的呢？如果我在运行一个数据库作业，Mesos如何确保当任务被调度时，分配的节点可以访问其所需的数据？如图所示，在Hindman的示例中，使用Hadoop文件系统（HDFS）作为Mesos的持久层，这是HDFS常见的使用方式，也是Mesos的执行器传递分配指定任务的配置数据给Slave经常使用的方式。实际上，Mesos的持久化存储可以使用多种类型的文件系统，HDFS只是其中之一，但也是Mesos最经常使用的，它使得Mesos具备了与高性能计算的亲缘关系。其实Mesos可以有多种选择来处理持久化存储的问题： * **分布式文件系统**。如上所述，Mesos可以使用DFS（比如HDFS或者Lustre）来保证数据可以被Mesos集群中的每个节点访问。这种方式的缺点是会有网络延迟，对于某些应用程序来说，这样的网络文件系统或许并不适合。 * **使用数据存储复制的本地文件系统**。另一种方法是利用应用程序级别的复制来确保数据可被多个节点访问。提供数据存储复制的应用程序可以是NoSQL数据库，比如Cassandra和MongoDB。这种方式的优点是不再需要考虑网络延迟问题。缺点是必须配置Mesos，使特定的任务只运行在持有复制数据的节点上，因为你不会希望数据中心的所有节点都复制相同的数据。为此，可以使用一个Framework，静态地为其预留特定的节点作为复制数据的存储。  * **不使用复制的本地文件系统**。也可以将持久化数据存储在指定节点的文件系统上，并且将该节点预留给指定的应用程序。和前面的选择一样，可以静态地为指定应用程序预留节点，但此时只能预留给单个节点而不是节点集合。后面两种显然不是理想的选择，因为实质上都需要创建静态分区。然而，在不允许延时或者应用程序不能复制它的数据存储等特殊情况下，我们需要这样的选择。 Mesos项目还在发展中，它会定期增加新功能。现在我已经发现了两个可以帮助解决持久化存储问题的新特性： * **动态预留**。Framework可以使用这个功能框架保留指定的资源，比如持久化存储，以便在需要启动另一个任务时，资源邀约只会发送给那个Framework。这可以在单节点和节点集合中结合使用Framework配置，访问永久化数据存储。关于这个建议的功能的更多信息可以从[此处](https://issues.apache.org/jira/browse/MESOS-2018)获得。 * **持久化卷**。该功能可以创建一个卷，作为Slave节点上任务的一部分被启动，即使在任务完成后其持久化依然存在。Mesos为需要访问相同的数据后续任务，提供在可以访问该持久化卷的节点集合上相同的Framework来初始化。关于这个建议的功能的更多信息可以从[此处](https://issues.apache.org/jira/browse/MESOS-1554)获得。 ## 容错 接下来，我们来谈谈Mesos在其协议栈上是如何提供容错能力的。恕我直言，Mesos的优势之一便是将容错设计到架构之中，并以可扩展的分布式系统的方式来实现。 * **Master**。故障处理机制和特定的架构设计实现了Master的容错。  首先，Mesos决定使用热备份（hot-standby）设计来实现Master节点集合。正如Tomas Barton对上图的说明，一个Master节点与多个备用（standby）节点运行在同一集群中，并由开源软件Zookeeper来监控。Zookeeper会监控Master集群中所有的节点，并在Master节点发生故障时管理新Master的选举。建议的节点总数是5个，实际上，生产环境至少需要3个Master节点。 Mesos决定将Master设计为持有软件状态，这意味着当Master节点发生故障时，其状态可以很快地在新选举的Master节点上重建。 Mesos的状态信息实际上驻留在Framework调度器和Slave节点集合之中。当一个新的Master当选后，Zookeeper会通知Framework和选举后的Slave节点集合，以便使其在新的Master上注册。彼时，新的 Master可以根据Framework和Slave节点集合发送过来的信息，重建内部状态。 * **Framework调度器**。Framework调度器的容错是通过Framework将调度器注册2份或者更多份到Master来实现。当一个调度器发生故障时，Master会通知另一个调度来接管。需要注意的是Framework自身负责实现调度器之间共享状态的机制。 * **Slave**。Mesos实现了Slave的恢复功能，当Slave节点上的进程失败时，可以让执行器/任务继续运行，并为那个Slave进程重新连接那台Slave节点上运行的执行器/任务。当任务执行时，Slave会将任务的监测点元数据存入本地磁盘。如果Slave进程失败，任务会继续运行，当Master重新启动Slave进程后，因为此时没有可以响应的消息，所以重新启动的Slave进程会使用检查点数据来恢复状态，并重新与执行器/任务连接。 如下情况则截然不同，计算节点上Slave正常运行而任务执行失败。在此，Master负责监控所有Slave节点的状态。  当计算节点/Slave节点无法响应多个连续的消息后，Master会从可用资源的列表中删除该节点，并会尝试关闭该节点。  然后，Master会向分配任务的Framework调度器汇报执行器/任务失败，并允许调度器根据其配置策略做任务失败处理。通常情况下，Framework会重新启动任务到新的Slave节点，假设它接收并接受来自Master的相应的资源邀约。 * **执行器/任务**。与计算节点/Slave节点故障类似，Master会向分配任务的Framework调度器汇报执行器/任务失败，并允许调度器根据其配置策略在任务失败时做出相应的处理。通常情况下，Framework在接收并接受来自Master的相应的资源邀约后，会在新的Slave节点上重新启动任务。 ## 结论 在接下来的文章中，我将更深入到资源分配模块。同时，我非常期待读者的反馈，特别是关于如果我打标的地方，如果你发现哪里不对，请反馈给我。我非全知，虚心求教，所以期待读者的校正和启示。我也会在[twitter](https://twitter.com/hui_kenneth)响应你的反馈，请关注 @hui_kenneth。 **查看英文原文：** [DEALING WITH PERSISTENT STORAGE AND FAULT TOLERANCE IN APACHE MESOS](http://cloudarchitectmusings.com/2015/03/31/dealing-with-persistent-storage-and-fault-tolerance-in-apache-mesos/)

> 来源：http://www.infoq.com/cn/articles/analyse-mesos-part-02 在本系列的[第一篇文章](http://www.infoq.com/cn/articles/analyse-mesos-part-01)中，我简单介绍了Apache Mesos的背景、架构，以及它在数据中心资源管理中的价值。本篇文章将深入剖析Mesos的技术细节和组件间的流程，以便大家更好地理解为什么Mesos是数据中心操作系统内核的重要候选者。文中所述的大部分技术细节都来自[Ben Hindman](https://twitter.com/benh)团队2010年在加州大学伯克利分校时发表的[白皮书](http://mesos.berkeley.edu/mesos_tech_report.pdf)。 顺便说一句，Hindman已经离开Twitter去了[Mesosphere](http://mesosphere.com/)，着手建设并商业化以Mesos为核心的[数据中心操作系统](http://mesosphere.com/product/)。在此，我将重点放在提炼白皮书的主要观点上，然后给出一些我对相关技术所产生的价值的思考。 ## Mesos流程 接着上一篇文章说。并结合前述的加州大学伯克利分校的白皮书以及[Apache Mesos网站](http://mesos.apache.org/documentation/latest/mesos-architecture/)，开始我们的讲述：  我们来研究下上图的事件流程。上一篇谈到，Slave是运行在物理或虚拟服务器上的Mesos守护进程，是Mesos集群的一部分。Framework由调度器（Scheduler）应用程序和任务执行器（Executor）组成，被注册到Mesos以使用Mesos集群中的资源。 * Slave 1向Master汇报其空闲资源：4个CPU、4GB内存。然后，Master触发分配策略模块，得到的反馈是Framework 1要请求全部可用资源。 * Master向Framework 1发送资源邀约，描述了Slave 1上的可用资源。 * Framework的调度器（Scheduler）响应Master，需要在Slave上运行两个任务，第一个任务分配资源，第二个任务分配资源。 * 最后，Master向Slave下发任务，分配适当的资源给Framework的任务执行器（Executor）,接下来由执行器启动这两个任务（如图中虚线框所示）。 此时，还有1个CPU和1GB的RAM尚未分配，因此分配模块可以将这些资源供给Framework 2。 ## 资源分配 为了实现在同一组Slave节点集合上运行多任务这一目标，Mesos使用了隔离模块， 该模块使用了一些应用和进程隔离机制来运行这些任务。 不足为奇的是，虽然可以使用虚拟机隔离实现隔离模块，但是Mesos当前模块支持的是容器隔离。 Mesos早在2009年就用上了Linux的容器技术，如cgroups和Solaris Zone，时至今日这些仍然是默认的。 然而，Mesos社区增加了Docker作为运行任务的隔离机制。 不管使用哪种隔离模块，为运行特定应用程序的任务，都需要将执行器全部打包，并在已经为该任务分配资源的Slave服务器上启动。 当任务执行完毕后，容器会被“销毁”，资源会被释放，以便可以执行其他任务。 我们来更深入地研究一下资源邀约和分配策略，因为这对Mesos管理跨多个Framework和应用的资源，是不可或缺的。 我们前面提到资源邀约的概念，即由Master向注册其上的Framework发送资源邀约。 每次资源邀约包含一份Slave节点上可用的CPU、RAM等资源的列表。 Master提供这些资源给它的Framework，是基于分配策略的。分配策略对所有的Framework普遍适用，同时适用于特定的Framework。 Framework可以拒绝资源邀约，如果它不满足要求，若此，资源邀约随即可以发给其他Framework。 由Mesos管理的应用程序通常运行短周期的任务，因此这样可以快速释放资源，缓解Framework的资源饥饿； Slave定期向Master报告其可用资源，以便Master能够不断产生新的资源邀约。 另外，还可以使用诸如此类的技术， 每个Fraamework过滤不满足要求的资源邀约、Master主动废除给定周期内一直没有被接受的邀约。 分配策略有助于Mesos Master判断是否应该把当前可用资源提供给特定的Framework，以及应该提供多少资源。 关于Mesos中使用资源分配以及可插拔的分配模块，实现非常细粒度的资源共享，会单独写一篇文章。 言归正传，Mesos实现了公平共享和严格优先级（这两个概念我会在资源分配那篇讲）分配模块， 确保大部分用例的最佳资源共享。已经实现的新分配模块可以处理大部分之外的用例。 ## 集大成者 现在来回答谈及Mesos时，“那又怎样”的问题。 对于我来说，令人兴奋的是Mesos集四大好处于一身（概述如下），正如我在前一篇文章中所述，我目测Mesos将为下一代数据中心的操作系统内核。 * 效率 - 这是最显而易见的好处，也是Mesos社区和Mesosphere经常津津乐道的。  上图来自Mesosphere网站，描绘出Mesos为效率带来的好处。如今，在大多数数据中心中，服务器的静态分区是常态，即使使用最新的应用程序，如Hadoop。这时常令人担忧的是，当不同的应用程序使用相同的节点时，调度相互冲突，可用资源互相争抢。静态分区本质上是低效的，因为经常会面临，其中一个分区已经资源耗尽，而另一个分区的资源却没有得到充分利用，而且没有什么简单的方法能跨分区集群重新分配资源。使用Mesos资源管理器仲裁不同的调度器，我们将进入动态分区/弹性共享的模式，所有应用程序都可以使用节点的公共池，安全地、最大化地利用资源。 一个经常被引用的例子是Slave节点通常运行Hadoop作业，在Slave空闲阶段，动态分配给他们运行批处理作业，反之亦然。 值得一提的是，这其中的某些环节可以通过虚拟化技术，如VMware vSphere的[分布式资源调度（DRS）](http://wordpress.redirectingat.com/?id=725X1342&site=varchitectthoughts.wordpress.com&xs=1&isjs=1&url=http%3A%2F%2Fwww.vmware.com%2Fproducts%2Fvsphere%2Ffeatures%2Fdrs-dpm&xguid=1d9204bd07663e5f9ea0dd30373503c1&xuuid=2fd1c0d399d172da1ffd0c4fecbff774&xsessid=e67353eeda490b34a26e2fb37a2d7517&xcreo=0&xed=0&sref=http%3A%2F%2Fcloudarchitectmusings.com%2F2015%2F03%2F26%2Fdigging-deeper-into-apache-mesos%2F&xtz=-480)来完成。 然而，Mesos具有更精细的粒度，因为Mesos在应用层而不是机器层分配资源，通过容器而不是整个虚拟机（VM）分配任务。 前者能够为每个应用程序的特殊需求做考量，应用程序的调度器知道最有效地利用资源; 后者能够更好地“装箱”，运行一个任务，没有必要实例化一整个虚拟机，其所需的进程和二进制文件足矣。 * 敏捷 - 与效率和利用率密切相关，这实际上是我认为最重要的好处。 往往，效率解决的是“如何花最少的钱最大化数据中心的资源”，而敏捷解决的是“如何快速用上手头的资源。” 正如我和我的同事[Tyler Britten](https://twitter.com/vmtyler)经常指出，IT的存在是帮助企业赚钱和省钱的；那么如何通过技术帮助我们迅速创收，是我们要达到的重要指标。 这意味着要确保关键应用程序不能耗尽所需资源，因为我们无法为应用提供足够的基础设施，特别是在数据中心的其他地方都的资源是收费情况下。 * 可扩展性 - 为可扩展而设计，这是我真心欣赏Mesos架构的地方。 这一重要属性使数据可以指数级增长、分布式应用可以水平扩展。 我们的发展已经远远超出了使用巨大的整体调度器或者限定群集节点数量为64的时代，足矣承载新形式的应用扩张。 Mesos可扩展设计的关键之处是采用两级调度架构。 使用Framework代理任务的实际调度，Master可以用非常轻量级的代码实现，更易于扩展集群发展的规模。 因为Master不必知道所支持的每种类型的应用程序背后复杂的调度逻辑。 此外，由于Master不必为每个任务做调度，因此不会成为容量的性能瓶颈，而这在为每个任务或者虚拟机做调度的整体调度器中经常发生。  * 模块化 - 对我来说，预测任何开源技术的健康发展，很大程度上取决于围绕该项目的生态系统。 我认为Mesos项目前景很好，因为其设计具有包容性，可以将功能插件化，比如分配策略、隔离机制和Framework。将容器技术，比如Docker和Rocket插件化的好处是显而易见。但是我想在此强调的是围绕Framework建设的生态系统。将任务调度委托给Framework应用程序，以及采用插件架构，通过Mesos这样的设计，社区创造了能够让Mesos问鼎数据中心资源管理的生态系统。因为每接入一种新的Framework，Master无需为此编码，Slave模块可以复用，使得在Mesos所支持的宽泛领域中，业务迅速增长。相反，开发者可以专注于他们的应用和Framework的选择。 当前而且还在不断地增长着的Mesos Framework列表参见[此处](http://mesos.apache.org/documentation/latest/mesos-frameworks/)以及下图：  ## 总结 在接下来的文章中，我将更深入到资源分配模块，并解释如何在Mesos栈的各级上实现容错。 同时，我很期待读者的反馈，特别是关于如果我打标的地方，如果你发现哪里不对，请反馈给我。 我也会在[Twitter](https://twitter.com/hui_kenneth)响应你的反馈，请关注 @hui_kenneth。 下一篇是关于Mesos的持久性存储和容错的。 **查看英文原文：** [DIGGING DEEPER INTO APACHE MESOS](http://cloudarchitectmusings.com/2015/03/26/digging-deeper-into-apache-mesos/)

> 来源：http://www.infoq.com/cn/articles/analyse-mesos-part-01 > 【编者按】Mesos是Apache下的开源分布式资源管理框架，它被称为是分布式系统的内核。Mesos最初是由加州大学伯克利分校的AMPLab开发的，后在Twitter得到广泛使用。InfoQ接下来将会策划系列文章来为读者剖析Mesos。本文是整个系列的第一篇，简单介绍了Mesos的背景、历史以及架构。 注：本文翻译自[Cloud Architect Musings](http://cloudarchitectmusings.com/2015/03/23/apache-mesos-the-true-os-for-the-software-defined-data-center/)，InfoQ中文站在获得作者授权的基础上对文章进行了翻译。 * * * 我讨厌“软件定义数据中心（SDDC）”这个词，并不是因为我质疑这个概念，而是我发现很多公司都对这个词有误用，他们甚至直接把这个词拿来套用，并急于把自己定位为下一代数据中心的创新者。具体来说，我认为，在商用x86硬件上运行软件（应用）并不是什么SDDC解决方案，它也不具备虚拟化硬件到资源池的能力。真正的SDDC底层基础架构应该可以从运行于其上的应用程序中抽象出来，并根据应用程序不断变化的需求，动态且自动地分配、重新分配应用程序，然后运行于数据中心的不同组件之中。 这就是为什么我一直兴奋地要在后面介绍Mesos，一个Apache开源项目。为什么我对Mesos如此兴奋？回想x86虚拟化之初对数据中心曾经的承诺：通过增加服务器利用率使其更高效，通过从物理基础架构抽象应用使其更敏捷。虽然收获颇丰，但是以虚拟机为单位，粒度仍不够精细，如果应用程序都过于庞大，那就难以充分实现这一承诺。如今，飞速发展的容器技术、分布式应用程序和微服务技术正悄然改变着我们对数据中心的运行和管理方式。 试想，可否整合数据中心中的所有资源，并将它们放在一个大的虚拟池里，代替单独的物理服务器；然后开放诸如CPU、内存和I/O这些基本资源而不是虚拟机？同样，可否把应用程序拆分成小的、隔离的任务单位，从而根据数据中心应用的需求，从虚拟数据中心池中动态分配任务资源？就像操作系统将PC的处理器和RAM放入资源池，使其可以为不同的进程协调分配和释放资源。进一步讲，我们可以把Mesos作为操作系统内核，然后将数据中心看为PC。这也是正是我想说的：Mesos正在改变数据中心，它让真正的SDDC成为现实。  接下来我先介绍下Mesos的历史。Mesos的起源于Google的数据中心资源管理系统Borg。你可以从WIRED杂志的[这篇文章](http://www.wired.com/2013/03/google-borg-twitter-mesos/)中了解更多关于Borg起源的信息及它对Mesos影响。Twitter从Google的Borg系统中得到启发，然后就开发一个类似的资源管理系统来帮助他们摆脱可怕的“失败之鲸”（译者注：见上图）。后来他们注意到加州大学伯克利分校AMPLab正在开发的名为Mesos的项目，这个项目的负责人是Ben Hindman，Ben是加州大学伯克利分校的博士研究生。后来Ben Hindman加入了Twitter，负责开发和部署Mesos。现在Mesos管理着Twitter超过30,0000台服务器上的应用部署，“失败之鲸”已成往事。其他公司纷至沓来，也部署了Mesos，比如Airbnb（空中食宿网）、eBay（电子港湾）和Netflix。 Mesos是如何让Twitter和Airbnb这样的公司，通过数据中心资源更高效的管理系统，扩展应用的呢？我们从一个相当简单但很优雅的两级调度架构开始说起。 [](https://docs.gechiui.com/gc-content/uploads/sites/kancloud/2015-07-31_55bb125b915a3.jpg) 上图修改自Apache Mesos网站上的图片，如图所示，Mesos实现了两级调度架构，它可以管理多种类型的应用程序。第一级调度是Master的守护进程，管理Mesos集群中所有节点上运行的Slave守护进程。集群由物理服务器或虚拟服务器组成，用于运行应用程序的任务，比如Hadoop和MPI作业。第二级调度由被称作Framework的“组件”组成。Framework包括调度器（Scheduler）和执行器（Executor）进程，其中每个节点上都会运行执行器。Mesos能和不同类型的Framework通信，每种Framework由相应的应用集群管理。上图中只展示了Hadoop和MPI两种类型，其它类型的应用程序也有相应的Framework。 Mesos Master协调全部的Slave，并确定每个节点的可用资源， 聚合计算跨节点的所有可用资源的报告，然后向注册到Master的Framework（作为Master的客户端）发出资源邀约。Framework可以根据应用程序的需求，选择接受或拒绝来自master的资源邀约。一旦接受邀约，Master即协调Framework和Slave，调度参与节点上任务，并在容器中执行，以使多种类型的任务，比如Hadoop和Cassandra，可以在同一个节点上同时运行。 我将在接下来的文章中，详细介绍Mesos的体系结构和工作流。我认为，Mesos使用的两级调度架构以及算法、隔离技术让在同一个节点上运行多种不同类型的应用成为了现实，这才是数据中心的未来。正如我之前所述，这是到目前为止我所见过的，履行SDDC承诺最好的现成技术。 我希望这篇介绍让你受用并吊起你了解Mesos的胃口。接下来，我将带你深入技术细节，教你一些上手方法，还会告诉你如何加入社区。 **查看英文原文：** [APACHE MESOS: THE TRUE OS FOR THE SOFTWARE DEFINED DATA CENTER?](http://cloudarchitectmusings.com/2015/03/23/apache-mesos-the-true-os-for-the-software-defined-data-center/)