这是我参与「第四届青训营 」笔记创作活动的第10天
yarn概述
1.调度系统演进
调度系统解决的问题
- 用有限资源解决有限资源无法满足的需求时就需要调度;
- 调度系统主要解决资源请求和可用资源间的映射(Mapping)问题;
调度系统预达到的目标
- 严格的多租户间公平、容量保障
- 调度过程的高吞吐与低延迟
- 高可靠性与高可用性保障
- 高可扩展的调度策略
- 高集群整体物理利用率
- 满足上层任务的个性化调度需求
- 任务持续、高效、稳定运行
调度系统范型
- 集中式
- 融合资源管理调度和任务控制
- 两层式
- 资源管理调度和任务控制解耦
- 共享状态式
- 多个调度器基于乐观并发共享全局资源视图
- 分布式
- 多个调度器基于先验知识进行最快调度决策
- 混合式
- 多种类型调度器共存，共同分配
2.YARN设计思想
YARN演化
Hadoop1.0：
- 可扩展性差
- 可靠性差
- 资源利用率低
- 无法支持多种计算框架
Hadoop2.0
- 资源管理和任务控制解耦
- 增加了YARN（Yet Another Resource Negotiator）支持多种计算框架的统一资源管理平台
YARN离线生态
YARN面临挑战
- 公平性:各租户能够公平的拿到资源运行任务
- 高性能:高调度吞吐、低调度延迟，保障资源快速流转
- 高可用:集群要具备很强的容错能力
- 大规模:单集群规模提升(原生YARN 5K)
- 高集群资源利用率
- 高任务运行质量保障
YARN系统架构
- Resource Manager
- 资源管理和调度√任务生命周期管理
- 对外进行交互
- Node Manager
- 提供集群资源
- 管理Container运行
任务运行生命周期核心流程
YARN核心模块
1.Resource Manager
整体架构
主要职责
RM负责集群所有资源的统一管理和分配，接收各节点汇报信息并按照定策略分配给各个任务。
- 与客户端交互
- 启动和管理所有AM
- 管理所有NM
- 资源管理与调度
- 组织资源(资源池)
- 组织任务(队列)
- 接收资源请求
- 分配资源
Resource Manager 状态机管理
- NEW_SAVING:收到任务后，创建RMApplmpl对象并将基本信息持久化;
- ACCEPTED:调度器接受该任务后所处的状态，任务等待被分配资源;
- RUNNING:任务成功获取到资源并在节点运行;
- SCHEDULED:通过合法性检查后所处的状态，开始为该任务分配资源;
- ALLOCATED_SAVING:收到分配的Container后，在持久化完成前所处的状态;
- ALLOCATED:信息持久化完成后所处的状态;
- LAUNCHED: RM的ApplicationMasterLauncher 与 NM通信以启动AM时所处的状态;
- RESERVED:开启资源预留时，当前节点不能满足资源请求时所处的状态;
- ALLOCATED:调度器分配一个 Container给AM;
- ACQUIRED: Container 被AM领走后的状态;
- EXPIRED:AM获取到Container后，若在一定时间内未启动Container，RM会强制回收该Container;
- DECOMMISSIONED:节点下线后的状态;
- UNHEALTHY:节点处于不健康状态，健康检测脚本异常或磁盘故障;
- LOST:节点超过一定时间(默认10分钟)未与RM发生心跳后所处的状态;
RM调度器分析
任务/资源组织
RM是按队列组织，节点按label组织
调度流程
- AM与RM心跳:记录资源请求
- 触发时机:节点心跳
- 找Label:获取所有队列
- 找队列:最“饥饿”队列优先
- 找任务:优先级高的任务优先
- 找资源请求:优先级高的请求优先
典型调度器
2.Node Manager
整体架构
主要职责
NM是节点代理，从AM接受命令（启停Container)并执行，通过心跳方式向RM汇报节点状态并领取命令（清理Container) 。
- 与RM交互
- 心跳汇报节点状态
- 领取RM下达的命令
- 与AM交互
- 启动容器
- 停止容器
- 获取容器状态
Node Manager状态机管理
Application
- INITING: Application初始化状态，创建工作目录和日志目录;
- FINISHING CONTAINERS_WAIT:调等待回收Container 所占用的资源所处的状态;
- APPLICATION_RESOURCE_CLEANINGUP:Application所有Container占用的资源被回收后所处的状态;
Container
- LOCALIZING:正在从 HDFS下载依赖的资源;
- EXITED WITH_suCCESS: Container运行脚本正常退出执行;
- CONTAINER_ CLEANUP AFTER_KILL:Container被kill后所处的状态
LocalizedResource
- DOWNLOADING:资源处于下载状态;
- LOCALIZED:资源下载完成;
- FAILED:资源下载失败;
Node Manager 节点健康检测机制
节点健康检测机制可时刻掌握NM健康状况并及时汇报给RM，RM根据NM是否健康决定是否为其调度新任务。
- 自定义Shell
- NodeHealthScriptRunner服务周期性执行节点健康状况检测脚本;
- 若输出以“ERROR”开头则不健康;
- 检测磁盘损坏数目
- 判断磁盘损坏标准:若一个目录具有读、写和执行权限，则目录正常;
- LocalDirsHandlerService服务周期性检测 NM本地磁盘好坏，坏盘数超过阈值则不健康;
YARN重要机制
YARN如何保证公平性
1.公平性保障
Fair Share 调度
为什么需要Fair Share调度策略?
- 实现队列间资源共享，提高资源利用率;
- 缓解繁忙队列压力;
什么是Fair Share调度策略?
队列空闲时按照一定策略将资源分配给其他活跃队列;
Fair Share类型
- Steady Fair Share
- Instantaneous Fair Share
DRF（Dominant Resource Fair）调度
为什么需要DRF调度策略?
- 在保证公平性的前提下进行资源降维;
什么是DRF调度策略?
- DRF是最大最小公平算法在多维资源上的具体实现;
- 旨在使不同用户的“主分享量”最大化的保持公平;
最大最小公平算法:最大化最小资源需求的满足度
- 资源按照需求递增顺序分配;
- 获取的资源不超过自身需求;
- 未满足用户等价分享剩余资源;
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 数据库加载数据;
