Hadoop商業環境實戰-HDFS NameNode 宕機元數據一致保障及SNN機制深刻研究

版權聲明：本套技術專欄是做者（秦凱新）平時工做的總結和昇華，經過從真實商業環境抽取案例進行總結和分享，並給出商業應用的調優建議和集羣環境容量規劃等內容，請持續關注本套博客。版權聲明：禁止轉載，歡迎學習。QQ郵箱地址：1120746959@qq.com，若有任何商業交流，可隨時聯繫。

1 從文件目錄樹談起(FSImage與EditLog)

• 文件目錄樹存在於NameNode的內存裏，維護了整個HDFS這個分佈式文件系統元數據信息。
• 任何對文件的建立，修改，刪除都會在內存中完成，並持久化到磁盤，也即edits log。
• 元數據的存儲形式主要有3類：內存鏡像、磁盤鏡像(FSImage)、日誌(EditLog)。
• 在Namenode啓動時，會加載磁盤鏡像到內存中以進行元數據的管理，存儲在NameNode內存;
• 磁盤鏡像是某一時刻HDFS的元數據信息的快照，包含全部相關Datanode節點文件塊映射關係和命名空間(Namespace)信息，存儲在NameNode本地文件系統;
• 日誌文件記錄client發起的每一次操做信息，即保存全部對文件系統的修改操做，用於按期和磁盤鏡像合併成最新鏡像，保證NameNode元數據信息的完整，存儲在NameNode本地和共享存儲系統Quorum Journal Manager(QJM)中。
• SNN會按期將本地FSImage和從QJM上拉回的ANN的EditLog進行合併，合併完後再經過RPC傳回ANN。
• 悖論：若頻繁的修改內存裏的元數據，並持久化，會存在大量的隨機IO，則性能極低。所以JournalNodes誕生了，利用ZKFC選舉和雙緩存機制實現高併發數據讀寫。

seen_txid: 是一個事務ID，這個事務ID是EditLog最新的一個結束事務id，當NameNode重啓時，會順序遍歷從edits_0000000000000000001到seen_txid所記錄的txid所在的日誌文件，進行元數據恢復，若是該文件丟失或記錄的事務ID有問題，會形成數據塊信息的丟失。

2 Secondary NameNode 優勝劣汰的棄兒（單點故障）

整個核心分爲最近更新的edit logs 和全局系統快照fsimage 。NameNode 宕機後，根據其最近更新的edit logs 和全局系統快照fsimage（Secondary NameNode幫忙協助處理的）在重啓時更新到內存進行回放，便可從新恢復整個系統的元數據。

• fsimage - 它是在NameNode啓動時對整個文件系統的快照 。
• edit logs - 它是在NameNode啓動後，對文件系統的改動序列 。

Secondary NameNode 誕生的重點緣由闡述：

• hadoop僅有單NameNode時：由於只有在NameNode重啓時，edit logs纔會合併到fsimage文件中，從而獲得一個文件系統的最新快照。可是在產品集羣中NameNode是不多重啓的，這也意味着當NameNode運行了很長時間後，edit logs文件會變得很大。
• 怎麼去管理edit logs是一個挑戰。 NameNode的重啓會花費很長時間，由於有不少改動（在edit logs中）要合併到fsimage文件上。 若是NameNode掛掉了，那咱們就丟失了不少改動，由於此時的fsimage文件很是舊。
• 爲了減少edit logs文件的大小和獲得一個最新的fsimage文件，初期引入了Secondary NameNode機制。
• Secondary NameNode會定時到NameNode中去獲取edit logs，並更新到Secondary NameNode 本身的fsimage上。一旦它有了新的fsimage文件，它將其拷貝回NameNode中。 NameNode在下次重啓時能夠直接使用這個新的fsimage文件，從而減小重啓的時間。
• secondary NameNode的整個目的是在HDFS中提供一個檢查點。它只是NameNode的一個助手節點。這也是它在社區內被認爲是檢查點節點的緣由。

  

2 JournalNodes 歷史動亂的維護者（集羣模式）

• 在一個典型的HA集羣中，每一個NameNode是一臺獨立的服務器。在任一時刻，只有一個NameNode處於active狀態，另外一個處於standby狀態。

• active狀態的NameNode負責全部的客戶端操做，standby狀態的NameNode處於從屬地位，維護着數據狀態，隨時準備切換。

• 兩個NameNode爲了數據同步，會經過一組稱做JournalNodes的獨立進程進行相互通訊。當active狀態的NameNode的命名空間有任何修改時，會告知大部分的JournalNodes進程。

• standby狀態的NameNode有能力讀取JournalNodes中的變動信息，而且一直監控edit log的變化，把變化應用於本身的命名空間。standby能夠確保在集羣出錯時，命名空間狀態已經徹底同步了。

  

3 宕機內存元數據一致性回放SNN機制（高可用）

• 第一步：通知hdfs客戶端，我要上傳一份文件。（提早設置副本）
• 第二步：更新Active NameNode(ANN)的內存元數據，並寫一份edits log到JournalNodes集羣上，另外一份寫在本地。
• 第三步：Standby NameNode （SNN）實時讀取JournalNodes中更新的 edits log，更新Standby NameNode內存元數據，並每隔一段時間（SNN上有一個線程StandbyCheckpointer），元數據寫入到磁盤的fsimage文件中，並同步到Active NameNode。
• 第四步：一旦Active NameNode宕機，Standby NameNode 直接讀取最近更新的edits log（不會太多）和 fsimage文件，進行內存中回放，便可實現快速恢復使用。
• 第五步：若是沒有宕機，hdfs客戶端負責分佈式寫副本便可。

4 總結

本文在這裏詳細介紹了宕機內存元數據一致性回放機制。注意這裏只是盲人摸象，只有藉助QJM和ZKFC的選舉機制，同時使用hadoop 分段加鎖 + 內存雙緩衝機制，才能真正實現每秒上千次的高併發數據訪問讀寫，從而造成了整套數據宕機恢復的體系。

版權聲明：本套技術專欄是做者（秦凱新）平時工做的總結和昇華，經過從真實商業環境抽取案例進行總結和分享，並給出商業應用的調優建議和集羣環境容量規劃等內容，請持續關注本套博客。

秦凱新 於深圳 201811222049