Rhel6-lvs配置文档

系统环境: rhel6 x86_64 iptables and selinux disabledhtml

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

yum仓库配置:算法

[rhel-source] vim

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] tcp

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

因为IPv4IP地址空间的日益紧张和安全方面的缘由,不少网络使用保留IP地址(10.0.0.0/255.0.0.0172.16.0.0 /255.128.0.0192.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地址或者端口号。咱们所知道有这个问题的网络服务有FTPIRCH.323CUSeeMeReal AudioReal VideoVxtreme / VosiacVDOLiveVIVOActiveTrue SpeechRSTPPPTPStreamWorksNTT AudioLinkNTT SoftwareVisionYamaha MIDPlugiChat PagerQuakeDiablo

下面,举个例子来进一步说明VS/NAT,以下图所示:





VS/NAT的配置以下表所示,全部到IP地址为202.103.106.5和端口为80的流量都被负载均衡地调度的真实服务器 172.16.0.2:80172.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查看


如下步骤在server19server25上实施:

[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/TUNTCP状态迁移是按照半链接的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查看

 

如下步骤在server93server94上实施:

[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服务的非对称特色,负载调度器中只负责调度请求,而服务器直接将响应返回给客户,可 以极大地提升整个集群系统的吞吐量。该方法与IBMNetDispatcher产品中使用的方法相似,但IBMNetDispatcher是很是昂贵 的商品化产品,咱们也不知道它内部所使用的机制,其中有些是IBM的专利。

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


 

VS/DR的工做流程下图所示:它的链接调度和管理与VS/NATVS/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 根据负载均衡算法选择一台activerealserver(假设192.168.57.122),将此 RIP 所在网 卡的mac地址做为目标 mac 地址,发送到局域网里.此时 IP 包头及数据帧头信息以下:


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


4 若是clientVS同一网段,那么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 地址,因此这里不一一叙述。在实际应用中,源地址散列调度 和目标地址散列调度能够结合使用在防火墙集群中,它们能够保证整个系统的惟一出入口。

相关文章
相关标签/搜索