hdfs高可用性（HDFS High Availability）

Hadoop2.2.0中HDFS的高可用性實現原理

http://www.iteblog.com/archives/833

官方文檔

http://www.cloudera.com/content/cloudera-content/cloudera-docs/CDH4/latest/CDH4-High-Availability-Guide/cdh4hag_topic_2_1.html

http://kicklinux.com/quorum-based-storage-ha/

 

我自己參考官方文檔，翻譯總結CDH4中HDFS高可用性的實現原理

CDH4 主要采用兩種方案：

• Quorum-based Storage
• Shared storage using NFS

注：Cloudera建議采用Quorum-based Storage來作為HA的解決方案，因為Shared storage using NFS只在CDH4中支持，CDH5不支持。如果想從NFS轉換成Quorum-based Storage，請看 http://www.cloudera.com/content/cloudera-content/cloudera-docs/CDH4/latest/CDH4-High-Availability-Guide/cdh4hag_topic_2_7.html#concept_ddg_ryd_cm_unique_1

Quorum-based Storage

在 HDFS的集群中，存在NameNode單點故障(a single point of failure)，Quorum-based Storage方法大體上是：增加journalnode節點部署Quorum Journal Manager，通過quorum來進行日志管理。NameNode Active將editlog寫入到journalnode，Standby NameNode讀取journalnode的日志並應用到本地。當NameNode Active不可用時，Standby NameNode在執行完全部journalnode上的日志后變為Active狀態。

繼6月份推出CDH4后，Cloudera於本月推出了CDH4.1版(2013-08)（注：Cloudera每年會推出一個新的CDH版本，並且大約每隔3個月會對當前的CDH作一次更新）。除了常規的補丁和性能改善，這一更新包含了關於HDFS和安全性方面的幾個特性，值得關注一下。

在CDH4提供的HDFS HA實現機制里，一對Name Node共享NFS目錄。現在CDH4.1則添加了基於一組Quorum存儲並使用一種叫作Quorum Journal Manager(QJM)的新機制。在這種新機制里，為了使備用節點（Standby node）與活動節點（Active node）同步，兩個節點與一組獨立的守護進程JournalNodes通信。當主節點中的namespace發生任何修改，它則生成一系列日志記錄，並把它記錄在大部分JournalNodes中。備用節點只能讀取這些在JournalNodes中的文件，當這些文件已發生變化，備用節點則將讀取這些變化並應用到自己的namespace。在故障轉移過程中，備用節點在切換成主節點前，會保證它已經將log文件中的內容都應用到自己的namespace中。這樣就保證了namespace的狀態與故障發生前一致了。

為了提供一個快速的故障轉移，備用節點應該有關於集群中blocks位置的最新信息。為了達到這個目標，在DataNode中應該配置兩個NameNode（active，standby），並通過心跳向他們發送block的位置信息。

為了保證HA Cluster的正確操作，保證集群中在任何時刻只有一個NameNodes是非常重要的，否則，namespace將面臨着數據丟失或者其他不正確的結果。為了 確保Namespace狀態正確和防止所謂的 "split-brain scenario,"，JournalNodes只允許在一時刻只有一個節點能夠編輯這些文件也就是只能有一個節點充當writer。在故障轉移過程中， 備用主節點想要變成主節點，只需要簡單將其角色改為writer，這樣就有效的保證了只有一個活動節點，讓新的主節點安全地進行故障轉移。

和共享NFS目錄這種被動的純存儲機制相比， JournalNodes能夠防止接受多個NameNode同時對其寫操作（所以 “fencing”這一步驟不是必須的）。不過，采用該機制實現HA的集群就變成了必須依賴於JournalNode　Quorum才能正常工作。在這一點上，和HBase對Zookeeper的依賴有點類似。如果NameNode無法獲取JournalNode Quorum，HDFS則會無法格式化或無法啟動，會提示如下錯誤信息：

10/21/12 01:01:01 WARN namenode.FSEditLog: Unable to determine input streams from QJM to [10.0.1.10:8485, 10.0.1.10:8486, 10.0.1.10:8487]. Skipping. java.io.IOException: Timed out waiting 20000ms for a quorum of nodes to respond.

不過，這些JournalNode的負載不大，建議是可以運行在Master daemon的機器上。

在配置方面，除了常規HA外，需要指定JournalNode Quorum和JournalNode用於存儲的目錄位置。這兩者分別通過“dfs.namenode.shared.edits.dir”和“dfs.journalnode.edits.dir”來指定。

- Data Encryption

在安全性方面，CDH4.1加入了支持對 MRv1/MRv2 的Shuffle數據和Web UIs進行加密，以及對所有通過網絡傳輸的HDFS數據進行加密。

Shared Storage Using NFS

為了使備用節點（Standby node）與活動節點（Active node）同步，這種實現方案需要兩個節點可以訪問一個共享存儲設備（例如, an NFS mount from a NAS）.

 

當 主節點（Active node)對任何namespace進行了修改，它將產生一系列日志，並將這些log記錄編輯成log文件存儲在共享目錄中。備用節點一直關注着這個目 錄，當log文件一被編輯，備用節點則將這些改變應用到自己的namespace中。在故障轉移過程中，備用節點在切換成主節點前，會保證它已經將log 文件中的內容都應用到自己的namespace中。這樣就保證了namespace的狀態與故障發生前一致了。

 

為了提供一個快速的故障轉移，備用節點應該有關於集群中blocks位置的最新信息。為了達到這個目標，在DataNode中應該配置兩個NameNode（active，standby），並通過心跳向他們發送block的位置信息。

 

為 了保證HA Cluster的正確操作，保證集群中在任何時刻只有一個NameNodes是非常重要的，否則，namespace將面臨着數據丟失或者其他不正確的結 果。為了確保Namespace狀態正確和防止所謂的 "split-brain scenario,"，管理員必須配置至少一種防護方法來防止多個節點對共享文件的編輯。在故障轉移過程中，如果它不能驗證先前的主節點已經放棄了活動狀 態，這個防護進程則負責切斷先前主節點對共享文件的編輯，讓新的主節點安全地進行故障轉移。

 

Important:

When you use Quorum-based Storage, only one NameNode will ever be allowed to write to the JournalNodes, so there is no potential for corrupting the file system metadata in a "split-brain" scenario. But when a failover occurs, it is still possible that the previous Active NameNode could serve read requests to clients - and these requests may be out of date - until that NameNode shuts down when it tries to write to the JournalNodes. For this reason, it is still desirable to configure some fencing methods even when using Quorum-based Storage.