我正在尝试确定用于共享存储设备的文件系统的“最佳选择”，该存储设备将通过 iSCSI 安装在数量不确定的服务器上。
设置：
- 27TB Synology RS2212+ 阵列，允许多个会话的 iSCSI LUN/目标
- 10-20 个基于 CentOS 的 Linux 机器，主要用于网络服务器
- 共享存储将托管静态 Web 内容（媒体，主要是图像）
本质上，我需要能够在多个 Web 服务器上安装这个大型共享卷，并且希望随着时间的推移，这个数字会继续增长。我们过去一直在使用 NFS，但性能问题迫使我们研究其他方法。（阅读：NFS 调整有时感觉像黑魔法，特别是在处理数百万个小图像时）。
通常情况下，设备上不会出现写入冲突问题，因为只有少数中央机器能够更改内容，但我知道如果我们以这种方式安装它们，我们需要某种方法来在处理文件时锁定文件，以免最终导致损坏。过去，我们依靠 NFS 来处理这个问题。所以现在我正在研究集群感知文件系统（除非我遗漏了什么，因此写了这篇文章）。
到目前为止，我发现了两个主要选择，但我不确定它们是否非常适合：
RHEL 集群和 GFS2-- 似乎很适合我的环境，但以这种方式“锁定”发行版确实让我有点担心。如果我需要添加具有不同风格的服务器，这将迫使我提出其他选择。虽然不是特别令人担忧，但我一直在考虑。最大的担忧是从 RHEL 文档中反复读到他们的集群仅支持 16 个节点。如果是这样的话，它肯定不会很好地扩展到我。这是准确的还是我读错了？
OCFS——Oracle 的集群文件系统当我用谷歌搜索时，它也引起了很多关注，但我对此了解不多。最麻烦的是，我必须运行他们的 Unbreakable Enterprise Kernel，这会在将我的所有服务器迁移到那里时造成很大的干扰。同样，这不是一个大问题，但我需要令人信服的证据来走这条路，特别是在尝试这种方法时。
我是不是漏掉了什么？有没有更好的方法可以采用？我甚至考虑过彻底改变架构，让一些“前端”服务器挂载 iSCSI 分区，然后根据需要从它们进行 NFS 共享，和/或使用 nginx 反向代理将媒体分发给 Web 服务器。
您有什么聪明的想法可以信任并应用于这种场景吗？
答案1
对于您的情况，我仍然坚持使用网络文件系统。您已经遇到了 NFS 的扩展问题，因此是时候考虑其他东西了。有几个不错的选择：
- 格鲁斯特。这是一个 RH 项目，因此在 CentOS 上得到了极好的支持，并且可以扩展到“很多”。数百/数千个客户端是完全可行的，尤其是在像您这样的读取密集型环境中。我目前正在将它与 Ubuntu 一起使用，因此在 debian-land 中得到支持。
- 头孢。与 Gluster 一样，它是下一代网络文件系统，也提供直接安装功能。还设计用于“多路复用”扩展。它不像 Gluster 那样与 Red Hat 绑定。
两者目前均在云规模基础设施中使用。
直接挂载文件系统（如 gfs2 和 ocfs）确实存在扩展瓶颈。跨系统文件锁定问题（更不用说跨主机缓存一致性问题）相当难以解决，并且是主要的扩展问题。出于同样的原因，其他集群文件系统（如 VMware 的 VMFS）也有“小十”最大挂载限制。
非 NFS 的网络文件系统被设计为可扩展到非常大的并发量。我上面提到的选项都具有复制甚至分布式卷支持，以帮助防止单点故障。
答案2
您可以使用灵活而强大的解决方案，该解决方案支持集群、多路径、多路复用和缓存，例如带有 SF-CACHE 的 VXFS (Veritas Storage Fundation)。如果您改进了写入冲突或 fs 损坏，则可以使用 VXFS 的重做日志重建文件系统，并且如果存在某些硬件 lun 错误，还可以重建已划伤的磁盘组。
PS：+OCFS 是为 Oracle Cluster DATABASE 设计的，不是为 webapps 设计的！