|
2.4 YARN 基本架构
: f; n' _; U# {+ P. u# `, B3 I* x" xYARN是Hadoop 2.0中的资源管理系统, 它的基本设计思想是将MRv1中的JobTracker拆分成了两个独立的服务: 一个全局的/ M$ l6 B' M! o+ e7 |2 X, E4 l2 F, l5 X
资源管理器ResourceManager和每个应用程序特有的ApplicationMaster。 其中ResourceManager负责整个系统的资源管理和分配, 而8 A8 Z0 [+ \# g( T
ApplicationMaster负责单个应用程序的管理。
5 P' h( T7 ^ h% _ N8 }, M# \2.4.1 YARN基本组成结构
, |* ^; q3 K+ V+ JYARN总体上仍然是Master/Slave结构, 在整个资源管理框架中, ResourceManager为Master, NodeManager为3 V" G3 x' y" C7 k/ r. w
Slave, ResourceManager负责对各个NodeManager上的资源进行统一管理和调度。 当用户提交一个应用程序时, 需要提供一个用以# Y# _/ L3 \/ W+ H
跟踪和管理这个程序的ApplicationMaster, 它负责向ResourceManager申请资源, 并要求NodeManger启动可以占用一定资源的任. m w; v- T$ B( }5 F" }, i* t# M
务。 由于不同的ApplicationMaster被分布到不同的节点上, 因此它们之间不会相互影响。 在本小节中, 我们将对YARN的基本组成
D* x' ^2 \7 m( U- S% C结构进行介绍。& N1 ^: }7 V+ t& N/ ]* h
图2-9描述了YARN的基本组成结构, YARN主要由ResourceManager、 NodeManager、 ApplicationMaster( 图中给出了1 T- `4 t; I# {+ S( }
MapReduce和MPI两种计算框架的ApplicationMaster, 分别为MR AppMstr和MPI AppMstr) 和Container等几个组件构成。6 Z2 w' t, R4 g/ R* _
图2-9 Apache YARN的基本架构
) S6 [8 |7 T7 r3 X1 G! G2 |7 @3 u" ~- U1.ResourceManager( RM)% Q7 \: A$ c/ a( g& q' b8 j
RM是一个全局的资源管理器, 负责整个系统的资源管理和分配。 它主要由两个组件构成: 调度器( Scheduler) 和应用程序
/ w- b5 u' y5 c& n0 l5 M6 K管理器( Applications Manager, ASM) 。
" X; ^- X& R7 G1 g/ @; j: h+ h# p5 a" q( 1) 调度器, F7 M1 T9 h/ f v
调度器根据容量、 队列等限制条件( 如每个队列分配一定的资源, 最多执行一定数量的作业等) , 将系统中的资源分配给各1 [9 @' W9 {' C4 w
个正在运行的应用程序。 需要注意的是, 该调度器是一个“纯调度器”, 它不再从事任何与具体应用程序相关的工作, 比如不负责4 c* b0 Y' k+ `# n# @
监控或者跟踪应用的执行状态等, 也不负责重新启动因应用执行失败或者硬件故障而产生的失败任务, 这些均交由应用程序相关. P, T8 `; T( C Q
的ApplicationMaster完成。 调度器仅根据各个应用程序的资源需求进行资源分配, 而资源分配单位用一个抽象概念“资源容1 P5 L" g2 S* \ F
器”( Resource Container, 简称Container) 表示, Container是一个动态资源分配单位, 它将内存、 CPU、 磁盘、 网络等资源封装在( ?) l; O' c/ u8 Z
一起, 从而限定每个任务使用的资源量。 此外, 该调度器是一个可插拔的组件, 用户可根据自己的需要设计新的调度器, YARN
% d( j9 |- I# E; a* Q提供了多种直接可用的调度器, 比如Fair Scheduler和Capacity Scheduler等。
0 b1 }% k8 |1 Z( 2) 应用程序管理器4 E* X! R8 t/ }& ^2 C6 ^! `2 F* i3 V
应用程序管理器负责管理整个系统中所有应用程序, 包括应用程序提交、 与调度器协商资源以启动ApplicationMaster、 监控
; @/ j7 a. g; k; i9 WApplicationMaster运行状态并在失败时重新启动它等。
1 n1 f r; \# t/ B2.ApplicationMaster( AM)2 i3 ^; y) s7 r. f
用户提交的每个应用程序均包含一个AM, 主要功能包括:, e( X. r; f/ g; l# Y m
❑与RM调度器协商以获取资源( 用Container表示) ;
' j$ d5 c; N' b" e# j9 K* I❑将得到的任务进一步分配给内部的任务;7 |0 ?$ g- T% Z8 Z, [! D0 J) h
❑与NM通信以启动/停止任务;# S; ~' g' o; i4 y2 t F
❑监控所有任务运行状态, 并在任务运行失败时重新为任务申请资源以重启任务。
' w p( N; P0 Q( d0 ]' b a当前YARN自带了两个AM实现, 一个是用于演示AM编写方法的实例程序distributedshell, 它可以申请一定数目的Container以) n: l/ B7 A- h
并行运行一个Shell命令或者Shell脚本; 另一个是运行MapReduce应用程序的AM—MRAppMaster, 我们将在第8章对其进行介绍。
1 }9 k& \: i3 B" s% Q C: |此外, 一些其他的计算框架对应的AM正在开发中, 比 如Open MPI、 Spark等 [18] 。" m; B% k1 i+ c% P1 \
3.NodeManager( NM)
1 {# z/ D% o* _3 g) T% N# y" R6 tNM是每个节点上的资源和任务管理器, 一方面, 它会定时地向RM汇报本节点上的资源使用情况和各个Container的运行状 a# y. Q2 ?6 [2 W5 e8 T
态; 另一方面, 它接收并处理来自AM的Container启动/停止等各种请求。( ?3 ?3 N2 c7 e0 u( X. q
4.Container
% l" x! _' q+ Z ^7 g' D3 BContainer是YARN中的资源抽象, 它封装了某个节点上的多维度资源, 如内存、 CPU、 磁盘、 网络等, 当AM向RM申请资源
9 b& T8 k1 S2 e5 X; N0 Y时, RM为AM返回的资源便是用Container表示的。 YARN会为每个任务分配一个Container, 且该任务只能使用该Container中描述的1 J* d0 `3 \7 K% i
资源。 需要注意的是, Container不同于MRv1中的slot, 它是一个动态资源划分单位, 是根据应用程序的需求动态生成的。 截至本
' `3 U' n4 m- z% h8 \' a, l书完成时, YARN仅支持CPU和内存两种资源, 且使用了轻量级资源隔离机制Cgroups进行 资源隔离 [19] 。
( r0 Z& g7 X& Q: h+ K2.4.2 YARN通信协议) W5 E/ E/ `( F4 m/ R3 i1 ]
RPC协议是连接各个组件的“大动脉”, 了解不同组件之间的RPC协议有助于我们更深入地学习YARN框架。 在YARN中, 任何
, d! W4 r1 I }7 o两个需相互通信的组件之间仅有一个RPC协议, 而对于任何一个RPC协议, 通信双方有一端是Client, 另一端为Server, 且Client总
6 q3 C$ {9 ^. [5 e. n是主动连接Server的, 因此, YARN实际上采用的是拉式( pull-based) 通信模型。 如图2-10所示, 箭头指向的组件是RPC Server,
# |4 b# g- a8 G3 G, H s5 ^/ p2 k而箭头尾部的组件是RPC Client, YARN主要由以下几个RPC协 议组成 [20] :
; }, ]6 l* `5 i7 c" X, v1 I( c❑JobClient( 作业提交客户端) 与RM之间的协议—ApplicationClientProtocol: JobClient通过该RPC协议提交应用程序、 查询应9 ]; U# l6 Z4 D. A; O7 h, X
用程序状态等。
% F, u1 \& \& n! W❑Admin( 管理员) 与RM之间的通信协议—ResourceManagerAdministrationProtocol: Admin通过该RPC协议更新系统配置文件,
' U% p6 j# A/ ^( G/ c0 |比如节点黑白名单、 用户队列权限等。
- w% \6 Z( I. y❑AM与RM之间的协议—ApplicationMasterProtocol: AM通过该RPC协议向RM注册和撤销自己, 并为各个任务申请资源。; N; r4 J1 c% s" H1 ]
❑AM与NM之间的协议—ContainerManagementProtocol: AM通过该RPC要求NM启动或者停止Container, 获取各个Container的
; b# n S5 O# j+ q8 \( O F) c% h使用状态等信息。% L5 {3 {- }6 q# S3 X ]" ^
❑NM与RM之间的协议—ResourceTracker: NM通过该RPC协议向RM注册, 并定时发送心跳信息汇报当前节点的资源使用情
( f8 i7 a2 K2 ^& u& E况和Container运行情况。! J) W5 R" E* j- c) F8 Y
图2-10 Apache YARN的RPC协议0 T5 K2 `% c1 @' Y2 Q, {* M
为了提高Hadoop的向后兼容性和不同版本之间的兼容性, YARN中的序列化框架采用了Google开源的Protocol Buffers。/ \' J. h" q$ r8 Z: y: U
Protocol Buffers的引入使得YARN具有协议向后兼容性, 相关内容将在第3章介绍。
* z: Z5 I E/ z& K. T! [3 O[18] 参见网址http://wiki.apache.org/hadoop/PoweredByYarn。; o1 L1 O: o; q% {* M+ y& q
[19] 参见网址https://issues.apache.org/jira/browse/YARN-3。7 u2 _+ {& x7 {
[20] RPC协议名称在2.1.0-beta版本进行了重构, 之前的名称分别为: ClientRMProtocol、 RMAdminProtocol、 AMRMProtocol、
6 s0 w9 W' W# o6 r7 W6 M* [ContainerManager、 ResourceTracker( 该协议名称未变)
7 O! E0 n t( k' s+ B
- P% s* T3 A. s$ E' |( A% _& O0 o0 o, R& `8 v
|
|