LVS详解

LVS集群的通用体系结构

LVS集群采用IP负载均衡技术和基于内容请求分发技术。调度器具有很好的吞吐率，将请求均衡地转移到不同的服务器上执行，且调度器自动屏蔽掉服务器的故障，从而将一组服务器构成一个高性能的、高可用的虚拟服务器。整个服务器集群的结构对客户是透明的，而且无需修改客户端和服务器端的程序。

图1：LVS集群的体系结构

为此，在设计时需要考虑系统的透明性、可伸缩性、高可用性和易管理性。一般来说，LVS集群采用三层结构，其体系结构如图1所示，三层主要组成部分为：

 负载调度器（load balancer），它是整个集群对外面的前端机，负责将客户的请求发送到一组服务器上执行，而客户认为服务是来自一个IP地址（我们可称之为虚拟IP地址）上的。

 服务器池（server pool），是一组真正执行客户请求的服务器，执行的服务有WEB、MAIL、FTP和DNS等。

 共享存储（shared storage），它为服务器池提供一个共享的存储区，这样很容易使得服务器池拥有相同的内容，提供相同的服务。

调度器是服务器集群系统的唯一入口点（Single Entry Point），它可以采用IP负载均衡技术、基于内容请求分发技术或者两者相结合。在IP负载均衡技术中，需要服务器池拥有相同的内容提供相同的服务。当客户请求到达时，调度器只根据服务器负载情况和设定的调度算法从服务器池中选出一个服务器，将该请求转发到选出的服务器，并记录这个调度；当这个请求的其他报文到达，也会被转发到前面选出的服务器。在基于内容请求分发技术中，服务器可以提供不同的服务，当客户请求到达时，调度器可根据请求的内容选择服务器执行请求。因为所有的操作都是在Linux操作系统核心空间中将完成的，它的调度开销很小，所以它具有很高的吞吐率。

服务器池的结点数目是可变的。当整个系统收到的负载超过目前所有结点的处理能力时，可以在服务器池中增加服务器来满足不断增长的请求负载。对大多数网络服务来说，请求间不存在很强的相关性，请求可以在不同的结点上并行执行，所以整个系统的性能基本上可以随着服务器池的结点数目增加而线性增长。

共享存储通常是数据库、网络文件系统或者分布式文件系统。服务器结点需要动态更新的数据一般存储在数据库系统中，同时数据库会保证并发访问时数据的一致性。静态的数据可以存储在网络文件系统（如NFS/CIFS）中，但网络文件系统的伸缩能力有限，一般来说，NFS/CIFS服务器只能支持3~6个繁忙的服务器结点。对于规模较大的集群系统，可以考虑用分布式文件系统，如AFS[1]、GFS[2.3]、Coda[4]和 Intermezzo[5]等。分布式文件系统可为各服务器提供共享的存储区，它们访问分布式文件系统就像访问本地文件系统一样，同时分布式文件系统可提供良好的伸缩性和可用性。此外，当不同服务器上的应用程序同时读写访问分布式文件系统上同一资源时，应用程序的访问冲突需要消解才能使得资源处于一致状态。这需要一个分布式锁管理器（Distributed Lock Manager），它可能是分布式文件系统内部提供的，也可能是外部的。开发者在写应用程序时，可以使用分布式锁管理器来保证应用程序在不同结点上并发访问的一致性。

负载调度器、服务器池和共享存储系统通过高速网络相连接，如100Mbps交换网络、Myrinet和Gigabit网络等。使用高速的网络，主要为避免当系统规模扩大时互联网络成为整个系统的瓶颈。

Graphic Monitor是为系统管理员提供整个集群系统的监视器，它可以监视系统的状态。Graphic Monitor是基于浏览器的，所以无论管理员在本地还是异地都可以监测系统的状况。为了安全的原因，浏览器要通过HTTPS（Secure HTTP）协议和身份认证后，才能进行系统监测，并进行系统的配置和管理

１

实现虚拟服务的相关方法

在网络服务中，一端是客户程序，另一端是服务程序，在中间可能有代理程序。由此看来，可以在不同的层次上实现多台服务器的负载均衡。用集群解决网络服务性能问题的现有方法主要分为以下四类。

2.1. 基于RR-DNS的解决方法

NCSA的可伸缩的WEB服务器系统就是最早基于RR-DNS（Round-Robin Domain Name System）的原型系统[1,2]。它的结构和工作流程如下图所示：

图1：基于RR-DNS的可伸缩WEB服务器 (注：本图来自文献【9】)

有一组WEB服务器，他们通过分布式文件系统AFS(Andrew File System)来共享所有的HTML文档。这组服务器拥有相同的域名（如www.ncsa.uiuc.edu），当用户按照这个域名访问时, RR-DNS服务器会把域名轮流解析到这组服务器的不同IP地址，从而将访问负载分到各台服务器上。

