ResourceManager架构解析

RM作为master管理着所有的集群资源，它会和NM和特定application的AM共同工作

1. NodeManagers

NM从RM中获得指令，并管理着单节点上可用资源

2. ApplicationMasters

负责和RM协调，然后通知NM来启动资源容器

RM有如下部件：

1. RM和客户端交互的部件

ClientRMService

RM的client接口，处理client端的RPC请求，比如提交application，强制杀死application，获得Queue信息，集群metrics

AdminService

单独的管理员客户端接口，比如refreshNodes，refreshUserToGroupsMappings等.

2. RM和NM交互的部件

ResourceTrackerService

负责响应NM过来的RPC请求，比如注册NM，拒绝不合法或者decommissioned节点请求，获得NM心跳信息并传递给事件处理器YarnScheduler。每次heartbeat会调用nodesListManager和 nmLivelinessMonitor组件

NMLivelinessMonitor

跟踪活跃的节点，并且记录挂掉的节点。该部件会记录每个节点最后一次心跳时间，任何节点如果在一定时间内没有心跳信息（默认是10分钟）会被认为已经挂了并被标记为expired node，新的container不会被分配到expired node.

NodesListManager

维护了include和exclude的NM列表信息，初始化时会读入yarn.resourcemanager.nodes.include-path和yarn.resourcemanager. nodes.exclude-path指定的两个文件。集群启动后也可以通过AdminService来动态refresh nodes

3. RM和AM交互的部件

ApplicationMasterService

AM向RM请求RPC的服务 ，AM可以注册或者注销，从RM中获得资源容器

AMLivelinessMonitor

这个部件在ApplicationMasterService中，AM在注册/注销和申请资源的时候都会调用(receivedPing方法 )，它负责记录每个AM最后一次心跳时间 ，若在规定间隔内NM未反馈心跳（默认10分钟），则NM被认为已经挂了，并被AM移除。所有这个AM上已经分配和正在执行的资源容器都会被标记为dead，RM Scheduler会重新调度AM到一个新的容器中，默认最多会尝试4次

RM的核心部件 - 调度器和相关部件

RMAppManager

负责维护提交的applications，信息存放到RMContext中， 同时会cache已经完成的application，用户可以通过WebUI或者命令行来查看

ApplicationACLsManager

维护每个应用的ACL列表，在杀死应用，查看应用信息的时候会检查ACL authorization

ApplicationMasterLauncher

内部有一个线程池来启动AM （新提交的或者之前由于某种原因失败了的），
如果application正常停止或者强制kill掉后会负责清理AM

YarnScheduler

Scheduler负责分配资源，它是基于application资源需求的分配策略，比如CPU，内存，网络，磁盘等

ContainerAllocationExpirer

负责保证所有分配给AM的容器都会被相应的NM启动起来了。由于AM有可能在得到资源后不启动，这会造成集群利用率的降低，所以ContainerAllocationExpirer会保持已经分配但是还未被NM启动的container列表。对于任何一个container，如果在一定的时间内（默认10分钟） NM未汇报给RM它已经被启动了，则该container会被认为已经过期了

 

参考：

http://hortonworks.com/blog/apache-hadoop-yarn-resourcemanager/

本文链接http://blog.csdn.net/lalaguozhe/article/details/10190653，转载请注明