架构文摘：LSV负载均衡技术笔记

以你之姓@ 2022-05-23 04:04 689阅读 0赞

# 一、LVS介绍 #

在本部分，我们将介绍Linux服务器集群系统——LVS（Linux Virtual Server）项目的产生背景和目标，并描述LVS服务器集群框架及目前提供的软件，列举LVS集群系统的特点和一些实际应用。

## 1、背景 ##

当今计算机技术已进入以网络为中心的计算时期。由于客户/服务器模型的简单性、易管理性和易维护性，客户/服务器计算模式在网上被大量采用。同时，Internet的飞速发展给网络带宽和服务器带来巨大的挑战。

因此，对于大型网站的构建，其对于用硬件和软件方法实现高可伸缩性、高可用网络服务的需求不断增长，这种需求可以归结为以下几点：

*  **可伸缩性（Scalability）**：当服务的负载增长时，系统能被扩展来满足需求，且不降低服务质量。
 *  **高可用性（Availability）**：尽管部分硬件和软件会发生故障，整个系统的服务必须是7\*24小时可用的。
 *  **可管理性（Manageability）**：整个系统可能在物理上很大，但应该容易管理。
 *  **价格有效性（Cost-Effectiveness）**：整个系统实现是经济的、易支付的。

## 2、服务器集群系统 ##

由于SMP的可扩展能力有限，SMP服务器显然不能满足高可伸缩、高可用网络服务中的负载处理能力不断增长需求。随着负载不断增长，会导致服务器不断地升级。这种服务器升级有下列不足：一是升级过程繁琐，机器切换会使服务暂时中断，并造成原有计算资源的浪费；二是越往高端的服务器，所花费的代价越大；三是 SMP服务器是单一故障点（Single Point of Failure），一旦该服务器或应用软件失效，会导致整个服务的中断。

通过高性能网络或局域网互联的服务器集群正成为实现高可伸缩的、高可用网络服务的有效结构。这种松耦合结构的服务器集群系统有下列优点：

*  性能  
    网络服务的工作负载通常是大量相互独立的任务，通过一组服务器分而治之，可以获得很高的整体性能。
 *  性价比  
    组成集群系统的PC服务器或RISC服务器和标准网络设备因为大规模生产降低成本，价格低，具有最高的性能/价格比。若整体性能随着结点数的增长而接近线性增加，该系统的性能/价格比接近于PC服务器。所以，这种松耦合结构比紧耦合的多处理器系统具有更好的性能/价格比。
 *  可伸缩性  
    集群系统中的结点数目可以增长到几千个，乃至上万个，其伸缩性远超过单台超级计算机。
 *  高可用性  
    在硬件和软件上都有冗余，通过检测软硬件的故障，将故障屏蔽，由存活结点提供服务，可实现高可用性。

当然，用服务器集群系统实现可伸缩网络服务也存在很多挑战性的工作：

*  透明性（Transparency）  
    如何高效地使得由多个独立计算机组成的松藕合的集群系统构成一个虚拟服务器；客户端应用程序与集群系统交互时，就像与一台高性能、高可用的服务器交互一样，客户端无须作任何修改。部分服务器的切入和切出不会中断服务，这对用户也是透明的。
 *  性能（Performance）  
    性能要接近线性加速，这需要设计很好的软硬件的体系结构，消除系统可能存在的瓶颈。将负载较均衡地调度到各台服务器上。
 *  高可用性（Availability）  
    需要设计和实现很好的系统资源和故障的监测和处理系统。当发现一个模块失败时，要这模块上提供的服务迁移到其他模块上。在理想状况下，这种迁移是即时的、自动的。
 *  可管理性（Manageability）  
    要使集群系统变得易管理，就像管理一个单一映像系统一样。在理想状况下，软硬件模块的插入能做到即插即用（Plug & Play）。
 *  可编程性（Programmability）  
    在集群系统上，容易开发应用程序。

## 3、LVS项目 ##

针对高可伸缩、高可用网络服务的需求，我们给出了基于IP层和基于内容请求分发的负载平衡调度解决方法，并在Linux内核中实现了这些方法，将一组服务器构成一个实现可伸缩的、高可用网络服务的虚拟服务器。

虚拟服务器的体系结构如下图所示：

![虚拟服务器体系结构][virtual_server_architecture.png]

一组服务器通过高速的局域网或者地理分布的广域网相互连接，在它们的前端有一个**负载调度器（Load Balancer）**。负载调度器能无缝地将网络请求调度到真实服务器上，从而使得服务器集群的结构对客户是透明的，客户访问集群系统提供的网络服务就像访问一台高性能、高可用的服务器一样。客户程序不受服务器集群的影响不需做任何修改。系统的伸缩性通过在服务机群中透明地加入和删除一个节点来达到，通过检测节点或服务进程故障和正确地重置系统达到高可用性。由于我们的负载调度技术是在Linux内核中实现的，我们称之为**Linux虚拟服务器（Linux Virtual Server）**。

