我目前正在尝试为基于 drupal 的 Web 应用程序指定一个水平可扩展的集群，它看起来类似于下面的彩色图表：
负载平衡器实现了粘性会话，因此一旦为用户分配了可用的服务器，他们就会保持状态。
每个应用服务器均具有以下内容：
- 正面涂有清漆
- drupal 6 在 lamp stack 上运行
- memcached 在后面
两个 mysql 数据库服务器位于共享 IP 上，并且它们位于具有 DRBD 和 heartbeat 的 HA 集群中，因此丢失一个服务器不会导致整个平台崩溃。
有几件事我不太确定，希望听听你的意见：
文件存储应如何水平扩展？
我正在考虑使用 NFS 在每个应用服务器上安装一个共享文件目录，这样在一个位置上传的文件就可以在所有服务器上使用。我之所以考虑使用 NFS，是因为它已经存在很久了，而且我没有使用过 MogileFS 或 GlusterFS，我们以前用过，所以我们对它比较熟悉。
是否有任何指导原则可供遵循，用于确定有多少台服务器可以通过这种方式共享目录？
这里的共享文件存储应如何提供 HA？
这里的一个问题是 NFS 服务器是单点故障。
我们已经在 Mysql 服务器上使用 Heartbeat 和 DRBD，并且我希望将堆栈中涉及的技术数量保持在尽可能低的水平 - 如果我也对文件服务器使用相同的 HA 策略，会有什么缺陷？
另一种方法
这是面向内部的网站，用户数量有限，在开展内部计划时，偶尔会在短时间内非常频繁地使用该网站。因此，它不需要像某些初创公司那样无限扩展。
鉴于
- 我们预期的流量有一个上限
- 为文件服务器添加 HA，并设计一个像这样的水平扩展设置，会带来相当大的复杂性
我还正在考虑使两个 Web 服务器更加强大，以便它们能够处理它们之间的峰值负载，并在 cron 作业上在两者之间设置 unison 或 rsync，以便：
- 它们的文件仍然同步（粘性会话使用户保持在他们上传文件的同一服务器上）
- 失去一个意味着该网站仍在运行。
这听起来像是解决 NFS/DRBD HA 复杂性问题的一种可能方法吗？
谢谢，
C
答案1
NFS 服务器至少要具有与 MySQL 服务器相同的配置，因为它们具有基本相同的功能和限制（两者都是写入数据的地方）。我不喜欢 NFS 有多个写入者的想法，这会使文件锁的管理变得非常复杂，而我在这方面的体验并不好。
我的建议是将所有写入集中在其中一个应用服务器上（也许有一个应用服务器专门用于在 NFS 服务器上写入），并将多个读取器应用服务器安装为只读（我知道 drupal 有一些需要写入的动态缩略图，但您可以将大部分内容保留在 RO fs 上）。您至少需要第二个 NFS 服务器（如果您没有像 SAN 这样的共享存储，使用 DRBD 是最佳选择）以确保 HA。
最后，看一下 Gluster 和其他分布式系统。
答案2
您可以尝试 mogileFS。我曾经在我们的一个项目中使用过它。它易于使用和配置，可以扩展，并且没有单点故障。
答案3
最好的方法是找到一个好的存储解决方案。根据应用程序的规模和类型，您可以使用一个好的 NAS，支持 NFS 和至少两个千兆端口和电源（查看一些企业解决方案）。
如果您对您的应用程序真的很认真，那么最好的选择是检查一些 SAN 解决方案，但这可能非常昂贵，因为它需要特殊的硬件（它可以使用现成的硬件来完成，但它可能太慢了）。