Linux的负载均衡详解

Posted 2023-03-25

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了Linux的负载均衡详解相关的知识，希望对你有一定的参考价值。

参考技术A Linux的负载均衡常用的有三种技术：中国人搞出来的大神级产品 LVS Linux Virtual Server，俄罗斯的nginx，来发法国的HAProxy。都是基于Linux的开源免费的负载均衡软件。

1. 抗负载能力强，性能高，能达到F5的60%，对内存和CPU资源消耗比较低

2. 工作在网络4层，通过VRRP协议(仅作代理之用)，具体的流量是由linux内核来处理，因此没有流量的产生。

3. 稳定，可靠性高，自身有完美的热备方案(Keepalived+lvs)

4. 不支持正则处理，不能做动静分离。

5. 支持多种负载均衡算法：rr(轮询)，wrr(带权轮询)、lc(最小连接)、wlc(带权最小连接)

6. 配置相对复杂，对网络依赖比较大，稳定性很高。

7. LVS工作模式有4种：

(1) nat 地址转换

(2) dr 直接路由

(3) tun 隧道

(4) full-nat

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

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

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

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

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

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

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

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

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

1.支持两种代理模式：TCP（四层）和HTTP（七层），支持虚拟主机；

2.能够补充Nginx的一些缺点比如Session的保持，Cookie的引导等工作

3.支持url检测后端的服务器出问题的检测会有很好的帮助。

4.更多的负载均衡策略比如：动态加权轮循(DynamicRoundRobin)，加权源地址哈希(Weighted SourceHash)，加权URL哈希和加权参数哈希(WeightedParameterHash)已经实现

5.单纯从效率上来讲HAProxy更会比Nginx有更出色的负载均衡速度。

6.HAProxy可以对mysql进行负载均衡，对后端的DB节点进行检测和负载均衡。

7.支持负载均衡算法：Round-robin（轮循）、Weight-round-robin（带权轮循）、source（原地址保持）、RI（请求URL）、rdp-cookie（根据cookie）

8.不能做Web服务器即Cache。

1. 负载能力

lvs抗负载能力最强，因为仅作分发不处理请求，相当于只作转发不做进一步处理直接在内核中完成，对系统资源消耗低（LVS DR模式）；

nginx和haproxy相对来说会弱，但是日PV2000万也没什么问题，因为不仅接受客户端请求，还与后端upstream节点进行请求并获取响应，再把响应返回给客户端，对系统资源和网络资源消耗高；

注：建议如果公司网站流量日PV在2000万以上，并发在7，8万以上才考虑用lvs+keepalived架构

2. 功能性

lvs仅支持4层tcp负载均衡，haproxy可以支持4层tcp和7层http负载均衡，nginx可以支持7层http负载均衡（新版本也支持7层负载均衡）；

nginx功能强大，配置灵活，可做web静态站点，静态缓存加速，动静分离，并支持域名，正则表达式，Location匹配，rewrite跳转，配置简单直观明了，还可以结合etc或consule做发布自动化上下线等等；

haproxy相对nginx的7层负载均衡会弱一些，灵活性不足，个人建议一般用haproxy做TCP负载均衡更合适一些；

3. 运维复杂度

lvs相对来说部署架构更复杂一些，lvs对网络是有要求，lvs必须与real server在同一个网段，也更费资源，需要多2台服务器成本；

nginx和haproxy部署架构更简单，对网络也没要求，更便于后续维护；

像对于大型的，需要进行高并发的网站或者对网络不太严格的时候，可以使用nginx；

对于大型的Web服务器的时候可以使用haproxy；

对性能有严格要求的时候可以使用lvs，就单纯从负载均衡的角度来说，lvs也许会成为主流，更适合现在大型的互联网公司。

注：lvs,nginx,haproxy要实现高可用，都需要借助keepalived软件

大型网站架构系列：负载均衡详解

本文是负载均衡详解的第四篇，主要介绍了LVS的三种请求转发模式和八种负载均衡算法，以及Haproxy的特点和负载均衡算法。具体参考文章，详见最后的链接。

三、LVS负载均衡

LVS是一个开源的软件，由毕业于国防科技大学的章文嵩博士于1998年5月创立，用来实现Linux平台下的简单负载均衡。LVS是Linux Virtual Server的缩写，意思是Linux虚拟服务器。

基于IP层的负载均衡调度技术，它在操作系统核心层上，将来自IP层的TCP/UDP请求均衡地转移到不同的服务器，从而将一组服务器构成一个高性能、高可用的虚拟服务器。

操作系统：Liunx

开发语言：C

并发性能：默认4096，可以修改但需要重新编译。

3.1.功能

LVS的主要功能是实现IP层（网络层）负载均衡，有NAT,TUN,DR三种请求转发模式。

