Namenode HA原理是什么

Namenode HA原理是什么，很多新手對(duì)此不是很清楚，為了幫助大家解決這個(gè)難題，下面小編將為大家詳細(xì)講解，有這方面需求的人可以來(lái)學(xué)習(xí)下，希望你能有所收獲。

Namenode HA原理詳解

社區(qū)hadoop2.2.0 release版本開(kāi)始支持NameNode的HA，本文將詳細(xì)描述NameNode HA內(nèi)部的設(shè)計(jì)與實(shí)現(xiàn)。

為什么要Namenode HA？

1. NameNode High Availability即高可用。

2. NameNode 很重要，掛掉會(huì)導(dǎo)致存儲(chǔ)停止服務(wù)，無(wú)法進(jìn)行數(shù)據(jù)的讀寫，基于此NameNode的計(jì)算（MR，Hive等）也無(wú)法完成。

Namenode HA 如何實(shí)現(xiàn)，關(guān)鍵技術(shù)難題是什么？

1. 如何保持主和備NameNode的狀態(tài)同步，并讓Standby在Active掛掉后迅速提供服務(wù)，namenode啟動(dòng)比較耗時(shí)，包括加載fsimage和editlog（獲取file to block信息），處理所有datanode第一次blockreport（獲取block to datanode信息），保持NN的狀態(tài)同步，需要這兩部分信息同步。

2. 腦裂（split-brain），指在一個(gè)高可用（HA）系統(tǒng)中，當(dāng)聯(lián)系著的兩個(gè)節(jié)點(diǎn)斷開(kāi)聯(lián)系時(shí)，本來(lái)為一個(gè)整體的系統(tǒng)，分裂為兩個(gè)獨(dú)立節(jié)點(diǎn)，這時(shí)兩個(gè)節(jié)點(diǎn)開(kāi)始爭(zhēng)搶共享資源，結(jié)果會(huì)導(dǎo)致系統(tǒng)混亂，數(shù)據(jù)損壞。

3. NameNode切換對(duì)外透明，主Namenode切換到另外一臺(tái)機(jī)器時(shí)，不應(yīng)該導(dǎo)致正在連接的客戶端失敗，主要包括Client，Datanode與NameNode的鏈接。

社區(qū)NN的HA架構(gòu)，實(shí)現(xiàn)原理，各部分的實(shí)現(xiàn)機(jī)制，解決了哪些問(wèn)題？

1. 非HA的Namenode架構(gòu)，一個(gè)HDFS集群只存在一個(gè)NN，DN只向一個(gè)NN匯報(bào)，NN的editlog存儲(chǔ)在本地目錄。

2. 社區(qū)NN HA的架構(gòu)

圖1，NN HA架構(gòu)（從社區(qū)復(fù)制）

    社區(qū)的NN HA包括兩個(gè)NN，主（active）與備（standby），ZKFC，ZK，share editlog。流程：集群?jiǎn)?dòng)后一個(gè)NN處于active狀態(tài)，并提供服務(wù)，處理客戶端和datanode的請(qǐng)求，并把editlog寫到本地和share editlog（可以是NFS，QJM等）中。另外一個(gè)NN處于Standby狀態(tài)，它啟動(dòng)的時(shí)候加載fsimage，然后周期性的從share editlog中獲取editlog，保持與active的狀態(tài)同步。為了實(shí)現(xiàn)standby在sctive掛掉后迅速提供服務(wù)，需要DN同時(shí)向兩個(gè)NN匯報(bào)，使得Stadnby保存block to datanode信息，因?yàn)镹N啟動(dòng)中最費(fèi)時(shí)的工作是處理所有datanode的blockreport。為了實(shí)現(xiàn)熱備，增加FailoverController和ZK，F(xiàn)ailoverController與ZK通信，通過(guò)ZK選主，F(xiàn)ailoverController通過(guò)RPC讓NN轉(zhuǎn)換為active或standby。

2.關(guān)鍵問(wèn)題：

(1) 保持NN的狀態(tài)同步，通過(guò)standby周期性獲取editlog，DN同時(shí)想standby發(fā)送blockreport。

