1 LVS介绍

博客转自：http://superproxy.github.io/docs/lvs/index.html

1.1 简介

负载均衡技术有很多实现方案，有基于DNS域名轮流解析的方法、有基于客户端调度访问的方法、有基于应用层系统负载的调度方法，还有基于IP地址的调度方法。本文介绍基于传输层的负载均衡器LVS。

LVS是Linux Virtual Server的简称，也就是Linux虚拟服务器, 用现在的观点来看就是个4层（传输层tcp/udp）的负责均衡器。它是一个由章文嵩博士发起的自由软件项目，它的官方站点是www.linuxvirtualserver.org。现在LVS已经是 Linux标准内核的一部分，在Linux2.4内核以前，使用LVS时必须要重新编译内核以支持LVS功能模块，但是从Linux2.4内核以后，已经完全内置了LVS的各个功能模块，无需给内核打任何补丁，可以直接使用LVS提供的各种功能。

LVS技术要达到的目标是：通过LVS提供的负载均衡技术和Linux操作系统实现一个高性能、高可用的服务器群集，它具有良好可靠性、可扩展性和可操作性。从而以低廉的成本实现最优的服务性能。

LVS自从1998年开始，发展到现在已经是一个比较成熟的技术项目了。可以利用LVS技术实现高可伸缩的、高可用的网络服务，例如WWW服务、Cache服务、DNS服务、FTP服务、MAIL服务、视频/音频点播服务等等，有许多比较著名网站和组织都在使用LVS架设的集群系统，例如：Linux的门户网站（www.linux.com）、向RealPlayer提供音频视频服务而闻名的Real公司（www.real.com）、全球最大的开源网站（sourceforge.net）等。

1.2 主要功能

LVS目前有三种IP负载均衡技术（VS/NAT、VS/TUN和VS/DR）；十种调度算法（rrr|wrr|lc|wlc|lblc|lblcr|dh|sh|sed|nq）

1.3 优点

1.3.1 功能特性

1、抗负载能力强、是工作在网络4层之上仅作分发之用，没有流量的产生；

2、配置性比较低，这是一个缺点也是一个优点，因为没有可太多配置的东西，所以并不需要太多接触，大大减少了人为出错的机率；

3、工作稳定，自身有完整的双机热备方案；

4、无流量，保证了均衡器IO的性能不会收到大流量的影响；

5、应用范围比较广，可以对所有应用做负载均衡；

1.3.2 高可用性

LVS是一个基于内核级别的应用软件，因此具有很高的处理性能，用LVS构架的负载均衡集群系统具有优秀的处理能力，每个服务节点的故障不会影响整个系统的正常使用，同时又实现负载的合理均衡，使应用具有超高负荷的服务能力，可支持上百万个并发连接请求。如配置百兆网卡，采用VS/TUN或VS/DR调度技术，整个集群系统的吞吐量可高达1Gbits/s；如配置千兆网卡，则系统的最大吞吐量可接近10Gbits/s。

1.3.3 高可靠性

LVS负载均衡集群软件已经在企业、学校等行业得到了很好的普及应用，国内外很多大型的、关键性的web站点也都采用了LVS集群软件，所以它的可靠性在实践中得到了很好的证实。有很多以LVS做的负载均衡系统，运行很长时间，从未做过重新启动。这些都说明了LVS的高稳定性和高可靠性。

1.3.4 适用环境

LVS对前端Director Server目前仅支持Linux和FreeBSD系统，但是支持大多数的TCP和UDP协议，支持TCP协议的应用有：HTTP，HTTPS ，FTP，SMTP，，POP3，IMAP4，PROXY，LDAP，SSMTP等等。支持UDP协议的应用有：DNS，NTP，ICP，视频、音频流播放协议等。

LVS对Real Server的操作系统没有任何限制，Real Server可运行在任何支持TCP/IP的操作系统上，包括Linux，各种Unix（如FreeBSD、Sun Solaris、HP Unix等），Mac/OS和Windows等。

