Hadoop 1.0核心主要由兩個分支組成：MapReduce和HDFS，眾所周知，這兩個系統的設計缺陷是單點故障，即MR的JobTracker和HDFS的NameNode兩個核心服務均存在單點問題，該問題在很長時間內沒有解決，這使得Hadoop在相當長時間內僅適合離線儲存和離線計算。

令人欣慰的是，這些問題在Hadoop 2.0中得到了非常完整的解決。Hadoop 2.0核心由三個分支組成，分別是HDFS、MapReduce和YARN，而Hadoop生態系統中的其他系統，比如HBase、Hive、Pig等，均是基於這三個系統開發的。截止本文釋出，Hadoop 2.0的這三個子系統的單點故障均已經解決或者正在解決（Hadoop HA），本文將為大家介紹當前的進度和具體的解決方案。

在正式介紹單點故障解決方案之前，先簡要回顧一下這三個系統（三個系統均採用簡單的master/slaves架構，其中master是單點故障）。

（1） HDFS：仿照google GFS實現的分散式儲存系統，由NameNode和DataNode兩種服務組成，其中NameNode是儲存了元資料資訊（fsimage）和操作日誌（edits），由於它是唯一的，其可用性直接決定了整個儲存系統的可用性；

（2）YARN：Hadoop 2.0中新引入的資源管理系統，它的引入使得Hadoop不再侷限於MapReduce一類計算，而是支援多樣化的計算框架。它由兩類服務組成，分別是ResourceManager和NodeManager，其中，ResourceManager作為整個系統的唯一元件，存在單點故障問題；

（3）：目前存在兩種MapReduce實現，分別是可獨立執行的MapReduce，它由兩類服務組成，分別是JobTracker和TaskTraker，其中JobTracker存在單點故障問題，另一個是MapReduce On YARN，在這種實現中，每個作業獨立使用一個作業跟蹤器（ApplicationMaster），彼此之間不再相互影響，不存在單點故障問題。本文提到的單點故障實際上是第一種實現中JobTracker的單點故障。

先說當前Hadoop單點故障的解決進度，截止本文釋出時，HDFS單點故障已經解決，且提供了兩套可行方案；MapReduce單點故障（JobTracker）由CDH4（CDH4同時打包了MRv1和MRv2，這裡的單點故障指的是MRv1的單點問題）解決，且已經發布；YARN單點故障尚未解決，但方案已經提出，由於解決方案借鑑了HDFS HA和MapReduce HA的實現，因為將會很快得到解決。

總體上說，Hadoop中的HDFS、MapReduce和YARN的單點故障解決方案架構是完全一致的，分為手動模式和自動模式，其中手動模式是指由管理員通過命令進行主備切換，這通常在服務升級時有用，自動模式可降低運維成本，但存在潛在危險。這兩種模式下的架構如下。

【手動模式】

【自動模式】

在Hadoop HA中，主要由以下幾個元件構成：

（1）MasterHADaemon：與Master服務執行在同一個程序中，可接收外部RPC命令，以控制Master服務的啟動和停止；

（2）SharedStorage：共享儲存系統，active master將資訊寫入共享儲存系統，而standby master則讀取該資訊以保持與active master的同步，從而減少切換時間。常用的共享儲存系統有zookeeper（被YARN HA採用）、NFS（被HDFS HA採用）、HDFS（被MapReduce HA採用）和類bookeeper系統（被HDFS HA採用）。

（3）ZKFailoverController：基於Zookeeper實現的切換控制器，主要由兩個核心元件構成：ActiveStandbyElector和HealthMonitor，其中，ActiveStandbyElector負責與zookeeper叢集互動，通過嘗試獲取全域性鎖，以判斷所管理的master進入active還是standby狀態；HealthMonitor負責監控各個活動master的狀態，以根據它們狀態進行狀態切換。。

（4）Zookeeper叢集：核心功能通過維護一把全域性鎖控制整個叢集有且僅有一個active master。當然，如果ShardStorge採用了zookeeper，則還會記錄一些其他狀態和執行時資訊。

尤其需要注意的是，解決HA問題需考慮以下幾個問題：

：腦裂是指在主備切換時，由於切換不徹底或其他原因，導致客戶端和Slave誤以為出現兩個active master，最終使得整個叢集處於混亂狀態。解決腦裂問題，通常採用隔離(Fencing)機制，包括三個方面：

• 共享儲存fencing：確保只有一個Master往共享儲存中寫資料。
• 客戶端fencing：確保只有一個Master可以響應客戶端的請求。
• Slave fencing：確保只有一個Master可以向Slave下發命令。

Hadoop公共庫中對外提供了兩種fenching實現，分別是sshfence和shellfence（預設實現），其中sshfence是指通過ssh登陸目標Master節點上，使用命令fuser將程序殺死（通過tcp埠號定位程序pid，該方法比jps命令更準確），shellfence是指執行一個使用者事先定義的shell命令（指令碼）完成隔離。

（2）切換對外透明：為了保證整個切換是對外透明的，Hadoop應保證所有客戶端和Slave能自動重定向到新的active master上，這通常是通過若干次嘗試連線舊master不成功後，再重新嘗試連結新master完成的，整個過程有一定延遲。在新版本的Hadoop RPC中，使用者可自行設定RPC客戶端嘗試機制、嘗試次數和嘗試超時時間等引數。

為了印證以上通用方案，以MapReduce HA為例進行說明，在CDH4中，HA方案介紹可參考我的這篇文章：“CDH中JobTracker HA方案介紹”，架構圖如下：

Hadoop 2.0 中 HDFS HA解決方案可閱讀文章：“Hadoop 2.0 NameNode HA和Federation實踐”，目前HDFS2中提供了兩種HA方案，一種是基於NFS共享儲存的方案，一種基於Paxos演算法的方案Quorum Journal Manager（QJM），它的基本原理就是用2N+1臺JournalNode儲存EditLog，每次寫資料操作有大多數（>=N+1）返回成功時即認為該次寫成功，資料不會丟失了。目前社群正嘗試使用Bookeeper作為共享儲存系統，具體可參考。HDFS-1623給出的HDFS HA架構圖如下所示：

目前進度最慢的是YARN HA解決方案，該方案已經文件化，正在規範和開發中，具體可參考：https://issues.apache.org/jira/browse/YARN-149，總體上看，它的整體架構與MapReduce HA和YARN HA的類似，但共享儲存系統採用的是Zookeeper。之所以採用Zookeeper這種輕量級“儲存系統”（需要注意的是，zookeeper設計目的並不是儲存，而是提供分散式協調服務，但它的確可以安全可靠的儲存少量資料以解決分散式環境下多個服務之間的資料共享問題），是由於YARN的大部分資訊可以通過NodeManager和ApplicationMaster的心跳資訊進行動態重構，而ResourceManager本身只需記錄少量資訊到Zookeeper上即可。

總體上講，HA解決的難度取決於Master自身記錄資訊的多少和資訊可重構性，如果記錄的資訊非常龐大且不可動態重構，比如NameNode，則需要一個可靠性與效能均很高的共享儲存系統，而如果Master儲存有很多資訊，但絕大多數可通過Slave動態重構，則HA解決方法則容易得多，典型代表是MapReduce和YARN。從另外一個角度看，由於計算框架對資訊丟失不是非常敏感，比如一個已經完成的任務資訊丟失，只需重算即可獲取，使得計算框架的HA設計難度遠低於儲存類系統。

Hadoop HA配置方法：

轉載自董的部落格