Rhel6-lvs配置文档

系统环境: 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=Instructor Server 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=Instructor Server 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=Instructor Server 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=Instructor Server 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

Load Balancer:

kernel 2.6.x 已內建 LVS 模组

kernel 2.4.x 或之前的内核版本需打补丁

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

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

	VS/NAT	VS/TUN	VS/DR
Server	Any	Tunneling	Non-arp device
Server network	Private	Lan/Wan	Lan
Server number	Low(10~20)	High(100)	High(100)
Server gateway	Load balancer	Own router	Own router

注:以上三种方法所能支持最大服务器数目的估计是假设调度器使用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访问时，就需要采用网络地址转换（Network Address Translation, 以下简称NAT），将内部地址转化为Internets上可用的外部地址。NAT的工作原理是报文头（目标地址、源地址和端口等）被正确改写后，客户相信它们连接一个IP地址，而不同IP地址的服务器组也认为它们是与客户直接相连的。由此，可以用NAT方法将不同IP地址的并行网络服务变成在一个IP地址上的一个虚拟服务。

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

客户通过Virtual IP Address（虚拟服务的IP地址）访问网络服务时，请求报文到达调度器，调度器根据连接调度算法从一组真实服务器中选出一台服务器，将报文的目标地址 Virtual IP Address改写成选定服务器的地址，报文的目标端口改写成选定服务器的相应端口，最后将修改后的报文发送给选出的服务器。同时，调度器在连接Hash 表中记录这个连接，当这个连接的下一个报文到达时，从连接Hash表中可以得到原选定服务器的地址和端口，进行同样的改写操作，并将报文传给原选定的服务 器。当来自真实服务器的响应报文经过调度器时，调度器将报文的源地址和源端口改为Virtual IP Address和相应的端口，再把报文发给用户。我们在连接上引入一个状态机，不同的报文会使得连接处于不同的状态，不同的状态有不同的超时值。在TCP 连接中，根据标准的TCP有限状态机进行状态迁移；在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，如下图所示：

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	Virtual IP Address	Port	Real IP Address	Port	Weight
TCP	202.103.106.5	80	172.16.0.2	80	1
172.16.0.3	8000	2
TCP	202.103.106.5	21	172.16.0.3	21	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处理的。

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

Load Balance 双网卡 192.168.122.163(外网) 192.168.1.163(内网)

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

Load Balance 192.168.1.163 server63.example.com

Gateway 192.168.1.163 （注：Realserver的网关应设为Load Balance的内网IP）

Realserver1 192.168.1.119 server19.example.com

Realserver2 192.168.1.25 server25.example.com

Virtual IP 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

注：可用ip addr 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隧道（IP tunneling）是将一个IP报文封装在另一个IP报文的技术，这可以使得目标为一个IP地址的数据报文能被封装和转发到另一个IP地址。IP隧道技 术亦称为IP封装技术（IP encapsulation）。IP隧道主要用于移动主机和虚拟私有网络（Virtual Private 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有限状态机进行的。

Realserver 192.168.122.193 server93.example.com

Realserver 192.168.122.194 server94.example.com

Load Balance 192.168.122.13 server13.example.com

Gateway 192.168.122.13(LB的网关为自身，Realserver的网关均为LB)

Virtual IP 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

注：可用ip addr 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 返回给用户.

 

Realserver 192.168.122.119 server19.example.com

Realserver 192.168.122.25 server25.example.com

Load Balance 192.168.122.163 server63.example.com

Virtual IP 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

注：可用ip addr 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-s 192.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

注：可用ip addr 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-s 192.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

注：可用ip addr 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 设置在出口网卡上,否则会响应客户端的 arp request,造成 client/gateway

arp table 紊乱,以至于整个 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 或者 Load Balance 则没有存在的实际意义.

6. LVS/DRip_forward 需要开启吗?

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

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

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

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

一 轮叫调度(Round-Robin Scheduling)

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

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

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

三 最小连接调度(Least-Connection Scheduling)

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

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

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

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

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

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

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

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

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

八 源地址散列调度(Source Hashing Scheduling)

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