HDFS 配置容量高于磁盘容量

Question

我在 Centos 上有一个带有 Cloudera Express 5.11 的 11 节点集群。最初它仅由 7 个节点组成；稍后又添加了 4 个节点。每个节点的磁盘容量都相同：5.4 TB。

我遇到的问题是hdfs dfsadmin -report 命令显示错误的磁盘使用值，尤其是对于配置容量。我的值是前 7 个节点中的 6.34 TB 和后 4 个节点中的 21.39 TB。

例如，在一个节点中，我有以下报告：

Decommission Status : Normal
Configured Capacity: 23515321991168 (21.39 TB)
DFS Used: 4362808995840 (3.97 TB)
Non DFS Used: 14117607018496 (12.84 TB)
DFS Remaining: 3838187159552 (3.49 TB)
DFS Used%: 18.55%
DFS Remaining%: 16.32%
Configured Cache Capacity: 2465202176 (2.30 GB)
Cache Used: 0 (0 B)
Cache Remaining: 2465202176 (2.30 GB)
Cache Used%: 0.00%
Cache Remaining%: 100.00%

在dfs.data.dir 文件夹上运行df 命令向我显示DFS Used 值（不是百分比）是正确的，但其他值是正确的。我读过 HDFS 可能显示的值可能不是最新的，但我已经看到相同的值几天了，即使在重新启动所有服务和所有机器之后也是如此。

最让我烦恼的是：

1. 配置的容量远高于真实容量（我只有 5 TB，它怎么能推断出 21 TB？）
2. 我对两组节点分别有两个不同的值

这些值的原因可能是什么？有没有办法修复它们？

PS：我问这个的原因是，使用错误的值，HDFS 低估了DFS Used%，因此无法重新平衡节点中的文件。事实上，我发布值的节点有：

• DFS Used：~4 TB（正确）
• DFS Used%：~19%（错误）

每个其他节点都有：

• DFS Used：~2 TB（正确）
• DFS Used%：从 11% 到 28%（错误）

这使得被指控节点的DFS Used%低于平均值，因此HDFS的平衡器推断该节点不应该重新平衡。

PS2：我注意到的一件事是第一组节点有 Centos 6.9，而第二组节点有 Centos 6.8。这会以某种方式导致问题吗？

Answer 1

更新

一年半之后，我找到了问题的真正根源。

原因是我在 HDFS 的dfs.datanode.data.dir 参数中列出了几个目录。显然，HDFS 通过汇总每个目录的容量来估计配置的容量。问题是：如果两个目录在同一个分区，那个分区的大小会被考虑两倍！奇怪的是，我在文档中没有发现任何提及这一点。

这给我带来了问题，因为在第一组机器中有 4 个 HDFS 目录分配给 3 个约 1.8T 的分区（因此只有一个被考虑两次），而第二组有 4 个 HDFS 目录分配给 1 ~5.4TB 的分区（因此乘以 4！）。

归根结底，问题在于机器的异构分区配置 + HDFS 的一些低级细节没有正确记录。

我最终在 Cloudera 中创建了两组 HDFS 目录配置：一组用于第一组机器（有 3 个目录，每个分区一个），另一组用于第二组（一个目录在唯一的分区中）。由于涉及数据重新平衡，请谨慎操作此操作。

原答案

这些值的原因可能是什么？

经过一些研究，似乎这个问题发生在集群使用新资源（即新磁盘或新节点）更新时，因为 HDFS 用所有相关 Datanodes 的总容量更新了相关 Datanodes 的 Configured Capacity （即我们升级前 7 个节点的磁盘时，每个节点的容量成为集群的总容量；当我们再增加 4 个节点时，每个新节点的容量成为新节点的总容量）。这可能是由于 Cloudera Manager 造成的吗？可能（这是我的猜测），但我没有证据。

有没有办法修复它们？

我已经阅读了 Hadoop 的 Java 代码以了解节点的配置容量的值是从哪里获取的，并且它似乎来自 Namenode 的命名空间图像（这是一个二进制文件，AFAIK，它是不可编辑的） .

我最终做的是停用不平衡的节点（这会触发其块在其余节点上的复制），删除此类节点上的 HDFS 数据，重新调试它并重新平衡数据。这不是我正在寻找的解决方案，但至少它使我的数据正确地重新平衡了。