系统环境: rhel6 x86_64 iptables and selinux disabled

相关网址：http://zh.linuxvirtualserver.org/

yum仓库配置:

[rhel-source]

name=Red Hat Enterprise Linux $releasever - $basearch - Source

baseurl=ftp://192.168.122.1/pub/yum

enabled=1

gpgcheck=1

gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release

[HighAvailability]

name=InstructorServer Repository

baseurl=ftp://192.168.122.1/pub/yum/HighAvailability

gpgcheck=1

gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release

enabled=1

[LoadBalancer]

name=InstructorServer Repository

baseurl=ftp://192.168.122.1/pub/yum/LoadBalancer

gpgcheck=1

gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release

enabled=1

[ResilientStorage]

name=InstructorServer Repository

baseurl=ftp://192.168.122.1/pub/yum/ResilientStorage

gpgcheck=1

gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release

enabled=1

[ScalableFileSystem]

name=InstructorServer Repository

baseurl=ftp://192.168.122.1/pub/yum/ScalableFileSystem

gpgcheck=1

gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release

enabled=1

LoadBalancer:

kernel2.6.x 已內建LVS模组

kernel2.4.x 或之前的内核版本需打补丁

rhel5/rhel6 自带LVS软件包安装 ipvsadm软件包即可使用

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

注:以上三种方法所能支持最大服务器数目的估计是假设调度器使用100M网卡,调度器的硬件配置与后端服务器的硬件配置相同,而且是对一般Web服务。使用更高的硬件配置(如千兆网卡和更快的处理器)作为调度器,调度器所能调度的服务器数量会相应增加。当应用不同时,服务器的数目也会相应地改变。所以,以上数据估计主要是为三种方法的伸缩性进行量化比较。

IP负载均衡技术:

通过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）[64,65,66]。这些地址不在Internet上使用，而是专门为内部网络预留的。当内部网络中的主机要访问Internet或被Internet访问时，就需要采用网络地址转换（NetworkAddress Translation,以下简称NAT），将内部地址转化为Internets上可用的外部地址。NAT的工作原理是报文头（目标地址、源地址和端口等）被正确改写后，客户相信它们连接一个IP地址，而不同IP地址的服务器组也认为它们是与客户直接相连的。由此，可以用NAT方法将不同IP地址的并行网络服务变成在一个IP地址上的一个虚拟服务。

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

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

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

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

下面，举个例子来进一步说明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上。而到其他端口的报文将被拒绝。

从以下的例子中，我们可以更详细地了解报文改写的流程。

访问Web服务的报文可能有以下的源地址和目标地址：

调度器从调度列表中选出一台服务器，例如是172.16.0.3:8000。该报文会被改写为如下地址，并将它发送给选出的服务器。

从服务器返回到调度器的响应报文如下：

响应报文的源地址会被改写为虚拟服务的地址，再将报文发送给客户：

这样，客户认为是从202.103.106.5:80服务得到正确的响应，而不会知道该请求是服务器172.16.0.2还是服务器172.16.0.3处理的。

VS/NAT的优点是服务器可以运行任何支持TCP/IP的操作系统,它只需要一个IP地址配置在调度器上,服务器组可以用私有的IP地址。缺点是它的伸缩能力有限,当服务器结点数目升到20时,调度器本身有可能成为系统的新瓶颈,因为在VS/NAT中请求和响应报文都需要通过负载调度器。

LoadBalance 双网卡192.168.122.163(外网)192.168.1.163(内网)

如果只有一块网卡可用以下方式:

LoadBalance 192.168.1.163 server63.example.com

Gateway192.168.1.163 （注：Realserver的网关应设为LoadBalance的内网IP）

Realserver1192.168.1.119 server19.example.com

Realserver2192.168.1.25 server25.example.com

VirtualIP 192.168.122.163

以下步骤在server63上实施：

#开启路由机制

[root@server63~]# vim /etc/sysctl.conf

net.ipv4.ip_forward= 1

[root@server63~]# sysctl -p

#加载nat模块

[root@server63~]# modprobe iptable_nat

注:如果不加载此模块,也可以在第一次访问时成功,但是会在再次访问时出现延迟过长,或访问超时现象

#加载rule

[root@server63~]# yum install ipvsadm -y

[root@server63~]# ipvsadm -C

