<li><ahref="#Configure_the_state-store_for_persisting_the_RM_state">Configure the state-store for persisting the RM state</a></li>
<li><ahref="#How_to_choose_the_state-store_implementation">How to choose the state-store implementation</a></li>
<li><ahref="#Configurations_for_Hadoop_FileSystem_based_state-store_implementation">Configurations for Hadoop FileSystem based state-store implementation</a></li>
<li><ahref="#Configurations_for_ZooKeeper_based_state-store_implementation">Configurations for ZooKeeper based state-store implementation</a></li>
<li><ahref="#Configurations_for_LevelDB_based_state-store_implementation">Configurations for LevelDB based state-store implementation</a></li>
<li><ahref="#Configurations_for_work-preserving_RM_recovery">Configurations for work-preserving RM recovery</a></li></ul></li>
<p>ResourceManager is the central authority that manages resources and schedules applications running on YARN. Hence, it is potentially a single point of failure in an Apache YARN cluster. This document gives an overview of ResourceManager Restart, a feature that enhances ResourceManager to keep functioning across restarts and also makes ResourceManager down-time invisible to end-users.</p>
<p>There are two types of restart for ResourceManager:</p>
<ul>
<li>
<p><b>Non-work-preserving RM restart</b>: This restart enhances RM to persist application/attempt state and other credentials information in a pluggable state-store. RM will reload this information from state-store on restart and re-kick the previously running applications. Users are not required to re-submit the applications.</p>
</li>
<li>
<p><b>Work-preserving RM restart</b>: This focuses on re-constructing the running state of RM by combining the container status from NodeManagers and container requests from ApplicationMasters on restart. The key difference from Non-work-preserving RM restart is that previously running applications will not be killed after RM restarts, and so applications will not lose its work because of RM outage.</p>
</li>
</ul></section><section>
<h2><aname="Feature"></a>Feature</h2>
<ul>
<li>
<p><b>Non-work-preserving RM restart</b></p>
<p>In non-work-preserving RM restart, RM will save the application metadata (i.e. ApplicationSubmissionContext) in a pluggable state-store when client submits an application and also saves the final status of the application such as the completion state (failed, killed, or finished) and diagnostics when the application completes. Besides, RM also saves the credentials like security keys, tokens to work in a secure environment. When RM shuts down, as long as the required information (i.e.application metadata and the alongside credentials if running in a secure environment) is available in the state-store, then when RM restarts, it can pick up the application metadata from the state-store and re-submit the application. RM won’t re-submit the applications if they were already completed (i.e. failed, killed, or finished) before RM went down.</p>
<p>NodeManagers and clients during the down-time of RM will keep polling RM until RM comes up. When RM comes up, it will send a re-sync command to all the NodeManagers and ApplicationMasters it was talking to via heartbeats. The NMs will kill all its managed containers and re-register with RM. These re-registered NodeManagers are similar to the newly joining NMs. AMs (e.g. MapReduce AM) are expected to shutdown when they receive the re-sync command. After RM restarts and loads all the application metadata, credentials from state-store and populates them into memory, it will create a new attempt (i.e. ApplicationMaster) for each application that was not yet completed and re-kick that application as usual. As described before, the previously running applications’ work is lost in this manner since they are essentially killed by RM via the re-sync command on restart.</p>
</li>
<li>
<p><b>Work-preserving RM restart</b></p>
<p>In work-preserving RM restart, RM ensures the persistency of application state and reload that state on recovery, this restart primarily focuses on re-constructing the entire running state of YARN cluster, the majority of which is the state of the central scheduler inside RM which keeps track of all containers’ life-cycle, applications’ headroom and resource requests, queues’ resource usage and so on. In this way, RM need not kill the AM and re-run the application from scratch as it is done in non-work-preserving RM restart. Applications can simply re-sync back with RM and resume from where it were left off.</p>
<p>RM recovers its running state by taking advantage of the container status sent from all NMs. NM will not kill the containers when it re-syncs with the restarted RM. It continues managing the containers and sends the container status across to RM when it re-registers. RM reconstructs the container instances and the associated applications’ scheduling status by absorbing these containers’ information. In the meantime, AM needs to re-send the outstanding resource requests to RM because RM may lose the unfulfilled requests when it shuts down. Application writers using AMRMClient library to communicate with RM do not need to worry about the part of AM re-sending resource requests to RM on re-sync, as it is automatically taken care by the library itself.</p>
<tdalign="left"> The class name of the state-store to be used for saving application/attempt state and the credentials. The available state-store implementations are <code>org.apache.hadoop.yarn.server.resourcemanager.recovery.ZKRMStateStore</code>, a ZooKeeper based state-store implementation and <code>org.apache.hadoop.yarn.server.resourcemanager.recovery.FileSystemRMStateStore</code>, a Hadoop FileSystem based state-store implementation like HDFS and local FS. <code>org.apache.hadoop.yarn.server.resourcemanager.recovery.LeveldbRMStateStore</code>, a LevelDB based state-store implementation. The default value is set to <code>org.apache.hadoop.yarn.server.resourcemanager.recovery.FileSystemRMStateStore</code>. </td></tr>
</tbody>
</table></section><section>
<h3><aname="How_to_choose_the_state-store_implementation"></a>How to choose the state-store implementation</h3>
<ul>
<li>
<p><b>ZooKeeper based state-store</b>: User is free to pick up any storage to set up RM restart, but must use ZooKeeper based state-store to support RM HA. The reason is that only ZooKeeper based state-store supports fencing mechanism to avoid a split-brain situation where multiple RMs assume they are active and can edit the state-store at the same time.</p>
</li>
<li>
<p><b>FileSystem based state-store</b>: HDFS and local FS based state-store are supported. Fencing mechanism is not supported.</p>
</li>
<li>
<p><b>LevelDB based state-store</b>: LevelDB based state-store is considered more light weight than HDFS and ZooKeeper based state-store. LevelDB supports better atomic operations, fewer I/O ops per state update, and far fewer total files on the filesystem. Fencing mechanism is not supported.</p>
</li>
</ul></section><section>
<h3><aname="Configurations_for_Hadoop_FileSystem_based_state-store_implementation"></a>Configurations for Hadoop FileSystem based state-store implementation</h3>
<p>Support both HDFS and local FS based state-store implementation. The type of file system to be used is determined by the scheme of URI. e.g. <code>hdfs://localhost:9000/rmstore</code> uses HDFS as the storage and <code>file:///tmp/yarn/rmstore</code> uses local FS as the storage. If no scheme(<code>hdfs://</code> or <code>file://</code>) is specified in the URI, the type of storage to be used is determined by <code>fs.defaultFS</code> defined in <code>core-site.xml</code>.</p>
<ul>
<li>Configure the URI where the RM state will be saved in the Hadoop FileSystem state-store.</li>
<tdalign="left"> URI pointing to the location of the FileSystem path where RM state will be stored (e.g. <aclass="externalLink"href="hdfs://localhost:9000/rmstore">hdfs://localhost:9000/rmstore</a>). Default value is <code>${hadoop.tmp.dir}/yarn/system/rmstore</code>. If FileSystem name is not provided, <code>fs.default.name</code> specified in *<i>conf/core-site.xml</i> will be used. </td></tr>
</tbody>
</table>
<ul>
<li>Configure the retry policy state-store client uses to connect with the Hadoop FileSystem.</li>
<tdalign="left"> Hadoop FileSystem client retry policy specification. Hadoop FileSystem client retry is always enabled. Specified in pairs of sleep-time and number-of-retries i.e. (t0, n0), (t1, n1), …, the first n0 retries sleep t0 milliseconds on average, the following n1 retries sleep t1 milliseconds on average, and so on. Default value is (2000, 500) </td></tr>
</tbody>
</table></section><section>
<h3><aname="Configurations_for_ZooKeeper_based_state-store_implementation"></a>Configurations for ZooKeeper based state-store implementation</h3>
<ul>
<li>Configure the ZooKeeper server address and the root path where the RM state is stored.</li>
<tdalign="left"> Comma separated list of Host:Port pairs. Each corresponds to a ZooKeeper server (e.g. “127.0.0.1:3000,127.0.0.1:3001,127.0.0.1:3002”) to be used by the RM for storing RM state. </td></tr>
<tdalign="left"> ZooKeeper session timeout in milliseconds. This configuration is used by the ZooKeeper server to determine when the session expires. Session expiration happens when the server does not hear from the client (i.e. no heartbeat) within the session timeout period specified by this configuration. Default value is 10 seconds </td></tr>
</tbody>
</table>
<ul>
<li>Configure the ACLs to be used for setting permissions on ZooKeeper znodes.</li>
</ul>
<tableborder="0"class="bodyTable">
<thead>
<trclass="a">
<thalign="left"> Property </th>
<thalign="left"> Description </th></tr>
</thead><tbody>
<trclass="b">
<tdalign="left"><code>hadoop.zk.acl</code></td>
<tdalign="left"> ACLs to be used for setting permissions on ZooKeeper znodes. Default value is <code>world:anyone:rwcda</code></td></tr>
</tbody>
</table></section><section>
<h3><aname="Configurations_for_LevelDB_based_state-store_implementation"></a>Configurations for LevelDB based state-store implementation</h3>
<tdalign="left"> Set the amount of time RM waits before allocating new containers on RM work-preserving recovery. Such wait period gives RM a chance to settle down resyncing with NMs in the cluster on recovery, before assigning new containers to applications.</td></tr>
</tbody>
</table></section></section><section>
<h2><aname="Notes"></a>Notes</h2>
<p>ContainerId string format is changed if RM restarts with work-preserving recovery enabled. It used to be such format: <code>Container_{clusterTimestamp}_{appId}_{attemptId}_{containerId}</code>, e.g. <code>Container_1410901177871_0001_01_000005</code>.</p>
<p>It is now changed to: <code>Container_</code><b>e{epoch}</b><code>_{clusterTimestamp}_{appId}_{attemptId}_{containerId}</code>, e.g. <code>Container_</code><b>e17</b><code>_1410901177871_0001_01_000005</code>.</p>
<p>Here, the additional epoch number is a monotonically increasing integer which starts from 0 and is increased by 1 each time RM restarts. If epoch number is 0, it is omitted and the containerId string format stays the same as before.</p></section><section>
