前言

上篇文章笔者简单介绍了HDFS Federation新方案RBF里的connection管理。RBF虽说在功能上只是帮助client做请求转发的，在角色功能定位上相当于一个代理的角色。但RBF的这个“代理”远比我们平常说的代理服务要复杂许多。RBF的核心服务Router在设计实现上被赋予了远比普通代理服务更为全面，成熟的功能。因此集群维护者需要对RBF有足够的了解，同时需要提前考虑到RBF可能存在的一些问题和挑战，这样才能将RBF真正更好的服务于底层的NameNode服务。本文笔者来聊聊部署RBF需要面对的问题和挑战，鉴于笔者也还在探索RBF的阶段中，本文暂不讨论相应的解决方案。

一. Router层面的潜在问题

如果我们想在集群中上线RBF功能，那么首先我们要对里面的Router服务做到相当深程度的了解。这里笔者列出下面几点需要考虑的问题点。在RBF部署生产前，我们需要能够做到很好地了解并知道怎么解决下面提及到的问题。

Router的性能测试，对请求延时的影响

Router作为介于client和下游NN的中间层，相比较于原始client直接访问NN的方式，毫无疑问，这里面会多了一定的处理延时。在测试环境中，我们需要清楚的知道这部分的处理延时的影响，会有多少比重的处理时间的耗损，轻微幅度处理时间的上涨是可以接受的。

Router间如何做到本地状态的一致性

Router在实现上是一个无状态的服务，它所需要的诸如mount table等状态数据信息都是保存在外部的State Store上的。然后Router间通过shared的State Store对外提供一致性状态的高可用服务。因此这里我们需要明白的一个点是，Router间如何做到本地状态的一致性更新的，因为可能存在client请求分别发请求到不同的Router进行处理。

Router对下游NN的统筹管理

Router除了负责最基本的请求转发功能外，社区还在其内部实现了更多的统筹管理下游多NN的功能，包括全局Quota这类的功能。从Router的视角出发，它相当于也是多NN服务的一个master中心管理服务。它已经包括基本的监控NN状态，mount point挂载，我们甚至可以在Router层面做跨ns的数据Balance。

Router对公有目录的处理

在RBF模式下，只会存在一套逻辑的文件系统，但是在原有Federation里各个ns都自己的文件路径信息，这里就会存在路径重叠的情况。这个时候，我们要解决的问题是如何将那些互相重叠的目录进行重新整理规划。比较典型的例子是那些每个ns可能会配置有同名的公共目录名称，比如/user这种目录。社区有专门的关于多ns下，关于user目录moveToTrash的issue，详见JIRA：HDFS-14117。

Router对底层State Store的压力

虽然说Router在实现上是无状态的，我们无需考虑其内存状态数据的性能问题，但是其外部State Store的存储性能也是我们需要考虑的。在Security模式下，Router会存储delegation token在ZK中，这个delegation token数量取决于application的提交量，所以是存在有可能会有大量delegation token需要被存入ZK的。我们需要特别考虑ZK存储应用delegation token这方面的压力，社区有相关JIRA HDFS-15383有提到这块的问题。

二. RBF架构部署下需要解决的问题

除了上小节提到的Router服务本身的很多细节需要我们了解之外，其次我们还需要去解决RBF架构模式下所需要解决的问题。

第一个问题是真实client信息丢失问题。在RBF下，client端前面被Router挡了一层，因此所有到下游NN上的请求的信息其实是来自于Router这个服务了。因此NN这边能够拿到的client信息就变成了Router的信息了，这里面就存在真实client信息丢失的问题。这里面比较重要的client信息是IP信息，因为client请求的source ip有助于我们的audit log信息记录。另一方面ip地址信息和数据的locality也是有直接关联的。

Client信息在Router层面是可以获取到的，因此这里需要解决的问题是如何在Router层面再将这些信息传入到下游NN中，社区已经有相关的JIRA来做这块的改进，HDFS-13293。

第二个问题是底层Router服务对client的透明。一个理想的部署模式是client无须知道我们有多少个Router在服务，也无须知道实际的Router通信地址。client只需要知道一个类似vip router地址就足够了。因此我们需要在Router服务前面多加一个LB或者vip供client端来透明地访问到Router服务。这样的话，我们在日后对Router服务的维护将会对client来讲完全透明。

三. 迁移RBF的挑战

最后一块需要考虑的问题是RBF实际部署生产环境时需要解决的问题。

这里主要有以下一些问题：

• Router与现有的client以及相关Hadoop service的集成。如何将Router无缝衔接地与现有独立cluster模式进行集成，做到对用户job的尽可能透明。
• Router生产环境参数指标的确认，包括其Router内部connection数，handler数的设置等等。
• Router如何平滑迁移问题，例如灰度升级可能对用户job的影响，能否透明兼容已有的hdfs scheme模式。一个基本的原则是尽可能减少client迁移成RBF模式所需要做的变更操作。

以上就笔者目前想到的关于RBF部署生产的一些诸多需要考虑到的问题点，挑战和困难点还是有一些的。但是在RBF模式下，HDFS NN的scalability将会得到一定的改善，同时Router可以进一步的帮助我们中心化管理多HDFS cluster，包括一些数据空间的整合，数据访问的隔离等等。在Router里还是有很多的文章可以作的。