企業(yè)是怎樣解決HDFS單點問題的

本篇文章為大家展示了企業(yè)是怎樣解決HDFS單點問題的，內(nèi)容簡明扼要并且容易理解，絕對能使你眼前一亮，通過這篇文章的詳細介紹希望你能有所收獲。

前言

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

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

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

方案一、目錄共享

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

方案二、使用JournalNode方案

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

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

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

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

方案三、使用zookeeper方案

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

總體架構

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

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

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

上述內(nèi)容就是企業(yè)是怎樣解決HDFS單點問題的，你們學到知識或技能了嗎？如果還想學到更多技能或者豐富自己的知識儲備，歡迎關注億速云行業(yè)資訊頻道。