Linux Virtual Server项目的目标 ：**使用集群技术和Linux操作系统实现一个高性能、高可用的服务器，它具有很好的可伸缩性（Scalability）、可靠性（Reliability）和可管理性（Manageability）**。

目前，LVS项目已提供了一个实现可伸缩网络服务的Linux Virtual Server框架，如下图所示。

![LVS体系结构][LVS]

在LVS框架中，提供了含有三种IP负载均衡技术的IP虚拟服务器软件IPVS、基于内容请求分发的内核Layer-7交换机KTCPVS和集群管理软件。可以利用LVS框架实现高可伸缩的、高可用的Web、Cache、Mail和Media等网络服务；在此基础上，可以开发支持庞大用户数的、高可伸缩的、高可用的电子商务应用。

### 3.1 IP虚拟服务器软件IPVS ###

在调度器的实现技术中，IP负载均衡技术是效率最高的。

#### 3.1.1 IP负载均衡技术 ####

在已有的IP负载均衡技术中有通过网络地址转换（Network Address Translation）将一组服务器构成一个高性能的、高可用的虚拟服务器，我们称之为**VS/NAT技术（Virtual Server via Network Address Translation）**。

在分析VS/NAT的缺点和网络服务的非对称性的基础上，我们提出通过IP隧道实现虚拟服务器的方法VS/TUN （Virtual Server via IP Tunneling），和通过直接路由实现虚拟服务器的方法VS/DR（Virtual Server via Direct Routing），它们可以极大地提高系统的伸缩性。

所以，IPVS软件实现了这三种IP负载均衡技术，它们的大致原理如下（我们将在其他章节对其工作原理进行详细描述）：

##### Virtual Server via Network Address Translation （VS/NAT） #####

通过网络地址转换，调度器重写请求报文的目标地址，将请求分派给后端的真实服务器；真实服务器的响应报文通过调度器时，报文的源地址被重写，再返回给客户，完成整个负载调度过程。

##### Virtual Server via IP Tunneling（VS/TUN） #####

采用NAT技术时，由于请求和响应报文都必须经过调度器进行地址重写，当客户请求越来越多时，调度器的能力将成为瓶颈。为了解决这个问题，调度器把请求报文通过IP隧道转发至真实服务器，而真实服务器将响应直接返回给客户，所以调度器只处理请求报文。由于一般网络服务响应比请求报文大许多，采用VS/TUN技术后，集群系统的最大吞吐量可以提高10倍。

##### Virtual Server via Direct Routing（VS/DR） #####

VS/DR通过改写请求报文的MAC地址，将请求发送到真实服务器，而真实服务器将响应直接返回给客户。同VS/TUN技术一样，VS/DR技术可极大地提高集群系统的伸缩性。这种方法没有IP隧道的开销，对集群中的真实服务器也没有必须支持IP隧道协议的要求，但是要求调度器与真实服务器都有一块网卡连在同一物理网段上。

#### 3.1.2 负载调度算法 ####

针对不同的网络服务需求和服务器配置，IPVS调度器实现了如下八种负载调度算法：

##### 轮询（Round Robin） #####

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

##### 加权轮询（Weighted Round Robin） #####

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

##### 最少连接（Least Connections） #####

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

##### 加权最少连接（Weighted Least Connections） #####

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

##### 基于局部性的最少连接（Locality-Based Least Connections） #####

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

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

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

##### 目标地址散列（Destination Hashing） #####

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

##### 源地址散列（Source Hashing） #####

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

### 3.2 内核七层交换机KTCPVS ###

在基于IP负载调度技术中，当一个TCP连接的初始SYN报文到达时，调度器就选择一台服务器，将报文转发给它。此后通过查发报文的IP和TCP报文头地址，保证此连接的后继报文被转发到该服务器。这样，IPVS无法检查到请求的内容再选择服务器，这就要求后端服务器组提供相同的服务，不管请求被发送到哪 一台服务器，返回结果都是一样的。

但是，在有些应用中，后端服务器功能不一，有的提供HTML文档，有的提供图片，有的提供CGI，这就需要基于内容的调度（Content-Based Schduling）。

由于用户空间TCP Gateway的开销太大，我们提出在操作系统的内核中实现七层交换方法，来避免用户空间与核心空间的切换和内存复制的开销。在Linux操作系统的内核中，我们实现了七层交换，称之为**KTCPVS（Kernel TCP Virtual Server）**。目前，KTCPVS已经能对HTTP请求进行基于内容的调度。

虽然应用层交换处理复杂，它的伸缩性有限，但应用层交换带来以下好处：

*  相同页面的请求被发送到同一服务器，可以提高单台服务器的Cache命中率。
 *  七层交换可以充分利用访问的局部性，将相同类型的请求发送到同一台服务器，使得每台服务器收到的请求具有更好的相似性，可进一步提高单台服务器的Cache命中率。
 *  后端服务器可运行不同类型的服务，如文档服务，图片服务，CGI服务和数据库服务等。

### 3.3 LVS集群 ###

LVS集群的特点可以归结如下：

*  **功能**

有实现三种IP负载均衡技术和八种连接调度算法的IPVS软件。在IPVS内部实现上，采用了高效的Hash函数和垃圾回收机制，能正确处理所调度报文相关的ICMP消息（有些商品化的系统反而不能）。虚拟服务的设置数目没有限制，每个虚拟服务有自己的服务器集。它支持持久的虚拟服务（如HTTP Cookie和HTTPS等需要该功能的支持），并提供详尽的统计数据，如连接的处理速率和报文的流量等。针对大规模拒绝服务（Deny of Service）攻击，实现了三种防卫策略。

有基于内容请求分发的应用层交换软件KTCPVS，它也是在Linux内核中实现。有相关的集群管理软件对资源进行监测，能及时将故障屏蔽，实现系统的高可用性。主、从调度器能周期性地进行状态同步，从而实现更高的可用性。

*  **适用性**

后端服务器可运行任何支持TCP/IP的操作系统，包括Linux，各种Unix（如FreeBSD、Sun Solaris、HP Unix等），Mac/OS和Windows NT/2000等。  
负载调度器能够支持绝大多数的TCP和UDP协议，无需对客户机和服务器作任何修改，可适用大多数Internet服务。

*  **性能**

LVS服务器集群系统具有良好的伸缩性，可支持几百万个并发连接。配置100M网卡，采用VS/TUN或VS/DR调度技术，集群系统的吞吐量可高达1Gbits/s；如配置千兆网卡，则系统的最大吞吐量可接近10Gbits/s。

*  **可靠性**

LVS服务器集群软件已经在很多大型的、关键性的站点得到很好的应用，所以它的可靠性在真实应用得到很好的证实。有很多调度器运行一年多，未作一次重启动。

*  **软件许可证**

LVS集群软件是按GPL（GNU Public License）许可证发行的自由软件，这意味着你可以得到软件的源代码，有权对其进行修改，但必须保证你的修改也是以GPL方式发行。

# 二、LVS集群的体系结构 #

## 1、LVS集群的通用体系结构 ##

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

![LVS集群体系结构][LVS 1]

为此，在设计时需要考虑系统的透明性、可伸缩性、高可用性和易管理性。

一般来说，LVS集群采用三层结构，如上图所示。三层结构的主要组成部分为：

*  **负载调度器（Load Balancer）**：它是整个集群对外面的前端机，负责将客户的请求发送到一组服务器上执行，而客户认为服务是来自一个IP地址（我们可称之为虚拟IP地址）上的。
 *  **服务器池（Server Pool）**：它是一组真正执行客户请求的服务器，执行的服务有WEB/Mail/FTP/DNS等等。
 *  **共享存储（Shared Storage）**：它为服务器池提供了一个共享的存储区，这样很容易使得服务器池拥有相同的内容，提供相同的服务。

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

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

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

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

### 1.1 为什么使用层次的体系结构 ###

层次的体系结构可以使得层与层之间相互独立，每一个层次提供不同的功能，在一个层次可以重用不同的已有软件。例如，调度器层提供了负载平衡、可伸缩性和高可用性等，在服务器层可以运行不同的网络服务，如Web、Cache、Mail和Media等，来提供不同的可伸缩网络服务。明确的功能划分和清晰的层次结构使得系统容易建设，以后整个系统容易维护，而且系统的性能容易被扩展。

### 1.2 为什么使用共享存储 ###

共享存储如分布式文件系统在这个LVS集群系统是可选项。当网络服务需要有相同的内容，共享存储是很好的选择，否则每台服务器需要将相同的内容复制到本地硬盘上。当系统存储的内容越多，这种无共享结构（Shared-nothing Structure）的代价越大，因为每台服务器需要一样大的存储空间，任何的更新需要涉及到每台服务器，系统的维护代价会非常高。

共享存储为服务器组提供统一的存储空间，这使得系统的内容维护工作比较轻松，如Webmaster只需要更新共享存储中的页面，对所有的服务器都有效。分布式文件系统提供良好的伸缩性和可用性，当分布式文件系统的存储空间增加时，所有服务器的存储空间也随之增大。对于大多数 Internet服务来说，它们都是读密集型（Read-intensive）的应用，分布式文件系统在每台服务器使用本地硬盘作Cache（如 2Gbytes的空间），可以使得访问分布式文件系统本地的速度接近于访问本地硬盘。

### 1.3 高可用性 ###

集群系统的特点是它在软硬件上都有冗余。系统的高可用性可以通过检测节点或服务进程故障和正确地重置系统来实现，使得系统收到的请求能被存活的服务器节点处理。

通常，我们**在调度器上有资源监测进程来时刻监视各个服务器节点的健康状况**。当服务器对ICMP ping不可达时或者探测到它的网络服务在指定的时间没有响应时，资源监测进程就会通知操作系统内核将该服务器从调度列表中删除或者失效。这样，新的服务请求就不会被调度到坏的节点。资源监测进程能通过电子邮件或传呼机向管理员报告故障。一旦监测进程监测到服务器恢复工作，其通知调度器将该服务器节点重新加入调度列表进行调度。另外，通过系统提供的管理程序，管理员可发命令随时可以将新机器加入服务来提高系统的处理性能，也可以将已有的服务器移出服务，以便对服务器进行系统维护。

现在**前端的调度器有可能成为系统的单一失效点（Single Point of Failure）**。一般来说，调度器的可靠性较高，因为调度器上运行的程序较少而且大部分程序早已经遍历过，但我们不能排除硬件老化、网络线路或者人为误操作等主要故障。为了避免调度器失效而导致整个系统不能工作，我们需要**设立一个从调度器作为主调度器的备份**。两个**心跳（Heartbeat）进程**分别在主、从调度器上运行，它们通过串口线和UDP等心跳线来相互定时地汇报各自的健康状况。当从调度器不能听得主调度器的心跳时，从调度器通过ARP欺骗 （Gratuitous ARP）来接管集群对外的Virtual IP Address，同时接管主调度器的工作来提供负载调度服务。当主调度器恢复时，这里有两种方法，一是主调度器自动变成从调度器，二是从调度器释放Virtual IP Address，主调度器收回Virtual IP Address并提供负载调度服务。这里，多条心跳线可以使得因心跳线故障导致误判（即从调度器认为主调度器已经失效，其实主调度器还在正常工作）的概率降到最低。

通常，当主调度器失效时，主调度器上所有已建立连接的状态信息将丢失，已有的连接会中断。客户需要向重新连接，从调度器才会将新连接调度到各个服务器上，这对客户会造成一定的不便。为此，IPVS调度器在Linux内核中实现一种**高效状态同步机制**，将主调度器的状态信息及时地同步到从调度器。当从调度器接管时，绝大部分已建立的连接会持续下去。

## 2、可伸缩Web服务 ##

基于LVS的Web集群的体系结构如下图所示。

![LVS Web Cluster][]

第一层是负载调度器，一般采用IP负载均衡技术，可以使得整个系统有较高的吞吐量；

第二层是Web服务器池，在每个节点上可以分别运行HTTP服务或HTTPS服务，或者两者都运行；

第三层是共享存储，它可以是数据库，可以是网络文件系统或分布式文件系统，或者是三者的混合；

集群中各个节点通过高速网络相连接。

对于动态页面（如PHP、JSP和ASP等），需要访问的动态数据一般存储在数据库服务器中。数据库服务运行在独立的服务器上，为所有Web服务器共享。无论同一Web服务器上多个动态页面访问同一数据，还是不同Web服务器上多个动态页面访问同一数据，数据库服务器有锁机制使得这些访问有序地进行，从而保证数据的一致性。

对于静态的页面和文件（如HTML文档和图片等），可以存储在网络文件系统或者分布式文件系统中。至于选择哪一种，看系统的规模和需求而定。通过共享的网络文件系统或者分布式文件系统，WebMaster可以看到统一的文档存储空间，维护和更新页面比较方便，对共享存储中页面的修改对所有的服务器都有效。

在这种结构下，当所有服务器节点超载时，管理员可以很快地加入新的服务器节点来处理请求，而无需将Web文档等复制到节点的本地硬盘上。

有些Web服务可能用到HTTP Cookie，它是将数据存储在客户的浏览器来追踪和标识客户的机制。使用HTTP Cookie后，来自同一客户的不同连接存在相关性，这些连接必须被发送到同一Web服务器。一些Web服务使用安全的HTTPS协议，它是HTTP协议加 SSL（Secure Socket Layer）协议。另有些Web服务可能使用安全的HTTPS协议，它是HTTP协议加SSL协议。当客户访问HTTPS服务（HTTPS的缺省端口为 443）时，会先建立一个SSL连接，来交换对称公钥加密的证书并协商一个SSL Key，来加密以后的会话。在SSL Key的生命周期内，后续的所有HTTPS连接都使用这个SSL Key，所以同一客户的不同HTTPS连接也存在相关性。针对这些需要，IPVS调度器提供了持久服务的功能，它可以使得在设定的时间内，来自同一IP地 址的不同连接会被发送到集群中同一个服务器结点，可以很好地解决客户连接的相关性问题。

## 3、可伸缩Cache服务 ##

