《Hadoop Yarn权威指南》学习笔记（一）——Yarn架构

1 ResourceManager组件

1.1 客户端和ResourceManager交互

用户和平台第一交互点为客户端和ResourceManager的交互，涉及以下组件

1.1.1 Client Service

该组件处理所有客户端到ResourceManager的远程过程调用（RPC）通信，包括：

• 应用程序提交
• 应用程序终止
• 获取应用程序、队列、集群统计、用户ACL及更多信息

ClientService在安全模式下确保用户请求都经过认真，且通过访问控制列表对用户进行授权。不支持认证的客户端也提供了ResourceManager代理令牌

1.1.2 Administration Service

管理员的操作需要比一般用户优先级更高，因此设计该接口，可以处理以下的操作：

• 刷新队列，例如增加新队列，停止队列，重新配置队列等
• 刷新ResourceManager处理的节点列表，例如节点的安装或退役
• 添加新用户组，添加、更新管理员ACL，修改超级用户列表

1.1.3 Application ACL Manager

管理每个应用程序的ACL，用户可以通过ApplicationSubmissionContext信息的一部分指定ACL

1.2 应用程序和ResourceManager的通信

应用程序被接纳后，它负责拉起ApplicationMaster的状态机，ApplicationMaster启动后和ResourceManager通过以下组件通信

1.2.1 ApplicationMaster Service

负责响应ApplicationMaster的所有请求，实现ApplicationMasterProtocol协议，负责以下任务：

• 注册ApplicationMaster
• ApplicationMaster的终止、取消注册请求
• 认证ApplicationMaster的所有请求
• 获取ApplicationMaster的Container分配和释放请求，转发给YARN调度器

ApplicationMaster Service保证ApplicationMaster任意时间点只有一个线程向ResourceManager发送请求

1.2.2 ApplicationMaster存活监控

跟踪每个ApplicationMaster以及它最后的心跳时间，超过设定值没有心跳的ApplicationMaster被认为死亡

1.3 节点和ResourceManager的通信

ResourceManager和节点通信涉及的组件如下

1.3.1 Resource Tracker Service

个人感觉类似于ApplicationMaster Service，主要负责：

• 注册新节点
• 接收前面注册节点的心跳
• 确保只有合法节点和ResourceManager通信

新节点注册后，ResourceManager发送安全相关的主键，NodeManager需要验证ApplicationMaster提交的NodeManager令牌和Container令牌，主键会滚动更新，在心跳中NodeManager会获得这些更新

Rosource Tracker Service转发合法的心跳给YARN调度器，YARN调度器根据资源请求做调度决定

1.3.2 NodeManager存活监控

跟踪每个节点的标识符和最后心跳信息，最后心跳时间超时的节点被标记为死亡

1.3.3 Nodes-List Manager

是ResourceManager内存中的一个集合，包括有效的节点和被排除的节点

1.4 ResourceManager核心组件

除了与外界通信的不同组件，还有一些核心组件如下

1.4.1 ApplicationsManager

负责管理已经提交的应用程序集合。检查应用程序规格，拒绝资源请求不合法的应用，然后确定应用程序ID是否已经被使用，最后把应用程序转给调度器

该组件还负责记录管理结束的应用程序，在日志中记录ApplicationSummary

保存一个已结束应用程序的缓存，以便用户请求应用程序的数据

1.4.2 ApplicationMaster Launcher

ApplicationMaster本身的Container是ResourceManager申请并在NodeManager上拉起的，该组件维护一个线程池且和NodeManager通信来拉起Applicationmaster（新的或之前失败的ApplicationMaster），它也在应用结束时告诉NodeManager清理ApplicationMaster

1.4.3 YarnScheduler

YARN调度器给运行的应用程序分配资源，默认调度器为Capacity调度器

1.4.4 ContainerAllocationExpirer

为防止恶意程序申请Container而不使用，该组件包含一个分配但未启动的Container列表，超时不启动的Container被判定为死亡

1.5 ResourceManager安全相关的组件

安全组件负责管理令牌和私钥，对各个RPG接口的请求进行认证和授权

1.5.1 ContainerToken SecretManager

管理Container令牌，该令牌通过ApplicationMaster路由到NodeManager以防直接发送给NodeManager带来的显著延迟（只有Container分配后，ResourceManager才能生成ContainerToken）

ApplicationMaster可能传递错误信息给NodeManager伪造CPU或内核数量，因此ResourceManager在Container令牌里加密了Container相关信息，令牌包括下面字段：

