跨水平扩展的 Web 服务器共享文件上传目录的最佳方式

Question

我目前正在尝试为基于 drupal 的 Web 应用程序指定一个水平可扩展的集群，它看起来像下面的彩色图表：

负载平衡器实现粘性会话，因此用户在分配了要使用的服务器后保持状态。

每个应用服务器都有以下内容：

• 在前面清漆
• 中间的 drupal 6 在灯组上运行
• 内存缓存在后面

两台 mysql 数据库服务器在一个共享 IP 上，它们在一个带有 DRBD 和心跳的 HA 集群中，因此丢失一个不会导致整个平台瘫痪。

有几件事我不确定，我会很感激你的意见：

文件存储应该如何横向扩展？

我正在考虑使用 NFS 在每个应用程序服务器上挂载一个共享文件目录，因此一次上传的文件在所有应用程序服务器上都可用。我在考虑 NFS，因为它已经存在了很长时间，而且我没有使用 MogileFS 或 GlusterFS 的经验，而且我们以前使用过它，所以我们更熟悉它。

是否有任何指导方针可以用来确定以这种方式通过 NFS 共享目录是明智的？

这里的共享文件存储应该如何提供HA？

这里的一个问题是 NFS 服务器是单点故障。

我们已经在 Mysql 服务器上使用 Heartbeat 和 DRBD，我更愿意保持堆栈中涉及的技术数量尽可能少 - 如果我对文件使用相同的 HA 策略会有什么陷阱服务器也是？

另一种方法

这适用于面向内部的站点，当内部计划启动时，用户数量有限，偶尔会在短时间内非常密集地使用该站点。所以这不需要像某些初创公司那样无限扩展。

鉴于

• 我们可以预期的流量有上限
• 将 HA 添加到文件服务器，并设计一个设置以像这样水平扩展会带来相当大的复杂性

我还在考虑让两个 Web 服务器更强大，以便它们可以处理它们之间的峰值负载，并在 cron 作业中设置一致或在两者之间进行 rsync，以便：

• 他们的文件仍然保持同步（粘性会话将用户保持在他们上传文件的同一服务器上）
• 丢失一个意味着该站点仍在运行。

这听起来像是绕过任何可能的 NFS/DRBD HA 复杂性问题的可能方法吗？

谢谢，

C

Answer 1

NFS 服务器至少必须具有与 MySQL 服务器相同的配置，因为它们具有基本相同的功能和限制（都是写入数据的地方）。我不喜欢 NFS 的多个写入者的想法，这使得管理文件锁变得非常复杂，而且我的经验在这一点上并不顺利。

我的建议是将所有写入集中在一台应用程序服务器上（也许有一个应用程序服务器专门用于在 NFS 服务器上写入），并将多个读取器应用程序服务器安装为只读（我知道 drupal 有一些动态缩略图，需要被写入，但您可以将大部分内容保留在 RO fs 上）。您至少需要第二个 NFS 服务器（如果您没有 SAN 等共享存储，那么使用 DRBD 是最佳选择）来确保 HA。

最后，看一下 Gluster 和其他分布式系统。