Yarn

模块	服务	描述
用户交互模块	ClientRMService	为普通用户服务，处理请求，如：提交应用程序、终止程序、获取程序状态
AdminService	给管理员提供的服务。普通用户交互模块是ClientRMService，管理员交互模块是AdminService，之所以要将两个模块分开，用不同的通信通道发送给ResourceManager，是因为要避免普通用户的请求过多导致管理员请求被阻塞
WebApp	更友好的展示集群资源和程序运行状态
NM管理模块	NMLivelinessMonitor	监控NM是否活着，如果指定时间内未收到心跳，就从集群中移除。RM会通过心跳告诉AM某个NM上的Container失效，如果Am判断需要重新执行，则AM重新向RM申请资源。
NodesListManager	维护inlude（正常）和exlude（异常）的NM节点列表。默认情况下，两个列表都为空，可以由管理员添加节点。exlude列表里的NM不允许与RM进行通信。
ResourceTrackerService	处理来自NM的请求，包括注册和心跳。注册是NM启动时的操作，包括节点ID和可用资源上线等。心跳包括各个Container运行状态，运行Application列表、节点健康状态
AM管理模块	AMLivelinessMonitor	监控AM是否还活着，如果指定时间内没有接受到心跳，则将正在运行的Container置为失败状态，而AM会被重新分配到另一个节点上
ApplicationMasterLauncher	要求某一个NM启动ApplicationMaster，它处理创建AM的请求和kill AM的请求
ApplicationMasterService	处理来自AM的请求，包括注册、心跳、清理。注册是在AM启动时发送给ApplicationMasterService的；心跳是周期性的，包括请求资源的类型、待释放的Container列表；清理是程序结束后发送给RM，以回收资源清理内存空间；
Application管理模块	ApplicationACLLsManager	管理应用程序的访问权限，分为查看权限和修改权限。
RMAppManager	管理应用程序的启动和关闭
ContainerAllocationExpirer	RM分配Container给AM后，不允许AM长时间不对Container使用，因为会降低集群的利用率，如果超时（时间可以设置）还没有在NM上启动Container，RM就强制回收Container。
状态机管理模块	RMApp	RMApp维护一个应用程序的的整个运行周期，一个应用程序可能有多个实例，RMApp维护的是所有实例的
RMAppAttempt	RMAppAttempt维护一个应用程序实例的一次尝试的整个生命周期
RMContainer	RMContainer维护一个Container的整个运行周期（可能和任务的周期不一致）
RMNode	RMNode维护一个NodeManager的生命周期，包括启动到运行结束的整个过程。
安全模块		RM自带了全面的权限管理机制。主要由ClientToAMSecretManager、ContainerTokenSecretManager、ApplicationTokenSecretManager等模块组成。
资源分配模块	ResourceScheduler	ResourceScheduler是资源调度器，他按照一定的约束条件将资源分配给各个应用程序。RM自带了一个批处理资源调度器（FIFO）和两个多用户调度器Fair Scheduler 和Capacity Scheduler

3、启动ApplicationMaster

(1) 客户端提交一个任务给RM，ClientRMService负责处理客户端请求

(2) ClentRMService通知RMAppManager。

(3) RMAppManager为应用程序创建一个RMApp对象来维护任务的状态。

(4) RMApp启动任务，创建RMAppAttempt对象。

(5) RMAppAttempt进行一些初始化工作，然后通知ResourceScheduler申请资源。

(6) ResourceScheduler为任务分配资源后，创建一个RMContainer维护Container状态

(7) 并通知RMAppAttempt，已经分配资源。

(8) RMAppAttempt通知ApplicationMasterLauncher在资源上启动AM。

(9) 在NodeManager的已分配资源上启动AM

(10) AM启动后向ApplicationMasterService注册。

4、申请和分配container

阶段一：

(1) AM通过RPC函数向RM发送资源需求信息，包括新的资源需求描述、待释放的Container列表、请求加入黑名单的节点列表、请求移除黑名单的节点列表等

(2) RM的ApplicationMasterService负责处理AM的请求。一旦收到请求，就通知RMAppAttempt，更新应用程序执行进度，在AMLivenessMonitor中记录更新时间。

(3) ApplicationMasterService调用ResourceScheduler，将AM的资源需求汇报给ResourceScheduler。

