我目前正在尝试为基于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
