处理用户上传到 Web 服务器集群

Question

我们在硬件负载平衡器后面有许多 Linux Web 服务器，它们为单个网站提供服务。

访问者需要能够上传文件。这些文件的大小通常为 300-700 KB，我们预计其中有 100 万个。然而，这带来了一个明显的问题：如果用户将文件上传到处理他们请求的服务器，我们如何保持所有服务器同步？

延迟应该是最小的，所以在设定的时间表上使用 rsync 之类的东西并不是一个真正的选择。也不应该有单点故障，因此 NFS 不适合，除非它与 DRBD 结合创建故障转移 NFS 服务器。

我研究了共享/集群文件系统（GlusterFS、MogileFS、OCFS2 和 GFS），但没有这些经验，所以我不确定它们在生产环境中的性能和可靠性如何。

我欢迎任何关于如何最好地解决这个问题的建议。

非常感谢

Answer 1

通过 DRBD 的 GFS2/OCFS2 允许一对服务器作为集群存储运行双主服务器。您的网络前端将从该共享对中获取。您也可以使用任一方式让多个头共享单个 FC 连接媒体，或者可以使用 NFS 来让每个 Web 前端使用单个共享文件系统。如果您将 NFS 与 DRBD 一起使用，请记住，由于缺少集群锁，您只能在主/辅助模式下运行它。这可能会将您的潜在吞吐量减少一半。

GlusterFS 听起来更像你正在寻找的东西。它将有一些独特的怪癖，即在尚不具有该文件的节点上请求文件，元数据查找表明它在那里，它从复制节点之一传输，然后提供服务。第一次在节点上请求时会有一些延迟，具体取决于文件大小。

OpenAFS 也是另一种可能性。您拥有共享存储，每个本地资源都有一个最近使用的项目的本地池。如果存储引擎出现故障，您的本地资源池仍然可以使用。

Hadoop 的 HDFS 是另一种“可行”的替代方案。设置起来有点复杂，但是也能满足您的要求。使用分布式文件系统时，您将有很多重复的内容。

另一种肮脏的方法是在每个 Web 前端上运行缓存，从单个计算机中提取静态/上传的内容，并在每个前端上使用 Varnish 来维护单个副本的内存缓存版本。如果你的单台机器出现故障，Varnish会缓存现有的项目，直到宽限期，新的项目将丢失。

这很大程度上取决于您需要的后端的可靠性。本地计算机作为复制节点的分布式文件系统可能会在速度上具有优势，因为它们不涉及获取数据的网络操作，但是，由于 gigE 和 10G 卡很便宜，您可能不会遇到明显的延迟。