我们的文件流程如下：
>文件由Linux处理节点读取.
>处理文件.
>结果(可以很小,可能很大)会在完成后写回GlusterFS卷.
>处理节点从队列和GOTO 1中选择另一个作业.
Gluster非常棒,因为它提供分布式卷以及即时复制.灾难恢复力很好！我们喜欢它.
但是,由于Windows没有本机GlusterFS客户端,我们需要一些方法让基于Windows的处理节点以类似弹性的方式与文件存储进行交互.提供Windows访问权限的方法是在挂载的GlusterFS卷上设置Samba服务器.这将导致像这样的文件流：
这看起来像是我的单点失败.
一个选项是cluster Samba,但这似乎是基于不稳定的代码,因此不在运行中.
所以我正在寻找另一种方法.
关于我们抛出的数据种类的一些关键细节：
>原始文件大小可以是几KB到几十GB.
>处理的文件大小可以是几KB到GB或两个.
>某些进程(例如挖掘.zip或.tar等存档文件)会导致大量进一步写入,因为包含的文件会导入到文件存储中.
>文件计数可以达到数百万的数量.
此工作负载不适用于“静态工作单元大小”Hadoop设置.同样,我们已经评估了S3风格的对象存储,但发现它们缺乏.
我们的应用程序是用Ruby自定义的,我们在Windows节点上有一个Cygwin环境.这可能对我们有帮助.
我正在考虑的一个选项是在已安装GlusterFS卷的服务器群集上的简单HTTP服务.由于我们对Gluster的所有操作基本上都是GET / PUT操作,因此这似乎很容易转移到基于HTTP的文件传输方法.将它们放在负载均衡器对后面,Windows节点可以HTTP PUT到它们的蓝心小内容.
我不知道的是如何保持GlusterFS的一致性. HTTP代理层在处理节点报告完成写入时以及在GlusterFS卷上实际可见时之间引入了足够的延迟,我担心以后处理阶段尝试获取文件不会找到它.我很确定使用direct-io-mode = enable mount-option会有所帮助,但我不确定这是否足够.我还应该做些什么来提高一致性？
或者我应该完全追求另一种方法？
正如Tom在下面指出的,NFS是另一种选择.所以我进行了测试.由于上述文件具有我们需要保留的客户端提供的名称,并且可以使用任何语言,因此我们需要保留文件名.所以我用这些文件构建了一个目录：
当我从安装了NFS客户端的Server 2008 R2系统安装它时,我得到一个如下目录列表：
显然,Unicode没有被保留.因此NFS对我不起作用.
关于GlusterFS的最好的事情之一就是在NFS中使用它.我最近一直在努力的一件令人惊讶的事情是NFS on Windows 7 and 2k8R2.
这就是我要做的.
>设置2个可以导出NFS的GlusterFS服务器.
>在它们之间建立心跳链接.
>也许部署Heartbeat / Pacemaker之类的东西？
>在Gluster节点之间设置虚拟IP(VIP).
>使用VIP的IP地址连接Windows Boxen的映射网络驱动器.
>测试你可能想象的一切.
群集Samba听起来很可怕,即使你这样做,Samba仍然缺乏在某些Windows网络中可靠行为的能力(所有NT4域兼容性,似乎永远无法超越它).
我认为,因为每个gluster节点都处于分布式复制模式,那么理论上你应该能够连接到任何一个并允许它担心移动你的数据.因此,heartbeatd应该是重定向和控制你正在谈论的那个.
至于你的
