Uploaded image for project: 'Hadoop HDFS'
  1. Hadoop HDFS
  2. HDFS-6507

Improve DFSAdmin to support HA cluster better

    XMLWordPrintableJSON

    Details

    • Type: Improvement
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 2.4.0
    • Fix Version/s: 2.5.0
    • Component/s: tools
    • Labels:
      None
    • Target Version/s:
    • Hadoop Flags:
      Reviewed
    • Tags:
      dfsadmin

      Description

      Currently, the commands supported in DFSAdmin can be classified into three categories according to the protocol used:
      1. ClientProtocol
      Commands in this category generally implement by calling the corresponding function of the DFSClient class, and will call the corresponding remote implementation function at the NN side finally. At the NN side, all these operations are classified into five categories: UNCHECKED, READ, WRITE, CHECKPOINT, JOURNAL. Active NN will allow all operations, and Standby NN only allows UNCHECKED operations. In the current implementation of DFSClient, it will connect one NN first, if the first NN is not Active and the operation is not allowed, it will failover to the second NN. So here comes the problem, some of the commands(setSafeMode, saveNameSpace, restoreFailedStorage, refreshNodes, setBalancerBandwidth, metaSave) in DFSAdmin are classified as UNCHECKED operations, and when executing these commands in the DFSAdmin command line, they will be sent to a definite NN, no matter it is Active or Standby. This may result in two problems:
      a. If the first tried NN is standby, and the operation takes effect only on Standby NN, which is not the expected result.
      b. If the operation needs to take effect on both NN, but it takes effect on only one NN. In the future, when there is a NN failover, there may have problems.

      Here I propose the following improvements:
      a. If the command can be classified as one of READ/WRITE/CHECKPOINT/JOURNAL operations, we should classify it clearly.
      b. If the command can not be classified as one of the above four operations, or if the command needs to take effect on both NN, we should send the request to both Active and Standby NNs.

      2. Refresh protocols: RefreshAuthorizationPolicyProtocol, RefreshUserMappingsProtocol, RefreshUserMappingsProtocol, RefreshCallQueueProtocol
      Commands in this category, including refreshServiceAcl, refreshUserToGroupMapping, refreshSuperUserGroupsConfiguration and refreshCallQueue, are implemented by creating a corresponding RPC proxy and sending the request to remote NN. In the current implementation, these requests will be sent to a definite NN, no matter it is Active or Standby. Here I propose that we sent these requests to both NNs.

      3. ClientDatanodeProtocol
      Commands in this category are handled correctly, no need to improve.

        Attachments

        1. HDFS-6507.1.patch
          52 kB
          Zesheng Wu
        2. HDFS-6507.2.patch
          27 kB
          Zesheng Wu
        3. HDFS-6507.3.patch
          30 kB
          Zesheng Wu
        4. HDFS-6507.4.patch
          32 kB
          Zesheng Wu
        5. HDFS-6507.4-inprogress.patch
          25 kB
          Vinayakumar B
        6. HDFS-6507.5.patch
          33 kB
          Zesheng Wu
        7. HDFS-6507.6.patch
          33 kB
          Zesheng Wu
        8. HDFS-6507.7.patch
          33 kB
          Zesheng Wu
        9. HDFS-6507.7.patch
          33 kB
          Zesheng Wu
        10. HDFS-6507.8.patch
          33 kB
          Zesheng Wu

          Issue Links

            Activity

              People

              • Assignee:
                wuzesheng Zesheng Wu
                Reporter:
                wuzesheng Zesheng Wu
              • Votes:
                0 Vote for this issue
                Watchers:
                13 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: