快捷導(dǎo)航

HDFS-Hadoop NameNode高可用機制

更新時間：2021年08月23日 10:27:57 作者：瘦風的南墻

本文詳細介紹了Hadoop NameNode高可用機制的各個方面內(nèi)容，NameNode 的可用性直接決定了 Hadoop 集群的可用性，感興趣的小伙伴可以參考本文章

1 - 為什么要高可用

在 Hadoop 中，NameNode 扮演著至關(guān)重要的角色 —— 整個 HDFS 文件系統(tǒng)的元數(shù)據(jù)信息都由 NameNode 管理，一旦 NameNode 進程出現(xiàn)異常，或者維護 NameNode 所在節(jié)點的時候，都會導(dǎo)致 HDFS 集群不可用。

所以 NameNode 的可用性直接決定了 Hadoop 集群的可用性。

2 - NameNode 的高可用發(fā)展史

在 Hadoop 2.0 以前，每個 HDFS 集群只有一個 NameNode，一旦這個節(jié)點不可用，則整個 HDFS 集群將處于不可用狀態(tài) —— 即，HDFS 2.0 以前，NameNode 存在單點故障風險。

與典型的 HA（High Availability，高可用）方案一樣（參考：常見的六種容錯機制），HDFS 2.0 開始支持的 HA，就是在 HDFS 集群中同時運行兩個 NameNode。

一個處于 Active（活躍）狀態(tài)：負責集群中所有客戶端的操作（修改命名空間、刪除備份數(shù)據(jù)塊等操作）；

另一個處于 Standby（備份）狀態(tài)：充當從服務(wù)器，和 Active NameNode 有相同的命名空間和元數(shù)據(jù)。

當 Active NameNode 停止服務(wù)時，Standby NameNode 能夠快速進行故障切換，以保證 HDFS 集群服務(wù)不受影響。

3 - HDFS 的高可用架構(gòu)

看圖：

Standby NemeNode 是如何做到故障切換的？換句話說，它和 Active NameNode 之間的數(shù)據(jù)是如何保持一致的？

3.1 Standby 和 Active 的命名空間保持一致

它們存儲著一樣的元數(shù)據(jù)，可以把集群恢復(fù)到系統(tǒng)奔潰時的狀態(tài) —— 這是實現(xiàn)自動故障切換的基礎(chǔ)。

為了使備份節(jié)點與活動節(jié)點的數(shù)據(jù)保持同步，兩個節(jié)點都需要同一組獨立運行的節(jié)點來通信，HDFS 中把這樣的節(jié)點稱為 JournalNode。

1）第一關(guān)系鏈的一致性，即 Active NameNode 和 Standby NameNode 的命名空間狀態(tài)的一致性：

a）Active NameNode 會定期地把修改命名空間或刪除備份數(shù)據(jù)塊等操作記錄到 EditLog，同時寫到 JN 的多數(shù)節(jié)點中。

b）Standby NameNode 會一直監(jiān)聽 JN 上 EditLog的變化，如果 editlog 有改動，Standby NameNode 就會讀取 editlog 并與當前的命名空間合并。

c）Active NameNode 出現(xiàn)故障時，Standby NameNode 會保證已經(jīng)從 JN 上讀取了所有 editlog 并與命名空間合并，然后才會從 Standby 切換為 Active。

2）第二關(guān)系鏈的一致性，即數(shù)據(jù)塊的存儲信息的一致性：

為了使故障切換能夠盡快執(zhí)行成功，就要保證 Standby NameNode 也實時保存了數(shù)據(jù)塊的存儲信息，HDFS 中是這樣做的：

DataNode 會同時向兩個 NameNode 發(fā)送心跳以及塊的存儲信息。

這樣以來，發(fā)生故障切換時，Standby NameNode 就可以直接切換到 Active 狀態(tài)（它和舊 Active 節(jié)點的元數(shù)據(jù)完全一致），而不需要等待所有的 DataNode 匯報全量數(shù)據(jù)塊信息 —— 這也是熱備功能。

需要注意：Standby NameNode 只會更新數(shù)據(jù)塊的存儲信息，并不會向 DataNode 發(fā)送復(fù)制或刪除數(shù)據(jù)塊的指令，這些指令只能由 Active NameNode 發(fā)送。

3.2 同一時刻只有一個 Active NameNode

如果兩個 NameNode 都是活躍狀態(tài)，那么這個集群就會被分成2個小集群，它們都認為自己是唯一活動的集群。這就是著名的“腦裂”現(xiàn)象。

腦裂的 HDFS 集群很可能造成數(shù)據(jù)錯亂、丟失數(shù)據(jù)塊，還可能向 DataNode 下發(fā)錯誤的指令，這些錯誤都很難恢復(fù)。

