linux – 确定GlusterFS数据损坏的原因

发布时间：2020-12-14 02:55:51 所属栏目：Linux 来源：网络整理

导读：将数据写入我在两台服务器上配置的复制GlusterFS卷时,我一直遇到数据损坏. 我设置的配置如下：服务器正在运行Ubuntu 16.04和GlusterFS v3.10.6 客户端正在运行Ubuntu 14.04和GlusterFS v3.10.6 已经配置了GlusterFS中的两个卷,每个卷都有两个砖块,每个服务

将数据写入我在两台服务器上配置的复制GlusterFS卷时,我一直遇到数据损坏.

我设置的配置如下：

>服务器正在运行Ubuntu 16.04和GlusterFS v3.10.6
>客户端正在运行Ubuntu 14.04和GlusterFS v3.10.6
>已经配置了GlusterFS中的两个卷,每个卷都有两个砖块,每个服务器上都有一块砖块.
>每块砖都是带有EXT4 / LUKS文件系统的MDADM RAID5阵列.
>每个卷都配置了默认选项和bitrot检测.这些如下：

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

当大型目录从其中一台客户端计算机上的本地文件系统复制到任一配置的GlusterFS卷时,数据损坏表明它是自我的.当为复制的文件和源文件计算md5校验和并且比较两者时,许多校验和不同.

在GlusterFS卷上手动触发自我修复显示没有确定要进行修复的文件.另外,查看gluster卷的输出bitrot< volname>擦除状态和/var/log/glusterfs/bitd.log和/var/log/glusterfs/scrub.log中的输出日志似乎没有识别任何错误.

这些问题最近才显现出来,最近大约一周后这两个卷被大约10个客户大量使用.

我已经尝试使卷脱机并且已经测试了直接通过底层本地文件系统将数据写入每个块,并且无法重现这些问题.

为了进一步调试该问题,我在VirtualBox中的VM上配置了类似的设置,但无法重现该问题.因此,我对这些错误的原因造成了相当大的损失.

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

解决方法

在无法使GlusterFS正常运行之后,我决定将我的设置移动到NFS,每小时左右同步一个主控主机和镜像,以便在主服务器发生故障时提供一定程度的故障转移.

最近我们在提供镜像的服务器上执行维护,结果发现我们在该服务器上的NFS上存在类似的数据损坏问题.

在对可能的损坏原因进行大量调试后,我们最终将其跟踪到硬件卸载到网络接口,之后我发现我们偶尔也会通过SSH获得断开连接：数据包损坏错误.

查看SSH错误的可能原因,我发现以下Unix& Linux问题：packet_write_wait Broken pipe even leaving top running?

关于此线程的一些讨论表明,当分段和rx / tx校验和传递给接口时,错误的网络接口驱动程序可能会导致数据包损坏.

在禁用rx / tx和分段卸载(遵循以下博客文章中的说明：How to solve ssh disconnect packet corrupt problems)并在网络负载较重的情况下测试服务器后,我发现SSH上的SSH错误和数据损坏消失了.

由于我不再在服务器上配置GlusterFS,因此我无法验证这是否是我们遇到的数据损坏的原因.但是,考虑到我们迁移到NFS之后其中一个服务器上存在问题,很可能这可能是导致我们出现问题的原因.

另外,网络接口驱动程序正在使用e1000e驱动程序.随后我在RHEL错误跟踪器上找到了以下讨论：Bug 504811 – e1000 silently corrupting data这表明由于硬件卸载到网络接口(例如使用e1000e驱动程序的某些卡)而导致数据包损坏.

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!