跨水平缩放Web服务器共享文件上载目录的最佳方法

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

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

每个应用程序服务器具有以下内容：

• 正面清漆
• drupal 6在中间运行在灯堆上
• 内存缓存在后面

两台mysql数据库服务器位于共享IP上，它们位于具有DRBD和listenbeat的HA群集中，因此，丢失一台将不会破坏整个平台。

对于您不确定的几件事，我不确定。

文件应如何水平扩展？

我正在考虑使用NFS在每个应用程序服务器上安装共享文件目录，因此所有位置都可以使用一次上传的文件。我之所以想到NFS，是因为它已经存在了很长时间，并且我没有使用MogileFS或GlusterFS的经验，并且它是我们以前使用过的东西，因此我们对其更加熟悉。

是否有任何可遵循的准则来确定以这种方式通过NFS共享目录的服务器数量是多少？

应该如何在此处的共享文件存储中提供HA？

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

我们已经在Mysql服务器上使用Heartbeat和DRBD，并且我希望将堆栈中涉及的技术数量保持在尽可能低的水平-如果我对文件使用相同的HA策略，将会有什么陷阱服务器呢？

另一种方法

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

鉴于

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

我也在考虑使两个Web服务器变得更强大，以便它们可以处理它们之间的峰值负载，并在cron作业中设置统一或rsync，以便：

• 它们的文件仍保持同步（粘性会话使用户保持与文件上传到的服务器相同）
• 丢失一个表示该站点仍在运行。

这听起来像是解决任何可能的NFS / DRBD HA复杂性难题的可行方法吗？

谢谢，

C

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

我的建议是将所有写入都集中在一个应用程序服务器上（也许有一个应用程序服务器专门在NFS服务器上进行写入），而多个读取器应用程序服务器将其安装为只读（我知道drupal具有一些动态缩略图需要编写，但您可以将其大部分保留在RO fs上）。您至少需要第二台NFS服务器（如果没有像SAN这样的共享存储，最好使用DRBD）来确保HA。

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

您可以尝试mogileFS。我曾经将它用作我们的项目。它易于使用和配置，并且可以扩展，并且没有单点故障。

http://danga.com/mogilefs/

最好的方法是找到一个好的存储解决方案。根据应用程序的规模和类型，您可以使用性能良好的NAS，并支持NFS以及至少两个千兆端口和电源（请检查某些企业解决方案）。

如果您真的对应用程序很认真，那么最好的选择就是检查一些SAN解决方案，但这可能会非常昂贵，因为它需要特殊的硬件（可以使用现成的硬件来完成，但可能太慢了）。