【系统架构】解读Mesos



  • Mesos是Apache下的开源分布式资源管理框架,今天的介绍主要有以下几个方面:

    1. Why Mesos
    2. What is Mesos
    3. Mesos Internal
    4. Mesos Scheduling
    5. Compare to Others

    1. Why Mesos?

    现今公司里的微架构很多,组件也越来越多,使得系统越来越复杂,工作量越来越大。有长期运行的服务,也有批处理任务。

    0_1469811023977_m1.png

    为了更好的管理这些服务,采取了很多措施,如下图:

    0_1469811046912_m2.png

    公司里把相似的软件放在同一个服务器上,同时预留出很多空间给突发或特殊事件(比如双十一)。这样存储空间被静态划分,需要人力来维护这些服务器。

    此外,集群的利用率很低,如下图:

    0_1469811073395_m3.png

    图中三个集群Hadoop,Pregel和MPI。横坐标为时间,纵坐标为集群利用率。

    下图为Docker的模型,虽然它能利于软件的自动部署,但是无法解决数据中心静态划分问题。

    0_1469811270949_m4.png

    我们所希望的是各种工作能放在共享集群上,软件更加紧密。

    0_1469811308578_m5.png

    2. What is Mesos

    Mesos是一个开源的集群管理框架,它可以将数据中心/集群放在一台电脑里运行,对外提供简单的API,同时隐藏内部的很多复杂架构。它由UC Berkeley的Benjemin Hinderman,Andy Konwinski和Matei Zaharia开发,后来在Twitter里发展成熟,并很快成为Apache基金会的顶级项目。

    3. Mesos Internal

    0_1469811363328_m6.png

    Mesos是一个分布式的架构,具有主从关系,master和slave。Zookeeper能做到首领选举(选mesos的master)等功能。要注意的是zookeeper也需要选举master。应用程序跑在frameworks上,它也是分布式的软件,包括scheduler和executor。图中蓝色部分是mesos本身,白色部分是需要自己开发的framework。这些需要自己开发的framework也需要考虑高可用性的问题,这算是mesos的缺点之一。Mesos使用protocol buffer和libprocess来进行通信。

    1)zookeeper做为leader election。每个master起来的时候都要向zookeeper的quorum注册znode。
    2)master主要用于管理slave node的状态,知道slave在哪儿,有哪些资源,同时知道各个框架的信息。比如Hadoop和MPI框架的基本信息。master还可以发resource offer。如果master down了,zookeeper可以马上从standby master里面选一个。因为几个master里面共享的东西很少,不需要数据的同步。
    3)slave负责运行任务,同时不断的向master发消息,报告可用资源和在运行的任务的状态。这两种消息并不相同,报告任务状态的消息保证一定delivery,而其他消息并不保证。
    4)framwork是一个分布式的应用,包括scheduler和executor。其中scheduler部分要和master紧密通信,接受master发送的offer,scheduler收到offer后决定是不是要跑某个task。executor真正的去执行任务。Offer的发送由master决定。

    4. Mesos Scheduling

    0_1469811414671_m7.png

    图中红色部分是具体的例子。比如第一个表示资源具有24个虚拟CPU等等。

    Mesos使用两层调度,如下图:

    0_1469811447960_m8.png

    Mesos的愿景是能跑所有类型的workload,但是这很难实现。

    Mesos master里面有Application module,负责具体的分配算法。这个模块本身有默认算法设置,也可以自己实现。

    首先slave向master报告自己的资源信息,比如4个CPU等等,在application module计算之后发给框架1,框架1里面有task queue,比如图中有两个Job,scheduler分配给不同task不同的资源,把信息发给master,master再返还给对应的slave去跑task。这就是two level scheduling,one level scheduling是指slave直接和scheduler通信。

    Two level scheduling的好处在于:

    0_1469811537180_m7.png

    Application module默认的算法实现是DRF:

    0_1469811549014_m10.png

    DRF强调的是公平性。如果在使用Mesos时不在意公平性,DRF并不适用。Yarn里面也有DRF。下图是个具体的关于公平性的例子:

    0_1469811585785_m11.png

    假设我们有个10块pizza,不同的人想要不同数量的pizza,如何实现公平分pizza。下图是作者提供的解决方案:

    0_1469811597516_m12.png

    这个方案的思路是:先平均分,每个人2.5份。从资源要求最少的人开始(Ted),抽取多余的资源(Ted多了1.5,Barney多了0.5)分给剩下资源不够的人。这是单一资源情况下的分配情况。当资源多样化时,情况不同,如下图:

    0_1469811626314_m13.png

    1)如果一个人得到的资源少于平均分配,那么他可以选择不share。所以这个算法是鼓励分享,不能出现这种情况。
    2)这个算法不能因为个别人的欺骗行为而影响整体分配。
    3)不同用户之间不能妒忌。如果一方任务完成,不能再领取额外资源。需求大的用户要获得大于或等于需求小的用户的资源。
    4)这个算法应最大化资源利用率。

    0_1469811660520_m14.png

    假如总共的资源是9个CPU,18个内存。最开始资源分配都为0,随机选择Framework 2(F2)分配资源。F2要了3个CPU,1个内存,dominant share为33%。现在F2的dominant share大于F1,下次分资源时先分配F1。依次类推,每次比较domiant share进行资源分配。

    5. Compare to Others

    0_1469811740829_m15.png

    Yarn和Mesos发展时间差不多,并且也是为了克服资源利用率方面问题而产生。区别在于Yarn是一个monolithic scheduling,不需要写framwork。整体来说,Yarn和Mesos的差别不大。

    0_1469811762361_m16.png

    Reference
    http://research.google.com/pubs/pub41684.html
    http://research.google.com/pubs/pub44843.html
    http://research.google.com/pubs/pub43438.html
    https://www.cs.berkeley.edu/~alg/papers/mesos/pdf
    https://www.cs.berkeley.edu/~alg/papers/drf/pdf

    本篇小编:Shaoke Xu


登录后回复
 

与 BitTiger Community 的连接断开,我们正在尝试重连,请耐心等待