三种LVS负载均衡模式及性能研究*

苏命峰

（1.湖南商务职业技术学院 2.湖南大学信息科学与工程学院）

1 前言

随着Internet飞速发展，Web、Mail、Media等网络应用已成为生活中的重要组成部分。Web等网络服务器面对越来越多的用户访问请求，仅靠单个服务器已远远不能满足需求。为了满足不断增长的服务器性能需求，实现系统的高可靠性，常采用DNS、反向代理服务器、NAT地址转换和集群等负载均衡技术。其中，章文嵩提出基于Linux集群的可伸缩网络服务体系结构（Linux Virutal Server，LVS[1]）能提供负载均衡、可伸缩性和高可用性等性能，是目前广泛应用且成熟的集群技术。本文分析网络地址转换、IP隧道和直接路由等三种实现LVS的方式，针对三种LVS模式分别设计实现一个 Web服务器集群，并采用WAS测试软件仿真大量网络用户，进行并发访问测试，最终得出三种 LVS负载均衡模式的系统性能分析结果。

2 LVS体系结构

LVS集群系统在两个层次上实现负载均衡，分别是基于IP层的IPVS和基于应用层的KTCPVS内容请求分发方式。它们均在Linux内核中实现，可将一组服务器构成一个可伸缩的、高可用的网络虚拟服务器，对外提供一个虚拟IP地址，响应用户访问请求。LVS体系结构由三部分组成，如图1所示。

2.1 负载均衡器(Load balancer)

负载均衡器是整个集群系统对外提供服务的前端，它将用户访问请求（目的地址为虚拟IP地址），根据工作模式、调度策略和内容分发到集群内部各台真实服务器上；服务器则通过负载均衡器响应请求或将结果直接返回给客户。服务器集群的结构对客户是透明的，客户访问集群系统提供的网络服务就像访问一台高性能、高可用的服务器（地址为虚拟IP地址）一样。负载均衡器可以采用 IP负载均衡技术、基于内容请求分发技术或两者相结合的技术。由于负载均衡器运行在Linux操作系统的内核中，无需在用户态和内核态之间切换，故调度开销小，占用资源少，效率较高。

图1 LVS体系结构

为避免负载均衡器单点故障导致整个 LVS集群系统不可用，可设置Master、Slaver两台负载均衡器，它们分别处于活跃、备用工作状态，两者之间通过Heartbeat[2]机制实时监测对方的健康状态。如果负载均衡器Master宕机，则Slaver立即由备用跳转为活跃状态，以确保系统的高可用性。

2.2 服务器池(Server pool)

服务器池由真正响应客户请求的真实服务器（简称节点）组成，这些节点可提供 Web、Mail、Media或DNS等网络服务。根据访问需求的变化，服务器池可灵活增加或减少节点数目，集群系统的整体访问性能随着节点数量的增加呈线性增长。LVS通过负载均衡器实时监控节点，将有故障的节点及时从服务器池中移除，确保系统的高可用性。

2.3 共享存储(Shared storage)

共享存储为服务器池提供统一的存储空间，使服务器池的节点拥有相同的内容，提供相同的服务，对于同步更新更方便，系统数据维护更简单。一般共享存储为数据库、网络文件系统或是分布式文件系统。对于大规模的集群系统，可使用分布式文件系统存储，如 AFS[3]、GFS[4]、Lustre[5]和 TFS[6]等，有良好的伸缩性和可用性。

3 LVS的3种实现模式

在负载均衡调度实现的技术中，IP负载均衡技术的应用比较广泛并且效率很高。基于 LVS的核心软件IPVS有三种IP负载均衡模式，分别是网络地址转换（Virtual Server via Network Address Translation ，VS/NAT）模式、IP隧道（Virtual Server via IP Tunneling ，VS/TUN）模式和直接路由（Virtual Server via Direct Routing ，VS/DR）模式。

3.1 VS/NAT模式

VS/NAT体系结构如图2所示。

图2 VS/NAT体系结构