这种方法带来几个问题。第一，域名服务器是一个分布式系统，是按照一定的层次结构组织的。当用户就域名解析请求提交给本地的域名服务器，它会因不能直接解析而向上一级域名服务器提交，上一级域名服务器再依次向上提交，直到RR-DNS域名服器把这个域名解析到其中一台服务器的IP地址。可见，从用户到RR-DNS间存在多台域名服器，而它们都会缓冲已解析的名字到IP地址的映射,这会导致该域名服器组下所有用户都会访问同一WEB服务器，出现不同WEB服务器间严重的负载不平衡。为了保证在域名服务器中域名到IP地址的映射不被长久缓冲，RR-DNS在域名到IP地址的映射上设置一个TTL(Time To Live)值，过了这一段时间，域名服务器将这个映射从缓冲中淘汰。当用户请求，它会再向上一级域名服器提交请求并进行重新影射。这就涉及到如何设置这个 TTL值，若这个值太大，在这个TTL期间，很多请求会被映射到同一台WEB服务器上，同样会导致严重的负载不平衡。若这个值太小，例如是０，会导致本地域名服务器频繁地向RR-DNS提交请求，增加了域名解析的网络流量，同样会使RR-DNS服务器成为系统中一个新的瓶颈。

第二，用户机器会缓冲从名字到IP地址的映射，而不受TTL值的影响，用户的访问请求会被送到同一台WEB服务器上。由于用户访问请求的突发性和访问方式不同，例如有的人访问一下就离开了，而有的人访问可长达几个小时，所以各台服务器间的负载仍存在倾斜（Skew）而不能控制。假设用户在每个会话中平均请求数为20，负载最大的服务器获得的请求数额高于各服务器平均请求数的平均比率超过百分之三十。也就是说，当TTL值为0时，因为用户访问的突发性也会存在着较严重的负载不平衡。

第三，系统的可靠性和可维护性差。若一台服务器失效，会导致将域名解析到该服务器的用户看到服务中断，即使用户按 “Reload”按钮，也无济于事。系统管理员也不能随时地将一台服务器切出服务进行系统维护，如进行操作系统和应用软件升级，这需要修改RR-DNS服务器中的IP地址列表，把该服务器的IP地址从中划掉，然后等上几天或者更长的时间，等所有域名服器将该域名到这台服务器的映射淘汰，和所有映射到这台服务器的客户机不再使用该站点为止。

2.2. 基于客户端的解决方法

基于客户端的解决方法需要每个客户程序都有一定的服务器集群的知识，进而把以负载均衡的方式将请求发到不同的服务器。例如，Netscape Navigator浏览器访问Netscape的主页时，它会随机地从一百多台服务器中挑选第N台，最后将请求送往wwwN.netscape.com。然而，这不是很好的解决方法，Netscape只是利用它的Navigator避免了RR-DNS解析的麻烦，当使用IE等其他浏览器不可避免的要进行 RR-DNS解析。

Smart Client[3]是Berkeley做的另一种基于客户端的解决方法。服务提供一个Java Applet在客户方浏览器中运行，Applet向各个服务器发请求来收集服务器的负载等信息，再根据这些

２

信息将客户的请求发到相应的服务器。高可用性也在Applet中实现，当服务器没有响应时，Applet向另一个服务器转发请求。这种方法的透明性不好，Applet向各服务器查询来收集信息会增加额外的网络流量，不具有普遍的适用性。 2.3. 基于应用层负载均衡调度的解决方法

多台服务器通过高速的互联网络连接成一个集群系统，在前端有一个基于应用层的负载调度器。当用户访问请求到达调度器时，请求会提交给作负载均衡调度的应用程序，分析请求，根据各个服务器的负载情况，选出一台服务器，重写请求并向选出的服务器访问，取得结果后，再返回给用户。

应用层负载均衡调度的典型代表有Zeus负载调度器[4]、pWeb[5]、Reverse-Proxy[6]和SWEB[7]等。Zeus负载调度器是Zeus公司的商业产品，它是在Zeus Web服务器程序改写而成的，采用单进程事件驱动的服务器结构。pWeb就是一个基于Apache 1.1服务器程序改写而成的并行WEB调度程序，当一个HTTP请求到达时，pWeb会选出一个服务器，重写请求并向这个服务器发出改写后的请求，等结果返回后，再将结果转发给客户。Reverse-Proxy利用Apache 1.3.1中的Proxy模块和Rewrite模块实现一个可伸缩WEB服务器，它与pWeb的不同之处在于它要先从Proxy的cache中查找后，若没有这个副本，再选一台服务器，向服务器发送请求，再将服务器返回的结果转发给客户。SWEB是利用HTTP中的redirect错误代码，将客户请求到达一台WEB服务器后，这个WEB服务器根据自己的负载情况，自己处理请求，或者通过redirect错误代码将客户引到另一台WEB服务器，以实现一个可伸缩的WEB服务器。

