|
2.4 YARN 基本架构
! ?; R* ?) C1 D" U/ z1 A% N. _1 g/ [+ LYARN是Hadoop 2.0中的资源管理系统, 它的基本设计思想是将MRv1中的JobTracker拆分成了两个独立的服务: 一个全局的* X- t4 A$ n8 J) L+ p( b
资源管理器ResourceManager和每个应用程序特有的ApplicationMaster。 其中ResourceManager负责整个系统的资源管理和分配, 而+ m6 t6 p7 _8 s4 _
ApplicationMaster负责单个应用程序的管理。1 n8 k1 ?/ q2 q4 c/ l+ l" i. a
2.4.1 YARN基本组成结构
% C) ?' x# b5 I6 K' K: @9 M/ q3 ?YARN总体上仍然是Master/Slave结构, 在整个资源管理框架中, ResourceManager为Master, NodeManager为( }$ t8 G& x3 W% F& u" @
Slave, ResourceManager负责对各个NodeManager上的资源进行统一管理和调度。 当用户提交一个应用程序时, 需要提供一个用以0 a* ^; B- \( N. d# n$ T3 j6 N
跟踪和管理这个程序的ApplicationMaster, 它负责向ResourceManager申请资源, 并要求NodeManger启动可以占用一定资源的任) X# D5 F8 |3 c, A
务。 由于不同的ApplicationMaster被分布到不同的节点上, 因此它们之间不会相互影响。 在本小节中, 我们将对YARN的基本组成/ f7 f: e- ~1 p
结构进行介绍。; q9 {# P2 \4 W: C& {
图2-9描述了YARN的基本组成结构, YARN主要由ResourceManager、 NodeManager、 ApplicationMaster( 图中给出了
, q D0 B* H# \1 }9 uMapReduce和MPI两种计算框架的ApplicationMaster, 分别为MR AppMstr和MPI AppMstr) 和Container等几个组件构成。
: o! Q0 v) ?7 l& C$ f' N2 H图2-9 Apache YARN的基本架构; M+ ^& P8 f( Y- L" |( l
1.ResourceManager( RM)
; t' a$ W. G- ?RM是一个全局的资源管理器, 负责整个系统的资源管理和分配。 它主要由两个组件构成: 调度器( Scheduler) 和应用程序3 |4 E" {. S: w- ~5 u1 X
管理器( Applications Manager, ASM) 。) C- n5 M! I. D9 o/ O I
( 1) 调度器, T8 P/ Y8 [5 M$ o6 `! G0 @
调度器根据容量、 队列等限制条件( 如每个队列分配一定的资源, 最多执行一定数量的作业等) , 将系统中的资源分配给各
: M' E. T7 X+ v' u个正在运行的应用程序。 需要注意的是, 该调度器是一个“纯调度器”, 它不再从事任何与具体应用程序相关的工作, 比如不负责
$ R6 h0 D) H2 S# u, q$ r# a监控或者跟踪应用的执行状态等, 也不负责重新启动因应用执行失败或者硬件故障而产生的失败任务, 这些均交由应用程序相关9 p; d5 {; l9 k* d& t
的ApplicationMaster完成。 调度器仅根据各个应用程序的资源需求进行资源分配, 而资源分配单位用一个抽象概念“资源容
- Q/ u) b* w; H- W器”( Resource Container, 简称Container) 表示, Container是一个动态资源分配单位, 它将内存、 CPU、 磁盘、 网络等资源封装在
# b/ O: v y" t. r一起, 从而限定每个任务使用的资源量。 此外, 该调度器是一个可插拔的组件, 用户可根据自己的需要设计新的调度器, YARN+ b+ T5 O+ K% A7 F; j
提供了多种直接可用的调度器, 比如Fair Scheduler和Capacity Scheduler等。. m1 ^! N+ q& s3 M, A* P9 ?
( 2) 应用程序管理器) ?& a3 K+ I: b- g* O1 o, b
应用程序管理器负责管理整个系统中所有应用程序, 包括应用程序提交、 与调度器协商资源以启动ApplicationMaster、 监控
& v7 C% Q: }0 q" bApplicationMaster运行状态并在失败时重新启动它等。
! }5 R, F& ?# X1 J V! ?! _2.ApplicationMaster( AM)8 X( j/ \. `+ v: y
用户提交的每个应用程序均包含一个AM, 主要功能包括:
$ p/ H; e, f$ E/ o6 K! [/ X❑与RM调度器协商以获取资源( 用Container表示) ;8 s6 u% _% o# l5 } `- s' |
❑将得到的任务进一步分配给内部的任务;
7 j& B" c$ M) `/ I: ^! N0 A❑与NM通信以启动/停止任务;( W! i7 l, \) i: X' m7 O
❑监控所有任务运行状态, 并在任务运行失败时重新为任务申请资源以重启任务。
% J9 k! b4 x, I3 N9 o5 n当前YARN自带了两个AM实现, 一个是用于演示AM编写方法的实例程序distributedshell, 它可以申请一定数目的Container以
; J, Q9 o# g/ T+ }+ b并行运行一个Shell命令或者Shell脚本; 另一个是运行MapReduce应用程序的AM—MRAppMaster, 我们将在第8章对其进行介绍。
5 d1 v0 O( B/ Z9 x. L" V此外, 一些其他的计算框架对应的AM正在开发中, 比 如Open MPI、 Spark等 [18] 。" K! a f4 L9 K0 R. w
3.NodeManager( NM)
" o# h; _$ _7 b& k0 ^* Z8 KNM是每个节点上的资源和任务管理器, 一方面, 它会定时地向RM汇报本节点上的资源使用情况和各个Container的运行状
, E- W7 \% R+ g5 } G" p/ p5 u态; 另一方面, 它接收并处理来自AM的Container启动/停止等各种请求。8 E& ]* o0 @7 K' R/ ?; n8 ?8 a7 _
4.Container
5 j& ?/ x% _1 ^Container是YARN中的资源抽象, 它封装了某个节点上的多维度资源, 如内存、 CPU、 磁盘、 网络等, 当AM向RM申请资源, H; X! g* r% O ^
时, RM为AM返回的资源便是用Container表示的。 YARN会为每个任务分配一个Container, 且该任务只能使用该Container中描述的' L7 g$ h: [) [( B, S
资源。 需要注意的是, Container不同于MRv1中的slot, 它是一个动态资源划分单位, 是根据应用程序的需求动态生成的。 截至本
% G: j0 `, p$ u9 d# E) k# n书完成时, YARN仅支持CPU和内存两种资源, 且使用了轻量级资源隔离机制Cgroups进行 资源隔离 [19] 。/ x1 P* C* U/ j0 n# k
2.4.2 YARN通信协议
! t" _- `, E6 o1 pRPC协议是连接各个组件的“大动脉”, 了解不同组件之间的RPC协议有助于我们更深入地学习YARN框架。 在YARN中, 任何 A1 W% Z# b5 t ^! K
两个需相互通信的组件之间仅有一个RPC协议, 而对于任何一个RPC协议, 通信双方有一端是Client, 另一端为Server, 且Client总
6 J5 h! [$ P2 }是主动连接Server的, 因此, YARN实际上采用的是拉式( pull-based) 通信模型。 如图2-10所示, 箭头指向的组件是RPC Server,
4 ]* G1 u; ]' ^而箭头尾部的组件是RPC Client, YARN主要由以下几个RPC协 议组成 [20] :
) l4 l# O5 n( w❑JobClient( 作业提交客户端) 与RM之间的协议—ApplicationClientProtocol: JobClient通过该RPC协议提交应用程序、 查询应
+ j e3 E G* b$ `用程序状态等。+ p6 ]. Z+ g5 u; }/ Z8 E/ b: S
❑Admin( 管理员) 与RM之间的通信协议—ResourceManagerAdministrationProtocol: Admin通过该RPC协议更新系统配置文件,, }7 S2 ]8 m: g3 r6 n
比如节点黑白名单、 用户队列权限等。$ Y% N" a: p5 H$ z: }
❑AM与RM之间的协议—ApplicationMasterProtocol: AM通过该RPC协议向RM注册和撤销自己, 并为各个任务申请资源。
' f# G6 Z! Y" s5 Z; k3 g1 G! Q❑AM与NM之间的协议—ContainerManagementProtocol: AM通过该RPC要求NM启动或者停止Container, 获取各个Container的: [/ t! E$ ~( s+ y7 i; v$ m
使用状态等信息。
2 ]/ L; i0 r( ], e7 ?❑NM与RM之间的协议—ResourceTracker: NM通过该RPC协议向RM注册, 并定时发送心跳信息汇报当前节点的资源使用情
6 o2 R$ M( M: E- B' u: }* `况和Container运行情况。0 I$ E/ K! Y* \; p
图2-10 Apache YARN的RPC协议. y. L' t' e' O
为了提高Hadoop的向后兼容性和不同版本之间的兼容性, YARN中的序列化框架采用了Google开源的Protocol Buffers。- q* E$ b2 ?& |3 s( `7 k9 X
Protocol Buffers的引入使得YARN具有协议向后兼容性, 相关内容将在第3章介绍。7 V% W* Z C% t" C+ v" W
[18] 参见网址http://wiki.apache.org/hadoop/PoweredByYarn。
6 @- z; t4 ?& J# l- r% x1 K8 ~0 A[19] 参见网址https://issues.apache.org/jira/browse/YARN-3。( U4 V2 ?% Z7 z( J- l( A1 G
[20] RPC协议名称在2.1.0-beta版本进行了重构, 之前的名称分别为: ClientRMProtocol、 RMAdminProtocol、 AMRMProtocol、. L+ X# k0 w2 n8 i
ContainerManager、 ResourceTracker( 该协议名称未变)
. o. i4 E; X+ Z; Z4 \6 H- z; ~% V+ {7 r
% K& X K9 B* K* E y |
|