谈Nginx负载均衡器的一些问题

关于nginx的负载均衡软件配置很多朋友都有接触过。但是，对于硬件产品，由于其高昂的费用，接触的人相对较少一些。后来，笔者在网上发现了一篇文章，写的是关于Nginx负载均衡器的一些思考问题。那么，对于这个硬件产品的一些看法，很值得大家一起来探讨。

Nginx负载均衡器的总结和思考

在项目实施过程中发现，业务系统最前端的Cisco　PIX535防火墙的外网IP映射的是内网Nginx负载均稀器的内网IP（DNAT），这时的Nginx负载均衡器的作用相当于整套系统的枢纽，如果该服务器发生故障，会导致整个网站无法访问，所以我们需要二台以上的Nginx负载均稀器，以实现故障转移和高可用性。

实现的办法有如下：

一、二台Nginx负载均衡器通过Keepalived形成高可用，防火墙映射的是Keepalived形成的vip地址；keepalived是lvs的扩展形式，部署起来非常容易，成熟的案例在sina等企业也得到应用；但Keepalived做不到监控nginx服务级别，即如果nginx服务崩溃了，Keepalived也没有办法，虽然可以通过Heartbeat来解决这个问题，但Heartbeat本身就存在着裂脑情况，所以目前我只是将Heartbeat用于内部测试环境，生产环境我仍然是用Keepalived。

二、最前端不用Cisco防火墙映射，而用F5代替；第二层用二台或二台以上的Nginx负载均衡器，第三层才是web集群。

这样的好处很明显：不存在单点Nginx负载均衡出现故障问题。

同样缺点也很明显：整个工程的成本增加，你的客户和老板很可能非常不满意。

三、张宴兄采用的办法是用DNS轮询，二台Nginx负载均衡器均提供一个虚拟的外网IP对应用DNS（应用环境为逍遥网xoyo．com），二台Nginx上的故障转移通过自身的shell脚本来实现，具体请参见张宴的《实战Nginx－取代Apache的高性能web服务器》一书。方案很实用，而且也是线上环境，但美中不足的是我手上的证券系统，都只有IP，并无DNS域名对应，看来这个需要跟券商谈判争取了。

四、目前我手上跑的三套在线系统都是单机Nginx，是由于券商都有值班人员和监控系统Nagios，但这样会增加生产成本。

我目前想的一个办法是：

在Nginx负载均衡器上开启sendmail服务，运行一个监控shell脚本，每2－5分钟就wgethttp：／／172．16．110．61／test．php（为了避免Cisco防火墙某些技术上的限制，这里采用内网IP形式）即2分钟或5分钟就自动去获取一次后端web的某网页一次，如果正常就啥也不做；如果发生异常情况，就向我的139邮箱发送Ctritical警报。因为139邮箱对应了手机号码，所以此时手机将会收到报警信息，达到预警目的。