為了要管理lab裡的Hadoop cluster,針對Hadoop的NameNode、SecondaryNameNode、CheckpointNode與BackupNode做個了survay。

NameNode

Hadoop的metadata是存放在運行Namenode的server的memory裡面,而Bamenode的工作就是將clients對metadata的讀寫修改紀錄在edits裡。

當namenode被啟動的時候,會先將HDFS上的fsimage與edits做合併,已取得完整的metadata。此時,原本的fsimage會被更新。

之後,在NameNode運作的期間,client對metadata的access還是只會記錄在新的edits裡,直到下一次NameNode restart的時候,周而復始的更新fsimage、產生新的edits。

SecondaryNameNode

SecondaryNameNode並不是第二個NameNode,充其量只是NameNode的一個tool,幫助NameNode管理metadata。

透過上一段我們得知,namenode會在每次start的時候,將舊的fsimage與edits整合得到新的metadata,並更新fsimage。之後在運作期間的任何修改都是存放在edits。

因此,namenode運作時間越長,理論上來說,下一次namenode start的時候,整併資料的時間就會越久。而SecondaryNameNode就是被設計用來解決這個問題。

SecondayNameNode會定期的向NameNode取得最新的metadata,這期間NameNode會停止對edits的讀寫,並且將log轉入edits.new中。然後SecondaryNameNode將edits與fsimage合併,產生一個新的fsimage。

完成之後,SecondaryNameNode會將新的fsimage傳回NameNode。當NameNode接收到新的fsimage之後,會覆蓋掉舊的fsimage,並刪除舊的edits,然後將edits.new重新命名為edit。

透過這個機制可以使得edits的檔案大小限制在一個固定的範圍內,使得NameNode在下一次restart之後,可以快速地完成整合metadata與啟動服務。

此外,當NameNode發生crash時,可以利用SecondaryNameNode上的fsimage進行recovery。當然,在SecondaryNameNode最後一次整併之後的data就無可避免地消失了。

CheckpointNode

由於SecondaryNameNode的名稱令人容易混淆,因此Hadoop 1.0.4版之後有考慮以CheckpointNode來取而代之。

CheckpointNode的架構與SecondaryNameNode相差無異,惟啟動命令不同:

hdfs namenode -checkpoint

BackupNode

由於SecondaryNameNode只有checkpoint的功用,因次也具有一些缺點:

  • fsimage較舊
  • Multi-SecondaryNameNode會造成data不一致,同時效能也較差

因此,新版的Hadoop(version 2.2)新增的BackupNode。

在新版的Hadoop中,BackupNode與NameNode擁有相同的資料,並且NameNode會將每次對edits的讀寫都同步傳給BackupNode,使得BackupNode擁有最新的metadata。


參考資料

Comments

comments powered by Disqus