Hadoop商業環境實戰-HDFS NameNode 宕機元資料一致保障及SNN機制深入研究
版權宣告：本套技術專欄是作者（秦凱新）平時工作的總結和昇華，通過從真實商業環境抽取案例進行總結和分享，並給出商業應用的調優建議和叢集環境容量規劃等內容，請持續關注本套部落格。版權宣告：禁止轉載，歡迎學習。QQ郵箱地址：[email protected]，如有任何商業交流，可隨時聯絡。
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