几个负载均衡器的小结

  1. 云栖社区>
  2. 博客>
  3. 正文

几个负载均衡器的小结

科技小先锋 2017-11-28 02:51:00 浏览880
展开阅读全文
之前负责过公司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设备类

高大上的设备,没接触过,不过有界面一切都好说。


一句话:用好一个软件比用一个好软件更重要。



本文转自菜菜光 51CTO博客,原文链接:http://blog.51cto.com/caiguangguang/1357638,如需转载请自行联系原作者

网友评论

登录后评论
0/500
评论
科技小先锋
+ 关注