基于应用层负载均衡调度的多服务器解决方法也存在一些问题。第一，系统处理开销特别大，致使系统的伸缩性有限。当请求到达负载均衡调度器至处理结束时，调度器需要进行四次从核心到用户空间或从用户空间到核心空间的上下文切换和内存复制；需要进行二次TCP连接，一次是从用户到调度器，另一次是从调度器到真实服务器；需要对请求进行分析和重写。这些处理都需要不小的ＣＰＵ、内存和网络等资源开销，且处理时间长。所构成系统的性能不能接近线性增加的，一般服务器组增至3或4台时，调度器本身可能会成为新的瓶颈。所以，这种基于应用层负载均衡调度的方法的伸缩性极其有限。第二，基于应用层的负载均衡调度器对于不同的应用，需要写不同的调度器。以上几个系统都是基于HTTP协议，若对于FTP、Mail、POP3等应用，都需要重写调度器。 2.4. 基于IP层负载均衡调度的解决方法

用户通过虚拟IP地址（Virtual IP Address）访问服务时，访问请求的报文会到达负载调度器，由它进行负载均衡调度，从一组真实服务器选出一个，将报文的目标地址Virtual IP Address改写成选定服务器的地址，报文的目标端口改写成选定服务器的相应端口，最后将报文发送给选定的服务器。真实服务器的回应报文经过负载调度器时，将报文的源地址和源端口改为Virtual IP Address和相应的端口，再把报文发给用户。Berkeley的MagicRouter[8]、Cisco的LocalDirector、 Alteon的ACEDirector和F5的Big/IP等都是使用网络地址转换方法。MagicRouter是在Linux 1.3版本上应用快速报文插入技术，使得进行负载均衡调度的用户进程访问网络设备接近核心空间的速度，降低了上下文切换的处理开销，但并不彻底，它只是研究的原型系统，没有成为有用的系统存活下来。Cisco的LocalDirector、Alteon的ACEDirector和F5的Big/IP是非常昂贵的商品化系统，它们支持部分TCP/UDP协议，有些在ICMP处理上存在问题。

IBM的TCP Router[9]使用修改过的网络地址转换方法在SP/2系统实现可伸缩的WEB服务器。TCP Router修改请求报文的目标地址并把它转发给选出的服务器，服务器能把响应报文的源地址置为TCP Router地址而非自己的地址。这种方法的好处是响应报文可以直接返回给客户，坏处是每台服务器的操作系统内核都需要修改。IBM的 NetDispatcher[10]是TCP Router的后继者，它将报文转发给服务器，而服务器在non-ARP的设备配置路由器的地址。这种方法与LVS集群中的VS/DR类似，它具有很高的可伸缩性，但一套在IBM SP/2和NetDispatcher需要上百万美金。总的来说，IBM的技术还挺不错的。

在贝尔实验室的 ONE-IP[11]中，每台服务器都的IP地址，但都用IP Alias配置上同一

３

VIP地址，采用路由和广播两种方法分发请求，服务器收到请求后按VIP地址处理请求，并以VIP为源地址返回结果。这种方法也是为了避免回应报文的重写，但是每台服务器用IP Alias配置上同一VIP地址，会导致地址冲突，有些操作系统会出现网络失效。通过广播分发请求，同样需要修改服务器操作系统的源码来过滤报文，使得只有一台服务器处理广播来的请求。

微软的Windows NT负载均衡服务（Windows NT Load Balancing Service，WLBS）[12]是1998年底收购Valence Research公司获得的，它与ONE-IP中的基于本地过滤方法一样。WLBS作为过滤器运行在网卡驱动程序和TCP/IP协议栈之间，获得目标地址为VIP的报文，它的过滤算法检查报文的源IP地址和端口号，保证只有一台服务器将报文交给上一层处理。但是，当有新结点加入和有结点失效时，所有服务器需要协商一个新的过滤算法，这会导致所有有Session的连接中断。同时，WLBS需要所有的服务器有相同的配置，如网卡速度和处理能力。

3. 通过NAT实现虚拟服务器（VS/NAT）

由于IPv4中IP地址空间的日益紧张和安全方面的原因，很多网络使用保留IP地址（10.0.0.0/255.0.0.0、 172.16.0.0/255.128.0.0和192.168.0.0/255.255.0.0）[, 65, 66]。这些地址不在Internet上使用，而是专门为内部网络预留的。当内部网络中的主机要访问Internet或被Internet访问时，就需要采用网络地址转换（Network Address Translation, 以下简称NAT），将内部地址转化为Internets上可用的外部地址。NAT的工作原理是报文头（目标地址、源地址和端口等）被正确改写后，客户相信它们连接一个IP地址，而不同IP地址的服务器组也认为它们是与客户直接相连的。由此，可以用NAT方法将不同IP地址的并行网络服务变成在一个IP地址上的一个虚拟服务。

