Hadoop2.0中單點故障解決方案總結

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設計難度遠低于存儲類系統。

原創文章，轉載請注明： 轉載自 董的博客

本文鏈接地址: http://dongxicheng.org/mapreduce-nextgen/hadoop-2-0-ha/

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

本博客的文章集合: http://dongxicheng.org/recommend/

原文地址：Hadoop 2.0中單點故障解決方案總結, 感謝原作者分享。

聲明：本網頁內容旨在傳播知識，若有侵權等問題請及時與本網聯系，我們將在第一時間刪除處理。TEL:177 7030 7066 E-MAIL:11247931@qq.com