Hadoop 2.0中單點故障解決方案總結

•  

• 項目構建

 

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是存儲了元數據信息（fsp_w_picpath）和操做日誌（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