VS/NAT的体系结构如图2所示。在一组服务器前有一个调度器，它们是通过Switch/HUB相连接的。这些服务器提供相同的网络服务、相同的内容，即不管请求被发送到哪一台服务器，执行结果是一样的。服务的内容可以复制到每台服务器的本地硬盘上，可以通过网络文件系统（如NFS）共享，也可以通过一个分布式文件系统来提供。

图2：VS/NAT的体系结构

客户通过Virtual IP Address（虚拟服务的IP地址）访问网络服务时，请求报文到达调度器，调度器根据连接调度算法从一组真实服务器中选出一台服务器，将报文的目标地址 Virtual IP Address改写成选定服务器的地址，报文的目标端口改写成选定服务器的相应端口，最后将修改后的报文发送给选出的服务器。同时，调度器在连接Hash 表中记录这个连接，当这个连接的下一个报文到达时，从连接Hash表中可以得到原选定服务器的地址和端口，进行同样的改写操作，并将报文传给原选定的服务器。当来自真实服务器的响应报文经过调度器时，调度器将报文的源地址和源端口改为Virtual IP Address和相应的端口，再把报文发给用户。我们在连接上引入一个状态机，不同的报文会使得连接处于不同的状态，不同的状态有不同的超时值。在TCP 连接中，根据标准的TCP有限状态机进行状态迁移，这里我们不一一叙述，请参见W. Richard Stevens的《TCP/IP Illustrated Volume I》；在UDP中，我们只设置一个UDP状态。不同状态的超时值是可以设置的，在缺省情况下，SYN状态的超时为1分钟，ESTABLISHED状态的超时为15分钟，FIN状态的超时为1分钟；UDP状态的超时为5分钟。当连接终止或超时，调度器将这个连接从连接Hash表中删除。

这样，客户所看到的只是在Virtual IP Address上提供的服务，而服务器集群的结构对用户是透明的。对改写后的报文，应用增量调整Checksum的算法调整TCP Checksum的值，避免了扫描整个报文来计算Checksum的开销。

在一些网络服务中，它们将IP地址或者端口号在报文的数据中传送，若我们只对报文头的IP地址和端口号作转换，这样就会出现不一致性，服务会中断。所以，针对这些服务，需要编写相应的应用模块来转换报文数据中的IP地址或者端口号。我们所知道有这个问题的网络服务有FTP、IRC、H.323、 CUSeeMe、Real Audio、Real Video、Vxtreme / Vosiac、VDOLive、VIVOActive、True Speech、RSTP、PPTP、StreamWorks、NTT AudioLink、NTT SoftwareVision、

４

Yamaha MIDPlug、iChat Pager、Quake和Diablo。 下面，举个例子来进一步说明VS/NAT，如图3所示：

图3：VS/NAT的例子

VS/NAT 的配置如下表所示，所有到IP地址为202.103.106.5和端口为80的流量都被负载均衡地调度的真实服务器172.16.0.2:80和 172.16.0.3:8000上。目标地址为202.103.106.5:21的报文被转移到172.16.0.3:21上。而到其他端口的报文将被拒绝。 Protocol TCP TCP Virtual IP Address 202.103.106.5 202.103.106.5 Port 80 21 Real IP Address 172.16.0.2 172.16.0.3 172.16.0.3 Port 80 8000 21 Weight 1 2 1 从以下的例子中，我们可以更详细地了解报文改写的流程。 访问Web服务的报文可能有以下的源地址和目标地址： SOURCE 202.100.1.2:3456 DEST 202.103.106.5:80 调度器从调度列表中选出一台服务器，例如是172.16.0.3:8000。该报文会被改写为如下地址，并将它发送给选出的服务器。 SOURCE 202.100.1.2:3456 DEST 172.16.0.3:8000 从服务器返回到调度器的响应报文如下： SOURCE 172.16.0.3:8000 DEST 202.100.1.2:3456 响应报文的源地址会被改写为虚拟服务的地址，再将报文发送给客户： SOURCE 202.103.106.5:80 DEST 202.100.1.2:3456 这样，客户认为是从202.103.106.5:80服务得到正确的响应，而不会知道该请求是服务器172.16.0.2还是服务器172.16.0.3处理的。 4. 通过IP隧道实现虚拟服务器（VS/TUN）

在VS/NAT 的集群系统中，请求和响应的数据报文都需要通过负载调度器，当真实服务器的数目在10台和20台之间时，负载调度器将成为整个集群系统的新瓶颈。大多数 Internet服务都有这样的特点：请求报文较短而响应报文往往包含大量的数据。如果能将请求和响应分开处理，即在负载调度器中只负责调度请求而响应直接返回给客户，将极大地提高整个集群系统的吞吐量。

IP隧道（IP tunneling）是将一个IP报文封装在另一个IP报文的技术，这可以使得目标为一个IP地址的数据报文能被封装和转发到另一个IP地址。IP隧道技术亦称为IP封装技术（IP encapsulation）。IP隧道主要用于移动主机和虚拟私有网络（Virtual Private Network），在其中隧道都是静态建立的，隧道一端有一个IP地址，另一端也有唯一的IP地址。

