负载均衡
-
F5:
- 采用F5服务器来做负载均衡,F5的全称是F5-BIG-IP-GTM,是最流行的硬件负载均衡设备,其并发能力达到百万级。
-
LVS:https://wsgzao.github.io/post/lvs-dr/
- 基于内核网络层面工作,有超强的承载能力和并发处理能力。单台LVS负载均衡器,可支持上万并发连接。
- 应用范围广:因为LVS工作在4层,所以它几乎可以对所有应用做负载均衡,包括http、数据库、DNS、ftp服务等等
- 缺点:工作在4层,不支持7层规则修改,机制过于庞大,不适合小规模应用。
- LVS架构中存在一个虚拟IP的概念,需要向IDC多申请一个IP来做虚拟IP。
-
HAProxy 会话保持
- HAProxy基于cookie实现客户端会话保持 使用ip_hash时,如果有众多用户使用相同的公网地址去访问同一个服务时,由于这些用户所使用的公网IP都为同一个,HAproxy就会把他们调度到同一后端的服务器,由此可能造成后天的单台服务器的压力过大,因此需要其他的方法来进行调度。
- HAProxy可以实现插入一层cookie,当用户第一次访问会查看是否有cookie,如果没有就在响应报文中插入以程cookie返回给客户端,当用户再次访问就会根据cookie来调度请求。lvs和nginx无法实现
Nginx/LVS/HAProxy是目前使用最广泛的三种开源的负载均衡软件。一般对负载均衡的使用是随着网站规模的提升根据不同的阶段来使用不同的技术。
- 如果是中小型的Web应用,比如日PV小于1000万,Web前端采用Nginx/HAProxy+Keepalived作负载均衡器;
- 如果服务器较多,可以用DNS轮询,LVS所耗费的机器还是比较多的。大型网站或重要的服务(Mysql),且服务器比较多时,可以考虑用LVS+Keepalived的架构
一次线上事故分析
本司网络拓扑结构中,入口是F5,后面既有HAProxy、也有Nginx进行网络的代理。
事发场景
有段时间的搞线上大促和秒杀活动,头两天可能参与人数尚可,没触发报警。两三天后,APP端的监控发现存在大量的慢请求,还是APP首页的加载,慢请求比例甚至高达5%,严重影响了用户体验。但是,后端服务、接口端的监控显示,一切正常。那么,真相会是什么呢?
问题排查及定位
在排查了机房网络没有异常,且没有出现网络波动。这时,开始怀疑会不会是F5出现了问题?我们开启了APP端的监控,并且实时监控F5的运行状况,发现当APP端大量出现慢请求时,F5上出现了大量的TCP链接被拒绝。因而请求根本就没打到后端服务上。
联系了F5的供应商进行支持,最终发现是:在高峰期,F5的SSL连接(Https和Websockets使用)已经远远超过了自身支持的并发上限(我们的F5的SSL TPS上限是5000),而实际SSL并发量已高达8000左右,此时也出现大量TCP链接被拒绝的现象。
解决方案
调整架构,采用HAproxy来分担SSL的流量。结合F5,采用6台HAproxy做高可用的分流。将一部分业务流量迁移到HAproxy,降低F5的压力。
总结
- F5是通过芯片来 SSL offloading的,后期如有要求还需升级F5。
- SSL在高并发下对于运算的要求是非常高的,普通的CPU是很难胜任的,因此CPU的性能可能成为一个瓶颈。
...