有效的网络Cache系统可以大大地减少网络流量、降低响应延时以及服务器的负载。但是，若Cache服务器超载而不能及时地处理请求，反而会增加响应延时。所以，Cache服务的可伸缩性很重要，当系统负载不断增长时，整个系统能被扩展来提高Cache服务的处理能力。尤其，在主干网上的 Cache服务可能需要几个Gbps的吞吐率，单台服务器（例如SUN目前最高端的Enterprise 10000服务器）远不能达到这个吞吐率。可见，通过PC服务器集群实现可伸缩Cache服务是很有效的方法，也是性能价格比最高的方法。

基于LVS的Cache集群的体系结构如下所示。

![LVS cache cluster][]

第一层是负载调度器，一般采用IP负载均衡技术，可以使得整个系统有较高的吞吐率；

第二层是Cache服务器池，一般Cache服务器放置在接近主干Internet连接处，它们可以分布在不同的网络中。

调度器可以有多个，放在离客户接近的地方。

IPVS负载调度器一般使用IP隧道方法（即VS/TUN方法），来架构Cache集群系统，因为Cache服务器可能被放置不同的地方（例如在接近主干Internet连接处），而调度器与Cache服务器池可能不在同一个物理网络中。采用VS/TUN方法，调度器只调度Web Cache请求，而Cache服务器将响应数据直接返回给客户。在请求对象不能在本地命中的情况下，Cache服务器要向源服务器发请求，将结果取回，最后将结果返回给客户。

# 三、IP负载均衡技术 #

## 1、实现虚拟服务的相关方法 ##

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

### 1.1 基于RR-DNS的解决方法 ###

服务器组拥有相同的域名（如www.jjj.com），当用户按照该域名访问时，RR-DNS服务器会把域名轮流解析到这组服务器的不同IP地址，从而将访问负载分到各台服务器上。

![LVS体系结构][LVS 2]

这种方法会带来几个问题。

第一，域名服务器是一个分布式系统，是按照一定的层次结构组织的。当用户就域名解析请求提交给本地的域名服务器，它会因不能直接解析而向上一级域名服务器提交，上一级域名服务器再依次向上提交，直到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”按钮，也无济于事。

### 1.2 基于客户端的解决方法 ###

基于客户端的解决方法需要每个客户程序都有一定的服务器集群的知识，进而把以负载均衡的方式将请求发到不同的服务器。例如，Netscape Navigator浏览器访问Netscape的主页时，它会随机地从一百多台服务器中挑选第N台，最后将请求送往wwwN.netscape.com。

### 1.3 基于应用层负载均衡调度的解决方法 ###

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

基于应用层负载均衡调度的多服务器解决方法也存在一些问题。

第一，系统处理开销特别大，致使系统的伸缩性有限。同时，需要两次TCP连接，一次是从用户到调度器，另一次是从调度器到真实服务器，同时需要对请求进行分析和重写。

第二，基于应用层的负载均衡调度器对于不同的应用，需要写不同的调度器。

### 1.4 基于IP层负载均衡调度的解决方法 ###

用户通过虚拟IP地址（Virtual IP Address）访问服务时，访问请求的报文会到达负载调度器，由它进行负载均衡调度，从一组真实服务器选出一个，将报文的目标地址Virtual IP Address改写成选定服务器的地址，报文的目标端口改写成选定服务器的相应端口，最后将报文发送给选定的服务器。真实服务器的回应报文经过负载调度器时，将报文的源地址和源端口改为Virtual IP Address和相应的端口，再把报文发给用户。

## 2、通过NAT实现虚拟服务器（VS/NAT） ##

![LVS/NAT][LVS_NAT]

客户通过Virtual IP Address（虚拟服务的IP地址）访问网络服务时，请求报文到达调度器，调度器根据连接调度算法从一组真实服务器中选出一台服务器，将报文的目标地址 Virtual IP Address改写成选定服务器的地址，报文的目标端口改写成选定服务器的相应端口，最后将修改后的报文发送给选出的服务器。

同时，调度器在连接Hash 表中记录这个连接，当这个连接的下一个报文到达时，从连接Hash表中可以得到原选定服务器的地址和端口，进行同样的改写操作，并将报文传给原选定的服务器。当来自真实服务器的响应报文经过调度器时，调度器将报文的源地址和源端口改为Virtual IP Address和相应的端口，再把报文发给用户。

## 3、通过IP隧道实现虚拟服务器（VS/TUN） ##

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

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

VS/TUN的体系结构如下图所示，各个服务器将VIP地址配置在自己的IP隧道设备上。

![LVS/TUN][LVS_TUN]

VS/TUN的工作流程如下：

