Details

    • Type: Sub-task Sub-task
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 0.23.0
    • Component/s: ha, namenode
    • Labels:
      None
    • Hadoop Flags:
      Reviewed

      Description

      In HDFS, following roles are supported in NameNodeRole: ACTIVE, BACKUP, CHECKPOINT and STANDBY.

      Active and Standby are the state of the NameNode. While Backup and CheckPoint are the name/role of the daemons that are started. This mixes up the run time state of NameNode with the daemon role. I propose changing the NameNodeRole to: NAMENODE, BACKUP, CHECKPOINT. HDFS-1974 will introduce the states active and standby to the daemon that is running in the role NAMENODE.

      1. HDFS-2141.1.patch
        8 kB
        Suresh Srinivas
      2. HDFS-2141.patch
        8 kB
        Suresh Srinivas

        Issue Links

          Activity

          Hide
          Suresh Srinivas added a comment -

          Changes:

          1. Changed NameNodeRole#ACTIVE to NameNodeRole#NAMENODE.
          2. Removed NameNodeRole#STANDBY.
          Show
          Suresh Srinivas added a comment - Changes: Changed NameNodeRole#ACTIVE to NameNodeRole#NAMENODE. Removed NameNodeRole#STANDBY.
          Hide
          Aaron T. Myers added a comment -

          +1, this patch looks good to me. If you care to, you might want to line up the indentation of ("NameNode") with the other members of NameNodeRole, but no reason to make another patch for it.

          We might even consider merging HdfsConstants.NodeType and HdfsConstants.NameNodeRole, since being a DN is certainly mutually exclusive with all of the NameNodeRoles, but that should probably be done as a separate JIRA.

          Show
          Aaron T. Myers added a comment - +1, this patch looks good to me. If you care to, you might want to line up the indentation of ("NameNode") with the other members of NameNodeRole , but no reason to make another patch for it. We might even consider merging HdfsConstants.NodeType and HdfsConstants.NameNodeRole , since being a DN is certainly mutually exclusive with all of the NameNodeRoles , but that should probably be done as a separate JIRA.
          Hide
          Aaron T. Myers added a comment -

          Also, I see no reason not to commit this to trunk. There's nothing HA-specific in this change - it just removes a vestigial field and renames another to be more accurate of what it actually represents. Both are used internally so there should be no compatibility concerns.

          Show
          Aaron T. Myers added a comment - Also, I see no reason not to commit this to trunk. There's nothing HA-specific in this change - it just removes a vestigial field and renames another to be more accurate of what it actually represents. Both are used internally so there should be no compatibility concerns.
          Hide
          Suresh Srinivas added a comment -

          The only concern I have is - the metrics is started with current NamenodeRole.ACTIVE. This one changes it to NamenodeRole.NAMENODE. Hence I was waiting for committing this to HDFS-1623 branch. The metrics thing would become clear as we implement more of HA functionality. Any comments?

          > We might even consider merging HdfsConstants.NodeType and HdfsConstants.NameNodeRole, since being a DN is certainly mutually exclusive with all of the NameNodeRoles, but that should probably be done as a separate JIRA.
          I like this. We could just have NodeType with NameNode, DataNode, Backup and Checkpointer?

          Show
          Suresh Srinivas added a comment - The only concern I have is - the metrics is started with current NamenodeRole.ACTIVE. This one changes it to NamenodeRole.NAMENODE. Hence I was waiting for committing this to HDFS-1623 branch. The metrics thing would become clear as we implement more of HA functionality. Any comments? > We might even consider merging HdfsConstants.NodeType and HdfsConstants.NameNodeRole, since being a DN is certainly mutually exclusive with all of the NameNodeRoles, but that should probably be done as a separate JIRA. I like this. We could just have NodeType with NameNode, DataNode, Backup and Checkpointer?
          Hide
          Aaron T. Myers added a comment -

          The only concern I have is - the metrics is started with current NamenodeRole.ACTIVE.

          But note that this patch doesn't change the description (and thus the result of NamenodeRole.toString()) for NamenodeRole.ACTIVE. So, the metrics should be unaffected from a user's point of view, correct?

          We could just have NodeType with NameNode, DataNode, Backup and Checkpointer?

          Exactly.

          Show
          Aaron T. Myers added a comment - The only concern I have is - the metrics is started with current NamenodeRole.ACTIVE. But note that this patch doesn't change the description (and thus the result of NamenodeRole.toString() ) for NamenodeRole.ACTIVE . So, the metrics should be unaffected from a user's point of view, correct? We could just have NodeType with NameNode, DataNode, Backup and Checkpointer? Exactly.
          Hide
          Suresh Srinivas added a comment -

          > But note that this patch doesn't change the description (and thus the result of NamenodeRole.toString()) for NamenodeRole.ACTIVE. So, the metrics should be unaffected from a user's point of view, correct?
          Hmm for some reason I thought it had ACTIVE before. You are right.

          I have attached new patch with indentation change. If you +1 it, I will commit it on Hudson validation.

          Show
          Suresh Srinivas added a comment - > But note that this patch doesn't change the description (and thus the result of NamenodeRole.toString()) for NamenodeRole.ACTIVE. So, the metrics should be unaffected from a user's point of view, correct? Hmm for some reason I thought it had ACTIVE before. You are right. I have attached new patch with indentation change. If you +1 it, I will commit it on Hudson validation.
          Hide
          Aaron T. Myers added a comment -

          +1, latest patch looks great.

          Show
          Aaron T. Myers added a comment - +1, latest patch looks great.
          Hide
          Sanjay Radia added a comment -

          +1 looks good.

          Show
          Sanjay Radia added a comment - +1 looks good.
          Hide
          Hadoop QA added a comment -

          +1 overall. Here are the results of testing the latest attachment
          http://issues.apache.org/jira/secure/attachment/12486944/HDFS-2141.1.patch
          against trunk revision 1147980.

          +1 @author. The patch does not contain any @author tags.

          +1 tests included. The patch appears to include 9 new or modified tests.

          +1 javadoc. The javadoc tool did not generate any warning messages.

          +1 javac. The applied patch does not increase the total number of javac compiler warnings.

          +1 findbugs. The patch does not introduce any new Findbugs (version 1.3.9) warnings.

          +1 release audit. The applied patch does not increase the total number of release audit warnings.

          +1 core tests. The patch passed core unit tests.

          +1 contrib tests. The patch passed contrib unit tests.

          +1 system test framework. The patch passed system test framework compile.

          Test results: https://builds.apache.org/job/PreCommit-HDFS-Build/965//testReport/
          Findbugs warnings: https://builds.apache.org/job/PreCommit-HDFS-Build/965//artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html
          Console output: https://builds.apache.org/job/PreCommit-HDFS-Build/965//console

          This message is automatically generated.

          Show
          Hadoop QA added a comment - +1 overall. Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12486944/HDFS-2141.1.patch against trunk revision 1147980. +1 @author. The patch does not contain any @author tags. +1 tests included. The patch appears to include 9 new or modified tests. +1 javadoc. The javadoc tool did not generate any warning messages. +1 javac. The applied patch does not increase the total number of javac compiler warnings. +1 findbugs. The patch does not introduce any new Findbugs (version 1.3.9) warnings. +1 release audit. The applied patch does not increase the total number of release audit warnings. +1 core tests. The patch passed core unit tests. +1 contrib tests. The patch passed contrib unit tests. +1 system test framework. The patch passed system test framework compile. Test results: https://builds.apache.org/job/PreCommit-HDFS-Build/965//testReport/ Findbugs warnings: https://builds.apache.org/job/PreCommit-HDFS-Build/965//artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html Console output: https://builds.apache.org/job/PreCommit-HDFS-Build/965//console This message is automatically generated.
          Hide
          Suresh Srinivas added a comment -

          I committed the patch.

          Show
          Suresh Srinivas added a comment - I committed the patch.
          Hide
          Hudson added a comment -

          Integrated in Hadoop-Hdfs-trunk-Commit #794 (See https://builds.apache.org/job/Hadoop-Hdfs-trunk-Commit/794/)
          HDFS-2141. Remove NameNode roles Active and Standby (they become states of the namenode). Contributed by Suresh Srinivas.

          suresh : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVN&view=rev&rev=1148125
          Files :

          • /hadoop/common/trunk/hdfs/src/test/unit/org/apache/hadoop/hdfs/server/namenode/TestNNLeaseRecovery.java
          • /hadoop/common/trunk/hdfs/CHANGES.txt
          • /hadoop/common/trunk/hdfs/src/java/org/apache/hadoop/hdfs/server/common/HdfsConstants.java
          • /hadoop/common/trunk/hdfs/src/java/org/apache/hadoop/hdfs/server/namenode/BackupNode.java
          • /hadoop/common/trunk/hdfs/src/test/hdfs/org/apache/hadoop/hdfs/server/namenode/TestSaveNamespace.java
          • /hadoop/common/trunk/hdfs/src/test/hdfs/org/apache/hadoop/hdfs/server/namenode/TestEditLogRace.java
          • /hadoop/common/trunk/hdfs/src/java/org/apache/hadoop/hdfs/server/namenode/FSImage.java
          • /hadoop/common/trunk/hdfs/src/java/org/apache/hadoop/hdfs/server/namenode/NameNode.java
          Show
          Hudson added a comment - Integrated in Hadoop-Hdfs-trunk-Commit #794 (See https://builds.apache.org/job/Hadoop-Hdfs-trunk-Commit/794/ ) HDFS-2141 . Remove NameNode roles Active and Standby (they become states of the namenode). Contributed by Suresh Srinivas. suresh : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVN&view=rev&rev=1148125 Files : /hadoop/common/trunk/hdfs/src/test/unit/org/apache/hadoop/hdfs/server/namenode/TestNNLeaseRecovery.java /hadoop/common/trunk/hdfs/CHANGES.txt /hadoop/common/trunk/hdfs/src/java/org/apache/hadoop/hdfs/server/common/HdfsConstants.java /hadoop/common/trunk/hdfs/src/java/org/apache/hadoop/hdfs/server/namenode/BackupNode.java /hadoop/common/trunk/hdfs/src/test/hdfs/org/apache/hadoop/hdfs/server/namenode/TestSaveNamespace.java /hadoop/common/trunk/hdfs/src/test/hdfs/org/apache/hadoop/hdfs/server/namenode/TestEditLogRace.java /hadoop/common/trunk/hdfs/src/java/org/apache/hadoop/hdfs/server/namenode/FSImage.java /hadoop/common/trunk/hdfs/src/java/org/apache/hadoop/hdfs/server/namenode/NameNode.java
          Hide
          Hudson added a comment -

          Integrated in Hadoop-Hdfs-trunk #729 (See https://builds.apache.org/job/Hadoop-Hdfs-trunk/729/)
          HDFS-2141. Remove NameNode roles Active and Standby (they become states of the namenode). Contributed by Suresh Srinivas.

          suresh : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVN&view=rev&rev=1148125
          Files :

          • /hadoop/common/trunk/hdfs/src/test/unit/org/apache/hadoop/hdfs/server/namenode/TestNNLeaseRecovery.java
          • /hadoop/common/trunk/hdfs/CHANGES.txt
          • /hadoop/common/trunk/hdfs/src/java/org/apache/hadoop/hdfs/server/common/HdfsConstants.java
          • /hadoop/common/trunk/hdfs/src/java/org/apache/hadoop/hdfs/server/namenode/BackupNode.java
          • /hadoop/common/trunk/hdfs/src/test/hdfs/org/apache/hadoop/hdfs/server/namenode/TestSaveNamespace.java
          • /hadoop/common/trunk/hdfs/src/test/hdfs/org/apache/hadoop/hdfs/server/namenode/TestEditLogRace.java
          • /hadoop/common/trunk/hdfs/src/java/org/apache/hadoop/hdfs/server/namenode/FSImage.java
          • /hadoop/common/trunk/hdfs/src/java/org/apache/hadoop/hdfs/server/namenode/NameNode.java
          Show
          Hudson added a comment - Integrated in Hadoop-Hdfs-trunk #729 (See https://builds.apache.org/job/Hadoop-Hdfs-trunk/729/ ) HDFS-2141 . Remove NameNode roles Active and Standby (they become states of the namenode). Contributed by Suresh Srinivas. suresh : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVN&view=rev&rev=1148125 Files : /hadoop/common/trunk/hdfs/src/test/unit/org/apache/hadoop/hdfs/server/namenode/TestNNLeaseRecovery.java /hadoop/common/trunk/hdfs/CHANGES.txt /hadoop/common/trunk/hdfs/src/java/org/apache/hadoop/hdfs/server/common/HdfsConstants.java /hadoop/common/trunk/hdfs/src/java/org/apache/hadoop/hdfs/server/namenode/BackupNode.java /hadoop/common/trunk/hdfs/src/test/hdfs/org/apache/hadoop/hdfs/server/namenode/TestSaveNamespace.java /hadoop/common/trunk/hdfs/src/test/hdfs/org/apache/hadoop/hdfs/server/namenode/TestEditLogRace.java /hadoop/common/trunk/hdfs/src/java/org/apache/hadoop/hdfs/server/namenode/FSImage.java /hadoop/common/trunk/hdfs/src/java/org/apache/hadoop/hdfs/server/namenode/NameNode.java
          Hide
          Konstantin Shvachko added a comment -

          I disagree with this change. NAMENODE is not a role. All of them are NameNodes. The role is active, checkpoint, or standby.
          I also do not understand what is the long term purpose of the change.
          I think the HA work should be done in a branch.
          Getting up to speed after vacation, Sorry if I missed any discussions in last two weeks.

          Show
          Konstantin Shvachko added a comment - I disagree with this change. NAMENODE is not a role. All of them are NameNodes. The role is active, checkpoint, or standby. I also do not understand what is the long term purpose of the change. I think the HA work should be done in a branch. Getting up to speed after vacation, Sorry if I missed any discussions in last two weeks.
          Hide
          Suresh Srinivas added a comment -

          NameNode is the name of the daemon. Active and standby are the states of the a namenode.

          Having a backup node, which starts out to be standby and can also become active is confusing. Active and backup should just be states of the namenode it can transition back and forth. To this regard, I had many comments in HADOOP-4539 which introduced Backup node.

          Long term purpose of this change is, as described before, to make active and standby states of the namenode.

          I am open to doing all this work in HDFS-1623 branch.

          Show
          Suresh Srinivas added a comment - NameNode is the name of the daemon. Active and standby are the states of the a namenode. Having a backup node, which starts out to be standby and can also become active is confusing. Active and backup should just be states of the namenode it can transition back and forth. To this regard, I had many comments in HADOOP-4539 which introduced Backup node. Long term purpose of this change is, as described before, to make active and standby states of the namenode. I am open to doing all this work in HDFS-1623 branch.
          Hide
          Konstantin Shvachko added a comment -

          Could you please clarify your terminology. What is a daemon, a role, and a state?

          We used to say that we start NameNode in active, backup, or checkpoint role. Active is the default, if you do not specify the role. The command is:
          hadoop namenode -backup
          Don't see any confusion here.
          Same with standby. It is a role of the NameNode. You can go from standby to active. And may be vice versa at some point.

          Do you want to change this terminology. How? Why?
          Seems like you want to introduce a state in addition to the role, so that a daemon in role NN could have two states active and standby. This IS really confusing to me.

          Show
          Konstantin Shvachko added a comment - Could you please clarify your terminology. What is a daemon, a role, and a state? We used to say that we start NameNode in active, backup, or checkpoint role. Active is the default, if you do not specify the role. The command is: hadoop namenode -backup Don't see any confusion here. Same with standby. It is a role of the NameNode. You can go from standby to active. And may be vice versa at some point. Do you want to change this terminology. How? Why? Seems like you want to introduce a state in addition to the role, so that a daemon in role NN could have two states active and standby. This IS really confusing to me.
          Hide
          Suresh Srinivas added a comment -

          Seems like you want to introduce a state in addition to the role, so that a daemon in role NN could have two states active and standby. This IS really confusing to me.

          I am not sure what the confusion is. Active and standby are truly states of the namenode. Depending on the state a namenode is in, the same process/daemon performs different function. It can change this state during failover without restarting. Irrespective of which state it is in, it is still the namenode.

          We used to say that we start NameNode in active, backup, or checkpoint role. Active is the default, if you do not specify the role.

          Just because checkpoint or backup used Namenode code, they are not namenodes. They provide entirely different functionality from namenode. Without a restart they cannot take over the role of the namenode (at least currently!). Hence they are roles a process/daemon started with and not the states.

          I had commented in HADOOP-4529 about not making a separate class for BackupNode. What I am proposing is:
          NameNode running as active or standby. One single code base for Namenode with just two states.

          This is different from:
          Namenode running as active or goes back to safemode and BackupNode running as backup or active, as done in HDFS-2064. These are issues I see:

          1. Unnecessary duplication of "active" state code between Namenode and BackupNode.
          2. If you also support the functionality of Namenode going from active to standby (currently HDFS-2064 does not), duplication of "backup" state code between Namenode and BackupNode.

          That leaves me a question - what is BackupNode? Why should it be distinct from Namenode.

          Show
          Suresh Srinivas added a comment - Seems like you want to introduce a state in addition to the role, so that a daemon in role NN could have two states active and standby. This IS really confusing to me. I am not sure what the confusion is. Active and standby are truly states of the namenode. Depending on the state a namenode is in, the same process/daemon performs different function. It can change this state during failover without restarting. Irrespective of which state it is in, it is still the namenode. We used to say that we start NameNode in active, backup, or checkpoint role. Active is the default, if you do not specify the role. Just because checkpoint or backup used Namenode code, they are not namenodes. They provide entirely different functionality from namenode. Without a restart they cannot take over the role of the namenode (at least currently!). Hence they are roles a process/daemon started with and not the states. I had commented in HADOOP-4529 about not making a separate class for BackupNode. What I am proposing is: NameNode running as active or standby. One single code base for Namenode with just two states. This is different from: Namenode running as active or goes back to safemode and BackupNode running as backup or active, as done in HDFS-2064 . These are issues I see: Unnecessary duplication of "active" state code between Namenode and BackupNode. If you also support the functionality of Namenode going from active to standby (currently HDFS-2064 does not), duplication of "backup" state code between Namenode and BackupNode. That leaves me a question - what is BackupNode? Why should it be distinct from Namenode.
          Hide
          Sanjay Radia added a comment -

          Konstantine, what is the difference between backup and standby from your perspective.

          >We used to say that we start NameNode in active, backup, or checkpoint role.
          The original NN was not designed with HA in mind. They were roles and once the process/daemon is started its role does not change.

          In HA howerver, the process/daemon will change its state from standby to active and from active to standby.
          Further, in standby state, the NN can use one of two techniques to keep in sync with the active NN: via shared storage (as in Avatar) or via the reading from an edits stream directly form the active. Both are valid approaches.

          Hence:

          1. A NN running as active
          2. A NN running as standby and it keeps in sync with the active using one of two methods
            • a) syncing from the active via shared storage
            • b) syncing from the active via direct edits stream (as done in the backup NN code)

          You seem to suggest that backup NN is the only way to be in standby mode i.e. 2b; but 2a is an equally valid
          way to perfrom the standby function.

          The HA community calls "active' and 'standby" as states not as roles because there is state machine with
          state transitions from active to standby and standby to active. But this is a terminology issue of whether or not to call these things roles, states or modes.
          The checkpointer is a different beast - it is not really a NN - current checkpointer uses the NN code
          but can never become a NN. But backup NN code can perform the checkpointing function as side benefit.

          Show
          Sanjay Radia added a comment - Konstantine, what is the difference between backup and standby from your perspective. >We used to say that we start NameNode in active, backup, or checkpoint role. The original NN was not designed with HA in mind. They were roles and once the process/daemon is started its role does not change. In HA howerver, the process/daemon will change its state from standby to active and from active to standby. Further, in standby state, the NN can use one of two techniques to keep in sync with the active NN: via shared storage (as in Avatar) or via the reading from an edits stream directly form the active. Both are valid approaches. Hence: A NN running as active A NN running as standby and it keeps in sync with the active using one of two methods a) syncing from the active via shared storage b) syncing from the active via direct edits stream (as done in the backup NN code) You seem to suggest that backup NN is the only way to be in standby mode i.e. 2b; but 2a is an equally valid way to perfrom the standby function. The HA community calls "active' and 'standby" as states not as roles because there is state machine with state transitions from active to standby and standby to active. But this is a terminology issue of whether or not to call these things roles, states or modes. The checkpointer is a different beast - it is not really a NN - current checkpointer uses the NN code but can never become a NN. But backup NN code can perform the checkpointing function as side benefit.
          Hide
          Todd Lipcon added a comment -

          Having just worked on some code in the BN recently, I agree with Suresh. The inheritance structure is error prone here and has resulted in bugs. For example, in trunk today, "hadoop fs -ls" against a BackupNode succeeds, whereas "hadoop fs -stat" or any other read operations fails with an exception that the BN does not support these operations. This is because of the inheritance structure - it's too easy to modify the NN in such a way that introduces issues in the BN (the "fragile base class" issue)

          Show
          Todd Lipcon added a comment - Having just worked on some code in the BN recently, I agree with Suresh. The inheritance structure is error prone here and has resulted in bugs. For example, in trunk today, "hadoop fs -ls" against a BackupNode succeeds, whereas "hadoop fs -stat" or any other read operations fails with an exception that the BN does not support these operations. This is because of the inheritance structure - it's too easy to modify the NN in such a way that introduces issues in the BN (the "fragile base class" issue)
          Hide
          Konstantin Shvachko added a comment -

          Guys, you are changing the meaning of the role and calling it state. I intentionally tried to avoid using "state" while designing BackupNode, because word state is highly overloaded.
          Yes original NameNode was not designed for HA, but BackupNode was. Therefore the roles.

          Please read here:
          "Standby node (SN) - a name-node in "standby" state.
          Standby is a backup node, which is able to take over the active role if the current active fails."

          Role is not a name of the daemon its the what defines the functionality of NN. NN functions as single active node, but cannot checkpoint. BN keeps the copy of the namepsace, but cannot turn into standby. CN creates checkpoints but does not keep the namespace. SBN can turn into Active.
          What is wrong with current terminology and why it needs to be changed?

          Todd, could we please stay on the topic and not diverge to inheritance issues. I agree NN should evolve into a single class for all nodes, but lets do it somewhere else.

          Show
          Konstantin Shvachko added a comment - Guys, you are changing the meaning of the role and calling it state. I intentionally tried to avoid using "state" while designing BackupNode, because word state is highly overloaded. Yes original NameNode was not designed for HA, but BackupNode was. Therefore the roles. Please read here: " Standby node (SN) - a name-node in "standby" state. Standby is a backup node, which is able to take over the active role if the current active fails." Role is not a name of the daemon its the what defines the functionality of NN. NN functions as single active node, but cannot checkpoint. BN keeps the copy of the namepsace, but cannot turn into standby. CN creates checkpoints but does not keep the namespace. SBN can turn into Active. What is wrong with current terminology and why it needs to be changed? Todd, could we please stay on the topic and not diverge to inheritance issues. I agree NN should evolve into a single class for all nodes, but lets do it somewhere else.
          Hide
          Suresh Srinivas added a comment -

          > Guys, you are changing the meaning of the role and calling it state. I intentionally tried to avoid using "state" while designing BackupNode, because word state is highly overloaded.
          I think state is more appropriate word - from state machines perspective. What I am building is indeed state machine for HA.

          > Todd, could we please stay on the topic and not diverge to inheritance issues. I agree NN should evolve into a single class for all nodes, but lets do it somewhere else.
          This is what I intend to do by introducing states in NameNode. Role as an abstraction, in my opinion, is what caused the inheritance mess.

          Show
          Suresh Srinivas added a comment - > Guys, you are changing the meaning of the role and calling it state. I intentionally tried to avoid using "state" while designing BackupNode, because word state is highly overloaded. I think state is more appropriate word - from state machines perspective. What I am building is indeed state machine for HA. > Todd, could we please stay on the topic and not diverge to inheritance issues. I agree NN should evolve into a single class for all nodes, but lets do it somewhere else. This is what I intend to do by introducing states in NameNode. Role as an abstraction, in my opinion, is what caused the inheritance mess.
          Hide
          Konstantin Shvachko added a comment -

          1. What state machine? A two state machine? Do you plan to share the design?

          2. Yes Role is an abstraction of the role the NameNode currently plays, that is which set of functions it can or cannot perform. There could be states that transition from one role to another (I am guessing without the design).

          3. You are not answering my questions, it is hard to discuss that way. I asked:
          "What is wrong with current terminology and why it needs to be changed?"

          Show
          Konstantin Shvachko added a comment - 1. What state machine? A two state machine? Do you plan to share the design? 2. Yes Role is an abstraction of the role the NameNode currently plays, that is which set of functions it can or cannot perform. There could be states that transition from one role to another (I am guessing without the design). 3. You are not answering my questions, it is hard to discuss that way. I asked: "What is wrong with current terminology and why it needs to be changed?"
          Hide
          Suresh Srinivas added a comment -

          Let me answer it in different order:

          "What is wrong with current terminology and why it needs to be changed?"

          Current NameNode roles are ACTIVE, STANDBY, BACKUP and CHECKPOINT

          Are all these namenodes? If there is STANDBY already what is the role of BACKUP? In my terminology, CHECKPOINT would not be a state, do you allow any of the roles to transition to CHECKPOINT? ACTIVE and STANDBY are the states related to HA. The others are related to functionality provided by a process. There is no reason to mix the two.

          What state machine? A two state machine? Do you plan to share the design?

          Please see HDFS-1974. I will add design details soon. But the initial version of the patch should give you an idea. Currently it has two states - Active and Standby.

          Show
          Suresh Srinivas added a comment - Let me answer it in different order: "What is wrong with current terminology and why it needs to be changed?" Current NameNode roles are ACTIVE, STANDBY, BACKUP and CHECKPOINT Are all these namenodes? If there is STANDBY already what is the role of BACKUP? In my terminology, CHECKPOINT would not be a state, do you allow any of the roles to transition to CHECKPOINT? ACTIVE and STANDBY are the states related to HA. The others are related to functionality provided by a process. There is no reason to mix the two. What state machine? A two state machine? Do you plan to share the design? Please see HDFS-1974 . I will add design details soon. But the initial version of the patch should give you an idea. Currently it has two states - Active and Standby.
          Hide
          Konstantin Shvachko added a comment -

          Here is another citation from the document we both authored:
          "The NameNode in HDFS, in addition to its primary role serving client requests, can alternatively execute either of two other roles, either a CheckpointNode or a BackupNode. The role is specified at the node startup..." Go to Chapter 9.2.5.

          > Are all these namenodes? If there is STANDBY already what is the role of BACKUP?

          Yes they are all NameNodes according to the definition we just published this month.
          The role of BackupNode is to keep the up-to-date namespace in memory, serve read requests and make checkpoints.
          Standby does not currently exist. You know all of it.

          So I would propose to keep the roles as they are and introduce states when necessary, provided the documentation is in place. Building a machine handling 2 states sounds unreasonable.

          Can you live with roles, without renaming 2 of them into states? I think it is an unnecessary change in terminology, which involved code change.

          Show
          Konstantin Shvachko added a comment - Here is another citation from the document we both authored: " The NameNode in HDFS, in addition to its primary role serving client requests, can alternatively execute either of two other roles, either a CheckpointNode or a BackupNode. The role is specified at the node startup... " Go to Chapter 9.2.5. > Are all these namenodes? If there is STANDBY already what is the role of BACKUP? Yes they are all NameNodes according to the definition we just published this month. The role of BackupNode is to keep the up-to-date namespace in memory, serve read requests and make checkpoints. Standby does not currently exist. You know all of it. So I would propose to keep the roles as they are and introduce states when necessary, provided the documentation is in place. Building a machine handling 2 states sounds unreasonable. Can you live with roles, without renaming 2 of them into states? I think it is an unnecessary change in terminology, which involved code change.
          Hide
          Suresh Srinivas added a comment -

          > "The NameNode in HDFS, in addition to its primary role serving client requests, can alternatively execute either of two other roles, either a CheckpointNode or a BackupNode. The role is specified at the node startup..." Go to Chapter 9.2.5.
          First, this is before HA. Second, I do not parse role as strictly as you are.

          > Can you live with roles, without renaming 2 of them into states? I think it is an unnecessary change in terminology, which involved code change.
          I prefer states, because these are truly states. I associate more permanent association of a process to a role, unlike state changes. As a product evolves, things change. It would be better to use the correct abstractions than try to keep a doc from getting outdated.

          Show
          Suresh Srinivas added a comment - > "The NameNode in HDFS, in addition to its primary role serving client requests, can alternatively execute either of two other roles, either a CheckpointNode or a BackupNode. The role is specified at the node startup..." Go to Chapter 9.2.5. First, this is before HA. Second, I do not parse role as strictly as you are. > Can you live with roles, without renaming 2 of them into states? I think it is an unnecessary change in terminology, which involved code change. I prefer states, because these are truly states. I associate more permanent association of a process to a role, unlike state changes. As a product evolves, things change. It would be better to use the correct abstractions than try to keep a doc from getting outdated.
          Hide
          Sanjay Radia added a comment -

          >SBN can turn into Active.
          Looks like you have BN and SBN and perhaps ABN when the SBN turns active.

          Both ABN and Active NN both provide the same active function. This seems confusing.

          Also you forgot to respond to
          >You seem to suggest that backup NN is the only way to be in standby mode i.e. 2b; but 2a is an equally valid
          >way to perfrom the standby function.

          There is another service where a standby reads edits from shared storage.

          Let me use a neutral term for the purposes of this discussion (I will call this mode for this discussion - we can then we can decide the terminology about whether to call this role or state or something else).

          1. Mode Active: A NN running as active
          2. Mode Standby: A NN running as standby and it keeps in sync with the active using one of two methods
            • a) syncing from the active via shared storage
            • b) syncing from the active via direct edits stream (as done in the backup NN code)

          NN in standby mode has to run a special service to keep its state hot = it uses (2a) or (2b).
          A NN in standby in 2b can run a special service called checkpoint if one desires.

          A Datanode or Checkpointer is not NN mode or even a Namenode.

          Show
          Sanjay Radia added a comment - >SBN can turn into Active. Looks like you have BN and SBN and perhaps ABN when the SBN turns active. Both ABN and Active NN both provide the same active function. This seems confusing. Also you forgot to respond to >You seem to suggest that backup NN is the only way to be in standby mode i.e. 2b; but 2a is an equally valid >way to perfrom the standby function. There is another service where a standby reads edits from shared storage. Let me use a neutral term for the purposes of this discussion (I will call this mode for this discussion - we can then we can decide the terminology about whether to call this role or state or something else). Mode Active: A NN running as active Mode Standby: A NN running as standby and it keeps in sync with the active using one of two methods a) syncing from the active via shared storage b) syncing from the active via direct edits stream (as done in the backup NN code) NN in standby mode has to run a special service to keep its state hot = it uses (2a) or (2b). A NN in standby in 2b can run a special service called checkpoint if one desires. A Datanode or Checkpointer is not NN mode or even a Namenode.
          Hide
          Sanjay Radia added a comment -

          I hit "add" a little too fast.
          Let us first agree on the various modes then decide whether we should call it mode, role or state.

          I also like the notion that a NN runs a set of services depending on the "mode" it is in (responding to
          client requests, getting edits state from disk or another NN, etc.

          Show
          Sanjay Radia added a comment - I hit "add" a little too fast. Let us first agree on the various modes then decide whether we should call it mode, role or state. I also like the notion that a NN runs a set of services depending on the "mode" it is in (responding to client requests, getting edits state from disk or another NN, etc.
          Hide
          Konstantin Shvachko added a comment -

          > Looks like you have BN and SBN and perhaps ABN when the SBN turns active.

          In my terminology there is only one NameNode. And it can have different roles ACTIVE, BACKUP, STANDBY.

          >You seem to suggest that backup NN is the only way to be in standby mode

          I do not suggest that. Both 2a and 2b are valid for NN in standby mode (or role as we used to call it).

          > Checkpointer is not NN mode or even a Namenode.

          Why not? It is a very rudimentary NN that can read image and edits, temporary create the namespace structure in RAM same as on NN, and then write it back to disk.

          > I also like the notion that a NN runs a set of services depending on the "mode".

          I like that too. So the NN in standby mode will run a journal digestion service, may run checkpoint service, but will not run lease recovery or block replication services. And NN in active mode is not allowed to run the checkpoint service.

          Can we keep the word "role" for that?

          Show
          Konstantin Shvachko added a comment - > Looks like you have BN and SBN and perhaps ABN when the SBN turns active. In my terminology there is only one NameNode. And it can have different roles ACTIVE, BACKUP, STANDBY. >You seem to suggest that backup NN is the only way to be in standby mode I do not suggest that. Both 2a and 2b are valid for NN in standby mode (or role as we used to call it). > Checkpointer is not NN mode or even a Namenode. Why not? It is a very rudimentary NN that can read image and edits, temporary create the namespace structure in RAM same as on NN, and then write it back to disk. > I also like the notion that a NN runs a set of services depending on the "mode". I like that too. So the NN in standby mode will run a journal digestion service, may run checkpoint service, but will not run lease recovery or block replication services. And NN in active mode is not allowed to run the checkpoint service. Can we keep the word "role" for that?

            People

            • Assignee:
              Suresh Srinivas
              Reporter:
              Suresh Srinivas
            • Votes:
              0 Vote for this issue
              Watchers:
              7 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development