3.4 深入研究Resource Manager
YARN采用了Maser-Slave结构（即主-从结构），其中Master实现为Resource Manager（资源管理器），负责整个集群的资源管理与调度。Slave实现为Node Manager（节点管理器），负责单个节点的资源管理与任务启动。Resource Manager接收来自各个节点（Node Manager）的资源汇报信息（见图3-16），并把这些信息按照一定的策略分配给各个应用程序（实际上是Application Manager）。
图3-16 Resource Manager架构
Resource Manager是整个YARN集群中最重要的组件之一，它的设计直接决定了系统的可扩展性、可用性和容错性等特点，它主要由以下几个部分组成：
1．用户交互（最左边部分）
YARN分别针对普通用户，管理员和Web提供了三种对外服务，分别对应Client Service、 Admin Service和Web Server。Client Service是为普通用户提供的服务，它会处理来自客户端的各种请求，例如提交应用程序、终止应用程序，获取应用程序运行状态等。Admin Service为管理员提供了一套独立的服务接口，以防止大量的普通用户请求使管理员发送的管理命令“饿死”，管理员可通过这些接口管理集群，例如动态更新节点列表，更新ACL列表，更新队列信息等。Web Server是为了更加友好地展示集群资源使用情况和应用程序运行状态等信息而对外提供的一个Web界面。
2．Node Manager管理（最右边部分）
NMLivelinessMonitor监控Node Manager是否活着，如果一个Node Manager在一定时间（默认为10分钟）内未汇报心跳信息，则认为它“死掉”了，会将其从集群中移除。NodesListManager维护正常节点和异常节点列表，管理exclude（类似于黑名单）和include（类似于白名单）节点列表，这两个列表均是在配置文件中设置的，可以动态加载。ResourceTrackerService处理来自Node Manager的请求，主要包括两种请求：注册和心跳，其中，注册是Node Manager启动时发生的行为，请求包中包含节点ID，可用的资源上限等信息；而心跳是周期性行为，包含各个Container（容器）运行状态，运行的应用程序列表、节点健康状况，而ResourceTrackerService则为Node Manager返回待释放的Container列表、应用程序列表等。
3．Application Master管理（当中部分）
AMLivelinessMonitor监控Application Master是否活着，如果一个Application Master（应用程序主控器）在一定时间（默认为10分钟）内未汇报心跳信息，则认为它“死掉”了，它上面所有正在运行的Container将被认为死亡了，Application Master本身会被重新分配到另外一个节点上（用户可指定每个Application Master的尝试次数，默认是1次）执行。
ApplicationMasterLauncher与Node Manager通信，要求它为某个应用程序启动Application Master。ApplicationMasterService处理来自Application Master的请求，主要包括两种请求：注册和心跳，其中，注册是Application Master启动时发生的行为，请求包中包含所在节点，RPC端口号和tracking URL等信息，而心跳是周期性行为，包含请求资源的类型描述、待释放的Container列表等，而ApplicationMasterService则为之返回新分配的Container、失败的Container等信息。
4．应用程序管理（当中部分）
ApplicationACLsManager管理应用程序访问权限，包含两部分权限：查看和修改。查看权限主要指查看应用程序的基本信息，而修改权限则主要是修改应用程序优先级、杀死应用程序等。RMAppManager管理应用程序的启动和关闭。ClientRMService收到来自客户端的提交应用程序的请求后，将调用函数RMAppManager#submitAppication创建一个RMApp对象，它将维护整个应用程序生命周期，从开始运行到最终结束。
YARN不允许Application Master获得Container后长时间不对其使用，因为这会降低整个集群的利用率。当Application Master收到Resource Manager新分配的一个Container后，必须在一定的时间（默认为10分钟）内在对应的Node Manager上启动该Container，否则Resource Manager会回收该Container。而一个已经分配的Container是否被回收，则是由ContainerAllocationExpirer决定和执行的。
5．安全管理（当中部分）
Resource Manager自带了非常全面的权限管理机制，主要由NMTokens、ContainerTokens、DelegationToken等模块完成。
6．资源分配
在YARN中，资源调度器（ResourceScheduler）是一个非常核心的部件，它负责将各个节点上的资源（主要是内存和CPU资源）封装成Container，并按照一定的约束条件（按队列分配，每个队列有一定的资源分配上限等）分配给各个应用程序。ResourceScheduler是一个插拔式模块，YARN自带了一个批处理资源管理器——FIFO，和两个多用户调度器——Fair Scheduler和Capacity Scheduler。
YARN的资源管理器实际上是一个事件处理器，它需要处理来自外部的6种SchedulerEvent类型的事件，并根据事件的具体含义进行相应的处理。这6种事件含义如下：
（1）NODE_REMOVED
事件NODE_REMOVED表示集群中被移除一个计算节点（可能是节点故障或者管理员主动移除），资源调度器收到该事件时需要从可分配资源总量中移除相应的资源量。
（2）NODE_ADDED
事件NODE_ADDED表示集群中增加了一个计算节点，资源调度器收到该事件时需要将新增的资源量添加到可分配资源总量中。
（3）APPLICATION_ADDED
事件APPLICATION_ADDED表示Resource Manager收到一个新的应用程序。通常而言，Resource Manager需要为每个应用程序维护一个独立的数据结构，以便于统一管理和资源分配。
（4）APPLICATION_REMOVED
事件APPLICATION_REMOVED表示一个应用程序运行结束（可能成功或者失败），资源管理器需将该应用程序从相应的数据结构中清除。
（5）CONTAINER_EXPIRED
当资源调度器将一个Container分配给某个Application Master后，如果该Application Master在一定时间间隔内没有使用该Container，则资源调度器会对该Container进行再分配。
（6）NODE_UPDATE
Node Manager通过心跳机制向Resource Manager汇报各个Container的运行情况，会触发一个NODE_UDDATE事件，由于此时可能有新的Container被释放，因此该事件会触发资源分配，也就是说，该事件是6个事件中最重要的事件，它会触发资源调度器最核心的资源分配机制。
7．状态管理
Resource Manager维护一个节点生命周期，记录了节点可能存在的各个状态。例如，当一个应用程序执行完成时候，会触发一个CLEANUP_APP事件，以清理应用程序占用的资源。当一个Container执行完成时候，会触发一个CLEANUP_CONTAINER事件，以清理Container占用的资源。
Resource Manager维护了一个Container的运行周期，包括从创建到运行的整个过程。Resource Manager将资源封装成Container发送给应用程序的Application Master，而Application Master则会在Container描述的环境中启动任务，因此，从这个层面上讲，Container和任务的生命周期是一致的。目前YARN不支持Container的重用，一个Container用完后会立刻释放。
Application Master通过RPC函数ApplicationMasterProtocol#allocate拉取分配给它的Container后，将与对应的Node Manager通信以启动这些Container，接着Node Manager通过心跳机制将这些Container状态汇报给Resource Manager，最终Resource Manager将这些Container状态置为RUNNING。当出现以下几种情况时，将导致Container置为KILLED状态。
· 资源调度器为了保持公平性或者更高优先级的应用程序的服务质量，不得不杀死一些应用占用的Container以满足另外一些应用程序的请求。
· 某个Node Manager在一定时间内未向Resource Manager汇报心跳信息，则Resource Manager认为它死掉了，会将它上面所有正在运行的Container状态设置为KILLED。
· 用户（使用API或者Shell命令）强制杀死一个应用程序时，会导致它所用的Container状态设置为KILLED。