|
|
2.4 YARN 基本架构
0 x; o0 x% }$ C7 j4 S' U, W$ RYARN是Hadoop 2.0中的资源管理系统， 它的基本设计思想是将MRv1中的JobTracker拆分成了两个独立的服务： 一个全局的
5 R4 Z' c$ ^1 O$ _9 c- K资源管理器ResourceManager和每个应用程序特有的ApplicationMaster。 其中ResourceManager负责整个系统的资源管理和分配， 而
- ]# J# ^% D" y" D+ T7 ?ApplicationMaster负责单个应用程序的管理。1 C( @ M: e% C) C' B
2.4.1 YARN基本组成结构
/ d7 I \9 M& o1 B( e3 E4 `4 DYARN总体上仍然是Master/Slave结构， 在整个资源管理框架中， ResourceManager为Master， NodeManager为
" K( |; z7 N: y1 b/ p4 Z6 jSlave， ResourceManager负责对各个NodeManager上的资源进行统一管理和调度。 当用户提交一个应用程序时， 需要提供一个用以2 w- t" p& r. `; o5 S
跟踪和管理这个程序的ApplicationMaster， 它负责向ResourceManager申请资源， 并要求NodeManger启动可以占用一定资源的任: W( K9 c9 o7 E- n: C- e1 W9 ]
务。 由于不同的ApplicationMaster被分布到不同的节点上， 因此它们之间不会相互影响。 在本小节中， 我们将对YARN的基本组成
/ _5 @; K* S: E5 |9 H) f$ R结构进行介绍。- G/ G% ?9 b! ]. I* J1 h
图2-9描述了YARN的基本组成结构， YARN主要由ResourceManager、 NodeManager、 ApplicationMaster（ 图中给出了3 m( X) H7 E6 _ e% S
MapReduce和MPI两种计算框架的ApplicationMaster， 分别为MR AppMstr和MPI AppMstr） 和Container等几个组件构成。
( y' O- v+ a4 d* W! v图2-9 Apache YARN的基本架构 o" P( ~9 F* L$ d$ u- Q
1.ResourceManager（ RM）
" c: G1 f0 z: H8 D4 }( DRM是一个全局的资源管理器， 负责整个系统的资源管理和分配。 它主要由两个组件构成： 调度器（ Scheduler） 和应用程序
8 P6 }6 o+ c% k- B, u% Y/ m) u6 j管理器（ Applications Manager， ASM） 。/ }: A" @' W3 K x+ |
（ 1） 调度器8 _ s0 L1 W6 |; `' \, N% |6 P
调度器根据容量、 队列等限制条件（ 如每个队列分配一定的资源， 最多执行一定数量的作业等） ， 将系统中的资源分配给各
1 B0 c) m* ^; r1 {% @& K( s个正在运行的应用程序。 需要注意的是， 该调度器是一个“纯调度器”， 它不再从事任何与具体应用程序相关的工作， 比如不负责
' q# X# ]& d' |监控或者跟踪应用的执行状态等， 也不负责重新启动因应用执行失败或者硬件故障而产生的失败任务， 这些均交由应用程序相关: Y1 |/ p) I4 u6 r
的ApplicationMaster完成。 调度器仅根据各个应用程序的资源需求进行资源分配， 而资源分配单位用一个抽象概念“资源容, U8 c% F* E0 U; A+ |2 H4 K
器”（ Resource Container， 简称Container） 表示， Container是一个动态资源分配单位， 它将内存、 CPU、 磁盘、 网络等资源封装在2 c: L0 z9 B- y2 b1 k& a/ H
一起， 从而限定每个任务使用的资源量。 此外， 该调度器是一个可插拔的组件， 用户可根据自己的需要设计新的调度器， YARN! z3 o \* i2 |# C
提供了多种直接可用的调度器， 比如Fair Scheduler和Capacity Scheduler等。: c- G9 C) u$ X$ p% x" g7 R# b. P
（ 2） 应用程序管理器
; `2 o6 h, R5 |/ E. u1 b应用程序管理器负责管理整个系统中所有应用程序， 包括应用程序提交、 与调度器协商资源以启动ApplicationMaster、 监控2 @; f' c9 O3 O- i. N
ApplicationMaster运行状态并在失败时重新启动它等。
1 T4 b! z$ |' h% @( S2.ApplicationMaster（ AM）- B5 }" R: {8 I; Y
用户提交的每个应用程序均包含一个AM， 主要功能包括：
% F/ U8 ~, B$ R* P❑与RM调度器协商以获取资源（ 用Container表示） ；
6 V8 j2 P" A* | B m❑将得到的任务进一步分配给内部的任务；
7 ^7 i3 R0 e, R2 j" l3 C; e❑与NM通信以启动/停止任务；; D2 v1 I& ^9 O W
❑监控所有任务运行状态， 并在任务运行失败时重新为任务申请资源以重启任务。; R& e1 P) ]2 a) K/ J6 O
当前YARN自带了两个AM实现， 一个是用于演示AM编写方法的实例程序distributedshell， 它可以申请一定数目的Container以
3 B3 n& C1 L6 C! t: H8 J% G并行运行一个Shell命令或者Shell脚本； 另一个是运行MapReduce应用程序的AM—MRAppMaster， 我们将在第8章对其进行介绍。5 `: {" t) C L' M
此外， 一些其他的计算框架对应的AM正在开发中， 比 如Open MPI、 Spark等 [18] 。
: t7 s3 Q7 T7 e" E, P3.NodeManager（ NM）
& | ]- Y+ O" J$ BNM是每个节点上的资源和任务管理器， 一方面， 它会定时地向RM汇报本节点上的资源使用情况和各个Container的运行状; a' Q& f4 [, \
态； 另一方面， 它接收并处理来自AM的Container启动/停止等各种请求。( m2 k1 M! b U2 t
4.Container. I6 |. w# ^" G0 S3 y1 g D
Container是YARN中的资源抽象， 它封装了某个节点上的多维度资源， 如内存、 CPU、 磁盘、 网络等， 当AM向RM申请资源
5 Q9 c5 \3 g1 ]# n) @5 N7 H时， RM为AM返回的资源便是用Container表示的。 YARN会为每个任务分配一个Container， 且该任务只能使用该Container中描述的
1 U8 M: O* Q# ?4 J E资源。 需要注意的是， Container不同于MRv1中的slot， 它是一个动态资源划分单位， 是根据应用程序的需求动态生成的。 截至本
! M9 z: g$ A. k' n( v5 i8 `( u书完成时， YARN仅支持CPU和内存两种资源， 且使用了轻量级资源隔离机制Cgroups进行 资源隔离 [19] 。; Y: F8 K; ^' E
2.4.2 YARN通信协议; l0 d5 H: d$ R; D8 `
RPC协议是连接各个组件的“大动脉”， 了解不同组件之间的RPC协议有助于我们更深入地学习YARN框架。 在YARN中， 任何( Y7 A% B, R% r. ^4 }0 F
两个需相互通信的组件之间仅有一个RPC协议， 而对于任何一个RPC协议， 通信双方有一端是Client， 另一端为Server， 且Client总2 w6 E3 n; ]# u9 E( {
是主动连接Server的， 因此， YARN实际上采用的是拉式（ pull-based） 通信模型。 如图2-10所示， 箭头指向的组件是RPC Server，
& j4 L" v2 i+ w7 i; x而箭头尾部的组件是RPC Client， YARN主要由以下几个RPC协 议组成 [20] ：
o6 K& L, E, U0 w' v# k/ N❑JobClient（ 作业提交客户端） 与RM之间的协议—ApplicationClientProtocol： JobClient通过该RPC协议提交应用程序、 查询应4 {4 f6 P5 N3 t" o5 g
用程序状态等。; j. I& Y8 g1 ]' p
❑Admin（ 管理员） 与RM之间的通信协议—ResourceManagerAdministrationProtocol： Admin通过该RPC协议更新系统配置文件，& E3 ]' B1 X1 ^ x
比如节点黑白名单、 用户队列权限等。. ^2 {7 J- m0 u4 {5 _$ E
❑AM与RM之间的协议—ApplicationMasterProtocol： AM通过该RPC协议向RM注册和撤销自己， 并为各个任务申请资源。
- h4 S+ L' ] ]: r5 F❑AM与NM之间的协议—ContainerManagementProtocol： AM通过该RPC要求NM启动或者停止Container， 获取各个Container的- t$ C; b& o* `8 M
使用状态等信息。
6 j8 U" I5 s; G# ^/ {7 D! ]❑NM与RM之间的协议—ResourceTracker： NM通过该RPC协议向RM注册， 并定时发送心跳信息汇报当前节点的资源使用情$ B; X* y: `8 l2 Q
况和Container运行情况。
# C7 I4 e. s# i5 L图2-10 Apache YARN的RPC协议
2 H% ] E/ b) p% _3 @2 H% @为了提高Hadoop的向后兼容性和不同版本之间的兼容性， YARN中的序列化框架采用了Google开源的Protocol Buffers。
- Z- d! \$ K3 {3 o: R: tProtocol Buffers的引入使得YARN具有协议向后兼容性， 相关内容将在第3章介绍。
! h+ R2 w6 @" s9 y9 c6 m' ?* G2 l[18] 参见网址http://wiki.apache.org/hadoop/PoweredByYarn。' P2 g5 d* q1 u" S
[19] 参见网址https://issues.apache.org/jira/browse/YARN-3。" M: }" b' Y$ u
[20] RPC协议名称在2.1.0-beta版本进行了重构， 之前的名称分别为： ClientRMProtocol、 RMAdminProtocol、 AMRMProtocol、
1 {; Y5 Q* K- E+ @$ ]ContainerManager、 ResourceTracker（ 该协议名称未变）
; m% h$ v+ o5 P- d- G. o" n& y5 g5 p1 `1 u3 X: A% ~' L0 n
4 `5 ~% _) u& `; l
|
|
发表于 2017-4-13 21:23:55
