You are viewing a plain text version of this content. The canonical link for it is here.
Posted to yarn-issues@hadoop.apache.org by "Craig Welch (JIRA)" <ji...@apache.org> on 2014/07/08 20:59:05 UTC
[jira] [Commented] (YARN-1994) Expose YARN/MR endpoints on multiple
interfaces
[ https://issues.apache.org/jira/browse/YARN-1994?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14055314#comment-14055314 ]
Craig Welch commented on YARN-1994:
-----------------------------------
We plan for our approach to be similar to the hdfs approach - there will be a service level bind-host parameter per service, like this:
<property>
<name>yarn.resourcemanager.bind-host</name>
<value>0.0.0.0</value>
</property>
<property>
<name>yarn.nodemanager.bind-host</name>
<value>0.0.0.0</value>
</property>
this will control the address component of the binding for the listening processes for these services. Any address (ip or name) which the host running the service can map to one of it's interfaces would be valid, but it's expected that it will primarily be used to indicate the desire to listen on all interfaces, which the 0.0.0.0 value above will accomplish. Where .address values for service endpoints are configured in the yarn-site.conf the port values will be taken from there - if not specified the default ports will be used (this is to allow one bind specification for the multiple port-listeners of these services, rpc and webapp, etc).
For muti-homed host support this would need to be combined with dfs (hdfs) mutli-home configuration (see hdfs patches referenced above, there is an additional configuration required for hdfs, see below) and the hosts will need to resolve to the same name on each of the networks they are attached to. So, if a host was "hadoop1" on an internal network with address 10.0.0.22, which is the primary network where the cluster transfers it's data, etc, and there was a desire to support an external 10.0.1.* network for client access to submit jobs, talk to hdfs, view the management webapp pages, logs, etc, it would also need to resolve as "hadoop1" on that "management" network (say, 10.0.1.22 (though there is no reason the last value of the ip must be the same, it's only the case that the same name has to resolve properly on both networks, and where ever addresses for a host are specified in yarn-site.conf, etc, they must use that name, not a different name or an ip).
An hdfs-site.xml configuration is required for multi-home hdfs support in addition to the bind properties in the hdfs patches referenced above, it is:
<property>
<name>dfs.client.use.datanode.hostname</name>
<value>true</value>
</property>
> 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
>
> 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)