[[379511]]

前言

在早期Hadoop剛出來的時候是沒有解決HDFS單點問題的，這就意味著當(dāng)NameNode的服務(wù)器宕機(jī)了就會導(dǎo)致整個集群癱瘓，這是非常危險的于是在Hadoop不斷的更新下提出了Hadoop HA來解決NameNode單點問題，接下來我們就來聊一聊。

解決HDFS單點問題解決方案 解決HDFS點單問題其實可以部署兩個NameNode，但是真正對外服務(wù)只有一個，部署兩個NameNode那他們之間的元數(shù)據(jù)信息是不是需要共享元數(shù)據(jù)信息呀，不然當(dāng)其中一個NameNode掛掉了元數(shù)據(jù)信息沒有同步不就會有問題。

根據(jù)appche提出的解決方案目前有三種解決方案如下

方案一、目錄共享

目錄共享是在appche社區(qū)中提出但是現(xiàn)在沒有引用，目錄共享也是一個單點問題，如果當(dāng)目錄共享掛掉了是不是也會導(dǎo)致HDFS掛掉。所以就被一些企業(yè)拋棄了。

方案二、使用JournalNode方案

我們使用JN來保存元數(shù)據(jù)信息就不會造成單點問題，JN也是一個集群，我們一般部署JN一般會選擇基數(shù)例如3,5,7,9等。JN有一個政策只要存活的節(jié)點大于二分之一就是一個正常的服務(wù)。

注意：我們不要為了解決NameNode的單點問題選擇的的組件也是單點問題，這個根本還是沒有解決。

JN中的信息都是一樣的，那為什么也是其中的一個NameNode就是寫數(shù)據(jù)其中一個就是讀取數(shù)據(jù)那?

其實NameNode也是有角色之分的寫的為action讀為standby,在高可用的架構(gòu)中只有一個NameNode真正對外服務(wù)， 用戶也只會對action的NameNode進(jìn)行打交道，舉個理解:假設(shè)我們在工作中有2個領(lǐng)導(dǎo)(平級的)我們?nèi)フ埣倨渲幸粋€領(lǐng)導(dǎo)同意其中一個領(lǐng)導(dǎo)不同意那這個假到底修還是不修那?這不就亂套了嗎?也就是在高可用架構(gòu)中同一時間只有一個說的算。

方案三、使用zookeeper方案

其實企業(yè)中也有好多使用zookeeper來帶代替了。我們來想一想JN解決了什么問題，不是就數(shù)據(jù)的一致性和單點故障我們在想想zookeepr是不是也有，于是企業(yè)中就把zookeeper的源碼改了改就使用了這個方案。

總體架構(gòu)

以上的解決方案是不是可以解決了NameNode單點問題，假設(shè)在凌晨的時候action的NameNode掛掉了是不是要進(jìn)行切換我們是不是需要人工去切換。是不是切換不及時就到導(dǎo)致整個集群不可用。接下來我實現(xiàn)自動切換。

兩個NameNode啟動成功后都會去zookeeper注冊自己zookeeper中會有一把鎖那個NameNode注冊成功了就是action當(dāng)其他的NameNode在去注冊是發(fā)現(xiàn)已經(jīng)被注冊了就變成了standby。

每個NameNode都部署了ZKFC 來監(jiān)控NameNode的情況當(dāng)action的NameNode發(fā)生故障時ActionZKF通過zookeeper刪除臨時的zNode (釋放鎖)StandBy狀態(tài)下的ZKF訂閱了這個臨時的zNode的變換，若zNode消失，StandBy狀態(tài)的ZKFC立刻通過standby NameNode。StandByNameNode遠(yuǎn)程登錄actionNameNode執(zhí)行kill-9 actionNameNode。StandByNameNode通知StandByZkfc去zookeeper上注冊zNode，注冊成功轉(zhuǎn)換為action狀態(tài)。這樣就實現(xiàn)了自己轉(zhuǎn)換

小結(jié)

上述給大家講解了幾種解決HDFS單點故障的問題，不知道大家吸收有多少，如果有不會的可以在下方留言或著私信我 我來給你解答。下期會分享NameNode內(nèi)存受限該怎么解決。 我在這里為大家提供大數(shù)據(jù)的資料(企業(yè)面試題，簡歷模板等)需要的朋友可以去下面GitHub去下載，信自己，努力和汗水總會能得到回報的。

本文轉(zhuǎn)載自微信公眾號「大數(shù)據(jù)老哥」，可以通過以下二維碼關(guān)注。轉(zhuǎn)載本文請聯(lián)系大數(shù)據(jù)老哥公眾號。