负载均衡器将用户发来的请求报文的目的 IP地址（即虚拟 IP地址）和目的端口号，如“请求数据包1”，根据预设的调度算法，改写为某台真实服务器的目的IP地址和目的端口号，如“请求数据包2”，转发给真实服务器；同时在负载均衡器的Hash表中记录这两个 IP地址和端口的映射关系。真实服务器负责处理、应答请求。负载均衡器将真实服务器响应的“应答数据包1”，根据Hash表中的记录，将报文的源IP地址和源端口号改为的虚拟IP地址和对应端口，如“应答数据包2”，再返回给客户，完成整个负载调度过程。当这个连接的下一个报文到达时，负载均衡器根据Hash表中记录，将请求和应答报文进行同样的改写，转发给相同的真实服务器和用户。

用NAT技术时，请求和响应报文都必须经过负载均衡器进行目的（和源）IP地址和端口的重写，当用户请求越来越多，真实服务器数量增加到一定程度时，负载均衡器的处理能力将成为瓶颈。

3.2 VS/TUN模式

为了解决VS/NAT模式的负载均衡器瓶颈问题，针对大多数Internet服务的请求报文时间较短而响应报文时间较长的特点，VS/TUN模式的负载均衡器只负责调度请求，响应由真实服务器直接发给用户。VS/TUN体系结构见图3。

图3 VS/TUN体系结构

图3中，负载均衡器利用IP隧道技术将“请求数据包1”封装一个新的IP数据包头，新数据包头的源IP地址和目的IP地址分别为负载均衡器IP地址和根据调度算法选定的真实服务器的物理接口IP地址。支持IP隧道协议的真实服务器接收“请求数据包2”，先解封新 IP数据包头，获得的源地址和目标地址分别为用户地址和虚拟 IP地址的报文。此时服务器发现虚拟IP地址为本机预先配置的IP隧道设备地址，所以处理这个请求，并构造一个响应报文，“直接应答数据包”的源IP地址和目的IP地址分别为IP隧道设备地址（即虚拟 IP地址）和用户地址，不需经过负载均衡器，而是直接发给用户。

由于一般网络服务应答比请求报文大许多，采用VS/TUN技术后，集群系统的最大吞吐量可以提高10倍以上。

3.3 VS/DR模式

和VS/TUN模式修改请求报文第3层IP地址不同（还需修改第2层MAC地址），VS/DR模式仅通过改写请求报文的第2层MAC地址实现负载均衡。但VS/DR要求负载均衡器和真实服务器处在同一广播网段，除了给负载均衡器和真实服务器的物理网卡配置不同的 IP地址外，还需要新添加逻辑（或Loopback）网卡接口，接口都设置为虚拟 IP地址，并在真实服务器上限制针对逻辑网卡接口的ARP广播。VS/DR体系结构见图4。

图4 VS/DR体系结构

图4中，负载均衡器接收用户请求，将“请求数据包1”的源MAC地址和目的MAC地址分别修改为自己物理网卡MAC地址和根据调试算法选定的真实服务器的物理网卡MAC地址（请求数据包2），真实服务器发现“请求数据包2”的目的MAC地址为自己物理网卡MAC地址、目的IP地址为自己逻辑网卡的虚拟 IP地址时，就接收、处理并响应用户请求。并将“直接响应数据包”返回给用户（源 MAC地址和目的MAC地址分别为真实服务器的物理网卡MAC地址和去用户最近网关接口MAC地址），不需经过负载均衡器。

这种模式只需处理第2层数据帧，没有第3层IP包的处理开销，对集群中的真实服务器也没有VS/TUN模式必须支持IP隧道协议的要求，相对前两种LVS模式来说，VS/DR的负载均衡性能更好、可扩展性更强，适应更广。不足的是要求负载均衡器与真实服务器的网卡位于同一广播域，且节点全暴露在外网，安全性较差，实际应用时需在 LVS系统和外网之间安装防火墙等安全设备。

3.4 三种IP负载均衡模式的比较

三种LVS负载均衡模式的特点见表1。

表1 三种LVS负载均衡模式的比较

4 LVS性能测试

