目前我们正在使用名为Splunk的NoSQL衍生工具来接收我们的数据。 该软件支持所谓的“search头池”，其中作业调度引擎位于几个共享公共存储点的服务器上。 本来我们的目的是使用像GFS2这样的集群文件系统，因为它具有低延迟，稳定性和易于安装的特点。 我们build立了GFS2，没有任何问题。
然而，当试图运行该软件时，它正在尝试创buildlocking文件，以及其他一些支持团队无法解释的事情。 他们的最终反馈是他们只支持NFS。
我们的networkingpipe理团队非常不满NFS（缺乏稳定性，文件locking问题等）。
所以，我正在考虑在集群中的每个服务器上设置NFS的可能性，以充当GFS2文件系统和软件之间的楔形层。 基本上configuration每个服务器通过NFS导出GFS2文件系统的挂载点，然后告诉每个服务器连接到该NFS共享。 这样，如果专用的NFS服务器出现故障，我们不会引入任何单点故障，但是供应商可以获得“必需的”NFS共享。
我只是集思广益，所以请撕开这个:)
GFS2locking的工作方式 ，通过将每个节点指向不同的NFS服务器，您可能会看到严重的性能问题：
如果另一个节点请求不能立即授予的glock，则DLM向当前持有阻塞新请求的glock的节点发送消息，要求他们放弃其locking。 滴滴涕可以是（大多数文件系统操作的标准）一个漫长的过程。 删除一个共享格洛克只需要caching失效，这是相对快速，并与caching的数据量成正比。
删除一个独占的glock需要一个日志刷新，并将任何已更改的数据写回到磁盘，然后根据共享的glock进行失效。
[…]
由于GFS2caching的实现方式，当发生以下任一情况时，获得最佳性能：
- 所有节点都以只读方式使用inode。
- inode只能从单个节点写入或修改。
另外， Red Hat的支持文档表明POSIXlockingNFS共享会导致问题 ，所以只有主动/被动集群configuration在任何给定的时间从单个活动节点导出NFS ，而不能访问GFS2文件系统除了通过NFS服务build立的一个会被支持。 显然，这应该处理NFS和GFS2之间的任何不可预见的locking交互，但可能不是你想看到的。