负载均衡器技术Nginx和F5的优缺点对比

Posted 2023-05-01

参考技术A

这是网上摘抄的文章，正好想了解一下负载均衡，看这篇文章写的比较易懂，就。。。。

对于数据流量过大的网络中，往往单一设备无法承担，需要多台设备进行数据分流，而负载均衡器就是用来将数据分流到多台设备的一个转发器。

目前有许多不同的负载均衡技术用以满足不同的应用需求，如软/硬件负载均衡、本地/全局负载均衡、更高网络层负载均衡，以及链路聚合技术。

腾讯、淘宝、新浪等大型门户及商业网站使用的是软负载均衡器nginx，而农行用的是F5硬负载均衡器，这里就简单介绍下这两种技术：

一.软件负载均衡解决方案

在一台服务器的操作系统上，安装一个附加软件来实现负载均衡，如Nginx负载均衡（我们管理系统平台使用的也是这款均衡器）。它的优点是基于特定环境、配置简单、使用灵活、成本低廉，可以满足大部分的负载均衡需求。

1.什么是Nginx

Nginx ("engine x") 是一个高性能的HTTP和反向代理服务器，也是一个IMAP/POP3/SMTP代理服务器。可以说Nginx是目前使用最为广泛的HTTP软负载均衡器，其将源代码以类BSD许可证的形式发布（商业友好），同时因高效的性能、稳定性、丰富的功能集、示例配置文件和低系统资源的消耗而闻名于业界。像腾讯、淘宝、新浪等大型门户及商业网站都采用Nginx进行HTTP网站的数据分流。

2.Nginx的功能特点

a.工作在网络的7层之上，可以针对http应用做一些分流的策略，比如针对域名、目录结构；

b.Nginx对网络的依赖比较小；

c.Nginx安装和配置比较简单，测试起来比较方便；

d.也可以承担高的负载压力且稳定，一般能支撑超过1万次的并发；

e.Nginx可以通过端口检测到服务器内部的故障，比如根据服务器处理网页返回的状态码、超时等等，并且会把返回错误的请求重新提交到另一个节点，不过其中缺点就是不支持url来检测；

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

g.Nginx能支持http和Email，这样就在适用范围上面小很多；

h.不支持Session的保持、对Big request header的支持不是很好，另外默认的只有Round-robin和IP-hash两种负载均衡算法。

3.Nginx的原理

Nginx采用的是反向代理技术，代理服务器来接受internet上的连接请求，然后将请求转发给内部网络上的服务器，并将从服务器上得到的结果返回给internet上请求连接的客户端，此时代理服务器对外就表现为一个服务器。反向代理负载均衡技术是把将来自internet上的连接请求以反向代理的方式动态地转发给内部网络上的多台服务器进行处理，从而达到负载均衡的目的。

二.硬件负载均衡解决方案

直接在服务器和外部网络间安装负载均衡设备，这种设备我们通常称之为负载均衡器。由于专门的设备完成专门的任务，独立于操作系统，整体性能得到大量提高，加上多样化的负载均衡策略，智能化的流量管理，可达到最佳的负载均衡需求。一般而言，硬件负载均衡在功能、性能上优于软件方式，不过成本昂贵，比如最常见的就是F5负载均衡器。

1.什么是F5 BIG-IP

F5负载均衡器是应用交付网络的全球领导者F5 Networks公司提供的一个负载均衡器专用设备，F5 BIG-IP LTM 的官方名称叫做本地流量管理器，可以做4-7层负载均衡，具有负载均衡、应用交换、会话交换、状态监控、智能网络地址转换、通用持续性、响应错误处理、IPv6网关、高级路由、智能端口镜像、SSL加速、智能HTTP压缩、TCP优化、第7层速率整形、内容缓冲、内容转换、连接加速、高速缓存、Cookie加密、选择性内容加密、应用攻击过滤、拒绝服务(DoS)攻击和SYN Flood保护、防火墙—包过滤、包消毒等功能。

2.F5 BIG-IP用作HTTP负载均衡器的主要功能

a.F5 BIG-IP提供12种灵活的算法将所有流量均衡的分配到各个服务器，而面对用户，只是一台虚拟服务器。

b.F5 BIG-IP可以确认应用程序能否对请求返回对应的数据。假如F5 BIG-IP后面的某一台服务器发生服务停止、死机等故障，F5会检查出来并将该服务器标识为宕机，从而不将用户的访问请求传送到该台发生故障的服务器上。这样，只要其它的服务器正常，用户的访问就不会受到影响。宕机一旦修复，F5 BIG-IP就会自动查证应用已能对客户请求作出正确响应并恢复向该服务器传送。

c.F5 BIG-IP具有动态Session的会话保持功能。

d.F5 BIG-IP的iRules功能可以做HTTP内容过滤，根据不同的域名、URL，将访问请求传送到不同的服务器。

三.方案优缺点对比

1.基于硬件的方式(F5)

优点：能够直接通过智能交换机实现,处理能力更强，而且与系统无关，负载性能强更适用于一大堆设备、大访问量、简单应用。

缺点：成本高，除设备价格高昂，而且配置冗余，很难想象后面服务器做一个集群，但最关键的负载均衡设备却是单点配置；无法有效掌握服务器及应用状态。

硬件负载均衡，一般都不管实际系统与应用的状态，而只是从网络层来判断，所以有时候系统处理能力已经不行了，但网络可能还来 得及反应（这种情况非常典型，比如应用服务器后面内存已经占用很多，但还没有彻底不行，如果网络传输量不大就未必在网络层能反映出来）。

2.基于软件的方式(Nginx)

