[
https://issues.apache.org/jira/browse/HADOOP-8468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13291638#comment-13291638
]
Junping Du commented on HADOOP-8468:
------------------------------------
Hey Konstantin, Thanks for a lot of good suggestions here.
For 1. In concept, there are two ways to look at the change we proposed. One
way is like you said, we add vm level extension to physical host (but make
physical host to be innernode, but not leaf any more.). The other way is: we
look at VM (virtual node) as previous physical node as container of processes
but add an innernode layer between node and rack. We are preferring the second
way as following reasons:
1) Each VM on the same physical machine plays independently in general but
have some relations on reliability and lower communication overhead. Each VM
has independent hostname, ip and it is the place where hadoop daemons running.
2) VMs lives on the same physical machine can belong to different logical
hadoop clusters, physical host is not like before that can only be dedicated to
one logical hadoop cluster but could be shared. Also, physical host's ip and
host info (hypervisor's ip and info) should not be aware by hadoop.
3) In some data locality related policies, VM map to previous physical node
well as the first choice to place 1st replica, scheduling task, etc.
For 2. It's right that VMs on the same host will not share storage directly but
could do so (with getting virtual disks) through Hypervisor FS (Like VMFS in
VMware vSphere) layer. Another way (should recommend for hadoop case) is to go
through RDM (Raw Disk Mapping) configuration in hypervisor that each VM can get
some dedicated physical disks. In both cases, the virtual disk drive (and its
capacity) for each VM are independent and can be reported by DN without any
overlapping.
For 3. Yes. It looks we are missing replica removal policy in proposal. I will
revise it as your suggestion. Thanks!
For 4. YARN is doing good job in resolving fixed task slot issue that exists in
MRv1. Besides resolving this issue in MRv1, it still have some scenarios to run
multiple VMs per physical node, like: tenant's task isolation in vm level,
separation data node and compute node to support hadoop MapReduce(YARN) cluster
auto scale in and out, support standard-customised nodes (as a requirement of
cloud) in a heterogeneous hardware environment, etc.
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.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
