調用 cati 復雜 問題 book 資源 腦裂 tor 如果

HA(High Available), 高可用，是保證業務連續性的有效解決方案，一般有兩個或兩個以上的節點，分為活動節點（Active）及備用節點（Standby）。通常把正在執行業務的稱為活動節點，而作為活動節點的一個備份的則稱為備用節點。當活動節點出現問題，導致正在運行的業務（任務）不能正常運行時，備用節點此時就會偵測到，並立即接續活動節點來執行業務。從而實現業務的不中斷或短暫中斷。
Hadoop1.X版本，NN是HDFS集群的單點故障點，每一個集群只有一個NN,如果這個機器或進程不可用，整個集群就無法使用。為了解決這個問題，出現了一堆針對HDFS HA的解決方案（如：Linux HA, VMware FT, shared NAS+NFS, BookKeeper, QJM/Quorum Journal Manager, BackupNode等）。
在HA具體實現方法不同情況下，HA框架的流程是一致的, 不一致的就是如何存儲、管理、同步edits編輯日誌文件。
在Active NN和Standby NN之間要有個共享的存儲日誌的地方，Active NN把edit Log寫到這個共享的存儲日誌的地方，Standby NN去讀取日誌然後執行，這樣Active和Standby NN內存中的HDFS元數據保持著同步。一旦發生主從切換Standby NN可以盡快接管Active NN的工作。

1． Namenode HA1.1． Namenode HA詳解
hadoop2.x之後，Clouera提出了QJM/Qurom Journal Manager，這是一個基於Paxos算法（分布式一致性算法）實現的HDFS HA方案，它給出了一種較好的解決思路和方案,QJM主要優勢如下：

不需要配置額外的高共享存儲，降低了復雜度和維護成本。
消除spof(單點故障)。
系統魯棒性(Robust)的程度可配置、可擴展。

基本原理就是用2N+1臺 JournalNode 存儲EditLog，每次寫數據操作有>=N+1返回成功時即認為該次寫成功，數據不會丟失了。當然這個算法所能容忍的是最多有N臺機器掛掉，如果多於N臺掛掉，這個算法就失效了。這個原理是基於Paxos算法。
在HA架構裏面SecondaryNameNode已經不存在了，為了保持standby NN時時的與Active NN的元數據保持一致，他們之間交互通過JournalNode進行操作同步。
任何修改操作在 Active NN上執行時，JournalNode進程同時也會記錄修改log到至少半數以上的JN中，這時 Standby NN 監測到JN 裏面的同步log發生變化了會讀取 JN 裏面的修改log，然後同步到自己的目錄鏡像樹裏面，如下圖：

當發生故障時，Active的 NN 掛掉後，Standby NN 會在它成為Active NN 前，讀取所有的JN裏面的修改日誌，這樣就能高可靠的保證與掛掉的NN的目錄鏡像樹一致，然後無縫的接替它的職責，維護來自客戶端請求，從而達到一個高可用的目的。
在HA模式下，datanode需要確保同一時間有且只有一個NN能命令DN。為此：
每個NN改變狀態的時候，向DN發送自己的狀態和一個序列號。
DN在運行過程中維護此序列號，當failover時，新的NN在返回DN心跳時會返回自己的active狀態和一個更大的序列號。DN接收到這個返回則認為該NN為新的active。
如果這時原來的active NN恢復，返回給DN的心跳信息包含active狀態和原來的序列號，這時DN就會拒絕這個NN的命令。

1.2． Failover Controller
HA模式下，會將FailoverController部署在每個NameNode的節點上，作為一個單獨的進程用來監視NN的健康狀態。FailoverController主要包括三個組件:
HealthMonitor: 監控NameNode是否處於unavailable或unhealthy狀態。當前通過RPC調用NN相應的方法完成。
ActiveStandbyElector: 監控NN在ZK中的狀態。
ZKFailoverController: 訂閱HealthMonitor 和ActiveStandbyElector 的事件，並管理NN的狀態,另外zkfc還負責解決fencing（也就是腦裂問題）。
上述三個組件都在跑在一個JVM中，這個JVM與NN的JVM在同一個機器上。但是兩個獨立的進程。一個典型的HA集群，有兩個NN組成，每個NN都有自己的ZKFC進程。

ZKFailoverController主要職責：
l 健康監測：周期性的向它監控的NN發送健康探測命令，從而來確定某個NameNode是否處於健康狀態，如果機器宕機，心跳失敗，那麽zkfc就會標記它處於一個不健康的狀態
l 會話管理：如果NN是健康的，zkfc就會在zookeeper中保持一個打開的會話，如果NameNode同時還是Active狀態的，那麽zkfc還會在Zookeeper中占有一個類型為短暫類型的znode，當這個NN掛掉時，這個znode將會被刪除，然後備用的NN將會得到這把鎖，升級為主NN，同時標記狀態為Active
l 當宕機的NN新啟動時，它會再次註冊zookeper，發現已經有znode鎖了，便會自動變為Standby狀態，如此往復循環，保證高可靠，需要註意，目前僅僅支持最多配置2個NN
l master選舉：通過在zookeeper中維持一個短暫類型的znode，來實現搶占式的鎖機制，從而判斷那個NameNode為Active狀態
2． Yarn HA
Yarn作為資源管理系統，是上層計算框架（如MapReduce,Spark）的基礎。在Hadoop 2.4.0版本之前，Yarn存在單點故障（即ResourceManager存在單點故障），一旦發生故障，恢復時間較長，且會導致正在運行的Application丟失，影響範圍較大。從Hadoop 2.4.0版本開始，Yarn實現了ResourceManager HA，在發生故障時自動failover，大大提高了服務的可靠性。
ResourceManager（簡寫為RM）作為Yarn系統中的主控節點，負責整個系統的資源管理和調度，內部維護了各個應用程序的ApplictionMaster信息、NodeManager（簡寫為NM）信息、資源使用等。由於資源使用情況和NodeManager信息都可以通過NodeManager的心跳機制重新構建出來，因此只需要對ApplicationMaster相關的信息進行持久化存儲即可。
在一個典型的HA集群中，兩臺獨立的機器被配置成ResourceManger。在任意時間，有且只允許一個活動的ResourceManger,另外一個備用。切換分為兩種方式：
手動切換：在自動恢復不可用時，管理員可用手動切換狀態，或是從Active到Standby,或是從Standby到Active。
自動切換：基於Zookeeper，但是區別於HDFS的HA，2個節點間無需配置額外的ZFKC守護進程來同步數據。

3． Hadoop HA集群的搭建
HA集群搭建的難度主要在於配置文件的編寫，心細，心細，心細！
詳細的搭建安裝步驟請參考附件資料。

Hadoop High Availability