|
|
2.4 YARN 基本架构
2 V) N5 x1 H$ G: a- l/ n/ J/ pYARN是Hadoop 2.0中的资源管理系统， 它的基本设计思想是将MRv1中的JobTracker拆分成了两个独立的服务： 一个全局的/ k" ~$ y6 F4 }( j g% W; G/ B
资源管理器ResourceManager和每个应用程序特有的ApplicationMaster。 其中ResourceManager负责整个系统的资源管理和分配， 而# p4 P* _/ ]' s1 y* @6 C
ApplicationMaster负责单个应用程序的管理。
' w! v' G! Z' l- q5 F9 P2.4.1 YARN基本组成结构' t7 c) o' J! X) q1 D8 m! w8 j: J
YARN总体上仍然是Master/Slave结构， 在整个资源管理框架中， ResourceManager为Master， NodeManager为
8 q% \( z' T; M0 _Slave， ResourceManager负责对各个NodeManager上的资源进行统一管理和调度。 当用户提交一个应用程序时， 需要提供一个用以8 M+ n" C: z8 Q* k" E
跟踪和管理这个程序的ApplicationMaster， 它负责向ResourceManager申请资源， 并要求NodeManger启动可以占用一定资源的任
" Y: A7 N- A" X' M R务。 由于不同的ApplicationMaster被分布到不同的节点上， 因此它们之间不会相互影响。 在本小节中， 我们将对YARN的基本组成
: y" j! Z! ]% f8 P4 S' ~0 u结构进行介绍。, D# Q7 S, Z# P* ?8 `2 P
图2-9描述了YARN的基本组成结构， YARN主要由ResourceManager、 NodeManager、 ApplicationMaster（ 图中给出了
0 c, F8 d' w: A; uMapReduce和MPI两种计算框架的ApplicationMaster， 分别为MR AppMstr和MPI AppMstr） 和Container等几个组件构成。
; v$ W* _7 A* k6 r: T% H+ ]+ x图2-9 Apache YARN的基本架构
6 l$ U1 y$ F8 a* y# ~% Y4 X1.ResourceManager（ RM）
2 p, x1 Q' T1 I8 N3 m+ H. l* URM是一个全局的资源管理器， 负责整个系统的资源管理和分配。 它主要由两个组件构成： 调度器（ Scheduler） 和应用程序- |" }: |' u# {0 m% t- u, z3 a6 W. {* u
管理器（ Applications Manager， ASM） 。+ \- w" |6 R' g. Y: G
（ 1） 调度器
8 Z5 [1 M( A2 T H+ t调度器根据容量、 队列等限制条件（ 如每个队列分配一定的资源， 最多执行一定数量的作业等） ， 将系统中的资源分配给各 }) H; M' B4 n8 K1 K
个正在运行的应用程序。 需要注意的是， 该调度器是一个“纯调度器”， 它不再从事任何与具体应用程序相关的工作， 比如不负责. j. Z7 X- `' q! f
监控或者跟踪应用的执行状态等， 也不负责重新启动因应用执行失败或者硬件故障而产生的失败任务， 这些均交由应用程序相关2 }$ l0 T/ Y4 P# x) v! K
的ApplicationMaster完成。 调度器仅根据各个应用程序的资源需求进行资源分配， 而资源分配单位用一个抽象概念“资源容4 @+ i- X' v' x- L) T) I$ b
器”（ Resource Container， 简称Container） 表示， Container是一个动态资源分配单位， 它将内存、 CPU、 磁盘、 网络等资源封装在$ u/ M1 T- w6 S' `. j6 O& }
一起， 从而限定每个任务使用的资源量。 此外， 该调度器是一个可插拔的组件， 用户可根据自己的需要设计新的调度器， YARN
9 v& Y, u8 P+ S( o; ]提供了多种直接可用的调度器， 比如Fair Scheduler和Capacity Scheduler等。
# _+ g! [5 b+ O0 ~（ 2） 应用程序管理器# `" D# P6 }9 l1 A+ W$ w8 ^: z
应用程序管理器负责管理整个系统中所有应用程序， 包括应用程序提交、 与调度器协商资源以启动ApplicationMaster、 监控0 Q: Q I* w* }) ]$ a% D$ m
ApplicationMaster运行状态并在失败时重新启动它等。
7 u- ]$ F' {# L, D7 V2.ApplicationMaster（ AM）
9 Y! P4 e9 j% s8 s, [* u用户提交的每个应用程序均包含一个AM， 主要功能包括：0 g6 M- {# |1 y& }% I, j
❑与RM调度器协商以获取资源（ 用Container表示） ；
! _" S; d+ G$ l❑将得到的任务进一步分配给内部的任务；: H/ c/ D v z& \5 W/ ~
❑与NM通信以启动/停止任务；
8 L9 P, k' t. |! \. C6 q Z) O( M4 x❑监控所有任务运行状态， 并在任务运行失败时重新为任务申请资源以重启任务。
. I) b: }5 T8 E6 I, a8 h. k, f) r6 w5 M当前YARN自带了两个AM实现， 一个是用于演示AM编写方法的实例程序distributedshell， 它可以申请一定数目的Container以
4 l- Z4 j" p: }2 D% s并行运行一个Shell命令或者Shell脚本； 另一个是运行MapReduce应用程序的AM—MRAppMaster， 我们将在第8章对其进行介绍。. _, P% V! l6 [) `7 t" t
此外， 一些其他的计算框架对应的AM正在开发中， 比 如Open MPI、 Spark等 [18] 。
; u% u* r* C. ^/ j# a$ u8 v3.NodeManager（ NM）' Y' Q0 t& p0 X. ^: f
NM是每个节点上的资源和任务管理器， 一方面， 它会定时地向RM汇报本节点上的资源使用情况和各个Container的运行状" k5 s" \3 ]$ J+ S, E M
态； 另一方面， 它接收并处理来自AM的Container启动/停止等各种请求。# \* h0 d; v% |/ m+ q3 F
4.Container6 a# s# @2 q! B
Container是YARN中的资源抽象， 它封装了某个节点上的多维度资源， 如内存、 CPU、 磁盘、 网络等， 当AM向RM申请资源
0 s0 Y3 ]. S7 h" ]* f时， RM为AM返回的资源便是用Container表示的。 YARN会为每个任务分配一个Container， 且该任务只能使用该Container中描述的& w1 _; m' C9 U: H9 ?
资源。 需要注意的是， Container不同于MRv1中的slot， 它是一个动态资源划分单位， 是根据应用程序的需求动态生成的。 截至本& Z6 h& g0 X8 B+ _4 P/ m" X" U
书完成时， YARN仅支持CPU和内存两种资源， 且使用了轻量级资源隔离机制Cgroups进行 资源隔离 [19] 。# y! Q% E; f- A
2.4.2 YARN通信协议( e0 q6 G6 S/ e; t1 ^! |
RPC协议是连接各个组件的“大动脉”， 了解不同组件之间的RPC协议有助于我们更深入地学习YARN框架。 在YARN中， 任何7 D x, G, `! P$ i2 _
两个需相互通信的组件之间仅有一个RPC协议， 而对于任何一个RPC协议， 通信双方有一端是Client， 另一端为Server， 且Client总5 E! a) {/ m- k0 n' C/ W+ e
是主动连接Server的， 因此， YARN实际上采用的是拉式（ pull-based） 通信模型。 如图2-10所示， 箭头指向的组件是RPC Server，
& ^" F5 R3 {3 U# g4 z, p而箭头尾部的组件是RPC Client， YARN主要由以下几个RPC协 议组成 [20] ：$ D6 f% m6 A- K3 x* y2 Y1 o( k; Z0 Y
❑JobClient（ 作业提交客户端） 与RM之间的协议—ApplicationClientProtocol： JobClient通过该RPC协议提交应用程序、 查询应
. J! ]9 f; j; Q; |) P* { z# X( Y! e用程序状态等。
/ T6 b+ s" K3 ~❑Admin（ 管理员） 与RM之间的通信协议—ResourceManagerAdministrationProtocol： Admin通过该RPC协议更新系统配置文件，
1 R& H/ Z, D1 X- r比如节点黑白名单、 用户队列权限等。8 S/ c. P3 k, N9 }
❑AM与RM之间的协议—ApplicationMasterProtocol： AM通过该RPC协议向RM注册和撤销自己， 并为各个任务申请资源。/ U' V5 e+ H' ^8 E: d( M, \9 }
❑AM与NM之间的协议—ContainerManagementProtocol： AM通过该RPC要求NM启动或者停止Container， 获取各个Container的, O0 b! Y8 ]) h( @3 ^ S2 @
使用状态等信息。
; E6 y4 Z8 h3 i5 G❑NM与RM之间的协议—ResourceTracker： NM通过该RPC协议向RM注册， 并定时发送心跳信息汇报当前节点的资源使用情
1 M) }. ~7 s# |2 N' [况和Container运行情况。
: y: \: q8 L# f) G$ @' f图2-10 Apache YARN的RPC协议2 w" [, r7 w& k
为了提高Hadoop的向后兼容性和不同版本之间的兼容性， YARN中的序列化框架采用了Google开源的Protocol Buffers。
$ J2 Z. r6 F8 o$ K# r3 N- HProtocol Buffers的引入使得YARN具有协议向后兼容性， 相关内容将在第3章介绍。
' ]/ ]5 A! r" H' S n8 J[18] 参见网址http://wiki.apache.org/hadoop/PoweredByYarn。6 Q6 v3 X& ?* b4 H3 t# a9 _
[19] 参见网址https://issues.apache.org/jira/browse/YARN-3。
6 c4 w4 S& B8 o8 q[20] RPC协议名称在2.1.0-beta版本进行了重构， 之前的名称分别为： ClientRMProtocol、 RMAdminProtocol、 AMRMProtocol、
' A3 e; W$ f% cContainerManager、 ResourceTracker（ 该协议名称未变）
8 e" `+ B7 J) m
: T7 l% P. A) w
2 A- E' x4 H+ k6 e9 d; [# f* F, D9 l |
|
发表于 2017-4-13 21:23:55
