NameNode與Secondary NameNode

很多人都認為，Secondary NameNode是NameNode的備份，是為了防止NameNode的單點失敗的，其實並不是在這樣。文章Secondary Namenode - What it really do? (需FQ)寫的很通俗易懂，現將其翻譯如下：

Secondary NameNode:它究竟有什麼作用？

在Hadoop中，有一些命名不好的模組，Secondary NameNode是其中之一。從它的名字上看，它給人的感覺就像是NameNode的備份。但它實際上卻不是。

很多Hadoop的初學者都很疑惑，Secondary NameNode究竟是做什麼的，而且它為什麼會出現在HDFS中。

因此，在這篇文章中，我想要解釋下Secondary NameNode在HDFS中所扮演的角色。

從它的名字來看，你可能認為它跟NameNode有點關係。沒錯，你猜對了。因此在我們深入瞭解Secondary NameNode之前，我們先來看看NameNode是做什麼的。

NameNode

NameNode主要是用來儲存HDFS的元資料資訊，比如名稱空間資訊，塊資訊等。當它執行的時候，這些資訊是存在記憶體中的。但是這些資訊也可以持久化到磁碟上。

上面的這張圖片展示了NameNode怎麼把元資料儲存到磁碟上的。這裡有兩個不同的檔案：

fsimage - 它是在NameNode啟動時對整個檔案系統的快照
edit logs - 它是在NameNode啟動後，對檔案系統的改動序列
只有在NameNode重啟時，edit logs才會合併到fsimage檔案中，從而得到一個檔案系統的最新快照

但是在生產叢集中NameNode是很少重啟的，這也意味著當NameNode運行了很長時間後，edit logs檔案會變得很大。

在這種情況下就會出現下面一些問題：

edit logs檔案會變的很大，怎麼去管理這個檔案是一個挑戰。
NameNode的重啟會花費很長時間，因為有很多改動[筆者注:在edit logs中]要合併到fsimage檔案上。
如果NameNode掛掉了，那我們就丟失了很多改動因為此時的fsimage檔案非常舊。
因此為了克服這個問題，我們需要一個易於管理的機制來幫助我們減小edit logs檔案的大小和得到一個最新的fsimage檔案，這樣也會減小在NameNode上的壓力。

這跟Windows的恢復點是非常像的，Windows的恢復點機制允許我們對OS進行快照，這樣當系統發生問題時，我們能夠回滾到最新的一次恢復點上。

現在我們明白了NameNode的功能和所面臨的挑戰 - 保持檔案系統最新的元資料。那麼，這些跟Secondary NameNode又有什麼關係呢？

Secondary NameNode

SecondaryNameNode就是來幫助解決上述問題的，它的職責是合併NameNode的edit logs到fsimage檔案中。

上面的圖片展示了Secondary NameNode是怎麼工作的。

首先，它定時到NameNode去獲取edit logs，並更新到fsimage上。[筆者注：Secondary NameNode自己的fsimage]
一旦它有了新的fsimage檔案，它將其拷貝回NameNode中。
NameNode在下次重啟時會使用這個新的fsimage檔案，從而減少重啟的時間。
Secondary NameNode的整個目的是在HDFS中提供一個檢查點。它只是NameNode的一個助手節點。這也是它在社群內被認為是檢查點節點的原因。

現在，我們明白了Secondary NameNode所做的不過是在檔案系統中設定一個檢查點來幫助NameNode更好的工作。它不是要取代掉NameNode也不是NameNode的備份。

所以從現在起，讓我們養成一個習慣，稱呼它為檢查點節點吧。

這篇文章基本上已經清楚的介紹了Secondary NameNode的工作以及為什麼要這麼做。

最後補充一點細節，是關於NameNode是什麼時候將改動寫到edit logs中的？

這個操作實際上是由DataNode的寫操作觸發的，當我們往DataNode寫檔案時，DataNode會跟NameNode通訊，告訴NameNode什麼檔案的第幾個block放在它那裡，NameNode這個時候會將這些元資料資訊寫到edit logs檔案中。

NameNode HA與Secondary NameNode

在hadoop2.0之前，namenode只有一個，存在單點問題（雖然hadoop1.0有secondarynamenode，checkpointnode，buckcupnode這些，但是單點問題依然存在），在hadoop2.0引入了HA機制。

hadoop2.0的HA機制官方介紹了有2種方式，一種是NFS（Network File System）方式，另外一種是QJM（Quorum Journal Manager）方式。

2 基本原理 

hadoop2.0的HA 機制有兩個namenode，一個是active namenode，狀態是active；另外一個是standby namenode，狀態是standby。

兩者的狀態是可以切換的，但不能同時兩個都是active狀態，最多隻有1個是active狀態。只有active namenode提供對外的服務，standby namenode是不對外服務的。

active namenode和standby namenode之間通過NFS或者JN（journalnode，QJM方式）來同步資料。

active namenode會把最近的操作記錄寫到本地的一個edits檔案中（edits file），並傳輸到NFS或者JN中。

standby namenode定期的檢查，從NFS或者JN把最近的edit檔案讀過來，然後把edits檔案和fsimage檔案合併成一個新的fsimage，合併完成之後會通知active namenode獲取這個新fsimage。

active namenode獲得這個新的fsimage檔案之後，替換原來舊的fsimage檔案。

這樣，保持了active namenode和standby namenode的資料的實時同步，standby namenode可以隨時切換成active namenode（譬如active namenode掛了）。

而且還有一個原來hadoop1.0的secondarynamenode，checkpointnode，buckcupnode的功能：合併edits檔案和fsimage檔案，使fsimage檔案一直保持更新。

所以啟動了hadoop2.0的HA機制之後，secondarynamenode，checkpointnode，buckcupnode這些都不需要了。

3 NFS方式 

NFS作為active namenode和standby namenode之間資料共享的儲存。active namenode會把最近的edits檔案寫到NFS，而standby namenode從NFS中把資料讀過來。

這個方式的缺點是，如果active namenode或者standby namenode有一個和NFS之間網路有問題，則會造成他們之前資料的同步出問題。

4 QJM（Quorum Journal Manager ）方式 

QJM的方式可以解決上述NFS容錯機制不足的問題。active namenode和standby namenode之間是通過一組journalnode（數量是奇數，可以是3,5,7...,2n+1）來共享資料。

active namenode把最近的edits檔案寫到2n+1個journalnode上，只要有n+1個寫入成功就認為這次寫入操作成功了，然後standby namenode就可以從journalnode上讀取了。

可以看到，QJM方式有容錯的機制，可以容忍n個journalnode的失敗。

5 主備節點的切換

active namenode和standby namenode可以隨時切換。當active namenode掛掉後，也可以把standby namenode切換成active狀態，成為active namenode。

可以人工切換和自動切換。人工切換是通過執行HA管理的命令來改變namenode的狀態，從standby到active，或者從active到standby。

自動切換則在active namenode掛掉的時候，standby namenode自動切換成active狀態，取代原來的active namenode成為新的active namenode，HDFS繼續正常工作。

主備節點的自動切換需要配置zookeeper。active namenode和standby namenode把他們的狀態實時記錄到zookeeper中，zookeeper監視他們的狀態變化。

當zookeeper發現active namenode掛掉後，會自動把standby namenode切換成active namenode。

6 實戰tips 

• QJM方式有明顯的優點，一是本身就有fencing的功能，二是通過多個journal節點增強了系統的健壯性，所以建議在生成環境中採用QJM的方式。
• journalnode消耗的資源很少，不需要額外的機器專門來啟動journalnode，可以從hadoop叢集中選幾臺機器同時作為journalnode。