• Container ID: Container的唯一标识符，NodeManager使用该信息与应用程序绑定，防止另外一个应用启动该Container
• NodeManager地址: 目标NodeManager的地址，避免应用程序去不相关的NodeManager上启动Container
• 应用程序提交者: 用户名，NodeManager以这个用户身份执行所有Container相关活动
• 资源: 通知NodeManager关于Container的每一个资源总量
• 超时时间戳: 查看这个时间戳决定Container令牌是否仍然合法
• 主键标识符: NodeManager用来验证Container令牌。ResourceManager生成一个密钥并和NodeManager共享，密钥滚动更新，NodeManager记住新旧密钥，根据主键标识符确定正确的密钥
• ResourceManager标识符: 如果在分配Container后，ApplicationMaster重启了，为了确保NodeManager区分新旧ResourceManager而有的字段

1.5.2 AMRMToken密钥管理器

为防止恶意程序模仿一个ApplicationMaster发送调度请求，ResourceManager使用AMRMToken令牌认证ApplicationMaster的请求

1.5.3 NMToken密钥管理器

ApplicationMaster使用NMToken管理跟一个NodeManager的连接，该令牌由ResourceManager生成

1.5.4 RMDelegation Token密钥管理器

负责给客户端生成令牌，由此令牌和ResourceManager通信

1.5.5 DelegationToken Renewer

在安全模式下，ResourceManager通过Kerberos认证，且提供代表应用程序更新文件系统令牌的服务，该组件负责在应用程序运行期间更新应用程序的令牌（不理解，存疑，待日后研究）

2 NodeManager组件

2.1 NodeStatusUpdater

负责和ResourceManager通信

NodeManager刚启动时，该组件向ResourceManager注册，发送本节点的可用资源、Web Server和RPC Server的监听端口。ResourceManager发送用于验证Container的KEY。后续该组件还继续向ResourceManager提供Container的相关信息

ResourceManager还可以通过该组件通知NodeManager杀死Container。当应用程序结束时，ResourceManager都会通知NodeManager清理应用程序的资源，发起日志聚集

2.2 ContainerManager

NodeManager的核心组件

2.2.1 RPC Server

负责和ApplicationMaster通信

接受ApplicationMaster关于Container的请求，和其他安全模块协同对请求进行认证和鉴权。记录Container的所有操作，并记录日志。

2.2.2 资源本地化服务

下载Container需要的文件资源，尽可能将文件分散到各个可用磁盘上，还对下载文件进行访问控制和使用率控制。PUBLIC的资源文件存储在公共缓存，通过一组称为Public-Localizer的线程池处理，该线程池运行在NodeManager内部的地址空间。PRIVATE的资源存储在用户缓存内，通过ContainerLocalizer的独立进程完成，并不在NodeManager内部完成

2.2.3 Containers Launcher

维护用于准备及拉起Container的线程池，该组件也负责Container的清理工作，每个Container操作都由一个线程独立完成，因此一个NodeManager内的所有Container是隔离的

2.3 辅助服务

可以在NodeManager启动前配置一组可插拔的辅助服务，例如，Map和Reduce任务间传输中间数据的ShuffleHandler。当应用程序的第一个Container启动、任何Container启动或完成、应用程序完成时，都要通知辅助服务

2.3.1 Containers Monitor

监控Container运行过程中的资源使用率，超出资源分配值的Container会被该组件杀掉

2.3.2 Log Handler

保存Container日志在本地磁盘或上传文件系统

2.3.3 Container Executor

放置Container需要的文件和目录，启动和清理Container相关进程

2.3.4 Node Health Checker Service

检测节点健康度，通过NodeStatusUpdater传递给ResourceManager

2.4  安全组件

2.4.1 Application ACLs Manager

维护ACL

2.4.2 ContainerToken SecretManager

验证启动Container的请求是否合法（顾名思义应该是通过Token）

2.4.3 NMToken SecretManager

通过NMToken验证所有来自API的请求

2.4.4 Web Server

展示在给定时间点的应用程序、Container列表、节点健康、Container日志等（应该是平时用于查询的网页端业务组价）

3 ApplicationMaster

3.1 功能概述

应用程序被提交后在ResourceManager中申请一个Container来启动引导进程。一旦分配了Container，ApplicationMaster的启动器将直接与NodeMaanger通信来启动该Container，整个ApplicationMaster生命周期内的与其他部分互动如图所示，注意ApplicationMaster本身也是一个Container

更详细的叙述上篇博文已经写过https://blog.csdn.net/jiangxuege/article/details/81558975

3.2 活跃

ApplicationMaster的第一个操作是向ResourceManager注册，告知ResourceManager它的IPC地址和网页URL。ResourceManager返回YARN接受的资源大小范围、应用程序的ACL等信息

