hadoop-yarn-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Milan Potocnik (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (YARN-1994) Expose YARN/MR endpoints on multiple interfaces
Date Tue, 29 Jul 2014 19:42:40 GMT

    [ https://issues.apache.org/jira/browse/YARN-1994?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14078240#comment-14078240
] 

Milan Potocnik commented on YARN-1994:
--------------------------------------

Hi [~cwelch], [~arpitagarwal],

I think some clarification is needed here. Initial reason we wanted to introduce _BIND_HOST
options was to provide deterministic behaviors when clients try to connect to a service endpoint
which is listening on all interfaces (0.0.0.0). In short, _BIND_HOST is what services use
to bind, _ADDRESS is what clients should use to connect. This way, everything is deterministic.

In Multi NIC environments, with default implementation, calls to conf.updateConnectAddress
for 0.0.0.0 address would eventually call InetSocketAddress.getHostName(). In MultiNIC environments,
this can introduce non-deterministic behavior. Imagine you have DNS entries for each of the
network interfaces and although you bind your service endpoint to all of them, you want users
to use a specific one (for instance, InfiniBand for better performance). InetSocketAddress.getHostName()
will return just the machine's hostname which will usually resolve to some random network
interface of the service when the client resolves it. Although service binds to 0.0.0.0, some
interfaces might be disabled by firewall.

This is why besides RPCUtil.getSocketAddress, we also need RPCUtil.updateConnectAddr to explicitly
specify connect address which clients should use, i.e. a DNS entry pointing to a specific
interface.

There are also two cases in the code, where current implementation does not work in MultiNIC
environments which we fixed:
- MRClientService & TaskAttemptListenerImpl where we had to propagate NM hostname through
context,
- which is set in ContainerManagerImpl via NodeId from YarnConfiguration.NM_ADDRESS (the logic
Arpit mentioned in the comment)

Please have a look the the patch version 5, for easier understanding.

Hope this clarifies the initial idea.

Thanks,
Milan


> Expose YARN/MR endpoints on multiple interfaces
> -----------------------------------------------
>
>                 Key: YARN-1994
>                 URL: https://issues.apache.org/jira/browse/YARN-1994
>             Project: Hadoop YARN
>          Issue Type: Improvement
>          Components: nodemanager, resourcemanager, webapp
>    Affects Versions: 2.4.0
>            Reporter: Arpit Agarwal
>            Assignee: Craig Welch
>         Attachments: YARN-1994.0.patch, YARN-1994.1.patch, YARN-1994.11.patch, YARN-1994.11.patch,
YARN-1994.12.patch, YARN-1994.2.patch, YARN-1994.3.patch, YARN-1994.4.patch, YARN-1994.5.patch,
YARN-1994.6.patch, YARN-1994.7.patch
>
>
> YARN and MapReduce daemons currently do not support specifying a wildcard address for
the server endpoints. This prevents the endpoints from being accessible from all interfaces
on a multihomed machine.
> Note that if we do specify INADDR_ANY for any of the options, it will break clients as
they will attempt to connect to 0.0.0.0. We need a solution that allows specifying a hostname
or IP-address for clients while requesting wildcard bind for the servers.
> (List of endpoints is in a comment below)



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Mime
View raw message