|
2.4 YARN 基本架构5 X1 U1 E5 p+ e2 k8 e1 n! A9 P
YARN是Hadoop 2.0中的资源管理系统, 它的基本设计思想是将MRv1中的JobTracker拆分成了两个独立的服务: 一个全局的2 o1 B5 v# {# e2 b, j' u- }
资源管理器ResourceManager和每个应用程序特有的ApplicationMaster。 其中ResourceManager负责整个系统的资源管理和分配, 而3 G% V. V( W4 ^0 N
ApplicationMaster负责单个应用程序的管理。; i4 A) U) s* @3 O
2.4.1 YARN基本组成结构0 Z1 C9 H& v- h; G# u D+ W
YARN总体上仍然是Master/Slave结构, 在整个资源管理框架中, ResourceManager为Master, NodeManager为3 S3 D6 E" c, Z- j
Slave, ResourceManager负责对各个NodeManager上的资源进行统一管理和调度。 当用户提交一个应用程序时, 需要提供一个用以
" n" F; z9 i5 W' V0 _跟踪和管理这个程序的ApplicationMaster, 它负责向ResourceManager申请资源, 并要求NodeManger启动可以占用一定资源的任. Y4 h' \( D3 q. f$ c1 g) R
务。 由于不同的ApplicationMaster被分布到不同的节点上, 因此它们之间不会相互影响。 在本小节中, 我们将对YARN的基本组成
3 ^0 _* K( [1 V/ j/ M4 B5 P; F结构进行介绍。+ F* ~: g3 Z2 u- e7 |3 U- j
图2-9描述了YARN的基本组成结构, YARN主要由ResourceManager、 NodeManager、 ApplicationMaster( 图中给出了" g# c3 h) E; z$ }" J0 U
MapReduce和MPI两种计算框架的ApplicationMaster, 分别为MR AppMstr和MPI AppMstr) 和Container等几个组件构成。
e, n h1 p4 ^+ k- @2 y7 X( a图2-9 Apache YARN的基本架构9 _, m! A5 k) J; m
1.ResourceManager( RM)
8 A. f7 F: ^7 wRM是一个全局的资源管理器, 负责整个系统的资源管理和分配。 它主要由两个组件构成: 调度器( Scheduler) 和应用程序
7 S/ C( Q5 U; J) G' ^管理器( Applications Manager, ASM) 。
( I( Q2 _2 T i" o6 d9 i+ S( 1) 调度器( d( ~9 d+ ?% e0 k! C
调度器根据容量、 队列等限制条件( 如每个队列分配一定的资源, 最多执行一定数量的作业等) , 将系统中的资源分配给各
" N/ q: ^7 f" c8 V* a7 }8 b个正在运行的应用程序。 需要注意的是, 该调度器是一个“纯调度器”, 它不再从事任何与具体应用程序相关的工作, 比如不负责4 W4 Z& s$ W; H) n
监控或者跟踪应用的执行状态等, 也不负责重新启动因应用执行失败或者硬件故障而产生的失败任务, 这些均交由应用程序相关
, H! C G' [: r" C; m的ApplicationMaster完成。 调度器仅根据各个应用程序的资源需求进行资源分配, 而资源分配单位用一个抽象概念“资源容; V6 d: ?+ ]3 |2 {
器”( Resource Container, 简称Container) 表示, Container是一个动态资源分配单位, 它将内存、 CPU、 磁盘、 网络等资源封装在
7 }0 B: H- g8 d一起, 从而限定每个任务使用的资源量。 此外, 该调度器是一个可插拔的组件, 用户可根据自己的需要设计新的调度器, YARN
3 y! | M; H# g5 e- R提供了多种直接可用的调度器, 比如Fair Scheduler和Capacity Scheduler等。
7 z, y( Y" M, Z* Z1 J7 ]! U6 P( 2) 应用程序管理器
. O- z4 F" J3 n* B2 h3 d& \2 R' R4 x应用程序管理器负责管理整个系统中所有应用程序, 包括应用程序提交、 与调度器协商资源以启动ApplicationMaster、 监控8 z6 x+ V: T. J, k
ApplicationMaster运行状态并在失败时重新启动它等。
$ H* x- E4 ~# W n/ D |) w2.ApplicationMaster( AM)
8 ?! H; h) H @/ C! k* N E0 r用户提交的每个应用程序均包含一个AM, 主要功能包括:9 z3 o% i" p: A7 \5 `' k5 i
❑与RM调度器协商以获取资源( 用Container表示) ;- }+ M! ]3 M1 l, e% [! a! D
❑将得到的任务进一步分配给内部的任务;( K* _/ C- f. F& Z/ n! J& l. G
❑与NM通信以启动/停止任务;* m2 `# i* d; M' T( d
❑监控所有任务运行状态, 并在任务运行失败时重新为任务申请资源以重启任务。. a3 ? C: r2 A; C
当前YARN自带了两个AM实现, 一个是用于演示AM编写方法的实例程序distributedshell, 它可以申请一定数目的Container以
a: M4 k9 P, d$ X2 Z7 m并行运行一个Shell命令或者Shell脚本; 另一个是运行MapReduce应用程序的AM—MRAppMaster, 我们将在第8章对其进行介绍。; |" w: F5 ]& }! d
此外, 一些其他的计算框架对应的AM正在开发中, 比 如Open MPI、 Spark等 [18] 。
6 }% N9 v+ o7 H; \! o3.NodeManager( NM)4 _1 `) ^5 {5 ~& g1 _
NM是每个节点上的资源和任务管理器, 一方面, 它会定时地向RM汇报本节点上的资源使用情况和各个Container的运行状
6 w/ R% s& }: t2 i& p8 ]态; 另一方面, 它接收并处理来自AM的Container启动/停止等各种请求。
% ^6 V% x; t" G4.Container
4 L# B5 Q: t( ^7 h" p: Y3 X$ g# VContainer是YARN中的资源抽象, 它封装了某个节点上的多维度资源, 如内存、 CPU、 磁盘、 网络等, 当AM向RM申请资源
' F F t$ [/ r7 A时, RM为AM返回的资源便是用Container表示的。 YARN会为每个任务分配一个Container, 且该任务只能使用该Container中描述的
$ |5 C7 `/ }" G0 O' ~/ l) V资源。 需要注意的是, Container不同于MRv1中的slot, 它是一个动态资源划分单位, 是根据应用程序的需求动态生成的。 截至本1 j' T: ^$ b5 V* G$ n- e
书完成时, YARN仅支持CPU和内存两种资源, 且使用了轻量级资源隔离机制Cgroups进行 资源隔离 [19] 。
6 t1 c; }( @3 S2.4.2 YARN通信协议
5 l& W1 P, l u+ ZRPC协议是连接各个组件的“大动脉”, 了解不同组件之间的RPC协议有助于我们更深入地学习YARN框架。 在YARN中, 任何
+ G; L4 z$ E% u. r. x" K- N$ @两个需相互通信的组件之间仅有一个RPC协议, 而对于任何一个RPC协议, 通信双方有一端是Client, 另一端为Server, 且Client总
) g0 f* j: ^5 |' F. x4 {% H$ P# Q是主动连接Server的, 因此, YARN实际上采用的是拉式( pull-based) 通信模型。 如图2-10所示, 箭头指向的组件是RPC Server,3 I. L5 E' }' z% e- Q
而箭头尾部的组件是RPC Client, YARN主要由以下几个RPC协 议组成 [20] :% l; [, G* d: m7 J6 C( y" `
❑JobClient( 作业提交客户端) 与RM之间的协议—ApplicationClientProtocol: JobClient通过该RPC协议提交应用程序、 查询应
3 c0 K5 R3 t# x用程序状态等。- S) d( C0 p6 P' \9 S$ o: Q
❑Admin( 管理员) 与RM之间的通信协议—ResourceManagerAdministrationProtocol: Admin通过该RPC协议更新系统配置文件, D# i* [- _, O) e
比如节点黑白名单、 用户队列权限等。
' y+ R8 i: W1 d; h. U/ y/ p: B❑AM与RM之间的协议—ApplicationMasterProtocol: AM通过该RPC协议向RM注册和撤销自己, 并为各个任务申请资源。
, f8 u" A1 m7 h# {; N$ P❑AM与NM之间的协议—ContainerManagementProtocol: AM通过该RPC要求NM启动或者停止Container, 获取各个Container的, b4 ?) e5 X$ f/ B. A' H
使用状态等信息。4 ?* o1 Z3 E0 |9 s6 h
❑NM与RM之间的协议—ResourceTracker: NM通过该RPC协议向RM注册, 并定时发送心跳信息汇报当前节点的资源使用情
) U, ]$ t& ?3 ^( C) t& W/ C' }况和Container运行情况。9 ]1 x/ o# l0 ~# `3 j) i
图2-10 Apache YARN的RPC协议
: x4 \4 g8 B5 f6 }4 k为了提高Hadoop的向后兼容性和不同版本之间的兼容性, YARN中的序列化框架采用了Google开源的Protocol Buffers。6 y0 @9 A% A3 V! z7 Z
Protocol Buffers的引入使得YARN具有协议向后兼容性, 相关内容将在第3章介绍。9 a7 o" ?+ N3 ?9 C5 l b& Q7 U
[18] 参见网址http://wiki.apache.org/hadoop/PoweredByYarn。
( O! g* N/ a3 @' y1 n4 r2 w! x0 n. e[19] 参见网址https://issues.apache.org/jira/browse/YARN-3。, {3 ^, I) C' X; Q+ O
[20] RPC协议名称在2.1.0-beta版本进行了重构, 之前的名称分别为: ClientRMProtocol、 RMAdminProtocol、 AMRMProtocol、
* J0 l" q6 g+ a2 J2 X. M iContainerManager、 ResourceTracker( 该协议名称未变)
( k* U& I3 L& ~- O1 P2 w% I
! }& j5 C4 @, Y3 U9 C5 Y: n
+ @- x: J% n0 y' Q, Y/ Q+ N7 p |
|