优点：基于系统与应用的负载均衡，能够更好地根据系统与应用的状况来分配负载。这对于复杂应用是很重要的，性价比高，实际上如果几台服务器，用F5之类的硬件产品显得有些浪费，而用软件就要合算得多，因为服务器同时还可以跑应用做集群等。

缺点：负载能力受服务器本身性能的影响，性能越好，负载能力越大。

国内据说迪普和深信服做的不错，手头没有啥资料，就不介绍了。

对比Haproxy和Nginx负载均衡效果

 

为了对比Hproxy和Nginx负载均衡的效果，分别在测试机上（以下实验都是在单机上测试的，即负载机器和后端机器都在一台机器上）做了这两个负载均衡环境，并各自抓包分析。
下面说下这两种负载均衡环境下抓包分析后的结果：

1）Haproxy负载均衡环境下的实验记录。后端有一台机器挂掉后，如果还没达到探测的时间点时，请求还会往挂掉的这台机器转发，请求会丢失。
Haproxy负载均衡的实验记录如下：
1--先看下Haproxy的配置。
配置inter 20000为20s检测一次，这个是为了更明显的抓下HAProxy的负载均衡探测机制。
[[email protected] ~]# cat /usr/local/haproxy/conf/haproxy.cfg

........
listen test9090
bind 127.0.0.1:9090
mode tcp
server localhost90 127.0.0.1:90 check inter 20000
server localhost91 127.0.0.1:91 check inter 20000

2--后端机器的Nginx的配置
[[email protected] ~]# cat /usr/local/nginx/conf/vhost/test.conf

server {
    listen  90;
    listen  91;
    location /{
      root /var/www/html;
    }
}

先在/var/www/html里创建一个首页index.html文件
[[email protected] ~]# echo "this is test" > /var/www/html/index.html
然后测试访问，并在机器上开两个窗口看下抓包是否均衡正常，两个窗口运行的命令分别如下：
[[email protected] ~]# curl 127.0.0.1:9090
[[email protected] ~]# tcpdump -i lo -nn ‘port 90‘
[[email protected] ~]# tcpdump -i lo -nn ‘port 91‘

上面抓包的截图证明Nginx监听的90和91端口都有在监听。使用抓包来检测比看日志来更细点，所以还是用抓包来分析了。

3--抓包查看HAProxy的健康检测机制
因为前面haproxy里配置了inter 20000，也就是告诉HAProxy 20s检测一次，抓包查看也是20s检查一下。
注意：这个检测是在客户端无任务请求的时候进行探测的，也就是处理请求跟探测是分开的。

4--模拟线上故障，Nginx挂掉91端口
把listen 91这个Nginx的配置去除，然后reload nginx，会发现前端的请求如果分发到91端口的话，就会挂掉，经抓包发现HAProxy需要探测三次才会把故障的给切下线。我们配置的是20s探测一次，也是最长可能得探测60s才能把故障的切除掉。如果这60s内有1w请求的话，那就会丢掉5k个。如果用在线上的话，探测机制肯定不会是20s一次，一般最多3s会切换掉。

2）Nginx负载均衡环境下的实验记录

1--Nginx的反向代理负载均衡配置，如下：
[[email protected] ~]# cat /usr/local/nginx/conf/vhost/LB.conf

upstream backend {   
    server 127.0.0.1:90 weight=1 max_fails=3 fail_timeout=30;
    server 127.0.0.1:91 weight=5 max_fails=3 fail_timeout=30;        
    }

server {
     listen 9090;
     location / {
     proxy_pass http://backend;
     }        
    }

前端还是使用9090来监听，把请求转发到90和91端口。
2--后端Nginx配置如下。可在/var/www/html/建个index.html进行测试
[[email protected] ~]# cat /usr/local/nginx/conf/vhost/test.conf

server {
    listen  90;
    listen  91;
    location /{
      root /var/www/html;
    }
}

在/var/www/html里创建一个首页index.html文件
[[email protected] ~]# echo "this is test2" > /var/www/html/index.html

3--抓包查看Nginx反向代理负载均衡的健康检测机制。抓包同样会发生90和91的包都有过来。
抓包会发现Nginx在没有请求的时候，90和91端口上没有任务的请求。也就是在没有请求的时候，是不会对后端的代理服务器进行检测的。

4--模拟线上故障，Nginx挂掉91端口
把listen 91这个Nginx的配置去除，然后reload一下，发现前端的访问没有任务影响。抓包如下，请求有打包91，但由于91没请求到数据。Nginx的均衡还会再次去90上取数据。也就是说，Nginx如果后端挂掉91端口的话，对前端的请求没有任务影响，只要并发支撑得住的话。

由上面的实验可知：
1）HAProxy对于后端服务器一直在做健康检测（就算请求没过来的时候也会做健康检查）：
后端机器故障发生在请求还没到来的时候，haproxy会将这台故障机切掉，但如果后端机器故障发生在请求到达期间，那么前端访问会有异常。也就是说HAProxy会把请求转到后端的这台故障机上，并经过多次探测后才会把这台机器切掉，并把请求发给其他正常的后端机，这势必会造成一小段时间内前端访问失败。
2）Nginx对于后端的服务器没有一直在做健康检测：
后端机器发生故障，在请求过来的时候，分发还是会正常进行分发，只是请求不到数据的时候，它会再转向好的后端机器进行请求，直到请求正常为止。也就是说Nginx请求转到后端一台不成功的机器的话，还会再转向另外一台服务器，这对前端访问没有什么影响。
3）因此，如果有用HAProxy做为前端负载均衡的话 ，如果后端服务器要维护，在高并发的情况，肯定是会影响用户的。但如果是Nginx做为前端负载均衡的话，只要并发撑得住，后端切掉几台不会影响到用户。