仙隐@数据平台-数据交换平台-实时计算

   随着公司业务的飞速发展，集群规模的逐步扩大，各计算系统，存储系统，应用系统也随着业务的发展，一个接一个的被创造了出来。但集群规模扩大以后，却带来很多问题，如自动化部署，集群整体利用率偏低等问题也逐步的暴露出来。所以，迫切的需求一套集群资源调度系统来解决这些问题。各大互联网公司也相继搞出了一些系统，如omega(google),yarn(apache社区，hadooop下面的一个分支，开源)，mesos(twitter,开源)，torca(腾讯soso), Corona(Facebook)。

   一．为什么要做资源调度系统

   资源调度系统主要是为了解决上述提到的两个问题，同时也给业务系统或计算系统带来了其它好处。集群资源调度系统对底层硬件进行了一层抽象，屏蔽了硬件的异构性(目前，各系统主要是对CPU, MEMORY, IO, DISK进行资源抽象)，对上层各种应用或服务提供资源统一管理和调度。从云计算的角度来划分，属于IAAS(Infrastructure-as-a-service)。总结起来，这样的系统主要带来三点好处：

• 提升资源利用率

   不同业务都有自己的峰值业务需求，如果是每个业务集群单独部署，则每个业务间都是隔离封闭的，资源无共享，无法错峰交谷。集群资源调度系统的引入可以很好的解决这一问题。多业务之前可以做到资源共享，并有弹性管理机制，这样就可以根据不同业务的需要，灵活的进行调度，提高了资源利用率

• 自动化部署

   相信很多开发同学和PE同学都有过这样的经历：新系统发布上线，需要制定各种发布部署方案，宕机后的恢复方案，监控方案等。如果系统不是很成熟，可能这些工作都得手工来完成，即使系统已经做到很成熟了，不同的系统可能也是多套部署系统，开发成本，运维成本也是非常高的。

• 容灾

   做分布式系统的同学都清楚，对于单个服务器来说，出故障的概率是比较小的，但在对于大型分布式环境中，故障就要作为一种理所当然的常态了，没有无故障的侥幸存在。一般分布式系统设计的时候，都会尽量去避免单点问题的出现，但是如果是机架，机柜，甚至是机房出问题怎么办？利用集群资源调度系统能够以较低的代价解决这类问题。

   二．三代集群调度系统

   

   在Omega的论文里描述了Google经历了三代资源调度系统，并探讨了各自的优势点，这里对论文的内容进行一个简单的总结

   这三代资源调度系统分别属于这三种类型：Monolithic, Two-level, Shared state

• Monolithic scheduler(中央式调度器)

   特点：资源的调度和作业的管理功能全部放到一个进程中完成，开源界典型的代表是Hadoop JobTracker的实现

   优点：结构简单，实现难度相对较低

   缺点：

   a)         集群规模受限

   b)         很难引入新的调度策略(比如想在原有调度策略中引入流式作业)

   c)         资源组管理逻辑复杂，需要嵌入到调度系统中

   Omega论文中提到了一种对中央式调度器的优化方案：将每种调度策略放到单独一个路径(模块)中，不同的作业由不同的调度策略进行调度。这种方案在作业量和集群规模比较小时，能大大缩短作业相应时间，但由于所有调度策略仍在一个集中式的组件中，整个系统扩展性没有变得更好。

• Two-level scheduler(双层调度器)

   针对Monolithic的问题，双层调度器是一种很容易想到的解决方法，典型的分布式系统中分层思想。

   特点：

   a)       上层是一个非常轻量的Monolithic调度系统，负责资源分配，但不侵入应用的调度策略。

   b)       下层是具体某个应用程序的调度器，如hadoop, storm, spark, mpi等

   c)       典型系统mesos

   优点：

   a)       两层调度的架构可以做到”大集群”，1万到10万台

   b)       减小“中心节点”的压力，由原来的一个“中心”，变成二层“中心”

   c)       同一个集群中，多种应用的接入，多种框架混部，提高分布式集群的利用率

   缺点：

   a)       各应用无法感知集群整体的使用状况，只能等待上层调度推送信息

   b)       资源分配采用轮询，ResourceOffer机制(mesos)，在分配过程使用悲观锁，并发粒度小，响应稍慢

   c)       缺乏一种有效的竞争或优先抢占的机制

