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

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

负载均衡器实现了粘性会话,因此用户一旦分配了服务器就会保持状态.

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

>前面的清漆
>中间的drupal 6在灯堆上运行
> memcached在后面

这两个mysql数据库服务器位于共享IP上,并且它们位于具有DRBD的HA群集中,并且听到了声音,因此丢失一个不会导致整个平台崩溃.

有一些我不确定的事情,我很感激你的意见：

文件存储应该如何水平扩展？

我正在考虑使用NFS在每个应用服务器上安装共享文件目录,因此在所有应用服务器上都可以使用一次上传的文件.我正在考虑NFS,因为它已存在很长时间了,而且我没有MogileFS或GlusterFS的经验,这是我们之前使用的东西,所以我们对它更熟悉.

是否有任何指导方针可以通过这种方式计算出通过NFS共享目录的明智服务器数量？

如何在共享文件存储上提供HA？

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

我们已经在Mysql服务器上使用了Heartbeat和DRBD,我宁愿尽可能降低堆栈中涉及的技术数量 – 如果我对文件使用相同的HA策略会有什么陷阱服务器呢？

另一种方法

这是针对面向内部的网站,当内部计划启动时,有限数量的用户偶尔会在短时间内非常密切地使用网站.所以这不需要像一些初创公司那样无限扩展.

鉴于

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

我也在考虑让这两个Web服务器更强大,以便它们可以处理它们之间的峰值负载,并在cron作业上设置unison或rsync,以便：

>他们的文件仍处于同步状态(粘性会话使用户在他们上传文件的同一台服务器上)
>失去一个意味着该网站仍在运营.

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

谢谢,

C

解决方法

NFS服务器至少具有与 MySQL服务器相同的配置,因为它们具有基本相同的功能和限制(两者都是您向其写入数据的位置).我不喜欢NFS的多个编写器的想法,它使管理文件锁非常复杂,我的经验在这一点上并不是很好.

我的建议是将所有写入集中在其中一个应用服务器上(可能有一个专用于在NFS服务器上写入的应用服务器)和多个读取器应用服务器将其安装为只读(我知道drupal有一些动态缩略图需要写的,但你可以在RO fs上保留最多.您将需要至少第二个NFS服务器(如果您没有像SAN这样的共享存储,则使用DRBD是最佳选择)以确保HA.

最后,看看Gluster和其他分布式系统.