返回 登录
0

十大主流集群调度系统大盘点

众所周知,集群调度系统是现代数据中心举足轻重的组件,一个好的调度器,能提高集群资源利用率,实现自动化部署和高可用,节约用户投资,“让开发者最大可能地把精力集中到上层业务逻辑上”。考虑到时下各路调度系统眼花缭乱,小编打算从Google的三代集群调度架构演进切入,对十个主流集群调度系统进行分门别类大盘点。

开始盘点前,让我们先快速回顾一下Google的三代集群调度架构——中央式(Monolithic)、双层式(Two-level)、共享状态式(Shared-state)都有哪些特征?

快速回顾:Google三代集群资源调度架构

早在十多年前,Google就开始使用第一代集群管理Borg技术管理数据中心。2013年,Google发表的Omega论文(Omega,a scalable scheduler for large compute clusters)详细介绍了Google的三代集群资源调度架构:中央式(Monolithic)、双层式(Two-level)、共享状态式(Shared-state)。(见下图)

图片描述

http://static.googleusercontent.com/media/research.google.com/zh-CN//pubs/archive/41684.pdf

(1) 中央式调度器(Monolithic scheduler)

中央式调度器实质上就是一个单一的调度agent来负责所有请求,通常用在HPC(高性能计算)中。由于将资源的调度和作业的管理功能全部放到一个进程中完成,扩展性较差:首先,集群规模受限。其次,很难引入新的调度策略,比如之前仅支持MapReduce作业,现在要支持流式作业,而将流式作业的调度策略嵌入到中央式调度器中是一项很难的工作。

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

双层调度器采用“分层”思想,上层是一个非常轻量级的的中央式调度器,下层是具体某个应用程序的调度器,如Hadoop、Storm、Spark、MPI等。这样就可以减小“中心节点”的压力,由原来的一个“中心”,变成二层“中心”;而且同一个集群中多种应用接入,多种框架混部,有效提高分布式集群的利用率。但是,这种“二级调度”也有缺陷:各应用无法感知集群整体的使用状况,只能等待上层调度推送信息;再加上资源分配采用轮询,在分配过程使用“悲观锁”(即PCC,Pessimistic Concurrency Control,悲观并发访问控制方式),并发粒度小,响应稍慢,缺乏一种有效的竞争机制。

(3)共享状态调度器(Shared-state scheduler)

为克服双层调度器的不足,Google提出了共享状态调度。这种调度器将双层调度器中的集中式资源调度模块简化为持久化的“共享数据”(状态)和针对这些数据的验证代码——这里的“共享数据”实际上就是整个集群的实时资源使用信息。共享状态调度器最典型的代表就是Google的Omega系统,它也可理解为改进版的“双层调度器”。通过将双层调度器中的“共享数据”进行全局持久化,任何应用都可以看到集群资源信息。而且资源申请采用“乐观锁”(即MVCC,Multi-Version Concurrency Control,多版本并发访问控制方式),优先级控制,大大提升并发性。

现在让我们基于这三类调度策略,对时下十个主流集群调度系统进行分门别类大盘点吧!

Monolithic篇

1. Google Borg

Borg作为Google的内部集群管理系统已有十多年历史了,但其细节信息一直鲜少公开,直到去年Google发表的论文(Large-scale cluster management at Google with Borg)才第一次揭开它的神秘面纱。一个Borg集群(即Cell)由一个逻辑中央控制器BorgMaster和若干代理节点Borglet组成,属于Monolithic架构。(见下图)

图片描述

http://static.googleusercontent.com/media/research.google.com/zh-CN//pubs/archive/43438.pdf

关于Borg架构的解读,网上有一个有趣的段子,它将Borg架构比作黑社会,BorgMaster是黑老大,Borglet是底下的一帮小弟,而Borg的一套调度流程就像黑社会运作一趟毒品交易。(见下图,转自网络)

图片描述

2. Kubernetes

Kubernetes是一个容器集群的编排管理系统,主要面向跨Docker主机场景之下容器集群的统一管理,据Wikipedia介绍,最初是由Google在2014年提出的开源项目,其开发设计思想深受Google的Borg系统影响。

图片描述

Kubernetes属于Monolithic架构,Kubernetes Master提供了集群统一视图的中心控制点,Node节点又称作Minion,负责运行Master交付的任务。

图片描述

3. Docker Swarm

Docker Swarm是Docker公司在2014年12月初发布的一套管理Docker集群的工具。一套Docker Swarm架构由一个Swarm manager和一组Swarm节点组成,Swarm manager上运行Swarm daemon,用户只需跟Swarm manager通信,然后Swarm manager根据discovery service的信息选择一个Swarm节点来运行容器。典型的Monolithic架构。

图片描述

4. 腾讯 Torca

Torca作为腾讯Typhoon云平台的资源调度子系统,已经在网页搜索、广告方面广泛应用。Torca属于Monolithic架构,一个Torca集群由一个Central Manager和若干Execute Server组成。Central Manager是集群任务调度中心,Execute Server接收任务并负责相应执行。

图片描述

5. 阿里飞天伏羲

“飞天”是阿里巴巴的云计算平台,其中分布式调度系统被命名为“伏羲”(代号Fuxi)。伏羲主要负责集群资源管理和任务调度,属于Monolithic架构。系统有一个“Fuxi Master”的集群控制中心,其余每个Slave节点上会运行一个“Fuxi Agent”的守护进程,Fuxi Agent除了管理节点上运行的任务外,还负责收集该节点上的资源使用情况,并汇报给Fuxi Master。Fuxi Master与Fuxi Agent之间使用Heartbeat机制,以监测节点健康状态。