我们利用IP隧道技术将请求报文封装转发给后端服务器，响应报文能从后端服务器直接返回给客户。但在这里，后端服务器有一组而非一个，所以我们不可能静态地建立一一对应的隧道，而是动态地选择一台服务器，将请求报文封装和转发给选出的服务器。这样，我们可

５

以利用IP隧道的原理将一组服务器上的网络服务组成在一个IP地址上的虚拟网络服务。 VS/TUN的体系结构如图4所示，各个服务器将VIP地址配置在自己的IP隧道设备上。

图4：VS/TUN的体系结构

VS/TUN 的工作流程如图5所示：它的连接调度和管理与VS/NAT中的一样，只是它的报文转发方法不同。调度器根据各个服务器的负载情况，动态地选择一台服务器，将请求报文封装在另一个IP报文中，再将封装后的IP报文转发给选出的服务器；服务器收到报文后，先将报文解封获得原来目标地址为VIP的报文，服务器发现VIP地址被配置在本地的IP隧道设备上，所以就处理这个请求，然后根据路由表将响应报文直接返回给客户。

图5：VS/TUN的工作流程

在这里需要指出，根据缺省的TCP/IP协议栈处理，请求报文的目标地址为VIP，响应报文的源地址肯定也为VIP，所以响应报文不需要作任何修改，可以直接返回给客户，客户认为得到正常的服务，而不会知道究竟是哪一台服务器处理的。

图6：半连接的TCP有限状态机

5. 通过直接路由实现虚拟服务器（VS/DR）

跟VS/TUN 方法相同，VS/DR利用大多数Internet服务的非对称特点，负载调度器中只负责调度请求，而服务器直接将响应返回给客户，可以极大地提高整个集群系统的吞吐量。该方法与IBM的NetDispatcher产品中使用的方法类似（其中服务器上的IP地址配置方法是相似的），但IBM的 NetDispatcher是非常昂贵的商品化产品，我们也不知道它内部所使用的机制，其中有些是IBM的专利。

VS/DR的体系结构如图 7所示：调度器和服务器组都必须在物理上有一个网卡通过不分断的局域网相连，如通过高速的交换机或者HUB相连。VIP地址为调度器和服务器组共享，调度器配置的VIP地址是对外可见的，用于接收虚拟服务的请求报文；所有的服务器把VIP地址配置在各自的Non-ARP网络设备上，它对外面是不可见的，只是用于处理目标地址为VIP的网络请求。

图7：VS/DR的体系结构

VS/DR 的工作流程如图8所示：它的连接调度和管理与VS/NAT和VS/TUN中的一样，它的报文转发方法又有不同，将报文直接路由给目标服务器。在VS/DR 中，调度器根据各个服务器的负载情况，动态地选择一台服务器，不修改也不封装IP报文，而是将数据帧的MAC地址改为选出服务器的MAC地址，再将修改后的数据帧在与服务器组的局域网上发送。因为数据帧的MAC地址是选出的服务器，所以服务器肯定可以收到这个数据帧，从中可以获得该IP报文。当服务器发现报文的目标地址VIP是在本地的网络设备上，服务器处理这个报文，然后根据路由表将响应报文直接返回给客户。

图8：VS/DR的工作流程

在VS/DR中，根据缺省的TCP/IP协议栈处理，请求报文的目标地址为VIP，响应报文的源地址肯定也为VIP，所以响应报文不需要作任何修改，可以直接返回给客户，客户认为得到正常的服务，而不会知道是哪一台服务器处理的。

６

VS/DR负载调度器跟VS/TUN一样只处于从客户到服务器的半连接中，按照半连接的TCP有限状态机进行状态迁移。 6.三种方法的优缺点比较

三种IP负载均衡技术的优缺点归纳在下表中： _ Server server network server number server gateway VS/NAT any private low (10~20) load balancer VS/TUN Tunneling LAN/WAN High (100) own router VS/DR Non-arp device LAN High (100) Own router 注：以上三种方法所能支持最大服务器数目的估计是假设调度器使用100M网卡，调度器的硬件配置与后端服务器的硬件配置相同，而且是对一般Web服务。使用更高的硬件配置（如千兆网卡和更快的处理器）作为调度器，调度器所能调度的服务器数量会相应增加。当应用不同时，服务器的数目也会相应地改变。所以，以上数据估计主要是为三种方法的伸缩性进行量化比较。

6.1. Virtual Server via NAT

