我们在硬件负载均衡器后面有许多
Linux Web服务器,它们为单个网站提供服务.
需要访问者能够上传文件.这些文件的大小通常为300-700KB,我们预计其中有100万个.但是,这会带来一个明显的问题：如果用户将文件上传到处理其请求的服务器,我们如何保持所有服务器同步？
延迟应该是最小的,因此在设定的时间表上使用像rsync这样的东西并不是一个真正的选择.应该没有单点故障,因此NFS不适合,除非它与DRBD结合以创建故障转移NFS服务器.
我已经研究过共享/集群文件系统(GlusterFS,MogileFS,OCFS2和GFS),但没有这方面的经验,所以我不确定它们在生产环境中的性能和可靠性如何.
我欢迎任何关于如何最好地解决这个问题的建议.
非常感谢
解决方法
通过DRBD的GFS2 / OCFS2允许一对服务器作为集群存储运行双主服务器.您的网络前端会从该共享对中拉出来.您可以使用多个磁头共享单个FC连接介质,或者可以使用NFS来使用每个Web前端使用的单个共享文件系统.如果将NFS与DRBD一起使用,请记住,由于缺少群集锁,您只能在主/辅助模式下运行它.这可以将您的潜在吞吐量减少一半.
GlusterFS听起来更像你正在寻找的东西.它会有一些独特的怪癖,即在尚未拥有它的节点上请求的文件,元数据查找说它存在,它从一个复制节点传输然后提供.在节点上首次请求将有一些延迟取决于文件大小.
OpenAFS也是另一种可能性.您有共享存储,每个本地资源都有一个最近使用过的项目的本地池.如果存储引擎发生故障,您的本地资源池仍可用.
Hadoop的HDFS是另一种“有效”的选择.设置有点复杂,但也符合您的要求.使用分布式文件系统时,您将拥有大量重复内容.
另一种脏方法是在每个Web前端上运行缓存,从单个机器上提取静态/上传内容,并在每个前端使用Varnish来维护单个副本的ram缓存版本.如果您的单台机器出现故障,Varnish将缓存现有项目,直到宽限期,新项目将丢失.
其中大部分将基于您需要的后端的可靠性.本地计算机是复制节点的分布式文件系统可能会有速度优势,因为它们不涉及网络操作来获取数据,但是,由于gigE和10G卡很便宜,您可能不会遇到明显的延迟.
