我正在构建一个应用程序，需要通过 WAN 在几个站点之间分发标准文件服务器。基本上，每个站点都需要写入大量大小各异的杂项文件（有些在 100 MB 范围内，但大多数都较小），并且应用程序的编写方式不会出现冲突。我希望建立一个满足以下条件的系统：
- 每个站点都可以将文件存储在共享的“命名空间”中。也就是说，所有文件都会显示在同一文件系统中。
- 除非必要，否则每个站点都不会通过 WAN 发送数据。也就是说，WAN 的每一侧都会有本地存储，这些存储将被“合并”到同一个逻辑文件系统中。
- Linux 和免费 ($$$$ 是加分项
基本上，类似中央 NFS 共享的东西可以满足大多数要求，但它不允许本地写入的数据保留在本地。来自 WAN 远端的所有数据都将始终在本地复制。
我研究过 Lustre，并对其进行了一些成功的测试，但是，它似乎在分布式存储中相当均匀地分布文件。我查阅了文档，没有发现任何会自动“优先”本地存储而不是远程存储的内容。即使是与最低延迟存储搭配使用的东西也可以。它在大多数情况下都可以工作，这将满足此应用程序的要求。
对以下一些问题的一些回答：
- 服务器节点：开始时为 2 或 3 个。每个服务器将有数十个同时连接的读/写客户端。
- WAN 拓扑是全网状且可靠的。（大型公司，成本不像繁文缛节那样限制）
- 客户端故障转移：我实际上没有想过让客户端进行故障转移（主要是因为我们当前的应用程序不会在一个站点上进行故障转移）。我认为实际的答案是，每个地理分布站点上的服务器预计会成为它们所服务的客户端的单点故障。不过，如果你在这里考虑一些具体的事情，我认为这与讨论非常相关。
- Roll-my-own：我考虑过 rsync/unison，但是我需要相当多的花哨逻辑才能使这个“动态”部分无缝工作。即，文件看起来是本地的，但只能根据需要检索。
- MS-DFS：这显然是我应该研究的问题。我的主要问题是可能不确定 Windows 上的 NFS 服务器配置/可靠性/性能，因为许多连接的客户端都是 NFS 客户端。
答案1
Linux 的要求真可惜。这正是 Windows DFS 所做的。自 2003 R2 以来，它也是在块级别上执行此操作。
答案2
一些问题：
您考虑让多少个“服务器”节点参与此事？
WAN 连接拓扑是什么样的？是中心辐射型还是全网状型？可靠性如何？
当本地服务器发生故障时，您是否希望客户端能够故障转移到地理位置不本地的服务器？
Windows DFS-R 肯定是您所寻找的，尽管可能会产生高昂的许可费用。
您说冲突不是问题，您不需要分布式锁管理器，因此您可以使用 rsync 或齐奏只需使用 NFS 将生成的文件集导出到本地客户端即可。这很丑陋，而且您必须处理某种系统来处理生成复制拓扑并实际运行用户空间工具，但就许可成本而言，这肯定很便宜。
答案3
答案4
也许是 NFS，但是缓存在应用服务器上执行此操作将实现您的目标。据我所知，所有写入的内容仍将发送到中央服务器，但至少读取操作最终可能会在本地缓存。这可能会大大减少读取延迟，具体取决于您的使用模式。
此外，也许 UnionFS 值得研究。我认为，有了它，每个位置都会是一个 NFS 导出，然后您可以在每个位置使用 UnionFS，让该位置和该位置的所有其他 NFS 挂载都显示为一个文件系统。不过，我没有这方面的经验。