标签: glusterfs

我正在为一个小型网络服务器场规划我的新共享存储基础设施。因此，我对许多 NAS 文件系统进行了大量测试。通过这样做，我得到了一些意想不到的结果，想知道这里是否有人可以证实这一点。

简而言之：对于小文件写入，Samba 比 NFS 和 GlusterFS 快得多。

这是我所做的：我运行了一个包含大量文件的简单“rsync 基准测试”，以比较小文件的写入性能。为了更容易复制，我刚刚用当前 wordpress tar.gz 的内容重新运行了它。

• GlusterFS 复制 2：32-35 秒，高 CPU 负载
• GlusterFS 单：14-16 秒，高 CPU 负载
• GlusterFS + NFS 客户端：16-19 秒，高 CPU 负载
• NFS 内核服务器 + NFS 客户端（同步）：32-36 秒，CPU 负载极低
• NFS 内核服务器 + NFS 客户端（异步）：3-4 秒，非常低的 CPU 负载
• Samba：4-7 秒，中等 CPU 负载
• 直接磁盘：< 1秒

我绝对不是 samba 大师（我想我最后一次接触的是 samba 2.x），所以我没有在这里优化任何东西——只是开箱即用的配置（debian/squeeze 包）。我添加的唯一一件事是“同步始终 = 是”，它应该在写入后强制执行同步（但看到这些结果......）。没有它，测试会快 1-2 秒。

所有测试都在同一台机器上运行（自安装它的 NAS 导出），因此没有网络延迟 …

我目前正在考虑将我们的一些服务器和应用程序迁移到coreOS环境。我在这里看到的问题之一是持久数据的管理，因为在将容器移动到新机器时，coreOS 不处理 Docker 卷。经过一番研究，我发现glusterFS声称是一个可以解决我所有问题的集群文件系统。

我目前的想法是：我有一个 glusterFS 容器，它在我的每台 coreOS 机器上作为特权容器运行，并公开一个存储，/mnt/gluster例如。在我的Dockerfiles 中，我指定我的所有卷都应安装在此路径上。

我考虑的下一件事是哪些容器应该获得自己的卷，哪些应该共享一个。例如，每个mysql容器都有自己的卷，因为它能够自己处理复制。我不想惹这个。为同一网站提供服务的网络服务器将正确使用相同的卷来处理“用户上传的图像”等内容，因为它们无法复制这些数据。

有没有人尝试过这样的事情，或者我错过了什么？

在我的特殊情况下，我想remote-fs在glusterfs完全启动后启动单元。

我的系统文件：

glusterfs 目标：

node04:/usr/lib/systemd/system # cat glusterfsd.service 
[Unit]
Description=GlusterFS brick processes (stopping only)
After=network.target glusterd.service

[Service]
Type=oneshot
ExecStart=/bin/true
RemainAfterExit=yes
ExecStop=/bin/sh -c "/bin/killall --wait glusterfsd || /bin/true"
ExecReload=/bin/sh -c "/bin/killall -HUP glusterfsd || /bin/true"

[Install]
WantedBy=multi-user.target

remote-fs 目标：

node04:/usr/lib/systemd/system # cat remote-fs.target 
[Unit]
Description=Remote File Systems
Documentation=man:systemd.special(7)
Requires=glusterfsd.service
After=glusterfsd.service remote-fs-pre.target
DefaultDependencies=no
Conflicts=shutdown.target

[Install]
WantedBy=multi-user.target

好的，所有 Gluster 守护进程都成功启动，我想通过 NFS 挂载 Gluster 文件系统，但是 Gluster 的 NFS 共享不是在glusterfs.service启动后立即准备好，而是在几秒钟后准备就绪，因此通常remote-fs无法挂载它，即使是关于Requires和After指令。

我们来看看日志：

Apr 14 …

是否可以创建 ZFS 集群？或者您是否需要使用由 GlusterFS 管理的 UFS 格式池来走 ZFS 看似丑陋（至少对我而言）的路线？

我们的想法是看看是否可以扩展到 ZFS 应该能够顺利处理的多拍字节分布式存储。

任何指针，博客，帖子？

