Yarn 的 RM 功能介绍

1 resourceManager 基本介绍

ResourceManager 负责集群中所有资源的统一管理和分配，它接收来自各个 NodeManager 的资源汇报信息，并把这些信息按照一定的策略分配给各个 ApplicationMaster。

1.1 RM 的职能

1. 与客户端交互，处理客户端的请求。

2. 启动和管理 AM，并在它运行失败时候重新启动它。

3. 管理 NM，接收来自于 NM 的资源汇报信息，并向 NM 下达管理指令。

4. 资源管理和调度，接收来自于 AM 的资源请求，并为它分配资源。

1.2 RM 的内部结构

用户交互模块:

1. clientRMService : 为普通用户服务，处理请求，如：提交应用程序、终止程序、获取程序状态

2. adminService : 给管理员提供的服务。普通用户交互模块是 ClientRMService，管理员交互模块是 AdminService，之所以要将两个模块分开，用不同的通信通道发送给 ResourceManager，是因为要避免普通用户的请求过多导致管理员请求被阻塞

3. WebApp : 更友好的展示集群资源和程序运行状态

NM 管理模块:

1. NMLivelinessMonitor : 监控 NM 是否活着，如果指定时间内未收到心跳，就从集群中移除。RM 会通过心跳告诉 AM 某个 NM 上的 Container 失效，如果 Am 判断需要重新执行，则 AM 重新向 RM 申请资源。

2. NodesListManager : 维护 inlude（正常）和 exlude（异常）的 NM 节点列表。默认情况下，两个列表都为空，可以由管理员添加节点。exlude 列表里的 NM 不允许与 RM 进行通信。

3. ResourceTrackerService : 处理来自 NM 的请求，包括注册和心跳。注册是 NM 启动时的操作，包括节点 ID 和可用资源上线等。心跳包括各个 Container 运行状态，运行 Application 列表、节点健康状态

AM 管理模块:

1. AMLivelinessMonitor : 监控 AM 是否还活着，如果指定时间内没有接受到心跳，则将正在运行的 Container 置为失败状态，而 AM 会被重新分配到另一个节点上

2. ApplicationMasterLauncher: 要求某一个 NM 启动 ApplicationMaster，它处理创建 AM 的请求和 kill AM 的请求

3. ApplicationMasterService : 处理来自 AM 的请求，包括注册、心跳、清理。注册是在 AM 启动时发送给 ApplicationMasterService 的；心跳是周期性的，包括请求资源的类型、待释放的 Container 列表；清理是程序结束后发送给 RM，以回收资源清理内存空间；

Application 管理模块:

1. ApplicationACLLsManager : 管理应用程序的访问权限，分为查看权限和修改权限。

2. RMAppManager : 管理应用程序的启动和关闭

3. ContainerAllocationExpirer : RM 分配 Container 给 AM 后，不允许 AM 长时间不对 Container 使用，因为会降低集群的利用率，如果超时（时间可以设置）还没有在 NM 上启动 Container，RM 就强制回收 Container。

状态机管理模块:

1. RMApp : RMApp 维护一个应用程序的的整个运行周期，一个应用程序可能有多个实例，RMApp 维护的是所有实例的

2. RMAppAttempt : RMAppAttempt 维护一个应用程序实例的一次尝试的整个生命周期

3. RMContainer : RMContainer 维护一个 Container 的整个运行周期（可能和任务的周期不一致）

4. RMNode : RMNode 维护一个 NodeManager 的生命周期，包括启动到运行结束的整个过程。

安全模块:

• RM 自带了全面的权限管理机制。主要由 ClientToAMSecretManager、ContainerTokenSecretManager、ApplicationTokenSecretManager 等模块组成。

资源分配模块：

• ResourceScheduler：ResourceScheduler 是资源调度器，他按照一定的约束条件将资源分配给各个应用程序。RM 自带了一个批处理资源调度器（FIFO）和两个多用户调度器 Fair Scheduler 和 Capacity Scheduler

1.3 启动 ApplicationMaster

1. 客户端提交一个任务给 RM，ClientRMService 负责处理客户端请求

2. ClentRMService 通知 RMAppManager。

3. RMAppManager 为应用程序创建一个 RMApp 对象来维护任务的状态。

4. RMApp 启动任务，创建 RMAppAttempt 对象。

5. RMAppAttempt 进行一些初始化工作，然后通知 ResourceScheduler 申请资源。

6. ResourceScheduler 为任务分配资源后，创建一个 RMContainer 维护 Container 状态

7. 并通知 RMAppAttempt，已经分配资源。

8. RMAppAttempt 通知 ApplicationMasterLauncher 在资源上启动 AM。

9. 在 NodeManager 的已分配资源上启动 AM

10. AM 启动后向 ApplicationMasterService 注册。

1.4 申请和分配 container

AM 向 RM 请求资源和 RM 为 AM 分配资源是两个阶段的循环过程：

