目錄
- HDFS NameNode 高可用
- Hadoop Namenode 高可用架構(gòu)
- Namenode 高可用的實現(xiàn)
HDFS NameNode 高可用
在 Hadoop 2.0.0 之前,一個集群只有一個Namenode,這將面臨單點故障問題。如果 Namenode 機器掛掉了,整個集群就用不了了。只有重啟 Namenode ,才能恢復(fù)集群。另外正常計劃維護集群的時候,還必須先停用整個集群,這樣沒辦法達到 7 * 24小時可用狀態(tài)。Hadoop 2.0 及之后版本增加了 Namenode 高可用機制,下面詳細介紹。
Hadoop Namenode 高可用架構(gòu)
Hadoop 2.0 克服了 Namenode 單點故障問題,即在一個集群中有2個 Namenode 節(jié)點,一個是活動的Namenode節(jié)點(Active Namenode),即主節(jié)點,一個是備用 Namenode(Passive Namenode),即備用節(jié)點,而且支持熱備份和故障切換。
活動 Namenode:負責(zé)處理集群中所有客戶端請求。
備用 Namenode:備用節(jié)點,擁有和活動的 Namenode 一樣的元數(shù)據(jù)。在活動 Namenode 失效后,會接管它的工作。
活動 Namenode 和備用 Namenode 之間是如何同步數(shù)據(jù)的呢?即他們是怎么保持一致性的,主要有下面幾點:
- 活動和備用 Namenode 兩者總是同步的,例如,他們存儲著一樣的元數(shù)據(jù),這可以把集群恢復(fù)到系統(tǒng)奔潰時的狀態(tài)。而且基于此還能實現(xiàn)自動故障切換。
- 同一時間,集群只能有一個活動的 Namenode 節(jié)點,否則,兩個 Namenode 會導(dǎo)致數(shù)據(jù)發(fā)生錯亂并且無法恢復(fù)。我們把這種情況稱為“腦裂”現(xiàn)象,即一個集群被分成兩個小集群,并且兩邊都認為自己是唯一活動的集群。Zookeeper 社區(qū)對這種問題的解決方法叫做 fencing,中文翻譯為隔離,也就是想辦法把舊的 活動 NameNode 隔離起來,使它不能正常對外提供服務(wù),使集群始終只有一個活動的 Namenode。
了解完 Hadoop 高可用架構(gòu)之后,讓我們來看一下 Hadoop Namenode 高可用是怎么實現(xiàn)的。
Namenode 高可用的實現(xiàn)
這里主要介紹通過隔離(fencing)和Quorum Journal Manager(QJM)共享存儲實現(xiàn)的 HDFS 高可用。
隔離(Fencing)
隔離(Fencing)是為了防止腦裂,就是保證在任何時候HDFS只有一個Active NN,主要包括三個方面:
- 共享存儲fencing:確保只有一個NN可以寫入edits。QJM中每一個JournalNode中均有一個epochnumber,匹配epochnumber的QJM才有權(quán)限更新 JN。當(dāng) Namenode 由 standby 狀態(tài)切換成 active 狀態(tài)時,會重新生成一個 epochnumber,并更新 JN 中的 epochnumber,以至于以前的 Active Namenode 中的QJM 中的 epoch number 和 JN 的 epochnumber 不匹配,故而原 Active Namenode上的 QJM 沒法往 JN 中寫入數(shù)據(jù)(后面會介紹源碼),即形成了 fencing。
- 客戶端f encing:確保只有一個 Namenode 可以響應(yīng)客戶端的請求。
- DataNode fencing:確保只有一個 Namenode 可以向 Datanode 下發(fā)命令,譬如刪除塊,復(fù)制塊,等等。
QJM 的 Fencing 方案只能讓原來的 Active Namenode 失去對 JN 的寫權(quán)限,但是原來的 Active Namenode 還是可以響應(yīng)客戶端的請求,對 Datanode 進行讀。對客戶端和 DataNode 的 fence 是通過配置 dfs.ha.fencing.methods 實現(xiàn)的。
Hadoop 公共庫中有兩種Fencing實現(xiàn):sshfence、shell
- sshfence:ssh到原Active NN上,使用fuser結(jié)束進程(通過tcp端口號定位進程 pid,該方法比 jps 命令更準(zhǔn)確)。
- shell:即執(zhí)行一個用戶事先定義的shell命令(腳本)完成隔離。
QJM共享存儲
Qurom Journal Manager(QJM)是一個基于 Paxos 算法實現(xiàn)的 HDFS 元數(shù)據(jù)共享存儲的方案。QJM 的基本原理就是用 2N+1 臺 JournalNode 存儲 EditLog,每次寫數(shù)據(jù)操作有大多數(shù)(>=N+1)返回成功時即認為該次寫成功,數(shù)據(jù)不會丟失。這個算法所能容忍的是最多有 N 臺機器掛掉,如果多于 N 臺掛掉,這個算法就失效了。這個原理是基于 Paxos 算法的。
用QJM的方式來實現(xiàn)HA的主要好處有:
- 不需要配置額外的高共享存儲,這樣對于基于商用硬件的云計算數(shù)據(jù)中心來說,降低了復(fù)雜度和維護成本;
- 不在需要單獨配置 fencing 實現(xiàn),因為 QJM 本身內(nèi)置了 fencing 的功能;
- 不存在單點故障問題;
- 系統(tǒng)魯棒性的程度是可配置的( QJM 基于 Paxos 算法,所以如果配置 2N+1 臺 JournalNode 組成的集群,能容忍最多 N 臺機器掛掉);
- QJM 中存儲日志的 JournalNode 不會因為其中一臺的延遲而影響整體的延遲,而且也不會因為 JournalNode 的數(shù)量增多而影響性能(因為 Namenode 向 JournalNode 發(fā)送日志是并行的)。
以上就是帶你連接HDFS的Namenode 高可用機制的詳細內(nèi)容,更多關(guān)于HDFS Namenode 高可用的資料請關(guān)注腳本之家其它相關(guān)文章!
您可能感興趣的文章:- HDFS-Hadoop NameNode高可用機制
- Hadoop中namenode和secondarynamenode工作機制講解
- Hadoop之NameNode Federation圖文詳解