(4) ResouceScheduler首先读取待释放的Container列表，通知RMContainer更改状态，杀死要释放的Container，然后将新的资源需求记录，如果资源足够就记录已经分配好资源。

阶段二：

(1) NM通过RPC向RM汇报各自的各个Container的运行情况

(2) RM的ResourceTrackerService负责处理来自NM的汇报，收到汇报后，就通知RMNode更改Container状态，并通知ResourceScheduler。

(3) ResourceScheduler收到通知后，如果有可分配的空闲资源，就将资源分配给等待资源的AM，等待AM下次心跳将资源领取走。

5、杀死application

Kill Job通常是客户端发起的，RM的ClientRMService负责处理请求，接收到请求后，先检查权限，确保用户有权限Kill Job，然后通知维护这个Application的RMApp对象，根据Application当前状态调用相应的函数来处理。

(1) Application没有在运行

向已经运行过的NodeManger节点对应的状态维护对象RMNode发送通知，进行清理；向RMAppManager发送通知，将Application设置为已完成状态。

(2) Application正在运行

如果正在运行，也首先像情况一处理一遍，回收运行过的NodeManager资源，将Application设置为已完成。另外RMApp还要通知维护任务状态的RMAppAttempt对象，将已经申请和占用的资源回收，但是真正的回收是由资源调度器ResourceScheduler异步完成的。

异步完成的步骤是先由ApplicationMasterLauncher杀死AM，并回收它占用的资源，再由各个已经启动的RMContainer杀死Container并回收资源。

6、 Container超时

YARN里有两种Container：运行AM的Container和运行普通任务的Container。

(1) RM为要启动的AM分配Container后，会监控Container的状态，如果指定时间内AM还没有在Container上启动的话，Container就会被回收，AM Container超时会导致Application执行失败

(2) 普通Container超时会进行资源回收，但是YARN不会自动在其他资源上重试，而是通知AM，由AM决定是否重试。

7、安全管理

Hadoop的安全管理是为了更好地让多用户在共享Hadoop集群环境下安全高效地使用集群资源。系统安全机制由认证和授权两大部分构成，Hadoop2.0中的认证机制采用Kerberos和Token两种方案，而授权则是通过引入访问控制表（Access Control List，ACL）实现的。

(1) 术语

Kerberos是一种基于第三方服务的认证协议，非常安全。特点是用户只需要输入一次身份验证信息就可以凭借此验证获得的票据访问多个服务。

Token是一种基于共享**的双方身份认证机制。

Principal是指集群中被认证或授权的主体，主要包括用户、Hadoop服务、Container、Application、Localizer、Shuffle Data等。

(2) Hadoop认证机制

Hadoop同时采用了Kerberos和Token两种技术，服务和服务之间的认证采用了Kerberos，用户和NameNode及用户和ResourceManager首次通讯也采用Kerberos认证，用户和服务之间一旦建立连接后，用户就可以从服务端获取一个Token，之后就可以使用Token认证通讯了。因为Token认证要比Kerberos要高效。

Hadoop里Kerberos认证默认是关闭的，可以通过参数hadoop.security.authentication设置为kerberos，这个配置模式是simple。

(3) Hadoop授权机制

Hadoop授权是通过访问控制列表（ACL）实现的，Hadoop的访问控制机制与UNIX的POSIX风格的访问控制机制是一致的，将权限授予对象分为：用户、同组用户、其他用户。默认情况下，Hadoop公用UNIX/Linux下的用户和用户组。

队列访问控制列表

应用程序访问控制列表

服务访问控制列表

8、 RM HA架构

通常来说Master/Slave架构中解决单点故障问题都采用热备份来实现HA，一个Active Master对外提供服务，若干个Standby Master实时同步Active Master，一旦Active Master故障，根据一定策略将Standby Master切换为Active Master对外提供服务。

(1) MasterHADaemon：控制RM的 Master的启动和停止，和RM运行在一个进程中，可以接收外部RPC命令。

(2) 共享存储：Active Master将信息写入共享存储，Standby Master读取共享存储信息以保持和Active Master同步。

(3) ZKFailoverController：基于Zookeeper实现的切换控制器，由ActiveStandbyElector和HealthMonitor组成，ActiveStandbyElector负责与Zookeeper交互，判断所管理的Master是进入Active还是Standby；HealthMonitor负责监控Master的活动健康情况，是个监视器。

(4) Zookeeper：核心功能是维护一把全局锁控制整个集群上只有一个Active的ResourceManager。

