前言

书接上话，YARN性能模糊的面纱终于揭开了。所谓“无度量不管理”，我觉得Linkedln这一点做的非常赞。值得一提的是，你可以看到Linkedln技术团队专业度是令人钦佩的，在拥抱开源的同时，也可以结合自身实际情况谨慎的对待开源。

随着HDFS/YARN都推出了Federation的联邦架构之后，RBF和各种特性、Patch应运而生。那么不做联邦是不是大规模的YARN就玩不转了？

这一篇我们主要来看看，Linkedln在YARN扩展方案上有哪些思考。究竟Federation是否是YARN扩展性的唯一解决方案呢？我们拭目以待。

使用Robin进行YARN的水平扩展

我们可以快速推出一些优化措施去减缓我们在resourcemanager上所发现的瓶颈问题，单个YARN集群不能再支撑Linkedln现有计算增长是显而易见的，主要由于单线程调度的基础设计。我们因此着手做了一个长期的方案规划，我们将会在未来几年实施。

我们首先从Hadoop社区评估了两个潜在的解决方案：全局调度和YARN Federation的联邦架构

全局调度的主要目标是解决复杂的资源放置需求，默认的心跳调度是不能满足的。这个解决方案引进了多线程调度，结合乐观锁的并发控制，去提升集群总的调度吞吐。然而我们在DynoYARN生产模拟中，默认的单线程调度器上无法观察到显著的提升(可能是由于调度线程中有过多的锁竞争或者在最终提交阶段container分配的拒绝率居高不下)，鉴于此我们结合增长趋势，只能从YARN调度优化上，试试一些改进措施。因此我们没有进一步在追求这个方向。

另一方面，YARN Federation专门设计去解决单个YARN集群扩展性限制问题，对于我们来说，YARN Federation似乎成为了一个特别有希望的解决方案。他允许任务去横跨上万节点的多个集群，同时呈现一个单集群的视图。通过增加多个集群去解决未来的计算增长问题，对于YARN的计算任务和用户来说，也是完全透明的。然而因为如下几个原因我们决定在不在Linkedln使用它。

• 当前全局策略生成器的实现是基于CLI实现的，他不能处理Hadoop集群中动态的资源变化。如果要处理，其操作的复杂性是非常高的。

• 他带来了很多新的依赖(存储策略的MySQL，YARN注册的ZooKeeper)，以及非常多我们没有测试或者使用的的特性，比如YARN Reservation，unmanaged AM和AMRMProxy。这些复杂度对于当前我们这种规模的团队来说影响很大。

值得注意的是，最复杂的设计来自允许YARN任务去横跨多个集群，如果作业可以保持单YARN集群的运行边界，我们可以避免很多复杂度高的工作，比如不需要在YARN上去定制一个类似L7一样的负载均衡。

负载均衡服务Robin

假设我们的Hadoop集群由多个5000节点的子集群组成，因此所有的application可以保持单集群的边界。基于这个假设，我们可以构建一个集群协调器的组件去协调子集群间的作业。在Linkedln，我们构建了在集群间动态分配YARN作业的负载均衡服务——Robin，来扩展我们的YARN集群。

在更高维度上，Robin提供了一套简单的REST API，为给定的作业返回一个YARN集群。在任务提交之前，YARN的client通过查询Robin来确定会路由到哪一个集群，并将作业发送给对应的集群。一旦作业提交，作业从开始到结束都会在对应的集群内完成。虽然作业只能使用单个集群的容量资源，但我们没有发现这对我们的工作造成影响。

在Linkedln,大多数任务都被我们的workflow引擎-Azkaban所管理，它本质上代表最终用户，担任了YARN client的功能。传统的Azkaban只支持单Hadoop集群。因此，我们不得不对Azkaban进行改造，去支持动态任务的提交和集成Robin，以便于当我们扩展逻辑集群并在下面添加物理集群时，给我们的用户呈现一个单逻辑集群的视图效果。结果是大部分用户对Robin是无感知的(请参考下面的架构图)。

尽管Robin的总体思路和设计架构比较简单，但仍有一些我们必须去值得注意和解决的问题。

• 高可用：Azkaban是我们Hadoop用户的核心，Azkaban上每一个job的运行都依赖于Robin，所以Robin的稳定是至关重要的。

1. Robin定期会在后台检查每一个YARN集群的可用资源，基于最新的快照进行路由选择，所以即使Robin连接YARN间歇性失败，作业也会被路由过去。

2. Robin的设计是无状态的，所以我们可以通过加实例去进行扩展和缩减规模。目前Robin部署在k8s上以实现动态伸缩。

1. 绝对资源公平的可用资源策略(DRF)，一个任务提交到集群时，将会被路由到可用资源最多的集群上。比如集群A总内存100T，20T可用；集群B总内存200T，30T可用，那么将会把作业路由到集群B上。

2. 相对资源公平的可用资源策略，路由一个作业到高比例可用资源的集群上。比如集群A有100T内存，可用20T，那么集群A资源可用率就是20%；集群B有200T内存，30T可用，那么集群B的资源可用率就是15%。那么这时就会将作业路由到集群A。

3. 队列级别绝对公平的可用资源策略，路由一个作业到队列可用资源最多的集群上(我们的集群有相同的队列结构)

我们在DynoYARN生产负载模拟中，模拟了每一个策略。最终发现绝对资源公平策略最小化了任务延迟，对我们来说是表现最好的策略。

• 数据本地化

目前Linkedln的作业性能重度依赖了数据本地化，作为部署Robin到我们最大的生产集群中的一个必要环节，我们拆分了存量的YARN到两个同规模的YARN子集群。HDFS集群和两个YARN子集群共享一样的节点。因为每一个作业都仅会访问50%的HDFS数据，相比拆分集群之前100%的数据访问率来说，因此在数据本地化率上是有缺失的。为了减缓影响，我们不得不在两个YARN子集群间平均的去分配每个机架的机器，以便于数据仍旧可以被同机架访问而不用关心作业运行在哪个集群上。结果表明是十分有效的。

后续规划

目前Linkedln正在积极的迁移到微软云。作为下一个阶段，我们会调研最佳的方式去管理和扩展我们云上的YARN集群。10000+节点的本地Hadoop集群迁移到云上所面临的挑战是令人兴奋的，包括解决复杂的问题，有规划的提升磁盘利用率进行成本降低和作业缓存层等等。与此同时，迁移也给我们提供了去探索微软云机会，比如spot实例，自动扩缩容等等。