[
https://issues.apache.org/jira/browse/HADOOP-8468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13295990#comment-13295990
]
Konstantin Shvachko commented on HADOOP-8468:
---------------------------------------------
Sorry, got distracted with the Hadoop event of the week.
Here is current replication policy.
0. No more than one replica is placed at any one node
1. First replica on the local node
2. Second and third replicas on two different nodes in a different rack
3. Other replicas on random nodes with restriction that no more than two
replicas are placed in the same rack, if there is enough racks.
With my thinking that the virtual node level is added, the policy remains
unchanged. With a single optional clarification:
(1) First replica on the virtual node then on the local node
With your approach of adding the hypervisor layer the policy need to be
revised, by replacing "node" with "node group".
So my motivation with virtual node extension is that _it formally inherits the
existing policy, but semantically adds a new level of topology_.
> Each VM on the same physical machine plays independently
As you correctly mention in the design doc, topology is about failure scenarios
rather than independence of VMs. VM-s are independent as the entities reporting
to the NameNode. But from the failure scenarios viewpoint they are bound to the
same node, meaning that node failure takes all of them down.
So the policy should not change, only the implementation of it should.
> VMs lives on the same physical machine can belong to different logical Hadoop
> clusters
Well you can run two DNs or TTs on the same node belonging to different
clusters even now, but nobody does that, because operationally it's just too
much hassle. Not sure if virtualization will make it different.
I heard of attempts to run multiple clusters on the same physical nodes for
isolation purposes, but didn't hear it was successful.
> Umbrella of enhancements to support different failure and locality topologies
> -----------------------------------------------------------------------------
>
> Key: HADOOP-8468
> URL: https://issues.apache.org/jira/browse/HADOOP-8468
> Project: Hadoop Common
> Issue Type: Bug
> Components: ha, io
> Affects Versions: 1.0.0, 2.0.0-alpha
> Reporter: Junping Du
> Assignee: Junping Du
> Priority: Critical
> Attachments: HADOOP-8468-total-v3.patch, HADOOP-8468-total.patch,
> Proposal for enchanced failure and locality topologies.pdf
>
>
> The current hadoop network topology (described in some previous issues like:
> Hadoop-692) works well in classic three-tiers network when it comes out.
> However, it does not take into account other failure models or changes in the
> infrastructure that can affect network bandwidth efficiency like:
> virtualization.
> Virtualized platform has following genes that shouldn't been ignored by
> hadoop topology in scheduling tasks, placing replica, do balancing or
> fetching block for reading:
> 1. VMs on the same physical host are affected by the same hardware failure.
> In order to match the reliability of a physical deployment, replication of
> data across two virtual machines on the same host should be avoided.
> 2. The network between VMs on the same physical host has higher throughput
> and lower latency and does not consume any physical switch bandwidth.
> Thus, we propose to make hadoop network topology extend-able and introduce a
> new level in the hierarchical topology, a node group level, which maps well
> onto an infrastructure that is based on a virtualized environment.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
