走进YARN资源管理与调度 | 青训营笔记

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

一、YARN概述。

1.初始调度系统—场景导入：

• 学校为改善学生生活新建了一所美食餐厅，餐厅座位有限且只能堂食；
• 各学院需缴纳一定管理费用后学生才能在该餐厅用餐，缴纳费用与分配的座位数成正比；
• 因餐厅物美价廉 环境干净，来该餐厅就餐的人络鲜不绝；

如何进行高效座位分配在保障就餐公平性的前提下让尽可能多的学生都能够及时就餐、尽可能多的座位被有效使用?

初始调度系统—一种简易分配模式：

• 各个学院:获得座位数
• 学院学生:按照学院组织
• 餐厅经理:分配餐厅座位
• 餐厅座位:有序排列放置
• 这种分配方式是否高效?
• 是否公平?

初始调度系统—优化的分配模式：

• 保障公平性
  • 学院间：低分配座位满足率优先
  • 学院内:先来先服务
• 保障高效性
  • 配备餐厅助手
  • 用餐小组负责人
• 保障高可用
  • 配置备用经理

是否还需要考虑其它因素?

• 如何满足 “尽可能多"?
  • 座位超售:分配座位大于总座位数
  • 学院超用：学院可以超分配座位
  • 座位超发: ”—个座位坐两个人”
  • 鼓励快餐:鼓励快速就餐离开
• 如何满足就餐学生个性化需求?
  • 用餐小组必须坐一个桌子
  • 用餐小组必须坐不同桌子
  • 用餐小组必须靠窗位置坐
  • 有重要活动同学需靠前就餐

调度系统演进—调度系统发展的背景：

• IT到DT时代的变革，注重数据价值；
• 数据计算方式的变革，注重计算效率；
• 企业对外服务需数以万计的硬件资源；
• 灵活调度、提高利用率是降本增效的关键问题；

2.调度系统演进-调度系统解决的问题：

• 用有限资源解决有限资源无法满足的需求时就需要调度;
• 调度系统主要解决资源请求和可用资源间的映射（Mapping)问题;

调度系统演进-调度系统预达的目标：

• 严格的多租户间公平、容量保障
• 调度过程的高吞吐与低延迟
• 高可靠性与高可用性保障
• 高可扩展的调度策略
• 高集群整体物理利用率
• 满足上层任务的个性化调度需求
• 任务持续、 高效、 稳定运行
• We want to have all of them.However...

调度系统演进-调度系统范型：

3.YARN设计思想-演化背景：

• Hadoop 1.0时代:
  • 可扩展性差
  • 可靠性差
  • 资源利用率低
  • 无法支持多种计算框架
• Hadoop 2.0时代:
  • 资源管理和任务控制解耦
  • YARN(Yet Another Resource Negotiator)支持多种计算框架的统一资源管理平台

离线生态：

面临挑战：

• 公平性:各租户能够公平的拿到资源运行任务
• 高性能:高调度吞吐、 低调度延迟，保障资源快速流转
• 高可用:集群要具备很强的容错能力
• 大规模:单集群规模提升(原生YARN 5K)
• 高集群资源利用率
• 高任务运行质量保障

4.YARN整体架构-系统架构：

• Resource Manager
  • 资源管理和调度
  • 任务生命周期管理
  • 对外进行交互
• Node Manager
  • 提供集群资源
  • 管理Container运行

YARN整体架构-任务运行生命周期核心流程：

二、YARN核心模块。

1.Resource Manager-整体架构：

Resource Manager-主要职责：

RM 负责集群所有资源的统一管理和分配，接收各节点汇报信息并按照一定策略分配给各个任务。

• 与客户端交互
• 启动和管理所有AM
• 管理所有NM
• 资源管理与调度
  • 组织资源(资源池)
  • 组织任务(队列)
  • 接收资源请求
  • 分配资源

Resource Manager状态机管理-RMA状态机：

• NEW SAVING: 收到任务后，创建RMApplmpl对象井将基本信息持久化;
• ACCEPTED: 调度器接受该任务后所处的状态，任务等待被分配资源
• RUNNING: 任务成功获取到资源井在节点运行;

Resource Manager状态机管理-RMAppAttempt：