4 - HDFS 高可用的實現(xiàn)原理

這里主要介紹通過隔離（fencing）和 Quorum Journal Manager（QJM）共享存儲實現(xiàn)的 HDFS 高可用。

4.1 隔離（Fencing）- 預(yù)防腦裂

預(yù)防腦裂的常見方案就是 Fencing，即隔離，思路是把舊的 Active NameNode 隔離起來，使它不能正常對外提供服務(wù)，使集群在任何時候都只有一個 Active NameNode。

HDFS 提供了 3 個級別的隔離（Fencing）：

1）共享存儲隔離：同一時間只允許一個 NameNode 向 JournalNode 寫入 EditLog 數(shù)據(jù)。

2）客戶端隔離：同一時間只允許一個 NameNode 可以響應(yīng)客戶端的請求。

3）DataNode 隔離：同一時間只允許一個 NameNode 向 DataNode 下發(fā)命名空間相關(guān)的命令，例如刪除塊，復(fù)制塊等。

4.2 Qurom Journal Manager 共享存儲

在 HDFS 的 HA 架構(gòu)中還有一個非常重要的部分：Active NameNode 和 Standby NameNode 之間如何共享 EditLog 文件。

解決思路是：Active NameNode 將日志文件寫到共享存儲上，Standby NameNode 實時地從共享存儲讀取 EditLog 文件，然后合并到 Standby NameNode 的命名空間中。一旦 Active NameNode 發(fā)生錯誤，Standby NameNode 就可以立即切換到Active狀態(tài)。

HDFS 2.6 開始，提供了一個叫做 Qurom Journal Manager（QJM）的共享存儲方案，來解決 HA 架構(gòu)中元數(shù)據(jù)的共享存儲問題。

QJM 基于 Paxos 算法實現(xiàn)，基本原理是：HDFS 集群中有 2n+1 臺 JournalNode，EditLog 保存在 JN 的本地磁盤上；

每個 JournalNode 都允許 NmaeNode 通過它的 RPC 接口讀寫 EditLog 文件；

當 NmaeNode 向共享存儲寫入 EditLog 文件時，它會通過 QJM 向集群中所有的 JournalNode 并行發(fā)送寫 EditLog 文件的請求，當有一半以上（>=n+1）的 JN 返回寫操作成功時，就認為這次寫操作成功了。

每次寫數(shù)據(jù)操作有多數(shù)（>=n+1）JN 返回成功，就認為這次寫操作成功了。

由此我們可以知道，這個 QJM 必須也是高可用的，否則 HDFS 的高可用就無法保障。

QJM 實現(xiàn) HA 的主要好處：

不存在單點故障問題；

不需要配置額外的共享存儲，降低了復(fù)雜度和維護成本；

不需要單獨配置 Fencing 實現(xiàn)（見文末#5.1節(jié)），因為 QJM 本身就內(nèi)置了 Fencing 的功能；

系統(tǒng)的魯棒性程度是可配置的（ QJM 基于 Paxos 算法，配置 2n+1 臺 JournalNode，最多能容忍 n 臺機器同時掛掉）；

QJM 中存儲日志的 JournalNode 不會因為其中一臺的延遲而影響整體的延遲，而且也不會因為 JournalNode 的數(shù)量增多而影響性能（因為 NameNode 向 JournalNode 發(fā)送日志是并行的）。

關(guān)于 QJM 的具體工作原理，后面有機會了專門講講。

5 - 其他補充

5.1 QJM 的 Fencing 方案

QJM 的 Fencing 只能讓原來的 Active NN 失去對 JN 的寫權(quán)限，但是原來的 Active NN 還是可以響應(yīng)客戶端的請求，對 DataNode 進行讀操作。

對客戶端和 DataNode 的隔離是通過配置 dfs.ha.fencing.methods 實現(xiàn)的，Hadoop 公共庫中有兩種 Fencing 實現(xiàn)：

shell：即執(zhí)行一個用戶事先定義的 shell 命令或腳本來完成隔離。

sshfence：ssh 到原 Active NN 上，使用 fuser 結(jié)束進程（通過 TCP 端口號定位進程 pid，比 jps 命令更準確）。

5.2 - HDFS 高可用組件簡介

5.2.1 ZKFailoverController

是基于 ZooKeeper 的故障轉(zhuǎn)移控制器，它負責控制 NameNode 的主備切換，ZKFailoverController 會監(jiān)測NameNode 的健康狀態(tài)，當發(fā)現(xiàn) Active NameNode 出現(xiàn)異常時會通過 ZooKeeper 進行一次新的選舉，完成 Active 和 Standby 狀態(tài)的切換。