hdfs如何保證高可用

這篇文章將為大家詳細講解有關hdfs如何保證高可用，小編覺得挺實用的，因此分享給大家做個參考，希望大家閱讀完這篇文章后可以有所收獲。

hdfs如何保證高可用

從上圖中我們可以看到，啟動的時候，主備選舉是利用 zookeeper 來實現(xiàn)的， hdfs  namenode節(jié)點上的 ZKFailoverController 進程， 主要負責控制主備切換，監(jiān)控 namenode進程是否還活著， 連接 zookeeper進行選舉，并且控制本機的 namenode 的行為，如果發(fā)現(xiàn)zookeeper的鎖節(jié)點還沒有被搶占創(chuàng)建，就創(chuàng)建鎖節(jié)點，并把本機的 namenode 變成 active 節(jié)點， 如果發(fā)現(xiàn)鎖節(jié)點已經(jīng)創(chuàng)建，就把 本機的namenode變成standby節(jié)點。

如果 ZKFailoverController 發(fā)現(xiàn)本機的 namenode 已經(jīng)掛掉了， 就刪除zookeeper上的節(jié)點，standby 上的ZKFailoverController感知到刪除事件， 就升級本機的namenode成為主節(jié)點。

如果 active節(jié)點超過 Zookeeper Session Timeout 參數(shù)配置的時間沒有連接 zookeeper， 同樣被認為主節(jié)點已經(jīng)掛了， standby 節(jié)點也會升級成為主節(jié)點

hdfs 如何進行主備切換

與單機文件系統(tǒng)相似，HDFS對文件系統(tǒng)的目錄結(jié)構(gòu)也是按照樹狀結(jié)構(gòu)維護，Namespace保存了目錄樹及每個目錄/文件節(jié)點的屬性。除在內(nèi)存常駐外，這部分數(shù)據(jù)會定期flush到持久化設備上，生成一個新的FsImage文件，方便NameNode發(fā)生重啟時，從FsImage及時恢復整個Namespace。

上圖我們可以看到基于 journalnode 進行共享元數(shù)據(jù)，  jounalnode中保存著 editlog，也就是對文件元數(shù)據(jù)的操作日志，比如用戶（hdfs dfs rm /a.txt）刪除一個文件， 就產(chǎn)生了一條操作日志，作用到命名空間后，a.txt 這個文件就被干掉了，這個日志就類似于數(shù)據(jù)庫中的 redo 日志， standby節(jié)點 周期性的從journalnode中拉取 editlog， 然后從上一次checkpoint的位置開始重放，在內(nèi)存中將操作結(jié)果合并到老的fsimage（命名空間），  并更新checkpoint位置。 最后把合并后的fsimage 上傳到 active namenode 保存替換老的fsimage文件，

NameNode 處于 active和standby狀態(tài)時候，扮演的角色是很不同的，

• active 角色， 把用戶對命名空間的操作作為 editlog 寫入 journalnode 集群

• standby 角色，EditLogTailer 線程 從 journalnode 上拉取 editlog日志， StandbyCheckpointer 線程把 editlog合并到 fsimage， 然后把 fsimage 文件上傳到 active namenode 節(jié)點

active 掛的時候，  standby 感知后， 轉(zhuǎn)換為 active 角色， 生成一個新的 epoch（就是每次主備切換就加一， 表明現(xiàn)在誰是老大，在誰的任期內(nèi)），因為 standby 是階段性拉取 editlog的，所以肯定最新的一段editlog還沒有作用于 fsimage， 需要拉取重放， 因為寫 editlog 到 journal的時候， 只要大多數(shù)（比如總5個點，要成功寫入3個點，總共3個點，要成功寫入2個點）寫入成功就認為成功了， 這樣在拉取恢復的時候，各個journalnode 節(jié)點上的數(shù)據(jù)有可能不一致， 這時候就必須找到大多數(shù)里面 事務id最大的點作為基準， 這個事務id就類似于數(shù)據(jù)庫中的 Log sequence number（簡稱LSN）， 簡單來講， 就是要把 上一次checkpoint 的（LSN） 到 redo 日志里面最大的 （LSN）這之間的 日志進行重放redo，合并到fsimage。

假設一種情況，  老的active節(jié)點，是因為網(wǎng)絡問題，連接不上 zookeeper， 然后被認為已經(jīng)死了，其實是假死，這時候網(wǎng)絡恢復了， 還認為自己是 leader， 往 journalnode里面寫editlog日志， 發(fā)現(xiàn)現(xiàn)在已經(jīng)是別人的天下了（epoch number已經(jīng)加1了），自己的epoch number已經(jīng)過時了，就把自己降級為 standby，做standby 角色該干的事情。

為什么要在 secondnamnode 上合并， 主要是為了減輕 namenode的壓力， namenode有很多其他的事情要干呢。

操作

• hadoop-daemon.sh start journalnode， 啟動  journalnode 集群，會根據(jù)你配置文件里面配置的機器上去啟動 journalnode 集群

• hdfs namenode -format，  格式化 namenode 命名空間

• hadoop-daemon.sh start namenode，nn1 上啟動 namenode

• hdfs namenode -bootstrapStandby，  nn2 同步nn1的元數(shù)據(jù)信息， 會把主節(jié)點上的 fsimage editlog目錄拷貝過來

• hadoop-daemon.sh start namenode，  nn2 上啟動 namenode

• 啟動 zk 集群  hdfs zkfc -formatZK 格式化 zkfc zk 中的目錄  hadoop-daemon.sh start zkfc   各個namenode節(jié)點上啟動dfszk failover controller, 先在哪臺機器上啟動，哪臺就是active namenode

• hadoop-daemon.sh start datanode 上傳文件 測試 讀寫文件

• 測試  ha 將 active namenode進程kill，    jps  進程號， kill，    將active namenode機器斷開網(wǎng)絡  service network stop

我們對集群進行以上的測試， 觀察日志，會發(fā)現(xiàn)hdfs干的事情基本上就是前面描寫的流程。

關于“hdfs如何保證高可用”這篇文章就分享到這里了，希望以上內(nèi)容可以對大家有一定的幫助，使各位可以學到更多知識，如果覺得文章不錯，請把它分享出去讓更多的人看到。