3.1.1LVS/NAT方式的负载均衡集群

NAT是指Network Address Translation，它的转发流程是：Director机器收到外界请求，改写数据包的目标地址，按相应的调度算法将其发送到相应Real Server上，Real Server处理完该请求后，将结果数据包返回到其默认网关，即Director机器上，Director机器再改写数据包的源地址，最后将其返回给外界。这样就完成一次负载调度。

构架一个最简单的LVS/NAT方式的负载均衡集群Real Server可以是任何的操作系统，而且无需做任何特殊的设定，惟一要做的就是将其默认网关指向Director机器。Real Server可以使用局域网的内部IP(192.168.0.0/24)。Director要有两块网卡，一块网卡绑定一个外部IP地址 (10.0.0.1)，另一块网卡绑定局域网的内部IP(192.168.0.254)，作为Real Server的默认网关。

LVS/NAT方式实现起来最为简单，而且Real Server使用的是内部IP，可以节省Real IP的开销。但因为执行NAT需要重写流经Director的数据包，在速度上有一定延迟；

当用户的请求非常短，而服务器的回应非常大的情况下，会对Director形成很大压力，成为新的瓶颈，从而使整个系统的性能受到限制。

3.1.2LVS/TUN方式的负载均衡集群

TUN是指IP Tunneling，它的转发流程是：Director机器收到外界请求，按相应的调度算法,通过IP隧道发送到相应Real Server，Real Server处理完该请求后，将结果数据包直接返回给客户。至此完成一次负载调度。

最简单的LVS/TUN方式的负载均衡集群架构使用IP Tunneling技术，在Director机器和Real Server机器之间架设一个IP Tunnel，通过IP Tunnel将负载分配到Real Server机器上。Director和Real Server之间的关系比较松散，可以是在同一个网络中，也可以是在不同的网络中，只要两者能够通过IP Tunnel相连就行。收到负载分配的Real Server机器处理完后会直接将反馈数据送回给客户，而不必通过Director机器。实际应用中，服务器必须拥有正式的IP地址用于与客户机直接通信，并且所有服务器必须支持IP隧道协议。

该方式中Director将客户请求分配到不同的Real Server，Real Server处理请求后直接回应给用户，这样Director就只处理客户机与服务器的一半连接，极大地提高了Director的调度处理能力，使集群系统能容纳更多的节点数。另外TUN方式中的Real Server可以在任何LAN或WAN上运行，这样可以构筑跨地域的集群，其应对灾难的能力也更强，但是服务器需要为IP封装付出一定的资源开销，而且后端的Real Server必须是支持IP Tunneling的操作系统。

3.3.3LVS/TUN方式的负载均衡集群

DR是指Direct Routing，它的转发流程是：Director机器收到外界请求，按相应的调度算法将其直接发送到相应Real Server，Real Server处理完该请求后，将结果数据包直接返回给客户，完成一次负载调度。

构架一个最简单的LVS/DR方式的负载均衡集群Real Server和Director都在同一个物理网段中，Director的网卡IP是192.168.0.253，再绑定另一个IP： 192.168.0.254作为对外界的virtual IP，外界客户通过该IP来访问整个集群系统。Real Server在lo上绑定IP：192.168.0.254，同时加入相应的路由。

LVS/DR方式与前面的LVS/TUN方式有些类似，前台的Director机器也是只需要接收和调度外界的请求，而不需要负责返回这些请求的反馈结果，所以能够负载更多的Real Server，提高Director的调度处理能力，使集群系统容纳更多的Real Server。但LVS/DR需要改写请求报文的MAC地址，所以所有服务器必须在同一物理网段内。

3.3架构

LVS架设的服务器集群系统有三个部分组成：最前端的负载均衡层（Loader Balancer），中间的服务器群组层，用Server Array表示，最底层的数据共享存储层，用Shared Storage表示。在用户看来所有的应用都是透明的，用户只是在使用一个虚拟服务器提供的高性能服务。

LVS的体系架构如图：

技术分享

LVS的各个层次的详细介绍：

Load Balancer层：位于整个集群系统的最前端，有一台或者多台负载调度器（Director Server）组成，LVS模块就安装在Director Server上，而Director的主要作用类似于一个路由器，它含有完成LVS功能所设定的路由表，通过这些路由表把用户的请求分发给Server Array层的应用服务器（Real Server）上。同时，在Director Server上还要安装对Real Server服务的监控模块Ldirectord，此模块用于监测各个Real Server服务的健康状况。在Real Server不可用时把它从LVS路由表中剔除，恢复时重新加入。

