hadoop-common-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Konstantin Shvachko (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HADOOP-8468) Umbrella of enhancements to support different failure and locality topologies
Date Fri, 15 Jun 2012 23:04:43 GMT

    [ 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

        

Mime
View raw message