如果rm不可用，则无法启动任何应用程序或任务。
如果您拥有rm的ha，那么它将从ha重新启动。

资源管理器（rm）的高可用性在ApacheLink中解释如下。

resourcemanager ha是通过主/备体系结构实现的。
在任何时间点，其中一个rm处于活动状态，如果活动rm出现故障，另一个备用节点将等待接管。
升级到活动状态的rm从状态存储加载rm内部状态，并从上一个活动状态停止的位置继续运行。
将为以前提交给rm的每个托管应用程序生成新的尝试。应用程序可以定期检查点以避免丢失任何工作。
状态存储必须在活动/备用rms中都可见。目前，有两种用于持久性的rmstatestore实现-filesystemrmstatestore和zkrmstatestore。
zkrmstatestore（zookeeper）隐式地允许在任何时间点对单个rm进行写访问，因此是建议在ha集群中使用的存储。
使用zkrmstatestore，不需要单独的围栏机制来解决多个rm可能担任主动角色的潜在分裂大脑情况。zookeeper可以很好地处理这种情况。
zookeeper不仅用于资源管理器故障转移。许多应用程序现在每天都在使用zookeeper。hadoop中的其他故障转移用例的例子-name节点故障转移也通过zookeeper发生。看看name节点的故障转移过程。
在hadoop 2.x之后和hadoop 2.6.x之前：
当resourcemanager死亡并重新启动时，或者在ha集群的情况下故障转移到另一个resourcemanager时，新活动的resourcemanager会指示正在运行的applicationmasters中止。这将耗尽应用程序尝试。
另外，如果resourcemanager关闭一段时间而applicationmaster无法连接，它将超时并中止。这也会耗尽应用程序的尝试。
当新的resourcemanager处于活动状态时，它可以恢复未超过最大尝试次数的失败尝试的应用程序。
更多细节请看这篇文章
来自hadoop 2.6.0：
资源管理器通过利用从所有节点管理器发送的容器状态来恢复其运行状态。节点管理器与重新启动的资源管理器重新同步时不会终止容器。
它继续管理容器，并在重新注册时将容器状态发送到资源管理器。
资源管理器通过吸收容器的信息来重构容器示例和相关应用程序的调度状态

管理员将创建一个新的资源管理器。将从所有应用程序管理器获取最新信息，并更新新资源管理器将使用的持久存储。这纯粹是一个管理任务