我一直在努力让越来越多的服务摆脱对 NFS 的依赖，我想知道其他人是如何解决这个问题的。我知道有分布式文件系统，我有使用其中一种文件系统的经验 (mogilefs)。我很好奇其他人是如何摆脱 NFS 的，尤其是在用户上传内容方面。具体来说，在 Web 领域，假设用户将内容上传到特定的 Web 服务器——您会怎么做才能让这些内容在您的集群中可用？我考虑过将 rsync 同步到集群中的其他机器，或者只是同步到单个内容服务器，但我很好奇其他人是如何解决这个问题的。
答案1
在花了一年时间尝试（但失败了）让 GFS 以任何合理的方式运行之后，我远离了任何类型的集群文件系统。它非常复杂，在负载下性能一文不值。这种评估延伸到我研究过的所有其他集群文件系统——移动部件的数量、缺乏有效的文档以及整个 Rube Goldberg 装置的普遍脆弱性让我的每一部分都发出“哎呀！”的感叹。
另一方面，我通过使用更高级别的、特定于应用程序的抽象取得了巨大的成功——思考应用程序具体是什么需求处理所涉及的数据，然后提供一种方法来做到这一点。Web 应用程序中的数据实际上很少需求对应用程序中的数据进行完整的 POSIX 文件系统抽象；相反，它可以使用一些更具功能性的动词。 那是您的 Web 层和数据之间的访问层。
以图像为例。如果您有图像，您可能目前将它们推送到 NFS 服务器上，然后 Web 服务器将它们拉出并根据需要进行操作。但您实际上对它们做了什么？它们每个都由一个唯一键标识，您可以存储它们（PUT 请求）、检索它们（GET 请求）、删除它们（DELETE 请求），并且可能以不同的大小获取它们（带有几个参数的 GET 请求）——瞧，有一个 REST API 可以做到这一点。不喜欢 REST？SOAP、XML-RPC，无论您喜欢什么。见鬼，您甚至不必使用 HTTP（尽管它是 Web 应用程序的自然选择，因为您的 GET 请求可以直接发送到文件服务器）。您可能执行的任何调整大小的方法（以及这些调整大小的缓存）都可以在存储服务器上处理，这可以节省网络带宽，本地化处理它们所涉及的逻辑，并使存储的图像接近处理它们的处理能力（更近 == 更快 == 很棒）。
扩展这些存储系统通常也比扩展通用文件服务器更容易。它们不需要快速扩展，因为它们效率更高，但当它们需要扩展时，只需确定分片算法并在几个关键位置实现它即可。我喜欢这种简单的方法，即确定单个服务器可以支持多少个（例如）图像，然后使用它来id / capacity获取用于任何给定图像请求的服务器数量。
这不是我第一次写这个答案；请参阅这个问题对这个问题有稍微不同的看法。
答案2
数据库（传统 SQL 或 NoSQL，如MongoDB) 是解决此问题的常见方法。
将需要共享的内容存储在数据库中，然后从前端 Web 服务器检索。
另一个相当常见的解决方案是具有共享访问的 SAN。
虽然我不是 NFS 的粉丝，但我会说，如果它对你有用，设计和实现得好，而且相对没有问题，你可能可以继续使用它几乎无限期。远离它是很好的，但如果除了“哎呀，它太NFS“！”不要为了摆脱它而自杀……
答案3
如果您正在寻找集群文件系统，有很多开放/封闭的解决方案可供选择。仅举几个例子：政府金融服务局，光泽，集群文件系统，OCFS2，Veritas 集群文件系统最后一个是商业企业FS，但是从经验上来说是最好的一个。
编辑：忘记提到，所有这些都应该抵抗所有群集节点共享的 SAN 设备。这也是 Veritas CFS 的要求。