hadoop-hdfs-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Todd Lipcon (Commented) (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HDFS-3148) The client should be able to use multiple local interfaces for data transfer
Date Sat, 31 Mar 2012 23:06:29 GMT

    [ https://issues.apache.org/jira/browse/HDFS-3148?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13243592#comment-13243592

Todd Lipcon commented on HDFS-3148:

- I think it makes more sense to make {{getLocalInterfaceAddrs}} static, and take {{localInterfaces}}
as a parameter. 

+  public static final String  DFS_CLIENT_LOCAL_INTERFACES = "dfs.client.local.interfaces";
Move this higher in the file, near the other DFS_CLIENT configs

+    final int idx = r.nextInt(localInterfaceAddrs.length);
+    final SocketAddress addr = localInterfaceAddrs[idx];
+    if (LOG.isDebugEnabled()) {
+      LOG.debug("Using local interface " + localInterfaces[idx] + " " + addr);
This doesn't seem right, since {{localInterfaces}} and {{localInterfaceAddrs}} may have different
lengths -- a given configured local interface could have multiple addrs  in the {{localInterfaceAddrs}}

This brings up another question: if a NIC has multiple IPs, should it be weighted in the load
balancing based on the number of IPs assigned? That doesn't seem right.

Maybe the right solution to both of these issues is to actually require that the list of addresses
decided upon has at most one IP corresponding to each device?

Another possibility is that you could change the member variable to a MultiMap<String,
SocketAddress> -- first randomly choose a key from the map, and then randomly choose among
that key's values. My hunch is this would give the right behavior most of the time.

+  <description>A comma separate list of network interface names to use
+    for data transfer between the client and datanodes. When creating
typo: comma separate*d* list

> The client should be able to use multiple local interfaces for data transfer
> ----------------------------------------------------------------------------
>                 Key: HDFS-3148
>                 URL: https://issues.apache.org/jira/browse/HDFS-3148
>             Project: Hadoop HDFS
>          Issue Type: Sub-task
>          Components: hdfs client
>            Reporter: Eli Collins
>            Assignee: Eli Collins
>         Attachments: hdfs-3148-b1.txt, hdfs-3148.txt
> HDFS-3147 covers using multiple interfaces on the server (Datanode) side. Clients should
also be able to utilize multiple *local* interfaces for outbound connections instead of always
using the interface for the local hostname. This can be accomplished with a new configuration
parameter ({{dfs.client.local.interfaces}}) that accepts a list of interfaces the client should
use. Acceptable configuration values are the same as the {{dfs.datanode.available.interfaces}}
parameter. The client binds its socket to a specific interface, which enables outbound traffic
to use that interface. Binding the client socket to a specific address is not sufficient to
ensure egress traffic uses that interface. Eg if multiple interfaces are on the same subnet
the host requires IP rules that use the source address (which bind sets) to select the destination
interface. The SO_BINDTODEVICE socket option could be used to select a specific interface
for the connection instead, however it requires JNI (is not in Java's SocketOptions) and root
access, which we don't want to require clients have.
> Like HDFS-3147, the client can use multiple local interfaces for data transfer. Since
the client already cache their connections to DNs choosing a local interface at random seems
like a good policy. Users can also pin a specific client to a specific interface by specifying
just that interface in dfs.client.local.interfaces.
> This change was discussed in HADOOP-6210 a while back, and is actually useful/independent
of the other HDFS-3140 changes.

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


View raw message