调度器根据各个服务器的负载情况，动态地选择一台服务器， 将请求报文封装在另一个IP报文中，再将封装后的IP报文转发给选出的服务器；服务器收到报文后，先将报文解封获得原来目标地址为VIP的报文，服务器发现VIP地址被配置在本地的IP隧道设备上，所以就处理这个请求，然后根据路由表将响应报文直接返回给客户。

## 4、通过直接路由实现虚拟服务器（VS/DR） ##

跟VS/TUN方法相同，VS/DR利用大多数Internet服务的非对称特点，负载调度器中只负责调度请求，而服务器直接将响应返回给客户，可以极大地提高整个集群系统的吞吐量。

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

![LVS/DR][LVS_DR]

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

VS/DR的工作流程如下：

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

## 5、三种方法的优缺点比较 ##

三种IP负载均衡技术的优缺点归纳在下表中：

![LVS体系结构][LVS 3]

## 6、小结 ##

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

# 四、LVS集群的负载调度 #

在本部分，我们将主要讲述在负载调度器上的负载调度策略和算法，如何将请求流调度到各台服务器，使得各台服务器尽可能地保持负载均衡。

主要由两个部分组成。第一部分描述IP负载均衡软件IPVS在内核中所实现的各种连接调度算法；第二部分给出一个动态反馈负载均衡算法（Dynamic-feedback load balancing），它结合内核中的加权连接调度算法，根据动态反馈回来的负载信息来调整服务器的权值，来进一步避免服务器间的负载不平衡。

## 1、内核中的连接调度算法 ##

在内核中的连接调度算法上，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）

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

### 1.1 轮询调度 ###

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

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

所以，算法要作相应的改动，它的算法流程如下：

假设有一组服务器S = {S0, S1, …, Sn-1}，一个指示变量i表示上一次选择的
    服务器，W(Si)表示服务器Si的权值。变量i被初始化为n-1，其中n > 0。
    
    j = i;
    do {
        j = (j + 1) mod n;
        if (W(Sj) > 0) {
            i = j;
            return Si;
        }
    } while (j != i);
    return NULL;

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

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

### 1.2 加权轮询调度 ###

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

加权轮询调度算法流程如下：

假设有一组服务器S = {S0, S1, …, Sn-1}，W(Si)表示服务器Si的权值，一个
    指示变量i表示上一次选择的服务器，指示变量cw表示当前调度的权值，max(S)
    表示集合S中所有服务器的最大权值，gcd(S)表示集合S中所有服务器权值的最大
    公约数。变量i初始化为-1，cw初始化为零。
    
    while (true) {
      i = (i + 1) mod n;
    if (i == 0) {
         cw = cw - gcd(S);
         if (cw <= 0) {
           cw = max(S);
           if (cw == 0)
             return NULL;
         }
      }
      if (W(Si) >= cw)
        return Si;
    }

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

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

### 1.3 最少连接调度 ###

**最少连接调度（Least-Connection Scheduling）算法**是把新的连接请求分配到当前连接数最小的服务器。

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

在系统实现时，我们也引入当服务器的权值为零时，表示该服务器不可用而不被调度。

它的算法流程如下：

假设有一组服务器S = {S0, S1, ..., Sn-1}，W(Si)表示服务器Si的权值，
    C(Si)表示服务器Si的当前连接数。
    
    for (m = 0; m < n; m++) {
        if (W(Sm) > 0) {
            for (i = m+1; i < n; i++) {
                if (W(Si) <= 0)
                    continue;
                if (C(Si) < C(Sm))
                    m = i;
            }
            return Sm;
        }
    }
    return NULL;

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

### 1.4 加权最少连接调度 ###

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

加权最少连接调度的算法流程如下：

假设有一组服务器S = {S0, S1, ..., Sn-1}，W(Si)表示服务器Si的权值，
    C(Si)表示服务器Si的当前连接数。所有服务器当前连接数的总和为
    CSUM = ΣC(Si)  (i=0, 1, .. , n-1)。当前的新连接请求会被发送服务器Sm，
    当且仅当服务器Sm满足以下条件
      (C(Sm) / CSUM)/ W(Sm) = min { (C(Si) / CSUM) / W(Si)}  (i=0, 1, . , n-1)
      其中W(Si)不为零
    因为CSUM在这一轮查找中是个常数，所以判断条件可以简化为
      C(Sm) / W(Sm) = min { C(Si) / W(Si)}  (i=0, 1, . , n-1)
      其中W(Si)不为零
    
    因为除法所需的CPU周期比乘法多，且在Linux内核中不允许浮点除法，服务器的
    权值都大于零，所以判断条件C(Sm) / W(Sm) > C(Si) / W(Si) 可以进一步优化
    为C(Sm)*W(Si) > C(Si)* W(Sm)。同时保证服务器的权值为零时，服务器不被调
    度。所以，算法只要执行以下流程。
    
    for (m = 0; m < n; m++) {
        if (W(Sm) > 0) {
            for (i = m+1; i < n; i++) {
                if (C(Sm)*W(Si) > C(Si)*W(Sm))
                    m = i;
            }
            return Sm;
        }
    }
    return NULL;

