共計 1659 個字符，預計需要花費 5 分鐘才能閱讀完成。

這期內容當中丸趣 TV 小編將會給大家帶來有關 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；事實上，運行這些守護進程是錯誤的。

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