走进Yarn资源管理和调度|青训营笔记

林路
126 阅读8分钟

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

一.YARN概述

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

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

image.png

2.调度系统预达的目标

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

3.调度系统范型（前两种使用较多）

image.png

  • 集中式：融合资源管理调度机制和任务管理（优：Master节点拥有全局视角，可以进行资源分配 缺：Master会成为单点瓶颈）
  • 两层式：资源管理调度和任务控制解耦（优：调度压力缓解）
  • 共享状态式：多个调度器基于乐观并发共享全局资源视图（优：效率高 缺：多个调度器间会产生矛盾）
  • 分布式：多个调度器基于先验知识进行最快调度决策（优：效率高 缺：各个调度器不能进行全局调度）
  • 混合式：多种类型调度器共存，共同分配

4.YARN设计思想：离线生态

image.png

5.面临挑战

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

6.系统架构

image.png 用户写代码基于不同引擎，通过YARN Client提交到集群 Resource Manager（有多个，但只有一个是主，其他是副本，主节点故障时会通过zk进行选主）

  • 资源管理和调度
  • 任务生命周期管理
  • 对外进行交互 Node Manager（每个物理节点上都有一个）
  • 提供集群资源
  • 管理Container运行 zk：
  • 选主
  • 存储重要元数据信息 HDFS/Kafaka
  • 从HDFS拉取jar包数据等，从Kafaka消费数据等

7.任务运行生命周期核心流程

image.png

二.YARN核心模块

1.Resource Manager整体架构

image.png

最上层：管理所有任务的ApplicationMaster，ApplicationMasterService会跟AM进行心跳的保持，负责资源请求的处理
MALivelinessMonitor负责监控每个AM是否活着，如果一段时间没心跳就异常
Launcher：进行AM的launch
User Service：用户或管理者的服务
Resource Scheduler：当请求来临，对资源进行调度
下面：对所有节点进行维护 每个节点都有一个NodeManager，每个NM都要与RM心跳维护
Service：响应刚刚心跳维护
Monitor：定期发现哪些节点没有心跳，及时将该节点清除，以防再调度资源
Manager：维护所有节点的状态信息

2.RM主要职责

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

image.png

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

3.RM状态机管理：RMApp状态机

image.png

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

4.RMAppAttempt：RMApp失败时重开，每个实例都有一个

image.png

  • SCHEDULED：通过合法性检查后所处的状态，开始为该任务分配资源
  • ALLOCATED_SAVING：收到分配的Container后，在持久化完成前所处的状态
  • LAUNCHED：RM的ApplicationMasterLauncher与NM通信以启动AM时所处的状态

5.RMContainer

image.png

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

6.RMNode

image.png

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

7.RM调度器分析：资源/任务组织

  • 任务按队列组织：不同任务提交不同任务，有不同配额，根据配额进行资源分配
  • 节点按Label组织：一个节点存在于不同label，label间有物理隔离。一个label下的队列只共享该label下的物理机。

8.RM调度流程

image.png

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

9.典型调度器

image.png 基于跳过次数的延迟：假如一个节点来了，但它不满足数据本地性，就先跳过，等下一个节点来了再尝试。当次数用完后，才把它调度到最新来的节点上。

10.NM整体架构

image.png

绿：跟RM进行心跳的模块
黄：管理container运行的内容
红：定期检测节点是否健康
红下：维护三个重要对象的状态机

11.NM主要职责：

image.png

NM是节点代理，从AM接受命令（启动Container）并执行，通过心跳方式向RM汇报节点状态并领取命令（清理Container）。
与RM交互：

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

12.NM状态机管理：Application

image.png

  • INITING：Application初始化状态，创建工作目录和日志目录
  • FINISHING_CONTAINERS_WAIT：调等待回收Container所占用的资源所处的状态
  • APPLICATION_RESOURCE_CLEANINGUP：Application所有Container占用的资源被回收后所处的状态

13.Container

image.png

  • LOCALIZING：正在从HDFS下载依赖的资源
  • EXITED-WITH-SUCCESS：Container运行脚本正常退出执行
  • CONTAINER_CLEANUP_AFTER_KILL：Container被kill后所处的状态

14.LocalizedResource：从HDFS拉取jar包

image.png

  • DOWNLOADING：资源处于下载状态
  • LOCALIZED：资源下载完成
  • FAILED：资源下载失败

15.NM节点健康检测机制

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

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

三.重要机制

1.Fair Share调度策略背景

  • 实现队列间资源共享，提高资源利用率
  • 缓解繁忙队列压力
  • 队列空闲时按照一定策略资源分配给其他活跃队列
  • 类型：Steady Fair Share（min）/Instantaneous Fair Share

2.Instantaneous Fair Share

3.DRF调度策略

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

4.DRF调度策略计算逻辑

5.事件机制：状态机管理

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

image.png

6.事件处理模型

image.png

  • 所有处理请求都会作为事件进入系统
  • AsyncDispatcher负责传递事件给相应事件调度器
  • 事件调度器将事件转发给另一个事件调度器或带有有限状态机的事件处理器
  • 处理结果以事件形式输出，新事件会再次被转发，直至处理完成
  • YARN采用了基于事件驱动的并发模型，具有很强的并发性可提高系统性能

7.容错机制--高可用性

RM高可用

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