NodeManager

1、NodeManager基本介绍

NM是单个节点上的代理，功能包括与ResourceManager保持通讯、管理Container的生命周期、监控Container的资源使用、追踪节点健康状态、管理日志。

2、NodeManager内部构造

模块	说明
NodeStatusUpdater	NodeStatusUpdater是NM和RM通讯的唯一通道。NM启动时，该组件负责向RM注册、汇报节点总的可用资源。该组件周期性地汇报各个Container的状态，接收RM返回的待清理的Container列表等
ContainerManager	ContainerManager是NM最核心的模块。
RPC Server	是AM和NM通讯的唯一通道，接收AM请求，启动或者停止Container
ResourceLocalizationService	负责Container所需资源的本地化，下载文件资源，尽量分摊到各个磁盘。
ContainersLauncher	维护一个线程池并行操作Container。
AuxServices	NM附属服务。
ContainersMonitor	ContainersMonitor负责监控Container的资源使用量。
LogHandler	用户可以通过LogHandler控制Container日志保存方式。
ContainerEventDispatcher	Container事件调度器，负责将ContainerEvent类型的事件调度给对应的Container的状态机
ApplicationEventDispatcher	Application事件调度器，负责将ApplicationEvent类型的事件调度给对应
ContainerExecutor	ContainerExecutor可与底层操作系统交互，安全存放Container需要的文件和目录，启动和清除Container对应的进程。
NodeHealthCheckerServiceNodeHealthCheckerService通过周期性运行一个脚本和写磁盘检测节点的健康状况，并通知RM。NodeHealthScriptRunner：运行脚本检测LocalDirsHandlerService：写磁盘文件检测
DeletionService	NM将文件删除功能化，DeletionService异步删除文件，避免同步删除文件带来的性能开销。
Security	安全模块分为两部分：ApplicationACLManager确保访问NM的用户是合法的。ContainerTokenSecreManager确保用户请求的资源被RM授权过
WebServer	Web UI向用户展示

3、状态机管理

(1) Application状态机

RM上有一个整个集群上Application信息列表，而一个NM上也有一个处在它自己节点的Application的信息列表，NodeManager上的Application状态机维护着NodeManager上Application的状态。

这有利于对一个NM节点上的同一个Application所有的Container进行统一管理。

(2) Container状态机

Container状态机维护NodeManager上所有Container的生命周期。

(3) LocalizedResource状态机

LocalizedResource状态是NodeManager上用于维护一个资源生命周期的数据结构。资源包括文件、JAR包等。

4、container生命周期管理

(1) 资源本地化

资源本地化主要是进行分布是缓存工作，分为应用程序初始化和Container本地化。

(2) 运行Container

Container运行是由ContainerLauncher服务完成启动后，调用ContainerExecutor来进行的。主要流程为：将待运行的Container所需要的环境变量和运行命令写到Shell脚本launch_container.sh中，并将启动该脚本的命令写入default_container_executor.sh中，然后通过运行该脚本启动container。

(3) 资源清理

container清理是资源本地化的逆过程，是指当container运行完成后，NodeManager来回收资源。

ApplicationMaster

1、ApplicationMaster基本介绍

ApplicationMaster实际上是特定计算框架的一个实例，每种计算框架都有自己独特的ApplicationMaster，负责与ResourceManager协商资源，并和NodeManager协同来执行和监控Container。MapReduce只是可以运行在YARN上一种计算框架。

2、ApplicationMaster职能

(1) 初始化向ResourceManager报告自己的活跃信息的进程

(2) 计算应用程序的的资源需求。

(3) 将需求转换为YARN调度器可以理解的ResourceRequest。

(4) 与调度器协商申请资源

(5) 与NodeManager协同合作使用分配的Container。

(6) 跟踪正在运行的Container状态，监控它的运行。

(7) 对Container或者节点失败的情况进行处理，在必要的情况下重新申请资源。

3、报告活跃

(1) 注册

ApplicationMaster执行的第一个操作就是向ResourceManager注册，注册时AM告诉RM它的IPC的地址和网页的URL。

IPC地址是面向客户端的服务地址；网页URL是AM的一个Web服务的地址，客户端可以通过Http获取应用程序的状态和信息。

注册后，RM返回AM可以使用的信息，包括：YARN接受的资源的大小范围、应用程序的ACL信息。

