|
|
2.4 YARN 基本架构7 F8 a- _$ V5 v6 q7 ^6 M
YARN是Hadoop 2.0中的资源管理系统， 它的基本设计思想是将MRv1中的JobTracker拆分成了两个独立的服务： 一个全局的
( F1 u4 C+ i' Y1 j$ Z. B1 v资源管理器ResourceManager和每个应用程序特有的ApplicationMaster。 其中ResourceManager负责整个系统的资源管理和分配， 而1 [0 Q; \7 }! u/ K
ApplicationMaster负责单个应用程序的管理。7 c) V, r. G/ @( p+ n# [
2.4.1 YARN基本组成结构
- b( J( S: N3 M! }( QYARN总体上仍然是Master/Slave结构， 在整个资源管理框架中， ResourceManager为Master， NodeManager为+ F) K# S: a6 ?
Slave， ResourceManager负责对各个NodeManager上的资源进行统一管理和调度。 当用户提交一个应用程序时， 需要提供一个用以0 X- C8 Y- H' j) K5 {
跟踪和管理这个程序的ApplicationMaster， 它负责向ResourceManager申请资源， 并要求NodeManger启动可以占用一定资源的任1 `% p% f8 ~' N: E! z& i, s
务。 由于不同的ApplicationMaster被分布到不同的节点上， 因此它们之间不会相互影响。 在本小节中， 我们将对YARN的基本组成2 W" [1 Z" ~8 E2 p H: I
结构进行介绍。
7 D( K$ D, ?+ O; f8 V5 h+ {图2-9描述了YARN的基本组成结构， YARN主要由ResourceManager、 NodeManager、 ApplicationMaster（ 图中给出了
1 U' q! I2 w8 e7 K- M6 v& [MapReduce和MPI两种计算框架的ApplicationMaster， 分别为MR AppMstr和MPI AppMstr） 和Container等几个组件构成。8 A9 O& A0 }/ n' T9 d
图2-9 Apache YARN的基本架构1 \; Y6 k6 I) Q+ {" K1 u" S1 ~
1.ResourceManager（ RM）
9 H4 u4 R! Y( ]& [; [% r: FRM是一个全局的资源管理器， 负责整个系统的资源管理和分配。 它主要由两个组件构成： 调度器（ Scheduler） 和应用程序
5 L9 s+ M) l$ f4 e8 P* q2 v管理器（ Applications Manager， ASM） 。+ _5 l7 s! `1 [$ d) C
（ 1） 调度器) }3 I+ b& {; p7 L
调度器根据容量、 队列等限制条件（ 如每个队列分配一定的资源， 最多执行一定数量的作业等） ， 将系统中的资源分配给各) u H- Q! \9 b4 b/ L5 Y
个正在运行的应用程序。 需要注意的是， 该调度器是一个“纯调度器”， 它不再从事任何与具体应用程序相关的工作， 比如不负责
5 T& W, D& t& A9 E监控或者跟踪应用的执行状态等， 也不负责重新启动因应用执行失败或者硬件故障而产生的失败任务， 这些均交由应用程序相关) v% V9 K; h- v0 A T- b# @9 j
的ApplicationMaster完成。 调度器仅根据各个应用程序的资源需求进行资源分配， 而资源分配单位用一个抽象概念“资源容
# }/ P: x7 F; S4 E' y7 I* F2 I器”（ Resource Container， 简称Container） 表示， Container是一个动态资源分配单位， 它将内存、 CPU、 磁盘、 网络等资源封装在8 _3 f% x/ t; L' z" E3 g: v
一起， 从而限定每个任务使用的资源量。 此外， 该调度器是一个可插拔的组件， 用户可根据自己的需要设计新的调度器， YARN* \6 `: \0 `) _( J% f2 s2 D' P
提供了多种直接可用的调度器， 比如Fair Scheduler和Capacity Scheduler等。
" q& _% E( ~3 O$ T& ?+ j a（ 2） 应用程序管理器, O( m- G* L: E, G2 B0 ?* o
应用程序管理器负责管理整个系统中所有应用程序， 包括应用程序提交、 与调度器协商资源以启动ApplicationMaster、 监控( T" s; s- h w# F; v
ApplicationMaster运行状态并在失败时重新启动它等。
. h a% U. z% {( L2.ApplicationMaster（ AM）
8 }/ t; v- `" A* k* N. T8 |用户提交的每个应用程序均包含一个AM， 主要功能包括：
4 w* M+ |( G% o( B2 q❑与RM调度器协商以获取资源（ 用Container表示） ； ^" H# ]# c' G' l, \
❑将得到的任务进一步分配给内部的任务；; i* w* U8 `2 L7 R
❑与NM通信以启动/停止任务；! D0 P% n& Y6 o+ e+ {! w
❑监控所有任务运行状态， 并在任务运行失败时重新为任务申请资源以重启任务。 v9 i/ l& ?& r9 V
当前YARN自带了两个AM实现， 一个是用于演示AM编写方法的实例程序distributedshell， 它可以申请一定数目的Container以
, B5 ^0 w ^. n9 U/ ]. B7 h3 I并行运行一个Shell命令或者Shell脚本； 另一个是运行MapReduce应用程序的AM—MRAppMaster， 我们将在第8章对其进行介绍。
: H* c: j, P! C( i* c0 r/ [此外， 一些其他的计算框架对应的AM正在开发中， 比 如Open MPI、 Spark等 [18] 。
, `0 S& H# |/ }# D3.NodeManager（ NM）
0 T% N& o' M' H2 l; Z1 ^NM是每个节点上的资源和任务管理器， 一方面， 它会定时地向RM汇报本节点上的资源使用情况和各个Container的运行状
& X9 I& \8 B6 ~2 G3 y' }! [态； 另一方面， 它接收并处理来自AM的Container启动/停止等各种请求。' c* Y: p' R3 _# M4 r2 a
4.Container
/ d# o/ z f8 A0 rContainer是YARN中的资源抽象， 它封装了某个节点上的多维度资源， 如内存、 CPU、 磁盘、 网络等， 当AM向RM申请资源
& m6 P( x2 B! W @; V( C时， RM为AM返回的资源便是用Container表示的。 YARN会为每个任务分配一个Container， 且该任务只能使用该Container中描述的
. |4 e6 p/ X1 C; K) }资源。 需要注意的是， Container不同于MRv1中的slot， 它是一个动态资源划分单位， 是根据应用程序的需求动态生成的。 截至本
* G h x- {: C- b7 m1 G0 F9 o% @书完成时， YARN仅支持CPU和内存两种资源， 且使用了轻量级资源隔离机制Cgroups进行 资源隔离 [19] 。, J9 L8 l6 r: E7 C/ W" y
2.4.2 YARN通信协议' w4 a" o8 G c- S7 l9 { v
RPC协议是连接各个组件的“大动脉”， 了解不同组件之间的RPC协议有助于我们更深入地学习YARN框架。 在YARN中， 任何* N" U. y: A0 o( i/ o _0 ?* q
两个需相互通信的组件之间仅有一个RPC协议， 而对于任何一个RPC协议， 通信双方有一端是Client， 另一端为Server， 且Client总
7 q% S2 l6 ^& ~+ [" T是主动连接Server的， 因此， YARN实际上采用的是拉式（ pull-based） 通信模型。 如图2-10所示， 箭头指向的组件是RPC Server，2 K+ F, W4 c& v. V p4 a# W
而箭头尾部的组件是RPC Client， YARN主要由以下几个RPC协 议组成 [20] ：. W& h8 `% V4 J- R4 G: X; F
❑JobClient（ 作业提交客户端） 与RM之间的协议—ApplicationClientProtocol： JobClient通过该RPC协议提交应用程序、 查询应; {0 c! O5 e) t0 D" i. O8 S$ q
用程序状态等。
; t6 g" F4 m e/ c% c! u❑Admin（ 管理员） 与RM之间的通信协议—ResourceManagerAdministrationProtocol： Admin通过该RPC协议更新系统配置文件，
- v5 h, \9 F& ^% @9 A4 v& E( h比如节点黑白名单、 用户队列权限等。
/ N& u5 Z9 y0 i7 l; i: C% U& u' P❑AM与RM之间的协议—ApplicationMasterProtocol： AM通过该RPC协议向RM注册和撤销自己， 并为各个任务申请资源。
1 c( k T( ~8 M& N0 K❑AM与NM之间的协议—ContainerManagementProtocol： AM通过该RPC要求NM启动或者停止Container， 获取各个Container的
! _1 ]5 u% I3 w- V) A0 q( I使用状态等信息。
( L2 \ w7 H2 \9 b❑NM与RM之间的协议—ResourceTracker： NM通过该RPC协议向RM注册， 并定时发送心跳信息汇报当前节点的资源使用情- F" M# q8 i8 m
况和Container运行情况。
# L9 q9 e- Y: k% e图2-10 Apache YARN的RPC协议
6 G" d6 O. @ `7 a p: z为了提高Hadoop的向后兼容性和不同版本之间的兼容性， YARN中的序列化框架采用了Google开源的Protocol Buffers。) R! Y1 S, {2 W" }" ^) H
Protocol Buffers的引入使得YARN具有协议向后兼容性， 相关内容将在第3章介绍。
8 g. J+ [9 l; M! p: q[18] 参见网址http://wiki.apache.org/hadoop/PoweredByYarn。
# B* ` `4 N, K H# V' g- r[19] 参见网址https://issues.apache.org/jira/browse/YARN-3。4 w! p9 m) b6 s9 `; J
[20] RPC协议名称在2.1.0-beta版本进行了重构， 之前的名称分别为： ClientRMProtocol、 RMAdminProtocol、 AMRMProtocol、3 w& \6 T! ?+ r; E
ContainerManager、 ResourceTracker（ 该协议名称未变）
; }1 |: j$ J) V+ u0 W8 v% y
4 U3 ?" v$ l0 v' @" O5 o
& `) M6 d3 |/ d% s |
|
发表于 2017-4-13 21:23:55
