集群调度框架的架构演进之路.docx

集群调度框架的架构演进之路.docx

ID:59124521

大小:106.48 KB

页数:5页

时间:2020-09-13

集群调度框架的架构演进之路.docx_第1页
集群调度框架的架构演进之路.docx_第2页
集群调度框架的架构演进之路.docx_第3页
集群调度框架的架构演进之路.docx_第4页
集群调度框架的架构演进之路.docx_第5页
资源描述:

《集群调度框架的架构演进之路.docx》由会员上传分享,免费在线阅读,更多相关内容在教育资源-天天文库

1、集群调度框架的架构演进之路这篇博客是关于大型机群任务调度系列的第一篇,资源调度在Amazon、Google、Facebook、微软或者Yahoo已经有很好实现,在其它地方的需求也在增长。调度是很重要的课题,因为它直接跟运行集群的投入有关:一个不好的调度器会造成低利用率,昂贵投入的硬件资源被白白浪费。而光靠它自己也无法实现高利用率,因为资源利用相抵触的负载必须要仔细配置,正确调度。架构演进这篇博客讨论了最近几年调度架构如何演进,为什么会这样。图一演示了不同的方法:灰色方块对应一个设备,不同颜色圈对应一个任

2、务,有“S”的方形代表一个调度器。箭头代表调度器的调度决定;三种颜色代表不同工作负载(例如,网站服务,批量分析,和机器学习)图一:不同调度架构,灰色框代表集群设备,圆圈代表任务,Si代表调度器。(a)单体式调度器(b)二级调度(c)共享状态调度(d)分布式调度(e)混合式调度许多集群架构,例如大量高性能计算(HPC),使用的是Borg调度器,它跟Hadoop调度器和Kubernetes调度器完全不同,是单体式调度。单体式调度单一调度进程运行在一台物理机内(例如HadoopV1中JobTacker,Kub

3、ernetes中的kube-scheduler),将任务指派给集群内其它物理机。所有负载都服从于一个调度器,所有任务都通过这一个调度逻辑运行(参见图一a)。这种架构最简单格式唯一,在此基础上发展起了很多负载的调度器,例如Paragon和Quasar调度器,采用机器学习方法来避免不同负载之间资源竞争。今天集群都运行着不同类型的应用(与之相对应的是MapReduce早期作业场景),然而,采用单一调度器来处理这么复杂异构负载会很棘手,有几个原因:1.调度器必须区分对待长期运行服务作业和批量分析作业,这是合理的

4、需求。2.因为不同应用有不同的需求,催生调度器内加入更多功能,增加业务逻辑和部署方式。3.调度器处理任务顺序变成一个问题:如果调度器不仔细设计,队列效果(例如线头阻塞head-of-lineblocking)和回滚会成为问题。总之,这听起来像是给工程师带来噩梦,调度器维护者面对的没完没了的功能请求证实了这点。二级调度二级调度通过将资源调度和任务调度分离解决了这个问题,这使得任务调度逻辑不仅可以根据不同应用要求而进行裁剪,而且保留了在集群之间共享资源的可能性。尽管侧重点不同,Mesos和YARN集群管理都

5、使用了这种方法:Mesos中,资源是主动提供(offer)给应用层调度,而YARN则允许应用层调度请求(request)资源(,并且随后接受被分配资源)。图一b展示了这一概念,作业负责调度(S0-S2)跟资源管理器交互,资源管理器则给每个作业分配动态资源。这一方案赋予客户灵活调度作业策略的可能性。然而,通过二级调度解决问题也有问题:应用层调度将资源全局调度隐藏起来,也就是说,不再能看到全局性的可选资源配置。相反,只能看到资源管理器主动提供(offer,对应于Mesos)或者请求/分配(request/a

6、llocate,对应于YARN)给应用的资源。由此带来一些问题:1.重入优先权(也就是高优先权会将低优先权任务剔除)实现变的很困难。在基于offer模式,被运行中任务占用的资源对高一级调度器不可见;在基于request模式,底层资源管理器必须理解重入策略(跟应用相关)。2.调度器不能介入运行中业务,有可能减低资源使用效率(例如,“饥饿邻居”占据了IO带宽),因为调度器看不见他们。3.应用相关调度器更关注底层资源使用的不同情况,但是他们唯一选择资源的方法就是资源管理器提供的Offer/request接口,

7、这个接口很容易变的很复杂。共享状态架构共享状态架构通过采用半分布式模式来解决这个问题,这种架构下集群状态多副本会被应用层次调度器独立更新,如图一C中所示。一旦本地有更新,调度器发布一个并发交易更新所有共享集群状态。有时候因为另外一个调度器发出了一个冲突交易,交易更新有可能失败。最重要的共享状态架构实例是Google的Omega系统,以及微软的Apollo和Hashicorp的Nomad容器调度。这些例子中,共享集群状态架构都是通过一个模块实现,也就是Omega中的“cellstate”,Apollo中的

8、“resourcemonitor”,以及Nomad中的“planqueue”。Apollo跟其他两个不同之处在于共享状态是只读的,调度交易直接提交到集群设备;设备自身会检查冲突,来决定接受或者拒绝更新,使得Apollo即使在共享状态暂时不可用情况下也可以继续执行。逻辑上来说,共享状态设计不一定必需将全状态分布在其它地方,这种方式(有点像Apollo)每个物理设备维护自己的状态,将更新发送到其它感兴趣的代理,例如调度器,设备健康监控,和资源监

当前文档最多预览五页,下载文档查看全文

此文档下载收益归作者所有

当前文档最多预览五页,下载文档查看全文
温馨提示:
1. 部分包含数学公式或PPT动画的文件,查看预览时可能会显示错乱或异常,文件下载后无此问题,请放心下载。
2. 本文档由用户上传,版权归属用户,天天文库负责整理代发布。如果您对本文档版权有争议请及时联系客服。
3. 下载前请仔细阅读文档内容,确认文档内容符合您的需求后进行下载,若出现内容与标题不符可向本站投诉处理。
4. 下载文档时可能由于网络波动等原因无法下载或下载错误,付费完成后未能成功下载的用户请联系客服处理。