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

serendipity__
161 阅读9分钟

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

走进 YARN 资源管理和调度

一、初识调度系统

1.1 场景描述

首先考虑如下虚拟场景，如何进行调度在保障就餐公平性的前提下让尽可能多的学生都能够在该餐厅就餐、尽可能多的座位被有效使用？

  • 学校为改善学生生活新建了一所美食餐厅，餐厅座位有限且只能堂食；

  • 各个学院需要缴纳一定管理费用后其学生才能在该餐厅用餐，缴纳费用与分配的座位数成正比；

  • 因餐厅物美价廉、环境干净，来该餐厅就餐的人络绎不绝

1.2 简易分配模型

一种简易的分配模型参考如下： image.png

  • 学院缴纳费用后获得固定座位数；

  • 学生按照学院组织，学院内的用餐小组按照预定时间排队，每个小组有一个负责人；

    • 各个学院：获得座位数
    • 学院学生：按照学院组织
    • 餐厅经理：分配餐厅座位
    • 餐厅座位：有序排列放置

  • 用餐结束后，用餐小组负责人向餐厅助手说明；

  • 保障公平性

    • 学院间：按照分配座位满足率排序；
    • 学院内：先来先服务、后来后服务；

  • 保障高效性

    • 餐厅经理有很多助手以辅助其派发，助理可以统计就餐信息、学院排序、引导等；
    • 餐厅经理做决策，助手异步同步信息；

  • 保障高可用

    • 两个备用经理，随时可以工作；

  • 如何满足 “尽可能多”？

    • 座位超售：所有学院分配座位大于总座位数
    • 学院超用：有座位时学院可以超分配座位
    • 座位超发：“允许一个座位坐两个人”
    • 鼓励快餐：鼓励大家快速就餐离开

  • 就餐学生有个性化需求

    • 同用餐小组必须坐一个桌子
    • 同用餐小组必须坐不同桌子
    • 用餐小组必须要坐靠窗位置
    • 有重要活动同学需靠前就餐

1.3 调度系统演进

1.3.1 调度系统演进 —— 调度系统的发展背景

  • IT到DT时代的变革，注重数据价值；
  • 数据计算方式的变革，注重计算效率；
  • 企业对外服务需要数以万计的硬件资源
  • 灵活调度、提高利用率是降低增效的关键问题

image.png

1.3.2 调度系统演进 —— 解决的问题

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

image.png

1.3.3 调度系统演进 —— 预达的目标

  • 严格的多租户间公平、容量保障

  • 调度过程的高吞吐与低延迟

  • 高可靠性与高可用性保障

  • 高可扩展的调度策略

  • 高集群整体物理利用率

  • 满足上层任务的个性化调度需求

  • 任务持续、高效、稳定运行

image.png

1.3.4 调度系统演进 —— 调度系统的范型

image.png

1.4 YARN 设计思想

1.4.1 演化背景

Hadoop 1.0 时代：由分布式存储系统 HDFS 和分布式计算框架 MapReduce(MR v1) 组成，MR v1 存在很多局限：

  • 可扩展性差：JobTracker 兼备资源管理和任务控制，是系统最大的瓶颈；

  • 可靠性差：采用 master/slave 结构，master 存在单点故障问题；

  • 资源利用率低：基于槽位的资源分配模型，各槽位间资源使用差异大；

  • 无法支持多种计算框架：只支持 MR 任务，无法支持其他计算框架；

Hadoop 2.0 时代：解决了 Hadoop 1.0 时代中 HDFS 和 MR 中存在的问题：

  • YARN(MR v2) 在 MR v1 的基础上发展而来，将资源管理和任务控制解耦，分别由 Resource Manager 和 ApplicationMaster 负责，是一个两层调度系统；

  • Hadoop YARN(Yet Another Resource Negotiator) 支持多种计算框架的统一资源管理平台；

1.4.2 离线调度生态介绍

image.png

  • 用户逻辑层：数据分析任务、模型训练任务等

  • 作业托管层：管理各种类型上层任务

  • 分布式计算引擎层：各种针对不同使用场景的计算引擎，例如：MR、Spark、Flink 等

  • 集群资源管理层：YARN

  • 裸金属层：众多物理节点组成

1.4.3 YARN面临的挑战

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

1.5 YARN 整体架构

1.5.1 系统架构

image.png

  • Resource Manager

  • 资源管理和调度

  • 任务生命周期管理

  • 对外进行交互

  • Node Manager

  • 提供集群资源

  • 管理Container

