Mailing-List: contact yarn-issues-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: yarn-issues@hadoop.apache.org
Date: Tue, 29 Jul 2014 19:42:40 +0000 (UTC)
From: "Milan Potocnik (JIRA)" <jira@apache.org>
To: yarn-issues@hadoop.apache.org
Message-ID: <JIRA.12711064.1398730602858.68427.1406662960820@arcas>
In-Reply-To: <JIRA.12711064.1398730602858@arcas>
References: <JIRA.12711064.1398730602858@arcas>
Subject: [jira] [Commented] (YARN-1994) Expose YARN/MR endpoints on multiple
 interfaces
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ 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)