[root@server63~]# ipvsadm -A -t 192.168.122.163:80 -s rr

[root@server63~]# ipvsadm -a -t 192.168.122.163:80 -r 192.168.1.119:80 -m

[root@server63~]# ipvsadm -a -t 192.168.122.163:80 -r 192.168.1.25:80 -m

#保存rule

[root@server63~]# /etc/init.d/ipvsadm save

#绑定vip

[root@server63~]# ifconfig eth0:0 192.168.122.163 netmask 255.255.255.0

或

[root@server63~]# ip addr add 192.168.122.163/24 dev eth0

注：可用ipaddr show查看

以下步骤在server19和server25上实施：

[root@server63~]# yum install httpd -y

[root@server63~]# echo `hostname` > /var/www/html/index.html

[root@server63~]# /etc/init.d/httpd start

测试:

选择一台192.168.122.0/24网段主机访问http://192.168.122.163 反复刷新网页,每次出现的网页不同则表示成功。

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

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

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

我们利用IP隧道技术将请求报文封装转发给后端服务器，响应报文能从后端服务器直接返回给客户。但在这里，后端服务器有一组而非一个，所以我们不可能静态地建立一一对应的隧道，而是动态地选择一台服务器，将请求报文封装和转发给选出的服务器。这样，我们可以利用IP隧道的原理将一组服务器上的网络服务组成在一个IP地址上的虚拟网络服务。VS/TUN的体系结构如图3.3所示，各个服务器将VIP地址配置在自己的IP隧道设备上。

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

在这里，请求报文的目标地址为VIP，响应报文的源地址也为VIP，所以响应报文不需要作任何修改，可以直接返回给客户，客户认为得到正常的服务，而不会知道是哪一台服务器处理的。

在VS/TUN中，响应报文根据服务器的路由表直接返回给客户，而不经过负载调度器，所以负载调度器只处于从客户到服务器的半连接中，VS/TUN的TCP状态迁移与VS/NAT的不同。我们给出半连接的TCP有限状态机，如图3.5所示，圈表示状态，箭头表示状态间的转换，箭头上的标识表示在当前状态上收到该标识的输入，迁移到下一个状态。VS/TUN的TCP状态迁移是按照半连接的TCP有限状态机进行的。

Realserver192.168.122.193 server93.example.com

Realserver192.168.122.194 server94.example.com

LoadBalance 192.168.122.13 server13.example.com

Gateway192.168.122.13(LB的网关为自身，Realserver的网关均为LB)

VirtualIP 192.168.122.222

以下步骤在server13上实施:

#开启路由机制

[root@server13~]# vim /etc/sysctl.conf

net.ipv4.ip_forward= 1

[root@server13~]# sysctl -p

#加载rule

[root@server13~]# yum install ipvsadm -y

[root@server13~]# ipvsadm -C

[root@server13~]# ipvsadm -A -t 192.168.122.222:80 -s rr

[root@server13~]# ipvsadm -a -t 192.168.122.222:80 -r 192.168.122.193:80 -i

[root@server13~]# ipvsadm -a -t 192.168.122.222:80 -r 192.168.122.194:80 -i

#保存rule

[root@server13~]# /etc/init.d/ipvsadm save

#绑定vip

[root@server13~]# ifconfig eth0:0 192.168.122.222 netmask 255.255.255.0

或

[root@server13~]# ip addr add 192.168.122.222/24 dev eth0

注：可用ipaddr show查看

以下步骤在server93和server94上实施：

[root@server93~]# vim /etc/sysctl.conf

net.ipv4.ip_forward= 1

net.ipv4.conf.all.arp_ignore= 1

net.ipv4.conf.all.arp_announce= 2

[root@server93~]# sysctl -p

[root@server93~]# ifconfig tunl0 192.168.122.222 netmask 255.255.255.0 up

[root@server93~]# route add -host 192.168.122.222 dev tunl0

[root@server93~]# yum install httpd -y

[root@server93~]# echo `hostname` > /var/www/html/index.html

[root@server93~]# /etc/init.d/httpd start

测试:

选择一台192.168.122.0/24网段主机访问http://192.168.122.222 反复刷新网页,每次出现的网页不同则表示成功。

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

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

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

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

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

VS/DR负载调度器也只处于从客户到服务器的半连接中，按照半连接的TCP有限状态机进行状态迁移。

