这是我参与「第四届青训营 」笔记创作活动的第15天.

背景：

1. 阅读书籍《大数据日知录》，概要性了解大数据是什么、大数据领域常用的算法与数据结构、资源管理与任务调度系统设计的基本问题与典型调度策略；

2. 阅读书籍《Hadoop 技术内幕 - 深入解析 YARN 架构设计与实现原理》，概要性了解 YARN 设计理念、关键模块 Resource Manager 和 Node Manager 的主要职责和功能；

3. 阅读论文《 Apache Hadoop YARN: Yet Another Resource Negotiator》，了解 YARN 的核心实现；

一、YARN概述

在前面的课程中我们学习了各种各样针对不同使用场景的计算引擎，例如：Flink、Spark 等，使用这些计算引擎的任务最终都需要运行在集群的节点上，如果调度这些任务就是本模块内容所要解决的问题。

下面我们开启《资源和调度》模块，资源和调度主要解决大规模集群中资源管理和任务调度相关问题。在本模块中主要会讲解两个典型系统：主要针对离线业务场景的 Hadoop YARN 系统，主要针对在线服务场景的 Kubernetes。

• 在《走进 YARN 资源管理与调度》课程中，会讲解 YARN 系统的设计思想和整体架构，两个核心模块 Resource Manger 和 Node Manager 的整体架构和主要职责，YARN 系统中 Fair Share 和 DRF 两种典型的调度策略， YARN 系统内部的事件处理机制， YARN 系统在高可用性方面的实现逻辑和 Failover 处理流程。

1、初识调度系统-场景导入

（1）简易分配模型

（2）优化的分配模型

• 低分配满足率：已分配的座位数比上获取的座位数。

2、调度系统演进

调度系统设计的基本问题

• 资源异质性与工作负载异质性

异质性通常指组成元素构成的多元性和相互之间较大的差异性。资源异质性是从系统所拥有的资源角度来看的，对于大型数据中心来说，其采购往往是分批次的，不同批次的机器硬件配置和计算存储资源都存在较大差异，很难保证采用完全相同的配置，目前主要通过将资源分配单位细粒度划分以及虚拟化技术来解决；工作负载异质性是从系统提交的任务角度来看的，负载类型多样化（流处理、批处理、内存计算、在线服务等），任务偏好多样化和动态化（任务的约束条件、运行过程中资源使用动态变化），资源需求多样化（CPU，内存，GPU，IO等），例如对外服务要保证高可用和快速响应，对于批处理任务要保证快速调度等。

• 数据局部性

大数据场景下因为数据传输开销要远大于计算逻辑传输开销，因此往往将计算任务推送到数据存储所在地进行，这种设计哲学一般被称为数据局部性问题。在资源管理与调度语境下一般存在3种类型数据局部性：节点局部性，机架局部性和全局局部性。节点局部性完成计算不需要进行数据传输，机架局部性需要在机架之间进行数据传输存在一定开销，其它情况则属于全局局部性需要跨机架进行网络传输进而产生较大的网络传输开销，因此最优的方式是尽可能保证节点局部性。

• 抢占式与非 抢占式调度

在多用户多任务场景下，面对已分配资源，资源管理与调度系统有两种不同类型的调度方式：抢占式调度与非抢占式调度。抢占式调度指的是当系统资源不足或存在资源竞争时高优先级的任务可以抢占低优先级任务的资源；非抢占式调度，每次只允许从空闲资源中分配，空闲资源若不足则须等待其它任务释放资源后才能继续推进，mesos采用非抢占式调度。两种方式各有特点，一般如果强调高优先级任务执行效率的调度策略会采用抢占式调度，强调资源公平分配的调度会采用非抢占式调度。

• 资源分配粒度

