我们在硬件负载均衡器后面拥有多个 Linux 网络服务器，为单个网站提供服务。
访客需要能够上传文件。这些文件的大小通常为 300-700KB，我们预计大约有 100 万个。然而，这带来了一个明显的问题：如果用户将文件上传到处理其请求的服务器，我们如何保持所有服务器同步？
延迟应该最小，因此按设定的时间表使用 rsync 之类的东西并不是一个真正的选择。还应该没有单点故障，因此 NFS 不适合，除非将其与 DRBD 结合以创建故障转移 NFS 服务器。
我研究过共享/集群文件系统（GlusterFS、MogileFS、OCFS2 和 GFS），但没有使用过这些，所以不确定它们在生产环境中的性能和可靠性如何。
我欢迎任何有关如何最好地解决该问题的建议。
非常感谢
答案1
通过 DRBD 的 GFS2/OCFS2 允许一对服务器以集群存储的形式运行双主服务器。您的 Web 前端将从该共享对中提取数据。您也可以让多个机头共享单个 FC 连接介质，或者可以使用 NFS 让每个 Web 前端使用单个共享文件系统。如果您将 NFS 与 DRBD 一起使用，请记住，由于缺少集群锁，您只能在主/辅助模式下运行它。这可能会将您的潜在吞吐量减半。
GlusterFS 听起来更像您要找的东西。它会有一些独特的怪癖，即在尚未拥有该文件的节点上请求文件，元数据查找显示它在那里，它会从其中一个复制节点传输然后提供服务。第一次在节点上请求时会有一些滞后，具体取决于文件大小。
OpenAFS 也是另一种可能性。您有共享存储，每个本地资源都有一个最近使用项目的本地池。如果存储引擎出现故障，您的本地资源池仍可提供服务。
Hadoop 的 HDFS 是另一种“可用”的替代方案。设置起来有点复杂，但也能满足您的要求。使用分布式文件系统时，您将会有很多重复的内容。
另一种肮脏的方法是让每个 Web 前端都运行缓存，从一台机器上提取静态/上传的内容，并在每个前端上使用 Varnish 来维护单个副本的内存缓存版本。如果您的单台机器发生故障，Varnish 会缓存现有项目，直到宽限期结束，新项目将会丢失。
这在很大程度上取决于您需要的后端的可靠性。分布式文件系统（您的本地机器是复制节点）可能在速度上具有优势，因为它们不涉及网络操作来获取数据，但是，由于千兆以太网和 10G 卡价格便宜，您可能不会遇到明显的延迟。
答案2
所有集群文件系统都有一个主要弱点：如果一定比例的系统离线，那么整个文件系统就毫无用处，但仍然运行的节点可能无法妥善处理它。
例如，假设机架中有 30 台服务器，并且希望共享它们的本地空间。您构建了一个集群文件系统，甚至构建了它，以便即使只有一个节点发生故障，数据也会复制到足够多的其他节点上，不会出现问题。到目前为止一切顺利。然后以太网交换机中的一张卡坏了。此交换机将集群中的所有节点互连。该卡切断了与 30 个节点中的 15 个节点的通信。您需要问自己的问题是：
- 如果您觉得这种情况可以接受，那么故障有多大程度上可以接受？进程是否会挂起直到通信恢复，还是您必须登录并重新启动每个系统才能重新获得控制权？
- 当您的机架出现交换机或电源故障时，您的客户会让您自食其果吗？如果是这样，请考虑将您的节点分散到整个数据中心，或让每个节点接入两个交换机并绑定接口。还需要进行一些交换机魔法，因此请找一位网络管理员。
设想一下，在以下情况下系统会采取哪些措施：任何主要部件，包括网络或电源线。
现在，您已经准备好使用集群文件系统以及了解之前不知道的数百万个新术语。
答案3
我们要么使用 NetApp 盒子中的 NFS，要么使用 FC LUN 上的 OCFS2 卷，我不知道它们是否是最佳选择，但多年来它们一直为我们服务。当然，这两种方法都表现得非常完美，尽管我个人更喜欢 OCFS2 而不是 FC LUN 选项，因为我实际上更擅长存储。我想这实际上取决于您已经拥有并习惯的共享存储基础设施。