Hadoop HA 深度解析
社區hadoop2.2.0 release版本開始支持NameNode的HA，本文將詳細描述NameNode HA內部的設計與實現。
?
為什么要Namenode HA？
1. NameNode High Availability即高可用。
2. NameNode 很重要，掛掉會導致存儲停止服務，無法進行數據的讀寫，基于此NameNode的計算（MR，Hive等）也無法完成。
?
Namenode HA 如何實現，關鍵技術難題是什么？
1. 如何保持主和備NameNode的狀態同步，并讓Standby在Active掛掉后迅速提供服務，namenode啟動比較耗時，包括加載fsimage和editlog（獲取file to block信息），處理所有datanode第一次blockreport（獲取block to datanode信息），保持NN的狀態同步，需要這兩部分信息同步。
2. 腦裂（split-brain），指在一個高可用（HA）系統中，當聯系著的兩個節點斷開聯系時，本來為一個整體的系統，分裂為兩個獨立節點，這時兩個節點開始爭搶共享資源，結果會導致系統混亂，數據損壞。
3. NameNode切換對外透明，主Namenode切換到另外一臺機器時，不應該導致正在連接的客戶端失敗，主要包括Client，Datanode與NameNode的鏈接。
社區NN的HA架構，實現原理，各部分的實現機制，解決了哪些問題？
1. 非HA的Namenode架構，一個HDFS集群只存在一個NN，DN只向一個NN匯報，NN的editlog存儲在本地目錄。
2. 社區NN HA的架構
圖1，NN HA架構（從社區復制）
????社區的NN HA包括兩個NN，主（active）與備（standby），ZKFC，ZK，share editlog。流程：集群啟動后一個NN處于active狀態，并提供服務，處理客戶端和datanode的請求，并把editlog寫到本地和share editlog（可以是NFS，QJM等）中。另外一個NN處于Standby狀態，它啟動的時候加載fsimage，然后周期性的從share editlog中獲取editlog，保持與active的狀態同步。為了實現standby在sctive掛掉后迅速提供服務，需要DN同時向兩個NN匯報，使得Stadnby保存block to datanode信息，因為NN啟動中最費時的工作是處理所有datanode的blockreport。為了實現熱備，增加FailoverController和ZK，FailoverController與ZK通信，通過ZK選主，FailoverController通過RPC讓NN轉換為active或standby。
?
2.關鍵問題：
(1) 保持NN的狀態同步，通過standby周期性獲取editlog，DN同時想standby發送blockreport。
(2) 防止腦裂
? 共享存儲的fencing，確保只有一個NN能寫成功。使用QJM實現fencing，下文敘述原理。
? datanode的fencing。確保只有一個NN能命令DN。HDFS-1972中詳細描述了DN如何實現fencing
? ? ?(a) 每個NN改變狀態的時候，向DN發送自己的狀態和一個序列號。
? ? (b) DN在運行過程中維護此序列號，當failover時，新的NN在返回DN心跳時會返回自己的active狀態和一個更大的序列號。DN接收到這個返回是認為該NN為新的active。
? ? ?(c) 如果這時原來的active（比如GC）恢復，返回給DN的心跳信息包含active狀態和原來的序列號，這時DN就會拒絕這個NN的命令。
? ? ?(d) 特別需要注意的一點是，上述實現還不夠完善，HDFS-1972中還解決了一些有可能導致誤刪除block的隱患，在failover后，active在DN匯報所有刪除報告前不應該刪除任何block。
? ?客戶端fencing，確保只有一個NN能響應客戶端請求。讓訪問standby nn的客戶端直接失敗。在RPC層封裝了一層，通過FailoverProxyProvider以重試的方式連接NN。通過若干次連接一個NN失敗后嘗試連接新的NN，對客戶端的影響是重試的時候增加一定的延遲。客戶端可以設置重試此時和時間。
ZKFC的設計
1. FailoverController實現下述幾個功能
? (a) 監控NN的健康狀態
? (b) 向ZK定期發送心跳，使自己可以被選舉。
? (c) 當自己被ZK選為主時，active FailoverController通過RPC調用使相應的NN轉換為active。
2. 為什么要作為一個deamon進程從NN分離出來
? (1) 防止因為NN的GC失敗導致心跳受影響。
? (2) FailoverController功能的代碼應該和應用的分離，提高的容錯性。
? (3) 使得主備選舉成為可插拔式的插件。
圖2 FailoverController架構（從社區復制）
3. FailoverController主要包括三個組件，
? (1) HealthMonitor 監控NameNode是否處于unavailable或unhealthy狀態。當前通過RPC調用NN相應的方法完成。
? (2) ActiveStandbyElector 管理和監控自己在ZK中的狀態。
? (3) ZKFailoverController 它訂閱HealthMonitor 和ActiveStandbyElector 的事件，并管理NameNode的狀態。
?
QJM的設計
?
圖3 QJM架構
(1) 初始化后，Active把editlog日志寫到2N+1上JN上，每個editlog有一個編號，每次寫editlog只要其中大多數JN返回成功（即大于等于N+1）即認定寫成功。
(2) Standby定期從JN讀取一批editlog，并應用到內存中的FsImage中。
(3) 如何fencing： NameNode每次寫Editlog都需要傳遞一個編號Epoch給JN，JN會對比Epoch，如果比自己保存的Epoch大或相同，則可以寫，JN更新自己的Epoch到最新，否則拒絕操作。在切換時，Standby轉換為Active時，會把Epoch+1，這樣就防止即使之前的NameNode向JN寫日志，也會失敗。
(4) 寫日志：
? (a) NN通過RPC向N個JN異步寫Editlog，當有N/2+1個寫成功，則本次寫成功。
? (b) 寫失敗的JN下次不再寫，直到調用滾動日志操作，若此時JN恢復正常，則繼續向其寫日志。
? (c) 每條editlog都有一個編號txid，NN寫日志要保證txid是連續的，JN在接收寫日志時，會檢查txid是否與上次連續，否則寫失敗。
(5) 讀日志：
? (a) 定期遍歷所有JN，獲取未消化的editlog，按照txid排序。
? (b) 根據txid消化editlog。
(6) 切換時日志恢復機制
? (a) 主從切換時觸發
? (b) 準備恢復（prepareRecovery），standby向JN發送RPC請求，獲取txid信息，并對選出最好的JN。
? (c) 接受恢復（acceptRecovery），standby向JN發送RPC，JN之間同步Editlog日志。
? (d) Finalized日志。即關閉當前editlog輸出流時或滾動日志時的操作。
? (e) Standby同步editlog到最新
(7) 如何選取最好的JN
? (a) 有Finalized的不用in-progress
? (b) 多個Finalized的需要判斷txid是否相等
? (c) 沒有Finalized的首先看誰的epoch更大
? (d) Epoch一樣則選txid大的。
?
參考：
1.https://issues.apache.org/jira/secure/attachment/12480489/NameNode%20HA_v2_1.pdf
2.https://issues.apache.org/jira/secure/attachment/12521279/zkfc-design.pdf
3.https://issues.apache.org/jira/secure/attachment/12547598/qjournal-design.pdf
4. https://issues.apache.org/jira/browse/HDFS-1972
5.https://issues.apache.org/jira/secure/attachment/12490290/DualBlockReports.pdf
6.http://svn.apache.org/viewvc/hadoop/common/branches/branch-2.2.0/
7.http://yanbohappy.sinaapp.com/?p=205
轉載于:https://www.cnblogs.com/LiCheng-/p/7670069.html
總結
以上是生活随笔為你收集整理的Hadoop HA 深度解析的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： Gradle 修改 Maven 仓库地址
- 下一篇： CriminalIntent项目开发--