浅谈软件和硬件负载均衡(LVS、HAProxy、Nginx、F5)及一次线上问题分析

文章目录

    • 一、负载均衡
      • 什么是负载均衡
      • 负载均衡的优点
      • 四层和七层负载均衡
      • 常见的负载均衡软硬件
    • 二、硬件负载均衡
      • 优点
      • 缺点
    • 三、软件负载均衡
      • LVS
      • HAproxy
      • Nginx
      • 三大主流软件负载均衡的适用场景:
    • 四、一次线上事故分析

一、负载均衡

什么是负载均衡

百度百科对负载均衡的解释:

负载均衡建立在现有网络结构之上,它提供了一种廉价有效透明的方法扩展网络设备和服务器的带宽、增加吞吐量、加强网络数据处理能力、提高网络的灵活性和可用性。
负载均衡(Load Balance)其意思就是分摊到多个操作单元上进行执行,例如Web服务器、FTP服务器、企业关键应用服务器和其它关键任务服务器等,从而共同完成工作任务。

简言之就是:将高并发、高流量的网络请求,经过负载均衡,动态转发给后端多个节点处理,以提高响应效率、T提高吞吐量

负载均衡的优点

  1. 减伤公网IP数量,节省IP支出成本
  2. 异常内部服务器IP,提高内部服务器安全性
  3. 解决单机故障问题,提供高并发下高可用的策略
  4. 在用户无感知情况下,做WEB服务器的动态水平拓展
  5. 支持四层和七层负载,对四层性能更好,支持服务器的动态上下线
  6. 性能强,并发数可达数万至数十万
  7. 配置简单,有固定格式的配置文件

四层和七层负载均衡

这里的四层和七层是指的OSI七层网络模型。OSI网络模型是从上往下的,越底层越接近硬件,越往上越接近软件。这七层模型分别是物理层、数据链路层、网络层、传输层、会话层、表示层、应用层

浅谈软件和硬件负载均衡(LVS、HAProxy、Nginx、F5)及一次线上问题分析_第1张图片

四层负载均衡:基于IP+端口的负载均衡:从传输层开始是,使用“ip + port”接受请求,在转发到对应的服务器

七层负载均衡:基于虚拟的URL或主机IP的负载均衡,在四层负载均衡的基础上,通过应用层协议实现负载均衡

常见的负载均衡软硬件

当前服务器集群的负载均衡主要分为:硬件负载均衡和软件负载均衡。

硬件负载均衡主要有:F5、Array、NetScaler等

软件负载均衡主要有:LVS、HAProxy、Nginx等

二、硬件负载均衡

硬件负载均衡解决方案是直接在服务器和外部网络间安装负载均衡设备,这种设备我们通常称之为负载均衡器。由于使用专门的设备完成网络请求转发的任务,独立于操作系统,整体性能高,负载均衡策略多样化,流量管理智能化。

优点

  • 其功能强大,不仅包含负载均衡还包括应用交换、会话交换、状态监控、智能网络地址转换、通用持续性、响应错误处理、IPv6网关、高级路由、智能端口镜像、SSL加速、智能HTTP压缩、TCP优化、第7层速率整形、内容缓冲、内容转换、连接加速、高速缓存、Cookie加密、选择性内容加密、应用攻击过滤、拒绝服务(DoS)攻击和SYN Flood保护、防火墙过滤等功能。

  • 直接连接交换机,处理网络请求能力强,与系统无关,负载性可以强。可以应用于大量设施、适应大访问量、使用简单。

缺点

  • 价格高昂、成本高,配置冗余.即使网络请求分发到服务器集群,负载均衡设施却是单点配置。
  • 无法有效掌握服务器及应使用状态。

三、软件负载均衡

由于硬件负载均衡价格高昂,一般对于中小规模网站,使用软件负载均衡便可解决生产中所遇到的问题。

Nginx/LVS/HAProxy是目前使用最广泛的三种开源的负载均衡软件。一般对负载均衡的使用是随着网站规模的提升根据不同的阶段来使用不同的技术。

  • 如果是中小型的Web应用,比如日PV小于1000万,Web前端采用Nginx/HAProxy+Keepalived作负载均衡器;
  • 如果服务器较多,可以用DNS轮询,LVS所耗费的机器还是比较多的。大型网站或重要的服务(Mysql),且服务器比较多时,可以考虑用LVS+Keepalived的架构。

LVS