• SCHEDULED: 通过合法性检查后所处的状态，开始为该任务分配资源；
• ALLOCATED SAVING: 收到分配的Container 后,在持久化完成前所处的状态；
• ALLOCATED: 信息持久化完成后所处的状态；
• LAUNCHED: RM的

ApplicationMasterLauncher与NM 通信以启动AM时所处的状态

Resource Manager状态机管理-RMContainer：

• RESERVED: 开启资源预留时，当前节点不能满足资源请求时所处的状态；
• ALLOCATED: 调度器分配一个Container给AM;
• ACQUIRED: Container被 AM 领走后的状态;
• EXPIRED: AM 获取到Container后，若在一定时间内未启动Container,RM会强制回收该Container:

Resource Manager状态机管理-RMNode：

• DECOMMISSIONED: 节点下线后的状态；
• UNHEALTHY : 节点处于不健康状态，健康检测脚本异常或破盘故障；
• LOST: 节点超过一定时间(默认10分钟)未与RM 发生心跳后所处的状态；

Resource Manager调度器分析-任务/资源组织：

• 任务按队组织
• 节点按Label组织

Resource Manager调度器分析-调度流程：

• AM与 RM心跳:记录资源请求
• 触发时机：节点心跳
• 找Label:获取所有队列
• 找队列：最“饥饿”队列优先
• 找任务:优先级高的任务优先
• 找资源请求：优先级高的请求优先

Resource Manager调度器分析-典型调度器：

2.Node Manager-整体架构：

Node Manager主要职责：

NM是节点代理，从AM接受命令（启停Container)并执行，通过心跳方式向RM汇报节点状态并领取命令(清理Container )

• 与RM交互
  • 心跳汇报节点状态
  • 领取RM 下达的命令
• 与AM交互
  • 启动容器
  • 停止容器
  • 获取容器状态

Node Manager状态机管理-Application：

• INTTING: Application 初始化状态，创建工作目录和日志目录；
• FINISHING CONTAINERS WAIT:调等待回收Container所占用的资源所处的状态；
• APPLCATION RESOURCE CLEANINGUP: Application 所有 Container 占用的资源被回收后所处的状态；

Node Manager状态机管理-Application：

• LOCALIZING:正在从HDFS 下载依赖的资源；
• EXITED WITH SUCCESS : Container 运行脚本正常退出执行；
• CONTAINER CLEANUP AFTER KILL:Container被kill后所处的状态

Node Manager状态机管理-LocalizedResource：

• DOWNLOADING:资源处于下载状态;
• LOCALZED:资源下载完成;
• FAILED:资源下载失败;

Node Manager节点健康检测机制：

节点健康检测机制可时刻掌握NM 健康状况并及时汇报给RM，RM 根据NM是否健康决定是否为其调度新任务。

• 自定义 Shell
  • NodeHealthScriptRunner 服务周期性执行节点健康状况检测脚本；
  • 若输出以 "ERROR"开头则不健康；
• 检测磁盘损坏数目
  • 判断磁盘损坏标准:若一个目录具有读、写和执行权限，则目录正常；
  • LocalDirsHandlerService 服务周期性检测N M本地磁盘好坏，坏盘数超过闻值则不健康；

YARN如何保证公平性？

三、重要机制。

1.调度策略-Fair Share 调度策略背景：

为什么需要Fair Share 调度策路？

• 实现队列间资源共享，提高资源利用率
• 缓解繁忙队列压力；

什么是Fair Share 调度策略?

• 队列空闲时按照一定策略将资源分配给其他活跃队列；

Fair Share 类型

• Steady Fair Share
• Instantaneous Fair Share

调度策略-Instantaneous Fair Share 定义：

• Instantaneous Fair Share 计算
• 定义
  • 所有队列Fair Share 之和<=TotalResource
  • S.minShare <= Fair Share <= S.maxShare;
• 目标
  • 找到一个R使其满足:
  • R*(All S.wieght) <= TotalResource;
  • S.minShare <= R* S.weight <= S.maxShare:
• 结果
  • 若S.minShare> R*S.weight, Fair Share=S.minShare
  • 若S.maxShare < R*S.weight, Fair Share= S.maxShare
  • 其他 Fair Share=R*S.weight

调度策略-Instantaneous Fair Share 计算逻辑：

