设计目标
主要目的是为了解决两种问题
- 计划外的机器挂掉
- 计划内的如软件和硬件升级等.
架构
流程：两个RM, 启动的时候都是standby, 进程启动以后状态未被加载, 转换为active后才会加载相应的状态并启动服务. RM的状态通过配置可以存储在zookeeper, HDFS上。Standby转换到active可以通过命令或开启auto failover。
- RM 的作业信息存储在ZK的/rmstore下，Active RM向这个目录写App信息。
- RM启动的时候会通过向ZK的/hadoop-ha目录下写一个Lock文件，写成功则成为Active，否则为Standby，Standby RM会一直监控Lock文件是否存在，如果不存在则会试图去创建，即争取成为Active RM。
- 当Active RM挂掉，另外一个Standby RM成功转换为Active RM后，会从/rmstore读取相应的作业信息，重新构建作业的内存信息。然后启动内部服务，开始接收NM的心跳，构建集群资源信息，并接收客户端提交作业的请求等。
社区trunk版本当前也已经支持RM HA，但只支持手动切换，不支持Auto Failover。社区的基本原理和Cloudera RM HA类似，其架构图如下图所示：
对比Cloudera RM HA的架构图，仅少了Auto Failover部分。
服务端RM HA的关键部分主要为RMStateStore和ZKFailoverController。RMStateStore是实现RM状态存储的基类，主要包括存储和加载RM状态等方法。实现类主要包括FileSystemRMStateStore和ZKRMStateStore。类图如下图所示。
ZKFailoverController中维护着ActiveStandbyElector和HealthMonitor，ActiveStandbyElector主要工作是。
1. 初始化时在ZK上创建一个Lock文件，
2. Standby RM运行过程中监控ZM上的Lock文件是否存在。
HealthMonitor的主要工作是检查自己（RM）的健康状态，通过HAServiceStatus提供的getServiceStatus()和monitorHealth()方法，如果自己健康的，则会试图创建Lock文件，按照结果成为active或standby。下图是ZKFailoverController的类图，图中可以看出，Cloudera的Hadoop版本中，NameNode、Jobtracker和ResourceManager都采用相同的Auto Failover机制。
客户端的实现机制
在RM HA之前，客户端与RM的通信直接使用ApplicationClientProtocol等协议，增加RM HA后，客户端使用RetryPolicy，它提供了一种重试机制，但一个RM连不上，则会Failover到另外一台RM上。具体的实现方法是采用动态代理模式，增加RMProxy实现retry方式连接RM。下图是RMProxy的类图。
其中ClientRMProxy，代理ApplicationClientProtocol、ApplicationMasterProtocol、ResourceManagerAdministrationProtocol，实现 Yarn client、AM与RM的连接。ServerRMProxy提供给NM连接RM使用。代理ResourceTracker。