### 1.5 基于局部性的最少连接调度 ###

**基于局部性的最少连接调度（Locality-Based Least Connections Scheduling，以下简称为LBLC）算法**是针对请求报文的目标IP地址的负载均衡调度，目前主要用于Cache集群系统，因为在Cache集群中客户请求报文的目标IP地址是变化的。这里假设任何后端服务器都可以处理任一请求，算法的设计目标是在服务器的负载基本平衡情况下，将相同目标IP地址的请求调度到同一台服务器，来提高各台服务器的访问局部性和主存Cache命中率，从而整个集群系统的处理能力。

LBLC调度算法先根据请求的目标IP地址找出该目标IP地址最近使用的服务器，若该服务器是可用的且没有超载，将请求发送到该服务器；若服务器不存在，或者该服务器超载且有服务器处于其一半的工作负载，则用“最少连接”的原则选出一个可用的服务器，将请求发送到该服务器。

该算法的详细流程如下：

假设有一组服务器S = {S0, S1, ..., Sn-1}，W(Si)表示服务器Si的权值，
    C(Si)表示服务器Si的当前连接数。ServerNode[dest_ip]是一个关联变量，表示
    目标IP地址所对应的服务器结点，一般来说它是通过Hash表实现的。WLC(S)表示
    在集合S中的加权最少连接服务器，即前面的加权最少连接调度。Now为当前系统
    时间。
    
    if (ServerNode[dest_ip] is NULL) then {
        n = WLC(S);
        if (n is NULL) then return NULL;
        ServerNode[dest_ip].server = n;
    } else {
        n = ServerNode[dest_ip].server;
        if ((n is dead) OR
            (C(n) > W(n) AND
             there is a node m with C(m) < W(m)/2))) then {
            n = WLC(S);
            if (n is NULL) then return NULL;
            ServerNode[dest_ip].server = n;
        }
    }
    ServerNode[dest_ip].lastuse = Now;
    return n;

此外，对关联变量ServerNode\[dest\_ip\]要进行周期性的垃圾回收（Garbage Collection），将过期的目标IP地址到服务器关联项进行回收。过期的关联项是指哪些当前时间（实现时采用系统时钟节拍数jiffies）减去最 近使用时间超过设定过期时间的关联项，系统缺省的设定过期时间为24小时。

### 1.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地址对应的服务器组；按“最少连接”原则从该服务器组中选出一台服务器，若服务器没有超载， 将请求发送到该服务器；若服务器超载；则按“最少连接”原则从整个集群中选出一台服务器，将该服务器加入到服务器组中，将请求发送到该服务器。同时，当该 服务器组有一段时间没有被修改，将最忙的服务器从服务器组中删除，以降低复制的程度。

LBLCR调度算法的流程如下：

假设有一组服务器S = {S0, S1, ..., Sn-1}，W(Si)表示服务器Si的权值，
    C(Si)表示服务器Si的当前连接数。ServerSet[dest_ip]是一个关联变量，表示
    目标IP地址所对应的服务器集合，一般来说它是通过Hash表实现的。WLC(S)表示
    在集合S中的加权最少连接服务器，即前面的加权最少连接调度；WGC(S)表示在
    集合S中的加权最大连接服务器。Now为当前系统时间，lastmod表示集合的最近
    修改时间，T为对集合进行调整的设定时间。
    
    if (ServerSet[dest_ip] is NULL) then {
        n = WLC(S);
        if (n is NULL) then return NULL;
        add n into ServerSet[dest_ip];
    } else {
        n = WLC(ServerSet[dest_ip]);
        if ((n is NULL) OR
            (n is dead) OR
            (C(n) > W(n) AND
             there is a node m with C(m) < W(m)/2))) then {
            n = WLC(S);
            if (n is NULL) then return NULL;
            add n into ServerSet[dest_ip];
        } else
        if (|ServerSet[dest_ip]| > 1 AND
            Now - ServerSet[dest_ip].lastmod > T) then {
            m = WGC(ServerSet[dest_ip]);
            remove m from ServerSet[dest_ip];
        }
    }
    ServerSet[dest_ip].lastuse = Now;
    if (ServerSet[dest_ip] changed) then
        ServerSet[dest_ip].lastmod = Now;
    return n;

此外，对关联变量ServerSet\[dest\_ip\]也要进行周期性的垃圾回收（Garbage Collection），将过期的目标IP地址到服务器关联项进行回收。过期的关联项是指哪些当前时间（实现时采用系统时钟节拍数jiffies）减去最近使用时间（lastuse）超过设定过期时间的关联项，系统缺省的设定过期时间为24小时。

### 1.7 目标地址散列调度 ###

