这是我参与「第四届青训营 」笔记创作活动的的第16天
- Yarn概述
- 初识调度系统
- 解决的问题
- 用有限资源解决有限资源无法满足的需求时就需要调度
- 调度系统主要解决资源请求和可用资源间的映射(Mapping)问题
- 目标
- 严格的多租户间公平、容量保障
- 调度过程的高吞吐与低延迟
- 高可靠性与高可用性
- 高可扩展的调度策略
- 高集群整体物理利用率
- 满足上层任务的个性化调度需求
- 任务持续、高效、稳定运行
- 系统演进
- 集中式
- 融合资源管理调度和任务控制
- 两层式
- 资源管理调度和任务控制解耦
- 共享状态式
- 多个调度器基于乐观并发共享全局资源视图
- 分布式
- 多个调度器基于先验知识进行最快调度决策
- 混合式
- 多种类型调度器共存，共同分配
- 集中式
- 解决的问题
- Yarn设计思想
- 演化背景
- Hadoop 1.0时代
- 组件
- MapReduce
- HDFS
- 特点
- 可扩展性差
- 可靠性差
- 资源利用率低
- 无法支持多种计算框架
- 组件
- Hadoop 2.0时代
- 组件
- MR
- Storm
- Yarn
- HDFS
- 特点
- 资源管理和任务控制解耦
- Yarn(Yet Another Resource Negotiator)
- 支持多种计算框架的统一资源管理平台
- 组件
- Hadoop 1.0时代
- 离线生态
- User Logic
- Workflow Hosting
- Compute Engine
- Resource Mgmt & Scheduling
- Yarn
- Bare Metal
- 挑战
- 公平性
- 各租户能够公平的拿到资源运行任务
- 高性能
- 高调度吞吐、低调度延迟，保障资源快速流转
- 高可用
- 集群要具备很强的容错能力
- 大规模
- 单集群规模提升
- 高集群资源利用率
- 高任务运行质量保障
- 公平性
- 整体架构
- 系统架构
- Resource Manager
- 资源管理和调度
- 任务生命周期管理
- 对外进行交互
- Node Manager
- 提供集群资源
- 管理Container运行
- Resource Manager
- 任务运行生命周期核心流程
- 系统架构
- 演化背景
- 初识调度系统
- 核心模块
- Resource Manager
- 整体架构
- ApplicationMasterService
- AMLivelinessMonitor
- ApplicationMasterLauncher
- Resource Scheduler
- State Machine
- 主要职责
- 负责集群所有资源的统一管理和分配，接收各节点汇报信息并按照一定策略分配给各个任务。
- 与客户端交互
- 启动和管理所有AM
- 管理所有NM
- 资源管理与调度
- 组织资源(资源池)
- 组织任务(队列)
- 接收资源请求
- 分配资源
- 负责集群所有资源的统一管理和分配，接收各节点汇报信息并按照一定策略分配给各个任务。
- 状态机管理
- RMApp
- NEW_SAVING
- 收到任务后，创建RMAppImpl对象并将基本信息持久化
- ACCEPTED
- 调度器接受该任务后所处的状态，任务等待被分配资源
- RUNNING
- 任务成功获取到资源并在节点运行
- NEW_SAVING
- RMAppAttempt
- SCHEDULED
- 通过合法性检查后所处的状态，开始为该任务分配资源
- ALLOCATED_SAVING
- 收到分配的Container后，在持久化完成前所处的状态
- ALLOCATED
- 信息持久化完成后所处的状态
- LAUNCHED
- RM的ApplicationMasterLauncher与NM通信以启动AM时所处的状态
- SCHEDULED
- RMContainer
- RESERVED
- 开启资源预留时，当前节点不能满足资源请求时所处的状态
- ALLOCATED
- 调度器分配一个Container给AM
- ACQUIRED
- Container被AM领走后的状态
- EXPIRED
- AM获取到Container后，若在一定时间内未启动Container，RM会强制回收该Container
- RESERVED
- RMNode
- DECOMMISSIONED
- 节点下线后的状态
- UNHEALTHY
- 节点处于不健康状态，健康检测脚本异常或磁盘故障
- LOST
- 节点超过一定时间(默认10min)未与RM发生心跳后所处的状态
- DECOMMISSIONED
- RMApp
- 调度器分析
- 任务/资源组织
- 任务按队列组织
- 节点按leader组织
- 调度流程
- AM与RM心跳
- 记录资源请求
- 触发时机
- 节点心跳
- 找label
- 获取所有队列
- 找队列
- 最"饥饿"队列优先
- 找任务
- 优先级高的任务优先
- 找资源请求
- 优先级高的请求优先
- AM与RM心跳
- 典型调度器
- 提供一种多租户资源分配方法，提高集群资源利用率减小集群管理成本
- Fair Scheduler
- 基于最大最小公平算法分配资源
- Container请求资源粒度
- 最小资源量的整数倍
- Capacity Scheduler
- 资源按比例分配给各队列，并添加各种限制
-
- Container请求资源粒度
- 专门的内存规整化参数控制，粒度更小
- Container请求资源粒度
- 任务/资源组织
- 整体架构
- Node Manager
- 整体架构
- NodeStatusUpdater
- Container Manager
- Node Health Checker Service
- State Machine
- 主要职责
- NM是节点代理，从AM接受命令(启停container)并执行，通过心跳方式从RM汇报节点状态并领取命令(清理Container)
- 与RM交互
- 心跳汇报节点状态
- 领取RM下达的命令
- 与AM交互
- 启动容器
- 停止容器
- 获取容器状态
- 与RM交互
- NM是节点代理，从AM接受命令(启停container)并执行，通过心跳方式从RM汇报节点状态并领取命令(清理Container)
- 状态机管理
- Application
- INITING
- Application初始化状态，创建工作目录和日志目录
- FINISHING_CONTAINERS_WAIT
- 等待回收container所占用的资源所处的状态
- APPLICATION_RESCOURCE_CLEANINGUP
- Application所有container占用的资源被回收后所处的状态
- INITING
- container
- LOCALIZING
- 正在从HDFS下载依赖的资源
- EXITED_WITH_SUCCESS
- container运行脚本正常退出运行
- CONTAINER_CLEANUP_AFTER_KILL
- container被kill后所处的状态
- LOCALIZING
- LocalizedResource
- DOWNLOADING
- 资源处于下载状态
- LOCALIZED
- 资源下载失败
- FAILED
- 资源下载失败
- DOWNLOADING
- Application
- 节点健康检查机制
- 时刻掌握NM健康状况被及时汇报给RM，RM根据NM是否健康决定是否为其调度新任务
- 自定义shell
- NodeHealthScriptRunner服务周期性执行节点健康状态检测脚本
- 若输出以ERROR开头，则不健康
- 检测磁盘损坏数目
- 判断磁盘损坏标准：若一个目录具有读、写和执行权限，则目录正常
- LocalDirsHandlerService服务周期性检测NM本地磁盘好坏，坏盘数超过阈值则不健康
- 自定义shell
- 时刻掌握NM健康状况被及时汇报给RM，RM根据NM是否健康决定是否为其调度新任务
- 整体架构
- Resource Manager
- 重要机制
- 公平性保障
- 调度策略
- Fair Share
- 调度策略背景
- why
- 实现队列间资源共享，提高资源利用率
- 缓解繁忙队列压力
- what
- 队列空闲时按照一定策略将资源分配给其他活跃队列
- 类型
- Steady Fair Share
- Instantaneous Fair Share
- 计算逻辑
- 计算Total Resource
- 初始化R上限RMax
- 通过二分法寻找R[0,RMax]
- 计算Fair Share
- 计算逻辑
- why
- 调度策略背景
- DRF(Dominant Resource Fair)
- why
- 在保证公平性的前提下进行资源降维
- what
- DRF是最大最小公平算法在多维资源上的具体实现
- 旨在使不同用户的"主分享量"最大化的保持公平
- 最大最小公平算法
- 最大化最小资源需求的满足度
- 资源按照需求递增顺序分配
- 获取的资源不超过自身需求
- 未满足用户等价分享剩余资源
- 最大化最小资源需求的满足度
- why
- Fair Share
- 调度策略
- 高性能保障
- 事件机制
- 状态机管理
- 状态机由一组状态(初始状态、中间状态和最终状态)组成，状态机从初始状态开始运行，接收一组特定事件，经过一系列中间状态后，到达最终状态并退出
- 每种状态转换由一个四元组表示:转换前状态、转换后状态、事件和回调函数
- Yarn定义了三种状态转换方式
- 初始状态:最终状态:事件 = 1:1:1
- 初始状态:最终状态:事件 = 1:N:1
- 初始状态:最终状态:事件 = 1:1:N
- 事件处理模型
- Yarn采用了基于事件驱动的并发模型，具有很强的并发性，可提高系统性能
- 所有处理请求都会作为事件进入系统
- AsyncDispatcher负责传递事件给相应事件调度器
- 事件调度器将事件转发给另一个事件调度器或带有有限状态机的事件处理器
- 处理结果以事件形式输出，新事件会再次被转发，直至处理完成
- Yarn采用了基于事件驱动的并发模型，具有很强的并发性，可提高系统性能
- 状态机管理
- 事件机制
- 高可用保障
- 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数据库
- 重启时从yam-nm-recovery下的leveldb数据库加载数据
- RM高可用
- 公平性保障
- 公司实践
- gang调度器
- why
- 流式作业和训练作业的调度需求与批处理有很大的不同
- 批处理强调高吞吐
- 流式/训练类作业更强调低延迟和全局视角
- 问题
- 调度缺乏全局视角
- 单app调度过慢
- app间存在资源互锁
- 流式作业和训练作业的调度需求与批处理有很大的不同
- 特点
- 全局视角
- 作业可自定义配置强弱约束
- 强约束
- 必须要满足的条件
- 弱约束
- 尽量满足的约束
- 低调度延迟
- rm维护所有节点状态信息
- 资源请求同步分配，毫秒级返回
- gang性资源交付
- 提供all-or-nothing语义
- 可满足的请求全部分配，否则返回失败
- 调度流程
- 强约束阶段
- 过滤掉不符合条件的节点
- 弱约束阶段
- 选择合适的节点分配资源
- Quota平均
- 分配后节点已使用资源尽可能平均
- 跳过高load节点
- 优先往低load节点调度
- Quota平均
- 选择合适的节点分配资源
- 兜底分配
- 强约束阶段
- 全局视角
- why
- 反调度器
- why
- 调度器的调度决策受“时空”限制
- “时”
- 触发调度时刻
- “空”
- 触发调度时集群状态
- “时”
- 任务运行和集群状态高动态性
- 任务资源使用随流量变化而不断波动
- 调度过程持续进行，集群状态持续变化
- 需要持续保证最初调度决策的正确性
- 调度器的调度决策受“时空”限制
- 反调度流程
- 根据AM请求中的强约束，构造强约束集
- 遍历强约束集选择不再符合强约束条件的节点
- 遍历异常节点下的container，选择需要进行反调度的container
- 将反调度container列表随心跳返回给AM
- why
- 反调度器与gang调度器的关系
- 不同点
- 发挥作用时机不同
- 处理机制完全相反
- 相同点
- 反调度器是gang调度器的补充
- 共同保障资源持续合理分配
- 不同点
- 单集群规模提升
- 原因
- 更好的资源池化和资源共享
- 资源池更大，利于资源分时复用
- 资源高效共享，提高集群资源利用率
- 降低运维成本
- yarn原生单集群仅支持5k节点
- 每多一个集群，运维负担就会加重
- 更好的资源池化和资源共享
- 瓶颈
- RPC瓶颈
- Dispatcher瓶颈
- Scheduler瓶颈
- 优化
- 心跳反压机制
- 将NM节点心跳周期改为根据RM的压力动态调整
- 多线程调度
- 对节点按hashcode放到对应的scheduler queue
- 其他优化
- 事件精简
- 对内部事件梳理调整，精准修改了一些事件处理逻辑
- 空转优化
- 调度时过滤不需要资源的app，减少空转
- 内存单位优化
- 修改内存单位(int->long)突破单集群21亿MB限制
- 切主优化
- 通过对切主过程深度优化，将切主时间控制在秒级
- 事件精简
- 心跳反压机制
- 原因
- gang调度器
