用GlusterFS和Windows避免SPOFS
我们有一个我们用于处理函数的GlusterFS集群。 我们希望将Windows集成到其中，但在如何避免服务于GlusterFS卷的Samba服务器的单点故障方面遇到一些麻烦。
我们的文件stream如下所示：
- 文件被Linux处理节点读取。
- 文件被处理。
- 结果（可以很小，可能很大）在完成后写回到GlusterFS卷。
- 结果可以写入数据库，也可以包含多个不同大小的文件。
- 处理节点从队列中取出另一个作业并转到GOTO 1。
Gluster很棒，因为它提供了一个分布式卷，以及即时复制。 抗灾能力很好！ 我们喜欢它。
但是，由于Windows没有本地的GlusterFS客户端，我们需要一些方法让我们的基于Windows的处理节点以类似的弹性方式与文件存储进行交互。 GlusterFS文档指出 ，提供Windows访问的方法是在已安装的GlusterFS卷上build立一个Samba服务器。 这将导致像这样的文件stream：
这对我来说看起来像是一个单一的失败点。
一种select是对Samba进行集群 ，但是现在似乎是基于不稳定的代码，因此无法运行。
所以我正在寻找另一种方法。
关于我们抛出的各种数据的一些关键细节：
- 原始文件大小可以从几KB到几十GB之间的任何地方。
- 处理过的文件大小可以从几个KB到一个GB或两个。
- 某些进程（如挖掘存档文件，如.zip或.tar）可能导致大量的进一步写入，因为所包含的文件将被导入到文件存储中。
- 文件计数可以达到数以百万计。
此工作负载不适用于“静态工作单元大小”Hadoop设置。 同样，我们评估了S3风格的对象存储，但发现它们缺乏。
我们的应用程序是用Ruby编写的，我们在Windows节点上有一个Cygwin环境。 这可以帮助我们。
我正在考虑的一个选项是在安装了GlusterFS卷的服务器集群上的简单HTTP服务。 由于我们所做的Gluster基本上是GET / PUT操作，这似乎很容易转移到基于HTTP的文件传输方法。 把它们放在一个负载平衡器对后面，Windows节点可以把HTTP PUT放到他们小心脏的内容上。
我不知道的是GlusterFS一致性如何维持 。 HTTP代理层在处理节点报告完成写操作和在GlusterFS卷上实际显示时间之间引入了足够的延迟时间，我担心后来处理尝试拾取文件的处理阶段不会find它。 我很确定，使用direct-io-mode=enable mount-option会有所帮助， 但是我不确定这是否足够 。 我还应该做些什么来提高连贯性？
或者我应该完全追求另一种方法？
正如Tom指出的那样，NFS是另一种select。 所以我跑了一个testing。 由于上述文件具有我们需要保留的客户端提供的名称，并且可以使用任何语言，因此我们需要保留文件名。 所以我用这些文件build立了一个目录：
当我从安装了NFS客户端的Server 2008 R2系统上安装它时，我得到如下所示的目录：
很显然，Unicode并没有被保留下来。 所以NFS不会为我工作。
我喜欢GlusterFS。 其实我喜欢GlusterFS。 只要你可以给它一些专用的带宽一切都很好。
GlusterFS最棒的一点就是使用NFS。 我最近一直在使用的是Windows 7和2k8R2上的NFS 。
这是我要做的。
- 设置2个可导出NFS的GlusterFS服务器。
- 设置它们之间的心跳链接。
- 也许部署像心跳/心脏起搏器？
- 在Gluster节点之间build立一个虚拟IP（VIP）。
- 使用VIP的IP地址连接Windows Boxen的映射networking驱动器。
- testing一切你可能想象的。
集群Samba听起来很可怕，即使你这么做，Samba仍然缺乏在某些Windowsnetworking中可靠运行的能力（所有NT4域的兼容性，似乎都无法超越）。
我认为 ，因为每个gluster节点都处于分布式，复制模式，那么理论上应该能够连接到其中任一个，并且让它担心移动数据。 因此，心跳应该是redirect和控制你正在谈论的事情。
至于你的
- 文件计数可以达到数以百万计。
我build议你研究使用XFS作为底层文件系统，因为它对于大型文件系统来说是相当不错的，而且在GlusterFS
也许你可以在HA解决scheme中思考…使用LDAP进行身份validation（可以复制尽可能多的LDAP服务器）并放置IP来监听SMB服务。
这个IP将在主服务器上浮动。 当这种情况下，Heartbeat可以在第二台服务器上启动服务。
这台服务器将有一个安装点到glusterfs，然后所有的数据将在那里。
这是一个可能的解决scheme，它很容易pipe理…