避免通过GlusterFS和Windows使用SPOFS
我们有一个用于处理功能的GlusterFS集群。我们希望将Windows集成到其中，但是在解决如何避免单点故障方面遇到了一些麻烦，单点故障是为GlusterFS卷提供服务的Samba服务器。 我们的文件流如下所示： 文件由Linux处理节点读取。 文件已处理。 完成后，结果（可能很小，可能会很大）被写回到GlusterFS卷。 结果可以改为写入数据库，也可以包括多个大小不同的文件。 处理节点从队列和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对我不起作用。