深入浅出Mesos.docx
《深入浅出Mesos.docx》由会员分享，可在线阅读，更多相关《深入浅出Mesos.docx（21页珍藏版）》请在冰豆网上搜索。
深入浅出Mesos
深入浅出Mesos
（一）为软件定义数据中心而生的操作系统
【编者按】Mesos是Apache下的开源分布式资源管理框架，它被称为是分布式系统的内核。
Mesos最初是由加州大学伯克利分校的AMPLab开发的，后在Twitter得到广泛使用。
InfoQ接下来将会策划系列文章来为读者剖析Mesos。
本文是整个系列的第一篇，简单介绍了Mesos的背景、历史以及架构。
注：
本文翻译自CloudArchitectMusings，InfoQ中文站在获得作者授权的基础上对文章进行了翻译。
我讨厌“软件定义数据中心（SDDC）”这个词，并不是因为我质疑这个概念，而是我发现很多公司都对这个词有误用，他们甚至直接把这个词拿来套用，并急于把自己定位为下一代数据中心的创新者。
具体来说，我认为，在商用x86硬件上运行软件（应用）并不是什么SDDC解决方案，它也不具备虚拟化硬件到资源池的能力。
真正的SDDC底层基础架构应该可以从运行于其上的应用程序中抽象出来，并根据应用程序不断变化的需求，动态且自动地分配、重新分配应用程序，然后运行于数据中心的不同组件之中。
这就是为什么我一直兴奋地要在后面介绍Mesos，一个Apache开源项目。
为什么我对Mesos如此兴奋？
回想x86虚拟化之初对数据中心曾经的承诺：
通过增加服务器利用率使其更高效，通过从物理基础架构抽象应用使其更敏捷。
虽然收获颇丰，但是以虚拟机为单位，粒度仍不够精细，如果应用程序都过于庞大，那就难以充分实现这一承诺。
如今，飞速发展的容器技术、分布式应用程序和微服务技术正悄然改变着我们对数据中心的运行和管理方式。
试想，可否整合数据中心中的所有资源，并将它们放在一个大的虚拟池里，代替单独的物理服务器；然后开放诸如CPU、内存和I/O这些基本资源而不是虚拟机？
同样，可否把应用程序拆分成小的、隔离的任务单位，从而根据数据中心应用的需求，从虚拟数据中心池中动态分配任务资源？
就像操作系统将PC的处理器和RAM放入资源池，使其可以为不同的进程协调分配和释放资源。
进一步讲，我们可以把Mesos作为操作系统内核，然后将数据中心看为PC。
这也是正是我想说的：
Mesos正在改变数据中心，它让真正的SDDC成为现实。
接下来我先介绍下Mesos的历史。
Mesos的起源于Google的数据中心资源管理系统Borg。
你可以从WIRED杂志的这篇文章中了解更多关于Borg起源的信息及它对Mesos影响。
Twitter从Google的Borg系统中得到启发，然后就开发一个类似的资源管理系统来帮助他们摆脱可怕的“失败之鲸”（译者注：
见上图）。
后来他们注意到加州大学伯克利分校AMPLab正在开发的名为Mesos的项目，这个项目的负责人是BenHindman，Ben是加州大学伯克利分校的博士研究生。
后来BenHindman加入了Twitter，负责开发和部署Mesos。
现在Mesos管理着Twitter超过30,0000台服务器上的应用部署，“失败之鲸”已成往事。
其他公司纷至沓来，也部署了Mesos，比如Airbnb（空中食宿网）、eBay（电子港湾）和Netflix。
Mesos是如何让Twitter和Airbnb这样的公司，通过数据中心资源更高效的管理系统，扩展应用的呢？
我们从一个相当简单但很优雅的两级调度架构开始说起。
上图修改自ApacheMesos网站上的图片，如图所示，Mesos实现了两级调度架构，它可以管理多种类型的应用程序。
第一级调度是Master的守护进程，管理Mesos集群中所有节点上运行的Slave守护进程。
集群由物理服务器或虚拟服务器组成，用于运行应用程序的任务，比如Hadoop和MPI作业。
第二级调度由被称作Framework的“组件”组成。
Framework包括调度器（Scheduler）和执行器（Executor）进程，其中每个节点上都会运行执行器。
Mesos能和不同类型的Framework通信，每种Framework由相应的应用集群管理。
上图中只展示了Hadoop和MPI两种类型，其它类型的应用程序也有相应的Framework。
MesosMaster协调全部的Slave，并确定每个节点的可用资源，聚合计算跨节点的所有可用资源的报告，然后向注册到Master的Framework（作为Master的客户端）发出资源邀约。
Framework可以根据应用程序的需求，选择接受或拒绝来自master的资源邀约。
一旦接受邀约，Master即协调Framework和Slave，调度参与节点上任务，并在容器中执行，以使多种类型的任务，比如Hadoop和Cassandra，可以在同一个节点上同时运行。
我将在接下来的文章中，详细介绍Mesos的体系结构和工作流。
我认为，Mesos使用的两级调度架构以及算法、隔离技术让在同一个节点上运行多种不同类型的应用成为了现实，这才是数据中心的未来。
正如我之前所述，这是到目前为止我所见过的，履行SDDC承诺最好的现成技术。
（二）：
Mesos的体系结构和工作流
在本系列的第一篇文章中，我简单介绍了ApacheMesos的背景、架构，以及它在数据中心资源管理中的价值。
本篇文章将深入剖析Mesos的技术细节和组件间的流程，以便大家更好地理解为什么Mesos是数据中心操作系统内核的重要候选者。
文中所述的大部分技术细节都来自BenHindman团队2010年在加州大学伯克利分校时发表的白皮书。
顺便说一句，Hindman已经离开Twitter去了Mesosphere，着手建设并商业化以Mesos为核心的数据中心操作系统。
在此，我将重点放在提炼白皮书的主要观点上，然后给出一些我对相关技术所产生的价值的思考。
1.Mesos流程
我们来研究下上图的事件流程。
上一篇谈到，Slave是运行在物理或虚拟服务器上的Mesos守护进程，是Mesos集群的一部分。
Framework由调度器（Scheduler）应用程序和任务执行器（Executor）组成，被注册到Mesos以使用Mesos集群中的资源。
∙Slave1向Master汇报其空闲资源：
4个CPU、4GB内存。
然后，Master触发分配策略模块，得到的反馈是Framework1要请求全部可用资源。
∙Master向Framework1发送资源邀约，描述了Slave1上的可用资源。
∙Framework的调度器（Scheduler）响应Master，需要在Slave上运行两个任务，第一个任务分配<2CPUs,1GBRAM>资源，第二个任务分配<1CPUs,2GBRAM>资源。
∙最后，Master向Slave下发任务，分配适当的资源给Framework的任务执行器（Executor）,接下来由执行器启动这两个任务（如图中虚线框所示）。
此时，还有1个CPU和1GB的RAM尚未分配，因此分配模块可以将这些资源供给Framework2。
2.资源分配
为了实现在同一组Slave节点集合上运行多任务这一目标，Mesos使用了隔离模块，该模块使用了一些应用和进程隔离机制来运行这些任务。
不足为奇的是，虽然可以使用虚拟机隔离实现隔离模块，但是Mesos当前模块支持的是容器隔离。
Mesos早在2009年就用上了Linux的容器技术，如cgroups和SolarisZone，时至今日这些仍然是默认的。
然而，Mesos社区增加了Docker作为运行任务的隔离机制。
不管使用哪种隔离模块，为运行特定应用程序的任务，都需要将执行器全部打包，并在已经为该任务分配资源的Slave服务器上启动。
当任务执行完毕后，容器会被“销毁”，资源会被释放，以便可以执行其他任务。
我们来更深入地研究一下资源邀约和分配策略，因为这对Mesos管理跨多个Framework和应用的资源，是不可或缺的。
我们前面提到资源邀约的概念，即由Master向注册其上的Framework发送资源邀约。
每次资源邀约包含一份Slave节点上可用的CPU、RAM等资源的列表。
Master提供这些资源给它的Framework，是基于分配策略的。
分配策略对所有的Framework普遍适用，同时适用于特定的Framework。
Framework可以拒绝资源邀约，如果它不满足要求，若此，资源邀约随即可以发给其他Framework。
由Mesos管理的应用程序通常运行短周期的任务，因此这样可以快速释放资源，缓解Framework的资源饥饿；Slave定期向Master报告其可用资源，以便Master能够不断产生新的资源邀约。
另外，还可以使用诸如此类的技术，每个Fraamework过滤不满足要求的资源邀约、Master主动废除给定周期内一直没有被接受的邀约。
分配策略有助于MesosMaster判断是否应该把当前可用资源提供给特定的Framework，以及应该提供多少资源。
关于Mesos中使用资源分配以及可插拔的分配模块，实现非常细粒度的资源共享，会单独写一篇文章。
言归正传，Mesos实现了公平共享和严格优先级（这两个概念我会在资源分配那篇讲）分配模块，确保大部分用例的最佳资源共享。
已经实现的新分配模块可以处理大部分之外的用例。
3.集大成者
现在来回答谈及Mesos时，“那又怎样”的问题。
对于我来说，令人兴奋的是Mesos集四大好处于一身（概述如下），正如我在前一篇文章中所述，我目测Mesos将为下一代数据中心的操作系统内核。
a）效率-这是最显而易见的好处，也是Mesos社区和Mesosphere经常津津乐道的。
上图来自Mesosphere网站，描绘出Mesos为效率带来的好处。
如今，在大多数数据中心中，服务器的静态分区是常态，即使使用最新的应用程序，如Hadoop。
这时常令人担忧的是，当不同的应用程序使用相同的节点时，调度相互冲突，可用资源互相争抢。
静态分区本质上是低效的，因为经常会面临，其中一个分区已经资源耗尽，而另一个分区的资源却没有得到充分利用，而且没有什么简单的方法能跨分区集群重新分配资源。
使用Mesos资源管理器仲裁不同的调度器，我们将进入动态分区/弹性共享的模式，所有应用程序都可以使用节点的公共池，安全地、最大化地利用资源。
一个经常被引用的例子是Slave节点通常运行Hadoop作业，在Slave空闲阶段，动态分配给他们运行批处理作业，反之亦然。
值得一提的是，这其中的某些环节可以通过虚拟化技术，如VMwarevSphere的分布式资源调度（DRS）来完成。
然而，Mesos具有更精细的粒度，因为Mesos在应用层而不是机器层分配资源，通过容器而不是整个虚拟机（VM）分配任务。
前者能够为每个应用程序的特殊需求做考量，应用程序的调度器知道最有效地利用资源;后者能够更好地“装箱”，运行一个任务，没有必要实例化一整个虚拟机，其所需的进程和二进制文件足矣。
b）敏捷-与效率和利用率密切相关，这实际上是我认为最重要的好处。
往往，效率解决的是“如何花最少的钱最大化数据中心的资源”，而敏捷解决的是“如何快速用上手头的资源。
”正如我和我的同事TylerBritten经常指出，IT的存在是帮助企业赚钱和省钱的；那么如何通过技术帮助我们迅速创收，是我们要达到的重要指标。
这意味着要确保关键应用程序不能耗尽所需资源，因为我们无法为应用提供足够的基础设施，特别是在数据中心的其他地方都的资源是收费情况下。
c）可扩展性-为可扩展而设计，这是我真心欣赏Mesos架构的地方。
这一重要属性使数据可以指数级增长、分布式应用可以水平扩展。
我们的发展已经远远超出了使用巨大的整体调度器或者限定群集节点数量为64的时代，足矣承载新形式的应用扩张。
Mesos可扩展设计的关键之处是采用两级调度架构。
使用Framework代理任务的实际调度，Master可以用非常轻量级的代码实现，更易于扩展集群发展的规模。
因为Master不必知道所支持的每种类型的应用程序背后复杂的调度逻辑。
此外，由于Master不必为每个任务做调度，因此不会成为容量的性能瓶颈，而这在为每个任务或者虚拟机做调度的整体调度器中经常发生。
d）模块化-对我来说，预测任何开源技术的健康发展，很大程度上取决于围绕该项目的生态系统。
我认为Mesos项目前景很好，因为其设计具有包容性，可以将功能插件化，比如分配策略、隔离机制和Framework。
将容器技术，比如Docker和Rocket插件化的好处是显而易见。
但是我想在此强调的是围绕Framework建设的生态系统。
将任务调度委托给Framework应用程序，以及采用插件架构，通过Mesos这样的设计，社区创造了能够让Mesos问鼎数据中心资源管理的生态系统。
因为每接入一种新的Framework，Master无需为此编码，Slave模块可以复用，使得在Mesos所支持的宽泛领域中，业务迅速增长。
相反，开发者可以专注于他们的应用和Framework的选择。
当前而且还在不断地增长着的MesosFramework列表参见此处以及下图：
（三）：
持久化存储和容错
正如我在前文中讨论过的，使用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配置，访问永久化数据存储。
关于这个建议的功能的更多信息可以从此处获得。
∙持久化卷。
该功能可以创建一个卷，作为Slave节点上任务的一部分被启动，即使在任务完成后其持久化依然存在。
Mesos为需要访问相同的数据后续任务，提供在可以访问该持久化卷的节点集合上相同的Framework来初始化。
关于这个建议的功能的更多信息可以从此处获得。
接下来，我们来谈谈Mesos在其协议栈上是如何提供容错能力的。
恕我直言，Mesos的优势之一便是将容错设计到架构之中，并以可扩展的分布式系统的方式来实现。
∙Master。
故障处理机制和特定的架构设计实现了Master的容错。
首先，Mesos决定使用热备份（hot-standby）设计来实现Master节点集合。
正如TomasBarton对上图的说明，一个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节点上重新启动任务。
（四）：
Mesos的资源分配
ApacheMesos能够成为最优秀的数据中心资源管理器的一个重要功能是面对各种类型的应用，它具备像交警一样的疏导能力。
本文将深入Mesos的资源分配内部，探讨Mesos是如何根据客户应用需求，平衡公平资源共享的。
我们将探讨Mesos的资源分配模块，看看它是如何确定将什么样的资源邀约发送给具体哪个Framework，以及在必要时如何回收资源。
让我们先来回顾一下Mesos的任务调度过程：
从前面提到的两级架构的说明一文中我们知道，MesosMaster代理任务的调度首先从Slave节点收集有关可用资源的信息，然后以资源邀约的形式，将这些资源提供给注册其上的Framework。
Framework可以根据是否符合任务对资源的约束，选择接受或拒绝资源邀约。
一旦资源邀约被接受，Framework将与Master协作调度任务，并在数据中心的相应Slave节点上运行任务。
如何作出资源邀约的决定是由资源分配模块实现的，该模块存在于Master之中。
资源分配模块确定Framework接受资源邀约的顺序，与此同时，确保在本性贪婪的Framework之间公平地共享资源。
在同质环境中，比如Hadoop集群，使用最多的公平份额分配算法之一是最大最小公平算法（max-minfairness）。
最大最小公平算法算法将最小的资源分配最大化，并将其提供给用户，确保每个用户都能获得公平的资源份额，以满足其需求所需的资源；一个简单的例子能够说明其工作原理，请参考最大最小公平份额算法页面的示例1。
如前所述，在同质环境下，这通常能够很好地运行。
同质环境下的资源需求几乎没有波动，所涉及的资源类型包括CPU、内存、网络带宽和I/O。
然而，在跨数据中心调度资源并且是异构的资源需求时，资源分配将会更加困难。
例如，当用户A的每个任务需要1核CPU、4GB内存，而用户B的每个任务需要3核CPU、1GB内存时，如何提供合适的公平份额分配策略？
当用户A的任务是内存密集型，而用户B的任务是CPU密集型时，如何公平地为其分配一揽子资源？
因为Mesos是专门管理异构环境中的资源，所以它实现了一个可插拔的资源分配模块架构，将特定部署最适合的分配策略和算法交给用户去实现。
例如，用户可以实现加权的最大最小公平性算法，让指定的Framework相对于其它的Framework获得更多的资源。
默认情况下，Mesos包括一个严格优先级的资源分配模块和一个改良的公平份额资源分配模块。
严格优先级模块实现的算法给定Framework的优先级，使其总是接收并接受足以满足其任务要求的资源邀约。
这保证了关键应用在Mesos中限制动态资源份额上的开销，但是会潜在其他Framework饥饿的情况。
由于这些原因，大多数用户默认使用DRF（主导资源公平算法DominantResourceFairness），这是Mesos中更适合异质环境的改良公平份额算法。
DRF和Mesos一样出自BerkeleyAMPLab团队，并且作为Mesos的默认资源分配策略实现编码。
读者可以从此处和此处阅读DRF的原始论文。
在本文中，我将总结其中要点并提供一些例子，相信这样会更清晰地解读DRF。
让我们开始揭秘之旅。
DRF的目标是确保每一个用户，即Mesos中的Framework，在异质环境中能够接收到其最需资源的公平份额。
为了掌握DRF，我们需要了解主导资源（dominantresource）和主导份额（dominantshare）的概念。
Framework的主导资源是其最需的资源类型（CPU、内存等），在资源邀约中以可用资源百分比的形式展示。
例如，对于计算密集型的任务，它的Framework的主导资源是CPU，而依赖于在内存中计算的任务，它的Framework的主导资源是内存。
因为资源是分配给Framework的，所以DRF会跟踪每个Framework拥有的资源类型的份额百分比；Framework拥有的全部资源类型份额中占最高百分比的就是Framework的主导份额。
DRF算法会使用所有已注册的Framework来计算主导份额，以确保每个Framework能接收到其主导资源的公平份额。
概念过于抽象了吧？
让我们用一个例子来说明。
假设我们有一个资源邀约，包含9核CPU和18GB的内存。
Framework1运行任务需要（1核CPU、4GB内存），Framework2运行任务需要（3核CPU、1GB内存）
Framework1的每个任务会消耗CPU总数的1/9、内存总数的2/9，因此Framework1的主导资源是内存。
同样，Framework2的每个任务会CPU总数的1/
升级会员 