分布式资源调度管理框架：YARN的架构及工作原理_yarn联邦配置

目录

简介

基础架构

高可用架构

联邦机制

调度器

---

简介

Hadoop2.x引入了一个新的组件：YARN ，它作为hadoop集群中的资源管理模块，为各类计算框架提供资源的管理和调度。负责管理集群中的资源：CPU，内存，磁盘，网络IO等等（v3.1.1版本之后新增了对GPU资源的管理）以及调度运行在YARN之上的各种计算任务。

基础架构

与HDFS中的NameNode和DataNode类似，YARN也是主从结构的，主要由ResourceManager、NodeManager、ApplicationMaster和Container等几个组件构成。

• ResourceManager：负责处理客户端请求，对各个NM上的资源进行统一管理和调度。给ApplicationMaster分配空闲的Container 运行并监控其运行状态。主要由两个组件构成：调度器和应用程序管理器。
  • 调度器(Scheduler)：调度器根据容量、队列等限制条件，将系统中的资源分配给各个正在运行的应用程序。调度器仅根据各个应用程序的资源需求进行资源分配，资源分配单位是Container。Scheduler不负责监控或者跟踪应用程序的状态。总之，调度器根据应用程序的资源要求，以及集群机器的资源情况，为应用程序分配封装在Container中的资源。
  • 应用程序管理器(Applications Manager)：应用程序管理器负责管理整个系统中所有应用程序，包括应用程序提交、与调度器协商资源以启动ApplicationMaster 、监控ApplicationMaster运行状态并在失败时重新启动等，跟踪分给的Container的进度、状态也是其职责。
• NodeManager：是每个节点上的资源和任务管理器。它会定时地向ResourceManager汇报本节点上的资源使用情况和各个Container的运行状态；同时会接收并处理来自ApplicationMaster 的Container 启动/停止等请求。
• ApplicationMaster：用户提交的每个应用程序都包含一个ApplicationMaster ，负责应用的监控，跟踪应用执行状态，重启失败任务等。ApplicationMaster是应用框架，它负责向ResourceManager协调资源，并且与NodeManager协同工作完成Task的执行和监控。
• Container：是YARN中的资源抽象，它封装了某个节点上的多维度资源，如内存、CPU、磁盘、网络等，当ApplicationMaster向ResourceManager申请资源时，ResourceManager为ApplicationMaster 返回的资源便是用Container 表示的。

 基础架构：http://hadoop.apache.org/docs/current/hadoop-yarn/hadoop-yarn-site/YARN.html

YARN的工作流程如上图：

1. 客户端向RM提交计算任务；
2. Applications Manager与NM交互开启第一个Container，并在其中启动APP Master；
3. APP Master向Applications Manager注册自己；
4. APP Master计算所需资源并向Scheduler申请资源；
5. Scheduler将资源封装为Container的形式返回给APP Master；
6. APP Master根据得到的资源列表与对应的NM节点通信，要求其启动任务；
7. NM准备该任务所需的配置如环境变量、JAR包、二进制程序等，然后启动该任务；
8. Container中的任务在执行过程中会以心跳的形式向APP Master汇报自己的执行状态；同时，APP Master也会向Applications Manager汇报任务执行状态；
9. 任务完成后，APP Master会向RM注销并关闭自己，释放资源；

高可用架构

通过上面的介绍可以看出，Resource Manager充当了YARN集群中的Master节点，负责接收任务的提交和分发，但一个RM会产生单点故障，因此和HDFS一样，YARN也是可以利用Zookeeper做高可用架构的。 

高可用架构：http://hadoop.apache.org/docs/current/hadoop-yarn/hadoop-yarn-site/ResourceManagerHA.html

自动故障转移（automatic-failover）：与HDFS不同的是，HDFS中的NameNode利用ZKFC进行选举和故障转移，而YARN中是内嵌了ZK的ActiveStandbyElector 组件，它负责监控当前ACTIVE的ResouceManager是否健康，一旦ACTIVE的RM出现故障，ActiveStandbyElector就会直接令另一个STANDBY的RM转变为ACTIVE状态。

当然我们也可以手动的查看和切换RM的状态，在另一篇文章中有更加详细的介绍，再此不再赘述。

传送门：YARN查看和切换ResourceManager的状态

联邦机制

YARN集群可管理数千个节点，但可伸缩性由Resource Manager确定，并且与节点数，活跃的应用程序，活跃的容器和心跳频率成比例。对于超级大厂，数千台计算节点可能是不够用的，虽然可以通过搭建多个YARN集群去解决，但由于RM管理节点数量过多会对性能造成影响，同时多个集群的统一管理也不方便，也不能最大化的利用集群内的计算资源。在v2.9.0版本新增的YARN的联邦机制，可以很好的帮助我们解决这些问题。 

