基本上，我正在寻找“多路径 nfs”。我想要一个经典的网络文件系统，但客户端上安装有多个服务器到单个安装点，并且它应该能够处理服务器故障，并在服务器之间进行透明的故障转移，而不会出现任何延迟。负载平衡和性能不是问题。服务器之间的同步可以在此解决方案之外完成，甚至可以通过此接口对普通客户端进行只读。
我倾向于避免使用 GFS、Lustre、AFS、IP 循环以及类似的“复杂”事物。
您知道这个问题的简单解决办法吗？
答案1
编辑：我刚看到你想避免使用 Lustre。GlusterFS（对我而言）不在同一空间，因为它不需要对内核进行任何调整。它纯粹是用户空间。
GlusterFS 就是这样做的。它是一个用户空间实现，因此速度稍慢。但我个人认为，大多数网络文件系统的瓶颈都是网络。
抛开个人问题不谈：
使用 GlusterFS 集群挂载任何节点。如果此节点随后发生故障，客户端实现会足够智能地检测到该情况并继续与集群中的另一个节点合作。
我不太确定 POSIX 兼容性，所以您可能不想从那里运行 PostgreSQL/MySQL/Oracle。但从 GlusterFS 提供静态文件完全没问题。请注意：提供静态文件并不一定意味着它必须是 Web 服务器。:)
答案2
诀窍是让客户支持这种非标准操作。也就是说，你可以让服务器高可用性。将两个 NFS 服务器放在 Heartbeat 集群中，您至少可以实现故障转移，尽管锁定不会转移。您将拥有一些当集群发现所有问题并启动故障转移时，就会产生停机时间，但它应该非常快；远低于 30 秒。
答案3
您所询问的问题通常正是存储区域网络 (SAN) 旨在解决的问题。
答案4
老实说，你不会找到一个“简单”的解决方案，因为这不是一个“简单”的问题。话虽如此，为了稳健性和简单性，我发现最不坏的选择是 NFS over DRBD。它仍然不简单，但它比 GFS/OCFS2/Lustre 好得多。假设你已经在 SAN 上拥有了相当于 DRBD 的东西（假设你想使用它），如果你想要故障转移，NFS+heartbeat 才是你最终的选择。