跟VS/TUN方法相同,负载调度器中只负责调度请求,而服务器直接将响应返回给客户,可以极大地提高整个集群系统的吞吐量。跟 VS/TUN相比,这种方法没有IP隧道的开销,但调度器和服务器组都必须在物理上有一个网卡通过不分断的局域网相连,如通过交换机或者高速的HUB相连。VIP地址为调度器和服务器组共享,调度器配置的VIP地址是对外可见的,用于接收虚拟服务的请求报文;所有的服务器把VIP地址配置在各自的Non-ARP网络设备上,它对外面是不可见的,只是用于处理目标地址为VIP的网络请求。

以下是LVS-DR的工作原理,包括数据包、数据帧的走向和转换过程:

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

实例场景设备清单:

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

1.client向目标vip发出请求,Director接收。此时IP包头及数据帧头信息如下:

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

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

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

Realserver192.168.122.119 server19.example.com

Realserver192.168.122.25 server25.example.com

LoadBalance 192.168.122.163 server63.example.com

VirtualIP 192.168.122.178

以下步骤在server63上实施:

[root@server63~]# yum install ipvsadm -y

#加载rule

[root@server63~]# ipvsadm -C (清空ipvs转发表)

[root@server63~]# ipvsadm -A -t 192.168.122.178:80 -s rr (-A:添加一个虚拟服务;-t:tcp服务;-s调度算法)

[root@server63~]# ipvsadm -a -t 192.168.122.178:80 -r 192.168.122.119:80 -g

[root@server63~]# ipvsadm -a -t 192.168.122.178:80 -r 192.168.122.25:80 -g

#保存rule

[root@server63~]# /etc/init.d/ipvsadm save

#绑定vip

[root@server63~]# ifconfig eth0:0 192.168.122.178 netmask 255.255.255.0

或

[root@server63~]# ip addr add 192.168.122.178/24 dev eth0

注：可用ipaddr show查看

Realserver必须不支持arp

以下步骤在server19上实施:

#关闭arp

方法一

[root@server19~]# yum install arptables_jf -y

[root@server19~]# arptables -A IN -d 192.168.122.178 -j DROP

[root@server19~]# arptables -A OUT -s 192.168.122.178 -j mangle --mangle-ip-s192.168.122.119

[root@server19~]# /etc/init.d/arptables_jf save

方法二

[root@server19~]# vim /etc/sysctl.conf

net.ipv4.conf.lo.arp_ignore= 1

net.ipv4.conf.lo.arp_announce= 2

net.ipv4.conf.all.arp_ignore= 1

net.ipv4.conf.all.arp_announce= 2

[root@server19~]# sysctl -p

[root@server19~]# ifconfig eth0:0 192.168.122.178 netmask 255.255.255.255

或

[root@server19~]# ip addr add 192.168.122.178 dev eth0

注：可用ipaddr show查看

[root@server19~]# yum install httpd -y

[root@server19~]# echo `hostname` > /var/www/html/index.html

[root@server19~]# /etc/init.d/httpd start

以下步骤在server25上实施:

#关闭arp

方法一

[root@server25~]# yum install arptables_jf -y

[root@server25~]# arptables -A IN -d 192.168.122.178 -j DROP

[root@server25~]# arptables -A OUT -s 192.168.122.178 -j mangle --mangle-ip-s192.168.122.25

[root@server25~]# /etc/init.d/arptables_jf save

方法二

[root@server25~]# vim /etc/sysctl.conf

net.ipv4.conf.lo.arp_ignore= 1

net.ipv4.conf.lo.arp_announce= 2

net.ipv4.conf.all.arp_ignore= 1

net.ipv4.conf.all.arp_announce= 2

[root@server25~]# sysctl -p

[root@server25~]# ifconfig eth0:0 192.168.122.178 netmask 255.255.255.255

或

[root@server25~]# ip addr add 192.168.122.178 dev eth0

注：可用ipaddr show查看

[root@server25~]# yum install httpd -y

[root@server25~]# echo `hostname` > /var/www/html/index.html

[root@server25~]# /etc/init.d/httpd start

测试:

访问192.168.122.178反复刷新网页,每次出现的网页不同则表示配置成功。

LVS常见问题:

1.LVS/DR如何处理请求报文的,会修改IP包内容吗?

