<ahref="../../hadoop-mapreduce-client/hadoop-mapreduce-client-core/MapReduce_Compatibility_Hadoop1_Hadoop2.html">Compatibilty between Hadoop 1.x and Hadoop 2.x</a>
<ahref="http://maven.apache.org/"title="Built by Maven"class="poweredBy">
<imgalt="Built by Maven"src="./images/logos/maven-feather.png"/>
</a>
</div>
</div>
<divid="bodyColumn">
<divid="contentBox">
<!-- Licensed under the Apache License, Version 2.0 (the "License"); --><!-- you may not use this file except in compliance with the License. --><!-- You may obtain a copy of the License at --><!-- --><!-- http://www.apache.org/licenses/LICENSE-2.0 --><!-- --><!-- Unless required by applicable law or agreed to in writing, software --><!-- distributed under the License is distributed on an "AS IS" BASIS, --><!-- WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. --><!-- See the License for the specific language governing permissions and --><!-- limitations under the License. See accompanying LICENSE file. --><ul>
<li><ahref="#Hadoop_MapReduce_Next_Generation_-_Cluster_Setup">Hadoop MapReduce Next Generation - Cluster Setup</a>
<h2>Hadoop MapReduce Next Generation - Cluster Setup<aname="Hadoop_MapReduce_Next_Generation_-_Cluster_Setup"></a></h2>
<divclass="section">
<h3><aname="Purpose">Purpose</a></h3>
<p>This document describes how to install, configure and manage non-trivial Hadoop clusters ranging from a few nodes to extremely large clusters with thousands of nodes.</p>
<p>To play with Hadoop, you may first want to install it on a single machine (see <ahref="./SingleCluster.html">Single Node Setup</a>).</p></div>
<divclass="section">
<h3><aname="Prerequisites">Prerequisites</a></h3>
<p>Download a stable version of Hadoop from Apache mirrors.</p></div>
<divclass="section">
<h3><aname="Installation">Installation</a></h3>
<p>Installing a Hadoop cluster typically involves unpacking the software on all the machines in the cluster or installing RPMs.</p>
<p>Typically one machine in the cluster is designated as the NameNode and another machine the as ResourceManager, exclusively. These are the masters.</p>
<p>The rest of the machines in the cluster act as both DataNode and NodeManager. These are the slaves.</p></div>
<divclass="section">
<h3><aname="Running_Hadoop_in_Non-Secure_Mode">Running Hadoop in Non-Secure Mode</a></h3>
<p>The following sections describe how to configure a Hadoop cluster.</p>
<p>Hadoop configuration is driven by two types of important configuration files:</p>
<ul>
<li>Read-only default configuration - <tt>core-default.xml</tt>, <tt>hdfs-default.xml</tt>, <tt>yarn-default.xml</tt> and <tt>mapred-default.xml</tt>.</li>
<li>Site-specific configuration - <b>conf/core-site.xml</b>, <b>conf/hdfs-site.xml</b>, <b>conf/yarn-site.xml</b> and <b>conf/mapred-site.xml</b>.</li></ul>
<p>Additionally, you can control the Hadoop scripts found in the bin/ directory of the distribution, by setting site-specific values via the <b>conf/hadoop-env.sh</b> and <b>yarn-env.sh</b>.</p>
<p>To configure the Hadoop cluster you will need to configure the <tt>environment</tt> in which the Hadoop daemons execute as well as the <tt>configuration parameters</tt> for the Hadoop daemons.</p>
<p>The Hadoop daemons are NameNode/DataNode and ResourceManager/NodeManager.</p>
<divclass="section">
<h4><aname="Configuring_Environment_of_Hadoop_Daemons">Configuring Environment of Hadoop Daemons</a></h4>
<p>Administrators should use the <b>conf/hadoop-env.sh</b> and <b>conf/yarn-env.sh</b> script to do site-specific customization of the Hadoop daemons' process environment.</p>
<p>At the very least you should specify the <tt>JAVA_HOME</tt> so that it is correctly defined on each remote node.</p>
<p>In most cases you should also specify <tt>HADOOP_PID_DIR</tt> and <tt>HADOOP_SECURE_DN_PID_DIR</tt> to point to directories that can only be written to by the users that are going to run the hadoop daemons. Otherwise there is the potential for a symlink attack.</p>
<p>Administrators can configure individual daemons using the configuration options shown below in the table:</p>
<p>Other useful configuration parameters that you can customize include:</p>
<ul>
<li><tt>HADOOP_LOG_DIR</tt> / <tt>YARN_LOG_DIR</tt> - The directory where the daemons' log files are stored. They are automatically created if they don't exist.</li>
<li><tt>HADOOP_HEAPSIZE</tt> / <tt>YARN_HEAPSIZE</tt> - The maximum amount of heapsize to use, in MB e.g. if the varibale is set to 1000 the heap will be set to 1000MB. This is used to configure the heap size for the daemon. By default, the value is 1000. If you want to configure the values separately for each deamon you can use.
<tdalign="left">Path on the local filesystem where the NameNode stores the namespace and transactions logs persistently.</td>
<tdalign="left">If this is a comma-delimited list of directories then the name table is replicated in all of the directories, for redundancy.</td></tr>
<tdalign="left">Comma separated list of paths on the local filesystem of a <tt>DataNode</tt> where it should store its blocks.</td>
<tdalign="left">If this is a comma-delimited list of directories, then data will be stored in all named directories, typically on different devices.</td></tr></table></li></ul></li>
<li><tt>conf/yarn-site.xml</tt>
<ul>
<li>Configurations for ResourceManager and NodeManager:
<tdalign="left">Enable ACLs? Defaults to <i>false</i>.</td></tr>
<trclass="a">
<tdalign="left"><tt>yarn.admin.acl</tt></td>
<tdalign="left">Admin ACL</td>
<tdalign="left">ACL to set admins on the cluster. ACLs are of for <i>comma-separated-users</i><i>space</i><i>comma-separated-groups</i>. Defaults to special value of <b>*</b> which means <i>anyone</i>. Special value of just <i>space</i> means no one has access.</td></tr>
<tdalign="left">Maximum ratio by which virtual memory usage of tasks may exceed physical memory</td>
<tdalign="left">The virtual memory usage of each task may exceed its physical memory limit by this ratio. The total amount of virtual memory used by tasks on the NodeManager may exceed its physical memory usage by this ratio.</td></tr>
<tdalign="left">HDFS directory where the application logs are moved on application completion. Need to set appropriate permissions. Only applicable if log-aggregation is enabled.</td></tr>
<tdalign="left">Suffix appended to the remote log dir. Logs will be aggregated to ${yarn.nodemanager.remote-app-log-dir}/${user}/${thisParam} Only applicable if log-aggregation is enabled.</td></tr>
<tdalign="left">How long to keep aggregation logs before deleting them. -1 disables. Be careful, set this too small and you will spam the name node.</td></tr>
<tdalign="left">Time between checks for aggregated log retention. If set to 0 or a negative value then the value is computed as one-tenth of the aggregated log retention time. Be careful, set this too small and you will spam the name node.</td></tr></table></li></ul></li>
<p>The HDFS and the YARN components are rack-aware.</p>
<p>The NameNode and the ResourceManager obtains the rack information of the slaves in the cluster by invoking an API <i>resolve</i> in an administrator configured module.</p>
<p>The API resolves the DNS name (also IP address) to a rack id.</p>
<p>The site-specific module to use can be configured using the configuration item <tt>topology.node.switch.mapping.impl</tt>. The default implementation of the same runs a script/command configured using <tt>topology.script.file.name</tt>. If <tt>topology.script.file.name</tt> is not set, the rack id <i>/default-rack</i> is returned for any passed IP address.</p></div>
<divclass="section">
<h3><aname="Monitoring_Health_of_NodeManagers">Monitoring Health of NodeManagers</a></h3>
<p>Hadoop provides a mechanism by which administrators can configure the NodeManager to run an administrator supplied script periodically to determine if a node is healthy or not.</p>
<p>Administrators can determine if the node is in a healthy state by performing any checks of their choice in the script. If the script detects the node to be in an unhealthy state, it must print a line to standard output beginning with the string ERROR. The NodeManager spawns the script periodically and checks its output. If the script's output contains the string ERROR, as described above, the node's status is reported as <tt>unhealthy</tt> and the node is black-listed by the ResourceManager. No further tasks will be assigned to this node. However, the NodeManager continues to run the script, so that if the node becomes healthy again, it will be removed from the blacklisted nodes on the ResourceManager automatically. The node's health along with the output of the script, if it is unhealthy, is available to the administrator in the ResourceManager web interface. The time since the node was healthy is also displayed on the web interface.</p>
<p>The following parameters can be used to control the node health monitoring script in <tt>conf/yarn-site.xml</tt>.</p>
<tdalign="left">Node health script timeout interval</td>
<tdalign="left">Timeout for health script execution.</td></tr></table>
<p>The health checker script is not supposed to give ERROR if only some of the local disks become bad. NodeManager has the ability to periodically check the health of the local disks (specifically checks nodemanager-local-dirs and nodemanager-log-dirs) and after reaching the threshold of number of bad directories based on the value set for the config property yarn.nodemanager.disk-health-checker.min-healthy-disks, the whole node is marked unhealthy and this info is sent to resource manager also. The boot disk is either raided or a failure in the boot disk is identified by the health checker script.</p></div>
<divclass="section">
<h3><aname="Slaves_file">Slaves file</a></h3>
<p>Typically you choose one machine in the cluster to act as the NameNode and one machine as to act as the ResourceManager, exclusively. The rest of the machines act as both a DataNode and NodeManager and are referred to as <i>slaves</i>.</p>
<p>List all slave hostnames or IP addresses in your <tt>conf/slaves</tt> file, one per line.</p></div>
<divclass="section">
<h3><aname="Logging">Logging</a></h3>
<p>Hadoop uses the Apache log4j via the Apache Commons Logging framework for logging. Edit the <tt>conf/log4j.properties</tt> file to customize the Hadoop daemons' logging configuration (log-formats and so on).</p></div>
<divclass="section">
<h3><aname="Operating_the_Hadoop_Cluster">Operating the Hadoop Cluster</a></h3>
<p>Once all the necessary configuration is complete, distribute the files to the <tt>HADOOP_CONF_DIR</tt> directory on all the machines.</p>
<h3><aname="Operating_the_Hadoop_Cluster">Operating the Hadoop Cluster</a></h3>
<p>Once all the necessary configuration is complete, distribute the files to the <tt>HADOOP_CONF_DIR</tt> directory on all the machines.</p>
<p>This section also describes the various Unix users who should be starting the various components and uses the same Unix accounts and groups used previously:</p>
<p>Run a script to start DataNodes on all slaves as <i>root</i> with a special environment variable <tt>HADOOP_SECURE_DN_USER</tt> set to <i>hdfs</i>:</p>
<p>Start a standalone WebAppProxy server. Run on the WebAppProxy server as <i>yarn</i>. If multiple servers are used with load balancing it should be run on each of them:</p>
<p>Stop the WebAppProxy server. Run on the WebAppProxy server as <i>yarn</i>. If multiple servers are used with load balancing it should be run on each of them:</p>