在Hadoop2.X之前，Namenode是HDFS集群中可能發(fā)生單點(diǎn)故障的節(jié)點(diǎn)，每個HDFS集群只有一個namenode，一旦這個節(jié)點(diǎn)不可用，則整個HDFS集群將處于不可用狀態(tài)。
HDFS高可用（HA）方案就是為了解決上述問題而產(chǎn)生的，在HA HDFS集群中會同時運(yùn)行兩個Namenode，一個作為活動的Namenode（Active），一個作為備份的Namenode（Standby）。備份的Namenode的命名空間與活動的Namenode是實時同步的，所以當(dāng)活動的Namenode發(fā)生故障而停止服務(wù)時，備份Namenode可以立即切換為活動狀態(tài)，而不影響HDFS集群服務(wù)。

在一個HA集群中，會配置兩個獨(dú)立的Namenode。在任意時刻，只有一個節(jié)點(diǎn)作為活動的節(jié)點(diǎn)，另一個節(jié)點(diǎn)則處于備份狀態(tài)?；顒拥腘amenode負(fù)責(zé)執(zhí)行所有修改命名空間以及刪除備份數(shù)據(jù)塊的操作，而備份的Namenode則執(zhí)行同步操作，以保持與活動節(jié)點(diǎn)命名空間的一致性。
為了使備份節(jié)點(diǎn)與活動節(jié)點(diǎn)的狀態(tài)能夠同步一致，兩個節(jié)點(diǎn)都需要同一組獨(dú)立運(yùn)行的節(jié)點(diǎn)（JournalNodes，JNS）通信。當(dāng)Active Namenode執(zhí)行了修改命名空間的操作時，它會定期將執(zhí)行的操作記錄在editlog中，并寫入JNS的多數(shù)節(jié)點(diǎn)中。而Standby Namenode會一直監(jiān)聽JNS上editlog的變化，如果發(fā)現(xiàn)editlog有改動，Standby Namenode就會讀取editlog并與當(dāng)前的命名空間合并。當(dāng)發(fā)生了錯誤切換時，Standby節(jié)點(diǎn)會保證已經(jīng)從JNS上讀取了所有editlog并與命名空間合并，然后才會從Standby狀態(tài)切換為Active狀態(tài)。通過這種機(jī)制，保證了Active Namenode與Standby Namenode之間命名空間狀態(tài)的一致性，也就是第一關(guān)系鏈的一致性。
為了使錯誤切換能夠很快的執(zhí)行完畢，就要保證Standby節(jié)點(diǎn)也保存了實時的數(shù)據(jù)快的存儲信息，也就是第二關(guān)系鏈。這樣發(fā)生錯誤切換時，Standby節(jié)點(diǎn)就不需要等待所有的數(shù)據(jù)節(jié)點(diǎn)進(jìn)行全量數(shù)據(jù)塊匯報，而直接可以切換到Active狀態(tài)。為了實現(xiàn)這個機(jī)制，Datanode會同時向這兩個Namenode發(fā)送心跳以及塊匯報信息。這樣就實現(xiàn)了Active Namenode 和standby Namenode 的元數(shù)據(jù)就完全一致，一旦發(fā)生故障，就可以馬上切換，也就是熱備。
這里需要注意的是 Standby Namenode只會更新數(shù)據(jù)塊的存儲信息，并不會向namenode 發(fā)送復(fù)制或者刪除數(shù)據(jù)塊的指令，這些指令只能由Active namenode發(fā)送。
在HA架構(gòu)中有一個非常重非要的問題，就是需要保證同一時刻只有一個處于Active狀態(tài)的Namenode，否則機(jī)會出現(xiàn)兩個Namenode同時修改命名空間的問，也就是腦裂（Split-brain）。腦裂的HDFS集群很可能造成數(shù)據(jù)塊的丟失，以及向Datanode下發(fā)錯誤的指令等異常情況。為了預(yù)防腦裂的情況，HDFS提供了三個級別的隔離機(jī)制（fencing）:

