青训营 走进 YARN 资源管理和调度
概述
2022の夏天,半壶水响叮当的我决定充实一下自我
一、内容介绍
青训营
总述
本节课程主要分为四个方面进行阐释:
- YARN 概述:从食堂分配座位场景导入,初识调度系统;介绍调度系统发展的背景、解决的问题、目标和范型;Hadoop YARN 的设计思想和整体架构;
- 核心模块:对 YARN 中两个核心模块 Resource Manager 和 Node Manager 进行详细阐释,介绍其整体架构、主要职责、核心功能;
- 重要机制:介绍 YARN 在调度公平性保障的重要调度策略:Fair Share 和 DRF 调度策略;介绍 YARN 系统内部的事件机制和高可用机制;
- 公司实践:介绍字节跳动在调度功能、调度性能和集群利用率提升方面的工作,包括:Gang 调度器、反调度器、单集群规模突破 50K;
课前
- 阅读书籍《大数据日知录》,概要性了解大数据是什么、大数据领域常用的算法与数据结构、资源管理与任务调度系统设计的基本问题与典型调度策略;
- 阅读书籍《Hadoop 技术内幕 - 深入解析 YARN 架构设计与实现原理》,概要性了解 YARN 设计理念、关键模块 Resource Manager 和 Node Manager 的主要职责和功能;
- 阅读论文《 Apache Hadoop YARN: Yet Another Resource Negotiator》,了解 YARN 的核心实现;
课程回顾
在前面的课程中我们学习了各种各样针对不同使用场景的计算引擎,例如:Flink、Spark 等,使用这些计算引擎的任务最终都需要运行在集群的节点上,如果调度这些任务就是本模块内容所要解决的问题。
下面我们开启《资源和调度》模块,资源和调度主要解决大规模集群中资源管理和任务调度相关问题。在本模块中主要会讲解两个典型系统:主要针对离线业务场景的 Hadoop YARN 系统,主要针对在线服务场景的 Kubernetes。
- 在《走进 YARN 资源管理与调度》课程中,会讲解 YARN 系统的设计思想和整体架构,两个核心模块 Resource Manger 和 Node Manager 的整体架构和主要职责,YARN 系统中 Fair Share 和 DRF 两种典型的调度策略, YARN 系统内部的事件处理机制, YARN 系统在高可用性方面的实现逻辑和 Failover 处理流程。最后会介绍字节跳动公司内根据业务场景对 YARN 系统的优化,主要包括:Gang 性调度器设计与应用、单集群规模突破 50K 优化、反调度器设计与应用。
- 在 《深入理解 K8S 资源管理与调度》课程中,会讲解 K8S 发展的背景和基本概念,K8S 中的资源管理机制,K8S 中的资源调度方式,以及字节跳动公司内部针对在线业务场景所做的优化。
二、YARN概述
从餐厅分配座位场景导入,初识调度系统;介绍调度系统的演进过程; Hadoop YARN的设计思想和整体架构;
2.1 初识调度系统
2.1.1 场景导入
- 学校为改善学生生活新建了一所美食餐厅, 餐厅座位有限且只能堂食;
- 各学院需缴纳一定管理费用后学生才能在该餐厅用餐,缴纳费用与分配的座位数成正比;
- 因餐厅物美价廉、环境干净,来该餐厅就餐的人络绎不绝; 如何进行高效座位分配在保障就餐公平性的前提下让尽可能多的学生都能够及时就餐、尽可能多的座位被有效使用?
2.1.2 初识调度系统 - 一种简易分配模型
- 各个学院:获得座位数
- 学院学生:按照学院组织
- 餐厅经理:分配餐厅座位
- 餐厅座位:有序排列放置 这种分配方式是否高效?是否公平?
2.1.3 初识调度系统 – 优化的分配模型
- 保障公平性
- 学院间:低分配座位满足率优先
- 学院内:先来先服务
- 保障高效性
- 配备餐厅助手
- 用餐小组负责人
- 保障高可用
- 配置备用经理
是否还需要考虑其它因素?
- 如何满足“尽可能多”?
- 座位超售:分配座位大于总座位数
- 学院超用:学院可以超分配座位
- 座位超发:“—个座位坐两个人”
- 鼓励快餐:鼓励快速就餐离开
- 如何满足就餐学生个性化需求?
- 用餐小组必须坐一个桌子
- 用餐小组必须坐不同桌子
- 用餐小组必须靠窗位置坐
- 有重要活动同学需靠前就餐
2.1.4 调度系统演进 – 调度系统发展的背景
- IT到DT时代的变革,注重数据价值;
- 数据计算方式的变革,注重计算效率;
- 企业对外服务需数以万计的硬件资源;
- 灵活调度、提高利用率是降本增效的关键问题;
2.2 调度系统演进
2.2.1 调度系统演进 - 调度系统解决的问题
- 用有限资源解决有限资源无法满足的需求时就需要调度;
- 调度系统主要解决资源请求和可用资源间的映射(Mapping) 问题;
2.2.2 调度系统演进 – 调度系统预达的目标
- 严格的多租户间公平、容量保障
- 调度过程的高吞吐与低延迟√高可靠性与高可用性保障√高可扩展的调度策略√高集群整体物理利用率
- 满足上层任务的个性化调度需求√任务持续、高效、稳定运行
- We want to have all of them... However...
2.2.3 调度系统演进 – 调度系统范型
2.3 YARN设计思想
2.3.1 YARN设计思想 – 演化背景
2.3.2 YARN设计思想 – 离线生态
2.3.3 YARN设计思想–面临挑战
- 公平性:各租户能够公平的拿到资源运行任务
- 高性能:高调度吞吐、低调度延迟,保障资源快速流转
- 高可用:集群要具备很强的容错能力
- 大规模:单集群规模提升(原生YARN 5K)
- 高集群资源利用率
- 高任务运行质量保障
2.4 YARN整体架构
2.4.1 YARN整体架构 – 系统架构
- Resource Manager
- 资源管理和调度
- 任务生命周期管理
- 对外进行交互
- Node Manager
- 提供集群资源
- 管理Container运行
2.4.2 YARN整体架构 – 任务运行生命周期核心流程
三、核心模块
对YARN中两个核心模块Resource Manager和Node Manager进行详细阐释,介绍其整体架构、主要职责、核心功能;
3.1 Resource Manager
3.1.1 整体架构
3.1.2 主要职责
RM负责集群所有资源的统一管理和分配,接收各节点汇报信息并按照一定策略分配给各个任务。
- 与客户端交互
- 启动和管理所有AM
- 管理所有NM
- 资源管理与调度
- 组织资源(资源池)
- 组织任务(队列)
- 接收资源请求
- 分配资源
3.1.3 状态机管理
3.1.3.1 RMApp 状态机
- NEW SAVING:收到任务后,创建RMApplmpl对象并将基本信息持久化;
- ACCEPTED:调度器接受该任务后所处的状态,任务等待被分配资源;
- RUNNING:任务成功获取到资源并在节点运行;
3.1.3.2 RMAppAttempt
- SCHEDULED:通过合法性检查后所处的状态,开始为该任务分配资源;
- ALLOCATED_SAVING:收到分配的Container后,在持久化完成前所处的状态;
- ALLOCATED:信息持久化完成后所处的状态;LAUNCHED: RM的
- ApplicationMasterLauncher 与NM通信以启动AM时所处的状态;
3.1.3.3 RMContainer
- RESERVED:开启资源预留时,当前节点不能满足资源请求时所处的状态;
- ALLOCATED:调度器分配一个Container给AM;
- ACQUIRED: Container被AM领走后的状态;
- EXPIRED:AM获取到Container后,若在一定时间内未启动Container,RM会强制回收该Container;
3.1.3.4 RMNode
- DECOMMISSIONED:节点下线后的状态;
- UNHEALTHY:节点处于不健康状态,健康检测脚本异常或磁盘故障;
- LOST:节点超过一定时间(默认10分钟)未与RM发生心跳后所处的状态;
3.1.4 调度器分析
3.1.4.1 任务/资源组织
- 任务按队列组织
- 节点按Label组织
3.1.4.2 调度流程
- AMRM心跳:记录资源请求
- 触发时机:节点心跳
- 找Label:获取所有队列
- 找队列:最“饥饿”队列优先
- 找任务:优先级高的任务优先
- 找资源请求:优先级高的请求优先
3.1.4.3 典型调度器
3.2 Node Manager
3.2.1 整体架构
3.2.2 主要职责
NM是节点代理,从AM接受命令(启停Container)并执行,通过心跳方式向RM汇报节点状态并领取命令(清理Container) 。
- RM交互
- 心跳汇报节点状态
- 领取RM下达的命令
- AM交互
- 启动容器
- 停止容器
- 获取容器状态
3.2.3 状态机管理
3.2.3.1 Application
- INITING:Application初始化状态,创建工作目录和日志目录;
- FINISHING_CONTAINERS_WAIT:调等待回收Container所占用的资源所处的状态;
- APPLICATION_RESOURCE_CLEANINGUP:Application所有Container 占用的资源被回收后所处的状态;
3.2.3.2 Container
- LOCALIZING:正在从HDFS下载依赖的资源;
- EXITED_WITH_sUCCESS: Container运行脚本正常退出执行;
- CONTAINER_CLEANUP_AFTER_KILL:Container 被kill后所处的状态
3.2.3.3 LocalizedResource
- DOWNLOADING:资源处于下载状态;
- LOCALIZED:资源下载完成;
- FAILED:资源下载失败;
3.2.4 节点健康检测机制
节点健康检测机制可时刻掌握NM健康状况并及时汇报给RM,RM根据NM是否健康决定是否为其调度新任务。
- 自定义Shell
- NodeHealthScriptRunner服务周期性执行节点健康状况检测脚本;
- 若输出以“ERROR”开头则不健康;
- 检测磁盘损坏数目
- 判断磁盘损坏标准:若一个目录具有读、写和执行权限,则目录正常;
- LocaIDirsHandlerService服务周期性检测NM本地磁盘好坏,坏盘数超过阈值则不健康;
四、重要机制
介绍YARN在调度公平性保障的重要调度策略:Fair Share和DRF调度策略;介绍YARN系统内部的事件机制和高可用机制;
4.1. 公平性保障
为什么需要Fair Share调度策略?
Fair Share调度策略原理
为什么需要DRF调度策略?
DRF调度策略原理
4.1.1 调度策略 - Fair Share调度策略背景
为什么需要Fair Share调度策略?
- 实现队列间资源共享,提高资源利用率:
- 缓解繁忙队列压力; 什么是Fair Share调度策略?
- 队列空闲时按照一定策略将资源分配给其他活跃队列; Fair Share类型
- Steady Fair Share
- Instantaneous Fair Share
4.1.2 调度策略 - Instantaneous Fair Share定义
Instantaneous Fair Share计算
- 定义
- 所有队列Fair Share之和< = TotalResource;
- S.minShare <= Fair Share <= S.maxShare;
- 目标
- 找到一个R使其满足:
- R * (AII 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
4.1.3 Instantaneous Fair Share计算逻辑
4.1.4 DRF(Dominant Resource Fair)调度策略
- 为什么需要DRF调度策略?
- 在保证公平性的前提下进行资源降维;
- 什么是DRF调度策略?
- DRF是最大最小公平算法在多维资源上的具体实现;
- 旨在使不同用户的"主分享量”最大化的保持公平;
- 最大最小公平算法:最大化最小资源需求的满足度
- 资源按照需求递增顺序分配;
- 获取的资源不超过自身需求;
- 未满足用户等价分享剩余资源;
4.1.5 调度策略- DRF调度策略描述
DRF调度策略示例
- 场景:系统有<9CPU, 18G>,A每个任务需要<1CPU, 4G>, B每个任务需要<3CPU, 1G>, 对于A因为: 1/9 < 4/18,所以A任务的主资源是内存,B任务的主资源是CPU;
- 数学模型: 一定约束条件下的最优化问题,下面 x代表A任务的个数,y代表B任务的个数
- 最大化资源分配max(x,y)
- 约束条件:
- (x+3y) <= 9 (CPU约束);
- (4x+y) <= 18 (内存约束) ;
- 4x/18 == 3y/9 (主资源公平约束) ;
- 最终计算得到: x=3, y=2
4.1.6 DRF调度策略计算逻辑
4.2. 高性能保障
高性能对调度的重要性
状态机管理
事件处理模型
4.2.1 事件机制 - 状态机管理
- 状态机由一组状态(初始状态、中间状态和最终状态)组成,状态机从初始状态开始运行,接收一组特定事件,经过-系列中间状态后, 到达最终状态并退出;
- 每种状态转换由一个四元组表示:转换前状态、转换后状态、事件和回调函数;
- YARN定义了三种状态转换方式如下所示:
4.2.2 事件机制 - 事件处理模型
- 所有处理请求都会作为事件进入系统;
- AsyncDispatcher 负责传递事件给相应事件调度器;
- 事件调度器将事件转发给另一个事件调度器或带有有限状态机的事件处理器;
- 处理结果以事件形式输出,新事件会再次被转发,直至处理完成; YARN采用了基于事件驱动的并发模型,具有很强的并发性可提高系统性能
4.3. 高可用保障
高可用对调度的重要性
RM高可用
NM高可用
4.3.1 容错机制--高可用性
五、公司实践
介绍字节跳动在调度功能、调度性能和集群利用率提升方面的工作,包括: Gang 调度器、反调度器、单集群规模突破50K;
5.1 Gang 调度器
5.1.1 为什么需要开发Gang调度器?
流式作业和训练作业的调度需求与批处理有很大的不同:批处理强调高吞吐,而流式/训练类型作业更强调低延迟和全局视角;
- 调度缺乏全局视角
- 单App调度过慢
- App间存在资源互锁
5.1.2 Gang调度器有什么典型特征?
5.1.3 Gang调度器调度流程
5.1.4 使用场景
5.2 反调度器
5.2.1 为什么需要开发反调度器?
5.2.2 反调度器调度流程
5.2.3 反调度器与Gang调度器
5.2.4 使用场景
5.3 单集群规模50K
5.3.1 为什么要提升单集群规模?
5.3.2 提升单集群规模有哪些瓶颈点?
- RPC层:接收请求、处理请求、返回结果
- RPC处理时间5ms, handler 默认80线程;
- 消费吞吐瓶颈约16K/s,RPC Server Queue易打满;
- Dispatcher层:将事件传给 对 应的件调度器
- 生产速率过大,AsyncDispatcher Queue容易Pending
- 消费速率过低,NODE UPDATE事件处理过慢,2K/s 瓶颈
- Scheduler层:真 正调度
- FSLeafQueue单Container分配延迟高,存在空转
- 心跳反压机制
- 心跳动态调整:将NM节点心跳周期改为根据RM的压力动态调整
- 多线程调度
- 对节点按hashcode放到对应的Scheduler Queue
- 其他优化
- 事件精简:对内部事件梳理调整,精准修改了-些事件处理逻辑
- 空转优化:调度时过滤不需要资源的App,减少空转
- 内存单位优化:修改内存单位(int -> long)突破单集群21亿MB限制
- 切主优化:通过对切主过程深度优化,将切主时间控制在秒级
晚安玛卡巴卡
快乐暑假