• Shared-state scheduler(共享状态的双层调度器)

   为了克服双层调度器存在的问题，google开发了下一代资源调度系统Omega。

   特点：

   a)       改进版的Two-level Scheduler

   b)       将Two-level Scheduler中的共享数据进行全局持久化，任何应用都可以看到集群资源信息

   c)       资源申请采用乐观锁(通过MVCC实现)，优先级控制，提高并发

   由于无法了解到Omega的细节，只能从论文里提供的信息进行判断，Omega最大的改进点就是将集群的使用信息存放到了一个全局共享存储中，各应用可以获取到整个集群的信息。其分层策略与Two-level是相同的，但是资源分配的过程中会引入些全局资源因素，作为决策因子，相对Two-level来说，调度策略要复杂一点。

   三．Two level Scheduler的典型代表—-mesos

   

   Apache Mesos由两种系统组件组成：Mesos-master, Mesos-slave

   Master是整个系统的核心，是一个轻量的Monolithic scheduler,负责接入mesos的各种framework(通过frameworks_manager来管理)和管理slave，并将slave上的资源按自定义策略分配给framework

   Slave负责接收并执行Master的命令，管理节点上的task，并为各task分配资源。同时，slave也会将当前机器资源汇报给Master进行分配。

   让我们先通一个实例来看一下，Mesos是如何为应用分配资源的。

   

   图中的四个步骤是典型的一个任务从提交，到最终通过mesos分配好资源，并将任务运行在集群中的一个过程。

• S1向master汇报：“我这里有4个cpu, 4G内存，可以给大家使用了”

• Master的开始轮询F1, F2，先询问F1：“s1有4个cpu,4G内存，这个资源你要不要，要多少？”这时，F1回答：“s1的资源我全要了”

• 客户端向F1提交了两个任务，task1需要2个2cpu,1G内存，task2需要1个cpu,2G内存，而已经接受的s1正好有这些资源，通知master,在s1上执行task1和task2

• Master接到起worker请求，通知s1,调用在s1上的f1的executor起动执行进程

   四．资源调度系统上的几类应用

   不同类型的应用系统对资源的要求有很大的差别

• 快短任务(hadoop, 有可能只持续几分钟)

• 周期调度(搜索，garuda，按天【周，月】调度)

• 常驻任务(storm, galaxy)

   五．galaxy流计算服务化平台的资源调度系统

   目前流式计算是业界研究的一个热点，同时集团内部各类流式计算应用得到迅猛发展。在近期的双11，双12等活动期间采用流式计算的实时应用非常抢眼。storm,s4等主要流式计算引擎，提供的编程模型，存在开发成本，开发效率的问题。对于数据类应用开发，SQL是用户最熟悉且较容易上手的一门语言。如何能让流计算也具备SQL编程接口，对用户提供服务化方式开发，维护，升级自己的流计算应用？galaxy为用户提供了一套非常好的解决方案。有以下特点：

   1.     开发成本、开发效率：

   a)      90%需求SQL实现；

   b)       抽象语义层(SQL无法满足，可基于语义层提供更抽象的接口)；

   c)       封装中间存储层；

   2.     集群服务化：多集群用户不感知；可运维迁移任务；

   3.     自动化测试体系：包含数据质量；

   4.     在云端流程整合；

   Galaxy为什么需要自己的资源调度系统呢？

• Galaxy的定位是一个流计算的服务化平台，目的是支持“万”级别的任务数

• Galaxy目前选用的计算引擎，从引擎设计和实现来看，无法做到大集群(千台以上)，多租户

• 在阿里生产环境中，有多个机房，不同的业务可能需要不同的资源组。单个计算集群显然无法满足需求。为了解决这个问题，galaxy采用的是多集群的方案，每个资源组分配N个小的计算集群。

• 为了能够使多个计算集群做到资源共享且做到任务隔离，在galaxy内部，也设计了一套小型Two-level调度系统，相对于mesos, yarn，omega要轻量的多。

   Galaxy资源调度系统的设计与实现

   目前galaxy资源调度系统正在紧张开发过程中，预计在8月份，第一个版发布。到时候会写一遍文章详细介绍galaxy资源调度系统的设计与实现

   六．总结

   Omega, mesos, yarn这类资源调度系统为我们设计和实现分布式系统时，带来了许多新的启发，随着互联网的发展，大数据时代的到来，在业务压力的驱使下，这类系统必定会得到飞速的发展。

   七．参考文献

• Omega: flexible, scalable schedulers for large compute clusters: http://eurosys2013.tudos.org/wp-content/uploads/2013/paper/Schwarzkopf.pdf

• Mesos: A Platform for Fine-Grained Resource Sharing in the Data Center: https://www.usenix.org/legacy/event/nsdi11/tech/full_papers/Hindman_new.pdf

• 解析Google集群资源管理系统Omega: http://ju.outofmemory.cn/entry/21397

• Torca：Typhoon上的分布式集群调度系统: http://djt.qq.com/bbs/thread-29998-1-1.html

• Yarn: http://hadoop.apache.org/docs/current/hadoop-yarn/hadoop-yarn-site/YARN.html