HDFS NameNode 高可用

在 Hadoop 2.0.0 之前，一個(gè)集群只有一個(gè)Namenode，這將面臨單點(diǎn)故障問題。如果 Namenode 機(jī)器掛掉了，整個(gè)集群就用不了了。只有重啟 Namenode ，才能恢復(fù)集群。另外正常計(jì)劃維護(hù)集群的時(shí)候，還必須先停用整個(gè)集群，這樣沒辦法達(dá)到 7 * 24小時(shí)可用狀態(tài)。Hadoop 2.0 及之后版本增加了 Namenode 高可用機(jī)制，下面詳細(xì)介紹。

Hadoop Namenode 高可用架構(gòu)

Hadoop 2.0 克服了 Namenode 單點(diǎn)故障問題，即在一個(gè)集群中有2個(gè) Namenode 節(jié)點(diǎn)，一個(gè)是活動(dòng)的Namenode節(jié)點(diǎn)（Active Namenode），即主節(jié)點(diǎn)，一個(gè)是備用 Namenode（Passive Namenode），即備用節(jié)點(diǎn)，而且支持熱備份和故障切換。

活動(dòng) Namenode：負(fù)責(zé)處理集群中所有客戶端請(qǐng)求。
備用 Namenode：備用節(jié)點(diǎn)，擁有和活動(dòng)的 Namenode 一樣的元數(shù)據(jù)。在活動(dòng) Namenode 失效后，會(huì)接管它的工作。

活動(dòng) Namenode 和備用 Namenode 之間是如何同步數(shù)據(jù)的呢？即他們是怎么保持一致性的，主要有下面幾點(diǎn)：

• 活動(dòng)和備用 Namenode 兩者總是同步的，例如，他們存儲(chǔ)著一樣的元數(shù)據(jù)，這可以把集群恢復(fù)到系統(tǒng)奔潰時(shí)的狀態(tài)。而且基于此還能實(shí)現(xiàn)自動(dòng)故障切換。
• 同一時(shí)間，集群只能有一個(gè)活動(dòng)的 Namenode 節(jié)點(diǎn)，否則，兩個(gè) Namenode 會(huì)導(dǎo)致數(shù)據(jù)發(fā)生錯(cuò)亂并且無法恢復(fù)。我們把這種情況稱為“腦裂”現(xiàn)象，即一個(gè)集群被分成兩個(gè)小集群，并且兩邊都認(rèn)為自己是唯一活動(dòng)的集群。Zookeeper 社區(qū)對(duì)這種問題的解決方法叫做 fencing，中文翻譯為隔離，也就是想辦法把舊的 活動(dòng) NameNode 隔離起來，使它不能正常對(duì)外提供服務(wù)，使集群始終只有一個(gè)活動(dòng)的 Namenode。

了解完 Hadoop 高可用架構(gòu)之后，讓我們來看一下 Hadoop Namenode 高可用是怎么實(shí)現(xiàn)的。

Namenode 高可用的實(shí)現(xiàn)

這里主要介紹通過隔離（fencing）和Quorum Journal Manager（QJM）共享存儲(chǔ)實(shí)現(xiàn)的 HDFS 高可用。

隔離（Fencing）

隔離（Fencing）是為了防止腦裂，就是保證在任何時(shí)候HDFS只有一個(gè)Active NN，主要包括三個(gè)方面：

• 共享存儲(chǔ)fencing：確保只有一個(gè)NN可以寫入edits。QJM中每一個(gè)JournalNode中均有一個(gè)epochnumber，匹配epochnumber的QJM才有權(quán)限更新 JN。當(dāng) Namenode 由 standby 狀態(tài)切換成 active 狀態(tài)時(shí)，會(huì)重新生成一個(gè) epochnumber，并更新 JN 中的 epochnumber，以至于以前的 Active Namenode 中的QJM 中的 epoch number 和 JN 的 epochnumber 不匹配，故而原 Active Namenode上的 QJM 沒法往 JN 中寫入數(shù)據(jù)（后面會(huì)介紹源碼），即形成了 fencing。
• 客戶端f encing：確保只有一個(gè) Namenode 可以響應(yīng)客戶端的請(qǐng)求。
• DataNode fencing：確保只有一個(gè) Namenode 可以向 Datanode 下發(fā)命令，譬如刪除塊，復(fù)制塊，等等。

QJM 的 Fencing 方案只能讓原來的 Active Namenode 失去對(duì) JN 的寫權(quán)限，但是原來的 Active Namenode 還是可以響應(yīng)客戶端的請(qǐng)求，對(duì) Datanode 進(jìn)行讀。對(duì)客戶端和 DataNode 的 fence 是通過配置 dfs.ha.fencing.methods 實(shí)現(xiàn)的。

Hadoop 公共庫中有兩種Fencing實(shí)現(xiàn)：sshfence、shell

• sshfence：ssh到原Active NN上，使用fuser結(jié)束進(jìn)程（通過tcp端口號(hào)定位進(jìn)程 pid，該方法比 jps 命令更準(zhǔn)確）。
• shell：即執(zhí)行一個(gè)用戶事先定義的shell命令（腳本）完成隔離。

QJM共享存儲(chǔ)

Qurom Journal Manager（QJM）是一個(gè)基于 Paxos 算法實(shí)現(xiàn)的 HDFS 元數(shù)據(jù)共享存儲(chǔ)的方案。QJM 的基本原理就是用 2N+1 臺(tái) JournalNode 存儲(chǔ) EditLog，每次寫數(shù)據(jù)操作有大多數(shù)（>=N+1）返回成功時(shí)即認(rèn)為該次寫成功，數(shù)據(jù)不會(huì)丟失。這個(gè)算法所能容忍的是最多有 N 臺(tái)機(jī)器掛掉，如果多于 N 臺(tái)掛掉，這個(gè)算法就失效了。這個(gè)原理是基于 Paxos 算法的。

用QJM的方式來實(shí)現(xiàn)HA的主要好處有：

• 不需要配置額外的高共享存儲(chǔ)，這樣對(duì)于基于商用硬件的云計(jì)算數(shù)據(jù)中心來說，降低了復(fù)雜度和維護(hù)成本；
• 不在需要單獨(dú)配置 fencing 實(shí)現(xiàn)，因?yàn)?QJM 本身內(nèi)置了 fencing 的功能；
• 不存在單點(diǎn)故障問題；
• 系統(tǒng)魯棒性的程度是可配置的（ QJM 基于 Paxos 算法，所以如果配置 2N+1 臺(tái) JournalNode 組成的集群，能容忍最多 N 臺(tái)機(jī)器掛掉）；
• QJM 中存儲(chǔ)日志的 JournalNode 不會(huì)因?yàn)槠渲幸慌_(tái)的延遲而影響整體的延遲，而且也不會(huì)因?yàn)?JournalNode 的數(shù)量增多而影響性能（因?yàn)?Namenode 向 JournalNode 發(fā)送日志是并行的）。

以上就是帶你連接HDFS的Namenode 高可用機(jī)制的詳細(xì)內(nèi)容，更多關(guān)于HDFS Namenode 高可用的資料請(qǐng)關(guān)注腳本之家其它相關(guān)文章！

最新評(píng)論