1.1vs/dr本身不会关心IP层以上的信息,即使是端口号也是tcp/ip协议栈去判断是否正确,vs/dr本身主要做这么几个事:

1)接收client的请求,根据你设定的负载均衡算法选取一台realserver的ip;

2)以选取的这个ip对应的mac地址作为目标mac,然后重新将IP包封装成帧转发给这台RS;

3)在hashtable中记录连接信息。

vs/dr做的事情很少,也很简单,所以它的效率很高,不比硬件负载均衡设备差多少。

数据包、数据帧的大致流向是这样的:client--> VS --> RS --> client

1.2前面已作了回答,vs/dr不会修改IP包的内容.

2.RealServer 为什么要在lo接口上配置VIP,在出口网卡上配置VIP可以吗?

2.1既然要让RS能够处理目标地址为vip的IP包,首先必须要让RS能接收到这个包。

在lo上配置vip能够完成接收包并将结果返回client。

2.2答案是不可以将VIP设置在出口网卡上,否则会响应客户端的arprequest,造成client/gateway

arptable 紊乱,以至于整个loadbalance都不能正常工作。

3.RealServer 为什么要抑制arp帧?

这个问题在上一问题中已经作了说明,这里结合实施命令进一步阐述。我们在具体实施部署的时候都会作如下调整:

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

我相信很多人都不会弄懂它们的作用是什么,只知道一定得有。我这里也不打算拿出来详细讨论,只是作几点说明,就当是补充吧。

3.1

echo"1" >/proc/sys/net/ipv4/conf/lo/arp_ignore

echo"2" >/proc/sys/net/ipv4/conf/lo/arp_announce

这两条是可以不用的,因为arp对逻辑接口没有意义。

3.2如果你的RS的外部网络接口是eth0,那么

echo"1">/proc/sys/net/ipv4/conf/all/arp_ignore

echo"2">/proc/sys/net/ipv4/conf/all/arp_announce

其实真正要执行的是:

echo"1">/proc/sys/net/ipv4/conf/eth0/arp_ignore

echo"2">/proc/sys/net/ipv4/conf/eth0/arp_announce

所以我个人建议把上面两条也加到你的脚本里去,因为万一系统里上面两条默认的值不是0,那有可能是会出问题滴。

4.LVS/DR loadbalancer(director)与RS为什么要在同一网段中?

从第一个问题中大家应该明白vs/dr是如何将请求转发给RS的了吧?它是在数据链路层来实现的,所以 director必须和RS在同一网段里面。

5.为什么director上eth0接口除了VIP另外还要配一个ip(即DIP)?

5.1如果是用了keepalived等工具做HA或者LoadBalance,则在健康检查时需要用到DIP

5.2没有健康检查机制的HA或者LoadBalance 则没有存在的实际意义.

6.LVS/DRip_forward 需要开启吗?

不需要。因为director跟realserver是同一个网段,无需开启转发。

7.lvs/dr 里,director的vip的netmask没必要设置为255.255.255.255,也不需要再去routeadd -host $VIP dev eth0:0

director的vip本来就是要像正常的ip地址一样对外通告的,不要搞得这么特殊.

LVS的负载调度算法在内核中的连接调度算法上,IPVS已实现了以下八种调度算法:

一轮叫调度(Round-RobinScheduling)

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

二加权轮叫调度(WeightedRound-Robin Scheduling)

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

三最小连接调度(Least-ConnectionScheduling)

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

四加权最小连接调度(WeightedLeast-Connection Scheduling)

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

五基于局部性的最少链接(Locality-BasedLeast Connections Scheduling )

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

六带复制的基于局部性最少链接(Locality-BasedLeast Connections with Replication Scheduling)

带复制的基于局部性最少链接调度(Locality-BasedLeast 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地址对应的服务器组;按“最小连接”原则从该服务器组中选出一台服务器,若服务器没有超载,将请求发送到该服务器;若服务器超载;则按“最 小连接”原则从整个集群中选出一台服务器,将该服务器加入到服务器组中,将请求发送到该服务器。同时,当该服务器组有一段时间没有被修改,将最忙的服务器从服务器组中删除,以降低复制的程度。

七目标地址散列调度(DestinationHashing Scheduling)

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

八源地址散列调度(SourceHashing Scheduling)

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

Rhel6-lvs配置文档