VS/NAT 的优点是服务器可以运行任何支持TCP/IP的操作系统，它只需要一个IP地址配置在调度器上，服务器组可以用私有的IP地址。缺点是它的伸缩能力有限，当服务器结点数目升到20时，调度器本身有可能成为系统的新瓶颈，因为在VS/NAT中请求和响应报文都需要通过负载调度器。 我们在Pentium 166 处理器的主机上测得重写报文的平均延时为60us，性能更高的处理器上延时会短一些。假设TCP报文的平均长度为536 Bytes，则调度器的最大吞吐量为8.93 MBytes/s. 我们再假设每台服务器的吞吐量为800KBytes/s，这样一个调度器可以带动10台服务器。（注：这是很早以前测得的数据） 基于 VS/NAT的的集群系统可以适合许多服务器的性能要求。如果负载调度器成为系统新的瓶颈，可以有三种方法解决这个问题：混合方法、VS/TUN和 VS/DR。在DNS混合集群系统中，有若干个VS/NAT负载调度器，每个负载调度器带自己的服务器集群，同时这些负载调度器又通过RR-DNS组成简单的域名。但VS/TUN和VS/DR是提高系统吞吐量的更好方法。

对于那些将IP地址或者端口号在报文数据中传送的网络服务，需要编写相应的应用模块来转换报文数据中的IP地址或者端口号。这会带来实现的工作量，同时应用模块检查报文的开销会降低系统的吞吐率。 6.2. Virtual Server via IP Tunneling

在VS/TUN 的集群系统中，负载调度器只将请求调度到不同的后端服务器，后端服务器将应答的数据直接返回给用户。这样，负载调度器就可以处理大量的请求，它甚至可以调度百台以上的服务器（同等规模的服务器），而它不会成为系统的瓶颈。即使负载调度器只有100Mbps的全双工网卡，整个系统的最大吞吐量可超过 1Gbps。所以，VS/TUN可以极大地增加负载调度器调度的服务器数量。VS/TUN调度器可以调度上百台服务器，而它本身不会成为系统的瓶颈，可以用来构建高性能的超级服务器。

VS/TUN技术对服务器有要求，即所有的服务器必须支持“IP Tunneling”或者“IP Encapsulation”协议。目前，VS/TUN的后端服务器主要运行Linux操作系统，我们没对其他操作系统进行测试。因为“IP Tunneling”正成为各个操作系统的标准协议，所以VS/TUN应该会适用运行其他操作系统的后端服务器。 6.3. Virtual Server via Direct Routing

７

跟VS/TUN方法一样，VS/DR调度器只处理客户到服务器端的连接，响应数据可以直接从的网络路由返回给客户。这可以极大地提高LVS集群系统的伸缩性。

跟VS/TUN相比，这种方法没有IP隧道的开销，但是要求负载调度器与实际服务器都有一块网卡连在同一物理网段上，服务器网络设备（或者设备别名）不作ARP响应，或者能将报文重定向（Redirect）到本地的Socket端口上。

内核中的连接调度算法

IPVS在内核中的负载均衡调度是以连接为粒度的。在HTTP协议（非持久）中，每个对象从WEB服务器上获取都需要建立一个TCP连接，同一用户的不同请求会被调度到不同的服务器上，所以这种细粒度的调度在一定程度上可以避免单个用户访问的突发性引起服务器间的负载不平衡。

在内核中的连接调度算法上，IPVS已实现了以下八种调度算法：

 轮叫调度（Round-Robin Scheduling）

 加权轮叫调度（Weighted Round-Robin Scheduling）  最小连接调度（Least-Connection Scheduling）

 加权最小连接调度（Weighted Least-Connection Scheduling）

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

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

 目标地址散列调度（Destination Hashing Scheduling）  源地址散列调度（Source Hashing Scheduling）

下面，我们先介绍这八种连接调度算法的工作原理和算法流程，会在以后的文章中描述怎么用它们。 2.1. 轮叫调度

轮叫调度（Round Robin Scheduling）算法就是以轮叫的方式依次将请求调度不同的服务器，即每次调度执行i = (i + 1) mod n，并选出第i台服务器。算法的优点是其简洁性，它无需记录当前所有连接的状态，所以它是一种无状态调度。

在系统实现时，我们引入了一个额外条件，当服务器的权值为零时，表示该服务器不可用而不被调度。这样做的目的是将服务器切出服务（如屏蔽服务器故障和系统维护），同时与其他加权算法保持一致。所以，算法要作相应的改动，它的算法流程如下： 轮叫调度算法流程

轮叫调度算法假设所有服务器处理性能均相同，不管服务器的当前连接数和响应速度。该算法相对简单，不适用于服务器组中处理性能不一的情况，而且当请求服务时间变化比较大时，轮叫调度算法容易导致服务器间的负载不平衡。

虽然Round-Robin DNS方法也是以轮叫调度的方式将一个域名解析到多个IP地址，但轮叫DNS方法的调度粒度是基于每个域名服务器的，域名服务器对域名解析的缓存会妨碍轮叫解析域名生效，这会导致服务器间负载的严重不平衡。这里，IPVS轮叫调度算法的粒度是基于每个连接的，同一用户的不同连接都会被调度到不同的服务器上，所以这种细粒度的轮叫调度要比DNS的轮叫调度优越很多。

８

2.2. 加权轮叫调度