大数据场景下的计算任务往往呈现层级结构，例如：作业级（Job）-任务级（Task）-实例级（Instance），从计算任务视角来看，此时资源调度系统就面临资源分配粒度问题，资源分配粒度主要存在三种方式：（1）群体分配策略（Gang Scheduler），即要么全满足要么全不满足，Flink和MPI任务依赖这种方式；（2）增量满足式分配策略，只要分配部分资源就可以启动运行，MR采用这种方式；（3）资源储备策略，资源达到一定量才能启动作业，在未获得足够资源时作业可以先持有目前已经分配的资源并等待其他作业释放资源，调度系统不断获取新资源并进行储备和积累，直到分配到的资源量达到最低标准后开始运行，在作业启动前已经分配的资源处于闲置状态。

• 饿死与死锁问题

饿死是由于调度策略不当而导致计算任务长时间无法获得开始执行所需要的最少资源量，例如支持优先级调度时，如果不断出现高优先级任务，那么低优先级任务可能饿死；死锁是由于资源分配不当而导致整个调度系统无法正常执行，例如在资源储备策略下，如果AB两个作业启动作业需要的最小资源为2/3，那么如果两个任务被分配了1/2的资源时，就导致死锁。调度系统出现死锁必然表现为某些作业处于饿死状态，但计算任务饿死的情景并不一定意味着调度系统处于死锁状态。

• 资源隔离方法

为了减少任务之间的干扰需要进行一定的隔离措施，LXC是一种轻量级的内核虚拟化技术，LXC在资源管理方面依赖于 Linux 内核的 cgroups 子系统，cgroups 子系统是 Linux 内核提供的一个基于进程组的资源管理框架，可以为特定的进程组限定可以使用的资源。其他技术有Intel RDT。

（1）发展背景

（2）调度系统解决的问题

（3）调度系统预达的目标

集群资源管理与调度系统的核心目标是：  设计出更好的资源管理与调度策略，使得整个集群在保障任务SLA的前提下能够实现更高的资源利用率、更快的计算任务完成速度。

• 高可扩展性：因为不同节点要求不同。

（4）调度系统范型（前两个使用最多）

• 集中式调度系统

  • 产生背景：该调度系统是大规模数据分析和云计算出现的雏形，主要进行大规模的集群管理以提高数据处理能力。

  • 基本原理：中心式调度系统融合了资源管理和任务调度，有一个中心式的 JobTracker 负责进行集群资源的合理分配、任务的统一调度、集群计算节点信息的统计维护、任务执行过程中的状态管理等。

  • 优点：

    • JobTracker 能够感知集群中所有资源和任务的执行状态，能够进行全局最优的资源分配和调度，避免任务间的干扰，适当进行任务抢占，保证任务计算效率和服务质量；
    • 架构模型简单，只有一个全局的管理者负责进行所有管理。

  • 缺点：

    • JobTracker 作为集群的中心，存在单点瓶颈问题，不能支持大规模集群；
    • 内部实现异常复杂，一个调度器中需要实现所有的功能模块，可扩展性差；
    • 负载变更会导致系统需要进行不断的迭代，这将增加系统的复杂性，不利于后期的维护和扩展；
    • 只支持单类型的任务，MR 类型的批处理任务；

  • 典型的调度系统：Hadoop1.*版本；K8S中的kube-scheduler，Quasar。

• 两层调度系统

  • 产生背景：为了解决集中式调度系统的扩展性问题，系统实现复杂，可扩展性差，不能支持不同类型任务等缺点。

  • 实现原理：将资源管理和任务调度解耦。集群资源管理器负责维护集群中的资源信息并将资源分配给具体的任务，任务管理器负责申请资源并将申请到的资源根据用户逻辑进行细分和具体的任务调度。

  • 优点：

    • 资源管理器只负责资源分配，任务调度由应用完成，提高了系统的扩展性；
    • 任务调度逻辑由具体的任务完成，能够提供对不同类型任务的支持；
    • 内部实现模块化，利于维护和扩展；

  • 缺点：

    • 任务无法感知全局的资源情况，只能基于request/offer来进行资源获取，无法有效避免异构负载之间的性能干扰问题；
    • 任务调度和资源管理解耦不利于实现多任务间的优先级抢占；
    • 所有任务的资源请求都需要资源管理器进行处理，此外其还需要与节点管理器之间维持通信，导致资源管理器存在单点问题；

  • 典型系统：Mesos，YARN，Fuxi

  •   Mesos 最先将资源管理和任务调度解耦的 offer-based（基于资源供应）方案，其有一个中心的资源管理器，通过分配策略（DRF）将资源分配给不同的计算框架，每个计算框架依据自身的逻辑、资源偏好等采取增量或者 All-or-Nothing 的方式决定接受还是拒绝分配的资源，计算框架根据分配到的资源进行下一步的资源分配和任务执行。

