几个负载均衡器的小结 推荐
2014-02-09 23:42
316 查看
之前负责过公司webcdn相关的设计和维护工作,同时做了些应用运维方面的工作,简单谈几个我对接触过的几款负载均衡器的了解:1.keepalived 使用vrrp实现高可用,可以理解成是IP层的高可用,虚拟出一个vip来实现高可用的功能。实际应用时主要是两两组合,提供两个vip,在一台挂掉后可以自动转移至另一台服务。比较常见的问题是脑裂问题和ip转移后的arp问题,第一种问题可以通过tcpdump快速定位rc(要抓vrrp协议),第二种情况可以使用arping的脚本解决(keepalived 的notify_master设置)。 基本上没有性能上的问题。
2.lvs 线上用的比较多的一种负载均衡器,内核态转发型的高可用工具,可以看做是tcp层的负载均衡器,主要原理就是对tcp的报文做些更改,然后进行转发,支持的状态检测方法也比较完善,有端口检测,url检测和自定义脚本检测。 实际应用中一般是用lvs的dr模式,配合keepalived使用,keepalived提供主机的高可用,lvs提供应用的高可用,lvs采用url的检测方式(避免端口ok但是应用挂起的情况,比如java应用的gc)。 比较常见的问题是realserver被踢出的问题,可以通过在lvs部署监控并根据检测方法部署相关的检测脚本(网络检测,端口检测,url检测)来找到问题的rc。 很少能遇到性能的问题,在包量很大的情况下(几十万/s),可能会遇到网卡ring buffer和网卡中断的问题,可以通过丢包率和mpstat来定位,ring buffer问题可以尝试增加网卡的ring buffer设置解决,中断问题可以采用centos5.8以上的内核配合多队列(必须)来解决。
3.nginx 现在主流的反向代理软件,可以通过代理的功能实现负载均衡的功能,本身功能比较完善,既可以做静态站点,缓存又可以做负载均衡器,配置上可以优化的地方很多,有端口检测和url的检测,但是检测的方式是被动式的,会对用户的访问造成一定的影响。 以java类应用来说,常见的使用方式是lvs+nginx+tomcat/resin,比较完善的日志,可以通过分析nginx日志的状态码,响应时间(response time)和后端响应时间(upstream time)来跟踪qos,定位问题。 性能上问题不大,比较常见的问题是buffer导致的io问题和日志本地切割导致的nginx慢速响应的问题第一个问题可以尝试内存换io或者干脆关掉buffer试试,第二个问题可以把日志通过网络写入远端处理(不过貌似目前nginx不支持)。
4.tengine nginx的变种,在url check上做了改进,支持主动的检查,减少了对用户的影响,同时可以支持多种方式的日志处理(通过网络写入远端处理等),还支持各种自定义的插件,灵活性比较高。在webcdn的结构设计中我就是用了lvs+tengine+squid/trafficserver的结构。
5.squid/trafficserver/varnish反向代理软件,个人觉得还是做缓存会比较有优势。没有用来做过负载均衡器,这里就不妄加评论了。。
6.haproxy个人感觉和nginx差不多,比nginx要轻量级。一般都是lvs + haproxy来做高可用,比如淘宝的cdn结构就是lvs+haproxy+trafficserver这个个人用的也比较少。。
7.f5设备类高大上的设备,没接触过,不过有界面一切都好说。
一句话:用好一个软件比用一个好软件更重要。
2.lvs 线上用的比较多的一种负载均衡器,内核态转发型的高可用工具,可以看做是tcp层的负载均衡器,主要原理就是对tcp的报文做些更改,然后进行转发,支持的状态检测方法也比较完善,有端口检测,url检测和自定义脚本检测。 实际应用中一般是用lvs的dr模式,配合keepalived使用,keepalived提供主机的高可用,lvs提供应用的高可用,lvs采用url的检测方式(避免端口ok但是应用挂起的情况,比如java应用的gc)。 比较常见的问题是realserver被踢出的问题,可以通过在lvs部署监控并根据检测方法部署相关的检测脚本(网络检测,端口检测,url检测)来找到问题的rc。 很少能遇到性能的问题,在包量很大的情况下(几十万/s),可能会遇到网卡ring buffer和网卡中断的问题,可以通过丢包率和mpstat来定位,ring buffer问题可以尝试增加网卡的ring buffer设置解决,中断问题可以采用centos5.8以上的内核配合多队列(必须)来解决。
3.nginx 现在主流的反向代理软件,可以通过代理的功能实现负载均衡的功能,本身功能比较完善,既可以做静态站点,缓存又可以做负载均衡器,配置上可以优化的地方很多,有端口检测和url的检测,但是检测的方式是被动式的,会对用户的访问造成一定的影响。 以java类应用来说,常见的使用方式是lvs+nginx+tomcat/resin,比较完善的日志,可以通过分析nginx日志的状态码,响应时间(response time)和后端响应时间(upstream time)来跟踪qos,定位问题。 性能上问题不大,比较常见的问题是buffer导致的io问题和日志本地切割导致的nginx慢速响应的问题第一个问题可以尝试内存换io或者干脆关掉buffer试试,第二个问题可以把日志通过网络写入远端处理(不过貌似目前nginx不支持)。
4.tengine nginx的变种,在url check上做了改进,支持主动的检查,减少了对用户的影响,同时可以支持多种方式的日志处理(通过网络写入远端处理等),还支持各种自定义的插件,灵活性比较高。在webcdn的结构设计中我就是用了lvs+tengine+squid/trafficserver的结构。
5.squid/trafficserver/varnish反向代理软件,个人觉得还是做缓存会比较有优势。没有用来做过负载均衡器,这里就不妄加评论了。。
6.haproxy个人感觉和nginx差不多,比nginx要轻量级。一般都是lvs + haproxy来做高可用,比如淘宝的cdn结构就是lvs+haproxy+trafficserver这个个人用的也比较少。。
7.f5设备类高大上的设备,没接触过,不过有界面一切都好说。
一句话:用好一个软件比用一个好软件更重要。
相关文章推荐
- Schtasks.exe计划任务的几个实例小结 推荐
- socket编程几个函数小结
- 推荐几个提供网站测速服务网站
- 强烈推荐几个比较好的Java代码查询网站
- 蛙蛙推荐:分享几个关于社交网络的创意
- IT运维经验小结 推荐
- 推荐视觉跟踪领域的几个研究者
- 推荐几个ACM网址
- 推荐几个学习网站
- python调用shell命令小结 推荐
- jQuery Select下拉框操作小结(推荐)
- UIApplicationDelegate里面最常用的几个函数执行顺序小结
- js创建对象的几种常用方式小结(推荐)
- 推荐几个按扭样式
- 推荐几个学习flex的好网站
- 推荐几个Net开源项目
- 几个比较好的网址(鸟哥推荐)
- 几个值得推荐的 .NET 工具
- 推荐几个比较好的Java代码查询网站
- 推荐系统的几个阶段