Where is the setting for the port-range used by org.apache.hadoop.mapred.YarnChild?

[#1]

org.apache.hadoop.mapred.YarnChild.main(YarnChild.java:136)

I have tried setting yarn.app.mapreduce.am.job.client.port-range to a specific range, but it doesn't look like that is the right setting.

I have seen it use ports ranging from 32000 - 65000

CDH 5.1

[#2]

From what I have seen these are IPC ephemeral ports.

Is there anyway to control the range on these?

[#3]

General ephemeral port ranges can be controlled from the OS side, but I've hardly ever seen a need to be doing such a thing. What is your exact issue or situation that is leading you down this path?

[#4]

Simple. We need communication ports between an external cluster and internal Informatica server to be predictable because there's a strict firewall in place. So we need some way to make sure only a known set of ports is used for communication between client and cluster.

[#5]

Thank you for explaining the need Rmutsaers!

The AM's IPC port is indeed used directly by clients and are controllable on the serving AM via the yarn.app.mapreduce.am.job.client.port-range config. It still has to be a range though, and the range must be chosen by keeping in mind that it will also effectively limit the number of AMs you can run on the host.

The AM's web port is also served on an ephemeral port, but this is a non-concern cause clients do not access the AM web port directly; they go via the RM's proxy service (wherein the RM makes the GET HTTP requests to the actual AM port, within the cluster).

Does yarn.app.mapreduce.am.job.client.port-range not solve your need? There's no IPC proxying today to eliminate the range requirement, unfortunately. The con of not having the IPC port ranges open is not too fatal, as the job can still get a completed notification once it gets moved to the job history server (and the RM redirects the client to it).

[#6]

Thanks, i'll try that and see if that solves the issue.

[#7]

Did the change work for you?

[#8]

I made the following in YARN/MR setting, but it doesn't work.

YARN Service MapReduce Advanced Configuration Snippet (Safety Valve)
<property>
<name>yarn.app.mapreduce.am.job.client.port-range</name>
<value>44000-50000</value>
<description>Restrict the range for firewall.</description>
</property>
For advanced use only, a string to be inserted into mapred-site.xml. Applies to configurations of all roles in this service except client configuration.

[#9]

When you say something "doesn't work" could you please also always include the observed behaviour vs. expected?

BTW the safety valve you've used is incorrect ("YARN Service MapReduce …"), as this is a client-side property. Use the safety valve under YARN Gateway called "MapReduce Client Advanced Configuration Snippet (Safety Valve) for mapred-site.xml".

[#10]

Thanks for replying.  I think that I use the correct setting since this should be on the server side.

MapReduce Client Advanced Configuration Snippet (Safety Valve) for mapred-site.xml

Gateway Default Group

For advanced use only, a string to be inserted into the client configuration for mapred-site.xml.

YARN Service MapReduce Advanced Configuration Snippet (Safety Valve)

YARN (MR2 Included) (Service-Wide)

For advanced use only, a string to be inserted into mapred-site.xml. Applies to configurations of all roles in this service except client configuration.

I double-checked the materialized configuration file on the disk and it contains the range setting.

/run/cloudera-scm-agent/process/1353-yarn-RESOURCEMANAGER/mapred-site.xml (with latest time stamp).

[#11]

The property is not server side, its per-app (client side). All MR2
properties (save for shuffle) are client properties in YARN.

[#12]

Thanks for your quick response. I did the quick test after putting the client side setting, but it still doesn't work. I still saw MR job failed due to No Route to Host from slave 1 to slave 2 on port not defined within the set range.

[#13]

Have you already ensured your launched app's specific configuration page on the JobHistory reflects the changed configs? Did you ensure to also deploy the client config change via a cluster-wide redeploy? https://www.youtube.com/watch?v=4S9H3wftM_0

I'm able to limit the ports just fine. The test case even passes.

Given you appear to have pre-limited iptables rules causing a NoRouteToHost for the IPCs between client and MR2 AM, have you already ensured that among the open port range you are able to make a proper connection by running something outside of CDH such as a simple Python HTTP service (python -m SimpleHttpServer -p some_target_open_range_port) on all NodeManagers and connecting to them from the edge host?

[#14]

Redeployed the client configuration from CM.  Checked both yarn and hive configuration, both mapred-site.xml files have the correct configuration reflected.

[#15]

I am not using iptables, using firewalld instead on Centos 7.x.   The error I saw is caused by Hive doing select count(*) on a table, and the log indicates that the communication is between two slave nodes, not between edge node and AM.

Please check your test setting. If your range is large enough, some jobs might succeed. With my current setting of 6000 port range, some jobs failed, and some succeeded by retrying and hitting the port within the range.

[#16]

I am in the same boat - we have a restrictive firewall in place and I am trying to open a range of ports 49900 - 50000 with the following in the mapred-site.xml.

<property>

    <name>yarn.app.mapreduce.am.job.client.port-range</name>

    <value>49900-50000</value>

  </property>

I am not able to restrict the ports at all - I see the following when I run my job - 

Got exception: java.net.NoRouteToHostException: No Route to Host from  rm.domain.com/X.X.X.XXXX to workernodeX.domain.com:38470 - AFAIK - No route to host means the destination firewall is kicking me out.

I am on cloudera CDH 5.10.0 - does it include the below fix forhttps://issues.apache.org/jira/browse/MAPREDUCE-6338? If not which version would - I need to run this thing with extensive firewall in place and hence the question.

Thanks in advance for your help!

[#17]

Could you check if this JIRA is fixed by Cloudera?

https://issues.apache.org/jira/browse/MAPREDUCE-6338

[#18]

Did anyone succussfully solved this problem. I am installing a new cloudera cluster using 5.15.1 version and we want to restrict the firewall rules in a range for the nodes to communicate. However, when i run jobs it starts using ports that are not open and hence, fails to run the job.