(2) 防止腦裂

  共享存儲(chǔ)的fencing，確保只有一個(gè)NN能寫成功。使用QJM實(shí)現(xiàn)fencing，下文敘述原理。

  datanode的fencing。確保只有一個(gè)NN能命令DN。HDFS-1972中詳細(xì)描述了DN如何實(shí)現(xiàn)fencing

     (a) 每個(gè)NN改變狀態(tài)的時(shí)候，向DN發(fā)送自己的狀態(tài)和一個(gè)序列號(hào)。

    (b) DN在運(yùn)行過(guò)程中維護(hù)此序列號(hào)，當(dāng)failover時(shí)，新的NN在返回DN心跳時(shí)會(huì)返回自己的active狀態(tài)和一個(gè)更大的序列號(hào)。DN接收到這個(gè)返回是認(rèn)為該NN為新的active。

     (c) 如果這時(shí)原來(lái)的active（比如GC）恢復(fù)，返回給DN的心跳信息包含active狀態(tài)和原來(lái)的序列號(hào)，這時(shí)DN就會(huì)拒絕這個(gè)NN的命令。

     (d) 特別需要注意的一點(diǎn)是，上述實(shí)現(xiàn)還不夠完善，HDFS-1972中還解決了一些有可能導(dǎo)致誤刪除block的隱患，在failover后，active在DN匯報(bào)所有刪除報(bào)告前不應(yīng)該刪除任何block。

   客戶端fencing，確保只有一個(gè)NN能響應(yīng)客戶端請(qǐng)求。讓訪問(wèn)standby nn的客戶端直接失敗。在RPC層封裝了一層，通過(guò)FailoverProxyProvider以重試的方式連接NN。通過(guò)若干次連接一個(gè)NN失敗后嘗試連接新的NN，對(duì)客戶端的影響是重試的時(shí)候增加一定的延遲?？蛻舳丝梢栽O(shè)置重試此時(shí)和時(shí)間。

ZKFC的設(shè)計(jì)

1. FailoverController實(shí)現(xiàn)下述幾個(gè)功能

  (a) 監(jiān)控NN的健康狀態(tài)

  (b) 向ZK定期發(fā)送心跳，使自己可以被選舉。

  (c) 當(dāng)自己被ZK選為主時(shí)，active FailoverController通過(guò)RPC調(diào)用使相應(yīng)的NN轉(zhuǎn)換為active。

2. 為什么要作為一個(gè)deamon進(jìn)程從NN分離出來(lái)

  (1) 防止因?yàn)镹N的GC失敗導(dǎo)致心跳受影響。

  (2) FailoverController功能的代碼應(yīng)該和應(yīng)用的分離，提高的容錯(cuò)性。

  (3) 使得主備選舉成為可插拔式的插件。

圖2 FailoverController架構(gòu)（從社區(qū)復(fù)制）

3. FailoverController主要包括三個(gè)組件，

  (1) HealthMonitor 監(jiān)控NameNode是否處于unavailable或unhealthy狀態(tài)。當(dāng)前通過(guò)RPC調(diào)用NN相應(yīng)的方法完成。

  (2) ActiveStandbyElector 管理和監(jiān)控自己在ZK中的狀態(tài)。

  (3) ZKFailoverController 它訂閱HealthMonitor 和ActiveStandbyElector 的事件，并管理NameNode的狀態(tài)。

QJM的設(shè)計(jì)

1. Namenode記錄了HDFS的目錄文件等元數(shù)據(jù)，客戶端每次對(duì)文件的增刪改等操作，Namenode都會(huì)記錄一條日志，叫做editlog，而元數(shù)據(jù)存儲(chǔ)在fsimage中。為了保持Stadnby與active的狀態(tài)一致，standby需要盡量實(shí)時(shí)獲取每條editlog日志，并應(yīng)用到FsImage中。這時(shí)需要一個(gè)共享存儲(chǔ)，存放editlog，standby能實(shí)時(shí)獲取日志。這有兩個(gè)關(guān)鍵點(diǎn)需要保證， 共享存儲(chǔ)是高可用的，需要防止兩個(gè)NameNode同時(shí)向共享存儲(chǔ)寫數(shù)據(jù)導(dǎo)致數(shù)據(jù)損壞。

