地理位置优先的地理分布式文件系统

我正在构build一个需要通过广域网在几个站点上分发标准文件服务器的应用程序。基本上，每个站点都需要编写大量不同大小的misc文件（一些在100 MB的范围内，但是最小的），并且应用程序被编写成碰撞不成问题。我想build立一个符合以下资格的系统：

基本上，像一个中央NFS共享将满足大部分要求，但它不会允许本地写入的数据保持本地。来自广域网远端的所有数据将始终在本地复制。

我已经看过Lustre，并且已经对它进行了一些成功的testing，但是，它似乎在整个分布式存储中均匀分布文件。我已经通过文档挖掘，并没有发现任何东西会自动“偏好”远程存储本地存储。即使是延迟最低的存储也是可以的。它大部分时间都可以工作，可以满足这个应用程序的要求。

以下是一些问题的答案：

服务器节点：2或3启动。每个服务器将有数十个同时读/写客户端连接。
广域网拓扑结构完整，可靠。（大公司，成本不如繁文</s>节）
客户端故障切换：我实际上并没有想过客户端故障切换（主要是因为我们目前的应用不在一个站点上这样做）。我认为实际的答案是，每个地理位置分散的站点上的服务器预计会成为他们正在服务的客户端的单点故障。不过，如果你在想这个问题，我想这个讨论会很有意义。
Roll-my-own：我曾经想过rsync / unison，但是我需要相当多的花式逻辑才能使这个工作的“dynamic”部分无缝地进行。也就是说，文件似乎是本地的，但只能根据需要检索。
MS-DFS：这当然似乎是我应该看的东西。我的主要问题可能是不确定在Windows上的NFS服务器configuration/可靠性/性能，因为许多连接的客户端是NFS客户端。

惭愧Linux的要求。这正是Windows DFS所做的。自2003 R2以来，它也在块级别上进行。

一些问题：

Windows DFS-R肯定会是你要找的东西，尽pipe有一些潜在的巨额授权费用。

你说碰撞不是问题，你不需要一个分布式的锁pipe理器，所以你可以用rsync或Unison这样的用户级工具来完成这个工作，只需要用NFS将导出的文件文件导出到本地客户端即可。这很丑陋，你必须处理一些类似的系统来处理生成复制拓扑和实际运行用户级工具，但是随着许可成本的降低，它肯定会便宜。

你考虑过AFS吗？

安德鲁文件系统（AFS）是一个分布式networking文件系统，它使用一组可信赖的服务器为所有客户端工作站提供一个同质，位置透明的文件名空间。

据我了解，最近的发展大部分是OpenAFS项目的背后。

我不能假装对项目有足够的了解，以了解“首选地点”function是否可用，但是否则听起来像是一个很好的select。

你看过Lustre的OST池吗？

它不会自动执行，但通过OST池，您可以将目录/文件分配给特定的OST / OSS – 基本上是基于策略的存储分配，而不是跨OST的默认循环/分段。

因此，您可以为每个站点设置一个目录，并将该目录分配给该站点的本地OST，从而将所有I / O指向本地OST。它仍然是一个全局的命名空间。

通过广域网连接（本地caching服务器等等）来改进Lustre工作还有很多工作要做，但是这一切都还处于重大的发展阶段。

也许在应用程序服务器上使用NFS，但使用Cachefs将完成你的目标。据我了解，所有写入的内容都将保留在中央服务器上，但至less读取内容可能会被本地caching。根据您的使用模式，这可能会延迟很长时间。

此外，mabye UnionFS值得关注。有了这个，我认为每个位置都是一个NFS导出，然后你可以在每个位置使用UnionFS来获得该位置的所有其他NFS挂载，并将其显示为一个文件系统。我没有这方面的经验。

您可以查看DRBD来复制磁盘。 http://www.drbd.org/ 。这是一个linux高可用性解决scheme，现在它已经进入了内核。

但是，这有一些限制：

如果你想保持简单，那么看看rsync，解决了很多问题，并可以脚本。

检查chironfs 。

也许它可以做到你想要的，在文件系统的基础上。

Btsync是我有很好的经验的另一个解决scheme。它使用BitTorrent协议传输文件，所以更多的服务器有更快的同步新文件。

与基于rsync的解决scheme不同，它会检测您何时重命名文件/文件夹，并在所有节点上重命名它们而不是删除/复制。

yout btsync客户端可以共享本地networking上的文件夹。

我发现唯一的缺点（与MS DFS相比）是它不会检测本地文件副本。相反，它会将其解释为上传到所有同行的新文件。

到目前为止，btsync似乎是最好的同步解决scheme，它可以安装在Windows，Linux，Android和ARM设备（如NAS）