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