☰

确定 GlusterFS 数据损坏的原因

tag-icon • tag-icon linux ubuntu network-share glusterfs
确定 GlusterFS 数据损坏的原因

我在将数据写入我在两台服务器上配置的复制 GlusterFS 卷时遇到了数据损坏问题。

我设置的配置如下：

  • 服务器运行的是 Ubuntu 16.04 和 GlusterFS v3.10.6
  • 客户端运行的是 Ubuntu 14.04 和 GlusterFS v3.10.6
  • GlusterFS 中配置了两个卷，每个卷有两块砖，每台服务器分布一块砖。
  • 每个砖块都是一个带有 EXT4/LUKS 文件系统的 MDADM RAID5 阵列。

  • 每个卷都配置了默认选项，以及位腐烂检测。具体如下：

    features.scrub: Active
features.bitrot: on
features.inode-quota: on
features.quota: on
nfs.disable: on

当大型目录从客户端计算机的本地文件系统复制到配置的 GlusterFS 卷之一时，数据损坏就会显现出来。当计算复制文件和源文件的 md5 校验和并将两者进行比较时，许多校验和不同。

在任一 GlusterFS 卷上手动触发自我修复均未显示任何需要修复的文件。此外，查看输出gluster volume bitrot <volname> scrub status和输出日志/var/log/glusterfs/bitd.log，似乎/var/log/glusterfs/scrub.log未发现任何错误。

这些问题最近才显现出来，大约在这两个卷被约 10 个客户端大量使用约一周之后。

我尝试将卷脱机，并测试通过底层本地文件系统直接将数据写入每个块，但无法重现问题。

为了进一步调试该问题，我在 VirtualBox 中的虚拟机上配置了类似的设置，但无法重现该问题。因此，我完全不知道这些错误的原因是什么。

对于我可以采取的进一步调试步骤的任何建议或有关 GlusterFS 和我的配置的已知问题，我将不胜感激。

答案1

在无法使 GlusterFS 正常运行后，我决定将我的设置移至 NFS，并使用实时主服务器和镜像服务器每小时左右同步一次，以便在主服务器发生故障时提供一定程度的故障转移。

最近，我们正在对提供镜像的服务器进行维护，结果发现该服务器上的 NFS 数据损坏也存在类似的问题。

在对可能导致损坏的原因进行大量调试之后，我们最终将其追溯到硬件卸载到网络接口，因为我注意到我们偶尔也会在Disconnecting: Packet corrupt通过 SSH 传输大数据包时遇到错误。

研究 SSH 错误的可能原因时，我发现以下 Unix 和 Linux 问题：packet_write_wait 管道破裂甚至使顶部继续运行？

该线程中的部分讨论表明，当分段和 rx/tx 校验和传递到接口时，有缺陷的网络接口驱动程序可能会导致数据包损坏。

禁用 rx/tx 和分段卸载后（按照以下博客文章中的说明进行操作：如何解决 ssh 断开连接数据包损坏问题) 并在高网络负载下测试服务器，我发现 SSH 错误和 NFS 上的数据损坏消失了。

由于我不再在服务器上配置 GlusterFS，因此我无法验证这是我们遇到的数据损坏的原因。但是，考虑到我们转移到 NFS 后其中一台服务器上的问题仍然存在，这很可能就是导致我们遇到问题的原因。

顺便提一下，网络接口驱动程序正在使用该e1000e驱动程序。随后，我在 RHEL 错误跟踪器上发现了以下讨论：Bug 504811 - e1000 悄悄破坏数据这表明由于硬件卸载到网络接口（例如使用该e1000e驱动程序的某些卡），可能会导致数据包损坏。

答案2

如果 Gluster 说没有损坏，则您的卷上可能没有任何可检测到的损坏。但是，根据您的描述，这些 gluster 卷上没有超过 1 个的数据副本。如果没有多个副本（理想情况下是三个完整的副本或 2n+a），我们无法确定节点是否损坏了其数据，因为它没有其他副本可以与之比较。

解决此问题的一种方法是启用 b​​itrot 检测守护程序，默认情况下该守护程序处于禁用状态。这将允许使用文件校验和进行数据清理。可以使用 来完成此操作gluster volume bitrot VOLNAME enable。检测到的错误记录在 /var/log/glusterfs/bitd.log 和 /var/log/glusterfs/scrub.log 中

这些都不能解释飞行途中的腐败现象。

如果以上内容均未找到任何内容，您可以检查客户端本身，以及来自客户端和服务器的任何相关日志。您可能还需要沿着这条路径测试您的网络、客户端或服务器硬件，以确定这种损坏究竟发生在哪里。希望您不必走那么远。

相关内容