加权轮叫调度（Weighted Round-Robin Scheduling）算法可以解决服务器间性能不一的情况，它用相应的权值表示服务器的处理性能，服务器的缺省权值为1。假设服务器A的权值为1，B的权值为2，则表示服务器B的处理性能是A的两倍。加权轮叫调度算法是按权值的高低和轮叫方式分配请求到各服务器。权值高的服务器先收到的连接，权值高的服务器比权值低的服务器处理更多的连接，相同权值的服务器处理相同数目的连接数。加权轮叫调度算法流程如下：

加权轮叫调度算法流程

例如，有三个服务器A、B和C分别有权值4、3和2，则在一个调度周期内(mod sum(W(Si)))调度序列为AABABCABC。加权轮叫调度算法还是比较简单和高效。当请求的服务时间变化很大，单独的加权轮叫调度算法依然会导致服务器间的负载不平衡。

从上面的算法流程中，我们可以看出当服务器的权值为零时，该服务器不被被调度；当所有服务器的权值为零，即对于任意i有W(Si)=0，则没有任何服务器可用，算法返回NULL，所有的新连接都会被丢掉。加权轮叫调度也无需记录当前所有连接的状态，所以它也是一种无状态调度。 2.3. 最小连接调度

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

当各个服务器有相同的处理性能时，最小连接调度算法能把负载变化大的请求分布平滑到各个服务器上，所有处理时间比较长的请求不可能被发送到同一台服务器上。但是，当各个服务器的处理能力不同时，该算法并不理想，因为TCP连接处理请求后会进入TIME_WAIT状态，TCP的TIME_WAIT一般为2分钟，此时连接还占用服务器的资源，所以会出现这样情形，性能高的服务器已处理所收到的连接，连接处于TIME_WAIT状态，而性能低的服务器已经忙于处理所收到的连接，还不断地收到新的连接请求。 2.4. 加权最小连接调度

加权最小连接调度（Weighted Least-Connection Scheduling）算法是最小连接调度的超集，各个服务器用相应的权值表示其处理性能。服务器的缺省权值为1，系统管理员可以动态地设置服务器的权值。加权最小连接调度在调度新连接时尽可能使服务器的已建立连接数和其权值成比例。加权最小连接调度的算法流程如下：

９

本文主要讲述了LVS集群中的三种IP负载均衡技术。在分析网络地址转换方法（VS/NAT）的缺点和网络服务的非对称性的基础上，我们给出了通过IP隧道实现虚拟服务器的方法VS/TUN，和通过直接路由实现虚拟服务器的方法VS/DR，极大地提高了系统的伸缩性。

前期准备：

试验环境 Red Hat Enterprise Linux 4 U2 软件版本 ipvsadm-1.24.tar.gz 编译安装注意 #pwd /usr/src

#ln -s kernels/2.6.9-22.EL.i686 linux 如果没有目录则安装RPEM包kernel-devel-2.6.9-22.EL

#rpmbuild -tb ipvsadm-1.24.tar.gz

#rpm -ivh /usr/src/redhat/RPEM/i386/ipvsadm-1.24-6.i386.rpm 正常使用时提示： [root@lvs boot]# ipvsadm

IP Virtual Server version 1.2.0 (size=65536) Prot LocalAddress:Port Scheduler Flags

-> RemoteAddress:Port Forward Weight ActiveConn InActConn 一、NAT方式

