主页 / server / 问题 / 425960
Accepted
Matthew
Asked: 2012-09-11 05:11:24 +0800 CST

GFS2 之上的 NFS - 它有效吗？

  • 772

我们目前正在使用名为 Splunk 的 NoSQL 衍生产品来接收我们的数据。该软件支持称为“搜索头池”的东西，其中作业调度引擎位于共享公共存储点的多个服务器上。最初我们的意图是使用像 GFS2 这样的集群文件系统，因为它具有低延迟、稳定性和易于设置的特点。我们设置了 GFS2，它没有任何问题。

然而，当试图运行该软件时，它会尝试创建锁定文件，以及他们的支持团队无法完全解释的一堆其他事情。他们的最终反馈是他们只支持 NFS。

我们的网络管理团队非常反对 NFS（缺乏稳定性、文件锁定问题等）。

因此，我在考虑在集群中的每台服务器上设置 NFS 以充当 GFS2 文件系统和软件之间的楔形层的可能性。基本上将每台服务器配置为通过 NFS 导出 GFS2 文件系统的挂载点，然后告诉每台服务器连接到该 NFS 共享。这样我们就不会在专用 NFS 服务器出现故障时引入任何单点故障，但供应商会获得他们“所需的”NFS 份额。

我只是在集思广益，所以请把它拆开:)

nfs

1 个回答

  1. Best Answer

    GFS2 锁定的工作方式，通过将每个节点指向不同的 NFS 服务器，您可能会看到严重的性能问题：

    如果另一个节点请求不能立即授予的 glock，则 DLM 会向当前持有 glock 的一个或多个节点发送一条消息来阻止新请求，要求它们放弃锁。删除 glocks 可能是（按照大多数文件系统操作的标准）一个漫长的过程。删除共享 glock 只需要使缓存失效，这相对较快并且与缓存数据量成正比。

    删除独占 glock 需要刷新日志，并将任何更改的数据写回磁盘，然后根据共享 glock 进行失效。

    [...]

    由于 GFS2 缓存的实现方式，当发生以下任一情况时可以获得最佳性能：

    • inode 在所有节点上以只读方式使用。
    • 仅从单个节点写入或修改 inode。

    此外，来自 Red Hat 的支持文档指出 NFS 共享上的 POSIX 锁会引发问题，因此只有在任何给定时间从单个活动节点导出 NFS并且没有文件访问 GFS2 文件系统的主动/被动集群配置是执行除了通过 NFS 服务设置的将被支持。显然，这应该会处理 NFS 和 GFS2 之间任何类型的不可预见的锁定交互，但这可能不是您希望看到的。

    • 2

相关问题