**目标地址散列调度（Destination Hashing Scheduling）算法**也是针对目标IP地址的负载均衡，但它是一种静态映射算法，通过一个散列（Hash）函数将一个目标IP地址映射到一台服务器。

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

该算法的流程如下：

假设有一组服务器S = {S0, S1, ..., Sn-1}，W(Si)表示服务器Si的权值，
    C(Si)表示服务器Si的当前连接数。ServerNode[]是一个有256个桶（Bucket）的
    Hash表，一般来说服务器的数目会运小于256，当然表的大小也是可以调整的。
    算法的初始化是将所有服务器顺序、循环地放置到ServerNode表中。若服务器的
    连接数目大于2倍的权值，则表示服务器已超载。
    
    n = ServerNode[hashkey(dest_ip)];
    if ((n is dead) OR
        (W(n) == 0) OR
        (C(n) > 2*W(n))) then
        return NULL;
    return n;

在实现时，我们采用素数乘法Hash函数，通过乘以素数使得散列键值尽可能地达到较均匀的分布。所采用的素数乘法Hash函数如下：

static inline unsigned hashkey(unsigned int dest_ip)
    {
        return (dest_ip* 2654435761UL) & HASH_TAB_MASK;
    }

其中，2654435761UL是2到2^32 (4294967296)间接近于黄金分割的素数，

### 1.8 源地址散列调度 ###

源地址散列调度（Source Hashing Scheduling）算法正好与目标地址散列调度算法相反，它根据请求的源IP地址，作为散列键（Hash Key）从静态分配的散列表找出对应的服务器，若该服务器是可用的且未超载，将请求发送到该服务器，否则返回空。它采用的散列函数与目标地址散列调度算法 的相同。它的算法流程与目标地址散列调度算法的基本相似，除了将请求的目标IP地址换成请求的源IP地址，所以这里不一一叙述。

在实际应用中，源地址散列调度和目标地址散列调度可以结合使用在防火墙集群中，它们可以保证整个系统的唯一出入口。

## 2、动态反馈负载均衡算法 ##

![LVS/DR][LVS_DR 1]

我们提出基于动态反馈负载均衡机制，来控制新连接的分配，从而控制各个服务器的负载。例如，在IPVS调度器的内核中使用加权轮询调度 （Weighted Round-Robin Scheduling）算法来调度新的请求连接；在负载调度器的用户空间中运行Monitor Daemon。Monitor Daemon定时地监视和收集各个服务器的负载信息，根据多个负载信息算出一个综合负载值。Monitor Daemon将各个服务器的综合负载值和当前权值算出一组新的权值。当综合负载值表示服务器比较忙时，新算出的权值会比其当前权值要小，这样新分配到该服务器的请求数就会少一些。当综合负载值表示服务器处于低利用率时，新算出的权值会比其当前权值要大，来增加新分配到该服务器的请求数。若新权值和当前权值的差值大于设定的阈值，Monitor Daemon将该服务器的权值设置到内核中的IPVS调度中。过了一定的时间间隔（如2秒钟），Monitor Daemon再查询各个服务器的情况，并相应调整服务器的权值；这样周期性地进行。可以说，这是一个负反馈机制，使得服务器保持较好的利用率。

在加权轮询调度算法中，当服务器的权值为零，已建立的连接会继续得到该服务器的服务，而新的连接不会分配到该服务器。系统管理员可以将一台服务器的权值设置为零，使得该服务器安静下来，当已有的连接都结束后，他可以将该服务器切出，对其进行维护。维护工作对系统都是不可少的，比如硬件升级和软件更新等，零权值使得服务器安静的功能很主要。所以，在动态反馈负载均衡机制中我们要保证该功能，当服务器的权值为零时，我们不对服务器的权值进行调整。

# 五、总结 #

在本文，我们主要对LVS技术进行了原理级的介绍。

[virtual_server_architecture.png]: http://img.kiterunner.top/virtual_server_architecture.png
[LVS]: http://img.kiterunner.top/lvs_framework.png
[LVS 1]: http://img.kiterunner.top/lvs_cluster_architecture.png
[LVS Web Cluster]: http://img.kiterunner.top/lvs_scalable_web_cluster.png
[LVS cache cluster]: http://img.kiterunner.top/lvs_scalable_cache_cluster.png
[LVS 2]: http://img.kiterunner.top/lvs_rrdns_cluster.png
[LVS_NAT]: http://img.kiterunner.top/lvs_virtual_server_via_NAT.png
[LVS_TUN]: http://img.kiterunner.top/lvs_virtual_server_via_TUN.png
[LVS_DR]: http://img.kiterunner.top/lvs_virtual_server_via_DR.png
[LVS 3]: http://img.kiterunner.top/lvs_balance_comp.png
[LVS_DR 1]: http://img.kiterunner.top/lvs_dynamic_lb.png