我们目前使用名为 Splunk 的 NoSQL 衍生产品来接收数据。该软件支持所谓的“搜索头池”，其中作业调度引擎位于共享一个公共存储点的多个服务器上。最初我们打算使用像 GFS2 这样的集群文件系统，因为它具有低延迟、稳定性和易于设置的特点。我们设置了 GFS2，它运行起来没有任何问题。
但是，当尝试运行该软件时，它会尝试创建锁定文件，以及他们的支持团队无法解释的许多其他事情。他们给出的最终反馈是他们仅支持 NFS。
我们的网络管理团队非常反对 NFS（缺乏稳定性、文件锁问题等）。
因此，我考虑在集群中的每台服务器上设置 NFS，作为 GFS2 文件系统和软件之间的楔层。基本上，配置每台服务器通过 NFS 导出 GFS2 文件系统的挂载点，然后告诉每台服务器连接到该 NFS 共享。这样，如果专用 NFS 服务器发生故障，我们就不会引入任何单点故障，但供应商会获得其“所需的”NFS 共享。
我只是在集思广益，所以请把它撕开:)
答案1
这GFS2 锁定的工作方式，通过将每个节点指向不同的 NFS 服务器，您可能会看到严重的性能问题：
如果另一个节点请求无法立即授予的 glock，则 DLM 会向当前持有阻止新请求的 glock 的节点发送消息，要求它们放弃锁定。放弃 glock 可能是一个漫长的过程（以大多数文件系统操作的标准来看）。放弃共享 glock 仅要求使缓存失效，这相对较快，并且与缓存数据量成正比。
删除独占 glock 需要刷新日志，并将任何更改的数据写回到磁盘，然后按照共享 glock 进行失效处理。
[...]
由于 GFS2 缓存的实施方式，当发生以下任一情况时均可获得最佳性能：
- 所有节点都以只读方式使用 inode。
- 一个 inode 只能从单个节点写入或修改。
此外，与 Red Hat 的支持文档类似表明 NFS 共享上的 POSIX 锁将引发问题，因此只有主动/被动集群配置，其中 NFS 是从任何给定时间的单个活动节点并且除了通过 NFS 服务设置的访问之外，不执行对 GFS2 文件系统的任何文件访问。显然，这应该可以处理 NFS 和 GFS2 之间任何类型的不可预见的锁定交互，但这可能不是您想要看到的。