图片描述

Two-level篇

1. Apache Mesos

Apache Mesos是2009年加州大学伯克利分校AMPLab首先开发出的一款开源集群管理软件,主要用于搭建高效扩展的分布式系统来支持各式各样不断增长的Framework。Mesos以Framework的形式,提供两级调度机制,即Two-level scheduler的典型代表。

Mesos Master协调全部的Mesos Slave,并确定每个节点的可用资源,聚合计算跨节点的所有可用资源的报告,然后向注册到Master的Framework(作为Master的客户端)发出资源邀约。Framework根据应用程序的需求,选择接受或拒绝来自Master的资源邀约。一旦接受邀约,Master即协调Framework和Slave,调度参与节点上的任务,并在容器中执行,使得多种类型的任务可在同一个节点上同时运行。

下图为Mesos“两级调度机制”示意图,图中只展示了Hadoop和MPI两种框架类型。

图片描述

2. Apache Hadoop YARN

Apache Hadoop 是一个开源软件框架,最初包含HDFS(Hadoop分布式文件系统)和Hadoop MapReduce分布式计算引擎。自2012年8月开始,Apache Hadoop YARN成为Apache Hadoop的一个新子项目,其目的是让Hadoop数据处理能力超越MapReduce。Hadoop YARN提供了一个更加通用的资源管理和分布式应用框架,不仅支持Hadoop MapReduce,而且MPI,图处理,在线服务(比如Spark、Storm、HBase)等应用都可放到YARN上。

注:在 YARN 中,MapReduce 降级为一个分布式应用程序的角色(但仍是一个非常流行且有用的角色),现在称为 MRv2。MRv2 是经典 MapReduce 引擎(现在称为 MRv1)的重现,运行在 YARN 之上。

MRv1属于Monolithic架构,由一个JobTracker和若干TaskTracker组成。JobTracker负责资源管理以及Job的生命周期管理,TaskTracker负责执行JobTracker分配的Task,并周期性向JobTracker汇报Task进度及状态。(见下图)

图片描述

YARN将MRv1中JobTracker的两大职责——资源管理和Job管理,分别交给两个角色负责。一个是全局的ResourceManager,一个是每个应用一个的ApplicationMaster。ResourceManager是整个系统仲裁应用之间资源分配的最高权威,而每个应用一个的ApplicationMaster负责向ResourceManager协商资源,并与NodeManager协同工作来执行和管理task。(见下图)

图片描述

最近CamSaS项目组(Cambridge System at Scale)在Cambridge官网发表了一篇博客——The evolution of cluster scheduler architectures,文中认为YARN属于“有限的两级调度”。因为YARN的ApplicationMaster只能将应用层的Tasks放置在已有容器里,无法挑选资源(除非它向ResourceManager请求的资源远超过它的需要)。(见下图)

图片描述

图片描述

http://www.cl.cam.ac.uk/research/srg/netos/camsas/blog/2016-03-09-scheduler-architectures.html

但Google在2013年的Omega论文中(Omega,a scalable scheduler for large compute clusters),直接将 YARN归到了Monolithic架构。

图片描述

Shared-state篇

1. Google Omega

如前所述,Omega使用基于共享状态的策略,每个调度器拥有全局资源视图,具有整个集群全部负载信息的完全访问权限。Omega中的“元调度器”(Cell State)维护着一个全局共享的集群状态,而每个调度器具有一个私有集群状态副本。

ACM Queue(美国计算机学会ACM发行的商业杂志)最近也发表了一篇文章(Borg, Omega, and Kubernetes:Lessons learned from three container-management systems over a decade),详细介绍了Omega的“共享状态”调度以及“乐观并发”策略。

图片描述

http://queue.acm.org/detail.cfm?id=2898444

2. 微软Apollo

Apollo是已经部署在微软实际生产环境中的集群调度系统,每天负责上万台机器上数以百万计的高并发计算任务的调度和管理。Apollo使用基于共享状态的策略。每个调度器(即Job Manager,负责Job的生命周期管理)拥有全局资源视图,具有整个集群的完全访问权限。Process Node负责管理所在server上的本地资源和调度。Resource Monitor负责维护一个全局共享的集群状态,即持续收集集群所有Process Node的负载信息,向每个Job Manager提供集群状态的全局视图。见下图,转自Microsoft Research(微软研究院)关于Apollo的论文(Apollo: Scalable and Coordinated Scheduling for Cloud-Scale Computing)。

图片描述

http://research.microsoft.com/pubs/232978/osdi14-paper-boutin.pdf

3. Hashicorp Nomad

Nomad是著名开源公司Hashicorp在2015年9月推出的一款分布式、高可用的开源集群管理工具,专为微服务和批量处理工作流设计,支持所有主流操作系统以及虚拟化、容器化或独立应用。现已在生产环境使用。Nomad支持跨数据中心跨区域数千节点的高扩展和任务调度,下图为Nomad跨区域调度示意图,转自Hashicorp官网。

图片描述

https://www.nomadproject.io/docs/internals/architecture.html

Nomad也是基于共享状态的调度器,它是通过“Plan Queue”来维持一个全局共享的集群状态。下图为Nomad的一个完整Evaluation工作流,转自Hashicorp官网。

图片描述

https://www.nomadproject.io/docs/internals/scheduling.html

评论