(2) 心跳

注册成功后，AM需要周期性地发送心跳到RM确认他还活着。参数yarn.am.liveness-monitor.expiry配置AM心跳最大周期，如果RM发现超过这个时间还没有收到AM的心跳，那么就判断AM已经死掉。

4、资源需求

(1) 静态资源

在任务提交时就能确定，并且在AM运行时不再变化的资源是静态资源，比如MapReduce程序中的Map的数量。

(2) 动态资源

AM在运行时确定要请求数量的资源是动态资源。

5、调度任务

当AM的资源请求数量达到一定数量或者到了心跳时，AM才会发送心跳到RM，请求资源，心跳是以ResourceRequest形式发送的，包括的信息有：resourceAsks、ContainerID、containersToBeReleased。

RM响应的信息包括：新分配的Container列表、已经完成了的Container状态、集群可用的资源上限。

6、启动container

(1) AM从RM那里得到了Container后就可以启动Container了。

(2) AM首先构造ContainerLaunchContext对象，包括分配资源的大小、安全令牌、启动Container执行的命令、进程环境、必要的文件等

(3) AM与NM通讯，发送StartContainerRequest请求，逐一或者批量启动Container。

(4) NM通过StartContainerResponse回应请求，包括：成功启动的Container列表、失败的Container信信息等。

(5) 整个过程中，AM没有跟RM进行通信。

(6) AM也可以发送StopContainerRequest请求来停止Container。

7、完成的container

当Container执行结束时，由RM通知AM Container的状态，AM解释Container状态并决定如何继续操作。所以YARN平台只是负责为计算框架提供Container信息。

8、AM的失败和恢复

当AM失效后，YARN只负责重新启动一个AM，任务恢复到失效前的状态是由AM自己完成的。AM为了能实现恢复任务的目标，可以采用以下方案：将任务的状态持久化到外部存储中。比如：MapReduce框架的ApplicationMaster会将已完成的任务持久化，失效后的恢复时可以将已完成的任务恢复，重新运行未完成的任务。

9、ApplicationMaster启动过程

Yarn

yarn的资源调度

1、资源调度器的职能

资源调度器是YARN最核心的组件之一，是一个插拔式的服务组件，负责整个集群资源的管理和分配。YARN提供了三种可用的资源调度器：FIFO、Capacity Scheduler、Fair Scheduler。

2、资源调度器的分类

不同的任务类型对资源有着不同的负责质量要求，有的任务对时间要求不是很高(如Hive)，有的任务要求及时返还结果(如HBase)，有的任务是CPU密集型的(如过滤、统计类作业)，有的是I/O密集型的(如数据挖掘、机器学习)，所以简单的一种调度器并不能完全符合所有的任务类型。

有两种调度器的设计思路：

一是在一个物理Hadoop集群上虚拟多个Hadoop集群，这些集群各自有自己全套的Hadoop服务，典型的代表是HOD(Hadoop On Demand)调度器，Hadoop2.0中已经过时。

另一种是扩展YARN调度器。典型的是Capacity Scheduler、Fair Scheduler。

3、基本架构

(1) 插拔式组件

YARN里的资源调度器是可插拔的，ResourceManager在初始化时根据配置创建一个调度器，可以通过参数yarn.resourcemanager.scheduler.class参数来设置调度器的主类是哪个，默认是CapacityScheduler，配置值为：org.apache.hadoop.yarn.server.resourcemanager.scheduler.capacity.CapacityScheduler。

所有的资源调度器都要实现接口org.apache.hadoop.yarn.server.resourcemanager.scheduler.ResourceScheduler。

(2) 是一个事件处理器

YARN的资源管理器实际上是一个事件处理器，它处理6个SchedulerEventType类型的事件。

事件说明

Node_Removed 集群中移除一个计算节点，资源调度器需要收到该事件后从可分配的资源总量中移除相应的资源量。

Node_Added 集群增加一个节点

Application_added RM收到一个新的Application。

Application_Remove 表示一个Application运行结束

Container_expired 当一个Container分配给AM后，如果在一段时间内AM没有启动Container，就触发这个事件。调度器会对该Container进行回收。

Node_Update RM收到NM的心跳后，就会触发Node_Update事件。

4、资源调度三种模型介绍

(1) 双层资源调度模型

YARN使用了双层资源调度模型。

