lvs、nginx、haproxy转发模式优缺点总结

最新推荐文章于 2024-02-18 17:47:32 发布

weixin_33896069

最新推荐文章于 2024-02-18 17:47:32 发布

阅读量520

点赞数

文章标签：运维后端数据库

原文链接：http://blog.51cto.com/402753795/1854626

版权

隐约脑子里现在只有upstream、dr 、ip_hash这几个词了。现对三者的转发方式做下总结。
一、LVS转发模式

LVS是章文嵩博士写的一个工作于四层的高可能性软件。不像后两者支持七层转发，不过也正因为其简单，所以其是最稳定的。其共有三种IP负载均衡技术：VS/NAT（Virtual Server via Network Address Translation）、VS/TUN（Virtual Server via IP Tunneling）和VS/DR（Direct Routing），三者之间具体的比较见下表

lvs
二、nginx负载模式

nginx有五种负载算法模式，分别是：轮询、weight(权重)、ip_hash、fair、url_hash 。现逐一说明：

轮询（默认）: 每个请求按时间顺序逐一分配到不同的后端服务器，如果后端服务器down掉，能自动剔除。
weight :指定轮询几率，weight和访问比率成正比，用于后端服务器性能不均的情况。配置为：

        upstream bakend {
        server 192.168.0.14 weight=10;
        server 192.168.0.15 weight=10;
        }

ip_hash:每个请求按访问ip的hash结果分配，这样每个访客固定访问一个后端服务器，可以解决session的问题。配置为：

        upstream bakend {
        ip_hash;
        server 192.168.0.14:88;
        server 192.168.0.15:80;
        }

fair：按后端服务器的响应时间来分配请求，响应时间短的优先分配。

        upstream backend {
        server server1;
        server server2;
        fair;
        }

url_hash：按访问url的hash结果来分配请求，使每个url定向到同一个后端服务器，后端服务器为缓存时比较有效。配置如：

        upstream backend {
        server squid1:3128;
        server squid2:3128;
        hash $request_uri;
        hash_method crc32;
        }

注：第五种模式下，需要注意在upstream中加入hash语句，server语句中不能写入weight等其他的参数，hash_method是使用的hash算法。

server后面常接的参数有如下几个：

    down 表示单前的server暂时不参与负载
    weight 默认为1.weight越大，负载的权重就越大。
    max_fails ：允许请求失败的次数默认为1.当超过最大次数时，返回proxy_next_upstream 模块定义的错误
    fail_timeout:max_fails次失败后，暂停的时间。
    backup：其它所有的非backup机器down或者忙的时候，请求backup机器。所以这台机器压力会最轻。

三、haproxy

haproxy是三者之间负载算法最多的，有八种，所以其应用场景也是最多，配置也是最灵活的，具体8种算法为：

①roundrobin，表示简单的轮询，这个是负载均衡基本都具备的；

②static-rr，表示根据权重，和nginx的weight算法类似；

③leastconn，表示最少连接者先处理，有点类似于nginx的fair,不过fair是根据响应时间；

④source，表示根据请求源IP，这个跟Nginx的IP_hash机制类似，我们用其作为解决session问题的一种方法，建议关注；

⑤ri，表示根据请求的URI，类似于nginx的url_hash；

⑥rl_param，表示根据请求的URl参数'balance url_param' requires an URL parameter name；

⑦hdr(name)，表示根据HTTP请求头来锁定每一次HTTP请求；

⑧rdp-cookie(name)，表示根据据cookie(name)来锁定并哈希每一次TCP请求。

优缺点

三种负载均衡器的优缺点说明如下：

LVS的优点：
1、抗负载能力强、工作在第4层仅作分发之用，没有流量的产生，这个特点也决定了它在负载均衡软件里的性能最强的；无流量，同时保证了均衡器IO的性能不会受到大流量的影响；
2、工作稳定，自身有完整的双机热备方案，如LVS+Keepalived和LVS+Heartbeat；
3、应用范围比较广，可以对所有应用做负载均衡；
4、配置性比较低，这是一个缺点也是一个优点，因为没有可太多配置的东西，所以并不需要太多接触，大大减少了人为出错的几率；
LVS的缺点：
1、软件本身不支持正则处理，不能做动静分离，这就凸显了Nginx/HAProxy+Keepalived的优势。
2、如果网站应用比较庞大，LVS/DR+Keepalived就比较复杂了，特别是后面有Windows Server应用的机器，实施及配置还有维护过程就比较麻烦，相对而言，Nginx/HAProxy+Keepalived就简单多了。
#############################################################

1. LVS/DR如何处理请求报文的，会修改IP包内容吗？

1.1 vs/dr本身不会关心IP层以上的信息，即使是端口号也是tcp/ip协议栈去判断是否正确，vs/dr本身主要做这么几个事：

1）接收client的请求，根据你设定的负载均衡算法选取一台realserver的ip；

2）以选取的这个ip对应的mac地址作为目标mac，然后重新将IP包封装成帧转发给这台RS；

3）在hash table中记录连接信息。

vs/dr做的事情很少，也很简单，所以它的效率很高，不比硬件负载均衡设备差多少。

数据包、数据帧的大致流向是这样的：client --> VS --> RS --> client

1.2 前面已作了回答，vs/dr不会修改IP包的内容.

2. RealServer为什么要在lo接口上配置VIP？在出口网卡上配置VIP可以吗？

