当前位置：首页 > 文章列表 > 数据库 > MySQL > 怎么做 HDFS 的原地平滑缩容？

怎么做 HDFS 的原地平滑缩容？

来源：SegmentFault 2023-02-16 15:36:29 0浏览收藏

亲爱的编程学习爱好者，如果你点开了这篇文章，说明你对《怎么做 HDFS 的原地平滑缩容？》很感兴趣。本篇文章就来给大家详细解析一下，主要介绍一下容器、MySQL、数据库、运维，希望所有认真读完的童鞋们，都有实质性的提高。

背景

当数据规模越来越大，存储成本也水涨船高。随着时间推移，数据热度分布往往呈 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 删除掉。