第一层：ResourceManager中的调度器将资源分配给各个ApplicationMaster。这一层调度由YARN的资源调度器来实现。

第二层：ApplicationMaster再进一步将资源分配给它内部的各个任务。这一层的调度由用户程序这个计算框架来实现。

YARN的资源分配过程是异步的，YARN的调度器分配给AM资源后，先将资源存入一个缓冲区内，当AM下次心跳时来领取资源。

资源分配过程如下7个步骤：

步骤1：NodeManager通过周期性的心跳汇报节点信息

步骤2：RM为NM返回一个应答，包括要释放的Container列表。

步骤3：RM收到NM汇报的信息后，会出发资源调度器的Node_Update事件。

步骤4：资源调度器收到Node_Update事件后，会按照一定的策略将该节点上资源分配给各个应用程序，并

将分配结果存入一个内存数据结构中。

步骤5：应用程序的ApplicationMaster周期性地向RM发送心跳，以领取最新分配的Container。

步骤6：RM收到AM的心跳后，将分配给它的Container以心跳应答的方式返回给ApplicationMaster

步骤7：AM收到新分配的Container后，会将这些Container进一步分配给他的内部子任务。

(2) 资源保证机制

YARN采用增量资源分配机制来保证资源的分配。

增量资源分配机制是指当YARN暂时不能满足应用程序的资源要求时，将现有的一个节点上的资源预留，等到这个节点上累计释放的资源满足了要求，再分配给ApplicationMaster。

这种增量资源分配机制虽然会造成资源的浪费，但是能保证AM肯定会得到资源，不会被饿死。

(3) 资源分配算法

YARN的资源调度器采用了主资源公平调度算法（DRF）来支持多维度资源调度。

(4) 资源抢占模型

资源调度器中，每个队列可以设置一个最小资源量和最大资源量。为了提高集群使用效率，资源调度器会将负载较轻的队列资源分配给负载较重的队列使用，当负载较轻的队列突然接到了新的任务时，调度器才会将本属于该队列的资源分配给它，但是此时资源有可能正被其他队列使用，因此调度器必须等待其他队列释放资源，如果一段时间后发现资源还未得到释放，则进行资源抢占。

关于资源抢占的实现，涉及到一下两个问题：

a.如何决定是否抢占某个队列的资源

b. 如何使得资源抢占代价最小

资源抢占是通过杀死正在使用的Container实现的，由于Container已经处于运行状态，直接杀死Container会造成已经完成的计算白白浪费，为了尽可能地避免资源浪费，YARN优先选择优先级低的Container做为资源抢占的对象，并且不会立刻杀死Container，而是将释放资源的任务留给ApplicationMaster中的应用程序，以期望他能采取一定的措施来执行释放这些Container，比如保存一些状态后退出，如果一段时间后，ApplicationMaster仍未主动杀死Container，则RM再强制杀死这些Container。

5、层级队列管理机制FIFO调度策略

(1) 层级队列

Hadoop1.0中使用了平级队列的组织方式，而后来采用了层级队列的组织方式。

层级队列的特点：

子队列

队列可以嵌套，每个队列都可以包含子队列；用户只能将应用程序提交到叶子队列中。

最小容量

每个子队列均有一个最小容量比属性，表示可以使用的父队列容量的百分比。

调度器总是优先选择当前资源使用率最低的队列，并为之分配资源。

指定了最小容量，但是不会保证会保持最小容量，同样会被分配给其他队列。

最大容量

队列指定了最大容量，任何时候队列使用的资源都不会超过最大容量。

默认情况下队列的最大容量是无限大。

用户权限管理

管理员可以配置每个叶子节点队列对应的操作系统的用户和用户组。

系统资源管理

管理员设置了每个队列的容量，每个用户可以用资源的量，调度器根据这些配置来进行资源调度

(2) 队列命名规则

为了防止队列名称的冲突和便于识别队列，YARN采用了自顶向下的路径命名规则，父队列和子队列名称采用.拼接。

6、Capacity Scheduler

(1) Capacity Scheduler特点

Capacity Scheduler是Yahoo!开发的多用户调度器。主要有以下几个特点：

容量保证

管理员可以为队列设置最低保证和资源使用上限，同一个队列里的应用程序可以共享使用队列资源。

灵活性

一个队列里的资源有剩余，可以暂时共享给其他队列，一旦该队列有的新的任务，其他队列会归还资源，这样尽量地提高了集群的利用率。

