Mesos—一个细粒度的资源共享调度平台

一个细粒度的资源共享调度平台——Mesos

  Mesos是一个应用于大型云计算中心的系统资源调度系统。在大数据与云计算中心，都部署着大规模的计算机集群，并对外提供各种各样的服务与应用，这些形式多样、需求各异的服务与应用通常依赖特定的计算框架（Hadoop，Spark，Flink，MPI…）来完成计算任务。而Mesos则是位于集群硬件平台与这诸多种计算框架之间的一个系统软件，负责硬件资源（CPU，MEM，Disk，BW…)与计算框架的合理对接，从而完成作业调度与资源分配的任务。

背景

  众所周知，面对复杂多样的应用种类，目前没有一个万能的计算框架能够适用于所有的计算应用，例如：科学计算有时需要使用并行计算框架；大数据处理作业有时需要用到Hadoop框架；迭代步骤较多的数据处理作业有时需要spark框架；图处理、深度学习等作业都须用对应的框架来完成作业处理。因此，就出现了同一物理集群上部署着众多计算框架的局面，进而如何将计算资源合理分配给这些计算框架就成为了一个热点的研究话题。对此，已有如下方案：将物理集群划分出众多的分区，每个分区上运行一个特定的计算框架；在物理集群上启动众多虚拟机，再为每个计算框架分配一组虚拟机来完成运算。而这些方案存在的问题，就是分配粒度与现有计算框架的不匹配，导致了较低的资源利用率和较低的资源共享效率；此外，若使用虚拟机方案，在集群中，虚拟机的启动将会小号较长时间，虚拟机的运行也将占用相当一部分资源，所以这是一个代价高但收益却不一定理想的方案。
  而如果考虑将一个节点划分成为多个资源槽（slots)，将一个作业划分成为多个作业，就可以自然而然使任务和资源槽匹配，实现细粒度的资源分配。但是我们知道，众多计算框架都是独立被开发的，还没有一个在计算框架之间执行细粒度资源共享的办法，进而很难实现高效的集群和数据共享。那么为了一举消灭前述的诸多问题，Mesos便应运而生。Mesos实现了集群上多计算框架之间的细粒度资源共享，它为所有计算框架提供了一个利用底层物理资源的接口。

基本架构

  Mesos的设计架构也属于Master/Slave架构，包括了1个处于运行状态的master服务器，2~3个灾备服务器（master服务器宕机时，起备份作用），众多slave服务器，还有运行在集群中的众多计算框架。其中，master服务器，除了基础的集群管理和监控功能以外，其主要功能就是向计算框架供给计算资源；众多slave服务器之上部署着多种计算框架，运行在这些slave服务器上的守护进程，主要负责计算框架的任务执行。运行在Mesos之上的计算框架，都有一个调度器scheduler和一个执行器execcutor，scheduler需要在master上进行注册，从而能够接收master供给的资源；在获取到资源之后，作业和任务由executor负责完成。

工作原理

  下面，我们将通过一个实例来了解Mesos的工作原理，从而对其基本架构则会有更加深入的理解。在此之前，先来了解一个Mesos中非常重要概念——Resource offer。所谓的Resource offer，即Mesos决定向每一个计算框架供给多少资源，而由计算框架自己来决定使用哪一部分资源，并且由其自己决定在这部分资源上运行那些任务。

根据这张图所展示的，Mesos的工作过程分为以下几个步骤：

• 步骤1：slave1向master报告自己此时有4个CPU、4G的内存空间是空闲的。master将这个信息注册之后，就来调度自己的资源分配模块，此时这个Allocation Module命令将当前所有这些空闲资源提供给framework1。
• 步骤2：master向framework1发送一个resource offer，我们可以将这个resource offer看作是一个空闲资源列表或者向量。
• 步骤3：framework1的scheduler对收到的resource offer并做出决断（接受或拒绝），反馈给master一条消息，说此时自己有两个任务需要运行，第一个任务需要占用2个CPU和2G的RAM；第二个任务需要占用1个CPU和2G的RAM。
• 步骤4：master根据步骤1的注册信息，将这两个任务发送到对应slave节点，由slave服务器负责任务运行。
• 步骤5：由于上一轮次分配完成之后还有1个CPU和2G的RAM仍然空闲，那么此时master还可以将这些资源当作一个resource offer发送给framework2。
    Mesos执行的工作就是这样重复进行，只要有任务运行结束释放出新的空闲资源，Mesos就会向各个framework发送resource offer。

