《深入解析YARN架构设计与实现原理》第2章 YARN设计理念与基本架构【2.4】
2.4 YARN 基本架构YARN是Hadoop 2.0中的资源管理系统， 它的基本设计思想是将MRv1中的JobTracker拆分成了两个独立的服务： 一个全局的
资源管理器ResourceManager和每个应用程序特有的ApplicationMaster。 其中ResourceManager负责整个系统的资源管理和分配， 而
ApplicationMaster负责单个应用程序的管理。
2.4.1 YARN基本组成结构
YARN总体上仍然是Master/Slave结构， 在整个资源管理框架中， ResourceManager为Master， NodeManager为
Slave， ResourceManager负责对各个NodeManager上的资源进行统一管理和调度。 当用户提交一个应用程序时， 需要提供一个用以
跟踪和管理这个程序的ApplicationMaster， 它负责向ResourceManager申请资源， 并要求NodeManger启动可以占用一定资源的任
务。 由于不同的ApplicationMaster被分布到不同的节点上， 因此它们之间不会相互影响。 在本小节中， 我们将对YARN的基本组成
结构进行介绍。
图2-9描述了YARN的基本组成结构， YARN主要由ResourceManager、 NodeManager、 ApplicationMaster（ 图中给出了
MapReduce和MPI两种计算框架的ApplicationMaster， 分别为MR AppMstr和MPI AppMstr） 和Container等几个组件构成。
图2-9 Apache YARN的基本架构
1.ResourceManager（ RM）
RM是一个全局的资源管理器， 负责整个系统的资源管理和分配。 它主要由两个组件构成： 调度器（ Scheduler） 和应用程序
管理器（ Applications Manager， ASM） 。
（ 1） 调度器
调度器根据容量、 队列等限制条件（ 如每个队列分配一定的资源， 最多执行一定数量的作业等） ， 将系统中的资源分配给各
个正在运行的应用程序。 需要注意的是， 该调度器是一个“纯调度器”， 它不再从事任何与具体应用程序相关的工作， 比如不负责
监控或者跟踪应用的执行状态等， 也不负责重新启动因应用执行失败或者硬件故障而产生的失败任务， 这些均交由应用程序相关
的ApplicationMaster完成。 调度器仅根据各个应用程序的资源需求进行资源分配， 而资源分配单位用一个抽象概念“资源容
器”（ Resource Container， 简称Container） 表示， Container是一个动态资源分配单位， 它将内存、 CPU、 磁盘、 网络等资源封装在
一起， 从而限定每个任务使用的资源量。 此外， 该调度器是一个可插拔的组件， 用户可根据自己的需要设计新的调度器， YARN
提供了多种直接可用的调度器， 比如Fair Scheduler和Capacity Scheduler等。
（ 2） 应用程序管理器
应用程序管理器负责管理整个系统中所有应用程序， 包括应用程序提交、 与调度器协商资源以启动ApplicationMaster、 监控
ApplicationMaster运行状态并在失败时重新启动它等。
2.ApplicationMaster（ AM）
用户提交的每个应用程序均包含一个AM， 主要功能包括：
❑与RM调度器协商以获取资源（ 用Container表示） ；
❑将得到的任务进一步分配给内部的任务；
❑与NM通信以启动/停止任务；
❑监控所有任务运行状态， 并在任务运行失败时重新为任务申请资源以重启任务。
当前YARN自带了两个AM实现， 一个是用于演示AM编写方法的实例程序distributedshell， 它可以申请一定数目的Container以
并行运行一个Shell命令或者Shell脚本； 另一个是运行MapReduce应用程序的AM—MRAppMaster， 我们将在第8章对其进行介绍。
此外， 一些其他的计算框架对应的AM正在开发中， 比 如Open MPI、 Spark等 。
3.NodeManager（ NM）
NM是每个节点上的资源和任务管理器， 一方面， 它会定时地向RM汇报本节点上的资源使用情况和各个Container的运行状
态； 另一方面， 它接收并处理来自AM的Container启动/停止等各种请求。
4.Container
Container是YARN中的资源抽象， 它封装了某个节点上的多维度资源， 如内存、 CPU、 磁盘、 网络等， 当AM向RM申请资源
时， RM为AM返回的资源便是用Container表示的。 YARN会为每个任务分配一个Container， 且该任务只能使用该Container中描述的
资源。 需要注意的是， Container不同于MRv1中的slot， 它是一个动态资源划分单位， 是根据应用程序的需求动态生成的。 截至本
书完成时， YARN仅支持CPU和内存两种资源， 且使用了轻量级资源隔离机制Cgroups进行 资源隔离 。
2.4.2 YARN通信协议
RPC协议是连接各个组件的“大动脉”， 了解不同组件之间的RPC协议有助于我们更深入地学习YARN框架。 在YARN中， 任何
两个需相互通信的组件之间仅有一个RPC协议， 而对于任何一个RPC协议， 通信双方有一端是Client， 另一端为Server， 且Client总
是主动连接Server的， 因此， YARN实际上采用的是拉式（ pull-based） 通信模型。 如图2-10所示， 箭头指向的组件是RPC Server，
而箭头尾部的组件是RPC Client， YARN主要由以下几个RPC协 议组成 ：
❑JobClient（ 作业提交客户端） 与RM之间的协议—ApplicationClientProtocol： JobClient通过该RPC协议提交应用程序、 查询应
用程序状态等。
❑Admin（ 管理员） 与RM之间的通信协议—ResourceManagerAdministrationProtocol： Admin通过该RPC协议更新系统配置文件，
比如节点黑白名单、 用户队列权限等。
❑AM与RM之间的协议—ApplicationMasterProtocol： AM通过该RPC协议向RM注册和撤销自己， 并为各个任务申请资源。
❑AM与NM之间的协议—ContainerManagementProtocol： AM通过该RPC要求NM启动或者停止Container， 获取各个Container的
使用状态等信息。
❑NM与RM之间的协议—ResourceTracker： NM通过该RPC协议向RM注册， 并定时发送心跳信息汇报当前节点的资源使用情
况和Container运行情况。
图2-10 Apache YARN的RPC协议
为了提高Hadoop的向后兼容性和不同版本之间的兼容性， YARN中的序列化框架采用了Google开源的Protocol Buffers。
Protocol Buffers的引入使得YARN具有协议向后兼容性， 相关内容将在第3章介绍。
参见网址http://wiki.apache.org/hadoop/PoweredByYarn。
参见网址https://issues.apache.org/jira/browse/YARN-3。
RPC协议名称在2.1.0-beta版本进行了重构， 之前的名称分别为： ClientRMProtocol、 RMAdminProtocol、 AMRMProtocol、
ContainerManager、 ResourceTracker（ 该协议名称未变）
页:
[1]