91
Hadoop2.0 Namenode HA實現方案介紹及匯總
基於社區最新release的Hadoop2.2.0版本，調研了hadoop HA方麵的內容。hadoop2.0主要的新特性(Hadoop2.0穩定版2.2.0新特性剖析)：
- hdfs snapshots: apache官方對hdfs snapshots說明
- namenode federation: namenode在集群規模大了之後會成為性能瓶頸，尤其是內存使用量急劇增大，同時hdfs所有元數據信息的讀取和操作都要與namenode通信。而聯邦模式解決的就是namenode的可擴展性問題。更多內容可以參看hadoop
2.0 namenode HA實戰和federation實踐 下圖是我畫的HA和Federation部署圖。每個namesevice映射了HDFS中部分實際路徑，可以單獨給Client提供服務，也可以由Client通過Client Mount Table來訪問若幹NS。圖中每個NS裏有一個active NN和一個standby NN，這部分HA會在下麵介紹。每個NS對應了一個Pool，Pool對應的DN是該NS可以訪問的DN id的集合。這樣做到可擴展，帶來的好處有很多，比如後續添加的NS不會影響之前的NS等。聯邦部署適合大規模集群，一般規模不大的情況下不需要使用。下麵主要介紹HA的內容。
- namenode單點故障解決方案。NN現在的HA解決方案主要思路是提供一個保存元數據信息的地方，保證editlog不會丟失。董的這篇HA單點故障解決方案總結中介紹了從解決MRv1的Jobtracker HA，到HDFS HA，再到還未正式發布的YARN RM HA解決方案的異同，各自采用的共享存儲係統有所不同，主要原因是HA的解決方案難度取決於Master自身記錄信息的多少和信息可重構性。共享存儲係統主要有NFS，ZK，BookKeeper，QJM。其中已經發行版本裏默認使用的QJM(Quaro Journal Manager)。QJM是Cloudera公司提出的，在QJM出現前，如果在主從切換的這段時間內出現腦裂，破壞HDFS元數據的時候，常見方式是去掉activeNN的寫權限來保證最多隻有一個active NN。QJM本質上是Paxos算法的實現，通過啟動2N+1個JournalNode來寫editlog，當其中大於N個Node寫成功時候認為本次寫成功，且允許容忍N以下個Node掛掉。QJM實現及源碼分析可以參考基於QJM的HDFS HA原理及代碼分析。QJM和BKJM(借助BookKeeper實現的JM)都是將editlog信息寫在磁盤上，這點也是與NFS方案的區別，且NFS相對而言其實更重量級，本身是一個需要獨立維護的東西，而QJM是已經實現的默認方案，配置方法在官方裏也可以找到，很詳細。BKJM正在實現中且長期看好。關於BookKeeper相關的JIRA進展可以參考 BookKeeper Option For NN HA。所以總結來說推薦使用QJM和BKJM，且他們的原理比較相似。再給出HDFS JIRA上一份cloudera員工給的Quorum-Journal Design設計文檔，地址為https://issues.apache.org/jira/secure/attachment/12547598/qjournal-design.pdf
- hdfs symbo links將在2.3.0裏發布。類似linux文件係統的軟鏈接。相關資料可以參考理解 Linux 的硬鏈接與軟鏈接 硬連接和軟連接的原理
其實現在的HA方案，很大程度上參考的是Facebook的AvatarNode的NN HA方案，隻是他是手動的。Facebook的AvatarNode是業界較早的Namenode HA方案，它是基於HDFS 0.20實現的，如下圖所示。
由於采用的是人工切換，所以實現相對簡單。AvatarNode對Namenode進行了封裝，處於工作狀態的叫Primary Avatar，處於熱備狀態的叫Standby Avatar(封裝了Namenode和SecondaryNameNode)，兩者通過NFS共享EditLog所在目錄。在工作狀態下，Primary Avatar中的Namenode實例接收Client的請求並進行處理，Datanode會向Primary和Standby兩個同時發送blockReport和心跳，Standby Avatar不斷地從共享的EditLog中持續寫入的新事務，並推送給它的Namenode實例，此時Standby Avatar內部的Namenode處於安全模式狀態，不對外提供服務，但是狀態與Primary Avatar中的保持一致。一旦Primary發生故障，管理員進行Failover切換：首先將原來的Primary進程殺死(避免了“Split Brain”和“IO Fencing”問題)，然後將原來的Standby設置為Primary，新的Primary會保證回放完成所有的EditLog事務，然後退出安全模式，對外接收服務請求。為了實現對客戶端透明，AvatarNode主從采用相同的虛擬IP，切換時將新的Primary設置為該虛擬IP即可。整個流程可在秒~分鍾級別完成。可以參考FaceBook 2011年的論文 Apache Hadoop Goes Realtime at Facebook 裏麵專門有一節講到HA AvatarNode的設計。
在董的博客裏還談到hadoop 2.0尚未解決的問題，提到namenode的熱備現在隻能是一個，且共享存儲係統也隻能有一套，本質上還是單點故障，其實是做了一層轉移。YARN的HA還沒解決。多資源存儲可能存在潛在問題。這裏關於YARN RM的HA的話，可以繼續跟進JIRA上的情況，JIRA地址為https://issues.apache.org/jira/browse/YARN-149，裏麵有RM HA的設計思路，最新的兩篇文檔：YARN ResourceManager Automatic Failover 和 RM HA Phase1: Cold Standby 關注這個問題的朋友可以跟進關注一下。
總結
本文參考了網上一些資深研究者的博客資料和HDFS JIRA上的一些內容，整理了一下NN HA方麵的幾種實現方式，也提供了更多細致和詳細的內容鏈接。
(全文完)
最後更新：2017-04-03 14:54:03