基於社群最新release的Hadoop2.2.0版本，調研了hadoop HA方面的內容。hadoop2.0主要的新特性(Hadoop2.0穩定版2.2.0新特性剖析)：

1. 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的內容。
2. 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
3. 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的設計。

總結

本文參考了網上一些資深研究者的部落格資料和HDFS JIRA上的一些內容，整理了一下NN HA方面的幾種實現方式，也提供了更多細緻和詳細的內容連結。

(全文完)