|
2.4 YARN 基本架构
; J0 X, y7 _! B+ b/ y: A8 k1 OYARN是Hadoop 2.0中的资源管理系统, 它的基本设计思想是将MRv1中的JobTracker拆分成了两个独立的服务: 一个全局的
0 Y/ C7 O2 [" O1 }: g3 v b资源管理器ResourceManager和每个应用程序特有的ApplicationMaster。 其中ResourceManager负责整个系统的资源管理和分配, 而- m; |8 S k1 K4 x! u" |, b
ApplicationMaster负责单个应用程序的管理。! W) ?9 M4 Y; X* G/ c
2.4.1 YARN基本组成结构0 \7 k" f0 a4 c( i! o4 k
YARN总体上仍然是Master/Slave结构, 在整个资源管理框架中, ResourceManager为Master, NodeManager为' |$ t; K9 K3 N- [7 v
Slave, ResourceManager负责对各个NodeManager上的资源进行统一管理和调度。 当用户提交一个应用程序时, 需要提供一个用以1 e# P" U3 y" y" @+ v$ _0 S
跟踪和管理这个程序的ApplicationMaster, 它负责向ResourceManager申请资源, 并要求NodeManger启动可以占用一定资源的任5 N3 |( {4 G3 S5 |: {9 m1 n; I0 H0 \. o
务。 由于不同的ApplicationMaster被分布到不同的节点上, 因此它们之间不会相互影响。 在本小节中, 我们将对YARN的基本组成+ B5 P. t; P5 |
结构进行介绍。
2 m4 ?6 S( K) g6 `" K图2-9描述了YARN的基本组成结构, YARN主要由ResourceManager、 NodeManager、 ApplicationMaster( 图中给出了0 t) `* Q- A! c" |9 b/ n3 E
MapReduce和MPI两种计算框架的ApplicationMaster, 分别为MR AppMstr和MPI AppMstr) 和Container等几个组件构成。/ M G! I7 Q) F% u3 u
图2-9 Apache YARN的基本架构
# }4 B& k% m$ E, _9 |1.ResourceManager( RM)4 K+ M+ a. T) U3 B& Y2 |
RM是一个全局的资源管理器, 负责整个系统的资源管理和分配。 它主要由两个组件构成: 调度器( Scheduler) 和应用程序
# C+ A8 A$ r) W1 C管理器( Applications Manager, ASM) 。
& i h1 P1 B( S! T; O/ o9 v1 R' e6 z( 1) 调度器
5 [/ Q4 Q) V: E4 D调度器根据容量、 队列等限制条件( 如每个队列分配一定的资源, 最多执行一定数量的作业等) , 将系统中的资源分配给各! c% Q/ x0 K. G+ q4 U
个正在运行的应用程序。 需要注意的是, 该调度器是一个“纯调度器”, 它不再从事任何与具体应用程序相关的工作, 比如不负责- I% c# e2 {& ~) ~5 ~
监控或者跟踪应用的执行状态等, 也不负责重新启动因应用执行失败或者硬件故障而产生的失败任务, 这些均交由应用程序相关, G2 R7 ~; f% S# R+ X; |
的ApplicationMaster完成。 调度器仅根据各个应用程序的资源需求进行资源分配, 而资源分配单位用一个抽象概念“资源容
0 z6 y1 T2 L4 Z+ p器”( Resource Container, 简称Container) 表示, Container是一个动态资源分配单位, 它将内存、 CPU、 磁盘、 网络等资源封装在! {0 _: D/ m! R4 V
一起, 从而限定每个任务使用的资源量。 此外, 该调度器是一个可插拔的组件, 用户可根据自己的需要设计新的调度器, YARN
R: }1 }# ]( v% `提供了多种直接可用的调度器, 比如Fair Scheduler和Capacity Scheduler等。* k) P0 |9 ]/ I
( 2) 应用程序管理器% T b/ k( |2 ?1 E
应用程序管理器负责管理整个系统中所有应用程序, 包括应用程序提交、 与调度器协商资源以启动ApplicationMaster、 监控$ F& k5 L0 q; P, ~
ApplicationMaster运行状态并在失败时重新启动它等。8 K4 w6 r) X3 ]4 J) r+ N2 O1 s
2.ApplicationMaster( AM)
" ^5 O4 Z3 D* u6 F用户提交的每个应用程序均包含一个AM, 主要功能包括:# u& J# W, g- v& _0 S$ i
❑与RM调度器协商以获取资源( 用Container表示) ;
9 b0 k+ |% q* |$ D❑将得到的任务进一步分配给内部的任务;( P# Q! q, v8 U6 [6 q% ^+ T
❑与NM通信以启动/停止任务;2 x3 v( A& l q6 V0 c* v( h7 ~9 ]0 w
❑监控所有任务运行状态, 并在任务运行失败时重新为任务申请资源以重启任务。
' x; a$ ], J! d" w5 {当前YARN自带了两个AM实现, 一个是用于演示AM编写方法的实例程序distributedshell, 它可以申请一定数目的Container以% J: ^4 K2 O5 c
并行运行一个Shell命令或者Shell脚本; 另一个是运行MapReduce应用程序的AM—MRAppMaster, 我们将在第8章对其进行介绍。
1 |0 r* z: S) B此外, 一些其他的计算框架对应的AM正在开发中, 比 如Open MPI、 Spark等 [18] 。
; u7 t( E) p; ~6 s) k0 }# h3.NodeManager( NM)
' c* e8 |, E% ?: l H/ pNM是每个节点上的资源和任务管理器, 一方面, 它会定时地向RM汇报本节点上的资源使用情况和各个Container的运行状
% A9 j. ?6 x5 Q/ T8 k0 |; X态; 另一方面, 它接收并处理来自AM的Container启动/停止等各种请求。
; ~6 c! [5 G* W6 @4.Container
* h+ K/ a/ \. ^) r6 v9 `8 W' ?Container是YARN中的资源抽象, 它封装了某个节点上的多维度资源, 如内存、 CPU、 磁盘、 网络等, 当AM向RM申请资源
* _/ @+ f% n# x- f, k% {% P- L时, RM为AM返回的资源便是用Container表示的。 YARN会为每个任务分配一个Container, 且该任务只能使用该Container中描述的
9 b1 w4 d& {" \' d资源。 需要注意的是, Container不同于MRv1中的slot, 它是一个动态资源划分单位, 是根据应用程序的需求动态生成的。 截至本
, T L8 }9 j' e. N书完成时, YARN仅支持CPU和内存两种资源, 且使用了轻量级资源隔离机制Cgroups进行 资源隔离 [19] 。
3 i; `" {% g( t1 D2.4.2 YARN通信协议
* u2 }) _5 y# i5 f# r# ~RPC协议是连接各个组件的“大动脉”, 了解不同组件之间的RPC协议有助于我们更深入地学习YARN框架。 在YARN中, 任何% p6 n, k6 j* A- J/ A) t4 U. t, \
两个需相互通信的组件之间仅有一个RPC协议, 而对于任何一个RPC协议, 通信双方有一端是Client, 另一端为Server, 且Client总
: ^% J+ C5 ~9 n+ j3 j是主动连接Server的, 因此, YARN实际上采用的是拉式( pull-based) 通信模型。 如图2-10所示, 箭头指向的组件是RPC Server,8 X- p1 E, v/ C
而箭头尾部的组件是RPC Client, YARN主要由以下几个RPC协 议组成 [20] :
; f8 e8 N. ]0 M" Q. b' ^❑JobClient( 作业提交客户端) 与RM之间的协议—ApplicationClientProtocol: JobClient通过该RPC协议提交应用程序、 查询应
/ F1 t. |- w/ j$ O用程序状态等。
4 \3 ?+ C5 e/ X" q& r4 K& D# i❑Admin( 管理员) 与RM之间的通信协议—ResourceManagerAdministrationProtocol: Admin通过该RPC协议更新系统配置文件,5 P8 ]! j% o3 m. l6 t4 N( {' T
比如节点黑白名单、 用户队列权限等。- d* d3 @# X' |1 m5 B
❑AM与RM之间的协议—ApplicationMasterProtocol: AM通过该RPC协议向RM注册和撤销自己, 并为各个任务申请资源。
! i" I% A/ r- Z8 l/ ?3 e❑AM与NM之间的协议—ContainerManagementProtocol: AM通过该RPC要求NM启动或者停止Container, 获取各个Container的
4 s m+ G) R* o, f4 ?使用状态等信息。
" N/ Y+ t. {: K) O9 v& ~, X! @4 K7 a❑NM与RM之间的协议—ResourceTracker: NM通过该RPC协议向RM注册, 并定时发送心跳信息汇报当前节点的资源使用情2 S8 p) S: P- \7 c1 @6 v
况和Container运行情况。
% z9 W6 ~9 i& v+ B% E图2-10 Apache YARN的RPC协议
/ g/ ?6 d6 J3 o为了提高Hadoop的向后兼容性和不同版本之间的兼容性, YARN中的序列化框架采用了Google开源的Protocol Buffers。
9 W9 |0 W7 @ eProtocol Buffers的引入使得YARN具有协议向后兼容性, 相关内容将在第3章介绍。* J' U! R/ m/ ]
[18] 参见网址http://wiki.apache.org/hadoop/PoweredByYarn。
/ [& j1 e) u# y9 k[19] 参见网址https://issues.apache.org/jira/browse/YARN-3。% r |. n& p3 d! _. A5 o
[20] RPC协议名称在2.1.0-beta版本进行了重构, 之前的名称分别为: ClientRMProtocol、 RMAdminProtocol、 AMRMProtocol、 H0 q8 Z4 {( ^' }
ContainerManager、 ResourceTracker( 该协议名称未变)
' c- Y% C% ~/ N7 M% m5 t
0 f% o7 t. A: v- H9 v8 A- d
$ z: J4 N- Q7 C& p |
|