1.4 缺点

需要网络环境的支持

不能针对上层协议分析

如果做成硬件会更完美

1.5 类似产品

1.5.1 介绍

现在网络中常见的负载均衡主要分为两种：一种是通过硬件来进行进行，常见的硬件有比较昂贵的NetScaler、F5、Radware和Array等商用的负载均衡器，也有类似于LVS、Nginx、HAproxy的基于Linux的开源的负载均衡策略。

商用负载均衡里面NetScaler从效果上比F5的效率上更高。对于负载均衡器来说，不过商用负载均衡由于可以建立在四~七层协议之上，因此适用面更广所以有其不可替代性，他的优点就是有专业的维护团队来对这些服务进行维护、缺点就是花销太大，所以对于规模较小的网络服务来说暂时还没有需要使用。

另一种负载均衡的方式是通过软件：比较常见的有LVS、Nginx、HAproxy等，其中LVS是建立在四层协议上面的，而另外Nginx和HAproxy是建立在七层协议之上的，下面分别介绍关于

Nginx的特点是：

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

2、Nginx对网络的依赖比较小；

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

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

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

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

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

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

HAProxy的特点是：

1、HAProxy是工作在网络7层之上。

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

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

4、更多的负载均衡策略比如：动态加权轮循(Dynamic Round Robin)，加权源地址哈希(Weighted Source Hash)，加权URL哈希和加权参数哈希(Weighted Parameter Hash)已经实现

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

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

1.5.2 软负载均衡器性能对比

上图是网上的数据，LVS的实际性能可能没有展示出来，肯定要比Nginx的并发量高。

2 LVS原理篇

2.1 工作模式

LVS的IP负载均衡技术是通过IPVS模块来实现的，IPVS是LVS集群系统的核心软件，它的主要作用是：安装在Director Server上，同时在Director Server上虚拟出一个IP地址，用户必须通过这个虚拟的IP地址访问服务。这个虚拟IP一般称为LVS的VIP，即Virtual IP。访问的请求首先经过VIP到达负载调度器，然后由负载调度器从Real Server列表中选取一个服务节点响应用户的请求。

当用户的请求到达负载调度器后，调度器如何将请求发送到提供服务的Real Server节点，而Real Server节点如何返回数据给用户，是IPVS实现的重点技术，IPVS实现负载均衡机制有三种，分别是NAT、TUN和DR。

注意：

director server 、ld 、lvs负责均衡器、调度器都是同一个概念

realserver 、后端服务器也代表一个意思。

2.1.1 转发机制

2.1.1.1 三种转发机制

VS/NAT：即（Virtual Server via Network Address Translation）

也就是网络地址翻译技术实现虚拟服务器，当用户请求到达调度器时，调度器将请求报文的目标地址（即虚拟IP地址）改写成选定的Real Server地址，同时报文的目标端口也改成选定的Real Server的相应端口，最后将报文请求发送到选定的Real Server。在服务器端得到数据后，Real Server返回数据给用户时，需要再次经过负载调度器将报文的源地址和源端口改成虚拟IP地址和相应端口，然后把数据发送给用户，完成整个负载调度过程。

可以看出，在NAT方式下，用户请求和响应报文都必须经过Director Server地址重写，当用户请求越来越多时，调度器的处理能力将称为瓶颈。

VS/TUN ：即（Virtual Server via IP Tunneling）l

也就是IP隧道技术实现虚拟服务器。它的连接调度和管理与VS/NAT方式一样，只是它的报文转发方法不同，VS/TUN方式中，调度器采用IP隧道技术将用户请求转发到某个Real Server，而这个Real Server将直接响应用户的请求，不再经过前端调度器，此外，对Real Server的地域位置没有要求，可以和Director Server位于同一个网段，也可以是独立的一个网络。因此，在TUN方式中，调度器将只处理用户的报文请求，集群系统的吞吐量大大提高。

