關於面試--【Standby Namenode Checkpoint】&【namenodeHA】

 Standby Namenode

 Standby Namenode(sbn)在進入standby狀態後對FSNamesystem調用startStandbyServices(final Configuration conf)，該方法會創建兩個重要的對象：EditLogTailer 和 StandbyCheckpointer，前者有兩個功能：

1. 觸發Active Namenode(nn) edits log roll
2. 從JournalNodes拉取edit log供fsimage合併

後者有三個功能：

1. 對namespace進行checkpoint

2. 清理陳舊的fsimage文件和edits文件(sbn並不會將拉取的edit log保存到磁盤，所以就不存在清理。nn將edit log寫到本地和JournalNodes，所以就涉及到陳舊edits文件的清理)，詳細清理過程後續博客會繼續分析。

3. 上傳新checkpoint出的fsimaeg文件到nn

       

     StandbyCheckpointer內部維護一個CheckpointerThread線程，該線程負責週期性檢查checkpoint條件是否滿足，如果滿足就進行checkpoint。

• 檢測週期(checkpointPeriod)：1000*Math.min(dfs.namenode.checkpoint.period, dfs.namenode.checkpoint.check.period)秒

• 條件1：最近一次合併到namespace的edit log的 txid 和最近一次做了checkpoint的txid的差值大於或者等於dfs.namenode.checkpoint.txns配置的數量(默認1000000)

• 條件2：當前時間距離最近一次checkpoint的時間間隔大於或者等於dfs.namenode.checkpoint.period (默認3600秒)

        CheckpointerThread每隔checkpointPeriod 秒檢查一次。優先檢查條件1是否滿足，如果滿足就進行checkpoint，否則檢查條件2，如果條件2滿足就進行checkpoint，否則就等待下一個檢查週期。一旦條件滿足，就進入doCheckpoint()方法進行checkpoint，流程如下： 

                                                                checkpoint流程【請點擊查看原圖】

        checkpoint過程本質就是將維護在內存中的namespace全量inode樹導出到磁盤保存爲fsimage_txid文件，並生成fsimage_txid文件的md5保存到fsimage_txid.md5文件。考慮到磁盤故障等問題，sbn 和 nn都可以配置多個目錄保存fsimage文件和edits文件【通常建議將fsimsge和edits分開保存到不同磁盤，這樣可以緩解磁盤壓力，畢竟運行中的nn會頻繁刷editlog到磁盤，checkpoint也會寫大文件到磁盤】，所以就需要將fsimage導出到多個目錄。導出過程由FSImageSaver完成，FSImageSaver實現了Runnable接口，內部根據_Protocol Buffer_定義好的fsimage的數據格式和壓縮格式將namespace寫入fsimage_txid.ckpt文件，寫入完成後再將此文件重名字爲fsimage_txid文件，並生成文件的md5碼保存到fsimage_txid.md5文件。對應於每個保存目錄都會創建一個線程和一個FSImageSaver對象，多個目錄並行導出。

        待新的fsimage文件生成之後，sbn會將磁盤上保留的陳舊的fsimage文件清理掉。歷史fsimage文件通常只會在元數據損壞的時候被用來做恢復用，適當保留幾份就夠了，太多了不僅沒用反而浪費磁盤空間。有關清理過程，後續會分析。

        最後一步，sbn將新的fsimage文件上傳給nn，這也是sbn除ha外的另一個存在意義。爲了在文件傳輸過程中也能快速完成transition to active(HDFS-4816)，StandbyCheckpointer會單獨啓動一個線程，在其內部由TransferFsImage用http協議(nn 用jetty維護了一個ImageServlet 用於 fsimage文件的上傳、下載)完成fsimage傳輸。

        涉及到的幾個重要參數：

參數名稱	說明	默認值
dfs.namenode.checkpoint.period	checkpoint的時間間隔	3600（秒）
dfs.namenode.checkpoint.check.period	檢查週期	60（秒）
dfs.namenode.checkpoint.txns	兩次checkpoint間的txid數量，超過該值就應該checkpoint	1000000
dfs.image.compress	是否壓縮生成的fsimage文件	false
dfs.image.compression.codec	壓縮格式	org.apache.hadoop.io.compress.DefaultCodec

前三個參數關係到checkpoint的頻率，如果過於頻繁會導致頻繁上傳fsimaeg文件、頻繁寫磁盤，給nn造成壓力，影響正常服務。如果頻率低，則會導致過多事務得不到持久化，最終nn重啓時間延長，sbn也就失去了意義。

--------------------------------------------------------------------------------------------------------------

HA（高可用）介紹

Hadoop2.0的HA 機制有兩個NameNode，一個是Active狀態，另一個是Standby狀態。兩者的狀態可以切換，但同時最多隻有1個是Active狀態。只有Active 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，BackupNode的功能：合併edits文件和fsimage文件，使fsimage文件一直保持更新。所以啓動了hadoop2.0的HA機制之後，SecondaryNameNode，CheckpointNode，BackupNode這些都不需要了。

數據同步方式：NFS與 QJM（Quorum Journal Manager ）

1、NFS

NFS作爲Active NameNode和Standby NameNode之間數據共享的存儲。Active NameNode會把最近的edits文件寫到NFS，而Standby NameNode從NFS中把數據讀過來。這個方式的缺點是，如果Active NameNode或者Standby Namenode有一個和NFS之間網絡有問題，則會造成他們之前數據的同步出問題。

2、 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的失敗。

Active和Standby兩個NameNode之間的數據交互流程爲：

1）NameNode在啓動後，會先加載FSImage文件和共享目錄上的EditLog Segment文件；

2）Standby NameNode會啓動EditLogTailer線程和StandbyCheckpointer線程，正式進入Standby模式；

3）Active NameNode把EditLog提交到JournalNode集羣；

4）Standby NameNode上的EditLogTailer 線程定時從JournalNode集羣上同步EditLog；

5）Standby NameNode上的StandbyCheckpointer線程定時進行Checkpoint，並將Checkpoint之後的FSImage文件上傳到Active NameNode。（在Hadoop 2.0中不再有Secondary NameNode這個角色了，StandbyCheckpointer線程的作用其實是爲了替代 Hadoop 1.0版本中的Secondary NameNode的功能。）

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

主備NameNode切換

Active NameNode和Standby NameNode可以隨時切換，可以人工和自動。人工切換是通過執行HA管理命令來改變NameNode的狀態，從Standby到Active，或從Active到Standby。自動切換則在Active NameNode掛掉的時候，Standby NameNode自動切換成Active狀態。

主備NameNode的自動切換需要配置Zookeeper。Active NameNode和Standby NameNode把他們的狀態實時記錄到Zookeeper中，Zookeeper監視他們的狀態變化。當Zookeeper發現Active NameNode掛掉後，會自動把Standby NameNode切換成Active NameNode。