1.5.2 任务运行核心流程

image.png

二、YARN 核心模块

2.1 Resource Manager

2.1.1 整体架构

image.png

2.1.2 主要职责

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

  • 与客户端交互，处理来自客户端的请求

  • 启动和管理 AM，运行失败时自动重试

  • 管理所有 NM，接收 NM 的汇报信息并下达管理指令

  • 资源管理与调度

    • 将资源按照一定方式组织起来，例如：资源池
    • 将任务按照一定方式组织起来，例如：队列
    • 接收来自各个 AM 的资源请求
    • 按照一定分配策略将资源分配给 AM

image.png

2.1.3 状态机管理

RMApp 状态机

image.png

  • NEW_SAVING: 收到提交的应用程序后，创建 RMAppImpl 对象并将基本信息持久化；

  • ACCEPTED：调度器接受该应用程序后所处的状态，任务等待被分配资源；

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

RMAppAttempt 状态机

image.png

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

  • ALLOCATED_SAVING：收到分配的 Container 后，在持久化完成前所处的状态；

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

  • LAUNCHED：RM 的 ApplicationMasterLauncher 与 NM 通信以启动 AM 时所处的状态；

RMContainer 状态机

image.png

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

  • ALLOCATED：调度器分配一个 Container 给 AM；

  • ACQUIRED：AM 获取到分配的 Container 后所处的状态；

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

RMNode 状态机

image.png

  • DECOMMSIONED: 节点下线后的状态；

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

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

三、重要机制

image.png

什么是 Fair Share 调度策略？

队列配置 minShare 和 maxShare，当队列空闲时按照一定策略将资源分配给其他活跃队列；

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

保障公平的前提下实现队列间资源共享，提高资源利用率，缓解繁忙队列压力；

两种类型 Fair Share

  • Steady Fair Share: TotalResource * S.weight

  • Instantaneous Fair Share:

四、公司实践

4.1 Gang 调度器

4.1.1 为什么要开发 Gang 调度器？

原生 YARN 的架构设计目标专注在离线 Batch 类计算作业上面，对于高吞吐追求极致，但是对于 latency 和全局约束上没有很好支持。流式/模型训练任务的出现，需求与 Batch 类相差较大， 当前YARN 的架构已经无法很好的满足这部分任务。目前 Flink 作业和模型训练类的作业在 YARN 上面运行， 在调度层面都遇到三个问题:

  1. 调度缺乏全局视角

  2. 单个 Application 调度过慢

  3. Application 之间存在资源互锁情况

4.1.2 Gang 调度器有什么典型特点？

  • 全局视角: 增加 YARN 调度时的全局视角

    • 首先支持 Flink/GPU 训练的全局约束需求(负载均衡/ GPU 亲和性)
    • 为未来更丰富的全局约束留出扩展空间

  • 低延迟:

    • 对于低 latency 需求的申请，在集群可以满足资源的条件时，1 次申请直接返回资源(ms级别)。

  • Gang性交付:

    • 调度提供 all-or-nothing 的语义， 对于无法满足的申请直接返回失败， 对于可以满足的申请直接交付所有的申请资源，规避应用之间资源互锁的情况。

4.2 反调度器

为什么需要开发反调度器？

  • 调度器的调度决策受“时空”限制

在目前系统中，当有资源请求到来时，调度器只根据资源请求内容和当前时刻集群状态信息做出正确的调度决策，一旦资源请求与空闲资源匹配完成则本次调度过程结束，调度器不会维护当前资源请求下任务和集群的后续状态信息。因此，调度器的调度决策受“时空”限制，“时”表示触发调度时的时刻，“空”表示触发调度时集群的状态。

  • 任务运行和集群状态高动态性

在大规模集群中，任务运行过程和集群状态具有高动态性。对于任务来说，其资源使用量会伴随着请求流量的变化而不断波动。对于集群来说，随着任务调度过程的持续进行、集群节点的添加和故障、集群节点标签的改变等，集群状态每时每刻都在发生变化。

  • 需要持续保证最初调度决策的正确性

4.3 单集群 50K 突破

为什么需要提升单集群规模？

  • 更好的资源池化和资源共享

    • 资源池更大，有利于资源的分时复用和共享；
    • 资源高效共享可以提高集群整体资源利用率；

  • 降低运维成本

    • YARN 原生系统单集群仅支持 5K 节点；
    • 每多一个集群，运维负担就会加重；
avatar
文章
阅读
粉丝