大數據小白系列——HDFS(3)

這裏是大數據小白系列，這是本系列的第三篇，介紹HDFS中NameNode選舉，JournalNode等概念。

上一期咱們說到了爲解決NameNode(下稱NN)單點失敗問題，HDFS中使用了雙NN的機制，一個Active NN，一個Standby NN。

 

現實經常是，解決一個問題的同時，免不了又引入了另外的問題。

誰來擔任Active，誰來擔任Standby？

兩個NN誰也說服不了誰，這個時候須要引入一個外部角色：一個Zookeeper(下稱ZK)集羣。

ZK也是個頗有趣的東西，大數據小白系列後續會專門介紹。

這裏，ZK集羣扮演了相似裁判的角色，若是兩個NN同時申請成爲Active，由ZK決定誰將獲勝。

 

兩臺NN機器上都分別存在一個ZKCF(Zookeeper Failover Controller)進程，該進程至關於ZK的一個客戶端。

ZKFC按期檢查NN進程的狀態，如狀態正常，而且目前沒有其餘NN在持有ZK集羣上的鎖，則加入選舉，而且申請鎖。(注：所謂的鎖，其實是ZK集羣上的一種特殊目錄)

若ZKFC檢查NN進程不正常，則退出選舉，並放棄ZK上的鎖(如持有)。

 

Q：若是不是NN進程死了，而是整個NN機器掉電了呢？

A：當集羣與ZKFC進程的鏈接斷開超過必定時間，鎖將自動過時，以便其餘NN能夠申請從新選舉。

Q：若是Active、Standby都死了呢？

A：很差意思，那就死透了。

 

---

 

上一期提到的另一個內容，Active NN負責將Edit Log寫入某個「共享存儲」，而Standby NN負責從該位置讀取以保持同步。

最簡單的，可使用NFS(Network File System)來擔任共享存儲。

可是NFS自己成爲了單點失敗，即，若是NFS系統壞了，致使Edit Log沒法讀寫，整個HDFS系統也就沒法工做。

所以，HDFS推薦使用的是專爲Edit Log高可用性所設計的「JournalNode(下稱JN))集羣」。

NN經過QJM(Quorum Journal Manager)進程將Edit Log寫入某JN節點，該JN節點須要將數據寫入其餘JN節點，直到數據被寫入集羣中的「多數節點」，本次操做纔算成功。

例如，JN集羣中共有3個節點，須要寫入到其中2個節點，即所謂的「多數」(majority)。

一般，JN集羣老是包含奇數個節點，至於爲何，我準備在介紹ZK的時候再來講明，由於兩者比較相似。

須要注意，雖然QJM的工做機制相似於ZK，但自己並無用到ZK，同時它也比ZK來的輕量級，它能夠跑在集羣現有的機器上，而不須要單獨爲它準備機器。

 

好了，這期就先到這，下期咱們將介紹現實世界中的HDFS集羣，以及Federation等概念。Cheers!

 

做者公衆號「程序員雜書館」，專一大數據，歡迎關注，每位關注者將獲贈《Spark快速大數據分析》紙質書一本