• 1.共享存儲隔離：同一時間只允許一個Namenode向JournalNodes寫入editlog數(shù)據(jù)。
• 2.客戶端隔離：同一時間只允許一個Namenode響應(yīng)客戶端的請求。
• 3.Datanode隔離：同一時間只允許一個Namenode向Datanode下發(fā)名字節(jié)點(diǎn)指令，李如刪除、復(fù)制數(shù)據(jù)塊指令等等。

在HA實現(xiàn)中還有一個非常重要的部分就是Active Namenode和Standby Namenode之間如何共享editlog日志文件。Active Namenode會將日志文件寫到共享存儲上。Standby Namenode會實時的從共享存儲讀取edetlog文件，然后合并到Standby Namenode的命名空間中。這樣一旦Active Namenode發(fā)生錯誤，Standby Namenode可以立即切換到Active狀態(tài)。在Hadoop2.6中，提供了QJM（Quorum Journal Manager）方案來解決HA共享存儲問題。

所有的HA實現(xiàn)方案都依賴于一個保存editlog的共享存儲，這個存儲必須是高可用的，并且能夠被集群中所有的Namenode同時訪問。Quorum Journa是一個基于paxos算法的HA設(shè)計方案。

Quorum Journal方案中有兩個重要的組件。

• 1.JournalNoe（JN）：運(yùn)行在N臺獨(dú)立的物理機(jī)器上，它將editlog文件保存在JournalNode的本地磁盤上，同時JournalNode還對外提供RPC接口QJournalProtocol以執(zhí)行遠(yuǎn)程讀寫editlog文件的功能。
• 2.QuorumJournalManager(QJM):運(yùn)行在NmaeNode上，（目前HA集群只有兩個Namenode），通過調(diào)用RPC接口QJournalProtocol中的方法向JournalNode發(fā)送寫入、排斥、同步editlog。

Quorum Journal方案依賴于這樣一個概念：HDFS集群中有2N+1個JN存儲editlog文件，這些editlog 文件是保存在JN的本地磁盤上的。每個JN對QJM暴露QJM接口QJournalProtocol，允許Namenode讀寫editlog文件。當(dāng)Namenode向共享存儲寫入editlog文件時，它會通過ＱＪＭ向集群中所有的ＪＮ發(fā)送寫editlog文件請求，當(dāng)有一半以上的ＪＮ返回寫操作成功時，即認(rèn)為寫成功。這個原理是基于Paxos算法的。

使用Quorum Journal實現(xiàn)的HA方案有一下優(yōu)點(diǎn)：

• 1.JN進(jìn)程可以運(yùn)行在普通的PC上，而無需配置專業(yè)的共享存儲硬件。
• 2.不需要單獨(dú)實現(xiàn)fencing機(jī)制，Quorum Journal模式中內(nèi)置了fencing功能。
• 3. Quorum Journa不存在單點(diǎn)故障，集群中有2N+1個Journal，可以允許有Ｎ個Journal Node死亡。
• 4. JN不會因為其中一個機(jī)器的延遲而影響整體的延遲，而且也不會因為JN數(shù)量的增多而影響性能（因為Namenode向JournalNode發(fā)送日志是并行的）

互斥機(jī)制

當(dāng)HA集群中發(fā)生Namenode異常切換時，需要在共享存儲上fencing上一個活動的節(jié)點(diǎn)以保證該節(jié)點(diǎn)不能再向共享存儲寫入editlog?；赒uorum Journal模式的ＨＡ提供了epoch number來解決互斥問題，這個概念可以在分布式文件系統(tǒng)中找到。epoch number具有以下幾個性質(zhì)。
1.當(dāng)一個Namenode變?yōu)榛顒訝顟B(tài)時，會分配給他一個epoch number。
2.每個epoch number都是唯一的，沒有任意兩個Namenode有相同的epoch number。
3.epoch number 定義了Namenode寫editlog文件的順序。對于任意兩個namenode ,擁有更大epoch number的Namenode被認(rèn)為是活動節(jié)點(diǎn)。

