windows-7 – 使用GlusterFS和Windows避免SPOFS

我们有一个GlusterFS集群,用于处理我们的处理功能.我们希望将 Windows集成到其中,但在确定如何避免作为服务于GlusterFS卷的Samba服务器的单点故障时遇到一些麻烦.

我们的文件流程如下：

>文件由Linux处理节点读取.
>处理文件.
>结果(可以很小,可能很大)会在完成后写回GlusterFS卷.

>结果可以写入数据库,也可以包含多个不同大小的文件.

>处理节点从队列和GOTO 1中选择另一个作业.

Gluster非常棒,因为它提供分布式卷以及即时复制.灾难恢复力很好！我们喜欢它.

但是,由于Windows没有本机GlusterFS客户端,我们需要一些方法让基于Windows的处理节点以类似弹性的方式与文件存储进行交互.提供Windows访问权限的方法是在挂载的GlusterFS卷上设置Samba服务器.这将导致像这样的文件流：

这看起来像是我的单点失败.

一个选项是cluster 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 = enable mount-option会有所帮助,但我不确定这是否足够.我还应该做些什么来提高一致性？

或者我应该完全追求另一种方法？

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

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

显然,Unicode没有被保留.因此NFS对我不起作用.

关于GlusterFS的最好的事情之一就是在NFS中使用它.我最近一直在努力的一件令人惊讶的事情是NFS on Windows 7 and 2k8R2.

这就是我要做的.

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

群集Samba听起来很可怕,即使你这样做,Samba仍然缺乏在某些Windows网络中可靠行为的能力(所有NT4域兼容性,似乎永远无法超越它).

我认为,因为每个gluster节点都处于分布式复制模式,那么理论上你应该能够连接到任何一个并允许它担心移动你的数据.因此,heartbeatd应该是重定向和控制你正在谈论的那个.

至于你的

>文件计数可以达到数百万的数量.

我建议您调查使用XFS作为底层文件系统,因为它对于大文件系统和supported under GlusterFS非常好

（编辑：PHP编程网 - 黄冈站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!