• **计算Total Resource **
• 初始化R上限RMax
  • 获取所有non-fixed Schedulable 的 maxShare
  • 初始化R为1，每次翻倍
  • 直到所有Schedulable 分完所有资源
• 通过二分法寻找R[O.,RMax]
  • mid=(left +right)/2.0
  • 若plannedResourceUsedmotalResource, right= mid;
  • 若plannedResourceUsed< totalResource, left= mid;
  • 若plannedResourceUsed > totalResource right = mid:
• 计算Fair Share
  • 若S.minShare > right* S.weight Fair Share= S.minShare;
  • 若S.maxShare < right S. weight, Fair Share = S.maxShare:
  • 其他情况 Fair Share m right* S.weight

调度策略-DRF（Dominant Resource Fair）调度策略：

• 为什么需要DRF调度策略？
• 在保证公平性的前提下进行资源降维
• 什么是DRF 调度策略?
• DRF 是最大最小公平算法在多维资源上的具体实现；
• 旨在使不同用户的 “主分享量”最大化的保持公平；
• 最大最小公平算法:最大化最小资源需求的满足度
• 资源按照需求递增顺序分配；
• 获取的资源不超过自身需求；
• 未满足用户等价分享剩余资源；

调度策略-DRF（Dominant Resource Fair）调度策略描述：

DRF调度策略示例