我的团队目前有两台大型存储服务器，两台 NAS 都运行 debian linux。第一个是已有几年历史的一体式 24 磁盘 (SATA) 服务器。我们在其上设置了两个硬件 RAID，并在其上设置了 LVM。第二个服务器是 64 个磁盘，分为 4 个机箱，每个机箱都是硬件 RAID 6，通过外部 SAS 连接。我们使用 XFS 和 LVM 来创建 100TB 的可用存储。所有这些都运行得很好，但我们正在超越这些系统。构建了两个这样的服务器并且仍在增长，我们希望构建一些东西，让我们在未来增长、备份选项方面具有更大的灵活性，在磁盘故障时表现更好（检查更大的文件系统可能需要一天或更长时间），并且可以承受在高度并发的环境中（想想小型计算机集群）。我们没有系统管理支持，

因此，我们寻求的是一种相对低成本、可接受的性能存储解决方案，它将允许未来的增长和灵活的配置（想想具有不同操作特性的不同池的 ZFS）。我们可能超出了单个 NAS 的范围。我们一直在考虑将 ZFS（例如在 openindiana 上）或每个服务器的 btrfs 与运行在其上的 glusterfs 结合起来，如果我们自己做的话。我们正在权衡的只是咬紧牙关并投资于 Isilon 或 3Par 存储解决方案。

任何建议或经验表示赞赏。

我正在使用 GlusterFS 在 4 台机器上创建和挂载卷。比方说，该机器被称为machine1，machine2，machine3和machine4。

我的同行已经成功探查了。

我使用以下命令来创建我的卷：

sudo gluster volume create ssl replica 2 transport tcp machine1:/srv/gluster/ssl machine2:/srv/gluster/ssl machine3:/srv/gluster/ssl machine4:/srv/gluster/ssl force

然后我开始音量：

sudo gluster volume start ssl

我已经/myproject/ssl使用以下命令挂载了目录：

sudo mount -t glusterfs machine1:/ssl /myproject/ssl

当安装在每台机器上时，一切都按预期工作，并且该/myproject/ssl目录具有跨所有机器共享的数据。

问题是，我到底如何以 Ansible 方式做到这一点？

以下是我以 Ansible 方式执行这两个命令的尝试：

- name: Configure Gluster volume.
  gluster_volume:
    state: present
    name: "{{ gluster.brick_name }}"
    brick: "{{ gluster.brick_dir }}"
    replicas: 2
    cluster: "{{ groups.glusterssl | join(',') }}"
    host: "{{ inventory_hostname …

Glusterfs 虽然是一个不错的分布式文件系统，但几乎没有提供监控其完整性的方法。服务器可以来来去去，砖块可能会变得陈旧或失败，我害怕知道这些可能为时已晚。

最近我们遇到了一个奇怪的故障，当一切正常时，但是一块砖从体积中掉了出来（纯属巧合）。

是否有一种简单可靠的方法（cron 脚本？）可以让我了解 GlusterFS 3.2卷的健康状况？

我最近一直在玩 glusterfs。

我想尝试以类似的方式在 glusterfs 之上运行 mysqld ，因为可以在 DRBD 之上运行MySQL。

我熟悉 MySQL 复制以及使用它代替这种方法的优势，我也知道 MongoDB 和其他 NoSQL 解决方案。

但是，如果我可以保留 MySQL 原样并复制底层文件系统，这将是我即将提出的一些特定项目的简单解决方案。

这是可能的，如果是的话，我在哪里可以找到方法？

过去 2 天我一直在玩 gluster，并在这里和他们的问题系统上提问。有些东西我真的不明白。我看到人们说这样的话

在服务器之间设置复制砖（因为你只使用 3 个，复制会更安全），每台服务器都会将所有其他服务器的文件视为“本地”——即使一台服务器出现故障，文件也已复制到其他服务器。

或者

Gluster 将保持跨卷（砖块）的文件同步，并具有“自我修复”功能，可以处理由于一台服务器离线而导致的任何不一致。

由于我将远程卷从服务器挂载到客户端，gluster 如何处理服务器节点的故障，卷是从哪个节点挂载的？从我尝试过的客户端上安装卷的文件夹变得无法访问，我必须使用 umount 来解除对它的阻止。之后没有来自服务器的内容。

这基本上是我在任何解释中都没有看到的内容：当服务器节点出现故障时会发生什么，以及是否可以像 unison 或 rsync 那样真正复制内容？

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

我们的文件流是这样工作的：

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

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 一致性将如何保持 …