HDFS RBF部署生产环境的难点和挑战

文章目录

  • 前言
  • 一. Router层面的潜在问题
    • Router的性能测试,对请求延时的影响
    • Router间如何做到本地状态的一致性
    • Router对下游NN的统筹管理
    • Router对公有目录的处理
    • Router对底层State Store的压力
  • 二. RBF架构部署下需要解决的问题
  • 三. 迁移RBF的挑战

前言


上篇文章笔者简单介绍了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里还是有很多的文章可以作的。

你可能感兴趣的:(Hadoop,HDFS,HDFS,RBF,rbf)