Categories
程式開發

大規模集群,HDFS如何從2.7滾動升級到3.2


1. 為什麼要升級

在2017年底, Hadoop3.0 發布了,到目前為止, Hadoop 發布的最新版本為3.2.1。在 Hadoop3 中有很多有用的新特性出現,如支持 ErasureCoding、多 NameNode、Standby NameNode read、DataNode Disk Balance、HDFS RBF 等等。除此之外,還有很多性能優化以及 BUG 修復。

其中最吸引我們的就是 ErasureCoding 特性,數據可靠性保持不變的情況下可以降低數據的存儲副本數量,結合公司的降成本目標以及用戶的痛點,我們對此做了深入的調研。同時,在實際工作中我們發現,我們遇到的一些 BUG 以及想做的一些優化點,社區早已經修復或者實現。內部使用的 Hadoop 版本對應社區的2.7.2,由於社區很多 BUG 修復是不會移植到太低版本的,我們解決問題時花費了較多精力在移植與測試驗證中。

如果升級到 HDFS3.2 版本,可以站在巨人肩膀上繼續工作,做一些更有意義的事情。

2. 調研升級方案

升級方式有兩種:Express 和 Rolling,Express 升級過程是停止現有服務,然後使用新版本啟動服務;Rolling 升級過程是滾動升級,不停服務,對用戶無感知。對於公司來說,當然滾動升級是最好的方案,離線集群用戶非常之多,影響面非常之大。

目前業界還沒有滾動升級的方案從2.x 版本升級到3.x 版本,Cloudera 和 Hontonworks 公司(目前兩個公司已合併)給出的推薦方案仍然是 Express 升級,例如 Hontonworks 的文檔中描述,目前滾動升級存在一些問題尚未解決,推薦用戶做 Express 升級。

當前滾動升級存在的問題記錄在 Apache Hadoop Wiki 中,主要問題是 Edit Log 不兼容,無法進行滾動升級。調研之後,我們對整個升級方案有了一個初步掌握,開始著手解決這些問題。

HDFS 整體架構圖(網絡上獲取)如下所示,我們準備對服務端進行升級,包括 JournalNode,NameNode,ZKFC,DataNode 組件。 Client 端受到 Spark,Hive,Flink 等等很多組件依賴,目前這些組件還不支持 Hadoop3,因此 Client 版本暫時保持不變。

大規模集群,HDFS如何從2.7滾動升級到3.2 1

3. 解決滾動升級中遇到的問題

滾動升級的操作流程在 Hadoop 官方升級文檔中有介紹,概括起來大致步驟如下:

1.JournalNode 升級,使用新版本依次重啟 JournalNode
2.NameNode 升級
2.1升級準備,生成 fallback fsimage 文件
2.2使用新版本 Hadoop 重啟 Standby NameNode,重啟 ZKFC
2.3做 failover,使升級後的 NameNode 變成 Active 節點
2.4使用新版本 Hadoop 重啟另一個 NameNode,重啟 ZKFC
3.升級 DataNode,使用新版本 Hadoop 重啟所有 DataNode 節點
4.做 Finalize,確認集群變更到3.2

在測試環境驗證 HDFS 滾動升級方案時,升級和降級過程中都遇到了一些問題。

在滾動升級中,當 Active NameNode 為3.2版本,Standby NameNode 為2.7版本時,會出現 EditLog 不兼容問題。此時,Active NameNode 寫 EditLog 時會將 EC 相關的結構寫入到 EditLog 當中,當 Standby NameNode 讀取 EditLog 時,會出現識別不了的情況,導致 Standby NameNode 直接 Shutdown。我們的解決方案是,考慮當前有效版本是否支持 EC,如果支持 EC 則會寫入 EC 信息到 EditLog,否則不會寫入。而在升級過程中,有效版本實際上還是2.7,是不支持 EC 的,這個時候忽略 EC 即可,這樣 Standby NameNode 讀取 EditLog 做合併時,不會出現 EC 相關信息,可正常工作。解決問題的 ISSUE 為 HDFS-13596

在滾動降級中,當3.2版本的NameNode 使用3.2版本Hadoop 重啟時,如果當前最新的Fsimage 是3.2版本NameNode 產生的,則2.7版本Hadoop 重啟NameNode 會直接Shutdown,原因是,3.2版本Haodop 產生的Fsimage 文件, 2.7版本的Hadoop 無法進行加載,這將導致如果升級中遇到問題想回滾的話,無法完成回滾操作。經過深入分析,我們發現有兩個問題會導致這種情況出現。

