具有首选位置的地理分布式文件系统

我正在构建一个需要通过WAN在几个站点之间分发标准文件服务器的应用程序。基本上，每个站点都需要编写许多大小不一的杂项文件（有些大小在100s MB范围内，但大多数很小），并且编写应用程序时不会出现冲突。我想建立一个符合以下条件的系统：

1. 每个站点都可以将文件存储在共享的“命名空间”中。也就是说，所有文件都将显示在同一文件系统中。
2. 除非必要，否则每个站点都不会通过WAN发送数据。即，在WAN的每一侧都有本地存储，这些本地存储将“合并”到同一逻辑文件系统中。
3. Linux＆Free（$$$）是一个加号

基本上，像中央NFS共享之类的东西可以满足大多数要求，但是它不允许本地写入的数据保留在本地。来自WAN远端的所有数据将始终被本地复制。

我研究了Lustre，并对其进行了一些成功的测试，但是，它似乎在整个分布式存储中相当均匀地分布了文件。我已经仔细阅读了文档，但是没有发现任何可以自动“优先”使用本地存储而不是远程存储的东西。即使是使用最低延迟存储的东西也可以。它大部分时间都可以工作，可以满足该应用程序的要求。

以下是一些问题的答案：

• 服务器节点：2或3个启动。每个服务器将同时连接数十个读/写客户端。
• WAN拓扑是全网状且可靠的。（大公司，成本不像繁文tape节那样限制）
• 客户端故障转移：实际上我没有考虑过进行客户端故障转移（主要是因为我们当前的应用并不仅仅在一个站点上执行此操作）。我认为实际的答案是，每个地理分布站点上的服务器对于它们所服务的客户端都是单点故障。但是，如果您正在考虑此处的特定内容，我认为这与讨论非常相关。
• Roll-my-own：我曾经考虑过rsync / unison，但是我需要很多漂亮的逻辑才能无缝地使这项工作的“动态”部分成为现实。即，文件似乎是本地文件，但仅按需检索。
• MS-DFS：当然，这似乎是我应该研究的东西。我的主要问题可能是不确定Windows上的NFS服务器配置/可靠性/性能，因为连接的许多客户端都是NFS客户端。

对Linux要求感到羞耻。这正是Windows DFS所做的。从2003 R2开始，它也以块级为基础。

一些问题：

• 您正在考虑参与多少个“服务器”节点？

• WAN连接拓扑是什么样的-集线器和辐条，全网格？它的可靠性如何？

• 您是否希望客户端在本地服务器发生故障的情况下故障转移到非地理位置的本地服务器？

Windows DFS-R当然会满足您的需求，尽管可能会产生高昂的许可费用。

您说冲突不是问题，并且您不需要分布式锁管理器，因此可以使用rsync或Unison之类的用户级工具来做到这一点，只需将生成的带有NFS的文件集导出到本地客户端。这很丑陋，您必须处理一些系统，才能处理生成复制拓扑并实际运行用户界面工具，但是随着许可费用的增加，它肯定会便宜。

您考虑过AFS吗？

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

据我了解，最近的大多数发展都在OpenAFS项目的背后。

我无法假装对项目不熟悉，无法知道“首选位置”功能是否可用，但是听起来很合适。

您是否看过Lustre的OST池？

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

因此，您可以为每个站点设置一个目录，然后将该目录分配给该站点的本地OST，这会将所有I / O定向到本地OST。它将仍然是全局名称空间。

要通过WAN连接（本地缓存服务器等）来改善Lustre，还有很多工作要做，但这些工作仍在AFAIK的大力开发下。

也许是NFS，但是在应用程序服务器上使用Cachefs可以实现您的目标。据我了解，所有写入的内容仍将流向中央服务器，但至少读取结果最终可能会在本地缓存。根据您的使用方式，这可能会导致读取延迟很多。

此外，mabye UnionFS也值得研究。有了这个，我认为每个位置都将是一个NFS导出，然后您可以在每个位置使用UnionFS使其具有该位置，并且该位置上的所有其他NFS挂载都显示为一个文件系统。我没有这个经验。

您可以查看DRBD以复制磁盘。http://www.drbd.org/。这是一个Linux高可用性解决方案，它刚刚成为内核。

但是，这有一些限制：

1. 只能设置两个节点
2. WAN可能太不可靠，无法保持DRBD的健壮性。

如果您想使其简单，请看一下rsync，它解决了很多问题并且可以编写脚本。

检查chironfs。

也许它可以根据文件系统执行您想要的操作。

Btsync是我经验丰富的另一个解决方案。它使用BitTorrent协议传输文件，因此与同步新文件相比，拥有更多服务器的速度更快。

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

然后，您的btsync客户端可以共享本地网络上的文件夹。

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

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