【深入浅出 Yarn 架构与实现】6-1 NodeManager 功能概述
本节开始将对 Yarn 中的 NodeManager 服务进行剖析。
NodeManager 需要在每个计算节点上运行，与 ResourceManager 和 ApplicationMaster 进行交互。管理节点的计算资源以及调度容器。后续将对 NM 的功能职责、状态机、容器生命周期和资源隔离等方面进行讲解。本篇将从整体上对 NM 进行介绍。
一、NodeManager 基本职能
在 Hadoop 集群中，每个计算节点都需要有一个管理服务，其就是 NodeManager（NM）。
它负责与 ResourceManager 保持通信，管理 Container 的生命周期，监控每个 Container 的资源使用情况，追踪节点健康状况，管理日志等。
主要职责：
- 保持与 ResourceManager 同步
- 跟踪节点的健康状况
- 管理节点各个 Container 的生命周期，监控每个 Container 的资源使用情况
- 管理分布式缓存（对 Container 所需的 Jar，库文件的本地文件系统缓存）
- 管理各个 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 操作。
参考文章：
《Hadoop技术内幕：深入解析YARN架构设计与实现原理》
深入YARN系列3：剖析NodeManager架构，组件与生产应用
NodeManager详细组件及功能
Yarn NodeManager总体架构