VS/DR：即（Virtual Server via Direct Routing）l

也就是用直接路由技术实现虚拟服务器。它的连接调度和管理与VS/NAT和VS/TUN中的一样，但它的报文转发方法又有不同，VS/DR通过改写请求报文的MAC地址，将请求发送到Real Server，而Real Server将响应直接返回给客户，免去了VS/TUN中的IP隧道开销。这种方式是三种负载调度机制中性能最高最好的，但是必须要求Director Server与Real Server都有一块网卡连在同一物理网段上。

2.1.1.2 三种转发机制流程

2.1.1.2.1 NAT

1. 客户端发起请求到load balancer的虚拟ip

2. load banlancer把客户请的目标地址改写为其中一个real server的，源地址改成不变。

3. realserver接受请求，并返回给load banlancer响应

4. load banlancer接受到响应，修改目标地址为不变，源地址改成自己的。

5. 客户端接受loader banlancer的响应

注意：

如果客户端和realserver在同一个网段，不会执行nat转换，realserver直接返回响应,客户端也会拒收此报文。

2.1.1.2.2 TUNNEL

1. 客户端发起请求到load balancer的虚拟ip

2. load banlancer把客户的请求包包裹，然后转发给其中的一个real server。

3. realserver接受请求，解包。得到客户端发来的原始包。

4. realserver处理，把结果通过vip直接返回给客户端。

5. 客户端接受real server的响应。

注意：

a. load balancer和realserver 直接通过ip tunnel技术重新封装、解包

b. load balancer和 realserver 使用相同的vip

c. load balnacer和realserver可以不再同一个网络

2.1.1.2.3 DR

1. 客户端发起请求到load balancer的虚拟ip

2. load banlancer把客户发送的包，修改源mac地址为vip的，目的mac地址为realserver的，然后发送给realserver

3. realserver接受请求,并处理，然后把结果通过vip直接返回给客户端。

4. 客户端接受real server的响应。

注意

a. load balancer和 realserver 使用相同的vip

b. load balancer和realserver必须在同一个网络，因为load balancer需要知道realserver的mac地址。

2.1.1.2.4 LVS-DR工作原理详解 (51CTO)

如下图所示：VS/DR的体系结构：

我将结合这幅原理图及具体的实例来讲解一下LVS-DR的原理，包括数据包、数据帧的走向和转换过程。

官方的原理说明：Director接收用户的请求，然后根据负载均衡算法选取一台realserver，将包转发过去，最后由realserver直接回复给用户。

实例场景设备清单：

说明：我这里为了方便，client是与vip同一网段的机器。如果是外部的用户访问，将client替换成gateway即可，因为IP包头是不变的，变的只是源mac地址。

① client向目标vip发出请求，Director接收。此时IP包头及数据帧头信息如下：

② VS根据负载均衡算法选择一台active的realserver(假设是192.168.57.122)，将此RIP所在网卡的mac地址作为目标mac地址，发送到局域网里。此时IP包头及数据帧头信息如下：

③ realserver(192.168.57.122)在局域网中收到这个帧，拆开后发现目标IP(VIP)与本地匹配，于是处理这个报文。随后重新封装报文，发送到局域网。此时IP包头及数据帧头信息如下：

④ 如果client与VS同一网段，那么client(192.168.57.135)将收到这个回复报文。如果跨了网段，那么报文通过gateway/路由器经由Internet返回给用户。

说明：

lvs的作者对这个写了详细的描述，请参考 http://www.linuxvirtualserver.org/zh/lvs3.html LVS集群中的IP负载均衡技术

2.1.1.3 三种转发机制的优缺点

◆Virtual Server via NAT