• 共享状态调度系统

  • 产生背景：前面的调度器存在一个问题就是计算框架在进行资源申请的时候无法获知到集群的全局资源信息，这就导致无法进行全局最优的调度，共享状态调度器就提供了这个问题的一种解决方式。

  • 基本原理：是一个半分布式的架构，通过共享集群状态为应用提供全局的资源视图，并采用乐观并发机制进行资源申请和释放，来提高系统的并发度。

  • 优点：

    • 支持全局最优调度；
    • 能够一定程度的提高并发度；

  • 缺点：

    • 高并发资源请求下会造成频繁的资源竞争；
    • 不利于资源分配的公平性；
    • 资源全局副本维护模块存在单点瓶颈；

  • 典型系统：Omega

• 分布式调度系统

  • 产生背景：提高系统吞吐率和并发度

  • 基本原理：分布式调度器之间没有通讯协作，每个分布式调度器根据自己最少的先验知识进行最快的决策，每个调度器单独响应任务，总体的执行计划与资源分配服从统计意义。

  • 优点：提高吞吐量和并发度

  • 缺点：

    • 调度质量得不到保障；
    • 资源非公平分配；
    • 不能支持多租户管理；
    • 不能避免不同任务之间的性能干扰；

  • 典型系统：Sparrow 是一个完全的去中心化的分布式调度系统，通常用于满足低延迟高吞吐的短任务场景。系统包含多个调度器，这些调度器分布在集群的节点上，作业可以提交给任何一个分布式调度器。其核心是采用随机调度模型，利用二次幂采样原理针对每个任务随机采样出两个服务节点，选择任务等待队列最短的一个作为调度结果，也可以采用异步预定的方式进行资源调度。实验证明近似最优解能够有效的满足大规模毫秒调度性能的需求。

• 混合式调度系统

  • 产生背景：针对一些特定的混合任务调度场景，某些任务需要比较快的调度响应，而其他任务不需要很快的调度响应，但是需要保证调度质量。

  • 基本原理:设计两条资源请求和任务调度路径，保留两层调度的优点，同时兼顾分布式调度器的优势。对于没有资源偏好且响应要求高的任务采用分布式调度器，对于资源调度质量要求较高的采用集中式资源管理器进行资源分配。

  • 优点：

    • 能够针对不同类型的任务进行不同方式的调度；
    • 为应用层提供灵活的接口和性能保障；

  • 缺点：复杂化了计算框架层的业务逻辑；调度系统内部也需要针对两种不同的调度器进行协同处理；

  • 典型调度系统：Mercury:微软的混合调度机制，中心式调度器对调度质量要求较高的作业进行公平的资源分配，分布式调度器对时间敏感和吞吐率要求高的作业进行调度。

3、YARN设计思想

（1）演化背景

1. Hadoop 2.0 时代：解决了 Hadoop 1.0 时代中 HDFS 和 MR 中存在的问题：

• YARN(MR v2) 在 MR v1 的基础上发展而来，将资源管理和任务控制解耦，分别由 Resource Manager 和 ApplicationMaster 负责，是一个两层调度系统；

• Hadoop YARN(Yet Another Resource Negotiator) 支持多种计算框架的统一资源管理平台；