• 阶段一：AM 请求资源请求并领取资源的过程，这个过程是 AM 发送请求、RM 记录请求。

• 阶段二：NM 向 RM 汇报各个 Container 运行状态，如果 RM 发现它上面有空闲的资源就分配给等待的 AM。

具体过程如下：

阶段一：

1. AM 通过 RPC 函数向 RM 发送资源需求信息，包括新的资源需求描述、待释放的 Container 列表、请求加入黑名单的节点列表、请求移除黑名单的节点列表等

2. RM 的 ApplicationMasterService 负责处理 AM 的请求。一旦收到请求，就通知 RMAppAttempt，更新应用程序执行进度，在 AMLivenessMonitor 中记录更新时间。

3. ApplicationMasterService 调用 ResourceScheduler，将 AM 的资源需求汇报给 ResourceScheduler。

4. ResouceScheduler 首先读取待释放的 Container 列表，通知 RMContainer 更改状态，杀死要释放的 Container，然后将新的资源需求记录，如果资源足够就记录已经分配好资源。

阶段二：

1. NM 通过 RPC 向 RM 汇报各自的各个 Container 的运行情况

2. RM 的 ResourceTrackerService 负责处理来自 NM 的汇报，收到汇报后，就通知 RMNode 更改 Container 状态，并通知 ResourceScheduler。

3. ResourceScheduler 收到通知后，如果有可分配的空闲资源，就将资源分配给等待资源的 AM，等待 AM 下次心跳将资源领取走。

1.5 杀死 application

杀死 Application 流程：

Kill Job 通常是客户端发起的，RM 的 ClientRMService 负责处理请求，接收到请求后，先检查权限，确保用户有权限 Kill Job，然后通知维护这个 Application 的 RMApp 对象，根据 Application 当前状态调用相应的函数来处理。

这个时候分为两种情况：Application 没有在运行、Application 正在运行。

1. Application 没有在运行

向已经运行过的 NodeManger 节点对应的状态维护对象 RMNode 发送通知，进行清理；向 RMAppManager 发送通知，将 Application 设置为已完成状态。

1. Application 正在运行

如果正在运行，也首先像情况一处理一遍，回收运行过的 NodeManager 资源，将 Application 设置为已完成。另外 RMApp 还要通知维护任务状态的 RMAppAttempt 对象，将已经申请和占用的资源回收，但是真正的回收是由资源调度器 ResourceScheduler 异步完成的。

异步完成的步骤是先由 ApplicationMasterLauncher 杀死 AM，并回收它占用的资源，再由各个已经启动的 RMContainer 杀死 Container 并回收资源。

1.6 Container 超时

YARN 里有两种 Container：运行 AM 的 Container 和运行普通任务的 Container。

1. RM 为要启动的 AM 分配 Container 后，会监控 Container 的状态，如果指定时间内 AM 还没有在 Container 上启动的话，Container 就会被回收，AM Container 超时会导致 Application 执行失败。

2. 普通 Container 超时会进行资源回收，但是 YARN 不会自动在其他资源上重试，而是通知 AM，由 AM 决定是否重试。

1.7 安全管理

Hadoop 的安全管理是为了更好地让多用户在共享 Hadoop 集群环境下安全高效地使用集群资源。系统安全机制由认证和授权两大部分构成，Hadoop2.0 中的认证机制采用 Kerberos 和 Token 两种方案，而授权则是通过引入访问控制表（Access Control List，ACL）实现的。

1. 术语

Kerberos 是一种基于第三方服务的认证协议，非常安全。特点是用户只需要输入一次身份验证信息就可以凭借此验证获得的票据访问多个服务。

Token 是一种基于共享密钥的双方身份认证机制。

Principal 是指集群中被认证或授权的主体，主要包括用户、Hadoop 服务、Container、Application、Localizer、Shuffle Data 等。

1. Hadoop 认证机制

Hadoop 同时采用了 Kerberos 和 Token 两种技术，服务和服务之间的认证采用了 Kerberos，用户和 NameNode 及用户和 ResourceManager 首次通讯也采用 Kerberos 认证，用户和服务之间一旦建立连接后，用户就可以从服务端获取一个 Token，之后就可以使用 Token 认证通讯了。因为 Token 认证要比 Kerberos 要高效。

Hadoop 里 Kerberos 认证默认是关闭的，可以通过参数 hadoop.security.authentication 设置为 kerberos，这个配置模式是 simple。

1. Hadoop 授权机制

Hadoop 授权是通过访问控制列表（ACL）实现的，Hadoop 的访问控制机制与 UNIX 的 POSIX 风格的访问控制机制是一致的，将权限授予对象分为：用户、同组用户、其他用户。默认情况下，Hadoop 公用 UNIX/Linux 下的用户和用户组。

• 队列访问控制列表

• 应用程序访问控制列表

• 服务访问控制列表