为了简化测试的物理平台，本文在一台CPU为intel Core i3M370 2.40GHz、内存为4GB的物理主机上运行VMware Workstation 7虚拟机软件，同时虚拟四台计算机（每台虚拟机的内存均为 512MB），分别是负载均衡器、两台真实服务器和测试客户端。

为测试不同 LVS负载均衡模式的性能，根据三种体系结构依次搭建LVS集群测试的软件平台，LVS集群系统提供 Web服务。负载均衡器和两台真实服务器均运行Redhat Enterprise Linux 5操作系统，都安装Apache组件，且负载均衡器安装LVS核心管理组件ipvsadm。三种LVS集群系统均采用加权最少连接(Weighted Least-Connection Scheduling)调试算法，两台真实服务器的权重都为 10。真实服务器的主页index.html为20kB大小的静态网页。测试客户端运行Windows Server 2003 Enterprise操作系统，安装Microsoft的 Web应用负载测试工具 WAS[7]（Web Applicationstress Tool），通过设置不同的并发连接数，在测试端模拟大量用户同时访问LVS集群的Web服务。每次测试运行时间为2分钟，以产生足够的请求，避免出现失真的测试结果。主要从平均响应时间长短来测试不同 LVS负载均衡模式的性能，平均响应时间参考TTFB（Time To First Byte）值（见表2）。WAS测试收到真实服务器响应的第一个数据所用的时间，值越小性能越好。

表2 三种LVS负载均衡模式的TTFB值(ms)

由表2的分析结果可得到三种LVS负载均衡模式在不同并发数下TTFB的变化曲线，如图5所示。

图5 三种LVS模式在不同并发数下TFFB的变化

由图5可知，随着并发数的增加，三种LVS负载均衡模式的TTFB值均随之增长，但在相同负载前提下，VS/DR模式的TTFB值最小，系统性能最优，VS/TUN模式次之，VS/NAT模式最差。

5 结束语

本文详细讨论了三种 LVS负载均衡技术，只从集群的系统性能看，VS/DR模式最优。除了 LVS、基于Linux的软件负载均衡集群、还有H A Proxy[8]和适应复杂网络的 Nginx[9]等。如果需要更高系统性能，可选择F5的BIG-IP[10]、Cisco的CSS[11]内容交换机、Radware的 AppDirector[12]等硬件负载均衡产品。

[1] 章文嵩.可伸缩网络服务的研究与实现[D].长沙：国防科学技术大学,2000：14-40.

[2] Alan Robertson,et al.Linux High AvailabilityProject [EB/OL].http：//www.linux-ha.org,2011-5.

[3] Daniel Lazenby.Book Review：Managing AFS：Andrew File System[M].Specialized System Consultants,Inc,1998.

[4] Steven R.Soltis,Thomas M.Ruwart,Matthew T.O’keefe.The Global File System[C].Fifth NASA Goddard Conference on Mass Storage Systems and Technologies,1996：319-342.

[5] Peter Braam.Lustre(file system)[EB/OL].http：//wiki.lustre.org,2010.

[6] Taobao.TFS(Taobao FileSystem)[EB/OL].http：//code.taobao.org/trac/tfs/wiki,2010-9.

[7] Aaron Ching,Pedro Silva,Allen Wagner.利用Web Application Stress Tool(WAS)做性能测试[EB/OL].http：//msdn.microsoft.com,2001-1.

[8] H A Proxy. The Reliable, High Performance TCP/HTTP Load Balancer[EB/OL].http：//haproxy.1wt.eu,2011-9.

[9] Igor Sysoev.Nginx[EB/OL].http：//nginx.org/en,2010-4.

[10] F5 Networks Inc.BIG-IP[EB/OL].http：//www.f5.com,2011-9.

[11] Cisco System Inc.Cisco Content Services Switches[EB/OL].http：//www.cisco.com/en/US/products/hw/contnetw/ps792/in dex.html,2011-9.

[12] Radware Ltd. AppDirector[EB/OL].http：//www.radware.com/Products/ApplicationDelivery/AppDirector/default.aspx,2011-9.