VS/NAT 的优点是服务器可以运行任何支持TCP/IP的操作系统，它只需要一个IP地址配置在LVS主机上，服务器组可以用私有的IP地址。缺点是它的扩充能力有限，当服务器结点数目升到20时，LVS主机本身有可能成为系统的新瓶颈，因为在VS/NAT中请求和响应封包都需要通过负载平衡LVS主机。在 Pentium 166主机上测得重写封包的平均延时为60us，假设TCP封包的平均长度为536 Bytes，则LVS主机的最大吞吐量为8.93 MBytes/s。再假设每台服务器的吞吐量为600KBytes/s，这样一个LVS主机可以带动16台服务器。

◆Virtual Server via IP Tunneling

在VS/TUN 的集群系统中，负载平衡LVS主机只将请求分配到不同的实际服务器，实际服务器将应答的资料直接返回给用户。这样，负载平衡LVS主机就可以处理巨量的请求，而不会成为系统的瓶颈。即使负载平衡LVS主机只有100Mbps的全双工网卡，虚拟服务器的最大吞吐量可以达到几Gbps。所以，VS/TUN可以极大地增加负载平衡LVS主机分配的服务器数量，它可以用来构建高性能超级服务器。VS/TUN技术对服务器的要求是所有的服务器必须支持"IP Tunneling"或者"IP Encapsulation"协议。目前，VS/TUN 的后端服务器主要运行Linux操作系统。因为"IP Tunneling"正成为各个操作系统的标准协议，所以VS/TUN也会适用运行其它操作系统的后端服务器。

◆Virtual Server via Direct Routing

同VS/TUN 一样，VS/DRLVS主机只处理客户到服务器端的连接，响应资料可以直接从独立的网络路由返回给客户。这可以极大地提高LVS集群系统的伸缩性。同 VS/TUN相比，这种方法没有IP隧道的开销，但是要求负载平衡LVS主机与实际服务器都有一块网卡连在同一物理网段上，服务器网络设备或者设备别名不作 ARP 响应。

2.1.1.4 结论

	VS/NAT	VS/TUN	VS/DR
服务器(OS)	任意	支持隧道	多数(支持Non-arp )
服务器网络	私有网络	局域网/广域网	局域网
服务器数目(100M网络)	10~20	100	多(100)
服务器网关	负载均衡器	自己的路由	自己的路由
效率	一般	高	最高

三种IP负载均衡技术中特别是后两种技术VS/TUN，VS/DR极大地提高系统的伸缩性。

2.1.2 调度算法

Director在接收到来自于Client的请求时，会基于"schedule"从RealServer中选择一个响应给Client。ipvs支持以下调度算法：（1、2为静态调度算法，3、4、5、6、7、8为动态调度算法）

1、轮询（round robin, rr)

2．加权轮询(Weighted round robin, wrr)——

新的连接请求被轮流分配至各RealServer；算法的优点是其简洁性，它无需记录当前所有连接的状态，所以它是一种无状态调度。轮叫调度算法假设所有服务器处理性能均相同，不管服务器的当前连接数和响应速度。该算法相对简单，不适用于服务器组中处理性能不一的情况，而且当请求服务时间变化比较大时，轮叫调度算法容易导致服务器间的负载不平衡。

2、目标地址散列调度（Destination Hashing，dh）

算法也是针对目标IP地址的负载均衡，但它是一种静态映射算法，通过一个散列（Hash）函数将一个目标IP地址映射到一台服务器。目标地址散列调度算法先根据请求的目标IP地址，作为散列键（Hash Key）从静态分配的散列表找出对应的服务器，若该服务器是可用的且未超载，将请求发送到该服务器，否则返回空。

3、源地址散列调度（Source Hashing，sh）

算法正好与目标地址散列调度算法相反，它根据请求的源IP地址，作为散列键（Hash Key）从静态分配的散列表找出对应的服务器，若该服务器是可用的且未超载，将请求发送到该服务器，否则返回空。它采用的散列函数与目标地址散列调度算法的相同。除了将请求的目标IP地址换成请求的源IP地址外，它的算法流程与目标地址散列调度算法的基本相似。在实际应用中，源地址散列调度和目标地址散列调度可以结合使用在防火墙集群中，它们可以保证整个系统的唯一出入口。