LVS的是Linux Virtual Server的简写,翻译为Linux虚拟服务器,即一个虚拟的服务器集群系统,是由我国章文嵩博士在1998年5月所研究成立,也是中国国内最早出现的自由软件项目之一。主要有一下特点:

1. 抗负载能力强,性能高,能达到F5的60%,对内存和CPU资源消耗比较低
2. 稳定,可靠性高,自身有完美的热备方案(Keepalived+lvs)
3. 配置性较低,这是缺点也是优点,因为没有可太多配置的东西,所以不需要人工介入,减少了人为出错几率
4. 工作在网络4层,通过VRRP协议(仅作代理之用),具体的流量是由linux内核来处理,因此没有流量的产生
5. 应用范围较广。因为LVS工作在4层,所以它几乎可以对所有应用做负载均衡,包括http、数据库、在线聊天室等等。
6. 不支持正则处理,不能做动静分离
7. 支持多种负载均衡算法:rr(轮询),wrr(带权轮询)、lc(最小连接)、wlc(带权最小连接)
8. LVS工作模式有4种:
 - nat 地址转换
 - dr 直接路由
 - tun 隧道
 - full-nat

HAproxy

HAProxy是一个使用C语言编写的自由及开放源代码软件,它提供高可用性、负载均衡,以及基于TCP(第四层)和HTTP(第七层)的应用程序代理。HAProxy特别适用于那些负载特大的web站点,这些站点通常又需要会话保持或七层处理。

  1. 支持两种代理模式:TCP(四层)和HTTP(七层),支持虚拟主机
  2. 能够补充Nginx的一些缺点比如Session的保持,Cookie的引导等工作
  3. HAProxy跟LVS类似,本身只是一款负载均衡软件;单纯从效率上来讲HAProxy会比Nginx有更出色的负载均衡速度,在并发处理上也是优于Nginx的。
  4. 支持url检测后端的服务器出问题的检测会有很好的帮助
  5. 更多的负载均衡策略比如:动态加权轮循(Dynamic Round Robin),加权源地址哈希(Weighted Source Hash),加权URL哈希和加权参数哈希(Weighted Parameter Hash)已经实现
  6. 自带强大的监控服务器状态的页面,实际环境中我们结合Nagios进行邮件或短信报警
  7. 不支持POP/SMTP协议 SPDY协议
  8. 不能做Web服务器,即不支持HTTP cache功能
  9. 重载配置的功能需要重启进程,虽然也是soft restart,但没有Nginx的reaload更为平滑和友好
  10. 多进程模式支持不够好

Nginx

Nginx是一款轻量级的Web服务器/反向代理服务器及电子邮件(IMAP/POP3)代理服务器,在BSD-like 协议下发行。其特点是占有内存少,并发能力强。Nginx默认采用多进程工作方式,Nginx启动后,会运行一个master进程和多个worker进程。

  1. 工作在网络7层,可以针对http应用做一些分流的策略,比如针对域名,目录结构

    注:1.10.X版本之后引入了对四层tcp转发的支持,默认:不开启

  2. Nginx对网络的依赖较小,理论上能ping通就能进行负载功能

  3. Nginx安装配置比较简单,测试起来很方便

  4. 也可以承担较高的负载压力且稳定,nginx是为解决c10k问题而诞生的

    官方测试Nginx能够支撑5万并发连接,实际生产环境中可以支撑2~4万并发连接数。

  5. 对后端服务器的健康检查,只支持通过端口来检测,不支持通过url来检测

  6. Nginx对请求的异步处理可以帮助节点服务器减轻负载压力

  7. Nginx仅能支持http、https和Email协议,这样就在适用范围较小。

  8. 不支持Session的直接保持,但能通过ip_hash来解决。对Big request header的支持不是很好。

  9. Nginx还能做Web服务器即Cache功能。

  10. 相较于HAproxy的重载配置的功能需要重启进程,Nginx则是支持热部署的。

三大主流软件负载均衡的适用场景:

  1. 网站建设初期,可以选用Nginx、HAProxy作为反向代理负载均衡(流量不大时,可以不选用负载均衡),因为其配置简单,性能也能满足一般业务场景。如果考虑到负载均衡器是有单点问题,可以采用Nginx+Keepalived/HAproxy+Keepalived避免负载均衡器自身的单点问题。
  2. 网站并发到达一定程度后,为了提高稳定性和转发效率,可以使用lvs,毕竟LVS比Nginx/HAProxy要更稳定,转发效率也更高。

四、一次线上事故分析

本司网络拓扑结构中,入口是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的性能可能成为一个瓶颈。

你可能感兴趣的:(网络)