繼上篇文章驗證Cloudera RM HA功能后，現在開始分析Cloudera RM HA的原理。
設計目標
主要目的是為了解決兩種問題
-
計划外的機器掛掉
-
計划內的如軟件和硬件升級等.
架構
流程：兩個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。