[译]集群调度架构的变革 (四)

原文地址：http://www.firmament.io/blog/scheduler-architectures.html

混合架构   是最近出现的致力于通过组合单体或共享态的设计来解决全分布架构的缺点。一般这样做是ok的 - 比如，在Tarcil（http://dl.acm.org/citation.cfm?id=2806779 ）, Mercury（https://www.usenix.org/conference/atc15/technical-session/presentation/karanasos ）, 和Hawk（https://www.usenix.org/conference/atc15/technical-session/presentation/delgado ） -  有两种调度路径： 一个分布式的来处理负载（如，很短的的任务，或低优先级的批处理任务）， 另一个中心式的来处理其他任务。图1e展示了这种设计。每一个混合调度器的行为都与以上架构描述的部分相同。在实际的实践中，目前据我所知还没有混合调度器在生产环境中部署。

在实践中意味着什么？

以上讨论的不同的调度架构并不只是一个学术课题，尽管他们确实在研究论文出现。作为一个关于Borg，Mesos和Omega论文从工业界角度的扩展的讨论，可以看看Andrew Wang的精彩博文(http://umbrant.com/blog/2015/mesos_omega_borg_survey.html )。此外，很多系统的讨论都部署在大型企业(微软的Apollo，Google的Borg，Apple的Mesos)的生产环境设定，并且他们启发了其他可用的开源项目。

最近，许多集群开始运行容器，所以很多关注容器的“编排框架”出现了。这些跟Google和其他公司称为“集群管理器”很像。不管怎样，一些关于调度器讨论的细节已经融入了这些框架和他们的设计规范，一般他们的关注点都是在面向用户的调度API(由Armand Grillet报道 http://armand.gr/static/files/htise.pdf ，其对比了Docker Swarm，Mesos/Marathon, Kubernetes default scheduler)。此外，很多用户并不知道调度器架构之间的差异，也不知道哪一个架构适合他们的应用。

图2 展示了开源编排框架的概要，他们的调度器的架构和支持的特性。在表格底部，我们也加入了Google和微软的闭源系统。资源粒度列指出了调度器分配任务到一个固定尺寸的slot，还是会根据多个维度（CPU,内存，磁盘I/O贷款，网络带宽等）来分配资源。

一个决定合适调度架构的关键点就是你的集群是否运行了混合的负载。这种case，举例来说，就是当既有在线服务(原文：front-end services) （web负载均衡服务与memcached）和批处理数据分析（MapReduce或Spark）的情况。为了提高使用率这种类型很有意义，但不同的应用有不同的调度需求。在一个混合式的设定中，单体调度器只能得到次优解，因为单一逻辑不能以每个应用为基础进行调整，双层或共享态调度器可以提供更好的收益。

大多数面向用户的在线业务负载设计为将所有资源用来服务每个容器的峰值需求，但这样会导致他们的使用率低于分配到的资源。这样的情况下，用低优先级的负载任务（保证QoS）来优化被过度订阅的资源成为优化有效集群的关键。Mesos是目前唯一支持过度订阅的开源系统，Kubernetes有一个提案（http://kubernetes.io/v1.1/docs/proposals/resource-qos.html ）来加入这个特性。我们期望未来这块领域会有更多的活动，因为目前很多集群的使用率实际上低于Google Borg集群报道（http://dl.acm.org/citation.cfm?id=2741964 ）的60-70%。我们会继续在今后发布关于容量规划，过度订阅，高效机器使用率的内容。

最后，特定的分析和OLAP类型的应用（如，Dremel或SparkSQL查询）可以从全分布式调度器受益。但是，全分布式调度器（如Sparrow）有很严格的特性集限制，它在任务负载都是同一个类型时有很好的性能（如，所有的任务大约在同一个时间段运行），set-up times are low（如，任务被调度到长时间运行的worker， 像YARN中的MapReduce应用级别任务），任务会大量产生（如，许多调度判断会在很短时间产生）。我们会在这个系列的下一个博文更细的讨论下为何全分布式调度器- 混合调度器的分布式组件只在这些应用中有意义。现在，分布式调度器比其他调度器更简单，不支持多资源维度，过度订阅，或重新调度。

大体上，图2证明了开源框架还有一段路要走，直到它们可以支持闭源系统的以上高级特性，这是行动的召唤：由于缺失的特性，糟糕的使用率，不可靠的任务性能，吵杂的邻居导致被半夜叫醒，为一些用户需求定制的黑科技。

不过，还是有一些好消息：今天很多框架还是单体调度器，他们开始向更弹性的设计变化。 Kubernetes已经开始支持插件化调度器（kube-调度器 pod可以被另一个API兼容的调度器pod替代），很多从V1.2后的调度器(https://github.com/kubernetes/kubernetes/blob/master/docs/proposals/multiple-schedulers.md )，开始支持自定义的策略（https://github.com/kubernetes/kubernetes/blob/master/docs/design/scheduler_extender.md ）。Docker Swarm可能-按我的理解-也会增加插件化调度器的支持。

最后，推荐一本书，内容均为阿里工程师一手线上问题处理案例，值得一看。

有关阿里VIPServer软负载的问题欢迎与我交流。

发布会详情与目录请看：

《逆流而上：阿里巴巴技术成长之路》重磅发售

---

本文来自微信公众号「麦芽面包」，id「darkjune_think」
转载请注明。长按图片识别二维码关注。
交流Email: [email protected]