# LVS与HAProxy的对比 > 作者/来源: UCloud 运营管理员 > 发布时间: 2023-01-11T05:20:00.000Z > 分类: 云主机 > 标签: 网络, Linux, 前端 > 原文链接: http://117.50.162.249:3000/yun/articles/1047 --- # LVS与HAProxy的对比 > 来源: https://www.ucloud.cn/yun/129888.html > 作者: IT那活儿 > 发布日期: 发布于2023-01-11 13:20 LVS与HAProxy的对比 众所周知LVS与HAProxy都是为集群提供负载均衡功能的，那我们在实际使用中应该如何在二者中选择更适合自己业务场景的呢？下面让我们来分析一下它们各自的特点。 LVS简介： LVS群集，也叫LVS虚拟服务器（Linux Virtual Server），针对Linux内核开发的一个负载均衡项目，由我国章文嵩博士在1998年5月创建，基于IP地址和内容请求分发的高效的负载均衡解决方法，现已为Linux内核的一部分，默认编译为ip\_vs模块。 官方网站：http://www.linuxvirtualserver.org/ ## **1．LVS主要使用场景：** 适用于各种高并发场景，抗并发能力特别强，LVS主要做的是四层（传输层）负载。 ## **2．LVS的优点：** - 首先它是基于4层的网络协议的，仅作为分发只用，没有流量的产生，抗负载能力强，对于服务器的硬件要求除了网卡外，其他没有太多要求； - 配置性比较低，这是一个缺点也是一个优点，因为没有可太多配置的东西，大大减少了人为出错的几率； - 应用范围比较广，不仅仅对web服务做负载均衡，还可以对其他应用（mysql）做负载均衡； - LVS架构中存在一个虚拟IP的概念，需要向IDC多申请一个IP来做虚拟IP。 ## **3．LVS的四种工作模式** DR：直接路由模式 TUN：隧道模式 NAT：路由转发模式 FULLNAT模式 **仅从性能上作比较：DR>TUN>NAT>FULLNAT** 四种工作模式的详细介绍： DS：Director Server 指的是前端负载均衡器节 点 RS：Real Server 后端真实的工作服务器 VIP：向外部直接面向用户请求，作为用户请求的 目标的IP地址 DIP：Director Server IP 主要用于和内部主机通 讯的IP地址 RIP：Real Server IP 后端服务器的IP地址 CIP：Client IP 访问客户端的IP地址 - **DR：直接路由模式** 请求由 LVS 接受，由真实提供服务的服务器（RealServer, RS）直接返回给用户，返回的时候不经过 LVS。 DR 模式下需要 LVS 和绑定同一个 VIP（RS 通过将 VIP 绑定在 loopback 实现）。 一个请求过来时，LVS 只需要将网络帧的 MAC 地址修改为某一台 RS 的 MAC，该包就会被转发到相应的 RS 处理，注意此时的源 IP 和目标 IP 都没变，LVS 只是做了一下移花接木。 RS 收到 LVS 转发来的包，链路层发现 MAC 是自己的，到上面的网络层，发现 IP 也是自己的，于是这个包被合法地接受，RS 感知不到前面有 LVS 的存在。 而当 RS 返回响应时，只要直接向源 IP（即用户的 IP）返回即可，不再经过 LVS。 - **TUN：隧道模式** 客户端将访问vip报文发送给LVS服务器； LVS服务器将请求报文重新封装，发送给后端真实服务器； 后端真实服务器将请求报文解封，在确认自身有vip之后进行请求处理； 后端真实服务器在处理完数据请求后，直接响应客户端。 此模式实现起来较为复杂。 - **NAT：路由转发模式** NAT（Network Address Translation）是一种外网和内网地址映射的技术。 多目标的DNAT(iptables)转换;它通过修改请求报文的目标IP地址（同时可能会修改目标端口)挑选出某Real Server的RIP地址实现转发；在LVS负载均衡调度器上请求先发送给PREROUTING-->INPUT，然后经由监听在INPUT上的LVS程序强制将请求转发给 POSTROUTING NAT 模式下，网络报的进出都要经过 LVS 的处理。LVS 需要作为 RS 的网关。 当包到达 LVS 时，LVS 做目标地址转换（DNAT），将目标 IP 改为 RS 的 IP。RS 接收到包以后，仿佛是客户端直接发给它的一样。 RS 处理完，返回响应时，源 IP 是 RS IP，目标 IP 是客户端的 IP。 这时 RS 的包通过网关（LVS）中转，LVS 会做源地址转换（SNAT），将包的源地址改为 VIP，这样，这个包对客户端看起来就仿佛是 LVS 直接返回给它的。客户端无法感知到后端 RS 的存在。 注意： RS的RIP和Director的DIP必须在同一IP网络 RS和DIP应该使用私网地址且RD的网关要指向DIP 真实服务器的网关必须设置为LVS的ip地址。 - **FULLNAT模式** 无论是 DR 还是 NAT 模式，不可避免的都有一个问题：LVS 和 RS 必须在同一个 VLAN 下，否则 LVS 无法作为 RS 的网关。 Full-NAT 相比 NAT 的主要改进是，在 SNAT/DNAT 的基础上，加上另一种转换，转换过程如下： ![](https://ucloud-blog.cn-bj.ufileos.com/articles/129888/images/129888_000.png) 在包从 LVS 转到 RS 的过程中，源地址从客户端 IP 被替换成了 LVS 的内网 IP。 内网 IP 之间可以通过多个交换机跨 VLAN 通信。 当 RS 处理完接受到的包，返回时，会将这个包返回给 LVS 的内网 IP，这一步也不受限于 VLAN。 LVS 收到包后，在 NAT 模式修改源地址的基础上，再把 RS 发来的包中的目标地址从 LVS 内网 IP 改为客户端的 IP。 Full-NAT 主要的思想是把网关和其下机器的通信，改为了普通的网络通信，从而解决了跨 VLAN 的问题。采用这种方式，LVS 和 RS 的部署在 VLAN 上将不再有任何限制，大大提高了运维部署的便利性。 **fullnat模式和nat模式相似，但是与nat不同的是nat模式只做了两次地址转换，fullnat模式却做了四次。** ## **4．LVS的十种负载均衡算法** **(1) 轮循调度 rr** 均等地对待每一台服务器，不管服务器上的实际连接数和系统负载 **(2) 加权轮调 wrr** 调度器可以自动问询真实服务器的负载情况，并动态调整权值 **(3) 最少链接 lc** 动态地将网络请求调度到已建立的连接数最少的服务器上 如果集群真实的服务器具有相近的系统性能，采用该算法可以较好的实现负载均衡 **(4) 加权最少链接 wlc** 调度器可以自动问询真实服务器的负载情况，并动态调整权值 带权重的谁不干活就给谁分配，机器配置好的权重高 **(5) 基于局部性的最少连接调度算法 lblc** 这个算法是请求数据包的目标 IP 地址的一种调度算法，该算法先根据请求的目标 IP 地址寻找最近的该目标 IP 地址所有使用的服务器，如果这台服务器依然可用，并且有能力处理该请求，调度器会尽量选择相同的服务器，否则会继续选择其它可行的服务器 **(6) 复杂的基于局部性最少的连接算法 lblcr** 记录的不是要给目标 IP 与一台服务器之间的连接记录，它会维护一个目标 IP 到一组服务器之间的映射关系，防止单点服务器负载过高。 **(7) 目标地址散列调度算法 dh** 该算法是根据目标 IP 地址通过散列函数将目标 IP 与服务器建立映射关系，出现服务器不可用或负载过高的情况下，发往该目标 IP 的请求会固定发给该服务器。 **(8) 源地址散列调度算法 sh** 与目标地址散列调度算法类似，但它是根据源地址散列算法进行静态分配固定的服务器资源。 **(9) 最少期望延迟 sed** 不考虑非活动链接，谁的权重大，优先选择权重大的服务器来接收请求，但权重大的机器会比较忙 **(10) 永不排队 nq** 无需队列，如果有realserver的连接数为0就直接分配过去 HAProxy简介： HAProxy是一个使用C语言编写的自由及开放源代码软件，其提供高可用性、负载均衡，以及基于TCP和HTTP的应用程序代理。 ## **1. HAProxy主要适用场景** HAProxy特别适用于那些负载特大的web站点，这些站点通常又需要会话保持或七层处理。HAProxy运行在当前的硬件上，完全可以支持数以万计的并发连接。 ## **2. HAProxy的优点** （1）HAProxy是支持虚拟主机的，通过frontend指令来实现 （2）支持Session的保持，Cookie的引导等工作 （3）支持url检测后端的服务器出问题的检测会有很好的帮助。 （4）它跟LVS一样，本身仅仅就只是一款负载均衡软件；单纯从效率上来讲HAProxy更会比Nginx有更出色的负载均衡速度，在并发处理上也是优于Nginx的。 （5）HAProxy可以对Mysql读进行负载均衡，对后端的MySQL节点进行检测和负载均衡 （6）能对请求的url和header中的信息做匹配，有比lvs有更好的7层实现 ## **3. 磁盘分区参数说明：** HAProxy的负载调度算法 （1）roundrobin 表示简单的轮询 （2）static-rr 表示根据权重进行轮询 （3）leastconn 表示最少连接者先处理 （4）source 表示根据请求源IP，这个跟Nginx的IP\_hash机制类似，我们用其作为解 决session问题的一种方法 （5）ri 表示根据请求的URI （6）rl\_param 表示根据请求的URl参数 （7）hdr(name) 表示根据HTTP请求头来锁定每一次HTTP请求 （8）rdp-cookie(name) 表示根据据cookie(name)来锁定并哈希每一次TCP请求 HAProxy相比LVS的使用要简单很多，功能方面也很丰富。当前，HAProxy支持两种主要的代理模式："tcp"也即4层（大多用于邮件服务器、内部协议通信服务器等）、7层（HTTP）。在4层模式下，HAProxy仅在客户端和服务器之间转发双向流量。7层模式下，HAProxy会分析协议，并且能通过允许、拒绝、交换、增加、修改或者请求(request)或者回应(response)里指定内容来控制协议，这种操作要基于特定规则。（新的1.3之后的版本引入了frontend,backend指令；frontend根据任意 HTTP请求头内容做规则匹配,然后把请求定向到相关的backend.） 以上是LVS和HAProxy的简介及详情，但上文只是陈述了它们的优秀的地方，下面让我们再来了解一下它们的不足，权衡利弊才能更好的帮我们进行选择。 LVS的缺点： 1. LVS本身不支持正则表达式的处理，不能做动静分离 2. 网站应用比较庞大时，LVS实现起来比较复杂，特别是后端存在Windows Server的机器时 HAProxy缺点： 1. 不支持POP/SMTP协议 2. 不支持SPDY协议 3. 不支持HTTP cache功能 4. 重载配置的功能需要重启进程 5. 多进程模式支持不够友好 **下图是对二者进行一个总结：** **![](https://ucloud-blog.cn-bj.ufileos.com/articles/129888/images/129888_001.png)** ![](https://ucloud-blog.cn-bj.ufileos.com/articles/129888/images/129888_002.png) END 更多精彩干货分享 点击下方名片关注 IT那活儿 ![](https://ucloud-blog.cn-bj.ufileos.com/articles/129888/images/129888_003.png)