我正在构建一个需要通过WAN在几个站点上分发标准文件服务器的应用程序.基本上,每个站点都需要编写大量不同大小的misc文件(有些在100s MB范围内,但大多数都很小),并且编写应用程序使得冲突不成问题.我想建立一个符合以下条件的系统：
>每个站点都可以将文件存储在共享的“命名空间”中.也就是说,所有文件都会显示在同一个文件系统中.
>除非必要,否则每个站点都不会通过WAN发送数据.也就是说,WAN的每一侧都有本地存储器,它们将“合并”到同一个逻辑文件系统中.
> Linux&免费($$$)是一个加号
基本上,类似于中央NFS共享的东西将满足大多数要求,但是它不允许本地写入的数据保持在本地.来自WAN远程端的所有数据将始终在本地复制.
我查看了Lustre,并使用它运行了一些成功的测试,但是,它似乎在分布式存储中相当均匀地分发文件.我已经挖掘了文档并且没有找到任何自动“偏好”本地存储而不是远程存储的东西.即使是具有最低延迟存储的东西也没关系.它大部分时间都可以工作,满足这个应用程序的要求.
下面提到的一些问题的一些答案：
>服务器节点：2或3开始.每个服务器都有几十个同时读/写客户端连接.
> WAN拓扑是全网状且可靠的. (大公司,成本不像繁文缛节那样有限)
>客户端故障转移：我实际上没有想过让客户端进行故障转移(主要是因为我们当前的应用程序不会在一个站点上执行此操作).我认为实际答案是,每个地理位置分散的站点上的服务器应该是他们所服务的客户的单点故障.但是,如果你在考虑某些特定的东西,我认为它与讨论密切相关.
> Roll-my-own：我已经考虑过rsync / unison,但是我需要相当多的花哨逻辑才能使这个工作的“动态”部分无缝地完成.即,文件似乎是本地的,但仅在需要时检索.
> MS-DFS：这似乎是我应该研究的问题.我的主要问题可能是不确定Windows上的NFS服务器配置/可靠性/性能,因为许多连接的客户端都是NFS客户端.
解决方法
关于Linux要求的耻辱.这正是Windows DFS所做的.自2003 R2以来,它也在块级基础上实现.