一、HDFS的高可用性
1.概述
本指南提供了一個HDFS的高可用性（HA）功能的概述，以及如何配置和管理HDFS高可用性(HA)集群。本文檔假定讀者具有對HDFS集群的組件和節點類型具有一定理解。有關詳情，請參閱Apache的HDFS的架構指南。
http://hadoop.apache.org/docs/current/hadoop-yarn/hadoop-yarn-site/HDFSHighAvailabilityWithQJM.html
2.背景
CDH4之前，在HDFS集群中NameNode存在單點故障（SPOF）。對於只有一個NameNode的集群，如果NameNode機器出現故障，那么整個集群將無法使用，直到NameNode重新啟動。
NameNode主要在以下兩個方面影響HDFS集群:
(1). NameNode機器發生意外，比如宕機，集群將無法使用，直到管理員重啟NameNode
(2). NameNode機器需要升級，包括軟件、硬件升級，此時集群也將無法使用
HDFS的HA功能通過配置Active/Standby兩個NameNodes實現在集群中對NameNode的熱備來解決上述問題。如果出現故障，如機器崩潰或機器需要升級維護，這時可通過此種方式將NameNode很快的切換到另外一台機器。
3.架構
HDFSHA的解決方案可謂百花齊放，Linux HA, VMware FT, sharedNAS+NFS, BookKeeper, QJM/Quorum Journal Manager, BackupNode等等。目前普遍采用的是shard NAS+NFS，因為簡單易用，但是需要提供一個HA的共享存儲設備。而社區已經把基於QJM/Quorum Journal Manager的方案merge到trunk了，clouderea提供的發行版中也包含了這個feature，這種方案也是社區在未來發行版中默認的 HA方案。
在HA具體實現方法不同的情況下，HA框架的流程是一致的。不一致的就是如何存儲和管理日志。在Active NN和Standby NN之間要有個共享的存儲日志的地方，Active NN把EditLog寫到這個共享的存儲日志的地方，Standby NN去讀取日志然后執行，這樣Active和Standby NN內存中的HDFS元數據保持着同步。一旦發生主從切換Standby NN可以盡快接管Active NN的工作（雖然要經歷一小段時間讓原來Standby追上原來的Active，但是時間很短）。
說到這個共享的存儲日志的地方，目前采用最多的就是用共享存儲NAS+NFS。缺點有：1）這個存儲設備要求是HA的，不能掛掉；2）主從切換時需要 fencing方法讓原來的Active不再寫EditLog，否則的話會發生brain-split，因為如果不阻止原來的Active停止向共享存儲 寫EditLog，那么就有兩個Active NN了，這樣就會破壞HDFS的元數據了。對於防止brain-split問題，在QJM出現之前，常見的方法就是在發生主從切換的時候，把共享存儲上存 放EditLog的文件夾對原來的Active的寫權限拿掉，那么就可以保證同時至多只有一個Active NN，防止了破壞HDFS元數據。
Clouera為解決這個問題提出了QJM/Qurom Journal Manager，這是一個基於Paxos算法實現的HDFS HA方案。QJM的結構圖如下所示：
QJM的基本原理就是用2N+1台JournalNode存儲EditLog，每次寫數據操作有大多數（>=N+1）返回成功時即認為該次寫成功， 數據不會丟失了。當然這個算法所能容忍的是最多有N台機器掛掉，如果多於N台掛掉，這個算法就失效了。這個原理是基於Paxos算法的，可以參考http://en.wikipedia.org/wiki/Paxos_(computer_science)。
用QJM的方式來實現HA的主要好處有：1）不需要配置額外的高共享存儲，這樣對於基於commodityhardware的雲計算數 據中心來說，降低了復雜度和維護成本；2）不在需要單獨配置fencing實現，因為QJM本身內置了fencing的功能；3）不存在Single Point Of Failure；4）系統魯棒性的程度是可配置的（QJM基於Paxos算法，所以如果配置2N+1台JournalNode組成的集群，能容忍最多N台 機器掛掉）；5）QJM中存儲日志的JournalNode不會因為其中一台的延遲而影響整體的延遲，而且也不會因為JournalNode的數量增多而 影響性能（因為NN向JournalNode發送日志是並行的）。
摘自：http://blog.csdn.net/dangyifei/article/details/8920164