我在Ubuntu 12.04上运行官方的GlusterFS 3.5软件包，作为客户端和服务器，除了在启动的时候挂载GlusterFS卷，所有东西似乎都能正常工作。 这是我在日志文件中看到的： [2014-06-17 08:20:52.969258] I [glusterfsd.c:1959:main] 0-/usr/sbin/glusterfs: Started running /usr/sbin/glusterfs version 3.5.0 (/usr/sbin/glusterfs –volfile-server=127.0.0.1 –volfile-id=/public_uploads /var/www/shared/public/uploads) [2014-06-17 08:20:52.998985] I [socket.c:3561:socket_init] 0-glusterfs: SSL support is NOT enabled [2014-06-17 08:20:52.999048] I [socket.c:3576:socket_init] 0-glusterfs: using system polling thread [2014-06-17 08:20:53.000373] E [socket.c:2161:socket_connect_finish] 0-glusterfs: connection to 127.0.0.1:24007 failed (Connection refused) [2014-06-17 08:20:53.000427] E [glusterfsd-mgmt.c:1601:mgmt_rpc_notify] 0-glusterfsd-mgmt: failed to […]
我正在设置我的第一个Gluster 3.4安装，并且一切都很好，直到我想创build一个分布式复制卷。 我有4台服务器192.168.0.11,192.168.0.12,192.168.0.13和192.168.0.14。 从192.168.0.11我跑了： gluster peer probe 192.168.0.12 gluster peer probe 192.168.0.13 gluster peer probe 192.168.0.14 在每个服务器上，我在/ export / brick1上安装了一个存储卷 然后我运行在192.168.0.11 gluster volume create gv0 replica2 192.168.0.11:/export/brick1 192.168.0.12:/export/brick1 192.168.0.13:/export/brick1 192.168.0.14:/export/brick1 但是我得到的错误： volume create: gv0: failed: Host 192.168.0.11 is not in 'Peer in Cluster' state 果然，如果你运行gluster对等状态，它会显示其他连接主机的3个对等点。 即同行人数：3 主机名：192.168.0.12端口：24007 Uuid：bcea6044-f841-4465-88e4-f76a0c8d5198状态：集群中的对等（已连接） 主机名：192.168.0.13端口：24007 Uuid：3b5c188e-9be8-4d0f-a7bd-b738a88f2199状态：集群中的对等（已连接） 主机名：192.168.0.14端口：24007 Uuid：f6f326eb-0181-4f99-8072-f27652dab064状态：集群中的对等（已连接） 但是，从192.168.0.12开始，同样的命令也显示3个主机，192.168.0.11是其中的一部分。 即 Number […]
我有2个networking服务器，有可能在这个过程中增加更多的服务器。 现在我使用lsyncd + csync2保持这些服务器同步。 由于所有文件都在两台服务器上（本地打开文件时不需要networking访问），但在其他情况下效果并不理想，因此性能performance良好。 其中一个例子是，如果我删除服务器1上的文件，并立即将新file upload到具有相同名称的服务器1。 同时从服务器2中删除该文件，导致服务器1上的新上传的文件被删除，服务器2向服务器1发送删除事件，完成“更新循环”。 我不禁想到，必须有更好的方法来保持服务器的同步。 我一直在看GlusterFS，我发现所有文件都复制到所有服务器的设置是不鼓励的。 但是，我正在这些服务器上运行Drupal等CMS系统。 这样的CMS系统通常会打开相当多的文件，我担心太多的networkingstream量来获取这些文件会减慢请求速度。 将GlusterFS设置为将所有文件复制到所有节点，这是一个想法，以取代lsyncd + csync2，或者这是一个坏主意？
我们有一个我们用于处理函数的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不会为我工作。
我最近一直在玩glusterfs。 我想尝试的是以类似的方式在glusterfs之上运行mysqld，因为它可能在DRBD之上运行MySQL 。 我熟悉MySQL复制以及使用它的好处，而不是使用这种方法，我也知道MongoDB和其他NoSQL解决scheme。 但是，如果我可以将MySQL保留原样并复制底层文件系统，那么这将是一个简单的解决scheme。 这是可能的，如果它是我能find如何？
过去两天我一直在玩gluster，并在这里和他们的问题系统提问。 我真的不明白一些东西。 我看到人们在说些什么 在服务器之间设置复制砖块（因为您只使用3，复制将会更安全），并且每台服务器都会将所有其他服务器的文件视为“本地” – 即使一台服务器发生故障，文件也会被复制到其他服务器。 要么 Gluster将跨卷（砖块）保持文件同步，并具有“自我修复”function，可处理由于一台服务器脱机而导致的任何不一致情况。 由于我将远程卷从服务器挂载到客户端，gluster如何处理服务器节点（卷挂载的卷）的故障？ 从我已经尝试在卷上安装的客户端上的文件夹变得无法访问，我必须使用卸载来解锁它。 之后没有来自服务器的内容。 基本上，我没有看到任何解释： 当服务器节点出现故障时，会发生什么，以及是否有可能真正复制内容，如unison或rsync呢？
Glusterfs虽然是一个很好的分布式文件系统，但几乎没有办法监视它的完整性。 服务器可以来来去去，砖块可能会陈旧或者失败，我恐怕知道这个可能太晚了。 最近我们有一个奇怪的失败，当一切都显现出来的时候，却有一块砖块掉了下来（纯粹是巧合）。 有一个简单可靠的方法（cron脚本？），让我知道我的GlusterFS 3.2卷的健康状况？
我只是检查我的glusterfs卷的状态，我有一个没有path的裂脑入口： # gluster volume heal private_uploads info Brick server01:/var/lib/glusterfs/brick01/uploads/ <gfid:4c0edafb-0c28-427c-a162-e530280b3396> – Is in split-brain <gfid:42d62418-1be9-4f96-96c4-268230316869> – Is in split-brain Number of entries: 2 Brick server02:/var/lib/glusterfs/brick01/uploads/ <gfid:42d62418-1be9-4f96-96c4-268230316869> – Is in split-brain <gfid:4c0edafb-0c28-427c-a162-e530280b3396> – Is in split-brain Number of entries: 2 这是什么意思？ 我该如何解决？ 我正在运行GlusterFS 3.5.9： # gluster –version glusterfs 3.5.9 built on Mar 28 2016 07:10:17 Repository […]
是否有可能创build一个ZFS集群？ 或者你是否需要去GFSTERFSpipe理的UFS格式化池的看似丑陋的（至less对我来说）ZFS路线？ 这个想法是看看是否有可能扩展到ZFS应该能够处理而没有打嗝的多Petabyte分布式存储。 任何指针，博客，文章？
我的团队目前有两个较大的存储服务器，都运行debian linux的NAS。 第一个是一个几十年前的一个全function的24盘（SATA）服务器。 我们有两个设置LVM的硬件RAIDS。 第二个服务器是64个磁盘，分为4个机箱，每个机箱都有一个硬件RAID 6，通过外部SAS连接。 我们使用LVM的XFS来创build100TB的可用存储。 所有这些工作都很好，但是我们超出了这些系统。 在构build了两个这样的服务器并仍在不断增长的情况下，我们希望构build一些能够使我们在未来增长方面更具灵活性的备份选项，在磁盘故障下更好地运行（检查更大的文件系统可能需要一天或更长时间）在一个严重的并发环境中（思考小型计算机集群）。 我们没有系统pipe理支持，所以我们自己pipe理所有这些（我们是一个基因组实验室）。 因此，我们所寻求的是相对低成本，可接受的性能存储解决scheme，它将允许未来的增长和灵活的configuration（认为ZFS具有不同的操作特性）。 我们可能超出了单个NAS的境界。 我们一直在考虑将ZFS（例如openindiana）或者每个服务器的btrfs与运行在其上的glusterfs结合起来，如果我们自己做的话。 我们所反对的仅仅是咬紧牙关，投资于Isilon或3Par存储解决scheme。 任何build议或经验，表示赞赏。