淺析Secondary NameNode與namenode
前言
最近剛接觸Hadoop, 一直沒有弄明白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的這部分。]
因此為了克服這個問題,我們需要一個易於管理的機制來幫助我們減小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檔案中。
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Hadoop Namenode和Secondary Namenode
Secondarynamenode作用
SecondaryNameNode有兩個作用,一是映象備份,二是日誌與映象的定期合併。兩個過程同時進行,稱為checkpoint. 映象備份的作用:備份fsimage(fsimage是元資料傳送檢查點時寫入檔案);日誌與映象的定期合併的作用:將Namenode中edits日誌和fsimage合併,防止(如果Namenode節點故障,namenode下次啟動的時候,會把fsimage載入到記憶體中,應用edit log,edit log往往很大,導致操作往往很耗時。)
Secondarynamenode工作原理
日誌與映象的定期合併總共分五步:
- SecondaryNameNode通知NameNode準備提交edits檔案,此時主節點產生edits.new
- SecondaryNameNode通過http get方式獲取NameNode的fsimage與edits檔案(在SecondaryNameNode的current同級目錄下可見到 temp.check-point或者previous-checkpoint目錄,這些目錄中儲存著從namenode拷貝來的映象檔案)
- SecondaryNameNode開始合併獲取的上述兩個檔案,產生一個新的fsimage檔案fsimage.ckpt
- SecondaryNameNode用http post方式傳送fsimage.ckpt至NameNode
- NameNode將fsimage.ckpt與edits.new檔案分別重新命名為fsimage與edits,然後更新fstime,整個checkpoint過程到此結束。 在新版本的hadoop中(hadoop0.21.0),SecondaryNameNode兩個作用被兩個節點替換, checkpoint node與backup node. SecondaryNameNode備份由三個引數控制fs.checkpoint.period控制週期,fs.checkpoint.size控制日誌檔案超過多少大小時合併, dfs.http.address表示http地址,這個引數在SecondaryNameNode為單獨節點時需要設定。
相關配置檔案
core-site.xml:這裡有2個引數可配置,但一般來說我們不做修改。fs.checkpoint.period表示多長時間記錄一次hdfs的映象。預設是1小時。fs.checkpoint.size表示一次記錄多大的size,預設64M。
<property><name>fs.checkpoint.period</name> <value>3600</value> <description>The number of seconds between two periodic checkpoints. </description> </property>
<property> <name>fs.checkpoint.size</name> <value>67108864</value> <description>The size of the current edit log (in bytes) that triggers a periodic checkpoint even if the fs.checkpoint.period hasn’t expired. </description> </property> |
映象備份的週期時間是可以修改的,如果不想一個小時備份一次,可以改的時間短點。core-site.xml中的fs.checkpoint.period值
Secondarynamenode工作原理圖
這也解釋了下面的問題:
(1)、為什麼namenode和Secondary namenode需要同樣大記憶體
(2)、大叢集中namenode和Secondary namenode需要是各自獨立的兩個節點。
Checkpoint的日誌資訊
2011-07-19 23:59:28,435 INFO org.apache.hadoop.hdfs.server.namenode.FSNamesystem: Number of transactions: 0 Total time for transactions(ms): 0Number of transactions batched in Syncs: 0 Number of syncs: 0 SyncTimes(ms): 02011-07-19 23:59:28,472 INFO org.apache.hadoop.hdfs.server.namenode.SecondaryNameNode: Downloaded file fsimage size 548 bytes. 2011-07-19 23:59:28,473 INFO org.apache.hadoop.hdfs.server.namenode.SecondaryNameNode: Downloaded file edits size 631 bytes. 2011-07-19 23:59:28,486 INFO org.apache.hadoop.hdfs.server.namenode.FSNamesystem: fsOwner=hadadm,hadgrp 2011-07-19 23:59:28,486 INFO org.apache.hadoop.hdfs.server.namenode.FSNamesystem: supergroup=supergroup 2011-07-19 23:59:28,486 INFO org.apache.hadoop.hdfs.server.namenode.FSNamesystem: isPermissionEnabled=true 2011-07-19 23:59:28,488 INFO org.apache.hadoop.hdfs.server.common.Storage: Number of files = 6 2011-07-19 23:59:28,489 INFO org.apache.hadoop.hdfs.server.common.Storage: Number of files under construction = 0 2011-07-19 23:59:28,490 INFO org.apache.hadoop.hdfs.server.common.Storage: Edits file /home/hadadm/clusterdir/tmp/dfs/namesecondary/current/edits of size 631 edits # 6 loaded in 0 seconds. 2011-07-19 23:59:28,493 INFO org.apache.hadoop.hdfs.server.common.Storage: Image file of size 831 saved in 0 seconds. 2011-07-19 23:59:28,513 INFO org.apache.hadoop.hdfs.server.namenode.FSNamesystem: Number of transactions: 0 Total time for transactions(ms): 0Number of transactions batched in Syncs: 0 Number of syncs: 0 SyncTimes(ms): 0 2011-07-19 23:59:28,543 INFO org.apache.hadoop.hdfs.server.namenode.SecondaryNameNode: Posted URL master:50070putimage=1&port=50090&machine=10.253.74.234&token=-18:1766583108:0:1311091168000:1311087567797 2011-07-19 23:59:28,561 WARN org.apache.hadoop.hdfs.server.namenode.SecondaryNameNode: Checkpoint done. New Image Size: 831 |
Namenode/Secondarynamenode檔案結構
[[email protected] /home/hadadm/clusterdir/tmp/dfs/namesecondary/current]$ ll 總用量 24 drwxr-xr-x 2 hadadm hadgrp 4096 7月 19 22:59 ./ drwxr-xr-x 5 hadadm hadgrp 4096 7月 19 23:59 ../ -rw-r–r– 1 hadadm hadgrp 4 7月 19 23:59 edits -rw-r–r– 1 hadadm hadgrp 548 7月 19 22:59 fsimage -rw-r–r– 1 hadadm hadgrp 8 7月 19 22:59 fstime -rw-r–r– 1 hadadm hadgrp 101 7月 19 22:59 VERSION
[[email protected] /home/hadadm/clusterdir/tmp/dfs/namesecondary/current] $ cat VERSION #Tue Jul 19 22:59:27 CST 2011 namespaceID=1766583108 cTime=0 storageType=NAME_NODE layoutVersion=-18 推這裡VERSION表示的是secondarynamenode中的fsimage版本是22:59時的;加上edits應用的日誌就可以到23:59 |
[[email protected] /home/hadadm/clusterdir/dfs/name/current]$ ls -l 總用量 16 -rw-r–r– 1 hadadm hadgrp 4 7月 19 23:59 edits -rw-r–r– 1 hadadm hadgrp 831 7月 19 23:59 fsimage -rw-r–r– 1 hadadm hadgrp 8 7月 19 23:59 fstime -rw-r–r– 1 hadadm hadgrp 101 7月 19 23:59 VERSION
[[email protected] /home/hadadm/clusterdir/dfs/name/current] $ cat VERSION #Tue Jul 19 23:59:28 CST 2011 namespaceID=1766583108 cTime=0 storageType=NAME_NODE layoutVersion=-18 這裡VERSION表示的是namenode中的fsimage版本是23:59時的; edits應用沒有變更 這裡的fsimage相當於secondarynamenode裡面的fsimage+edits |
[[email protected] /home/hadadm/clusterdir/tmp/dfs/namesecondary]$ ls -l 總用量 12 drwxr-xr-x 2 hadadm hadgrp 4096 7月 19 23:59 current drwxr-xr-x 2 hadadm hadgrp 4096 7月 19 22:59 image -rw-r–r– 1 hadadm hadgrp 0 7月 19 23:59 in_use.lock drwxr-xr-x 2 hadadm hadgrp 4096 7月 19 22:59 previous.checkpoint
[[email protected] /home/hadadm/clusterdir/tmp/dfs/namesecondary] $ ls -l previous.checkpoint/ 總用量 16 -rw-r–r– 1 hadadm hadgrp 4 7月 19 23:59 edits -rw-r–r– 1 hadadm hadgrp 548 7月 19 22:59 fsimage -rw-r–r– 1 hadadm hadgrp 8 7月 19 22:59 fstime -rw-r–r– 1 hadadm hadgrp 101 7月 19 22:59 VERSION 這裡上一個檢查點的資料是可以用來恢復資料的 |
Import Checkpoint(恢復資料)
如果主節點namenode掛掉了,硬碟資料需要時間恢復或者不能恢復了,現在又想立刻恢復HDFS,這個時候就可以import checkpoint。步驟如下:
- 準備原來機器一樣的機器,包括配置和檔案
- 建立一個空的資料夾,該資料夾就是配置檔案中dfs.name.dir所指向的資料夾。
- 拷貝你的secondary NameNode checkpoint出來的檔案,到某個資料夾,該資料夾為fs.checkpoint.dir指向的資料夾(例如:/home/hadadm/clusterdir/tmp/dfs/namesecondary)
- 執行命令bin/hadoop namenode –importCheckpoint
- 這樣NameNode會讀取checkpoint檔案,儲存到dfs.name.dir。但是如果你的dfs.name.dir包含合法的 fsimage,是會執行失敗的。因為NameNode會檢查fs.checkpoint.dir目錄下映象的一致性,但是不會去改動它。
一般建議給maste配置多臺機器,讓namesecondary與namenode不在同一臺機器上值得推薦的是,你要注意備份你的dfs.name.dir和 ${hadoop.tmp.dir}/dfs/namesecondary。
後續版本中的backupnode
Checkpoint Node 和 Backup Node在後續版本中hadoop-0.21.0,還提供了另外的方法來做checkpoint:Checkpoint Node 和 Backup Node。則兩種方式要比secondary NameNode好很多。所以 The Secondary NameNode has been deprecated. Instead, consider using the Checkpoint Node or Backup Node. Checkpoint Node像是secondary NameNode的改進替代版,Backup Node提供更大的便利,這裡就不再介紹了。
BackupNode : 備份結點。這個結點的模式有點像 mysql 中的主從結點複製功能, NN 可以實時的將日誌傳送給 BN ,而 SNN 是每隔一段時間去 NN 下載 fsimage 和 edits 檔案,而 BN 是實時的得到操作日誌,然後將操作合併到 fsimage 裡。在 NN 裡提供了二個日誌流介面: EditLogOutputStream 和 EditLogInputStream 。即當 NN 有日誌時,不僅會寫一份到本地 edits 的日誌檔案,同時會向 BN 的網路流中寫一份,當流緩衝達到閥值時,將會寫入到 BN 結點上, BN 收到後就會進行合併操作,這樣來完成低延遲的日誌複製功能。 總結: 當前的備份結點都是冷備份,所以還需要實現熱備份,使得 NN 掛了後,從結點自動的升為主結點來提供服務。 主 NN 的效率問題: NN 的檔案過多導致記憶體消耗問題, NN 中檔案鎖問題, NN 的啟動時間。 |
因為Secondarynamenaode不是實施備份和同步,所以SNN會丟掉當前namenode的edit log資料,應該來說backupnode可以解決這個問題
在初學Hadoop時,有個讓人疑惑的概念:Secondary NameNode,也叫輔助namenode。從命名看,好像是第二個namenode,用於備份主namenode,在主namenode失敗後啟動。那麼,Secondary NameNode的作用是什麼?是如何工作的?
一,NameNode
HDFS叢集有兩類節點以管理者和工作者的工作模式執行,namenode就是其中的管理者。它管理著檔案系統的名稱空間,維護著檔案系統樹及整棵樹的所有檔案和目錄。這些資訊以兩個檔案的形式保存於記憶體或者磁碟,這兩個檔案是:名稱空間映象檔案fsimage和編輯日誌檔案edit logs ,同時namenode也記錄著每個檔案中各個塊所在的資料節點資訊。
namenode對元資料的操作過程
圖中有兩個檔案:
(1)fsimage:檔案系統對映檔案,也是元資料的映象檔案(磁碟中),儲存某段時間namenode記憶體元資料資訊。
(2)edits log:操作日誌檔案。
這種工作方式的特點:
(1)namenode始終在記憶體中儲存元資料(metedata),使得“讀操作”更加快、
(2)有“寫請求”時,向edits檔案寫入日誌,成功返回後才修改記憶體,並向客戶端返回。
(3)fsimage檔案為metedata的映象,不會隨時同步,與edits合併生成新的fsimage。
從以上特點可以知道,edits檔案會在叢集執行的過程中不斷增多,佔用更多的儲存空間,雖然有合併,但是隻有在namenode重啟時才會進行。並且在實際工作環境很少重啟namenode,
這就帶來了一下問題:
(1)edits檔案不斷增大,如何儲存和管理?
(2)因為需要合併大量的edits檔案生成fsimage,導致namenode重啟時間過長。
(3)一旦namenode宕機,用於恢復的fsiamge資料很舊,會造成大量資料的丟失。
二,Secondary NameNode
上述問題的解決方案就是執行輔助namenode–Secondary NameNode,為主namenode記憶體中的檔案系統元資料建立檢查點,Secondary NameNode所做的不過是在檔案系統中設定一個檢查點來幫助NameNode更好的工作。它不是要取代掉NameNode也不是NameNode的備份,
SecondaryNameNode有兩個作用,一是映象備份,二是日誌與映象的定期合併。兩個過程同時進行,稱為checkpoint(檢查點)。
映象備份的作用:備份fsimage(fsimage是元資料傳送檢查點時寫入檔案);
日誌與映象的定期合併的作用:將Namenode中edits日誌和fsimage合併,防止如果Namenode節點故障,namenode下次啟動的時候,會把fsimage載入到記憶體中,應用edits log,edits log往往很大,導致操作往往很耗時。(這也是namenode容錯的一套機制)
Secondary NameNode建立檢查點過程
Secondarynamenode工作過程
(1)SecondaryNameNode通知NameNode準備提交edits檔案,此時主節點將新的寫操作資料記錄到一個新的檔案edits.new中。
(2)SecondaryNameNode通過HTTP GET方式獲取NameNode的fsimage與edits檔案(在SecondaryNameNode的current同級目錄下可見到 temp.check-point或者previous-checkpoint目錄,這些目錄中儲存著從namenode拷貝來的映象檔案)。
(3)SecondaryNameNode開始合併獲取的上述兩個檔案,產生一個新的fsimage檔案fsimage.ckpt。
(4)SecondaryNameNode用HTTP POST方式傳送fsimage.ckpt至NameNode。
(5)NameNode將fsimage.ckpt與edits.new檔案分別重新命名為fsimage與edits,然後更新fstime,整個checkpoint過程到此結束。
SecondaryNameNode備份由三個引數控制fs.checkpoint.period控制週期(以秒為單位,預設3600秒),fs.checkpoint.size控制日誌檔案超過多少大小時合併(以位元組為單位,預設64M), dfs.http.address表示http地址,這個引數在SecondaryNameNode為單獨節點時需要設定。
從工作過程可以看出,SecondaryNameNode的重要作用是定期通過編輯日誌檔案合併名稱空間映象,以防止編輯日誌檔案過大。SecondaryNameNode一般要在另一臺機器上執行,因為它需要佔用大量的CPU時間與namenode相同容量的記憶體才可以進行合併操作。它會儲存合併後的名稱空間映象的副本,並在namenode發生故障時啟用。