设计要点

  Mesos的工作机制并不复杂，它的设计考虑了几个方面的内容，下面就来简单了解一下Mesos的设计考虑。

• 设计理念
  • 简单——Mesos是一个可扩展的，弹性化的内核，是一个能使多计算框架之间高效共享资源的迷你的程序接口。
  • 去中心化——将任务调度和执行控制权交给计算框架
    • 这个设计允许计算框架对各种各样的问题实现多种方法。
    • 这一设计还保证了Mesos内核的简单化，微型化，降低了Mesos需要改进升级的概率，增加了可扩展性和稳定性。

问题1.中心化的调度方案有何弊端？

中心化的调度方案主要存在以下三个方面的弊端：
1）复杂性：中心化调度，需要主服务器维护所有资源信息，包括总的资源量、空闲资源信息和占用资源的信息；此外还要维护各类作业信息，包括等待作业、已完成作业、作业优先级信息等等，进行合理的资源分配和作业调度就需要基于这些信息求解一个在线的优化问题，当系统规模较大时，这个优化问题将是非常复杂耗时的。复杂性导致了中心化调度的可扩展性较差。
2）频繁改进：新的计算框架，或者现有计算框架中应用的新的调度规则不断涌现，来自上层计算框架对资源的要求也处于改变的状态，所以中心化调度方案想要长时间满足上层计算框架的需求是很难的，只能做到频繁地改进调度模块。
3）冗余调度：我们可以注意到，许多现有地计算框架内部都实现了自带的资分配与作业调度机制，而中心调度方案中所作的调度工作则成为了冗余。Mesos只是提供一整块的资源给计算框架，而由计算框架自身来分配这部分资源，则消除了冗余调度的情况。

• 资源分配
  • Mesos中的资源分配模块是一个可插拔的算法模块，不同的系统可根据自身的作业类型或者业务需求配置使用不同的资源分配模块。在Mesos内部，自带有一个资源分配模块——主要资源公平机制（Dominant Resource Fairness，DRF），这是一个在多种资源环境下的最大最小公平算法。该算法考虑的是在一个包含多种资源类型的系统中的资源公平分配问题，其中不同的用户和作业对资源有不同的需求。具体的算法原理不在此赘述。
• 可扩展的稳定资源供给（Resource offer）
  • 部署在集群上的计算框架不能指定资源需求和限制，只能由Mesos来向计算框架供给资源，由计算框架决定是否使用该部分资源，或者使用哪一部分。也就是说，计算框架对于master发送来的Resource offer可以选择接受，也可以选择拒绝。所以，就会存在两种情况导致Mesos的工作效率有所下降：1）.可能存在一个计算框架，在接收到满足自身需求的Resource offer之前需要等待相当长一段时间；2）.也可能存在一个Resouce offer在被某一个计算框架接受之前，已经被多个计算框架拒绝。

问题2.针对这种降低Mesos工作效率的情况，Mesos是如何解决的？

  由于计算框架拒绝Resource offer的原因多种多样，例如，可能是用于供给的资源量不足。那么对于一个Resource offer，将其发送给每一个计算框架无疑会增加被拒绝的可能性，也会增加系统的通信开销。对此，Mesos在master内部设计了一个过滤器，并附加了两条标准“对于某一计算框架，只从固定部分的节点上供给资源；或只从至少含有R空闲资源量的节点上供给资源”。这一过滤器的使用，相当于在Mesos向上层计算框架供给资源之前就已经附加了一层保障，由此，将会降低计算框架拒绝Resource offer的可能性。

• 隔离
  • 由于存在多个计算框架运行在同一台slave服务器上的情况，所以Mesos使用了操作系统级别的隔离措施，它使用的是LXC（Linux Containers）。而当前最热门的容器解决方案当属Docker容器，它占据着当下云计算市场的霸主地位。

  由于笔者可能存在理解或表述错误，敬请读者批评指正，也欢迎各位同仁一起交流学习，共同进步！

参考文献：Mesos: A Platform for Fine-Grained Resource Sharing in the Data Center