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

用户5236754501065
56 阅读5分钟

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

Lecture15. 走进 Yarn 资源管理和调度

01. YARN概述

1.1 初识调度系统–场景导入

  • 学校为改善学生生活新建了一所美食餐厅，餐厅座位有限且只能堂食;
  • 各学院需缴纳一定管理费用后学生才能在该餐厅用餐，缴纳费用与分配的座位数成正比;
  • 因餐厅物美价廉、环境干净，来该餐厅就餐的人络绎不绝;

如何进行高效座位分配在保障就餐公平性的前提下让尽可能多的学生都能够及时就餐、尽可能多的座位被有效使用?

一种简易分配模型

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

优化的分配模型

  • 保障公平性

    • 学院间:低分配座位满足率优先
    • 学院内:先来先服务(先来后到)

  • 保障高效性

    • 配备餐厅助手
    • 用餐小组负责人保障高可用

  • 配置备用经理

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

    • 座位超售:分配座位大于总座位数
    • 学院超用:学院可以超分配座位，将这个学院座位分给另一个学院
    • 座位超发:”—个座位坐两个人”
    • 鼓励快餐:鼓励快速就餐离开，快速流动

  • 如何满足就餐学生个性化需求?

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

调度系统发展的背景

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

1.2 调度系统演进–调度系统解决的问题

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

调度系统预达的目标

  • 严格的多租户间公平、容量保障
  • 调度过程的高吞吐与低延迟
  • 高可靠性与高可用性保障（快速切换）
  • 高可扩展的调度策略（需求不同：有的需要全局最优调度、有的需要低延迟）
  • 高集群整体物理利用率（硬件成本高）
  • 满足上层任务的个性化调度需求（调用不同的节点）
  • 任务持续、高效、稳定运行
  • We want to have all of them...However...

调度系统泛型

  1. 只有一个Master
  2. 调度层压力降低
  3. 调度冲突
  4. 不能全局最优调度

前两种用的多

1.3 YARN设计思想–演化背景

  • Hadoop 1.0时代:

  • MapReduce承担工作非常多。一边维护工作运行状态，一边负责资源调度

    • 可扩展性差
    • 可靠性差
    • 资源利用率低（槽位）
    • 无法支持多种计算框架

  • Hadoop 2.0时代:

    • 资源管理和任务控制解耦

      • 与具体的计算框架并不绑定

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

离线生态

面临挑战

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

1.4 YARN 整体架构–系统架构

  • Resource Manager

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

  • Node Manager

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

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

02. 核心模块

Resource Manager

  • 整体架构
  • 主要职责
  • 状态机管理
  • 调度器分析

Node Manager

  • 整体架构
  • 主要职责
  • 状态机管理
  • 节点健康检测机制

2.1 Resource Manager-整体架构

UserService ：提供服务，外部访问

主要职责

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

  • 与客户端交互

  • 启动和管理所有AM

  • 管理所有NM

  • 资源管理与调度

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

RMApp状态机

一个任务提交上来后，就会在RM维护

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

RMAppAttempt

失败重试的对象

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

RMContainer

每一个容器在RM内部都会被维护

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

    • 某些大容器分配资源比较多，有可能永远都轮不上

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

  • ACQUIRED:Container被AM领走后的状态;

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

RMNode

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

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

  • 任务按队列组织：不同的核心、内存数
  • YARN节点按Label组织（任务资源模型）

调度流程

  • AM与RM心跳:记录资源请求
  • 触发时机:节点心跳
  • 找Label:获取所有队列
  • 找队列:最“饥饿”队列优先
  • 找任务:优先级高的任务优先
  • 找资源请求:优先级高的请求优先
avatar
文章
阅读
粉丝