[02/16] hadoop git commit: HDFS-8657. Update docs for mSNN. Contributed by Jesse Yates.
HDFS-8657. Update docs for mSNN. Contributed by Jesse Yates. Project: http://git-wip-us.apache.org/repos/asf/hadoop/repo Commit: http://git-wip-us.apache.org/repos/asf/hadoop/commit/ed01dc70 Tree: http://git-wip-us.apache.org/repos/asf/hadoop/tree/ed01dc70 Diff: http://git-wip-us.apache.org/repos/asf/hadoop/diff/ed01dc70 Branch: refs/heads/HADOOP-12111 Commit: ed01dc70b2f4ff4bdcaf71c19acf244da0868a82 Parents: e4f7562 Author: Aaron T. Myers a...@apache.org Authored: Mon Jul 20 16:40:06 2015 -0700 Committer: Aaron T. Myers a...@apache.org Committed: Mon Jul 20 16:40:06 2015 -0700 -- hadoop-hdfs-project/hadoop-hdfs/CHANGES.txt | 2 + .../markdown/HDFSHighAvailabilityWithNFS.md | 40 +++- .../markdown/HDFSHighAvailabilityWithQJM.md | 32 ++-- 3 files changed, 45 insertions(+), 29 deletions(-) -- http://git-wip-us.apache.org/repos/asf/hadoop/blob/ed01dc70/hadoop-hdfs-project/hadoop-hdfs/CHANGES.txt -- diff --git a/hadoop-hdfs-project/hadoop-hdfs/CHANGES.txt b/hadoop-hdfs-project/hadoop-hdfs/CHANGES.txt index 13d9969..cd32c0e 100644 --- a/hadoop-hdfs-project/hadoop-hdfs/CHANGES.txt +++ b/hadoop-hdfs-project/hadoop-hdfs/CHANGES.txt @@ -341,6 +341,8 @@ Trunk (Unreleased) HDFS-8627. NPE thrown if unable to fetch token from Namenode (J.Andreina via vinayakumarb) +HDFS-8657. Update docs for mSNN. (Jesse Yates via atm) + Release 2.8.0 - UNRELEASED NEW FEATURES http://git-wip-us.apache.org/repos/asf/hadoop/blob/ed01dc70/hadoop-hdfs-project/hadoop-hdfs/src/site/markdown/HDFSHighAvailabilityWithNFS.md -- diff --git a/hadoop-hdfs-project/hadoop-hdfs/src/site/markdown/HDFSHighAvailabilityWithNFS.md b/hadoop-hdfs-project/hadoop-hdfs/src/site/markdown/HDFSHighAvailabilityWithNFS.md index 626a473..cc53a38 100644 --- a/hadoop-hdfs-project/hadoop-hdfs/src/site/markdown/HDFSHighAvailabilityWithNFS.md +++ b/hadoop-hdfs-project/hadoop-hdfs/src/site/markdown/HDFSHighAvailabilityWithNFS.md @@ -65,18 +65,18 @@ This impacted the total availability of the HDFS cluster in two major ways: * Planned maintenance events such as software or hardware upgrades on the NameNode machine would result in windows of cluster downtime. -The HDFS High Availability feature addresses the above problems by providing the option of running two redundant NameNodes in the same cluster in an Active/Passive configuration with a hot standby. This allows a fast failover to a new NameNode in the case that a machine crashes, or a graceful administrator-initiated failover for the purpose of planned maintenance. +The HDFS High Availability feature addresses the above problems by providing the option of running two (or more, as of Hadoop 3.0.0) redundant NameNodes in the same cluster in an Active/Passive configuration with a hot standby(s). This allows a fast failover to a new NameNode in the case that a machine crashes, or a graceful administrator-initiated failover for the purpose of planned maintenance. Architecture -In a typical HA cluster, two separate machines are configured as NameNodes. At any point in time, exactly one of the NameNodes is in an *Active* state, and the other is in a *Standby* state. The Active NameNode is responsible for all client operations in the cluster, while the Standby is simply acting as a slave, maintaining enough state to provide a fast failover if necessary. +In a typical HA cluster, two or more separate machines are configured as NameNodes. At any point in time, exactly one of the NameNodes is in an *Active* state, and the others are in a *Standby* state. The Active NameNode is responsible for all client operations in the cluster, while the Standby is simply acting as a slave, maintaining enough state to provide a fast failover if necessary. -In order for the Standby node to keep its state synchronized with the Active node, the current implementation requires that the two nodes both have access to a directory on a shared storage device (eg an NFS mount from a NAS). This restriction will likely be relaxed in future versions. +In order for the Standby nodes to keep their state synchronized with the Active node, the current implementation requires that the nodes have access to a directory on a shared storage device (eg an NFS mount from a NAS). This restriction will likely be relaxed in future versions. -When any namespace modification is performed by the Active node, it durably logs a record of the modification to an edit log file stored in the shared directory. The Standby node is constantly watching this directory for edits, and as it sees the edits, it applies them to its own namespace. In the event of a failover, the Standby will
hadoop git commit: HDFS-8657. Update docs for mSNN. Contributed by Jesse Yates.
Repository: hadoop Updated Branches: refs/heads/trunk e4f756260 - ed01dc70b HDFS-8657. Update docs for mSNN. Contributed by Jesse Yates. Project: http://git-wip-us.apache.org/repos/asf/hadoop/repo Commit: http://git-wip-us.apache.org/repos/asf/hadoop/commit/ed01dc70 Tree: http://git-wip-us.apache.org/repos/asf/hadoop/tree/ed01dc70 Diff: http://git-wip-us.apache.org/repos/asf/hadoop/diff/ed01dc70 Branch: refs/heads/trunk Commit: ed01dc70b2f4ff4bdcaf71c19acf244da0868a82 Parents: e4f7562 Author: Aaron T. Myers a...@apache.org Authored: Mon Jul 20 16:40:06 2015 -0700 Committer: Aaron T. Myers a...@apache.org Committed: Mon Jul 20 16:40:06 2015 -0700 -- hadoop-hdfs-project/hadoop-hdfs/CHANGES.txt | 2 + .../markdown/HDFSHighAvailabilityWithNFS.md | 40 +++- .../markdown/HDFSHighAvailabilityWithQJM.md | 32 ++-- 3 files changed, 45 insertions(+), 29 deletions(-) -- http://git-wip-us.apache.org/repos/asf/hadoop/blob/ed01dc70/hadoop-hdfs-project/hadoop-hdfs/CHANGES.txt -- diff --git a/hadoop-hdfs-project/hadoop-hdfs/CHANGES.txt b/hadoop-hdfs-project/hadoop-hdfs/CHANGES.txt index 13d9969..cd32c0e 100644 --- a/hadoop-hdfs-project/hadoop-hdfs/CHANGES.txt +++ b/hadoop-hdfs-project/hadoop-hdfs/CHANGES.txt @@ -341,6 +341,8 @@ Trunk (Unreleased) HDFS-8627. NPE thrown if unable to fetch token from Namenode (J.Andreina via vinayakumarb) +HDFS-8657. Update docs for mSNN. (Jesse Yates via atm) + Release 2.8.0 - UNRELEASED NEW FEATURES http://git-wip-us.apache.org/repos/asf/hadoop/blob/ed01dc70/hadoop-hdfs-project/hadoop-hdfs/src/site/markdown/HDFSHighAvailabilityWithNFS.md -- diff --git a/hadoop-hdfs-project/hadoop-hdfs/src/site/markdown/HDFSHighAvailabilityWithNFS.md b/hadoop-hdfs-project/hadoop-hdfs/src/site/markdown/HDFSHighAvailabilityWithNFS.md index 626a473..cc53a38 100644 --- a/hadoop-hdfs-project/hadoop-hdfs/src/site/markdown/HDFSHighAvailabilityWithNFS.md +++ b/hadoop-hdfs-project/hadoop-hdfs/src/site/markdown/HDFSHighAvailabilityWithNFS.md @@ -65,18 +65,18 @@ This impacted the total availability of the HDFS cluster in two major ways: * Planned maintenance events such as software or hardware upgrades on the NameNode machine would result in windows of cluster downtime. -The HDFS High Availability feature addresses the above problems by providing the option of running two redundant NameNodes in the same cluster in an Active/Passive configuration with a hot standby. This allows a fast failover to a new NameNode in the case that a machine crashes, or a graceful administrator-initiated failover for the purpose of planned maintenance. +The HDFS High Availability feature addresses the above problems by providing the option of running two (or more, as of Hadoop 3.0.0) redundant NameNodes in the same cluster in an Active/Passive configuration with a hot standby(s). This allows a fast failover to a new NameNode in the case that a machine crashes, or a graceful administrator-initiated failover for the purpose of planned maintenance. Architecture -In a typical HA cluster, two separate machines are configured as NameNodes. At any point in time, exactly one of the NameNodes is in an *Active* state, and the other is in a *Standby* state. The Active NameNode is responsible for all client operations in the cluster, while the Standby is simply acting as a slave, maintaining enough state to provide a fast failover if necessary. +In a typical HA cluster, two or more separate machines are configured as NameNodes. At any point in time, exactly one of the NameNodes is in an *Active* state, and the others are in a *Standby* state. The Active NameNode is responsible for all client operations in the cluster, while the Standby is simply acting as a slave, maintaining enough state to provide a fast failover if necessary. -In order for the Standby node to keep its state synchronized with the Active node, the current implementation requires that the two nodes both have access to a directory on a shared storage device (eg an NFS mount from a NAS). This restriction will likely be relaxed in future versions. +In order for the Standby nodes to keep their state synchronized with the Active node, the current implementation requires that the nodes have access to a directory on a shared storage device (eg an NFS mount from a NAS). This restriction will likely be relaxed in future versions. -When any namespace modification is performed by the Active node, it durably logs a record of the modification to an edit log file stored in the shared directory. The Standby node is constantly watching this directory for edits, and as it sees the edits, it applies
