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

用户3618319768332
188 阅读6分钟

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

1. YARN概述

image.png

1.2 调度系统预达到的目标

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

image.png

1.3 调度系统范型

image.png

1.4.1 YARN整体架构---系统架构

Resource Manager

  • 资源管理和调度
  • 任务生命周期管理
  • 对外进行交互

Node Manager

  • 提供集群资源
  • 管理Container运行

image.png

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

image.png

2. YARN核心模块

2.1 Resource Manager

整体架构image.png主要职责

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

  • 与客户端交互

  • 启动和管理所有AM

  • 管理所有NM

  • 资源管理与调度

    • 组织资源（资源池
    • 组织任务（队列
    • 接收资源请求
    • 分配资源

image.png

2.1.1 Resource Manager状态机管理---RMApp状态机

NEW SAVING:  收到任务后，创建RMAppImpl对象并将基本信息持久化

ACCEPTED:  调度器接受该任务后所处的状态任务等待被分配资源

RUNNING:  任务成功获取到资源并在节点运行

image.png

2.1.2 Resource Manager状态机管理---RMAppAttempt状态机

SCHEDULED:  通过合法性检查后所处的状态，开始为该任务分配资源

ALLOCATED SAVING:  收到分配的Container后，在持久化完成前所处的状态；

ALLOCATED:  信息持久化完成后所处的状态：

LAUNCHED:  RM的ApplicationMasterLauncher与NM通信以启动 AM时所处的状态：image.png

2.1.3 Resource Manager状态机管理---RMContainer状态机

RESERVED:  开启资源预留时，当前节点不能满足资源请求时所处的状态

ALLOCATED:  调度器分配一个Container给AM;

ACQUIRED:  Container被AM领走后的状态；

EXPIRED:  AM获取到Container后，若在一定时间内未启动Container,RM会强制回收该Container;

image.png

2.1.4 Resource Manager状态机管理---RMNode状态机

DECOMMISSIONED:  节点下线后的状态；

UNHEALTHY：节点处于不健康状态，健康检测脚本异常或磁盘故障

LOST:  节点超过一定时间（默认10分钟）未与RM发生心跳后所处的状态；

image.png

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

任务按队列组织

节点按Label组织（一批有共同特点的节点的组合）image.png

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

AM与RM心跳：记录资源请求

触发时机：节点心跳

找Label::获取所有队列

找队列：最“饥饿”队列优先

找任务：优先级高的任务优先

找资源请求：优先级高的请求优先

image.png

2.2.3 2.2.2 Resource Manager调度器分析---典型调度器

image.png

2.3 Node Manager整体架构

image.png

主要职责

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

  • 与RM交互

    • 心跳汇报节点状态
    • 领取RM下达的命令

  • 与AM交互

    • 启动容器
    • 停止容器
    • 获取容器状态

image.png

2.3.1 Node Manager状态机管理---Application

INITING:  Application初始化状态，创建工作目录和日志目录

FINISHING CONTAINERS WAIT:  调等待回收Container所占用的资源所处的状态；

APPLICATION RESOURCE CLEANINGUP：  Application所有Container占用的资源被回收后所处的状态：image.png

2.3.2 Node Manager状态机管理---Container

LOCALIZING:  正在从HDFS下载依赖的资源

EXITED WITH SUCCESS：  Container运行脚本正常退出执行

CONTAINER CLEANUP AFTER KILL：  Container被kill后所处的状态image.png

2.3.3 Node Manager状态机管理---LocalizedResource

DOWNLOADING:  资源处于下载状态；

LOCALIZED:  资源下载完成；

FAILED:  资源下载失败；image.png

2.4 Node Manager节点健康检查机制

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

自定义Shell

  • NodeHealthScriptRunner服务周期性执行节点健康状况检测脚本；
  • 若输出以“ERROR”开头则不健康；

检测磁盘损坏数目

  • 判断磁盘损坏标准：若一个目录具有读、写和执行权限，则目录正常；
  • LocalDirsHandlerService服务周期性检测NM本地磁盘好坏，坏盘数超过阈值则不健康；

3. 重要机制

3.1 调度策略-Fair Share 调度策略背景

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

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

什么是Fair Share调度策略？

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

Fair Share类型

  • Steady Fair Share
  • Instantaneous Fair Share

image.png

3.2 调度策略-DRF 调度策略

为什么需要DRF调度策略？

  • 在保证公平性的前提下进行资源降维

什么是DRF调度策略？

  • DRF是最大最小公平算法在多维资源上的具体实现
  • 旨在使不同用户的“主分享量”最大化的保持公平：

最大最小公平算法：最大化最小资源需求的满足度

  • 资源按照需求递增顺序分配：
  • 获取的资源不超过自身需求
  • 未满足用户等价分享乘剩余资源：

image.png

3.3 事件机制---状态机管理

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

image.png

事件处理模型

image.png

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

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

3.4 容错机制---高可用性

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数据库加载数据；
avatar
文章
阅读
粉丝