hadoop-common-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From ji...@apache.org
Subject [45/50] hadoop git commit: HDFS-8945. Update the description about replica placement in HDFS Architecture documentation. Contributed by Masatake Iwasaki.
Date Tue, 27 Oct 2015 21:47:56 GMT
HDFS-8945. Update the description about replica placement in HDFS Architecture documentation.
Contributed by Masatake Iwasaki.

Project: http://git-wip-us.apache.org/repos/asf/hadoop/repo
Commit: http://git-wip-us.apache.org/repos/asf/hadoop/commit/e8aefdf0
Tree: http://git-wip-us.apache.org/repos/asf/hadoop/tree/e8aefdf0
Diff: http://git-wip-us.apache.org/repos/asf/hadoop/diff/e8aefdf0

Branch: refs/heads/HDFS-8966
Commit: e8aefdf08bc79a0ad537c1b7a1dc288aabd399b9
Parents: 37bf614
Author: Andrew Wang <wang@apache.org>
Authored: Mon Oct 26 15:47:26 2015 -0700
Committer: Andrew Wang <wang@apache.org>
Committed: Mon Oct 26 15:47:59 2015 -0700

 hadoop-hdfs-project/hadoop-hdfs/CHANGES.txt      |  3 +++
 .../hadoop-hdfs/src/site/markdown/HdfsDesign.md  | 19 +++++++++++++++++++
 2 files changed, 22 insertions(+)

diff --git a/hadoop-hdfs-project/hadoop-hdfs/CHANGES.txt b/hadoop-hdfs-project/hadoop-hdfs/CHANGES.txt
index 55c77f8..478d48b 100644
--- a/hadoop-hdfs-project/hadoop-hdfs/CHANGES.txt
+++ b/hadoop-hdfs-project/hadoop-hdfs/CHANGES.txt
@@ -1578,6 +1578,9 @@ Release 2.8.0 - UNRELEASED
     HDFS-9291. Fix TestInterDatanodeProtocol to be FsDataset-agnostic. (lei)
+    HDFS-8945. Update the description about replica placement in HDFS
+    Architecture documentation. (Masatake Iwasaki via wang)
     HDFS-8026. Trace FSOutputSummer#writeChecksumChunks rather than

diff --git a/hadoop-hdfs-project/hadoop-hdfs/src/site/markdown/HdfsDesign.md b/hadoop-hdfs-project/hadoop-hdfs/src/site/markdown/HdfsDesign.md
index 5b1f66e..4c0d44e 100644
--- a/hadoop-hdfs-project/hadoop-hdfs/src/site/markdown/HdfsDesign.md
+++ b/hadoop-hdfs-project/hadoop-hdfs/src/site/markdown/HdfsDesign.md
@@ -121,8 +121,27 @@ A simple but non-optimal policy is to place replicas on unique racks.
This preve
 For the common case, when the replication factor is three, HDFS’s placement policy is to
put one replica on one node in the local rack, another on a different node in the local rack,
and the last on a different node in a different rack. This policy cuts the inter-rack write
traffic which generally improves write performance. The chance of rack failure is far less
than that of node failure; this policy does not impact data reliability and availability guarantees.
However, it does reduce the aggregate network bandwidth used when reading data since a block
is placed in only two unique racks rather than three. With this policy, the replicas of a
file do not evenly distribute across the racks. One third of replicas are on one node, two
thirds of replicas are on one rack, and the other third are evenly distributed across the
remaining racks. This policy improves write performance without compromising data reliability
or read performance.
+If the replication factor is greater than 3,
+the placement of the 4th and following replicas are determined randomly
+while keeping the number of replicas per rack below the upper limit
+(which is basically `(replicas - 1) / racks + 2`).
+Because the NameNode does not allow DataNodes to have multiple replicas of the same block,
+maximum number of replicas created is the total number of DataNodes at that time.
+After the support for
+[Storage Types and Storage Policies](ArchivalStorage.html) was added to HDFS,
+the NameNode takes the policy into account for replica placement
+in addition to the rack awareness described above.
+The NameNode chooses nodes based on rack awareness at first,
+then checks that the candidate node have storage required by the policy associated with the
+If the candidate node does not have the storage type, the NameNode looks for another node.
+If enough nodes to place replicas can not be found in the first path,
+the NameNode looks for nodes having fallback storage types in the second path.
 The current, default replica placement policy described here is a work in progress.
 ### Replica Selection
 To minimize global bandwidth consumption and read latency, HDFS tries to satisfy a read request
from a replica that is closest to the reader. If there exists a replica on the same rack as
the reader node, then that replica is preferred to satisfy the read request. If angg/ HDFS
cluster spans multiple data centers, then a replica that is resident in the local data center
is preferred over any remote replica.

View raw message