Nginx负载均衡器排障实录【摘】

摘自：

---

---

这段时间，公司的web架构要升级，考虑用负载均衡；初期准备采用LVS+Keepalived，我比较有自信，刚刚在一个客户的局域网里实现了这个，所以直接把脚本移过来了；然而，杯具开始了，发现LVS怎么也实现不了后端二台web的转发。

后来关于此问题我请教了田逸兄，他怀疑我们的网络环境太复杂了，因为牵涉到内外网的问题，我们的每台机器上有5条静态路由，2个gateway，直接导致了LVS的不成功；我们试图跟network Engeneer沟通，结果是网络不能做一丝一毫改动，所以白白测试了二天。

后来改用了Nginx负载均衡器，5分钟就解决了问题，真真切切的体会到了Nginx对网络的依赖较小，理论上只要ping得通，网页访问正常，nginx就能连得通。为了以防万一，我采用的是Nginx+keepalived高可用架构。

在这里，我不是神话Nginx，只是说这是一种解决问题的方法而矣，LVS也有适用的场合，稳定性方面是众所周知的，所以只要提到web层的负载均衡，我就想到LVS，但LVS不仅仅是；如果网络环境比较复杂的朋友们，不妨换种思路解决问题。

当然用了Nginx后，大问题暂时没有；小问题就都来了，首先是SSL，这个目前支持得算是比较好的，在负载均衡器上开启ssl功能，监听443端口，将证书放在Nginx代理上，非后面的web服务器,轻构解决掉问题，详细见以下http.conf配置文件

server
    {
        listen  443;
        server_name

        ssl on;
        ssl_certificate /usr/local/nginx/keys/
        ssl_certificate_key /usr/local/nginx/keys/

        ssl_protocols  SSLv3 TLSv1;
        ssl_ciphers  ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:-LOW:-SSLv2:-EXP;
        }

但问题又来了，这么有个问题，跑在后方 apache 上的应用获取到的IP都是Nginx所在服务器的IP ，或者是本机 127.0.0.1 。最明显就是查看 apache 的访问日志。就会见到来来去去都是内网的IP；虽然可以通过Nginx日志来判断客户的client,但有些考虑不周全的应用，例如 Tattertools (一个博客程序) 就会犯误,后台的访问日志死活显示访客数 1，ip来自 127.0.0.1。这时候就要想办法来处理了。你可以通过修改 nginx proxy 的参数令后端应用获取到Nginx 发来的请求报文获取到外网的IP。

proxy_set_header        Host $host;
proxy_set_header        X-Real-IP $remote_addr;
proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;

这仅仅只是让Nginx获到到外网IP，Apache未必买帐呢，即Aapche端也需要设置，搜寻了一下，发现了apache这一个来自第三方的mod 配合Nginx proxy 使用。

说明：

下载：download/

最新版本是 mod_rpaf-0.6.tar.gz

安装也相当简单。

# tar zxvf mod_rpaf-0.6.tar.gz 下载后解压# cd mod_rpaf-0.6

Apache 的目录按自己的环境修改，并选择相应的安装方式：

#/usr/local/apache/bin/apxs -i -c -n mod_rpaf-2.0.so mod_rpaf-2.0.c  

完成后会在 http.conf  的 LoadModule 区域为你多加了一行。

LoadModule mod_rpaf-2.0.so_module modules/mod_rpaf-2.0.so 经 apache 2.2.6 的实验，使用这一行启动 apache 的时候会报错的。

所以改为：

LoadModule rpaf_module        modules/mod_rpaf-2.0.so

并在下方添加

RPAFenable On
RPAFsethostname On
RPAFproxy_ips 127.0.0.1 192.168.1.101 192.168.102

#填写Nginx所在的内网IP，Nginx的内网地址必写，不然一样失败的，这问题花了几个小时测试；有几个代理服务器的IP就写几个代理服务器的IP

RPAFheader X-Forwarded-For

保存退出后重启apache，再看看 apache 的日志内容？不再是来来去去的那几个IP了吧，呵呵。

另外这里来个小插曲，我做的某个小项目本为是基于Nginx的1+3架构，突然要加一台机器是windows2003系统，专门作存放图片及 PDF等，但项目的要求是能在nginx后的三台web上有显示图片及pdf下载的需求；当时迷糊了下，因为程序是用到的Zend Framwork，所以一直用正则作跳转；后来才想明白，IE程序是先在nginx负载均衡器上提申请，所以nginx.conf是做分发而非正则跳转，此时最前端的nginx，既是负载匀衡器也是反向代理，明白这个就好做多了，语法如下；另外注意location /StockInfo与location ~^/StockInfo的差异性，Nginx默认的是正则优先的，by the way,proxy_pass支持直接写IP的方式。

upstream mysrv {
    ip_hash;
    server 192.168.110.62;
    server 192.168.110.63;
    }

upstream myjpg {
    server 192.168.110.3:88;
    }


    server
    {
        listen 80;
        server_name web.tfzq.com;
        proxy_redirect off;

        location ~ ^/StockInfo{
        proxy_pass
}

再说下Nginx下的并发，这是个容易让人误会的概念。现在Nginx的文章满天飞，好像只要一涉及到web并发，就非将Apache换成nginx不可，其实完全没这必要；在内存足够的情况，Apache的抗并发能力也是很强的。玩了几年nginx了，遇到的最大并发也是以前在北京维护的CDN之广告网站，大约在3000-5000之间(这种情况建议用Nginx)，一般的资讯类金融网站也就100多，电子商务网站1100左右，web层的并发压力并没有想象中的大；相反，我感觉文件和数据层的压力越来越大，单个NFS服务器越来越难受了，所以我后期准备布署moosefs；而mysql数据库我一般用的是主从复制，压力也不小，目前只是从二方面来解决此问题：一、用公司最好的服务器来作数据库服务器；二、尽可能的优化，如果压力持续增长的话，后期我考虑从架构级方面优化了。对于一个网站而言，建议多从架构极的观念来看问题和解决问题。

今天一直测试网站的响应时间是用Linux/unix下工具httping,今天同事找了个专业网站给我，发现很好用，特的拿出来与大家共享可以测试个几十次然后取平均值，这样得出的结果较为精准；系统运维工作本来就是一个细腻活，有时短短几行代码，说不定就要调试几天；而有时维护的服务器日志，经常是十几万行，看得人心花缭乱...痛并快乐着，这也是算是目前工作的心态吧。