避免通过GlusterFS和Windows使用SPOFS

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

我们的文件流如下所示：

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

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

还是我应该完全追求另一种方法？

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

当我从装有NFS客户端的Server 2008 R2系统中挂载它时，会得到一个目录列表，如下所示：

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

我喜欢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节点都处于分布式复制模式，因此从理论上讲，您应该可以连接到其中一个，并允许它担心来回移动数据。结果，心跳应该是执行重定向并控制与您交谈的对象的事情。

至于你

• 文件数可以达到百万分之十。

我建议您研究将XFS用作基础文件系统，因为它对于大型文件系统非常有用，并且在GlusterFS下受支持

也许您可以考虑在HA解决方案中...使用LDAP进行身份验证（可以将其复制为所需的许多LDAP服务器），并放置一个IP来侦听SMB服务。

该IP将在主服务器上浮动。如果关闭，则心跳可以在第二台服务器上启动服务。

该服务器将有一个glusterfs的挂载点，然后所有数据都将在那里。

这是一个可能的解决方案，而且非常容易管理...