YARN的联邦机制单个大的YARN集群划分为数个子集群的较小单元，每个子集群具有其自己的YARN RM和NM。联邦系统（federation system）将这些子集群拼接在一起，使它们成为一个大型YARN集群。在此联邦环境中运行的应用程序只能看到单个大型YARN群集，并且能够在联邦群集的任何节点上提交任务。联邦系统将与子集群的Resource Manager协商并为应用程序提供资源，允许单个作业无缝地跨子集群运行。这种架构更有助于对集群的线性扩展。

联邦机制：http://hadoop.apache.org/docs/current/hadoop-yarn/hadoop-yarn-site/Federation.html

1. sub-cluster：子集群也是YARN集群，具有多达数千个节点。子集群的YARN RM将在保持高可用性的情况下运行，即，我们应该能够容忍YARN RM，NM故障。如果整个子集群遭到破坏，外部机制将确保在单独的子集群中重新提交作业。子集群也是联邦中的可伸缩性单元。我们可以通过添加一个或多个子集群来进行扩展。
2. Router：路由组件，一个Federation 集群可以配置一组，但最少配置一个。用户提交应用时首先会访问其中一个Router，然后Router会先从State Store中获得所有“Sub Cluster”信息（active rm 和 其他一些使用率信息），之后根据配置的路由策略（联邦策略存储）将应用程序提交请求转发到对应的RM上。
3. AMRMProxy：帮助App跨子集群运行。AMRMProxy运行在所有的NM机器上，它实现了ApplicationMasterProtocol接口作为AM的YARN RM的代理。 应用程序不能直接与子集群的RM通信，YARN框架强制应用程序只能连接到AMRMProxy，从而提供对多个YARN RM（通过动态路由/拆分/合并通信）的透明访问。 在任何时候，作业都可以跨主子集群和多个辅助子集群运行，其中AMRMProxy的运行策略会试图限制每个作业的占用空间以降低调度上的开销。
4. Global Policy Generator(简写：GPG)：全局策略生成器根据集群状态信息写入相关Policy调度策略信息；
5. Federation State-Store：联邦状态定义了需要维护的附加状态，以便将多个单独的子集群松散地耦合到单个大型联邦集群中。
6. Federation Policy Store：联邦策略存储是一个逻辑上独立的存储，其中包含有关如何将应用程序和资源请求路由到不同子集群的信息。 当前的几种策略：随机/散列/循环/优先级（random/hashing/round-robin/priority）。 

调度器

YARN支持下面几种调度方式，调度器可以在yarn-site.xml中的 yarn.resourcemanager.scheduler.class 属性中进行配置：

<property>
  <name>yarn.resourcemanager.scheduler.class</name>
  <value>org.apache.hadoop.yarn.server.resourcemanager.scheduler.fair.FairScheduler</value>
</property>

FIFO Scheduler（队列调度）：把任务按提交的顺序排成一个队列，这是一个先进先出队列，在进行资源分配的时候，先给队列中最头上的任务进行分配资源，待最头上任务需求满足后再给下一个分配，以此类推。FIFO Scheduler是最简单也是最容易理解的调度器，也不需要任何配置，但它并不适用于共享集群。大的任务可能会占用所有集群资源，这就导致其它任务被阻塞。

Capacity Scheduler（容量调度器）：apache版本默认使用的调度器，容量调度器允许多个组织共享整个集群，每个组织可以获得集群的一部分计算能力。通过为每个组织分配专门的队列，然后再为每个队列分配一定的集群资源，这样整个集群就可以通过设置多个队列的方式给多个组织提供服务了。除此之外，队列内部又可以垂直划分，这样一个组织内部的多个成员就可以共享这个队列资源了，在一个队列内部，资源的调度是采用的是先进先出(FIFO)策略。

Fair Scheduler（公平调度器）：CDH版本默认使用的调度器，公平调度器的设计目标是为所有的应用分配公平的资源（对公平的定义可以通过参数来设置）。公平调度在也可以在多个队列间工作。举个例子，假设有两个用户A和B，他们分别拥有一个队列。当A启动一个job而B没有任务时，A会获得全部集群资源；当B启动一个job后，A 的job会继续运行，不过一会儿之后两个任务会各自获得一半的集群资源。如果此时B再启动第二个job并且其它job还在运行，则它将会和B的第一个job共享B这个队列的资源，也就是B的两个job会分别使用四分之一的集群资源，而A的job仍然用于集群一半的资源，结果就是资源最终在两个用户之间平等的共享。

 

希望本文对你有帮助，请点个赞鼓励一下作者吧~ 谢谢！