大資料小白系列——HDFS(3)

Morven.Huang發表於2018-12-20

這裡是大資料小白系列,這是本系列的第三篇,介紹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快速大資料分析》紙質書一本

相關文章