这个论坛一直通过NFS服务共享文件给三台web服务器做负载均衡.
在实际环境中WEB Server总是出现CPU负载突然升高、文件交互的网络流量异常、甚至WEB Server夯死，NFS不能卸载，只能重启才能解决。尝试优化NFS没有明显效果。
在文件服务器一次宕机之后，决定改造现有系统。
1、去NFS Server的单中心节点，提升系统可用性。
2、做动静分离，将论坛的图片、种子、压缩包等附件分离，还可以利用其他项目已购买的CDN服务提升图片下载速度。
设计了两种方案：
一、利用MFS、FastDFS等分布式文件系统。MFS使用方便，但是有单点故障。FastDFS还挺不错的，缺点是应用上需要改动的太多。
二、现有架构上不需要调整增加服务器，利用脚本、ftp，修改附件上传的代码，在最小投入就能实现目标。缺点就是文件服务出现问题，恢复之前不能上传附件。
基于成本的考虑最后选择了第二种方案。从实际运行状况来看，这个也是最优的方案。不需要购买服务器，不需要对程序代码做大的改动，而且维护量小，稳定可靠。
改造后的架构图：
下面详细说说架构原理：
1、 将附件、和代码上传改为FTP方式上传（这里需要做开发的同学配合下了），在File Server通过VsFTP接收附件和代码更新。
2、 在停用NFS服务后，做了一个代码同步系统（工具是rsync）。计划任务每隔5分钟WEB Server同步File Server的代码，当然非代码目录、附件目录除外，这样需要同步的文件量非常小。同步耗时秒级别。
3、 所有附件和代码都会更新到File Server。File Server利用sersync实时将文件的所有更新同步到备份的File Server端。两个File Server是同时使用Nginx提供附件HTTP服务的。
4、 在两台File Server负载均衡提供附件下载服务时，可能会出现新上传的文件在备份File Server上找不到的情况。这个时候在前段Nginx代理配置proxy_next_upstream 将404跳转到另一台服务器就可以了。
相关配置：
Nginx的配置
upstream img_hapth {
server 192.168.200.29:80;
server 192.168.200.28:80;
}
server {
listen 80;
server_name img.hapath.com;
access_log /data/logs/access.log main;
error_log /data/logs/error.log;
location / {
proxy_next_upstream error timeout http_404;
proxy_pass http://img_hapath;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
}
Sersync的使用，请见http://code.google.com/p/sersync/，这个程序貌似金山的一个同学写的，但是已经很久不更新了。有两个bug要注意，一个是程序有时候会自己终结；一个是已经同步的文件仍然会写到/tmp/rsync_fail_log.sh文件，这个是它的失败日志。而且它的失败日志是一个有执行权限的shell脚本，日志内容也是可命令，是一个安全隐患。所以俺在备份File Server每隔12小时整体同步一次数据，改了日志目录，并且做了一个检测脚本监控sersync的运行状况。
红框中是改造之前，性能不稳定，经常出现异常。前后对比很明显。
这是一个很简单的架构改造，但是效果却非常好。很多时候为了解决问题，费了很多时间做大的系统架构，增加服务器，增加维护量，改变应用。换个角度，大并不一定美。