注册成功后，ApplicationMaster需要发送心跳信息，心跳信息超时会被ResourceManager认为停止运行并被杀死

3.3 资源需求

应用程序需要的资源分为静态和动态

在提交申请时能确定，且ApplicationMaster运行后不会产生变化的资源称为静态资源，否则称为动态资源

资源需求明确后，ApplicationMaster发送请求到ResourceManager的调度器请求分配Container

3.4 调度

ApplicationMaster积累足够资源请求或计时器超时，就通过API allocate向ResourceManager发送心跳（不知道这里为什么又不以组件的方式讲了），任何时刻只有一个线程可以调用allocate

ApplicationMaster通过ResourceRequest请求特定资源，ResourceRequest可能包含resourceAsks、Container ID或containersToBeReleased（先前从调度器分配但现在不再需要的Container）。响应信息包含新分配的Container列表、自ApplicationMaster和ResourceManager上次交互以来完成的应用程序相关的Container状态、集群中可用资源。ApplicationMaster可以根据Container的相关信息进行相关操作，还可以根据集群资源调节未来资源请求

ApplicationMaster有两种方式请求调度资源：

• 告知ResourceManager所有的资源请求，让全局调度器做所有决定
• 动态交互，让调度器采取全局调度，并根据资源可用性和应用程序业务逻辑，对分配的Container再做一次调度。例如，MapReduce的ApplicationMaster收到一个Container时，将该Container与待执行的Map任务匹配，首先尝试数据本地局部性的任务，然后尝试有机架局部性的任务（不理解，存疑，是否是ApplicationMaster自己承担了一部分调度任务）

3.5 调度协议

资源请求时ResourceRequest包含以下要素：

• 请求的优先级
• 资源被分配的位置，即机器名和机架名
• 资源大小
• Container数目
• relaxLocality，布尔值，决定Container是否必须严格遵循资源分配位置

3.6 启动Container

启动Container前构造ContainerLaunchContext对象，该对象包括分配资源的大小、安全令牌、启动Container的执行命令、进程环境、必要文件等。ApplicationMaster通过NodeManager通信，逐一启动Container，也可以批量运行

NodeManager通过StartContainerResponse回应，该回应包含启动成功的Container列表、失败的Container ID异常、allServicesMetaData映射（附加服务的名字到它们相应的元数据，这是个啥，不明）

ApplicationMaster可以向NodeManager发送StopContainersRequest，NodeManager通过类似的StopContainersResponse回应，该回应包含成功停止的Container列表、每个失败请求的Container ID异常

ApplicationMaster退出时，ResourceManager杀死所有正在运行的Container

3.7 完成的Container

ResourceManager以事件形式通知ApplicationMaster某个Container结束，ApplicationMaster收集已完成的Container信息并进行后续处理

3.8 协调和输出提交

框架如果支持多个Container争夺资源或输出提交，ApplicationMaster为他们提供同步原语，以便只有一个Container抢占资源或输出

3.9 退出时清理

ApplicationMaster完成工作后，向ResourceManager发送FinishApplicationRequest注销，然后做一些清理工作

4 YARN Container

4.1 Container运行环境

YARN中的Container代表在应用中的一个工作单元（说好的一种资源分配的形式呢），根据运行时是否可以解析，Container包括的信息分为静态信息和动态信息

静态信息如下：

• ApplicationMaster在ContainerLaunchContext（CLC）中描述Container启动时所需库和依赖，Container启动时，这些依赖已经通过NodeManager的本地化模块下载
• 输入、输出路径和文件系统URL是配置的一部分，可以通过环境变量、命令行参数、本身作为本地资源传来的配置文件配置
• 环境变量ApplicationConstants.Environment.LOCAL_DIRS可以决定Container输出目录
• 环境变量ApplicationConstants.LOG_DIR_EXPANSION_VAR指向日志目录
• API ApplicationConstants.Environment保存了NodeManager记录下的用户名、主目录、Container ID等信息，Container可以查看这些信息
• 环境变量ApplicationConstants.CONTAINER_TOKEN_FILE_ENV_NAME指向了保存安全令牌的文件

动态信息如下：

• ApplicationMaster的URL在故障恢复时会动态变化，可以与ResourceManager通信得到
• ApplicationMaster可以协调Container的输出位置以及相应的辅助服务，并向Container提供这些信息
• HDFS NameNode的位置在故障恢复后变化，可以通过配置来查找NameNode位置

4.2 与ApplicationMaster通信

Container并不向NodeManager汇报任何信息，也不需要向ApplicationMaster汇报信息，很多情况下Container只是独立地运行。如果应用程序需要通信，则需要将Container配置成某种进程间通信，与ApplicationMaster交互