|
2.4 YARN 基本架构
1 K0 F( K7 q! Z7 U2 p& k/ HYARN是Hadoop 2.0中的资源管理系统, 它的基本设计思想是将MRv1中的JobTracker拆分成了两个独立的服务: 一个全局的0 z4 Y7 U& Y0 _; H
资源管理器ResourceManager和每个应用程序特有的ApplicationMaster。 其中ResourceManager负责整个系统的资源管理和分配, 而 j& s1 R5 M7 G" I
ApplicationMaster负责单个应用程序的管理。 L! G( a+ V: S, C- G
2.4.1 YARN基本组成结构
/ J. V% @$ p- R$ nYARN总体上仍然是Master/Slave结构, 在整个资源管理框架中, ResourceManager为Master, NodeManager为1 i4 B8 k/ q7 z" S
Slave, ResourceManager负责对各个NodeManager上的资源进行统一管理和调度。 当用户提交一个应用程序时, 需要提供一个用以) @& W0 `3 N6 L. R0 _
跟踪和管理这个程序的ApplicationMaster, 它负责向ResourceManager申请资源, 并要求NodeManger启动可以占用一定资源的任: C) O& v: s9 o6 z
务。 由于不同的ApplicationMaster被分布到不同的节点上, 因此它们之间不会相互影响。 在本小节中, 我们将对YARN的基本组成; D+ o6 P+ G$ }
结构进行介绍。0 b" R; L# |5 e. ^, p9 n% ^" M: H
图2-9描述了YARN的基本组成结构, YARN主要由ResourceManager、 NodeManager、 ApplicationMaster( 图中给出了; z2 |. j1 S- Q: A
MapReduce和MPI两种计算框架的ApplicationMaster, 分别为MR AppMstr和MPI AppMstr) 和Container等几个组件构成。! N: p' i1 d9 p2 `, `+ c+ @
图2-9 Apache YARN的基本架构$ z6 Q- b& K: X+ o" Q& o: X5 Y
1.ResourceManager( RM)
2 |! U( y* M' V& Y3 PRM是一个全局的资源管理器, 负责整个系统的资源管理和分配。 它主要由两个组件构成: 调度器( Scheduler) 和应用程序/ L' j' T$ v: r1 d
管理器( Applications Manager, ASM) 。1 u& I: i. S l& i- Y5 R; i
( 1) 调度器
7 \$ e8 d! I4 h2 o7 ]调度器根据容量、 队列等限制条件( 如每个队列分配一定的资源, 最多执行一定数量的作业等) , 将系统中的资源分配给各! C2 i$ D7 {: x. c! B. m
个正在运行的应用程序。 需要注意的是, 该调度器是一个“纯调度器”, 它不再从事任何与具体应用程序相关的工作, 比如不负责
& I. i4 \4 b3 _0 b# C: ^监控或者跟踪应用的执行状态等, 也不负责重新启动因应用执行失败或者硬件故障而产生的失败任务, 这些均交由应用程序相关, g! w" a& l! P$ _5 C9 W! p- X
的ApplicationMaster完成。 调度器仅根据各个应用程序的资源需求进行资源分配, 而资源分配单位用一个抽象概念“资源容
+ S! H$ U4 e# ~2 B; c. _器”( Resource Container, 简称Container) 表示, Container是一个动态资源分配单位, 它将内存、 CPU、 磁盘、 网络等资源封装在2 m. D5 }' {4 j
一起, 从而限定每个任务使用的资源量。 此外, 该调度器是一个可插拔的组件, 用户可根据自己的需要设计新的调度器, YARN0 q3 v/ I7 ^/ p+ T7 j& E1 k
提供了多种直接可用的调度器, 比如Fair Scheduler和Capacity Scheduler等。
. `: v# q1 R; [4 I0 g7 w( 2) 应用程序管理器
8 ?, I+ }6 L0 E. N3 V- j% B$ H应用程序管理器负责管理整个系统中所有应用程序, 包括应用程序提交、 与调度器协商资源以启动ApplicationMaster、 监控( S% O* T& o% x) v: {: A
ApplicationMaster运行状态并在失败时重新启动它等。
. |9 V" R# X; J- q; j& M0 M2.ApplicationMaster( AM)
$ g3 J: J6 G9 [* `7 M; I# D用户提交的每个应用程序均包含一个AM, 主要功能包括:
S7 j; D) d! ~2 S* ]❑与RM调度器协商以获取资源( 用Container表示) ;
: j3 Z: N0 r2 @- O5 L❑将得到的任务进一步分配给内部的任务;
A% p2 L: G( W6 ~" ^7 o❑与NM通信以启动/停止任务;2 t3 u# }7 x0 n; L
❑监控所有任务运行状态, 并在任务运行失败时重新为任务申请资源以重启任务。 y. u& O) A, ~$ _* i
当前YARN自带了两个AM实现, 一个是用于演示AM编写方法的实例程序distributedshell, 它可以申请一定数目的Container以. [' h! h: _, c" o: _+ S
并行运行一个Shell命令或者Shell脚本; 另一个是运行MapReduce应用程序的AM—MRAppMaster, 我们将在第8章对其进行介绍。
2 P) Z: s" g; }4 G% d: N4 D此外, 一些其他的计算框架对应的AM正在开发中, 比 如Open MPI、 Spark等 [18] 。/ ~+ {( `! z/ X% E6 V( |
3.NodeManager( NM)0 E, J3 }7 Z2 a* J% ^
NM是每个节点上的资源和任务管理器, 一方面, 它会定时地向RM汇报本节点上的资源使用情况和各个Container的运行状
! n# S7 _2 Y" E( L1 K态; 另一方面, 它接收并处理来自AM的Container启动/停止等各种请求。
0 x6 c- ^; K# n s% F$ F4.Container V" y. N( p2 s6 d- s0 }5 Q: G4 g
Container是YARN中的资源抽象, 它封装了某个节点上的多维度资源, 如内存、 CPU、 磁盘、 网络等, 当AM向RM申请资源
& w" o3 B3 f; C$ F* H7 \时, RM为AM返回的资源便是用Container表示的。 YARN会为每个任务分配一个Container, 且该任务只能使用该Container中描述的
8 |! o5 {/ ]- ~4 p( h, L资源。 需要注意的是, Container不同于MRv1中的slot, 它是一个动态资源划分单位, 是根据应用程序的需求动态生成的。 截至本' F+ Z+ ~; P3 Q" b0 r
书完成时, YARN仅支持CPU和内存两种资源, 且使用了轻量级资源隔离机制Cgroups进行 资源隔离 [19] 。
% S( K9 ]6 }2 G$ ^; P }) ]2.4.2 YARN通信协议
- {- l* F0 h! KRPC协议是连接各个组件的“大动脉”, 了解不同组件之间的RPC协议有助于我们更深入地学习YARN框架。 在YARN中, 任何8 F I4 {. W3 G7 k. Q- I
两个需相互通信的组件之间仅有一个RPC协议, 而对于任何一个RPC协议, 通信双方有一端是Client, 另一端为Server, 且Client总
% d5 W$ p5 O; o D J# b- Y是主动连接Server的, 因此, YARN实际上采用的是拉式( pull-based) 通信模型。 如图2-10所示, 箭头指向的组件是RPC Server,0 }' e4 ^$ M! c, X: j i) `
而箭头尾部的组件是RPC Client, YARN主要由以下几个RPC协 议组成 [20] :
; w; q6 b( @. a, _) S❑JobClient( 作业提交客户端) 与RM之间的协议—ApplicationClientProtocol: JobClient通过该RPC协议提交应用程序、 查询应% C9 Z' M6 h8 T9 O+ Z3 a
用程序状态等。
- ~ _7 @: n) y2 q; H# K2 R❑Admin( 管理员) 与RM之间的通信协议—ResourceManagerAdministrationProtocol: Admin通过该RPC协议更新系统配置文件,6 f' l" X5 C5 T6 m
比如节点黑白名单、 用户队列权限等。
* l. v( V, P/ H, h0 W❑AM与RM之间的协议—ApplicationMasterProtocol: AM通过该RPC协议向RM注册和撤销自己, 并为各个任务申请资源。
; ]4 g' l8 Q2 \6 B5 r❑AM与NM之间的协议—ContainerManagementProtocol: AM通过该RPC要求NM启动或者停止Container, 获取各个Container的
" H# d% D+ j4 t6 t; d使用状态等信息。
; P$ B+ b* f( j$ q+ d❑NM与RM之间的协议—ResourceTracker: NM通过该RPC协议向RM注册, 并定时发送心跳信息汇报当前节点的资源使用情% x; f2 Q% v' L6 T
况和Container运行情况。
% e/ E- h" x2 m! I7 S. z. _图2-10 Apache YARN的RPC协议
. g2 m) J2 {3 ?) u$ Y, _( s为了提高Hadoop的向后兼容性和不同版本之间的兼容性, YARN中的序列化框架采用了Google开源的Protocol Buffers。3 W0 a6 Q. n5 [1 G& M3 e; h6 d
Protocol Buffers的引入使得YARN具有协议向后兼容性, 相关内容将在第3章介绍。
' h" w% a" c/ y4 u3 R[18] 参见网址http://wiki.apache.org/hadoop/PoweredByYarn。
2 M, m3 \$ m8 N# r/ S[19] 参见网址https://issues.apache.org/jira/browse/YARN-3。
& u1 F1 @9 \6 P* w5 v[20] RPC协议名称在2.1.0-beta版本进行了重构, 之前的名称分别为: ClientRMProtocol、 RMAdminProtocol、 AMRMProtocol、
; b0 p. }& h, j: X( cContainerManager、 ResourceTracker( 该协议名称未变) . g' ]& f6 ]5 I$ P, z3 K
( F' z; `) m N, i5 K/ M/ a3 B6 N2 ]4 ]% D' a' e- `7 E. ^; ]
|
|