• 可扩展性差：JobTracker 兼备资源管理和任务控制，是系统最大的瓶颈；

• 可靠性差：采用 master/slave 结构，master 存在单点故障问题；

• 资源利用率低：基于槽位的资源分配模型，各槽位间资源使用差异大；

• 无法支持多种计算框架：只支持 MR 任务，无法支持其他计算框架；

（2）离线生态

• 用户逻辑层：数据分析任务、模型训练任务等

• 作业托管层：管理各种类型上层任务

• 分布式计算引擎层：各种针对不同使用场景的计算引擎，例如：MR、Spark、Flink 等

• 集群资源管理层：YARN

• 裸金属层：众多物理节点组成

（3）面临挑战

（4）系统架构

• Resource Manager

  • 整个集群的大脑，负责为应用调度资源，管理应用生命周期；
  • 对用户提供接口，包括命令行接口，API， WebUI 接口；
  • 可以同时存在多个RM、，同一时间只有一个在工作，RM 之间通过 ZK 选主；

• Node Manager

  • 为整个集群提供资源, 接受 Container 运行；
  • 管理Contianer的运行时生命周期, 包括Localization, 资源隔离, 日志聚合等；

YARN上运行的作业在运行时会访问外部的数据服务，常见的如 HDFS， Kafka 等；在运行结束后由 YARN 负责将日志上传到 HDFS；

• RM有多个，但是只有一个有用，当RM失效，ZK（存储重要元数据信息）重选一个RM。选举成功后，ZK交信息给RM,保障切主前后信息相同。

（5）任务运行生命周期核心流程

1. Client 获取 ApplicationID，调用 ApplicationClientProtocol #getNewApplication。

2. RM 返回 GetNewApplicationResponse，其中主要包括：ApplicationID、最大可申请资源以及相关配置。

3. Client 将任务运行所需的资源上传至HDFS的指定目录下，并初始化AM配置，主要构造 ApplicationSubmissionContext （应用ID、应用名称、所属队列、应用优先级、应用类型、应用尝试次数、运行AM所需要的资源等）和 ContainerLaunchContext（容器运行所需的本地资源、容器持有的安全令牌、应用自有的数据、使用的环境变量、启动容器的命令行等）。

4. Client 将 AM 提交至 RM，调用 ApplicationClientProtocol #submitApplication。

5. RM 根据一定的分配策略为 AM 分配container，并与 NM 通信。

6. NM 启动 AM。

7. AM 从 HDFS 下载本任务运行所需要的资源并进行初始化工作。

8. AM 向 RM 注册和申请资源。ApplicationMasterProtocol # registerApplicationMaster，注册信息包括：AM所在节点的主机名、AM的对外RPC服务端口和跟踪应用状态的Web接口；ApplicationMasterProtocol # allocate，相关信息封装在 AllocateRequest中包括：响应ID、申请的资源列表、AM主动释放的容器列表、资源黑名单、应用运行进度。

9. RM 接受 AM 请求后，按照调度算法分配全部或部分申请的资源给 AM，返回一个 AllocateResponse 对象，其中包括：响应ID、分配的container列表、已完成的container状态列表、状态被更新过的节点列表、资源抢占信息（强制收回部分和可自主调配部分）等。

10. AM 获取到资源后与对应的 NM 通信以启动 container， ContainerManagementProtocol # startContainers

11. NM 启动container。

12. Container 从 HDFS 下载任务运行必要的资源。

13. Container 在运行过程中与AM通信及时汇报运行情况。

14. 任务运行完成后 AM 向 RM 注销，ApplicationMasterProtocol # finishApplicationMaster()。

二、YARN核心模块

1、RM

（1）整体架构

（2）主要职责

（3）状态机管理

• RMApp状态机

NEW-Saving：如果不持久化，可能导致切主后数据丢失，进而导致任务永远异常。持久化是因为不可避免的RM总发生故障。关键信息随时间持久化。

