[
https://issues.apache.org/jira/browse/HADOOP-8468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13296139#comment-13296139
]
Junping Du commented on HADOOP-8468:
------------------------------------
Hi Konstantin,
That's good suggestions. Updated proposal should address most of them. A few
comments below:
> So my motivation with virtual node extension is that it formally inherits the
> existing policy, but semantically adds a new level of topology.
Agree. That's what I try to do previously also. :) The current way is mapping
node -> (virtual) node and add "nodegroup" level, so that policy is almost
exactly the same: 1st on local (virtual) node, 2nd on off-rack, 3rd on local
node of 2nd. The only difference is to make sure 2nd and 3rd are off-nodegroup
(and if 1st cannot be local(virtual) node, then can be nodegroup-local node).
> But from the failure scenarios viewpoint they are bound to the same node,
> meaning that node failure takes all of them down
Yes. So adding a node-group level should address the failure relationship
between (virtual) nodes perfectly. I think the key points for map current node
to vm level include:
Virtual node (VM) plays as leaf node. There are still failure only happens
within VM like daemon failure, os failure, and some physical failure (like:
disk failure, as in most cases for running hadoop, VM should mount separated
physical disks rather than sharing disk with other VM). So, VM still show some
independency even in failure group semantics.
Virtual node is where JVM is running and java network call happens. In current
code base, ip(hostname) of a node (reader, datanode) is used to keep data
locality. Only VM-level ip is easy to get by JVM and RPC call so that make
sense to represent node ip.
Thoughts?
> 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 (revised-1.0).pdf,
> 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