Server Array层：由一组实际运行应用服务的机器组成，Real Server可以是WEB服务器、MAIL服务器、FTP服务器、DNS服务器、视频服务器中的一个或者多个，每个Real Server之间通过高速的LAN或分布在各地的WAN相连接。在实际的应用中，Director Server也可以同时兼任Real Server的角色。

Shared Storage层：是为所有Real Server提供共享存储空间和内容一致性的存储区域，在物理上，一般有磁盘阵列设备组成，为了提供内容的一致性，一般可以通过NFS网络文件系统共享数据，但是NFS在繁忙的业务系统中，性能并不是很好，此时可以采用集群文件系统，例如Red hat的GFS文件系统，oracle提供的OCFS2文件系统等。

从整个LVS结构可以看出，Director Server是整个LVS的核心，目前，用于Director Server的操作系统只能是Linux和FreeBSD，linux2.6内核不用任何设置就可以支持LVS功能，而FreeBSD作为 Director Server的应用还不是很多，性能也不是很好。对于Real Server，几乎可以是所有的系统平台，Linux、windows、Solaris、AIX、BSD系列都能很好的支持。

3.4均衡策略

LVS默认支持八种负载均衡策略，简述如下：

3.4.1.轮询调度（Round Robin）

调度器通过“轮询”调度算法将外部请求按顺序轮流分配到集群中的真实服务器上，它均等地对待每一台服务器，而不管服务器上实际的连接数和系统负载。

3.4.2.加权轮询（Weighted Round Robin）

调度器通过“加权轮询”调度算法根据真实服务器的不同处理能力来调度访问请求。这样可以保证处理能力强的服务器能处理更多的访问流量。调度器可以自动问询真实服务器的负载情况，并动态地调整其权值。

3.4.3.最少链接（Least Connections）

调度器通过“最少连接”调度算法动态地将网络请求调度到已建立的链接数最少的服务器上。如果集群系统的真实服务器具有相近的系统性能，采用“最小连接”调度算法可以较好地均衡负载。

3.4.4.加权最少链接（Weighted Least Connections）

在集群系统中的服务器性能差异较大的情况下，调度器采用“加权最少链接”调度算法优化负载均衡性能，具有较高权值的服务器将承受较大比例的活动连接负载。调度器可以自动问询真实服务器的负载情况，并动态地调整其权值。

3.4.5.基于局部性的最少链接（Locality-Based Least Connections）

“基于局部性的最少链接”调度算法是针对目标IP地址的负载均衡，目前主要用于Cache集群系统。该算法根据请求的目标IP地址找出该目标IP地址最近使用的服务器，若该服务器是可用的且没有超载，将请求发送到该服务器；若服务器不存在，或者该服务器超载且有服务器处于一半的工作负载，则用“最少链接” 的原则选出一个可用的服务器，将请求发送到该服务器。

3.4.6.带复制的基于局部性最少链接（Locality-Based Least Connections with Replication）

“带复制的基于局部性最少链接”调度算法也是针对目标IP地址的负载均衡，目前主要用于Cache集群系统。它与LBLC算法的不同之处是它要维护从一个目标IP地址到一组服务器的映射，而LBLC算法维护从一个目标IP地址到一台服务器的映射。该算法根据请求的目标IP地址找出该目标IP地址对应的服务器组，按“最小连接”原则从服务器组中选出一台服务器，若服务器没有超载，将请求发送到该服务器；若服务器超载，则按“最小连接”原则从这个集群中选出一台服务器，将该服务器加入到服务器组中，将请求发送到该服务器。同时，当该服务器组有一段时间没有被修改，将最忙的服务器从服务器组中删除，以降低复制的程度。

3.4.7.目标地址散列（Destination Hashing）

“目标地址散列”调度算法根据请求的目标IP地址，作为散列键（Hash Key）从静态分配的散列表找出对应的服务器，若该服务器是可用的且未超载，将请求发送到该服务器，否则返回空。

3.4.8.源地址散列（Source Hashing）

“源地址散列”调度算法根据请求的源IP地址，作为散列键（Hash Key）从静态分配的散列表找出对应的服务器，若该服务器是可用的且未超载，将请求发送到该服务器，否则返回空。

除具备以上负载均衡算法外，还可以自定义均衡策略。

3.5场景

一般作为入口负载均衡或内部负载均衡，结合反向代理服务器使用。相关架构可参考Ngnix场景架构。

4、HaProxy负载均衡

HAProxy也是使用较多的一款负载均衡软件。HAProxy提供高可用性、负载均衡以及基于TCP和HTTP应用的代理，支持虚拟主机，是免费、快速并且可靠的一种解决方案。特别适用于那些负载特大的web站点。运行模式使得它可以很简单安全的整合到当前的架构中，同时可以保护你的web服务器不被暴露到网络上。