• RMAppAttempt

• RMContainer

• RMNode

（4）调度器分析

• 任务资源组织

• 调度流程： YARN 调度流程由心跳触发：

• AM 定期与 RM 保持心跳，并将资源请求记录在 RM 中；

• 触发时机: 由节点心跳触发针对此节点的调度；

• 找 Label: 根据节点 Label 找到对应 Lable 下的所有队列；

• 找队列: 将队列进行 DRF 排序, 找到当前最“饥饿”的队列；

• 找应用: 将此队列内所有应用按照优先级进行排序(优先级由用户提交时指定), 找到优先级最高的应用, 优先级相同时按DRF 算法排序；

• 找资源请求: 将此应用内的所有资源请求按照优先级排序(优先级由计算引擎指定), 找到优先级最高的资源请求进行资源分配；

• 典型调度器

2、NM

（1）主要职责

（2）状态机管理

• Application

• Container

• LocalizedResource

（3）节点健康检测机制

• 自定义 Shell

  • NodeHealthScriptRunner 服务周期性执行节点健康状况检测脚本；
  • 若输出以 “ERROR”开头，节点处于 unhealthy 状态并随心跳上报给 RM，RM 拉黑节点并停止分配新任务；
  • 脚本一直执行，一旦节点变为 healthy 状态，RM 会继续为该节点分配新任务；

• 检测磁盘损坏数目

  • LocalDirsHandlerService 服务周期性检测 NM 本地磁盘好坏，一旦发现正常磁盘比例低于一定阈值则节点处于 unhealthy 状态；
  • NM 判断磁盘好坏的标准：如果一个目录具有读、写和执行权限，则目录正常；

三、重要机制

1、调度策略

（1）Fair Share调度策略背景

（2）Instantaneous Fair Share

• 计算逻辑

（3）DRF（Dominant Resource Fair）

• 调度策略描述

• 计算逻辑

2、事件机制

（1）状态机管理

（2）事件处理模型

3、容错机制

（1）高可用性

RM 高可用

热备方案：集群中存在一个对外服务的 Active Master 和若干 Standby Master，一旦 Active Master 故障，立即采取一定策略选取某个 Standby Master 转换为 Active Master 正常对外提供服务；

基于共享存储的 HA 解决方案：Active Master 不断将信息写入共享存储系统（ZK）,故障切换时 Standby Master 从共享存储恢复数据，待信息完全同步后切换至 Active Master;

两种切换模式：

• 手动模式：使用 “yarn rmadmin”命令将现在的 Active Master 切换为 Standby 并选择一个 Standby 切换为 Active Master；

• 自动模式：使用 ZK 的 ActiveStandbyElector 进行选主操作，ZK 中有一个 /yarn-leader-election/yarn1 的锁节点，所有 RM 在启动时去竞争写一个 Lock 子节点：/yarn-leader-election/yarn1/ActiveBreadCrumb，该节点是临时节点。ZK 保证最终只有一个 RM 能够创建成功，创建成功的为 Active Master;

Client 、 AM、NM 自动重试：切主时各组件基于配置文件中的所有 RM 采用 round-robin 轮询方式不断尝试连接 RM 直到命中 Active Master；

四、公司实践

1、Gang调度器

（1）为什么需要开发Gang调度器

原生 YARN 的架构设计目标专注在离线 Batch 类计算作业上面，对于高吞吐追求极致，但是对于 latency 和全局约束上没有很好支持。流式/模型训练任务的出现，需求与 Batch 类相差较大， 当前YARN 的架构已经无法很好的满足这部分任务。目前 Flink 作业和模型训练类的作业在 YARN 上面运行， 在调度层面都遇到三个问题:

