5.1 Resourcemanager 概述
image.png❑与客户端交互,处理来自客户端的请求;
❑启动和管理ApplicationMaster,并在它运行失败时重新启动它;
❑管理NodeManager,接收来自NodeManager的资源汇报信息,并向NodeManager下达管理指令(比如杀死Container等);
❑资源管理与调度,接收来自ApplicationMaster的资源申请请求,并为之分配资源。
5.2 Resourcemanager 内部架构
RM内部架构5.2 用户交互模块
5.2.1 ClientRMServiceClientRMService是一个RPC Server,为来自客户端的各种RPC请求提供服务。从实现角度看,它是一个实现了ApplicationClientProtocol协议的服务,其定义如下:
5.2.2 AdminService与ClientRMService类似,AdminService也是一个RPC Server,但它的服务对象是管理员。在YARN中,管理员列表由属性yarn.admin.acl指定(在yarn-site.xml中设置),默认情况下,属性值为“*”,表示所有用户都是管理员。从实现角度看,它是一个实现了ResourceManagerAdministrationProtocol协议的服务,其定义如下
5.3 ApplicationMaster管理
image.png- 步骤1 用户向YARN ResourceManager提交应用程序,ResourceManager收到提交请求后,先向资源调度器申请用以启动ApplicationMaster的资源,待申请到资源后,再由ApplicationMasterLauncher与对应的NodeManager通信,从而启动应用程序的ApplicationMaster。
- 步骤2 ApplicationMaster启动完成后,ApplicationMasterLauncher会通过事件的形式,将刚刚启动的ApplicationMaster注册到AMLivelinessMonitor,以启动心跳监控。
- 步骤3 ApplicationMaster启动后,先向ApplicationMasterService注册,并将自己所在host、端口号等信息汇报给它。
- 步骤4 ApplicationMaster运行过程中,周期性地向ApplicationMasterService汇报“心跳”信息(“心跳”信息中包含想要申请的资源描述)。
- 步骤5 ApplicationMasterService每次收到ApplicationMaster的心跳信息后,将通知AMLivelinessMonitor更新该应用程序的最近汇报心跳的时间。
- 步骤6 当应用程序运行完成后,ApplicationMaster向ApplicationMasterService发送请求,注销自己。
- 步骤7 ApplicationMasterService收到注销请求后,标注应用程序运行状态为完成,同时通知AMLivelinessMonitor移除对它的心跳监控。
AM运行过程中,需要周期性地通过RPC函数ApplicationMasterProtocol#allocate与RM通信主要有以下三个作用:
❑请求资源;
❑获取新分配的资源;
❑形成周期性心跳,告诉RM自己还活着。
5.4 NodeManager管理
(1)NMLivelinessMonitor该服务周期性遍历集群中所有NodeManager,如果一个NodeManager在一定时间(可通过参数yarn.nm.liveness-monitor.expiry-interval-ms配置,默认为10min)内未汇报心跳信息,则认为它死掉了,它上面所有正在运行的Container将被置为运行失败
(2)NodesListManagerNodesListManager管理exlude(类似于黑名单)和inlude(类似于白名单)节点列表
(3)ResourceTrackerServiceResourceTrackerService实现了RPC协议ResourceTracker,负责处理来自各个NodeManager的请求,请求主要包括注册和心跳两种,
5.5 Application管理
(1)ApplicationACLsManagerApplicationACLsManager负责管理应用程序的访问权限,包含两部分权限:查看权限和修改权
(2)RMAppManagerRMAppManager负责应用程序的启动和关闭
(3)ContainerAllocationExpirer当一个AM获得一个Container后,YARN不允许AM长时间不对其使用
5.6 状态机管理
在YARN ResourceManager内部,共有4类状态机,分别是RMApp、RMAppAttempt、RMContainer和RMNode。其中,前2类状态机维护了一个应用程序相关的生命周期,包括Application生命周期、一次运行尝试的生命周期;RMContainer则维护了分配出去的各个资源的使用状态;RMNode维护了一个NodeManager(一个节点上可以有多个NodeManager)的生命周期
image.png
Application Attempt的生命周期与ApplicationMaster的生命周期基本上是一致的:一个Application内部所有任务均由ApplicationMaster维护和管理,ApplicationMaster本身需要占用一个Container,而这个Container由ResourceManager为其申请和启动。一旦ApplicationMaster成功启动,它就会与ResourceManager通信,为它内部的任务申请Container。如果ApplicationMaster重新启动,则意味着一个新的Application Attempt被启动,换句话说,一个Application Attempt的“生死存亡”与ApplicationMaster的“命运”紧紧绑定在一起。
5.6.1 RMApp状态机
RMApp是ResourceManager中用于维护一个Application生命周期的数据结构,它的实现是RMAppImpl类,该类维护了一个Application状态机,记录了一个Application可能存在的各个状态(RMAppState)以及导致状态间转换的事件(RMAppEvent)
image.pngimage.png
5.6.2 RMAppAttempt状态机
image.pngimage.png
5.6.3 RMContainer状态机
image.pngimage.png
5.6.4 RMNode状态机
RMNode是ResourceManager中用于维护一个节点生命周期的数据结构,它的实现是RMNodeImpl类,该类维护了一个节点状态机,记录了节点可能存在的各个状态以及导致状态间转换的事件。当某个事件发生时,RMNodeImpl会根据实际情况进行节点状态转移,同时触发一个行为
image.png
image.png
网友评论