HDFS（二）高可用架構

引言

在 hadoop 1.x 的 HDFS 框架中只存在一個 namenode 節點，當這個 namenode 節點出現內存溢出、宕機等意外狀況以後，整個系統就會中止服務，直到咱們重啓這個 namenode 節點。爲了解決這個問題，在 hadoop2.x 的 HDFS 框架中，實現了 HA 的機制，接下來咱們來看看 2.x 中的這個機制是如何保證系統的高可用。

架構

1.x 只存在一個 namenode 纔不能保證系統長時間運行，所以第一個關鍵點就是爲這個系統多添加幾個 namenode 節點，當其中一個 namenode 掛掉以後，其餘 namenode 頂上提供服務，不過存在多個 namenode 會提升系統的複雜性，所以在 2.x 的 HDFS 高可用架構，只配備了兩個 namenode 節點（active 和 standby）。系統運行過程當中，只有 active 節點纔對外提供服務，standby 節點負責同步 edit 文件，與本地的 fsimage 文件合併，這樣就保證它們存儲數據的一致性了。

共享內存

可是在同步 edit 文件也有面臨一個問題，即是同步 edit 文件的頻率改如何設定？若是 active 每插入一條文件，standby 就要同步一條數據，那麼系統的性能就會降低很多；若是按照必定的時間間隔去同步 edit 文件，那麼系統就有可能存在丟失數據的風險，所以第二個關鍵點就是設計能夠共享 edit 文件的系統，active 節點負責往這個系統的 edit 文件寫入數據，standby 節點負責同步這個系統中的 edit 文件。

因爲這個系統存儲着 edit 文件，所以咱們要保證這個系統也是高可用的，hadoop 提供了兩個方案 -- QJM（Quorum Journal Manager） 和 NFS，我將重點放在 QJM 上，想要了解 NFS 的小夥伴能夠看下 這篇博客 。QJM 包含 2N+1 個 journal 節點，每一個 journal 節點提供了一個簡單的 RPC 接口，容許 namenode 讀取或寫入數據。當 namenode 寫入 edit 文件時，它向集羣中的 journal node 發送寫入請求，只有當 N+1 個節點寫入成功時，才表明客戶端的寫入是成功的。

腦裂

如今系統的架構愈來愈清晰了，兩個 namenode 節點，一個共享 edit 文件系統，active 節點寫入數據，standby 節點同步 edit 文件，系統看似能夠長時間提供服務了，但其中仍是存在問題。假設有這樣一種場景，active 節點運行過程當中網絡斷了，此時系統誤覺得其不能提供服務了，將 standby 節點轉變爲 active 節點了。但是以前的 active 節點網絡恢復以後仍是能夠提供服務的，這時系統中就存在兩個 namenode 節點，運行過程當中就會存在各類各樣的問題了，這種狀況稱爲腦裂。這就是 HA 機制的第三個關鍵點 -- 如何防止腦裂問題的發生。

在 QJM 中，是經過 epoch 數來解決腦裂問題的。當 namenode 變爲 active 狀態時，會分配到一個 epoch 數，這個數是獨一無二的，而且比以前的全部 namenode 持有的 epoch 數要高。當 namenode 向 journal 發送消息時，會帶上這個數。journal node 收到消息時，只有當這個 epoch 比本地存儲的 opoch 數大時纔會處理該請求，不然拒絕這次請求。

經過 epcho 數只是切斷了這個 namenode 和 journal node 集羣的通訊，可是客戶端仍然能夠和這個 namenode 通訊，因爲這個 namenode 不能和 journal node 通訊，所以沒法處理客戶端的請求，這樣就會致使客戶端沒法對系統就行操做，爲了解決這個問題，HDFS 提供了 fencing 機制，當 standby 節點轉變爲 active 節點時，會經過 ssh 的方式發送一條命令，殺掉另外一臺機器上的 namenode 進程，確保系統只有一個 active 的 namenode 節點存在，這樣就解決了腦裂的問題。

故障轉移

上面的內容只是講到了當 namenode 不能提供服務以後咱們的解決方案，可是並無提到咱們如何檢測 namenode 是否掛掉了，以及如何將 stangdy 節點轉變爲 active 節點。這就是 HA 機制的第四個關鍵點 -- 何時以及如何進行故障轉移。

如下部分參考 blog.csdn.net/Androidlush…

爲了檢測 namenode 是否掛掉，HDFS 引入了 zookeeper，當一個 namenode 被成功切換爲 active 狀態時，它會在 zookeeper 內部建立一個臨時的 znode，在這個 znode 中將保留當前 active nodenode 的一些信息，好比主機名等等。當 active nanode 出現失敗的狀況下，監控程序會將 zookeeper 上對應的臨時 znode 刪除，znode 的刪除事件會主動觸發到下一次的 active namenode 的選擇。

爲了解決故障轉移的問題，HDFS 引入了 ZKFC（ZKFailoverController） 組件，它是 HDFS HA 自動切換的核心對象，也就是咱們日常在 namenode 節點上啓動的 ZKFC 進程，在這個進程內部，運行這 3 個服務對象：

• HealthMonitor：監控 namenode 是否不可用或是進入了一個不健康的狀態
• ActiveStandbyElector：控制和監控 ZK 上的節點狀態
• ZKFailoverController：協調 HealMonitor 和 ActiverStandbyElector 對象，處理它們發來的 event 變化事件，完成自動切換的過程。

當 HealthMonitor 檢測到當前 namenode 不健康時，ZKFailoverController 會調用 ActiveStandbyElector 中的 quitElection 方法，從而使自身暫時退出 Active 狀態；若是 namenode 狀態健康，則會調用 ActiveStandbyElector 中的 joinElection，參與 namenode 的選舉。這是故障轉移的大體過程，詳細的源碼分析能夠參考上面那篇文章。

把 HDFS 中的四個關鍵點解決了以後，咱們對於 HA 機制也有了充分的瞭解，下面給出它的總體架構圖：

以上是我對 HDFS HA 機制的總結，若是當中存在錯誤，歡迎指出！