當(dāng)一個Namenode切換為活動狀態(tài)時，它的QJM會向所有的JN發(fā)送命令，以獲取該JN的最后一個promise epoch變量值。當(dāng)ＱＪＭ接受到了集群中多于一半的ＪＮ回復(fù)后，它會將所接收到的最大值加一，并保存到myepoch 中，之后ＱＪＭ會將該值發(fā)送給所有的JN并提出更新請求。每個JN會將該值與自身的epoch值相互比較，如果新的myepoch比較大，則JN更新，并返回更新成功；如果小，則返回更新失敗。如果QJM接收到超過一半的JN返回成功，則設(shè)置它的epoch number為myepoch；，否則它終止嘗試為一個活動的Namenode，并拋出異常。

當(dāng)活動的NameNode成功獲取并更新了epoch number后，調(diào)用任何修改editlog的RPC請求都必須攜帶epoch number。當(dāng)RPC請求到達(dá)JN后，JN會將請求者的epoch與自身保存的epoch相互對比，若請求者的epoch更大，JN就會更新自己的epoch，并執(zhí)行相應(yīng)的操作，如果請求者的epoch小，就會拒絕相應(yīng)的請求。當(dāng)集群中大多數(shù)的JN拒絕了請求時，這次操作就失敗了。
當(dāng)HDFS集群發(fā)生Namenode錯誤切換后，原來的standby Namenode將集群的epoch number加一后更新。這樣原來的Active namenode的epoch number肯定小于這個值，當(dāng)這個節(jié)點(diǎn)執(zhí)行寫editlog操作時，由于JN節(jié)點(diǎn)不接收epoch number小于自身的promise epoch的寫請求，所以這次寫請求會失敗，也就達(dá)到了fencing的目的。

寫流程

• 1.將editlog輸出流中緩存的數(shù)據(jù)寫入JN，對于集群中的每一個JN都存在一個獨(dú)立的線程調(diào)用RPC 接口中的方法向JN寫入數(shù)據(jù)。
• 2.當(dāng)JN收到請求之后，JN會執(zhí)行以下操作：

1）驗證epoch number是否正確

2）確認(rèn)寫入數(shù)據(jù)對應(yīng)的txid是否連續(xù)

3）將數(shù)據(jù)持久化到JN的本地磁盤

4）向QJM發(fā)送正確的響應(yīng)

• 3.QJM等待集群JN的響應(yīng)，如果多數(shù)JN返回成功，則寫操作成功；否則寫操作失敗，QJM會拋出異常。

Namenode會調(diào)用FSEditlogLog下面的方法初始化editlog文件的輸出流，然后使用輸出流對象向editlog文件寫入數(shù)據(jù)。
獲取了QuorumOutputStream輸出流對象之后，Namenode會調(diào)用write方法向editlog文件中寫入數(shù)據(jù)，QuorumOutputStream的底層也調(diào)用了EditsDoubleBuffer雙緩存區(qū)。數(shù)據(jù)回先寫入其中一個緩沖區(qū)中，然后調(diào)用flush方法時，將緩沖區(qū)中的數(shù)據(jù)發(fā)送給JN。

讀流程

Standby Namenode會從JN讀取editlog，然后與Sdtandby Namenode的命名空間合并，以保持和Active Namenode命名空間的同步。當(dāng)Sdtandby Namenode從JN讀取editlog時，它會首先發(fā)送RPC請求到集群中所有的JN上。JN接收到這個請求后會將JN本地存儲上保存的所有FINALIZED狀態(tài)的editlog段落文件信息返回，之后QJM會為所有JN返回的editlog段落文件構(gòu)造輸入流對象，并將這些輸入流對象合并到一個新的輸入流對象中，這樣Standby namenode就可以從任一個JN讀取每個editlog段落了。如果其中一個ＪＮ失敗了輸入流對象會自動切換到另一個保存了該edirlog段落的JN上。

恢復(fù)流程