1. 调度缺乏全局视角

   1. 由于 YARN 的调度以 NM 心跳触发，各个心跳彼此独立, 因此没有全局的视角；

   2. 目前为了达到尽量全局的视角，目前有两种应对方法:

      • YARN 管理员增加了一些单个节点的过滤条件，在尝试若干个节点后再放宽过滤条件；
      • 应用 AM 向 YARN 申请尽可能多的资源，经过自己的筛选后再释放掉不符合预期的资源；

2. 单个 Application 调度过慢

   1. 由于 YARN 架构设计是全异步的，由 NM 的心跳触发调度，即使整个集群有闲置资源也需要等待心跳才能进行分配；
   2. 由于 AM 的申请也是异步的， 导致 AM 至少需要两次心跳才能得到想要申请的资源(第1次只是提出申请，第 2 次能拿到两次心跳之间已经调度分配的 container)；

3. Application 之间存在资源互锁情况

   1. YARN 支持多个应用按 share 同时分配资源，导致部分请求存在互锁的情况, 即:

      • 假设整个集群目前有 15 个核, A作业和B作业都需要 10 个核才能运行, 但是 A 申请到了 7 个, B申请了 8 个, 最终A和B都无法启动, 并且这些资源也无法被其它人使用；
      • 这种情况在资源稀缺(如 GPU )时会表现得特别明显；

（2）Gang调度器有什么典型特点

（3）Gang 调度器调度流程

• 选择 App

  • 基于公平性策略对所有队列排序并选择一个队列；
  • 基于公平性策略对队列内的任务排序并选择一个任务；

• 分配资源

  • 强约束阶段：过滤掉不符合条件的节点

  • 弱约束阶段：选择合适的节点分配资源（不排序，时间复杂度 O(n)）

    • Quota 平均：分配后节点已使用资源尽可能平均。总请求资源为 V1，总节点数为 N，已用资源为 U，节点目标资源为：S = (V1 + U)/N，遍历所有节点，每个节点分配 S - Un 即可；
    • 跳过高 load 节点：优先往低 load 节点调度。满足 load 阈值节点 N1，不满足 N2，优先把 N1 剩余资源分配完，分配后未满足资源量为 V2，每个节点分配 V2/N2;
    • 兜底分配

（4）字节内部使用场景

2、反调度器

（1）为什么需要开发反调度器

• 调度器的调度决策受“时空”限制

在目前系统中，当有资源请求到来时，调度器只根据资源请求内容和当前时刻集群状态信息做出正确的调度决策，一旦资源请求与空闲资源匹配完成则本次调度过程结束，调度器不会维护当前资源请求下任务和集群的后续状态信息。因此，调度器的调度决策受“时空”限制，“时”表示触发调度时的时刻，“空”表示触发调度时集群的状态。

• 任务运行和集群状态高动态性

在大规模集群中，任务运行过程和集群状态具有高动态性。对于任务来说，其资源使用量会伴随着请求流量的变化而不断波动。对于集群来说，随着任务调度过程的持续进行、集群节点的添加和故障、集群节点标签的改变等，集群状态每时每刻都在发生变化。

• 需要持续保证最初调度决策的正确性

任务配置的调度约束在运行过程中需要持续被满足

（2）反调度流程

（3）反调度器与Gang调度器关系

反调度器与 Gang 调度器关系：是 Gang 调度器的“伴侣”

• 两者不同点

  • 发挥作用的时机不同。调度器在资源请求到来时根据当前时刻集群信息进行资源分配。反调度器在任务运行过程中，检测出不再正确的调度决策并进行修正。
  • 处理机制相反。调度器负责根据调度策略分配container到计算节点。反调度器负责根据反调度策略清理计算节点上的container。

• 两者联系

  • 反调度器是调度器的修正和补充，在反调度器的恢复过程中需要通过调度器进行新container的申请，两者共同促进资源的合理分配。

（4）字节内部使用场景

3、单集群规模50K

（1）为什么需要提升单集群规模

（2）RPC瓶颈

（3）Dispatcher瓶颈

（4）Scheduler瓶颈

（5）心跳反压机制

（6）多线程调度

（7）其他优化