大數據學習筆記：Hadoop之HDFS（下）

02-12

Hadoop中NameNode單點故障解決方案

Hadoop 1.0內核主要由兩個分支組成：MapReduce和HDFS,這兩個系統的設計缺陷是單點故障，即MR的JobTracker和HDFS的NameNode兩個核心服務均存在單點問題，這裡只討論HDFS的NameNode單點故障的解決方案。

[問題]

HDFS仿照google GFS實現的分散式存儲系統，由NameNode和DataNode兩種服務組成，其中NameNode是存儲了元數據信息（fsimage）和操作日誌（edits），由於它是唯一的，其可用性直接決定了整個存儲系統的可用性。因為客戶端對HDFS的讀、寫操作之前都要訪問name node伺服器，客戶端只有從name node獲取元數據之後才能繼續進行讀、寫。一旦NameNode出現故障，將影響整個存儲系統的使用。

[解決方案]

Hadoop官方提供了一種quorum journal manager來實現高可用，在高可用配置下，edit log不再存放在名稱節點，而是存放在一個共享存儲的地方，這個共享存儲由若干Journal Node組成，一般是3個節點(JN小集群)，每個JN專門用於存放來自NN的編輯日誌，編輯日誌由活躍狀態的名稱節點寫入。

要有2個NN節點，二者之中只能有一個處於活躍狀態（active），另一個是待命狀態（standby），只有active節點才能對外提供讀寫HDFS服務，也只有active態的NN才能向JN寫入編輯日誌；standby的名稱節點只負責從JN小集群中的JN節點拷貝數據到本地存放。另外，各個DATA NODE也要同時向兩個NameNode節點報告狀態(心跳信息、塊信息)。

一主一從的2個NameNode節點同時和3個JN構成的組保持通信，活躍的NameNode節點負責往JN集群寫入編輯日誌，待命的NN節點負責觀察JN組中的編輯日誌,並且把日誌拉取到待命節點（接管Secondary NameNode的工作）。再加上兩節點各自的fsimage鏡像文件，這樣一來就能確保兩個NN的元數據保持同步。一旦active不可用，standby繼續對外提供服。架構分為手動模式和自動模式，其中手動模式是指由管理員通過命令進行主備切換，這通常在服務升級時有用，自動模式可降低運維成本，但存在潛在危險。這兩種模式下的架構如下。

[手動模式]

模擬流程:

1. 準備3台伺服器分別用於運行JournalNode進程（也可以運行在date node伺服器上），準備2台namenode伺服器用於運行NameNode進程（兩台配置要一樣），DataNode節點數量不限。

2. 分別啟動3台JN伺服器上的JournalNode進程，分別在date node伺服器啟動DataNode進程。

3. 需要同步2台name node之間的元數據。具體做法：從第一台NN拷貝元數據到放到另一台NN，然後啟動第一台的NameNode進程,再到另一台名稱節點上做standby引導。

4. 把第一台名節點的edit日誌初始化到JN節點，以供standby節點到JN節點拉取數據。

5. 啟動standby狀態的NameNode節點，這樣就能同步fsimage文件。

6. 模擬故障，手動把active狀態的NN故障，轉移到另一台NameNode。

[自動模式]

模擬流程：

在手動模式下引入了ZKFC（DFSZKFailoverController）和zookeeper集群

ZKFC主要負責: 健康監控、session管理、leader選舉

zookeeper集群主要負責：服務同步

1-6步同手動模式

7. 準備3台主機安裝zookeeper，3台主機形成一個小的zookeeper集群.

8. 啟動ZK集群每個節點上的QuorumPeerMain進程

9. 登錄其中一台NN, 在ZK中初始化HA狀態

10. 模擬故障：停掉活躍的NameNode進程，提前配置的zookeeper會把standby節點自動變為active,繼續提供服務。

腦裂

腦裂是指在主備切換時，由於切換不徹底或其他原因，導致客戶端和Slave誤以為出現兩個active master，最終使得整個集群處於混亂狀態。解決腦裂問題，通常採用隔離(Fencing)機制。

共享存儲fencing：確保只有一個Master往共享存儲中寫數據，使用QJM實現fencing。

Qurom Journal Manager，基於Paxos（基於消息傳遞的一致性演算法），Paxos演算法是解決分散式環境中如何就某個值達成一致。

[原理]

a. 初始化後，Active把editlog日誌寫到JN上，每個editlog有一個編號，每次寫editlog只要其中大多數JN返回成功（過半）即認定寫成功。

b. Standby定期從JN讀取一批editlog，並應用到內存中的FsImage中。

c. NameNode每次寫Editlog都需要傳遞一個編號Epoch給JN，JN會對比Epoch，如果比自己保存的Epoch大或相同，則可以寫，JN更新自己的Epoch到最新，否則拒絕操作。在切換時，Standby轉換為Active時，會把Epoch+1，這樣就防止即使之前的NameNode向JN寫日誌，也會失敗。

客戶端fencing：確保只有一個Master可以響應客戶端的請求。

[原理]

在RPC層封裝了一層，通過FailoverProxyProvider以重試的方式連接NN。通過若干次連接一個NN失敗後嘗試連接新的NN，對客戶端的影響是重試的時候增加一定的延遲。客戶端可以設置重試此時和時間

Slave fencing：確保只有一個Master可以向Slave下發命令。

[原理]

a. 每個NN改變狀態的時候，向DN發送自己的狀態和一個序列號。

b. DN在運行過程中維護此序列號，當failover時，新的NN在返回DN心跳時會返回自己的active狀態和一個更大的序列號。DN接收到這個返回是認為該NN為新的active。

c. 如果這時原來的active（比如GC）恢復，返回給DN的心跳信息包含active狀態和原來的序列號，這時DN就會拒絕這個NN的命令。