HDFS全量块汇报(FBR)的限流机制

前言


众所周知在HDFS中,DataNode会进行定期的全量块汇报操作到NameNode中,来向NameNode表明其上所存储的所有块数据。这个动作在HDFS中称之为Full Block Report,简称FBR。FBR其实是一个十分expensive的操作,尤其当DataNode存储有大量block块的时候。又因为HDFS FSN全局单一锁的设计,当NameNode同时需要处理来自其下多个DataNode的FBR的时候,就可能陷入overload的情况。进而表现在用户应用层面,就是用户请求响应延时等等。本文笔者来聊聊HDFS的全量块汇报问题,以及目前社区对此的优化方案。

HDFS全量块汇报(FBR)的性能问题


如上文所提到的,由于HDFS内部的全局单一锁的设计,当NameNode对系统元数据做修改操作时,其它所有别的操作都将被block住。因此假设每个DN的FBR都包含有大量块信息的时候,NameNode将会花费很大的开销来处理这些汇报的块。

Hadoop社区在很早的时候就发现了这个问题,它提出的一个改进思路是:既然一整个大的FBR行为会造成很大的性能问题,那么我们是否可以将它拆分成多个小部分的块,并且分多次RPC进行发送呢?基于这个思路,社区在HDFS-5153: Datanode should send block reports for each storage in a separate message.实现了基于每个Storage的块汇报实现。在此优化下,当DataNode发现自身全量块汇报的总数大于阈值块汇报数(默认为100w)时,会将块按照每个Storage存储目录进行汇报,这样一个大的FBR RPC就变为了多次小的RPC行为。这样的话,远端NameNode处理DataNode的FBR压力会小许多。,相关逻辑代码如下:

      // 当全量块汇报数小于阈值块时,进行一次性汇报行为
      if (totalBlockCount < dnConf.blockReportSplitThreshold) {
        // Below split threshold, send all reports in a single message.
        DatanodeCommand cmd = bpNamenode.blockReport(
            bpRegistration, bpos.getBlockPoolId(), reports,
              new BlockReportContext(1, 0, reportId, fullBrLeaseId, true));
        blockReportSizes.add(
            calculateBlockReportPBSize(useBlocksBuffer, reports));
        numRPCs = 1;
        numReportsSent = reports.length;
        if (cmd != null) {
          cmds.add(cmd);
        }
      } else {
        // 否则按照Storage,进行多次RPC汇报
        // Send one block report per message.
        for (int r = 0; r < reports.length; r++) {
          StorageBlockReport singleReport[] = { reports[r] };
          DatanodeCommand cmd = bpNamenode.blockReport(
              bpRegistration, bpos.getBlockPoolId(), singleReport,
              new BlockReportContext(reports.length, r, reportId,
                  fullBrLeaseId, true));

NameNode的FBR限流机制


上面提到的HDFS-5153改进虽然在一定程度上的确是优化了HDFS的FBR处理,但是随着当今存储技术的进步,单块磁盘能够存储的数据量也在不断提升。进一步地来说,DataNode将FBR拆分出的小的Storage Report也可能存在包含有大量块信息的情况。面对Storage存储密度不断上升的情况,HDFS-5153并没有解决掉本质问题。

那么这里我们有什么别的优化方向呢?我们是否能在NameNode端做特殊处理,能够使得它避免长时间忙碌于FBR的处理之中呢?为此,社区在block report中引入了租约的概念来控制DataNode的全量块汇报行为,简称BR Lease。在BR Lease机制下,只有那些获得了NameNode所授予的BR Lease的DataNode节点,才能进行FBR行为。有了这层控制,NameNode就能够减缓底层大量DataNode所带来的FBR操作压力了。

用一个轻松、简单的对话来模拟BR Lease下的FBR行为:

DN: Hi NN,我现在能进行全量块汇报行为吗?
NN:我现在太忙了,不能让你汇报。
过了一会儿,DN又来问了:
DN: Hi NN,我现在可以进行全量块汇报行为吗?
NN:现在不忙了,可以汇报了,我来分配给你一个租约。
DN拿到了NN所授予的租约,NN验证了DN租约的有效性后,然后进行了FBR处理。

其实从中我们可以看到,BR Lease在这里变相起到了Rate Limit的作用,至于这个Rate到底控制在什么值,可以根据具体场景进行具体设置。

BR Lease的管理控制


社区在HDFS-7923: The DataNodes should rate-limit their full block reports by asking the NN on heartbeat messages中实现了基于BR Lease的FBR的限流控制。在此实现内,新增了一个专门管理BR Lease的管理类BlockReportLeaseManager。BlockReportLeaseManager负责有以下2类功能:

  • 分配DataNode租约Id
  • 处理块汇报前验证DataNode提供的租约Id是否有效

BlockReportLeaseManager对DataNode的BR Lease做了额外两项的限制:

  • 当前最多允许的Lease分配数,进而限制DataNode的FBR上报数,DataNode只有拿到Lease Id才能进行下一步的FBR。
  • 每个Lease有其过期时间,过期时间设置是为了限制Lease的有效使用时间范围,借此避免DataNode长时间占用Lease。

基于BR Lease的FBR限流逻辑


下面我们通过具体代码来展示基于BR Lease的FBR限流逻辑。

首先是DataNode端,相关操作方法BPServiceActor#offerServic

          // 1. 判断是否需要发送请求BR Lease
          boolean requestBlockReportLease = (fullBlockReportLeaseId == 0) &&
                  scheduler.isBlockReportDue(startTime);
          if (!dn.areHeartbeatsDisabledForTests()) {
        	// 2. 发送心跳给NN,获取BR Lease信息
            resp = sendHeartBeat(requestBlockReportLease);
            assert resp != null;
            if (resp.getFullBlockReportLeaseId() != 0) {
              if (fullBlockReportLeaseId != 0) {
              ...
              fullBlockReportLeaseId = resp.getFullBlockReportLeaseId();
            }
            ..
        // 3. 如果获取到的Lease Id不为0,则进行FBR操作(顺带带上LeaseId)
        if ((fullBlockReportLeaseId != 0) || forceFullBr) {
          cmds = blockReport(fullBlockReportLeaseId);
          // 重置FBR的Lease Id, 为了让DN下次重新申请Lease Id
          fullBlockReportLeaseId = 0;
        }

然后我们紧接着来看服务端的逻辑方法,首先是FSNamesystem.handleHeartbeat对于request FBR Lease的处理,相关方法FSNamesystemhandleHeartbeat

  HeartbeatResponse handleHeartbeat(DatanodeRegistration nodeReg,
      StorageReport[] reports, long cacheCapacity, long cacheUsed,
      int xceiverCount, int xmitsInProgress, int failedVolumes,
      VolumeFailureSummary volumeFailureSummary,
      boolean requestFullBlockReportLease,
      @Nonnull SlowPeerReports slowPeers,
      @Nonnull SlowDiskReports slowDisks)
          throws IOException {
    readLock();
    try {
      //get datanode commands
      ...
      long blockReportLeaseId = 0;
      // 从BlockManage中获取租约
      if (requestFullBlockReportLease) {
        blockReportLeaseId =  blockManager.requestBlockReportLeaseId(nodeReg);
      }

      //...
      return new HeartbeatResponse(cmds, haState, rollingUpgradeInfo,
          blockReportLeaseId);
    } finally {
      readUnlock("handleHeartbeat");
    }
  }

我们进入BlockManager的requestBlockReportLeaseId方法,在里面分配BR LeaseId时就有着限流逻辑,通过当前可允许分配的最大Lease数来做,相关方法BlockReportLeaseManager#requestLease

  public synchronized long requestLease(DatanodeDescriptor dn) {
    NodeData node = nodes.get(dn.getDatanodeUuid());
    ...
    // 1. 在分配新的Lease之前先移除过期的Lease
    pruneExpiredPending(monotonicNowMs);
    // 2. 如果当前的有效Lease超过最大可允许值,返回0代表请求Lease Id失败
    if (numPending >= maxPending) {
      if (LOG.isDebugEnabled()) {
        StringBuilder allLeases = new StringBuilder();
        String prefix = "";
        for (NodeData cur = pendingHead.next; cur != pendingHead;
             cur = cur.next) {
          allLeases.append(prefix).append(cur.datanodeUuid);
          prefix = ", ";
        }
        LOG.debug("Can't create a new BR lease for DN {}, because " +
              "numPending equals maxPending at {}.  Current leases: {}",
              dn.getDatanodeUuid(), numPending, allLeases.toString());
      }
      return 0;
    }
    ...
  }

接着是BlockManager对于DataNode上报的FBR的处理,相关方法NameNodeRpcServer#blockReport

  public DatanodeCommand blockReport(final DatanodeRegistration nodeReg,
        String poolId, final StorageBlockReport[] reports,
        final BlockReportContext context) throws IOException {
    checkNNStartup();
    ...
    try {
      // 1. 检查FBR租约的有效性,主要包含两方面的检查
      //    1)租约Id是否为当前已分配给此DN的Lease Id值
      //    2)租约Id是否已过期
      if (bm.checkBlockReportLease(context, nodeReg)) {
        for (int r = 0; r < reports.length; r++) {
          final BlockListAsLongs blocks = reports[r].getBlocks();
          ...
          final int index = r;
          // FBR租约验证通过,BlockManager进行FBR的处理
          noStaleStorages = bm.runBlockOp(() ->
            bm.processReport(nodeReg, reports[index].getStorage(),
                blocks, context));
        }
        ...

附上上述逻辑的流程图:

在这里插入图片描述

以上就是基于Lease的FBR限流控制原理,但是回过头来再细看这个方案,它依然还不是最完美的。因为DataNode的FBR在本质上依然没有被彻底改造,可能在未来更好的做法将FBR行为进行分段拆分,然后NN再要求DN汇报这些分段的block report,然后进行处理。这里笔者想表达一个核心point是FBR的行为应该由NN这边来控制,它来要求DN怎么去发,而不是目前单方面的由DN一股脑地将自身的全量块汇报给NN。

引用

[1]. https://issues.apache.org/jira/browse/HDFS-5153
[2]. https://issues.apache.org/jira/browse/HDFS-7923

已标记关键词 清除标记
相关推荐
©️2020 CSDN 皮肤主题: 编程工作室 设计师:CSDN官方博客 返回首页