2.1 既然要让RS能够处理目标地址为vip的IP包，首先必须要让RS能接收到这个包。

在lo上配置vip能够完成接收包并将结果返回client。

2.2 答案是不可以将VIP设置在出口网卡上,否则会响应客户端的arp request,造成client/gateway arp table紊乱，以至于整个load balance都不能正常工作。

3. RealServer为什么要抑制arp帧？

这个问题在上一问题中已经作了说明，这里结合实施命令进一步阐述。我们在具体实施部署的时候都会作如下调整：

       echo "1" >/proc/sys/net/ipv4/conf/lo/arp_ignore
       echo "2" >/proc/sys/net/ipv4/conf/lo/arp_announce
       echo "1" >/proc/sys/net/ipv4/conf/all/arp_ignore
       echo "2" >/proc/sys/net/ipv4/conf/all/arp_announce我相信很多人都不会弄懂它们的作用是什么，只知道一定得有。我这里也不打算拿出来详细讨论，只是作几点说明，就当是补充吧。

3.1

echo "1" >/proc/sys/net/ipv4/conf/lo/arp_ignore
echo "2" >/proc/sys/net/ipv4/conf/lo/arp_announce这两条是可以不用的，因为arp对逻辑接口没有意义。

3.2 如果你的RS的外部网络接口是eth0，那么

echo "1" >/proc/sys/net/ipv4/conf/all/arp_ignore
echo "2" >/proc/sys/net/ipv4/conf/all/arp_announce其实真正要执行的是：

echo "1" >/proc/sys/net/ipv4/conf/eth0/arp_ignore
echo "2" >/proc/sys/net/ipv4/conf/eth0/arp_announce所以我个人建议把上面两条也加到你的脚本里去，因为万一系统里上面两条默认的值不是0，那有可能是会出问题滴。

4. LVS/DR load balancer（director）与RS为什么要在同一网段中？

从第一个问题中大家应该明白vs/dr是如何将请求转发给RS的了吧？它是在数据链路层来实现的，所以director必须和RS在同一网段里面。

5. 为什么director上lo接口除了VIP另外还要在eth0配一个ip（即DIP）？

5.1 如果是用了keepalived等工具做HA或者Load Balance,则在健康检查时需要用到DIP。

5.2 没有健康检查机制的HA或者Load Balance则没有存在的实际意义。

6. LVS/DR ip_forward需要开启吗？

不需要。因为director跟realserver是同一个网段，无需开启转发。

7. director的vip的netmask一定要是255.255.255.255吗？

lvs/dr里，director的vip的netmask 没必要设置为255.255.255.255，也不需要再去

route add -host $VIP dev eth0:0director的vip本来就是要像正常的ip地址一样对外通告的,不要搞得这么特殊.

8. LVS/DR如何进行tcp的三次握手？

#####################################################################

Nginx的优点：
1、工作在OSI第7层，可以针对http应用做一些分流的策略。比如针对域名、目录结构。它的正则比HAProxy更为强大和灵活；
2、Nginx对网络的依赖非常小，理论上能ping通就就能进行负载功能，这个也是它的优势所在；
3、Nginx安装和配置比较简单，测试起来比较方便；
4、可以承担高的负载压力且稳定，一般能支撑超过几万次的并发量；
5、Nginx可以通过端口检测到服务器内部的故障，比如根据服务器处理网页返回的状态码、超时等等，并且会把返回错误的请求重新提交到另一个节点；
6、Nginx不仅仅是一款优秀的负载均衡器/反向代理软件，它同时也是功能强大的Web应用服务器。LNMP现在也是非常流行的web环境，大有和LAMP环境分庭抗礼之势，Nginx在处理静态页面、特别是抗高并发方面相对apache有优势；
7、Nginx现在作为Web反向加速缓存越来越成熟了，速度比传统的Squid服务器更快，有需求的朋友可以考虑用其作为反向代理加速器；
Nginx的缺点：
1、Nginx不支持url来检测。
2、Nginx仅能支持http和Email，这个它的弱势。
3、Nginx的Session的保持，Cookie的引导能力相对欠缺。

HAProxy的优点：
1、HAProxy是支持虚拟主机的，可以工作在4、7层(支持多网段)；
2、能够补充Nginx的一些缺点比如Session的保持，Cookie的引导等工作；
3、支持url检测后端的服务器；
4、它跟LVS一样，本身仅仅就只是一款负载均衡软件；单纯从效率上来讲HAProxy更会比Nginx有更出色的负载均衡速度，在并发处理上也是优于Nginx的；
5、HAProxy可以对Mysql读进行负载均衡，对后端的MySQL节点进行检测和负载均衡，不过在后端的MySQL slaves数量超过10台时性能不如LVS；
6、HAProxy的算法较多，达到8种；

四、总结

具体现网应用可以根据据体的实际情况选择最好的负载方式。三者中，lvs稳定性最好，可配置性最少；nginx针对域名、目录结构进行正则匹配是最强的，同时其对网络依赖比较小，不过性能上和lvs和haproxy相比稍差一点点；haproxy支持虚拟主机，尤其在session保持方面做的最好，其有三种算法可以实现session共享———— ip识别（source）、cookie识别、session识别三种，除此之外在对mysql做HA方案时也经常会用到该软件。

转载于:https://blog.51cto.com/402753795/1854626