• 场景： 系统有<9CPU,18G>，A每个任务需要<1CPU.4G>， 3每个任务需要<3CPU,1G>，对于A因为:1/9<4/18，所以A任务的主资源是内存，B 任务的主资源是CPU:
• 数学模型： 一定约束条件下的最优化问题，下面X代表A 任务的个数，y代表B任务的个数
  • 最大化资源分配max(x，y)的
  • 约束条件
    • (x+3y)<=9(CPU的约束）
    • (4x+ty)<=18(内存约束）:
    • 4x/18==3y/9(主资源公平约束）:
• 最终计算得到: x=3. y=2

调度策略-DRF（Dominant Resource Fair）调度策略计算逻辑：

R表示总资源量，有m个维度

C已经使用的资源量

si用户i的 “主分享量”

Ui分配给用户i的资源量

• 选择最小“主分享量”用户i
• Di用户i下一个任务资源需求量
• 若资源充足
  • 更新已使用资源量
  • 更新用户i的已分配资源量
  • 更新用户i的 “主分享量”

2.事件机制-状态机管理。

• 状态机由一组状态(初始状态、 中间状态和最终状态)组成，状态机从初始状态开始运行，接收一组特定事件，经过一系列中间状态后,到达最终状态并退出；
• 每种状态转换由一个四元组表示：转换前状态、 转换后状态、事件和回调函数;
• YARN定义了三种状态转换方式如下所示:

事件机制-事件处理模型：

• 所有处理请求都会作为事件进入系统；
• AsyncDispatcher 负责传递事件给相应事件调度器；
• 事件调度器将事件转发给另一个事件调度器或带有有限状态机的事件处理器；
• 处理结果以事件形式榆出 新事件会再次被转发，直至处理完成

YARN采用了基于事件驱动的并发模型，具有很强的并发性可提高系统性能。

3.容错机制--高可用性。

• RM高可用
• 热备方案 : Active Master 提供服务、 Standby Master 作为备节点；
• 基于共享存储的HA解决方案: 关键信息写入共享存储系统(ZK)
• 两种切换模式:
• 手动模式: "yarn rmadmin" 命令手动操作
• 自动模式: ZK的ActiveStandbyElector进行选主操作，ZK 中有一个锁节点，所有RM 竟争写一个子节点， ZK 保证最终只有一个RM能够创建成功，创建成功的为Active Master,
• Client、 AM、NM自动重试: 切主时各组件采用round-robin 方式尝试连接RM;
• NM高可用
• 关键信息存储至leveldb 数据库；
• 重启时从 yarn-nm-recovery 下的 leveldb 数据库加载数据；

四、公司实践。

1.Gang调度器-为什么需要开发Gang调度器？

流式作业和训练作业的调度需求与批处理有很 的不同:批处理强调高吞吐，而流式/训练类型作业更强调低延迟和全局视角；

• 调度缺乏全局视角
• 单App调度过慢
• App 间存在资源互锁

Gang调度器-Gang调度器有什么典型特点？

• 全局视角
  • 作业可自定义配置强弱约束；
  • 强约束:必须要满足的条件
  • 弱约束:尽量满足的约束；
• 低调度延迟
  • RM维护所有节点状态信息；
  • 资源请求同步分配，毫秒级返回；
• Gang性资源交付
  • 提供Al-or-Nothing语义；
  • 可满足的请求全部分配，否则返回失败;

Gang调度器-Gang调度器调度流程：

• 强约束阶段： 过滤掉不符合条件的节点
• 弱约束阶段: 选择合适的节点分配资源(不排序，时间复杂度O(n))
  • Quota 平均:分配后节点已使用资源尽可能平均
    • 总请求资源为V1，总节点数为N，已用资源为U，节点目标资源为:S=(V1+U/N）,遮历所有节点，每个节点分配S-Un即可；
  • 跳过高load 节点:优先往低load 节点调度
    • 满足load 闽值节点 N1，不满足N2，优先把N1剩余资源分配完，分配后未满足资源量为V2,每个节点分配 V2/N2:
• 兜底分配

2.反调度器-为什么需要开发反调度器？

• 调度器的调度决策受 “时空”限制
  • 时 :触发调度时刻；
  • 空 :触发调度时集群状态；
• 任务运行和集群状态高动态性
  • 任务资源使用随流量变化而不断波动
  • 调度过程持续进行，集群状态持续变化;
• 需要持续保证最初调度决策的正确性

反调度器-反调度流程：

• 根据AM请求中的强约束，构造强约束集；
• 遇历强约束集选择不再符合强约束条件的节点；
• 追历异常节点下的Container，选择需要进行反调度的Container；
• 将反调度Container列表随心跳返回给AM;

反调度器-反调度与Gang调度器关系：

反调度器是Gang 调度器的 “伴侣”

• 不同点:
  • 发挥作用时机不同
  • 处理机制完全相反
• 相同点:
  • 反调度器是Gang调度器的补充
  • 共同保障资源持续合理分配;

3.单集群规模突破50K-为什么需要提升单集群规模？

• 更好的资源池化和资源共享

  • 资源池更大，利于资源分时复用；
  • 资源高效共享，提高集群资源利用率；

• 降低运维成本

  • YARN原生单集群仅支持5K节点
  • 每多一个集群，运维负担就会加重

单集群规模突破50K-RPC瓶颈：

• RPC层:接收请求回结果
  • RPC 处理时间 5ms andler 默认 80 线程
  • 消费吞吐瓶颈约 16K/s,RPC Server Queue 易打满；

单集群规模突破50K-Dispatcher瓶颈：

• Dispatcher层：特事件传对的件调度器
• 生产速率过大，AsyncDispatcher Queue 容易 Pending
• 消费速率过低 NODE UPDATE 事件处理过慢，2K/s 瓶颈

单集群规模突破50K-Scheduler瓶颈：

• Scheduler层：真正调度
• FSLeafQueue 单Container 分配延迟高，存在空转

单集群规模突破50K-心跳反压机制：

心跳动态调整 ：将 NM节点心跳周期改为根据RM的压力动态调整

单集群规模突破50K-多线程调度：

多线程调度： 对节点按 hashcode 放到对应的Scheduler Queue

单集群规模突破50K-其他优化：

• 事件精简：对内部事件梳理调整，精准修改了一些事件处理逻辑
• 空转优化:调度时过滤不需要资源的App，减少空转
• 内存单位优化：修改内存单位(int-→ long)突破单集群21亿MB限制
• 切主优化:通过对切主过程深度优化，将切主时间控制在秒级

总结

经过本次课程的学习，我学会了Resource Manger和Node Manger的整体架构和主要责任，YARN系统中Fair Share和DRF两种典型的调度策略，并知道了Gang Scheduler调度与原生调度Fair Scheduler的关系：

两个调度器会并存在 RM 中，当用户可以配置使用，默认使用原生调度器(Fair Scheduler)

Gang Scheduler 不是一个完整的 Scheduler，它只负责决定哪个 container 被分配到哪台机器上，不负责完整的container生命周期管理，这些管理工作依然由Fair Scheduler负责

两种调度模式在调度资源时会争抢Node级别的锁，各自调度。