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是存儲了中繼資料資訊（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/

作者：Dong，作者介紹：http://dongxicheng.org/about/

本部落格的文章集合:http://dongxicheng.org/recommend/