使用 GlusterFS 和 Windows 避免 SPOFS

Question

我们有一个用于处理功能的 GlusterFS 集群。我们希望将 Windows 集成到其中，但在弄清楚如何避免单点故障（Samba 服务器为 GlusterFS 卷提供服务）时遇到了一些麻烦。

我们的文件流是这样工作的：

1. 文件由 Linux 处理节点读取。
2. 文件被处理。
3. 结果（可能很小，也可能很大）在完成后写回 GlusterFS 卷。
   • 结果可以写入数据库，也可以包含多个不同大小的文件。
4. 处理节点从队列中取出另一个作业并转到 1。

Gluster 很棒，因为它提供了分布式卷以及即时复制。抗灾能力不错！我们喜欢它。

但是，由于 Windows 没有本机 GlusterFS 客户端，我们需要某种方式让基于 Windows 的处理节点以类似的弹性方式与文件存储交互。该GlusterFS文档指出，为了提供Windows访问的方式是建立在顶部处的Samba服务器安装GlusterFS卷。这将导致这样的文件流：

对我来说，这看起来像是单点故障。

一种选择是集群 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=enablemount-option 会有所帮助，但我不确定这是否足够。我还应该做些什么来提高一致性？

还是我应该完全采用另一种方法？

---

正如汤姆在下面指出的，NFS 是另一种选择。所以我做了一个测试。由于上述文件具有我们需要保留的客户端提供的名称，并且可以采用任何语言，因此我们确实需要保留文件名。所以我用这些文件建立了一个目录：

当我从安装了 NFS 客户端的 Server 2008 R2 系统挂载它时，我得到如下目录列表：

显然，Unicode 没有被保留。所以NFS对我不起作用。

Answer 1

我喜欢 GlusterFS。实际上，我喜欢 GlusterFS。只要你可以给它一些专用带宽，一切都很好。

GlusterFS 最好的事情之一是将它与 NFS 一起使用。我最近一直在使用的令人惊讶的事情之一是Windows 7 和 2k8R2 上的 NFS。

这就是我要做的。

1. 设置 2 个可以导出 NFS 的 GlusterFS 服务器。
2. 在它们之间建立心跳链接。
3. 也许部署类似 Heartbeat/Pacemaker 的东西？
4. 在 Gluster 节点之间设置虚拟 IP (VIP)。
5. 使用 VIP 的 IP 地址连接 Windows boxen 的映射网络驱动器。
6. 测试你能想象到的一切。

集群 Samba 听起来很可怕，即使你这样做了，Samba 仍然缺乏在某些 Windows 网络中可靠运行的能力（所有 NT4 域兼容性，似乎永远无法超越）。

我认为因为每个 gluster 节点都处于分布式、复制模式，所以理论上你应该能够连接到任何一个并允许它担心移动你的数据。因此，heartbeatd 应该是进行重定向和控制与您交谈的对象的东西。

至于你的

• 文件数可以达到数百万。

我建议你研究一下使用 XFS 作为底层文件系统，因为它对大文件系统非常好，并且在 GlusterFS 下支持