介绍
众所周知，YARN可扩展到数千个节点。 YARN的可伸缩性由Resource Manager确定，并且与节点数，活跃的应用程序，活跃的容器和心跳频率成比例。降低心跳可以提高可扩展性，但对利用率有害。本文档描述了一种基于联邦（federation）的方法，通过联合多个YARN子集，将单个YARN集群扩展到数万个节点。所提出的方法是将大的（10-100k节点）集群划分为称为子集群的较小单元，每个集群具有其自己的YARN RM和计算节点。联合系统（federation system）将这些子集群拼接在一起，使它们成为应用程序的一个大型YARN集群。在此联合环境中运行的应用程序将看到单个大型YARN群集，并且能够在联合群集的任何节点上计划任务。联合系统将与子集群的Resource Manager协商并为应用程序提供资源。目标是允许单个作业无缝地“跨越”子集群。
这种设计在结构上是可扩展的，因为我们限制每个RM负责的节点数量，并且适当的策略将会保证大多数应用程序驻留在单个子集群中，因此每个RM看到的应用程序数量 也是有限的。 这意味着我们几乎可以通过简单地添加子集来线性扩展（因为它们之间需要很少的协调）。 此体系结构可以在每个子集群中提供非常严格的调度不变量来实施，而跨集群的连续重新平衡将强制这些属性在全局级别也得到尊重。
架构
YARN Federation的主要设计思想是希望通过联合的方式让集群可以有多个SubCluster 。 每个SubCluster都是一个独立的小集群，由子集群的ResourceManager分别管理一部分节点。这些小集群共同组成一个大的YARN Federation集群，实现资源的统一管理与作业调度。
- sub-cluster：子集群是一个YARN集群，具有多达数千个节点。
子集群的YARN RM将在保持高可用性的情况下运行，即，我们应该能够容忍YARN RM，NM故障。如果整个子集群遭到破坏，外部机制将确保在单独的子集群中重新提交作业。
子集群也是联合环境中的可伸缩性单元。我们可以通过添加一个或多个子集群来扩展联合环境。 - Router：路由组件，一个Federation 集群可以配置一组，但最少配置一个。用户提交应用时首先会访问其中一个Router，然后Router会先从State Store中获得所有“Sub Cluster”信息（active rm 和 其他一些使用率信息），之后根据配置的路由策略（从策略存储中获取）将应用程序提交请求转发到对应的RM上。
- AMRMProxy：AMRMProxy是应用程序和多个RM通讯的桥梁。他允许一个App可以跨子集群运行。例如，一个App有2000个task, 这些task会分散到所有子集群上运行，每个子集群运行一部分。AMRMProxy运行在所有的NM机器上，它实现了ApplicationMasterProtocol接口作为AM的YARN RM的代理。 应用程序不能直接与子集群的RM通信。 YARN框架强制应用程序只能连接到AMRMProxy，从而提供对多个YARN RM（通过动态路由/拆分/合并通信）的透明访问。 在任何时候，作业都可以跨主子集群和多个辅助子集群运行，其中AMRMProxy的运行策略会试图限制每个作业的占用空间以降低调度上的开销。
- Global Policy Generator(简写：GPG)：全局策略生成器忽略整个联合，并确保系统始终被正确的配置和调整。 关键设计点是群集的可用性不依赖于永远在线的GPG。
- Federation State-Store：联合状态定义了需要维护的附加状态，以便将多个单独的子集群松散地耦合到单个大型联合集群中。
- Federation Policy Store：联合策略存储是一个逻辑上独立的存储，其中包含有关如何将应用程序和资源请求路由到不同子集群的信息。 当前的实现提供了几种策略，从随机/散列/循环/优先级（random/hashing/roundrobin/priority）到更复杂的策略，这些策略考虑了子集群的负载。
应用程序跨Sub-Clusters运行的流程
提交应用程序时，Router会找一个最合适的子集群运行应用程序，称之为应用程序的主子集群。AM与RM的所有通信都通过AM机器本地的AMRMProxy进行。理想情况下，应用程序默认会运行在资源和数据都可用的子集群上，但如果需要其他子集群节点上的资源，则AMRMProxy将与这个子集群的RM通讯请求资源。让应用程序像在一个大集群上运行。这个功能需要AMRMProxy，全局策略生成器（Global Policy Generator，GPG）和Router组合在一起使用。
配置
具体配置在官网上可以看到，在此不介绍。
