服务器 Gind.cn

服务器问题集锦,包括 Linux(Ubuntu, Centos,Debian等)和Windows Server服务器

用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不会为我工作。