【深入浅出 Yarn 架构与实现】6-1 NodeManager 功能概述

本节开始将对 Yarn 中的 NodeManager 服务进行剖析。
NodeManager 需要在每个计算节点上运行，与 ResourceManager 和 ApplicationMaster 进行交互。管理节点的计算资源以及调度容器。后续将对 NM 的功能职责、状态机、容器生命周期和资源隔离等方面进行讲解。本篇将从整体上对 NM 进行介绍。

一、NodeManager 基本职能

在 Hadoop 集群中，每个计算节点都需要有一个管理服务，其就是 NodeManager（NM）。
它负责与 ResourceManager 保持通信，管理 Container 的生命周期，监控每个 Container 的资源使用情况，追踪节点健康状况，管理日志等。
主要职责：

1. 保持与 ResourceManager 同步
2. 跟踪节点的健康状况
3. 管理节点各个 Container 的生命周期，监控每个 Container 的资源使用情况
4. 管理分布式缓存（对 Container 所需的 Jar，库文件的本地文件系统缓存）
5. 管理各个 Container 生成日志

整体来说，NM 通过两个 RPC 协议与 RM 和 AM 交互，如下图所示。

一）与 RM 交互

通过 ResourceTrackerProtocol 协议：

• NM 通过该 RPC 协议向 RM 注册、汇报节点健康状况和 Container 运行状态；
• 领取 RM 下达的命令，包括重新初始化、清理 Container 占用资源等。

在该协议中，RM 扮演 RPC server 的角色，而 NM 扮演 RPC Client 的角色（由内部组件 NodeStatusUpdater 实现）。NM 与 RM 之间采用 「pull 模型」，NM 总是周期性地主动向 RM 发起请求，并领取下达给自己的命令。

二）与 AM 交互

通过 ContainerManagementProtocol 协议：

• 应用程序的 AM 通过该 RPC 协议向 NM 发起 Container 的相关操作（启动、kill、获取 Container 执行状态等）。

在该协议中，AM 扮演 RPC Client 的角色，而 NM 扮演 RPC Server 的角色（由内部组件 ContainerManager 实现）。NM 与 AM 之间采用「push 模型」，AM 可以将 Container 相关操作的第一时间告诉 NM，相比于「pull 模型」，可以大大降低时间延迟。

二、NodeManager 内部结构

NodeManager 内部由多个组件构成，如下图所示。其中最主要的三个组件是：NodeStatusUpdater、ContainerManager、NodeHealthCheckService。

一）NodeStatusUpdater

NodeStatusUpdater 是 NM 与 RM 通信的唯一通道。

• 当 NM 启动时，该组件负责向 RM 注册，并汇报节点上总的可用资源；
• 之后，该组件周期性与 RM 通信，汇报各个 Container 的状态更新（包括节点上正在运行的 Container、已经完成的 Container 等信息）；
• 同时 RM 会返回待清理的 Container 列表、待清理的应用程序列表、诊断信息、各种 Token 等信息。

二）ContainerManager

ContainerManager 是 NM 中最核心的组件之一，它由多个子组件组成，每个子组件负责一部分功能，协同管理运行在该节点上的所有 Container，各个子组件如下。

• **RPC Server：**该 RPC Server 实现了 ContainerManagementProtocol 协议，是 AM 与 NM 通信的唯一通道。ContainerManager 从各个 AM 上接收 RPC 请求以启动新的 Container 或者 停止正在运行的 Container。需要注意的是，任何 Container 操作均会经 ContainerTokenSecretManager 合法性验证，以防止伪造启动或停止 Container 的命令。
• **ResourceLocalizationService：**负责 Container 所需资源的本地化，它能够按照描述从 HDFS 上下载 Container 所需的文件资源，并尽量将它们分摊到各个磁盘上以防止出现热点访问。此外，它会为下载的文件添加访问控制限制，并为之施加合适的磁盘空间使用份额。
• **ContianersLauncher：**维护了一个线程池以并行完成 Container 相关操作，比如启动或者杀死 Container，其中启动 Container 请求是由 AM 发起的，而杀死 Container 请求则可能来自 AM 或者 RM。
• **AuxService：**NodeManager 允许用户通过配置附属服务的方式扩展自己的功能，这使得每个节点可以定制一些特定框架的服务。附属服务需要在 NodeManager 启动之前配置好，并由 NodeManager 统一启动与关闭。
• **ContainersMonitor：**ContainersMonitor 负责监控 Container 的资源使用量，为了实现资源隔离和公平共享，RM 为每个 Container 分配了一定量的资源。而 ContainersMonitor 周期性探测它在运行过程中的资源利用量，一旦发生 Container 超出了它的允许使用份额上线，就向 Container 发送信号将其杀掉，这可以避免资源密集型的 Container 影响同节点上其他正在运行的 Container。
• **LogHandler：**一个可插拔组件，用户可通过它控制 Container 日志的保存方式，即是写到本地磁盘上还是将其打包后上传到一个文件系统中。
• **ContainerEventDispatcher：**Container 事件调度器，负责将 ContainerEvent 类型的事件调度给对应 Container 的状态机 ContainerImpl。
• **ApplicationEventDispatcher：**Application 事件调度器，负责将 ApplicationEvent 类型的事件调度给对应 Application 的状态机 ApplicationImpl。

三）NodeHealthCheckerService

NodeHealthCheckerService 通过周期性地运行一个自定义脚本（由组件 NodeHealthScriptRunner 完成）和向磁盘写文件（由服务 LocalDirsHandlerService 完成）检查节点的健康状况。
并通过 NodeStatusUpdater 传递给 ResourceManager。一旦 ResourceManager 发现一个节点处于不健康状态，则会将它加入黑名单，此后不再使用该资源，直到再次转为健康状态。需要注意的是，节点被加入黑名单时，正在运行的 Container 仍会正常运行，不会被杀死。

四）DeletionService

NodeManager 使用一个专门的服务用于文件删除。异步地删除失效文件，这样可避免删除文件带来的性能开销。

五）Security

安全部分。它包含两部分，分别是 ApplicationACLsManager 和 ContainerTokenSecretManager，ApplicationACLsManager 确保访问 NodeManager 的用户是合法的，ContainerTokenSecretManager 确保用户请求的资源被 ResourceManager 授权过。

• **ApplicationACLsManager：**NodeManager 需要为所有面向用户的 API 提供安全检查，如在 Web UI 上只能将 Container 日志显示给授权用户。该组件为每个应用程序维护了一个 ACL 列表，一旦收到类似请求后会利用该列表对其进行验证。
• **ContainerTokenSecretManager：**检查收到的各种访问请求的合法性，确保这些请求操作已被 ResourceManager 授权。

六）WebServer

通过 Web 界面向用户展示该节点上所有应用程序运行状态、Container 列表、节点健康状况和 Container 产生的日志等信息。

七）ContainerExecutor

与底层操作系统交互，安全的放置 Container 所需要的文件和目录，随后以一个安全的方式启动和清理Container相关进程。

三、NodeManager 的事件与事件处理器

NodeManager主要组件也是通过事件进行交互的，这使得组件能够异步并发完成各种功能。如下图所示：

四、总结

本节对 NodeManager 整体结构进行了介绍。从它的基本职能、内部结构、事件处理三个方面进行讲解，对 NM 整体结构有了认知。
实际上 NM 主要就负责两个事情：1）与 RM 交互，注册以及汇报状态，领取 RM 指令处理 container。2）与 AM 交互，处理其管理的 container 操作。