本节开始将对 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 总体架构