多重租赁

支持多用户共享集群和多应用程序同时运行。

安全保证

每个队列有严格的ACL列表，限制了用户的权限。

更新配置文件

管理员对参数的配置是动态的。

(2) 配置

Capacity Scheduler的所有配置都在capactiy-scheduler.xml里，管理员修改后，要通过命令来刷写队列：yarn mradmin –refreshQueues

Capacity Scheduler不允许管理员动态地减少队列数目，且更新的配置参数值应该是合法值。

以下以队列tongyong为例来说明参数配置：

资源分配相关参数
<property>

   <name>yarn.scheduler.capacity.root.tongyong.capacity</name>

   <value>10</value>

   <description>队列资源容量百分比</description>

 </property> 
 <property>

   <name>yarn.scheduler.capacity.root.tongyong.user-limit-factor</name>

   <value>3</value>

   <description>

    每个用户最多可以使用的资源量百分比

   </description>

 </property>
 <property>

   <name>yarn.scheduler.capacity.root.tongyong.maximum-capacity</name>

   <value>30</value>

   <description>

     队列资源的使用的最高上限，由于存在资源共享，所以队列使用的资源可能会超过capacity设置的量，但是不会超过maximum-capacity设置的量

   </description>

 </property>
 <property>                                                                                                                                                                       
   <name>yarn.scheduler.capacity.root.tongyong.minimum-user-limit-percent</name>                                                                                            
   <value>30</value>                                                                                                                                                              

  <description>用户资源限制的百分比，当值为30时，如果有两个用户，每个用户不能超过50%，当有3个用户时，每个用户不能超过33%，当超过三个用户时，每个用户不能超过30%
   </description>                                                                                                                                                                
</property>
限制应用程序数目相关参数
<property>

   <name>yarn.scheduler.capacity.root.tongyong.maximum-applications</name>

   <value>200</value>

    <description>

      队列中同时处于等待和运行状态的应用程序的数量，如果多于这个数量的应用程序将被拒绝。

   </description>

 </property>

 <property>

   <name>yarn.scheduler.capacity.root.tongyong.maximum-am-resource-percent</name>

   <value>0.1</value>

   <description>

     集群中用于运行应用程序ApplicationMaster的资源比例上限，该参数通常用于限制处于活动状态的应用程序的数目。

   </description>

 </property>

队列的访问和权限控制参数

 <property>

  <name>yarn.scheduler.capacity.root.tongyong.state</name>

   <value>RUNNING</value>

   <description>

     队列状态，可以为STOPPED或者为RUNNING。如果改为STOPPED，用户将不能向集群中提交作业，但是正在运行的将正常结束。

   </description>

 </property>

 <property>

   <name>yarn.scheduler.capacity.root.tongyong.acl_submit_applications</name>

   <value>root,tongyong,user1,user2</value>

  <description>

    限定哪些用户可以向队列里提交应用程序，该属性有继承性，子队列默认和父队列的配置是一样的。

   </description>

 </property>

 <property>

   <name>yarn.scheduler.capacity.root.tongyong.acl_administer_queue</name>

   <value>root,tongyong</value>

   <description>
    限定哪些用户可以管理当前队列里的应用程序。

   </description>

 </property>

7、Fair Scheduler

特点:

1.资源公平共享

默认是Fair策略分配资源，Fair 策略是一种基于最大最小公平算法实现的，所有应用程序平分资源。

2.支持资源抢占

某个队列中有剩余资源时，调度器会将这些资源共享给其他队列，当该队列有了新的应用程序提交过来后，调度器会回收资源，调度器采用先等待再强制回收的策略。

3.负载均衡

Fair Scheduler提供了一个基于任务数目的负载均衡机制，尽可能将系统中的任务均匀分布到各个节点上。

4.调度策略配置灵活

可以每个队列选用不同的调度策略：FIFO、Fair、DRF

5.提高小应用程序的响应时间

小作业也可以分配大资源，可以快速地运行完成。

yarn的多租户配置实现资源隔离

第一步：node01编辑yarn-site.xml
node01修改yarn-site.xml添加以下配置
cd /export/servers/hadoop-2.6.0-cdh5.14.0/etc/hadoop
vim yarn-site.xml

