關於Hadoop 2.x的HA：
在Hadoop2.0.0之前，NameNode(NN)在HDFS集羣中存在單點故障（single point of failure），每一個集羣中存在一個NameNode，如果NN所在的機器出現了故障，那麼將導致整個集羣無法利用，直到NN重啓或者在另一臺主機上啓動NN守護線程。
主要在兩方面影響了HDFS的可用性：
（1）、在不可預測的情況下，如果NN所在的機器崩潰了，整個集羣將無法利用，直到NN被重新啓動；
（2）、在可預知的情況下，比如NN所在的機器硬件或者軟件需要升級，將導致集羣宕機。
HDFS的高可用性將通過在同一個集羣中運行兩個NN（active NN & standby NN）來解決上面兩個問題，這種方案允許在機器破潰或者機器維護快速地啓用一個新的NN來恢復故障。
在典型的HA集 羣中，通常有兩臺不同的機器充當NN。在任何時間，只有一臺機器處於Active狀態；另一臺機器是處於Standby狀態。Active NN負責集羣中所有客戶端的操作；而Standby NN主要用於備用，它主要維持足夠的狀態，如果必要，可以提供快速的故障恢復。
爲了讓 Standby NN的狀態和Active NN保持同步，即元數據保持一致，它們都將會和JournalNodes守護進程通信。當Active NN執行任何有關命名空間的修改，它需要持久化到一半以上的JournalNodes上(通過edits log持久化存儲)，而Standby NN負責觀察edits log的變化，它能夠讀取從JNs中讀取edits信息，並更新其內部的命名空間。一旦Active NN出現故障，Standby NN將會保證從JNs中讀出了全部的Edits，然後切換成Active狀態。Standby
NN讀取全部的edits可確保發生故障轉移之前，是和Active NN擁有完全同步的命名空間狀態。
爲了提供快速的故障恢復，Standby NN也需要保存集羣中各個文件塊的存儲位置。爲了實現這個，集羣中所有的Database將配置好Active NN和Standby NN的位置，並向它們發送塊文件所在的位置及心跳，如下圖所示：
Hadoop2.2.0中HDFS的高可用性實現原理
在任何時候，集羣中只有一個NN處於Active 狀態是極其重要的。否則，在兩個Active NN的狀態下NameSpace狀態將會出現分歧，這將會導致數據的丟失及其它不正確的結果。爲了保證這種情況不會發生，在任何時間，JNs只允許一個 NN充當writer。在故障恢復期間，將要變成Active 狀態的NN將取得writer的角色，並阻止另外一個NN繼續處於Active狀態。
爲了部署HA集羣，你需要準備以下事項：
（1）、NameNode machines：運行Active NN和Standby NN的機器需要相同的硬件配置；
（2）、JournalNode machines：也就是運行JN的機器。JN守護進程相對來說比較輕量，所以這些守護進程可以可其他守護線程（比如NN，YARN ResourceManager）運行在同一臺機器上。在一個集羣中，最少要運行3個JN守護進程，這將使得系統有一定的容錯能力。當然，你也可以運行3 個以上的JN，但是爲了增加系統的容錯能力，你應該運行奇數個JN（3、5、7等），當運行N個JN，系統將最多容忍(N-1)/2個JN崩潰。
在HA集羣中，Standby NN也執行namespace狀態的checkpoints，所以不必要運行Secondary NN、CheckpointNode和BackupNode；事實上，運行這些守護進程是錯誤的。
這裏再引用一下另一篇關於Hadoop的高可用性原理：
hadoop2.0HA的基本原理和2種方式。
1 概述
在hadoop2.0之前，namenode只有一個，存在單點問題（雖然hadoop1.0有secondarynamenode，checkpointnode，buckcupnode這些，但是單點問題依然存在），在hadoop2.0引入了HA機制。hadoop2.0的HA機制官方介紹了有2種方式，一種是NFS（Network File System）方式，另外一種是QJM（Quorum Journal Manager）方式。
2 基本原理
hadoop2.0的HA 機制有兩個namenode，一個是active namenode，狀態是active；另外一個是standby namenode，狀態是standby。兩者的狀態是可以切換的，但不能同時兩個都是active狀態，最多隻有1個是active狀態。只有active namenode提供對外的服務，standby namenode是不對外服務的。active namenode和standby namenode之間通過NFS或者JN（journalnode，QJM方式）來同步數據。
active namenode會把最近的操作記錄寫到本地的一個edits文件中（edits file），並傳輸到NFS或者JN中。standby namenode定期的檢查，從NFS或者JN把最近的edit文件讀過來，然後把edits文件和fsimage文件合併成一個新的fsimage，合併完成之後會通知active namenode獲取這個新fsimage。active namenode獲得這個新的fsimage文件之後，替換原來舊的fsimage文件。
這樣，保持了active namenode和standby namenode的數據的實時同步，standby namenode可以隨時切換成active namenode（譬如active namenode掛了）。而且還有一個原來hadoop1.0的secondarynamenode，checkpointnode，buckcupnode的功能：合併edits文件和fsimage文件，使fsimage文件一直保持更新。所以啓動了hadoop2.0的HA機制之後，secondarynamenode，checkpointnode，buckcupnode這些都不需要了。
3 NFS方式
NFS作爲active namenode和standby namenode之間數據共享的存儲。active namenode會把最近的edits文件寫到NFS，而standby namenode從NFS中把數據讀過來。這個方式的缺點是，如果active namenode或者standby namenode有一個和NFS之間網絡有問題，則會造成他們之前數據的同步出問題。
4 QJM（Quorum Journal Manager ）方式
QJM的方式可以解決上述NFS容錯機制不足的問題。active namenode和standby namenode之間是通過一組journalnode（數量是奇數，可以是3,5,7...,2n+1）來共享數據。active namenode把最近的edits文件寫到2n+1個journalnode上，只要有n+1個寫入成功就認爲這次寫入操作成功了，然後standby namenode就可以從journalnode上讀取了。可以看到，QJM方式有容錯的機制，可以容忍n個journalnode的失敗。
5 主備節點的切換
active namenode和standby namenode可以隨時切換。當active namenode掛掉後，也可以把standby namenode切換成active狀態，成爲active namenode。可以人工切換和自動切換。人工切換是通過執行HA管理的命令來改變namenode的狀態，從standby到active，或者從active到standby。自動切換則在active namenode掛掉的時候，standby namenode自動切換成active狀態，取代原來的active namenode成爲新的active namenode，HDFS繼續正常工作。
主備節點的自動切換需要配置zookeeper。active namenode和standby namenode把他們的狀態實時記錄到zookeeper中，zookeeper監視他們的狀態變化。當zookeeper發現active namenode掛掉後，會自動把standby namenode切換成active namenode。
6 實戰tips
- QJM方式有明顯的優點，一是本身就有fencing的功能，二是通過多個journal節點增強了系統的健壯性，所以建議在生成環境中採用QJM的方式。
- journalnode消耗的資源很少，不需要額外的機器專門來啓動journalnode，可以從hadoop集羣中選幾臺機器同時作爲journalnode。
PS:
---主備NameNode
---解決點單故障
主Namenode對外提供服務，備用Namenode同步主Namenode元數據
所有Datanode同時向兩個Namenode彙報數據塊信息
---兩種切換選擇
手動切換：通過命令實現主備之間的切換，可以用HDFS升級等場合
自動切換：基於Zookeeper實現
---基於Zookeeper自動切換方案
Zookeeper FiloverController：監控Namenode健康狀態
並向Zookeeper註冊Namenode
Namenode掛掉後，ZKFC爲Namenode競爭鎖，獲得ZKFC鎖的Namenode變爲active