一、Yarn 架构

1.1 基本概念

Yarn 采用传统的 master-slave 架构模式，其主要由 4 种组件组成，它们的主要功能如下：




  • ResourceManager（RM）：全局资源管理器，负责整个系统的资源管理和分配；

  • 处理客户端请求
  • 启动/监控ApplicationMaster
  • 监控NodeManager
  • 资源分配与调度

  • ApplicationMaster（AM）：负责应用程序（Application）的管理；

  • 为应用程序申请资源，并分配给内部任务
  • 任务调度、监控与容错

  • NodeManager（NM）：负责 slave 节点的资源管理和使用；

  • 单个节点上的资源管理
  • 处理来自ResourceManger的命令
  • 处理来自ApplicationMaster的命令

  • Container（容器）：对任务运行环境的一个抽象。


Yarn集群资源管理器_hadoop


Yarn 架构图


1.2 组件职责


ResourceManager (RM)


ResourceManager 是一个全局的资源管理器，负责整个系统的资源管理和分配。它主要由两个组件组成：


  • Scheduler：资源调度器，主要功能和特点如下：

  • 负责将资源分配给各种正在运行的应用程序，这些应用程序受到容量、队列等限制；
  • Scheduler 是纯调度程序，不会监视或跟踪应用程序的状态；
  • 由于应用程序故障或硬件故障，它不提供有关重新启动失败任务的保证；
  • Scheduler 根据应用程序的资源需求来执行其调度功能，它是基于资源容器的抽象概念来实现的，容器（Container）内包含内存、CPU、磁盘、网络等因素；
  • Scheduler 是一个可插拔的插件（即可配置），负责在各种队列、应用程序等之间对集群资源进行区分。当前支持的Scheduler类包括：FairScheduler、FifoScheduler、CapacityScheduler；

  • Application Manager：负责接受 job 提交请求，为应用程序分配第一个 Container 以运行 ApplicationMaster，并提供失败时重新启动运行着 ApplicationMaster 的 Container 的服务。

 

ApplicationMaster（AM）

当用户提交一个应用程序时，将启动一个被称为 ApplcationMaster 的轻量级进程的实例，用以协调应用程序内所有任务的执行。它的主要工作包括：


  • 向 ResourceManager 申请并以容器（Container）的形式提供计算资源；
  • 管理在容器内运行的任务：

  • 跟踪任务的状态并监视它们的执行；
  • 遇到失败时，重新启动失败的任务；
  • 推测性的运行缓慢的任务以及计算应用计数器的总值。


 

NodeManager（NM）

NodeManager 进程运行在集群中的节点上，是每个节点上的资源和任务管理器。它的主要功能包括：


  • 接收 ResourceManager 的资源分配请求，并为应用程序分配具体的 Container；
  • 定时地向 ResourceManager 汇报本节点上的资源使用情况和各个 Container 的运行状态，以确保整个集群平稳运行；
  • 管理每个 Container 的生命周期；
  • 管理每个节点上的日志；
  • 接收并处理来自 ApplicationMaster 的 Container 启动/停止等请求。

 

Container（容器）

Container 是 Yarn 中的资源抽象，是执行具体应用的基本单位，它包含了某个 NodeManager 节点上的多维度资源，如内存、CPU、磁盘和网络 IO，当然目前仅支持内存和 CPU。任何一个 Job 或应用程序必须运行在一个或多个 Container 中，在 Yarn 中，ResourceManager 只负责告诉 ApplicationMaster 哪些 Containers 可以用，ApplicationMaster 需要自己去找 NodeManager 请求分配具体的 Container。

Container 和集群节点的关系是：一个节点会运行多个 Container，但一个 Container 不会跨节点。

二、Yarn 任务提交流程


Yarn集群资源管理器_重新启动_02


Yarn 任务执行流程图


Yarn 任务执行流程主要包括如下几个步骤：



  2. 客户端向 RM 发出请求；
  3. RM 返回一个 ApplicationID 作为回应；
  4. 客户端向 RM 回应 Application Submission Context（ASC）和 Container Launch Context（CLC）信息。其中 ASC 包括 ApplicationID、user、queue，以及其它一些启动 AM 相关的信息，CLC 包含了资源请求数（内存与CPU），Job 文件，安全 token，以及其它一些用于在 NM 上启动 AM的信息；
  5. 当 ResourceManager 接受到 ASC 后，它会调度一个合适的 container 来启动 AM，这个 container 经常被称做 container 0。AM 需要请求其它的 container 来运行任务，如果没有合适的 container ，AM 就不能启动。当有合适的 container 时，RM 发请求到合适的 NM 上，来启动 AM。这时候，AM 的 PRC 与监控的 URL 就已经建立了；
  6. 当 AM 启动起来后，RM 回应给 AM 集群的最小与最大资源等信息。这时 AM 必须决定如何使用那么当前可用的资源。Yarm 不像那些请求固定资源的 scheduler，它能够根据集群的当前状态动态调整；
  7. AM 根据从 RM 那里得知的可使用的资源，它会请求一些一定数目的 container。这个请求可以是非常具体的包括具有多个资源最小值的 Container（例如额外的内存等）；
  8. RM 将会根据调度策略，尽可能的满足 AM 申请的 container；
  9. AM 根据分配的信息，去找NM启动对应的 container。