<!--  指定我们的任务调度使用fairScheduler的调度方式  -->
<property>
	<name>yarn.resourcemanager.scheduler.class</name>
	<value>org.apache.hadoop.yarn.server.resourcemanager.scheduler.fair.FairScheduler</value>
</property>

<!--  指定我们的任务调度的配置文件路径  -->
<property>
	<name>yarn.scheduler.fair.allocation.file</name>
	<value>/export/servers/hadoop-2.6.0-cdh5.14.0/etc/hadoop/fair-scheduler.xml</value>
</property>

<!-- 是否启用资源抢占，如果启用，那么当该队列资源使用
yarn.scheduler.fair.preemption.cluster-utilization-threshold 这么多比例的时候，就从其他空闲队列抢占资源
  -->
<property>
	<name>yarn.scheduler.fair.preemption</name>
	<value>true</value>
</property>
<property>
	<name>yarn.scheduler.fair.preemption.cluster-utilization-threshold</name>
	<value>0.8f</value>
</property>
<!-- 默认提交到default队列  -->
<property>
	<name>yarn.scheduler.fair.user-as-default-queue</name>
	<value>true</value>
	<description>default is True</description>
</property>

<!-- 如果提交一个任务没有到任何的队列，是否允许创建一个新的队列，设置false不允许  -->
<property>
	<name>yarn.scheduler.fair.allow-undeclared-pools</name>
	<value>false</value>
	<description>default is True</description>
</property>



第二步：node01添加fair-scheduler.xml配置文件
node01执行以下命令，添加faie-scheduler.xml的配置文件

cd /export/servers/hadoop-2.6.0-cdh5.14.0/etc/hadoop
vim fair-scheduler.xml
<?xml version="1.0"?>
<allocations>
<!-- users max running apps  -->
<userMaxAppsDefault>30</userMaxAppsDefault>
<!-- 定义我们的队列  -->
<queue name="root">
	<minResources>512mb,4vcores</minResources>
	<maxResources>102400mb,100vcores</maxResources>
	<maxRunningApps>100</maxRunningApps>
	<weight>1.0</weight>
	<schedulingMode>fair</schedulingMode>
	<aclSubmitApps> </aclSubmitApps>
	<aclAdministerApps> </aclAdministerApps>

	<queue name="default">
		<minResources>512mb,4vcores</minResources>
		<maxResources>30720mb,30vcores</maxResources>
		<maxRunningApps>100</maxRunningApps>
		<schedulingMode>fair</schedulingMode>
		<weight>1.0</weight>
		<!--  所有的任务如果不指定任务队列，都提交到default队列里面来 -->
		<aclSubmitApps>*</aclSubmitApps>
	</queue>

<!-- 

weight
资源池权重

aclSubmitApps
允许提交任务的用户名和组；
格式为： 用户名 用户组

当有多个用户时候，格式为：用户名1,用户名2 用户名1所属组,用户名2所属组

aclAdministerApps
允许管理任务的用户名和组；

格式同上。
 -->
	<queue name="hadoop">
		<minResources>512mb,4vcores</minResources>
		<maxResources>20480mb,20vcores</maxResources>
		<maxRunningApps>100</maxRunningApps>
		<schedulingMode>fair</schedulingMode>
		<weight>2.0</weight>
		<aclSubmitApps>hadoop hadoop</aclSubmitApps>
		<aclAdministerApps>hadoop hadoop</aclAdministerApps>
	</queue>

	<queue name="develop">
		<minResources>512mb,4vcores</minResources>
		<maxResources>20480mb,20vcores</maxResources>
		<maxRunningApps>100</maxRunningApps>
		<schedulingMode>fair</schedulingMode>
		<weight>1</weight>
		<aclSubmitApps>develop develop</aclSubmitApps>
		<aclAdministerApps>develop develop</aclAdministerApps>
	</queue>

	<queue name="test1">
		<minResources>512mb,4vcores</minResources>
		<maxResources>20480mb,20vcores</maxResources>
		<maxRunningApps>100</maxRunningApps>
		<schedulingMode>fair</schedulingMode>
		<weight>1.5</weight>
		<aclSubmitApps>test1,hadoop,develop test1</aclSubmitApps>
		<aclAdministerApps>test1 group_businessC,supergroup</aclAdministerApps>
	</queue>
</queue>
</allocations>



