YARN将共享存储系统抽象成RMStateStore,以保存恢复ResouceManager所必须的信息，包括：
Application状态信息ApplicationState。内部包含应用程序提交描述信息context、提交时间submitTime、拥有者user三个字段
Application对应的每个ApplicationAttempt信息ApplicationAttemptState。内部包含attemptId、所在Container的信息masterContainer、安全Token三个字段
安全令牌相关信息RMDTSecretManagerState。内部包含delegateionTokenState、masterKeyState、dtSequenceNumber三个字段
ResouceManager并不会保存已经分配给每个ApplicationMaster的资源信息和每个NodeManager的资源使用信息，这些均可通过相应的心跳汇报机制重构出来，也正因如此，ResouceManager HA的实现是非常轻量级的。
ResouceManager提供了四种RMStateStore实现(管理员可通过参数yarn.resourcemanager.store.class设置采用的RMStateStore实现类)，分别是NullRMStateStore(不存储任何状态信息，在不启动恢复机制时，它是默认实现的)、MemoryRMStateStore(将状态信息存储到内存中，在启用恢复机制时，它是默认实现的)、FileSystemRMStateStore(将状态信息存储到HDFS中)、ZKRMStateStore(将状态信息存储到zookeeper中)，从目前来看YARN HA最佳实践是采用基于ZKRMStateStore的共享存储方案
目前ResouceManager的容错机制涉及到的流程有
1、ResouceManager收到客户端发送的提交应用程序请求后，在相应之前，会将应用程序的”application submission context”同步保存下来。这个有2点好处
这样可确保一旦客户端成功提交应用程序后，无论何时重启，ResouceManager均有足够的信息将应用程序恢复出来。
考虑到用户提交应用程序的频率很低，且ClientRMService使用了一个独立的RPC通道，因此同步记录信息不会产生太大的性能开销
2、当一个新的应用程序运行实例被创建时，它的基本信息和之前失败的运行实例信息将被保存下来
当ResouceManager重启后，它需要获之前失败的应用程序实例ID以产生一个新的运行实例ID
相关信息将被异步记录下来，这主要是考虑到相关事件由中央异步调度器AsyncDispatcher处理，而同步记录日志会造成性能问题
3、当一个应用程序运行结束后，它保存的信息将被移除，考虑到性能问题，该过程是异步进行的
4、ResouceManager重启后，它首先将之前保存的数据加载到内存中，这些信息将用于构建RMApp对象和创建新的运行实例RMAppAttempt。之后，内部服务将被启动，所有操作照旧进行
重启ResouceManager收到NodeManager汇报的心跳后，发现该NodeManager并不存在，则要求他重新启动，这样它上面运行的container将被杀死
重启的ResouceManager收到ApplicationMaster汇报的心跳后，发现心跳中涉及的运行实例ID并不存在，从而会向ApplicationMaster发送一个RemoteException异常，这将导致ApplicationMaster异常退出
NodeManager重启并向ResouceManager注册，新的运行实例将被启动，接下来所有操作照旧进行