目录

1. 问题：集群资源如何管理？

2. 独立资源管理与调度系统的优势

3. 概念模型

4. 通用架构

4.1 通用调度器

4.2 节点管理器 

5. 设计一个合理的资源管理与调度系统需要考虑的问题

5.1 异质性

5.2 数据局部性（Data Locality）

5.3 抢占式和非抢占式

5.4 资源分配粒度

5.5 饿死和死锁

5.6 资源隔离方法

6. 三种资源管理和调度系统范型

6.1 集中式调度器

6.2 两级调度器 Two-Level Scheduler

6.3 状态共享调度器 Shared-State Scheduler

6.4 不同范型比较

---

1. 问题：集群资源如何管理？

传统——静态资源划分方法：

• 将划分后的固定的硬件资源给固定的计算框架。各个框架之间各行其是、互不干扰。
• 优点：简便易行。
• 缺点：资源的整体利用率不高。

集群资源管理和调度的核心目标：使得整个集群的大量资源在能够实现更高资源利用率的同时加快所有计算任务的整体完成速度。

当前发展趋势：在集群硬件层上抽象出一个功能独立的集群资源管理系统。将所有可用资源当作一个整体来进行管理，并对其他所有计算任务提供统一的资源管理与调度框架和接口。

2. 独立资源管理与调度系统的优势

• 集群整体资源利用率高，可以根据任务即时需要动态分配资源。
• 增加数据共享能力，所有资源对所有任务可用，只需存储一份即可。
• 支持多类型计算框架和多版本计算框架。

3. 概念模型

强调三要素：

• 资源组织模型：将集群中当前可用的各种资源采用一定方式组织起来，方便后续资源分配过程。
• 调度策略：以一定方式将资源分配给提交到系统的任务。常见的调度策略包括FIFO、公平调度、能力调度、延迟调度等。
• 任务组织模型：将多用户提交的多任务通过一定方式组织起来，方便后续资源分配。

4. 通用架构

• 通用调度器
• 节点管理器

4.1 通用调度器

构成：

• 资源收集器
• 资源调度策略

管理资源池和工作队列数据结构。

4.2 节点管理器 

向资源收集器汇报当前本机资源使用情况，并负责容器的管理工作。

所分配的任务由管理器纳入容器隔离执行。

5. 设计一个合理的资源管理与调度系统需要考虑的问题

5.1 异质性

往往指的是组成元素构成的多元性和相互之间较大的差异性。

• 资源异质性：例如数据中心的机器很难保证采用完全相同的配置。
• 工作负载（Workload）异质性：互联网服务商所提供的各种服务和功能特性各异，对资源的需求差异也很大。

5.2 数据局部性（Data Locality）

大多数场景下的基本设计原则：移动计算代码到数据所在地而非移动数据到计算任务所在地。

三种：

• 节点局部性：将计算任务分配到数据所在的机器节点。最优情形，完成计算无需任何数据传输。
• 机架局部性：计算任务和所需数据分属两个不同的计算节点，但两节点在同一个机架中。
• 全局局部性：需要跨机进行数据的网络传输，产生较大网络传输开销。

5.3 抢占式和非抢占式

对于强调优先级任务执行效率的调度策略来说，往往会采纳抢占式调度方式。

5.4 资源分配粒度

计算任务两层结构：作业级（Job）、任务级（Task）

一个作业由多个并发任务构成。 

• 作业级对应“群体分配（Gang Scheduler）”策略，或者“全分或不分（All-or-Nothing）”，将作业所需资源一次性分配完成。
• 任务级对应增量满足式分配策略。对于某个作业，只要分配部分资源就能启动一部分任务运行。
• 特殊的增量满足式分配策略：资源储备（Resource Hoarding）策略。分配到一定量的资源作业才能启动，作业可以先持有目前已分配的资源。

5.5 饿死和死锁

饿死：计算任务长时间无法获得开始执行所需的最少资源量，导致一直处于等待执行的状态。

死锁：资源调度不当导致整个调度系统无法继续正常执行。两个任务互相等待对方释放资源。

死锁必然表现为某些作业饿死，饿死不一定表示调度系统处于死锁状态。

5.6 资源隔离方法

当前资源管理系统大都采取了将各种资源封装在容器中的细粒度资源分配方法。

整个系统封装了众多资源容器，为了避免不同任务之间的相互干扰，需要提供容器间的资源隔离方法。

最常用手段Linux容器（Linux Container，LXC）

• 轻量级的内核虚拟化技术
• 依赖cgroups将任意进程进行分组化管理
• 可以有效隔离各类进程，也可以控制进程的资源占用情况

6. 三种资源管理和调度系统范型

6.1 集中式调度器

在整个系统中只运行一个全局的中央调度器实例。

所有资源请求都由其满足。

I单路径调度器

不论何种任务都采用统一的调度策略。

基本调度逻辑是采用融合多种考虑因素来综合计算每个任务的优先级，然后根据优先级来进行调度。

在高性能计算系统（HPC）中非常常见。

完全按顺序调度任务而无并发性。

II多路径调度器

针对不同任务执行不同调度策略。

类似于Switch-Case分支路径判断。

通过多线程等方式可以实现一定程度的并发性。

集中式调度器的缺点：

• 所有调度逻辑全部融入中央调度器，实现逻辑复杂，可扩展性差，支持不同类型的调度策略缺乏灵活性。
• 并发性能较差，比较适合小规模的集群系统。缺乏并行性会导致工作负载达到一定程度后调度系统工作饱和。

6.2 两级调度器 Two-Level Scheduler

• 中央调度器
• 框架调度器

中央调度器：可以看到集群中所有机器的可用资源并管理其状态。粗粒度的资源调度方式。

框架调度器：各个计算框架在接收到所需资源后，根据自身特性进一步细粒度分配从中央调度器获得的资源。

*只有中央调度器能够观察到所有集群资源的状态，而每个框架并无全局资源概念，只能看到中央调度器分配给自己的资源。 

优点及缺点：

• 可以实现并发性。整体调度性能较好，也适合大规模集群下的多任务高负载计算情绪，具有较好的扩展性。
• 由于中央调度器的存在，并没有实现严格的并发。中央调度器在做出资源分配给框架的决策过程中，必须依次顺序进行。

6.3 状态共享调度器 Shared-State Scheduler

每个计算框架可以看到整个集群中的所有资源，并采用相互竞争的方式去获取自己所需的资源。

再根据自身特性采取不同的资源调度策略。

即：

采取自由竞争的方式实现抢占式整体资源管理与调度。

相较两级调度器做出的改进：

• 通过并发控制增加了系统的并发性能。
• 每个计算框架可以获得全局的资源使用状况信息。

缺点：

如果存在大量资源竞争冲突，竞争失败者很可能需要重新执行任务，造成大量的资源浪费。

无法保证不同框架之间的资源分配公平性。

6.4 不同范型比较

• 发展过程是一个逐步弱化中央调度器功能二逐渐增强框架调度器自由度的过程。
• 不同范型适应不同应用场景。 
• 集中式调度器：小规模集群
• 两集调度器：负载同质的大规模集群。
• 状态共享调度器：负载异质性较强且资源冲突不多的大规模集群。