建立：
> 27TB Synology RS2212阵列,允许多个会话的iSCSI LUN /目标
> 10-20个基于CentOS的Linux机箱,主要是Web服务器
>共享存储将托管静态Web内容(媒体,主要是图像)
从本质上讲,我需要能够在许多Web服务器上安装这个大型共享卷,并且这个数字有望继续增长.我们过去一直在使用NFS,但性能问题迫使我们不得不考虑其他方法. (阅读：NFS调整有时会像黑魔法一样,特别是在处理数百万个小图像时).
通常情况下,设备上的写入冲突不应该存在问题,因为只有少数中央机器能够更改内容,但我知道如果我们这样安装它们,我们需要一些方法来当一个人正在使用它时锁定文件,这样我们就不会腐败.在过去,我们依靠NFS来处理这个问题.所以现在我正在寻找支持群集的文件系统(除非我遗漏了一些东西,因此这篇文章).
到目前为止,我已经找到了两个主要选择,但我不确定它们是否适合：
RHEL Clustering和GFS2 – 似乎非常适合我的环境,但它确实让我有点担心以这种方式“锁定”一个发行版.如果我需要添加具有不同风格的服务器,会迫使我提出其他选项.不是一个节目,但在我的脑海里.最大的担忧是从RHEL文档反复阅读其群集仅支持16个节点.如果是这样的话,对我来说肯定不会很好地扩展.这是准确的还是我读错了？
OCFS – 甲骨文的群集文件系统在我谷歌时也受到了很多关注,但我对此并不了解.最麻烦的是,我必须运行他们的Unbreakable Enterprise Kernel,这会导致将所有服务器移动到那里造成很大的中断.再次,不是一个显示阻止,但我需要有力的证据走这条道路,特别是在尝试这种方法时.
我错过了什么吗？我应该使用更好的方法吗？我甚至考虑完全改变架构以允许一些“前端”服务器安装iSCSI分区,然后根据需要从它们进行NFS共享,和/或使用Nginx反向代理将媒体分发给Web服务器.
有什么聪明的想法,你会信任在这种情况下使用？
解决方法
> Gluster.这是一个RH项目,因此在CentOS上得到了极好的支持,并且可以扩展到“批量”.成百上千的客户端是完全可行的,特别是在你似乎处于阅读沉重的环境中.我目前正在使用它与Ubuntu,因此在debian-land中有支持.
> Ceph.与Gluster一样,它是下一代网络文件系统,也提供直接安装功能.也是为“方式批量”缩放而设计的.它与Gluster之类的Red Hat无关.
两者目前都在云规模基础设施中使用.
像gfs2和ocfs这样的直接挂载文件系统确实存在扩展瓶颈.跨系统文件锁定问题,更不用说跨主机缓存一致性,很难解决,并且是主要的扩展问题.出于同样的原因,VMware的VMFS等其他集群文件系统也具有“小数十”的最大安装限制.