4、最少连接(least connected, lc)，加权最少连接(weighted least connection, wlc)——

新的连接请求将被分配至当前连接数最少的RealServer；最小连接调度是一种动态调度算法，它通过服务器当前所活跃的连接数来估计服务器的负载情况。调度器需要记录各个服务器已建立连接的数目，当一个请求被调度到某台服务器，其连接数加1；当连接中止或超时，其连接数减一。

lc：256*A+I=当前连接数 wlc：（256*A+I）/W=当前连接数【A：活动连接数 I:非活动连接数 W：权重值】

5、基于局部性的最少链接调度（Locality-Based Least Connections Scheduling，lblc）——

针对请求报文的目标IP地址的负载均衡调度，目前主要用于Cache集群系统，因为在Cache集群中客户请求报文的目标IP地址是变化的。这里假设任何后端服务器都可以处理任一请求，算法的设计目标是在服务器的负载基本平衡情况下，将相同目标IP地址的请求调度到同一台服务器，来提高各台服务器的访问局部性和主存Cache命中率，从而整个集群系统的处理能力。LBLC调度算法先根据请求的目标IP地址找出该目标IP地址最近使用的服务器，若该服务器是可用的且没有超载，将请求发送到该服务器；若服务器不存在，或者该服务器超载且有服务器处於其一半的工作负载，则用“最少链接”的原则选出一个可用的服务器，将请求发送到该服务器。

6、带复制的基于局部性最少链接调度（Locality-Based Least Connections with Replication Scheduling，lblcr）

——也是针对目标IP地址的负载均衡，目前主要用于Cache集群系统。它与LBLC算法的不同之处是它要维护从一个目标IP地址到一组服务器的映射，而 LBLC算法维护从一个目标IP地址到一台服务器的映射。对于一个“热门”站点的服务请求，一台Cache 服务器可能会忙不过来处理这些请求。这时，LBLC调度算法会从所有的Cache服务器中按“最小连接”原则选出一台Cache服务器，映射该“热门”站点到这台Cache服务器，很快这台Cache服务器也会超载，就会重复上述过程选出新的Cache服务器。这样，可能会导致该“热门”站点的映像会出现在所有的Cache服务器上，降低了Cache服务器的使用效率。LBLCR调度算法将“热门”站点映射到一组Cache服务器（服务器集合），当该“热门”站点的请求负载增加时，会增加集合里的Cache服务器，来处理不断增长的负载；当该“热门”站点的请求负载降低时，会减少集合里的Cache服务器数目。这样，该“热门”站点的映像不太可能出现在所有的Cache服务器上，从而提供Cache集群系统的使用效率。LBLCR算法先根据请求的目标IP地址找出该目标IP地址对应的服务器组；按“最小连接”原则从该服务器组中选出一台服务器，若服务器没有超载，将请求发送到该服务器；若服务器超载；则按“最小连接”原则从整个集群中选出一台服务器，将该服务器加入到服务器组中，将请求发送到该服务器。同时，当该服务器组有一段时间没有被修改，将最忙的服务器从服务器组中删除，以降低复制的程度。

7、最短的期望的延迟（Shortest Expected Delay Scheduling ,sed）

sed: (A+1)/w=当前连接数

8、最少队列调度（Never Queue Scheduling ,nq）

无需队列。如果有台realserver的连接数＝0就直接分配过去，不需要在进行sed运算

四、关于LVS追踪标记fwmark

如果LVS放置于多防火墙的网络中，并且每个防火墙都用到了状态追踪的机制，那么在回应一个针对于LVS的连接请求时必须经过此请求连接进来时的防火墙，否则，这个响应的数据包将会被丢弃

说明：作者写了详细的调度算法优缺点可以查看

http://www.linuxvirtualserver.org/zh/lvs4.html LVS集群的负载调度