2. 是什么，Qurom Journal Manager，基于Paxos（基于消息傳遞的一致性算法）。這個(gè)算法比較難懂，簡(jiǎn)單的說(shuō)，Paxos算法是解決分布式環(huán)境中如何就某個(gè)值達(dá)成一致，（ 一個(gè)典型的場(chǎng)景是，在一個(gè)分布式數(shù)據(jù)庫(kù)系統(tǒng)中，如果各節(jié)點(diǎn)的初始狀態(tài)一致，每個(gè)節(jié)點(diǎn)都執(zhí)行相同的操作序列，那么他們最后能得到一個(gè)一致的狀態(tài)。為保證每個(gè)節(jié)點(diǎn)執(zhí)行相同的命令序列，需要在每一條指令上執(zhí)行一個(gè)"一致性算法"以保證每個(gè)節(jié)點(diǎn)看到的指令一致）

    

   圖3 QJM架構(gòu)

3. 如何實(shí)現(xiàn)，

   (1) 初始化后，Active把editlog日志寫到2N+1上JN上，每個(gè)editlog有一個(gè)編號(hào)，每次寫editlog只要其中大多數(shù)JN返回成功（即大于等于N+1）即認(rèn)定寫成功。

   (2) Standby定期從JN讀取一批editlog，并應(yīng)用到內(nèi)存中的FsImage中。

   (3) 如何fencing： NameNode每次寫Editlog都需要傳遞一個(gè)編號(hào)Epoch給JN，JN會(huì)對(duì)比Epoch，如果比自己保存的Epoch大或相同，則可以寫，JN更新自己的Epoch到最新，否則拒絕操作。在切換時(shí)，Standby轉(zhuǎn)換為Active時(shí)，會(huì)把Epoch+1，這樣就防止即使之前的NameNode向JN寫日志，也會(huì)失敗。

   (4) 寫日志：

     (a) NN通過(guò)RPC向N個(gè)JN異步寫Editlog，當(dāng)有N/2+1個(gè)寫成功，則本次寫成功。

     (b) 寫失敗的JN下次不再寫，直到調(diào)用滾動(dòng)日志操作，若此時(shí)JN恢復(fù)正常，則繼續(xù)向其寫日志。

     (c) 每條editlog都有一個(gè)編號(hào)txid，NN寫日志要保證txid是連續(xù)的，JN在接收寫日志時(shí)，會(huì)檢查txid是否與上次連續(xù)，否則寫失敗。

   (5) 讀日志：

     (a) 定期遍歷所有JN，獲取未消化的editlog，按照txid排序。

     (b) 根據(jù)txid消化editlog。

   (6) 切換時(shí)日志恢復(fù)機(jī)制

     (a) 主從切換時(shí)觸發(fā)

     (b) 準(zhǔn)備恢復(fù)（prepareRecovery），standby向JN發(fā)送RPC請(qǐng)求，獲取txid信息，并對(duì)選出最好的JN。

     (c) 接受恢復(fù)（acceptRecovery），standby向JN發(fā)送RPC，JN之間同步Editlog日志。

     (d) Finalized日志。即關(guān)閉當(dāng)前editlog輸出流時(shí)或滾動(dòng)日志時(shí)的操作。

     (e) Standby同步editlog到最新

   (7) 如何選取最好的JN

     (a) 有Finalized的不用in-progress

     (b) 多個(gè)Finalized的需要判斷txid是否相等

     (c) 沒(méi)有Finalized的首先看誰(shuí)的epoch更大

     (d) Epoch一樣則選txid大的。

看完上述內(nèi)容是否對(duì)您有幫助呢？如果還想對(duì)相關(guān)知識(shí)有進(jìn)一步的了解或閱讀更多相關(guān)文章，請(qǐng)關(guān)注億速云行業(yè)資訊頻道，感謝您對(duì)億速云的支持。