iSCSI 共享存储的 Linux 文件系统选项

Question

我正在尝试确定用于共享存储设备的文件系统的“最佳选择”，该共享存储设备将通过 iSCSI 安装在不确定数量的服务器上。

设置：

• 27 TB Synology RS2212+ 阵列，允许多个会话的 iSCSI LUN/目标
• 10-20 个基于 CentOS 的 linux 机器，主要是网络服务器
• 共享存储将托管静态 Web 内容（媒体，主要是图像）

从本质上讲，我需要能够在许多网络服务器上安装这个大的共享卷，而且这个数字有望随着时间的推移而继续增长。我们过去一直在使用 NFS，但性能问题迫使我们寻找其他方法。（阅读：NFS 调优有时感觉像是黑魔法，尤其是在处理数百万个小图像时）。

通常情况下，设备上的写冲突不应该有问题，因为只有少数中央机器能够更改内容，但我知道如果我们这样安装它们，我们需要一些方法来在使用文件时锁定文件，这样我们就不会以损坏而告终。过去，我们依靠 NFS 来处理这个问题。所以现在我正在研究集群感知文件系统（除非我遗漏了一些东西，因此这篇文章）。

到目前为止，我为此找到了 2 个主要选择，但我不确定它们是否非常合适：

RHEL Clustering 和 GFS2 -- 似乎很适合我的环境，但是以这种方式“锁定”到发行版确实让我有点担心。如果我需要添加不同风格的服务器，会迫使我提出其他选项。不是表演障碍，而是在我的脑海中。最大的担忧是从 RHEL 文档中反复阅读他们的集群仅支持 16 个节点。如果是这样的话，它对我来说肯定不够好。这是准确的还是我读错了？

OCFS - Oracle 的集群文件系统我google的时候也很受关注，但是我对它了解不多。最麻烦的方面是我必须运行他们的 Unbreakable Enterprise Kernel，这会在将我的所有服务器迁移到该内核时造成大量中断。再一次，不是表演障碍，但我需要令人信服的证据来走这条路，尤其是在尝试这种方法时。

我错过了什么吗？我应该使用更好的方法吗？我什至考虑过完全改变架构以允许一些“前端”服务器挂载 iSCSI 分区，然后根据需要从它们进行 NFS 共享，和/或使用 nginx 反向代理将媒体分发给网络服务器.

在这种情况下，您有任何值得信赖的聪明想法吗？

Answer 1

对于您的情况，我仍然坚持使用网络文件系统。您已经遇到了 NFS 的扩展问题，所以是时候看看别的东西了。有几个不错的选择：

• 格鲁斯特。这是一个 RH 项目，因此在 CentOS 上得到了极好的支持，并且可以扩展到“很多”。成百上千的客户端是完全可行的，尤其是在像您这样的读取繁重的环境中。我目前正在 Ubuntu 中使用它，因此在 debian-land 中有支持。
• 头孢。与 Gluster 一样，它是下一代网络文件系统，也提供直接挂载功能。也专为“路批”缩放而设计。它不像 Gluster 那样与 Red Hat 相关联。

两者目前都用于云规模的基础设施。

像 gfs2 和 ocfs 这样的直接挂载文件系统确实存在扩展瓶颈。跨系统文件锁定问题，更不用说跨主机缓存一致性问题了，它很难解决并且是主要的扩展问题。出于同样的原因，其他集群文件系统，如 VMware 的 VMFS，也有“小十”的最大挂载限制。

非 NFS 的网络文件系统旨在扩展到非常大的并发。我上面提到的选项都有重复甚至分布式卷支持，以帮助防止单点故障。