怎麼做 HDFS 的原地平滑縮容？

JuiceFS發表於2022-03-15

背景

當資料規模越來越大，儲存成本也水漲船高。隨著時間推移，資料熱度分佈往往呈 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 也需要按照以下步驟執行（可以適當並行）：

  1. 選擇磁碟。選擇需要被解除安裝的資料盤和接收資料的資料盤，注意要確保接收資料的磁碟剩餘空間夠大於被解除安裝磁碟上的資料。這裡假設：

被解除安裝磁碟：/dfs1，此磁碟上的 DataNode 資料目錄：/dfs1/dfs/dn

資料接收盤：/dfs，此磁碟上的 DataNode 資料目錄：/dfs/dfs/dn

  1. 第一次複製資料。從 dfs.data.dir 裡面挑選出在被解除安裝磁碟上面的目錄，然後將此目錄全量拷貝到接收資料盤上，為了儘量減少對 IO 的佔用，用 ionice 加 rsync 的方式拷貝資料，確保不阻塞高優先順序的任務。
ionice -c 2 -n 7 rsync -au /dfs1/dfs/dn/ /dfs/shrink_temp/dn

  1. 需要保證資料都被拷貝過去了，所以需要將 DataNode 停掉。可以通過 ClouderaManager 介面關閉 DataNode。

  2. 第二次增量複製資料。重複步驟 2，將在步驟 2 和步驟 3 之間的新增資料增量更新到接收盤上。增量資料會比較少，估計能很快完成。

ionice -c 2 -n 7 rsync -au /dfs1/dfs/dn/ /dfs/shrink_temp/dn
  1. 合併目錄。此時被解除安裝盤上的資料都已經複製到接收盤上，但是資料還在原來的資料夾裡面。如果同一塊磁碟上面有兩個 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

  1. 通過 ClouderaManager 修改 dfs.data.dir 配置項，刪除解除安裝磁碟上的資料目錄。

  2. 通過 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✿)

相關文章