為了要管理 lab 裡的 Hadoop cluster，針對 Hadoop 的 NameNode、SecondaryNameNode、CheckpointNode 與 BackupNode 做個了survay。
NameNode
Hadoop 的 metadata 是存放在運行 Namenode 的 server 的 memory 裡面，而 Namenode 的工作就是將 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 會在每次啟動的時候，將舊的 fsimage 與 edits 整合得到新的 metadata，並更新 fsimage。之後在運作期間的任何修改都是存放在 edits。
因此，Namenode運作時間越長，理論上來說，下一次啟動 Namenode 的時候，合併資料的時間就會越久。而 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 在重啟之後，可以快速地完成整合 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。