第三步：将修改后的配置文件拷贝到其他机器上
将node01修改后的yarn-site.xml和fair-scheduler.xml配置文件分发到其他服务器上面去
cd /export/servers/hadoop-2.6.0-cdh5.14.0/etc/hadoop
[aaa@qq.com hadoop]# scp yarn-site.xml  fair-scheduler.xml node02:$PWD
[aaa@qq.com hadoop]# scp yarn-site.xml  fair-scheduler.xml node03:$PWD


第四步：重启yarn集群
修改完yarn-site.xml配置文件之后，重启yarn集群，node01执行以下命令进行重启
[aaa@qq.com hadoop]# cd /export/servers/hadoop-2.6.0-cdh5.14.0/
[aaa@qq.com hadoop-2.6.0-cdh5.14.0]# sbin/stop-yarn.sh


第五步：创建普通用户hadoop
node01创建普通用户hadoop，用于测试我们使用hadoop用户提交任务到hadoop队列当中去
node01执行以下命令添加普通用户
useradd hadoop
passwd hadoop


第六步：修改文件夹权限
node01指向以下命令，修改hdfs上面tmp文件夹的权限，不然普通用户执行任务的时候会抛出权限不足的异常
hdfs dfs  -chown -R hadoop:hadoop  /tmp


第七步：使用hadoop用户提交mr任务
node01执行以下命令，切换到普通用户hadoop，然后使用hadoop来提交mr的任务
[aaa@qq.com hadoop-2.6.0-cdh5.14.0]# su hadoop
[aaa@qq.com hadoop-2.6.0-cdh5.14.0]$ yarn jar /export/servers/hadoop-2.6.0-cdh5.14.0/share/hadoop/mapreduce/hadoop-mapreduce-examples-2.6.0-cdh5.14.0.jar pi 10 20


第八步：浏览器界面查看任务调度队列

Yarn

文章目录

Yarn

架构

优点

组成

1、 ResourceManager

2、ApplicationMaster

3、NodeManager

4、Container

任务提交流程

RM、NM和AM

ResourceManager

1、RM的职能

2、RM的内部结构

3、启动ApplicationMaster

4、申请和分配container

阶段一：

阶段二：

5、杀死application

Kill Job通常是客户端发起的，RM的ClientRMService负责处理请求，接收到请求后，先检查权限，确保用户有权限Kill Job，然后通知维护这个Application的RMApp对象，根据Application当前状态调用相应的函数来处理。

(1) Application没有在运行

(2) Application正在运行

6、 Container超时

7、 安全管理

(1) 术语

(2) Hadoop认证机制

(3) Hadoop授权机制

8、 RM HA架构

通常来说Master/Slave架构中解决单点故障问题都采用热备份来实现HA，一个Active Master对外提供服务，若干个Standby Master实时同步Active Master，一旦Active Master故障，根据一定策略将Standby Master切换为Active Master对外提供服务。

NodeManager

1、NodeManager基本介绍

NM是单个节点上的代理，功能包括与ResourceManager保持通讯、管理Container的生命周期、监控Container的资源使用、追踪节点健康状态、管理日志。

2、NodeManager内部构造

3、状态机管理

(1) Application状态机

(2) Container状态机

(3) LocalizedResource状态机

4、container生命周期管理

(1) 资源本地化

(2) 运行Container

(3) 资源清理

ApplicationMaster

1、ApplicationMaster基本介绍

2、ApplicationMaster职能

3、报告活跃

(1) 注册

(2) 心跳

4、资源需求

(1) 静态资源

(2) 动态资源

5、调度任务

6、启动container

7、完成的container

8、AM的失败和恢复

9、ApplicationMaster启动过程

yarn的资源调度

1、 资源调度器的职能

2、 资源调度器的分类

3、 基本架构

(1) 插拔式组件

(2) 是一个事件处理器

4、 资源调度三种模型介绍

(1) 双层资源调度模型

(2) 资源保证机制

(3) 资源分配算法

(4) 资源抢占模型

5、 层级队列管理机制FIFO调度策略

(1) 层级队列

(2) 队列命名规则

6、Capacity Scheduler

(1) Capacity Scheduler特点

(2) 配置

7、Fair Scheduler

特点:

1.资源公平共享

2.支持资源抢占

3.负载均衡

4.调度策略配置灵活

5.提高小应用程序的响应时间

7、安全管理

1、资源调度器的职能

2、资源调度器的分类

3、基本架构

4、资源调度三种模型介绍

5、层级队列管理机制FIFO调度策略