应用总结:关于Nginx负载均衡器的思考
2013-05-13 22:11
288 查看
关于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邮箱对应了手机号码,所以此时手机将会收到报警信息,达到预警目的。
在项目实施过程中发现,业务系统最前端的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邮箱对应了手机号码,所以此时手机将会收到报警信息,达到预警目的。
相关文章推荐
- 关于负载均衡的一切:总结与思考
- 关于每日学习效率的思考(小总结)
- Android关于ThreadLocal的思考和总结
- Atitit 关于微服务的思考与理解 attilax总结 1.1. 架构的历史 微服务发展历史 Web》soa》msa 1 1.2. 微服务最大特点 独立部署 1 2. 微服务的优点 1 2.1.
- WINCE应用层设计经验总结-关于当前时间显示和当前时间获取
- 关于 HTML5 应用现状与前景的思考
- 关于响应式布局的总结与思考(一)-常识介绍
- nginx应用总结(2)--突破高并发的性能优化
- 应用库后关于_OBJC_CLASS_$_文件referenced from:objc-class-ref in报错的测试总结
- 【C++学习与应用总结】2: 关于类型前置声明
- 关于课程设计、毕业设计的一些总结与思考
- 关于LVS+Nginx为什么会被同时使用的思考
- 关于工业4.0和智能制造的总结以及背后的思考
- 关于互联网应用前端架构的一些思考
- JS关于this的思考和总结
- 也谈谈关于WEB应用访问权限的思考
- 关于机器学习应用的一些思考
- LVS、Nginx和HAProxy负载均衡器对比总结
- 关于用上线IOS上线的一些总结与思考
- 关于一个小应用软件的思考