第一個問題,Fsimage 的不兼容是由於3.2版本的 NameNode 將 EC 信息寫入到了 Fsimage 當中,2.7版本的 Hadoop 無法識別 EC 信息,導致失敗。解決方案與上麵類似,在保存 Fsimage 時考慮當前的有效版本,如果不支持 EC 則不會將 EC 信息寫入到 Fsimage 文件中。解決問題的 ISSUE 為 HDFS-14396

第二個問題,由於NameNode 對StringTable 的修改導致了Fsimage 的不兼容,目前該問題可以通過回滾commit 進行解決,社區反饋修復也不是很必要,可以通過先升級到無該commit 的版本,滾動升級穩定後,直接進行小版本升級,跨過這個不兼容特性。記錄 ISSUE 為 HDFS-14831

由於滴滴使用的是內部的用戶名密碼認證機制,社區出現的一個問題我們沒有遇到, ISSUE 為 HDFS-14509 ,升級過程中 NameNode 和 DataNode 由於數據結構的變化,生成了不同的 password,導致無法認證,讀寫數據會失敗。該 ISSUE 記錄了這個問題,需要先升級到 2.x 的最新版本進行過度,之後才能滾動升級到 3.x 版本。

總結起來,需要做 HDFS2.x 到 3.x 的滾動升級,需要關注這些 ISSUE,HDFS-13596HDFS-14396HDFS-14831HDFS-14509

4. 測試與上線

從19年初開始關注 HDFS 滾動升級,在解決遇到的已知問題之後,開發與測試不斷討論升級方案,將可能遇到的風險進行總結。

在這個過程中,我們詳細閱讀分析了滾動升級的源碼,確定升級中 NameNode,DataNode 會做哪些動作,以明確風險點。同時我們還分析了從2.7到3.2版本引入的關於 HDFS 的4000左右的 Patch ,找出可能存在兼容性問題的點,進行深入地分析。同時我們對3.2中新引入的 Feature 也進行了分析,以確保新功能對升級沒有影響。種種總結、分析、測試相關的工作,我們寫了四五十篇的 WIKI 文檔進行記錄。在測試環境中升級步驟進行了數次演練,確認沒問題之後,我們開始了升級之路。相關的具體里程碑上線過程如下:

1.19年5月左右,升級演練多次,準備全量 Hadoop、Hive、Spark Case 進行測試,確定方案沒有問題
2.19年7月左右,離線小集群1(百台)升級到3.2版本,用戶未受到影響。
3.19年10月左右,離線小集群2(數百台)升級到3.2版本,用戶未受到影響。
4.19年11月底,離線大集群(數千台)升級到3.2版本,用戶未受到影響.

升級過程中,DataNode 在刪除 Block 時,是不會真的將 Block 刪除的,而是先將Block 文件放到一個 Trash 目錄中,為了能夠使用原來的 FallBack Fsimage 恢復以前的數據。當升級週期比較長時,Trash 中的數據就會很多,例如我們這邊大集群升級週期就有3週之長。升級操作在短時間之內,是可以確定是否有問題的,並且三週之後也不可能真的回滾到以前的數據,倘若真的遇到問題,是需要及時修復的。我們開發了額外的工具,對 Trash 中的 Block 文件進行按天歸檔,設置好保留時間,例如設置1天。我們會每天例行將1天之前的數據進行刪除,這樣可以大大減少 DataNode 上磁盤的存儲壓力。

升級之後,我們對各個集群進行都進行自己觀察,目前服務一切正常。

5. 總結

非常高興在如此大規模的集群上完成從2.7到3.2的滾動升級,走在了行業的前列。 HDFS 升級過程漫長,但是收益是非常多的。在此基礎上,我們可以繼續做非常有意義的工作,持續在穩定性、性能、成本等多個方面深入探索,使用技術為公司創造可見的價值。

作者介紹

費輝

滴滴 | 大數據架構技術專家

滴滴出行大數據架構技術專家,負責離線存儲。在加入滴滴之前,曾在阿里巴巴參與過JVM和EMR產品的開發。開源大數據愛好者,積極參與社區的交流討論,Hadoop/Hive/Tez 社區貢獻者。

本文轉載自公眾號滴滴技術(ID:didi_tech)。

原文鏈接

https://mp.weixin.qq.com/s/KnP_nod_FDGzWcXeaps-8w