作为新演出的一部分，我继承了一个10节点的Gluster集群（v 3.8.13）。我遇到的主要问题是，一个节点上的nfs-ganesha服务通常变得无响应，需要重新启动。经过调查，我找到了检查集群运行状况的途径，并且发现了很长的文件需要修复。
但是我似乎无法对不断增长的文件列表进行修复。
尝试使用gluster volume heal volx执行修复会立即产生有关禁用砖块的警告：
启动修复操作以对卷volx执行索引自修复 在倒下的砖块上失败了。请检查是否所有砖块 进程正在运行
当我检查gluster volume status时，“ volx”卷中的所有砖块都已上升，唯一可疑的是有关共享存储的消息：
未启动卷gluster_shared_storage
我确实在/ etc / fstab中看到一个用于挂载的条目：
1xx.1xx.1.xx:/gluster_shared_storage /var/run/gluster/shared_storage/ glusterfs defaults 0 0
但是在我们说的时候没有安装。
似乎有人attempted to enable shared storage，但是故意降低了音量/安装量，或者踢了水桶。我只是不想删除该卷并发现它很关键（和/或发现进行任何修复都无法帮助正常的ganesha崩溃）。这是生产系统的一部分，因此我必须在这里轻描淡写。
这两个不相关的问题吗？它只说治愈是“在倒下的砖块上不成功”，那么也许是在治愈上升的砖块？有没有办法检查？
对ganesha崩溃的任何见解也将有所帮助，但就目前而言，我将尽一切可能了解Gluster。
更新： docs seem to indicate，您需要此共享存储卷才能使用nfs-ganesha：
确保已考虑以下先决条件 在您的环境中运行NFS-Ganesha之前：...
- 创建并安装gluster共享卷。
肯定会感觉像A）我应该保留共享存储卷，B）需要根据ganesha要求启动它。我只是不想在大多数完好无损（如果未优化）的生产系统上开始翻转开关。
答案 0 :(得分：0)
作为跟Gluster发生冲突的任何勇敢灵魂的跟进，上述书籍都是虚假的，而且完全不活跃。