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