Load Balance：192.168.1.1(内部IP） 125.70.253.211（公网IP） RealServer1： 192.168.1.2 RealServer2： 192.168.1.3 nameserver: 192.168.1.1

gateway: 192.168.1.1 (使用正确地址，或者使用本机地址，否则会出现刷新ipvsadm rule时很慢)

１０

1.开启路由机制

#echo 1 > /proc/sys/net/ipv4/ip_forward 注意：

永久修改要修改sysctl.conf 2.加载nat模块 #modprobe iptable_nat 注意：

用lsmod检查，另如果不加载此模块，也可以在第一次访问时成功，但是会在再次访问时出现延迟过长，或访问超时现象。 3.加载rule

#ipvsadm -A -t 125.70.253.211:80 -s rr

#ipvsadm -a -t 125.70.253.211:80 -r 192.168.1.2:80 -m #ipvsadm -a -t 125.70.253.211:80 -r 192.168.1.3:80 -m rr 轮询方式 -m 设置为NAT方式 4.保存rule

#ipvsadm ——save > /etc/sysconfig/ipvsadm 5.RealServer设置 RealServer1: ip: 192.168.1.2 gateway: 192.168.1.1 nameserver: 192.168.1.1

开启HTTP服务，确认自己能够访问。 RealServer2: ip: 192.168.1.3 gateway: 192.168.1.1

１１

nameserver: 192.168.1.1

开启HTTP服务，确认自己能够访问。页面与realserver1不同就可以。 7.测试

选择一台主机，ip设置125.70.253.211 ，访问http://125.70.253.211,反复刷新网页，每次出现的网页不同则表示成功。 二、Direct Routing方式

Load Balance：192.168.1.1

lo:1-------10.0.0.1/24（Virtual IP） RealServer1： 192.168.1.2 RealServer2： 192.168.1.3

网关: 192.168.1.254 (内部IP） 125.70.253.211 （外部IP）

首先网关能和lvs服务器的虚拟IP地址通信，然后做DNAT将80端口的请求转发给lvs LVS设置： 1.开启路由机制

#echo 1 > /proc/sys/net/ipv4/ip_forward 注意：

永久修改要修改sysctl.conf 2.加载rule

#ipvsadm -A -t 10.0.0.1:80 -s rr

#ipvsadm -a -t 10.0.0.1:80 -r 192.168.1.2:80 -g #ipvsadm -a -t 10.0.0.1:80 -r 192.168.1.3:80 -g rr 轮询方式 -g 设置为DR方式 3.保存rule

#ipvsadm ——save > /etc/sysconfig/ipvsadm

１２

4.邦定vip

#ifconfig eth0:1 10.0.0.1 netmask 255.255.255.0 borcast 10.0.0.255 4.RealServer设置 RealServer1: ip: 192.168.1.2 gateway: 192.168.1.254

#ifconfig lo:1 10.0.0.1 netmask 255.255.255.255 borcast 10.0.0.1

#echo 1 > /proc/sys/net/ipv4/conf/lo/arp_ignore 注释：这四句目的是为了关闭ARP广播响应

#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 开启HTTP服务，确认自己能够访问。 RealServer2: ip: 192.168.1.3 gateway: 192.168.1.254

#ifconfig lo:1 10.0.0.1 netmask 255.255.255.255 borcast 10.0.0.1 #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

开启HTTP服务，确认自己能够访问。页面与realserver1不同就可以。 5.测试

访问http://125.70.253.211,反复刷新网页，每次出现的网页不同则表示成功。 三、IP Tunnel方式 server：

１３

eth0:10.0.0.3 (测试时使用的OPENVPN) gateway server： eth0:10.0.0.2 eth1:192.168.1.254 LVS Director Servers: Load Balance：192.168.1.1 Virtual IP: 10.0.0.1 nameserver: 192.168.1.254 gateway: 192.168.1.254 RealServer1： ip: 192.168.1.2 gateway: 192.168.1.254

tun0: 20.0.0.1 (这个是连接到后有服务器分配到的) RealServer2： ip: 172.0.0.1 gateway: 172.0.0.254

tun0: 20.0.0.2 (这个是连接到后有服务器分配到的) 1.开启路由机制

#echo 1 > /proc/sys/net/ipv4/ip_forward 注意：

永久修改要修改sysctl.conf 2.加载rule

#ipvsadm -A -t 10.0.0.1:80 -s rr

#ipvsadm -a -t 10.0.0.1:80 -r 20.0.0.1:80 -i (RS1的地址指定,也可以选择本地地址192.168.1.2)

#ipvsadm -a -t 10.0.0.1:80 -r 20.0.0.2:80 -i

１４

rr 轮询方式

-i 设置为IP Tunnel方式 3.保存rule

#ipvsadm ——save > /etc/sysconfig/ipvsadm 4.邦定vip

#ifconfig eth0:1 10.0.0.1 netmask 255.255.255.0 borcast 10.0.0.255 5.RealServer设置 RealServer1： ip: 192.168.1.2 gateway: 192.168.1.254 nameserver: 192.168.1.254 tun0: 20.0.0.1

#ifconfig tunl0 10.0.0.1 netmask 255.255.255.255 borcast 10.0.0.1

#echo 1 > /proc/sys/net/ipv4/conf/tunl0/arp_ignore 注释：这四句目的是为了关闭ARP广播响应

#echo 2 > /proc/sys/net/ipv4/conf/tunl0/arp_announce #echo 1 > /proc/sys/net/ipv4/conf/all/arp_ignore #echo 2 > /proc/sys/net/ipv4/conf/all/arp_announce 开启HTTP服务，确认自己能够访问。 RealServer2: RealServer2： ip: 172.0.0.1 gateway: 172.0.0.254 nameserver: 172.0.0.254 tun0: 20.0.0.2

#ifconfig tunl0 10.0.0.1 netmask 255.255.255.255 borcast 10.0.0.1

１５

#echo 1 > /proc/sys/net/ipv4/conf/tunl0/arp_ignore #echo 2 > /proc/sys/net/ipv4/conf/tunl0/arp_announce #echo 1 > /proc/sys/net/ipv4/conf/all/arp_ignore #echo 2 > /proc/sys/net/ipv4/conf/all/arp_announce

开启HTTP服务，确认自己能够访问。页面与realserver1不同就可以。 6.测试

在网关作测试即可，访问http://10.0.0.1,反复刷新网页，每次出现的网页不同则表示成功。

１６