我们有一个用于处理功能的 GlusterFS 集群。我们想将 Windows 集成到其中，但在如何避免 Samba 服务器为 GlusterFS 卷提供服务的单点故障方面遇到了一些麻烦。
我们的文件流的工作原理如下：
- 文件由Linux处理节点读取。
- 文件已处理。
- 结果（可能很小，也可能很大）完成后会被写回到 GlusterFS 卷。
- 结果可以写入数据库，或者可以包含多个不同大小的文件。
- 处理节点从队列中挑选另一项作业并 GOTO 1。
Gluster 很棒，因为它提供分布式卷以及即时复制。灾难恢复能力很棒！我们喜欢它。
然而，由于 Windows 没有原生的 GlusterFS 客户端，我们需要某种方式让基于 Windows 的处理节点以类似的弹性方式与文件存储进行交互。GlusterFS 文档指出提供 Windows 访问的方法是在已安装的 GlusterFS 卷上设置 Samba 服务器。这将导致如下文件流：
在我看来，这就像一个单点故障。
一个选择是集群 Samba，但目前看来这是基于不稳定的代码，因此无法运行。
所以我正在寻找另一种方法。
关于我们所抛出的数据类型的一些关键细节：
- 原始文件大小可以是几 KB 到几十 GB。
- 处理的文件大小可以是几KB到一两GB。
- 某些过程（例如挖掘 .zip 或 .tar 等存档文件）可能会导致大量进一步的写入，因为其中包含的文件会被导入文件存储。
- 文件数量可以达到数千万。
此工作负载不适用于“静态工作单元大小”的 Hadoop 设置。同样，我们也评估了 S3 样式的对象存储，但发现它们存在不足。
我们的应用程序是用 Ruby 编写的，并且我们在 Windows 节点上有一个 Cygwin 环境。这可能会对我们有所帮助。
我正在考虑的一个选项是在安装了 GlusterFS 卷的服务器集群上提供简单的 HTTP 服务。由于我们使用 Gluster 所做的一切本质上都是 GET/PUT 操作，因此这似乎很容易转移到基于 HTTP 的文件传输方法。将它们放在负载平衡器对后面，Windows 节点就可以 HTTP PUT 到它们小小的蓝色心脏的内容。
我不知道的是如何维护 GlusterFS 一致性。HTTP 代理层在处理节点报告写入完成和实际在 GlusterFS 卷上可见之间引入了足够的延迟，我担心尝试获取文件的后续处理阶段将找不到它。我很确定使用 mount 选项direct-io-mode=enable会有所帮助，但我不确定这是否足够我还应该做什么来提高连贯性？
或者我应该完全采用另一种方法？
正如 Tom 在下面指出的那样，NFS 是另一种选择。所以我进行了测试。由于上述文件具有我们需要保留的客户端提供的名称，并且可以采用任何语言，因此我们确实需要保留文件名。所以我用这些文件建立了一个目录：
当我从安装了 NFS 客户端的 Server 2008 R2 系统挂载它时，我得到了如下目录列表：
显然，Unicode 未被保留。因此 NFS 对我来说不起作用。
答案1
我喜欢 GlusterFS。实际上，我非常崇拜 GlusterFS。只要你能给它一些专用带宽，一切都会好起来。
GlusterFS 的一大优点是可以与 NFS 配合使用。最近我使用时遇到的一个令人惊讶的事情是Windows 7 和 2k8R2 上的 NFS。
以下是我要做的。
- 设置 2 个可以导出 NFS 的 GlusterFS 服务器。
- 它们之间建立心跳链接。
- 也许部署类似 Heartbeat/Pacemaker 的东西？
- 在您的 Gluster 节点之间设置虚拟 IP（VIP）。
- 使用 VIP 的 IP 地址连接 Windows 盒的映射网络驱动器。
- 测试您所能想到的一切。
集群 Samba 听起来很可怕，而且即使你这样做了，Samba 仍然缺乏在某些 Windows 网络中可靠运行的能力（所有 NT4 域兼容性，似乎永远无法超越这一点）。
我思考因为每个 gluster 节点都处于分布式、复制模式，所以理论上你应该能够连接到任何一个并让它负责移动您的数据。因此，heartbeatd 应该负责重定向和控制您正在与哪个服务器通信。
至于你的
- 文件数量可以达到数千万。
我建议你研究使用 XFS 作为底层文件系统，因为它非常适合大型文件系统，并且GlusterFS 下支持
答案2
也许您可以考虑 HA 解决方案...使用 LDAP 进行身份验证（它可以复制任意数量的 LDAP 服务器）并放置一个 IP 来监听 SMB 服务。
此 IP 将在主服务器上浮动。当主服务器停机时，Heartbeat 可以在第二台服务器上启动服务。
该服务器将有一个到 glusterfs 的挂载点，然后所有数据都将在那里。
这是一个可能的解决方案，而且很容易管理......