Hadoop2.2.0中的高可用性實現原理是什么

這期內容當中小編將會給大家帶來有關Hadoop2.2.0中的高可用性實現原理是什么，文章內容豐富且以專業的角度為大家分析和敘述，閱讀完這篇文章希望大家可以有所收獲。

在Hadoop2.0.0之前，NameNode(NN)在HDFS集群中存在單點故障（single point of failure），每一個集群中存在一個NameNode，如果NN所在的機器出現了故障，那么將導致整個集群無法利用，直到NN重啟或者在另一臺主機上啟動NN守護線程。
　　主要在兩方面影響了HDFS的可用性：
　　（1）、在不可預測的情況下，如果NN所在的機器崩潰了，整個集群將無法利用，直到NN被重新啟動；
　　（2）、在可預知的情況下，比如NN所在的機器硬件或者軟件需要升級，將導致集群宕機。
　　HDFS的高可用性將通過在同一個集群中運行兩個NN（active NN & standby NN）來解決上面兩個問題，這種方案允許在機器破潰或者機器維護快速地啟用一個新的NN來恢復故障。
　　在典型的HA集 群中，通常有兩臺不同的機器充當NN。在任何時間，只有一臺機器處于Active狀態；另一臺機器是處于Standby狀態。Active NN負責集群中所有客戶端的操作；而Standby NN主要用于備用，它主要維持足夠的狀態，如果必要，可以提供快速的故障恢復。
　　為了讓Standby NN的狀態和Active NN保持同步，即元數據保持一致，它們都將會和JournalNodes守護進程通信。當Active NN執行任何有關命名空間的修改，它需要持久化到一半以上的JournalNodes上(通過edits log持久化存儲)，而Standby NN負責觀察edits log的變化，它能夠讀取從JNs中讀取edits信息，并更新其內部的命名空間。一旦Active NN出現故障，Standby NN將會保證從JNs中讀出了全部的Edits，然后切換成Active狀態。Standby NN讀取全部的edits可確保發生故障轉移之前，是和Active NN擁有完全同步的命名空間狀態。
　　為了提供快速的故障恢復，Standby NN也需要保存集群中各個文件塊的存儲位置。為了實現這個，集群中所有的Database將配置好Active NN和Standby NN的位置，并向它們發送塊文件所在的位置及心跳，如下圖所示：

Hadoop2.2.0中HDFS的高可用性實現原理

　　在任何時候，集群中只有一個NN處于Active 狀態是極其重要的。否則，在兩個Active   NN的狀態下NameSpace狀態將會出現分歧，這將會導致數據的丟失及其它不正確的結果。為了保證這種情況不會發生，在任何時間，JNs只允許一個 NN充當writer。在故障恢復期間，將要變成Active 狀態的NN將取得writer的角色，并阻止另外一個NN繼續處于Active狀態。
　　為了部署HA集群，你需要準備以下事項：
　　（1）、NameNode machines：運行Active NN和Standby NN的機器需要相同的硬件配置；
　　（2）、JournalNode machines：也就是運行JN的機器。JN守護進程相對來說比較輕量，所以這些守護進程可以可其他守護線程（比如NN，YARN ResourceManager）運行在同一臺機器上。在一個集群中，最少要運行3個JN守護進程，這將使得系統有一定的容錯能力。當然，你也可以運行3 個以上的JN，但是為了增加系統的容錯能力，你應該運行奇數個JN（3、5、7等），當運行N個JN，系統將最多容忍(N-1)/2個JN崩潰。
　　在HA集群中，Standby NN也執行namespace狀態的checkpoints，所以不必要運行Secondary NN、CheckpointNode和BackupNode；事實上，運行這些守護進程是錯誤的。

上述就是小編為大家分享的Hadoop2.2.0中的高可用性實現原理是什么了，如果剛好有類似的疑惑，不妨參照上述分析進行理解。如果想知道更多相關知識，歡迎關注億速云行業資訊頻道。