項目構建
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
另外有需要云服務器可以了解下創新互聯scvps.cn,海內外云服務器15元起步,三天無理由+7*72小時售后在線,公司持有idc許可證,提供“云服務器、裸金屬服務器、高防服務器、香港服務器、美國服務器、虛擬主機、免備案服務器”等云主機租用服務以及企業上云的綜合解決方案,具有“安全穩定、簡單易用、服務可用性高、性價比高”等特點與優勢,專為企業上云打造定制,能夠滿足用戶豐富、多元化的應用場景需求。
文章標題:Hadoop2.0中單點故障解決方案總結-創新互聯
新聞來源:http://vcdvsql.cn/article0/ccedio.html
成都網站建設公司_創新互聯,為您提供網站策劃、外貿建站、電子商務、網站營銷、標簽優化、小程序開發
聲明:本網站發布的內容(圖片、視頻和文字)以用戶投稿、用戶轉載內容為主,如果涉及侵權請盡快告知,我們將會在第一時間刪除。文章觀點不代表本網站立場,如需處理請聯系客服。電話:028-86922220;郵箱:631063699@qq.com。內容未經允許不得轉載,或轉載時需注明來源: 創新互聯