當(dāng)Namenode發(fā)生主從切換時，原來的Standby namenode會接管共享存儲并執(zhí)行寫editlog的操作。在切換之前，對于共享存儲會執(zhí)行以下操作：
1.fencing原來的Active Namenode。這部分在互斥部分已經(jīng)講述。
2.恢復(fù)正在處理的editlog。由于Namenode發(fā)生了主從切換，集群中JN上正在執(zhí)行寫入操作的editlog數(shù)據(jù)可能不一致。例如，可能出現(xiàn)某些JN上的editlog正在寫入，但是當(dāng)前Active Namenode發(fā)生錯誤，這時該JN上的editlog文件就與已完成寫入的JN不一致。在這種情況下，需要對JN上所有狀態(tài)不一致的editlog文件執(zhí)行恢復(fù)操作，將他們的數(shù)據(jù)同步一致，并且將editlog文件轉(zhuǎn)化為FINALIZED狀態(tài)。
3.當(dāng)不一致的editlog文件完成恢復(fù)之后，這時原來的Standby Namenode就可以切換為Active Namenode并執(zhí)行寫editlog的操作。
4.寫editlog。在前面已經(jīng)介紹了。

日志恢復(fù)操作可以分為以下幾個階段：

1.確定需要執(zhí)行恢復(fù)操作的editlog段落：在執(zhí)行恢復(fù)操作之前，QJM會執(zhí)行newEpoch（）調(diào)用以產(chǎn)生新的epoch number，JN接收到這個請求后除了執(zhí)行更新epoch number外，還會將該JN上保存的最新的editlog段落的txid返回。當(dāng)集群中的大多數(shù)JN都發(fā)回了這個響應(yīng)后，QJM就可以確定出集群中最新的一個正在處理editlog段落的txid，然后QJM就會對這個txid對應(yīng)的editlog段落執(zhí)行恢復(fù)操作了。

2.準(zhǔn)備恢復(fù)：QJM向集群中的所有JN發(fā)送RPC請求，查詢執(zhí)行恢復(fù)操作的editlog段落文件在所有JN上的狀態(tài)，這里的狀態(tài)包括editlog文件是in-propress還是FINALIZED狀態(tài)，以及editlog文件的長度。

3.接受恢復(fù)：QJM接收到JN發(fā)回的JN發(fā)回的響應(yīng)后，會根據(jù)恢復(fù)算法選擇執(zhí)行恢復(fù)操作的源節(jié)點(diǎn)。然后QJM會發(fā)送RPC請求給每一個ＪＮ，這個請求會包含兩部分信息：源editlog段落文件信息，以及供JN下載這個源editlog段落的url。
接收到這個RPC請求之后，JN會執(zhí)行以下操作：

1）同步editlog段落文件，如果JN磁盤上的editlog段落文件與請求中的段落文件狀態(tài)不同，則JN會從當(dāng)前請求中的url上下載段落文件，并替換磁盤上的editlog段落文件。
2）持久化恢復(fù)元數(shù)據(jù)，JN會將執(zhí)行恢復(fù)操作的editlog段落文件的狀態(tài)、觸發(fā)恢復(fù)操作的QJM的epoch number等信息（恢復(fù)的元數(shù)據(jù)信息）持久化到磁盤上。
3）當(dāng)這些操作都執(zhí)行成功后，JN會返回成功響應(yīng)給QJM，如果集群中的大多數(shù)JN都返回了成功，則此次恢復(fù)操作執(zhí)行成功。

4.完成editlog段落文件：到這步操作時，QJM 就能確定集群中大多數(shù)的JN保存的editlog文件的狀態(tài)已經(jīng)一致了，并且JN持久化了恢復(fù)信息。QJM就會向JN發(fā)送指令，將這個editlog段落文件的狀態(tài)轉(zhuǎn)化為FINALIZED狀態(tài)，，并且JN會刪除持久化的恢復(fù)元數(shù)據(jù)，因為磁盤上保存的editlog文件信息已經(jīng)是正確的了，不需要保存恢復(fù)的元數(shù)據(jù)。

到此這篇關(guān)于詳細(xì)講解HDFS的高可用機(jī)制的文章就介紹到這了,更多相關(guān)HDFS的高可用機(jī)制內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！