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實現，分別是可獨立運行的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問題需考慮以下幾個問題：
（1）腦裂（brain-split）：腦裂是指在主備切換時，由於切換不徹底或其他原因，導致客戶端和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配置方法：
（1）HDFS HA：Hadoop 2.0 NameNode HA和Federation實踐
（2）MapReduce HA：Configuring JobTracker High Availability
轉載自董的博客
本文鏈接地址: http://dongxicheng.org/mapreduce-nextgen/hadoop-2-0-ha/
參考：
《HDFS中的SecondaryNameNode節點解析 》
《Facebook公開其Hadoop與Avatarnode代碼——有效解決Namenode頑疾》