Yarn_ResourceManager剖析

1. 概述

   Yarn采用了Master/Slave结构，其中，Master实现为ResourceManager,负责整个集群资源的管理与调度；Slave实现为NodeManager，负责单个节点的资源管理与任务启动。ResourceManager是整个YARN集群中最重要的组件之一，它的设计直接决定了系统的可扩展性、可用性和容错性等特点，它的功能较多，包括ApplicationMaster管理（启动、停止等）、NodeManager管理、Application管理、状态机管理等。
   ResourceManager负责集群中所有资源的统一管理和分配，它接收来自各个节点（N odeManager）的资源、汇报信息，并把这些信息按照一定的策略分配给各个应用程序（实际上是ApplicationMaster ）。

   概括起来， ResourceManager 主要完成以下几个功能：
   ❑ 与客户端交互，处理来自客户端的请求；
   ❑ 启动和管理ApplicationMaster，并在它运行失败时重新启动它；
   ❑ 管理NodeManager ，接收来自NodeManager 的资源汇报信息，并向NodeManager下达管理指令（比如杀死Container 等）；
   ❑资源管理与调度，接收来自ApplicationMaster 的资源申请请求，并为之分配资源。

2. ApplicationMaster管理

   步骤1 用户向YARN ResourcManager提交应用程序， ResourcManager收到提交请求后， 先向资源调度器申请用以启动AppIicationMaster的资源， 待申请到资源后，再由AppIicationMasterLauncher 与对应的NodeManager通信，从而启动应用程序的AppIicationMaster
   步骤2 ApplicationMaster启动完成后， ApplicationMasterLauncher会通过事件的形式，将刚启动的ApplicationMaster注册AMLivelinessMonitor， 以启动心跳监控。
   步骤3 ApplicationMaster 启动后， 先向ApplicationMasterService 注册，并将自己所在host、端口号等信息汇报给它。
   步骤4 ApplicationMaster 运行时，周期性地向ApplicationMasterService 汇报“心跳” 信息（ “心跳” 信息中包含想要申请的资源描述）。
   步骤5 ApplicationMasterService 每次收到ApplicationMaster 的心跳信息后，将通知AMLivelinessMonitor 更新该应用程序的最近汇报心跳的时间。
   步骤6 当应用程序运行完成后， ApplicationMaster 向ApplicationMasterService 发送请求， 注销自己。
   步骤7 ApplicationMasterService 收到注销请求后， 标注应用程序运行状态为完成，同时通知AMLivelinessMonitor 移除对它的心跳监控。

3. 申请与分配Container

   整个过程可看做以下两个阶段的迭代循环：
   阶段1 ApplicationMaster汇报资源需求并领取已经分配到的资源，
   阶段2 NodeManager向ResourceManager汇报各个Container运行状态， 如果ResourceManager发现它上面有空闲的资源，则进行一次资源分配，并将分配的资源保存到对应的应用程序数据结构中， 等待下次ApplicationMaster发送心跳信息时获取(即阶段1）。

4. Container超时

   在YARN中， 存在两种类型的Container， 分别是用于运行ApplicationMaster的Container （后面简称为“AM Container” ）和运行普通任务的Container （后面简称为“ 普通Container ” ）， 第一种Container的超时将导致整个Application运行失败， 而第二种Container超时则会触发一次资源回收。需要注意的是， 第二种Container超时导致任务运行失败后，YARN不会主动将其调度到另外一个节点上运行， 而是将状态告诉应用程序的ApplicationMaster， 由它决定是否重新申请资源或者重新执行。

5. 安全管理

   一般而言，系统安全机制由认证（ authentication ）和授权（ authorization ）两大部分构成。认证就是简单地对一个实体的身份进行判断；而授权则是向实体授予对数据资源和信息访问权限的决策过程。Hadoop 2.0 中的认证机制采用Kerberos和Token 两种方案， 而授权则是通过引入访问控制列表（ Access Control List. ACL ）实现的。

6. 术语介绍

   ❑Kerberos : Kerberos 是一种基于第三方服务的认证协议， 其特点是用户只需输入一次身份验证信息就可以凭借此验证获得的票据访问多个服务。Kerberos 认证过程的实现不依赖于主机操作系统的认证，它不基于主机地址的信任， 也不要求网络上所有主机是物理安全的。Kerberos 是一种非常安全的认证协议。
   ❑Token : Token 是一种基于共享密钥的双方身份认证机制， 它会被加入到当前的UGI( UserGrouplnformation ）对象中， 并以Credential 对象的形式加入到JAAS ( JavaAuthentication and Authorization Service, Java 认证和授权服务） Subject 中 ，当在UGI.doAS 上下文中执行RPC 函数时， Subject 信息将被推送到线程上下文中。
   ❑Principal : H adoop 集群中被认证或授权的主体， 主要包括用户、Hadoo p 服务、Container、Application 、Localizer、Shuffle Data 等。

7. 容错机制

   ❑Applica tionMaster容错．前面提到，不同类型的应用程序拥有不同的ApplicationMaster,而ResourceManager负责监控App licationMaster的运行状态， 一旦发现它运行失败或者超时，会为其重新分配资源并启动它。至于启动之后ApplicationMaster内部的状态如何恢复需要由自己保证，比如MRAppMaster ( MapReduce ApplicationMaster)在作业运行过程中将状态信息动态记录到HDFS上， 一旦出现故障重启后，它能够从HDFS读取并恢复之前的运行状态，以减少重新计算带来的开销。
   ❑ NodeManager容错： 如果NodeManager在一定时间内未向Resource Man ager汇报心跳信息（可能是网络原因或者自身原因）， 则ResourceManager认为它已经死掉了， 会将它上面所有正在运行的Container状态置为失败， 并告诉对应的Application Master （如果AM Container运行失败， 则需重新分配资源启动ApplicationMaster）， 以决定如何处理这些Container中运行的任务。
   ❑Container容错．如果Application Master在一定时间内未启动分配到的Containr，则ResourceManager会将该Container状态置为失败并回收它；如果－个Container在运行过程中，因为外界原因（比如资源不足、误杀等）导致运行失败， 则ResourceManager会转告给对应的ApplicationMaster， 由它决定如何处理。
   ❑ ResourceManager 容错： ResourceManager 负责整个集群的资源管理和调度， 它的重要性不言而喻， 因此它自身的容错性直接决定了YARN 的可用性和可靠性。

8. YARN HA实现

   YARN 将共享存储系统抽象成RMStateStore （它是一个Java 接口）， 以保存（出故障后）恢复ResourceManager 所必需的信息， 包括：
   ❑Application状态信息ApplicationState。内部包含应用程序提交描述信息context（对应类型为ApplicationSubmissionContext ）、提交时间submitTime （对应类型为long ）、拥有者user （对应类型为String ）三个字段。
   ❑Application 对应的每个ApplicationAttempt 信息ApplicationAttemptStateo 内部包含attemptld （对应类型为ApplicationAttemptld ）、所在Container 的信息masterContainer（对应类型为Container ）、安全Token （对应类型为Credentials ）三个字段。
   ❑安全令牌相关信息RMDTSecretManagerState o 内部包含delegationTokenState （授权令牌状态）、maste rKeyState ( master key 状态）、dtSequenceNumber （序列号）三个字段。