背景
當資料規模越來越大，存盤成本也水漲船高，隨著時間推移，資料熱度分布往往呈 2?8 原則，即 80% 的訪問集中在 20% 的資料上，對于那不經常訪問的 80% 資料來說，使用多個 SSD 來存盤真是巨大的浪費，需要將冷資料遷移到其他存盤成本更低的系統里，這時 JuiceFS 成了理想之選，成本下降 20 倍，同時又提供跟 HDFS 一樣高性能的元資料能力（避免Metastore 遍歷元資料時雪崩），大量掃描冷資料時也有很高的吞吐量，如果 80% 的資料轉移到 JuiceFS 上來，整體成本可節省 90%，如果再給 JuiceFS 提供 適當的空間做快取，還可以完整替換 HDFS (20% 的熱資料通過 JuiceFS 管理的快取盤來服務，也可以有極高的性能），
2019 年里，我們就實施過幾個這樣的案例，當資料遷移到 JuiceFS 上之后，HDFS 容量降下來了，就需要做好縮容才能最終把存盤成本降下來，擴容大家都做過，但是縮容很多人還不熟悉，下面我們就詳細說說如何做好 HDFS 縮容，尤其是這個背景下的縮容，
三種縮容方案
第一種縮容方法，如果 DataNode 的節點數目比較多，并且允許縮減存盤空間的同時縮減 CPU 和記憶體資源，則可以縮掉若干個 DataNode 節點，直接使用 HDFS 提供的 decommission，這是最常見的方法，縮減程序中涉及大量資料的跨節點遷移，會產生大量的內網流量可能影響線上負載，需要運維人員保持密切關注和手動調優，通常需要一兩周的時間，如果集群只剩 3 個 DataNode 節點，或者上面的 CPU 或者 記憶體資源不能同步縮減時，就不能用這個方法了，
第二種縮容方法，即在保持 DataNode 節點數不變的情況下，縮減每個節點上的磁盤空間，可以修改 DataNode 上的 dfs.data.dir引數，刪掉一個或者多個磁盤目錄，然后等待 HDFS 自動補充副本，這個方法統一也會導致節點間的大量資料移動，會產生大量的內網流量可能影響線上負載，需要運維人員保持密切關注和手動調優，可能也需要一兩周時間，此外，如果資料只有 2 副本，相對會比較危險，一旦洗掉一個磁盤目錄時正好有節點出問題或者某塊磁盤壞掉，極有可能造成資料缺失，
以上兩種方法都會產生大量網路流量，可能影響線上服務，并且會增加丟失資料的風險，本文提供第三種方法，怎么在縮容的同時，盡量避免產生的內網流量影響線上作業負載，同時盡量減少縮容程序中資料丟失的風險，
方案分析
首先我們看一下 DataNode 在磁盤上的目錄結構：
└── dn
├── current
│ ├── BP-847673977-192.168.0.120-1559552771699
│ │ ├── current
│ │ │ ├── dfsUsed
│ │ │ ├── finalized
│ │ │ │ ├── subdir0
│ │ │ │ │ ├── subdir1
│ │ │ │ │ │ ├── blk_1073742303
│ │ │ │ │ │ ├── blk_1073742303_1479.meta
│ │ │ ├── rbw
│ │ │ └── VERSION
│ │ ├── scanner.cursor
│ │ └── tmp
│ └── VERSION
└── in_use.lock
BP-847673977-192.168.0.120-1559552771699：這是塊池目錄，如果以 Federation 方式部署的時候，會有多個塊池目錄，dfsUsed：保存的是磁盤的使用統計資料，每 10 分鐘重繪一次，finalized和 rbw 目錄：這兩個都是用于存盤資料塊的，finalized 放的是已經完成寫入的資料塊，rbw 是正在寫入的資料塊，每個資料塊對應 2 個檔案，blk 檔案存放資料，另外一個以 meta 結尾的存放校驗和等元資料，VERSION檔案：主要包含布局版本、集群 ID、DataNode ID、塊池 ID 等資訊，scanner.cursor檔案：DataNode 會定期的對每個blk檔案做校驗，這個檔案是用來記錄校驗到哪個位置的，- 不難看出所有的資料檔案都存在
finalized和rbw里面，并且同一個DataNode上面不會存在相同 Block ID 的資料檔案，因此完全可以通過遷移 blk 檔案的方式來將一塊磁盤上面的資料移動到另外一塊磁盤上，然后在卸載此磁盤來達到縮容的目的，
縮容步驟
本文示例的 HDFS 是 CDH 5.16 版本，使用 ClouderaManager 管理集群，集群只有 3 個節點，每個節點有多塊 SSD 盤，資料兩副本，存盤利用率很低，每個節點都可以卸載掉一塊磁盤，但是無法使用前面兩種常見的縮容方法，同時縮容程序要盡可能可能減小對線上服務的影響，
以下操作均是針對單一 DataNode 的操作，其他 DataNode 也需要按照以下步驟執行（可以適當并行）：
- 選擇磁盤，選擇需要被卸載的資料盤和接收資料的資料盤，注意要確保接收資料的磁盤剩余空間夠大于被卸載磁盤上的資料，這里假設：
被卸載磁盤：/dfs1，此磁盤上的 DataNode 資料目錄：/dfs1/dfs/dn
資料接收盤：/dfs，此磁盤上的 DataNode 資料目錄：/dfs/dfs/dn
- 第一次復制資料，從
dfs.data.dir里面挑選出在被卸載磁盤上面的目錄，然后將此目錄全量拷貝到接收資料盤上，為了盡量減少對 IO 的占用，用ionice加rsync的方式拷貝資料，確保不阻塞高優先級的任務，
ionice -c 2 -n 7 rsync -au /dfs1/dfs/dn/ /dfs/shrink_temp/dn
-
需要保證資料都被拷貝過去了，所以需要將 DataNode 停掉，可以通過 ClouderaManager 界面關閉 DataNode，
-
第二次增量復制資料，重復步驟 2，將在步驟 2 和步驟 3 之間的新增資料增量更新到接收盤上，增量資料會比較少，估計能很快完成，
ionice -c 2 -n 7 rsync -au /dfs1/dfs/dn/ /dfs/shrink_temp/dn
- 合并目錄，此時被卸載盤上的資料都已經復制到接收盤上，但是資料還在原來的檔案夾里面，如果同一塊磁盤上面有兩個 DataNode 資料目錄的話，會導致 HDFS 容量計算重復，因此需要合并，可以通過 rsync 的硬鏈的方式將資料拷貝過去，這樣不涉及真正的資料拷貝，執行非常快，同時將拷貝過去的源資料洗掉，檢查剩余資料是否有 blk 檔案，沒有就合并完成，
ionice -c 2 -n 7 rsync -au --link-dest=/dfs/shrink_temp/dn --ignore-existing --remove-source-files /dfs/shrink_temp/dn/ /dfs/dfs/dn
-
通過 ClouderaManager 修改 dfs.data.dir 配置項，洗掉卸載磁盤上的資料目錄，
-
通過 ClouderaManager 啟動 DataNode，并檢查 HDFS 的狀態，
sudo -u hdfs hdfs fsck /
為什么不直接將被卸載盤的資料復制合并到接收盤的 DataNode 資料目錄里面呢？ 這是因為，在第一次拷貝的時候，DataNode 仍然在運行，因此 DataNode 會定期檢查副本數量，此時拷貝過去的資料算是額外副本，有可能會被 DataNode 洗掉掉，
整個縮容程序中 DataNode 停止的時間只是步驟 4 和步驟 5 所需時間，步驟 4 是增量拷貝，速度很快，步驟 5 只是檔案元資料操作，同樣很快，
以上步驟看起來比較多，手動操作會容易出錯，因此我們將以上縮容程序寫了一個腳本（部分操作依賴 Hadoop 發行版的 API，目前支持 CDH5），請下載setup-hadoop.py，運行命令，并按照提示輸入進行縮容：
python setup-hadoop.py shrink_datanode
未來改進
在上面的縮容程序里，需要將資料是從一塊磁盤完整地拷貝到另外一塊磁盤，需要它有足夠的剩余空間，另外也可能導致 DataNode 內磁盤間資料不均衡，未來可以改進下這個縮容程序，在復制資料時根據某個規則將 blk 檔案復制到多塊盤，確保多塊磁盤之間的資料均衡，
如有幫助的話歡迎關注我們專案 Juicedata/JuiceFS 喲！ (0?0?)
轉載請註明出處，本文鏈接：https://www.uj5u.com/shujuku/444456.html
標籤：其他