集群调度架构的变革 (一)

原文： http://www.firmament.io/blog/...

集群调度器是现代基础设施很重要的组件，尤其在最近几年有很大发展。架构从单体应用的设计进化成更灵活，分散的，分布式的设计。但是，目前很多开源能提供的还是单体应用或缺了关键特性。这些特性对于真实世界的用户很重要，因为他们需要很高的使用率。

这是我们发布的第一篇关于在大集群上进行任务调度的系列文章，那些在亚马逊，谷歌，facebook，微软或雅虎实际在使用的。调度是一个重要的话题，因为它直接影响操作集群的成本：一个差调度器会导致极低的使用率，让昂贵的机器空闲，导致浪费钱。高使用率，对于集群自己并不容易：除非仔细的决策，负载之间会互相影响。

架构进化

这篇文章主要讨论调度架构在近些年是如何进化的，以及这为什么发生。图一将这些不同的方式可视化：灰色的方块代表一个机器，圆圈代表一个任务，一个里面标着S的团员性代表一个调度器。箭头表示调度器做的决策，三种颜色代表不同类型的负载（例如，web服务，批量分析，机器学习）。

许多集群调度器 - 例如高性能计算（HPC）调度器，Borg调度器，早期Hadoop调度器和Kubernetes调度器 - 都是单体的。一个单例的调度进程泡在一个机器上（例如，Hadoop第一版的JobTracker，Kubernetes的kube-scheduler）并且给机器调度任务。所有的负载被同一个调度器来处理，所有的任务跑着相同的调度逻辑（图1a）。这样简单并统一，却导致了越来越复杂的调度器。举个例子，可以看看Paragon和Quasar调度器，使用了机器学习的方式来避免在资源上相互冲突的负载调度。

在今天很多集群运行很多不同类型的应用（在早期只有Hadoop MapReduce任务在运行）。因此维护单个的调度器实现处理混合型的负载很需要技巧，原因如下：

1. 很明显我们期望一个调度器按不同的方式来处理长周期服务型任务和批量分析型任务。
2. 不同的应用有不同的需求，要支持他们所有的需求需要给调度器添加许多特性，增加了逻辑和实现的复杂性。
3. 调度器处理任务的顺序成了问题：队列效应（队列头部阻塞 head-of-line blocking）与积压问题需要小心地设计调度器。

综上所述，这听起来是一个工程上的噩梦 - 调度器的开发者会收到无穷无尽的特性需求。

---

本文来自微信公众号「麦芽面包，id「darkjune_think」
转载请注明。微信扫一扫关注公众号。
交流Email: zhukunrong@yeah.net